Size: a a a

Работа для ИТ-архитекторов

2021 November 05

ГШ

Григорий Шатров... in Работа для ИТ-архитекторов
Берём его, сажаем рядом с собой, пишем под диктовку.
источник

ОИ

Олег Игонин... in Работа для ИТ-архитекторов
Причины могут быть либо резонные, либо не резонные.
Если они резонны, то помогаем, если нет, то... А какого чёрта только через 6 месяцев стало понятно, что он ничего не делает?
Кажется, что это вопрос не к архитектору)))

Но в целом, "что делаем?" зависит от позиции того, кто должен делать.
источник

RK

Roman Klin in Работа для ИТ-архитекторов
Неясно,  что это за проект,  в современном ИТ, где архитектор решения может сидеть полгода и что-то приодумывать у себя в голове,  не выдавая ничего команде... ситуация выглядит искусственно.
источник

GC

George Cronk in Работа для ИТ-архитекторов
Стейтмент понятен. Хорошо. Давайте усложним.

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

Не совсем понял про позицию. Что вы имеете ввиду? Если вы про виртуального архитектора - о да, он хочет все сделать. Просто временная ось она иная :)

\\
добавлю тут же @klin_rl . так как не получится попостить еще раз быстро.
Ситуация искусственная, именно ее мы и обсуждаем.

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

Вот как раз вопрос не о ситуации, а об ответе на такую ситуацию
источник

ОИ

Олег Игонин... in Работа для ИТ-архитекторов
Я человек маленький в айти. Понимаю, что в том же КХМбанке чтобы внедрить новый продукт порой бывает надо года два поработать.
Но для CTO эти сроки +/-  должны быть понятны, т.к. для них это не первый проект. Но тут всё зависит от корректности декомпозиции и желания вникнуть в проект.
У каждого проекта есть MVP. Нужно смотреть на его объём, нужно понимание состояние требований, нужно смотреть команду.

Но в целом, если MVP проекта в не очень большом домене при наличии архитектора не выходит в прод, то это прямая заявка на провальность проекта.  Хотя последнее тоже зависит от многих факторов.

Пример: сделать ракету или веб-приложение. В одном случае проектная документация будет рассчитываться в годах, в другом в месяцах. И задача проектного офиса и CTO постоянно следить за проектом, чтобы видеть недостатки в ресурсах или персонале для выполнения MVP или проекта целиком.

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

Нормальное управление как раз про второе.
источник

GC

George Cronk in Работа для ИТ-архитекторов
Да все так. Полностью поддерживаю все выводы.

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

Второе, это управление. Усложним.
Допустим, задачи ставились одни, а делаются другие. Например, арх заявил, что знает лучше что надо делать в первую очередь и это требует, скажем, 2-3 мес. Дал обоснование. Время прошло - ничего нет. О как! )
 
Вот случилась, допустим, описанная ситуация. Что предлагаете делать с этим?

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

ОИ

Олег Игонин... in Работа для ИТ-архитекторов
Разбираться в первопричинах. Реально ли это нужно было? Достаточно ли у него было времени и ресурсов, чтобы создать документацию?
Да, он оценил в 2-3 месяца. А что пошло не так? А проблема это архитектора вообще? Может быть там были получены новые вводные? Может кто-то занимается саботажем проекта в целом по какой-то иной причине и тормозит процесс? Может быть ресурсы, которые архитектору выделили на деле не были выделены?

Вы пытаетесь просить нас решить уравнение из трёх неизвестных, когда на деле их там куча.

Главный ответ, лично от меня. За проектом надо следить, видеть как он "дышит", вовремя решать возникающие проблемы и распутывать узлы.  Если вы у нас спрашиваете такие вопросы, значит вы не знаете достаточно деталей и обстоятельств, которые привели к данной ситуации.

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

Если вы не в курсе того, что у вас происходит на кухне, то какой из вас шеф-повар?

О проблемах сроков 6 месяцев вы должны были узнать уже на 1-2 месяце совместной работы. Это вроде называется риск-менеджмент.
источник

GC

George Cronk in Работа для ИТ-архитекторов
Погодьте, погодьте 😊 Вы так меня обвините в чем то... 😃

Я же создал ситуацию для обсуждения. Это же не пример из жизни. Данные у меня все, так как я их создаю от вопроса к вопросу, если вы заметили. Мне важен ход мыслей сообщества.

Сам то я свои мысли знаю. Я исследую ход мыслей отвечающих людей.


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

Какое бы решение вы бы приняли?

\\
К слову, на нашем проекте (ПОЛАТОР) дефект заметен уже через 3 дня, так как ежедневные чеки ALM,  и принимаются митигирующие действия.
источник

ОИ

Олег Игонин... in Работа для ИТ-архитекторов
Зависит от человека. Можно:
- найти крайнего и скинуть проблему на него
- начать делать работу за арха самому (если сесть квалификация и острая надобность)
- найти другого арха, а этого уволить
- прокоучить этого арха (как надо, что надо делать, какие точки надо достигнуть и когда) вот прямо с ним и отработать следующие 2 месяца, неа своём примере показав как надо + курсы по т-менеджменту накинуть
- забить (вай нот?)
- попросить арха из другого отдела сделать работу/прокоучить арха №1
- выкинуть арха из проекта и заменить человеком, который и без арха справится (тут качество может быть разным)
- оставить арха, начать его оправдывать, тянуть сроки
- уволиться/сменить отдел/позицию и это уже не ваши проблемы (вай нот?)
- переложить проект другому менеджеру/команде
- отдать на аутсорс

