Как Вы подписывали контракт к Гибкому проекту? (не, как Вы думаете, что были бы, как Вы сделали) [закрытый]

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

К тому времени, когда МОВ будет на самом деле, я уже потратил несколько часов на то, чтобы выяснить, каковы требования (они обрабатываются по стандартной почасовой ставке). Исходя из этого, в сочетании с оценкой моей скорости и сходства с предыдущими проектами, я даю общую оценку количества времени и затрат на требуемые функции, снова объясняя, что реальная стоимость определяется тем, какие функции мы фактически реализуем и сколько времени это действительно займет Это требует значительного доверия, но, поскольку мы работали вместе, чтобы разработать требования, которые я обычно предъявляю к людям, которым я Я имею дело непосредственно. Я часто пытаюсь оставить фактическую оценку вне MOU, но включу ее, если настаивает их менеджер. Я стараюсь дать им номер бюджета.

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

Я думаю, что ключевым вопросом является доверие. Я' Я предлагаю работать с новым заказчиком над небольшими проектами или явно разбивать большой проект на более мелкие проекты для развития доверия. Как только они и вы узнаете, что можете доверять друг другу в создании правильного продукта с нужными функциями, я думаю, что риск - и всегда есть один - внезапного отказа клиента от него сводится к минимуму.

Наши методы работы с PM все еще догоняют к гибкому подходу доставки программного обеспечения. Большую часть времени, ошибаясь на стороне осторожности, Первоначальный контракт определяет цели высокого уровня, но накладывает ограничения на функциональность с предсказуемыми техническими проблемами. Определены основные этапы поставки, такие как альфа, бета, финал и цены. Дополнительная область определяется как запросы на изменение, которые дополняют первоначальный контракт. Это опыт обучения, поскольку мы отошли от традиционных подходов к водопаду; Самая большая проблема, которую я видел, состоит в том, что некоторые вещи, такие как регулярные развертывания, трудно оценить, потому что вы никогда не знаете, сколько времени займет обращение к «обратной связи» от итерации. У нас было "это круто, мы хорошо продвигаемся!" и у нас был «вот список 200 дефектов»; есть разная степень понимания того, какова цель частых выпусков среди клиентов.

Определены основные этапы поставки, такие как альфа, бета, финал и цены. Дополнительная область определяется как запросы на изменение, которые дополняют первоначальный контракт. Это опыт обучения, поскольку мы отошли от традиционных подходов к водопаду; Самая большая проблема, которую я видел, состоит в том, что некоторые вещи, такие как регулярные развертывания, трудно оценить, потому что вы никогда не знаете, сколько времени займет обращение к «обратной связи» от итерации. У нас было "это круто, мы хорошо продвигаемся!" и у нас был «вот список 200 дефектов»; есть разная степень понимания того, какова цель частых выпусков среди клиентов.

Определены основные этапы поставки, такие как альфа, бета, финал и цены. Дополнительная область определяется как запросы на изменение, которые дополняют первоначальный контракт. Это опыт обучения, поскольку мы отошли от традиционных подходов к водопаду; Самая большая проблема, которую я видел, состоит в том, что некоторые вещи, такие как регулярные развертывания, трудно оценить, потому что вы никогда не знаете, сколько времени займет обращение к «обратной связи» от итерации. У нас было "это круто, мы хорошо продвигаемся!" и у нас был «вот список 200 дефектов»; есть разная степень понимания того, какова цель частых выпусков среди клиентов.

Дополнительный объем определяется как запросы на изменение, которые дополняют первоначальный договор. Это опыт обучения, поскольку мы отошли от традиционных подходов к водопаду; Самая большая проблема, которую я видел, состоит в том, что некоторые вещи, такие как регулярные развертывания, трудно оценить, потому что вы никогда не знаете, сколько времени займет обращение к «обратной связи» от итерации. У нас было "это круто, мы хорошо продвигаемся!" и у нас был «вот список 200 дефектов»; есть разная степень понимания того, какова цель частых выпусков среди клиентов.

Дополнительный объем определяется как запросы на изменение, которые дополняют первоначальный договор. Это опыт обучения, поскольку мы отошли от традиционных подходов к водопаду; Самая большая проблема, которую я видел, состоит в том, что некоторые вещи, такие как регулярные развертывания, трудно оценить, потому что вы никогда не знаете, сколько времени займет обращение к «обратной связи» от итерации. У нас было "это круто, мы хорошо продвигаемся!" и у нас был «вот список 200 дефектов»; есть разная степень понимания того, какова цель частых выпусков среди клиентов.

мы видели, что некоторые вещи, такие как регулярные развертывания, трудно оценить, потому что вы никогда не знаете, сколько времени займет обращение к «обратной связи» от итерации. У нас было "это круто, мы хорошо продвигаемся!" и у нас был «вот список 200 дефектов»; есть разная степень понимания того, какова цель частых выпусков среди клиентов.

мы видели, что некоторые вещи, такие как регулярные развертывания, трудно оценить, потому что вы никогда не знаете, сколько времени займет обращение к «обратной связи» от итерации. У нас было "это круто, мы хорошо продвигаемся!" и у нас был «вот список 200 дефектов»; есть разная степень понимания того, какова цель частых выпусков среди клиентов.

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

The only agile projects I have ever worked on were either In House, Time and Materials (T&M) or Pay per Cycle projects.

The trouble is, as you have pointed out, that there is a risk of a project failing/ending early. However, isn't that the same as any project? If you go T&M you take all the risk, if you go Fixed Price the customer takes all the risk. By going Pay Per Cycle you are taking most of the risk, but are passing small chunks of it onto the customer one cycle at a time. As it happens neither you or the client want to take any risk at all, which is why you have posted this question.

The trouble is taking risks is what business is all about, the more risk you take the bigger the profit when it comes off, but also the bigger the loss if it doesn't. If the risk is too great for you to handle the only solution is to find someone else that can take the risk off your hands, but you are going to have to pay them. If neither you nor the client are prepared to take it then there are probably only two answers:

1. Get some rich fool to underwrite the risk (i.e. get insurance).
2. Spread the risk out amongst a number of people until the risk each one takes is so small that it is acceptable.

I think this second option is what makes Contactors so popular. Because they are easy to get rid of, they end up taking the risk of an early project termination. As the risk would be spread between a number of them, the risk is spread to an acceptable level. They will charge you more than an Employee because of the extra risk, but that is what you get for trying to avoid the risk yourself.

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

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

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

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

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

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

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

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

То, как мы с этим справляемся, довольно продуктивно.

Наши клиенты в основном покупают итерации. Клиенты подписывают контракт с указанием «X двухнедельных итераций». Существует процесс обучения клиентов (как и все гибкие проекты, над которыми я работал), чтобы помочь клиенту быстрее освоить процесс планирования и понять, что то, что они на самом деле получают в конце процесса разработки, не является конкретным. начало проекта, НО то, что они контролируют конечный результат.

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