Недавно я для себя открыл простую модель, которая обьясняет, какие инструменты нужны менеджеру и команде для ведения и управления проектами.
Все проекты можно разделить на три уровня, по потребности в структуризации и формализации потоков информации и команд. Почему именно это лежит в основе модели? Потому что структура проекта, на мой взгляд, это первое что следует за «стилем управления» и другими неформализируемыми человеческими вопросами.
![](https://habrastorage.org/r/w780q1/getpro/megamozg/post_images/ed4/ce1/455/ed4ce1455b6d1598d4e86b5580b66b26.jpg)
Весь проект на нулевом уровне держится на личных качествах людей. Самое важное – поток общения, количество связей между людьми, а не разграничивание ответственности и структура организации. Идеальные инструменты – whiteboard, если команда не выходит за границы одного офиса, чат, или почтовая конференция (в случае распределенной команды). Распределенной и во времени, и в пространстве, что чаще всего сейчас бывает.
Самый известный инструмент, реализующий хаотический уровень управления проектами – это, конечно, Google Groups :).
Я не стал выносить «хаос» в отдельный уровень структурности, потому что хаос должен присутствовать в любом проекте. Так проект остается живым и мобильным. Хаос человеческого общения – это источник жизни, его нельзя «накрывать» другими уровнями структурности.
С гибким (быстрым) уровнем структурности, я думаю, знакомы многие. Благодаря Basecamp от «37 Signals», гибкая методология ведения проекта стала понятна не только разработчикам ПО, но и в других областях бизнеса.
Инструменты, которые используются на этом уровне, позволяют не терять решения, и минимально складировать артефакты работы. Упор на разделении задач на атомарные «дела», которые понятны исполнителям. Минимальный набор инструментов этого уровня позволяет реализовать «управление по вехам» (management by milestones):
Есть множество проектов, где время исполнения задачи является критичной информацией. И эта информация бывает настолько важна для многих руководителей, что я выделяю такой стиль ведения проектов в отдельный уровень.
Здесь царствует Диаграмма Ганта и «время, потраченное на задачу». Цель – планирование, максимально детальное и реалистичное. Чем более предсказуем контекст проекта и чем более отработаны операции, необходимые в проекте – тем лучше работает диаграмма Ганта. Естественно, прописывание взаимосвязей между задачами и попытка спланировать все, в условиях нечеткой задачи или постоянно меняющихся требований – это безумие. Но есть и другие проекты, например, «постройка микрорайона», где каждый экскаватор расписан по дням и часам.
Есть также дополнительные цели, которых достигают команды, используя инструменты управляемого уровня. Диаграмма проекта – это способ показать клиенту свой пафос и ту самую управляемость. Как на крутой встрече должны быть галстуки и начищенные ботинки, в проекте должна быть диаграмма Ганта :)
Известные системы, которые работают с управляемым видом проекта – MS Project (увы, это его единственная функция), LiquidPlanner, IBN, Zoho, Comindwork. И, конечно, гранды управления проектами типа @Task или Daptiv.
Последний уровень, из тех, до которых добрался я сам – настройка бизнес-процессов. На этом уровне в проекте выделяются отдельные процессы, для каждого из которых настраиваются свои инструменты. Примеры таких процессов – инциденты и проблемы от клиентов; платежи и финансовые транзакции; утверждение критичных документов.
Каждый процесс описывается:
Инструментов, которые поддерживают настраиваемые процессы, уже намного меньше. Хорошие примеры, где это есть – SalesForce (правда, в области CRM, а не управления проектами), Jira, IBN, Comindwork.
Автору зачет и уважуха по любому, потому что не так просто написать текст, упомянув собственный продукт так мало раз :)
Спасибо за внимание, жду ваших комментариев!
Все проекты можно разделить на три уровня, по потребности в структуризации и формализации потоков информации и команд. Почему именно это лежит в основе модели? Потому что структура проекта, на мой взгляд, это первое что следует за «стилем управления» и другими неформализируемыми человеческими вопросами.
![](https://habrastorage.org/getpro/megamozg/post_images/ed4/ce1/455/ed4ce1455b6d1598d4e86b5580b66b26.jpg)
Нулевой уровень: управляемый хаос
Весь проект на нулевом уровне держится на личных качествах людей. Самое важное – поток общения, количество связей между людьми, а не разграничивание ответственности и структура организации. Идеальные инструменты – whiteboard, если команда не выходит за границы одного офиса, чат, или почтовая конференция (в случае распределенной команды). Распределенной и во времени, и в пространстве, что чаще всего сейчас бывает.
![](https://habrastorage.org/getpro/megamozg/post_images/1e5/6cd/d15/1e56cdd1587a90637ee94c1b6b375493.gif)
Я не стал выносить «хаос» в отдельный уровень структурности, потому что хаос должен присутствовать в любом проекте. Так проект остается живым и мобильным. Хаос человеческого общения – это источник жизни, его нельзя «накрывать» другими уровнями структурности.
Первый уровень: гибкий (agile)
![](https://habrastorage.org/getpro/megamozg/post_images/dc3/72e/77f/dc372e77fd8ea28cf284c470fe3b3d30.png)
Инструменты, которые используются на этом уровне, позволяют не терять решения, и минимально складировать артефакты работы. Упор на разделении задач на атомарные «дела», которые понятны исполнителям. Минимальный набор инструментов этого уровня позволяет реализовать «управление по вехам» (management by milestones):
- Списки дел (to-do lists)
- События и календарь (milestones)
- Документы или другие возможности хранить результаты работы
Второй уровень: управляемый (managed)
Есть множество проектов, где время исполнения задачи является критичной информацией. И эта информация бывает настолько важна для многих руководителей, что я выделяю такой стиль ведения проектов в отдельный уровень.
![](https://habrastorage.org/getpro/megamozg/post_images/029/374/f7b/029374f7be2f0bd7de8cae668f9c8e83.jpg)
Есть также дополнительные цели, которых достигают команды, используя инструменты управляемого уровня. Диаграмма проекта – это способ показать клиенту свой пафос и ту самую управляемость. Как на крутой встрече должны быть галстуки и начищенные ботинки, в проекте должна быть диаграмма Ганта :)
Известные системы, которые работают с управляемым видом проекта – MS Project (увы, это его единственная функция), LiquidPlanner, IBN, Zoho, Comindwork. И, конечно, гранды управления проектами типа @Task или Daptiv.
Третий уровень: определенный (defined)
Последний уровень, из тех, до которых добрался я сам – настройка бизнес-процессов. На этом уровне в проекте выделяются отдельные процессы, для каждого из которых настраиваются свои инструменты. Примеры таких процессов – инциденты и проблемы от клиентов; платежи и финансовые транзакции; утверждение критичных документов.
Каждый процесс описывается:
- Объектом процесса, его полями и свойствами
- Диаграммой состояний и переходов
- Правилами доступа при переходах
- Визуальным оформлением формы и списка
![](https://habrastorage.org/getpro/megamozg/post_images/d12/e58/171/d12e5817111b923ba322bedc2cc3b0b6.gif)
Заключение
Автору зачет и уважуха по любому, потому что не так просто написать текст, упомянув собственный продукт так мало раз :)
Спасибо за внимание, жду ваших комментариев!