Кто такой архитектор? Системный или функциональный? Статья 1

31.07.22

Архитектура

Часто сталкиваюсь с непониманием того, кто такой архитектор. Во многих командах эту компетенцию не используют, либо используют неверно. В связи с непониманием того, как устроен процесс разработки в сфере 1С и кто за что отвечает, будут написаны 8 статей. Это первая статья. В статье постараюсь раскрыть роль архитектора и его значимость в процессе проектирования и разработки. Основываюсь на своём опыте (более 15 лет). Для написания этой статьи изучал статьи на эту тему от коллег и консультировался с руководителями крупных команд.

Немного подробнее о причинах написания статьи:

1. Недопонимания на собеседованиях

-- Нет понимания роли и ценности позиции

-- Непонятен пул задач и зоны ответственности

-- Нет четкой иерархии подчиненности

2. Проблемы на проектах

-- Неверный выбор исполнителей по задачам

-- Наличие нерешенных задач из-за костылей

-- Ублажаем заказчика вместо выполнения проекта

3. Проекты ради проекта

-- "Странная" архитектура по задачам

-- Трудности в сопровождении/обновлении

-- Не найти крайнего по задачам

 

Все эти проблемы приводят к тому, что на проектах как во время выполнения, так и после возникает БАРДАК. Цель данной статьи помочь таким командам упорядочить процесс разработки, тем самым повысить качество работ по проектам.

 

В данной статье будут раскрыты следующие вопросы:
1.    Кто такой архитектор? 
2.    Какие задачи выполняет архитектор?

3.    Какие задачи он НЕ выполняет?
4.    Можно ли без него обойтись?
5.    Чем отличается системный архитектор от функционального архитектора?
6.    Кто главный: РП или архитектор? Кому подчиняется проектная команда?

 

  1. Кто такой архитектор?

 

Для того чтобы ответить на это вопрос, надо дать определение архитектуры.

 

Архитектура программного обеспечения – это совокупность важнейших решений об организации программной системы. Состоит из:

  •  
  • Выбора структурных элементов и их интерфейсов, с помощью которых составлена система, их поведение в рамках сотрудничества структурных элементов.
  • Способов соединения выбранных элементов структура в более крупные системы.
  • Архитектурного стиля, который направляет все элементы, их интерфейсы, сотрудничество и соединение.

 

Данное определение можно найти в интернете. Переведем это на язык 1С!

  • Архитектор определяет состав и структуру объектов метаданных и взаимосвязи между всеми объектами метаданных в рамках каждой отдельной подсистемы.
  • Каждое решение состоит из подсистем. Состав каждой подсистемы и взаимодействие между подсистемами определяет архитектор.
  • Архитектор определяет, с помощью каких объектов метаданных решать ту или иную задачу, насколько глубоко необходимо переработать типовое решение, какие объекты метаданных сделать новыми.
  • Определяет подходы к разработке интерфейсов. Определяет сценарии работы каждого объекта метаданных.

 

Как видно из определения и его перевода на язык 1С, архитектор отвечает за:

  • Структура метаданных
  • Функциональность системы
  • Отказоустойчивость системы
  • Удобство использования системы
  • Быстродействие системы
  • Простота сопровождения

 

  1. Какие задачи выполняет архитектор?

 

После того, как разобрались кто такой архитектор, можно подумать о его задачах.

Главными задачами архитектора являются (в части постановки задач):

 

Изучение информации:

  • Изучение документации. Многие бизнес-процессы в организации четко описаны в ЛНД компании.
  • Изучение бизнес-процессов. Изучаем бизнес-процессы без привязки к используемому ПО. Связано это с тем, что многие этапы существующих бизнес-процессов происходят вне ПО и требуют автоматизации.
  • Типовой конфигурации. Невозможно корректно спроектировать систему без изучения сценариев и структуры типовой конфигурации.
  • Текущего ПО. На этом этапе можно выявить задачи, которые требуют особого внимания. Также можно увидеть ошибки предыдущих команд и не повторять их.

Проектирование:

  • Состав метаданных. Принятие решения с помощью каких объектов будет решена задача
  • Определение структуры метаданных в целом и каждого объекта метаданных в частности.
  • Определение связей между объектами метаданных.
  • Наполнение системы новыми сценариями.

 

Для выполнения задач в назначенные сроки и с нужным качеством архитектор выполняет следующие задачи (в части сопровождения и приемки задач):

 

Сопровождение реализации:

  • Разъяснение постановки и сценариев исполнителям. Не стоит думать, что прочитав ТЗ исполнитель сам с ним разберётся. Можно сократить время и обсудить постановку до начала работ. Это позволяет прийти к одинаковому пониманию как у постановщика, так и у исполнителя.

  • Обсуждение способа реализации. Стоит заранее обсудить этот момент, чтоб не переделывать
  • Desing review. Этап проводится при реализации 30-40% задачи. Необходим он чтоб убедиться в правильности выбранного архитектором пути. На этом же этапе могут быть найдены дополнительные сценарии, требующие автоматизации.

Проверка реализации:

  • Проверка реализации (Code review).
  • Организация внутреннего тестирования. Проверка протокола тестирования.
  • Включение доработки в релиз.

Прочие задачи по проекту:

  • Участие в собеседованиях с целью оценки знаний в предметной области и навыков в программировании.
  • Обсуждение задач с методологами и заказчиком.
  • Предварительная оценка сроков выполнения задач.
  • Участие в разборе причин инцидентов.
  • Участие в разработке регламентов работы команды (согласование).
  • Участие в разработке технической документации (согласование).

 

  1. Чего архитектор НЕ должен делать?

 

Часто на проектах архитектору поручают не свойственные ему задачи:

Функции менеджера:

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

Оформление бумаг:

  • Написание инструкций для пользователей.
  • Описание архитектуры серверов.
  • Информационная безопасность.
  • ТЗ и ТП по ГОСТу.
  • Регламент разработки.

Прочие задачи:

  • Тим билдинг.
  • Обучение и развитие сотрудников.
  • Убеждение коллег и руководства в правильности архитектурных решений.
  • Сдача работы заказчику.
  • Консультирование пользователей.
  • Убеждение коллег исправить ошибки.
  • Поиск виноватых.
  • Соврать заказчику, потом доделаем.
  • Настройка и администрирование серверов и прочего ПО.

Пояснение некоторых пунктов:

  • Планирование сроков разработки... Да архитектор определяет что, как и в какой последовательности делать, но пока не описана архитектура и не определены сценарии угадать срок разработки невозможно. В целом планирование – это задача РП. Архитектор здесь выступает только как эксперт, но не как составитель план-графика! О сроках подробнее ниже…
  • Контроль сроков разработки по каждой задаче. Некоторые руководители думают, что обзвонить всех разработчиков и консультантов каждый день это задача архитектора. Это опять роль РП или помощника РП. Архитектору этим некогда заниматься!
  • Архитектор не должен убеждать членов команды (даже вышестоящих) в правильности своего решения. У всех членов команды разный уровень знаний и опыт работы. Архитектор (в нормальном виде) – это самый грамотный и самый опытный. Это человек, который в голове держит всю картину проекта и знающий, что как и с чем связано. Отступление от плана архитектора грозит разрухой в архитектуре.
  • Техническую документацию оформлять по ГОСТам и прочим нотациям должен Технический писатель. Исходный текст документации формируют аналитики/консультанты. Архитектор является согласующим по всей документации, но не автором.

 

  1. Можно ли без него обойтись?

 

