Игра победителя
Давайте сегодня чуть-чуть отвлечемся от процессов, ИТ и всякого. Я вот люблю игры, особенно МОВА, особенно доту. Играю я редко, но постоянно замечаю нюанс: все члены моей команды пытаются победить... И из-за этого проигрывают. Да-да, именно так: люди проигрывают, потому что стараются выиграть. Я не сошел с ума: дайте мне буквально пару минут, и я все объясню.
Ученый Саймон Рамо проанализировал тысячи теннисных матчей игроков всех уровней, от начинающих до звезд. Саймон старался понять, почему одни игроки побеждают чаще других.
Открытие его поразило. Оказалось, что новички и любители играют в принципиально другой теннис. Если в профессиональном теннисе побеждает игрок, который забил больше мячей, то в играх классом ниже побеждает тот, кто меньше пропустил. Саймон пошел еще дальше и свел все к выводу: "В профессиональном теннисе 80% игр выигрываются, а в любительском те же 80% проигрываются."
Игрой победителя Саймон назвал те матчи, где исход решил игрок, который забил больше мячей. Матчи, где победителем стал тот, кто меньше пропустил, Саймон назвал игрой проигравшего.
И под конец еще один парадокс: чем больше любитель старается победить, тем больше он фокусируется на победных действиях и тем больше любительских ошибок допускает, ведь его внимание заключено в победных действиях. Если бы вместо этого он старался бы избегать ошибок, шансов победить у него бы прибавилось.
Аналогий с работой избежать не получится. Я часто вижу, как начинающие тимлиды, проджекты и продакты пытаются сыграть в игру победителя: отойти от лучших практик, закостылить свой фреймворк, срезать углы, которые лучше не срезать... Иными словами, я вижу, как игроки-любители играют в игру победителя и совершают ошибки, из-за чего срывают себе проекты.
В доте и любых онлайн играх все то же самое. Если вы не профи и не тратите 8 часов в день на теннис или доту, предпочтите игру проигравшего и минимизируйте количество ошибок. Так вы начнете побеждать чаще.
Если интересно прочитать подробнее, вот книга Саймона
Давайте сегодня чуть-чуть отвлечемся от процессов, ИТ и всякого. Я вот люблю игры, особенно МОВА, особенно доту. Играю я редко, но постоянно замечаю нюанс: все члены моей команды пытаются победить... И из-за этого проигрывают. Да-да, именно так: люди проигрывают, потому что стараются выиграть. Я не сошел с ума: дайте мне буквально пару минут, и я все объясню.
Ученый Саймон Рамо проанализировал тысячи теннисных матчей игроков всех уровней, от начинающих до звезд. Саймон старался понять, почему одни игроки побеждают чаще других.
Открытие его поразило. Оказалось, что новички и любители играют в принципиально другой теннис. Если в профессиональном теннисе побеждает игрок, который забил больше мячей, то в играх классом ниже побеждает тот, кто меньше пропустил. Саймон пошел еще дальше и свел все к выводу: "В профессиональном теннисе 80% игр выигрываются, а в любительском те же 80% проигрываются."
Игрой победителя Саймон назвал те матчи, где исход решил игрок, который забил больше мячей. Матчи, где победителем стал тот, кто меньше пропустил, Саймон назвал игрой проигравшего.
И под конец еще один парадокс: чем больше любитель старается победить, тем больше он фокусируется на победных действиях и тем больше любительских ошибок допускает, ведь его внимание заключено в победных действиях. Если бы вместо этого он старался бы избегать ошибок, шансов победить у него бы прибавилось.
Аналогий с работой избежать не получится. Я часто вижу, как начинающие тимлиды, проджекты и продакты пытаются сыграть в игру победителя: отойти от лучших практик, закостылить свой фреймворк, срезать углы, которые лучше не срезать... Иными словами, я вижу, как игроки-любители играют в игру победителя и совершают ошибки, из-за чего срывают себе проекты.
В доте и любых онлайн играх все то же самое. Если вы не профи и не тратите 8 часов в день на теннис или доту, предпочтите игру проигравшего и минимизируйте количество ошибок. Так вы начнете побеждать чаще.
Если интересно прочитать подробнее, вот книга Саймона
Salve, patricii!
В блоге я уже говорил о стиле управлении Хидэеси, императора-крестьянина Японии. Сегодня мы перенесемся еще дальше во времени и начнем разговор об управлении в Римской Империи.
Нам поможет Марк Сидоний Фалкс — патриций, который написал трактат об управлении рабами. Нам повезло, что трактат выжил спустя две тысячи лет и был переведен плебеем Джерри Тонером — за что мы говорим ему спасибо и жалуем сотни серебряных сестерциев. Если надумаете его поддержать, приобретайте его книгу "Как управлять рабами".
Марк Сидоний Фалкс владел сотнями рабов, то есть управлял очень большой компанией. Коллектив был пестрый: все-таки, рабов в Империю поставляли со всех уголков Pax Romana. Вы увидите, что Марк вполне сносно относился к своим сотрудникам и рекомендовал остальным вести себя так же. Он задавался примерно теми же вопросами, что и текущие менеджеры: возможно, вас удивит, насколько они похожи на ваши собственные вопросы.
И не читайте эту серию постов на слишком уж серьезных щах. Abeamus!
В блоге я уже говорил о стиле управлении Хидэеси, императора-крестьянина Японии. Сегодня мы перенесемся еще дальше во времени и начнем разговор об управлении в Римской Империи.
Нам поможет Марк Сидоний Фалкс — патриций, который написал трактат об управлении рабами. Нам повезло, что трактат выжил спустя две тысячи лет и был переведен плебеем Джерри Тонером — за что мы говорим ему спасибо и жалуем сотни серебряных сестерциев. Если надумаете его поддержать, приобретайте его книгу "Как управлять рабами".
Марк Сидоний Фалкс владел сотнями рабов, то есть управлял очень большой компанией. Коллектив был пестрый: все-таки, рабов в Империю поставляли со всех уголков Pax Romana. Вы увидите, что Марк вполне сносно относился к своим сотрудникам и рекомендовал остальным вести себя так же. Он задавался примерно теми же вопросами, что и текущие менеджеры: возможно, вас удивит, насколько они похожи на ваши собственные вопросы.
И не читайте эту серию постов на слишком уж серьезных щах. Abeamus!
Как выбрать раба
Давайте поговорим о римском найме. Точнее — о покупке раба.
Марк Сидоний Фалкс пишет, что вопрос покупки нельзя переоценить. Если ошибиться с рабом на стадии покупки, потом придется потратить в разы больше усилий, чтобы он вышел на нужный уровень производительности.
Прежде всего Марк отмечает, что покупка раба — само по себе не лучшее решение. Лучшие, самые лояльные рабы, получаются их тех, кто был рожден и выращен в доме владельца. Найм — то есть покупка — приходится к месту тогда, когда вырастить нет возможности. Люди ведь не растут на деревьях.
Марк поначалу не дает четких рекомендаций, каких рабов стоит приобретать. Вместо этого он рекомендует спросить себя вопрос: что ты собираешься построить? Если скульптор намеревается создать великое произведение, ему нужна подходящая глина. Для простенькой статуи сойдет глина подешевле. Так же и с рабами: для гладиатора или раба-спутника нужен совершенно особенный материал, а для сборщика винограда подойдет почти любой.
Потом Марк дает несколько простых советов:
- Заранее определите работу, которую будет выполнять раб. Исходя из его должности, составьте список требований и с ним идите на рынок.
- Избегайте грустных. Они заразят своим унынием весь коллектив, отчего упадет и дисциплина, и желание работать.
- Не покупайте рабов без нужды. В книге Марк приводит примеры рабов, которые были куплены напрасно, без четких целей. Такое расточительство вредит кошельку.
- Не покупайте рабов с общим бэкграундом, которые говорят на одном языке. Такие рабы будут тратить больше времени на разговоры, меньше — на работу. А если они достаточно подружатся, смогут решиться на совместный побег.
Вот и все советы, которые патриций дает в своем трактате. Лично я вижу в этом несколько пересечений с нашей реальностью. Если видите и вы, то добро пожаловать в комментарии!
Давайте поговорим о римском найме. Точнее — о покупке раба.
Марк Сидоний Фалкс пишет, что вопрос покупки нельзя переоценить. Если ошибиться с рабом на стадии покупки, потом придется потратить в разы больше усилий, чтобы он вышел на нужный уровень производительности.
Прежде всего Марк отмечает, что покупка раба — само по себе не лучшее решение. Лучшие, самые лояльные рабы, получаются их тех, кто был рожден и выращен в доме владельца. Найм — то есть покупка — приходится к месту тогда, когда вырастить нет возможности. Люди ведь не растут на деревьях.
Марк поначалу не дает четких рекомендаций, каких рабов стоит приобретать. Вместо этого он рекомендует спросить себя вопрос: что ты собираешься построить? Если скульптор намеревается создать великое произведение, ему нужна подходящая глина. Для простенькой статуи сойдет глина подешевле. Так же и с рабами: для гладиатора или раба-спутника нужен совершенно особенный материал, а для сборщика винограда подойдет почти любой.
Потом Марк дает несколько простых советов:
- Заранее определите работу, которую будет выполнять раб. Исходя из его должности, составьте список требований и с ним идите на рынок.
- Избегайте грустных. Они заразят своим унынием весь коллектив, отчего упадет и дисциплина, и желание работать.
- Не покупайте рабов без нужды. В книге Марк приводит примеры рабов, которые были куплены напрасно, без четких целей. Такое расточительство вредит кошельку.
- Не покупайте рабов с общим бэкграундом, которые говорят на одном языке. Такие рабы будут тратить больше времени на разговоры, меньше — на работу. А если они достаточно подружатся, смогут решиться на совместный побег.
Вот и все советы, которые патриций дает в своем трактате. Лично я вижу в этом несколько пересечений с нашей реальностью. Если видите и вы, то добро пожаловать в комментарии!
Как добиться максимума от рабов
Salve, patricii! Я продолжаю рассказывать вам о римском менеджменте, и сегодня мы поговорим о повышении эффективности рабов. Но прежде, чем мы начнем, рекомендую прочитать комментарии к прошлому посту: тот случай, когда комментарий не уступает статье.
Применяйте грубую силу, наказывайте, запугивайте — от Марка Сидония я ждал любых советов. Все-таки, нравы в Древнем Риме были пожестче, чем наши с вами. Но вместо этой жести Марк первым делом советует: не забывайте о прянике! "Жестокость это палка о двух концах, и больнее всего она попадает по хозяину, а не рабу" пишет Марк. Он считает, что опытного управленца отличает понимание, что одним кнутом нельзя добиться успехов.
В первую очередь, раба нужно обучить. Марк Сидоний не утруждает себя объяснением процесса обучения, но из двух параграфов понятно: он имеет в виду онбординг. На этапе онбординга раба знакомят с будущей работой, коллективом, обязанностями и ответственностями.
Важно определить для раба четкую долгосрочную цель. Чаще всего для трудолюбие и усердность рабу с Древнем Риме даровали свободу: держать раба в неволе до его смерти считалось моветоном. За успехи в работе нужно давать выходные дни и улучшать бытовые условия раба. Марк Сидоний считал неприемлемой ситуацию, в которой раб-трудоголик и раб-бездельник живут в одних и тех же условиях и едят одну и ту же пищу.
Нужно определить для каждого раба его обязанности. За каждую работу отвечает определенный раб и он это знает. Если к вечеру трава будет не скошена, все знают, чья эта провинность. Если же скошена хорошо — чье достижение. Здесь Марк еще раз подчеркивает, что если раб трудится усердно, его труд не должен уходить в "общую копилку".
Рабов следует объединить в группы не слишком большие, но и не слишком маленькие. Если группа большая, ей будет сложно управлять, ответственность начнет размазываться. Идеальный размер группы — 5-10 человек. Такие группы нужно разбросать по всему имению и следить за тем, чтобы рабы не работали поодиночке или по два-три человека.
Марк считал, что у рабов должен быть и досуг. Ему была противна идея Катона, что раб должен лишь спать и работать. Марк был уверен, что хороший отдых вечером повышает эффективность труда днем.
Вдумайтесь: это советы рабовладельца! Поощрять рабов, давать им отдых, следить за выгоранием — в современном мире я знаю руководителей, которые лихо забивают на все эти нюансы и заставляют людей работать на износ. Поэтому впервые за серию я дам вам свой совет: если вы управляете коллективом менее гуманно, чем рабовладелец, вам пора задуматься о ваших решениях и подходах. Правда.
А на этом на сегодня у меня все. В следующий раз я расскажу, как Марк Сидоний Фалкс рекомендует выбирать управляющих из числа рабов. Если вам понравилось, то репост станет для меня самой приятной оценкой.
Salve, patricii! Я продолжаю рассказывать вам о римском менеджменте, и сегодня мы поговорим о повышении эффективности рабов. Но прежде, чем мы начнем, рекомендую прочитать комментарии к прошлому посту: тот случай, когда комментарий не уступает статье.
Применяйте грубую силу, наказывайте, запугивайте — от Марка Сидония я ждал любых советов. Все-таки, нравы в Древнем Риме были пожестче, чем наши с вами. Но вместо этой жести Марк первым делом советует: не забывайте о прянике! "Жестокость это палка о двух концах, и больнее всего она попадает по хозяину, а не рабу" пишет Марк. Он считает, что опытного управленца отличает понимание, что одним кнутом нельзя добиться успехов.
В первую очередь, раба нужно обучить. Марк Сидоний не утруждает себя объяснением процесса обучения, но из двух параграфов понятно: он имеет в виду онбординг. На этапе онбординга раба знакомят с будущей работой, коллективом, обязанностями и ответственностями.
Важно определить для раба четкую долгосрочную цель. Чаще всего для трудолюбие и усердность рабу с Древнем Риме даровали свободу: держать раба в неволе до его смерти считалось моветоном. За успехи в работе нужно давать выходные дни и улучшать бытовые условия раба. Марк Сидоний считал неприемлемой ситуацию, в которой раб-трудоголик и раб-бездельник живут в одних и тех же условиях и едят одну и ту же пищу.
Нужно определить для каждого раба его обязанности. За каждую работу отвечает определенный раб и он это знает. Если к вечеру трава будет не скошена, все знают, чья эта провинность. Если же скошена хорошо — чье достижение. Здесь Марк еще раз подчеркивает, что если раб трудится усердно, его труд не должен уходить в "общую копилку".
Рабов следует объединить в группы не слишком большие, но и не слишком маленькие. Если группа большая, ей будет сложно управлять, ответственность начнет размазываться. Идеальный размер группы — 5-10 человек. Такие группы нужно разбросать по всему имению и следить за тем, чтобы рабы не работали поодиночке или по два-три человека.
Марк считал, что у рабов должен быть и досуг. Ему была противна идея Катона, что раб должен лишь спать и работать. Марк был уверен, что хороший отдых вечером повышает эффективность труда днем.
Вдумайтесь: это советы рабовладельца! Поощрять рабов, давать им отдых, следить за выгоранием — в современном мире я знаю руководителей, которые лихо забивают на все эти нюансы и заставляют людей работать на износ. Поэтому впервые за серию я дам вам свой совет: если вы управляете коллективом менее гуманно, чем рабовладелец, вам пора задуматься о ваших решениях и подходах. Правда.
А на этом на сегодня у меня все. В следующий раз я расскажу, как Марк Сидоний Фалкс рекомендует выбирать управляющих из числа рабов. Если вам понравилось, то репост станет для меня самой приятной оценкой.
У Римской Империи не было недостатка в новых рабах. Плутарх пишет, что война Юлия Цезаря в Галлии принесла Риму один миллион новых рабов за восемь лет. Это 125 тысяч рабов каждый год только с одного театра военных действий, на деле их было больше. Современные ученые считают, что до 20% населения всей Империи были рабами.
Но соотношение пять граждан на одного раба не работало. В городской среде это соотношение было ниже, ведь в городах находилось больше граждан и меньше рабов. А в сельской местности, там, где возделывались поля и производилось всякое, соотношение менялось в пользу рабов. Бывало и так, что в имении кроме хозяйской семьи и рабов никто не проживал.
Если сложить эти два пункта, получается вот такое:
- Рабов в имениях было много
- Управленцев не хватало
- Эпизодически происходил бурный рост числа рабов.
Если заменить рабов на сотрудников, получается почти правильное определение гипер-роста: это время, когда компания вырастает в разы или даже в десятки раз.
Сейчас я расскажу, как Марк Сидоний Фалкс предлагал выживать во времена такого бурного роста.
Марк рекомендовал не искать управляющих на стороне. Конечно, управляющий из числа рабов ничего не стоил, но это не было решающим плюсом. Марк считал, что такой управляющий уже хорошо знает хозяйство, привык общаться с хозяином, выучил язык (подавляющее число рабов было не из Италии). Чтобы выбрать управляющего из числа рабов, Марк рекомендовал обращать внимание на следующее:
- Назначьте человека опытного, который давно работает в поле. В современных реалиях я бы сказал так: менеджер должен быть от станка. Я не верю в тимлидов разработки, которые не писали код. Я и в СТО не-программиста не очень верю. Марк вообще считает, что лучший способ для управляющего добиться авторитета -- это делать свою работу лучше всех.
- Никогда не назначайте раба, который "склонен тратить время впустую, гоняясь за городскими удовольствиями". Уже спорно для наших реалий, но Марк имел в виду склонность к вредным привычкам. Если утрировать, то не стоит нанимать человека, который потенциально может напороться во вторник днем и весь день быть не на связи.
- Слишком молодому рабу будет сложно командовать более взрослыми, потому что его не будут воспринимать всерьез. В современном мире все так: поставьте тимлида 20-ти лет в команду опытных дядек за 40 и убедитесь сами, что это плохая идея.
Для эффективной работы управляющего Марк рекомендовал:
- Не давайте управляющему жить или есть отдельно от коллектива. Цитата: "ничто так не раздражает усталого раба, как созерцание начальника работ, поглощающего вкусную еду, когда сам раб получил лишь скудный паек". Мысль глубокая, так что оставлю ее вам самим на размышление.
- Запрещайте управляющему покидать территорию имения. Кажется, что неприменимо к нашей с вами реальности, но нет -- еще как применимо. Замените "территорию имения" на "скоуп работ". Если человек берется за все сразу, это плохо.
- Внушите управляющему, что он знает совсем мало. Хороший управляющий постоянно учится. Забавно, но сейчас (последние N лет) все говорят о learning mindset, так вот Марк Сидоний Фалкс изобрел его две тысячи лет назад.
- Не пускайте в имение магов и волшебников. В современном мире волшебники -- это сомнительные практики, которые обещают повысить эффективность работы всего лишь за семь простых шагов. Или фреймворки, у которых три звезды на гитхабе.
Но соотношение пять граждан на одного раба не работало. В городской среде это соотношение было ниже, ведь в городах находилось больше граждан и меньше рабов. А в сельской местности, там, где возделывались поля и производилось всякое, соотношение менялось в пользу рабов. Бывало и так, что в имении кроме хозяйской семьи и рабов никто не проживал.
Если сложить эти два пункта, получается вот такое:
- Рабов в имениях было много
- Управленцев не хватало
- Эпизодически происходил бурный рост числа рабов.
Если заменить рабов на сотрудников, получается почти правильное определение гипер-роста: это время, когда компания вырастает в разы или даже в десятки раз.
Сейчас я расскажу, как Марк Сидоний Фалкс предлагал выживать во времена такого бурного роста.
Марк рекомендовал не искать управляющих на стороне. Конечно, управляющий из числа рабов ничего не стоил, но это не было решающим плюсом. Марк считал, что такой управляющий уже хорошо знает хозяйство, привык общаться с хозяином, выучил язык (подавляющее число рабов было не из Италии). Чтобы выбрать управляющего из числа рабов, Марк рекомендовал обращать внимание на следующее:
- Назначьте человека опытного, который давно работает в поле. В современных реалиях я бы сказал так: менеджер должен быть от станка. Я не верю в тимлидов разработки, которые не писали код. Я и в СТО не-программиста не очень верю. Марк вообще считает, что лучший способ для управляющего добиться авторитета -- это делать свою работу лучше всех.
- Никогда не назначайте раба, который "склонен тратить время впустую, гоняясь за городскими удовольствиями". Уже спорно для наших реалий, но Марк имел в виду склонность к вредным привычкам. Если утрировать, то не стоит нанимать человека, который потенциально может напороться во вторник днем и весь день быть не на связи.
- Слишком молодому рабу будет сложно командовать более взрослыми, потому что его не будут воспринимать всерьез. В современном мире все так: поставьте тимлида 20-ти лет в команду опытных дядек за 40 и убедитесь сами, что это плохая идея.
Для эффективной работы управляющего Марк рекомендовал:
- Не давайте управляющему жить или есть отдельно от коллектива. Цитата: "ничто так не раздражает усталого раба, как созерцание начальника работ, поглощающего вкусную еду, когда сам раб получил лишь скудный паек". Мысль глубокая, так что оставлю ее вам самим на размышление.
- Запрещайте управляющему покидать территорию имения. Кажется, что неприменимо к нашей с вами реальности, но нет -- еще как применимо. Замените "территорию имения" на "скоуп работ". Если человек берется за все сразу, это плохо.
- Внушите управляющему, что он знает совсем мало. Хороший управляющий постоянно учится. Забавно, но сейчас (последние N лет) все говорят о learning mindset, так вот Марк Сидоний Фалкс изобрел его две тысячи лет назад.
- Не пускайте в имение магов и волшебников. В современном мире волшебники -- это сомнительные практики, которые обещают повысить эффективность работы всего лишь за семь простых шагов. Или фреймворки, у которых три звезды на гитхабе.
А еще у меня для вас есть 2 (два!) бесплатных билета на https://podlodka.io/techcrew. Я там буду выступать, расскажу про пост мортемы, инцидент менеджмент и как вообще увидеть 99.95% на метрике доступности системы.
Чтобы принять участие в розыгрыше, нужно оставить коммент к этой записи. Вообще любой коммент, но если напишите отзыв о контенте, что нравится, чего не хватает, я буду очень рад :)
Двух победителей выберет рандом 14-го числа (пятница). Не реклама — Подлодка дает 2 билета спикеру, их мы и разыгрываем.
Чтобы принять участие в розыгрыше, нужно оставить коммент к этой записи. Вообще любой коммент, но если напишите отзыв о контенте, что нравится, чего не хватает, я буду очень рад :)
Двух победителей выберет рандом 14-го числа (пятница). Не реклама — Подлодка дает 2 билета спикеру, их мы и разыгрываем.
podlodka.io
Онлайн-конференция Podlodka Teсhlead Crew #9
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам techlead-разработки, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
Билеты мы разыграли, но пятничный контент у меня для вас еще есть :) "Микросервисы: проблемы, которые мы не замечаем" — это 40 минут (+вопросы) полезной инфы о сервисах. В программе:
- Что такое контракты, где их хранить и как катить
- Как построить стейджи в распределенной системе
- Зачем нужен Circuit Breaker и Rate Limiter
- Бонусом небольшой заход в отказоустойчивость
И еще многое другое. Наверное, этот доклад съел у меня больше всего времени среди прочих.
https://www.youtube.com/watch?v=VtlS8ETYXvc&ab_channel=TechLeadChannel
- Что такое контракты, где их хранить и как катить
- Как построить стейджи в распределенной системе
- Зачем нужен Circuit Breaker и Rate Limiter
- Бонусом небольшой заход в отказоустойчивость
И еще многое другое. Наверное, этот доклад съел у меня больше всего времени среди прочих.
https://www.youtube.com/watch?v=VtlS8ETYXvc&ab_channel=TechLeadChannel
Что делать, если дел стало слишком много
Привет всем, кто задолбался. Вы когда-нибудь ощущали совокупность этих прекрасных эмоций?
- Пока делаешь одну задачу, вспоминаешь про другую, третью, десятую — ощущение, что 24 часа в сутках слишком мало для твоей работы
- Новые задачи появляются быстрее, чем делаются старые
- Дедлайны горят, задачи не делаются
- Изо дня в день ситуация становится только хуже
Я в ней провел пару месяцев. Отсюда и пустота в этом блоге. В моем личном трекере запись "написать в блог статью" висела больше месяца и переносилась каждый вечер на следующий день, вместе с другими задачами.
Ужасное ощущение.
И это с учетом, что я выполнял все методики управления временем! Исправно вел и веду список своих задач, планирую день и неделю, не скроллю телеграм. Не помогает. Поэтому я решил, что нехватка времени и есть норма. И вообще, у какого-нибудь Безоса времени еще меньше.
Неделю назад мне попалась на глаза избитая временем фраза "если вы оказались в яме, первое, что вам нужно сделать — перестать копать". Меня осенило — это же про меня! Я в яме, факт. Ситуация становится хуже, значит, я продолжаю копать. Но что такое "копать" в моей ситуации?
Если вас завалило делами, копать — это соглашаться на новые дела. Этим я и занимался: когда кто-то просил помочь или что-то сделать, я с радостью соглашался, потому что я люблю помогать людям... Но вообще нет. Вот основные причины, почему мы любим отвечать "да":
- Говорить "да" просто приятнее и легче.
- Хотим выглядеть командными игроками. В корпоративной культуре это важно.
- Боимся не понравится. Говорить "нет" не так выгодно, если ты хочешь поддерживать хорошие отношения со всеми вокруг.
- Хотим попробовать что-то новое. Даже если ты загружен работой, возможность получить опыт работы с какой-нибудь новинкой может пересилить.
- Не понимаем масштаба задачи. Задача на пять минут легко оборачивается засадой на пару часов или весь день.
- Ищем социального одобрения. Желание быть для всех хорошим парнем и поддерживать горизонтальные связи ценится в коллективе.
Что делать? Начинать говорить нет. Будет непросто, поэтому вот пару советов:
- Не соглашаться ни на что сразу. Можно взять время на подумать, перезвонить или пообещать написать ответ позже. Не очень хороший способ, потому что если решил отказать, лучше отказать сразу. Быстрый отказ — проявление уважения к времени партнера.
- Не соглашаться, потому что хочется. Любое "да" должно вести человека к цели. Если "да" не приближает человека к целям, оно отодвигает от них.
tl; dr желание постоянно соглашаться и говорить "да" — токсичная штука, которая может похоронить вас в делах и задачах. Лучше говорите "нет". Вот хорошая статья из моих закладок на эту тему.
А статьи теперь вернутся обратно. Про рабов момент упущен, так что перейдем к следующей теме — моей любимой компании, которая делает лучшие процессы и лучшие машины.
Привет всем, кто задолбался. Вы когда-нибудь ощущали совокупность этих прекрасных эмоций?
- Пока делаешь одну задачу, вспоминаешь про другую, третью, десятую — ощущение, что 24 часа в сутках слишком мало для твоей работы
- Новые задачи появляются быстрее, чем делаются старые
- Дедлайны горят, задачи не делаются
- Изо дня в день ситуация становится только хуже
Я в ней провел пару месяцев. Отсюда и пустота в этом блоге. В моем личном трекере запись "написать в блог статью" висела больше месяца и переносилась каждый вечер на следующий день, вместе с другими задачами.
Ужасное ощущение.
И это с учетом, что я выполнял все методики управления временем! Исправно вел и веду список своих задач, планирую день и неделю, не скроллю телеграм. Не помогает. Поэтому я решил, что нехватка времени и есть норма. И вообще, у какого-нибудь Безоса времени еще меньше.
Неделю назад мне попалась на глаза избитая временем фраза "если вы оказались в яме, первое, что вам нужно сделать — перестать копать". Меня осенило — это же про меня! Я в яме, факт. Ситуация становится хуже, значит, я продолжаю копать. Но что такое "копать" в моей ситуации?
Если вас завалило делами, копать — это соглашаться на новые дела. Этим я и занимался: когда кто-то просил помочь или что-то сделать, я с радостью соглашался, потому что я люблю помогать людям... Но вообще нет. Вот основные причины, почему мы любим отвечать "да":
- Говорить "да" просто приятнее и легче.
- Хотим выглядеть командными игроками. В корпоративной культуре это важно.
- Боимся не понравится. Говорить "нет" не так выгодно, если ты хочешь поддерживать хорошие отношения со всеми вокруг.
- Хотим попробовать что-то новое. Даже если ты загружен работой, возможность получить опыт работы с какой-нибудь новинкой может пересилить.
- Не понимаем масштаба задачи. Задача на пять минут легко оборачивается засадой на пару часов или весь день.
- Ищем социального одобрения. Желание быть для всех хорошим парнем и поддерживать горизонтальные связи ценится в коллективе.
Что делать? Начинать говорить нет. Будет непросто, поэтому вот пару советов:
- Не соглашаться ни на что сразу. Можно взять время на подумать, перезвонить или пообещать написать ответ позже. Не очень хороший способ, потому что если решил отказать, лучше отказать сразу. Быстрый отказ — проявление уважения к времени партнера.
- Не соглашаться, потому что хочется. Любое "да" должно вести человека к цели. Если "да" не приближает человека к целям, оно отодвигает от них.
tl; dr желание постоянно соглашаться и говорить "да" — токсичная штука, которая может похоронить вас в делах и задачах. Лучше говорите "нет". Вот хорошая статья из моих закладок на эту тему.
А статьи теперь вернутся обратно. Про рабов момент упущен, так что перейдем к следующей теме — моей любимой компании, которая делает лучшие процессы и лучшие машины.
Почему позитивный опыт не так важен
Я настороженно отношусь к чужим историям успеха. Не всегда из них можно извлечь что-то полезное. В худшем случае, попытка повторить чужую историю успеха может мне навредить.
Например, пусть Вася прочитал биографию Оззи Осборна -- он как раз такую написал, называется "Все, что мне удалось вспомнить". Вы можете подумать, теперь у Васи есть пошаговый рецепт, как стать рок-звездой. Но если Вася попытается по шагам повторить все действия Оззи Осборна, он не станет рок-звездой, это очевидно. Вероятнее, Вася просто откинет копыта от передоза: маэстро употреблял феноменальное количество веществ, запрещенных к обороту на территории РФ.
Мысль понятна: если повторить по шагам историю успеха Оззи, самому рок-звездой не стать. Это так не работает. Чужая история успеха не воспроизводится. Оззи жил в другое время, в другом месте, по телевизору шли другие новости, по дорогам ездили другие машины. Истории успеха часто зависят от контекста, а без контекста история успеха теряет воспроизводимость. Знание "как надо" сложно перенести на себя и свой контекст.
Если перенести эту идею на наше ИТ, получается вот что:
- Если у кого-то взлетел SCRUM и ему похорошело, это не значит, что вам нужен SCRUM
- Если кто-то перешел с PG на MongoDB, не факт, что вам оно надо
- Правила управления Netflix применимы только в рамках Netflix, если вы бездумно затащите их к себе, можете навредить
- И так далее
Мысли кажется очевидные, но почему-то попытки "построить иерархию как у Spotify" совершаются с поражающей частотой. И закономерно плохим итогом.
С другой стороны, есть истории провала. Их редко выставляют напоказ, о них не пишут книги и стараются побыстрее забыть. Но такие истории содержат в себе ошибки, которые и привели автора к провалу. Это и есть знание "как не надо". Оно менее зависимо от контекста, а потому более ценно.
Например, между докладами "как мы построили иерархию Spotify у себя в компании" и "как у нас не получилось построить модель Spotify" я выберу последний. Если докладчик расскажет про свои ошибки, то я не буду их повторять и повышу свои шансы на успех, если вдруг надумаю затащить модель Spotify к себе. А вот если я буду повторять чужую историю успеха без чужого контекста, то сам смогу выступить с докладом о факапе.
Итак: получить негативный опыт более ценно, чем получить позитивный опыт. Это не значит, что истории успеха вообще бесполезны. Это не так. Просто предпочтение я был отдавал опыту провалов.
А если вы захотите послушать про чужие факапы, регайтесь на нашу конфу Fuckup Meetup'22. 14-го Декабря мы соберемся оффлайн и онлайн и послушаем пять прекрасных историй про факапы :) Я буду ведущим, но если успею, тоже что-нибудь расскажу из последних факапов.
P.S. У нас на ютубе и запись с прошлого митапа есть. Вот мой рассказ про NASA, шаттлы и мистическое исчезновение всей базы данных утром субботы.
Я настороженно отношусь к чужим историям успеха. Не всегда из них можно извлечь что-то полезное. В худшем случае, попытка повторить чужую историю успеха может мне навредить.
Например, пусть Вася прочитал биографию Оззи Осборна -- он как раз такую написал, называется "Все, что мне удалось вспомнить". Вы можете подумать, теперь у Васи есть пошаговый рецепт, как стать рок-звездой. Но если Вася попытается по шагам повторить все действия Оззи Осборна, он не станет рок-звездой, это очевидно. Вероятнее, Вася просто откинет копыта от передоза: маэстро употреблял феноменальное количество веществ, запрещенных к обороту на территории РФ.
Мысль понятна: если повторить по шагам историю успеха Оззи, самому рок-звездой не стать. Это так не работает. Чужая история успеха не воспроизводится. Оззи жил в другое время, в другом месте, по телевизору шли другие новости, по дорогам ездили другие машины. Истории успеха часто зависят от контекста, а без контекста история успеха теряет воспроизводимость. Знание "как надо" сложно перенести на себя и свой контекст.
Если перенести эту идею на наше ИТ, получается вот что:
- Если у кого-то взлетел SCRUM и ему похорошело, это не значит, что вам нужен SCRUM
- Если кто-то перешел с PG на MongoDB, не факт, что вам оно надо
- Правила управления Netflix применимы только в рамках Netflix, если вы бездумно затащите их к себе, можете навредить
- И так далее
Мысли кажется очевидные, но почему-то попытки "построить иерархию как у Spotify" совершаются с поражающей частотой. И закономерно плохим итогом.
С другой стороны, есть истории провала. Их редко выставляют напоказ, о них не пишут книги и стараются побыстрее забыть. Но такие истории содержат в себе ошибки, которые и привели автора к провалу. Это и есть знание "как не надо". Оно менее зависимо от контекста, а потому более ценно.
Например, между докладами "как мы построили иерархию Spotify у себя в компании" и "как у нас не получилось построить модель Spotify" я выберу последний. Если докладчик расскажет про свои ошибки, то я не буду их повторять и повышу свои шансы на успех, если вдруг надумаю затащить модель Spotify к себе. А вот если я буду повторять чужую историю успеха без чужого контекста, то сам смогу выступить с докладом о факапе.
Итак: получить негативный опыт более ценно, чем получить позитивный опыт. Это не значит, что истории успеха вообще бесполезны. Это не так. Просто предпочтение я был отдавал опыту провалов.
А если вы захотите послушать про чужие факапы, регайтесь на нашу конфу Fuckup Meetup'22. 14-го Декабря мы соберемся оффлайн и онлайн и послушаем пять прекрасных историй про факапы :) Я буду ведущим, но если успею, тоже что-нибудь расскажу из последних факапов.
P.S. У нас на ютубе и запись с прошлого митапа есть. Вот мой рассказ про NASA, шаттлы и мистическое исчезновение всей базы данных утром субботы.
О компании, которая делает лучшие процессы
Пришло время рассказать вам про принципы управления лучшей компании на свете, которая делает лучшие на свете машины.
БМВ и Мерседес, сядьте, вам завтра в сервис. Я про Тойоту. Первый пост будет не про принципы управления, а про историю Тойоты.
В 1965-ом году Тойота пришла на американский рынок с новой Короной. Это такой маленький автомобильчик, по-японски компактный и бережливый. Думаю, с его двигателем в 1.2 литра, автомобиль мог ездить даже на парах бензина. Просто нюхнул 95-го и поехал.
В 60-70-х годах в США автомобильный двигатель начинался литров от 3-ех, и это еще была малолитражка! Настоящие ковбои катались на пятилитровых зверях, которые жрали по 25 литров на сто километров. Иначе как-то не солидно. Но Тойоту Корону покупать все же стали: в отличие от тогдашних поделий автопрома США, Тойота могла проехать 100к километров и не сломаться. Американский автопром ломался чаще и ремонтировался дороже. Этим Тойота и начала завоевывать США.
Завоевание США продолжалось бы еще десятки лет, если бы не топливный кризис 70-х годов. Цена за баррель подскочила с 10 баксов сначала до 40, а потом до 65. Строить тачки с большими моторами стало как-то невыгодно, а строить тачки с маленькими моторами Америка не умела. Тут-то Тойота (а так же Хонда, Ниссан и все-все-все) очень быстро начали съедать рынок США. Правда, вмешалось государство и ввело заградительные пошлины, чтобы родной автопром хоть как-то выжил. В итоге Тойота была вынуждена строить заводы в США и иными способами инвестировать в местный автопром. Да-да, свободный рынок выглядит именно так, а что вы хотели?
Но это все был приквел, чтобы у вас в голове появился вопрос: как страна, вбомбленная буквально в средние века в 45-ом году, смогла основать Тойоту? Между ядерными ударами и захватом автопрома США прошло меньше 20 лет!
Ответ: бережливое производство. Понятие очень широкое, но в следующих статьях я постараюсь раскрыть его пошире.
Интересно другое: принципы бережливого производства описал великий инженер и руководитель Тайити Оно в 1977 году в своей статье "Система Оно" на английском языке. Подчеркиваю, Тайити не изобрел, а лишь описал принципы Тойоты. Позже он и книгу про принципы Тойоты выпустит.
В 88-ом году Джон Крафчик выпускает статью "Триумф системы бережливого производства", после чего слово Lean и Lean Manufacturing вообще появляется как термин. Идеи Джона вторят идеям Тайити Оно и принципам Тойоты.
В 95-ом Сазерленд и Швабер на конференции презентуют Scrum -- новую методологию управления проектами. Пишутся книги, статьи, а в 2009-ом году появляется Scrum Guide. И сам Scrum, и Scrum Guide основаны на принципах бережливого производства.
Получается, что Scrum основан на Lean, а Lean -- на принципах Тойота, которые были заложены еще в конце 19-го века. Не имею ничего против, но на мой вкус, Scrum неправильно понимает часть принципов Тойоты, а другую часть он просто игнорирует. Яркий пример: ретроспектива, тесно увязанная с понятием "хансей", которого в европейской культуре просто нет. Про хансей будет целый отдельный пост.
Пока что у меня все. В следующих постах я расскажу вам о принципах Тойоты, с которых все началось и которыми все до сих пор продолжается. Без искажений.
Пришло время рассказать вам про принципы управления лучшей компании на свете, которая делает лучшие на свете машины.
БМВ и Мерседес, сядьте, вам завтра в сервис. Я про Тойоту. Первый пост будет не про принципы управления, а про историю Тойоты.
В 1965-ом году Тойота пришла на американский рынок с новой Короной. Это такой маленький автомобильчик, по-японски компактный и бережливый. Думаю, с его двигателем в 1.2 литра, автомобиль мог ездить даже на парах бензина. Просто нюхнул 95-го и поехал.
В 60-70-х годах в США автомобильный двигатель начинался литров от 3-ех, и это еще была малолитражка! Настоящие ковбои катались на пятилитровых зверях, которые жрали по 25 литров на сто километров. Иначе как-то не солидно. Но Тойоту Корону покупать все же стали: в отличие от тогдашних поделий автопрома США, Тойота могла проехать 100к километров и не сломаться. Американский автопром ломался чаще и ремонтировался дороже. Этим Тойота и начала завоевывать США.
Завоевание США продолжалось бы еще десятки лет, если бы не топливный кризис 70-х годов. Цена за баррель подскочила с 10 баксов сначала до 40, а потом до 65. Строить тачки с большими моторами стало как-то невыгодно, а строить тачки с маленькими моторами Америка не умела. Тут-то Тойота (а так же Хонда, Ниссан и все-все-все) очень быстро начали съедать рынок США. Правда, вмешалось государство и ввело заградительные пошлины, чтобы родной автопром хоть как-то выжил. В итоге Тойота была вынуждена строить заводы в США и иными способами инвестировать в местный автопром. Да-да, свободный рынок выглядит именно так, а что вы хотели?
Но это все был приквел, чтобы у вас в голове появился вопрос: как страна, вбомбленная буквально в средние века в 45-ом году, смогла основать Тойоту? Между ядерными ударами и захватом автопрома США прошло меньше 20 лет!
Ответ: бережливое производство. Понятие очень широкое, но в следующих статьях я постараюсь раскрыть его пошире.
Интересно другое: принципы бережливого производства описал великий инженер и руководитель Тайити Оно в 1977 году в своей статье "Система Оно" на английском языке. Подчеркиваю, Тайити не изобрел, а лишь описал принципы Тойоты. Позже он и книгу про принципы Тойоты выпустит.
В 88-ом году Джон Крафчик выпускает статью "Триумф системы бережливого производства", после чего слово Lean и Lean Manufacturing вообще появляется как термин. Идеи Джона вторят идеям Тайити Оно и принципам Тойоты.
В 95-ом Сазерленд и Швабер на конференции презентуют Scrum -- новую методологию управления проектами. Пишутся книги, статьи, а в 2009-ом году появляется Scrum Guide. И сам Scrum, и Scrum Guide основаны на принципах бережливого производства.
Получается, что Scrum основан на Lean, а Lean -- на принципах Тойота, которые были заложены еще в конце 19-го века. Не имею ничего против, но на мой вкус, Scrum неправильно понимает часть принципов Тойоты, а другую часть он просто игнорирует. Яркий пример: ретроспектива, тесно увязанная с понятием "хансей", которого в европейской культуре просто нет. Про хансей будет целый отдельный пост.
Пока что у меня все. В следующих постах я расскажу вам о принципах Тойоты, с которых все началось и которыми все до сих пор продолжается. Без искажений.
Хансей
Первый принцип Тойоты это хансей. Все принципы, которые мы рассмотрим дальше, опираются на хансей. Поэтому нет смысла говорить о Тойоте, если сначала не понять смысл хансей.
Большинство книг или статей сразу заявят вам: хансей -- это рефлексия. Я скажу: нет. Хансей это не только и не столько рефлексия. Чтобы разобраться в истинном смысла слова, давайте начнем с его составляющих.
Что такое хансей
Слово "хансей" состоит из двух иероглифов: 反省.
反 (Хан) может означать противоположность, противопоставление, сомнение или отрицание. Но так же иероглиф может значит "отражать". Например, слово "反光 板" буквально означает "отражатель".
省 (Сей) имеет примерно дофига значений: сущ. провинция, глаголы оставлять или пропускать. Для нашего контекста подходит перевод "понимать" или "проверять себя".
Я перевожу хансей как "сомнение по поводу собственных действий и достижений". Хансей -- это постоянный поиск причин, которые привели к провалу или успеху. Конечно, я не переводчик и японский знаю очень условно, так что здесь на научную точность не претендую.
Почему хансей -- это не рефлексия
Первое и главное различие: рефлексия -- это разовое действие, процесс размышления над своими действиями из прошлого. Хансей -- это постоянный способ восприятия мира.
Второе: европейцы рефлексируют над провалом, но не над успехом. Даже уважаемый Рей Далио (миллиардед и автор книг про личный рост) пишет: "Успех -- это боль плюс рефлексия". Над победами у нас рефлексировать вроде не принято. Победителей не судят, говорим мы. Хансей предполагает рефлексию и над провалом, и над успехом.
Что значит хансей для Тойоты
Для Тойоты хансей это главный инструмент развития. После завершения задачи, исполнители собираются на встречу "хансей-кай", где обсудят свои действия и результаты. Цель встречи -- выяснить причины, которые привели к успеху или провалу. Если принятые решение были неудачными, их не следует повторять. Хорошие решения стоит запомнить и начать применять дальше, а в будущем, если они пройдут проверку временем, начать применять как стандарты.
Как вы можете практиковать хансей
Во-первых, задумайтесь, а надо ли оно вам. У японцев другой менталитет, у них хансей в школах преподают. Если вы начнете задумываться и даже сомневаться насчет своих достижений, может получиться не очень хорошо.
Если вы решили, что добавите хансей в свою жизнь, начните с себя. В конце дня уделите несколько минут, чтобы записать итоги дня. Что вы сделали хорошо, что вы сделали плохо, к чему все это привело и как в следующий раз сделать лучше. В идеале записать все ручкой или карандашом на бумаге, но и клавиатура сойдет.
tl;dr Каждый сотрудник Тойоты подвергает сомнениям любой успех и ищет причины любого провала, чтобы избежать его в будущем. Постоянное сомнение и поиск причин любого результата -- это и есть хансей.
Первый принцип Тойоты это хансей. Все принципы, которые мы рассмотрим дальше, опираются на хансей. Поэтому нет смысла говорить о Тойоте, если сначала не понять смысл хансей.
Большинство книг или статей сразу заявят вам: хансей -- это рефлексия. Я скажу: нет. Хансей это не только и не столько рефлексия. Чтобы разобраться в истинном смысла слова, давайте начнем с его составляющих.
Что такое хансей
Слово "хансей" состоит из двух иероглифов: 反省.
反 (Хан) может означать противоположность, противопоставление, сомнение или отрицание. Но так же иероглиф может значит "отражать". Например, слово "反光 板" буквально означает "отражатель".
省 (Сей) имеет примерно дофига значений: сущ. провинция, глаголы оставлять или пропускать. Для нашего контекста подходит перевод "понимать" или "проверять себя".
Я перевожу хансей как "сомнение по поводу собственных действий и достижений". Хансей -- это постоянный поиск причин, которые привели к провалу или успеху. Конечно, я не переводчик и японский знаю очень условно, так что здесь на научную точность не претендую.
Почему хансей -- это не рефлексия
Первое и главное различие: рефлексия -- это разовое действие, процесс размышления над своими действиями из прошлого. Хансей -- это постоянный способ восприятия мира.
Второе: европейцы рефлексируют над провалом, но не над успехом. Даже уважаемый Рей Далио (миллиардед и автор книг про личный рост) пишет: "Успех -- это боль плюс рефлексия". Над победами у нас рефлексировать вроде не принято. Победителей не судят, говорим мы. Хансей предполагает рефлексию и над провалом, и над успехом.
Что значит хансей для Тойоты
Для Тойоты хансей это главный инструмент развития. После завершения задачи, исполнители собираются на встречу "хансей-кай", где обсудят свои действия и результаты. Цель встречи -- выяснить причины, которые привели к успеху или провалу. Если принятые решение были неудачными, их не следует повторять. Хорошие решения стоит запомнить и начать применять дальше, а в будущем, если они пройдут проверку временем, начать применять как стандарты.
Как вы можете практиковать хансей
Во-первых, задумайтесь, а надо ли оно вам. У японцев другой менталитет, у них хансей в школах преподают. Если вы начнете задумываться и даже сомневаться насчет своих достижений, может получиться не очень хорошо.
Если вы решили, что добавите хансей в свою жизнь, начните с себя. В конце дня уделите несколько минут, чтобы записать итоги дня. Что вы сделали хорошо, что вы сделали плохо, к чему все это привело и как в следующий раз сделать лучше. В идеале записать все ручкой или карандашом на бумаге, но и клавиатура сойдет.
tl;dr Каждый сотрудник Тойоты подвергает сомнениям любой успех и ищет причины любого провала, чтобы избежать его в будущем. Постоянное сомнение и поиск причин любого результата -- это и есть хансей.
_Генти Генбуцу
"Мы смотрим на процесс доставки ценности и убираем из него все, что не приносит ценности" -- цитата Тайити Оно, одного из мастодонтов Тойоты. Фраза очень похожа на высказывание Микеланджело. Великого скульптора спросили, как ему удается создавать свои шедевры? Он ответил: "Я беру камень и отсекаю все лишнее".
__Как определить лишнее
Несложно убрать из процесса лишнее. Сложно лишнее найти. В нашем любимом ИТ для поиска проблем мы используем метрики. Например, для Scrum спринтов можно следить за такими циферками:
- Сколько задач осталось открытыми после завершения спринта
- Сколько задач включили в спринт после старта спринта
- Сколько задач удалили из спринта
- И так далее, циферок можно придумать еще много
Если любая из трех метрик не равна нулю, значит процессы в команде неэффективны. Где-то затесалось лишнее, которое нужно немедленно искоренить. Это правда. Подвох кроется в другом: ни одна из цифр не сообщает нам, где находится неэффективность внутри процесса. Например, команда можем выбрасывать задачи в ходе из спринта из-за факторов:
- У продакта семь пятниц на неделе и он постоянно меняет планы и задачи
- Команда не успевает сделать все таски и скидывает балласт
- Неправильно распилили эпик на задачи, пришлось выкинуть старые
- И так далее
Значит, метрика только сигнализирует о проблеме, но не указывает прямо на нее.
__Как найти лишнее
Тут и включается генти генбуцу (現地現物). Давайте для начала переведем на русский.
現地 (генти) -- местный, локальный.
現物 (генбуцу) -- реальный, настоящий.
Дословный перевод генти генбуцу -- это "реальное место". То место, где нам нужно находиться, чтобы найти лишнее в своих процессах. Сейчас объясню.
Например, Тайити Оно узнавал о проблеме: один из участков конвейера стал выдавать больше брака, чем в прошлом месяца. Тогда Тайити Оно буквально рисовал круг на полу в цеху, рядом с проблемным участком. Небольшой круг, чтобы внутри него можно было стоять, но не гулять туда-обратно.
Внутрь круга Тайити своего подчиненного и поручал следить за участком в течение нескольких часов. Человек наблюдал производственный процесс, действия рабочих и результат каждого действия. Спустя несколько часов, у него появлялось представление о реальном положении дел на участке линии. Не домыслы или предположения, а факты.
На основании собранных фактов Тайити Оно с командой принимал решения и исправлял проблему.
__Как использовать генти генбуцу в ИТ
Вернемся к примеру выше, про выброшенные из спринта задачи. Неопытный менеджер примет решение сразу же, без похода "на производство". Это неправильно. Настоящий менеджер должен начать ходить на дейли синки команд, на их PBR (или груминги), возможно устроить skip-the-level встречи. Это и есть генти генбуцу. Это путь к решению настоящей проблемы.
"Мы смотрим на процесс доставки ценности и убираем из него все, что не приносит ценности" -- цитата Тайити Оно, одного из мастодонтов Тойоты. Фраза очень похожа на высказывание Микеланджело. Великого скульптора спросили, как ему удается создавать свои шедевры? Он ответил: "Я беру камень и отсекаю все лишнее".
__Как определить лишнее
Несложно убрать из процесса лишнее. Сложно лишнее найти. В нашем любимом ИТ для поиска проблем мы используем метрики. Например, для Scrum спринтов можно следить за такими циферками:
- Сколько задач осталось открытыми после завершения спринта
- Сколько задач включили в спринт после старта спринта
- Сколько задач удалили из спринта
- И так далее, циферок можно придумать еще много
Если любая из трех метрик не равна нулю, значит процессы в команде неэффективны. Где-то затесалось лишнее, которое нужно немедленно искоренить. Это правда. Подвох кроется в другом: ни одна из цифр не сообщает нам, где находится неэффективность внутри процесса. Например, команда можем выбрасывать задачи в ходе из спринта из-за факторов:
- У продакта семь пятниц на неделе и он постоянно меняет планы и задачи
- Команда не успевает сделать все таски и скидывает балласт
- Неправильно распилили эпик на задачи, пришлось выкинуть старые
- И так далее
Значит, метрика только сигнализирует о проблеме, но не указывает прямо на нее.
__Как найти лишнее
Тут и включается генти генбуцу (現地現物). Давайте для начала переведем на русский.
現地 (генти) -- местный, локальный.
現物 (генбуцу) -- реальный, настоящий.
Дословный перевод генти генбуцу -- это "реальное место". То место, где нам нужно находиться, чтобы найти лишнее в своих процессах. Сейчас объясню.
Например, Тайити Оно узнавал о проблеме: один из участков конвейера стал выдавать больше брака, чем в прошлом месяца. Тогда Тайити Оно буквально рисовал круг на полу в цеху, рядом с проблемным участком. Небольшой круг, чтобы внутри него можно было стоять, но не гулять туда-обратно.
Внутрь круга Тайити своего подчиненного и поручал следить за участком в течение нескольких часов. Человек наблюдал производственный процесс, действия рабочих и результат каждого действия. Спустя несколько часов, у него появлялось представление о реальном положении дел на участке линии. Не домыслы или предположения, а факты.
На основании собранных фактов Тайити Оно с командой принимал решения и исправлял проблему.
__Как использовать генти генбуцу в ИТ
Вернемся к примеру выше, про выброшенные из спринта задачи. Неопытный менеджер примет решение сразу же, без похода "на производство". Это неправильно. Настоящий менеджер должен начать ходить на дейли синки команд, на их PBR (или груминги), возможно устроить skip-the-level встречи. Это и есть генти генбуцу. Это путь к решению настоящей проблемы.
Мне надоело писать сюда теорию из книг. Канал у меня "Инженер и Менеджер" называется, а не "Пересказываем лучшие практики из разных книг". Поэтому теория менеджмента останется, по как отдельный тэг: #теория_менеджмента (логично). Плюс три новых тега: про технику, прочитанные книги и фан факты. Давайте начнем с последнего.
#fun_fact
Люди любят сбиваться в группы. Групповое поведение заложено у нас в генах: чтобы выжить, нашим предкам нужно было вместе охотиться, обмениваться корешками, торговать каменными топорами и вместе бить по шапке соседние племена. Если человека отторгала его группа, он помирал и проваливал естественный отбор, так что его гены дальше не шли.
Научное доказательство
В прошлом веке Генри Тайфель задумался: какой необходимый минимум нужен толпе людей, чтобы разделиться на две группы? Чтобы вычленить минимальные условия, Генри с коллегами провел эксперимент.
Дано: группа людей разного цвета кожи, религиозных предпочтений, пола и вообще. Людей разделили на две группы, красные и синие. Потом всех людей развели по комнатам и предложили начислить условные баллы каждому участнику эксперимента. Баллы вообще ничего не значили, просто цифры.
Результаты поразили Генри: участники предпочитали ставить более высокие баллы членам своей группы! Не потребовалось ни идеологии группы, ни общих целей, вообще ничего. Чтобы люди ощутили себя группой и начали предпочитать своих (и дискриминировать чужих) надо было просто поделить их на две группы. Все.
Если вы думаете, что это случайность, то нет. Оригинальный эксперимент 1973 года повторяли многократно, в том числе уже в нашем веке. Результаты не меняются: нам, людям, настолько свойственно стремление быть в группе, что нам даже не нужны доводы. Достаточно факта наличия группы.
Кое-какие выводы
С одной стороны, это хорошо, ведь внутри группы люди лучше относятся друг к другу. С другой стороны, к людям вне группы, участники относятся хуже.
Что делать с этой информацией? Я пока задумался, если честно. Но если вы менеджерите несколько команд, наверное, вы бы хотели, чтобы все команды мнили себя единой группой, а не несколькими группами поменьше.
Оригинальное исследование
Любимая цитата: It was found that, as soon as the notion of ‚group' was introduced into the situation, the subjects still discriminated against those assigned to another random category.
Люди любят сбиваться в группы. Групповое поведение заложено у нас в генах: чтобы выжить, нашим предкам нужно было вместе охотиться, обмениваться корешками, торговать каменными топорами и вместе бить по шапке соседние племена. Если человека отторгала его группа, он помирал и проваливал естественный отбор, так что его гены дальше не шли.
Научное доказательство
В прошлом веке Генри Тайфель задумался: какой необходимый минимум нужен толпе людей, чтобы разделиться на две группы? Чтобы вычленить минимальные условия, Генри с коллегами провел эксперимент.
Дано: группа людей разного цвета кожи, религиозных предпочтений, пола и вообще. Людей разделили на две группы, красные и синие. Потом всех людей развели по комнатам и предложили начислить условные баллы каждому участнику эксперимента. Баллы вообще ничего не значили, просто цифры.
Результаты поразили Генри: участники предпочитали ставить более высокие баллы членам своей группы! Не потребовалось ни идеологии группы, ни общих целей, вообще ничего. Чтобы люди ощутили себя группой и начали предпочитать своих (и дискриминировать чужих) надо было просто поделить их на две группы. Все.
Если вы думаете, что это случайность, то нет. Оригинальный эксперимент 1973 года повторяли многократно, в том числе уже в нашем веке. Результаты не меняются: нам, людям, настолько свойственно стремление быть в группе, что нам даже не нужны доводы. Достаточно факта наличия группы.
Кое-какие выводы
С одной стороны, это хорошо, ведь внутри группы люди лучше относятся друг к другу. С другой стороны, к людям вне группы, участники относятся хуже.
Что делать с этой информацией? Я пока задумался, если честно. Но если вы менеджерите несколько команд, наверное, вы бы хотели, чтобы все команды мнили себя единой группой, а не несколькими группами поменьше.
Оригинальное исследование
Любимая цитата: It was found that, as soon as the notion of ‚group' was introduced into the situation, the subjects still discriminated against those assigned to another random category.
#articles
Про Постгрес
На собеседованиях люблю задавать вот такой вопрос:
> Представь, что в вашем Постгресе есть важная таблица с платежами. Как-то раз, к тебе приходит команда и говорит: дяденька, мы только что удалили половину платежей. Удаляли с помощью DELETE, прямо из консоли. Вопрос: что будешь делать?
Кто-то говорил "накачу дамп". Чуть более прошаренные спрашивают, есть ли реплика с отставанием. Но это все не то :) Совсем прошаренные люди по-другому. Как именно -- не скажу, мне ж еще этот вопрос на собеседовании задавать :) Но подскажу.
Чтобы так ответить правильно, неплохо было бы знать про MVCC, как Постгрес хранит данные и зачем вообще VACUUM нужен и какой он бывает. Изначально я хотел с вами поделиться списком статей на тему, но нашел на Хабре прекрасный цикл статей на русском. Вот он: https://habr.com/ru/company/postgrespro/blog/442804/.
Читать абсолютно точно стоит всем, кто использует ПГ. Тем более все на русском. Если осилите целиком, то я даже не знаю, как потом вас можно завалить по теории Постгреса на собеседовании. Никак, наверное. Автору серии низкий поклон, очень подробно получилось.
Про Постгрес
На собеседованиях люблю задавать вот такой вопрос:
> Представь, что в вашем Постгресе есть важная таблица с платежами. Как-то раз, к тебе приходит команда и говорит: дяденька, мы только что удалили половину платежей. Удаляли с помощью DELETE, прямо из консоли. Вопрос: что будешь делать?
Кто-то говорил "накачу дамп". Чуть более прошаренные спрашивают, есть ли реплика с отставанием. Но это все не то :) Совсем прошаренные люди по-другому. Как именно -- не скажу, мне ж еще этот вопрос на собеседовании задавать :) Но подскажу.
Чтобы так ответить правильно, неплохо было бы знать про MVCC, как Постгрес хранит данные и зачем вообще VACUUM нужен и какой он бывает. Изначально я хотел с вами поделиться списком статей на тему, но нашел на Хабре прекрасный цикл статей на русском. Вот он: https://habr.com/ru/company/postgrespro/blog/442804/.
Читать абсолютно точно стоит всем, кто использует ПГ. Тем более все на русском. Если осилите целиком, то я даже не знаю, как потом вас можно завалить по теории Постгреса на собеседовании. Никак, наверное. Автору серии низкий поклон, очень подробно получилось.
Хабр
MVCC-1. Изоляция
Привет, Хабр! Этой статьей я начинаю серию циклов (или цикл серий? в общем, задумка грандиозная) о внутреннем устройстве PostgreSQL. Материал будет основан на у...
Про Кафку
Судя по реакциям, посты вида "вопросы с собеседований" вам зашли. Не вижу повода не продолжить :)
На прошлом месте работы мы втаскивали Кафку рядом с кроликом (RabbitMQ). Мне понравились гарантии доставки Кафки, возможность перечитать топик и философия pull'а сообщений. То есть Кролик буквально ЗАПИХИВАЕТ сообщения в потребителя, даже если в него -- потребителя -- уже откровенно ничего не лезет. Это все равно что в вас после хорошего обеда попытаются запихнуть еще один обед. Неприятно ведь. Кафка более обходительная и позволяет потребителю читать сообщения по мере доступности.
// А еще один коллега придумал шутку, которая меня до сих пор веселит. Когда кто-то говорил "Кафка", он быстро добавлял "грефневая". Не знаю как вам, мне было (и до сих пор) смешно :)
У нас в Сбермаркете мы Кафку тоже используем, и на собеседованиях любим про нее поговорить. Один из первых моих вопросов: "Расскажи плиз про гарантии доставки Кафки".
Вы подумали, что это простой вопрос?
Нет.
Многие люди, которые работали с Кафкой в продакшне, на него не отвечают. Оставим этот факт на их совести. Правильный ответ: at-least-once. То есть: Кафка гарантирует доставку МИНИМУМ один раз, но так же гарантирует, что может доставить сообщение повторно. Если вы не учли этот момент в проектировании системы, на высоких нагрузках у вас появится очень интересный способ проводить вечера в попытках найти баг в распределенной системе.
А еще я для вас нашел статью, в которой есть картиночки и есть заход в идемпотентность. И объясняет автор хорошо. Делюсь: https://medium.com/@andy.bryant/processing-guarantees-in-kafka-12dd2e30be0e
(Кстати, если вас вдруг недавно на собесе завалили или удивили каким-нибудь вопросом, можете написать в комменты или мне в телегу. Разберу вопрос и напишу пост в канал.)
P.S. Если совсем докопаться, правильный ответ "а какие настройки у брокера, потребителя и продьюсера?". Кафка может работать в нескольких режимах доставки, нужно смотреть настройки. Из коробки у нее почти at-least-once. Почему "почти" я расскажу, но в следующих постах, все в один не залезет.
Судя по реакциям, посты вида "вопросы с собеседований" вам зашли. Не вижу повода не продолжить :)
На прошлом месте работы мы втаскивали Кафку рядом с кроликом (RabbitMQ). Мне понравились гарантии доставки Кафки, возможность перечитать топик и философия pull'а сообщений. То есть Кролик буквально ЗАПИХИВАЕТ сообщения в потребителя, даже если в него -- потребителя -- уже откровенно ничего не лезет. Это все равно что в вас после хорошего обеда попытаются запихнуть еще один обед. Неприятно ведь. Кафка более обходительная и позволяет потребителю читать сообщения по мере доступности.
// А еще один коллега придумал шутку, которая меня до сих пор веселит. Когда кто-то говорил "Кафка", он быстро добавлял "грефневая". Не знаю как вам, мне было (и до сих пор) смешно :)
У нас в Сбермаркете мы Кафку тоже используем, и на собеседованиях любим про нее поговорить. Один из первых моих вопросов: "Расскажи плиз про гарантии доставки Кафки".
Вы подумали, что это простой вопрос?
Нет.
Многие люди, которые работали с Кафкой в продакшне, на него не отвечают. Оставим этот факт на их совести. Правильный ответ: at-least-once. То есть: Кафка гарантирует доставку МИНИМУМ один раз, но так же гарантирует, что может доставить сообщение повторно. Если вы не учли этот момент в проектировании системы, на высоких нагрузках у вас появится очень интересный способ проводить вечера в попытках найти баг в распределенной системе.
А еще я для вас нашел статью, в которой есть картиночки и есть заход в идемпотентность. И объясняет автор хорошо. Делюсь: https://medium.com/@andy.bryant/processing-guarantees-in-kafka-12dd2e30be0e
(Кстати, если вас вдруг недавно на собесе завалили или удивили каким-нибудь вопросом, можете написать в комменты или мне в телегу. Разберу вопрос и напишу пост в канал.)
P.S. Если совсем докопаться, правильный ответ "а какие настройки у брокера, потребителя и продьюсера?". Кафка может работать в нескольких режимах доставки, нужно смотреть настройки. Из коробки у нее почти at-least-once. Почему "почти" я расскажу, но в следующих постах, все в один не залезет.
Medium
Processing guarantees in Kafka
Each of the projects I’ve worked on in the last few years has involved a distributed message system such as AWS SQS, AWS Kinesis and more…
Если вдруг не знали, какую БД выбрать для вашего нового сервиса или монолита, то я принес: https://www.amazingcto.com/postgres-for-everything/
#management
Хвалите публично, но помните о капуцинах
В книжках по менеджменту часто встречается мысль: "хвалите публично, ругайте наедине". Это значит, что успехи чувака подчеркивать публично, а косяки обсуждать где-нибудь на встрече один-на-один. Мысль хорошая, идея правильная. Но есть офигенно важный нюанс, без которого "хвалите публично" становится токсичной херней.
Проще всего мне будет объяснить на примере обезьян-капуцинов. Мордочку одной из них вы видите на фотографии выше. Так вот, ученые взяли двух обезьян и посадили в разные клетки. Клетки стояли недалеко друг от друга, так, чтобы обезьяны могли друг друга видеть. Внутри каждой клетки ученые поместили по кнопке.
На этих кнопках и завязан эксперимент. Обезьяны умеют жать кнопки без проблем, хотя бы просто ради интереса. Когда капуцин из клетки А нажимал на кнопку, ученые давали ему виноград. Капуцины виноград любят, так что обезьянка была в восторге и радостно вжимала кнопку дальше.
Вторая обезьяна из клетки Б тоже нажимала кнопку, но вместо винограда ей дали огурец. Капуцины его конечно едят, но совсем не так охотно, как виноград. Первые несколько раз капуцин из клетки Б огурец выкидывал и косился на коллегу из клетки А, который за то же самое действие получал виноград. Потом капуцин из клетки Б начал кидаться огурцами, прыгать на стены клетки и всячески выражать крайнюю озабоченность происходящим произволом.
Так что если вдруг надумаете хвалить кого-то публично, посмотрите по сторонам: возможно, кто-то с огурцом в руке смотрит на то, как вы кидаетесь виноградом в других за ту же работу.
Всем хорошего понедельника :)
Хвалите публично, но помните о капуцинах
В книжках по менеджменту часто встречается мысль: "хвалите публично, ругайте наедине". Это значит, что успехи чувака подчеркивать публично, а косяки обсуждать где-нибудь на встрече один-на-один. Мысль хорошая, идея правильная. Но есть офигенно важный нюанс, без которого "хвалите публично" становится токсичной херней.
Проще всего мне будет объяснить на примере обезьян-капуцинов. Мордочку одной из них вы видите на фотографии выше. Так вот, ученые взяли двух обезьян и посадили в разные клетки. Клетки стояли недалеко друг от друга, так, чтобы обезьяны могли друг друга видеть. Внутри каждой клетки ученые поместили по кнопке.
На этих кнопках и завязан эксперимент. Обезьяны умеют жать кнопки без проблем, хотя бы просто ради интереса. Когда капуцин из клетки А нажимал на кнопку, ученые давали ему виноград. Капуцины виноград любят, так что обезьянка была в восторге и радостно вжимала кнопку дальше.
Вторая обезьяна из клетки Б тоже нажимала кнопку, но вместо винограда ей дали огурец. Капуцины его конечно едят, но совсем не так охотно, как виноград. Первые несколько раз капуцин из клетки Б огурец выкидывал и косился на коллегу из клетки А, который за то же самое действие получал виноград. Потом капуцин из клетки Б начал кидаться огурцами, прыгать на стены клетки и всячески выражать крайнюю озабоченность происходящим произволом.
Так что если вдруг надумаете хвалить кого-то публично, посмотрите по сторонам: возможно, кто-то с огурцом в руке смотрит на то, как вы кидаетесь виноградом в других за ту же работу.
Всем хорошего понедельника :)
Почему заставлять кого-то делать что-то — контрпродуктивно
Представьте: два одинаковых человека совершают одно и то же действие. Например, бегут. У первого из них уровень стресса находится на приемлемом уровне, у второго — значительно выше. Сейчас расскажу, как такое возможно, но начнем мы издалека.
Эксперименты
Ученые взяли две одинаковых крысы и посадили их внутрь колеса, примерно как на картинке сверху. Оба колеса соединили между собой, так что когда вращалось колесо в первое клетке, оно вращалось и во второй, но не наоборот.
То есть: у первой крысы колесо было обычным и вращалось только когда крыса по нему бежала. А вот во второй клетке колесо вращалось самостоятельно, когда первая крыса бежала по своему колесу. Чтобы не упасть, вторая крыса была вынуждена бежать.
Сразу после забега ученые замерили несколько параметров каждой крысы: уровень адреналина и других гормонов стресса в крови, например. Плюс, одновременно с этим, ученые снимали ЭЭГ с мозга. Точнее — с зубчатой извилины, части которой отвечают за память, изучение нового и так далее.
Результат номер один: мозги двух крыс физически работали по-разному, на разной частоте. Мозг крысы, которая бежала самостоятельно, работал активнее, с бОльшей частотой, а значит — активнее. А ведь обе крысы совершали одно и то же действие, разница была только одна — первая крыса бежала сама, вторая вынуждена была бежать.
Результат номер два: эндокринная система двух крыс тоже работала по-разному. У второй крысы уровень гормонов стресса в крови был заметно выше. И это странно: так как колесо двигалось само, вторя крыса прилагала меньше усилий, но гормоны стресса у нее все равно были выше.
Коротко: если крыса бежала в колесе самостоятельно, то ее мозг работал лучше и спокойнее чем у той крысы, которую бежать заставляли.
Почему это важно в работе
Очень просто: если вы заставляете человека делать работу, которая ему не нравится, он будет делать ее плохо и ощущать себя при этом хуже.
Все. Остальное выводы предлагаю сделать вам :) Хороших выходных!
Исследование
Представьте: два одинаковых человека совершают одно и то же действие. Например, бегут. У первого из них уровень стресса находится на приемлемом уровне, у второго — значительно выше. Сейчас расскажу, как такое возможно, но начнем мы издалека.
Эксперименты
Ученые взяли две одинаковых крысы и посадили их внутрь колеса, примерно как на картинке сверху. Оба колеса соединили между собой, так что когда вращалось колесо в первое клетке, оно вращалось и во второй, но не наоборот.
То есть: у первой крысы колесо было обычным и вращалось только когда крыса по нему бежала. А вот во второй клетке колесо вращалось самостоятельно, когда первая крыса бежала по своему колесу. Чтобы не упасть, вторая крыса была вынуждена бежать.
Сразу после забега ученые замерили несколько параметров каждой крысы: уровень адреналина и других гормонов стресса в крови, например. Плюс, одновременно с этим, ученые снимали ЭЭГ с мозга. Точнее — с зубчатой извилины, части которой отвечают за память, изучение нового и так далее.
Результат номер один: мозги двух крыс физически работали по-разному, на разной частоте. Мозг крысы, которая бежала самостоятельно, работал активнее, с бОльшей частотой, а значит — активнее. А ведь обе крысы совершали одно и то же действие, разница была только одна — первая крыса бежала сама, вторая вынуждена была бежать.
Результат номер два: эндокринная система двух крыс тоже работала по-разному. У второй крысы уровень гормонов стресса в крови был заметно выше. И это странно: так как колесо двигалось само, вторя крыса прилагала меньше усилий, но гормоны стресса у нее все равно были выше.
Коротко: если крыса бежала в колесе самостоятельно, то ее мозг работал лучше и спокойнее чем у той крысы, которую бежать заставляли.
Почему это важно в работе
Очень просто: если вы заставляете человека делать работу, которая ему не нравится, он будет делать ее плохо и ощущать себя при этом хуже.
Все. Остальное выводы предлагаю сделать вам :) Хороших выходных!
Исследование
К прошлому посту в комментах насыпали вопросов. Вы спрашиваете — я отвечаю :)
Вопрос: Если мы принуждаем к выполнению той или иной задачи, это однозначный провал работы с мотивацией, или есть исключения?
Ответ: почти всегда это правда. Если вам приходится принуждать человека к работе над задачей, это менеджерская недоработка. Но давай разберемся подробнее и начнем с терминологии.
Принуждение для кого-то может показаться сродни мотивации. Например, когда вы говорите "если ты не сделаешь Х, то я тебя уволю", вы все равно мотивируете человека. Поэтому для некоторых людей грань между мотивацией и принуждением стирается. Давайте очертим ее.
Мотивация — это когда у человека есть причины делать задачу. Например, задача прокачает его скиллы, принесет пользу миру, ускорит работу проекта или просто принесет ценность компании. Так или иначе, задача находит отклик у человека и он делает ее.
Принуждение — это когда у человека есть только одна причина делать задачу: потому что ему так сказал руководитель.
Теперь к ответу. Иногда — очень редко! — принуждать допустимо, но лучше поискать варианты.
Например, вам нужно пройти ИБ аудит, и 10 ваших сервисов аудит завалят.
Вариант один
Вы можете прийти и сказать: "Через 5 дней я ожидаю, что вы пофиксите все уязвимости". Они даже не понимают, что это за уязвимости, но начинают их фиксить. Это — неоправданное принуждение.
Вариант два
Вы приходите, объясняете командам, что если они не исправят уязвимости, компания завалит аудит и всем сотрудникам будет грустно. Это — хорошая мотивация.
Вариант три
Вы приходите, объясняете последствия, но командам все равно. Для них ваши аргументы — не аргументы. Очевидно, проблема все еще в нас с вами: мы должны уметь мотивировать. В таком случае, вы говорите "Через 5 дней я ожидаю, что вы все пофиксите". Это — оправданное принуждение.
Вопрос: Если мы принуждаем к выполнению той или иной задачи, это однозначный провал работы с мотивацией, или есть исключения?
Ответ: почти всегда это правда. Если вам приходится принуждать человека к работе над задачей, это менеджерская недоработка. Но давай разберемся подробнее и начнем с терминологии.
Принуждение для кого-то может показаться сродни мотивации. Например, когда вы говорите "если ты не сделаешь Х, то я тебя уволю", вы все равно мотивируете человека. Поэтому для некоторых людей грань между мотивацией и принуждением стирается. Давайте очертим ее.
Мотивация — это когда у человека есть причины делать задачу. Например, задача прокачает его скиллы, принесет пользу миру, ускорит работу проекта или просто принесет ценность компании. Так или иначе, задача находит отклик у человека и он делает ее.
Принуждение — это когда у человека есть только одна причина делать задачу: потому что ему так сказал руководитель.
Теперь к ответу. Иногда — очень редко! — принуждать допустимо, но лучше поискать варианты.
Например, вам нужно пройти ИБ аудит, и 10 ваших сервисов аудит завалят.
Вариант один
Вы можете прийти и сказать: "Через 5 дней я ожидаю, что вы пофиксите все уязвимости". Они даже не понимают, что это за уязвимости, но начинают их фиксить. Это — неоправданное принуждение.
Вариант два
Вы приходите, объясняете командам, что если они не исправят уязвимости, компания завалит аудит и всем сотрудникам будет грустно. Это — хорошая мотивация.
Вариант три
Вы приходите, объясняете последствия, но командам все равно. Для них ваши аргументы — не аргументы. Очевидно, проблема все еще в нас с вами: мы должны уметь мотивировать. В таком случае, вы говорите "Через 5 дней я ожидаю, что вы все пофиксите". Это — оправданное принуждение.
Мне стало интересно копнуть глубже в мотивацию. Искал я медь, но нашел чистое золото, делюсь.
Негативная мотивация
Если спросить человека, что лучше: позитивная мотивация или негативная, большинство ответят однозначно — позитивная! Не согласен. Более того, сама постановка вопроса в корне неправильна.
Для начала определимся с терминами:
Позитивная мотивация — это награждать человека за действие или бездействие. Например, пообещать выдать премию по итогам года.
Негативная мотивация — наказывать за действие или бездействие. Например, пригрозить оштрафовать водителя за нарушение ПДД.
Люди противопоставляют два типа мотивации друг другу. Если менеджер использует позитивную мотивацию, он хороший. Если использует негативную, то плохой. Я же считаю, что если менеджер использует лишь один тип мотивации и забывает про другой, то это — плохой менеджер.
Но у нас на канале принято подтверждать мнения наукой.
Нейробиология о мотивации
Яак Панксепп, нейробилог, провел ряд экспериментов на тему мотивации и написал целую книгу -- Affective Neuroscience. Главным открытием стало разделение мотивации на две системы: вознаграждающую и наказывающую. За каждую из них отвечал свой участок мозга.
Представьте несколько голодных крыс, практически голодающих. Перед ними расположили сыр, а к хвосту крыс прицепили пружинку, чтобы замерить силу, с которой крыса будет рваться к сыру. В ходе первого опыта, ученые выяснили, что крыса рвется к сыру с силой X. Х -- это сила позитивной, вознаграждающей мотивации.
В теории, голодающая крыса будет рваться к сыру на пределе своих сил, но это не так!
Ученые провели тот же самый эксперимент, но теперь позади каждой крысы распылили запах кошки. И крысы стали тянуть пружинку еще сильнее! Дополнительная сила, с которой крысы тянулись к сыру, и есть негативная мотивация.
Выводы
Я в процессе поиска исследований, которые показали бы те же результаты и на людях, но эмпирически вывод очень верный: негативная мотивация сильна.
Дайте знать, если вам интересна эта тематика.
Ссылочка на интервью
Негативная мотивация
Если спросить человека, что лучше: позитивная мотивация или негативная, большинство ответят однозначно — позитивная! Не согласен. Более того, сама постановка вопроса в корне неправильна.
Для начала определимся с терминами:
Позитивная мотивация — это награждать человека за действие или бездействие. Например, пообещать выдать премию по итогам года.
Негативная мотивация — наказывать за действие или бездействие. Например, пригрозить оштрафовать водителя за нарушение ПДД.
Люди противопоставляют два типа мотивации друг другу. Если менеджер использует позитивную мотивацию, он хороший. Если использует негативную, то плохой. Я же считаю, что если менеджер использует лишь один тип мотивации и забывает про другой, то это — плохой менеджер.
Но у нас на канале принято подтверждать мнения наукой.
Нейробиология о мотивации
Яак Панксепп, нейробилог, провел ряд экспериментов на тему мотивации и написал целую книгу -- Affective Neuroscience. Главным открытием стало разделение мотивации на две системы: вознаграждающую и наказывающую. За каждую из них отвечал свой участок мозга.
Представьте несколько голодных крыс, практически голодающих. Перед ними расположили сыр, а к хвосту крыс прицепили пружинку, чтобы замерить силу, с которой крыса будет рваться к сыру. В ходе первого опыта, ученые выяснили, что крыса рвется к сыру с силой X. Х -- это сила позитивной, вознаграждающей мотивации.
В теории, голодающая крыса будет рваться к сыру на пределе своих сил, но это не так!
Ученые провели тот же самый эксперимент, но теперь позади каждой крысы распылили запах кошки. И крысы стали тянуть пружинку еще сильнее! Дополнительная сила, с которой крысы тянулись к сыру, и есть негативная мотивация.
Выводы
Я в процессе поиска исследований, которые показали бы те же результаты и на людях, но эмпирически вывод очень верный: негативная мотивация сильна.
Дайте знать, если вам интересна эта тематика.
Ссылочка на интервью