Заказчик обучен вас использовать. Эпизод 4

Серия постов с конкретными ситуациями. Цель — обратить внимание на особенности взаимодействия — избежать, быть готовым к подобному. предыдущие Эпизоды см на www.it-tuning.com или www.facebook.com/it.tuning.

Было такое, когда заказчик говорит «а зачем нам тестирование? Разве ваши разработчики не могут качественно работать?», и не хочет оплачивать тестирование, или совсем, или оплачивает в гораздо меньшем объеме чем требуется. Кстати, типичное соотношение разработчиков к тестировщикам в типичном проекта разработки ПО порядка 1-го тестировщика на 3-4 разработчиков, +/-. Или же, когда вы говорите, что собираетесь делать такие инженерные практики как код ревью, или ревью документации, или писать документацию, то тоже можете получить нежелание заказчика их внедрять и оплачивать. При этом заказчик может аргументировать свое нежелание как угодно. Действительно ли он не понимает ценность определенных практик? Возможно. Но также возможно, что у него ограничен бюджет. Будет ли такой заказчик открыто говорить об этом исполнителю? Вряд ли, т.к. не хочет показаться неплатежеспособным. Он просто хочет больше «напедалить» за меньшие деньги. Суть именно в этом. Хотя, есть заказчики, которые могут прямо сказать — «бюджет ограничен, поэтому не могу позволить применять все инженерные практики».

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

  • Если заказчик хочет сэкономить (говоря об этом открыто или завуалировано) это нормально! Имеет полное право. Важно договориться, что делаем, а что не делаем.
  • Попытаться выяснить бюджетные ограничения и ожидаемое заказчиком количество результата на выходе. Это может оказаться не так сложно как кажется, если не получается напрямую узнать бюджет, то можно опосредованно, исходя из заказываемого объема работ.
  • Нужно обязательно выяснить приоритеты заказчика по срокам, бюджету, объему работ и т.п. Например, разрабатываемое приложение может быть важно сдать к учебному сезону, к рождеству, к выставке и т.п. Если вы это знаете, то намного проще договариваться о приоритетах. Есть пример из жизни, когда заказчик говорил: «я знаю, что в команде в два раза меньше тестировщиков чем нужно, больше финансово не могу позволить, но у меня начало сезона 1 сентября, мне нужно педалить, меня вполне устроит наличие некритичных bug-ов, претензий по ним иметь не буду».
  • Можно и нужно попытаться объяснить заказчику ценность тех или иных практик. НО! Понятным ему языком, а именно перевести ценность практик в сэкономленное время, деньги и другие понятные заказчику ценности.
  • И самая главная рекомендация — ФОРМАЛЬНО закрепить, желательно подписать соглашение о том, какие инженерные и управленческие практики применяются, а какие нет. И что будет если нет? И что будет, если не смотря на договоренности заказчик настаивает «выбросить» ту или иную практику? Формулировка может звучать так: «практика код ревью не применяется, стороны осознают возможные последствия по отношению к качеству кода и качеству алгоритмических решений, но потенциальные проблемы, возникшие по этой причине не могут являться источником претензий Заказчика к Исполнителю. В случае необходимости исправления таких проблем они рассматриваются как запросы на Изменения».

Где такие договоренности фиксировать? В Договоре, в приложении к Договору, в Уставе Проекта. Или хотя бы в емейл (с копиями на руководство с обеих сторон), что есть достаточно формальным способом коммуникаций. Возможный комментарий, что такое невозможно или заказчик не подпишет, не согласиться. А вы делайте, пробуйте, убеждайте, если даже не пытаться, то ничего и не произойдет.

Tags: , , , ,

Comments are closed.