Сьюзен Фаулер, «Почему они не работают? Новый взгляд на мотивацию сотрудников»

Благодаря усилиям различных горе-предпринимателей и горе-руководителей термин «мотивация» стал почти таким же ругательным, как «целеполагание». Но при этом тема человеческой мотивации невероятно глубока и интересна.

Я всегда задавался вопросом: что нами движет? Как мы создаём и обретаем смыслы своей деятельности? На разных этапах жизни я получал разные ответы, и сейчас настало время очередного витка моих попыток понять, как человеки (в частности — я сам) мотивируются помимо кнута и пряника.

Моё путешествие длиной в три книги началось с «Почему они не работают?» за авторством Сьюзен Фаулер. Так уж вышло, что на работе я сейчас прохожу глубокое обучение для руководителей, и тема мотивации заинтересовала меня особенно сильно.

⭐️ О чём книга

Я думал, что книга посвящена мотивации сотрудников, но это оказалось так лишь отчасти. Львиная доля книги посвящена модели человеческой мотивации и разнице мотивационных статусов. Основной посыл книги заключается в том, что руководитель должен научиться работать со своей мотивацией, прежде чем лезть к подчинённым. «Познай самого себя» в действии.

В книге раскрываются следующие темы:
➡️Почему метод кнута и пряника не работает?
➡️Какие у нас есть мотивационные статусы и чем они отличаются?
➡️Какие компоненты обязательны для обеспечения оптимальной мотивации?
➡️Как связаны психологическая саморегуляция и мотивация человека?
➡️Как помогать подчинённым находиться на оптимальных уровнях мотивации?

⭐️ 3 идеи из книги

🟡Люди мотивированы всегда — вопрос только в качестве этой мотивации. Один человек гонится за внешними регалиями или бежит от чего-то, а другой делает работу, которая совпадает с его ценностями. С виду они будут делать одно и то же, но разница в состоянии — колоссальная.

🟡Традиционные методы кнута и пряника улучшают краткосрочные результаты, но ухудшают долгосрочные. Исследования показали, что при появлении внешних стимулов люди прикладывают дополнительные усилия, но затем идёт спад. А ещё те же исследования показали падение креативности, появление зашоренности взгляда и сильнейшую демотивацию, если желаемого достичь не удалось.

🟡Три главных компонента мотивации — автономия, принадлежность, компетентность. Людям важно самим принимать решения и чувствовать доверие, делать нечто большее, чем они сами, и успешно справляться с рабочими задачами. При этом отсутствие любого из компонентов вызывает эффект домино и рушит всё остальное.

⭐️ Мои впечатления

Книга просто великолепна. Это вам не Тони Роббинс со своими призывами «ты можешь всё». Это скорее Джордж Карлин, который утверждал, что с мотивацией у вас всё нормально, раз вам хватило её на то, чтобы дойти до книжного магазина и купить книгу по мотивации.

Фаулер даёт несколько классных посылов. Первый заключается в том, что люди мотивированы всегда — вопрос только чем и как. Из этого посыла вытекает понимание, что кнут и пряник могут вообще не сработать или сработать в обратную сторону, поэтому копать нужно глубже.

Второй посыл заключается в том, что менеджеры не умеют работать с мотивацией сотрудников, потому что не понимают её природу и не умеют работать со своей личной мотивацией. И это замечание абсолютно справедливо, потому что работа с мотивацией фактически сводится к набору навыков. Если менеджер не отработал эти навыки на себе и не прожил этот опыт, то как он может применить их к другим людям? Правильно — никак.

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

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

Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

🎙️Про онбординг с Двумя Иванами

В это не такое солнечное и более прохладное воскресенье я принёс вам хороший подкаст.

Два Ивана позвали меня в гости на свой подкаст “Два Ивана”, где мы пообсуждали всякое тимлидское. В частности говорили про онбординг: что это такое и с чем его едят, зачем он нужен и как его проводить так, чтобы всем было максимально комфортно.

Обсуждение вышло живым и очень интересным. Вот некоторые из тем, которые мы затронули:
➡️ Какую роль в онбординге играет тимлид?
➡️ Как парное программирование помогает новичкам?
➡️ Почему оффбординг – это тоже важно?
➡️ Можно ли быть играющим тренером в большой команде?

Главная загадка для меня – почему я на превью выпуска темноволосый… Но это всё мелочи, ведь от записи подкаста я получил море удовольствия и стащил себе несколько классных идей (Ваня, спасибо, я уже обкатал парное программирование на погружении в новый проект).

🎙 А вот и сам подкаст

Приятного прослушивания! И обязательно загляните в канал Ostrovok! Tech, ведь именно они выпускают и поддерживают этот прекрасный подкаст.

Читать легко, а думать — больно

В предыдущем посте я рассказал о том, что процесс письменного размышления над идеями помогает их “переваривать” и делать своими. Я бы сказал, что это и есть настоящий процесс понимания идеи.

Школа и университет превращают людей в инвалидов чтения. Нас задалбливают чтением от корки до корки и обязательным запоминанием всего того, что нам не интересно. Умение понимать прочитанное и глубоко вникать в информацию на страницах считается чуть ли не утраченным.

Неудивительно, что сейчас так популярно скорочтение. “Я прочёл Х книг за год!” — знакомая фраза? Логично, что такой подход считается крутым, ведь в нас с детства вбивали, что читать нужно больше. Но так ли это на самом деле?

⭐️ Читать — легко

Сам по себе процесс чтения — штука довольно простая. Мы складываем буквы в слоги, слоги в слова, слова в предложения и так далее, а затем интерпретируем их у себя в голове. Иногда процесс становится чуть сложнее: у автора может быть тяжёлый слог или в тексте встречается много терминов, но суть не меняется.

При этом мало кто задаётся вопросом: а какая задача сейчас передо мной стоит? Зачем я читаю эту книгу? За все годы своего формального обучения я ни разу не слышал подобных вопросов. А чтение книги в рамках школы и универа осуществлялось в рамках задачи “сдать и забыть”.

Поэтому чаще всего книги (да и не только они) читаются бездумно, без глубокого анализа. В лучшем случае по книге составляется конспект, который лишь дублирует прочитанное. Это не плохо — просто нас так научили.

⭐️ Думать — больно

Идея рефлексировать прочитанное не нова. Просто в современном мире под бешеным потоком информации все на неё дружно забили. “Читать быстрее” подкупает своей простотой и измеримостью. А какой линейкой измерять “качество” чтения?

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

Проблема в том, что “думать” противоречит задаче “читать больше”. Думанье тратит время и силы, вызывает головную боль и вообще может не получаться. Куда проще вернуться к старой модели поведения и прочитать ещё пяток книг.

⭐️ В размышлениях весь смысл

Подход “читать больше” фактически запинывает человека в то, чтобы поглощать информацию, не особенно её обдумывая. Тем самым читатель лишается возможности по-настоящему что-то изменить для себя в лучшую сторону.

