Ноя 15
10
Серия постов с конкретными ситуациями. Цель — обратить внимание на особенности взаимодействия — избежать, быть готовым к подобному. предыдущие Эпизоды см на www.it-tuning.com или www.facebook.com/it.tuning.
Было такое, когда заказчик говорит «а зачем нам тестирование? Разве ваши разработчики не могут качественно работать?», и не хочет оплачивать тестирование, или совсем, или оплачивает в гораздо меньшем объеме чем требуется. Кстати, типичное соотношение разработчиков к тестировщикам в типичном проекта разработки ПО порядка 1-го тестировщика на 3-4 разработчиков, +/-. Или же, когда вы говорите, что собираетесь делать такие инженерные практики как код ревью, или ревью документации, или писать документацию, то тоже можете получить нежелание заказчика их внедрять и оплачивать. При этом заказчик может аргументировать свое нежелание как угодно. Действительно ли он не понимает ценность определенных практик? Возможно. Но также возможно, что у него ограничен бюджет. Будет ли такой заказчик открыто говорить об этом исполнителю? Вряд ли, т.к. не хочет показаться неплатежеспособным. Он просто хочет больше «напедалить» за меньшие деньги. Суть именно в этом. Хотя, есть заказчики, которые могут прямо сказать — «бюджет ограничен, поэтому не могу позволить применять все инженерные практики».
Какой вывод, и что можно порекомендовать.
- Если заказчик хочет сэкономить (говоря об этом открыто или завуалировано) это нормально! Имеет полное право. Важно договориться, что делаем, а что не делаем.
- Попытаться выяснить бюджетные ограничения и ожидаемое заказчиком количество результата на выходе. Это может оказаться не так сложно как кажется, если не получается напрямую узнать бюджет, то можно опосредованно, исходя из заказываемого объема работ.
- Нужно обязательно выяснить приоритеты заказчика по срокам, бюджету, объему работ и т.п. Например, разрабатываемое приложение может быть важно сдать к учебному сезону, к рождеству, к выставке и т.п. Если вы это знаете, то намного проще договариваться о приоритетах. Есть пример из жизни, когда заказчик говорил: «я знаю, что в команде в два раза меньше тестировщиков чем нужно, больше финансово не могу позволить, но у меня начало сезона 1 сентября, мне нужно педалить, меня вполне устроит наличие некритичных bug-ов, претензий по ним иметь не буду».
- Можно и нужно попытаться объяснить заказчику ценность тех или иных практик. НО! Понятным ему языком, а именно перевести ценность практик в сэкономленное время, деньги и другие понятные заказчику ценности.
- И самая главная рекомендация — ФОРМАЛЬНО закрепить, желательно подписать соглашение о том, какие инженерные и управленческие практики применяются, а какие нет. И что будет если нет? И что будет, если не смотря на договоренности заказчик настаивает «выбросить» ту или иную практику? Формулировка может звучать так: «практика код ревью не применяется, стороны осознают возможные последствия по отношению к качеству кода и качеству алгоритмических решений, но потенциальные проблемы, возникшие по этой причине не могут являться источником претензий Заказчика к Исполнителю. В случае необходимости исправления таких проблем они рассматриваются как запросы на Изменения».
Где такие договоренности фиксировать? В Договоре, в приложении к Договору, в Уставе Проекта. Или хотя бы в емейл (с копиями на руководство с обеих сторон), что есть достаточно формальным способом коммуникаций. Возможный комментарий, что такое невозможно или заказчик не подпишет, не согласиться. А вы делайте, пробуйте, убеждайте, если даже не пытаться, то ничего и не произойдет.
