#полезности
Амбулаторное обследование процессов

Привет, читатель!

Недавно в Канбан Толкс наткнулся на классное обсуждение — делились вопросами для интервью о процессах. Как понять, что болит у команды или заказчиков, на что стоит обратить внимание?

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

➡️ Лови список:

О человеке

- Чем занимаешься в компании
- Какая цель твоей работы
- Что именно ты делаешь?
- Какие ожидания от твоей работы, как тебя оценивают?
- В какой команде/подразделении работаешь, кто под твоим руководством?

О бизнесе в целом

- Какая бизнес-цель стоит перед подразделением/твоим продуктовым направлением?
- Что сейчас хорошо в подразделении/бизнесе?
- Что сейчас плохо в подразделении/бизнесе?
- От кого/чего зависит успех подразделения/бизнеса?

О команде

- Какая цель работы твоего подразделения/команды/направления?
- Кто для тебя заказчики?
- От кого/чего зависит успех вашей команды?
- Что сейчас работает хорошо?
- Чем ты сам сейчас не доволен?
- Чем сейчас довольны и недовольны заказчики
- Какие ожидания не выполняются? Сроки? Предсказуемость сервиса?
- Понятно ли на какой стадии работа? Когда будет завершена?
- Качество работ устраивает?
- На какие темы чаще всего возникают дискуссии?
- Возможно, есть какие-то явные или скрытые конфликты отделов/сотрудников, которые ты ощущаешь?
- Чем сейчас довольны и недовольны участники команды/отдела
- Нравится ли формат и режим работы?
- Что замедляет их работу?
- Часто прерывают?
- Часто ли задача заблокирована другими?
- Хорошо ли ставятся задачи?
- Возможно, что-то мешает улучшать процесс работы/совершенствоваться?
- Есть ли что-то, что регулярно мешает делать работу так качественно, как хотелось бы?
- Есть перегрузка? Переработки?
- Какие планы по развитию команды и бизнеса? Что ждет всех в ближайший год?

О процессах

- Что вы выпускаете? Что для тебя является единицей завершенной работы? Перечисли
- Откуда обычно появляются задачи?
- Опиши по любой задаче ваш процесс работы
- Как вы выбираете что делать? Как работают приоритеты?
- Как вы ведете учет своей работы, визуализируете её?
- У вас есть доска команды? Поделись ссылкой
- Как узнать текущий статус работ?
- Как узнать, что задача заблокирована и работа не ведется?
- Часто ли у вас задачи с дедлайном?
- Как измеряете процесс?
- Какие есть регулярные встречи, ритуалы, какие действия предпринимаете после них?
- Бывает ли, что делаете работу, которая потом оказывается не нужна?

Советы

- Что можно быстро изменить?
- На что нужно обратить внимание в первую очередь?
- Чего нужно остерегаться?
- С кем еще стоит пообщаться? Что нужно прочесть и изучить?
- Дай мне любой совет

Автор @britishpop
А еще там же мелькал ассесмент https://docs.google.com/document/d/1GxBAhQbhz_86Fd2qpH1qhh8Vtf_wbUyAYI5ZLhmVJbo/edit?tab=t.0

#кейс_стади
Задача на подумать для менеджера

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

Ситуация:

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

На стороне клиента есть три заинтересованных отдела:

1. Отдел продаж хочет увидеть увеличение числа успешных сделок.
2. Отдел поддержки клиентов заинтересован в уменьшении времени на обработку заявок.
3. IT-отдел требует данных о стабильности системы (аптайм, число критических ошибок).

Проблема:

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

Вопрос:

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

#кейс_стади
Задача на подумать для менеджера

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

Ваша роль

Вы — руководитель проектного офиса в IT-ГАЗМЯС, отвечаете за управление программами проектов, процессы проектного управлеиня, распределение ресурсов и отчетность перед топ-менеджментом.

Ваш контекст

Ваша компания разрабатывает IT-продукты для родительской компании ГАЗМЯС, структура матричная. Новый топ-менеджер делает акцент на детализации отчетов и личном участии руководителей в работе над проектами.

Ваша проблема

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

Ваши действия

Вы уже предприняли следующие шаги:

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

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

Главный вопрос

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

#кейс_стади
Задача на подумать для менеджера

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