В прошлом посте я писал о том, что в процессе размышления над идеей я пишу много личных мыслей. В частности, я смотрю, как идея могла бы пригодиться мне в прошлом или в потенциальной ситуации в будущем. Такой анализ даёт мне невероятную вещь — альтернативные варианты поведения.

Если я подумал над какой-то идеей, оценил её значимость для себя и нашёл случаи, когда она могла бы быть полезна, то я создал у себя в голове несколько “крючков”, которые могут стриггерить мысли об этой идее в жизни. В частности, для этого я и использую ситуации из прошлого или моделирую будущее: как оказалось, такие крючки у меня работают лучше всего.

Получается, что в процессе размышлений над идеей я закладываю себе в голову альтернативные варианты поведения в будущем. В жизни это выглядит так: в какой-то ситуации я вспоминаю свою заметку и применяю ту идею, которая в ней описана.

Так у меня происходят изменения поведения. Заметка закладывает альтернативные модели мне в голову, а вспоминание и применение превращает идею в новое поведение. Бонусом применение часто вызывает новое понимание, и я иду писать новую заметку. Получается бесконечный цикл обучения.

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

В следующем посте поговорим об опасности наивных теоретиков и о переводе знаний в умения.

// А пока поставьте 💛, если тема заходит. И конечно я буду рад вашему мнению в комментариях!

Сколько книжек по боксу нужно прочитать, чтобы побить Майка Тайсона?

В прошлом посте я рассуждал о том, что процесс потребления информации лёгкий и приятный, а процесс перевода этой информации в личное знание — медленный и болезненный.

Мало получить информацию из какого-либо источника — её ещё нужно «переварить», найти ей место в своей личной системе знаний, опыта и убеждений. Правильное «переваривание» также закладывает возможность применения этого знания в будущем. Но на этом процесс работы над идеей только начинается.

⭐️ Опасность теоретиков

Прежде чем мы пойдём дальше, мне хотелось бы рассмотреть обратную ситуацию — как выглядит человек, который перенасыщен концептуальным знанием? Вы наверняка встречали такого человека хотя бы раз в своей жизни. Он знает, как всё правильно сделать и организовать, но при этом уклоняется от вопросов вида: «А ты это в жизни пробовал?»

Причина проста: наш мозг очень плохо отделяет фантазии от реальности. В исследования и буддизм мы сейчас погружаться не будем, просто возьмём за опору такой тезис: если я очень хорошо представил себе применение какой-то идеи, то мозг приравнивает это к реальным действиям, потому что плохо различает реальность и фантазии.

Но при этом такие фантазии ≠ реальные действия. Я могу прочитать книжку по боксу и представить, как выигрываю соревнования — но разве это поможет мне хоть сколько-нибудь приблизиться к реальному месту на пьедестале? Конечно же нет. Любопытный читатель для усиления эффекта может провести аналогичные рассуждения с Камасутрой.

Знание — это ещё не навык. И люди, которые приравнивают эти понятия, могут быть по-настоящему опасны для себя и окружающих. Их святая уверенность в своей правоте может закончиться катастрофой. В мягкой форме я это многократно наблюдал у различных agile-коучей (no offence, ребята, просто пример): они знают, как должно быть «правильно», но реальность раз за разом ломает их гениальные идеи.

⭐️ Проверка реальностью

Так вот, сама по себе идея автора ничего не значит. И даже переработанная мною она может быть неправильной, ошибочной. Есть лишь один способ проверки — это проверка в реальном деле. Нужно взять свою идею, применить её в реальности и посмотреть, достаточно ли она прочна для успешного функционирования в окружающем мире.

Этого этапа теоретики обычно избегают и боятся. Реальный мир суров, и многие идеи просто не выдерживают его проверок. Для теоретика крушение его фантазий и гениальных идей смерти подобно, поэтому он обычно избегает подобных ситуаций и продолжает толкать вдохновенные речи (или писать мечтательные посты).

Но для практиков типа меня проверка идеи на деле — это самая интересная часть! Проверяя перспективные идеи, я получаю возможность найти их слабые места, доработать и встроить в свою систему жизни в этом мире. А иногда я не знаю, как такую идею улучшить, но она мне нравится — и я иду исследовать дальше. Так цикл обучения выходит на новый виток.

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

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

// Я учусь делать свои посты более компактными, но пока сложно. Ставь 💛, если нравится такой формат и буду рад обратной связи!

Про разработку Frontend и любовь к нему

Я недавно снова полез писать фронт после долгого перерыва и удивился, насколько там всё стало сложнее и интереснее. Настолько сложно, что пришлось обратиться к знакомым frontend-разработчикам и попросить их профессионального мнения.

Сегодня у меня в рубрике #добрый_пиар — Саша Белькевич, автор канала "Frontend вдохновляет". Саша профессионально занимается frontend-разработкой, а в своих ТГ- и YouTube-каналах делится всякими интересными фишками из мира фронта, а также личным взглядом на разработку клиентских приложений и юзабилити.

Вот несколько постов, которые мне особенно приглянулись:
➡ Про NDA — с этой штукой важно разобраться, чтобы лучше понимать риски бизнеса.
➡ Про важность pet-проектов — пост, с которым я согласен на 100% (я сам топлю за пет-проекты).
➡ Про реальный опыт в стартапах — очень перекликается с моим опытом работы в хаосе :)
➡ Про честность на собеседованиях — о наболевшей в последнее время теме накрутки опыта.

Я сам люблю читать Сашины посты, хоть и не занимаюсь фронтом профессионально. Поэтому рекомендую и вам подписаться. И не стесняйтесь задавать вопросы: Саша с удовольствием общается в комментариях с подписчиками.

Дэниел Пинк «Драйв. Что на самом деле нас мотивирует»

Тема мотивации меня внезапно увлекла. Книга Сьюзен Фаулер «Почему они не работают», о которой я писал на прошлой неделе, лишь раззадорила мой интерес. Мотивация стала понятнее, но вопросы ещё оставались (и много), поэтому я продолжил копать.

Книгу Дэниела Пинка «Драйв» я уже читал несколько лет назад. Тогда она мне показалась не очень примечательной – много воды, много “волшебных таблеток”, крайне много отсылок к Канеману и Чиксентмихайи. Однако я победил свой скепсис, напомнив себе о том, что теперь у меня есть новые навыки исследования, и принялся за чтение.

⭐️ О чём книга

Книга посвящена двум основным темам. Первая – несостоятельность метода “кнута и пряника” (автор называет его Мотивация 2.0) в современных реалиях. Вторая тема – Мотивация 3.0 (термин, который придумал сам автор), в рамках которой рассказываются факторы мотивации современного человека.

