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