Денис Бесков: умные мысли и несколько своих

Что я делаю сейчас в школе SE

Как директор по продуктам
— организую и провожу исследования рынка по востребованности разных компетенций в области анализа и проектирования информационных систем
— ищу и привлекаю новых экспертов к созданию курсов
— заказываю разработку новых курсов экспертам
— анализирую отзывы и оценки по курсам
— заказываю доработку курсов методисту

Как директор по маркетингу

1. Контент-маркетинг:
— заказываю проведение экспертных вебинаров
— заказываю подготовку статей по результатам вебинаров и переводы
— создаю и заказываю публикацию нейроконспектов с командой экспертов-редакторов
— организовываю и заказываю команде проведение онлайн-конференций
— готовлю и оформляю некоторые публичные экспертные материалы (мини-книги, systems.wiki)

2. SMM-маркетинг
— согласовываю посты с анонсами курсов
— пишу посты с интересными ссылками и новостями рынка и публикую их в разные наши каналы и группы
— модерирую группы по работе и САП

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

4. Общий маркетинг и аналитика
— уточняю и развиваю позиционирование школы
— заказываю доработки и развитие сайта
— ищу новые методы и каналы привлечения аудитории для школы и её каналов в целом (сайт, телеграм)
— мониторю показатели сайта и телеграма

Как технический директор
— нахожу новые сервисы на замену существующим и веду проекты по замене
— ставлю задачи техническому администратору
— оплачиваю зарубежные сервисы
— заказываю разработку публичных сервисов для наших групп (чат-боты)

Как владелец компании
— выстраиваю отношения с исполнительным директором и партнёром
— обсуждаю с директорами текущие успехи и проблемы в области продаж и проведения обучения

Мартин Фаулер, международный эксперт по программной инженерии, начал свою публичную просветительскую деятельность с книги Analysis Patterns 1997-го года.

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

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

Андрей Гордиенков решил исправить это досадное обстоятельство и подготовил собственную версию перевода.

https://habr.com/ru/articles/872598/

Вступление
1.1 Концептуальные модели
1.2 Мир шаблонов
1.3 Шаблоны в этой книге
1.4 Концептуальные модели и реинжиниринг бизнес-процессов
1.5 Шаблоны и фреймворки
1.6 Использование шаблонов

Часть 1. Аналитические шаблоны
2. Ответственность
3. Наблюдения и измерения
4. Наблюдения для корпоративных финансов
5. Обращение к объектам
6. Инвентаризация и учет
7. Использование моделей учета
8. Планирование
9. Торговля
10. Производные контракты
11. Торговые пакеты

Часть 2. Поддерживающие шаблоны
12. Слоёная архитектура для ИС
13. Фасады приложения
14. Подходы для моделирования типов
15. Шаблоны ассоциации
16. Послесловие

Часть 3. Приложения
А. Техники и обозначения
В. Таблица паттернов
C. Краткая справка по диаграммам

Алина, CEO SE, задалась вопросом о том, стоит ли разделять репутацию и бренд основателя и компании на нашем примере:

https://t.me/mialinist/127

https://t.me/mialinist/128

https://t.me/mialinist/129

Будет здорово, если поделитесь своим мнением и проголосуете

Курс «Анализ систем»: научиться проектировать сложные системы и распиливать монолиты

16 января стартует курс «Анализ систем», где вы научитесь проектировать сложные системы и разбираться с монолитами, которые достались в наследство. Это ваш шанс стать тем, кто решает системные проблемы, а не создаёт их.

Во время курса вы:

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

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

Курс подходит синьёрам, тимлидам, архитекторам и CTO. Фронтендеры и аналитики тоже найдут много полезного: разберутся, как работают коллеги, и научаться говорить на их языке.

Учёба продлится 5 недель, нагрузка — 10 часов в неделю. Программа выстроена так, чтобы теория сразу превращалась в практику, а сложность увеличивалась постепенно — знания можно применять хоть с первой недели. Код писать не придётся, домашка — прикольная.

Узнать больше →

До 16 января действует промокод AS4BESKOV, который даёт скидку 10%. Если сомневаетесь, подходит ли вам курс, напишите ребятам на почту [email protected] — они честно подскажут, если он не для вас.

Мы с Валерием Зубаировым подготовили рождественский подарок для системных аналитиков — мини-книгу по Apache Kafka

https://systems.education/kafka

Глава 1. Введение в концепции потоковых данных и Event-Driven Architecture
— Традиционные подходы к интеграции
— Эволюция к реальному времени
— Роль Kafka в архитектуре предприятия

Глава 2. Основные элементы Kafka с точки зрения системного аналитика
— Топики и разделы
— Сообщения (messages)
— Продьюсеры (producers) и консьюмеры (consumers)
— Кластер Kafka и брокеры

Глава 3. Kafka как центральный элемент интеграционной шины
— «Шина событий» vs традиционная ESB
— Типовые интеграционные паттерны
— Реактивные системы и CQRS
— Сопряжение с другими системами

Глава 4. Проектирование топиков и стратегий партицирования
— Логическая модель топиков
— Определение ключей сообщений
— Число разделов и фактор репликации
— Рекомендации по выделению топиков

Глава 5. Гарантии доставки и консистентность данных
— Типы гарантированных доставок
— Управление смещениями (offsets)
— Транзакции в Kafka
— Последовательность событий

Глава 6. Роль Kafka Connect и поточная обработка (Kafka Streams)
— Kafka Connect
— Kafka Streams
— Схема High-Level: Kafka -> Processing -> Хранилища

Глава 7. Инфраструктурные аспекты: масштабирование, отказоустойчивость, безопасность
— Масштабирование Kafka
— Отказоустойчивость
— Безопасность
— Мониторинг и логгирование

Глава 8. Типовые интеграционные сценарии и паттерны использования
— Микросервисы и взаимодействие через события
—  Централизованная аналитика событий (Event Streaming)
— Интеграция с legacy-системами
— Социальные сети, push-уведомления, геймификация
— Оркестрация бизнес-процессов

Глава 9. Практические рекомендации по проектированию и внедрению
— Разработка требований к шине Kafka
— Управление схемами и форматами данных
— Управление версиями и совместимостью
— Документирование архитектуры
— Best Practices

