Простой приём: Как ускорить принятие решений в команде

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

В этом случае может помочь простой приём — попробуйте предложить радикальное, обоим сторонам неудобное решение.

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

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

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

#teamwork #devfm

В продолжение поста про правила коммуникации от 37signals

Пример из практики.

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

И это катастрофа. По факту — частная договоренность, которую никто больше не видел, без фиксации в соответствующих артефактах.

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

Но самое интересное в другом. Эти правила уже были в команде, но инцидент показал, что они плохо зафиксированы или донесены до новых сотрудников.

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

#devfm #teamwork

Как я провожу синки с тимлидами

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

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

Структура
Повестка состоит из трёх частей:
1️⃣ Обязательная часть
Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется.
Как правило это:
– Посмотреть action points с предыдущего синка
– Общий статус по задачам в работе
Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы.

2️⃣ Опциональная часть
Эта такой живой раздел. Сюда каждый из участников записывает темы/вопросы, накапливающиеся в течение недели. Темы могут быть самыми разными: какой формат перфоманс ревью в этом полугодии, обсудить новую идею по изменению шаблонного сервиса, внедрение новых метрик и т.д.

3️⃣ Action points
Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных.

Соответственно, такой скелет повестки с пояснениями по каждому разделу создается для каждой встречи и наполняется в течение недели.

Почему именно так?
Кому-то может показаться, что такой формат слишком бюрократичен. И в целом, когда у тебя пара подчиненных, действительно можно держать многое в голове, но когда их становится больше, то подобный формат мне дает:
✅ прозрачное отслеживание всех вопросов и договоренностей
✅ возможность накидывать темы заранее, не теряя их
✅ отсутствие стихийных созвонов, когда появляется какой-то вопрос. Всегда есть понятное место, куда его можно припарковать
✅ наличие повестки заранее, что позволяет лучше подготовиться к встрече
✅ лучше работает на асинхронное взаимодействие – если какая-то тема потеряла актуальность за неделю, можно просто её удалить, не тратя время на обсуждение

О применении ТГ для асинхронной работы была отдельная статья.

#teamwork #devfm

Оперативный постмит

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

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

Это оказалось супер удобно:
– Сразу видно, что записывается, а участники могут поправить, уточнить, добавить
– Все сразу понимают, кто на ком стоял, кто за что отвечает
– Не нужно тратить время после встречи и что-то дооформлять
– Шаблон постмита позволяет ускорить процесс ещё больше

#devfm

Как проводить встречи эффективно

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

Подготовка
– Избегай звонков без необходимости – большинство вопросов решаются в чате
– Не дергай “на минутку” – если прод не упал, значит не срочно
– Анонсируй: кто, когда, зачем. Иногда достаточно треда в чате
– Проверяй доступность участников через календарь
– Ограничивай время – 30 минут обычно хватает, 1 час — максимум
– Готовь повестку заранее: тема, пункты обсуждения, цель встречи, уважай чужое время
– Рассылай материалы и документы до встречи
– Предупреждай об отмене или задержке как можно раньше
– Опаздываешь? Не опаздывай 🙂

Старт встречи
– Начинай вовремя – без «ждём ещё кого-то»
– Проверь комнату ожидания и список участников
– Напомни повестку – это фокусирует команду

Фасилитация
– Держись повестки и возвращай к цели встречи
– Дай слово молчунам, притормози болтунов.
– Подводи итоги каждые 10–15 минут: «Итак, договорились, что…»
– Следи за чатом и поднятыми руками
– Делись экраном, глаза – тоже канал восприятия
– Включай камеру по возможности
– Не перебивай – сначала дослушай, потом задавай вопросы.
– Паркуй спорные темы после трёх заходов
– Уважай выделенный слот – если нужно больше времени, спроси
– Веди пост-мит в реальном времени

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

#devfm

Еще один способ организовать рабочие чатики

Я пробовал организовывать рабочие чатики самыми разными способами: иногда просто в отдельную папочку, иногда – в папки по проектам.

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

И некоторое время назад я придумал (вряд ли я, но в моем мире – именно я), как иначе организовать рабочие чатики – по срочности.

