Всем хорошего начала рабочей недели. А чтобы не было скучно нашел для вас хорошую книгу по теории баз данных. https://edu.postgrespro.ru/dbtech.pdf
Книга по сути является структурированным описанием курса Бориса Асеновича Новикова, доктора физико-математических наук, профессора департамента информатики Высшей школы экономики в Санкт Петербурге. В книге разбираются такие темы как:
• устройство и принципы работы СУБД;
• проектирование баз данных;
• работа с SQL — составление и оптимизация запросов;
• разработка серверных приложений;
• использование различных типов индексов;
• обработка транзакций и одновременный доступ;
• основы эксплуатации баз данных;
• обеспечение надежности хранения, отказоустойчивости и высокой доступности;
• принципы организации и работы параллельных и распределенных СУБД;
• работа со слабоструктурированными данными (JSON, XML)
Если хотите погрузиться в проектирование баз данных и не знаете с чего начать - то эта книга - прекрасный вариант.
#book #database

Наконец публикую свое выступление на пятом аналитическом марафоне. В рамках выступления затронул:
☑️ тему работы аналитика в Agile, как от него пытались отказаться и как к нему вернулись,
☑️ способы взаимодействия аналитика с Agile командой - в рамках одного Scrum процесса или отдельно
☑️ перспективы развития аналитика в Agile в Product owner или в архитектора
#myvideo

Прочитал интересную статью Оксаны Бурбы про критерии качества требований.
Казалось бы, что по этому поводу уже написано огромное количество материалов, но Оксана помимо перечисления различных систем оценки качества приводит сводную аналитику по разным системам и их критериям.
Так же Оксана даёт ряд полезных практических советов, как найти зоны улучшения в своих требованиях.
Читать вдумчиво 8-10 минут
#article #requirements https://www.artofba.com/post/requirements_quality_criteria

Всем доброго вечера. Наконец нашел интересную статью на подумать: 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, ну или которых обидела команда разработки. А на вопрос в начале статьи - могу ответить другим вопросом: "Самолет и турбина: чем отличаются и стоит ли применять их вместе"