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

Публикация № 1257685 30.06.20

Управление - Анализ и проектирование ИТ-систем

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

Часто сталкиваюсь с непониманием того, кто такой архитектор. Во многих командах эту компетенцию не используют, либо используют неверно. В связи с непониманием того, как устроен процесс разработки в сфере 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. Качеством работы кто-то должен заниматься. Само собой оно не появляется!

 

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

Специальные предложения

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

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

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


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

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

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

Как

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


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

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

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


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

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

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

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

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

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

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

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

Здесь от меня нет перехода на личности. А от Вас есть оскорбления и эмоции.
marinakomarova89; AlbinaAAA; vaskomain; +3 3 Ответить
33. пользователь 01.07.20 14:50
Сообщение было скрыто модератором.
...
34. biimmap 732 01.07.20 14:52 Сейчас в теме
(33) Коллега, в моё посте нет эмоций. Ваш наполнен ими и оскорблениями. Спасибо за "участие".
marinakomarova89; AlbinaAAA; +2 2 Ответить
46. da.buraev 02.07.20 02:18 Сейчас в теме
18. пользователь 01.07.20 08:34
Сообщение было скрыто модератором.
...
32. biimmap 732 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 732 01.07.20 10:10 Сейчас в теме
(19)
чушь??? Вы название хотя бы прочитайте!
"Аналитик"! Чем должен

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

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

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

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

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

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

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

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

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

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

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

Почему написал об этом, потому что видел, как аналитик пишет разработчику задачу: Создать документ... Создать отчет, данные взять из документа. Про регистр ни слова. Вот в таких ситуациях на отчетах нужен архитектор.
74. VVi3ard 50 20.09.21 15:50 Сейчас в теме
(69) Аналитик разработчику писать не должен, он может писать это проектировщику/постановщику задач а дальше уже как проектировщик решит, и если архитектор согласует.
75. biimmap 732 20.09.21 15:53 Сейчас в теме
(74) Тут наверно речь про мегапроекты... Мой профиль ЗУП, тут проекты поменьше... И главное знаешь что в статье? не то, что исполнитель даже... Главное качество выполнения и главное, что все этапы жизненного цикла задач выполнялись. Потому как многие этапы не выполняются или делаются с ужасным качеством. Поэтому главное качество, а как предложенную мною модель использовать и двигать туда сюда, решат руководители соответствующих проектов.
24. a.abelentsev 125 01.07.20 11:42 Сейчас в теме
28. biimmap 732 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 1266 01.07.20 16:04 Сейчас в теме
(19)

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


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

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

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

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


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

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


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


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

В моем понимании архитектор это больше про контроль должность чем про разработку и проектирование. Да на разных этапах проекта задачи архитектора могут меняться. Но все равно 90% это контроль ("архитектурный надзор", участие в совещаниях что бы пресекать совсем уж бредовые идеи на уровне руководства или хотя бы предложить реальные варианты, и.т.п.).
72. biimmap 732 20.09.21 15:38 Сейчас в теме
(71) Вот тут Ваше понимание прям очень далеко от моего и думаю от правильного тоже! Да всё зависит от размеров проекта... Но учитывая то, что сами написали, что большинство людей не очень грамотное... Это правда! Поэтому многое и приходится делать в одно лицо. Да я работаю очень много. Совещания стараюсь игнорить если оно не про архитектуру а про сроки и прочую ерунду.
50. papami 53 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 75 12.07.20 16:52 Сейчас в теме
Там много слов.... (в коментах) , так мало ... общего, в понятиях. Может стоит посмотреть что такое архитектор вообще и в частности:
Архите́ктор (от др.-греч. αρχι- — главный, старший и др.-греч. τέκτων — плотник, строитель[1]) — квалифицированный специалист, который на профессиональной основе осуществляет архитектурное проектирование (организацию архитектурной среды), включая проектирование зданий, в том числе разработку объёмно-планировочных и интерьерных решений.

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

И тогда я плюсую топикстартера - он ближе к истине Википедии, чем уважаемый мной for_sale
55. biimmap 732 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 732 31.07.21 18:23 Сейчас в теме
(60) Эта вакансия называется Эксперт по технологическим вопросам. Это не есть архитектор) Админ-Оптимизатор по-русски)
62. XAKEP 31.07.21 18:26 Сейчас в теме
(61)
а как вам это :
https://infostart.ru/job/vacancy/1481990/

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

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


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

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

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

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

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

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

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

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

См. также

Путь покупателя интернет-магазина (Customer Journey) с использованием УФМТП Промо

Анализ и проектирование ИТ-систем Управленческий учет Бесплатно (free)

Недавно у меня вышла статья под названием «Универсальная функциональная модель торгового предприятия (УФМТП) в нотации IDEF0». И одно из пожеланий читателей было пояснить подробнее, как я лично пользуюсь этой моделью и как вообще ее можно применять на практике. В этой статье я выполню просьбу читателей. И на примере взаимодействия покупателей с интернет-магазином продемонстрирую практическое применение этой модели.

12.05.2022    1002    raiml    2    

Пример автоматизированного управления публикацией списка баз

Анализ и проектирование ИТ-систем Администрирование СУБД Бесплатно (free)

Данная публикация в художественном стиле описывает путь нашей команды по решению задачи автоматизации публикаций списка 1С-систем.

29.11.2022    414    Elaks    2    

Мобильные приложения 1С: зачем они бизнесу? Обзор + 7 идей применения

Мобильная разработка Анализ и проектирование ИТ-систем Бесплатно (free)

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

31.10.2022    769    ystetsenko    0    

Простой пример частного технического задания (ЧТЗ) для 1С-ника

Анализ и проектирование ИТ-систем Бесплатно (free)

В статье расскажем о том, как происходит разработка структуры технического задания. Покажем пример технического задания в 1С.

27.10.2022    1567    Koder_Line    2    

Универсальная функциональная модель торгового предприятия в нотации IDEF0 Промо

Анализ и проектирование ИТ-систем Управленческий учет Бесплатно (free)

Из чего состоит предприятие? Какие функции основные, а какие нет? В данной статье вы найдете ответ на этот и другие вопросы. Модель, построенная на основе опыта бизнес-консультанта с использованием нотации IDEF0.

12.05.2022    1870    raiml    4    

Аналитик 1С: так ли он нужен?

Анализ и проектирование ИТ-систем Управление командой Внедрение ИТ-системы Россия Бесплатно (free)

Не все клиенты понимают, зачем на проекте внедрения или сопровождения 1С аналитики. Разве с поставленными задачами не справится хороший программист? Давайте разбираться вместе с экспертами компании «Внедренцы и Программисты».

13.10.2022    1167    ystetsenko    14    

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    7647    Evil Beaver    14    

Дизайн-мышление в заказной разработке

Анализ и проектирование ИТ-систем Бесплатно (free)

Метод дизайн-мышления смещает приоритеты разработки на потребности пользователя. Но как понять, что пользователь хочет и учесть его подразумеваемые требования? О том, как с помощью эмпатии к пользователю и визуализации идей сделать удобный для заказчика продукт, в докладе на Infostart Event 2021 Moscow Premiere рассказала Мария Серёгина.

30.06.2022    2044    SerjoginaMaria    15    

Ошибка №1 внедрения "Бюджетирования" в 1С:ERP2 и 1С:КА2: настройка статей бюджетов и статей ДДС 1-в-1 Промо

Бюджетирование и планирование Внедрение ИТ-системы Анализ и проектирование ИТ-систем Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Управленческий учет Бесплатно (free)

В цикле статей я хочу поделиться ошибками во внедрении подсистемы «Бюджетирование», которые мне приходится исправлять после коллег на реальных проектах, и лучшими приемами по автоматизации бюджетирования на 1С:ERP 2 и 1C:КА 2. Сегодня поговорим и о самой распространенной ошибке – настройке статей бюджетов 1-в-1 к справочнику «Статьи ДДС».

13.06.2018    40998    SergeyN    97    

Автоматизация vs оптимизация

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Бесплатно (free)

Анализ и оптимизация бизнес-процессов становятся все более востребованными в проектах автоматизации, а с массовым переходом с 1С: УПП на 1С:ERP эта задача станет еще более актуальной. О том, как собрать полную картину реальных потребностей вашего заказчика, исходя из логики его бизнес-процессов, на конференции Infostart Event 2021 Moscow Premiere рассказала Елена Иванова.

27.06.2022    1937    e_ivanova    0    

Скальпель, зажим, … пластырь, валерьянка. Мы закончили..: инструменты работы бизнес-аналитика

Анализ и проектирование ИТ-систем Бесплатно (free)