Для ответа на этот вопрос необходимо проанализировать каждую задачу архитектора и найти на неё исполнителя. Главное обеспечить такое же качество выполнения этой задачи на уровне архитектора!

  • Выяснение требований. Часто эту задачу поручают аналитикам или консультантам. В одной из следующих статей будут описаны компетенции членов команды. Для выяснения требований надо знать и существующую архитектуру решения, и сценарии и особенности реализации. Аналитик/консультант такой компетенцией не обладает. По некоторым задачам необходимо реорганизовать бизнес-процесс для снижения трудоемкости в разработке. Для этого требуется задать вопросы в правильном ракурсе.
  • Определение структуры метаданных. Данная задача часто поручается либо аналитикам, либо разработчикам. В первом случае, аналитик – не разработчик, а значит правильно спроектировать решение не способен! Во втором случае разработчик будет искать кратчайший путь решения задачи. Он может учесть далеко не все сценарии, а только очевидные для него. Разработчик обычно не работает с данными и не в полной мере осведомлен о протекающих в компании бизнес-процессах.
  • Определение связей между объектами. Данную задачу также поручают аналитикам или разработчикам. Каждый отдельный разработчик и аналитик не в курсе всего пула задач. Следствием этого является доработка тех объектов, которые дорабатывать было нельзя, либо необходим другой способ решения задачи. Выливается это в перекладывании ответственности за неверное решение с одного на другого. В итоге никто не отвечает за возникшие ошибки, а главное никто не предусмотрел, как избежать ошибок.
  • Наполнение системы новыми сценариями. Обычно сценарии тестирования появляются после завершения разработки. Автором сценариев обычно выступает консультант. Это ужасная ошибка!!! Т.к. разработка должна вестись по конкретным сценариям! Необходимо на начальном этапе учесть все сценарии и продумать целостность решения.
  • Обсуждение способа реализации. Обычно этот этап предшествует написанию ТЗ. Участвуют в таких совещаниях все кому не лень. Люди пытаются всеобщими усилиями придумать, как же решать задачу. Т.е. в начале такого обсуждения нет ни одного человека, который знает правильный путь. Это как заблудиться в лесу и всем кричать «ау», вместо того, чтоб взять с собой проводника и GPS трекер. Desing review – это этап, цель которого выяснить, правильно ли разработчик понял постановку задачи, в правильных ли местах в коде он начал доработку. Использовал ли разработчик программный интерфейс. Как видно из описания, ТЗ уже написано! И есть человек, который знает, как правильно решить поставленную задачу!
  • Проверка реализации. В большинстве проектов, которые я видел «со стороны», этот этап либо отсутствует вовсе, либо его поручают разработчикам. Т.е. один разработчик проверяет реализацию у другого разработчика. Что происходит? Каждый разработчик знает только свои задачи. Чтоб проверить задачу, в неё нужно глубоко вникнуть! Т.к. сроки разработки всегда сжаты и уровень разработчиков разный – качество такой проверки носит лишь формальный характер. Многие не соблюдают стандарты разработки, пишут неоптимальный или нечитаемый код, не владеют способами оптимизации запросов и в целом пишут много лишнего кода. Просто поставить галочку в Jire – такой способ проверки подойдёт, однако результата от него не будет!
  • Проверка протокола тестирования. Обычно на этапе тестирования могут появиться новые сценарии (заказчик подкинул, или кто-то из членов команды). Может потребоваться повторное проектирование по новым сценариям. Минусы проектирования консультантами и разработчиками описаны выше.
  • Включение доработки в релиз. Всем знакома ситуация, когда кто-то затер чужие доработки? Это результат того, что сборкой релиза занимаются все кому не лень.

 

Если внимательно прочитать все описанные обязанности архитектора, должно быть понятно, что корректно выполнить/проконтролировать эти обязанности может только человек с большим багажом знаний и опыта – архитектор! Качественно заменить архитектора невозможно!

 

Каждый член команды должен заниматься своей работой:

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

Минусы отсутствия архитектора:

  • Нет одного ответственного. За коллективные решения никто ответственности не несёт.
  • Выдаваемые задания на разработку не связаны между собой либо ломают друг друга.
  • Не полные данные на этапе обследования.
  • Неверная структура метаданных. Проблемы при обновлении.
  • Трудности при разработке сложных алгоритмов, не оптимальные решения.
  • Проблемы при сборке релизов. Зоопарк в коде.

 

  1. Чем отличается системный архитектор от функционального архитектора?

 

В последнее время стало модным слово архитектор использовать с префиксами «функциональный» и «системный». Предлагаю разобраться, кто есть кто, а главное нужно ли 2 архитектора?

Итак, функциональный архитектор отвечает за функционал системы, за сценарное наполнение подсистем. Очень часто это НЕ программирующий человек. Он хорошо знает, как решаются различные задачи с помощью типового функционала.

В компетенции такого специалиста входят:

  • Знания обо всех подсистемах внедряемого ПО.
  • Знания о сценарном наполнении объектов.
  • Знания о существующих настройках ПО.
  • Навыки работы с большими объемами данных, способами исправления часто встречающихся ошибок.
  • Навыки сбора и систематизации информации от пользователя.

 

Кто же такой системный архитектор? Это, прежде всего технический специалист и разработчик. В компетенции такого специалиста входят:

  • Знания обо всех подсистемах внедряемого ПО.
  • Знания о сценарном наполнении объектов.
  • Знания о существующих настройках ПО.
  • Навыки работы с большими объемами данных, способами исправления часто встречающихся ошибок.
  • Навыки сбора и систематизации информации от пользователя.
  • Знания об объектах метаданных, правилах их использования.
  • Знания о построении объектов метаданных с точки зрения кода.
  • Знания о способах оптимизации запросов и кода в целом.
  • Знания о стандартах разработки.
  • Знания о серверной архитектуре (опционально).
  • Знания о настройке SQL, администрировании баз (опционально).

 

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

  • Постоянный конфликт мнений. Обусловлен он глубокими знаниями архитектуры решения «изнутри». Часто проектируя решения, функциональный архитектор ищет просто кратчайший путь с минимальными доработками. Системный архитектор ищет правильный путь, который верно впишется в концепцию решения, будет оптимально работать по производительности, не нарушит обновляемость системы.
  • Оба архитектора будут работать в пол силы. Обычно это 2 высокооплачиваемых специалиста.
  • Нет единого центра принятия решений. Возможен постоянный поиск виноватых, то на стороне постановки задачи, то на стороне реализации.

 

Поэтому если и есть так называемый функциональный архитектор, то он должен подчиняться системному архитектору! Однако можно такому специалисту доверить управление группой аналитиков и консультантов. Такая связка исключает конфликт мнений. Каждый занимается своей задачей и стремится сделать её максимально качественно. Качество – это главный критерий при принятии решений на проекте.

 

  1. Кто главный: РП или архитектор? Кому подчиняется проектная команда?

 

Вечный вопрос: «Кому подчиняется команда?». Не так ли? Можно ли найти в этом вопросе компромисс? Попробуем разобраться.

Для этого разберемся с зонами ответственности РП и архитектора.

Итак, руководитель проекта отвечает за:

  • Коммуникации между проектной командой и заказчиком.
  • Учет выполняемых задач.
  • Составление регламентов работы.
  • Контроль сроков по выполняемым задачам.
  • Мотивация членов команды (в т.ч. KPI).
  • Развитие компетенций, обучение.
  • Составление отчетности по состоянию проекта перед заказчиком.
  • Согласование отсутствий.
  • Team building.
  • Управление бюджетом проекта (опционально).

 

В свою очередь архитектор отвечает за:

  • Архитектуру решений.
  • Качество кода.
  • Качество/полноту сценариев работы.
  • Техническую документацию.
  • Способы устранения ошибок в данных.
  • Настройки учета.
  • Назначение исполнителей по задачам.
  • Последовательность выполнения задач.
  • Оценка компетенций членов команды.

 

Как видно из описания, руководитель проекта не несет никакой ответственности за качество выполненной работы. Да естественно, ему в первую очередь выскажут претензии за отсутствие качества. НО! Роль РП предусматривает просто принести все претензии команде, узнать, кто и когда их устранит. РП не будет вместе с Вами до ночи программировать или разбирать пользовательские ошибки.

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

Из этого можно сделать вывод, что по административным вопросам, по коммуникациям и т.д. вся команда подчиняется РП. Но абсолютно недопустимо, когда РП ставит задачу хоть программистам, хоть консультантам без согласования с архитектором.

Из этого можно сделать второй вывод, что по техническим вопросам вся команда подчиняется архитектору. Если архитектор утвердил или отверг тот или иной вариант решения задачи, то никто из команды не вправе менять решение архитектора. Даже всемогущий руководитель проекта не имеет на это права. Т.к. я не знаю ни одного РП, который способен заказчику прямо сообщить: «Это я сказал архитектору сделать так (сроки поджимали, или денег нет в проекте на это), и это из-за меня возникла такая проблема».

Даже если предположить, что руководитель проекта на это способен, то абсолютно неверно принимать решение, из-за которого возникнет проблема. Именно архитектор отвечает за то, чтоб никаких проблем не возникало.

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

 

Из всей статьи делаем простые, но очень ёмкие выводы:

1. Каждый должен заниматься в команде своим делом! 

2. Качеством работы кто-то должен заниматься. Само собой оно не появляется!

 

Поддержите статью плюсами! 

Архитектор системный архитектор функциональный качество разработки разработка проект программирование управление проектом.

См. также

Как мы автоматизировали башню раздачи воды

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1614    0    slavik27    4    

14

Управленческие аналитики для 1С:Бухгалтерии – отчеты для принятия верных решений

Отчеты и дашборды Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    1836    0    Serg_Tangatarov    2    

15

Архитектурное ревью. Процесс разработки

Архитектура решений Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    4197    0    ivanov660    10    

30

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    2096    0    user1754524    15    

16

Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

29.08.2023    3082    0    ke_almaty    0    

14

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

Нашей компании часто приходится сталкиваться с обновлением конфигураций разной степени переписанности. Какие-то из них обновляются легко, какие-то — не очень. Расскажем о некоторых принципах модификации программы, которые помогут сделать последующий процесс обновления легче. Или тяжелее, если стараться их не соблюдать.

