World of tasks, или Куда разработчикам прикладывать Product thinking

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

Оставим пока в стороне клиента и немного поговорим о продуктовом мышлении самой команды. Итак, куда прикладывать Product thinking, зачем это делать и почему команде лучше не жить в мире задач?

Копать от забора и до вечера!

Хотелось бы начать с общей картины мира, но не всей, а той небольшой ее части, которая относится к разработке программного обеспечения как таковой. Очевидно, разработка в отрыве от конкретного бизнеса из реального мира совершенно бесполезна. Даже если непосредственный клиент — другой IT-сервис, скажем Google, для которого мы пишем какую-то плюшку для Adsense. В конце цепочки все равно стоит человек, который платит реальные деньги. В данном случае за размещение рекламы, которое потом оплатит покупатель рекламируемого товара и так далее.

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

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

Prerequisites

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

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

Также вынесем за скобки ситуацию, когда команда не ставит одной из целей повышение своего профессионального уровня. Если вы готовы N лет продолжать клепать за деньги ровно те же самые пасочки, тем же самым способом, продуктовое мышление будет вас только отвлекать.

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

Мы знаем только то, что мы знаем

Кто определяет, что именно будет иметь ценность для конечного пользователя? Конечно, клиент. Исходя из чего? Исходя из массы вещей — исследований, опросов, трендов, своих знаний, опыта и так далее. То есть, используя доступные инструменты, клиент формирует свое видение того, что, собственно, нам нужно сделать. В какой-то момент он приходит к более-менее формализованному набору фич, наиболее ценному для конечного пользователя.

Тут важно понимать, что независимо от количества и качества продуктовых ресурсов и усилий, мы все еще имеем дело с предположениями. Это не вопрос качества планирования, никто не может быть уверенным на 100%, что именно нужно пользователю. Никто, до того момента, пока команда не произведет и не выпустит первую версию продукта, получив обратную связь.

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

Бизнес-ценность и полфичи

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

Команда как группа умных и мотивированных людей, которая уже находится в контексте продукта — это первая линия обратной связи по ценности функционала и, соответственно, совсем не лишний инструмент валидации в руках клиента. Если вы не можете доступно объяснить команде, зачем нужна фича Х, как вы собираетесь заставить «купить» это реальных пользователей?

Впрочем, справедливо и обратное. Если команда, к примеру, говорит, мол, не знаю, не моя работа, придумайте сами, подробно объясните, а уж мы закодим и нарисуем точно так, как будет написано в тасках, клиенту понадобится промежуточный приемник передатчика. Приемник, во-первых, убедится, что задачи, над которыми работает команда, имеют отношение к бизнес-ценности. А во-вторых, будет держать в голове всю фичу и проследит, чтобы люди, которые роют тоннель с двух сторон, например, back-end и mobile, все-таки встретились.

Где гарантия, что промежуточное звено ничего не упустит и ничего не потеряется «в переводе»? Зачем этим нагружать отдельного человека, который сам не создает этот функционал? И, собственно, где командная (в самом широком смысле) работа над достижением бизнес-цели?

Ценность метода, сделанного на back-end, сама по себе, без интерфейса, к примеру, на mobile, обычно равна нулю. Как и интерфейса без метода. Потому что нету таких фич: Х.back-end и Х.mobile. И пользователю все равно, что там у вас припасено в репозитории в стадии даже 90%-й готовности. Ценность либо создана, либо нет.

Плюсы и минусы

Естественно, я не предлагаю команде принимать бизнес-решения — это тернистая тропа в никуда. Почему? Потому что, во-первых, любое решение предполагает ответственность, а сам бизнес — это зона ответственности клиента, тут нет никакой технологии. Во-вторых, команда не обязана обладать и, как правило, не обладает достаточным уровнем экспертизы в предметной области для того, чтобы принимать такие решения. И я не предлагаю команде это делать, я предлагаю видеть за своим кодом конечный результат, которым будут пользоваться живые люди.

Помимо прочего, массу логических проблем можно отловить на гораздо более ранних стадиях, где их устранение будет менее болезненным и долгим. Даже до разработки функционала, на стадии, к примеру, Product Backlog refinement, команда часто в состоянии оценить целостность и логичность решения, которое предлагает клиент. Да, такой подход требует бóльших усилий, но и каждый член команды, и команда в целом, становятся инструментом гораздо более широкого спектра применения.

Зачем это нужно в аутсорсе и особенно аутстафе? Затем, что это качество разработчика и команды. Это его или ее уровень. Не существует разработчиков, которые генетически не способны мыслить категориями продукта. Это навык, а навык нужно отрабатывать и оттачивать. Есть разработчики и команды, которые не хотят идти этим путем, но это уже другая история.

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

