Последние посты

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


Продуктовая (раз)Работка
15 сент., 06:20
Привет, это Веня! Расскажу сегодня, почему не нужно умно думать, а нужно тупо делать 👍На этапе захода в новый проект всегда куча сомнений и страх ошибиться. Хочется сначала продумать все до мелочей, чтобы потом не облажаться, стартануть максимально правильно. И вот это желание все просчитать заранее как раз и есть главный блокер: ты неделю готовишься начать, вместо того чтобы начать.Помню, кто-то где-то давал совет: не знаешь, с чего начать писать, напиши «так, б@ать» и дальше польется. Тут работает такой же прием. Вместо того чтобы сомневаться и продумывать все до мелочей, лишь бы не ошибиться, надо просто сделать минимальный первый шаг. Пусть даже он будет максимально тупой.Раньше я либо гугл-таблицу, либо гугл-док создавал и просто вываливал туда свои мысли по тому, как делать непонятную задачу. Из этого рождалось понимание задачи, а из
Продуктовая (раз)Работка
11 сент., 08:20
Если срочно нужно застопорить проект, стоит подождать, когда все станет понятно 💭На проектах регулярно всплывают сложные, незнакомые задачи с кучей неизвестных. И человек, который за них отвечает, подвисает. То ли боится, что не справится. То ли просто откладывает. То ли ждёт, пока всё прояснится само. Но пока он ждёт, ничего не происходит.Ведь всегда приятнее начинать, когда задача уже понятна. Только полного понимания можно и не дождаться. Нам ближе принцип «ничего не понятно — всё понятно».Напрмер, делаем фичу «Расчёт стоимости страхового полиса», поначалу непонятно вообще ничего. Раскидываем по верхам: от каких факторов зависит цена, откуда берутся коэффициенты, где человек вводит данные и что видит на выходе. Крупными мазками уже ясно. Дальше зумимся в один кусок, скажем «от чего зависит коэффициент», и снова упираемся в неопределенность.


Продуктовая (раз)Работка
8 сент., 10:53
Как проектирование архитектуры превращается в черную дыру в бэклоге и как с этим быть 🖥Бывало у вас такое? На старте проекта или какой-то большой фичи даешь такую задачу тимлиду или разработчику, он уходит в малиновый закат глубоко думать. Проходят дни, недели, а на вопрос «когда будет готово?» ответ туманный. Мол, надо еще изучить и проработать, a few sprints later — на выходе — 2 картинки с квадратиками и отстающий по срокам проект.Почему так происходит❓Разработчиков понять можно, ведь задача а) важная б) интересная в) сложная (для многих это дополнительный бонус!) г) редкая (эпик вин!) и очень хочется сделать максимально качественно, не ошибиться, да и просто потянуть удовольствие и насладиться моментом.Да, и забыл главное: это задача высокой степени неопределенности.🔤Много


Продуктовая (раз)Работка
4 сент., 10:49
На этом канале мы обычно разбираем то, что можно описать и зафиксировать: архитектуру, процессы, команду, роли. Но есть один артефакт, который в документ не занесешь, но и проект без него вывезти будет тяжко. Это честность.Честность в проекте начинается с готовности говорить неудобное. Что на дистанции обязательно что-то пойдёт не так, планы поменяются, форс-мажор случится. Что всё, о чём клиент мечтает на старте, в продукт целиком не влезет. И что не раз придётся вместе принимать неприятные решения: упрощать, от чего-то отказываться, переносить на потом, чтобы успеть в срок и не вылететь из бюджета.Можно, конечно, сказать «всё будет!», подписать контракт и разгребать завалы потом. Но доверие вдолгую так не строится. И честность обязана быть обоюдной. Если заказчику внезапно всё нравится, он либо в эйфории, либо чего-то недоговаривает, и это молчание потом аукнется на самом


