Code of Leadership 9 - An Elegant Puzzle - System of Engineering Management (часть 1)

Девятый выпуск Code of Leadership посвящен обсуждению крутой книги "An Elegant Puzzle: Systems of Engineering Management", про которую я уже рассказывал. Эту книгу написал Will Larson, технический директор Carta, который до этого работал в Calm, Stripe и Uber. В этой книге автор рассказывает про подходы к engineering management.
Саму книгу я обсуждаю с Eugene Sergueev, senior engineering manager во Flo health, приложении для женского здоровья. У Жени больше 15 лет опыта в индустрии, из которых 7 лет в менеджменте. Он успешно руководил небольшими командами, так и компанией 50+ человек на позиции СТО. Женя любит системный подход к решению проблем, поэтому он и выбрал эту книгу для обсуждения.

В этом выпуске только первая половина обсуждения, так как весь выпуск получился длинной больше трех часов:) А если кратко, то за час мы успели поговорить про книгу в общем и обсудить полностью вторую главу и часть третьей главы книги:
2. Organizations - здесь идет речь про определение размера команд, как оставаться на пути к высокоэффективным командам, как не оптимизировать сверху вниз (часто это работает плохо), как быть продуктивным в быстрорастущих компаниях, как планировать успех
3. Tools - здесь автор рассказывает про системное мышление и упоминает Медоуз с ее "Азбукой системного мышления" (про которую я писал ранее), как быть исполняющим обязанности продакт менеджера, как формлировать vision и strategy, как драйвить технические миграции.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

Why Is My App SLOw? Defining Reliability in Platform Engineering • Jez Humble • YOW! 2023

Крутое выступление от Jez Humble про то, как определять, что проблемы есть у платформы, а не у потребителей, которые ей пользуются. Jez сейчас работает SRE в serverless платформе Google, у которой большое количество клиентов с разным профилем нагрузки, разными показателями latency и так далее. В такой конфигурации есть проблема в отделении проблем клиентских нагрузок от проблем самой платформы. Но ребята в Google справились с этим, используя знания математической статистики. Если формулировать точнее, то цель была такая

A metric that represents the customer experience
- Combinable across projects / cells / regions
- Can be used to detect anomalies affecting multiple customers (likely platform
issues)
- Computationally cheap (high QPS)
- Principle-based

Дальше автор говорит про три столпа reliability:
- Availability - здесь основа в том, чтобы посчитать количество (долю) неуспешных запросов. Ситуация осложняется тем, что есть некая субъективность в ошибках (куча 400х и 500х ошибок, которые задаются самими владельцами пользовательских нагрузок), возможны ошибки из-за нарушенных deadlines, могут просто с ошибками плохо сформированные запросы от клиентов, retries могут усиливать количество ошибок
- Performance - здесь автор говорит про установку P99 latency SLO и создании проберов. Но есть проблемы с зависимостями между нагрузками и тем, что проберы могут быть слишком узкими
- Correctness - здесь есть много тестов и анализ канареечных развертываний, но проблема с тем, что покрытие ограничено

Дальше автор говорит, что можно попробовать построить функцию распределения для пользовательских нагрузок (например, log-normal), а дальше можно представить, что пользовательские нагрузки можно считать стационарными. И следом использовать метод двух сигм и сформулировать гипотезу

Hypothesis:
Self-Similar Workloads Should Have Consistent Performance
Technique Overview:
- Partition workloads into Cohorts ← Approximate Intent via Workload Features
- Build Performance Baselines ← Estimate Distributional Form (e.g. Normal)
- Estimate Likelihood of Delivered Performance ← Test For Stationary
Result:
- Set of Events with Predicted Likelihoods
- Time-series of summary statistics describing concentration of extreme outliers