Мне продолжать или уже понятно, что всё будет зависеть от конкретной ситуации, наличия ресурсов, человека, который принимает решения?
Как я сказал, слишком много неизвестных. =)
источник

GC

George Cronk in Работа для ИТ-архитекторов
Согласен. Слишком искусственная ситуация.

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

Неизвестных, конечно много, как и невозможность подобной ситуации. Это просто не бывает так.
Я взял в пример срок 6 месяцев потому, что, например, 3 или 1 или 2, могли бы вызвать много вопросов. Но 6 уже зашквар по теме арха, а по другому кровожадность не смог выразить =)

Снимается вопрос.
источник

ОИ

Олег Игонин... in Работа для ИТ-архитекторов
Вообще, 6 месяцев невозможно работать арху без документов, т.к. уже на втором месяце в голове не останется места для удержания контекста большого проекта.
Проще будет выгружать структуру в схемы в виде диаграмм, списков требований, ссылок, документов.
Это как держать в голове схему авианосца - можно понимать где корма, где палуба, но отсеки и их детали для головы обычного человека - это уже чересчур.
Конечно если все 6 месяцев - это согласования и информация собирается в meeting notes, то это тоже вариант.
Бывает, что для арха проект шаблонный, тогда и для количества умещающегося в голове требуется меньше места и он реально может 6 месяцев думать, потом неделю писать и запускать проект на 8й день.


VVV

Тут проблемы две:
а. Вообще этот чат не для таких бесед, есть https://t.me/itarchitect
б. Если схемы часто меняются, то лучше их не рисовать в компьютере, а калякать на доске и фоткать впоследствии
источник

G

Grigoriy in Работа для ИТ-архитекторов
Вот да, Я пока не арх, но когда продумываю взаимодействие систем, как минимум какая-то схема уде рисуется, и вместе с ней, уже набрасывается описание. Оно может меняться несколько раз ещё, но история мысли в вики будет видна
источник

GC

George Cronk in Работа для ИТ-архитекторов
да, так и есть.
У нас например это видно через пол недели, а через неделю пайплайн блочится. Это ахтунг и ни разу не было.

Но в целом, интересовало мнение о том, как кто считает. Например, можно идти сначала вширь, а потом вглубь (это наш тех процесс), а можно идти вглубь а потом вширь (нет примеров, но думаю много кто так). И видимо можно заниматься майнингом. Типа, потом всем все рассказать (примеров тоже нет, но теоретически ситуация возможна).

Вот и интересно было, может ли подобная ситуация являться темой для репрессий? Может репрессии менеджера, что это допустил? Может милование? Может что то волшебное? и тд

По ссылке. Так вопрос уже закрыт же. Мы все поняли, что тема слишком искусственная и отменился вопрос.
источник

I

Ivan in Работа для ИТ-архитекторов
Поддержу.

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

F

Fagor in Работа для ИТ-архитекторов
Что делать что делать.

Вы поставили человека из ваакума не в свое место в вааукуме, брать его и ставить на то место где он подходит. Это если глобально.

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

Остальное нюансы, которые знают только участники того самого ваакума где этот кейс и архитектор в ваакуме.
источник

GC

George Cronk in Работа для ИТ-архитекторов
Ну вот и разобрались 😊 - такое просто невозможно (https://t.me/itarchitect_jobs/19475).
Согласен, и в целом доволен всеми вашими ответами. Было позновательно. Всем спасибо.

Как говорил один из моих преподов по физике "Все может быть, не может быть лишь того, чего вообще не может быть".
источник

RP

Roman Piontik in Работа для ИТ-архитекторов
Мои - оценка соответствия продукта ожиданиям. Затем, выявление причастных. Только потом оценка арха.
источник

GC

George Cronk in Работа для ИТ-архитекторов
Чувствуется тренинг по кризисменеджменту ) Поэтому я и задал вопрос именно вам вначале. Интересно было ваше мнение, так как ваша спроектированная платформа достаточно крупный проект и интересна. Жаль что лично я не по этой теме.

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

но уже в принципе мое личное понимание моего же вопроса немного изменилось. Я понял его абсурдность. Поэтому и Бог с ним, с вопросом.
источник

I

Ivan in Работа для ИТ-архитекторов
> Причины по мнению этого самого обсуждаемого виртуального персонажа, по его мнению, резонные: "Надо все обдумать", с чем не поспоришь.

Существует два способа обработки неопределенности: Prediction & Adaptation.

Последний существует именно потому, что точность первого лимитирована экономическими причинами.

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

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

RP

Roman Piontik in Работа для ИТ-архитекторов
Не совсем тренинги причина. Хотя, не скрою, они многое дали.

Но мое мнение, что арх это функция команды. Команды. Это даже не человек и даже не роль, а функция. И эта функция может быть делегирована персоне. Тогда это арх.

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

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

С другой стороны, убрав архитектора архитектура не исчезнет. Эта функция перераспределится. И вопрос встает о качестве функции. А этот показатель гораздо сложнее...

P.S. Все в этом мире может быть, и лишь того не может быть, чего быть может быть не может, но даже это может быть;)
источник