– За последний месяц он побеседовал с каждым из своих учеников. Своего рода передача последней крупицы мудрости.– И какой же последней крупицей мудрости он поделился с тобой? – спросил я. – Ну, то есть если это не секрет… или не что-то такое, слишком личное.Энея улыбнулась:– Напомнил, что заказчик непременно заплатит вдвое больше, если сообщать о дополнительных расходах постепенно и только после того, как будет заложен фундамент и конструкция начнет обретать форму. Он сказал, что тогда отступать уже некуда, и клиент не сорвется с крючка.Дэн Симмонс, Восход Эндимиона.
Правдоподобное отрицание (plausible deniability) – поведение, при котором лицо, совершившее действие или отдавшее распоряжение, сохраняет возможность в дальнейшем отрицать свою вовлечённость без большого риска быть уличённым во лжи.
Тут подумалось, что вся реализация гибкого процесса разработки, которую я встречал в жизни – об этом.
Например, приходит человек и говорит, что ему нужен проект, который будет делать то и это, и будет стоить шестьдесят тысяч долларов. А мы рассказываем ему, что мы работаем по гибкой методологии. Это когда мы придумываем список задач, так, что после выполнения их всех получится проект. Потом оцениваем, сколько времени займёт каждая из них. Потом выбираем задач на первую итерацию (допустим, неделю) и делаем. Заказчик проверяет нашу работу, оценивая результат выполнения каждой из задач. Если что-то недоделано / сделано не так, просит переделать. В итоге, как мы это называем, "принимает" задачу, говоря, что тем. что мы сделали в рамках этой задачи, он доволен. Потом выбираем задач на вторую итерацию. Смыть, повторить.
Самое главное – список задач на итерацию тоже составляет заказчик. И они не обязаны быть из изначального набора – заказчик может добавлять по ходу дела, может удалять старые, не пошедшие в ход задачи и так далее. Это даёт возможность корректировать направление движения в связи с вновь открытыми обстоятельствами – заказчик видит, что у него получается по ходу дела, и может поменять планы.
Как вы думаете, есть ли у клиента таким образом шанс получить то, что он хотел тогда, когда он хотел?
При этом, виноват клиент. Он вносил дополнительные правки. Он затягивал процесс сдачи каждой отдельной задачи, придираясь к мелочам. Он менял направление движения столько раз, что уже через месяц-два любые его претензии о несоответствии сроков (то есть, бюджета) изначально заявленным, абсолютно беспочвенны – мы делаем не тот проект, который обещали сделать за шестьдесят тысяч. А за всё, что мы сделали, он уже расписался, что мы сделали хорошо и правильно – приняв сделанные задачи. Клиент действительно не может выдвинуть никаких честных и справедливых претензий по поводу того, что мы обещали сделать его проект за указанный срок, срок прошёл, а проекта нет. Понимаете, это он виноват!
А для того, чтобы в срок получить то, что хочешь, по такой системе, нужно быть адски дисциплинированным заказчиком. Битым, опытным, с развитым самоконтролем и хладнокровным – то есть, таким, которые крайне редко оказываются создателями стартапов, с просьбами создать которые к нам, разработчикам и обращаются обычно.
Большая часть проектов заканчивается по исчерпанию бюджета заказчика. А точнее, по исчерпанию 3-10 изначально заявленных бюджетов, то есть, когда у заказчика действительно заканчиваются деньги. И виноват в этом заказчик.
Кент Бек – великий человек. Продал заказчикам мысль о том, что экстремальное программирование, из которого и выросла гибкая методология разработки – это что-то, что нужно и полезно именно им.
Компания всячески пытается улучшить ключевые показатели такого процесса ведения проектов, требуя этого от разработчиков и применяя материальное стимулирование. Ключевыми же являются показатели, которые улучшают нашу способность правдоподобно отрицать. Это закрытые истории – всемерное уменьшение количества незакрытых историй. Это постоянное уведомление заказчика о пересмотре оценок – мол, ты же понял, что после твоих изменений мы теперь будет это делать на два дня дольше? Это обязательные ежедневные отчёты – сегодня я делал то-то и то-то. И потом если что – ну он же получал ежедневные отчёты о работе и принимал выполненную работу и соглашался с оценками.
Как разработчик я всячески приветствую гибкую методологию в аутсорсе. Она позволяет продавать свою работу по максимуму и поддерживать стабильный денежный поток.
Дисклеймеры:
- Может показаться, что я говорю это так, как будто это что-то плохое. Это не совсем так. Я понимаю, что разработчику гораздо комфортнее при такой системе, и что я разработчик я тоже понимаю. Но чем-то от этого попахивает. Наверно тем, что сначала заказчику вообще оценивают проект целиком, а не говорят сразу, что он получит неизвестно что неизвестно когда.
Хорошее резюме из комментариев: "Фактически, используя аджайл и оценив матерость заказчика на этапе собеседования, можно сказать проект провалится или нет. Получается, что исполнитель заранее подписывается на проект, который в итоге окажется провальным и в этом несомненно будет виноват заказчик, потому что исполнитель матерый, а заказчик -- нет." - Нет, я не знаю, как лучше. Фиксированная цена звучит честнее, но там возникают проблемы с определением понятия "сделано".
- Да, я знаю, что при классическом "водопаде" тоже проваливаются проекты. Но там я могу увидеть шанс, что проект состоится, если команда сделает всё правильно. А здесь посредством дисперсии ответственности любая команда не может обеспечить успешную сдачу проекта в срок – только дисциплина заказчика может дать шанс на это. С другой стороны в провале "водопадного" проекта всегда виновата команда, а в провале "гибкого" – заказчик.
Ссылки:
