Size: a a a

Архитектура ИТ-решений

2020 January 09

МП

Михаил Поздняков in Архитектура ИТ-решений
Phil Delgyado
И всегда делают это ужасно, так как некомпетентны.
С заявлениями вида "все мужики козлы" спорить не готов. )
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну просто чтобы рисовать хорошие схемы данных - нужно быть в первую очередь разработчиком базы данных. А у аналитиков и другие задачи и другой опыт и другие компетенции.
А этот опыт еще и устаревает с неимоверной скоростью
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Наверно бывает разрабочтик баз данных, которого называют системным аналитиком - но это редкость и неверное именование.
источник

МП

Михаил Поздняков in Архитектура ИТ-решений
Phil Delgyado
Но так как разработчика все равно нужно погружать в бизнес (без этого он вообще ничего не сделает), то аналитик не нужен.
На каких-то проектах наверное не нужен. На каких-то нужен этап работы с требованиями и этап анализа. Как будет называться человек который это делает, лично мне не так важно. Щас вон многие аналитики переписались в продакты а делают то же самое.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, да, это и есть работа или БА или продукта. Без попыток описывать "как делать", а только "что делать" и "какую проблему решать".
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Т.е. написать текстом основные сущности предметной области с точки зрения клиента - это их работа.
Но не больше.
Кстати, генерализацию сущностей им тоже делать не стоит (не видел еще корреткной генерализации сущностей от СА, всегда что-то крайне неудобное для реализации)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Phil Delgyado
Т.е. написать текстом основные сущности предметной области с точки зрения клиента - это их работа.
Но не больше.
Кстати, генерализацию сущностей им тоже делать не стоит (не видел еще корреткной генерализации сущностей от СА, всегда что-то крайне неудобное для реализации)
Не только текстом. Потоки данных и процессы КАК ИХ ВИДИТ БИЗНЕС. Они почти всегда, неизбежно, будут уточнены либо разработчиками, либо аналитиками по обратной связи от разработчиков. Потому что бизнес НИКОГДА НЕ ВИДИТ ВСЕХ ДЕТАЛЕЙ.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, не ER-диаграммами.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Бизнес не видит деталей, бизнес плохо обобщает - так что все равно разработка все поменяет )
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Phil Delgyado
Ну, не ER-диаграммами.
Да, не ER-диаграммами и даже не UML
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Phil Delgyado
Бизнес не видит деталей, бизнес плохо обобщает - так что все равно разработка все поменяет )
Я это и хотел сказать)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну да, все правильно написал
источник

S

Serg in Архитектура ИТ-решений
Добрый вечер. А вы с ГОСТом 34.320/34.321 не сталкивались? Когда заказчик требует решения по работе с данными по этим нормативным документам описать :) Я думаю ни разработчик, ни "классический БА" не даст результата
источник

S

Serg in Архитектура ИТ-решений
Классический документ 96 года выпуска )
источник

МП

Михаил Поздняков in Архитектура ИТ-решений
Phil Delgyado
Ну, да, это и есть работа или БА или продукта. Без попыток описывать "как делать", а только "что делать" и "какую проблему решать".
В том то и дело что у БА и продакта свои зоны ответственности, БА это специалист по реорганизации бизнес-процессов он вообще может существовать отдельно от разработки систем, но часто включен в разработку так как она меняет бизнес-процесс. Продакт это вообще бетмен получается который и про маркетинг и про рынок и про валидацию гипотез и про анализ. С ростом сложности проекта он порвется просто, В итоге на сложном проете нужна роль которая преобразует поток инфы извне в непротиворечивую систему утверждений и опишет это в виде требований кейсов или еще как-то. У нас под эту роль выделена отдельная должность, называется системный аналитик. Где-то роль может и разработчик закрыть но тогда это тоже будет бетмен с несколькими ролями.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Serg
Добрый вечер. А вы с ГОСТом 34.320/34.321 не сталкивались? Когда заказчик требует решения по работе с данными по этим нормативным документам описать :) Я думаю ни разработчик, ни "классический БА" не даст результата
А это уже про совсем другие процессы, там нужные "нормативные писатели", как раз для подобных задач. Но это не СА и не БА.
Ну и работы по такому ГОСТУ - тоже bad smell )
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Serg
Добрый вечер. А вы с ГОСТом 34.320/34.321 не сталкивались? Когда заказчик требует решения по работе с данными по этим нормативным документам описать :) Я думаю ни разработчик, ни "классический БА" не даст результата
Госуха это отдельная тема. Там нужны не просто аналитики, а "аналитики с ГОСТами". Но и там по факту документы и решения живут своей жизнью.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Михаил Поздняков
В том то и дело что у БА и продакта свои зоны ответственности, БА это специалист по реорганизации бизнес-процессов он вообще может существовать отдельно от разработки систем, но часто включен в разработку так как она меняет бизнес-процесс. Продакт это вообще бетмен получается который и про маркетинг и про рынок и про валидацию гипотез и про анализ. С ростом сложности проекта он порвется просто, В итоге на сложном проете нужна роль которая преобразует поток инфы извне в непротиворечивую систему утверждений и опишет это в виде требований кейсов или еще как-то. У нас под эту роль выделена отдельная должность, называется системный аналитик. Где-то роль может и разработчик закрыть но тогда это тоже будет бетмен с несколькими ролями.
Под БА понимают две разные вещи - то, что ты описал и аналитик проблем бизнеса. Который не про реогранизацию, а про вытаскивание конкретных проблем из бизнеса и нахождение их решений. Вот решение этих проблем бизнеса (и на языке бизнеса) БА и должен нести в разработку, где их реализуют.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, у вас БА назвали СА, тоже норм. Главное - что бы он не описывал "как делать", не выходил за пределы user stories, описаний бизнес-процессов и т.п.
источник

МП

Михаил Поздняков in Архитектура ИТ-решений
Да я эт понимаю сам работал и тем и тем. Кстати в среде аналитиков есть такие же холивары на тему нужно ли разделять БА и СА. В итоге мне кажется все эти разделения просто обычная эвоюция. Были вон в девяностые отличные ребята под названием "программисты" они были в одном лице и проджект и аналитик и разраб и тестировщик и девопс. И еще обучали и поддерживали потом. А ща развелось беков, фронтов разных, одних аналитиков: БА, СА, еще и аналитики данных есть и про инеграционных я слышал. Бардак-с.
источник