Считается, что аналитику для работы на проекте достаточно уметь строить бизнес-процессы в одной-двух популярных нотациях. Но это не так, потому что работа аналитика гораздо разнообразнее и не ограничивается рисованием схем. О том, какие инструменты пригодятся аналитику и помогут ему сделать свою работу комфортной и удобной, на конференции Infostart Event 2021 Moscow Premiere рассказала руководитель отдела сопровождения финансового учета компании «Самокат» Анастасия Штей.

23.06.2022    3893    ashtey    0    

Эмпатия и системный подход в сборе требований и составлении ТЗ

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Бесплатно (free)

Начальник отдела внедрения и сопровождения информационных систем в торговой сети «Командор» Елена Качаева выступила на митапе «Сбор требований и составление ТЗ». Елена рассказала, как разобраться в особенностях клиента, как найти с заказчиком общий язык и составить корректное ТЗ, которое в дальнейшем будет легко реализовать и сдать.

10.06.2022    1852    kacelena    2    

IDEF0. Знакомство с нотацией и пример использования Промо

Анализ и проектирование ИТ-систем Обучение, бизнес-тренинг, курсы 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

28.06.2017    54389    raiml    37    

Аналитика и BI. Белые пятна рынка и тренды, которые нельзя игнорировать

Анализ и проектирование ИТ-систем Консолидация данных Бесплатно (free)

Мир вычислений бурно развивается, и потребность анализировать «большие данные» уже плотно вошла в жизнь любой, даже маленькой компании. О том, какие исторические предпосылки привели к текущей ситуации на рынке BI-систем, и какие перспективы у этого развития, на митапе «Бизнес-анализ по данным базы 1С» рассказали представители компании «Консон» Евгений Скребанов и Иван Мищенко.

08.06.2022    1530    imischenko    0    

SAFe Epic (Эпик)

Анализ и проектирование ИТ-систем Бесплатно (free)

Перевод https://www.scaledagileframework.com/epic/, с переводом сопутствующих терминов, для понимания основного термина и варианта его использования.

06.06.2022    1027    malikov_pro    0    

ТЗ как обязательный атрибут в автоматизации. Реальные кейсы из 16-ти летнего опыта

Анализ и проектирование ИТ-систем Бесплатно (free)

Техническое задание – документ, который многим кажется слишком дорогим удовольствием. Руководитель консалтингового направления ГК СофтБаланс Клавдия Макарова объяснила, почему нельзя на него смотреть только с этой точки зрения, и какую пользу он приносит команде и заказчику.

01.06.2022    1872    user1551153    0    

Краткое описание BPMN с примером Промо

Анализ и проектирование ИТ-систем Бесплатно (free)

О том, что такое BPMN, написано очень много. Но проблема в том, что почти вся информация, которую можно найти в Интернет, ориентирована на людей, которые уже ранее сталкивались с BPMN или с другим стандартом моделирования бизнес-процессов. Я же предлагаю разобраться «с нуля» — что такое BPMN? В чем особенности и преимущества этой технологии и почему она появилась и оказалась столь востребованной, по крайней мере, за рубежом. Да и у нас в стране ей все больше и больше интересуются.

28.06.2017    43970    raiml    10    

Современные СЭД: курс на упрощенчество и подмена понятий

Документооборот и делопроизводство Анализ и проектирование ИТ-систем Внедрение ИТ-системы Управленческий учет Бесплатно (free)

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

12.05.2022    612    user1214797    5    

Business Objective Model или Модель бизнес-целей - где, зачем и как применять?

Анализ и проектирование ИТ-систем Бесплатно (free)

Модель бизнес-целей или Business Objective Model (далее BOM) - техника, которая захватила моё сердце и разум с первого взгляда. Простая и наглядная, она помогает избежать того, от чего так часто возникает недопонимание между бизнесом и теми, кто его автоматизирует.

23.03.2022    1998    SerjoginaMaria    18    

Power BI дешево или очень дорого?

Консолидация данных Анализ и проектирование ИТ-систем Бесплатно (free)

На онлайн митапе «Бизнес-анализ по данным базы 1С. Интеграция c платформами BI» выступил Петр Базелюк, CTO компании Digital Business. Петр рассказал, как запустить систему аналитики для полноценной цифровизации всего бизнеса, сравнил возможности подписок Free, Pro и Premium и подсказал возможные пути минимизации затрат.

