Есть в этом что-то подбадривающее. А это как раз то, что нужно в начале рабочей недели 😎

#юмор

🌛 Ночь больших технологий

Сегодня хочу проанонсировать довольно необычное событие — big tech night. Это коллаборация Яндекса, Сбера, X5, Т-Банка и Lamoda.

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

👉 Мероприятие будет проходить 12 сентября в Москве. Притом между площадками будет организован трансфер 🚍, так что теоритически будет возможность побывать в нескольких местах.

Для посещения необходима регистрация на сайте: https://bigtechnight.ru/ Там же можно ознакомиться с программой более детально.

P.S. По моим данным "оттуда"😎, посетителей ждёт ещё кое-что интересное. Каждая компания-организатор для посетителей готовит свои "фишки": иммерсивные экскурсии, IT-стендап, поэтический AI-слэм, Robo-зона с роботами-официантами и пиццамейкерами, лаборатория софт-скиллов и др.

#события #анонсы #ai #сбер #роботы

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

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

➡️ В чëм выражается последовательность
Предлагается предъявлять требования к бизнесу и пользователям (сотрудникам). Это позволяет (на каждом из трёх уровней требований) располагать субъектом, к которому предъявляются требования.

➡️ В чëм выражается системность
Всё есть система. Три уровня требований соотносятся с тремя уровнями систем. Так, если двигаться вглубь, то это: организационная система (бизнес-система), человеко-машинная система, техническая система.

Итого. Видео получилось свежим, наполненным смыслами и делающим шаг в верном, как мне кажется, направлении.

#требования #системныйподход #видео

🧐 Выбор между User Story и Use Case

Вопрос о предпочтении одного метода описания требований перед другим — User Story или Use Case — регулярно всплывает среди участников команд разработки и в профильных чатах. Давайте попробуем разобраться, какой метод действительно лучше выбрать, и можно ли вообще комбинировать оба подхода?

🚩 Что такое User Story?

User Story (пользовательская история) описывает поведение системы с точки зрения конечного пользователя, причём простым языком. Это короткое предложение, которое обычно формулируется следующим образом: "Как <роль>, я хочу <действие>, чтобы достичь <цель>".

▌ Плюсы:
- простота формулировки;
- фокусировка на потребностях пользователей;
- гибкость и традиционность для Agile-проектов.

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


🚩 Что такое Use Case?

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

▌ Плюсы:
- ясность сценариев и выполняемых взаимодействий;
- подходит для сложных систем с множеством ролей и вариантов поведения;
- идеально подходит для документирования традиционных водопадных проектов.

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

🕯Это, если тезисно и с определённой долей условности. Но как с этим работать — об этом далее.


🚩 User Story и/или Use Case?

🚩 Когда выбирать один из методов?

Выбор зависит от контекста проекта.

- Если команда работает по Agile, где важны короткие итерации и постоянная обратная связь, User Stories будут логичным выбором.
- Для больших и комплексных систем с высоким уровнем неопределëнности или критическими требованиями рекомендуется использовать Use Cases.

Что важно: выбор следует делать осознанно, но, одновременно с этим, приведённые ранее доводы — это не догма, а только отправная точка. Реальная практика может меняться в зависимости от обстоятельств и получаемой в процессе обратной связи.

🚩 Можно ли совмещать методы?

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

1⃣ Начните с высокоуровневых User Stories, чтобы быстро настроиться на образ результата, определить границы реализуемой функциональности и расставить приоритеты.
На этом этапе некоторые команды дополнительно создают диаграмму вариантов использования UML (Use Case Diagram), чтобы иметь возможность обозреть всю функциональность.

2⃣ Углубитесь в отдельные аспекты с помощью подробных Use Cases, особенно там, где требуются точные спецификации (например, обработка ошибок, неочевидное поведение или граничные условия).
Обычно одна User Story детализируется одним Use Case, при этом User Story в данном случае выступает своего рода заголовком для Use Case.

