Business | System analyst
13.2K subscribers
158 photos
86 videos
7 files
912 links
Авторский канал для бизнес/системных аналитиков от аналитика со стажем, как для начинающих, так и для бывалых. Выкладываем авторские посты, статьи (также зарубежные), видео, опросы, юмор))

Сотрудничество: @the_real_bird
Канал ИТ-анализ: @analysis_it
Download Telegram
​​Алоха! Сегодня хочу поделиться с вами одним случаем из моего опыта работы как бизнес-аналитика, так сказать #случайизжизни 💃🏻 На тот момент я была уже опытным аналитиком со стажем более 5-лет и работала в компании на позиции сеньора.

Меня поставили старшим бизнес-аналитиком на проект по запуску новой онлайн-платформы для продажи своих услуг.

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

Однако, в процессе работы я была столкнута с несколькими проблемами и одной из них была недопонимание нефункциональных требований в команде, да и такое бывает 😂. Команда разработчиков и менеджеры продукта имели разное понимание того, что такое нефункциональные требования и как их определить, в целом они не понимали зачем их отделять в отдельные требования и придавать такое важное значение, а команда разработки так вообще не понимала для чего писать все эти доки и кому они нужны🤦🏼‍♀️ но это отдельная история…

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

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

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

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

P.s. Забыла отметить, что я уже там не работаю, и я впервые столкнулась с не пониманием таких определений, как нефункциоанльные и функциональные требования. Мой совет знать такие мелочи и быть более квалифицированными специалистами.

Источник: @ba_and_sa
​​Алоха! Сегодня хочу описать еще один #случайизжизни, с которым я столкнулась на работе в сфере нефтепереработки, где как раз все работают по документации и инструкциям, с этим у них строго, это же производство!

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

⚠️ Суть проблемы: в процессе работы с ключевыми стейкхолдерами, я столкнулась с проблемой коммуникации и разъяснения сложных технических терминов между бизнес-пользователями и разработчиками. Это приводило к недопониманию и неправильному выполнению требований. Так же были недопонимания и бизнесовых терминов между бизнес-пользователями/стейкхолдерами, кто-то говорил об одном, другой говорил о другом, не было единого понимания и целевой картины, все тянули одеяло на себя.

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

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

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

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

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

#случайизжизни | @ba_and_sa
Алоха! Продолжаем нашу рубрику про #случайизжизни и сегодня я не одна, а со мной Александра! Со своим каналом - @normalno_delaj, которая поделится своим опытом и разбором лучших коммуникационных стратегий по моему случаю!

Начнём👇:

Как-то был случай на проекте, мы не могли поладить с разработчиками и тестерами.

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

Я много раз разговаривала с лидом по поводу моей работы, что я им предоставлю все требования верные и согласованный и мы вместе все сделаем, но походу это было без толку… отношение ко мне с его стороны было, как просто к девушке, которая просто сидит и получает зп, мои слова воспринимались в шутку, и серьезного отношения не было, типо «Оксана не лезь в серьезное дела, иди рисуй свои квадратики🤦🏼‍♀️😂, тут дяди работают»…

И вот в один день меня позвали на встречу по предоставлению разработанных фич, я была немного в недоумении🤦🏼‍♀️ презентация прошла плачевно, многое было понято не так и соответсвенно разработано тоже не так, и было много ошибок. В итоге получили по шапке мы оба, хоть я об этом даже была не в курсе.

Что же было дальше? ….


В этот раз предлагаю дать свои комментарии и ответ на вопрос - «что было дальше?» или как поступили бы вы в этой ситуации.

Отвечать и комментировать можно как тут, так и в канале @normalno_delaj под аналогичным постом. Я и Саша будем мониторить комментарии и потом от Саши будет разбор лучших коммуникационных стратегий в этой ситуации, а от меня — рассказ-продолжение истории.
Please open Telegram to view this post
VIEW IN TELEGRAM
​​Алоха! Сегодня хочу описать еще один #случайизжизни, с которым я столкнулась на работе в сфере нефтепереработки

У меня был все тот же проект по внедрению новой системы отслеживания работы и выявления отклонений по продукту. Но в этот раз я столкнулась с проблемой коммуникации между заказчиками!

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

Тут и повалились на меня проблемы и недопонимаю со всех сторон 🤯

Я пришла такая деловая мелкая особа к мужикам на завод, со своими непонятными бумаженциями и схемами, где был описан идеальный процесс их работы в глазах их начальства 🤷‍♀️ Но! В тот же день, я получила очень много вопросов по работе ПО, очень много новых требований и удивленных глаз заводчан! Ведь шишки хотят идеальную картину мира, а на самом деле это все работает не совсем так! И у меня стояла задача разобраться, как донести истину до больших шишек, получить требования с заводчан, которые бы легли на процесс, и найти идеальную картину для всех! Это была задача не из легких, с меня сошло 7 потов, чтобы хоть с чего-то начать! Для начала, мне надо было пояснить заводчанам кто такой БА, с чем я пришла и как устроена разработка🤯

Еще в копилку то, что большие шишки были в СПб, а завод в Омске, и я к тому времени была на заводе в Омске на 2-3 дня! Т.е, у меня стояла задача в маленький срок собрать все требования с заводчан и понять суть их работы, чтобы автоматизировать ее часть и чтобы это все легло на процесс, который был согласован со стороны главных стейкхолдеров🤯

Если вдаваться в небольшие подробности, то в офисе у меня было порядка 3-4 главных стейкхолдеров, на заводе их было 5, это руководители по производству разных отделов, я была одна и со мной еще мой администратор проекта, которая помогала вести список требований и назначала встречи. Сроки для разработки MVP стоял 4 мес и это вместе с разработкой, т.е. в идеале, я должна была собрать все требования и описать процессы, наложить это все на бумагу (описать ТЗ) и передать на разработку, но как я говорила ранее, разработка начала делать все сама, не дожидаясь моих писулек и процессов🤷‍♀️ там тоже были свои конфликты.

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


Что же было дальше

В прошлый раз было очень много интересных кейсов развязки конфликта, давайте в этот раз тоже попробуем придумать развязку и подсказать, что можно было мне сделать в данной ситуации, когда внутри заказчиков есть недопонимания того, что они хотят на выходе!! Делитесь в комментариях👇

Про возникновении вопросов, готова ответить в комментариях!

А я попозже поделюсь своей историей развязки, что я делала, кого привлекала, что вышло и не вышло!!

#случайизжизни | @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
Алоха! Сегодня я поделюсь с вами продолжением истории про ситуацию между заказчиками, когда они не смогли найти общее решение. И спасибо за ваши комментарии!! В след раз рассмотрим другие ситуации в таком же формате))
____________

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

1️⃣Привлечение сторонних отделов, в чьей зоне ответственности это находится, в моем случае - центр компетенции. - «да, к такому решению можно прислушаться и прийти и свалить всю зону ответственности на них, если таковы имеются на проекте, но! В основном таковых нет»

2️⃣Переговоры со стейкхолдерами - «это само собой будет в цепочке развязки таких проблем, но просто переговоры не всегда все решают, ну или затянутся на долгий срок»

____

«Ну а что же было дальше у меня?»

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

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

Вторым шагом было обсуждение отдельных мелких процессов с каждым руководителем отделов на заводе, где я собрала и с них требования по процессу! С каждым по отдельности

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

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

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

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

Никого стороннего мы не привлекали, все обошлось глубоким изучением процессов на заводе, изучением документации, обсуждением со стейкхолдерами, тесным общением с Владельцем продукта, общение с разработчиками и тестированием ПО и конечно же, глубоким погружением в сам завод и в их работу!

В итоге мы выпустили MVP🥳

#случайизжизни | @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM