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

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

Методология - Проектирование

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

В связи с повальным непониманием того, как устроен процесс разработки в сфере 1С и кто за что отвечает, будут написаны 8 статей. Это первая статья. Она очень актуальна, т.к. многие проектные команды не имеют архитектора, либо используют его не по назначению. В этой статье раскрываю роль архитектора и его значимость. Основываюсь на своём опыте (более 10 лет), также изучал статьи на эту тему от коллег и консультировался с руководителями крупных команд. В данной статье будут раскрыты следующие вопросы: 1. Кто такой архитектор? 2. Какие задачи выполняет архитектор? 3. Можно ли без него обойтись? 4. Чем отличается системный архитектор от функционального архитектора? 5. Кто главный: РП или архитектор? Кому подчиняется проектная команда?
  1. Кто такой архитектор?

 

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

 

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

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

 

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

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

 

Как видно из определения и его перевода на язык 1С, архитектор – это ключевая фигура на проекте. Архитектор отвечает за всё. От него зависит:

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

 

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

 

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

  • Выяснение у заказчика требований к автоматизации бизнес-процессов (итерационная задача).
  • Определение структуры метаданных в целом и каждого объекта метаданных в частности.
  • Определение связей между объектами метаданных.
  • Наполнение системы новыми сценариями.

 

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

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

 

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

 

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

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

 

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

 

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

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

 

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

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

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

 

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

 

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

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

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

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

 

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

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

 

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

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

 

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

 

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

 

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

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

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

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

 

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

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

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

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

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

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

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

Лучшие комментарии
43. Yashazz 3253 01.07.20 20:04 Сейчас в теме
Трепология ни о чём. Пустое умствование. И знаете почему? Потому что а) использующие архитекторов имеют своё видение, оно у них как откровение свыше, альфа и омега, пуп их знания о проекте, и переубеждать бесполезно; б) не использующие архитекторов свято убеждены, что без них всегда жили и дальше прокатит; в) ничто не влияет на процесс внедрения и эксплуатации системы меньше, чем наличие/отсутствие и качество архитектора на проекте.
Ta_Da; akimych; vaskomain; Grania; biimmap; +5 1 Ответить
44. sapervodichka 3892 02.07.20 00:05 Сейчас в теме
Мне понравилась данная статья, т.к. в моей жизни реально происходит то, о чём пишет автор. Приходится общие концепции в разработке контролировать у групп программистов. Обидно только, что оплату и полномочия архитектора не каждый РП выделяет на своём проекте (т.к. придётся премией делиться к архитектором) и часто время за концепт и целостность продукта оплачивается по той же ставке, что и разработка отчета или документа. Короче фигня такая *)
Остальные комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. barelpro 1162 29.06.20 23:30 Сейчас в теме
Немного не понятно как быть на крупных проектах? В одно лицо уточнить задачи, придумать решение, поставить задачу, проверить реализацию, собрать релиз - бутылочное горлышко. Все в итоге будут работать в пол силы или имитировать бурную деятельность пока бедолага рвёт базис на британский флаг! Мой опыт подсказывает иерархию архитекторов по направлениям, с одним корневым. Под каждым архитектором три- пять разрабов.

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


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

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

Как

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


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

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

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


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

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

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

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

Калёным железом надо выжигать из архитектора, руководства и остальной команды эту уверенность. Всегда должно быть место аргументированной дискуссии. А то приходят на проект такие вот архитекторы, понасочиняют архитектур, а потом все попытки этого остолопа убедить в чём-то разбиваются о "я архитектор, я так вижу, я самый грамотный и опытный" вместо аргументированного обоснования, почему так лучше всего.
vaskomain; mikl79; da.buraev; Grania; a.abelentsev; +5 1 Ответить
31. biimmap 60 01.07.20 14:30 Сейчас в теме
(17) Что вижу в этом посте:
1. Вам не дают архитекторы принимать самостоятельные решения, а убедить их аргументами наверно не получается.
2. Аргументированная дискуссия лишь в том случае, если аргументы направлены на улучшение решения. Могу только предположить, что более опытный архитектор отклоняет аргументы, т.к. они направлены на упрощение разработки, а не на улучшение качества и целостности системы.
3. Вижу прямое оскорбление в адрес всех архитекторов. Автор комментария их считает остолопами.

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

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

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

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

Здесь от меня нет перехода на личности. А от Вас есть оскорбления и эмоции.
vaskomain; +1 2 Ответить
33. for_sale 854 01.07.20 14:50 Сейчас в теме
(31)
Мдаааа... всё ещё сложнее, чем я думал. То есть человек не в пылу задетых чувств переходит на личности - он даже в принципе не способен отличить переход на личности от аргументированной дискуссии. Спрятался за щитом "я архитектор, я самый грамотный и умный, не лезьте ко мне, любите меня таким, какой я есть". И потратил час времени на то, чтобы в очередной раз обсудить высказавшего, а не высказанное, причём, залив это личными эмоциями.

