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

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

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

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

Заказчик

Что хочет?

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

Чего боится?

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

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

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

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

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

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

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

Что делать?

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

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

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

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

Что делать?

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

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

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

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

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

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

Недостатки:

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

Leave a Reply

Your email address will not be published.