Comments 10
В небольшом продукте все метрики в голове владельца продукта.
А в большом когда пытаются их отчуждать такая фигня и получается.
Согласен: у владельца небольшого продукта есть полный контекст — он видит и скорость, и качество, и цену срезанных углов, контрметрики у него «посчитаны» самим положением дел. Рост эту полноту разрушает: система становится больше контекста любого одного человека, и тогда контрметрики приходится делать явными и отдавать конкретным владельцам. Собственно, об этом Дёрнер и говорит: проблемы начинаются, когда сложность системы превышает модель реальности в голове принимающего решения.
Сокращение цикла разработки на 20% — цель понятная и измеримая.
Нет, совсем не понятная. Почему на 20%, а не на 10 или 30? Почему вообще надо было сокращать цикл - было исследование, что именно длинный цикл тормозит бизнес? Может быть, наоборот, удлинение цикла позволило бы давать клиентам настолько отточенный и вылизанный продукт, что клиенты потекли к вам рекой?
А может, изменить ценовую политику? А может, сократить штат грузчиков?
Непонятно.
Тут и правда есть неточность формулировки: «понятная» значит «ясно сформулированная», а не «обоснованная». Почему именно −20% — решение бизнеса, оно принималось за пределами моего контура: я отвечал за надёжность и работал не с самой целью, а с последствиями её достижения.
Но статья не про то, правильная ли цель. Она про то, что у любой цели — хоть −20%, хоть удлинение цикла ради качества — должен быть противовес, иначе система оптимизируется за счёт того, что не измеряется.
Всё это понятно и я согласен. Но мой поинт как раз в том, чтобы все в компании, сверху до низу, понимали обоснованность целей, а особенно таких, выполнять которые придётся непосредственно им. По крайней мере, я бы написал хоть одно письмо руководству, с копией своей группе, на тему, почему, как и откуда была взята именно эта цель.
О. Осознанность, туды её в качель.
Непонимание целей фирмы, отдела, группы - одна из основных причин демотивации и выгорания сотрудников. По-моему.
Письмо руководству с вопросом «откуда взялась цель» — ход дешёвый и правильный, тут присоединяюсь. Уточню только одно: обоснованность цели и противовес защищают от разных рисков. Цель может быть обоснована безупречно — побочные эффекты всё равно будут копиться невидимо: у нас они вскрылись только через месяцы, на графике. Осознанность на входе не заменяет контрметрику на выходе — нужны обе.
Пришёл сюда понегативить.
Никто не задумывается о качестве по умолчанию, бизнесу важно быстро и дёшево (выбираем 2 из 3 - быстро, качественно, дёшево) - вот оно на самом деле по умолчанию.
Помните фразу "ничего личного, просто бизнес"? Так вот, конкурентноспособность за счёт скорости и урезание костов (тот же ФОТ) - вот главное правило бизнеса, а у инженеров... Ну, у разной градации свое - senior не зря, как правило, получает много денег, поэтому он всегда думает о скорости и качестве, а для бизнеса это дорого, вот и...
Вот и рождаются подобные статьи и разговоры только тогда, когда бизнесу встаёт вопрос о "скупой платит дважды".
Я на входе в компанию всегда предлагаю качество и скорость, и как следствие - системный подход ко всему. Но бизнес этого не понимает и не принимает, пока ему больно не будет...
Полагаю, один из этапов, которые вы удачно проскочили - попытаться вернуть всё назад, ибо всё уже настолько критично плохо, что пусть уж будет dev cycle time останется прежним, чем будем терять клиентов
Вы, по сути, подтвердили — «по умолчанию» в реальных решениях живут только скорость и стоимость, а качество туда не попадает, пока его не оцифруют. Ровно поэтому спор «у нас все думают о качестве» выигрывался опросами, а не убеждениями.
Насчёт «пока больно не будет» — да, триггером стала боль: возросшее количество инцидентов. Но в этом и смысл контрметрик: в следующий раз боль становится видимой на графике раньше либо не возникает вообще.
А вот финальное предположение не подтвердилось — откатывать ускорение не пришлось. dev cycle time сохранили, а количество инцидентов снизили за счёт системных изменений, которые стали неизбежными, когда цена ускорения оказалась на виду.
Сильный пример того, как локальная оптимизация одной метрики может ухудшить систему в целом. Особенно откликнулась мысль, что контрметрика должна не тормозить ускорение, а делать его цену видимой. И отдельно важно, что заранее согласованные действия при отклонении работают лучше, чем попытки договориться уже в момент кризиса. Было действительно интересно прочитать, спасибо!
Сократили цикл разработки на 20% — и получили вдвое больше инцидентов