Книга пока в бета-версии, как дополним схемами — выложим с возможностью скачивания.

на каникулах пересмотрели сериал «Светлячок» с фильмом-сиквелом

стало понятнее, почему мне так нравится фильм:

1. в центре картины благородный пират, прям как из моих детских книжек Рафаэля Сабатини

2. общая канва сюжета и место Светлячка и его команды в мире сильно напоминает то, что делаю я с коллегами:

— у нас нет глубокой иерархии, только небольшая команда с прямым управлением

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

— в какой-то мере можно сказать, что я проиграл войну-игру с корпорациями, пытаясь работать менеджером продуктов из модели ценностей «адвокат пользователя», когда понял, что на самом деле модель ценностей Альянса для продакта «верная собака бизнеса», а не что я там себе придумал)

— мы находимся на периферии рынка, вдали от больших платформ (Альянса), с которыми неявно враждуем, отбивая у них клиентов

— нам нужно постоянно находить себе новые квесты, чтобы оставаться на плаву

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

— мы часто работаем с планетами и поселенцами-клиентами, которые выбрали жизнь вдали от Альянса

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

«Любой разработчик справится с работой аналитика»

в общем случае при работе с заказчиком нужно:

1. выслушать его идеи о решениях (solution + decisions)

2. постараться вернуть на уровень требований к решению

3. постараться вернуть на уровень целей и ограничений

4. постараться вернуть на уровень потребностей и проблем

5. обсудить улучшаемую деятельность, построить её неформальные модели

6. пофасилитировать месиво проблем, чтобы оно было устойчивым и связанным с бизнесом, а не с личностью наёмника

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

8. переписать идеи о решениях (decisions) на языке потребностей и ограничений в контексте выбранной категории решения (solution)

ЛЮБОЙ в смысле СРЕДНИЙ разработчик будет ломаться уже на 1-2-м шаге, тк он не специалист по:

а) терпеливому общению с людьми.

б) перемещению между 3-4 уровнями абстракции.

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

Почему сложно быть хорошим бизнес-аналитиком

Работа бизнес-аналитика (БА) с первого взгляда может показаться простой: «собрал требования у заказчика — передал команде». На практике же эта роль гораздо глубже и сложнее. Ниже — несколько основных причин, которые делают профессию БА по-настоящему вызовом:

1. Заказчик приходит с идеями о решениях, а не с потребностями
Частая ситуация: на встречу с аналитиком заказчик приходит уже с «готовым» решением, которое хочет внедрить. С точки зрения заказчика, он знает, что нужно, а аналитик должен это просто зафиксировать и задокументировать. Однако в задачу бизнес-аналитика входит возвращать фокус с конкретного решения на то, какие бизнес-проблемы нужно решить или какие процессы усовершенствовать. Без этого не удаётся сформулировать действительно полезные требования и достигнуть ощутимых результатов для бизнеса.

2. Необходимость «разворачивать» заказчика к сути деятельности
Чтобы вывести заказчика на осознание настоящих бизнес-потребностей, БА задаёт вопросы:
— «Что именно мы улучшаем?»
— «Какие есть проблемы и метрики, их описывающие?»
— «Почему эти проблемы возникли?»
— «Какие цели мы хотим достичь и как мы поймём, что успех достигнут?»

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

3. Сопротивление и недоверие со стороны заказчиков
Вопросы «чтобы что?» и «зачем?» — ключевой инструмент БА, помогающий уточнить ценность изменений. Но многие заказчики считают их «подрывом авторитета» или ненужным усложнением. Особенно остро это воспринимается, если аналитик выступает со стороны подрядчика: он — «чужой», и с ним могут очень неохотно делиться деталями внутреннего устройства бизнеса. В таких условиях работа БА усложняется многократно.

4. Трудности работы на стороне заказчика
Когда бизнес-аналитик нанят самим заказчиком, возникает риск «служебной зависимости»: сложно спорить с начальством или спорить с людьми, которые платят тебе деньги. Это может привести к тому, что аналитик принимает требования «как есть», даже если видит их слабые стороны или отсутствие бизнес-логики.

5. «Скучные» для заказчика бизнес-требования
Хорошие бизнес-требования описывают деятельность компании на языке, понятном бизнесу: цели, процессы, метрики, показатели эффективности. Но со стороны заказчика они часто выглядят «сухими» и «самоочевидными». Заказчик же ждёт красивых схем решения и технологических деталей. В результате у него может сложиться впечатление, что аналитик «тормозит» процесс, вместо того чтобы помогать «прокачивать» его идеи.

6. Ограничения конкретных технологических платформ
Если бизнес-аналитик представляет подрядчика, внедряющего определённое решение (например, CRM, ERP, BPM-платформу), то он часто вынужден ориентироваться на возможности и ограничения этой конкретной системы. В итоге может оказаться, что оптимальным решением было бы и вовсе не использовать IT-инструмент, а внести изменения в оргструктуру, процессы или команду. Но в реальности аналитик «подтягивает» бизнес-потребности к тому, что платформа умеет делать «из коробки».

7. Готовность соглашаться с навязанной категорией решения
Из-за всех описанных выше факторов — давления заказчика, желания подрядчика продать свою платформу, привычки руководителей сразу «бросаться в решение» — многие аналитики предпочитают не спорить. Они быстро соглашаются с тем, что уже «придумано сверху», по сути выступая в роли неявных проектировщиков навязанного решения, а не бизнес-аналитиков в классическом понимании.

8. Ограниченный кругозор в бизнес-домене
Профессиональный БА должен разбираться не только в методах анализа и сбора требований, но и иметь широкий кругозор в конкретном бизнес-домене (финансы, ритейл, производство, логистика и т.д.) и типовых решениях. Без глубокого понимания отраслевых реалий он не сможет предложить действенные альтернативы и его участие рискует свестись к «переписыванию хотелок» заказчика.

Как я наконец вышел из «операционки»

В этом году я перестал себя чувствовать как крестоносец, который скачет по рынку и борется с ветряными мельницами против «системной аналитики».

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

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

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

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

Кроме того, в Алине я впервые встретил человека, который так искренне и сильно восхищался нашей школой, а также предлагал множество разных толковых идей по её развитию.

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

И тут как нельзя кстати пришёлся обширный профессиональный опыт Алины в корпоративных финансах и летом я предложил ей сотрудничество в качестве финансового директора школы. Я давно мечтал, чтобы у нас появился свой CFO и вот наконец это случилось.

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

Уже к октябрю стало понятно, что таланты Алины практически безграничны — например, у неё оказался опыт управления коллективом в 30 человек — и вместо того, чтобы выступать исполнителем её идей по выстраиванию операционной работы школы я решил просто доверить ей бразды правления как исполнительному директору школы.

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

Поздравляю Алину с успешным дебютом в роли директора школы и желаю успехов в новом как коллеге и партнёру по бизнесу.

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

в качестве небольшого новогоднего подарка мы собрали материалы наших экспертов в отдельный Systems Integration Hub:

https://systems.education/integration

Надеемся, что эта ссылка станет для вас удобной точкой входа и навигатором в теме интеграций.

Сейчас в хаб попали:
— 6 статей, один перевод мини-книги
— 7 вебинаров
— 11 книг
— 5 онлайн-курсов
— каталог ссылок по интеграции, созданный в партнёрстве с Андреем Бураковым из NextWay
— ссылка на ТГ-группу по теме Интеграции систем

NB: На рождество готовим вам обзорный материал по Apache Kafka для системных аналитиков

Гномам Мории запретили майнить

Миф об утилитарности высшего образования

Где-то в 1990-е годы в России на фоне рыночной экономики и прагматизма возник миф (в терминологии Харари), что:

а) высшее образование должно давать знания и умения, которые ты используешь в работе (в целом звучит разумно)

б) всё, что ты не используешь в работе — это лишняя информация и потери времени на получение этих знаний и умений (звучит как будто разумно)

Я долгое время как инженер и технократ верил в этот миф и спорил с необходимостью проходить обязательную 5-летнюю когнитивную дедовщину.

Но сейчас у меня другое понимание ВО — это не подготовка профессионалов для выполнения понятной типовой работы и даже не чистилище-фильтр для подготовки учёных.

Какие настоящие ценные результаты ВО я вижу:

1. Формирование картины мира — продолжение и расширение того, что было в школе. В этом смысле жаль, что техническое образование однобоко освещает в основном физический и технический мир, но не мир отношений, компаний, людей.

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

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

4. Формирование библиотеки методов. Фундаментальные и прикладные предметы дают студенту множество методов выполнения работ. Но ошибочно ожидать, что студент должен в дальнейшем просто брать их и применять как есть. Выбор и применение готовых методов — это работа из связки «руководитель работ» + «техник», а не бакалавр-инженер-специалист высокой квалификации.

Библиотека методов нужна скорее для создания новых.

Почему так?

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

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

Поэтому да, ВО в каком-то смысле — тренировка нейросетки для решения новых задач, тк для не-новых ВО не нужно.

Так что перестаньте ожидать, что каждый курс вуза обязательно найдёт прямое применение в работе в ближайшие годы. Он может никогда не найти прямого применения. Но это не значит, что он не выполнил своей задачи по развитию вашего мозга.

Итого, если ВО не обязано быть утилитарным, это не значит, что оно обязано быть таким, как сейчас. Можно придумать другие подходы к тренировке мозга. Но учитывая объём текущих программ ВО в 5-10 тысяч часов частным исследователям и мелким организациям сложно предложить работающие альтернативы.

Но критика ВО нужна, про неё — в следующий раз.

Итак, начнём:

Блог Руслан Сафина «Архитектура распределённых систем»

@rsa_enc

в блоге уже почти 1000 подписчиков, надеюсь, с нашей помощью Руслан возьмёт эту планку

Что ценно и хорошо

1. Каналов архитекторов и про архитектуру достаточно мало, поэтому здорово, что такой канал есть.

2. Руслан пишет не только собственные заметки, но и публикует свои выступления и статьи. Причём их очень много!

3. Хорошо, что есть возможность комментирования и прямой контакт автора.

Что можно сделать лучше >>

Самопрезентация

Сейчас из описания канала и закреплённых постов плохо видно, где работает автор и чем ещё занимается, где что преподаёт. Можно добыть частично, если перейти в личный контакт, но так будет делать далеко не каждый.
В идеале сделать закреплённый пост с подробным описанием и ссылками, а также видеопредставление на 20-30 секунд.

Глубина просмотра

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

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

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

Как я вижу, как минимум были бы интересны теги #конференции #мои_выступления #мои_статьи #отзывы

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

Актуальность

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

Продвижение

Было бы здорово, чтобы авторы архитектурных каналов сделали совместную подборку и опубликовали у себя — это может давать прирост до 30% аудитории, по моему опыту.

#разбор_каналов

Предлагаю новый формат постов — разбор тг-канала

С вас ссылка на ваш канал

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

Яндекс делает свой онлайн-редактор документов и это прям очень хорошо https://habr.com/ru/news/865700/

Прошло 10 лет, скилбокс открыл для себя когортное обучение https://skillbox.ru/media/corptrain/chto-takoe-kogortnoe-obuchenie-i-pochemu-ono-populyarno-v-krupnyh-korporaciyah/

экспериментирую с Suno, чего и вам желаю

угадаете жанр?

#музыка

14 декабря, в субботу, Ольга Азимбаева проведёт деловую игру для опытных аналитиков, которые хотят разобраться с темой создания концепции ИТ-решений.

Участники игры:

Узнают

— Зачем нужно думать о концепции решении в работе аналитика;
— Что нужно учесть при проработке концепции;
— Познакомятся с алгоритмом подхода к задаче проработки концепта;
— По каким критериям оценить предложенную концепцию;

Научатся

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

Игровой кейс — автоматизация парка развлечений.

Автор и ведущая

Ольга Азимбаева, бизнес-архитектор

https://sysanschool.timepad.ru/event/3153373/

Кто хотел в этом году разобраться с интеграциями через брокеры — последний в 2024-м поток воркшопа по брокерам ведёт Зоя Степчева:

https://systems.education/kafka-workshop

Посмотреть на Зою можно на видео с её вебинара про кроликов:
https://vk.com/video-211773358_456239227

Небольшие и малоизвестные каналы по анализу и проектированию и не только:

Аналитики

@analyticagain
Анализ, коты, цветы и Катя
85

@kozlovaabout
Козлова обо всем
127

