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

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

Продолжая предыдущий пост, рассказываю про содержание первого урока по написанию книги
😍 Установка на работу над текстом - даже если текст не получается не совсем идеальным, то над ним надо работать системно и исправлять недостатки и постепенно улучшать.
9) Внутренняя опора и важность текста для автора - автору важно осозновать, что этот текст нужен ему самому, а не только является внешним проявлениям успеха. В этом случае у автора будет внутренняя опора и понимание того, зачем он занимается творчеством, а это может помочь преодолеть трудности и продолжить писать.
10) Публичность автора - публичность автора может помочь в продвижении книги, но это не обязательный критерий. Автору важно выбрать уровень публичности, который ему комфортен.
11) Процесс работы над книгой - тут важна системность и движение маленькими шагами, которые приближают к большой цели. Важно не думать постоянно про большую цель в виде конечной книги - это может демотивировать. А вот за достижение ежедневных результатов можно себя и похвалить:) Тут, кстати, хорошо работает концепция streaks, про которую рассказывал автор доклада "Infobesity" (подробнее здесь)
12) Планирование и систематизация информации - этот процесс может быть поначалу сложным, но можно воспользоваться подходами типа Zettelkasten (я как-то сделал обзор этой книги). Также можно использовать mindmaps для структурирования информации и поиска связей между различными уровнями книги.
13) Планирование и сюжетные точки книги - этот пункт важен при написании художественных книг и там надо ответить на четыре базовых вопроса для определения идеи книги: кто, где, что и кто мешает. Также важно понимать основные сюжетные точки: экспозиция, завязка, развитие действия, кульминация и развязка, для облегчения процесса написания. Эти знания помогут сориентироваться в процессе написания и будут полезны для всех авторов, независимо от их опыта.
14) Самотивация и эмоции при работе над книгой - для самомотивации можно представить, что книга уже напечатана и находится в руках, и поделиться позитивными эмоциями, которые это вызывает. Однако, когда книга уже будет напечатана, то важно помнить, что внешние факторы, такие как продажи и отзывы, не всегда отражают качество книги. Поэтому если продажи идут не так как вы представляли, то не стоит опускать руки. Важно спокойно относиться к критике и продолжать работать над своими навыками написания хорошего текста.

#Writing #SelfDevelopment #Management

Architecture Modernization: Aligning Software, Strategy, and Structure - Nick Tune

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

Architecture Modernization is about converting architecture from a competitive disadvantage to a competitive advantage.

И дальше его подход содержит три пункта
1) Architecting for flow - проектирование для улучшения потока создания ценности и взаимосвязи изменений
2) 5 Essential tools for architecture modernization - инструменты для модернизации архитектуры
3) Kickstarting and enabling architecture modernization - как начать модернизацию

В первой части автор говорит про stream-aligned команды из team topologies, которые формируют вокруг value-stream. Отдельно надо отметить, что иногда между системами команд бывают зависимости, которые влияют на flow. Поэтому все и мечтают создавать автономные команды (про это было много в докладе, о котором я рассказывал вчера):)

Дальше спикер говорит про fullstack модернизацию по всем уровням

- User interface - modernize the UI to enable a better UX improving user happiness and productivity
- Software - modernize tech and alignment to domain model for code that is easier to understand and evolve.
- Domain model (conceptual) - modernize the conceptual domain model, creating a better shared understanding and language improving collaboration & innovation
- Domain - modernize the domain by adding new and better capabilities which create new business and customer value.

Дальше речь идет про инструменты:
1) Активное слушание - оно помогает понять бизнес-цели и проблемы заинтересованных сторон
2) Impact mapping - в этом подходе создается связка: strategic business objectives - actor - impact - deliverables. Подробнее можно почитать в книге "Impact mapping", про которую я писал раньше
3) Wardley mapping - здесь компоненты архитектуры связаны с цепочкой создания ценности, а также стадиями жизненного цикла продукта. Интересная концепция, про которую я узнал впервые и которую можно использовать для определения текущего состояния и эволюции компонентов архитектуры.
4) Event storming - это интересный подход lkz проведения воркшопов для коллаборативного изучения сложного бизнес домена ... Подробнее можно прочитать в моем посте
5) Modernization strategy selector - график для обсуждения вариантов модернизации через раскладывание по осям platform modernization и product, domain, software modernization
В конце перечисления автор еще вспоминает CodeScene - инструмент для поведенческого анализа кода.

Дальше автор рассказывает, а с чего стоит начать модернизацию и показывает матрицу 2x2 (риски - эффект). В итоге, у нас есть
1) "низковисящие фрукты" (риск небольшой, а эффект значительный)
2) проекты, для тех, кто уклоняется от риска (риск и эффекты незначительные)
3) проекты, для тех, кто готов к большим ставкам (риски и эффекты большие)
4) "последняя паста в тюбике" (рисковые проекты с низким эффектом) - такими часто вообще не занимаются никогда:)

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

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

