Я работаю в продуктовой компании. Что это значит?
Мы не разрабатываем проекты на заказ, мы делаем продукт, который продаем клиентам.
Для своих команд я формирую видение продукта, принимаю решение, какие из “хотелок” пользователей мы будем делать и объясняю команде (иногда на уточках), зачем они нужны. Описываю задачи с точки зрения ценности для бизнеса, формулирую и проверяю гипотезы.
Мои требования к разработке зачастую сформулированы нечетко, фичи часто приходится переделывать или дорабатывать после запуска.
Этим я мешаю разработчикам писать идеальный код. Я знаю, что так поступают многие менеджеры продукта.
И я хочу рассказать, зачем я делаю это снова и снова.
Продукт должен решать боль
У менеджера продукта есть видение того, что необходимо создать компании, чтобы не потратить зря время и силы дорогих (во всех смыслах!) разработчиков.
Это не значит, что мы делаем только то, что нам нравится, а потом пытаемся “впарить” это конечному пользователю. Задача любого продукта — решить проблему, а не создать новые.
Продуктовая команда
Раньше у нас были функциональные команды, которые делают только свою часть фичи (например, пишут фронтенд). Нас не устраивала скорость разработки, нарушение коммуникации, процесс передачи задач между командами и отслеживание их статусов.
Мы перешли к продуктовым командам, которые отвечают за продукт в целом и могут сделать любой функционал самостоятельно.
Наша продуктовая команда включает в себя менеджеров продукта и проекта, несколько бэкенд и фронтенд разработчиков, тестировщика.
Каждый член команды выполняет свою роль. Менеджер продукта проводит исследования, формирует бэклог и расставляет приоритеты. Разработчики пишут код. Тестировщик следит за качеством. Менеджер проекта детализирует требования, организует взаимодействие между командами и помогает устранить препятствия, например, найти оборудование для тестов, маркеры и доску, забронировать переговорку, организовать митинги и т.д.
Моя мечта, как и любого менеджера продукта — команда, которая будет понимать своего пользователя и его потребности, будет валидировать задачи и думать о том, какую пользу каждая фича принесет клиенту.
Но мечты исполняются очень нечасто. Мои разработчики редко думают о тех, для кого и зачем они пишут свой код. Их главная задача — построить идеальную архитектуру, использовать самые топовые инструменты, попробовать новые технологии.
И это противоречие становится самой частой причиной споров между мной и разработчиком.
MVP VS Идеальная архитектура
Мы работаем в сфере, которая меняется очень быстро. Количество абстракций постоянно увеличивается. Новые продукты появляются и умирают. Пользователи не хотят учиться работе с нашим ПО, они хотят приложить минимум усилий и решить свою проблему. При этом мы часто забываем, что пользователь не знает, как он хочет эту проблему решить. Он просто хочет, чтобы ее не было.
А бывает еще сложнее — пользователь может не знать, что у него есть проблема. Он жил так много лет, боролся с трудностями и считает это нормой. И если я спрашиваю: “А какая у тебя проблема?”, часто в ответ слышу: “Никакой, у меня все хорошо”.
Задача продуктовой команды — понять боль клиента, дать ему наилучшее решение и рассказать, как волшебна станет его жизнь с нашим инструментом.
Мы поняли, что без customer development почти невозможно создать ПО, которое с радостью будут покупать. Моя задача, как менеджера продуктов, искать целевую аудиторию, проводить интервью, выявлять потребности, описывать персонажей и их боли. Но даже это не всегда гарантирует успех. Я тоже человек и тоже могу ошибаться.
Чтобы ошибаться меньше, я описываю гипотезы и для их проверки мне нужно, чтобы команда создавала MVP — минимально жизнеспособный продукт. Чтобы добиться успеха, мне хочется постоянно экспериментировать, как это делает большинство продуктовых компаний. Ведь чем больше гипотез проверю, и чем быстрее это сделаю, тем больше шанс, что компания выпустит именно тот продукт, который оценит пользователь.
Но часто, когда я прихожу к команде и говорю, что нам нужно сделать функционал “на коленке” и запустить его в работу через неделю, в ответ я слышу, что это невозможно. Нужно продумать архитектуру! Нужно учесть все сценарии! Нужно полное ТЗ с описанием всего функционала! А что будет, если один из 1000 пользователей сделает не то, что мы ждали, и у него все сломается?! Нельзя написать и провести ревью кода в такие сжатые сроки!
Я понимаю опасения разработчиков, но, общаясь с пользователями, я понимаю, что большинству из них не нужна идеальная архитектура. Они никогда не увидят идеальный код. Они готовы (на первых этапах, конечно) терпеть баги, если получат решение своей проблемы.
Работа в стол
И вот, мы все-таки запилили функционал, который не нужен пользователю.
Хорошо, если мы потратили на это мало времени и с ним не жалко расставаться. Но если разработчик душу в него вложил? Ночами не спал, рисовал идеальные кнопки с “продающим зелёным”? Учел и обработал все сценарии? Сделал гибкую архитектуру, которую можно безболезненно покрыть тестами? Написал статью и всем коллегам рассказал о том, как круто он применил новейшие технологии?
А потом прихожу я и говорю фразу, которую ненавидят все программисты: “Нужно эту фичу переделать”. И случается в ответ услышать то, что ненавидят все менеджеры: “Я старался, все по ТЗ делал, а вы с пользователями не оценили. Ничего переделывать не буду”.
Так начинается самый частый конфликт разработчика и менеджера продукта. И каждый думает, что он прав. Ведь моя задача как менеджера — проверить как можно больше гипотез, а задача разработчика — написать красивый код, которым он будет гордиться.
Когда я слышу от разработчика фразу “Ну вот, опять в стол поработали”, я снова и снова пытаюсь объяснить, что это не так, его работа принесла компании выгоду — мы проверили гипотезу, не потратили на нее много денег, и поняли, что рынку нужно не это. Мы сделали шаг вперед. Разработчик помог не сделать ошибку.
Продуктовое мышление
Я и раньше постоянно общалась с конечными пользователями, видела их проблемы. Но вот беда — я не задумывалась о том, чтобы рассказать о своих исследованиях команде. А ведь задача ребят — как можно скорее сделать то, что решит боль клиента.
А потом я подумала: “Как может разработчик думать о человеке, которого ни разу не видел и с которым не говорил?”
Он сделал всё, чтобы любой пользователь мог использовать его ПО максимально гибко — сделал максимум разных настроек на все случаи жизни, добавил много кнопочек, каждая из которых делает свое действие — их только нажимать нужно в нужный момент, написал подробный мануал на 25 страниц. И он даже подумать не мог, что кто-то может не хотеть потратить несколько часов на изучение всего этого. Он то любит разбираться со сложными проектами!
Он никогда не видел, кто и в каких условиях использует его продукт. В его мире все очевидно — клиент должен разобраться во всех настройках сам. А клиент почему-то злится.
И никто не рассказал разработчику, что его программу использует девочка-кассир, которая только пришла на работу. Перед ней стоит очередь из 20 человек, а ей нужно каждый раз для достижения результата нажать 10 кнопок в правильной последовательности. И вот, она уже плачет от бессилия, потому что люди в очереди начинают кричать, а она сбилась несколько раз.
Я знаю об этом и понимаю, что функционал нужно доработать — убрать ненужные настройки, сократить количество действий, добавить новые сценарии, которые не предусмотрели раньше. Но разработчик противится. Он не хочет несколько раз переделывать одно и то же, вставляя новые “костыли”. “Почему сразу нельзя было это сделать?” — слышу я от него.
Потому что в сложных продуктах никогда не знаешь, будет ли новый функционал востребован. Клиент может говорить, что он жить не может без этой фичи, а потом не пользуется ей, потому что проще (или дешевле) делать все по-старинке.
Потому что о сложных кейсах использования клиент мне не рассказал на интервью (или я не смогла вытянуть).
Потому что забыли “повесить” аналитику.
Потому что менеджер тоже может ошибаться.
Поэтому я стараюсь наладить коммуникации в команде. Потому стараюсь научить всех членов команды думать в первую очередь о продукте и как клиент его использует.
Вы можете обвинить меня в перекладывании ответственности, но у меня, как и у большинства людей, бывают когнитивные искажения, замыливается взгляд. Я могу не видеть очевидного решения, потому что слишком долго думаю над решением этой проблемы. Могу что-то упустить в цепочке рассуждений. Могу просто отбросить хорошую идею, потому что считаю её технически нереализуемой или очень сложной, а оказывается, что работы там на 2 часа.
И очень часто нужен кто-то, кто задаст правильный вопрос, посмотрит свежим взглядом, предложит нестандартное решение.
И я постоянно задаюсь вопросом, почему разработчики так редко спрашивают меня, зачем и для кого мы делаем фичу? Почему не пытаются поставить себя на место клиента? Почему не всегда рассказывают мне о техническом долге, а просто тихо делают рефакторинг вместо продуктовых задач?
И так же часто я ловлю себя на мысли, что не всегда делюсь с командой как клиент использует их продукт. Забываю сказать разработчику, что он сейчас “пилит” не полноценный функционал, а только MVP, который может и не взлететь. Я не объясняю, какую проблему решает их фича, а просто набрасываю задачи в бэклог, надеясь, что команда сама придет ко мне с вопросами.
Мечты сбываются
Мне все еще стыдно за задачи на переработку какой-то фичи или просьбы выпилить функционал. Я все еще испытываю чувство обиды, когда разработчики указывают на непроработанную задачу. И я радуюсь каждый раз, когда команда предлагает свои решения поставленной задачи, спорит со мной и задает вопросы о том, как пользуются их инструментом.
Я верю, что если каждый в команде будет думать о продукте и как его используют, мы вместе сможем решить проблемы наших клиентов, заработать много денег (какой бизнес этого не хочет?) и сделать жизнь людей чуточку лучше. Если каждая команда сделает то же самое, потратит свои силы на решение чьих-то проблем, мы будем жить в фантастическом мире, который существует пока только в книгах.
И я упорно продолжаю проверять гипотезы, просить запилить что-то по-быстрому, учусь “продавать” команде задачи и передавать обратную связь от пользователя. И жду, что они перестанут ненавидеть меня за то, что я мешаю им писать идеальный код.
P.S.: Автор статьи Stratanovich, у нее пока readonly, а нам очень хотелось опубликоваться.
Комментарии (74)
Tomato404
26.02.2018 11:48Я понимаю, какой цели вы хотели достичь этой публикацией: вовлечь разработчиков в более тесную работу с продактом. И цель благая, только мне показалось что разработчики в вашей статье, мягко говоря предстали не в лучшем свете.
Меня бы такая статья демотивировала от работы в вашей команде.
Wert1go Автор
26.02.2018 11:49Давайте разбираться. Чем демотивировала бы?
Tomato404
26.02.2018 14:09На самом деле, мне показалось, что говоря «Моя мечта [...] команда, которая будет понимать своего пользователя...», вы как бы говорите: «моя команда – не огонь». Что, мне бы, будь я разработчиком, сразу захотелось бы уволиться, ведь зачем работать в команде которая «так себе», по мнению руководства.
Было и несколько других моментов, например про то «идеальную архитектуру». Здесь рождается конфликт, и я понимаю вас, как продакт менеджера, выпустить продукт приносящий прибыль компании и реализующий крутые фичи для пользователей, но я вполне могу понять и разработчика/техлида, который не хочет, чтоб к нему через месяц/два/полгода прибегали вы или ваши коллеги и жаловались, что «приложение что-то долго загружается». Конфликт это не плохо, а в случае выпуска продукта, даже хорошо. Но в статье видно только «боль» продакт менеджера задачи которого яростно режутся плохими, исходя из контекста, разработчиками, которые постоянно делают рефакторинг.
Stratanovich
26.02.2018 14:58Моя команда не идеальна, и я не вижу ничего страшного в том, чтобы об этом говорить. В моей жизни вообще мало чего-то идеального. Да и себя я бы менеджером мечты не назвала.
Но это не значит, что я не стремлюсь стать лучше. И от команды я хочу того же. Замалчивая проблемы и не озвучивая ожидания, сложно получить то, чего хочешь.
Про конфликт и «идеальную архитектуру» полностью согласна. Я тоже понимаю разработчиков. И как я «продаю» свои продуктовые таски команде, я хочу, чтобы мне «продавали» технический долг. Я никогда не откажусь выделить время на рефакторинг, если мне расскажут, что это избавит нас от каких-то конкретных проблем.
Боль даже не в том, что продуктовыми тасками жертвуют ради рефакторинга, а в том, что разработчики хотят написать сразу «бетон» и больше его не переделывать. А в современной продуктовой разработке это почти невозможно (как раз и пыталась донести, почему)
SirEdvin
26.02.2018 15:10Я никогда не откажусь выделить время на рефакторинг, если мне расскажут, что это избавит нас от каких-то конкретных проблем.
Ну значит, у вас плохо работает тим лид. Или же, если ваш тимлид еще и пишет код, у вас банально некому это делать. Потому что управление техническим долгом и его оценка вроде как тоже задача менеджера и если у вас некому ее делать, очень странно ожидать от программиста, что бы он этим занимался. В свободное время от работы?)
Боль даже не в том, что продуктовыми тасками жертвуют ради рефакторинга, а в том, что разработчики хотят написать сразу «бетон» и больше его не переделывать.
Из статьи мне показалось, что разработчики хотят для начала фундамент, на котором можно строить приложение.
И опять же таки, постоянно переделывать это тоже плохо, потому что постоянные хаотичные переделывания очень плохо сказываются на качестве продукта и обычно означают, что у вас проблемы с долгосрочным планированием.
Stratanovich
26.02.2018 18:24И опять же таки, постоянно переделывать это тоже плохо, потому что постоянные хаотичные переделывания очень плохо сказываются на качестве продукта и обычно означают, что у вас проблемы с долгосрочным планированием.
Я как раз и пыталась донести мысль, что в быстроразвивающемся продуктовом мире, где постоянно нужно проверять гипотезы (чем больше, тем лучше), долгосрочное планирование — непозволительная роскошь.
У нас, конечно, есть общее стратегическое планирование, но знать заранее, какой функционал будет востребованным через 3/6/9 месяцев очень сложно. Недавний пример — 54ФЗ, фактически создавший новую отрасль.
Если мы будем так планировать каждую фичу, то будем уступать юрким стартапам. Им терять нечего, они проверяют больше гипотез, и находят те самые алмазы, за которые люди готовы платить.SirEdvin
26.02.2018 18:58И сколько проблем у этих стартапов потом? Они буквально тонут в плохом коде, им часто приходится банально выкидывать функционал из продукта, который уже никто не понимает, как работает. Более того, у них часто бывают раздражающие баги, которые не фиксятся месяцами, потому что никто не знает, как и где это происходит.
Если вы планируете быть хорошей продуктовой компанией и уже не стартап, не стоит пытаться за ними угнаться, у них как раз есть свои минусы и плюсы, так же как у большой компании. Пытаясь за ними угнаться, вы получаете те же самые проблемы, вот только в крупной компании никто не любит сидеть по 12 часов на работе и текучка в большой компании обычно гораздо больнее.Stratanovich
26.02.2018 19:04Как раз очень важно соблюдать баланс между гибкостью стартапа и налаженными процессами крупной компании. Среди продуктологов это очень актуальная тема сейчас. И у некоторых получается.
никто не любит сидеть по 12 часов на работе
Тут полностью согласна, я совершенно против овертаймовSirEdvin
26.02.2018 19:17Баланс — это важно. Но как я понял, вы слишком сильно склоняетесь к формату стартапа, что как бы означает в итоге большую не очень приятную кучу кода.
Stratanovich
26.02.2018 19:24Иногда у меня, как у продуктолога, нет выхода.
Выбор достаточно жесткий:
— или мы даем рынку хоть что-то, что закроет его боль
— или это дают конкуренты, и нас вытесняют с рынка
Все еще усугубляется тем, что мы делаем b2b решения — это значит, что клиентов у нас мало, каждый платит много (потеря даже одного клиента ощутима), они все другу друга знают. Сарафанное радио работает очень быстро.
Мы, конечно, стараемся баланс сохранять, но если мы потеряем клиентов, то любая куча кода будет бесполезна.
Tomato404
26.02.2018 18:15Похвально, что вы понимаете что не идеальны и стремитесь стать лучше. Никто из нас, само собой, не идеален. И я, ни в коем случае, не хотел сказать что конструктивная критика и обратная связь это плохо.
В то же время обратную связь нужно правильно подать. Сейчас вы описываете исключительно слабые, на ваш взгляд, стороны вашей команды. Я не услышал ни слова про то, что они профессионалы своего дела, отлично разбираются в архитектуре приложений и так далее.Stratanovich
26.02.2018 18:33Когда я писала статью, я не ставила целью дать обратную связь команде — обратную связь я даю в другом формате.
Так же моей целью не была критика разработчиков. Я хотела указать на причину одного из самых частых моих конфликтов с командой и показать, почему я уделяю столько сил и времени продуктовому мышлению, почему для меня это важно (и, возможно, важно для ваших менеджеров).
И да, что касается разработки — моя команда действительно классная. Иногда даже слишком) Они действительно могут построить архитектуру и написать классный код.
sshmakov
27.02.2018 08:37Как быстро "бетон" вошёл в обиход, однако...
Почему вы думаете, что разработчики должны вам что-то продавать? У них другая работа. Технический долг и необходимость рефакторинга присутствует постоянно, просто примите это. Доверьтесь своей команде и дайте им время для рефакторинга.
VolCh
27.02.2018 22:49+1Разработчики не сейлсы, их не учат манипулировать людьми. Некоторые учатся, но довольно быстро перестают быть разработчиками. Максимум от нас можно ожидать технико-экономического обоснования. Но никак не «продаж».
webzest
26.02.2018 12:09А можно чуть подробнее про сам продукт? Сколько «продуктовых команд» и что именно подразумевается под «продуктом» (платформа, крупная фича)? Легаси?
Stratanovich
26.02.2018 12:17Мы занимаемся автоматизацией кинобизнеса. У нас линейка b2b продуктов, которая закрывает все потребности кинотеатров от составления репертуара до отчетности по проданным билетам.
Всего у нас 6 продуктовых команд, каждая из которых занимается своим направлением.
Я — менеджер продуктов для 2-команд (одна отвечает за продажи офлайн, другая — за онлайн)
nporaMep
26.02.2018 22:50я скорее всего работаю в другой компании по автоматизации кинобизнеса, но могу рассказать о своём недовольстве со стороны разработчика:
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% работы программиста над новой модификацией превращается в походы по этажам и разговоры со старичками в поисках всех возможных сценариев и очень хочется уволиться :)
jehy
01.03.2018 16:52Вот да, хочется яростно плюсовать этот комментарий. Потому что часто оказывается, что продукт годами разрабатывается как "допилим быстро эту фичу как MVP", после чего у тебя оказывается просто свалка костылей, и любое изменение проходит через адовую боль и занимает кучу времени. И да — очень хочется уволиться.
SirEdvin
26.02.2018 12:12Я понимаю опасения разработчиков, но, общаясь с пользователями, я понимаю, что большинству из них не нужна идеальная архитектура. Они никогда не увидят идеальный код. Они готовы (на первых этапах, конечно) терпеть баги, если получат решение своей проблемы.
Судя по всему, вы не понимаете. Вот вы готовы после того, как MVP прошел проверку выкинуть его полностью и написать заново? Судя по тому, как ведут себя ваши разработчики, таки нет, а разрабатывать MVP, который писался на коленке очень больно.
Опять же, пользователям нужна нормальная архитектура, потому что она приносит такие вещи, как:
- Более быстрое внедрение изменений.
- Меньшее количество багов при регрессии.
- Меньше странный багов, которые никто не понимает
И так далее. Фраза "пользователям не нужна идеальная архитектура, потому что они никогда ее не увидят" похожа на "гражданам нашей страны не нужен уголь, потому что напрямую они его не потребляют", хотя скорее всего у той страны большая часть электричества производится при помощи угля.
Большинство разработчиков очень не любят писать MVP, потому что в итоге его все равно не выкидывают, а он обрастает функционалом все больше и больше, времени на рефакторинг так же не выделяют и получается монстр, которого надо саппортить и страдать.
Wert1go Автор
26.02.2018 12:30Спасибо за развернутый комментарий.
Вы верно замечаете, что момент когда начинается разработка MVP может стать моментом, в который начинает накапливаться технический долг.
Перед публикацией, я скидывал статью одному из наших ведущих разработчиков и он тоже указал на этот момент:
А что если после очередного mvp, у тебя не будет времени на осмысление написанного тобою за этот период кода? и дальше тебя ждет очередное mvp? что станет с этим кодом?
И все же.
Фраза «пользователям не нужна идеальная архитектура, потому что они никогда ее не увидят» похожа на «гражданам нашей страны не нужен уголь, потому что напрямую они его не потребляют»
Я склоняюсь к тому, что до тех пор, пока архитектура не мешает причинению пользы клиентам и развитию бизнеса, её можно приносить в жертву (это trade-off — компромисс). В тот момент, когда это начинает мешать развитию — этим стоит серьезно заняться.
И классно, когда разработчик понимает (будучи погруженным в контекст), что здесь и здесь в перспективе может быть развитие архитектуры в такие то модули, а здесь может быть вот так. И закладывает это в фундамент, тратя на это минимум времени.SirEdvin
26.02.2018 12:44Я склоняюсь к тому, что до тех пор, пока архитектура не мешает причинению пользы клиентам и развитию бизнеса, её можно приносить в жертву (это trade-off — компромисс). В тот момент, когда это начинает мешать развитию — этим стоит серьезно заняться.
Проблема в том, что стоимость этого растет экспоненциально, а архитектурой нельзя заняться потом. Обычно, когда уже есть напиленный кусок продукта, который каждый разработчик пилил как видел, то свести это все в цельную архитектуру можно только выкинув и написав заново. И потом, обычно, если у вас есть хоть один опытный разработчик, вам будет выгоднее попросить его проработать верхнеуровневую архитектуру, что бы технический долг не погреб под собой разработчиков.
Просто чем дальше, тем больше времени вам нужно на то, что бы разгрести технический долг и обычно менеджеры замечают его только тогда, когда количество багов резко начинает расти, а время внедрения новых фич катастрофически увеличивается. И в это время пытаться думать над архитектурой написанного приложения уже поздно, его можно только выкинуть и написать с нуля. Пойдет ли на это бизнес? Вопрос почти риторический.
И классно, когда разработчик понимает (будучи погруженным в контекст), что здесь и здесь в перспективе может быть развитие архитектуры в такие то модули, а здесь может быть вот так. И закладывает это в фундамент, тратя на это минимум времени.
Давайте будем честны, я сомневаюсь, что даже команда из довольно опытных (скажем, 10+ лет) людей всегда будет способна писать приложение выдержанное в одной архитектуре. А что говорить про другие случаи, когда в команде значительное количество менее опытных разработчиков?
Перекладывать всю ответственность на разработчиков это крутая идея, но проблема в том, что если они не могут с этим справится и вы об этом знаете (а если не знаете, это еще хуже), то вам стоит брать это во внимание, если вы менеджер.
Ну и да, я не настолько опытных разработчик, но сделать качественную архитектуру за минуты — это очень близко к невозможному. Архитектура это не только какие-то дополнительные возможности в модуле, это еще подходы как эти модули будут взаимодействовать и виденье цельного механизма работы продукта, что разработчикам крайне сложно сделать, так как они занимаются частями продукта более детально. Даже если у вас будут бесконечно крутые разработчики, в таком подходе у вас будет куча отдельных крутых шестеренок, которые будут слеплены толстыми слоями клея, потому что интегрируются плохо.
africaunite
26.02.2018 23:38У меня вопрос, Вы сами видите способы разрешения такой проблемы?
Т.е. когда и ждать нельзя, надо приколачивать, проверять, убирать. А с другой стороны — изба вот-вот рассыпется в бирюльки (ну или Микадо, кто во что играл) и трогать просто страшно?
Я, кроме варианта чередования этапов развития (MVP) и стабилизации (refactoring), ничего придумать не смог. Только очень важно ориентироваться не по уровню на плотине — все равно прозеваешь, развернуться и добежать до винтиля — всегда превращается в кошмарную пантомиму замедленного действия. А договориться, что не реже, например, чем раз в два месяца, как в вытесняющей эмуляции многозадачности. И при этом — если текущий этап (независимо от вида) можно сократить — всем торт.
SirEdvin
27.02.2018 11:12+1Проблема в том, что все решение знают (вы его описали), но очень часто менеджеры поддаются искушению и откладывают рефакторинг "на потом". Но, только, скорее всего не по времени, а по тому, насколько много нового функционала появляется, который уже не входить в MVP и надо делать стабилизацию.
Но обычно, менеджеры и заказчики вообще не понимают, что MVP должен быть выкинут после проверки гипотезы и переписан, если она подтвердилась. Они начинают набрасывать функционал и получается то, что описали выше.
africaunite
27.02.2018 12:01Вытесняющая многозадачность в противовес кооперативной — это моя главная мысль. Есть нюансы, конечно. Если интересно — могу развернуть большим комментарием.
Непонимание того, что MVP нужно выбрасывать говорит о том, что в системе приоритет у менеджера фич (адвокат пользователя), а не у менеджера кода (программиста, да программист — тоже менеджер). Если у любого из менеджеров приоритет солиднее — все, кооператив начинает страдать.
Вообще — огромная тема. Но попытки всех равных, на самом деле, менеджеров (кода или отношений) сваливать вину друг на друга — всегда приводят к сливу, а иногда и острой необходимости дизенфекции.
cheiwe
27.02.2018 12:23Ну так это от менеджера зависит. Поверьте не все менеджеры тупые и безответственные
cheiwe
27.02.2018 12:18Уголь потребляют напрямую и еще как. Выезжайте из крупных городов почаще. Я вижу, что в комментах пошла извечная борьба между разработкой и бизнесом. Как продуктолог, скажу, что в большей степени солидарен с автором и не потому, что она коллега. Просто идеально вылизанный код или архитектура — они может быть действительно никому не нужен, т.к. на низ требуется время, а рынок ждать не будет
Как написао автор — тут надо чувствовать и соблюдать баланс. И — да, не боятся, если нужно выкинуть MVP на помойку. Вопрос в цели создания MVP и то, какую информацию из него можно булет почерпнуть. И, обычно, MVP с грамотным продуктологом во главе, окупаются и их можно использовать для дальнейшего развития.SirEdvin
27.02.2018 12:27Уголь потребляют напрямую и еще как.
Ну так и пользователи иногда потребляют архитектуру, те же программисты, например, я.
Просто самая большая проблема MVP в том, что программисты рассчитывают на то, что он выкидывается сразу после проверки гипотезы, а бизнес не желает позволить себе задержку в развитии продукта, что бы заложить хороший фундамент под нормальное приложение. И получается то, что никто не любит.
Ну так это от менеджера зависит. Поверьте не все менеджеры тупые и безответственные
Дело даже не в том, тупой менеджер или нет. Я так понимаю, довольно часто бывает, что это больше решение бизнеса, которому менеджер не смог вовремя объяснить что и как или же, они по каким-то причинам упустили это из виду. Не то, что бы это была простая и тривиальная задача, менеджер иногда может просто не справится с этим.
DracoWF
26.02.2018 12:18«Но мечты исполняются очень нечасто. Мои разработчики редко думают о тех, для кого и зачем они пишут свой код. Их главная задача — построить идеальную архитектуру, использовать самые топовые инструменты, попробовать новые технологии.»
Незрелые какие-то разработчики…Stratanovich
26.02.2018 12:22По опыту общения с другими менеджерами — такая проблема не только у меня. Я верю, что где-то есть разработчики моей мечты — зрелые, самоорганизующиеся и с продуктовым мышлением. Я описываю те проблемы, с которым сталкиваюсь именно сейчас. Я надеюсь, что мы с командой их перерастем
SirEdvin
26.02.2018 13:35Каждый хочет, что бы разработчики еще и занимались куском их работы.
Админы хотят, что бы разработчики думали о таких страшных штуках, как observability.
Тестировщики хотят, что бы разработчики думали о том, как будет удобно тестировать приложение.
Менеджеры хотят, что бы разработчики еще занимались самоогранизацией.
Продукт овнеры хотят, что бы разработчики еще имели продуктовое мышление.
CTO хочет, что бы разработчики разбирались в последних технологиях.
Архитектор хочет, что бы разработчики были сознательные и сами думали про архитектуру.
А что делать разработчикам?Stratanovich
26.02.2018 14:49Проще всего сказать — «Я тут просто код пишу, а вы дальше сами мучайтесь, это не моя задача.»
Так же, как и я, менеджер, могу вообще о коде не думать, не понимать, что такое API, и как там внутри все взаимодействует. Могу не разбираться в железках, а каждый раз дёргать админа, когда мне задают вопрос по оборудованию.
Менеджер проекта может не читать документацию, которую нам прислали партнеры для интеграции, а просто скинуть ее в задачу (Нам часто присылают неполную документацию или вообще не то. Мы стараемся сами ее просматривать и просим уточнения, чтобы лишний раз разработчиков не отвлекать).
Да много чего можем не делать, что не входит в круг наших прямых обязанностей. В тоже время я понимаю, что иногда мне проще пожертвовать своим временем, чем просить это сделать разработчика.
В этом смысл командной работы — помощь друг другу, коммуникации.
Ну и еще момент — продуктовое мышление не требует дополнительных затрат времени. Когда ты открываешь задачу, ты не просто как робот ее выполняешь, а сначала задаешь вопросы — себе и менеджеру, если нужно. В большинстве случаев этого достаточно.SirEdvin
26.02.2018 15:05Ну и еще момент — продуктовое мышление не требует дополнительных затрат времени. Когда ты открываешь задачу, ты не просто как робот ее выполняешь, а сначала задаешь вопросы — себе и менеджеру, если нужно. В большинстве случаев этого достаточно.
У вас прямо тут скрыто противоречие. Перед тем, как делать задачу, мне нужно отвлечься от погружения в код и технический реализации и подумать про то, как это должно быть для конечного кастомера, и, очень вероятно, задать кучу вопросов менеджеру, потому что у него банально знаний о кастомерах довольно мало. И в зависимости от задачи это может занимать довольно много времени, особенно если задача была плохо проработана сверху (а такое тоже бывает).
Продуктовое мышление требует затрат по времени, особенно от программистов, так как очень часто из-за процессов и экономии по времени они не посвящены даже в концепции продукта. Так же как и другие факторы, о которых нужно думать, observability, тестирование и прочее. Ну и менеджеры не готовы выделять на это время, потому что как и вы считают, что "это не требует затрат по времени", хотя на самом деле это далеко не так.
Мое мнение в том, что очень часто менеджеры при том, что желают получить более инициативную команду с прокачанными скилами не готовы ни платить выше рынка, что бы привлекать профессионалов, ни выделать дополнительное время, что бы у разработчиков была возможность посмотреть выше головы, ни становится жестким буферов между ними и заказчиком, когда тот давит со сроками.
Ну и опять же таки, продуктовое мышление, как мне кажется, что вы его понимаете, очень сложно будет даваться разработчикам, например, часто можно оценивать фичу, которые запрашивают в том числе и с точки зрения того, как эта фича повлияет на саму программу, и скажем, иногда в угоду логике программы просить даже ее немного изменить. В противовес этому, мне кажется, большинство продакт менеджеров к такому не готовы.
SirEdvin
26.02.2018 15:37Немного тупняка.
У вас прямо тут скрыто противоречие. Перед тем, как делать задачу, мне нужно отвлечься от погружения в код и технический реализации и подумать про то, как это должно быть для конечного кастомера, и, очень вероятно, задать кучу вопросов менеджеру, потому что у него банально знаний о кастомерах довольно мало. И в зависимости от задачи это может занимать довольно много времени, особенно если задача была плохо проработана сверху (а такое тоже бывает).
Я имел ввиду как-то так:
У вас прямо тут скрыто противоречие. Перед тем, как делать задачу, мне нужно отвлечься от погружения в код и технический реализации и подумать про то, как это должно быть для конечного кастомера, и, очень вероятно, задать кучу вопросов менеджеру, потому что у меня банально знаний о кастомерах довольно мало. И в зависимости от задачи это может занимать довольно много времени, особенно если задача была плохо проработана с точки зрения бизнеса. (а такое тоже бывает).
Stratanovich
26.02.2018 18:42У вас прямо тут скрыто противоречие. Перед тем, как делать задачу, мне нужно отвлечься от погружения в код и технический реализации и подумать про то, как это должно быть для конечного кастомера, и, очень вероятно, задать кучу вопросов менеджеру, потому что у него банально знаний о кастомерах довольно мало.
Не вижу противоречий. Когда вы садитесь делать задачу (я говорю о продуктово задаче, а не о технической, где четко прописано, в какой функции что нужно изменить), вы должны сначала понять, что именно должны запрограммировать.
Бэкенд и фронтенд садятся и пишут спеку на основе прототипа от дизайнера, например. Они уже трогают функционал. Нужно просто сделать маленький шажок и посмотреть на это не с точки зрения: «Мне нужно, чтобы мой код вот так делал», а с точки зрения: «Хотел бы я этим пользоваться? Удобно ли бы мне было?»
Продуктовое мышление требует затрат по времени, особенно от программистов, так как очень часто из-за процессов и экономии по времени они не посвящены даже в концепции продукта.
Так разработчики как раз и должны быть посвящены в концепцию продукта. Задача менеджера продукта, в том числе, объяснять команде, кто и как использует продукт, зачем мы вообще его делаем.
И если разработчики этого не знают (хотя хотели бы), то это уже ошибка менеджера.SirEdvin
26.02.2018 18:53Бэкенд и фронтенд садятся и пишут спеку на основе прототипа от дизайнера, например. Они уже трогают функционал. Нужно просто сделать маленький шажок и посмотреть на это не с точки зрения: «Мне нужно, чтобы мой код вот так делал», а с точки зрения: «Хотел бы я этим пользоваться? Удобно ли бы мне было?»
И вот тут вы не правы. Им нужно не просто подумать "мне нужно, что бы мой код делал X", а "Как мне написать так, что бы мой код делал X", что далеко не всегда тривиальная задача, иначе бы им не платити так много. И вы их просите подумать еще дополнительно о том "Хотел бы я этим пользоваться? Удобно ли бы мне было?". Это дополнительная работа, которая требует время. Тут еще стоит заметить, что у некоторых разработчиков (например, у меня), немного другие подходы к оценке удобства инструментов, чем у пользователей. Например, я считаю довольно важным существование API для этого инструмента. Важно ли это пользователю? Сложный вопрос.
Stratanovich
26.02.2018 19:14И вот тут вы не правы. Им нужно не просто подумать «мне нужно, что бы мой код делал X», а «Как мне написать так, что бы мой код делал X», что далеко не всегда тривиальная задача, иначе бы им не платити так много. И вы их просите подумать еще дополнительно о том «Хотел бы я этим пользоваться? Удобно ли бы мне было?». Это дополнительная работа, которая требует время.
Любой навык можно тренировать. В первый раз вы потратите на это 2 дополнительных часа. Во второй — 1,5. В третий — час. И т.д. Со временем вы привыкнете к продукту и к такому мышлению, и это будет происходить очень быстро. И если мне разработчик скажет, что он потратит 2 часа, чтобы понять функционал продукта, я с радостью включу эти 2 часа в план разработки.
Потому что это принесет много дополнительных бонусов. Как минимум, вы начнете отлично разбираться в функционале и будете видеть всю картину целиком.
Тут еще стоит заметить, что у некоторых разработчиков (например, у меня), немного другие подходы к оценке удобства инструментов, чем у пользователей.
Тут согласна, есть замечательная книга на эту тему «Психбольница в руках пациентов». Никто не говорит, что вы полностью должны проводить ревью функционала, но иногда команда действительно может заметить какие-то неудобства или предложить решение, которое менеджеру просто не пришло в голову, потому что он над этой задачей сидит уже 5 дней, и у него банально взгляд замылен.
Нужно просто обращать на это внимание. И если возник вопросы, не думать: «Зачем я за менеджера буду его работу делать? Он пусть и думает. Не написано, значит не делаю.» Иногда действительно достаточно просто вопрос правильный задатьSirEdvin
26.02.2018 19:22Потому что это принесет много дополнительных бонусов. Как минимум, вы начнете отлично разбираться в функционале и будете видеть всю картину целиком.
Я не знаю, как в вашей команде, но в некоторых компаниях у разработчиков не хватает времени, что бы изучать то, что делать другие с технической части, откуда у них будет время еще и на продукт?
К тому же, стоит заметить, что это не два часа и не единоразово. Вполне возможно, что первый месяц оценки задач вырастут в два раза (взял с потолка) и без учета времени, которое вам нужно будет тратить, что бы объяснять все разработчикам.
Опять же таки, стоит заметить, что:
- Вроде как большинству людей довольно сложно поддерживать две точки зрения на продукт. А значит, или продуктовая точка зрения будет хромать, или он будет писать плохой код. Лично мне довольно сложно и видеть всю картину целиком, и вдаваться в детали. Вроде получается, но все время то там, то тут могу что-то упустить. Мне кажется, не я один такой буду.
- Его понимание продукта, внезапно, может оказаться совершенно другим, не таким как у вас, а значит, за ним все равно нужно будет следить.
proercontra
27.02.2018 10:55«Нужно просто сделать маленький шажок» — одна моя команда разработки, любила в верхней части доски для мозгоштурмов и обсуждений выписывать актуальную моменту цитату. Часто побеждала «всё просто, что делаешь не ты».
Вы сами код писали когда-либо, что так уверенно говорите про «просто» и «маленький шажок»?
JekaMas
27.02.2018 11:50Вероятно, вопрос еще хуже и сложнее.
"Если бы я был ЦА этого продукта, то как я бы хотел этим пользоваться? Блин, мне надо понять ЦА этого продукта… но я вроде как программист..."
Что толку если я, представитель среднего класса, буду думать об удобстве бизнеса, не ведая его проблем, бизнес-процессов, персонала, обучения и квалификации его персонала? Это выглядит далека не как "не составит труда", а скорее, как отдельная компетенция, которую надо прокачивать. Хорошо, я начну ее прокачивать, а как на это мое управление посмотрит? Вот я прокачиваюсь в понимании клиента и продажах (ведь вопрос, по сути, о том, как мне писать код, который лучше продастся), а что мне делать с тем, что, скажем, через месяц ко мне подойдет мой лид и спросит, почему я не расту как программист? Ответить, ну я клиента лучше понимать стал? Ну стал, а продукт нам на что?
dmitry_hidden
26.02.2018 17:55Соглашусь с комментатором. А по поводу этого:
«Моя мечта, как и любого менеджера продукта — команда, которая будет понимать своего пользователя и его потребности, будет валидировать задачи и думать о том, какую пользу каждая фича принесет клиенту.»
А моя мечта как разработчика, получать четкое ТЗ. В идеале чтобы в тикете была вся необходимая информация, и единственное что мне нужно сделать, это найти техническое решение поставленной задачи.
Что же я вижу на практике?
Не полное ТЗ, постоянная коммуникация с PM, аналитиком, в заказчиком прежде чем приступить к выполнению задачи.
Так а что же важно для бизнеса?
А для бизнеса не нужны ни менеджеры, ни аналитики, ни программисты. Для бизнеса важны люди, которые могут закрыть собой какую-то область проблем, взять на себя головняк и не беспокоить начальство. Нужны люди которые будут своей грудью закрывать дот, чтобы по телам этих страдальцев мог пройти бизнес.
Правильно или нет — спорный вопрос. Но то что я вижу вокруг, говорит о том что бизнес так работает. Есть только единственный ресурс который бизнес бережет и пытается заполучить — это деньги. Все остальное это инструменты заполучения этого ресурса.Stratanovich
26.02.2018 18:45Не полное ТЗ, постоянная коммуникация с PM, аналитиком, в заказчиком прежде чем приступить к выполнению задачи.
Я вас понимаю) Как и своих разработчиков, которые тоже этого хотят.
В статье я как раз попыталась приоткрыть завесу и рассказать, почему зачастую это очень сложно (а еще долго, дорого и может оказаться никому ненужным)
mad_nazgul
27.02.2018 07:17И вы хотите эту сложность переложить на программистов?!
Типа они умные пусть думают. :-)
Зачем тогда нужны PM?!
JekaMas
27.02.2018 11:53Ну сначала это займет месяц, потом 3 недели, потом 2…
Простите, не удержался.
Mishiko
27.02.2018 00:38Я верю, что где-то есть разработчики моей мечты — зрелые, самоорганизующиеся и с продуктовым мышлением.
— тут есть обратная сторона) В одной из контор видел «зрелых» разработчиков, которые ПМа хренами крыли когда им казалось, что он предлагает то что, на их взгляд, заказчику не нужно. И, да, они стремились лично пообщаться с заказчиком)
Mishiko
26.02.2018 18:15Грустная статья. Автор плохо понимает что именно он пишет:
Я понимаю опасения разработчиков, но, общаясь с пользователями, я понимаю, что большинству из них не нужна идеальная архитектура… Они готовы (на первых этапах, конечно) терпеть баги
Нужно эту фичу переделать
— непродуманная архитектура, помноженная на многократные доделки и переделки, рождает блохастое чудовище, которое проще усыпить чем вылечить. Через пару лет существования такого продукта неожиданно окажется, что добавление новой фичи или устранение простой на вид ошибки вызывает у разработчиков непропорционально большие трудозатраты. И не говорите тогда, что вас не предупреждали — все эти стоны разработчиков про необходимость рефакторинга, это вам четкий сигнал, что продукт с гнильцой.
Следствия вашего подхода к разработке:
— низкая мотивация в команде (это уже заметно в статье) и недовольство менеджмента в отношении команды, с последующей текучкой кадров;
— бесконечный поток ошибок в продукте, в стиле эту лапу вытащили, другая увязла. Да еще и ошибки устранять будете медленно. За это получите справедливое недовольство клиента, который наивно предполагал что покупает качественный продукт.
Также хорошо видно, что автор не понимает термин MVP. Минимально работоспособный продукт, это продукт с минимальной функциональностью, а не интерфейс пришитый белыми нитками к коленке. Хорошая картинка про это:
Ну а это вообще супер:
Mishiko
26.02.2018 18:30Ну а это вообще супер:
Я не объясняю, какую проблему решает их фича, а просто набрасываю задачи в бэклог, надеясь, что команда сама придет ко мне с вопросами
— постыдились бы такое писать! Ваша задача мотивировать команду, а не демотивировать ее. Уверен, что разработчики видя задачи в бэклоге комментируют это так: «опять какая то мутная и непонятно кому нужная хрень, которую потом придется переделывать».
В общем, хорошего менеджера, умеющего работать не только с заказчиком, но и с исполнителями, также трудно найти как и хорошего разработчика.Wert1go Автор
26.02.2018 18:52В общем, хорошего менеджера, умеющего работать не только с заказчиком, но и с исполнителями, также трудно найти как и хорошего разработчика.
И это абсолютная истина.
В тексте как раз речь о том, что и за менеджерами бывают такие грехи. Стыдиться этого или нет — это выбор личный. На мой взгляд открыто говорить о проблеме — это один из шагов на пути к её решению.
Stratanovich
26.02.2018 18:57— непродуманная архитектура, помноженная на многократные доделки и переделки, рождает блохастое чудовище, которое проще усыпить чем вылечить. Через пару лет существования такого продукта неожиданно окажется, что добавление новой фичи или устранение простой на вид ошибки вызывает у разработчиков непропорционально большие трудозатраты. И не говорите тогда, что вас не предупреждали — все эти стоны разработчиков про необходимость рефакторинга, это вам четкий сигнал, что продукт с гнильцой.
Это один из рисков быстрой разработки.
На другой чаше весов — мы будем продумывать архитектуру, писать ТЗ, долго и качественно все реализовывать, а потом, например, выйдет закон, который скажет, что так больше делать нельзя (а такое часто бывает с b2b продуктами). И мы получим много потраченных денег и ненужный продукт, но зато с классной архитектурой.
Вопрос лишь в том, что вы считаете большим риском.
низкая мотивация в команде
Надеюсь, что нет. Я как раз очень стараюсь донести, что гордиться надо не идеальным кодом, а тем, что твой продукт приносит пользу людям
Также хорошо видно, что автор не понимает термин MVP
Автор понимает, что такое MVP, а эта картинка стоит у нее в качестве заставки на рабочем столе.
Если посмотреть на эту картинку, то видно, что на первом этапе MVP, например, не имеет двигателя. Я прихожу к разработчику и говорю: «Давай сделаем железную коробку на колесах, чтобы ее можно было вручную толкать». Разработчик делает. Потом я прихожу и говорю: «Давай двигатель добавим», а в ответ слышу: «Мы это в архитектуру не закладывали», так что пусть и дальше руками толкают.
постыдились бы такое писать!
Я как раз и писала это в негативном свете, что я ловлю себя на мысли, что так делаю, хотя это неверно. Я тоже неидеальна. И иногда замечаю, что не объяснила что-то разработчикам, потому что для меня это очевидно, а для них — нет. Когнитивные искажения никто не отменял.SirEdvin
26.02.2018 19:06Это один из рисков быстрой разработки.
Это не риск быстрой разработки. Это практически гарантированный результат, которого можно избежать только при помощи очень крутой командой, которой может похвастаться очень мало компаний.
Опять же таки, никто не просит вылизывать архитектуру до идеального варианта, но хотелось бы хоть неплохую. А часто даже такого не дают.Junior
26.02.2018 19:10Альтернатива тоже практически гарантирована. Попасть в рыночную потребность с первого раза могут только очень крутые менеджеры. Но у них и команды часто их уровня :-)
SirEdvin
26.02.2018 19:11Как я понимаю, альтернатива гарантирована в любом случае, даже если вы стартап с MVP и выпустили продукт за месяц.
А у архитектуры хотя бы есть какие-то шансы)Junior
26.02.2018 19:17Я это говорю, как человек, который сделал классное ТЗ на сервис, дал возможность сделать хорошую архитектуру, но только продукт оказался нахрен никому не нужный на рынке, хаха! Ну и спалил туда денег своих размером с «аааавтомобиль» © Зато архитектура хороша, пропади она пропадом :-))
Думаете доволен разработчик, что сделал классный код? Неа. Потому что его труд остался лежать ровно также незаметно, как если бы он его удалил.
А вот я бы с радостью «закопал» в проект чуть меньше денег и а остальные деньги пустил бы в другой проект, глядишь бы второй выстрелил.Junior
26.02.2018 19:20Риск и потеря своих личных денег хорошо отрезвляет и расставляет все по местам. Отличная школа.
Junior
26.02.2018 19:07Я прихожу к разработчику и говорю: «Давай сделаем железную коробку на колесах, чтобы ее можно было вручную толкать». Разработчик делает. Потом я прихожу и говорю: «Давай двигатель добавим», а в ответ слышу: «Мы это в архитектуру не закладывали», так что пусть и дальше руками толкают.
Решение напрашивается само собою: Вместе с задачей на железную коробку можно обсудить перспективы: «Слушай, а если тележка понравится, сможем мы приделать ей колеса?»
Если, конечно, есть понимание возможных сценариев развития.Stratanovich
26.02.2018 19:18Вот тут есть риск, что тебе начнут сразу закладывать двигатель, что потребует еще 2 недели разработки. А потом окажется, что железная коробка вообще не подходит. И колеса не нужны — а нужны крылья. И вообще оно по земле перемещаться не может в силу ограничений бизнеса клиента.
Ну и сценарии не всегда понятны, когда ты первопроходец.
Mishiko
27.02.2018 00:11эта картинка стоит у нее в качестве заставки на рабочем столе.
Если посмотреть на эту картинку, то видно, что на первом этапе MVP, например, не имеет двигателя. Я прихожу к разработчику и говорю: «Давай сделаем железную коробку на колесах, чтобы ее можно было вручную толкать». Разработчик делает. Потом я прихожу и говорю: «Давай двигатель добавим», а в ответ слышу: «Мы это в архитектуру не закладывали»
— кто то неправильно понимает картинку. Я вижу, что изначально проектируется приложение на которое можно установить двигатель, но пока его нет — толкаем руками, типа приложение принципиально может масштабироваться, но сдаем мы его на одной ноде. Видимо не донесли до разработчика/архитектора граничные условия и он понял что всегда будут руками толкать, либо он все понял, но на вас болт положил и саботирует, ссылаясь на то что изначально про двигатель ничего не говорилось (а сказать надо было).
На всякий случай та же картинка еще раз:
Mishiko
27.02.2018 00:23Это один из рисков быстрой разработки.
На другой чаше весов — мы будем продумывать архитектуру, писать ТЗ, долго и качественно все реализовывать, а потом, например, выйдет закон, который скажет, что так больше делать нельзя (а такое часто бывает с b2b продуктами). И мы получим много потраченных денег и ненужный продукт, но зато с классной архитектурой.
— не надо называть продуктом то что им не является, вы делаете не продукт, а прототип, да и то усеченный (в прототип, архитектура тоже обычно закладывается). Вместо того чтобы расписывать в ТЗ неизвестно что, надо сообщить разработчику граничные условия, что он должен сделать — самокат или автомобиль и, если автомобиль, то грузовой или легковой. Детали про окраску, фары и отделку салона на ранних этапах не нужны. Как раз архитектура, часто описывается даже не в виде кода, а в виде блоксхем и если и требует заметных трудозатрат, то на отработку не проверенных гипотез — типа, а сможем мы лить в базу XX по YYY запросов в сек. Ну и насчет законов влияющих на архитектуру… такая мизулина еще не родилась или вы называете архитектурой не то что я.
ninadinastiia
27.02.2018 17:43Совершенно с Вами согласна! Профессионалов мало, умных терминов нахватались, а работу друг на друга переваливают). У меня был жизненный пример, когда разработка сайта была полностью на верстальщике, который заголовки у фото охотников с волками подписал «Улов волка»))))
Программист — это программист. Он совсем не менеджер и то что нужно клиенту — он не знает. Вы еще предложите всем программистам и участником команды поговорить с клиентом… Вы должны вникать и переводить на два языка — «для клиентов» и «для работников».
От менеджера приходит заказ на товар, и если он не верно понял клиента — винить команду не стоит, что нужно переделывать. Используйте в работе прототипы, что ли… Это проблема называется «Нет хороших работников»! Извиняюсь, сама руководитель.
Junior
26.02.2018 19:01Все просто:
- У разработки результат выполнения известен и валидируется однозначно;
- У product-owner'ов результат выполнения НЕ известен и валидируется рынком по-разному.
И надо помнить, что работа «в стол» демотивирует ЛЮБОГО. А чтобы снизить этот эффект, надо задать разработке один вопрос: «Парни, я за пиццей, какую возьмем сегодня?» И за совместным поеданием наладить отношения и обсудить «эксперименты Эдисона».
p.s. Опытные менеджеры, кстати, в бюджет проекта закладывают «представительские расходы» на такие угощения пиццей ;-)
watti
27.02.2018 04:54для меня странно выглядит весь этот продакт-менеджерский рандом вслепую с целью найти хорошее решение. обычно когда человек в чем-то разбирается, то он бьет не вслепую, а отбирает решения на основе некоторых рассуждений
признавать что вы не в состоянии составить ТЗ и продумать на пару шагов архитектуру и возможные подводные камни — на мой взгляд как расписываться в том что вы не шарите в предметной области
сидишь потом без ТЗ и мутным заданием и сам за продакта додумываешь как это дело реализовыватьJunior
27.02.2018 09:17Работа «вслепую» выглядит странно для любой специальности, не так ли? Речь в статье не о плохих ТЗ, а невозможности сделать market fit с наскока.
Как говорил Эйнштейн, правильно сформулированный вопрос содержит ответ. Проблема в том, чтобы этот вопрос (market fit) найти и сформулировать. В этом первая задача продакта.
Вторая описываемая в статье проблема в том, что зачастую команда разработки живет в своем мире, где все задачи гарантированно правильные и в самой задаче не содержится «багов». При том, что «баги» в результатах выполнения задач считаются нормой и наличие тестировщиков тоже считается нормой.
Junior
27.02.2018 09:22В этом смысле очень интересно почитать о том, как устроена разработка в Booking.com.
ggo
27.02.2018 10:56Надо различать в принципе мутное ТЗ, когда действительно выгодоприобретатель не знает чего хочет. Да, такое бывает. Но недолго, т.к. рынок возвращает прагматичность очень быстро.
И случай, когда в принципе есть неопределенность, и сегодня ты решения принимаешь в одних условиях. А завтра ты быстро переобуваешься, потому что условия изменились.
lotse8
27.02.2018 10:13+1Может быть Вы причину не там ищите?
Мои разработчики
Их главная задача
я описываю гипотезы и для их проверки мне нужно, чтобы команда
Такое создается впечатление, что Вы сами противоставляете себя команде. Я и команда. Я и они. Я хорошая, а они такие непонятливые (мягко говоря).
Или же у Вас лично проблемы с коммуникацией с командой, что Вы не можете свои идеи правильно донести. Или же у Вас идеи слабоваты и в результате потом 90% приходится переделывать. Не знаю, диагноз по интернет поставить невозможно.
Сам работал и сделал несколько продуктов с разными командами, но таких проблем никогда не возникало. Приходилось некоторые функции доделывать или делать иначе, но чтобы все в стол — такого никогда не было. Может быть поэтому команде с Вами и работать тяжело, что бОльшая часть кода потом выбрасывается. По-человечески все без исключения хотят гордиться результатами своего труда, а не работать вхолостую.
ggo
27.02.2018 10:49У статьи у очень ценные комментарии. ;) Классика случая, когда бизнес хочет, а ИТ не может.
И про мотивацию, и про архитектуру, и про кто кому чего должен, и про хорошее тз ;)ninadinastiia
27.02.2018 17:53Точно… как на дороге) так и тут… дипломы есть — а работать ник то не умеет)
DarkWanderer
27.02.2018 10:55+1А команде это точно преподносится как MVP, или команда каждый раз находится в уверенности что делает финальный продукт и "уж на этот раз точно всё"
JekaMas
Какая-то у вас странная продуктовая компания с waterfall, разработчиками, рисующими "продающий зеленый"…
Теме много-много лет, так много, что мне уже кажется, что все холивары о гибких подходах отгремели.
Wert1go Автор
Речь не совсем про гибкие подходы, а скорее про отношение к тому, что и как делается.
Можно быть сколько угодно гибкими и не делать то, что действительно нужно. И можно использовать waterfall, и при этом решать задачи/проблемы клиентов и все будут довольно. Это всего лишь инструменты.
Важен результат.
JekaMas
Про это гибкие подходы и есть. Они ж не о том, как программировать, а о том, как продукт сделать.
Вы пробовали работать не по waterfall?