Продуктовая (раз)Работка

🔍Как мы готовим груминг по дизайну, чтобы он не превращался в бесполезную формальность

Вот пример из опыта о том, как обслуживать продуктовую практику, чтобы она приносила оценимую пользу. Это груминг по дизайн-макетам: команда смотрит на визуализацию фичи и вместе с разработкой прикидывает, насколько все реализуемо и трудоемко. Здесь удобнее всего поймать, что слишком дорого и что упростить, пока макеты не ушли в работу. Как раз тут обратиться можно и к FFF: резать надо, пока еще есть что резать, и такой груминг дает шанс не упустить момент.

Зачем вообще городить такой трудоёмкий процесс? Ну, вот допустим дизайнер не показал макеты разработке, а понес сразу клиенту, тому все понравилось, ушло в работу. А на макетах оказалось нарисовано то, что мы технически не закладывали и в разумные сроки не вытянем. Придется все переигрывать задним числом, когда объем уже утвержден, а время расписано. Груминг ровно для того и нужен, чтобы этот сценарий не случился.

Держится все на заранее понятном распределении ролей. Аналитик проверяет, что макет отвечает требованиям, защищает идею клиента. Дизайнер следит за пользовательским опытом и целостностью дизайн-системы, защищает пользователя. Разработка оценивает техническую сторону: можно ли заменить тяжелый компонент на простой, сколько времени все это займет.

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

Высказаться про цвета и композицию может каждый, но чтобы не упороться в коллективное рисование дизайна всей командой, но по вопросам эстетики право вето все же за дизайнером. Это тоже важно помнить.

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

Продуктовые практики мало просто внедрить

В прошлый раз разбирали, как убить FFF неправильным флексом. История эта не только про FFF: почти любую хорошую продуктовую практику легко превратить в бесполезную, если внедрить ее номинально.

⚙️ Начнем с контрактов в разработке. Допустим, применили на проекте API-first: бэкенд фиксирует контракт и отдает его фронту, и тот делает экраны, не дожидаясь серверной логики. Пока контракт держат в актуальном виде, работа идет параллельно, время экономится. А стоит перестать за ним следить, начинается расхождение: на сервере логику уже поменяли, а фронт все еще собирает экраны по старому контракту. В какой-то момент это вскрывается, и фронту приходится переделывать готовые куски. Время, сэкономленное на параллельной работе, тут же и теряется, а порой и перерасходуется.

⌛️ Та же тема в командных ритуалах. Возьмем груминг, на котором команда вместе разбирает фичу до того, как она уйдёт в работу, чтобы заранее вскрыть сложности. Держится это на подготовке участников. Если разработка впервые видит макеты прямо на созвоне, встреча проходит вхолостую и толку от него ноль.

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

Короче, какая бы практика правильная и известная ни была, все решает процесс вокруг нее.

А какие практики чаще всего ломаются у вас, потому что внедрили их только номинально?

💎 Флекс работает, просто флексить нужно вовремя

Работаем мы по FFF: фиксируем срок и бюджет, а гибким оставляем скоуп. Идея в том, что когда все, что хотелось, в релиз не помещается, мы не двигаем дату и не добираем людей, а решаем, что со скоупом делать: что-то упростить, что-то отложить в следующую очередь, а что-то и вовсе выкинуть.

То есть флекс скоупа — штатный рабочий инструмент, которым нужно пользоваться постоянно.

Обычно проблема в том, что пользоваться им забывают: пока флексить можно, его все откладывают и откладывают.

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


Почему так происходит?

1️⃣Оптимизм: кажется, что вот эту задачу закроем быстрее, чем договаривались.

2️⃣Флексить по-настоящему — это идти к заказчику и говорить «мы не успеваем, давайте вот это упростим или уберем». Разговор неприятный, и его хочется отложить. В итоге варианты сокращений крутишь в голове или обсуждаешь внутри команды, но до заказчика они не доходят. А без него никакого флекса не происходит, ведь объемом-то распоряжается он.

С оценками та же история. Задачу оценили в сто часов, заказчик готов оплатить шестьдесят пять, сошлись на семидесяти пяти, а сделать получилось все равно только за сто.

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

Интерфейс должен обслуживать бизнес-процесс, а не наоборот

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

Например, интерфейс корзины в онлайн-магазине. В рознице она одна, и путь прямой: положил, оплатил, получил. В B2B сценарий может усложниться.

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

Для «Москворечья» мы собирали оптовую B2B-платформу по продаже автозапчастей. Поскольку требовалось развести одну закупку по разным получателям, мы шли от формы этого процесса. Раз пользователь делит закупку на части еще на этапе заказа, корзина должна это делать вместе с ним.

