Плохое качество продукта и как с этим жить
И почему нельзя это изменить, а лишь принять и простить
Давненько ничего не писал. Наверное, кто-то мог подумать, что я пал жертвой модной ОРВИ, но не дождетесь =)))
Просто взял себе время на переосмысление профессии.
Итак: сегодня в нашей юмористической программе ответ на вопрос: Почему ВСЕ ваши любимые придожения (веб и мобильные) работаю глючно, а фичи в них добавляются медленно, хаотично и непредсказуемо?
Речь пойдет про базовый продакт менеджмент, нежели про дизайн как таковой, но раз уж в 2/3 вакансий зазывают на работу именно продакт дизайнеров, то о вопросах качества продукта стоит задуматься уже сейчас.
Поехали.
Бизнес vs пользователь
Если смотреть на B2C продукты, то обычно бизнес=пользователь и всё, что хорошо пользователю, хорошо и бизнесу.
Но если мы посмотрим на B2B рынок, то я открою вам тайну: иногда приоритеты меняются в сторону запросов тех пользователей, которые готовы платить деньги за конкретную фичу. Я говорю про разовый платеж за нужную фичу или доработку помимо подписки (если это SaaS продукт).
И что же происходит? Платная фича сдвигает все остальные в сторону (жестко меняет приоритеты в разработке) и не факт, что эта фича войдет в тело основного продукта и достанется другим на халяву. Иногда это называется Custom solution.
Согласитесь, вряд ли владелец бизнеса долго будет выбирать между запланированными фичами и фичей, за которую готовы заплатить 50 000€ 😁 💵
Так бывает не очень часто. Но, как правило, чем больше продукт ориентирован на B2B или Enterprise, тем больше кастомных фич делаются за деньги. И тем меньше уделяется развитию продукта и баг фиксу в моменте времени.
Мифический бэклог
Наверняка вы уже слышали про бэклог. Это помойка, куда кладутся идеи или наброски фич, которые когда-нибуть сделают, но без гарантий, разумеется.
При создании тикета в службе поддержки очередная хотелка или предложение от пользователя попадает в бэкдог.
Фича из бэклога может попасть в разработку только если наберется опреденное количество таких же хотелок / предложений от пользователей. При таких условиях, фичу достанут из бэклога и начнут раскуривать (анализировать) и, возможно, возьмут в разработку.
Почему так происходит?
Представьте, что в компании над продуктом работает два разработчика. Каждый из них может сделать одну среднего размера фичу за две недели.
А в бэклоге может храниться сотни фич.
Параллельно наши два разработчика чинят баги, поэтому разработчик делает половину фичи за две недели в лучшем случае…
Бэклог ширится и раз в год его чистят, выкидывая из него самые «светлые» идеи и предложения, оставляя только то, что кажется важным продакт менеджеру и бизнесу.
Именно поэтому фича, которую вы много раз просили, может никогда не увидеть свет.
Стоимость фичи
Каждая фича стоит денег. Ее стоимость измеряется в часах занятости разработчика.
На ее оценку влияет понимание того, сколько она принесет денег / лидов / платных пользователей.
Основной фактор выбора фичи кроется именно в этих причинах.
Исключение составляют фичи, которые кому-то обещали (обычно крупным или супер важным клиентам).
Бывают исключения и фичи выбирают по зову сердца, но как правило, зов сердца заканчивается сразу после запуска продукта. Потом никто такой ху**ей не занимается, дорого. Надо оговориться: первые несколько лет жизни проекта обычно фичи выбираются по зову сердца, но потом при рассказе об истории успешного успеха бизнеса, никто об этом никогда не скажет. А затем уже всё по науке.
Нетрудно предположить, что высший приоритет имеют дорогие фичи, гарантирующие увеличение прибыли.
Кстати, фичи по улучшению UX становятся востребованными бизнесом в следующих случаях:
- Появился мощный конкурент.
- Пользователи ставят низкий рейтинг и возмущаются в соц.сетях.
- Начальство само в кой-то веки решило воспользоваться продуктом и ах**ло =))
Дизайн бэклог
Хороший и безумно ленивый (в правильном смысле) дизайнер делает фичи быстро. Очень быстро, чтобы поскорее заняться халтурой и личными делами, а не переделывать по десять раз одно и то же.
У «трудоголика» образуется приличный запас фич. В среднем (обсуждал с коллегами по цеху, все из опрошенных называли схожие цифры) запас составляет 7–8 месяцев, в течение которых разработчики закодят всё, что есть в Zeplin (Sketch, Figma, Avocode, не важно где), а «трудоголик» будет заниматься своими делами. Я не утрирую (если честно, приуменьшаю, обычно запас на год+).
Мой личный бэклог по нашему с друзьями проекту сейчас составляет 2 года. То есть, если я не буду рисовать новые фичи, а буду лишь актуализировать старые, то разработчики сделают их за пару лет. Звучит очень пафосно, но когда это от части твой проект, начинаешь грустить 😱😩
Такова реальность. Отмороженный и упоротый менеджмент может начать с этим бороться и обвинять дизайнера в лени, но на закономерное предложение нанять еще пару разработчиков, перед вами разведут руками. Такие ситуации периодически возникают, но после диалога с глазу на глаз вопрос обычно решается в пользу дизайнера и все делают вид, что ничего не было.
Тот самый запас фич ОЧЕНЬ ждут любимые пользователи, но запустить все фичи в продакшн разом физически невозможно. Придется им немного подождать 😶
С такой ситуацией сталкиваются почти все 99.9% IT-компаний, кроме дизайн-студий потому что у них бизнес устроен по-другому. Если вам хочется работать по 12 часов в день и не иметь запаса фич, то вы знаете куда нужно устраиваться на работу 🤣
Плохой неудобный дизайн
Да-да. Не потому что страшный и неудобный, а потому что порой нас всех заносит в сторону красоты, просыпается внутренний креакл и несет в продукт радугу и искрящийся смуззи 🌈 🦄 🍹 .
Иногда мы изобретаем новые контролы и паттерны просто ради того, чтобы изобретать новые контролы и паттерны (как на дрибббббл). А их в свою очередь, кто-то должен закодить и протестировать.
Очередной новый контрол – источник багов, увеличение сроков разработки и тестирования.
Подумайте об этом. Вы должны это понять. Порой ваша заносчивость может стоить баг фикса, длинною в несколько месяцев…
Стоит ли оно того? Вопрос филосовский и зависит от ситуации, но вы обязаны взвесить все ЗА и ПРОТИВ.
Есть удобный способ себя проверить. В пылу креатива отложите комп на минутку, выдохните и задайте себе вопрос: А не ху**ей ли я занимаюсь? Ответ может вас удивить.
Но если очень хочется, заведите аккаунт на дрибббббл, там вас поймут и оценят 🎸
Eternal bugfix
Недавно размышлял, почему весь современный софт являет собой дивный калейдоскоп из багов, костылей и велосипедов.
Пришел к простому выводу: в эпоху CD и DVD шансов выпустить глючный продукт не давали. Исключения было сделано лишь для Windows =)))
Представьте, что после печати миллиона DVD выяснится, что Photoshop тупо зависает после использования Magic wand? Что! будем перепечатывать миллион копий?)
Замечательным примером может служить игра Cyberpunk 2077.
В эпоху «облачных» приложений и гонки за деньги пользователя, разработчики стали расслабленнее, дизайнеры пофигистичнее, продакт менеджеры наивнее, QA почти ослепло.
На самом деле всех выше перечисленных стало в сотню другую раз больше, отсюда и общее падение культуры проектрирования, дизайна и разработки.
Я не хочу никого обидеть, ибо неоднократно сам за собой переделывал и переосмыслял куски продукта спустя некоторое время. И продолжаю это делать, как и все. Потому что продукт эволюционирует, меняется рынок, растут в ширь хотелки клиентов, увеличивается ваш личный опыт в конце концов… 🙃
Но виной замкнутому кругу багов стал именно Agile. Сам по себе он неплох (в гос.лавках саорее безвреден) и в общем-то полезен, но Agile-подход несколько обесценивает главенство данных и архитектуру продукта (читай, сделать тяп-ляп, а там посмотрим), что в итоге оборачивается переделкой всего и вся спустя пару лет. Зато на старте быстро и дешево, не надо обладать особыми скиллами и дальновидностью. Хуяк-хуяк и в продакшн (с)
В итоге именно Agile, плохая разновидность лени и некомпетентность членов команды в области архитектуры данных и продукта и порождает замкнутый хоровод из багов, костылей и велосипедов. Да и Agile официально мертв, LOL.
Говорить о том, что Waterfall подход тоже говно я бы не стал, потому что когда самый аджайловейший стартап со временем превращается в корпорацию, то он все равно начинает жить в реалиях Waterfall, каким бы Аджайловым его не называли с трибун на бизнес-форумах и в кулуарах…
Короче, Agile=Bugfix 🔪
Аверс и реверс
В наше время у каждого большого продукта есть клиентская часть и админка.
Возьмем пример банка, интернет-магазина и сервиса такси. Для большинства B2C клиентов эти продукты представляют собой мобильные приложения и их веб-версии.
Другая же часть продукта, в массе именуемая «Админкой», представляет собой комплекс взаимноинтегрированных систем от CRM, до BPMs и ABS. Монстр-система верхом на монстр-системе на самом деле!
Очевидно, что дизайн интерфейса требуется обоим частям продукта.
Чинить и обогащать фичами нужно обе части продукта, а ресурс, как правило, ограничен.
Дизайнер рисует, а разработка больше фокусируется на той части системы, которая требует внимания прямо сейчас / на которую не было ресурсов / которая и так как-то работала. Чем меньше контора, тем больше перекос в одну из двух из сторон продукта.
Как правило, большие апдейты (редизайны) одной части продукта занимают годы, тогда как другая его часть деградирует под тяжестью веков.
И так по кругу. Удивительно, но увеличение ресурсов разработки не всегда способно сбалансировать обе стороны (чуть чаще, чем никогда).
Это, кстати, вечный предмет споров. Но ковид показал, что от лишнего ресурса с приставкой Middle с удовольствием бросились избавляться, а производительность НЕ ПОСТРАДАЛА 🎩
Крайние кейсы
Мое самое любимое заблуждение, которому подвержены почти все: от дизайнеров до тестировщиков (QA).
Принято считать (видимо, это пошло от ленивых в плохом смысле людей), что при проектировании и дизайне не стоит уделять особого внимания ситуациям (кейсам), которые возникают для 0.001% пользователей 🍿🍿🍿
На деле получается, что сразу же после релиза, тот самый крайний кейс выстреливает матерным тикетом в службу поддержки в через час после релиза. Бинго!!!
Почему так получается? Ввиду заблуждений вроде тех, что пользователь туп либо что такой кейс вряд ли случится 😂
И так происходит до тех пор, пока вы не начнете относиться к этому серьезно! А тем, кто учитывает крайние кейсы, еще и платят больше остальных за экономию нервных клеток для всего коллектива.
Вселенская скорбь
Теперь вы будете с улыбкой и пониманием воспринимать очередной баг в любимом приложении.
Поверьте, вы как дизайнера внесете свои 5 копеек в общую копилку багов, применяя не те паттерны не в том месте, усложняя то, что можно было бы сделать проще или при помощи нативных компонентов.
Да, мы всегда хотим привнести праздник в эту унылую вечеринку, но иногда стоит остановиться на минутку, подумать о том, сколько этот новый контрол принесет геморроя разработчику и как много багов может потом вылезти при тестировании…
Любви вам и терпения ❤️
Если у вас есть вопросы — оставляйте их в комментариях, и я, с удовольствием, дополню этот пост ответами на них 🙏🏻
