Кто такой архитектор? Системный или функциональный? Статья 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 4682 02.07.20 00:05 Сейчас в теме
Мне понравилась данная статья, т.к. в моей жизни реально происходит то, о чём пишет автор. Приходится общие концепции в разработке контролировать у групп программистов. Обидно только, что оплату и полномочия архитектора не каждый РП выделяет на своём проекте (т.к. придётся премией делиться к архитектором) и часто время за концепт и целостность продукта оплачивается по той же ставке, что и разработка отчета или документа. Короче фигня такая *)
gmw; newtraveller; Senator_I; user1525327; blindcat2006; Ta_Da; +6 Ответить
80. vow 08.11.21 14:16 Сейчас в теме
Очень грамотно все расписано, опыт чувствуется огромный, и прям каждый пункт того, что НЕ должен делать архитектор всплывает в памяти яркими фантомными болями))

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

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


Интересно!
А где про этот метод можно почитать подробнее?
9. shmalevoz 250 30.06.20 12:21 Сейчас в теме
(8) Как раз на главной странице странице ссылка на книгу
Не спеша эффективно и правильно
там есть про это в Базовые методы проектирования, в частности про Черный ящик и особенно Первородство спецификации
а аннотации начинают писаться если обязать всех использовать шаблоны, в которых есть заготовки комментариев. ну и просто не пропускать методы без описания. через пару месяцев приходит привыкание =)
10. barelpro 1230 30.06.20 12:24 Сейчас в теме
(9) а, ок, спасибо! Как раз эту статью отложил для чтения на выходные )))
3. awk 733 30.06.20 08:55 Сейчас в теме
Статья - отличная. Читается легко, почти нет воды. Одна из немногих, которую читал не по диагонали.

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

Как

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

