«Хочу ли я с тобой работать»

У нас в компании есть система оценки инженеров (мы ее называем rs-devs). Суть ее в том, чтобы дать оценку инженеру на предмет того какую задачу без микроменеджмента можно разработчику поручить, а проставляет оценки в идеале всегда заказчик (у нас это менеджеры). Уровни задач L10, L20, L30.

Условно, если у разработчика L30 оценка по пятибальной шкале 5, это означает что задачи самого сложного уровня такому разработчику можно дать без микроменеджмента вообще.


Одна с ней проблема - сложность понимания критериев уровня L30 и L20. А еще было сложно понять перспективы человека — ну, сейчас оценка низкая, но это он растет медленно но вырастет, или нет?

И вот, руководитель производства на звонке собрал всех руководителей подразделений и попросил каждому проставить оценку «хочу ли я с ним работать».

1 — не хочу,
2 — только если нет альтернатив,
3 — норм, хочу,
4 — в идеальной вселенной только с такими бы и работал, моя dreamteam.

Просто, лаконично.

Выяснилось, что у нас 34 человека с оценками 1,2. В оценки попали и разработчики которые по хардам сильные, но проактивность — «не пнешь — не пошевелится». Кстати, это наглядная демонстрация для инженеров, которые занимают чисто кодерскую позицию — ваши хардскиллы никто не ценит если вы не проявляете активность.

Мы это исправим в самом обозримом будущем. Работаем!

Мы ищем HRD

Нам нужен HRD, требования к которому и примеры задач описаны здесь.
Работа с людьми - сложная
Если вкратце, нам нужен человек, который всегда удостоверится в качестве обратной связи сотрудникам - чтобы недовольство команды не было для них сюрпризом (вот буквально недавно выявили 2 случая, когда команда высказывала недовольство, и HR должны бы помочь сотруднику понять градус этого недовольства), и человек, который любит метрики и концепции.

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

Если вы хотите в data-driven культуру, иметь миллион метрик касательно любого разреза HR но при этом иметь огромной потенциал для их совершенствования - пишите!

Мечта касательно нашей большой и амбициозной цели:
YT: https://youtu.be/7nCMgg2gvx8
Rutube: https://rutube.ru/video/private/ecd718497e63cf05f009a6027de2d11f/?p=sqJu45RUtfBqZ3dDoh1Z2A

Я всё еще ищу формат совмещения Youtube и TG постов.

Попробую так - в этом канале выкладывать свои мысли быстрее Youtube, но в youtube более edutraiment формат.

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

Выкладывайтесь сразу на продуктив
Мы долгое время повторяли как мантру, что нужны тестовые стенды. Вот есть мол продуктив, а есть какие-то тестовые стенды. Разработчики ещё говорят что dev стенды нужны. Управленцы смотрят на это и соглашаются, но это - Муда, потеря, которой нужно давать бой, ведь это противоречит парадигме бережливости (Agile) и вот почему – на тестовых стендах никто не работает.

Реальные пользователи работают на продуктиве, с реальными данными (если проект не запущен - тем более, вам только прод и нужен).
Если вы не можете обходиться без промежуточных стендов — это симптом системных проблем.

Проблема 1 - Низкое качество разработки, включая архитектуру (всё спроектировано таким образом, что потенциальная ошибка может привести к катастрофе, последствия которой исправлять - не в рамках часа, а в рамках недели). Монолитные решения например.

Проблема 2 - Команда думает, что её продукт — код, сторипойнты, релизы.
На деле продукт — рост ценности для пользователя.
Она измеряется не сторипойнтами, а реальными бизнес-метриками и бизнес-задачами.
Чем быстрее команда получает обратную связь от реального пользователя, тем быстрее растёт ценность продукта.
Ошибки — не зло, а источник обучения.
Ведь ошибки - не только чисто кодерские (“кнопка не работает потому что не нажимается”), есть ошибки иного свойства – технически всё окей, но в реальности никто этим не пользуется (или неудобно, или избыточно, или в принципе не нужно).

Хуже, когда всё “технически работает”, но этим никто не пользуется.

Решение для управленца тут контринтуитивное, но простое – выкладываться сразу на продуктив.

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

Тогда пользователь мгновенно дает обратную связь (“тут кнопку пожалуйста пошире”), потому что он пользуется проектом в реальной своей деятельности и ему не нужно заходить в какие-то экзотические места типа тестовых стендов, чтобы это посмотреть.


