Всем доброго вечера. Наконец нашел интересную статью на подумать: https://blog.systems.education/lies-statistics-and-ba-in-it-1bd10484a706
Денис Бесков вполне обоснованно замечает, что бизнес аналитик в ИТ это как морская свинка - и не про бизнес и далеко не только про анализ. В целом позиция мне близка и я могу сказать, что себя никогда именно бизнес аналитиком не считал. Мне ближе термин ИТ аналитик, так как я использую техники и системного и бизнес-анализа, но, действительно не являюсь серьезным экспертом в каком-то бизнес-домене, ведь я его всегда рассматривал через призму ИТ.
Термин Дениса "Business Operations Automation Designer" достаточно интересный, но лично у меня сейчас запрос в первую очередь с точки зрения собственного развития, чтобы не только управлять автоматизацией бизнес-операций, а все же непосредственно улучшать бизнес-процессы и оказывать прямое воздействие на деятельность своей компании. Это в целом приближает меня именно к бизнес-аналитикам и владельцам продуктов (а они ведь тоже в первую очередь аналитики, см. мой доклад на Analyst Marathon https://t.iss.one/spherical_analyst/53).
Итого:
1. Полностью согласен, что не бывает БА в ИТ на аутсорсе, он должен быть либо внутри компании, либо именно консультантом без привязки к ИТ
2. В ИТ деятельность "БА" в первую очередь направлена на выявление требований и их описание в контексте конкретного бизнес-процесса или его части.
3. Если вам не очень интересно развиваться в сторону системного анализа и архитектуры, то лучше переходить в in-house разработку и изучать конкретный бизнес-домен, постепенно становясь Product Owner.

Всем привет! Екатерина Лысенко из Самоката собирает аналитические чаепития. Присоединиться можно тут: https://t.iss.one/+QGby-1Yezpo5YjZi

Доброго воскресного утра. Прочитал интересную статью на РБК про решение проблем и принятие решений (PSDM). Статья рассказывает о принципах дивергентного и конвергентного мышления и о том, как их использовать для принятия решений. На самом деле я все больше отмечаю, что многие аналитики прекрасно пользуются дивергентным мышлением для поиска информации, генерации идей и расширению кругозора, но совершенно забывают про то, что наша конкретная цель - это принять решение, как и что мы будем делать. В статье как раз говорится о том, как к этому подойти.
А зачастую нам приходится не просто принимать решения, а помогать целой группе стейкхолдеров принимать важные решения. Для развития в этом направлении рекомендую почитать книгу "Руководство фасилитатора" Сэма Кейнера, в которой в интересной форме подаётся концентрированный опыт по приведению группы к удовлетворяющему всех решению. #article #PSDM
https://trends.rbc.ru/trends/education/5f60d65c9a79477af9127db9

Начинаем неделю с хорошей статьи по архитектуре. Это расшифровка доклада Александра Поломодова про собеседование для разработчиков в Тинькоф, но рассказывает он про Дизайн-секцию в рамках такого собеседования для уровня Senior. То есть про проектирование приложения, а это уже очень полезно для тех СА, которые хотят расти в архитектуру.
Кроме того, Александр сделал свой мини курс по архитектуре, который я как раз с интересом читаю. Присоединяйтесь.
https://apolomodov.medium.com/system-design-interview-at-tinkoff-7bd97c20d082

Ещё одна статья в копилку. Она достаточно общая и теоретическая, но зато описывает основные принципы работы аналитика в Agile с точки зрения международного института бизнес анализа. Если вы пока что не нашли времени почитать BABOK, то рекомендую обратить внимание на эту статью. Читать 5 минут. #article #Agile #BA
https://habr.com/ru/post/590395/

Всем привет. Я наткнулся на статьи Марти Кагана (тот самый, что написал книжку Вдохновленные/ Inspired) и залип на несколько часов. Делюсь с вами интересной статьей про SAFe. Марти явно недолюбливает этот фреймворк, говоря, что его придумали те самые проджект менеджеры проектных офисов крупного энтерпрайза, чтобы не остаться без работы. По сути, Марти говорит, что SAFe в явном виде противоречит продуктовому подходу и мешает кроссфункциональным самоорганизующимся командам приносить максимальную пользу и ценность. Заходите похоливарить в комментарии. #article #agile #SAFe https://svpg.com/revenge-of-the-pmo/

Беспощадная реклама #humor

Всем доброго вечера пятницы. Нашёл прекрасный ликбез по тому, что такое agile. Все чётко и структурированно. #Agile #article https://telegra.ph/CHto-oznachaet-rabotaem-po-Agile-12-02

Всем привет. Прочитал статью про работу бизнес-аналитика от портала Your Mentor. В целом написано неплохо, освещаются фундаментальные вещи в работе аналитика.
Но что мне бросилось в глаза и с чем я категорически не согласен, это постоянное употребление термина "проект". В особенности для работы БА очень опасно концентрироваться на проекте, как на ограниченном скоупе работ на ограниченном отрезке времени. БА должен управлять изменениями в процессах и деятельности организации перманентно, а не только в рамках проекта, так что при прочтении статьи думайте и об этом аспекте. #article #BA https://telegra.ph/CHem-zanimaetsya-biznes-analitik-Sut-raboty-rol-i-navyki-CHast-1-12-14

Ребята, тут со мной поделились интересным видео с Летнего аналитического фестиваля аж 2011 года, где Сергей Мартыненко рассказывает об управлении требованиями, в частности, об из приоритезации, делится несколькими интересными техниками, которые не потеряли актуальности и по сей день!
Сергей вообще общепризнанный гуру в подобных вещах и регулярно выступает с докладами про организацию процесса анализа, разработки и тестирования на различных конференциях. Рекомендуется к просмотру! #video #requirements https://vimeo.com/27122901

Раз уж пошла такая пьянка, то надо повести итоги года.
Сначала казалось, что подвести нечего, но потом начал загибать пальчики:
1. Запустил с Otus курс для системных аналитиков с опытом. Один поток уже выпустился, у второго защита в январе.
2. Запустил с Otus курс для начинающих аналитиков, первый запуск будет защищаться в феврале.
3. Благодаря пунктам 1 и 2 познакомился с кучей крутых аналитиков и просто замечательных людей, спасибо вам, вы очень крутые!
4. Впервые посетил большую аналитическую конференцию Analyst Days и просто мегакрутой Летний аналитический фестиваль. Там познакомился с еще большим количеством прекрасных людей.
5. Сменил работу в крупном Enterprise на работу с динамично развивающимся финтех стартапом (я реально почти сразу вижу результаты своей работы, чем очень доволен)
6. Мало того, что посетил конференции, так еще успел отметиться выступлениями на Analyst Marathon 4 и 5, Analyst Days 13 и Точке Сборки. Спасибо всем организаторам, что дали возможность выступить и рассказать.
И это только профессиональные отметки, а ведь еще:
1. Я дважды отметился на лыжах в больших горах (Сочи и Хибины)
2. Встал еще и на борд
3. Поколесил по России аж до Мурманска на север и до Сочи и Севестополя на юг (дальше пока не выпускают).
Надо на 2022 ставить более амбициозные цели)
Всех с наступающим Новым годом!

