Как превратить бизнес-заказчиков и разработчиков в единую команду?

26.05.22

Управление продуктом - Продуктовый подход

Один из подходов, который помогает найти с бизнес-заказчиком общий язык и организовать сотрудничество – это использование принципа бережливой разработки (Lean Development). На митапе «Сбор требований и составление ТЗ» директор по проектам Инфостарта Мария Темчина рассказала, как с помощью этого принципа наладить взаимодействие с заказчиком, и показала практические инструменты, которые удобно применять при сборе требований.

Мне нравится подход дизайн-мышления, который говорит про то, что возможность попробовать что-то сделать – ценнее, чем тысячи слов, чем много разговоров. Поэтому давайте сначала рассмотрим типичные проблемы работы с требованиями, разберемся, как найти общий язык и организовать сотрудничество с заказчиком. А потом попробуем с вами на практике посмотреть, как работает инструмент сбора требований – Lean Requirements Workshop.

 

Я думаю, что подавляющее большинство со мной знакомо. Я пишу статьи, провожу вебинары, провожу курсы.

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

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

Именно с этим связано то, что управление требованиями – это самая больная тема в проектах, гораздо более проблемная, чем формальные вещи, процедуры или технологии.

На слайде показаны результаты опроса руководителей проектов Инфостарта про то, какие темы в проджект-менеджменте самые больные, самые сложные, самые проблемные. Практически все признали, что тема требований самая острая, самая актуальная.

 

 

В подавляющем большинстве проектов работа с требованиями – это непросто.

 

 

Мне удалось собрать довольно значимую подборку разных кейсов проектов внедрения 1С, а также других ИТ-проектов.

Повторюсь, я уже несколько лет веду на Инфостарте курсы по управлению проектами, их прошли уже несколько сотен слушателей, мы там обязательно разбираем разные истории проблемных внедрений.

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

 

Типичные проблемы работы с требованиями

 

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

 

 

Большинство проблем с требованиями возникает из-за того, что заказчики не до конца понимают, что им нужно.

Они могут составить техническое задание из одной-единственной фразы. Или мне как-то показывали техническое задание в виде листа бумаги, на котором была изображена какая-то совершенно непонятная схема (весь расчерканный), и гордо было сказано: «Вот вам ТЗ – пожалуйста, работайте!»

 

 

Еще одна проблема связана с тем, что требования постоянно растут, их количество постоянно увеличивается.

Мне очень понравился образ, что требования заказчика растут со скоростью размножения осколков атомных ядер в ходе неуправляемой ядерной реакции. Действительно, мы часто с этим сталкиваемся.

 

 

Заказчики искренне считают, что знают, что им нужно. До тех пор, пока разработчики не дают им ровно то, что они просили.

Типичная история, когда говорят: «Давайте выстраивать бизнес-процесс по регламенту компании». А потом выясняется, что по этому регламенту никто не работает. Да действительно в компании есть регламент, но он чисто на бумаге, и поэтому смысла в бизнес-процессе, который выстроен по регламенту, нет.

 

 

Ну и, конечно, в конце проекта заказчик в гораздо большей степени готов дать точные требования, чем в начале.

 

 

Среди разных представителей заказчика очень часто возникает ситуация, что их требования противоречат друг другу.

Роль владельца продукта (продукт оунера) обычно воспринимается как единая точка входа требования. Но на моей практике очень часто бедные разработчики, бедные аналитики приходят к одному представителю заказчика – он говорит, что нужно. А потом приходят к другому, он говорит, что нужно прямо противоположное.

Что с этим делать – совершенно непонятно.

 

 

Взаимодействие заказчиков и разработчиков не всегда конструктивно.

Я помню, как успокаивала в какой-то момент аналитика, который очень устал от общения с бухгалтерией, и объясняла, как можно улучшить обстановку. Аналитик попробовал вместе с бухгалтером попить кофе – это немного улучшило обстановку.

То есть взаимодействие не всегда получается хорошо.

 

 

И когда уже доходит до внедрения, до перехода на новую систему – очень часто возникает саботаж, потому что переходить становится слишком сложно, и само внедрение проваливается в том числе по этой причине.

 

Как найти общий язык и организовать сотрудничество

 

 

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

 

