Agile договор: Agile договор на разработку ПО (метод SCRUM) — ARBITRAGE

Agile договор на разработку ПО (метод SCRUM) — ARBITRAGE

5.1. Стороны, основываясь на общих требованиях Заказчика к ПО, указанных в Приложении №1, в дату ▒▒.▒▒.▒▒▒▒ и время ▒▒:▒▒, проводят встречу – первое планирование, по адресу Подрядчика – г. Москва, ул. ▒▒▒▒▒▒▒▒▒▒▒▒▒▒, д. ▒▒▒/▒▒, оф. ▒▒, с целью первого согласования (планирования) списка Product backlog и списка Sprint backlog на первый этап работ Sprint (формат Sprint backlog и Product backlog определен в Приложении №4).

5.2. В случае, если Стороны, в результате первого планирования, не пришли к взаимному, и достаточному для Подрядчика, соглашению, проводится повторная встреча в срок не позже, чем через 3 (три) рабочих дня с момента проведения первого планирования. Если за время проведения двух встреч первого планирования Стороны не пришли к соглашению о формулировании требований User story и согласованном их внесении в списки Product backlog и Sprint backlog, настоящей договор прекращает свое действие без каких-либо взаимных претензий, штрафов и иных требований Сторон.

5.3. Любое дальнейшее согласование внесения изменений и/или дополнений в Product backlog выполняется Сторонами совместно и непрерывно, на условиях и в течение всего срока действия настоящего договора, на основании инициатив любой из Сторон. В любой момент времени действия договора, Стороны, внося изменения и/или дополнения в Product backlog, стремятся согласовать все элементы изменяемого или добавляемого User story.

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

• 5.4.1. Обзор этапа Sprint проводится Сторонами совместно, в целях демонстрации и приемки результатов выполненных Подрядчиков работ в течение этапа Sprint, в срок не более 2 рабочих дней с момента истечения срока Sprint. В случае выполнения Подрядчиком согласованных Сторонами условий приемки какого-либо отдельного объема работ (User story), указанного в утвержденном к выполнению Sprint backlog, такие работы принимаются на условиях настоящего договора Заказчиком. По результатам проведения Обзора этапа Sprint и приемки работ, Стороны заполняют и совместно подписывают Перечень выполненных на этапе Sprint и принятых Заказчиком работ (форма определена в Приложении №5 к договору). В срок не более 5 рабочих дней с момента подписания Сторонами, Подрядчик направляет Заказчику акт выполненных работ, согласно подписанному Сторонами Перечню выполненных на этапе Sprint и принятых работ. Указанный акт считается Сторонами подписанным и принятым Заказчиком, в случае отсутствия мотивированных возражений в срок не более ▒▒ рабочих дней с момента отправки скан-копии акта Подрядчиком.

• 5.4.2. Ретроспектива этапа Sprint проводится Сторонами совместно, в целях обсуждения улучшений и недостатков совместной работы в срок не более 2 рабочих дней с момента проведения Сторонами Обзора этапа Sprint.

5.5. Стороны, каждый раз, по итогам проведения встреч Обзор этапа Sprint и Ретроспектива этапа Sprint, в срок не более 2 рабочих дней с момента проведения Сторонами встречи Ретроспективы этапа Sprint, проводят планирование нового этапа Sprint – согласование (планирование) Sprint backlog.

5.6. Согласование Сторонами списка Sprint backlog, при проведении планирования этапа Sprint, считается завершенным, если по всем User Story в списке Sprint backlog Сторонами согласованы: название, важность (приоритет выполнения работ), предварительная оценка объема и сложности работ выполняемых работ, способ демонстрации, способ проверки и приемки результатов каждой из согласованных работ. Согласование Сторонами списка Sprint backlog, подтверждается путем подписания дополнительного соглашения, (по форме указанной в приложении №4) и применяется Сторонами, как к первому, так и ко всем последующим согласованиям списков Sprint backlog.

5.7. При каждом проведении согласования списка Sprint backlog (при планировании этапа работ Sprint), Стороны определяют и согласовывают количество реализуемых Подрядчиком требований к ПО — User story, руководствуясь показателем Story point по каждому User story. Показатель трудозатрат и сложности Story point для каждого User story определяется Подрядчиком и согласовывается Сторонами. Если Заказчик не согласен с оценкой трудозатрат Story point для каждого User story, определенных Подрядчиком, он вправе разбить User story на отдельные задачи с меньшей оценкой трудозатрат по каждой и изменить приоритетность User story в Product backlog, и, в конечном итоге, включить измененные User Story в список Sprint backlog. В любом случае, показатель трудозатрат Подрядчика приоритетен, и, в случае его оспаривания Заказчиком, Подрядчик не приступает к работе до его согласования.

5.8. Для первого этапа Sprint, Стороны, с учетом количества и квалификации задействованного персонала Подрядчика, и предварительной оценки Подрядчиком списка общих требований к ПО, установили суммарное (всех User story, которые включены в Sprint backlog) максимальное значение показателя Story point для всего первого Sprint backlog, равное ▒▒, исходя из которого Заказчик подбирает и приоритизирует User story.

5.9. Для каждого последующего этапа, Подрядчик вправе в одностороннем порядке корректировать суммарное максимальное значение показателя Story point для соответствующего Sprint backlog в меньшую сторону не более чем на ▒▒%, в случае если иное не согласовано Сторонами, для каждого отдельного случая.

5.10. По итогам планирования очередного Sprint, и только в случае согласования сторонами списка Sprint backlog, Подрядчик приступает к выполнению работ, на следующий рабочий день, если иное не согласовано Сторонами.

Применение Agile в рамках договора с фиксированными фазами / Хабр

Вы руководитель нового проекта заказной разработки. Вам принесли договор, неизвестно кем и как заключенный, дали контакты заказчика и дальше вы предоставлены сами себе. Изучив функциональный объем проекта, вы понимаете, что в данном случае было бы правильно применить Agile. Но в договоре уже прописаны четкие фазы в соответствии с каскадной моделью разработки (waterfall) со сроками, результатами и фиксированной ценой по каждому этапу. Что делать в этой ситуации?

1. Подготовка проекта

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

2. Этап концептуального проектирования

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

Рис. 3 Закрытие этапа Проектирования

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

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

3. Этап реализации

Настоящая засада ждет вас дальше, когда подойдет срок сдачи этапа реализации.

Рис.4 Закрытие этапа Реализации

К этому моменту, половина функционала уже работает в продуктиве, вторая половина толком не начинала обследоваться, а вы приносите заказчику акт, с просьбой закрыть вам этап реализации. Тут у него в голове обычно что-то щелкает: «как это я закрою им всю разработку, если я пока получил только половину?!». К такому повороту надо подготовиться заранее и встретить его во всеоружии:

• Надо заранее объяснять заказчику, почему вы придерживаетесь методологии Agile. Рассказывать про бесперебойную поставку ценного ПО, снижение рисков и все такое прочее.
• Можно нарисовать схему, похожую на рис. 4 и наглядно показать, что половина работ выполнена, поэтому вы хотите получить половину денег.
• Очень хорошо, если у вас будут критичные дефекты по функционалу находящемуся в продуктивной эксплуатации. Вы говорите: «Как же так, вы хотите, чтобы мы вам устраняли дефекты, то есть выполняли работы по этапу 4, а вы нам еще за этап 2 не заплатили?». Если внедряемая система действительно полезна заказчику – это хороший рычаг воздействия.
• Чтобы заказчику было психологически проще подписать вам акт, можно попробовать для оставшегося функционала реализовать в системе заглушки: неработающие пункты меню, интерфейсы без реализации и т. п. При этом объяснять, что все это будет реализовано на этапе внедрения, по уже привычной ему итеративной схеме.
• Можно заявить, что заказчик сам виноват в сложившейся ситуации, потому что не мог сразу сформулировать все требования. А вы пошли ему на встречу и позволили формулировать требования постепенно на протяжении всего проекта.
• Постоянно напоминайте, что это только вторая фаза и до конца проекта еще далеко.
• Ну и применяйте все остальные стандартные средства из арсенала проджект-менеджера: просьбы, манипуляции, изматывание, угрозы, шантаж. На этом этапе все средства хороши.

4. Этап внедрения

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

Рис.5 Закрытие этапа внедрения

5. начальное сопровождение промышленной эксплуатации

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

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

Какими должны быть контракты в Agile — статья в блоге ScrumTrek

Scaled Agile Framework, SAFe — фреймворк Agile-разработки, разработанный Scaled Agile Inc., который является базой знаний по реализации бережливой Agile-разработки в корпоративных масштабах. Ниже вольный пересказ оригинальной статьи «Agile Contracts — Scaled Agile Framework».

…выберите перспективного поставщика и ждите, что он поставит продукт в соответствии с требованиями, согласованными сроками и бюджетом. Однако, этот традиционный подход почти всегда ведет к провалам, за каждым из которых — весьма эффектное прожигание денег налогоплательщиков.
— Jason Bloomberg, Forbes, Fixing Scheduling with Agile at the VA

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

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

Попытка управлять рисками за счёт подробного описания требований на раннем этапе имела обратный эффект и приводила к потерям у ключевых участников проекта.

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

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

Традиционные подходы к контрактам по разработке и внедрению новых систем

Крупные компании используют несколько подходов в работе со сторонними вендорами, у которых они заказывают сложное программное обеспечение. Обычно эти подходы варьируются между «жестко фиксированным бюджетом» (Fixed Price) и «оплатой по факту» (Time & Material), а также вариациями, находящимися между этими крайностями. Рисунок ниже описывает эти подходы, а также критерии, по которым риски в них делятся между сторонами.

Подходы в работе со сторонними вендорами

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

Контракты с жёстко фиксированным бюджетом

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

Контракты с жёстко фиксированным бюджетом создают «железный треугольник»

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

Однако этот подход имеет также и обратные стороны:

• Он предполагает, что потребности клиента хорошо известны задолго до внедрения решения.
• Эти потребности должны быть отражены в спецификации требований и проекте решения, что приводит к необходимости детального проектирования до начала разработки (BUFD, Big Design Up Front), каскадной модели разработки и соответствующей контрактной модели.
• Контракт обычно подписывается с поставщиком, обещающим наименьшую стоимость. Это может принести, а может и не принести покупателю максимальную экономическую выгоду в долгосрочной перспективе.

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

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

Но хуже всего то, что в момент подписания такого контракта экономические интересы сторон становятся противоположными:

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

В результате такой тип контракта часто устанавливает между клиентом и поставщиком отношения «победитель-проигравший», что влияет на дальнейшие взаимоотношения сторон и в конечном счете наносит вред каждой из них.

Контракты с оплатой по факту

Понятно, почему многие в индустрии хотят двигаться в правую сторону спектра. Но правая граница, представляющая «оплату по факту», которая с первого взгляда может показаться исключительно гибкой и соответствующей методологии Agile, тоже таит в себе сложности. Клиент в данном случае может рассчитывать только на своё собственное доверие. Доверие, безусловно, очень ценно, и мы опираемся на него в методологии бережливой разработки (Lean), но в моменты недопонимания между сторонами, изменений на рынке или технических условий, а также экономических моделей у клиента или поставщика доверие могут отодвинуть на задний план.

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

Сложности могут возникнуть и на стороне заказчика. Например, в ходе разбора полетов по результатам провального проекта Стивен В. Уоррен (Stephen W. Warren), ответственный исполнитель и директор по ИТ в департаменте по делам ветеранов США, отметил, что, по словам руководителя проекта, проект никогда не был в кризисе, так как каждый год они полностью расходовали свой бюджет, что позволяло им сохранять финансирование на следующий год. Критерием успешности для них было то, будут ли они продолжать получать финансирование, а не то, будут ли они способны поставить требуемый функционал.

Совместный подход к Agile-контрактам

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

То, что действительно нужно — это подход, который «доверяет, но проверяет», что разработчики системы делают действительно правильные вещи правильным способом, оставляя при этом объективное управление клиенту и таким образом давая поставщику уверенность в клиенте и его будущих экономических обязательствах.

Такой тип Agile-контракта потенциально позволяет:

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

Контракт с управляемыми инвестициями на основе подхода SAFe

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

Предварительные соглашения

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

Фаза предварительных соглашений для контракта с управляемыми инвестициями на основе подхода SAFe

Прим. ред. Program Increment, PI или инкремент программы — это временной интервал, за который программа поставляет инкремент ценности в виде работающих и протестированных программного обеспечения и систем. Обычно длится от 8 до 12 недель.

В идеале на этом этапе клиенту нужно донести до поставщика (или потенциальных поставщиков) глобальные цели (миссию) программы.

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

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

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

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

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

Однако в какой-то момент клиент все-таки может перейти к заключению основного контракта.

Исполнение контракта

Далее начинается непосредственно разработка, как описано на рисунке ниже.

Исполнение контракта с управляемыми инвестициями по основе подхода SAFe

Описание активностей на каждом из этапов:

• Подготовка к PI 1. Клиент и поставщик совместно прорабатывают содержание и логистику первой встречи по планированию инкремента программы (примечание: в некоторых случаях бывает удобно включать планирование PI 1 в фазу предварительных соглашений, несмотря на то, что это потребует от сторон существенных инвестиций).
• Планирование PI 1. Планирование первого инкремента программы является основополагающим событием для всей программы. В рамках этой сессии ключевые участники со стороны клиента и поставщика планируют первый инкремент на уровне итераций. Подробнее про то, как проходит эта сессия, см. в статье «PI-планирование в SAFe».
• Исполнение PI 1. В зависимости от контекста представители клиента участвуют на разных уровнях проведения итерации; как минимум непосредственное присутствие клиента требуется на каждой системной демонстрации (System Demo). Однако для больших рабочих процессов (Value Streams) множественные системные демонстрации могут быть заменены на демонстрации решения (Solution Demo), которые глубже интегрированы в процесс и могут проводиться чаще, чем по результатам PI.
• Оценка PI. С этого момента завершение каждого инкремента программы означает ключевой этап проекта как для клиента, так и для поставщика. На каждом из этих этапов проводится демонстрация, а также комплексная оценка решения. Собираются и анализируются согласованные метрики проекта, а также принимается решение о следующих инкрементах программы. Все это происходит во время обязательной в конце каждого PI сессии инспекции и адаптации, чтобы осознать прогресс и спланировать улучшения на предстоящий инкремент. В этот момент клиент может решить сохранить финансирование на текущем уровне, увеличить его, уменьшить или даже начать его сворачивать в зависимости от того, была ли достигнута требуемая ценность продукта. После этого стартует планирование следующего инкремента, и входными данными для него являются результаты и решения, принятые по итогам оценки предыдущего. Подробнее про финансовое управление с динамическим бюджетированием см. в статье «Бюджетирование в SAFe».

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

Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.

Agile руководство шаг за шагом, внедряем эджайл 5+ шагов

Agile как методология гибкого управления становится очень популярной, уже можно с уверенностью сказать, что 100% компаний из списка Forbes применяет Agile в своей работе или по крайне мере думает о том как применить. Почему?

Константин Савкин /автор публикации/

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

Мои образовательные курсы:

➡️ AGILE: базовый курс для руководителя — основные вопросы применения методов гибкого управления Agile (эджайл) в работе компании — подробная информация.

➡️ AGILE: Создание команд и управление процессом внедрения — ключевые вопросы построения Agile команд для внедрения методов гибкого управления в различные бизнес-процеccы — подробная информация.

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

Руководство по Agile

Как эффективно внедрить Agile

Гибкие методы управления используются давно, можно сказать всегда, только назывались они по другому — хитрость и смекалка.

В Agile входит много разных методологий Scrum, Канбан, ХР, Lean, а также множество интересных методик, которые можно использовать по отдельности.

Модель Водопада — Waterfall Model

Agile (Эджайл) краткое руководство по внедрению шаг за шагом

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

Для этого используем Agile — комплекс методов гибкого управления, с возможностью доработки, разработки, адаптации непосредственно под вашу конкретику. Лично мне очень нравится Agile, так как дает возможность решать множество сложнейших задач простым способом и смотреть на проблемные ситуации под другим углом. Интересно? Обратитесь за индивидуальным решением.  

Конечно есть Agile манифест, но он не является ни аксиомой, ни теоремой, это просто свод правил для ориентирования в методах гибкого управления, с одной стороны определяющей границы, а с другой дающий ориентиры — именно так мы будем понимать термин Эджайл манифест.

Зачем внедрять Agile методы гибкого управления в компании

Agile манифест

Методология Agile, как и в целом концепция гибкого управления выражается в следующих простых принципах:

• умение работать с людьми; находить,… воспитывать и управлять талантами.
• выстраивать систему деловых коммуникаций, как с клиентами, так и с партнерами.
• уметь управлять изменениями, девиз: «подвижный в подвижной среде» очень хорошо подходит для Agile команд.

Принципы методов гибкого управления Agile

Распространенные заблуждения по методологии Эджайл

Я намеренно написал Agile в русском произношении Эджайл, что бы акцентировать ваше внимание на следующие факторы, акцент на которые может привести ваш проект к провалу несмотря на методы гибкого управления:

Документация в Agile

Отсутствие документации, игнорирование документации или создание большого объема документации — вот ключевые камни преткновения при работе с документацией и в Agile работать с документацией нужно, главное чтобы документация не создавалась ради документации.

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

Документация в Agile это дневник капитана корабля, а в серьезных проектах черный ящик, который фиксирует все и вся, возможно и не так явно, как кажется.

Договор в Agile

Любой юрист Вам скажет к чему приводит игнорирование договора, конечно возможно вам повезет, а возможно нет, так что? — есть желание игнорировать контракт или может быть потратим немного времени и составим приложение к нашему договор, чтобы потом не было обидно.

Agile управление в компании

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

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

Agile это военная операция в условиях высокой неопределенности

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

Какие отличия Agile от других систем управления

Рекомендую ознакомиться:

Agile позволяет улучшить коммуникации внутри компании и снизить возникновение конфликтных ситуаций.

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

Примеры Agile в компании

Могу ли я привести примеры успешных команд, которые работали по Agile? — да могу, но многие руководители даже не осознают, что частично применяли методы гибкого управления.

Может ли Agile привести к хаосу — да, а хаос к системе? Ответ тоже Да, почему?

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

Scrum методика гибкого управления

Scrum (Скрам) пожалуй одна из популярных и простых методик гибкого управления, мы знаем про Scrum от Джеффа Сазерленда.

Алгоритм реализации Scrum в компании довольно простой:

• определите владельца продукта.
• сформируйте команду от 2-10 человек.
• найдите наставника или скрам-мастера.
• составьте требования к продукту и цели, которые вы хотите достичь, зафиксировав данные в бэклог продукта.
• проведите оценку данных вместе со всей командой, зафиксировав сколько времени потребуется на выполнение.
• определитесь с периодом спринтов, отрезки времени, которые необходимы для внедрения выделенного объема задач. Спринты проводятся до момента завершения проекта.
• проводите ежедневные встречи, 15-20 минут, кратко обозначая следующие вопросы: что делал вчера, что будем делать сегодня и какие трудности мешают.

Дополнительно вы можете делать:

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

7 шагов внедрения SCRUM в компании

Что-то новое? Скорее всего нет, хорошо забытое старое. Agile и Scrum позволяет немного по-другому посмотреть на текущую работу, но это дает совершенно другие результаты. Мы видим новые подходы в лидерстве, командообразовании, управлении проектами и командной работе. Методы гибкого управления могут быть использованы в любых проектах, позволяют повысить эффективность и производительность рабочих команд, снизив при этом вероятность возникновения рисков.

Договор на разработку сайта, мобильного приложения при работе по scrum

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

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

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

Ошибки в документах могут стоить очень дорого. Поэтому мы придерживаемся (и вам рекомендуем) следующих правил при подготовке договоров:

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

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

Сам документооборот в студии и другие шаблоны и регламенты мы разбираем в нашем с Теглайном курсе управления digital-проектами. Присоединяйтесь!

Agile-технологии и их применение в проектах 1С

Наша статья расскажет, как используется методика ведения проектов Agile в 1С.

Agile: что это такое?

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

Спринт – тот промежуток времени, отведенный на получение какого-либо результата, который предоставляем заказчику.

Заключение контрактов

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

Формулировать цели нужно грамотно и конкретно. Например, «автоматизировать работу какого-либо подразделения» – неправильно сформулированная цель, а вот «получить структуру отчета по себестоимости» еще и с «визуальным представлением» – это грамотно поставленная цель. Клиент должен понимать и видеть, что в результате должно получиться, с чем ему дальше нужно будет работать. То есть цель должна быть не только правильно поставлена, но и визуально представлена заказчику.

Также крайне важно расставить акценты. С клиентом стоит оговорить все важные моменты, в том числе и то, как будет приниматься проект. Специфика Agile состоит в том, что важен непосредственно результат, а не организация процесса, поэтому принимать работу заказчику, возможно, придется в полусобранном виде. Объясним на примере. В течение спринта – двух недель – команда разработчиков трудится над проектом. Результатом становится какой-то продукт, к примеру, система, ее подсистема или блок. Это конечный продукт и клиент должен его принять, внедрить и использовать. Такой подход может вызвать неоднозначную реакцию у клиента. Поэтому, еще раз повторим, перед подписанием контракта следует четко оговорить с заказчиком, каким должен быть результат и в каком виде он будет приниматься.

Создание проекта по Agile

Методология Agile не предполагает написания технического задания. Объясняется это просто: нет смысла исписывать сотни листов бумаги, так как техническое задание как таковое нигде потом не применяется. Техническое задание требуют государственные учреждения, которым необходимо отчитываться за потраченные денежные средства.

Но это не значит, что этапа планирования в Agile нет совсем. Просто он представлен в другом виде. Новые проекты 1С создаются на основе готового решения. На предпроектном этапе в готовое решение, к примеру, ERP, вносятся нужные рабочие данные. Если осуществляется переход с уже существующей системы, то заранее будет готовиться конвертация, соответственно, заполняться система будет уже реальными данными. Проектирование в таком случае сводится к созданию системы и ее запуску. В идеальном варианте работы в Agile заказчик принимает активное участие в создании проекта: формирует отчеты, вносит предложения касательно того, как должна выглядеть система, какие изменения нужно внести, чтобы с ней было просто работать и так далее.

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

Оценивание работы

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

В Agile применяется технология Agile Planning Poker, которая, кстати, применяется не только в Agile, и не только для оценки.

Поясним, как она работает. Каждый участник команды обеспечивается колодой карт с цифрами. Для начала подсчитывается, сколько часов необходимо потратить, чтобы выполнить работу. Затем карты кладут рубашкой вверх, программисты берут по одной и вскрывают. Максимальная оценка берется в том случае, если разбежка в количестве часов не превышает 10-20%. Если разница превышает 20%, значит, оценка сильно отличается. В этом случае необходимо организовать обсуждение, в ходе которого выясняется, кто из специалистов был прав. Как правило, этот тот, кто отвел на выполнение работы больше времени. Однако в некоторых случаях прав тот, кто запланировал мало часов. Эта ситуация вероятна тогда, когда программист знает, что есть готовое решение, которое значительно сэкономит время разработки. За этапом обсуждения следует переоценка.

Таким образом получается примерное количество затрат программистов. Преимущество такого подхода в том, что команда несет ответственность за принятые решения. Соответственно, если допустили ошибку при определении затраты времени, трудно будет обвинить в этом кого-то другого.

Составление сметы

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

Составление плана-графика

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

Более мелкий план, в котором прорисованы детали, называется спринт.

Спринт

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

Что главное в проекте? Хорошо подобранная команда

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

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

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

Еще одна незаменимая фигура – ведущий программист, или архитектор. Этот тот, кто непосредственно занимается разработкой проекта. Одна из его задач – тесное сотрудничество с командой заказчика по вопросам разработки продукта. Тестирование, внесение изменений должно быть согласовано с заказчиком и проводится совместно с ним. В идеальном варианте Agile исполнитель должен находиться на территории заказчика.

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

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

Как закрывается спринт

Спринт сопровождается летучками, которые проводятся раз в один-два дня. Главная задача спринта – к назначенному времени успеть выполнить все поставленные задачи. В некоторых компаниях к спринту привязана система мотивации, то есть, если к концу спринта были решены все задачи, команда получает премии. Если хотя бы один из разработчиков не справился, премии не получает никто, даже тот, кто работал безупречно. Таким образом, членам команды нужно помогать друг другу, чтобы в итоге все получили свои бонусы. Чтобы определить, кто оказался в отстающих и кому нужна помощь, проводятся митинги. Зачастую разработчики проводят вечера и выходные дни в офисе, чтобы выполнить в срок требуемые задачи.

Правила проведения митинга

•  Митинг не должен превышать 10-15 минут. Следует четко ограничивать время, чтобы задавались конкретные вопросы. Если митинг затягивается больше чем на 20 минут, значит что-то идет не так. Если на митинге была обнаружена проблема, поиск решения которой займет много времени, нужно организовать отдельную встречу.
•  Члены команды должны быть универсальными специалистами. Если разработчик умеет разрабатывать только интерфейсы, то он явно не подходит для работы с Agile. Для проекта важно, чтобы члены команды могли заменить друг друга в случае необходимости. Поэтому нужно поручать разработчикам выполнение разнообразных задач. Да, он потратит больше времени, чем профи в этой области. Но, если кто-то уйдет на больничный или уволится, работа над проектом будет продолжаться.
•  Присутствие заказчика. Тесный контакт с заказчиком необходим, чтобы он был в курсе, как продвигается работа. Клиенту необязательно посещать офис, можно организовать встречи онлайн.

Презентация спринта

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

Спринт должен быть принят клиентом и оплачен. Об этом заказчик и исполнитель договариваются на стадии подписания договора.

Кто участвует в операции сдачи-приемки спринта?

Со стороны заказчика выступают три представителя.

1.  Тот, кто будет непосредственно эксплуатировать продукт – конечный потребитель или руководитель. С этими лица должен быть налажен тесный контакт.
2.  Тот, кто отвечает за приемку спринта. С этим человеком или командой также нужно налаживать контакт, так как именно они будут принимать работу и подписывать акт о выполненном этапе.
3.  Тот, кто платит, – акционер, инвестор. С ним тоже нужно поддерживать связь, хотя бы изредка. Ведь на проект тратятся его деньги, и человек должен знать и понимать, за что он платит. Достаточно одной встречи в месяц, в ходе которой коротко и ясно рассказывается о результатах работы над проектом.

Учет рабочего времени

Что самое важное в работе программиста? Правильно, время. Время программистов можно условно разделить на инвойсное, которое получили при планировании, и реально потраченное.

И если при запланированных на работу 10 часах реально потраченных получилось 100, то стоит разобраться, была неправильно проведена оценка времени или эффективность сотрудников невелика. Важно каждый день проводить тайм-менеджменты. Они занимают не более 15 минут, зато позволяют проверить, чем заняты члены команды. А заполняемые каждый день отчеты позволяют контролировать эффективность каждого члена команды и проект в целом.

Мотивация

Для того чтобы что-то делать, человеку нужна мотивация, как внешняя, так и внутренняя. В основе пирамиды потребностей Маслоу – безопасность. То есть одним из способов мотивации будет оплата. В проектах Agile есть план – то количество часов, которая закрывается в конце месяца. План зависит как от количества рабочих часов, так и от градации сотрудника. К примеру, из 180 рабочих часов специалист 3 категории должен отработать 60 часов, а программист первой категории – 100. Благодаря отчетам, предоставляемым сотрудниками, считаем фактически отработанное каждым из них время. От заработной платы 60% составляет оклад, 40% – это премии, которые получает сотрудник в зависимости от того, как эффективно был выполнен план. То есть у сотрудника есть мотив – выполнить или перевыполнить план. В этом случае в выигрыше остается и компания, так как члены команды работают не только над процессом, но и стараются выполнить максимальное количество задач за минимальное время.

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

Работы по гарантии

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

