Эпизод #4. Роли и задачи в IT проекте. А зачем все эти роли (TeamLead, Project manager, Product Owner, etc.)?

Роли и задачи в IT проекте. А зачем все эти роли (TeamLead, Project Manager, Product Owner, etc.)?

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

Сегодня мы планируем поговорить о тех задачах, которые важно реализовать в любом IT проекте и о том, какие роли (их всего порядка 20) призваны решать эти задачи, чтобы проект был реализован в планируемые сроки и бюджет, с качеством, удовлетворяющим потребности заказчика.
При этом, мы обсудим сложные IT проекты, для которых нет готовых шаблонных решений, поскольку именно в данных проектах можно наглядно продемонстрировать важность всего спектра ролей

Практический кейс для иллюстрации ролей в IT-проекте.

Примерно год назад к нам обратился один корпоративный стартап из области девелопмента.
Задача выглядела следующим образом:
Инженер-сметчик, имея на входе готовый САПР проект торгового или бизнес-центра, жилого комплекса, на выходе должен получить смету материалов.

Для этого необходимо:

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

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

Верхне — уровневые вопросы, которые нужно решать в процессе реализации данного проекта.

• Сколько займет времени и сколько будет стоить проект?
• Кто нужен для этого проекта внутри и какие нужны подрядчики?
• Как определить периметр первичного минимального функционала, без которого нельзя стартовать?
• Какие роли будут в системе?
• Будут ли частные / корпоративные пользователи?
• Нужна ли возможность вести несколько проектов и историю их изменений?
• Какой функционал будет в личном кабинете инженера, производителя, поставщика?
• Как они могут друг с другом взаимодействовать?

На этапе организации процесса разработки нужно понимать и сделать следующее:

1. Собрать со всех участников процесса их требования и пожелания, чтобы в конце избежать сюрпризов, что кого-то забыли.
2. Понять какие этапы и процессы автоматизируются, какие остаются ручными.
3. Проработать внешний вид системы: сколько страниц, экранных форм и с каким функционалом должно быть в системе?
4. Сделать соответствующие макеты (эскизы).
5. Найти дизайнерские решения по оформлению и внешнему виду.
   Разработать архитектурное решение, модель данных, выбрать стек технологий разработки.
6. Оценить нагрузочные параметры (кол-во одновременных пользователей, объем данных).
7. Определить формат рабочих мест (соотношение мобильных и десктоп пользователей).
8. Составить план проекта (даже agile проекты в них нуждаются).
9. Организовать процесс управления жизненным циклом разработки от совместного доступа к коду, до билдов и развертывания системы.
10. Организовать управление серверами и средами разработки.
    Организовать процесс тестирования (функционального, пользовательского, нагрузочного).
11. Определить объем необходимой документации (для пользователей, службы поддержки, разработчиков и тд).

Кто за все эти вопросы задачи отвечает и как ничего не упустить?
Как правильно распределить ответственности между ролями?

Сегодня, мы просто перечислим все необходимые роли в проекте, чтобы в следующем материале продемонстрировать то, как роли взаимодействуют друг с другом, и как распределяются ответственности между ними.
Важно понимать, что роли не зависят от кол-ва членов команды. Ролей порядка 15-20, а команды могут состоять из 2-3х и до 15 и более человек. Чем меньше команда, тем большее кол-во “шапок” будет на каждом из участников. Но, упусти одну из ролей, и картинка начинает рассыпаться.

В целом, можно поделить все задачи/роли на три блока:

• “Локомотив”, роли, которые всех продвигают всех к цели.
• Отраслевая экспертиза  / предметная в продукте / бизнес-модели
• Производственная экспертиза в реализации / разработке

Локомотив

1. Заказчик/Owner
2. Product Owner
3. Проджект менеджер

Отраслевая экспертиза

4. Тим-лид
5. Product Owner
6. Бизнес-Аналитик

Производственная экспертиза

7. Архитектор
8. Тех-лид/Системный аналитик
9. Разработчики

1. Фронт
2. Бэк
3. Интеграции
4. Full-stack
5. Mobile

10. DevOps
11. UX — дизайнер
12. UI —  дизайнер
13. QA (Тестировщик)

1. Функциональный
2. UAT
3. Нагрузочный

14. Тех-райтер