а) и б) - плюсую ++ (2"+")
в) - люто минусую. Ибо дело на в личностях и строчках приказа о приеме на работе. ВЛИЯЕТ. И сильно. только архитектор не обязательно отдельно сидящая на троне личность с нимбом в виде непомерной ЗП (как тут некоторые писали).
Им может быть и программист въедливый и не ленивый (да таких сейчас редко делают).
И консультант дотошный (и как раз ленивый) которому надоедает тысячный раз дописки делать и начинает он системно к вопросам подходить.
Потому извините - оставлю Вас пока без оценок ))
Артано; +1 Ответить
57. Yashazz 4110 12.07.20 20:50 Сейчас в теме
(56) Видите ли, может оказаться замечательный программист, отличный методист, и выйдет прекрасный продукт. Может оказаться криворукий кодер и ленивый пофигист-методист. Но и в том, и в ином случае собственно внедрение и работа системы будут зависеть совершенно от другого - от настырности руководства автоматизаторв и РП, от упёртости руководства автоматизируемых, от политических подковёрных игр, дележа власти и денег, заказов, траншей, контрактов и прочая. В результате у замечательной разработки и у адской стрёмной поделки почти равные шансы (поделка даже лучше, она такая примитивная и понятная, что интуитивно кажется доступной и потому "нормуль" с точки зрения командующих дилетантов). И-таки мыши будут колоться, да жрать кактус. Независимо от вклада тех, кто оный кактус растил и поливал... Вот я о чём.
58. biimmap 316 12.07.20 22:13 Сейчас в теме
(57) В какой-то степени Вы правы. Но на своих проектах я всегда стаскиваю руководство с небес на землю и тыкаю в правду. Т.к. я не занимаюсь политическими играми (я не РП. а технарь), то руководству приходится смотреть в правду и проект идёт как надо!
На моих проектах именно мой опыт позволяет избегать политики.
59. Артано 718 06.01.21 11:32 Сейчас в теме
(56) Истина & Ложь = Ложь. Лепи минус смело за претенциозные обобщения (за что, в том числе, Яша и обвинял автора).
44. sapervodichka 4682 02.07.20 00:05 Сейчас в теме
Мне понравилась данная статья, т.к. в моей жизни реально происходит то, о чём пишет автор. Приходится общие концепции в разработке контролировать у групп программистов. Обидно только, что оплату и полномочия архитектора не каждый РП выделяет на своём проекте (т.к. придётся премией делиться к архитектором) и часто время за концепт и целостность продукта оплачивается по той же ставке, что и разработка отчета или документа. Короче фигня такая *)
gmw; newtraveller; Senator_I; user1525327; blindcat2006; Ta_Da; +6 Ответить
45. biimmap 316 02.07.20 00:45 Сейчас в теме
(44) Спасибо тебе добрый человек за твой комментарий)))
47. vaskomain 03.07.20 08:05 Сейчас в теме
Автор, начну с того, что очень детально и качественно разложил свой личный опыт организации работ, очень структурного. Честь и хвала. Далее пойдут замечания, которые направлены не для того чтобы критиковать, а чтобы улучшить качество работы.
1. Это все-таки личный опыт, поэтому очень напрягает безапелляционный стиль повествования - вот так должно быть и все! Возможно это следствие способа организации работ в команде - см. далее
2. Путаница между функциональным и системным архитектором не прояснилось даже после статьи. Если сделать вывод по формулировка, то функциональный архитектор у вас в принципе не нужен, так как ему делегируется часть работы системного, по вашему описанию - это сотрудник в команде системного администратора
3. Исходя из этого системный архитектор на себя натягал столько практик, что у него в голове может (и всегда так бывает) возникнуть ошибка заинтересованности. Дело в том что между функциональными требованиями (требованиями заказчика) и требованиями архитектуры (как уже все встроено в системе) всегда есть конфликт. И основная задача процесса проектирования системы - решить этот конфликт. Увы если этот конфликт будет в голове архитектора, то чаще программные практики возьмут вверх над требованиями заказчика (производство над продажами)
4. Поэтому лучшие практики выделяют роль руководителя продукта, который отвечает за удовлетворение требований заказчика. И в этом случае искусство и задачи архитектора системы заключаются в том, чтобы с проектировать максимально эффективную систему, для удовлетворения требований заказчика. И здесь не речь о том кто кому подчинении - руководитель продукта или системный архитектор - не надо их подчинять. Здесь речь о том, что требования к архитектуре системы подчинены требованиям заказчика. Требования, а не люди
5. Ну и работа в команде (насчёт безапелляционности). Мой личный опыт 20-летнего управления разработкой подтверждает мировой опыт - командная работа эффективнее иерархической по всем параметрам - скорость, качество, адекватность требованиям. Поэтому меня напрягают такие пассажи, как Архитектор никому ничего не должен доказывать - это и снижение качества отношений в команде, и отсутствие возможности обучения для команды, отсутствие тройной валидациии прочие факторы снижающие эффективность.
6. Немного о тройной валидациии - разработал требование, проверил сам - первая, рассказал команде - получил обратную связь, вторая, команда несогласилась, подробно изложил, почему так решил - третья
7. Ну и для тех кто дочитал - прочтите курс Левенчука Системное мышление - есть В свободном доступе, очень помогает все по полочкам разложить относительно всех терминов со словом системное
Артано; biimmap; +2 Ответить
48. vaskomain 03.07.20 08:05 Сейчас в теме
(47) прошу прощения за опечатки, писал в телефоне, пока ехал на работу
49. biimmap 316 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 316 20.09.21 15:38 Сейчас в теме
(71) Вот тут Ваше понимание прям очень далеко от моего и думаю от правильного тоже! Да всё зависит от размеров проекта... Но учитывая то, что сами написали, что большинство людей не очень грамотное... Это правда! Поэтому многое и приходится делать в одно лицо. Да я работаю очень много. Совещания стараюсь игнорить если оно не про архитектуру а про сроки и прочую ерунду.
50. papami 44 03.07.20 19:58 Сейчас в теме
Подача спорная. Буду ждать другие 7 статей. Может сложится пазл)
52. ovasiliev 20 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 74 12.07.20 16:52 Сейчас в теме
Там много слов.... (в коментах) , так мало ... общего, в понятиях. Может стоит посмотреть что такое архитектор вообще и в частности:
Архите́ктор (от др.-греч. αρχι- — главный, старший и др.-греч. τέκτων — плотник, строитель[1]) — квалифицированный специалист, который на профессиональной основе осуществляет архитектурное проектирование (организацию архитектурной среды), включая проектирование зданий, в том числе разработку объёмно-планировочных и интерьерных решений.

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

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

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

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


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

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

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

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

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

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

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

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

См. также

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

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

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

28.06.2017    44987    raiml    37    

Несколько простых приемов для удобной работы в конфигураторе

Конфигурирование 1С v8 Бесплатно (free)

Простая и удобная среда разработки 1С:Предприятия позволяет практически любому человеку начать работать под капотом 1С - в конфигураторе. Время идет, новички становятся программистами, специалистами, а об удобных приемах работы узнают годами, по ходу своего карьерного пути. А здорово было бы, если бы все знали удобные приемы в начале своего пути? Эти несколько приемов будут полезны новичкам, так как они затрагивают ту область работы, с которой приходится сталкиваться в начале карьеры.

