Pull to refresh

Три с половиной уровня структурности проекта

Reading time3 min
Views3K
Недавно я для себя открыл простую модель, которая обьясняет, какие инструменты нужны менеджеру и команде для ведения и управления проектами.

Все проекты можно разделить на три уровня, по потребности в структуризации и формализации потоков информации и команд. Почему именно это лежит в основе модели? Потому что структура проекта, на мой взгляд, это первое что следует за «стилем управления» и другими неформализируемыми человеческими вопросами.


Нулевой уровень: управляемый хаос

Весь проект на нулевом уровне держится на личных качествах людей. Самое важное – поток общения, количество связей между людьми, а не разграничивание ответственности и структура организации. Идеальные инструменты – whiteboard, если команда не выходит за границы одного офиса, чат, или почтовая конференция (в случае распределенной команды). Распределенной и во времени, и в пространстве, что чаще всего сейчас бывает.

Самый известный инструмент, реализующий хаотический уровень управления проектами – это, конечно, Google Groups :).

Я не стал выносить «хаос» в отдельный уровень структурности, потому что хаос должен присутствовать в любом проекте. Так проект остается живым и мобильным. Хаос человеческого общения – это источник жизни, его нельзя «накрывать» другими уровнями структурности.

Первый уровень: гибкий (agile)

С гибким (быстрым) уровнем структурности, я думаю, знакомы многие. Благодаря Basecamp от «37 Signals», гибкая методология ведения проекта стала понятна не только разработчикам ПО, но и в других областях бизнеса.

Инструменты, которые используются на этом уровне, позволяют не терять решения, и минимально складировать артефакты работы. Упор на разделении задач на атомарные «дела», которые понятны исполнителям. Минимальный набор инструментов этого уровня позволяет реализовать «управление по вехам» (management by milestones):
  • Списки дел (to-do lists)
  • События и календарь (milestones)
  • Документы или другие возможности хранить результаты работы
Часто в списке agile-инструментов есть еще обмен файлами и версионированное хранилище файлов.

Второй уровень: управляемый (managed)

Есть множество проектов, где время исполнения задачи является критичной информацией. И эта информация бывает настолько важна для многих руководителей, что я выделяю такой стиль ведения проектов в отдельный уровень.

Здесь царствует Диаграмма Ганта и «время, потраченное на задачу». Цель – планирование, максимально детальное и реалистичное. Чем более предсказуем контекст проекта и чем более отработаны операции, необходимые в проекте – тем лучше работает диаграмма Ганта. Естественно, прописывание взаимосвязей между задачами и попытка спланировать все, в условиях нечеткой задачи или постоянно меняющихся требований – это безумие. Но есть и другие проекты, например, «постройка микрорайона», где каждый экскаватор расписан по дням и часам.

Есть также дополнительные цели, которых достигают команды, используя инструменты управляемого уровня. Диаграмма проекта – это способ показать клиенту свой пафос и ту самую управляемость. Как на крутой встрече должны быть галстуки и начищенные ботинки, в проекте должна быть диаграмма Ганта :)

Известные системы, которые работают с управляемым видом проекта – MS Project (увы, это его единственная функция), LiquidPlanner, IBN, Zoho, Comindwork. И, конечно, гранды управления проектами типа @Task или Daptiv.

Третий уровень: определенный (defined)

Последний уровень, из тех, до которых добрался я сам – настройка бизнес-процессов. На этом уровне в проекте выделяются отдельные процессы, для каждого из которых настраиваются свои инструменты. Примеры таких процессов – инциденты и проблемы от клиентов; платежи и финансовые транзакции; утверждение критичных документов.

Каждый процесс описывается:
  • Объектом процесса, его полями и свойствами
  • Диаграммой состояний и переходов
  • Правилами доступа при переходах
  • Визуальным оформлением формы и списка
Инструментов, которые поддерживают настраиваемые процессы, уже намного меньше. Хорошие примеры, где это есть – SalesForce (правда, в области CRM, а не управления проектами), Jira, IBN, Comindwork.

Заключение

Автору зачет и уважуха по любому, потому что не так просто написать текст, упомянув собственный продукт так мало раз :)
Спасибо за внимание, жду ваших комментариев!
Tags:
Hubs:
Total votes 42: ↑40 and ↓2+38
Comments54

Articles