Возможно, вы спрашивали себя, совместима ли концепция заключения контрактов с гибким способом работы. Возможно, вы задаетесь вопросом, почему вас вообще должны волновать контракты. Что ж, вас должны волновать контракты, если вы являетесь владельцем продукта. Оказывается, предприимчивым владельцам продуктов приходится что-то делать с контрактами чаще, чем им хотелось бы. Нечасто случается, что владелец продукта создает контракт, и маловероятно, что владелец продукта сможет управлять деталями контракта. Однако регулярно случается, что владельцы продукта влияют на контракты по следующим причинам:
- Они разрабатывают и поставляют продукты (или проекты) для клиентов на основе контракта.
- Они поставляют продукт или услугу третьей стороне и должны соответствовать соглашению об уровне обслуживания, соглашению об уровне опыта или другой форме контракта.
- Они приобретают компоненты для своих продуктов или услуг у третьей стороны.
- Их продукт в значительной степени представляет собой контракт, и/или их продукт представляет собой набор положений, правил и соглашений. Например, подумайте о менеджерах по продуктам, которые управляют страховыми продуктами. Обычно они определяют полисы страховых продуктов и/или управляют ими. Они играют важную роль в определении договорных границ.
Как владелец продукта или менеджер по продукту, маловероятно, что вы тратите большую часть своего времени на управление контрактами или их создание. Создание контрактов и управление ими обычно входит в обязанности юридических отделов и/или отделов закупок. В конце концов, они эксперты.
В вашей Scrum-команде также есть эксперты, обычно эксперты в области пользовательского опыта (UX), кодирования, архитектуры, безопасности, тестирования, дизайна и т.д. Эти эксперты также могут быть экспертами в области продаж, маркетинга, бизнеса или операций. Подобно тому, как эксперты в вашей Scrum-команде нуждаются в некотором руководстве от владельца продукта относительно видения, стратегии и целей, команда юристов также нуждается в руководстве. Для вас было бы разумно принять участие, потому что, как владелец продукта, вы можете влиять на то, как будет составлен контракт с поставщиком. По этой причине мы считаем, что вы должны обладать некоторыми базовыми знаниями о заключении контрактов. Вам не обязательно быть экспертом, но возможность эффективно сотрудничать с юристами очень полезна.
Что такое Контракт?
Контракт - это юридический документ, в котором излагается и разъясняется официальное соглашение между двумя различными субъектами, которыми могут быть отдельные лица, группы людей или организации. Контракты часто существуют потому, что две стороны предпринимают совместные усилия. Будь то отношения между заказчиком и поставщиком, партнерство или что-то еще, это совместные усилия. Когда отдельные лица, организации или другие стороны объединяют усилия и начинают сотрудничать, создается зависимость друг от друга, и все стороны хотят фиксировать и документально оформлять свои обязательства. Контракты создаются для заключения соглашений, например, об объеме работ, взаимных усилиях, условиях оплаты и других вопросах. Контракты помогают вам выявить неявные допущения и предназначены для выявления рисков и управления ими. В конечном счете, контракты - это просто решение для управления рисками для вовлеченных сторон.
Традиционно многие контракты, используемые при разработке продукта, способствуют последовательному циклу разработки. Многие из этих контрактов включают исследование, определение, определение объема, разработку продукта, тестирование, поставку и техническое обслуживание. Другими словами, многие контракты, использовавшиеся в прошлом, способствуют более традиционному каскадному способу работы. В строительных проектах это может хорошо сработать, но в большинстве сложных проектов при таком подходе риски возрастут, как и шансы на провал.
Итак, что помогло бы сделать контракты более гибкими?
К сожалению, такого понятия, как “гибкий контракт”, не существует. Не существует единого способа создания гибкого контракта, потому что используется очень много различных типов контрактов. Однако существуют положения контракта или темы, которые обеспечивают гибкость или маневренность, если хотите. Вместо того чтобы сосредотачиваться на последовательной доставке, сосредоточьтесь на итеративной доставке. Досрочное расторжение контракта не является нарушением контракта — это желаемая ситуация (при условии, что мы обеспечили ценность). То, как мы сотрудничаем, создаем прозрачность и получаем обратную связь, может быть включено в контракт, чтобы позволить нам более эффективно применять эмпирический подход (и быть более гибкими). В контракте обычно описываются элементы, подобные показанным в таблице 27.1.
Найдите минутку, чтобы просмотреть пункты, перечисленные в левой колонке. Эти пункты касаются сотрудничества между обеими сторонами. Они описывают, как обе стороны работают вместе, и в качестве основы для этой части можно использовать фреймворк, подобный Scrum framework. Scrum — это оптимизация ценности, минимизация рисков и решение сложных проблем посредством эффективного сотрудничества - так почему бы не использовать Scrum в качестве основы?
Элементы, перечисленные в правой колонке, не обязательно являются темами, для решения которых Scrum framework может быть очень полезен. Вы можете возразить, что Scrum предлагает спринты максимальной продолжительностью в один месяц, так что это можно использовать для определения сроков. Бюджет может быть связан с расходами на персонал в Scrum-команде. Вероятно, вы можете использовать значения Scrum для принятия некоторых решений. Но Scrum помогает меньше на правой стороне, чем на левой.
Следующий отрывок взят из “Учебника по гибким контрактам” Тома Арбогаста, Крейга Лармана и Баса Водде. Арбогаст - юрист, и понимание точки зрения юриста на заключение контрактов очень полезно, когда мы говорим о контрактах. Мы можем порекомендовать вам прочитать эту статью, чтобы узнать больше о контрактах, поскольку эта книга предлагает только введение в тему. Мы сочли следующее наиболее важным для вас:
Профессиональные юристы устроены по-другому. Эта перестройка начинается с того момента, как студент поступает в юридическую школу. Концепции профессиональной ответственности и адвокатуры укореняются в образе мышления юриста. Юристы обучены действовать в соответствии с юридическими обязанностями для продвижения интересов своих клиентов и защиты их от всех подводных камней, видимых или невидимых. Как вы определяете интересы клиента? Клиент, вероятно, просто сказал бы об успешной реализации проекта. Профессиональный юрист скажет, что он успешен, если он в максимально возможной степени защищает своего клиента от разоблачения и риска, в то же время продвигая конечную цель контракта/проекта.
.. .
Третья ценность манифеста Agile - сотрудничество с клиентами, а не переговоры по контракту. Естественно, при первом прочтении юрист по контрактам примет это к сведению, отреагирует и, возможно, подумает: “Это приятно, но я здесь для того, чтобы обеспечить надлежащую защиту моего клиента. Она может думать все, что ей заблагорассудится, но я готов поспорить, что она не сказала бы, что ценит сотрудничество больше, чем переговоры по контракту, когда все пойдет наперекосяк и будет подан иск”. Юрист должен учитывать "немыслимое" в договорных отношениях и обеспечить основу — выраженную на языке контракта — для борьбы с неприятными последствиями. Юристы имеют образование и большой опыт в том, что происходит, когда отношения ухудшаются и доверие разрушается.
Кто берет на себя риск?
Контракты используются как способ управления, ограничения и смягчения рисков, особенно риска неполучения желаемого (или согласованного), что позволяет любой из сторон расторгнуть контракт. Для управления этими рисками часто используются три основных типа контрактов, показанных на рисунке 27.1.
Первый вариант - это контракт с фиксированной ценой (который обычно также включает фиксированный срок и фиксированный объем). При использовании этого контракта в отношениях между заказчиком и поставщиком поставщик несет все риски. Если клиент изменит свое мнение, если в процессе разработки продукта возникнут сбои, если возникнут проблемы в технологии или иным образом, поставщик несет этот риск. На практике это означает, что поставщики, скорее всего, добавят (потенциально огромный) фактор риска к своей цене. Если вы работаете со многими субподрядчиками, каждый из которых опасается риска, вы можете в конечном итоге заплатить очень высокую цену. Поскольку маловероятно, что риск материализуется у всех сторон, заключивших субподряд, вы можете сами пойти на больший риск.
Это подводит нас ко второму варианту, который представляет собой контракт на поставку времени и материалов (T&M). Этот тип контракта часто выбирается, когда между заказчиком и поставщиком существует большое доверие. Клиенты доверяют поставщику в том, что он сделает все возможное, учитывая, что любая неопределенность в прогнозе теперь становится риском для клиента. Это часто имеет место, когда продукт или услуга являются товаром или если взаимные отношения гарантируют такой уровень доверия.
Контракты T&M могут стать дополнительной проблемой, когда вы применяете профессиональный Scrum в своих командах. Часто они рассчитаны на почасовую или дневную оплату. Если вы хотите применять Scrum и эффективно сотрудничать как Scrum-команда (возможно, состоящая из людей из нескольких поставщиков), почасовая или дневная оплата может способствовать неэффективному поведению в команде. Кроме того, часы, потраченные на постоянное совершенствование и обмен знаниями, могут показаться в глазах договаривающейся стороны менее ценными, чем часы, потраченные на создание результата. Итак, в качестве небольшой альтернативы почасовым контрактам вы могли бы рассмотреть вариант с оплатой за спринт. Оплата поставщикам за спринт позволяет им сосредоточиться на создании дополнительных затрат, а не на максимизации количества часов (и, следовательно, их доходов). Это может помочь больше сосредоточиться на выполнении поставленных задач.
Третий вариант - это форма контракта, которая заключается между фиксированной ценой, временем и материалами. Этот вариант называется разделяемым риском. В случае контракта с разделяемым риском обе стороны несут часть риска, часто связанного с вознаграждением. Типичным для этих контрактов является то, что они смещают акцент с крупных платежей на более прогрессивную схему оплаты.
Двухэтапные контракты
Другим способом контроля рисков является использование двухэтапного контракта. Контракты могут состоять из двух (или даже более) этапов. Использование нескольких этапов в контракте помогает снизить риски или отсрочить принятие рисков при участии в новых крупных начинаниях, таких как начало разработки нового продукта.
Самое забавное в создании планов, прогнозов и контрактов заключается в том, что начало проекта обычно не лучшее время для создания плана, прогноза или контракта. В начале нового проекта мы знаем о нем меньше всего, и риски обычно больше, чем в конце. В идеале, тогда мы хотели бы создать контракт в конце проекта, потому что на этом этапе мы точно знаем, что требуется проекту. Это, конечно, глупая мысль, но что, если бы мы могли предпринять меньшие шаги или создать меньшие этапы контракта, или фазы? Разве это не было бы более эффективно для управления этими рисками?
На рисунке 27.2 представлен конус неопределенности. Он иллюстрирует, что наши оценки в начале проекта могут быть отклонены в 4 раза из-за всех неизвестных и неопределенностей. В большинстве случаев мы (как заказчик) хотим, чтобы наши поставщики несли риск недооценки сложности и усилий, необходимых для реализации проекта. Однако, если мы хотим, чтобы наш поставщик взял на себя все риски, мы, скорее всего, заплатим гораздо больше “денег за риск”, чем необходимо. Альтернативным подходом к установлению фиксированной цены является использование двухэтапного контракта.
На первом этапе, или фазисе, этого контракта мы должны сосредоточиться на создании первого продукта, чтобы снизить риск. Мы также могли бы разработать видение и стратегию продукта, определить некоторые цели продукта, создать первоначальный список невыполненных работ по продукту или дорожную карту и провести ряд экспериментов по снижению технических рисков (можем ли мы это создать?), бизнес-рисков (хотят ли этого клиенты?) и социальных рисков (может ли эта команда работать вместе и построить что-то ценное?).
В какой-то момент (точка фиксации на рис. 27.2) клиент обретет достаточную уверенность в том, что этот новый продукт или инициатива могут быть успешными и приносить достаточную ценность для ведения устойчивого бизнеса. Затем заказчик может принять решение продолжить финансирование проекта, но снижение риска делает другие формы контрактов менее проблематичными. Другими словами, сотрудничающие стороны теперь могут перейти, например, на форму контракта T&M, где заказчик платит за спринт и берет на себя больший риск.
Двухэтапный контракт также можно использовать и наоборот. Представьте себе клиента, который не очень гибок, и он хочет, чтобы вы взяли на себя все риски. Вы могли бы создать двухэтапный контракт и в этом случае. На первом этапе объем, сроки и цена будут фиксированными. Однако на этом первом этапе у клиента, несомненно, появятся новые идеи и пожелания, особенно если вы пригласите его на обзор Sprint, где он получит в свои руки постепенно разрабатываемый продукт. Однако внесение каких-либо изменений в область применения на первом этапе запрещено! Чтобы изменить область применения, вам нужно перейти к этапу 2.
Таким образом, единственный способ для заказчика воплотить свои новые идеи в рамках проекта - это перейти к варианту контракта T&M (этап 2). На этапе 2 клиент может изменить свое мнение и добавлять новые функции в любое удобное для него время (предпочтительно, однако, не в рамках спринта), что обеспечивает гораздо большую гибкость. Однако заказчик никогда не сможет вернуться к этапу 1 или форме контракта с фиксированной ценой, потому что, ну, мы все знаем, что происходит с проектами с фиксированной ценой, объемом и крайними сроками, верно? Кроме того, клиент, скорее всего, предпочтет перейти ко второму этапу, как только между сторонами установится достаточное доверие.
Joe’s Bucket
Контракт Joe's bucket является альтернативой двухэтапному контракту, как показано на рисунке 27.3. В этой форме контракта контракт описывает ожидаемый объем или цель, для достижения которой выделяется бюджет. Он также содержит два “блока”, которые можно использовать для устранения неожиданностей и непредвиденных проблем. Каждая сторона управляет своим бюджетом на непредвиденные работы. Клиент управляет буферным бюджетом на случай изменений объема работ. Поставщик обычно управляет буферным бюджетом на случай недооценки объема работ и непредвиденных задач и мероприятий.
Если корзины не используются во время выполнения задания, они приносят дополнительную прибыль обеим сторонам. Однако большее преимущество заключается в том, что вам не нужно будет пересматривать объем и цену каждый раз, когда что-то получается не так, как ожидалось.
Хотя вы, возможно, не слышали, что это называется "Корзина Джо", эта форма заключения контракта часто используется, и вы, вероятно, знакомы с концепцией. Это очень похоже на резервирование денег при ремонте вашего дома. Это немного дополнительных денег, зарезервированных на случай непредвиденных событий, работы или проблем.
Деньги ни за что
Ответственность владельца продукта заключается в максимизации ценности продукта. Один из способов максимизации ценности - прекратить инвестировать в продукт, когда он “достаточно хорош”. Когда бы это ни произошло, решать владельцу продукта, и это во многом связано с законом убывающей отдачи. Этот закон гласит, что в какой-то момент прикладывание одинаковых или большего количества усилий не приводит к равному результату. Другими словами, наступает момент, когда мы инвестируем больше денег, чем получаем взамен. Такой ситуации вы, как владелец продукта, хотите избежать.
Но как? Как мы можем остановить проект, если у нас есть контракт на весь проект? Контракт обычно создается для выполнения всего проекта — на 100 процентов. Кроме того, поставщику нужно будет найти новый проект для работы и перенаправить своих людей и материалы на другую работу. Поставщик, вероятно, рассчитывает на получение доходов от проекта.
Чтобы эффективно справиться с этой ситуацией, вы можете применить концепцию "деньги даром" (рис. 27.4), согласно которой поставщик получает компенсацию за досрочное расторжение контракта. Они получают процент от оставшегося бюджета, который из-за досрочного расторжения не будет потрачен на проект. Это также выгодно заказчику, потому что он экономит деньги, поскольку ему не нужно оплачивать весь бюджет, который был выделен на последнюю часть проекта. По сути, заказчик экономит часть бюджета, а поставщик получает деньги ни за что. Но подождите, разве в этой песне не было другой строчки?
Меняйте бесплатно
Контракт с фиксированной ценой, объемом и сроком действия может создать проблему как для заказчика, так и для поставщика, поскольку новые идеи, пожелания и потребности обычно возникают в процессе разработки продукта. Чтобы позволить заказчику изменить свое мнение, запросить новые функции, изменить порядок выполнения работ и, таким образом, масштаб, может быть полезна концепция change for free (см. рис. 27.5). Мы считаем, что эта концепция обязательна для любого проекта, разрабатываемого гибким способом.
Бесплатное изменение сокращает общий объем работ по разработке, но позволяет сторонам менять местами элементы одинакового размера. Клиенты могут добавлять новые идеи в область для следующей итерации или спринта, если продается что-то еще равного размера. В этом смысле это в точности похоже на гибкость, которой мы обладаем от спринта к спринту. Это похоже на то, как разработчики извлекают элементы из спринта во время планирования спринта.
Элементы гибкого контракта
Вы ознакомились с несколькими вариантами контрактов, техниками и принципами, которые могут помочь вам лучше адаптироваться к изменениям и гибкости. Помимо различных форм контрактов, вы также можете включить статьи — или пункты — которые описывают, как сотрудничать гибким способом. На рисунке 27.6 показаны различные элементы, которые следует учитывать в контрактах, которые могут помочь вам сделать контракт более благоприятным для гибкого способа работы.
На рисунке, конечно, не описаны фактические статьи или оговорки контракта. Вам следует описать статьи, которые вы хотели бы видеть в контракте. Затем ваш юридический отдел может помочь вам воплотить ваши потребности в договорных положениях и условиях, которые будут иметь силу в суде (хотя весь смысл тесного сотрудничества гибким способом, очевидно, заключается в том, чтобы никогда не обращаться в суд).
Если вы хотите получить преимущество или ознакомиться с некоторыми примерами, существуют различные книги и статьи об гибких контрактах, такие как Agile Contracts: Создание успешных проектов и управление ими с помощью Scrum.
Ключевые уроки и инсайты
В этой части вы рассмотрели, как управление часто оказывает значительное влияние на способность владельца продукта или менеджера по продукту эффективно сотрудничать с другими людьми и другими сторонами. Вы узнали, что управление включает в себя множество различных элементов, начиная от документации и заканчивая управлением выпусками, от контроля качества до составления бюджета и от управления инцидентами до заключения контрактов. Управление - это просто множество различных элементов, которые предписывают, как все делается и контролируется в вашей организации. Из "Понимания управления" вы узнали, как составление бюджета может осуществляться другими, более гибкими способами, позволяющими владельцам продуктов и менеджерам по продуктам более эффективно сотрудничать. Затем вы изучили практики и концепции, позволяющие по-другому подходить к заключению контрактов в гибких организациях, обеспечивая большую гибкость, маневренность, нацеленность на ценность и сотрудничество между сторонами.
В конечном счете, продукты-победители создаются не (просто) владельцами продуктов или менеджерами по продуктам. Продукты-победители создаются командами-победителями, людьми, которые мотивированы и сосредоточены на общем видении/цели, открыты и прозрачны друг с другом и работают вместе как единое целое. Следовательно, чтобы создавать выигрышные продукты на рынке, владельцам продуктов и менеджерам по продуктам необходимо стать сильными сотрудниками. Но сотрудничество не ограничивается только командой разработчиков, с которой они работают. Они должны эффективно взаимодействовать с заказчиками, пользователями, множеством различных заинтересованных сторон, а также внешними сторонами. Понимание и применение методов гибкого управления, которые мы рассмотрели в этой части, может просто помочь вам сделать следующий шаг в качестве эффективного сотрудника.