Процесс · форматы · гарантии

Как мы работаем: этапы, оплата и гарантии

Порядок, который удерживает сложность под контролем: решения фиксируются до кода, а качество проверяется автоматически.

  • Договор с ИП Диденко М. С.
  • Репозиторий у вас
  • Работаем удалённо по России
Обсудить задачу → Смотреть проекты
  • ЭтапыДискавери → архитектура → реализация → качество → эксплуатация
  • ФорматыФиксированная цена по ТЗ, работа спринтами, архитектор part-time
  • Оплата50/50, 30/70 или 30/40/30 — привязана к этапам, а не к календарю
  • Гарантия2 недели на исправление ошибок, связанных с реализацией по ТЗ
  • ПраваИсключительные права на результат передаются вам по договору

Процесс

Пять этапов: от разбора домена до эксплуатации

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

  1. 01

    Дискавери

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

  2. 02

    Архитектура

    Решение фиксируется письменно до первой строки кода: модель C4 от контекста до компонентов, границы модулей, контракты gRPC и GraphQL, схема данных и план миграций. Каждый спорный выбор оформляется отдельным ADR — с альтернативами и последствиями, чтобы через полгода не спорить о том, почему сделано именно так.

  3. 03

    Реализация

    Доменный слой пишем отдельно от транспорта, схему меняем только обратимыми миграциями — в этой ERP их накопилось больше сотни на Goose, и каждая откатывается. Контракты генерируются из proto через buf, GraphQL-схема собирается gqlgen. Работающие куски показываем по ходу, а не одним пакетом в конце.

  4. 04

    Качество

    Ветка не вливается, пока не прошли линтеры, unit- и интеграционные тесты и сборка; тесты гоняются с детектором гонок. Проверка контрактов ловит несовместимое изменение proto до того, как его увидит клиент. Приёмка идёт по критериям, согласованным вместе с ТЗ, а не по ощущению «вроде работает».

  5. 05

    Эксплуатация

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

Форматы сотрудничества

Три способа купить инженерную работу

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

Фиксированная цена по ТЗ

Когда объём описывается заранее: интеграция, бот, парсер, отдельный модуль или миграция данных.

  • Как считается. Пишем и согласуем ТЗ, разбираем его на задачи, называем цену и срок до старта работ.
  • Риск объёма — на нас. Недооценили трудоёмкость в рамках согласованного ТЗ — доделываем без доплаты.
  • Изменения — отдельно. Новое требование не «дописывается по ходу», а оформляется дополнением со своей ценой и сроком.
  • Не подходит для исследовательских задач, где ТЗ рождается только в процессе.
Обсудить ТЗ
чаще всего

Работа спринтами

Продуктовая разработка, где требования уточняются на ходу: доменные модули ERP, платформы, длинные проекты.

  • Как считается. Оплачивается время работы в спринте фиксированной длины; в конце каждого — демо на стенде и обновлённый план.
  • Риск объёма — у вас, риск качества — на нас. Приоритеты вы меняете между спринтами, планка кода держится CI-гейтами.
  • Выход в любой момент. Остановиться можно на границе спринта; код, миграции и документация уже лежат в вашем репозитории.
  • Подходит, когда систему нужно вводить в работу по частям, а не одним запуском.
Обсудить спринты

Архитектор part-time

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

  • Как считается. Оговорённое количество часов в неделю с понятной повесткой: разбор архитектуры, схема данных, ADR.
  • Что входит. Ревью ключевых merge request'ов, границы модулей, план миграций, участие в технических собеседованиях.
  • Риск сроков — у вас. Реализацию ведёт ваша команда; мы отвечаем за решения и за то, что они записаны, а не рассказаны на созвоне.
  • Не заменяет разработку: если писать код некому, это другой формат.
Обсудить формат

Оплата

Деньги идут за этапами

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

  • 50 / 50Половина при старте, половина после приёмки. Короткие работы на две-три недели: бот с интеграцией в amoCRM, отдельный обмен, доработка одного модуля. Дробить такой объём на большее число платежей — только создавать бумажную работу.
  • 30 / 70Аванс 30 %, остальное после приёмки. Так устроена оплата парсинга: результат проверяется одним прогоном на ваших данных и либо соответствует ТЗ, либо нет — промежуточная веха здесь ничего не измеряет.
  • 30 / 40 / 30Три платежа: старт, промежуточная веха с демо, приёмка. Схема для проектов от нескольких месяцев — по ней рассчитана платформа для онлайн-школ на Telegram. Средний платёж закрывается не датой в календаре, а работающей частью системы.