Я потому и писал комменты и влепил вашей поделке минус - именно, чтобы вот такие "архитекторы" не превратились в пандемию.
akimych; da.buraev; a.abelentsev; Grania; +4 Ответить
34. biimmap 60 01.07.20 14:52 Сейчас в теме
(33) Коллега, в моё посте нет эмоций. Ваш наполнен ими и оскорблениями. Спасибо за "участие".
46. da.buraev 02.07.20 02:18 Сейчас в теме
18. for_sale 854 01.07.20 08:34 Сейчас в теме
Выяснение требований. Часто эту задачу поручают аналитикам или консультантам.

И правильно делают. Архитектор - это технический специалист. Он может выяснять требования только если на той стороне сидит другой технический специалист (в идеале - тоже архитектор), и они могут говорить на одном языке. О чём может говорить архитектор с финансовым директором или с пенсионеркой-бухгалтером? Ну нам вот надо такую кнопку, чтобы нажать - и всё работало. Архитектор вообще может не знать (и не должен знать!) прикладную область, это атавизм сферы 1С, когда архитектор - это и программист, и бухгалтер, и кадровик, и финансист. В какой-нибудь джаве архитектор - это архитектор, он сегодня автоматизирует банк, завтра - космодром, послезавтра - интернет-казино, он не может и не обязан разбираться во всех этих сферах.

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

Простой пример. Если тёте-бухгалтеру нужна большая красная кнопка, чтобы всё делала для надзорных органов, то что не разбирающийся в прикладной области архитектор сможет ей напридумывать? А аналитик сможет расшифровать для архитектора, что кнопка должна считать себестоимость, фин.результат, закрывать месяц и т.д. и т.п.

Да, в сфере 1С архитектор может быть сразу и аналитиком. Но это, повторюсь, атавизм и нарушает принцип разделения труда. Такому специалисту всё сложнее будет поддерживать свои знания актуальными во всех сферах, стоить он будет непомерно дорого и т.п.
Grania; a.abelentsev; +2 1 Ответить
32. biimmap 60 01.07.20 14:46 Сейчас в теме
(18) Что в этом посте написано:
1. Архитектор может выяснить детали только у технического специалиста.
2. Архитектор не должен знать предметную область.
3. Аналитик может выяснить требования в общих чертах и передать архитектору.
4. Архитектору со знанием предметной области будет сложно поддерживать свои знания актуальными во всех сферах.

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

Здесь тоже не вижу аргументов по моей статье. Здесь описан Ваш опыт, и к сожалению - он неправильный! Так быть не должно! Именно для этого написана моя статья.
35. for_sale 854 01.07.20 15:48 Сейчас в теме
(32)
1. Здесь нет ни одного аргумента, почему вдруг архитектор не может выяснять потребности у заказчика?

Если бы вы читали полностью и уважали чужое мнение, а не эмоционировали на любое несогласие с вашим самолюбованием, вы бы увидели там целый абзац разъяснений, почему.


(32)
Мне крайне тяжело в среде 1С (а именно об этом моя статья) представить архитектора ЕРП, который не знает производство и ни разу не был в цеху.

То, что вам тяжело, совсем не значит, что вы совершенно правы. Именно об этом я и писал - что сфера 1С всё ещё полна вот такими атавизмами и такими "архитекторами" (обязательно в кавычках!), которые уверены, что только так правильно и что они - самые грамотные. Именно об этом я и писал, что у вас архитектор сросся с аналитиком и РПшником и даже не хочет задумываться о том. что может быть что-то делает неправильно. Даже не неправильно, до этого вообще далеко, но даже не хочет задумываться о том, чтобы вообще проанализировать происходящее, поискать какие-то альтернативы. Нет, такой "архитектор" - он самый умный и самый грамотный, наместник бога на земле, не спорьте с ним!

И из вот этого подхода, конечно же, неминуемо должно было явиться вот это:

(32)
Архитектор не может и не должен работать в разных областях. Я лично (тут на свою личность перейду) работаю в сфере зарплаты.


Теперь архитектор - он вообще уже не архитектор, оказывается, а скрещенный с кадровиком программист)) Типичная история в сфере 1С, это понятно. Но когда эта типичная история ещё и ходит по форумам и на полном серьёзе пишет статьи, где заявляет свои аксиомы, что так правильно и так и должно быть - это уже совсем странно.

И что мы имеем в результате? Архитектор - это (в вашем случае) кадровик-аналитик-программист, который способен (и должен!!!) уметь только придумывать регистры зарплатного учёта!

(32)
Когда аналитик дойдёт до архитектора, то получится испорченный телефон, который уже забыл половину разговора с заказчиком