Dune (Дюна)

Побывал на прошлой недели на второй части фильма, что снял Дени Вильнёв. Фильм мне понравился своими визуальными эффектами, где планета Арракис выглядит как настоящая, актеры отлично отыгрывают персонажей, в кадре есть динамика и развитие событий. Но если бы я не знал первоисточник в виде книг Фрэнка Герберта, то мне было бы сложно понимать все хитросплетения происходящих событий. Поэтому я рекомендую помимо просмотра фильма почитать и книги:
- Дюна - первая книга цикла, которая получила премию Хьюго в 1966 и в этом же году премию Небьюла. По этой книге сняты первые две части фильма Дени Вильнёва
- Мессия Дюны - предположительно эта книга будет основой сюжета для третьей части фильма (если он будет)
- Дети Дюны и остальные книги цикла - я эти книги в детстве прочесть уже не успел, но если Дени продолжит снимать Дюну, то придется ознакомиться с этим текстами

P.S.
Ну и рекомендую сходить на Дюну в кино, так как этот фильм стоит того, чтобы увидеть его на больших экранах:)

#SciFi

Code of leadership #11 - Интервью про системных аналитиков в Тинькофф

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

- Информация про системных аналитиков в Тинькофф доступна здесь
- Информация про приближающийся one day offer системных аналитиков в Тинькофф доступна здесь

Список рекомендованных Кириллом книг:
- Ричардс М. , Форд Н. "Фундаментальный подход к программной архитектуре: паттерны, свойства, проверенные методы"
- Форд Н. , Ричардс М. , Садаладж П., Дехгани Ж. "Современный подход к программной архитектуре: сложные компромиссы"
- Ousterhout, John. "A Philosophy of Software Design"
- Влад Хононов. Изучаем DDD

Интересно, что все эти книги мы разбирали в подкасте Code of Architecture
- Обзор книги "Fundamentals of Software Architecture"
- Code of Architecture — Recap of "Software Architecture: The Hard Parts"
- Книжный клуб CoA — "A Philosophy of Software Design"
- Изучаем DDD – предметно-ориентированное проектирование

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

P.S.
Подкаст доступен в аудиоверсии на Я.Музыке.

#Career #SystemDesign #Software #SoftwareArchitecture #Architecture #Engineering #Analyst

Ex-technology companies

Интересный пост от Will Larson, который поднимает вопрос, а каким критериям должна удовлетворять компания, чтобы считаться технологической. И что бывает с компанией, когда она перестает удовлетворять этим критериям. Will Larson выделяет два критерия:
- Предельная стоимость обслуживания дополнительного пользователя стремится к нулю - тут отсылка к статье Ben Thompson’s “Software has zero marginal costs”. Если это так, то рост пользовательской базы позволяет большие косты в перспективе распределить по большой пользовательской базе и получить хорошую маржинальность. Если инвесторы верят в эту оценку предельной стоимости обслуживания, то они оценивают компанию в 2-3 раза выше, чем нетехнологическую:)
- Инженеры влият на стратегические решения компании - здесь автор отсылает к мнению Camille Fournier, которая написала крутую книгу "The Manager's Path", про которую я рассказывал в четырех частях: pre-manager, engineering managers, engineering directors и senior leaders. Отдельно на эту тему рекомендую почитать книгу "A Seat at the Table", про которую я рассказывал раньше
Я согласен с мнением Will и тоже считаю, что эти два критерия достаточно точно разделяют tech и non-tech компании.

Ну а дальше в статье автор рассказывает про то, как меняется характер работы в компаниях, которые перестают быть технологическими. Это может быть из-за разных, например
- если инвесторы перестают верить в оценку предельной стоимости обслуживания клиентов и делают переоценку стоимости компании вместо 10xот revenue до 2x от revenue
- если технологические лидеры теряют место за столом топов и к власти приходят условные финансисты, что просто срезают траты на RnD и технологическое развитие, что приводит к тому, что косты на поддержку и развитие IDP (internal developer platform) до неподъемным для команд, которые подверглись сокращениям
А дальше автор вспоминает свой опыт работы в Digg, где acquihire привело к сокращению инженерных команд и тому, что старая инфра и архитектура, рассчитанная на 50 инженеров перестала соответствовать тому, что нужно было для оставшегося десятка инженеров.

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

Ask yourself is whether R&D at your company can significantly change your company’s financial profile over the next three years

