Да, а действительно, зачем руководителю проекта брать на себя ещё и задачи по дизайн-мышлению? Руководитель проекта и так занят координацией, ускорением и приоритезацией всего того, что без него не движется.
Написать эту статью меня вдохновил опыт коллег плюс собственная рефлексия руководителя проекта по внедрению SAP eWM (Extended Warehouse Management – система для автоматизации складского менеджмента) и по совместительству конечного пользователя многих других проектов.
В чем основная ценность дизайн-мышления? Эта техника позволяет не забыть простые и практически бесплатные шаги, которые часто упускаются или де-приоритезуются (особенно в больших проектах), но потом очень громко выстреливают во время запуска.
Когда имеет смысл применять дизайн-мышление? В любой ситуации, где есть неопределённость. Набрали неожиданно +NN кг? Работа перестала радовать? Ищете новые идеи автоматизации? Можно попробовать применить дизайн-мышление. Эта методология стала популярной совсем недавно, но многие её инструменты мы использовали в нашей работе уже давно.
В чём же тогда уникальность этой методологии? Дизайн-мышление структурно подходит к процессу создания нового, что позволяет быстро и эффективно приходить к бизнес-результату.
В отличие от традиционного аналитического подхода, когда ставится задача, разрабатываются решения и выбирается лучшее:
методология дизайн-мышления предпочитает фокусироваться на конечном пользователе, быстром создании первого прототипа продукта, например, бумажный экран смартфона, и тестировании этого прототипа с конечными пользователями для получения мгновенной обратной связи:
Таким образом то, что раньше занимало месяцы, теперь можно сделать за один день. Это особенно актуально в нашем быстроменяющемся VUCA-мире.
В Mars мы используем адаптированную методологию дизайн-мышления, состоящую из шести стадий, каждую из которых мы можем подстраивать под конкретную бизнес-проблему.
Предлагаю пройти по всем шагам на примере запуска проекта SAP eWM (мы меняли SAP BIOS на складах наших фабрик от Новосибирска до Ростова-на-Дону). В проекте было понятно ЧТО делать, но оставался вопрос КАК выстроить эффективное взаимодействие команды, которая базируется в разных часовых поясах и уже занимается операционными задачами.
Первая стадия: Frame. Здесь мы определяем реальную проблему, расширяя область поиска через перефразирование проблемы в «Как мы можем…?» и копая вглубь с помощью знаменитых вопросов «Зачем?» и «Почему?». В проекте SAP eWM проблема была изначально понятна: «Как мы можем обойти «грабли» предыдущего проекта и забрать из него всё самое лучшее, чтобы за год запуститься в запланированном бюджете?», поэтому поделюсь другим примером от команды по ИТ-автоматизации, где до проблемы пришлось докапываться (а позже покажу финальные результаты проекта SAP eWM). Изначально команда по ИТ-автоматизации хотела увеличить количество идей, но после трёх «Почему?» ребята поняли, что проблема не в количестве идей по ИТ-автоматизации, а в увеличивающемся потоке запросов, который надо обрабатывать существующими ресурсами. Соответственно, проблема была переформулирована в «Как мы можем найти скрытые резервы в нашей текущей работе?».
Вторая стадия: Explore. Здесь мы выходим из комнаты, ставим себя на место пользователя (проходим его путь пользования/получения опыта) или просто спрашиваем, что ему нравится, что «болит», что работает/не сработало, пытаясь понять истинные потребности пользователя. В проекте SAP eWM мы сделали это в формате рефлексии предыдущего опыта и надежд каждого участника: один страх («грабли») = один стикер, одно пожелание (лучшее) = один стикер, это позволило в дружественной атмосфере проговорить предыдущий опыт и совместно сформировать критерии успеха. В примере с ИТ-автоматизацией мы спрашивали коллег, что им нравится в их работе, а что хотелось бы улучшить. Неважно в каком формате происходит погружение; важно – количество инсайтов, которые собираются в результате.
Третья стадия: Sense-Make нужна для того, чтобы количество инсайтов перевести в качество, обобщить результаты исследования и сформировать наше видение глубинных потребностей пользователя. Я использую группировку похожих инсайтов, также есть техники по созданию персон и карты пути пользователя. Обычно на этой стадии происходит переформулирование изначальной проблемы уже с учётом реальных потребностей пользователей. Например, в проекте SAP eWM изначальная проблема «Как мы можем обойти «грабли» предыдущего проекта и забрать из него всё самое лучшее, чтобы за год запуститься в запланированном бюджете?» трансформировалась в два вопроса: «Как мы можем организовать работу удаленной проектной команды наиболее эффективно, совмещая оперативную и проектную работу?» и «Как мы можем заменить WMS (Warehouse Management System) на фабриках, незаметно для конечных пользователей, четко в срок, наиболее эффективно и результативно с едиными максимально простыми и прозрачными для конечных пользователей процессами, не упуская важные детали и удерживая фокус бизнес-стейкхолдеров?».
Если время на сессию дизайн-мышления ограничено, то первые три шага можно сделать в офлайн подготовке.
Четвертая стадия: Create. Здесь мы начинаем стандартную сессию брейншторма на проблему, определённую на предыдущем шаге, по результатам которой выбираются идеи для воплощения в прототипе.
Прототип – это то, что возвращает нас в детство, когда деньги вырезались из бумаги, а дом строился из стульев и одеяла. Всё это были прототипы реальных ситуаций. В мире дизайн-мышления прототип можно сделать из содержимого мусорной корзины, из того, что ничего не стоит.
Пример прототипа по ИТ-автоматизации:
Пятая стадия: Learn – это тестирование прототипа с конечными пользователя, получение быстрой обратной связи, доработка прототипа с учётом фидбэка и снова тестирование, обратная связь, доработка до приемлемого результата.
Шестая стадия — Pilot: запуск бомбического продукта, ведь пользователи сами участвовали в его рождении, разработке и доработке!
Ещё один плюс дизайн-мышления, в том, что процесс очень гибкий и совсем необязательно проходить все пять шагов. Можно остановить процесс в любой точке или, если это необходимо, зациклить его.
Есть у этого подхода и свои минусы:
Также хочется отметить, что дизайн-мышление – это больше, чем сессия или техника, это мышление руководителя проекта, который понимает нужды конечных пользователей и учитывает их при принятии решений. Конечно, дизайн-мышление не отменяет классические техники проектного управления, и только увеличивает вероятность успешного проекта при наличии необходимых ресурсов.
Ну и как же дизайн-мышление поможет руководителю ИТ-проекта? Из своего опыта и опыта коллег из других регионов я поняла, что дизайн-мышление добавляет новое измерение в проект – конечный пользователь. Чаще всего заказчиком ИТ-проекта является старший лидер или совет директоров компании и проблема, которую решает проект, формулируется на этом уровне совместно с руководителем проекта без учёта опыта конечных пользователей. Обычно проектная команда успешно решает эту проблему при помощи ИТ-инструментов и уже после внедрения все осознают, что теперь необходимо изменить существующие бизнес-процессы, а это может проходить достаточно болезненно для компании.
Привлекая конечных пользователей ещё на стадии формирования проблемы, мы можем «увидеть» проблему старших лидеров глазами реального бизнеса и выбрать более точное и подходящее ИТ-решение.
Привлекая конечных пользователей на стадии дизайна, мы можем понять, как наше ИТ-внедрение повлияет на бизнес-процесс, и инициировать параллельно изменения текущих процессов.
Тестируя вместе с конечными пользователями, мы помогаем им заранее проходить через стадии отрицания, гнева, торга и принятия нового решения, делая их своими амбассадорами ещё до запуска (если коллега говорит, что ребята из ИТ делают классную фишку, то все сразу хотят её попробовать).
В заключение ещё раз хочу напомнить, что дизайн-мышление хорошо работает в ситуации высокой неопределённости, когда как минимум у одного из участников проектной команды есть сознательное желание использовать этот подход и проектная команда (вместе с руководителем) может спокойно выслушать альтернативные точки зрения.
Слушайте с открытым сердцем, смотрите внимательно, говорите с любовью и не забывайте о самом сокровенном желании пользователей: «чтобы оно работало само!»
Написать эту статью меня вдохновил опыт коллег плюс собственная рефлексия руководителя проекта по внедрению SAP eWM (Extended Warehouse Management – система для автоматизации складского менеджмента) и по совместительству конечного пользователя многих других проектов.
В чем основная ценность дизайн-мышления? Эта техника позволяет не забыть простые и практически бесплатные шаги, которые часто упускаются или де-приоритезуются (особенно в больших проектах), но потом очень громко выстреливают во время запуска.
Когда имеет смысл применять дизайн-мышление? В любой ситуации, где есть неопределённость. Набрали неожиданно +NN кг? Работа перестала радовать? Ищете новые идеи автоматизации? Можно попробовать применить дизайн-мышление. Эта методология стала популярной совсем недавно, но многие её инструменты мы использовали в нашей работе уже давно.
В чём же тогда уникальность этой методологии? Дизайн-мышление структурно подходит к процессу создания нового, что позволяет быстро и эффективно приходить к бизнес-результату.
В отличие от традиционного аналитического подхода, когда ставится задача, разрабатываются решения и выбирается лучшее:
методология дизайн-мышления предпочитает фокусироваться на конечном пользователе, быстром создании первого прототипа продукта, например, бумажный экран смартфона, и тестировании этого прототипа с конечными пользователями для получения мгновенной обратной связи:
Таким образом то, что раньше занимало месяцы, теперь можно сделать за один день. Это особенно актуально в нашем быстроменяющемся VUCA-мире.
В Mars мы используем адаптированную методологию дизайн-мышления, состоящую из шести стадий, каждую из которых мы можем подстраивать под конкретную бизнес-проблему.
Предлагаю пройти по всем шагам на примере запуска проекта SAP eWM (мы меняли SAP BIOS на складах наших фабрик от Новосибирска до Ростова-на-Дону). В проекте было понятно ЧТО делать, но оставался вопрос КАК выстроить эффективное взаимодействие команды, которая базируется в разных часовых поясах и уже занимается операционными задачами.
Первая стадия: Frame. Здесь мы определяем реальную проблему, расширяя область поиска через перефразирование проблемы в «Как мы можем…?» и копая вглубь с помощью знаменитых вопросов «Зачем?» и «Почему?». В проекте SAP eWM проблема была изначально понятна: «Как мы можем обойти «грабли» предыдущего проекта и забрать из него всё самое лучшее, чтобы за год запуститься в запланированном бюджете?», поэтому поделюсь другим примером от команды по ИТ-автоматизации, где до проблемы пришлось докапываться (а позже покажу финальные результаты проекта SAP eWM). Изначально команда по ИТ-автоматизации хотела увеличить количество идей, но после трёх «Почему?» ребята поняли, что проблема не в количестве идей по ИТ-автоматизации, а в увеличивающемся потоке запросов, который надо обрабатывать существующими ресурсами. Соответственно, проблема была переформулирована в «Как мы можем найти скрытые резервы в нашей текущей работе?».
Вторая стадия: Explore. Здесь мы выходим из комнаты, ставим себя на место пользователя (проходим его путь пользования/получения опыта) или просто спрашиваем, что ему нравится, что «болит», что работает/не сработало, пытаясь понять истинные потребности пользователя. В проекте SAP eWM мы сделали это в формате рефлексии предыдущего опыта и надежд каждого участника: один страх («грабли») = один стикер, одно пожелание (лучшее) = один стикер, это позволило в дружественной атмосфере проговорить предыдущий опыт и совместно сформировать критерии успеха. В примере с ИТ-автоматизацией мы спрашивали коллег, что им нравится в их работе, а что хотелось бы улучшить. Неважно в каком формате происходит погружение; важно – количество инсайтов, которые собираются в результате.
Третья стадия: Sense-Make нужна для того, чтобы количество инсайтов перевести в качество, обобщить результаты исследования и сформировать наше видение глубинных потребностей пользователя. Я использую группировку похожих инсайтов, также есть техники по созданию персон и карты пути пользователя. Обычно на этой стадии происходит переформулирование изначальной проблемы уже с учётом реальных потребностей пользователей. Например, в проекте SAP eWM изначальная проблема «Как мы можем обойти «грабли» предыдущего проекта и забрать из него всё самое лучшее, чтобы за год запуститься в запланированном бюджете?» трансформировалась в два вопроса: «Как мы можем организовать работу удаленной проектной команды наиболее эффективно, совмещая оперативную и проектную работу?» и «Как мы можем заменить WMS (Warehouse Management System) на фабриках, незаметно для конечных пользователей, четко в срок, наиболее эффективно и результативно с едиными максимально простыми и прозрачными для конечных пользователей процессами, не упуская важные детали и удерживая фокус бизнес-стейкхолдеров?».
Если время на сессию дизайн-мышления ограничено, то первые три шага можно сделать в офлайн подготовке.
Четвертая стадия: Create. Здесь мы начинаем стандартную сессию брейншторма на проблему, определённую на предыдущем шаге, по результатам которой выбираются идеи для воплощения в прототипе.
Прототип – это то, что возвращает нас в детство, когда деньги вырезались из бумаги, а дом строился из стульев и одеяла. Всё это были прототипы реальных ситуаций. В мире дизайн-мышления прототип можно сделать из содержимого мусорной корзины, из того, что ничего не стоит.
Пример прототипа по ИТ-автоматизации:
Пятая стадия: Learn – это тестирование прототипа с конечными пользователя, получение быстрой обратной связи, доработка прототипа с учётом фидбэка и снова тестирование, обратная связь, доработка до приемлемого результата.
Шестая стадия — Pilot: запуск бомбического продукта, ведь пользователи сами участвовали в его рождении, разработке и доработке!
Ещё один плюс дизайн-мышления, в том, что процесс очень гибкий и совсем необязательно проходить все пять шагов. Можно остановить процесс в любой точке или, если это необходимо, зациклить его.
Есть у этого подхода и свои минусы:
- тяжело отцифровать выгоду применения техники;
- часто сессия дизайн-мышления воспринимается, как «отлично провели время» и её результаты скорее всего просто лягут в стол, если нет обязательств о первом демо продукта через 3 недели и пошагового плана с ответственными.
Также хочется отметить, что дизайн-мышление – это больше, чем сессия или техника, это мышление руководителя проекта, который понимает нужды конечных пользователей и учитывает их при принятии решений. Конечно, дизайн-мышление не отменяет классические техники проектного управления, и только увеличивает вероятность успешного проекта при наличии необходимых ресурсов.
Ну и как же дизайн-мышление поможет руководителю ИТ-проекта? Из своего опыта и опыта коллег из других регионов я поняла, что дизайн-мышление добавляет новое измерение в проект – конечный пользователь. Чаще всего заказчиком ИТ-проекта является старший лидер или совет директоров компании и проблема, которую решает проект, формулируется на этом уровне совместно с руководителем проекта без учёта опыта конечных пользователей. Обычно проектная команда успешно решает эту проблему при помощи ИТ-инструментов и уже после внедрения все осознают, что теперь необходимо изменить существующие бизнес-процессы, а это может проходить достаточно болезненно для компании.
Привлекая конечных пользователей ещё на стадии формирования проблемы, мы можем «увидеть» проблему старших лидеров глазами реального бизнеса и выбрать более точное и подходящее ИТ-решение.
Привлекая конечных пользователей на стадии дизайна, мы можем понять, как наше ИТ-внедрение повлияет на бизнес-процесс, и инициировать параллельно изменения текущих процессов.
Тестируя вместе с конечными пользователями, мы помогаем им заранее проходить через стадии отрицания, гнева, торга и принятия нового решения, делая их своими амбассадорами ещё до запуска (если коллега говорит, что ребята из ИТ делают классную фишку, то все сразу хотят её попробовать).
В заключение ещё раз хочу напомнить, что дизайн-мышление хорошо работает в ситуации высокой неопределённости, когда как минимум у одного из участников проектной команды есть сознательное желание использовать этот подход и проектная команда (вместе с руководителем) может спокойно выслушать альтернативные точки зрения.
Слушайте с открытым сердцем, смотрите внимательно, говорите с любовью и не забывайте о самом сокровенном желании пользователей: «чтобы оно работало само!»