А дальше стратегия использования в том, чтобы
- Рассчитать z-scores среди нагрузок по кагортам, где z-scores = (observed-workloads - baseline-mean) / baseline-std
- Отслеживать долю нагрузок, у которых z-score ≥ 2 в выбранном временном окне
- Считать, что 2-5% процентов нагрузок с 2𝜎 отклонениями нормой
- Тригерриться, когда этот показатель будет выше 10%

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

P.S.
Мне нравятся материалы Джеза, которые бывают как в печатном виде, так и в виде докладов. Раньше я уже рассказывал про
- Книгу "Accelerate" 2018 года, где Jez выступал в качестве соавтора (подробнее в постах 1, 2, 3)
- Книгу "Continuous Delivery" 2010 года, которая была важной вехой в развитии CI/CD (подробнее в посте)
- Этот же доклад, но на конференции goto в 2023 году
- Доклад Expert Talk: The Current State of Software Engineering"
- Доклад "How to Improve Developer Productivity"

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering #Math #ContinuousDelivery

Infobesity - How to Cope with the Overload of Information • Fabio Nudge • YOW! 2023

Интересный доклад про инфоожирение (или информационное ожирение) от Fabio Nudge, который написал книгу "Digital nudge". Рассказ Фабио состоит из следующих частей
- Автор вспоминает про поведенческую экономику и рекомендует книги "Thinking Fast & Slow", "Predictably Irrational", "Nudge" (а также дополнительно еще три: "Building a Second Brain", "A World Without Email", "Make time")
- Показывает как работают nudges на примере ранжирования поисковых ответов, а также streaks из snapchat, duolingo
- Дискутирует относительно того, чем отличается push от nudges. Тут он показывает тизер сериала "The push" от Netflix, а дальше говорит, что nudge - это когда человек может отказаться от предложения:)
- Потом опять идет отсылка, но уже к книге "Hooked" и моделе trigger -> action -> variable reward -> investment -> trigger -> ...
- И дальше рассказывает про убеждение (persuasion) и принуждение (coercion), которые похожи, но в убеждении это то, чего хотят и то, что нужно людям, а вот в принуждении наоборот
- Как пример автор показывает кусочек выступления сооснователя Duolingo "How to make learning as addictive as social media", а конкретно Фаби показывает часть про streaks
- Ну и потом начинается история про избыточность информации и то, как нас ей заваливает со всех сторон
- Он сравнивает это изобилие с изобилием еды, что нам доступна сейчас. Но наш мозг развивался в условиях недостатка пищи, поэтому когда мы снабжаем его пищей, то он вознаграждает нас за это ... даже если это четвертая шоколадка за день. А это легко приводит к ожирению. Ну а по отношению к информации это приводит к infobesity
- А дальше автор переходит к советам о том, как блюсти цифровую диету и говорит

Being aware of your sources of dopamine and understanding what’s good and bad for you is one of the best tools to fight infobesity.

- Автор рассказывает про проект "Cognitive Loadometer" для измерения когнитивной нагрузки на команды
- Дальше говорит про модель push и pull - смысл в том, что иногда в нас пушат информацию (например, присылают emails), но потреблять информацию удобнее по моделе pull - так мы можем контролировать ситуацию (фильтровать сообщения, потреблять асинхронно, когда нам удобнее, etc)
- Автор показывает как можно использовать фильтры в почте, чтобы отфильтровать только важное (для этого он использует labels и дальше фильтры по булевым выражениям с ними)
- Дальше автор показывает группировку вкладок в Chrome для объединение вкладок по контексту и переключения между ними
- Заканчивается выступление упоминанием BMI (body mass index), который используют как метрику ожирения. А дальше Фабио предлагает пройти опрос и померить свой infobesity вес, заполнив форму в Google forms и прочитав расшифровку результата на сайте книги

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

P.S.
Больше года назад я рассказывал про другой доклад Фабио "The Psychology of UX", который можно считать предысторией к докладу про "Infobesity"

#Conference #PopularScience #Software #UX #Economics #Psychology

Statist — платформа продуктовой аналитики

