Все идет по скраму

Готов поспорить на пиво, что самый полезный навык будущего - реверс инжиниринг. Кому-то придется разбираться в том вайбкоде, на котором сейчас запускается бизнес. В общем-то, ничего нового. Лет 10 назад, на фриленсе, самые вкусные заказы были от отчаявшегося малого бизнеса, которому нужно было быстро добавить фичу в свой продукт, собранный за две сотки уставшим фриленсером. За такое платили уже не две, а три сотки, конечно же😏

Не знаю чем вам Max не нравится

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

Очень раздражает, когда люди для объяснения своих решений используют аргументы "так правильно" или "так лучше". Я понимаю такую аргументацию в быту, но на работе за такое надо леща давать. "Лучше" это оценочная характеристика. За ней должно следовать объяснение "лучше по сравнению с чем?", "для кого?" и "по каким параметрам?". Зуб даю, в большинстве случаев "лучше" это удобный способ сказать "отъебись, я всегда так делал". А "правильно" это удобный способ сказать "отъебись, я не знаю, но на хабре пишут что так лучше". У нас с такими аргументами появился k8s, pgbouncer и rabbitmq. В админке на 10 человек без интеграций. Как вы понимаете это все "правильно" и "лучше" затащить их заранее.

Хехе. Теперь даже у библиотеки компонентов есть свой MCP сервер. https://chakra-ui.com/docs/get-started/ai/mcp-server С другой стороны как еще научить LLM-ку писать код, используя твою "никому не известную" библиотеку. Видимо теперь вместе с инструментами для разработки нужно еще и AI Rules, MCP и другие инструкции для ИИ-шки предоставлять.

Будильник включи. А то дейли проспишь😏

Фух, вот это я награфоманил, да? А теперь, дамы и господа, расчехляйте ваши 🎄! Время резать салаты и готовиться к празднику. Выключайте будильник, прячьте подальше рабочий ноут и помните: хорошо работает тот, кто хорошо отдохнул. С наступающим!

Последняя часть, обещаю! Закон Конвея помните? Вот прототип его отлично показывает - франкенштейн, собранный из компромиссов и договоренностей в команде. В таблицах данные отображаются по-разному, формы работают неочевидно, а API иногда удивляет респонсом. В общем, прототип работает, но не создает ощущения цельного продукта. Да и откуда взяться целостности, если нет "режиссера", который видит общую картину и задает рамки для команды? Я погуглил и не нашел хоть сколько-нибудь известных фильмов, где было несколько равноправных режиссеров без кровного родства (привет Вачевски!), снимавших одну картину, а не новеллы (Четыре комнаты, например) и работавших над фильмом одновременно, а не заменяющих друг-друга (как Кубрик, пришедший доснять Спартак). Получается, что хороший продукт базируется на видении одного человека, но все еще состоит из вклада всей команды. Где был бы Питер Джексон без художников по костюмам? Как быстро поехал кукухой, если бы ему пришлось продумывать концепт каждого костюма, что бы отдать его художнику? Но зуб даю, рамки, которые он задавал своим видением, помогли команде сделать шедевр. Что-то я отвлекся... Мы тут не Спартака снимаем, да и я не Кубрик, но роль "режиссера" очень важна в команде. Он забирает у команды когнитивную нагрузку удержания целостности продукта. Да и за результат отвечает тоже он. Это не значит, что нужен диктатор. Я все еще не хочу превращаться в менеджера, который сидит 24/7 в чатах и пишет подробные задачи, пытаясь думать за команду. Моя задача выстроить правила решения конфликтов и снять с разработчика необходимость думать за весь продукт. Так родились зоны ответственности: - PO: взаимодействует с клиентами и бизнесом, формирует гипотезы с метриками (фокусируется на «зачем», а не «что»). С него спросят, если продукт не принесет пользу. - Руководитель разработки: продумывает решение для проверки гипотезы, встраивает его в продукт и передаёт видение команде (через истории, раскадровку и др.). Его будут отчитывать за качество продукта. - Команда разработчиков: реализует решение - от дизайна элементов до архитектуры и интеграций. К ним придут с вопросами о скорости работы продукта, качество интерфейса, стабильности и т.д. Теперь, в случае конфликта, мы знаем кто должен сказать последнее слово и получили простой процесс работы: гипотеза -> концепт -> реализация -> наблюдение. Надеюсь, теперь нам не придется идти на компромиссы. Всегда будет тот, кто может принять решение, пусть и неприятное, но полезное для продукта. Еще я надеюсь, что команда не замкнется в своих зонах. Ведь ответственность за кусок работы не означает, что твои решения нельзя обсуждать и предлагать идеи. Да и конфликты необходимы для развития команды, но они должны быть продуктивными. Ладно... Требовательность и продуктивные конфликты это уже другая история на следующий год. Последние пару недель вся команда подбирает технические хвосты и собирает фидбек от пользователей. Парни молодцы и сделали очень много, так что теперь время чиллить и готовиться к празднику.

Это упрощённый пример планирования с картой сценариев. В реальности она в 10 раз больше и описывает несколько ролей. Сверху карта, снизу релизы, в них фичи. С первого релиза мы даем возможность пройти сценарий, а потом улучшаем путь. Бонусом этот подход облегчает тестирование: с картой очевидны приоритеты багов и она, по сути, описывает шаги e2e тестов. Оказывается, даже паттерн для тестирования сценариев существует - screenplay pattern. Сначала у нас обкатаем, потом вам расскажу.

Я уже видел как процессы превращаются в бюракратический ад, тормозя разработку. В таких командах любое изменение проходит через карусель согласований и проще сделать как сказали, чем пытаться сделать лучше. К счастью, мы маленькие и бюрократия нам не нужна. По этому я задумал очень простой подход: - Мы с PO описываем пользовательские сценарии - Вместе с разработчиками накидываем детали реализации - Дробим на релизы - каждый содержит полный сценарий, но с разным уровнем проработки (от минимума к удобному UX) Звучит прекрасно - каждый может быть автором проекта, но что делать, когда у двух авторов конфликт? Я постоянно повторял: "мы взрослые люди и должны уметь договариваться", очевидно, это не так просто. На всех 1-1 я слышал одну и ту же боль: нет единого источника правды. Мне нужно было придумать как это исправить, не забирая у команды авторство. Я всеми силами избегал превращение разработчиков в ИИ, генерящий код по спекам, но в этот момент мне казалось что я выбрал слишком сложный путь и не затащу его. Проблема существовала, но работе она не мешала. Конфликты решались компромиссами. Например, на старте мы хотели делать offline first, но в процессе API перестало учитывать ограничения такого подхода и фронт, что бы избежать конфликта с бекенедером, переписал часть логики под новый формат. Или количество статусов выросло с 5 до 15 из-за решения PO, а мне пришлось на выходных вкорячивать новый enum в БД. Каждый такой компромисс жрал силы и время разработки. Иронично. Теперь нас тормозила не бюрократия, а свобода. Это не было смертельным, как температура 37.2. Спринт не пробежишь, но до финиша доковыляешь. Многие команды так всю жизнь живут. Но я-то хочу сильную и здоровую команду, а для этого нужно устроить встряску нашему "больному", вытащив симптомы наружу. Я прикинул сколько времени нужно на завершение прототипа, согласовал этот дедлайн с командой и договорился с PO собрать фокус группу на демо. Внешнее обещание работает как рубикон - всем будет неловко показывать недоделанный продукт. Затем, накидал список оставшихся фичей и наметил даты завершения каждой. Работать пришлось в полную силу и наша 37.2 стала повышаться. В команде появились конфликты и я, наконец-то, увидел первопричину наших проблем. Да и ребята почувствовали острое желание решить проблему. Кстати, в сроки мы попали. Даже сделали пару дополнительных фичей, которые придумали разработчики. На демо ничего не отвалилось, а получившийся прототип решал проблему пользователей, пускай и топорно. Но для меня было важнее то, что корень проблем стал очевиден, а решение пришло само собой. С этим решением я и пришел на наше первое командное ретро.

Так вот. Найм. Ты же в курсе как сейчас рынок штормит? HR-ов закидывают сотнями сгенеренных резюме, а они в ответ, не глядя, отсеивают 99% людей через ИИ фильтр. Всем сложно, все недовольны. Вот и наши HR-ы были перегружены и им было не до маленькой команды со специфичными запросами. Вспомнив, что "спасение утопающих - дело рук самих утопающих", я нашел среди знакомых владельцев каналов с вакансиями в ТГ. Написал максимально честную вакансию. Не потому что я такой правильный, а потому что врать в вакансии это прямой путь найти не того, кто нужен. Опубликовал и понеслось... За неделю я получил больше 50 откликов. Чего там только не было: стаж работы с 16 лет, тимлид в 20 лет, умение использовать чат гопоту... Короче, осталось 20 резюме, которым я назначил собес. Из них нам подошли 3 кандидата, из которых 2 честно признались, что не хотят к нам. Последнего дожившего до оффера пришлось уговаривать нашему СТО. Так мы нашли бекендера, а я понял, что нужно не только уметь отсеивать, но и продавать вакансию. Мы не заставляли кандидатов крутить деревья и лайвкодить. Нам были важны софты, так как техническая сложность проекта была минимальна и нужен был тот, кто не повысит ее искуственно. Такие навыки невозможно проверить по чеклисту и приходилось проводить полноценное интервью с каждым кандидатом. Еще и превлекать всю команду, что бы не вводить отдельный этап "знакомства", затягивая найм. Мы обсуждали прошлые проекты, задавали смешные вопросы (мой топ: почему твой предыдущий начальник дурак?) и рассказывали о проекте. На старте на это уходило минимум час и еще пол часа на обсуждение, но в итоге стало хватать 30 минут на знакомство и принятия решения. Кстати, это отличный пример, как группа людей постепенно вырабатывает одинаковые критерии "качества" кандидата и учится их оперативно выявлять. Срабатывались, короче. Таким образом, взяв на себя работу HR-ов и нарушив все корпоративные процессы найма, мы справились с поиском. Запишу это в успехи, ведь если бы мы шли по шаблону, мы бы еще долго ждали "повышения приоритетов найма в вашу команду". Иногда лучше просить прощения, а не разрешение. Ауф! Теперь у нас была команда из меня, PO и двух разработчиков. Команда была, а выстроенных процессов не было.

На проекте меня встретили тонны спецификаций и макетов, описывающих до мелочей продукт, который от нас ждали. Кто ждал? В основном product owner, так как реальные заказчики были заняты и не особо интересовались разработкой. Спеки были великолепны. Описывался каждый закуток интерфейса. Даже поля в БД и взаимотношения сущностей были бережливо расписаны аналитиками. Я не знаю как, но они, фактически, описали архитектуру без технарей в команде. Потрясающе. Вот бы они еще код писали. Я перелопачивал тонны спецификаций, но так и не нашел ответ на главный для меня вопрос: зачем мы это делаем? PO (product owner), рассчитывал что на разработку по спекам потребуется от 6 до 12 месяцев. Т. е. следующим летом мы бы показали пользователям инструмент который им (как-то) поможет. Он ждал, что сейчас придут разработчики и как начнут код писать! Для них все подготовили - осталось байтики туда-сюда погонять и дело в шляпе. Я пришел. Отложил найм команды. Полез к PO с вопросами: Зачем мы это делаем? Кто пользователь? Как они работают сейчас? Как им поможет наш продукт? Как мы принесем прибыль компании? Сначала меня одаривали снисходительной улыбкой: Мишань, уже все запланировали. Давай по спекам сделаем, мы же их не зря писали? Я начал задавать вопросы напрямую бизнесу и ответы не матчались со спеками. Тогда улыбка стали шире, но злее: Миш, все описано в спецификациях, если ты потрудишься их прочитать, конечно... Тем временем я вытащил из бизнеса сформулированные цели, для которых нужен продукт. Улыбка стала уставшей: Хорошо, сделаем как ты говоришь и посмотрим. Я нарисовал карту пользовательских историй "as is" и на ее основе мы накидали карту прототипа. Прототип был гипотезой, что мы таким вот решением приблизимся к бизнесовым целям, затратив минимум усилий. Честно говоря, я даже не пытался оценить время на его реализацию, я просто выкидывал вообще все что могло затормозить: красивый UI? Не сегодня. Сложная валидация полей? В топку. Все под нож в угоду скорости. И что в итоге? Гипотеза не работала. Настолько, что прототип можно было выкидывать. Не работала из-за людей, которые не смогли договориться между собой. А знаете когда они начали говорить? Когда я пришел с прототипом и сказал "Все готово - ждем вас! Договоритесь уже!". Вот было бы смешно, если бы мы следовали изначальному плану и вбухали год разработки команды из 6 человек, что бы упереться в политику на финальном этапе. Так, подожди! Я сэкономил деньги компании, а мог бы дать работу людям на целый год? Я точно поступил правильно? Так или иначе, мы сделали MVP. За месяц, силами одного фронта, который освоил fast api и накидал бекенд так, что бы прототип можно было пощупать. Голова, а не фронтендер, спасибо ему. А могли бы проверить гипотезу еще быстрее. Если бы я не пасовал и дожимал С-level в спорах, то они бы начали договариваться сильно раньше. Мы бы уткнулись в проблему не написав ни строчки кода. Красиво! (Или нет, я все еще не понимаю) Погрустив над результатами, мы придумали следующую гипотезу. На этот раз взяли уже существующие процессы, разложили их на этапы и выбрали самый болезненный для пользователей. Убедились, что мы можем сделать очередной прототип для проверки гипотезы и приступили к работе. А пока наш единственный разраб пилил прототип я погряз в найме (и всех туда затащил).

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