Для того чтобы мотивировать работников, можно включить гарантийные работы в спринт. Если к концу спринта баги не будут закрыты, команда не получит премии. Кроме этого, можно ввести планы по гарантии, то есть включать в планы гарантийные работы. Каждый из членов команды обязан выполнить определенное количество часов гарантийных работ. Если они выполнены не будут, это отразится на заработной плате сотрудника. Отличная мотивация, верно?

Преимущества технологии Agile

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

Прозрачный результат

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

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

Сжатые сроки

Спринт в среднем рассчитан на 2-3 недели. Значит, уже примерно через месяц будет получено решение, которое можно пустить в эксплуатацию. К примеру, форму отчета в 1С. После закрытия спринта формой можно будет пользоваться. Это позволяет компании заказчика эффективно функционировать, соответственно не терять доход. Заказчик выигрывает дважды: меньше платит за выполненный в минимальные сроки спринт и получает прибыль от эффективной работы своей компании.

Нацеленность членов команды на результат

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

Недостатки технологии Agile

Нет бюджета на полный проект

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

Затраченное на митинги время

Ежедневно команда собирается на митинги. Даже если они занимают 15 минут, тратится драгоценное время, иногда неэффективно.

Вывод

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

Гибкий подход: зачем нужны agile-решения в недвижимости :: Деньги :: РБК Недвижимость

В Москве и России растет спрос на адаптивные рабочие пространства, сформированные исходя из бизнес-потребностей компаний

Фото: Сергей Савостьянов/ТАСС

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

Аgile — это гибкие принципы работы, которые интегрированы в стратегические и операционные бизнес-процессы, а также в корпоративную культуру компании. Сегодня agile активно проникает в область недвижимости. «Офисное здание может быть agile. Это значит, что наряду с классической моделью сдачи площадей в аренду на длительный срок (обычно пять — десять лет) собственник также обязательно размещает в здании инфраструктуру и выделяет площади для временных арендаторов здания и других заинтересованных компаний», —подтверждает руководитель отдела офисных помещений CBRE Елена Денисова.

Agile в недвижимости

Признаком agile может обладать не только офисный актив, но и офисное пространство. Это адаптивное рабочее пространство, сформированное исходя из бизнес-потребностей компании. Гибкие офисы подразумевают мобильность и способность транформироваться в контексте внешних изменений. Следуя этому принципу, компания разделяет рабочее пространство на зоны, где нет закрепленных за сотрудниками мест. По словам руководителя отдела управления проектами CBRE Павла Якимчука, гибкое рабочее пространство может включать изолированные места для уединенной работы, комфортные зоны для работы проектных команд, креативные зоны для обмена мнениями и генерации новых идей, wellbeing-зоны, которые предназначаются для отдыха, фитнеса, занятий йогой и многое другого. Задача такого рабочего пространства — способствовать реализации главных задач организации через создание комфортной среды для сотрудников.

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

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

​Специфика Agile офиса — зонирование или Activity Based планирование (Фото: CBRE)

На мировом рынке можно найти немало примеров гибких офисов во всех отраслях. Например, банк ING стал одной из первых компаний за пределами традиционной ИТ-отрасли, которая внедрила agile-культуру и переформатировала пространство офиса. Сегодня ING строит новую штаб-квартиру в Амстердаме, руководствуясь принципами гибкости и креативности.

Российский рынок недвижимости находится в начале пути agile-трансформации. Зачастую компании с осторожностью рассматривают перспективы перехода от традиционного офиса и привычного менеджмента к гибкому пространству и новым методам управления. Тем не менее по этому пути идет все больше компаний. Самым знаменитым agile-проектом офисного пространства в Москве стала штаб-квартира Сбербанка на Кутузовском проспекте — Sberbank Agile Home. Более того, банк объявил о приобретении соседних зданий на улице Кульнева и планах по созданию целого инновационного квартала «Сбербанк-Сити». Гибкими офисами могут похвастаться также компании «Яндекс», Lamoda, Avito, Samsung Artificial Intelligence Center.

Офисы как часть шеринг-экономики

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

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

Гибкая аренда

Самый распространенный сегодня вид гибких решений аренды — коворкинги. Такие рабочие пространства впервые появились на Западе в конце прошлого столетия, однако большую популярность как в России, так и в мире они приобрели в последние годы. За это время трансформировалось само понятие коворкинга, считает руководитель гибких офисных решений CBRE Татьяна Шараева. Если раньше к ним относили оборудованные рабочие места, расположенные в одной зоне, где могли работать случайные и незнакомые люди, то сегодня коворкинги включают не только оборудованные рабочие места, но и ряд других решений. В их числе — сервисные офисы или индивидуальные зоны / кабинеты для представителей одной и той же компании. В рамках коворкинга также можно арендовать зоны для проведения мероприятий и переговорные комнаты на почасовой или дневной основе.

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

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

Сегодняшнему собственнику уже недостаточно просто предложить площади в аренду, необходимо создать максимально функциональную и технологичную среду в бизнес-центре, которая будет отвечать потребностям и желаниям арендаторов и их сотрудников. «Компании-арендаторы могут пересмотреть традиционную стратегию аренды офиса в сторону гибкой стратегии для повышения эффективности используемых площадей, — говорит руководитель отдела услуг корпоративным клиентам CBRE Ирина Хорошилова. — Данный поход включает зонирование офиса согласно бизнес-потребностям и использование гибких решений аренды для удовлетворения кратковременной потребности в дополнительных рабочих местах. Стратегия гибкой аренды позволит пересмотреть объем занимаемых площадей на долгосрочной основе».

Продвинутая тема — гибкие контракты

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

— Джейсон Блумберг, «Исправление планирования с помощью Agile в Вирджинии». Forbes

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

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

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

Что необходимо, так это более гибкий подход к контрактам, который принесет пользу обеим сторонам в краткосрочной и долгосрочной перспективе.В этой статье описывается текущее состояние, а затем дается руководство по подходу к гибкому контракту, «Контракту с управляемыми инвестициями SAFe».

Традиционные подходы к системным договорам закупки

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

Рисунок 1. Ряд традиционных типов контрактов

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

Контракты с твердой фиксированной ценой

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

Рис. 2. Контракты с твердо фиксированной ценой создают «железный треугольник»

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

Однако у этого подхода есть много недостатков:

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

Более того, чтобы получить фиксированную ставку, критические решения принимаются слишком рано, когда известно наименьшее количество информации о решении (см. Принцип № 3 — Предполагать изменчивость; сохранять варианты).Стороны вошли в «железный треугольник» с фиксированным объемом, графиком и стоимостью, как показано на рисунке 2. И если факты изменятся, руки покупателя и поставщика будут связаны с контрактом, который теперь может определять то, что никому не нужно. строить или покупать точно так, как было сказано при написании. Большую часть остального времени уходит на переговоры об изменении контракта, что приводит к значительным потерям в процессе.

Хуже всего то, что после заключения соглашения каждая сторона имеет противоположный экономический интерес:

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

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

Контракты на сроки и материалы

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

Проблемы могут существовать и на стороне покупателя. Например, в ходе интервью во время вскрытия проекта Стивен Уоррен, ответственный руководитель и ИТ-директор Управления информации и технологий Департамента по делам ветеранов, отметил, что, по словам руководителя проекта, «проект никогда не был в кризисе», поскольку они расходовали весь бюджет каждый год и, таким образом, могли возобновить финансирование на следующий год.Мерилом успеха в то время было то, будет ли проект продолжать получать финансирование, а не то, сможет ли он предоставить необходимую функциональность [1] ».

Коллективный подход к гибким контрактам

Поскольку ни одна из конечных точек на Рисунке 1 не обеспечивает достаточной уверенности, возможно, средний диапазон является оптимальным вариантом? Возможно, но даже в этом случае предвзятость традиционных контрактов — слева или справа на Рисунке 1 — скорее всего, проникнет в эти соглашения и ожидания.В таком случае нужен другой подход, основанный на доверии и проверке того, что поставщики строят то, что нужно, правильным образом. В идеале он обеспечивает регулярное и объективное управление для покупателя, но при этом позволяет поставщикам быть уверенными в своих клиентах, а также в подразумеваемых будущих экономических обязательствах.

Характеристики такого гибкого контракта будут включать способность:

• Оптимизация экономической стоимости для всех сторон как в краткосрочной, так и в долгосрочной перспективе
• Используйте вариативность, адаптируясь к требованиям по мере появления новых знаний
• Обеспечение полной и непрерывной видимости и объективного подтверждения пригодности решения
• Обеспечьте взвешенный подход к инвестициям, который может меняться с течением времени и прекращаться при достижении достаточной стоимости
• Предложите поставщику краткосрочную уверенность в финансировании и достаточное уведомление, когда финансирование прекращается или прекращается
• Мотивируйте все стороны к созданию наилучшего возможного решения в рамках согласованных экономических границ

Контракты управляемых инвестиций SAFe

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

Предварительное обязательство

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

Рис. 3. Фаза предварительного обязательства по контракту с управляемыми инвестициями SAFe

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

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

Совместная ответственность, показанная на рисунке 3, побуждает клиента и поставщика к более взвешенным инвестициям, подкрепленным постоянными объективными доказательствами пригодности для использования.Эти обязанности включают:

