Уставший техдир

Про изолированные метрики и узкую специализацию В комментариях был справедливый вопрос: "а в чем проблема, ведь задача разработчика - затащить таску в прод, на кой ему остальные метрики". Я тут могу написать пару сотен слов и приводить примеры, но, позвольте процитирую бессмертную сценку Аркадия Райкина Она высмеивает ту самую функциональную систему разделения труда, когда до обсурда доводиться любой процесс, когда в попытке сделать его детерминированным и эффективным он разделяется на сотни независимых процессов (здарова эффективным бюрократам). Как вы понимаете, уже тогда всем было понятно, что подобная схема работает против качественного результата Ну и что что продукт гавно и не летит, к верстке вопросы есть? Вопросов нет) Так и живем П.С. А вот кто продолжает так управлять, задумайтесь, не гавно-ли вы делаете на выходе

Закон Гудхарта Очень важное наблюдение, но, к сожалению контринтуитивное, особенно для начинающих руководителей. Суть в том, что когда метрика становится целью, она перестаёт быть честным показателем. Это из-за того, что начинаем играть по цифрам, забывая о реальной ценности. Разберемся, как это работает на деле. Мой примитивный, но крайне показательный пример. Количество задач, которые сделаны в месяц. Представим, что есть какая-то метрика, которая, к примеру, считает количество фич, или количество сторей (ну допустим). И мы такие: а давайте растить эту метрику, поставим всем ее в KPI Что ж, казалось бы, простая и логичная цель. Однако, как только мы превращаем эту метрику в ключевой показатель эффективности, начинают происходить интересные вещи. Разработчики, стремясь достичь заданной нормы, начинают выбирать задачи попроще, которые можно быстро закрыть. В результате количество сданных фич растет, но их сложность и значимость для продукта могут существенно упасть. Более того, в погоне за количеством сторей разработчики могут начать игнорировать техническое качество кода. Это ведет к увеличению технического долга: код становится сложнее поддерживать и развивать, что в перспективе замедляет процесс разработки и увеличивает количество ошибок. Ну или еще успешный самообман - увеличить декомпозицию, теперь вместо одной карточки у тебя может быть расписано три. То есть метрика выросла в три раза, но, объем конечной ценности при этом не увеличился. Имитация бурной деятельности во всей красе) Поэтому, класть производственные метрики в KPI считается крайне дурным тоном. Потому что, внезапно, может оказаться, что вся команда сфокусирована не на достижении целей компании, а на "зеленении" метрики, которая врет А у вас какие метрики лежат в KPI?

Задумывались, почему много объявлений от экстрасенсов «верну мужа», но ни одного «верну жену»? 🙃

#мемы

Олды тут?)

Вот ради таких комментариев я и решил делать подкаст, спасибо тебе добрый комментатор ❤️

Помните, я топлю за прокачку бизнес-мышцы разработчиками? Так вот, принес вам полезную папку, в которой предприниматели рассказывают о своих взлетах и падениях, делятся реальными цифрами проектов, а также рассуждают о трендах. Крайне полезная коллекция, которая прокачает кругозор и насмотренность и позволит вам увидеть чем обеспокоен бизнес, как он рассуждает при принятии решений и какими образами результата живет. Кроме этого, надеюсь, каждый найдет полезное лично для себя) Ссылочка на папочку: https://t.me/addlist/fDfkrlwugG5jOGJi Подписывайтесь и прокачивайте кругозор и бизнес-мышцу!)

Все больше поводов не доверять удаленке, особенно в решении важных вопросов А теперь представьте, что сюда добавляется процессинг голоса, немного OSINT-инженерии, плюс, социальные сети или утекшие аккаунты. Звонит тебе дружище и просит денег в долг, твои действия?)

Иногда новые фичи не нужны, если продукт стабильно закрывает потребность.