Не удержался чтобы не забрать с сообщества Продвижение и сопровождение программных продуктов и систем замечательный текст “Новые фичи? Резать к чертовой матери… ”

Новые функции (фичи, требования, …) в продукте – это не всегда хорошо. В пылу погони за дополнительным функционалом продукта мы можем навредить как непосредственно продукту, так и бизнесу в целом.

Анамнез

“Больше функций хороших и разных!” – часто думаем мы в порыве создания продукта мечты. Бесконечные новые навороты и фишки делают нашу систему более серьезной и профессиональной, позволяют нам поднимать цену, создают видимость развития и прогресса и, конечно же, свидетельствуют о нашей клиентоориентированности – ведь мы стараемся удовлетворить максимальное число запросов наших текущих и потенциальных пользователей. Ох… уж эти запросы в духе “если вы добавите эту функцию, то я обязательно куплю” знакомые всем нам.

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

• Невозможность уделить каждой добавляемой функции достаточных усилий по ее проработке, дизайну, тестированию, оптимизации и доводке до совершенства часто приводит к тому, что программа превращается в комбайн с сотней функций, ни одна из которых не работает идеально. Из-за этого ухудшается общее восприятие продукта, как совокупности посредственных решений. Неповоротливая софтзила с тяжелой поступью, которую невозможно приручить, или нишевая няшка-работяжка, которую хочется бесконечно гладить за ушком и кормить сахарком, за то изящество, с которым она делает свою работу?
• Потеря фокуса продукта, предназначение которого уже тяжело описать одним предложением, порождает очередного Jack-of-all-trades. Попытка впихнуть в маркетинговый слоган, дескриптор или пресс-релиз упоминание всех достоинств приводит к тому, что систему становится очень сложно позиционировать на рынке. Стремление резко расшириться по горизонтали и зацепить как можно больше непересекающихся целевых групп за счет дополнительных функций снижает степень проникновения и признания в каждой отдельной группе. “Как видно, эта программа не является профессиональным инструментом для …., но иногда может быть полезна в …” – вот что уготовано обозревателями подобным системам. Вы маркетолог-многорук-многоног, чтобы эффективно продвигать такие решения в дюжине ниш одновременно?
• Каждая новая функция – это, как правило, несколько сот строк кода, ради которых потребуется “предать” сложившуюся и верившую в тебя архитектуру и изменить оттестированные фрагменты кода. Редко когда удается сделать это удачно, т.е. не посадив ни одного нового бага. Причем, посадить баг в саму новую фичу – полбеды. Как правило, волшебным образом баги начинают появляться в других частях программы, казалось бы, надежных и проверенных вами, временем и пользователями. Любите насекомых?
• Возможность посадить баг при добавлении нового функционала заставляет нас при каждом релизе проводить регрессионное и интеграционное тестирование, объем и сложность которого от сборки к сборке растет отнюдь не линейно. Написание новых unit-тестов, придумывание новых тест-кейсов, найм новых тестировщиков – все это плата за новые “прикольные” и “полезные” фишки. Всегда ли она соизмерима с получаемым эффектом?
• Единожды добавив функцию в программу, практически невозможно избавиться от нее. Если ей начнет пользоваться хотя бы пара человек, они не дадут вам убрать ее. Напротив, они будут требовать ее улучшения, доделки, расширения. Они будут писать и звонить в вашу тех.поддержку и выносить ей мозг своим недовольством. Даже если вы понимаете, что требуемое улучшение не расширит круг почитателей этой фичи, вам будет очень тяжело общаться с этими людьми, не обижая их отказами. Может и не стоило тогда изначально намекать им на возможное вселенское счастье, подарить которое вы им на самом деле не в состоянии?
• Новая функция в подавляющем большинстве случаев потребует новой кнопки на давно похожей на витрину супермаркета панели управления или еще одного пункта в и без того стремящемся к бесконечности по длине меню. Стремитесь к “насыщенному интерфейсу”? Ну ну…
• В конце концов, думая о добавлении новой фичи, просто ответьте себе честно на вопрос: “Этим будет пользоваться кто-то еще, кроме тех полутора человек, которые спросили об этом за последние три года?”

Резать

Развивать продукт, не ухудшая его, – искусство… Ну хорошо, – ремесло, но ремесло непростое.
Вот некоторые инструменты, которые можно использовать для того, чтобы гармонично и сбалансировано наполнять продукт новыми функциями и при этом сохранять его фокус, простоту и эффективность.

Мозговой штурм “Какую функцию или элемент можно убрать из продукта?”

Раз в год собирайте свою команду на один час и просто выписывайте на доску все ответы на этот вопрос, не критикуя и не обсуждая варианты. Во второй час коротко обсудите каждый ответ, попросив его автора объяснить причину, по которой он предлагает избавиться от конкретной функции. Обещаю – вы узнаете много нового о продукте… и о своей команде 
За последний мозговой штурм мы записали порядка тридцати ответов. Спустя некоторое время около десятка функций из этого списка были либо удалены из продукта, либо запрятаны в самую его глубь. Хуже не стало.

“Мягкое” отключение функционала

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

Анализ общения с пользователями

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

Умение говорить “Нет” пользователям

Как говорил мой преподаватель по алгебраическим структурам, раздавая на экзамене двойки и тройки: “Всех не обогреешь.” Учитесь отказывать своим пользователям в их желаниях. Иногда, даже не надо оставлять и лучика надежды, что та или иная функция будет когда-либо реализована. Лучше отказать четко и сразу, чем пообещать, дать надежду и потом ее медленно разрушать. Чувствуете, что функция лишняя – отказывайте.

Вынесение функций в отдельный продукт или расширение

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