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

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

редактировать:

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

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

Два слова: пользовательские истории.

Я узнал , что самый быстрый способ помочь клиенту Получить Clue®, чтобы иметь их поговорить со мной через историю пользователя для каждой функции или страницы , что они хотят. Происходит несколько вещей, в том числе:

1. Они должны думать о том, что, черт возьми, должна делать эта страница / функция.
2. По мере того, как вы будете просить все больше и больше подробностей («а потом? ... и потом? ...»), они начинают понимать, что все это не произойдет, если в игру вступят и полетят Магические Космические Обезьяны ™. это на выходных.
3. Они становятся настоящими партнерами в процессе создания. Это означает, что они поймут, почему изменение их мнения о том, что уже завершено на 80%, приведет к a) задержке графика и b) увеличению стоимости.

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

При обсуждении вопроса о стоимости и времени производства попросите ранжировать требования («должен иметь», «должен иметь» и «приятно иметь»), чтобы минимальный жизнеспособный набор функций, которые были бы важны, был «must have» в версии 1, затем поместите оставшуюся часть требований в наборы невыполненных заданий, которые могут быть выполнены в виде спринтов после первой версии. Надеемся, что второстепенные «приятно иметь» попадут в конец пакета, и к тому времени, когда вы доберетесь до тех спринтов, новые, более важные (из реального опыта работы с продуктом), будут всплывать наверх.

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

Редактировать, чтобы ответить на OP. Редактировать: чтобы убедить клиента, почему стоит выпустить ранний минимально жизнеспособный продукт, объясните, что, пока продукт не используется реальными пользователями, трудно определить, будет ли он успешным (особенно с точки зрения удобства использования). Если клиент не решается выпустить ранний продукт для всей своей пользовательской базы, рекомендуйте сделать «ограниченную бета-версию», когда она доступна только для целевого подмножества их клиентов. Скажите им, что обратной стороной этого подхода является длительный, дорогостоящий цикл разработки с поздним определением, что продукт непригоден для использования. 37 Сигналов дали пару хороших отзывов об этом: Getting Real и Rework . Getting Real доступен в сети бесплатно.

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

Это не всегда проблема

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

Что делать, если это проблема?

Допустим, вы не в такой редкой ситуации. В этом случае вы захотите устранить два основных недостатка списка желаний, как указано ниже:

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

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

Как вы это исправите?
Как говорит Мэтью Флинн в своем ответе - начните с того, чтобы клиент расставил приоритеты в соответствии с требованиями. Это не всегда легко, но заставляет их это делать. При необходимости используйте фразу «Если кто-то приставил пистолет к вашей голове, какое единственное требование вы бы выполнили?». Во время этого процесса вы часто обнаруживаете, что клиент на самом деле не имеет четкого представления о том, что означают индивидуальные требования. В этом случае сделайте то, что предлагает Питер Роуэлл, и заставьте клиента работать с пользовательскими историями. Вы и клиент начнете гораздо лучше понимать проблему и требования, а затем вы сможете вернуться к расстановке приоритетов. Повторите эти шаги так часто, как вам нужно, пока вы не почувствуете себя комфортно, что вы знаете достаточно, чтобы решить проблему клиента .

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

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

Подобно тому, что предложили другие люди, но немного по-другому, я бы предположил, что все, что клиент может быть действительным, но они должны приоритизировать. Какой пункт должен быть сделан первым. Какой пункт нужно сделать вторым. Самое главное, что если у вас не хватит времени, какие предметы он причинит меньше всего вреда. Расставьте приоритеты по каждому пункту от 1 до 732 (или как угодно) и заполните их в указанном порядке.

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

Я видел работу "У меня все это есть" в 2 случаях. В одном крупном финансовом клиенте (использующем водопад всех вещей) было заменено 40 различных систем (наша компания сделала одну из 40), и они были введены в эксплуатацию одним махом. Интеграционное тестирование и общение были огромными проблемами. По моим оценкам, они потратили около 100 тыс. Долл. США в день на конференц-звонки (если учесть тарифы всех участников на звонки). В обоих случаях потребовались сильные переговорщики, чтобы составить список того, что должно было быть доставлено, а затем прибили всех к ногам. Не было никакого перемещения ворот, никаких пересмотров. Обе работы закончились вовремя и по спецификации. Один был за бюджет, другой за бюджет. Для этого вам нужны очень хорошие менеджеры проектов, которые знают, что могут сделать их команды (например, кто может сказать, что функция Q занимает 3.

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

Краткий ответ: я бы послушал своего клиента и нашел бы подход к ним среднего уровня.

Я бы посоветовал выслушать клиентов и в зависимости от их бюджета и сроков разделить проект на этапы (выпуск, выпуск2 и т. Д.).

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

Таким образом, определение объема работ и результатов - это путь :)

Как утверждают другие ответы, расстановка приоритетов очень важна. Удобный способ сделать это через метод MoSCoW . Но вы можете начать с деления всего списка, иначе сам список функций создаст вам (или вашему клиенту) проблемы с пониманием :)

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

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

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