К чему готовиться и на что обращать внимание при работе по развитию сайта новыми разработчиками

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

Да, разбираться в незнакомом, устаревшем, legacy коде, в нестандартных функциональных и давно работающих сайтах — так себе перспектива.

Мы перебороли себя (и наших технарей), и стали брать.

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

Выводы, к которым мы пришли, к чему готовиться и на что обращать внимание

• Едва ли пятая часть разработчиков готова взять проект другого исполнителя на сопровождение.
• У разработчика должен быть релевантный опыт в проектах аналогичного уровня сложности и применения требуемых технологий.
• Используйте модель Time and materials (оплата затраченного времени исполнителя) и производные схемы. Проверено — другие подходы не работают столь же стабильно. Оценки по трудозатратам разработчик, конечно, должен предоставлять, но для ориентира.
• Стартовать нужно с аудита. Предварительную оценку объёмом в несколько часов исполнитель может сделать бесплатно. А заказчик должен быть готов оплатить последующие несколько десятков часов глубокого изучения проекта и погружения разработчиков.
• Первые боевые задачи — сопровожденческие, с постепенным усложнением и переходом в развитие и модернизацию.
• Выстраивать долговременное сотрудничество. Если не планируете играть вдолгую, то лучше не начинайте. Только усложните проект, а ключевые проблемы не успеете решить.
• Готовность заказчика платить на длинной дистанции.
• Комфортность и открытость в общении. Работать нужно будет долго и плотно, и проблемы будут (много и серьёзные).
• Обратите внимание на качество управления и коммуникационные процессы. Команда разработчиков должна иметь высокий уровень проектного менеджмента и культуры коммуникаций. Их будет много, к этому нужно быть готовыми. И хорошо, если у разработчика уже отлажены эти процессы (митинги, созвоны, ретроспективы, отчёты).
• Договорённости должны выполняться с обеих сторон, никаких придуманных по ходу работ наказаний и штрафов, уважительное профессиональное общение. Попробуйте забыть негативный опыт взаимодействия с фрилансерами.
• Если у заказчика большой опыт взаимодействия с разработчиками, то это не значит, что с ним будет проще работать. Опыт может быть разным.
• Заказчик должен быть готов участвовать в работе. Не только при постановке и приёмке задач, но и в процессе её выполнения.
• Улучшайте возможности для отчуждения. Обе стороны должны иметь способы разорвать отношения. И не нужно, чтобы проект пострадал.
• Не делайте новый функционал «по-старому». Здорово когда каждый релиз улучшает кодовую базу.
• Часть бюджета (10–20 %) выделяйте на рефакторинг старого кода.
• Стабильность работы разработчика. Изменения должны внедряться без постоянного надрыва и форс-мажоров.
• Оговаривайте ограничение по бюджету в месяц.
• Учитывайте эффективность решений с учётом бюджета.
• Семь раз подумайте, прежде чем предлагать или входить в долю. Принципы продуктовой и заказной разработки отличаются, и в одной компании редко работают хорошо.
• Следите за своевременностью оплаты, договаривайтесь в рамках разумного и с учётом рисков.
• Согласуйте в каких ситуациях разработчик приостановит работы.
• Будьте готовы к тому, что когда исполнитель погрузится в проект (почувствует незаменимость), а проблем станет меньше (непонятно за что платим такие большие деньги), то взаимоотношения могут измениться.
• Если всё сделаете правильно, то сайт получит дополнительное развитие, а разработчик опыт и стабильную загрузку над работающим проектом.