– Аналитик, дизайнер, архитектор, проектировщик – довольно близкие по смыслу роли. Это специалисты, способные представить будущий продукт в виде модели: процессов, сценариев, дизайнов интерфейса, модулей, сервисов, объектов и компонент. Зачем? Да чтобы уменьшить вероятность ошибки в разработке. Чем шире и качественнее проведено предварительное моделирование, тем меньше вероятность, что разработчики «выбросят» уже написанный код из-за появившихся уточнений/требований.

Их результат – архитектурная схема, концепция, описание сценариев и состав пользовательских экранов, постановка задачи в разработку.

– Тестировщики, они же QA/QC-специалисты, они же специалисты по контролю качества. Их ключевая цель – дать вселенной увидеть ровно тот результат, который нужен на самом деле. Их результат – отсутствие замечаний и ошибок в будущей системе и факт того, что система работает «как надо», т. е. поддерживает целевые процессы.

– DevOps-инженер организует и настраивает инфраструктуру как для самой команды, так и для будущей реальной системы. На старте, как правило, тесно работает с техлидом, чтобы организовать рабочее пространство команды так, как тот задумал. Его результат – правила сборки кода каждого разработчика в общий репозиторий и настроенные окружения:

– DEV, т. е. для разработки;

– QA для тестирования;

– UAT (user acceptance testing), предназначенный для приемки продукта.

– Менеджер. Это ты. И у тебя много дел. Давай попробуем обозначить основные твои обязанности и результаты:

– Контроль достижения результата – ты должна осознавать, как команда дойдет до результата, отслеживать изменения на этом пути. Твой результат – это достижимый план проекта и его регулярная актуализация.

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

– Работа с качеством – полученный результат должен соответствовать как ожиданиям качества от заказчика, так и собственным требованиям к качеству команды, например, таким, как качество кода, качество документации и базы знаний, тестовых сценариев. Каждый проектный результат проверен и соответствует заявленному качеству: протестирован, продемонстрирован, подтвержден опытным путем и т. д.

– Работа с коммуникациями – выстраивание всех коммуникационных потоков в проекте: как внутри, так и наружу. Результат: отсутствие простоев или лишней работы из-за «не договорились», отсутствие конфликтов с внешними относительно команды ролями.

Это роли. От проекта к проекту каждая роль может исполняться отдельным человеком или один человек может подхватывать несколько ролей. Помни: каждый новый специалист «съест» кусочек ресурса проекта. Ты должна понимать, каким результатом для команды обосновано присутствие в ней каждого участника.

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

Акцент твоей работы в роли менеджера будет меняться по ходу проекта:

– Старт проекта. Ничего не понятно, результат существует в виде общей концепции, риски «не получить результат в конце» максимальны. Ты акцентируешь свое внимание на понимании архитектуры/концепции и построении плана проекта. Выстраиваешь основные потоки коммуникаций. Основная задача – выйти из предпроектного тумана «ничего не понятно» и перейти в штатный режим работы.

– Проект. Когда работа встает на стабильные рельсы и разработчики начинают «строгать» фичи, а также появляются осязаемые кусочки результата, ты переключаешься на контроль и управление ожиданиями: демонстрируешь промежуточные результаты, получаешь уточнения и новые вводные, актуализируешь путь к успеху, т. е. план проекта. Это этап производства – тебе надо в заявленные сроки и с ожидаемым качеством прийти к целевому результату.