Как выбрать команду для разработки программного обеспечения
После неудачного программного проекта недостаточно просто найти другую компанию. Нужно понять, почему первая команда не достигла цели, и выбрать партнёра, который сможет показать, как он избежит тех же ошибок. Проверьте его опыт в работе с похожими процессами, запросите конкретный план, уточните, кто несёт ответственность, и договоритесь, как вы будете принимать каждую часть системы.
Что нужно выяснить после проваленного проекта?
Начните с краткого внутреннего разбора. Соберите договор, предложение, техническую документацию, доступы, код, дизайн и список обещанных функций. Отметьте, что действительно работает, чего не хватает и что уже не соответствует вашим процессам.
Не думайте, что проблема только в программировании. Проваленный проект часто начинается с неясного задания, меняющихся требований, отсутствия ответственного со стороны клиента или обещания уложиться в жёсткий срок при недостатке информации. Иногда код хорош, но нет интеграции с бухгалтерией, склад не отражает реальную работу или сотрудники не могут пользоваться системой.
Подготовьте список конкретных вопросов: Что изменилось во время первого проекта? Кто утверждал решения? Как принимались функции? Когда вы поняли, что срок не будет соблюдён? Был ли у вас доступ к коду и данным? Были ли тестовая среда и резервные копии?
Какие вопросы задать потенциальной команде?
Первая встреча не должна быть презентацией одного лишь портфолио. Она должна показать, как команда мыслит. Дайте ей описание процесса, который хотите улучшить, а не только список кнопок и экранов.
- Какие части процесса вы бы изучили до того, как предложить технологию?
- Как вы разделите проект на этапы, которые можно тестировать и принимать?
- Какие риски вы видите уже сейчас и как будете их проверять?
- Кто будет моим постоянным контактным лицом и кто принимает технические решения?
- Что вы будете делать, если в процессе разработки окажется, что определённая функция сложнее, чем ожидалось?
- Что я получу при передаче: код, базу данных, документацию, доступы и инструкции?
- Как обрабатываются ошибки после запуска системы?
Хороший ответ не обязательно самый технический. Если команда говорит только о языке программирования и дизайне, не спрашивая о ролях, согласованиях, счетах, складе, API и реальных пользователях, вероятно, она ещё не понимает задачу.
Как проверить опыт и портфолио?
Изучите портфолио, но не ограничивайтесь красивыми главными страницами. Ищите проекты с похожей логикой: управление заявками, роли и права доступа, документооборот, мобильные команды, платежи, склад, автоматическое выставление счетов или связь между несколькими системами.
Например, LiftexPro — ERP для лифтовых компаний сочетает планирование проверок, управление зданиями, мобильное приложение для техников и автоматическое выставление счетов. Для команды, которая должна создать бизнес-систему, это показательнее, чем общее обещание «уникальной платформы».
Для выездных процессов изучите также Ековат — ERP на заказ, где связаны заявки, рабочие карты, автопарк, склад и документы. Вопрос не в том, относится ли проект к вашей отрасли. Вопрос в том, решала ли команда задачи сопоставимой сложности.
Попросите показать демонстрацию работающей системы, а не только изображения. В демоверсии ERP для международных перевозок можно увидеть рейсы, водителей, автопарк, клиентов, счета, расходы и разные представления для ролей в компании. Так вы поймёте, показывает ли поставщик реальную логику или только визуальную концепцию.
Спросите, какая часть показанного является готовым продуктом, а какая разработана специально для конкретного клиента. Попросите объяснить вашу роль, используемые интеграции и ограничения. Не принимайте чужие результаты за доказательство, если команда не может объяснить свою работу над проектом.
Как оценить технический подход?
Технический подход должен начинаться с процессов и данных. Например, для CRM описываются клиенты, сделки, предложения, задачи, история коммуникации и права сотрудников. Для ERP уточняются склад, продажи, счета, отчёты, роли и связи с другими системами.
Попросите схему основных модулей и потока данных. Если интернет-магазин принимает заказ, как он попадает на склад? Когда создаётся накладная? Как отражается платёж? Что видит бухгалтер? Если ясного ответа нет, проблема позже проявится в виде ручной работы и ошибок.
Проверьте, как планируются интеграции. Связь по API с курьером, платёжным оператором, телефонией или бухгалтерской программой — не просто отметка в предложении. Нужно уточнить данные, частоту синхронизации, ошибки, повторную отправку и того, кто будет следить за связью.
Спросите о тестовой среде, резервных копиях, логах, правах доступа и способе публикации изменений. Для системы с персональными данными обсудите, у кого есть доступ, как записываются действия и как восстанавливается работа при проблеме.
Как понять, будет ли коммуникация работать?
Коммуникация измеряется не тем, насколько быстро команда отвечает до подписания договора. Проверьте, как вы будете работать после запуска. Будет ли еженедельная встреча? Где будут фиксироваться задачи? Как вы будете утверждать дизайн, процесс и готовую функцию? Как вы будете видеть, что запланировано, а что заблокировано?
Назначьте со своей стороны человека, который знает бизнес и может принимать решения. Если каждый сотрудник будет давать программистам разные указания напрямую, проект начнёт расползаться. У новой команды должен быть один понятный канал для требований и изменений.
Попросите пример отчёта о работе. Хороший отчёт показывает, что завершено, что предстоит сделать, какие вопросы ждут решения и что влияет на сроки. Это полезнее общего сообщения о том, что «проект движется».
Как сравнить сроки и бюджет?
Не сравнивайте только итоговые суммы. Сравните, что за ними стоит. Одно предложение может включать анализ, дизайн, разработку, миграцию данных, тестирование, обучение, публикацию и поддержку. Другое может включать только программирование.
| Что сравнить | Вопрос к команде | Риск при отсутствии ответа |
|---|---|---|
| Объём работ | Какие функции включены, а какие не входят в предложение? | Новые расходы и споры во время проекта |
| Этапы | Что мы получим и примем на каждом этапе? | Вы ждёте до конца, чтобы увидеть проблемы |
| Данные | Кто перенесёт старых клиентов, товары и документы? | Потеря информации или ручной ввод |
| Интеграции | Какие API-связи включены и как они тестируются? | Система ненадёжно обменивается данными |
| Поддержка | Как подаются сообщения об ошибках и что не входит в ежемесячное обслуживание? | Нет чёткого ответа при срочной проблеме |
| Право собственности | Где хранятся код, данные и доступы? | Зависимость от поставщика |
Для разработки программного обеспечения на заказ ориентир по предложению составляет 3 000–29 300 €. Что вам предложат в этих рамках, зависит от количества модулей, сложности ролей, миграции данных, мобильного приложения, интеграций, тестирования и необходимости постоянной поддержки. Не сравнивайте нижнюю границу одного предложения с полным объёмом другого.
Срок также должен быть связан с результатом. Вместо «готово за короткое время» попросите график с этапами, зависимостями и условиями утверждения. Если вы задерживаете доступ, контент или принятие решения, срок должен меняться прозрачно.
Как должен выглядеть рабочий процесс?
- 01Аудит старого проекта
Вы проверяете имеющийся код, базу данных, доступы, документацию и нереализованные функции. Новая команда описывает, какие части можно использовать, а какие безопаснее переработать.
- 02Описание реального процесса
Вы рассказываете, как работают отделы продаж, склад, бухгалтерия, выездные сотрудники и руководитель. Команда переводит этот процесс в роли, состояния, данные, уведомления и интеграции.
- 03Пилотный объём
Вы выбираете важную, но ограниченную часть системы. Она должна пройти через реальный сценарий и показать, удобны ли решения для людей, которые будут ими пользоваться.
- 04Приёмка по этапам
Для каждой функции вы определяете, что означает «готово». Вы тестируете её на конкретных данных, записываете замечания и отделяете дефекты от новых идей.
- 05Запуск и обучение
Вы планируете миграцию, права доступа, резервное копирование, обучение и период наблюдения. Не останавливайте старую работу, пока не поймёте, что будете делать в случае проблемы.
- 06Поддержка и развитие
Вы уточняете канал для заявок, приоритеты, реакцию на ошибки, обновления и стоимость дополнительных изменений. Так следующий этап не начинается с нового поиска поставщика.
Как не повторить старые ошибки?
Подключайте пользователей ещё до начала разработки. Сотрудник склада, диспетчер и бухгалтер видят другие проблемы, чем руководитель. Короткая демонстрация на их реальном сценарии может выявить недочёт, который не показывает длинный список требований.
Не меняйте постоянно цель без оценки последствий. Новая функция может затронуть базу данных, роли, API связи и сроки. Для каждого расширения объёма должны быть описание, цена и оценка влияния на график.
Не оставляйте всё на уровне устных разговоров. Фиксируйте решения, согласования и зоны ответственности. В договоре уточните права на код, доступ к хостингу и базе данных, конфиденциальность, порядок приёмки и условия расторжения.
В конце проверьте, как будет организована поддержка после запуска. Для существующего сайта или системы она может включать обновления, резервное копирование, проверки и небольшие изменения. Для более сложной ERP или CRM системы потребуются мониторинг интеграций, управление пользователями и развитие функциональности.
Как сделать правильный выбор после неудачного проекта?
Правильная команда не та, которая обещает сделать быстрее и дешевле всех. Она задаёт вопросы о вашей работе, показывает похожие системы, объясняет ограничения и разделяет большой риск на небольшие проверяемые решения.
До подписания договора вы должны знать, кто работает над проектом, что получите на каждом этапе, как принимаются функции, что произойдёт с кодом и данными и к кому обращаться при проблемах. Если ответы на эти вопросы ясны уже в начале, вероятность повторить прежний сценарий значительно ниже.
Часто задаваемые вопросы
- Как понять, есть ли у софтверной компании реальный опыт?
- Попросите показать похожие проекты, продемонстрировать работающую систему и объяснить, как команда решила конкретную бизнес задачу. Портфолио только со скриншотами дизайнов не подтверждает опыт работы с интеграциями, ролями, данными и поддержкой.
- Что делать с кодом провалившегося проекта?
- Проведите технический аудит, прежде чем решать, использовать ли код. Проверить нужно архитектуру, безопасность, базу данных, документацию, доступы и возможность другой команды поддерживать систему.
- Как определяется цена разработки ПО на заказ?
- Цена зависит от объёма работ, количества модулей, ролей, интеграций, миграции данных, мобильных приложений, тестирования и поддержки. Сравнивайте не только итоговую стоимость, но и то, что входит в каждый этап.
- Как контролировать сроки разработки?
- Согласуйте этапы с конкретным результатом и критериями приёмки. Следите за зависимостями, задержками в принятии решений и изменениями объёма, поскольку они напрямую влияют на график.
- Кто должен участвовать со стороны клиента?
- Назначьте одного человека, который знает процессы и может принимать решения. В ключевые демонстрации включайте и сотрудников, которые будут ежедневно работать с системой.
