Если "глаз замылился" - запроси обратную связь
За последние две недели я потратил ~30 часов на код-ревью проекта, который пишет стажёр в моей команде. Он разрабатывает пример реализации шардирования БД — это не самый простой, но довольно интересный проект.
За это время я успел сродниться с каждой написанной строчкой кода. Мне кажется, они стали моей семьёй. Я знаю каждую чуть ли не наизусть. Я принимаю их такими, какие они есть, со всеми достоинствами и недостатками.
Конечно же, я немного иронизирую. Делаю это намеренно, чтобы подвести к одной простой мысли. Я вложил в ревью этого кода столько сил и внимания, что у меня "замылился глаз". Все решения мне кажутся понятными и логичными, все функции — аккуратными и правильными, структура пакетов не вызывает вопросов, а комментарии кажутся избыточными, ведь всё так понятно.
К счастью, я довольно быстро заметил это состояние и понял, что заблуждаюсь. Во-первых, идеального кода не существует. Во-вторых, я абсолютно уверен в том, что проект можно во многом улучшить.
В такой ситуации лучшее, что можно сделать, — запросить обратную связь. Нужен честный, открытый, свежий взгляд на проделанную работу. Человек, который никогда раньше не видел этот проект, может дать совершенно неожиданные мысли и инсайты для размышления. В моей ситуации я так и поступил, договорившись с несколькими менторами о ревью проекта.
Однако эффект "замыленности глаза" не ограничивается кодом. Подумайте: сколько вещей в жизни кажутся нам абсолютно понятными и привычными? Настолько очевидными, что не вызывают вопросов? Чаще всего именно в этих местах "замылился глаз", и неплохо бы запросить мнение со стороны.
Для этого отлично подходят любые люди, способные дать вам конструктивный фидбек: руководители, коллеги, подчинённые, менторы и даже психологи с коучами. Наше мышление и восприятие ограничены, а сторонний наблюдатель может обратить внимание на те аспекты, которые мы совершенно упускаем из виду. Даже если вы ничего не предпримете после получения этой обратной связи, она заставит мозг пошевелиться и поискать другие, обделённые вниманием, области.
За последние две недели я потратил ~30 часов на код-ревью проекта, который пишет стажёр в моей команде. Он разрабатывает пример реализации шардирования БД — это не самый простой, но довольно интересный проект.
За это время я успел сродниться с каждой написанной строчкой кода. Мне кажется, они стали моей семьёй. Я знаю каждую чуть ли не наизусть. Я принимаю их такими, какие они есть, со всеми достоинствами и недостатками.
Конечно же, я немного иронизирую. Делаю это намеренно, чтобы подвести к одной простой мысли. Я вложил в ревью этого кода столько сил и внимания, что у меня "замылился глаз". Все решения мне кажутся понятными и логичными, все функции — аккуратными и правильными, структура пакетов не вызывает вопросов, а комментарии кажутся избыточными, ведь всё так понятно.
К счастью, я довольно быстро заметил это состояние и понял, что заблуждаюсь. Во-первых, идеального кода не существует. Во-вторых, я абсолютно уверен в том, что проект можно во многом улучшить.
В такой ситуации лучшее, что можно сделать, — запросить обратную связь. Нужен честный, открытый, свежий взгляд на проделанную работу. Человек, который никогда раньше не видел этот проект, может дать совершенно неожиданные мысли и инсайты для размышления. В моей ситуации я так и поступил, договорившись с несколькими менторами о ревью проекта.
Однако эффект "замыленности глаза" не ограничивается кодом. Подумайте: сколько вещей в жизни кажутся нам абсолютно понятными и привычными? Настолько очевидными, что не вызывают вопросов? Чаще всего именно в этих местах "замылился глаз", и неплохо бы запросить мнение со стороны.
Для этого отлично подходят любые люди, способные дать вам конструктивный фидбек: руководители, коллеги, подчинённые, менторы и даже психологи с коучами. Наше мышление и восприятие ограничены, а сторонний наблюдатель может обратить внимание на те аспекты, которые мы совершенно упускаем из виду. Даже если вы ничего не предпримете после получения этой обратной связи, она заставит мозг пошевелиться и поискать другие, обделённые вниманием, области.
Рефлексия прокачивает автоматическое принятие решений
В течение дня мы принимаем огромное количество решений. Причём большую часть из них мы принимаем неосознанно, на автомате. Это нормально: если начать анализировать абсолютно всё, то через примерно полторы минуты средний человек "закончится", и можно будет снова ложиться спать.
Эти маленькие решения во многом определяют нашу жизнь, поэтому было бы неплохо иметь инструменты для их улучшения. Многие уже знакомы с разными инструментами анализа и принятия решений, однако они слишком сложны и неповоротливы для небольших задач.
Чтобы улучшить качество принимаемых на автомате решений, нужно каким-то образом вклиниться в цепочку принятия этих самых решений. Мысль не рождается из ниоткуда, она формируется на основании знаний, опыта и системы убеждений. Комбинация этих элементов создаёт в голове логическую связь, которая и приводит к последующим решениям.
Мне этот процесс представляется как прохождение тока по электрической цепи (видимо, образование даёт о себе знать). Ток бежит от входа к выходу, попутно претерпевая некоторые изменения. А компоненты электрической цепи — это как раз те самые знания, опыт и убеждения. Добавляя новые элементы в цепь, я могу менять то, что получаю на выходе.
Соответственно, для прокачки автоматического принятия решений нужно работать с каждым из перечисленных элементов:
~ Нужно получать новые знания, чтобы формировать новые способы решения старых проблем. И нет, просто читать книжки и смотреть видео недостаточно, это простое потребление информации.
~ Нужно получать новый опыт и рефлексировать уже имеющийся, чтобы сделать из него выводы. Опыт мы рефлексируем в любом случае, просто неосознанная рефлексия может привести к неправильным выводам.
~ Нужно развивать, обогащать и пересматривать свои убеждения. Чаще всего это возможно при рефлексии. Очень помогают вопросы типа "Почему я так подумал/поступил?"
Когда я обдумываю новую идею или рефлексирую некоторый опыт, то в процессе мышления прихожу к новым выводам, которые остаются у меня в голове. Можно сказать, что тем самым я формирую новые элементы для существующих и будущих цепочек принятия решений (вспоминаем аналогию с электрической цепью).
Поэтому очень полезно подводить итоги прочитанного, просмотренного и пережитого. Обдумывание полученных знаний и опыта позволяет создавать в сети знаний мозга новые "крючки", которые начинают неожиданно срабатывать. Мне бывает очень забавно наблюдать за тем, как в привычной ситуации я делаю что-то по-новому и сам потом удивляюсь своему поведению.
В течение дня мы принимаем огромное количество решений. Причём большую часть из них мы принимаем неосознанно, на автомате. Это нормально: если начать анализировать абсолютно всё, то через примерно полторы минуты средний человек "закончится", и можно будет снова ложиться спать.
Эти маленькие решения во многом определяют нашу жизнь, поэтому было бы неплохо иметь инструменты для их улучшения. Многие уже знакомы с разными инструментами анализа и принятия решений, однако они слишком сложны и неповоротливы для небольших задач.
Чтобы улучшить качество принимаемых на автомате решений, нужно каким-то образом вклиниться в цепочку принятия этих самых решений. Мысль не рождается из ниоткуда, она формируется на основании знаний, опыта и системы убеждений. Комбинация этих элементов создаёт в голове логическую связь, которая и приводит к последующим решениям.
Мне этот процесс представляется как прохождение тока по электрической цепи (видимо, образование даёт о себе знать). Ток бежит от входа к выходу, попутно претерпевая некоторые изменения. А компоненты электрической цепи — это как раз те самые знания, опыт и убеждения. Добавляя новые элементы в цепь, я могу менять то, что получаю на выходе.
Соответственно, для прокачки автоматического принятия решений нужно работать с каждым из перечисленных элементов:
~ Нужно получать новые знания, чтобы формировать новые способы решения старых проблем. И нет, просто читать книжки и смотреть видео недостаточно, это простое потребление информации.
~ Нужно получать новый опыт и рефлексировать уже имеющийся, чтобы сделать из него выводы. Опыт мы рефлексируем в любом случае, просто неосознанная рефлексия может привести к неправильным выводам.
~ Нужно развивать, обогащать и пересматривать свои убеждения. Чаще всего это возможно при рефлексии. Очень помогают вопросы типа "Почему я так подумал/поступил?"
Когда я обдумываю новую идею или рефлексирую некоторый опыт, то в процессе мышления прихожу к новым выводам, которые остаются у меня в голове. Можно сказать, что тем самым я формирую новые элементы для существующих и будущих цепочек принятия решений (вспоминаем аналогию с электрической цепью).
Поэтому очень полезно подводить итоги прочитанного, просмотренного и пережитого. Обдумывание полученных знаний и опыта позволяет создавать в сети знаний мозга новые "крючки", которые начинают неожиданно срабатывать. Мне бывает очень забавно наблюдать за тем, как в привычной ситуации я делаю что-то по-новому и сам потом удивляюсь своему поведению.
Сэм Ньюмен, "От монолита к микросервисам"
Распил монолита на микросервисы уже стал притчей во языцех. Если вбить в поиск ютуба эту ключевую фразу, то вы увидитебесконечную загрузку кучу видосов и выступлений на конфе. Оно и неудивительно, тема сложная и богатая на нюансы.
Сэм Ньюмен, автор книги "Создание микросервисов" (на которую я писал обзор), тоже успел проехаться на хайповой теме. Его книга про микросервисы мне очень понравилась, поэтому я решил прочитать и про распил монолита.
О чём книга
Книга довольно небольшая, состоит из 5 глав, которые и покрывают все аспекты миграции.
Первая глава посвящена терминологии, которая используется в книге (микросервис, монолит, cohesion/coupling, немного DDD).
Вторая глава покрывает планирование миграции с монолита на микросервисы. Интересно, что Ньюмен акцентирует внимание на важности планирования и как управлять распилом с точки зрения проектного управления (риски, контрольные точки, вот это всё). Даже когнитивные искажения вспомнил.
Третья и четвёртая главы рассказывают о технической части миграции: как пилить монолит и как пилить БД. Для распила монолита автор предлагает несколько шаблонов, которые позволяют постепенно переехать с монолита. Есть как относительно стандартные шаблоны (душитель, вынос куска логики в микросервис и так далее), так и более экстравагантные типа использования CDC для создания параллельно работающих систем.
Для распила БД автор тоже предлагает набор архитектурных шаблонов, от обёртывания БД микросервисом до различных синхронизаций. Также описан ряд вспомогательных шаблонов, которые могут немного упростить переезд. В конце главы про БД автор прошёлся по транзакциям, 2FC и сагам в микросервисах.
Пятая глава на мой вкус должна быть второй, потому что она рассказывает о болезнях роста микросервисной архитектуры. В ней описаны все страдания, которые предстоит пережить с масштабированием микросервисной архитектуры. Также в ней Ньюмен затрагивает вопросы мониторинга и логирования, DX разработчиков микросервисов, проблемы отказоустойчивости и многое другое.
Мои впечатления
Книга мне понравилась. Она даёт общий обзор проблемы распила монолита на микросервисы с точки зрения как кода, так и хранения данных. Ньюмен двигается от проблемы к решению, поэтому книгу довольно легко читать и воспринимать.
Конечно, в ней не хватает детализации, однако в такой сложной теме избыток подробностей делает книгу слишком узкоспециализированной. Автор ставил перед собой задачу дать читателю общее понимание проблемы распила монолита на микросервисы и путей её решения, и ему это удалось.
Отдельно хочу выделать русский перевод, который сделан из рук вон плохо. Если английский позволяет, то читайте книгу в оригинале.
На мой взгляд, книгу стоит прочитать каждому бэкендеру начиная с уровня Middle (это то место, где хочется прикручивать много всяких разных архитектурных паттернов и тому подобных вещей). С книгой стоит ознакомиться, даже если вы не планируете в ближайшее время пилить монолит - планы могут измениться :)
#обзор_книги
Распил монолита на микросервисы уже стал притчей во языцех. Если вбить в поиск ютуба эту ключевую фразу, то вы увидите
Сэм Ньюмен, автор книги "Создание микросервисов" (на которую я писал обзор), тоже успел проехаться на хайповой теме. Его книга про микросервисы мне очень понравилась, поэтому я решил прочитать и про распил монолита.
О чём книга
Книга довольно небольшая, состоит из 5 глав, которые и покрывают все аспекты миграции.
Первая глава посвящена терминологии, которая используется в книге (микросервис, монолит, cohesion/coupling, немного DDD).
Вторая глава покрывает планирование миграции с монолита на микросервисы. Интересно, что Ньюмен акцентирует внимание на важности планирования и как управлять распилом с точки зрения проектного управления (риски, контрольные точки, вот это всё). Даже когнитивные искажения вспомнил.
Третья и четвёртая главы рассказывают о технической части миграции: как пилить монолит и как пилить БД. Для распила монолита автор предлагает несколько шаблонов, которые позволяют постепенно переехать с монолита. Есть как относительно стандартные шаблоны (душитель, вынос куска логики в микросервис и так далее), так и более экстравагантные типа использования CDC для создания параллельно работающих систем.
Для распила БД автор тоже предлагает набор архитектурных шаблонов, от обёртывания БД микросервисом до различных синхронизаций. Также описан ряд вспомогательных шаблонов, которые могут немного упростить переезд. В конце главы про БД автор прошёлся по транзакциям, 2FC и сагам в микросервисах.
Пятая глава на мой вкус должна быть второй, потому что она рассказывает о болезнях роста микросервисной архитектуры. В ней описаны все страдания, которые предстоит пережить с масштабированием микросервисной архитектуры. Также в ней Ньюмен затрагивает вопросы мониторинга и логирования, DX разработчиков микросервисов, проблемы отказоустойчивости и многое другое.
Мои впечатления
Книга мне понравилась. Она даёт общий обзор проблемы распила монолита на микросервисы с точки зрения как кода, так и хранения данных. Ньюмен двигается от проблемы к решению, поэтому книгу довольно легко читать и воспринимать.
Конечно, в ней не хватает детализации, однако в такой сложной теме избыток подробностей делает книгу слишком узкоспециализированной. Автор ставил перед собой задачу дать читателю общее понимание проблемы распила монолита на микросервисы и путей её решения, и ему это удалось.
Отдельно хочу выделать русский перевод, который сделан из рук вон плохо. Если английский позволяет, то читайте книгу в оригинале.
На мой взгляд, книгу стоит прочитать каждому бэкендеру начиная с уровня Middle (это то место, где хочется прикручивать много всяких разных архитектурных паттернов и тому подобных вещей). С книгой стоит ознакомиться, даже если вы не планируете в ближайшее время пилить монолит - планы могут измениться :)
#обзор_книги
Тимлид не нужен?
Я довольно чётко помню момент, когда первый раз в жизни почувствовал, что я не нужен команде. Это произошло где-то месяца через 4 после того, как я стал тимлидом.
Руководителем я стал в уже существующей команде, поэтому мне не пришлось выстраивать процессы с нуля, нанимать людей и так далее. Это ощутимо упростило мне вкатывание в новую профессию. Команда уже работала, процессы уже были настроены и мне понадобилось только ознакомиться с необходимой информацией и принять на себя ответственность.
Но через некоторое время я почувствовал сильнейший приступ синдрома самозванца. Мне показалось, что я ничего полезного для команды не делаю. Убери меня - и ничего особо не изменится, команда продолжит работать.
С такой же проблемой сталкивались практически все начинающие тимлиды, которым я как ментор помогал вкатываться в новую роль. Когда процессы построены и команда нормально по ним работает, поставляя результат, то возникает ощущение, что тимлид такой команде только мешает.
Это ощущение на самом деле является очень большим заблуждением. Хорошо выстроенная команда и правда может работать без тимлида, но только какой-то ограниченный промежуток времени. Чем лучше всё настроено - тем дольше команда сможет работать, но рано или поздно наступит точка, в которой кому-то придётся взять на себя ответственность.
Можно провести аналогию с автомобилем. Он какое-то время может ездить без ТО, но однажды что-то произойдёт - и придётся ехать в мастерскую.
Если вас атаковал синдром самозванца, то одним из лучших лекарств от него будет обратная связь. Можно пойти к членам команды и попросить их поделиться честным мнением о вашей работе. Пусть они расскажут, что в вашей работе для них ценно и полезно. Такой разговор сделает лучше всем: вы получите плюс к самооценке и понимание, что ценно для команды, а члены команды получат внимание тимлида и возможность высказать свои потребности.
Такой же разговор можно провести и со своим руководителем. Спросите его, как он оценивает вашу работу, что у вас получается хорошо, чего не хватает. Так вы лучше поймёте, что важно для руководства в вашей работе и какие у вас есть сильные стороны. А точки роста помогут направить усилия в нужное русло.
Тимлид - важный и нужный член команды. Если вы в этом засомневались, то лучше не затягивать и поработать с этим чувством. Хорошая команда всегда поддержит своего руководителя.
Я довольно чётко помню момент, когда первый раз в жизни почувствовал, что я не нужен команде. Это произошло где-то месяца через 4 после того, как я стал тимлидом.
Руководителем я стал в уже существующей команде, поэтому мне не пришлось выстраивать процессы с нуля, нанимать людей и так далее. Это ощутимо упростило мне вкатывание в новую профессию. Команда уже работала, процессы уже были настроены и мне понадобилось только ознакомиться с необходимой информацией и принять на себя ответственность.
Но через некоторое время я почувствовал сильнейший приступ синдрома самозванца. Мне показалось, что я ничего полезного для команды не делаю. Убери меня - и ничего особо не изменится, команда продолжит работать.
С такой же проблемой сталкивались практически все начинающие тимлиды, которым я как ментор помогал вкатываться в новую роль. Когда процессы построены и команда нормально по ним работает, поставляя результат, то возникает ощущение, что тимлид такой команде только мешает.
Это ощущение на самом деле является очень большим заблуждением. Хорошо выстроенная команда и правда может работать без тимлида, но только какой-то ограниченный промежуток времени. Чем лучше всё настроено - тем дольше команда сможет работать, но рано или поздно наступит точка, в которой кому-то придётся взять на себя ответственность.
Можно провести аналогию с автомобилем. Он какое-то время может ездить без ТО, но однажды что-то произойдёт - и придётся ехать в мастерскую.
Если вас атаковал синдром самозванца, то одним из лучших лекарств от него будет обратная связь. Можно пойти к членам команды и попросить их поделиться честным мнением о вашей работе. Пусть они расскажут, что в вашей работе для них ценно и полезно. Такой разговор сделает лучше всем: вы получите плюс к самооценке и понимание, что ценно для команды, а члены команды получат внимание тимлида и возможность высказать свои потребности.
Такой же разговор можно провести и со своим руководителем. Спросите его, как он оценивает вашу работу, что у вас получается хорошо, чего не хватает. Так вы лучше поймёте, что важно для руководства в вашей работе и какие у вас есть сильные стороны. А точки роста помогут направить усилия в нужное русло.
Тимлид - важный и нужный член команды. Если вы в этом засомневались, то лучше не затягивать и поработать с этим чувством. Хорошая команда всегда поддержит своего руководителя.
Тимлид не нужен
Начать этот пост я хочу с благодарности ув. тов. Виталию Шароватову, который натолкнул меня на эти размышления.
Что обычно делает тимлид в команде? Занимается организационной деятельностью. Когда я читал "Цель" Голдратта, то у меня возникла чёткая аналогия работы IT команды и производственного конвейера. И тимлид в команде - это зачастую эдакий Алекс Рого, который наблюдает за всем процессом производства и как-то его "оптимизирует".
Неопытные тимлиды (страдая от FOMO, см. предыдущий пост) нахватывают себе по-максимуму задач. Они стараются одновременно всё обмазать метриками, нахватывают себе какой-то дополнительной ответственности, оверкоммитятся в фичи и параллельно пытаются писать код. Чем это обычно заканчивается - вы и без меня прекрасно знаете.
Опытные руководители наоборот стремятся к самоустранению из процесса работы. Они делегируют свои задачи членам команды, а сами стараются действовать только тогда, когда это действительно необходимо. Такой подход помогает людям освоить новые навыки, взять на себя больше ответственности и в целом прокачивает автономию команды.
Звучит, как будто я какого-то бездельника описал. В некотором роде это так и есть, но разве это плохо? У такого руководителя получается более автономная команда, которая может долгое время стабильно работать без него (в идеале - до бесконечности). Бас фактор у такой команды гораздо ниже, потому что руководитель не становится бутылочным голышком. Да и сами отношения между членами команды становятся крепче, потому что каждый что-то делает ради общего блага.
Из минусов могу отметить, что менять людей становится чуть сложнее. Каждый член команды скорее всего будет выполнять дополнительные задачи помимо основных рабочих обязанностей, поэтому в случае его ухода эти задачи придётся кому-то передать. Но на моём опыте эта проблема в сплочённой и сильной команде обычно решается минут за 5 на созвоне.
Поэтому тимлид должен стараться "оторвать руки от руля", как бы ему ни было страшно. Чем больше задач тимлид скидывает на команду, тем более автономной и устойчивой она становится. А освободившееся время можно потратить, например, на обучение или менторинг менее опытных коллег.
Хорошей идеей будет заручиться поддержкой более опытных коллег - они и совет грамотный дадут, и поддержат в случае эмоциональных пертрубаций. С проблемами FOMO тоже можно обратиться к ним (или к психотерапевту).
В следующем посте поговорим о том, насколько утопична идея команды без руководителя и что удерживает людей вместе.
#менеджмент
Начать этот пост я хочу с благодарности ув. тов. Виталию Шароватову, который натолкнул меня на эти размышления.
Что обычно делает тимлид в команде? Занимается организационной деятельностью. Когда я читал "Цель" Голдратта, то у меня возникла чёткая аналогия работы IT команды и производственного конвейера. И тимлид в команде - это зачастую эдакий Алекс Рого, который наблюдает за всем процессом производства и как-то его "оптимизирует".
Неопытные тимлиды (страдая от FOMO, см. предыдущий пост) нахватывают себе по-максимуму задач. Они стараются одновременно всё обмазать метриками, нахватывают себе какой-то дополнительной ответственности, оверкоммитятся в фичи и параллельно пытаются писать код. Чем это обычно заканчивается - вы и без меня прекрасно знаете.
Опытные руководители наоборот стремятся к самоустранению из процесса работы. Они делегируют свои задачи членам команды, а сами стараются действовать только тогда, когда это действительно необходимо. Такой подход помогает людям освоить новые навыки, взять на себя больше ответственности и в целом прокачивает автономию команды.
Звучит, как будто я какого-то бездельника описал. В некотором роде это так и есть, но разве это плохо? У такого руководителя получается более автономная команда, которая может долгое время стабильно работать без него (в идеале - до бесконечности). Бас фактор у такой команды гораздо ниже, потому что руководитель не становится бутылочным голышком. Да и сами отношения между членами команды становятся крепче, потому что каждый что-то делает ради общего блага.
Из минусов могу отметить, что менять людей становится чуть сложнее. Каждый член команды скорее всего будет выполнять дополнительные задачи помимо основных рабочих обязанностей, поэтому в случае его ухода эти задачи придётся кому-то передать. Но на моём опыте эта проблема в сплочённой и сильной команде обычно решается минут за 5 на созвоне.
Поэтому тимлид должен стараться "оторвать руки от руля", как бы ему ни было страшно. Чем больше задач тимлид скидывает на команду, тем более автономной и устойчивой она становится. А освободившееся время можно потратить, например, на обучение или менторинг менее опытных коллег.
Хорошей идеей будет заручиться поддержкой более опытных коллег - они и совет грамотный дадут, и поддержат в случае эмоциональных пертрубаций. С проблемами FOMO тоже можно обратиться к ним (или к психотерапевту).
В следующем посте поговорим о том, насколько утопична идея команды без руководителя и что удерживает людей вместе.
#менеджмент
Встречаемся на A?.Frontend Day
Для профессионального роста бывает очень полезно закопаться в смежные направления. То, что раньше казалось магией, становится более (иногда - менее) понятно и обретает смысл.
Например, я люблю делать выступления про всякие базовые бэкендерские штуки для фронтенд-разработчиков. Обычно они не задумываются о том, что происходит "за апишкой" - и я их прекрасно понимаю, им своих забот хватает. Но общение на тему проблем бэкенда расширяет им кругозор. А ещё это просто весело :)
21 сентября буду выступать на A?.Frontend Day с докладом на тему "Как работать с отказами систем в BFF: основные паттерны отказоустойчивости". Тех, кто придёт на доклад, я немного погружу в чудесный мир распределённых систем. Поговорим про сбои микросервисов и как заложить их в архитектуру вашего Backend For Frontend, обсудим некоторые паттерны отказоустойчивости, посмотрим мемы.
Приходите, будет весело!
Для профессионального роста бывает очень полезно закопаться в смежные направления. То, что раньше казалось магией, становится более (иногда - менее) понятно и обретает смысл.
Например, я люблю делать выступления про всякие базовые бэкендерские штуки для фронтенд-разработчиков. Обычно они не задумываются о том, что происходит "за апишкой" - и я их прекрасно понимаю, им своих забот хватает. Но общение на тему проблем бэкенда расширяет им кругозор. А ещё это просто весело :)
21 сентября буду выступать на A?.Frontend Day с докладом на тему "Как работать с отказами систем в BFF: основные паттерны отказоустойчивости". Тех, кто придёт на доклад, я немного погружу в чудесный мир распределённых систем. Поговорим про сбои микросервисов и как заложить их в архитектуру вашего Backend For Frontend, обсудим некоторые паттерны отказоустойчивости, посмотрим мемы.
Приходите, будет весело!
digital.alfabank.ru
A?.Frontend Day
Большая конференция для frontend-разработчиков о хардах и софтах. Лучший работодатель России по версии HeadHunter в 2023 году.
Что удерживает членов команды вместе?
Насколько вообще утопична идея команды, которая может работать без руководителя? Звучит как что-то мифическое и недостижимое, особенно с учётом FOMO-based руководителей, которые не могут отпустить контроль. Давайте немного пофантазируем на эту тему.
Сначала я подумал, что такая команда должна быть очень статичной. Но это практически невозможно, потому что в команде слишком много переменных: состав, задачи, контекст, сами люди и их жизненные обстоятельства. В таких условиях невозможно построить неизменную систему, каждый день что-то будет меняться. И это нормально.
Но при этом я и своими глазами видел, и сам создавал крепкие, дружно работающие и устойчивые команды. Значит, есть некий клей, который удерживает этих людей вместе и заставляет упорно работать над общими целями, поддерживать друг друга, строить отношения и всё такое.
Имя этому клею — ценности.
Но это не те ценности, которые бизнес написал на красивом плакате и повесил на стеночку в офисе. Такие ценности зачастую мертворождённые и используются только в громких речах и лозунгах. То, как люди на самом деле поступают, обычно основано на их внутренних ценностях. Навязать внешние ценности человеку можно, но это далеко не самая простая задача.
Ценность — это то, что для конкретного человека по-настоящему важно в жизни. Это те вещи, к которым он тянется и которые считает эталоном. Человек может даже не осознавать свои ценности, но они всё равно есть и влияют на его жизнь, мировоззрение и механизм принятия решений.
У каждого человека свой набор ценностей. Более того, даже если два человека обладают одинаковой ценностью, уровень важности этой ценности для них может быть кардинально разным.
Так вот, реальным клеем команды являются общие ценности. Если в группе людей одни и те же ценности являются ориентиром, то такие люди будут понимать друг друга с полуслова. Конечно же, им будет проще работать, потому что они смотрят в одну сторону и легко находят общий язык. Пересечение ценностей создаёт у людей ощущение, что они работают рука об руку с теми, кто близок им по духу.
Представляете, насколько сильно понимание ценностей команды влияет на её работу и устойчивость? Об этом и поговорим в следующем посте.
Насколько вообще утопична идея команды, которая может работать без руководителя? Звучит как что-то мифическое и недостижимое, особенно с учётом FOMO-based руководителей, которые не могут отпустить контроль. Давайте немного пофантазируем на эту тему.
Сначала я подумал, что такая команда должна быть очень статичной. Но это практически невозможно, потому что в команде слишком много переменных: состав, задачи, контекст, сами люди и их жизненные обстоятельства. В таких условиях невозможно построить неизменную систему, каждый день что-то будет меняться. И это нормально.
Но при этом я и своими глазами видел, и сам создавал крепкие, дружно работающие и устойчивые команды. Значит, есть некий клей, который удерживает этих людей вместе и заставляет упорно работать над общими целями, поддерживать друг друга, строить отношения и всё такое.
Имя этому клею — ценности.
Но это не те ценности, которые бизнес написал на красивом плакате и повесил на стеночку в офисе. Такие ценности зачастую мертворождённые и используются только в громких речах и лозунгах. То, как люди на самом деле поступают, обычно основано на их внутренних ценностях. Навязать внешние ценности человеку можно, но это далеко не самая простая задача.
Ценность — это то, что для конкретного человека по-настоящему важно в жизни. Это те вещи, к которым он тянется и которые считает эталоном. Человек может даже не осознавать свои ценности, но они всё равно есть и влияют на его жизнь, мировоззрение и механизм принятия решений.
У каждого человека свой набор ценностей. Более того, даже если два человека обладают одинаковой ценностью, уровень важности этой ценности для них может быть кардинально разным.
Так вот, реальным клеем команды являются общие ценности. Если в группе людей одни и те же ценности являются ориентиром, то такие люди будут понимать друг друга с полуслова. Конечно же, им будет проще работать, потому что они смотрят в одну сторону и легко находят общий язык. Пересечение ценностей создаёт у людей ощущение, что они работают рука об руку с теми, кто близок им по духу.
Представляете, насколько сильно понимание ценностей команды влияет на её работу и устойчивость? Об этом и поговорим в следующем посте.
Как упростить подбор людей в команду с помощью ценностей
Фит-интервью мне иногда напоминают угадайку. Особенно когда я сам выступал в роли кандидата. Я прямо вижу, как сидит напротив меня человек и напряжённо думает: «Подойдёт в команду или нет?»
Опытные менеджеры умеют набирать людей интуитивно. Благодаря опыту и насмотренности они заранее понимают, сработается ли команда с потенциальным кандидатом или будут трудности. Однако такой опыт набирается долго и зачастую болезненно.
Конечно, без ошибок найма обойтись не получится. Опыт — он, знаете ли, не просто так сын ошибок трудных. Однако снизить эти ошибки можно, если серьёзно подумать о том, какой человек нужен команде.
К сожалению, чаще всего ответ на этот вопрос сводится либо к набору абстрактных технических навыков («глубокое знание Go, повышенное мастерство в юнит-тестах, умение варить суп из PostgreSQL и Kafka»), либо к набору абстрактных общечеловеческих качеств («аккуратность, ответственность, любовь к переводу бабушек через дорогу»).
Что они нам дают при найме? Да практически ничего. Аккуратный и ответственный джедай PostgreSQL и Kafka может быть, например, невыносимым занудой. А у вас команда гачи-стикеры отправляет друг другу в Telegram и на дейли гадает на картах с мемами (привет, Pages ❤️, я знаю, что вы меня читаете). Ну и как с таким работать?
И здесь мы возвращаемся к ценностям команды. Ценности у членов команды есть всегда, даже если они неосознанные. Соответственно, и пересечение ценностей тоже имеется, хотите вы того или нет.
Проявление и понимание ценностей команды может существенно упростить и прокачать найм. Порефлексируйте: доводилось ли вам нанимать человека, который вот чуть-чуть не дотягивал по техничке, но идеально вписывался в вайб команды? Мне — да. Ничуть не пожалел, потому что техничку докачали буквально за пару месяцев, а команда получила отличного члена в свои ряды.
Если нанимать кандидатов, изначально ориентируясь на ценности команды, то это сильно упрощает весь процесс — от найма до работы. Во-первых, сам найм становится проще, потому что гадание на кофейной гуще превращается в проверку конкретных, заранее определённых ценностей (об этом напишу отдельно). Во-вторых, онбординг становится для новичка и команды гораздо проще и менее стрессовым, потому что новичок «на одной волне» с командой и легко в неё вливается.
Понимание ценностей команды делает найм и онбординг кандидатов значительно проще и приятнее для всех сопричастных. Не стоит пренебрегать этим.
Дальше поговорим о том, как выявлять ценности. Не переключайтесь :)
Фит-интервью мне иногда напоминают угадайку. Особенно когда я сам выступал в роли кандидата. Я прямо вижу, как сидит напротив меня человек и напряжённо думает: «Подойдёт в команду или нет?»
Опытные менеджеры умеют набирать людей интуитивно. Благодаря опыту и насмотренности они заранее понимают, сработается ли команда с потенциальным кандидатом или будут трудности. Однако такой опыт набирается долго и зачастую болезненно.
Конечно, без ошибок найма обойтись не получится. Опыт — он, знаете ли, не просто так сын ошибок трудных. Однако снизить эти ошибки можно, если серьёзно подумать о том, какой человек нужен команде.
К сожалению, чаще всего ответ на этот вопрос сводится либо к набору абстрактных технических навыков («глубокое знание Go, повышенное мастерство в юнит-тестах, умение варить суп из PostgreSQL и Kafka»), либо к набору абстрактных общечеловеческих качеств («аккуратность, ответственность, любовь к переводу бабушек через дорогу»).
Что они нам дают при найме? Да практически ничего. Аккуратный и ответственный джедай PostgreSQL и Kafka может быть, например, невыносимым занудой. А у вас команда гачи-стикеры отправляет друг другу в Telegram и на дейли гадает на картах с мемами (привет, Pages ❤️, я знаю, что вы меня читаете). Ну и как с таким работать?
И здесь мы возвращаемся к ценностям команды. Ценности у членов команды есть всегда, даже если они неосознанные. Соответственно, и пересечение ценностей тоже имеется, хотите вы того или нет.
Проявление и понимание ценностей команды может существенно упростить и прокачать найм. Порефлексируйте: доводилось ли вам нанимать человека, который вот чуть-чуть не дотягивал по техничке, но идеально вписывался в вайб команды? Мне — да. Ничуть не пожалел, потому что техничку докачали буквально за пару месяцев, а команда получила отличного члена в свои ряды.
Если нанимать кандидатов, изначально ориентируясь на ценности команды, то это сильно упрощает весь процесс — от найма до работы. Во-первых, сам найм становится проще, потому что гадание на кофейной гуще превращается в проверку конкретных, заранее определённых ценностей (об этом напишу отдельно). Во-вторых, онбординг становится для новичка и команды гораздо проще и менее стрессовым, потому что новичок «на одной волне» с командой и легко в неё вливается.
Понимание ценностей команды делает найм и онбординг кандидатов значительно проще и приятнее для всех сопричастных. Не стоит пренебрегать этим.
Дальше поговорим о том, как выявлять ценности. Не переключайтесь :)
Как определить ценности команды?
В предыдущих сериях мы уже выяснили, что ценности команды - штука важная, нужная и существующая вне зависимости от субъективного мнения окружающих о них. Однако главная интрига остается не раскрытой.
Что это вообще за ценности такие? Как они выглядят? И главное - как их выявить и использовать себе и команде во благо?
Начнем с конца и разберёмся, как определить ценности. Лично я знаю три способа:
1. Вангование
2. Гадание на картах Таро
3. Командный семинар по выявлению ценностей
Первые два я привел не только шутки ради. Люди в целом склонны придумывать и додумывать себе разные интересные вещи, никак не связанные с реальностью. С ценностями такая же история: их можно предположить, но это не гарантирует точного попадание. В общем, общайтес.
Переходим к третьему пункту, а именно к командному семинару. Фактически это обычное собрание, в рамках которого члены команды должны ответить на ряд вопросов:
Что для меня ценно в команде и командной работе?
Каждый член команды накидывает свои варианты ценностей. Здесь может быть все, что угодно: помощь и взаимовыручка, уважение коллег, приватный чат с мемами, ходить в бар по пятницам после работы с командой и так далее.
На этом этапе лучше всего устроить бреиншторм и не ограничивать людей в вариантах. Пусть они напишут все, что считаю важным. Затем возьмите все написанное и попытайтесь сформулировать ценности общего характера для частных случаев. Например, если для человека важно ходить в бар с командой, то это можно отнести к ценности «неформальное общение».
Когда у вас появится набор ценностей, можно перейти к следующему этапу. Для каждой ценности вам нужно ответить на следующие вопросы:
Что эта ценность значит для нас?
Вопрос специально составлен таким образом, чтобы на него не было однозначного ответа. В ответах на него вы узнаете, как члены команды относятся к каждой из ценностей. Важно: сохраняйте фокус на команде, ваша задача - понять, как ценности работают именно в команде.
Как ценность выглядит в действии?
Очень важный вопрос, который «приземляет» абстрактные ценности на конкретные действия. В ответах вы узнаете, в каких действиях люди видят проявление той или иной ценности (см. пример про бар).
Как эту ценность можно неверно понять?
Заглядываем на тёмную сторону мира ценности. Ту же ценность неформального общения легко истолковать как «я обязан ходить с коллегами в бар, чтобы меня принимали в команде». Ответив на вопрос, вы определите границы ценности.
Как мы поймем, что ценность соблюдается?
Здесь хорошо будет вернуться к конкретным действиям и ещё раз их обсудить. Постарайтесь переложить всё написанное на повседневную жизнь команды. Возможно, какие-то штуки стоит делать почаще.
Как эта ценность изменит работу или отношения в команде?
Вопрос, который накрепко вбивает в членов команды понимание, почему ценность важна для всех. Он фактически подводит результат всей проделанной вами работы и даёт людям понять, ради чего они столько времени напрягались.
Провести такой семинар непросто, да и времени он съедает прилично. Но результаты могут вас приятно удивить. Сам факт командного разговора о важных для каждого члена вещах сближает людей и помогает им лучше понять друг друга.
Что потом делать с написанными ценностями - решайте сами. Вполне неплохой идеей будет написать манифест и регулярно к нему возвращаться. Его также можно давать новичкам на онбординге, чтобы упростить погружение в работу. Также будет полезно иногда повторять этот семинар, потому что люди меняются.
Получилось много, но ещё не всё. В следующем посте поговорим о том, как собирать команду с нуля, опираясь на ценности.
#management
В предыдущих сериях мы уже выяснили, что ценности команды - штука важная, нужная и существующая вне зависимости от субъективного мнения окружающих о них. Однако главная интрига остается не раскрытой.
Что это вообще за ценности такие? Как они выглядят? И главное - как их выявить и использовать себе и команде во благо?
Начнем с конца и разберёмся, как определить ценности. Лично я знаю три способа:
1. Вангование
2. Гадание на картах Таро
3. Командный семинар по выявлению ценностей
Первые два я привел не только шутки ради. Люди в целом склонны придумывать и додумывать себе разные интересные вещи, никак не связанные с реальностью. С ценностями такая же история: их можно предположить, но это не гарантирует точного попадание. В общем, общайтес.
Переходим к третьему пункту, а именно к командному семинару. Фактически это обычное собрание, в рамках которого члены команды должны ответить на ряд вопросов:
Что для меня ценно в команде и командной работе?
Каждый член команды накидывает свои варианты ценностей. Здесь может быть все, что угодно: помощь и взаимовыручка, уважение коллег, приватный чат с мемами, ходить в бар по пятницам после работы с командой и так далее.
На этом этапе лучше всего устроить бреиншторм и не ограничивать людей в вариантах. Пусть они напишут все, что считаю важным. Затем возьмите все написанное и попытайтесь сформулировать ценности общего характера для частных случаев. Например, если для человека важно ходить в бар с командой, то это можно отнести к ценности «неформальное общение».
Когда у вас появится набор ценностей, можно перейти к следующему этапу. Для каждой ценности вам нужно ответить на следующие вопросы:
Что эта ценность значит для нас?
Вопрос специально составлен таким образом, чтобы на него не было однозначного ответа. В ответах на него вы узнаете, как члены команды относятся к каждой из ценностей. Важно: сохраняйте фокус на команде, ваша задача - понять, как ценности работают именно в команде.
Как ценность выглядит в действии?
Очень важный вопрос, который «приземляет» абстрактные ценности на конкретные действия. В ответах вы узнаете, в каких действиях люди видят проявление той или иной ценности (см. пример про бар).
Как эту ценность можно неверно понять?
Заглядываем на тёмную сторону мира ценности. Ту же ценность неформального общения легко истолковать как «я обязан ходить с коллегами в бар, чтобы меня принимали в команде». Ответив на вопрос, вы определите границы ценности.
Как мы поймем, что ценность соблюдается?
Здесь хорошо будет вернуться к конкретным действиям и ещё раз их обсудить. Постарайтесь переложить всё написанное на повседневную жизнь команды. Возможно, какие-то штуки стоит делать почаще.
Как эта ценность изменит работу или отношения в команде?
Вопрос, который накрепко вбивает в членов команды понимание, почему ценность важна для всех. Он фактически подводит результат всей проделанной вами работы и даёт людям понять, ради чего они столько времени напрягались.
Провести такой семинар непросто, да и времени он съедает прилично. Но результаты могут вас приятно удивить. Сам факт командного разговора о важных для каждого члена вещах сближает людей и помогает им лучше понять друг друга.
Что потом делать с написанными ценностями - решайте сами. Вполне неплохой идеей будет написать манифест и регулярно к нему возвращаться. Его также можно давать новичкам на онбординге, чтобы упростить погружение в работу. Также будет полезно иногда повторять этот семинар, потому что люди меняются.
Получилось много, но ещё не всё. В следующем посте поговорим о том, как собирать команду с нуля, опираясь на ценности.
#management
Как Figma масштабировали свою БД, часть 1
По работе мы с командой сейчас очень плотно занимаемся вопросами масштабирования БД в целом и шардирования в частности. Поэтому я довольно много смотрю/читаю всего, что связано с этой темой.
На выходных прочитал замечательную эпопею о том, как Figma столкнулись с проблемами роста своей БД. У них был заряженный по железу монолитный Postgresql, который всё-таки начал упираться в свои пределы.
Из интересного в статье:
👉 Базовые тактические действия, когда БД начинает не вывозить
👉 Почему Figma отказались от переезда на другие БД
👉 Как инженеры Figma делали вертикальное партиционирование (вытаскивали таблицы в отдельные базы) без даунтайма (но есть нюанс)
Рекомендую к ознакомлению всем, у кого база потенциально может начать задыхаться. Будете знать, к чему готовиться :)
Приятного чтения!
#architecture #highload #db
По работе мы с командой сейчас очень плотно занимаемся вопросами масштабирования БД в целом и шардирования в частности. Поэтому я довольно много смотрю/читаю всего, что связано с этой темой.
На выходных прочитал замечательную эпопею о том, как Figma столкнулись с проблемами роста своей БД. У них был заряженный по железу монолитный Postgresql, который всё-таки начал упираться в свои пределы.
Из интересного в статье:
👉 Базовые тактические действия, когда БД начинает не вывозить
👉 Почему Figma отказались от переезда на другие БД
👉 Как инженеры Figma делали вертикальное партиционирование (вытаскивали таблицы в отдельные базы) без даунтайма (но есть нюанс)
Рекомендую к ознакомлению всем, у кого база потенциально может начать задыхаться. Будете знать, к чему готовиться :)
Приятного чтения!
#architecture #highload #db
Как строить команду с нуля, основываясь на ценностях?
В предыдущем посте мы разобрались, как определить ценности команды за несколько часов. Этот способ хорошо работает, если команда уже существует и функционирует. Но что делать, если команды нет и руководителю только предстоит её создать?
Хочет руководитель того или нет, но ценностями новой команды станут его ценности. Потому что именно по ним он будет подбирать и оценивать людей. В некотором роде ему можно даже позавидовать, ведь у него есть крутейшая возможность собрать команду сразу под свои ценности. Но для начала руководителю придётся провести сессию определения ценностей с одним человеком - самим собой.
Семинар по определению ценностей команды из одного человека
Первое, что нужно понять - команда уже есть. Просто она пока что состоит из одного человека. Но тем не менее у этой команды уже есть некоторые планы, задачи, амбиции и ценности. Поэтому имеет смысл заняться их определением.
Достаточно просто взять структуру из предыдущего поста и пройтись по вопросам. Однако в одиночку это упражнение может быть чуть сложнее, потому что нет притока идей со стороны и иногда бывает не за что зацепиться. В этом случае можно использовать вспомогательные вопросы.
Что делало мои предыдущие команды успешными?
Это могут быть не обязательно команды в прямом управлении - вполне подойдут и команды, в которых вы просто работали. Вспомните, что для вас было ценно и важно, почему вам было комфортно (или некомфортно) работать. Это как даст как минимум несколько идей для старта.
Что для меня важно в людях, с которыми я работаю?
Этот вопрос является логическим продолжением предыдущего. Команда состоит из людей, поэтому подумайте: с кем особенно приятно было работать? А почему? Ответ на этот вопрос поможет вывести уже конкретные ценности.
Определение ценностей может выглядеть скучным и бесполезным занятием. Зачем заниматься какой-то философией и высокими материями, когда работать надо? Но мой опыт показывает, что самые прочные команды чётко осознают свои ценности и используют их в повседневной работе. Поэтому стоит сразу заложить фундамент ценностей, на которых будет строиться команда. Дальше будет сложнее.
#management
В предыдущем посте мы разобрались, как определить ценности команды за несколько часов. Этот способ хорошо работает, если команда уже существует и функционирует. Но что делать, если команды нет и руководителю только предстоит её создать?
Хочет руководитель того или нет, но ценностями новой команды станут его ценности. Потому что именно по ним он будет подбирать и оценивать людей. В некотором роде ему можно даже позавидовать, ведь у него есть крутейшая возможность собрать команду сразу под свои ценности. Но для начала руководителю придётся провести сессию определения ценностей с одним человеком - самим собой.
Семинар по определению ценностей команды из одного человека
Первое, что нужно понять - команда уже есть. Просто она пока что состоит из одного человека. Но тем не менее у этой команды уже есть некоторые планы, задачи, амбиции и ценности. Поэтому имеет смысл заняться их определением.
Достаточно просто взять структуру из предыдущего поста и пройтись по вопросам. Однако в одиночку это упражнение может быть чуть сложнее, потому что нет притока идей со стороны и иногда бывает не за что зацепиться. В этом случае можно использовать вспомогательные вопросы.
Что делало мои предыдущие команды успешными?
Это могут быть не обязательно команды в прямом управлении - вполне подойдут и команды, в которых вы просто работали. Вспомните, что для вас было ценно и важно, почему вам было комфортно (или некомфортно) работать. Это как даст как минимум несколько идей для старта.
Что для меня важно в людях, с которыми я работаю?
Этот вопрос является логическим продолжением предыдущего. Команда состоит из людей, поэтому подумайте: с кем особенно приятно было работать? А почему? Ответ на этот вопрос поможет вывести уже конкретные ценности.
Определение ценностей может выглядеть скучным и бесполезным занятием. Зачем заниматься какой-то философией и высокими материями, когда работать надо? Но мой опыт показывает, что самые прочные команды чётко осознают свои ценности и используют их в повседневной работе. Поэтому стоит сразу заложить фундамент ценностей, на которых будет строиться команда. Дальше будет сложнее.
#management
Telegram
Никита Ульшин про IT
Как определить ценности команды?
В предыдущих сериях мы уже выяснили, что ценности команды - штука важная, нужная и существующая вне зависимости от субъективного мнения окружающих о них. Однако главная интрига остается не раскрытой.
Что это вообще за ценности…
В предыдущих сериях мы уже выяснили, что ценности команды - штука важная, нужная и существующая вне зависимости от субъективного мнения окружающих о них. Однако главная интрига остается не раскрытой.
Что это вообще за ценности…
Как Figma масштабировали свою БД, часть 2
Предыдущая часть вызвала интерес, делюсь продолжением.
Figma смогли выграть некоторое время с помощью тактических действий и вертикального партиционирования, но инженеры поняли, что рано или поздно столкнутся с той же проблемой. Единственным способом снять ограничения была реализация бесшовного, удобного горизонтального шардирования. Поэтому они заранее определили требования к реализации и приступили к проектированию.
Во второй части рассказывается о том, как они переделали архитектуру БД и достигли (почти) бесконечного scalability:
👉 Разделение таблиц на группы (colocations), которые объединены ключом шардирования и физическим размещением данных
👉 Зачем инженеры Figma написали свой роутер подключений к БД
👉 Как проверить поведение продакшн трафика до релиза в продакшн
По сути, Figma придумали уникальное инженерное решение, которое решает конкретно их спектр задач. Не рекомендую бездумно повторятьдома у себя на проекте. Но рекомендую ознакомиться, чтобы иметь представление о том аде, который происходит в мире больших баз данных.
Приятного чтения!
#architecture #highload #db
Предыдущая часть вызвала интерес, делюсь продолжением.
Figma смогли выграть некоторое время с помощью тактических действий и вертикального партиционирования, но инженеры поняли, что рано или поздно столкнутся с той же проблемой. Единственным способом снять ограничения была реализация бесшовного, удобного горизонтального шардирования. Поэтому они заранее определили требования к реализации и приступили к проектированию.
Во второй части рассказывается о том, как они переделали архитектуру БД и достигли (почти) бесконечного scalability:
👉 Разделение таблиц на группы (colocations), которые объединены ключом шардирования и физическим размещением данных
👉 Зачем инженеры Figma написали свой роутер подключений к БД
👉 Как проверить поведение продакшн трафика до релиза в продакшн
По сути, Figma придумали уникальное инженерное решение, которое решает конкретно их спектр задач. Не рекомендую бездумно повторять
Приятного чтения!
#architecture #highload #db
Три отличные книги по логике
Лично мне логика кажется важнейшим инструментом любого айтишника. Даже в технической части решения бывают очень разные, и умение беспристрастно логически анализировать их — очень важно. А уж для переговоров я вообще молчу: умение оперировать логическими категориями сильно помогает составлять понятные договорённости.
В целом большинство людей так или иначе владеют логикой даже без её фундаментального понимания (привет школе и институту). Однако явное лучше, чем неявное, поэтому я уделил силы и время подкачке своих навыков логического мышления. Для этого я прошёл курс Максима Дорофеева и прочитал несколько книг. Про курс расскажу отдельно, а вот книгами поделюсь.
Книги во многом пересекаются и сходны по тематике, поэтому я решил объединить их в один пост.
📖 Сергей Виноградов "Логика. Учебник для средней школы"
Начать предлагаю с этого достаточно простого учебника, который погрузит вас в базовые понятия логики на примерах. Учебник рассчитан на школьников, поэтому читать его просто и приятно. А ещё смешно, потому что учебник — советский, и автор постоянно восхваляет советскую власть, товарищей Ленина и Сталина.
Лично мне читать было легко, приятно и смешно благодаря ярким просоветским вставкам. Очень рекомендую.
📖 Георгий Челпанов "Учебник логики"
Учебник Челпанова — это уже более продвинутое чтиво. Академический слог, схемы, формулы логики поджидают любопытного читателя на страницах этой книги. Примеры тоже более сложные и интересные.
Часть информации пересекается с книгой Виноградова, однако многие вещи разобраны глубже и полнее. Также в книге Челпанова очень плотно раскрыты темы индукции/дедукции, силлогизмов и обобщений.
Мне понравилось читать её второй, потому что после учебника Виноградова уже появилась база, и новые идеи легче воспринимались.
📖 Александр Ивин "Искусство мыслить правильно"
Завершает наш список прекрасная книга на тему языка и мышления — "Искусство мыслить правильно". Если первые две книги фокусируются на логике как на науке, то книга Ивина, в свою очередь, рассказывает про логику в реальной жизни.
Автор акцентирует внимание на повседневной, будничной логике: определения слов и названия вещей, какие есть языковые ловушки, софизмы, как применять доказательства и так далее. В книге очень много ярких, интересных примеров (например, есть прекрасная глава "О смысле бессмысленного", где в пример приводятся части "Алисы в стране чудес").
Для меня книга стала отличным дополнением к первым двум благодаря необычным и интересным примерам. Но её можно читать и отдельно — получите и отличные идеи, и эстетическое удовольствие.
В бэклоге у меня лежит ещё несколько интересных книг по логике, буду делиться по мере чтения.
Если читали что-то из вышеперечисленного — делитесь в комментариях своими впечатлениями.
#обзор_книги
Лично мне логика кажется важнейшим инструментом любого айтишника. Даже в технической части решения бывают очень разные, и умение беспристрастно логически анализировать их — очень важно. А уж для переговоров я вообще молчу: умение оперировать логическими категориями сильно помогает составлять понятные договорённости.
В целом большинство людей так или иначе владеют логикой даже без её фундаментального понимания (привет школе и институту). Однако явное лучше, чем неявное, поэтому я уделил силы и время подкачке своих навыков логического мышления. Для этого я прошёл курс Максима Дорофеева и прочитал несколько книг. Про курс расскажу отдельно, а вот книгами поделюсь.
Книги во многом пересекаются и сходны по тематике, поэтому я решил объединить их в один пост.
📖 Сергей Виноградов "Логика. Учебник для средней школы"
Начать предлагаю с этого достаточно простого учебника, который погрузит вас в базовые понятия логики на примерах. Учебник рассчитан на школьников, поэтому читать его просто и приятно. А ещё смешно, потому что учебник — советский, и автор постоянно восхваляет советскую власть, товарищей Ленина и Сталина.
Лично мне читать было легко, приятно и смешно благодаря ярким просоветским вставкам. Очень рекомендую.
📖 Георгий Челпанов "Учебник логики"
Учебник Челпанова — это уже более продвинутое чтиво. Академический слог, схемы, формулы логики поджидают любопытного читателя на страницах этой книги. Примеры тоже более сложные и интересные.
Часть информации пересекается с книгой Виноградова, однако многие вещи разобраны глубже и полнее. Также в книге Челпанова очень плотно раскрыты темы индукции/дедукции, силлогизмов и обобщений.
Мне понравилось читать её второй, потому что после учебника Виноградова уже появилась база, и новые идеи легче воспринимались.
📖 Александр Ивин "Искусство мыслить правильно"
Завершает наш список прекрасная книга на тему языка и мышления — "Искусство мыслить правильно". Если первые две книги фокусируются на логике как на науке, то книга Ивина, в свою очередь, рассказывает про логику в реальной жизни.
Автор акцентирует внимание на повседневной, будничной логике: определения слов и названия вещей, какие есть языковые ловушки, софизмы, как применять доказательства и так далее. В книге очень много ярких, интересных примеров (например, есть прекрасная глава "О смысле бессмысленного", где в пример приводятся части "Алисы в стране чудес").
Для меня книга стала отличным дополнением к первым двум благодаря необычным и интересным примерам. Но её можно читать и отдельно — получите и отличные идеи, и эстетическое удовольствие.
В бэклоге у меня лежит ещё несколько интересных книг по логике, буду делиться по мере чтения.
Если читали что-то из вышеперечисленного — делитесь в комментариях своими впечатлениями.
#обзор_книги
Сегодня на А?.Frontend рассказал немного про тёмную сторону BFF и как заложить потенциальные сбои в его дизайн.
Спасибо организаторам и гостям за тёплый прием, было очень приятно выступать ❤️
Отдельно хочу отметить отличные вопросы от аудитории, было трудно выбрать всего два лучших (я бы вам всем подарки дал, честное слово 🔥).
Записью поделюсь, как только будет возможность 🥰
Спасибо организаторам и гостям за тёплый прием, было очень приятно выступать ❤️
Отдельно хочу отметить отличные вопросы от аудитории, было трудно выбрать всего два лучших (я бы вам всем подарки дал, честное слово 🔥).
Записью поделюсь, как только будет возможность 🥰
Зачем выступать публично?
Я думаю, что все вокруг уже прекрасно осведомлены о пользе публичных выступлений. Личный бренд, заявление о своей экспертности, вот это вот всё. По мотивам своего субботнего выступления тоже хочу накинуть пару необычных ответов на вопрос "Зачем?"
Это стрёмно
Представить свой доклад публике всегда волнительно. У меня даже на внутренних прогонах с супер-лояльными коллегами колотится сердце и потеют ладошки. Что уж говорить о рассказе чего-то сотне-другой незнакомцев? А вдруг помидорами закидают?
Но преодоление этого страха вызывает настоящую эйфорию. Когда заканчивается доклад и уходят остатки адреналина, то возникает осознание сделанного. И это осознание приносит огромное удовольствие и удовлетворение от проделанной работы. А если ещё и обратной связи хорошей накидают, то можно на мгновение ощутить себя центром Вселенной.
Это сложно
Даже небольшой базовый докладик на 20 минут - это часы напряжённой работы. Давайте расскажу, что входит в "сделать докладик на 20 минут":
1. Придумать идею.
2. Написать тезисы.
3. Найти подходящую конфу или митап.
4. Подать туда заявку.
5. Презентовать свою тему кому-то из ПК.
6. Если доклад не одобрили - запросить фидбек и начать с п.1
7. Если доклад одобрили - его нужно сделать.
8. Провести несколько тестовых прогонов доклада (обычно от двух до бесконечности)
9. Нормально прочитать сам доклад на конфе
10. Нормально ответить на вопросы к докладу
11. Нормально ответить на вопросы после доклада
Кто там хотел сложных задач от работы? Как вам такое?
Сделать любой доклад - это большой и сложный труд. Когда идёшь по этому пути первые разы, то сталкиваешься с неожиданными трудностями и вызовами. Каждый доклад - это не просто проект, это маленькая жизнь.
Это необычно
Вы наверняка слышали, что наш мозг любит всё новое-интересное. Так вот, публичные выступления сильно выталкивают из зоны комфорта. Если тимлидам ещё более-менее привычно презентовать свои идеи, то для разработчиков это сильно нестандартная деяельность. Сделать что-то новое - это всегда прикольно и интересно, потому что помогает по-новому взглянуть на привычные вещи.
В общем, выступайте и будет вам новый опыт.
Я думаю, что все вокруг уже прекрасно осведомлены о пользе публичных выступлений. Личный бренд, заявление о своей экспертности, вот это вот всё. По мотивам своего субботнего выступления тоже хочу накинуть пару необычных ответов на вопрос "Зачем?"
Это стрёмно
Представить свой доклад публике всегда волнительно. У меня даже на внутренних прогонах с супер-лояльными коллегами колотится сердце и потеют ладошки. Что уж говорить о рассказе чего-то сотне-другой незнакомцев? А вдруг помидорами закидают?
Но преодоление этого страха вызывает настоящую эйфорию. Когда заканчивается доклад и уходят остатки адреналина, то возникает осознание сделанного. И это осознание приносит огромное удовольствие и удовлетворение от проделанной работы. А если ещё и обратной связи хорошей накидают, то можно на мгновение ощутить себя центром Вселенной.
Это сложно
Даже небольшой базовый докладик на 20 минут - это часы напряжённой работы. Давайте расскажу, что входит в "сделать докладик на 20 минут":
1. Придумать идею.
2. Написать тезисы.
3. Найти подходящую конфу или митап.
4. Подать туда заявку.
5. Презентовать свою тему кому-то из ПК.
6. Если доклад не одобрили - запросить фидбек и начать с п.1
7. Если доклад одобрили - его нужно сделать.
8. Провести несколько тестовых прогонов доклада (обычно от двух до бесконечности)
9. Нормально прочитать сам доклад на конфе
10. Нормально ответить на вопросы к докладу
11. Нормально ответить на вопросы после доклада
Кто там хотел сложных задач от работы? Как вам такое?
Сделать любой доклад - это большой и сложный труд. Когда идёшь по этому пути первые разы, то сталкиваешься с неожиданными трудностями и вызовами. Каждый доклад - это не просто проект, это маленькая жизнь.
Это необычно
Вы наверняка слышали, что наш мозг любит всё новое-интересное. Так вот, публичные выступления сильно выталкивают из зоны комфорта. Если тимлидам ещё более-менее привычно презентовать свои идеи, то для разработчиков это сильно нестандартная деяельность. Сделать что-то новое - это всегда прикольно и интересно, потому что помогает по-новому взглянуть на привычные вещи.
В общем, выступайте и будет вам новый опыт.
Забор Честертона
Представьте, что вы идёте по цветущему ромашковому лугу и внезапно упираетесь в забор. Просто забор, без ограды или чего-либо ещё. "Что за ерунда?" — скорее всего, первое, что вы подумаете.
Наверняка у вас возникнут мысли о том, что забору здесь не место, и вообще, было бы неплохо его снести. Но это плохое решение, потому что вы не знаете назначения этого забора. В своё время по этому поводу удачно выразился Гилберт Честертон: «Никогда не ломайте забор, не узнав, зачем его поставили».
Аналогия с забором хорошо показывает, как мы можем заблуждаться в своих убеждениях. Часто специалист приходит в новую команду и думает: "А чего это у вас тут всё так плохо сделано? Сейчас поправим". Это не так страшно, если этим занимаются программисты — их на код-ревью остановят и всё объяснят. Но ситуация становится гораздо интереснее, когда принцип забора Честертона начинают нарушать тимлиды и руководители на более высоких уровнях.
Не все команды успели построить устойчивые системы, а иногда вообще всё держится на временных решениях и взаимовыручке. Поэтому изменение даже незначительной на первый взгляд детали (того самого забора) может привести к нарушению всего процесса и коллапсу.
Внесение изменений без понимания ситуации может создать массу проблем как для руководителя, так и для его команды. Да, энтузиазм руководителя понятен — он пришёл на новое место и хочет как можно быстрее показать себя с лучшей стороны. Но если вы начинаете работать в новых условиях, лучше сначала собрать как можно больше информации и разобраться, как всё устроено. Иначе это может закончиться как в той байке, где программисты поддерживали "Войну и мир".
Представьте, что вы идёте по цветущему ромашковому лугу и внезапно упираетесь в забор. Просто забор, без ограды или чего-либо ещё. "Что за ерунда?" — скорее всего, первое, что вы подумаете.
Наверняка у вас возникнут мысли о том, что забору здесь не место, и вообще, было бы неплохо его снести. Но это плохое решение, потому что вы не знаете назначения этого забора. В своё время по этому поводу удачно выразился Гилберт Честертон: «Никогда не ломайте забор, не узнав, зачем его поставили».
Аналогия с забором хорошо показывает, как мы можем заблуждаться в своих убеждениях. Часто специалист приходит в новую команду и думает: "А чего это у вас тут всё так плохо сделано? Сейчас поправим". Это не так страшно, если этим занимаются программисты — их на код-ревью остановят и всё объяснят. Но ситуация становится гораздо интереснее, когда принцип забора Честертона начинают нарушать тимлиды и руководители на более высоких уровнях.
Не все команды успели построить устойчивые системы, а иногда вообще всё держится на временных решениях и взаимовыручке. Поэтому изменение даже незначительной на первый взгляд детали (того самого забора) может привести к нарушению всего процесса и коллапсу.
Внесение изменений без понимания ситуации может создать массу проблем как для руководителя, так и для его команды. Да, энтузиазм руководителя понятен — он пришёл на новое место и хочет как можно быстрее показать себя с лучшей стороны. Но если вы начинаете работать в новых условиях, лучше сначала собрать как можно больше информации и разобраться, как всё устроено. Иначе это может закончиться как в той байке, где программисты поддерживали "Войну и мир".
Грег Хорин "Управление проектами с нуля"
Совершая камбэк в роль тимлида, я решил освежить и систематизировать знания в области управления проектами. Мой выбор пал на книгу Грега Хорина "Управление проектами с нуля".
О чём книга
Книга, по сути, является большим настольным справочником по базовому управлению проектами. Она состоит из пяти больших частей: быстрый старт, планирование проекта, контроль хода выполнения проекта, выполнение работ по проекту и "ускорение обучения".
Первая часть знакомит читателя с терминологией и определением проектного менеджера. По сути, это просто введение, но без него будет тяжело читать дальше.
Вторая часть посвящена планированию, декомпозиции и оценке проекта. Здесь подробно обсуждаются вопросы определения и планирования проекта, разработки структуры декомпозиции работ, создания графика и составления бюджета проекта.
В третьей части обсуждается контроль выполнения проекта. Это одна из самых важных частей книги, потому что в ней раскрыты темы управления изменениями и конечными результатами проекта. Также в ней рассматривается тема управления проектными рисками (не так глубоко, как хотелось бы, но в целом вполне неплохо).
Четвёртая часть тоже показалась мне очень важной, потому что она посвящена управлению ходом проекта и коммуникации со стейкхолдерами. Мне она оказалась наиболее полезной, потому что ранее мои навыки презентации результатов работы откровенно страдали. Я нашёл несколько полезных советов.
Пятая часть содержит главы, которые не показались мне слишком полезными: например, про использование Microsoft Project и подготовку к сертификации. Однако довольно интересными оказались главы про управление проектами в реальных условиях. Здесь, по сути, обсуждается ответ на вопрос: "Что делать, когда всё идёт не по плану?" (то есть примерно каждый день).
Мои впечатления
Книга — отличный, достаточно подробный настольный справочник проектного менеджера. Считаю её крайне полезной для тимлидов, потому что в ней найдут много полезного как начинающие, так и опытные специалисты.
Конечно, многие темы в книге раскрыты не очень глубоко. Но я не считаю это недостатком, потому что задача книги — дать общее понимание, обзор темы управления проектами. Если какая-то тема сильно заинтересовала, это отличный повод углубиться в неё самостоятельно.
Также хочу отметить, что в книге много разных полезных чек-листов (уважаемому автору Итак, список это точно понравится). Поэтому я рекомендую использовать её как настольный справочник: многие чек-листы и опросники можно просто брать и применять в работе. Они могут быть не идеальными, но точно заставят задуматься в нужную сторону.
Отличная книга для тимлидов всех уровней — знания по управлению проектами ещё никому не вредили. :)
#management #book #обзор_книги
Совершая камбэк в роль тимлида, я решил освежить и систематизировать знания в области управления проектами. Мой выбор пал на книгу Грега Хорина "Управление проектами с нуля".
О чём книга
Книга, по сути, является большим настольным справочником по базовому управлению проектами. Она состоит из пяти больших частей: быстрый старт, планирование проекта, контроль хода выполнения проекта, выполнение работ по проекту и "ускорение обучения".
Первая часть знакомит читателя с терминологией и определением проектного менеджера. По сути, это просто введение, но без него будет тяжело читать дальше.
Вторая часть посвящена планированию, декомпозиции и оценке проекта. Здесь подробно обсуждаются вопросы определения и планирования проекта, разработки структуры декомпозиции работ, создания графика и составления бюджета проекта.
В третьей части обсуждается контроль выполнения проекта. Это одна из самых важных частей книги, потому что в ней раскрыты темы управления изменениями и конечными результатами проекта. Также в ней рассматривается тема управления проектными рисками (не так глубоко, как хотелось бы, но в целом вполне неплохо).
Четвёртая часть тоже показалась мне очень важной, потому что она посвящена управлению ходом проекта и коммуникации со стейкхолдерами. Мне она оказалась наиболее полезной, потому что ранее мои навыки презентации результатов работы откровенно страдали. Я нашёл несколько полезных советов.
Пятая часть содержит главы, которые не показались мне слишком полезными: например, про использование Microsoft Project и подготовку к сертификации. Однако довольно интересными оказались главы про управление проектами в реальных условиях. Здесь, по сути, обсуждается ответ на вопрос: "Что делать, когда всё идёт не по плану?" (то есть примерно каждый день).
Мои впечатления
Книга — отличный, достаточно подробный настольный справочник проектного менеджера. Считаю её крайне полезной для тимлидов, потому что в ней найдут много полезного как начинающие, так и опытные специалисты.
Конечно, многие темы в книге раскрыты не очень глубоко. Но я не считаю это недостатком, потому что задача книги — дать общее понимание, обзор темы управления проектами. Если какая-то тема сильно заинтересовала, это отличный повод углубиться в неё самостоятельно.
Также хочу отметить, что в книге много разных полезных чек-листов (уважаемому автору Итак, список это точно понравится). Поэтому я рекомендую использовать её как настольный справочник: многие чек-листы и опросники можно просто брать и применять в работе. Они могут быть не идеальными, но точно заставят задуматься в нужную сторону.
Отличная книга для тимлидов всех уровней — знания по управлению проектами ещё никому не вредили. :)
#management #book #обзор_книги
Как я провёл это субботнее утро
Я немного барабанщик. Открыл для себя ударную установку больше года назад и с тех занимаюсь, даже пару раз выступал с песнями в своей любимой-дорогой школе барабанов.
Ещё я (естественно) посматриваю всякие интересные видосики, связанные с барабанами. Обычно я про них рассказываю только в нашем барабанном чатике, но сегодняшнее видео меня немножко порвало.
У Drumeo есть классное шоу, где приглашённые барабанщики должны подобрать партию к песне, которую они никогда раньше не слышали. При этом песню им включают без ударных, оригинальную партию они слышат только после того, как отыграют свою. Забавнее всего, что песня частенько оказывается довольно популярной. И сегодня этой песней оказалась Toxicity группы System Of A Down, которую я сейчас разучиваю.
Было очень интересно посмотреть-послушать альтернативную интерпретацию того, что я сейчас по несколько часов в неделю наигрываю. Рекомендую и вам посмотреть это шоу, оно интересно само по себе, даже если вы не занимаетесь музыкой (проверено на жене).
Видео тут: https://www.youtube.com/watch?v=hyR5-b1wfrw
А чем вы с утра занимаетесь?
Я немного барабанщик. Открыл для себя ударную установку больше года назад и с тех занимаюсь, даже пару раз выступал с песнями в своей любимой-дорогой школе барабанов.
Ещё я (естественно) посматриваю всякие интересные видосики, связанные с барабанами. Обычно я про них рассказываю только в нашем барабанном чатике, но сегодняшнее видео меня немножко порвало.
У Drumeo есть классное шоу, где приглашённые барабанщики должны подобрать партию к песне, которую они никогда раньше не слышали. При этом песню им включают без ударных, оригинальную партию они слышат только после того, как отыграют свою. Забавнее всего, что песня частенько оказывается довольно популярной. И сегодня этой песней оказалась Toxicity группы System Of A Down, которую я сейчас разучиваю.
Было очень интересно посмотреть-послушать альтернативную интерпретацию того, что я сейчас по несколько часов в неделю наигрываю. Рекомендую и вам посмотреть это шоу, оно интересно само по себе, даже если вы не занимаетесь музыкой (проверено на жене).
Видео тут: https://www.youtube.com/watch?v=hyR5-b1wfrw
А чем вы с утра занимаетесь?
YouTube
Gregg Bissonette Hears System Of A Down For The First Time
Take a sneak peek into the mind of Gregg Bissonette. Watch as he listens to "Toxicity" by System Of A Down for the very first time and attempts to play along. How does he immediately craft an appropriate drum part? Tune in and find out!
Try 7 Days Of Drumeo…
Try 7 Days Of Drumeo…
Что бы я посоветовал другу?
Моим главным препятствием на пути к рефлексии был (и частично остаётся) перфекционизм. Анализ ошибок давался с трудом, потому что я частенько скатывался в критику и терял рациональность. В какой-то момент дошло до того, что сама мысль об анализе ошибок вызывала у меня тревогу.
С одной стороны, я понимал, что так дело не пойдёт — поразмыслить над своими ошибками бывает полезно и всё такое. Но и заставлять себя заниматься тревожно-раздражающей деятельностью я тоже не хотел, потому что после очередной сессии таких «размышлений» настроения что-либо делать не было от слова совсем.
Помощь неожиданно пришла из книги Дэвида Бернса «Терапия беспокойства». Сама по себе книга прекрасная, и я очень рекомендую её к прочтению, если вы страдаете от тревоги. В ней описано множество техник, которые помогают справиться с тревогой. Одна из этих техник и помогла мне ослабить самокритику.
Техника называется «Что бы я посоветовал другу?». Суть её заключается в том, чтобы сменить точку зрения на проблему. Я рассматриваю ситуацию так, будто с ней ко мне обратился мой друг, и стараюсь ответить себе на вопрос: «Что бы я сказал ему в такой ситуации?»
Мы зачастую намного мягче и добрее относимся к другим людям, нежели к самим себе. Техника «Что бы я посоветовал другу?» помогает применить это доброе и заботливое отношение к себе, что позволяет более здраво и спокойно анализировать проблемы. Часто оказывается, что ошибка не так уж страшна, исправить её легко, и в целом нет повода для беспокойства. Вряд ли вы будете разгромно критиковать друга, который принёс вам свою проблему, верно?
Сейчас я не очень часто применяю эту технику, потому что научился оценивать себя менее критично. Однако периодически, в сложные моменты жизни, она мне сильно помогает успокоиться и взглянуть на сложившуюся ситуацию более трезво.
#self_management
Моим главным препятствием на пути к рефлексии был (и частично остаётся) перфекционизм. Анализ ошибок давался с трудом, потому что я частенько скатывался в критику и терял рациональность. В какой-то момент дошло до того, что сама мысль об анализе ошибок вызывала у меня тревогу.
С одной стороны, я понимал, что так дело не пойдёт — поразмыслить над своими ошибками бывает полезно и всё такое. Но и заставлять себя заниматься тревожно-раздражающей деятельностью я тоже не хотел, потому что после очередной сессии таких «размышлений» настроения что-либо делать не было от слова совсем.
Помощь неожиданно пришла из книги Дэвида Бернса «Терапия беспокойства». Сама по себе книга прекрасная, и я очень рекомендую её к прочтению, если вы страдаете от тревоги. В ней описано множество техник, которые помогают справиться с тревогой. Одна из этих техник и помогла мне ослабить самокритику.
Техника называется «Что бы я посоветовал другу?». Суть её заключается в том, чтобы сменить точку зрения на проблему. Я рассматриваю ситуацию так, будто с ней ко мне обратился мой друг, и стараюсь ответить себе на вопрос: «Что бы я сказал ему в такой ситуации?»
Мы зачастую намного мягче и добрее относимся к другим людям, нежели к самим себе. Техника «Что бы я посоветовал другу?» помогает применить это доброе и заботливое отношение к себе, что позволяет более здраво и спокойно анализировать проблемы. Часто оказывается, что ошибка не так уж страшна, исправить её легко, и в целом нет повода для беспокойства. Вряд ли вы будете разгромно критиковать друга, который принёс вам свою проблему, верно?
Сейчас я не очень часто применяю эту технику, потому что научился оценивать себя менее критично. Однако периодически, в сложные моменты жизни, она мне сильно помогает успокоиться и взглянуть на сложившуюся ситуацию более трезво.
#self_management
Большие проблемы маленьких изменений
Не так страшны первые 90% проекта, как вторые 90% проекта.
Шутка смешная, а ситуация страшная. Если проект проработан слабо, то его с высокой вероятностью ждёт судьба из шутки - медленное, мучительное доталкивание до конца.
Для плохо проработанных проектов проблема очевидна: на старте много чего не продумали, и это "много чего" начинает вылезать в процессе работы. Но в такой же ситуации могут оказаться и вполне достойно проработанные проекты. Вроде всё продумали и расписали, а в срок не попадаем. Почему?
Из моего опыта самая частая причина смещения сроков - это изменения проекта. Вот был нормальный, проработанный эпик. Команда его делает-делает, тут прибегает продакт и говорит, что нужно срочно добавить вот сюда маленькую кнопочку. Раз, второй, третий - и вот проект завершается на месяц позже.
Собака часто бывает зарыта в процессе управления изменениями. Крупные и средние изменения обычно не проходят мимо - ответственный за проект их документирует, оценивает, утверждает и так далее. Но при этом маленькие, почти незаметные изменения часто игнорируются. Ведь ничего же страшного не произойдёт, такая мелочь не повлияет на объём проекта? Не повлияет, правда?
Каждое маленькое изменение может быть незаметным само по себе и не оказывать существенного влияния на проект. Но когда у проектного менеджера есть привычка игнорировать такие мелочи, то они накапливаются и могут значительно увеличить сроки выполнения.
Избежать изменений объёма работ по проекту не получится (да и смысла в этом нет). Изменения несут опасность, только если ими не управлять. Самый простой выход из ситуации - документировать любые изменения вне зависимости от их размера. Тогда ни одна мелочь не проскочит незамеченной, а в случае смещения сроков завершения проекта будет понятна причина.
Более того, документирование и оценка изменений иногда подталкивают представителей бизнеса к тому, чтобы отказаться от изменения. Когда стейкхолдеры видят, что их хотелка увеличит сроки на две недели, то могут задуматься, стоит ли реализация хотелки такой задержки.
Не так страшны первые 90% проекта, как вторые 90% проекта.
Шутка смешная, а ситуация страшная. Если проект проработан слабо, то его с высокой вероятностью ждёт судьба из шутки - медленное, мучительное доталкивание до конца.
Для плохо проработанных проектов проблема очевидна: на старте много чего не продумали, и это "много чего" начинает вылезать в процессе работы. Но в такой же ситуации могут оказаться и вполне достойно проработанные проекты. Вроде всё продумали и расписали, а в срок не попадаем. Почему?
Из моего опыта самая частая причина смещения сроков - это изменения проекта. Вот был нормальный, проработанный эпик. Команда его делает-делает, тут прибегает продакт и говорит, что нужно срочно добавить вот сюда маленькую кнопочку. Раз, второй, третий - и вот проект завершается на месяц позже.
Собака часто бывает зарыта в процессе управления изменениями. Крупные и средние изменения обычно не проходят мимо - ответственный за проект их документирует, оценивает, утверждает и так далее. Но при этом маленькие, почти незаметные изменения часто игнорируются. Ведь ничего же страшного не произойдёт, такая мелочь не повлияет на объём проекта? Не повлияет, правда?
Каждое маленькое изменение может быть незаметным само по себе и не оказывать существенного влияния на проект. Но когда у проектного менеджера есть привычка игнорировать такие мелочи, то они накапливаются и могут значительно увеличить сроки выполнения.
Избежать изменений объёма работ по проекту не получится (да и смысла в этом нет). Изменения несут опасность, только если ими не управлять. Самый простой выход из ситуации - документировать любые изменения вне зависимости от их размера. Тогда ни одна мелочь не проскочит незамеченной, а в случае смещения сроков завершения проекта будет понятна причина.
Более того, документирование и оценка изменений иногда подталкивают представителей бизнеса к тому, чтобы отказаться от изменения. Когда стейкхолдеры видят, что их хотелка увеличит сроки на две недели, то могут задуматься, стоит ли реализация хотелки такой задержки.