Если ответ да, то значит вы еще в игре и ваша компания все еще технологическая:) Даже если у компании сейчас сложный момент, то за счет технологий она может выйти из него.
Ну и если подвести итоги, то в технологических компаниях технологии - это драйвер роста, а в нетехнологических компаниях - это центр затрат:)

P.S.
Отдельно отмечу, что у нас был крутой новогодний выпуск, где мы обсуждали гибридный подход к RnD и гостями были
- Игорь Маслов, руководитель управления базовых технологий и обработки данных Тинькофф
- Станислав Моисеев, директор инженерных исследований в Тинькофф
А также я в прошлом году рассказывал доклад "Как RnD появляется в крупных IТ-компаниях" на Techlead Conf.

#Management #Leadership #Engineering #RnD

Яндекс.Дзен. Как создать свой блог и сделать его популярным

Вчера решил почитать книгу от Анны Денисовой про то, как вести блог на Дзене (книга была написана еще в те времена, когда он принадлежал Яндексу).
Не скажу, что я узнал что-то новое про создание блога, но не могу не отметить хорошую структуру книги
- Введение - обсуждение мотивации становления блоггером (и заодно темы монетизации)
- Обсуждение концепции блога - обсуждение целевой аудитории и темы, о которой автор сможет писать тексты
- Форматы Дзена, которые доступны для публикации - статьи, видео, истории, etc
- Создание контент плана по выпуску материалов - план того, что и когда вы опубликуете в своем блоге
- Написание статьи - здесь автор говорит про тему статьи и ее небанальность, структуру, яркость, call to action в статье и так далее
- Подготовка статьи к публикации - здесь обсуждается оформление статьи - создание заголовков, краткого описания, изображения для обложки, выставления тегов и т.д.
- Создание иллюстраций для статей - базовый рассказ про поиск фотографий, снять самому, а также адаптировать их в статье
- Съемка видео - похожие советы как те, что были для фото
- Статистика - как проанализировать метрики вашего блога через интерфейс редактора и используя данные Метрики
- Монетизация - рассказ о том, как начать зарабатывать на блоге
- Повышение популярности блога - здесь речь про программу поддежки авторов, продвижение статьи, коллаборации с другими авторами и т.д.
- Психология блогерства - автор разбирает стандартные проблемы: хейтеров, неудовлетворенность заработком, непредсказуемость показателей, выгорание и обманутые ожидания в том, что быть блогером легко
- Полезные материалы - здесь автор дает ссылки на полезные для блогеров сервисы, а также делится чеклистами: чеклист хорошей статьи, рекламной статьи, плана развития нового канала

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

#Writing #SelfDevelopment

ЦЕХ 4 - Урок #2 "Целевая аудитория и ее потребности в создании книги. Эксперт — Ольга Архипова"

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

Ниже основные моменты, что я вынес с этого урока
1) Целевая аудитория - это люди с определенными характеристиками, которые могут быть заинтересованы в книге. При создании книги стоит думать про них, чтобы точнее откалибровать наши желания о том, что мы хотим рассказать и потребности аудитории, которые возможно захотят прочитать нашу книгу.
2) Критерии для определения аудитории - можно рассматривать разные факторы, например, стиль жизни, ценности, восприимчивость к цене, скорость чтения книг, доступность информации о продукте. Это влияет на параметры книги: оформление обложки, качества текста и бумаги, доступности ее в книжных магазинах и маркетплейсах
3) Сегментация аудитории - нам важно сегментировать аудиторию, чтобы понимать широту сегмента (потенциальный спрос на книгу), а также то, какие ожидания у этого сегмента. Причем мы можем смотреть на параметры, характерные для группы покупателей (возраст, пол, семья, статус, стиль жизни) и параметры, основанные на искомых выгодах. Для оценок параметров аудитории мы можем использовать разные источники: статистику по населению РФ, данные по книжному рынку, ...
4) Сегментация с использование эмоциональных, функциональных, истинных потребностей - более глубокий подход к сегментации, где мы идем от
— Эмоциональных потребностей: положительных (радость, счастье, вдохновение, мотивация) и отрицательных (обида, страх, вина, стыд, подавленность)
— Функциональных потребностей, например, изучение нового языка, чтение для саморазвития, прокачка навыков или даже книги как предмета интерьера
5) Книжная пирамида по уровням потребностей - ее можно разложить на три уровня: низ, середина и верх. Внизу пирамиды находятся книги с простыми названиями и простым содержанием, в середине - более специализированные книги, а вверху - узкоспециализированные книги для специалистов. Это пересекается с пирамидой Маслоу. Используя эту пирамиду, можно описать потребителей
— Низ пирамиды: потребители, которые мечтают научиться чему-то, но не готовы долго концентрироваться на контенте.
— Середина пирамиды: читатели, которые уже что-то приобрели и хотят развиваться в определенной области.
— Верх пирамиды: читатели, которые уже прокачались и готовы платить больше за уникальный контент.
6) Упаковка книги для каждого уровня - каждый уровень требует собственной обложки: для низа пирамиды нужны яркие, выделяющиеся обложки, простые названия, для середины - более сложные названия, метафоры, образы, а для верха - профессиональные названия, сложные названия, метафоры.
7) Пирамида для художественной литературы - в художественной литературе также есть пирамида потребностей, но она определяется жанром и построением сюжета. Но основная цель все-таки быть понятной для целевой аудитории, а также выделяться на фоне конкурентов. В художественной литературе читатель примеряет себя к описанным ситуациям, узнает себя в них, а дальше безопасно их переживает.
8) Глубинные потребности читателей - эксперт описывает как хороший консультант может постараться глубинную потребность покупателя, не удовлетворившись дежурным ответом. Интересно, что меня, например, консультанты в книжных обычно только раздражают:)
9) Зачем думать про ЦА и маркетинг до написания книги - для того, чтобы написать хорошую книгу хорошо бы понимать для кого мы ее пишем и насколько она подходит этой ЦА. Конечно можно сначала написать книгу, а потом думать кому она нужна, но это может привести к грустному ответу, что "никому":)
10) Маркетинг, воронка продаж, медиаплан - эксперт рассказывает базовую историю про маркетинг, которую можно почерпнуть изучив марткениг микс (4P): product, price, place (distribution) и promotion

