Про нестандартные решения и продуктовых инженеров
Мы тут обсуждаем в наших командах, как строить разработку в новых условиях и возможностях. Так чтобы это и не вайбкодинг, но и не эджайл по-советски. Понятно, что сквозная агентная инженерия, спеки, харнесс, подписки, все дела... Но пока продакт и инженер-билдер это не один человек, проблемы в коммуникации и сквозных бизнес-процессах неизбежны. Это просто как преамбула.
***
Думаю, вы понимаете, что в одиночку единорога уже можно конечно пробовать, но пока это скорее ошибка выжившего, как и в целом с успехом. Как правильно -- все знают. В теории.
Так вот, мы по-прежнему командами работаем. Небольшими командами. Может быть расскажу как-нибудь об этом подробнее.
Но сегодня о другом.
Обновили и утвердили очередную методологию процесса разработки. В моменте все счастливы. Но вы думаете она нас сделает успешными? Ну нет конечно.
Успешными людей и компании делают нестандартные решения.
И что интересно, способность принимать такие решения часто возникает с двух противоположных концов опыта.
Либо вы дурак или новичок, что в данном случае практически равноценно, и просто еще не знаете, что так нельзя.
Либо вы профи с огромным прикладным опытом и уже слишком хорошо знаете, почему именно так нельзя, когда это действительно нельзя, а когда вполне можно.
Все, кто посередине, обычно лучше всех знают, как правильно.
Давайте признаемся, что мы все плюс-минус посередине. Поэтому рассчитывать на спасительное незнание правил или гениальность огромного опыта нам не приходится. Придется включать голову и сознательно учиться делать иначе.
И вот тут начинается самое интересное. Можно сколько угодно улучшать спеки, чистить контекст и описывать процесс, но в реальной разработке инженер все равно постоянно будет сталкиваться с противоречиями, пропущенными сценариями, решениями, которые на бумаге выглядели разумно, а в коде внезапно перестали быть таковыми.
И в этот момент у него есть два варианта. Непрерывно итерировать в агентских циклах строго по PRD и дельтам или глубоко понимать что и для кого он делает, чтобы самому, или совместно с продактом, принимать нестандартные решения там, где закончилась спецификация, а продукт еще не случился.
Решил об этом не в командных чатах, а с трибуны, как Владимир Ильич. Может кому тоже полезно будет.
Неотправленный пост моим командам:
Вы же помните, что конечная цель каждой команды это создать сильный продукт и как можно быстрее довести его до рынка, а не построить правильную методологию разработки? Мы собираем команды, чтобы выигрывать на рынке, а не чтобы идеально соблюдать процесс.
Методология для нас по сути побочный продукт накопленного опыта. Она должна помогать нам двигаться быстрее и совершать меньше повторяющихся ошибок.
Но в тот момент, когда конкретное правило начинает мешать скорости нашего процесса или качеству продукта, мы немедленно будем его нарушать столько раз, сколько потребуется.
Поэтому я пока по-прежнему буду полагаться больше на инженеров с сильным продуктовым мышлением. Никакая методология не должна превращать их в исполнителей спецификаций или электриков, соединяющих провода изолентой.
Надо давать им возможность самостоятельно восстанавливать смысл, замечать противоречия, задавать вопросы, принимать инженерные решения с учетом продуктовой цели и вытягивать продукт даже через неизбежно неполный, противоречивый и замусоренный контекст. Он все равно не будет полным. Он у людей-то всегда не полон!
Можно убиться за чистоту контекста, но так и не сделать продукт или так и не вывести его на рынок. Таких большинство, если что. А делают все по уму.
Так что продуктовый контекст и методология не должны заменять мышление.
В условиях стартапа, скорость появляется не тогда, когда человек точно следует процессу, а когда он хорошо понимает, какой пользовательский результат мы хотим получить, и берет ответственность за путь до работающего продукта.
Другими словами, включает голову, по полной.
