Избегайте фичеризма

[Перевёл статью Брэда Таунта, про то, как не поддаваться раздуванию сложности проекта.
В самое сердечко!]

Мне очень нравится термин «фичеризм». Я наткнулся на этот термин, когда читал замечательную статью «Почему я не использую Netscape», которую автор приписывает Бернду Пайсану. Он достаточно хорошо описывает нынешнюю индустрию «цифровых продуктов», но гораздо лучше её описывает термин «ползучий фичеризм»:

«Ползучий фичеризм» (сущ.) — состояние, при котором один или несколько человек, часто ЛПРы, постепенно увеличивают объём и сложность проекта до тех пор, пока проект не будет признан невыполнимым и впоследствии не будет отменен в ущерб всем участникам.

На протяжении всей моей карьеры в проектировании и разработке программного обеспечения я слишком часто сталкивался с этой проблемой. Основная проблема, связанная с попаданием в черную дыру «фичеризма», заключается в том, что некого винить. Кажется, что легко возложить всю ответственность на продакт-менеджеров или руководителей, но даже если именно они усложняют проект, говорить об этом должны разработчики и дизайнеры. Это требует командных усилий, поэтому вся команда должна быть начеку, чтобы избежать этого.

Простые рекомендации

Эти «советы» не идеальны, и они не будут работать для каждой рабочей ситуации. Надеюсь, их можно будет использовать в качестве основных рекомендаций, а затем расширить.

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

• Все члены команды, которые будут участвовать в разработке функции, должны определить её сложность (прим. пер. В оригинале «скоуп» — не смог подобрать лучший перевод). Слишком часто я вижу, что сложность функции, требующие участия дизайнеров, оцениваются исключительно разработчиками, и наоборот.

• Радикально ограничить объём каждой отдельной задачи¹. Каждая из них должна быть чёткой, небольшой и выглядеть почти тривиально.

• Заблокированные задачи. После того, как они согласованы, они не могут быть изменены². Всё, что необходимо добавить, должно стать будущей задачей.

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

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

Ползучий фичеризм может убить ваш продукт и моральный дух вашей команды. Избегайте его, как чумы!
___

[1] Это легче сказать, чем сделать. Обычно вам нужно будет разработать некоторую внутреннюю «балльную систему», чтобы вы знали, как эффективно делить функции.

[2] Устранение сложности, внесение изменений, не влияющих на рабочую нагрузку, или уменьшение тикета — это нормально, в разумных пределах.