• Создание первоначального видения и дорожной карты
• Определение минимально жизнеспособного продукта (MVP) и дополнительных потенциальных возможностей приращения программы (PI)
• Определение начального фиксированного и переменного намерения решения
• Приоритизация начального невыполненного задания программы для планирования PI
• Установление исполнительной ответственности
• Установление экономической основы, включая параметры экономического компромисса, обязательство по финансированию ИП (количество выделенных ИП), начальные уровни финансирования и другие договорные условия

В некоторых случаях поставщику может потребоваться предоставить предварительную оценку для обеспечения обязательства по финансированию PI для завершения.В других случаях может оказаться подходящим подход с оплатой по факту. На основе условий заказчик соглашается профинансировать поставщика для ранних ИП. Это начальный период обязательств. Продолжительность зависит от контекста, но два или около того ИП (20 недель) могут быть разумной отправной точкой.

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

Однако в какой-то момент заказчик может перейти к заключению контракта.

Исполнение договора

После присуждения контракта начинается разработка, как показано на Рисунке 4.

Рис. 4. Этап исполнения контракта по управляемым инвестициям SAFe

Ниже приводится описание графика деятельности:

• Подготовка к PI — И поставщик, и заказчик потратят некоторое время и усилия на подготовку контента и логистики для первого сеанса планирования PI.(Примечание: в некоторых случаях может быть целесообразным, чтобы первое PI-планирование было частью этапа предварительного принятия обязательств, хотя этот маршрут явно требует значительных инвестиций с обеих сторон.)
• PI-планирование — Первое событие PI-планирования влияет на всю программу. Там заинтересованные стороны клиента и поставщика планируют первую PI с детализацией на уровне итераций.
• Выполнение PI — В зависимости от контекста клиенты участвуют в итерационном выполнении на разных уровнях. Однако, как минимум, для каждой демонстрации системы обычно требуется прямое взаимодействие с клиентами.Однако для больших решений множество демонстраций системы может быть заменено более полно интегрированной демонстрацией решения, которая может происходить чаще, чем на границах PI.
• Оценка PI — После этого каждый PI отмечает критический этап как для клиента, так и для поставщика. На каждом этапе проводится демонстрация решения, и решение оценивается. Согласованные показатели собираются и анализируются, и принимаются решения для следующего PI. Прогресс решения и улучшения программы оцениваются во время мероприятия «Проверка и адаптация» (I&A).На этом этапе клиент может решить увеличить, уменьшить или сохранить уровень финансирования или даже начать сворачивать инициативу в зависимости от того, была ли достигнута достаточная ценность. После этого начинается следующее PI-планирование, объем которого зависит от результата этого решения.

Управление рисками с помощью подхода бережливого стартапа

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

Рис. 5. Цикл экономичного запуска для управления крупными инвестициями в разработку продукта

Эта модель экономичного запуска сокращает время вывода на рынок и помогает предотвратить раздутие системы ненужными функциями, которые, возможно, никогда не будут использоваться. Он также обеспечивает выполнение цикла «гипотеза-построение-измерение-изучение», описанного в статьях Epic и Continuous Delivery Pipeline.

Подразумевается, что язык контрактов Agile изменен для отражения комбинации фиксированных и переменных компонентов.MVP, определенный на этапе перед принятием обязательств, может установить высокоуровневое определение фиксированного объема, который должен быть доставлен по предложенному количеству PI. Помимо предоставления MVP, в контракте также может быть указано количество периодов опционов, состоящих из одного или нескольких PI. Цель состоит в том, чтобы оптимизировать предоставление приоритетных функций в каждом PI.

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

• Лучшая предсказуемость оценок, связанная с гораздо меньшим MVP, чем полный список всех требований
• Полный контроль над расходами, необходимыми для дополнительных дополнительных функций в зависимости от экономических результатов

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

---

Узнать больше

[1] Блумберг, Джейсон. Исправление планирования с помощью Agile в VA. Forbes, 23 октября 2014 г. [2] Джемило, Дрю. Agile Contracts: Старт в зону создания систем для совместной работы. Agile 2015. https://www.slideshare.net/JEMILOD/agile-contracts-by-drew-jemilo-agile2015

Последнее обновление: 10 февраля 2021 г.

Информация на этой странице принадлежит © 2010-2021 Scaled Agile, Inc. и защищена американскими и международными законами об авторских правах.Ни изображения, ни текст не могут быть скопированы с этого сайта без письменного разрешения правообладателя. Scaled Agile Framework и SAFe являются зарегистрированными товарными знаками Scaled Agile, Inc. Посетите раздел часто задаваемых вопросов о разрешениях и свяжитесь с нами для получения разрешений.

Три типа гибких контрактов

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

Щелкните ниже, чтобы просмотреть короткое видео с основными моментами блога, или продолжайте прокрутку, чтобы прочитать остальную часть статьи.

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

Целевая стоимость

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

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

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

Инкрементная доставка

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

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

Время и материалы

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

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

Agile контрактов

Один из часто задаваемых вопросов об Agile-методах: «Как подписать контракт на основе Agile-методологии?»

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

После подписания контракта следует период разработки, когда все спорят о том, что на самом деле входит в объем, что выходит за рамки и что составляет запрос на изменение контракта. Но в конце концов работа сделана, и после некоторых жарких споров заказчик официально принимает программное обеспечение, и оплата производится. Заказчик получает 200 кг программного обеспечения, поставщик получает свои деньги, и все довольны, а может быть, и не все.

Сопутствующий спонсируемый контент

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

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

В этой статье будут рассмотрены четыре модели, доступные поставщикам и клиентам для заключения контрактов на Agile-работу. Со временем, вероятно, появятся новые модели, но сейчас есть четыре варианта.

Разоблачение фиксированного контракта

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

Эта модель основана на понимании того, что это «вещь», а именно некоторое количество специализированного программного обеспечения. Тем не менее, покупка нестандартного программного обеспечения — это не столько покупка индивидуального костюма, сколько покупка финансового совета.То, что вы покупаете, — это больше услуга, чем товары или товары.

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

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

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

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

Не для всех

Прежде чем рассматривать варианты, стоит отметить, что эта проблема затрагивает не все компании, создающие программное обеспечение или пытающиеся использовать Agile. Компании, которые создают и продают программные продукты — иногда называемые независимыми поставщиками программного обеспечения, независимыми поставщиками программного обеспечения, например Adobe и Intuit, — сталкиваются с этой проблемой только на периферии. Большинство их клиентов покупают только готовые продукты и не могут напрямую сказать, что делает продукт.

Некоторые корпоративные ИТ-группы, создающие программное обеспечение, также избегают проблем с контрактами.Они покупают готовое программное обеспечение (например, SQL Server) или создают индивидуальное программное обеспечение, которое будет использоваться только самой компанией. Большинство корпоративных ИТ-групп в какое-то время передают работу по контракту и, следовательно, должны заключать и согласовывать контракты. В этих случаях ИТ-группа является заказчиком стороннего поставщика программного обеспечения.

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

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

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

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

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

Вариант 1. Скрыть

Самый простой и наименее разрушительный способ использования Agile в контракте на поставку — просто скрыть его. Не говорите клиенту, что вы работаете иначе, чем обычно. Оцените и спланируйте работу, как обычно, подпишите совершенно нормальный контракт, а затем используйте методы Agile, чтобы улучшить выполнение.

Разработка, основанная на тестировании, непрерывная интеграция, регулярный рефакторинг и перепланирование — все это в любом случае поможет вам добиться большего успеха.По возможности игнорируйте первоначальный план, так как он в любом случае был «неправильным». Если возможно, выбросьте исходный план.

Проблема в том, что некоторые клиенты хотят видеть «прогресс против плана». Вы могли подделать это. Я слышал истории о командах, которые обновляли планы, чтобы казалось, будто они следуют плану. Однако этот подход не совсем правдив. На самом деле, как мы можем надеяться на то, чтобы завоевать доверие клиентов, если мы фальсифицировали часть процесса, в который они верят? Естественно, мы не хотим лгать клиенту, мы хотим завоевать доверие, и почему они будут нам доверять, если мы притворяемся, следуя плану?

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

Итак, чтобы подход «спрятать» работал, необходима политика типа «не спрашивай, не говори». Если у вас есть клиент, который готов следовать политике «не спрашивать, не рассказывать» и вместо этого измерять прогресс по фактическим поставкам, а не следовать плану, то сокрытие Agile может сработать. Но если у вас есть такой понимающий клиент, то вам, вероятно, вообще не нужно скрывать Agile.

Вариант 2: Без лечения, без оплаты

Принятие подхода «Нет лечения — нет оплаты» требует определенной степени уверенности.Подход прост: если клиенту не нравится то, что вы доставляете, плата не взимается. Однако, если они не платят за то, что вы производите, они тоже не могут оставить себе это.

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

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

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

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

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

Вариант 3: Продление контрактов

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

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

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

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

Со стороны поставщика существует явный стимул продемонстрировать ценность через вертикальные срезы завершенной функциональности — обычная практика Agile.

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

Эта опция перемещает правовые рамки от предложения вещи к предоставлению услуги. Клиенты заключают договор на оказание услуги, и необходимо подумать о количестве услуг, которые они покупают. Четыре человеко-месяца? 200 точек скорости работы?

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

Вариант 4: Деньги даром, сдача бесплатно

Контракт «Деньги в дар, сдача бесплатно» был подробно задокументирован создателем Scrum Джеффом Сазерлендом. Вместо того, чтобы строить контракт как основу для мини-проектов, этот подход поддерживает большой контракт, который неявно предполагает некоторый большой предварительный анализ требований. Однако к контракту добавляются два дополнительных пункта.

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

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

