Комментарии 76
Какая-то у вас странная продуктовая компания с waterfall, разработчиками, рисующими "продающий зеленый"…
Теме много-много лет, так много, что мне уже кажется, что все холивары о гибких подходах отгремели.
Можно быть сколько угодно гибкими и не делать то, что действительно нужно. И можно использовать waterfall, и при этом решать задачи/проблемы клиентов и все будут довольно. Это всего лишь инструменты.
Важен результат.
Меня бы такая статья демотивировала от работы в вашей команде.
Было и несколько других моментов, например про то «идеальную архитектуру». Здесь рождается конфликт, и я понимаю вас, как продакт менеджера, выпустить продукт приносящий прибыль компании и реализующий крутые фичи для пользователей, но я вполне могу понять и разработчика/техлида, который не хочет, чтоб к нему через месяц/два/полгода прибегали вы или ваши коллеги и жаловались, что «приложение что-то долго загружается». Конфликт это не плохо, а в случае выпуска продукта, даже хорошо. Но в статье видно только «боль» продакт менеджера задачи которого яростно режутся плохими, исходя из контекста, разработчиками, которые постоянно делают рефакторинг.
Но это не значит, что я не стремлюсь стать лучше. И от команды я хочу того же. Замалчивая проблемы и не озвучивая ожидания, сложно получить то, чего хочешь.
Про конфликт и «идеальную архитектуру» полностью согласна. Я тоже понимаю разработчиков. И как я «продаю» свои продуктовые таски команде, я хочу, чтобы мне «продавали» технический долг. Я никогда не откажусь выделить время на рефакторинг, если мне расскажут, что это избавит нас от каких-то конкретных проблем.
Боль даже не в том, что продуктовыми тасками жертвуют ради рефакторинга, а в том, что разработчики хотят написать сразу «бетон» и больше его не переделывать. А в современной продуктовой разработке это почти невозможно (как раз и пыталась донести, почему)
Я никогда не откажусь выделить время на рефакторинг, если мне расскажут, что это избавит нас от каких-то конкретных проблем.
Ну значит, у вас плохо работает тим лид. Или же, если ваш тимлид еще и пишет код, у вас банально некому это делать. Потому что управление техническим долгом и его оценка вроде как тоже задача менеджера и если у вас некому ее делать, очень странно ожидать от программиста, что бы он этим занимался. В свободное время от работы?)
Боль даже не в том, что продуктовыми тасками жертвуют ради рефакторинга, а в том, что разработчики хотят написать сразу «бетон» и больше его не переделывать.
Из статьи мне показалось, что разработчики хотят для начала фундамент, на котором можно строить приложение.
И опять же таки, постоянно переделывать это тоже плохо, потому что постоянные хаотичные переделывания очень плохо сказываются на качестве продукта и обычно означают, что у вас проблемы с долгосрочным планированием.
И опять же таки, постоянно переделывать это тоже плохо, потому что постоянные хаотичные переделывания очень плохо сказываются на качестве продукта и обычно означают, что у вас проблемы с долгосрочным планированием.
Я как раз и пыталась донести мысль, что в быстроразвивающемся продуктовом мире, где постоянно нужно проверять гипотезы (чем больше, тем лучше), долгосрочное планирование — непозволительная роскошь.
У нас, конечно, есть общее стратегическое планирование, но знать заранее, какой функционал будет востребованным через 3/6/9 месяцев очень сложно. Недавний пример — 54ФЗ, фактически создавший новую отрасль.
Если мы будем так планировать каждую фичу, то будем уступать юрким стартапам. Им терять нечего, они проверяют больше гипотез, и находят те самые алмазы, за которые люди готовы платить.
Если вы планируете быть хорошей продуктовой компанией и уже не стартап, не стоит пытаться за ними угнаться, у них как раз есть свои минусы и плюсы, так же как у большой компании. Пытаясь за ними угнаться, вы получаете те же самые проблемы, вот только в крупной компании никто не любит сидеть по 12 часов на работе и текучка в большой компании обычно гораздо больнее.
никто не любит сидеть по 12 часов на работе
Тут полностью согласна, я совершенно против овертаймов
Выбор достаточно жесткий:
— или мы даем рынку хоть что-то, что закроет его боль
— или это дают конкуренты, и нас вытесняют с рынка
Все еще усугубляется тем, что мы делаем b2b решения — это значит, что клиентов у нас мало, каждый платит много (потеря даже одного клиента ощутима), они все другу друга знают. Сарафанное радио работает очень быстро.
Мы, конечно, стараемся баланс сохранять, но если мы потеряем клиентов, то любая куча кода будет бесполезна.
В то же время обратную связь нужно правильно подать. Сейчас вы описываете исключительно слабые, на ваш взгляд, стороны вашей команды. Я не услышал ни слова про то, что они профессионалы своего дела, отлично разбираются в архитектуре приложений и так далее.
Так же моей целью не была критика разработчиков. Я хотела указать на причину одного из самых частых моих конфликтов с командой и показать, почему я уделяю столько сил и времени продуктовому мышлению, почему для меня это важно (и, возможно, важно для ваших менеджеров).
И да, что касается разработки — моя команда действительно классная. Иногда даже слишком) Они действительно могут построить архитектуру и написать классный код.
Как быстро "бетон" вошёл в обиход, однако...
Почему вы думаете, что разработчики должны вам что-то продавать? У них другая работа. Технический долг и необходимость рефакторинга присутствует постоянно, просто примите это. Доверьтесь своей команде и дайте им время для рефакторинга.
Всего у нас 6 продуктовых команд, каждая из которых занимается своим направлением.
Я — менеджер продуктов для 2-команд (одна отвечает за продажи офлайн, другая — за онлайн)
1. компания разрабатывает свой продукт уже больше 20 лет
2. у компании примерно 90 продуктов, но всего 7 баз данных
3. компания поддерживает по 5 версий каждого продукта параллельно (раз в 3 месяца большой релиз, 5 последних релизов на активной поддержке)
4. компания обещает что все версии будут работать друг с другом, просто некоторые фичы могут не работать
разработка фич происходит в той же мвп схеме:
1. выпускаем мвп под кастомера максимально простой, не заморачиваясь с архитектурой (настройки в локальных файлах, в базе данных еще какие-нить пара настроек)
2. приходит другой кастомер, хочет туже фичу но с перламутровыми пуговицами
3. решаем что настройки в локальных файлах уже не катят, в базе данных теперь надо 1:n и тут большое НО — у предыдущего кастомера не должно ничего сломаться после апгрейда и он не должен ничего делать
Получается надо делать пару фоллбеков на всё подряд.
Потом 1-3 повторяется ещё для одного кастомера, потом еще для одного но в другом продукте на той же БД и так код превращается в ад. Особенно когда встречаешь функциональность прошедшую этот путь в 2005-м и уже никого нет вокруг кто вообще знает почему и зачем делали так и кто как используют этот функционал.
Так вот с точки зрения программиста решение должно быть:
1. писать нормальные апгрейд скрипты, которые апгрейдят любую существующую конфигурацию на новую модель
2. заставлять кастомеров апгрейдить все продукты
С точки зрения продуктолога:
1. на 1й пункт — это затратно, это требует делать пункт 2 (потому что апгрейд схемы БД обычно ломает существующие аппы)
2. на 2й пункт — часто бывает что при апгрейде че то ломается или надо донастраивать, поэтому приходят к выводу, что лучше пусть программисты закодят в новом продукте 33 фоллбека, чем заапгрейдить кастомеров на более менее чистую и понятную архитектуру.
Вообщем заключение что я не против выпуска МВП, но когда продуктолог понимает косты развития этого МВП далее для других кастомеров в будущем и не игнорит эти косты наращивая технический долг до бесконечности. Потому что иначе 80% работы программиста над новой модификацией превращается в походы по этажам и разговоры со старичками в поисках всех возможных сценариев и очень хочется уволиться :)
Вот да, хочется яростно плюсовать этот комментарий. Потому что часто оказывается, что продукт годами разрабатывается как "допилим быстро эту фичу как MVP", после чего у тебя оказывается просто свалка костылей, и любое изменение проходит через адовую боль и занимает кучу времени. И да — очень хочется уволиться.
Ну, это как если у вас каждая ветка минорного релиза в репозитории живёт не 2 недели, а 2 года.
Ну и у нас другой вариант, кастомеры очень долго сидят и никуда не валят особо. В основном есть кастомеры, которые грозятся свалить если мы что-нибудь не выпустим в НОВОЙ версии.
Разброс кастомеров большой правда, есть такие, кто платит что-то в районе 10к$, а есть близкие к 10mln$, а продукт один.
Я понимаю опасения разработчиков, но, общаясь с пользователями, я понимаю, что большинству из них не нужна идеальная архитектура. Они никогда не увидят идеальный код. Они готовы (на первых этапах, конечно) терпеть баги, если получат решение своей проблемы.
Судя по всему, вы не понимаете. Вот вы готовы после того, как MVP прошел проверку выкинуть его полностью и написать заново? Судя по тому, как ведут себя ваши разработчики, таки нет, а разрабатывать MVP, который писался на коленке очень больно.
Опять же, пользователям нужна нормальная архитектура, потому что она приносит такие вещи, как:
- Более быстрое внедрение изменений.
- Меньшее количество багов при регрессии.
- Меньше странный багов, которые никто не понимает
И так далее. Фраза "пользователям не нужна идеальная архитектура, потому что они никогда ее не увидят" похожа на "гражданам нашей страны не нужен уголь, потому что напрямую они его не потребляют", хотя скорее всего у той страны большая часть электричества производится при помощи угля.
Большинство разработчиков очень не любят писать MVP, потому что в итоге его все равно не выкидывают, а он обрастает функционалом все больше и больше, времени на рефакторинг так же не выделяют и получается монстр, которого надо саппортить и страдать.
Вы верно замечаете, что момент когда начинается разработка MVP может стать моментом, в который начинает накапливаться технический долг.
Перед публикацией, я скидывал статью одному из наших ведущих разработчиков и он тоже указал на этот момент:
А что если после очередного mvp, у тебя не будет времени на осмысление написанного тобою за этот период кода? и дальше тебя ждет очередное mvp? что станет с этим кодом?
И все же.
Фраза «пользователям не нужна идеальная архитектура, потому что они никогда ее не увидят» похожа на «гражданам нашей страны не нужен уголь, потому что напрямую они его не потребляют»
Я склоняюсь к тому, что до тех пор, пока архитектура не мешает причинению пользы клиентам и развитию бизнеса, её можно приносить в жертву (это trade-off — компромисс). В тот момент, когда это начинает мешать развитию — этим стоит серьезно заняться.
И классно, когда разработчик понимает (будучи погруженным в контекст), что здесь и здесь в перспективе может быть развитие архитектуры в такие то модули, а здесь может быть вот так. И закладывает это в фундамент, тратя на это минимум времени.
Я склоняюсь к тому, что до тех пор, пока архитектура не мешает причинению пользы клиентам и развитию бизнеса, её можно приносить в жертву (это trade-off — компромисс). В тот момент, когда это начинает мешать развитию — этим стоит серьезно заняться.
Проблема в том, что стоимость этого растет экспоненциально, а архитектурой нельзя заняться потом. Обычно, когда уже есть напиленный кусок продукта, который каждый разработчик пилил как видел, то свести это все в цельную архитектуру можно только выкинув и написав заново. И потом, обычно, если у вас есть хоть один опытный разработчик, вам будет выгоднее попросить его проработать верхнеуровневую архитектуру, что бы технический долг не погреб под собой разработчиков.
Просто чем дальше, тем больше времени вам нужно на то, что бы разгрести технический долг и обычно менеджеры замечают его только тогда, когда количество багов резко начинает расти, а время внедрения новых фич катастрофически увеличивается. И в это время пытаться думать над архитектурой написанного приложения уже поздно, его можно только выкинуть и написать с нуля. Пойдет ли на это бизнес? Вопрос почти риторический.
И классно, когда разработчик понимает (будучи погруженным в контекст), что здесь и здесь в перспективе может быть развитие архитектуры в такие то модули, а здесь может быть вот так. И закладывает это в фундамент, тратя на это минимум времени.
Давайте будем честны, я сомневаюсь, что даже команда из довольно опытных (скажем, 10+ лет) людей всегда будет способна писать приложение выдержанное в одной архитектуре. А что говорить про другие случаи, когда в команде значительное количество менее опытных разработчиков?
Перекладывать всю ответственность на разработчиков это крутая идея, но проблема в том, что если они не могут с этим справится и вы об этом знаете (а если не знаете, это еще хуже), то вам стоит брать это во внимание, если вы менеджер.
Ну и да, я не настолько опытных разработчик, но сделать качественную архитектуру за минуты — это очень близко к невозможному. Архитектура это не только какие-то дополнительные возможности в модуле, это еще подходы как эти модули будут взаимодействовать и виденье цельного механизма работы продукта, что разработчикам крайне сложно сделать, так как они занимаются частями продукта более детально. Даже если у вас будут бесконечно крутые разработчики, в таком подходе у вас будет куча отдельных крутых шестеренок, которые будут слеплены толстыми слоями клея, потому что интегрируются плохо.
В целом, для архитектуры отлично подходит аналогия с домом. Если каждый строитель будет под свой кусок здания класть немного фундамента, в глобальном смысле оно все равно не сильно поможет дому не просесть вниз.
У меня вопрос, Вы сами видите способы разрешения такой проблемы?
Т.е. когда и ждать нельзя, надо приколачивать, проверять, убирать. А с другой стороны — изба вот-вот рассыпется в бирюльки (ну или Микадо, кто во что играл) и трогать просто страшно?
Я, кроме варианта чередования этапов развития (MVP) и стабилизации (refactoring), ничего придумать не смог. Только очень важно ориентироваться не по уровню на плотине — все равно прозеваешь, развернуться и добежать до винтиля — всегда превращается в кошмарную пантомиму замедленного действия. А договориться, что не реже, например, чем раз в два месяца, как в вытесняющей эмуляции многозадачности. И при этом — если текущий этап (независимо от вида) можно сократить — всем торт.
Проблема в том, что все решение знают (вы его описали), но очень часто менеджеры поддаются искушению и откладывают рефакторинг "на потом". Но, только, скорее всего не по времени, а по тому, насколько много нового функционала появляется, который уже не входить в MVP и надо делать стабилизацию.
Но обычно, менеджеры и заказчики вообще не понимают, что MVP должен быть выкинут после проверки гипотезы и переписан, если она подтвердилась. Они начинают набрасывать функционал и получается то, что описали выше.
Вытесняющая многозадачность в противовес кооперативной — это моя главная мысль. Есть нюансы, конечно. Если интересно — могу развернуть большим комментарием.
Непонимание того, что MVP нужно выбрасывать говорит о том, что в системе приоритет у менеджера фич (адвокат пользователя), а не у менеджера кода (программиста, да программист — тоже менеджер). Если у любого из менеджеров приоритет солиднее — все, кооператив начинает страдать.
Вообще — огромная тема. Но попытки всех равных, на самом деле, менеджеров (кода или отношений) сваливать вину друг на друга — всегда приводят к сливу, а иногда и острой необходимости дизенфекции.
Ну так это от менеджера зависит. Поверьте не все менеджеры тупые и безответственные
Уголь потребляют напрямую и еще как. Выезжайте из крупных городов почаще. Я вижу, что в комментах пошла извечная борьба между разработкой и бизнесом. Как продуктолог, скажу, что в большей степени солидарен с автором и не потому, что она коллега. Просто идеально вылизанный код или архитектура — они может быть действительно никому не нужен, т.к. на низ требуется время, а рынок ждать не будет
Как написао автор — тут надо чувствовать и соблюдать баланс. И — да, не боятся, если нужно выкинуть MVP на помойку. Вопрос в цели создания MVP и то, какую информацию из него можно булет почерпнуть. И, обычно, MVP с грамотным продуктологом во главе, окупаются и их можно использовать для дальнейшего развития.
Уголь потребляют напрямую и еще как.
Ну так и пользователи иногда потребляют архитектуру, те же программисты, например, я.
Просто самая большая проблема MVP в том, что программисты рассчитывают на то, что он выкидывается сразу после проверки гипотезы, а бизнес не желает позволить себе задержку в развитии продукта, что бы заложить хороший фундамент под нормальное приложение. И получается то, что никто не любит.
Ну так это от менеджера зависит. Поверьте не все менеджеры тупые и безответственные
Дело даже не в том, тупой менеджер или нет. Я так понимаю, довольно часто бывает, что это больше решение бизнеса, которому менеджер не смог вовремя объяснить что и как или же, они по каким-то причинам упустили это из виду. Не то, что бы это была простая и тривиальная задача, менеджер иногда может просто не справится с этим.
Незрелые какие-то разработчики…
Админы хотят, что бы разработчики думали о таких страшных штуках, как observability.
Тестировщики хотят, что бы разработчики думали о том, как будет удобно тестировать приложение.
Менеджеры хотят, что бы разработчики еще занимались самоогранизацией.
Продукт овнеры хотят, что бы разработчики еще имели продуктовое мышление.
CTO хочет, что бы разработчики разбирались в последних технологиях.
Архитектор хочет, что бы разработчики были сознательные и сами думали про архитектуру.
А что делать разработчикам?
Так же, как и я, менеджер, могу вообще о коде не думать, не понимать, что такое API, и как там внутри все взаимодействует. Могу не разбираться в железках, а каждый раз дёргать админа, когда мне задают вопрос по оборудованию.
Менеджер проекта может не читать документацию, которую нам прислали партнеры для интеграции, а просто скинуть ее в задачу (Нам часто присылают неполную документацию или вообще не то. Мы стараемся сами ее просматривать и просим уточнения, чтобы лишний раз разработчиков не отвлекать).
Да много чего можем не делать, что не входит в круг наших прямых обязанностей. В тоже время я понимаю, что иногда мне проще пожертвовать своим временем, чем просить это сделать разработчика.
В этом смысл командной работы — помощь друг другу, коммуникации.
Ну и еще момент — продуктовое мышление не требует дополнительных затрат времени. Когда ты открываешь задачу, ты не просто как робот ее выполняешь, а сначала задаешь вопросы — себе и менеджеру, если нужно. В большинстве случаев этого достаточно.
Ну и еще момент — продуктовое мышление не требует дополнительных затрат времени. Когда ты открываешь задачу, ты не просто как робот ее выполняешь, а сначала задаешь вопросы — себе и менеджеру, если нужно. В большинстве случаев этого достаточно.
У вас прямо тут скрыто противоречие. Перед тем, как делать задачу, мне нужно отвлечься от погружения в код и технический реализации и подумать про то, как это должно быть для конечного кастомера, и, очень вероятно, задать кучу вопросов менеджеру, потому что у него банально знаний о кастомерах довольно мало. И в зависимости от задачи это может занимать довольно много времени, особенно если задача была плохо проработана сверху (а такое тоже бывает).
Продуктовое мышление требует затрат по времени, особенно от программистов, так как очень часто из-за процессов и экономии по времени они не посвящены даже в концепции продукта. Так же как и другие факторы, о которых нужно думать, observability, тестирование и прочее. Ну и менеджеры не готовы выделять на это время, потому что как и вы считают, что "это не требует затрат по времени", хотя на самом деле это далеко не так.
Мое мнение в том, что очень часто менеджеры при том, что желают получить более инициативную команду с прокачанными скилами не готовы ни платить выше рынка, что бы привлекать профессионалов, ни выделать дополнительное время, что бы у разработчиков была возможность посмотреть выше головы, ни становится жестким буферов между ними и заказчиком, когда тот давит со сроками.
Ну и опять же таки, продуктовое мышление, как мне кажется, что вы его понимаете, очень сложно будет даваться разработчикам, например, часто можно оценивать фичу, которые запрашивают в том числе и с точки зрения того, как эта фича повлияет на саму программу, и скажем, иногда в угоду логике программы просить даже ее немного изменить. В противовес этому, мне кажется, большинство продакт менеджеров к такому не готовы.
Немного тупняка.
У вас прямо тут скрыто противоречие. Перед тем, как делать задачу, мне нужно отвлечься от погружения в код и технический реализации и подумать про то, как это должно быть для конечного кастомера, и, очень вероятно, задать кучу вопросов менеджеру, потому что у него банально знаний о кастомерах довольно мало. И в зависимости от задачи это может занимать довольно много времени, особенно если задача была плохо проработана сверху (а такое тоже бывает).
Я имел ввиду как-то так:
У вас прямо тут скрыто противоречие. Перед тем, как делать задачу, мне нужно отвлечься от погружения в код и технический реализации и подумать про то, как это должно быть для конечного кастомера, и, очень вероятно, задать кучу вопросов менеджеру, потому что у меня банально знаний о кастомерах довольно мало. И в зависимости от задачи это может занимать довольно много времени, особенно если задача была плохо проработана с точки зрения бизнеса. (а такое тоже бывает).
У вас прямо тут скрыто противоречие. Перед тем, как делать задачу, мне нужно отвлечься от погружения в код и технический реализации и подумать про то, как это должно быть для конечного кастомера, и, очень вероятно, задать кучу вопросов менеджеру, потому что у него банально знаний о кастомерах довольно мало.
Не вижу противоречий. Когда вы садитесь делать задачу (я говорю о продуктово задаче, а не о технической, где четко прописано, в какой функции что нужно изменить), вы должны сначала понять, что именно должны запрограммировать.
Бэкенд и фронтенд садятся и пишут спеку на основе прототипа от дизайнера, например. Они уже трогают функционал. Нужно просто сделать маленький шажок и посмотреть на это не с точки зрения: «Мне нужно, чтобы мой код вот так делал», а с точки зрения: «Хотел бы я этим пользоваться? Удобно ли бы мне было?»
Продуктовое мышление требует затрат по времени, особенно от программистов, так как очень часто из-за процессов и экономии по времени они не посвящены даже в концепции продукта.
Так разработчики как раз и должны быть посвящены в концепцию продукта. Задача менеджера продукта, в том числе, объяснять команде, кто и как использует продукт, зачем мы вообще его делаем.
И если разработчики этого не знают (хотя хотели бы), то это уже ошибка менеджера.
Бэкенд и фронтенд садятся и пишут спеку на основе прототипа от дизайнера, например. Они уже трогают функционал. Нужно просто сделать маленький шажок и посмотреть на это не с точки зрения: «Мне нужно, чтобы мой код вот так делал», а с точки зрения: «Хотел бы я этим пользоваться? Удобно ли бы мне было?»
И вот тут вы не правы. Им нужно не просто подумать "мне нужно, что бы мой код делал X", а "Как мне написать так, что бы мой код делал X", что далеко не всегда тривиальная задача, иначе бы им не платити так много. И вы их просите подумать еще дополнительно о том "Хотел бы я этим пользоваться? Удобно ли бы мне было?". Это дополнительная работа, которая требует время. Тут еще стоит заметить, что у некоторых разработчиков (например, у меня), немного другие подходы к оценке удобства инструментов, чем у пользователей. Например, я считаю довольно важным существование API для этого инструмента. Важно ли это пользователю? Сложный вопрос.
И вот тут вы не правы. Им нужно не просто подумать «мне нужно, что бы мой код делал X», а «Как мне написать так, что бы мой код делал X», что далеко не всегда тривиальная задача, иначе бы им не платити так много. И вы их просите подумать еще дополнительно о том «Хотел бы я этим пользоваться? Удобно ли бы мне было?». Это дополнительная работа, которая требует время.
Любой навык можно тренировать. В первый раз вы потратите на это 2 дополнительных часа. Во второй — 1,5. В третий — час. И т.д. Со временем вы привыкнете к продукту и к такому мышлению, и это будет происходить очень быстро. И если мне разработчик скажет, что он потратит 2 часа, чтобы понять функционал продукта, я с радостью включу эти 2 часа в план разработки.
Потому что это принесет много дополнительных бонусов. Как минимум, вы начнете отлично разбираться в функционале и будете видеть всю картину целиком.
Тут еще стоит заметить, что у некоторых разработчиков (например, у меня), немного другие подходы к оценке удобства инструментов, чем у пользователей.
Тут согласна, есть замечательная книга на эту тему «Психбольница в руках пациентов». Никто не говорит, что вы полностью должны проводить ревью функционала, но иногда команда действительно может заметить какие-то неудобства или предложить решение, которое менеджеру просто не пришло в голову, потому что он над этой задачей сидит уже 5 дней, и у него банально взгляд замылен.
Нужно просто обращать на это внимание. И если возник вопросы, не думать: «Зачем я за менеджера буду его работу делать? Он пусть и думает. Не написано, значит не делаю.» Иногда действительно достаточно просто вопрос правильный задать
Потому что это принесет много дополнительных бонусов. Как минимум, вы начнете отлично разбираться в функционале и будете видеть всю картину целиком.
Я не знаю, как в вашей команде, но в некоторых компаниях у разработчиков не хватает времени, что бы изучать то, что делать другие с технической части, откуда у них будет время еще и на продукт?
К тому же, стоит заметить, что это не два часа и не единоразово. Вполне возможно, что первый месяц оценки задач вырастут в два раза (взял с потолка) и без учета времени, которое вам нужно будет тратить, что бы объяснять все разработчикам.
Опять же таки, стоит заметить, что:
- Вроде как большинству людей довольно сложно поддерживать две точки зрения на продукт. А значит, или продуктовая точка зрения будет хромать, или он будет писать плохой код. Лично мне довольно сложно и видеть всю картину целиком, и вдаваться в детали. Вроде получается, но все время то там, то тут могу что-то упустить. Мне кажется, не я один такой буду.
- Его понимание продукта, внезапно, может оказаться совершенно другим, не таким как у вас, а значит, за ним все равно нужно будет следить.
Вы сами код писали когда-либо, что так уверенно говорите про «просто» и «маленький шажок»?
Вероятно, вопрос еще хуже и сложнее.
"Если бы я был ЦА этого продукта, то как я бы хотел этим пользоваться? Блин, мне надо понять ЦА этого продукта… но я вроде как программист..."
Что толку если я, представитель среднего класса, буду думать об удобстве бизнеса, не ведая его проблем, бизнес-процессов, персонала, обучения и квалификации его персонала? Это выглядит далека не как "не составит труда", а скорее, как отдельная компетенция, которую надо прокачивать. Хорошо, я начну ее прокачивать, а как на это мое управление посмотрит? Вот я прокачиваюсь в понимании клиента и продажах (ведь вопрос, по сути, о том, как мне писать код, который лучше продастся), а что мне делать с тем, что, скажем, через месяц ко мне подойдет мой лид и спросит, почему я не расту как программист? Ответить, ну я клиента лучше понимать стал? Ну стал, а продукт нам на что?
«Моя мечта, как и любого менеджера продукта — команда, которая будет понимать своего пользователя и его потребности, будет валидировать задачи и думать о том, какую пользу каждая фича принесет клиенту.»
А моя мечта как разработчика, получать четкое ТЗ. В идеале чтобы в тикете была вся необходимая информация, и единственное что мне нужно сделать, это найти техническое решение поставленной задачи.
Что же я вижу на практике?
Не полное ТЗ, постоянная коммуникация с PM, аналитиком, в заказчиком прежде чем приступить к выполнению задачи.
Так а что же важно для бизнеса?
А для бизнеса не нужны ни менеджеры, ни аналитики, ни программисты. Для бизнеса важны люди, которые могут закрыть собой какую-то область проблем, взять на себя головняк и не беспокоить начальство. Нужны люди которые будут своей грудью закрывать дот, чтобы по телам этих страдальцев мог пройти бизнес.
Правильно или нет — спорный вопрос. Но то что я вижу вокруг, говорит о том что бизнес так работает. Есть только единственный ресурс который бизнес бережет и пытается заполучить — это деньги. Все остальное это инструменты заполучения этого ресурса.
Не полное ТЗ, постоянная коммуникация с PM, аналитиком, в заказчиком прежде чем приступить к выполнению задачи.
Я вас понимаю) Как и своих разработчиков, которые тоже этого хотят.
В статье я как раз попыталась приоткрыть завесу и рассказать, почему зачастую это очень сложно (а еще долго, дорого и может оказаться никому ненужным)
Я верю, что где-то есть разработчики моей мечты — зрелые, самоорганизующиеся и с продуктовым мышлением.
— тут есть обратная сторона) В одной из контор видел «зрелых» разработчиков, которые ПМа хренами крыли когда им казалось, что он предлагает то что, на их взгляд, заказчику не нужно. И, да, они стремились лично пообщаться с заказчиком)
Я понимаю опасения разработчиков, но, общаясь с пользователями, я понимаю, что большинству из них не нужна идеальная архитектура… Они готовы (на первых этапах, конечно) терпеть баги
Нужно эту фичу переделать
— непродуманная архитектура, помноженная на многократные доделки и переделки, рождает блохастое чудовище, которое проще усыпить чем вылечить. Через пару лет существования такого продукта неожиданно окажется, что добавление новой фичи или устранение простой на вид ошибки вызывает у разработчиков непропорционально большие трудозатраты. И не говорите тогда, что вас не предупреждали — все эти стоны разработчиков про необходимость рефакторинга, это вам четкий сигнал, что продукт с гнильцой.
Следствия вашего подхода к разработке:
— низкая мотивация в команде (это уже заметно в статье) и недовольство менеджмента в отношении команды, с последующей текучкой кадров;
— бесконечный поток ошибок в продукте, в стиле эту лапу вытащили, другая увязла. Да еще и ошибки устранять будете медленно. За это получите справедливое недовольство клиента, который наивно предполагал что покупает качественный продукт.
Также хорошо видно, что автор не понимает термин MVP. Минимально работоспособный продукт, это продукт с минимальной функциональностью, а не интерфейс пришитый белыми нитками к коленке. Хорошая картинка про это:
Ну а это вообще супер:
Я не объясняю, какую проблему решает их фича, а просто набрасываю задачи в бэклог, надеясь, что команда сама придет ко мне с вопросами
— постыдились бы такое писать! Ваша задача мотивировать команду, а не демотивировать ее. Уверен, что разработчики видя задачи в бэклоге комментируют это так: «опять какая то мутная и непонятно кому нужная хрень, которую потом придется переделывать».
В общем, хорошего менеджера, умеющего работать не только с заказчиком, но и с исполнителями, также трудно найти как и хорошего разработчика.
В общем, хорошего менеджера, умеющего работать не только с заказчиком, но и с исполнителями, также трудно найти как и хорошего разработчика.
И это абсолютная истина.
В тексте как раз речь о том, что и за менеджерами бывают такие грехи. Стыдиться этого или нет — это выбор личный. На мой взгляд открыто говорить о проблеме — это один из шагов на пути к её решению.
— непродуманная архитектура, помноженная на многократные доделки и переделки, рождает блохастое чудовище, которое проще усыпить чем вылечить. Через пару лет существования такого продукта неожиданно окажется, что добавление новой фичи или устранение простой на вид ошибки вызывает у разработчиков непропорционально большие трудозатраты. И не говорите тогда, что вас не предупреждали — все эти стоны разработчиков про необходимость рефакторинга, это вам четкий сигнал, что продукт с гнильцой.
Это один из рисков быстрой разработки.
На другой чаше весов — мы будем продумывать архитектуру, писать ТЗ, долго и качественно все реализовывать, а потом, например, выйдет закон, который скажет, что так больше делать нельзя (а такое часто бывает с b2b продуктами). И мы получим много потраченных денег и ненужный продукт, но зато с классной архитектурой.
Вопрос лишь в том, что вы считаете большим риском.
низкая мотивация в команде
Надеюсь, что нет. Я как раз очень стараюсь донести, что гордиться надо не идеальным кодом, а тем, что твой продукт приносит пользу людям
Также хорошо видно, что автор не понимает термин MVP
Автор понимает, что такое MVP, а эта картинка стоит у нее в качестве заставки на рабочем столе.
Если посмотреть на эту картинку, то видно, что на первом этапе MVP, например, не имеет двигателя. Я прихожу к разработчику и говорю: «Давай сделаем железную коробку на колесах, чтобы ее можно было вручную толкать». Разработчик делает. Потом я прихожу и говорю: «Давай двигатель добавим», а в ответ слышу: «Мы это в архитектуру не закладывали», так что пусть и дальше руками толкают.
постыдились бы такое писать!
Я как раз и писала это в негативном свете, что я ловлю себя на мысли, что так делаю, хотя это неверно. Я тоже неидеальна. И иногда замечаю, что не объяснила что-то разработчикам, потому что для меня это очевидно, а для них — нет. Когнитивные искажения никто не отменял.
Это один из рисков быстрой разработки.
Это не риск быстрой разработки. Это практически гарантированный результат, которого можно избежать только при помощи очень крутой командой, которой может похвастаться очень мало компаний.
Опять же таки, никто не просит вылизывать архитектуру до идеального варианта, но хотелось бы хоть неплохую. А часто даже такого не дают.
А у архитектуры хотя бы есть какие-то шансы)
Думаете доволен разработчик, что сделал классный код? Неа. Потому что его труд остался лежать ровно также незаметно, как если бы он его удалил.
А вот я бы с радостью «закопал» в проект чуть меньше денег и а остальные деньги пустил бы в другой проект, глядишь бы второй выстрелил.
Я прихожу к разработчику и говорю: «Давай сделаем железную коробку на колесах, чтобы ее можно было вручную толкать». Разработчик делает. Потом я прихожу и говорю: «Давай двигатель добавим», а в ответ слышу: «Мы это в архитектуру не закладывали», так что пусть и дальше руками толкают.
Решение напрашивается само собою: Вместе с задачей на железную коробку можно обсудить перспективы: «Слушай, а если тележка понравится, сможем мы приделать ей колеса?»
Если, конечно, есть понимание возможных сценариев развития.
Ну и сценарии не всегда понятны, когда ты первопроходец.
эта картинка стоит у нее в качестве заставки на рабочем столе.
Если посмотреть на эту картинку, то видно, что на первом этапе MVP, например, не имеет двигателя. Я прихожу к разработчику и говорю: «Давай сделаем железную коробку на колесах, чтобы ее можно было вручную толкать». Разработчик делает. Потом я прихожу и говорю: «Давай двигатель добавим», а в ответ слышу: «Мы это в архитектуру не закладывали»
— кто то неправильно понимает картинку. Я вижу, что изначально проектируется приложение на которое можно установить двигатель, но пока его нет — толкаем руками, типа приложение принципиально может масштабироваться, но сдаем мы его на одной ноде. Видимо не донесли до разработчика/архитектора граничные условия и он понял что всегда будут руками толкать, либо он все понял, но на вас болт положил и саботирует, ссылаясь на то что изначально про двигатель ничего не говорилось (а сказать надо было).
На всякий случай та же картинка еще раз:
Это один из рисков быстрой разработки.
На другой чаше весов — мы будем продумывать архитектуру, писать ТЗ, долго и качественно все реализовывать, а потом, например, выйдет закон, который скажет, что так больше делать нельзя (а такое часто бывает с b2b продуктами). И мы получим много потраченных денег и ненужный продукт, но зато с классной архитектурой.
— не надо называть продуктом то что им не является, вы делаете не продукт, а прототип, да и то усеченный (в прототип, архитектура тоже обычно закладывается). Вместо того чтобы расписывать в ТЗ неизвестно что, надо сообщить разработчику граничные условия, что он должен сделать — самокат или автомобиль и, если автомобиль, то грузовой или легковой. Детали про окраску, фары и отделку салона на ранних этапах не нужны. Как раз архитектура, часто описывается даже не в виде кода, а в виде блоксхем и если и требует заметных трудозатрат, то на отработку не проверенных гипотез — типа, а сможем мы лить в базу XX по YYY запросов в сек. Ну и насчет законов влияющих на архитектуру… такая мизулина еще не родилась или вы называете архитектурой не то что я.
Программист — это программист. Он совсем не менеджер и то что нужно клиенту — он не знает. Вы еще предложите всем программистам и участником команды поговорить с клиентом… Вы должны вникать и переводить на два языка — «для клиентов» и «для работников».
От менеджера приходит заказ на товар, и если он не верно понял клиента — винить команду не стоит, что нужно переделывать. Используйте в работе прототипы, что ли… Это проблема называется «Нет хороших работников»! Извиняюсь, сама руководитель.
- У разработки результат выполнения известен и валидируется однозначно;
- У product-owner'ов результат выполнения НЕ известен и валидируется рынком по-разному.
И надо помнить, что работа «в стол» демотивирует ЛЮБОГО. А чтобы снизить этот эффект, надо задать разработке один вопрос: «Парни, я за пиццей, какую возьмем сегодня?» И за совместным поеданием наладить отношения и обсудить «эксперименты Эдисона».
p.s. Опытные менеджеры, кстати, в бюджет проекта закладывают «представительские расходы» на такие угощения пиццей ;-)
признавать что вы не в состоянии составить ТЗ и продумать на пару шагов архитектуру и возможные подводные камни — на мой взгляд как расписываться в том что вы не шарите в предметной области
сидишь потом без ТЗ и мутным заданием и сам за продакта додумываешь как это дело реализовывать
Как говорил Эйнштейн, правильно сформулированный вопрос содержит ответ. Проблема в том, чтобы этот вопрос (market fit) найти и сформулировать. В этом первая задача продакта.
Вторая описываемая в статье проблема в том, что зачастую команда разработки живет в своем мире, где все задачи гарантированно правильные и в самой задаче не содержится «багов». При том, что «баги» в результатах выполнения задач считаются нормой и наличие тестировщиков тоже считается нормой.
И случай, когда в принципе есть неопределенность, и сегодня ты решения принимаешь в одних условиях. А завтра ты быстро переобуваешься, потому что условия изменились.
Мои разработчики
Их главная задача
я описываю гипотезы и для их проверки мне нужно, чтобы команда
Такое создается впечатление, что Вы сами противоставляете себя команде. Я и команда. Я и они. Я хорошая, а они такие непонятливые (мягко говоря).
Или же у Вас лично проблемы с коммуникацией с командой, что Вы не можете свои идеи правильно донести. Или же у Вас идеи слабоваты и в результате потом 90% приходится переделывать. Не знаю, диагноз по интернет поставить невозможно.
Сам работал и сделал несколько продуктов с разными командами, но таких проблем никогда не возникало. Приходилось некоторые функции доделывать или делать иначе, но чтобы все в стол — такого никогда не было. Может быть поэтому команде с Вами и работать тяжело, что бОльшая часть кода потом выбрасывается. По-человечески все без исключения хотят гордиться результатами своего труда, а не работать вхолостую.
И про мотивацию, и про архитектуру, и про кто кому чего должен, и про хорошее тз ;)
Исповедь менеджера продукта