Выводы

Гарантирует ли такой подход оглушительный успех? Конечно, нет. Любую схему без исключения можно реализовать плохо. Даже если копнуть только со стороны клиента, он может превратить все виды планирования в брейнсторминг, или упасть до горизонта планирования в 1 день, или попытаться принять участие в корректировке технологии, или, наконец, фундаментально неверно оценить перспективы самого продукта.

Но! Даже в последнем случае клиент хотя бы будет знать, что проблема в самом продукте как таковом, а не в его кривой реализации. Он проверит свои предположения и видение. А это тоже знания, которые прошли проверку рынком. И могут стать основой для формирования видения нового продукта.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




32 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Эх, какой оптимальный и красивый путь взаимодействия команды с Product owner. Безусловно нужно, чтобы команда видела стратегию развития продукта, как минимум. Как максимум ее воспринимала, была в диалоге с бизнесом и предлагала оптимизацию этой стратегии со своей стороны.
Но реальный мир аутсорса, (про аутстаф вообще промолчим), как правило, не нуждается даже в слове «команда». Купил подешевле, продал подороже. Вот и вся стратегия.
Вот и все бизнес-интересы со стороны разработки на топ-уровне.
Более того, мы ж говорим о реальной жизни? Мне приходилось работать в продуктовых компаниях, где разработчики не понимают куда идет продукт, и что нельзя лить в прод, в то время, когда СЕО презентует уже разработанные фичи новому клиенту. Мир задач и маржи он такой. И попробуй убедить топов, что можно иначе.

Мир не идеален. Поэтому я добавил первый абзац в Выводах

в то время, когда СЕО презентует уже разработанные фичи новому клиенту.

Идёт запуск нового шаттла на нём присутствует инженерный состав. Младший инженер отчаянно шепчет старшему:
— Но старт нужно отложить — наша система не готова!
— Молчи и улыбайся! — так же шёпотом отвечает старший.
— Но будет же ж авария!
— Молчи!..
3 минуты до старта. 2 минуты до старта. 1 минута до старта. Вскакивает младший инженер другой команды и кричит:
— Старт нужно отложить — в нашей системе критическая ошибка!
Старший инженер первой команды своему младшему:
— Вот видишь старт отложен найдена ошибка но не в нашей системе и в отложенном старте виноваты не мы теперь у нас есть время разобраться в нашей.
(к)

ЗЫ: была картинка-комикс на тему (ровно то же ж только в картинках) но с ходу не нашёл.

а что такое бизнес-цель?

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

работу Сизифа

.
Часто вижу в коментах мысли вида «у нас мало продуктов, нам нужно больше своих продуктов, все продукты в кремниевой долине». Видели как американцы работают? Я не говорю про владельцев бизнеса, про всех, кто работает в команде — они искренне переживают и паряться о своем продукте. Для нас же это выглядит дикостью, у нас лейтмотив обычно «чего я должен переживать о его продукте, вот пусть он мне даст акции, тогда посмотрим» и «корпоративная культура, ценности, цели — это все менеджерский булщит. Чего это я должен с коллегами разговаривать или поддерживать беседу, я не нанимался „лучшим другом“, я пришел сюда набирать код, все остальное меня не колышыт. Лучше накиньте 300 баксов, вместо этих ваших культур и тим билдингов». А рынок услуг тоже развивается, клиенты приходят за доменной экспертизой, за консультациями и советами не чисто по технологиям, а по тому, как приносить больше велью, как добиться бОльшего результата.
— Вот у нас есть классные разработчики
— Это хорошо, а вы умеете делать Active Safety системы?
— Эээ, ну нам все равно какую систему делать, что скажете, то они и сделают
— Та нет, пойдем искать тех кто умеет.

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

Отлично! У меня как раз есть этот самый продуктовый майндсет, можно сказать это моя специализация! После разговора со мной клиент часто кардинально меняет первоначальное задание. Ты готов мне за эти навыки платить ну скажем ещё одну зарплату? Восемь штук баксов, четыре за java и ещё четыре за нужные тебе личные качества? Рынок же развивается, сам сказал. Если да, напиши в личку. Если нет, буду -ка я и дальше фрилансить. А тебе успехов в поисках дополнительных навыков за бесплатно!

