Коллеги, от одного из наших постоянных читателей пришел вопрос про построение отношений с заказчиком. Конечно, отношения с Заказчиком – это любимая тема Сергей Бережного AKA @anotherpm, но и с точки зрения коммуникации кейс тоже интересный.
Заказчик обратился к нескольким именитым независимым экспертам для проверки качества кода проекта. Эксперты, конечно, выдали свою оценку. Если кратко – код ужасно запутан, что неизбежно приведет к проблемам при дальнейшем росте проекта и при добавлении новых разработчиков. Еще эксперты были в шоке, что за такое время такая команда написала всего N строк кода. Что такой проект реально было написать вдвоем за втрое меньшее время. И что в данный момент у проекта огромный технический долг. Настоятельная рекомендация экспертов – всё переделать. Желательно с нуля.
С точки зрения PMа, проект в нормальном состоянии – новые фичи появляются, разработка идет стабильно и равномерно, ошибки исправляются быстро, критических жалоб со стороны пользователей нет. PM считает, что оценка экспертов необоснованна, т.к. чужая работа всегда кажется легче.
Задача: по мнению PMа, проект находиться в очень хорошем состоянии, и полный рефакторинг сейчас излишен. Эту мысль надо донести заказчику.
Как это лучше сделать, коллеги, какие есть идеи?
“Еще эксперты были в шоке…”
А что, у экспертов были все данные об истории развития проекта, что они могут судить о производительности?
Если отбросить вариант действительно слабых проф. навыков разработчиков, то, к.м.к., наблюдаем результат классического треугольника стоимость-сроки-качество.
Соответственно, свои доводы строить на этой основе.
Полный рефакторинг вообще редко используется. Если это именно тот случай, то взять и переписать заново – единственно правильное решение. Никакой полный рефакторинг тут не поможет, да и смысла тратить ресурсы на него нет.
Что-то им заказчик рассказал – нам не известно. Идея донести заказчику мысль про треугольник – это правильно. Вопрос в том, как подать и как он к этому отнесется. В комментах (здесь и на фейсбуке) справедливо сказали, что что-то же заставило его обратиться к экспертам.
Как подать?
Мало данных, вариантов много.
Некоторые варианты другие комментаторы приводили.
Не обязательно “что-то заставило” с смысле проблем.
Мог ведь просто поддаться модному тренду через сарафанное радио или интернет-статью.
Я, собственно, почему так акцентирую внимание на отсутствии видения всей картины.
Пара примеров.
1. Важно знать рыночную нишу, позиционирование продукта. Наличие/отсутствие конкурентов у продукта.
Что определяет? Риски для заказчика.
На что влияет? На сроки, ресурсы.
Одно дело, когда это софт для внутреннего использования заказчиком, совсем другое, если команда пишет на аутсорс какой-нибудь сервис.
2. Аналогично п1., только вместо продукта выступает команда разработчиков.
Риски тут не только для заказчика, но и для команды.
Для команды из большой фирмы (одна из многих) и команды-фирмы советы нужно давать разные, т.к. финансовые и имиджевые риски разные.
3. Связь продукта (зависимости) с остальным миром.
Например, наличие API, используемое сторонними компаниями или продуктами повлечет за собой большууую головную боль для всех сторон.
Насчет сарафанного радио и модных трендов – это супер! Некоторые люди делают техосмотр “просто так”, заранее, для профилактики.
Для начала скажу, что переписать проект с нуля — мечта любого разработчика, поэтому если находится заказчик, желающий оплатить эту работу, его надо холить и лелеять, тем более если проект действительно долгий, и технический долг есть, то нужно ловить момент, когда заказчик готов оплачивать работы по его устранению.
Если же все-таки рефакторить мы не хотим, то я бы обьяснил заказчику полный объем и стоимость работ по рефакторингу. Далее, обратил бы особое внимание на последствия в виде увеличения сроков добавления новой функциональности. Подчеркнул бы риски появления новых дефектов в уже сданных и работающих частях проекта (всегда есть дефекты, упускаемые внутренним QC).
Если проект длительный, можно добавить рефакторинг в устраивающее обе стороны место в roadmap, или обсудить поэтапный рефакторинг модулей в процессе добавления в них новой функциональности.
P.S. Читаю сайт через RSS, и пропустил смену дизайна. А куда делась возможность комментирования через OpenID/Facebook?
Правильно ли я понял, что есть три варианта ответа. В виде моделей их можно представить так:
– Мы хотим переписать заново – стоит поддержать мнение экспертов и убедиться, что работа будет оплачена;
– Мы не хотим переписывать заново – объясняем заказчику полную стоимость подобной работы, рассказываем о рисках связанных с подобной работой, и о недополученных выгодах. То есть рисуем мрачную картинку перед ним, если мы пойдем на этот шаг.
– Компромисс, соглашаемся с тем что рефакторинг нужен, правда критической необходимости в нем сейчас нет, и предлагаем определить, когда мы его будем проводить.
Уточнения от автора кейса: проект сравнительно свежий. Мнение тех, кто работает на проекте с начала (полгода-год) – технический долг невелик.
P.S. Спасибо про инфу про отпавшую логинзу. Fixed.
В целом так, хотя соглашаться с экспертами все же не стоит, уж больно резкая оценка, заставляющая сомниваться в их компетентности. Но в любом проекте найдется достаточно внутренних причин для рефакторинга.
Если уж рефакторим, можно еще предложить клиенту пригласить консультанта-архитектора со стороны для разработки устраивающей все стороны архитектуры.
Все это говорю на основании опыта — мне приходилось учавствовать как в проектах, проходивших аудит кода экспертами (правда, не такими хамоватыми, как описанные), так и в проектах с консультирующим архитектором.
P.S. Хоть логинза и позволяет логиниться, все равно требуется вводить имя и почту.
Согласен, можно “под шумок” и провести рефакторинг проекта и/или пригласить архитектора со стороны, за счет заказчика. Думаю, что можно согласиться в чем-то безопасном для нас, например: “наверное у экспертов были основания дать такую оценку”, а потом поинтересоваться – “вся ли информация об этапах разработки была у экспертов?”
P.S. На логинзу посмотрю более пристально, спасибо.
Согласна с предыдущими комментаторами, полный рефакторинг или полное переписывание кода должно оплачиваться. Плюс, как уже сказали, есть большие риски потери информации и функционала.
Из описанной ситуации непонятна позиция заказчика — согласен ли он с мнением экспертов, действительно ли он думает, что в коде полный бардак, или может быть кто-то ему сказал, что привлечение независимых экспертов это круто, модно, да и вообще все так вокруг делают. Вполне вероятно, что вся эта активность заказчика прекратиться с уходом экспертов. А может быть это способ «прозрачно намекнуть» команде, что за ними «следят» и непонятно что и матерные комментарии в коде не потерпят:) Опять же, продолжения у этого намёка может и не быть.
Допустим, ситуация складывается так, что заказчик безоглядно верит экспертам, намерен весь проект переписать и даже за это заплатить. А PM и команда уверены, что показаний для этого нет, и что подобное глубокое вторжение в код проекту и команде только навредит (команда может быть сильно демотивирована тем, что хороший/приемлемый с их точки зрения код заставляют переписывать; особенно нехорошо получится, если разработчики уверены, что большую часть кода по-другому написать нельзя и они будут тратить время на копи-паст). В таком случае, во-первых, надо аргументировано прокомментировать для заказчика все замечания экспертов, а во-вторых, сделать небольшую рекламу команде, отметить положительные моменты в проекте.
Судя по описанию вердикта экспертов, у проекта нет проблем с производительность (которую мог бы повлечь за собой плохо написанный код), также нет претензий у пользователей. То есть приложение или система всех удовлетворяет (более или менее). Подобные идеи можно донести в качестве «рекламы».
Замечание, что код запутан, можно нивелировать толково написанными комментариями или какой-либо документацией «в помощь разработчикам». Если этого нет, то такой вариант можно предложить в качестве компромиссного вместо переписывания с нуля. На замечание про время можно объяснить (или напомнить, но крайне аккуратно), почему в итоге получилось такое количество строк на единицу времени на одного человека. Возможно, что команда занималась не только тем, что денно и нощно писала код. Возможно, разработчики помимо кодинга что-то анализировали, исследовали, проектировали и разрабатывали. Ещё можно сказать, что если бы тоже самое было написано быстрее, то возникли бы определённые сложности, и перечислить их (например, разработчики в спешке не смогли бы как следует разобраться в каком-либо алгоритме, по этому алгоритму стали бы поступать неопределённые нарекания от пользователей, доработки были бы в несколько итераций и в итоге времени было бы потрачено ещё больше).
Считаю, что при заказчике не стоит говорить то, что оценка экспертов была необоснованной. У них были свои критерии, они выдавали оценки на основе той информации, которая у них была. И эта оценка корректна, но именно в разрезе той ситуации, которую эксперты представили. PM, как человек не первый день работающий на проекте, имеет более полную картину. Именно на этом можно сделать основной акцент.
Alice, спасибо за развернутый ответ.
Потеря информации при рефакторинге – это действительно большой риск. Особенно, если большая часть информации – только в головах разработчиков. Идея, про намек команде – это тоже правильно, я до такого не додумался.
Заказчик претензий к скорости разработки до обращения к экспертам не имел.
> Считаю, что при заказчике не стоит говорить то, что оценка экспертов была необоснованной.
Золотые слова. Если заказчик к ним обратился, значит, чем-то они для него важны. Для меня здесь наибольший интерес представляет, как именно PMу сказать заказчику о своей лучшей картине, так чтобы не зацепить его убеждения и получить результат.
Алиса, детальный ответ, спасибо.
Я увидел в твоем комменте такой набор действий: похвалить команду перед заказчиком, провести работу с возражениями, согласиться с мнением экспертов, но указать что РМ имеет более полную картину.
Что хотелось бы добавить: в какой последовательности стоит эти действия делать, какое сделать предложение заказчику?
Коллеги, в кросспосте на фейсбуке http://www.facebook.com/vladimir.zheleznyak.35/posts/4256726748414 тоже пошло обсуждение. Присоединяйтесь!
Уведомление: Независимые эксперты + Сократический диалог | Психология в IT
Уведомление: разбор кейса «Независимые эксперты» | Психология в IT