Corner-cases 😖

Недавно размышлял про поиск баланса между быстрой доставкой ценности и качественным продумыванием редких сценариев. Вопреки общепризнанному подходу с MVP, реальность бывает сложнее. Мыслями про это хочу поделиться.


Очевидно, что в условиях ограниченных ресурсов (то есть, всегда) приходится выбирать, насколь качественно реализовывать функционал.

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

В моём продукте глубина просто запредельная...

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

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

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

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

Но есть, как минимум три "НО", которые стоит при этом держать в голове:


1. Бомба с часовым механизмом

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

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

А ещё эти "взрывы" могут накладываться по времени, превращая работу в непрерывное тушение пожаров на месяцы и просранные коммитменты.


2. Хреновые архитектурные решения

Не смотря на 3-4 шага вперёд, а отталкиваясь только от текущих требований, можно легко разработать фичу, которую дальше не получится развивать.

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


3. Потеря контекста

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

Но, когда я через 2-3 месяца после написания требований разбираю возникшую на проде ошибку, контекст потерян напрочь. И чтобы придумать качественное решение для редкого сценария и потрачу в 2-3 раза больше времени, чем на старте.


Однако, есть и обратная сторона.

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

Некоторые наши конкуренты умудряются работать по такой схеме:
- отдали фичу через 2 недели
- клиент пытается использовать и ругается об ошибках
- ошибки планимерно правятся как инциденты
- фактически фича работает через 2 месяца

При этом у клиента в голове остаётся иллюзия, что "фичи доставляют быстро". Профит!


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


Восхищаюсь подходом Егора Данилова про "отключаем нах" неработающих фичей - позволяет сдерживать комплексити продукта. Но пока не понимаю, как это применить в B2B, и без бюджета на отдельную growth team. Пойду думать дальше. 😆

#product_management