12.11.2021    5039    acces969    82    

Кейсы решения задач на СКД

Конфигурирование 1С v8 v8::СКД Бесплатно (free)

Разработчик 1С в компании Neti Александр Крынецкий выступил на Infostart Meetup, посвященном практике работы с СКД. Александр поделился с коллегами кейсами по решению сложных задач при работе с СКД.

08.11.2021    2746    echo77    7    

Как спроектировать структуру регистра сведений

Конфигурирование 1С v8 v8::Запросы Бесплатно (free)

«Что может быть проще?» — это первое, что приходит в голову. Но что, если это не так? В этой статье мы попробуем затронуть некоторые вопросы, которые могут возникнуть при проектировании больших регистров.

08.11.2021    4196    Neti    60    

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

Техническое задание Управление бизнес-процессами (BPM) Методология Бесплатно (free)

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

23.02.2017    28674    Gavrik    11    

Готовые механизмы 1С: ЗУП, представления

Зарплата Расчетные механизмы v8 v8::СПР ЗУП3.x БУ Бесплатно (free)

Здесь будет храниться архив запросов, которые могут помочь разработчику правильно строить отчеты и получать данные в 1С: ЗУП. Статью буду периодически дополнять.

03.11.2021    1662    Margo462    17    

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

Анализ учета Механизмы оперативного учета v8 ERP2 Россия УУ Бесплатно (free)

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

01.11.2021    1006    pma_2015    9    

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

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

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

26.10.2021    557    malikov_pro    9    

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

Техническое задание Россия Бесплатно (free)

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

11.08.2016    36804    SamBadi    55    

Типовые операции в 1С: БГУ 2. Часть 4. Заключение

Механизмы бухгалтерского учета v8 v8::БУ 1cv8.cf БУ Бесплатно (free)

В данной статье автор расскажет, что такое типовые операции в конфигурации бухгалтерии для госсектора, установит стандарты качества написания типовых операций. Часть 4 "Заключение". Завершаем типовую операцию из ТЗ, изучаем простые условия, немного касаемся сложных условий, прикасаемся к булевой алгебре, изучаем функцию ЗНАЧЕНИЕ() и прочие прикладные функции как примеры, задаем стандарты типовой операции.

14.09.2021    483    ldmonster    8    

Типовые операции в 1С: БГУ 2. Часть 3

Механизмы бухгалтерского учета v8 v8::БУ БГУ БУ Госбюджет Бесплатно (free)

В данной статье автор расскажет, что такое типовые операции в конфигурации бухгалтерии для госсектора, установит стандарты качества написания типовых операций. Часть 3. Разбор четвертой страницы формы типовой операции "Проводки", знакомство с источниками данных, формирующих проводку, первое знакомство с языком СКД.

10.09.2021    529    ldmonster    0    

Типовые операции в 1С: БГУ 2. Часть 2

Механизмы бухгалтерского учета v8 v8::БУ БГУ Госбюджет Бесплатно (free)

В данной статье автор расскажет, что такое типовые операции в конфигурации бухгалтерии для госсектора, установит стандарты качества написания типовых операций. Часть 2. Разбор второй страницы формы типовой операции "Реквизиты", функциональное назначение кнопок, создание реквизитов и групп, базовые знания о форматировании.

09.09.2021    756    ldmonster    0    

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

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

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

29.06.2005    37398    support    11    

Типовые операции в 1С: БГУ 2. Часть 1

Механизмы бухгалтерского учета v8 v8::БУ БГУ БУ Госбюджет Бесплатно (free)

В данной статье автор расскажет, что такое типовые операции в конфигурации бухгалтерии для госсектора, установит стандарты качества написания типовых операций Часть 1. Знакомство с типовыми операциями. Разбор первой страницы формы типовой операции, корректное создание (копирование), создание правильного и удобного наименования, написание комментария.

07.09.2021    792    ldmonster    2    

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 4

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

Сколько бизнес-аналитиков – столько и мнений: какая нотация лучше и какую следует использовать при моделировании бизнес-процессов. Рассмотрим следующую группу нотаций…

01.06.2021    2884    ashtey    1    

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 3

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

Итак, сейчас рассмотрим уже самые разнообразные графические нотации и начнем с очень неожиданной – ДРАКОНа.

03.05.2021    2915    ashtey    13    

Направления работы программиста 1С Промо

Техническое задание Бесплатно (free)

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

08.11.2012    44770    adhocprog    63    

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 2

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

Самая суть – графическая нотация моделирования бизнес-процессов. Какие бывают и когда их использовать… Начнем с семейства нотаций IDEF.

