Летний Аналитический Фестиваль, #lafest — одна из моих любимых конференций. Я в ней участвую с 2010 года, хотя и с перерывами. На ней всегда не только доклады, но и ламповая атмосфера и активное общение. С самого первой конференции в Иваново после докладов был выезд на турбазу и активное общение, которое продолжалось до глубокой ночи. А на следующей день — мастер-классы, которые люди предпочитали тем развлечениям, которые давала турбаза. Постепенно конференция росла и меняла площадки, ее начали проводить в доме отдыха два дня в разных местах: Владимир, Кострома, Софрино и других. И к нетворкингу добавился еще вечер пятницы. В этот раз она была под Москвой, комплекс Skypoint hotel рядом с Шереметьево. Там, конечно, поменьше природы, но были вечерние шашлыки в пятницу, и в субботу после афтепати в шатре общение активно продолжалось на свежем воздухе. И это создает атмосферу, которой нет на других конференциях. Этим ЛАФ чем-то похож на [festpir.ru ПИР], тусовку бизнес-тренеров, коучей и консультантов совместно с бизнесом, в котором я тоже участвую много лет. И я желаю ЛАФ развиваться еще много лет, также как и фестивалю Winter Analitical Weekend, который организаторы запустили в этом году в том же формате.

Программа фестиваля включала 5-7 параллельных треков, при этом почти половина активностей — воркшопы и мастер-классы. Так что я был лишь на малой части того, что было на конференции. В том числе — из-за активного нетворкинга. Увы, общаясь с участниками и отвечая на вопросы после своего доклада я пропустил доклад Татьяны Половинкиной HumanOps, о котором услышал много хороших отзывов. А доклад Димы Безуглого стоял параллельно с Максимом Шаломовичем, который тоже интересно и содержательно выступает. А параллельно с моим выступлением вели воркшопы Наталья Семенова и Андрей Дмитриев, на которые я тоже не попал. Так что заметки заведомо неполные, и я знаю, что в них не хватает ряда интересных выступлений. Но публикую то, что есть. И я хочу отдельно отметить воркшоп Анны Подолиной про юмор.

Эта реплика сложилась на фестивале в ходе нетворкинга. Она точно дополнит мои доклады о самоопределении. И я хочу ее зафиксировать в отчете.

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

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

А мне лично тут вспоминается вот какая история. Когда я был студентом, то почти все вечера просиживал в компьютерном зале, решал задачи, которые сам себе ставил. И летом тоже. Мне было просто интересно, я особо не думал про пользу. Хотя она несомненно, именно за счет этого я научился решать сложные задачи, это — фундамент моей дальнейшей работы в ИТ. Но за счет этого у меня было меньше других развлечений, тусовок и дискотек. Хотя, например, ходить в театры я любил еще тогда. Это был собственный выбор. И ретроспективно оценивая результат, я думаю, что интегрально в жизни я приобрел больше, чем потерял. Хотя упущенных возможностей потусоваться иногда до сих пор жалко. Так вот, с пользой для мира ситуация такая же: чем раньше начнешь об этом думать — тем больше шансов, что сделаешь больше.

Был комментарий Feiruz Gabibov: на схеме резкий переход от «Компания» к «Страна», даже если подумать через масштабы. Мой ответ: по-моему, большинство компаний так или иначе вписаны именно в надсистему страны. Естественно, есть локальные компании, которые вписываются в регион или город, или международные, которые вписаны сразу в человечество. Еще есть отраслевое деление, но отрасли — они друг с другом перевязаны. и конкретная отрасль приносит пользу другим отраслям.

Мой доклад был одним из открывающим. Я рассказывал про модель личности, построенную на связке психологических моделей с нейрофизиологией. Презентация опубликована на странице доклада Взаимодействуй с людьми и развивайся с опорой на модели личности (ЛАФ-2024), там же появится видео, когда организаторы его опубликуют.

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

Этому помогают модели softskill: они позволяют понять, как думают и действуют другие люди, которые на тебя не похожи, показывают разнообразие. Другие модели описывают конструкцию и динамику развития команды. Польза от знания моделей примерно такая же, как от знания шаблонов разработки или подходов тестирования: можно работать без них, но с ними — быстрее и эффективнее. Но неуместное применение шаблона может нанести вред. Моделей много, в докладе обо всех не расскажешь. Я остановлюсь на тех, которые входят в мой арсенал и покажу их объединение в комплексную модель, покажу их использование на конкретных кейсах.

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

