Выявление требований: метод гипотез
Оптимальные решения неверных проблем никогда не позволят вам достичь желаемых результатов в бизнесе. Тем не менее, проекты по созданию ПО нуждаются в расширении сферы своего применения и должны быть нацелены на поиск правильных задач, а не только на работу по их разрешению. Странным остается тот факт, что большинство методологий разработки программного обеспечения до сих пор ориентированы только на создание новых возможностей и функций. В то время как основная сложность заключается не в создании ПО как такового, а в выявлении задач, требующих решения. Мы хотим создавать то, что можно будет продать, а не продавать то, что мы можем создать! Для того чтобы справиться с этой задачей, необходимо ввести искусство проверки гипотез в арсенал разработчика технических требований. Проверка гипотез пришла к нам из мира науки и представляет собой метод объективного определения достоверности неопределенных возражений. Затем, путем определения и построения наименьшего возможного продукта и предоставления его в качестве проверки гипотезы, мы сможем получить больше информации о наших клиентах и избежать нерационального использования ресурсов, выделяемых на разработку бесполезных продуктов. В свою очередь, это позволит нам сосредоточить наши усилия на развитие тех проектов, которые позволят достичь желаемых результатов в коммерческой деятельности. Проверка гипотезБизнес-модель отображает стремление компании предоставить своим клиентам потенциально выгодную фичу, заинтересовать их в ее приобретении и трансформировать этот параметр в чистую прибыль. В процессе своей разработки любая бизнес-модель представляет собой всего лишь цепочку гипотез о причинно-следственных связях, обуславливающих долгосрочный коммерческий эффект. Расчеты на бумаге могут выглядеть впечатляюще, а в разработку самого проекта могут быть инвестированы колоссальные усилия, но все это еще не является стабильной платформой для создания новых направлений в бизнесе. Тем не менее, модели высокого уровня поразительно часто воспринимаются в качестве весомых аргументов, в то время как на самом деле они являются "terra incognita" и нуждаются в поэтапном тестировании. Проблема заключается в том, что люди склонны придерживаться своих убеждений, а впоследствии оправдывать и обосновывать их полным арсеналом интеллектуальных причин, убедительных аргументов и рациональных объяснений. На самом деле нам просто безумно сложно расстаться с полюбившимися когда-то идеями. Возникнув в материях мира науки, система проверки гипотез является неотъемлемой частью научного метода. Научный метод гарантирует, что любое возражение может перейти в разряд фактов только в том случае, когда степень его обоснованности станет целесообразной для выдвижения общего мнения. Стадии процесса использования научного метода просты, но эффективны:
Хотя разработка программного обеспечения относится больше к творческому процессу, чем научному, все же, применяя на практике основы научного метода, мы сможем создавать продукты с большей степенью соответствия требованиям современного рынка. Для того чтобы программное решение не просто считалось умной идеей, а могло быть реализовано в реальных рыночных условиях, мы должны подтвердить следующие общие гипотезы: Гипотеза 1: Люди испытывают эту проблему Как проверить: Для того чтобы ответить на подобный вопрос, часто применяется предварительное изучение ситуации и маркетинговые исследования. Привлечение большого количества людей в исследовательскую группу и внедрение усовершенствованных методов исследования обеспечивают большую степень уверенности в полученных результатах. Гипотеза 2: Наше решение направлено на устранение этой проблемы Как проверить: Если проблема четко определена, то системное тестирование сможет оценить правильность возражения путем его проверки по отношению к указанным требованиям. Гипотеза 3: Люди будут использовать наше решение Как проверить: Создайте наименьшую возможную модель и предоставьте ее клиентам в качестве проверки гипотезы.  Большинство проектов проверяют гипотезы первого типа. Технико-экономические обоснования и маркетинговые исследования, проведенные перед инвестированием в какой-либо проект, являются действенной гарантией того, что излишние ресурсы не будут потрачены на развитие бесполезного продукта. Как правило, во всех проектах осуществляется проверка гипотез второго типа. Это как раз тот случай, когда в игру вступает обычный процесс функциональной верификации. Данный тип тестирования относительно легок в исполнении. Далеко не во всех проектах создаются и распространяются уменьшенные версии продукта с целью отслеживания и последующей работы в соответствии с рыночными показателями, а, следовательно, у них нет ни малейшего представления о коммерческом эффекте до завершения работы над продуктом. К этому времени все ресурсы уже будут потрачены. Разработчики технических требований довольно часто серьезно вовлечены (или должны бы были быть вовлечены) в процесс оказания помощи тестировщикам в разработке тестов на функциональную верификацию. Эти тесты, несомненно, важны, но они позволяют оценить правильность системы только с точки зрения эксплуатационного качества, в то время как существует также необходимость оценить, насколько охотно люди будут покупать, подписываться или использовать этот продукт. Это именно тот случай, когда проверка гипотезы имеет значение, и разработчики технических требований должны быть не просто глубоко вовлечены в процесс их создания, а являться их движущей силой. Читайте продолжение: Выявление требований: как проверять гипотезы -- Автор: Mats Wessberg Оригинал статьи: http://re-magazine.ireb.org/issues/2014-[...]-learning-to-fly/think-like-a-scientist/ |
Сертифицированные курсыАндрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.
Еще интересные статьи на эту тему:
|
