Может ли клиент оценить качество кода?

2014-01-31

Мой друг натолкнул меня на мысли о проблеме, объединяющей всех разработчиков ПО:

Как сделать так, чтобы клиенты оценили важность написанного нами кода?

Качественный код крайне сложно продать, ведь его никто не видит.

Каждый разработчик сталкивался с вечной борьбой между «сделать качественно» и «сделать быстро». В своё время я даже написал по этому поводу книгу «Разработка архитектуры приложений в реальном мире на .NET» и опубликовал её на PluralSight.

Для разработчиков совершенно естественно познакомиться с очередной успешной методологией и захотеть применять её везде. Однако, в авральной ситуации разработчики быстро возвращаются к режиму «запилить как можно быстрее». Что это означает? А это означает, что на время программист забывает о «чистом коде» и автоматическом тестировании. Многим кажется, что разработка через тестирование в долгосрочной перспективе позволяет быстрее закончить проект, но последние исследования Майкрософт показывают, что TDD на 15-35% увеличивают срок выполнения проекта. TDD, как и многие другие прогрессивные практики разработки, – это инвестиции, которые окупаются не сразу.

Поэтому перед нами встаёт вопрос:

Кто регулирует качество разрабатываемого приложения?

Существует два подхода:

1. Качество диктуется разработчиком. Программист пишет код так, чтобы чувствовать себя удовлетворённым и компетентным. Он даже не обсуждает процесс с клиентом. В конце концов, зачем ему эти технические нюансы?

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

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

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

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

Как профессионалы в сфере разработки ПО, мы понимаем, что вопросы качества — это не те вопросы, где есть только чёрное и белое. Наша задача — выяснить потребности клиента и выбрать достаточно качественное и быстрое решение. Другими словами, вашим предложением для клиента никогда не будет «100%-ное покрытие тестами» или «отсутствие тестирования». Принимайте решение, исходя из ситуации. И если случится так, что установленные сроки не позволяют вам гарантировать отличное качество работы, не стоит молча снижать его, чтобы уложиться в сроки.

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

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

А вы бы стали обсуждать технические вопросы со своими клиентами?

Перевод: Люся Ширшова. По материалам статьи на bitnative.com.