Как создать коробочный программный продукт

Мы будем говорить:

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

О себе

В сфере разработки на 1С я с 2007 года.

Основал компанию MoscowSoft – у нас удаленная разработка, и команда у нас тоже удаленная. Мы специализируемся на универсальных готовых переносах данных между различными программами 1С, но это не единственное наше направление, есть и другие разработки.

Мы уже более 5 лет активно сотрудничаем с Инфостартом и за это время добились того, что находимся на 3-м месте по продажам коммерческих продуктов.

Почему стоит разрабатывать свои программы

Зачем заниматься чем-то своим, особенно если у вас уже есть наемная работа? Чем привлекательно создание своего собственного продукта?

Даже если из этого не вырастет какой-то большой истории, вы получите огромное количество плюсов:

• В первую очередь, вы как разработчик 1С можете создать свой бренд, и для работодателя при собеседовании это будет уже огромный плюс. Вы же понимаете, что топ-100 рейтинга на Инфостарте – это не пустой звук для многих директоров по ИТ. Вы получаете огромные преимущества.
• Когда вы начинаете заниматься чем-то своим, вы получаете большой опыт в смежных областях – маркетинг, продажи, отношения с партнерами, отношения с сотрудниками, официальное юридическое оформление своей деятельности. Этим всем вы также будете заниматься.
• Кроме того, у вас растет и профессиональная квалификация как разработчика. Потому что не секрет, что на наемной работе очень часто (если это не франчайзи, хотя и во франчайзи такое тоже есть) задачи однотипные. Вы пользуетесь каким-то ограниченным стеком технологий, а что-то новое пока не используете. Но в своих проектах вы можете это ограничение снять, потому что в этом случае только рынок, только ваша фантазия и ваши способности вас могут ограничить, и больше ничего.
• Немаловажный вопрос, что вы можете получать финансовое вознаграждение за свои разработки, если с самого начала будете распространять их как коммерческие решения.
• И еще один момент (он не очевидный, но очень важный, на мой взгляд) – когда вы создаете публикацию на Инфостарте, то получаете обратную связь от сообщества. Вы получаете ее иногда жёстко, но это позволяет сохранять адекватность, позволяет видеть, какие тренды и идеи владеют рынком и людьми, и в зависимости от этого вы будете более четко понимать ситуацию, сможете двигаться и развиваться в том направлении, куда движется весь мир.

Как выбрать идею

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

• В первую очередь, я думаю, многие с этим сталкивались, это когда вы свою заказную разработку адаптируете под коробочное решение.
• Следующий вариант: есть популярный способ – Customer development – это общение с вашими нынешними клиентами. Вы делаете опросы, сбор требований, пожеланий и некий анализ этой информации, ее структуризацию. Очень здорово будет, когда вы увидите, что есть множество клиентов, которые просят одно и то же, им нужны одинаковые разработки. И возможно, это именно то, чем вам стоит начать заниматься.
• Популярная история, когда продукт делается для своей внутренней автоматизации, а в дальнейшем предлагается рынку (конечно, тоже после адаптации).
• Кроме того, вы можете провести маркетинговое исследование – вы можете анализировать биржи фриланса, теги на Инфостарте. Сейчас часто выпускаются публикации типа «Программные продукты, которые будут востребованы в ближайшее время». Это все тоже позволяет оставаться в тренде, понимать, что происходит на рынке.
• Мозговой штурм – еще один способ выбрать идею для продукта. Его можно проводить вместе с командой или в одиночку. Но когда вы будете его делать, все равно будете опираться на свой опыт, на то, что вы знаете о рынке.

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

Но все, что вы в результате поисков найдете, это всего лишь гипотезы. Нет никакой гарантии, что идея выгорит. А что мы делаем с гипотезами? Мы их проверяем.

MVP

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

