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