ЧАСТЬ 1

Добрый день, уважаемые хабровчане!

Каково это — поднимать стартап

Давно собирался структурировать и рассказать наш путь — путь команды, которая уже более 3.5 лет занимается автоматизацией технических скринингов. За это время мы собрали много практики, боли, инсайтов и решений — всё это легло в основу продукта jumse.ru (читается «Джамси» ©).  Мы делаем сервис, который помогает быстро и точно оценивать технические скиллы кандидатов — без лишнего ручного труда и с фокусом на реальную экспертизу. 

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

Мы работаем в компании ITQuick. Я — senior разработчик и тимлид в команде, где мы вместе проектируем, пишем, выкидываем, рефакторим, и снова пишем.

Один из наших ключевых форматов — быстрое усиление команд синьорами под конкретные задачи, без долгих наймов и онбординга. Здесь важно подключаться впритирку к процессам, разбираться в коде и  приносить value с первой недели.

Необходимо работать гибко — как на этапе MVP, так и на зрелых проектах с продовыми legacy-джунглями. И, конечно, бесконечно подбирать новых членов в команды, половина рабочего дня, уходящая на техсобесы — стандартная реальность.

На какой стадии сейчас находится Jumse 

На текущий момент у продукта — десятки активных клиентов, а количество пилотов в сегменте крупного B2B перевалило за сотню. В числе участников — компании из топ-30 практически каждого отраслевого сегмента.

На борту уже более 25 стеков и фреймворков, и мы продолжаем расширяться — до конца года планируем добавить ещё порядка 20. Через наш технический скрининг прошло почти 5000 разработчиков, и это число стабильно растёт.

Мы входим в совет АПКИТ, где участвуем в разработке национального стандарта сертификации разработчиков в РФ.

Алгоритмы активно используют ИИ, а точность определения грейда кандидата по результатам скрининга достигла 98% — это не просто цифра, а подтверждённый результат, сверенный с внутренними грейдами клиентов.

Дальше — только масштабирование.

Но всё это — уже сейчас, спустя 3.5 года развития продукта. Цифры, метрики, клиенты, точность — это важно. Но самое живое и по-настоящему интересное обычно кроется в начале пути.

Там — всё: боль от первых итераций, бессонные ночи с дебагом, MVP на костылях, первые пользователи (все с фидбеком «ну почти»), первые питчи, которые не взлетели, и та самая вера, которая не давала бросить.

Как всё начиналось? Рассказываю дальше.

Как мы решили делать скрининг сами

Если откатиться на 3.5 года назад, мои будни выглядели примерно так: по 3–4 технических собеседования в день. Вопросы — одни и те же, энтузиазма выдумывать новые уже не оставалось: была основная работа, команда, прод.

Сами собесы со временем стали рутиной. Кандидаты адаптировались — ответы на типовые вопросы у многих были отточены до автоматизма. Чтобы хоть как-то понять реальный уровень, приходилось уходить в сторону от скрипта и импровизировать прямо на ходу. Иногда угадывал, иногда — нет.

Параллельно — постоянный квест «найди слот»: кандидаты отпадали, потому что мы слишком долго отвечали или слот был слишком далеко. Кто-то из кандидатов вызывал симпатию, и я, неосознанно, «помогал». Кто-то — наоборот, и тут включался эффект «ну не нравится мне этот человек» (что уж скрывать, любой тимлид в какой-то момент через это проходит). Тогда всё это казалось честным и даже справедливым — сейчас понимаю, насколько много было субъективщины.

Но сильнее всего демотивировала конверсия: на выходе проходили 15–30% кандидатов. И это после фильтрации HR-ами. Причём и среди прошедших возникал вопрос — насколько эти ребята действительно умеют решать задачи?

Бывали случаи, когда кандидат на собесе уверенно рассуждал про плюсы/минусы подходов, ссылался на статьи, спорил, показывал уверенность — а потом, попав в проект, просто… не тянул.

Хуже всего, что это не сразу вскрывалось. Пока он проходил онбординг, втягивался в процессы, общался с командой, проходило 1.5–2 месяца. А потом — бац: задач не решает, саппорт проседает, коммуникация плывёт. Потери для бизнеса были вполне реальные. И вопросы — тоже реальные: кто пропустил? Почему не отсеяли?

Ответ был — я. И это, наверное, стало одной из главных точек, когда я понял: нужен другой подход.

И тут появилась мысль: а что если не просто «отказывать» тем, кто по анкете вроде бы ок, но по скринингу не дотягивает до нужного грейда. А взять и проклясть за отнятое время попробовать прокачать до нужного уровня и дать второй шанс?

Немного флэшбека. Лет 5–10 назад я, как и весь айтишный рынок, увлекался edtech’ом. Был интересный опыт: как из стажёров вырастали джуны, потом спустя пару лет возвращались уже «проситься» на мидлов.

Как практик, я ещё тогда для себя выбрал подход learning by doing — никаких видосов «на фоне», только живой код и настоящие задачи.

Так вот, возвращаясь к идее: мы выбрали несколько кандидатов, которые на первом скрининге не прошли, но по анкете выглядели «очень даже ничего». Дали им шанс, запустили эксперимент — прокачка 2–6 месяцев. Результат?

Превзошёл ожидания:

Уверенно проходили собесы на middle/senior;

Не «тонули» в испытательный срок, а наоборот — вливались в команды и брали задачи;

До сих пор все работают и, как говорят, вспоминают нас добрым словом.

Методика была предельно проста:

• дать кандидату реальный проект,

• убрать всё, что не качает,

• оставить только «мясо» по его карте компетенций (полученной после первичного скрининга).

Работать было тяжело, но продуктивно: мозг горел на 150–200%, но это и давало рост.

Сессии по 2–4 часа в день, чтобы не перегореть. Не все тянули, но кто тянул — выстреливал.

PoC показал: метод работает. Решили оцифровать и масштабировать. Остался один затык — как быстро получать подробную карту компетенций, чтобы строить ИПР (индивидуальный план развития).

С джунами всё понятно — качай всё подряд. А вот с более опытными всё сложнее: чем выше грейд, тем точечнее нужно попадать в слабые места.

Казалось бы, рынок предлагает десятки инструментов для оценки разработчиков: Codility, DevSkiller, HackerRank и другие. Мы попробовали — и довольно быстро поняли, почему ни один не подошёл.

Разделили всё многообразие на четыре условные группы:

1. HR-инструменты — автоматизируют процесс найма, но проверка в основном про теорию. Плюс, почти всегда нужно руками настраивать контент, писать вопросы, собирать сценарии — out of the box ничего не работает.

2. Live-coding платформы — интерактивно и «в духе времени», но требует участия техспециалиста. Без него оценка теряет смысл, а значит — масштаб не получится.

3. Задачи и проекты — чаще всего рассчитаны на джунов и миддлов. Оценка происходит через анализ кода кандидата, но по сути проверяются базовые теоретические или академические знания, а не прикладной опыт.

4. Edtech-платформы — море контента, но вся нагрузка по сборке, настройке и адаптации ложится на нас. Плюс они не решают задачу моментальной и точной оценки грейда.

Почему они нам не подошли:

• Закрытые вопросы → почти всегда про теорию, а не реальные скиллы.

• Таргет — в основном middle и ниже, старшие грейды остаются «за бортом».

• Контент — твоя головная боль. И писать, и обновлять, и подстраивать под специфику.

• Без живого участия часть инструментов не даст полной картины.

• А live-coding (о нём подробнее чуть позже) в нашем случае стал больше стопором, чем решением.

Всё это подвело нас к очевидному выводу: ни одна из готовых платформ не даёт точной, глубокой и автоматизированной оценки компетенций. А без этого наш подход к прокачке — просто не работал.

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

Так родилась идея: сделать свою систему оценки. Не просто «для галочки», а под наши задачи. С расчётом на масштаб, метрики, гибкость и возможность использовать тот же движок для внутренних собесов — от которых, откровенно, мы все уже начали выгорать.

Методология

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

Этот опыт — не в книгах, не в туториалах и не в «что спросить на собесе у Java-разработчика». Он живёт в головах тех, кто через всё это прошёл. Именно он отличает «читал — знаю» от «делал — понял».

В какой-то момент пришло чёткое осознание:

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

Что мы сделали? Пошли на рынок. И три с половиной года собирали этот опыт по крупицам.

С одной стороны, мы системно разобрали все популярные стеки:

• какие есть направления,

• из чего состоят,

• какие темы и подтемы внутри.

Искали только в первоисточниках — документация, репозитории, блоги авторов фреймворков. Никаких пересказов, только авторитетные источники.

Для визуализации структуры создавали ментальные карты. В итоге их накопилось порядка 170 штук, покрывающих несколько сотен тем — от базовых до узкоспециализированных, по самым разным технологиям.

Базовая структура знаний была готова. Но это был только основа.

Дальше — самое сложное:

Как собрать и структурировать практическую информацию?

И что вообще считать практикой?

С этого и началась самая интересная (и самая нетривиальная) часть пути.

Практические кейсы

Идея базы знаний началась с понимания, что её основой должна стать неделимая единица — практический кейс, оформленный, структурированный и проверенный на практике фрагмент опыта.

Мы дали ему конкретные признаки:

• он всегда привязан к одной теме/подтеме;

• он отражает либо понимание конкретного use case, либо принцип работы, либо архитектурный аспект, либо побочный эффект, либо ошибку.;

• он обязательно несёт в себе ценность для повторного использования.

Такой подход позволил нам уйти от абстрактных размышлений о «знаниях в команде» к реальной, измеримой и масштабируемой структуре.

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

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

Процесс оказался неспешным: работа с каждым экспертом занимала месяцы. Но зато сейчас у нас уже накопилось порядка 9 000 кейсов — проверенных, реальных, живых, с полей.

И всё это — по ключевым технологическим стэкам. Мы регулярно обновляем наш roadmap в зависимости от того, что происходит на рынке. А рынок, как вы знаете, на месте не стоит.

На данный момент мы уверенно покрываем бэкенд: Java, Python, .NET, Apache Kafka, RabbitMQ, PostgreSQL, SQL, Redis, разработческим инструментам, архитектурным подходам, паттернам, REST API, QA, бизнес и системной аналитике, Data Science и т.д..

Параллельно в работе ещё около 20 технологических направлений. Задача на ближайшее время — закрыть все актуальные стэки, которые есть на рынке, чтобы любой разработчик мог найти в нашей базе не теорию, а опыт, максимально приближенный к его задачам.

Ниже — фрагмент ментальной карты по языку Java. Хорошо видно, как от высокоуровневых тем мы постепенно спускаемся к более конкретным подтемам, а в самом низу — к практическим кейсам, отмеченным зелёными кубиками. Каждый такой кубик — это и есть единица знаний, оформленная по всем правилам.

Что важно: каждый кейс существует не в отрыве от контекста, а в связке с темой, в которую он встроен. Он сопровождается теоретическим пояснением, практическим кодом и, по сути, представляет собой мини-документ с полным разбором конкретной ситуации.

Вот, к примеру, один из таких кейсов — демонстрация DDoS-эффекта при десериализации в Java. В нём показано:

• как имитировать уязвимую ситуацию;

• какие условия к ней приводят;

• какие меры можно (и нужно) принять для её предотвращения.

import java.io.*;
import java.util.HashSet;
import java.util.Set;

public class DeserializationDosDemo {

    public static void main(String[] args) throws Exception {
        byte[] payload = createPayload();
        System.out.println("Payload size: " + payload.length);
        deserialize(payload);
    }

    public static byte[] createPayload() throws IOException {
        Set<Object> root = new HashSet<>();
        Set<Object> set1 = root;
        Set<Object> set2 = new HashSet<>();

        for (int i = 0; i < 999; i++) {
            Set<Object> temp1 = new HashSet<>();
            Set<Object> temp2 = new HashSet<>();

            temp1.add("VAL-" + i);
            temp1.add(temp2);
            set1.add(temp1);
            set2.add(temp1);

            set1 = temp1;
            set2 = temp2;
        }

        return serialize(root);
    }

    public static byte[] serialize(Object obj) throws IOException {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        ObjectOutputStream oos = new ObjectOutputStream(baos);
        oos.writeObject(obj);
        return baos.toByteArray();
    }

    public static Object deserialize(byte[] data) throws IOException, ClassNotFoundException {
        ByteArrayInputStream bais = new ByteArrayInputStream(data);
        ObjectInputStream ois = new ObjectInputStream(bais);
        return ois.readObject(); // Здесь произойдёт рекурсивная загрузка
    }
}

Помимо кода и объяснений, там есть выводы, архитектурные замечания и даже ссылки на связанные кейсы, если тема раскрывается шире.

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

Сетка грейдирования

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

Наш подход принципиально отличается от классической схемы «оценки разработчика». Мы не оцениваем человека — мы оцениваем знания. А уже после этого сопоставляем профиль разработчика с этой картиной и делаем выводы о грейде. Такой подход позволяет максимально объективно подойти к вопросу — без субъективных собеседований, случайных вопросов и «впечатления от кандидата».

Чтобы выстроить знания в систему, мы разработали концепцию сетки грейдирования. Она состоит из двух основных компонентов:

1. Тематики: стек → раздел → тема → подтема.

2. Четыре уровня сложности:

• Middle Base

• Middle Advanced

• Senior Base

• Senior Advanced

Дальше — всё просто. Если по определённой теме у нас есть практические кейсы соответствующего уровня сложности, мы ставим зелёный индикатор в соответствующей ячейке. Один прямоугольник — это не один кейс, а десятки или сотни, проверенных и упорядоченных. Если индикатора нет — значит, покрытие темы на данном уровне ещё не завершено.

Важно: грейды относятся не к людям, а к сложности самих кейсов. Это ключевой момент. Мы не говорим, что кто‑то «Middle» или «Senior», мы говорим, что данный кейс соответствует, например, уровню Middle Advanced по уровню сложности, абстракции и глубине.

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

Например, выбрав колонку Middle Base и пробежавшись по всем темам, можно сразу увидеть, какие практические кейсы соответствуют базовому уровню сложности типа Middle и, соответственно — что действительно нужно знать, чтобы в реальных условиях освоить указанный уровень сложности.

Определения уровня сложности кейса

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

Если представить шкалу сложности, то все грейды до Junior+ условно можно отнести к теоретической оси: это знание терминов, основ, синтаксиса, общих представлений. А начиная с Middle-, мы уже переходим в область практики, где оценивается не «знаешь ли ты», а «умеешь ли применять».

Чтобы классифицировать кейсы по уровням, мы ввели простую, но масштабируемую матрицу:

•  по горизонтали — два грейда: Middle и Senior,

• по вертикали — два уровня: Base и Advanced.

Это даёт нам четыре клетки:

1. Middle Base — простые практические кейсы, описывающие базовую механику работы с темой.

2. Middle Advanced — простые кейсы, в которых усложняется логика, добавляется вариативность или более глубокий контекст.

3. Senior Base — сложные практические кейсы, затрагивающие архитектурные аспекты, интеграцию, масштабирование, но всё ещё на уровне базовых паттернов.

4. Senior Advanced — сложные продвинутые кейсы, в которых либо описана производная механика от базовой, либо поднимаются темы высокой сложности: нестандартные ситуации, отказоустойчивость, безопасность, оптимизация.

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

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

Чтобы было понятнее, используем аналогию из школьной математики:

• Сложение и вычитание — Middle Base

• Умножение и деление — Senior Base

• Суммирование ряда или использование цикла суммирования — Middle Advanced

• Работа с дробными степенями, корнями, логарифмами, интегралами — Senior Advanced

Такая схема масштабируется на любую область: от Java и DevOps до бизнес-анализа и Data Science. Каждый практический кейс можно чётко отнести в одну из четырёх ячеек.

Чтобы проверить объективность этой модели, мы провели слепое тестирование:
дали одни и те же 100 кейсов пяти независимым экспертам и попросили разметить их по сложности.

Результат оказался практически идентичным — распределение по грейдам совпало с высокой точностью. Это подтвердило, что модель рабочая и достаточно объективна, чтобы применять её для системной оценки знаний.

Code review

Трэк

На этапе матчинга знаний разработчика с нашей базой знаний мы быстро поняли: формат закрытых вопросов — мимо. Такие вопросы проверяют лишь теорию. Да и то — скорее запоминание, чем понимание. Польза от них минимальная.

Окей, подумали мы, может, классическое собеседование? Но и тут затык: готовиться к интервью сейчас умеют даже те, кто не писал реальный код месяцами. В интернете полно подборок «топ-100 Java вопросов», «как пройти интервью в FAANG» и даже целые курсы «подготовься к собесу за неделю». А реального опыта — ноль. Формально знает, а на практике — не тянет.

И тут нас осенило: всё дело в контексте. Знание без контекста — это как велосипед без колёс: вроде бы есть, но не едет. Когда разработчик решает реальные задачи в проекте, делает код-ревью, обсуждает решения с коллегами — вот тогда и видно, что он умеет на самом деле. Там и синтаксис, и архитектура, и компромиссы — всё всплывает.

Поэтому мы решили уйти от классических форматов и сосредоточиться на code review как основе оценки. Мы даём кандидату программный код (сгенерированный по определённым правилам), и просим прокомментировать интересующие нас фрагменты. Где ошибка? Как можно улучшить? Что с архитектурой?

Такой подход показывает не только знание языка и фреймворков, но и умение думать, видеть слабые места и аргументированно выражать свои мысли. А это — куда ценнее, чем заученные ответы из «Cracking the Coding Interview».

Первый подход был… амбициозный. Мы решили сделать штуку посложнее: давали кандидату код и просили найти ошибки. Причём не просто «где тут не так», а на каждой строке — список возможных косяков: от runtime-исключений до спорного вординга переменной. Такая себе мини-квестовая система: тыкаешь в строку — выбираешь, что там не так.

На бумаге выглядело круто. В реальности — оказалось слишком жёстко. Прямо скажем, пройти такой скрининг могли единицы. По факту — процентов 5 от всех, кто пытался. Остальные — сдувались где-то на середине и оставляли фидбек в духе «вы что, с ума сошли?». Мы поняли: сделали слишком хардкорно, перебор.

Пришлось переосмыслить. Вместо того чтобы искать ошибки по чек-листу, мы стали давать контекст. Создаём ситуацию: вот код, вот задача, вот комментарий от условного коллеги. А теперь расскажи — что бы ты сделал? Что смущает? Где баг может быть неявным? Что переписал бы и почему?

Получилось не просто проще — получилось живее. Разработчики больше не чувствовали себя участниками олимпиад по алгоритмам. Это стало ближе к реальной работе. И мы сразу увидели разницу: фидбек стал положительным, вовлечённость — выше, а результат — честнее.

Суть концепции

Суть всей концепции простая: разработчик видит код — и понимает, что за этим кодом стоит. Какая архитектура? Какие бизнес-задачи он решает? Как устроено взаимодействие компонентов? Причём никаких комментариев и пояснений — всё нужно считать прямо с кода. И вот тут сразу чувствуется разница между человеком, который действительно писал боевой код, и тем, кто просто читал книжки по Java.

Дальше — интереснее. Мы подсвечиваем определённые участки кода и просим их прокомментировать. Изначально пробовали формат свободного ответа — типа, «напиши, что думаешь». Но довольно быстро поняли: не работает. Ответы получаются размытые, разного уровня, кто-то пишет простыню, кто-то одно слово. А оценить, насколько глубоко человек реально понимает механику — сложно.

Тогда мы решили уйти в более структурированный формат: не просто «что думаешь», а вот тебе набор утверждений — выбери то, что точнее всего описывает, что здесь происходит.

Причём важный момент: утверждений может быть несколько «в целом верных», но одно — наиболее точное, максимально соответствующее контексту. Где-то это может быть описание паттерна. Где-то — описание ошибки. Где-то — указание на нарушение SRP. А где-то — намёк на баг, который всплывёт только в проде через месяц.

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

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

Потому что один и тот же фрагмент кода для разных людей выглядит по-разному. Для новичка — просто строчка с циклом. Для разработчика с опытом — потенциальное место утечки памяти.

Мы это видим снова и снова: одни спотыкаются на мелочах, другие — сходу вычленяют суть, чувствуют запахи, замечают архитектурные артефакты. Именно практический опыт позволяет не просто «читать код», а понимать его как живой организм — с контекстом, компромиссами и подводными камнями.

Вот это и проверяет наша функция. Ни шаблонные курсы, ни списки вопросов с leetcode не помогут — тут нужно было реально писать, дебажить, рефакторить, жить в коде.

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

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

Вот наш тест — это смоделированная версия такой ситуации. Код, задача, немного контекста — и пошёл разбираться. Всё, как в жизни. Только без продакшн-нервов.

Когда мы продвинулись достаточно далеко и начали использовать продукт внутри своей компании, стало ясно — пора выходить в большой мир. Мы сделали первые шаги навстречу внешнему рынку, начав предлагать решение нашим партнёрам.

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

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

О том, какие вопросы нам пришлось решить, расскажем во второй части нашей статьи.