К выступлению готов. Презентационный конструктор (Рубрика #PublicSpeaking)

Сегодня я решил продолжить тему презентаций и обсудить книгу "К выступлению готов. Презентационный конструктор" Радислава Гандапаса, которую я прочитал лет 8 назад:)
Эта книга состоит из трех частей
1. Презентация сегодня
2. Структура презентации
3. Как сделать презентацию эффективнее

Интересно, что и публичные речи по мнению автора делятся на три жанра
1. Речи побуждающие (рекламные выступления) - цель в том, чтобы аудитория сделала то, что хочет спикер
2. Речи ритуальные (тосты, поздравления) - цель эмоционально всколыхнуть аудиторию
3. Речи информирующие (доклады, лекции) - цель в донесении новой информации

Причем автор убеждает читателей в том, что в бизнесе презентации относятся к жанру побуждающих, так как спикер обычно хочет что-то от аудитории. Даже если изначально он думает, что просто ее информирует о чем-то и в отдаленной перспективе усвоенная информация как-то повлияет на поведение слушаетелей в отношении объекта презентации. Хороших презентаций без цели не бывает:)

Дальше Радислав дает рецепт подготовки к презентации
0) Римские каникулы - тонкая самонастройка, в которой будущее выступление сравнивается с отдыхом в Риме
1) Вопросы жизни и смерти - Кто будет в зале? Что мне от них нужно? Что я должен делать?
2) Структура презентации - лучше это делать в соответствии с законами композиции и драматургии
3) Репетиция - без тренировок не бывает успеха
4) Фиксация - слайды как способ фиксации канвы рассказа
5) Коррекция - демо-прогоны перед людьми в условиях близких к "боевым"
6) Заслуженный отдых - в день перед выступлением стоит взять паузу и отдохнуть

Ну и дальше в книге даются алгоритмы того, как правильно структурировать презентацию и как работать с аудиторией во время выступления:)
В общещм, книга интересная и ее стоит прочитать для улучшения своих presentation skills.

P.S.
Грустно, что автор потом ушел из области публичных выступлений в бизнес-тренерство и дальше его авторитет в моих глазах пошел по нисходящей

#Presentations #PublicSpeaking

Убеждай и побеждай (Рубрика #PublicSpeaking)

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

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

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

#SelfDevelopment #Thinking #PublicSpeaking #Presentations

Пиши, сокращай (Рубрика #Writing)

Часто слышу упоминание книги "Пиши, сокращай" в позитивном контексте, но мне эта книга далась очень тяжело - я читал ее в сумме полгода:)
Из этого времени первую половину книги я прочитал за день и понял, что она мне не нравится. Не нравится тотальное упрощение языка и ультимативная подача инфостиля как лучшего инструмента для информационных коммуникаций. С этими мыслями я отложил книгу отстояться ...

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

#Writing #PublicSpeaking #SelfDevelopment #Presentations

Site Reliability Engineering (Рубрика #SRE)

Fb напомнил мне, что три года назад я постил свои впечатления после прочтения книги "Site Reliability Engineering. Надежность и безотказность как в Google".
Тогда книга определенно понравилась, но есть нюанс ... Нюанс заключается в том, что название SRE в головах людей получило коннотацию Devops, что в принципе неплохо, но ... у кого из знакомых разработчиков я не справшивал читали ли они эту книгу, то получал ответ в стиле "Нет, это вроде что-то для devops'ов"🙂 А на самом деле книга определенно хороша и ряд глав стоит прочесть разработчикам в первую очередь.

Структура книги довольна проста и состоит из 5 частей:
1) Введение
2) Принципы
3) Практики
4) Управление
5) Выводы

В введении кратко описывается содержание книги, а вот уже в принципах начинается интересное и рассматриваются вопросы, касающиеся:
- менеджмента рисков (глава 3)
- определения качества обслуживание сервиса aka SLO, SLA, SLI (глава 4)
- избавления от рутины (глава 5)
- мониторинга распределенных систем (глава 6)
- технологий выпуска ПО (глава 😎 - эту главу рекомендую разработчикам
- простоты (глава 9) - эту главу рекомендую разработчикам

В части, касающейся практик, приводится порядка 20 глав, среди которых особо важны для разработчиков главы касающиеся:
- тестирования надежности систем (глава 17)
- балансировки нагрузки на уровне фронтенда (глава 19)
- балансировки нагрузки в датацентрах (глава 20)
- способах борьбы с перегрузками (глава 21)
- способах борьбы с каскадными сбоями (глава 22)
- разрешениях конфликтов в распределенных системах и достижения консенсуса (глава 23)
- распределенный cron (глава 24)
- конвейеры обработки данных (глава 25)
- сохранность данных (глава 26)

В части про управление расказано о некоторых вопросах менеджмента команд SRE. А в последней части, называющейся "Выводы" проводятся параллели между разработкой ПО в Google и разработкой mission critical систем в авиастроении, кораблестроении, атомной энергетике и т.д.

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

#SRE #Software #SystemDesign #Architecture #SoftwareArchitecture

Defense Industrial Base Guide: Detecting Agile BS - интересный 5-страничный гайд от министерства обороны США, посвященный теме распознавания Agile Bullshit, когда гибкие подходы только декларируются, но не имеют отношения к реальности:) Он был написан в 2018 году, но до сих пор актуален.