30/40/30чаще всего на длинных проектах

Платёж привязан к этапу, а не к календарю: этап закрывается, когда выполнены критерии приёмки, согласованные вместе с ТЗ. Работаем по договору с ИП Диденко М. С., после приёмки этапа подписываем акт. Для Telegram-ботов и парсинга цены опубликованы на страницах услуг. Для ERP, интеграций, backend-разработки, баз данных и аудита фиксированных прайсов нет — там продаётся платный вход с фиксированной стоимостью, которую считаем после короткого созвона.

Стоимость зависит от объёма работ, состояния текущих систем и требований к срокам. Информация на сайте не является публичной офертой.

Гарантия и приёмка

Что мы обещаем письменно

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

Что покрывает гарантия

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

Промежуточные демо

На каждой вехе показываем не слайды, а систему на стенде: вы нажимаете сами, на своих данных или на приближенных к ним. Демо нужны для того, чтобы расхождение в понимании задачи всплывало на второй неделе, а не на приёмке.

Приёмка по согласованным критериям

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

Что гарантия не покрывает

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

Права на результат

Всё, что сделано, остаётся вашим

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

Репозиторий на вашей стороне

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

git · доступ с первого дня

Исключительные права по договору

Права на созданный код передаются вам договором с ИП Диденко М. С. Никаких лицензий на «платформу», скрытых ядер и обязательной подписки на сопровождение: развивать систему вы можете с кем угодно.

договор · акт · передача прав

Документация и ADR по ходу

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

C4 L1–L4 · ADR · runbook

NDA — до обсуждения деталей

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

NDA · по запросу

Старт

Что нужно от вас, чтобы начать

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

  • ЗадачаЧто должно работать иначе, чем сейчас, — в терминах процесса, а не кнопок. «Кладовщик вводит приход дважды» полезнее, чем «нужна форма с автозаполнением».
  • СистемыЧто уже есть: 1С, CRM, кассы, самописные сервисы, обмен файлами, базы данных. Названия и роли — сразу, версии и доступы — потом.
  • ОбъёмыСколько документов, заказов или строк проходит в сутки, где пики, что нельзя останавливать даже на час. От этого зависит архитектура, а не только цена.
  • СрокиЕсть ли дата, к которой нужно, и чем она обусловлена: сезон, отчётность, обязательство перед вашим клиентом. Дата без причины обычно двигается, дата с причиной — нет.
  • РамкаБюджетная рамка, даже приблизительная. Она не поднимает цену — она отсекает решения, которые в неё не помещаются, и экономит обеим сторонам неделю переговоров.
  • РешениеКто со стороны заказчика принимает архитектурные и приоритетные решения. Нужен один человек с правом сказать «да», а не комитет с правом сказать «подумаем».

Возражения

Неудобные вопросы, которые всё равно возникнут

Лучше ответить на них здесь, чем услышать после первого созвона в виде вежливого «мы подумаем».

Bus factor: что будет с проектом, если вы пропадёте?

Репозиторий заводится на вашей стороне в первый день работы, а не отдаётся архивом при сдаче. Архитектура зафиксирована в модели C4 и корпусе ADR, схема базы — в обратимых миграциях, контракты — в proto и GraphQL-схеме. Передача проекта другому Go-разработчику занимает несколько дней: он читает принятые решения, а не реконструирует их по коду.

Студия — это ведь один человек?

Да, и мы это не прячем. Архитектуру, ключевые решения и ревью ведёт Максим Диденко — 9+ лет в разработке, с 2015 года. На реализацию при необходимости подключаются проверенные подрядчики, но точка ответственности одна, и между вами и инженером нет менеджерской прослойки, которая пересказывает задачу своими словами.

Почему нельзя назвать срок сразу, в первом письме?

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

Что будет, если результат первого этапа не устроит?

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

У нас уже есть код, и он плохой. С чего начинать?

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

Дальше

Куда идти с конкретной задачей

Если ваша задача другая — все услуги →

Контакты

Опишите задачу — предложим формат, этапы и оценку.

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

Телефон+7 923 805-29-19 Почтаsupport@maincode.ru
РегионРеспублика Хакасия
РеквизитыКонтакты → Написать письмо →