Как вы подписали контракт на Agile-проект? (не так, как вы думаете, что бы вы сделали, как вы это сделали)

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

Единственными гибкими проектами, над которыми я когда-либо работал, были проекты In House, Time and Materials (T & M) или Pay per Cycle.

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

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

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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