Ваша роль

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

Контекст

Компания специализируется на создании высоконагруженных систем для анализа и визуализации данных, которые используют трейдеры. В команде — 8 разработчиков, 3 тестировщика, дизайнер, и 2 аналитика. Процессы построены на Scrum, задачи распределяются через Jira,. Ключевые клиенты компании требуют быстрой реакции на изменения и высокую точность работы системы.

Проблема

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

Эти разногласия приводят к:

- Постоянным пересчетам капасити команды.
- Задержкам с датой код-фриза.
- Ругани в кулуарах.

Ваша цель

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

Другие действующие лица

- Разработчики. Их интерес — делать задачи с хорошими техническими решениями, которые легко поддерживать.
- Тестировщики. Хотят, чтобы их время на проверку учитывалось наравне с разработкой.
- Дизайнер. Настаивает на том, что его работа должна стать частью приоритетов.
- Продакт-овнер. Заинтересован в соблюдении дедлайнов и запросов от клиентов.

#мнение
Нейросети всех заменяют!

Полно таких кликбейтных лозунгов (тут кстати тоже). Но что я пока вижу на деле поделюсь ниже.

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

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

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

- LLM Arena — актуальные по мощности нейросети и их ранкинг: https://lmarena.ai/?leaderboard
- AI For That — нейросетевой поисковик для нейросетей. Позволяет легко подбирать под конкретную задачу сервис и смотреть его юзкейсы: https://theresanaiforthat.com/
- Промтгайд — вводный тестовый курс про промптинг: https://www.promptingguide.ai/
- Промпт хиро — сборник хороших промптов: https://prompthero.com/
- Ведущие принципы качественных промптов — https://github.com/VILA-Lab/ATLAS. Ребята провели крутое исследование и опубликовали результаты.

P.S. Для чего я сам планирую использовать нейросети и что мне удалось накопать. А особо ничего — сейчас больше это для развлечения и совсем небольшой помощи. Действительно что-то автоматизировать или заменить, не на уровне говорящей головы, ничего не может. Но я в процессе поисков.

Генерация идей
Да, нашел пару сервисов. Но мое буйное воображение все равно справляется лучше

Создание скелетонов и набросков
Ничего нет толкового.

Хуманизация текстов
Да, есть пару сервисов, но они не палятся лишь при чеке другими нейросетями. Опытный глаз легко видит работу нечеловека.

Грамматика и ошибки
Тут навалом, много крутых сервисов.

Суммаризация и упрощение информации
Есть 2–3 игрока, но они достаточно бестолковые и под капотом GPT-3.5.

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

Репурпойзинг (когда из большой статьи делается сторис в инстаграм)
Ничего нет на рынке

Генерация визуала
Тут много крутого, и уже очень далеко продвинулись. Но нормально писать текст на картинке еще никто не умеет.

Сторителлинг
Есть 2 сервиса которые хорошо как развивают истории, так и пишут с нуля. Но без готового скелета и действительно расписанного черновика генерят скучные вещи

Шутки, мемы, геги, реддит-триггеры
Действительно что-то забавное ничего особо делать не умеет

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

Написание автоматизаций и файлов
Есть пара крутых игроков, но по сути gpt-o1-pro справляется лучше.

Факт-чекинг
Никто пока не справляется

Поиск среди научных публикаций и обоснованных исследований
Есть несколько попыток, но результаты грустные

Вовлечение аудитории
Навалом сервисов, которые генерят заголовки, seo/aso теги

Выдержка тон-оф-войс и бренд стиля
Есть 3 хороших сервиса, но за просто космический прайс

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

#кейс_стади
Задача на подумать для менеджера

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

Ситуация

Ты управляешь четырьмя проектами, и на одном из них команда выросла с 5 до 9 человек из-за увеличения задач. Операционка стала забирать всё время: нужно контролировать, кто что делает, решать мелкие конфликты, следить за сроками. Ты понимаешь, что пора назначить тимлида, чтобы разгрузить себя и наладить работу внутри команды

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

Проблема

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

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

