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