Ну а за такие несуразицы я вашу статью чушью и назвал)) В какой-то момент вы просто срываетесь в какой-то горячечный бред. "Забыл половину разговора". И мы это обсуждаем всерьёз? Или вы за полным недостатком аргументов в этот детский сад скатились? Если, как говорилось в анекдоте, "он идиот и забывает, то пусть записывает, как это делаю я")) Жесть. Уровень аргументов просто зашкаливает за плинтус. "Господа, так как аналитики у нас с короткой памятью, то пусть пишут инструкции, а вместо них работают архитекторы!"))

Ладно, я уже понял, что, скорее всего, вы ничего не поняли и не поймёте, так бывает всегда, когда человек себя объявляет "самым грамотным и умным" и отказывается обучаться. Но оставлю здесь это для тех, кто, может, зачем-то и правда придёт в эту статью за осмыслением роли архитектора.

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

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

Суперархитектор в среде обитания
Начинаем проект. Ищем архитектора именно в этой области, потому что он жыш обязан знать прикладную область! Кое-как нашли (товар-то штучный и дорогой!), внесли его непомерную ЗП в себестоимость и цену. Этот полубог общается с заказчиком, со всеми заинтересованными ролями, впитывает в себя потребности бизнеса (а он все его стороны знает, не забываем!), затем придумывает тоннель, в конце которого эти потребности реализовываются, и разрабатывает архитектуру вплоть до последнего регистра (он же и в программировании умнее всех!). Через полгода или год проект начинает реализовываться. При этом к нему приставляют охрану из пяти телохранителей, оборачивают в три слоя поролона и хранят в закрытом бункере, потому что если с ним что-то случится или он уйдёт - проект умрёт.

Теперь попробуем альтернативный вариант, где каждый занимается своим делом

Аналитик: свойства
Знает только прикладную область и немного - язык технарей.
Стоит дорого, но дешевле суперархитектора раза в два-три.
Не обучается сутками, но всё равно поддерживает гораздо более узкую сферу знаний актуальной.

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

Проект
Начинаем проект. Ищем аналитика, который знает только прикладную область и умеет её доносить технарям. Он общается с заказчиком и, разговаривая на одном языке, понимает, что нужно бизнесу в конце тоннеля. Аналитик пишет функциональные требования о том, что нужно, чтобы получить результат, чего хочет заказчик. ФТ оперирует понятиями высокого уровня - "список сотрудников", "передаёт заказ в служу доставки", "руководитель формирует отчёт" и т.п. Первый этап завершён, на нём работал только РП и аналитик, не требовалось привлечения и простоя других кадров. На этом роль анатилика заканчивается, ресурс высвобождается, он может участвовать в других проектах. При этом, если аналитик выходит из проекта где-то до этой черты, то заменить нужно только аналитика и затраты только в работе аналитика.

РП оценивает проект, нужные ресурсы, нужное время. Теперь он ищет архитектора, который знает техническую часть. Это гораздо проще, чем найти суперархитектора. Архитектор в свою очередь на основании ФТ изобретает архитектуру решения и пишет ТЗ. ТЗ оперирует понятиями прикладного технического уровня - "регистр сведений Список сотрудников", "по нажатию на кнопку... запускает бизнес-процесс...", "команда в разделе... формирует отчёт..., видна пользователю с ролью...". Если он выходит из проекта где-то до этой черты, то заменить нужно только архитектора, работа аналитика уже выполнена, её не нужно переделывать, затраты - только в работе архитектора.

Выводы, какой подход лучше, даже не буду писать, пусть каждый сам сделает их для себя.
Casey1984; da.buraev; a.abelentsev; gavlexx; Grania; +5 Ответить
51. Casey1984 3 03.07.20 22:55 Сейчас в теме
(35) Поддерживаю полностью.
for_sale; +1 Ответить
19. for_sale 854 01.07.20 09:01 Сейчас в теме
Аналитик – составлением инструкций, сценариев, сдачей работ заказчику.

Что за чушь??? Вы название хотя бы прочитайте!
"Аналитик"! Чем должен заниматься "Аналитик"? Само название происходит от слова Анализ! Да, он может всем вышеописанным заниматься теоретически (и постоянно занимается практически), но просто потому, что в этой сфере всё ещё дикий запад и никто почему-то до сих пор не может натянуть правила разработки, которые десятилетиями используются в других сферах, на эту.

Аналитик должен прежде всего АНАЛИЗИРОВАТЬ. Это - первая линия обороны, которая и должна общаться с заказчиком (а не архитектор!), выяснять, что у них есть, что им нужно и АНАЛИЗИРОВАТЬ, как это все превратить в полезный конечный результат. И дальше уже результаты своего АНАЛИЗА предоставить архитектору для технической реализации. Это как раз и есть самый грамотный, который должен с языка заказчика на язык архитектора перевести. От него должна зависеть в целом судьба проекта. Если заказчик говорит при сдаче проекта - а мы не это хотели! - то это как раз вина аналитика.

