Про нестандартные решения и продуктовых инженеров

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

***

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

Так вот, мы по-прежнему командами работаем. Небольшими командами. Может быть расскажу как-нибудь об этом подробнее.

Но сегодня о другом.

Обновили и утвердили очередную методологию процесса разработки. В моменте все счастливы. Но вы думаете она нас сделает успешными? Ну нет конечно.

Успешными людей и компании делают нестандартные решения.

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

Либо вы дурак или новичок, что в данном случае практически равноценно, и просто еще не знаете, что так нельзя.

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

Все, кто посередине, обычно лучше всех знают, как правильно. 

Давайте признаемся, что мы все плюс-минус посередине. Поэтому рассчитывать на спасительное незнание правил или гениальность огромного опыта нам не приходится. Придется включать голову и сознательно учиться делать иначе.

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

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

Решил об этом не в командных чатах, а с трибуны, как Владимир Ильич. Может кому тоже полезно будет. 

Неотправленный пост моим командам:

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

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

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

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

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

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

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

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

Другими словами, включает голову, по полной.