Максим — самый энергичный и амбициозный. Ему нравится решать проблемы и брать ответственность за сложные задачи. Он горит желанием развиваться и готов работать сверхурочно, чтобы доказать свою ценность. Но у него пока не так много опыта, и не все в команде воспринимают его как равного. Однако лучше всех разбирается в новых технологиях и у него отличные навыки ментора, так как он участвует во многих менторских программах и является энтузиастом разработчиком, контрибьютящим в Open JDK и некоторые крупные npm пакеты

Вопрос

Ты выбрал Екатерину, потому что веришь, что её подход поможет команде стать более сплочённой. Но что, если её нерешительность или недостаток уверенности приведут к проблемам? Это правильное решение?

#кейс_стади
Задача на подумать для менеджера. Итоги эксперимента

Привет, читатель!

Как ты уже, наверное, заметил, последние 5 рабочих дней я публиковал каждый день с утра по одной управленческой задаче. Это был экспериментальный контент. Хотелось проверить, зайдёт ли такой формат, оживит ли он активность в канале и не станет ли мне накладно его писать

Спойлер: "накладно не стало!" Более того, я пишу посты примерно на неделю вперёд, и проблема скорее в том, чтобы выбрать из кучи тем для кейсов, чем придумывать что-то новое

Теперь к сути. Перед запуском этого эксперимента у меня было несколько гипотез:

1. Если выпускать задачи утром (в районе 9–10 по Москве), это будет удобно для аудитории. Думал, что такой тайминг даст 2–3% прироста вовлечённости;
2. Ежедневный контент покажет, что канал более живой и активный чем обычно. Это должно было привлечь новых подписчиков — хотя бы на 20–30% больше обычного;
3. Если публиковать кейсы в формате открытых вопросов, это увеличит количество реакций и комментариев.** Ожидал прироста на 20% день ото дня.

Что же получилось на практике?


1️⃣ Утренний тайминг
Утро оказалось действительно удобным временем. Большинство просмотров собирается в первые 1–2 часа после публикации (до 57% от общего охвата). Но, увы, прироста вовлечённости на 2–3% не случилось. ERR держится в привычном диапазоне 16–24.8%.

2️⃣ Ежедневные посты
Тут интересно. Активность подписчиков стабильна, но бури новых подписчиков не случилось. За месяц +14 человек — это примерно в рамках стандартного роста. То есть аудитория оценила регулярность, но это не сделало канал виральным

3️⃣ Формат открытых кейсов
Комментарии есть, но их мало (0–2 на пост). Реакций тоже немного (в среднем 12–20). Ожидаемого прироста на 20% не произошло. Видимо, чтобы разговорить аудиторию, нужно искать другие подходы — пока этот формат работает, но без фейерверков

Дополню двумя наблюдениями

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

5️⃣ Регулярность
Честно, ежедневный постинг требует дисциплины, но для меня это пока нормально. Заметил, что слишком частые публикации (каждый день) могут слегка "примелькаться", и ERR остаётся на том же уровне, что и при менее частом постинге. Может, стоит подумать над форматом "пост через день" или миксовать с чем-то большим и более глубоким

А теперь мне интересно твоё мнение! Понравился ли тебе этот эксперимент с задачами? Стоит ли продолжать?

👉 Оставить детальную обратную связь можно по этой ссылке

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

P.S. Что будет дальше - я возьму паузу до конца недели собрать обратную связь и подумать что делать с форматом. А еще вечером сегодня запущу новый, также ради теста!

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

#напутствие
Еще новый тип постов

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

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

#напутствие
Почему я работаю менеджером

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

#напутствие
Почему я работаю менеджером

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

#мнение
Опять про сторипойнты и эти оценки из agile

Здравствуй, читатель! Почему относительные оценки — не серебряная пуля, но работают (иногда)

Когда речь заходит об оценке задач в а-жаль, всегда найдутся те, кто скажет: "Story Points спасут мир!". Смотри, это точнее, проще, удобнее! А абсолютные оценки (в часах или днях) — прошлый век. Давай в очередной раз разберемся: так ли это на самом деле?

Спойлер: Story Points — не магия и не гарантия успеха. Они не сделают вашу команду суперточной машиной по оценке. Но есть очевидные плюсы, которые часто упускают

Почему Story Points не идеальны?

1) Неточность заложена в подход

