Региональный малый и средний бизнес в ИТ — 3

в 19:09, , рубрики: agile, бизнес-анализ, бизнес-процессы, Исследования и прогнозы в IT, Управление продуктом, управление проектами

Коллеги, в данной публикации хотелось бы рассмотреть некоторые принципы современной организации процесса разработки, в большей степени присущие современным гибким (Agile) методологиям, чем «водопаду».

Возможно, в публикации будет некоторый акцент на критике, но не стоит на ней зацикливаться. Скорее, это некий обзор: каждый из подходов имеет свои плюсы и минусы.
Данный пост является продолжением предыдущих публикаций (часть 1, часть 2).

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

Вот некоторые тезисы-вопросы, которыми я хотел бы поделиться:

1. Аналитики создают модель предметной области в своих терминах, разработчики ее кодируют в своих.
Нужно, чтобы кто-то «наводил мосты» между первыми и вторыми.


Эти люди — архитекторы, причем видов архитекторов нужно как минимум три:
— архитектор системы в целом (системный архитектор, system architect);
— архитектор программного обеспечения (программный архитектор, software architect);
— архитектор баз данных (DB architect).

2. Во времена «водопада» аналитики, руководители проектов, архитекторы вырастали из линейных специалистов и руководителей профильных подразделений, лучшие становились постановщиками задач.

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

Например, начальник отдела (или главный инженер) мог по совместительству занимать должность руководителя проекта (проекта, а не проектов, как современные PM).

3. В текущую эпоху доминирования гибких (Agile) технологий, хотя это с ними и не напрямую связано, преобладает такой подход:

3.1. Аналитиками становятся те, кто не смог стать разработчиком, но на аналитиков они и не учились (а где сейчас на них учат? — наверное учат, но процесс только пошел, а текущему подходу уже лет 10-15 как).

3.2. Разработчикам отвели роль «дешевых кодеров», соответственно, они или не могут по своим качествам заниматься аналитикой, или их до нее не допускают;

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

4. Итак, самое интересное — а где эти архитекторы?

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

«Дорогие архитекторы» в эту модель не вписываются. Сама то идея правильная: используя более четкое разделение ролей (аналитики — архитекторы — кодеры), мы получаем более качественный процесс разработки и — более качественный результат.

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

Автор: sand14

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js