В книге раскрываются следующие темы:
➡️ Как появился метод кнута и пряника?
➡️ Почему метод кнута и пряника не работает в современном мире?
➡️ К чему приводит неуместное применение кнута и пряника?
➡️ Что такое внутренняя и внешняя мотивация?
➡️ Какие факторы способствуют укреплению и поддержанию внутренней мотивации?
➡️ И, конечно, Мотивация 3.0

⭐️ 3 идеи из книги

🟡Зарплата является не мотивирующим, а базовым фактором.
Люди должны зарабатывать себе на жизнь, и достойная, справедливая оплата их труда является основой для развития мотивации, а не самой мотивацией.

🟡Чем сильнее стимул – тем хуже может оказаться конечный результат по причине сверхзацикленности. Человек настолько сильно увлекается вознаграждением, что перестаёт думать о качестве своей работы и конечном результате, всеми силами стремясь получить награду.

🟡Возможность выбора задач – важный компонент внутренней мотивации.
Люди ценят свободу, поэтому возможность выбирать, чем именно заняться на работе, может мотивировать лучше денег и похвал.

⭐️ Мои впечатления

Прочитав книгу Пинка, я полез гуглить год издания и обнаружил, что «Почему они не работают» Сьюзен Фаулер вышла на 7 лет позже. Фаулер многое позаимствовала из книги Пинка, в том числе взяла его “Мотивацию 3.0” и немного докрутила под себя.

Конечно, читать «Драйв» после «Почему они не работают» – так себе идея. Сейчас я понимаю, что стоило делать это в обратном порядке. Пинк сформулировал отличную, стройную теорию новой мотивации, а Фаулер хорошо расширила и дополнила её мотивационными состояниями и факторами саморегуляции.

Я по-прежнему вижу, что Пинк многое взял из других книг. Но сделано это уместно и гармонично вписывается в общую структуру его идей. Однако раздел про мотивирование сотрудников мне показался откровенно слабым. Возможно, это связано с тем, что сам Пинк толком никогда никем не руководил (что, впрочем, не умаляет ценности его идей).

В общем, для прокачки своего уровня работы с мотивацией рекомендую прочитать «Драйв» для понимания Мотивации 3.0 и дополнить его «Почему они не работают» – для понимания мотивационных состояний, техник саморегуляции и способов применения этих новых подходов к мотивации.

А книги по мотивации у нас ещё не закончились – оставайтесь на связи.

Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

Как тестировать идеи и при чём тут Голлум

В предыдущем посте мы выяснили, что чтение книжек по боксу не поможет навалять Майку Тайсону, хоть он уже и старый дед.

Мало получить идею из книги — даже «переварить» и отрефлексировать её недостаточно. Несмотря на весь объём работы, идея на этом этапе всё ещё остаётся идеей. Пришла пора превратиться в практика и столкнуть идею с реальностью, чтобы посмотреть, насколько она жизнеспособна.

Теоретик носится со своими идеями, как Голлум с небезызвестным кольцом. Практик же придерживается принципа “выживает сильнейший” и всеми силами стремится сломать идеи об окружающий мир.

⭐️ Как спроектировать тест идеи

Как же хорошо и приятно работать с понятными идеями: сделай А, потом Б, потом В — и готово! Например, книжка по продуктивности говорит: «Записывай все дела в задачник, чтобы не перегружать рабочую память». Всё предельно понятно — начинаем записывать все дела и смотрим, как оно.

Но большинство идей не имеют такой простой и понятной прикладной формы. При этом они всё ещё могут быть крайне ценными. Давайте возьмём более абстрактную идею. Скажем, такую: «Регулярная похвала поддерживает моральный дух и мотивацию членов команды».

Как эту идею протестировать? Можно просто начать рандомно хвалить людей. А сколько раз надо хвалить? А как долго? А как понять, что моральный дух действительно поддерживается? Понимаете теперь, насколько это на самом деле сложно и интересно?

Когда я хочу протестировать что-то в реальности, я задаю себе два простых вопроса:
💛Где и в каком контексте я могу применить эту идею?
💛Какие у меня ожидания от её применения?

Для меня эти вопросы — часть процесса работы над идеей. Я не считаю её проработанной, пока не понимаю, куда её можно приткнуть. А если я не знаю ответа на этот вопрос — зачем мне эта идея сейчас?

⭐️ Удешевляем тестирование

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

Таким тестом стала героиня моей предыдущей серии постов — обратная связь. Пока я работаю с идеей сам, она существует в очень ограниченном контексте. Другие люди могут взглянуть на неё со стороны и заметить различные несостыковки или неучтённые границы применимости (которые, кстати, есть у каждой идеи). Их обратная связь может показать, что над идеей ещё стоит поработать, прежде чем выводить её в реальность.

Для примера вернёмся к идее про похвалу. Допустим, я прихожу к коллеге и возбуждённо рассказываю, как круто хвалить людей. А он мне в ответ: «Ты их всю жизнь палкой гонял за каждый косяк, а теперь резко решил хвалить? Сбрендил, что ли? Команда подумает, что у тебя биполярочка, и разбежится!»

Пример, конечно, выдуманный, но отлично иллюстрирует столкновение идеи с реальностью. Собеседник показывает мои личные границы применимости этой идеи и требует её доработки. Появляется новая идея: «Если ты всю жизнь гонял подчинённых палкой, сначала перестань это делать — и только потом начинай хвалить».

Здесь очень важен момент выбора человека, об которого можно «подумать» свою идею. Безусловно, вы должны ему доверять и ценить его мнение. Но при этом он не должен быть излишне предвзят к вам, и вы — к нему (либо вы должны чётко осознавать эту предвзятость). Человек должен не бояться, как говорит мой руководитель, «накидать вам хуёв в панамку». Иначе вся его обратная связь не будет иметь никакой ценности.

Задача исследования идеи — получить обратную связь от мира. Конечно, лучшим тестом будет проверка в деле. Но это не всегда целесообразно и возможно, поэтому иногда стоит для начала «подумать» свою прекрасную идею об других людей.

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

// И как всегда прошу ваших реакций 💛 под постом. Они греют мне эго душу и подталкивают писать дальше

Сколько нужно знать, чтобы делать?

В предыдущем посте мы остановились на том, что за новые идеи не нужно держаться как за святыню, а стоит попытаться «обстучать» их об реальный мир. Делать это можно разными способами. Лучше всего, конечно, взять и попробовать, но даже «обстучать» идею об другого человека — уже достаточно хорошо.

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

Но я стремлюсь не просто накапливать теорию, а учиться с пользой для своей жизни. Поэтому я постоянно задаюсь вопросами: «Зачем мне это знать?» и «Как я это могу применить?»

⭐️ Теория без практики мертва, практика без теории слепа

Авторство этой цитаты приписывают Суворову, но для нас это не так значимо.

Мы уже рассмотрели крайность накопления теоретических знаний без их практического применения (ссылка на пост, если хотите освежить память). Давайте теперь прогуляемся в другую крайность — где человек считает, что вся теория — это ерунда для академиков, книжки пишут одни зануды для других зануд, а настоящий учёный должен работать лишь в полях.

