Отключаем оповещения о новых сообщениях (Пример из главы «Улитки против м%даков». Фрагмент третьей книги)

Включенные оповещения о новых сообщениях в рабочих чатах

В этом примере мы поговорим с руководителем продукта (как обычно – вымышленным) о том, что для сосредоточенной работы нам нужна тишина и как минимум отключенные оповещения о новых сообщениях, чтобы он не отвлекался каждые 2 минуты.

— Да я всё понимаю, что я буду продуктивнее, если отключу эти оповещения, но мне же надо быть в курсе…
— Не торопись, давай по порядку. Ты точно понимаешь, что тебе дадут отключенные оповещения о новых сообщениях в чате?
— Да, я буду меньше отвлекаться
— И что с этого? В смысле, что хорошего произойдет, если ты будешь меньше отвлекаться?
— У меня есть много задач по развитию системы и там надо думать, чтобы все описать и подготовить хорошую постановку задачи. А бывает так, что прилетит новое сообщение, и вроде бы на я него потратил 2 минуты, но потом еще минут 15-20 не могу вернутся к размышлениям, ковыряюсь в других сообщениях… Ну раз в чаты залез, то что бы не ответить? И так время улетает.
— Давай ближе к делу, если ты будешь меньше отвлекаться, то…
— Я смогу быстрее готовить постановки задач по разработке новых фич.
— Хорошо. Значит вот верхняя часть нашей тучи:

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

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

— Хорошо, давай пока так и зафиксируем. Итого, нижняя часть нашей тучи:

— А теперь нам стоит подумать, есть ли какая-то общая цель у этих двух ветвей? Для чего вам одновременно нужно и быстрее получать постановки задач по разработке новых фич и быстрее устранять возникающие сбои?
— Здесь просто – мы повышаем количество платящих пользователей. Разработка нового функционал – это фактически привлечение новых пользователей. У нас есть один большой сегмент, который начал бы пользоваться нашей системой, но им не хватает <пошли какие-то узкоспециализированные термины>, над разработкой чего мы работаем. Как только мы это выпустим – эти пользователи начнут к нам приходить. А быстрое устранение сбоев – это во многом про удержание…
— Итак, давай зафиксируем в туче общую цель: «Большее количество пользователей платят за использование нашей системы»:

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

— Перед тем, как начать анализировать тучу, нам нужно убедиться, что D ставит под угрозу выполнение C, а D’ ставит под угрозу B. Это так называемая диагональная проверка тучи.
— Да, всё так. Если я отключу оповещения, то я ставлю под угрозу быстрое устранение сбоев, а если не отключу оповещения, то не смогу сосредоточиться, и буду работать медленнее над постановками.
— Прекрасно. Давай теперь проверим, на каких предположениях держится эта туча. Начнем со связи B-D. Тут ты уже говорил, что даже если отвлекся на новое сообщение на 2 минуты, то потом еще 15-20 минут не можешь вернуться обратно.
— Это в среднем, если можно так выразиться. Иногда я могу вернуться достаточно быстро, если удалось ответить, не выходя из состояния потока. А иногда ты отвлекаешься… Смотришь, что у тебя через полчаса встреча и как-то уже смысла нет возвращаться в аналитику и занимаешься всякой мелочью. А после встречи надо отдохнуть, а там еще одна встреча или уже вообще поздно и в этот день я больше ничего не сделаю. Короче, в любом случае с оповещениями я работаю медленнее.
— Понятно. Тут тогда вопросов нет. Давай подумаем про связь A-B. Я услышал, что чем быстрее вы разработаете определенный функционал, тем быстрее сможете привлекать пользователей из нового сегмента. Всё так?
— Да, всё так. Тоже вопросов нет?
— Пока не понятно. А над постановкой какого функционала ты сейчас работаешь?
— Над фичей Х.
— Много там еще работы?
— Это как отвлекать будут. Но в текущих условиях неделю точно.
— Если постановка будет готова через 10 минут, то когда команда сможет взяться за её реализацию?
— Так… Тут грустно, на самом деле. Они еще не реализовали то, что я им описал в прошлом квартале.
— Тогда есть вопрос. Почему ты думаешь, что чем быстрее ты сделаешь новые постановки, тем быстрее они будут реализованы?
— Ээээ… Ну я не знаю… Так что, мне теперь можно не работать что ли?
— Почему сразу «не работать»? Если ты даже при текущих условиях работы успеваешь сделать больше, чем способна реализовать команда, то не ты являешься ограничением общей скорости работы. Если ты начнешь писать постановки даже с утроенной скоростью, то, как я понял, с утроенной скоростью пользователи новые фичи получать не будут.
— То есть моя эффективность…
— Не важна для эффективности системы в целом. Нет, конечно, если ты начнешь работать ещё медленнее и сам станешь ограничением, тогда конечно. А так тебе надо всеми силами стараться помочь команде разработки, даже в ущерб своей эффективности.
— Например, быстрее отвечать на их вопросы по старым постановкам?
— Да, например.
— То есть, все-таки включить оповещения о новых входящих сообщениях в чатах?
— Как минимум в тех чатах, где члены команды пытаются выяснить вопросы по тем постановкам, которые у них уже в работе. Если отсутствие ответа тормозит работу над фичей, то ответы на вопросы команды должны стать для тебя приоритетом. Ведь, если команда ускорится хотя бы на десять процентов, то…
— Скорость поставки новых фич увеличится на десять процентов. Понял, пойду настраивать себе оповещения…
— Не спеши. Запиши этот пункт себе в список задач. Давай, раз уж мы собрались, проанализируем тучу дальше. Вдруг, она нам еще какие-то идеи подбросит?
— Хорошо. Ты – босс!

