Як продати Agile development клієнтам (водоспад)

Наш магазин розробки дуже хотів би робити більш гнучкі проекти, але у нас є проблеми з залученням клієнтів. Багато клієнтів хочуть бюджету та терміну. Важко продати клієнта за спритним проектом, коли наші конкуренти придумують фіксовані терміни на основі водоспаду та фіксовані ціни. Ми знаємо, що їх фіксовані цифри погані, але клієнт цього не знає. Таким чином, ми в кінцевому підсумку виглядаємо погано для клієнта, оскільки ми не можемо встановити ціну чи термін, але наші конкуренти можуть.

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

Ключовим для цього є використання контракту на підтримку.

В основному, коли ви вперше продаєте клієнта, ви продаєте їх на основі свого досвіду, і ви робите це водоспадом. Це означає контракт, який встановлює сферу застосування та тверду строку. Це те, чого хоче клієнт. Клієнт більш-менш знає сферу застосування. Водоспад працює дуже добре, у фіксованому та визначеному середовищі, я б сказав, що він працює краще, ніж спритний у таких умовах. І в цьому випадку це дає клієнту рівень комфорту, коли схильність нервувати, тому що він ніколи раніше з вами не працював. Це добре, Agile не завжди краще, ніж водоспад.

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

Якщо під час проекту з’явиться зміна, просто відкладіть її для обробки під контактом підтримки. (Якщо припустити, що ця зміна спричинить серйозні зриви для проекту)

Умови контакту з підтримкою такі: " Робота, яка проводиться щогодини, за запитом клієнта, може використовуватися для запитів на зміни або загальної підтримки та обслуговування системи ". BAM! Ви в Agile.

Потім ви можете продовжити розширення контакту підтримки та просто використовувати контакт підтримки як засіб для запуску нових проектів. Крім того, якщо ці години придбані та оплачені заздалегідь , ми зазвичай надаємо клієнтові знижку 15%. Це Win-Win.

Agile не виключає термінів і бюджетів. Якщо я був клієнтом, і я пішов до забудовника, і вони сказали мені, що не можуть дати мені термін або орієнтовну вартість, я б поставив під сумнів їхню розумність. І сказати їм, що вони просто не розуміють, не вийде: їм потрібно вміти складати бюджет і планувати.

Їм не потрібно знати процес розробки. Вони повинні знати, скільки часу піде на розробку функцій і скільки це буде коштувати. Надайте їм число, виходячи з (помилкового) припущення, що їх вимоги є на 100% точними, а коли їх вимоги змінюються, то змініть свої оцінки.

Це дає їм позиції бюджету та дати розгортання, які вони хочуть, а коли зміниться, ваш процес дозволяє виглядати гнучким та пристосованим.

Це здається, що ваші продавці створюють шар недоліків між вашими розробниками та замовниками. Якщо вони давно не продають на ринку ІТ, вони можуть розглядати свою роль як "переміщення товару", тобто отримати підпис на контракті "все, що потрібно". Коротше кажучи, вони мотивовані закрити, незалежно від того, що вони обіцяють. За таких обставин вони збираються відслідковувати мову замовника якомога ретельніше.

Я побитий запис, цитую це, але ось так: ти на операційному столі, і коли ти йдеш під хірурга, каже: «Виведемо тебе звідси вчасно та в межах бюджету». Чудово. Я буду живий?

Якщо ви працюєте над внутрішніми органами бізнесу, чи зупиняєтесь ви в якійсь довільній точці? Зазвичай на додаток впливають сили, ані ви, ані ваш клієнт - це регулювання, діловий клімат, поведінка конкурентів, поява нової парадигми тощо. Якщо ви просто скажете «ми зробимо« річ х »за« ціну у » замовник повернеться через три місяці і скаже - "ну ...". Загалом це означає, що вони знають щось, чого не знали, коли ви погодилися на проект водоспаду.