У нас на tinkoff.ru появилась статья про нашу платформу продуктовой аналитики Statist, которую мы обсуждали с Андреем Цыбиным в выпуске Code of Leadership #8. Собственно статью написал как раз сам Андрей.

Если рассказывать кратко, то Statist
- это единая платформа Тинькофф для сбора продуктовой аналитики и телеметрии с мобильных и веб-приложений
- позволяет собирать, обрабатывать и визуализировать данные как о поведении клиентов, так и о технических деталях работы приложений
- дает возможность отслеживать изменения в продукте, искать инсайты в UX приложений, реагировать на сбои
- позволяет использовать практики data governance, а точнее разметить событиями метаданными и разделить их по клиентским приложениям, их версиям и так далее

В итоге, мы можем принимать решения о развитии продуктов Тинькофф на основе данных, полученных и проанализированных при помощи Statist. Аминь!

#Analytics #Architecture #DistributedSystems

ЦЕХ № 4 от МИФ

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

P.S.
По плану к концу лета у меня должна быть готова как минимум одна книга:)

#Writing #SelfDevelopment

Patterns of Distributed Systems • Unmesh Joshi & James Lewis • GOTO 2024

Крутое интервью Unmesh Joshi, автора книги "Patterns of Distributed Systems". Расшифровка доступна здесь. Общение состоит из следующих моментов
- Unraveling the Foundations: A Patterns-Based Exploration
Автор книги рассказывает про свой путь как инженера и как он дошел до жизни такой, что написал книгу про паттерны распределенных систем. Мне особенно понравилось как Unmesh рассказывает про изучение реальных распределенных систем (Akka, Kafka, Cassandra, ...), в которых автор находил практические реализации тех концепций, что обычно описаны в whitepapers. Например, в интервью обсуждается часы Лампорта и whitepapers Барбары Лисков (ее принцип отвечает за букву L в акрониме SOLID). В общем, я бы сам с удовольствием поковырялся в реальных технологиях и попробовал сравнить как теоретические концепции реализуются на практике в разных системах и на какие trade-offs идут авторы этих систем
- Should Every Software Developer Should Understand Distributed Systems?
В общем, ответ да:) Но точка зрения зависит от контекста. Условные микросервисы - это тоже распределенная система. Но фокус автора книги был на данных и поддержании их консистентности на многих серверах и он фокусировался на работе систем аля Kafka, Cassandra, Amazon S3, Cosmos DB.
- Comparing Patterns: Raft and Paxos
Здесь ребята обсуждают модели консенсуса - они говорят про
1) Paxos, который предложил уже упоминавшийся Лампорт
2) Raft, одним из соавторов которого был Джон Остерхут, чью книгу "A Philosophy of Software Design" я уже рассказывал в постах: 1 и 2
Тут авторы вспоминают про CAP теорему (я про нее рассказывал), не вспоминают про ее расшширение в виде PACELC (я про нее рассказывал), вспоминают Jepsen с его тестированием гарантий производителей баз данных и проверкой их соответстия моделям консистентности (про них я тоже рассказывал). В обсуждении они говорят про время и вспоминают про TrueTime от Google и гибридные часы в MongoDB, YugabyteDB и CockroachDB.
- Why Are Patterns Useful?
Пользу от паттернов лучше описать словами автора книги

One of the goals for these patterns work as well is that someone reading this material should be able to navigate open-source code bases. And I think navigating, I mean, following open-source products and going through their code bases, trying out, maybe isolating some pieces of it and playing with it, I think that's a great way to learn about distribution. I mean, particularly topics like distributed systems, it's a great way to learn because if you go down the route of theoretical understanding, I mean, there are a lot of nice books, I would say, but you might get lost. So I think it helps a lot to remain closer to code while you are learning stuff.

- Conclusion
Напоследок ребята подводят итоги и James пытается выяснить творческие планы у Unmesh, который планирует продолжать работу над паттернами, а также начать проводить воркшопы на эти темы. Думаю, что я бы на такой воркшоп бы записался:) Ну и обязательно прочту эту книгу - автор мне ее продал в этом интервью.