Пока этот скил в дефиците, специалисты им обладающие безусловно получают больше. Когда наберется критическая масса спецалистов с этим скилом — он станет нормой и те, кто не овладел — потеряют в ценности.
Все разговоры сводятся к +300 ). Я не говорю, что нужно работать бесплатно, я говорю, что цивилизация развивается, мир развивается и меняется профиль востребованных услуг. Можно еще какое-то время продолжать делать то, что делал вчера, но прогресс не остановить, поезд все равно уйдет. А можно развиваться, идти в ногу с рынком и повышать профессионализм и авторитет не только личный, но и нашей страны на мировом рынке. Ну и конечно продавать это преимущество и зарабатывать на нем.

Нет дефицита: хочу и хочу купить — разные вещи.

На вопрос «почему он это делает» никто обычно не отвечает.

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

А еще мало кто спрашивает «а какую пользу принесет этот проект», но все спрашивают «а какие там технологии».

Думаю, в стартапах, медицине, различном конструировании — спрашивают. А в каких-нибудь финансах — по большому счету, какая разница?

хочет, чтобы при этом сроки реализации остались прежними

а це треба зразу доносити до людини, язик для того даний

розвал проекту починається від міскомунікації «ви не сказали, а я подумав» — такого не має бути

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

После просмотра требований большей части вакансий вопрос отпадает сам собой. Понятно, что человек будет стараться попасть на тот проект, который обеспечит ему тёплое место на рынке в будущем — с какой стати ему поступать иначе?) Когда будут вакансии с описанием «нам по барабану, на чём вы пилили раньше, лишь бы у Вас был продакт майндсет», тогда можно будет это обсуждать. Да и cutting edge продакт майндсету не мешает как бы.

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

Потому что этот опыт они уже успешно конвертируют в компенсацию и уверены за своё место на рынке труда, а остальным нужно вписываться в вакансии «чтоб знал всё новое и побольше».

В общем, удивление положению вещей удивляет).

Для нас же это выглядит дикостью, у нас лейтмотив обычно «чего я должен переживать о его продукте, вот пусть он мне даст акции, тогда посмотрим»

С этим согласен — показатель.

«корпоративная культура, ценности, цели — это все менеджерский булщит. Чего это я должен с коллегами разговаривать или поддерживать беседу, я не нанимался „лучшим другом“, я пришел сюда набирать код, все остальное меня не колышыт. Лучше накиньте 300 баксов, вместо этих ваших культур и тим билдингов»

Как человек, работающий удалённо, смотрю на эти слова крайне, крайне скептично — мне отсутствие буллшита только помогает сохранять ориентацию на продукт. Даже очень рад, что никто не вешает нам лапшу — зато есть: большой отпуск, фактически свободный график, лояльное и адекватное руководство, а также прозрачные правила и распределение ролей, плюс контакты в пределах команды сведены к минимуму (в т.ч. с руководством), потому что процессам уделяется пристальное внимание — работай себе в удовольствие.
Недостатки в процессах сглаживаются подобной мишурой, т.к. не могут отказаться от микроменеджмента — раз, далеко не всех возможно научить продакт майндсету — два (потому что чаще всего это проистекает из личных качеств, а перевоспитать взрослого человека силами компании — миссия невыполнима), ну и неумение структурировано излагать мысли и требования в тексте — три (что заменяется разговорами ни о чём, после которых конечный результат всё равно доходит в нужном виде в лучшем случае до половины участников). Не зря же в Railsware жалуются, что не могут найти себе людей — потому что таких людей всегда мало, и их ищут во всех сферах.

Если ты не знаешь, как твои усилия влияют на конечный результат, то для тебя твоя работа становится в некотором смысле бессмысленной. До индустриализации люди занимались ремеслом, они понимали что они делают и для чего, они любили свое дело, учили ему своих детей, они гордились тем, кем были.
Индустриализация заменила персоналии на процессы, и для повышения эффективности процессы разбили на ряд активностей — конвеер. Работник в таком конвеере не делает что-то значимое, к нему поступает деталь с дыркой, в которую нужно вкрутить болтик, и как только он это сделает за ней приезжает следующая точно такая же деталь. В такой ситуации сложно говорить о пользе, которую приносишь, ты понимаешь, что конкретно от тебя ничего не зависит, не выйдешь ты завтра на работу и болтики будет вкручивать другой Вася. Остается разве что думать о том, что ты просто зарабатываешь деньги, вот и весь смысл работы.
В ИТ, мне кажется, ситуация не определенная и многое зависит от конкретных людей. Можно видеть себя частью конвеера и говорить «вот сюда поступают тасочки, я их делаю, остальное меня не колышит, хотите чтоб я делал что-то еще, добавляйте денежек», а можно заниматься ремеслом — любимым делом, «делать лучшие кольчуги или вилы в округе», удобные для пользователей, видеть и понимать как они делают жизнь воинов или мирных жителей проще, лучше, гордится этим.
Разговор не о том, что от ИТшников кто-то хотчет бОльшего за те же деньги, а о том, как мы сами воспринимаем нашу работу, как мы хотим ее воспринимать — как бессмысленный конвеер от которого не получаешь никакого удовольствия или как ремесло и любимое занятие, осмысленное занятие, с видимым результатом и влиянием на мир.
Вот пример отношения, о котором я говорю:
«Innovation is what drives the world forward. It’s what makes the world a better place and the reality is that every era has it’s defining technology. In 1800, it was steam power. In 1880, electricity. In 1925, the internal combustion engine. Today, it’s evident that the defining technology is IT. It’s also evident that innovators in an era’s defining technology are the people who create the future. Do you ever feel like you’re just writing one more piece of code or testing one more app or going to one more meeting? You shouldn’t feel that way. You work in IT. We are the people who drive the world forward. The truth, and I believe this with all of my heart, the truth is this. We work in the most important profession in the world». David Chappell

