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

С бизнес точки зрения – это чушь собачья. Не нужен ни идеальный код, ни идеальная документация, ни идеальный дизайн. Нужен продукт, который продается.

То, что я видел и на что и сам наступил, что люди думают, что если они выпустят первую версию плохую – то это полный капут и крышка. Люди увидят эту версию, найдут в ней баги и больше никогда-никогда не купят ваш продукт. Причем естественно об этом узнает весь мир, напечатают на первой полосе в New York Times и по телевизору будут показывать видеоролики о том, какой же у вас ужасный продукт.

На самом деле все поставлено с ног на голову в этой мысли.

Во первых, даже если продукт не понравиться кому-то, то они не будут трубить об этом. Когда вы в последний раз рассказывали своим знакомым о каком-нибудь продукте (первой версии), который вам не понравилcя? У людей времени нету даже о понравившихся рассказывать…

А во вторых. Выложить продукт и начать его продавать – это единственный метод получить деньги и отзывы (да в том числе таки и негативные).

По моему нынешнему разумению идеальная последовательность такова:
а) Организовать Adwords и направить их на “Coming soon” website. Вы тратите некоторое количество денег, зато узнаете о интересе к вашему продукту, еще даже не написав и строчки кода.
б) Вы делаете (заказываете) очень простой website и предлагаете купить первую версию вашего продукта которая выйдет через 3 месяца или подписаться на сообщения о выходе. Опять же получаете список заинтересованных людей, а в хорошем случае еще и деньги.
в) Делаете минимальную (абсолютно минимальную) полезную первую версию и выпускаете ее. Смотрите, на то, как все движется.
г) А теперь в тот момент, когда капают какие-то мелкие денежки, приходят (изредка) письма с предложениями, замечаниями, вы можете улучшать продукт, сайт, играть с adwords и другой рекламой.

Замечу, что программисты (включая меня) очень склонны таки переворачивать эту последовательность) и превращать ее в), б), а), г).

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

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

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

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 часов разработку.

У меня большущая просьба. Мой продукт(ик) подходит наконец к готовности для выпуска в виде версии 1.0 и было бы здорово получить первую волну отзывов/идей/комментариев.

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

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

Пожалуйста, напишите мне на vronin at consultant.com для дальнейшего обсуждения деталей. Заранее спасибо.

И пользуясь случаем, хочу сказать спасибо Сергею Корнилову, который подкинул мне идею попросить помощь. А также, хочу упомянуть о сайте, развитием которого он занимается – AskDev.ru. Сайт предназначен для программистского обмена опытом и заточек для русскоязычную аудиторию. Рекомендую заглянуть.

P.S. Само собой, если вы хотите использовать факт того, что вы участвовали в бета тестировании в своих целях – то можете делать это. Также вам будет предоставлен лицензи(я/и) на продукт, когда он будет выпущен.

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

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

Просто напишу пункты из той статьи, к которым комментарий относится

>6) Идея должна быть размеров, которые можно потянуть
>2) У идеи должен быть рынок.
>1) Идея должна решать реальную проблему.
>5) Идею нужно иметь возможность сделать лучше чем конкуренты.

Охохонюшки…. Я с своим продуктом конкретно влип по всем статьям.

Деньги и время, деньги и время, деньги и время… Блин, эту мантру нужно повторять каждый день. В тот момент, когда она наконец дойдет до мозга, наступит счастье.

Даже супер идея и супер реализация не доведенная до конца вероятнее всего будут стоить ровно круглый нолик.

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

Так вот “деньги и время” должны стать коэффициентом, на который вы должны домножить абсолютно все. Есть идея, которая должна покорить рынок в 5 миллиардов баксов? А теперь домножьте на свои накопления в $123 и по полчаса в день по вечерам, которые вы собираетесь вложить. Умножили? Так вот, результат равен нулю.

Этот самый коэффициент точно также относится относится и к тому, что идея должна решать реальную проблему. Может ваша идея и решает
проблему, но вот реализация = идея*(деньги+время). И если второй множитель маленький, прощай решение проблемы.

Аналогично и с конкурентоспособностью.

Так, что повторяю еще раз – деньги и время.

На самом деле, статья – это мой вопрос вам. Как вы считаете, почему создание продукта такое сложное дело?

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

Что скажете по этому поводу?

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

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

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

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