И на этом (АНАЛИЗЕ) его роль завершается, дальше уже начинается королевская печать с орехами. Инструкции писать - чушь! Инструкции пусть пишет консультант (это по идее не такой продвинутый специалист, и менее дорогостоящий, к тому же более приближённый по знаниям к конечному пользователю - операторам, бухгалтерам и т.п.) Аналитик - это стратег, он НЕ должен тратить время на описание кнопочек.

А вы просто рассказали и "утвердили", как оно сейчас в сфере 1С есть. Где аналитики - это просто консультанты в профиль, которые за три копейки пишут инструкции пользователям и понятия не имеют, как из требований заказчика сделать конечный результат. Где "я проработал оператором 1С полгода, больше ничего не умею - пойду в аналитики!". Вы просто перепутали архитектора и аналитика, назначив архитектору бОльшую часть функций аналитика.

Аналитик - это стратегия и концепция проекта. Дальше уже по этой стратегии и концепции архитектор придумывает техническую сторону, а РП - прогнозирует стоимость и сроки. Когда в нашей многострадальной сфере это поймут, количество горделивых рассказов про "истории ещё одного провалившегося проекта" будет гораздо меньше.
Casey1984; sapervodichka; ivanov660; Grania; a.abelentsev; +5 1 Ответить
22. biimmap 60 01.07.20 10:10 Сейчас в теме
(19)
чушь??? Вы название хотя бы прочитайте!
"Аналитик"! Чем должен

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

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

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

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

Поэтому Ваше мнение проигнорирую. Аргументы у Вас слабые. Я основываюсь на своём опыте и на достижении результата, а не на названиях.
23. ivanov660 2137 01.07.20 11:02 Сейчас в теме
(22)Каждый должен заниматься своими обязанностями.
У вас идет перекос обязанностей в сторону архитектора. Как в поговорке - и жнец и на дуде игрец.
Архитектор должен держать в голове укрупненный каркас и должен контроллировать процесс сборки этой констркуции.
Далее в зависимости от процесса разработки существуют различные наборы команд, в которых различные роли и обязанности.
В итоге - у вас есть кейс, он рабочий в определенных условиях, но не единственный.
Casey1984; байт; sapervodichka; for_sale; +4 Ответить
26. biimmap 60 01.07.20 13:38 Сейчас в теме
(23)
Архитектор должен держать в голове укрупненный каркас и должен контроллировать процесс сборки этой констркуции.
Я согласен с Вашей формулировкой и не вижу отклонений в своём тексте. Архитектор должен участвовать во всех ключевых процессах и контролировать их. Последнее слово по техническим решениям за архитектором, а не за РП или аналитиком не дай бог. И главное чтоб он вообще был! Вот об этом статья!
24. a.abelentsev 119 01.07.20 11:42 Сейчас в теме
28. biimmap 60 01.07.20 13:43 Сейчас в теме
(24) приветствую. даже интересно что ты имел ввиду. Для публики: Артур был мои руководителем, когда я приехал в Москву. Работал я просто программистом по ТЗ от аналитика.
25. for_sale 854 01.07.20 11:50 Сейчас в теме
(22) Ваш комментарий многое объясняет в вашей статье. Сразу становится понятно, откуда эти тезисы "архитектор самый умный, никто с ним не должен спорить")) Переход на личности и обсуждение высказавшего, а не высказываемого, "я самый умный, не спорьте со мной" - вот такие у нас архитекторы.

Вопросов больше нет, статье - жирный минус. По таким материалам потом и получим новое поколение таких вот "архитекторов".
Ta_Da; sapervodichka; a.abelentsev; Grania; +4 1 Ответить
27. biimmap 60 01.07.20 13:41 Сейчас в теме
(25) не вижу в своем комментарии перехода на личности... Я знаю, что будут те кто не согласны со мной. И готов к этому. Но называть без аргументов (просто основываясь на своих привычках) статью чушью - мне кажется это неадекватным. Да и кто заставляет читать? можно пройти мимо...
29. for_sale 854 01.07.20 13:46 Сейчас в теме
(27) Я вам воз и тележку аргументов привёл. Но вы же решили просто "игнорировать мнения", отличные от вашего.
sapervodichka; +1 Ответить
30. biimmap 60 01.07.20 13:48 Сейчас в теме
(29) хорошо, я отвечу подробно с примерами на каждый ваш аргумент. полчаса времени требуется.
37. barelpro 1162 01.07.20 16:04 Сейчас в теме
(19)