Сделал 4 папки:
🔹Now – то, на что мне нужно реагировать незамедлительно. Таких чатов всего 1–2, но стремиться нужно к нулю
🔹Hourly – то, на что нужно посмотреть в течение часа
🔹Daily – пробежаться раз в день, узнать, что происходило
🔹Later – оно же «никогда», оно же «когда-нибудь». Это чаты, где просто нужно присутствовать :)

В результате стало гораздо легче ориентироваться и не отвлекаться на лишний шум.

#devfm

Шаблонный сервис

Я всячески люблю, когда разработка идёт предсказуемо – и многое для этого делаю.
Давно хотел написать пост о важности шаблонного сервиса, но не было хорошего примера под рукой. И тут мой коллега выложил наш шаблонный сервис на FastAPI, который мы долгое время использовали и развивали.

Так зачем же нужен шаблонный сервис?

Легко ориентироваться в других сервисах. Иногда нужно залезть в сервис коллег, или поддерживаешь несколько сервисов. Никаких проблем – структура везде одинаковая, всё знакомо, не нужно тратить время на раскопки.

Быстрый старт. Стартуете новый сервис? Полчаса – и он готов. Никаких лишних приседаний.

Единые практики. Шаблон определяет, не только структуру, но и то, как мы, например, делаем ретраи, какие у нас зависимости. как устроен circuit breaker, обработка ошибок и т.д.

Лучшие практики – в одном месте. Если появляется что-то классное, мы добавляем это в шаблон и новые сервисы сразу это наследуют.

Обсервабилити, логирование, работа с секретами – готово из коробки. И меньше шансов, что кто-то забьёт на логирование до лучших времён»:)

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

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

Унификация линтинга. Конфиги линтеров лежат в шаблоне. Ничего настраивать не нужно, а код-ревью идёт быстрее – обо всём уже однажды договорились и зафиксировали.

Базовый CI/CD. Для шаблонного сервиса существует шаблонный ci/cd – и это очень удобно.

Мы активно использовали шаблонный сервис в микросервисной архитектуре, но и для монолитных решений он тоже отлично зашёл – стартовали с ним несколько проектов.

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

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

#devfm #systemdesign

Ух, вчера вспомнил давно забытую боль.

Некоторое время назад мы пилили b2b-продукт и интегрировались по HTTP с большим сервисом большой компании.

И вот представьте моё удивление, когда приходит разработчик и говорит, что мы получаем код 200, а в body – что-то типа «произошла ошибка». Мы тогда повозмущались и смирились, потому что альтернатив всё равно не было.

И всё бы ничего, если бы вчера я не рассказал эту историю своему хорошему товарищу. А он, представьте себе, вообще не удивился. Сказал: «Да, всё так и есть. Видел это не раз. И во вполне приличных конторах – тоже».

И вот у меня вопрос – ну как так то, доколе?! Может, у этого есть какая-то логика?
Вы такое встречали?

#devfm

Хотел написать небольшой пост – а в итоге получилась целая статья.

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

Собрал в статье практические советы, которые помогают при работе с агентами:
– как организовать удобный флоу
– почему не стоит просить «сделать всё под ключ» и как стоит
– как формировать рабочие rules
– зачем переключать модели и когда это спасает
– почему экспертиза разработчика всё ещё критично важна

Заходите почитать, если понравилась ставьте лайкосики.

#devfm

Зачем вы проводите код-ревью?

Большая часть команд, с которыми я работал, проводят код-ревью. Код-ревью – как священная корова: “А код поревьюили?”, “Без ревью не пушим” и всякое такое.

И каждый PR дисциплинированно пропускают через код-ревью: назначаются ревьюеры, они что-то пишут, код как-то правится...

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

Ответы бывают разные.

Мы хотим поддерживать качество кода, соблюдать единый стиль.
Что ж, похвально. Только у меня сразу возникает вопрос: а что вы считаете качественным кодом, что считаете единым стилем? А у вас настроены какие-то автоматизации? Ответы бывают разными, но по моему опыту редко есть уверенные ответы на все из них. А без этого код-ревью очень быстро превращается в вкусовщину и в обсуждение того, что вообще-то должна делать машина – линтеры, форматеры, базовые проверки.

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

