Не «я решил», а «давайте обсудим» — Open Decision Framework
Нашел для изучения новые мега-листинги опенсорсных проектов, комиксы и книги по теме открытых разработок. Сегодня хотел бы поговорить о управленческом фреймворке, который разработали и передали в open source специалисты Red Hat.
В его основе лежит идея о том, что значимые решения в организации следует принимать открыто и с участием тех, кого они затрагивают. Так коллеги будут лучше понимать, почему значимы те или иные изменения, и чего стоит ждать.

The Open Source Way
ODF зародился в недрах Red Hat. Это — одна из первых крупных компаний, построенная по принципам «The Open Source Way». В их основе — прозрачность, сотрудничество и меритократия. Кстати, с позиции менеджмента данные принципы раскрыты в книге «The Open Organization» Джеймса Уайтхёрста, возглавлявшего Red Hat более десяти лет.
Но если в двух словах, решения в «открытом» формате принимаются сообща, а не спускаются сверху в духе «начальник сказал — подчинённый сделал».
Подход сформировался по мере роста самой Red Hat, когда традиционные методы управления дали сбой. С переходом на распределённые команды стало сложнее планировать и обсуждать задачи. Кроме того, динамично менялась иерархия, что приводило к перекидыванию вопросов между специалистами. Чтобы решить эту проблему, в Red Hat и перешли на открытое обсуждение проблем и инициатив.
Так родился ODF — сначала как внутренний инструмент для управления проектами, а позже — как универсальный фреймворк. В 2016 году компания Red Hat передала его в open source под лицензией CC-BY-SA 4.0. Фреймворк можно найти здесь.
От непрозрачного и предвзятого…
Обычно ключевые решения в организациях и командах принимают «наверху» — руководители анализируют ситуацию, выбирают стратегию и спускают её вниз. Проблема в том, что менеджеры часто не видят всей картины: они могут не знать о проблемах на местах или попасть в ловушку собственных когнитивных искажений. Кстати, последний вопрос поднимали специалисты McKinsey еще в 2010 году. Топ-менеджеры и стратеги действительно редко учитывают системные ошибки мышления в своей работе.
К ним можно отнести предвзятость восприятия (confirmation bias) — склонность искать аргументы «за» свою идею и игнорировать «против» — или эффект сиюминутности (saliency bias), когда люди придают непропорциональное значение новой информации. Причем, чем опытнее руководитель, тем выше шансы, что он будет опираться на аналогии, искать похожие паттерны в ситуациях, с которыми он сталкивался в прошлом. Если что-то сработало раньше, кажется, что сработает и сейчас. Но все это — лишь ошибка мышления.

Конечно, это не значит, что руководители считают свои решения идеальными. В том же исследовании McKinsey опросили более 2 тыс. топ-менеджеров, и только 28% назвали качество решений в своих компаниях «хорошим». 60% признали, что плохие решения принимаются так же часто, а 12% и вовсе заявили, что хорошие решения — редкость.
Можно предположить, что открытый процесс принятия решений мог бы улучшить ситуацию. Хотя здесь все же необходим баланс — не все решения должны приниматься единолично, но и не все нужно обсуждать коллективно. Грубо говоря, сотрудникам бухгалтерии возможно не стоит вмешиваться в стратегию маркетинга, если речь не идет о продвижении бухгалтерской компании.
… к понятному и открытому подходу
Интересный пример по части операционных решений приводит инженер и профессор Стэнфордского университета Джон Аустерхаут. У себя в блоге он описывает процесс анализа результатов собеседования сотрудников в компании Electric Cloud. После интервью все, кто общался с кандидатом, собирались на обсуждение. Каждый отмечал преимущества и недостатки соискателя в общей таблице. Если кто-то соглашался с замечанием коллеги, то напротив соответствующей графы ставилась галочка (если не соглашался, то крестик). Затем проводилось общее голосование.
В итоге участники команды могли высказать свои опасения и пожелания, а также убедиться в том, что их мнение учтено. Из «минусов» — на обсуждение требовалось время, но результаты — как отмечает Аустерхаут — были хорошими.
Другой пример, который приводит Аустерхаут, назывался Blink Test. Его использовали, когда было необходимо собрать как можно большее количество мнений сотрудников — например, при выборе названия продукта или функции. Вариант писали на доске и спрашивали у случайных коллег: «Что первое приходит в голову?». За час собирали десятки реакций — (как минимум) это помогало избежать неочевидных ассоциаций.
Что предлагает ODF
Это — сбалансированный подход: в обсуждения вовлекают тех, кого затрагивают те или иные изменения. В результате снижается вероятность ошибок, генерируется больше идей, появляется больше возможностей их проверить, растет вовлеченность команды.
В открытой дискуссии лучшие идеи естественным образом получают поддержку, независимо от того, исходят они от сеньора или джуна. Такой подход снижает риски принятия ошибок из-за «эффекта начальника», позволяет проверить больше гипотез.
Если коротко, то в основу ODF положены четыре фазы:
-
Концептуализация. Эта фаза подразумевает постановку проблемы, оформленную простым и лаконичным языком (и описанную максимально детально). Это важно, поскольку не все возможные варианты её решения могут быть доступны. Еще один важный шаг — назначить ответственных за принятие последующих решений. Кто возьмёт на себя финансовую сторону вопроса, кто будет координировать действия команды — все для обеспечения прозрачности и исключения недопонимания.
-
Анализ и планирование. Эта фаза включает исследование и сбор данных о проблеме и организации. Члены команды Red Hat отмечают, что на этом этапе важно устранять барьеры для участия. Ещё одна задача этапа — собрать первую обратную связь и продумать, как работать с теми, кто будет недоволен новой инициативой.
-
Разработка и тестирование. Здесь — помимо формулирования гипотеза и вариантов решений — необходимо сосредоточиться на поиске релевантных единомышленников. Также важно предусмотреть каналы, по которым они смогут оставить обратную связь — сделать так, чтобы они видели, что их мнение учитывается. Если идея или обратная связь того или иного коллеги ценная и её планируется использовать — нужно будет отметить, кто её автор.
-
Запуск. Наконец, наступает этап реализации принятых решений (в виде модификации процессов или внедрения инструментов). Здесь важно показать, как был учтен полученный фидбек на предыдущих этапах. Если у команды остались какие-либо опасения, их необходимо проработать. В некоторых случаях может потребоваться дополнительные встречи или даже новый цикл ODF.

В Red Hat используют ODF не только для управления проектами, но и при стратегическом планировании. Однако, как и любая методология, она не универсальна. Авторы выложили фреймворк в том виде, в котором он используется внутри компании, поэтому можно ожидать, что его нужно будет немного адаптировать для своей организации.
Дополнительное чтение на выходные: опенсорсные проекты, комиксы и книги.
Автор: dmitrykabanov