Комментарии 17
Очень интересно и наглядно показано, как системный анализ помогает оптимизировать работу команды и сэкономить ресурсы компании. Примеры и инструменты действительно полезны!
Прошу прощения, но был бы уместен "конкретный кейс" который показал бы что именно было плохо (кроме отсутствия аналитика) и как это удалось улучшить (кроме привлечения аналитика). А так текст выглядит будто его написал бессистемный аналитик который хотел стать системным но из инструментов имел только тазик с водой. Для того чтобы научиться пользоваться джирой аналитик не обязателен. И что кроме аналитика никто задачи сформулировать не мог - это звучит как диагноз :)
Нахожу Ваше замечание по поводу "конкретного кейса" вполне обосновано, но все же как то уж много критики, статья вроде более менее понятна.
Ведь если задуматься то скорее всего из "разработчики, тестировщики, скрам-мастер" действительно врядли кто то сможет написать внятные требования заказчика и требования к системе.
Я сам немного в другой области работаю, но так понимаю что системный аналитик плотно общается с заказчиками и составляет хорошо проработанные юз кейсы, и на базе этого формулирует понятные и структурированные требования звказчика (не системные и не софтверные).
Однако в данной схеме мне кажется отсутсвует как минимум архитектор (объеденим системного и софтверного в одну роль и наделим его властью писать реквайрементсы).
Ну и скрам мастер тут конечно лишний %)
Я бы ещё добавил, что роль "Аналитик" в команде должна быть, но совершенно не обязательно, что это будет отдельный человек :-)
Вообще странно выглядит команда, где выделили скрам-мастера, но не упомянули ПМ или тимлида, которые действительно must have в команде. В небольшом проекте они же могут выполнять роль аналитика...
Про архитектора валидно, но я писал только о внутрикомандном взаимодействии, а тенденция на найм и внедрение скрамов растет, на нашем рынке)
К сожалению(или счастью) диагноз уместен. Разработчики пишут код, ПМы и бизнес заказчики строят карту проекта и приоритеты, тестировщики тестируют. В условиях когда бизнес хочет быстро, качественно и не зависимо от конкретного человека в команде - аналитик думает за всех. Целью статьи было донести до общества что делает аналитик для того чтобы команде было комфортно работать с продуктом, который состоит из множества элементов, и так как сообщество Хабра не только жесткие технари пересобирабщие линукс ядро на встрече, был выбран такой язык и подход к написанию
Конкретных кейсов достаточно, ведь многие разработчики игнорируют и половину того что описано в статье)
Разработчики начинают работу, но у них возникает куча вопросов → Они идут с вопросами к тестировщикам, те обращаются к бизнесу
Извините, а что это за сумасшедший дом? Тестировщики общающиеся с бизнесом и разъясняющие задачи программистам?
Нельзя по хотелкам бизнеса начинать программировать, без предварительного проектирования, это будут бесконечные переделки даже у программ уровня "hello world"! А тут целый коллектив разработчиков, причём судя по уровню оплаты не бог весть какой квалификации.
К сожалению есть и такие кейсы на рынке) Не могу назвать компанию т.к дискредитация не очень хорошая практика, но это реальный кейс когда нарушается коммуникация в команде. Во многом сказывается наш рынок
Понятно что бывает по-разному, но по-моему в такой ситуации речь идёт не о том что не хватает аналитика на проекте, а вообще об отсутствии организации процессов, когда все заняты не своим делом. Тут просто чудесный рыцарь-аналитик в сверкающих доспехах не спасёт, он ещё и должен роли перераспределить, и много чего.
Статья из разряда - как с помощью воды потушить пожар.
Вот команда, она горит. В команде никто не пользуется водой, команда выгорает. Приходится нанимать новых, сроки не выдержаны.
Второй кейс - вот команда, они пьют воду и работают(+50 руб./бутылка). Издержки сокращены и команда не выгорела. Нанимаем в штат водовоза.
В ваших кейсах проблема в отсутствии профессионализма в организации работы команды и отсутствии подобия мыслительного процесса у самих участников команды, а не потому что у них в команде нет СА.
Почему разработчики начинают работу когда им сказали "Сделай приложение"? В такой ситуации любой вменяемый человек, который хоть немного думает (и даже какой-нибудь chatgpt), не говоря уже о профессиональном разработчике, начнет задавать вопросы ЗАКАЗЧИКУ или его представителям, чтобы хотя бы выявить требования. Я понимаю что это реальный кейс, когда они ходили к тестировщикам, но это какой-то нерелевантный мрак.
Тестировщик (он же QA - специалист по контролю качества разработки) должен тестировать работу разработчика, а не общаться с заказчиком и формулировать требования. Но опять же, даже если в такой команде тестировщик занимается требованиями, он, будучи, вменяемым человеком, как минимум должен их куда-то записать, чтобы потом передать разработчику (doc-first, так сказать).
И мои любимые скрам-мастера. Вся фасилитация команды лежит на них. Организация процесса взаимодействия лежит на них. Тем более, если его продали вместе с командой заказчику. И если вот эта схема "разработчик к тестировщику, а тестировщик к заказчику" его рук дело, тогда в неразработанном в срок приложении и увеличении бюджета виноват он. Ну и сам заказчик. У него, видимо, неограниченные бюджеты и довольно низкий уровень зрелости.
Если добавить в такую команду СА соответствующего уровня (непрофессионал с отсутствием способности думать), то он раздует бюджет, будет писать косноязычные требования с непонятными схемами, постоянно их менять и, по традиции этой команды, передавать их скрам-мастеру через директора, чтобы тот передал их тестировщикам, чтобы разработчики чувствовали себя комфортно.
Системный анализ - это не doc-first, это не miro-jira, не управление задачами, не назначение разработчиков и не поддержка команды от выгорания (what?). Это все административная работа, которую вы почему-то поручили СА.
Системный анализ - это мыслительный процесс анализа и синтеза систем, определение состава компонентов, их связей, границ, результата работы и прочего. Системный анализ - навык не только системного аналитика - им должен обладать любой участник команды, занимающийся разработкой ПО.
Иногда, в сложных системах подобной работы с системами необходимо довольно много, поэтому нанимают системного аналитика. Но в подавляющем большинстве случаев отдельный сотрудник для этого не нужен, достаточно профессионального разработчика/ПМ, который сможет задать вопросы заказчику.
Наличие системного аналитика в команде - не панацея от проблем и не всегда экономия ресурсов.
Тема с издержками ресурсов до появления СА и после не раскрыта совсем. На проектах/заказах любого ли масштаба расходы на СА (или нескольких СА) оправданы? Всегда ли наличие СА сокращает сроки и бюджеты? Может ли быть такое, что СА, выполняя свою работу, накопает нечто, что существенно увеличит стоимость проекта/заказа, а без СА такого бы не произошло?
Решения по ресурсам принимает не СА, соответственно не ему их экономить. Я как СА могу спроектировать систему, а человек с ресурсами на разработку не найдет их для моей системы. Поэтому в будущем придется потратить в два раза больше ресурсов. Системный анализ произошел, а экономии ресурсов нет.
Подытожу: системный анализ - must-have для любого человека.
Чем больше людей с таким навыком будут иметь отношение к разработке ПО, тем быстрее и за меньшие деньги это ПО будут разрабатывать (но это не точно).
ps: Я сам СА. После прочтения вашей статьи, у меня такое чувство, что либо вы, либо у вас в компании не понимают что такое системный анализ и чем должен заниматься СА, либо в профессии произошел какой-то раскол. И снова придется объяснять команде, что я проектирую системы, а не занимаюсь поддержкой от выгорания...
Системный аналитик, к тому же, берёт на себя функции, о которых обычно забывают:
фильтрует поток сознания заказчика, задавая неудобные вопросы (как это будет выглядеть? из чего это считается? откуда будут данные и в каком формате? как нам это принять, разобрать и разложить? кто за что будет отвечать и где исходная документация очередной интегрируемой системы, Билли?)
придумывает невероятные ситуации и определяет места отказа нового функционала (слабые точки, в которые можно ткнуть хитроизогнутой палкой и всё сломать);
ограждает разработчиков от словесного поноса бизнеса (находит в море созвонов, переписок и намаханых руками абстракций суть, переводя в итоге с "бизнесового" на "программистский", формализируя требования бабуинов от маркетинга в читабельное человеками разумными ТЗ);
рассказывает бизнесу о том, что честно-честно были серьезные технические ограничения сделать именно так, как сделано (упоминая мимоходом, что у розового цвета на салатовом фоне есть тенденция уменьшать производительность труда на 37,6%);
держит в голове взаимосвязь всех прошлых, имеющихся и будущих компонентов своей системы и всяких смежных с ней, но рассказывает об этом только когда явно спросят (либо когда хотелка бизнеса ну совсем уже врастопырку вставляется во всё и так еле-еле пыхтящее).
Иначе говоря, системный аналитик - это человек-модем (матюгатор-дематюгатор), который может замкнуть на себя бизнес, разработчиков и тестировщиков, оградив первых от вторых и третьих (TODO: вписать здесь красивый пассаж о флуктуациях уровней "технического интеллекта"), но позволив им при этом коммуницировать.
СА умеет думать "как бизнес", "как разработчик" и "как тестировщик" одновременно. И доносить одну и ту же мысль, зная свою систему с фронта, бэка и вокруг, по разному в каждую из этих сторон, почти всегда имея ответ на любой спонтанный ВТФ-вопрос, откуда бы тот не прозвучал. А если нет ответа - пойдёт и задолбает тех, у кого он должен быть. Он знает людей, которые знают людей..
То что вы перечисляете - это не функции СА, которые он почему-то берет на себя - я не могу эти функции перечислить, например, в своем резюме.
У вас это набор ситуаций, с которыми СА столкнулся в своей работе.
"Фильтрация потока сознания заказчика" - это сбор и составление требований к системе. Это одна из базовых обязанностей СА, почему о ней забывают?
"Поиск невероятных ситуаций и мест отказов" - это вменямое моделирование процессов, которые будет обслуживать проектируемая система. Это также базовая обязанность СА, о ней нельзя забыть. Если забудешь, тебе напомнит QA, когда найдет будет составлять тест-кейсы.
"Ограждать от словесного поноса" - это не обязанность СА (представляю такую строчку в своем резюме), это обязанность ПМ выстроить коммуникации с клиентом правильным образом и не допускать подобных ситуаций. Т.е. не очень понятно, в чем провинился СА и почему выслушивание словесного потока должно быть его обязанностью.
"Рассказывать клиенту о честно-честно о принятых решениях" - так это тоже базовая обязанность, о ней нельзя забыть. СА должен спроектировать несколько вариантов решений, у них может быть разный состав, характеристики и трудоемкость, цена и пр.
"Держит в голове взаимосвязь всех прошлых решений" - это да, это нужно. Но лучше не в голове, лучше документацию писать:) И это тоже базовая обязанность СА, о которой просто нельзя забыть.
Думать "как бизнес" должна уметь вся команда. QA тестирует "как бизнес", разработчик переносит бизнес-объекты и процессы в код. Нет такого, что разработчики или QA говорят на своем "разработческом" или "куашном" и не понимают человеческий/бизнесовый язык. Они же тоже люди в конце концов.
Если на СА замыкается коммуникация всей команды, это не нормально, это никакого отношения к системному анализу не имеет. Я не видел ни одной книги, ни одного стандарта где было бы написано, что системный аналитик (или где сотрудник с навыком системного анализа) - это центр команды. Почему в центре не тимлид разработки или фронтэндер Петя? И главное почему это не ПМ, в чьи прямые обязанности менеджера входит управление проектом, для чего было бы неплохо свести коммуникации на себя, чтобы контролировать ход проекта?
Ну ладно вам, друзья, не обижайте человека.
Он работает в казахском государственном телеком-операторе. А в таких компаниях бизнес-заказчик - это не равный тебе горизонтальный функционер, а живущий на небесах господин, которому перечить нельзя и вопросы задавать нельзя. А сам он слишком покрыт золотом, чтобы объяснять всякой черни детали своих гениальных хотелок.
Тут не аналитик нужен, а смена управленческой парадигмы. Но Алтел уже десять лет пытается свой кривой менеджмент поправить, да всё никак не выходит.
Спасибо,Виктор,за статью.Вме четко ,понятно и по существу.Я сам педагог+ методист и я в очередной раз понял ,что правильно поданное знание всегда выходит за рамки какой определенной сферы и всегда "учит" всех .
Как системный анализ помогает экономить ресурсы: кейс из реальной разработки