Category Archives: Без рубрики

Как думать об ответственности архитектора?

Интересный факт, что рано или поздно в любом чате про архитекторов возникает примерно такой фрагмент диалога:

Собеседник 1: Архитектор должен брать на себя ответственность за качество всего проекта.
А из этого вытекает — должен иметь право на принятие решения, иметь право распоряжаться некоторым объёмом ресурсов для рефакторинга.

Собеседник 2: Это лютый бред. Нет у архитектора никакой ответственности, и соответственно, никаких решений, кроме мелких технических, он принимать не может. Ответственность есть у того, кто владеет ресурсами и бюджетом, и это не архитектор. Про тех, кому нравится думать про ответственность на позиции архитектора, можно сказать одно: она для них никогда не наступала.

Оставим в стороне безапелляционную форму реплики №2, и сконцентрируемся на одном крайне важном моменте: собеседники вкладывают совершенно разный смысл в термин «ответственность«. Для Собеседника 1 «ответственность» — это то, что берут на себя. Для Собеседника 2 «ответственность» — это то, что «наступает».

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

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

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

Я: Не надо путать административную ответственность и деятельностную. Слово одно, смысл совсем разный, второе бывает без первого, и в организации в первую очередь нужно второе, а не первое. Рассказывал об этом тут: https://bespalchuk.ru/presentations/goal-and-responsibility
Роль архитектора предусматривает наличие весьма широкой д.ответственности — за качество и своевременность принятия, согласования, трансляции архитектурных решений. Подкреплено ли это а.ответственностью и какого масштаба — это вопрос вторичный.

То, о чем говорите вы — это скорее административная (пост-фактумная) ответственность. Если вы не видите за этим словом второго, совсем другого понятия, вы упускаете главное и говорите только про второстепенное, которое вовсе не так интересно и важно.

Вкратце, а.отв — это что вам будет плохого, после факапа. А д.отв — это ваша деятельностная позиция и что вы делаете/думаете для того, чтобы факап не случился. Первое — один из инструментов усиления второго. Но второе важнее и его можно обеспечивать без первого.


Собеседник 2 (продолжает описывать а.ответственность): Ответствнность — это всегда «когда есть что терять». Другое дело, что некоторых только угроза жизни заставляет о чем то думать, а некоторый — недобрый взгляд начальника / жены.


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


Собеседник 3 (тоже зацепился за постфактумную половинку значения термина отв.): А почему тогда «отвественность» вдруг становится именно «ответственостью» если после ее наступления для человека ничего не меняется?


Я: Еще раз, это как функция и реализация — вроде как про одно, но вообще-то про разное. Вас опять сносит на мотив, хотя это десятое дело, важнее наличие/отсутствие поведения/мышления/фокуса внимания (д.отв). Вторичный вопрос, каким мотивом это поведение обеспечивается. Ну и даже обсуждая альтернативные мотивы типа профессиональной гордости, репутации, социальных норм, вы вынуджены их подводить под а.отв типа «человек не хочет, чтобы его мучала совесть». Хотя проще разлепить эти вещи (кстати, это не я придумал, можете и в википедии почитать про проспективную/ретроспекттвную отв.), и после этого сказать, что д.отв может обеспечиваться наказанием (а.отв), но может и другим — причастностью, профессионализмом, социальностью, etc. Сразу картинка становится богаче. А самое важное, что организация в первую очередь строится из д.отв, как «круги» в социократии. А не из наказаний. Совсем другой залог рассуждения и орг-проектирования. Я уверен, между собой с коллегами вы обсуждаете разделение ваших ответственностей в терминах «кто за что», а не «кто чем», не так ли? 🙂
Еще одна очень простая и понятная модель — волейбол. Что важнее и первее — договориться о том, где чья зона под сеткой, за которую отвечает тот или иной игрок, или «как кто будет наказан»? 🙂


Собеседник 2 (продолжает упорствовать и ввел еще редукционистскую «первичность») мотив первичен. Без мотива человек не встанет с дивана. А про волейбол — мотив победить. Нет такого мотива — да ваще можно на площадку не выходить, пусть техническое поражение защитают


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


Собеседник 2 (отказывается слышать): из лекции следует, что наличие мотива вторично для деятельности, что является неправдой.


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


Собеседник 2: понимая механизм, я могу додумать более высокоуровневую абстракцию. Если я знаю только абстракцию, без механизма, то переодически я буду иметь проблемы с объяснением происходящего.