10.08.2023    10004    0    1c-izhtc    37    

22

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

Стабильное качество выпускаемой продукции и ее соответствие нормативным документам (ТУ, ГОСТам, СМК) для активного предприятия является конкурентным преимуществом, так как оно подчеркивает, что на предприятии отлажены контрольные процедуры на входящее сырье, производство полупродуктов и готовой продукции, доставки. В своей практике я принимал участие во внедрении цифровых инструментов в сельском хозяйстве, где показателями зерна служат влажность, засоренность, крупность и т.д.; в металлургии — перед литьем в формы надо проверить сплав на содержания железа, алюминия, магния и т.д.; в кабельной промышленности в дополнение к физическим свойствам типа геометрии, длины, шероховатости, надо выдерживать и электротехнические показатели. 

22.05.2023    1547    0    Ingraf    0    

16
Отзывы
44. sapervodichka 6823 02.07.20 00:05 Сейчас в теме
Мне понравилась данная статья, т.к. в моей жизни реально происходит то, о чём пишет автор. Приходится общие концепции в разработке контролировать у групп программистов. Обидно только, что оплату и полномочия архитектора не каждый РП выделяет на своём проекте (т.к. придётся премией делиться к архитектором) и часто время за концепт и целостность продукта оплачивается по той же ставке, что и разработка отчета или документа. Короче фигня такая *)
AllexSoft; AlbinaAAA; 1v7; SpecRam; MishinVl; gmw; newtraveller; Senator_I; user1525327; blindcat2006; Ta_Da; +11 Ответить
80. vow 08.11.21 14:16 Сейчас в теме
Очень грамотно все расписано, опыт чувствуется огромный, и прям каждый пункт того, что НЕ должен делать архитектор всплывает в памяти яркими фантомными болями))

С какими-то вещами полностью согласен, с какими-то можно спорить и обсуждать, но один тезис вызывает прям полное отторжение!
Планирование сроков разработки... Да архитектор определяет что, как и в какой последовательности делать, но пока не описана архитектура и не определены сценарии угадать срок разработки невозможно. В целом планирование – это задача РП. Архитектор здесь выступает только как эксперт, но не как составитель план-графика! О сроках подробнее ниже…
Нельзя награждать задачей планирования срока проекта одного РП. Архитектор угадать не может, а у РП появился хрустальный шар? Что ж вы так своего РП-шника то подставляете)) Из этого не выйдет ничего хорошего, если только целью реализации проекта со стороны архитектора не является заработать деньги и уйти на новый проект. Я, как РП, не скажу ни слова про срок реализации Заказчику, пока архитектор кровью не распишется и не защитит каждую неделю разработки (иного этапа). Иначе, погнали в пацанский эджайл.
GorkyGorod; user1145418; anastasija182; biimmap; +4 Ответить
Остальные комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. barelpro 1370 29.06.20 23:30 Сейчас в теме
Немного не понятно как быть на крупных проектах? В одно лицо уточнить задачи, придумать решение, поставить задачу, проверить реализацию, собрать релиз - бутылочное горлышко. Все в итоге будут работать в пол силы или имитировать бурную деятельность пока бедолага рвёт базис на британский флаг! Мой опыт подсказывает иерархию архитекторов по направлениям, с одним корневым. Под каждым архитектором три- пять разрабов.

А в целом разумная статья!
engely; Belka5542360; GAVe; +3 1 Ответить
2. shmalevoz 306 30.06.20 08:34 Сейчас в теме
(1) Просто проект имхо должен начинаться с создания архитектерного каркаса - интерфейсов, заготовок объектов, ... На это тратится до месяца, а дальше можно этот каркас наполнять смыслом в порядке приоритетов. Тогда задачи ставятся на 70% комментариями к методам, там должен быть контракт метода. Заодно можно и поставить требование перед кодом покрыть решаемое тестами. В код ревью и тем паче сборке очень неплохо помогают средства автоматизации. Архитектор имхо лучше когда один, если есть деление на группы, то там "старшие" групп. Но не архитекторы.
Спасибо за статью.
vladimir-89; Irwin; CreateNewUser; barelpro; +4 Ответить
8. barelpro 1370 30.06.20 12:07 Сейчас в теме
(2)
Тогда задачи ставятся на 70% комментариями к методам, там должен быть контракт метода


Интересно!
А где про этот метод можно почитать подробнее?
9. shmalevoz 306 30.06.20 12:21 Сейчас в теме
(8) Как раз на главной странице странице ссылка на книгу
Не спеша эффективно и правильно
там есть про это в Базовые методы проектирования, в частности про Черный ящик и особенно Первородство спецификации
а аннотации начинают писаться если обязать всех использовать шаблоны, в которых есть заготовки комментариев. ну и просто не пропускать методы без описания. через пару месяцев приходит привыкание =)
10. barelpro 1370 30.06.20 12:24 Сейчас в теме
(9) а, ок, спасибо! Как раз эту статью отложил для чтения на выходные )))
87. GAVe 08.09.22 14:34 Сейчас в теме
(1) Подтверждаю, что на крупнейших проектах сама фирма 1С пользуется именно таким подходом, один главный архитектор, за каждый блок отдельный архитектор.
А предложенное barelpro явное ограничение управления в 3-5-7мь человек позволяет с большей вероятностью ожидать прямого управленческого воздействия от ответственного архитектора на разработчиков (а не стихийного разделения большой группы программистов на несколько подгрупп с их лидерами, безответственно /ведь ответственность им не назначали/ внедряющими свои подходы в разработку).

P.S. Конечно, может и удача улыбнуться с лидерами, но статья явно про гарантированный успех проекта с архитектором.
3. awk 742 30.06.20 08:55 Сейчас в теме
Статья - отличная. Читается легко, почти нет воды. Одна из немногих, которую читал не по диагонали.

Однако возник вопрос:

Как

Наполнение системы новыми сценариями. Обычно сценарии тестирования появляются после завершения разработки. Автором сценариев обычно выступает консультант. Это ужасная ошибка!!! Т.к. разработка должна вестись по конкретным сценариям! Необходимо на начальном этапе учесть все сценарии и продумать целостность решения.


может сочетаться с

Каждый член команды должен заниматься своей работой:

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


И складывается впечатление, что архитектор - это сверхчеловек, что очень сомнительно, для людей не верящих в Деда Мороза.
Yakud3a; for_sale; ivanov660; a.abelentsev; Aluvika4; +5 1 Ответить
5. biimmap 1917 30.06.20 09:51 Сейчас в теме
(3) Имелось ввиду, что консультант не должен быть единственным автором сценариев. Их необходимо согласовывать с архитектором и бизнес-заказчиком. Любое требование бизнеса должно переводиться в сценарии.

Что касается Деда Мороза - это как верить в Бога... Каждый сам выбирает верить ему или нет! Однако на своих проектах я и есть тот самый Дед Мороз))

Спасибо что внимательно читали.
6. awk 742 30.06.20 10:00 Сейчас в теме
(5) Боюсь, что если добавить роль "Тестировщика" и "Ведущего тестировщика", то сценарии тестирования/использования уйдут на него и роль Архитектора не будет выглядеть как роль "Супермена". Я правда только на одном предприятии такую роль видел, а точнее целый отдел.