• Во-первых, есть представление, что MVP – это что-то, сделанное на коленке, неказистое, неудобное, когда люди недовольны, плюются. Так быть ни в коем случае не должно. MVP – это то, что несет ценность. Да, у приложения может быть ограничена функциональность, но оно должно работать замечательно, у людей должны появляться положительные эмоции. Только в таком случае возможна какая-то дальнейшая жизнь продукта. Если вы создали что-то неприятное, оно в дальнейшем не вырастет.
• Учтите еще: даже за MVP нужно сразу брать какие-то небольшие деньги. Это показатель того, что вы даете людям ценность, за которую они готовы заплатить какую-то небольшую сумму, но уже реальные деньги.
• Следующий момент: минимальный жизнеспособный продукт – это не обязательно прототип. Расскажу историю про создание первого менеджера файлов Дропбокс для их синхронизации между различными компьютерами. Когда создатели планировали этот продукт, они хотели исследовать рынок. Для этого они создали видеоролик, в котором демонстрировали, как файлик перемещается, синхронизируется и появляется на другом компьютере. Этот видеоролик они отправили в интернет, и уже за первую ночь его посмотрели около 7 тысяч раз. Это был огромный трафик, который рос с каждым днем. И разработчики поняли, что есть спрос именно на такое новое решение. Но на тот момент у них не было прототипа. Видео, которое они сделали, было рендером, имитацией. Кстати, MVP за границей называют «Методом волшебника страны Оз» – есть ширма, за которой создаются какие-то оптические иллюзии, а для пользователей все выглядит как готовое. Именно так может выглядеть в вашем случае MVP – ведь оно нужно для того, чтобы можно было проверять много различных гипотез быстро, не тратя на это очень времени. И только если рынок хорошо отреагирует, можно ставить вопрос о создании программного продукта.
• Стоит заметить, что коммерческая публикация на Инфостарте сырого решения запрещена, но никто не запрещает вам выкладывать свою бету или альфу за стартмани. И это замечательный способ проверки. Также обратите внимание, что для проверки гипотез Инфостарт дает замечательную возможность: вы попадаете в еженедельную рассылку и на самый верх ленты, когда вы публикуете что-то свое. Это сразу дает вам большой охват. Публикация на каком-то своем сайте не даст так быстро такого большого трафика. Пользуйтесь этой возможностью, это абсолютно бесплатно.

Развитие программного продукта

Допустим, мы протестировали несколько идей, выбрали самую перспективную, самую интересную, и выпустили первую версию продукта.

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

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

• В первую очередь здесь понятная для всех схема – сбор обратной связи (Customer development): собираем самые востребованные хотелки пользователей, реализуем их в ближайших релизах.
• Но чтобы корректно выбирать, вам нужно смотреть на рынок стратегически и понимать, что происходит – не только следовать требованиям ваших клиентов, но и думать самостоятельно. Почему? Генри Форд однажды сказал: «Если бы я просто спросил людей, чего они хотят, они бы сказали, что хотят более быструю лошадь». Чтобы не создавать лошадь, а создавать ракеты или хотя бы автомобили, нужно что-то предугадывать самостоятельно, а не только действовать по требованиям ваших текущих клиентов.

Защита от пиратов

Говоря про программные продукты, про то, как с ними работать, нельзя пропустить момент защиты.

• Хотя лично я считаю, что внимание пиратов еще нужно «заслужить»: нужно создать такой «бриллиант», который будет принят рынком, будет известен на всю Россию. Когда вы вырастете до такого размера, вопрос защиты станет одной из ваших текущих задач, и тогда ее уже надо будет решать. На мой взгляд, не нужно решать ее в самом начале, когда у вас еще ничего нет.
• Но, конечно, свои разработки нужно регистрировать – можно получить патент, можно зарегистрироваться в реестре отечественного ПО. Это актуально и для существующих уже решений.
• Есть еще более простой способ – на начальных этапах можно просто воспользоваться юридической службой Инфостарта. Если на каких-то форумах выкладывают ваше решение, можно просто туда жаловаться и ни о чем больше не думать. Дальше всю работу по защите авторских прав за вас сделают совершенно бесплатно, если вы являетесь партнером Инфостарта.
• На первых этапах, когда у вас еще не такой большой программный продукт, важнее проработать процесс постоянного развития, выпускать новые релизы. Чтобы это не было просто теорией, расскажу, как мы работаем. Мы представляем универсальные переносы, и поскольку фирма 1С обновляет релизы программ, мы тоже выпускаем обновления. Мы предоставляем обновление в автоматическом режиме с помощью веб-сервиса и при этом проверяем, действует ли у данного клиента подписка. Это работает автоматически, очень просто, это невозможно взломать, потому что мы предоставляем файл только после проверки подписки.

