Как мы можем реально планировать проекты с учетом вопросов поддержки?

У нас проблема на работе: мы пытаемся планировать работу так, чтобы мы могли оценить временные рамки и получить сроки.

Проблема в том, что трудно спланировать проект, не зная всего, что произойдет.

Например, прямо сейчас мы запланировали все наши проекты до начала декабря, однако в это время у нас будут различные внутренние и внешние встречи, телеконференции и дополнительная работа. Хорошо, что проект займет три недели, но если в это время будет недельный перерыв, тогда дата завершения будет перенесена на неделю.

Проблема в 3 раза:

1. Когда мы планируем проекты, временные рамки принимаются буквально. Если мы оцениваем три недели, крайний срок устанавливается на три недели, клиенту говорят, и нет места для продления.

2. Промежуточная работа и такое означает, что мы теряем продуктивное время, работая над проектом.

3. Иногда у клиентов нет времени, которое нам нужно, чтобы выполнить работу, поэтому они иногда приходят к нам и говорят, что им нужен проект, выполненный к концу месяца, даже если мы думаем, что работа займет два месяца. - не говоря уже о том, что у нас уже есть работа.

У нас есть диаграмма Ганта, которую мы пытаемся заполнить всеми имеющимися у нас проектами, и мы заполняем расписания, но они вообще не сравниваются с диаграммой Ганта. Из-за этого сложно сказать: «Ну, мы запланировали 3 недели для этого проекта, но мы потеряли неделю здесь, поэтому крайний срок должен быть перенесен на неделю».

Также не профессионально соблюдать установленные сроки, о которых мы сообщали клиенту.

Как другие люди справляются с такой ситуацией? Как вы управляете планированием проектов? Сколько «дополнительного» времени вы запланируете в проекте для учета внепроектной работы, которая происходит во время проекта? Как вы справляетесь с проблемами поддержки, ошибками и прочим? Вещи, которые вы не можете учесть во время планирования?

ОБНОВИТЬ

Большое количество хороших ответов, спасибо.

Однако проблема в том, что сложно планировать проект, не зная всего, что произойдет.

В этом смысл управления рисками. Вы не можете знать все, поэтому вы планируете на основе того, что вы знаете, и определяете, какие вещи могут оказать наибольшее влияние на ваш план и насколько вероятно, что это произойдет. Оцените также потенциальное влияние графика, сказав, что если произойдет X, это приведет к смещению графика на предполагаемые (по ключевым словам - оценочные) Y дней или недель.

Все хорошо, что проект займет 3 недели,

Никогда не давайте такой конкретной оценки. Укажите диапазон или количественно определите вероятность достижения этой оценки. Например, скажите «этот проект займет 2-5 недель» или «есть вероятность 85%, что этот проект будет выполнен через 3 недели, и 95%, что он будет выполнен через 4 недели».

Клиенту также непрофессионально постоянно повторять, что мы пропустили крайний срок.

Правда. Однако вы смешиваете понятия «оценка», «график» и «срок исполнения». Ваша оценка является приблизительной оценкой того, сколько времени потребуется, чтобы выполнить задание или проект, и вероятностью выполнения этого. Крайний срок - назначенная клиентом дата, когда проект должен быть выполнен, чтобы повысить ценность. Расписание - это то, как вы используете имеющиеся ресурсы, чтобы уложиться в срок.

Бывают моменты, когда просто невозможно выполнить назначенную работу в установленные сроки, и все оценки и планирование в мире не будут иметь значения.

Итак, мой вопрос ... как другие люди делают это? Как вы управляете планированием проектов? Сколько «дополнительного» времени вы планируете в проекте для учета всего, что происходит в это время?

Я рекомендую прочитать две книги, обе от Стива Макконнелла: Оценка программного обеспечения: Демистификация Black Art и Быстрое развитие: Укрощение графиков программного обеспечения . Оценка программного обеспечения - это все о том, как придумать ваши оценки, представить их клиентам, а также некоторые аспекты ведения переговоров и решения нереалистичных ожиданий. Rapid Development - это общее управление проектами, касающееся жизненных циклов разработки, планирования, распределения ресурсов, а также того, как наилучшим образом планировать и составлять бюджетные проекты, чтобы соответствовать вашим оценкам и срокам.

Я бы предложил покопаться в деталях процесса разработки Scrum . Это покрывает такие побочные действия focus factorметрикой. В основном вы должны проработать 2-3 спринта / итерации, а затем измерить коэффициент фокусировки вашей команды (и для каждого участника это также будет полезно). После этого вы сможете предоставить более точные оценки, которые охватывают ежедневную активность.

Взгляните на эту статью - «Фактор фокуса»

Если кто-то из вас знаком с гибкой разработкой, вы, вероятно, слышали о факторе фокуса (или факторе производительности). Он используется для планирования, чтобы помочь определить, сколько «реальных часов» вам нужно над чем-то работать. Это разница между «реальными часами» и «идеальными часами».

