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 день, или попытаться принять участие в корректировке технологии, или, наконец, фундаментально неверно оценить перспективы самого продукта.
Но! Даже в последнем случае клиент хотя бы будет знать, что проблема в самом продукте как таковом, а не в его кривой реализации. Он проверит свои предположения и видение. А это тоже знания, которые прошли проверку рынком. И могут стать основой для формирования видения нового продукта.
В любом случае, вероятность успеха, если команда будет понимать бизнес-смысл всего функционала, будет выше. Поэтому не живите только в мире задач. Этого мира в реальности не существует.