Масштабирование

Тема масштабирования для меня является наиболее актуальной – я над этим задумываюсь каждый день.

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

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

• В этот момент у вас уже есть своя проторенная дорожка: вы знаете, какие идеи позволяют вам создавать успешный востребованный продукт, вы знаете, как вы проверяете эти идеи. Возможно, для профессионала, для методолога, теоретика этот путь будет выглядеть не самым оптимальным, но это тот путь, который вы прошли, и вы знаете, что он работает.
• Теперь этот путь нужно максимально масштабировать, повторяя историю, которая у вас работает – делать как можно больше таких продуктов, развивать функциональность, которая требуется клиентам.
• Что такое стартап? Это – временное предприятие, созданное с целью поиска работающей бизнес-модели. Если вы создали такую бизнес-модель, которая позволяет вам этот путь проходить от начала до успешного продукта раз за разом, нужно ее масштабировать. Нужно развивать свою команду, увеличивать ее размер, нужно создавать максимально большое количество продуктов. Это позволит вам создать полноценную компанию.

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

Почему мы выбрали именно такой способ? Чтобы увеличить прибыль. Прибыль – это средний чек, умноженный на количество продаж.

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

Роли менеджера

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

Но что происходит, когда вы начинаете расти, когда ваш программный продукт становится серьезным и масштабным? Дальше перед вами встанет проблема:

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

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

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

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

Неудачи и работа над ошибками

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

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

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

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

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

Конкуренция и риски

Хочу еще поговорить про путь предпринимательства. Допустим, у вас много своих проектов, вы еще работаете на наемной работе. Но тут надо кое-что учитывать.

• По данным статистики, большинство компаний не проживает и 5 лет. Конечно, есть компании-однодневки, которые закрываются в течение 3 лет, но все равно эти данные страшно звучат. Но что такое большинство? Большинство – это больше 50% процентов. Тогда можно сказать, что 49% юрлиц в России, даже с учетом однодневок, проживает более пяти лет. Такая статистика звучит лучше.
• Как видите, конкуренция есть, но на успех влияют множество факторов. Представьте, два человека открыли новые рестораны.
• Первый получил наследство, раньше в ресторанном бизнесе не работал, ничего в нем не понимает.
• А второй человек 10 лет работал управляющим ресторана, он знает, какие должны быть затраты, какая должна быть система оплаты труда, какие должны быть расходы.
• Вы же понимаете, что у каждого из них будет своя история в дальнейшем, и сложности будут возникать разные. Но скорее всего, у второго больше шансов работать в этом бизнесе успешно.
• Здесь может сработать стратегия «голубого океана». Если вам удастся занять свою нишу на высококонкурентном рынке, вам будет легче сделать свой продукт востребованным.
• Есть пути минимизации рисков. Например, если вы – разработчик 1С, который трудится по найму – можете развивать собственный коммерческий продукт по вечерам в свободное время. Если это продукт для какой-то востребованной ниши, то рано или поздно вы будете в выигрыше. При этом риски у вас минимальные. Вы можете очень долгое время развивать свой продукт, создавать новые продукты, масштабировать, расти, пока не нащупаете то, что приносит действительно хороший доход, то, что действительно востребовано рынком. В какой-то момент у вас произойдёт следующее: каждый час вашего рабочего времени, которое вы уделяете своим задачам, своим проектам, будет приносить больше денег, чем на основной работе. В какой-то момент вы станете зарабатывать больше, чем на основной работе. И когда вам будет выгоднее уйти с наемной работы, вы уйдете. Я понимаю, что этот путь не для всех. Не на каждой наемной работе получится совмещать – где-то это запрещено, кому-то может банально не хватать времени и сил. Но мы же знаем, что многие разработчики создают свои какие-то программы, разработки для своего удовольствия, это хобби. Так почему бы не делать их коммерческими?

