Русский
Русский
English
Статистика
Реклама

Системная аналитика

Анонс. Профессия системный аналитик развитие сообществ, популяризация профессии и подготовка

08.11.2020 14:17:04 | Автор: admin


В ПОНЕДЕЛЬНИК, 9 ноября, в 20:00 в наших соцсетях выступит Алексей Лобзов главный системный аналитик Альфа-Банка, техлид аналитиков корпоративного направления. Алексей занимается подбором, онбордингом и развитием системных аналитиков. Так же, он известен на Хабре как alobzov, регулярно выступает с докладами, обучает системных аналитиков онлайн.



О чем расскажет Алексей, кроме ответов на вопросы



  • Развитие сообщества.
  • Популяризация профессии.
  • Подготовка аналитиков.
  • Есть ли сообщества у системных аналитиков.
  • Как обменяться опытом на стороне.
  • Об организации собственного сообщества.
  • Зачем я пишу и рассказываю о системных аналитиках.
  • Как на два разработчика стало меньше.
  • Откуда приходят в аналитику и куда уходят.
  • Возможно ли вырастить системного аналитика с нуля.
  • О школе системного анализа Альфа-Банка.
  • Об онлайн-обучении.


Кроме того вы можете задать вопрос о системной аналитике здесь в комментариях или в инстаграме и он ответит на них в прямом эфире.



Как не пропустить эфир?


Выбирайте платформу, которая вам нравится и нажмите кнопку Напомнить. Так как ютуб самая популярная платформа среди наших эфиров, вставляем трансляцию.


До встречи в эфире!

Подробнее..

Профессия системный аналитик развитие сообществ, популяризация профессии и подготовка

14.11.2020 12:04:35 | Автор: admin

Недавно на нашем ютуб-канале выступил Алексей Лобзов главный системный аналитик Альфа-Банка, техлид аналитиков корпоративного направления. Алексей занимается подбором, онбордингом и развитием системных аналитиков. Так же, он известен на Хабре как alobzov, регулярно выступает с докладами, обучает системных аналитиков онлайн.

Делимся записью эфира и расшифровкой.




Меня зовут Алексей Лобзов, я являюсь главным системным аналитиком в компании Альфа-Банк. Я одновременно выполняю роль технического лидера аналитиков корпоративного направления нашего банка.

Я хочу рассказать о профессии системного аналитика и рассмотреть три вопроса: сообщество аналитиков, популяризацию профессии и подготовку аналитиков, в первую очередь без опыта работы, то есть, аналитиков начального уровня.

Есть ли какое-то официальное определение системного аналитика и его области ответственности?


Это роль на проекте, в продукте или компании, или профессия/должность?
Системный аналитик это профессия. На сайте Минтруда есть раздел Справочник профессий, где можно найти профессию системного аналитика и прочитать, в чем состоит ее описание. Также с этой страницы можно перейти на профессиональный стандарт и узнать, какие функции ожидаются от человека этой профессии.

Хотя, на практике могут быть отклонения. Так или иначе, если вы устраиваетесь на работу на должность системного аналитика, то у вас будет должностная инструкция с обязанностями, которые работодатель ожидает от вас. Отклонения от стандарта, скорее всего, не будут существенными.

Встречались ли на практике разные понимания этой профессии у разных людей, были ли конфликты на этой почве?


Разные понимания этой профессии встречаются повсеместно, и в различных компаниях к аналитику могут предъявляться разные требования. Один из факторов здесь размер компании. Небольшая компания может быть не готова к тому, чтобы нанять в штат одновременно системного аналитика, бизнес-аналитика, тестировщика и техписателя. Ряд функциональных обязанностей других специалистов может отразиться на системном аналитике.

Если вы общались с людьми, которые имели опыт работы в компании, где системный аналитик занимался проработкой бизнес-процессов, работой с бизнес-требованиями и составлением ТЗ, но не занимался проектированием архитектуры будущей системы и разработкой технических спецификаций на отдельные модули, то может возникнуть непонимание.

На практике встречались кейсы, когда к нам приходил владелец продукта и просил проработать требования по определенным фичам например, списание за услугу плюс уведомление клиента о списании и в постановке содержались требования вплоть до того, какой должен быть текст уведомления. Такие примеры задач мы относим к задачам бизнеса, и в системный анализ мы их не берем. Мы ожидаем, что владельцы продуктов дадут нам бизнес-требования покажут, что нужно сделать и мы, как системные аналитики и члены команды разработки, совместно с остальными членами команды подумаем, как эти требования лучше реализовать.

Если говорить о конфликтах до настоящих конфликтов, когда все бы переругались и эскалировали ситуацию до уровня руководителей, на моей практике не доходило. Непонимания решались в разговоре. Я допускаю, что в каких-то компаниях непонимание может принимать более ожесточенный вид.

Я хочу рассказать о сообществах системных аналитиков существуют ли они вообще, и что из себя представляют. Конечно, ответ они существуют слишком простой я расскажу, как я сам с ними познакомился.

Это произошло относительно недавно; это было тогда, когда я пришел в Альфа-Банк, в начале 2017 года. Тогда моя команда (и еще 4 таких же команды) занималась созданием интернет-банка для юридических лиц и ИП. Каждая команда развивала свой программный продукт, и интернет-банк в целевой картине должен был состоять из этих продуктов. Мы пришли к пониманию того, что все эти продукты невозможно развивать независимо, каждый по-своему.

Например, с интерфейсом пользователь сталкивается в первую очередь, и у одного продукта цвет UI может быть условно песочный, а у другого серый, а у третьего еще какой-то; такого нельзя было допускать. Мы пришли к пониманию того, что разрабатывать наши пять продуктов нужно скоординированно. Команды изначально работали по методике, близкой к SCRUM, но с особенностями, которые накладывает банковская специфика. Так или иначе, мы масштабировали SCRUM на пять команд, поработали в таком режиме и выпустили интернет-банк, открыли его на пользователей. Появился любопытный опыт, который я до этого нигде не встречал в том числе, и в текстах. Поэтому у меня появилась идея поделиться этим опытом.

Я хотел поделиться конкретно с сообществом аналитиков, и передо мной встала задача: найти такое сообщество. Я поспрашивал у коллег из Альфы; мне сказали, что есть популярная конференция аналитиков Analyst Days. Она проходит каждый год, и можно пойти туда и выступить, или хотя бы поучаствовать, узнать какие-то интересности, которые можно будет потом применить в работе.

Я начал анализировать возможность посещения этой конференции и как спикер, и как обычный участник; в итоге я пришел к выводу, что эта конференция мне не подходит. Этому было две причины: во-первых, в моем понимании, на конференцию приходят серьезные люди с серьезными темами, и участники платят за то, чтобы послушать их и задать вопросы. Во-вторых, я просто не был готов платить за билет участника; у меня был пример Московское сообщество разработчиков на Python (Moscow Python Meetup), которое ежемесячно проводит митапы со свободным входом. Там можно бесплатно прийти, послушать спикера, задать вопрос, пообщаться с питонистами, съесть пиццу в пицца-паузе; если у тебя есть тема, то ты можешь самостоятельно записаться, заявить тему перед оргкомитетом, и, если тема подходящая, тебя с высокой вероятностью включат в план выступлений. Поэтому я стал искать что-то похожее на MPP, но для сообщества аналитиков.

