Как мы создавали SaaS-проект (о проблемах it-стартапа на этапе разработки)

Трудно ли сделать SaaS-проект с нуля и под ключ? – Отвечу так: если бы сегодня передо мной стоял вопрос, браться за него или нет, то я НЕ уверен, что согласился бы. Хотя сейчас, после недавнего запуска такого проектa, есть немало чего положительного. Но все равно не уверен, что кинулся бы в этот марафон вновь. Может просто потому, что еще не успел перевести дух? А может, оглядываясь назад, меня страшит пройденный путь?.. Ответ, наверное, где-то посередине.

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

Конечно, нельзя начинать что-то новое без веры в успех. Однако, вера стартапера в свои силы должна быть обоснована.

Итак, шел 2014-й год. Начало лета. На очередном совещании мы решили: новому онлайн-сервису быть! Мы – то есть сотрудники небольшой региональной компании, оказывающей услуги в области управления персоналом.

За 13 лет существования компании многое чего произошло. Были успехи и неудачи. Как у всех. Кризис конца нулевых дал нам возможность сосредоточиться на собственных разработках, которым мы ранее из-за повседневной текучки не могли уделить должного внимания. Разработки были связаны с созданием инновационной методики и софта для изучения трудовой мотивации. Много времени и прочих ресурсов было потрачено. Итогом стало появление уникального программного продукта.

Вначале жутко радовались. С одной стороны, продукт сулил неплохие перспективы. Однако… он был коробочным.

А на дворе уже — эра облачных технологий. Начинка – хороша, а it-решение на ее основе становилось морально устаревшим. Мы понимали, что в реальной перспективе масштабных продаж тут не добиться.

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

Становилось ясно – требуется переориентация и перенастройка наших НИОКР-овских мощностей.

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

Сервис должен был отвечать трем основным требованиям:

1. иметь хорошую начинку (методологию),
2. быть простым и удобным в использовании,
3. быть доступным (по цене) почти любой компании.

Почему так? – Пойдем по порядку.

Хорошая методология в основе продукта – это, во-первых, шанс на долгую прописку в ТОПе аналогичного софта, читай, лояльность пользователей. А во-вторых, это потенциал, на базе которого можно продолжать развитие продукта, его качественное усовершенствование. Ведь когда изобрел сам, тебе и флаг в руки – надстраивай! Ну и, в-третьих, сейчас обозначился тренд на отечественные технологии. А на данном рынке были представлены, в основном, иностранные методики и их модификации. Мы, конечно, не против иностранных продуктов априори. Но создавались-то они зарубежными авторами под влиянием и с учетом особенностей трудовых отношений, существующих в тех странах, где авторы проживали. Поэтому есть различия в восприятии таких опросников у иностранцев и россиян. А попытки адаптации иностранных опросников часто не удачны и в полной мере не решают эту проблему.

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

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

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

Основного веб-разработчика нашли быстро. Остановились на фрилансере. С ним уже был положительный опыт сотрудничества. Но тут ведь SaaS, а не абы что! Решили рискнуть и… предоставили ему большой кредит доверия. Парню все-таки уже 30 с гаком, бесшабашная юность позади. Окончательно нас убедили его интерес и отношение к будущему проекту. Договорились, что после запуска он станет суперадмином нового сервиса со своим процентом от дохода. Расчет был очевидный: если он хочет получать долю от результата, то должен сильно постараться и максимально ответственно отнестись к качеству создаваемого продукта.

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

Было решено разделить промо-часть сайта и собственно сам сервис, куда входит весь сопутствующий механизм и система личных кабинетов. Промо-сайт разместить на основном домене, а сервис — на поддомене. Зачем смешивать? Промо-контент должен работать на привлечение новых пользователей. А личные кабинеты — давать этим пользователям ТО, зачем они к нам пришли, и не отвлекать лишней рекламой.

Весь объем работы поделили на 5 частей. Таким образом, предстояло разработать:

• Основной функционал сервиса.
• Функционал для проведения опроса на бумажных бланках, включая механизм распознавания меток. Это в качестве альтернативы онлайновому опросу.
• Финансовый блок и биллинговую систему.
• Промо-сайт.
• Видео-контент: промо-ролик и инструкции для пользователей.

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

Совет: если вы реализуете серьезный интернет-проект, тем более SaaS, не вешайте очень много задач и внушительный объем работы на одного специалиста, каким бы "супер-мега-монстром" он не был. Человеческие возможности ограничены. Работать 24 часа в сутки он не сможет. Распределяйте нагрузку. И потом, у каждого специалиста есть свои сильные стороны. Вот на них и рассчитывайте. Основной технический рулевой процесса, конечно, должен быть. Он также может выполнять и конкретные задачи как веб-разработчик. Но вряд ли стоит доверять ему все этапы разработки — высокий риск завязнуть… Лучше распределите под его контролем все задачи между несколькими спецами. Пусть даже они будут из его команды, но вы должны убедиться в том, что такая команда у него действительно есть, обязательно встретиться с этими ребятами и ознакомиться с их портфолио. Ведь цена вопроса высока.

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

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

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

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

