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

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

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

Зачем?

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

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

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

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

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

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

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

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