[2/2] Squad Health Check и сравнение его с DORA Metrics, SPACE, DevEx (Рубрика #Management)
Продолжая сравнение разных подходов к оценке эффективности команд, расскажу про оставшиеся параметры по которым их можно сравнивать.
3) Ограниченная масштабируемость и анализ трендов
- SHC затрудняет агрегацию результатов по нескольким командам - частота опросов, список ответов и многое другое команды могут кастомизировать под себя. Это приводит к проблемам при отслеживании тенденций
- DORA Metrics хорошо масштабируется между командами и предоставляет четкий анализ трендов для оценки производительности с течением времени.
- SPACE разработан для анализа продуктивности как на уровне отдельных сотрудников, так и на уровне всей организации, что делает его масштабируемым и эффективным для анализа трендов.
- DevEx предлагает структурированный подход к измерению опыта разработчиков в разных командах, что позволяет последовательно отслеживать улучшения в таких областях, как состояние потока и обратная связь.
4) Применимость полученных данных
- SHC иногда приводит к выводам, что бывают слишком общими или расплывчатыми для того, чтобы их можно было напрямую преобразовать в конкретные действия. Обсуждения могут сосредотачиваться больше на симптомах, чем на их причинах.
- DORA Metrics: Определяет конкретные област, например, MTTR (mean time to recover), которые можно улучшить с помощью целевых вмешательств, таких как оптимизация CI/CD.
- SPACE предоставляет данные, связывая метрики с конкретными аспектами продуктивности (например, проблемы в коммуникации). Это позволяет легко понять как их использовать для оптимизации
- DevEx сосредоточен на изменениях в инструментах и процессах разработчиков, которые напрямую повышают продуктивность и удовлетворенность.
5) Чрезмерный акцент на моральном духе
- SHC сильно акцентирует внимание на моральном духе команды, удовольствии от работы и сотрудничестве, но может упускать из виду важные бизнес-результаты или техническую эффективность.
- DORA Metrics отдает приоритет метрикам производительности разработки, которые влияют на эффективность разработки, а через нее на бизнес-результаты.
- SPACE уравновешивает моральный дух с другими аспектами (например, эффективностью и потоком), обеспечивая учет как благополучия команды, так и бизнес-целей.
- DevEx фокусируется на улучшении опыта разработчиков в целом при согласовании с организационными целями (например, ускорение вывода продукта на рынок).
6) Ресурсоемкость
- SHC требует подготовки фасилитаторов для эффективного проведения обсуждений. Регулярное проведение оценки может быть трудоемким для команд под давлением сроков.
- DORA Metrics позволяет автоматизировать сбор данных с CI/CD систем, что делает менее ресурсоемким использование системы после внедрения.
- SPACE достаточно сложен из-за многомерной природы данных, которые надо подтянуть из внутренних систем компании, но после первоначального внедрения может работать без супер-больших вложений
- DevEx cосредоточен на автоматизации рабочих процессов и улучшении инструментов разработки, находится где-то посередине между DORA и SPACE.
В заключение можно сказать, что хотя Squad Health Check отлично подходит для обсуждения проблем внутри команды и улучшения межличностных отношений, он уступает DORA Metrics, SPACE Framework или DevEx Framework в объективности измерений, техническом фокусе, масштабируемости и применимости данных. Организации должны выбирать фреймворк исходя из своих целей — будь то улучшение морального духа команды или повышение технической эффективности.
#Management #Devops #Management #Leadership #Processes #SRE #Software #Metrics #Productivity
Продолжая сравнение разных подходов к оценке эффективности команд, расскажу про оставшиеся параметры по которым их можно сравнивать.
3) Ограниченная масштабируемость и анализ трендов
- SHC затрудняет агрегацию результатов по нескольким командам - частота опросов, список ответов и многое другое команды могут кастомизировать под себя. Это приводит к проблемам при отслеживании тенденций
- DORA Metrics хорошо масштабируется между командами и предоставляет четкий анализ трендов для оценки производительности с течением времени.
- SPACE разработан для анализа продуктивности как на уровне отдельных сотрудников, так и на уровне всей организации, что делает его масштабируемым и эффективным для анализа трендов.
- DevEx предлагает структурированный подход к измерению опыта разработчиков в разных командах, что позволяет последовательно отслеживать улучшения в таких областях, как состояние потока и обратная связь.
4) Применимость полученных данных
- SHC иногда приводит к выводам, что бывают слишком общими или расплывчатыми для того, чтобы их можно было напрямую преобразовать в конкретные действия. Обсуждения могут сосредотачиваться больше на симптомах, чем на их причинах.
- DORA Metrics: Определяет конкретные област, например, MTTR (mean time to recover), которые можно улучшить с помощью целевых вмешательств, таких как оптимизация CI/CD.
- SPACE предоставляет данные, связывая метрики с конкретными аспектами продуктивности (например, проблемы в коммуникации). Это позволяет легко понять как их использовать для оптимизации
- DevEx сосредоточен на изменениях в инструментах и процессах разработчиков, которые напрямую повышают продуктивность и удовлетворенность.
5) Чрезмерный акцент на моральном духе
- SHC сильно акцентирует внимание на моральном духе команды, удовольствии от работы и сотрудничестве, но может упускать из виду важные бизнес-результаты или техническую эффективность.
- DORA Metrics отдает приоритет метрикам производительности разработки, которые влияют на эффективность разработки, а через нее на бизнес-результаты.
- SPACE уравновешивает моральный дух с другими аспектами (например, эффективностью и потоком), обеспечивая учет как благополучия команды, так и бизнес-целей.
- DevEx фокусируется на улучшении опыта разработчиков в целом при согласовании с организационными целями (например, ускорение вывода продукта на рынок).
6) Ресурсоемкость
- SHC требует подготовки фасилитаторов для эффективного проведения обсуждений. Регулярное проведение оценки может быть трудоемким для команд под давлением сроков.
- DORA Metrics позволяет автоматизировать сбор данных с CI/CD систем, что делает менее ресурсоемким использование системы после внедрения.
- SPACE достаточно сложен из-за многомерной природы данных, которые надо подтянуть из внутренних систем компании, но после первоначального внедрения может работать без супер-больших вложений
- DevEx cосредоточен на автоматизации рабочих процессов и улучшении инструментов разработки, находится где-то посередине между DORA и SPACE.
В заключение можно сказать, что хотя Squad Health Check отлично подходит для обсуждения проблем внутри команды и улучшения межличностных отношений, он уступает DORA Metrics, SPACE Framework или DevEx Framework в объективности измерений, техническом фокусе, масштабируемости и применимости данных. Организации должны выбирать фреймворк исходя из своих целей — будь то улучшение морального духа команды или повышение технической эффективности.
#Management #Devops #Management #Leadership #Processes #SRE #Software #Metrics #Productivity
Telegram
Книжный куб
[1/2] Squad Health Check и сравнение его с DORA Metrics, SPACE, DevEx (Рубрика #Management)
Буквально на днях наткнулся на древний инструмент опросов от Spotify. Этот концепт был опубликован в далеком 2014 году, через пару лет после публикации знаменитой…
Буквально на днях наткнулся на древний инструмент опросов от Spotify. Этот концепт был опубликован в далеком 2014 году, через пару лет после публикации знаменитой…
👍3❤2🔥2
Я люблю читать канал "Малоизвестное интересное", так как там периодически, бывают очень интересные мысли. Они позволяют мне самому чуть шире взглянуть на происходящее на переднем краю технологических возможностей, а иногда этот взгляд не шире, но как будто под другим углом:) Конкретно в этом посте мне понравилась интересная визуализация и вообще график качество/стоимость для LLMs, а также фронтир возможностей OpenAI, DeepSeek и Gemini моделей.
👍3🔥2💯1
Forwarded from Малоизвестное интересное
Кто получит «Мандат Неба»?
Динамика «гонки вооружений» LLM одним слайдом.
«Гонка вооружений» на рынке больших языковых моделей (LLM) определяется просто: все стараются получить максимально высокую точность при минимальной цене. А а «фронтир» отражает лучшие на данный момент варианты по сочетанию этих двух параметров.
Диаграмма показывает [1], как разные версии языковых моделей (от OpenAI, Deepseek, Google «Gemini», Anthropic и др.) соотносятся по:
• стоимости (ось X): цена за миллион токенов - чем правее точка, тем дешевле использование модели (ниже стоимость за миллион токенов).
• качеству (ось Y): рейтинг LMSys Elo - чем выше точка, тем сильнее модель (лучшее качество ответов/результатов).
Ключевые выводы (по состоянию на февраль 2025)
• Чемпион в соотношении цена-производительность - Gemini 2.0 Flash Thinking (лучше, чем DeepSeek r1 (по ELO) и дешевле
• Стоимость возможностей GPT-4 упала в 1000 раз за 18 месяцев
• Скорость роста возможностей моделей просто немыслимая – так не бывает, … но так есть!
PS Спецы из Google DeepMind полагают, что они близки к получению «Мандата Неба» ("Mandate of Heaven" (天命, Тяньмин)) [2]. Когда говорят, что компания имеет "Mandate of Heaven" в сфере ИИ, это означает, что она занимает лидирующую позицию не просто благодаря рыночной доле, но и благодаря признанию её технологического превосходства и инновационного лидерства.
Но вряд ли конкуренты согласятся 😊
#ИИгонка
Динамика «гонки вооружений» LLM одним слайдом.
«Гонка вооружений» на рынке больших языковых моделей (LLM) определяется просто: все стараются получить максимально высокую точность при минимальной цене. А а «фронтир» отражает лучшие на данный момент варианты по сочетанию этих двух параметров.
Диаграмма показывает [1], как разные версии языковых моделей (от OpenAI, Deepseek, Google «Gemini», Anthropic и др.) соотносятся по:
• стоимости (ось X): цена за миллион токенов - чем правее точка, тем дешевле использование модели (ниже стоимость за миллион токенов).
• качеству (ось Y): рейтинг LMSys Elo - чем выше точка, тем сильнее модель (лучшее качество ответов/результатов).
На диаграмме видны две основные "границы эффективности" (pareto frontier):
• Синяя линия от OpenAI, показывающая их модели
• Оранжевая линия от Gemini 2, которая, судя по надписи, предлагает "лучше, дешевле, круче"
• Более дорогие и мощные модели в верхней левой части (например, различные версии GPT-4)
• Средний сегмент в центре (Claude 3.5, Gemini 1.5)
• Более доступные модели в правой части (Amazon Nova Lite, Gemini 1.5 Flash)
Ключевые выводы (по состоянию на февраль 2025)
• Чемпион в соотношении цена-производительность - Gemini 2.0 Flash Thinking (лучше, чем DeepSeek r1 (по ELO) и дешевле
• Стоимость возможностей GPT-4 упала в 1000 раз за 18 месяцев
• Скорость роста возможностей моделей просто немыслимая – так не бывает, … но так есть!
PS Спецы из Google DeepMind полагают, что они близки к получению «Мандата Неба» ("Mandate of Heaven" (天命, Тяньмин)) [2]. Когда говорят, что компания имеет "Mandate of Heaven" в сфере ИИ, это означает, что она занимает лидирующую позицию не просто благодаря рыночной доле, но и благодаря признанию её технологического превосходства и инновационного лидерства.
Но вряд ли конкуренты согласятся 😊
#ИИгонка
👍8❤3🔥2
[1/2] Behavioral Interview Discussion with Ex-Meta Hiring Committee Member (Рубрика #Management)
Интересное обсуждение поведенческих интервью в бигтех компаниях. Оно само выполнено в виде интервью, которое берет Stefan Mai у Austen McDonald, бывшего senior engineering manager в Meta, а также члена комитета по найму там же. Собственно, в этом интервью Остин делится своим опытом и рассказывает свои мысли относительно поведенческих интервью. Мне эта запись понравилась, так как я часто сам провожу интервью инженеров и руководителей и знаю о чем речь не понаслышке.
Вот что я вынес для себя из этого интервью
1) Остин считает, что поведенческие интервью требуют тщательной подготовки, причем подготовка дает возможность стать лучшим инженером в будущем из-за глубокой рефлексии об опыте и достижениях в прошлых проектах. Мне кажется, что навыки рефлексии - это ключ к ежедневному росту над собой, но это обычно не слишком приятно, поэтому люди избегают таких размышлений, а подготовка к интервью помогает им найти силы для этого дела
2) Поведенческие интервью важных для высоких грейдов, как инженерных, так и менеджерских. Компании оценивают прошлые успехи и поведение и используют это как экстраполяцию будущих результатов кандидата
3) Поведенческие интервью варьируются в зависимости от грейда, в приведенном видео Остин приводит примеры таких различий
4) У компаний есть критерии для оценки кандидатов, например, инициативность, настойчивость, ...
5) Крупные компании стремятся уйти от субъективных решений, поэтому формализуют критерии оценки
6) Как и всегда первое впечатление очень важно, поэтому важно правильно начать интервью ине обосраться . Автор рекомендует подготовить ответы на вопросы, которые с большой вероятностью будут заданы в начале интервью: "Расскажи о себе", "Расскажи о своем любимом проекте". Ответы на эти вопросы позволят задать првильный тон всей встрече.
7) Часто для проведения интервью используют стандартные схемы, например, STAR (Situation - Tasks - Actions - Results) или CARL (Context - Actions - Results - Learning), причем Остину нравится CARL больше STAR за счет последнего пункта про извлеченные уроки, а также он рекомендует меньше тратить времени на рассказ о контексте и больше на само действие и результаты
8 ) Стандартизированный подход (STAR / CARL / ваш любимый) может мешать непринужденной беседе и выглядеть неестественно, это решается тренировкой интервьюеров
Продолжение рассказа во втором посте.
#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career
Интересное обсуждение поведенческих интервью в бигтех компаниях. Оно само выполнено в виде интервью, которое берет Stefan Mai у Austen McDonald, бывшего senior engineering manager в Meta, а также члена комитета по найму там же. Собственно, в этом интервью Остин делится своим опытом и рассказывает свои мысли относительно поведенческих интервью. Мне эта запись понравилась, так как я часто сам провожу интервью инженеров и руководителей и знаю о чем речь не понаслышке.
Вот что я вынес для себя из этого интервью
1) Остин считает, что поведенческие интервью требуют тщательной подготовки, причем подготовка дает возможность стать лучшим инженером в будущем из-за глубокой рефлексии об опыте и достижениях в прошлых проектах. Мне кажется, что навыки рефлексии - это ключ к ежедневному росту над собой, но это обычно не слишком приятно, поэтому люди избегают таких размышлений, а подготовка к интервью помогает им найти силы для этого дела
2) Поведенческие интервью важных для высоких грейдов, как инженерных, так и менеджерских. Компании оценивают прошлые успехи и поведение и используют это как экстраполяцию будущих результатов кандидата
3) Поведенческие интервью варьируются в зависимости от грейда, в приведенном видео Остин приводит примеры таких различий
4) У компаний есть критерии для оценки кандидатов, например, инициативность, настойчивость, ...
5) Крупные компании стремятся уйти от субъективных решений, поэтому формализуют критерии оценки
6) Как и всегда первое впечатление очень важно, поэтому важно правильно начать интервью и
7) Часто для проведения интервью используют стандартные схемы, например, STAR (Situation - Tasks - Actions - Results) или CARL (Context - Actions - Results - Learning), причем Остину нравится CARL больше STAR за счет последнего пункта про извлеченные уроки, а также он рекомендует меньше тратить времени на рассказ о контексте и больше на само действие и результаты
8 ) Стандартизированный подход (STAR / CARL / ваш любимый) может мешать непринужденной беседе и выглядеть неестественно, это решается тренировкой интервьюеров
Продолжение рассказа во втором посте.
#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career
YouTube
Behavioral Interview Discussion with Ex-Meta Hiring Committee Member
In this conversation, Stefan Mai interviews Austen McDonald, a former senior engineering manager and hiring committee member at Meta, about the how behavioral interviews are assessed, what you should do to prepare, and common red flags.
Check out Austen's…
Check out Austen's…
👍12❤4🔥3
[2/2] Behavioral Interview Discussion with Ex-Meta Hiring Committee Member (Рубрика #Management)
Продолжу рассказ про поведенческие интервью в зарубежных бигтехах, который я начал в первом посте.
9) Кандидатам важно уметь правильно презентовать свой опыт, а для этого важно понимать свои достижения и проекты, а также соотнести свои проекты с ценностями компании
10) Важно правильно выбирать проекты для рассказа. Например, автор рекомендует делить проекты по личному участию, влиянию на бизнес и масштабу. Важно, чтобы о выбранных проектах можно было интересно рассказать (рассказ об унылом проекте вгоняет интервьюера в депрессию )
11) На интервью часто задают вопросы об совершенных ошибках. Не стоит отвечать, что их не было - все люди ошибаются, но хорошие кандидаты признают ошибки и учаться на них (а лучшие учатся еще и на чужих ошибка )
12) Помимо ошибок интервьюер может спросить про слабости кандидата. Не стоит отвечать на них, что их нет или "Я - трудоголик", важно признавать свои слабости, а если еще рассказать про извлеченные из них уроки, то будет еще лучше. Но для интервьера важна честность и искренность, наигранные рассказы не принесут вистов
13) При подготовке к интервью важно подумать о том, а как показать, что вы подходите команде и решаете похожие задачи и сможете принести пользу новой компании. Лучше всего показать это через то, чтобы показать как вы добились реальных результатов на прошлом месте и принесли пользу бизнесу
14) При подготовке к интервью будьте готовы рассказать о себе, любимом проекте, а также конфликтной ситуации. В принципе, можно подготовить еще набор историй, привязанных к ценностям компании, а также отсортированных по масштабу, личному участию и импакту. Это поможет вам на интервью проще подбирать примеры из своего опыта под вопросы интервьюера
15) В конце интервью часто есть время на то, чтобы задать вопросы интервьюеру - это важный момент для того, чтобы продемонстировать интересе к компании и команде (если вас смотрят в конкретную команду), например можно задать вопросы про
- О развитии отдела и технологий
- О стиле управления нанимающего менеджера и динамике команды
В принципе, все советы достаточно логичные и помогут не просто подготовиться к интервью, а запустить процесс рефлексии о своем рабочем опыте и своих ожиданиях от дальнейшего места. Поэтому рекомендую поразмышлять о них, даже если вы не ищите работу:)
P.S.
Я как-то рассказывл про то, как мы нанимаем
- Технических руководителей
- Staff+ инженеров
В принципе, многие советы Остина полезны и для подготовки к нашим интервью.
#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career
Продолжу рассказ про поведенческие интервью в зарубежных бигтехах, который я начал в первом посте.
9) Кандидатам важно уметь правильно презентовать свой опыт, а для этого важно понимать свои достижения и проекты, а также соотнести свои проекты с ценностями компании
10) Важно правильно выбирать проекты для рассказа. Например, автор рекомендует делить проекты по личному участию, влиянию на бизнес и масштабу. Важно, чтобы о выбранных проектах можно было интересно рассказать (
11) На интервью часто задают вопросы об совершенных ошибках. Не стоит отвечать, что их не было - все люди ошибаются, но хорошие кандидаты признают ошибки и учаться на них (
12) Помимо ошибок интервьюер может спросить про слабости кандидата. Не стоит отвечать на них, что их нет или "Я - трудоголик", важно признавать свои слабости, а если еще рассказать про извлеченные из них уроки, то будет еще лучше. Но для интервьера важна честность и искренность, наигранные рассказы не принесут вистов
13) При подготовке к интервью важно подумать о том, а как показать, что вы подходите команде и решаете похожие задачи и сможете принести пользу новой компании. Лучше всего показать это через то, чтобы показать как вы добились реальных результатов на прошлом месте и принесли пользу бизнесу
14) При подготовке к интервью будьте готовы рассказать о себе, любимом проекте, а также конфликтной ситуации. В принципе, можно подготовить еще набор историй, привязанных к ценностям компании, а также отсортированных по масштабу, личному участию и импакту. Это поможет вам на интервью проще подбирать примеры из своего опыта под вопросы интервьюера
15) В конце интервью часто есть время на то, чтобы задать вопросы интервьюеру - это важный момент для того, чтобы продемонстировать интересе к компании и команде (если вас смотрят в конкретную команду), например можно задать вопросы про
- О развитии отдела и технологий
- О стиле управления нанимающего менеджера и динамике команды
В принципе, все советы достаточно логичные и помогут не просто подготовиться к интервью, а запустить процесс рефлексии о своем рабочем опыте и своих ожиданиях от дальнейшего места. Поэтому рекомендую поразмышлять о них, даже если вы не ищите работу:)
P.S.
Я как-то рассказывл про то, как мы нанимаем
- Технических руководителей
- Staff+ инженеров
В принципе, многие советы Остина полезны и для подготовки к нашим интервью.
#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career
👍5❤2🔥2🗿2
Digital Nudge (Рубрика #Management)
Полгода назад мне подарили эту книгу, но прочитал я ее на днях. В ней Fabio Pereira рассказывает про базовые принципы поведенческой экономики, которые могут быть применены в цифровом миру для тонкого влияния на решения и поведение пользователей. Автор вводит концепцию digital nudging или цифрового подталкивания, которая представляет собой использование тонких элементов дизайна, информации и взаимодействия в цифровой среде для управления поведением пользователей без ограничения их свободы выбора. По-факту, это адаптация nudge theory Ричарда Талера и Касса Састейна из книги "Nudge". Правда, digital nudge адаптирован к цифровому контексту, например, веб-сайтам, приложениям или онлайн-платформам, и используют элементы интерфейса, такие как настройки по умолчанию, визуальные подсказки, персонализированные рекомендации и своевременные уведомления для влияния на принятие решений.
Оснонвые идеи книги
1) Choice architecture (архитектура выбора): То, как представлены варианты выбора в цифровой среде, может существенно влиять на поведение пользователей. Например, настройки по умолчанию (например, автоматическое продление подписок) часто направляют пользователей к определенным действиям.
2) Behavioral triggers (психологические триггеры): Цифровые "подталкивания" опираются на психологические принципы, такие как социальное доказательство (например, отзывы пользователей), дефицит (например, "Осталось всего 3 товара") и избегание потерь для стимулирования желаемого поведения.
3) Personalization (персонализация): "Подталкивания" могут быть адаптированы на основе данных о пользователях, таких как предпочтения или действия в реальном времени, для повышения их эффективности.
4) Low-cost interventions (дешевые интервенции): Цифровые "подталкивания" недороги и минимально навязчивы, что делает их масштабируемым решением для влияния на поведение в разных областях
Автор приводит большой список примеров использования digital nudges
- Электронная коммерция: Выделение ограниченных по времени предложений или персонализированных рекомендаций для увеличения продаж.
- Здоровье и фитнес: Стимулирование более здорового образа жизни или регулярных тренировок через напоминания и элементы геймификации.
- Продуктивность на работе: Подталкивание сотрудников к выполнению задач или освоению новых инструментов с помощью целевых уведомлений.
- Образование: Повышение вовлеченности студентов с помощью интерактивных учебных материалов и функций отслеживания прогресса.
Эта книга связана с другими
- "Nudge: Improving Decisions About Health, Wealth, and Happiness" Ричарда Талера и Касса Санстейна — основополагающая работа о теории "подталкивания".
- "Hooked: How to Build Habit-Forming Products" ("На крючке") - эта книга Нира Эяля о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. Я про нее уже рассказывал
- "Thinking, Fast and Slow" ("Думай медленно... решай быстро") Даниэля Канемана — исследует психологические системы принятия решений. Я про нее уже рассказывал
- "Predictably Irrational" ("Предсказуемая иррациональность") Дэна Ариели — объясняет, почему люди принимают иррациональные решения и как на них можно влиять.Я про нее уже рассказывал
- "Inside the Nudge Unit" Дэвида Хэлперна — о практическом применении теории "подталкивания" в государственной политике.
- "Misbehaving: The Making of Behavioral Economics" Ричарда Талера — рассказывает о развитии поведенческой экономики как научной дисциплины.
Эти книги предоставляют более глубокое понимание поведенческой экономики и науки о принятии решений, дополняя темы из Digital Nudge.
А вообще, сама книга "Digital nudge" очень простая и легкая, а поэтому хорошо подходит для того, чтобы познакомиться с этой темой.
P.S.
Я уже рассказывал про пару выступлений Фабио конференциях, из которых можно сложить отличное представление о самой концепции digital nudge
- The Psychology of UX
- Infobesity - How to Cope with the Overload of Information
#Thinking #PopularScience #SelfDevelopment #Brain #Economics #Psychology
Полгода назад мне подарили эту книгу, но прочитал я ее на днях. В ней Fabio Pereira рассказывает про базовые принципы поведенческой экономики, которые могут быть применены в цифровом миру для тонкого влияния на решения и поведение пользователей. Автор вводит концепцию digital nudging или цифрового подталкивания, которая представляет собой использование тонких элементов дизайна, информации и взаимодействия в цифровой среде для управления поведением пользователей без ограничения их свободы выбора. По-факту, это адаптация nudge theory Ричарда Талера и Касса Састейна из книги "Nudge". Правда, digital nudge адаптирован к цифровому контексту, например, веб-сайтам, приложениям или онлайн-платформам, и используют элементы интерфейса, такие как настройки по умолчанию, визуальные подсказки, персонализированные рекомендации и своевременные уведомления для влияния на принятие решений.
Оснонвые идеи книги
1) Choice architecture (архитектура выбора): То, как представлены варианты выбора в цифровой среде, может существенно влиять на поведение пользователей. Например, настройки по умолчанию (например, автоматическое продление подписок) часто направляют пользователей к определенным действиям.
2) Behavioral triggers (психологические триггеры): Цифровые "подталкивания" опираются на психологические принципы, такие как социальное доказательство (например, отзывы пользователей), дефицит (например, "Осталось всего 3 товара") и избегание потерь для стимулирования желаемого поведения.
3) Personalization (персонализация): "Подталкивания" могут быть адаптированы на основе данных о пользователях, таких как предпочтения или действия в реальном времени, для повышения их эффективности.
4) Low-cost interventions (дешевые интервенции): Цифровые "подталкивания" недороги и минимально навязчивы, что делает их масштабируемым решением для влияния на поведение в разных областях
Автор приводит большой список примеров использования digital nudges
- Электронная коммерция: Выделение ограниченных по времени предложений или персонализированных рекомендаций для увеличения продаж.
- Здоровье и фитнес: Стимулирование более здорового образа жизни или регулярных тренировок через напоминания и элементы геймификации.
- Продуктивность на работе: Подталкивание сотрудников к выполнению задач или освоению новых инструментов с помощью целевых уведомлений.
- Образование: Повышение вовлеченности студентов с помощью интерактивных учебных материалов и функций отслеживания прогресса.
Эта книга связана с другими
- "Nudge: Improving Decisions About Health, Wealth, and Happiness" Ричарда Талера и Касса Санстейна — основополагающая работа о теории "подталкивания".
- "Hooked: How to Build Habit-Forming Products" ("На крючке") - эта книга Нира Эяля о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. Я про нее уже рассказывал
- "Thinking, Fast and Slow" ("Думай медленно... решай быстро") Даниэля Канемана — исследует психологические системы принятия решений. Я про нее уже рассказывал
- "Predictably Irrational" ("Предсказуемая иррациональность") Дэна Ариели — объясняет, почему люди принимают иррациональные решения и как на них можно влиять.Я про нее уже рассказывал
- "Inside the Nudge Unit" Дэвида Хэлперна — о практическом применении теории "подталкивания" в государственной политике.
- "Misbehaving: The Making of Behavioral Economics" Ричарда Талера — рассказывает о развитии поведенческой экономики как научной дисциплины.
Эти книги предоставляют более глубокое понимание поведенческой экономики и науки о принятии решений, дополняя темы из Digital Nudge.
А вообще, сама книга "Digital nudge" очень простая и легкая, а поэтому хорошо подходит для того, чтобы познакомиться с этой темой.
P.S.
Я уже рассказывал про пару выступлений Фабио конференциях, из которых можно сложить отличное представление о самой концепции digital nudge
- The Psychology of UX
- Infobesity - How to Cope with the Overload of Information
#Thinking #PopularScience #SelfDevelopment #Brain #Economics #Psychology
👍9❤5🔥3
Обложка книги "Digital Nudge" и немного примеров применения концепции
👍8❤4🔥2
Research Insights Made Simple #8 "Measuring developer goals" (Рубрика #DevEx)
В этом выпуске подкаста про инсайты ко мне в гости пришел Александр Кусургашев для того, чтобы поговорить про гугловую статью "Measuring developer goals":) Александр работает в Т-Банке в подразделении Core Tech и занимается развитием нашей внутренней платформы разработки. Он верит в законы физики, платформизацию и пользу от переиспользования. Для него важно, чтобы IT системы Т-Банка работали эффективно - от уровня физической инфраструктуры до конечных сервисов для потребителей. Большую часть своей IT карьеры Саша провел разрабатывая платформенные решения для low latency и ultra low latency electronic trading.
За время подкаста мы обсудили темы:
- Опыт работы Саши и его зона ответственности в Т-Банке
- Обсуждение critical user journeys для определения измеримых и объективных целей инженеров
- Гранулярность и декомпозиция целей
- Комплексный подход к оптимизации
- Важность систематического процесса выделения целей
- Эволюция обратной связи в опросах Engineering Satisfaction Survey
- Переход от инструментов к целям
- Измерение метрик и мониторинг процессов
- Вариативность инструментов и сложность стандартизации
- Научный подход к улучшению процессов
Выпуск доступен на Youtube, VK, Podster.fm, Ya Music
P.S.
Я уже разбирал этот whitepaper полгода назад.
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
В этом выпуске подкаста про инсайты ко мне в гости пришел Александр Кусургашев для того, чтобы поговорить про гугловую статью "Measuring developer goals":) Александр работает в Т-Банке в подразделении Core Tech и занимается развитием нашей внутренней платформы разработки. Он верит в законы физики, платформизацию и пользу от переиспользования. Для него важно, чтобы IT системы Т-Банка работали эффективно - от уровня физической инфраструктуры до конечных сервисов для потребителей. Большую часть своей IT карьеры Саша провел разрабатывая платформенные решения для low latency и ultra low latency electronic trading.
За время подкаста мы обсудили темы:
- Опыт работы Саши и его зона ответственности в Т-Банке
- Обсуждение critical user journeys для определения измеримых и объективных целей инженеров
- Гранулярность и декомпозиция целей
- Комплексный подход к оптимизации
- Важность систематического процесса выделения целей
- Эволюция обратной связи в опросах Engineering Satisfaction Survey
- Переход от инструментов к целям
- Измерение метрик и мониторинг процессов
- Вариативность инструментов и сложность стандартизации
- Научный подход к улучшению процессов
Выпуск доступен на Youtube, VK, Podster.fm, Ya Music
P.S.
Я уже разбирал этот whitepaper полгода назад.
#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes
YouTube
Research Insights Made Simple #8 "Measuring developer goals"
В этом выпуске подкаста про инсайты ко мне в гости пришел Александр Кусуршашев для того, чтобы поговорить про гугловую статью "Measuring developer goals":) Александр работает в Т-Банке в подразделении Core Tech и занимается развитием нашей внутренней платформы…
❤9👍6🔥6
This media is not supported in your browser
VIEW IN TELEGRAM
Как я чувствую себя, когда иду на работу ... А вообще это обычный поход моего младшего сына в сад.
❤36🔥18😁13👍8👏1
10 Developer Productivity Boosts from Generative AI (Рубрика #DevEx)
Глянул очередное интересное и короткое видео от Martin Keen, IBM Fellow, который за много лет в IBM проявил себя как изобретатель (больше 400 патентов), технический руководитель, исследователь в AI, а также создатель контента на канале IBM Technology. В этом видео Мартин рассказывает про то, как Gen AI может помочь повысить продуктивность разработчиков, а я про эту тему рассказывал много и подробно раньше, например, в последнем докладе про то, как и зачем мерить developer productivity. Но давайте вернемся к мыслям Мартина
1) Elemenating repetitive tasks. Генеративный ИИ может помочь исключить повторяющиеся задачи, ускоряя рутинную работу.
2) Natural language interface. Интерфейс на естественном языке позволяет запрашивать генерацию кода и контроль версий.
3) Code suggestions. Подсказки помогают начать работу с незнакомыми библиотеками и пакетами.
4) Code improvements. Это улучшения для устранения избыточных и неэффективных частей кода, почти как при pair programming, но где пару составляет AI ассистент
5) Code translation. Трансляции кода с одного языка на другой, которая может быть полезна для масшабной миграции, например, со Scala на Java/Kotlin
6) Code testing. ИИ может создавать тестовые сценарии и оценивать результаты.
7) Bug detection. Автоматическая идентификация и даже исправление багов
😍 Personalized dev environment. Как я понял это история про тюнинг IDE и других инструментов под стиль разработчика
9) Generation documentation. Генерация документации на основе кода
В конце автор говорит о том, что сейчас Gen AI скорее не замена разработчика, а помощь для расширения его возможностей. Это хорошо перекликается с мыслями из статьи "What Do Developers Want From AI?", про которую я рассказывал раньше.
P.S.
Автор не забыл про десятый пункт - он предложил зрителем самим написать в комментах:)
P.P.S.
У Мартина есть интересное видео про тренды AI в 2025 году, про которое я уже писал в канале.
#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx
Глянул очередное интересное и короткое видео от Martin Keen, IBM Fellow, который за много лет в IBM проявил себя как изобретатель (больше 400 патентов), технический руководитель, исследователь в AI, а также создатель контента на канале IBM Technology. В этом видео Мартин рассказывает про то, как Gen AI может помочь повысить продуктивность разработчиков, а я про эту тему рассказывал много и подробно раньше, например, в последнем докладе про то, как и зачем мерить developer productivity. Но давайте вернемся к мыслям Мартина
1) Elemenating repetitive tasks. Генеративный ИИ может помочь исключить повторяющиеся задачи, ускоряя рутинную работу.
2) Natural language interface. Интерфейс на естественном языке позволяет запрашивать генерацию кода и контроль версий.
3) Code suggestions. Подсказки помогают начать работу с незнакомыми библиотеками и пакетами.
4) Code improvements. Это улучшения для устранения избыточных и неэффективных частей кода, почти как при pair programming, но где пару составляет AI ассистент
5) Code translation. Трансляции кода с одного языка на другой, которая может быть полезна для масшабной миграции, например, со Scala на Java/Kotlin
6) Code testing. ИИ может создавать тестовые сценарии и оценивать результаты.
7) Bug detection. Автоматическая идентификация и даже исправление багов
😍 Personalized dev environment. Как я понял это история про тюнинг IDE и других инструментов под стиль разработчика
9) Generation documentation. Генерация документации на основе кода
В конце автор говорит о том, что сейчас Gen AI скорее не замена разработчика, а помощь для расширения его возможностей. Это хорошо перекликается с мыслями из статьи "What Do Developers Want From AI?", про которую я рассказывал раньше.
P.S.
Автор не забыл про десятый пункт - он предложил зрителем самим написать в комментах:)
P.P.S.
У Мартина есть интересное видео про тренды AI в 2025 году, про которое я уже писал в канале.
#Management #Leadership #Software #SoftwareDevelopment #Metrics #Devops #Processes #AI #ML #DevEx
YouTube
10 Developer Productivity Boosts from Generative AI
Want to play with the technology yourself? Explore our interactive demo → https://ibm.biz/BdKRwX
Learn more about the technology → https://ibm.biz/BdKRwH
Can AI really help speed up code development? In this video, Martin Keen discusses how generative AI…
Learn more about the technology → https://ibm.biz/BdKRwH
Can AI really help speed up code development? In this video, Martin Keen discusses how generative AI…
👍6❤3🔥1
CTO Conf X (Рубрика #Management)
В этом году пройдет CTO Conf X, первая профессиональная конференция для технических директоров, от компании "Онтико". Я много выступал на других конференциях этой компании, например, Highload++, Teamlead Conf, Teachlead Conf, а теперь вошел в программный комитет этой новой конференции. Мы в программном комитете долго обсуждали какие доклады будут полезны посетителям конференции и получилось следующее
- Как CTO быть партнером бизнесу, а не просто исполнителем
- Как CTO создавать и актуализировать технологическую стратегию
- Как не утонуть в операционке и уделять еще время стратегии и тактике
- Как управлять командами разработки на масштабе (когда помнить все про всех уже не возможно)
- Как и зачем появляются внутренние платформы разработки (IDP) внутри компаний
- Как CTO смотрят на использование AI в SDLC (Software Development Life Cycle)
Я думаю, что у нас получиться собрать крутую программу конференции и она принесет пользу тем, кто ее посетит. Если вы планируете посетить конфу, то самое время купить билет со скидкой, а если вы хотите выступить, то еще можно отправить заявку на доклад.
P.S.
Интересно, что еще до появления этой конференции я часто сам рассказывал доклады, которые могли бы присутствовать на ней:
- Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - Highload++ 2021
- Как нанимать технических руководителей - Teamlead Conf 2023
- Эволюция роли технического руководителя от инженера до CTO - SouthHub 2022
- Как формировать структуру команд под запросы бизнеса - YaTalks 2023
- Как и зачем измерять инженерную продуктивность в крупной компании - MTS True Tech Days 2024
#Management #Leadership #Strategy #PlatformEngineering #Engineering #Software #Architecture
В этом году пройдет CTO Conf X, первая профессиональная конференция для технических директоров, от компании "Онтико". Я много выступал на других конференциях этой компании, например, Highload++, Teamlead Conf, Teachlead Conf, а теперь вошел в программный комитет этой новой конференции. Мы в программном комитете долго обсуждали какие доклады будут полезны посетителям конференции и получилось следующее
- Как CTO быть партнером бизнесу, а не просто исполнителем
- Как CTO создавать и актуализировать технологическую стратегию
- Как не утонуть в операционке и уделять еще время стратегии и тактике
- Как управлять командами разработки на масштабе (когда помнить все про всех уже не возможно)
- Как и зачем появляются внутренние платформы разработки (IDP) внутри компаний
- Как CTO смотрят на использование AI в SDLC (Software Development Life Cycle)
Я думаю, что у нас получиться собрать крутую программу конференции и она принесет пользу тем, кто ее посетит. Если вы планируете посетить конфу, то самое время купить билет со скидкой, а если вы хотите выступить, то еще можно отправить заявку на доклад.
P.S.
Интересно, что еще до появления этой конференции я часто сам рассказывал доклады, которые могли бы присутствовать на ней:
- Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - Highload++ 2021
- Как нанимать технических руководителей - Teamlead Conf 2023
- Эволюция роли технического руководителя от инженера до CTO - SouthHub 2022
- Как формировать структуру команд под запросы бизнеса - YaTalks 2023
- Как и зачем измерять инженерную продуктивность в крупной компании - MTS True Tech Days 2024
#Management #Leadership #Strategy #PlatformEngineering #Engineering #Software #Architecture
ctoconf.ru
Профессиональная конференция для технических директоров CTO Conf X 2025 2025
👍14🔥11❤6
Gartner 2024 Hype Cycle for Emerging Technologies (Рубрика #Management)
Недавно столкнулся с картинкой из отчета "Gartner Hype Cycle™ for Emerging Technologies", что вышел летом прошлого года. Несмотря на то, что это по большей части маркетинг Gartner как тренд сеттера в технологиях, часто бывает интересно глянуть отчет и посмотреть, а что в нем есть кроме красивой картинки. Конкретно в этом отчете перечислены 25 прорывных технологий, сгруппированных в самые хайповые темы Autonomous AI (автономный ИИ), Developer Productivity (продуктивность разработчиков), Total Experience (общий опыт), and Human-Centric Security and Privacy (ориентированная на человека безопасность и конфиденциальность). Именно эти темы будут определять будущее бизнеса и технологий в ближайшие годы по мнению Gartner
1. Autonomous AI (автономный ИИ)
Здесь фокус на развитии ИИ-систем, способных выполнять задачи с минимальным участием человека. Эта тема включает в себя такие технологии, как мультиагентные системы, обучение с подкреплением, гуманоидные роботы и machine customers. Для бизнес это означает переход к системам ИИ, которые могут динамически взаимодействовать с окружающей средой и принимать решения в сложных сценариях.
2. Developer Productivity (продуктивность разработчиков)
Здесь объединены инструменты и подходы для повышения эффективности работы разработчиков. Основные технологии: ИИ для поддержки разработки ПО, GitOps, prompt engineering и внутренние порталы для разработчиков. Цель — создать условия для "потока" в работе разработчиков, улучшая их удовлетворенность, сотрудничество и качество результатов. Я на эту тему много уже писал на канале, например, "Как и зачем измерять инженерную продуктивность в крупной компании"
3. Total Experience (общий опыт)
Этот пункт объединяет стратегии клиентского опыта (CX), опыта сотрудников (EX), пользовательского опыта (UX) и многоканального взаимодействия (MX). Здесь авторы говорят про такие технологии, как цифровые двойники клиентов, пространственные вычисления, суперприложения и 6G. Здесь цель в том, чтобы обеспечить бесшовное взаимодействие на всех точках контакта для повышения удовлетворенности, лояльности и вовлеченности.
4. Human-Centric Security and Privacy (ориентированная на человека безопасность и конфиденциальность)
Эта тема направлена на создание доверия за счет мер безопасности, которые учитывают пользовательский опыт и совместное управление рисками. Конкретные технологии такие: AI TRISM (управление доверием, рисками и безопасностью ИИ), цифровые иммунные системы и архитектура сетевой безопасности. Здесь поощряется прозрачность, этичность и проактивное выявление угроз для повышения устойчивости организаций.
Эти темы отражают стратегический подход к использованию новых технологий для трансформации бизнеса при решении таких вызовов, как чрезмерная автоматизация, проблемы конфиденциальности данных и необходимость этических рамок.
#Strategy #Management #Leadership
Недавно столкнулся с картинкой из отчета "Gartner Hype Cycle™ for Emerging Technologies", что вышел летом прошлого года. Несмотря на то, что это по большей части маркетинг Gartner как тренд сеттера в технологиях, часто бывает интересно глянуть отчет и посмотреть, а что в нем есть кроме красивой картинки. Конкретно в этом отчете перечислены 25 прорывных технологий, сгруппированных в самые хайповые темы Autonomous AI (автономный ИИ), Developer Productivity (продуктивность разработчиков), Total Experience (общий опыт), and Human-Centric Security and Privacy (ориентированная на человека безопасность и конфиденциальность). Именно эти темы будут определять будущее бизнеса и технологий в ближайшие годы по мнению Gartner
1. Autonomous AI (автономный ИИ)
Здесь фокус на развитии ИИ-систем, способных выполнять задачи с минимальным участием человека. Эта тема включает в себя такие технологии, как мультиагентные системы, обучение с подкреплением, гуманоидные роботы и machine customers. Для бизнес это означает переход к системам ИИ, которые могут динамически взаимодействовать с окружающей средой и принимать решения в сложных сценариях.
2. Developer Productivity (продуктивность разработчиков)
Здесь объединены инструменты и подходы для повышения эффективности работы разработчиков. Основные технологии: ИИ для поддержки разработки ПО, GitOps, prompt engineering и внутренние порталы для разработчиков. Цель — создать условия для "потока" в работе разработчиков, улучшая их удовлетворенность, сотрудничество и качество результатов. Я на эту тему много уже писал на канале, например, "Как и зачем измерять инженерную продуктивность в крупной компании"
3. Total Experience (общий опыт)
Этот пункт объединяет стратегии клиентского опыта (CX), опыта сотрудников (EX), пользовательского опыта (UX) и многоканального взаимодействия (MX). Здесь авторы говорят про такие технологии, как цифровые двойники клиентов, пространственные вычисления, суперприложения и 6G. Здесь цель в том, чтобы обеспечить бесшовное взаимодействие на всех точках контакта для повышения удовлетворенности, лояльности и вовлеченности.
4. Human-Centric Security and Privacy (ориентированная на человека безопасность и конфиденциальность)
Эта тема направлена на создание доверия за счет мер безопасности, которые учитывают пользовательский опыт и совместное управление рисками. Конкретные технологии такие: AI TRISM (управление доверием, рисками и безопасностью ИИ), цифровые иммунные системы и архитектура сетевой безопасности. Здесь поощряется прозрачность, этичность и проактивное выявление угроз для повышения устойчивости организаций.
Эти темы отражают стратегический подход к использованию новых технологий для трансформации бизнеса при решении таких вызовов, как чрезмерная автоматизация, проблемы конфиденциальности данных и необходимость этических рамок.
#Strategy #Management #Leadership
Gartner
Hype Cycle for Emerging Technologies, 2024
Gartner Information Technology Research on Hype Cycle for Emerging Technologies, 2024
❤5🔥4👍2
[1/2] The Mythical Man-Month (Мифический человеко-месяц) (Рубрика #Management)
Эта книга Фредерика Брукса была впервые издана 50 лет назад, в 1975 года, но она до сих пор переиздается, а цитаты из нее стали классическими. Я решил вспомнить про нее к юбилею и посмотреть насколько она еще актуальна.
В заглавие книги вынесена идея о том, что "добавление сотрудников в отстающий проект только увеличивает задержки" из-за роста коммуникационных издержек, времени на адаптацию новых членов команды и неделимости некоторых задач. Брукс критикует ошибочное предположение, что труд (измеряемый в "человеко-месяцах") можно масштабировать линейно, сравнивая это с невозможностью девяти женщин родить ребенка за один месяц. Это относится к области управления проектом/продуктом и так же актуально, как было 50 лет назад. Еще он подчеркивает важность концептуальной целостности - согласованной архитектуры системы под руководством единого видения - для предотвращения хаоса, вызванного "проектированием при помощи комитетов". Этот тезис относится к проектированию софта. Следующая ключевая идея относится к "эффекту второй системы" (перегрузка сложностью при создании следующей версии). Вот эта проблема кажется уже решена, так как продукты часто сейчас строятся итеративно и понятие версии системы вообще размывается:) Ну и последняя идея, которую стоит отметить - это различие между essential complexity (существенной сложностью, что присуща задаче) и accidental complexity (случайной сложностью, которая возникает из-за неэффективных инструментов или процессов).
Если провести параллели между разработкой во времена Брукса (1970-е годы и засилье мейнфреймов), то мы получим следующее
1) Закон Брукса vs Agile и гибридной работы
- Agile подходы снижают риск неожиданностей и даже работая проектно мы на поздних стадиях получаем меньше рисков, это соответствует мыслям Брукса о важности прототипирования в больших проектах
- Гибридная работа - современные инструменты (GitHub, Jira, Slack) снижают барьеры для коммуникаций, но правило про квадратичный рост затрат на коммуникацию от роста команды никуда не девается (помним, что в полном графе n*(n-1)/2 связей)
- Брукс рекомендовал использовать локализованные "хирургические команды", а у нас теперь есть two-pizza teams
2) Модульность и мокросервисы
- У Брукса вызывала опасения монолитная система, что они делали для мейнфрейма, но в наше время у нас пронеслись перед глазами SOA, микросервисы, FaaS и теперь людям монолит уже не кажется таким плохим вариантом для старта
- По-факту, нам нужна модульность нашего кода, а как он разворачивается можно решить потом (условно модульный монолит можно нормально разделить на отдельные микросервисы при необходимости)
3) Инструменты против человеческого фактора
- Одна из ключевых мыслей Брукса была про то, что серебрянной пули для повышения производительности разработки нет
- Но мы видим, что хорошие инженерные практики постепенно повышали продуктивность инженеров - речь про CI/CD и всю автоматизацию
- А сейчас мы живем во время, когда щепотка AI, добавленная в SDLC (software development life cycle) навроде GitHub Copilot обещает в будущем грандиозный эффект (если LLM продолжат также прогрессировать)
- Но пока мы все еще видим AI в качестве ассистента, а значит нам нужно обращать внимание на человеческий фактор, тут есть классная колонка про "Human approach to developer productivity" от Google, про которую я уже рассказывал раньше
Продолжение обзора в следующем посте.
#Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps
Эта книга Фредерика Брукса была впервые издана 50 лет назад, в 1975 года, но она до сих пор переиздается, а цитаты из нее стали классическими. Я решил вспомнить про нее к юбилею и посмотреть насколько она еще актуальна.
В заглавие книги вынесена идея о том, что "добавление сотрудников в отстающий проект только увеличивает задержки" из-за роста коммуникационных издержек, времени на адаптацию новых членов команды и неделимости некоторых задач. Брукс критикует ошибочное предположение, что труд (измеряемый в "человеко-месяцах") можно масштабировать линейно, сравнивая это с невозможностью девяти женщин родить ребенка за один месяц. Это относится к области управления проектом/продуктом и так же актуально, как было 50 лет назад. Еще он подчеркивает важность концептуальной целостности - согласованной архитектуры системы под руководством единого видения - для предотвращения хаоса, вызванного "проектированием при помощи комитетов". Этот тезис относится к проектированию софта. Следующая ключевая идея относится к "эффекту второй системы" (перегрузка сложностью при создании следующей версии). Вот эта проблема кажется уже решена, так как продукты часто сейчас строятся итеративно и понятие версии системы вообще размывается:) Ну и последняя идея, которую стоит отметить - это различие между essential complexity (существенной сложностью, что присуща задаче) и accidental complexity (случайной сложностью, которая возникает из-за неэффективных инструментов или процессов).
Если провести параллели между разработкой во времена Брукса (1970-е годы и засилье мейнфреймов), то мы получим следующее
1) Закон Брукса vs Agile и гибридной работы
- Agile подходы снижают риск неожиданностей и даже работая проектно мы на поздних стадиях получаем меньше рисков, это соответствует мыслям Брукса о важности прототипирования в больших проектах
- Гибридная работа - современные инструменты (GitHub, Jira, Slack) снижают барьеры для коммуникаций, но правило про квадратичный рост затрат на коммуникацию от роста команды никуда не девается (помним, что в полном графе n*(n-1)/2 связей)
- Брукс рекомендовал использовать локализованные "хирургические команды", а у нас теперь есть two-pizza teams
2) Модульность и мокросервисы
- У Брукса вызывала опасения монолитная система, что они делали для мейнфрейма, но в наше время у нас пронеслись перед глазами SOA, микросервисы, FaaS и теперь людям монолит уже не кажется таким плохим вариантом для старта
- По-факту, нам нужна модульность нашего кода, а как он разворачивается можно решить потом (условно модульный монолит можно нормально разделить на отдельные микросервисы при необходимости)
3) Инструменты против человеческого фактора
- Одна из ключевых мыслей Брукса была про то, что серебрянной пули для повышения производительности разработки нет
- Но мы видим, что хорошие инженерные практики постепенно повышали продуктивность инженеров - речь про CI/CD и всю автоматизацию
- А сейчас мы живем во время, когда щепотка AI, добавленная в SDLC (software development life cycle) навроде GitHub Copilot обещает в будущем грандиозный эффект (если LLM продолжат также прогрессировать)
- Но пока мы все еще видим AI в качестве ассистента, а значит нам нужно обращать внимание на человеческий фактор, тут есть классная колонка про "Human approach to developer productivity" от Google, про которую я уже рассказывал раньше
Продолжение обзора в следующем посте.
#Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps
👍17❤5🔥2
Обложка для книг "The Mythical Man-Month" и "Мифический человеко-месяц)"
🔥9❤1👍1