Управление проектами в разных его вариантах описано в большом количестве литературы, и все авторы имеют свой оригинальный взгляд на этот процесс. Прочитав не один талмуд и ведя ни один проект хочу представить и свой взгляд на этот процесс, в части проектирования проекта что, на мой взгляд, мало описано (все увлекаются описанием непосредственно процесса, а он сам и его качество не в последнюю очередь зависит от того как все было спроектировано).
Все управление можно представить как и стек протокола TCP/IP, разложив его про уровням взаимодействия вовлеченных в процесс субъектов и объектов.
Так можно выделить
К идейному относится все то, что является самой сутью проекта (чего хотим добиться и какие у него свойства). Трудно структурировано представить этот уровень, но это, в первую очередь, общение на этапе «Слушай тут есть классная идея…» или «Вот, нам тут надо…». Тут самое главное опыт самого РМ, который позволит разграничить необходимые и маловразумительные сомнительные желания (они же в дальнейшем характеристики) проекта. Понять и объяснить реальность воплощения тех или иных идей, не исключено что уже тут станет ясно, что по чем. Общение, общение и еще раз общение, со всеми смежными с проектом и могущими в нем участвовать спецами и дилетантами. Дилетанты опишут суть в двух словах – больше они и сами не знают, а суть им так или иначе рассказали. Спецы – посвятят в тонкости и нюансы.
Само собой РМ должен быть специализирован на какой-то области, уверяю вас — РМ интернет стартапов будет жалко смотреться на производстве ЖБИ.
На коммуникативном уровне решаются вопросы как и каким образом весь этот бардак предыдущего уровня, да и последующих, будет управляться в смысле людей и их взаимодействий. Тут есть обязательные, на мой взгляд, для участия субъекты. А именно: ответственный субъект со стороны заказчика, ответственный субъект со стороны исполнителя и идеолог проекта. Как и в какой степени три этих субъекта будут трансформироваться в конкретные личности – дело ваше, но по возможности старайтесь избегать совмещения ответственного субъекта со стороны исполнителя и идеолога проекта в одном лице – иначе в случае завала работ идеологом (ибо люди либо творческие, либо ОЧЕНЬ занятые) у вас не будет возможности влиять на него через ответственного со стороны заказчика.
Из ранней практики:
Проект с постоянно меняющимся ТЗ. В проекте были сомнительные в плане стороны исполнителя задачи по работе с исходными данными. При этом необходимость решения данных задач осознавали все участники проекта. Будем думать, что участие заказчика в выполнении задач проекта объяснять нет необходимости. Так вот исполнитель был и не против взять на себя решение этих задач, за отдельную плату, соответственно. Заказчик долго принимал решение по этому поводу, меняя решение, попутно пытаясь сам что-то делать. В итоге без исходных формализованных данных дальнейшая работа была невозможна, а воз и ныне там. Проект заглох сам собой…
Старайтесь сразу определить степень бюрократичности, а именно какие решения и как будут фиксироваться и подтверждаться актами, протоколами и etc. Избежать бумажного подтверждения совсем не удастся (должны быть хотя бы роли и ответственность), превращать проект в работу бюрократического аппарата тоже нет смысла. Но если в проекте есть вероятность задержки от постоянно меняющихся данных со стороны заказчика, а сроки проекта жесткие и заказчик каждый раз приносит что-то новое и противоположное предыдущему ¬ вам не обойтись без фиксирования этих этапов, с указанием смещения сроков проекта. И если сразу нет договоренности о подписании протоколов и других документов, вы можете получить очень конфликтную ситуацию, решив в середине проекта подписать решение заказчика. Придется работать с тем что есть и вся ответственность о срыве проекта ляжет целиком на вас.:-(
Рабочий уровень касается непосредственно работ, когда наступает момент «фигачить и фигачить» На этом уровне работают все современные модели управления проектом, водопадный, эджайл и т.д. Выбор за вами.
Вместо заключения:
На практике все приобретает очень трансформированный вид относительно теории.
Я вывел для себя некоторые пункты без которых проект – неблагодарное занятие:
Все управление можно представить как и стек протокола TCP/IP, разложив его про уровням взаимодействия вовлеченных в процесс субъектов и объектов.
Так можно выделить
- идейный
- коммуникативный
- и проектный уровни
К идейному относится все то, что является самой сутью проекта (чего хотим добиться и какие у него свойства). Трудно структурировано представить этот уровень, но это, в первую очередь, общение на этапе «Слушай тут есть классная идея…» или «Вот, нам тут надо…». Тут самое главное опыт самого РМ, который позволит разграничить необходимые и маловразумительные сомнительные желания (они же в дальнейшем характеристики) проекта. Понять и объяснить реальность воплощения тех или иных идей, не исключено что уже тут станет ясно, что по чем. Общение, общение и еще раз общение, со всеми смежными с проектом и могущими в нем участвовать спецами и дилетантами. Дилетанты опишут суть в двух словах – больше они и сами не знают, а суть им так или иначе рассказали. Спецы – посвятят в тонкости и нюансы.
Само собой РМ должен быть специализирован на какой-то области, уверяю вас — РМ интернет стартапов будет жалко смотреться на производстве ЖБИ.
На коммуникативном уровне решаются вопросы как и каким образом весь этот бардак предыдущего уровня, да и последующих, будет управляться в смысле людей и их взаимодействий. Тут есть обязательные, на мой взгляд, для участия субъекты. А именно: ответственный субъект со стороны заказчика, ответственный субъект со стороны исполнителя и идеолог проекта. Как и в какой степени три этих субъекта будут трансформироваться в конкретные личности – дело ваше, но по возможности старайтесь избегать совмещения ответственного субъекта со стороны исполнителя и идеолога проекта в одном лице – иначе в случае завала работ идеологом (ибо люди либо творческие, либо ОЧЕНЬ занятые) у вас не будет возможности влиять на него через ответственного со стороны заказчика.
Из ранней практики:
Проект с постоянно меняющимся ТЗ. В проекте были сомнительные в плане стороны исполнителя задачи по работе с исходными данными. При этом необходимость решения данных задач осознавали все участники проекта. Будем думать, что участие заказчика в выполнении задач проекта объяснять нет необходимости. Так вот исполнитель был и не против взять на себя решение этих задач, за отдельную плату, соответственно. Заказчик долго принимал решение по этому поводу, меняя решение, попутно пытаясь сам что-то делать. В итоге без исходных формализованных данных дальнейшая работа была невозможна, а воз и ныне там. Проект заглох сам собой…
Старайтесь сразу определить степень бюрократичности, а именно какие решения и как будут фиксироваться и подтверждаться актами, протоколами и etc. Избежать бумажного подтверждения совсем не удастся (должны быть хотя бы роли и ответственность), превращать проект в работу бюрократического аппарата тоже нет смысла. Но если в проекте есть вероятность задержки от постоянно меняющихся данных со стороны заказчика, а сроки проекта жесткие и заказчик каждый раз приносит что-то новое и противоположное предыдущему ¬ вам не обойтись без фиксирования этих этапов, с указанием смещения сроков проекта. И если сразу нет договоренности о подписании протоколов и других документов, вы можете получить очень конфликтную ситуацию, решив в середине проекта подписать решение заказчика. Придется работать с тем что есть и вся ответственность о срыве проекта ляжет целиком на вас.:-(
Рабочий уровень касается непосредственно работ, когда наступает момент «фигачить и фигачить» На этом уровне работают все современные модели управления проектом, водопадный, эджайл и т.д. Выбор за вами.
Вместо заключения:
На практике все приобретает очень трансформированный вид относительно теории.
Я вывел для себя некоторые пункты без которых проект – неблагодарное занятие:
- 1) Понимание круга вовлеченных в проект и меры ответственности с подтвержденным в бумажном виде вариантом;
- 2) Понимание круга задач и стороны исполнителя этих задач также с подтверждением этого на бумаге;
- 3) Понимание степени формализации процесса и модель взаимодействия;
- 4) Фиксирование контрольных сроков и зависимость от наличия или отсутствия исходных данных и соответственно сдвиг конечной точки от даны подписания конечного варианта или его изменения после.