Делаем сложные решения играючи: интервью с основателями компании заказной разработки
Нам было всегда интересно, как развивается профессиональная карьера членов сообщества. Особенно когда в карьере происходит крутой поворот. А запуск бизнеса в нестабильном 2023 — поворот круче некуда. Мы пообщались с Михаилом Соломоновым, генеральным директором, и Евгением Дегтяревым, техническим директором компании «УМАРТА», которые в этом году стартовали свой бизнес и занимаются разработкой заказного ПО.
На дворе 2023 год — год непростой, как пришла идея создавать в этом году бизнес?
Михаил: На самом деле мы не планировали создавать бизнес и проводить кардинальные изменения в жизни — букнвально в январе-феврале 2023 года. Но обстоятельства привели к тому, что мы независимо друг от друга приняли решение покинуть наше предыдущее место работы, где мы были наемными менеджерами. Узнав о решении друг друга и обсуждая будущие планы, мы подумали, было бы хорошо что-то сделать вместе — тем более, что в последние четыре года у нас хорошо получалось работать вместе, наши компетенции дополняют друг друга. Потом были мучительные две-три недели, когда мы прикидывали, какие у нас есть ресурсы и чьи еще ресурсы мы можем задействовать — ведь нам предстояло платить зарплату команде, стать аккредитованной ИТ-компаний и т. д. В конечном итоге мы взвесили все за и против и решили рискнуть, запустив своё предприятие.
Евгений: Я с 2011 года занимался различными side-проектами параллельно основной работе. Некоторые из них превращались во что-то крупное, где-то я просто старался заработать дополнительно но меня всегда преследовало чувство, что если я буду больше времени вкладывать в такие активности, то у меня вполне может получиться что-то хорошее, и я смогу сказать, что я сделал что-то сам. В какой-то момент я взялся рефлексировать, чего я вообще хочу от жизни. Я бы хотел построить в России какой-то свой бизнес, который будет двигать мир к лучшему, и я смогу вкладывать туда все свои силы без траты времени на согласования, политику, бюрократию, потому что я буду управлять бизнесом так, как считаю нужным. На этом фоне мы с Михаилом долго общались — на самом деле наши разговоры о собственных проектах начались еще даже раньше января-февраля этого года. Просто раньше мы планировали запускать что-то новое внутри организации, в которой мы были трудоустроены, предлагали модели акционерам, а сейчас это выросло в свой проект. Если кратко: хотел давно, занимался давно, очень хотелось попробовать, и тут так совпали обстоятельства, решил — надо действовать. А какой год на дворе, уже не так важно. Да, были времена, когда лопаты втыкались в землю и зеленели. Эти времена прошли, но это не значит, что теперь нельзя открывать новые бизнесы. Можно.
Вы оба произнесли фразу про свой прошлый опыт. Какие компетенции вы принесли в «УМАРТУ», какой была ваша траектория, которая вас сюда вас привела?
Евгений: Я в первую очередь был всегда разработчиком, программистом в широком смысле слова. Я любил программирование, ещё когда учился в школе и институте — и да, я всем сердцем люблю это дело. Это прямо-таки отдушина в моей управленческой деятельности. С 2012 года я стал заниматься управленческими вещами: мы с товарищами организовали компанию, которая работала в госсекторе, делали разные проекты. Из маленькой компании она выросла в большую, затем, когда значительная часть тех, кто был на старте, отключились — стала разваливаться, и теперь существуют осколки. Соответственно, я прошел путь от программиста до управленца, может, не самого лучшего, но понимающего, что происходит в производстве. Я руководил проектами, потом это выросло в департамент — и параллельно я развивал практику разработки на Java, а потом практику разработки вообще. Не могу сказать, что я большой специалист в управлении — ни проектами, ни командами, ни компаниями. Но некую практику я накопил. В 2016 году я предложил развивать направление заказной разработки в компании, где был трудоустроен. С нуля, потихоньку начал это делать, не без ошибок, не без косяков. Проверял все гипотезы на практике методом проб и ошибок. В какой-то момент это стало утомительно, в этот же момент присоединился Михаил, у которого опыт в управлении более фундаментальный — и у меня была возможность научиться чему-то вместе с ним. Ранее сфера управления меня мало интересовала, теперь подтягиваюсь по теории. Сейчас задача — создать работающий конвейер, где на входе будет ТЗ, а на выходе — продукт и счастливые пользователи.
Евгений, назови три проекта, которые запомнились больше всего?
Евгений: Мобильная приемная правительства Москвы для портала «Наш город». Потом приемная превратилась в СОЭСГ (систему обработки электронных сообщений граждан), а потом СОЭСГ был интегрирован в портал. Эту систему я сделал с нуля своими руками. Второй проект — электронный дневник (дневник МЭШ). Наша команда делала весь бэкенд. Работая в Haulmont, я тоже делал много интересных проектов, среди них — портал непрерывного образования сотрудников здравоохранения. Федеральный портал, где все врачи и медсестры страны каждые 5 лет обучаются и проходят аттестацию. Если говорить о частных компаниях, то могу выделить британскую компанию судебных приставов — начиная с 2010 года, я участвовал в разработке нескольких автоматизированных систем: мобильное приложение, ERP-система, автолокатор, портал. В 2010 году это была маленькая компания со штатом 50 человек, а теперь в ней около тысячи сотрудников — в том числе и благодаря нашим решениям.
Михаил, если говорить о твоей траектории?
Михаил: Хотел подчеркнуть, что Евгений — действительно наш самый дорогой программист. И я думаю, что навсегда таким останется. В отличие от Жени, я шел по другой траектории: если Женя программист, то я занимался областью технической поддержки и системного администрирования. Начал я это еще в школе, в университете на 1-2 курсе пошел работать системным администратором. Как только у меня появилась техническая возможность, в 2006 году открыл первую компанию. Сейчас бы ее назвали «компанией по торговле айтишниками», тогда мы думали, что это бизнес по обслуживанию чего-то или кого-то. Поднимая этот бизнес, параллельно работал еще в шести местах, и имея уже семь работодателей за плечами, пошел в большую международную компанию NetCracker со страшной целью: «подсмотреть, как большие люди делают бизнес, чтобы скопировать себе». Желание «создать свою большую компанию» зародилась еще тогда, но в 2008 году мой бизнес умер в кризис. Я полностью сосредоточился на NetCracker, потом работал в «Сибур», «Крок», машиностроительном дивизионе «Росатом». Одна из ключевых компетенций, которая у меня была всегда, но которой я старался не пользоваться — это дар убеждения, он помогал мне коммуницировать с людьми, ещё когда я был сотрудником технической поддержки. Благодаря одному своему другу присоединился к Haulmont в качестве директора по развитию бизнеса, и там снова окунулся в продажи.
Женя уже несколько раз упомянул про самообразование. Я получил базовое образование специалиста по информационной безопасности, потом образование переводчика, потом психолога. Последнее — очень важно, потому что при общении с людьми важно думать, как закрыть не только свои цели, но людей вокруг. Только синергия работает вдолгую. Сейчас учусь по программе MBA в МГУ. Таким образом, мы отлично друг друга дополняем. У меня больше компетенций в управленческой части, у Жени — технической. Но при этом я достаточно глубоко понимаю техчасть, а Женя в ней и вовсе близок к абсолюту.
Предположим, я потенциальный клиент, создаю для себя шорт-лист компаний заказной разработки — почему я должен добавить в него «Умарту»?
Михаил: Если мы говорим про внутренние корпоративные системы, про нечто совершенно нестандартное, сложное, чего раньше на рынке не существовало, то компетенции нашей команды позволяют еще на этапе первых встреч определить: можно ли использовать что-то существующее или нужно новое решение. Если мы понимаем, что какое-то чужое существующее решение будет гораздо эффективнее, и мы про него знаем, мы никогда не возьмем этот проект себе. Всегда познакомим с друзьями, знакомыми или просто покажем продукт на рынке. При этом если мы понимаем, что такого нет, или по каким-то глубоким причинам готовые продукты не подходят компании-заказчику — мы предложим оптимальные технологии, подходящие именно для этого клиента. При это предварительно непременно разберем долгосрочные цели и задачи компании, чтобы не создавать дорогую систему, которая заказчику не нужна. Или наоборот — можно сделать простое доступное решение, а потом выяснить, что у заказчика планов на 10-12 лет вперед. Мы все это проработаем заранее. Поэтому первый пункт — широкий технический кругозор и понимание использования технологий во внутренних корпоративных информационных системах.
Насколько обширное исследование потребностей клиента для этого приходится проводить?
Михаил: Это зависит от класса системы, которую мы рассматриваем. Если это CRM (с ними мы сталкиваемся постоянно), то внешнее исследование — минимально, внутреннее зависит от размера заказчика и наличия у него старых исторических систем. Если таких систем нет, то полное обследование можно провести за полтора месяца, если старых систем много, и надо разобраться, как они работают, — такой проект может занять до года.
Получается, что это отдельный проект до разработки?
Михаил: Да, если мы говорим про крупных заказчиков и большие крупные информационные системы, то это длительный процесс. Но есть масса других систем: личные кабинеты клиентов, мобильные приложения для выполнения двух-четырех рабочих функций, — и там предварительные изыскания могут занять день: одна большая встреча и серия уточняющих вопросов.
А часто первичный запрос клиента соответствует тому, что ему реально нужно?
Михаил: Скажем так, 30% запросов соответствуют тому, что клиент хочет. Есть отдельные категории заказчиков, которые приходят со своим ТЗ. Мы пониманием, что в реальности ему это не нужно, но задача — сделать так, как написано.
Так, первую причину понял, вторая и третья?
Михаил: Вторая причина — финансовая. На текущий момент мы молодая компания, не обремененная накладными расходами. Мы достаточно приземленно смотрим на вопросы управленческого учета, на вопросы эффективности внутри команды, есть понимание экономических аспектов ведения бизнеса, поэтому постоянные затраты мы стремимся сделать как можно меньше. Расчетная стоимость наших проектов минимальна на рынке.
И третий пункт, когда вы работаете с крупными игроками, у них обычно большая команда: аккаунт-менеджер, руководитель проекта, руководитель производственного направления и много других ролей. Зачастую при возникновении проблем с компанией сложно или почти невозможно повлиять как-то на скорость достижения результата, дать обратную связь, чтобы она привела к изменениям. Я надеюсь, что мы сможем сохранить нашу «плоскую» структуру. Каждый клиент для нас уникальный. Мы можем обеспечить высокое качество сервиса, так как основатели могут оперативно включиться в работу.
Может вы и небольшая компания, но в «Умарту» принесен гигантский опыт. А вообще, если выбираешь компанию заказной разработки, как понять, в какую компанию обратиться? Есть ли какой-то чек-лист?
Евгений: У меня есть ответ на этот вопрос. Поскольку значительная часть моей работы — это делегирование каких-то кусков другим компаниям. Условно, аутсорсинг аутсорсинга. Поэтому я часто сталкиваюсь с вопросом, как понять, что компания хорошая. Главное — определиться, что мы хотим. Например, мы хотим просто ресурсы, условно, у нас есть свои процессы, у нас все налажено, просто у нас не хватает рук. Тогда компания — это поставщик ресурсов, не заказной разработки, а заказных разработчиков. Это нормальный вариант, он многих заказчиков устраивает. В определенных случаях в этой схеме возникают проблемы, например, если требуется что-то сделать в ограниченные сроки с высоким уровнем качества, то такие компании-поставщики ресурсов не подходят. Почему? Потому что в них собираются разные люди — им надо все объяснить, их надо построить, им нужно сказать, что делать. Если свои процессы прихрамывают, то команда тоже будет прихрамывать. Целое будет отличаться от суммы частей — хорошие разработчики, которые есть в таких компаниях по отдельности, могут не дать нужного результата в команде. Хорошая компания заказной разработки в первую очередь узнает: а что нужно клиенту? Зачем ему люди? Зачем ему нужен тот или иной сервис? Смотрел ли он имеющиеся на рынке решения? Хорошая компания разберется в проблеме. Возможно, вам вообще разрабатывать ничего не нужно — достаточно найти имеющийся аналог. А если нужна разработка, то процесс будет максимально прозрачным: заказчик будет понимать, что и на каком этапе делается. У заказчика должна быть ясность. Хорошая компания хочет не просто получить деньги, она хочет «дружить» с клиентом.
Давайте посмотрим на клиента, на каком этапе развития бизнеса у компании возникает понимание, что готовое решение с рынка не устраивает, нужна своя разработка?
Евгений: На любом. Среди наших заказчиков есть и очень маленькие компании со штатом пять человек, но у них есть идея, как сделать для себя классный продукт. Среднего уровня компании обычно сталкиваются с тем, что они не понимают, как должно быть. Например, у компании есть какой-то софт, допустим, 1С, в нем что-то настроено, что-то работает — но работает через пень-колоду, и у заказчика нет понимания «а как правильно». Как сделать так, чтобы процесс был сквозным, чтобы все было визуализировано, чтобы было всем было удобно? Компания понимает, что так жить тяжеловато и приходит к нам. У крупных компаний часто возникает потребность что-то автоматизировать на стыке крупных систем. Для них надо сделать уникальный сервис. Например, такой, который будет из социальных сетей доставать посты, агрегировать их по тегам и отдавать маркетологам.
А вы в этом случае снесете существующую систему или пристроите что-то новое?
Евгений: Пристроим. Сейчас все хотят микросервисы, но что такое микросервисы — не все понимают. Есть определенные задачи и области, где микросервисы подходят идеально. Самый яркий пример — банковская деятельность: у банка есть огромный монолит, который никто и никогда не распилит на микросервисы. Но вокруг этой большой системы работают сервисы, которые помогают решать точечные задачи. Например, при сдаче декларации в налоговую система ее проанализирует и предложит или не предложит предпринимателю кредит. У некоторых банков в части микросервисов все хорошо налажено, у других не так. Поэтому менеджмент не до конца понимает, что делать с микросервисами. Мы в этом случае помогаем. Крупную систему сносить нецелесообразно. Адекватный вариант — сделать «пристройку».
Михаил: На самом деле, я поддерживаю мнение, что от размера компании необходимость в разработке решения не зависит. Есть много компаний, которые только-только открылись, но не нашли на рынке для себя каких-то подходящих систем в силу узкопрофильности бизнеса. Даже мы, открыв «Умарту», сделали решение по управлению ресурсами сами. Учет человеческих ресурсов в ИТ-компании — это специфично, за много лет мы посмотрели массу разных решений и поняли, что наша специфика отличается. Было два варианта: найти что-то готовое или сделать своими силами, повторюсь, что Евгений — наш самый дорогой разработчик. За 3-4 дня мы получили готовую систему, позволяющую вести учет ресурсов. Очень часто бывает так, что компания берет существующее решение, думая, что оно ей подходит, а на деле оказывается не так. Например, суть процесса работы компании, которая занимается претензионно-исковой деятельностью, максимально близка к Service Desk. Есть претензия, решили — хорошо, не решили — пошли в суд. Выиграли суд — закрыли задачу, не выиграли — апелляция. И так далее. Но первых шагах все ок, но как только мы начинаем погружаться в процесс — выясняется, что на втором и третьем шаге это уже не Service Desk. Такая компания нуждается в собственной разработке. Поэтому главная задача на старте — задавать максимальное количество вопросов заказчику. Потому что именно вопросы и анализ помогают понять: нужно ли новое решение.
Когда стоит отказаться от заказной разработки и растить собственную команду?
Михаил: Если есть понимание, как построить правильный процесс разработки у себя, есть возможности привлечь ресурсы и удержать их у себя внутри. Зачастую высококвалифицированные кадры заинтересованы в развитии своего технического потенциала. Поэтому вопрос удержания таких кадров — самый сложный. Когда вы ведете сложную разработку внутри компании, то вы должны либо сразу готовиться к постоянной текучке и как-то учиться с этим работать — либо в какой-то момент вы поймете, что бюджет, который вы закладывали, вырос вне прогнозных показателей. Люди будут уходить, а новые всегда дороже. При этом у крупных корпоративных решений скорость обновления крайне низкая. Они работают по 7-10-20 лет. А у нас постоянно что-то меняется в законодательстве, поэтому не изменять существующие информационные решения не получится. Поэтому держать людей внутри на уже устаревшие решения становится дороже и дороже.
«Умарта» через три года — это какая компания?
Евгений: Известная во всем российском ИТ-секторе, имеющая репутацию компании, которая может делать крупные сложные проекты. Причем делает это играючи.
Михаил: Три собственных продукта и миллиард выручки.
Беседовал Феликс Карасев
