Формулировка проблемы
В момент начала нового проекта в роли бизнес-аналитика, я часто сталкиваюсь с ситуацией, когда дано описание программного решения, но отсутствует важная информация о том, какие конкретные проблемы оно направлено на решение сейчас. Отсутствие разъяснений о том, почему решение выглядит именно так, а также отсутствие планов его дальнейшего развития, создает некоторую неопределенность.
Эта тенденция не является изолированной возможностью, как показывает мой опыт в организации профессиональных конференций и в роли тренера.
Многие руководители и тимлиды выражают недовольство тем, что их коллеги часто ограничиваются разработкой единого решения, не рассматривая альтернативных вариантов. Они также высказывают замечания относительно того, что часто ставится акцент исключительно на внутренней реализации системы, учитывая контекст работы пользователя и текущую ситуацию в бизнесе.
Даже самые опытные аналитики, начиная работу над системой, часто выражают недовольство по поводу того, что предыдущие этапы не должным образом освещены или документированы. Отсутствие общего понимания контекста и целей становится критическим для ведущих специалистов, ответственных за команды, поскольку им приходится тратить значительное время на тщательный анализ работы аналитиков, что в свою очередь снижает эффективность выполнения более стратегических обязанностей.
Далее в этой статье я рассмотрю обоснованность подобных жалоб на мой взгляд, предложу возможные пути решения проблемы и обсудим, стоит ли винить исключительно аналитиков или можно улучшить ситуацию другими методами.
Почему пристальное рассмотрение решаемой проблемы вызывает беспокойство коллег? Это связано с несколькими ключевыми аспектами, которые могут иметь серьезные последствия для бизнеса и разработчиков.
-
Неполное решение проблемы
Простое или поверхностное рассмотрение проблемы может привести к тому, что выбранное решение будет неполным или неоптимальным. Это может привести к ненужным трудозатратам на доработку системы и переписке кода. -
Трансформация стиля работы заказчика
Решения, не учитывающие особенности текущего стиля работы бизнес-заказчика, могут потребовать от него значительных изменений. Это может вызвать недовольство и утрату эффективности работы. -
Бесконечные изменения и дописывание кода
Несовершенные решения часто приводят к постоянной необходимости дописывать и переписывать код, что в результате становится тяжелым бременем для разработчиков. -
Утрата лояльности и репутационные потери
Неудачные проекты могут привести к потере доверия клиента и повлиять на репутацию компании на рынке. Это может сказаться на предстоящих предложениях и выделении финансирования. -
Несоблюдение требований регулирующих документов
Отсутствие всестороннего анализа может привести к нарушению требований отраслевых и государственных стандартов. Это может привести к административным правонарушениям и штрафам. -
Проблемы с безопасностью и хранением данных
Неправильное решение может привести к нарушению требований безопасности и хранения данных. Это особенно важно в сфере заботы о персональной информации и медицинских данных.
Все эти факторы подчеркивают важность тщательного и всестороннего рассмотрения задачи перед принятием решения. Такой подход помогает избежать негативных последствий и обеспечивает успешную реализацию проекта.
Что нужно для удовлетворения запроса
Среди всех ролей в проекте роль бизнес-аналитика ближайшая к миссии "видеть задачу в целом". Поэтому я хотел бы обсудить деятельность, которая может приблизить к широкому рассмотрению задачи, освещенной с точки зрения этой роли. Хотя руководитель проекта также может испытывать потребность в этом, у него, однако, фокус на поиске баланса между временем, объемом работы и удовлетворенностью заказчика, что делает невозможным рассмотрение всех вариантов.
Итак, если вы решаете серьезно заняться переосмыслением и анализом текущей задачи, вам следует:
- Рассматривать задачи с точки зрения разных заинтересованных сторон.
- Будет охватывать весь жизненный цикл системы.
- Анализировать входящую информацию на полноту, качество и актуальность.
- Учитывать риски и ограничения.
- Использовать широкий набор аналитических инструментов.
- Будет рассматривать несколько вариантов решений.
- Сначала рассматривать тривиальное решение.
Возможно, это не полный перечень, но достаточно для разработки плана саморазвития или развития своей команды на несколько лет, поэтому на данном этапе ограничимся этим.
Анализ ситуации с учетом интересов разных сторон
Анализ ситуации с учетом интересов разных сторон является ключевым аспектом успешной работы бизнес-аналитика. Рассмотрение перспектив бизнес-заказчика и пользователя, руководителя проекта и архитектора, тимлида и техподдержки являются важнейшими точками фокуса. Важно отметить, что задача аналитика не предусматривать все, а обеспечить наличие информации о принципах архитектурного проектирования текущей системы, управления проектом, планах поддержки и особенностях финансирования со стороны спонсора.
Если эта информация отсутствует в документации, необходимо обеспечить доступ к людям, способным ответить на эти вопросы.
Не стоит сомневаться в поиске и общении с соответствующими специалистами, чтобы разъяснить контекст разработки. В идеале, аналитику следует стремиться к пониманию всех аспектов проекта, что, наконец, способствует лучшему восприятию задачи в целом.
Предоставление аналитику доступа к ключевой информации по всем аспектам проекта обеспечивает более глубокое и всестороннее понимание контекста, что в свою очередь поддерживает принятие информированных и обоснованных решений в ходе анализа и удовлетворяет потребности всех заинтересованных сторон.
Рассматривать весь жизненный цикл системы
Учесть полный жизненный цикл системы является ключевым моментом в работе бизнес-аналитика. Не менее важно также сохранить во мнении временную перспективу жизни разрабатываемых продуктов. Строить систему, учитывая не только текущее развитие, но и будущую поддержку, является обязанностью, лежащей на плечах разработчиков. Важно, что ответственность за товар не исчезает после завершения разработки; поддержка и изменения, согласованные с продуктом, будут неизбежны.
Также следует иметь в виду, что любая система, сколько бы тщательно она ни была спроектирована, рано или поздно будет заменена другой. Это отражает действительность современного мира, где технологические конфигурации происходят так скоро, что долговременная устойчивость становится вызовом. Однако главной ценностью для бизнеса остается хранящаяся в системе информация. Безопасность и безопасность сохранения или экспорта данных становятся критическими моментами.
Таким образом, необходимо задуматься о том, насколько разрабатываемый продукт будет актуальным и полезным в будущем. Будь то прототип для моделирования решения задачи или ценный источник информации на долгий срок — это важное размышление, которое поможет создать продукт, способный отвечать требованиям бизнеса не только сегодня, но и в перспективе.
Проведение анализа входящей информации с учетом ее полноты
Проведение анализа входящей информации с учетом ее полноты, качества и актуальности является важным этапом бизнес-аналитика. Поскольку информация может поступать в разных форматах, от технических задач до неполных описаний задач, важно принимать активные меры по уточнению деталей и заполнению пробелов.
При работе с техническим заданием, созданным неопытным заказчиком, бывает недостаточно информации о целях и ограничениях системы. В случае макетов интерфейсов иногда сложно однозначно понять пользовательские сценарии и жизненные циклы объектов. Даже при таких простых запросах, как "реализовать возможность отображения списка заказов в ЛК пользователя", неясно, в каких условиях пользователи будут взаимодействовать с продуктом и какие у них роли.
Эффективная стратегия включает активное взаимодействие с заказчиком или другими ответственными сторонами.
Запрос дополнительной информации об ограничениях и целях системы, задачи дополнительных вопросов при обнаружении пробелов в информации, а также проверка актуальности и времени создания артефактов становятся первыми шагами при проработке задачи. Это помогает сформировать более полное и точное представление о требованиях, что, в свою очередь, обеспечивает успешное выполнение проекта.
Выявлять риски и ограничения
Полностью согласен с вашим подходом к выявлению и описанию рисков и ограничений. Работа с этими аспектами действительно требует внимания и активного подхода со стороны бизнес-аналитика.
Риски, связанные с изменением заинтересованных сторон, изменением их точек зрения и пожеланий, а также ограничения, связанные с временными рамками, архитектурой, инструментами и используемой регулирующей документацией, являются неотъемлемой частью проектной деятельности.
Бизнес-аналитик, как вы правильно отмечаете, имеет способность работать с различной информацией на разных уровнях абстракции и выявлять нестыковки и пробелы, которые могут остаться незамеченными другими участниками процесса.
Важно не только ставить вопрос об этих нестыковках, но и обсуждать их последствия и потенциальные риски для проекта.
Прозрачность в общении и открытое выражение беспокойства по рискам и ограничениям являются ключевыми элементами успеха. Взаимодействие с заказчиком, руководителем проекта, архитектором, UX/UI-специалистом и другими участниками проекта для четкого понимания ситуации и принятия совместных решений действительно помогает снизить вероятность непредвиденных проблем и повышает качество проектной работы.