Код-ревью нам нужно для шаринга знаний – такой ответ дают самые прогрессивные. Честно говоря, какое-то время это был мой любимый аргумент, и я очень им гордился. Но если задуматься: для шаринга знаний предполагается, что разработчик, у которого куча своих задач и контекстов, переключится на чужую задачу, впитает всё, что там написано, разберётся и получит ценные знания. Вопрос – сколько же времени нужно для этого? Как говорят классики: «сомнительно, но окэээээй». Если услышите такой аргумент, спросите у разработчиков, сколько времени они тратят на ревью, и подумайте, можно ли за это время действительно перенять знания. Ответы, которые получал я, говорят: скорее нет, нельзя.
Моё мнение – код-ревью создаёт иллюзию шаринга знаний, но по факту распространяет только очень поверхностный контекст. Если вы реально хотите шарить знания, есть куда более прямые и честные инструменты – дизайн-доки, обсуждения решений до реализации, грумминги задач.

И это я ещё не затронул другие проблемы и крайности: когда в PR появляется миллион комментариев, когда какой-то очень умный разработчик упирается рогом и говорит, что такой PR "только через мой труп", когда PR-ы висят днями, копят строчки, а потом полдня тратится на разруливание конфликтов. В общем – красота.
Так зачем это всё?

Код-ревью – полезная практика
Да, я всё ещё считаю код-ревью полезной практикой. Но чтобы она работала, над этим нужно много работать. Хорошее код-ревью – это работа над инженерной культурой.

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

Второе – автоматизировать всё, что можно автоматизировать: линтеры, форматеры и вот это всё. Чтобы на ревью об этом даже не думали.

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

Ревью действительно должно быть:
– когда вы залезли в чужой сервис или область знаний и сами просите эксперта посмотреть код
– когда вы мейнтейнер опенсорсного проекта
– когда вы менторите новичков или джунов и осознанно инвестируете время

Если вы прочитали и подумали: "Что это за бред?" – ну что же. Либо вы никогда критически не смотрели на этот процесс, либо вам действительно повезло с командой. Во втором случае искренне за вас рад – держитесь за неё. Так бывает далеко не у всех.

#devfm

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

Собрал подборку лучших постов за прошедший год – если пропустили или хотите вернуться к избранному:
– Зачем нужен шаблонный сервис и пример такого сервиса на FastAPI
– Чтобы провести встречу продуктивно, нужно постараться. Мы написали, что сами применяем на практике
– Видео про роли в крупном проекте – аналитики, разработчики, тестировщики и как всё это живёт вместе
– Набор заметок о том, зачем нужны архитектурные схемы, как их составлять и где проходят зоны ответственности
– Пост-стенание на тему код-ревью
– Революционный метод организации рабочих чатов
– Сайт с сериалами на разных языках и бот для изучения иностранного языка методом карточек
– Мой опыт работы с ai-агентами
– Приём, который помогает быстрее принимать решения в команде
– Как не забивать на написание постмитов
– Статья о том, как написать своего первого ai-агента
– Советы и антипаттерны при работе с Postgres
– Очень крутой курс по System Design, который искренне рекомендую

#devfm #backup

Когда у задачи нет даты

Я уже рассказывал, как организую свои задачи. Сегодня про один приём, который мне сильно помогает.

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

Но есть такие задачи, которые не привязаны к дате – они привязаны к событию.
Примеры из жизни: “когда поеду в Сочи – сходить в такое то место”, “когда будет синк по проекту – обсудить текущий CI/CD”. У этих задач нет конкретной даты, и непонятно, куда их складывать. Если просто кинуть в общий список – они точно потеряются. Если поставить произвольную дату – будут раздражать напоминаниями не в тот момент и постоянно еще придется переносить.

И вот тут мне помогают теги. Я размечаю такие задачи по событию: #сочи, #ретро, #созвон-с-заказчиком. Когда событие наступает – открываю нужный тег и вижу всё, что хотел сделать или обсудить.

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

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

#devfm #productivity

Правило трёх итераций – когда диалог зашел в тупик

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

И в этом потоке обсуждения почему-то кажется, что ещё одна итерация – и точно договоримся. Ещё раз объясню свою позицию, приведу новый аргумент, и собеседник наконец поймёт.

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

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

Три итерации – и тормозим, работает удивительно хорошо.

#devfm