— Давай посмотрим на связь A-C. Почему ты думаешь, что если сбои в системе будут быстро устраняться, то большее число пользователей будет готово платить за использование вашей системы?
— Как минимум потому, что снизится их отток. Мы уже не уникальны и у нас есть конкуренты. Некоторые даже опасные. Когда наша система не работает, то наши пользователи не могут продавать свои услуги и фактически теряют деньги. Если мы успели починить всё так быстро, что никто ничего не заметил – хорошо. А если пользователи это замечают, то кто-то из них начинает думать о переключении на систему конкурентов, как будто у них сбоев не бывает...
— Понятно. Разумно. Давай это и зафиксируем.
— И пойдем анализировать предположение за связью C-D’? То есть, почему я думаю, что если я держу включенными оповещения, то будут быстрее устраняться сбои?
— Да, но только перед этим давай поправим формулировку C.
— А что с ней не так?
— Здесь у нас пассивная форма глагола, которая прячет действующего субъекта. Мы же понимаем, что сами себя сбои в системе устранять не могут, так?
— Конечно не могут. Если сбой типовой, то его устраняют на первой линии поддержки. Если они не могут справиться сами, то подключают ребят со второй линии. Если произошло что-то более серьезное, то включаются эксперты с третьей линии и даже разработчики.
— А для решения инцидентов какого уровня сложности нужно подключать тебя?
— Ну вообще для любых.
— И какова твоя роль в решении инцидентов?
— Ну я же должен быть в курсе! Мне отчет потом писать, анализировать, что произошло и что нам надо сделать, чтобы такого не повторялось.
— Так, давай здесь подробнее. Отчет потом писать – ясно, но потом – это после устранения инцидента, да?. И там нет же никакой спешки, типа любая секунда задержки в написании отчета – это минус прибыль нашим клиентам?
— Нет, там такого нет, но это обязательно нужно делать.
— Нужно сделать обязательно и нужно делать как можно быстрее – это разное. А как твое «быть в курсе» помогает команде быстрее решить инцидент?
— Не знаю, даже…
— Может, у них и спросим?
— Не уверен, что стоит их сейчас отвлекать…
— А что, они очередной инцидент сейчас чинят?
— Нет, когда они что-то чинят их вообще нельзя трогать, а сейчас просто лучше не беспокоить