#Writing #SelfDevelopment #Management

Обучение детей программированию

Недавно обсуждал тему обучения детей программированию и решил вспомнить как я к этому подходил со своим старшим сыном Пашей, который так и не стал программистом, а решил пойти в геймдизайн:) Собственно, я лет 10 назад ориентировался на такие проекты как Scratch и Lego Mindstorm
— Scratch - это проект MIT, который представляет собой визуальный язык программирования и web IDE для разработки. Это очень крутая история, которая позволяет малышами проявить свой креатив и буквально сразу делать интересные проекты:) Идейный вдохновитель проекта, Митчел Резник, написал отличную книгу "Спираль обучения" ("Lifelong kindergarten"), в которой он рассказывает про развитие подходов к креативности и встраивание их в цикл обучения. У меня есть краткое саммари этой книги. Мой сын пробовал собирать проекты в этом IDE, используя пару книг, что есть на Озоне, но ему это особо не заходило, поэтому он бросил (тут есть отчасти моя "заслуга", так как я с этим не сильно помогал)
— Lego Mindstorm - это крутой проект от Lego, где до появления всяких "малинок" (raspberry pi и иже с ними) ребенок мог попробовать робототехнику в привычном формате с кубиками лего, центральным блоком с процессором и кучей входов для подключения датчиков, моторов и остальной машинерии. В итоге, малыш мог собрать своего робота, научить его видеть, подключив сенсор с камерой, чувствовать, подключив датчик касания, добавить ему чувство равновесия за счет датчика с гироскопом и так далее. В эту штуку мой сын играл с удовольствием, но только до момента окончания сбора робота, а вот писать софт для него и программировать в IDE аля Scratch ему не нравилось и он подключал папу.

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

