И еще немного мыслей на тему методологий управления проектами

Последнее время меня часто записывают в лагерь противников методологий управления проектами (чаще имея ввиду agile/scrum/kanban). Это не совсем так. Я не против методологий, а против их фанатичного применения к месту и без, а также просто мистичесой уверенности в успехе после внедрения agile.

Мне кажется, многие не понимают, зачем вообще нужна методология.

Методология — это некий контракт (договоренность) между всеми участниками процесса. Это как язык жестов, правила дорожного движения, эсперанто или математические формулы. Отличие этих примеров от aglile/scrum/kanban в том, что они не подразумевают различных трактовок. В случае с aglile/scrum/kanban — каждая компания, и даже каждая команда имеет свой «канбан», который в большинстве своем вообще ничего общего с ним не имеет.

По сути, нужно просто собраться всем участникам процесса и обговорить все нюансы. Это достаточно просто, например:

1. Отчетность. Раз в неделю письменно, дважды в неделю (вторник и четверг) — по скайпу.
2. Время реагирования. Для обычных писем — 4 часа, для тех, которые помечены как «важные» — 1 час (у многих компаниях это 15 минут).
3. Обязанности. За технические вопросы отвечает Вася, за сервер — Коля, за чай на кухне — Петя.
4. И т.д.

К примеру, зачем писать на доске задачи, если они есть в жире или TFS. Если вы уверены, что с этим проблем не будет — смело исключайте этот пункт из «контракта». И заметьте, таким образом вы можете комбинировать best practices с разных методологий, подстраиваясь под конкретную команду и проект. Между прочим, это тоже agile, только без налета псевдо-элитности.

Задача менеджера — не написать отчет о проделанной работе или найти исполнителей для проекта. Управление проектом подразумевает достижение цели при отсутствии необходимых ресурсов и полной или частичной неопределенности. Считаю, что знание методов управления рисками и основ бизнеса помогут среднестатической команде больше, чем внедрение agile.

Дальше, любая методология управления предназначена, в первую очередь, для опытных специалистов. Таким образом, если у вас в команде есть начинающие специалисты или новые сотрудники (а такая ситуация была в каждой первой команде, где я работал), то внедрение гибких методологий пагубно скажеться на производительности некоторых членов команды. Ведь джуниор будет думать: «ок, не успею в этот спринт, сделаю в следующем, так методология говорит» (хотя это и не так).

Недавно задали вопрос: «а можно ли fixed price + agile?». Почему бы и нет. При правильном планировании. Но, опять таки, правильное и эффективное планирование зависит не от методологии, а от умения правильно планировать (извините за тавтологию).

Еще одна проблема — использование agile/scrum/kanban там, где его использовать не нужно. Например, в проектах с очень ограниченными сроками или R&D. Или когда выполнение вашей задачи зависит не от вас или вашего начальника, а от внешних факторов, на которые вы влиять не можете. Примеров можно привести множество.

В качестве выводов:

1. Есть ли смысл внедрять методологии? Однозначно.
2. Есть ли смысл тулить agile везде? Нет.
3. Есть ли смысл на всех форумах и сайтах, где есть слово «методология» писать «agile всех спасет, а если нет — у вас руки из жопы растут»? Воля ваша, но со стороны вы выглядите, как минимум, глупо.
4. Нужно ли читать книги о методологиях и ходить на agile тусовки? Однозначно, да. Но относиться ко всему услышанному нужно скептически и просеивать все мнения через ситечко.
5. Ну и, наконец, какая методология лучше? Лучшей методологии нет. Лучшая методология — та, которая подходит вам, вашей команде и заказчику в конкретный момент и в конкретном месте и проекте.

Спасибо за внимание!