18.02.2022    2981    pbazeliuk    2    

Про спагетти, или как исследовать бизнес-процессы организации Промо

Анализ и проектирование ИТ-систем Бесплатно (free)

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

23.02.2017    29231    Gavrik    11    

Какие риски и ответственность берет на себя бизнес-аналитик

Анализ и проектирование ИТ-систем Бесплатно (free)

Профессия бизнес-аналитика хотя и интересная, но полна неопределенности. Чем должен заниматься этот специалист, какими навыками обладать, за что отвечать? На эти вопросы попытался ответить исполнительный директор Инфостарта Александр Чавалах.

16.02.2022    3524    chavalah    8    

Как из 1С отдать миллионы строк в BI и успеть это сделать быстро

Консолидация данных Анализ и проектирование ИТ-систем WEB-интеграция Платформа 1С v8.3 Бесплатно (free)

На онлайн-митапе «Бизнес-анализ по данным базы 1С. Интеграция c платформами BI» выступил ведущий разработчик WiseAdvice.tech Дмитрий Фурцев. Дмитрий рассказал о том, как отдать миллионы строк из 1С в платформу бизнес-аналитики и не потратить на это сутки.

14.02.2022    4409    Fudj1k    11    

Как мы подружили "1С:Аналитику" и "Финансист". Практический опыт

Консолидация данных Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

«1С:Аналитика» – достаточно молодой инструмент от фирмы «1С». О том, как его настроить и запустить для отображения консолидированных данных из различных баз, на митапе «Бизнес-анализ по данным базы 1С. Интеграция с платформами BI» рассказала Ирина Богданова – ведущий разработчик тиражного решения «Финансист» в компании WiseAdvice.

11.02.2022    2937    bogira    2    

Как оценивать задачи программисту 1С Промо

Анализ и проектирование ИТ-систем Россия Бесплатно (free)

Оценивать задачу всегда сложно. У меня не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, субъективным опытом в этом вопросе. Речь пойдет только о технической оценке.

11.08.2016    39154    SamBadi    55    

Не надо делать мне как лучше, оставьте мне как хорошо

Анализ и проектирование ИТ-систем 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Даже самое продуманное решение может потерпеть фиаско при внедрении, если пользователи не увидят в нем пользу.

08.02.2022    3303    SerjoginaMaria    37    

42 или главный вопрос по бизнес-процессам

Анализ и проектирование ИТ-систем Бесплатно (free)

Приветствую вас, уважаемые коллеги! Меня зовут Анастасия Штей, я – бизнес-аналитик 1С. Именно так я начинала свои доклады на INFOSTART EVENT 2021 Post-Apocalypse и INFOSTART EVENT 2021 Moscow Premiere. Мне очень близка тема бизнес-анализа, изучения подходов и практик моделирования бизнес-процессов и компетенции бизнес-аналитика. И сейчас я запускаю на Инфостарт серию статей, а уже скоро и курс, посвященный основам моделирования и анализа бизнес-процессов.

07.02.2022    6013    ashtey    20    

Документальное оформление бизнес-процессов в проектах по автоматизации

Анализ и проектирование ИТ-систем Управление проектом Внедрение ИТ-системы Бесплатно (free)

При формировании проектной документации под конкретного заказчика важно использовать в качестве основного источника информации автоматизируемые бизнес-процессы. О том, как такой подход позволяет соблюсти правило полноты и непротиворечивости информации на митапе «Бизнес-аналитик. Роль в команде, компетенции, инструментарий» рассказал руководитель отдела экспертизы компании «Первый БИТ» Денис Галимов.

02.02.2022    5472    denisgalimoff    3    

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

Анализ и проектирование ИТ-систем Бесплатно (free)

Поговорить о том, какие причины способствуют гибели существующего и часто даже успешного на определенном этапе бизнеса, я планировал давно, но все не доходили руки. Но недавно я услышал о банкротстве моего, теперь уже, клиента. Именно этот факт стал для меня неким толчком. Я осознал, что именно сейчас, в условиях кризиса очень важно понимать, почему бизнес может окончиться крахом и учиться избегать подобных ситуаций. Как известно, когда в экономике кризис, любой бизнес ослаблен. Если сравнивать с человеческим организмом, то кризис для экономики – как ослабление иммунитета. Когда человек здоров, то мелкие болезни проходят незамеченными. Организм сам справляется с проблемами, а в случае ослабления иммунитета, любая инфекция может привести к серьезным заболеваниям или даже стать фатальной. Так происходит и в бизнесе. Если в период подъема экономики какие-то недостатки конкретного бизнеса сглаживаются, остаются незамеченными и даже не слишком мешают работать, то в периоды экономического спада они становятся теми самыми «тонкими местами», которые приводят к снижению прибыли, к определенным проблемам, а иногда даже к полному краху всего бизнеса.

