Forwarded from Бессознательное в организации
Отрицание как защита в организациях
#защиты #психодинамика #отрицание
На днях обсуждали в небольшом профессиональном кругу вопрос: "как организации реагируют на события последних дней". Кто-то создает ситуационные центры, кто-то просчитывает риски, кто-то готовит запасы, кто-то ищет новые рынки. Но кроме всего прочего прозвучали и примеры, когда в компаниях было принято решение "не обсуждать и не реагировать на эти события".
Отрицание, хочу напомнить, это одна из примитивных форм психологической защиты. Примитивная - значит детская, т.е. лидеры организаций очень сильно регрессировали.
Также можно вспомнить, что Шок-Отрицание это первая стадия горевания по Кублер-Росс. А значит лидеры организаций не смогли после регресса восстановится за эти несколько недель. И организации, которые они возглавляют, застыли в этой защите вместе с ними.
Есть примеры, когда руководители даже запрещают вообще на работе "подобные разговоры". И мы можем предположить, что идет запрет и на переживания: ведь "мы профессионалы и должны держать эмоции при себе".
Запрет на эмоции, вытеснение их в область бессознательного означает, что напряжение не осознается и не отпускается, а запихивается глубоко. И оно будет там бродить, и человек будет отыгрывать: кричать на людей или наоборот сворачиваться калачиком и плакать, страдать от хронической усталости или заболевать (гастритами, головными болями, мышечными спазмами и иными болезнями).
И при таком поведении, конечно же, лидеры и сотрудники становятся бесполезными для организаций. А в некоторых случаях - и токсичными.
Организация перестает быть контейнером для сотрудников, и остается только источником тревог. Сотрудники, предоставленные самим себе, врубают персональные психологические защиты, которые приводят к дополнительным конфликтам внутренним и организационным.
В таких условиях как грибы начинают расти группы базовых эмоциональных допущений. Команды перестают быть командами, но становятся группами
людей, сфокусированных не на задачах организации, а на уменьшении тревоги, которая исходит от организации. Люди занимаются чем угодно, лишь бы заглушить эту звенящую тревогу. Работа - только один из способов справится с этим, и она не самый популярный способ.
Что это значит для лидеров и что с этим нужно делать?
Если горевание затянулось, то жизнеспособность организации поставлена под вопрос. Необходимо начать приспосабливаться к новой реальности.
Для начала нужно помочь себе. Далее советы из разряда привет капитан, но эти вещи и активности должны в каком-то виде присутствовать в нашей жизни:
- Достаточный и продолжительный сон.
- Информационная гигиена. Исключать из своего рациона информацию, которая тревожит и ситуации повлиять на которые вы лично не можете. Исключение каналов, людей и групп людей из своего поля.
- Практики заземления и расслабления. Это и работа с дыханием, и растяжки и пр. - интернет сейчас переполнен этими практиками. Выберите 1-2 и используйте их.
- Круг поддержки. Люди, с которыми спокойно, и с которыми можно заземлится.
- Помощь специалистов (психологи, психотерапевты). Войти в контакт со своими эмоциями, принять свои эмоции, отлепить от себя эмоции других людей.
- Спорт и работа с телом. Не поднимание тяжестей, что вызывает выброс адреналина и кстати дополнительный выброс кортизола. Правильный выбор - умеренный бег, плавание, скандинавская ходьба, массаж, баня и пр.
- Рутины и ритуалы- простые понятные практики, которые позволяют удержаться в реальности.
Что необходимо сделать в организациях:
- Признать ситуацию на уровне организации и дать посыл сотрудникам, что вы будете работать вместе.
- Не дистанцироваться от людей.
- Сформировать и поддерживать контейнирующие структуры. Необходимы и рефлексивно-эмпатические и структурно функциональные (MHFA, ситуационные центры, периодические апдейты о ситуации, психологическая помощь специалистов, работы в группах, супервизии, группы по интересам, работа сообществ и пр. пр. пр.).
#защиты #психодинамика #отрицание
На днях обсуждали в небольшом профессиональном кругу вопрос: "как организации реагируют на события последних дней". Кто-то создает ситуационные центры, кто-то просчитывает риски, кто-то готовит запасы, кто-то ищет новые рынки. Но кроме всего прочего прозвучали и примеры, когда в компаниях было принято решение "не обсуждать и не реагировать на эти события".
Отрицание, хочу напомнить, это одна из примитивных форм психологической защиты. Примитивная - значит детская, т.е. лидеры организаций очень сильно регрессировали.
Также можно вспомнить, что Шок-Отрицание это первая стадия горевания по Кублер-Росс. А значит лидеры организаций не смогли после регресса восстановится за эти несколько недель. И организации, которые они возглавляют, застыли в этой защите вместе с ними.
Есть примеры, когда руководители даже запрещают вообще на работе "подобные разговоры". И мы можем предположить, что идет запрет и на переживания: ведь "мы профессионалы и должны держать эмоции при себе".
Запрет на эмоции, вытеснение их в область бессознательного означает, что напряжение не осознается и не отпускается, а запихивается глубоко. И оно будет там бродить, и человек будет отыгрывать: кричать на людей или наоборот сворачиваться калачиком и плакать, страдать от хронической усталости или заболевать (гастритами, головными болями, мышечными спазмами и иными болезнями).
И при таком поведении, конечно же, лидеры и сотрудники становятся бесполезными для организаций. А в некоторых случаях - и токсичными.
Организация перестает быть контейнером для сотрудников, и остается только источником тревог. Сотрудники, предоставленные самим себе, врубают персональные психологические защиты, которые приводят к дополнительным конфликтам внутренним и организационным.
В таких условиях как грибы начинают расти группы базовых эмоциональных допущений. Команды перестают быть командами, но становятся группами
людей, сфокусированных не на задачах организации, а на уменьшении тревоги, которая исходит от организации. Люди занимаются чем угодно, лишь бы заглушить эту звенящую тревогу. Работа - только один из способов справится с этим, и она не самый популярный способ.
Что это значит для лидеров и что с этим нужно делать?
Если горевание затянулось, то жизнеспособность организации поставлена под вопрос. Необходимо начать приспосабливаться к новой реальности.
Для начала нужно помочь себе. Далее советы из разряда привет капитан, но эти вещи и активности должны в каком-то виде присутствовать в нашей жизни:
- Достаточный и продолжительный сон.
- Информационная гигиена. Исключать из своего рациона информацию, которая тревожит и ситуации повлиять на которые вы лично не можете. Исключение каналов, людей и групп людей из своего поля.
- Практики заземления и расслабления. Это и работа с дыханием, и растяжки и пр. - интернет сейчас переполнен этими практиками. Выберите 1-2 и используйте их.
- Круг поддержки. Люди, с которыми спокойно, и с которыми можно заземлится.
- Помощь специалистов (психологи, психотерапевты). Войти в контакт со своими эмоциями, принять свои эмоции, отлепить от себя эмоции других людей.
- Спорт и работа с телом. Не поднимание тяжестей, что вызывает выброс адреналина и кстати дополнительный выброс кортизола. Правильный выбор - умеренный бег, плавание, скандинавская ходьба, массаж, баня и пр.
- Рутины и ритуалы- простые понятные практики, которые позволяют удержаться в реальности.
Что необходимо сделать в организациях:
- Признать ситуацию на уровне организации и дать посыл сотрудникам, что вы будете работать вместе.
- Не дистанцироваться от людей.
- Сформировать и поддерживать контейнирующие структуры. Необходимы и рефлексивно-эмпатические и структурно функциональные (MHFA, ситуационные центры, периодические апдейты о ситуации, психологическая помощь специалистов, работы в группах, супервизии, группы по интересам, работа сообществ и пр. пр. пр.).
👍25😁1
Александр Поломодов @apolomodov продолжает писать о прочитанных книгах (считаю, что мышление письмом очень помогает усваивать знания). В этот раз это обзор книги @vladik_kh
Если не читали – можно пробежать по верхам, если уже прочитали, то можно сверить часы.
https://apolomodov.medium.com/обзор-книги-what-is-domain-driven-design-7128373196e8
Если не читали – можно пробежать по верхам, если уже прочитали, то можно сверить часы.
https://apolomodov.medium.com/обзор-книги-what-is-domain-driven-design-7128373196e8
Medium
Обзор книги “What Is Domain-Driven Design?”
DDD или Domain Driven Design — это концепция введенная Эриком Эвансом в одноименной книги в 2003 года, а значит ей скоро исполнится 20 лет…
🔥14👍3
Читаю сейчас не спеша новую книгу Вернона. Оказывается по следам публикации книги вышел подкаст на se-radio https://www.se-radio.net/2022/01/episode-495-vaughn-vernon-on-strategic-monoliths-and-microservices/
В целом ничего неожиданного, но Вернона всегда интересно послушать)
В целом ничего неожиданного, но Вернона всегда интересно послушать)
👍5😁1
Вышел новый техрадар thoughtworks.com/radar
Что приглянулось, чтоб подробнее поразбираться:
- транзитивная архитектура https://martinfowler.com/articles/patterns-legacy-displacement/transitional-architecture.html
- КУПИДон https://dannorth.net/2022/02/10/cupid-for-joyful-coding/
- Четыре ключевые метрики https://www.thoughtworks.com/radar/techniques?blipid=1298
- Сальса https://slsa.dev/
- https://www.testcontainers.org/
и многое другое.
Как вам эта версия радара? Что вы отметили для себя на будущее?
Что приглянулось, чтоб подробнее поразбираться:
- транзитивная архитектура https://martinfowler.com/articles/patterns-legacy-displacement/transitional-architecture.html
- КУПИДон https://dannorth.net/2022/02/10/cupid-for-joyful-coding/
- Четыре ключевые метрики https://www.thoughtworks.com/radar/techniques?blipid=1298
- Сальса https://slsa.dev/
- https://www.testcontainers.org/
и многое другое.
Как вам эта версия радара? Что вы отметили для себя на будущее?
Thoughtworks
Technology Radar | Guide to technology landscape
The Technology Radar is an opinionated guide to today's technology landscape. Read the latest here.
👍13🔥1
Транзитивная архитектура – только один из паттернов поставки для замещения легаси.
Помимо паттернов поставки (delivery)
Авторы выделяют
– паттерны понимания проблематики
– паттерны разбиения проблематики
– и даже паттерны непрерывных оргизменений.
Рекомендую к ознакомлению https://martinfowler.com/articles/patterns-legacy-displacement/
Помимо паттернов поставки (delivery)
Авторы выделяют
– паттерны понимания проблематики
– паттерны разбиения проблематики
– и даже паттерны непрерывных оргизменений.
Рекомендую к ознакомлению https://martinfowler.com/articles/patterns-legacy-displacement/
martinfowler.com
Patterns of Legacy Displacement
Patterns for the effective modernization of legacy software systems
👍12🔥1
Коллеги из IT's Tinkoff начинают серию стримов по книге Влада Learning Domain-Driven Design
Первый стрим уже прошел https://www.youtube.com/watch?v=W8aZiL298E8&list=PLLrf_044z4JpIlGkIDn6sdBstsTkKMXU6&index=2
Также в плейлисте подробный обзор книги с кабанчиком Клеппмана, тоже всячески рекомендую, если не читали или хотите свериться.
Первый стрим уже прошел https://www.youtube.com/watch?v=W8aZiL298E8&list=PLLrf_044z4JpIlGkIDn6sdBstsTkKMXU6&index=2
Также в плейлисте подробный обзор книги с кабанчиком Клеппмана, тоже всячески рекомендую, если не читали или хотите свериться.
YouTube
Code of Architecture Vlad Khononov "Learning Domain-Driven Design". Chapter 1
Мы в Тинькофф верим в обучение, поэтому хотим, чтобы наши сотрудники постоянно росли в профессиональном плане.
В связи с этим, мы создали свой Tinkoff Reader Club "Code of Architecture" для тех, кто строит программные системы.
В нем мы подбираем соответствующие…
В связи с этим, мы создали свой Tinkoff Reader Club "Code of Architecture" для тех, кто строит программные системы.
В нем мы подбираем соответствующие…
👍26🔥12
Не очень слежу, но тем не менее, в марте в гошечке 1.18 завезли генерики)
Я помню как они появились в c# 2.0 (а до этого я только у читал про них у Майерса). И это был кайф!
https://go.dev/doc/tutorial/generics
Я помню как они появились в c# 2.0 (а до этого я только у читал про них у Майерса). И это был кайф!
https://go.dev/doc/tutorial/generics
go.dev
Tutorial: Getting started with generics - The Go Programming Language
Faster is slower
Иван Закревский напомнил мне про отличную статью, в которой объясняется важность системного подхода к своим решениям и почему быстрота в моменте оборачивается замедлением на дистанции. https://less.works/less/principles/systems-thinking
P.S. Есть русский перевод https://less.works/ru/less/principles/systems-thinking
Иван Закревский напомнил мне про отличную статью, в которой объясняется важность системного подхода к своим решениям и почему быстрота в моменте оборачивается замедлением на дистанции. https://less.works/less/principles/systems-thinking
P.S. Есть русский перевод https://less.works/ru/less/principles/systems-thinking
Large Scale Scrum (LeSS)
Systems Thinking
I took a speed reading course and read “War and Peace” in twenty minutes. It involves Russia. —Woody Allen “No matter what we do, the number of defects...
🔥7👍3
https://www.meetup.com/Technical-Excellence/events/285738419/
Коллеги проводят митап про эволюционное проектирование.
Термин пришел из архитектуры и ландшафтного дизайна, позже появился и в проектировании ПО. В частности упоминается в LeSS (https://less.works/less/technical-excellence/architecture-design) и SAFe (https://www.scaledagileframework.com/agile-architecture/). Ну и нельзя не вспомнить книгу Building Evolutionary Architectures (https://www.thoughtworks.com/insights/books/building-evolutionary-architectures).
Коллеги проводят митап про эволюционное проектирование.
Термин пришел из архитектуры и ландшафтного дизайна, позже появился и в проектировании ПО. В частности упоминается в LeSS (https://less.works/less/technical-excellence/architecture-design) и SAFe (https://www.scaledagileframework.com/agile-architecture/). Ну и нельзя не вспомнить книгу Building Evolutionary Architectures (https://www.thoughtworks.com/insights/books/building-evolutionary-architectures).
Meetup
Login to Meetup | Meetup
Not a Meetup member yet? Log in and find groups that host online or in person events and meet people in your local community who share your interests.
👍10
Forwarded from StringConcat - разработка без боли и сожалений
Работая с тактическими паттернами DDD, в очередной раз убеждаешься какой же этот ваш DDD "душный" в хорошем смысле слова. Вот буквально на днях пилили небольшой объект-значение, отражающий количество (при этом количество может быть дробным значением). И в процессе запилки возникли вопросы вида
- Какие могут быть максимальные и минимальные значения?
- Какая должна точность дробной части?
- Как округляется значение при выполнении арифметических операций?
- Какие вообще арифметические операции допустимы, с какими аргументами и в каких диапазонах?
- Как вести себя при переполнении?
И это довольно простой класс, ничего особенного. В обычном случае пишут что-то вроде fun calculate(float: count) и забивают, мы же уделяем столько внимания казалось бы такой незначительной чиселке. И в итоге может показаться, что все это не нужно. Да и вообще тратим больше времени - нужно подумать, написать тесты, etc. Но это не совсем так, ведь мы получаем:
- Снижение когнитивной нагрузки. Мы работаем над небольшим независимым кусочком кода и за счет этого яснее видим граничные случаи.
- Сами тесты получаются проще и шустрее, их дешевле поддерживать. Местами очень хорошо заходит property-тестирование
- Самый главный пункт - мы защищаемся от нелепых багов вида "нам передали отрицательное число в качестве количества, а мы его пропустили, потому что забыли провалидировать. Теперь надо полбазы перетряхнуть на проде, чтобы устранить последствия".
- За счет инкапсуляции упрощается сам код, ведь нам не нужно таскать и копипастить разного рода проверки.
Итого, если количество тестов и растет, то время на их написание (незначительное) компенсируется отсутствием детсадовских багов, а так же более читабельным и поддерживаемым кодом.
- Какие могут быть максимальные и минимальные значения?
- Какая должна точность дробной части?
- Как округляется значение при выполнении арифметических операций?
- Какие вообще арифметические операции допустимы, с какими аргументами и в каких диапазонах?
- Как вести себя при переполнении?
И это довольно простой класс, ничего особенного. В обычном случае пишут что-то вроде fun calculate(float: count) и забивают, мы же уделяем столько внимания казалось бы такой незначительной чиселке. И в итоге может показаться, что все это не нужно. Да и вообще тратим больше времени - нужно подумать, написать тесты, etc. Но это не совсем так, ведь мы получаем:
- Снижение когнитивной нагрузки. Мы работаем над небольшим независимым кусочком кода и за счет этого яснее видим граничные случаи.
- Сами тесты получаются проще и шустрее, их дешевле поддерживать. Местами очень хорошо заходит property-тестирование
- Самый главный пункт - мы защищаемся от нелепых багов вида "нам передали отрицательное число в качестве количества, а мы его пропустили, потому что забыли провалидировать. Теперь надо полбазы перетряхнуть на проде, чтобы устранить последствия".
- За счет инкапсуляции упрощается сам код, ведь нам не нужно таскать и копипастить разного рода проверки.
Итого, если количество тестов и растет, то время на их написание (незначительное) компенсируется отсутствием детсадовских багов, а так же более читабельным и поддерживаемым кодом.
👍34🔥5😁2
Forwarded from agileism (Anton Zotin)
Каждый раз, когда я заказываю вот такой healthy bowl, в пакете находится леденец. Ну и этот леденец тут же летит в мусорную корзину. Целевая аудитория и её потребности? Нет не слышали!
Такая же история происходит со многими диджитал приложениями (особенно этим страдают европейские диджитал банки). А вот у нас есть основной функционал, а давайте запилим пару "леденцов" чтобы нашим клиентам было послаще. Стоит ли говорить, что часто эти "леденцы" целевой аудитории нужны, как козе баян.
А когда приходишь к ним, то на вопрос "что болит?" получаешь "команды медленно деливерят". Ага, они медленно деливерят 100500 "леденцов", которые никому не нужны. Agile не про скорость, он про the art of maximizing the amount
of work not done.
Anton
from Berlin with love
Такая же история происходит со многими диджитал приложениями (особенно этим страдают европейские диджитал банки). А вот у нас есть основной функционал, а давайте запилим пару "леденцов" чтобы нашим клиентам было послаще. Стоит ли говорить, что часто эти "леденцы" целевой аудитории нужны, как козе баян.
А когда приходишь к ним, то на вопрос "что болит?" получаешь "команды медленно деливерят". Ага, они медленно деливерят 100500 "леденцов", которые никому не нужны. Agile не про скорость, он про the art of maximizing the amount
of work not done.
Anton
from Berlin with love
👍27🔥5
Moscow Python Podcast продолжают копать тему Domain-Driven Design. В этот раз они позвали Колю Фоминых (@tigrrrus) из Медси Digital.
Приятного просмотра https://www.youtube.com/watch?v=nxiMm3tyDL4
Приятного просмотра https://www.youtube.com/watch?v=nxiMm3tyDL4
YouTube
Moscow Python Podcast. Domain Driven Design (level: all)
В гостях у Moscow Python Podcast Python руководитель разработки компании МЕДСИ Digital Николай Фоминых. Обсудили с Николаем, что такое DDD, зачем оно нужно и как применяют в МЕДСИ.
Ведущие выпуска — сооснователь MoscowPython и компании Geekfactor.io Валентин…
Ведущие выпуска — сооснователь MoscowPython и компании Geekfactor.io Валентин…
👍5
Часто в индустрии слышу противопоставление заказная разработка vs in-house или outsource vs продуктовая разработка.
Причем иной раз работаешь в продукте, а отношение как к заказной. Или наоборот, ребята на аутсорсе, но настолько вовлечены – очень приятно работать.
Эта статья чуть лучше разделила для меня эти два мира и подсветила разницу.
Что я вынес из статьи:
1. Если в продуктовой компании вам кажется, что вы продаете (покупаете) время – что-то идет не так.
2. Если вам вашим разработчикам важно успеть сделать все запланированные таски (output) – возможно им будет менее интересен реальный результат (outcome).
3. Мы очень часто сталкиваемся (начиная со школьных оценок) с тем, что у нас фейковые, не приносящие ценности цели. Фича, написанная в стол. Отчет, который никто не читает.
И напоследок, пара цитат на эту тему
“The righter we do the wrong thing, the wronger we become” (Russell Ackoff)
"Successful outcomes over efficient delivery" (из статьи)
Понимайте своего потребителя и делайте правильные вещи
Причем иной раз работаешь в продукте, а отношение как к заказной. Или наоборот, ребята на аутсорсе, но настолько вовлечены – очень приятно работать.
Эта статья чуть лучше разделила для меня эти два мира и подсветила разницу.
Что я вынес из статьи:
1. Если в продуктовой компании вам кажется, что вы продаете (покупаете) время – что-то идет не так.
2. Если вам вашим разработчикам важно успеть сделать все запланированные таски (output) – возможно им будет менее интересен реальный результат (outcome).
3. Мы очень часто сталкиваемся (начиная со школьных оценок) с тем, что у нас фейковые, не приносящие ценности цели. Фича, написанная в стол. Отчет, который никто не читает.
И напоследок, пара цитат на эту тему
“The righter we do the wrong thing, the wronger we become” (Russell Ackoff)
"Successful outcomes over efficient delivery" (из статьи)
Понимайте своего потребителя и делайте правильные вещи
👍42🔥2
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Пять монументальных статей о размере микросервиса:
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов
#DDD #MSA
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов
#DDD #MSA
Kalele
Microservices and [Micro]services | Kalele
Kalele Vaughn Vernon discusses whether the size of a microservice matters. What do Domain-Driven Design Bounded Contexts have to do with Microservices.
👍14
Forwarded from Книжный куб (Alexander Polomodov)
Вчера у меня был интересный разговор с коллегой про развитие технических руководителей, в рамках которого я упоминал или ссылался на список книг, который представлен ниже.
Суть нашего разговора сводилась к тому, а что требуется прокачивать техническому руководителю по мере его перехода с позиции инженера на позицию технического руководителя команды, а потом и целого набора команд, которые совместно закрывают потребности одного из бизнесовых доменов.
Мы выделил несколько моментов, которые для него важны:
- инженерные навыки и практики - это его база, которую он принесет с позиции инженера
- понимание бизнеса - здесь важно, что он понимает зачем работает эта команда или группа команд, как выглядит конечный продукт для пользователей и автоматизируемый бизнес-процесс
- понимание как правильно выстраивать delivery - тут важно отметить, что без этого пункта скорее всего execution будет западать
- понимание как работать с людьми - команды состоят из людей и их взаимоотношений, поэтому от этого уйти тоже не получится:)
По итогам нашего часового разговора я накидал такой список того, что я рекомендую почитать и посмотреть
1) Для будущих CTO - Technology Strategy Patterns - https://bit.ly/TechStrgPatterns - тут классно рассказано про подходы к мышлению бизнесменов и паттерны, которые они используют, например, Value Chain, SWOT Analysis, Growth Matrix, Futures Funnel, ... Эти подходы неплохо знать технарям, чтобы коммуницировать с бизнесом насчет техннических решений в терминах и подходах, которые будут им понятны
2) Про деливери - Визуализируте работу - https://apolomodov.medium.com/review-making-work-visible-8ff41a044f9b - базовая книжка про Kanban подход и чем он хорош при оптимизации Delivery
3) Про создание крутых продуктов - Дизайн привычных вещей - https://apolomodov.medium.com/review-design-of-everyday-things-part-1-ab86566431c6 - это книга про human centric design
4) Крутая книга про мышление - The Model Thinkign - https://apolomodov.medium.com/the-model-thinker-review-8ff710d38f96 - крутая книга, что улучшает понимание подходов к моделированию окружающего мира
5) Книга про топологии команд - Team Topologies - https://apolomodov.medium.com/review-team-topologies-part-1-205533a027c0 - здесь про струткуру команд и их эффективное взаимодействие
6) Мой доклад про изменение роли руководителя по мере роста компании и команды - Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - https://apolomodov.medium.com/highload-what-is-cto-406afab7fd5
7) Про изменение процессов (лучше прочитать и посмотреть видео, так как в тексте нет части про delivery managers) - Как мы меняли разработку лучшего* мобильного банка под требования бизнеса - https://apolomodov.medium.com/refactoring-of-mobile-bank-d40858d96f73
8) Моя статья про качество и скорость разработки - Качество vs скорость разработки — как найти баланс? - https://bit.ly/speedVsQuality
9) Книга про лидерство - The Art of Leadership - https://bit.ly/artOfLeadership
#SelfDevelopment #Software #Architecture #Management
Суть нашего разговора сводилась к тому, а что требуется прокачивать техническому руководителю по мере его перехода с позиции инженера на позицию технического руководителя команды, а потом и целого набора команд, которые совместно закрывают потребности одного из бизнесовых доменов.
Мы выделил несколько моментов, которые для него важны:
- инженерные навыки и практики - это его база, которую он принесет с позиции инженера
- понимание бизнеса - здесь важно, что он понимает зачем работает эта команда или группа команд, как выглядит конечный продукт для пользователей и автоматизируемый бизнес-процесс
- понимание как правильно выстраивать delivery - тут важно отметить, что без этого пункта скорее всего execution будет западать
- понимание как работать с людьми - команды состоят из людей и их взаимоотношений, поэтому от этого уйти тоже не получится:)
По итогам нашего часового разговора я накидал такой список того, что я рекомендую почитать и посмотреть
1) Для будущих CTO - Technology Strategy Patterns - https://bit.ly/TechStrgPatterns - тут классно рассказано про подходы к мышлению бизнесменов и паттерны, которые они используют, например, Value Chain, SWOT Analysis, Growth Matrix, Futures Funnel, ... Эти подходы неплохо знать технарям, чтобы коммуницировать с бизнесом насчет техннических решений в терминах и подходах, которые будут им понятны
2) Про деливери - Визуализируте работу - https://apolomodov.medium.com/review-making-work-visible-8ff41a044f9b - базовая книжка про Kanban подход и чем он хорош при оптимизации Delivery
3) Про создание крутых продуктов - Дизайн привычных вещей - https://apolomodov.medium.com/review-design-of-everyday-things-part-1-ab86566431c6 - это книга про human centric design
4) Крутая книга про мышление - The Model Thinkign - https://apolomodov.medium.com/the-model-thinker-review-8ff710d38f96 - крутая книга, что улучшает понимание подходов к моделированию окружающего мира
5) Книга про топологии команд - Team Topologies - https://apolomodov.medium.com/review-team-topologies-part-1-205533a027c0 - здесь про струткуру команд и их эффективное взаимодействие
6) Мой доклад про изменение роли руководителя по мере роста компании и команды - Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - https://apolomodov.medium.com/highload-what-is-cto-406afab7fd5
7) Про изменение процессов (лучше прочитать и посмотреть видео, так как в тексте нет части про delivery managers) - Как мы меняли разработку лучшего* мобильного банка под требования бизнеса - https://apolomodov.medium.com/refactoring-of-mobile-bank-d40858d96f73
8) Моя статья про качество и скорость разработки - Качество vs скорость разработки — как найти баланс? - https://bit.ly/speedVsQuality
9) Книга про лидерство - The Art of Leadership - https://bit.ly/artOfLeadership
#SelfDevelopment #Software #Architecture #Management
👍45🔥2
В продолжение темы продуктовой разработки. На моем опыте хорошие инженерные практики (в том числе Domain-driven design) намного лучше приживаются если продакт взаимодействует с командой не с позиции "заказчик-исполнители", а активно вовлекает в свою работу и интересуется техническими аспектами реализации.
👍4🔥2
Forwarded from AgileFluent: карьера без границ (Dasha Shulgina)
В России часто встречаются продакты-заказчики — те, кто работает над задачкой сам, потом передаёт её по конвейеру дизайнерам, аналитикам и разработчикам.
За границей продакты всё делают в команде — рисерч, брейншторм решения, обсуждение дизайна и способов реализации задачи. Поэтому в международных вакансиях в требованиях встречаются словечки collaborative, non-ego driven, inquisitive, servant leader.
Вместе с Настей, автором канала Кнопка Хорошо, сделали карточки про различия продакта-заказчика и продакта-коллаборатора. Настя - руководитель проектной группы в Актионе, внедряет продуктовую культуру и пишет об этом на канале.
Чтобы проходить скрининги резюме, а после и интервью в зарубежные компании, стоит сместить акцент с самостоятельной на командную работу и запастись кейсами про успешные коллаборации. А ещё обогатить свою лексику и добавить в CV побольше ключевых слов по теме.
За границей продакты всё делают в команде — рисерч, брейншторм решения, обсуждение дизайна и способов реализации задачи. Поэтому в международных вакансиях в требованиях встречаются словечки collaborative, non-ego driven, inquisitive, servant leader.
Вместе с Настей, автором канала Кнопка Хорошо, сделали карточки про различия продакта-заказчика и продакта-коллаборатора. Настя - руководитель проектной группы в Актионе, внедряет продуктовую культуру и пишет об этом на канале.
Чтобы проходить скрининги резюме, а после и интервью в зарубежные компании, стоит сместить акцент с самостоятельной на командную работу и запастись кейсами про успешные коллаборации. А ещё обогатить свою лексику и добавить в CV побольше ключевых слов по теме.
👍12😁3❤2🔥1