#Software #Architecture #DistributedSystems #SystemDesign #Patterns #Engineering

Node.js: The Documentary | An origin story

Вчера на канале Honeypot вышел часовой документальный фильм про историю создания Node.js.

История начинается в 2008 году, когда javascript был технологий для написания кода на фронте и исполнения его в браузере. Но потом появился движок Google V8 и Ryan Dahl соединил идею неблокирующих сервисов, javascript и запуска этого в V8. Так появился Node.js. Он рос и развивался под руководством Ryan, но в какой-то момент Joyent Inc решило предложить Ryan денег и выкупить права на trademark Node.js, а также начать руководить этим open source проектом. Ryan согласился и успешно проработал в компании Joyent пока у него не завестились все обещанные плюшки, а потом он передал проект Isaac Schlueter, который когда-то создал npm, менеджер пакетов для Node.js. Дальше эта история закрутилась и привела к ситуации, когда community из ранних контрибьюторов node.js решило форкнуть проект, чтобы развивать его параллельно Joyent ... А как закончилась эта история вы узнаете из самого фильма:)

P.S.
Это интересная история про динамику взаимоотношений внутри open source проектов. Зачастую сложно обеспечить баланс между желаниями core контрибьюторов, запросами community, а также компанией, из которой вышел open source продукт или которая его купила на ранней стадии. В итоге, при неаккуратном развитии событий легко словить split brain и получить вместо единства кучу отдельных форков, что эффективно приводит к падению популярности технологии и скорости инноваций в mainline технологии (так как инновации теперь кусочно распределены между форками).

#OpenSource #Management #Leadership #Engineering #Software

Understanding Statistics and Experimental Design. How to Not Lie With Statistics (Статистика и планирование эксперимента для непосвященных)

Эта книга подойдет даже новичкам - авторы отлично постарались, чтобы донести основы статистики максимально просто, с минимумом формул и максимумом смысла. Если вы когда-то слышали магические слова навроде a/b тесты, статзначимость, t-критерий, p-value и хотели понять что именно это значит, то эта книга для вас. Если вы знаете теорвер, матстаты, матанализ, то вам будет проще следить за мыслью авторов, но даже без этого эта книга позволит вам начать чувствовать bullshit, который иногда показывают под видом отличного эксперимента. В общем, в эпоху повсеметного data-driven эта книга всего в 150+ страниц очень хороша:) Она доступна бесплатно на сайте издательства Springer.

Сама книга состоит из 3 частей и 12 глав
I - Принципы статистики - эта часть must read для людей, что используют статистику для принятия решений
1 - Основы теории вероятностей - авторы говорят про вероятность, распределение вероятностей, условную вероятность и концепцию независимых событий. Дальше рассматривается вариант анализа на некоторую болезнь и дальше вводятся термины чувствительность (sensivity), специфичность (specificity), частота ложноположительных результатов (false positive rate) и частота ложноотрицательных результатов (miss rate). Дальше автор показывает как это все работает вместе и почему даже врачи не всегда понимают статистику:)
2 - Планирование эксперимента и основы статистики: теория обнаружения сигналов - авторы идут от signal detection theory и на примере желтой подводной лодки и эхолокаторов показывают как выглядит дизайн эксперимента и принятие решения. По-факту, у нас есть различимость сигнала и шума, а также некоторый порог принятия решений. В итоге, процент верных решений смешивает их вместе. Этот вывод дальше авторы показывают в части про t-критерий, где размер эффекта смешан с размером выборки:)
3 - Главная концепция статистики - здесь авторы рассказывает про канонический подход к статистике, обсуждают статистику для выборочного среднего, а дальше показывают как можно сравнивать выборочные средние при помощи одностороннего и двухстороннего t-критерия. Дальше авторы показывают, что в стандартном тесте p-value контролирует частоту ошибок первого типа или false positive, когда мы находим эффект, а его нет. Еще интереснее обсуждение рассчета мощности эксперимента, который говорит про вероятность получить значимый результат, если альтернативная гипотеза верна (то есть средние в наших совокупностях отличаются). Концепция мощности нужна в дальнейших главах, особенно в третей части книги. А вообще самая сочная часть этой главы - это следствия в конце, которые напрямую влияют на дизайн экспериментов и говорят про размер выборки, размер эффекта, нулевые результаты и так далее
4 - Вариации на тему t-критерия - это глава со звездочкой относительно третей главы, где рассматривался обычный t-критерий

