Какую проблему мы пытаемся решить?
Представьте, что вы снова сидите на том самом организационном совещании и жуете то самое вкусное печенье. Но теперь уже идет второй день, когда перед командой стоит один из руководителей высшего звена и излагает фактическую цель проекта примерно в таком духе:
«Нам нужен новый сайт. Нам нужно улучшить информирование о наших услугах по доставке хлеба. Вот список функций, которые нам, исходя из результатов конкурентного анализа, необходимо добавить. Так что до праздника наша жизнь будет весьма насыщенной».
«Мы собрались здесь, чтобы выбрать и внедрить новую систему биллинга для нашего финансового отдела. Она должна быть готова к третьему кварталу, прежде чем мы подготовим большинство счетов».
«Генеральный директор отправился в оздоровительный центр, и теперь он хочет, чтобы мы разработали программу здорового питания для всех сотрудников».
Команда получает неявное послание: «Это очень важная работа. Всем ясно, для чего мы собрались. Цель поставлена. Давайте поторапливаться». Однако в подобных ситуациях мы редко задаем важный вопрос: почему на самом деле этот проект реализуется? И еще вопрос, непосредственно связанный с предыдущим: какую проблему мы пытаемся решить?
Организации инициируют проекты не для достижения целей, а для решения проблем.
Обратите внимание на цель первого проекта. Генеральный директор, по сути, определил три критических бизнес-проблемы, которые, если их не решить в следующем квартале, могут погубить компанию. Сайт как инструмент обладает определенным потенциалом для удовлетворения подобных потребностей, но является ли он решением? Сосредоточена ли команда на этих проблемах и помогает ли сайт решить их? Ведь именно так должно быть.
Теперь давайте рассмотрим вторую цель проекта. Биллинговую систему компании необходимо как можно скорее обновить, поскольку база данных, на которую она опирается, постоянно дает сбои и выставляемые клиентам счета полны ошибок. Поможет ли данный проект решить эту проблему? Сможет ли новая биллинговая система полностью устранить ее? Или через год вам придется собираться снова, чтобы исправить ситуацию?
Мы называем такое организационное поведение поиском решения (solutioning). Все отдается на усмотрение команды. Вот что нужно сделать, а как именно — сами разбирайтесь. С виду это вроде самостоятельность, но на самом деле — просто выполнение приказа. Причем изначально неясно, позволит ли предлагаемое решение устранить основную проблему.
Исходное формулирование проекта может обеспечить его успех или провал, и не только для вашей команды, но и для всех, кого вы пытаетесь привлечь к работе в своей организации. Прежде чем говорить о целях проекта с командой, нужно понять, какие проблемы требуют устранения. Команды более ответственно подходят к работе, когда могут точно определить проблемы, которые нужно решить. В идеале вы должны воспринимать эти проблемы как «свои» в той же мере, что и решения, которые ваши команды будут придумывать, тестировать и реализовывать.
Приведенные ниже алгоритмы позволят вам научиться формулировать проблемы вместе с командами перед началом проектов. Вы также научитесь собирать информацию об известных и неизвестных факторах, которые могут влиять на проект.
Алгоритм
«Какую проблему мы пытаемся решить?»
Проблемы — это обобщенные образы, создаваемые людьми. Чтобы у команды возникла мотивация к действиям, необходимо понять проблему и четко, пословно, сформулировать ее. В самом начале проекта нет оснований полагать, что все участники понимают проблему, которую вы пытаетесь решить. Чтобы составить из отдельных элементов полное представление о проблеме и определить диапазон вариантов ее решения, нужно использовать видение и опыт каждого, даже если вы уже провели широкомасштабные исследования и выполнили работу, требующую беготни. Без четкого видения перспективы у каждого члена работа команды осложнится. Если вы не можете ясно представить другим проблему и подкрепить ее необходимой информацией, вряд ли кто захочет помогать вам в ее решении.
Этот алгоритм показывает общекомандный подход к постановке проблем. Он позволяет каждому внести вклад и правильно определить, кого вы обслуживаете и кто выигрывает от результатов коллективной работы. Важно понимать, что проблемы бизнеса и проблемы клиентов это не одно и то же и предлагаемый подход к постановке проблем помогает командам различать то и другое, ничего не упуская из виду. В большинстве случаев команды формируются для решения проблем бизнеса, а эти проблемы зачастую доходят до команды уже в «обертке» готового решения, предполагающего, например, создание нового сайта или обновленной биллинговой системы. Приведенные ниже рекомендации помогают командам препарировать готовое решение, определить, откуда оно взялось и кто от него реально выигрывает. Это позволяет командам принимать более обоснованные решения относительно того, что нужно делать и почему.
Шаблоны для постановки проблем достаточно часто используются в бизнес-сообществе. Ниже представлена наша версия, отчасти опирающаяся на книгу Майкла Шраге «Гипотеза новатора» (The Innovator’s Hypothesis):
Рассмотрим каждый из этих элементов более подробно.
Кого мы обслуживаем?
- Группа людей. Люди, которых мы обслуживаем, создавая для них нечто полезное в ходе реализации данного проекта. Чем точнее вы определите эту группу, тем лучше. Для одной команды она может быть внешним потребителем, в то время как другая команда может разрабатывать решение для внутреннего клиента, которое не предназначено для представления его общественности. Каждая команда обслуживает свою группу потребителей.
- Конкретная проблема. Проблема, которую определенная группа людей пытается решить.
- Данная ситуация. Определяется местом и временем возникновения конкретной проблемы.
- Желаемый результат. То, чего хочет группа людей и чего она пока не получает. Именно на этом должна сосредоточиться команда. Она должна точно определить, как именно будет достигаться этот результат.
Кто выигрывает?
- Наша команда. Люди, которые работают над проектом.
- Результат проекта. То, что позволяет команде считать проект успешным (с точки зрения результативности).
- Группы людей. Конкретные группы людей, которые выигрывают от реализации проекта. Это могут быть сотрудники вашей организации, потребители или клиенты, которых вы обслуживаете, или и те, и другие.
- Показатель успеха. С его помощью команда определяет, достигнут успех или нет. При отсутствии какого-либо измеримого показателя вы вряд ли сможете доказать своей организации, что выполнили поставленную задачу.
Вот пример полной постановки задачи.
1. Выясните мнения членов команды о том, кого вы обслуживаете
Поместите первую схему этого алгоритма в таком месте, где ее смогут видеть все. Попросите членов команды перечислить элементы, которые, по их мнению, должны стать частью первой половины постановки проблемы. Попросите записать соображения на стикерах, чтобы их было легко размещать на схеме и перемещать.
2. Поделитесь своими соображениями
Попросите членов команды поделиться тем, что они считают нужным занести в каждую колонку. Разместите их стикеры в соответствующих колонках. Каждый может назвать несколько элементов.
3. Решите, что необходимо включить в постановку проблемы
Всей командой проанализируйте информацию и обсудите, что необходимо включить в первую половину постановки проблемы. Начните с первой колонки, т.е. с определения конкретной группы людей, которая будет обслуживаться. При переходе от первой колонки ко второй привлеките всех членов команды к разработке первого, чернового варианта постановки проблемы. Когда команда решит, какие элементы необходимо включить в постановку проблемы, запишите их, прежде чем продолжить работу.
4. Повторите этот процесс для второй половины постановки проблемы
Когда команда закончит эту работу, постройте вторую схему для алгоритма. Как и в первом случае, попросите членов команды индивидуально подумать над тем, кто выигрывает от вашего проекта, и записать соображения. Затем огласите эти соображения, разместите соответствующие стикеры и завершите постановку проблемы.
Формулировки могут существенно повлиять на то, как команда определит суть проекта, поэтому прочитайте каждую половину постановки проблемы несколько раз, чтобы убедиться, что она приемлема, точна и логична.
Не удивляйтесь, если после второй половины постановки проблемы придется внести коррективы в первую половину.
Процедура «Пересмотр постановки проблемы»
Ваше определение проблемы и того, что команде нужно сделать, — это всего лишь первоначальная гипотеза. Далее мы покажем, что по мере реализации любого проекта понимание проблем, подлежащих решению, изменяется. Например, вы можете получить новую информацию, доказывающую ошибочность некоторых элементов первоначальной постановки проблемы. В случае появления такой информации поделитесь ею с командой и выделите несколько минут, чтобы команда повторно проанализировала постановку проблемы. Коллективно решите, что необходимо изменить, и обсудите, как это повлияет на реализацию проекта.
Процедура «Использование постановки проблем при тестировании решений»
Всякий раз, когда команда генерирует идеи или тестирует их в рамках проектов, обращайтесь к постановке проблемы и используйте информацию, полученную в ходе экспериментов.
Алгоритм
«Что мы знаем? Что нам нужно узнать?»
Бывают проблемы, которые легко объяснить и устранить. Например, если команда — это сотрудники мастерской по ремонту компьютеров, то проблемы клиентов, которые вам приходится решать, обычно ясны и имеются четкие процедуры их диагностики и устранения.
Но чаще всего командам приходится решать не столь очевидные, сложные и просто непонятные проблемы. Может случиться так, что в начале реализации проекта члены команды не обладают знаниями, позволяющими четко формулировать соображения, не говоря уже о четкой постановке проблемы, позволяющей правильно распределить усилия.
А если ваша команда занимается инновационной или изобретательской деятельностью, то весь проект может быть посвящен выявлению проблем, которые необходимо решить. В таких случаях у команды обычно нет очевидных представлений о потребностях клиентов или о пригодности той или иной технологии.
Если какая-либо из этих гипотетических ситуаций имеет отношение к вам и вашей команде, попробуйте для начала использовать данный алгоритм. Он помогает командам правильно ставить вопросы в начале проекта, предлагать более точные гипотезы для принятия решений в ходе реализации проекта и моделировать желательное поведение членов команды на протяжении всего проекта. Мы также используем этот алгоритм, когда приходится вносить изменения в первоначальную постановку проблемы. В частности, для инновационных команд вопросы, возникающие по ходу выполнения этого алгоритма, становятся движущими факторами при запуске проекта.
Это упражнение взято из описания процесса, представленного в докладе «Презентация презентации» (Presentation Presentation) Майка Круженицки на интерактивной дизайн-конференции HOW в Сан-Франциско, Калифорния, в 2014 г.
1. Опишите то, что вы уже знаете, и то, что вам нужно узнать
Запишите два приведенных ниже вопроса так, чтобы их могли видеть все члены команды. Попросите индивидуально ответить на них. Если проект сложный, попросите команду подготовить ответы заранее. Подчеркните, что есть множество причин, по которым вы можете чего-то не знать, но лишь немногие из них плохо отражаются на команде.
Что мы знаем о проблеме?
Это информация или данные, на которые команда будет ссылаться на протяжении всего проекта.
Что нам нужно узнать о проблеме?
Это пробелы в информации или данных о проблемах, которые вы пытаетесь решить. Если команда привыкла обсуждать данные с точки зрения надежности, используйте соответствующую терминологию, особенно когда известно, что данные неконфиденциальны, устаревшие или ненадежные. Например: «Какая информация по этой проблеме высоконадежна?»
2. Поделитесь своими взглядами
Разместите схему этого алгоритма так, чтобы все могли ее видеть. Присвойте двум колонкам заголовки «Что мы уже знаем?» и «Что нам нужно узнать?». Попросите членов команды поделиться ответами и поместите их в соответствующие колонки.
3. Идентификация предположений
Начните с левой колонки. По каждому пункту спрашивайте команду: «Как убедиться в том, что это правда?» Если команда признает, что данный элемент в списке достоверен, то на него можно опираться в ходе реализации проекта. Если команда не уверена в достоверности, переместите элемент в правую колонку.
4. Формулирование вопросов, на которые команда должна ответить
Представьте каждый элемент в правой колонке в виде вопроса. Спросите членов команды, на какие из вопросов нужно ответить в первую очередь. Потом сообща решите, кто будет заниматься поиском ответов для всей команды.
Поместите результат выполнения этого алгоритма в таком месте, где он будет доступен членам команды. Со временем он может стать местом размещения текущих записей о том, что команда узнала по ходу реализации проекта.
Процедура «Уточнение предположений по окончании каждого этапа проекта»
Мы рекомендуем командам повторно выполнять этот алгоритм по окончании каждого этапа проекта, поскольку представления о том, чего вы пытаетесь достичь, со временем изменяются.
Вперед, к успеху! Стоп, а это что такое?
Теперь у команды определена проблема, которую нужно решить, и целевая группа, которую нужно обслуживать. Вроде бы все готово, можно начинать работу. Правда, есть одна небольшая закавыка: как команде определить, все ли она делает правильно? Следующий раздел поможет вам выбрать универсальные количественные критерии успеха, пригодные для всех и учитывающие различные программы, приоритеты и потребности сотрудников в вашей организации.