Що може спрацювати в такій ситуації - це показати вашому власному торговому персоналу, що таке проїзд через каньйон. На кожному кроці трапляються сюрпризи. Неможливо побачити більше, ніж приблизно три місяці, тому якщо клієнт просить проект на 18 місяців, він буде невпізнанним до того часу, коли ви закінчитесь. Тому ваш торговий представник повинен починатися з пошуку фінансової виплати проекту. Чи збільшить це продажі на 10 мільйонів доларів? Якщо так, то чи варто вкласти 2 000 000 доларів, щоб зробити ці додаткові 10 мільйонів доларів? Якщо клієнт і представник відділу продажів сходяться на 500 000 доларів США, то щось може бути не так, і ніхто не може сказати, що це таке - це просто не відчуває себе правильно. Те, що "не відчуває себе правильним", - це зобов'язання робити щось, що ризикує бути марним.

Дві останні моделі реактивних авіалайнерів мали історію снафу. 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 речі - вартість та масштаб часу. І як тільки ти їм це скажеш, вони потім хочуть дешевше і швидше. І ви знаєте чого, ми хочемо все це. Всі вимоги. Ніхто не може чекати або бути рубаним.

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

Вони не створюють програмне забезпечення, вони, як правило, не мають уявлення про те, як це працює напроти гучних слів.

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

Отже, як ви можете змусити свою торгову силу для успішного продажу проекту, який використовує спритні методи розробки, або продукту, який розробляється за допомогою таких методів?

Маючи вашу торгову силу, приводьте клієнта в офіс. Вся суть спритного полягає в отриманні негайного відгуку від клієнта, щоб ви могли виробляти те, що він хоче (і не більше). Приведіть їх, запитайте, що вони хочуть. Через два тижні принесіть їх і покажіть демонстрацію / прототип. Продайте їх на тій взаємодії. Покажіть їм прогрес і поясніть, що саме таку ітерацію ви хочете зробити, щоб вони отримували саме те, що хочуть.

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

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

Інша частина вирішення цього питання - можливо, спробувати використовувати обидва підходи. Використовуйте підхід щодо водоспаду зі старшими керівниками та людьми, що ведуть переговори за контрактами. Наприклад, "система, яка дозволяє клієнтам підтримувати портфелі та приймати інвестиційні рішення, використовуючи пристрої на основі браузера та мобільних телефонів (Apple і Android)." чи щось подібне. Потім використовуйте Agile для розробки команди розробників для більш детальних функцій, наприклад, Створити домашню сторінку, Створити сторінку входу, Створити історію управління Portolio, Створити мобільний вхід тощо.

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

Ви також можете знайти деяку тягу, якщо ваші клієнти люблять тестування. Якісно перевірені продукти можуть бути легшими продажами для деяких клієнтів. Книга, яка мені здається корисною в цій галузі, - це "Агільні тестування" від Едісон Уеслі Прес.

Ви також можете використовувати поточні події для підтримки своєї справи. Наприклад, існуючий (написав це у жовтні 2012 року) сайт охорони здоров’я є чудовим випадком того, як НЕ впоратися зі змінами, необхідними за 2 тижні до початку роботи. Крім того, очевидне перевиробництво, швидше за все, було б краще вирішити більш спритні методи.

Зверніться до попередніх клієнтів, які задоволені вашою роботою. Особливо, якщо вони перетворюють Водоспад на Agile. Принаймні, перетворювачі, які не були вашими клієнтами.

Їхні відгуки (як замовник) будуть переважувати все, що можна сказати. Вони можуть вирішити проблеми та побоювання вашого нового клієнта більше, ніж ви коли-небудь могли.

З точки зору менеджменту, бюджет та терміни є потребою бізнесу у проекті. Вам потрібно переконатися, що ви вирішуєте ці потреби, і якщо ви подивитеся відгуки компанії про перехід, ви помітите, що з’являється безпосередньо. Якщо ви подивитеся на відгуки розробників про перемикання, ви помітите, що часто це не відбувається.