Особенность прерываний заключается в том, что для отдельных лиц или команд они имеют тенденцию происходить в относительно небольшом диапазоне вероятностей. Например, у вас примерно одинаковое количество собраний в неделю, или примерно одинаковое количество часов, затрачиваемых на срочные исправления ошибок каждый месяц, или одинаковое количество времени, затрачиваемое на ответы на вопросы людей, приходящих к вам на стол, особенно при усреднении по длительный период времени.

Многие современные методы планирования принимают это во внимание. Скрам переводит это в скорость. Планирование на основе доказательств также использует скорость с доверительным интервалом для любой данной оценки. Pomodoro учитывает перерывы, когда вы решаете, сколько «pomodoros» вы можете рассчитывать на завершение в любую данную неделю. Все это зависит от отслеживания исторических показателей ваших прерываний и их учета в ваших оценках. Я рекомендую вам взглянуть на все из них и разработать технику, которая будет работать для вашей команды.

Хороший совет всем вокруг.

Еще одна вещь, которая может быть полезна для решения вопросов поддержки, - это выделять людей для поддержки на постоянной основе.

Например, если у вас есть 5 разработчиков, назначьте по одному на каждый день недели. Когда наступит этот день, назначенный разработчик работает на тот день ТОЛЬКО на поддержке. На следующий день другой разработчик берет на себя поддержку. Таким образом, у каждого есть шанс остаться в своем «потоке», каждый получает вкус собачьей еды.

То, как вы на самом деле решили разделить регулярную работу по поддержке, на самом деле не имеет значения ( циклический перерыв дня недели - только пример). Что важно, так это ограничить время поддержки фиксированными регулярными интервалами. Это делает время разработки более предсказуемым с компромиссом, так что вы не можете «все бросить все» для решения вопросов поддержки.

Это навык, который действительно приходит с опытом, и часто людей спрашивают, прежде чем они смогут точно судить о такой вещи. Я всегда работал в довольно сплоченной группе с неформальным стилем, но мы разработали несколько эмпирических правил, которые, казалось, хорошо держались.

Во-первых, ни одно задание не займет меньше недели. Всегда оценивайте в неделях, даже если задача только кажется, что она займет несколько дней. По какой-то причине это не будет сделано до конца недели.

Во-вторых, сделайте все возможное, чтобы оценить, сколько времени займет задача, включая прерывания, проблемы с поддержкой клиентов, прохождение тестирования и т. Д. Теперь удвойте это число. Это ваша оценка (в неделях).

В-третьих, убедитесь, что ваш менеджер еще не добавляет некоторые отступы к вашим оценкам. В нашей команде менеджер пожаловался на наши оценки. Оказалось, что он уже собирался умножить это на 2,1 (его эмпирически полученная оценка заполнения), и мы уже удвоили это, прежде чем сказать ему.

Это не причудливый инструмент и, возможно, не идеальный метод, но он работает на удивление хорошо.

Люди, занимающиеся оценкой, должны понимать, что ни одна команда никогда не участвует в проекте на 100%. У вас есть отпуск по болезни, отпуск, обязанности присяжного, отпуск по случаю тяжелой утраты, необходимые встречи с персоналом (это выгодное время!), Групповые встречи, которые не связаны с проектом, неизбежная задержка, перерывы в ванной комнате, работа по поддержке над уже работающими предметами, работа с электронными письмами настройку нового компьютера после его смерти, ответы на вопросы о будущей работе и оценки ее работы, наставничество для младших школьников и т. д., которые необходимо учесть. Оценщик не несет ответственности за то, что он предположил более 6 из 8 часов доступно в день. Это гарантия, что срок не может быть соблюден. Если вы гарантируете, что крайний срок не может быть соблюден, вы гарантируете несчастного клиента.

Вы абсолютно правы - сложно спланировать проект, не зная всего, что произойдет. Но очень важно следить за вещами, которые являются нормой, а также за задачами, которые вы предвидите. Вот где управление расписанием играет свою роль. Я использую Microsoft Project Management (стандартная версия), для которой также включены функции, являющиеся частью программного обеспечения для управления проектами.

Вы можете посетить http://www.microsoft.com/project/en/us/schedule-management.aspx для получения дополнительной информации.

Похоже, что от ваших проектных команд много скрытых усилий, из-за которых вы теряете фокус и скорость. Возможно, было бы полезно отделить задачу по

... проблемы поддержки и ошибки и прочее?

для конкретной группы людей, чтобы другие члены команды могли сосредоточиться на новых задачах разработки. В результате их общее производство может немного снизиться, но качество улучшится, потому что меньше отвлекается. Это, в свою очередь, уменьшит количество ошибок, а следовательно, специальную работу, которая поможет вам в ваших проектах.

Что касается планирования, я полностью согласен с ответом Томаса Оуэнса.