Для начала надо уточнить, что в 1С-проектах используются системные аналитики. Бизнес аналитики как правило являются заказчиками для системных аналитиков. Системный аналитик - это файервол между бизнесом и командой разработчиков. Берёт на себя все первичные разговоры с бизнесом, проверяет адекватность и реалистичность, систематизирует, отсеивает шлак, и выдает команде в краткой содержательной форме основной смысл хотелок. Далее после того как РП проверил эти хотелки на входимость в рамки проекта, можно сделать второй подход к бизнесу с уточняющими вопросами. Вот тут уже могут быть варианты, кто пойдет - аналитик или архитектор. О правилах ролевой игры проектная команда договаривается внутри себя заранее. Тут главное слово скорее за РП.
Многое зависит от кадровой составляющей - если достался сильный аналитик и никакой архитектор (который максимум тянет на релиз менеджера) - это беда! Если наоборот - в принципе архитектор конечно вытянет две функции, но есть риск что поплывут либо сроки либо качество.
Это касается первой фазы проекта - постановка, проектирование, моделирование.
На второй фазе (разработка и внедрение), когда основные хотелки уже выявлены, аналитик нужен разве что для проверки уточненных требований на соответствие скопу проекта. Его функции плавно перетекают в то, о чем написано в статье. Либо аналитик вообще уходит.
38. gavlexx 37 01.07.20 17:22 Сейчас в теме
Архитектор должен выяснять у Заказчика требования? При разделении труда - точно нет. Только если он же - и выясняет, и строит архитектуру и программирует.
Но цикл статей же не о "на-все-руки-мастеров-1С", верно? :)
Casey1984; Grania; for_sale; +3 Ответить
39. biimmap 60 01.07.20 17:30 Сейчас в теме
(38) Вечер добрый. Почему люди размышляют ОДНОЙ ЕДИНСТВЕННОЙ ЗАДАЧЕЙ? Статья написана про проект в целом. Проект состоит из множества задач. И всё это множество между собой связано! И только в этом ракурсе необходимо воспринимать написанное! Я написал про КОНЦЕПЦИЮ, т.е. АРХИТЕКТУРУ.
Могу сотнями приводить примеры, где Аналитик, так восхваляемый некоторыми, приносил от Заказчика вообще не то. Просто не понял смысл задачи. В таких случаях возникает сомнение в правдивости принесенной информации. Выясняю сам - получаю совсем другие ответы.
43. Yashazz 3253 01.07.20 20:04 Сейчас в теме
Трепология ни о чём. Пустое умствование. И знаете почему? Потому что а) использующие архитекторов имеют своё видение, оно у них как откровение свыше, альфа и омега, пуп их знания о проекте, и переубеждать бесполезно; б) не использующие архитекторов свято убеждены, что без них всегда жили и дальше прокатит; в) ничто не влияет на процесс внедрения и эксплуатации системы меньше, чем наличие/отсутствие и качество архитектора на проекте.
Ta_Da; akimych; vaskomain; Grania; biimmap; +5 1 Ответить
44. sapervodichka 3892 02.07.20 00:05 Сейчас в теме
Мне понравилась данная статья, т.к. в моей жизни реально происходит то, о чём пишет автор. Приходится общие концепции в разработке контролировать у групп программистов. Обидно только, что оплату и полномочия архитектора не каждый РП выделяет на своём проекте (т.к. придётся премией делиться к архитектором) и часто время за концепт и целостность продукта оплачивается по той же ставке, что и разработка отчета или документа. Короче фигня такая *)
45. biimmap 60 02.07.20 00:45 Сейчас в теме
(44) Спасибо тебе добрый человек за твой комментарий)))
47. vaskomain 03.07.20 08:05 Сейчас в теме
Автор, начну с того, что очень детально и качественно разложил свой личный опыт организации работ, очень структурного. Честь и хвала. Далее пойдут замечания, которые направлены не для того чтобы критиковать, а чтобы улучшить качество работы.
1. Это все-таки личный опыт, поэтому очень напрягает безапелляционный стиль повествования - вот так должно быть и все! Возможно это следствие способа организации работ в команде - см. далее
2. Путаница между функциональным и системным архитектором не прояснилось даже после статьи. Если сделать вывод по формулировка, то функциональный архитектор у вас в принципе не нужен, так как ему делегируется часть работы системного, по вашему описанию - это сотрудник в команде системного администратора
3. Исходя из этого системный архитектор на себя натягал столько практик, что у него в голове может (и всегда так бывает) возникнуть ошибка заинтересованности. Дело в том что между функциональными требованиями (требованиями заказчика) и требованиями архитектуры (как уже все встроено в системе) всегда есть конфликт. И основная задача процесса проектирования системы - решить этот конфликт. Увы если этот конфликт будет в голове архитектора, то чаще программные практики возьмут вверх над требованиями заказчика (производство над продажами)
4. Поэтому лучшие практики выделяют роль руководителя продукта, который отвечает за удовлетворение требований заказчика. И в этом случае искусство и задачи архитектора системы заключаются в том, чтобы с проектировать максимально эффективную систему, для удовлетворения требований заказчика. И здесь не речь о том кто кому подчинении - руководитель продукта или системный архитектор - не надо их подчинять. Здесь речь о том, что требования к архитектуре системы подчинены требованиям заказчика. Требования, а не люди
5. Ну и работа в команде (насчёт безапелляционности). Мой личный опыт 20-летнего управления разработкой подтверждает мировой опыт - командная работа эффективнее иерархической по всем параметрам - скорость, качество, адекватность требованиям. Поэтому меня напрягают такие пассажи, как Архитектор никому ничего не должен доказывать - это и снижение качества отношений в команде, и отсутствие возможности обучения для команды, отсутствие тройной валидациии прочие факторы снижающие эффективность.
6. Немного о тройной валидациии - разработал требование, проверил сам - первая, рассказал команде - получил обратную связь, вторая, команда несогласилась, подробно изложил, почему так решил - третья
7. Ну и для тех кто дочитал - прочтите курс Левенчука Системное мышление - есть В свободном доступе, очень помогает все по полочкам разложить относительно всех терминов со словом системное
48. vaskomain 03.07.20 08:05 Сейчас в теме
(47) прошу прощения за опечатки, писал в телефоне, пока ехал на работу
49. biimmap 60 03.07.20 10:33 Сейчас в теме
(47) Спасибо за аргументированные адекватные комментарии. Немного отвечу на некоторые пункты:
1. Да лично я действительно не понимаю как не программирующий человек может проектировать архитектуру. Здесь могу десятками приводить примеры из моего опыта, где это потом становилось необновляемым.
2. Нет безаппеляционности. Есть стремление показать, что при грамотном архитекторе (как коллега назвал супер архитектор), которому подчиняется вся команда можно достичь наиболее высоких результатов.
3. Всегда поясняю свою точку зрения команде! Т.е. в моей статье не написано, что я не должен пояснять!!! Просто члены команды люди с разным опытом. И для того, чтоб понять какие-то мои решения нужно иметь мой опыт. В таких ситуациях люди говорят: я всё равно не согласен (или не согласна). И вот тут решения архитектора должно быть весомее просто несогласия. Причем многие реально даже не могут аргументировать своё несогласие. Часто просто хотят оставить своё решение и всё.
4. Дело в том, что у меня конфликта не возникает! Для меня бизнес-требования - это то, что обязательно нужно сделать. А вот как это сделать, чтоб не сломать систему - вот тут приходится хорошо подумать! Иногда действительно уточняю у заказчика насколько ему принципиальны те или иные требования, чтоб упростить разработку.
5. Я не против работы в команде. Но давайте отделять стадное чувство (т.е. учитывать мнение большинства), от настоящей команды! Работа в команде - это достижение максимально качественного результата благодаря вкладу каждого члена команды. А когда каждый член команды просто хочет чтоб его мнение учли, но не способен его аргументировать нормально и, главное, его мнение приводит к ухудшению качества... Это не работа в команде! Вот для этого и нужен архитектор, который сможет принять решение - что правильно, а что нет. Вот об этом моя статья.

И главное - ответственность на одном человеке! А не так, что над задачей работали 5 человек, накосячили все, задачу выполнили ужасно, а спросить не с кого! В моей модели люлей отхватит архитектор! И я всегда отхватываю столько..... А команде почти ничего не прилетает! Это ещё один плюс такого подхода.
50. papami 30 03.07.20 19:58 Сейчас в теме
Подача спорная. Буду ждать другие 7 статей. Может сложится пазл)
52. ovasiliev 04.07.20 09:15 Сейчас в теме
Всех этих архитекторов и аналитиков придумали ушлые программисты для сверхобогащения, потому что они считают себя слишком умными.
А самый умный, на самом деле, это я - я выслушаю клиента с умным видом, что-то с его слов запишу, заявлю клиенту миллион, а потом найду программиста, который всё сделает за 20 тыщ.

P.S. Мысль не моя, я просто разместил ремарку.
Оставьте свое сообщение

См. также

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

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

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

23.02.2017    27030    0    Gavrik    10    

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

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

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

30.06.2020    740    0    biimmap    5    

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

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

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

19.06.2020    1715    0    SergeyN    0    

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

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

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

28.05.2020    6761    0    sapervodichka    69    

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

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

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

11.08.2016    32959    0    SamBadi    52    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    5791    0    DataReducer    22    

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

Расширения v8 БП3.0 Бесплатно (free)

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

26.04.2020    5304    0    alfanika    19    

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

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

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

03.04.2020    1243    0    gtrr34    1    

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

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

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

29.06.2005    36363    0    support    11    

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

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

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

26.03.2020    4747    0    Yashazz    19    

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

Расширения v8 1cv8.cf Бесплатно (free)

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

18.03.2020    4825    0    wtlz    28    

RPA (роботизация) – "костыль" или автоматизация будущего? Идеи и практические примеры

Проектирование Бесплатно (free)

Автоматизация действий пользователя упрощает интеграцию с внешними системами, сокращает рутинную работу, делает бизнес-процесс более контролируемым. О подходе Robotic Process Automation (RPA), случаях, когда его можно использовать, существующем рынке RPA-систем, на конференции Infostart Event 2019 Inception рассказал CTO компании WiseAdvice Олег Филиппов.