А вообще про архитектора очень хорошо написано в книге "Унифицированный процесс разработки" https://krupoderovakr.files.wordpress.com/2014/02/d0b0-d18fd0bad0bed0b1d181d0bed0bd-d0b3-d0b1d183d187-d0b4d0b6-d180d0b0d0bcd0b1d0be-d183d0bdd0b8d184d0b8d186d0b8d180d0bed0b2d0b0d0bd.pdf
7. biimmap 1917 30.06.20 10:05 Сейчас в теме
(6) Речь в согласовании, а не написании! Пишет в любом случае аналитик/консультант, можно тестировщик, если такой есть выделенный. Я за всё время видел только 2-х человек, которые могут найти дырки в куске масла (не сыра! а именно масла). Это редкая компетенция.
84. ntv580 09.02.22 23:41 Сейчас в теме
(3) Не поверите, но так оно и есть и в этом случае достигается максимальный эффект
4. AlbinaAAA 1434 30.06.20 08:59 Сейчас в теме
Очень полезная статья, спасибо за труд. Жду следующие статьи!
11. rossoxa 164 30.06.20 14:07 Сейчас в теме
Отличная статья. Очень точно и грамотно. Спасибо
12. xrrg 325 30.06.20 22:49 Сейчас в теме
Надеюсь, мы скоро дождёмся статьи про истинно верное написание проектной документации.
so-quest; papami; +2 Ответить
14. biimmap 1917 30.06.20 23:19 Сейчас в теме
(12)Вы знаете именно этой темы в запланированных 8-ми статьях нет. Причина тому - некачественные разработки довольно неплохо документируют)))
40. xrrg 325 01.07.20 17:40 Сейчас в теме
(14) Экстравагантное мнение. То есть чем меньше документации (желательно чтоб на рулоне туалетной бумаги была написана от руки), тем лучше сделан проект? Есть ГОСТ на это дело. Вижу слово ТЗ, а слова ТП не вижу. Вы имеете опыт написания подобного документа? (Подсказка: это прямая обязанность архитектора)
41. biimmap 1917 01.07.20 17:46 Сейчас в теме
(40) Вы неверно прочитали мой ответ. Немного расшифрую: Цель статей - поднять качество разработки в крупных проектах. Ибо количество теплокодеров просто зашкаливает. При этом на всех проектах документации хоть дома из неё строй. Поэтому не вижу смысла описывать как должны проекты документироваться, т.к. здесь проблем на проектах не так много. Сначала надо разработку вести правильно! Соблюдать стандарты и т.д. Мне приходилось делать абсолютно всё в т.ч. в одно лицо. Ответ же связан не с моим опытом, а с направленностью всего цикла статей.
42. xrrg 325 01.07.20 17:51 Сейчас в теме
(41) у вас есть опыт подготовки проектной документации?
13. 1СERP 3058 30.06.20 23:17 Сейчас в теме
Все понял, кроме одного. С чего это такой ограниченный функционал у РП?
Управление качеством - ключевая задача РП. Как он этого добьётся - отдельная задача. Сам - эксперт. Привлекает эксперта (Архитектора). Ещё какие-то варианты...
В том варианте, который описан, РП - это, скорее, администратор проекта.
Мы так пробовали - не сработало.
15. biimmap 1917 30.06.20 23:21 Сейчас в теме
(13) Я ждал этого вопроса... Отвечу кратко: РП - обычно человек с чек-листом, которому некогда вникать в суть. Ему надо просто знать когда. Архитектор - обратная сторона монеты. Просто каждый должен быть на своем месте. Орел и решка не могут быть с одной стороны монеты!
AllexSoft; user750576; +2 Ответить
16. alex_sayan 01.07.20 06:41 Сейчас в теме
Статья слишком абстрактная. Автор, попробуй расписать:
- какие цели у архитектора и разработки архитектуры
- что является показателями хорошей и плохой работы архитектора
vaskomain; +1 1 Ответить
21. biimmap 1917 01.07.20 09:55 Сейчас в теме
(16) Есть ощущение, что задачи архитектора это оно и есть.
А вот про показатели хорошей и плохой работы действительно стоит добавить...
17. пользователь 01.07.20 08:27
Сообщение было скрыто модератором.
...
31. biimmap 1917 01.07.20 14:30 Сейчас в теме
(17) Что вижу в этом посте:
1. Вам не дают архитекторы принимать самостоятельные решения, а убедить их аргументами наверно не получается.
2. Аргументированная дискуссия лишь в том случае, если аргументы направлены на улучшение решения. Могу только предположить, что более опытный архитектор отклоняет аргументы, т.к. они направлены на упрощение разработки, а не на улучшение качества и целостности системы.
3. Вижу прямое оскорбление в адрес всех архитекторов. Автор комментария их считает остолопами.

Я здесь не вижу ни одного аргумента, почему архитектор не является самым грамотным на проекте.

К примеру на одном из моих проектов тим лид пыталась меня всё время склонить в сторону более быстрых и некачественных проектов. Ессно она получала от меня отказ. И якобы я был плохой. Но от тех решений, которые она продавливала плевались и тестировщики и заказчики!

Именно поэтому данный комментарий я склонен игнорировать полностью.

Предлагаю Вам взять на себя ответственность за весь проект и стать архитектором. Тогда Вам никто не будет указывать как делать. Это будет полностью сфера Вашей ответственности.

Здесь от меня нет перехода на личности. А от Вас есть оскорбления и эмоции.
marinakomarova89; AlbinaAAA; vaskomain; +3 3 Ответить
33. пользователь 01.07.20 14:50
Сообщение было скрыто модератором.
...
34. biimmap 1917 01.07.20 14:52 Сейчас в теме
(33) Коллега, в моё посте нет эмоций. Ваш наполнен ими и оскорблениями. Спасибо за "участие".
marinakomarova89; AlbinaAAA; +2 2 Ответить
46. da.buraev 02.07.20 02:18 Сейчас в теме
(31) Сколько эмоций.
for_sale; +1 Ответить
18. пользователь 01.07.20 08:34
Сообщение было скрыто модератором.
...
32. biimmap 1917 01.07.20 14:46 Сейчас в теме
(18) Что в этом посте написано:
1. Архитектор может выяснить детали только у технического специалиста.
2. Архитектор не должен знать предметную область.
3. Аналитик может выяснить требования в общих чертах и передать архитектору.
4. Архитектору со знанием предметной области будет сложно поддерживать свои знания актуальными во всех сферах.

Отвечу на каждый пункт:
1. Здесь нет ни одного аргумента, почему вдруг архитектор не может выяснять потребности у заказчика? Скорей всего автор опирается на следующий пункт (нет знаний в предметной области).
2. Моя статья в п. 5 описывает кто такой системный архитектор. Мне крайне тяжело в среде 1С (а именно об этом моя статья) представить архитектора ЕРП, который не знает производство и ни разу не был в цеху. Также и здесь, если архитектор не знает предметную область - это не архитектор, а всего лишь ведущий разработчик! Вы описываете ситуацию, когда на проекте нет архитектора и его обязанности исполняет ведущий разработчик! Это очень плачевная ситуация. Я в свое статье рассказываю, что так быть не должно ни в коем случае!
3. В п.4 своей статьи я описал недостатки того, что аналитик выясняет суть задачи. Когда аналитик дойдёт до архитектора, то получится испорченный телефон, который уже забыл половину разговора с заказчиком (таково устройство памяти). Да действительно по некоторым отдельным задачам архитектор может и должен поручать аналитику такую работу. Но в этом случае аналитик получает инструкции от архитектора, какие вопросы требуется выяснить. И потом в несколько итераций аналитик приносит информацию архитектору, пока не будут даны развернутые ответы на поставленные архитектором вопросы.
4. Архитектор не может и не должен работать в разных областях. Я лично (тут на свою личность перейду) работаю в сфере зарплаты. Другие сферы я не знаю и даже знать не хочу. Конечно невозможно быть архитектором в нескольких предметных областях. Это крайне сложно. Также в помощь архитектору на проекте есть МЕТОДОЛОГ. Но аналитик - это не методолог. Если говорить об одной задаче, то да аналитик может и должен помочь. Но моя статья написана про проект в целом! И здесь аналитик не может проектировать архитектуру всего проекта, и даже 5 аналитиков на это не способны. они должны подчиняться одному центру принятия решений!

Здесь тоже не вижу аргументов по моей статье. Здесь описан Ваш опыт, и к сожалению - он неправильный! Так быть не должно! Именно для этого написана моя статья.
35. пользователь 01.07.20 15:48
Сообщение было скрыто модератором.
...
51. Casey1984 3 03.07.20 22:55 Сейчас в теме
(35) Поддерживаю полностью.
for_sale; +1 Ответить
19. пользователь 01.07.20 09:01
Сообщение было скрыто модератором.
...
22. biimmap 1917 01.07.20 10:10 Сейчас в теме
(19)
чушь??? Вы название хотя бы прочитайте!
"Аналитик"! Чем должен

К сожалению, чушь пишите Вы! И данная статья направлена ровно на таких как Вы.
Я часто в своей практике встречаю проекты, в которых либо нет архитектора вообще, либо архитектор только функциональный. И никто не контролирует процесс разработки.

С этим связаны например такие постановки (моей подруге на днях поставили задачу):
Необходимо создать отчет для сверки соответствия плановых начислений тем, что предусмотрены по штатному расписанию. Дальше пишут: Данные необходимо собирать по документам "Кадровый перевод" и "Изменение оплаты труда".

Такая постановка содержит 2 грубейшие ошибки, которые наверно каждый заметит:
1. Ни один нормальный разработчик не должен собирать данные по документам, если документы имеют движения! К таблице можно обратиться, если документ НЕ делает движений. А здесь необходимо использовать программный интерфейс, который получает данные из интервального регистра сведений. Для начислений по штатному расписанию также есть программный интерфейс!
2. Почему вдруг сверять нужно только изменения??? Почему аналитик НЕ ПРОАНАЛИЗИРОВАЛ, что при приеме на работу также можно назначить неверные начисления? Или штатное расписание могло измениться после приема на работу! Трудно было догадаться?

Так вот архитектор таких ошибок глупых не допускает!