@public_analyst
Публичный аналитик. Настя Московкина
148

@analystsdeliver
Саша Вахненко. Аналитик в Лаборатории Касперского
221

@highuncertainty
Интересные мемы про анализ
250

Продакты

@fake_product
Лжепродакт и AI. Андрей Бураков
162

@startwithease
200

@AlexGetsHRDone
Александр Чигарьков.
Руковожу цифровизацией и продуктовым подходом в HR
722

Архитекторы

@road_architect
Путь IT архитектора. Маша, 23 года
290

@devops_architecture
Об DevOps и архитектуру. Тимур Батыршин
290

@corp_engineering
Инжиниринг корпорации. Тимур Кадыев
331

@rect_arrow
Заметки по Архитектуре программного обеспечения и около того. Ведущий Максим Юнусов.
745

@dochubchannel
Архитектура как код
779

@rsa_enc
Архитектура распределённых систем
Канал Руслана Сафина об ИТ-архитектуре
890

#подборки #каналы

[часть 1] [часть 2] [часть 3] [часть 4]

Алина Богачёва @mialinist подготовила очередной раздел Systems.Wiki на тему

Generative AI for Analysis & Design

в раздел попали материалы:

1. Список нейросетей

2. Бизнес-анализ и требования
Анализ информации
— Обработка интервью
— Обработка анкет
— Анализ законов

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

4. Моделирование и диаграммы
Генерация схем
Генерация UML-диаграмм

5. Интеграции
Создание сценариев интеграции
Создание API-запросов
— REST API
— SOAP

https://systems-wiki.notion.site/Generative-AI-for-Analysis-Design-14b8db9e4167808eac30de6d5740dc03

Обсуждаем кейсы применения GenAI в группе @genai4AnD

Получил подарок от своей музы, очень приятно))

-----

Исландия

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

Припев:
Иглы твоих слов
И нрава крутой торос
Встретят мой напалм.
Другие пусть ищут кров,
Убегают, поджав хвост.
Не на ту напал.

Под шквалом волн, под гнётом непогоды
Я не пойду ко дну в плену оков.
Я девка вулканической породы,
Я вздыблюсь
о‌стровом
из-подо льдов.

Под валом волн, под гнётом непогоды
Я не пойду ко дну в плену оков.
Я девка вулканической породы,
Я вздыблюсь
о‌стровом

Припев

Здесь из речной долины хлещет гейзер,
Петляет многогранных скал гранит,
А ночью распаляет Бетельгейзе
В глазах твоих горящий антрацит.

Припев

#музыка

https://analystdays.ru/ru/talk/129202

Выступили c Алиной Богачёвой (@mialinist) на AD-19, рассказали-показали вживую, как можно делать полезные и обоснованные требования к решению на основе анализа настоящих БТ, а не хотелок-решений Заказчика.

Мой первый опыт парного доклада, в целом получилось не так страшно, как я опасался :) Драматургии и экспрессии немного не хватило, тк все силы ушли на попытку втиснуть материал в полчаса :)

#доклады #выступления #бизнес_анализ

Оценка рынка: обоснованные и необоснованные предположения

У кандидатов в продакты кажется есть некоторая путаница между демонстрацией:
а) умений рассуждать и делать предположения и
б) умений эти предположения обосновывать.

Умения рассуждать хорошо показаны в статьях про прохождение интервью в консалтинговую компанию.

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

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

Почему так?

Например, мы считаем объём рынка по формуле, которая предполагает перемножение нескольких величин (типичный кейс в модели Top-Down и TAM-SAM-SOM):
V = A x B x С x D

Если наши предположения отличаются от фактических величин в +-3 раза, и мы перемножаем например 4 такие оценки, то накапливаемая ошибка может достигать 3 x 3 x 3 x 3 ~= 100 раз в обе стороны, т.е. разницы в 4 порядка.

Оценка рынка с точностью в +-100 раз имеет мало смысла, тк например при оценке рынка в 10.000 человек разброс реальной величины составляет:
— от 100 человек до
— 1.000.000 человек — это совершенно разный масштаб рынка

Для принятия взвешенных бизнес-решений мне интересна оценка с точностью до +-5 раз, полпорядка, те каждая из промежуточных оценок-гипотез должна иметь ошибку не более +-50% — 1,5 x 1,5 x 1,5 x 1,5 = 5.

Тогда максимальный разброс финальных оценок составит не более 25 раз, например, для оценки в 100.000 человек:
— от 20.000 человек
— до 500.000 человек

С этим уже как-то можно мириться и работать.

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

В кои-то веки силами наших талантов Алёны и Катрин обновили лендинг моего курса: https://systems.education/sard

Теперь надеюсь пару лет за него не будет стыдно :)

На 30 ноября к Евгению по выходным ещё есть места. Кто мечтал доразобраться с требованиями по Вигерсу в этом году — welcome

Мы подготовили очередной раздел базы ссылок по инженерии информационных систем http://Systems.Wiki

На этот раз раздел по Инженерии Требований.

В него попали подборки ссылок по темам:

Общие стандарты и своды знаний

Сертификации

Международные журналы

Международные сообщества

Международные конференции

Общие пособия по разработке требований

Инструменты разработки и управления требованиями

Критика инженерии требований

Инженерия требований в машиностроении

Инженерия требований в авиации

Формулирование требований

Разработка бизнес-требований

Требования к продукту

Требования уровня пользователей
— User Stories
— User Story Mapping
— Use Cases

Разработка системных требований

Разработка требований к информационным системам

Разработка требований к ПО

Обеспечение полноты требований к ПО

Я ищу себе стажёра в отдела маркетинга Systems.Education

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

Для этого мы регулярно проводим учебные курсы, воркшопы, открытые вебинары и пишем статьи.

Сейчас нам нужен коллега в помощь, так как объём работ растёт.

Что будет делать маркетолог:
— Исследования и сегментация клиентов
— Разработка и тестирование ценностных предложений
— Поиск и тестирование новых каналов продвижения
— Разработка маркетинговых воронок
— Разработка креативов
— Доработка лендингов
— Разработка и ведение рекламных акций и кампаний
— Анализ маркетинговых метрик и статистики
— Подготовка маркетинговых отчётов