Оценки всегда субъективны. Что абсолютные, что относительные. Разница лишь в том, что Story Points маскируют вашу неуверенность под "умные" числа. И ими проще отбиваться от чрезмерного микроменеджмента. Как выяснилось из исследования https://onlinelibrary.wiley.com/doi/full/10.1002/spe.3333, опыт команды почти не влияет на точность. Даже эксперты могут ошибаться — просто чуть реже, чем новички;

2) Они не универсальны

Если вы работаете с новичками, они могут переоценивать простые задачи и недооценивать сложные. Если команда не привыкла к Story Points, результат будет таким же хаотичным, как и при абсолютных оценках;

3) Игра в покер — это не всегда весело

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

Но у них есть плюсы. И важные:

1) Они учат команду думать вместе

Когда вы обсуждаете задачу в формате "это сложнее, чем то, что мы делали вчера?", появляется общая картинка. Команда начинает лучше понимать друг друга и проект;

2) Они помогают избежать споров про часы

Story Points не про время, а про усилия. Это убирает ненужные разговоры вроде: "Как ты можешь делать эту задачу 8 часов, если я бы сделал за 3?";

3) Они проще адаптируются под реальность

Если что-то пошло не так (а в Agile это почти гарантировано), Story Points легче перенастроить, чем абсолютные оценки;

4) Они делают планирование менее неприятным

Никто не уходит с планирование с ощущением, что ему "выставили счёт". Все понимают (если это адекватно внедрено), что оценки — это инструмент, а не правда в последней инстанции.

Что важно помнить, работая с Story Points?

1. Planning Poker — это не про числа, а про общение

Не нужно затягивать процесс. Если вся команда согласилась на одну оценку — не тратьте время, идите дальше;

2. Делайте ретроспективы оценок

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

3. Не превращайте Story Points в часы

Как только начнёте говорить "1 SP — это примерно 2 часа", весь смысл метода исчезнет;

4. Сравнивайте внутри спринта

Самое главное — держать контекст. Оценки становятся хаотичными, если вы сравниваете задачу из прошлого года с тем, что делаете сегодня.

На эту тему я уже писал раньше:
- Почему Story Points — это не ловушка https://t.me/junior_pm/99
- В целом про оценки https://t.me/junior_pm/167

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

P.S.
Story Points — это не серебряная пуля. Но если использовать их правильно, они делают команду сплочённой, а процесс оценки — осознанным и менее токсичным. А если вы ещё не пробовали Planning Poker — самое время начать.

Что думаете? Как у вас проходят оценочные сессии? Делитесь опытом в комментария

#напутствие
Почему я работаю менеджером

Половина команды в отпуске, заказчик пишет капсом, а релиз уже завтра? Ты не волшебник, но точно найдёшь, как закрыть дыры. Приоритизация, временные костыли и пара срочных звонков – и ты снова превратишь хаос в управляемый бардак. Главное, ты всегда держишь процесс под контролем. А еще не забывай про крепкие словца

#напутствие
Почему я работаю менеджером

Неделя заканчивается, а то, что обещали закрыть, всё ещё висит в воздухе. Ты-то знал, что так и будет, но вместо паники – чёткий план: выдели главное, собери команду, зафиксируй, что реально можно сделать сразу в начале недели и уже показать что работа не стоит на месте и дай возможность четко отслеживать прогресс. Время на нытье– после дедлайна, сейчас важно довести до финиша что-то полезное. Все всегда сделать нереально

#рецепты
Вводим больше бюрократии с помощью DoD. Часть 1

Здравствуй, читатель!
Последние полгода я, признаться, выключил DoD из наших процессов. Причина — бизнес-критикал кейсы, которые требовали моего максимального вовлечения. Иногда я работал буквально как эникейщик: от настройки инфраструктуры до тестирования багов. Мы даунгрейдили процессы ради выживания. Теперь же я возвращаю DoD и хочу рассказать, почему это намой взгляд важно

Сперва как обычно немного теории, чтобы выровняться и говорить на одном языке

Что такое DoD?

Definition of Done — это минимальные требования, которые должны быть соблюдены, чтобы задача считалась выполненной. Это не про конкретную задачу, а про общий стандарт качества. DoD отвечает на вопрос: как мы поймём, что работа сделана качественно? Например: тесты пройдены, документация написана, код соотв. принятому стилю. Если DoD выполняется по всем задачам, можно “почти быть уверенным” в качестве итогового продукта