Остановитесь на секунду и подумайте: какое будущее ждёт такого человека? Какое будущее ждёт джуна, который всему учится лишь на своём эмпирическом опыте? А электрика?

Последствия недостаточных теоретических знаний могут быть катастрофическими. Джун в лучшем случае будет долго и упорно изобретать велосипеды, а в худшем — наговнокодит так, что проще будет всё переписать. С электриком всё будет зависеть от того, в какие дебри электричества он залезет. Веер вероятностей расходится от возмущённого «Ай!» до летального исхода.

⭐️ Сколько вешать в граммах?

Получается вот что: совсем без теории — плохо, совсем без практики — бессмысленно. А где же золотая середина?

Опытным путём я пришёл к следующему умозаключению: it depends. К сожалению, нельзя для любой ситуации, любого навыка, любой идеи найти идеальный баланс теории и практики. Мы, люди, несовершенны, и поэтому перекосы являются частью нормы.

В большинстве случаев я пользуюсь принципом: «знать нужно достаточно для того, чтобы начать действовать». Я не пытаюсь изучить всё-всё-вообще-всё перед экспериментированием с идеей. Но я стараюсь убедиться, что понял её в достаточной мере для активных действий.

К примеру, я могу отложить книгу прямо в процессе чтения и сразу что-то сделать с той информацией, которую получил. Скажем, внести какое-то изменение в свой календарь, написать кому-то сообщение или попытаться объяснить жене свою «очередную гениальную мысль». Я не пытаюсь накопить как можно больше информации, а начинаю с ней что-то делать.

При этом я стараюсь делать эксперименты простыми, небольшими, короткими. Моя задача — не убедиться в непоколебимости идеи, а получить первую обратную связь от мира и двигаться дальше по своему пути обучения, сохраняя тонкий баланс между теорией и практикой.

// Ставь 💛, если тоже пытаешься поймать эту неуловимую золотую середину между теорией и практикой

Михай Чиксентмихайи "Поток. Психология оптимального переживания"

Вчерашний праздник я решил почтить молчанием. Поэтому пост переехал на субботу.

Одной из точек пересечения книг “Драйв” и “Почему они не работают?” оказалась концепция потока. Обе книги характеризуют поток как одно из наиболее продуктивных и высокомотивированных состояний.

Конечно же, мне стало интересно разобраться в потоке из первоисточника, потому что пересказы Пинка и Фаулер довольно скудные и вряд ли отображали картину целиком. Поэтому я решил завершить своё небольшое исследование темы мотивации книгой Михая Чиксентмихайи “Поток”.

⭐️ О чём книга

Книга полностью посвящена состоянию потока. Однако при этом Чиксентмихайи раскрывает тему довольно широко, рассматривая в том числе роль потока и психической саморегуляции в современном мире.

В книге раскрываются следующие темы:
➡️ Как жить более качественно и счастливо?
➡️ Как взаимосвязь личности и внимания влияет на человека?
➡️ Что такое состояние потока и как в нём оказаться?
➡️ Чем полезно состояние потока для психики?
➡️ Как получать удовольствие от всего, что делаешь?

⭐️ 3 идеи из книги

🟡Человек может сделать себя счастливым или несчастным вне зависимости от того, что происходит в окружающем мире. Всё зависит от восприятия происходящих событий, направленности внимания и развитости внутренней саморегуляции.

🟡Качество жизни можно улучшить с помощью двух стратегий: подстраивая внешние обстоятельства под свои цели и подстраивая свои цели под внешние обстоятельства. Эффективнее всего будет использовать обе в разных пропорциях.

🟡Настоящее удовольствие мы получаем от деятельности, которая требует от нас вложений сил и концентрации внимания. При этом деятельность должна быть достаточно сложной, чтобы пришлось напрягаться, но преодолимой. Тогда мы полностью вовлекаемся в этой деятельности и погружаемся в неё с головой, входя в состояние потока.

⭐️ Мои впечатления

Чиксентмихайи писал в то время, когда книги больше 200 страниц считались чем-то естественным. Поэтому не постеснялся и написал очень обстоятельный труд о счастье, состоянии потока и роли сосредоточенного труда во всём этом.

Книга – трудная. Сама концепция потока достаточно проста, понятна и узнаваема. Но Чиксентмихайи пошёл гораздо дальше темы “как получать удовольствие от работы”. Они поднимает такие важные темы, как счастье, получение удовольствия от жизни в целом и своей деятельности в частности, развитие личности через труд и многое другое.

“Поток” содержит много мудрых мыслей. Настолько много, что я до сих пор не успел до конца разгрести все заметки, собранные в процессе чтения. Но эта книга, на мой взгляд, стоит потраченных усилий. Она помогает увидеть смысл и радость в своей повседневной деятельности, а это положительно сказывается на личной мотивации.

Настоятельно рекомендую!

Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

Зачем так заморачиваться с обучением?

Знать нужно ровно столько, чтобы действовать со знанием дела. Этой мысли был посвящён мой предыдущий пост. Однако есть ещё одна мысль, без которой мой цикл будет неполным.

Всё, о чём я писал в предыдущих постах (эксперименты, осмысленное получение теории, рефлексия и так далее), — это лишь инструменты. Они просто делают свою работу в умелых руках. А вот зачем эти руки взялись за инструменты — это вопрос, на который каждому из нас нужно ответить самостоятельно.

⭐️ Мне это зачем?

Помните один из первых инструментов, который я привёл? Вопрос к книге: «Зачем я вообще её в руки взял?» Этот простой вопрос очень помогает повысить осмысленность чтения.

Но этот же вопрос применим и в более глобальном смысле — к самообразованию. В своё время я пошёл учиться читать книги, потому что хотел лучше понимать и применять прочитанное. Мой ответ на вопрос «Зачем?» звучал как: «Я хочу, чтобы моё время на чтение тратилось с пользой, а не просто на поглощение буковок с бумаги».

Точно так же и в самообразовании рано или поздно придётся прийти к вопросу «Зачем?» более высокого порядка. Любой процесс в жизни должен быть осмысленным и целенаправленным, иначе он просто не приживётся. Вспомните любую свою неудачную попытку «начать бегать по утрам» — самообразование подвержено тем же рискам.

⭐️ Ответ всегда разный

У меня нет готового ответа на вопрос «Зачем так заморачиваться с самообразованием?» Но я точно знаю, что невозможно найти один ответ на этот вопрос и остаться с ним на всю жизнь.

Пока я живу — мои цели изменяются и прогрессируют. Когда-то я просто очень любил читать и ощутил сильную потребность лучше осознавать прочитанное. Затем моя потребность трансформировалась в «Хочу рассуждать о прочитанном и эффективно применять новые знания в жизни». Сейчас же у меня новый виток, который я бы охарактеризовал как: «Хочу получать ответы на свои вопросы и менять свою жизнь к лучшему через чужой опыт».

Но в одном я уверен точно: главное — это получать радость от самого процесса. Например, мне очень нравится писать посты и заметки. Я получаю искреннее удовольствие от наблюдения за процессом перекладывания мыслей в печатную форму. И такое же удовольствие я получаю от самого процесса анализа и рассуждения.

Получение радости от самого процесса «подсаживает» на процесс. Как привычное к физкультуре тело требует пойти в зал и позаниматься, так и привычный к размышлениям ум требует подумать о чём-то интересном.

⭐️ Делиться с миром своими идеями

Думать о чём-то — интересно, но вдвойне интересно принести свою идею в реальный мир и «подумать» её совместно с другими людьми. Процесс размышления в какой-то момент начинает подталкивать к тому, чтобы показать свои мысли хоть кому-то. Так появляются каналы, статьи, доклады, видосики и прочие радости качественного контента.

Так когда-то начинал писать и я. Меня настолько увлекали некоторые идеи, что было просто невозможно удержать их в себе. И я продолжаю сохранять этот подход. Каждый мой пост, каждый доклад — это идея, которой мне хочется поделиться с миром. И этих идей у меня настолько много, что я уже не знаю, куда их девать :)

Каждому из нас придётся самостоятельно найти ответы на вопросы о целях и методах самообразования. Этому не учат в школе, да и вообще мало где учат. Лично я просто получаю радость от процесса размышлений и изменений в своей жизни. Но одно я знаю точно: если не заниматься своим образованием, то его заменит потребление контента без какой-либо смысловой нагрузки.

На этом я заканчиваю цикл постов про самообучение. Получилось много хороших постов — на днях соберу их в один материал как цикл про обратную связь. Дальше мы немного отдохнём от «софтовых» тем и поговорим о чём-то более тимлидско-прикладном.

// Прошу обратной связи в комментариях: как вам формат циклов и сам цикл? Что нравится и не нравится? Удалось ли что-то попробовать в жизни? И, конечно, ставьте 💛 во имя радости от самообразования.

Как оптимизация может ухудшить поставку

Когда инженер только становится тимлидом, у него есть чёткая цель: заставить всё вокруг работать максимально эффективно. Чаще всего это происходит из-за желания закрепиться в новой роли, но и технический бэкграунд даёт о себе знать — привычка всё оптимизировать никуда не делась.

Поэтому загружать команду на 100% кажется максимально эффективным и правильным решением. Если мы за это платим – пусть работает. Желание всё оптимизировать кажется экономически оправданным. В результате юный тимлид частенько начинает заниматься локальными оптимизациями, забывая о картине в целом.

⭐️ К чему приводит локальная загрузка

Но производственный процесс — не инженерная система. Локальная оптимизация в коде может привести только к ускорению его выполнения. А вот оптимизация какой-либо точки производственного процесса может, наоборот, ухудшить общую производительность команды.

Так происходит потому, что в реальных системах есть так называемые «бутылочные горлышки» — узкие места, которые по сути определяют пропускную способность всей системы. Любые локальные оптимизации в других местах приведут лишь к тому, что перед бутылочным горлышком начнёт скапливаться всё больше и больше работы, вызывая снижение производительности всей системы.

⭐️ Что будет, если загрузить команду на 100%

Термин «бутылочное горлышко» ввёл Элияху Голдратт в своей теории ограничений. Впервые его можно встретить в книге «Цель» (см. мой обзор), которую я настоятельно рекомендую всем тимлидам.

Расскажу случай из своей практики. В одной из команд мы в какой-то момент озаботились наращиванием поставки. Естественно, первая же мысль была ошибочной — «нам нужно оптимизировать время работы программистов». Путём различных манипуляций с процессами мы снизили затраты времени разработчиков, в результате чего они действительно начали закрывать больше задач. Круто же?

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

Оказалось, что бутылочным горлышком нашей системы были вовсе не программисты, а QA. Их было меньше, система была сложной, и ребята просто не успевали тестировать всё то, что к ним поступало. А когда мы оптимизировали процесс разработки и стали закрывать больше задач, QA совсем приуныли. Из-за роста нагрузки и обязательств они начали работать в спешке и менее качественно, больше уставать и пропускать баги. В результате мы получили снижение и поставки команды, и качества системы.

⭐️ Производительность системы определяется бутылочным горлышком

В незавершённом продукте нет ценности. Код программиста бесполезен до тех пор, пока не окажется в проде и не начнёт приносить пользу клиентам. Но до этого он должен быть отревьюен, протестирован и, собственно, выкачан.

Если бутылочное горлышко системы находится не в скорости разработки, нет смысла её оптимизировать. Разработчики просто перегрузят узкое место и будут ворчать, что постоянно приходится решать конфликты в ветках.

Парадоксально, но в нашей ситуации первым правильным решением было перестать копать. И да, это означало уменьшение количества производимого кода. Поскольку ограничение системы заключалось не в скорости разработки, мы отказались от идеи «запихнуть в работу как можно больше фич» и стали отталкиваться от загрузки QA.

От этого решения выиграли все. QA выдохнули и смогли спокойно делать свою работу. У разработчиков появилось время на технический долг и изучение новых областей (например, фронты начали периодически брать задачи по бэку и наоборот). Система стабилизировалась, и всё вернулось на круги своя.

Однако изначальную проблему мы не решили. Скорость поставки осталась прежней. Но об этом я расскажу в следующем посте. :)

// Если сталкивались с ситуациями ухудшения производительности из-за локальных оптимизаций — пишите в комментах. И не забывайте про 💛!

Патрик Ленсиони «5 пороков команды»

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

Первый раз «5 пороков команды» я читал где-то пять лет назад. Я тогда уже больше года управлял своей первой командой и в целом неплохо справлялся. Книга мне понравилась, но не зажгла, оставив послевкусие типа: «С тезисами согласен, звучит хорошо».

Но недавно, на обучении для руководителей, я вновь коснулся модели Ленсиони. И на этот раз она показалась мне гораздо более глубокой, чем на первый взгляд. Поэтому я взял первоисточник и приступил к чтению.

⭐️ О чём книга

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

В книге раскрываются следующие темы:
➡️ Как каждый из пороков негативно влияет на команду?
➡️ Как исправлять эти пороки?
➡️ Какие упражнения могут сблизить и сплотить команду?

⭐️ 3 идеи из книги

🟡Члены команды должны рассматривать коллективные результаты как счёт в футбольном матче. В хорошей команде выигрывают или проигрывают все одновременно. Если в команде возможны ситуации, где кто-то выигрывает, а другие нет, то это не команда, а группа.

🟡Не соглашайся, но выполняй. Иногда обсуждения проблем и попытки прийти к единому мнению могут парализовать работу команды. В таких случаях самая эффективная стратегия — не согласиться с решением, но подчиниться ему, будто согласен. Решения команды должны быть выше конкретного человека.

