Как не провалить разработку ПО, доверив ее внешним исполнителям

Ошибки в организации работы с внешними разработчиками, которых вы могли бы избежать

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

Ситуации, которые могут стать причиной срыва проекта:

1.“Черный ящик”

Признаки назревания проблемы:
  • Исполнитель для разработки вашего программного обеспечения выбран, контракт подписан, срок проекта назначен на через N месяцев. Отличное начало.
  • По-прошествии нескольких недель на ваш запрос получен ответ: “Все идет по графику, проект изучен, работа идет — ожидайте готовую программу в согласованные сроки.”

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

ошибки в работе с разработчиками

Как должно быть:

  • Вам должны представить ответственного за разработку. Это может быть менеджер, руководитель проекта, даже программист — не важно, какова его должность, главное, что это человек, осуществляющий регулярную связь между командой разработчиков и заказчиком проекта (даже при внутрикорпоративной разработке).
  • По согласованному графику (например, еженедельно) проходят встречи, где вам докладывают о ходе работ, согласуя вопросы, которые недостаточно четко были прописаны в техзадании или возникли по ходу пьесы.
  • На старте проекта зафиксированы реперные точки, соответствующие этапам разработки. Завершение каждого этапа — это встреча или скайп-колл с презентацией результатов, обсуждением достигнутого и получением командой обратной связи от вас, заказчика проекта.
  • На финишной прямой вы должны получить практически готовый программный продукт для внутреннего тестирования. Только после вашего тест-драйва, при условии отсутствия замечаний, компания-разработчик готова к финальной передаче ПО.

2.Коммуникации

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

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

Как должно быть:

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

3.Контроль качества (QA)

взаимодействие клиента с ит командой

Признаки назревания проблемы:

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

Прогноз: При отсутствии у компании-разработчика в перечне работ этапа контроля качества и ревью кода, финальные сроки проекта могут быть существенно сдвинуты в связи с регулярным выявлением ошибок даже в практически готовом ПО.

фейлы в разработке по

Как должно быть:

QA — это не финальные тесты, которые проводятся на полностью готовом к запуску программном обеспечении, а процесс контроля разработки, который, как цементный раствор при строительстве, закрепляет результаты всех стадий разработки. Часть процесса — покрытие авто-тестами и ручная проверка, моделирующая поведение пользователя; отдельный этап — анализ кода на предмет соответствия стандартам.

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