Как получить конкурентное преимущество
Большинство ответов на запросы предложений состоят из заявки, даты исполнения обязательств, квалификации сотрудников и компании, перечисления предыдущих аналогичных контрактов и опыта, используемой методологии разработки и плана в виде высокоуровневых и низкоуровневых диаграмм Ганта. План показывает, какая работа будет выполнена, позволяет определить требуемых сотрудников и оценить стоимость. Чтобы предоставить эту информацию, необходимо проанализировать запрос потенциального клиента, полностью понять и учесть все требования и разработать предварительную архитектуру системы. Когда для участия в конкурсе предложений по договорам с фиксированной ценой и датой используется скрам, эти требования лягут в основу новой части заявки – бэклога продукта. Он позволит потенциальному заказчику увидеть не только то, что все требования были поняты, но и что компания-исполнитель понимает приоритет требований в создании ценности для бизнеса. Наиболее ценные требования, помогающие решить проблемы клиента, окажутся в верхней части списка с высокими приоритетами, а менее полезные требования – в нижней части.
Подавшая заявку фирма покажет клиенту, что она подготовила список требований, упорядоченный в соответствии с ее оценкой ценности и важности функциональных возможностей для бизнес-потребностей клиента. Затем фирма-претендент может сказать, что она произвела такой анализ, потому что ее процесс разработки отличается от процесса большинства других компаний, предоставляющих профессиональные услуги. Вместо поставки системы целиком ближе к дате контракта, она будет наращивать возможности системы инкремент за инкрементом. Фирма предпочитает подход, при котором команда разработки может не реже раза в месяц показывать заказчику то, что она создала за прошедший период, чтобы убедиться, что находится на верном пути и отвечает запрошенным потребностям. Каждый месяц команда фирмы собирается вместе с клиентом и инспектирует только что созданную функциональность.
Далее фирма-кандидат может указать на дополнительные преимущества такого подхода. Поскольку команда разработки превращает самые важные требования в бизнес-функциональность итерациями, если из-за меняющихся рыночных условий заказчик захочет изменить какие-то требования более низкого приоритета, то фирма сможет пойти на это без дополнительных бюрократических ограничений. В ходе работы по проекту команда не будет прикладывать усилия к требованиям внизу списка, пока не подойдет их очередь. При замене нетронутых требований никакая работа не окажется потерянной, а значит, клиент не потратит деньги на работу, ставшую ненужной.
В качестве заключительного аргумента фирма-претендент может объяснить, что многие ее клиенты получили всю изначально ожидаемую бизнес-ценность задолго до реализации всех требований. Следуя правилу 80/20, они получили 80 % выгод проекта от всего лишь 20 % функциональности. Требования с самым низким приоритетом часто оказываются лишними. Фирма предоставит заказчику возможность отказаться от дальнейшей работы раньше даты окончания контракта, если он считает, что получено достаточно пользы для бизнеса. Разумеется, придется выплатить неустойку, но это будет дешевле, чем реализация и внедрение ненужных требований.
Когда следует проигнорировать это конкурентное преимущество
Чтобы выиграть в конкурсе и получить контракт с фиксированными датой и ценой, применяющая скрам фирма может использовать все перечисленные конкурентные преимущества, если потенциальный клиент открыт к обсуждению. Некоторые клиенты будут заинтригованы. Другим не понравится такой подход. Третьи не будут знать, как его обсуждать. На семинаре министерства обороны США в 2002 году я был участником дискуссии об этом подходе. В конце обсуждения специалист ВВС США по контрактам сказал: «Я даже не знаю, о чем вы, коллеги, говорили. Если бы вы предоставили мне материалы, поясняющие это, я отклонил бы вашу заявку по причине несоответствия критериям. Специалисты по контрактам ВВС и других ведомств проходят формальную, строгую подготовку, и ничто из изучаемых тем даже не намекает на то, о чем вы говорили». Претендуя на контракт с фиксированными датой и ценой, вы можете использовать скрам для получения дополнительных преимуществ, но только если ваша аудитория знает, как слушать, и хочет слушать.
Приложение Д
Модель зрелости возможностей создания ПО (CMMI)
CMMI–Capability Maturity Model Integration, набор моделей зрелости возможностей создания ПО, или «моделей полноты потенциала», – это набор моделей эволюционного развития способностей компании разрабатывать программное обеспечение.
В 1986 году Билл Кертис и Марк Полк из Института программной инженерии (Software Engineering Institute, SEI) при Университете Карнеги – Меллона
[25] начали всесторонний обзор зрелости процессов разработки программного обеспечения, чтобы впоследствии улучшать их, и в 1991 году впервые опубликовали CMM, которая, постоянно дорабатываясь, в 2009 году была переименована в CMMI.
CMMI состоит из пяти уровней с номерами от одного до пяти. Первый уровень означает, что организация не имеет определенного, повторяемого или улучшаемого подхода к созданию программного обеспечения. Фактически разработчики самостоятельно прокладывают свой путь к решению. На пятом уровне организация имеет определенный, повторяемый и улучшаемый набор методов для разработки программного обеспечения. Организация первого уровня считается незрелой, организация пятого уровня – зрелой. На каждом уровне методы, которые следует использовать, определяются как ключевые процессные области (КПО). Если организация считает, что полностью реализовала КПО на определенном уровне, она может привлечь оценщика. Если организация соответствует требованиям, ее сертифицируют. Сертификация – большое дело, потому что некоторые компании и правительственные агентства не нанимают фирмы, не сертифицированные как минимум на уровне CMMI 3.
CMM в MegaFund
Я уже рассказывал о MegaFund в третьей, пятой и девятой главах. Компания потратила три года и более $40 млн на совершенствование своих подходов к разработке программного обеспечения, пока не была сертифицирована на уровне CMM 3. На этом уровне MegaFund не только обладала стандартизированным подходом к управлению совершенно любым проектом разработки программного обеспечения, но также могла формально определять эти методы. В девятой главе мы рассмотрели, как компания MegaFund масштабировала проект, чтобы быстрее реализовать для клиентов возможность управлять счетами с помощью телефона и через интернет.
К сожалению для MegaFund, компания не определила практики, позволяющие в важном проекте c жесткими сроками автоматизировать нечеткие требования к передовым и непроверенным технологиям, как это описано в восьмой главе. Когда MegaFund начала использовать скрам в этом проекте, он буксовал уже более девяти месяцев, а участники команды безуспешно пытались преодолеть процессуальные и бюрократические препоны, которые CMM третьего уровня наложил на деятельность в неопределенных и непредвиденных обстоятельствах. Я получил неблагоприятное впечатление от CMM в этом проекте и других компаниях. Однако меня все чаще спрашивали, что я думал о CMM и как эта модель связана со скрамом. Поняв, что мне нужны дополнительные информация и знания, я организовал встречу с Марком Полком в Институте программной инженерии осенью 2002 года.