🟡Ссора и спор — это две разные вещи. Спор (конструктивный) является нормальной частью работы и направлен на то, чтобы улучшить конечный результат команды. Ссора же — это конфликт, который вредит доверию и командному духу, никак не помогая двигаться к цели.

⭐️ Мои впечатления

В этот раз книга Ленсиони произвела на меня гораздо большее впечатление. Я думаю, что сказывается прожитый опыт — многие ситуации, которые автор описывает в книге, были мне уже знакомы (местами прямо флешбеки возникали).

Модель Ленсиони неидеальна, как и любая другая модель. Но это не лишает её полезности. Особенно мне понравилось рассматривать, как пороки взаимосвязаны и один порождает другой. Например, из недоверия вытекает безответственность и нетребовательность, которые, в свою очередь, порождают уход от конфликта и безразличие к результату.

Конечно, связи там чуть сложнее, но ключевая мысль — любой порок команды создаёт усиливающую петлю обратной связи для других пороков. Фактически, можно получить каскадный эффект: возникновение одного порока создаёт второй, который создаёт третий, который…

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

Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

Цикл постов про самообучение

Формат обучения в школе и институте — это верный способ привить человеку отвращение к самой мысли о том, чтобы учиться чему-то новому. Я довольно долго искал свои принципы эффективного самообразования, потому что в IT невозможно бесконечно ехать на старых знаниях.

Очередной мой цикл постов был посвящён тем принципам обучения и самообразования, которыми я руководствуюсь каждый день. Поэтому если что-то пропустили — самое время наверстать. И для удобства я собрал все ссылки по порядку в один пост. Но читать посты можно в любом порядке — они самодостаточны.

⭐️ Посты

➡️ Зачем мне это знать? – о волшебном вопросе, который значительно бустит эффективность обучения.
➡️ Хочешь научиться? Пиши. – о подходе, который позволяет осмыслять информацию, а не просто потреблять её.
➡️ Читать легко, а думать — больно — о том, что наиболее ценно в процессе самообразования.
➡️ Сколько книжек по боксу нужно прочитать, чтобы побить Майка Тайсона? – о ценности тестирования новых идей на практике.
➡️ Как тестировать идеи и при чём тут Голлум – о процессе тестирования новых идей.
➡️ Сколько нужно знать, чтобы делать? – о том, в какой момент нужно переходить от теории к практике.
➡️ Зачем так заморачиваться с обучением? – личная рефлексия о том, чего ради я так усложняю себе жизнь.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

Как я искал, что тормозит поставку команды

Итак, локальная оптимизация привела нас в парадоксальную ситуацию: программисты стали делать больше, а поставка команды снизилась. Чаще всего это случается, когда изменения не учитывают бутылочное горлышко системы. Но мы не сразу поняли, в чём проблема.

В предыдущем посте я рассказал о том, что такое бутылочные горлышки и как производительность моей команды ухудшилась из-за увеличения скорости разработки. В конечном счёте нам пришлось откатить изменения и снизить количество задач, производимых программистами. Бутылочным горлышком оказался ресурс тестировщиков, а не скорость написания кода.

⭐️ С чего начать поиск бутылочных горлышек

Я забежал вперёд и раскрыл спойлер — что оказалось бутылочным горлышком в нашем случае. Но ведь это не вся история. Нам пришлось потратить время и усилия на поиск узкого места.

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

Для начала я пошёл и покопался, что может указывать на бутылочное горлышко в системе. В книге «Цель» Голдратт приводит следующий признак: перед бутылочным горлышком всегда скапливается работа. Выглядеть это может по-разному: какой-то этап процесса оказывается переполнен задачами или же задачи на нём выполняются очень долго. Так или иначе, при визуализации процесса на той же канбан-доске бутылочное горлышко обычно легко увидеть.

⭐️ Действительно ли это бутылочное горлышко?

В нашем случае всё оказалось просто до боли: на этапе Ready for QA было огромное количество задач, которое в основном увеличивалось. В среднем там висело по 10 задач с периодическими увеличениями до 15.

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

➡️ Посмотрели на некотором периоде времени (несколько недель), как у нас меняется состояние колонки Ready for QA и cycle time для этого статуса. Мы увидели, что cycle time самый большой на всём жизненном цикле задачи, а задач в Ready for QA приходит больше, чем уходит.

➡️ Провели ретроспективы, посвящённые трудностям в поставке за последние несколько недель. Тестировщики жаловались на нагрузку, программисты жаловались, что задачи висят в тестировании и их не получается смержить, из-за чего приходится править конфликты.

➡️ На дейликах часто звучали фразы вида: «Протестируйте, пожалуйста, эту задачу в приоритете, она мне нужна для следующей задачи».Как видите, сразу несколько признаков указывали на то, что бутылочным горлышком является тестирование. Поэтому наша локальная оптимизация скорости разработки сделала всей системе только хуже — тестирование просто не могло переварить увеличившийся поток задач.

⭐️ Главная ошибка при поиске бутылочных горлышек

На мой взгляд, главная ошибка — принимать первую же гипотезу как истину и бросаться её чинить.

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

В некоторых процессах бывают статусы с долгим cycle time, но это не делает их бутылочным горлышком. Например, одна из моих команд работала по Scrum, и самый долгий cycle time был у статуса Ready for release. Делает ли это частоту релизов бутылочным горлышком команды? Конечно, нет. Поэтому важно внимательно и всесторонне изучить свои гипотезы, прежде чем что-либо менять.

Итак, нам удалось найти и провалидировать бутылочное горлышко команды. Теперь мы были готовы к тому, чтобы ускорять поставку. Об этом — в следующем посте.

// Сталкивались ли вы с бутылочными горлышками в разработке? Делитесь в комментариях, интересен чужой опыт. А также ставьте 💛, если тема заходит.

Как ускорить поставку без дополнительных людей

Итак, моей команде потребовалось ускорить поставку. Увеличив производительность разработки, мы чуть не довели своих QA до выгорания. Поэтому мы сделали шаг назад и начали анализировать весь процесс поставки, чтобы найти затык.

Предыдущий пост закончился на том, что мы нашли “бутылочное горлышко” своего процесса поставки. Им оказалось тестирование — команда не могла поставлять больше, чем QA в состоянии переварить. Мы тщательно проверили эту гипотезу и убедились, что она верна.

Конечно же, первым делом я запросил дополнительных тестировщиков в команду. Начальство ответило в стиле ДимАнатолича: “Денег нет, но вы там держитесь. И поставку ускорьте.” Что поделать — пришлось выкручиваться.

⭐️ Выкручиваемся как можем

Первым делом я вернулся к книге “Цель” Голдратта, которая и дала мне понимание бутылочных горлышек. Вопрос был следующий: как ускоряться без дополнительных ресурсов? И я нашёл ответ — строить систему вокруг бутылочного горлышка, подчинить ему весь производственный процесс. Для этого можно сделать следующие вещи:

