Сравнение подходов к реализации пректов
В процессе поиска решения возникших задач растет понимание как много всего есть вокруг полезного, что стоит применить и у себя. В итоге проект разрастается. Есть несколько способов справиться с возникающими сложностями, рассмотрим их.
PMBoK (Project Management Body of Knowledge)
Наличием диаграммы Гантта ("Дорожной картой") похож на Waterfall, но принципиально отличается исчерпывающим списком рисков. Для каждого риска прорабатывается план избегания/минимизации, а также указываются действия на случай, если риск реализовался. Менеджер проекта обязан каждый из них постоянно контролировать. Эта работа помогает укладываться в "проектный треугольник" - в сроки, в бюджет, в согласованное содержание. Отклонения допустимы, но тем меньшие, чем больше времени прошло от начала проекта:
- Этап концепции (conceptual estimate): -25% ... +75%
- Этап предварительного планирования (budget estimate): -10% ... +25%
- Этап запуска проекта (definitive estimate): -5% ... +10%
Вопреки ожиданиям любителей сложные проекты запускать "под ключ" или "Большим взрывом", PMBoK не обязывает запускать все наработки в финальный день проекта, более того, поэтапный запуск может быть сценарием избегания рисков. Очень результативный метод, но весьма сложный и дорогой. В частности, чтобы попасть в указанную выше точность прогнозов, число выявленных и контролируемых рисков исчисляется сотнями.
Подход Waterfall (Водопад, Каскадная модель, Дорожная карта, метод "Большого взрыва", "Под ключ")
Суть подхода - детализировать все требования. Если оценки затрат и сроков вышли за плановые рамки, требования заранее урезаются или увеличивается бюджет. Ключевое отличие от PMBoK - работа с рисками по мере их срабатывания. Применительно к реализации инноваций называют "Методом Большого взрыва", как раз по причине, что зачастую не продумывается работа с рисками, надеются на успешный запуск в назначенную "Дату Х", успех которой возлагается на детальную проработку требований. Фактический бюджет редко совпадает с плановым, может отличаться в разы. Для мероприятий с приемлемой стоимостью рисков практичнее других перечисленных методов, поэтому пользуется большой популярностью. Часто применяется компаниями при открытии новых магазинов, складов, офисов, не редко можно встретить под именем "Дорожной карты" той или иной инициативы.
Система Kanban
Система хорошо подходит для конвейера. Применительно к внедрению инноваций, суть - "дорогу осилит идущий", со всеми вытекающими. Все, что пришло в голову, записывается в список задач ("бэклог"), как получится, определяются приоритеты, по мере возможностей задумки реализовываются. Бюджет и прогресс оценить сложнее, чем в других методах. Для реализации инноваций сомнительный выбор - система не запрещает, но и не предполагает как продумывания общего плана, так и проактивной работы с рисками. Отлично подходит для обслуживания в ИТ: выполнение (несложных) доработок, закрытие заявок на устранение инцидентов.
Методология Scrum
Метод отлично подходит для проектов с высокой неопределенностью и ограниченным бюджетом времени и денег. Ключ успеха - в активном использовании принципа ("закона") Парето. Уложиться в требуемый бюджет и сроки проще, чем по другим методам. Обычно, требуя работать по Scrum, ожидают получить бюджет и сроки в ответ на выданные команде требования, но с этой методологией правильно работать наоборот - заранее определить эти ограничения:
- в какую сумму необходимо уложиться
- к какой дате основная часть функционала должна быть готова
Далее необходимо очень грубо определить план релизов. Их очередность стоит определять исходя из основных выгод и ключевых рисков. Чем больше будет запланировано релизов, тем выше будут шансы уложиться в установленные бюджет и сроки. Все остальное, что описывает методология - важно, но не первостепенно для успеха реализации проекта по Scrum. Две роли, от которых, в основном, зависит результат: Владелец продукта и Скрам-мастер. Владелец продукта преимущественно отвечает за реализацию выгод в оптимальной очередности. Скрам-мастер обеспечивает работу с рисками и возможностями:
- контроль оперативных рисков:
- ежедневные стендапы для контроля, что команда движется к Sprint Goal с запланированной скоростью
- организация устранения возникающих заминок (на стендапе выявили, следом нужным составом собрались, чтобы устранить проблемы технические, организационные или административные)
- управление стратегическими рисками:
- Sprint Demo не только демонстрирует успех итерации, но и позволяет контролировать верность выбранного плана, которого придерживается Владелец продукта
- выявление возможностей:
- Sprint Retrospective призвана выявлять возможности повышения эффективности работы над проектом.
Их задача вдвоем составить оптимальный план релизов с учетом ключевых рисков и выгод. Важна ли команда (Development Team)? Да! Но с неудачным планом работ ее квалификации может не хватить для реализации проекта.
Подготовка плана проекта
Для подготовки плана необходимо верно определить цели. Очень редко когда на старте проекта не описана цель. Но верно ли она определена и описана?
Определение выгод. Техника "Пять зачем" ("Пять почему", "Five whys")
Данная техника применяется инженерами для поиска первопричин возникающих проблем. Эмпирическим путем установлено, что пяти последовательных вопросов в большинстве случаев достаточно, чтобы докопаться до первопричины. Эту же технику практично использовать для выявления ключевых целей проекта. То есть, с большой вероятностью пяти "зачем" хватит, чтобы определить ключевые факторы, мотивирующие выделение бюджета.
К сожалению, гарантированного алгоритма таких вопросов не существует. Все зависит от эксперта, задающего вопросы, и открытости собеседников. Примеры ниже преднамеренно приведу вдалеке от ИТ тематики - суть это не меняет, зато, надеюсь, фокусирует на понимании различий в сценариях вопросов и к каким решениям это ведет.
Пять зачем: Клиент ищет стул
Как-то преподаватель на курсе привел пример, когда важно выявить неочевидные мотивы клиента, на примере стула:
- стул как стремянка, чтобы достать книги с верхних полок
- стул как вешалка для костюма
- стул как предмет интерьера, радующий глаз
- стул как демонстрация гостям статуса владельца дома
Это помимо очевидных требований к стулу. Не редко, клиент сам не до конца осознает свои мотивы. Продавец, который выявит скрытые мотивы, увеличит удовлетворенность покупкой, а также облегчит сам процесс продажи.
Для некоторых задач подобного списка требований достаточно, остается выявить основные риски. Для данного примера можно предложить следующие потенциальные неприятности:
- эксплуатация покажет, что выбранная комбинация свойств предмета далека от ожидавшейся
- клиент скроет или не сможет достаточно точно описать требования
(например, сказал, что стульями как стремянкой пользуются только дети, которых он легко выдерживает, но, предположим, в будем он сломается под взрослым, а этот сценарий клиет умышленно или непреднамеренно отверг) - клиент откажется от задачи в процессе выбора решения
Первые два риска перекрываются предоставлением образцов для полевых испытаний, но это увеличивает третий риск и наоборот.
Для составления плана релизов необходимо получить приоритеты заказчика по каждому требованию, сопоставить с рисками, бюджетом и сроками. Например, приоритеты и комментарии даны следующие:
- 50% ценности: статус по восприятию покупателя
- 20% ценности: стул для столовой
- 10% ценности: стул для работы за столом
- 10% ценности: предмет интерьера, радующий глаз
- 5% ценности: стремянка для детей
- 5% ценности: вешалка для костюма главы семьи
- клиент может приехать в назначенный день в полном составе семьи, чтобы ускорить покупку
Это самый простой сценарий - проверить выполнение первых трех требований можно в одну встречу, пригласив в магазин всю семью в день, когда требуемые образцы будут на витрине, для подтверждения статуса предложить только соответствующие этому требованию бренды. Продажа может стать успешной, так сказать, в "один релиз", если за него считать визит всей семьи с покупкой в тот же день.
Более сложный набор приоритетов:
- 50% ценности: предмет интерьера, радующий глаз
- 20% ценности: статус по мнению важных для покупателя лиц
- 10% ценности: стул для столовой
- 10% ценности: стул для работы за столом
- 5% ценности: стремянка для детей
- 5% ценности: вешалка для костюма главы семьи
- приехать в магазин может только супруга, но есть время на проверку образцов в домашних условиях
Соответствие всем требованиям, кроме статуса, можно проверить, позволив клиенту привезти образцы домой. Повысить вероятность удовлетворенности покупкой можно предоставив достаточный срок на испытания. Но как это повлияет на цену варианта, который в итоге клиент оплатит? Как компенсировать работу продавца, если сделка сорвется? Сколько релизов требуется? Минимум два: "предоставить образцы", "продать выбранный вариант".
ИТ проекты только на первый взгляд отличаются от этого случая. Суть - при таком сценарии вопросов "Пять зачем" мы можем жонглировать требованиями и рисками лишь в достаточно ограниченном диапазоне, нам сложно предложить решения, решающие исходные проблемы альтернативными способами. Однако, для ряда задач этого достаточно.
Пять зачем: Клиент просит сделать "красный удобный топор"
Однажды, когда потребовалось развивать аналитиков, пришел в голову пример, специально далекий от ИТ, демонстрирующий насколько широко иногда требуется посмотреть на задачу, чтобы подобрать верное решение. Представим, что наша команда специализируется на изготовлении различных инструментов. К нам приходит заказчик и просит изготовить для него "красный удобный топор".
Вариант 1, типичные вопросы аналитика на просьбу сделать "красный удобный топор":
- Зачем требуется топор?
Ответ: рубить деревья - Почему топор должен быть красным?
Ответ: чтобы быть более заметным в траве - Давайте уточним оттенок красного, отражающую способность, износостойкость краски, стоимость, противоскользящие свойства
- Давайте уточним параметры удобства топора:
- Требуется работать в основном одной рукой или преимущественно двумя руками?
- Требуется ли сделать топорище как можно легче, либо приоритет за надежностью, за ценой?
- Полотно топора должно медленно тупиться или быть стойким к излому?
- Сколько требуется изготовить топоров?
- Какие сроки на изготовление? Актуально ли разделить заказ на партии?
- В какой бюджет хотелось бы уложиться?
И далее в том же ключе. Это достаточно очевидный сценарий сбора требований. Но на какие вопросы будет в состоянии ответить заказчик? Не редко, когда покупатель ожидает, что исполнитель сам найдет ответы на большую часть вопросов - он же в этом профессионал, а не заказчик! Какие риски мы можем увидеть из полученных ответов? Как и в случае с кейсом "Клиент ищет стул", полученных сведений может хватить для успешной реализации задачи. Но не редко приходилось видеть ситуации, когда команды пытались годами реализовать задуманное, но всякий раз получалось совсем не то, что хотелось бы, а почему - непонятно.
Вариант 2, вопросы опытного аналитика на просьбу сделать "красный удобный топор":
- Зачем требуется топор?
Ответ: рубить деревья - Сколько деревьев планируется срубить?
Ответ: точно не знаю, несколько тысяч - Сколько топоров необходимо?
Ответ: пара сотен - Сколько времени у нас есть?
Ответ: 1-2 недели - Вы рассматривали альтернативные решения? Например:
- Не будет ли удобнее использовать двуручную пилу? Можем предоставить несколько экземпляров на пробу
- Можно ли использовать бензиновую цепную пилу? У нас такие можно взять в аренду
- Вырубка деревьев "под ключ"? Готовы спилить деревья, отпилить сучья, доставить по нужному адресу. При необходимости очистим деревья от коры, высушим, можем распилить на доски требуемых габаритов.
Такой сценарий диалога позволяет взглянуть на задачу шире, предоставив клиенту более практичное решение, которое по разным причинам могло ему не прийти в голову. Возможно, клиент только начал свои изыскания и наиболее практичное решение ему предложит конкурент, а не Вы. Поэтому бывает практичным выйти за привычные рамки, даже, если клиент не видит пока в этом нужды. Не хочу усложнять данный варинт перечислением рисков и выгод, здесь принципиально было показать расширение рамок поставленной задачи.
Вариант 3, вопросы глубокомыслящего аналитика на просьбу сделать "красный удобный топор":
- Зачем требуется топор?
Ответ: рубить деревья - Сколько деревьев планируется срубить?
Ответ: точно не знаю, несколько тысяч - Зачем требуется вырубить столько деревьев?
Ответ: необходимо вырубить 10 гектар леса, насколько я слышал - под пашню - Идем к коллегам: Зачем нужна пашня?
Ответ: необходимо засеять пшеницей, насколько я слышал - сделать муку - Идем к другим коллегам: Зачем нужно столько муки?
Ответ: не знаю, слышал, что из муки сделают хлеб - Идем к следующим коллегам: Зачем нужно столько хлеба?
Ответ: этим хлебом в течение следующего года требуется кормить 1000 человек - С 10 гектар удастся ли собрать необходимый урожай, чтобы год кормить 1000 человек?
Ответ: некоторые считают, что для этого может потребоваться засеять более 100 гектар, но у нас нет для этого ни территории, ни зерна (есть 100-150кг) - Когда требуется начать посевные работы, чтобы успеть засеять 10 гектар?
Ответ: у нас есть 1-2 месяца, после этого мы не успеем засеять - Сколько людей планируется привлечь к вырубке леса?
Ответ: мы готовы выделить до 200 мужчин - Сколько времени потребуется 200 мужчинам для выручки 10 гектар?
Ответ: не знаем, но по оценкам, 10 профессионалов могут вырубить 10 гектар за 2-4 недели. Но требуется не только вырубить, но также выкорчевать пни, все вывезти, подготовить участок под пашню.
В некоторых случаях крайне важно пройти примерно по такому сценарию выявления первопричин задачи. Что мы выяснили этими вопросами?
Ожидаемые выгоды / цели:
- В течение следующего года кормить 1000 человек
Ограничения:
- Есть 10 гектар леса, который готовы использовать для обеспечения 1000 людей пищей
- Часть из 1000 человек может быть привлечено к заготовке пищи на следующий год
- Есть около года на заготовку пищи на следующий год
Основные риски:
- 10 гектар, засеянных пшеницей, не хватит для обеспечения пищей 1000 человек в течение года.
Исходя из оценки среднего потребления 500г в день на человека (если питаться только хлебом, калорийность которого около 2500кДж/кг), 150-250 тонн пшеницы на 1000 человек на год, 2-4 тонны пшеницы с гектара, сбора 20-50 зерен с каждого посеянного зерна, может потребоваться 200-500кг пшеницы и 40-100 гектар под посевы.
Суть - маловероятно, что 10 гектар и 150 кг пшеницы хватит, чтобы собрать требуемый урожай, который еще нужно хранить в течение года. В данной ситуации уже нет особой необходимости начинать с предложений альтернативных способов вырубки леса. Заказчику жизненно важно проработать альтернативные варианты обеспечить 1000 человек едой. Например, продолжить проект с вырубкой леса под пашню, но исходить, что это обеспечит рацион лишь на четверть.
Вот этот, третий, вариант отражает суть моего подхода к выявлению целей, финансирующих инновационные проекты. Он зачастую позволяет выявить неочевидные риски и совместно найти не очевидные изначально решения за счет смены формулировок, когда "верно заданный вопрос, содержит половину решения".
Выводы
Agile подход, которым пользуюсь, ближе всего к Scrum. Его ключевые моменты:
- Выявить и сформулировать выгоды, дающие финансирование проекту
- Определить Критерии приемки работ
- Выявить риски
- Составить план релизов
Эти нехитрые правила позволяют повысить шансы на успех инициативы почти до 100%