Что нужно знать и уметь для стажировки:
— Профессиональное образование в области маркетинга (можно в процессе)
— Владение методами исследования клиентов (JTBD)
— Умение строить маркетинговые воронки и моделировать клиентский путь (CJM)
— Высокий уровень интеллекта (у нас очень требовательная аудитория)
— Ответственность: соблюдение дедлайнов и стандартов качества
— Коммуникабельность: хороший письменный русский язык
— Хорошее знание английского языка

Пожелания, также будут плюсом:
— Опыт автоматизации маркетинга, своей работы и использования ИИ
— Интерес к информационным технологиям и разработке ИТ-сервисов
— Опыт работы методистом или преподавателем
— Образование и/или опыт в области Customer Experience или Instructional Design
— Образование в сфере ИТ

Почитать условия и откликнуться можно на Хабр.Карьере

https://beskov.substack.com/p/product-vision-8198dcd79b62

ты знаешь — мне с собой не скучно
всегда хватает мыслей и идей
легко могу занять свой мозг полезной
работой — для себя и для людей

теперь же чувство есть совсем иное
не то что скуки, а скорей тоски
мне скучно, без — чего?
твоих касаний,
желаний,
страсти
права —
да, права целовать твои виски

пока иду, лечу, плыву — мечтаю,
и думаю, что слаще, что сильней
куснуть тебя за мочку ареолы?
лизнуть ложбинку меж ухоженных бровей?

Ошибки вашей матрицы

Обнаружил у себя интересные дыры в картине мира при работе с рынком

Я долгие годы считал, что население Казахстана и Белоруссии меньше России в разы, например, в 2-3-4-5 раз

Какая у меня была модель в голове:

Если в России живут 146 млн, то
- в Белорусии миллионов 25-30 (в реальности 9 млн, в 15 раз меньше)
- в Казахстане миллионов 50-70 (в реальности 20 млн, в 7,5 раз меньше)

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

так что будьте осторожны и проверяйте свои карты)

Всем привет!

В основе расписания и каталога наших курсов долгое время были 2 столпа:

- первые 7 лет онлайна (2013-2020) — мой курс по разработке требований к ПО, который позволял получить прочную прагматичную основу профессии СА

- последние 4 года — курс Лены Бенкен по проектированию интеграций, который учитывал изменение профиля СА на рынке в сторону проектирований

но требования к СА растут, работодатели всё больше ожидают не только работы с бизнес-процессами, требованиями и интеграциями, а с проектированием других важных аспектов информационных систем и ИТ-решений — баз данных и архитектуры в целом

Партнёр нашей школы, Анна Вичугова, за последние 2 года показала себя как сильный профессионал как в проектировании ИТ-систем, так и в обучении этому проектированию — половина каталога воркшопов школы сейчас — это воркшопы Анны.

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

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

Анна создала интенсивную 24-часовую программу, которая построена не просто на рассуждениях про архитектуру и её свойства, а позволяет познакомиться, как именно РАБОТАЕТ архитектура за счёт привычного вам уже формата воркшопов, похожих в этом случае на полноценные лабораторные работы.

с 3 ноября пройдёт 2-й полупилотный поток курса из 6 занятий по 4 часа по воскресеньям, как можно догадаться, по умеренной цене, которая дальше будет существенно расти

для тех, кто прошёл наши основные курсы и воркшопы этот курс Анны —  хороший способ завершить (насколько это возможно в наше время) свой профессиональный портрет глубоким практическим пониманием архитектуры программных систем, и по мере набора опыта в рабочей среде, уверенно претендовать на уровень Senior-специалиста

что интересно — программа построена так, что умения программировать будут полезны, но не обязательны (!). Анна поможет вам писать код по заготовкам, даже если у вас не было опыта коммерческого или учебного программирования

https://systems.education/arch-mvp

2 крайности — гипер-аналитик и гипер-менеджер

лет 10 назад по рынку ходили байки, что в Яндексе считают, что аналитик — этот тот, у кого есть мозги, а менеджер — у кого есть яйца

и видимо мне нужен тот, кто из статистики по Максу Дорофееву — «статистически у человека одно яйцо»

это я продолжаю работу и наблюдение за кандидатами на позицию стажёра-продакта, на примере тестовых заданий по оценке объёма рынка

обнаружил 2 крайних антипаттерна:

1. Тревоженка-остороженка

преимущественно женский паттерн

общается осторожно, по шагам, постоянно ссылается на нехватку информации

«так для оценки рынка нужно знать статистику, а у меня со статистикой плохо»

«ой, так это же надо правильные источники знать»

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

обратную связь слушает внимательно и как-будто боится её

настойчиво продолжает что-то делать, не останавливаясь на замечаниях

но смелость мышления в построении эвристических моделей видимо за 2 часа не сформируешь :(


2. Булшитер-«иногда и впендюриваю»

преимущественно мужской паттерн

общается быстро и уверенно, закидывает текстами и идеями

подача информации слабоструктурированная, такая, которая удобна автору, а не читателю

в ответ на замечания уходит в сопротивление, те по итогу не хочет слышать и признавать свою неправоту

склонен быстро давать правдоподобные ответы, действует по модели «что там думать, делать надо» (move fast and break things)

быстро заканчивает диалог и прощается, если получает критику

4-й пилот воркшопа по бизнес-требованиям и требованиям к решению

Я не оставляю попытки сделать работающий курс по анализу бизнес-требований и разработке требований к решению (это уже 3я попытка после 2016 и 2020-го годов :).

В этот раз моя программа курса усилена авторской методикой ЛЮСТРА Алины Богачёвой.

Мы проведём 4-й пилот воркшопа вместе с Алиной через 10 дней, по утрам с 28 по 31 октября, всего 8 часов.

Что будет в программе:

Исследование участка организации
Уточнение контекста бизнес-запроса
Исследование и описание бизнес-процесса
Выявление организационных подразделений и ролей

Уточнение формальных бизнес-требований
Формулирование требований внешних к организации сторон
Выявление бизнес-требований к сотруднику (обязательств)

Анализ рисков и проблем
Выявление рисков
Выявление проблем
Оценка экономических потерь от проблем

Анализ потребностей участников
(Stakeholder Requirements) и бизнес-функций
Выявление опасений участников
Исследование и описание бизнес-функций
Выявление интересов и ожиданий участников
Формулирование потребностей ответственных сотрудников

Формулирование требований к ИТ-решению
Формулирование целей
Уточнение макро-ограничения инициативы
Формулирование требований владельцев процессов к решению

И на пилоте и на курсе в дальнейшем будет не более 8-9 мест, тк тема сложная и нужна только опытным аналитикам и проектировщикам.

Не знаю, как мы уместимся в 8 часов, но будем очень стараться)