Я так красиво рассказал про этот замечательный путь – все так прекрасно, даже рисков никаких нет: вы просто ищете, придумываете, работаете.

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

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

Вопросы

• Бывают ли у вас ситуации, когда заказчик заказал разработку для обмена данными между какими-то системами, вы ему ее сделали, а потом эту разработку продаете другим? Как вы в этой ситуации поступаете?
• Я с этого и начинал в свое время. Осенью 2014 года два заказчика с перерывом в два месяца заказали переход из «Комплексной автоматизации 1.1» в «Бухгалтерию 3.0». Но чтобы все было этично и честно, нужно на этапе договоренности обсудить, что исключительные права будут у вас. Это нужно прописать в договоре.
• Почему я спросил? Получается, что человек заплатит больше денег, чем, если бы он потом купил коробочный продукт. Ведь индивидуальная разработка дороже стоит. Бывали такие моменты?
• Но заказчику ведь это нужно «здесь и сейчас», ему не нужно через год, когда у вас будет готов коробочный продукт.
• То есть это нормально? Никто не обижается?
• Смотрите, вы сделали какой-то частный продукт для конкретного заказчика. Чтобы упаковать продукт – создать универсальное решение – нужно в 3 раза больше ресурсов. Мы, например, до сих пор исправляем какие-то замечания, потому что у заказчиков возникают какие-то частные случаи учетных политик, и мы каждый раз дорабатываем перенос с учетом всех этих частных случаев.
• Если вы разрабатываете программный продукт, отталкиваясь от опыта на проектах, то, как правило, руководитель проекта или архитектор этого решения входит в состав разработчиков программного продукта. Но со временем они начинают растекаться, и в команде продукта, если она достаточно долго существует, и у вас достаточно большой рынок, необходимо выделять две отдельные роли – разработка программного продукта и внедрение программного продукта, работа с ним на рынке. Сталкивались ли вы с этим? И если были такие переходы, как вы это решали, и какие роли были в ваших командах? И еще очень важный вопрос – как происходит сбор обратной связи и пожеланий заказчика?
• Я расскажу, как это у нас работает. Есть ответственный за каждый перенос данных либо за самые масштабные решения – там поделены участки. Это люди, которые развивают продукт. Те, кто внедряет, как правило, пользуются этими правилами переноса и просто согласовывают изменения. Но когда не получается выполнить проект с помощью универсального решения, тогда можно дорабатывать правила. И если это какой-то частный проект, не универсальное решение, то внедренец может менять все самостоятельно.
• Скажите, пожалуйста, каким образом вы фиксируете и храните техническую документацию – описание всех тех разработок, которые вы ведете. Это регламентно как-то происходит, например, есть какой-то ответственный сотрудник?
• В нашем случае максимально подробным описанием решения является публикация на Инфостарте и на нашем сайте. Мы из этого исходим. Там доходит до того, что есть перечень поддерживаемых видов документов, которые входят в решение. Если заказчик не находит что-то, он просит добавить. Человек, который ответственен за данное решение, даже не имеет доступа к этой публикации, это все проходит через меня – и описание, и вся техническая информация. Что касается внутренней документации, как я уже говорил, у нас есть обучающий курс для новых разработчиков, там есть раздел «Часто задаваемые вопросы», куда включаются вопросы от всех обучаемых.
• Как вы продвигаете свои решения кроме Инфостарта?
• У нас есть баннер на Инфостарте, мы таким образом поднимаем публикацию. Кроме того, стандартным способом продвигаем свой собственный сайт: есть внештатный маркетолог, запускаем рекламу в интернете. Но на самом деле собственный сайт и реклама не очень работают, не сильно помогают снять возражения клиентов. Допустим, человек никогда о вас не слышал, ему нужно какое-то решение, но только по одному сайту и по рекламе он вряд ли согласится платить вам большие деньги. Потому что он вас не знает, он вам не доверяет. Гораздо легче снимать возражения клиентов и завоевывать их доверие на Инфостарте, где видна дата публикации, видно количество звезд, видны комментарии. От своей площадки тоже нельзя отказываться, но это более сложный процесс развития.

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.