Как писать статус-репорты

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

Автор статьи рассказывает про набор советов, которыми он руководствуется при написании таких отчетов. Некоторые мне кажутся странненькими, но вот те, которые точно утащу себе:

👉Регулярность переоценена. Вместо того, чтобы публиковать отчет по строгому расписанию, лучше делать перерывы разной продолжительности – иногда неделю, иногда три. Так будет создаваться ощущение, что у вас действительно появилась новая и интересная информация, и вероятность прочтения отчета повышается.
👉Если для вас такой режим подходит, то попробуйте headline driven development. Заранее запланируйте, когда будете писать следующий отчет, и к этому моменту постарайтесь сделать что-то весомое в проекте.
👉Всегда любой отчет начинайте с TL;DR в одно предложение и с короткого напоминания целей проекта. Во-первых, список читателей мог поменяться. Во-вторых, это для вас ваш проект – центр мира, а остальные люди его могут не держать в голове. В-третьих, любые новости проще воспринимать в общем контексте.
👉Все любят приятные сюрпризы. Можете заранее прикинуть, что может быть таким сюрпризом, и целенаправленно подготовить его для включения в отчет.
👉Если в проекте произошли какие-то изменения, особенно те, которые противоречат опубликованным вами ранее отчетам, обязательно в явном виде про них напишите. Неявные изменения могут легко привести к поломанным ожиданиям, а те к политическим проблемам.
👉Держите в голове три основных вопроса, которые могут быть у вашей аудитории, и постарайтесь на них ответить.
👉Если в проекте случились какие-то проблемы или появились новые риски – о них тоже стоит ясно рассказать. При этом обязательно упомяните, что вы будете с ними делать.

Команда, напоминаю, что впереди ещё два рабочих дня. Уточняю: два именно рабочих дня. Почему у нас вместо воды в кулере коньяк? Я два стакана с утра случайно выпил. Думал просто вода ржавая. Уже час пою караоке и вынужден слегка дебоширить. Те, кто совершил такую же ошибку, как и я - заходите в переговорку: у меня тут кальян, закуски и азартные игры. Ко всем остальным просьба не прерывать рабочий процесс. Всем дня!

#пятничное
Сегодня очень странная пятница, вторая на неделе😁

🔥 - если вы хотите FW FW FW
👍 - чисто поддержать

@badtechproject

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

Канал вырос и надо больше маны, чтобы постить сторис 😉
Жмите кнопку)))

Расскажу связь между проектами и шашлыками 🤣🤣🤣

#личное

@badtechproject

Ну че, народ, пошла жара 🙈
Наконец-то меня позвали на South Hub - кэмп для C-Level в IT 🔥

Тут все, как мы с вами любим:
- топ менеджмент, который расскажет про развитие технологий, здоровое управление командой и прочее
- невероятно крутой нетворкинг
- work life balance: утром пробежка, днем знания, вечером жаркие дискуссии
- Красная поляна в окружении Кавказских гор и море свежего воздуха

Конечно же боссам я сказал, что поехал работать.

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

Ну и промокод на скидку 5% - SH24BadTechProject
Билеты по ссылке

@badtechproject

«Он нас посчитал» или оценка состояния производственного конвейера Часть 1

История с оценкой работ программистов имеет древние корни, много подходов в свое время отмели (вы же не оцениваете по строчкам кода, да?), много осталось.
Современный подход - Story Points.

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

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

Картинка, которая приложена к посту, отлично иллюстрирует разницу между Time to Market и LeadTime.

❓Так что же такое LeadTime? LT - время от момента взятия обязательств делать задачу до ее поставки. Работает она хорошо только на масштабе. То есть, мы должны наработать статистику, посчитать 85% перцентиль (это бест практис мировой) по LT. Тогда, при поступлении новой задачи мы сможем с данной вероятностью оценить срок ее реализации. Если LT у нас 53 дня, то +/- в этот срок мы и уложимся.

🙋‍♂️ Но в чем же проблема этой метрики?
А тут все просто, как и у любой другой метрики, если людям начать платить только за нее, то они могут начать выпускать продукт с дефектами, экономить время на написании автотестов, забить на надежность, построить заграждения из кучи бюрократии . Так, что одной метрики вам точно не хватит.

👉🏼 Стоит обложиться и кучей других: надежность, покрытие автотестами, кол-во дефектов в проме, кол-во тех.долгов и прочее.

❗️ А самое вкусное в этой метрики для менеджера то, что разложив ее на составляющие можно будет выявить узкие места/ бессмысленные простои (когда вы все ждете запуска джобы, которая почему-то запускается только раз в неделю или согласования некоего эксперта и т.п.).

💛 Вот тут уже есть где менеджеру разгуляться, устраняя все эти проблемы в конвейере, выравнивая процессы и занимаясь вот этой вот менеджерской работой (обожаю ее❤️).

