Victor Ronin's IT blog

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

Сейчас коротенько пробегусь по ним, а дальше может выложу рассусоленные детальные описания (если что-то потребует большей детализации).

По каждому пункту я указал свои ошибки (который, ой как хотелось бы не совершать).

1. Опыт работы над продуктом в наемном виде не равен опыту создания своего продукта.

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

Когда я начинал работу над продуктом, то я думал, что я знаю достаточно много о продуктопроизводстве (так как последние 4 года работал в продуктовых компаниях) и наступлю на меньшее (чем оказалось) количество грабель.

2. Всегда нужно иметь ПОЛНЫЙ список задач, который нужно сделать до выпуска. И когда я говорю ПОЛНЫЙ, я таки имею в виду ПОЛНЫЙ.

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

Хотя я и работал по какому-то упрощенному Scrum процессу, записывая дела, но все равно, по приближению к release, я начал обнаруживать, что 20% оставшихся
задач таки хотят поесть 80% времени, так как выплывают разные отложенные, забытые или незапланированные задачи.

3. Нужно все делать Just In Time.

Когда работаешь над своим продуктом, то вероятнее всего количество ресурсов очень ограниченно. Нужно делать всего самое важное и только тогда, когда оно таки уже нужно.

То есть, с одной стороны, нельзя (точнее можно, но не выгодно) тратить два месяца на написание супер-пупер расширяемой архитектуры, которая дай бог будет использована к версии 3.0. C другой стороны нельзя и откладывать на потом решение важных проблем, так как их таки придется решать до выпуска продукта.

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

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

4. Выбор идеи для продукта

Если вы надеетесь получить инвестиции (или вложить много своих денег/времени), то вы можете работать только над большими идеями (либо которая должна собрать по $100 от миллиона людей, либо $1M от 100 компаний). Под маленькую идею вы не получите инвестиций, а свои деньги/время только потратите.

Если вы собираетесь потихоньку раскручивать продукт сами не беря денег у других и не вбухивая свои, то вы можете начинать только с маленьких идей ($20 долларов от 500 человек). На большую идею у вас просто не хватит времени и денег.

Этот пункт спорный… Но, мне кажется что большинства компаний так оно и будет работать.

Я выбрал не слишком удачный вариант. Идея слишком мала, чтобы в нее кто-то вложился, но слишком большая, для того, чтобы первую версию можно было сделать быстро.

5. Размеры релиза

Я бы рекомендовал до начала работы над продуктом делать релиз N0. Внутри этого релиза вы должны сделать все, чтобы доставить Hello World макет вашего проекта от вашего рабочего компьютера покупателю в товарном виде.

То есть, вы должны собрать, выложить, иметь документацию, website и т.п.
Это слегка противоречит принципу JIT, но зато очень помогает написанию списка задач.

Внезапно вы обнаружите, что желательно иметь build машину, которая собирает ваши изменения, какие-нибудь скрипты, документацию, веб сайт и т.п. Гораздо лучше обнаружить все эти детали в релизе номер 0, чем получить их незапланированными задачами релиза N1.

Касательно релиза N1. Выберите, ту функциональность которую вы хотите включить в него. Разбейте на три раздела — обязательно, желательно и возможно. Выкиньте желательно и возможно. Теперь разделите обязательно на две части — супер обязательно и просто обязательно. Просто обязательно отложите на релиз 1.5. Над оставшимся супер обязательно — начинайте работать.

6. Заручитесь поддержкой своей жены/мужа/девушки/парня/собаки/рыбок.

Вероятнее всего вам предстоят длинные вечера в которые вместо того, чтобы расслабляться, вы будете матюгаюсь исправлять какие-нибудь левые баги, писать документацию и т.п.

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

Понимание и поддержка людей, которые находятся рядом очень-очень помогает.

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

7. Используйте Open Source

Сейчас гигантское количество разного open sourc’а, который можно применять в коммерческих продуктах.

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

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

8. Время на НЕ разработку

Последнее, что хочу сказать в этой статье, что не бойтесь тратить время на НЕ разработку (маркетинг, поиск open source продуктов, поиск похожих продуктов, их опробование и т.п.) В большинстве случае час потраченный на сторонюю деятельность сокращает на 5 часов разработку.