Как по-настоящему решать проблемы
Есть четыре пути решения проблемы: absolve, resolve, solve, dissolve. Давайте представим себе голодного человека и постараемся решить его проблему с помощью всех четырех инструментов:
- Absolve — сделать вид, что проблемы нет. Самое простое решение: мы взаимодействуем с проблемой путем бездействия! Красиво?
- Resolve — частичное решение: вернуть систему назад к рабочему состоянию. Мы даем человеку рыбу и возвращаем систему к "рабочему" состоянию, человек сыт. Но это не решает проблему целиком!
- Solve — оптимальное решение: не просто вернуть систему в рабочее состояние, но обеспечить стабильность решения: мы выдаем человеку рыбу каждый день. Проблема решена навсегда, ведь человек будет сыт каждый день, верно? Не совсем: это не системное решение, это костыль. Ключевое здесь вот что: мы не поменяли систему, мы просто решили проблему.
- Dissolve — ликвидация проблемы и перестройка системы таким образом, что в будущем она не сможет возникнуть ни при каких условиях: мы даем человеку удочку и учим рыбачить. Проблема решена навсегда.
Абстрактно и непонятно, понимаю. Позвольте мне развернуть идею.
Перенесем пример на ИТ. Представьте: в результате инцидента сервис деградировал на час и компания понесла убыток в десяток миллионов рублей. Инцидент устранили и теперь все работает нормально. Поехали!
I — Absolve
Инцидент устранен, бизнес работает, деньги капают. Ну упали и упали, надо дальше двигаться.
Итог: никаких действий не предприняли. Вопрос времени, когда инцидент повторится.
II — Resolve
Фиксим баг в коде, который привел к падению.
Итог: мы вернули систему в стабильное состояние. Но у нас нет гарантий, что тот же баг не стрельнет, когда разработка поменяет код в следующий раз. Ситуация изменилась не сильно: падение по той же причине очень вероятно.
III — Solve
Фиксим баг и пишем тесты. Кажется, что решение системное. Но нет: вы не застрахованы, что ваш код сломается в другом месте, где тестов нет. Покрыть весь код тестами? Даже если у вас получится, вы потратите тонну времени.
Итог: мы вернули систему в стабильное состояние плюс обеспечили продолжительность нашего решения, больше в этом месте ничего не сломается. А в других — может сломаться.
IV — Dissolve
Проводим post mortem, на котором разбираем причину возникновения бага. Допустим, разработчик не успел дописать тесты, потому что у него слишком много горящих задач.
Тогда настоящее решение — это снизить поток входящих задач, чтобы дать время на написание тестов. Такой подход перестроит процесс разработки и устранит проблему, а не просто решит ее следствие.
Итог: мы вернули систему в стабильное состояние и устранили возможность появления багов из-за спешки разработчиков. Конечно, баги будут и дальше, но вероятность их появления из-за спешки теперь кратно ниже.
Что дальше
Это хорошая система для измерения себя как руководителя. Я думаю, хороший менеджер стремится решать проблемы с помощью dissolve: таким образом, проблем будет возникать все меньше и меньше.
Еще раз подчеркну разницу: solve решает проблему самым оптимальным образом, а dissolve перестраивает систему и устраняет возможность появления проблемы в будущем.
Проблему редко можно решить там, где она проявилась — ищите, где она появилась.
Подумайте, какой из подходов вы или ваша организация используете чаще всего? А какой хотели бы? Поделитесь в комментариях.
Есть четыре пути решения проблемы: absolve, resolve, solve, dissolve. Давайте представим себе голодного человека и постараемся решить его проблему с помощью всех четырех инструментов:
- Absolve — сделать вид, что проблемы нет. Самое простое решение: мы взаимодействуем с проблемой путем бездействия! Красиво?
- Resolve — частичное решение: вернуть систему назад к рабочему состоянию. Мы даем человеку рыбу и возвращаем систему к "рабочему" состоянию, человек сыт. Но это не решает проблему целиком!
- Solve — оптимальное решение: не просто вернуть систему в рабочее состояние, но обеспечить стабильность решения: мы выдаем человеку рыбу каждый день. Проблема решена навсегда, ведь человек будет сыт каждый день, верно? Не совсем: это не системное решение, это костыль. Ключевое здесь вот что: мы не поменяли систему, мы просто решили проблему.
- Dissolve — ликвидация проблемы и перестройка системы таким образом, что в будущем она не сможет возникнуть ни при каких условиях: мы даем человеку удочку и учим рыбачить. Проблема решена навсегда.
Абстрактно и непонятно, понимаю. Позвольте мне развернуть идею.
Перенесем пример на ИТ. Представьте: в результате инцидента сервис деградировал на час и компания понесла убыток в десяток миллионов рублей. Инцидент устранили и теперь все работает нормально. Поехали!
I — Absolve
Инцидент устранен, бизнес работает, деньги капают. Ну упали и упали, надо дальше двигаться.
Итог: никаких действий не предприняли. Вопрос времени, когда инцидент повторится.
II — Resolve
Фиксим баг в коде, который привел к падению.
Итог: мы вернули систему в стабильное состояние. Но у нас нет гарантий, что тот же баг не стрельнет, когда разработка поменяет код в следующий раз. Ситуация изменилась не сильно: падение по той же причине очень вероятно.
III — Solve
Фиксим баг и пишем тесты. Кажется, что решение системное. Но нет: вы не застрахованы, что ваш код сломается в другом месте, где тестов нет. Покрыть весь код тестами? Даже если у вас получится, вы потратите тонну времени.
Итог: мы вернули систему в стабильное состояние плюс обеспечили продолжительность нашего решения, больше в этом месте ничего не сломается. А в других — может сломаться.
IV — Dissolve
Проводим post mortem, на котором разбираем причину возникновения бага. Допустим, разработчик не успел дописать тесты, потому что у него слишком много горящих задач.
Тогда настоящее решение — это снизить поток входящих задач, чтобы дать время на написание тестов. Такой подход перестроит процесс разработки и устранит проблему, а не просто решит ее следствие.
Итог: мы вернули систему в стабильное состояние и устранили возможность появления багов из-за спешки разработчиков. Конечно, баги будут и дальше, но вероятность их появления из-за спешки теперь кратно ниже.
Что дальше
Это хорошая система для измерения себя как руководителя. Я думаю, хороший менеджер стремится решать проблемы с помощью dissolve: таким образом, проблем будет возникать все меньше и меньше.
Еще раз подчеркну разницу: solve решает проблему самым оптимальным образом, а dissolve перестраивает систему и устраняет возможность появления проблемы в будущем.
Проблему редко можно решить там, где она проявилась — ищите, где она появилась.
Подумайте, какой из подходов вы или ваша организация используете чаще всего? А какой хотели бы? Поделитесь в комментариях.
Что происходит, когда ИТ и бизнес не поняли друг друга
1️⃣ Элитные инженеры
Представьте: вы — сотрудник самого секретного ИТ-отдела в стране. Само ваше существование это тайна, а от ваших действий зависят судьбы сотен тысяч людей. Каждый из вас прошел самый тщательный отбор. Вы лучшие инженеры, математики и технари своей страны. Элита из элит, creme de la creme.
Представили? Хорошо, потому что сейчас я расскажу, как даже лучшие их лучших ошибаются, потому что не поняли заказчика.
Итак, именно такими ИТшниками были сотрудники Комнаты №40 — секретного отдела Британии. Комната №40 занималась дешифровкой немецких радио-сообщений во время Первой Мировой. Они перехватывали сообщения, ломали шифр и передавали информацию флотским адмиралам.
В комнате действительно работали лучшие: они выяснили, что кодовое имя адмирала Шеера — DK. Но немцы тоже не были дураками и пытались запутать англичан, поэтому когда адмирал Шеер покидал бухту, кодовое имя DK присваивали маяку в той же бухте.
Система несложная: если адмирал в бухте, DK — его кодовое имя. Если не в бухте, то DK становился кодовым именем маяка.
2️⃣ История одной ошибки
30-го Мая Комната №40 начинает перехватывать тревожные сигналы: 3-ая немецкая эскадра покинула бухту. Это 5 линкоров, бронированных монстров с пушками больше 300мм. Даже один линкор — огромная угроза, а тут пять!
31-го Мая бухту покидает 1-ая и 2-ая эскадры. То есть, все линкоры немецкого флота вышли в море. Очевидно, не просто так погулять вышли. Судя по радиоперехвату, адмирал Шеер тоже вышел в море, потому что кодовое имя DK было переназначено на маяк.
Вывод лишь один: немцы готовятся дать генеральное сражение.
Адмиралтейство посылает запрос в Комнату №40: «Где находится DK?». Конечно, адмиралам было интересно текущее расположение немецкого флота.
Однако, в Комнате №40 сидели люди со строго инженерным мышлением. Кодовое имя DK на момент запроса было прикреплено к маяку, а маяк не отличается особой мобильностью. Строго говоря, маяк вообще не двигается за неимением двигателей.
Поэтому Комната №40 ответила, что DK находится в бухте. Адмиралов ответ устроил и они продолжили действовать исходя из вводной, что немецкий флот никуда не вышел.
А дальше была история. История Ютландского сражения — самого массово сражение на воде во всей истории людей. Ни до, ни после не происходило даже близко ничего подобного. Загуглите, если интересно.
И все из-за того, что разработка неправильно поняла бизнес… В смысле, инженеры не поняли адмиралтейство.
3️⃣ Кто виноват и что делать
Без понимания запросов бизнеса усилия даже самых лучших инженеров могут быть сведены к минимуму. Виноваты процессы, которые оторвали инженеров от реалий. Менеджмент, который не выстроил коммуникацию.
В следующей серии постов я расскажу, как наладить взаимодействие ИТ и продукта.
Кстати, а в вашей истории было что-то похожее?
1️⃣ Элитные инженеры
Представьте: вы — сотрудник самого секретного ИТ-отдела в стране. Само ваше существование это тайна, а от ваших действий зависят судьбы сотен тысяч людей. Каждый из вас прошел самый тщательный отбор. Вы лучшие инженеры, математики и технари своей страны. Элита из элит, creme de la creme.
Представили? Хорошо, потому что сейчас я расскажу, как даже лучшие их лучших ошибаются, потому что не поняли заказчика.
Итак, именно такими ИТшниками были сотрудники Комнаты №40 — секретного отдела Британии. Комната №40 занималась дешифровкой немецких радио-сообщений во время Первой Мировой. Они перехватывали сообщения, ломали шифр и передавали информацию флотским адмиралам.
В комнате действительно работали лучшие: они выяснили, что кодовое имя адмирала Шеера — DK. Но немцы тоже не были дураками и пытались запутать англичан, поэтому когда адмирал Шеер покидал бухту, кодовое имя DK присваивали маяку в той же бухте.
Система несложная: если адмирал в бухте, DK — его кодовое имя. Если не в бухте, то DK становился кодовым именем маяка.
2️⃣ История одной ошибки
30-го Мая Комната №40 начинает перехватывать тревожные сигналы: 3-ая немецкая эскадра покинула бухту. Это 5 линкоров, бронированных монстров с пушками больше 300мм. Даже один линкор — огромная угроза, а тут пять!
31-го Мая бухту покидает 1-ая и 2-ая эскадры. То есть, все линкоры немецкого флота вышли в море. Очевидно, не просто так погулять вышли. Судя по радиоперехвату, адмирал Шеер тоже вышел в море, потому что кодовое имя DK было переназначено на маяк.
Вывод лишь один: немцы готовятся дать генеральное сражение.
Адмиралтейство посылает запрос в Комнату №40: «Где находится DK?». Конечно, адмиралам было интересно текущее расположение немецкого флота.
Однако, в Комнате №40 сидели люди со строго инженерным мышлением. Кодовое имя DK на момент запроса было прикреплено к маяку, а маяк не отличается особой мобильностью. Строго говоря, маяк вообще не двигается за неимением двигателей.
Поэтому Комната №40 ответила, что DK находится в бухте. Адмиралов ответ устроил и они продолжили действовать исходя из вводной, что немецкий флот никуда не вышел.
А дальше была история. История Ютландского сражения — самого массово сражение на воде во всей истории людей. Ни до, ни после не происходило даже близко ничего подобного. Загуглите, если интересно.
И все из-за того, что разработка неправильно поняла бизнес… В смысле, инженеры не поняли адмиралтейство.
3️⃣ Кто виноват и что делать
Без понимания запросов бизнеса усилия даже самых лучших инженеров могут быть сведены к минимуму. Виноваты процессы, которые оторвали инженеров от реалий. Менеджмент, который не выстроил коммуникацию.
В следующей серии постов я расскажу, как наладить взаимодействие ИТ и продукта.
Кстати, а в вашей истории было что-то похожее?
Я обещал вам серию постов про ИТ и продукт. Я ее написал. Но получилась каша — мысли плохо отделялись друг от друга и никак не хотели лезть в серию постов.
Поэтому появилась статья "Как понять продукт и зачем это нужно разработчику" — два полезных фреймворка, которые прямо сейчас помогут вам лучше понять бизнес и вообще задуматься, что весь наш код, который мы пишем и все наши решения, которые мы принимаем — это все для бизнеса. А значит, доложно нести ему пользу.
А если соберетесь и напишите Цепочку Ценности или Матрицу БКГ, обязательно поделитесь этой новостью в комментариях :)
Поэтому появилась статья "Как понять продукт и зачем это нужно разработчику" — два полезных фреймворка, которые прямо сейчас помогут вам лучше понять бизнес и вообще задуматься, что весь наш код, который мы пишем и все наши решения, которые мы принимаем — это все для бизнеса. А значит, доложно нести ему пользу.
А если соберетесь и напишите Цепочку Ценности или Матрицу БКГ, обязательно поделитесь этой новостью в комментариях :)
Хабр
Как понять продукт и зачем это нужно разработчику
Если вы не понимаете бизнес своей компании, вы не сможете полностью реализовать свои технические навыки. Крутой технарь на позиции СТО, который знает нюансы TOGAF и отличия Raft от Paxos — это хорошо,...
Семь типов руководителей, которыми вы не хотите стать
Наткнулся на статью про девять типов плохих менеджеров и подумал, что и сам смог бы составить подобное. Контент как раз для пятницы, легкий и веселый :) Представляю вам список руководителей, которым вы никогда не захотите стать!
🎯 Борис-хрен-попадешь
Любой свой косяк скидывает на команду. Упал прод? Это тестировщики виноваты, плохо протестировали. Сроки поехали? Это разработка долго кодит. Фича не принесла денег? Очевидно, аналитики плохо посчитали. Если же что-то получается, забирает все лавры себе. Действует по проверенной веками схеме: успех мой, провалы — командные.
🦆 Чайка
Прилетает, кричит, улетает дальше. Чайка умеет видеть проблемы, но не умеет или не хочет их решать. Как только в его поле зрения попадает проблема, летит в то место, где она проявилась и фокусирует людей на ее исправлении, даже если они были заняты чем-то более важным. Так как системно проблемы не решаются, мест для "покричать" у него будет в избытке. Создает иллюзию динамики: проблемы возникают, проблемы решаются — значит, все хорошо! Но есть нюанс: это одни и те же проблемы из месяца в месяц.
🪄 Алиса в стране чудес
Не очень понимает реалии системы, которой он управляет. С удивлением может обнаружить, что ключевой сотрудник ушел в отпуск неделю назад. Может не знать точный состав команд. Совершенно точно не знает архитектуру своего участка системы. Теряется, если его спрашивают о текущем положении дел или про нюансы работы его сервисов. В случае, если его непонимание реалий приводит к проблемам, может превратиться в Чайку или Бориса-хрен-попадешь.
🚜 Погрузчик
Как только поступает задача, тут же отгружает ее подчиненному. Не пытается разобраться и вникнуть в детали, потому что занят более важными делами. Какими — мало кто знает, но очень важными. Помощь не предлагает, потому что слишком занят поиском, кому отгрузить новую задачу, которая прилетела сверху. Искренне удивляется, почему подчиненные вокруг в огне, ведь его бэклог совершенно пуст.
🥒 Садовод
Ни за что не пустит вас в свою зону ответственности, потому что это — только его сад. Решения внутри сада принимаются только и только самим Садоводом. Вся коммуникация только через него. Его отдел — это компания в компании, часто со своими практиками и решениями. После ухода садовника, выясняется много интересных деталей, которые часто ведут к рефакторингу архитектуры и реорганизации всего садика.
🖨 Ксерокс
Обожает подсматривать процессы и практики из успешных компаний и приносить их к себе. Как правило, после очередной прочитанной статьи или книги, Ксерокс решает: так дальше жить нельзя! Поэтому в понедельник он приходит и объявляет, что теперь все будут жить по-новому. Например, нужно создать гильдии, потому что на выходных он прочитал про Спотифай и теперь уверен, что гильдии это маст хэв. Зачем — неясно, как внедрять — непонятно, но решение принято! Ядерная смесь получается при совмещении с Алисой в стране чудес: человек не совсем понимает, что вообще вокруг происходит, но тащит из книг все новые и новые практики.
🦄 One trick pony
Не могу перевести на русский, но это человек, который из раза в раз повторяет один и тот же прием. Как цирковой пони, который умеет выполнять только один трюк, такой руководитель продолжает использовать для решения новых проблем одни и те же подходы. Главный аргумент — я так уже делал в прошлых компаниях, и это работало. Разница в контекстах не учитывается, а оппоненты давятся опытом. Хорошо совмещается вместе с Борисом-хрен-попадешь: когда старые решения перестают работать, виноваты будут все, кроме менеджера!
Вот такой список получится. Узнали кого-то? Напишите в комментариях, доводилось ли вам видеть таких руководителей :)
Наткнулся на статью про девять типов плохих менеджеров и подумал, что и сам смог бы составить подобное. Контент как раз для пятницы, легкий и веселый :) Представляю вам список руководителей, которым вы никогда не захотите стать!
🎯 Борис-хрен-попадешь
Любой свой косяк скидывает на команду. Упал прод? Это тестировщики виноваты, плохо протестировали. Сроки поехали? Это разработка долго кодит. Фича не принесла денег? Очевидно, аналитики плохо посчитали. Если же что-то получается, забирает все лавры себе. Действует по проверенной веками схеме: успех мой, провалы — командные.
🦆 Чайка
Прилетает, кричит, улетает дальше. Чайка умеет видеть проблемы, но не умеет или не хочет их решать. Как только в его поле зрения попадает проблема, летит в то место, где она проявилась и фокусирует людей на ее исправлении, даже если они были заняты чем-то более важным. Так как системно проблемы не решаются, мест для "покричать" у него будет в избытке. Создает иллюзию динамики: проблемы возникают, проблемы решаются — значит, все хорошо! Но есть нюанс: это одни и те же проблемы из месяца в месяц.
🪄 Алиса в стране чудес
Не очень понимает реалии системы, которой он управляет. С удивлением может обнаружить, что ключевой сотрудник ушел в отпуск неделю назад. Может не знать точный состав команд. Совершенно точно не знает архитектуру своего участка системы. Теряется, если его спрашивают о текущем положении дел или про нюансы работы его сервисов. В случае, если его непонимание реалий приводит к проблемам, может превратиться в Чайку или Бориса-хрен-попадешь.
🚜 Погрузчик
Как только поступает задача, тут же отгружает ее подчиненному. Не пытается разобраться и вникнуть в детали, потому что занят более важными делами. Какими — мало кто знает, но очень важными. Помощь не предлагает, потому что слишком занят поиском, кому отгрузить новую задачу, которая прилетела сверху. Искренне удивляется, почему подчиненные вокруг в огне, ведь его бэклог совершенно пуст.
🥒 Садовод
Ни за что не пустит вас в свою зону ответственности, потому что это — только его сад. Решения внутри сада принимаются только и только самим Садоводом. Вся коммуникация только через него. Его отдел — это компания в компании, часто со своими практиками и решениями. После ухода садовника, выясняется много интересных деталей, которые часто ведут к рефакторингу архитектуры и реорганизации всего садика.
🖨 Ксерокс
Обожает подсматривать процессы и практики из успешных компаний и приносить их к себе. Как правило, после очередной прочитанной статьи или книги, Ксерокс решает: так дальше жить нельзя! Поэтому в понедельник он приходит и объявляет, что теперь все будут жить по-новому. Например, нужно создать гильдии, потому что на выходных он прочитал про Спотифай и теперь уверен, что гильдии это маст хэв. Зачем — неясно, как внедрять — непонятно, но решение принято! Ядерная смесь получается при совмещении с Алисой в стране чудес: человек не совсем понимает, что вообще вокруг происходит, но тащит из книг все новые и новые практики.
🦄 One trick pony
Не могу перевести на русский, но это человек, который из раза в раз повторяет один и тот же прием. Как цирковой пони, который умеет выполнять только один трюк, такой руководитель продолжает использовать для решения новых проблем одни и те же подходы. Главный аргумент — я так уже делал в прошлых компаниях, и это работало. Разница в контекстах не учитывается, а оппоненты давятся опытом. Хорошо совмещается вместе с Борисом-хрен-попадешь: когда старые решения перестают работать, виноваты будут все, кроме менеджера!
Вот такой список получится. Узнали кого-то? Напишите в комментариях, доводилось ли вам видеть таких руководителей :)
А что бы такого почитать — новая рубрика на канале! Три самых интересных статьи, которые я прочитал за последнюю неделю.
Кто такие Навигаторы и почему они вам нужны
Кому читать: руководителям и инженерам, которые хотят вырасти дальше сеньора.
Статья предлагает новую роль в компании — Навигатор. Это опытный инженер, который отвечает за целую область разработки. Например, домен или продуктовая вертикаль. Автор — Вилл Ларсон — описывает решаемые проблемы и алгоритм внедрения роли Навигатора в компанию.
Проблемы, которые решают Навигаторы:
- Разработчики не согласны с решениями, которые принимаются в другой части компании. Например, "неправильный" дизайн сервисов в соседнем домене, не те стандарты разработки, не то API и все такое.
- Непонятно, кто отвечает за весь домен или вертикаль целиком. С сервисом — понятно, есть команда. А к кому обращаться, если есть вопросы по целой группе сервисов?
- Как разрулить конфликт двух команд разных доменов без эскалации в СТО?
На моем прошлом месте работы я внедрил роль Навигатора, правда, назвал я ее стафф-инженер, потому что на тот момент Вилл Ларсон Навигаторов еще не описал. В статье описан его опыт и видение, с которым я согласен почти полностью.
В компаниях от 100 человек Навигаторы нужны как воздух, без них начнется хаос и неразбериха. Причем отдельно выделенные архитекторы проблемы не решат, а могут сделать даже хуже.
Читайте и пробуйте внедрить Навигаторов у себя — или подумайте, как вам самим стать Навигатором. Роль интересная, очень востребованная на рынке. А еще название прикольное.
Инцидент коммандер: как стать человеком, у которого есть план (даже если его нет)
Кому читать: всем, кто спасти мир — в смысле, компанию
Представьте: произошел инцидент и вы собрались, чтобы его потушить. Все беспорядочно пытаются выяснить проблему, действия не согласованы, за метриками никто не следит, коммуникацию с бизнесом никто не производит. Ужас какой-то.
Или все может пойти по иному пути: появляется человек, который скажет всем, что делать. Вася мониторит метрики, Петя проверяет последние релизы, Аня ищет ошибку в логах, а Толя дает бизнесу апдейты каждые 15 минут. Все на своих местах. Все знают, что делать.
Человек, который остановит судорожную беготню — Инцидент коммандер. Его разум холоден, действия точны, уверенность в себе непоколебима. Если такой человек есть, инцидент вы потушите в разы быстрее.
Статья рассказывает, как вам стать Инцидент коммандером и принять на себя руководство кораблем, который вот-вот потонет и спасти его. Такие люди — на вес золота, и очень быстро становятся опорой для всей компании. Даже в крупной организации на тысячу человек их имена знают все.
Инцидент коммандер — это не постоянная роль. Это плащ, который надевает обычный разработчик или руководитель, чтобы превратится в героя вечера и спасти город. В смысле, компанию.
Хотите узнать, как примерить на себя геройский плащ? Читайте! Этому городу нужен новый герой.
Вы понимаете роль Product Owner'а неправильно
Кому читать: всем, кто работает с продакт овнерами
Скрам научил нас, что у разработки может быть лишь два вопроса к продакту: какие фичи пилить и в каком порядке? Но вообще-то есть нюанс.
Автор приводит аналогию, что разработка — это солдаты на поле боя, а продакты это командиры в штабе и раздают приказы по рации. Продакт не может сказать, что именно делать, только дает задачу. Как именно ее решить, разработка знает лучше, потому что находится прямо в гуще событий.
Статья предлагает по-новому построить ваши отношения с продуктом: узнайте своих клиентов, поймите данные, которые стоят за гипотезами продакта.
Это не сухая статья, а оригинальные метафоры и примеры, которые помогут вам взглянуть на роль разработчика по-новому. Если вы работаете в продуктовой команде и ощущаете себя простым исполнителем, исправьте это — а автор подскажет вам, как.
Кто такие Навигаторы и почему они вам нужны
Кому читать: руководителям и инженерам, которые хотят вырасти дальше сеньора.
Статья предлагает новую роль в компании — Навигатор. Это опытный инженер, который отвечает за целую область разработки. Например, домен или продуктовая вертикаль. Автор — Вилл Ларсон — описывает решаемые проблемы и алгоритм внедрения роли Навигатора в компанию.
Проблемы, которые решают Навигаторы:
- Разработчики не согласны с решениями, которые принимаются в другой части компании. Например, "неправильный" дизайн сервисов в соседнем домене, не те стандарты разработки, не то API и все такое.
- Непонятно, кто отвечает за весь домен или вертикаль целиком. С сервисом — понятно, есть команда. А к кому обращаться, если есть вопросы по целой группе сервисов?
- Как разрулить конфликт двух команд разных доменов без эскалации в СТО?
На моем прошлом месте работы я внедрил роль Навигатора, правда, назвал я ее стафф-инженер, потому что на тот момент Вилл Ларсон Навигаторов еще не описал. В статье описан его опыт и видение, с которым я согласен почти полностью.
В компаниях от 100 человек Навигаторы нужны как воздух, без них начнется хаос и неразбериха. Причем отдельно выделенные архитекторы проблемы не решат, а могут сделать даже хуже.
Читайте и пробуйте внедрить Навигаторов у себя — или подумайте, как вам самим стать Навигатором. Роль интересная, очень востребованная на рынке. А еще название прикольное.
Инцидент коммандер: как стать человеком, у которого есть план (даже если его нет)
Кому читать: всем, кто спасти мир — в смысле, компанию
Представьте: произошел инцидент и вы собрались, чтобы его потушить. Все беспорядочно пытаются выяснить проблему, действия не согласованы, за метриками никто не следит, коммуникацию с бизнесом никто не производит. Ужас какой-то.
Или все может пойти по иному пути: появляется человек, который скажет всем, что делать. Вася мониторит метрики, Петя проверяет последние релизы, Аня ищет ошибку в логах, а Толя дает бизнесу апдейты каждые 15 минут. Все на своих местах. Все знают, что делать.
Человек, который остановит судорожную беготню — Инцидент коммандер. Его разум холоден, действия точны, уверенность в себе непоколебима. Если такой человек есть, инцидент вы потушите в разы быстрее.
Статья рассказывает, как вам стать Инцидент коммандером и принять на себя руководство кораблем, который вот-вот потонет и спасти его. Такие люди — на вес золота, и очень быстро становятся опорой для всей компании. Даже в крупной организации на тысячу человек их имена знают все.
Инцидент коммандер — это не постоянная роль. Это плащ, который надевает обычный разработчик или руководитель, чтобы превратится в героя вечера и спасти город. В смысле, компанию.
Хотите узнать, как примерить на себя геройский плащ? Читайте! Этому городу нужен новый герой.
Вы понимаете роль Product Owner'а неправильно
Кому читать: всем, кто работает с продакт овнерами
Скрам научил нас, что у разработки может быть лишь два вопроса к продакту: какие фичи пилить и в каком порядке? Но вообще-то есть нюанс.
Автор приводит аналогию, что разработка — это солдаты на поле боя, а продакты это командиры в штабе и раздают приказы по рации. Продакт не может сказать, что именно делать, только дает задачу. Как именно ее решить, разработка знает лучше, потому что находится прямо в гуще событий.
Статья предлагает по-новому построить ваши отношения с продуктом: узнайте своих клиентов, поймите данные, которые стоят за гипотезами продакта.
Это не сухая статья, а оригинальные метафоры и примеры, которые помогут вам взглянуть на роль разработчика по-новому. Если вы работаете в продуктовой команде и ощущаете себя простым исполнителем, исправьте это — а автор подскажет вам, как.
Шестой порок команды
Патрик Ленсиони в книге "Пять Пороков Команды" описывает эти самые пороки:
- Недоверие
- Боязнь конфликта
- Безответственность
- Нетребовательность
- Безразличие к результатам
Не буду на них подробно останавливаться. Если не читали книгу, рекомендую — читается за вечер, а пользы на всю жизнь.
Я обнаружил шестой порок: необоснованная эскалация.
❓Что это такое?
Необоснованная эскалация — это когда вместо того, чтобы разобраться в ситуации и решить проблему самостоятельно, проблема эскалируется руководителю, руководитель обращается к другому руководителю, вместе они спускаются к проблеме и пытаются ее решить.
Звучит сложно, поэтому давайте на примерах.
📁 Пример
Разработчик Вася считает, что все API должно быть исключительно RESTful. По шагам:
- Вася пришел в сервис соседней команды и запилил новую ручку.
- Соседняя команда в ходе ревью кода сказала Васе, что у них так не принято и API надо писать по-другому.
- Вася ответил, что RESTful — это лучшая практика, и он не понимает, почему это плохо и надо переписать.
- Соседняя команда вместо разговора с Васей обращается к своему тимлиду с просьбой разобраться.
- Тимлид идет к своему юнит-лиду.
- Их юнит-лид идет к юнит-лиду Васи.
- Юнит-лид Васи идет к тимлиду Васи.
- Тимлид Васи идет к Васе и говорит, что не надо так делать, лучше переписать по правилам команды.
Как итог получаем: кучу потраченного времени, рост времени на разработку, демотивированного Васю и нерешенный конфликт. Последнее — самое важное, потому что в следующий раз проблема никуда не исчезнет, и когда Васе понадобится вновь сделать коммит в соседний сервис, проблема появится вновь.
❌ Почему необоснованная эскалация — это порок
- Убивает инициативность в людях. Человек видит, что его действия приводят к эскалации, в ходе которой проблему решает не он. Это ведет к выученной беспомощности: зачем вообще проявлять инициативу, если она ни к чему не ведет?
- Мешает росту лидеров. Если необоснованная эскалация стала стандартом, вырастить настоящего лидера в подобных условиях не получится.
- Крадет время. Для решения одной проблемы задействуются сразу несколько руководителей. Если необоснованная эскалация – регулярная практика, то руководители постоянно заняты решением этих эскалация вместо улучшения работы команд.
🏆 Как побороть
Я знаю лишь один способ: показывать своим примером. Если ваш сотрудник эскалировал в вас понапрасну, объясните ему, что не надо так делать. Если необоснованная эскалация возникла со стороны члена другой команды, поговорите с руководителем этого человека и постарайтесь объяснить, что такую эскалацию лучше не делать.
Поделитесь своим мнением — случалась ли необоснованная эскалация в вашей жизни? Очень интересно узнать, не один ли я заметил этот порок.
Патрик Ленсиони в книге "Пять Пороков Команды" описывает эти самые пороки:
- Недоверие
- Боязнь конфликта
- Безответственность
- Нетребовательность
- Безразличие к результатам
Не буду на них подробно останавливаться. Если не читали книгу, рекомендую — читается за вечер, а пользы на всю жизнь.
Я обнаружил шестой порок: необоснованная эскалация.
❓Что это такое?
Необоснованная эскалация — это когда вместо того, чтобы разобраться в ситуации и решить проблему самостоятельно, проблема эскалируется руководителю, руководитель обращается к другому руководителю, вместе они спускаются к проблеме и пытаются ее решить.
Звучит сложно, поэтому давайте на примерах.
📁 Пример
Разработчик Вася считает, что все API должно быть исключительно RESTful. По шагам:
- Вася пришел в сервис соседней команды и запилил новую ручку.
- Соседняя команда в ходе ревью кода сказала Васе, что у них так не принято и API надо писать по-другому.
- Вася ответил, что RESTful — это лучшая практика, и он не понимает, почему это плохо и надо переписать.
- Соседняя команда вместо разговора с Васей обращается к своему тимлиду с просьбой разобраться.
- Тимлид идет к своему юнит-лиду.
- Их юнит-лид идет к юнит-лиду Васи.
- Юнит-лид Васи идет к тимлиду Васи.
- Тимлид Васи идет к Васе и говорит, что не надо так делать, лучше переписать по правилам команды.
Как итог получаем: кучу потраченного времени, рост времени на разработку, демотивированного Васю и нерешенный конфликт. Последнее — самое важное, потому что в следующий раз проблема никуда не исчезнет, и когда Васе понадобится вновь сделать коммит в соседний сервис, проблема появится вновь.
❌ Почему необоснованная эскалация — это порок
- Убивает инициативность в людях. Человек видит, что его действия приводят к эскалации, в ходе которой проблему решает не он. Это ведет к выученной беспомощности: зачем вообще проявлять инициативу, если она ни к чему не ведет?
- Мешает росту лидеров. Если необоснованная эскалация стала стандартом, вырастить настоящего лидера в подобных условиях не получится.
- Крадет время. Для решения одной проблемы задействуются сразу несколько руководителей. Если необоснованная эскалация – регулярная практика, то руководители постоянно заняты решением этих эскалация вместо улучшения работы команд.
🏆 Как побороть
Я знаю лишь один способ: показывать своим примером. Если ваш сотрудник эскалировал в вас понапрасну, объясните ему, что не надо так делать. Если необоснованная эскалация возникла со стороны члена другой команды, поговорите с руководителем этого человека и постарайтесь объяснить, что такую эскалацию лучше не делать.
Поделитесь своим мнением — случалась ли необоснованная эскалация в вашей жизни? Очень интересно узнать, не один ли я заметил этот порок.
3 признака плохого лидера
Джоко Виллинк — бывший морской котик, Navy SEAL называется. Это очень элитное подзразделение, на их обучение и тренировки США тратит невероятное количество бабла. Особенное внимание уделяется лидерству.
Виллинк — как раз лидер, который командовал несколькими отрядами. После отставки он написал книгу "Extreme Ownership", где описал концепт экстремальной ответственности, который теперь применяют менеджеры во многих ИТ компаниях.
Лидер, и только лидер определяет успех или провал операции, считает Виллинк. В реалиях боевых действий "провал" означает не только потерю премии из-за провала KPI — в реалиях морских котиков провал это некоторым образом страшнее. Например, плохое лидерство привело к дружественному огню, в ходе которого пострадали союзники и члены его отряда.
Согласитесь: дружественный огонь — это совсем не по-дружески!
Поэтому для Виллинка было критично выявлять плохих лидеров и либо делать из них хороших, либо отстранять от лидерской роли.
Вот какие признаки плохого лидера определяет Виллинк.
1️⃣ Рычит на своих людей
Виллинк употребляет термин "bark orders" — когда вместо спокойного тона, вы бувально рычите на своих людей.
Если вам приходится рычать, чтобы отдать приказ — вы уже облажались. Если вас не слушают и вам приходится повышать голос и давить на людей, это не просто плохой знак, это огромный красный флаг.
В мире ИТ я знаю руководителей, которые так себя ведут. Их не любят.
2️⃣ Не доносит конечную цель
Рычать на людей приходится из-за того, что плохой лидер не донес до них конечную цель. Если бойцы не знают, как должен выглядеть итоговый результат, они теряются и лидеру приходится рычать.
В ИТ это частая история. Приходит руководитель, очень смутно описывает что надо сделать и уходит. Приходит через пару недель и понимает, что результат вообще не соответствует его ожиданиям. Что он начинает делать? Он начинает гавкать на сотрудников!
Всегда убеждайтесь, что вы нарисовали у каждого члена команды правильную картину конечного результата. Не просто доносите цель — убеждайтесь, спрашивайте и проверяйте, что вас поняли правильно!
3️⃣ Не создает правильных прецедентов
Допустим, ваш сотрудник на общей встрече предложил решение проблемы. Плохое решение. Очевидно плохое, потому что вы готовы по полочкам разложить, почему он не прав.
Если вы начнете сразу объяснять ему, что он не прав, вы создадите плохой прецедент: инициатива в вашей команде ведет к тому, что инициатора публично поставят на место. В следующий раз он промолчит. Ваши сотрудники будут пассивными и вам придется на них рычать!
Если вы начнете задавать наводящие вопросы и поможете человеку самому разобраться, почему решение не ок, вы тоже создадите прецедент. Хороший прецедент — ведь инициатива помогла человеку самому разобраться в вопросе и стать чуточку экспертнее. В следующий раз он предложит лучшее решение.
Хороший лидер создает хорошие прецеденты. Плохой — плохие.
‼️Выводы
Лидер, который не доносит целей и не дает проявлять инициативу в итоге вырастит пассивную команду. Они будут следовать за лидером — правда, иногда лидеру придется нарычать на команду, чтобы сдвинуть их с места.
В итоге все сводится к одному: плохой лидер — тот, кто из-за своего эго не может позволить людям вокруг проявлять инициативу, принимать решения и расти.
Что скажете? Согласны с Виллинком, или его армейские принципы в ИТ неприменимы? Расскажите в комментариях :)
Джоко Виллинк — бывший морской котик, Navy SEAL называется. Это очень элитное подзразделение, на их обучение и тренировки США тратит невероятное количество бабла. Особенное внимание уделяется лидерству.
Виллинк — как раз лидер, который командовал несколькими отрядами. После отставки он написал книгу "Extreme Ownership", где описал концепт экстремальной ответственности, который теперь применяют менеджеры во многих ИТ компаниях.
Лидер, и только лидер определяет успех или провал операции, считает Виллинк. В реалиях боевых действий "провал" означает не только потерю премии из-за провала KPI — в реалиях морских котиков провал это некоторым образом страшнее. Например, плохое лидерство привело к дружественному огню, в ходе которого пострадали союзники и члены его отряда.
Согласитесь: дружественный огонь — это совсем не по-дружески!
Поэтому для Виллинка было критично выявлять плохих лидеров и либо делать из них хороших, либо отстранять от лидерской роли.
Вот какие признаки плохого лидера определяет Виллинк.
1️⃣ Рычит на своих людей
Виллинк употребляет термин "bark orders" — когда вместо спокойного тона, вы бувально рычите на своих людей.
Если вам приходится рычать, чтобы отдать приказ — вы уже облажались. Если вас не слушают и вам приходится повышать голос и давить на людей, это не просто плохой знак, это огромный красный флаг.
В мире ИТ я знаю руководителей, которые так себя ведут. Их не любят.
2️⃣ Не доносит конечную цель
Рычать на людей приходится из-за того, что плохой лидер не донес до них конечную цель. Если бойцы не знают, как должен выглядеть итоговый результат, они теряются и лидеру приходится рычать.
В ИТ это частая история. Приходит руководитель, очень смутно описывает что надо сделать и уходит. Приходит через пару недель и понимает, что результат вообще не соответствует его ожиданиям. Что он начинает делать? Он начинает гавкать на сотрудников!
Всегда убеждайтесь, что вы нарисовали у каждого члена команды правильную картину конечного результата. Не просто доносите цель — убеждайтесь, спрашивайте и проверяйте, что вас поняли правильно!
3️⃣ Не создает правильных прецедентов
Допустим, ваш сотрудник на общей встрече предложил решение проблемы. Плохое решение. Очевидно плохое, потому что вы готовы по полочкам разложить, почему он не прав.
Если вы начнете сразу объяснять ему, что он не прав, вы создадите плохой прецедент: инициатива в вашей команде ведет к тому, что инициатора публично поставят на место. В следующий раз он промолчит. Ваши сотрудники будут пассивными и вам придется на них рычать!
Если вы начнете задавать наводящие вопросы и поможете человеку самому разобраться, почему решение не ок, вы тоже создадите прецедент. Хороший прецедент — ведь инициатива помогла человеку самому разобраться в вопросе и стать чуточку экспертнее. В следующий раз он предложит лучшее решение.
Хороший лидер создает хорошие прецеденты. Плохой — плохие.
‼️Выводы
Лидер, который не доносит целей и не дает проявлять инициативу в итоге вырастит пассивную команду. Они будут следовать за лидером — правда, иногда лидеру придется нарычать на команду, чтобы сдвинуть их с места.
В итоге все сводится к одному: плохой лидер — тот, кто из-за своего эго не может позволить людям вокруг проявлять инициативу, принимать решения и расти.
Что скажете? Согласны с Виллинком, или его армейские принципы в ИТ неприменимы? Расскажите в комментариях :)
Доброго утра!
Я работаю по 60-80 часов в неделю и привык думать, что это еще норм. А работать сорок часов в неделю — вообще роскошь. Ведь раньше-то люди работали вообще без отдыха и выходных! Но так ли это? Мы с вами работаем где-то 2000 часов в год при рабочей неделе в 40 часов.
Давайте отмотаем время назад.
🛠 Индустриальная эпоха
В эпоху индустриализации люди на заводах работали по 12-16 часов каждый день, с редкими выходными. Тогдашние фабрики были филиалом ада на земле. В 19-ом веке в Британии человек мог работать 3000-3500 часов в год.
🧑🌾 Средневековье
А вот средневековый крестьянин работал значительно меньше нашего. В статье указаны вот такие цифры:
- 13-ый век — 1620 часов в год
- 14-ый век — 1440 часов в год
Это примерно на 500 часов меньше, чем работаем мы с вами. Это 12 недель или 3 месяца. Откуда такая разница?
- Праздники: если сложить все праздники того времени в Испании, получается пять месяцев в году. Неплохо!
- Перерывы в работе. Исследователи отмечают, что люди могли работать от рассвета до заката, но с перерывами: завтрак, послеобеденный сон (круто же?), ужин и различные перекусы.
- Сезонность: зимой ни сеять, ни жать нечего. Работать полный день или полную неделю не было смысла.
И я не спорю, что жить тогда было хуже: не было нормальной медицины, люди лечились то ртутью, то мышьяком (я не шучу). Болезни, чума — ужас.
Но работали при этом на 3 месяца меньше, чем мы с вами.
🦁 Первобытные племена
Думаете, это все? Нет, давайте-ка отмотаем время еще дальше, к нашим первобытным предкам и охотникам-собирателям. Они могли работать по 3 часа в неделю! Мужчина охотился неделю, а потом отдыхал еще две. Разные исследователи приводят разные цифры, но в среднем в те времена работали по 20 часов в неделю. В два раза меньше!
Роберт Сапольски жил рядом с таким племенем в Кении, и писал, что большую часть времени племя просто отдыхало и общалось. "Старики" вообще не работали ни одного часа в неделю. Стариком, кстати, считаются люди старше 25-30 лет. По меркам кенийцев, я уже старик.
‼️ Итоги
Прогресс принес нам много плюшек, это глупо отрицать. Но отрицать регресс тоже неправильно:
- Мы стали работать больше.
- Мы меньше общаемся с другими людьми вне работы, поддерживаем ограниченное количество социальных контактов.
- Мы сильно потеряли во взаимопомощи. В первобытном племени сплоченность была на совершенно ином уровне, чем в нашем развитом обществе.
Технический прогресс идет дальше, мы уже видим зарождение ИИ. А вот прогресс социальный застыл: новые технологии пока не помогли нам даже приблизиться к норме работы первобытных людей.
А что вы думаете? Раньше действительно было лучше? :)
Я работаю по 60-80 часов в неделю и привык думать, что это еще норм. А работать сорок часов в неделю — вообще роскошь. Ведь раньше-то люди работали вообще без отдыха и выходных! Но так ли это? Мы с вами работаем где-то 2000 часов в год при рабочей неделе в 40 часов.
Давайте отмотаем время назад.
🛠 Индустриальная эпоха
В эпоху индустриализации люди на заводах работали по 12-16 часов каждый день, с редкими выходными. Тогдашние фабрики были филиалом ада на земле. В 19-ом веке в Британии человек мог работать 3000-3500 часов в год.
🧑🌾 Средневековье
А вот средневековый крестьянин работал значительно меньше нашего. В статье указаны вот такие цифры:
- 13-ый век — 1620 часов в год
- 14-ый век — 1440 часов в год
Это примерно на 500 часов меньше, чем работаем мы с вами. Это 12 недель или 3 месяца. Откуда такая разница?
- Праздники: если сложить все праздники того времени в Испании, получается пять месяцев в году. Неплохо!
- Перерывы в работе. Исследователи отмечают, что люди могли работать от рассвета до заката, но с перерывами: завтрак, послеобеденный сон (круто же?), ужин и различные перекусы.
- Сезонность: зимой ни сеять, ни жать нечего. Работать полный день или полную неделю не было смысла.
И я не спорю, что жить тогда было хуже: не было нормальной медицины, люди лечились то ртутью, то мышьяком (я не шучу). Болезни, чума — ужас.
Но работали при этом на 3 месяца меньше, чем мы с вами.
🦁 Первобытные племена
Думаете, это все? Нет, давайте-ка отмотаем время еще дальше, к нашим первобытным предкам и охотникам-собирателям. Они могли работать по 3 часа в неделю! Мужчина охотился неделю, а потом отдыхал еще две. Разные исследователи приводят разные цифры, но в среднем в те времена работали по 20 часов в неделю. В два раза меньше!
Роберт Сапольски жил рядом с таким племенем в Кении, и писал, что большую часть времени племя просто отдыхало и общалось. "Старики" вообще не работали ни одного часа в неделю. Стариком, кстати, считаются люди старше 25-30 лет. По меркам кенийцев, я уже старик.
‼️ Итоги
Прогресс принес нам много плюшек, это глупо отрицать. Но отрицать регресс тоже неправильно:
- Мы стали работать больше.
- Мы меньше общаемся с другими людьми вне работы, поддерживаем ограниченное количество социальных контактов.
- Мы сильно потеряли во взаимопомощи. В первобытном племени сплоченность была на совершенно ином уровне, чем в нашем развитом обществе.
Технический прогресс идет дальше, мы уже видим зарождение ИИ. А вот прогресс социальный застыл: новые технологии пока не помогли нам даже приблизиться к норме работы первобытных людей.
А что вы думаете? Раньше действительно было лучше? :)
Как найти тему для выступления
Я часто пушу людей выступать на конференциях. Это полезно и для самого человека, и для карьеры.
Когда я говорю "иди выступи", в 90% случаев мне отвечают "у меня нет темы для выступления". Я слышал этот ответ настолько часто, что мне уже даже не смешно. Сейчас я расскажу вам один лайфхак, который навсегда решит для вас проблему "нет темы выступления".
Не. Выступайте. Для. Себя.
Когда вы думаете над темой, вы думаете, о чем было бы вам самим интересно послушать. Это неправильно — если вам тема интересна, значит, вы не до конца в ней разобрались.
Придумайте тему, которая вам уже наскучила, а два года назад была интересной. Например:
- Сейчас вы уже на автомате разбиваете систему на DDD-шные домены, а два года назад не понимали, с чего подступиться.
- Сейчас вы не боитесь написать плохую миграцию в Постгресе, а два года назад чуть не положили прод с помощью добавления дефолтной колонки.
Хорошая тема для выступления должна вам быть понятна, и даже немного скучна. Не бойтесь рассказывать о темах, которые вам кажутся скучными. Для вашей аудитории они могут оказаться не такими очевидными.
Не выступайте для себя нынешнего — выступайте для себя два года назад. Это главный лайфхак, который позволит вам найти десятки тем для публичных выступлений.
Если хотите копнуть тему подробнее, вот статья на Хабре. А еще, сегодня стартовал TeamLead Conf — вот каналы спикеров. Посмотрите и подпишитесь, если найдете для себя полезное 🙂
Я часто пушу людей выступать на конференциях. Это полезно и для самого человека, и для карьеры.
Когда я говорю "иди выступи", в 90% случаев мне отвечают "у меня нет темы для выступления". Я слышал этот ответ настолько часто, что мне уже даже не смешно. Сейчас я расскажу вам один лайфхак, который навсегда решит для вас проблему "нет темы выступления".
Не. Выступайте. Для. Себя.
Когда вы думаете над темой, вы думаете, о чем было бы вам самим интересно послушать. Это неправильно — если вам тема интересна, значит, вы не до конца в ней разобрались.
Придумайте тему, которая вам уже наскучила, а два года назад была интересной. Например:
- Сейчас вы уже на автомате разбиваете систему на DDD-шные домены, а два года назад не понимали, с чего подступиться.
- Сейчас вы не боитесь написать плохую миграцию в Постгресе, а два года назад чуть не положили прод с помощью добавления дефолтной колонки.
Хорошая тема для выступления должна вам быть понятна, и даже немного скучна. Не бойтесь рассказывать о темах, которые вам кажутся скучными. Для вашей аудитории они могут оказаться не такими очевидными.
Не выступайте для себя нынешнего — выступайте для себя два года назад. Это главный лайфхак, который позволит вам найти десятки тем для публичных выступлений.
Если хотите копнуть тему подробнее, вот статья на Хабре. А еще, сегодня стартовал TeamLead Conf — вот каналы спикеров. Посмотрите и подпишитесь, если найдете для себя полезное 🙂
Как сделать встречи полезными?
В прошлом посте мы обсудили вред бесполезных встреч. Теперь давайте разберемся, как сделать встречи эффективными.
1️⃣ Уберите лишнее
Чтобы встречи были вам полезны, ходите только на полезные встречи. Отклоняйте ненужные или бесполезные для вас встречи.
Если сомневаетесь, спросите себя: на что конкретно вы меняете 30-60 минут своей жизни? Чтобы просто посидеть кустиком, потому что позвали, или вы внесете значимый вклад во встречу?
2️⃣ Слушайте и говорите
Если вы просидели молча всю встречу или постоянно смотрели мемы в соседней вкладке, поздравляю: вы только что растранжирили свое время одним из самых странных способов.
Если вы молчите и вам неинтересно содержимое встречи, скорее всего, это бесполезная для вас встреча.
3️⃣ Записывайте
Я пользуюсь программой LogSeq, чего и вам советую. После каждой встречи у меня остается 5-10 поинтов исключительно для меня. Иногда я к ним обращаюсь, иногда — нет. Но пишу всегда.
Записи помогают мне сосредоточится, так что меня меньше тянет отвлекаться от того, что говорят люди на встрече.
4️⃣ Пишите агенду
Если я собираю новую встречу, я либо прикреплю агенду ко встрече, либо отправлю людям документ в мессенджер. Агенда помогает мне четче сформулировать мою цель для встречи и экономит время на введение.
5️⃣ Пишите план действий
В конце встречи определите, что каждый из участников сделает (или не сделает) по итогу встречи. Например, мы договорились, что Вася напишет архитектурное решение до среды. Обязательно должны быть конкретные действия. Если после встречи их нет, боюсь, встреча могла пройти впустую.
‼️ Итоги
Для меня каждая встреча — важное событие, по итогу которого я ожидаю каких-то изменений и действий. Неважно: это регулярный 1-1 или встреча по Event Storming'у, каждая встреча важна и нужна, а без нее будет хуже, чем с ней.
А как вы делаете ваши встречи эффективнее?
В прошлом посте мы обсудили вред бесполезных встреч. Теперь давайте разберемся, как сделать встречи эффективными.
1️⃣ Уберите лишнее
Чтобы встречи были вам полезны, ходите только на полезные встречи. Отклоняйте ненужные или бесполезные для вас встречи.
Если сомневаетесь, спросите себя: на что конкретно вы меняете 30-60 минут своей жизни? Чтобы просто посидеть кустиком, потому что позвали, или вы внесете значимый вклад во встречу?
2️⃣ Слушайте и говорите
Если вы просидели молча всю встречу или постоянно смотрели мемы в соседней вкладке, поздравляю: вы только что растранжирили свое время одним из самых странных способов.
Если вы молчите и вам неинтересно содержимое встречи, скорее всего, это бесполезная для вас встреча.
3️⃣ Записывайте
Я пользуюсь программой LogSeq, чего и вам советую. После каждой встречи у меня остается 5-10 поинтов исключительно для меня. Иногда я к ним обращаюсь, иногда — нет. Но пишу всегда.
Записи помогают мне сосредоточится, так что меня меньше тянет отвлекаться от того, что говорят люди на встрече.
4️⃣ Пишите агенду
Если я собираю новую встречу, я либо прикреплю агенду ко встрече, либо отправлю людям документ в мессенджер. Агенда помогает мне четче сформулировать мою цель для встречи и экономит время на введение.
5️⃣ Пишите план действий
В конце встречи определите, что каждый из участников сделает (или не сделает) по итогу встречи. Например, мы договорились, что Вася напишет архитектурное решение до среды. Обязательно должны быть конкретные действия. Если после встречи их нет, боюсь, встреча могла пройти впустую.
‼️ Итоги
Для меня каждая встреча — важное событие, по итогу которого я ожидаю каких-то изменений и действий. Неважно: это регулярный 1-1 или встреча по Event Storming'у, каждая встреча важна и нужна, а без нее будет хуже, чем с ней.
А как вы делаете ваши встречи эффективнее?
Чему нас могут научить автобусы
Бизнес всегда хочет, чтобы разработка поставляла фичи быстрее. И мы у себя в ИТ придумали процессы, скрам, CI/CD — кучу всего придумали, если честно.
Но сегодня я дам вам самый простой рецепт, как повысить ощущение скорости разработки для бизнеса. И помогут нам в этом... Автобусы!
🚍 Как психология помогла сэкономить миллионы долларов
Во всех городах всех стран мира есть проблема: пассажиры расстраиваются, если слишком долго ждут свой автобус. Можно добавить новые автобусы на линию и решить проблему, но новые автобусы стоят много тысяч долларов.
Здесь важно помнить, какую проблему мы решаем. Корневая проблема — люди считают, что они слишком долго ждут автобуса. Добавление новых автобусов должно снизить их время ожидания, но это лишь один из методов решить проблему.
И тогда ученые подумали: как еще мы можем повлиять на время ожидания автобуса? В качестве эксперимента ученые установили на некоторых остановках дисплей, на которых отображалось время до прибытия следующего автобуса. Плюс у каждого пассажира начали спрашивать его ощущения, сколько минут он ждал своего автобуса.
Результаты удивили: пассажиры на остановках с дисплеем заявляли, что ждут автобуса примерно на 30% времени меньше, чем пассажиры на остановках без дисплея!
Еще раз: автобусов осталось ровно столько же. Ученые только добавили дисплей, на котором было видно, сколько еще осталось ждать. И это улучшило показатель на 30 процентов! Представьте, сколько автобусов нужно было бы вывести, чтобы достигнуть такого же результата? Сколько денег потратить — кошмар просто.
🚌 Автобусы помогают в ИТ
Думаю, вы уже догадались, куда я веду: контролируйте ожидания сроков своего заказчика. Не обещайте просто сделать задачу, озвучьте сроки и придерживайтесь их. А еще лучше: приведите в порядок вашу Джиру, чтобы бизнес сам мог видеть движение задач и знал, сколько ему еще ждать автобуса. В смысле, сколько еще ждать его фичи.
Я, кстати, до сих пор помню, как в Купере ко мне подошла менеджер и попросила просто говорить ей сроки. Она была согласна ждать задачу и месяц, и два — ей нужен был просто дедлайн, до которого задача гарантировано была бы сделана. Вместо этого, одна из моих команд просто говорила "сделаем" без ясных сроков. Так не надо.
Инструменты, которые могут вам помочь:
- Дорожная карта, на которой отмечены важные даты проекта или его релизы
- Текстовые апдейты раз в неделю (или чаще), как двигается проект и как мы попадаем в сроки
- Заполненная Джира, в которой виден статус проекта и его задач
Я в Циан использую все три, кстати.
Итак: прозрачные сроки сами по себе могут ускорить ощущение скорости разработки. Исследований в ИТ на эту тему пока не проводилось, поэтому скажите в комментариях, что думаете — бьется ли мой метод с вашим восприятием? Как вы сообщаете бизнесу сроки и контролируете его ощущения?
Бизнес всегда хочет, чтобы разработка поставляла фичи быстрее. И мы у себя в ИТ придумали процессы, скрам, CI/CD — кучу всего придумали, если честно.
Но сегодня я дам вам самый простой рецепт, как повысить ощущение скорости разработки для бизнеса. И помогут нам в этом... Автобусы!
🚍 Как психология помогла сэкономить миллионы долларов
Во всех городах всех стран мира есть проблема: пассажиры расстраиваются, если слишком долго ждут свой автобус. Можно добавить новые автобусы на линию и решить проблему, но новые автобусы стоят много тысяч долларов.
Здесь важно помнить, какую проблему мы решаем. Корневая проблема — люди считают, что они слишком долго ждут автобуса. Добавление новых автобусов должно снизить их время ожидания, но это лишь один из методов решить проблему.
И тогда ученые подумали: как еще мы можем повлиять на время ожидания автобуса? В качестве эксперимента ученые установили на некоторых остановках дисплей, на которых отображалось время до прибытия следующего автобуса. Плюс у каждого пассажира начали спрашивать его ощущения, сколько минут он ждал своего автобуса.
Результаты удивили: пассажиры на остановках с дисплеем заявляли, что ждут автобуса примерно на 30% времени меньше, чем пассажиры на остановках без дисплея!
Еще раз: автобусов осталось ровно столько же. Ученые только добавили дисплей, на котором было видно, сколько еще осталось ждать. И это улучшило показатель на 30 процентов! Представьте, сколько автобусов нужно было бы вывести, чтобы достигнуть такого же результата? Сколько денег потратить — кошмар просто.
🚌 Автобусы помогают в ИТ
Думаю, вы уже догадались, куда я веду: контролируйте ожидания сроков своего заказчика. Не обещайте просто сделать задачу, озвучьте сроки и придерживайтесь их. А еще лучше: приведите в порядок вашу Джиру, чтобы бизнес сам мог видеть движение задач и знал, сколько ему еще ждать автобуса. В смысле, сколько еще ждать его фичи.
Я, кстати, до сих пор помню, как в Купере ко мне подошла менеджер и попросила просто говорить ей сроки. Она была согласна ждать задачу и месяц, и два — ей нужен был просто дедлайн, до которого задача гарантировано была бы сделана. Вместо этого, одна из моих команд просто говорила "сделаем" без ясных сроков. Так не надо.
Инструменты, которые могут вам помочь:
- Дорожная карта, на которой отмечены важные даты проекта или его релизы
- Текстовые апдейты раз в неделю (или чаще), как двигается проект и как мы попадаем в сроки
- Заполненная Джира, в которой виден статус проекта и его задач
Я в Циан использую все три, кстати.
Итак: прозрачные сроки сами по себе могут ускорить ощущение скорости разработки. Исследований в ИТ на эту тему пока не проводилось, поэтому скажите в комментариях, что думаете — бьется ли мой метод с вашим восприятием? Как вы сообщаете бизнесу сроки и контролируете его ощущения?
Почему мы ВСЕГДА ошибаемся в сроках?
Ты когда-нибудь сталкивался с ситуацией, когда проект сорвал дедлайн, даже несмотря на все подстраховки? Это случается постоянно.
Люди не умеют точно оценивать задачи — об этом написаны сотни статей и книг. Но оценивать их все равно приходится. Причем не просто так, а так, чтобы реально укладываться в сроки.
И вот тут начинается самое интересное.
🚗 Почему даже простая оценка дороги до работы сложнее, чем кажется?
Возьмем простой пример.
Допустим, моя дорога до работы занимает 60 минут. Это если пробки средние и ничего не случилось.
Но если меня попросят дать оценку, я не скажу «60 минут». Почему? Потому что:
- Сильные пробки — +10 минут
- Перекрытие дорог — +10 минут
А если мне нужно назвать время, в которое я гарантированно уложусь? Тогда:
- Пробитое колесо — +20 минут
- Первый снег в Москве — +20 минут
В итоге выходит уже 120 минут — в два раза больше!
👨💻 Почему в IT-проектах происходит то же самое?
Когда мы оцениваем задачу в IT, мы тоже учитываем непредвиденные обстоятельства. Задача могла бы занять 4 дня? Добавляем подстраховку → получается 6 или 8 дней.
Почему так?
- Разработчик обжегся на прошлом проекте и теперь перестраховывается.
- Мы знаем, что форс-мажоры случаются.
- Мы хотим попасть в срок, а значит, лучше перебдеть, чем недобдеть.
В итоге, каждую задачу переоценивают → каждая подстраховка накапливается → проект вместо месяца занимает квартал.
Но проблема не только в этом.
🤦 Как мы сами разбазариваем время?
Подстраховка почти никогда не используется по назначению. Как она расходуется?
- Задача занимает ВСЕ время, что на нее выделено — если дали 3 дня, но справились за 2, оставшийся день потратим на «полировку».
- Синдром студента — раз у нас много времени, мы не торопимся. Мы знаем, что успеем, так что откладываем до последнего (как с курсовыми).
Получается парадокс: подстраховка должна помогать нам укладываться в сроки, но она же и создает задержки!
🧨 Почему проект ВСЕ РАВНО опаздывает?
Мы завышаем оценки → проект становится длиннее, чем нужно.
Подстраховка почти всегда используется (но не по назначению).
И когда рано или поздно одна из задач начинается опаздывать, подстраховка из других задач ей не поможет. Опоздание ОДНОЙ задачи тянет за собой ВСЕ следующие.
Как итог, что бы мы ни делали, сроки все равно срываются. Знакомая ситуация, да?
Я специально не буду давать решение в этом посте.
Мне интересно:
❓ Согласны ли вы с тем, что мы всегда завышаем оценки?
❓ Как у вас принято бороться с этой проблемой?
❓ Оцениваете ли вы задачи без подстраховки?
А в следующем посте расскажу, как предлагает решать этот вопрос Элияху Голдратт.
// Если пост был полезен, поделитесь им — так вы помогаете развитию канала. Спасибо!
Ты когда-нибудь сталкивался с ситуацией, когда проект сорвал дедлайн, даже несмотря на все подстраховки? Это случается постоянно.
Люди не умеют точно оценивать задачи — об этом написаны сотни статей и книг. Но оценивать их все равно приходится. Причем не просто так, а так, чтобы реально укладываться в сроки.
И вот тут начинается самое интересное.
🚗 Почему даже простая оценка дороги до работы сложнее, чем кажется?
Возьмем простой пример.
Допустим, моя дорога до работы занимает 60 минут. Это если пробки средние и ничего не случилось.
Но если меня попросят дать оценку, я не скажу «60 минут». Почему? Потому что:
- Сильные пробки — +10 минут
- Перекрытие дорог — +10 минут
А если мне нужно назвать время, в которое я гарантированно уложусь? Тогда:
- Пробитое колесо — +20 минут
- Первый снег в Москве — +20 минут
В итоге выходит уже 120 минут — в два раза больше!
👨💻 Почему в IT-проектах происходит то же самое?
Когда мы оцениваем задачу в IT, мы тоже учитываем непредвиденные обстоятельства. Задача могла бы занять 4 дня? Добавляем подстраховку → получается 6 или 8 дней.
Почему так?
- Разработчик обжегся на прошлом проекте и теперь перестраховывается.
- Мы знаем, что форс-мажоры случаются.
- Мы хотим попасть в срок, а значит, лучше перебдеть, чем недобдеть.
В итоге, каждую задачу переоценивают → каждая подстраховка накапливается → проект вместо месяца занимает квартал.
Но проблема не только в этом.
🤦 Как мы сами разбазариваем время?
Подстраховка почти никогда не используется по назначению. Как она расходуется?
- Задача занимает ВСЕ время, что на нее выделено — если дали 3 дня, но справились за 2, оставшийся день потратим на «полировку».
- Синдром студента — раз у нас много времени, мы не торопимся. Мы знаем, что успеем, так что откладываем до последнего (как с курсовыми).
Получается парадокс: подстраховка должна помогать нам укладываться в сроки, но она же и создает задержки!
🧨 Почему проект ВСЕ РАВНО опаздывает?
Мы завышаем оценки → проект становится длиннее, чем нужно.
Подстраховка почти всегда используется (но не по назначению).
И когда рано или поздно одна из задач начинается опаздывать, подстраховка из других задач ей не поможет. Опоздание ОДНОЙ задачи тянет за собой ВСЕ следующие.
Как итог, что бы мы ни делали, сроки все равно срываются. Знакомая ситуация, да?
Я специально не буду давать решение в этом посте.
Мне интересно:
❓ Согласны ли вы с тем, что мы всегда завышаем оценки?
❓ Как у вас принято бороться с этой проблемой?
❓ Оцениваете ли вы задачи без подстраховки?
А в следующем посте расскажу, как предлагает решать этот вопрос Элияху Голдратт.
// Если пост был полезен, поделитесь им — так вы помогаете развитию канала. Спасибо!
Как сделать так, чтобы разработчики не завышали оценку задач?
⬅️ Совершите shift left
Прямо сейчас у нас в Циане я активнее сдвигаю разработку "влево" — то есть поближе в discovery. Это и есть shift left.
Так разработчики лучше понимают фичу, зачем мы ее пилим и как ее реализовать потом в коде сервиса. Задают вопросы по ходу discovery, следят за развитием мысли продакта и так далее.
Если же ваши разработчики получают требования откуда-то из черного ящика и в discovery не вовлекаются, они по-любому будут пытаться перестраховаться. Вы ведь просите их оценить что-то, что они видят в первый или второй раз в жизни.
⏳ Создайте буфер
Чтобы люди меньше пытались перестраховаться, заложите буфер на опоздания в конце квартала. Например, когда я планировал проекты, я всегда делал дату релиза ровно за один спринт до дедлайна. Таким образом, у нас всегда оставался спринт на то, чтобы порешать какие-то зависшие проблемы или нагнать отставание.
При этом в остальных, рабочих спринтах, я исключал перестраховку. Перестраховка уже заложена в конце квартала, нечего туда лезть внутри спринта.
🥊 Челленджите оценки
Это самый тяжелый, но в то же время самый простой способ. Легкий он потому что требует лишь одного вопроса, "а чо так долго?". Тяжелый — потому что его бывает непросто задавать.
Стесняться челленджить оценку — это критически плохо, потому что если оценка излишне высокая, вы просто потратите лишнее время зря. А могли бы потратить на другую задачу, на которую времени в итоге у вас может не хватить.
Но мне спрашивать было легко. Я — менеджер "от станка" и лет десять писал код каждый день. Поэтому когда я стал тимлидом, практически на любую оценку задачи я мог ответить, что сделал бы задачу в полтора-два раза быстрее.
Это — другая крайность, не делайте так. Потому что очень уж высок риск услышать в ответ на ваше "да я эту задачу за пару дней бы сделал" ответ "ну вот бери и делай тогда".
‼️ Выводы
- Совершите shift left — погрузитесь в продукт и фичи
- Создайте буфер — единый для всего проекта, а не несколько маленьких для каждой задачи
- Челленджите оценки — не стесняйтесь, но и борщить тут нельзя
Есть еще способы, но эти три — самые действенные для меня. А какие вы используете в своей работе?
⬅️ Совершите shift left
Прямо сейчас у нас в Циане я активнее сдвигаю разработку "влево" — то есть поближе в discovery. Это и есть shift left.
Так разработчики лучше понимают фичу, зачем мы ее пилим и как ее реализовать потом в коде сервиса. Задают вопросы по ходу discovery, следят за развитием мысли продакта и так далее.
Если же ваши разработчики получают требования откуда-то из черного ящика и в discovery не вовлекаются, они по-любому будут пытаться перестраховаться. Вы ведь просите их оценить что-то, что они видят в первый или второй раз в жизни.
⏳ Создайте буфер
Чтобы люди меньше пытались перестраховаться, заложите буфер на опоздания в конце квартала. Например, когда я планировал проекты, я всегда делал дату релиза ровно за один спринт до дедлайна. Таким образом, у нас всегда оставался спринт на то, чтобы порешать какие-то зависшие проблемы или нагнать отставание.
При этом в остальных, рабочих спринтах, я исключал перестраховку. Перестраховка уже заложена в конце квартала, нечего туда лезть внутри спринта.
🥊 Челленджите оценки
Это самый тяжелый, но в то же время самый простой способ. Легкий он потому что требует лишь одного вопроса, "а чо так долго?". Тяжелый — потому что его бывает непросто задавать.
Стесняться челленджить оценку — это критически плохо, потому что если оценка излишне высокая, вы просто потратите лишнее время зря. А могли бы потратить на другую задачу, на которую времени в итоге у вас может не хватить.
Но мне спрашивать было легко. Я — менеджер "от станка" и лет десять писал код каждый день. Поэтому когда я стал тимлидом, практически на любую оценку задачи я мог ответить, что сделал бы задачу в полтора-два раза быстрее.
Это — другая крайность, не делайте так. Потому что очень уж высок риск услышать в ответ на ваше "да я эту задачу за пару дней бы сделал" ответ "ну вот бери и делай тогда".
‼️ Выводы
- Совершите shift left — погрузитесь в продукт и фичи
- Создайте буфер — единый для всего проекта, а не несколько маленьких для каждой задачи
- Челленджите оценки — не стесняйтесь, но и борщить тут нельзя
Есть еще способы, но эти три — самые действенные для меня. А какие вы используете в своей работе?
Эмпатия без требовательности — путь к плохому менеджменту
В книге "Радикальная прямота" увидел интересный фреймворк, решил, что должен с вами им поделиться. Сам фреймворк представлен на картинке выше: это график с двумя измерениями:
- Эмпатия (личный интерес) — насколько "по-человечески" вы относитесь к человеку, которому даете обратную связь, насколько вам важны его эмоции
- Требовательность (жесткие требования) — насколько четко вы выделяете, что хотите от человека и подсвечиваете его несоответствие требованиям
Отсюда вытекает четыре типа менеджмента. Разберем каждый тип на примере ситуации: ваш сотрудник завершил большую задачу, но результаты весьма средние. Есть сильные стороны, например, глубина проработки архитектуры. Есть слабые — не попал в сроки и проблемы с багами.
🕹 Манипулятивная неискренность (эмпатия — нет, требовательность — нет)
Если по-простому, вам феноменально безразличен и человек, и его эмоции, и требовать от него вы ничего не хотите.
В таком случае, вы похвалите человека за завершенную задачу, чтобы остаться в рамках социальной нормы. И все. Никакой обратной связи. Просто отмашка "норм, работай дальше".
С такими руководителями я не работал еще ни разу; и вам, если честно, не советовал бы. Даже нормального результата они вряд ли достигнут.
🤬 Оскорбительная агрессивность (эмпатия — нет, требовательность — да)
Такой руководитель укажет на абсолютно все слабые стороны результата в самой понятной и простой форме. Главное намерение — донести мысль до сотрудника, а не беспокоиться о чувствах человека.
Если вы спросите подчиненных оскорбительно-агрессивного руководителя, вам ответят, что он "выжимает" их досуха. Но результат обеспечивает; правда, ценой морального состояния коллектива.
🍨 Разрушительное сочувствие (эмпатия — да, требовательность — нет)
Этот тип укажет на все сильные стороны решения, но постарается как можно меньше и без подробностей говорить о слабых. Либо упомянет слабые стороны решения, но вскользь и в очень мягких формулировках.
К сожалению, шансов достичь результата у такого руководителя меньше, чем у оскорбительно-агрессивного. Причина проста: если вы явно не укажете человеку на его ошибки и не сделаете акцент, что такая ошибка — это плохо и надо ее исправить, то ошибки исправляться и не будут.
Из-за желания быть "экологичным" такой руководитель не позволяет расти и развиваться своим подчиненным. Наоборот, они убеждены, что выполняют свою работу великолепно, ведь лидер их всегда хвалит.
📏 Радикальная прямота (эмпатия — да, требовательность — да)
Такой руководитель постарается подобрать слова, чтобы сообщить человеку все как есть: подсветить и сильные, и слабые стороны его работы.
В отличие от оскорбительно-агрессивного, он подсветит слабые места с заботой о чувствах сотрудника.
В отличие от разрушительно-сочувственного, он укажет на точки роста без лишней словесной мишуры и сглаживания углов.
‼️ Вывод
Я стараюсь быть радикально откровенным и избегаю разрушительного сочувствия. Со временем радикальная прямота входит в привычку и уже не понимаешь, как можно по-другому. Сотрудники тоже привыкают и сами начинают использовать радикальную прямоту.
Главное — хорошо разобраться в проблеме и не спешить с выводами: радикальная прямота подразумевает акцент в том числе на слабых сторонах, поэтому нужно быть уверенным, что вы правильно выделили эти слабые стороны.
Но мне вот что интересно: если бы вы выбирали между руководителем типа "оскорбительная агрессия" и "разрушительное сочувствие", что бы вы выбрали?
В книге "Радикальная прямота" увидел интересный фреймворк, решил, что должен с вами им поделиться. Сам фреймворк представлен на картинке выше: это график с двумя измерениями:
- Эмпатия (личный интерес) — насколько "по-человечески" вы относитесь к человеку, которому даете обратную связь, насколько вам важны его эмоции
- Требовательность (жесткие требования) — насколько четко вы выделяете, что хотите от человека и подсвечиваете его несоответствие требованиям
Отсюда вытекает четыре типа менеджмента. Разберем каждый тип на примере ситуации: ваш сотрудник завершил большую задачу, но результаты весьма средние. Есть сильные стороны, например, глубина проработки архитектуры. Есть слабые — не попал в сроки и проблемы с багами.
🕹 Манипулятивная неискренность (эмпатия — нет, требовательность — нет)
Если по-простому, вам феноменально безразличен и человек, и его эмоции, и требовать от него вы ничего не хотите.
В таком случае, вы похвалите человека за завершенную задачу, чтобы остаться в рамках социальной нормы. И все. Никакой обратной связи. Просто отмашка "норм, работай дальше".
С такими руководителями я не работал еще ни разу; и вам, если честно, не советовал бы. Даже нормального результата они вряд ли достигнут.
Такой руководитель укажет на абсолютно все слабые стороны результата в самой понятной и простой форме. Главное намерение — донести мысль до сотрудника, а не беспокоиться о чувствах человека.
Если вы спросите подчиненных оскорбительно-агрессивного руководителя, вам ответят, что он "выжимает" их досуха. Но результат обеспечивает; правда, ценой морального состояния коллектива.
Этот тип укажет на все сильные стороны решения, но постарается как можно меньше и без подробностей говорить о слабых. Либо упомянет слабые стороны решения, но вскользь и в очень мягких формулировках.
К сожалению, шансов достичь результата у такого руководителя меньше, чем у оскорбительно-агрессивного. Причина проста: если вы явно не укажете человеку на его ошибки и не сделаете акцент, что такая ошибка — это плохо и надо ее исправить, то ошибки исправляться и не будут.
Из-за желания быть "экологичным" такой руководитель не позволяет расти и развиваться своим подчиненным. Наоборот, они убеждены, что выполняют свою работу великолепно, ведь лидер их всегда хвалит.
📏 Радикальная прямота (эмпатия — да, требовательность — да)
Такой руководитель постарается подобрать слова, чтобы сообщить человеку все как есть: подсветить и сильные, и слабые стороны его работы.
В отличие от оскорбительно-агрессивного, он подсветит слабые места с заботой о чувствах сотрудника.
В отличие от разрушительно-сочувственного, он укажет на точки роста без лишней словесной мишуры и сглаживания углов.
‼️ Вывод
Я стараюсь быть радикально откровенным и избегаю разрушительного сочувствия. Со временем радикальная прямота входит в привычку и уже не понимаешь, как можно по-другому. Сотрудники тоже привыкают и сами начинают использовать радикальную прямоту.
Главное — хорошо разобраться в проблеме и не спешить с выводами: радикальная прямота подразумевает акцент в том числе на слабых сторонах, поэтому нужно быть уверенным, что вы правильно выделили эти слабые стороны.
Но мне вот что интересно: если бы вы выбирали между руководителем типа "оскорбительная агрессия" и "разрушительное сочувствие", что бы вы выбрали?
Please open Telegram to view this post
VIEW IN TELEGRAM
Нет более верного способа испортить себе дела на работе, чем говорить "да" на каждую влетающую вам просьбу. Ну например:
- Можешь плиз посмотреть задачку быстренько? Там недолго, но мне прям очень надо, завтра релиз!
- Добавь пожалуйста в API вот эту ручку, мне для задачи не хватает, а взять ее могут только в следующем спринте, не могу ждать.
Ну и так далее. Знакомо? Соглашались? Тогда читайте дальше.
🦁 Зачем мы соглашаемся?
Очень просто: мы — социальные животные, и мы очень хотим быть в хороших отношениях с социумом вокруг нас. Это эволюционный механизм: люди, которые портили с социумом отношения, в большинстве своем не выжили и свои гены дальше не передали. Причин тому много: и саблезубые тигры, и различные виды мамонта.
Например, если неудачливый охотник-собиратель сломает себе на охоте ногу, его выживание целиком зависит от того, насколько к нему расположено племя. Если человек постоянно отказывался помочь коллегам по родо-племенному строю, вряд ли его будут подкармливать.
Поэтому наше подсознание говорим нам: соглашайся, сделай коллеге доброе дело, и тогда он сделает доброе дело тебе. Ситуация вин-вин! Тогда, в случае чего, с тобой поделятся мамонтом и ты не помрешь. Это называется "реципрокность" — наша склонность отвечать хорошим на хорошее.
⏳ А где здесь проблема?
Вот где: наше время в сутках жестко ограничено: 24 часа, из которых на работу желательно тратить часов 10-12 максимум. Многие скажут, что лучше даже поменьше. Время — невосполняемый ресурс, которым вы должны распоряжаться ответственно и инвестировать его только в важные и нужные дела.
Проблема в том, что каждое "да" отъедает кусок вашего рабочего времени. Плюс у вас есть свои рабочие задачи, в которые тоже нужно инвестировать время.
И самое главное: по ощущениям сказать "да" и согласится инвестировать время не стоит нам ни копейки времени! Ведь когда мы говорим да, мы не платим своим временем сразу. Мы выдаем сами себе кредит, который придется гасить чуть-чуть попозже, когда придет время реально выполнять работу.
Поэтому мы и говорим "да": в моменте нам это ничего не стоит, но дает ощущение, что социум нам если что подкинет кусок мамонта, если станет туго.
◀️ Обратный эффект
Рано или поздно человек, который на все говорит "да", влезает в долги: инвестирует больше времени, чем у него есть. А потом приходит время платить по этому кредиту, но выясняется, что платить нечем: мы помним, что время в сутках конечно.
Поэтому часть просьб либо отклоняется, либо делается тяп-ляп, по принципу "лишь бы отстали". Оба варианта очень плохи: человек рассчитывает на вас, строит свои планы исходя из того, что вы выполните его просьбу в срок. Вместо этого, он получает либо плохой результат, либо не получает его вообще.
В результате, вместо повышения социального одобрения и образа отзывчивого человека, мы получаем разочарованного коллегу, который вряд ли поделился бы с нами куском мамонта. Это и есть обратный эффект "да".
Самое интересное: если бы мы просто сказали "нет", эффект был бы гораздо позитивнее. Возможно, в моменте, коллега бы немного на нас подулся, но в целом — вряд ли вспомнил бы про этот отказ через пару дней. В конце-концов, отказы это просто часть нашей жизни и мы не заносим их в свою книгу обид. Правда же?
‼️ Что делать?
Не нужно отказывать всем во всех просьбах — тогда работа встанет во всей компании. Помогать коллегам важно и нужно, но внимательно рассчитывайте свою способность платить по тому кредиту, который создаст данное вами согласие. Тогда все получится как надо: вы и работе компании поможете, и вам не откажут в вашей просьбе спустя время.
А вы попадали в ситуации, где набрали слишком много кредитов на свое время? Поделитесь своей историей в комментариях! 🙂
- Можешь плиз посмотреть задачку быстренько? Там недолго, но мне прям очень надо, завтра релиз!
- Добавь пожалуйста в API вот эту ручку, мне для задачи не хватает, а взять ее могут только в следующем спринте, не могу ждать.
Ну и так далее. Знакомо? Соглашались? Тогда читайте дальше.
🦁 Зачем мы соглашаемся?
Очень просто: мы — социальные животные, и мы очень хотим быть в хороших отношениях с социумом вокруг нас. Это эволюционный механизм: люди, которые портили с социумом отношения, в большинстве своем не выжили и свои гены дальше не передали. Причин тому много: и саблезубые тигры, и различные виды мамонта.
Например, если неудачливый охотник-собиратель сломает себе на охоте ногу, его выживание целиком зависит от того, насколько к нему расположено племя. Если человек постоянно отказывался помочь коллегам по родо-племенному строю, вряд ли его будут подкармливать.
Поэтому наше подсознание говорим нам: соглашайся, сделай коллеге доброе дело, и тогда он сделает доброе дело тебе. Ситуация вин-вин! Тогда, в случае чего, с тобой поделятся мамонтом и ты не помрешь. Это называется "реципрокность" — наша склонность отвечать хорошим на хорошее.
⏳ А где здесь проблема?
Вот где: наше время в сутках жестко ограничено: 24 часа, из которых на работу желательно тратить часов 10-12 максимум. Многие скажут, что лучше даже поменьше. Время — невосполняемый ресурс, которым вы должны распоряжаться ответственно и инвестировать его только в важные и нужные дела.
Проблема в том, что каждое "да" отъедает кусок вашего рабочего времени. Плюс у вас есть свои рабочие задачи, в которые тоже нужно инвестировать время.
И самое главное: по ощущениям сказать "да" и согласится инвестировать время не стоит нам ни копейки времени! Ведь когда мы говорим да, мы не платим своим временем сразу. Мы выдаем сами себе кредит, который придется гасить чуть-чуть попозже, когда придет время реально выполнять работу.
Поэтому мы и говорим "да": в моменте нам это ничего не стоит, но дает ощущение, что социум нам если что подкинет кусок мамонта, если станет туго.
◀️ Обратный эффект
Рано или поздно человек, который на все говорит "да", влезает в долги: инвестирует больше времени, чем у него есть. А потом приходит время платить по этому кредиту, но выясняется, что платить нечем: мы помним, что время в сутках конечно.
Поэтому часть просьб либо отклоняется, либо делается тяп-ляп, по принципу "лишь бы отстали". Оба варианта очень плохи: человек рассчитывает на вас, строит свои планы исходя из того, что вы выполните его просьбу в срок. Вместо этого, он получает либо плохой результат, либо не получает его вообще.
В результате, вместо повышения социального одобрения и образа отзывчивого человека, мы получаем разочарованного коллегу, который вряд ли поделился бы с нами куском мамонта. Это и есть обратный эффект "да".
Самое интересное: если бы мы просто сказали "нет", эффект был бы гораздо позитивнее. Возможно, в моменте, коллега бы немного на нас подулся, но в целом — вряд ли вспомнил бы про этот отказ через пару дней. В конце-концов, отказы это просто часть нашей жизни и мы не заносим их в свою книгу обид. Правда же?
‼️ Что делать?
Не нужно отказывать всем во всех просьбах — тогда работа встанет во всей компании. Помогать коллегам важно и нужно, но внимательно рассчитывайте свою способность платить по тому кредиту, который создаст данное вами согласие. Тогда все получится как надо: вы и работе компании поможете, и вам не откажут в вашей просьбе спустя время.
А вы попадали в ситуации, где набрали слишком много кредитов на свое время? Поделитесь своей историей в комментариях! 🙂
Если у вас не взлетает Scrum, достаточно лишь...
Институт Исследования Scrum выпустил исследование, которое поможет вам внедрить Scrum, даже если команда сопротивляется.
Представляю вам Принципы Итеративных Постоянных Ежедневных Централизованных решений.
1️⃣ Давите авторитетом
Напоминайте команде, что решение о внедрении Скрам было принято на самом высоком уровне. Если кто-то против, пусть говорит со своим менеджером. Таким образом, вы избежите дискуссии и укрепите вертикаль власти в компании.
"Скрам — не мое решение, руководство так решило. Свои возражения ты можешь выразить руководителю."
2️⃣ Уберите ретроспективы
Ретроспективы скатываются в идеологические дебаты. Если инженеры не могут конструктивно спорить, но только атакуют идею Скрама, ваш единственный выход — заморозить практику ретроспектив. Пока инженеры не согласятся со Скрамом, вам придется отнять у них возможность пользоваться плюшками Скрама и устранять огрехи в нем.
"Ретроспектива — это бонус, а не стандарт. На данный момент я считаю, что команда не готова к ним."
3️⃣ Закрутите гайки
Безусловное следование практикам Скрама возможно лишь под вашим контролем. Без четкого следования практикам, прогресса не будет. Например, вы можете начать делать так:
- Проводите все Скрам-встречи самостоятельно, не доверяйте никому другому вести даже дейлики. Не подрывайте ваш авторитет.
- Усильте контроль с помощью инструментов: добавьте больше обязательных полей в Джиру, чтобы команда четко следовала процессам. Да, это скучно, но работа и не должна быть веселой.
- Детально проработайте Definition of Done: опишите все максиально подробно, превратите в чеклист и заставьте всех неукоснительно следовать ему.
Постоянство — ключ к успеху. Сама возможность сделать что-то не так вызовет мысль, что с идеями Скрам можно спорить. Избегайте подобных ситуаций.
4️⃣ Удерживайте контроль
Вы — владелец Скрам, и лишь ваши решения приведут команду в мир выполненных спринтов и качественной доставкой ценности. Например:
- Не допускайте дебатов. Избегайте споров с инженерами. Ваша коммуникация должна быть короткой и четкой, без возможности интерпретаций. Вы — командир, так что отдавайте приказы. А приказы не обсуждаются.
- Оставайтесь невозмутимым. Если что-то пошло не по плану или возникла очевидная проблема со Скрамом, удалитесь из беседы. "Простите, мне пора не следующую встречу" — отличная фраза, чтобы не потерять лицо перед инженерами.
5️⃣ Эскалируйте
Если возражения продолжают поступать, предложите эскалировать их вверх по цепочке. Помните про вертикаль власти в компании. Например:
- Предложите обратиться к HR или менеджменту. Четко коммуницируйте, что ваша работа состоит во внедрении решений, которые уже принял менеджмент. Вы внедряете лучшие стандарты индустрии, их приняли тысячи компаний по всему миру.
- Рассматривайте проблемы обезличенно. "Мы не говорим о чьем-то мнении, мы следуем общим, универсальным стандартам". Устраняйте личные мнения, принуждайте к следованию лучшим практикам.
‼️ Итоги
Предложенные выше решения могут показаться вам слишком суровыми. Это нормально. Иногда необходимо быть твердым, потому что Скрам может быть внедрен только тогда, когда вы следуете букве и духу Скрам гайда. Со временем инженеры привыкнут и даже начнут уважать ту дисциплину и следование правилам, которые вы внедрили.
А до тех пор, оставайтесь твердыми, непоколебимыми и не допускайте никаких дискуссий.
Что скажете — станете ли вы сторонником ПИПЕЦ (Принципы Итеративных Постоянных Ежедневных Централизованных) решений?
Оригинал статьи
Институт Исследования Scrum выпустил исследование, которое поможет вам внедрить Scrum, даже если команда сопротивляется.
Представляю вам Принципы Итеративных Постоянных Ежедневных Централизованных решений.
1️⃣ Давите авторитетом
Напоминайте команде, что решение о внедрении Скрам было принято на самом высоком уровне. Если кто-то против, пусть говорит со своим менеджером. Таким образом, вы избежите дискуссии и укрепите вертикаль власти в компании.
"Скрам — не мое решение, руководство так решило. Свои возражения ты можешь выразить руководителю."
2️⃣ Уберите ретроспективы
Ретроспективы скатываются в идеологические дебаты. Если инженеры не могут конструктивно спорить, но только атакуют идею Скрама, ваш единственный выход — заморозить практику ретроспектив. Пока инженеры не согласятся со Скрамом, вам придется отнять у них возможность пользоваться плюшками Скрама и устранять огрехи в нем.
"Ретроспектива — это бонус, а не стандарт. На данный момент я считаю, что команда не готова к ним."
3️⃣ Закрутите гайки
Безусловное следование практикам Скрама возможно лишь под вашим контролем. Без четкого следования практикам, прогресса не будет. Например, вы можете начать делать так:
- Проводите все Скрам-встречи самостоятельно, не доверяйте никому другому вести даже дейлики. Не подрывайте ваш авторитет.
- Усильте контроль с помощью инструментов: добавьте больше обязательных полей в Джиру, чтобы команда четко следовала процессам. Да, это скучно, но работа и не должна быть веселой.
- Детально проработайте Definition of Done: опишите все максиально подробно, превратите в чеклист и заставьте всех неукоснительно следовать ему.
Постоянство — ключ к успеху. Сама возможность сделать что-то не так вызовет мысль, что с идеями Скрам можно спорить. Избегайте подобных ситуаций.
4️⃣ Удерживайте контроль
Вы — владелец Скрам, и лишь ваши решения приведут команду в мир выполненных спринтов и качественной доставкой ценности. Например:
- Не допускайте дебатов. Избегайте споров с инженерами. Ваша коммуникация должна быть короткой и четкой, без возможности интерпретаций. Вы — командир, так что отдавайте приказы. А приказы не обсуждаются.
- Оставайтесь невозмутимым. Если что-то пошло не по плану или возникла очевидная проблема со Скрамом, удалитесь из беседы. "Простите, мне пора не следующую встречу" — отличная фраза, чтобы не потерять лицо перед инженерами.
5️⃣ Эскалируйте
Если возражения продолжают поступать, предложите эскалировать их вверх по цепочке. Помните про вертикаль власти в компании. Например:
- Предложите обратиться к HR или менеджменту. Четко коммуницируйте, что ваша работа состоит во внедрении решений, которые уже принял менеджмент. Вы внедряете лучшие стандарты индустрии, их приняли тысячи компаний по всему миру.
- Рассматривайте проблемы обезличенно. "Мы не говорим о чьем-то мнении, мы следуем общим, универсальным стандартам". Устраняйте личные мнения, принуждайте к следованию лучшим практикам.
‼️ Итоги
Предложенные выше решения могут показаться вам слишком суровыми. Это нормально. Иногда необходимо быть твердым, потому что Скрам может быть внедрен только тогда, когда вы следуете букве и духу Скрам гайда. Со временем инженеры привыкнут и даже начнут уважать ту дисциплину и следование правилам, которые вы внедрили.
А до тех пор, оставайтесь твердыми, непоколебимыми и не допускайте никаких дискуссий.
Что скажете — станете ли вы сторонником ПИПЕЦ (Принципы Итеративных Постоянных Ежедневных Централизованных) решений?
Оригинал статьи
У вас есть право на ошибку. И вы обязаны им пользоваться.
Понедельник — лучшее время, чтобы вспомнить: «Мы можем ошибаться». Даже не так — мы имеем право ошибаться! И мы будем ошибаться.
Но ведь ошибаться неприятно и даже больно? Правда. Рэй Далио писал: «Рост это боль плюс рефлексия», и по этой формуле ваш личный рост без совершения ошибок невозможен.
Венчурные инвесторы вообще считают, что если вы не совершаете ошибок в инвестировании, вы просто выбрали плохую стратегию. Ошибка — это не страшно, отсутствие ошибок это плохо. Потому что там, где нет ошибок, нет прогресса и роста.
Чем выше мы целимся, тем больше вероятность ошибки. Цельтесь высоко, но умно: не забывайте про диверсификацию рисков. Ставить все на красное это не стратегия, это азарт.
Понедельник — лучшее время, чтобы вспомнить: «Мы можем ошибаться». Даже не так — мы имеем право ошибаться! И мы будем ошибаться.
Но ведь ошибаться неприятно и даже больно? Правда. Рэй Далио писал: «Рост это боль плюс рефлексия», и по этой формуле ваш личный рост без совершения ошибок невозможен.
Венчурные инвесторы вообще считают, что если вы не совершаете ошибок в инвестировании, вы просто выбрали плохую стратегию. Ошибка — это не страшно, отсутствие ошибок это плохо. Потому что там, где нет ошибок, нет прогресса и роста.
Чем выше мы целимся, тем больше вероятность ошибки. Цельтесь высоко, но умно: не забывайте про диверсификацию рисков. Ставить все на красное это не стратегия, это азарт.
Президент США принял решение о депортации целых пяти языков программирования!
Проверьте, возможно, Трамп решил выслать из США и ваш любимый язык. Что тогда будете делать?
Поделитесь с коллегами — вдруг их любимый язык уже пересекает границу с Мексикой?
Проверьте, возможно, Трамп решил выслать из США и ваш любимый язык. Что тогда будете делать?
Поделитесь с коллегами — вдруг их любимый язык уже пересекает границу с Мексикой?