Темные времена софтверной IT-компании

Наверное, вы думаете, надо сильно постараться, чтобы отдать 200 тысяч рублей непонятным фрилансерам, зафейлить крупный госпроект, потерять почти всех сотрудников и довести заглавный внутренний продукт до статуса «legacy». Но оказалось, завести молодую IT-компанию на дно – очень легкая задача, и в этой статье я расскажу, как докатился до жизни такой.

На связи команда ZAKUPKI.GROUP, заходите в гости на наш LinkedIn.

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

Итак, все началось с внутреннего продукта – CRM-системы для компаний-участников госзакупок. На тот момент мой будущий партнер Сергей решил нанять для разработки фрилансеров. Ребята кормили его обещаниями, завтраками, какими-то картинками и скриншотами.

В итоге они просто пропали вместе с деньгами. Многие после такого разочаровались бы в айтишниках и в человечестве в целом, но не Сергей. Он продолжил поиски и вышел на меня. Скооперировавшись, мы основали свою софтверную компанию zakupki.GROUP, и сейчас занимаемся разработкой корпоративного ПО в России и за рубежом.

Но к этому мы пришли не сразу, сначала было дно.

Думаю, для молодой команды разработчиков взять госзаказ – это шанс проявить себя и заиметь хороший кейс в портфолио. И в свое время мы ухватились за такой шанс. Стояла задача разработать модуль онлайн-записи в МФЦ для одного из регионов РФ. Мы сразу решили нанять субподрядчиков, потому что сами не сильно разбирались в битриксе.

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

Круглосуточная работа, перекрестное покрытие матами в рабочих чатах (а точнее в одном-единственном чате, но об этом чуть позже)… Тогда в самый неподходящий момент у одного из наших ключевых разработчиков заболела бабушка, ему пришлось ехать в деревню. Сроки горят, а он из-за плохого интернета выходит на связь раз в час. Сейчас этот парень с нами не работает, но я уверен, он по сей день не отошел от пережитого травмирующего опыта. Меня так точно до сих пор триггерят любые сообщения капсом.

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

Примерно за 2 недели до дедлайна к команде присоединился Артем, ныне наш CTO. Он сразу понял, что примерно все у нас пошло не по плану, и попытался стать голосом разума среди хаоса. Регламенты, методологии, корпоративная культура… Мы не были к этому готовы!

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

Так вот. Я думаю, большинство менеджеров, утверждающих, что работают по тому самому Agile, даже не понимают сути этой методологии. Как не понимали и мы, хотя честно пытались в итерации, спринты, канбан и иже с ними. Мы применяли модные методики и ожидали, что это обеспечит решение всех сложных задач – карго-культ в действии. Но почему-то при попытке внедрения одной новой фичи ломались две старые. В итоге каждые две недели мы делали не шаг вперед, а два назад. Да, мы попали в регрессионный ад, он же «регрессионная спираль смерти». Это громкие названия одной простой проблемы: невозможность за короткий срок сотворить что-то стоящее. Попытки угнаться за спринтами приводили к недостаточности тестирования. Целью было не сделать рабочий и со всех сторон гармоничный продукт, а показать новую фичу как можно скорее.

Кроме того, процессы внутри команды были не налажены. К примеру, у нас был всего один рабочий чат в ТГ на всех. Только представьте: общение разработчиков, ПМов, дизайнеров и всех-всех в одном месте. И мемы туда же. Было не смешно!

Но пришел Артем. И как истинный евангелист от мира IT принес на ладошке знания о международных стандартах разработки, рассказал о bus-факторе, показал, как организовать систему знаний внутри компании, предложил структурировать рабочее общение…

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

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

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

Помимо всего прочего, мы затеяли переезд на кластер Kubernetes. Напомню, что девопсеров у нас не было, и разбираться в теме пришлось разработчикам. Денис воодушевленно взялся за изучение вопроса, сам находил полезную литературу, писал инструкции для корпоративной Wiki. Но случился ковид и Денис попал в больницу, однако даже там продолжал работать. Наш CTO выслал ему свой личный ноутбук, потому что у Дениса был только стационарный ПК. Так получилось, что в тот момент Денис с его знаниями был очень нам нужен, и он сам не хотел прерывать работу, даже тяжело болея. Но после выписки из больницы что-то сломалось. Казалось, Денис потерял весь свой энтузиазм, его задачи простаивали и проекты не продвигались. Через какое-то время мы смогли откровенно поговорить, и оказалось, после болезни он потерял сон, а также способность нормально соображать и работать. Он обращался к врачам, но те ничего дельного не посоветовали, и на этом попытки привести себя в порядок прекратились. Мы пытались уговорить его сходить к хорошему специалисту, он только отнекивался. В итоге нам пришлось попрощаться. Сначала мы даже не убирали Дениса из рабочих чатов, надеясь, что он отдохнет, восстановится и вернется, но этого так и не случилось. Где он и что с ним сейчас, мы не знаем.

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

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

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

Вот как обстоят дела на сегодняшний день.

Waterfall

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

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

Workflow

Важно, чтобы информация по проекту была доступна и понятна всем членам команды. Для этого мы переехали на более эффективную платформу для командного управления проектами, завели корпоративную Wiki с документами / ссылками / инструкциями / чек-листами, а также ввели принцип «отчуждаемый результат»‎. Это помогло снизить bus-фактор, сделать работу более прозрачной, а также уйти от необходимости интенсивной коммуникации между сотрудниками и постоянного присутствия стейкхолдеров и CTO в обсуждении задач.

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

Аналитика

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

На первых этапах работы наши аналитики интервьюируют клиента, собирают с него функциональные и нефункциональные требования, оформляют документацию по проекту. Она разрабатывается по общепринятым мировым стандартам (UML, Waterfall), и в дальнейшем любая компания или исполнитель смогут понять, какие требования к продукту были предъявлены.

Далее мы визуализируем полученный результат на диаграммах:

• доменная модель;
• диаграмма развертывания;
• use case diagram;
• ER-модель.

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

Kubernetes + Docker

Нам удалось спроектировать гибкую и масштабируемую инфраструктуру на базе Kubernetes – решение с максимальной отказоустойчивостью и доступностью 24/7/365. Для построения и настройки кластера мы привлекали DevOps-инженеров и специалистов по кибербезопасности, а теперь его обслуживают наши штатные сотрудники. При переезде в наш кластер клиент получает круглосуточное DevOps обслуживание и бесплатный консалтинг по подготовке продукта к стандартизированному виду.

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

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

Система аккаунтинга с внутренними балансами пользователей и расчетом налогов

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

Вот только некоторые из функциональных характеристик сервиса:

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

Мы поставляли этот продукт для экосистемы проведения турниров по играм Apex Legends, где сейчас также планируем введение единой внутренней валюты с возможностью задавать курс в админке.

Агрегаторы данных

Расскажем на примере CRM-системы для участников госзакупок. Задача – собирать данные о закупках по следующим полям:

• Номер закупки
• Дата публикации
• Дата подачи заявок
• Дата торгов
• Заказчик
• Заголовок закупки/название
• Способ определения поставщика (подрядчика, исполнителя), тип закупки
• Закон
• ЭТП источник
• Этап закупки
• Контакты заказчика
• Обеспечение заявки
• Обеспечение контракта
• Позиции закупки
• Сопутствующие документы

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

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

Привет! Я Алексей Николаев, основатель и COO софтверной компании ZAKUPKI.GROUP.

Нет, наш редактор ничего не перепутал, я решил представиться в конце лонгрида. Почему? Во-первых, в век фрагментарного/клипового мышления глупо тратить на приветствие драгоценные первые строки, ведь они должны зацепить читателя и заставить дочитать текст до конца (вы уже тут, цель достигнута, ура!).

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

Один из корпоративных принципов ZAKUPKI.GROUP – рациональный нигилизм, мы подвергаем сомнению любую общепринятую практику, будь то Agile, спринты, Kanban или «Привет, я Вася Пупкин!» в начале текста.

И не то чтобы мы стараемся казаться «не такими». Просто не считаем нужным подвергаться карго-культу, а используем только самые эффективные и проверенные временем методики. Это как в медицине: есть доказательные практики, а есть капустный лист и подорожник. Так вот, мы не отрицаем Agile, он действительно может быть полезен в определенных ситуациях. Но опыт показывает, что для разработки корпоративного ПО Waterfall – самая эффективная модель, поэтому мы на нее опираемся. И так во всем остальном.

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

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

Алексей Николаев, COO ZAKUPKI.GROUP / CEO NIKSOFT

#истории #it #разработка #факап #softwaredevelopment