Как выглядит процесс принятия решений в ваших командах? Если вам нужно принять совместное, устраивающее всех, решение, то как вы достигаете консенсуса? С какими сложностями сталкиваетесь? Если у вас есть молчуны, то решение принимают самые громкие?

Меня зовут Александра Баптизманская, мы с Евгенией Чумачковой и Оксаной Сливинской работаем Agile-коучами, у нас есть небольшая компания Co-Actors. Сегодня мы научим вас, как при помощи довольно простых фасилитационных техник помочь принять решение группе — не единолично, не демократическим способом и не методом «Два лида договорились». Расскажем, как вовлечь всю группу и провести ее через этот процесс — от генерации идей через споры-обсуждения к выбору решения, которое устроит всех, и достичь консенсуса.

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

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

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

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

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

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

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

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

Миф о групповом принятии решений

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

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

Люди высказываются, идеи множатся, перетекают одна в другую и… повисает молчание. Потому что идеи очень разные, и как договориться — непонятно. Все сидят, иногда смотрят на менеджера: «Что теперь?» Если выйти без решения, то встреча совсем бесполезной будет. Поэтому в итоге самый ответственный человек (или самый громкий в команде, или самый экспертный, или тимлид, или архитектор) принимает решение.

Уровень приверженности этому решению, понятно, будет не очень велик. Если вы были за вариант А, а менеджер выбрал вариант С, то в худшем случае вы будете его саботировать, в лучшем — не очень много в него вкладываться.

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

Зона расхождения

Наверняка вы помните ретроспективы, где принимали решения «писать без багов», «лучше тестировать» или «быть более ответственными». Это всё очевидно, но не работает — потому что эти решения на поверхности и неконкретны.

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

Помогите высказаться всем присутствующим. Потому что обычно говорят несколько громких персон, а остальные свое мнение придерживают: «А вдруг скажу какую-то глупость? Лучше промолчу. Тут умные люди, которые всегда принимают решения — кто я такой».

Зона стонов

Вспомните момент в мозговых штурмах, когда мнений и идей становится довольно много, и некоторые из них — уж очень странные. Обычно люди начинают сразу их критиковать и говорить, что так не сработает. В этот момент они перестают друг друга понимать, потому что это не очень комфортно, когда мнения слишком разные. Кажется, зачем мы здесь собрались, мы вообще команда или где?! В команде появляется разлад, и чтобы этого избежать, менеджер просто принимает решение сам.

Задача фасилитатора на этой стадии — помочь людям услышать друг друга, понять потребности, договориться. Это этап обсуждения и формирования взаимопонимания, всё еще без фильтрации и выбора идей. 

Зона схождения

Это этап выбора идей. Здесь ваша цель, как фасилитатора — помочь людям отфильтровать идеи из множества вариантов, которые проявились. Приоритезировать их и выбрать те, что устраивают всех для движения дальше. А также вам нужно убедиться, что все в команде готовы дальше это решение тащить, следовать ему и за него бороться. Только здесь можно начинать сходиться, голосовать и выбирать. В конце концов это и поможет вам принять решение.

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

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

Фасилитация на практике

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

Шаг 1. Расходящееся мышление

Этот этап может вам показаться слишком простым, но не спешите делать выводы. Всё, что вам с командой нужно делать здесь — это в течение двух минут записывать свои идеи на стикерах и наклеивать их на лист, при этом ничего не обсуждая. Если что-то совсем непонятно, то, конечно, можно задать вопросы. Но кроме этого, ничего не критикуем, не фильтруем и не обсуждаем — просто генерим идеи.

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

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

Цель этапа: нагенерировать много идей по обсуждаемому вопросу.

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

Чего не делать: не обсуждать, не критиковать, не фильтровать идеи.

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

Шаг 2. Формирование взаимопонимания 

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

Каждому участнику нужно коротко представить свою идею, например: 

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

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

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

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

  • Возить людей в Сочи. Или альтернатива — весь Питер со всеми людьми перенести в район Сочи. Или выдавать путевки на Бали.

  • В первую очередь я задумалась, как этот период влияет на физиологию и психику. Поэтому предлагаю обеспечить всех льготными ультрафиолетовыми лампами, чтобы у них витамин Д вырабатывался. Также мелатонин можно бесплатно выдавать. Еще можно телу помочь через абонементы в банях и на психотерапию. 

  • Раздать денег.

После того как всем идеи стали ясны, предложите их сгруппировать. Есть ли среди них похожие? Какие можно переместить поближе друг к другу и соединить кластеры? Объедините в кластеры то, что хорошо объединяется, например:

  • Кластер привнести в город цвета — это идеи про яркую одежду и елки. Можно добавить зимние праздники и стрит-арт.

  • Кластер про праздники: бочки с глинтвейном и зимние праздники с огоньками.

  • Про здоровье и помощь телу: мелатонин с психотерапией, бани, ультрафиолетовые лампы.

  • Кластер про поездки в теплые места: две идеи про Сочи — вывозить в Сочи и скидки на билеты, к ним можно добавить про путевки в теплые страны. 

  • Остальные идеи настолько разные, что не группируются. 

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

Важно! Обводите кластеры так, чтобы их размеры были одинаковы — это подчеркнет что маленькие кластеры имеют такой же вес, как и большие. Иначе у людей может возникнуть впечатление, что из-за большого размера кластер важнее. Важно учитывать и одинокие стикеры, потому что гениальные идеи иногда представлены в одиночном формате.

Важно, чтобы кластеризовала группа, а не фасилитатор. Который не настаивает, а просто следит за процессом и помогает. Если вы будете делать это сами, то группа кивнет, но ее уровень приверженности сильно упадет. Не совершайте эту ошибку. Даже если люди поначалу не хотят вставать и идти к флипчарту перетаскивать бумажки — будьте настойчивы, просите их самостоятельно объединить идеи. Скажите: «Ребята, группируйте, а я отхожу». Так они понимают, что у них нет никаких вариантов.

Если они все же никак не вовлекаются и сидят со страдающим выражением лица, то имеет смысл уточнить, насколько для них актуален вопрос. Возможно, эта тема нужна только вам или кому-то одному из них, и тогда странно ждать от людей вовлеченности. Можно задать фрустрирующий вопрос: «Ребята, вы так активно генерили идеи, но совсем их не кластеризуете — в чем дело? Поясните, странная динамика, очень любопытно!»

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

Все гениальное просто, поэтому мы предлагаем очень простую матрицу 2х2 с двумя разрезами: 1. Эффективно/неэффективно и 2. Дорого/дешево:

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

Цель этапа: Хорошо понять позицию каждого (суть, аргументацию, потребности).

Чего НЕ делать? Не критиковать, не фильтровать идеи.

Техники: представление своих идей, раунд вопросов, кластеризация и матрицы.

Что делает фасилитатор? Помогает взаимопониманию: услышать и понять людям друг друга. Задает вопросы, чтобы люди лучше поняли друг друга. Пресекает критику и попытки отфильтровать идеи. 

Шаг 4. Сходящееся мышление 

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

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

Чтобы рассчитать нужное количество точек для голосования, представьте себя участником. Обычно хватает 3-4 точек, потому что две — маловато и будет сложно выбрать, а шесть — многовато, всё будет в точках. Если стикеров очень много, то можно дать пять точек. Если кластеров не очень много, то можно и две.

Вы, как фасилитатор, подведите итоги: каким кластерам отдано больше всего голосов? Если при голосовании получилось одинаковое количество точек, то можно выдать еще одну и предложить второй тур. Если и после этого вы не договорились, то вернитесь на предыдущий пункт, где обсуждали, почему это важно и почему это хорошая идея. Возможно, после этого все смогут сойтись во мнении.

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

  1. Категорическое «за» — большой палец вверх;

  2. Категорическое «против» — большой палец вниз;

  3. Средняя позиция. Она очень важна, и не означает «мне всё равно». Она звучит как «может быть, у меня есть идея получше, но я ОК, ответственность разделяю, готов, подписываюсь, беру».

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

Дальше опросите тех, кто опустил палец вниз. Есть ли что-то, что можно поменять в этом решении, чтобы выбор был хотя бы нейтральным, чтобы человек был хотя бы не против? Это один из самых конструктивных вопросов фасилитатора, а вовсе не «почему человек против», и «критикуешь — предлагай» (есть такое поверье). И по нашему опыту — самый быстрый способ прояснить потребность человека.

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

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

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

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

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

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

Завершение. План действия

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

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

