Comments 14
После «фасилитации/фасилитатора» полностью читать статью перехотелось сразу.
Фасилитация нужна как раз для того, чтобы не хорошенечко трындеть по любому поводу, а исключительно по делу, и потратить на это времени не больше необходимого, так то.
Разработка это индивидуальный вид спорта. Решения принимает одна голова. Не встречалось мне хороших решений, разработанных и принятых на совещании. Брейншорм-подобный процесс из статьи не работает. В реальности нужно документацию почитать, прототипы собрать, поговорить с теми, кто подобное делал. Каким образом это все на флипчарт поместить и сделать за час я не знаю.
Пример: новая фича, вывести данные фичи в админку
Нужно:
распарить данные внешнего источника (какой-нибудь гос.базы тендеров или продуктов)
Обработать данные, извлечь нужное, что-то посчитать
Правильно сохранить в бд
Предоставить фронту API
Удобно и красиво это отрисовать
Совещающиеся:
Дата сайнтист - знает что извлечь из внешней бд, что посчитать на основе этих данных
Ведущий бэкендер - с него информация о том как парсить, реализовать эффективно то что сделал датасайнтист, хранить в бд, реализация API
По отрисовке нужен дизайнер.
Ещё нужен фронтендер которому получать данные из API и делать то что сделал дизайнер.
Тут, конечно, есть задачи где не надо совещаться (фронтендер и бэкендер сами свой код пишут).
Но вот всё что на стыках - это придется обсуждать, если только у вас не фулстек фронт-бэк-дизайнер-аналитик.
Что обсуждать:
А удобна ли предложенная схема API и фронту и бэку, удастся ли с такой схемой сделать приятное для пользователя приложение? (Мне тут неделю назад без совещаний втихую запили супер апишку, где каждое поле формы обновляется отдельным запросом. Пачкой в транзакции не обновить).
То что нарисовал дизайнер - это удобно делается на фронте, или странная не очень нужная хотелка, увеличивающая срок реализации в разы?
А на бэке? Как мне это считать и хранить? Как синхронизировать? Почему так? А можем по-другому считать?
Ой, в дело ещё вступил сисадмин и с ним ещё придется обсуждать какие бд и как можно использовать, где хостить парсеры. А то тут какие-то требования по безопасности, сертификации, бюджеты.
Наконец, и бэкендер с фронтендером у нас не в единственном числе. Оказывается что на фронте есть ведущий разраб который радостно запили архитектуру апишки, но вопросы по дизайну он как-то привык делегировать бывшему дизайнеру-верстальщику, а теперь мидлу-разработчику. У него тут экспертизы внезапно больше.
Короче, я к чему, то что в статье обсуждается, это не про собрать 20 человек, включая уборщиц, в одной комнате и за час решить. Это серия совещаний, на каждом несколько заинтересованных человек.
Правильно организовать такие группы для совещаний - задача сама по себе.
Ещё и результаты работы этих групп координировать. Тут, допустим,некий ответственный за фичу в целом. И этот ответственный не мог за всех вышеперечисленных диктовать все условия.
Эта команда первый раз выводит данные в админку? Если нет, то у них уже есть архитектура и каждый должен знать что делать. То есть решено, что данные от датасаентиста идут в эту трубу в таком формате. А бек их хранит в реляционной БД и отдаёт через GraphQL апи на фронт. И так далее. Никому вообще разговаривать не надо, обо всем уже договорились на уровне архитектурных решений. Если же архитектуры нет, то садится архитектор, с каждым экспертом по отдельности говорит и принимает ключевые решения - про трубу от саентиста, про реляционную БД и про GraphQL. После чего команда работает без мозговых штурмов.
Согласования нужны, но не в такой форме. Датасаентист лично объяснит беку, что означают данные, которые он шлёт. Ещё лучше если из произведённых им артефактов будет сгенерирована документация, которую бек понимает.
Команда это не там где совещания, дружба, жевачка. Команда там где люди согласованно работают, не тратя время на согласование. Представьте футбольную команду, много ли они времени тратят на совещания и фасилитацию на футбольном поле? У них есть «архитектура» - план на игру и каждый профессионал знает что делать и знает как этот план можно адаптировать. Без совещаний.
Совещания это отличный способ быстро принимать непродуманные решения и нести коллективную ответственность, то есть не нести не вовсе.
Идут в трубу в таком то формате
Это новая фича, формата ещё нет.
GraphQL
Это протокол, описание API ещё предстоит разработать
Садится архитектор
Фулстек фронт-бэк-дизайнер-аналитик? Который станет бюрократичным бутылочным горлышком для любого мелкого согласования? И будет эдаким почтальоном Печкиным.
Такое, наверное, работает в кровавом энтерпрайзе с waterfall и большими сроками. В более гибких командах так не принято.
Всё таки задача архитектора - дать направление и контролировать, что всё делается согласно общей задумке, а не прописывать в камне каждый пункт до мелочей.
Если же не в камне, то будут правки - надо обсуждать.
Вообще, архитектору из вашего примера неплохо было бы научиться делегировать.
>Такое, наверное, работает в кровавом энтерпрайзе с waterfall и большими сроками. В более гибких командах так не принято.
Вообще-то нет, при чем тут waterfall? Я говорю простую штуку - ничего хорошего на совещании придумать нельзя. Потому что болтание языком и думание головой несовместимы между собой, хоть с фасилитатором, хоть без. Статья же такой пример приводит - накидаем идей, обведём кружочками на флипчарте и споём реквием здравому смыслу.
Мне думается что это максимально похоже на плановую/рыночную экономики.
Партия владеет всей информацией по всем заводам и, конечно же, лучше знает как правильно и эффективно распорядиться ресурсами. Если заводам что-то надо, они идут к партии и обсуждают каких им запчастей нехватает. Партия пишет план, всё довольны. Между собой заводам общаться не надо, вредно. Ещё план нарушат идеальный.
Тем более что ассортимент давно известен, всем понятно какие трубы надо делать и из чего. Архитектура считай известна.
Если на заводе чего-то не хватает - партия не доработала, бывает. Завод не виноват, ему думать не полагается, есть план.
Пример отвратительный и, как правильно сказали тут, тривиальный. Обсуждать тут нечего. Ну сделали кривое API ну и что? Один другому дал по башке и все поправили. Вы лучше расскажите как "фасилитировать" когда три команды подчиняются разным менеджерам, у каждой своей работы полно, план на год в перед, а тут пришел такой генератор идей и хочет странного. Вроде и работы на неделю, но надо-ж слгласовать. Ни одна из команд не берет на себя координацию - никому из них фича не сдалась. Никто не хочет ее в план вставлять - все-ж расписано на год. И начинается... "мы обсудим внутри команды", "у нас нет ресурсов", "это вообще не наша команда делать должна", "мы готовы, но сначала дайте нам...", "вот будет ТЗ, тогда и поговорим" и им подобное.
Я про то, что фаза нытья будет точно, а вот фазы консолидации может и не наступить вовсе. И вроде все согласны, всем понятно чего делать, и времени займет не много, но... Помимо того кто сказал, что "общее" решение будет прямо реально общим и всех устраивать? Оно будет устраивать тех кто за, быть достаточно хорошим для тех, кому все равно и не устраивать тех, кто против. А вот если реально работу работать надо именно тем, кто против, то будь он хоть один против 20, будет он если и не несчастен, то "топить" за решение точно не будет.
То, что вы описали - это самый обычный брейнсторминг. Только применяется он не для рядовых вещей, а для поиска решения, которого никто по-отдельности не видит, для проблемы, которая ранее не решалась никем. Т.е. для нетривиальных вещей. Вот именно тут и надо разных специалистов (включая уборщицу - на полном серьезе!).
Эм, не, я не за брейншторминг топлю. Мне такой сумбур как раз тоже не заходит
Мой коммент был именно к
Разработка это индивидуальный вид спорта
про то, что всё сделать один человек не может и не должен (его ресурса не хватит).
нужно взаимодействие между исполнителями и делегирование.
Возможно меня несколько понесло выше и я не донёс эту мысль...
_____
А в вашем примере про три команды с разными менеджерами отсутствует владелец фичи. Исполнители есть, а ответственного нет, все отказываются под разными предлогами. Непорядок. Тут до разработки то дело не дойдет, разработчикам обсуждать даже нечего ещё. Мои комменты выше были уже к ситуации когда ресурсы имеются, за работу взялись, только что именно делать непонятно. И что это не должен решать один человек, в силу ограниченности его ресурсов (по времени, в основном).
В истории про три занятых команды по идее нужен некий владелец фичи (знает какой нужен результат и отвечает за него).
А его задача уже определить исполнителей (те три отдела), найти им ресурсы для выполнения задачи и контролировать процесс. Если ресурсов всё равно нет, то кто-то ответственный раздул скоуп задач больше чем возможности команд. Вопросы к составителю плана, надо решать, переприотеризировать задачи, что-то двигать в очередности или исключать из плана (что-то старое или эту новую задачу, смотря у чего приоритет выше)
Разработка это индивидуальный вид спорта
Раскрою мысль. Два программиста не придумают решение проблемы в 2 раза быстрее, скорее даже все замедлится. Но два программиста могут написать программу в 2 раза быстрее если будут работать по общему плану, определят зоны отвественности, модули, интерфейсы между ними. То есть каждый будет пилить свой кусок и не мешать другим.
Для руководителей, которые по любому поводу хотят собраться и хорошенечко потрындеть.
Как раз наоборот. Это для команд, которые принимают решение совместно, а не полагаются на руководителя, который скажет, что сделать.
После «фасилитации/фасилитатора» полностью читать статью перехотелось
Да, стремноватая калька. Но смысл ясен - кто-то, кто ведет обсуждение. Председатель? На суть статьи это не влияет - там все по делу.
Спасибо, статья фактически эталон как рассказывать про коучинг: с теорией, практикой и совсем немножко рекламы. :)
Мы используем подобный подход для приоритезации тех долга в команде. Только первая фаза - генерация идей - у нас асинхронная (и порой довольно растянутая во времени): перед митингом все могут добавить свои идеи в общий список.
Фасилитация на практике, или Как команде принять одно решение для всех