Если посмотреть на те задачи, которые идут в разработку, с точки зрения их ROI — то можно значительно улучшить производительность команды без каких-либо изменений в процессах.
Активное внедрение LLM во все этапы разработки ясно показало то, что и так было очевидно всем более-менее опытным руководителям: написание кода не является бутылочным горлышком. Если команда делает бесполезные и слабо продуманные задачи, то с LLM она начнёт делать х2 бесполезных и слабо продуманных задач.
Но те же LLM можно прекрасно применить для того, чтобы повысить ценность входящего потока фич и требований, значительно улучшив конечный результат команды.
GIGO
Старый принцип гласит: «Garbage in — garbage out» (мусор на входе — мусор на выходе). Можно сколько угодно докручивать и оптимизировать процессы разработки, но если продукт никому не нужен — увы, никакую проблему это не решит.
Поэтому я топил, топлю и буду топить за то, что хорошая разработка начинается с качественной продуктовой и аналитической работы. Мне, как ответственному за распределение и использование capacity своих подчинённых, всегда важно понимать:
- Зачем мы делаем эту фичу?
- Какая у неё ценность?
- Кто потребитель этой фичи?
- Как она позволит продукту зарабатывать больше денег?
Помню, приходит ко мне как-то бизнес-аналитик с идеей фичи. Фича классная и красивая, попахивает месяцем разработки. И задаю я ему простой вопрос: «Сколько человек будет потенциально этим пользоваться и как часто?»
Аналитик думает, на глазах грустнеет и отвечает: пару процентов аудитории раз в пару месяцев. На что я ободряюще хлопаю его по плечу и говорю, что он совершенно зря приуныл, ведь мы только что сэкономили кучу времени разработки. На его непонимающий взгляд я предлагаю решение, которое займёт от силы часа четыре одного человека.
Одним этим разговором мы резко повысили ROI фичи за счёт того, что снизили её стоимость в разработке. 4 часа и 4 недели — значительная разница.
Когда стоимость команды перестаёт быть абстракцией
Для разработчика не думать о деньгах нормально: у него и без финансовых потоков задач хватает. Для руководителя это становится опасно, потому что без стоимости работы все задачи легко начинают выглядеть одинаковыми.
Когда-то я составил годовой бюджет команды с учётом зарплат, повышений и премий и увидел, что она обходится примерно в три миллиона рублей в месяц. После этого фича на три месяца перестала выглядеть просто «большой задачей». Она стала инвестицией, для которой хочется понять ожидаемую отдачу.
Поэтому на очередное предложение продакта я начал отвечать вопросом: «А почему эта штука окупится?» Не каждая задача приносит прямую прибыль. Одни улучшают клиентские метрики, другие снижают риски, третьи убирают технический долг. Но руководителю важно понимать, какую бизнес-ценность покупает компания за время команды.
Эту связь хорошо показывает книга Элияху Голдратта «Цель»: команда, процесс и локальное улучшение имеют смысл не сами по себе, а через влияние на результат всей системы.
Самым жёстким тренажёром денежного мышления для меня стал запуск собственных проектов. Когда на работу есть пара часов вечером, делать что попало уже не получается: приходится взвешивать стоимость каждой задачи и держать свою шкуру на кону. Но начинать можно проще — узнать экономику продукта, спрашивать о ценности фич и хотя бы грубо оценивать стоимость разработки.
А у нас всё важное!
На этом этапе обсуждения мои братья по духу и стартапам могут сказать, что у них вообще нет неважных фич. Добро пожаловать в клуб, друзья! Прямо сейчас в моём рабочем проекте просто нет неважных задач — последние полгода мы с командой добродушно посмеиваемся, что у нас всё «high crit blocker».
В таких условиях ещё важнее думать про ROI, ведь чем быстрее мы поставим нашим клиентам core value фичи — тем выгоднее всем. Практически всегда, практически в любой фиче можно срезать жирок / срезать углы / обойтись небольшим костыльком на будущее и тем самым увеличить ROI. Простейший запрос в LLM типа «вот описание фичи, что из неё можно выкинуть нахрен без потери ценности?» уже даёт много интересной пищи для размышлений.
Если разработка занимается какой-то ерундой — то это никогда не проблема разработки. Это проблема тех людей, у которых не хватает либо желания закопаться в суть, либо яиц на оспаривание чужих решений.