В это же время случайно узнали про Фонд содействия (так называемый, Фонд Бортника), который выдает гранты на реализацию инновационных проектов. Поначалу отнеслись с недоверием, дескать, знаем мы, как и кому в таких фондах деньги выдают. Но оказалось, что здесь всё по-честному.

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

Мы решили подавать заявку. Тем более что финансовый вопрос был у нас не последним в очереди.

Для нашего случая подошла программа Старт-1. Она предполагает выдачу грантов на реализацию НИОКР инновационных проектов для вновь образованных компаний. Фирму-то под свой новый проект мы зарегистрировали как раз совсем недавно. Заполнили формуляры на сайте фонда, в том числе составили бизнес-план. Нужно сказать, довольно-таки содержательный документище!

Гранты в Фонде содействия предоставляются на конкурсной основе. Мы прошли предварительный отбор, затем провели удаленно видеопрезентацию своего проекта для московского жюри фонда. По его итогам проект был поддержан. Нас одобрили! Это стало нашей первой победой.

Совет: Не стоит скептически относиться к подобным фондам. Дерзайте! Для стартапов сегодня это реальная возможность получить финансовую помощь.

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

Стоит сказать и о неудобствах, связанных с большим объемом отчетов и сопутствующих им документов. Чего стоит один заключительный научно-технический отчет на 100 страниц! Да и корреспонденция с фондом у нас накопилась ого-го!

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

Жесткие сроки выполнения работ, зафиксированные в договоре с фондом, дополнительно подтолкнули нас к тому, чтобы распределить задачи между несколькими исполнителями. Оно и к лучшему — мы УЖЕ сильно буксовали, понадеявшись на одного разработчика с его командой.

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

Приступили к поиску специалистов. Использовали специализированные сайты для фрилансеров.

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

Искали не торопясь, основательно, и, как показало время, не просчитались. В итоге механизмом бланкового опроса занялся парень из Новосибирска, а биллингом – группа ребят из Петрозаводска. Эх, широка страна моя родная!. Одновременно возобновили контакты с теми, кого еще ранее присмотрели для создания промо-сайта (вступительной, рекламной части веб-сервиса) и видео-контента. Это были местные ребята, обладающие соответствующими навыками и неплохим портфолио.

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

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

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

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

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

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

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

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

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

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

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

А предпочтение Highcharts обусловлено следующим:

1. универсальность (работает со всеми популярными браузерами);
2. большой выбор типов/видов графиков;
3. интуитивно понятный код;
4. относительно невысокая стоимость.

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

Отдельно остановлюсь на такой теме, как копирайтинг. Любой веб-сервис имеет в своем составе текстовые материалы рекламного, ознакомительного характера. Суть их везде примерно одинакова: поведать, для чего создан сервис, и какие задачи он решает. Но работают они по-разному. Одни достигают цели, в результате многие посетители сайта соглашаются попробовать сервис и становятся пользователями, другие – не достигают. Понятно, что причина — в содержании этих текстов и в том, как они представлены на сайте. Но поначалу нам было не понятно, как поступить лучше: сразу обратиться к профессионалам-копирайтерам либо сперва самим подготовить материал и только потом отдать его на растерзание этим гуру.

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

Конечно, мы снабдили его исходной информацией, и в достаточном объеме. Но когда посмотрели, что у него получилось в итоге, то нервно похихикали. Написано-то было четко, просто, лаконично. По форме – что надо. Однако содержание текста оказалось таким, что профессиональная общественность, увидев сие, подняла бы нас на вилы. А ведь мы предварительно всё хорошенько ему разжевали и убедились, что с той стороны нас поняли…

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

Стало очевидно, исходный текст нужно составлять самим. И уже потом отдавать этот текст копирайтеру, чтобы привести форму в надлежащий вид.

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

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

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

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

Следует выделить еще одну причину, которая сильно задержала запуск нашего онлайн-сервиса. (Кстати, на все разработки мы потратили всего-то навсего около трех лет!). Эта причина явилась опять же следствием нашей неопытности в it-стартапах. Итак, мы не смогли вовремя остановиться.

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

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

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

Кстати, в сфере it-разработок есть такое понятие как mvp (minimum viable product) — минимально жизнеспособный продукт, который можно запускать и уже получать от него некий финансовый эффект.

И наконец, о чем не могу не вспомнить, это — тестирование продукта. Длительный изматывающий процесс на протяжении почти всего периода разработки. За весь период работы мы неоднократно захлебывались в этой рутине. Были моменты, когда уже опускались руки. Тут даже не знаю, чего можно посоветовать, кроме как запастись терпением и с упорством, достойным муравья, сражаться с багами и недочетами вплоть до…

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

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

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

В том и другом случае такие люди должны обладать высоким уровнем внимательности и быть дотошными до мелочей.

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

Успешных вам стартапов!