Document-driven management. Почему писать документы — это круто

 Публичный пост
16 марта 2024  3701
ОХУЕННО ⨯3

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

Однако история делает витки, и в какой-то момент появляется Джеф Безос из Amazon и говорит, что PowerPoint это плохо. Затем он буквально объявляет на него бан внутри компании и убедительно просит людей писать документы.

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

Disclaimer. Пишу свое личное мнение. Рассказ не связан напрямую с Авито, где я работаю. Мой опыт субъективен, а людям со степенью в области менеджмента я могу показаться неграмотным.

Как работает document-driven management на уровне команд

Признаюсь, термин document-driven management придумал я сам. Под ним я понимаю процесс принятия решений, когда в компании активно используют составление документов, их обсуждение и согласование.

Я - Data Scientist, занимаюсь разработкой алгоритмов. Например, у меня родилась идея нового алгоритма. На мой взгляд идея очень классная, но требует довольно много нашей работы и работы другой команды. Тогда я составляю небольшой текстовый документ на 2-3 странички, в котором пишу разделы.

  • Текущая ситуация
  • Проблемы
  • На какие метрики влияем, какие OKR достигаем
  • Предлагаемое решение (со ссылкой на схему)
  • Кому что нужно сделать
  • Риски

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

Плюсы документов

  • Стимулируют участников глубоко изучать проблематику
  • Являются референсом для тех, кто хочет разобраться в теме
  • Сокращают количество очных встреч

Как работает document-driven management на уровне крупных инициатив и стратегий

На более высоком уровне все работает примерно также.

Расскажу на примере инициатив. В частности в Авито для работы с инициативами существует так называемый процесс гейтов, который был описан в этой статье на Хабре. Когда появляется новая инициатива, за ней закрепляется product manager. Его задача доблестно провести ее через эти самые гейты или похоронить где-нибудь в процессе. А сам процесс гейтов тесно связан с подготовкой и защитой документов.

Документ на крупную инициативу может быть реально большой. Часто я вижу формат вида ответов на вопросы (вопрос - это заголовок раздела).

  • Какая проблема решается инициативой?
  • Какие решения реализованы у конкурентов?
  • Какие ресурсы необходимы для реализации?
  • Какая финансовая модель у данной инициативы?
  • Что будет с другим продуктом, попадающим под каннибализацию?
  • Какие результаты показал MVP?

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

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

Почему это круто

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

Отличия больших компаний, активно использующих презентации

Расскажу на примере условного Сбера, в котором я работал, и который обладает огромным количеством плюсов. Вклад менеджера в Сбере во многом определяется людьми, которых он нанимает и собирает у себя в команде, а также его стратегическим видением.

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

Минусы

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

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

Джефф Безос говорил Лексу Фридману в подкасте, что один из самых плохих способов принятия решений - методом истощения. Но документная культура очень этому способствует. Иногда, проще дать человеку сделать как он думает, чем вынуждать все согласовывать.

Выводы

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

Надеюсь этот документ эта статья рассказала вам что-то новое. Буду рад комментариям! А еще приглашаю в свой канал Big Ledovsky https://t.me/big_ledovsky. Я рассказываю про профессиональную и личную жизнь, часто пишу про Data Science, продуктивность, здоровье, обсуждаю Лекса Фридмана и многое другое.

28 комментариев 👇
Roman Pavlov System Development Engineer 18 марта в 17:32

Признаюсь, термин document-driven management придумал я сам.

Плохой русский: много саморефлекструет, придумывает воображаемых западных партнёров друзей и объясняет всем почему надо отдать все заводы и пароходы уважаемым людям с ним надо дружить.

Хороший русский: берет немецкую
западную идею и устраивает революцию исполняет ее с восточной непоколебимостью.

Гуглить за amazon writing culture.

  Развернуть 1 комментарий

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

И к чему это приводит:

  • Документы используются для visibility и обоснования для повышения. Ведь чем больше документов за авторством сотрудника - тем больше уровень публичности у его работы. А если еще и оставлять комментарии в других доках (и не всегда важно, по делу или без) - то незамеченным для менеджеров разных уровней совсем не останешься.