Я: Согласен с вами. Точно также как проектирование систем сверху вниз всегда дополняется проходами снизу вверх, а functional view дополняется development view’шкой. Я готов смягчить свои слова по поводу важности, но стою на полезности разлепления 🙂 Уверен, что мы уже потренировались достаточно, чтобы прочитав сегодняшнее обсуждение с самого начала уже стало четко заметно, где произошел перескок с разговора о д.отв на разговор об а.отв. Главный тезис, который, на мой взгляд, становится очевидным после разлепления — архитектор может быть офигенно ответственным за многое (в смысле д.отв), даже если он не отвечает ничем материальным (а.отв), мотивы/механизмы обеспечения д.отв могут быть и другими. То есть одновременно — «ответственность есть» и «ответственности нету» — это классическая ситуация, когда надо разлеплять понятия, расщеплять на два.


Собеседник 4 (пошел топить за «все хорошее против всего плохого» и вводить рассмотрение психического «внутри»): Безответственность порождает наплевательство и вседозволенность. ответственость != наказание, но ответственость === «есть что терять».
Разница принципиальная: «наказывает» как правило кто-то «снаружи», а «теряю» я внутри. Мало того, «наказывать» != «есть что терять», точнее часто не равно.
Можно переформулировать: отвественость это недополучение мотивационных полюсов в результате недоделанных (виновных) действий. По этому ответственность прямо проистекает из мотивации. Он неразрывно взаимосвязаны.
Опять же «внутренняя отвественость» — это когда я сам недополчил (или недодал себе) этих самых мотивационных плюсов, оценив свои результаты как «не очень».


Я: Да, бывает и так, конечно (про безответственность ведущую к провалам). Именно поэтому часто в прошлом под мостом, по которому проезжает первый экипаж/автомобиль/поезд стояли двое — архитектор и начальник стройки. Механизм а.отв конечно иногда работает и иногда очень эффективно (обеспечивая д.отв), кто ж с этим будет спорить. Я ж про другое.

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


Собеседник 4 (все еще не разлепил А и Д): Погоди. Ну давай представим: мы пошли в поход компанией. Кому то было поручено взять с собой например те же спички. И он не взял. Просохатил, без злого умысла. Отвественность наступит? — БЕЗУСЛОВНО ДА!


Я (пытаюсь подвести итог): Я всего лишь говорю, что мы этот разговор неявно для себя начинаем в терминах д.отв — кто отвечает за что, не так ли? И с этого начинается организация и в этот момент мы не думаем о последствиях-если-не. Потому что вопрос в другом — как нам собрать целый результат. И только если вдруг что-то регулярно идет не так, мы говорим «Вася, ты задрал, если еще раз забудешь спички, не возьмем больше». И это другой вопрос, не так ли? Так вот, из-за лингвистического казуса в обоих случаях мы используем термин «ответственность», заметили? Хотя смыслы вообще о разном. Ergo: полезно разлепить термин (добавлением прилагательного) и понятие (запомнив, что можно думать про А и не думать про Б).

Друзья, еще раз, обратите внимание, это не я придумал, это все в википедии тоже написано 🙂 Буквально «ученые изучают этот мутный вопрос, но уже выделяют несколько значений/видов ответственности «.

А еще через пару десятков реплик с другими собеседниками мы вдруг видим:


Собеседник 2: Теперь уже ты наглухо игнорируешь ответственность, как наказание, как одно из значений слова. Чтобы избегать путаницы, предлагаю заменить твою часть на «добросовестную работу«, а мою часть на «получение люлей«.


Я (влезаю опять): Ага. Именно. Оно и есть. «Проспективная» (думай наперед и подкладывая соломку) и «ретроспективная» (получай люлей) ответственность — другие «научные» названия того же самого, о чем я тут распинался. Вроде вышли на различение как минимум в кейсах, ура! Осталось убедить, что когда слева — крякает, плавает, откладывает яйца и в перьях, а справа — кормит детенышей молоком, на голове — рога, на четырех ногах — копыта и живет в лесу, то можно конечно и то и это назвать одним словом «дичь» и подать в составе одного блюда на стол, но в огромном числе других жизненных ситуаций лучше называть разными словами. 🙂
И тогда не будет воспроизводиться этот самый антипаттерн в чатиках «— Архитектор отвечает за это и за это. — Это бред, архитекторы никогда ответственности не несут!«, с которого начался и наш разговор вчера.

