Три с половиной уровня структурности проекта
Недавно я для себя открыл простую модель, которая обьясняет, какие инструменты нужны менеджеру и команде для ведения и управления проектами.
Все проекты можно разделить на три уровня, по потребности в структуризации и формализации потоков информации и команд. Почему именно это лежит в основе модели? Потому что структура проекта, на мой взгляд, это первое что следует за «стилем управления» и другими неформализируемыми человеческими вопросами.
Весь проект на нулевом уровне держится на личных качествах людей. Самое важное – поток общения, количество связей между людьми, а не разграничивание ответственности и структура организации. Идеальные инструменты – whiteboard, если команда не выходит за границы одного офиса, чат, или почтовая конференция (в случае распределенной команды). Распределенной и во времени, и в пространстве, что чаще всего сейчас бывает.
Самый известный инструмент, реализующий хаотический уровень управления проектами – это, конечно, Google Groups :).
Я не стал выносить «хаос» в отдельный уровень структурности, потому что хаос должен присутствовать в любом проекте. Так проект остается живым и мобильным. Хаос человеческого общения – это источник жизни, его нельзя «накрывать» другими уровнями структурности.
С гибким (быстрым) уровнем структурности, я думаю, знакомы многие. Благодаря Basecamp от «37 Signals», гибкая методология ведения проекта стала понятна не только разработчикам ПО, но и в других областях бизнеса.
Инструменты, которые используются на этом уровне, позволяют не терять решения, и минимально складировать артефакты работы. Упор на разделении задач на атомарные «дела», которые понятны исполнителям. Минимальный набор инструментов этого уровня позволяет реализовать «управление по вехам» (management by milestones):
Есть множество проектов, где время исполнения задачи является критичной информацией. И эта информация бывает настолько важна для многих руководителей, что я выделяю такой стиль ведения проектов в отдельный уровень.
Здесь царствует Диаграмма Ганта и «время, потраченное на задачу». Цель – планирование, максимально детальное и реалистичное. Чем более предсказуем контекст проекта и чем более отработаны операции, необходимые в проекте – тем лучше работает диаграмма Ганта. Естественно, прописывание взаимосвязей между задачами и попытка спланировать все, в условиях нечеткой задачи или постоянно меняющихся требований – это безумие. Но есть и другие проекты, например, «постройка микрорайона», где каждый экскаватор расписан по дням и часам.
Есть также дополнительные цели, которых достигают команды, используя инструменты управляемого уровня. Диаграмма проекта – это способ показать клиенту свой пафос и ту самую управляемость. Как на крутой встрече должны быть галстуки и начищенные ботинки, в проекте должна быть диаграмма Ганта :)
Известные системы, которые работают с управляемым видом проекта – MS Project (увы, это его единственная функция), LiquidPlanner, IBN, Zoho, Comindwork. И, конечно, гранды управления проектами типа @Task или Daptiv.
Последний уровень, из тех, до которых добрался я сам – настройка бизнес-процессов. На этом уровне в проекте выделяются отдельные процессы, для каждого из которых настраиваются свои инструменты. Примеры таких процессов – инциденты и проблемы от клиентов; платежи и финансовые транзакции; утверждение критичных документов.
Каждый процесс описывается:
Инструментов, которые поддерживают настраиваемые процессы, уже намного меньше. Хорошие примеры, где это есть – SalesForce (правда, в области CRM, а не управления проектами), Jira, IBN, Comindwork.
Автору зачет и уважуха по любому, потому что не так просто написать текст, упомянув собственный продукт так мало раз :)
Спасибо за внимание, жду ваших комментариев!
Все проекты можно разделить на три уровня, по потребности в структуризации и формализации потоков информации и команд. Почему именно это лежит в основе модели? Потому что структура проекта, на мой взгляд, это первое что следует за «стилем управления» и другими неформализируемыми человеческими вопросами.
Нулевой уровень: управляемый хаос
Весь проект на нулевом уровне держится на личных качествах людей. Самое важное – поток общения, количество связей между людьми, а не разграничивание ответственности и структура организации. Идеальные инструменты – whiteboard, если команда не выходит за границы одного офиса, чат, или почтовая конференция (в случае распределенной команды). Распределенной и во времени, и в пространстве, что чаще всего сейчас бывает.
Самый известный инструмент, реализующий хаотический уровень управления проектами – это, конечно, Google Groups :). Я не стал выносить «хаос» в отдельный уровень структурности, потому что хаос должен присутствовать в любом проекте. Так проект остается живым и мобильным. Хаос человеческого общения – это источник жизни, его нельзя «накрывать» другими уровнями структурности.
Первый уровень: гибкий (agile)
С гибким (быстрым) уровнем структурности, я думаю, знакомы многие. Благодаря Basecamp от «37 Signals», гибкая методология ведения проекта стала понятна не только разработчикам ПО, но и в других областях бизнеса. Инструменты, которые используются на этом уровне, позволяют не терять решения, и минимально складировать артефакты работы. Упор на разделении задач на атомарные «дела», которые понятны исполнителям. Минимальный набор инструментов этого уровня позволяет реализовать «управление по вехам» (management by milestones):
- Списки дел (to-do lists)
- События и календарь (milestones)
- Документы или другие возможности хранить результаты работы
Второй уровень: управляемый (managed)
Есть множество проектов, где время исполнения задачи является критичной информацией. И эта информация бывает настолько важна для многих руководителей, что я выделяю такой стиль ведения проектов в отдельный уровень.
Здесь царствует Диаграмма Ганта и «время, потраченное на задачу». Цель – планирование, максимально детальное и реалистичное. Чем более предсказуем контекст проекта и чем более отработаны операции, необходимые в проекте – тем лучше работает диаграмма Ганта. Естественно, прописывание взаимосвязей между задачами и попытка спланировать все, в условиях нечеткой задачи или постоянно меняющихся требований – это безумие. Но есть и другие проекты, например, «постройка микрорайона», где каждый экскаватор расписан по дням и часам. Есть также дополнительные цели, которых достигают команды, используя инструменты управляемого уровня. Диаграмма проекта – это способ показать клиенту свой пафос и ту самую управляемость. Как на крутой встрече должны быть галстуки и начищенные ботинки, в проекте должна быть диаграмма Ганта :)
Известные системы, которые работают с управляемым видом проекта – MS Project (увы, это его единственная функция), LiquidPlanner, IBN, Zoho, Comindwork. И, конечно, гранды управления проектами типа @Task или Daptiv.
Третий уровень: определенный (defined)
Последний уровень, из тех, до которых добрался я сам – настройка бизнес-процессов. На этом уровне в проекте выделяются отдельные процессы, для каждого из которых настраиваются свои инструменты. Примеры таких процессов – инциденты и проблемы от клиентов; платежи и финансовые транзакции; утверждение критичных документов.
Каждый процесс описывается:
- Объектом процесса, его полями и свойствами
- Диаграммой состояний и переходов
- Правилами доступа при переходах
- Визуальным оформлением формы и списка
Инструментов, которые поддерживают настраиваемые процессы, уже намного меньше. Хорошие примеры, где это есть – SalesForce (правда, в области CRM, а не управления проектами), Jira, IBN, Comindwork. Заключение
Автору зачет и уважуха по любому, потому что не так просто написать текст, упомянув собственный продукт так мало раз :)
Спасибо за внимание, жду ваших комментариев!
комментарии (54)