Code of Leadership (Рубрика #Management)
Примерно год назад я стартанул подкаст про engineering management с названием Code of Leadership. За это время получилось выпустить 21 эпизод, но я не планирую на этом останавливаться:) Подкаст доступен в Youtube и Ya Music.
Вот ссылки на материалы по каждому эпизоду:
1) Team topologies со Станиславом Халупом
2) "Antifragility in IT" с Александром Бындю
3) "Herding Cats" с Женей Кузовлевым
4) "Turn the ship around" с Екатериной Шестимеровой
5) "Project Phoenix" с Иваном Михеевым
6) Интервью про Staff+ инженеры, архитектура и SDLC с Алексеем Тарасовым
7) "Your brain at Work" с Эрнесто Инаркиевым
8) Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)
9) "An Elegant Puzzle - System of Engineering Management (часть 1)" с Eugene Sergueev
10) "An Elegant Puzzle - System of Engineering Management (часть 2)" с Eugene Sergueev
11) Интервью с Кириллом Крайневым про системных аналитиков в Тинькофф
12) Интервью с Димой Гаевским про платформу Spirit (Internal developer platform) в Тинькофф
13) "Accelerate" с Игорем Курочкиным
14) Interview with Artem Ivanov about Risk Tech
15) Interview with Roman Lebed about Information security
16) "The Five Dysfunctions of a Team" с Андреем Соколовым
17) Interview with Anton Kosterin about Architecture Governance
18) Interview with Pavel Akhmetchanov about Processes and Tools
19) Interview with Evgeny Sokolov about Modern Education
20) Interview with Alexey Grishin about Software Architecture
21) "A Philosophy of Software Design" с Гришей Скобелевым
#Architecture #Processes #Management #Leadership #Software #Statistics #Project #Productivity #ProductManagement
Примерно год назад я стартанул подкаст про engineering management с названием Code of Leadership. За это время получилось выпустить 21 эпизод, но я не планирую на этом останавливаться:) Подкаст доступен в Youtube и Ya Music.
Вот ссылки на материалы по каждому эпизоду:
1) Team topologies со Станиславом Халупом
2) "Antifragility in IT" с Александром Бындю
3) "Herding Cats" с Женей Кузовлевым
4) "Turn the ship around" с Екатериной Шестимеровой
5) "Project Phoenix" с Иваном Михеевым
6) Интервью про Staff+ инженеры, архитектура и SDLC с Алексеем Тарасовым
7) "Your brain at Work" с Эрнесто Инаркиевым
8) Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)
9) "An Elegant Puzzle - System of Engineering Management (часть 1)" с Eugene Sergueev
10) "An Elegant Puzzle - System of Engineering Management (часть 2)" с Eugene Sergueev
11) Интервью с Кириллом Крайневым про системных аналитиков в Тинькофф
12) Интервью с Димой Гаевским про платформу Spirit (Internal developer platform) в Тинькофф
13) "Accelerate" с Игорем Курочкиным
14) Interview with Artem Ivanov about Risk Tech
15) Interview with Roman Lebed about Information security
16) "The Five Dysfunctions of a Team" с Андреем Соколовым
17) Interview with Anton Kosterin about Architecture Governance
18) Interview with Pavel Akhmetchanov about Processes and Tools
19) Interview with Evgeny Sokolov about Modern Education
20) Interview with Alexey Grishin about Software Architecture
21) "A Philosophy of Software Design" с Гришей Скобелевым
#Architecture #Processes #Management #Leadership #Software #Statistics #Project #Productivity #ProductManagement
🔥25👍6❤2⚡2
Assessing IT Project Success: Perception vs. Reality (Рубрика #Management)
Эта статья была опубликована в сентябре в ACM Queue и она посвящена рассмотрению изменяющегося понимания успеха IT проектов. Раньше эту тему активно педалировали ребята из Standish Group, еще в 1994 году рассказывая в "The CHAOS Report" о том, что большая часть IT проектов проваливается. Они рассматривали успех с точки зрения не просто проекта, а проектного управления, а точнее попадания в проектный треугольник: сроки, бюджет и scope.
Но авторы нового исследования задумались о том, а какие еще есть объективные показатели помимо этих метрик, по которым можно оценить успешность проекта. Они выбрали следующие дополнительные метрики
- Level of global success achieved
Level of compliance with the scope, time, and cost
- Level of vendor (supplier) satisfaction
- Level of client satisfaction
- Deliverables impact
- Achievement of benefits verified in the project.
Для проведения исследования использовались опросы с участием опытных менеджеров IT-проектов из различных отраслей и регионов. Респондентов попросили оценить один недавно завершенный проект с помощью детализированной анкеты, включающей как субъективные оценки, так и объективные критерии. Ответы предполагалось давать по шкале Лайкерта, а всего было заполнено порядка 200 опросов. Надо было выбрать проект, который закончился больше полугода назад - это позволяло ответить на дополнительные вопросы про
- Использование клиентом результатов проекта на постпроектной стадии.
- Найм клиентом специалистов для поддержки или обслуживания проекта.
- Заключение клиентом новых контрактов с тем же подрядчиком.
- Рекомендации клиента данного подрядчика другим.
Основными выводами исследования стало то, что вопреки распространенному мнению о частых неудачах IT-проектов (например, согласно отчетам Chaos Reports группы Standish) большинство IT-проектов достигают высокого уровня успеха. В частности, 90,16% опрошенных проектов получили оценки выше среднего уровня по глобальной шкале успеха, а 61,66% достигли двух верхних уровней. По расширенным критериям, описанным выше результаты проектов тоже показывают высокую долю успеха. Интересно, что обнаружена положительная корреляция между глобальным успехом проекта и такими факторами, как удовлетворенность клиента (ρ = 0.714), выгоды для клиента (ρ = 0.751) и удовлетворенность подрядчика (ρ = 0.653). Это подчеркивает важность ориентированности на результаты для клиента как ключевого индикатора успеха.
В будущих исследованиях авторы рекомендуют начать учитывать мнения различных заинтересованных сторон (например, конечных пользователей, спонсоров) для получения более целостной картины. Практикам проектного менеджмента авторы рекомендуют оценивать не только показатели выполнения проекта, но и долгосрочные результаты, такие как удовлетворенность клиентов и выгоды для бизнеса. Такой подход позволит организациям лучше понимать и улучшать свои методы управления проектами. Я это трактую так, что стоит использовать продуктовый подход, так как часто результатом проекта является новый продукт или изменение существующего, а долговременным результатом проекта является успех этого продукта:)
Итого, в этом исследовании дан более комплексный взгляд на успех IT-проектов, по сравнению с демагогией от Standish Group. И это исследование показывает, что многие IT-проекты достигают значительных успехов при всесторонней оценке, бросая вызов устаревшим представлениям о повсеместных неудачах в этой области. Исследование подчеркивает необходимость развития рамок оценки для учета многогранности современных IT-проектов:)
#Management #Processes #Leadership #Project #Product
Эта статья была опубликована в сентябре в ACM Queue и она посвящена рассмотрению изменяющегося понимания успеха IT проектов. Раньше эту тему активно педалировали ребята из Standish Group, еще в 1994 году рассказывая в "The CHAOS Report" о том, что большая часть IT проектов проваливается. Они рассматривали успех с точки зрения не просто проекта, а проектного управления, а точнее попадания в проектный треугольник: сроки, бюджет и scope.
The project is completed on time and on budget, with all features and functions as initially specified.
Но авторы нового исследования задумались о том, а какие еще есть объективные показатели помимо этих метрик, по которым можно оценить успешность проекта. Они выбрали следующие дополнительные метрики
- Level of global success achieved
Level of compliance with the scope, time, and cost
- Level of vendor (supplier) satisfaction
- Level of client satisfaction
- Deliverables impact
- Achievement of benefits verified in the project.
Для проведения исследования использовались опросы с участием опытных менеджеров IT-проектов из различных отраслей и регионов. Респондентов попросили оценить один недавно завершенный проект с помощью детализированной анкеты, включающей как субъективные оценки, так и объективные критерии. Ответы предполагалось давать по шкале Лайкерта, а всего было заполнено порядка 200 опросов. Надо было выбрать проект, который закончился больше полугода назад - это позволяло ответить на дополнительные вопросы про
- Использование клиентом результатов проекта на постпроектной стадии.
- Найм клиентом специалистов для поддержки или обслуживания проекта.
- Заключение клиентом новых контрактов с тем же подрядчиком.
- Рекомендации клиента данного подрядчика другим.
Основными выводами исследования стало то, что вопреки распространенному мнению о частых неудачах IT-проектов (например, согласно отчетам Chaos Reports группы Standish) большинство IT-проектов достигают высокого уровня успеха. В частности, 90,16% опрошенных проектов получили оценки выше среднего уровня по глобальной шкале успеха, а 61,66% достигли двух верхних уровней. По расширенным критериям, описанным выше результаты проектов тоже показывают высокую долю успеха. Интересно, что обнаружена положительная корреляция между глобальным успехом проекта и такими факторами, как удовлетворенность клиента (ρ = 0.714), выгоды для клиента (ρ = 0.751) и удовлетворенность подрядчика (ρ = 0.653). Это подчеркивает важность ориентированности на результаты для клиента как ключевого индикатора успеха.
В будущих исследованиях авторы рекомендуют начать учитывать мнения различных заинтересованных сторон (например, конечных пользователей, спонсоров) для получения более целостной картины. Практикам проектного менеджмента авторы рекомендуют оценивать не только показатели выполнения проекта, но и долгосрочные результаты, такие как удовлетворенность клиентов и выгоды для бизнеса. Такой подход позволит организациям лучше понимать и улучшать свои методы управления проектами. Я это трактую так, что стоит использовать продуктовый подход, так как часто результатом проекта является новый продукт или изменение существующего, а долговременным результатом проекта является успех этого продукта:)
Итого, в этом исследовании дан более комплексный взгляд на успех IT-проектов, по сравнению с демагогией от Standish Group. И это исследование показывает, что многие IT-проекты достигают значительных успехов при всесторонней оценке, бросая вызов устаревшим представлениям о повсеместных неудачах в этой области. Исследование подчеркивает необходимость развития рамок оценки для учета многогранности современных IT-проектов:)
#Management #Processes #Leadership #Project #Product
🔥4❤2👍2
How to Deliver Quality Software Against All Odds • Daniel Terhorst-North & Julian Wood • GOTO 2024 (Рубрика #Management)
Интересное интервью Дэниела Терхорст-Норта, которое он дал Джулиану Вуду в рамках конференции goto. Интересно, что Daniel - это первый сотрудник лондонского офиса ThoughWorks, который когда-то давно в прошлом помог нанять туда звездную команду, многие из которых уже написали книги и часто выступают на goto конференциях. Но если возвращаться к тезисам доклада, то вот они
1) Дэниэль начинает с воспоминаний о том, как 20 лет назад он в рамках конфы сидел на дискуссии с Мартином Фаулером:) Он говорит, что конференции goto и yow были для него местом получения знаний и инсайтов (там выступали сами создатели технологий)
2) За последние 20 лет многие технологии и подходы прошли путь от новинок до буквально commodity. Например, потрепанный жизнью Agile, который стал просто маркетинговым термином, но вот например adoption CI/CD подходов пока не слишком хорощ (по мнению автора)
3) Сейчас актуальна тема эффективности использования ресурсов, автор упоминает про serverless в этом контексте.
4) Даниэль вспоминает про подход impact mapping от Гойко Аджича, про который я уже рассказывал. Этот инструмент стал популярным для создания гипотез и бизнесовых планов в виде mind maps. А это уже помогает правильно собрать эффективную архитектуру под требования бизнеса. Даниэль предлагает рассматривать архитектуру с точки зрения экономических драйверов
6) Дэниэль был пионером BDD (behavior-driven development) и создал jbehave, поэтому ребята обсудили связь BDD с разработкой, а также с TDD (test-driven development)
7) Даниэль поучаствовал в создании книги 97 вещей, которые должен знать каждый программист", куда он принес принцип о том, что надо писать код, используя язык бизнеса (аля ubiquitous language). Он рассказал пример о том, как это помогло ему в сложном проекте при его рефакторинге и понимании бизнес-правил
😍 Дальше Даниэль размышляет про DDD и важность понимания бизнесовой составляющей для программистов
9) Даниэль интересно рассказывает про свой путь в Thoughtworks, сбор команды и ранние проекты - очень интересно заглянуть за кулисы этого консультанта аля BCG, но из мира технологий:)
10) Так автор доходит до того, что они внедряли CI/CD и DevOps своим клиентам, когда этих слов еще не знали:)
11) Отдельно прикольно, как автор описывает проблемы крупных изменений в организациях - он сейчас консультирует разных заказчиков и есть проблемы с тем, чтобы преодолеит инерцию, запустить изменения и не потерять всю команды на их волне:)
12) К Даниэлю часто заходят топ-менеджеры крупных компаний за помощью в изменениях и он не может рекомендовать ни одной серебрянной пули, поэтому приходиться разбираться на месте с тем, что требуется и как этого достичь:)
13) Даниэль отмечает важность управления продуктом (do the right things), но он говорит, что это не его - он умеет в delivery (do the things right) и зачастую он работает в паре с крутыми CPO (chief product officer), чтобы создавать крутые продукты
14) Даниэль очень точно показывает разницу между продуктами и проектами, которая состоит в том, что мы по разному их финансируем и по разному подходим к управлению рисками (это прямо в точку)
15) У Даниэля есть проблемы с реализацией своих идей - у него их много, но он не умеет доводить свои личные проекты до конца. Уже больше 10 лет он пишет книгу "Software, faster" (еще с 2011-2012 года), но так и не дописал ее, а вот книгу "Patterns of effective teams" он почти дописал и это заслуга со-автора, что ограничил полет фантазии Даниэля:)
16) Напоследок ребята обсудили выступление Даниэля "Лучший программист, которого я знаю", про которое я расскажу отдельно, а дальше финализировали тезисами
- При разработке продукта люди являются ключевыми участниками процесса
- Цель - повлиять на изменение поведения и сделать жизнь веселее
P.S.
У Даниэля есть и другие выступления, про которые я рассказывал
- How to Bake a Change
- The Most Dangerous Phrase
#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking
Интересное интервью Дэниела Терхорст-Норта, которое он дал Джулиану Вуду в рамках конференции goto. Интересно, что Daniel - это первый сотрудник лондонского офиса ThoughWorks, который когда-то давно в прошлом помог нанять туда звездную команду, многие из которых уже написали книги и часто выступают на goto конференциях. Но если возвращаться к тезисам доклада, то вот они
1) Дэниэль начинает с воспоминаний о том, как 20 лет назад он в рамках конфы сидел на дискуссии с Мартином Фаулером:) Он говорит, что конференции goto и yow были для него местом получения знаний и инсайтов (там выступали сами создатели технологий)
2) За последние 20 лет многие технологии и подходы прошли путь от новинок до буквально commodity. Например, потрепанный жизнью Agile, который стал просто маркетинговым термином, но вот например adoption CI/CD подходов пока не слишком хорощ (по мнению автора)
3) Сейчас актуальна тема эффективности использования ресурсов, автор упоминает про serverless в этом контексте.
4) Даниэль вспоминает про подход impact mapping от Гойко Аджича, про который я уже рассказывал. Этот инструмент стал популярным для создания гипотез и бизнесовых планов в виде mind maps. А это уже помогает правильно собрать эффективную архитектуру под требования бизнеса. Даниэль предлагает рассматривать архитектуру с точки зрения экономических драйверов
6) Дэниэль был пионером BDD (behavior-driven development) и создал jbehave, поэтому ребята обсудили связь BDD с разработкой, а также с TDD (test-driven development)
7) Даниэль поучаствовал в создании книги 97 вещей, которые должен знать каждый программист", куда он принес принцип о том, что надо писать код, используя язык бизнеса (аля ubiquitous language). Он рассказал пример о том, как это помогло ему в сложном проекте при его рефакторинге и понимании бизнес-правил
😍 Дальше Даниэль размышляет про DDD и важность понимания бизнесовой составляющей для программистов
9) Даниэль интересно рассказывает про свой путь в Thoughtworks, сбор команды и ранние проекты - очень интересно заглянуть за кулисы этого консультанта аля BCG, но из мира технологий:)
10) Так автор доходит до того, что они внедряли CI/CD и DevOps своим клиентам, когда этих слов еще не знали:)
11) Отдельно прикольно, как автор описывает проблемы крупных изменений в организациях - он сейчас консультирует разных заказчиков и есть проблемы с тем, чтобы преодолеит инерцию, запустить изменения и не потерять всю команды на их волне:)
12) К Даниэлю часто заходят топ-менеджеры крупных компаний за помощью в изменениях и он не может рекомендовать ни одной серебрянной пули, поэтому приходиться разбираться на месте с тем, что требуется и как этого достичь:)
13) Даниэль отмечает важность управления продуктом (do the right things), но он говорит, что это не его - он умеет в delivery (do the things right) и зачастую он работает в паре с крутыми CPO (chief product officer), чтобы создавать крутые продукты
14) Даниэль очень точно показывает разницу между продуктами и проектами, которая состоит в том, что мы по разному их финансируем и по разному подходим к управлению рисками (это прямо в точку)
15) У Даниэля есть проблемы с реализацией своих идей - у него их много, но он не умеет доводить свои личные проекты до конца. Уже больше 10 лет он пишет книгу "Software, faster" (еще с 2011-2012 года), но так и не дописал ее, а вот книгу "Patterns of effective teams" он почти дописал и это заслуга со-автора, что ограничил полет фантазии Даниэля:)
16) Напоследок ребята обсудили выступление Даниэля "Лучший программист, которого я знаю", про которое я расскажу отдельно, а дальше финализировали тезисами
- При разработке продукта люди являются ключевыми участниками процесса
- Цель - повлиять на изменение поведения и сделать жизнь веселее
P.S.
У Даниэля есть и другие выступления, про которые я рассказывал
- How to Bake a Change
- The Most Dangerous Phrase
#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking
1❤7👍4🔥1
The Best Programmer I Know • Daniel Terhorst-North • GOTO 2024 (Рубрика #Leadership)
Интересное выступление Дэниела Терхорст-Норта (презентация тоже доступна), в котором он поделился своими наблюдениями о том, что делает хорошего программиста отличным. Фактически он разбил все наблюдения на три категории
1) Getting the job done
2) Choosing the right tool
3) Caring about the team
Part 1 - Getting the job done
1) Just start - для того, чтобы сделать работу, важно ее начать, а многим инженерам перфекционизм мешает это сделать:)
- Resist procrastinating - иногда перфекционизм превращается в прокрастинацию, с которой надо бороться
- Know you don’t know - первая версия не обязана быть правильной или хорошей, все равно она будет переписана
- Iterate wildly - это про test and learn и извлечение знаний из опыта (Try, fail, learn, repeat)
2) Build a product - мы не просто пишем код, а создаем продукт
- Invest in the outcome - собственно, должна быть какая-то цель и привязанность должна быть не к коду, а к достижению результата
- Study the domain - важно понимать домен и разговаривать на языке домена
- Watch your users - лучший способ получить обратную связь от пользователей — провести время с ними. Так вы сможете понять что мешает им и поправить это в продукте
3) Solve for now
- Learn to see what is really there - важно научиться видеть глубже
- Solve the real problem - важно решать реальные проблемы, а не те, которые кажутся таковыми.
- Strive for simplicity - нужно стремиться к простым решениям, а не плодить complexitty
Part 2: Choosing the right tool
1) Choosing the right tool for the product, not the team! - выбор инструментов должен основываться на продукте и ситуации, а не на предпочтениях команды.
- Teams can learn! - внутри команд работают инженеры, которые могут учиться новому:)
- Do the simplest thing, not the easiest - нужно выбирать инструменты, которые лучше подходят для решения конкретной проблемы.
- The ‘right tool’ may change over time - тут пример Scala для создания первой версии торговой системы, а потом замена ее на другой язык
2) Make the change easy
- Minimise blast radius - для упрощения изменений надо ограничить радиус их поражения:)
- Reduce, reuse, recycle - надо строить модульную систему, чтобы можно было менять отдельные компоненты
- Then do the same with production code! - Дэн рекомендует упрощать и продакшен код (рефакторинг)
3) Be a polyglot - важно быть универсальным разработчиком
- Explore languages, tools, paradigms - Дэну часто помогает с этим Advent of Code - 25-дневная игра с головоломками.
- Be ‘full-stack’ - тут про фронт, бек, API, мобилу
- Be really full-stack - здесь про инженерные процессы, железо и вопросы к тому, а зачем мы вообще делаем задачу:)
Part 3: Caring about the team
1) Caring about others
- Find joy in helping others learn - лидерские качества, работа в команде, наставничество и коучинг важны.
- Send the team home! - нет переработкам
- Be kind - предполагай, что люди вокруг делают лучшее из возможного, а также работай над психологической безопасностью в команде (подробнее я говорил об этом при обзоре проекта "Google's Project Aristotle" про команды)
2) Caring about staying current
- Join communities - контрибьють в коммьюнити и знакомься с новыми крутыми людьми
- Try new things - но подходи к этому со здоровым скептицизмом
- Practise, practise, practise - чтобы быть хорошим инженером, надо практиковаться
3) Caring about yourself
- Have interests outside of programming - нужны хобби вовне:)
- Go home on time - не забывай о доме
- Be kind to yourself - будь добр к себе и ведите себя так, как хотите, чтобы вели себя другие
Итого
- Наша работа - создавать полезные продукты, а не писать программы.
- Выбирайте правильные инструменты для конкретной ситуации.
- Заботьтесь о команде, себе и своем развитии.
P.S.
У Даниэля есть и другие выступления, про которые я рассказывал
- How to Bake a Change
- The Most Dangerous Phrase
- How to Deliver Quality Software Against All Odds
#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking
Интересное выступление Дэниела Терхорст-Норта (презентация тоже доступна), в котором он поделился своими наблюдениями о том, что делает хорошего программиста отличным. Фактически он разбил все наблюдения на три категории
1) Getting the job done
2) Choosing the right tool
3) Caring about the team
Part 1 - Getting the job done
1) Just start - для того, чтобы сделать работу, важно ее начать, а многим инженерам перфекционизм мешает это сделать:)
- Resist procrastinating - иногда перфекционизм превращается в прокрастинацию, с которой надо бороться
- Know you don’t know - первая версия не обязана быть правильной или хорошей, все равно она будет переписана
- Iterate wildly - это про test and learn и извлечение знаний из опыта (Try, fail, learn, repeat)
2) Build a product - мы не просто пишем код, а создаем продукт
- Invest in the outcome - собственно, должна быть какая-то цель и привязанность должна быть не к коду, а к достижению результата
- Study the domain - важно понимать домен и разговаривать на языке домена
- Watch your users - лучший способ получить обратную связь от пользователей — провести время с ними. Так вы сможете понять что мешает им и поправить это в продукте
3) Solve for now
- Learn to see what is really there - важно научиться видеть глубже
- Solve the real problem - важно решать реальные проблемы, а не те, которые кажутся таковыми.
- Strive for simplicity - нужно стремиться к простым решениям, а не плодить complexitty
Part 2: Choosing the right tool
1) Choosing the right tool for the product, not the team! - выбор инструментов должен основываться на продукте и ситуации, а не на предпочтениях команды.
- Teams can learn! - внутри команд работают инженеры, которые могут учиться новому:)
- Do the simplest thing, not the easiest - нужно выбирать инструменты, которые лучше подходят для решения конкретной проблемы.
- The ‘right tool’ may change over time - тут пример Scala для создания первой версии торговой системы, а потом замена ее на другой язык
2) Make the change easy
- Minimise blast radius - для упрощения изменений надо ограничить радиус их поражения:)
- Reduce, reuse, recycle - надо строить модульную систему, чтобы можно было менять отдельные компоненты
- Then do the same with production code! - Дэн рекомендует упрощать и продакшен код (рефакторинг)
3) Be a polyglot - важно быть универсальным разработчиком
- Explore languages, tools, paradigms - Дэну часто помогает с этим Advent of Code - 25-дневная игра с головоломками.
- Be ‘full-stack’ - тут про фронт, бек, API, мобилу
- Be really full-stack - здесь про инженерные процессы, железо и вопросы к тому, а зачем мы вообще делаем задачу:)
Part 3: Caring about the team
1) Caring about others
- Find joy in helping others learn - лидерские качества, работа в команде, наставничество и коучинг важны.
- Send the team home! - нет переработкам
- Be kind - предполагай, что люди вокруг делают лучшее из возможного, а также работай над психологической безопасностью в команде (подробнее я говорил об этом при обзоре проекта "Google's Project Aristotle" про команды)
2) Caring about staying current
- Join communities - контрибьють в коммьюнити и знакомься с новыми крутыми людьми
- Try new things - но подходи к этому со здоровым скептицизмом
- Practise, practise, practise - чтобы быть хорошим инженером, надо практиковаться
3) Caring about yourself
- Have interests outside of programming - нужны хобби вовне:)
- Go home on time - не забывай о доме
- Be kind to yourself - будь добр к себе и ведите себя так, как хотите, чтобы вели себя другие
Итого
- Наша работа - создавать полезные продукты, а не писать программы.
- Выбирайте правильные инструменты для конкретной ситуации.
- Заботьтесь о команде, себе и своем развитии.
P.S.
У Даниэля есть и другие выступления, про которые я рассказывал
- How to Bake a Change
- The Most Dangerous Phrase
- How to Deliver Quality Software Against All Odds
#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking
YouTube
The Best Programmer I Know • Daniel Terhorst-North • GOTO 2024
This presentation was recorded at GOTO Amsterdam 2024. #GOTOcon #GOTOams
https://gotoams.nl
Daniel Terhorst-North - Originator of Behavior Driven Development (BDD) & Principal at Dan North & Associates @daniel-terhorst-north
RESOURCES
https://bsky.app…
https://gotoams.nl
Daniel Terhorst-North - Originator of Behavior Driven Development (BDD) & Principal at Dan North & Associates @daniel-terhorst-north
RESOURCES
https://bsky.app…
❤18🔥8👍6🤔1
Code of Leadership #25 - Interview with Anastasia Kabishcheva about group dynamics and BART Model (Рубрика #Management)
В этом выпуске подкаста речь идет про групповую динамику и модель BART (boundaries - authorities - roles - tasks), а в гостях у меня Анастасия Кабищева - организационный консультант и ментор, которая помогает разобрать эту сложную тему за счет своего опыта. Настя работала в разных ИТ-компаниях в качестве менеджера проектов и портфельного менеджера проектов, пересобирала команды для проектов заказной разработки, а сейчас заканчивает магистратуру по психоанализу в Вышке и пишет диссертацию на тему профессиональной идентичности продакт менеджеров. Кстати, эпизод доступен и в Ya Music.
За время выпуска мы успели обсудить следующие темы
- Что такое групповая динамика и чем ее знание может быть полезно
- Что такое идентичность человека / компании и как это связано с корпоративной культурой
- Как работают культурные принципы и причем здесь антропология
- Что такое модель BART и как она может помочь руководителю
- Что такое модель Такмана и как она связана с BART
- Как связано лидерство и алгоритм консенсуса Raft
- Как думать о политике внутри компании в парадигме теории игр, шахмат, го, ...
- Как изучить групповую динамику на практике
Дополнительные материалы
0. Сайт Анастасии "Soulcoaching"
1. Конференция про психоаналитические техники работы с бизнесом (10 декабря 2024) - Промокод для подписчиков канала - ENERGY50 (скидка на билет 50%)
2. Конференция GRC онлайн
3. Книга «Бессознательное в организации» (Гирнальзик, Катуржевский, Ломер)
4. Книга "Личность и групповая динамика" (Стейпли)
5. Вопросы для каждого блока модели BART
6. Канал про офлайн конференции GRC
7. Фреймворк SPACE на тему developer productivity
8. Книга "The corporate tribe"
9. Эпизод "Code of Leadership" с разбором книги "5 пороков команды"
10. Интервью "How to Deliver Quality Software Against All Odds • Daniel Terhorst-North & Julian Wood • GOTO 2024"
#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking
В этом выпуске подкаста речь идет про групповую динамику и модель BART (boundaries - authorities - roles - tasks), а в гостях у меня Анастасия Кабищева - организационный консультант и ментор, которая помогает разобрать эту сложную тему за счет своего опыта. Настя работала в разных ИТ-компаниях в качестве менеджера проектов и портфельного менеджера проектов, пересобирала команды для проектов заказной разработки, а сейчас заканчивает магистратуру по психоанализу в Вышке и пишет диссертацию на тему профессиональной идентичности продакт менеджеров. Кстати, эпизод доступен и в Ya Music.
За время выпуска мы успели обсудить следующие темы
- Что такое групповая динамика и чем ее знание может быть полезно
- Что такое идентичность человека / компании и как это связано с корпоративной культурой
- Как работают культурные принципы и причем здесь антропология
- Что такое модель BART и как она может помочь руководителю
- Что такое модель Такмана и как она связана с BART
- Как связано лидерство и алгоритм консенсуса Raft
- Как думать о политике внутри компании в парадигме теории игр, шахмат, го, ...
- Как изучить групповую динамику на практике
Дополнительные материалы
0. Сайт Анастасии "Soulcoaching"
1. Конференция про психоаналитические техники работы с бизнесом (10 декабря 2024) - Промокод для подписчиков канала - ENERGY50 (скидка на билет 50%)
2. Конференция GRC онлайн
3. Книга «Бессознательное в организации» (Гирнальзик, Катуржевский, Ломер)
4. Книга "Личность и групповая динамика" (Стейпли)
5. Вопросы для каждого блока модели BART
6. Канал про офлайн конференции GRC
7. Фреймворк SPACE на тему developer productivity
8. Книга "The corporate tribe"
9. Эпизод "Code of Leadership" с разбором книги "5 пороков команды"
10. Интервью "How to Deliver Quality Software Against All Odds • Daniel Terhorst-North & Julian Wood • GOTO 2024"
#Processes #Management #Agile #Leadership #Software #Project #CriticalThinking
YouTube
Code of Leadership #25 - Interview with Anastasia about group dynamics and BART Model
В этом выпуске подкаста речь идет про групповую динамику и модель BART (boundaries - authorities - roles - tasks), а в гостях у меня Анастасия Кабищева - организационный консультант и ментор, которая помогает разобрать эту сложную тему за счет своего опыта.…
👍6🔥5❤3
Менеджмент ИТ-проектов (IT Project Management: On Track from Start to Finish) (Рубрика #Management)
Разбирал старые бумаги и наткнулся на свой сертификат руководителя проектов (PMP). На этом фоне решил вспомнить как 17 лет назад изучал целую пачку книг по управлению проектами, когда начал учиться в только что открывшейся магиструре IBS в МФТИ:) Тогда я купил и заботал несколько книг на эту тему, одна из которых оказалось именно этой книгой Джозефа Филлипса. Сама книга включала информацию по каждому этапу процесса управления проектом, включая инициацию, планирование, выполнение, мониторинг и завершение проектов. Основные темы, охватываемые в книге, включают определение требований к проекту, создание технико-экономических обоснований, управление объемом и расходами проекта, разработку планов управления проектом, организацию и руководство командами, отслеживание прогресса с использованием таких метрик, как индекс производительности по затратам, внедрение изменений и обеспечение постоянного управления качеством. Помню, что тогда мне книга не зашла, а перечитывая сейчас я понял почему - она написана формально и содержит нужную информацию, но она выглядит или формальной или очевидной. Чтобы достать что-то интересное, требуется иметь опыт и внимательно вчитываться в каждую главу. Отдельно автор активно промотировал сертификации в общем, а также экзамен CompTIA Project+ в частности:)
На голову выше были две книги, который я изучил еще в то время
- "Проектный бизнес - Адаптированная модель для России"
- "Rita Mulcahy's PMP® Exam Prep, Tenth Edition" (тут конечно издание было не последнее, а сильно более раннее)
Еще из интересного стоит отметить, что в магистратуре IBS учили не управлению проектами по PMI (Project Management Institute), а его альтернативе в виде IPMA (International Project Management Association), а точнее его локализованной российской версией в виде СОВНЕТ. Если говорить откровенно, то те же яйца, только в профиль:)
#Management #Leadership #Processes #Project #ProjectManagement
Разбирал старые бумаги и наткнулся на свой сертификат руководителя проектов (PMP). На этом фоне решил вспомнить как 17 лет назад изучал целую пачку книг по управлению проектами, когда начал учиться в только что открывшейся магиструре IBS в МФТИ:) Тогда я купил и заботал несколько книг на эту тему, одна из которых оказалось именно этой книгой Джозефа Филлипса. Сама книга включала информацию по каждому этапу процесса управления проектом, включая инициацию, планирование, выполнение, мониторинг и завершение проектов. Основные темы, охватываемые в книге, включают определение требований к проекту, создание технико-экономических обоснований, управление объемом и расходами проекта, разработку планов управления проектом, организацию и руководство командами, отслеживание прогресса с использованием таких метрик, как индекс производительности по затратам, внедрение изменений и обеспечение постоянного управления качеством. Помню, что тогда мне книга не зашла, а перечитывая сейчас я понял почему - она написана формально и содержит нужную информацию, но она выглядит или формальной или очевидной. Чтобы достать что-то интересное, требуется иметь опыт и внимательно вчитываться в каждую главу. Отдельно автор активно промотировал сертификации в общем, а также экзамен CompTIA Project+ в частности:)
На голову выше были две книги, который я изучил еще в то время
- "Проектный бизнес - Адаптированная модель для России"
- "Rita Mulcahy's PMP® Exam Prep, Tenth Edition" (тут конечно издание было не последнее, а сильно более раннее)
Еще из интересного стоит отметить, что в магистратуре IBS учили не управлению проектами по PMI (Project Management Institute), а его альтернативе в виде IPMA (International Project Management Association), а точнее его локализованной российской версией в виде СОВНЕТ. Если говорить откровенно, то те же яйца, только в профиль:)
#Management #Leadership #Processes #Project #ProjectManagement
👍8❤7🔥6🤗1
Code of Leadership & Research Insights Made Simple (Рубрика #Management)
В этом году я стартанул два подкаста - один про engineering management с интервью и разбором книг, а второй с разбором whitepapers. За год получилось пообщаться с большим количеством интересных гостей, спасибо каждому из них. А также спасибо все зрителям, слушателям и читателям. В качестве новогоднего поздравления я выложил все видео в VK, чтобы их можно было смотреть без ограничений
Code of Leadership
- Видео: Youtube, Vk Video
- Аудио: Podster, Ya Music
Описание отдельных эпизодов
01) "Team topologies" со Станиславом Халупом
02) "Antifragility in IT" с Александром Бындю
03) "Herding Cats" с Женей Кузовлевым
04) "Turn the ship around" с Екатериной Шестимеровой
05) "Project Phoenix" с Иваном Михеевым
06) Интервью про Staff+ инженеры, архитектура и SDLC с Алексеем Тарасовым
07) "Your brain at Work" с Эрнесто Инаркиевым
08) Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)
09) "An Elegant Puzzle - System of Engineering Management (часть 1)" с Eugene Sergueev
10) "An Elegant Puzzle - System of Engineering Management (часть 2)" с Eugene Sergueev
11) Интервью с Кириллом Крайневым про системных аналитиков в Тинькофф
12) Интервью с Димой Гаевским про платформу Spirit (Internal developer platform) в Тинькофф
13) "Accelerate" с Игорем Курочкиным
14) Interview with Artem Ivanov about Risk Tech
15) Interview with Roman Lebed about Information security
16) "The Five Dysfunctions of a Team" с Андреем Соколовым
17) Interview with Anton Kosterin about Architecture Governance
18) Interview with Pavel Akhmetchanov about Processes and Tools
19) Interview with Evgeny Sokolov about Modern Education
20) Interview with Alexey Grishin about Software Architecture
21) "A Philosophy of Software Design" с Гришей Скобелевым
22) Интервью с Дмитрием Аношиным про data engineering
23) Interview with Andrew Marchenko
24) Interview with Konstantin Evteev
25) Interview with Anastasia Kabishcheva about group dynamics and BART Model
26) Interview with Salikh Fakhrutdinov about SRE Growth and SRE Team
Reserach Insights Made Simple
- Видео: Youtube, Vk Video
- Аудио: Podster, Ya Music
Описание отдельных эпизодов
01) Обсуждение paper "API Governance at Scale" от Google
02) Обсуждение paper "Defining, measuring and managing technical debt"
03) Обсуждение paper "Security by Design at Google"
04) Обсуждение "AI-Enhanced API Design" от Google
05) Обсуждение "DORA Metrics, SPACE, DevEx, Human Approach to Dev Productivity"
06) Interview with Nikolay Golov about data platforms
07) Interview with Pavel Lakosnikov about Architecture Governance
#Architecture #Processes #Management #Leadership #Software #Statistics #Project #Productivity #ProductManagement
В этом году я стартанул два подкаста - один про engineering management с интервью и разбором книг, а второй с разбором whitepapers. За год получилось пообщаться с большим количеством интересных гостей, спасибо каждому из них. А также спасибо все зрителям, слушателям и читателям. В качестве новогоднего поздравления я выложил все видео в VK, чтобы их можно было смотреть без ограничений
Code of Leadership
- Видео: Youtube, Vk Video
- Аудио: Podster, Ya Music
Описание отдельных эпизодов
01) "Team topologies" со Станиславом Халупом
02) "Antifragility in IT" с Александром Бындю
03) "Herding Cats" с Женей Кузовлевым
04) "Turn the ship around" с Екатериной Шестимеровой
05) "Project Phoenix" с Иваном Михеевым
06) Интервью про Staff+ инженеры, архитектура и SDLC с Алексеем Тарасовым
07) "Your brain at Work" с Эрнесто Инаркиевым
08) Интервью с Андреем Цыбиным про Statist (система для продуктовой аналитики)
09) "An Elegant Puzzle - System of Engineering Management (часть 1)" с Eugene Sergueev
10) "An Elegant Puzzle - System of Engineering Management (часть 2)" с Eugene Sergueev
11) Интервью с Кириллом Крайневым про системных аналитиков в Тинькофф
12) Интервью с Димой Гаевским про платформу Spirit (Internal developer platform) в Тинькофф
13) "Accelerate" с Игорем Курочкиным
14) Interview with Artem Ivanov about Risk Tech
15) Interview with Roman Lebed about Information security
16) "The Five Dysfunctions of a Team" с Андреем Соколовым
17) Interview with Anton Kosterin about Architecture Governance
18) Interview with Pavel Akhmetchanov about Processes and Tools
19) Interview with Evgeny Sokolov about Modern Education
20) Interview with Alexey Grishin about Software Architecture
21) "A Philosophy of Software Design" с Гришей Скобелевым
22) Интервью с Дмитрием Аношиным про data engineering
23) Interview with Andrew Marchenko
24) Interview with Konstantin Evteev
25) Interview with Anastasia Kabishcheva about group dynamics and BART Model
26) Interview with Salikh Fakhrutdinov about SRE Growth and SRE Team
Reserach Insights Made Simple
- Видео: Youtube, Vk Video
- Аудио: Podster, Ya Music
Описание отдельных эпизодов
01) Обсуждение paper "API Governance at Scale" от Google
02) Обсуждение paper "Defining, measuring and managing technical debt"
03) Обсуждение paper "Security by Design at Google"
04) Обсуждение "AI-Enhanced API Design" от Google
05) Обсуждение "DORA Metrics, SPACE, DevEx, Human Approach to Dev Productivity"
06) Interview with Nikolay Golov about data platforms
07) Interview with Pavel Lakosnikov about Architecture Governance
#Architecture #Processes #Management #Leadership #Software #Statistics #Project #Productivity #ProductManagement
🔥24❤7🆒5👍4
[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
[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