T>извините, но написанное выше не имеет ничего общего с реальным миром.
Как раз наоборот. В реальном мире происходит именно так. А мечта об идеальном заказчике, который четко знает чего хочет и никогда не делает change requests — неосуществимая иддилия, которая загубила много проектов.
T>Представьте, что вас заказчик попросил построить дом на два этажа с гаражом за $100k. ТЗ вам не нужно (цитата: бумажка для прикрытия задницы в случае провала проекта). Вы построили 80% дома, как вы считаете классно, но тут вы от заказчика узнаете, что он передумал и решил строить не 2-х этажный дом, а 10-ти этажный со скоростным лифтом, подземным гаражом на 100 машин, бассейном во дворе и оранжереей на крыше. При этом он хочет "получить решение в ожидаемые сроки и уложиться в бюджет".
Не надо приводить аналогию со строительством. Переделать дом очень сложно, даже поменять проводку в стене — уже трудность. Аналогичные изменения в программе — это норма жизни, при регулярном рефакторинге и наличии юнит-тестов совершенно не представляют проблемы.
У заказчика есть бизнес-задача, которая не меняется. Программа — это реализация модели бизнес-задачи. Эта модель будет уточняться и развиваться, поэтому требования к программе тоже будут изменяться. Но это всегда разумно. Никто не требует начав писать калькулятор резко переключиться на разработку интернет-браузера.
Заказчик, объясняя чего ему хочется и работая с прототипом программы, сам начинает лучше понимать свою бизнес-задачу и ее внутренние процессы. Какие-то функции, казавшиеся второстепенными, выходят на первый план. У других функций замечается неверная реализация. Поэтому изменения вносятся очень часто. Чем лучше организовано общение с заказчиком, тем больше таких изменений, тем они чаще, и тем проще их реализовывать. При это программа не ломается, а вырастает от простого к сложному.
T>Любые изменения в ТЗ обычно оформляются как enhancements (feature request) и выносятся за scope текущей фазы проекта, иногда можно пойти на то, чтобы включить изменения в текущую фазу, но это очень не желательно, так как влечет изменения в сроках и бюджете текущей фазы.
Это здорово, если фаза длится одну-две недели. Но таких фаз не бывает в проектах с детально расписанными планами, утвержденными сроками и ТЗ. И на практике получается, что туча времени уходит на проектирование, разработку и тестирование _не_того_. Проект к этому моменту уже слишком закостенел, ведь рефакторингом никто не занимался. Когда заказчик обоснованно просит вернуть программу в колею его бизнес-задачи, на него обижаются и приделывают изменения в виде заплаток.
T> Надо понимать, что если заказчик заинтересован в проекте, то он (или его представитель) должен участвовать в проекте, особенно это критично на этапе составления технических требований.
Заказчик должен участвовать в разработке с первого дня, он должен постоянно пользоваться текущей версией программы, стараясь применять ее для решения реальных задач. В каждый момент он должен знать какие функции имеют высший приоритет — их нужно реализовать в ближайшую итерацию, а какие можно пока отложить — а со временем они вообще отвалятся как ненужные.
T>
T>Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
T>....
T>отказаться от выполнения работ, не указанных в ТЗ
abibok пишет: > T>Представьте, что вас заказчик попросил построить дом на два этажа с > гаражом за $100k. ТЗ вам не нужно (цитата: бумажка для прикрытия задницы > в случае провала проекта). Вы построили 80% дома, как вы считаете > классно, но тут вы от заказчика узнаете, что он передумал и решил > строить не 2-х этажный дом, а 10-ти этажный со скоростным лифтом, > подземным гаражом на 100 машин, бассейном во дворе и оранжереей на > крыше. При этом он хочет "получить решение в ожидаемые сроки и уложиться > в бюджет". > > Не надо приводить аналогию со строительством. Переделать дом очень > сложно, даже поменять проводку в стене — уже трудность.
Господа, я понимаю что у нас это дикость, но в других странах это в
порядке вещей. Речь идет, конечно, не о таких глобальных перестройках,
но изменение проекта в процессе строительства (например коренное
изменение функционала, как-то переделать офисное здание в торговый
центр) достаточно распространенная практика.
Нужно просто софт писать (дома строить) так, чтобы такие изменения не
были проблемой.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Правила форума нарушены.
— оверквотинг
Правила можно найти в разделе FAQ данного форума и\или ресурса.
Нарушение правил может повлечь за собой санкции, описанные там же — модератор
A>Что из этого вы ему обеспечили? Вместо этого написана мудро спроектированная, изящно реализованная и великолепно выглядящая программа, которая не нужна заказчику, потому что отлично решает какую-то другую задачу. И это целиком ваша вина.
Все это конечно хорошо, но только не на условиях fixed price. Ради бога, пусть меняет условия, задачи, но заказчик должен четко понимать, что любые отклонения от первоначального плана стоят времени, и, соответственно, денег. Так что браться за проект с нечеткими требованиями на условиях фиксированной цены — самоубийственно. Только почасовая оплата. А тогда пусть фантазия играет как хочет. Любой каприз за ваши деньги.
Здравствуйте, abibok, Вы писали:
T>>извините, но написанное выше не имеет ничего общего с реальным миром.
A>Как раз наоборот. В реальном мире происходит именно так. А мечта об идеальном заказчике, который четко знает чего хочет и никогда не делает change requests — неосуществимая иддилия, которая загубила много проектов.
Я в свою очередь могу сказать, что постоянные изменения в ТЗ без пересмотра цены загубили еще больше проектов, поскольку разработчик не будет работать себе в убыток. Почему он должен оценивать трудоемкость и стоимость работ для одних требований к продукту, а потом когда объем работ меняется он не может изменить оценку? Про идеального заказчика, итеративный процесс разработки с короткими фазами (1 мес) и контроль результата, как раз позволяет избежать проблем обоим сторонам — клиент видит, что получается, и может скорректировать направление разработки, если у него появились новые идеи или он так или иначе решил изменить свои требования, разработчик со своей стороны не оказывается в ситуации, когда после полугода разработки, оказывается, что клиент хотел вовсе не то, что получилось. Опять же повторюсь: на заказчика накладывается большая ответственность по контролю хода разработки, если он все это время лежал на пляже на Мальдивах вместо того, чтобы смотреть progress reports, то получит он в итоге такое видение реализации как себе ее представлял разработчик.
T>>Представьте, что вас заказчик попросил построить дом на два этажа с гаражом за $100k. ТЗ вам не нужно (цитата: бумажка для прикрытия задницы в случае провала проекта). Вы построили 80% дома, как вы считаете классно, но тут вы от заказчика узнаете, что он передумал и решил строить не 2-х этажный дом, а 10-ти этажный со скоростным лифтом, подземным гаражом на 100 машин, бассейном во дворе и оранжереей на крыше. При этом он хочет "получить решение в ожидаемые сроки и уложиться в бюджет".
A>Не надо приводить аналогию со строительством. Переделать дом очень сложно, даже поменять проводку в стене — уже трудность. Аналогичные изменения в программе — это норма жизни, при регулярном рефакторинге и наличии юнит-тестов совершенно не представляют проблемы.
Нормальная аналогия, изменения в требованиях могут привести к полной переделке программы, начиная с полной переработки архитектуры. Рефакторинг тут не спасает, так как начинает отнимать больше времени чем добавление функциональности. Рефакторинг нужен лишь для повышения качества кода и простоты внесения измений, расширений, но изменения тут совсем другого порядка.
A>У заказчика есть бизнес-задача, которая не меняется. Программа — это реализация модели бизнес-задачи. Эта модель будет уточняться и развиваться, поэтому требования к программе тоже будут изменяться. Но это всегда разумно. Никто не требует начав писать калькулятор резко переключиться на разработку интернет-браузера.
Это разумно, но не разумно делать это за фиксированную стоимость, каждое изменение в программе, если это не bugfix (обычно включается в оценку), должно быть оплачено. Это приучает заказчика думать наперед, прежде чем вносить какие изменения, т.е. более ответственно подходить к выработке требований к продукту, а не придумывать все новые и новые фишки каждую неделю. Если продолжать вашу аналогию про калькулятор, заказчик должен отдавать себе отчет в том, что калькулятор и маткад вещи несколько разного порядка и не могут быть сделаны за одну стоимость, и если он все же хочет маткад, до в его интересах сразу об этом в своих требованиях указать, а не пытаться съэкономить в надежде, что исполнитель все потом доделает.
A>Заказчик, объясняя чего ему хочется и работая с прототипом программы, сам начинает лучше понимать свою бизнес-задачу и ее внутренние процессы. Какие-то функции, казавшиеся второстепенными, выходят на первый план. У других функций замечается неверная реализация. Поэтому изменения вносятся очень часто. Чем лучше организовано общение с заказчиком, тем больше таких изменений, тем они чаще, и тем проще их реализовывать. При это программа не ломается, а вырастает от простого к сложному.
Это должно оплачиваться, т.к. исполнитель, когда он подготавливает оценку, не может предусмотреть все изменения, которые придут в голову клиенту в связи с тем что он наконец начал "лучше понимать свою бизнес-задачу" (откуда это исполнитель об этом-то тогда узнает). В противном случае, исполнителю придется закладывать оценку с существенным запасом (скажем в 10 раз), на случай если все же понадобится не калькулятор, а редактор с формулами.
T>>Любые изменения в ТЗ обычно оформляются как enhancements (feature request) и выносятся за scope текущей фазы проекта, иногда можно пойти на то, чтобы включить изменения в текущую фазу, но это очень не желательно, так как влечет изменения в сроках и бюджете текущей фазы.
A>Это здорово, если фаза длится одну-две недели. Но таких фаз не бывает в проектах с детально расписанными планами, утвержденными сроками и ТЗ. И на практике получается, что туча времени уходит на проектирование, разработку и тестирование _не_того_. Проект к этому моменту уже слишком закостенел, ведь рефакторингом никто не занимался. Когда заказчик обоснованно просит вернуть программу в колею его бизнес-задачи, на него обижаются и приделывают изменения в виде заплаток.
У меня фаза в проекте длится 1-1.5 месяца, конечно, кроме функциональности, которую надо сделать дальше и которая была вынесена на 2 и 3 фазы, чтобы сократить длительность каждой фазы, есть пожелания и изменения. Все их я переношу на последующие фазы, зато я гарантирую, что первую фазу я сделаю в указанный срок и в рамках выделенного бюджета. За это время, одни пожелания заменятся другими и я уже буду приблизительно знать трудоемкость на новый этап работ, это нормально и не влияет на текущий процесс разработки.
T>> Надо понимать, что если заказчик заинтересован в проекте, то он (или его представитель) должен участвовать в проекте, особенно это критично на этапе составления технических требований.
A>Заказчик должен участвовать в разработке с первого дня, он должен постоянно пользоваться текущей версией программы, стараясь применять ее для решения реальных задач. В каждый момент он должен знать какие функции имеют высший приоритет — их нужно реализовать в ближайшую итерацию, а какие можно пока отложить — а со временем они вообще отвалятся как ненужные.
Вот-вот, с одной стороны исполнитель должен понимать, что требования меняются, со своей стороны заказчик должен отдавать себе отчет, что изменения в требованиях всегда влекут изменения в стоимости и сроках. Когда такое понимание присутствует у обоих сторон, это очень хорошо.
T>>
T>>Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:
T>>....
T>>отказаться от выполнения работ, не указанных в ТЗ
T>>http://ru.wikipedia.org/wiki/Техническое_задание
A>Позволяет защититься когда заказчик недоволен сделанным. Позволяет избежать штрафов, но проваленный проект не спасает и заказчик уже не вернется.
A>Мне понравилась аналогия с арендой трактора. Именно так и стоит строить отношения с заказчиком. Не fixed price, а subscription.
Я никогда не выставляю fixed price на проект, если он больше недели-двух. Т.е. скорее у меня разновидность subscription сервиса, с часовым рейтом, но мне не удобно и заказчику полагаю тоже, каждую неделю получать счета на несколько часов, поэтому я готовлю оценку на некоторую законченную функциональность, документацию и пр. сразу на месяц. Все что сверх, выносится в отдельную фазу или оплачивается отдельно, если есть возможность без подвижки сроков сделать некоторую работу.
Здравствуйте, Trean, Вы писали:
T>Представьте, что вас заказчик попросил построить дом на два этажа с гаражом за $100k. ТЗ вам не нужно (цитата: бумажка для прикрытия задницы в случае провала проекта). Вы построили 80% дома, как вы считаете классно, но тут вы от заказчика узнаете, что он передумал и решил строить не 2-х этажный дом, а 10-ти этажный со скоростным лифтом, подземным гаражом на 100 машин, бассейном во дворе и оранжереей на крыше. При этом он хочет "получить решение в ожидаемые сроки и уложиться в бюджет".
У меня сестра как-то рассказывала, что проектировали они многоэтажную парковку с гаражами. Потом заказчик передумал и пришлось добавлять еще один этаж за счет снижения высоты потолков. Если ты думаешь, что подобное изменение ТЗ было проще, чем некислый рефакторинг софта, то ты сильно заблуждаешься.
Так что проблемы в строительстве схожи, только аналогии у тебя неверные. Разработка программы — это этап проектирования здания в строительстве. А этап строительства — это сборка программы кнопочкой Build. После такой корректировки все становится на свои места и проблемы с заказчиком, ТЗ, сроками и т.п. получаются общими.
давно уже известно что правильная аналогия софтостроению-...
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