Конечно, это гораздо проще сказать, чем сделать. Но один из подходов, который нам может в этом помочь – это использование принципа бережливой разработки (Lean Development).

Принцип бережливой разработки подразумевает, что мы держим фокус внимания:

  • на людях;

  • на том, чтобы выстроить процесс оптимальным образом;

  • и на том, чтобы подходить к продукту как к некоей целостной системе.

 

 

Этап сбора требований – тот самый момент, когда мы в наибольшей степени можем реализовать эти принципы бережливой разработки:

  • В первую очередь, мы должны ликвидировать потери – поставить себя на место пользователя и понять, какая функциональность ему нужна в первую очередь. В качестве примера: «Зачем вам нужен этот отчет?» – «Нам нужно узнавать из него такую-то информацию». Поэтому мы лишнего делать не будем, а только добавим в старый отчет новую колонку.

  • Встраивать качество – потому что мы можем понимать, как мы будем принимать, уже при создании определения технического задания.

  • Создавать знание – то есть содержимое ТЗ могут определять разработчики вместе с бизнес-заказчиками (пользователями).

  • Откладывать необратимые решения – принимать решения по ходу.

  • Доставлять быстро – выдавать реализацию маленькими кусочками (тот же самый MVP).

  • Рассматривать ситуацию в целом.

  • И быть готовым воспринимать точку зрения собеседника.

 

 

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

 

Lean Requirements Workshop – это совместное обсуждение требований с командой разработки и заказчиком по методике бережливого управления

Что мы делаем:

  • мы собираем в одном месте бизнес-заказчиков, пользователей, исполнителей – погружаем всех в процесс;

  • воспроизводим, как у нас будет выглядеть реальная работа пользователей;

  • и получаем на выходе разностороннюю информацию о продукте – то, что нам нужно.

В реальности такой воркшоп занимает, как минимум, несколько часов, но у нас на обзорное знакомство с его инструментами будет меньше часа.

 

 

Мы с вами рассмотрим четыре компонента, которые можно использовать в рамках совместного обсуждения требований.

  • Во-первых, мы составим так называемый устав продукта – не путайте с уставом проекта! Это некая формулировка, зачем вообще нам то, что мы делаем, для чего это нужно. Это то самое понимание цели, которое нам нужно сформулировать, прежде чем мы приступим к работе.

  • Следующий момент – мы создадим портрет пользователя, поймем, кто же будет пользоваться этим продуктом.

  • Составим карту пути пользователя – как пользователь будет использовать продукт

  • Составим карты пользовательских историй – user story map, то есть посмотрим, какие функции должны быть у продукта, и каков приоритет тех или иных функций.

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

Но когда у нас предполагаются доработки со сложной неочевидной архитектурой, то попытка в начале проекта всем вместе собраться и договориться, сэкономит нам много времени после. Это позволит убрать или минимизировать большую часть тех проблем, которые я озвучила – сложности в договоренностях, непонимание, как работает система и т.д.

 

 

В рамках обсуждения требований мы с вами нарисуем карту пользовательского пути – как пользователь проходит по пути в рамках использования продукта.

 

 

И сформируем карту пользовательских историй, где соберем детальную информацию по всем функциям, которые нам нужны от системы.

 

Практикум

 

Инструменты Lean Requirements Workshop мы рассмотрим на примере проекта внедрения электронного документооборота некоей условной компании, которой система документооборота нужна для реализации проектного управления.

Работать будем на доске Miro.

 

Устав продукта (Product Charter)

 

Первый инструмент – «Устав продукта», позволяет посмотреть на решаемые проблемы широко, заранее предметно оценить желаемые результаты внедрения.

 

 

Вспомните любое внедрение, которое у вас недавно проходило, или, например, планируется сделать:

  • В левой колонке напишите, про какой продукт идет речь.

  • В соседней колонке ответьте на вопрос: «В чем текущие проблемы?» Потому что обычно мы запускаем какое-то внедрение, когда у нас либо возникла какая-то проблема, либо мы столкнулись с какой-то возможностью. Озвучиваем эту проблему или возможность.

  • В третьей колонке пишем, какое у вас видение итогового результата.

  • И в последней колонке запишите ответ – как мы можем измерить успех.