Махровая теория: quality gate и shift left

DoD — это часть двух больших концепций: quality gate и shift left. Quality gate — это контрольные точки, где проверяется качество на каждом этапе работы. Shift left — это перенос проверок качества на более ранние стадии, чтобы выявлять проблемы как можно раньше. В этом контексте DoD — это финальный quality gate, который гарантирует, что результат полностью готов

Чем отличаются DoD, DoR и AC?

Их часто путают. Хотя все три — это quality gate, их роли различны:

- DoR (Definition of Ready): требования к задаче, чтобы её можно было начать. Если задача переходит от менеджера к команде, то DoR — это чеклист для менеджера. Например, задача должна быть чётко описана, иметь все входные данные и учтённые зависимости;
- AC (Acceptance Criteria): требования к тому, как должен вести себя результат задачи. Это простой перечень того, что результат должен уметь, чтобы заказчик сказал: «Да, это то, что мне нужно»;
- DoD: критерии, которые показывают, что задача выполнена с должным качеством. Это не только про соответствие ТЗ, но и про тесты, документацию, ревью — всё, что делает результат стабильным и готовым к использованию.

Почему DoD — «дорогая» практика?

DoD — это инвестиция, которая требует усилий.

1. Ресурсы. Нужно время на написание тестов, документации, проведение ревью;
2. Замедление работы. На первых этапах команда работает медленнее, но это снижает количество багов в будущем;
3. Повышение планки. Например, если в DoD прописано писать юнит-тесты или релиз-ноутсы, команда должна этому научиться;
4. Долгосрочная выгода. В будущем DoD снижает затраты на доработки, стабилизирует продукт и улучшает отношения с заказчиками.


В следующем посте я расскажу, как мы вернули DoD, какие шаги предприняли и какие трудности пришлось преодолеть

P.S. Если хочешь вспомнить и другие похожие аббревиатуры, загляни в https://t.me/junior_pm/35 😉
P.P.S. А еще мы решили вернуть DoD потому что стали забывать некоторые важные вещи делать и он позволяет не забывать

#полезности
Вводим больше бюрократии с помощью DoD. Часть 2

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

1. Собери команду. Важно, чтобы разработчики, тестировщики, менеджеры и любые другие ключевые участники обсудили, что они понимают под «готовностью»;
2. Проведи воркшоп. Вместе составьте список минимальных требований для всех типов задач (баги, фичи, техдолг). Это должна быть командная работа, чтобы все приняли DoD как свой инструмент. Важно учесть что для разных типов работы может быть разный DoD. Мы пока сделали только для фичей;
3. Протестируй DoD. Введите его на несколько спринтов, фиксируя проблемы и улучшения;
4. Закрепите DoD. После тестирования утвердите DoD как обязательный стандарт.

Важно, чтобы DoD пересматривался на ретроспективах (если их нет, то вообще была опция его обсудить и пересмотреть). Это живой документ,

Почему DoD должен охватывать весь процесс команды, а не только финальный этап

DoD часто воспринимают как чеклист для последнего этапа перед релизом. Это ошибка. Если DoD ограничивается только финальными шагами, проблемы накапливаются в процессе разработки.

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

DoD должен покрывать весь процесс. Условно:

- Стадия планирования: план разработки, систем ревью. Тут важно держать баланс с DoR;
- Стадия разработки: код проверен и покрыт тестами;
- Стадия тестирования: все критичные дефекты устранены;
- Стадия релиза: релиз-ноутсы оформлены и фича работает на проде.

Такой подход предотвращает «эффект снежного кома», когда небольшие недочёты превращаются в крупные проблемы.

Наш текущий DoD:

Вот текущий DoD, который мы используем в моей команде:

- Фича-флаг Firebase (если применимо);
- Ремоут-конфиг Firebase (если применимо);
- Диплинк (если применимо);
- Написан юнит-тест или заведена задача на его написание;
- Описание, как ревьюить;
- Описание, как тестировать;
- Заполнен дев-компонент;
- MR направлен в корректную ветку;
- Пройден код-ревью;
- QA обеспечивает тестовое покрытие (тест-кейс, чек-лист и т.д.);
- Задача протестирована, есть комментарий с результатом;
- MR влит в корректную ветку.

Это не-универсальный набор для любой задачи, пока только для сторей

Как я устанавливал и дорабатывал DoD заново

После периода «выключения» DoD я начал возвращать его шаг за шагом.

1. Анализ ситуации. Я оценил, почему прошлый DoD не сработал, и какие элементы команды были не готовы соблюдать. Например, отсутствие знаний в написании тестов или отсутствие документации. В нашем случае он был слишком абстрактным и неконкретным;
2. Собрание команды. Мы провели (и еще проведем) несколько встреч, где обсудили ценность DoD и его влияние на продукт. Важно было убедить команду, что DoD — это не просто бюрократия, а инструмент, который помогает;
3. Постепенное внедрение.** По-хорошему стоит добавлять элементы DoD не сразу, а поэтапно. Сначала — ревью, потом написание мануал тестов, затем тесты документации и так далее. Это позволит избежать перегрузок команды одномоментно;
4. Регулярные проверки. Мы обсуждаем, что работает, а что — нет. Некоторые пункты придется доработать. Например, упростить требования к юнитам;
5. Закрепление. После тестового периода я закреплю DoD как обязательный стандарт. Но уже он — неотъемлемая часть наших процессов.

В общем в лучших традициях ADKAR

#иное
Итоги эксперимента с задачками и напутствиями

Последний месяц я тестировал два новых формата контента:
1. Управленческие задачи (#кейс_стади) — короткие кейсы для размышления
2. Напутствия (#напутствие) — мои поддерживающие мысли о работе, управлении и бытии руководителем

Эксперимент получился интересным, но не всё зашло так, как хотелось.

Что с задачками
Ежедневный формат не сработал так, как я рассчитывал.

— Усталость аудитории: многие отключили уведомления, часть подписчиков просто перестала читать;
— Комментариев и реакций оказалось меньше, чем ожидалось: 2–5 комментариев, 12–20 реакций на пост;
— Тайминг с утра работает: 57% просмотров в первые два часа, но вовлеченность не выросла.

Что меняю:
— Больше не каждый день, а 2–3 раза в неделю

— Буду разбирать решения и показывать своё мнение через 1–2 дня после кейса

— Добавлю голосования и варианты решений

Что с напутствиями
Этот формат работает лучше.

— Реакций на такие посты больше, чем на задачки;
— Помогает создать настроение на день, но важно не загонять себя в однообразные советы;
— Лучше заходят посты с личными историями, чем абстрактные мысли.

Что меняю:
— 1 раз в неделю, а не чаще
— Добавлю больше историй из жизни и работы

— Чередую стили: не только мотивация, но и ошибки, инсайты, неожиданные выводы

Адаптированный контент-план

📌 Понедельник — управленческая задача, голосование, обсуждение
📌 Вторник — разбор кейса;
📌 Среда — напутствие;
📌 Четверг — что-то еще;
📌 Пятница — напутствие.

Протестирую этот формат 2 недели, потом соберу обратную связь. Между ними нерегулярные средние посты и крупные. Пока я попробую еще себя в эссе и сторителинге.

Если есть мысли или предложения — пиши в комментарии!

#рецепт
Cписок книг для начинающих менеджеров проектов

Привет, читатель

Я принес для тебя еще чтиво, правда, не мое, но очень уважаемых товарищей. Если ты уже умеешь ставить задачи в Jira, но не понимаешь, почему все застряло в «in progress» на третью неделю — возможно, дело не в Scrum, Kanban или волшебных методологиях, а в фундаменте.

В статье на habr, linkedin или vc можешь прочитать подробнее, а здесь будет выдержка.

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

📌 «Общее и промышленное управление» — Анри Файоль

Файоль выделил 5 функций менеджмент*: планирование, организация, руководство, координация и контроль. Это не скучная теория, а каркас, на который ложатся все современные практики управления.

📌 «Принципы научного управления» — Фредерик Тейлор

Как выжать максимум из системы? Тейлор заложил основы эффективности, которые работают даже сейчас (с огромными оговорками, но он прадедушка, его знать надо).

📌 «Эффективный руководитель» — Питер Друкер

Главный вопрос Друкера: «Что делает менеджера по-настоящему эффективным?». Книга поможет не путать «занятость» с результативностью.

📌 «Динамика администрирования» — Мэри Паркер Фоллетт

Если Друкер — про эффективность, то Фоллетт — про лидерство и влияние. Классика, которая объясняет, как управлять не командуя, а направляя.

📌 «Экономический контроль качества продукции» — Уолтер Шухарт

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

📌 «Управление проектами: быстрый старт» — Дмитрий Завертайлов

Практическое руководство: как стартовать проект без погружения в теоретические дебри.

📌 «Канбан Метод. Базовая практика» — Алексей Пименов

Как сделать так, чтобы Kanban не превратился в «вот тебе доска, и сам разбирайся».

📌 «Антихрупкость в IT» — А. В. Бындю

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

📌 «OKR. Инструмент, который изменит вашу компанию» — Нивен, Ламорт

Не «давайте придумаем KPI», а как действительно ставить осмысленные цели.

📌 «Коучинг agile-команд» — Лисса Адкинс

Scrum-мастерам и agile-менеджерам сюда. Про командную динамику, рост специалистов и эффективное лидерство.

Вывод:

Фреймворки и методологии — это инструменты. Но если не понимать зачем, любые Agile-практики превращаются в пляску с бубном. Освой базу, и тогда ты сам будешь решать, какой метод выбрать: кроль, брасс или баттерфляй.

P.S. Да, все эти книги читаются не за один вечер, но PM без базы — это Моисей без скрижалей
P.P.S. Дополнительно советую еще 2 книги: «Проджект-менеджер маминой подруги» — Семена Колосова (кстати там есть небольшой фрагмент от меня) и «Карьера менеджера IT-проекта...» — Г. Лакман Макдауэлл, Д. Баваро, что также будет очень полезно до начинающих/

#кейс_стади
Задача на подумать для менеджера

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

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

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

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

Ты обсуждал с Вадимом эту ситуацию. Он соглашается, что "не все идеально", но добродушно утверждает, что всё исправится. Каждый раз, когда что-то идет не так, он говорит: *«Разберусь»*, но ты не видишь, чтобы он брал на себя реальную ответственность или предпринимал системные шаги для решения проблем. Он скорее тушит пожары, чем предотвращает их

Ты уже попробовал несколько способов изменить ситуацию:

- Давал Вадиму развивающую обратную связь;
- Организовывал для него менторинг;
- Собирал на него широкоформатную обратную связь;
- Его руководитель даже открывал ему испытательный срок, но затем без объяснения причин закрыл его.

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

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

P.S. Весь ваш фидбэк учел и кейсы будут более конкретными, редкими, с вариантами и моим разбором

#кейс_стади
Задача на подумать для менеджера. Разбор

Задача с Вадимом вызвал обсуждение, и неслучайно — у многих есть похожие ситуации, когда сильный технический специалист оказывается на управленческой роли, но не справляется. У каждого был/есть свой Вадим. Это не проблема Вадима как человека, это проблема системы, которая допустила такую ситуацию и не меняет её.

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

В таких ситуациях решения нужно принимать одновременно в двух горизонтах:

1) Краткосрочное — найти костыль, который закроет управленческие провалы Вадима. Это может быть сотрудник в его команде, которому формально или неформально добавляются функции управления, или сам менеджер, который временно берет процессы на себя.
2) Долгосрочное — на позиции Вадима должен оказаться другой человек, обладающий не только техническими компетенциями, но и управленческими навыками

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

- Представление о лучшем будущем
- Желание значимого лица изменить статус-кво
- Безопасные шаги для перехода к новой системе

Если этих факторов нет, любые разговоры о развитии останутся без последствий

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

Дальше начинаю фиксировать всё в формате: дата – ситуация – пример (ссылка, скриншот) – что стоило сделать иначе. Когда накапливается достаточно данных, собираю кейс-эффект диаграмму, где фиксирую системные проблемы, их причины и следствия. Это даёт целостную картину: какие конкретно ошибки ведут к каким последствиям

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

В ситуации с Вадимом я поступил именно так: за месяц собрал 22 кейса, визуализировал их влияние и представил его руководству. Этого оказалось достаточно. В итоге произошло перераспределение ролей среди DevOps-лидов, и к нам пришёл новый человек, который действительно занимался процессами. Стало проще и команде, и бизнес

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