P.S.
На тему игр и геймдизайна у меня уже были раньше посты
— The Making of Prince of Persia
- Геймдзайн (Designing games. A guide to engineering experiences)
- Minecraft: Мобиология (Minecraft: Mobestiary)
- Кровь, пот и пиксели (Blood, sweat and pixels)
- Настольная игра "Нефариус"
- Настольная игра "Корпорация Гоблинов" (Goblins Inc)
- Прогейминг, Overwatch, киберспорт (Young guns: obsession, owerwatch, and the future of gaming)
- Мастера Геймдизайна (Game Designer Confessions: Insights from Finland's Top Game Designers)
- Мальчик, сделанный из кубиков (A Boy Made of Blocks)
- Настольня игра "Бумунту"
- Документальный фильм про AlphaGo
- Настольная игра "Ужасы Аркхэма"

P.P.S.
А кто и как сейчас обучает своих детей программированию, особенно учитывая, что Lego Mindstorm прекратили выпускать? Поделитесь своими подходами в комментариях.

#Software #Education #GameDesign #SelfDevelopment

Tools and practices to help you deal with legacy code - Dennis Doomen - NDC Porto 2023

Интересно выступление на тему работу с наследием прошлого или, проще говоря. легаси кодом. В этом выступлении автор приводит алгоритм своих действий в качестве консультанта, которого зовут для занятий археологий вокруг legacy систем. Алгоритм мне показался интересным, поэтому я решил расписать его кратко
- Деннис начинает с анализа прода, включая изучение запущенных процессов и их конфигурации.
- Дальше он изучает код и его структуру и ищет проблемы - обычно именно эти проблемы мешают клиенту и он призывает решить их Денниса
- Деннис сравнивает код с системой управления версиями и ищет закомментированные или измененные части кода
- Он изучает log файлы, а также отчеты о сбоях и уже найденные проблемы
- Дальше Денис занимается exploratory testing и пробует воспроизвести проблемы, о которых сообщали клиенты.
- При изучении кода автор обращает внимание на пространства имен, подходы к неймингу классов и функций, а также создает ментальные карты и визуализирует зависимости между частями проекта
- Автор отмечает, что сейчас появились AI инструменты, которые можно просить объяснить логику того или иного куска кода
- Для улучшения кодовой базы стоит удалять куски неиспользуемого кода - если они понядобятся, то мы сможем их восстановить из системы контроля версий
- Перед внесением изменения в код автор создает safety nets, создавая высокоуровневые тесты, которые позволяют отследить изменения в поведении программы. Тут автор рекомендует книгу "Working Effectively with Legacy Code" от Michael Feathers
- Дальше автор работает над автоматизацией сборки и развертывания программы, чтобы не делать это руками, а сделать нормальный CI/CD пайплайн. Тут автор рекомендует Ansible или Pulumi
- Отдельно автор говорит про стратегии ветвления и версионирования программы (semver)
- Также надо выстроить работу с исключениями, сделать нормальное логгирование с уровнями и использовать open telemetry для трейсинга
- Следующий шаг - это использование статического анализатора кода, в .net автор рекомендует Roslyn
- Дальше автор отформатировать код в единый стиль и применить это изменение одним коммитом, а дальше настроить линтеры и поддерживать этот стиль:)
- Автор топит за то, чтобы даже на старых платформах использовать новые возможности языка, используя аналог polyfills из js, но для .net платформы
- Дальше автор говорит про реструктуризацию кода и перенос связных частей в отдельные функциональные папки, отдельно он предлагает дублировать код для снижения coupling разных частей кода (это позволяет оставить меньше связей, хоть и в угоду дублированию)
- Важная часть посвящена применению шаблонов проектирования при рефакторинге старого кода - автор считает их полезными идиомами, которые позволяют снизить сложность старого кода за счет использования знакомых концепций
- Дальше автор вспоминает SOLID и отдельно упоминает про последнюю концепцию с DIP (dependency inversion principle), которая помогает нам организовать зависимости между частями нашего legacy приложения. Автор говорит о том, что зависимости надо оставлять от более абстрактных и стабильных компонентов и если требуется выделять зависимость в интерфейс и использовать инверсию. Тут же автор вспоминает про композицию и наследования и объясняет почему он предпочитает первое второму
- Ну и финал выступления посвящен вопросам архитектуры, где автор вспоминает про onion architecture, hexagonal architecture, clean architecture и говорит, что они решают определенные классы проблем:) То есть выбирать архитектуру надо от того, какие проблемы мы хотим решить

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

#Software #Architecture #SoftwareDevelopment

Предсказуемая иррациональность (Predictably Irrational. The Hidden Forces That Shape Our Decisions) (Part I)

В эти выходные я прочитал книгу Дэна Ариели (Dan Ariely), которая посвящена нашему процессу принятия решений. Эта книга предсказуемо оказалась превосходной, так как большую часть материала я уже видел, когда проходил 10 лет назад его курс "A Beginner's Guide to Irrational Behavior" на edx.org. Также у Дэна было крутое выступление на TED "Are we in control of our own decisions?" 15 лет назад, сразу после первого издания этой книги "Predictably Irrational".
Теперь я расскажу про содержание книги, где в каждой главе автор рассказывает про важный вопрос и описывает те эксперименты, что он проводил вместе с коллегами для исследования поведения людей
0. Как несчастный случай привел меня к исследованиям иррациональности, описанным в этой книге - Дэн рассказывает как в 18 лет он получил обширные ожоги тела и дальше несколько лет пролежал в больнице, пытаясь восстановить свой кожный покров. Там он начал задумываться о причинах того или иного поведения, а также заинтересовался подходами к лечению пациентов с сильной болью.
1. Правда об относительности - автор рассказывает о том, что мы умеем принимать решения сравнивая опции между собой. Здесь описываются эксперименты с выбором из вариантов А и Б, которые выбирают с примерно одинаковой частотой. Но если добавить к выбору ухудшенный вариант А, то обычный вариант А станет лидером, так как на фоне ухудшенного А он будет смотреться выигрышно. Например, так девушка может позвать с собой менее красивую подругу в бар, чтобы на ее фоне смотреться более выигрышно:)
2. Недостатки модели спроса и предложения - автор рассказывает про эффект прайминга, когда мы при принятии решений привязываемся к первоначальной информации (например, о цене) и дальше начинаем принимать решения относительно него. Похожая история есть с гусятами, которые привязываются к первому взрослому, которого увидели в своей жизни. Интересно, что в этой главе автор говорит про то, что стоило бы вести журнал принятых решений и иногда возвращаться к ним, чтобы оценивать насколько они еще актуальны. Это напрямую напоминает процесс RFC/ADR, где мы фиксируем принятые решения и можем возвращаться к ним в будущем
3. Чего стоят нулевые издержки - история про магическую притягательность "бесплатных" предложений. Подзаголовок этой главы "Почему, не платя ничего, мы платим слишком много" отлично отражает содержимое главы. Здесь автор рассказывает про боль потери (когда мы платим за что-то), а мы не любим испытывать эти эмоции. Используя эту концепцию, он объясняет почему прикольно платить за ресторан по очереди, если вы ходите в него со своими друзьями:)
4. Цена социальных норм - глава на тему социальных и экономических норм и того, что они не совместимы между собой. Например, если вы попросите знакомого помочь вам по мелочи, то он вероятно согласится из-за социальных норм и ваших хороших отношений. А если вы предложите ему за это 100 рублей, то он откажется и оскорбится (оценив стоимость своего времени и считая, что вы предложили слишком мало). Этому вопросу посвящена книга-комикс "Умные решения" ("Amazing decisions"), про которую я рассказывал
5. Сила бесплатного печенья - здесь автор рассказывает о том, что если вы принесете на работу печенье и будете предлагать его бесплатно, то люди будут скромно угощаться печеньем. А вот если вы назначите за него небольшую цену, то скромность сразу исчезнет. Вы сразу перейдете из плоскости социальных норм в мир рыночных отношений:)
6. Влияние возбуждения - рассказ о том, что в рациональном состоянии мы не можем точно предсказать как будем себя вести при переходе в эмоциональное состояние. Результаты эксперимента показали, что моральные нормы могут сильно сдвигаться в возбужденном состоянии

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

#Psychology #Economics #Brain #SelfDevelopment

Code of Leadership #12 - Интервью про платформу Spirit (Internal developer platform) в Тинькофф

В двенадцатом выпуске подкаста я общаюсь с Димой Гаевским, Technical CPO (Chief Product Owner) нашей внутренней платформы разработки Spirit. Дима рассказывает про свой путь в Тинькофф, немного про разработку и много про создание и развитие платформенных решений. ЗА 45 минут мы успели поговорить про
- Путь Димы в компании
- Платформу для разработчиков (internal developer platform)
- Декомпозицию ответственности
- Роль инженера
- Распределение времени и восприятие работы
- Продуктовые практики и обратная связь
- Роль технического продакт менеджера
- Принципы развития платформы разаработки (IDP)
- Рекомендации для инженеров и технических руководителей

P.S.
У Димы есть прикольная статья про IDP на Хабре по мотивам выступления на Highload++ 2022. Плюс подробнее про платформу можно почитать на нашем сайте. Ну и для тех, кто заинтересовался этой историей, у Димы есть вакансия technical product manager, про которую я писал уже раньше.

#ProductManagement #Management #Leadership #PlatformEngineering #Software #SoftwareDevelopment #Architecture #Processes

Предсказуемая иррациональность (Predictably Irrational. The Hidden Forces That Shape Our Decisions) (Part II)

Продолжая предыдущий пост по этой книге, рассказываю об остальных главах:
7. Проблема прокрастинации и самоконтроля - здесь автор рассказывает истории про обучение и домашние задания студентов (и как дефолтным поведением является попытка все оттянуть напоследок). Дальше речь идет про здравоохранение и проактивное решение проблем, которое мало кто практикует. Потом идет история про сбережения и то, что люди часто не думают о старости, предпочитая здесь жить здесь и сейчас, а долговременные последствия игнорировать. Автор интересно рассказывает о том, как связать полезное дело с получением позитивных эмоций - у него это был прием лекарства с кучей побочек, которое ему нужно было принимать месяцами. Он связал его с просмотром кинофильмов, которые он очень любил, но не смотрел в другое время. В итоге, он ждал этого времени и не пропустил ни один прием препарата:)
8. Высокая цена владения - автор показывает как обладание чем-то увеличивает стоимость предмета в наших глазах. Он даже называет это эффектом Икеи, когда мы ценим собранную своими руками мебель гораздо выше, чем если бы нам ее собрал кто-то другой:)
9. Как держать двери открытыми - тут речь идет про то, что мы любим оставлять доступными альтернативные варианты, даже если это не оптималььно с точки зрения принятия решений. Из-за этого мы раскидываемся и тратим силы на левые активности, которые можно было бы не делать. Я думаю, что у меня есть уязвимость к этому типу поведения:)
10. Эффект ожиданий - здесь автор говорит про самосбывающиеся пророчества и что наши ожидания влияют напрямую на наше восприятие результатов.
11. Сила цены - здесь автор рассказывает про эффект плацебо:) Это когда мы покупаем гомеопатические препараты в надежде на то, что "вода помнит" и они нам действительно помогают, из-за того, что мы верим в их чудодейственный эффект (даже если там почти нет активного вещества)
12. Цикл недоверия - автор показывает, что мы давно перестали верить рекламе и обещанием брендов, потому что она часто не оправдывает ожиданий. Это приводит к тому, что мы начинаем искать подвох в любой рекламе, даже такой, как политические лозунги:)
13. Контекст нашего характера, часть 1 - здесь автор показывает как люди читерят и что можно с этим сделать. Наример, автор показывает как напоминание про 10 заповедей или подпись бумаги о следовании моральному кодексу снижала читерство до нуля:)
14. Контекст нашего характера, часть 2 - глава о том, что мы действуем относительно честно, если имеем дело с наличными деньгами. А вот при появлении уровней косвенности нам гораздо проще читерить - особенно просто это делать с виртуальными фантиками на счетах
15. Пиво и "бесплатный сыр" - финал про поведенческую экономику, которая лучше описывает поведение людей, чем стандартный подход к экономике, где мы предполагаем, что имеем дело с рациональными людьми:) Понимая эти особенности нашего поведения, мы можем научиться принимать лучшие решения, чем те, чтобы мы принимали без этих знаний.

P.S.
Если вам понравилась эта книга, то рекомендую почитать еще книгу Канемана "Thniking, Fast and Slow" ("Думай медленно ... Решай быстро"), про которую я писал раньше.

#Psychology #Economics #Brain #SelfDevelopment

Banking Cybersecurity: Battling DeepFakes & AI-powered Scammers - George Proorocu - at NDC Security in Oslo, Norway

Интересное выступление Джорджа из нидерландского банка ING про безопасность в век deepfakes и AI, что могут использовать скаммеры.
Джорд рассматривает 4 сценария:
- C-level impersnation - когда мошенники пытаются выдать себя за топ-менеджера компании и дальше попросить перевести деньги на определенный счет. Кстати, у этого типа атаки есть реальные примеры
- Audio deepfakes - когда мошенники звонят людям и говорят голосом их детей, знакомых или родителей и просят перевести деньги. Эффективность атаки обусловлена тем, что мы, слыша знакомый голос, а также личную информацию верим, что произошло что-то серьезное и готовы последовать просьбе близкого человека.
- Deepfake interviews - пример атаки, когда ваш инженер проходит интервью, ему присылают оффер, он открывает его на рабочем компе (что туповато). Но оказывается, что все это было фейковым и все интервью были проведены мошенниками, которые хотели пробраться в вашу сеть. Интересный вектор атаки, но deepfake interviews сейчас используют и наоборот - интервью проходит один человек с фейк видео другого человека, а на работу выходит тот, чье лицо натягивал на себя интервьюируемый крутой инженер. В итоге, если это сделано ради зарплаты, то это еще полбеды, а если это сделано для того, чтобы получить доступ к системам компании?
- Investment scam - дипфейки в видео с известными людьми, которые рекламируют всякий скам. Здесь мошенничество в том, что эти люди явно бы не стали рекламировать этот скам, но небольшая помощь AI и дальше реклама готова:)

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

P.S.
Джордж показал как выглядели дипфейки год или полтора назад и как они выглядят сейчас и это небо и земля. Если раньше иногда были glitches как в Матрице, например, при вращении головой, то теперь даже это обрабатывается хорошо. Так что этот вектор атаки становится все реальнее.

#Security #Software #AI

Why Great Leaders Must Unlearn to Succeed in Today's Exponential World • Barry O’Reilly • YOW! 2018

Интересное выступление автора книги "Unlearn. Let go of past success to achieve extraordinary results". В этой книге предлагается трехшаговый процесс для лидеров

1. Unlearn the behaviors and mindsets that keep them and their businesses from moving forward.
2. Relearn new skills, strategies, and innovations that are transforming the world every day.
3. Break through old habits and thinking by opening up to new ideas and perspectives while achieving extraordinary results.

