Комментарии 26
Спасибо за статью и за вашу точку зрения.
Нет ли у вас ощущения, что вопрос сугубо терминологический?
То что вы называется "моделированием", в других компаниях часто называют "проектированием".
В вакансиях под «проектированием интеграций» часто имеют в виду "нарисовать сиквенс-диаграмму и определить набор методов", а не что-то более глубокое. Это вполне может сделать аналитик.
Хорошо бы в начале статьи четко определить эти термины (в идеале со ссылкой на источники), чтобы все одинаково понимали о чем идёт речь.
по поводу интеграций дополню:
сейчас всё чаще от аналитиков, даже БА, хотят разработку спек на REST API
что это, как не низкоуровневый техдизайн?
правда с такой работой сейчас ChatGPT справляется лучше и быстрее среднего аналитика)
Это не дизайн. Это сбор в одной спеке всех требований. Без финальной обработки архитектором или хотя бы разработчиком, такая спека останется только черновиком.
да? а что тогда означает выражение «API Design»?
https://swagger.io/resources/articles/best-practices-in-api-design/
3D-макеты архитектора здания тоже могут согласовываться заказчиком и конструкторами, но это не значит, что 3D-макеты это не результат проектирования, а какие-то «спеки требований»
кроме того, напомню, что есть устойчивое выражение Design Specification, а specification есть по большому счету просто «детальный перечень чего-то», «детальное описание чего-то»
Я ничего против разработки АПИ не имею. Я говорю только, что ей не может заниматься сис.аналитик. Тем более б.аналиьик. Ей занимается архитектор или разраб.
Согласование и разработка - это разные процедуры, требующие разных навыков.
Design Specification - это specification, а не design. Если будете причислять к разрабатывающим всех сопричастных, то вам придется причислить и дворников, курьеров и поваров.
Я соглашусь, что на рынке бардак. Вон автор не понимает разницы между сис. и б. аналитиками. Много где аналитики принимают архитектурные решения. Ну так потом и имеем кошмар на проектах.
Спасибо за вопрос.
Я в начале дал определение, что я подразумеваю под “моделированием” и что под “проектированием”. В данном случае, я не опираюсь на канонические определения (даже не знаю, что можно считать каноническими), это скорее из серии “я художник, я так вижу”.
Вопрос не в терминологии, то что я называю моделированием, это про коммуникации, а проектирование - про реализацию. Если в некоторых компаниях, то что я называю моделированием называют проектированием, то как они называют то, что я называю проектированием? Выполняется ли та работа, которую я считаю проектированием? Если выполняется, как они разделяют ответственность между разными ролями?
Давайте разберем ваш пример - "нарисовать сиквенс-диаграмму и определить набор методов", “не что-то более глубокое”. Для чего это делает аналитик? Кому он адресует этот артефакт? Скорее всего, чтобы рассказать, что есть вот такие объекты, вот так они примерно общаются, примерно такой характер операций. Будет ли аналитик что-то предпринимать, если по факту реализации методов будет больше, изменится последовательность, характер вызовов?
Если вы сталкивались со строительством или ремонтом, то легко можете определить разницу между строительством по требованиям и строительством по проекту.
Очень актуальная тема
>> Под «проектированием» я подразумеваю технический дизайн — отображение верхне-уровневой модели и требований на конкретные технические решения: программные компоненты, интерфейсы, сервисы, схемы данных, типы. Проектирование носит обязывающий характер для реализации, это чертеж по которому будет выполняться разработка
Почему только технический дизайн? А концептуальный дизайн, логический, функциональный — их что, нет? они не нужны?
Ещё может быть путаница в предметах/уровнях проектирования — информационная система или ПО.
Если под проектированием понимать не только «техдизайн», а в целом принятие проектных (design) решений, то
На уровне информационной системы надо принять принять решения о:
автоматизируемых процессах
ролевой модели
перечне смежных систем и составе данных для обмена
сценариях использования и показателях качества в использовании
наборе бизнес-подсистем и потоках данных между ними
структурах используемых данных
жизненных циклах объектов учёта
атрибутах качества и ограничениях, включая прогнозы
алгоритмах обработки данных
структуре отчётов
структуре пользовательских интерфейсов
На уровне ПО надо принять решения о:
применяемых архитектурных стилях и паттернах (в частности подходах к обмену данными внутри и снаружи)
методах обеспечения атрибутов качества (например, механизмах обеспечения ИБ)
наборе программных модулей-сервисов, из которых состоят бизнес-подсистемы
применяемых технологиях и языках программирования для каждого из модулей
конкретных программных библиотеках, реализующих готовые алгоритмы и сервисы
TLDR
Почему системный аналитик не должен заниматься проектированием
аналитик не должен заниматься проектированием, так как это является обязанностью техлида со стороны разработки и/или архитектора (software, solution)
ну т.е. аргументация вида «потому лишь, потому, что не положено ему» :)
в общем аналитик ни у кого не занимал, поэтому никому ничего не должен)
вы в конкретной организации можете проводить границы ролей и должностей, как угодно, но для того, чтобы рекомендовать рынку проводить их по вашему, нужна более серьёзная аргументация
Полностью согласен с вашей точной зрения. Прочитал все ваши комментарии здесь, они гораздо полезнее самой статьи, где автор ищет лишь повод сократить спектр работ для своего отдела. Вероятно часть, а может быть и весь отдел (не берусь судить, лишь оценочно делаю вывод) не готова к проектированию Часто вижу в последнее время, что некоторые компании берут в аналитики кого попало, филологи после курсов аналитика, это еще не самые цветочки... поэтому и заявления, что не должны, ибо не умеют. Ну а ведь это беда.. Не умеют - пусть идут техническими писателями работать.. хотя... как вы упомянули чат ГПТ сейчас не плохо с этим справляется. В общем статья из разряда оправдания отсутствия должного уровня компетенций.
А вообще проектирование как это правильно делается в правильных компаниях должна выполнять команда, а не один аналитик. В команде должны быть и архитекторы и тимлиды и специалисты по данным. Понятное дело что в ряде проектов на полноценной команде чаще всего экономят. Это просто повлияет на нюансы того "чертежа" который вы описали в одном из комментариев. Которые могут дополниться при разработке, или так и будут не реализованы с различной степенью последствий (где то последствий даже и не будет). Хоть я считаю что и индексы и другие особенности работы БД сеньоры системные аналитики обязаны знать (это моё личное мнение, но кому надо смогу аргументировать его).
Как и сказал выше, в ваших словах увидел близкое мне, поэтому решил поддержать.
Поддерживаю претензию к слабой аргументации! Если провести аналогию с продуктовой разработкой (то есть дать крен в область проблем), то с тем же успехом можно заявить, что аналитики не должны заниматься, например, формированием продуктовых гипотез и выработкой метрик использования продукта, т.к. делают они это плохо да и вообще эта работа владельца/менеджера продукта.
чем должен заниматься аналитик — управлять требованиями
управлять — это вообще функция менеджера, то бишь проектного менеджера, продуктового менеджера или product owner/system owner :)
кроме того, сейчас всё чаще в разработке коммерческих систем общего назначения встречаются подходы, когда работа идёт в обход требований, кроме бизнесовых и атрибутов качества (которые как раз обычно аналитики умеют выявлять слабо) — см. Domain-Driven Design, Event Storming
Для начала, нужно было разобраться в профессиях, работать можно кем угодно, от названия должности ничего не зависит. Вопрос в компетенциях (трудовых функциях). Если вы соответствуйте квалификации, то это уже вопрос руководителя, как распределять ТФ между сотрудниками.
Есть ещё такие "штуки", как стандарты. В них можно ознакомиться с терминологией, относительно контекста, в котором вы работайте.
Бизнес-аналитик
Системный аналитик
Руководитель проектов в области информационных технологий
NB: я основной автор стандарта системного аналитика
стандарт СА устарел на 10 лет. в 2013-м году в среде экспертов был относительный консенсус, что основная задача СА — разработка требований (инженерия требований).
сегодня, в 2023-м году, есть понимание, что важнее обеспечивать качество проектирования системы, вне зависимости от того, кто именно принимает проектные решения
PS. и вы немного промахнулись с веткой
PS. и вы немного промахнулись с веткой
Не промахнулся! тк знал этот факт))) Надеялся, в случае чего, ссылочку на новый проект ст-та получить)
есть понимание, что важнее обеспечивать качество проектирования системы, вне зависимости от того, кто именно принимает проектные решения
Ну дак об этом весь ГОСТ Р 9001 и 57193(15288)... incose, по крайней мере, так 15288 "рекламирует". ТФ там правда всё ровно нет...
ПС: Есть ли информация, в открытом доступе, по новой версии?
вот проект с декабря висит, только его уже не я готовил, лишь минимально участвовал https://www.garant.ru/products/ipo/prime/doc/56840796/
Постоянно присутствует терминологическая путаница между понятием "системный анализ" ("Системный анализ — прикладное направление теории систем, применяемое при решении сложных слабоформализуемых проблем") и тем, что понимается под сферой деятельности "системного аналитика" в компаниях занимающихся разработкой ПО ("профессиональной роли и профессии, ответственной за анализ потребностей пользователей на предмет возможности их удовлетворения посредством функций соответствующей информационной системы").
FYI: "https://classinform.ru/profstandarty/06.022-sistemnyi-analitik.html", -- профстандарт на системного аналитика. Сравните с результатами запроса "системный анализ сборник статей".
Если аналитик много не может, а разработчик многого не хочет (пример с итальянской забастовкой), то может убрать аналитика из цепочки? Если ПО не очень сложна, то его роль будет распределена между
- PO в части управления ожиданиями и верхнеуровневыми требованиями.
-архитектором в части верхнеуровневого контроля архитектуры решения, качества и целостности.
-для всего остального есть лид/тех лид/разработчик.
Всегда есть потери на передачу информации Заказчик-Аналитик, Аналитик-Разработчик. Может мы зря добавили эту роль в принципе? Насколько я помню аналитики есть только на постсоветском пространстве. На западе есть эксперты, но не аналитики как у нас...
вы ошибаетесь
Так и есть. Не на всех проектах нужен аналитик, но на каждом проекте нужно делать анализ. Если проект небольшой, то роль аналитика размазывается по другим участникам команды. Если уровень неопределенности на входе слишком высок, то команда приходит к пониманию, что на входе надо поставить выделенного специалиста, который сможет фильтровать неструктурированный поток потребностей от стейкхолдеров. Тогда и нанимают аналитика.
Спасибо за статью!
Излишний уход в проектирование от моделирования требований ведет к смешению роли системного аналитика и архитектора. С какой целью это делается я не понятно.
Аргументы в стиле давайте уберем лишнее звено могут привести к тому, что сам клиент садиться и программирует. Никаких потерь на коммуникации не будет :)
Я сама работаю системным аналитиком и мне очень откликается ваша статья. На мой взгляд системный аналитик в первую очередь (не смейтесь) нужен для системного анализа, а не анализа системы. То есть, должен обладать достаточными знаниями, чтобы "подружить" ожидания людей и возможности продукта. Для этого нужно как уметь коммуницировать с людьми, так и разбираться в технологиях. Но главный поинт: "разбираться" и "принимать решения" — разные вещи. Я знаю, что такое реляционные БД и микросервисы, но не возьмусь их проектировать, потому что нет у меня достаточных для этого навыков. Это не значит, что системный аналитик не может проектировать архитектуру, может. Только это будет называться — системный аналитик взял на себя роль архитектора. А значит и отвечать за принятые решения он должен на уровне архитектора. Да, и ещё свои задачи аналитика он тоже должен успеть закрывать и закрывать их качественно. Сможет ли такой аналитик найти на всё время или же что-то пострадает?
Если говорить про компетенции, то я считаю, что моя первичная задача как аналитика - снимать неопределенность на входе до уровня, достаточного для команды, чтобы начать делать решение, и проверять, чтобы на выходе ожидания (стейкхолдеров) и реальность (готового решения) совпали.
Спасибо, что подняли эту тему
Почему системный аналитик не должен заниматься проектированием