👝 Так появилась мультикорзина:

• несколько корзин в одном профиле: под СТО, договор или клиента;
• резерв, чтобы отложить позиции, пока собираешь большой заказ;
• комментарии к корзине и к позициям, чтобы не терять контекст.

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

Это одна деталь из большого проекта.«Москворечью» мы помогли перейти от устаревшего портала к собственной управляемой платформе, которая объединяет поиск автозапчастей, заказ, логистику, договорную модель и интеграции в единую B2B-систему. Полный кейс можно почитать на сайте.

Привет, это Веня! Расскажу сегодня, почему не нужно умно думать, а нужно тупо делать 👍


На этапе захода в новый проект всегда куча сомнений и страх ошибиться. Хочется сначала продумать все до мелочей, чтобы потом не облажаться, стартануть максимально правильно. И вот это желание все просчитать заранее как раз и есть главный блокер: ты неделю готовишься начать, вместо того чтобы начать.

Помню, кто-то где-то давал совет: не знаешь, с чего начать писать, напиши «так, б@ать» и дальше польется. Тут работает такой же прием. Вместо того чтобы сомневаться и продумывать все до мелочей, лишь бы не ошибиться, надо просто сделать минимальный первый шаг. Пусть даже он будет максимально тупой.

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

✏️ Важная оговорка, чтобы не поняли превратно. Это не призыв забить на правила и методологии и делать вот прям совсем как чувствуешь. Правила на месте. Просто из процесса убирается долгая подготовка, чтобы быстрее сдвинуться с места. 

А что помогает сделать первый шаг вам?

Если срочно нужно застопорить проект, стоит подождать, когда все станет понятно 💭

На проектах регулярно всплывают сложные, незнакомые задачи с кучей неизвестных. И человек, который за них отвечает, подвисает. То ли боится, что не справится. То ли просто откладывает. То ли ждёт, пока всё прояснится само. Но пока он ждёт, ничего не происходит.

Ведь всегда приятнее начинать, когда задача уже понятна. Только полного понимания можно и не дождаться. Нам ближе принцип «ничего не понятно — всё понятно».

Напрмер, делаем фичу «Расчёт стоимости страхового полиса», поначалу непонятно вообще ничего. Раскидываем по верхам: от каких факторов зависит цена, откуда берутся коэффициенты, где человек вводит данные и что видит на выходе. Крупными мазками уже ясно. Дальше зумимся в один кусок, скажем «от чего зависит коэффициент», и снова упираемся в неопределенность. Идём к заказчику, разбираем тарифную логику, при случае болтаем с профильным аналитиком, дописываем. Опять проясняется.

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

Главное не застревать в попытке довести всё до предельно понятного состояния, потому что проект подвижен. Так что держим общую картину и дорабатываем детали по мере надобности.

А как с непонятными задачами работаете вы?

Как проектирование архитектуры превращается в черную дыру в бэклоге и как с этим быть 🖥

Бывало у вас такое? На старте проекта или какой-то большой фичи даешь такую задачу тимлиду или разработчику, он уходит в малиновый закат глубоко думать. Проходят дни, недели, а на вопрос «когда будет готово?» ответ туманный. Мол, надо еще изучить и проработать, a few sprints later — на выходе — 2 картинки с квадратиками и отстающий по срокам проект.

Почему так происходит❓

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

Да, и забыл главное: это задача высокой степени неопределенности.

🔤Много неизвестных на старте - куда пойдет продукт, как он будет работать, и т.д.
🔤Часто ставят ее нетехнические руководители и не могут ясно описать образ ее конечного результата (тот самый Definition of Done), поэтому где поставить точку решает исполнитель.

Что делать, чтобы не слить время команды на старте ❓

1️⃣ Жестко ограничить время на задачу. Даем Х часов или дней на обдумывание и подготовку: не успели все продумать, не страшно, презентуем что есть, и используем в работе, разберемся по ходу пьесы. Стандартное средство от перфекционистов всех мастей.

2️⃣ Снизить неопределенность, где можете. Возможно вам не нужна архитектура на 3 года вперед, а достаточно сделать на ближайший релиз. Может быть объем клиентов никогда не вырастет в 10 раз; может быть мы не будем запускать его в облаке и т.д. Лучше сделать это вместе с вашим тимлидом, и не забыть зафиксировать, чтобы не было сюрпризов потом.

3️⃣ Все таки зафиксировать как-то definition of done. Если вы нетехнарь, результатом может быть набор документов, презентация команды, прохождение ревью техдиром или просто ок от команды.

