Наш идеал почти 9 лет был такой: собрание стоя, 15 минут максимум, минимум людей. И лучше вообще в коридоре. Не можешь решить за 15 минут — значит, что-то пошло не так. Звучит круто, правда?
Оказывается, надо делать и долгие. В прошлом посте я рассказывал про то, как мы научились выделять минимально достаточную группу людей, которая может выработать решение так, чтобы не бегать с ним наверх к руководителям. Осталось сделать так, чтобы совещание обошлось без крови.
Механика, которую нам предложили — это совещание по специальному протоколу. Оно занимает невероятно дохрена времени (4 часа на вопрос, где ушло бы наши 15 минут), навевает скуку и тоску, но если проходить по этапам, появляется ощущение, что решение всё же есть. И его можно реализовать. И оно, скорее всего, получится очень качественное: будет учитывать больше нюансов, будет поддержано теми, кому его исполнять. А это существенно сокращает срок внедрения.
Лучше пару часов потерпеть, но потом внедрить на месяц быстрее.
Как это было
Первый раз, когда мы попробовали пойти по регламенту, получилось вообще 4 часа. Это мы ещё утром начали, и сразу полдня в задницу. Было бы в обед — весь день сходил бы лесом. Правда, нам обещали, что потом будет легче. До 2-3 часов мы уже научились сокращать, но шаманы утверждают, что можно и за час.
Оказалось, только так люди друг друга слышат. А это чертовски важно на следующем этапе, когда надо делать. «Медленно решаем, делаем с первого раза и быстрее» — это крутой тезис.
Началось всё просто: мы позвали чувака-консультанта из института Адизеса. Он как-то небрежно обронил слова «фасилитация» и «имплементация», а потом рассказал байку про японский иероглиф «кризис», и про левые ботинки Найка и так далее. Это нас немного смутило, но его механика сработала неожиданно круто.
Смысл такой:
- Надо установить правила совещания, чтобы никто не отвлекался. У нас они такие: нельзя опаздывать, нельзя уходить до конца совещания, вышел — не вошёл, телефон выключить, планшет и ноутбук только для записей и показа чего-то по теме, не перебивать, не материться. Последний пункт для эффективных коммуникаций абсолютно не важен, но вызвал целый филологический диспут, в ходе которого мы узнали про «экспрессивное ядро» и почерпнули несколько новых слов из славянских берестяных грамот. Ещё один из участников заранее назначается администратором — он следит, чтобы была нужна переговорка, все всё поняли, проектор работал, печеньки не спёрли закупщики и так далее.
- Нужен человек, который будет записывать все тезисы совещания (модератор) и сразу выводить их на экран. Модератор же отвечает за соблюдение правил, в частности, бьёт по рукам тем, кто перебивает. Ещё одна важная задача модератора — быть холодной логикой. Он как компилятор, может не пропустить ряд тезисов. Почему и что это — чуть дальше. Модератор не имеет никакого отношения к обсуждаемому вопросу в принципе, может в нём даже близко не разбираться. Его задача — обеспечивать протокол обмена данными. Предполагается, что в компании есть пара специально обученных людей, которые умеют модерировать.
- Нужен экран или проектор, который все видят.
Дальше мясо.
Сначала — определение терминов. Например, наш сюрприз такой: в слово «наличие» три разных подразделения вкладывали разные смыслы. Для закупки «есть в наличии» — это хотя бы один товар в любом одном магазине в России. Для розницы — есть в большинстве магазинов хотя бы один товар. Для организации акций — есть хотя бы 5 штук в большинстве магазинов. И в результате требование «обязательное наличие группы А» выполняется каждым по-своему. Ещё, кстати, кое-кто понимал группу А по умолчанию по выручке, а кто-то — по прибыли. Что тоже требует уточнений.
Потом каждый высказывает возникшие по теме совещания проблемы. Вот тут и нужна холодная логика модератора — потому что очень легко перескочить с проблемы сразу на решение.
Например, запрос от колл-центра: уберите кнопку «Заказать в один клик».
Раньше я им отвечал в духе: «Вы там обкурились? Конечно, нет.»
На самом деле правильный ответ: «Это решение, а в чём проблема?»
А оказывается, от одного человека падает несколько заказов с разницей в 3-5 минут по кнопкам «Заказать в 1 клик». Он заказывает одну игру, ходит по сайту, заказывает вторую и так далее. Может получиться, что колл-центр делает несколько звонков по одному телефону. Это проблема.
Забегая чуть вперёд, оказывается, человек хочет заказать игру здесь и сейчас, оформляет первый документ на заказ в системе. В итоге так хорошо сработавшая кнопка, которая прошлый раз не подвела, плюс автозаполненные поля (мы сохраняем в куки предыдущие вводы) дают несколько разных заказов. Если повезёт в рабочее время — по ним перезвонят аж 2-3 оператора. Потому что мы быстрые.
Решение: надо ускорить синхронизацию и склеивать заказы с одним телефоном, поступившие примерно в одно время, в один большой заказ на бекэнде. Интерфейс заказа трогать не надо. Колл-центр об этом не думал, но зато считал нас гадами, потому что мы не помогаем им работать.
Так вот, когда все проблемы поставлены, они коротко обсуждаются. Часть снимается сразу, просто потому, что кто-то что-то не понимал. Вообще, это самый важный момент — синхронизировать точки зрения. Потому что на той же игре есть текст. Дизайнер считает, что если его будет меньше, будет лучше. А я знаю, что пропускать состав нельзя, и есть ещё пара важных блоков. Производство знает, что там нужен огромный технический блок с адресами-телефонами и так далее. Когда мы все понимаем, что цель — сделать игру лучше, и «лучше» — это понятнее для пользователя, пускай с небольшим ущербом красоте плашек, дизайнер понимает, зачем всё это. И наступает короткий интервал счастья, когда все делают одно дело.
В 70-80% случаев проблемы остаются после объяснений.
Потом идёт оценка важности каждой из проблем — сколько времени займёт решение, сколько это будет стоить, и сколько денег принесёт компании (считается прибыль, экономия средств и «добрая карма»). Точные оценки не важны, главное — примерно выделить ТОП-5 вещей, которые можно решить или хотя бы надгрызть за месяц. И которые реально актуальны. То есть всё неважное — отложить в никогда (может, всплывёт на следующем таком совещании), а критичное — начинать грызть. По той же методологии, если начать решать тактические проблемы (не уровня климата в компании), то постепенно задачи климата переедут и на этот уровень. Сразу большие проекты не берутся.
Это удивительно отрезвляет, потому что хочется делать всё, а надо выбрать одну вещь. Или две. Или пять. Больше не выйдет за месяц. И фокусированно их решать.
Дальше — обсуждаются варианты решения реально важных вещей, раздаются задачи, фиксируются сроки их исполнения.
Зачем вся эта шарманка?
Это всё очень долго, но полезно. Вот ещё пример запроса от колл-центра. Говорят: «Сделайте нам блок парных товаров — чтобы было видно, что с этой игрой покупают».
Неправильный ответ, который я давал почти два года: «В фиче отказано».
Правильный ответ:
— Нет, это уменьшает конверсию, мы пробовали уже. Вы же знаете, этот блок был. С ним конверсия чуть ниже, чем без него. Это связано с тем, что люди начинают смотреть другие товары и не решаются выбрать. То есть срок внедрения — 3 недели, ожидаемый экономический эффект — ну, минус 300 тысяч рублей в год.
Колл-центр, слегка поменяв картину мира:
— А тогда сделайте на те товары, которые сняты с производства, чтобы были похожие.
Оказывается, люди приходят на сайт, видят, что товар снят с производства и звонят в магазин узнать, совсем-совсем нет или просто нет. И если совсем-совсем нет, то этим людям интересно, какие игры используют ту же механику. И какие подойдут, если имениннику нравилась эта вот конкретная, которой уже не достать.
Естественно, не все звонят и не всегда можно ответить (например, ночью по Москве). Поэтому колл-центр и просит сделать блок с похожими товарами на тех страницах, где товара нет и больше не будет.
Конечно, надо делать. Не факт, что сейчас, когда есть другие фичи в запросах. Не факт, что это надо раньше того же прикручивания определения ближайшего магазина по мобильной геолокации, но нужно. И вот снова все вокруг не гады, которым плевать на нужды колл-центра, а нормальные, оказывается люди. Просто с другой точкой зрения.
В общем, мы уже сделали много чудных открытий. И вилы на каждом шагу: разное понимание задачи, попытки пропихивать решение вместо проблемы, не дают рассказать свою точку зрения (потому что кто-то лучше знает), не было оценки важности проблем и их цены… В общем, может, мы, конечно, делаем всё неправильно и косо, но эти монструозные совещания реально окупаются. Возможно, есть другая методология, которая сильнее, выше и быстрее. Но уже эта показала себя хорошо.
Напомню, у каждого такого совещания есть конкретный человек, который отвечает за результат решения проблемы и срок. Он выслушивает все точки зрения по ней и принимает решение сам.
Вполне возможно, что если вы разработчик, вам в вашей проектной группе всё это нафиг не надо, и даже тимлидам это тоже нафиг не надо, и даже ПМы решают всё интуитивно и понятийно. Но когда бизнес растёт, это становится ой как полезно — потому что раньше все непонятки ты так или иначе утрясаешь с людьми, с которыми постоянно общаешься. А теперь их просто больше, и нужной передачи данных нет. Ну и само понимание механики помогает даже на обычных встречах задавать правильные вопросы и более точно оценивать приоритеты.