А наличие отдельно стендов для разработчиков, тестировщиков и для продуктива просто является одной большой системной потерей!
И вот почему:
1. Разработчик привыкает к тому, что его результат в том, чтобы dev-стенды работали, а что там дальше что происходит – не их будто бы вопрос. На свою работу такие разработчики получают обратную связь медленно – и уже одно это является очень большой проблемой.
2. Это противоречит devops парадигме (CD:Pipeline), где разработчик отвечает за весь цикл - development & operation,
3. Противоречит бережливости (даже принципу DRY - зачем мы выкладку делаем несколько раз?),
4. Не поощряет разработчиков внимательнее относится к своей работе и тщательнее тестировать,
5. Повышает временные затраты на проверку (пользователю нужно зайти туда, где он обычно не работает), пользователь не может на тестовом стенде начать делать что-то ценное и увидеть ошибку – следовательно, часть ошибок / неудобств все-равно только на проде найдет),
6. Приучает команду к огромным релизам (в продуктив мы выкладываемся редко - значит и объем изменений там больше),
7. В свою очередь, повышает вероятность тех аварий, в которых сложно что-то быстро поправить (исправить ошибку из-за пары коммитов проще, чем из десятка, я уж не говорю про сотни).

Именно поэтому один из критериев качества - как часто команда сливает свою работу на продуктив (первая метрика DORA), четвертая (скорость восстановления) – лишь следствие первой.
DORA указывает, что выдающиеся команды релизят много раз в день в продакшн.

Я тут имею ввиду не отказ от тестирования, а переход к trunk-based development и коротким инкрементам, когда изменения безопасно и часто попадают в продакшн.

В книге Дао Тойота описано, что TPS расшифровывается не как Toyota Production System, а Thinking Production System.

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

Ошибки собственного производства - это как ребенок руку сломал. Примерно такие же ощущения.

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

Очень неприятное чувство.

Зачем сотруднику знать финансовые показатели?

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

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

Все эти вопросы любой собственник мечтает, чтобы задавались на самом нижнем уровне. И при этом, нижний уровень не имеет доступа к отчетности! Не только из-за технических проблем, но и проблемы знаний – сотрудники просто не понимают мудреную управленческую отчетность.
Это управленческая ошибка, которую мы помогаем предотвращать в osno-va.com.

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

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

Уму непостижимо, но до недавнего времени китайцам требовалось получать визу в Россию. А например соседней Киргизии — нет. Европейцам надо получать какую-то сложную визу. Туркам. Американцам.

Чтобы что? На сдачу от турпотока можно было бы решить все вопросы по безопасности, если б дело было в этом.

Это я к чему? К тому, что интересно, а сколько в моей компании таких «виз»? Интересный вопрос для меня как управленца.

Деление на frontend и backend вредит

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

И в IT разработке тоже так?
Скажем, есть специалист на react.js - профи, фронтент задачки "рубит" как дышит. Но на бэке ничего осмысленного сделать не может. Или наоборот, бэкенд разработчик. Так же и должно быть, это же логично?

С другой стороны, Kanban предполагает что человек бросится на помощь любой операции - тот кто тестирует, может начать помогать доделывать задачи в разработке, ведь есть WIP limits (work in progress limits) - если где-то затор, то мы бросаемся всей командой помогать.
Или scrum - почему во фреймворке производящая роль только одна - разработчик? Где аналитики, тестировщики, фронтенд, бэкенд, SRE, техлид. Они что, забыли про них? Пиндосы, блин.
Почему исследования DORA говорят, что концентрация должна быть вокруг ценности, а не стека?
Мартин Фаулер говорит о таком делении как о большущей проблеме в разработке.

Если на поставку ценностей столько людей, то как же так в Notion всего 13 человек. Почему Нельзяграмм был сделан 9 людьми?

Знаю и по нашим командам, что многие предпочитают делать ценности в формате пара людей (front+back), но оправдано ли такое устройство команды и какие у того проблемы?

Вот это всё и разберем в новом видео.

https://youtu.be/8GxlLD53Hyw

Новости управленческого учета Основы.

У нас в app.osno-va.com впервые стали заканчиваться процессорные мощности. И очередь клиентов.

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

Мечтаю, что через какое-то время финансовые директора которые мутят воду, смогут уйти в прошлое, а количество data driven компаний увеличится.

На ДР команда подарила спектакль «Почему я» на Плющихе.
Поражаюсь, что контент сейчас становится прогревающим на личность. В стендапе прикольно рассказать про свою жизнь, в спектакле. Моноспектакль Ирины Горбачевой.
И "Почему я", итоговая мысль что в жизни есть мир материальный (в котором плоть и кровь, "Иисус распят"), в нем очень много боли. И если есть только он, нет духовного ("Иисус воскрес"), то мы не выдержим. Это резиновый коврик под ногами, когда ты касаешься проводов под напряжением..
Для Ирины коврик - это сцена. Для меня коврик это... это что? Пласт какого-то микса культуры-миссии-инженерии, через который возможно когда-нибудь я смогу изменить что-то существенное? Дети? Как devops - deveopment & operation, мир духовного закольцовывается в мир материальный и наоборот.

Супер спектакль. Спасибо команде за такой подарок!

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

DORA-2025 на русском

Мы в kt.team часто ссылаемся на DORA.

Конечно, в эпоху ИИ велик соблазн попросить GPT сделать суммаризацию, но лично мне кажется что это очень плохая практика - как узнавать Толстого по краткому пересказу содержимого.

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

Но для тех, кто понимает что такое DORA и в целом интересуется инженерией, отдел маркетинга подготовил исследование в русском виде, у нас на сайте:
www.kt-team.ru/blog/dora-2025-ai-impact-part-1
www.kt-team.ru/blog/dora-2025-team-profiles-part-2
www.kt-team.ru/blog/dora-2025-ai-transformation-part-3
www.kt-team.ru/blog/dora-2025-ai-change-3-years-part-4

В Основе есть под капотом Apache Superset, он там давно, и мы слабо им пользовались. А потом для сложной задачи с 3d отчетами (в трех разрезах — месяц, магазин, типы трат) как посмотрели, как зашло.

Только теперь не понятно что такое Osnova — это какая-то облачная BI система с интеграционной шиной и сильной интеграцией с банками и 1С и вычисляемыми полями (конвертации валют, налоги, сопоставление со статьями трат и тп).

Основа, блин, ты что такое, как тебя назвать? 😭

Всех с Новым годом!
У меня очень много надежд с 2026 годом и большая уверенность в пресказуемости. Раньше, особенно после 2022 года, я не понимал корреляции - почему всё как бы лучше, но должно быть хуже. Что я не так понимаю?

В конце 2025 года понимание сошлось, и предсказуемость действий выросла. Супер! )

А ещё, я достаточно активно с осени вернулся в управление компанией - и только сейчас понял, что видимо несколько лет был в выгоревшем состоянии. Провели с командой тесты - Fade (а ещё PiF, Герчикова).

Может быть надо написать инсайты про это, но дождусь общей встречи с менторами по тестам, и потом поделюсь выводами.

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

Спринты понимаются неверно.

Одна из ключевых вещей, которую хочу передать всем в своей команде, что спринт - это не ведро с задачами и константной ритмичностью.

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

А во-вторых, ключевое в спринте - это наличие одной цели. Одной. Цели.
Что такое "цель"? Это не ценность. Цель спринта - перевести проект в какое-то новое состояние. Как определить новое состояние? Это достаточно легко - представьте, что вы объясняете какое-то новое следующее состояние проекта для челоека, который вообще о проекте и об IT ничего не знает. Часто это называется эпиком.

Когда мы говорим про эпик, все остальные ценности выглядят в нем гипотезами, а не конкретной реализацией.

Давайте конкретно с примерами, можете себя потестировать самостоятельно (не раскрывайте первый спойлер пока не ответите на все 4 вопроса самостоятельно).

Цель спринта или просто ценность:
1. Появилась система взаиморасчетов между подразделениями. Это - ценность, а не состояние (определено техническое решение, не определено состояние).

2. Мы на перекрестке решили добавить светофор. Это - тоже не состояние, а ценность.

3. На перекрестке стало меньше пробок. Это - состояние, а ценности (светофор ли, разметка, дорогу сузить или расширить - что именно повлияет, предстоит выяснить в реальности, и чем опытнее команда, чем больше PDSA циклов она прошла (спринты + рефлексия), тем точнее команда будет с прогнозами).