Тут какой то умный парень в Стэнфорде рассказывает о будущем разработки с ИИ: https://t.me/denissexy/11080 И, если отбросить все что связано с генерацией кода, остаются хорошие тейки, которые часто говорят, но мало используют. Код стал дешевле - дороже стало “решить, что строить” и “описать это четко”. Так было всегда. Написать код это малая часть работы, которая ещё сильнее обесценилась. Понять проблему и спроектировать решение так, что бы оно было полезным - вот где настоящая сложность. Вам придётся учиться спрашивать "зачем?", если не хотите сливать деньги в разработке. Умение разговаривать с пользователями - это ускоритель разработки Так было до ИИ. Ждать от пользователя чёткого ТЗ глупо. Провести интервью, погрузиться в бизнес домен, выявить проблему - лучший способ избежать траты времени. Ну, т.е. "ускориться". Можно огородить разработку менеджерами, дизайнерами и аналитиками, но это костыль для команд у которых нехватает софтов. За этот костыль вы платите искажением информации на каждом этапе и не даёте команде прокачать эти самые софты. Хороший “долг” - быстрый прототип, который приносит проверенную пользу/знания и окупает поддержку Эта идея в основе всех гибких методологий. Тут тоже ничего нового, потому что MVP это следующий шаг для того что бы показать пользователю прототип и спросить - это то что ты хотел? Мы и раньше говнокодили в стартапах ради быстрого результата. Но теперь, видимо, это будет ещё быстрее. Думаю, что дальше мы увидим расцвет небольших продуктовых команд из кроссфункциональных разработчиков. Им не нужна бюрократия, которая тормозит корпорации, но они могут делать масштабные проекты за счёт делегирования части работы ИИ-шкам. Возьмут лучшее из двух миров.

https://vereis.com/ - зацените сколько стиля в этом блоге💃

А вообще к чему я распинался? Недавно меня позвали обсудить эту тему два Ивана в свой подкаст, за что я им очень благодарен. Но так как я впервые говорил с людьми под запись, получилось... Нормально... Но мне нужно научиться не растекаться мыслями и перестать нервничать. Тем более, что слушать живое общение интереснее, чем читать мои монологи. Спасибо Ивану 1 за то что помогал формулировать и Ивану 2 за хорошие вопросы. Кто из них кто решите сами, пока слушаете: https://doubleivan.mave.digital/ep-38

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

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

- Ладно, допустим это не обучение, но мне нужно что бы Петя и Вася знали о работе друг друга. Иначе каждый замкнется на своей задаче и не будет понимать что происходит в проекте. Если Петя не знает чем занят Вася, то они не в одной команде. У команды есть общая цель, для достижения которой необходимо обмениваться информацией. А у твоих ребят единственная причина обмена информацией это кнопка апрув? Может быть дело в плохой топологии команд? Бывает, что одна команда так разрастается, что, фактически, перестаёт быть командой. Для проверки попробуй сформулировать единственную цель спринта. Не получается? Значит проблема не в том, что Вася с Петей не в курсе работы друг друга, а сильно глубже. Но даже если не углубляться, то зачем Васе ждать, пока Петя прочитает его код? Сделай так, что бы этот процесс был асинхронным. Пусть смотрят МР-ы тогда, когда им удобно. Постревью или дайджест с изменениями, как хочешь. Зачем вообще нужно читать код? Твоя цель что бы все знали об изменениях, так пусть Вася пишет диздок прямо в МР-е. Это сэкономит кучу времени и сил, ведь вместо того что бы продираться через изменения в коде будет достаточно прочитать о причинах этих изменений. Глядишь, так до ADR дойдёте...