Нам повезло (в вымышленных ситуациях такое часто бывает), мимо проходил инженер 3-ей линии с чашкой горячего кофе и краем уха подслушал наш разговор:
— Мозги он нам клюёт, вот как он нам помогает. Встанет рядом и давай: когда вы почините? Когда вы почините? Так и хочется ответить, что не раньше, чем ты закончишь нас об этом спрашивать.
— Ценное дополнение, спасибо большое!

Дальше мы возвращаемся к обсуждению тучи:
— Ну что, ваш коллега прав?
— Может, немного грубо сказано, но… Я же волнуюсь. Да и генеральный может узнать о сбое, он же мне будет звонить и спрашивать. А мне нужно знать, что ему ответить.
— И что, не отвлекая исполнителя ничего нельзя сказать об инциденте?
— У исполнителя самая актуальная и точная информация…
— Которой он с удовольствием поделится вместо того, чтобы устранять сбой, так? А так ли вам в эти моменты нужна самая актуальная и точная информация? Особенно, если все быстро меняется. И есть ли еще кто-то, кто может хоть что-то сообщить?
— Какая-то информация есть в нашей системе, так как сбой сразу же фиксируется. Но все равно все детали есть только у того, кто работает над устранением. Ну и мне много не надо, мне буквально на одну минуту эксперта спросить…
— Интересно, вот в самом начале ты говорил, что иногда 2-х минутное сообщение отвлекает тебя надолго от работы над постановкой. Вот, когда эксперт пытается разобраться в сбое, а его спрашивают про то, когда он всё починит…
— Ну ладно, я понимаю. Но в такие моменты я реально начинаю переживать. Мне хочется хоть чем-то помочь, потому что, как только я узнаю о сбое, то все равно больше уже ни о чем другом думать не могу!
— Может, тогда и не надо узнавать о сбое, если всё равно помочь не сможешь, а только начинаешь мешать…
— В смысле?...
— Ты говоришь, что сбои все фиксируются, как только ребята его устранят, ты получишь информацию по результатам и приступишь к своему отчету, с ним же спешки нет?
— А если я уже увидел, что произошел сбой, то как мне это развидеть, чтобы перестать волноваться?
— Отключи оповещения в том канале, куда эта информация приходит.
— Погоди! Я был морально готов к тому, что надо будет гибко настроить оповещения и мне казалось, что в книге Дорофеева об этом говорилось, ну типа не всегда обязательно отключать прям все оповещения, оповещения о важных событиях можно оставить…
— Всё так. Но что значит «важные события»? Во-первых, ничего не бывает важным само по себе и для всех сразу. Любое событие оно важно для кого-то и почему-то. Быстро узнавать о сбое важно специалистам, чтобы они могли быстрее приступить к его устранению. А тебе важно быстро узнавать о сбоях, чтобы быстрее приступить к отвлеканию специалистов от устранения сбоя, так?..
— Ну как-то это все вообще неправильно… Ты предлагаешь мне включить оповещения о вопросах по постановкам, которые не срочные, но выключить оповещения об авариях, а это, вроде как, срочно?..
— Ну да… Отвечать на вопросы о постановках ты можешь. Помочь устранить аварию – нет.
— Но вот как-то это совсем не по правилам…
— Почему же? Это не по шаблону, который ты взял из книги и счел правильным в своей ситуации. Еще не факт, правильно ли ты понял этот шаблон. Мы же с тобой взяли правила более низкого уровня – закон причин и следствий – и вывели из этого закона конкретные правила для конкретного человека в конкретной ситуации. Общие шаблонные правила часто жертвуют эффективностью в ущерб универсальности. Мы же здесь занялись тонкой настройкой. Но так уж получилось, что конкретно в твоей ситуации пришлось общее шаблонное правило вывернуть на изнанку.
— Да… Интересно, сколько еще шаблонов в моем поведении, которые мне стоило бы пересмотреть и вывернуть наизнанку?..

Оставим менеджера размышлять. Разбирая этот пример тучи, мы не дошли до предположений, стоящих за конфликтом D-D’. Почему в принципе существует этот конфликт? Почему я не нахожусь в каком-то из двух состояний: «Точно нельзя отключать оповещения» или «Точно нужно отключить оповещения»?. Ответ зафиксируем на диаграмме. Просто для примера:

Текущая структура третьей книги