Потребность в аналитике

Аналитика
Аналитика: Потребность в аналитике

В один прекрасный момент мы в компании ТриЛан задались следующими вопросами: в какие именно проекты необходимо привлекать аналитика; по каким признакам можно определить, что для конкретно взятого проекта роль аналитика должен выполнять отдельный человек?

В ответе на эти вопросы мне помог доклад Александра Белина на Analyst Days 2014. Александр обобщил свой многолетний опыт работы и очень доходчиво рассказал, как следует подходить к вопросу выбора методологии разработки для конкретно взятого проекта.

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


О рисках


Чаще всего риски по проекту закрываются за счет переноса веса в общении с заказчиком на документы. Создаются объемные технические задания и подробные протоколы встреч. Короче говоря, фиксируются все договоренности с заказчиком. Документы описываются максимально полно. Параллельно идет дополнительная формализация процессов доведения информации через документы. Из-за большого объема данных, приходится вводить сроки на согласование, внесение правок или принятие решений.

Из-за объемных технических заданий возникает необходимость дать узким специалистам (проектировщикам интерфейсов, системным архитекторам, тестировщикам) возможность быстро находить интересующие их блоки информации. Приходится дополнительно формализовать структуру документов.

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

Теперь подробнее о рисках, которые мы берем в расчет до старта проекта.

Риск «есть представление, нет идеи»


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

Риск «нет времени на аналитику»


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

Риск «сложная география команды»


Риск обычно связывают с тем, что работы полностью отдаются на аутсорс или команда разработки географически распределена. В такой ситуации особое внимание должно уделяться ТЗ и постановке задач. На мой взгляд, достаточно придерживаться простых принципов:
— «явное, лучше неявного»;
— следует указывать контекст выполнения задачи (почему и для чего реализуем выбранный функционал; какую проблему решаем);
— желательно снабжать задачу примерами работы с реализуемым функционалом или вариантами его использования (use case).

Риск «трудный заказчик»


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

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

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

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

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

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

Риск «сложный проект»


Первый признак «сложного» проекта — это большое количество заинтересованных лиц. В такой ситуации даже для принятия незначительного решения очень много времени уходит на обсуждение мнений. Я столкнулась с этой проблемой во время разработки CRM для наших внутренних нужд. В каждый момент времени приходилось договариваться с двумя или тремя руководителями. И, конечно, каждый из них хотел лучшего для своего отдела или компании в целом.

Второй признак «сложного» проекта — много бизнес-областей и, как следствие, большой объем бизнес-требований, которые нужно обрабатывать. И снова хорошим примером является CRM. Мне потребовалось разобраться в бизнес-процессах отделов продаж, продвижения, разработки, контекста и оценки качества.

Третий признак «сложного» проекта — разработка затрагивает несколько систем. В такой ситуации приходится обрабатывать большой объем требований по интеграции и взаимодействию с этими системами. Хуже, если во время разработки или внедрения новой системы вам необходимы доработки существующих, повлиять на которые вы не можете.

Вывод


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

Аналитика: Потребность в аналитике
  • avatar
  • +10
  • 3030

0 комментариев

Оставить комментарий

Комментировать при помощи:


Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.