Если вы немного шарите в разработке, можете уточнить еще детальнее, чего ждете. Например, описание сущностей в БД, схему потоков данных, описание всей предметной области, или только какой-то важной части, или код конкретной фичи. Сейчас также ждем от архитекторов локальный харнесс проекта для разработки с ИИ-агентом: спеки, структуры тестов, линтеры или скиллы верификации нужных требований.

Сорри, если обломал кайф вашему тимлиду!

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

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

Можно, конечно, сказать «всё будет!», подписать контракт и разгребать завалы потом. Но доверие вдолгую так не строится. И честность обязана быть обоюдной. Если заказчику внезапно всё нравится, он либо в эйфории, либо чего-то недоговаривает, и это молчание потом аукнется на самом неудобном этапе. Чем раньше всплывает недовольство, тем проще с ним разобраться, пока оно не превратилось в переделку половины проекта.

📌 Кстати, честность ещё и неплохой фильтр. Хотите проверить подрядчика — назовите заведомо нереальные сроки и невозможный целевой результат. Тот, кто радостно кивнёт и побежит за договором на подпись, вам не нужен.

Честностью не закрыть спринт, и в процессы её не впишешь. Но без нее работать будет сложно.

Тимлид, техлид, продакт — роли уже знакомые. А вот про мишн-лида слышали? ℹ️

Обычно, чтобы начать влиять на продукт и уйти от чисто исполнительской функции, разработчику предлагают один путь: уйти в менеджмент. Но есть компании, которые придумали, как дать это влияние, не вынимая человека из разработки. Практику под названием Mission Lead нам на круглом столе про продуктового разработчика описал Антон Бевзюк, инженерный менеджер Mindbox.

Работает так. Сеньорный разработчик берёт на себя ответственность за короткую бизнес-цель, которую небольшая команда из трёх-четырёх человек может закрыть за месяц-два. Цель бизнесовая, но отвечает за неё именно разработчик.

Он погружается в проблему вместе с продактом и дизайнером ещё на этапе, когда выясняют боль заказчика и её масштаб. Дальше готовит архитектурное решение и защищает его перед архитектором, разбивает работу на понедельные инкременты, а на демо сам показывает результат клиентам, не перепоручая это продакту.

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

Кстати, у Антона тоже есть канал, в котором он рассказывает о работе и делится интересными мероприятиями, заходите 🙂

Бесконечные улучшения: что в бэклог, а что — в работу ✏️

Возьмём большой продукт, где заказчик сам выступает владельцем продукта. Работа ведется долго, мы итеративно развиваем решение. Большинство идей по улучшению идёт от него, он же приоритизирует бэклог. Мы тоже можем что-то предложить, но без глубокой проработки. Если идея кажется стоящей, выходим на аналитику за счёт клиента и дальше по стандартному процессу. Но чаще наши предложения уезжают в бэклог: у клиента свой текущий приоритет, и распыляться он не хочет. Мы иногда напоминаем, чтобы он про них не забыл.

Это в основном про крупные фичи. С мелкими правками проще: часть делаем сразу, когда понятно, что дешевле потратить время сейчас, чем переделывать потом. Но и это согласуем. Убедили клиента, берём; не убедили, откладываем. Клиент платит деньги, у него сроки ещё с этапа планирования, и чтобы что-то поменять, нужно объяснить, почему это стоит времени.

А есть другой случай, когда у нас сжатый по срокам проект. Например, MVP какого-то продукта, где мы еще не знаем получит он дальнейшее развитие или нет. Тут чаще уже мы приходим и просим отложить фичу, чтобы успеть к запуску. Аргумент простой: для MVP это некритично, без этого релиз спокойно выйдет. Заказчик соглашается — фича в бэклог. Не соглашается — стараемся упростить задачу до минимального варианта исполнения, согласовать его и взять в работу. Всё остальное опять же в бэклог.

Как видите, в обоих случаях всё держится на диалоге. Либо ты просишь клиента что-то добавить, либо что-то убрать. Что именно и когда, зависит от проекта, сроков, этапа и самого клиента. Никакого тайного правила, что отправлять в бэклог, а что в топку, не существует. Есть только разговор и аргументы. Ну, и умение быть в живом контексте работы и разрабатываемого решения.

Ускоряйтесь, только не говорите как именно

Вот мы тут поныли и про нагенерированные ТЗ, и про «давайте подойдем творчески, чтобы побыстрее и подешевле». Из этих штук еще одна проблема вытекает, с которой вы, наверное, тоже уже сталкивались…

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