II - Множественная проверка гипотез - очень интересная часть, про то, насколько сложно задизайнить правильный эксперимент с множественной проверкой гипотез
5 - Задача множественной проверки гипотез
6 - Дисперсионный анализ (ANOVA)
7 - Планирование эксперимента: подгонка модели, мощность и сложные планы - очень важная глава для практика-экспериментатора, где авторы делятся правильной методикой и показывают на примере как можно отстрелить себе обе ноги и не только
8 - Корреляции - сравнение t-критерия, ANOVA и стандартной истории с поиском корреляций между относительными переменными (в ANOVA у нас независимые переменные номинальные)

III - Метаанализ и кризис науки - эту часть интересно прочитать ученым и тем, кто любит читать статьи английских ученых:) Тут авторы на пальцах показывают как в погоне за результатами авторы исследований публикуют слишком хорошие результаты, чтобы они были правдой:)
9 - Метаанализ
10 - Воспроизводимость
11 - Величины избыточного успеха
12 - Предлагаемые улучшения и нерешенные проблемы

#Math #Statistics #PopularScience #Science #ML #Data

Code of Leadership #10 - An Elegant Puzzle - System of Engineering Management (часть 2)

В десятом выпуске Code of Leadership заканчивается обсуждение крутой книги "An Elegant Puzzle: Systems of Engineering Management" (начало в выпуске 9), про которую я уже рассказывал. Эту книгу написал Will Larson, технический директор Carta, который до этого работал в Calm, Stripe и Uber. В этой книге автор рассказывает про подходы к engineering management.
Книгу мы продолжаем разбирать с Eugene Sergueev, senior engineering manager во Flo health, приложении для женского здоровья. У Жени больше 15 лет опыта в индустрии, из которых 7 лет в менеджменте. Он успешно руководил небольшими командами, так и компанией 50+ человек на позиции СТО. Женя любит системный подход к решению проблем, поэтому он и выбрал эту книгу для обсуждения.

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

3. Tools - как проводить инженерную реорганизацию (и стоит ли это вообще делать), как формировать свои карьерные нарративы, как подходить к продвижению сложных тем без формального authority с использование подхода model-document-share, как делать презентации топ-менеджменту и управлять своим временем
4. Approaches - как не погрязнуть в управлении исключениями к собственным policies, как говорить нет, формулировать свою философию менеджмента, как понимать где у engineering managers возникают проблемы, как быть в партнерских отношениях со своим менеджером, находить себе зону ответственности и устанавливать направление развития организации
5. Culture - как формировать культуру инклюзивной организации с использованием возможностей и membership, как выбирать лидов проектов, делать своих peers первой командой, как балансировать positive и negative freedoms в культуре компании, отказаться от культуры героев в пользу устойчивого роста
6. Careers - как выстраивать процесс интервью, как проводить холодный sourcing, работать над воронкой найма, использовать performance management для развития уже нанятых сотрудников через понятные карьерные лестницы, как создавать специализированные роли вроде SRE или TPM (technical product manager), как проектировать циклы собеседований для желаемых позиций
7. Appendix - как оперировать в растущей оранизации: на уровне линейного менеджмента, уровне middle management и дальше менеджмента всей организации, а напоследок автор приводит список книг и white papers по интересным для него темам

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

