+7 (812) 424-39-42
17.04.2017

Как понять, что пора менять подрядчика

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

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

Работа как-бы идет, счета вам выставляют, но даже примерную дату запуска сказать страшно.

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

Определим основные признаки, которые предрекают время кардинальных изменений.

Глобальная задержка

Вы все хорошенько продумали, согласовали ТЗ на 400 листов и пару лет назад отдали в работу.

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

Для разработки интернет-магазина «водопад» означает ночной кошмар: изменение цвета кнопочки превращается в череду бесконечных согласований. Запуск все откладывается и откладывается.

Проект, в котором все плохо

На длинной дистанции меняются условия взаимодействия, требования к элементам системы или логика работы. Это имеет отношение к любому более-менее крупному проекту, над которым работают дольше 6 месяцев.
Команда спешит выполнить все условия, описанные в ТЗ два года назад а в ответ получает все новые доработки.
Проект, так и не готовый к публикации, дорабатывается и дорабатывается. Это длится годами.

Общая усталость от проекта

Студия на другом конце провода уже работает в убыток, вы перекидываете друг другу письма по электронке, всем все надоело.

Ре: Ре: Правки!

Большей части разработчиков комфортно «бегать» на короткие дистанции (возможно, из-за сидячего образа жизни :-).
Участвовать в проекте, который даже на горизонте не будет опубликован — сложно.
Сложно мотивировать команду, сложно внедрять новый функционал. И заказчик и исполнитель ждут перерыв или паузу. Усталость коллектива замедляет все процессы.

В таких случаях самые рисковые меняют проект-менеджера или подключают к проекту дополнительных сотрудников. По нашим наблюдениям, это только мешает.

Пример из нашей практики

Клиент работал над интернет-магазином с топовой российской студией. Клиент понял, что Студия не справляются с проектом.
Чтобы не провоцировать конфликт и безболезненно разрешить ситуацию, Клиент решил мягко перейти от Студии к DPROMO.

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

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

После переходного периода Клиент сказал Студии: «Мы заканчиваем работу». Проект полностью перешел под контроль DPROMO.

Какие выводы мы сделали из ситуации:

  1.  Переходный период — самое тяжелое время. Работа над проектом останавливается, сроки затягиваются и команды деморализуются. Важно не затягивать.
  2. Важно «свести» нового и старого разработчика до разрыва отношений, чтобы вовремя получить ответы на все вопросы. Когда нет возможности связываться напрямую — общаемся по переписке через клиента.
  3. Самый тонкий момент — разорвать отношения с предыдущим разработчиком. К этому моменту клиент должен получить все документы, наработки и сайты. Идеально, если все файлы, коды доступа и документация уже у вас.
  4. Чтобы не совершать ошибки, собираем аналитику и выясняем, почему не получилось с предыдущим подрядчиком.

Андрей Шишкин,
технический директор:

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

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

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

Возможно вам будет интересно

Рассказываем, как обсуждать собственные идеи, не теряя связь с реальностью.

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

Поле заполнено неверно
Поле заполнено неверно
Ответ в течение 1-го дня
Поле заполнено неверно
Ответ в течение 1-го дня

Разработка сайтов

Мобильные приложения

Интеграция 1С+веб

Все кейсы

Приложение для обучения ортодонтов

Приложение для Сбербанк

Transit Media Group

Концерн «Питер»

ECA Service

Ниеншанц-Автоматика

Интернет-магазин Hamilton

Приложение «Фурнитура.ру»

ClubTurbo — tuning shop

Сайт компании SeaData

Приложение для конференции

Поле заполнено неверно
Поле заполнено неверно
Ответ в течение 1-го дня
Поле заполнено неверно
Ответ в течение 1-го дня
Поле заполнено неверно