Поиск выдал мне информацию о сообществе аналитиков с сайтом uml2.ru. Я ознакомился с сайтом, мне все понравилось; даже попробовал сходить на несколько встреч сообщества. В принципе, было все интересно: контент, люди. Не устраивала меня регулярность встреч: по сравнению с сообществом питонистов эти встречи проходили нерегулярно (или я не получал информацию о том, когда будет очередная встреча). Плюс, с сообществом аналитиков у меня не срослось возможно, были дополнительные факторы. Мне пришлось выступать с докладом у разработчиков на Python.

Время шло; потребность в сообществе осознал не только я, но и мои коллеги из Альфы. В 2018 году родилась внутренняя инициатива: создать собственные митапы для аналитиков.

Мы собрались с коллегами и создали митап AnalyzeIT: первый раз он прошел 20 сентября 2018 года. В 2019 году было еще два митапа, мы планировали проводить их раз в полгода. В том же году прошел митап от сообщества аналитиков Райффайзенбанка я узнал о нем от коллег из Райфа, которые предложили мне поучаствовать в качестве докладчика. Я не мог отказать; таким образом, я узнал про новое сообщество системных аналитиков, которое мне подходило. Со временем, с моим ростом, с приобретением новых знаний, с общением внутри сообществ я стал узнавать о новых и новых площадках, на которых можно было обмениваться опытом, заводить контакты, организовывать проекты, даже искать новую работу. Из таких площадок я могу выделить Открытый митап для аналитиков: он проходит онлайн, недавно прошла первая встреча, и следующая планируется на 26 ноября. Его идея состоит в том, что, на самом деле, сообществ аналитиков по России очень много; если брать региональную разбивку они есть в Москве, Петербурге, Екатеринбурге, Перми, других городах, и требовалась площадка, на которой люди из разных сообществ могли бы коммуницировать друг с другом.

Как я уже сказал, 26 ноября будет вторая встреча этого сообщества IT Analyst Online Meetup. Если вам интересно зарегистрируйтесь; думаю, она пройдет полезно.

Что делать системному аналитику, когда он пришел на новый проект, а там плохое покрытие документации, конфликты между пользовательским интерфейсом и бэком? С чего правильнее начать в такой ситуации?


Универсального средства для решения таких проблем нет. Аналитик должен разобраться в текущей ситуации и навести порядок; как именно зависит от конкретной ситуации. Если нет документации возможно, стоит выделить время и сформировать ее. Если есть проблемы между интерфейсом и бэком возможно, стоит состыковаться с фронт- и бэк-разработчиком, привлечь архитектора и вместе решать проблему. Сходу ответить на вопрос невозможно, я думаю.

Я рассказал, что есть несколько митапов для аналитиков, где можно свободно выступить, задать вопрос спикеру, пообщаться с членами сообщества. Помимо митапов, есть и другие площадки; сейчас очень популярны телеграм-группы: у того же Райффайзенбанка есть группа для системных аналитиков, я в ней состою. Там, хотя и не так часто, появляются вопросы, и сообщество с удовольствием предлагает варианты решения проблем. Группа называется Open SA Community Raiff; если вам интересно, тоже заходите. Как пример вопроса: недавно заходила девушка и писала, что работает в системном анализе, но чувствует, что в знаниях не хватает структуры, общей методологии аналитика. Она спрашивала мнения сообщества о том, как получить такую структуру; с одной стороны, можно пойти получить высшее образование, с другой сейчас есть много онлайн-курсов, в том числе и по системному анализу, и, возможно, стоит идти туда. А, возможно, стоит попросить руководителя или лида побыть ментором и помочь прокачать аналитику. Различные варианты, возможности; в сообществе как раз и обсудили, что может быть лучшим вариантом.

На митапах можно найти работу джуном?


Да, на митапах можно найти работу. Если мы берем митапы от Альфа-банка там всегда есть HR-специалисты, у них можно получить информацию по вакансиям и передать им свое резюме для рассмотрения. Если в компании есть джуниорские позиции, то можно на них претендовать. Сейчас в Альфе есть оплачиваемые стажировки; конечно, их немного, но они доступны если бы сейчас проводились митапы, можно было бы на них претендовать. Я думаю, на любом митапе, где присутствуют представители HR компании-организатора, есть шанс найти джуниорскую позицию. Поэтому, ходя по митапам, нужно спрашивать.

Я упомянул телеграм-группу Райффайзенбанка; на самом деле, есть и другие группы. В том числе, можно найти отдельные группы по городам. Недавно на Хабре я видел статью, которую написала Анна Михайлова из консорциума Кодекс статья посвящена теме развития аналитиков. Она упоминала сообщества, приводила ссылки на них; в комментариях читатели накидали других ссылок, на телеграм-группы разных сообществ. Статья называется Развитие аналитиков. Ссылок там очень много; все вряд ли можно перечислить.

Обмен знаниями проводится и на других интернет-ресурсах. На том же Хабре, в корпоративных блогах, публикуются статьи от аналитиков компаний; также аналитики пишут собственные статьи, без привязки к компаниям. Мне доставляет удовольствие читать Хабр, и время от времени я нахожу полезный материал.

Чем бизнес-аналитик отличается от системного?


Непростой вопрос, потому что есть разные компании. Должности в них называются по-разному, и обязанности системных и бизнес-аналитиков в разных компаниях могут во многом пересекаться, или даже совпадать. Я уже упоминал профессиональный стандарт системного аналитика для бизнес-аналитика также есть профессиональный стандарт. Можно посмотреть эти стандарты и понять, чем эти профессии отличаются друг от друга. Также я могу порекомендовать статью Ярослава Вартохова, написанную в этом году она посвящена разнице между системным и бизнес-аналитиком. Всё описано в деталях.

Если кратко бизнес-аналитик больше работает с бизнес-составляющей. Это работа с бизнес-требованиями, создание процессов, реинжиниринг существующих процессов. Больше процессов и бизнеса. Системный аналитик больше работает с техникой: проектирование архитектуры будущей системы, проектных решений, написание технических спецификаций, плотное взаимодействие с командой разработки. В моем понимании, бизнес-аналитик больше взаимодействует с бизнесом, а системный с командой разработки. Более формальная граница проводится в профессиональных стандартах. Но, так или иначе, от компании к компании обязанности будут отличаться, и это остается спорным вопросом.

Используется ли вы EPС, или достаточно UML и BPMN?


Если мы говорим про то подразделение, в котором работаю я, то в архитектурных и технических документах мы используем все эти нотации. UML Sequence наверно, наиболее популярные. EPC мы используем в архитектурных документах, при описании функциональных моделей процессов. BPMN я лично еще не использовал его, но некоторые коллеги в Альфе используют в описании архитектурных документов.

Если аналитик ищет в enum переменные на C# и сопоставляет их с документацией это не слишком ли большой отход от обязанностей системного аналитика?