Положение «деньги в обмен на ничего» позволяет заказчику на любом этапе отменить оставшуюся работу и сохранить то, что было создано до сих пор. За эту привилегию клиент оплачивает 20% выполненной работы.

Таким образом, если клиент отменяет 12-месячный проект стоимостью 12 миллионов долларов на полпути, он заплатит дополнительно 1,2 миллиона долларов в дополнение к 6 миллионам долларов, уплаченным на сегодняшний день. Клиент экономит 4,8 миллиона долларов, которые он бы потратил на выполнение контракта.

На первый взгляд поставщик может не одобрить этот вариант, так как он может потерять 4 доллара.8м они бы заработали. Однако 1,2 миллиона долларов, которые им платят за бездействие, во многом компенсируют это. Если предположить, что они быстро переведут свой персонал на другую работу, большая часть из этих 1,2 миллиона долларов будет чистой прибылью.

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

На данный момент примеров этого типа контрактов мало.

Комбинации

Учитывая эти четыре варианта, легко увидеть еще несколько альтернатив, комбинируя их разными способами. Например, «Обмен бесплатно» можно комбинировать с любым из трех других вариантов, чтобы создать более эффективное решение. Аналогичным образом «Нет лечения — нет оплаты» можно применить к отдельным поставкам в третьем варианте — «Постоянные контракты».

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

И наоборот, четвертый вариант работает в рамках существующей модели с учетом предварительных требований. Часть «изменение бесплатно» обеспечивает структуру, аналогичную скользящему контракту: первоначальные требования служат инструментом оценки для определения времени и бюджета. Как только начнется работа, их можно выбросить. Часть «деньги за ничего» имитирует повторяющийся контракт, позволяя останавливать работу в любой момент, хотя и с надбавкой.

Каким бы способом ни составлялись контракты для Agile-команд, необходимо учитывать два важных элемента.Во-первых, сами контракты должны отражать итеративный характер работы Agile: делать немного, показывать немного, делать немного больше. Это тема, которая повторяется снова и снова в Agile: ограниченные по времени итерации, ретроспективы, разработка через тестирование и т. Д. И т. Д. Это цикл PDCA в действии.

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

Последнее, но не менее

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

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

Один из моих клиентов теперь регулярно предлагает своим клиентам два варианта: традиционный «фиксированный» контракт и скользящий вариант Agile. Если заказчик думает, что все можно исправить до начала работы, он может использовать традиционный подход.Если они не уверены в этом, они могут применить итеративный метод гибкой прокрутки.

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

Об авторе

Аллан Келли занимал практически любую должность в мире программного обеспечения: системный администратор, тестировщик, разработчик, архитектор, менеджер по продукту и менеджер по развитию.Он живет в Лондоне и специализируется на оказании помощи компаниям-разработчикам программного обеспечения во внедрении и углублении практик Agile и Lean посредством обучения, консультирования и коучинга.

В дополнение к многочисленным статьям в журналах и презентациям на конференциях он является автором книги «Изменение разработки программного обеспечения: как научиться гибкости».

Обзор Agile-контрактов: Scrumology Pty Ltd

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

---

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

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

• Отдельные лица и взаимодействия важнее процессов и инструментов
• Рабочее программное обеспечение поверх исчерпывающей документации
• Сотрудничество с клиентами в рамках переговоров по контракту
• Реагирование на изменение в соответствии с планом

То есть, в то время как предметы справа имеют ценность, мы ценим предметы слева больше.

Большая часть ранних работ по Agile-контрактам была написана сообществом экономичных разработчиков программного обеспечения… в частности, из книги Мэри Поппендик «Бережливая разработка программного обеспечения». Алистер Кокберн также опубликовал на своем веб-сайте большое количество различных типов контрактов.

Хотя есть множество вариантов выбора, на практике есть только несколько стилей контрактов, которые я вижу снова и снова. Это связано с тем, что мы склонны использовать знакомые нам контракты и поэтому основываем свои решения на том, что сработало в прошлом.

По мере изменения нашего опыта и ожиданий мы будем использовать нестандартные контракты. А пока я хотел бы представить три типа контрактов. Первые два ( Capped T&M и Incremental Delivery ) являются наиболее распространенными типами Agile-контрактов. Третий тип контракта ( Cost Targeted ) — это стиль контракта, о котором часто говорят, но редко замечают.

T&M с заглушкой

Обычным контрактом является контракт Time and Materials (T&M), но, хотя этот вид контракта защищает поставщика, он не обеспечивает никакой защиты для клиента.Заказчик полностью подвергается риску, в то время как поставщик не разделяет этот риск.

Итак, обычным продлением контрактов T&M является контракт Capped T&M . Это контракты T&M до фиксированного согласованного верхнего предела (или верхнего предела). Ограниченные T&M контракты дают поставщику выгоду на раннем этапе, полностью покрывая его расходы; но также обеспечить выгоду для клиента ближе к концу проекта, установив ограничение на общую подверженность риску.Обе стороны заинтересованы в том, чтобы как можно раньше предоставить высококачественную функциональность и избежать перерасхода средств.

T&M с ограничениями часто имеют переменный объем, хотя это и не обязательно.

Инкрементальная доставка

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

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

Контракты с целевым назначением затрат

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

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

Несколько заключительных мыслей…

Я лично успешно использовал как контракты Capped T&M , так и контракты Incremental Delivery с проектами Agile. И хотя вокруг контрактов Target Cost ведется много разговоров и обсуждений, я еще не видел, чтобы они использовались в Agile-проектах.Если вы использовали какой-либо из контрактов, описанных Алистером, я хотел бы услышать о вашем опыте.

Связанные

Гибким проектам нужны гибкие контракты

Использование гибких подходов для внесения изменений как в ИТ, так и в бизнес-функции стремительно растет. Такие отчеты, как исследование State of Agile, неизменно демонстрируют рост внедрения гибких практик с переломным моментом, когда с помощью Agile будет реализовано больше изменений, чем при использовании традиционных подходов, таких как водопад, которые, как ожидается, будут реализованы в конце 2016 или начале 2017 года.

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

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

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

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

Распознать и понять условия вашего проекта для эффективного заключения контракта

Первый шаг в определении наиболее подходящего коммерческого подхода — это задать вопросы, которые позволят вам понять условия проекта, в которых вы будете работать. Вы работаете с поставщиком, с которым у вас прочные прозрачные отношения и который, как вы доверяете, будет вести себя разумно по мере появления и изменения требований? Какого уровня изменений объема вы ожидаете в ходе реализации вашего проекта? Знакомы ли вы и продавец с предлагаемой архитектурой и набором технологий? Такие условия повлияют на используемый вами коммерческий подход.Например, плохие отношения с поставщиком могут указывать на то, что может оказаться полезным более высокий уровень специфичности предварительных требований; Если вы работаете с новым набором технологий, вы можете попытаться устранить неопределенность с помощью прототипирования в начальных циклах до заключения долгосрочного контракта с поставщиком.

Совместите мотивацию клиентов и поставщиков с помощью вашего коммерческого подхода

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

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

Этот подход затем позволяет заключить контракт на вторую фазу проекта по фиксированной цене, основанной на размере всех известных эпиков. В рамках этого заказчик может заменить новые Epics в контракт по мере их появления на основе «один на один из аналогичных размеров» с согласия поставщика. Этот подход поддерживается дополнительными коммерческими методами, такими как фиксированная прибыль, которые снижают маржу, которую поставщик может применить, если работа продлевается из-за перерасхода средств.Ключ к успеху — это постоянный и прозрачный диалог и партнерский подход между заказчиком и поставщиком.

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

Конструкция выхода

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

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

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

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

Agile Contract Models — Работа с внутрифирменными командами

+++ Гибкое межкорпоративное сотрудничество +++ Кто назначает владельца продукта? +++ Контрактные модели для гибких проектов и их преимущества / недостатки +++

Автор: Antje Lehmann-Benz

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

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

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

Как работают гибкие команды?

Давайте начнем с быстрого обзора: agile-команда — часто Scrum-команда — состоит из владельца продукта, scrum-мастера и трех-девяти разработчиков. Команда использует итерации, называемые спринтами, чтобы сосредоточиться на разработке нового продукта или дальнейшей разработке существующего. Каждое приращение продукта должно быть готово к демонстрации и, возможно, доставлено к концу каждого спринта.

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

Special Загрузка: Гибкое, традиционное или гибридное управление проектами? (PDF файл)

Заполните, пожалуйста, форму.
* Поля, обязательные для заполнения | Защита данных

Эта форма заблокирована вашими настройками файлов cookie для нашего веб-сайта.Нажмите здесь и выберите хотя бы маркетинговые файлы cookie. Тогда эта форма будет видна. Большое спасибо.

Что такое «product owner»?

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

В любом случае обычно есть одно лицо, которое несет ответственность за разъяснение, документирование и доведение до сведения требований.Эту роль часто называют «владельцем продукта» даже в командах, не участвующих в схватке. Однако «инженеры по требованиям», «бизнес-аналитики» или просто «заказчики» также могут взять на себя эту роль. Для простоты в этой статье мы будем называть эту роль «владельцем продукта».

Модель контракта для гибких проектов: кто выбирает владельца продукта?

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

Изображение: Сотрудничество сталкивается с серьезной проблемой: создание гибкой команды с участием разных компаний

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

