Хитро -*@[%№ -умный заказчик. Часть 1

Попытаюсь проанализировать некоторые ситуации, когда заказчик чудит. А именно, под предлогом того, что проектная команда сделала «не то», «не так», «не все», «медленно», «некачественно» и т.п. настаивает на доделках, переделках, скидках и прочих благах для себя.

Обычно виды реакции проектной команды примерно такие: доказать свою невиновность, доказать виновность заказчика, попробовать договориться (но обычно в ущерб себе).

Например, заказчик предъявляет претензии к качеству кода и архитектурным решениям, настаивает «все переделать по-правильному», и, внимание – БЕСПЛАТНО! Анализ претензии и работы показывает, что:

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

А теперь давайте вспомним определение качества – «Качество — это степень соответствия продукта выдвинутым требованиям». Как-то так.

В этом примере этими самыми выдвинутыми требованиями (которые были задвинуты куда подальше) могли бы быть:

  • Стандарты кодирования
  • Оговоренный процесс код ревью со всеми чеклистами, инструментарием, ответственностями
  • Оговоренный процесс формализации требований со всеми ответственностями, процедурами ревью и утверждения и т.п.
  • Оговоренные процессы архитектурных решений и рефакторинга
  • И, ВНИМАНИЕ!, что будет, если эти процессы (инженерные практики) НАМЕРЕННО «выкидываются»

Важно то, что эти процессы должны быть формализованы и приняты обеими сторонами любом удобном виде. Кроме «мы это и так подразумеваем», такой удобный вид НЕ ПОДХОДИТ.

Это может быть томик документации на пару килограмм, диаграмма на одну страничку, страничка на портале проекта, сфотографированное описание процесса на доске и т.п. Главное, чтобы оно было читаемо глазами, доступно всем и понятно.

Еще раз, «мы это и так подразумеваем» НЕ ПОДХОДИТ!

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

Поняли к чему это? Все к тому же – оговоренным заранее критериям качества, которые могли бы совершенно однозначно сказать, где грань «некачества» и «медленно», хоть за весь период, хоть за его часть. Чтобы вместо драматичного беспокойства были цифры и факты.

Итак, что можно предположить:

  • Надо договариваться ЗАРАНЕЕ
  • Надо договариваться о КОНКРЕТНЫХ вещах, даже до мелочей, и не бояться быть занудой
  • Надо знать о политических, финансовых и других МОТИВАХ заказчика, в интересах которых он может «чудить»
  • Никогда НЕЛЬЗЯ РАССЛАБЛЯТЬСЯ, особенно если все идет гладко
  • Эти все договоренности и мотивы однозначно выходят за рамки только лишь проектной команды.

А вот кому, когда, как, и о каких вещах договариваться напишу во второй части через 2-3 недели.

Tags: , ,

Comments are closed.