Выделение команд на основе деятельности

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

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

В проекте участвует несколько команд, которые я определяю по виду их деятельности:

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

Также есть пара людей занимающихся:

  • Сбором и актуализацией требований.
  • Управлением процессами и контролем сроков.

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

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

Артур, спасибо за пост!
Отлично, что заметили отсутствие предпринимательских альф. Это может быть опасно для проекта, тк система может удовлетворять требованиям (пройти проверку), но не удовлетворять потребностям (не пройти приемку). Так что неплохо бы обратить внимание туда.
В рассказе о команде анализа данных почему-то основной объект внимания – требования. Может, вы подумаете над другим названием команды, которое точнее отразит суть работы?)

Похоже, что условная команда “анализа данных” и является предпринимательской альфой в данном случае - именно их проблемы должны решить инженеры и эта команда проводит приёмку работ.

Интересно, что до вашего комментария - я рассматривал эту команду не как заказчика, а как одну из внутренних команд проекта и похоже не я один, поскольку уже попадали в ситуацию, когда сделано было не то, что ожидала эта команда, а то о чём “громче” говорили.

Спасибо за комментарий, Анна!