22.04.2021    6059    ashtey    1    

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 1

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

Их действительно много – разных нотаций и методологий моделирования бизнес-процессов. Как понять, какую выбрать?

19.04.2021    14126    ashtey    6    

Новая упрощенная процедура перерасчета записей регистров расчета (пример)

Расчетные механизмы v8 1cv8.cf Россия Бесплатно (free)

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

24.03.2021    642    galexmvs    5    

Есть 2 подхода к внедрению информационных систем. На примере 1С УПП 8 Промо

Методология Техническое задание v8 УПП1 Россия Бесплатно (free)

С детальным ТЗ? Или без серьезного ТЗ? Какой лучше? И где успех более вероятен?

26.01.2012    102188        54    

Динамический список и поиск... неприятностей

Работа с интерфейсом Конфигурирование 1С v8 Бесплатно (free)

Страх и ненависть в поиске по динамическому списку, или "Кое-что о неоптимальном отборе".

17.03.2021    4631    Yashazz    37    

Пишем ТЗ через сценарии

Техническое задание Бесплатно (free)

От того, насколько одинаково понимают ТЗ заказчик и исполнитель, зависит успех проекта. Включение моделей на UML и BPMN в состав ТЗ помогает упростить взаимопонимание с заказчиком и обеспечить минимум доработок за счет полного покрытия всех процессов функциональностью системы. О том, как грамотно составить ТЗ и увязать требования заказчика с детализированными моделями, на митапе Saint Petersburg.Online рассказал Сергей Наумов.

05.03.2021    4482    SergeyN    6    

Практика применения DevOps. Тестирование

DevOps Сценарное тестирование BDD/TDD-тестирование, Vanessa СППР v8 1cv8.cf Бесплатно (free)

В третьей части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступила Светлана Попова. Она рассмотрела возможности использования двух инструментов тестирования от фирмы «1С» – «Сценарного тестирования» и связки СППР и Vanessa Automation, и рассказала про плюсы и минусы каждого из этих вариантов.

11.12.2020    5559    SvVik    0    

Централизованное управление НСИ при внутрикорпоративном внедрении Фреш

Обмен данными и распределенная БД Облачные сервисы, хостинг Конфигурирование 1С v8 ЗКГУ3.0 Государственные, бюджетные структуры Россия Бесплатно (free)

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

19.11.2020    1675    zivan38    0    

Хранилище версий объектов в условиях массовых изменений

Чистка данных Конфигурирование 1С v8 1cv8.cf Бесплатно (free)

Проблема хранения версий объектов при огромном количестве изменений.

08.11.2020    1334    Punisher_1C    4    

Альтернативный способ записи в регистры

Конфигурирование 1С v8 Бесплатно (free)

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

20.10.2020    2871    DarkAn    30    

Чего хочет разработчик от ТЗ? Примеры из практики

Техническое задание Бесплатно (free)

Модная нынче тема - составление ТЗ и формирование технических требований. Внесу свою маленькую лепту в виде примеров из личной практики и того, каким я вижу идеальное описание задачи. Задачи, которую можно просто взять и сделать! Без лишних вопросов.

16.10.2020    7603    stas_ganiev    36    

Учимся создавать http сервис (часть четвертая). Изучение метода POST http запроса (передача текстовых данных)

Конфигурирование 1С v8 Бесплатно (free)

Пошаговое руководство по созданию http сервисов (часть четвертая). Изучение метода POST http запроса.

11.10.2020    14608    hpi    25    

Несколько групп для одной номенклатуры в УТ 11

Механизмы оперативного учета Учет ТМЦ v8 v8::ОУ УТ11 Россия УУ Бесплатно (free)

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

23.09.2020    1851    malikov_pro    14    

Учимся создавать http-сервисы (часть первая)

Конфигурирование 1С v8 1cv8.cf Бесплатно (free)

Пошаговое руководство по созданию http-сервиса.

16.09.2020    15657    hpi    37    

Регистры бухгалтерии. Виртуальная таблица остатков

Механизмы бухгалтерского учета v8::БУ 1cv8.cf БУ Бесплатно (free)

Принцип работы виртуальной таблицы остатков. А также некоторые особенности.

24.08.2020    11934    YPermitin    1    

Регистры бухгалтерии. Еще одна таблица оборотов ДТ / КТ

Механизмы бухгалтерского учета v8::БУ 1cv8.cf Бесплатно (free)

Виртуальная таблица оборотов ДТ / КТ регистра бухгалтерии. Особенности и применение.

12.08.2020    6740    YPermitin    1    

Динамический список, ключи записей. Нюансы

Инструментарий разработчика Конфигурирование 1С Практика программирования v8 Бесплатно (free)

Заметки об особенностях динамических списков с произвольным запросом и видом ключа, отличным от "Авто"

07.08.2020    5422    Yashazz    6    

Субсчета в 1С

Бухгалтерский учет Механизмы бухгалтерского учета 1cv8.cf Бесплатно (free)

Краткое содержание: в данной статье мы рассмотрим принципы организации иерархии планов счетов в программах 1С Предприятие 8. Как известно, в программах 1С Предприятие 8, использующихся для ведения бухгалтерского учета, есть такой объект – План счетов в 1С. Он необходим для организации бухгалтерского учета в системе по принципам двойной записи, а также для реализации в этом учете различных разрезов учета – например, чтобы отделять товары от основных средств, денежные средства от задолженности покупателей и т.д.

07.08.2020    978    Koder_Line    1    

Регистры бухгалтерии. Виртуальная таблица оборотов

Механизмы бухгалтерского учета v8::БУ 1cv8.cf БУ Бесплатно (free)

Виртуальная таблица оборотов регистра бухгалтерии. Принцип работы, особенности и кое-что еще.

28.07.2020    9619    YPermitin    10    

Установка расширений в 1С 8.3

Конфигурирование 1С v8 1cv8.cf Россия Бесплатно (free)

Краткая инструкция, как подключить расширение конфигурации в 1С.

27.07.2020    20006    Mouros    11    

Что такое качество разработки и качество поддержки? Статья 2

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

Это вторая из 8 статей про разработку в сфере 1С. В данной статье будут раскрыты следующие вопросы: 1. Ошибки в решениях в пользовательском режиме и их причины. 2. Технические ошибки при разработке решений в 1С. 3. Мы закрыли 100 заявок за 1 день. Есть ли польза от такой поддержки? Польза или вред от SLA.

30.06.2020    2313    biimmap    5    

Находим взаимопонимание с заказчиками с применением Enterprise Architect

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

Enterprise Architect – мощное средство моделирования бизнес-процессов и информационных систем. Сергей Наумов на мастер-классе конференции Infostart Event 2019 Inception показал, как моделировать бизнес-процессы и составлять понятные заказчику документы при внедрении 1С-систем с помощью Enterprise Architect. Материалы мастер-класса будут полезны как разработчикам на платформе 1С, так и аналитикам, участвующим во внедрении.

19.06.2020    6797    SergeyN    0    

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

Техническое задание Бесплатно (free)

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

28.05.2020    10978    sapervodichka    75    

Как обойти глюк механизма расширений. Пошаговая инструкция в картинках

Конфигурирование 1С v8 БП3.0 Бесплатно (free)

После очередного обновления Бухгалтерии 3.0 в одной очень известной фирме мне звонит наш программист 1С, который ведет эту фирму, со словами - Шеф. Все пропало. Нам конец. Наше расширение грохнулось.

26.04.2020    12262    alfanika    21    

Настройка через конфигуратор. При открытии карточки номенклатуры открывается вкладка с развернутыми реквизитами

Конфигурирование 1С v8 Бесплатно (free)

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

03.04.2020    1911    gtrr34    1    

Вложенные СКД

Конфигурирование 1С Практика программирования v8 v8::СКД Бесплатно (free)

Возможности, нюансы, заметки.

26.03.2020    9736    Yashazz    19    

Конвертация расширения cfe в конфигурацию сf руками

Конфигурирование 1С v8 1cv8.cf Бесплатно (free)

Как быстро преобразовать расширение в конфигурацию (для дальнейшего переноса в основную конфигурацию, например).

18.03.2020    10974    wtlz    35    

Интеграция "Библиотеки интеграции МДЛП 1.1.2.7" с типовой конфигурацией

Интеграция с сервисами Конфигурирование 1С v8 Здравоохранение, медицина, стоматология Россия Бесплатно (free)

Инструкция для интеграции “Библиотеки интеграции МДЛП 1.1.2.7” в типовые конфигурации, на примере конфигурации “Управление нашей фирмой, редакция 1.6 (1.6.18.168)”.

02.03.2020    9330    RPGrigorev    3    

Регистры бухгалтерии. Настройки, субконто и движения с субконто

Бухгалтерский учет Механизмы бухгалтерского учета v8::БУ Бесплатно (free)

Описание основных настроек регистров бухгалтерии, работы виртуальных таблиц "Субконто" и "Движения с субконто" и кое-что еще.

10.02.2020    24723    YPermitin    13