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

March 30 2023

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

Разработка никогда не заканчивается
Интеграция
Внедрение
Постпроектная поддержка

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

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

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

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

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

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

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

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

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

Интеграция

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

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

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

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

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

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

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

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

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

Внедрение

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

Посмотрите, в каком виде запускаются сервисы на американском рынке, как они выглядят, как работают. Зайдите на Product Hunt или Crunchbase и поищите проекты с низким рейтингом — которые недавно добавились и не имеют заметных достижений. Проходит время — выкатывается редизайн и проект взлетает и т.д.

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

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

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

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

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

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

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

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

Автор статьи
Кирилл Гришанин
Последние 10 лет руковожу командой аналитиков, дизайнеров и разработчиков

Подпишитесь на блог WB—Tech

Никакого спама, только анонсы новых статей

    ИП Гришанин Кирилл Олегович
    ИНН 774313842609

    Подписаться на новости блога

      Подписаться на обновления блога

      Коворкинг Starthub

      Б. Новодмитровская ул., 36, стр. 12, вход 6,
      Москва, Россия, 127015

      Коворкинг Wework

      Ahad Ha'am 54,Tel Aviv-Yafo,Израиль

      © 2023 WB—Tech. Мы разрабатываем уникальные решения для компаний из России, США и Европы.