Отношения с клиентами в гибкой разработке

Мой менеджмент только что задал беспрецедентный вопрос в моей (по общему признанию) истории с организацией: «Что мы можем сделать, чтобы помочь вам?»

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

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

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

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

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

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

Процитируйте, как вы это обычно делаете (с отступом), и установите некоторые границы вокруг объема проекта. С этого момента следуйте своей гибкой методологии:

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

Но что более важно:

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

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

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

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

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

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

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

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