Для работы над любым продуктом очень важно ответить на эти вопросы, потому что без понимания, зачем мы что-то делаем, мы получаем очень странные результаты. Это больная тема на многих проектах.

Очень часто внедрение идет по принципу: «А давайте мы внедрим вот этот программный продукт». А «Зачем? Почему? Какие цели? Что мы хотим получить в результате?» совершенно никого не интересует. «Ну как же, мы такая большая организация, у нас нет ERP. Конкуренты внедрили, нам тоже нужно».

 

Роли пользователей (Users, roles, and flow map)

 

Рассмотрим следующий компонент – «Роли пользователей». Поскольку продукт создается для людей, перед началом разработки нам важно разобраться, кто будет пользователями продукта, какие у них цели и опасения.

 

 

Нам нужно разобраться:

  • какие роли могут использовать продукт – напомню, мы внедряем ЭДО для проектного управления;

  • какие пользователи могут быть по отношению к той или иной роли;

  • какие цели для каждой роли (что пользователи хотят получить в результате использования продукта?);

  • какие риски для каждой роли (что может помешать пользователям добиться своих целей?);

  • какие мотиваторы для каждой роли (зачем пользователи пытаются добиться своих целей?).

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

  • представители высшего руководства;

  • РП, работающие с внутренними заказчиками;

  • РП, работающие с внешними заказчиками;

  • представители заказчиков;

  • начальники отделов;

  • роль наблюдателя, предоставляющая доступ только на чтение – внешние подрядчики, аудиторы и т.д.;

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

Ниже выделим отдельную дорожку, и запишем, какие пользователи будут представлять каждую из ролей – в нашем случае это будут условные названия должностей, которые представляют эту роль.

А в дорожке еще ниже – какие у представителей этих ролей цели.

Например, какие цели у руководителя проекта, работающего с внешними заказами? Что ему может быть нужно от электронного документооборота?

  • отчетность в разных разрезах (статус, ФИО, заказчик);

  • возможность отслеживать сроки и бюджет (превышение и т.д.);

  • возможность лицам, принимающим решения, принимать решения вне офиса;

  • отбор данных в различных разрезах;

  • уменьшение количества заявок в техподдержку и претензий.

В следующей дорожке мы перечислим риски – чего боится руководитель проекта.

  • это утечка информации;

  • потеря данных всей базы.

И еще ниже – какие у руководителя проекта мотиваторы:

  • быстрое получение наглядной информации с графиками;

  • удобство видеть стадию договора.

 

Карта пользовательского пути (User Journey Map)

 

Сейчас давайте попробуем пройти по карте пути пользователя.

 

 

Колонки карты представляют собой этапы и шаги процесса, который мы рассматриваем. Поскольку мы рассматриваем электронный документооборот применительно к проектному управлению, мы смотрим, что у нас происходит с проектом – по сути, мы смотрим жизненный цикл проекта. Он состоит из этапов:

  • Инициация – на этом этапе у нас появляется заявка на проект, она согласуется, принимается решение, подписываются документы

  • Реализация – этап, на котором проект реализуется,

  • Архив – после реализации проект уже попадает в архив, откуда можно запросить и получить информацию по этому проекту.

 

 

Строки этой таблицы – это разные роли в нашем проекте.

Давайте посмотрим, что будет происходить в рамках нашего проекта. Например, как будет пользоваться электронным документооборотом руководитель проекта со стороны заказчика. На этапе инициации в карте его пользовательского пути можно отметить шаги:

  • инициация согласования протоколов (она не часто встречается, но здесь она появляется);

  • согласование таких документов как бизнес-кейс;

  • разработка и согласование параметров устава проекта также на инициации;

  • далее приказ о составе проекта и формирование рабочих групп;

  • согласование и инициация – это согласование бюджета проекта;

  • регистрация плана проведения при согласовании с рабочими группами;

  • согласование технического задания.

