Войти в систему
Войти с помощью соц. сетей:
В предыдущих разделах мы рассмотрели особенности того, что календарная длительность проекта не зависит линейно от трудозатрат в оценках задач в расчете на одного специалиста. Разделение задачи между несколькими специалистами вызывает дополнительные затраты на обучение и обмен информацией, что приводит, как правило, к падению производительности на 10–30 % в расчете на каждого дополнительного участника команды проекта, участвующего или влияющего на разработку. То есть получается, что небольшие команды более эффективны. Но следует отметить, что при большой масштабности задач небольшая команда может просто не справиться в разумные сроки или с приемлемым уровнем качества. В общем случае нельзя просто взять и поделить итоговое число часов, полученное оценками ИСР проекта, на 8 рабочих часов в день и число специалистов в команде для получения итогового срока в рабочих днях. Но тогда как же получить календарный срок проекта, зная его трудозатраты?
Прежде чем ответить на этот вопрос, вернемся к особенностям самой оценки трудозатрат, т. к. этот вопрос не был закрыт рассмотрением методов оценок до конца. Все приведенные выше методы оценки трудозатрат, используемые при оценках бюджета проекта, показывают парадоксальную картину: все сводится к экспертным оценкам как основе для прочих моделей («снизу вверх», PERT, аналогов). А как именно думает эксперт – не формализованный процесс! Это же человек, а человеку свойственно ошибаться. Разработчики часто склонны быть оптимистами и оценивать любую задачу только со стороны разработки. А это время изучения задачи и самого процесса программирования ее реализации. Отладка, тестирование, документирование, обучение пользователей, настройка данных для рабочей базы – это все остается за бортом, если спросить: «За сколько сделаешь?» – у разработчика. Что логично: остальное же делает не он. В проектах автоматизации много работы, вообще не связанной непосредственно с разработкой. Поэтому спрашивать как эксперта нужно системного архитектора, который понимает, когда задача действительно завершается, сколько людей и каких над ней работают.
Как бороться с рисками обычно оптимистичных оценок экспертов со стороны разработки, мы рассмотрим в следующей главе. Если кратко, то нужно вводить коэффициент-мультипликатор к оценкам экспертов (причем у каждого эксперта он может быть своим и определяется руководителем проекта опытно).
Рассмотрим подробнее прием применения параметрических оценок, когда задачи ИСР классифицируются по сложности реализации и применяется соответствующий шаблон оценок. Например, шаблоны от сложности модификаций:
Сами шаблоны оценок получаются экспертными оценками, аналогами и уточняются формулой PERT.
Ключевое для нас – это понять состав работ внутри такого шаблона, то, что даже самая простая на первый взгляд задача («да что тут делать, за 15 мин справлюсь») имеет определенный пул сопроводительных работ и задач на 15 минут в проектах внедрения ERP-систем просто не бывает.
Рассмотрим в качестве примера шаблон оценки разработки простого отчета: какие работы входят в такую модификацию системы, кто участвует (в часах) и сколько календарного времени это может занять. Оценки даны примерные и могут различаться внутри разных команд.
| Описание работы | Консультант | Разработчик | Системный архитектор | Календарных дней |
|---|---|---|---|---|
| Формирование шаблона отчета с предварительным описанием заполнения по столбцам | 4 | 1 | 0,5 | |
| Обсуждение и согласование шаблона с заказчиком | 1 | 0,5 | 0,5 | |
| Подготовка ТЗ с описанием шаблона и особенностей алгоритмов | 4 | 1 | 0,5 | |
| Обсуждение, согласование и уточнение ТЗ | 2 | 1 | 1 | 0,5 |
| Разработка по утвержденному ТЗ | 8 | 0,5 | 1 | |
| Тестирование модификации системы, устранение дефектов | 3 | 2 | 0,5 | 1 |
| Обновление или подготовка нового руководства пользователя | 2 | 0,5 | 0,5 | |
| Перенос модификации, настройка данных для демонстрации и тестирования на сервере заказчика | 0,5 | 0,5 | 0,25 | |
| Демонстрация работы нового функционала специалистам заказчика | 0,5 | 0,25 | ||
| Поддержка тестирования модификации и ее приемки специалистами заказчика | 2 | 2 | 1 | |
| Итого | 19 | 13,5 | 6 | 5 |
Отметим, что прямой конвертации трудозатрат в человеко-часах в календарные дни путем деления часов на 8 часов в рабочем дне в шаблоне нет. В случае задач с согласованием (внутри команды и тем более с заказчиком) возникают накладные расходы на ожидание, когда специалисты смогут встретиться (удаленно подключиться) и обсудить или посмотреть функциональность. Во время простоя могут выполняться другие задачи, но календарно именно разработка некоего простого отчета быстрее не завершится.
Поддержка процесса тестирования специалистами заказчика календарно в этом примере шаблона не оценена, т. к. считаем, что модификация от исполнителя уже сдана заказчику. При сложной структуре баз данных проекта (отдельные базы для разработки, тестирования исполнителем, тестирования заказчиком и рабочей базы) календарное время на тестирование заказчиком тоже нужно закладывать в шаблон, т. к. без завершения этого этапа модификация не попадет в рабочую базу. Так как логично общее время задачи считать до полного завершения жизненного цикла разработки – передачи функциональности конечному пользователю и перевода ее в промышленную эксплуатацию.
Как мы видим из рассмотренного примера, довольно простой отчет, который, если спросить конечного разработчика: «За сколько сделаешь?» – то он ответит: «За 1 день», выливается в почти 40-часовые работы на 5 календарных дней. Вот если спрашивать системного архитектора как эксперта, то он такой отчет оценит – уже с учетом всех участников и запаса времени на согласования с заказчиком – как раз в рабочую неделю на 40 часов, что и соответствует детализированному шаблону.
Такие детальные шаблоны на разные виды задач и разные по сложности модификации хорошо показывают руководителю проекта со стороны заказчика логику расчета трудозатрат и снимают вопросы о том, почему так много часов по такой, казалось бы, простой модификации системы. Так как в ИСР оценки будут сводные на задачу целиком, а не с такой детализацией, как приведено в шаблоне выше. Все это в итоге позволяет защитить сводные оценки трудозатрат, итоговый бюджет и обосновать календарные сроки проекта.
Есть еще один важный психологический аспект, связанный со сроками, и закон Паркинсона к нему: «Работа заполняет все время, отпущенное на нее» (для консалтинга можно добавить: «И еще чуть-чуть сверху»). В идеале руководителю проекта нужно планировать разные версии сроков: для заказчика и для специалистов внутри команды. Установить внутренние сроки меньше внешних, чтобы был запас по времени, о котором не должен знать конечный исполнитель задач. Как это сделать при прозрачности проектной документации и доступности ее всей команде проекта?
Эмпирический закон был сформулирован историком Сирилом Норткотом Паркинсоном в его сатирической статье, напечатанной в британском журнале The Economist в 1955 году и изданной позднее в книге «Закон Паркинсона» (англ. Parkinson’s Law: The Pursuit of Progress; Лондон, John Murray, 1958).
При моделировании в системе управления проектами и задачами можно задачу разделять не просто на «постановку – разработку – тестирование», но добавить еще задачу «внедрение», где стоит отдельный исполнитель, не разработчик или консультант. Эта подзадача будет влиять на сроки завершения всей задачи целиком, но не мешать, например, разработчику переключаться на другие задачи разработки встык с завершенной задачей по связям. И будет фиксировать срок завершения разработки (внутренний срок) при итоговом большем внешнем сроке по всей задаче для заказчика.
Все это делает график запутаннее и сложнее для восприятия, но как подход расчета внешних сроков работает. Для данной книги по введению в тему управления проектами это все может быть преждевременно и излишне усложнит материал и его понимание, до этого нужно дойти на практике самостоятельно. Потому обозначим, что есть проблема планирования внешних сроков и внутренних дедлайнов для команды, это нужно понимать и учитывать при планировании календарных сроков.
Вообще поддерживать в актуальном состоянии максимальной детализации план-график очень сложно. При использовании для планирования Excel (с нарисованной там диаграммой Ганта) перебить все связи задач, их даты и длительность в них будет очень сложно. Потому нужно либо использовать специализированное ПО для проектного управления, либо актуализацию отчетного план-графика проводить только на высокоуровневых задачах и фазах целиком. А отклонения и прогресс исполнения конкретных задач оставить в системе класса Task Tracking, позволяющих учитывать плановое и фактическое время по задачам. Например, система 1С:СППР позволяет решать вопросы отслеживания и планирования исполнения задач. Для заказчика высокоуровневой актуализации плана-графика проекта будет достаточно, т. к. внутренняя декомпозиция до подзадач разных исполнителей – это внутренние планы исполнителя.
Если руководитель проекта со стороны заказчика настаивает на максимальной детализации и контроле за ходом проектных работ, то ему можно дать доступ в такую систему Task Tracking или строить отчет из нее.
Вернемся с расчету календарного срока проекта. Необходимо учесть время отпусков специалистов (как исполнителя, так и заказчика), заложить риски на болезни (если работы попадают на ежегодные сезоны простуд). Если ИСР имеет достаточную детализацию, то расчет сроков можно доверить инструментарию управления проектом, способному выстроить последовательность исполнения задач диаграммой Ганта на календарь с учетом выходных и праздничных дней. Остается аккуратно задать последовательность и связи исполнения задач, заложить время ожидания реакции со стороны заказчика (этим сложно управлять исполнителю; хотя сроки реакции и прописываются в уставе проекта, но календарно нужно иметь некий дополнительный запас). Получаем итоговый план-график.
В процессе согласования проекта срок его начала может сдвигаться – нужно будет актуализировать план-график: по мере сдвига срока начала проекта смещаются условия, заложенные в план (сезонность, отпуска). Недостаточно только в одной задаче изменить дату начала работ и ждать того, что весь график сместится сам. В идеале – да, и ПО управления проектами такую задачу существенно облегчает, но критически посмотреть и скорректировать новые сроки руководителю проекта тоже нужно. В итоге от переноса сроков начала работ по проекту может измениться календарная длительность срока проекта – например, стать больше на полмесяца за счет того, что происходит наложение на январь, в котором первая неделя праздничная, а февраль короткий месяц.
Нужно также помнить и регулярно обновлять план-график проекта по мере внесения изменений в согласованные ранее границы проекта. В ходе проекта могут возникать дополнительные работы, не заложенные в проект изначально. Расширение границ проекта может быть оформлено дополнительными соглашениями к договору по обоюдной договоренности сторон, нужно помнить, что любые дополнительные работы (или выявленные задержки), очевидно, влияют на итоговый срок, и лучше это явно отражать в соглашениях. Сами соглашения могут менять или не менять бюджет проекта, но вот срок они, скорее всего, увеличат в любом случае.
Ведение руководителем проекта со стороны исполнителя план-факта по исполнению задач, выполняемых сотрудниками заказчика, и соблюдению их контрольных сроков позволит в итоге исполнителю бесконфликтно сдвинуть срок на накопленные заказчиком задержки. Например, исполнитель не сможет реализовать свою задачу по загрузке начальных данных, если заказчик их не предоставит своевременно. Или будет все время переноситься начало обучения из-за невозможности собрать сотрудников заказчика в группу.
Руководителю проекта нужно учесть такие задержки при планировании работ, чтобы не приходилось регулярно менять заявленный срок проекта, пусть и не по вине исполнителя, так как частое продление срока смотрится не очень хорошо – больше похоже на плохое планирование и управление рисками.
Как выявлять риски и бороться с ними на ранних стадиях, рассмотрим в следующей главе.
Войти с помощью соц. сетей: