Контекст · План · Результат

Промышленная/
разработка ПО

Инженерная команда для компаний, которые выросли быстрее своих систем.

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

Начинаем с вводного анализа: за две-четыре недели разбираемся, из чего состоит ваша система, как организована работа над ней и в какой последовательности её имеет смысл менять.

Зачем мы это делаем

Мы помогаем компаниям перестать бояться собственных систем.

Когда система непонятна, любое изменение превращается в риск.

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

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

Речь не о красивом коде, а о том, чтобы бизнес снова мог принимать решения быстро.

Мы подходим, если

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

Мы не подходим, если

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

Вводный анализ

Две-четыре недели. Мы не меняем код и не вмешиваемся в текущие процессы — на этом этапе мы собираем данные.

Этап 1
Система
Изучаем код, документацию и историю изменений. Строим карту: какие сервисы существуют на самом деле, как они связаны, где границы размыты настолько, что изменение в одном месте ломает другое. Собираем перечень внешних интеграций и оцениваем последствия отказа каждой.
Этап 2
Процессы и команда
Разбираем, как устроена работа: трекер задач, релизный цикл, порядок принятия технических решений. Считаем долю задач, возвращённых на доработку, и сроки прохождения изменений. Разговариваем с разработчиками, аналитиками и тестировщиками: знание о системе распределено между ними, и до уровня бюджетных решений доходит редко.
Этап 3
Выводы
Сводим наблюдения в три документа и разбираем их вместе с вами и вашей командой. К этому моменту у вас есть материал для планирования на ближайшие месяцы — независимо от того, продолжаем мы работу или нет.

Три документа на выходе

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

Что нужно от вас

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

Чего не требуется

Готовить документацию, приводить репозитории в порядок перед нашим приходом и объяснять, как сложилось исторически. Мы работаем с тем, что есть.

Что именно мы оцениваем

Десять показателей состояния системы. По каждому — что мы считаем проблемой.

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

Дальнейшая работа

Инженеры в составе вашей команды

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

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

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

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

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

Новые продукты

MVP, который не придётся переделывать

Большинство первых версий делают в расчёте на то, что от них впоследствии откажутся. Не отказываются.

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

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

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

Это почти не удорожает первую версию. Это меняет то, что происходит со второй.

Искусственный интеллект

Инструменты генерации кода снимают ограничение по скорости набора. Ограничение по качеству решений они не снимают.

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

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

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

Технологии

Языки и платформы: Java, Go и связанная с ними экосистема
Клиентская часть: React, Angular
Хранение и обмен данными: Реляционные и документные СУБД, брокеры сообщений, потоковая обработка
Интеграционный слой: Внешние API, протоколы обмена, связывание систем, которые не проектировались работать вместе

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

Как устроены расчёты

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

Границы ответственности

Чего мы не гарантируем

Точную оценку до изучения системы: Любая цифра, названная до вводного анализа, останется догадкой. После него это оценка с понятной погрешностью, и мы объясняем, из чего она складывается.
Что все рекомендации будут выполнены: Часть решений упирается в бюджет, сроки и договорённости, к которым мы отношения не имеем. Мы показываем последствия каждого варианта; выбор остаётся за вами.
Неизменность сроков при изменении объёма: Если состав работ меняется по ходу, меняются и сроки. Мы сообщаем об этом в день, когда это становится понятно, а не при сдаче.
Отсутствие дефектов, возникших до нас: Состояние системы на момент начала работ фиксируется документально и согласуется с вами. Это защищает обе стороны: видно, за что мы отвечаем, и за что не отвечаем.

Мы перечисляем это до начала работы, а не в момент, когда что-то пошло не так. Подрядчик, который обещает всё, обычно не отвечает ни за что.

Принципы

01Идеальный код не является целью. Мы выбираем решение под задачу и срок, а не под профессиональные амбиции.
02Мы не берём денег за усложнение. Если задача решается проще, мы сообщаем об этом, даже когда сложный вариант выгоднее нам.
03Сначала спецификация, затем реализация. Не из склонности к документам, а потому что переработать описание дешевле, чем систему.
04О возникших проблемах сообщаем немедленно. Срок, который перестал быть реалистичным, обсуждается в день, когда это стало понятно.
05Решения объясняются на языке последствий. Не «требуется рефакторинг», а «через полгода это будет стоить втрое дороже, и вот почему».
06Результат должен пережить наше участие. Система, которую невозможно развивать без нас, — это плохо выполненная работа.

