Решебник начинающего руководителя проекта

Чем шире и качественнее проведено предварительное моделирование, тем меньше вероятность, что разработчики «выбросят» уже написанный код из-за появившихся уточнений/требований.

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

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

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

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

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

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

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

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

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

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

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

Это роли. От проекта к проекту каждая роль может исполняться отдельным человеком или один человек может подхватывать несколько ролей.