История, с которой все началось…
Перед нашей командой стояла задача, которую иначе как вызовом не назовешь: перевести сразу несколько кадровых процессов на кадровый электронный документооборот – КЭДО.
Мы IT-компания, гибкая, а тут бюрократия, бумажные процессы, особые требования и консервативная культура госкорпорации. Все как мы любим.
Одним из легких и в то же время сложных, как потом оказалось, процессов был перевод на КЭДО приема на работу. На первый взгляд внедрение портала кандидата казалось нам очень легким и понятным. Мы уже делали внедрение EmplDocs для других компаний, но реальность сразу все поставила на свои места.
Стандартные решения не работали, а заказчик настаивал на автоматизации сложного, нетипового процесса согласования приема нового кандидата до запуска оформления кадровых документов.
Какой вывод мы сделали? Даже знакомый продукт требует нестандартных и уникальных решений.
Критическая роль требований и аналогия с гольфом
Вы когда-нибудь задумывались, почему некоторые проекты достигают невероятного успеха, в то время как другие застревают в тупике? Управление требованиями остается критически важным, но в то же время недооцененным аспектом проектов. Почему это важно?
Первое – статистика. По данным PMI, почти 70% провалов проектов связаны с плохим сбором требований.
Второе – динамика. Требования меняются, а команды сталкиваются с синдромом скользящей дорожки. Постоянные правки, заказчик «в полете переобувается», и все это срывает сроки.
И, конечно, есть личный аспект – умение управлять собой в условиях стресса и перегрузок.
Что отличает победителей от проигравших? Это не технологии, не ресурсы, а что-то гораздо более простое, но в то же время сложное.
Почему простое и в то же время сложное? Потому что люди во все времена искали какие-то магические методы достижения желаемого. Но все гораздо проще. Это как в книге «Монах, который продал свой Ferrari»: главный секрет заключается в простоте, поэтому в него никто и не верит.
Представьте, что управление требованиями – это как игра в гольф. В видео мы увидели, как гольфист сразу, с первого удара, попал в лунку. Классно? А какая связь с управлением требованиями?
У вас есть цель – лунка, и путь к ней извилистый: банкер, вода, деревья. Точно так же с управлением требованиями в IT-проектах. Требования – это наши цели. А путь их достижения – сбор, приоритизация, реализация – это путь к успеху.
Как сделать так, чтобы правильно расставить приоритеты, правильно посмотреть на всю картину и чтобы проект взлетел?
Сбор требований: инструменты и практика
Сбор требований – это первый шаг к успеху. Но как часто мы забываем вовлекать все заинтересованные стороны?
Вначале мы столкнулись с тем, что у каждого подразделения нашего заказчика было свое мнение и свое понимание идеального процесса. Первый соблазн – собрать требования под галочку. Но тогда мы рискнули бы получить какие-то фичи или сам продукт, который вообще никому не нужен.
Что говорит теория и что нам советуют? Мы должны использовать интервью, опросы, вебинары – все, чтобы не пропустить важные детали.
Следующее – техника активного слушания. Здесь я бы хотела выделить три очень важных аспекта:
-
Внимательно относитесь к своим словам. Слушайте без предвзятости, чтобы выявить истинные потребности.
-
Не стройте предположений, а задавайте уточняющие вопросы. Вместо того чтобы додумывать, что имел в виду заказчик или коллега, лучше лишний раз задать уточняющий вопрос.
-
Не принимайте ничего на свой счет. Это помогает сохранить объективность при обсуждении требований и не воспринимать критику лично. Такой подход очень помогает конструктивно выстроить диалог и получить самые важные данные для дальнейшей работы в проекте.
Следующие инструменты – Mind Mapping и Flowcharts. Это визуализация взаимосвязей требований, которая помогает не упустить детали.
И четвертый очень важный пункт – прототипирование и микротребования. Эти инструменты помогают выявлять скрытые потребности и на ранних этапах получать обратную связь, чтобы улучшить дальнейшую работу.
Посмотрим, что сработало у нас в проекте. Мы провели серию интервью, вебинаров, демо-показов с ключевыми пользователями, визуализировали процесс, разбили требования на микротребования и сделали прототип.
Сильно много рассказывать про инструменты, которые можно использовать для разбивки на микротребования, прототипирования либо flowcharts, я не буду. Miro, Figma для прототипирования – все это помогает нам в работе с управлением требованиями и со сбором требований.
Какой вывод мы сделали? Вовлечение всех сторон, активное слушание и визуализация – ключ к тому, чтобы собрать не просто список каких-то хотелок, а реальные требования, которые работают и будут помогать в дальнейшем выпуску продукта.
Но это только начало. Следующий шаг – приоритизация. И вот здесь начинается настоящее искусство.
Приоритизация
Гольфист понимает, что в игре важно оценить расстояние до лунки и правильно выбрать клюшку. В управлении требованиями приоритизация помогает сосредоточиться на критически важных задачах.
Чемпионы – это не только те, кто выигрывает, но и те, кто правильно настраивается на игру. В управлении проектами, в управлении требованиями это означает, что мы должны сосредоточиться на наших целях и правильно ставить приоритеты.
Когда требований много, а ресурсов, как обычно, меньше, чем хотелось бы, важно отличить главное от второстепенного. В нашем проекте это был вопрос выживания.
Есть такой термин – MoSCoW. Его впервые использовал разработчик программного обеспечения Дай Клегг из компании Oracle. Он разработал этот метод, чтобы помочь своей команде приоритизировать задачи разработки и помочь в выпуске продуктов.
MoSCoW разделяет требования по четырем категориям:
-
Must Have – это требования, которые должны быть обязательно. Без этого продукт никак не будет работать, и заказчик не подпишет акты.
-
Следующее требование – Should Have. Это требования, которые должны быть, но их можно реализовать в следующих релизах. Это сильно не будет влиять на качество продукта, но их обязательно нужно реализовать сразу после Must Have.
-
Дальше идут требования Could Have, которые могут быть реализованы только тогда, когда у нас останутся время и ресурсы.
-
И следующее – Won’t Have This Time: сделаем, но не в этот раз. И, может быть, даже об этом забудем. Потому что обычно самые важные требования распределены в первых трех группах: должны быть обязательно, должны быть, а потом все остальное, что можем реализовать только в том случае, когда у нас есть время и ресурсы.
Итак, метод MoSCoW фокусируется на важности и необходимости задач. Но появляется вопрос: как же нам определить, как расставить эти приоритеты, что является Must Have, а что является Should Have?
Для точного определения необходимо задать вопрос: что произойдет, если данное требование не будет выполнено? Если ответ будет: продукт останется работоспособным, но менее конкурентным, значит, это Should Have.
Соответственно, таким образом мы определяем наш поток требований: Must Have, Should Have – и так будем реализовывать. Это то, что говорит нам теория, чтобы помочь в приоритизации задач.
Матрица Эзэнхауэра
Задачи мы приоритизировали. Теперь есть необходимость распределить это все по времени и реализовать. Поговорим про тайм-менеджмент.
Матрица Эйзенхауэра широко используется в бизнес-образовании и входит в программы топовых бизнес-школ в таких курсах, как управление временем, стратегический менеджмент и стратегическое управление.
Матрица Эйзенхауэра помогает разделить задачи на важные и срочные, важные и несрочные, неважные и срочные, неважные и несрочные.
На первый взгляд матрица Эйзенхауэра помогает сосредоточиться на важных и срочных задачах. Однако, если глубже рассмотреть этот метод, эту матрицу, мы поймем, что в первую очередь она делает фокус на важных, но несрочных задачах.
Почему? Важные и несрочные задачи – это наши повседневные задачи, о которых почему-то мы забываем, когда появляются срочные задачи. И неважно, важные они и срочные или неважные, но срочные.
И здесь начинается следующая история. Если в течение долгого времени мы будем говорить «да» задачам из квадранта A или C, то рискуем, что наши повседневные задачи из квадранта B плавно перетекут в квадрант A, станут важными и срочными. Соответственно, начнется паника и тот самый эффект скользящей дорожки.
Поэтому матрица Эйзенхауэра делает фокус на важных, но несрочных задачах, чтобы избежать эффекта скользящей дорожки. То есть делает фокус на наших повседневных задачах, которые мы должны реализовывать в обычном рабочем ритме.
Что сработало в кейсе
Что сработало в нашем кейсе? Как мы начали использовать это у себя?
Мы разделили требования по методу MoSCoW и честно проговорили все это с заказчиком: что критично, а что можно отложить на потом, а что, может быть, даже забыть.
Использовали матрицу Эйзенхауэра для личной эффективности, чтобы не тратить время на неважные, но срочные задачи.
В Must Have мы определили такой функционал, как согласование процесса приема нового кандидата, а в Should Have – такие функции, как автоматические уведомления и напоминания.
Также мы все это визуализировали на доске Kanban. Вывели в swimlane разбивку требований по методу MoSCoW: Must Have, Should Have, Could Have и Would Like. В этих swimlanes, в каждой линии, мы видим наши задачи в соответствии с требованиями.
Дальше, чтобы не терять фокус и держать внимание на важных и несрочных задачах, то есть на наших повседневных задачах, мы в Quick Filters выявили по меткам наши задачи, связанные с требованиями. То есть на доске визуально мы видим, какие требования самые важные по методу MoSCoW и какие из них находятся в повседневной работе.
Какой вывод мы сделали? Четкая приоритизация экономит месяцы работы и тонны нервов. Без этого проект превращается в гольф с закрытыми глазами: вы бьете по мячу, но не видите, куда он летит, и нет никакого результата.
Приоритизация – это не только о том, что важно, но и о том, что действительно нужно вашим клиентам, вашим заказчикам и вам.
И если вы думаете, что метод MoSCoW и матрица Эйзенхауэра только для гольфистов, используйте их в следующем проекте. Попробуйте немного поэкспериментировать, и ваши клиенты это оценят, а коллеги больше не будут спрашивать: «А почему мы это делаем?»
Реализация требований
Теперь реализация. Это этап, когда все становится реальным. Самое интересное – когда все можно щупать.
Когда требования определены и приоритеты расставлены, начинается настоящая работа. Но именно здесь начинается откат назад: появляются новые требования, заказчик снова переобувается в полете, меняются вводные, команда начинает переживать, устает.
Что для этого можно сделать? Что говорит нам теория и что подсказывает?
-
Прослеживаемость требований. Каждое требование должно быть связано с задачами разработки, анализа и тестирования.
-
Управление изменениями. Это прозрачный процесс для оценки и утверждения изменений.
-
И, конечно, Agile-подход: итеративная разработка и корректировка приоритетов, требований.
Как было в нашем кейсе? Мы ввели доску Kanban для визуализации статуса задач в связке с требованиями по методу MoSCoW и важностью и срочностью по матрице Эйзенхауэра.
Сейчас мы видим нашу связку требований с этапами задач. Здесь мы видим взаимосвязь с важностью и срочностью задач, а также разбивку требований по методу MoSCoW. Кроме того, мы видим, на каких этапах находятся наши задачи: анализ, разработка, в разработке, в тестировании.
Таким образом, мы обеспечиваем прослеживаемость этих требований и каждый раз держим фокус на главных повседневных задачах.
Мы регулярно сверяли реализацию с исходными требованиями и использовали Agile-подход для быстрой адаптации к изменениям. У нас итеративная разработка, и каждая задача выполняется в течение двух недель. Это как раз про то, как мы разбили большие требования на микротребования, а по этим микротребованиям уже сделали задачи на каждые две недели.
Какой вывод мы сделали? Гибкость и прозрачность – единственный способ довести проект до конца, когда условия меняются каждую неделю, а может быть, даже каждый день.
Ошибки и инсайты
Какие у нас были ошибки и инсайты? Чему мы научились?
-
Вначале мы не в полной мере вовлекли обе стороны в приоритизацию. Почему-то думали, что мы, зная свой продукт, лучше приоритизируем задачи и лучше все это разработаем. Но это привело к недопониманиям с заказчиком. Теперь мы всегда начинаем с совместного обсуждения.
-
Использование MoSCoW помогло убедить клиента отказаться от лишних и, может быть, даже ненужных требований.
-
И, конечно, визуализация требований позволила не терять фокус и в нормальном ритме выполнять свою работу.
Самое главное – помнить, что ошибки – это не провал, а топливо для роста и развития. Главное – быстро выявить их и честно обсуждать с заказчиком и с командой. Всегда все можно понять, скорректировать свой курс и идти дальше.
Используя эти методы вместе, можно получить взрывную мощность в проектах, силу для работы без усталости, баланс и осознание, устойчивость и гибкость. Это очень важно в управлении требованиями, чтобы в итоге мы получили продукт, который не просто используют, но и любят.
Оставляю маленький чек-лист. Потом можете проверить у себя, есть ли у вас критерии для определения требований и приоритизации:
-
Есть ли у вас четкие критерии для Must Have?
-
Используете ли вы Agile-ритуалы для пересмотра приоритетов?
-
Есть ли у команды инструмент для визуализации требований?
И в заключение хочу сказать, что успех проекта – это не магия и не обычное везение. Это системная, кропотливая работа по управлению требованиями и собой. И здесь секрет прост: вовлекайте людей, честно расставляйте приоритеты, визуализируйте и не бойтесь делать ошибки, а потом их исправлять.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
