Независимые эксперты

Коллеги, от одного из наших постоянных читателей пришел вопрос про построение отношений с заказчиком. Конечно, отношения с Заказчиком — это любимая тема Сергей Бережного AKA @anotherpm, но и с точки зрения коммуникации кейс тоже интересный.

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

С точки зрения PMа, проект в нормальном состоянии — новые фичи появляются, разработка идет стабильно и равномерно, ошибки исправляются быстро, критических жалоб со стороны пользователей нет. PM считает, что оценка экспертов необоснованна, т.к. чужая работа всегда кажется легче.

Задача: по мнению PMа, проект находиться в очень хорошем состоянии, и полный рефакторинг сейчас излишен. Эту мысль надо донести заказчику.

Как это лучше сделать, коллеги, какие есть идеи?

Tagged ,

15 комментариев: Независимые эксперты

  1. Александр говорит:

    «Еще эксперты были в шоке…»
    А что, у экспертов были все данные об истории развития проекта, что они могут судить о производительности?

    Если отбросить вариант действительно слабых проф. навыков разработчиков, то, к.м.к., наблюдаем результат классического треугольника стоимость-сроки-качество.
    Соответственно, свои доводы строить на этой основе.

    Полный рефакторинг вообще редко используется. Если это именно тот случай, то взять и переписать заново — единственно правильное решение. Никакой полный рефакторинг тут не поможет, да и смысла тратить ресурсы на него нет.

    • Что-то им заказчик рассказал — нам не известно. Идея донести заказчику мысль про треугольник — это правильно. Вопрос в том, как подать и как он к этому отнесется. В комментах (здесь и на фейсбуке) справедливо сказали, что что-то же заставило его обратиться к экспертам.

      • Александр говорит:

        Как подать?
        Мало данных, вариантов много.
        Некоторые варианты другие комментаторы приводили.

        Не обязательно «что-то заставило» с смысле проблем.
        Мог ведь просто поддаться модному тренду через сарафанное радио или интернет-статью.

        • Александр говорит:

          Я, собственно, почему так акцентирую внимание на отсутствии видения всей картины.
          Пара примеров.
          1. Важно знать рыночную нишу, позиционирование продукта. Наличие/отсутствие конкурентов у продукта.
          Что определяет? Риски для заказчика.
          На что влияет? На сроки, ресурсы.
          Одно дело, когда это софт для внутреннего использования заказчиком, совсем другое, если команда пишет на аутсорс какой-нибудь сервис.

          2. Аналогично п1., только вместо продукта выступает команда разработчиков.
          Риски тут не только для заказчика, но и для команды.
          Для команды из большой фирмы (одна из многих) и команды-фирмы советы нужно давать разные, т.к. финансовые и имиджевые риски разные.

          3. Связь продукта (зависимости) с остальным миром.
          Например, наличие API, используемое сторонними компаниями или продуктами повлечет за собой большууую головную боль для всех сторон.

        • Насчет сарафанного радио и модных трендов — это супер! Некоторые люди делают техосмотр «просто так», заранее, для профилактики.

  2. Джек говорит:

    Для начала скажу, что переписать проект с нуля — мечта любого разработчика, поэтому если находится заказчик, желающий оплатить эту работу, его надо холить и лелеять, тем более если проект действительно долгий, и технический долг есть, то нужно ловить момент, когда заказчик готов оплачивать работы по его устранению.

    Если же все-таки рефакторить мы не хотим, то я бы обьяснил заказчику полный объем и стоимость работ по рефакторингу. Далее, обратил бы особое внимание на последствия в виде увеличения сроков добавления новой функциональности. Подчеркнул бы риски появления новых дефектов в уже сданных и работающих частях проекта (всегда есть дефекты, упускаемые внутренним QC).

    Если проект длительный, можно добавить рефакторинг в устраивающее обе стороны место в roadmap, или обсудить поэтапный рефакторинг модулей в процессе добавления в них новой функциональности.

    P.S. Читаю сайт через RSS, и пропустил смену дизайна. А куда делась возможность комментирования через OpenID/Facebook?

    • Правильно ли я понял, что есть три варианта ответа. В виде моделей их можно представить так:
      — Мы хотим переписать заново — стоит поддержать мнение экспертов и убедиться, что работа будет оплачена;
      — Мы не хотим переписывать заново — объясняем заказчику полную стоимость подобной работы, рассказываем о рисках связанных с подобной работой, и о недополученных выгодах. То есть рисуем мрачную картинку перед ним, если мы пойдем на этот шаг.
      — Компромисс, соглашаемся с тем что рефакторинг нужен, правда критической необходимости в нем сейчас нет, и предлагаем определить, когда мы его будем проводить.
      Уточнения от автора кейса: проект сравнительно свежий. Мнение тех, кто работает на проекте с начала (полгода-год) — технический долг невелик.

      P.S. Спасибо про инфу про отпавшую логинзу. Fixed.

      • Джек говорит:

        В целом так, хотя соглашаться с экспертами все же не стоит, уж больно резкая оценка, заставляющая сомниваться в их компетентности. Но в любом проекте найдется достаточно внутренних причин для рефакторинга.

        Если уж рефакторим, можно еще предложить клиенту пригласить консультанта-архитектора со стороны для разработки устраивающей все стороны архитектуры.

        Все это говорю на основании опыта — мне приходилось учавствовать как в проектах, проходивших аудит кода экспертами (правда, не такими хамоватыми, как описанные), так и в проектах с консультирующим архитектором.

        P.S. Хоть логинза и позволяет логиниться, все равно требуется вводить имя и почту.

        • Согласен, можно «под шумок» и провести рефакторинг проекта и/или пригласить архитектора со стороны, за счет заказчика. Думаю, что можно согласиться в чем-то безопасном для нас, например: «наверное у экспертов были основания дать такую оценку», а потом поинтересоваться — «вся ли информация об этапах разработки была у экспертов?»

          P.S. На логинзу посмотрю более пристально, спасибо.

  3. Alice говорит:

    Согласна с предыдущими комментаторами, полный рефакторинг или полное переписывание кода должно оплачиваться. Плюс, как уже сказали, есть большие риски потери информации и функционала.
    Из описанной ситуации непонятна позиция заказчика — согласен ли он с мнением экспертов, действительно ли он думает, что в коде полный бардак, или может быть кто-то ему сказал, что привлечение независимых экспертов это круто, модно, да и вообще все так вокруг делают. Вполне вероятно, что вся эта активность заказчика прекратиться с уходом экспертов. А может быть это способ «прозрачно намекнуть» команде, что за ними «следят» и непонятно что и матерные комментарии в коде не потерпят:) Опять же, продолжения у этого намёка может и не быть.
    Допустим, ситуация складывается так, что заказчик безоглядно верит экспертам, намерен весь проект переписать и даже за это заплатить. А PM и команда уверены, что показаний для этого нет, и что подобное глубокое вторжение в код проекту и команде только навредит (команда может быть сильно демотивирована тем, что хороший/приемлемый с их точки зрения код заставляют переписывать; особенно нехорошо получится, если разработчики уверены, что большую часть кода по-другому написать нельзя и они будут тратить время на копи-паст). В таком случае, во-первых, надо аргументировано прокомментировать для заказчика все замечания экспертов, а во-вторых, сделать небольшую рекламу команде, отметить положительные моменты в проекте.
    Судя по описанию вердикта экспертов, у проекта нет проблем с производительность (которую мог бы повлечь за собой плохо написанный код), также нет претензий у пользователей. То есть приложение или система всех удовлетворяет (более или менее). Подобные идеи можно донести в качестве «рекламы».
    Замечание, что код запутан, можно нивелировать толково написанными комментариями или какой-либо документацией «в помощь разработчикам». Если этого нет, то такой вариант можно предложить в качестве компромиссного вместо переписывания с нуля. На замечание про время можно объяснить (или напомнить, но крайне аккуратно), почему в итоге получилось такое количество строк на единицу времени на одного человека. Возможно, что команда занималась не только тем, что денно и нощно писала код. Возможно, разработчики помимо кодинга что-то анализировали, исследовали, проектировали и разрабатывали. Ещё можно сказать, что если бы тоже самое было написано быстрее, то возникли бы определённые сложности, и перечислить их (например, разработчики в спешке не смогли бы как следует разобраться в каком-либо алгоритме, по этому алгоритму стали бы поступать неопределённые нарекания от пользователей, доработки были бы в несколько итераций и в итоге времени было бы потрачено ещё больше).
    Считаю, что при заказчике не стоит говорить то, что оценка экспертов была необоснованной. У них были свои критерии, они выдавали оценки на основе той информации, которая у них была. И эта оценка корректна, но именно в разрезе той ситуации, которую эксперты представили. PM, как человек не первый день работающий на проекте, имеет более полную картину. Именно на этом можно сделать основной акцент.

    • Alice, спасибо за развернутый ответ.
      Потеря информации при рефакторинге — это действительно большой риск. Особенно, если большая часть информации — только в головах разработчиков. Идея, про намек команде — это тоже правильно, я до такого не додумался.
      Заказчик претензий к скорости разработки до обращения к экспертам не имел.
      > Считаю, что при заказчике не стоит говорить то, что оценка экспертов была необоснованной.
      Золотые слова. Если заказчик к ним обратился, значит, чем-то они для него важны. Для меня здесь наибольший интерес представляет, как именно PMу сказать заказчику о своей лучшей картине, так чтобы не зацепить его убеждения и получить результат.

    • Алиса, детальный ответ, спасибо.
      Я увидел в твоем комменте такой набор действий: похвалить команду перед заказчиком, провести работу с возражениями, согласиться с мнением экспертов, но указать что РМ имеет более полную картину.

      Что хотелось бы добавить: в какой последовательности стоит эти действия делать, какое сделать предложение заказчику?

  4. Коллеги, в кросспосте на фейсбуке http://www.facebook.com/vladimir.zheleznyak.35/posts/4256726748414 тоже пошло обсуждение. Присоединяйтесь!

  5. Уведомление: Независимые эксперты + Сократический диалог | Психология в IT

  6. Уведомление: разбор кейса «Независимые эксперты» | Психология в IT

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

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