То есть ускорение нейросетями заказчик вроде бы использует и сам подразумевает, но подразумевает молча. Ему нужно, чтобы мы там у себя внутри как-то ускорялись и приносили результат быстрее, а как именно, знать не хочет. А если еще сказать «мы вам навайбкодим», то про контракт можно сразу забыть.

Явную нейросетевую разработку не покупают из принципа, ей пока не доверяют. Хотя в целом плоды ИИ при этом всех вроде устраивают.

А у вас как с этим? Проговариваете заказчику, что и где ускоряете нейросетями, или тихо делаете свое дело и не выносите тему на переговоры?

Привет, подписчики. Пришли к вам пожаловаться и узнать, у кого так же 🤪

Бизнес сейчас часто приходит с нагенерированными ТЗ. Скидывают 17 страниц текста и вот, говорят, все расписано, берите в работу.

Но а работать с таким ТЗ невозможно ведь. Говоришь об этом, и люди обижаются, говорят, мол, как так, МЫ ЖЕ НА ЭТО ВРЕМЯ ПОТРАТИЛИ. Ну, классно, очень жаль, что впустую было потрачено 30 минут.

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

У кого так же происходит, что думаете по этому поводу?

Ребята, нам надо побыстрее и подешевле. Давайте подойдем творчески! Вот сколько раз к вам с таким запросом приходили? У нас это каждый третий, наверное.

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

Думаем, чем можно пожертвовать и что можно не писать руками. Смотрим, что выкинуть из MVP по-максимуму. То есть с оговорками, но пожелание клиента выполнимо, если он готов принять то, из чего складывается цена ускорения и удешевления.

Этот запрос ведь заметно участился с тех пор, как ИИ стал формировать ожидания заказчика: нейронка пишет код за пять минут, значит продукт должен собираться за неделю и за три копейки. Как часто к вам приходят с таким? Расскажите в комментариях, интересно послушать с разных сторон.

Человек зачастую делает плохо не из вредности, а потому что он думает, что это хорошо

Часто сложно дать негативный фидбек. То не хочется рубить с плеча, то боимся человека обидеть. Плюс в это же еще надо время и энергию вкладывать, чтобы нормально этот фидбек донести.

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

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

А вы как, боитесь давать негативный фидбек? Как это делаете? Есть ли кроме 1на1 и перформанс ревью какие-то инструменты?

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

🐞 Софт без багов бывает?

Если мы посмотрим описание новой версии любого продукта, увидим, что в ней исправлены баги. Но каждый последний исправленный баг — предпоследний. И не важно, это пет-проект студента или продукт бигтеха с командой выпускников MIT.

При этом бизнес резонно ждёт, что софт будет просто работать: мы же четко все описали и спроектировали, почему нельзя сразу сделать без ошибок? Это расхождение в мировоззрении — вечный источник конфликтов между бизнесом и разработкой. Разрешается оно просто: нужно отойти от бинарного «работает / не работает».

Для начала разберемся, почему баги все-таки неизбежны?

Программы в общем выглядят как набор детерминированных инструкций «ЕСЛИ Х, ДЕЛАЙ Y», а вариантов их сочетаний просто прорва. Плюс разные ОС и железо, на которых наш софт работает. И собирается он, кстати, из разного другого софта: библиотек, компонентов, компиляторов и т.д. Проверить все это за разумное время нереально.

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

Как говорить об этом с бизнесом?

Стоимость разных классов ошибок можно прикинуть заранее. Разработка легко перечислит возможные риски, а вам нужно их оценить.

Падение прода у крупного e-commerce — это потеря Х миллионов выручки. Баг в возврате товара — просто испорченный клиентский опыт. Обходимая ошибка будет просто раздражать, а вот совсем неработающая фича завалит техподдержку.

📌 Короче: важны не сами баги, а какие они. И каких у нас точно нет.

⚡️Давайте не путать релиз и приемку, а то поссоримся

Диалог следующий:

PM: Что нам осталось доделать, чтобы наконец зарелизиться?

Клиент: Ну, без фичи Х я у вас проект не приму.

PM (паникует и бежит к команде): Релиз отменяется, срочно пилим фичу Х, без неё никак.

Команда негодует. Релиз откладывается на пару недель. И все на проекте в плохом настроении.


💡 Релиз ≠ Приемка
Это два принципиально разных понятия, которые почему-то путают:

Релиз — про продукт и ценность. Ваша задача — как можно быстрее выкатить рабочую версию (MVP), чтобы пользователи решили свою проблему, а вы получили метрики и фидбек. И релизов в одном продукте по мере его разработки будет масса.

