Как вы подписали контракт с Agile-проектом? (не так, как ты думаешь, как бы ты поступил) [закрыто]

для выполнения гибкого проекта вам сначала нужен контракт. Нет контракта – нет проекта! Нет проекта-нет Agile, SCRUM или что-то еще!

контракт, если мы говорим о средних и больших проектах, должен иметь четко определенные триггеры безопасности. Т. е. клиенты хотят быть очень уверены, что если мы договоримся о завершении проекта во времени = T, бюджете = B и объеме = S, Мы не получим время = T×2, бюджет = B×3 или объем = S/2.

с другой стороны, мы, как компания, которая поставляет продукт, не хочу, чтобы проект закончился неожиданно. Т. е. если после некоторой итерации клиент говорит: "Теперь я вижу, что это все, что нам нужно. Мы останавливаемся."и проект планировался еще на 2 МЕСЯЦА, чем у нас люди без запланированной работы. Если 3-6 человек не является большой проблемой, 15-25 может быть реальной проблемой!

но я не нашел никакого реального примера контракта с функциями безопасности в нем, который позволил бы проекту быть выполненным в полной гибкой манере (заявлено или нет заявленный клиенту как таковой). Стандартная говоря, я нахожу на многих форумах – поговорите с заказчиком, объясните ему, что это гораздо более продуктивный способ работы и т. д. не убеждает ни меня, ни мое руководство. Не то чтобы мы не верили в то, что Agile-лучший способ сделать это. Просто пробелы в триггерах безопасности настолько очевидны, что никто из наших клиентов не покупает его, и нам они не нравятся (пробелы, а не клиенты;)).

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

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

7 ответов


Я работаю в правительстве.

недавно мы запустили процесс закупок разработки программного обеспечения и выбрали трех поставщиков для работы над гибким проектом. Некоторые примечания:

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

  2. одной из гарантий, которую мы использовали, было заключить контракт с очень опытным (независимым) мастером SCRUM, чтобы работать на нас и обрабатывать обязанности по управлению проектами программного обеспечения от имени нашего руководителя команды / архитектора / парня юзабилити. Мы потратили много времени, чтобы найти этого человека, и выбрали их из трех великих претендентов. Это было дорого, но стоит он.

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

  4. затем мы прыгнули с технической сессии планирования / калибровки и получили, что стороне дела. За это время не было сделано никакой работы или дизайна, но мы сделали много калибровки и оценки высокого уровня.

  5. к концу месяца мы собрали контракты для каждого поставщика (один опоздал, но это было нормально). Один поставщик предложил образцы контрактов, которые мы могли бы использовать, один на основе оплаты третей проекта; другой по завершении спринтов. Я думаю, что в конце концов мы сделали завершение спринты (ежемесячно), используя некоторые из поставщиков предложил язык в разделе Платежи нашего стандартного шаблона контракта.

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

в конце концов, это был очень успешный проект, и с тех пор мы начали использовать SCRUM in-house для других проекты. Я думаю, что наличие отличной команды было ключевым. Мы были уверены в продавцах - не только в том, что они могут выполнять работу, но и в том, что они хорошо подходят с точки зрения их отношения к работе в одной команде и с точки зрения четко определенных ролей для каждого (т. е. они не будут конкурировать за одни и те же деньги).

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

с тех пор мы свернули все три контракта на второй год разработки, хотя я бы сказал, что на этот раз все идет не так гладко (новый SCRUM master, другой состав команды), это все еще отличный проект для участия.

вы можете также интересно: Аутсорсинг Agile.


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

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

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

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


единственные гибкие проекты, над которыми я когда-либо работал, были либо в доме, времени и материалах (T&M), либо в проектах с оплатой за цикл.

проблема в том, как вы указали, что существует риск провала/преждевременного завершения проекта. Однако разве это не то же самое, что любой проект? Если вы идете T&M, вы берете на себя весь риск, если вы идете фиксированная цена клиент берет на себя весь риск. Идя платить за цикл, вы берете на себя большую часть риска, но передаете небольшие куски его на клиента цикл за раз. Как это происходит, ни вы, ни клиент не хотите рисковать вообще, поэтому вы разместили этот вопрос.

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

  1. получить какой-то богатый дурак, чтобы переписать риск (т. е. получить страховку).
  2. распределите риск среди нескольких людей до тех пор, пока риск, который каждый из них принимает настолько мал, что это приемлемо.

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


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

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

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

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

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

то, как мы выполнили отношения сначала отправить бизнес-партнера в agile boot camp. Затем мы обучили бизнес-партнера быть product owner'ом. Затем мы построили отставание, предоставили оценку высокого уровня и зафиксировали размер команды и время упаковало развитие. В течение двух недель было демонтировано первое рабочее программное обеспечение. С этого момента бизнес-партнер был и понимал ценность внесения изменений по мере того, как они узнавали больше. Вскоре все разговоры о контракте с фиксированной сферой применения были забыты.


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

наши клиенты в основном покупают итерации. Клиенты подписывают контракт с надписью "X 2-недельные итерации". Существует процесс обучения клиентов (как и все agile-проекты, над которыми я работал), чтобы помочь клиенту ускорить процесс планирования и идею о том, что то, что они фактически получают в конце процесса разработки, не является конкретным в начале проекта, но что они контролируют, что окончательное исход будет.

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


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


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