А еще забавно – это смотреть не вперед, а назад. Действительно, когда только начинаешь делать продукт, то все то что впереди непонятно/неизвестно и затянуто туманом. Но с другой стороны, можно легко посмотреть назад и четко видеть путь пройденный другими компаниями и из этого делать вывод.

Вот например, так компания в которой я работал, эдак лет с 10 назад сделала маленькую утилитку для выборочного шифрования файлов на SD карточке для Palm. Ну, что, какой потенциал у этой идеи? Я думаю все скажут, что откровенно маленький.
А теперь глядим дальше. Где-то 8-9 лет назад она эту утилитку расширила и сделал небольшую программу для Palm, которая позволяет шифровать данные и на устройстве и на карточке, плюс показывать пароль. Уже конечно лучше, но, программа продается по $20 на сайтах а-ля Handango и тоже пока не слишком выглядит мощной.

Движемся дальше, и где-то лет 7-8 назад, количество функциональности нарастает – появляется пароли на отдельные программы, запрещение использования IR портов, добавляется Desktop часть по управлению настройками (что разрешать, что запрещать). Уже звучит еще более интересней.

Где-то еще через год – появляется WinMobile версия. Количество функциональности и количество поддерживаемых телефонов ползет вверх. Понемногу все это начинают продавать небольшим компаниям (то бишь оптом, а не в розницу).

Далее, где-то 5 лет назад в эту смесь добавляются венчурные капиталисты, которые вливают деньги в компанию и перестраивают ее на путь enterprise mobile security. Продукт перестает продаваться в розницу и переходит чисто на опт. При этом все продолжают расти количество функций и количество поддерживаемых устройств.

Следующие где-то два года идет бег на месте, так как на рынки мобильных платформ большой сдвиг. PalmOS с четвертого перешел на пятый, вышел WinMobile 5.0 и компания просто гребет против течения, чтобы не унесло в открытое море. И где-то три года назад, компания переходит с режима центральная программа Desktop, на центральная программа в Web, плюс появляются возможность централизованного просмотр информации о том, какие устройства защищены, а какие нет, функции по удаленной работе с устройствами.

И где-то в течении прошлых лет трех, парадигма меняется с режима “шифрование на устройстве”, на “управление безопасностью мобильных устройств в компании”. Соответственно, заказчики уже не мелкие голожопики, которые покупают по 1-3 копии, а серьезные фирмы, которые покупают продукт очень крупных оптом. Плюс, к этому времени уже очень много компаний обеспокоины тем, что потеря мобильника с 4Gb памяти с кучей почты содержащей конфиденциальную информацию ни чем не уступает уже потери notebook’а.

А теперь, возвращаемся назад – утилита для шифрования SD карты для Palm и продукт с десятком разных программ, работающий на многих платформах, который занимается управление безопасностью для мобильных устройств всей компании. Ведь, сразу понятен абсолютно разный размах и перспектива. А ведь на самом деле – это одна и та же компания.

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

Так что буду потихоньку эту тему раскапывать.

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

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

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

А теперь, о том, что я имел ею в виду

- Первое и самое основное (того, чего в схемке не указано). У каждой позиции должен быть четкий список обязанностей и ответственности. Директор по продажам не должен садиться подпедалить код,
а технический менеджер не должен мотаться по всему миру собирая у заказчиков требования.
Я кстати об этом писал в статье “О разделении обязанностей между технарями и продавцами.”

- Второе. Это размер фирмы. Естественно, нарисованная фирма скорее выглядит как что-то эдак размером человек 500. Скажем так, многие из этих должностей могут быть объедененны в одном человек для небольшой фирмы. Главное, что можно объеденять должности внутри одного подразделения, но не между ними.

То есть может быть и программист и главный программист в одном лице. И product manager с business director’ом в одном лице. Но уж никак не главный QA и sales director в одном флаконе.

Теперь можно уже и по структуре. Основное, с чего я вообще начал рисовать эту схему с Product Manager’а. Звучит конечно смешно, но это самый главный человек в компании. C одной стороны он находится достаточно низко в структуре, чтобы влиять на детали, с другой стороны достаточно высоко, чтобы выбирать направление. В этому его уникальность и ценность одновременно.

Итак, самая основная его идея в том, чтобы собирать все хотелки сверху (от CEO, от Sales (это скорее сбоку)), идеи о том куда двигаться в будущем (от маркетинка), крики и плевки от заказчиков (через отдел support’а) и пинки от engineering’а. После того, как все собрано – все приоритезируется и выдается вниз engineering’у на исполнение и вверх отчетность о приоритетах.