Будет много сессий интервью с заказчиком, рисования в Miro и формулирования в преемнике Notion.

https://systems.education/br-workshop

#анонсы #бизнес_анализ #воркшопы

Попугай научился говорить фразу «Что вы сейчас чувствуете?» и устроился работать психотерапевтом

Получил 8 откликов, 4 кандидатам выдал тестовое задание на оценку объема рынка

Что интересно, никто не уточнил, 1) зачем мы делаем оценку рынка, 2) какие решения будем принимать на её основе и 3) как

Ведь можно же просто сказать — «оценка рынка — миллион!»

Вот такой у людей опыт работы в бизнес-анализе (а у троих ещё и в управлении проектами), что спрашивать «чтобы что» не принято :)

Гарвард ведёт онлайн-трансляцию курса по основам программирования этой осенью и выкладывает: https://cs50.harvard.edu/x/2024/zoom/

Сейчас например в 17 по москве будет лекция по SQL: https://cs50.zoom.us/meeting/register/tJEqdOCqrz4rEtSHKCkxdG7yR3MY6LnqElEm

органический рост профессионального тг-канала

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

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

я смотрю канал — а там какой-то тупняк и вода, аж стыдно за людей. они почему-то думают, что если у них есть какой-то опыт и они умеют писать по-русски, то людей в канале нет потому, что это они просто рекламу не дали!

так вот, лучший способ продвигать свой канал — органический

1. называете свой канал так, что бы в нём было видно имя и было видно, что это канал, например «Манка Монолитик / пишу про макросервисы»

2. приходите в большие популярные профессиональные группы, например, к нам в @itsysdes

3. и даёте толковые профессиональные комментарии от лица именно канала, а не личного профиля

4. читатели видят, какой вы умный, понимают, что у вас есть канал, смотрят на него и если вы ещё и пишете полезно, то подписываются

NB: заодно ваши ответы в группах дают вам прекрасную базу для будущих постов

PROFIT!

Сделал подборку каналов на тему Архитектура и системный дизайн: https://t.me/addlist/OOZrK9yfqFllNWRi

Если что-то забыл интересное — пишите!

Ещё раз о пользе опросов — закрытых и открытых

Начинающий аналитик, а тем более продакт, очень верит в силу опросов.

Если потенциальных пользователей у системы много, если потенциальных клиентов у продукта много, то их так и подмывает решать вопрос о составе-концепции продукта, системы, релиза, используя голосование-опрос.

В 2014-м году мы провели опрос наших подписчиков в Facebook о том, обучение какой теме им наиболее интересно. Победила тема про user story. Спустя год мы сделали тренинг на эту тему, но продажи были практически нулевые.

Спустя 10 лет мы сделали в Телеграме опросы нашей аудитории о том, какие темы курсов им интересны. Собрали по 100-150 голосов на набор тем. Приходим спустя 3 месяца в личку, говорим «вот сделали курс на эту тему, как он вам?». Получаем единицы откликов, в лучшем случае вида «я в другом городе, что вы мне сделаете».

Почему так происходит?

Опытные продакты и предприниматели знают, что опросы об интересе — это завуалированный вопрос о будущем. Будущее неизвестно и поведение людей в целом тоже. Всё, на что можно полагаться, с некоторой вероятностью — если человек вёл себя определённым образом несколько раз в похожем контексте, то он возможно продолжит. Например, купит очередной ваш продукт, если купил уже 2-3.

Также опытные П и П знают, что подтверждением намерения является только действие, рассказ о намерении ничего не подтверждает.

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

Опросы похожи на ленивое поскрёбывание по коробке, в которой лежит проблема и, возможно, интересное решение для продукта.

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

Самые частые заблуждения и косяки картины мира в прикладном системном анализе в ИТ и инженерии требований к ПО

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

Почему я так решил — потому что ИИ опирается на весь доступный в нашей ноосфере корпус знаний. И по сути транслирует «коллективное сознательное».

Какие типовые ошибки и заблуждения я обнаружил, наблюдая за перепиской ИИ:

1. Бизнес-требования, сформулированные как свойства программного продукта.

Что не так:
Бизнес-требования — это как минимум требования к результату применения программной системы, а если брать более широко — это требования к устройству и поведению бизнеса, а не ПО.

Хорошей статьи про это не знаю, придётся писать и бороться с том числе с устоявшимися онтологиями.

2. Абстрактные НФТ

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

Подробнее про количественные НФТ в моей статье.

3. Путаница между анализом и аналитикой

Тут возможно работают языковые барьеры, но даже я не могу вас сказать точную принципиальную разницу между например, data analysis и data analytics и существует ли она. В БА я точно понимаю и вижу разницу. В СА я точно понимаю и знаю, что один из терминов не имеет смысла.

Неформальный, но очень полезный рассказ про разницу между БА и БА есть в видеоформате у Константина.

Нецензурная ругань про один единственный СА, ожидаемо, у меня.

4. Путаница между разработкой требований и управлением требованиями

Когорта варягов-менеджеров, популяризировавших PMBOK, начала к любой деятельности и предмету приставлять слово «управление» —
управление проектами, управление бюджетом, управление рамками, управление командой, управление составом работ и т.д., вплоть до абсурдного «управления временем» («он хотел убить время — о ужас!»).

И в какой-то момент почему-то оказалось, что АНАЛИЗ и РАЗРАБОТКА требований местами воспринимаются как часть УПРАВЛЕНИЯ требованиями, хотя любому ежу понятно, что разработка автомобиля, например, не является частью управления автомобилем. Я про это рассказывал ещё на Analyst Days 2012, но воз и ныне там.

Поэтому будьте внимательны, когда общаетесь с ИИ на эти темы.

курс, который перешёл из онлайна в реал

с 2011-го года мы с коллегами ежемесячно проводили в Москве однодневный тренинг «Практика разработки требований», также известный как «ручка» на котором участники за 8 часов получали важный опыт ключевых умений — выявление, классификация, формулирование, согласование требований

к 2013-му году мы попробовали сделать ещё пару тренингов про моделирование и документирование, но они не очень зашли рынку

я задумал сделать курс, который бы помогал научиться сделать полные требования к ПО, как это предлагал Вигерс и в целом лучшие источники по устойчивым практикам рынка типа RUP и IEEE/ISO

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

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

так родился формат 3-месячного онлайн-курса «Разработка требований к ПО», где были модули по бизнес-требованиям, концепции и собственно требованиям к ПО

подробно опыт пилотирования, обкатки и переработки этого курса я описал в своей статье

важно то, что за год экспериментов мне удалось прийти к работающему формату с высокой, близкой к 100% доходимостью до конца курса (Completion Rate, CoR) и близкой к 100% удовлетворённостью (Customer Satisfaction Index, CSI) — 3 недели практических занятий по выходным

востребованность и успех курса были такими, что я сначала передал его для проведения Евгению Галактионову, который с блеском справился и справляется с задачей его проведения уже больше 10 лет, а потом, по запросу корпоративных клиентов — сделал очную 3-дневную версию с Юрой Куприяновым

Юра Куприянов не только практик с 20-летним стажем, но и автор ряда собственных насыщенных и информативных выступлений и статей про инженерию требований

я с чистой совестью говорю, что Евгений и Юрий (а последние пару лет ещё и Мира) ведут мой курс лучше меня, тк я себя считаю неплохим аналитиком и методистом, но посредственным тренером

мы делали перерыв в очных курсах на время пандемии, сейчас видим, что интерес к такому обучению возвращается

несмотря на то, что с 2020-х годов профессия СА сильно ушла в проектирование (архитектуры, баз данных, интеграций), умения применять практики именно анализа и инженерии требований мы до сих пор считаем важным фундаментом работы СА, да и точкой для перехода БА в системный анализ

Юра ведёт мой курс-боевик по разработке требований c 31 октября в Москве, насколько я вижу в CRM, осталось только 5 билетов

мы постарались сделать курс доступным, поэтому очно он идёт по той же цене, что и онлайн

https://systems.education/sard

24 и 25 октября в Москве идём с коллегами на конференцию «Проектирование бизнес‑архитектур 2024»

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

Я воспринимаю конференцию как некоммерческую, тк при достаточно насыщенной программе её ценник за 2 дня всего 14 тр - 10%, что в несколько раз меньше того же Analyst Days:

1. Моделирование в нотации VAD для решения задач ТОП-менеджмента

2. Единая корпоративная архитектура как инструмент поддержки цифровой трансформации и импортозамещения

3. Практика управления процессами и рисками от девелопера

4. Цифровые инструменты организационного развития: практика применения

5. Клиентоцентричный подход к организационному развитию. История автохолдинга

6. Как не похоронить результаты моделирования процессов в проектах автоматизации на платформе «1С»?

7. Как внедрить RPA в компании? Как подготовиться и с чего начать?

8. Есть такая профессия — владелец процесса

9. Оптимизация процессов на уровне ДНК компании. История транспортной компании

10. Точно в цель! BSC vs OKR: стратегия, процессы, метрики, люди

11. Прогресс через вызовы: история внедрения процессного подхода в торговой компании

12. Проектирование процессов в Business Studio 6 для внедрения «1С:Документооборот»: проблемы и возможности

13. Практика оргразвития как драйвер выхода на новые рынки

14. Как сделать так, чтобы процессы работали? Формируем культуру и вовлеченность

Приходите и вы.

Я напомню, что в этом канале не любят непрошеных советов

Точнее, не любили до сегодняшнего дня

В конце концов, праздник — что в группе @itsysdes 10K участников!

Поэтому отныне можно дать мне любой совет в комментарии к любому посту в канале, сначала воспользовавшись ссылкой https://yoomoney.ru/fundraise/15OHTCC8LA7.241008

Ищу стажёра на позицию менеджера продукта с опытом в БА

Основная задача:
Поиск product-market fit и перезапуск продукта

Продукт:
интенсивный контактный онлайн-курс в теме бизнес-анализа

Что будем вместе делать:
1. Изучать рынок, искать интересный сегмент, оценивать размер рынка
2. Исследовать группы потенциальных клиентов и их потребности
3. Исследовать офферы и продукты конкурентов
4. Разрабатывать и тестировать гипотезы ценностных предложений
5. Разрабатывать MVP нового продукта и придумывать методы их проверки
6. Считать и оптимизировать юнит-экономику
8. Описывать и тестить концепцию продукта
9. Заказывать переработку продукта
10. Запускать рекламные кампании и тестить рекламные каналы, собирать первый поток обновлённого курса

Требования к кандидату:
— Опыт работы бизнес-аналитиком в автоматизации
— Законченное обучение управлению продуктами от 50 часов, как минимум полученные умения (а не знания):
а) оценивать объём рынка
б) проводить исследовательские интервью
в) считать юнит-экономику
— Готовность выделять на стажировку 15 часов в неделю
— Готовность встречаться 3 раза в неделю по часу в заранее согласованные рабочие дни и время в интервале 9-18 пн-пт

Также приветствуются:
— любое образование и опыт в теме Instructional Design, Experience Design
— любое образование и опыт в сфере социологии и психологии

Срок стажировки: 3 месяца
Стипендия стажёра: 40 тр в месяц

После стажировки возможны:
— премия по итогам стажировки
— работа на полставки на других условиях

Присылайте структурированный рассказ о себе, включая опыт БА и описание пройденного обучения на продакта, в личку @beskov

NB: подробнее моё видение профессии и компетенций продакта в посте

#вакансии #стажировки #работа_в_SE

Что такое маркетинг и что с ним (обычно) не так

Проблема начинается уже на уровне определений:

1. Однокомпонентное определение

Например, Контур.Школа пишет Маркетинг — это деятельность по продвижению товаров и услуг

(Потом конечно поправляется и раскрывает содержание объёмнее, но поздно, осадок остался.)

Подход очень древний и даже работающий в малом бизнесе.

Известен под названиями "build it and they come", «клиенты голосуют ногами-рублём», «да чё там думать, делать надо».

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