Приемка — про формальности и деньги. Это выполнение юридических договорных обязательств. Клиент говорит «не приму» не потому, что фича нужна в первый день пользователям, а потому что без неё он не подпишет финальный акт и не переведет оплату.

📎 Что с этим делать менеджеру?
Разделять продуктовые релизы и юридическую приемку.

Если фича необходима по договору, но бесполезна на старте MVP, договаривайтесь о поэтапных релизах. Запускайте MVP1 без нее, собирайте фидбек и параллельно дорабатывайте остальной скоуп под подписанный акт.

Железная дисциплина не приведет команду к лучшей эффективности. А что приведет?

Зафиксируем несколько практик, которые для любой ниши или команды будут полезны.

1️⃣ Красная нить от общей стратегии до каждого действия разработчика. Самый большой демотиватор для инженера — непонимание смысла своей работы. Если человек знает, зачем он перекрашивает кнопку и как это повлияет на генеральный результат, он относится к задаче иначе. Даже если и правда просто перекрашивает кнопку.

2️⃣ Прозрачный и описанный путь доставки ценности. Чем меньше догадок о следующем шаге, тем меньше когнитивной нагрузки. И тем меньше задачи зависают между этапами. Когда не нужно гадать, какие блокеры откроет релиз, работать становится проще.

3️⃣ Не хвататься за новую задачу, пока текущая не дошла до прода. Разработчики торопыги по природе: хочется отдать задачу в тестирование и сразу бежать дальше. Но когда приходят баги по старой задаче, контекст уже потерян, и переключение съедает время. Если оставаться в контексте до отметки DONE, процесс ощутимо ускоряется.

4️⃣ Явно разделять Discovery и Delivery. Когда инженер вынужден додумывать за кого-то вещи, которые зависят от интерпретации, он теряет фокус на качественной реализации. Исследование идеи и производство продукта — разные процессы с разной логикой. Смешивать их дорого.

5️⃣Банальное, но фундаментальное: эффективность — это люди. Способность вовремя подсветить проблему в коммуникации или по-настоящему вникнуть в бизнес, для которого делается продукт, — это софт-скиллы и мудрость управления ресурсами. Полагать, что результата можно достичь одной железной дисциплиной, — самообман.

ИИ доломает то что у вас в команде уже сломано, но есть и хорошая новость

Опытную и перформящую команду агенты усилят, это очевидно. Если процессы и до ИИ были в порядке, эффективность вырастет. Но работает это и в обратную сторону.

Если агентов берет в руки незрелая команда, все ее проблемы заиграют новыми красками. Несовершенства процессов станут заметнее, это навредит продукту. Поэтому важно подготовиться заранее: нормальные тестовые контуры, задокументированные требования, понятные правила работы.

Отсюда и разброс в результатах: у одних команд lead time падает, у других растет. Потому что не все умеют пользоваться инструментом (и просто нормально работать тоже). Кто-то забивает микроскопом гвозди, а кто-то уже отдал ИИ весь цикл от анализа до проектирования.

А еще ИИ меняет саму роль инженера. Когда код перестает быть узким местом, освобождается время, которое можно тратить на то, чтобы разобраться в предметной области и понять, для кого делается продукт.

Условному фронтендеру становится не все равно, удобен ли интерфейс кладовщику, который бегает по складу в перчатках со старым планшетом. Ценность написания кода падает, а архитектурного мышления и качественного код-ревью — растет. Инженер теперь скорее цензор сгенерированного кода, а не его автор.

Параллельно происходят другие изменения: менеджеры становятся технически подкованнее, ТЗ — полнее, а коммуникация между бизнесом и разработкой — богаче. И это тоже понемногу работает на общую эффективность.

⚽️ Запустили ещё один проект в спортивной отрасли — встречайте QOFA!

QOFA — цифровой портал для Карагандинской областной футбольной ассоциации Казахстана.

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

Меньше чем за год мы вместе с ассоциацией сконструировали систему профессионального уровня. Внутри: админка для организации турниров, протоколы матчей, публичная витрина, где болельщики, родители и спонсоры в реальном времени видят результаты, таблицы и статистику по командам и игрокам.

Региональный футбол — фундамент всей футбольной системы страны: здесь готовят резерв, растят тренеров и судей. И теперь есть сервис для оцифровки всех ассоциаций, с которым в будущем получится создать единную базу всего массового футбола Казахстана и оцифровать все процессы.
Так реализуется движение к глобальной цели: поднять уровень массового футбола до профессиональных турниров и соревнований.

Дрим-тим, спасибо за блестящую игру! 🏆