3⃣ При необходимости дополните Use Cases диаграммами процессов в релевантной нотации.
Так, на практике даже можно встретить подход, при котором каждый Use Case ограничивается несколькими ключевыми ветками сценария, а самая детальная логика представляется в виде развесистой диаграммы на BPMN.

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


🚩 И напоследок

Если требуется углубиться в вопрос разработки User Story или Use Case, советую ознакомиться с моей подборкой видео (ссылка), а точнее — с её 4-м разделом.

#требования #методыуправления #термины #статьи #гайды #визуализация

🥤🍔 Продуктовые метрики

Каждый, кто работает в продуктовой команде, время от времени слышит "мау", "ретеншн" и прочие кажущиеся заклинаниями слова 🧙🏻‍♀️🔮🪄. Не всем и не всегда они понятны, поэтому сегодня я решил этому вопросу посвятить отдельный пост.

Прежде всего, стоит сказать, что речь идёт о продуктовых метриках — показателях, собираемых и оцениваемых владельцами продуктов (Product Owner, PO) с целью определения соответствия продукта ожиданиям его пользователей. Конечная цель — определить, что стоит улучшить, какую фичу добавить, какую убрать и т.п.

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

Я же предлагаю сфокусироваться на самой базе. А это пять метрик, применяемых практически каждым PO. Вот они. ⁀➴

1️⃣ Активность пользователей (DAU/MAU/WAU)

🔜 Описание: ежедневная активность (Daily Active Users), месячная активность (Monthly Active Users), недельная активность (Weekly Active Users) — показывают количество уникальных активных пользователей за соответствующий период времени.
🔜 Цель: измерение популярности и вовлечённости пользователей продукта.

2️⃣ Удержание пользователей (Retention Rate)

🔜 Описание: процент пользователей, продолжающих пользоваться продуктом спустя определённое время после первого взаимодействия.
🔜 Цель: оценка лояльности аудитории и качества продукта.

3️⃣ Отток пользователей (Churn Rate)

➡️ Описание: доля клиентов, прекративших использование продукта за указанный промежуток времени.
➡️ Цель: выявление проблемных зон и улучшение удержания пользователей.

4️⃣ Время жизни клиента (Lifetime Value, LTV)

➡️ Описание: совокупная прибыль, которую приносит клиент за весь срок пользования продуктом.
➡️ Цель: оптимизация расходов на привлечение🔥 новых клиентов и повышение доходности каждого пользователя.

5️⃣ Коэффициент конверсии (Conversion Rate)

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

☝😒 Зачем это знать аналитику?

А затем, чтобы:
— общаться с PO на одном языке;
— понимать потребности бизнеса;
— принимать обоснованные решения при проектировании систем.

#статьи #продукт #термины

🌟 if pow (аналитик, 2) == архитектор

Часто замечаю, что в обсуждениях нет-нет да и возникает вопрос: куда расти аналитику? И, что примечательно, довольно популярной ответ – в архитектора решений.

Но стоит ли аналитику в действительности грезить карьерой solution-архитектора? Или эти две роли настолько разные, что одна из другой никак не вырастает?

Я рассуждаю так.

Системный аналитик – это как опытный следопыт🕵🏻‍♂️, шаг за шагом исследующий лес проблем заказчика и клиентов. Он знает каждую тропинку, ловушку и даже растяжку, старательно установленную смежниками😉 на пути. Но каким бы аналитик ни был выносливым, возможность прочесать весь лес всё же малореальна.

А вот архитектор решений – это как Маша из сказки "Маша и мелведь". Он высоко сидит и далеко глядит. 🔭 Его задача – увидеть общую архитектуру проекта, функциональной области или даже компании в целом, учесть риски и планы по трансформации ИТ-ландшафта. Поэтому архитектор с высоты физически может не видеть всех "тропинок", а некоторые из них просто сливаются в одну большую трассу.

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

Согласны ли вы с моей логикой? Делитесь мыслями в комментариях! ✨