Нашел для изучения новые мега-листинги опенсорсных проектов, комиксы и книги по теме открытых разработок. Сегодня хотел бы поговорить о управленческом фреймворке, который разработали и передали в 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 положены четыре фазы:

1. Концептуализация. Эта фаза подразумевает постановку проблемы, оформленную простым и лаконичным языком (и описанную максимально детально). Это важно, поскольку не все возможные варианты её решения могут быть доступны. Еще один важный шаг — назначить ответственных за принятие последующих решений. Кто возьмёт на себя финансовую сторону вопроса, кто будет координировать действия команды — все для обеспечения прозрачности и исключения недопонимания.

2. Анализ и планирование. Эта фаза включает исследование и сбор данных о проблеме и организации. Члены команды Red Hat отмечают, что на этом этапе важно устранять барьеры для участия. Ещё одна задача этапа — собрать первую обратную связь и продумать, как работать с теми, кто будет недоволен новой инициативой.

3. Разработка и тестирование. Здесь — помимо формулирования гипотеза и вариантов решений — необходимо сосредоточиться на поиске релевантных единомышленников. Также важно предусмотреть каналы, по которым они смогут оставить обратную связь — сделать так, чтобы они видели, что их мнение учитывается. Если идея или обратная связь того или иного коллеги ценная и её планируется использовать — нужно будет отметить, кто её автор.

4. Запуск. Наконец, наступает этап реализации принятых решений (в виде модификации процессов или внедрения инструментов). Здесь важно показать, как был учтен полученный фидбек на предыдущих этапах. Если у команды остались какие-либо опасения, их необходимо проработать. В некоторых случаях может потребоваться дополнительные встречи или даже новый цикл ODF.

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

Дополнительное чтение на выходные: опенсорсные проекты, комиксы и книги.