Developer Joy – How great teams get s%*t done - Sven Peters - NDC Porto 2023 - Part I

Интересное выступление от Sven Peters из Atlassian на тему developer productivity, developer experience и developer joy:)
Автор начинает с того, что возвращается в прошлое и вспоминает про Тейлора и его научный подход к менеджменту на заводе. Правда, там выполнялась однотипная работа на конвейере, но за счет измерения времени выполнения разных активностей Тейлор смог оптимизируя инструменты, время на отдых и другие вещи повысить эффективность завода в разы. Но сейчас в информационный век многие хотят научиться также повышать эффективность разработки, но разработка сейчас достаточно сложна и software development engineer должен уметь работать над quality, работать в облаке, деплоить и эксплатировать свое решение (you build it, you run it). Я говорил про эту же проблему в своем подкасте "Software development engineers в tech компаниях". Но автор предлагает уйти от термина developer productivity к developer joy и разобраться с тем, что делает работу разработчиков приятной и продуктивной и туда попадает
- Dev quality - качество кодовой базы, архитектуры, отсутствие техдолга
- Dev progress - темп разработки и поставки фичей
- Dev value - какую пользу приносят поставленные фичи
Автор рассказывает на примерах из разных команд
- Команда Jira написала code of conduct для проведения ревью кода
- Команда Confluence, которая написала инструмент для поиска нестабильных (флакающих) тестов во время прогонов
- Команда Confluence написала бота для пушинга участвующих в code review - это уменьшило среднее время ревью PR с 3 дней до 1.2 дня

Дальше автор рассказывает про зависимости между командами, что тормозят разработку. Он делает это на примере того, как разные развязки на дорогах влияют на пропускную способность шоссе. Когда мы делаем нормальные развязки, которые позволяют машинам не мешать друг другу, то мы получаем максимальный traffic flow. Этим автор обосновывает стремление к автономным командам. А дальше он рассказывает про команду Trello, где на 1 qa инженера приходится 30 software development engineer. В итоге, сами sde забирают на себя большую часть стандартных функций qa-инженеров, а потому не ждут пока qa-инженеры протестируют их фичи. Плюс автор рассказывает про подход с блиц тестированием, когда вся команда тестирует критически важную функцию. Забавно, что оставшиеся qa-инженеры отвечают за qa-тулинг, тестовые данные, базы и так далее.

Продолжается история тем, что разработчикам надо понимать dev value
- Инженеры (sde) и продакт менеджеры должны работать вместе над одним и тем же делом
- Инженеры (sde) должны быть вовлечены в процесс создания и понимать проблему, которую нужно решить
- Стоит использовать демо, которые важны для всех команд, они помогают увидеть результат и ценность, которую создают для клиентов

Дальше идет речь про измерение производительности и улучшение показателей
- Как помним еще Тейлор говорил о важности измерения производительности труда
- Если у вас ничего нет, то стоит начать с метрик DORA
- А дальше стоит начать использовать свой собственный инструмент для базовых показателей отслеживания прогресса
- Раньше в офисах раньше были настенные панели и телевизоры, на которых можно было видеть состояние сборки и тестов.
- Сейчас используются проверки, которые помогают определить проблемы и улучшить показатели.

Автор рекомендует использовать разметку задач и оценивать время, которое команда тратит
- На change бизнеса
- На keep the lights on (поддержание работы)
- На поддержание эффективности разработки и улучшение developer productivity

Developer Joy – How great teams get s%*t done - Sven Peters - NDC Porto 2023 - Part II

Начало обзора этого выступления есть в первом посте. А здесь надо еще расскаать про использование регулярных опросов разработчиков, чтобы узнать их мнение о различных аспектах работы. Результаты опроса помогают определить области, требующие улучшения и обсудить их с командой. В Atlassian команды используют 10% времени для исправления ошибок и улучшения производительности разработчиков. Некоторые команды проводят "week of developer joy", а другие включают планирование в спринт и работают над проблемами производительности. А также команды распространяют знания и делятся с коллегами полученными выводами - например, команда создала пост в блоге о своем решении проблемы и его использовании в других командах.

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