Продуктовая (раз)Работка
1 сент., 09:30
Тимлид, техлид, продакт — роли уже знакомые. А вот про мишн-лида слышали? ℹ️Обычно, чтобы начать влиять на продукт и уйти от чисто исполнительской функции, разработчику предлагают один путь: уйти в менеджмент. Но есть компании, которые придумали, как дать это влияние, не вынимая человека из разработки. Практику под названием Mission Lead нам на круглом столе про продуктового разработчика описал Антон Бевзюк, инженерный менеджер Mindbox.Работает так. Сеньорный разработчик берёт на себя ответственность за короткую бизнес-цель, которую небольшая команда из трёх-четырёх человек может закрыть за месяц-два. Цель бизнесовая, но отвечает за неё именно разработчик.Он погружается в проблему вместе с продактом и дизайнером ещё на этапе, когда выясняют боль заказчика и её масштаб. Дальше готовит архитектурное решение и защищает его перед архитектором,


Продуктовая (раз)Работка
28 авг., 08:55
Бесконечные улучшения: что в бэклог, а что — в работу ✏️Возьмём большой продукт, где заказчик сам выступает владельцем продукта. Работа ведется долго, мы итеративно развиваем решение. Большинство идей по улучшению идёт от него, он же приоритизирует бэклог. Мы тоже можем что-то предложить, но без глубокой проработки. Если идея кажется стоящей, выходим на аналитику за счёт клиента и дальше по стандартному процессу. Но чаще наши предложения уезжают в бэклог: у клиента свой текущий приоритет, и распыляться он не хочет. Мы иногда напоминаем, чтобы он про них не забыл.Это в основном про крупные фичи. С мелкими правками проще: часть делаем сразу, когда понятно, что дешевле потратить время сейчас, чем переделывать потом. Но и это согласуем. Убедили клиента, берём; не убедили, откладываем. Клиент платит деньги, у него сроки ещё с этапа планирования, и чтобы


Продуктовая (раз)Работка
25 авг., 10:59
Ускоряйтесь, только не говорите как именноВот мы тут поныли и про нагенерированные ТЗ, и про «давайте подойдем творчески, чтобы побыстрее и подешевле». Из этих штук еще одна проблема вытекает, с которой вы, наверное, тоже уже сталкивались…Бизнес все это приносит, кивает на творческий подход и вообще всей душой за прогресс. А потом мы на переговорах честно говорим, что часть проекта команда соберет с помощью ИИ-агентов и не будет выписывать каждую строчку вручную. И вот тут желание ударить по рукам с той стороны почему-то убавляется.То есть ускорение нейросетями заказчик вроде бы использует и сам подразумевает, но подразумевает молча. Ему нужно, чтобы мы там у себя внутри как-то ускорялись и приносили результат быстрее, а как именно, знать не хочет. А если еще сказать «мы вам навайбкодим», то про контракт можно сразу забыть.Явную нейросетевую разработку не покупают из принципа,
Продуктовая (раз)Работка
21 авг., 09:35изменён
Привет, подписчики. Пришли к вам пожаловаться и узнать, у кого так же 🤪Бизнес сейчас часто приходит с нагенерированными ТЗ. Скидывают 17 страниц текста и вот, говорят, все расписано, берите в работу.Но а работать с таким ТЗ невозможно ведь. Говоришь об этом, и люди обижаются, говорят, мол, как так, МЫ ЖЕ НА ЭТО ВРЕМЯ ПОТРАТИЛИ. Ну, классно, очень жаль, что впустую было потрачено 30 минут.И вот сложно пока это донести так, чтобы человек понял, что это не мы обнаглели, а действительно материал бесполезный и очень синтетический.У кого так же происходит, что думаете по этому поводу?


