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

22.05.2015 2 комментария

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

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

Зачем?

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

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

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

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

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

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

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

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

VN:F [1.9.20_1166]
Rating: 4.2/5 (5 votes cast)
Share

Онлайн

23.03.2015 14 комментариев

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

Я несколько раз за последние лет 5 пытался делать онлайновые базы в онлайне, но каждый раз сталкивался с техническими проблемами из-за молодости технологий.

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

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

Если же брать по гибкости интерфейсов и по удобству использования для новичков, онлайн уже опережает десктоп на голову из-за отсутствия необходимости что-то скачивать, устанавливать и настраивать.

С точки зрения поддержки онлайн тоже оказался гораздо приятнее, чем я ожидал: за счет реал-таймового мониторинга и немедленной правки багов любое, даже самое глобальное изменение в структуре приложения выходит на уровень «не больше одной новой ошибки в сутки» примерно за 4-5 дней. В десктопе, к сожалению, такой уровень достигался примерно за год из-за зоопарка платформ и временных лагов из-за невозможности моментально «выкатывать» исправленные версии.

В общем, если планируете что-то новое, я бы рекомендовал уже чисто онлайн. По поводу нативных приложений на андроид и айпад у меня пока мнение не сложилось: я просто подстроил интерфейс так, чтобы можно было более-менее удобно пользоваться и на мобильных браузерах. Мне лично достаточно, клиенты тоже пока не жаловались.

Ваш кэп-слоупок :)

VN:F [1.9.20_1166]
Rating: 5.0/5 (2 votes cast)
Share

Ловушка инвестора

24.07.2014 3 комментария

В психологии есть один интересный момент: мы ценим сильнее всего то, во что уже вложили много усилий или денег.

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

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

Единственный способ избежать ловушки инвестора — понимать эту особенность нашего мозга и примеривать ее на себя в нужные моменты.

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

Обычно желание продолжать бессмысленную работу маскируется под желание закончить, типа «не бросать же в самом конце, здесь и работы-то на пару недель осталось…» В итоге «пара недель» легко превращаются в пару месяцев, а то и лет.

А это — минус пару месяцев или лет ТВОЕЙ жизни.

VN:F [1.9.20_1166]
Rating: 5.0/5 (7 votes cast)
Share

Writer’s Block

02.07.2014

Вчера burnis, огромное ему спасибо, поднял мысль о том, что проектирование интерфейсов иногда проще начинать даже не с рисования, а с текстов.

Эта тема хорошо известна в сторителлинге как Writer’s Block (ступор писателя). Это когда ничего в голову не лезет, и чем больше ты заставляешь себя написать что-нибудь хорошее, тем тяжелее это получается.

Лекарство тут простое: начать писать хоть что-нибудь, пусть даже и не имеющее отношения к теме произведения. Этим ты как бы «включаешь» загнанное в угол творческое мышление.

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

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

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

Рекомендую попробовать, если еще не практикуете :)

VN:F [1.9.20_1166]
Rating: 5.0/5 (2 votes cast)
Share

Естественная и искусственная сложность

01.07.2014 2 комментария

Собственно, мысль не моя — вычитал ее в свое время в книже «97 Things Every Software Architect Should Know». Мысль из разряда «многое объясняет», особенно полезна для начинающих программистов.

Итак, естественная сложность проекта — сложность, обусловленная предметной областью. Я бы еще упростил определение — сложность, обусловленная интерфейсами. Допустим, если пользователю удобнее делать что-то именно так, а не иначе — стоит это сделать, даже если это добавит в проект «излишнюю» сложность.

Искусственная сложность проекта — сложность, обусловленная выбранными технологиями. Допустим, захотелось программисту «поиграться» с новомодными фреймворками, в итоге код перегружен тяжелым функционалом работы с мощной библиотекой. Из которой, по-хорошему, используется лишь 1% функционала.

Проблема — в том, что программисты склонны наращивать искусственную сложность, поскольку им нравится заниматься «настоящим делом», а не банальщиной. Это усугубляется тем, что изначально любой проект выглядит простым и параллельно-перпендикулярным. Искусственная сложность вроде как не вызывает вопросов: работает — и ладно.

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

Я — сторонник простых «велосипедов»: если что-то можно решить «в лоб» максимально простым способом без дополнительных библиотек — стоит сделать именно так. Причем ни в коем случае не пытаться сделать «универсальные» решения: если нужно хранить, допустим, список последних просмотренных страниц, нужно сделать хранилище именно под страницы, а не городить абстрактное хранилище абстрактных объектов.

«Работа на будущее» НИКОГДА не окупается. Принцип «лучше за день научиться, зато потом за полчаса долететь» превращается в создание сферических коней в вакууме, которые никогда в итоге не выходят за рамки изначального проекта, то есть весь тот «универсальный» функционал только осложняет тебе жизнь.

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

Простое правило: если ты пишешь или используешь код, который непосредственно не решает твои сегодняшние задачи, ты работаешь впустую. Проверено не раз.

VN:F [1.9.20_1166]
Rating: 4.6/5 (5 votes cast)
Share