В остальном, если не доводить ведение документов до абсурда, получается очень полезная схема. После культуры презентаций Сбере ведение доков кажется куда эффективнее.

  Развернуть 1 комментарий

@olgaduchovny, о, спасибо за классный комментарий!!

Да, у нас тоже документы являются подтверждением твоей работы на ревью..) Но далеко не единственным, поэтому ок. Скорее это в подтверждение скиллов систем дизайна или управления проектами.

Но в целом вопрос, должно ли ревью строиться на сборе документов, отчётов AB-ницы с аплифтами и прочих формальных штуках?

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

А вот про visibility очень-очень интересно, если расскажешь подробнее? Насколько сильная конкуренция за внимание на уровне IC и тимлидов?

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

  Развернуть 1 комментарий

@olgaduchovny, а что в этом плохого, использовать документы как показатель вклада людей в проект/продукт?

  Развернуть 1 комментарий

Уже лет 5 применяю аналогичный подход.
Разработку каждой фичи\продукта, начинаю со странички в Confluence, которая включает в себя:

  • описание проблемы и аудитории
  • детали ресерча, принятые решения и вижен
  • ссылки на остальные документы, драфты UI, etc.

С этой страничкой валидирую полученный вижен со стейкхолдерами, делаю hands-off команде разработки, делаю онбординг новичков.

  Развернуть 1 комментарий

@auvoronov, А используются ли документы как основа для защиты, нужно ли делать проект? Или скорее как фиксация договоренностей?

  Развернуть 1 комментарий

@big_ledovsky, и то и другое. Может так оказаться, что в результате рисерча становится понятно, что делать проект не стоит. И очень полезно зафиксировать причины.

  Развернуть 1 комментарий

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

Вообще, изначально я думал про систему из этого видео, когда увидел "document-driven" в заголовке


Тут уже упомянули про неё, и я с клиентурой тоже пытаюсь вводить её самостоятельно, но из других предпосылок, скорее связанных со мной. Документ собственно, в котором обязателен аналог git, в котором дизайн архитектуры и список действий фиксируются. Плюс топлю за "вечный" чат, который сохраняет все записи. Осталось подклеить whisper для перевода звуков в текст.

  Развернуть 1 комментарий

@mighty_conrad, Спасибо за видео, понравилось. Обнаружил, что смотрел с этого канала даже один ролик про обсидиан (сам использую LogSeq кстати).

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

  Развернуть 1 комментарий

Люблю практики вокруг документов. Добавлю пару мыслей:

  • RFC и ADR - основные инструменты архитектора в современном IT. Ключевое мне кажется, что ты за счет таких документов проверяешь свои решения до того, как покажешь сообществу. Пробелов можно достаточно найти и сократить время на обсуждение. Работает познание через письмо.
  • Обычно в пункты добавляем список вариантов и альтернатив. Они есть всегда. Выбор из одного варианта что-то странное. Я бы даже сказал, что это существенный звоночек.
  • Презентации скрывают существенный объем контента. А документ ты пишешь с прицелом на то, что коллеги или ты сам в будущем (а это уже другой человек) могут самостоятельно восстановить весь нужный контекст.
  Развернуть 1 комментарий

@izonov, плюсую про познание через письмо! Пока делаешь документ, сам исправляешь недостатки прежде чем покажешь что-то другим.

  Развернуть 1 комментарий

Использую подобный подход у себя. 1.5 года назад начала лидировать data team из новых специалистов для одного бизнес юнита. Получила, кстати, 0 документации, так что начала составлять ее сама. Помимо технической документации у нас есть:

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

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

  Развернуть 1 комментарий

@sofya_panda, круто! У нас тоже довольно много моделей и дашбордов. Тоже документируем наиболее важные куски. Но тут конечно очень сложно все поддерживать. Я стараюсь сейчас описание метрик, чтобы были сразу на дашбордах. У нас redash, он не прям чтобы огонь, но там можно текстовые блоки делать.

  Развернуть 1 комментарий

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

Да, поддерживать сложно. Еще структурировать всё это добро - отдельная задача.

  Развернуть 1 комментарий

