Гибкая разработка программного обеспечения: как вы реагируете * финансово * на изменение требований пользователей?

Есть одна вещь, которую я всегда удивлялся, когда читал обо всем этом "проворном развитии" здесь, на SE и других сайтах:

В «традиционной» разработке программного обеспечения вы

1. собирать требования пользователя,
2. написать спецификацию на основе этих требований,
3. отдайте его клиенту и выставьте ему счет за проделанную работу,
4. сделать (грубый) технический проект, чтобы вы могли оценить стоимость реализации,
5. дать пользователю ценовое предложение для реализации,
6. подождите, пока клиент подпишет спецификацию и примет предложение,
7. проектировать, внедрять, тестировать,
8. счет.

Если во время процесса требования меняются, вы отправляете предложение (с ценой) для желаемых изменений (или делаете это бесплатно, если изменение небольшое, вам нравится клиент, и клиент делает это не слишком часто) ,

Итак, как это работает (финансово) в гибком проекте, где частые изменения требований являются частью процесса?

• Вы пишете предложение для каждого изменения дизайна? (Разве это не было бы довольно беспорядок?)
• Или вы договариваетесь о фиксированной цене и надеетесь, что клиент не слишком часто меняет требования? (Может быть рискованно, я знаю клиентов, которые будут использовать эту возможность для запроса новых функций в течение многих лет, прежде чем признать, что проект завершен.)
• Или вы просто выставляете счет клиенту за общее время? (Может быть рискованно для клиента, который не знает стоимость заранее.)

В идеальном Agile-мире вы заранее соглашаетесь с ценой и количеством часов, но не сферой. Покупатель сам решает, какой минимально полезный продукт, а не тот, который ему действительно нужен, и это должно оцениваться намного меньше согласованного количества часов.

Затем вы предоставляете им итеративно, и они передумают все, что они хотят, но вы никогда не идете за количество согласованных часов. Теоретически и часто на практике они получают продукт, который им действительно нужен, а не продукт, который им действительно нужен.

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

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

Во-вторых, они должны быть вовлечены в течение всего процесса, иначе все проиграют. Многие клиенты не понимают, насколько они должны быть заняты, пока не стало слишком поздно.

Но если вы, как компания, объясните это достаточно хорошо, каждый победит.

Некоторые люди пытались с дать решение использовать ловкость в основных проектах цен в прошлом. Я лично думаю, что это вообще невозможно.

Scrum, в частности, подходит для компаний , занимающихся разработкой программного обеспечения , и в меньшей степени используется в сервисных компаниях.

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

Пожалуйста, не подавайте Agility à toutes les sauces . Мы должны использовать соответствующее решение данной проблемы.

Это не имеет никакого отношения к гибкому программированию или к какой-либо модели, которую вы используете. Работая в качестве фрилансера, я использую смесь Waterfall и V-модели, но у меня все та же проблема: что если клиент захочет что-то изменить во время детального проектирования? Что если он внесет изменения во время реализации?

Подход, который вы должны использовать, зависит от клиента и ваших отношений.

Если контакт является обязательным для всего, что вы делаете для этого клиента, потому что вы знаете, что он старается не платить, когда он может, или он будет пытаться подать в суд на вас, когда это возможно, тогда да, вы должны написать предложение для каждого крошечное изменение в требованиях. Это не беспорядок: если вы хорошо организованы, то, возможно, не составит труда приспособить новое требование во время разработки. Но наверняка это потеря времени и денег, и довольно странно подписывать предложение об изменении, которое займет у вас два часа.

Для других клиентов подход, который работает хорошо, заключается в следующем:

• При подписании первого предложения укажите ориентировочную стоимость и максимальную стоимость. Ориентировочная стоимость ничего не значит юридически: это просто оценка. Максимальная стоимость имеет юридическое значение: если вы скажете, что продукт будет стоить 3000 долларов вашему покупателю и, наконец, он будет стоить вам 3 157,24 долларов США, клиент все равно должен будет заплатить 3000 долларов. На практике в большинстве случаев реальная стоимость будет меньше заданного максимума и будет ближе к вашей оценке.

• Когда клиент просит изменить требование, оцените его стоимость и сравните его с фактической стоимостью и состоянием. Если вы почти закончили работу с продуктом, а его реальная стоимость составляет 2 108,36 долларов, а стоимость изменения оценивается в 150 долларов, просто сделайте это. Если, с другой стороны, существует риск достижения максимума, скажите вашему клиенту, что вам нужно пересмотреть общую стоимость вместе.

Agile и «Написать предложение» кажутся антитезой :) - последняя не является продуктивной разработкой программного обеспечения: D

Хорошо, теперь, когда у нас есть шутка с пути - вернемся к реальному.

"Как это работает в Agile ?" - договор все усложняет, но я надеюсь прояснить. Agile основан на принципе «доверия» и «совместной работы», что означает, что клиенту разрешено менять все, что угодно, когда он понимает, что это может стоить немного дороже или, если не навязчиво, возможно, без дополнительных затрат.

Что это значит? Это означает, что в контракте прописано, что мы (клиент) фиксируем первоначальную оценку стоимости и +/- отклонения%, с которым мы можем справиться, например, 100 тыс. Долл. США, но я готов подняться до 120 тыс. Долл. (Это МОЖЕТ не быть часть договора, но в голове у заказчика).

Теперь, когда приходит изменение в дизайне, вы идете вразрез с оценкой и планированием - вы собираете свою команду и спрашиваете у них «основную точку» для оценки сложности учета изменений. Вследствие некоторой оценки скорости вы можете умножить их и дать оценку графика. Если вы знаете команду и ее относительную зарплату, сравнительно легко вывести цену за сюжетную линию (пожалуйста, не усредняйте зарплату КАЖДОГО, вы уступите среднему недостатку).

Вам нужно вернуться к клиенту с финансовыми данными? NO. Не обязательно. У вас будет приоритет клиентов и вставьте их в нужное место в очереди. Теперь, когда вы знаете размер задела (вы должны это сделать, если вы этого еще не сделали) и, основываясь на финансовых результатах (стоимость за сюжетную линию), вы знаете, какие требования с низким приоритетом не могут быть выполнены с данным бюджетом. Покажите им перераспределенное отставание с оценкой выполнимых возможностей согласно контракту $$. Тогда пусть ИХ решит, готовы ли они платить больше, чтобы получить больше, если / когда вы / они доберетесь туда. Если они хотят это бесплатно ... вы встаете и СКАЖИТЕ им, что это будет стоить дороже.

Это должно помочь без того, чтобы вы постоянно возвращались к финансовым данным, если у вас есть этот график, чтобы клиент мог его увидеть.

Надеюсь это поможет!

Опыт других людей, вероятно, будет отличаться, но один из способов, которым я это видел, во многом совпадает с вашим «традиционным», с несколькими замечаниями:

1. Вложите некоторые накладные расходы на изменения (например, 10%)
2. Оценивать и отдельно выставлять счета за большие изменения или агрегировать и выставлять счета за изменения, превышающие встроенную стоимость (хорошим, хотя и не программирующим, примером является проектная работа, где часто первоначальная стоимость включает, скажем, 3 пересмотра, и последующие пересмотры или, возможно, общие повторы за дополнительную плату)

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

Затем клиент решает, что он хочет, чтобы рядом с вами были какие-то достопримечательности. Хорошо, это довольно большая часть (условно говоря), поэтому вы выставляете счет как новый «модуль» или заказ на покупку. Изменения в таких вещах, как цвет или дизайн этих контактов, включены в стоимость этого заказа. Направления и наложения - это еще один заказ на покупку, так как они не запрашивались до тех пор, пока не выполнялся другой заказ на покупку, и так далее, и так далее.