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

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

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

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

Эти люди — архитекторы, причем видов архитекторов нужно как минимум три:

архитектор системы в целом (системный архитектор, System Architect);
архитектор программного обеспечения (программный архитектор, Software Architect);
архитектор баз данных (DB Architect).

О том, что бывает, когда это звено пропущено, можно почитать в части 1, п.1.

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

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

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

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

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

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

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

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

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