Самоуничтожение продукта

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

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

Зачем?

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

«Полировка» любой фичи занимает, по моей оценке, от 300% до 1000% от времени, затраченного на ее первую (абсолютно рабочую, к слову) версию. Мало кто делает подобные замеры, поскольку это время размазывается равномерным слоем по всему жизненному циклу продукта. На практике это обычно выглядит как переход из стадии: «о, круто» до «бля, а здесь вот криво, нужно поправить» несколько недель или даже месяцев после ее первого релиза.

То есть, добавив новую «сырую» фичу, потратив на нее всего 1 день, ты, по факту, только что «заработал» себе долг в размере от 3-х до 10-ти рабочих дней, необходимых на доведение ее «до ума». Потратил неделю на новые фичи — получил себе от месяца до трех месяцев геморроя. Я не утрирую.

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

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

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

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

Внимание к мелочам, к деталям, одним словом. Да, это — геморройное занятие. Но, по моей практике, окупается сторицей. Чего и вам рекомендую :)

VN:F [1.9.20_1166]
0 голосов
2 комментариев
старее
новее большинство голосов
Межтекстовые Отзывы
Посмотреть все комментарии
Сергей

Вспоминается фраза про хорошего дизайнера(проектировщика), который вырезает скальпелем все маргинальные фичи, игнорируя крики «постойте, моя мама один раз пользовалась этой хуйнёй». Прошу прощения за мат в цитате.

Konstantin

100%. А в идеале продукт должен вырождаться в окно с единственной кнопкой «работать».