В разработке
Обычно аналитика рассматривают с точки зрения проекта: на эту тему в аспекте разработки и документирования требований написано множество книг. В данной статье мы рассмотрим неформальный аспект работы аналитика как коммуникационного центра команды и инженера знаний.
Разработка и документирование требований является только начальным этапом работы, верхушкой айсберга в командной работе. Традиционно это используется прежде всего для определения границ проекта, его бюджета и высокоуровневого планирования.
При попытке использовать эти требовании в разработке обнаруживаются классические проблемы неполноты и недостаточной детализации, неоднозначности и сложности их понимания разными членами команды. В течении проекта неизбежно меняются исходные требования, в т.ч. и принципиальные, критически влияющие на архитектуру решения.
Соответственно, аналитик постоянно общается с пользователями и командой в течение всего проекта, получает обратную связь и непрерывно изменяет и дорабатывает требования. Очевидно, что аналитик не может быть экспертом по всем аспектам предметной области и проекта. Поэтому навыки обнаружения логической неполноты и непоследовательности в проектных знаниях являются базовыми для аналитика. На основе этих навыков аналитик сможет обнаружить недостающие знания и сформулировать потребности в экспертизе и вопросы к экспертам.
Для меня разработка требований является более сложой задачей, чем программирование. Я стараюсь как можно раньше сформировать обратную связь от пользователей и команды и писать документацию под конкретных разработчиков, учитывая их особенности восприятия.
Задачи аналитика как коммуникационного центра:
- Координация команды – важно, чтобы каждый член команды имел целостное представление о проекте и понимал, с кем ему нужно взаимодействовать для решения задач, и кто будет использовать результаты его работы. Критерием является минимальное количество конфликтов при слиянии кода и относительно небольшой или редкий технический (нефункциональный) рефакторинг при интеграции кода.
- Построение конвейера – важно эффективно распределить задачи между разработчиками в зависимости от их опыта и компетенций, уменьшить зависимости между между исполнителями для распараллеливания работы. Критерием является минимальное количество ожиданий разработчиков друг друга.
- Мониторинг процесса – важно оценить риски задержек или тупиковых решений из-за технической сложности, недостаточного непонимания требований или архитектуры решения. Перед выполнением задачи обсуждаются предметные и технические вопросы, при необходимости выполняется их документирование всеми членами команды. Важно детализировать задачи для организации конвейера, демонстрации прогресса в разработке и раннего обнаружения возможных проблем и обеспечении поддержки.
Эти задачи аналитик выполняет совместно с архитектором и руководителем разработки на основе согласованных шаблонов постановки задач и программных решений.
Шаблоны постановки задач
Постановка задач является многоуровневым процессом, в котором участвует вся команда.
Аналитик определяет прежде всего цели и функции, решаемые в рамках задач. Эксперты и разработчики добавляют предметные и технические знания, используемые или производимые в процессе их решения.
Потенциально постановка задачи является бесконечным процессом, если стремиться к полноте и однозначному пониманию. Поэтому, для обеспечения безостановночной работы команды важно вначале быстро определить начальные аспекты задач: сценарии работы пользователей и визуальные макеты пользовательского интерфейса в 1-й версии.
Затем, на основе вопросов со стороны пользователей и разработчиков, а также при привязке пользовательских функций к программной реализации выполняется детализация постановки.
Размещение визуальных компонентов
..
Словарь визуальных компонентов
…
Схемы данных и функции
…
Шаблоны программных решений
…
