Заказчик и аутсорс — итоговый результат работы

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

Разработка никогда не заканчивается

В ходе разработки трудно сказать, что всё готово, и можно переходить к следующему этапу. Известная буддийская притча гласит: «Чтобы что-то закончилось, нужно только одно: чтобы оно началось. Кроме разработки». Потому что «Обновляйся или умри». Если разработка началась, то она не закончится никогда.

Первый критерий готовности проекта: если он проходит визит-эффект, его можно сдавать и внедрять.

Нужно ли дёргать разработчиков во время разработки? Да, нужно. Но важно чувствовать грань между держанием руки на пульсе, чтобы ваш проект не попал в нижний приоритет, и бесконечными сообщениями в чатиках «А как дела? А сейчас? А вот сейчас?».

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

Чтобы этого избежать — обсуждайте правила коммуникации до старта проекта.

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

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

Важно: хорошая команда называет сроки проектов с учётом рисков.

Интеграция

Отдельное внимание стоит уделить процессу интеграции. Всегда (всегда!) интеграция затягивается, потому что коммуникация между командами не выстроена. Чтобы наладить коммуникацию, нужно уже на этапе ТЗ договориться с заказчиком об общении с командой сервисов интеграции.

Будьте в копии переписки и, если не понимаете, о чём идёт речь, просто следите за общением обеих сторон. Оно должно быть осмысленным и содержать все технические подробности.

Неправильно, если разработчик напишет в банк так:

Банк, у вас транзакции не проходят!

А вот если напишет:

Банк, сегодня в 14:06 по Мск транзакция типа «Списание с карты (номер 1234567890qwerty)» подвисла и до сих пор висит со статусом pending. Ранее мы договаривались об обработке транзакций за минуту. Скажите, как это исправить? PS: обращаемся к среде bank-test–1 по выданным ранее доступам.

Если в ответ на такое письмо банк молчит, то вынимайте банку душу — доставайте, пока кто-нибудь не примет меры.

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

Договоритесь c разработчиками об определённых условиях участия на этапе интеграции, чтобы всем было удобно.

Внедрение

К концу проекта точно возникнет проблема улучшений, несмотря на то, что всё сделано по ТЗ. Разумеется, принимать работу, когда есть откровенные баги, легко воспроизводимые и явно противоречащие ТЗ — нельзя. Если же сервис работает, пользователь может купить, найти, послушать, посмотреть — в общем всё, что вы задумали, — смело запускайте проект. Если очень страшно, то зажмурьтесь. Посмотрите, в каком виде запускаются сервисы на американском рынке, как они выглядят, как работают. Зайдите на Producthunt или Crunchbase и поищите проекты с низким рейтингом — которые недавно добавились и не имеют заметных достижений. Проходит время — выкатывается редизайн и проект взлетает и т.д.

Как только проект запустится — пользователи сами скажут, что надо исправлять, а что нет. Список задач сформируется сам собой.

Постпроектная поддержка

Сервис запущен, всё работает. Понимание заказчиком процесса разработки значительно возросло. Теперь возникает вопрос: как пользоваться продуктом и не сидеть на абонементе аутсорсеров?

Очень просто — разработчики должны передать заказчику минимум два документа:

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

Дополнительно должно появиться:

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

Чтобы убедиться, что ваш проект готов, напишите нам. Сделаем аудит и проконтролируем команду разработки. Удачи с проектом! :)