Замечу, дальше в зависимости от удачности или не удачности приоритезации именно product manager’ов (включая business development director) должны либо гладить по голове, либо гладить утюгом.

То есть к ним идут все ниточки входных сигналов и от них идут все ниточки выходных сигналов. Еще раз замечу, не к CEO, а к ним.

Теперь, расходимся от них концентрическими кругами.

В случае если product  manager’ов несколько – то Business Director как раз должен руководить, тем чтобы ниточки по нужным направлениями шли к нужному product manager’у и в ответ выходили нужные ответные сигналы.

Кстати, замечу, что если входные сигналы имеют право быть аналоговыми (то есть в достаточно произвольной форме), то выходные сигналы – все должны быть очень цифровым (четкий формат в виде документа с требованиями для инженеров, документа с планом и сроками для sales и т.п.)

Движемся дальше. Когда сигнал опускается до director’а engineering’а – то он обычно заключается в крупных проектах и это уже его дело разбить это напроекты поменьше, раздать менеджерам проектов х контролировать и т.п. В общем-то director engineering’а и project manager’ы это как раз те самые менеджеры среднего звена о которых я писал уже несколько раз.

Дальше движемся вверх по схеме. CEO по большему счету должен быть нужен в фирме для трех вещей

а) В случае наличия инвесторов – общение с ними

б) В случае если он основатель и задумщик идеи – он должен кормить этими идеям product manager’а. Хотя в идеале, тогда он должны перейти на должность Business Development Director и отдать руль CEO кому-то другому.

в) В случае если какая-то ветка работает плохо, разобраться в причине и уволить ее.

Ну и плюс сюда можно приписать воодушивительные выступления перед фирмой.

По большему счету это все, за что он должен отвечать

To be continued…

P.S. Круто… Первая картинка в блоге

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

Но, перед тем как начать делать продукт, найдите в нем пять недостатков. Причем не для отмазки, а именно настоящих 5 недостатков. Если вы их не можете найти сами, спросите друзей… потом врагов.

Только после того, как вам хорошенького “подгадили” идею, раскритиковав ее достаточно, то тогда уже взвешивайте “за” и “против”.

P.S. Кстати, идеальных продуктов без недостатков в идее, просто не существует.

О чем это я… Ах да. Так вот, фактически никто из подражателей не получил и 1 цента прибыли.

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

Это я к тому, что когда вы читаете как гарантировано заработать денег (пиша plugin’ы по Facebook или разрабатывая web 2.0 магазины), то на самом деле – это значит, что на этом заработать уже нельзя.

P.S. Добавление и разъяснение. Все бросились штурмовать то, что есть удачные подражатели. Я с этим не спорю – таки есть удачные подражатели, однако вероятность выживания в не слишком занятой нише 5%, вероятность выживания в занятой нише скажем 1%. Один из методов, повысить свою вероятность выживания, копировать, но позиционировать для другого рынка (например русскоговорящий vs. англоговорящий).

Плюс, ключевая фраза в статье был: “когда вы читаете как гарантировано заработать денег”. То есть, когда уже туча людей увидела, что можно скопировать и заработать и уже это сделали. К этому моменту ниша становится перенасыщенной.

P.P.S. Пожалуйста прочитайте мое пояснение к этой статье тут: “Либо встречу, либо нет“.

- Написание чего-то нового

- Исправление чего-то старого

Чаще всего, когда вы (или любой другой разработчик) делаете одно, то вы (в тот же момент времени) не делаете второго.

Достаточно часто фирмы начинают погоню за все новой и новой функциональностью позволяя качеству проекта постепенно съезжать. Зачастую это даже дает некое возрастание прибыли, так как продукт становится более конкурентным, и подписываются многие сделки, которые не могли быть подписаны, без новой функциональности.

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

По большему счету, выпуск продукта можно сравнить с бегом. Если вы планируете, чтобы ваш продукт жил 5 лет, то лучше действовать методикой стайера – бежать медленно и равномерно. Когда вы бросаетесь, делать кучу новой функциональности – то это скорее спринтерство. Да, вы можете пробежать полгода быстро, но после этого три года вы будете запыхавшись отходить от этих пол года.

Так, что не позволяйте планке качества падать в вашем продукте.