Участники активно спрашивали: с чего начать. Мой ответ — это зависит от ситуации. Если основная проблема — понимание других людей, то MBTI дает хорошее представление о спектре разнообразия по мышлению и образу действия, а спиральная динамика — о разнообразии и конструкциях ценностей и корпоративной культуры. А если речь идет про устройство команды и поведение людей в ней — то модель командных ролей Белбина, и тоже спиральная динамика, так как она описывает различие agile-mindset от mindset регулярного менеджмента. Эти три модели для меня основные.

По MBTI надо читать книги Отто Крегера, по Белбину — его книги. По Белбину у меня есть статьи и доклады, ориентированные на ИТ. По спиральной динамике есть книга Дона Бека и Криса Кована, но я бы рекомендовал начать с моих статей — блок Спиральная динамика в серии статей «Менеджмент цифрового мира», а также выступлении Спиральная динамика для аналитика - работа на стыке культур (AnalystDays-9 осень 2018).

Дима выполняет важную миссию: показать людям разницу mindset между продуктовым подходом современной цифровой команды и предыдущим классическим проектным подходом. Это — нетривиальная задача, потому что надо вывести человека за пределы привычных представлений. И я могу приветствовать, что Дима регулярно говорит об этой теме. С другой стороны, этот доклад, в отличие от предыдущих, на мой взгляд, дает гораздо менее системное изложение темы, а разницу мировоззрения надо показывать четко. А еще, с моей точки зрения, в докладе смешиваются ряд принципиальных моментов, которые не позволяют хорошо провести границы. И по мере изложения материала я буду это комментировать.

Итак, по состоянию 5 лет назад спрос на системный анализ не рос в России. А сейчас спрос вырос в 4 раза, перегнал рост на продуктов. По бизнес-аналитикам анализ провести не получается, google-тренд не знает такой роли, хотя вакансии есть (это как услышано, подробнее надо смотреть в презентации). И тут российский тренд противоречит мировому, потому что в мире спрос на аналитиков упал в 4 раза.

Почему так происходит? Ответ Димы — потому что в мире формированием продукта занимаются либо разработчики, которые сами определяют куда развиваться продукту, либо менеджеры из бизнеса, которые делают заказ, и им не нужно передаточное звено в виде аналитика. А в России — нужно, потому что менеджеры не умеют разговаривать с разработчиками так, чтобы те не разбежались.

Я считаю, что тут Дима ошибается. Просто 2-3 года назад пошло два тренда: (а) ИТ в производстве, не на основе собственных вендорских решений, а на собственной разработке и (б) импортозамещение, требуемое объективными обстоятельствами. Обе эти деятельности требуют аналитиков, много аналитиков.

Дальше — терминологическое отступление про бизнес-анализ и системный анализ. Если из широкой рамки, то бизнес есть система, потому бизнес-аналитик применяет системный анализ как метод. А вот из узкой, отраслевой рамки, в ИТ сложилось разделение специализаций: бизнес-аналитик понимает бизнес, а системный — проектирует автоматизированную систему. Я отмечу, что такое разделение — не российская особенность, оно принято во всем мире и корни его — в водопадной модели, которая именно так выделила фазы проекта.

Дальше была схема: бизнес-процесс — автоматизированная система — ручные операции. Классическая система: вендор — интегратор — бизнес. Прохождение цепи 6-24 месяцев, быстрее не бывает. И проектный подход: as is — to be и прописать переходный период. И работает классическая система не качественно: чем больше мы деливерим — тем больше запросов получаем. Глюки в элементарном софте — везде, в основном функционале. Яндекс, Сбер, ВТБ и далее по списку.

Я тут хочу заметить, что наезд — не по адресу. Дело не в подходе, он-то как раз более за качество. А вот бизнес-практика побуждает выпускать систему с приемлемым качеством, без перфекционизма — ибо быстрее и дешевле. И, опять-таки, тема — старая, смотри статью Ривза 1992 года «What is software design», кому интересно — у меня в статье Развитие и провал регулярного менеджмента в IT есть подробности.

Дальше был переход к современной digital-команде, которая владеет продуктом и сама, без участия бизнеса, выбирает путь его развития. Аналитик участвует в этом процессе, обеспечивая переход от product и feature discovery, исследований, к разработке и поставке, delivery. И это — конвейер, требования в такой команде не должны прокиснуть, разработчиков надо кормить свеженьким. Жизненного цикла требований — не существует, в отличие от классического подхода, где у Microsoft в Visual studio было 11 этапов преобразования требований с трассировками. Фича проходит 4 фазы: discovery + research, design, development, delivery.

Разработка продукта в продуктовой модели — примерно в 10 раз дороже, чем в проектной. Потому что надо делать инкрементами, итерационно, с проверками гипотез, с проверкой общезначимости. Дима комментировал, откуда появляется эта цифра и, на мой взгляд это — некорректно. Дело в том, что он ссылается на работы старого времени, когда анализировали различие в enterprise-разработке между созданием повторно-используемого продукта для разных компаний с разработкой конкретно под заказ решения, нужного одной компании. И там понятно: выделение повторно-используемого кода, работа с архитектурой, разделяющей ядро и точки расширения и так далее. Как-то справедливо. Но современные-то цифровые команды, такие как авито, Яндекс-такси или Тинькофф-банк не делают повторно-используемых продуктов. Они делают один конкретный продукт в единственном экземпляре, так что это — другое. А реально, на мой взгляд, ситуация другая: когда продукт взлетел, то он начинает приносить столько денег, что ими можно заливать разработку со средненькой эффективностью. А Дима это разделение по продуктам не проводит.

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

Топ-5 ошибок продуктовой разработки.

1. Сделаем продукт по требованиям заинтересованных сторон — опросили пациентов как лечить
2. Сначала соберем все требования — аналитический паралич.
3. Сделаем требования по организации X, а остальным впарим как продукт.
4. Сначала запилим, потом измерим. Или даже не будем измерять — зачем расстраиваться.
5. Как-то плохо продается, давайте еще фич добавим, никому не было плохо. Реально надо выпилить лишнее — поддержка стоит денег.

Разные mindset: управление требованиями — разработка требований — создание продукта. Создание vision с ценностью ля бизнеса требует мышления, которого у многих аналитиков нет.

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

Переход в цифровой мир трансформация цепочки создания ценности. Раньше была пирамидка: процессы — проекты — автоматизированные системы — инфраструктура. А теперь команды, которые автоматизиуют, уменьшают взаимодействие людей. Сетевая структура вместо иерархической. И у каждой системы — своя траектория развития, которую определяет ее команда. Есть контракты на взаимодействие систем, но нет контракта по внешней границы компании, команда ее она двигает сама. Digital team: лаборатория research, product team, эксплуатация и управление, пользователи.

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

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

Итак, есть прошлое: информационные технологии, и есть будущее — цифровые компании. Выбор за вами.

Вопрос: Почему разработчик не мог обойтись перед аналитиком, а вдруг может? Почему разделение труда не работает. Ответ: классическое разделение труда — производство. И там можно поделить фазы, сделать конвейер. А разработка продуктов — НИОКР, и там нельзя разделить на фазы. Проблема бизнеса решается не только ИТ.

Прототип новой системы можно запустить в рамках хакатона, или один спринт, неделя. За следующий спринт можно переделать. За 3-4 итерации что-то заработает. И именно так надо запускать новые системы. А не два года разрабатывать то, что не взлетит. А такой old school по-прежнему местами практикуют. И по-прежнему живут длинными горизонтами планирования, недавно одна российская компания заказывала стратсессию на 10 лет со словами «на 5 лет у нас все спланировано». И половина изменений требований — со сменой настроения руководителей, а не объективные.

Из обсуждения доклада на моем канале.

Oleg Anikin. Я думаю рост потребности в анализе данных закономерен и связан с эволюцией цифровых продуктов. Сперва продукт создан, привлекает клиентов, приносит прибыль. Затем нужно каким-то образом увеличивать прибыль, привлекать новых клиентов, разбираться с проблемами текущих. Объективным способом выглядит анализ данных. А что мы имеем сейчас: цифровизация общества за последние 10 лет значительно выросла, it компании тоже выросли от стартапов до корпораций — данных стало много, пошел бум на анализ этих данных. Думаю, сейчас снижение спроса на аналитиков связано с ростом популярности ИИ, нейросетей в частности, как одного из способов решения проблемы работы с гигантским объемом данных.

Максим Цепков. Это — справедливо. Но тут еще одна исторически сложившаяся путаница в терминологии. Аналитики занимаются проектированием автоматизации, бизнес-аналитик для этого анализирует бизнес, а системный аналитик — проектирует. И ЛАФ — конференция именно таких аналитиков. B вакансии, которые Дима смотрел — на эти специализации. А анализом данных, о котором ты пишешь, занимаются другие специализации — Data Scientist, а еще — специалисты по ML и смежные с ними.

Oleg Anikin. Спасибо за пояснение, теперь надо перечитать еще раз))

Рассказ о том, как получить оценки по новым задачам, когда еще даже непонятно что делать. С практиками ссылками на статьи и примерами. Четыре этапа: Декомпозиция — Оценка — Этапы — Сроки.

1. Декомпозиция — есть разные варианты. Садитесь с командой и выписываете на стикерах. Получаете — иерархическая структура работ. Эпик — Такс — Субтаск. И с ее помощью отслеживают. И есть плугины для сложной Structure — и он делает произвольную структуру и появляются графики.

2. Оценка. Есть хорошая статья Андрей Летюшев. Путеводитель по оценкам задач и котики. Оценка не является обязательством. Это предварительное представление. Они могут и должны изменяться. Программисты не любят оценки. Они отвечают «1 день», делая ввиду, что сделают какой-то прототип, который как-то заработает. А там — посмотрим. Этого менеджер не понимает.

Planing poker. Смысл карт в закрытую — чтобы зафиксировать разницу мнений. Если оценки близкие — значит есть понимание что надо делать. Если большие различия — значит разные представления. А если оценка большая — значит большая неопределенность, надо вынести исследовательскую задачу.

Механика story point — есть статья Оценка задач в Story Points. И пересчет sp в трудоемкости.

Риски не закладываются в оценку, они отдельно.

3. Этапы. user story mapping. Дальше делаем поэтпаное выполнение. Есть дополнительные активности, влияющие на сроки: найм, инфраструктура, доступы, лицензии, закупки. Это может двигать сроки, а в задачах на разработку этого нет.

Приоритизация Статья 20 техник приоритизации в продукте: карта и руководство.

Техники MVP minimal viable product и MMF — minimal marketable feature. Примеры.

• Поиск — сначала по названию, посмотреть как используют.
• Новость — как есть, потом умный редактор, потом массовое.
• Поиск авиабилетов — сначала медленно с крутилкой, потом ускоряем.
• Оплаты — сначала 1 способ, потмо добавляем.
• Загрузка каталога в формате Яндекс-маркета: сначала вручную из файла командой, потом скрипты — уже можно наполнять массово, потом ui без обработки ошибок, потмо разбор ошибок.

4. Сроки. Их всегда два: запланированный и желаемый. Они не совпадают. Когда сделали — надо проверить и исправить. Должен быть запас, и с учетом праздников.

Нетривиально: Пришпоренная лошадь бежит быстрее, а команды под давлением работают медленнее.

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

• Декомпозируем: главная страница, еще страницы, инфраструктура и т. д. Стараемся не забыть.
• Берем понятную, но не самую простую работу. Потом следующий — оцениваем по предыдущей — сложнее или проще. Растаскиваем по горизонтальной шкале условной оценки. И вешаем майки на ось. Размер увеличивает срок вдвое. Важно: много сделано, но никаких сроков и дат не называем.
• Дальше коэффициент пересчета размеров в трудоемкости или сроки.
• Проверка реалистичности оценки.
• Определяем скоуп первого этапа — что и когда покажем заказчику как первую версию. Как только заказчик увидит прототип — он забудет про вторую дату, и начнет креативить.
• Смотрим календарь, не забываем внешние задачи и работы. Включая сроки найма, если надо.

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

Команда соучаствует в оценке — и это важно. Это работает как эффект ИКЕА: The IKEA effect and how I screwed up

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

История о том, как в большой корпоративной структуре — МОЭК делали отдел бизнес-аналитиков под задачу импортозамещения. В ходе импортозамещения надо было поменять 10+ ключевых систем, между которыми исторически сложилось 150+ интеграций, и сделать это, не нарушив работу компании. Идея — сделать отдельный отдел бизнес-аналитиков, чтобы обеспечить целостное представление о бизнес-процессах компании. Идея получила поддержку руководства, и это был первый, самый простой этап. А дальше был рассказ о том, как эту идею реализовывали в корпоративной среде. Для начала пройти бюрократические процедуры определения места бизнес-аналитиков с требуемыми схемами и регламентами, написание должностных инструкций. Надо было обосновать, что будет отдельный отдел, а не распределение аналитиков по командам. К объему этой части, согласованием в корпоративной среде, они не слишком было готовы. Но прошли.

Дальше был найм сотрудников. Профиль: технические навыки — нотации и инструменты; компетенция аналитиков работы с информацией — доставать, формулировать, доносить; коммуникационные навыки. Нужно было 20 человек — 500 анкет, 100 собеседований. Решили давать кейс на 1-2 дня. Например, нарисовать бизнес-процесс по рассказу заказчика. Человек тратит пару часов, но за это понимаем можно ли сотрудничать. Сейчас рынок кандидатов, они диктуют условия и выбирают компании. Приняли решение закрыть часть потребностей через внутреннее совместительство. Взяли экспертов в функциональных областях, тех кто имеет компетенции — и доукомплектовали отдел. И еще запустили программу стажировок для студентов.

Следующее — организовать деятельность команды. И тут ключевая проблема — объяснение бизнесу, кто такой аналитик и что делает в проекте. То есть то, что на этапе бюрократической процедуры делали в документах, теперь делали в реальной работе. Как аналитик встраивается в проект и что делает, при том, что проекты — на разных стадиях. Схемы взаимодействия сотрудников и результаты.

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

И последнее — определить дальнейшее направление. Что будет после импортозамещения? Следующий шаг компании — цифровая трансформация. И они уже сейчас делают задел там, где получается.

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

Хороший доклад с конкретными примерами о том, как применять вместо тяжелых и сложных промышленных языков простые DSL, создаваемые под ситуацию конкретного проекта: делать автотесты и автодоки без Gherkin, бизнес-процессы без BPMN и обмен данными без OpenAPI или SOAP. Потому что мощность, которую дает язык общего вида, в проекте не нужна, при этом, используя такой инструмент, ты платишь сложностью описаний. А простой DSL получается компактным, практически это инициализации данных JScript, которые интерпретируются, или конструкции на Kotlin DSL. При этом ты получаешь ряд преимуществ:

• Конструкции на таких DSL пишут аналитики
• Их можно показывать заказчику, хотя с объяснениями, и тот их согласует
• Работают в коде именно написанные аналитиком описания, нет этапа кодирования конкретных случаев, работает DSL
• По DSL-описанию можно порождать читаемую документацию простыми преобразованиями в asciidoc или markdown и она всегда будет соответствовать коду, а при изменении — сборка документа будет падать

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

И было предостережение: если ваш DSL начинает усложнятся — остановитесь. Усложняя, вы потеряете преимущества. Может быть, у вас ситуация применения полноценного языка типа BPMN, не взирая на его сложность. Или надо описать на простом DSL типовые вещи, а исключения реализовать в коде.

Основной тезис Анны: юмор полезен. Он снимает стресс и переводит мозг в ресурсное состояние. В команде — объединяет и облегчает общение. Средство критики и самокритики. Можно отшутиться от агрессии.

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

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

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

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

Вообще есть три уровня: шутка, уместная на презентации, требующей соблюдения протокола, например, на встрече с министром; шутка в деловых переговорах с внешними партнерами или другими слабознакомыми людьми и шутка в знакомой компании. Хотя тут не однозначно, говорят, на переговорах с министром необходимость точного ТЗ проиллюстрировали анекдотом про ИТ-шника, которого жена просила купить в магазине батон, а если будут яйца — купить десяток — и он купил 10 батонов. потому что яйца в магазине были. Я, кстати, не очень понимаю, почему он купил 10 батонов, формальное выполнение инструкции дает 11. А вот шутка «нет ТЗ — результат ХЗ» — она с теми, про кого знаешь, что такой сленг будет нормально воспринят. Так же как «Ты скажи, ты скажи, че те надо».

Систематика:

• Формы: шутка, анекдот, пародия, каламбур, смешная история. А еще — черный юмор и туалетный юмор, это не для бизнеса, а на стендапе учат этому.
• Смежные жанры: сатира, ирония, сарказм, гротеск
• Подача: история, стендап, импровизация, скетч, сценка.

В шутке, как и в любом произведении искусства, два слоя:

• Идея — что, тема и смыслы. Что мы хотим заявить, чего добиться, какие ценности заложены.
• Композиция — как, по законам гармоничного создания в выбранном стиле, форме, схеме.

Шутка вызывает эмоции.

• Негатив: сложно, трудно, странно, страшно.
• Переводим в позитив: трудно-вызов-маняще; неожиданно-интересно говоришь; удивительно; будоражит-волнует

Схема шутки. Шутка — несмешное превращаем в смешное.

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

Длина шутки. Ванлайн — хлесткая шутка, с обыгрыванием. Редко и тяжело. Остальное — несколько фраз, с обыгрыванием, раскрытием.

Есть 8 основных способов реинтерпретации, которое несмешное делают смешным. И надо тренироваться.

1. Деформация значимости явления — преувеличение мелочей или уменьшение важного.
2. Доведение до крайности
3. Обмен позитив-негатив
4. Обыгрывание, ассоциации, каламбуры
5. Отыгрыш
6. Выверт — очень резкая смена логики
7. Правило 3: большой-большой-маленький или нормальный-нормальный-странный
8. Микс.

И дальше были иллюстрации приемов на примерах. А участникам предлагалось придумывать на свою тему.

• Деформация. Если система не грузится на показе: Это не страшно, вот когда метеорит в серверную попадает… Или вот теперь я начинаю волноваться, как будем год работы восстанавливать…
• Присвоение негативу позитивных характеристик: пока не грузится система я могу рассказать…
• Обыгрывание — отсылки: Брюки превращаются… О, превратились! Крутись колесико, крутись, экранная форма — появись.
• Отыгрыш. 3 способа: акцент, диалоги и слова с интонацией, одушевление. Машины идут в атаку, восстание уже началось. Или у них забастовка, только нам об этом не скажут, потому что агрессия не разрешена.
• Выверт. Взгляд другой стороны. Система не грузится: Вот почему машина может взять перерыв в это время, а я нет? Я тоже хочу зависнуть на кофе с пирожными, и пусть мир подождет…
• Правило 3х. Резкий разрыв логики. Три намека, что сегодня приемо-сдаточные испытания лучше перенести: на прогоне система много виснет, выключили электричество, метеорит попал в серверную час назад.

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

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

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

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

Но, к сожалению, ответы на кейсы получились однотипные. Может быть, потому что сами кейсы были простые. Отмечу, что сам я проводил аналогичную игру на Точке сборки 2019, была такая конференция аналитиков в Петербурге, мы предлагали представить мини-концепцию проекта. При этом, однако, кейс был не учебным: участники игры предлагали свои реальные кейсы, и голосованием был выбран один из них. И, наверное, потому что кейс был реальным, там в самом деле получили девять разных концепций. Детали можно почитать в моем отчете, ближе к концу.

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

Классика — бизнес-процессы в форматах BPMN, EPC и других. Это часто хотят, нанимают аналитиков, чтобы они отрисовали. Применяя этот метод надо помнить, что далеко не всю деятельность можно представить в форме процессов. Есть разбор особых случаев, например, выверка отчетов или разбор, кого обидеть, потому что у логистики заказов на завтра столько, что все не успеть, или есть диагностика инцидента. Это тоже часто называют процессом, потому как мы имеем регулярную результативную деятельность, только вот схему процесса нарисовать нельзя. Для этих случаев работает не Process management, а Case management, для него есть своя нотация, но распространена она гораздо меньше. А еще есть работа трейдера — она тоже не описывается через процессы, его нужно обеспечить информацией и дать возможность для действий. Отмечу, что у меня в был доклад Process и Case Management (Максим Цепков на SECR-2016).

Альтернативные способы: Customer Journey Map, Event storming. Customer Journey Map описывает работу пользователя, и как раз хорошо подходит там, где пользователю от системы нужна информационная поддержка, при этом в зависимости от ситуации есть большое количество сценариев. А Event storming дает взгляд на предметную область как на совокупность событий и реакции на них, это альтернативно классическим процессам.

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

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

В ходе обсуждения добавили еще несколько способов представления процессов.

• Согласование договора хорошо описывается через птички утверждения разных отделов, между которыми может быть своя зависимость условия, когда конкретная птичка необходима в зависимости от параметров договора. Если все это рисовать в BPMN, получится сложная нечитаемая схемА, а так — вполне обозримо.
• Процедуры на отдельные действия и чек-листы проверки — так работают пилоты.
• Доска задач — способ исполнения процессов, а ее структура описывает сам процесс.

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

На этом я заканчиваю отчет с конференции.

Еще обо мне…
Мои доклады
Мои статьи
Мои схемы