Поэтому Ваше мнение проигнорирую. Аргументы у Вас слабые. Я основываюсь на своём опыте и на достижении результата, а не на названиях.
marinakomarova89; barelpro; +2 5 Ответить
23. ivanov660 4359 01.07.20 11:02 Сейчас в теме
(22)Каждый должен заниматься своими обязанностями.
У вас идет перекос обязанностей в сторону архитектора. Как в поговорке - и жнец и на дуде игрец.
Архитектор должен держать в голове укрупненный каркас и должен контроллировать процесс сборки этой констркуции.
Далее в зависимости от процесса разработки существуют различные наборы команд, в которых различные роли и обязанности.
В итоге - у вас есть кейс, он рабочий в определенных условиях, но не единственный.
NataliaZh; VVi3ard; d4rkmesa; Casey1984; improg; sapervodichka; for_sale; +7 Ответить
26. biimmap 1917 01.07.20 13:38 Сейчас в теме
(23)
Архитектор должен держать в голове укрупненный каркас и должен контроллировать процесс сборки этой констркуции.
Я согласен с Вашей формулировкой и не вижу отклонений в своём тексте. Архитектор должен участвовать во всех ключевых процессах и контролировать их. Последнее слово по техническим решениям за архитектором, а не за РП или аналитиком не дай бог. И главное чтоб он вообще был! Вот об этом статья!
67. VVi3ard 52 20.09.21 15:18 Сейчас в теме
(26)
Что / откуда брать для очтёта это не задача архитектора. Подобные вопросы должен решать консультант/аналитик/проектировщик/постановщик задачи.
В принципе для проектирования отчетов архитектор не особо нужен.

И задачи архитектор если и ставить то явно не обычным исполнителям.

Статья интересная, но есть лишние функции:
*Выпуск релиза это отдельная роль (обычно релиз менеджер).
*Сценарии тестирования (проектировщик, постановщик задачи, разработчик, специалисты отдела тестирования)

Но главное что отсутствуют проектировщики, постановщики задач. На крупном проекте где хотя бы 8 разработчиков, архитектор просто физически не сможет ставить задачи в таких объёмах, при этом писать тестовые сценарии.

Единственная первоочередная задача архитектора это контроль изменений в архитектуре решения, и это примерно 10% от всех заявок. Большинство заявок это выгрузки/загрузки/отчеты/обработки.

Максимум что может успевать делать архитектор на крупном проекте это просматривать уже готовые задачи на разработку.
NataliaZh; +1 Ответить
69. biimmap 1917 20.09.21 15:21 Сейчас в теме
(67) не знаю огорчу или порадую... Но успеваю гораздо больше)))

Что касается отчетов на 90% согласен никакой архитектор там не нужен, сами справятся. НО! Отчеты бывают регламентированные, отчеты бывают сложные. Иногда информации в конфе недостаточно для формирования отчетов. И вот тут надо правильно добавить эту информацию.

Почему написал об этом, потому что видел, как аналитик пишет разработчику задачу: Создать документ... Создать отчет, данные взять из документа. Про регистр ни слова. Вот в таких ситуациях на отчетах нужен архитектор.
74. VVi3ard 52 20.09.21 15:50 Сейчас в теме
(69) Аналитик разработчику писать не должен, он может писать это проектировщику/постановщику задач а дальше уже как проектировщик решит, и если архитектор согласует.
75. biimmap 1917 20.09.21 15:53 Сейчас в теме
(74) Тут наверно речь про мегапроекты... Мой профиль ЗУП, тут проекты поменьше... И главное знаешь что в статье? не то, что исполнитель даже... Главное качество выполнения и главное, что все этапы жизненного цикла задач выполнялись. Потому как многие этапы не выполняются или делаются с ужасным качеством. Поэтому главное качество, а как предложенную мною модель использовать и двигать туда сюда, решат руководители соответствующих проектов.
24. a.abelentsev 126 01.07.20 11:42 Сейчас в теме
28. biimmap 1917 01.07.20 13:43 Сейчас в теме
(24) приветствую. даже интересно что ты имел ввиду. Для публики: Артур был мои руководителем, когда я приехал в Москву. Работал я просто программистом по ТЗ от аналитика.
25. пользователь 01.07.20 11:50
Сообщение было скрыто модератором.
...
27. пользователь 01.07.20 13:41
Сообщение было скрыто модератором.
...
29. пользователь 01.07.20 13:46
Сообщение было скрыто модератором.
...
30. пользователь 01.07.20 13:48
Сообщение было скрыто модератором.
...
37. barelpro 1370 01.07.20 16:04 Сейчас в теме
(19)

Для начала надо уточнить, что в 1С-проектах используются системные аналитики. Бизнес аналитики как правило являются заказчиками для системных аналитиков. Системный аналитик - это файервол между бизнесом и командой разработчиков. Берёт на себя все первичные разговоры с бизнесом, проверяет адекватность и реалистичность, систематизирует, отсеивает шлак, и выдает команде в краткой содержательной форме основной смысл хотелок. Далее после того как РП проверил эти хотелки на входимость в рамки проекта, можно сделать второй подход к бизнесу с уточняющими вопросами. Вот тут уже могут быть варианты, кто пойдет - аналитик или архитектор. О правилах ролевой игры проектная команда договаривается внутри себя заранее. Тут главное слово скорее за РП.
Многое зависит от кадровой составляющей - если достался сильный аналитик и никакой архитектор (который максимум тянет на релиз менеджера) - это беда! Если наоборот - в принципе архитектор конечно вытянет две функции, но есть риск что поплывут либо сроки либо качество.
Это касается первой фазы проекта - постановка, проектирование, моделирование.
На второй фазе (разработка и внедрение), когда основные хотелки уже выявлены, аналитик нужен разве что для проверки уточненных требований на соответствие скопу проекта. Его функции плавно перетекают в то, о чем написано в статье. Либо аналитик вообще уходит.
38. gavlexx 39 01.07.20 17:22 Сейчас в теме
Архитектор должен выяснять у Заказчика требования? При разделении труда - точно нет. Только если он же - и выясняет, и строит архитектуру и программирует.
Но цикл статей же не о "на-все-руки-мастеров-1С", верно? :)
VVi3ard; Casey1984; Grania; for_sale; +4 Ответить
39. biimmap 1917 01.07.20 17:30 Сейчас в теме
(38) Вечер добрый. Почему люди размышляют ОДНОЙ ЕДИНСТВЕННОЙ ЗАДАЧЕЙ? Статья написана про проект в целом. Проект состоит из множества задач. И всё это множество между собой связано! И только в этом ракурсе необходимо воспринимать написанное! Я написал про КОНЦЕПЦИЮ, т.е. АРХИТЕКТУРУ.
Могу сотнями приводить примеры, где Аналитик, так восхваляемый некоторыми, приносил от Заказчика вообще не то. Просто не понял смысл задачи. В таких случаях возникает сомнение в правдивости принесенной информации. Выясняю сам - получаю совсем другие ответы.
ntv580; Yashazz; +2 2 Ответить
68. VVi3ard 52 20.09.21 15:20 Сейчас в теме
(39)
(38) Вечер добрый. Почему люди размышляют ОДНОЙ ЕДИНСТВЕННОЙ ЗАДАЧЕЙ? Статья написана про проект в целом. Проект состоит из множества задач. И всё это множество между собой связано! И только в этом ракурсе необходимо воспринимать написанное! Я написал про КОНЦЕПЦИЮ, т.е. АРХИТЕКТУРУ.


Вот почитать то что принес аналитик и наложить это на реализацию, после чего задать вопросы или вообще забраковать отчёт это как раз и есть задача архитектора.

У вас же получается что он должен поехать к заказчику, провести интервью, подготовить отчёт и.т.п. это выглядит странно.
70. biimmap 1917 20.09.21 15:24 Сейчас в теме
(68) Да есть перегибы в статье! Для этого стучусь на Ивент московский... Там чуть мягче рассказываю. Но перегибы полезны тем, что позволяют определить границы! В каких-то задачах можно поручить аналитику... А есть задачи, которые без шуток постановку не могут понять 5-7 человек подряд. Иду делать сам) Можно покидать камни что не умею ставить... Но нет, вопрос в сложности и объёмности задачи.
85. ntv580 09.02.22 23:53 Сейчас в теме
(37)
(70) Полностью согласна с автором статьи. Никто лучше архитектора (хорошего архитектора с большим опытом и багажом знаний) не сможет проговорить задачу с бизнесом, разложить ее на детали и запустить в реализацию. Аналитик с этим не справится
43. Yashazz 4734 01.07.20 20:04 Сейчас в теме
Трепология ни о чём. Пустое умствование. И знаете почему? Потому что а) использующие архитекторов имеют своё видение, оно у них как откровение свыше, альфа и омега, пуп их знания о проекте, и переубеждать бесполезно; б) не использующие архитекторов свято убеждены, что без них всегда жили и дальше прокатит; в) ничто не влияет на процесс внедрения и эксплуатации системы меньше, чем наличие/отсутствие и качество архитектора на проекте.
kondrashka; pro-rok; user700897_nkt1c; Maxisussr; Ta_Da; akimych; vaskomain; Grania; +8 4 Ответить
56. blindcat2006 91 12.07.20 17:07 Сейчас в теме
(43) Поднялась рука оценку поставить за емкий комментарий... да не знаю какую кнопку нажать

