MEDOED: Как мы создали свой программный продукт, десять лет проработав в консалтинге, да еще и получили льготы

Наша команда RTM Group занимается услугами в области информационной безопасности и права в ИТ вот уже 9 лет. Бизнес постепенно рос, и к 2019 году мы стали задумываться о том, чтобы сделать свой продукт. И в конце 2022г. эта идея окончательно созрела, мы решили стартовать. При том, что денег у нас было ровно на год жизни отдела разработки. Ниже делимся своим опытом, рассказываем, как мы создавали продукт, какие шишки собрали, какие результаты и плюшки получили.

Мы надеялись, что продукт поможет нам решить следующие задачи:

· Автоматизировать отдельные услуги

· Реализовать имеющийся опыт

· В перспективе двух лет иметь больше прибыли

· Поддержать материнский бренд

· Получить опыт разработки

MEDOED задумывался как платформа для автоматизации выполнения требований законодательства в различных сферах (защиты информации, персональных данных и т.д.). Предполагалось, что использовать продукт смогут мелкие компании (для них однопользовательская версия со всем функционалом полностью бесплатна), средние (за небольшую плату в год за многопользовательский доступ к платформе) и крупные (коробочное решение). Платформа должна позволять гибко настраивать справочники и документы, обладать функционалом импорта и экспорта, и, самое главное, - давать возможность создания и редактирования выходных документов. В качестве примера возможностей платформы реализуется функционал в части информационной безопасности. В принципе, чуть больше, чем через год, мы смогли создать работающую версию и в марте этого года открыли платформу для пользователей. Результат, кому интересно, можно посмотреть здесь: https://medoed-soft.ru/.

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

Мы искали везде, где можно, используя разные подходы:

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

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

3) «Все мои знакомые знают, что я ищу программиста, подкидывают варианты». Это оптимальный путь – всех, ну просто всех достать поисками. В итоге несколько человек так удалось «поймать». А тимлида я нашел на кафедре, где защищал диссертацию.

В итоге, 60% пришли к нам по объявлению, 40% - по знакомству. Структура команды разбилась сама собой на фронт и бэк, при этом в каждой банде есть свой «главарь». Нам нравится называть их так, поскольку каждый из них заслужил свой авторитет в коллективе знаниями и умениями. В первые полгода у нас была определенная текучка (примерно 20%), но сейчас коллектив трудится стабильно, даже сходили в отпуск.

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

А пока в команде ребята, один из которых, к примеру, единолично переделал систему авторизации под корпоративные возможности. Теперь есть админская учетка для создания других учеток, а не только самостоятельная регистрация и добавление через СУБД. А еще наш супербоец с бэка освоил DevOps и теперь сборка и установка коробочных решений ведется автоматизировано. А «фронтовики» радуют тем, что пропускают через себя весь функционал – большая часть фишечек, которые есть в интерфейсе – их заслуга.

Как я уже отметил, можно выбирать команду под технологии, а можно наоборот. Мы пошли по второму пути, но это не значит, что ограничений у нас не было. Главное из них - от Минцифры – связано с запретом на использование «недружественных технологий», поэтому MS SQL и иже с ним сразу оказались за бортом. Второе: мы работаем в сфере информационной безопасности, а потому скоро пойдем за сертификацией. В этих условиях нельзя использовать платформенные вещи типа уже отброшенного .Net и всерьез рассматриваемой Java.

Также мы понимали, что приложение наше 100% будет с WEB-интерфейсом, поэтому круг еще сузился. В итоге, у нас сформировался достаточно прозаичный стек с Python и JS (React). Из экзотики взяли только нереляционную СУБД Arango по настоянию одного из будущих «главарей».

Различные библиотеки для питона и реакта перечислять нет смысла, оговорюсь только, что за их обновлениями следим, и очень внимательно. Так, пропустив одну строчку (это не гипербола, реально одну) в библиотеке экспорта в Open Document мы практически парализовали работу на пару дней. С тех пор через гит проверяем обновления построчно, чтобы было понятно, откуда может прилететь.

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

Как только появилась команда, определили технологии, мы стали формулировать, что конкретно хотим. К этому моменту 100 идей превратились в 120, причем первоначальных всего 30 – полёт фантазии продолжается.

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

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

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

Далее пошли прототипы (не совсем MVP, но что-то более-менее пригодное для практики).

Отдел разработки постоянно (безуспешно) пытались привлечь для решения коммерческих задач по оценке качества кода и прочим вещам, которыми занимается RTM Group, это примерно 20% от рабочего времени.

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

Спустя почти год после старта, когда появилось коммерчески пригодное к продаже ПО, мы зарегистрировали юрлицо для разработки. До этого программисты были оформлены в другом ЮЛ дабы не плодить сущности сверх необходимости. Еще профит: 100% выручки нового юрлица - от реализации ПО – 100%, и это дало нам возможность получить аккредитацию Минцифры в качестве ИТ-компании, а значит, и льготы. Но о чуть позже, ведь не для них же все затевалось.

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

Роспатент принял с первого раза, а вот Минцифры только со второго – сами виноваты, пропустили в одном документе раздел и остался почтовый адрес одного из заказчиков. Но персданные не раскрыты, иная конфиденциальная информация не пострадала, переподача заняла примерно 25 минут с учетом настройки браузера под госуслуги на домашнем ПК (ответ пришёл перед выходным днём в восемь вечера). С учетом переподачи весь процесс занял меньше месяца, чего и всем желаем.

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

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

Поэтому мы придерживались (и продолжаем это делать) следующих правил:

1) В штате только те, кто имеет отношение к проекту. Юристы и маркетологи, которые занимаются MEDOEDом. Бухгалтерия же как была на аутсорсе, так и осталась.

2) Зарплата (не смотря на то, что наличие ПО в реестре исключает требования к ее уровню) – выше среднего. При средней по РФ 74 тысяч по РФ, мы платим в «белую» и получается больше.

3) Выручка – самый критичный параметр. Объем надо поддерживать любыми скидками, прибыльность никого не интересует. И НЕ надо смешивать с другими видами деятельности – тонкую грань в 70% очень легко перешагнуть.

Ну и еще полезная информация: если вы получаете гранты, они не считаются в выручку. Вообще.

Всем желающим попробовать платформу MEDOED – добро пожаловать, если есть вопросы – пишите, мы планируем организовать вебинар по тематикам, которые описали выше.