Пристрелите фичу

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

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

Вот какие варианты усекновения фич мне встречались.

Снять с забега

Капитанский совет: перед тем, как отдавать функцию в разработку, проверьте — может она вовсе не нужна? Ориентируйтесь на ценность для потребителя. Три простых правила:

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

Наивные пользователи просят вернуть гугл-ридер

Поставить заглушку

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

Соберите обратную связь от целевой аудитории и решите, что делать с фичей дальше.

Упростить

Все любят усложнять: заказчики, аналитики, разработчики. Поэтому если у вас есть требования к системе, можете быть уверены — они переусложнены. Когда сроки кусают за попу, самое время радикально упрощать.

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

Медицинская клиника: вместо интеллектуального алгоритма автоматического подбора врача по симптомам — кнопка «Заказать звонок». Сотрудник легко справится, причем лучше любого алгоритма.[/notice]

Победитель среди форм записи на прием к врачу — чат с девушкой из регистратуры

Вариант второй: предусмотреть только основной сценарий, удобный для большинства случаев. И не поддерживать более редкие альтернативы.

CRM-система: сортировать заказы в списке по дате создания. Менять сортировку нельзя. 3% пользователей страдают, а остальным как-то пофиг.[/notice]

Изолировать изменения

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

Система мониторинга серверов Заббикс 3 стала визуально опрятнее, а функциональность не изменилась

Замести под ковер

У зрелой программы всегда есть участки, которыми нормальный человек без мата пользоваться не в состоянии (у сложных систем такие участки обычно составляют ~90%, но это отдельный разговор).

Просветленные дизайнеры и аналитики про такие куски знают и мечтают их переделать. Если получается — хорошо. Но если не успеваете, попробуйте скрыть плохую часть, чтобы снизить ее отравляющее влияние на остальную систему.

Отложить на потом

Вообще сейчас не делать, перенести на следующую итерацию. Слабый вариант: поскольку фичи нет вовсе, бизнес-задача не решена, и заказчик страдает.

Часто до отложенных фич дело не доходит никогда. Проверьте свой бэклог, если не верите.

Впихнуть невпихуемое

Любимый способ криворукого управленца. Урезать тестирование, поработать 60 часов в неделю, срочно нанять еще пять разработчиков, молча продолбать сроки, выпустить неработающую функцию, а потом с каменным лицом допиливать — вариантов много. Не делайте так.

Помните: при попытке впихнуть невпихуемое выпихивается ранее впихнутое

Ω План действий

1. Начните с потребностей, которые закрывает фича. Если их нет, выкидывайте.
2. Упрощайте реализацию и изолируйте изменения. Старайтесь сохранить пользу для потребителя.
3. Если все равно не влезает — заметите под ковер.
4. Отложите, если не осталось других вариантов.
5. Никогда не впихивайте невпихуемое.

Григорий Петров: Ползучий фичеризм