а) и б) - плюсую ++ (2"+")
в) - люто минусую. Ибо дело на в личностях и строчках приказа о приеме на работе. ВЛИЯЕТ. И сильно. только архитектор не обязательно отдельно сидящая на троне личность с нимбом в виде непомерной ЗП (как тут некоторые писали).
Им может быть и программист въедливый и не ленивый (да таких сейчас редко делают).
И консультант дотошный (и как раз ленивый) которому надоедает тысячный раз дописки делать и начинает он системно к вопросам подходить.
Потому извините - оставлю Вас пока без оценок ))
Артано; +1 Ответить
57. Yashazz 4734 12.07.20 20:50 Сейчас в теме
(56) Видите ли, может оказаться замечательный программист, отличный методист, и выйдет прекрасный продукт. Может оказаться криворукий кодер и ленивый пофигист-методист. Но и в том, и в ином случае собственно внедрение и работа системы будут зависеть совершенно от другого - от настырности руководства автоматизаторв и РП, от упёртости руководства автоматизируемых, от политических подковёрных игр, дележа власти и денег, заказов, траншей, контрактов и прочая. В результате у замечательной разработки и у адской стрёмной поделки почти равные шансы (поделка даже лучше, она такая примитивная и понятная, что интуитивно кажется доступной и потому "нормуль" с точки зрения командующих дилетантов). И-таки мыши будут колоться, да жрать кактус. Независимо от вклада тех, кто оный кактус растил и поливал... Вот я о чём.
blindcat2006; +1 Ответить
58. biimmap 1917 12.07.20 22:13 Сейчас в теме
(57) В какой-то степени Вы правы. Но на своих проектах я всегда стаскиваю руководство с небес на землю и тыкаю в правду. Т.к. я не занимаюсь политическими играми (я не РП. а технарь), то руководству приходится смотреть в правду и проект идёт как надо!
На моих проектах именно мой опыт позволяет избегать политики.
59. Артано 764 06.01.21 11:32 Сейчас в теме
(56) Истина & Ложь = Ложь. Лепи минус смело за претенциозные обобщения (за что, в том числе, Яша и обвинял автора).
44. sapervodichka 6823 02.07.20 00:05 Сейчас в теме
Мне понравилась данная статья, т.к. в моей жизни реально происходит то, о чём пишет автор. Приходится общие концепции в разработке контролировать у групп программистов. Обидно только, что оплату и полномочия архитектора не каждый РП выделяет на своём проекте (т.к. придётся премией делиться к архитектором) и часто время за концепт и целостность продукта оплачивается по той же ставке, что и разработка отчета или документа. Короче фигня такая *)
AllexSoft; AlbinaAAA; 1v7; SpecRam; MishinVl; gmw; newtraveller; Senator_I; user1525327; blindcat2006; Ta_Da; +11 Ответить
45. biimmap 1917 02.07.20 00:45 Сейчас в теме
(44) Спасибо тебе добрый человек за твой комментарий)))
47. vaskomain 03.07.20 08:05 Сейчас в теме
Автор, начну с того, что очень детально и качественно разложил свой личный опыт организации работ, очень структурного. Честь и хвала. Далее пойдут замечания, которые направлены не для того чтобы критиковать, а чтобы улучшить качество работы.
1. Это все-таки личный опыт, поэтому очень напрягает безапелляционный стиль повествования - вот так должно быть и все! Возможно это следствие способа организации работ в команде - см. далее
2. Путаница между функциональным и системным архитектором не прояснилось даже после статьи. Если сделать вывод по формулировка, то функциональный архитектор у вас в принципе не нужен, так как ему делегируется часть работы системного, по вашему описанию - это сотрудник в команде системного администратора
3. Исходя из этого системный архитектор на себя натягал столько практик, что у него в голове может (и всегда так бывает) возникнуть ошибка заинтересованности. Дело в том что между функциональными требованиями (требованиями заказчика) и требованиями архитектуры (как уже все встроено в системе) всегда есть конфликт. И основная задача процесса проектирования системы - решить этот конфликт. Увы если этот конфликт будет в голове архитектора, то чаще программные практики возьмут вверх над требованиями заказчика (производство над продажами)
4. Поэтому лучшие практики выделяют роль руководителя продукта, который отвечает за удовлетворение требований заказчика. И в этом случае искусство и задачи архитектора системы заключаются в том, чтобы с проектировать максимально эффективную систему, для удовлетворения требований заказчика. И здесь не речь о том кто кому подчинении - руководитель продукта или системный архитектор - не надо их подчинять. Здесь речь о том, что требования к архитектуре системы подчинены требованиям заказчика. Требования, а не люди
5. Ну и работа в команде (насчёт безапелляционности). Мой личный опыт 20-летнего управления разработкой подтверждает мировой опыт - командная работа эффективнее иерархической по всем параметрам - скорость, качество, адекватность требованиям. Поэтому меня напрягают такие пассажи, как Архитектор никому ничего не должен доказывать - это и снижение качества отношений в команде, и отсутствие возможности обучения для команды, отсутствие тройной валидациии прочие факторы снижающие эффективность.
6. Немного о тройной валидациии - разработал требование, проверил сам - первая, рассказал команде - получил обратную связь, вторая, команда несогласилась, подробно изложил, почему так решил - третья
7. Ну и для тех кто дочитал - прочтите курс Левенчука Системное мышление - есть В свободном доступе, очень помогает все по полочкам разложить относительно всех терминов со словом системное
AllexSoft; astrius; AleksAaron; GAVe; SpecRam; marinakomarova89; Артано; biimmap; +8 Ответить
48. vaskomain 03.07.20 08:05 Сейчас в теме
(47) прошу прощения за опечатки, писал в телефоне, пока ехал на работу
49. biimmap 1917 03.07.20 10:33 Сейчас в теме
(47) Спасибо за аргументированные адекватные комментарии. Немного отвечу на некоторые пункты:
1. Да лично я действительно не понимаю как не программирующий человек может проектировать архитектуру. Здесь могу десятками приводить примеры из моего опыта, где это потом становилось необновляемым.
2. Нет безаппеляционности. Есть стремление показать, что при грамотном архитекторе (как коллега назвал супер архитектор), которому подчиняется вся команда можно достичь наиболее высоких результатов.
3. Всегда поясняю свою точку зрения команде! Т.е. в моей статье не написано, что я не должен пояснять!!! Просто члены команды люди с разным опытом. И для того, чтоб понять какие-то мои решения нужно иметь мой опыт. В таких ситуациях люди говорят: я всё равно не согласен (или не согласна). И вот тут решения архитектора должно быть весомее просто несогласия. Причем многие реально даже не могут аргументировать своё несогласие. Часто просто хотят оставить своё решение и всё.
4. Дело в том, что у меня конфликта не возникает! Для меня бизнес-требования - это то, что обязательно нужно сделать. А вот как это сделать, чтоб не сломать систему - вот тут приходится хорошо подумать! Иногда действительно уточняю у заказчика насколько ему принципиальны те или иные требования, чтоб упростить разработку.
5. Я не против работы в команде. Но давайте отделять стадное чувство (т.е. учитывать мнение большинства), от настоящей команды! Работа в команде - это достижение максимально качественного результата благодаря вкладу каждого члена команды. А когда каждый член команды просто хочет чтоб его мнение учли, но не способен его аргументировать нормально и, главное, его мнение приводит к ухудшению качества... Это не работа в команде! Вот для этого и нужен архитектор, который сможет принять решение - что правильно, а что нет. Вот об этом моя статья.

И главное - ответственность на одном человеке! А не так, что над задачей работали 5 человек, накосячили все, задачу выполнили ужасно, а спросить не с кого! В моей модели люлей отхватит архитектор! И я всегда отхватываю столько..... А команде почти ничего не прилетает! Это ещё один плюс такого подхода.
AllexSoft; VVi3ard; +2 Ответить
71. VVi3ard 52 20.09.21 15:34 Сейчас в теме
(49)
1. Да лично я действительно не понимаю как не программирующий человек может проектировать архитектуру. Здесь могу десятками приводить примеры из моего опыта, где это потом становилось необновляемым.


Если у тебя есть хотя бы 3 разработчика в подчинении, на разработку просто нет времени. Если вы разработчик то понимаете что для того что бы плодотворно писать код нужно что бы тебя хотя бы 3 часа не отвлекали для простых задач. Но это практически не реально если ты архитектор среднего/крупного проекта постоянно есть вопросы, новые задачи, совещания с бизнесом и.т.п. Нужно ещё где то брать 8 часов что бы при этом оставалось время на разработку.

