Хм, ну я так понимаю это вопрос рациональности. У меня такая же ситуация с метро (на которое мой работодатель вообще повлиять не может по определению).
Хочу быстро доехать — еду на метро, хочу медленно — еду на машине. Хочу ехать на метро и с комфортом — встаю раньше и еду в пустых вагонах.
Так же и с маршруткой — хочешь доехать быстро и в час-пик — готовься потолкаться, если же хочешь ехать в комфорте — приезжай в офис пораньше.
Ланит я думаю (как и любой другой работодатель) может лишь такой же выбор предложить, обеспечив гибкий график работы.
Пускать же 10 маршруток в час пик и 1-2 в остальные часы — можно, и я так понимаю что это 10 машин и 10 водителей, 8 из которых будут простаивать или возить воздух ~70% времени.
Зачем же тратить корпоративные деньги на водителей, когда можно их потратить на зарплаты, офис, комфортные рабочие места, вкусняшки, корпоративные праздники, ДМС, и прочие ништяки? Я бы, например, не сильно порадовался, если бы мой годовой бонус пустили на маршрутки тех, кто любит ездить в часы пик (при гибком графике то!).
P.S. Плюс я вспоминаю что вроде в Ланите есть карпул — на портале можно оставить свои координаты, и брать попутчиков, если регулярно ездишь на машине.
Спасибо за статью, читается интересно. Ваш блог хороший — много разных тем, написано так, что интересно читать даже не профильные хабы.
Что было бы клёво сделать еще — напишите побольше про внутреннюю кухню — про офис, про командировки, про клиентов. Возможно, это не соберет рекордное число просмотров, но притянет больше подписчиков среди коллег (и желающих ими стать), которым будет интересно следить за жизнью внутри компании (и сравнивать ее со своей, или черпать лучшее).
Не вижу к сожалению курсов в Москве, а хотелось бы что бы были.
P.S. Отдельное спасибо за очень актуальные курсы в Самаре по бизнес-анализу — с удовольствием порекомендовал друзьям и коллегами.
1. Да, с планом проекта в классическом понимании (я под этим подразумеваю конечно же PMI)- все сложнее, ибо это составная сущность и в нем не только файл проджекта и это понятно.
Здесь речь идет именно о календарном плане проекта, который можно использовать для 2 вещей: 1 — ставить как календарный план-график в договор, 2 — использовать для резервирования ресурсов внутри компании (при определенных условиях). Определить цель проекта, собрать требования и превратить их в скоуп, анализировать риски — этого статья и не собиралась описывать, добро пожаловать в PMI PMBOK 6 (и его порождения) где все это описано подробно.
2. Навыки БА — согласен, небольшая терминологическая путаница. Имеется в виду скиллы, которым обладает любой БА по умолчанию (навыки устной речи тоже, например).
Практически все хорошие ПМы, с которыми я работал — были из технарей — разработчиков, DevOps, инженеров. И очень немногие — выходили из БА. И никого не встречал, кто бы стал ПМом просто после ВУЗа. И, кстати, не знаю никого с сертификатом PMI PMP, кто бы не имел за плечами внушительных технических позиций (хотя уверен, такие люди есть и немало).
По ролям — дано краткое описание, которое я встречал в компаниях, с которыми работал. В каждом случае — они разные (и об этом прямо написано в статье), и описывать подробно роли на проекте — дело неблагодарное, т.к. все равно каждый меняет их под себя в зависимости даже не от конкретной организации, а от конкретной команды.
3. Протокол — дело вообще добровольное, знаю кучу успешных проектов, на которых и протоколов то не было (спойлер: а ПМ просто умел договариваться с коллегами в почте). В любом случае, на всех проектах (кроме одного о коем ниже), которые я вел или вели мои коллеги, вполне хватало протоколов, где фиксировались обсуждаемые вопросы и результаты обсуждения, а так же поручения.
Про тот же один проект, где протоколы встреч велись очень подробно, и все было по ГОСТам (по я думаю понятным причинам) — компания, которая его вела, поклялась больше с такими проектами не связываться, т.к. весь проектный офис потом покрывал убытки от него на проектах с нормальными протоколами и без ГОСТов. Возможно, их процессы были просто заточены под создание софта, а не написание протоколов.
Про ТЗ — опять же дело добровольное, знаю кучу проектов, на которых ТЗ не было (опять же в статье даются названия документов, способных в той или иной мере заменить ТЗ) и других проектов где ТЗ согласовывалось аж до испытаний, ну а то что в PMBOK прямо сказано вносить изменения во всю документацию (очевидно, включая ТЗ) при наличии (согласованных) изменений — это первый звоночек.
Про ПМИ и тест-кейсы — отдельный разговор, можно и так и так :-) Знаю кучу примеров успешных проектов…
За фидбек про планирование и организацию деятельности — спасибо, на досуге посмотрю.
Про РП — в корне не согласен, но спорить думаю тут бессмысленно — с тем же успехом можем спорить о том, какой из цветов лучше — красный или синий.
Вопрос про оптимизацию загрузки — абсолютно правильный, именно его я задал себе когда закончил свой первый план — что дальше?
Здесь в помощь приходит MS Project Server (или Oracle Primavera, но я к сожалению ее не использовал) — он предоставляет все инструменты для управления ресурсами проектов внутри портфеля.
Вкратце — после того, как вы закончили свой план — вы меняете ресурсы на реальных людей (поддерживается загрузка из эктив директори), и публикуете план на проджект сервере. Ваш руководитель программы/портфеля/ПМО видит загрузку людей на будущий период. Пока, она его устраивает, т.к. никто не работает более 8 часов, и люди не перегружены.
Следом за вами, другой такой же ПМ публикует такой же план, но у него уже не получается сделать это так просто как у вас — Project говорит о том, что ресурсы заняты.
Поэтому, он идет к ПМу №1 (т.е. к вам) и спрашивает вас — реально ли тебе в августе нужен Вася каждый день на 6 часов? Вы отвечаете что нет, это вы взяли с хорошим запасом, и можете спокойно снизить загрузку до 4 часов, после чего меняете свой план и переопубликовываете его. Ваш коллега делает то же самое, планируя Василия в августе — на 4 часа, конфликт исчерпан. Итого, если за год вы делаете 10-12 проектов (что в сумме очень примерно 50 млн рублей), каждый месяц вам придется 3-4 раза обсуждать загрузку ресурсов в среднесрочной перспективе.
Конечно, конфликты будут возникать и в краткосрочной — плох тот план, который не меняется. Например, у вас есть разработчик Петя, который пишет основную часть кода, и по каким то причинам вы неправильно рассчитали его загрузку на текущую неделю, и что бы догнать на сл. неделе — вместо запланированных 4 часов, Пете у вас понадобится 6. В этом случае вам нужно убедится, что Петя не занят на других проектах — вы идете на проджект сервер, и видите что Петя свободен, и резервируете его.
Но и тут вас поджидает сюрприз — нерадивый соседнего менеджер проекта Оля, поленилась зарезервировать Петю на следующую неделю в проджекте, а он нужен ей позарез сделать багофикс. На следующей неделе. Оля прибежит к вам с выпученными глазами, и будет требовать у вас Петю, которого вы конечно не отдадите, но проектному офису от этого пользы мало — ибо слив свой проект, Оля ударит по бюджету всех.
Именно для этого у вашего руководителя ПМО со всеми ПМами запланирована часовая встреча — на каждую пятницу, где все ПМы балансируют ресурсы и решают кто нужен на следующую неделю. Иногда, случаются переработки, но если ПМО придерживается политики — 80% людей планировать на проекты, а 20 — на самообучение и резерв, и люди не перегорают, и планы сильно не двигаются.
Как когда то сказал мой шеф, мы всегда можем планировать, но не всегда можем спланировать.
Про расходы на ПМа — вопрос очень тонкий. Дело в том, что на вышеописанном проекте — рокетсайенса нет, и серьезный ведущий разработчик на таком проекте заскучает — он слишком типовой, без сложный интеграций и архитектуры.
А вот с ПМством наоборот — у Заказчика есть выбор между подрядчиками, и выбирать он будет ориентируясь на ПМа — есть ли у того международные сертификаты, есть ли опыт работы и какие конкретно проекты за плечами, как он составил план и как описал работы, совпадает ли его видение с видением куратора проекта заказчика и т.д.
+ если менеджер проекта работает в компании недавно — это лишний риск для Заказчика — риск смены ПМа проекта (прощайте сроки, под которые куратор Заказчика коммитился перед своим руководством) — и хороший Заказчик такой риск на себя брать не будет (лучше возьмет интегратора с ПМом, который вырос из его команды и работает очень долго).
Ну и конечно, расслабленному ПМу Заказчик быстро накидает новый требований, от которых не все умеют и могут отказатся, а команда расслабится и сроки и качество поедут.
Поэтому хороший ПМ — это основа экономики проекта, это управление Заказчиком и командой, это грамотно сделанный пресейл и планирование, это полная ответственность за продукт, разрабатываемый в ходе проекта.
Такой человек, да который плавает в ИТ как рыба в воде (особенно в узких областях) — на вес золота, но не всем компаниям он нужен — у многих и проектных офисов то нет.
Во-первых, спасибо за фибдек! :-)
Во-вторых, про треть — нет, неверно. Это не бюджет проекта — это ФОТ (фонд оплаты труда).
Бюджет формируется следующим образом — ФОТ (например 15-30% — и 30% это очень ФОТ на проектах, где (сомнительной надежности) Исполнитель делает (сомнительного качества) работу снимая офис в Запанском, на пиратском ПО и используя беглых рабов вместо сотрудников) + капитальные затраты исполнителя (аренда офиса, работа продажников, функциональных руководителей, оплата компов и ПО, резерв на риски, и прибыль компании, обучение сотрудников и т.д.). Так же есть Заказчик может платить еще НДС (возвращается либо можно использовать ООО на упрощенке), командированные расходы (обычно включаются отдельно от бюджета проекта), штрафы (например за простой команды из-за задержек в согласовании документации).
У нас ПМ еще и за ведущего внедренца выступает, + он по сравнению с другими ресурсами дорогой и постоянно держит руку на пульсе. Отсюда и затраты в треть ФОТа. Если очень хочется сэкономить — надо менеджера нанимать дешевле, либо снимать с него обязанности — например отдельного администратора проекта взять на оформление задач в трекере, протоколов и т.д. (что неразумно на маленьком проекте), или внедренца взять опытнее (что разумно, но не всегда возможно, т.к. ПМ мог вырасти из внедренца), который сам сможет организовать пилот — вариантов много — но сильно сэкономить не выйдет, скорее потеряете — ибо ПМ одновременно 10 проектов вести не будет (или будет, но крайне неэффективно, путая заказчиков, ресурсы, трекеры, документы и т.д.), а будет вести 3-4 проекта, т.е. тратить 25-33% своего времени на один проект и съедать соответствующий ФОТ (пусть он за этот ФОТ лучше работу делает хорошо и много).
Да и зачем? Хороший ПМ — это порядок на проекте, это отлаженные процессы по созданию документации, управлению заказчиком, развитию команды — и да, это дорого в краткосрочной перспективе, но дешево когда проекты сдаются и вы с них получаете прибыль, а не убытов (в случае плохого ПМа, который напутал сроки или не правильно оценил скоуп, или не увидел риски и т.д.).
Разработка софта — это вообще всегда дорого.
В-третьих — про тест-планы и спеки — описанная вами ситуация может быть, но может быть и разработка через тестирование например вообще, вариантов много — выбирайте тот, что вам нравится и используйте — но я все же советую обратить внимание на тот, что у меня (недаром проектные методологии разных компаний часто выделяют отдельно фазу тестирования).
Тестирование в фазе разработки у меня конечно же есть — посмотрите внимательно задачу 81 и вы увидите что на 5 дней заложено 120 рабочих часов — при 8 часовом рабочем дне в ресурсах и отсутствии флага перегрузки ресурсов в левом столбце (MS Project подсвечивает, если ресурсы перегружены). Объяснение тут простое и оно сразу выплывает если скачать файл mpp и посмотреть ресурсы в нем — там есть тестировщик.
По нашему плану — предполагается что на этой стадии он выполняет тестирование каждой задачи, отмеченной как resolved в трекере, но это не настоящее тестирование продукта, разрабатываемого в ходе проекта. Конечно, если у него нет других задач — он может приступать к разработке плана тестирования и тест-кейсов — но выйдет дороже, т.к. план придется переделывать, тест-кейсы переписывать. Гораздо выгоднее, что бы он это время поработал на другом проекте, а к нам вернулся уже в фазе тестирования, с полным планом и кейсами, разработанными частично на этапе разработки (ему просто надо сделать ревью списка задач в трекере + добавить все кейсы, которые он считает нужным для полного покрытия).
Ага, но честно говоря не знаю как использовать файл проекта .mpp именно в гуглдоксе, если только таблицей, но в этом теряется смысл примера — таблицы не используют связи как MS Project и не сильно полезнее картинок (нельзя ничего поменять, т.к. связи между работами не будут проставлены).
Дело в том, что проектному офису лучше планировать работы по завершению проекта из своих внутренних костов.
Т.е. есть регламент завершения проекта — закрытие проекта в Jira, ревью кода (и кастомизации при необходимости), архивирование виртуальных машин, дистрибутивов, сдача в архив проектных документов и т.д.
Все это лучше сделать чек-боксом — на внутренней вики завести страницу чек-листа проекта, где ПМ проставит каждому пункту отметку «Выполнено».
После выполненный чек-лист можно отдать руководству компании, как основание для закрытия проекта в компании и начисления проектных премий.
Но в плане проекта — это указывать не нужно, во-первых потому что заказчику это видеть неинтересно (и ненужно), а планировать эти работы — слишком мелочно (ибо отнести документы в архив занимает 5 мин и т.д.).
Как показывает практика, лучше всего просто иметь внутренний регламент закрытия проекта, косты на его исполнение накидывать к стоимости проекта % и при учете рабочего времени отображать как «Административная работа» (или «Процессы закрытия (фазы) проекта), а стимулировать к его исполнению — фактом обмена проектных премий на заполненный чек-лист.
Хочу быстро доехать — еду на метро, хочу медленно — еду на машине. Хочу ехать на метро и с комфортом — встаю раньше и еду в пустых вагонах.
Так же и с маршруткой — хочешь доехать быстро и в час-пик — готовься потолкаться, если же хочешь ехать в комфорте — приезжай в офис пораньше.
Ланит я думаю (как и любой другой работодатель) может лишь такой же выбор предложить, обеспечив гибкий график работы.
Пускать же 10 маршруток в час пик и 1-2 в остальные часы — можно, и я так понимаю что это 10 машин и 10 водителей, 8 из которых будут простаивать или возить воздух ~70% времени.
Зачем же тратить корпоративные деньги на водителей, когда можно их потратить на зарплаты, офис, комфортные рабочие места, вкусняшки, корпоративные праздники, ДМС, и прочие ништяки? Я бы, например, не сильно порадовался, если бы мой годовой бонус пустили на маршрутки тех, кто любит ездить в часы пик (при гибком графике то!).
P.S. Плюс я вспоминаю что вроде в Ланите есть карпул — на портале можно оставить свои координаты, и брать попутчиков, если регулярно ездишь на машине.
Что было бы клёво сделать еще — напишите побольше про внутреннюю кухню — про офис, про командировки, про клиентов. Возможно, это не соберет рекордное число просмотров, но притянет больше подписчиков среди коллег (и желающих ими стать), которым будет интересно следить за жизнью внутри компании (и сравнивать ее со своей, или черпать лучшее).
P.S. Отдельное спасибо за очень актуальные курсы в Самаре по бизнес-анализу — с удовольствием порекомендовал друзьям и коллегами.
1. Да, с планом проекта в классическом понимании (я под этим подразумеваю конечно же PMI)- все сложнее, ибо это составная сущность и в нем не только файл проджекта и это понятно.
Здесь речь идет именно о календарном плане проекта, который можно использовать для 2 вещей: 1 — ставить как календарный план-график в договор, 2 — использовать для резервирования ресурсов внутри компании (при определенных условиях). Определить цель проекта, собрать требования и превратить их в скоуп, анализировать риски — этого статья и не собиралась описывать, добро пожаловать в PMI PMBOK 6 (и его порождения) где все это описано подробно.
2. Навыки БА — согласен, небольшая терминологическая путаница. Имеется в виду скиллы, которым обладает любой БА по умолчанию (навыки устной речи тоже, например).
Практически все хорошие ПМы, с которыми я работал — были из технарей — разработчиков, DevOps, инженеров. И очень немногие — выходили из БА. И никого не встречал, кто бы стал ПМом просто после ВУЗа. И, кстати, не знаю никого с сертификатом PMI PMP, кто бы не имел за плечами внушительных технических позиций (хотя уверен, такие люди есть и немало).
По ролям — дано краткое описание, которое я встречал в компаниях, с которыми работал. В каждом случае — они разные (и об этом прямо написано в статье), и описывать подробно роли на проекте — дело неблагодарное, т.к. все равно каждый меняет их под себя в зависимости даже не от конкретной организации, а от конкретной команды.
3. Протокол — дело вообще добровольное, знаю кучу успешных проектов, на которых и протоколов то не было (спойлер: а ПМ просто умел договариваться с коллегами в почте). В любом случае, на всех проектах (кроме одного о коем ниже), которые я вел или вели мои коллеги, вполне хватало протоколов, где фиксировались обсуждаемые вопросы и результаты обсуждения, а так же поручения.
Про тот же один проект, где протоколы встреч велись очень подробно, и все было по ГОСТам (по я думаю понятным причинам) — компания, которая его вела, поклялась больше с такими проектами не связываться, т.к. весь проектный офис потом покрывал убытки от него на проектах с нормальными протоколами и без ГОСТов. Возможно, их процессы были просто заточены под создание софта, а не написание протоколов.
Про ТЗ — опять же дело добровольное, знаю кучу проектов, на которых ТЗ не было (опять же в статье даются названия документов, способных в той или иной мере заменить ТЗ) и других проектов где ТЗ согласовывалось аж до испытаний, ну а то что в PMBOK прямо сказано вносить изменения во всю документацию (очевидно, включая ТЗ) при наличии (согласованных) изменений — это первый звоночек.
Про ПМИ и тест-кейсы — отдельный разговор, можно и так и так :-) Знаю кучу примеров успешных проектов…
За фидбек про планирование и организацию деятельности — спасибо, на досуге посмотрю.
Про РП — в корне не согласен, но спорить думаю тут бессмысленно — с тем же успехом можем спорить о том, какой из цветов лучше — красный или синий.
Здесь в помощь приходит MS Project Server (или Oracle Primavera, но я к сожалению ее не использовал) — он предоставляет все инструменты для управления ресурсами проектов внутри портфеля.
Вкратце — после того, как вы закончили свой план — вы меняете ресурсы на реальных людей (поддерживается загрузка из эктив директори), и публикуете план на проджект сервере. Ваш руководитель программы/портфеля/ПМО видит загрузку людей на будущий период. Пока, она его устраивает, т.к. никто не работает более 8 часов, и люди не перегружены.
Следом за вами, другой такой же ПМ публикует такой же план, но у него уже не получается сделать это так просто как у вас — Project говорит о том, что ресурсы заняты.
Поэтому, он идет к ПМу №1 (т.е. к вам) и спрашивает вас — реально ли тебе в августе нужен Вася каждый день на 6 часов? Вы отвечаете что нет, это вы взяли с хорошим запасом, и можете спокойно снизить загрузку до 4 часов, после чего меняете свой план и переопубликовываете его. Ваш коллега делает то же самое, планируя Василия в августе — на 4 часа, конфликт исчерпан. Итого, если за год вы делаете 10-12 проектов (что в сумме очень примерно 50 млн рублей), каждый месяц вам придется 3-4 раза обсуждать загрузку ресурсов в среднесрочной перспективе.
Конечно, конфликты будут возникать и в краткосрочной — плох тот план, который не меняется. Например, у вас есть разработчик Петя, который пишет основную часть кода, и по каким то причинам вы неправильно рассчитали его загрузку на текущую неделю, и что бы догнать на сл. неделе — вместо запланированных 4 часов, Пете у вас понадобится 6. В этом случае вам нужно убедится, что Петя не занят на других проектах — вы идете на проджект сервер, и видите что Петя свободен, и резервируете его.
Но и тут вас поджидает сюрприз — нерадивый соседнего менеджер проекта Оля, поленилась зарезервировать Петю на следующую неделю в проджекте, а он нужен ей позарез сделать багофикс. На следующей неделе. Оля прибежит к вам с выпученными глазами, и будет требовать у вас Петю, которого вы конечно не отдадите, но проектному офису от этого пользы мало — ибо слив свой проект, Оля ударит по бюджету всех.
Именно для этого у вашего руководителя ПМО со всеми ПМами запланирована часовая встреча — на каждую пятницу, где все ПМы балансируют ресурсы и решают кто нужен на следующую неделю. Иногда, случаются переработки, но если ПМО придерживается политики — 80% людей планировать на проекты, а 20 — на самообучение и резерв, и люди не перегорают, и планы сильно не двигаются.
Как когда то сказал мой шеф, мы всегда можем планировать, но не всегда можем спланировать.
Про расходы на ПМа — вопрос очень тонкий. Дело в том, что на вышеописанном проекте — рокетсайенса нет, и серьезный ведущий разработчик на таком проекте заскучает — он слишком типовой, без сложный интеграций и архитектуры.
А вот с ПМством наоборот — у Заказчика есть выбор между подрядчиками, и выбирать он будет ориентируясь на ПМа — есть ли у того международные сертификаты, есть ли опыт работы и какие конкретно проекты за плечами, как он составил план и как описал работы, совпадает ли его видение с видением куратора проекта заказчика и т.д.
+ если менеджер проекта работает в компании недавно — это лишний риск для Заказчика — риск смены ПМа проекта (прощайте сроки, под которые куратор Заказчика коммитился перед своим руководством) — и хороший Заказчик такой риск на себя брать не будет (лучше возьмет интегратора с ПМом, который вырос из его команды и работает очень долго).
Ну и конечно, расслабленному ПМу Заказчик быстро накидает новый требований, от которых не все умеют и могут отказатся, а команда расслабится и сроки и качество поедут.
Поэтому хороший ПМ — это основа экономики проекта, это управление Заказчиком и командой, это грамотно сделанный пресейл и планирование, это полная ответственность за продукт, разрабатываемый в ходе проекта.
Такой человек, да который плавает в ИТ как рыба в воде (особенно в узких областях) — на вес золота, но не всем компаниям он нужен — у многих и проектных офисов то нет.
Во-вторых, про треть — нет, неверно. Это не бюджет проекта — это ФОТ (фонд оплаты труда).
Бюджет формируется следующим образом — ФОТ (например 15-30% — и 30% это очень ФОТ на проектах, где (сомнительной надежности) Исполнитель делает (сомнительного качества) работу снимая офис в Запанском, на пиратском ПО и используя беглых рабов вместо сотрудников) + капитальные затраты исполнителя (аренда офиса, работа продажников, функциональных руководителей, оплата компов и ПО, резерв на риски, и прибыль компании, обучение сотрудников и т.д.). Так же есть Заказчик может платить еще НДС (возвращается либо можно использовать ООО на упрощенке), командированные расходы (обычно включаются отдельно от бюджета проекта), штрафы (например за простой команды из-за задержек в согласовании документации).
У нас ПМ еще и за ведущего внедренца выступает, + он по сравнению с другими ресурсами дорогой и постоянно держит руку на пульсе. Отсюда и затраты в треть ФОТа. Если очень хочется сэкономить — надо менеджера нанимать дешевле, либо снимать с него обязанности — например отдельного администратора проекта взять на оформление задач в трекере, протоколов и т.д. (что неразумно на маленьком проекте), или внедренца взять опытнее (что разумно, но не всегда возможно, т.к. ПМ мог вырасти из внедренца), который сам сможет организовать пилот — вариантов много — но сильно сэкономить не выйдет, скорее потеряете — ибо ПМ одновременно 10 проектов вести не будет (или будет, но крайне неэффективно, путая заказчиков, ресурсы, трекеры, документы и т.д.), а будет вести 3-4 проекта, т.е. тратить 25-33% своего времени на один проект и съедать соответствующий ФОТ (пусть он за этот ФОТ лучше работу делает хорошо и много).
Да и зачем? Хороший ПМ — это порядок на проекте, это отлаженные процессы по созданию документации, управлению заказчиком, развитию команды — и да, это дорого в краткосрочной перспективе, но дешево когда проекты сдаются и вы с них получаете прибыль, а не убытов (в случае плохого ПМа, который напутал сроки или не правильно оценил скоуп, или не увидел риски и т.д.).
Разработка софта — это вообще всегда дорого.
В-третьих — про тест-планы и спеки — описанная вами ситуация может быть, но может быть и разработка через тестирование например вообще, вариантов много — выбирайте тот, что вам нравится и используйте — но я все же советую обратить внимание на тот, что у меня (недаром проектные методологии разных компаний часто выделяют отдельно фазу тестирования).
Тестирование в фазе разработки у меня конечно же есть — посмотрите внимательно задачу 81 и вы увидите что на 5 дней заложено 120 рабочих часов — при 8 часовом рабочем дне в ресурсах и отсутствии флага перегрузки ресурсов в левом столбце (MS Project подсвечивает, если ресурсы перегружены). Объяснение тут простое и оно сразу выплывает если скачать файл mpp и посмотреть ресурсы в нем — там есть тестировщик.
По нашему плану — предполагается что на этой стадии он выполняет тестирование каждой задачи, отмеченной как resolved в трекере, но это не настоящее тестирование продукта, разрабатываемого в ходе проекта. Конечно, если у него нет других задач — он может приступать к разработке плана тестирования и тест-кейсов — но выйдет дороже, т.к. план придется переделывать, тест-кейсы переписывать. Гораздо выгоднее, что бы он это время поработал на другом проекте, а к нам вернулся уже в фазе тестирования, с полным планом и кейсами, разработанными частично на этапе разработки (ему просто надо сделать ревью списка задач в трекере + добавить все кейсы, которые он считает нужным для полного покрытия).
Пока, выложил на гуглдиск — скачать бесплатно и без регистрации.
Т.е. есть регламент завершения проекта — закрытие проекта в Jira, ревью кода (и кастомизации при необходимости), архивирование виртуальных машин, дистрибутивов, сдача в архив проектных документов и т.д.
Все это лучше сделать чек-боксом — на внутренней вики завести страницу чек-листа проекта, где ПМ проставит каждому пункту отметку «Выполнено».
После выполненный чек-лист можно отдать руководству компании, как основание для закрытия проекта в компании и начисления проектных премий.
Но в плане проекта — это указывать не нужно, во-первых потому что заказчику это видеть неинтересно (и ненужно), а планировать эти работы — слишком мелочно (ибо отнести документы в архив занимает 5 мин и т.д.).
Как показывает практика, лучше всего просто иметь внутренний регламент закрытия проекта, косты на его исполнение накидывать к стоимости проекта % и при учете рабочего времени отображать как «Административная работа» (или «Процессы закрытия (фазы) проекта), а стимулировать к его исполнению — фактом обмена проектных премий на заполненный чек-лист.