В консалтинге может присутствовать налаженный документооборот, составление объёмных технических заданий перед решением, система выделения ресурсов на задачи и т.д. А может отсутствовать. Вообще.

Ниже я попробую сравнить порядок и хаос, “водопад” и “ковбойский консалтинг”, а также показать возможный “промежуточный взгляд на вещи” - ведение проектов с помощью команды “самоорганизующихся консультантов”.

Ковбои против водопада

Водопад

Рассмотрим более подробно первый случай. Для такой работы нам нужна будет некая методология ведения проекта, зачастую предусматривающая несколько месяцев обследований заказчика, изучений рынка, составления технических заданий, функциональных спецификаций, технико-экономических обоснований и так далее. Наличие этой методологии позволит нам производить стандартные артефакты (выдавать результат) даже при условии наличия слабых специалистов в команде. Регулярные встречи с заказчиком, презентации по запуску, отчёты о состоянии проекта и т.д. дают возможность управлять движением проекта вперёд. Назовём такую схему “водопад”.

Чуть подробнее о “водопаде”. Так называют проект, состоящий из нескольких функционально-различных стадий, выполняемых в один проход, без повторений. Например, мы сначала собираем все требования заказчика и только потом приступаем к их анализу. И только когда закончим анализ всех требований начнём проектировать решение. Применительно к автоматизации управления предприятием фазы могут выглядеть так:
Модель водопада
Кликните, пожалуйста, на картинку, если хотите увидеть её целиком. Подробнее о модели водопада можно прочитать в энциклопедии консалтинга GoodLancer.com.

Ковбойский консалтинг

Рассмотрим второй вариант: заключаете с клиентом договор, в котором оговорена оплата за потраченное время консультантов и технических специалистов, после чего посылаете специалистов с наказом “сделать клиенту хорошо”. Как они делают это “хорошо” контролируем по подписанным клиентом таймшитам (листам учета времени специалистов). Консультанты работают абсолютно автономно в плане решений. Назовем это “ковбойским консалтингом”. После начала проекта вмешательство менеджера может быть минимальным. Ковбой, не способный подписать таймшиты у заказчика, снимается с проекта и переводится на другой проект или увольняется из компании. Т.к. ковбою мы платим некий процент из акцептованных заказчиком человекочасов помноженных на часовую ставку, то рисков заплатить сотруднику больше, чем заработала компания у нас нет. Есть риск потерять клиента из-за несоответствующей квалификации отдельного консультанта.

Кто сильнее - слон или кит?

Каждый документ, каждое решение при использовании “водопада” является компромиссом - оно должно быть понятно и принято руководителями или ключевыми специалистами команд заказчика и исполнителя. Во многих случаях если опыт одного из членов команды отличается от опыта всех остальных, мы не сможем использовать этот уникальный опыт. Кроме того так как все основные решения принимаются в начале проекта, а дальше только расшифровываются, то и знания приобретённые в ходе проекта мы не всегда сможем использовать - процедура внесения изменений в “соглашение о масштабе проекта” или в “техническое задание” может быть очень громоздкой.

Ковбойский консалтинг этим недостатком не обладает. Вопрос только в том можно ли организовать эффективную работу команды ковбоев.

SCRUM для консалтинга

В разработке программного обеспечения методологии управления командами “ковбоев” сейчас являются хитом номер один и, в общем-то нам ничего не мешает применить такую методологию и к крупному консалтинговому проекту. Мы можем, для примера, обратиться к одной из наиболее популярной из “гибких” методологий управления процессом разработки программного обеспечения - SCRUM. Это - итерационная методология, что означает, что конечный результат пользователь получает не в конце проекта, а несколькими “порциями” на всём протяжении проекта. Вторая особенность состоит в том, что SCRUM позволяет полнее использовать знания, навыки и наклонности членов команды с помощью следующего принципа - в SCRUM нет менеджера, говорящего конкретному члену команды что и как делать. Есть только требования клиента к продукту и SCRUM-мастер, который помогает членам команды взяимодействовать друг с другом и заказчиком. Ссылку на хорошее описание методологии SCRUM ищите внизу этой статьи.

Определим роли:
1. Заказчик. В данном примере это может быть некоторая группа бухгалтеров
2. Исполнитель. Неструктурированная команда из консультантов, аналитиков и программистов
3. SCRUM-мастер. Человек-интерфейс. Обеспечивает взаимодействие между первыми и вторыми плюс не даёт им мешать друг другу. В оригинальной формулировке “отвечает за SCRUM”.

SCRUM-процесс:
1. Определение требований
На общей встрече заказчик описывает свои требования по пунктам, причём требования могут быть как обязательными к исполнению, так и необязательными - то, что клиент хотел бы видеть, но без чего он мог бы прожить. Далее заказчик в некоторых сравнительных цифрах (а возможно, что и в деньгах) оценивает каждый пункт. Исполнитель напротив каждого пункта ставит оценку в человекочасах. Назовём полученный документ “требованиями к системе”.
2. Договариваемся об организации процесса. Схема может быть такая - весь проект разбиваем на итерации по месяцу (не обязательно по месяцу, но именно итерации длиной в месяц очень удобны). В начале каждой итерации (назовём её также, как она называется в scrum - спринтом) исполнитель выбирает требования из общего списка таким образом, чтобы получить наилучший результат на конец спринта. В конце итерации исполнитель сдаёт заказчику результат. В полностью рабочем виде - в том виде, что закачик может использовать. Более того, сразу оговариваем, что после очередного спринта заказчик может поменять свой набор требований или даже закрыть проект, удовлетворившись результатом на конец спринта.
3. Внутри каждой итерации исполнитель преобразует выбранные для спринта требования в список задач и оценивает сложность задач в человекочасах. Далее члены команды выбирают самостоятельно для себя задачи, стараясь брать в первую очередь наиболее приоритетные, но при этом учитывая навыки, знания и предпочтения каждого конкретного члена команды.
4. В конце каждого спринта исполнитель передаёт заказчику полученные результаты.

Отслеживание хода проекта

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

Плюсы и минусы SCRUM для консалтинга

По сравнению с “водопадом” scrum даст следующие плюсы:
- каждый месяц заказчик получает и начинает использовать результаты нашей работы за месяц. Риски того, что в конце проекта выяснится, что его результаты не могут быть использованы минимальны;
- мы можем позволить нанимать специалистов-звёзд и полностью использовать их потенциал даже при работе в команде;
- любые идеи заказчика или консультанта, возникшие по ходу проекта могут быть использованы, если несут преимущества по сравнению с первоначальным техзаданием.

По сравнению с обычным “ковбойским консалтингом” мы тоже получим плюсы:
- мы можем использовать схему на проекте, требующем команды консультантов. Более того, мы даже извлечём пользу от использования на одном проекте консультантов с разной специализацией;
- мы точно знаем в каком состоянии находится проект и вряд ли потеряем клиента из-за того, что ситуация вышла из под контроля.

Считаю ли я SCRUM идеальной методологией для внедрения программного обеспечения? Нет. Идеальной методологией я считаю здравый смысл, а никак не трёх- и пятибувенные сочетания. Вы сами можете придумать ситуации когда проекту позарез нужна авторитарность, быстрое принятие чётких и обязательных для всех членов команды решений или разработка решений, которые не могут быть реализованы в рамках одного спринта.

Тем не менее я считаю SCRUM очень интересным подходом к управлению командой и задачами и если вы заинтересовались, то предлагаю вам скачать и прочитать книгу Хенрика Книберга “Scrum и XP: заметки с передовой” в переводе сообщества Agile Ukraine.