Данная статья относится к циклу статей по разработке требований к программному обеспечению. Если вы сразу попали на эту статью, то вам необходимо начать читать с первой. В конце каждой статьи есть ссылка на следующую, поэтому в итоге вы вернетесь сюда.
У нас есть исходные данные, теперь необходимо понять, а что именно мы решаем. Я думаю, что все прекрасно понимают, что решить можно две вещи: проблему или задачу. Но при разработке требований мы в первую очередь решаем проблему, а во-вторых, проблему связанную непосредственно с процессом компании, следовательно, решаем бизнес-проблему.
Определение бизнес проблемы
Бизнес-проблема - это ситуация, возникающая в рамках деятельности организации, которая мешает достижению поставленных целей или приводит к нежелательным последствиям. Она может быть связана с финансовыми трудностями, неэффективными процессами, конкурентным давлением, изменениями в законодательстве или другими факторами, влияющими на бизнес. Решение бизнес-проблемы требует анализа, планирования и принятия конкретных мер для устранения её причин и последствий.
Естественно, в рамках документа о концепции и границах вы рассматриваете лишь те проблемы, которые возможно решить путем автоматизации или создания информационной системы возлагающей на себя ряд задач для устранения проблемы.
Напоминаю, что документ о концепциях и границах читают все, кто участвует в процессе разработки. Поэтому необходимо писать в документе, возможно очевидный для вас вещи, но иногда загадочные для их читателя. Например, о существовании категорий при определении бизнес-проблем.
Если вы до сих пор задаетесь вопросом “а почему я должен задумываться о том, как будет читать этот документ заказчик, если я его пишу для разработчиков?”, то стоит уточнить один очень важный момент.
Вы пишите документ о концепциях и границах в первую очередь для того, чтобы обеспечить процесс разработки в полной мере путем утверждения всех выявленных требований заказчиком. Простыми словами, заказчик должен поставить свою подпись под всем требованиями в данном документе, чтобы в итоге не говорить “вы меня не так поняли, я имел в виду другое”.
Поэтому, заказчик должен ясно понимать все, что написано, т.к. он тем самым подтверждает, что именно это он хочет решить, получить, увидеть и т.д.
Да, конечно, подпись под данным документом не означает, что требования у заказчика могут измениться. Но это уже попадает в категорию дополнительные требования, что оплачивается отдельно. Документ о концепциях и границах позволяет решить следующие задачи:
- Повышает ответственность заказчика при утверждении требований, т.к. он понимает, что любое изменение бьёт по его карману и любое затраченное время на выявленные им дополнительные требования должны быть оплачены;
- Держит всех в единых рамках понимания того, над каким проектом ведется работа: заказчик, системный аналитик, менеджер по продукту, руководитель группы и сами программисты. Все читают один и тот же документ и каждый должен ставить свою подпись в рамках того участка задачи, к которому он имеет отношение;
- Устраняет неявные требования. Другими словами, программисты не должны будут додумывать то, что имел в виду заказчик, который в последствии скажет уже известную фразу “Ой, да я не это имел в виду”.
Возвращаемся к бизнес-проблеме. Как вы поняли они разделяются на две категории. Если говорить простым языком, то речь идет о том, что есть одна большая бизнес-проблема для организации и из неё вытекает ряд других бизнес-проблем.
Когда вы думаете о том, как правильно провести разработку требований к программному обеспечению, то в первую очередь задумывайтесь о том, а точно ли вы смогли определить и выписать бизнес-проблему. Фактически вся дальнейшая разработка требований сводится к тому, что мы решаем ранее определенные проблемы.
Попробую объяснить более точно: определение бизнес-проблемы является фундаментальной частью разработки требований, т.к. всё решение определяется лишь вокруг проблемы. Поэтому для вас задание - внимательно посмотрите на частные бизнес проблемы и напишите в комментариях, что на ваш взгляд необходимо добавить.
Определение бизнес-цели
Поверьте, я не просто так написал, что бизнес-проблема является фундаментальной частью разработки требований и все опирается на её точное определение. Вот первый кирпичик, который мы кладем на наш фундамент (бизнес-проблему), который называется бизнес-цель.
Бизнес-цель - это конкретное и измеримое достижение, к которому стремится организация для улучшения своей деятельности, роста и развития. Бизнес-цели могут включать увеличение прибыли, расширение рынка, улучшение качества продукции или услуг, повышение эффективности процессов и другие аспекты, направленные на успех и процветание компании.
Если коротко, то цель - это то, к чему мы должны прийти, т.е. чего мы должны достигнуть в итоге. Бизнес-цель - это та точка, достигнув которую мы решаем определенную бизнес-проблему.
Так как бизнес-цели определяются на базе ранее выявленных бизнес-проблем, то там есть такая же категоризация, т.е. общая бизнес-цель, которая решает общую бизнес-проблему и частная бизнес цель.
Как обычно объясняем подробности для читателей краткой преамбулой. Затем переходим к определению самих бизнес-целей.
Таким образом, мы смогли установить вектор развития для разработки требований. Именно установленная цель определяет вектор, а для её определения выявляется проблема, которая её решает, а для определения проблемы необходимо знать исходные данные. Вот такой путь мы с вами уже успели пройти. В следующей статье будем определять:
- критерии успеха;
- положение о концепции проекта;
- бизнес-риски.
Не забудь подписаться на канал, чтобы ничего не пропустить и поставь лайк, если материал был интересен. Спасибо за прочтение!