➡️ Перестать перегружать бутылочное горлышко работой (всё равно больше не сделает).
➡️ Ускорить прохождение работы через бутылочное горлышко (повысить КПД).
➡️ Убрать лишнюю работу с бутылочного горлышка (вдруг оно делает что-то бесполезное).
➡️ Увеличить ресурсы бутылочного горлышка (то, с чего я пытался начать).

В нашем случае подчинение поставки бутылочному горлышку значило, что тестирование становится центральным компонентом системы. И вся система должна быть построена вокруг него. Увеличение ресурсов нам было недоступно (по крайней мере сейчас), поэтому мы стали применять остальные пункты выше.

⭐️ Первые шаги

Первым делом мы перестали перегружать тестировщиков фичами. К счастью, мне даже не пришлось продавать это стейкхолдерам — их интересовала только конечная поставка по результатам спринта, а её объём определялся ресурсом тестирования. Ребята выдохнули, и мы стали думать над фундаментальным вопросом: как нам ускорить тестирование за счёт более свободных ресурсов разработки?

У нас уже была автоматизация, но самих тестов было не слишком много. У тестировщиков постоянно не хватало на них времени. Параллельно мы примерно прикинули, сколько задач возвращается из тестирования на доработку, и поняли, что повышение качества входа может сильно нас ускорить.

Поэтому мы решили вложиться одновременно в автоматизацию и улучшение требований. Список идей выглядел примерно так:

➡️ Изменили DoR: задача считается готовой к разработке, только если в ней описаны тест-кейсы. Для описания тест-кейсов подключается тестирование.
➡️ Изменили DoD: задача считается выполненной, только если разработчик написал автотесты, покрывающие описанные в требованиях кейсы.
➡️ Завели задачи на написание автотестов. Эти задачи выполнялись как техдолг.

Эти перемены учитывали все заинтересованные стороны. Гипотетический путь выглядел примерно так:

➡️ Описанные тест-кейсы упрощали работу программиста, которому не приходилось придумывать их на ходу.
➡️ Написание автотестов снижало количество багов на входе в тестирование.
➡️ Поскольку автотесты сохраняются, количество багов в целом должно уменьшаться.
➡️ Ресурс тестировщиков тратится на написание тест-кейсов, но это окупается за счёт ускорения тестирования.
➡️ Написание автотестов программистами постепенно повысит общее покрытие приложения и дополнительно снизит количество багов.

⭐️ Что получилось в итоге

Гипотезы сработали отлично. Пару спринтов мы привыкали, но обратная связь от ребят была потрясающей. Программисты радовались, что задачи реже возвращаются на доработку, тестировщики радовались, что в задачах меньше багов и растёт покрытие тестами, я радовался ускорению поставки. При этом спокойны были и стейкхолдеры: все при деле, фичи делаются — всё прекрасно.

Мы добились ускорения поставки на 30%, и этот показатель продолжал расти. Бонусом мы получили постепенное снижение багов на проде практически до нуля. Но впереди были новые челленджи, о которых я расскажу в следующем посте :)

// Ставь 💛 в поддержку своих тестировщиков!

Тейва Харшани «100 ошибок Go и как их избежать»

Давайте немного отдохнём от менеджмента, софтов и вот этого вот всего — с хардкорным кодом! Как-никак, я до сих пор каждый день пишу код. Последние полтора года я программирую на Golang, и мне очень нравится этот язык.

Конечно же, базовые книжки я прочитал ещё на стадии изучения языка. Но с тех пор как-то руки не доходили почитать что-то конкретно про Go — я больше читал про архитектуру, распределённые системы и базы данных. И тут произошло неожиданно приятное событие: ко мне пришли ребята из издательского дома «Питер» и предложили сделать обзор на обновлённое издание книги «100 ошибок Go».

Конечно, я не мог отказаться от обзора очередной интересной книги. Тем более что «100 ошибок Go» — книга не для новичков. Но обо всём по порядку.

⭐️ О чём книга

Как следует из названия, книга посвящена разбору 100 примеров ошибок и неэффективной работы в языке Golang. Глобально ошибки разбиты на смысловые разделы: организация кода, обработка ошибок, конкурентность и так далее.

Что можно узнать из книги:
➡️ Как грамотно использовать интерфейсы
➡️ Как выстрелить себе в ногу, перепутав длину и ёмкость среза
➡️ Чем всё-таки отличается конкурентность от параллелизма
➡️ Как создать race condition с помощью оператора append
➡️ И многое другое :)

⭐️ 3 идеи из книги

В Go интерфейс создаётся на уровне клиента. Это непривычно для программистов типа меня, которые обычно определяют интерфейс как абстракцию доступа. Проблема в том, что интерфейсы в Go реализуются неявно, и поэтому код не должен навязывать абстракцию своим клиентам.

Называть пакеты в Go нужно ещё тщательнее, чем переменные. Именование пакета должно быть кратким, ёмким и отражать его возможности. Пакеты похожи на namespace из C#, и одновременно не являются ими. Знали бы вы, сколько мы времени на код-ревью тратим, придумывая нейминг пакетов…

Обработка ошибки должна быть выполнена ровно один раз. Знаю-знаю, всегда есть соблазн сделать что-то и передать ошибку дальше, но это не идиоматично. Если код обработал ошибку, то она не должна «лететь» дальше. Является ли дополнительное логирование обработкой — решайте самостоятельно :)

⭐️ Мои впечатления

Книга мне очень понравилась. Она далеко не такая простая и примитивная, как базовые руководства по Go, и посвящена разным хитрым нюансам языка. Некоторые ошибки довольно очевидны, если внимательно пройти A Tour of Go, но многие другие дали мне достаточно интересной пищи для размышлений.

Большой плюс книги — куча интерактивных примеров кода, которые можно запихнуть в Go Playground и поэкспериментировать (я провёл несколько весьма интересных экспериментов с конкурентностью). При этом код написан очень ясно, лаконично и снабжён комментариями, поэтому читать его легко и приятно.

Отдельный плюс — перевод книги. Он достаточно хорош: в процессе чтения я не спотыкался на словах и не ловил ступор. Технические книги в целом переводить непросто, и переводчики «100 ошибок Go» хорошо справились со своей задачей.

Если вы только начинаете изучать Go — скорее всего, книга вам покажется тяжеловатой. Но более опытным ребятам она, по моему мнению, зайдёт очень хорошо.

Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

Плавающие бутылочные горлышки

В процессе ускорения поставки командой мы обнаружили бутылочное горлышко в тестировании. В предыдущем посте я рассказал, как мы его “расшили”.

Хотелось бы мне сказать, что это был счастливый конец истории и после этого все зажили счастливо, но это было бы не совсем правдой. Мы и правда добились значительного ускорения поставки и снижения количества багов, но появились новые трудности.

⭐️ Прилетело откуда не ждали