Что касается деградации проекта, это неизбежно, многие требования срочные для бизнеса и на архитектуру всем в общем то наплевать.
В любом случае, проще раз в 5-6 лет написать с 0. (как 1С и делает часто со своими типовыми).


(49)
2. Нет безаппеляционности. Есть стремление показать, что при грамотном архитекторе (как коллега назвал супер архитектор), которому подчиняется вся команда можно достичь наиболее высоких результатов.


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

В моем понимании архитектор это больше про контроль должность чем про разработку и проектирование. Да на разных этапах проекта задачи архитектора могут меняться. Но все равно 90% это контроль ("архитектурный надзор", участие в совещаниях что бы пресекать совсем уж бредовые идеи на уровне руководства или хотя бы предложить реальные варианты, и.т.п.).
72. biimmap 1917 20.09.21 15:38 Сейчас в теме
(71) Вот тут Ваше понимание прям очень далеко от моего и думаю от правильного тоже! Да всё зависит от размеров проекта... Но учитывая то, что сами написали, что большинство людей не очень грамотное... Это правда! Поэтому многое и приходится делать в одно лицо. Да я работаю очень много. Совещания стараюсь игнорить если оно не про архитектуру а про сроки и прочую ерунду.
50. papami 55 03.07.20 19:58 Сейчас в теме
Подача спорная. Буду ждать другие 7 статей. Может сложится пазл)
52. ovasiliev 6 04.07.20 09:15 Сейчас в теме
Всех этих архитекторов и аналитиков придумали ушлые программисты для сверхобогащения, потому что они считают себя слишком умными.
А самый умный, на самом деле, это я - я выслушаю клиента с умным видом, что-то с его слов запишу, заявлю клиенту миллион, а потом найду программиста, который всё сделает за 20 тыщ.

P.S. Мысль не моя, я просто разместил ремарку.
Maxisussr; Ta_Da; +2 Ответить
53. Maxisussr 08.07.20 08:53 Сейчас в теме
Часто вижу, что ряд разработчиков 1С стараются "абстрагироваться" от предметной области, и начать "жесткое" разделение "разработчик / технический архитектор" - "аналитик - методолог"..

1. Безусловно , в больших проектах это разделение есть. Но при этом разработчик должен знать на хорошем уровне (3 из 5) предметные области (и не одну), с которыми работает. На 5 из 5 их знает аналитик. Иначе проект просто выйдет намного дороже для заказчика, т.к. ему придется заплатить за "трансляцию" множества базовых знаний по предметной области от аналитика к разработчику.

2.Если смотреть с позиции разработчика/архитектора: так уж сложилось, что работая в сфере 1С, часто нужно совмещать несколько ролей, как минимум - разработчик + аналитик. Но почему же не воспользоваться этим и не стать "супер-специалистом", с которого как раз "сдувают пылинки", который разбирается на уровне эксперта в разработке на 1С (а это не Java, не C++ и т.п., где технических сложностей ИМХО поболее - для нас многое автоматизировано в платформе, если вести речь именно о задачах учета), плюс хорошо знать 1-2 предметные область и поверхностно - еще несколько ?
Такие люди есть, при этом на проектах работают также и методологи, консультанты (ввиду размера проекта) они в целом взаимозаменяемы. Но при этом "передаточные" звенья в виде "аналитик послушал заказчика, потом пошел к не знающим предм. область разработчикам и обратно" отсутствуют, что идет на пользу проекту..
Да, нужно учиться постоянно, актуализировать информацию в голове. Но это везде так. Зачем заведомо ставить низкую планку себе , ограничивая роль "только разработка" или "только аналитик" ?
54. blindcat2006 91 12.07.20 16:52 Сейчас в теме
Там много слов.... (в коментах) , так мало ... общего, в понятиях. Может стоит посмотреть что такое архитектор вообще и в частности:
Архите́ктор (от др.-греч. αρχι- — главный, старший и др.-греч. τέκτων — плотник, строитель[1]) — квалифицированный специалист, который на профессиональной основе осуществляет архитектурное проектирование (организацию архитектурной среды), включая проектирование зданий, в том числе разработку объёмно-планировочных и интерьерных решений.

Просьба обратить внимание - он таки и Старший плотник (в наших терминах - Ведущий программист).
И проектировщик здания (Системный архитектор).
И дизайнер интерьеров - да-да, тот самый, который обсуждает какого оттенка должна быть большая красная кнопка, чтобы понравится бухгалтеру Бабе Маше...
И если кто сталкивался со строителями и строительством - авторский надзор за строительством ведет все таки Архитектор, а не прораб стройучастка.

И тогда я плюсую топикстартера - он ближе к истине Википедии, чем уважаемый мной for_sale
55. biimmap 1917 12.07.20 17:05 Сейчас в теме
(54)
Может стоит посмотреть что такое архитектор вообще и в частности:
Архите́ктор (от др.-греч. αρχι- — главный, старший и др.-греч. τέκτων — плотник, строитель[1]) — квалифицированный специалист, который на профессиональной основе осуществляет архитектурное проектирование (организацию архитектурной среды), включая проектирование зданий, в том числе разработку объёмно-планировочных и интерьерных решений.

Именно об этом и писал статью! Что архитектор - ГЛАВНЫЙ. Но меня тут чуть не порвали на тряпочки... Вам спасибо!
60. XAKEP 31.07.21 18:16 Сейчас в теме
а вот как считает работодатель :


Вступление:

Компания «IT-swarm» – команда опытных специалистов, которая предоставляет ИТ- услуги для бизнеса.

Продукты и услуги, над которыми мы работаем позволяют нашим заказчикам быть эффективнее и существенно экономить с помощью комплексных ИТ-решений.


Обязанности
Обеспечивать бесперебойное функционирование систем 1С;
Контролировать работу серверов 1С;
Решать проблемы производительности 1С;
Анализировать предлагаемые разработчиками решения;
Развивать систему тестирования и анализа качества кода;
Сопровождать системы автоматического контроля;
Выполнять поиск и устранять узкие места в работе систем;
Поддерживать высокий уровень сервиса, ориентированного на клиента.

Требования
Знать возможности пакета 1С:КИП;
Применять методики проектирования и разработки больших информационных систем;
Уметь отлаживать и оптимизировать код;
Автоматизировать рутинные задачи;
Системно подходить к решению проблем;
Иметь высокий уровень ответственности, самоорганизованности и быть стрессоустойчивым.

Условия

Работу в команде профессионалов;
Оформление по ТК РФ, полностью «белую» заработную плату;
Обучение за счет компании;
Если вы из другого города – всегда удаленка;
Если вы из Перми - работа в офисе на ул. Луначарского,85, также имеется возможность выбрать удаленный или гибридный формат работы;
Чай, кофе, фрукты, печененки в офисе.


всего лишь за 200 000
ноль не пропустил, иначе бы эта вакансия была бы занята давно :)
61. biimmap 1917 31.07.21 18:23 Сейчас в теме
(60) Эта вакансия называется Эксперт по технологическим вопросам. Это не есть архитектор) Админ-Оптимизатор по-русски)
AllexSoft; VVi3ard; +2 Ответить
62. XAKEP 31.07.21 18:26 Сейчас в теме
(61)
а как вам это :
https://infostart.ru/job/vacancy/1481990/

даже не думал, сколько смежных специальностей хотят иметь в этой вакансии за такую оплату :)
63. biimmap 1917 31.07.21 18:55 Сейчас в теме
(62) для Перми 200 это как в Мск 350. За такие бабки почему бы и нет?! только таких уникумов наверное не существует... А так пусть ищут. У кого то будет уникальный опыт)
73. VVi3ard 52 20.09.21 15:48 Сейчас в теме
От архитектора тут:
(60)

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


Остальное действительно к "Эксперт по технологическим вопросам" ну и немного DevOps
64. pro-rok 296 17.08.21 17:21 Сейчас в теме
РП - обычно человек с чек-листом
Ну Вы прям совсем РП опустили. Можно добавлю своего виденья, а меня прокомментируют.
РП - самый главный администратор, он отвечает за проект, за реализацию в срок, в должном качестве и в заявленный бюджет. Тут боюсь чек листом не отделаться.
Аналитик - собирает бизнес и функциональные требования с клиента, на уровне бизнес процесса предлагает более оптимальные решения если речь идет о модернизации БП. Так же укладывает требования в штатный функционал.
Архитектор - придумывает как реализовать не штатный функционал исходя из требований аналитика, возможно совместно с аналитиком.
Что мы имеем в мире 1С. Крупный проект Отдельно РП, Архитектор и Аналитик. Средний проект РП отдельно, а Аналитик и Архитектор один человек. Мелкий проект - Может быть все в одном лице в т.ч. и программист.
65. biimmap 1917 17.08.21 17:24 Сейчас в теме
(64) Да статья жестковата... Планирую с этим докладом на Infostart Event в Мск. Уже выступал с модифицированной версией доклада... Там все углы сглажены и информация лучше разложена по полкам. Завтра начинается голосование - поддержите, появится возможность рассказать новую версию доклада. Редактировать статью нет времени к сожалению.
66. titanium2008 43 20.08.21 18:35 Сейчас в теме
Хорошая статья-все верно написал. Проголосовал. Был на проектах и в роли технического и в роли функционального архитектора.
Как правило в 1С это одна роль. При внедрении западной системы (OEBS) , выступал в роли функционального архитектора, т.к. как правило используют почти типовой функционал системы.
76. murzilka88 81 26.09.21 07:47 Сейчас в теме
Я считаю, что архитектор - это в первую очередь тимлид.

