Добрый день.
Я работаю в проектной организации и мне требуется описать процесс планирования разработки проектной документации. Исходные данные: сотрудники организации в основном удаленные, постоянный сотрудник только менеджер проекта. Структура подчинения при разработке проекта следующая: менеджер проекта (основные обязанности планирование проекта, контроль сроков, постановка задач по контракту) -> ГИП (обязанности: согласование проектных решений с заинтересованными лицами, согласование между проектных решений разделами) -> Руководители групп (разработка проектных решений руками проектировщиков и их согласование между собой) -> Проектировщик (непосредственный исполнитель). Общая последовательность событий: договор-> получение исходных данных, согласование проектных решений с 3-ими заинтересованными лицами, согласование с заказчиком-> передача документации -> подписание актов. В принципе процесс планирования идентичен тому чем занимаются программисты, осложняется это тем, что: - всеми исходными данными не обладает никто, так же никто до конца не знает у кого они. - цикл: получения исходных данных, согласование с 3-ми заинтересованными лицами, согласование с заказчиком - может врящаться очень и очень много раз в разных вариациях. - исходные данные невозможно получить все на начальном этапе, необходимость части исходных данных определяется в ходе разработки. В результате таких сложностей на любом этапе разработки можно откатиться чуть ли не в начало работы. При правильной последовательности действий: - срыв сроков не несет никакой угрозы для компании. - дополнительные затраты компании при затягивании сроков составляют не более 10% от стоимости работ. Вот я и хотел поинтересоваться может есть у кого опыт планирования подобных работ и есть чем поделиться. Буду рад любому комментарию.
На: Планирование проекта разработки проектной документации
Роман, добрый день!Не знаю, в какой сфере у Вас ведётся деятельность, но безотносительно отрасли я бы подходил так. Документация - это "фотография", отражение выполненных проектных решений, т.е. саму разработку кто-то должен делать. В идеале, ГИП должен выполнять и роль главного конструктора, т.е. иметь в своей голове основные технические детали проекта, начиная с технических требований и ограничений, выявленных в процессе обследования. Желательно, кстати, выносить его (хотя бы часть) на "пресейл", т.е., если речь не о типовой разработке, то делать предварительное обследование нужно до заключения договора - и только тогда можно будет более/менее точно определиться с объёмом и составом работ, требуемыми ресурсами, последовательностью задач, вехами, сроками, трудоёмкостью и т.п. - в общем, по PMBoK). Достаточно универсальным можно считать подход, описанный в ГОСТ 34.601. Хотя этот стандарт и относится к ИТ, тем не менее, принципиально состав любого проекта по разработке чего-либо будет сводиться к этому набору работ. Что важно. Очень хорошо, что у Вас выделены роли МП и ГИП. В этой схеме "просится", чтобы именно ГИП выполнял роль не только координатора разрозненных разработок, но и роль главного конструктора, как я уже упомянул выше. Далее, есть смысл определить основные задачи (не работы, а именно задачи, каждая из которых заканчивается измеримым результатом), вехи, и после завершения каждой задачи заложить совещания (даже дистанционные, с использованием электронной почты, телеконференций и т.п.). При разработке я закладывал обычно 3 итерации на те этапы, где может возникнуть какая-либо вариативность, предполагая, что за три итерации все вопросы гарантированно будут закрыты. Как раз поэтапная итеративность позволит Вам избежать ситуаций "откатитьса в начало работы". Разработку (и проекта, и документации) рекомендую разбивать на очереди, группируя задачи не столько по времени, объединяя те, которые можно выполнить раньше по доступности ресурсов, сколько по влиянию на конечный результат. Например, нет смысла делать документ в финальном виде, если он с высокой вероятностью будет переделан по внутренним причинам - лучше разрабатывать их по частям, и то только после выполнения разработки той части проекта, которую он (документ) отражает. Опять же, чем хорош подход в ГОСТ 34.601 - он предполагает "водопадную" методологию, т.е. переход к следующему этапу происходит только тогда, когда готов и ожидаемо неизменен (в рамках поставленных требований и ограничений проекта/договора) результат этапа. Как со строительством дома: изыскания - проект - котлован - фундамент - стены+перекрытия - крыша - отделка. Вряд ли кто в здравом уме и ясной памяти попытается клеить обои на непостроенные над незалитым фундаментом стены :) Ещё. Не брезгуйте концептом и эскизом и их согласованием с заказчиком. Лучше согласовать принятое техническое решение (убедившись, что реализуемо) с заказчиком, т.е. возврат за точку невозврата будет уже на совести заказчика (за его дополнительные деньги на ваше дополнительное время). Кстати, эти согласования желательно закрепить во "внешнем" плане работ (календарном плане к договору). Очень полезно не брезговать техническим заданием. Т.е. предварительно "тактико-техническое задание" (функциональное задание, и т.п.) - это хорошо и полезно, но ещё полезней выделить этап обследования и по итогам его подготовить большое и подробное ТЗ, и согласовать его с заказчиком. Тут, конечно, есть ловушка. Не зная деталей, сложно определиться с трудоёмкостью/сроками и стоимостью (особенно, если помимо работ в составе проекта выполняется поставка продукции сторонних поставщиков). Но бОльшую часть ключевых требований можно и нужно вынести на пресейл. Эти затраты всё равно войдут в контрактную цену, так что не потеряете - зато выиграете на более точном расчёте. Если погрешность будет укладываться в 15-20% - значит, процесс правильный (ну и накиньте эти 20% для стаховки, уложитесь компактнее - вот и бонус :)). Да, ещё момент. Определитесь со стандартами, по которым работаете. Если по Вашей отрасли есть формальные стандарты на оформление документации, укажите это в ТЗ (можно и в договоре), и строго им следуйте. Если нет - придумайте свои, которые бы устанавливали состав документации, структуру и содержание; в этом случае (для своих стандартов) неплохо бы с "болванками" познакомить заказчика заранее, и уж естественно - довести шаблоны до всех участников проекта. Ответственный - ГИП. Вот как-то так навскидку. Будут вопросы - пишите, рад буду ответить. Удачи!
RE: На: Планирование проекта разработки проектной документации
Спасибо большое за подробный ответ.Почерпнул для себя новое, и хотелось бы по подробнее некоторые моменты оговорить: - почему закладываете именно 3 итерации при вариативности?Из личного опыта, опыта других людей или еще откуда? - каким образом определить "водопады", когда этап это водопад а не просто промежуточное событие. Может он должен удовлетворять какому то значению вероятности? К примеру, не раз наблюдал ситуацию когда после отделочных работ начинали двигать перегородки; было такое что выполняли проект после строительства, а изыскания после выполнения проекта и передачи на экспертизу.
RE: RE: На: Планирование проекта разработки проектной документации
Три варианта - да, это личный опыт плюс проанализированный чужой опыт, но изначально (смутные воспоминания из студенческих времён, сейчас уже не скажу точно, откуда - кажется, в рамках предмета "организация производства" что-то такое встречалось) были даже какие-то математические выкладки из области теории вероятности и статистики. Можно "погуглить в яндексе" - наверняка найдётся. По поводу этапности. Позволю себе цитату из упомянутого мной ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания":
Как видите, разработка Технического задания идёт не ДО проекта, а лишь на третьей стадии. Часто по разным причинам (по каким - тема отдельная) от этого отходят, что приводит к проблемам. Главная причина проблем - неопределённость требований (условий, ограничений) к конечному результату проекта, из-за чего сложно (а порой и невозможно) оценить состав задач, объём работ, их длительность, трудоёмкость, требуемые ресурсы, стоимость и т.д.
Как выглядит водопад - это не один большой "плюх", а каскад, ступеньки. В пределах "ступеньки" - те самые итерации. Как только подошёл к краю ступеньки и шагнул - всё, ушёл на следующий этап. По каждому этапу может быть определена своя "точка невозврата", после которой нужно двигаться строго вперёд, но нельзя вернуться "малой кровью": возврат должен означать возврат на исходную позицию. А уж чей "косяк" тому виной - тот и платит; если это техническая/технологическая ошибка исполнителя, то платит он, если новая внезапная "хотелка" заказчика - то заказчик. При этом, в большинстве случаев, управленческий "косяк" исполнителя тоже оплачивается исполнителем. (грешат этим иногда МП и продавцы, стремясь угодить клиенту, сэкономить или просто по незнанию - тут без ГИП их к телу заказчика допускать опасно, чтобы на нереализуемые вообще или в рамках бюджета/сроков проекта "фишки" не подписались). Похоже всё это в итоге на водопад - коли уж вода прошла порог и падает вниз, уже не остановишь, и с нижнего уровня наверх просто так не вернуться (даже график где-то такой есть, описывающий суть подхода) - только насосом за счёт того, кто эту воду хочет поднять :) Или как спуск с горы на горных лыжах. Или американские горки. В общем, аналогов много. Так вот, этой точкой невозврата по каждому крупному этапу должен быть некий результат, являющийся основой для дальнейших работ (следующего этапа). Стены - на фундамент. Крышу - на стены. И т.д. Вот Вы привели пример, что "сдвигали перегородки". Это и есть пример плохой проработки - потому что изначально не были собраны (и не уточнены в процессе разработки, но до монтажа) все требования (включая требования/пожелания потенциальных пользователей/потребителей продукта - чтобы перегородка изначально была поставлена там, где нужно заказчику или будущему пользователю), либо в процессе выполнения проекта они поменялись. Ну, что касается изменения требований/пожеланий в процессе выполнения проекта, это уже немного другая тема. В идеале такого быть не должно: для этого и проводятся обследования и согласования с подписанием формальных промежуточных документов - в т.ч. и для того, чтобы заказчик понимал, что изменения согласованных требований повлекут как минимум дополнительные затраты времени/денег/ресурсов, а как максимум - окажутся невозможными. Конечно, могут поменяться внешние условия (законодательство, нормативы, обстановка, климат, ... и т.д.), и на них имеет смысл закладываться в виде рисков и подстраховываться в тексте договора. Конечно, не всегда сразу можно предугадать/предусмотреть/формализовать всё. Но тут должен быть разумный предел. Во-первых, некое дробление на этапы с заранее заложенным в план уточнением деталей. Во-вторых, можно (и нужно) оставить некий запас свободы (погрешность) на непредвиденные обстоятельства. Обычно я закладываю 15-20% трудоёмкости/сроков/цены. Ну и в-третьих, как учат нас классики технического писательства, "если в ТЗ должно быть приведено требование, но оно не определено на момент написания ТЗ или не предъявляется вообще - так и надо написать: будет уточнено на этапе ... или не предъявляется". А если грамотно и подробно составлена контрактная часть (договор, ТЗ, календарный план) - не стесняйтесь отбиваться от заказчика. "А вот нам бы еще хотелось, чтобы вы нам вот тут вот так вот сделали" - не надо сразу исполнять. Если видно, что почти бескровно (в пределах тех 15-20%, о которых я говорил) можно, то сделайте, конечно, для налаживания добрых отношений с заказчиком (пригодится при приёмке или на будущих проектах ;)), но зафиксируйте письменно изменение. Если же не укладываетесь в заложенный рисковый запас - отказывайтесь, и если клиент настаивает, делайте новый план (обязательно проверив реализуемость и влияние нового требования на остальную часть работы, прежде всего - уже выполненную).
Ну вот, опять "многобукафф".
Планирование
Борис, Спасибо большое. |