P.S.
На похожую тему я размышлял в постах про developer productivity: 1, 2 и 3.

#Processes #Management #Performance #Engineering #Software #SoftwareDevelopment #Leadership

ЦЕХ 4 - Урок #1 "Увидеть свое имя на обложке может каждый"

На прошлой неделе прошел первый вводный урок курса для начинающих авторов, что планируют написать и издать книгу:) Этот урок напоминал самосбывающее пророчество, которое должно было вдохновить участников и вселить в них уверенность в своих силах. Екатерина Звонцова и Ренат Шагабутдинов одновременно рассказывали и про non-fiction и про художественную литературу. Были рассмотрены следующие темы

1) Как начать писать книгу - авторы блогов и статей могут начать собирать книгу из своих материалов уже опубликованных в блоге (я так и планирую сделать). Но даже если у вас нет блога, но есть соцсети, то можно поискать в своих постах материалы для старта, чтобы не сталкиваться с эффектом пустой страницы. Если мы говорим про художественную книгу, то начинать стоит когда в голову пришла идея сюжета или персонажей, которыми вы хотите поделиться с другими или поднять важную проблему. Но тут важно выбирать персонажей и тему, которая интересна как вам, так и читателю.
2) Зачем писать книгу - написание книги может помочь структурировать мысли, поделиться опытом, передать свою философию (примерно поэтому я пишу статьи и хочу написать книгу). Отдельно эксперты курса отмечают, что написание книги может быть способом стать экспертом в своей области и повысить свой статус. Но тут важно разбираться в теме, которую вы исследуете, чтобы лучше ее преподнести другим. А вот художественные книги могут помочь автору осмыслить свой опыт и преподнести его так, чтобы он обладал терапевтическим эффектом для читателей, которые тоже переживают сложный период
3) Написание книги позволяет научиться чему-то новому и творческому - через творчество автор может узнать что-то новое и интересное, а также это может быть способом общения с миром. Это может помочь найти своих единомышленников и сформировать сообщество вокруг себя.
4) Про успех - даже если успех приходит к автору, то не стоит ожидать мгновенных результатов. Важно продолжать работать над своими навыками и повышать свои шансы на успех. Часто здесь работает подход накопления авторитета - сначала автор работает на зачетку, которая затем работает на автора:) Факторами успеха могут быть: экспертиза, платформа, харизма, начитанность, структурированность текста, юмор, примеры, иллюстрации. Классно, если случается вирусный эффект: сарафанное радио, рекомендации книги другим. Иногда визуальное оформление и обложка книги тоже влияет на успех книги.
5) Самозванец и критик - Эксперты рассказывают про то, что с ростом знания темы растет осознание того, как много еще не известно. Поэтому даже у экспертов есть синдром самозванца (правда, эксперты умеют его преодолевать). Другая история основана на "проклятии знания", когда экспертам сложно передавать свои знания, так как для них все очевидно и не ясно зачем разжевывать материал (а всем остальным почти ничего не ясно).
6) Страхи и сомнения начинающих авторов - здесь эксперты говоят о том, что даже если вы не являетесь "небожителем", вы все равно можете добиться успеха, если будете развиваться и двигаться вперед. Причем если вы уже задумываетесь о проблемах и осознаете их, то вы уже на правильном пути.
7) Уникальность темы книги - есть мнение, что все уже написано до нас ... Но всегда можно найти свое и написать уникальную книгу на стыке двух тем, которые могут быть обычны и тривиальны. Кроме того, можно написать книгу под конкретных читателей, которые могут быть разными по уровню знаний и интересам. В общем, наличие уже написанных книг на выбранныю тему - это не приговор, а скорее хороший знак - люди интересуются этой темой:)

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

#Writing #SelfDevelopment #Management