Про то, что видел и слышал со сцены сегодня.

Первый доклад, который посетил, был на тему "Инструменты диагностики процессов и структуры команд разработки". Представляла Оксана Григорьева из "Контура".

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

Третий доклад (да, рассказываю не по порядку) был тоже про диагностику. Назывался "Метрики эффективности delivery-процесса: масштабируем управление командами, опираясь на факты", представлял Михаил Чугунков из Авто.ру. К моему удивлению, на спикере была точно такая же сорочка, точно такие же брюки со стрелкой и точно такой же блейзер от не самой распространённой марки, какие висят в моём личном гардеробе. Учитывая то, что вообще ИТ-шника в блейзере и брюках со стрелкой встретить в жизни практически нереально, это всё было какой-то магией!

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

1) Вообще метрики надо для начала целевые и отладочные. Первых нужно мало, вторых может быть гораздо больше. И вторые лучше особо никому не светить, чтобы не было соблазна крутить вверх, чтобы "сделать лучше"

2) Рано или поздно надо пробираться через простые вбросы от заказчиков/начальства, мол, "делать работу надо быстрее и качественнее", и докапываться до сути. За любыми убеждениями стоят конкретные потребности и факты. А вот когда докопались, можно уже "делайте хорошо" переводить на язык цифр. И затем ставить те самые целевые метрики

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

4) Ещё понравилась мысль, что однократная неудача по одной метрике может вообще не значить ничего плохого. В то время как ровный успех по другой может скрывать за собой накапливающиеся проблемы. В общем, 200 раз подумать, как и какие метрики использовать, а главное, для каких целей.