Ну что, каникулы закончились, снова вернемся к работе.
Для разминки - интересная статья про то, какие выражения лучше использовать при подготовке документации. От себя могу сказать, что очень поддерживаю тему с правильным использованием пары функционал/функциональность. Но и остальные примеры тоже очень полезные. #article https://habr.com/ru/post/594631/

Всем привет. Первые две недели года выдались очень жаркими, немного выдохнул и решил почитать статейки, которые вышли за это время. Обратил внимание вот на эту статью https://telegra.ph/Agile-i-DevOps-chem-otlichayutsya-i-stoit-li-primenyat-ih-vmeste-01-21. И очень разочаровался. Статья написана людьми, явно далекими от Agile и в принципе не понимающими его ценностей. Об этом говорят хотя бы пассажи, что после доставки кода Agile команда считает свою работу законченной. А дальше все ложится на плечи несчастных DevOps, которые вынуждены все это мониторить. Ну как бы да - мониторить это работа DevOps, это реально крутые сисадмины, которые сильно расширили свои подходы, наборы практик и задачи, но базовые то функции мониторинга остались на них. Команда разработки ровно так же мониторит свой продукт, на на более высоком уровне - на уровне пользовательского опыта и функциональных возможностей/потребностей. Но говорить, что они бросают продукт после релиза - уж точно нельзя.
Ставить Agile и DevOps на одну ступеньку понятийную - так же ошибка, как мне кажется. DevOps - это набор практик и инструментов, которые позволяют организовать и ускорить доставку ПО, а значит они служат целя Agile, благодаря которому они, в общем то и появились.
Подытожим. Статья написана DevOpsами (ребята занимаются частным облаком), которым почему-то захотелось в один ряд с Agile, ну или которых обидела команда разработки. А на вопрос в начале статьи - могу ответить другим вопросом: "Самолет и турбина: чем отличаются и стоит ли применять их вместе"

Извините, но это очень жизненно

Доброго утра. Прочитал интересную статью от ребят из банка Открытие про то, как они делали шаблон для ТЗ. https://habr.com/ru/company/otkritie/blog/648155/.
Сама идея очень крутая, не вычеркивать из шаблона ненужные пункты, а набирать из конструктора только нужные. По умолчанию всегда проще выбрать то что нужно, чем выбросить то что не нужно (вспомните свою антресоль/балкон/дачу). Так что подход я могу только рекомендовать, я сам что то подобное практиковал, когда работал в условно одинаковых проектах на потоке, просто набирал нужные мне куски.
Но один момент меня зацепил и вызвал недоумение. Они пишут ТЗ для реализации User Story. Серьезно? User Story это мелкий квант разработки, которые должен быть выполнен за спринт и принести какую-то ценность (не обязательно конечному потребителю, кстати). Но писать под нее ТЗ, да еще и из огромного количества пунктов с указанием проблемы, цели и решения - это как-то совсем не про гибкие методологии. Я не против такого подхода, просто не надо пихать User Story куда не попадя, особенно туда, где они ни к селу ни к городу. Этим вы только запутаете окружающих.
#article #requirements #userstory

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

Прочитал статью от компании Agima https://habr.com/ru/company/agima/blog/648273/. Все пытался понять, почему всю статью мы вроде про продукты, но нет - про проекты. А потом увидел подпись автора - Head of PMO и все встало на свои места, проджекты в подавляющем большинстве не умеют в продукт, они не умеют в ценность, они только про сроки и бабки.

Очень сильно выдает незнание терминологии, например, growth team - это не команда, которая создает продукт. Growth - это команда, которая растит уже существующий продукт, который доказал свою эффективность и потребительскую ценность, но уперся в некоторый потолок развития и ему нужен новый качественный скачок, они занимаются в первую очередь оптимизацией продукта: SEO, пользовательские пути, поиск узких мест в конверсии.

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

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

Привет, уже совсем скоро 6 аналитический марафон. Крутое мероприятие, в котором я уже два раза участвовал в качестве спикера. Настоятельно рекомендую к посещению!

❗️Напоминаем, что завтра, 4 февраля – первое подорожание билетов 6-й конференции Analyst Marathon «Инструменты и Техники BA/SA».

➡️ А сегодня ещё действуют минимальные цены раннего бронирования – присоединяйтесь: https://bit.ly/35DNLEJ

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

✔️PlantUML на максималках: Как эффективно строить sequence диаграммы
✔️Лайфхаки по использованию Confluence+Requirement Yogi для работы с требованиями
✔️Figmа для аналитика, макеты и прототипы
✔️Техника «Самоонбординга» - Помоги себе сам!

И это не всё, впереди представление ещё двух спикеров и их докладов.

➡️ Купить билеты по минимальной цене: https://bit.ly/35DNLEJ