Коллеги, давайте напомним описание кейса
Заказчик обратился к нескольким именитым независимым экспертам для проверки качества кода проекта. Эксперты, конечно, выдали свою оценку. Если кратко — код ужасно запутан, что неизбежно приведет к проблемам при дальнейшем росте проекта и при добавлении новых разработчиков. Еще эксперты были в шоке, что за такое время такая команда написала всего N строк кода. Что такой проект реально было написать вдвоем за втрое меньшее время. И что в данный момент у проекта огромный технический долг. Настоятельная рекомендация экспертов — всё переделать. Желательно с нуля.
C чего тут стоит начать? На наш взгляд, стоит начать со взгляда на ситуацию со стороны заказчика.
Заказчик
Что хочет?
- Сделать проект качественно, в срок, в бюджете. Приоритеты, по словам PMа, именно такие. Качество важнее всего, сроки важны, бюджет – попросту разумен.
Чего боится?
Артем Сердюк совершенно справедливо указал, что мы не знаем, что было в бизнес-прошлом у этого заказчика. Мог быть и сомнительный код, и бесконечные “will be done tomorrow” и выход за бюджет.
Действия со стороны PM
Узнать, что двигало заказчиком, когда он обратился к экспертам. Самый простой способ – это задать вопрос. Гипотезы, которые стоит проверить:
Гипотеза: Заказчик перестраховался
Заказчик спокоен, и он просто следует best practices. Либо просто встретил знакомых экспертов “- а хочешь, мы твой проект заревьювим нахаляву? – а давай”.
С одной стороны, хорошо, если заказчик просто перестраховался. С другой – экспертами поставлены негативные оценки и это требует действий. И хорошо ли теперь на проекте после такого code review – уже сложно сказать.
Контрольные вопросы для понимания ситуации:
- как обычно ведет себя заказчик когда волнуется? Он становиться болтливым? Замкнутым? Задает много вопросов или начинает учить правильно работать?
Если до обращения к экспертам заказчик вел себя так же, как и обычно, то он перестраховался, с большой вероятностью
Если эта гипотеза подтверждается, то у заказчика не было серьезных поводов волноваться ДО code review. Но ПОСЛЕ у него уже поводы были.
Что делать?
Что мы можем сказать заказчику?
- “твои эксперты ошиблись и, вообще, идиоты”. Ведь, если он обратился к экспертам, значит, их мнение для него что-то значит. Здесь в дело вступает защита собственного выбора: “умный я выбрал экспертов, значит и они тоже умны”. Сомнения в экспертах – это сомнение и в выбравшем их.
- “успокойся, всё будет хорошо”. Эта фраза обычно ведет к взрыву – очень многим не нравится, когда им говорят, что надо чувствовать в какой-то ситуации.
- Воспользоваться Сократическим Диалогом с выводом на разные сценарии дальнейшей работы: рефакторим или нет; если рефакторим, то что.
Гипотеза: Заказчика что-то напугало
Может быть, он увидел на проекте что-то этакое. Например, для начинающего заказчика может быть непонятно, что производительность меняется скачкообразно от недели к неделе. Еще причина может быть вообще снаружи проекта – например, заказчик почувствовал приближение кризиса.
Мы не знаем, и лучший способ узнать – это спросить. Не обязательно, конечно, что он ответит правду “как есть”, но у нас здесь есть важный помощник. Если KPI для программиста подсчитать практически невозможно, то KPI для проекта – очень даже можно. Например, количество багов, замеченных пользователями за прошлый спринт, или uptime для сервера, или изменение velocity команды, или много задач висит в состоянии “90% done”.
Что делать?
Подготовительные действия:
- Спрашиваем заказчика, что именно подтолкнуло его обратиться к экспертам
- Проверяем KPI на проекте.
Если на проекте всё ок, то успокаиваем заказчика и идем дальше. Если не ок – исправляем.
Вариант ответа: Сделать всё так, как говорят эксперты
Вариант без оценки мотивов заказчика, и проверки KPI на проекте. Подобный вариант даже чем-то привлекательный с точки зрения программистов. Есть возможность всё переписать “набело”, покрыть юнит-тестами и т.д. Особенно, если за счет заказчика.
- Переписать? Да без проблем. Любой каприз за ваши деньги.
Недостатки:
- демотивация команды “мы строили-строили, а оно никому и не нужно”. Alice очень верно это отметила.
- заказчик может и исполнителей сменить под шумок