4. Компания стала лучше взаимодействовать между подразделениями, не платя за помощь другим своими KPI. Это состояние. Подойдет под цель спринта. Система взаимодрасчетов тут - одна из гипотез.

https://youtube.com/shorts/igblJSrXgqY

Итого, если новое состояние потребует не 2 недели (как условно в компании принято), а 3 (4, 5, …) недели, что мы сделаем:

1. Определим, что новое состояние будет через 2 спринта. В конце первого спринта будем показывать просто то что сделано или пропустим демо.

2. Попробуем поделить эпик на эпик меньшего размера, если это возможно. А если невозможно — увеличим спринт до необходимого размера (спринт будет не 2, а 3 или более недель).


Какой вариант правильный?


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

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

Есть компании, которые сфокусировались на эффективности, как Telegram c 40 IT специалистами, Whatsapp - 32, Instagram - 9 всего сотрудников (в некоторых источниках 10 или 12), Notion дошел до завоевания рынка 13 сотрудниками (сейчас у них примерно 300-500 инженеров, но и количество пользователей более 100 млн), Perplexity всего сотрудников 700 (мы говорим о всех сотрудниках, IT специалисты примерно делим на три), Anthropic - 500 сотрудников, OpenAI 5300 человек (всех сотрудников, IT сотрудников 1000-1500 примерно), ключевая команда Revolut (без учета тех, кто поддерживает пользователей и ищет схемы) - 5000 человек, а всего сотрудников 10000 (для сравнения, один только IT отдел Альфа-банка это 9500 человек, а численность российского Авито такая же, как глобального eBay).

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

Есть компания, которая с 1978 года исследует аспекты качества разработки программного обеспечения. Эта компания - QSM (https://www.qsm.com).
Они сформулировали принцип и поняли, что кривая Релея описывает затраты на проект. Норден сформулировал прицип "Любое увеличение “фрагментации” работ (ролей/интерфейсов) растягивает кривую, увеличивая время проекта даже при неизменном объёме работ." (переводя уравнение с математического на человеческий).

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

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

Причина этого в том, что, согласно DORA и QSM, статистически значимо влияет на успех управления только частая поставка на прод и быстрый сбор обратной связи. При этом, QSM в основном исследует "кровавый энтерпрайз" (исторически сложилось), и повторяют исследования каждые 2-3 года, так что сказать что они исследуют только хипстеров или какие-то супер уникальные компании - крайне затруднительно.

В dora-2025 AI назван Amplifier. По-русски кажется точнее перевести как "множитель" - ИИ не усиливает слабых, но усиливает сильных.

Короткий Шортс на этот счет тут https://youtube.com/shorts/b90CDucOYXA

PMBOK в разработке ПО выглядит умно, но вредит.

PMBOK и похожие фреймворки не глупые и не устаревшие.
Они прекрасно работают в линейных средах — например, в строительстве или на заводах.

Почему?

Потому что там:
-цель заранее известна,
-результат = сумма действий,
-можно локально оптимизировать части и улучшать целое.

Именно поэтому:
-декомпозиция,
-специализация ролей,
-жёсткая этапность

там работают.

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

Разработка ПО — complex (нелинейная) среда.

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

Управленцы искренне хотят результата.

И они логично думают:
«Если я разделю труд,
если каждый будет делать “своё” лучше всех,
система станет эффективнее».

Отсюда:
- бизнес-аналитик анализирует,
- дизайнер проектирует,
- разработчик фронта делает фронт,
- разработчик бэка делает бэк для фронта,
- тестировщик тестирует,
- релиз-инженер релизит.

Локально — всё оптимально.
Глобально — система деградирует.

Почему?

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

Знание теряется:

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

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

PMBOK исходит из идеи этапности:

сначала понять → потом сделать.

Agile исходит из другой реальности:

понимание и реализация происходят одновременно.

Не потому что Agile «модный»,
а потому что в complex-средах реальность познаётся только через эксперимент.

Все наши решения — гипотезы.
Вся наша деятельность — работа с риском.


В разработке ПО локальная оптимизация разрушает целое.
Чем сложнее система ролей —
тем медленнее она учится.

Цитаты напоследок

Gene Kim (DORA):
“Local optimization leads to global degradation.”

Dave Snowden:
“The moment you think you understand a complex system, you have already failed.”

--
При форматировании и оптимизации этого поста был использован GPT5.2