Если же говорить про само выступление, то оно достаточно интересно
- Римская империя и обучение - автор показывает карту Римской империи и говорит о том, что она поддерживала себя на протяжении 2000 лет, используя различные методы и системы работы. Именно это позволяло ей адаптироваться к изменяющимся условиям
- Инновации - это подход компаний к адаптации к изменяющимся условиям. И важно создать систему внутри компании, которая будет помогать постоянно учиться и отучаться от старых подходов (unlearn - отсюда название книги)
- Примеры подходов автора - "execamp" для руководителей, которые оставляют свой бизнес на срок от 4 до 8 недель для того, чтобы попробовать придумать модель стартапа для своей компании. Например, в результате такого unlearn опыта менеджеры из International Airlines Group (IAG) придумали концепцию Level (бренд для low-cost трансатлантических полетов)
- Важность unlearn - мысль в том, что для роста и развития необходимо выходить за пределы своей зоны комфорта и создавать ситуации, в которых некомфортно. Могу добавить, что мы растем, когда преодолеваем трудности и когда нам тяжело. Поэтому я и стараюсь всегда быть хотя бы одной ногой вне зоны комфорта:) Но для того, чтобы действовать так, нужно чувствовать себя в безопасности и иметь уверенность в себе - это помогает создавать ситуации, в которых можно учиться и отучиться. Здесь автор вспоминает про "Проект Аристотель" (Google's Project Aristotle) от ребят из Google, где самым главным фактором успеха команд является psychological safety. Я уже писал про это исследование
- Изменение мышления - важно не просто поменять свои подходы на словах, но и изменить свое поведение, а дальше за этим подтянется мышление
- Обучение на ошибках - автор рассказывает про важность использования обратной связи об ошибках для улучшения продуктов и услуг. В пример приводится генеральный директор T-Mobile Джон Ларч, который использовал жалобы клиентов для улучшения своей работы и бизнеса. Другой пример работы с ошибками - это НАСА, где ошибки вообще приводили к катастрофам, но в итоге стали основой для обучения и адаптации поведения.
- Культура обучения и безопасности - умение работать с ошибками может быть конкурентным преимуществом, если ими делиться и использовать для улучшения систем. Правда, подход к работе с ошибками зависит от культуры организации, о чем можно подробнее прочитать у Веструма в whitepaper "A typology of organisational cultures", о которой я уже рассказывал. Плюс тут же работает и упоминавшейся выше фактор psychological safety.
- Важность экспериментов и обратной связи - для достижения выдающихся результатов, нужно экспериментировать и пробовать новые подходы, даже если они вызывают дискомфорт. Важно создать цикл обратной связи с людьми, которым доверяешь, чтобы ориентироваться в процессе обучения.

#Culture #Management #Leadership #SRE #Software #Processes #Engineering #Thinking

Наткнулся в канале Валерия Черепенникова на пост про его знакомого Илью Лебедева, который будучи незрячим работает над повышением доступности информационно-коммуникационных технологий для всех граждан России без исключений. Илью можно поддержать на конкурсе "Россия - страна возможностей", проголосовав за него в номинации "АйТи и ИИ". Кстати, на канал Валерия я подписан с его цикла статей про историю Intel, которую он недавно выпустил в виде книги "Made at Intel", которую я прочитал и про которую уже рассказывал.

P.S.
Я, кстати, свой голос в этом конкурсе отдал за Илью.

#Software

Leetcode - прогресс за первый квартал

Продолжаю свою серию постов про свой опыт с Leetcode (смотри 1, 2 и 3). Я закончил первый квартал с leetcode
- прошел больше половины курса "Data Structures and Algorithms"
- начал стабильно решать ежедневные задачи (но иногда не успеваю некоторые решать, а hard задачки просто часто пропускаю)
- темп решения задачек упал еще больше, но хотя бы полчасика в день я трачу на leetcode (на решение ежедневной задачи), а по выходным как раз занимаюсь курсом
Я понял что мне нравится в этой деятельности - эффект быстрого дофамина, когда тесты по задачке проходят и загарается зеленая галка, что она становится "Solved". Это очень отличается от моих обычных рабочих задач, где результаты я могу увидеть через недели, месяцы, годы:) А тут все предельно ясно и понятно и за полчаса ты получаешь подтверждение, что все еще немного инженер, а не просто менеджер:)

#SelfDevelopment #Algorithm #Software #SoftwareDevelopment

Tinkoff CTF (Сapture the Flag)

Продолжая инженерную тему, я хотел бы рассказать про соревнование capture the flag в Тинькофф, которое состоится в 20-21 апреля. Начинается анонс соревнования с такого сетапа

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

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

Вас ждут задания на безопасность в вебе'"\, мобильных приложениях и $инфраструктуре_, крипт0гр4Fию, реверс‑инжиниринг.i64 и хакерскую смекалку

#Software #Security #Engineering