Про власть разработчиков

Выношу из чата архитекторов про «власть, которая то ли есть, то ли нету у разработчиков»:


…Это очень интересный вопрос. Казалось бы, у разработчиков, которые собственно, пишут код — власти очень много! Адизес, кстати, в таком же духе разъяснял про большую власть, которая есть у рядовых исполнителей. И иногда мы видим проявления этой власти — какие-нибудь экспериментальные фреймворки, всунутые куда надо и куда не надо. Но в другие моменты разработчик начинает спрашивать — а мне так сделать или эдак, и вот тогда ему прилетает ответ, и вдруг власть как будто исчезает. Боб Мартин в одном хорошем своем цикле встреч на этот вопрос про техдолги и рефакторинг и тесты отвечал так — никогда, ни при каких обстоятельствах не показывайте тесты или рефакторинг как отдельные строки затрат менеджменту, это ваша поляна и ответственность — как написать или изменить код. Если вы это покажете, вам это вырежут и вы будете без тестов и без рефакторинга, и как раз и превратитесь в безвластных г..кодеров. Я думаю, что в этом есть смысл, и на самом деле у разработчиков очень много власти. Архитектор, кстати, это чувствует очень хорошо, потому что ты ж явно говоришь и пишешь сделать одно, а они делают другое 🙂 Нужно только научиться об этой власти вспоминать и правильно к ней относиться, разумно использовать.

Про системное мышление

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

В очередной раз отвечая на вопрос о том, «ну что же такое это системное мышление» я вздохнул и написал это:

> (собеседник)… Хотя… пока термин (системное мышление) не раскрыт, судить о его смысле, не верно….

Давайте раскроем конкретнее, выпукло и поэтично. Хорошо освоенное системное мышление — это когда вы: быстро (в «реальном времени», в середине разговора, на грани осознавания, как обычно водите машину, но при необходимости осознавая на 95%) очень многие попадающиеся вам ситуации и вещи раскладываете по характерной мета-модели, в которой есть связанная группа понятий: система (подсистема, надсистема, целевая/обеспечивающая система), роль=функция, элемент/функциональный компонент, материал=морфология, стейкхолдер/интерес, модель/описание/вид/точка зрения, производственный/эксплуатационный контекст, потребность/требование/решение/архитектура/дизайн, функция/процесс/слой, структура/состав, связь/отношение, паттерн/стиль/архетип, понятие/знак/значение/термин, обязанность/ответственность; бегло (также на скорости речи) перемещаетесь между системными уровнями, между позициями стейкхолдеров, между точками зрения; за счет этого можете свои интуитивные «чуйки» (которые у вас были всегда) обосновать рационально, быстро протянув цепочку следствий и влияний от внутреннего технического решения до интересов стейкхолдера; проще можете «продать» идею, понимая позицию стейкхолдера; мыслите примерно одинаково системно и «железные» технические системы, и программные, и организационные, потому что в этой метамодели нет разницы; отказываетесь от любых правил, best practice, и догматов («Scrum велит делать так!») и переходите к механизмам и ситуациям, причинам и следствиям в данном конкретном окружении; начинаете требовать рациональных объяснений от других, не удовлетворяясь скрижалями и авторитетами; обнаруживаете, что многие «методологии» (от SOLID и DDD до Теории Ограничений и TOGAF) суть ограниченные и иногда ущербные частные примеры общих принципов системного подхода; легче определяете любую деятельность как целенаправленную или механистичную/догматичную; отказываетесь от многих ритуалов, не встраивающихся в цепочку системных причин и следствий до ваших интересов; легче принимаете те ритуалы, которые встраиваются в ваши интересы, даже будучи в остальном бессмысленными :), начинаете различать проблемы и задачи, реальные цели и модные лозунги, проблемы в компетенциях/личности и в организации; лучше предвидите проблемы, вызванные недостатками организации; легче отказываетесь от «стандартов», не несущих пользы, лучше видите ход мысли других людей и лучше можете его направлять, подбрасывая в реальном времени новые схемы и понятия; понимаете системное устройство коммуникации и за счет этого спокойнее и быстрее договариваетесь или рационально переубеждаете; можете объяснить по шагам, как и для чего вы делаете все вышеперечисленное и почему это наилучшее с вашей стороны действие в данный момент в данной ситуации.

Сегодня мне это видится как-то так 🙂

Copyright © 2023 Igor Bespalchuk