Загружаем каталог…
Задачи в одном инструменте, документация в другом, обсуждение в третьем. Классическая ситуация, где половина контекста задачи живёт в переписке, документация устаревает через неделю, а на вопрос «почему мы так решили» ответа не находится. Плюс расстановка приоритетов сводилась к спору на встрече, где выигрывал самый настойчивый.
Типовая картина у подрядчика: смета в одной программе, закупки во второй, бухгалтерия в 1С, исполнительная документация — папками на диске. Между системами руки: объём из сметы переносят в спецификацию вручную, КС-2 собирают по журналу вручную, маржу считают в таблице, потому что ни одна система не знает выручку и себестоимость одновременно. Каждый перенос руками — место, где число меняется молча, и к закрытию месяца расхождения уже не найти. Рынок при этом разделён: облачные системы удобны, но не знают российских форм, а 1С формы знает, но требует сервера и внедренца.
Инфраструктура росла без DevOps: сервисы поднимали по мере надобности, каждый своим compose-файлом, настройки правили руками на сервере. Снаружи всё работало, ошибок не было, поэтому и повода заглянуть внутрь не возникало. Первый DevOps пришёл в систему, которая годами жила на том, что ничего не падало.
Основной бизнес компании — подбор специалистов под задачи клиентов. Пока подбор ведётся вручную, его скорость ограничена временем менеджера. Отсюда возникла идея платформы, которая автоматизирует этот процесс.
Значительная часть рынка вакансий и проектных запросов живёт в Telegram-каналах. У каждого канала свой формат, поэтому объявления приходилось читать и переносить в платформу вручную.
Защита персональных данных. Платформа получает резюме с полным набором персональных данных: ФИО, телефон, почта, дата рождения, гражданство, фото. Показывать их заказчику до этапа отбора нельзя — и по 152-ФЗ, и по существу: обезличенное резюме снижает предвзятость на первичном скрининге. Ручная чистка не масштабируется: на одно резюме уходит около 15 минут, и человек всё равно что-нибудь пропускает.
Стандарт постановки задач жил в голове тимлида. Новичку его объясняли на словах в первую неделю, и он всё равно писал задачи по-своему: «сделать авторизацию» вместо разбивки на шаги с критериями приёмки. Лид переписывал примерно половину задач — не потому что новичок плохой, а потому что стандарт нигде не записан. На онбординг одного человека уходило три-четыре недели до состояния «задачи можно не проверять».
Ревью раз в полгода, оценка — со слов руководителя. Он помнит последние два спринта и самые громкие истории, остальное стирается. Спорные грейды разбирались на встречах, где обе стороны опирались на впечатления: «он много тащит» против «я закрыл больше задач». Данные о том, кто сколько ревьюит и чей код возвращается на доработку, лежали в GitLab и Jira, но никто их не сводил — руками это несколько дней на команду.
Поиск тендеров означал ручной обход десятка с лишним площадок: СберТендер, РосТендер, закупки Газпрома, Bidzaar и ещё несколько похожих. На каждой свои фильтры, своя выдача, свой личный кабинет. Человек тратил время не на оценку тендеров, а на то, чтобы их вообще собрать в одном месте. Напрашивался внутренний бот: задал фильтры один раз, он ищет сразу по всем площадкам и приносит подходящее одним списком.
Вакансии заведены в платформе, аудитория живёт в Telegram. Публиковали руками — значит раз в неделю пачкой, с опечатками и без обновлений. Главная боль была не в трудозатратах: закрытая вакансия продолжала висеть в канале и собирать отклики. Рекрутер тратил время на людей, которым уже нечего предложить, а кандидат получал отказ по вакансии, которой не существует.
Наполнение каталога. В каталоге HR-решений было 26 продуктов. Каталог с 26 карточками не каталог — им нельзя пользоваться и его нечем продавать. Единого справочника HR-tech решений в России не существует, а руками такой объём собрать невозможно: на одну карточку с проверкой уходит около 15 минут, то есть тысяча карточек — это больше двух месяцев работы одного человека без выходных.
Ревью кода делали руками, а на мелких проектах не делали вовсе. Причина не в лени: старших разработчиков ограниченное число, и их время уходит на крупные продукты. В результате получалась вилка — либо снимать старшего с основной работы ради небольшого проекта, либо мириться с тем, что часть кода не смотрит никто. Кадровая сторона этой вилки была даже неприятнее технической. Джуниор растёт на обратной связи, а получал он её редко и с задержкой в несколько дней, когда контекст задачи уже выветрился. На мелких проектах, куда обычно и сажают новичков, обратной связи не было в принципе: человек
Ежемесячная отчётность по проектам — процесс, где все всё знают и всё равно забывают. Координатор тратил около трёх дней в месяц на обход сорока рабочих чатов и сведение таблицы «кто сдал». Задача была не в самих отчётах, а в дисциплине их сдачи: напоминание работает, но только если его кто-то отправляет.
Онбординг жил в почте, чатах и головах конкретных людей. Новичок не знал, к кому идти с отпуском. HR вручную заводил почту и собирал анкеты. Руководитель не мог ответить, прошла ли его команда обязательные инструктажи — формально процесс был, данных о нём не было. При этом любой отдельный шаг казался мелочью, поэтому годами никто за это не брался.
Объявления — обновление регламента, переезд офиса, опрос, напоминание о дедлайне — нужно донести до всех рабочих чатов компании. Делали копипастом: человек открывает чат за чатом и вставляет один и тот же текст. Уходило около получаса, к середине списка формулировка успевала измениться, пара чатов всегда оставалась пропущенной, и никто не мог сказать, куда объявление реально дошло. Отдельная сложность — время отправки: готово оно вечером, а прочитать его должны утром.
В платформе письма расползлись по коду: текст в сервисном слое, вёрстка в хелпере, отправка в трёх местах по-разному. Поменять формулировку письма стало задачей для разработчика с релизом, а на вопрос «какое письмо ушло этому пользователю и когда» никто не мог ответить. Решили вынести уведомления в отдельный сервис.
Заявки в ИТ-службу приходили в личные сообщения. Поток заметный, значительная часть обращений повторялась из раза в раз — одни и те же вопросы про доступы, оборудование и настройки. Разгребать всё вовремя не получалось, часть заявок терялась в переписке, а понять реальную нагрузку было невозможно: обращения нигде не считались, и разговор о том, нужен ли ИТ-службе ещё человек, упирался в отсутствие цифр. Из такой ситуации напрашивается очевидный ответ: единое окно заявок. Очередь, приоритеты, категории, база типовых решений, отчётность. Ровно то, что описано в любом учебнике по организации п
База партнёров и подрядчиков жила в Excel-таблице с полутора десятками разнородных колонок — от «наличие собственной команды разработки» до «в каких направлениях хочет развиваться». Пользоваться ей мог только тот, кто её вёл. Под конкретную задачу — «нужен подрядчик в Казани, работает с НДС, есть команда, стек Java» — приходилось глазами читать всю таблицу, и это занимало минут сорок.
Коммерческие системы медиамониторинга стоят от нескольких сотен тысяч рублей в год и всё равно не покрывают нужные площадки — особенно нишевые отраслевые. При этом сама задача несложная: искать ключевые слова в известных местах и складывать найденное в одно окно.
Реестр договоров, спецификаций и актов вёлся в Excel. Любой вопрос вида «какие договоры были с этим заказчиком за прошлый год и на какую сумму» означал, что человек открывает файл и читает его глазами, сопоставляя три таблицы между собой. Занимало это минут двадцать, отвечать могли полтора человека, и они же были узким местом — а справки такого рода запрашивают регулярно.
Корпоративным порталом пользуются, только если в него удобно заходить, а рабочая коммуникация компании идёт в Telegram. Задача была не переписать платформу, а дать доступ к её функциям там, где сотрудники уже находятся.
Внешний заказчик планировал мероприятие по маршруту: участников нужно было вести по этапам, вовремя выдавать материалы и держать всю группу в одном канале связи. Мероприятие было привязано к конкретной дате.
Административные задачи ИТ-компании — оценку трудоёмкости проектов, согласования, протоколы встреч, отчётность — обычно закрывают набором покупных систем. Компания решила собрать собственное решение.
В распределённой команде решения принимаются на созвонах, но их итоги часто нигде не фиксируются. Нужен был простой способ сохранять содержание встреч — без отдельного приложения и обучения.