О команде

Инженеры с опытом в архитектуре, системном анализе и разработке нагруженных бэкендов.

Основная специализация — проектирование распределённых систем и интеграционных решений в B2B: там, где данные ходят между десятками сервисов и внешних систем, а цена ошибки измеряется не в багрепортах.

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

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

Вопросы

Что такое Planel?: Инженерная команда, которая возвращает управляемость разработке в компаниях со сложившимся продуктом. Начинаем с вводного анализа системы и плана работ, дальше ведём проект своими инженерами в составе вашей команды. Отдельное направление — разработка первых версий продукта с расчётом на дальнейшее развитие.
Чем вы отличаетесь от аутстаффинга?: Аутстаффинг предоставляет специалистов, а подбор, управление и ответственность за результат остаются на вашей стороне. Мы принимаем на себя состояние тех частей системы, которыми занимаемся, и участвуем в выработке технических решений вместе с вашим руководством, а не только в их исполнении.
Сколько это стоит?: Оплата почасовая, включая вводный анализ. Ставка зависит от состава участников: на первом этапе это обычно один-два человека. Ориентир по стоимости и срокам называем после разговора на двадцать минут.
Почему вы не работаете по фиксированной цене?: Потому что до изучения системы любая фиксированная оценка оказывается либо завышенной, либо неточной, и оба варианта невыгодны вам. Фиксированная цена также превращает каждое уточнение требований в спор о том, входило оно в объём работ. Мы предпочитаем прозрачный учёт времени.
С какими по размеру проектами вы работаете?: От отдельного модуля до системы из нескольких десятков сервисов. Небольшие задачи берём, если понятно, какую проблему они решают и как результат будет использован дальше.
У нас уже есть команда. Зачем нам вы?: Как правило, затем, что команда находится слишком близко к системе. Специалисты, развивавшие продукт несколько лет, не видят его со стороны, и им затруднительно сообщить о собственных ошибках тому, кто принимает бюджетные решения. Внешняя оценка стоит недорого и часто окупается одним найденным решением.
Не воспримет ли наша команда это как проверку?: Мы не проводим аттестацию специалистов и не даём персональных оценок — в документах не фигурируют имена. На практике разработчики оказываются основным источником сведений при анализе: им обычно есть что сказать о состоянии системы, и наличие адресата для этого воспринимается положительно.
Вы будете переписывать систему с нуля?: Практически никогда. Переписывание работающей системы — наиболее затратный и рискованный сценарий, и предлагают его обычно там, где не хотят разбираться в существующем коде. В плане работ всегда присутствует вариант «сохранить без изменений» для частей, которые работают и развиваться не будут.
На каких технологиях вы работаете?: Основной бэкенд — Java со всем её окружением и Go. Фронтенд — React и Angular. Отдельная компетенция — интеграции и обмен данными между системами. Стек подбираем под задачу: если у вас работает решение на другой технологии, переписывать его ради нашего удобства мы не предложим.
Работаете ли вы с искусственным интеллектом?: Ежедневно. При этом исходим из того, что инструменты генерации кода снимают ограничение по скорости набора, но не по качеству решений. Подробнее — в разделе выше.
Можно посмотреть ваши работы?: Проекты, которые мы ведём, закрыты соглашениями о неразглашении, поэтому публичных описаний нет. Вместо них мы подробно излагаем метод: по этому тексту видно, как мы работаем, и этого обычно достаточно, чтобы решить, стоит ли продолжать разговор.
Что если результат вводного анализа нас не устроит?: Документы остаются у вас независимо от того, продолжаем мы работу или нет. Вводный анализ — законченный результат, а не заявка на длительный контракт.

Расскажите, что происходит с вашей разработкой.

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

hello@planel.io @planel_io

Промышленная/разработка ПО