Немного подробнее о причинах написания статьи:
1. Недопонимания на собеседованиях
-- Нет понимания роли и ценности позиции
-- Непонятен пул задач и зоны ответственности
-- Нет четкой иерархии подчиненности
2. Проблемы на проектах
-- Неверный выбор исполнителей по задачам
-- Наличие нерешенных задач из-за костылей
-- Ублажаем заказчика вместо выполнения проекта
3. Проекты ради проекта
-- "Странная" архитектура по задачам
-- Трудности в сопровождении/обновлении
-- Не найти крайнего по задачам
Все эти проблемы приводят к тому, что на проектах как во время выполнения, так и после возникает БАРДАК. Цель данной статьи помочь таким командам упорядочить процесс разработки, тем самым повысить качество работ по проектам.
В данной статье будут раскрыты следующие вопросы:
1. Кто такой архитектор?
2. Какие задачи выполняет архитектор?
3. Какие задачи он НЕ выполняет?
4. Можно ли без него обойтись?
5. Чем отличается системный архитектор от функционального архитектора?
6. Кто главный: РП или архитектор? Кому подчиняется проектная команда?
- Кто такой архитектор?
Для того чтобы ответить на это вопрос, надо дать определение архитектуры.
Архитектура программного обеспечения – это совокупность важнейших решений об организации программной системы. Состоит из:
- Выбора структурных элементов и их интерфейсов, с помощью которых составлена система, их поведение в рамках сотрудничества структурных элементов.
- Способов соединения выбранных элементов структура в более крупные системы.
- Архитектурного стиля, который направляет все элементы, их интерфейсы, сотрудничество и соединение.
Данное определение можно найти в интернете. Переведем это на язык 1С!
- Архитектор определяет состав и структуру объектов метаданных и взаимосвязи между всеми объектами метаданных в рамках каждой отдельной подсистемы.
- Каждое решение состоит из подсистем. Состав каждой подсистемы и взаимодействие между подсистемами определяет архитектор.
- Архитектор определяет, с помощью каких объектов метаданных решать ту или иную задачу, насколько глубоко необходимо переработать типовое решение, какие объекты метаданных сделать новыми.
- Определяет подходы к разработке интерфейсов. Определяет сценарии работы каждого объекта метаданных.
Как видно из определения и его перевода на язык 1С, архитектор отвечает за:
- Структура метаданных
- Функциональность системы
- Отказоустойчивость системы
- Удобство использования системы
- Быстродействие системы
- Простота сопровождения
- Какие задачи выполняет архитектор?
После того, как разобрались кто такой архитектор, можно подумать о его задачах.
Главными задачами архитектора являются (в части постановки задач):
Изучение информации:
- Изучение документации. Многие бизнес-процессы в организации четко описаны в ЛНД компании.
- Изучение бизнес-процессов. Изучаем бизнес-процессы без привязки к используемому ПО. Связано это с тем, что многие этапы существующих бизнес-процессов происходят вне ПО и требуют автоматизации.
- Типовой конфигурации. Невозможно корректно спроектировать систему без изучения сценариев и структуры типовой конфигурации.
- Текущего ПО. На этом этапе можно выявить задачи, которые требуют особого внимания. Также можно увидеть ошибки предыдущих команд и не повторять их.
Проектирование:
- Состав метаданных. Принятие решения с помощью каких объектов будет решена задача
- Определение структуры метаданных в целом и каждого объекта метаданных в частности.
- Определение связей между объектами метаданных.
- Наполнение системы новыми сценариями.
Для выполнения задач в назначенные сроки и с нужным качеством архитектор выполняет следующие задачи (в части сопровождения и приемки задач):
Сопровождение реализации:
-
Разъяснение постановки и сценариев исполнителям. Не стоит думать, что прочитав ТЗ исполнитель сам с ним разберётся. Можно сократить время и обсудить постановку до начала работ. Это позволяет прийти к одинаковому пониманию как у постановщика, так и у исполнителя.
- Обсуждение способа реализации. Стоит заранее обсудить этот момент, чтоб не переделывать
- Desing review. Этап проводится при реализации 30-40% задачи. Необходим он чтоб убедиться в правильности выбранного архитектором пути. На этом же этапе могут быть найдены дополнительные сценарии, требующие автоматизации.
Проверка реализации:
- Проверка реализации (Code review).
- Организация внутреннего тестирования. Проверка протокола тестирования.
- Включение доработки в релиз.
Прочие задачи по проекту:
- Участие в собеседованиях с целью оценки знаний в предметной области и навыков в программировании.
- Обсуждение задач с методологами и заказчиком.
- Предварительная оценка сроков выполнения задач.
- Участие в разборе причин инцидентов.
- Участие в разработке регламентов работы команды (согласование).
- Участие в разработке технической документации (согласование).
- Чего архитектор НЕ должен делать?
Часто на проектах архитектору поручают не свойственные ему задачи:
Функции менеджера:
- Контроль сроков исполнения задач.
- Планирование по проекту (весь проект, недельный план, месячный план).
- Решение любых вопросов связанных с деньгами, бюджетом, зарплатой, премией.
- Согласование отпусков, отгулов в т.ч. часовых.
- Контроль опозданий обедов и т.д.
- Подписание актов, листов учета рабочего времени.
Оформление бумаг:
- Написание инструкций для пользователей.
- Описание архитектуры серверов.
- Информационная безопасность.
- ТЗ и ТП по ГОСТу.
- Регламент разработки.
Прочие задачи:
- Тим билдинг.
- Обучение и развитие сотрудников.
- Убеждение коллег и руководства в правильности архитектурных решений.
- Сдача работы заказчику.
- Консультирование пользователей.
- Убеждение коллег исправить ошибки.
- Поиск виноватых.
- Соврать заказчику, потом доделаем.
- Настройка и администрирование серверов и прочего ПО.
Пояснение некоторых пунктов:
- Планирование сроков разработки... Да архитектор определяет что, как и в какой последовательности делать, но пока не описана архитектура и не определены сценарии угадать срок разработки невозможно. В целом планирование – это задача РП. Архитектор здесь выступает только как эксперт, но не как составитель план-графика! О сроках подробнее ниже…
- Контроль сроков разработки по каждой задаче. Некоторые руководители думают, что обзвонить всех разработчиков и консультантов каждый день это задача архитектора. Это опять роль РП или помощника РП. Архитектору этим некогда заниматься!
- Архитектор не должен убеждать членов команды (даже вышестоящих) в правильности своего решения. У всех членов команды разный уровень знаний и опыт работы. Архитектор (в нормальном виде) – это самый грамотный и самый опытный. Это человек, который в голове держит всю картину проекта и знающий, что как и с чем связано. Отступление от плана архитектора грозит разрухой в архитектуре.
- Техническую документацию оформлять по ГОСТам и прочим нотациям должен Технический писатель. Исходный текст документации формируют аналитики/консультанты. Архитектор является согласующим по всей документации, но не автором.
- Можно ли без него обойтись?
Для ответа на этот вопрос необходимо проанализировать каждую задачу архитектора и найти на неё исполнителя. Главное обеспечить такое же качество выполнения этой задачи на уровне архитектора!
- Выяснение требований. Часто эту задачу поручают аналитикам или консультантам. В одной из следующих статей будут описаны компетенции членов команды. Для выяснения требований надо знать и существующую архитектуру решения, и сценарии и особенности реализации. Аналитик/консультант такой компетенцией не обладает. По некоторым задачам необходимо реорганизовать бизнес-процесс для снижения трудоемкости в разработке. Для этого требуется задать вопросы в правильном ракурсе.
- Определение структуры метаданных. Данная задача часто поручается либо аналитикам, либо разработчикам. В первом случае, аналитик – не разработчик, а значит правильно спроектировать решение не способен! Во втором случае разработчик будет искать кратчайший путь решения задачи. Он может учесть далеко не все сценарии, а только очевидные для него. Разработчик обычно не работает с данными и не в полной мере осведомлен о протекающих в компании бизнес-процессах.
- Определение связей между объектами. Данную задачу также поручают аналитикам или разработчикам. Каждый отдельный разработчик и аналитик не в курсе всего пула задач. Следствием этого является доработка тех объектов, которые дорабатывать было нельзя, либо необходим другой способ решения задачи. Выливается это в перекладывании ответственности за неверное решение с одного на другого. В итоге никто не отвечает за возникшие ошибки, а главное никто не предусмотрел, как избежать ошибок.
- Наполнение системы новыми сценариями. Обычно сценарии тестирования появляются после завершения разработки. Автором сценариев обычно выступает консультант. Это ужасная ошибка!!! Т.к. разработка должна вестись по конкретным сценариям! Необходимо на начальном этапе учесть все сценарии и продумать целостность решения.
- Обсуждение способа реализации. Обычно этот этап предшествует написанию ТЗ. Участвуют в таких совещаниях все кому не лень. Люди пытаются всеобщими усилиями придумать, как же решать задачу. Т.е. в начале такого обсуждения нет ни одного человека, который знает правильный путь. Это как заблудиться в лесу и всем кричать «ау», вместо того, чтоб взять с собой проводника и GPS трекер. Desing review – это этап, цель которого выяснить, правильно ли разработчик понял постановку задачи, в правильных ли местах в коде он начал доработку. Использовал ли разработчик программный интерфейс. Как видно из описания, ТЗ уже написано! И есть человек, который знает, как правильно решить поставленную задачу!
- Проверка реализации. В большинстве проектов, которые я видел «со стороны», этот этап либо отсутствует вовсе, либо его поручают разработчикам. Т.е. один разработчик проверяет реализацию у другого разработчика. Что происходит? Каждый разработчик знает только свои задачи. Чтоб проверить задачу, в неё нужно глубоко вникнуть! Т.к. сроки разработки всегда сжаты и уровень разработчиков разный – качество такой проверки носит лишь формальный характер. Многие не соблюдают стандарты разработки, пишут неоптимальный или нечитаемый код, не владеют способами оптимизации запросов и в целом пишут много лишнего кода. Просто поставить галочку в Jire – такой способ проверки подойдёт, однако результата от него не будет!
- Проверка протокола тестирования. Обычно на этапе тестирования могут появиться новые сценарии (заказчик подкинул, или кто-то из членов команды). Может потребоваться повторное проектирование по новым сценариям. Минусы проектирования консультантами и разработчиками описаны выше.
- Включение доработки в релиз. Всем знакома ситуация, когда кто-то затер чужие доработки? Это результат того, что сборкой релиза занимаются все кому не лень.
Если внимательно прочитать все описанные обязанности архитектора, должно быть понятно, что корректно выполнить/проконтролировать эти обязанности может только человек с большим багажом знаний и опыта – архитектор! Качественно заменить архитектора невозможно!
Каждый член команды должен заниматься своей работой:
- Архитектор – постановкой задач, проверкой результатов и формированием релизов.
- Аналитик – составлением инструкций, сценариев, сдачей работ заказчику.
- Консультант – тестированием доработок, поддержка пользователей.
- Разработчик – выполнением работ по постановкам, утвержденным архитектором.
- Руководитель проекта – административной работой, мониторингом сроков, управлением бюджетом проекта, переговорами с заказчиком.
Минусы отсутствия архитектора:
- Нет одного ответственного. За коллективные решения никто ответственности не несёт.
- Выдаваемые задания на разработку не связаны между собой либо ломают друг друга.
- Не полные данные на этапе обследования.
- Неверная структура метаданных. Проблемы при обновлении.
- Трудности при разработке сложных алгоритмов, не оптимальные решения.
- Проблемы при сборке релизов. Зоопарк в коде.
- Чем отличается системный архитектор от функционального архитектора?
В последнее время стало модным слово архитектор использовать с префиксами «функциональный» и «системный». Предлагаю разобраться, кто есть кто, а главное нужно ли 2 архитектора?
Итак, функциональный архитектор отвечает за функционал системы, за сценарное наполнение подсистем. Очень часто это НЕ программирующий человек. Он хорошо знает, как решаются различные задачи с помощью типового функционала.
В компетенции такого специалиста входят:
- Знания обо всех подсистемах внедряемого ПО.
- Знания о сценарном наполнении объектов.
- Знания о существующих настройках ПО.
- Навыки работы с большими объемами данных, способами исправления часто встречающихся ошибок.
- Навыки сбора и систематизации информации от пользователя.
Кто же такой системный архитектор? Это, прежде всего технический специалист и разработчик. В компетенции такого специалиста входят:
- Знания обо всех подсистемах внедряемого ПО.
- Знания о сценарном наполнении объектов.
- Знания о существующих настройках ПО.
- Навыки работы с большими объемами данных, способами исправления часто встречающихся ошибок.
- Навыки сбора и систематизации информации от пользователя.
- Знания об объектах метаданных, правилах их использования.
- Знания о построении объектов метаданных с точки зрения кода.
- Знания о способах оптимизации запросов и кода в целом.
- Знания о стандартах разработки.
- Знания о серверной архитектуре (опционально).
- Знания о настройке SQL, администрировании баз (опционально).
Как видно из описания, функциональный архитектор отличается от системного архитектора лишь недостатком знаний в области программирования! Если на проекте работают оба специалиста, то возникают следующие недостатки:
- Постоянный конфликт мнений. Обусловлен он глубокими знаниями архитектуры решения «изнутри». Часто проектируя решения, функциональный архитектор ищет просто кратчайший путь с минимальными доработками. Системный архитектор ищет правильный путь, который верно впишется в концепцию решения, будет оптимально работать по производительности, не нарушит обновляемость системы.
- Оба архитектора будут работать в пол силы. Обычно это 2 высокооплачиваемых специалиста.
- Нет единого центра принятия решений. Возможен постоянный поиск виноватых, то на стороне постановки задачи, то на стороне реализации.
Поэтому если и есть так называемый функциональный архитектор, то он должен подчиняться системному архитектору! Однако можно такому специалисту доверить управление группой аналитиков и консультантов. Такая связка исключает конфликт мнений. Каждый занимается своей задачей и стремится сделать её максимально качественно. Качество – это главный критерий при принятии решений на проекте.
- Кто главный: РП или архитектор? Кому подчиняется проектная команда?
Вечный вопрос: «Кому подчиняется команда?». Не так ли? Можно ли найти в этом вопросе компромисс? Попробуем разобраться.
Для этого разберемся с зонами ответственности РП и архитектора.
Итак, руководитель проекта отвечает за:
- Коммуникации между проектной командой и заказчиком.
- Учет выполняемых задач.
- Составление регламентов работы.
- Контроль сроков по выполняемым задачам.
- Мотивация членов команды (в т.ч. KPI).
- Развитие компетенций, обучение.
- Составление отчетности по состоянию проекта перед заказчиком.
- Согласование отсутствий.
- Team building.
- Управление бюджетом проекта (опционально).
В свою очередь архитектор отвечает за:
- Архитектуру решений.
- Качество кода.
- Качество/полноту сценариев работы.
- Техническую документацию.
- Способы устранения ошибок в данных.
- Настройки учета.
- Назначение исполнителей по задачам.
- Последовательность выполнения задач.
- Оценка компетенций членов команды.
Как видно из описания, руководитель проекта не несет никакой ответственности за качество выполненной работы. Да естественно, ему в первую очередь выскажут претензии за отсутствие качества. НО! Роль РП предусматривает просто принести все претензии команде, узнать, кто и когда их устранит. РП не будет вместе с Вами до ночи программировать или разбирать пользовательские ошибки.
Выше я описал, сферу ответственности архитектора. Как видно, именно архитектор будет основным человеком, который будет заниматься устранением ошибок.
Из этого можно сделать вывод, что по административным вопросам, по коммуникациям и т.д. вся команда подчиняется РП. Но абсолютно недопустимо, когда РП ставит задачу хоть программистам, хоть консультантам без согласования с архитектором.
Из этого можно сделать второй вывод, что по техническим вопросам вся команда подчиняется архитектору. Если архитектор утвердил или отверг тот или иной вариант решения задачи, то никто из команды не вправе менять решение архитектора. Даже всемогущий руководитель проекта не имеет на это права. Т.к. я не знаю ни одного РП, который способен заказчику прямо сообщить: «Это я сказал архитектору сделать так (сроки поджимали, или денег нет в проекте на это), и это из-за меня возникла такая проблема».
Даже если предположить, что руководитель проекта на это способен, то абсолютно неверно принимать решение, из-за которого возникнет проблема. Именно архитектор отвечает за то, чтоб никаких проблем не возникало.
Задача грамотного и опытного руководителя проекта выяснить, сколько ресурсов требуется на решение затянувшейся задачи, узнать аргументы для заказчика и донести всю эту информацию до заказчика. В таких ситуациях абсолютно оправдано взять с собой архитектора на совещание, чтоб он пояснил заказчику техническим языком, почему так, а не иначе.
Из всей статьи делаем простые, но очень ёмкие выводы:
1. Каждый должен заниматься в команде своим делом!
2. Качеством работы кто-то должен заниматься. Само собой оно не появляется!
Поддержите статью плюсами!
