И у нее есть два слоя, каким образом она может быть полезна руководителям проектов (я, по-крайней мере, на это надеюсь): во-первых, здесь много интересных идей, высказанных РП, работающими в разных условиях и с разными заказчиками. А во-вторых, можно посмотреть, как проводить такого рода онлайн-мозговые штурмы - можно повторить по темам, которые актуальны вам. Кстати, если будете проводить свой мозговой штурм по мотивам - поделитесь в комментариях, как оно прошло - интересно обменяться опытом!
Прежде чем мы приступим к сути - традиционная минутка рекламы. Тех, кому интересен формат такого типа обсуждений и обмена опытом - приглашаю на свои интерактивные онлайн-курсы по управлению проектами.
24 февраля 2021 стартует Базовый курс в рамках Комплексного курса по управлению ИТ-проектами, а 25 марта - курс по Agile.
Суть проблемы
Те, кто читали мою статью под заголовком “Как собрать исчерпывающие бизнес-функциональные требования в начале проекта внедрения?” помнят предлагаемый в ней ответ на поставленный в названии вопрос (спойлер: Никак!).
Действительно, практически всем кто имел опыт внедрения сколько-нибудь сложной информационной системы, знакома ситуация - наиболее полные и четкие требования бизнес-заказчики способны озвучить на финальных стадиях проекта, когда продукт пора переводить в опытно-промышленную эксплуатацию. А (конечно, если внедрение не “для галочки”, а систему предполагается использовать в реальной работе) предварительную версию ТЗ, созданную на старте, практически всегда приходится существенно трансформировать и дорабатывать.
Выход, разумеется, есть. Он описан, в частности, в моей статье Можно ли объять необъятное или чем Agile отличается от водопада? и предполагает использование вместо предиктивного подхода (“Водопада”) подходов адаптивных (итеративного, инкрементального или гибкого - Agile). Как известно, при работе по Agile мы не пытаемся создавать иллюзию, что ТЗ будет полным, и сразу констатируем тот факт, что окончательный объем, сроки и стоимость будут корректироваться по ходу. Для достижения главной цели - поставки бизнес-ценности, и получения продукта который будет максимально полезен Заказчику. В смысле, на самом деле максимально полезен, а не в том смысле, как он предполагал на начальных стадиях.
Идея прекрасная, но бизнес-заказчик (особенно на внешних проектах) часто настаивает на том, чтобы исполнитель сразу описал объем работ, указал точные сроки и стоимость.
Описание кейса
Автор: Антон Солодков, РП, выпускник курсов по управлению ИТ-проектами.
На практике нередко приходится иметь дело с проектом с большими неопределенностями. Как в такой ситуации склонить заказчика на сторону «света»? (если «свет» - это гибкие методологии) При этом заказчик совсем не понимает о чем речь и хочет поэтапной конкретики. И, конечно, ожидает выполнения по этапам и такое же актирование/оплату.
1. Получили запрос на внедрение. Как-то примерно оценили общую стоимость исходя из допущений и опыта.
2. Сделали предпроектное обследование. Сформулировали этапы, описание, сроки, бюджет скорректировали (все что хотел видеть заказчик). При этом из заказчика как будто «клещами вытаскивали информацию». И почему-то устойчивое ощущение, что в проекте нас ждет огромное количество подводных камней, много решений/предложений, когда «ходим по краю» - один маленький шаг в сторону и вся архитектура «к чертям». На этом месте у Исполнителя сложилось устойчивое убеждение, что выполнить проект можно только гибкими методологиями - внедряя по частям, и уточняя требования по мере продвижения.
3. У заказчика нет человека кто бы был «в теме» гибких методологий. При этом гибкие методологии предполагают активное участие заказчика во всем процессе разработки, следование общим принципам и методам командной работы (для успеха проекта необходимо тесное сотрудничество - фактически, общая команда исполнителя и заказчика). Конечно, можно было бы обучить заказчика гибким методологиям, но как это в реальности осуществить совершенно непонятно – никто не хочет время «тратить», тем более, что заказчик считает, что “итак все понятно”.
4. В условиях высокой неопределенности определить бюджет проекта не представляется возможным. Просто умножить сумму «на 2» или «на 10» - вряд ли помогут. Во-первых есть конкуренты. А во-вторых, сколько не закладывай, если нет четкого понимания как управлять – все проестся и все-равно не хватит.
5. Мария Темчина любит цитировать на этом месте афоризм:
- Ты сильный, ты справишься!
- Я умный, я даже не возьмусь!
Это, конечно, хороший ответ. Но часто именно изначально кажущиеся неразрешимые проекты давали бесценный опыт и были потом не просто рентабельны, но и выводили исполнителя на другой уровень развития. Хотелось бы возможных решений, как можно склонить Заказчика к Agiel?
Вопрос: как такие проекты запускать, как общаться с Заказчиком, на какие точки давить. Как донести другой порядок работы?
Как проходил мозговой штурм
Обсудить этот вопрос мы пригласили всех заинтересованных сторон (из сообщества Инфостарта, сообществ РП 1С, выпускников и слушателей курсов и т. п.).
На вебинаре собралось около 100 человек, причем большинство с многолетним опытом (на этой картинке можно посмотреть, кто из участников как оценил свой уровень профессионализма)...
И на онлайн-доске Miro мы попробовали разделиться на несколько команд и провести письменный мозговой штурм - BrainWriting. Кстати, очень рекомендую эту форму - мы часто его практикуем в Agile-команде разработчиков. В отличие от обычного мозгового штурма, когда каждый пытается выкрикнуть как можно больше идей и не всегда прислушивается к мнению других, письменное обсуждение более основательное. Во-первых, стирается преимущество между активными и разговорчивыми участниками и молчаливыми задумчивыми - писать готовы даже те, кто не любит громко говорить. Во-вторых, формат проведения мозгового штурма предполагает, что каждый высказывает одну свою идею, а потом по-очереди знакомится с идеями коллег и пытается придумать, как их идеи можно развить и продолжить. Ну и за счет того, что несколько участников по-очереди развивают и продолжают одну и ту же мысль, получается диалог вместо серии монологов.
Если вы работаете на доске Miro, то там для обсуждения существует удобный шаблон BrainWriting. На первом шаге каждый из участников выбирает свой цвет, и записывает на первом стикере свою идею по рассматриваемому вопросу. Когда все записали идеи, участник перемещается в соседний столбец, читает идею своего коллеги и размышляет, как ее можно развить, продолжить, доработать, улучшить. И в следующей строчке на стикере своего цвета записывает свои мысли. В следующий ход участники опять перемещаются в следующий столбец, и теперь вслед уже за двумя коллегами развивают следующую идею… А в конце автор каждой идеи смотрит вниз столбца, который он начал. И видит, куда идею развили и направили коллеги. Дальше можно выбирать наиболее конструктивные идеи, и можно обсуждать, как их можно применить на практике.
Советы, как уговорить Заказчика
Итак, какие же предложения прозвучали? Какие ходы и аргументы могут помочь “склонить заказчика к гибким методологиям” - то есть к работе “по кусочкам” с постепенным сбором требований и небольшими поставками?
Ниже привожу прозвучавшие идеи с моими комментариями
Совет №1. Познакомить с чужим опытом
Можно продемонстрировать заказчику положительный опыт завершенных проектов с применением гибких технологий. Особенно, если есть список известных компаний, с конкретным описанием историй внедрения - то это может убедить Заказчика создавать и развивать проект гибкими методологиями.
Вообще, если есть возможность показать заказчику портфолио готовых проектов со схожим бюджетом/целями - шансы на успех переговоров заметно возрастают.
Продемонстрировать также недостатки не гибких внедрений (как известно, собрать в начале проекта требования полностью практически невозможно, и на практике реальные желания заказчика часто отличаются от озвученных изначально). Стоит поинтересоваться историей прошлых проектов. Сколько потребовалось времени, какие были сложности. Возможно, заказчик сам признает, что работа по “Водопаду” на практике оказывается куда менее предсказуемой, чем это кажется в момент подписания договора и ТЗ. Если заказчик сам осознает, что требования могут меняться в процессе - убедить его работать по гибким методологиям будет проще.
Совет №2. Лучше один раз попробовать, чем сто раз услышать
Самое сложное - это убедить заказчика, что на самом деле, ни он ни исполнитель не понимают, как должен выглядеть конечный результат. Потому что заказчику по умолчанию всегда “здесь же все понятно”. Для того, чтобы наглядно показать, что неопределенность куда выше, чем заказчик предполагает, полезно подготовить список вопросов, чтобы был очевиден объем неопределенности.
Можно продемонстрировать как происходит работа гибким методом на примере демо-итерации.
Например, можно помочь заказчику избавиться от иллюзии, что он может четко поставить все задачи разработчиком, и полученным продуктом можно будет пользоваться в реальности. Для этого нужно предложить заказчику видеочат совместно с непосредственным пользователем - по какому-то маленькому участку, который нужно автоматизировать:
1. Сначала он ставит задачу (или тот, кто по его мнению в курсе - руководитель среднего звена)
2. Пользователь комментирует эту задачу и описывает все реальные проблемы.
Наглядно будет видна разница. И сразу расхочется “писать полное ТЗ в начале”. Правда, чтобы этот метод сработал, нужно, чтобы были заинтересованные конечные пользователи, а не с реакцией “нас всё устраивает”...
Совет №3. Обеспечить прозрачность
Тот факт, что заказчики часто “в штыки” воспринимают разговоры про возможный разброс в цене связано в первую очередь с недоверием. Поэтому важно не брать цифры с потолка, а показать прозрачный расчет вилки с учетом возможных рисков, влияющих на реализацию проекта. Чтобы было понятно, откуда взялись те или иные цифры.
Стоит внедрить систему управления проектами, например, Jira. И дальше предложить Заказчику контролировать стадии выполнения проекта в системе. Когда разработка из “черного ящика” превращается в понятный и управляемый процесс, вопросов и претензий становится резко меньше (ну, или они становятся более обоснованными).
Совет №4. Объяснить Заказчику, что Agile не увеличивает его риски, а наоборот, снижает
Очень часто страх применять гибкие методы обусловлен ощущением, что это более рискованно. Мол, при внедрении по Водопаду сразу понятен и план, и бюджет, и сроки поставки. А как работать, когда неизвестно в какую сумму внедрение выльется и сколько времени займет. Так вот, ключевая задача при взаимодействии - наглядно объяснить заказчику, что кажущаяся определенность “Водопада” - это иллюзия.
Скажем, добавляя этап моделирования можно в красках расписать Заказчику, что они смогут сразу же попробовать модель в работе. Ну и сразу будет понятно, какие требования сформулированы в формате “я думал будет хорошо, а вышло не очень…”
А при работе по водопаду Заказчику придется утвердить ТЗ на 300-500 страницах и потом все риски на его стороне. Ну а качественно собрать все требования в начале проекта, как мы помним, практически нереально...
Ну и если бюджет больная тема - то можно и на нее надавить, объяснив, что Agile - это еще и способ сэкономить. Стоит заранее объяснить, что в классическом подходе стоимость изменений в конце проекта, как правило, стоит дорого. Так что Agile - это способ сэкономить на ненужных переделках, но получить при этом нужный и ценный результат.
Стоит объяснить, что прототип поможет быстро реагировать на изменения требований и окружение бизнеса. И Цена изменения будет во много раз меньше, чем когда мы 3 месяца проектируем, потом 3-4 месяца настраиваем, а потом уже только получаем результат. Если прототип делается за месяц, то экономия составит почти 6-8 месяцев.
Совет №5. Перейти от общих слов к конкретике. Самый сложный шаг - первый. Выбираем самое важное
Один из распространенных (и понятных) страхов заказчиков перед Agile - страх неизвестности. Важно показать заказчику, что неопределенность будет падать по мере перехода к конкретным работам. Для этого можно выделить замкнутый блок проекта, который удается оценить (например, один внедряемый модуль). Желательно, чтобы это был базовый блок - который можно сделать в начале проекта. Но чтобы ожидаемый эффект для Заказчика был максимальным. И промежуточные результаты можно было сразу использовать в работе. На примере выбранного замкнутого блока продемонстрировать, что возможно реализовать нужный функционал в оговоренные рамки (по срокам и стоимости), и что неизвестность на старте быстро рассеивается по ходу работы. Если выбранный функционал самый “больной”, то Заказчик скорее всего будет рад тому, что этот блок будет готов “быстро”. По результату, возможно, клиент согласится нашей методологией ведения проекта.
Далее можно переходить к другим блокам, обращая внимание на то, что неопределенных моментов по проекту достаточно много. Здесь важно выстроить приоритеты блоков от базового функционала к надстройкам и сервисам.
После первого кусочка дальше эта схема работы будет уже привычной, и ее можно повторять.По ходу итераций придёт понимание стоимости всего проекта. Отдельное преимущество сотрудничества в том, что у заказчика есть возможность прервать процесс улучшения для любого блока (подцели). Заказчик сам может принять решение о том, что "уже достаточно".
Совет №6. Грамотно расставить акценты - не на недостатках, а на достоинствах
Для того, чтобы договориться, необходимо "популярно донести" до заказчика идею гибких технологий. Не акцентировать внимания на том, что не известны сроки и стоимость проекта. Акцент держать на преимуществах и плюсах гибких технологий.
Явным плюсом является скорость поставки. При использовании гибких технологий ценность поставляется итерационно, а значит заказчик может использовать часть продукта до завершения финальных работ. Это удобно, особенно если проект делается в формате “нам этот функционал был нужен еще вчера”...
Ну и со стоимостью и сроками - все-таки речь идет не о полной неопределенности - нужно обговорить некоторую “вилку”. Вилку можно оценить при помощи экспертной оценки проекта. Можно использовать метод трехточечной оценки - когда рассматриваются наиболее вероятная, оптимистичная и пессимистичная точки зрения по стоимости и по срокам, и берется среднее между ними. Практика показывает, что такой прогноз обычно оказывается более точным, чем когда рассматривают только наиболее вероятный вариант развития событий.
Совет №7. Ищите человека, который станет проводником изменений
Вполне возможно, что в культуре организации заказчика пока не говорят про гибкие технологии. Если убедить всех ключевых участников невозможно -попробуйте представителя руководства у Заказчика влияющего на проект и попытайтесь объяснить ему преимущества работы по гибким методологиям.
Найти одного человека, через которого можно “протащить” изменения всегда проще, чем изменить культуру организации в целом. Чтобы работа по Agile “взлетела” - важно найти людей "зажигалок", с активной позицией для уточнения ТЗ и примерной общей оценки, для выдачи более точных рамок разбега. А еще важно найти союзников из управленцев среднего звена - тогда работу удастся реально запустить, и даже есть шанс, что люди будут реально пользоваться продуктом.
Можно предлагать бизнес-заказчику почитать книжку по Scrum - говорят, с некоторыми заказчиками это срабатывает ))). Можно вообще подарить набор книг по управлению проектами при начале работы по проекту.
Можно использовать человеческое любопытство и попробовать уговорить на эксперимент. Мол, для Заказчика это тоже интересный опыт работы “гибкими” методами, который потом можно применить в других сферах. Agile часто вызывает любопытство у тех, кто его не пробовал, ну и отличный повод освоить новую технологию!
Как известно - вода камень точит. Важно постепенно выстроить доверительные отношения с заказчиком. Начинать совместную работу стоит с небольших задач или проектов, а дальше постепенно все уже “притираются” друг к другу. При этом важно показывать свою компетентность - она повышает доверие.
Кстати, иногда стоит избегать слова Agile
Бывают компании, где “гибкие методологии” - слово ругательное (чаще всего по итогам негативного опыта из серии “мы не документируем, у нас Agile”). В такой ситуации можно подробно объяснить, что имеется в виду по сути - например, что мы предлагаем часто встречаться для сверки и корректировки результата. И преподнести метод "под другим соусом". Иногда этого бывает достаточно, чтобы предложение сработало.
Совет №8. Использовать разные методы создания определенности в сфере расходов
Время и материалы. Один из способов добавить определенности в расходы - это перейти на контракт “Время и материалы”. То есть оговориться, что исполнитель выполняет каждый месяц фиксированный объем работ за фиксированную оплату. А очередь заданий как раз можно сделать динамической - то есть изменяемой под текущие запросы/приоритеты. Что важно - динамическая очередь должна оперативно формироваться, редактироваться и быть доступной клиенту онлайн в режиме реального времени
Кстати, можно еще и проговорить, что при уточнении требований задачи будут не только добавляться - . часть ТЗ, возможно, уйдет. Соответственно бюджет будет потрачен более целенаправленно.
Фиксированный бюджет, но плавающий функционал. На самом деле, если бюджет жестко фиксирован - то работать по Agile тоже можно. Вопрос в ожиданиях. Мы не можем сразу четко определить то, что получится в конечном виде. Зато можем гарантировать, что это будет самый важный для заказчика функционал.
Если большие цифры пугают - можно сократить бюджет до минимума. Можно управлять бюджетом проекта, реализуя в первую очередь только самые необходимые требования, чтобы получить работающую модель в минимальной комплектации. Все дополнительные "хотелки" выносим вне рамок проекта. То есть принять решение про расширение бюджета нужно будет не сразу, а когда до них уже дойдет речь. Когда уже есть позитивный опыт сотрудничества (пока реализовывали базовую комплектацию), то если “хотелки” действительно важные - договориться, как правило, удается.
Совет №9. Оговорить в договоре возможность пересмотра параметров проекта при желании обеих сторон
Реальность такова: Заказчик уверен, что он уже на старте знает, что ему нужно. Исполнитель при этом уверен, что по ходу реализации блоков проекта Заказчик передумает (так чаще всего и бывает), и требования будут существенно изменяться. Но убедить в этом Заказчика на старте практически невозможно.
На этом месте Антон, автор кейса дискуссии, предложил следующее решение: в начале создается рамочное соглашение по всем этапам проекта. Но в договор мы обязательно вставляем пункт о пересмотре после каждого выполненного этапа целей всего проекта и результатов по каждому следующему этапу и возможно вообще из изменению, соответственно и возможному изменению как бюджета, так и сроков.
Если Заказчик вдруг скажет, что его требования не изменились - все можно будет оставить как есть. Но по итогам фактической работы и вникания в подробности, скорее всего, Заказчик сам будет заинтересован в добавлении новых требований - и договор должен это допускать.
Кажется, основные идеи на этом всё. Кто дочитал до конца - поделитесь - какие из предложений показались наиболее жизнеспособными, а какие - малореалистичными?
Про второй мозговой штурм (на этот раз проходивший в формате “reverse brainstorming” - то есть мозговой штурм наоборот) расскажу в следующей публикации.
Ну и для тех, кто дочитал статью до конца - еще одно приглашение на курсы по управлению проектами - с актуальным расписанием можно познакомиться на странице курсов Марии Темчиной.
Кстати, нулевой Welcome-вебинар 24 февраля по традиции будет открытым - присоединяйтесь, продолжим практику мозговых штурмов!..
