Вступление
Вавилонская башня - известный всему миру пример великого замысла, который провалился.
Причина провала - внешнее вмешательство бога, который заставил людей говорить на разных языках, и те просто не смогли продолжить совместную работу над проектом.
В современном мире отсутствие общего языка, типовых инструментов и хорошо специфицированных требований приводит к провалу множества IT-проектов и без воздействия извне.
К счастью, у некоторых IT-проектов, есть люди, которые могут помочь исполнить задуманное - это IT-архитекторы.
Эти профессионалы призваны решать целый спектр проблем и вопросов, принимать решения различной степени сложности, а порой и менять первоначальные замыслы. И всё это ради того, чтобы достичь результата по его духу, а не по формальному описанию.
И конечно, каждый такой специалист накапливает свой багаж знаний, получает свои уникальные умения и выносит свои выводы и суждения.
Ведь башня огромная, и каждый смотрит на неё со своего угла, компетенций и яруса, на котором он работал.
Здесь я хочу описать свой опыт строительства башни, рассказать о своих ошибках и правилах ведения архитектуры.
Если вдруг вы окажетесь на моей стороне башни, возможно, эти советы будут вам полезны и спасут от досадных ошибок, потраченных нервов и необходимости начинать если не с нуля, то с пары шагов назад.
Чтобы статья не вышла слишком длинной и не читаемой, я буду публиковать ссылки на отдельные статьи правил ниже. Каждое правило это законченный текст, который можно читать отдельно.
Правило 1. «Документируйте свои решения, особенно временные»
Правило 2. «Любые временные решения – зло»
Павило 3. «Не будь пассивным участником»
Правило 4. «Ешьте слона по частям: люди боятся больших задач»
Комментарии (8)
avf48
10.04.2022 19:19В современном мире отсутствие общего языка, типовых инструментов и хорошо специфицированных требований приводит к провалу множества IT-проектов и без воздействия извне.
Не соглашусь с вами. Языки и инструменты есть, вот только в ИТ сфере за их применение могут сжечь на костре... Почему? А по тому, что не умеют у нас Заказчики и PM'ы описывать требования к конечному продукту, который должен встроиться в бизнес... тк бизнес архитектура тоже не описывается.
Как только у IT специалиста появится ответственность, за продукт, то тогда и документация сразу появится... Тут как получается, если меня, как разработчика, начинают спрашивать за результат, то тогда и к заказчику требования по формулированию целей и возможностей тоже повысятся.
Типичный ответ сейчас: "- Как просили я так и сделал...".
Я бы посмотрел на того Айтишника в больнице или у стоматолога, который в подробностях рассказывает как и чем его лечить...
Не спорю, я тоже работал без ТЗ и внятной постановки задачи, но в этом случае, я Архитектуру брал из Стандарта, типовую, которая по умолчанию закрывает все бизнес задачи, не согласовывая её с заказчиком. (И да, потом сам объяснял как должен работать бизнес в тех или иных ситуациях... благо образование инженерное).
Для примера, список стандартов, которыми пользуюсь
Эти профессионалы призваны решать целый спектр проблем и вопросов, принимать решения различной степени сложности, а порой и менять первоначальные замыслы. И всё это ради того, чтобы достичь результата по его духу, а не по формальному описанию.
Профессионал начинается с Профстандара.
Ничего не надо менять... Нужно на берегу определиться какую цель должна выполнять система...
Бизнес-аналитик, Системный аналитик
Картинка ниже отражает 7 элементов, которые должны быть осознаны до начала проекта.
7 Альф инженерного проекта
Альфа: Обязательный элемент программно-инженерной деятельности, относящийся к оценке прогресса и состояния деятельности.
Возможность: Совокупность обстоятельств, которая обусловливает разработку или изменение программной системы.
Действие: Определяет один или более видов единиц работ и дает указания по их выполнению.
Деятельность: Действие или набор действий, направленных на достижение цели.
Единица работы: Часть работы, которую необходимо сделать, чтобы завершить работу.
Команда: Группа людей, активно вовлеченных в разработку, обслуживание, поставку, внедрение или поддержку конкретной программной системы.
Заинтересованные стороны: Люди, группы или организации, которые влияют на программную систему или находятся под ее влиянием.
Программная система: Система, состоящая из программного и аппаратного обеспечения и данных, главная ценность которой создается посредством исполнения программного обеспечения.
Работа: Деятельность, в рамках которой предпринимают умственные или физические усилия, направленные на достижение результата.
Технология работы: Адаптированный набор практик и инструментов, используемых командой для ведения и поддержки ее работы.
Требования: То, что должна сделать программная система, для того чтобы воспользоваться возможностью и удовлетворить заинтересованные стороны.
PS: Коллеги, Тема хорошая, давайте обсуждать!
В сложившейся на рынке ситуации, нам (Отечественным ИТ специалистам) нужно закрыть дыры именно в части стандартных/типовых решений.... SAP, Сименс ПЛМ, и др. все эти гиганты просто автоматизировали стандарты СИ, не больше... Незачем строить башни, нужно заводик кирпичный сделать.
Marcus_Agrippa Автор
10.04.2022 19:22Я не говорю, что стандарта нет. У строитель вавилонской башни я думаю были и чертежи и стандарты, иначе они бы просто не смогли этого построить. Но вопрос знают ли все эти стандарты? все ли их одинаково понимают? Все ли ими пользуются. Наиболее частый ответ на переписывание кода, который я слышал это все делали не мы, тут все не правильно, будем писать сами. Собственно когда таких команд много, архитектору приходится всех их собирать воедино.
avf48
10.04.2022 20:36+1У строитель вавилонской башни я думаю были и чертежи и стандарты, иначе они бы просто не смогли этого построить.
Вроде как и не смогли)))
Смотрите, чертеж относится к конкретной конфигурации продукта, а стандарт нужен для взаимодействия на уровне смежных систем. (прим.: Система- автомобиль. Стандарты: на сами авто, инфраструктуру, гсм и тд) те Можно делать любое авто (соотв условиям), которое должно использоваться на таких то дорогах и в таких то условиях.
И в стандартах (я сейчас про стандарты на Системы) всегда есть набор процедур, обеспечивающих качество. Например исо 9001 - очень полезная штука, только вот я ещё не видел предприятия, где бы он был именно внедрен... а не вот это вот всё! Я утверждаю, если СМК организации соответствует 9001, то Вся автоматизация пойдет, как по маслу, тк суть этого документа в наведении порядка именно у Руководителей (в Управлении), рабочему и программисту он не нужен у них свои есть.
*в IT почти все пользуются стандартами (прим: SOAP), просто не в курсе, что это такой же стандарт, как и на колбасу.
Но вопрос знают ли все эти стандарты? все ли их одинаково понимают?
Вот именно для этого ими нужно пользоваться всем. Разбираться в требованиях в своей области обязан каждый специалист! Выбрал профессию - прочитал проф стандарт! Если Профессионал не знает НТД в своей области, то он не профессионал, а пустозвон (даже если это супер мега аналитик-архитектор-программист-бариста).
ПС: Хоть может показаться что я сейчас наезжаю на ITшнико, но в большей степени это относится к руководителям всех уровней, именно они заваривают кашу, со словами "- Я насяльник, мне виднее". Если к тебе, мой IT друг, пришел заказчик без ссылок на стандарты, то это уже должно быть звоночком! Не ведись, он сам не знает как нужно.
ППС: для начинающих аналитиков я бы рекомендовал такой порядок анализа задачи: 1. У того, что хотят есть Цель и Границы? 2. Описаны под и над системы? 3. Определен их ЖЦ? Нет ли подобных систем на уровне концепций (прим: eTOM, BIAN, PODS).
А лучше всего учиться у нашего ВПК, у тех, кто строит самолеты, танки и ракеты!
И лучше забудьте про "Гибкие" методы... Всё должно быть по ГОСТу - шутка!! Ни кто не запрещает сделать лучше.
Гибкие методы, дают возможность не замечать ошибки и риски, а так же прощёты руководителя проекта (они же всегда не при делах).
ПППС: не знаю почему все минусят, я считаю, что такие темы нужно обсуждать. зачем тогда хабр нужен? +
funca
10.04.2022 21:59не знаю почему все минусят, я считаю, что такие темы нужно обсуждать. зачем тогда хабр нужен
Тут кто в теме обсуждает, остальные минусят. Хабр уже давно развернулся в сторону новостных механик. Поэтому все ждут чего-то нового, а не большого.
Мне кажется автор промахнулся с частотой публикаций статей своего цикла - слишком много новостей на одну и ту же тему выглядит уныло и вызывает негатив. Комментаторы теряются, что комментировать. Сделал бы паузу в несколько дней между публикациями, результат мог быть абсолютно другим.
zelcam
«Чтобы избавиться от глистов, нужно всего лишь…»
Marcus_Agrippa Автор
Я выкладываю материал по мере его подготовки к публикации, просто наберитесь терпения. Два совета уже есть:)
avf48
И соглашусь с коллегами, всё что сейчас опубликовано, можно было одной статьей.
Marcus_Agrippa Автор
Ну тут видимо у нас разное представление. Я конечно могу это в одну статью засунуть, только думаю читать это будет тяжело. Потому что 5 правил это уже 15 страниц текста А4, а если их будет скажем 40, то это такой трактат, который ты откроешь, увидишь объем и закроешь. Изначально я хотел выкладывать по одной статье раз в неделю скажем, так коллега жаловались, что мало текста и не понятно. Выложил 5 сразу, ой а чего не в одной статье. Не знаю какая формула правильная. Хотелось бы по сути получить комментарий - полезно или нет, а как выкладывать я тогда подумаю.