Мы все примерно знаем
хардовый и софтовый профиль хорошего биайщика. Это тема отдельной статьи - но грубо это бизнесово-мыслящий инженер с творческими и коммуникативными способностями. Люди приходят в профессию разные и у большинства есть перекос сильных сторон - в сторону техники, бизнеса, дизайна или коммуникаций. Прокачивать слабые стороны членов команды безусловно важная задача BI лида - но это разнообразие, с другой стороны, обогащает команду, дает больше интересной экспертизы и стимулов роста. Поэтому мы помимо развития общеизвестных скилов делаем фокус на "проповедовании" определенного майнсета в виде принципов - установок, помогающих всем, несмотря на отличия, вести BI проекты по короткому пути к успеху.
Вот некоторые из них:
- Заказчик чаще не прав - неправильно представляет себе отчет, то что он хочет
- Вы главный в проекте - вы несете ответственность за неоптимальное использование своего ресурса (=ресурса компании)
- До того как вы стартовали проект - вы должны клиенту сервис, после того как вы стартовали проект еще и он должен вам свой ресурс и адопшн. Холдите проекты где заказчик от вас бегает
- Разбивайте растущие требования на части и разносите их хронологически в разные "релизы", заставляйте принимать и выпускать проект частями
- Не рассматривай мелкую задачу как мелкую задачу, бОльшую часть требований или проблем с данными от тебя спрятали
- Не берите на себя ответственность за несовершенство процесса. Инициируя изменения в процессах и системах - подчеркивайте границу ответственности свою и владельца процесса/системы
- Много и открыто говорите о текущих и потенциальных рисках проекта и получаете подтверждение от заказчика их понимания и принятия
- Не концентрируйтесь на фичах и визуализациях дольше, чем на решении бизнес-задач и проверке бизнес-ценности разрабатываемого
- Проговаривайте и фиксируйте договоренности, в случае изменения требований аккуратно тыкайте в это заказчика носом и заставляйте осознавать вину
- Используй Fail-Fast подход, проверяя, что заказчик к нему готов.
Не все эти принципы понятны без контекста, будет интересно - опишу отдельно.
Наложив эти принципы на софтскиловость аналитика и специфику задачи, я получил несколько
стратегий ролевого самопозиционирования BI аналитика в проекте:
Продуктивные стратегии:
Могут быть оптимальны в зависимости от кейса
Стратегия 1 - Like a god
- Вы делаете все от бизнес-логики до техники и визуала
- Вы определяете сроки и роли, структурируете рабочую группу и экспертов
- Вы требуйте от заказчика/экспертов необходимую активность, сами формализуете бизнес-логику
- Вы несете все риски
Условия
- Нет владельца данных
- Нет инициативы, ресурса у бизнес-функции владельца
Стратегия 1 - Like a boss
- Вы лучше знаете как надо и как не надо в части данных и визуала
- Вы определяете сроки и роли, формат взаимодействия
- Вы требуйте от заказчика/экспертов необходимую активность, бизнес-логику
- Заказчик принимает на себя риски как за системы и требования, вы за визуал и технику
Условия
- Вы реально должны иметь прокачанный скилл в домене данных и подбора эффективного визуала (а не так кажется лучше)
- На выходе клиент должен быть счастлив, если он делал все что нужно
Стратегия 3 - Like a partner
- Вы выступаете как эксперт в области визуализации и работе с данными, предлагая конечные решения, принимая от заказчика пожелания
- Вы участвуете в проработке бизнес-логики с заказчиком как консультант
- Вы делите с заказчиком риски
Условия - Вы не готовы диктовать как должно быть по визуалу
- Заказчик не имеет нормальных требований, финальных метрик и "идет от данных", понимает риски
- Нет жестких дедлайнов, заказчик принимает работу по agile
Стратегия 4 - Like an executor
- Вы выступаете "как руки" - что вы скажите то мы и сделаем
- Вы получаете на вход требования как по логике так и по визуалу, если и предлагаете то без напора, клиент решает
- Мы даете сроки и корректируете их при смене требований
- Заказчик несет всю ответственность
Условия
- Вы не имеете экспертизы в визуализации или задача не про визуализацию а получение цифр
- Есть четкое и полное тз
Cтратегии низкой продуктивности:Стратегия 5 - Like a friend - Вы берете задачу на хорошем человеческом контакте с заказчиком
- Вы стремитесь "помочь" - смешиваете роли и не коммуницируете риски и ответственность до и во время проекта
- Вы мало оцениваете сроки и сдвиги, идете от ситуации
Условия
- Вы уверены, что хорошо понимаете заказчика у вас долгий опыт успешных проектов
- Заказчик не имеет нормальных требований, финальных метрик и "идет от данных", понимает риски
- Нет жестких дедлайнов
- У вас есть ресурс на это
- Проект не высокого приоритет
Стратегия 6 - Like a slave
- Вы выступаете "как руки" - что вы скажите то мы и сделаем
- Вы получаете на вход требования в общем виде и раскапываете их сами
- Вы несете ответственность за результат и не коммуницируете риски Заказчику
Условия
- Нет правильного проектного менеджмента в вашей работе, нет контакта с заказчиком (супер-топ?)
- Неадекватно выстроенные ожидания заказчика
Эти стратегии стратегии полезно осознавать и перемещать себя и заказчика в конструктивные роли в зависимости от условий в которых вы находитесь. Полная аналогия с "Games People Play" Эрика Берна.
Пользуйтесь и оставляйте комментарии.
Раз дочитали до сюда - желаю получить от процесса извращенное удовольствие перфекциониста)