Разбор кейса “Независимые эксперты” мы сделаем позже, а пока идет обсуждение “что делать”, хотелось бы предложить схему “как делать”.
- Давайте сделаем допущение, что PM в данной ситуации всё тщательно обдумал, и таки хочет донести до заказчика мысль “код на проекте хороший”.
В чем есть риск? В том, что заказчик уже этих экспертов выбрал и к ним обратился. Он вложил своё время, и, возможно, деньги. Люди склонны защищать свои решения, бизнесмены – тем более. Прямое заявление PMа, что эти эксперты дураки не владеют всем объемом информации, запросто будет воспринято как обвинение в адрес заказчика. В таком случае включится психологическая защита, пойдут придирки по мелочам, анализ таймрепортов за полгода… В результате – много-много головняка.
Поскольку Сократический диалог и предназначен для обхода защиты, то давайте попробуем его и использовать.
Заказчик обратился к нескольким именитым независимым экспертам для проверки качества кода проекта. Эксперты, конечно, выдали свою оценку. Если кратко — код ужасно запутан, что неизбежно приведет к проблемам при дальнейшем росте проекта и при добавлении новых разработчиков. Еще эксперты были в шоке, что за такое время такая команда написала всего N строк кода. Что такой проект реально было написать вдвоем за втрое меньшее время. И что в данный момент у проекта огромный технический долг. Настоятельная рекомендация экспертов — всё переделать. Желательно с нуля.
Шаг 1. Согласиться
Давайте посмотрим, какие там есть утверждения, и с чем там можно согласиться. И сразу построим ответ в форме фразы для заказчика:
- Заказчик обратился к нескольким именитым независимым экспертам для проверки качества кода проекта. Наш ответ заказчику:
- Джон, эксперты, которые работают в <имя_компании> – это серьезно
- Джон, перекрестная проверка со стороны нескольких независимых экспертов – это серьезный шаг. Думаю, у тебя были веские основания так поступить.
- Код ужасно запутан, что неизбежно приведет к проблемам при дальнейшем росте проекта и при добавлении новых разработчиков. Наш ответ заказчику:
- Качество кода – это важный показатель состояния проекта и его будущего.
- Запутанный код – плохой признак
- В сложном и запутанном коде новичкам сложно разобраться
- У проекта огромный технический долг. Наш ответ заказчику:
- В проекте точно есть места, которые можно улучшить
Список можно продолжить и еще, он сильно зависит от конкретного проекта.
Шаг 2. Провоцируем сомнения
Давайте посмотрим на сомнительные места:
- Эксперты, конечно, выдали свою оценку. Мы вопросом провоцируем сомнения о полноте информации у экспертов:
- Джон, насколько полной информацией обладали эксперты? Была ли у них возможность пообщаться с разработчиками, посмотреть багтрекер, прочитать документацию из wiki и гитхаба? Было ли у них достаточно времени на это?
- Еще эксперты были в шоке, что за такое время такая команда написала всего N строк кода. Мы провоцируем сомнения в достаточности информации у экспертов.
- Ко всем ли репозиториям получили доступ эксперты? Я сейчас вижу, что у нас в коде, как минимум, 2N строк.
- Что такой проект реально было написать вдвоем за втрое меньшее время. Мы провоцируем сомнения в выводах экспертов.
- Бывают команды, которые обгоняют других в разы. Но в шесть раз – я с таким сталкиваюсь впервые.
Шаг 3. Предлагаем решение
Описываем, как мы видим ситуацию, и какие можно сделать шаги.
