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

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

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

Перейти к публикации

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

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


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

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

Как

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для начала надо уточнить, что в 1С-проектах используются системные аналитики. Бизнес аналитики как правило являются заказчиками для системных аналитиков. Системный аналитик - это файервол между бизнесом и командой разработчиков. Берёт на себя все первичные разговоры с бизнесом, проверяет адекватность и реалистичность, систематизирует, отсеивает шлак, и выдает команде в краткой содержательной форме основной смысл хотелок. Далее после того как РП проверил эти хотелки на входимость в рамки проекта, можно сделать второй подход к бизнесу с уточняющими вопросами. Вот тут уже могут быть варианты, кто пойдет - аналитик или архитектор. О правилах ролевой игры проектная команда договаривается внутри себя заранее. Тут главное слово скорее за РП.
Многое зависит от кадровой составляющей - если достался сильный аналитик и никакой архитектор (который максимум тянет на релиз менеджера) - это беда! Если наоборот - в принципе архитектор конечно вытянет две функции, но есть риск что поплывут либо сроки либо качество.
Это касается первой фазы проекта - постановка, проектирование, моделирование.
На второй фазе (разработка и внедрение), когда основные хотелки уже выявлены, аналитик нужен разве что для проверки уточненных требований на соответствие скопу проекта. Его функции плавно перетекают в то, о чем написано в статье. Либо аналитик вообще уходит.
38. gavlexx 37 01.07.20 17:22 Сейчас в теме
Архитектор должен выяснять у Заказчика требования? При разделении труда - точно нет. Только если он же - и выясняет, и строит архитектуру и программирует.
Но цикл статей же не о "на-все-руки-мастеров-1С", верно? :)
Casey1984; Grania; for_sale; +3 Ответить
39. biimmap 76 01.07.20 17:30 Сейчас в теме
(38) Вечер добрый. Почему люди размышляют ОДНОЙ ЕДИНСТВЕННОЙ ЗАДАЧЕЙ? Статья написана про проект в целом. Проект состоит из множества задач. И всё это множество между собой связано! И только в этом ракурсе необходимо воспринимать написанное! Я написал про КОНЦЕПЦИЮ, т.е. АРХИТЕКТУРУ.
Могу сотнями приводить примеры, где Аналитик, так восхваляемый некоторыми, приносил от Заказчика вообще не то. Просто не понял смысл задачи. В таких случаях возникает сомнение в правдивости принесенной информации. Выясняю сам - получаю совсем другие ответы.
43. Yashazz 3330 01.07.20 20:04 Сейчас в теме
Трепология ни о чём. Пустое умствование. И знаете почему? Потому что а) использующие архитекторов имеют своё видение, оно у них как откровение свыше, альфа и омега, пуп их знания о проекте, и переубеждать бесполезно; б) не использующие архитекторов свято убеждены, что без них всегда жили и дальше прокатит; в) ничто не влияет на процесс внедрения и эксплуатации системы меньше, чем наличие/отсутствие и качество архитектора на проекте.
user700897_nkt1c; Maxisussr; Ta_Da; akimych; vaskomain; Grania; biimmap; +7 1 Ответить
56. blindcat2006 72 12.07.20 17:07 Сейчас в теме
(43) Поднялась рука оценку поставить за емкий комментарий... да не знаю какую кнопку нажать

а) и б) - плюсую ++ (2"+")
в) - люто минусую. Ибо дело на в личностях и строчках приказа о приеме на работе. ВЛИЯЕТ. И сильно. только архитектор не обязательно отдельно сидящая на троне личность с нимбом в виде непомерной ЗП (как тут некоторые писали).
Им может быть и программист въедливый и не ленивый (да таких сейчас редко делают).
И консультант дотошный (и как раз ленивый) которому надоедает тысячный раз дописки делать и начинает он системно к вопросам подходить.
Потому извините - оставлю Вас пока без оценок ))
57. Yashazz 3330 12.07.20 20:50 Сейчас в теме
(56) Видите ли, может оказаться замечательный программист, отличный методист, и выйдет прекрасный продукт. Может оказаться криворукий кодер и ленивый пофигист-методист. Но и в том, и в ином случае собственно внедрение и работа системы будут зависеть совершенно от другого - от настырности руководства автоматизаторв и РП, от упёртости руководства автоматизируемых, от политических подковёрных игр, дележа власти и денег, заказов, траншей, контрактов и прочая. В результате у замечательной разработки и у адской стрёмной поделки почти равные шансы (поделка даже лучше, она такая примитивная и понятная, что интуитивно кажется доступной и потому "нормуль" с точки зрения командующих дилетантов). И-таки мыши будут колоться, да жрать кактус. Независимо от вклада тех, кто оный кактус растил и поливал... Вот я о чём.
58. biimmap 76 12.07.20 22:13 Сейчас в теме
(57) В какой-то степени Вы правы. Но на своих проектах я всегда стаскиваю руководство с небес на землю и тыкаю в правду. Т.к. я не занимаюсь политическими играми (я не РП. а технарь), то руководству приходится смотреть в правду и проект идёт как надо!
На моих проектах именно мой опыт позволяет избегать политики.
44. sapervodichka 3671 02.07.20 00:05 Сейчас в теме
Мне понравилась данная статья, т.к. в моей жизни реально происходит то, о чём пишет автор. Приходится общие концепции в разработке контролировать у групп программистов. Обидно только, что оплату и полномочия архитектора не каждый РП выделяет на своём проекте (т.к. придётся премией делиться к архитектором) и часто время за концепт и целостность продукта оплачивается по той же ставке, что и разработка отчета или документа. Короче фигня такая *)
45. biimmap 76 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 76 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. Мысль не моя, я просто разместил ремарку.
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 72 12.07.20 16:52 Сейчас в теме
Там много слов.... (в коментах) , так мало ... общего, в понятиях. Может стоит посмотреть что такое архитектор вообще и в частности:
Архите́ктор (от др.-греч. αρχι- — главный, старший и др.-греч. τέκτων — плотник, строитель[1]) — квалифицированный специалист, который на профессиональной основе осуществляет архитектурное проектирование (организацию архитектурной среды), включая проектирование зданий, в том числе разработку объёмно-планировочных и интерьерных решений.

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

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

Именно об этом и писал статью! Что архитектор - ГЛАВНЫЙ. Но меня тут чуть не порвали на тряпочки... Вам спасибо!
Оставьте свое сообщение
Вопросы с вознаграждением