Беспощадная реклама #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

Всем привет. 9 февраля на площадке Самоката Екатерина Лысенко организует вторые аналитические чаепития. Будем обсуждать карьерные пути и выбор для аналитиков. Ваш покорный слуга будет одним из участников круглого стола, приходите послушать нас в онлайне.

Коллеги, привет!

Вот и ссылка на таймпад! Ждём вас 09/02/22 в 19:30 в зуме!

Тема - огонь 🔥, спикеры - огнище 🔥!

Запасайтесь чаечком и плюшками, укутывайтесь в пледик, включайте камеру, настраивайте мягкий свет и ныряйте в вопросы поиска путей и тропочек в карьере!

Ждём всех!

https://samokat-tech.timepad.ru/event/1921569/

10 Forecasts For The Near Future Of Tech 🔮 | by Scott Belsky | Positive Slope | Dec, 2021 | Medium
https://medium.com/positiveslope/10-forecasts-for-the-near-future-of-tech-61e73b51647c

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

Ключевые навыки будущего по McKinsey | блог Новая Эпоха Управления
https://blog.bitobe.ru/article/deltas-navyki-budushchego/

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

Короткий, но толковый ликбез по типам интеграции со ссылками на почитать: https://telegra.ph/Tipy-integracii--kakie-oni-byvayut-01-24 #article #integration

Если вы давно хотели понять в чем разница между SaaS и PaaS, или хотите узнать что такое FaaS (спойлер - Function as a Service) то нашел вот такую классную статью со сравнением и примерами. https://habr.com/ru/post/645753/ #article