Проблемы метода начинаются при росте бизнеса и отчуждении от клиентов.

Буквально ещё 3 года назад меня позвал CTO Qiwi, познакомил с коллегами и те говорят «мы сделали продукт — Qiwi.Платформа, осталось её продать». Те взрослые умные люди с высшим образованием на голубом глазу говорят «мы тут сделали какую-то хуёвину, но для кого и зачем — не знаем, давайте вы теперь поможете нам это решить, это же просто ?».

2. Двухкомпонентное определение

Тут уже отдельно выделяют:
1) исследование потребителей и
2) продвижение товаров и услуг

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

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

Можно конечно бесконечно пере-«упаковывать» товар и врать клиенту, обещая совсем не то, что товар реально даёт, но для немелкого бизнеса быстро становится ясно, что это очень дорого и нерезультативно.

Поэтому оказывается, прежде чем что-то продвигать, надо изучить, а для кого и зачем.

Причём что забавно в этом определении — тут опять (!) нет никакой связи с производством.

Т.е. как и на основании чего работает производство — не сказано и возникает ощущение, что и аудиторию можно поисследовать хоть и ДО продвижения, но тоже ПОСЛЕ или параллельно с производством.

И это приводит к тем же граблям — что мы продвигаем не то, что произвели, потому что произвели не то, что исследовали.

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

3. Трёхчастное определение маркетинга

1) исследование потребителей
2) заказ и контроль производства товара-услуги
3) продвижение товара услуги

Кажется, только в этом варианте возникает замыкание товара на рынок.

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

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

Понятное дело, что сами маркетологи-а-по-факту-втюхиватели в этом мало виноваты. Вся проблема в CMO и в понимании функции маркетинга (и в частности продуктового управления) топами.

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

И я много раз наблюдал, как возникают сбои при найме первого продакта или даже CPO, когда он пытается применить правильные современные методы по работе с рынком в ситуации, когда это самое понимание рынка не изучено и не извлечено из головы основателя. Результаты плачевные, особенно в B2B. Внятного рецепта у меня пока даже нет, буду сам делать очередной виток)

(продолжение исследования лжи в комментах)

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

Некоторые мои коллеги считают, что чтобы предъявлять адекватные требования к надёжности, критично разбираться в том, как эта надёжность вообще обеспечивается и мне сложно с этим не согласиться.

Если у вас не получается найти время самостоятельно ковырять книги про надёжность в технических системах и примерять на свои ИТ-сервисы, то команда Подлодки поможет вам это время сэкономить:

Podlodka Techlead Crew — онлайн-конференция для техлидов и опытных инженеров, которая пройдёт с 14 по 18 октября.

Тема сезона — «Проектируем надёжность». В программе много всего интересного, и вот несколько примеров:

- Александр Поломодов (Т-Банк) и Олег Бондарь (Яндекс) расскажут о том, как закладывать надёжную архитектуру на старте, используя механизмы самоисцеления и повторных попыток.

- Григорий Кошелев проведет публичное собеседование, в ходе которого проверит, насколько техлиды понимают важность надёжности систем.

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

- Николай Тимонин разберёт, как Feature Toggles помогают гибко управлять функционалом и снижать риски.

А ещё в командах спроектируем надёжную систему в рамках архитектурной каты.

Подключайся и учись строить устойчивые системы! https://podlodka.io/techcrew

#архитектура #надёжность

Базовый билет на 10 сессий обойдётся в 5+ тр, но промокод techlead_crew_7_dmL4nx даёт скидку в 500 руб🥳

Сегодня в Питере на Севкабеле проходит https://beatlesmuseum.ru/beatlesday

Я планирую заехать на концерт в 7, приходите, кому интересна ливерпульская четвёрка, заодно познакомимся
https://beatlesmuseum.ru/prazdnik

Реклама как автоматическое зло

Я вижу, что многие люди и достаточно много среди айтишников воспринимают рекламу как синоним чего-то плохого.

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

Я не понимаю такой установки. Я люблю полезную рекламу — например, нового интересного сервиса, кинофильма, книги, музыкального альбома.

Мне нравится, когда Google показывает мне на дефолтном экране в Андроиде интересные мне новые статьи.

Мне нравится, когда Ozon и Маркет рекомендуют интересные мне товары.

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

Думаю тут происходит ошибка обобщения — если вы видите очень много навязчивой, нерелеватной, тупой, плохой рекламы, то вы начинаете думать, что плоха реклама сама по себе. Но если 70-90% рекламных сообщений для вас не по теме, некстати, неинтересны, то это не значит, что плоха вся реклама целиком.

Отдельно ещё стоит поговорить в целом про маркетинг, а не только про рекламу.

#против_ветра

Первая статья на хабре за 5 лет :)

https://habr.com/ru/articles/846786/

Каких умений я ожидаю от менеджера ИТ-продуктов?

Профстандарт продакта написан очень фундаментально и устойчиво, в нём не видно важных методических деталей:

1. Оценивать объём рынка в TAM-SAM-SOM как через top-down, так и через bottom-up

2. Исследовать опыт клиентов и их потребности через фреймворк Jobs To Be Done, в частности, проводить глубинное интервью

3. Формулировать тестируемые гипотезы о проблемах, решениях, ценности, росте

4. Приоритизировать идеи через один из фреймворков приоритизации (например, RICE)

5. Формулировать и тестировать ценностные предложения

6. Делать черновые макеты интерфейсных решений

7. Проводить тестирование гипотез без реализации их в коде (коридорные тесты, concierge mvp и тд)

8. Считать юнит-экономику продукта

9. Определять состав релиза через Impact Map

10. Создавать карту создания-запуска-развития продукта через User Story Map

11. Анализировать метрики продукта в популярных инструментах

12. Проводить ключевые церемонии Scrum (груминг, планирование спринта, дейли, обзор спринта, ретро)

Чтобы УМЕТЬ делать каждый из этих пунктов, а не просто знать, надо потратить минимум 4-8 часов на каждый.

Поэтому объём практической подготовки современного продакта будет никак не меньше 50-100 часов.

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

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

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

Пожалуйста идите и учитесь сначала сами за свой счёт у Замесина, Красинского, Ханина, Якубенкова, Медведева. Да хоть на любом другом курсе-курсах, которые покрывают перечисленные мной 12 умений.