Заказчик и аутсорс — как перестать контролировать мониторы и начать эффективно работать

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

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

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


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

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

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

    Интеграция

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

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

    Неправильно, если разработчик напишет в банк так: «Банк, у вас транзакции не проходят!».

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

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

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

    Внедрение

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


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

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


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

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

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


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

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


    Удачи с проектом! :)

    Кирилл Гришанин

    Кирилл Гришанин

    Последние 10 лет руковожу командой аналитиков, дизайнеров и разработчиков.

    🇮🇱 Israel http://wbtech.ru/