@sofya_panda, смотрели на dbt? (https://www.getdbt.com/). Там есть очень много всего для того чтобы было проще документировать модели/внешние зависимости от моделей (обычно это как раз дашборды)/метрики, итд.

Ну и это не считая всех плюшек которые идут от core возможностей и analytics engineering.

  Развернуть 1 комментарий
🕵️ Юзер скрыл свои комментарии от публичного просмотра...
Anton Sol решаю вопросики (с данными) 3 апреля в 10:17

Есть советы, что делать, если в моей компании так не принято, но хочется?

  Развернуть 1 комментарий

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

Мне кажется, что на уровне компании документную культуру без усилий топ менеджеров не привить, но вполне можно на уровне команды!

  Развернуть 1 комментарий

Благодарю за статью, подход действительно имеет значительные плюсы.
Может у кого-то есть опыт перехода команды на такой подход? И что делать, если подход - инициатива нисходящая, и твой руководитель предпочитают PowerPoint вместо того, чтобы асинхронно почитать текст перед встречей?

  Развернуть 1 комментарий

@leitosama, ох, хороший вопрос)

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

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

Может быть можно выстроить взаимодействие между несколькими командами.

Но в целом культура будет тяготеть к тому вектору, который задается топ менеджментом.

  Развернуть 1 комментарий
Алесь Жук Онлайн-квесты, геймификация, вовлечение 25 марта в 07:49

Спасибо за описание. А почему на обсуждении с топ-менеджерами, первый час на чтение?
Логично к встрече прийти уже прочитав документ и оставив комментарии.

  Развернуть 1 комментарий

@gamedozor, кажется, это удачная практика - отдельно бронировать у стейкхолдеров время на ознакомление с материалом.

Тогда точно гарантирует, что человек с материалом ознакомился и его решение будет информированным/взвешенным

  Развернуть 1 комментарий

@gamedozor, обычно у топ менеджеров календари состоят из встреч на 100%. Час на чтение - это резервирование времени людей на ознакомление. Если этого не делать, то никто заранее не прочитает))

  Развернуть 1 комментарий
Никита Третьяков ванильный уолл с волкстрит. 13 мая в 20:45

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

  Развернуть 1 комментарий

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

Но ведь в данном посте описан упрощенный пример бюрократии.

Причем, если процесс принятия решений в компании отлажен, то будет налажен и документооборот, определены стандарты подготовки документов и требования к ним.

Встречи с на уровне топ-менеджмента с обсуждением инициатив - это просто "заседание комитета", комитетов может быть великое множество: комитет по инвестициям, заседание группы по разработке ...., комитет по рискам и т.д.

И заседания комитетов - это примерно как защита диплома, в кратком варианте. Если вопросом нет - члены комитета, наделенные правом голоса, голосуют "за" (условно), если есть к докладчику (он же менеджер, он же владелец продукта, он же ... подставить нужное) - их обсуждают, но не час, точно, минут 10. Час - это суммарное время заседания, на котором может быть обсуждено 10 инициатив, например. Если докладчик не может защитить свой документ - решение не принимается, необходимо доработать. Либо могут вообще заблокировать инициативу, чтобы не развивать это направление. И, по опыту, в очной встрече чаще всего нет необходимости - если докладчик не может изложить суть в документе, то и очно он это сделает так себе.

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

Пример хренового управления, что, скорее всего, является преступной безалаберностью, но не мошенничеством или воровством:

  Развернуть 1 комментарий

@StasOn, прошу прощения, возможно не очень понял мысль. Правильно я понимаю, что мысль в том, что отличия описанной культуры от традиционных корпораций не так много?

  Развернуть 1 комментарий

@big_ledovsky, да, не так много отличий, а по некоторым пунктам - 1 в 1 соответствие.

  Развернуть 1 комментарий

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

  • Согласование документов в старых корпорациях долгое, а несогласующие часто не помогают доделывать документ, а только пишут замечания
  • На комитетах менеджмент может поверхностно погружается в детали, т.к. не может это сделать за 15 минут
  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб