Мы уже рассказали о том, как общаться с разработчиками на старте проекта и о проблемах дизайна и технического задания при работе с командой на аутсорсе. Осталось понять, как оценивать результаты работы разработки вашего проекта.
Разработка никогда не заканчивается
В ходе разработки трудно сказать, что все готово, и можно переходить к следующему этапу. Известная буддийская притча гласит: «Чтобы что-то закончилось, нужно только одно: чтобы оно началось. Кроме разработки». Потому что «Обновляйся или умри». Если разработка началась, то она не закончится никогда.
Первый критерий готовности проекта: если он проходит визит-эффект, его можно сдавать и внедрять.
Нужно ли дергать разработчиков во время разработки? Да, нужно. Но важно чувствовать грань между держанием руки на пульсе, чтобы ваш проект не попал в нижний приоритет, и бесконечными сообщениями в чатиках «А как дела? А сейчас? А вот сейчас?».
В ходе просмотров и апдейта не мучайте ребят вопросами, сообщениями об ошибках. 99% того, что пишут на таких этапах — информационный мусор, который не помогает, а сжигает время и внимание разработчиков и тестировщиков. Важные задачи и/или смену приоритетов обсуждайте на спринтах.
Чтобы этого избежать — обсуждайте правила коммуникации до старта проекта.
Для нас комфортен темп общения 2 раза в месяц, на некоторых проектах — отчетность раз в неделю.
Заказчики, не должно быть такого, что вам не хотят показывать результат хотя бы раз в месяц. Если такое происходит — бейте тревогу. Отсутствие гибкости в коммуникации — серьезный минус, признак того, что проект развивается не туда. Каждое общение позволит вам быть в курсе проекта, знать, что происходит у разработчиков: кто-то уволился, заболел, умер, что угодно.
Важно: хорошая команда называет сроки проектов с учетом рисков.
Интеграция
Отдельное внимание стоит уделить процессу интеграции. Всегда (всегда!) интеграция затягивается, потому что коммуникация между командами не выстроена. Чтобы наладить коммуникацию, нужно уже на этапе ТЗ договориться с заказчиком об общении с командой сервисов интеграции.
Будьте в копии переписки и, если не понимаете, о чем идет речь, просто следите за общением обеих сторон. Оно должно быть осмысленным и содержать все технические подробности.
Неправильно, если разработчик напишет в банк так:
Банк, у вас транзакции не проходят!
А вот если напишет:
Банк, сегодня в 14:06 по Мск транзакция типа «Списание с карты (номер 1234567890qwerty)» подвисла и до сих пор висит со статусом pending. Ранее мы договаривались об обработке транзакций за минуту. Скажите, как это исправить? PS: обращаемся к среде bank-test–1 по выданным ранее доступам.
Если в ответ на такое письмо банк молчит, то вынимайте банку душу — доставайте, пока кто-нибудь не примет меры.
Однако заказчикам стоит понимать, что заставлять разработчиков бегать за другими вашими подрядчиками тоже неправильно.
Договоритесь c разработчиками об определенных условиях участия на этапе интеграции, чтобы всем было удобно.
Внедрение
К концу проекта точно возникнет проблема улучшений, несмотря на то, что все сделано по ТЗ. Разумеется, принимать работу, когда есть откровенные баги, легко воспроизводимые и явно противоречащие ТЗ — нельзя. Если же сервис работает, пользователь может купить, найти, послушать, посмотреть — в общем все, что вы задумали, — смело запускайте проект. Если очень страшно, то зажмурьтесь 🙂
Посмотрите, в каком виде запускаются сервисы на американском рынке, как они выглядят, как работают. Зайдите на Product Hunt или Crunchbase и поищите проекты с низким рейтингом — которые недавно добавились и не имеют заметных достижений. Проходит время — выкатывается редизайн и проект взлетает и т.д.
Как только проект запустится — пользователи сами скажут, что надо исправлять, а что нет. Список задач сформируется сам собой.
Постпроектная поддержка
Сервис запущен, все работает. Понимание заказчиком процесса разработки значительно возросло. Теперь возникает вопрос: как пользоваться продуктом и не сидеть на абонементе аутсорсеров?
Очень просто — разработчики должны передать заказчику минимум два документа:
- Инструкция по разворачиванию сервиса — документ, который позволяет любому грамотному разработчику установить созданное ПО и начать его эксплуатацию. Этот документ + ТЗ + сам код дают возможность передать проект другим разработчикам.
- Инструкция по использованию админки (бэк-офиса) сайта. Этот документ должен быть понятным для заказчика, чтобы не было дальнейших вопросов разработчикам.
Дополнительно должно появиться:
- Ощущение, что вы неплохо разобрались в разработке и сами можете сделать еще один такой же проект.
- Легкая ненависть к проекту, который занял собой всю вашу жизнь, семью и работу.
- Разбитые розовые очки и небольшой ужас от того, куда вы попали.
Чтобы убедиться, что ваш проект готов, напишите нам. Сделаем аудит и проконтролируем команду разработки. Удачи с проектом!
