разбор кейса «Независимые эксперты»

Коллеги, давайте напомним описание кейса

Заказчик обратился к нескольким именитым независимым экспертам для проверки качества кода проекта. Эксперты, конечно, выдали свою оценку. Если кратко — код ужасно запутан, что неизбежно приведет к проблемам при дальнейшем росте проекта и при добавлении новых разработчиков. Еще эксперты были в шоке, что за такое время такая команда написала всего N строк кода. Что такой проект реально было написать вдвоем за втрое меньшее время. И что в данный момент у проекта огромный технический долг. Настоятельная рекомендация экспертов — всё переделать. Желательно с нуля.

C чего тут стоит начать? На наш взгляд, стоит начать со взгляда на ситуацию со стороны заказчика.

Заказчик

Что хочет?

  • Сделать проект качественно, в срок, в бюджете. Приоритеты, по словам PMа, именно такие. Качество важнее всего, сроки важны, бюджет — попросту разумен.

Чего боится?

Артем Сердюк совершенно справедливо указал, что мы не знаем, что было в бизнес-прошлом у этого заказчика. Мог быть и сомнительный код, и бесконечные «will be done tomorrow» и выход за бюджет.

Действия со стороны PM

Узнать, что двигало заказчиком, когда он обратился к экспертам. Самый простой способ — это задать вопрос. Гипотезы, которые стоит проверить:

Гипотеза: Заказчик перестраховался

Заказчик спокоен, и он просто следует best practices. Либо просто встретил знакомых экспертов «- а хочешь, мы твой проект заревьювим нахаляву? — а давай».
С одной стороны, хорошо, если заказчик просто перестраховался. С другой — экспертами поставлены негативные оценки и это требует действий. И хорошо ли теперь на проекте после такого code review — уже сложно сказать.
Контрольные вопросы для понимания ситуации:

  • как обычно ведет себя заказчик когда волнуется? Он становиться болтливым? Замкнутым? Задает много вопросов или начинает учить правильно работать?

Если до обращения к экспертам заказчик вел себя так же, как и обычно, то он перестраховался, с большой вероятностью
Если эта гипотеза подтверждается, то у заказчика не было серьезных поводов волноваться ДО code review. Но ПОСЛЕ у него уже поводы были.

Что делать?

Что мы можем сказать заказчику?

  • «твои эксперты ошиблись и, вообще, идиоты». Ведь, если он обратился к экспертам, значит, их мнение для него что-то значит. Здесь в дело вступает защита собственного выбора: «умный я выбрал экспертов, значит и они тоже умны». Сомнения в экспертах — это сомнение и в выбравшем их.
  • «успокойся, всё будет хорошо». Эта фраза обычно ведет к взрыву — очень многим не нравится, когда им говорят, что надо чувствовать в какой-то ситуации.
  • Воспользоваться Сократическим Диалогом с выводом на разные сценарии дальнейшей работы: рефакторим или нет; если рефакторим, то что.

Гипотеза: Заказчика что-то напугало

Может быть, он увидел на проекте что-то этакое. Например, для начинающего заказчика может быть непонятно, что производительность меняется скачкообразно от недели к неделе.  Еще причина может быть вообще снаружи проекта — например, заказчик почувствовал приближение кризиса.
Мы не знаем, и лучший способ узнать — это спросить. Не обязательно, конечно, что он ответит правду «как есть», но у нас здесь есть важный помощник. Если KPI для программиста подсчитать практически невозможно, то KPI для проекта — очень даже можно. Например, количество багов, замеченных пользователями за прошлый спринт, или uptime для сервера, или изменение velocity команды, или много задач висит в состоянии «90% done».

Что делать?

Подготовительные действия:

  • Спрашиваем заказчика, что именно подтолкнуло его обратиться к экспертам
  • Проверяем KPI на проекте.

Если на проекте всё ок, то успокаиваем заказчика и идем дальше. Если не ок — исправляем.

Вариант ответа: Сделать всё так, как говорят эксперты

Вариант без оценки мотивов заказчика, и проверки KPI на проекте. Подобный вариант даже чем-то привлекательный с точки зрения программистов. Есть возможность всё переписать «набело», покрыть юнит-тестами и т.д. Особенно, если за счет заказчика.

  • Переписать? Да без проблем. Любой каприз за ваши деньги.

Недостатки:

  • демотивация команды «мы строили-строили, а оно никому и не нужно». Alice очень верно это отметила.
  • заказчик может и исполнителей сменить под шумок
Tagged , ,

Добавить комментарий

Ваш e-mail не будет опубликован.