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