Рассказываем, как выбрать компанию для разработки программного обеспечения и оценить подрядчика до заключения договора: команда, архитектура, сроки, стоимость, тестирование, безопасность и поддержка.
На этапе выбора исполнителя заказчик обычно сравнивает портфолио, сроки и стоимость. Это важные параметры, но они не показывают, насколько качественно будет организован сам проект.
Проблемы в заказной разработке редко начинаются с того, что команда не может реализовать отдельную функцию. Чаще они возникают из-за неполных требований, неучтенных интеграций, неверно выбранной архитектуры или отсутствия общего понимания результата. Система постепенно усложняется, сроки смещаются, а каждая новая доработка затрагивает уже работающие модули.
Поэтому компанию по разработке программного обеспечения следует оценивать не только по завершенным проектам. Важно разобраться, как исполнитель изучает задачу, фиксирует требования, принимает технические решения, управляет изменениями и готовит систему к дальнейшей эксплуатации.
Ниже разберем 11 критериев, которые помогают оценить ИТ-подрядчика до заключения основного договора.
Содержание
2. Качество аналитики и требований
4. Обоснованность сроков и стоимости
6. Прозрачность процесса разработки
7. Тестирование и контроль качества
8. Информационная безопасность
10. Передача системы заказчику
В начале проекта заказчик часто описывает будущую систему через функции. Нужны личный кабинет, заявки, отчеты, уведомления, несколько ролей пользователей и обмен данными с внутренней учетной системой.
Такого описания достаточно для первого обсуждения, но недостаточно для проектирования. Одни и те же функции могут обслуживать совершенно разные процессы.
Например, заявка может создаваться одним пользователем и сразу уходить исполнителю. В другой компании она проходит проверку, согласование бюджета, юридическую экспертизу и только после этого поступает в работу. Внешне в обеих системах есть раздел «Заявки», но объем бизнес-логики, ролей и исключений отличается в несколько раз.
Поэтому перед оценкой разработки ПО для бизнеса подрядчик должен разобраться в текущем порядке работы. Кто создает данные, кто их проверяет, какие решения принимаются на каждом этапе, где возникают задержки и какие действия сотрудники выполняют вручную.
Результатом такого обсуждения становится модель процесса. В ней видны участники, статусы, переходы, исключительные ситуации и данные, которые должны передаваться между подразделениями или информационными системами.
Компетентная команда также уточнит, какой результат должен получить бизнес. Сам по себе запуск нового сервиса не является измеримым результатом. Им может быть сокращение срока согласования заявки, снижение количества ручных операций, объединение данных из нескольких источников или повышение прозрачности конкретного процесса.
Именно поэтому разработка программного обеспечения для бизнеса начинается с изучения операционной задачи. Иначе есть риск автоматизировать неэффективный процесс, не устранив его основные ограничения.
Следующий критерий — качество предпроектной аналитики. Ее задача заключается не в подготовке максимально большого документа, а в устранении критичной неопределенности до начала программирования.
Качественная разработка требований к программному обеспечению должна описывать пользователей системы, их права, основные операции, правила обработки данных и результат каждого действия. Отдельно фиксируются ограничения по производительности, безопасности, размещению и интеграциям.
Большое значение имеют исключительные ситуации. Что произойдет, если пользователь дважды отправит одну заявку? Можно ли изменить документ после согласования? Как система поведет себя, если внешняя база временно недоступна? Кто увидит запись, созданную сотрудником из другого подразделения?
Такие детали часто не попадают в первоначальное описание, но именно они формируют значительную часть бизнес-логики.
Например, требование «пользователь формирует отчет за выбранный период» выглядит понятным. Но для разработки необходимо определить источник данных, момент их фиксации, доступные фильтры, формат выгрузки и правила пересчета. Если исходные данные изменились через месяц, ранее сформированный отчет должен обновиться или остаться в первоначальном виде? Для бухгалтерской, управленческой и операционной отчетности ответы будут разными.
Формат документации зависит от проекта. В одном случае готовится подробное техническое задание на разработку программного обеспечения. В другом требования хранятся в виде пользовательских сценариев, прототипов, спецификаций и критериев приемки. Главное, чтобы команда и заказчик одинаково понимали границы проекта и могли проверить готовый результат.
Перед стартом разработки можно попросить пример аналитических материалов по предыдущему проекту. Обезличенный фрагмент технического задания, описание сценария или матрица ролей первично покажут качество работы.
Технологический стек сам по себе мало говорит о качестве решения. Перечень из PostgreSQL, React, Kubernetes, Kafka и нескольких языков программирования показывает, с какими инструментами знакома команда, но не объясняет, зачем они нужны конкретной системе.
Архитектура программного обеспечения определяет, из каких компонентов состоит решение, где хранятся данные, как модули взаимодействуют между собой и что произойдет при отказе одного из элементов.
На этапе выбора подрядчика полезно попросить хотя бы укрупненную схему. На ней должны быть видны пользователи, внешние системы, основные программные компоненты, базы данных и направления обмена информацией.
Для таких схем часто используется модель C4. Она позволяет показывать архитектуру с разной степенью детализации. Для обсуждения с заказчиком обычно достаточно контекстной схемы системы и схемы основных приложений и хранилищ. Более глубокая детализация нужна уже технической команде.
При этом сложная архитектура не является преимуществом сама по себе. Микросервисы дают возможность независимо развивать отдельные части платформы, но одновременно усложняют развертывание, мониторинг, обмен данными и обработку ошибок. Для корпоративной системы, которую развивает одна команда, модульный монолит иногда оказывается более надежным и экономичным вариантом.
Качество проектирования архитектуры ПО видно по тому, насколько аргументированно подрядчик объясняет свои решения. Команда должна учитывать объем данных, предполагаемую нагрузку, требования к отказоустойчивости, ограничения инфраструктуры и планы развития продукта.
Если ожидается разработка высоконагруженных систем, следует отдельно обсудить модель нагрузки. Недостаточно сказать, что решение можно масштабировать. Нужно понимать, сколько пользователей будет работать одновременно, какие операции создают основную нагрузку, какой объем данных хранится и какие внешние сервисы могут ограничивать производительность.
Еще один полезный вопрос касается отказов. Что произойдет, если недоступна база данных, 1С, внешний API или очередь сообщений? Сохранится ли операция, сможет ли система повторить ее позднее и увидит ли оператор причину ошибки?
Стоимость разработки программного обеспечения зависит не только от количества функций. На нее влияют глубина аналитики, число ролей, интеграции, объем данных, требования к безопасности, инфраструктура, миграция и порядок приемки.
Поэтому точная оценка крупной системы после короткого созвона должна вызывать вопросы. На этом этапе подрядчик еще не знает всех правил процесса и может рассчитать стоимость только на основании собственных предположений.
Предварительная оценка допустима в виде диапазона. После аналитики она должна быть уточнена и разложена на отдельные этапы и модули. Заказчику важно видеть, какие работы включены в расчет и что считается результатом каждого этапа.
Например, оценка интеграции не должна учитывать только написание программного кода. До разработки потребуется изучить интерфейс внешней системы, определить формат обмена, согласовать ответственность сторон, получить тестовые доступы и проверить обработку ошибок. Если часть этих действий зависит от другого подрядчика или внутренней ИТ-службы заказчика, это должно быть указано в плане.
При сравнении предложений необходимо убедиться, что услуги по разработке программного обеспечения имеют одинаковый состав. В одной оценке могут быть учтены аналитика, дизайн, тестирование, развертывание и гарантийная поддержка. В другой — только непосредственная реализация функций.
Особенно часто за пределами первоначального бюджета остаются миграция исторических данных, настройка промышленной инфраструктуры, подготовка инструкций, нагрузочные испытания и приобретение сторонних лицензий.
Также нужно заранее определить порядок изменения требований. В длительном проекте новые задачи неизбежны. Важно не запретить изменения, а установить понятный процесс. Новое требование оценивается, после чего заказчик понимает, как оно повлияет на бюджет, сроки и состав текущего релиза.
В BPA основные риски заказной разработки учитываются еще до начала реализации. На этапе аналитики мы уточняем бизнес-логику, интеграции, объем данных, требования к безопасности и будущей нагрузке, после чего фиксируем ограничения, зависимости и критерии приемки. Такой подход позволяет заранее увидеть потенциальные точки роста бюджета и сроков, выбрать подходящую архитектуру, спланировать передачу документации и снизить зависимость заказчика от конкретных специалистов после запуска.
На переговорах заказчик обычно общается с руководителем направления, коммерческим директором или опытным архитектором. Это еще не означает, что данные специалисты будут ежедневно работать с проектом.
До подписания договора желательно познакомиться с руководителем проекта, аналитиком и техническим лидером, которые войдут в рабочую команду. Для крупной разработки ПО на заказ именно эти специалисты определяют качество требований, архитектуры и коммуникации.
Технический лидер должен понимать основные ограничения проекта и уметь объяснить предлагаемый подход. Аналитик — показать, как будет изучать процесс и фиксировать требования. Руководитель проекта — описать порядок планирования, демонстрации результатов и работы с изменениями.
Следует также уточнить, кто будет выполнять фронтенд- и бэкенд-разработку, тестирование, настройку инфраструктуры и подготовку релизов. Необязательно выделять отдельного специалиста на каждую роль, особенно в небольшом проекте. Однако за каждую область должен отвечать конкретный участник команды.
Отдельный вопрос касается загрузки специалистов. Архитектор может присутствовать на первой встрече, но затем участвовать в проекте несколько часов в месяц. Если его экспертиза критична, необходимо понимать, на каких этапах и в каком объеме он будет подключаться.
Прозрачность не означает ежедневный контроль каждого действия команды. Заказчику нужен доступ к информации, которая позволяет понимать текущее состояние проекта и вовремя принимать решения.
Управляемый процесс разработки программного обеспечения обычно строится короткими итерациями. Команда регулярно показывает работающий результат, обсуждает замечания и согласовывает состав следующего этапа. Чем раньше заказчик увидит новую функцию, тем дешевле исправить неверное понимание требований.
На старте необходимо определить, где хранятся задачи, как фиксируются договоренности и с какой периодичностью проводятся демонстрации. Также следует согласовать ответственных с обеих сторон. Если решение по требованиям неделями ожидает подтверждения заказчика, это будет влиять на срок так же, как и задержка со стороны разработчиков.
Этапы разработки программного обеспечения могут включать аналитику, проектирование, дизайн, реализацию, тестирование и внедрение. При этом они не всегда выполняются строго последовательно. В крупном проекте аналитика следующего модуля может идти одновременно с разработкой и тестированием предыдущего.
Для оценки инженерного процесса можно смотреть не только на соблюдение календарного плана. В современной практике также отслеживают частоту выпусков, скорость прохождения изменений до рабочей среды, долю проблемных релизов и время восстановления после сбоя.
ЛПР необязательно погружаться в технические метрики. Но подрядчик должен уметь ответить, насколько регулярно выпускаются новые версии, сколько релизов требуют срочных исправлений и как быстро команда восстанавливает систему после ошибки.
Качественная разработка и тестирование программного обеспечения идут параллельно. Если проверка начинается только после завершения всей системы, команда слишком поздно обнаруживает ошибки в требованиях, модели данных и взаимодействии модулей.
На уровне разработки изменения должны проходить проверку другим специалистом. Такой анализ помогает находить не только синтаксические ошибки, но и проблемы в бизнес-логике, безопасности и структуре кода.
Автоматические тесты особенно полезны для функций, которые регулярно изменяются. Они позволяют быстро проверить, не нарушила ли новая доработка уже работающий сценарий. Однако высокий процент покрытия кода сам по себе не гарантирует качество. Можно проверить десятки простых функций и не протестировать операцию, от которой зависит ключевой бизнес-процесс.
Поэтому тестирование должно строиться вокруг рисков.
В платежном сервисе особенно важно исключить повторное списание. В складской системе — расхождение фактических и учетных остатков. В корпоративном кабинете — доступ сотрудника к данным другой организации. Подрядчик должен уметь назвать такие критичные сценарии и объяснить, как они проверяются.
У проекта также должны быть отдельные среды для разработки, тестирования и промышленной эксплуатации. Проверять новую версию непосредственно на рабочей системе опасно. Ошибка в миграции базы данных или настройке конфигурации может затронуть реальных пользователей и данные.
Для уже существующей системы может потребоваться аудит кода. В таком случае проверяется не только аккуратность написания программы, но и архитектура, безопасность, технический долг, зависимости и возможность воспроизвести сборку на другой инфраструктуре.
Перед началом доработки подрядчик должен определить, что выгоднее — развивать текущую систему, провести рефакторинг отдельных модулей или постепенно заменить наиболее проблемные компоненты.
Информационную безопасность нельзя полностью добавить в готовый продукт после завершения разработки. К этому моменту уже выбраны способы хранения данных, модель авторизации, внешние интерфейсы и сторонние библиотеки.
Безопасная разработка программного обеспечения начинается с определения того, какие данные обрабатывает система, кому они доступны и какие последствия может вызвать их утечка или изменение.
На этапе проектирования должна появиться модель ролей и прав. Администратор, руководитель подразделения, оператор и внешний пользователь не могут иметь одинаковый доступ. Кроме того, система должна ограничивать действия не только на уровне интерфейса, но и на стороне сервера. Скрытая кнопка не является механизмом защиты.
Также важно понимать, где хранятся пароли, ключи доступа и токены внешних систем. Они не должны находиться непосредственно в исходном коде или открытых конфигурационных файлах.
Для критичных решений проверяются сторонние зависимости, ведется журнал действий пользователей, настраивается резервное копирование и определяется порядок установки обновлений безопасности.
Требуемый объем мер зависит от проекта. Для небольшого внутреннего сервиса и государственной системы в закрытом контуре требования будут различаться. Но подрядчик должен поднять вопросы безопасности до старта разработки, а не после подготовки первой промышленной версии.
Большинство корпоративных систем обмениваются данными с 1С, CRM, ERP, WMS, системами электронного документооборота, корпоративными справочниками или внешними сервисами.
Поэтому интеграция информационных систем должна рассматриваться как отдельная часть проекта. Простого заявления о наличии опыта подключения к 1С недостаточно.
До начала разработки определяется, какие данные передаются, какая система считается их основным источником, с какой периодичностью выполняется обмен и кто отвечает за корректность информации. Отдельно проектируется поведение при ошибках.
Предположим, новая система отправляет заказ в учетную платформу. Учетная платформа создала заказ, но ответ не дошел из-за сетевого сбоя. Новая система повторяет запрос и создает второй такой же заказ. Чтобы этого не произошло, интеграция должна распознавать повторную операцию и возвращать результат первой обработки.
Такие ситуации типичны для разработки API. Кроме структуры запросов, необходимо согласовать авторизацию, коды ошибок, ограничения, версионирование, правила повторной отправки и обратную совместимость.
Если планируется интеграция с 1С, важно заранее получить сведения о конфигурации, доступных механизмах обмена и возможности создать тестовую среду. Две системы на базе 1С могут существенно отличаться из-за отраслевых модулей и доработок, выполненных предыдущими подрядчиками.
Заказчик должен сохранять контроль над системой независимо от продолжительности сотрудничества с конкретным исполнителем.
При заказной разработке ПО недостаточно получить архив с исходным кодом после завершения договора. Для дальнейшего развития нужны история изменений, инструкции по развертыванию, описание архитектуры, схема базы данных, спецификации интеграций и конфигурации окружений.
Доступ к репозиторию желательно предоставить заказчику еще во время проекта. Тогда код, версии и изменения не остаются исключительно внутри инфраструктуры подрядчика.
То же относится к облачным ресурсам, доменам, сертификатам и учетным записям. Критичная система не должна быть зарегистрирована на личный аккаунт разработчика. Владельцем основных ресурсов становится заказчик либо специально созданная корпоративная учетная запись.
В договоре на разработку программного обеспечения на заказ необходимо определить права на исходный код, документацию, дизайн, структуру базы данных и другие создаваемые материалы. Отдельно учитываются сторонние библиотеки и программные компоненты, которые распространяются по собственным лицензиям.
Разработка и внедрение программного обеспечения не заканчиваются подписанием акта по последнему этапу. После запуска меняются данные, интеграции, инфраструктура и требования пользователей. Поэтому условия сопровождения программного обеспечения лучше определить еще до завершения основной разработки. Заказчику нужно понимать, кто отслеживает состояние системы, принимает обращения и отвечает за выпуск исправлений.
При этом гарантия, поддержка и развитие — разные виды работ. Гарантия распространяется на ошибки, при которых система не соответствует согласованным требованиям. Техническая поддержка включает реакцию на инциденты, мониторинг, обновления и помощь пользователям. Развитие связано с новыми функциями и изменением существующей логики.
В условиях поддержки программного обеспечения обычно фиксируются уровни критичности, время реакции, режим работы команды и порядок эскалации. Полная недоступность системы и ошибка в неосновном отчете не должны иметь одинаковый приоритет.
Стоит разделять время реакции и срок восстановления. Подрядчик может принять обращение за 15 минут, но устранение сбоя потребует анализа данных, отката версии или участия ИТ-службы заказчика. Также важно проверить, как организовано резервное копирование. Сам факт создания копий еще не означает, что данные можно восстановить. Команда должна периодически проверять процедуру восстановления и знать, сколько времени она занимает.
Выбор ИТ-подрядчика — это оценка того, как будет организован весь жизненный цикл разработки программного обеспечения. От первого обследования и архитектурного проектирования до внедрения, передачи документации и промышленной поддержки.
Портфолио помогает проверить общий опыт, но не заменяет анализ подхода. До заключения договора заказчику полезно увидеть примеры требований, архитектурную схему, декомпозицию стоимости, состав команды и порядок выпуска новых версий.
Качественная разработка программного обеспечения не обязательно требует сложной архитектуры, большого количества документов и десятков специалистов. Масштаб решения должен соответствовать задаче. При этом ключевые требования должны быть зафиксированы, технические решения — обоснованы, а результаты — доступны заказчику.
BPA оказывает услуги по разработке программного обеспечения полного цикла. Команда проводит предпроектную аналитику, проектирует архитектуру, разрабатывает интерфейсы и серверную часть, настраивает интеграции, тестирует и внедряет системы в инфраструктуре заказчика. Работа может начинаться с обследования и подготовки требований, чтобы до основной разработки определить границы проекта, риски, сроки и предполагаемый бюджет.
