Приложение работает, а разработка стоит: когда пора менять подрядчика

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

Редакция «Точки Интерфейса» предлагает начать не с поиска замены, а с проверки: где именно застревает работа. Иначе вместе с репозиторием новой команде достанутся старые проблемы управления.

Представим условную ситуацию. Компания просит добавить в приложение повтор заказа. На первый взгляд нужно поставить кнопку рядом с предыдущей покупкой. Разработчики говорят, что потребуется изменить серверную часть. Руководитель слышит знакомое объяснение: «У нас все сложно».

Но у этой задачи есть вопросы, которых не видно на макете. Что делать с товаром, которого больше нет? С какой ценой собирать корзину? Можно ли повторить заказ в другой точке выдачи? Если ответы появились после оценки, изменился и объем работы.

Проблема здесь не обязательно в скорости программистов. Возможно, задача попала в разработку раньше, чем бизнес решил, как она должна работать. Замена исполнителя этого не исправит.

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

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

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

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

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

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

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

В каждом случае полезно сформулировать причину перехода одним предложением. «Нам нужен предсказуемый выпуск обновлений раз в согласованный период» помогает выбирать новую команду. «Нам нужны разработчики получше» не задает никаких критериев.

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

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

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

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

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

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

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

Не стоит одновременно менять подрядчика, дизайн, технологии и платежную логику. Если что-то пойдет не так, будет трудно понять причину.

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

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

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

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

Главный результат смены подрядчика — не другой логотип в ежемесячном отчете. Это возможность снова планировать развитие продукта и понимать, за что отвечает каждая сторона.