Независимые эксперты + Сократический диалог

Разбор кейса «Независимые эксперты» мы сделаем позже, а пока идет обсуждение «что делать», хотелось бы предложить схему «как делать».

  • Давайте сделаем допущение, что PM в данной ситуации всё тщательно обдумал, и таки хочет донести до заказчика мысль «код на проекте хороший».

В чем есть риск? В том, что заказчик уже этих экспертов выбрал и к ним обратился. Он вложил своё время, и, возможно, деньги. Люди склонны защищать свои решения, бизнесмены — тем более. Прямое заявление PMа, что эти эксперты дураки не владеют всем объемом информации, запросто будет воспринято как обвинение в адрес заказчика. В таком случае включится психологическая защита, пойдут придирки по мелочам, анализ таймрепортов за полгода… В результате — много-много головняка.
Поскольку Сократический диалог и предназначен для обхода защиты, то давайте попробуем его и использовать.

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

Шаг 1. Согласиться

Давайте посмотрим, какие там есть утверждения, и с чем там можно согласиться. И сразу построим ответ в форме фразы для заказчика:

  • Заказчик обратился к нескольким именитым независимым экспертам для проверки качества кода проекта. Наш ответ заказчику:
    • Джон, эксперты, которые работают в <имя_компании> — это серьезно
    • Джон, перекрестная проверка со стороны нескольких независимых экспертов — это серьезный шаг. Думаю, у тебя были веские основания так поступить.
  • Код ужасно запутан, что неизбежно приведет к проблемам при дальнейшем росте проекта и при добавлении новых разработчиков. Наш ответ заказчику:
    • Качество кода — это важный показатель состояния проекта и его будущего.
    • Запутанный код — плохой признак
    • В сложном и запутанном коде новичкам сложно разобраться
  • У проекта огромный технический долг. Наш ответ заказчику:
    • В проекте точно есть места, которые можно улучшить

Список можно продолжить и еще, он сильно зависит от конкретного проекта.

Шаг 2. Провоцируем сомнения

Давайте посмотрим на сомнительные места:

  • Эксперты, конечно, выдали свою оценку. Мы вопросом провоцируем сомнения о полноте информации у экспертов:
    • Джон, насколько полной информацией обладали эксперты? Была ли у них возможность пообщаться с разработчиками, посмотреть багтрекер, прочитать документацию из wiki и гитхаба? Было ли у них достаточно времени на это?
  • Еще эксперты были в шоке, что за такое время такая команда написала всего N строк кода. Мы провоцируем сомнения в достаточности информации у экспертов.
    • Ко всем ли репозиториям получили доступ эксперты? Я сейчас вижу, что у нас в коде, как минимум, 2N строк.
  • Что такой проект реально было написать вдвоем за втрое меньшее время. Мы провоцируем сомнения в выводах экспертов.
    • Бывают команды, которые обгоняют других в разы. Но в шесть раз — я с таким сталкиваюсь впервые.

Шаг 3. Предлагаем решение

Описываем, как мы видим ситуацию, и какие можно сделать шаги.

Tagged , ,

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

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

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>