🏭 А почему я заговорил про LT?
Управление разработкой - это множество параметров. Нет единого показателя, который нужно улучшать. Есть совокупность метрик.
При этом LT - хороший интегральный показатель, отражающий общее здоровье конвейера

🏎️

А делать сложные проекты - это как переделывать на ходу Феррари на Ламборджини.

🔥 - знаю все текущие метрики в своем производстве, есть план по улучшению.
👍 - задумался, пошел гуглить и считать.
❤️ - чисто поддержать.

@badtechproject

Цель 🎯

Один из форматов книг по менеджменту, которые мне нравятся - это те, где рассказываются истории.
В них есть главный герой, «дракон» с которым он сражается и приз, который заслуживает.

Сейчас кайфую от Цель Голдратта.
Она максимально своевременна для меня и отражает важную мысль:
👉🏼задача менеджера находить узкие места в производственном процессе и «расшивать» их.
Больше мы почти низачем и не нужны.

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

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

🔥 - ищу узкие места в процессах и «расшиваю» их
👍 - книга гуд, читал
🫡 - побежал читать

@badtechproject

Как выстраивается гибкое и эффективное управление разработкой — Фичи катятся, выпуск номер два!

И вот, долгожданный (мной), второй релиз, где мы с Виктором Никишиным разгоняем про то, как управлять разработкой в 2k24 году. Получился отличный двухчасовой выпуск (дада, я люблю поговорить), в котором мы достаточно глубоко и детально прошлись по концеции Agile Flight Levels, обсудили философию гибкого управления разработкой, метрики и уровни управления, выяснили почему личные метрики зло, а производственные метрики - лишь сигнальная модель, какие бывают подходы к стратегии, зачем и как готовить OKR и много всего)

Витя большой руководитель в Тинькофф, занимается оптимизацией end-to-end процессов и отвечает за эффективность процессов в 4 управлениях разработки, работающих над мобильным и интернет банками, социальной платформой и еще пачкой продуктов меньшего масштаба, общим объемом это порядка 900 разработчиков.

https://www.youtube.com/watch?v=46d6hBcFevI

Если понравился видос: лайкате, пишите комментарии, делитесь с коллегами и друзьями по цеху!

Метрики или за чем следить на вашем конвейере_Часть 2

Продолжим рассматривать метрики разработки под пристальным углом (Часть 1).

📈Как прошлый раз писал - LeadTime очень хороший интегральный показатель и стоит использовать его в качестве индикатора здоровья производственного процесса и, конечно, улучшать.

🤑 Однако, как только любая метрика попадает на контроль или того хуже, от нее начинает зависеть бонус менеджера любого уровня, то у него (менеджера этого!) возникает желание читерить.
Что же тогда делать?

🎭 Идеальный вариант - развитие культуры производства.
Но будем честны, процессы в любой корпорации строятся не для высокоорганизованного, высокомотивированного сотрудника, который работает не за бонус, за идею.
Они (процессы эти) строятся под среднего специалиста, работающего с 9 до 18.

❓Так что делать?
Правильно, добавить еще метрик.
Как определить, какие метрики добавить? Поставить себя на место того человека и подумать, как он будет читерить.

⁉️Как бы читерил я?

1️⃣ Не правил баги.
Вводим расчет %дефектов в проме.

2️⃣ Забил бы на надежность продукта.
Вводим показатель надежности и его оценку.

3️⃣ Ввел бы бюрократию, чтобы как можно меньше задач попадало на конвейер, а там может и релизиться было бы нужно все реже.
Вводим показатель Deployment Frequency, с кол-во фичей в поставке.

4️⃣ Гнал бы разработку вперед и плодил архитектурный тех.долг. Вводим метрику - Архитектурный тех.долг.

И далее, далее, далее.

❗️Что важно?
Метрики - это всегда холиварная история. Вы можете бесконечно спорить, что вам измерять. Это будут настоящие конфликты, возможно даже драки.

Однако, вы всегда должны держать в голове следующее:

👉🏼 Измерять нужно то, что болит или имеет значение.
👉🏼 Измерять и ничего не улучшать - бесполезная трата времени.
👉🏼 Ваша задача развивать бизнес и если ему не нужно ускорение, значит не тратьте время.
👉🏼 Метрики подскажут вам многое, но команды расскажут еще больше. Регулярно общайтесь с командами.
👉🏼 Если ищете повод поругаться с коллегами, предложите им ввести новые метрики.🤣

Обратите внимание, пока мы все время говорим только о правой части конвейера и ни слова о его левой части, где бизнес и меняющийся скоуп и требования 😉

👍 - в курсе всех значений метрик своего производства
🫡 - пошел их считать и делать дашборд
❤️ - деду опять не дали таблеток, поддержим его.

#career

@badtechproject