Тестирование перестало захлёбываться от нагрузки, разработка пилит тесты — кажется, что всё прекрасно. Но теперь перестал справляться другой элемент системы. Угадаете, какой?

Требования от бизнеса. Ускорение поставки привело к тому, что мы действительно стали делать больше фич. Поэтому нам потребовалось больше задач со стороны бизнеса, к чему наш продакт оказался не готов. Он привык работать в определённом темпе и уделять нам определённый объём внимания (он работал с несколькими командами), поэтому рост производительности создал ему внезапные проблемы. Он за нас был, конечно, рад — но не от всего сердца.

А теперь добавьте к этой возросшей производительности мой принцип “не делать бессмысленную хрень” и поставьте себя на место продакта. Ему понадобилось некоторое время на адаптацию, а мы в это время с довольными лицами переделали кучу техдолга в продукте и докрутили автоматизацию.

⭐️ Главный вывод о бутылочных горлышках

Но сама ситуация меня немного напрягла. Мы исправили проблемы в одном месте — и сразу же получили новые проблемы в другом. Я вернулся к книге “Цель” и стал читать про бутылочные горлышки.

Герои книги тоже неоднократно сталкивались с такой проблемой. Каждый раз, когда они “расшивали” бутылочное горлышко, в системе неизбежно возникало новое. Это приводит нас к следующему выводу:

➡️ Бутылочное горлышко в системе есть всегда.

Вывод настолько очевиден, что аж бесит. И в этом весь Голдратт — он стремился сделать всё настолько очевидным, чтобы мог понять кто угодно.

Из этого вывода следует, что в системе всегда будет ограничивающий элемент. И он может перемещаться по системе. Любые изменения в системе могут вызвать перемещение бутылочного горлышка в другое место. К примеру, “расшивая” одно бутылочное горлышко, мы автоматически создаём другое.

В нашей ситуации мы “расшили” тестирование — и быстро упёрлись в поставку требований от бизнеса. Но другое решение могло создать и другие бутылочные горлышки. Например, если бы мне дали ещё парочку тестировщиков, то бутылочным горлышком могла бы стать разработка — программисты просто не успевали бы делать задачи с той скоростью, с которой их тестируют.

⭐️ Подводя итог

Из всей этой ситуации я вынес для себя несколько уроков:

➡️ Хочешь ускорить систему — найди бутылочное горлышко и строй процессы вокруг него.
➡️ Бутылочное горлышко в системе есть всегда.
➡️ Если бутылочное горлышко перестало быть бутылочным горлышком, значит, оно переместилось в другое место.
➡️ Любые изменения в системе могут вызвать перемещение текущего бутылочного горлышка в новое место.

Это был интересный путь, и он меня многому научил. С тех пор я всегда стараюсь сначала посмотреть на процесс верхнеуровнево, чтобы определить его потенциальные узкие места — чаще всего в них и скрываются точки оптимизации.

На этом я заканчиваю небольшой цикл про бутылочные горлышки. Спасибо за ваши лайки, комментарии и вопросы — они были для меня очень ценны. Мне настолько понравилось писать этот цикл, что аж доклад захотелось сделать (но этому препятствует бутылочное горлышко в виде моего времени).

// И не забывайте нажать волшебный 💛

Почему цели по SMART не работают

Недавно на обучении для руководителей я проходил модуль по постановке целей. Мы разбирали современные фреймворки и методологии и, конечно же, начали с популярного SMART.

Я всегда относился к нему (как и к прочим аббревиатурам) скептически, потому что мнемоники частенько «натягивают сову на глобус» ради красоты (привет, ACID). Но сама идея SMART мне нравилась. И вот на обучении мне порекомендовали статью, которая коротко и ясно объясняет, как именно нужно ставить цели по SMART, чтобы они действительно работали.

⭐️ Интересные идеи

➡️ Основная проблема — зацикливание на том, что хорошая цель должна обладать всеми пятью признаками SMART. Но во многих случаях это просто нереально. Попытки полностью применить SMART приводят либо к очень странным целям, либо к отказу от него.

➡️ Чем выше уровень менеджмента, тем более абстрактными становятся цели и тем сложнее применять SMART. Излишняя конкретизация лишает цель преимуществ абстрактности (этот принцип реализован в OKR — абстрактная цель, конкретные результаты).

➡️ Основная проблема SMART — слишком много разных трактовок. Руководителей сбивает с толку разнородная информация из книг, журналов, статей и так далее. Изначальная идея обычно намного шире, чем альтернативные версии других авторов.

Приятного чтения!

// Ставь 💛, если применяешь SMART в делах
➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog

Радислав Гандапас, «Камасутра для оратора»

В этом году у меня довольно бурно идёт работа с публичными выступлениями: доклады (наконец-то) начали попадать в программы конференций, выступаю я относительно регулярно, плюс наложилось внутреннее обучение по выступлениям. Тема для меня всё-таки относительно новая, поэтому я постоянно ищу любые советы и идеи, как сделать свои доклады лучше.

Конечно же, я не мог пройти мимо книги одного из самых известных спикеров России — Радислава Гандапаса. Этот человек зарабатывает на жизнь публичными выступлениями, поэтому его опыт в этой области я считаю ценным и интересным.

⭐️ О чём книга

Книга посвящена основам публичных выступлений. Автор задаётся целью научить читателя не просто выступать публично, но ещё и получать от этого удовольствие (прекрасный посыл, я считаю).

В книге раскрываются следующие темы:
➡️ Как работать с волнением перед выступлением?
➡️ Как подготовить хорошее выступление?
➡️ Как устанавливать контакт с аудиторией и вовлекать её?
➡️ Как отвечать на каверзные вопросы?

⭐️ 3 идеи из книги

➡️ При анализе прошедшего выступления сосредоточьтесь на том, что у вас получилось хорошо. Поиск ошибок закрепляет мнение о себе как о слабом спикере. Нужно найти свои фирменные сильные стороны и использовать их.

➡️ Блестящий финал получается, если последние фразы выступления перекликаются с первыми и таким образом замыкают круг. Подтверждаю на своём опыте как слушателя: от таких выступлений всегда остаются приятные впечатления.

➡️ Не выступайте перед людьми, а разговаривайте с ними. Скучные лекторы-всезнайки всем ещё в университете оскомину набили.

⭐️ Мои впечатления

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

Но вау-эффекта книга не произвела. Довольно много воды и бахвальства, а вторая половина вообще состоит из многословных вопросов и ответов. Плюс некоторые метафоры Гандапаса показались мне, кхм, излишне яркими.

В целом книжка достойна того, чтобы начинающие спикеры просмотрели её и взяли себе на вооружение некоторые идеи. Да и опытные докладчики могут найти себе парочку нововведений. Но хорошее обучение по публичным выступлениям и большое количество практики она, конечно, не заменит.

Все мои обзоры книг доступны по тегу #обзор_книги@ulshinblog и в этом посте.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog