Представьте: вы затеяли глобальный IT-проект, сделали ставку на студию с отличной репутацией, и ведете разработку уже многие месяцы.
Работа как-бы идет, счета вам выставляют, но даже примерную дату запуска сказать страшно.
И если в первые месяцы сотрудничества подрядчик рвался в бой, то сейчас выделяет на ваш проект все меньше и меньше времени.
За студией не было крупных косяков, но и вы не раздаете деньги просто так и хотите уверенности в том, что проект увидит свет.
Определим основные признаки, которые предрекают время кардинальных изменений.
Глобальная задержка
Вы все хорошенько продумали, согласовали ТЗ на 400 листов и пару лет назад отдали в работу.
Такую модель разработки называют «водопадом» — она отлично подходит для финтеха и разработок в медицине, когда каждая кнопочка просчитывается командой аналитиков и проект предсказуем.
Для разработки интернет-магазина «водопад» означает ночной кошмар: изменение цвета кнопочки превращается в череду бесконечных согласований. Запуск все откладывается и откладывается.
На длинной дистанции меняются условия взаимодействия, требования к элементам системы или логика работы. Это имеет отношение к любому более-менее крупному проекту, над которым работают дольше 6 месяцев.
Команда спешит выполнить все условия, описанные в ТЗ два года назад а в ответ получает все новые доработки.
Проект, так и не готовый к публикации, дорабатывается и дорабатывается. Это длится годами.
Общая усталость от проекта
Студия на другом конце провода уже работает в убыток, вы перекидываете друг другу письма по электронке, всем все надоело.
Большей части разработчиков комфортно «бегать» на короткие дистанции (возможно, из-за сидячего образа жизни :-).
Участвовать в проекте, который даже на горизонте не будет опубликован — сложно.
Сложно мотивировать команду, сложно внедрять новый функционал. И заказчик и исполнитель ждут перерыв или паузу. Усталость коллектива замедляет все процессы.
В таких случаях самые рисковые меняют проект-менеджера или подключают к проекту дополнительных сотрудников. По нашим наблюдениям, это только мешает.
Пример из нашей практики
Клиент работал над интернет-магазином с топовой российской студией. Клиент понял, что Студия не справляются с проектом.
Чтобы не провоцировать конфликт и безболезненно разрешить ситуацию, Клиент решил мягко перейти от Студии к DPROMO.
Переходный период — самое напряженное время. Перед Клиентом стояла задача получить у Студии все наработки и документацию по проекту. В переходный период оба разработчика не могли ничего сделать.
Во время переходного периода мы связывались со Студией и получали все ответы на наши вопросы. Радует высокая культура общения между коллегами по цеху.
После переходного периода Клиент сказал Студии: «Мы заканчиваем работу». Проект полностью перешел под контроль DPROMO.
Какие выводы мы сделали из ситуации:
- Переходный период — самое тяжелое время. Работа над проектом останавливается, сроки затягиваются и команды деморализуются. Важно не затягивать.
- Важно «свести» нового и старого разработчика до разрыва отношений, чтобы вовремя получить ответы на все вопросы. Когда нет возможности связываться напрямую — общаемся по переписке через клиента.
- Самый тонкий момент — разорвать отношения с предыдущим разработчиком. К этому моменту клиент должен получить все документы, наработки и сайты. Идеально, если все файлы, коды доступа и документация уже у вас.
- Чтобы не совершать ошибки, собираем аналитику и выясняем, почему не получилось с предыдущим подрядчиком.
Андрей Шишкин,
технический директор:Самое неприятное — предыдущий подрядчик больше не поддерживает проект, который ведет новая студия.
Это значит, что периодически мы будем натыкаться на проблемы в коде, за которые не несем ответственности. В этой ситуации виноватых нет: некоторый функционал приходится изменять или разрабатывать с нуля.
Менять студию-разработчика — огромный риск для бизнеса. Чтобы избежать рисковых перемен, опытные заказчики с умом подходят к началу разработки, не экономят на важном и делают хорошо с самого начала.
Мы не призываем читателя бросить студию, с которой он работает. Напротив, надеемся, что наш опыт поможет сразу принимать правильные решения в будущем.
Подбор методологий разработки — тема, достойная отдельной статьи. Как правильно начать, расскажем в одном из следующих выпусков.