Size: a a a

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

2019 August 22

ИЦ

Илья Цуцков in Архитектура ИТ-решений
dreamore
выражу свое скромное мнение, что описываемая ситуация (постановка в ворде в виде описания таблиц от аналитика) - это исторически сложившийся артефакт и причины этого плачевны, и это вполне понятно. говоря сленгом программиста - абстракция "протекла". раз аналитик пишет требования к бд, то аналитик должен иметь фундамент знаний в области проектирования бд. развивать эту "протечку" можно и дальше, но не к месту. кажется, что нужно развернуть эту зависимость и доверить проектирование бд тем, кто в этом специализируется, и кажется, это не аналитик.
В природе существует широкий спектр аналитиков, от бизнесовых до системных🙃 иногда обе роли совмещаются в одном человеке, иногда разделены.
Но в целом логическую модель проектирует именно роль системного аналитика.
По моему опыту, логические модели у них как раз выходят получше, чем у разработчиков.
источник

ИЦ

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

RM

Roman Molchanov in Архитектура ИТ-решений
Прощу прощения, а есть кто общается с такими людьми как ит бизнес партнёры?
Или вы сами он?
источник

ИЦ

Илья Цуцков in Архитектура ИТ-решений
Тут везде по-разному будет) в моем случае это product owner + бизнес аналитик
источник

RM

Roman Molchanov in Архитектура ИТ-решений
Ну я хочу заметить что это достаточно разные функции
источник

ИЦ

Илья Цуцков in Архитектура ИТ-решений
Ну в данные они не лезут, конечно. Есть аналитики данных и системные аналитики для этого
источник

SB

Sergei Beilin in Архитектура ИТ-решений
Вот именно, зачем же до деталей реализации спускаться?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Andrey Kharintsev
Необходимо решение, чтобы документировать изменения структуры (модели) базы данных. Обычно от аналитика приходит огромный документ Word с таблицей внутри, когда его спрашиваешь что изменилось в документе, описывающем БД - он говорит не знаю, вот моя постановка читай ищи. Расскажите свой опыт.
Лучше всего уволить аналитика, как не владеющего минимальной компьютерной грамотностью (он даже не умеет пользоваться вордом, не говоря уж о Confluence/Git). А со следующим искать не инструменты, а выстраивать процесс взаимодействия аналитики и разработки, не предполагающего обмен вордовскими документами. Если процесс не выстраивается - то увольнять начальников до получения результата.
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Phil Delgyado
Лучше всего уволить аналитика, как не владеющего минимальной компьютерной грамотностью (он даже не умеет пользоваться вордом, не говоря уж о Confluence/Git). А со следующим искать не инструменты, а выстраивать процесс взаимодействия аналитики и разработки, не предполагающего обмен вордовскими документами. Если процесс не выстраивается - то увольнять начальников до получения результата.
👍👍👍
источник

A

Andreλ in Архитектура ИТ-решений
Sergei Beilin
А зачем описывать сущность в виде таблицы, если потом это может быть совсем не таблица, или не одна таблица?
Например затем, что сущность остаётся сущностью, со своим набором полей, вне зависимости от того, куда её сохранили. Хоть в постгрес, хоть в xml.
источник

AS

Alexander Smith in Архитектура ИТ-решений
Phil Delgyado
Лучше всего уволить аналитика, как не владеющего минимальной компьютерной грамотностью (он даже не умеет пользоваться вордом, не говоря уж о Confluence/Git). А со следующим искать не инструменты, а выстраивать процесс взаимодействия аналитики и разработки, не предполагающего обмен вордовскими документами. Если процесс не выстраивается - то увольнять начальников до получения результата.
Расстрелять политбюро и покрасить казанский вокзал в синий цвет - уже проходили
источник

PO

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

VA

Viktor Alexandrov in Архитектура ИТ-решений
Paul Olesh
Аналитиков, в последнее время, надо ещё русскому языку учить. К сожалению, это касается и отдельных разработчиков.
Тру
источник

E

Eugene in Архитектура ИТ-решений
В каждом профильном чате считают, что остальные хорошие ребята, но не дотягивают немного :))))
источник

SB

Sergei Beilin in Архитектура ИТ-решений
Andreλ
Например затем, что сущность остаётся сущностью, со своим набором полей, вне зависимости от того, куда её сохранили. Хоть в постгрес, хоть в xml.
Да, но начали-то за техническое описание. А сущность сущности не в полях все равно, а в их смысле.

А это уже можно правками описывать, т.е. писать русским по белому - "с 10.09.2019 поле VAT_RATE содержит ставку НДС в процентах с фиксированной точностью (ранее: содержало ставку НДС в долях с плавающей запятой)" (пример в общем-то из жизни)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Это про описание сущности от аналитиков? Или уже про модель в БД?
источник

SB

Sergei Beilin in Архитектура ИТ-решений
Phil Delgyado
Это про описание сущности от аналитиков? Или уже про модель в БД?
Вот собственно про что и начали - что это надо разделять.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А, ну да. Вообще для меня основным пожеланием к аналитикам было даже не определение самих требований, а выяснение 'а зачем это надо', иначе фигня все равно выходит.
источник

SB

Sergei Beilin in Архитектура ИТ-решений
(лирическое отступление: счастье - это в сравнительно небольших компаниях есть прямой доступ к стейкхолдерам, и никаких "испорченных телефонов")
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Это в основном про процессы, а не размер. Я видел испорченные телефоны и в компаниях на 20 человек и нормальные коммуникации в компаниях на 300. Вот в компаниях на 2000 уже не видел, но у меня в таких очень мало опыта )
источник