Дмитрий, это не то, чтоб так должно быть, это один из вариантов, а выбор делать каждому. Я для себя выбрал вариант «я хочу тратить твою жизнь на работу, которая мне нравится и в которой я нахожу смысл». Конечно это не значит, что я абсолютно всегда хеппи, и что мне в работе не встречается г0вно, но я хочу понимать что и для чего я делаю, и когда приходит новая задача или проект, это обычно одни из первых вопросов, ответы на которые я ищу.
Полностью с Вами согласен касательно того, что сложно париться когда всем вокруг насрать и руки очень быстро опускаются. Хорошо, когда такой подход разделяет ваш руководитель, или его руководитель, или несколько коллег. «Менеджер г0вно» — это обобщение, если вникнуть — то оно состоит из каких-то конкретных проблем, которые можно поднимать, решать, эскалировать и т.п. при условии, что вам не все равно. Менеджер точно такой же сотрудник, как и все остальные, просто делает другую работу. Если решать не с кем и вокруг всем пофиг, то возможно это не лучшее место работы для вас, чисто статистически где-то рядом есть компании и люди, которым не пофиг.

Перекладаю з манагєрскої на галєрну.
Продуктове мислення — це не про сири по 500. Ковбасити тасочки можна, але можна й не ковбасити. Думати треба не сракою, а головою.

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

Вот, кстати да.
Катергон от дромона, отличает по сути, только взаимоотношение между командой и командиром :)
Хотя мне больше по душе плавать на кноррах:)

Тю, я думав, що галєра — це про бізнес модель.
Продуктове мислення не залежить від розміру команди. Воно або є, або його немає.

Вот не понял о чем это вообще? Скажу ли я клиенту о потенциальный проблеме — конечно, если увижу её будь уверен. Для этого нужна целая статья?

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

За такого рода проблемы отвечает инженер-проектировщик бассейнов, а не плиточники.

За технологию — да. А если косяк в продукте? Скажем, сам бассейн спроектирован правильно, но вход в него напротив андронного коллайдера, откуда дует. А в душевую надо идти через столовую. Это не проблема бассейна как такового, но ведь этим должны пользоваться живые люди. Им не нужен просто сферический бассейн в вакууме, им должно быть можно пользоваться. Опять же, об этом должен думать в первую очередь Продакт овнер, но сильно не провредит, если контекст будет видеть и команда.
Если у меня как у клиента будет выбор между просто плиточниками и людьми, которые думают, как этим продуктом будут пользоваться конечные юзеры, кого я выберу?

плиточник, который думает, как этим продуктом будут пользоваться — это не плиточник, а человек, который думает, как этим будут пользоваться.

То есть, возвращаясь со скользкой тропы аналогий к разработке софта, разработчик не должен думать, как будут пользоваться продуктом, который он разрабатывает?

Головне тасочку закрити.... ;)

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

Потому что держать для этого отдельного человека в маленьком проекте просто дорого.

нет, не дорого.

Это скилл, но не в сфере продукта. Скилл понимать, для чего ты делаешь то, что ты делаешь. Никто не требует погружаться в глубины или думать вместо Head of Product. Я не знаю, что такое, как вы выразились, небольшое понимание, но я говорю об общей логике и понимании контекста своей работы.

В целом тема важная, но как формировать продуктовое мышление не прибегая к патовым «должны» и «если бы» — вопрос.

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

Красивая картинка воды.
Текст тоже вода, но ее много.
А ценности мало.

Ценность либо создана, либо нет.

Підписатись на коментарі