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

Для того что бы не объяснять каждому новому ПМу как делать план в Project'e и какие работы и какую структуру туда закладывать, я решил сделать некий драфт плана, который показывал бы типовую структуру работ по проекту внедрения и доработки простой информационной системы, стоимостью приблизительно 5 миллионов рублей и сроком около полугода. Условно, заказчик хочет стартовать проект в мае, а завершить в октябре, при этом старт проекта для нас — начинается в апреле, с подготовки пилота и КП.

Описание проекта


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

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

Риски проекта


Поскольку никакого Rocket Science в проекте нет, его риски составляют около 10%. Заложить их можно по разному — добавить 10% к стоимости ресурсов (но это не учитывает сроки), планировать работы с учетом рисков накидывая 10% длительности к каждой сколько-либо рискованной (именно такой вариант использовал я), или сделать этап Contingency перед завершающим этапом (в моем случае он бы составлял 3 недели или ~1/10 от длительности проекта.

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

Команда проекта


Руководитель проекта — менеджер, с хорошей технической экспертизой и навыками бизнес- анализа. Хорошо разбирается в функциональности решения, понимает бизнес-задачу заказчика.
Аналитик — проводит встречи по анализу, занимается разработкой проектной документации (протоколы встреч, описание функциональных требований, спецификаций, инструкций и т.д.)
Специалист по внедрению — отвечает за внедрение решения, организацию инфраструктуры для серверов, а так же их связь с внешним миром. Т.е. настраивает ОС, БД, отвечает за трекер поддержки и т.д.

  • Ведущий разработчик — он же архитектор. Участвует в проработке архитектуры решения, оценке задач по разработке, обеспечивает наставничество команде разработки и помощь в решении сложных задач.
  • Разработчик — основной разработчик проекта,
  • Младший разработчик — джуниор на подхвате кода, решает задачи под контролем разработчика, параллельно учится.
  • Аккаунт — менеджер по работе с клиентами, отвечает за взаимодействие с клиентом, составление и подписание договоров, контроль удовлетворенности клиента и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
  • Куратор — высший менеджер компании исполнителя, обеспечивающий контроль и поддержку проекта. Может быть так же — руководитель портфеля проектов и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
  • Заказчик — все сотрудники заказчика, привлекаемые к проекту. В плане — не детализируемы, предполагается что заказчик сам решит, кого из своих специалистов привлекать к тем или иным активностям.

Конечно, нам нужно забить команду проекта на представлении «Лист ресурсов» — я просто указал роли, краткое наименование и внутренние ставки (они «средние по больнице» и не привязаны к конкретной компании), а так же указал свой базовый календарь (в общем, соответствующий производственному календарю на 2018 год). Если вы используете сервер проектов, в дальнейшем вы можете указать вместо роли — конкретных исполнителей, но на данном этапе — важны именно роли, для понимания необходимости сотрудников той или иной квалификации. Если вы готовите план проекта для представления заказчикам, есть смысл заменить внутренние ставки на внешние — и то и другое вы наверное уже знаете, а если нет — то это повод обратится к владельцам ресурсов, которые их откроют.

Минимум миниморум:



Конечно, роли могут быть другими — все зависит от компании (и методологии) в которой вы делаете проекты. Одним даром не нужен аналитик и внедренец, у них есть консультанты, другие делят аналитиков на бизнес и системных и добавляют техписателей, третьи используют стажерские программы с подключением сотрудников и т.д. У меня — один из множества вариантов команды, на листе ресурсов можно смело заменить сущности на свои и добавить новые.
Здесь, мы отмечаем заказчиков — зеленым цветом, а специалистов нашей компании, не подлежащих к расчету ФОТа — фиолетовым. Кроме того, что это наглядно, это так же удобно в дальнейшем, например если заказчик попросит сформировать график его привлечения к проекту — вы просто выгрузите план в Excel и отфильтруете по цвету.

Жизненный цикл проекта


В данном кейсе использован очень простой и распространённый жизненный цикл проекта — хорошо знакомый всем «Waterfall» где несколько фаз следуют друг за другом.

Некоторые части проекта все же сделаны итеративно — например разработка разбита на итерации, в конце каждой из которых — реализуется показ разработанного функционала заказчику.
Но тем не менее, такой жизненный цикл не предполагает каких либо серьезных изменений в ходе проекта, поэтому предполагается что скоуп проекта определен на этапе входа в проект, а ограничения по скоупу разработаны и включены в договор. Стоит так же отметить «Этап 0» — на котором происходит оценка скоупа и организация пилотного проекта (для некоторых компаний это нынче редкость) — здесь предполагается что руководитель проекта выступает так же неким руководителем пресейла, в котором он описывает и оценивает функционал, а так же неким руководителем «пилотного» проекта — цель которого, познакомить заказчика с функционалом системы, показать ему интерфейс и преимущества на берегу, что бы заинтересовать его. Пилотный проект назвать проектом можно лишь условно — естественно, это просто стандартная заготовка системы минимально дорабатываемая под нужды конкретного заказчика. Например, виртуальная машина со стабильной версией системы, в которой может быть быстро реализована пара простых, но реальных процессов заказчика, и, например, быстро настроена связь с одной из используемых им систем (на основе уже существующего драйвера, или коннектера, требующего лишь простой настройки).

Так же для экономии места на экране я убрал отображение поля «Режим задачи» — на всех задачах он автоматический, ручного нигде нет.

Общий обзор этапов, их сроков и стоимости:



Итак, у нас есть 8 этапов (включая этап 0) и проект, который начинается 2 апреля, завершается 5 октября. Заказчику — можно вовсе не показывать этап 0, и конечно, не стоит его учитывать если вы не считаете ФОТ пресейлов и пилотов (но это для первый звоночек того, что вам есть над чем поработать, так как такой ФОТ считать нужно обязательно).

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

Этап 0 — подготовка проекта


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

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

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

При средних ставках внедренца и ПМа такой пилот будет стоить нам 59 400 рублей + еще 10800 рублей на его сопровождение, ведь у Заказчика появятся вопросы про его развертывание и использование. Ну как, вы все еще не хотите считать затраты на нулевом этапе?

Далее, если заказчику понравился пилот, мы приступаем к анализу скоупа проекта и его оценке. Предполагается, что проект типовой и все методы оценки уже разработаны и опробованы в вашей компании — если это не так, то вас ждет увлекательный аттракцион по сравнению стоимости работы написания ТЗ со стоимостью разработки функционала, покрывающего то, или иное требование (но это тема отдельной статьи).

Предположим, процесс описания скоупа и оценки у вас поставлен на поток, и после оценки куратор проекта одобряет ее (и накидывает % на торг и внепроектные риски) после чего КП отправляется на согласование заказчику. Здесь указанных 7 рабочих дней может быть явно мало, поэтому эта работа указана отдельно, и именно от нее зависит веха «КП Утверждено».

Разделять задачи по организации пилота и оценке скоупа проекта — надо, т.к. вы должны хорошо понимать их стоимость, и пытаться оптимизировать затраты на подготовку пилотов и оценку (например, создать типовые шаблоны для оценки и типовые виртуалки для внедрения).



Этап 1 — сбор требований


Итак, вы успешно подписали контракт (или получили одобрение от спонсора внутреннего проекта) и теперь самое время стартовать, начав со сбора требований к системе. Но перед этим, надо надо устроить kick-off meeting, или как это называется на русском, стартовую встречу.

В некоторых проектах есть смысл показать разработанный Project Charter, в некоторых проектах вместе с договором подписывается официальный устав, но независимо от этого кикофф нужен — для того, что бы ясно объяснить цели и сроки проекта команде (или командам) и познакомить всех друг с другом, договорится о взаимодействии. В общем, проведение Kick-off — это тоже тема отдельной статьи.

Т.к. проект небольшой, мы предполагаем, что 12 часов за глаза хватит нам, что бы подготовить небольшую презентацию, в которой мы вкратце обозначим цели и задачи проекта, участников и их роли, наглядно покажем сроки проекта (например, красивую диаграмму Ганта) и представим следующие шаги (например график встреч с заказчиком).

А вот кстати, и график встреч — для нашего простого проекта мы предусмотрели 6 встреч, на которых участвуют разные специалисты и которые стоят для нас по разному. Предполагается, что график мы заранее согласовали с заказчиками (или спонсорами), что бы бизнес-пользователи и вообще все заинтересованные лица, не ушли в отпуска или не были заняты на других активностях. Конечно, если вы работаете над внешним проектом, есть смысл включить план проекта в договор — в этом случае никто не сможет обвинить вас в срыве сроков, если заказчик по каким то причинам не сможет присутствовать на встречах.



Рассмотрим несколько встреч на примере:



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

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

Естественно, это идеальный вариант, который работает только при наличии 2 очень сильных и мотивированных проектных команд.

В реальной жизни — отсидеть на встрече 4 часа и за 4 часа составить приличный протокол с описанием требований и договоренностей (или отревьювить его) — и так 6 дней подряд — довольно тяжело. Не говоря о том, что встреча может быть и более 4 часов (кстати, в этом случае эффективность встречи резко падает и протокол может быть и не согласован). Если сроки (и заказчик) позволяют — заложите 1 встречу в 2 дня, и возьмите запас недельку — для проведения дополнительных встреч и ревью протоколов. Если вы на 100% не уверены в заказчике и команде — никогда не ставьте на неделе более 3 встреч. Ну и конечно, все зависит от региона присутствия — если вы делаете проект в своем городе, или хотя бы в своей области — тут торопится смысла нет. Если же ваш заказчик из Нового Уренгоя, а вы — из Самары — увы, придется выложится на встречах по полной — мариновать команду без работы в другом городе нет никакого смысла. Так же, обязательно пропишите участие заказчика во встречах отдельной строкой — и вставьте это в договор.

Этап 2 — Архитектура и дизайн


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

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

Есть ли смысл детализировать эти 5 дней в задачи и отражать их в плане проекта? На мой взгляд нет, логичнее сделать это в Jira/Redmine, а заказчику/спонсору показать такой план.
У меня предусмотрено 2 итерации согласования — это совершенно разумно, но требует от заказчика определенной ответственности — на берегу стоит объяснить, что все замечания к ТЗ Заказчик выставляет в одной итерации, а во второй — только проверяет их исправление, а новые замечания — не ставятся. Если заказчик настаивает на третей итерации замечаний — что ж, хозяин барин, вставляем и третью (и четвертую, и пятую…) не забыв прописать затраты и объяснить заказчику насколько вырастет стоимость проекта. Презентовать ТЗ первый раз разумно вдвоем с аналитиком, а вот вычитывать его необходимо всей команде — на сколько либо больших проектах это весьма емкий документ, который является условием для завершения фазы проекта (а следовательно подписания актов и оплаты), и случайные ошибки в нем не допустимы. Если у вас в компании есть свободные ресурсы, например аналитики, логично подключить их к чтению ТЗ в качестве свежего взгляда — ТЗ от этого хуже не станет, а проект не подорожает на сколько бы существенно.



Этап 3 — Разработка


Итак, техническое задание подписано, и казалось бы можно приступать к разработке.
Первое, о чем хочется сказать — это предупредить о недопустимости начала разработки, без утвержденного ТЗ. Это ведет просто к тому, что одну и ту же работу приходится делать 2 раза. Конечно, если вы работает по Agile, и у вас четких требований нет, а есть заказчик платит по схеме Time&Materials, тогда смело игнорируйте это требование. Если же скоуп проекта у вас утвержден, оплата FixPrice и вы не закладывали бюджет и сроки на переделку задач, то не позволяйте разработчикам сделать ни единого коммита, без подписанного ТЗ.

Второе — конечно подразумевается, что инфраструктура для разработки развернута, а процессы отлажены. Нерадивые спонсоры и кураторы проектов, стремятся включить в бюджет проектов такие расходы — переход на использование CI, развертывание Jira/Redmine, переход на новую версию ПО и библиотек, БД и т.д. и т.п. Задача ПМа здесь — защитить свой проект (и его бюджет) от такого, аргументируя что такие вещи должны быть вынесены в отдельные проекты с отдельными бюджетами.

Если вы работает по Waterfall — делать разработку стоит итерационно — т.е. разбить весь скоуп на части и показывать заказчику/спонсору по мере наработок. Пускай в софте еще будут баги, пускай нет данных, пусть формы не доделаны — лучше потратить бюджет и время на написание сценариев показа и дополнительные тесты, чем пропасть на месяц с глаз заказчика и появится с готовым продуктом. Фидбек заказчика на этапе завершения итерации разработки так же полезен, но это не значит что его надо бездумно пихать в скоуп — оцените его замечания. Если он предлагает что то несущественное — например, сменить цвет или размер поля на форме — покажите что вы лояльны и приветливо согласитесь. Если заказчик предлагает откровенно сложный функционал — откажитесь, аргументировав отсутствием в скоупе, а если заказчик настаивает — запускайте свою машину changemanagment'а (конечно, она у вас есть). Бывает, что заказчик предлагает казалось бы что то не существенное, например поменять формат телефонного номера, но это может сказаться на всей системе. В этом случае, посоветуйтесь с ведущим разработчиком/архитектором, возьмите его оценку под этой фичей, если она небольшая — можно пойти навстречу заказчику для повышения лояльности (но стоит помнить о риске ошибки оценки).

Но все это еще впереди, а пока, вам нужно будет декомпозировать задачи из ТЗ в задачи в трекере задач. Здесь подробного универсального рецепта нет, но в общем случае — создать задачи по каждому функциональному требованию, и в его рамках создайте подзадачи. Далее, используя методы оценок (например покер планирования), вы с проектной задачей оцените трудоемкость задач. Не забудьте расставить приоритеты задач, в соответствии с итерациями (можете прикрутить к описанию задач номера спринтов, и планировать исходя из производительности команды). В плане проекта всегда разумно указать, что является результатом той или иной итерации (например разработаны экранные формы, интеграция, аналитика или что то еще) — что бы заказчик знал, что он получает на показах и мог отслеживать, идете ли вы по плану, или задерживаетесь. Постарайтесь разбить итерации исходя из вашего опыта, но в любом случае — не пропадайте надолго, и ведите протоколы показа, куда заносите замечания от заказчиков, с вашими решениями по ним — это прикроет вас, в случае конфликта относительно скоупа проекта — иначе говоря, поможет избежать ситуации на сдаче-приемке — «Не подпишем, мы ведь говорили, что окошко надо было делать синим…».



Этап 4 — Тестирование


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

Обратите внимание на задачу 110 (исправление дефектов) — она параллельна 109 (поиску дефектов) с задержкой в день. Т.е. предполагается, что тестировщик, проходя по тест-кейсам, описывает дефекты в системе задач, а разработчики правят их не отходя от кассы. Такой подход разумен и используется, но есть и другое решение — приступать к починке только когда тестирование будет завершено. Какой из этих подходов подойдет именно вам — знает ваш руководитель разработки.

Не забывайте, что заказчик тоже захочет протестировать систему — на этот случай вы предоставите ему документ который называется «ПМИ» — или программа и методика испытаний. Сделать его логично на основе разработанных тест-кейсов, убрав всю внутреннюю кухню и оставив только нужные заказчику вещи (в т.ч. нефункциональное тестирование).

ПМИ должен быть прочитан и утвержден заказчиком и именно по результатам прохождения ПМИ, заказчик будет принимать итоговое решение о переводе системы в промышленную эксплуатацию.
У меня в проекте — согласование ПМИ не включено, т.к. на моей практике, заказчики редко вчитываются в ПМИ и тест-кейсы, ибо слабо понимают о каком конкретно функционале идет речь и чем в одном случае чек-бокс отличается от радиобаттона в другом случае (это шутка, такое вообще в ПМИ писать не надо). Поэтому при разработке документа, особое внимание следует уделить списку кейсов, о прохождении которых пойдет речь, и конечно, проследить что бы они были нормально проработаны внутри.

Пройти ПМИ должны не только тестировщики, но и ПМ и аналитики, и желательно внедрение — сдавать систему придется всем вместе, и иметь представление о том, как работает функционал — очень полезно, и конечно. повышается шанс найти неочевидные дефекты.



Этап 5 — Внедрение


Ура! Мы добрались! Система на тестовых серверах работает как часы, команда QA отсыпается и уходит в отгулы, и пришел звездный час команды внедрения. Начинается он с развертывания окружения — и тут же у меня в плане заложен некий запас по времени, т.к. я подразумеваю что окружение развёртывали уже минимум 100 раз и в худшем случае на вашей корпоративной вике есть подробная инструкция по развертыванию, а в лучшем — внедренец сам ее писал. Главное, помните — после развертывания полезно протестировать все, что вы можете протестировать по заранее разработанному смоук-тесту, конечно же он остался у вас с фазы тестирования.
Теперь — о главном, ведь если дьявол и кроется где то, то это именно в интеграции и миграции данных. Сколько красивых диаграмм Ганта было погублено тем, что интеграция не была оттестирована тщательно и тем, что данные заказчика находились в ужасном состоянии, ненормализованные, выходящие за все грани разумного (и пределы полей), отличные от того, что написано в ТЗ.

Здесь главное — не дать заказчику сыграть на том, что интеграция (или миграция) может не заработать и переложить ответственность на вас — предупредите его заранее о том, что если эти работы будут задержаны по его вине, ответственность за увеличение сроков (и бюджета) проекта ляжет на его плечи. Не стесняйтесь писать письма и созывать ProjectBoard (или что там у вас) ибо интеграция и миграция пользовательских данных — это самая частая проблема срыва сроков на подобных проектах.

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

На прохождение ПМИ — планируйте от 25% времени ПМа и выше, в зависимости от вашего опыта и годности аналитика, который участвует в проекте — в идеале испытания должны проходить как по маслу, ну и во всяком случае в этом должен быть уверен заказчик по крайней мере до начала испытаний.

Если же испытания идут через пень колоду — виноват в этом ПМ, ПМ и еще раз ПМ — значит предыдущие фазы были или плохо запланированы, или плохо реализованы — ищите причину и решайте проблемы, но уже не за счет заказчика, а за счет рисков, который вы заложили на старте проекта.



Этап 6 — Поддержка


Или, как ее называют — сопровождение ОПЭ (т.к. с гарантийной или технической поддержкой это общего почти не имеет). Итак, вся пицца съедена, бессонные ночи закончены, и ваш проект перешел в промышленную эксплуатацию. Это значит что у заказчика нет (или он просто не сумел найти) критичных замечаний к системе, разработанной в ходе вашего проекта, и дает пользователям команду работать в ней, как в основной системе (или как в клоне боевой системы, такое тоже бывает).

Теперь, ваша задача продержаться определенный период (от 5 дней до 4 месяцев) и убедится что система работает правильно. Выбор сроков зависит от назначения системы — иногда хватает и недели работы в новой системе, иногда нужно проработать в ней месяц или два, а то еще и квартал закрыть. Планируйте на это время людей, что бы они могли оперативно разобраться с возникшими у заказчика вопросами, но учтите, что вопросов может быть (должно быть!) немного — поэтому логично запланировать так же внутренние проектные активности — архивирование документации, приведение в порядок вики и трекера задач, подготовку ретро и т.д.

Не забывайте, что все проблемы, возникшие в ходе ОПЭ, надо фиксировать в специальном журнале (а в идеале — в трекере задач) и ежедневно отслеживать их статус совместно с заказчиком.

По окончании этапа можете так же запланировать одну встречу команды с заказчиком, где вы торжественно объявите о закрытии проекта и продолжении сотрудничества и подведете итоги. Если только ваш заказчик не в Новом Уренгое.



В общем то это все, конечно, хотелось бы выложить куда то план проекта в формате mpp — для того, что бы уважаемые хабровчане могли не забивать все это руками, а посмотреть на примере каким образом связаны задачи.

Предложения по этому — я выслушаю в комментариях, и обязательно опубликую mpp в месте, где его можно будет легко и безопасно забрать.

Комментарии (8)


  1. HSerg
    24.01.2018 14:43

    А почему в план не попали фаза завершения проекта и процессы сворачивания инфраструктуры?


    1. PMVyatkin Автор
      24.01.2018 14:51

      Дело в том, что проектному офису лучше планировать работы по завершению проекта из своих внутренних костов.
      Т.е. есть регламент завершения проекта — закрытие проекта в Jira, ревью кода (и кастомизации при необходимости), архивирование виртуальных машин, дистрибутивов, сдача в архив проектных документов и т.д.
      Все это лучше сделать чек-боксом — на внутренней вики завести страницу чек-листа проекта, где ПМ проставит каждому пункту отметку «Выполнено».
      После выполненный чек-лист можно отдать руководству компании, как основание для закрытия проекта в компании и начисления проектных премий.
      Но в плане проекта — это указывать не нужно, во-первых потому что заказчику это видеть неинтересно (и ненужно), а планировать эти работы — слишком мелочно (ибо отнести документы в архив занимает 5 мин и т.д.).
      Как показывает практика, лучше всего просто иметь внутренний регламент закрытия проекта, косты на его исполнение накидывать к стоимости проекта % и при учете рабочего времени отображать как «Административная работа» (или «Процессы закрытия (фазы) проекта), а стимулировать к его исполнению — фактом обмена проектных премий на заполненный чек-лист.


  1. oleshko
    24.01.2018 16:44

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


    docs.google.com?


    1. PMVyatkin Автор
      24.01.2018 16:48

      Ага, но честно говоря не знаю как использовать файл проекта .mpp именно в гуглдоксе, если только таблицей, но в этом теряется смысл примера — таблицы не используют связи как MS Project и не сильно полезнее картинок (нельзя ничего поменять, т.к. связи между работами не будут проставлены).

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


  1. RationalBot
    24.01.2018 17:42

    Я правильно понимаю, что на прожект менеджера уходит примерно треть бюджета проекта?
    При том, что риски проекта 10% — т.е. он достаточно линейный и корректирующих действий особо не требуется?
    Фазы проектов не пересекаются (скажем, составление и ревью тест-планов/ПМИ может идти параллельно с разработкой при наличии спецификаций).
    Т.е. план не оптимален с точки зрения загрузки ресурсов и сроков поставки, а значит и бюджета проекта.


    1. PMVyatkin Автор
      24.01.2018 19:22

      Во-первых, спасибо за фибдек! :-)
      Во-вторых, про треть — нет, неверно. Это не бюджет проекта — это ФОТ (фонд оплаты труда).
      Бюджет формируется следующим образом — ФОТ (например 15-30% — и 30% это очень ФОТ на проектах, где (сомнительной надежности) Исполнитель делает (сомнительного качества) работу снимая офис в Запанском, на пиратском ПО и используя беглых рабов вместо сотрудников) + капитальные затраты исполнителя (аренда офиса, работа продажников, функциональных руководителей, оплата компов и ПО, резерв на риски, и прибыль компании, обучение сотрудников и т.д.). Так же есть Заказчик может платить еще НДС (возвращается либо можно использовать ООО на упрощенке), командированные расходы (обычно включаются отдельно от бюджета проекта), штрафы (например за простой команды из-за задержек в согласовании документации).
      У нас ПМ еще и за ведущего внедренца выступает, + он по сравнению с другими ресурсами дорогой и постоянно держит руку на пульсе. Отсюда и затраты в треть ФОТа. Если очень хочется сэкономить — надо менеджера нанимать дешевле, либо снимать с него обязанности — например отдельного администратора проекта взять на оформление задач в трекере, протоколов и т.д. (что неразумно на маленьком проекте), или внедренца взять опытнее (что разумно, но не всегда возможно, т.к. ПМ мог вырасти из внедренца), который сам сможет организовать пилот — вариантов много — но сильно сэкономить не выйдет, скорее потеряете — ибо ПМ одновременно 10 проектов вести не будет (или будет, но крайне неэффективно, путая заказчиков, ресурсы, трекеры, документы и т.д.), а будет вести 3-4 проекта, т.е. тратить 25-33% своего времени на один проект и съедать соответствующий ФОТ (пусть он за этот ФОТ лучше работу делает хорошо и много).
      Да и зачем? Хороший ПМ — это порядок на проекте, это отлаженные процессы по созданию документации, управлению заказчиком, развитию команды — и да, это дорого в краткосрочной перспективе, но дешево когда проекты сдаются и вы с них получаете прибыль, а не убытов (в случае плохого ПМа, который напутал сроки или не правильно оценил скоуп, или не увидел риски и т.д.).
      Разработка софта — это вообще всегда дорого.
      В-третьих — про тест-планы и спеки — описанная вами ситуация может быть, но может быть и разработка через тестирование например вообще, вариантов много — выбирайте тот, что вам нравится и используйте — но я все же советую обратить внимание на тот, что у меня (недаром проектные методологии разных компаний часто выделяют отдельно фазу тестирования).
      Тестирование в фазе разработки у меня конечно же есть — посмотрите внимательно задачу 81 и вы увидите что на 5 дней заложено 120 рабочих часов — при 8 часовом рабочем дне в ресурсах и отсутствии флага перегрузки ресурсов в левом столбце (MS Project подсвечивает, если ресурсы перегружены). Объяснение тут простое и оно сразу выплывает если скачать файл mpp и посмотреть ресурсы в нем — там есть тестировщик.
      По нашему плану — предполагается что на этой стадии он выполняет тестирование каждой задачи, отмеченной как resolved в трекере, но это не настоящее тестирование продукта, разрабатываемого в ходе проекта. Конечно, если у него нет других задач — он может приступать к разработке плана тестирования и тест-кейсов — но выйдет дороже, т.к. план придется переделывать, тест-кейсы переписывать. Гораздо выгоднее, что бы он это время поработал на другом проекте, а к нам вернулся уже в фазе тестирования, с полным планом и кейсами, разработанными частично на этапе разработки (ему просто надо сделать ревью списка задач в трекере + добавить все кейсы, которые он считает нужным для полного покрытия).


  1. RationalBot
    24.01.2018 20:23

    К сожалению, у меня нет MS Project на домашнем ноутбуке и нет желания его ставить только для того, чтобы посмотреть на этот проект.
    Поэтому сужу только по картинкам.
    Да, согласен, что вопрос был не о бюджете проекта, а ФОТ на разработку.
    Мое мнение, что выделенный прожект менеджер на команду такого размера — избыточен.
    Я бы сказал, что максимум он должен быть утилизирован на четверть (если у него ставка на уровне ведущего разработчика).

    Если предполагать, что во время «простоев» люди заняты на других проектах, то возникают «паразитные зависимости» между проектами и переключения контекста.
    По сути, нарушается ограничение Work in progress для команды.
    Там погрешность в 10% уже становится существенной (скажем, +10% на фазу разработки в одном проекте, -10% во втором, и фазы тестирования в них наложились; или на оборот — фазы разбежались и тестировщики простаивают).
    Синхронизовать несколько параллельных проектов, особенно если у каждого из них свой менеджер, гораздо более творческая задача, чем оптимизировать загрузку на одном так, чтобы сократить общее время проекта и снизить накладные расходы.
    Я не спорю, возможно кому-то этот темплейт проектного плана и принесет пользу (благо в самом начале четко описан контекст). Просто обращаю внимание на то, что я пытался бы оптимизировать.


    1. PMVyatkin Автор
      25.01.2018 07:24

      Вопрос про оптимизацию загрузки — абсолютно правильный, именно его я задал себе когда закончил свой первый план — что дальше?
      Здесь в помощь приходит MS Project Server (или Oracle Primavera, но я к сожалению ее не использовал) — он предоставляет все инструменты для управления ресурсами проектов внутри портфеля.
      Вкратце — после того, как вы закончили свой план — вы меняете ресурсы на реальных людей (поддерживается загрузка из эктив директори), и публикуете план на проджект сервере. Ваш руководитель программы/портфеля/ПМО видит загрузку людей на будущий период. Пока, она его устраивает, т.к. никто не работает более 8 часов, и люди не перегружены.
      Следом за вами, другой такой же ПМ публикует такой же план, но у него уже не получается сделать это так просто как у вас — Project говорит о том, что ресурсы заняты.
      Поэтому, он идет к ПМу №1 (т.е. к вам) и спрашивает вас — реально ли тебе в августе нужен Вася каждый день на 6 часов? Вы отвечаете что нет, это вы взяли с хорошим запасом, и можете спокойно снизить загрузку до 4 часов, после чего меняете свой план и переопубликовываете его. Ваш коллега делает то же самое, планируя Василия в августе — на 4 часа, конфликт исчерпан. Итого, если за год вы делаете 10-12 проектов (что в сумме очень примерно 50 млн рублей), каждый месяц вам придется 3-4 раза обсуждать загрузку ресурсов в среднесрочной перспективе.
      Конечно, конфликты будут возникать и в краткосрочной — плох тот план, который не меняется. Например, у вас есть разработчик Петя, который пишет основную часть кода, и по каким то причинам вы неправильно рассчитали его загрузку на текущую неделю, и что бы догнать на сл. неделе — вместо запланированных 4 часов, Пете у вас понадобится 6. В этом случае вам нужно убедится, что Петя не занят на других проектах — вы идете на проджект сервер, и видите что Петя свободен, и резервируете его.
      Но и тут вас поджидает сюрприз — нерадивый соседнего менеджер проекта Оля, поленилась зарезервировать Петю на следующую неделю в проджекте, а он нужен ей позарез сделать багофикс. На следующей неделе. Оля прибежит к вам с выпученными глазами, и будет требовать у вас Петю, которого вы конечно не отдадите, но проектному офису от этого пользы мало — ибо слив свой проект, Оля ударит по бюджету всех.
      Именно для этого у вашего руководителя ПМО со всеми ПМами запланирована часовая встреча — на каждую пятницу, где все ПМы балансируют ресурсы и решают кто нужен на следующую неделю. Иногда, случаются переработки, но если ПМО придерживается политики — 80% людей планировать на проекты, а 20 — на самообучение и резерв, и люди не перегорают, и планы сильно не двигаются.
      Как когда то сказал мой шеф, мы всегда можем планировать, но не всегда можем спланировать.

      Про расходы на ПМа — вопрос очень тонкий. Дело в том, что на вышеописанном проекте — рокетсайенса нет, и серьезный ведущий разработчик на таком проекте заскучает — он слишком типовой, без сложный интеграций и архитектуры.
      А вот с ПМством наоборот — у Заказчика есть выбор между подрядчиками, и выбирать он будет ориентируясь на ПМа — есть ли у того международные сертификаты, есть ли опыт работы и какие конкретно проекты за плечами, как он составил план и как описал работы, совпадает ли его видение с видением куратора проекта заказчика и т.д.
      + если менеджер проекта работает в компании недавно — это лишний риск для Заказчика — риск смены ПМа проекта (прощайте сроки, под которые куратор Заказчика коммитился перед своим руководством) — и хороший Заказчик такой риск на себя брать не будет (лучше возьмет интегратора с ПМом, который вырос из его команды и работает очень долго).
      Ну и конечно, расслабленному ПМу Заказчик быстро накидает новый требований, от которых не все умеют и могут отказатся, а команда расслабится и сроки и качество поедут.
      Поэтому хороший ПМ — это основа экономики проекта, это управление Заказчиком и командой, это грамотно сделанный пресейл и планирование, это полная ответственность за продукт, разрабатываемый в ходе проекта.
      Такой человек, да который плавает в ИТ как рыба в воде (особенно в узких областях) — на вес золота, но не всем компаниям он нужен — у многих и проектных офисов то нет.