Size: a a a

2021 July 08

Ю

Юрий in SPb CoA
Действительно, тема была сформирована хайпово, но по сути bad smell - это признак плохо выстроенных процессов, а не выпад в сторону СА. Если процессы были бы идеальны, то ни СА, ни тимлиды не были бы нужны. А наличие необходимости в СА говорит лишь о том, что приходится искать посредника, чтобы наладить коммуникации между бизнесом и разработчиками.
источник

Ю

Юрий in SPb CoA
Слушал урывками, но как понял, Филипп говорил о том, что для СА целесообразнее совершенствоваться в предметной области, чтобы лучше понимать потребности бизнеса. При этом он не должен лезть в техдизайн, не его это дело. Так будет эффективнее и дешевле для проекта в целом.
источник

IS

Ivan Starygin in SPb CoA
это тогда БА получается
источник

Ю

Юрий in SPb CoA
Ну да, а Solution Architect вырастает из разрабов
источник

KS

Konstantin Semenov in SPb CoA
Вот паззл и сложился!:)
источник

AA

Anna Abramova in SPb CoA
А я поняла, что мне даже особо не с чем поспорить. Всё очень толково и консистентно. А если слушать в состоянии "у меня подгорает", а не с желанием услышать точку зрения коллеги, то можно много странного услышать
источник

AA

Anna Abramova in SPb CoA
Мне вот интересно было, что я получила подтверждение своей гипотезе: СА втискивают в процесс, чтобы решать все проблемы, которые остальные роли не хотят решать. В результате системный аналитик исполняет куски многих ролей, а платят ему по какому-то странному прейскуранту, достаточно мало для такой ответственности. И это, конечно, выгодно для больших компаний - иметь таких разнорабочих по небольшой цене. Поэтому можно не улучшать процессы, а продолжать затыкать аналитиками дыры, пока они сами на это согласны. Почему согласны не знаю, может нравится чувствовать себя спасителями всех и вся.
источник

Ю

Юрий in SPb CoA
А я услышал ещё, что такие разнорабочие в лице системных аналитиков по факту не шарят в техдизайне, и разработчикам всё равно приходится после них проектировать самим. Например, структуры БД и т.п.
источник

Ю

Юрий in SPb CoA
YouTube
Кирилл Щемелинин. Системный аналитик vs Solution Architect. Как правильно определить  роль.
Системный аналитик, проблема самоидентификации, или почему правильное название системного аналитика – Solution Architect.

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

Ю

Юрий in SPb CoA
Вот ещё любопытный взгляд на этот холивар
источник

DF

Dmitriy Filippov in SPb CoA
тут или желание услышать точу зрения коллеги или желание получить подтверждение своей точки зрения (спойлер: второй вариант)
источник

DF

Dmitriy Filippov in SPb CoA
а о том что из информационного повода две противоположные стороны легко могут извлечь подтверждения своих, противоположных, точек зрения еще Талеб писал
источник

KS

Konstantin Semenov in SPb CoA
Зачастую не  "не хотят", а просто не могут.
Т.е. часто сильный СА это симптом слабой разработки, которая не может исполнять свои же обязанности
источник

DF

Dmitriy Filippov in SPb CoA
пространство для чужих точек зрения начинается примерно там, где заканчивается желание найти подтверждение своим убеждениям
источник

AA

Anna Abramova in SPb CoA
Да, это скорее личный опыт Фила, меня тоже зацепило, и ещё то, что аналитик в одиночку в уголке генерит решение, потом приходит и выдаёт в разработку, как готовое, а оно неоптимально. Вообще, у аналитика обычно достаточно хорошие коммуникационные навыки, чтобы согласовать решение со всеми, кто может добавить свою экспертизу. Но, опять же, зависит от того, как выстроен процесс. Я видела жёсткий канбан, в котором разработчики требовали, чтобы им выдавали уже готовое описание AP, а не отвлекали их до момента, когда нужно брать задачу в разработку. Если аналитик привык к такому процессу, его придётся переучивать на нормальные коммуникации
источник

AA

Anna Abramova in SPb CoA
Что значит "не могут"? Язык отвалился сказать что туту что-то не так, или ноги не ходят уйти из такой ситуации? У меня такой подход - если я смогла, то и другие могут. Могу устроить получасовую промывку мозгов для расширения угла обзора вариантов
источник

AA

Anna Abramova in SPb CoA
Это губительная точка зрения для аналитика. Мы всё-таки должны уметь работать с сырой информацией, отключая иногда эмоции и иногда даже свои ценности. Ненадолго. Надолго я сама не умею, но на два часа можно
источник

m

madDoctor in SPb CoA
Если кто-то что-то может, это не значит , что остальные тоже смогут. Люди разные, себя делать мерой вещей так себе политика
источник

AA

Anna Abramova in SPb CoA
Я предложила помощь, если вы заметили
источник

F

Fagor in SPb CoA
А аналитик (кроме аналитиков бд) вроде и не должен проектировать структуру бд...
источник