В разработке

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

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

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

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

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

Задачи аналитика как коммуникационного центра:

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

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

Шаблоны постановки задач

Постановка задач является многоуровневым процессом, в котором участвует вся команда.

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

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

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

Размещение визуальных компонентов

..

Словарь визуальных компонентов

…

Схемы данных и функции

…

Шаблоны программных решений

…