Вот, например, как трансформированы 4 основные мысли Agile:
1) Individuals and interactions over processes and tools -> “Competence trumps process”
2) Working software over comprehensive documentation -> “Minimize time from program launch to deployment of simplest useful functionality”
3) Customer collaboration over contract negotiation -> “Adopt a DevSecOps culture for software systems”
4) Responding to change over following a plan -> “Software programs should start small, be iterative, and build on success ‒ or be terminated quickly”

Дальше в документе указываются некоторые паттерны, которые сразу позволяют понять, что в твоем проекте не все хорошо. Например,
- Nobody on the software development team is talking with and observing the users of the software in action; we mean the actual users of the actual code.
- Continuous feedback from users to the development team (bug reports, users assessments) is not available.
- Meeting requirements is treated as more important than getting something useful into the field as quickly as possible.
- Stakeholders are acting more-or-less autonomously (e.g. ‘it’s not my job.’)
- End users of the software are missing-in-action throughout development
- DevSecOps culture is lacking if manual processes are tolerated when such processes can and should be automated

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

P.S. Сам документ можно изучить здесь - https://bit.ly/AgileBSbyDIB

#Agile #Processes #Software #SoftwareDevelopment

Раньше я успевал читать еще и научно-популярные книги по физике, например, такие как книга Джима Аль-Халили "Парадокс. Девять великих загадок физики", выпущенная в серии New Science. В книге отлично подаются парадоксальные вопросы физики. Но начинает автор с простым математических историй, относящихся к теории вероятности, а именно с Парадокса Монти Холла и парадокса дней рождений. Первый интересен мне тем, что я его услышал первый раз лет в десять от своего тренера по шахматам, который мне периодически подкидывал интересные задачки и методички на развитие когнитивных способностей. Насколько я помню, в детстве мне было сложно понять в чем суть этого парадокса даже с объяснениями тренера. В итоге, я разобрался уже в старших классах школы, когда поизучал немного университетские учебники по теорверу:)
Интерсно, что формулировка парадокса Монти Холла простая, а большинство моих знакомых, впервые услышавших его, отвечают на поставленные вопрос неправильно. Приведу для интереса формулировку прямо в посе
"Представьте, что вы стали участником игры, в которой вам нужно выбрать одну из трёх дверей. За одной из дверей находится автомобиль, за двумя другими дверями — козы. Вы выбираете одну из дверей, например, номер 1, после этого ведущий, который знает, где находится автомобиль, а где — козы, открывает одну из оставшихся дверей, например, номер 3, за которой находится коза. После этого он спрашивает вас — не желаете ли вы изменить свой выбор и выбрать дверь номер 2? Увеличатся ли ваши шансы выиграть автомобиль, если вы примете предложение ведущего и измените свой выбор?"
В общем, если вам интересно, то можете почитать про этот парадокс. А я пойдут дальше, т.к. дальше автор переходит к физическим вопросам, которые включачют:
- парадокс Зенона про Ахилесса и черепаху - бесконечно малые ряды
- Демонов Максвелла и Лапласа - первый про второй закон термодинамики, а второй про теорию хаоса
- парадокс близнецов и парадокс дедушки - первый про специальную и общую теорию относительности, а второй про путешествия во времени
- кота Шредингера - про квантовый мир и переход к макромиру
- парадокс Ольберса и парадокс Ферми - первый про то, почему ночью темно, если звезд так много, а второй про то, где же зеленые человечки, если звезд так много и много планет вокруг них.
Напоследок автор высказывает набор вопросов, которые еще предстоит разгадать.

#PopularScience #Physics

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

#Presentations #PublicSpeaking #Pitching

Просто оху...ное выступление John Ousterhout, профессора CS из Стэнфорда. Одного из создателей скриптового языка tcl, про который мало кто помнит, а также алгоритм консенсуса raft, про который знает большинство, изучавших Distributed Systems.
В этом выступлении он рассказывал про философию Software Design.
Мне особенно понравилась часть про правильный mindset и разрушительных tactical tornados:)
https://youtu.be/bmSAYlu0NcY?t=2040

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

#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign