Расходимся)
На самом интересном месте 
Можно еще подумать про системные уровни и какая роль на каком из них работает. Одна из проблем системных аналитиков в ит в том, что разные компании по разному понимают их задачи, а еще бывают случаи, когда написано одно, а делается совсем другое. В некоторых компаниях, например, я был просто техническим писателем и записывал те решения, которые приняла команда (я был в этой же команде, как разработчик по скраму, поэтому влиял на решения).
В другой компании были задачи интересней, ниже опишу примерно как был устроен процесс, на примере системы удаленного повара.
Концепция системы в том, чтобы человек, который хочет приготовить блюдо может удаленно поразговаривать с поваром, который выдаст ему комментарии и рекомендации по итогу которых человек сделает вкусную еду, утолит свой голод и произведет впечатление на гостей.
- Продакт формирует проблему клиента и примерно накидывает как ее можно решить и как еще можно использовать удаленного повара, чтобы он приносил больше денег. Он формирует концепцию использования удаленного повара, система “повар + наше ПО” (все документы тут и далее фактически называются требованиями).
. - Продакт идет к системному аналитику и дизайнеру и они продумывают концепцию системы “повар + наше ПО” - сценарии, как клиент будет взаимодействовать с поваром, а как повар с клиентом.
.
3.1 Далее все трое придумывают концепцию использования системы “наше по”, как повар будет с ней взаимодействовать, через какой UI и тут же описываются макеты и функции системы (это уже начинается концепция системы “наше по”).
.
3.2 Системный аналитик работает один над технической частью концепции системы “наше по” (бэкенд) и понимает, как UI ляжет на части системы. Какие новые функции лягут на какую часть системы, а может нужно добавить еще одну часть системы или изменить существующие. Он тут проектирует микросервисы, их функции, их способы взаимодействия и контракты между ними, базу данных. Тут видно, что углубляясь в концепцию системы “наше по” мы затрагивает концепцию использования системы “микросервис”.
.
3.2_комментарии. В процессе системный аналитик согласует свой проект с архитектором - распределение функций по сервисам, с разработчиками - контракты, базу данных. 80% решений, которые придумал аналитик идут в работу так, как он их придумал, а 20% меняются. Тут мы можем отметить, что формально аналитик не принимает решения, но фактически проектирует и придумывает большую часть он.
. - Тут начинается работа разработчика, мы ему передаем концепцию использования и концепцию системы “повар + наше по”, тоже самое для системы “наше по”, а так же передаем концепцию использования системы “микросервис”, НО не передаем ему концепцию системы “микросервис”. Разработчик как раз тут и проектирует эту концепцию системы “микросервис”, которая состоит из концепций использования системы “модуль микросервиса” и концепции системы “модуль микросервиса” (всякие классы, объекты, функции внутри). Тут же он пишет код или другой разработчик его пишет по придуманным концепциям микросервисов (старший может описать какие классы создать, а младший это все кодит).
.
4_интересный факт, кто концепцию системы “микросервис” придумывает разработчик, а концепцию системы “база данных” (какие таблички и какие столбцы) придумывает системный аналитик.
. - После 4 шага аналитик не включается в процесс, а дальше все идет до тестирования и девопсов в эксплуатацию. Аналитик может что-то уточнить по ходу и скорректировать свой проект, но обычно больше 10% проекта не меняется по обратной связи от разработчиков и тестировщиков.
.
p.s. еще в 3 пункте аналитик пишет, что нужно сделать со старыми данными, что нужно сделать при обновлении системы, какие события нужно добавить в систему для дальнейшей работы дата аналитиков, выявляет архитектурные характеристики.
Надеюсь, что информация поможет вскрыть аналитиков успешнее))
3 лайка
Спасибо за подробный комментарий!
Написал свою рефлексию на тему отдельно
1 лайк
Лично я разрабатывал и разрабатываю системы с нуля (от общения с заказчиком) до техподдержки и продажи. То есть весь процесс понимаю.
Дак вот всегда, перед тем, как начать что то пилить в коде, работаю как “аналитик” - пишу ТЗ, ве эти user story, требования и прочее. Да - в минимально необходимом объеме, но это все равно не так кж и мало. И не по тому, что сам с собой договрится не могу - а потому, что это этап проектирования и уточнения задачи. То самое “мышление письмом”. Прописывая втыкаешься на непонятки, недодумки.
И потом, когда пишу код и его тестирую - всегда можно понять, почему надо именно так.
И паралельно - формирую и у себя и у заказчика правильные ожидания. ЧТо бы когда я все сделаю - заказчик сказал “вау! А что, так мождно было? Это же имено то, что мне нужно” и с удовольствием мне заплатил.
Да, как показывает практика, с этим всем может справится и разработчик. НО! Письмо кода требует времени. ОТлавиливание заказчика и задавание ему вопосов - требует времени. И написание текстов ТЗ то же требует времени. В общем, квалифицированный ипонимающия СА (не важно, как называют эту роль) может:
- съекономить время всей команде в части понимания и документирования того, что нужно сделать. И документирования принятых изменений
- являет иную точку зрения, помогая быстрее найти проблеммные места и несоотвествия.
НО!! Если аналитик грамотный. А если он с таких вот курсов (как в началном посте), из серии “войти в айти, там деньгов платят” - то польза может бтыть карайне сомнительной, если не вредом.
То есть суть не в аналитике как таковом. Роль, как мне кажется, нужна неизбежно, а в квалификации ианалитиков, и организаторов работы команд.
Сэкономить аналитик ничего не может. Но я про это уже писала. Требования и понятие ТЗ устарели. Но это в материале Системной инженерии, третий семестр аж.
Звучит зловеще
Да, звучит “категорично”… или непривычно. Как требовать по “требованию”)
Наверное разница в восприятии, как кто понимает/трактует термины Требования и ТЗ.
В “больших” водопадных проектах несомненно, а в аджайло-скрамовских циклах разве нет потребностей, их описаний (железных vs программных, хотя сейчас уже железные без программных еще поискать надо).
Да, степень категоричности требований наверное явно не помешает согласовывать с заказчиком, “подстелить соломки” … если что не по плану.
Кто “сшивает” концепцию использования и концепцию системы?
Всегда одни и те же роли?
Набор ролей или количество участвующих людей в создании насколько влияет?
Сама операция(интеграция, соединения, сплочение) же никуда не делась .
Либо ее делает аналитик, который обязательно должен разбираться в домене/прикладной области + иметь представление о деятельности смежников.
Либо ее делают сами смежники (роли согласующие концепцию использования, архитекторами, проектировщики, разработчики создаваемой системы) без “бесполезных” аналитиков.
Может роль выполняющая кусок аналитической деятельности зависит от размеров прикладной области, в которой происходит создание системы, самого размера системы или объема требуемых компетенций.
Хотя скорее благодаря культуре использования “требований” на практике и привычности в быту это понятие будет жить ЭНное/немалое количество лет. Пока большинство людей на планете не пройдут в ШСМ системную инженерию и проверят/удачно применят большинство гипотез-деклараций на практике.
Пользуясь тем же разделом применительно к текущей дискуссии “оптимальных решений нет, поэтому всегда выбираем не лучший вариант, а наименее плохой”.
Мы же не спорим о терминах?