Если таково требование работодателя я думаю, это отход от обязанностей системного аналитика. Если это ваша собственная инициатива, то тем самым вы показываете, что вам интересно то, чем вы занимаетесь; вы развиваетесь, вы хотите лучше понимать, что делают ваши коллеги по команде например, .NET-разработчики. В таком случае это ваше преимущество. То есть, если аналитик разбирается в коде, то это должно быть по его собственной инициативе, а не по требованию сверху. Это на мой взгляд.

Могу сказать, что в Альфе многие аналитики погружаются в код, и даже в ходе анализа кода находят логические ошибки, которые не всегда устраняются на этапе ревью со стороны разработчиков. Например, у нас есть единый сервис, определяющий тип клиента банка. Был написан код, который разделяет организации и индивидуальных предпринимателей, и там был прописан анализ ИНН (12 символов ИП, 10 символов организация). Но зачем писать собственную логику, если есть готовый сервис, и все системы банка используют его это единая точка входа. Если у нас логика как-то меняется, то мы вносим изменения в этот сервис. Если есть альтернативные реализации, то мы должны о них знать и в случае изменения менять код не в одном месте, а в двух. Поэтому, если аналитик погружается в код, то он может выявить неточности в логике работы и помочь их устранить своевременно.

Что лучше использовать для верхнеуровневого проектирования системы? Компонентную диаграмму или диаграмму deployment?


Не могу сказать, потому что требования бывают разные. Даже если говорить о постановке на разработку; у нас есть опытный разработчик, который поймет с полуслова, и есть неопытный разработчик, которому требуется детальная спецификация. Поэтому в данном случае вопрос в том, для кого разрабатывается эта схема, кто является потребителем; в каком виде он хочет получить информацию. Второй момент: в компаниях должны быть стандарты по оформлению документов и моделированию. Каких стандартов придерживается ваша компания? Возможно, у вас принято использовать компонентную диаграмму.

Про сообщества аналитиков поговорили. Если резюмировать, то сообществ на самом деле очень много. Есть конференции я назвал одну, Analyst Days, но на самом деле их много, та же Точка сборки в Питере чего стоит. Помимо конференций, есть митапы аналитиков, телеграм-группы, ресурсы в интернете, где можно общаться и обмениваться опытом.

Что, если вы просмотрели множество сообществ, но не нашли ничего для себя? Вам все еще хочется поделиться информацией с другими или узнать, чем занимаются коллеги из других профессиональных сообществ. В этом случае вы свободны в выборе сообщества из другой области. Например, вы можете посетить сообщество разработчиков, посмотреть, чем они занимаются. Или сообщество тестировщиков, или QA-инженеров и обменяться опытом там. Я достаточно долго ходил на митапы сообщества питонистов, мне было там интересно; я даже задумывался о том, чтобы стать разработчиком на Python. Также я участвовал в старте сообщества QA-инженеров компании Додо Пицца. Это было в 2018 году; ребята только начинали свои митапы, прошел один митап и готовился второй в феврале. Они искали спикеров и предложили мне выступить с докладом несмотря на то, что я не являюсь QA-инженером и отношение к тестированию имею опосредованное, только с точки зрения аналитика.

В случае, если вас приглашают в другое сообщество, или у вас есть желание посетить другое сообщество не стесняйтесь, посещайте, выступайте. Мы все работаем в IT, у нас много точек соприкосновения и общих тем для общения. Например, на втором митапе от Додо Пиццы я выступил с докладом, рассказал, как я (как аналитик) участвую в процессе QA, рассказал о техниках, которые аналитики применяют в своей работе, о тестировочных техниках. Должен заметить, что в наших командах приветствуется развитие Т-компетенций. Это когда у тебя есть основная компетенция (у меня системная аналитика) и смежная компетенция (разработка, тестирование). Это помогает лучше понимать, чем занимаются коллеги, и иногда подстраховывать их в выполнении простых задач, если они отсутствуют. То есть, можно прокачать компетенции и, например, разработать несколько автотестов с использованием существующего фреймворка. Поэтому, если у вас есть возможность и желание посещать другие сообщества я очень рекомендую это делать.

Также я хотел упомянуть об организации собственного сообщества. В чем проблема: вы можете пройтись по существующим сообществам, посмотреть сообщества смежных направлений, но вас ничего не устроит; вы видите для себя определенную нишу и готовы запустить собственное сообщество. Если у вас такая ситуация это хороший опыт; вы можете попробовать войти в эту историю и, возможно, из этого что-то вырастет. На примере Альфы как я уже говорил, мы запускали собственное сообщество, свои митапы AnalyzeIT. У нас было всего три митапа. Как мы их запускали: у нас была команда аналитиков, которые отвечали за контент, и команда из отдела развития бренда, которая отвечала за организацию помещения, привлечения участников и слушателей и за организацию бургер-пати (потому что какой митап без бургер- или пицца-пати; очень важный компонент можно перекусить и пообщаться с коллегами, которые пришли на мероприятие). Организация первого митапа потребовала много времени; мы тщательно готовились, отобрали несколько докладов и 3-4 недели проводили их репетиции. Была безумная подготовка, потом выступили и выдохнули. Остальные митапы были полегче, потому что мы получили опыт, но первый был самым сложным и запоминающимся.

Конечно, сейчас митапы не проводятся из-за эпидемии; в онлайн мы ещё не вышли, но следующем году, возможно, будет развитие.

Мне очень понравилось участвовать в организации сообщества системных аналитиков от Альфа-банка, и в качестве спикера в старте сообщества аналитиков от Райффайзенбанка, и в организации митапов для QA-специалистов от Додо Пицца. Все это полезный опыт.
Я хочу перейти к следующей теме популяризации профессии. Я, как системный аналитик, хотел бы популяризовать нашу профессию. Зачем это нужно? Я выделил для себя две главных причины того, почему стоит этим заниматься.

Первая из них состоит в том, что до сих пор ощущается острое непонимание рядом специалистов сути того, чем все-таки занимаются аналитики. Оно возникает по нескольким причинам. Во-первых, в разных компаниях под должностью аналитика подразумевает различные вещи не кардинально, но различия есть.

В одних компаниях аналитики занимаются только работой с требованиями и написанием верхнего уровня в их ТЗ, в других они лезут в БД, делают запросы и пишут хранимые процедуры.

Все относительно и зависит от самой компании. Если она может позволить себе иметь выделенную должность техписателя, то аналитик будет заниматься работой с требованиями и проектирование, а не описанием существующих решений и документированием системы. В разных компаниях разные требования и ожидания для аналитика, поэтому порой возникает непонимание: чем должен заниматься эталонный аналитик?

Если читать интернет-ресурсы тот же самый Хабр то можно найти относительно много публикаций на одну и ту же тему: какие типы аналитиков бывают и чем они отличаются. Я видел такие публикации и в 2013 году, и сейчас. Вроде бы прошло 7 лет, но об этом продолжают писать значит, непонимание сохраняется.

Например, статей о том, какие типа разработчиков на Python бывают и чем они отличаются, нет; понятно, что среди них есть такие, кто занимается разработкой софта, или аналитикой данных с использованием Python для анализа, но статей с разделением их на типы я не встречал. Наверно, с этой специальностью-профессией все понятно, а вот с аналитиками нет.

Собственно, поэтому я хожу и рассказывают о наших аналитиках. У меня есть опыт системного анализа в Альфа-Банке, и поэтому я фокусируюсь на том, кто же такой системный аналитик в Альфе, чем мы живем, чем занимаемся, как пишем документацию, как оцениваем ее качество, работаем ли мы с метриками продуктов, как происходит развитие наших аналитиков. Я пишу обо всем этом, но с примечанием, что это происходит именно в Альфе; какую-то обобщенную точку зрения на то, кто такой системный аналитик, я не могу дать для этого лучше воспользоваться профессиональными стандартами. В них написан эталон.

Очень интересный кейс, связанный с популяризацией профессии я его назвал кейсом о том, как на двух разработчиков стало меньше. У меня есть два знакомых девушка и парень; девушка закончила технический университет и искала место для стажировки, парень имел большой опыт работы, последние несколько лет работал в продажах, но хотел сменить деятельность перейти в ИТ.

То есть, оба искали возможности в ИТ-сфере; конечно, первое, что приходит на ум в связи с ИТ это программирование, поэтому они смотрели, в том числе, на то, могут ли они зайти на рынок разработчиков информационных систем, и, если могут, то куда: front, middle. У них были свои предпочтения и обстоятельства. И ребята, на самом деле, не до конца понимали, чем занимается системный аналитик; но после того, как мы с ними побеседовали, у них появился интерес. Вслед за беседой я привел их на второй митап от Альфы, они пообщались с нашими аналитиками, послушали доклады. Девушка потом устроилась на стажерскую программу в Альфа-банке, прошла ее и теперь работает в одном из подразделений системным аналитиком. Парень прошел через школу системного анализа, тоже у нас, устроился в штат и сейчас работает в другом подразделении.

Популяризовать профессию надо; это полезно не только с точки зрения снятия неопределенности и внесения ясности в то, чем занимаются системные аналитики, но и с точки зрения привлечения кадров в профессию. Ребята работают уже больше года, у них положительные отзывы то есть, им нравится; системная аналитика для них. Без популяризации профессии они могли бы уйти не туда, например в разработку.

Следующий поинт откуда приходят в аналитику и куда уходят из неё; это пересекается с одним из вопросов из зала: какая следующая ступень после системного аналитика.

Если брать непосредственно Альфу и бэкграунд некоторых ребят, которые сейчас работают аналитиками, то можно сказать, что в аналитику обычно приходят из нескольких определенных областей. Тестирование поработал тестировщиком, набрался опыта, хочет заняться требованиями. Сопровождение (в частности, функциональное сопровождение) нам надоело поддерживать ваши системы, мы хотим сами разрабатывать новые системы; ребята хотят войти в команду разработки, и, за счет неплохого технического бэкграунда, они могут успешно зайти на рынок аналитики.

И разработка: ребята, которым надоело писать код и которые хотят заняться проектированием. Все три направления ИТ-шные, смежные, у всех у них есть шанс попасть в аналитику. Также велик пласт ребят, которые приходят к нам с резюме как кандидаты. Достаточно много приходит из бизнес-анализа: они позанимались бизнес-анализом, хотят глубже погрузиться в технику. Также часто встречаются ребята, которые приходят к нам с управленческих позиций: руководители проектов и владельцы продуктов.

На самом деле, ограничений никаких нет. Прийти в системный анализ можно из любой сферы как я уже говорил, мой знакомый пришел из продаж. Но, наверно, технический бэкграунд и опыт в ИТ это плюс; больше вероятности найти работу системным аналитиком.

Куда системные аналитики уходят дальше? Если брать модель Альфы, то можно выделить бизнесовое и техническое направление. Бизнесовое направление это развитие в сторону владельца продукта; будучи аналитиком, ты развивался как член команды разработки, но теперь ты хочешь выйти из команды разработки, взять ответственность за продукт на себя, хочешь, чтобы тебе выделили бюджет, на который ты бы собрал собственную команду разработки и занялся бы развитием интересующего тебя продукта. Техническое направление это путь к становлению solution-архитектора. Кто это такой? Если взять за пример интернет-банк для юридических лиц, то, с точки зрения клиента, этот банк большая единая система; но с точки зрения нас (как команд разработки) он совокупность программных продуктов, развитием которых занимаются разные команды. Есть команды, которые занимаются развитием приложений по рублевыми платежам, или по депозитам, или по другим направлениям. Много приложений и много команд. Аналитик у нас во-первых, член команды разработки, и, во-вторых, позиционируется как архитектор в рамках своего программного продукта. Solution-архитектор отвечает за архитектуру всего интернет-банка в целом, работая в более широком контексте, чем аналитик. Аналитик эксперт в своем продукте, а архитектор должен разбираться во всем банке. Это второй путь развития аналитика.
Естественно, не забываем про организационную структуру. Если у вас есть возможность, то можно после рядового аналитика или аналитика высокого уровня можно стать руководителем направления, руководителем центра компетенции системной аналитики и далее руководителем дирекции и так далее, как позволит структура.

Чем отличается старший аналитик от ведущего?


Отличается рядом факторов. В разных компаниях требования к старшему и ведущему аналитикам различаются, но глобально различия включают в себя опыт работы, ряд технических навыков, которые он продемонстрировал в ходе выполнения задач, и набор дополнительных обязанностей, которые аналитик выполняет в дополнение к работе над проектом. Это могут быть обязанности по проведению технических интервью, например: опытный аналитик может общаться с кандидатами и давать взвешенную оценку их скиллов аналитики. Если мы считаем, что он способен это делать, то он явно выше, чем обычный старший аналитик. Или он может отвечать за дополнительный блок работ. В общем, у него обычно больше обязанностей соответственно его более высокой компетенции. Но от компании к компании требования, которые разграничивают одного аналитика от другого, различаются.

Расскажите про микросервисную архитектуру


Да, в Альфе используется микросервисная архитектура. У нас есть как монолитные, так и микросервисные системы. Мы идем в микросервис.

Третий блок моего выступления относится к подготовке аналитиков, в первую очередь к подготовке аналитиков с нуля, или подготовке людей, которые еще не имеют определенного опыта в профессии.

У нас одно время была потребность в новых специалистах: банк рос, наше подразделение росло. В какой-то момент мы столкнулись с осознанием проблемы: на рынке не хватало людей, которые удовлетворяли бы нашим критерием. Эта проблема возникла потому, что мы в те времена пользовались, в основном, нашим локальным рынком то есть, рынком тех городов, где у нас находятся офисы (например, Москва и Санкт-Петербург). То есть, большую часть ребят мы тогда смотрели именно в этих городах и не шли в регионы.

И мы осознали, что в наших городах закончились подходящие специалисты. Возникла идея самостоятельного выращивания аналитиков с нуля с доведением до такого уровня компетенции, чтобы они могли спокойно выполнять наши аналитические задачи.

Мы провели пилот в 2018 году; я познакомился с первым кандидатом мне предложили провести онбординг. Девушку посадили в мою команду на период испытательного срока; идея состояла в том, чтобы, работая в команде и взаимодействуя с опытными аналитиками, она бы приобрела необходимые знания для джуна и потом уже, в ходе работы, развилась бы в серьезного аналитика. По результатам 3 месяцев девушка показала достаточно неплохой результат; по ее отзыву, она бы прошла план, который мы составили на 3 месяца, за 2 недели, если бы была опытным аналитиком: то есть, у нее уже возникло осознание того, какие навыки и знания она приобрела за это время.

Она почувствовала свой рост, это неплохо. Далее, на протяжении некоторого времени, мы вместе работали. Потом девушку вывели в отдельную команду, и она стала самостоятельным аналитиком. Она до сих пор растет и развивается в банке. Таким образом, мы подтвердили гипотезу того, что мы в состоянии вырастить аналитика с нуля собственными силами.

СОА или монолит?


Могу сказать, что в банке много разнообразных систем. Если вы работали в банке или сталкивались с похожими системами, то вы представляете, сколько их может быть. У нас есть и СОА, и монолиты, и микросервисы полный набор.

Как эффективно найти работу начинающему системному аналитику?


Много факторов влияет на успех в поисках работы. Немалое значение имеет желание самого кандидата найти эту работу и развиться в области. Бывает так, что человек приходит на курсы, говорит: научите меня. Заканчивает его, получает сертификат, потом ходит по собеседованиям и показывает его. Но если при этом у него нет желания, нет огня в глазах тогда поиск будет затруднительным.

Как эффективно найти работу начинающему системную аналитику? Прокачивать себя и ходить по собеседованиям. Но не просто ходить: надо определить для себя, в какой компании или в какой сфере ты хочешь работать. Не иметь четкой цели и ходить с желанием попасть хоть куда-нибудь это не подходит.

Можно наметить, что вы хотите работать в банке, например. Найти стажерские программы, которые предоставляет банк. Если таких нет, то, может быть, банк проводит обучение для внешних специалистов с возможностью трудоустройства. Или, возможно, у банка есть юниорские вакансии, на которые можно претендовать.

То есть, определите для себя компанию, посмотрите, какие возможности по трудоустройству она предоставляет, найдите сотрудников этой компании наверняка в сообществах аналитиков их можно встретить. Такой комплекс мероприятий может помочь ускорить поиск работы.

На что смотрят при приеме джуна на работу, какой минимум нужен?


Вопрос непростой, потому что до недавнего времени в Альфе начальная позиция называлась старший системный аналитик. Она подразумевала, что в центр компетенции приходит не джун, а опытный специалист с определенным набором знаний и умений. Просто джунов мы не брали. Были стажерские программы (я уже рассказывал про свою знакомую); там было собеседование и задачи в частности, на SQL. Я думаю, если вы ищете джуниорскую работу, то надо почитать, что обычно спрашивают на джуниорские позиции. Моей знакомой знаний из института и предварительной подготовки по SQL оказалось достаточно.

На более высокие позиции, на которые собеседую я, мы не рассматривали джунов до недавнего времени; джуны скорее приравнивались к стажерам.

Что является результатом работы системного бизнес-аналитика, с вашей точки зрения?


С моей точки зрения, беря опыт моего текущего места работы, для системного аналитика можно выделить 3 области работы. Проектирование информационных систем, документирование разработанного и разбор боевых ошибок. Если мы говорим про проектирование, то результат архитектурное решение плюс спецификации на разработку. Для документирования документация по слоям приложения (фронт, мидл, бэк); часто документация и спецификация пересекаются то есть, иногда это один документ. Если мы говорим про разбор дефектов мы, как продуктовая команда, работаем на качество и заинтересованы в том, чтобы наш программный продукт не имел дефектов. Мы стараемся устранить их. Аналитик, в том числе участвует в разрешении дефектов прода.

Какие хорошие команды по системному анализу вы знаете, чтобы джун формировал у себя правильный подход?


На самом деле, я буду рекомендовать своего работодателя. Команд у нас много, они разные, везде есть свои особенности. Но именно тот процесс, который у нас построен, меня привлекает.
В чем состоит эта особенность?

У нас системный аналитик рассматривается как мини-архитектор.Он занимается проектированием архитектуры, и это больше технический специалист. Мы в меньшей степени работаем с бизнес-требованиями, созданием или реорганизацией бизнес-процессов. Здесь вопрос на любителя: если вам нравится общаться с заказчиком, разбираться в нюансах бизнеса, вы не хотите соприкасаться с техникой, то мое подразделение вам не подойдет.

Если же вам нравится погружаться в технику, если у вас есть интерес и вы готовы читать код, учиться писать автотесты для того, чтобы понимать, как работают ваши QA-инженеры и при случае помогать им, то Альфа подойдет вам. Иначе можно посмотреть другие компании. По отзывам, в Лаборатории Касперского хорошо устроены процессы системного анализа; в Райффайзенбанке тоже есть интересные задачи для аналитиков. Это спорный вопрос, конечно: компании большие, команд много, в каких-то командах может быть хорошо, в других плохо. У меня есть знакомая, которая занимается биометрией в Сбере она гордится своей командой, говорит они на высоте, они лучшие. А другие люди приходят к нам из того же Сбера и говорят, что работа скучная, релизы редкие, доступов приходится ждать месяцами. Раз на раз не приходится.

Я назвал несколько компаний; на мой взгляд, там, наверно, хорошо быть системным аналитиком. Как будет в реальности, я не могу гарантировать на это влияет много факторов.

Для джунов главное хардскиллы, что бы вы конкретно рекомендовали?


Да, для джунов главное хардскиллы, чтобы в первое время выполнять относительно рутинную работу. Я бы порекомендовал научиться структурно писать документы, разобраться в типах сервисов и в написании постановок для них, из чего они состоят. Вначале у джуна будет основной поток задач связан с тем, чтобы описать, как реализована система, либо написать постановку по известным требованиям: что нужно сделать, что запрограммировать, чтобы получить техническое решение. На собеседованиях у нас спрашивают знания SQL, но навыки проектирования структур данных и информационных систем настолько же важны (или важнее); если вы это знаете, хорошо разбираетесь и умеете это описывать, то, наверно, это будет ваш плюс.

Как правильно учиться на аналитика и получать опыт для смены профессии, если работаешь в несмежной сфере?


Я бы порекомендовал, во-первых, посмотреть, что предлагают компании. Некоторые компании предлагают школы подготовки аналитиков с нуля, даже не из ИТ я рассказывал, как это было в Альфе; знакомый продажник пришел, и его подготовили. Есть онлайн-курсы, в том же самом GeekBrains (факультет системной бизнес-аналитики), SkillFactory (курс для системных аналитиков я автор этого курса и веду его) или SkillBox (курс для системных аналитиков с нуля). Есть еще Школа системного анализа это серьезный проект, он стартовал в 2011 году и до сих пор существует. Можно найти курсы, можно получить образование. Здесь есть разные варианты: можно сначала поучиться, можно получить некий опыт а онлайн-курсы позволяют выполнять кейсы и набивать портфолио и после этого пытаться устроиться по профессии.

Я рассказал, что был опыт подготовки системного аналитика с нуля это реально. Мы запускали в Альфе школу, нацеленную на то, чтобы массово готовить новых аналитиков; наш пилот закончился успехом, по результатам проведения школы у нас появились аналитики, которых мы взяли на работу. У нас было 18 учеников, которые прошли все этапы отбора. 6 из них устроились у нас в штате, то есть треть; еще один человек получил повышение в своей компании за счет новых навыков и знаний. Поэтому эта школа принесла свои плоды, и большинство ребят, пришедших в нее, не имело опыта в ИТ или смежной профессии.

Я назвал три площадки для онлайн-курсов: GeekBrains, SkillFactory, SkillBox. Я, конечно, могу порекомендовать SkillFactory, потому что являюсь автором и ведущим одного из курсов, но это было бы нечестно с моей стороны; площадок много, я до конца не знаю, что происходит на других площадках и как на них организован учебный процесс. На мой взгляд, у GeekBrains очень большая программа; если посмотреть на сайт, ребята предлагают, в том числе, обучение анализу данных и работе на Python. Я не до конца понимаю, зачем это нужно системному аналитику. На SkillBox неплохая программа, но, судя по косвенным признакам, они больше ориентированы на подготовку именно бизнес-аналитиков; если посмотреть URL-адрес ресурса с описанием системного аналитика, там написано business. Поэтому у меня есть вопросы относительно технической составляющей этого курса, но это только мое предположение; не могу сказать, хорошо ли там или плохо.

Есть еще отдельные онлайн-курсы, при помощи которых можно получить знания, собрать портфолио и дальше, со знанием и портфолио, пробовать устроиться в компанию. На большинстве из этих ресурсов есть свой карьерный центр, который помогает составить резюме, подготовиться к собеседованиям, и даже предлагает вакансии компаний-партнеров. Онлайн-школы сами заинтересованы в том, чтобы их выпускники выходили работу: если выпускник нашел работу и продолжает работать значит, школа провела курс успешно и помогла ученику достигнуть цели. Поэтому, если вы планируете пойти в системный анализ, но не планируете долго обучаться (получать второе высшее), то, возможно, онлайн-курсы вам как раз подойдут.



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, основатель и технический директор компании DeviceLock кто ворует и зарабатывает на ваших персональных данных.
  6. Сания Галимова, маркетолог RUVDS как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
  7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег как стать тимлидом фронтендеров и как жить после этого.
  8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
  9. Ричард Левелорд Грей, создатель игр Duke Nukem 3D, SiN, Blood про личную жизнь, любимые игры и о Москве.
  10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем про игры, их жизненный цикл и монетизацию
  11. Андрей, технический директор GameAcademy как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
  12. Александр Высоцкий, ведущий PHP-разработчик Badoo как создаются Highload проекты на PHP в Badoo.
  13. Андрей Евсюков, заместитель CTO в Delivery Club про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
  14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D байки о том, как создавался DOOM
  15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero о своем проекте и другой деятельности
  16. Татьяна Ландо, лингвист-аналитик в Google как научить Google-ассистента человеческому поведению
  17. Путь от джуна до исполнительного директора в Сбербанке. Интервью с Алексеем Левановым
  18. Как Data Science продает вам рекламу? Интервью с инженером Unity
  19. Как я переехал в Лондон c Revolut
  20. Завтрак с легендарным геймдизайнером Американом МакГи: о новой Алисе, России и депрессии
  21. Как организовать IT-конференцию и не сойти с ума
  22. Чем биоинформатика отличается от вычислительной биологии краткое введение




Подробнее..

Как мы делали SM Lab Analyst Day первый митап по системной аналитике в Sportmaster Lab ( видео всех докладов)

25.03.2021 14:07:14 | Автор: admin

Всем привет. Меня зовут Кирилл Капранов, я руководитель направления системного анализа в компании Sportmaster Lab. 10 марта 2021 года мы с коллегами сделали первый митап по системному анализу, и я хочу поделиться с вами тем, как это было.

Что первым приходит в голову, когда слышишь фразу: "работаю в Спортмастере"? Уверен, у 90% людей промелькнет в голове: "Хм, наверное, продаёт кроссовки". Почему именно эти стереотипы?

Всё просто: в прошлом компания "Спортмастер" делала упор на развитие розничной сети, создание собственного производства, налаживание сети поставок, и, хотя ИТ в этом играло большую роль, знали об этом только внутри компании.

С каждым годом развивающая роль ИТ увеличивалась, но существующая структура компании не позволяла покрывать потребности бизнеса, и в компании началась цифровая трансформация. Внутри цифровой трансформации мы проделали и продолжаем делать большую работу, подробнее можно почитать тут и тут. Мне бы хотелось выделить 2 значимые вехи трансформации:

  • Создание продуктовых команд;

  • Создание центров компетенций.

Когда мы трансформировались, было сформировано отдельное ИТ-подразделение, которое получило название Sportmaster Lab. В это подразделение вошли центры компетенции разработки, системного анализа, QA и методологии.

На этом я подведу черту и перейду к теме статьи. Подробнее о трансформации и роли ЦК аналитики можете послушать в выступлении Сергея Павлова, руководителя направления системного анализа в Спортмастере.

Как мы делали SM Lab Analyst Day

Как появилась идея провести митап?

Центр компетенции (далее - ЦК) аналитики появился меньше года назад. За это время ЦК объединил больше сотни сотрудников из 30 разных команд. Мы выработали стандарты, процессы, подходы и до сих пор прорабатываем решения, которые помогают развивать сотрудников и поддерживать развитие компании.

Однажды мы задали себе вопрос : "А кто об этом знает?". Ответ был неприятный, но честный : "Никто, кроме нас".

Ну что ж, приняли. Пора действовать.

Как спланировали

Любая идея начинается с плана. Наш случай не исключение. Мы оформили план в виде следующего списка:

Цель митапа: Формат проведения: Продвижение: Целевое количество людей: Количество докладов: Тайминг: Этапы подготовки: Договоренности:

План готов, а что с ним делать дальше?

Подготовка к митапу

Для себя мы выделили такие этапы подготовки:

  • Анонс о проведении митапа на сотрудников ЦК, призыв к действию

    На данном этапе важно донести до сотрудников ценность проведения митапа, а также прояснить все оставшиеся вводные:

    • Формат проведения

    • Количество докладов

    • Дата проведения

    • TO-DO list

Эту активность провели в корпоративных чатах и на встречах с сотрудниками. А потом начался этап сбора заявок на выступление.

  • Сбор заявок на выступление

Часто бывает, что на старте подготовки к митапу докладов нет, а есть только идея и желание. Но как же понять суть доклада, его мессадж? Инструменты для выполнения этой задачи можно объединить в такие структурные блоки*:*

  • Идея доклада. Это опыт, трудности или факап, который вдохновил сделать эти выводы.

  • Описание. Краткое изложение материала.

  • Почему это интересно слушать.

Эта информация помогает получить представление о выступлении без подготовки доклада и презентации целиком.

В нашем случае удалось немного прочитерить :)

В SM Lab у нас регулярно проходят внутренние клубы, предназначенные для того, чтобы делиться опытом или показывать полезные инструменты, упрощающие жизнь. Поэтому на старте мы имели порядка 8 тем с готовыми докладами.

Ну всё: считай, дело сделано, расходимся! Но нет...

  • Отбор докладов

Когда хочешь пойти в кино, то вряд ли пойдёшь на фильм, которые тебе неинтересен, ведь так же?

То же самое происходит и при проведении ИТ мероприятий. Нужно заинтересовать своего слушателя.

О чем интересно слушать:

  • Улучшение процессов (с цифрами)

  • Как я могу переиспользовать полученную информацию

  • Практический опыт, разбор примера

  • Факапы и какие выводы из этого были сделаны

  • Как увеличить личную или командную эффективность

О чем слушать не хочется:

  • Мы придумали штуку, но мы её не попробовали

  • Я прочитал статью или книгу, теперь я вам её перескажу

  • Мы тут сделали у себя локальную штуку, послушайте

  • Я расскажу всем известную информацию

Мы взяли бритву Оккама и применили эти списки к своим 8 докладам. Таким образом, у нас осталось 6 докладов и 4 спикера. Так как у каждого из двух спикеров было по два доклада, то мы отдали право выбора им. Так получился тот список докладов, который решили рассказывать на нашем митапе. Теперь пора подумать о продвижении.

  • Начало продвижения

    Для продвижения любого мероприятия нужны деньги ... на самом деле, не cовсем :). Деньги нужны, но не так много, как вы могли бы подумать, особенно в 2021 году, в эру онлайна.

    Для продвижения мероприятия важно подсветить следующие пункты:

    • Где будет проходить запись на мероприятие

    • Целевая аудитория

    • Инструмент проведения мероприятия

    Для своего мероприятия мы выбрали площадкой Timepad. Сначала мы рассматривали его только как инструмент записи на мероприятие, но, изучив его, поняли, что Timepad идеально подходит для нашего мероприятия, так как позволяет делать трансляции на 500 человек.

    В качестве целевой аудитории выбрали профиль обычного системного аналитика специалиста с компетенцией в системном анализе, работающего в команде, не тимлида, не руководителя и не бизнес аналитика.

    И вот теперь, кажется, всё готово! Но нет...

    Заходя в анонс мероприятия, человек должен понимать, какую ценность он получит на выходе. Для этого необходимы тезисы краткие и емкие, отражающие суть доклада.

    Мы их сформулировали, теперь пора переходить к следующему этапу.

  • Тестовые прогоны

    Кажется, что тут всё просто: собирай встречи на спикеров и всех заинтересованных людей и проводи прогоны. Исправляй неточности, предлагай улучшения по презентации и докладу, задавай вопросы. Но много репетиций и правок совсем не гарант того, что финальный результат понравится публике. Мы посовещались и выбрали два прогона необходимым максимумом для митапа. И не прогадали.

Проведение митапа

Митап SM Lab analyst day состоялся 10 марта 2021 года. Пик слушателей составлял 200 человек. Среди участников митапа были cотрудники Сбербанка, Tinkoff, Райффайзенбанка, Альфа-Банка, МТС, EPAM, банка Открытие и РТЛабс и многих других компаний.

О чём мы рассказывали:

Пантелеева Елизавета -Работа в Спортмастере на примере проекта "Новый интернет магазин"

Лиза работает системным аналитиком в команде "Новый интернет магазин", которая состоит из 20 сотрудников (системные аналитики, бэкенд и фронтенд-разработчики, тестировщики).

В докладе Лиза затронула следующие моменты:

  • Как устроена работа продуктовой команды в компании Спортмастер

  • Как мы пришли к продуктовому подходу и какую проблему хотели решить

  • Кто и как проводит декомпозицию задач

  • Как задача переходит в работу и какие стадии она проходит

  • Какова роль системного аналитика

Полуян Артем -Практический кейс замещения аналитиками роли Тестировщик.

Когда ключевой сотрудник уходит из компании, это становится головной болью команды. Думаю, что многие из вас сталкивались с этой неприятной ситуацией. Появляются вопросы, требующие незамедлительного решения что же с этим делать, кто возьмёт на себя роль этого человека.

В докладе Артёма есть ответы на эти вопросы:

  • Как команда может остаться без одной из компетенций

  • Кто и каким образом может забрать на себя работу в момент поиска специалистов

  • Какие подходы в команде опробовали при замещении компетенции

  • Как происходил онбординг и обучение новых сотрудников

  • Какие выводы сделала команда и сам Артем

  • Практические советы по онбордингу нового сотрудника

Заев Артем -Ходим с разработчиками налево!Или Как уменьшить потери на пробелах в бизнес-постановках

Как мы знаем, cистемный аналитик выступает связующим звеном между бизнесом и командой, но зачастую аналитик смотрит на задачу верхнеуровнево и не может задать вопросы бизнесу, которые возникают из-за специфики слоев разработки. Системный аналитик становится "лишним звеном" в цепочке: бизнес-аналитик-разработчик. Как же построить прямой диалог?

Артем поделился кейсом о том, как смогли сначала наладить диалог между командой разработки и заказчика, а потом и уменьшить количество прямого общения c помощью интерактивных досок Miro. Он рассказал о функционале Miro применимо ко Спортмастеру, о том, как общаются с помощью инструмента участники команды, и о профитах от внедрения.

Хахарев Иван -Как мы пришли к Figma или зачем учиться готовить вкусно

Однажды к Ивану в команду пришли новые разработчики и сказали, что макеты это уже прошлый век, и будущее за прототипированием. Так как Ваня человек, который любит изучать новое, он загорелся идеей исследования инструментов прототипирования. В своем докладе он рассмотрел 3 популярных инструмента Axure, Adobe XD и Figma, сравнил их между собой, а также объяснил, почему он выбрал один из них. Бонусом Ваня устроил мини-воркшоп по созданию прототипа.

Заключение

Это был наш первый митап по системному анализу: не всё прошло гладко, как это бывает в первый раз, но мы получили классный опыт проведения подобных мероприятий и рассказали миру инсайдерской информации о системной аналитике в крупном спортивном ритейлере :)

На этом мы не заканчиваем. 20-21 мая мы участвуем в конференции Analyst Days, где выступим с докладами и пообщаемся с единомышленниками на стенде компании.

Нам нравится открыто рассказывать о своей работе. Увидимся на наших новых мероприятиях!

Подробнее..

Перевод 10 советов для написания хороших пользовательских историй

11.03.2021 16:14:30 | Автор: admin

Привет, хабровчане. Для будущих студентов курса Системный аналитик. Advanced подготовили перевод статьи.

Также приглашаем всех желающих участвовать в открытом вебинаре на тему
Как спроектировать REST API и не умереть?. Участники вместе с экспертом на занятии рассмотрят следующие моменты:

Основные плюсы и фичи REST API;
Правильное разделение ресурсов в REST API;
Наследование ресурсов и абстрактные ресурсы.


Пользовательские истории (User stories, юзер стори), вероятно, являются самой популярной техникой аджайл (гибкой методологии) для описания функциональности продукта: с пользовательскими историями очень легко работать. Но рассказывать эффективные истории бывает достаточно сложно. Следующие десять советов помогут вам в создании хороших пользовательских историй.

Аудиоверсия статьи здесь.

Скачать аудиоверсию можно здесь.

1. Пользователи прежде всего

Как следует из названия, пользовательская история описывает, как покупатель или пользователь использует продукт; она повествует с точки зрения пользователя. Более того, пользовательские истории особенно полезны для отражения конкретных функций, таких как поиск продукта или бронирование. На следующем рисунке показана взаимосвязь между пользователем, историей и функциональностью продукта (обозначена кружком).

Если вы не знаете своих пользователей или клиентов, и почему они хотели бы использовать ваш продукт, вам не следует браться писать какие-либо пользовательские истории. Сначала проведите необходимые исследования пользователей, например, с помощью наблюдения за ними или опроса. В противном случае вы рискуете написать спекулятивные истории, основанные на домыслах и идеях, но не на эмпирических данных и реальных свидетельствах.

2. Используйте персонажей, чтобы найти правильные истории

Отличный способ получить представление о пользователях и клиентах это работа с персонажами (или персонами persona). Это вымышленные персонажи, основанные на первичных сведениях о потенциальных клиентах. Обычно они состоят из имени и изображения; соответствующих характеристик, поведения и отношений; и цели. Цель это выгода, которую хочет достичь персонаж, или проблема, которую персонаж хочет видеть решенной с помощью вашего продукта.

Но это еще не все: цели персонажей помогают вам выявлять правильные истории: спросите себя, какую функциональность должен обеспечивать продукт для достижения целей персонажей (я объясняю это в своей статье От персонажей к пользовательским историям. Вы можете скачать удобный шаблон для описания своих персонажей с romanpichler.com/tools/persona-template.

3. Совместное создание историй

Пользовательские истории задуманы как легкий метод, который позволяет вам быстро продвигаться. Это не спецификация, а инструмент для совместной работы. Истории никогда не следует спихивать на команду разработчиков. Вместо этого они должны существовать в диалоге: Product Owner и команда должны обсуждать истории вместе. Это позволяет собирать только необходимый минимум информации, сокращать накладные расходы и ускорять доставку продукта.

Вы можете развить этот подход еще дальше и совместно писать истории во время вашего процесса обработки бэклога продукта. Это усиливает творческий потенциал и знания команды и результирует в создании лучших пользовательских историй.

Если вы не можете задействовать команду разработки к работе с пользовательскими историями, вам следует подумать об использовании другого, более формального метода для фиксирования функциональности продукта, например вариантов использования (юзкейсов).

4. Делайте истории простыми и лаконичными

Пишите истории так, чтобы их было легко понять. Старайтесь делать их простыми и лаконичными. Избегайте путаницы и двусмысленных терминов, используйте активную речь. Сосредоточьтесь только на том, что важно, и не отбросьте все остальное. Приведенный ниже шаблон помещает пользователя или покупателя, смоделированного как персонажа, в историю и ясно показывает ее преимущества. Он основан на широко известном шаблоне Рейчел Дэвис, но я заменил роль пользователя (user role) на имя персонажа, чтобы соединить историю с соответствующим персонажем.

Как <персонаж>

я хочу <что?>,

чтобы <почему?>.

Используйте этот шаблон, когда думаете, что он будет полезен, но не чувствуйте себя обязанным применять его всегда и везде. Поэкспериментируйте с разными способами написания своих историй, чтобы понять, что лучше всего подходит вам и вашей команде.

5. Начните с эпиков

Эпик (Epic) это большая, схематичная, крупномасштабная история. Обычно с течением времени он разбивается на несколько пользовательских историй, на основе отзывов пользователей о ранних прототипах и новых продуктах. Вы можете думать о нем как о преамбуле и временном решении до более подробных историй.

Начало работы с эпика позволяет вам набросать функциональность продукта, не вдаваясь в детали. Это особенно полезно для описания новых продуктов и фич: позволяет охватить приблизительный объем и дает вам время, чтобы узнать больше о том, как наилучшим образом удовлетворить потребности пользователей.

Это также сокращает время и усилия, необходимые для интеграции новых идей. Если у вас много подробных историй в бэклоге продукта, то связать фидбэк с соответствующими элементами часто достаточно сложно, отнимает много времени, и несет в себе риск внесения несоответствий.

6. Уточняйте истории, пока они не будут готовы

Разбивайте свои эпики на более мелкие и подробные истории, пока они не достигнут готового состояния: ясные, выполнимые и проверяемые. Все члены команды разработки должны иметь общее понимание смысла истории; история не должна быть слишком большой, она должна комфортно вписываться в спринт; и должен быть эффективный способ определить, готова ли история.

7. Добавьте критерии приемлемости

Разбивая эпик на более мелкие истории, не забудьте добавить критерии приемлемости (Acceptance Criteria). Критерии приемлемости дополняют истории: они позволяют описать условия, которые должны быть выполнены, чтобы история считалась готовой. Критерии обогащают историю, они делают ее проверяемой и гарантируют, что история может быть продемонстрирована или выпущена для пользователей и других заинтересованных сторон. Как правило, для детализированных историй я люблю использовать от трех до пяти критериев приемлемости.

8. Используйте бумажные карточки

Пользовательские истории пришли к нам из экстремального программирования, и ранняя литература по экстремальному программированию оперирует карточками историй (story cards) а не пользовательскими историями. Причина проста: пользовательские истории были записаны на бумажных карточках. Такой подход дает три преимущества. Во-первых, бумажные карточки дешевы и просты в использовании. Во-вторых, они облегчают сотрудничество: каждый может взять карточку и записать идею. В-третьих, карточки можно легко сгруппировать на столе или стене, чтобы проверить последовательность и полноту, а также визуализировать зависимости. Даже если ваши истории хранятся в электронном виде, при написании новых историй стоит использовать бумажные карточки.

9. Делайте ваши истории видимыми и доступными

Истории нацелены передавать информацию. Поэтому не прячьте их на жестком диске, в джунглях корпоративной интрасети или в лицензированном инструменте. Сделайте их видимыми для всех, например, повесив на стену. Это способствует сотрудничеству, создает прозрачность и делает очевидным, что вы добавляете слишком много историй слишком быстро, так как у вас начинает заканчиваться свободное пространство на стене. Мой Product Canvas, показанный ниже, представляет собой удобный инструмент для поиска, визуализации и управления вашими историями.

10. Не полагайтесь исключительно на пользовательские истории

Для создания хорошего пользовательского опыта (user experience, UX) требуется нечто большее, чем пользовательские истории. Пользовательские истории полезны для отражения функциональности продукта, но они не подходят для описания пользовательского пути и визуального дизайна. Поэтому дополняйте пользовательские истории другими методами, такими как карты историй (story maps), диаграммы рабочих процессов, сториборды (storyboards), скетчи и макеты.

Кроме того, пользовательские истории плохо отражают технические требования. Если вам нужно передать, что должен делать такой архитектурный элемент, как компонент или сервис, тогда пишите технические истории или что предпочитаю я используйте какой-нибудь язык моделирования, такой как UML.

Наконец, написание пользовательских историй имеет смысл при разработке программного обеспечения, которое, вероятно, будет использоваться повторно. Но если вы хотите быстро создать одноразовый прототип или макет для проверки идеи, в написании историй может не оказаться необходимости. Помните: пользовательские истории не о документировании требований; они нацелены дать вам возможность действовать быстро и как можно быстрее разрабатывать программное обеспечение, не создавая никаких особых накладных расходов.


Узнать подробнее о курсе Системный аналитик. Advanced.

Смотреть открытый вебинар на тему Как спроектировать REST API и не умереть?.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru