Как продать Agile Development (водопад) клиентам

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

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

Ключом к успеху является использование контракта на поддержку.

По сути, когда вы впервые продаете клиента, вы продаете его на основе своего опыта, и вы делаете это водопадом. Это означает контракт, который устанавливает объем и твердый срок. Это то, что хочет клиент. Клиент более или менее знает сферу. Waterfall работает очень хорошо, в среде с фиксированной и определенной областью действия, я бы сказал, что в таких средах он работает лучше, чем agile. И в этом случае это дает клиенту определенный уровень комфорта, когда склонна нервничать, потому что он никогда не работал с вами раньше. Это хорошо, Agile не всегда лучше, чем водопад.

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

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

Условия обращения в службу поддержки заключаются в следующем: « Работа, выполняемая на почасовой основе, по запросу клиента, может использоваться для запросов на изменение или для общей поддержки и обслуживания системы» . BAM! Вы находитесь в Agile.

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

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

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

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

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

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

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

Что может сработать в такой ситуации, так это продемонстрировать собственному торговому персоналу, что такое проезд через каньон. На каждом шагу есть сюрпризы. Невозможно увидеть более трех месяцев, поэтому, если клиент запрашивает 18-месячный проект, он будет неузнаваем к тому моменту, когда вы близки к завершению. Поэтому ваш торговый представитель должен начать с поиска финансовой отдачи от проекта. Это увеличит продажи на 10 миллионов долларов? Если так, стоит ли инвестировать 2 000 000 долларов, чтобы получить эти дополнительные 10 миллионов долларов? Если клиент и торговый представитель сходятся на обещании в 500 000 долларов, то что-то может быть не так, и никто не может сказать, что это такое - это просто не правильно. «Неправильное чувство» - это обязательство делать что-то, что может оказаться бесполезным.

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

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

Четыре из этих типичных организационных предпосылок изображены ниже:

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

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

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

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

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

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

Обратитесь к таблице ниже для конкретных рекомендаций

Источник - Взаимодействие между линейным водопадом и гибкими подходами Майкл Нир

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

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

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

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

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

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

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

Мы держали их в курсе прогресса и поддерживали очень открытое общение. Они получают отчет о проделанной работе каждые 2 недели: x% баллов за историю, сделанные за y% от расчетного времени, оставляют z% дополнительных баллов за сюжет. У нас было немного трудное начало, но мы смогли догнать оценки к концу проекта, что оставило 100% дополнительных сюжетных моментов, доступных для дополнительной разработки. Клиент был счастлив, потому что он получил все, что ему действительно нужно (и это немного отличалось от его первоначально запрошенных функций, он удалил некоторые и добавил другие).

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

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

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

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

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

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

Они хотят 2 вещи - стоимость и масштаб времени. И как только вы скажете им это, они захотят это дешевле и раньше. И знаете что, мы хотим всего этого. Все требования. Никто не может ждать или быть расколотым.

И как бы мне не нравились продавцы в большинстве слоев общества, не стоит слишком усердно работать с продавцами. Это тяжелая работа.

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

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

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

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

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

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

Другая часть решения этой проблемы, возможно, состоит в том, чтобы попытаться использовать оба подхода. Используйте подход с водопадом вместе со старшим руководством и людьми, ведущими переговоры по контракту. Например, «система, позволяющая клиентам поддерживать портфели и принимать инвестиционные решения, используя как браузерные, так и мобильные телефоны (Apple и Android)». или что-то типа того. Затем используйте Agile для разработки команды разработчиков с более детальными функциями, например, «Создание домашней страницы», «Создание страницы входа», «Создание истории управления Portolio», «Создание мобильной учетной записи» и т. Д.

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

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

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

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

Их отзывы (как клиента) перевесят все, что вы могли бы сказать. Они могут решить проблемы и страхи вашего нового клиента больше, чем вы когда-либо могли.

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