• Насколько хороши отношения между клиентом и поставщиком? Сможет ли product owner, представляющий клиента, достаточно тесно сотрудничать с командой разработчиков и гарантировать, что он / она будет доступен столько, сколько потребуется? И: Доверяют ли друг другу product owner и разработчики, или есть атмосфера недоверия?
• Кто хорошо знает заинтересованные стороны и понимает их потребности? Кто действительно разбирается в рынке? Обычно это должна быть компания, заказывающая работы.
• С другой стороны, кто хорошо знает команду разработчиков и знаком с ее методами?
• Кто лучше всего может перевести и расставить приоритеты требований клиента на уровне реализации?
• Насколько хорошо осведомлены об Agile-методах задействованные? Есть ли с обеих сторон кто-нибудь, кто имел бы опыт владения продуктом?

Аргументы в пользу того, чтобы владельцем продукта был кто-то на стороне поставщика:

• Технические навыки
• Близость к группе внедрения
• Знакомство с внутренними процессами разработки

С другой стороны, аргументы в пользу того, чтобы владельцем продукта был кто-то на стороне клиента, следующие:

• Близость к рынку, конечные потребители / заинтересованные стороны, требования
• «Власть» или авторитет через свое положение платежеспособного клиента

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

Что такое «прокси-владелец продукта»?

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

Однако доверенное лицо продукта, как правило, находится в слабом положении и поэтому не имеет полномочий принимать решения. Этот человек в основном служит фильтром в отношении требований.

Эти и другие характеристики, составляющие типичные проблемы, с которыми сталкивается владелец продукта, описаны Романом Пихлером в его статье блога «Как избежать распространенных ошибок владельца продукта».

Наш совет: Люди, оказавшиеся в роли доверенных лиц продукта и сталкивающиеся с проблемами, должны попытаться разрешить ситуацию, поскольку это единственное решение. Человеку должны быть предоставлены полномочия , необходимые для того, чтобы быть «истинным владельцем продукта», включая полномочия принимать решения, связанные с продуктом, и устанавливать приоритеты, или роль должна быть предоставлена ​​кому-то с такими полномочиями. По крайней мере, четко опишите роли и разграничьте ответственность за принятие решений для них, с акцентом на коммуникации и согласование между ними.В противном случае конфликты ролей поставят под угрозу любые попытки установить приоритеты при разработке продукта.

Другие факторы, которые следует учитывать при заключении контракта с гибкими проектами

Хорошо, теперь вы решили вопрос, кто является владельцем продукта? Большой! Вот еще несколько вещей, которые следует учитывать при гибком управлении контрактами:

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

Обзор гибких контрактных моделей

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

Модели с фиксированной ценой

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

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

В таких контрактных процессах часто используются следующие рабочие процессы:

Изображение: Традиционная последовательность документов и процессов в закупках проекта

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

Фиксированная цена с несколькими гибкими элементами

Чтобы адаптировать модель с фиксированной ценой к более подходящей для гибких проектов, вам необходимо включить в нее несколько гибких принципов.Можно учитывать следующие факторы:

1. Функции изначально не определены полностью. Каждая из договаривающихся сторон подтверждает другим, что понимает этот факт.
2. Существует взаимное согласие по целям проекта , в частности, что существует общее видение продукта и дорожная карта. Существует договорное обязательство по постоянному обмену информацией посредством обсуждений, а не только путем пересылки документов туда и обратно.
3. Если возникают проблемы, кооперативные подходы используются для решения проблемы, а «гибкое мышление» подчеркивается, чтобы уменьшить различия и найти точки соприкосновения.Это требует доверия и расширения прав и возможностей всех участников. Ссылка на существующий подход может быть задокументирована в контракте. Например, может быть ссылка на руководство по схватке, если команда использует его в качестве основы.
4. Критерии завершения (Определение выполненного), согласованные группой внедрения вместе с владельцем продукта и заинтересованными сторонами, также могут быть включены в контракт. Однако вы должны подчеркнуть, что эти критерии могут измениться в ходе проекта.Договаривающиеся стороны должны понимать, что именно представляет собой определение выполненного , чем оно отличается от критериев приемки и почему оно представляет собой командное соглашение . Критерии приемки также могут быть определены в контракте и служат основой для определения «Сделано». Наконец, определяет временные рамки для итераций (называемых «спринтами» в схватках) и встреч (и их периодичность), также можно записать в контракт.
5. Разъяснение ролей и Уставы команды — это другие документы, которые могут быть включены в контракты с фиксированной ценой, адаптированные для гибких проектов.
6. Вместо описания объема работ или технических условий может быть договорное соглашение о необходимости отставания по продукту .
7. Роли четко определены для проекта и задокументированы в контракте. Также задокументировано, кто и на каких собраниях должен участвовать. Например, подрядчик и заказчик могут отправить своего представителя на собрания по планированию спринта, чтобы предотвратить неприятные сюрпризы, связанные с контрактом.
8. Методы оценки можно использовать наиболее эффективным способом.От вас не требуется использовать гибкую калькуляцию размеров и оценку относительных усилий. Это особенно верно, когда существуют уже доказавшие свою эффективность методы. Стороны могут уделить больше времени гибким оценкам , если они считают, что это принесет пользу проекту. Конечно, стороны также могут заключить договор об использовании диаграмм выгорания продукта или выпуска для измерения прогресса .

Приоритезация в гибких проектах

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

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

Изображение: Матрица для приоритезации требований в гибких проектах для клиентов

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

Agile с фиксированной ценой

Примеры, описанные выше, служат для постепенного внедрения гибких принципов в традиционные среды и соглашения. У вас также есть возможность сделать весь контракт более «гибким».

При использовании гибкой модели с фиксированной ценой вы сначала описываете согласованный в контракте объем проекта , основанный на видении продукта , и даете очень приблизительное описание функций.

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

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

Особый тип контракта для гибких проектов в данном контексте — это модель «Деньги за ничего, изменения бесплатно» соавтора схватки Джеффа Сазерленда. В этом случае клиент сначала следует традиционному курсу, определяя требования, а участник торгов в ответ подает заявку по фиксированной цене. В начале реализации клиент берет на себя роль владельца продукта и управляет отставанием по продукту.

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

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

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

Идея «Изменения бесплатно», с другой стороны, оказалась успешной в реальных проектах.

Фиксированная цена: оплата за спринт

Вы также можете сделать свой базовый контракт более гибким, договорившись о платежном цикле, согласованном с ритмом спринта — следовательно, фиксированной цене за спринт. В этой модели «фиксированная цена за спринт» договаривающиеся стороны по существу имеют много небольших проектов с фиксированной ценой, при этом каждая итерация представляет собой мини-продукт. Каждый план спринта ведет к новому контракту, а каждый обзор представляет собой приемочную встречу.Таким образом, четко определены временные рамки каждого спринта. Подобные модели часто используются регулирующими органами США, где они известны как «Соглашения о полной покупке» или «Контракты на неопределенную поставку / неопределенное количество» (IDIQ).

Время и материалы (T&M)

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

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

Одним из решений может быть адаптация контракта T&M для создания контракта «Дизайн в соответствии с затратами» или «Плата за производительность».

• «От проектирования к стоимости» контрактов имеют фиксированный бюджет, но более гибкий объем проекта. Этот тип контракта особенно хорошо подходит для ситуаций, когда подрядчик может предложить цену, приемлемую для него, на основе его предыдущего опыта работы с аналогичными проектами.
• В контракте «Плата за производительность» подрядчик по договору обязуется соблюдать определенный уровень производительности на основе согласованных критериев. Цель состоит в том, чтобы создать стимул для поддержания высокого стандарта качества продукции.В противном случае большая часть оплачиваемой производительности тратится на простое обслуживание и устранение проблем. Однако эта модель на самом деле не ориентирована на выгоду клиента, потому что команды теоретически могут очень эффективно работать над функциональностью, которая мало приносит пользу ни клиенту, ни конечному пользователю.

T&M: оплата за спринт

Модель «Платите, что получаете» Модель аналогична модели с фиксированной ценой за спринт. Однако существует явное соглашение о том, что клиент будет платить только за результаты, принятые в обзоре спринта.Это работает, если между договаривающимися сторонами существует высокая степень доверия.

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

Изображение: Сравнение модели с фиксированной ценой и модели времени и материалов, показывающее степень контроля и финансовые риски для клиента и поставщика в гибком контракте

Другие формы гибридных и специализированных контрактов для гибких проектов

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

Льготные контрактные модели

Разработка продукта с добавленной стоимостью — одна из ключевых задач гибкой разработки. Ни одна из представленных до сих пор контрактных моделей не способствует достижению этой цели. Поэтому юристы часто относительно незнакомы с этими принципами контрактов. Однако они могут помочь справиться с высокой степенью сложности и неопределенности в современных программных проектах.

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

Соглашения о предоставлении льгот

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

В этом случае всем участникам должно быть ясно, что клиент считает «ценностью» и как она измеряется. Это делается с использованием карты столкновения .

«Плата за использование»

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

Отобранный вручную контент: Подробнее о том, как гибкие методы могут обеспечить успех управления ресурсами: Конфликты ресурсов в проектах — может ли гибкое планирование их уменьшить?

Какой тип контракта наиболее подходит?