Если после утверждения плана действий кому-то пришла другая идея или в общей ситуации произошли изменения, то для поправок запускается новая итерация. 

Вишенкой на торте может стать сбор обратной связи. Например, о том, как встреча прошла. Было ценно было или нет? Соответствует ли инвестированное во встречу  время тому выхлопу, который люди получили? 

Цель этапа: Прийти к решению, которое устраивает всех.

Чего HE делать? He принимать решение большинством. Не принимать одному человеку решение за группу.

Техники: Dot voting и Consensus check.

Что делает фасилитатор? Применяет техники. Помогает договориться.

Выводы

Мы с вами прошли по шагам все три этапа встречи: 

  1. Сначала сделайте мозговой штурм на стикерах, где вся команда выскажет свои идеи;

  2. Потом как фасилитатор, помогите группе договориться и понять друг друга, кто что имел в виду;

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

Главные мысли:

  • Лидерство не в том, чтобы вести за собой, а в том, чтобы растить команду.

  • Люди вовлечены, когда они чем-то владеют и могут принимать решения.

  • Постепенно втягивайте команду в принятие решений.

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

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

Наш мастер-класс на эту тему на конференции TeamLead Conf 2021:

17-18 мая на площадке из двух этажей Крокус-Экспо встретятся 2000 тимлидов и руководителей со своим опытом, инсайтами и энергией. Расписание конференции TeamLead Foundation 2022 уже готово, а купить билеты можно здесь.

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