06.04.2015    39072    raiml    14    

Как бизнес-аналитик может повысить эффективность и прибыльность разработчиков

Управление ИТ-подразделением Анализ и проектирование ИТ-систем Бесплатно (free)

Эксперты не устают спорить, насколько важны аналитики, какие функции они должны выполнять, как взаимодействовать с другими ролями в проекте. О том, как привлечение бизнес-аналитиков помогло увеличить эффективность разработчиков, рассказал директор и ведущий разработчик украинской компании «Арт Порт» Максим Артёменко.

31.01.2022    1739    drmaxart    2    

Матрица компетенций аналитика 1С

Мотивация, лидерство и личная эффективность Анализ и проектирование ИТ-систем Бесплатно (free)

Тема мотивации сотрудников – одна из центральных в любой организации. Но, как и за что премировать работников, определиться сложно. В компании ФТО решили, что нужно сформировать матрицу компетенций, присвоить каждой определенное количество баллов, и уже на основании такой независимой оценки распределять премиальные. Подробнее о системе рассказала руководитель аналитиков 1С проектного отдела компании ФТО Анна Бирюкова.

28.01.2022    3599    abir    20    

Экспресс-обследование и реинжиниринг бизнес-процессов

Внедрение ИТ-системы Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Проведение обследования – это первый этап работы на проекте. От того, как этот этап пройдет, и какие результаты будут получены, будет зависеть дальнейший исход вообще всего проекта. О проведении обследования предприятия для целей управленческого учета на основе МСФО рассказал Генеральный директор ООО «Рэй Консалтинг» Николай Шилкин.

26.01.2022    2494    RayCon    0    

Бизнес-аналитики 1С: спрос есть, но кто они?

Управление ИТ-подразделением Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

Каждый понимает по-своему, кто такой бизнес-аналитик и чем он занимается. Руководитель компании CORS Consulting Илья Отькало постарался ответить на вопросы, что должен знать такой специалист, какие знания и навыки ему пригодятся в работе.

24.01.2022    6283    otkalo    0    

Роль и задачи аналитика в проектной команде при внедрении 1С

Управление командой Внедрение ИТ-системы Анализ и проектирование ИТ-систем Бесплатно (free)

Типовые продукты фирмы «1С» становятся все более гибкими, и функция разработки или изменения для них очень часто вообще не требуется или требуется точечно, поэтому для подобных проектов появился отдельный специалист – аналитик 1С. Какие у него задачи, и чем он отличается от системного аналитика и бизнес-аналитика, рассказал руководитель отдела экспертизы компании «Первый БИТ» Денис Галимов.

19.01.2022    7978    denisgalimoff    8    

Склад Готовой Продукции – отказать, прямое распределение. Промо

Анализ и проектирование ИТ-систем Оптовая торговля, дистрибуция, логистика Управленческий учет Бесплатно (free)

Данная статья описывает методику складского учета без использования склада готовой (СГП) продукции или центрального склада. Сразу скажу – это я немного лукавлю, но так или иначе факт – в 3 крупных компаниях, где применили эту методику – СГП больше нет. Цель данной статьи – познакомить читателя с методикой, применимой как в производстве, так и в оптовой торговле.

27.02.2015    28610    izidavld    69    

Как быстро нарисовать блок-схему или изобразить бизнес-процесс

Анализ и проектирование ИТ-систем Россия Бесплатно (free)

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

25.11.2021    9438    VachKirp    10    

Моделирование в 1С:ERP - практика анализа движений документов

Анализ учета Анализ и проектирование ИТ-систем Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Управленческий учет Бесплатно (free)

Практика анализа движений документов при моделировании в 1С:ERP - анализ цепочки документов, функциональный анализ, сценарный и событийный.

01.11.2021    2255    pma_2015    9    

Реактивный интерфейс для 1С:Предприятия

Работа с интерфейсом Анализ и проектирование ИТ-систем Бесплатно (free)