Тип договора	Подтип / вариант	Характеристики	Когда подходит?
Традиционная фиксированная цена		Скорее негибкий: менее подходит, если требуется гибкость при разработке продукта	Подходит, если можно точно определить усилие
	Фиксированная цена с гибкими элементами	По-прежнему довольно негибкий, но он дает начальное понимание гибких концепций	Гибридный проектный подход, новое внедрение гибких принципов в традиционную среду
	Agile с фиксированной ценой	Видение продукта и приблизительное определение характеристик используются для оценки фиксированной цены.Это может сработать, но есть риск возникновения проблем, если оценки неверны.	Процессы, требующие фиксированной цены, но для которых существует большой спрос на использование гибкой методологии
	«Деньги напрасно, сдача бесплатно»	Добавляет высокую скорость изменений и бюджетную ответственность в проект с фиксированной ценой	Эта модель работает, если существует взаимное доверие между договаривающимися сторонами, сотрудничество, основанное на равенстве, клиент принимает непосредственное участие в реальной работе, а процессы закупок клиента позволяют использовать эту модель.
	Фиксированная цена за спринт	Это подчеркивает итеративный характер работы команды схватки — минимальная гибкость, разбитая на спринты.	Взаимное доверие между договаривающимися сторонами, эмпирические данные должны быть доступны или быстро получены
Время и материалы		Оплата и выставление счетов на основе понесенных расходов Подрядчик может гибко подходить к выполняемым работам, что полезно для гибких проектов, но существует риск того, что что-то может пойти не так.	Уверенность клиента в том, что подрядчик не будет злоупотреблять этими отношениями, и уверенность в том, что эта модель контракта не будет юридически искажена в его пользу.
	Платите столько, сколько получаете	Поставщик услуг выполняет работу до получения оплаты, а клиент платит только в том случае, если он одобряет результат по окончании спринта.	Это требует высокой степени доверия между договаривающимися сторонами, чтобы не было неприятных сюрпризов.
	Дизайн по цене	Фиксированный бюджет, гибкий объем, фактура выставлена ​​в соответствии с понесенными расходами	Имеются применимые эмпирические данные
	Оплата за производительность	Выплата на основе согласованных критериев оценочной производительности; контент гибкий	Верьте, что подрядчик разработает что-то действительно полезное для клиента; активное участие клиентов
Контракты исключительно с добавленной стоимостью		Сосредоточение внимания на потребностях клиента — один из основных принципов гибкой разработки, и эта модель контракта пытается это учесть.	Доступны и понятны хорошие показатели для определения, оценки и последующего измерения добавленной стоимости.
	Соглашения о предоставлении льгот	Подрядчик получает оплату за труд и дополнительный стимул за произведенную добавленную стоимость.	Хорошие показатели для определения, оценки и последующего измерения добавленной стоимости доступны и понятны — если возможно, и не будет неприятного сюрприза, если не будет выплачено вознаграждение.
	Плата за использование	Модель лицензирования SAAS: клиент платит только за фактически использованную функциональность	Проект по внедрению лицензионного программного обеспечения для клиента и его последующему регулярному использованию

Резюме и заключение

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

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

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

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

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

Есть ли у вас опыт работы с гибкими контрактными моделями? Что, на ваш взгляд, требует особого внимания? Пожалуйста, оставьте нам небольшой комментарий.

распечатать артикул

Обзор гибких контрактов

Собираетесь ли вы справиться с гибким проектом, но не знаком с гибкими контрактами? Или не уверены в ключевых факторах гибких контрактов? Тогда вам как руководителю проекта, бизнес-аналитику или даже члену agile-команды пора узнать основы этого термина управления проектами Agile — Agile Contracts.

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

Большая распродажа Whizlabs (ограниченное предложение)

Поделитесь этой статьей на любой платформе социальных сетей и получите практические тесты PMI ACP® бесплатно . Поделитесь им сейчас и отправьте нам письмо по адресу [адрес электронной почты защищен] со ссылкой на сообщение в социальных сетях.

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

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

Зачем нам нужны гибкие контракты?

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

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

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

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

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

Какие бывают типы гибких контрактов?

Ценовой механизм гибких контрактов для реального мира основан на времени и материалах. В отрасли практикуются в основном три типа гибких контрактов, а именно:

1. Контракты с ограниченным сроком и материалами

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

2. Контракты с плановой стоимостью

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

3. Контракты на дополнительные поставки

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

Получение сертификата Agile Certified дает вам явное преимущество перед коллегами. Прочтите эту статью, чтобы узнать 5 лучших сертификатов Agile.

Характеристики гибкого контракта

Давайте рассмотрим основные характеристики Agile-контракта, чтобы лучше понять его.

• Эффективная обработка отказов с помощью шипов

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

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

• Обеспечение подотчетности поставщика

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

• Четкое представление о принципах работы проекта, включая роли и обязанности.
• Как управлять невыполненной работой, то есть списком элементов, которые необходимо выполнить, их приоритетом, а также оценкой усилий, необходимых для очистки невыполненной работы.
• Обеспечение соответствующей структуры управления, которая будет включать показатели работоспособности проекта и контрольные точки для измерения этих показателей.
• Введение «определения выполненного» во избежание любых будущих договорных споров.
• Обеспечение гарантийной защиты, гарантирующей соответствие конечного продукта описанию продукта.

• Гарантия эффективного разрешения споров

Гибкие контракты для реального мира должны быть готовы к разрешению споров, которые могут возникнуть, помимо всплесков, упомянутых в гибких контрактах. Таким образом, гибкое управление контрактами должно уделять особое внимание —

.

• Быстрый процесс разрешения.
• Удаление спорных элементов из спринта для обеспечения бесперебойной доставки оставшихся спринтов.

• Обеспечение прозрачной модели ценообразования

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

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

• Фиксированная цена за пользовательскую историю — Следует избегать слишком длинных пользовательских историй.
• Фиксированная цена за итерацию. Все итерации должны соответствовать одинаковым сюжетным точкам. Это создаст беспроигрышную ситуацию для обеих сторон.
• Фиксированная цена за согласованное количество функций — заранее описать функцию.
• Время и материал — Как указано в разделе выше в разделе «Ограниченное время и материал».

Хотя объемы гибких проектов являются переменными, в контракт необходимо включить объемы высокого уровня. Однако акцент следует делать на процессе, а не на сроках доставки.

• Ориентация на ценности бизнеса

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

Готовитесь к Agile-собеседованию? Здесь мы собрали полный набор 25 самых популярных вопросов на собеседовании по Agile, которые помогут вам пройти собеседование.

Преимущества гибкого управления контрактами

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

Вот некоторые преимущества гибких контрактов —

• Гибкость
• Разбивает проекты на более короткие спринты — проще обрабатывать детали
• Частое сотрудничество
• Ориентирован на беспроигрышную ситуацию для обеих сторон

Чтобы быть более конкретным, мы можем сказать, что преимущества гибкого управления контрактами заключаются в принципах гибкого заключения контрактов, которые соответствуют определенным критериям, таким как:

Поощрять стимулы

• Поощряет оплату за результат, а не за усилия — В конечном итоге это побуждает поставщиков сосредоточиться на создании бизнес-ценностей.
• Предложить деньги даром — обеспечивает справедливый способ досрочно расторгнуть контракт в случае, если ключевое значение было доставлено.
• Принять запрос на изменение бесплатно — Предоставляет возможность обновить область действия, избегая «смещения области действия».

Сотрудничество и прозрачность

• Преимущества постоянного улучшения — Продавцы получают повышенную эффективность
• Поддержание доверия — Обе стороны должны вести дела честно и добросовестно.
  

  Последствия нарушения доверия со стороны договорных и рыночных отношений

  Регулярные встречи и задачи по невыполнению заказов

  Отслеживание правильных показателей для обеспечения постоянного улучшения

  Гибкость и адаптируемость

• Сосредоточьтесь на видении, а не на процессе — Конкретизируйте цели в контракте и укажите невыполненные задания для подробного определения объема работ
• Установите регулярные процессы обратной связи — укажите цикл спринта вместе с встречами для обзора и уточнения невыполненных работ.
• Укажите правила взаимодействия — Определите роли и процессы для предоставления обратной связи, принятия работ, уточнения невыполненных работ,
  

  Включите язык для управления продлением контракта

Гибкое управление контрактами для снижения рисков

Agile-контракты сопряжены с некоторыми неотъемлемыми рисками. В основном это вызвано двумя причинами:

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

Тогда каковы возможные решения упомянутых выше рисков? Что ж, в гибком управлении проектами риски можно снизить разными способами. Вот некоторые из разрешений:

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

Также прочтите: Факторы для выбора правильного метода гибкой разработки

Шаблон Agile-контракта

Шаблон гибкого контракта должен включать все критерии, указанные в характеристиках гибкого контракта.Ожидается, что стандартный шаблон контракта Agile будет включать все разделы, указанные в таблице ниже.

Sr №	Описание
1	Определения и толкования
2	Проектный подход
3	Услуги
4	ТЭО
5	Фаза фундамента
6	Планирование проекта
7	Эволюционная фаза развития
8	Этап развертывания
9	Процесс управления изменениями
10	Руководители проектов
11	Персонал
12	Зарядов
13	Конфиденциальность
14	Защита данных
15	Гарантии
16	Интеллектуальная собственность
17	Возмещение ПИС
18	Ограничение ответственности
19	Страхование
20	Условия и прекращение действия
21	Разрешение споров
22	Уведомления
23	Общие положения Определения Техническое задание Определение архитектуры решения Определение подхода к разработке Определение управленческого подхода План доставки Зарядов Роли и ответственность

Итог

Гибкое управление контрактами следует подходу, основанному на методологии гибкой разработки.

No related posts.