Ventara

/Как мы работаем

Шесть шагов: от первого звонка до передачи.

  1. 01

    Обследование

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

  2. 02

    Архитектура и стек

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

  3. 03

    Планирование

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

  4. 04

    Разработка и тестирование

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

  5. 05

    Развёртывание

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

  6. 06

    Поддержка и передача

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

/Форматы работы

Три способа работать с нами.

  • Фиксированный объём

    Согласованная работа за согласованную цену. Но сначала обследование: если объём неточен, честной цены не бывает.

    /Когда подходит

    Подходит для чётко очерченной задачи: конкретной интеграции, миграции, первой версии с ясной границей.

  • Time & materials

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

    /Когда подходит

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

  • Выделенная мощность

    Часть недели закреплена за вами, каждую неделю, внутри вашего процесса и на вашей доске. Стоимость предсказуема, и контекст не приходится восстанавливать заново.

    /Когда подходит

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

/Вопросы

Частые вопросы

Сколько это будет стоить?

Прайс-листа нет: два проекта с одинаковым названием редко оказываются одной и той же работой. Начинаем с короткого этапа обследования. Он платный, срок оговаривается заранее, и заканчивается он зафиксированным объёмом работ и конкретной суммой, а не диапазоном. Если сумма вам не подходит, документ по объёму остаётся у вас.

Сколько времени это займёт?

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

У меня нет технического задания. Это проблема?

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

Что входит в стоимость?

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

Что происходит после запуска?

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