Дмитрий Агапов, основатель IT-компании CHM Software, рассказывает об уроках, которые извлек из своего опыта по развитию IT-продукта на украинском рынке.
Для старта проекта пришлось отдать все деньги, что были
Решение о создании продуктовой IT-компании не было осознанным выбором. Так случилось. А началось все с кризиса в 2008–2009 годов. Тогда я работал в небольшой IT-компании, которая занималась финансовыми сервисами (пополнение счетов мобильных телефонов). Именно там родилась идея разработки программного продукта для кассовых аппаратов.
Софт должен был расширить возможности классических кнопочных кассовых аппаратов, которые тогда представляли собой некую печатную машинку для чеков и никуда не передавали собранные данные. Наша идея была в том, чтобы даже самый старый кассовый аппарат можно было удаленно программировать, получать с него чеки (в идеале — в режиме онлайн), делая все это в условиях использования беспроводного интернета. На тот момент это был стандарт передачи данных GPRS, дорогой и медленный, что повышало требования к разрабатываемому программному обеспечению.
Однако компания, где я работал, кризис не пережила, закрывшись оставила долги перед своими клиентами, а основное руководство и вовсе «исчезло из эфира». Один из экс-соучредителей предложил мне организовать совместный с ним бизнес, погасив долги перед клиентами, и заново начать деятельность в области финансовых сервисов.
Для старта проекта я принес из дома все деньги, что у меня были, порядка 2500 евро. Плюс мы взяли ссуду у частного заемщика в размере 10000 евро. В июне 2009 года наш продуктовый IT-бизнес стартовал, и мы начали развивать свое ПО.
К сожалению, первоначальная версия для работы с кассовыми аппаратами не имела спроса. Мы продали всего 45 лицензий одному единственному клиенту — сети по продаже прессы. Думаю, причиной послужило то, что кассовые аппараты стали развиваться и появились модели, которые уже умели обмениваться данными с центральным сервером самостоятельно, без всякого стороннего софта.
В 2010 году казалось, что это конец. Но судьба дала очередной шанс для продукта. Появился новый заказчик — сеть киосков в Днепре. У нас тогда даже своего сайта не было, он разыскал нас именно через нашего единственного клиента. Заказчик захотел сделать полноценный учет: от регистрации продаж до электронного документооборота, печати ценников и накладных прямо в киосках.
Мы выиграли контракт. Кроме того, получили грантовую поддержку ЕБРР, и через год на рынок вышла версия программного обеспечения, по функционалу опережающего свое время: на беспроводных GPRS-каналах удалось реализовать внутренний электронный документооборот, инвентаризацию можно было проводить без остановки торговли и еще множество интересных возможностей, которые тогда придумал и прописал в виде ТЗ консультант клиента Андрей Найденов.
Все эти возможности софта рынок начал понимать с 2016 года. Тем не менее, уже в 2012 году мы продали нескольким сетям более 1000 лицензий на этот продукт.
Поиск «длинных» денег, еще и фактически под зарплату командам проектов — непростая задача
Сегменты IT — разные, специфика есть везде.
Возьмем в качестве примера классический украинский сырьевой аутсорсинг. Берется контракт на какой-то код, пишется, передается заказчику, берется новый контракт. И так по циклу. Первое отличие продуктовых компаний от такой модели: они в основном играют в долгую.
Конечно, есть проекты быстрые, но если брать более сложные решение, то это не один год разработки, тестирований и улучшений. Дальше — маркетинг, продажи, сопровождение, поддержка.
Срок разработки продукта и выхода с ним на рынок — более 2-х лет. Но и актуальность продукта в нашем сегменте превышает 7–8 лет. Например, сейчас самый большой доход нам дает вторая версия софта, которая была выпущена в 2014 году для кассовых систем с обычной клавиатурой, а в 2015 году — для кассовых систем с сенсорными экранами.
Конечно, она постоянно дорабатывается и сейчас в продаже уже седьмое поколение второй версии, и, как мы планируем, завершающее. В планах на 2022 год — появление третьего поколения платформы нашего софта.
Плюс нашей специфики: мы понимаем, что если клиент подписывает с нами контракт, то это всерьез и надолго. Минус: требуются значительные финансовые ресурсы для выпуска готового решения, не только с точки зрения кода, но и с точки зрения вывода продукта на рынок, которые необходимо привлекать сроком минимум на 2–3 года. А в условиях постоянной нестабильности у нас в стране, поиск «длинных» денег, да еще фактически под зарплату командам проектов — задача очень непростая.
За последний год на рынке разработчиков стоимость трудовых ресурсов выросла в 2 раза
Продажи софта мы в основном вели на территории Украины, только недавно начали получать первую валютную выручку. То есть основные доходы — с украинского рынка, далеко не самого платежеспособного, с низкими ценниками на продукты и услуги. А нанимать разработчиков мы вынуждены именно в валюте, конкурируя с компаниями, работающими на западные рынки.
Локдаун вообще поднял планку зарплат, так как мировые продуктовые компании научились нанимать разработчиков в обход локальных аутсорсеров и аутстаферов, оплачивая напрямую более высокие оклады. За последний год на рынке разработчиков стоимость трудовых ресурсов выросла в два раза.
Усложняет ведение бизнеса в области разработки и продвижения IT-продуктов в Украине, и ограниченный доступ к финансовым ресурсам. Здесь, в первую очередь, стоит отметить их дефицит в принципе. Отсутствие ресурсов на длительные периоды и их стоимость не добавляют позитива. Мне кажется, что по мнению владельцев финансовых учреждений в Украине каждая компания или житель нашей страны занимаются какой-то сверхприбыльной незаконной деятельностью. Именно так можно объяснить размер ставок по кредитам в стране.
Качественные консультации экспертов экономят годы жизни, помогают избежать сотен набитых шишек
Когда у вас в команде всего несколько человек, трудностей с организацией и операционкой нет, все работает, как часы. Но тут происходит рост, о котором ты не задумываешься и к которому не готовишься. Начинается бег «по полю с граблями». Причем на одни и те же грабли наступаешь порой несколько раз.
А проблемы роста стандартные — нет описанных процессов, регламентов, должностных инструкций, организационной структуры, планирования, бюджетирования, отчетность недостаточно автоматизирована, слабая внутренняя и внешняя безопасность и прочее.
И в какой-то момент ты понимаешь, что расширение — это не просто нанять еще персонал, доверить новому сотруднику какой-то участок работ, который ты делал ранее сам, либо снять офис побольше и купить мебель. Это — не самая большая проблема. Проблема роста — это необходимость аккумулировать гигантский труд, время и деньги на построение системы взаимодействия, правил как внутри компании, так и с внешними партнерами.
А самые большие сложности возникают, если ты эту систему не строишь либо она недостаточно эффективна. Последствия проявляются в разных аспектах: какой-то написанный модуль в софте не работает, на складе «исчезает» оборудование, на счетах заканчиваются деньги для выплат заработных плат и расчетов с поставщиками. В общем, проблемы накапливаются комом.
В последнее время, когда мы видим, что что-то нужно быстро менять в той или иной сфере, мы привлекаем внешних консультантов на проблемные участки. И как показывает практика, качественные консультации экономят годы жизни, помогают избежать сотен набитых шишек, стать сильнее и развиваться еще быстрее. Это позволяет фокусироваться на том, в чем мы имеем сильную экспертизу, — разработке программного обеспечения для ритейла.
СЕО в продуктовой IT-компании нужно быть «камикадзе», полностью отдаваться компании, верить в ее продукты и результаты
В зависимости от целей компании СЕО прорабатывает стратегию их достижения, правильно делит на этапы, определяет необходимые ресурсы, доводит цели и задачи до менеджмента и контролирует, корректирует ход всех процессов, актуализирует цели и стратегию уже в процессе работы.
Положительными финансовыми показателями его работы может быть не только рост прибыли, но и привлечение финансирования, расширение клиентской базы, а следовательно, и рост товарооборота.
СЕО в продуктовой IT-компании, помимо того, что должен обладать стратегическим мышлением и быть «заточенным» на развитие, должен иметь широкие знаниям в разных сферах: программирование, администрирование, финансы, учет, маркетинг, продажи, безопасность и т. д.
Не обязательно самостоятельно уметь, например, программировать, но обладать глубоким представлением процессов в каждом бизнес-процессе, который используется в компании, обязательно. Важно логически уметь связать всю цепочку производственного процесса, сбалансировать его для достижения результата.
Управленца продуктовой IT-компании можно сравнить, скажем, с капитаном космического корабля, который еще и руководит его созданием, сборкой, запуском и дальнейшим пилотированием. Какими для этого качествами нужно обладать? Быть «камикадзе», полностью отдаваться компании, верить в ее продукты и результаты.
Поиск разработчиков сегодня — целый обряд с бубнами, танцами, уговорами, плюшками и многим другим
У нас относительно небольшая команда разработчиков – на сегодня это в районе 15 человек. Тем не менее уже сталкиваемся с постоянными сложностями формирования команд. Пока у нас нет жестких процедур в работе, как, например, в более крупных компаниях с сотнями разработчиков (за что в массах их называют «галерами»). Но эволюционно уже и мы приходим к ужесточению правил, регламентов, таймингов в работе, усиливаем контроль.
Собрать описанное воедино, организовать работу, быть готовым к процессу постоянной миграции разработчиков между компаниями — в этом и есть сложности, нюансы и специфика формирования команд в нашей отрасли. И это все в условиях, когда срок входа разработчика в проект — от двух месяцев.
Сложность в том, что нет идеального портрета разработчика. Разработчик может быть и холериком, и флегматиком, замкнутым в себе или социально активным, любящим компьютерные игры, сидящим дома или активно занимающимся спортом. И когда в принципе абсолютно разные люди начинают работать над проектами, часто возникают коммуникативные барьеры между ними. Разработчики – люди творческие и местами ранимые. Может просто наступить «выгорание». В один день могут прийти и сказать: «Надоело заниматься этим продуктом, пойду писать игры». И ничего ты тут не сделаешь.
Поиск разработчиков — это отдельная отрасль, которая ушла в формирование самостоятельного рекрутинг-бизнеса. Это сегодня целый обряд с бубнами, танцами, уговорами, плюшками и многим другим. Такого нет на рынках труда по другим направлениям.
Ошибки научили нас более детально накладывать идеи на реальный бизнес, отклоняя нерабочие модели, даже если их заказывает клиент
Сегодня наш классический цикл разработки продукта выглядит следующим образом: рождается идея (внутри нашей команды или как предложение от клиента), далее она проходит жесткий фильтр на предмет ее практической пользы и выгоды для бизнеса, потом идет проработка приоритетов функционала, которая постепенно превращается в детальное техническое задание, выполнение которого контролирует проектный менеджер (PM).
На финише каждая задача проверяется таксировщиком. PM принимает разработанный проект согласно ТЗ, а технический писатель готовит документацию для внутреннего и внешнего использования. В итоге заказчики и рынок получают новый функционал и продукты, которые повышают эффективность бизнеса.
Но стоит признать, системная работа всех участников процессов разработки у нас была далеко не всегда. Раньше приходилось «бегать по граблям», часто по одним и тем же. Сейчас мы уже можем говорить о наших «детских болезнях» вслух, когда от них удалось избавиться.
- Разрабатывалась фича, которая в итоге была никому не нужна. Нужно признать, таких рудиментов в коде у нас хватает. В том числе и таких, которые заказывал клиент, но после реализации понимал, что это ему не нужно. Это научило нас более детально накладывать идеи на реальный бизнес, отклоняя нерабочие модели, даже если их заказывает клиент.
- Программистам ставились общие, а не детализированные задачи. Была уверенность, что программист сам их раскроет и сделает так, как мы задумали. Но сколько людей – столько и мнений. В итоге мы получали функционал, который или работал не так, как хотелось, или вообще отличался от желаемого конечного результата. Сейчас на старте запуска любого проекта у нас работает бизнес-аналитик, который превращает задачу в детальное техническое задание (ТЗ). Его передают проектному менеджеру (PM), который в свою очередь «нарезает» ТЗ на мелкие задачи, распределяет их среди разработчиков и контролирует ход работ.
- Разные разработчики реализовывали одни и те же функции. В итоги мы получали разный код, но один функционал. И чем сложнее продукт, тем больше вероятность таких ошибок. Теперь мы практически пошагово документируем проект, усилили управление проектами, внедрили обмен знаниями между командами.
- Главным тестировщиком был клиент. Поэтому автотестов кода делалось мало, как и тестирований функционала перед выпуском в релиз, а поиск ошибок перекладывался на клиента. Сейчас мы регулярно проводим внутренний АBС-анализ, делаем автотесты, контролируем качество кода с помощью ревью более опытными разработчиками, проводим постоянные митинги, обучения и многое другое.
Главное — выносить уроки из ошибок, которые часто неизбежны. Порой это — единственный путь к разработке действительно качественного и полезного продукта. Наши недочеты помогают нам улучшать процесс создания и выпуска новых продуктов и функциональных возможностей существующих.
За последние 2 года мы двукратно увеличили товарооборот и персонал. В 2021 году практически параллельно выпустила сразу нескольких новых продуктов — кассы самообслуживания, POS-систему для аптек с функциями работы со складом, систему учета для розничной торговли в малом и среднем бизнесе POSKit, а также поддерживаем и развиваем текущие релизы программного обеспечения.
Планы на 2022 год: от десятки тысяч дополнительных инсталляций продукта, подключения тысяч новых клиентов и до выхода на новые территориальные рынки.
Автор: Дмитрий Агапов, основатель IT-компании CHM Software