Продуктовая (раз)Работка
18 авг., 12:14
Ребята, нам надо побыстрее и подешевле. Давайте подойдем творчески! Вот сколько раз к вам с таким запросом приходили? У нас это каждый третий, наверное.Тут понятно, можно встать в оборону и начать рассказывать, кто и почему не прав. Но если подойти творчески и разобрать, что мы реально способны сделать, чтобы это пожелание удовлетворить?Думаем, чем можно пожертвовать и что можно не писать руками. Смотрим, что выкинуть из MVP по-максимуму. То есть с оговорками, но пожелание клиента выполнимо, если он готов принять то, из чего складывается цена ускорения и удешевления.Этот запрос ведь заметно участился с тех пор, как ИИ стал формировать ожидания заказчика: нейронка пишет код за пять минут, значит продукт должен собираться за неделю и за три копейки. Как часто к вам приходят с таким? Расскажите в комментариях, интересно послушать с разных сторон.


Продуктовая (раз)Работка
14 авг., 11:04
Человек зачастую делает плохо не из вредности, а потому что он думает, что это хорошоЧасто сложно дать негативный фидбек. То не хочется рубить с плеча, то боимся человека обидеть. Плюс в это же еще надо время и энергию вкладывать, чтобы нормально этот фидбек донести.Вы молчите, а человек искренне уверен, что все делает нормально, и завтра сделает ровно так же. А потом через полгода с человеком приходится расставаться, и в этот момент он впервые узнает, что все это время что-то было не так.Руководитель, который не хотел человека расстраивать, в итоге поступает с ним куда жестче, чем если бы честно сказал все полгода назад.А вы как, боитесь давать негативный фидбек? Как это делаете? Есть ли кроме 1на1 и перформанс ревью какие-то инструменты?


Продуктовая (раз)Работка
11 авг., 11:52
Хороший руководитель вытащит проект даже с посредственной командой и кривыми процессами. А плохой похоронит и тот, где команда супер и процессы на пятерку. Признавать это немного обидно, особенно зная, сколько сил обычно уходит на выстраивание этих самых процессов.
Продуктовая (раз)Работка
6 авг., 10:33
🐞 Софт без багов бывает?Если мы посмотрим описание новой версии любого продукта, увидим, что в ней исправлены баги. Но каждый последний исправленный баг — предпоследний. И не важно, это пет-проект студента или продукт бигтеха с командой выпускников MIT.При этом бизнес резонно ждёт, что софт будет просто работать: мы же четко все описали и спроектировали, почему нельзя сразу сделать без ошибок? Это расхождение в мировоззрении — вечный источник конфликтов между бизнесом и разработкой. Разрешается оно просто: нужно отойти от бинарного «работает / не работает».Для начала разберемся, почему баги все-таки неизбежны?Программы в общем выглядят как набор детерминированных инструкций «ЕСЛИ Х, ДЕЛАЙ Y», а вариантов их сочетаний просто прорва. Плюс разные ОС и железо, на которых наш софт работает. И собирается он, кстати, из разного другого софта:


Продуктовая (раз)Работка
4 авг., 11:18
⚡️Давайте не путать релиз и приемку, а то поссоримсяДиалог следующий:PM: Что нам осталось доделать, чтобы наконец зарелизиться?Клиент: Ну, без фичи Х я у вас проект не приму.PM (паникует и бежит к команде): Релиз отменяется, срочно пилим фичу Х, без неё никак.Команда негодует. Релиз откладывается на пару недель. И все на проекте в плохом настроении.💡 Релиз ≠ Приемка Это два принципиально разных понятия, которые почему-то путают:Релиз — про продукт и ценность. Ваша задача — как можно быстрее выкатить рабочую версию (MVP), чтобы пользователи решили свою проблему, а вы получили метрики и фидбек. И релизов в одном продукте по мере его разработки будет масса.Приемка — про формальности и деньги. Это выполнение юридических договорных обязательств. Клиент говорит «не приму» не потому, что фича нужна в первый день
Продуктовая (раз)Работка
30 июл., 12:58
Железная дисциплина не приведет команду к лучшей эффективности. А что приведет?Зафиксируем несколько практик, которые для любой ниши или команды будут полезны.1️⃣ Красная нить от общей стратегии до каждого действия разработчика. Самый большой демотиватор для инженера — непонимание смысла своей работы. Если человек знает, зачем он перекрашивает кнопку и как это повлияет на генеральный результат, он относится к задаче иначе. Даже если и правда просто перекрашивает кнопку.2️⃣ Прозрачный и описанный путь доставки ценности. Чем меньше догадок о следующем шаге, тем меньше когнитивной нагрузки. И тем меньше задачи зависают между этапами. Когда не нужно гадать, какие блокеры откроет релиз, работать становится проще.3️⃣ Не хвататься за новую задачу, пока текущая не дошла до прода.