Мы с вами уже плавно переместились по горизонтали на этап реализации. Далее, на этапе реализации, если мы используем документальное сопровождение проекта, у нас будут шаги:

  • подписание и регистрация договора, если этот проект с внешними подрядчиками;

  • регистрация плана проекта;

  • анкетирование, интервью и согласование результатов с пользователями рабочих групп;

  • протоколы совещаний;

  • фиксация требований и ограничений – чем больше моментов у нас будет зафиксировано в общей системе на старте работы, тем меньше у нас потом будет конфликтов из серии: «Я этого не говорил».

  • согласование частного технического задания или технического проекта, методологических решений – все это тоже можно пропускать через документооборот;

  • утверждение актов выполненных работ.

После завершения разработки и подписания актов выполненных работ у нас появится работа с проектом в архиве:

  • хранение архивных документов;

  • поиск документов;

  • хранение шаблонов и так далее.

 

Карта пользовательских историй (Story Map)

 

Следующий инструмент – это карта пользовательских историй.

 

 

Благодаря докладу Ивана Селиверстова вы уже знаете, как формировать пользовательские истории для команды – мы смотрим, какие у нас есть требования и дальше их детализируем.

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

Ниже, на уровне задач пользователя, укажем, что пользователи хотят делать с информацией в системе:

  • вносить;

  • собирать;

  • выводить;

  • хранить сканы и т.д.

Ниже, на уровне конкретных пользовательских историй, укажем, что при сборе информации нам для каждого документа нужно учитывать:

  • статус;

  • ответственных;

  • бюджет;

  • сроки оплаты.

А с точки зрения работы с документами у нас следующие пользовательские истории:

  • работать с версиями – хранить историю изменений;

  • иметь возможность возвращаться к версии.

Карта пользовательских историй детализирует бизнес-требования к системе до конкретных пользовательских историй:

  • на верхнем уровне у нас конкретные бизнес-цели;

  • дальше идут задачи пользователя,

  • и дальше детализируем задачи – что конкретно нужно сделать, чтобы пользователь мог достичь своей цели.

Давайте полностью заполним уровень целей для нашего проекта внедрения документооборота. Итак, у наших пользователей относительно системы есть цели:

  • учитывать информацию;

  • ограничивать доступ;

  • маршрутизировать согласование;

  • применять аналитические инструменты;

  • обучать пользователей – проводить обучение, проводить проверку знаний;

  • иметь систему уведомлений – например, напоминания о необходимости согласовать;

  • интегрироваться с другими информационными системами. Например, нам нужно обеспечивать передачу информации в Галактику и из Галактики, синхронизировать данные в системах.

И дальше можно спускаться ниже и накидывать пользовательские истории.

Результат работы на воркшопе можно посмотреть на доске Miro.

Я всем рекомендую попробовать эти инструменты в реальности и призываю делиться впечатлениями в комментариях.

 

Вопросы

 

Какой уровень детализации мы должны использовать при заполнении карты пользовательских историй? Как далеко на этом этапе заходим?

Здесь мы применяем тот самый метод «набегающей волны», о котором говорил Иван Селеверстов – заходим на тот уровень детализации, какой нам актуален сейчас. Ближайшие события мы планируем подробно, а далекие мы планируем приблизительно.

На карте пользовательских историй мы можем планировать сразу несколько релизов.

  • В верхнюю дорожку пользовательских историй у нас войдет то, что называется MVP – Minimum Viable Product. Здесь мы будем детализировать возможности и расписывать их подробно.

  • А ниже будет уже второй релиз, в него мы с вами перенесем некоторые дополнительные пользовательские истории – их пока не будем прорабатывать подробно.

То есть сначала мы смотрим общую картинку, а потом начинаем эти пользовательские истории приоритизировать по ближайшим релизам. И то, что мы планируем внедрить в ближайшее время, мы детализируем уже шире и точнее.

Какую роль в Lean Requirements Workshop играют представители разработки?

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

Если бы бизнес-заказчики лучше понимали архитектуру системы, они бы четче формулировали требования, и, наоборот, если бы разработчики лучше понимали бизнес-процессы, они бы выдавали более корректный результат.

Требования действительно должны писаться совместно, поэтому все участники процесса важны, взаимодействие между разработчиками и заказчиками должно быть выстроено. Нужно задавать правильные вопросы и как-то направлять движение, обращать внимание на моменты, на которые не обращали внимание ранее.

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

Поэтому озвучивать возможные проблемы, наводить, наталкивать на какие-то мысли – это идеальный вариант, когда у нас получается действительно совместное обсуждение.