10.03.2020    3936    0    comol    1    

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

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

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

08.11.2012    43244    0    adhocprog    58    

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

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

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

02.03.2020    4147    0    RPGrigorev    3    

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

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

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

10.02.2020    8436    0    YPermitin    6    

Эволюция расширения конфигурации

Расширения v8 1cv8.cf Бесплатно (free)

С каждым днем всё больше возможностей появляется в расширении конфигурации, но не все до сих пор работают даже на платформе 8.3.6! Давайте окунемся в историю появления и эволюции расширения конфигурации, чтобы знать и понимать, когда можно применить тот или иной функционал!

06.02.2020    8011    0    Xershi    33    

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

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

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

26.01.2012    55652    0        54    

Доработки объектов метаданных и форм (только кодом) с помощью расширений на примере типовых конфигураций: 1C:ERP Управление предприятием 2.4 и 1С:Альфа-Авто: Автосалон+Автосервис+Автозапчасти КОРП 6

Практика программирования Расширения v8 1cv8.cf Россия Бесплатно (free)

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

01.02.2020    1738    0    байт    7    

1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

СППР Управление проектом Бесплатно (free)

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

09.01.2020    5728    0    roman72    0    

1С: СППР и оценка сроков и стоимости проектов методом COCOMO II

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

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

06.01.2020    3364    0    roman72    9    

Обновление релиза измененной типовой конфигурации

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

Пригодится тем, кому еще не приходилось обновлять измененную типовую конфигурацию.

29.11.2019    10991    0    John_d    76    

Vanessa Automation + СППР

Vanessa Automation СППР v8 Бесплатно (free)

Vanessa Automation. Использование автоматизированного тестирования в СППР.

07.11.2019    10940    0    SvVik    14    

Обработка расширением на клиенте

Расширения Универсальные функции v8::УФ 1cv8.cf Бесплатно (free)

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

31.10.2019    6575    0    EvgenURNN    9    

Модернизация КА 2.4 под маркетинговую компанию. Часть 1

Управление взаимоотношениями с клиентами (СRM) Техническое задание v8 КА2 Россия УУ Бесплатно (free)

Выполнил для компании, которая занимается маркетингом и продвижением продуктов, проектирование и модификацию конфигурации КА 2.4 и справочника «Проекты». Теперь в конфигурации «Проекты» имеют особенную роль и на основании выполненной доработки руководство компании принимает решения по продолжению, закрытию или продвижению проекта/ов, поиск путей решения возникающих вопросов. При необходимости доработку можно реализовать под ERP конфигурацию. Архитектура решения выполнена «рядом» с основной конфигурацией. В настоящее время конфигурация поддерживается, модификация ведется в актуальной версии КА 2.4.10 на платформе 8.3.14.1630.

29.10.2019    5753    0    BraunAlex    1    

Об общих реквизитах

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

Общие реквизиты. Что за ними скрывается?

28.10.2019    12040    0    YPermitin    30    

Реализация продвинутой обработки запросов HTTP сервиса

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

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

05.10.2019    3057    0    malikov_pro    4    

От чего можно отказаться при разработке расширений 1С

Практика программирования БСП (Библиотека стандартных подсистем) Расширения v8 Бесплатно (free)

Разработка расширений 1С и оптимизация через механизм БСП: Дополнительные отчеты и обработки.

23.09.2019    9964    0    independ    24    

Мастер-класс СППР

Управление проектом СППР Бесплатно (free)

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    10578    0    SergeyN    6    

Impact mapping: чем он может быть вам полезен

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

Привет, коллеги! Сегодня хочу поговорить про один из инструментов Владельца продукта - Impact mapping (карта влияния). Чем он хорош и почему его стоит использовать.

26.07.2019    6166    0    slozhenikin_com    14    

Как проектировать отчетность

Техническое задание Управление проектом Управленческие v8 УУ Бесплатно (free)

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

16.10.2018    9124    0    weissfeuer    2    

Проектирование архитектуры и модификация программных продуктов как технология в сложных проектах системной интеграции и автоматизации на базе 1С: СППР

Управление проектом Интеграция СППР v8 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

03.10.2018    15820    0    roman72    19    

Управление отделом разработки с помощью "1С:СППР"

Управление проектом СППР v8 Бесплатно (free)

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

20.08.2018    15446    0    pau74    11    

На чьей стороне мячик? Алгоритм определения исполнителя задачи

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

Я считаю, что мало кому удалось избежать ситуации, когда его назначали исполнителем работы, мягко скажем, не его уровня. На мой взгляд, такое особенно часто встречается среди технических специалистов. Причем, в случае возражения, обычным аргументом противоположной стороны является: "Нам так раньше всегда делали!". Эта публикация является попыткой описать формализовано процесс определения исполнителя с точки зрения логики. Посвящается тем, кто, будучи невежественным в вопросе, смеет указывать, кому его решать. А также тем, кто это терпит.

14.08.2018    7247    0    itriot11    42    

Первый шаг к успешному проекту автоматизации

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

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

30.03.2018    10143    0    Aprsoft    1    

Должностная инструкция специалиста по 1С

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

Описание функциональных обязанностей для трёх категорий специалистов 1С: Администратор платформы, Программист, Администратор конфигурации (Методист).

14.12.2017    25292    0    Vikki-di    20    

Внедрение МСФО: план-график выполнения проекта по автоматизации МСФО

Техническое задание Управление проектом МСФО (GAAP) МСФО (GAAP) БУ Бесплатно (free)

В данной статье будут детально рассмотрены задачи, которые предстоит выполнить в процессе запуска проекта автоматизированной подготовки отчетности МСФО

23.10.2017    10039    0    user743750    0    

Систематизация опыта подготовки технического задания

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

Решил «закинуть» на портал свою статью пяти-шестилетней давности. Статья писалась для внутреннего употребления в нашей компании – обобщил и систематизировал свой опыт. Думаю, кому-то она будет полезной. В процессе подготовки статьи немного отредактировал первоначальный вариант.

26.04.2017    23990    0    Soliton    33    

Концепция автоматизации многопрофильного Холдинга в системе АУБ на платформе 1С

Техническое задание Управление проектом Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика Бухгалтерский учет Управленческий учет (прочее) Финансовый учет и бюджетирование (FRP) Управление холдингом (CPM) Учетная политика v8 Россия УУ Бесплатно (free)

Это схема и обоснование концепции системы АУБ (Автоматизация Управления Бизнесом, авторская разработка) для автоматизации многопрофильного холдинга на платформе 1С. Система изначально проектировалась для многопрофильного холдинга, что определило особенность ее концепции - три уровня автоматизации. Система АУБ не является готовым решением, это определенная концепция (видение, подход) к автоматизации управленческого учета и расширяемый базис наработок реализованных в этой концепции. В конкретном проекте автоматизации, с учетом специфики управления предприятием, делается индивидуальная «функциональная сборка» с использованием готовых, существенно модифицируемых и заново разрабатываемых подсистем. Таким образом, концепция и расширяемый базис наработок системы АУБ, представляют своего рода конструктор, из которого компонуется решение в конкретном проекте, при этом заново разрабатывается лишь функционал, отражающий новую специфику. На практике концепция использовалась, например, в отраслевом решении для производства ЖБИ и добычи нерудных материалов.

02.03.2017    18315    0    aaw    3    

Как самим написать техническое задание

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

Как показывает практика, под заветной аббревиатурой «ТЗ» понимаются совершенно разные по сути, содержанию, оформлению и детализации документы. 

21.02.2017    14257    0    user694964_olamikyw    6    

Проектное внедрение прав доступа в системах 1С

Техническое задание Управление бизнес-процессами (BPM) Управление проектом v8::Права 1cv8.cf Бесплатно (free)

Для крупных предприятий я рекомендую разрабатывать "Техническое задание на права доступа в системе 1С Предприятие 8". Данная работа сопровождается комплексным подходом по аналогии проектного внедрения. Рассмотрим порядок работы, переход от исследования к ТЗ и критерии упрощения документации.

17.01.2017    17371    0    Gavrik    4    

Наблюдения, которые указывают на решимость предприятия к изменениям

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

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

06.12.2016    18941    0    Gavrik    19    

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

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

Хочу рассказать об очень интересном проекте, с которым мы недавно столкнулись. В этом проекте необходимо было сделать огромный объем работы за очень короткий промежуток времени, поэтому мы его условно назвали «Марафон со спринтерской скоростью».

26.09.2016    14322    0    R.Tsarenko    27    

Дропшиппинг или "виртуальные" склады поставщиков в 1С

Техническое задание Оптовая торговля Розничная торговля Учет ТМЦ Оптовая торговля Розничная торговля Учет ТМЦ v8 УТ10 УУ Бесплатно (free)

Сейчас всё больше компаний работают по системе дропшиппинг (прямые поставки, когда поставщик отправляет товар непосредственно клиенту, а не продавцу) или продают товар со склада поставщика не закупая его себе на склад (под конкретные заказы покупателей). При этом за частую есть необходимость хранения остатков и цен поставщика, выгрузки их на сайты и другие информационные ресурсы, рассылки в своих прайс листах. В статье рассматриваются варианты отражения подобных операций в управленческих конфигурациях 1С без привязки к конкретной конфигурации. С некоторыми различиями данные схемы можно применить в Управлении торговлей 10 и 11, Рарус:Альфа-авто, Комплексной автоматизации, УПП и др. т.е. в целом в любой конфигурации с возможностью ведения управленческого учета и механизма заказов.

02.09.2016    28075    0    de0nis    17