Продуктовая (раз)Работка
28 июл., 11:12
ИИ доломает то что у вас в команде уже сломано, но есть и хорошая новостьОпытную и перформящую команду агенты усилят, это очевидно. Если процессы и до ИИ были в порядке, эффективность вырастет. Но работает это и в обратную сторону.Если агентов берет в руки незрелая команда, все ее проблемы заиграют новыми красками. Несовершенства процессов станут заметнее, это навредит продукту. Поэтому важно подготовиться заранее: нормальные тестовые контуры, задокументированные требования, понятные правила работы.Отсюда и разброс в результатах: у одних команд lead time падает, у других растет. Потому что не все умеют пользоваться инструментом (и просто нормально работать тоже). Кто-то забивает микроскопом гвозди, а кто-то уже отдал ИИ весь цикл от анализа до проектирования.А еще ИИ меняет саму роль инженера. Когда код перестает быть узким местом, освобождается время, которое можно тратить на


Продуктовая (раз)Работка
23 июл., 11:28
⚽️ Запустили ещё один проект в спортивной отрасли — встречайте QOFA!QOFA — цифровой портал для Карагандинской областной футбольной ассоциации Казахстана.Прежде ассоциация оставалась незаметной на фоне коммерческого спорта. Турниры были лишены единых стандартов проведения, статистика велась в блокнотах и чатах, не было никакой публичности за пределами стадиона.Меньше чем за год мы вместе с ассоциацией сконструировали систему профессионального уровня. Внутри: админка для организации турниров, протоколы матчей, публичная витрина, где болельщики, родители и спонсоры в реальном времени видят результаты, таблицы и статистику по командам и игрокам.Региональный футбол — фундамент всей футбольной системы страны: здесь готовят резерв, растят тренеров и судей. И теперь есть сервис для оцифровки всех ассоциаций, с которым в будущем получится создать единную базу всего массового футбола


Продуктовая (раз)Работка
20 июл., 10:06
К слову о поставке ценности – у команды телеги в этот раз неважно получилось.Выкатили этот убер-редактор текстов и чего? Новый вид цитат опрятно только в десктопе выглядит, абзацы текста слипаются, даже если в режиме редактирования между ними есть отбивка в строку. То есть даже базовая штука, которая была до нововведения работать перестала, если этим редактором пользоваться. Ну и прочитать пост не получается у тех, кто не обновился пока, хотя в сущности ничего супер нового в посте то в общем и нет. Дизлайк, в общем 💩
Продуктовая (раз)Работка
20 июл., 08:50изменён

Продуктовая (раз)Работка
17 июл., 11:01
3 неочевидных признака падения эффективности разработкиЭффективность разработки не падает единомоментно. Она потихоньку просаживается, подавая косвенные сигналы, которые легко пропустить, если смотреть только в дашборд.📌 Первый сигнал — резкий скачок lead time без видимой причины. Если фича обычно делалась, например, 20 дней, а теперь занимает 40, это почти всегда означает, что что-то сломалось: появились скрытые зависимости, начались системные сбои или задачи начали застревать где-то в процессе.📌 Второй — сильный разрыв между оценками и реальностью. Если маленькая задача делается неделями, а сложная пролетает за день, то вероятно ваша система планирования мертва. В таких условиях что-либо обещать бизнесу становится невозможно.📌 Третий, и, возможно, самый недооцененный сигнал —