Комментарии (14)


  1. azzas
    11.04.2022 10:42
    +6

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


    1. ArchimeD
      11.04.2022 12:35
      +1

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


      1. andreyverbin
        11.04.2022 21:12

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


        1. Yozi
          12.04.2022 09:55

          Пример: новая фича, вывести данные фичи в админку

          Нужно:

          • распарить данные внешнего источника (какой-нибудь гос.базы тендеров или продуктов)

          • Обработать данные, извлечь нужное, что-то посчитать

          • Правильно сохранить в бд

          • Предоставить фронту API

          • Удобно и красиво это отрисовать

          Совещающиеся:

          • Дата сайнтист - знает что извлечь из внешней бд, что посчитать на основе этих данных

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

          • По отрисовке нужен дизайнер.

          • Ещё нужен фронтендер которому получать данные из API и делать то что сделал дизайнер.

          Тут, конечно, есть задачи где не надо совещаться (фронтендер и бэкендер сами свой код пишут).

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

          Что обсуждать:

          • А удобна ли предложенная схема API и фронту и бэку, удастся ли с такой схемой сделать приятное для пользователя приложение? (Мне тут неделю назад без совещаний втихую запили супер апишку, где каждое поле формы обновляется отдельным запросом. Пачкой в транзакции не обновить).

          • То что нарисовал дизайнер - это удобно делается на фронте, или странная не очень нужная хотелка, увеличивающая срок реализации в разы?

          • А на бэке? Как мне это считать и хранить? Как синхронизировать? Почему так? А можем по-другому считать?

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

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

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

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

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


          1. andreyverbin
            12.04.2022 13:10

            Эта команда первый раз выводит данные в админку? Если нет, то у них уже есть архитектура и каждый должен знать что делать. То есть решено, что данные от датасаентиста идут в эту трубу в таком формате. А бек их хранит в реляционной БД и отдаёт через GraphQL апи на фронт. И так далее. Никому вообще разговаривать не надо, обо всем уже договорились на уровне архитектурных решений. Если же архитектуры нет, то садится архитектор, с каждым экспертом по отдельности говорит и принимает ключевые решения - про трубу от саентиста, про реляционную БД и про GraphQL. После чего команда работает без мозговых штурмов.

            Согласования нужны, но не в такой форме. Датасаентист лично объяснит беку, что означают данные, которые он шлёт. Ещё лучше если из произведённых им артефактов будет сгенерирована документация, которую бек понимает.

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

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


            1. Yozi
              12.04.2022 14:42

              Идут в трубу в таком то формате

              Это новая фича, формата ещё нет.

              GraphQL

              Это протокол, описание API ещё предстоит разработать

              Садится архитектор

              Фулстек фронт-бэк-дизайнер-аналитик? Который станет бюрократичным бутылочным горлышком для любого мелкого согласования? И будет эдаким почтальоном Печкиным.

              Такое, наверное, работает в кровавом энтерпрайзе с waterfall и большими сроками. В более гибких командах так не принято.

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

              Если же не в камне, то будут правки - надо обсуждать.

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


              1. andreyverbin
                13.04.2022 00:08

                >Такое, наверное, работает в кровавом энтерпрайзе с waterfall и большими сроками. В более гибких командах так не принято.

                Вообще-то нет, при чем тут waterfall? Я говорю простую штуку - ничего хорошего на совещании придумать нельзя. Потому что болтание языком и думание головой несовместимы между собой, хоть с фасилитатором, хоть без. Статья же такой пример приводит - накидаем идей, обведём кружочками на флипчарте и споём реквием здравому смыслу.


            1. Yozi
              12.04.2022 14:49

              Мне думается что это максимально похоже на плановую/рыночную экономики.

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

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

              Если на заводе чего-то не хватает - партия не доработала, бывает. Завод не виноват, ему думать не полагается, есть план.


          1. UnclShura
            13.04.2022 11:44

            Пример отвратительный и, как правильно сказали тут, тривиальный. Обсуждать тут нечего. Ну сделали кривое API ну и что? Один другому дал по башке и все поправили. Вы лучше расскажите как "фасилитировать" когда три команды подчиняются разным менеджерам, у каждой своей работы полно, план на год в перед, а тут пришел такой генератор идей и хочет странного. Вроде и работы на неделю, но надо-ж слгласовать. Ни одна из команд не берет на себя координацию - никому из них фича не сдалась. Никто не хочет ее в план вставлять - все-ж расписано на год. И начинается... "мы обсудим внутри команды", "у нас нет ресурсов", "это вообще не наша команда делать должна", "мы готовы, но сначала дайте нам...", "вот будет ТЗ, тогда и поговорим" и им подобное.

            Я про то, что фаза нытья будет точно, а вот фазы консолидации может и не наступить вовсе. И вроде все согласны, всем понятно чего делать, и времени займет не много, но... Помимо того кто сказал, что "общее" решение будет прямо реально общим и всех устраивать? Оно будет устраивать тех кто за, быть достаточно хорошим для тех, кому все равно и не устраивать тех, кто против. А вот если реально работу работать надо именно тем, кто против, то будь он хоть один против 20, будет он если и не несчастен, то "топить" за решение точно не будет.

            То, что вы описали - это самый обычный брейнсторминг. Только применяется он не для рядовых вещей, а для поиска решения, которого никто по-отдельности не видит, для проблемы, которая ранее не решалась никем. Т.е. для нетривиальных вещей. Вот именно тут и надо разных специалистов (включая уборщицу - на полном серьезе!).


            1. Yozi
              13.04.2022 23:35

              Эм, не, я не за брейншторминг топлю. Мне такой сумбур как раз тоже не заходит

              Мой коммент был именно к

              Разработка это индивидуальный вид спорта

              про то, что всё сделать один человек не может и не должен (его ресурса не хватит).

              нужно взаимодействие между исполнителями и делегирование.

              Возможно меня несколько понесло выше и я не донёс эту мысль...

              _____

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

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

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


              1. andreyverbin
                14.04.2022 02:52

                Разработка это индивидуальный вид спорта

                Раскрою мысль. Два программиста не придумают решение проблемы в 2 раза быстрее, скорее даже все замедлится. Но два программиста могут написать программу в 2 раза быстрее если будут работать по общему плану, определят зоны отвественности, модули, интерфейсы между ними. То есть каждый будет пилить свой кусок и не мешать другим.


    1. amakhrov
      12.04.2022 04:04

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

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

      После «фасилитации/фасилитатора» полностью читать статью перехотелось

      Да, стремноватая калька. Но смысл ясен - кто-то, кто ведет обсуждение. Председатель? На суть статьи это не влияет - там все по делу.


  1. funca
    11.04.2022 18:04
    +1

    Спасибо, статья фактически эталон как рассказывать про коучинг: с теорией, практикой и совсем немножко рекламы. :)


  1. amakhrov
    12.04.2022 04:13
    +1

    Мы используем подобный подход для приоритезации тех долга в команде. Только первая фаза - генерация идей - у нас асинхронная (и порой довольно растянутая во времени): перед митингом все могут добавить свои идеи в общий список.