Интеграция 1С:Предприятие с веб-приложениями требует нестандартных решений. О том, как построить веб-интерфейс для 1С на HTTP-сервисах, и какие технологии при этом можно использовать, на митапе «Интерфейс в 1С» рассказал автор профессиональных курсов по JavaScript в HTML Academy Игорь Антонов.

27.10.2021    5073    antonov_i    17    

"Бескомпьютерная" автоматизация Промо

Анализ и проектирование ИТ-систем Внедрение ИТ-системы Россия Бесплатно (free)

Новое, хорошо забытое старое. Недавно решали проблему в логистике, и я вспомнил статью про автоматизацию без компьютеров, основанную на системе "канбан". Канбан система - система эффективной синхронизации многоэтапного производства и материально-технического обеспечения, осуществляемая с помощью карточек производственного заказа и карточек отбора (карточек канбан). Канбаном часто называют всю систему организации производства Toyota Motor Company, считая его почти синонимом данной системы. Это не совсем точно. Канбан - только один из элементов Toyota Production System (TPS). Канбан как инструмент предложил один из создателей TPS - Таичи Оно. Хотя он утверждает, что придумал его вместе с рабочими для упрощения управления на местах.

17.08.2007    32447    support    32    

Модель C4 (C4 model) для визуализации архитектуры программного обеспечения

Анализ и проектирование ИТ-систем Бесплатно (free)

Перевод главной страницы сайта https://c4model.com/, посвященной C4 model.

26.10.2021    8190    malikov_pro    10    

Использование PlantUML в Redmine

Анализ и проектирование ИТ-систем Бесплатно (free)

В статье опишу порядок настройки плагина PlantUML для Redmine 4.2

25.10.2021    978    malikov_pro    2    

Уникальный дизайн в 1С на примере разработки реального продукта

Работа с интерфейсом Анализ и проектирование ИТ-систем Бесплатно (free)

Изменить стандартный дизайн интерфейса в 1С можно не только с помощью классических веб-технологий. О том, как для этой цели использовать SVG-картинки, и какие особенности есть у такого подхода, рассказал разработчик 1С в компании «Ангелы ИТ» Сергей Харламов.

18.10.2021    12760    papa_harlo    38    

Автоматизация бизнес-процессов как способ выявления потерь производства Промо

Анализ и проектирование ИТ-систем Бесплатно (free)

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

09.12.2013    23252    pro-rok    15    

Когда интерфейсам 1С нужны веб-технологии

WEB-интеграция Работа с интерфейсом Анализ и проектирование ИТ-систем Бесплатно (free)

Есть несколько способов сделать интерфейс в 1С богаче и оптимальнее с помощью веб-технологий. О том, какие практические приемы помогут в этой задаче, на митапе «Интерфейс в 1С» рассказали руководители разработки в компании «Арбис» Матвей Серегин и Анна Гнатюк.

15.10.2021    4836    Akcium    11    

Из арт-директора веб-студии в команду разработки продукта на платформе 1С

Работа с интерфейсом Анализ и проектирование ИТ-систем Бесплатно (free)

В мире 1С по сравнению с веб-разработкой незаслуженно мало внимания уделяется поведению и внешнему виду интерфейсов. На митапе «Интерфейс в 1С» руководитель группы разработки компании АРБИС Анна Гнатюк рассказала, что она привнесла из большого мира дизайна в разработку на 1С.

13.10.2021    1547    gntk    2    

Детские механизмы для взрослых людей

Мотивация, лидерство и личная эффективность Анализ и проектирование ИТ-систем Бесплатно (free)

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

06.09.2021    2071    ashtey    6    

ГОСТ 34.602-89. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ Промо

Анализ и проектирование ИТ-систем Россия Бесплатно (free)

Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее - ТЗ на АС). Дата введения с 01.01.1990г

29.06.2005    38031    support    11    

Решение детективных задач

Анализ и проектирование ИТ-систем Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Пробуем систематизировать методы решения детективных задач

25.08.2021    4535    1c-intelligence    31    

Берримор, ты потерял рецепт овсянки? Не беда, нам поможет DFD!

Анализ и проектирование ИТ-систем Бесплатно (free)

Методология DFD наряду с нотациями IDEF0 и IDEF3 входит в тройку популярных методологий описания бизнес-процессов. Мы не говорим о современных нотациях eEPC или BPMN, мы говорим о классике.

16.08.2021    5768    ashtey    2