Это не всегда просто, потому что мы действительно говорим на разных языках, и на взаимодействие нет времени, на него не хватает мотивации. Взаимодействовать не всегда получается. Но когда получается, результат нам нравится.

Основное, к чему я хочу вас призвать по итогам воркшопа – это попытаться организовать взаимодействие, создать некую единую команду из разработчиков, заказчиков и пользователей, чтобы получать именно тот результат, который нужно.

Получается, что разработчики на встрече нужны, чтобы приземлять требования пользователей, спускать их на землю из «космоса»?

Совершенно верно, причем один из способов приземления требований я только что показала на карте пользовательских историй – у нас планируется несколько релизов, и мы обязательно это сделаем, но не в первом релизе. И дальше уже при переходе к следующему релизу возникает вопрос, а нужно ли это делать.

Как избежать типичной ситуации, когда разработчики в роли советников становятся единственным источником знаний, в итоге вся постановка задачи переносится на разработчиков?

Поэтому я и говорю, что здесь очень важно, чтобы было взаимодействие. И как раз очень ценно, что на встрече присутствуют представители заказчика, и именно они озвучивают требования. Как раз важно, чтобы не было крена – ни в одну, ни в другую сторону.

Кому интересно больше узнать о проектном управлении – приглашаю на мои курсы на Инфостарте.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Сбор требований и составление ТЗ: современные подходы в управлении проектами".

См. также

Личная эффективность Продуктовый подход Работа с заинтересованными сторонами Бесплатно (free)

В шестом выпуске третьего сезона подкаста Радио “Аналитик“ обсудили траектории развития бизнес-аналитика и варианты для перехода в другую роль. Подробно рассмотрели переход в продуктовый менеджмент, обсудили, какие особенности нужно учитывать и какие навыки необходимо развивать, чтобы перейти в новую роль.

18.11.2024    257    0    Radio_Analyst    0    

1

Продуктовый подход Кейсы продуктов Бесплатно (free)

В пятом выпуске третьего сезона подкаста Радио “Аналитик“ обсудили, что важно знать и уметь аналитикам для работы с 1С:ERP, поговорили про историю развития 1С:ERP и планы на будущее.

08.11.2024    340    0    Radio_Analyst    0    

3

Продуктовый подход Бесплатно (free)

В четвертом выпуске третьего сезона подкаста Радио “Аналитик“ обсудили, что такое метрики, для чего они нужны в B2B и B2C приложениях и как с ними работать.

21.10.2024    310    0    Radio_Analyst    0    

5

Коммуникации Продуктовый подход Бесплатно (free)

Когда в экосистеме много продуктов, каждый из них развивается согласно своему роадмапу. При появлении интеграционного проекта у смежных команд будут разные приоритеты, которые часто нельзя подвинуть. Как оценить риски продукта в интеграционном проекте, можно ли влиять на смежные команды, и как планировать сроки реализации, рассмотрим в статье.

25.07.2024    536    0    user1142961    0    

3

Продуктовый подход Программист Россия Бесплатно (free)

Статья является попыткой доступно объяснить принцип открытости/закрытости (Open-Closed) из SOLID в контексте разработки ПП на платформе 1С:Предприятие.

14.05.2024    1053    0    EvgeniyOlxovskiy    7    

4

Продуктовый подход Бесплатно (free)

При запуске нового продукта нужно проверить идею на прочность, оценить ваши возможности и определить позиционирование среди целевой аудитории. Расскажем о том, какие инструменты могут в этом помочь.

09.02.2024    1572    0    comol    0    

10

Продуктовый подход Бесплатно (free)

Производство продукта обходится дорого, и иногда вы можете потратить большое количество времени и ресурсов, человеческих сил, но не получить на это спрос от клиента. О том, как балансировать в «поле сил», собирая необходимую информацию от «агентов влияния», попадать в ожидания клиента и успевать подготовить продукт в условиях ограниченного времени, пойдет речь в статье.

22.01.2024    1201    0    user1075439    8    

5

Продуктовый подход Бесплатно (free)

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

17.11.2023    1256    0    user1949771    0    

7
Оставьте свое сообщение