О числе Пи при составлении технического задания

Сегодня мне вновь хотелось бы вернуться к соотношению рационального и иррационального, но уже в контексте решения задач, которые приходится решать Git in Sky. Впрочем, я уверен, что подобные проблемы характерны для всех компаний, которым приходится выполнять нетиповые проекты.

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

Любая задача такого рода начинается с рационального действия — составления технического задания. Не открою секрета, что формирование ТЗ, хотя и не очень хорошо оплачиваемая операция, составляет основу проекта и занимает порой до половины времени, приходящегося на его реализацию. К счастью, в данном проекте представителем заказчика выступил технический директор, который смог на техническом языке объяснить, как он видит решение задачи.

А дальше вступил в силу факт иррационального, когда наши программисты долго не могли дать четкого ответа, сколько времени займет решение задачи. Мы слышали традиционный ответ: «Как пойдет!». В конце концов, был пройден и этот этап, в договоре указали определенное количество часов на реализацию проекта. И он пошел в работу.

Здесь необходимо сделать небольшое отступление. Существует такое негласное правило, когда озвученное программистами количество часов нужно умножать на число Пи (3,14). Дело здесь опять в иррациональности исполнителя. У него в голове складывается картинка идеального процесса, который редко осуществляется на практике. Всегда найдется какой-то пустячок, который потребует дополнительного времени на его устранение. И иногда значительного…

Однако в данном проекте правило числа Пи мы применять не стали. И напрасно. Когда код был написан, заказчик сказал, что все хорошо, но он хотел несколько иного решения, что естественно требует дополнительного времени.

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

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

В данной истории имелись и новые потребности заказчика, и непредвиденные решения программистов, так что мы вместе с нашим клиентом стали доводить проект до той степени, которая его полностью устроила. Фактически мы использовали методологию Agile (некоторые из принципов Agile: итеративные наглядные результаты, плотное сотрудничество с заказчиком). Однако agile методология не подразумевает изначального ТЗ и согласованных трудозатрат. Кстати, про agile методологию мы подробнее поговорим в следующем материале.

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

Стоило ли оно того? Я со своей командой считаю, что да.