- Функциональный (бизнес) архитектор курирует работу команды аналитиков.
Выполняет работу аналитика, а также вычитывает документацию аналитиков, чтобы был единый подход к системе.

- Технический (системный) архитектор курирует команду разработчиков.
Согласует технические задания, проводит код-ревью по задачам на разработку.
AllexSoft; +1 Ответить
77. biimmap 1917 26.09.21 09:56 Сейчас в теме
(76) Вот к сожалению, многие как и Вы заблуждаются на эту тему! Тимлид - это тимлид, т.е. ОТДЕЛЬНОЕ ЛИЦО.

Со второй частью комментария почти согласен... в такой схеме плохо, что 2 "ответственных".
Если аналитики написали чушь и функциональный архитектор эту чушь принял... Как не крути надо вмешиваться в работу аналитиков и делать всё правильно.
78. murzilka88 81 26.09.21 11:09 Сейчас в теме
(77)
Если аналитики написали чушь и функциональный архитектор эту чушь принял... Как не крути надо вмешиваться в работу аналитиков и делать всё правильно.

У нас аналитики готовят 2 документа:
1. функциональный дизайн (результат моделирования) - описание используемого типового функционала, с указанием функциональных разрывов.
2. техническое задание - где по функциональным разрывам идут постановки задач для программистов.

1 документ вычитывает функциональный архитектор - чтобы проверить, действительно ли эти разрывы нельзя реализовать в типовом функционале, правильно ли отражены требования клиентов.
2 документ вычитывают оба архитектора, функциональный - с точки зрения общей логики, технический - с точки зрения корректности постановки задачи, все ли требования для программистов указаны (например, не забыли ли описать роли для новых объектов).
79. biimmap 1917 26.09.21 13:42 Сейчас в теме
Молодцы. В целом моя статья никак не противоречит описанному подходу.
Единственное я редко смотрю на то можно ли сделать в типовой... Мне всегда важно, чтоб было быстро и качественно... А типовая конфигурация на это не заточена! Если надо много данных вводить, то часто требуется автоматизация ввода данных, несмотря на то, что это не является функциональным разрывом.
80. vow 08.11.21 14:16 Сейчас в теме
Очень грамотно все расписано, опыт чувствуется огромный, и прям каждый пункт того, что НЕ должен делать архитектор всплывает в памяти яркими фантомными болями))

С какими-то вещами полностью согласен, с какими-то можно спорить и обсуждать, но один тезис вызывает прям полное отторжение!
Планирование сроков разработки... Да архитектор определяет что, как и в какой последовательности делать, но пока не описана архитектура и не определены сценарии угадать срок разработки невозможно. В целом планирование – это задача РП. Архитектор здесь выступает только как эксперт, но не как составитель план-графика! О сроках подробнее ниже…
Нельзя награждать задачей планирования срока проекта одного РП. Архитектор угадать не может, а у РП появился хрустальный шар? Что ж вы так своего РП-шника то подставляете)) Из этого не выйдет ничего хорошего, если только целью реализации проекта со стороны архитектора не является заработать деньги и уйти на новый проект. Я, как РП, не скажу ни слова про срок реализации Заказчику, пока архитектор кровью не распишется и не защитит каждую неделю разработки (иного этапа). Иначе, погнали в пацанский эджайл.
GorkyGorod; user1145418; anastasija182; biimmap; +4 Ответить
81. biimmap 1917 08.11.21 20:21 Сейчас в теме
(80) Предлагаю Вам поработать в Роснефти, Росгосцирке и т.д. И в целом самое главное - займитесь ЗУПом! Вот сейчас делаю задачу (ноябрь 21) со следующей постановкой: Нужно переделать обработку загрузки табелей из УТ (да, да это управление торговлей, непонятно правда как там появились табеля!) в ЗУП 3.1. Как работала обработка раньше, НИКТО НЕ ЗНАЕТ! Все люди сменились, как со стороны заказчика, так и в ИТ отделе! Нарыл таких интересных сценариев, что волосы дыбом, так даже НИКТО НЕ ЗНАЕТ КАК НАДО! Вот какой прикол. Ну и как тут планировать? Давай выкладывай супер способ. А у меня весь опыт в 18 лет состоит из решения вот таких задач!

На добром слове по статье спасибо!
82. KargaсoK 14.11.21 12:46 Сейчас в теме
что-есть, то есть...
И как пример: Парниша главный по разработкам 1С БИТ
Прикрепленные файлы:
83. biimmap 1917 14.11.21 14:22 Сейчас в теме
(82) В БИТе главное всё таки прибыль. Если качество можно достичь быстро это хорошо, а также хорошо когда клиент готов платить за достижение качества. Но сейчас это редкость, сейчас везде идут батлы между менеджерами за бабки. Нет батлов между спецами за качество.
86. пользователь 30.03.22 09:03
Сообщение было скрыто модератором.
...
88. AllexSoft 22.02.23 16:32 Сейчас в теме
Статья супер! Раздел что НЕ должен делать архитектор это прям в точку.. это вот в каждой вакансии на архитектора есть что то из этого раздела ) Прям боль.
Наполнение системы новыми сценариями. Обычно сценарии тестирования появляются после завершения разработки. Автором сценариев обычно выступает консультант. Это ужасная ошибка!!! Т.к. разработка должна вестись по конкретным сценариям! Необходимо на начальном этапе учесть все сценарии и продумать целостность решения.

эх и жили бы все счастливо... только ни разу я не видел таких проектов в 1С, хотя они может и есть конечно, но скорее это исключение.
89. biimmap 1917 22.02.23 16:40 Сейчас в теме
(88)
только ни разу я не видел таких проектов в 1С


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

Ну и статья должна мотивировать) Если на Вашем проекте не так - дайте почитать статью руководителю.
90. biimmap 1917 22.02.23 16:43 Сейчас в теме
(88)
в каждой вакансии на архитектора есть что то


Сейчас пишу в серии статей по названием "Я-ЗУПер" часть 2 и 3. И вот в третьей части будут разобраны реальные вакансии на предмет лишних требований. Планирую публиковать в апреле-мае. Вот ссылка на первую часть https://infostart.ru/1c/articles/1716474/
91. DDA4746 31.05.23 16:51 Сейчас в теме
Если грамотно разделить зоны ответственности между функциональным и техническим (системным) архитектором - не будет ни конфликта мнений, ни работы в пол силы.

Функциональный как правило является выходцем из консультантов/бизнеса, и умеет в бизнес-процессы и хорошо знает предметную область (не только решения типовой системы, но и методологию работы). По сути - тимлид у консультантов. Его задача - управление структурой процессов проекта, их увязкой между собой, т.е. функциональное проектирование.
Технический/системный - это квалифицированный разработчик, разбирающийся в технической части, способный выбрать и проконтролировать правильность разработки.

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

Проще разделить функции на двоих (и масштабировать их по подсистемам, если проект очень большой), им между собой будет проще договориться, не заходя на полянку соседа.
Я, как функциональный, могу предложить техническое решение задачи (структуру нового регистра, например) при обсуждении, но финальное слово - за техническим. В то же время он может предложить изменение порядка работы пользователей и структуру АРМов, но здесь за мной финальное решение и его согласование с заказчиком.
92. biimmap 1917 31.05.23 18:05 Сейчас в теме
(91) Отлично если можно разделить грамотно) Мой опыт здесь печален
93. DDA4746 07.06.23 14:30 Сейчас в теме
(92)
Тыжпрограммист, спаситель планеты,
Чинит все: от холодильников до лыж (с)
:)
94. Torin57 7 18.07.23 13:06 Сейчас в теме
В статье написано что в компетенцию системного архитектора входит:
Знания о серверной архитектуре (опционально).
Знания о настройке SQL, администрировании баз (опционально).

Насколько это распространено?

Например, мы ищем 1С архитектора. Он пришел к нам на работу. И тут я его озадачиваю: Помоги нам настроить отказоустойчивый кластер из 4 серверов. Он меня пошлет?