«Ты можешь услышать хлопок двух ладоней, когда они ударяются друг о друга, — сказал Мокурай. — Теперь покажи мне хлопок одной ладони».
Тойо поклонился и пошёл в свою комнату, чтобы рассмотреть эту проблему.
Из окна он услышал музыку гейш. «Ах, я понял!» — воскликнул он.
На следующий вечер, когда учитель попросил его показать хлопок одной ладони, Тойо начал играть музыку гейш.
«Hет, нет, — сказал Мокурай, — это никак не подойдёт. Это не хлопок одной ладони. Ты совсем не понял его».
Думая, что музыка будет мешать, Тойо ушёл в более спокойное место. Он снова погрузился в медитацию. «Чем же может быть хлопок одной ладони?» Он услышал, как капает вода.
«Я понял», — подумал Тойо.
Оказавшись перед учителем в следующий раз, Тойо начал капать водой.
«Что это? — спросил Мокурай. — Это звук капающей воды, но не хлопок ладони. Попробуй ещё раз».
Hапрасно Тойо медитировал, чтобы услышать хлопок одной ладони. Он услышал шум ветра, но и этот звук был отвергнут. Он услышал крик совы, но и этот звук был отвергнут.
Более чем десять раз приходил Тойо к Мокураю с различными звуками, всё было неправильно.
Почти год обдумывал он, что же может быть хлопком одной ладони. Hаконец, маленький Тойо достиг подлинной медитации и перешёл пределы звуков. «Я больше не мог собирать их, — объяснил он позже, — поэтому я достиг беззвучного звука».
Тойо уразумел хлопок одной ладони.
Тойо поклонился и пошёл в свою комнату, чтобы рассмотреть эту проблему.
Из окна он услышал музыку гейш. «Ах, я понял!» — воскликнул он.
На следующий вечер, когда учитель попросил его показать хлопок одной ладони, Тойо начал играть музыку гейш.
«Hет, нет, — сказал Мокурай, — это никак не подойдёт. Это не хлопок одной ладони. Ты совсем не понял его».
Думая, что музыка будет мешать, Тойо ушёл в более спокойное место. Он снова погрузился в медитацию. «Чем же может быть хлопок одной ладони?» Он услышал, как капает вода.
«Я понял», — подумал Тойо.
Оказавшись перед учителем в следующий раз, Тойо начал капать водой.
«Что это? — спросил Мокурай. — Это звук капающей воды, но не хлопок ладони. Попробуй ещё раз».
Hапрасно Тойо медитировал, чтобы услышать хлопок одной ладони. Он услышал шум ветра, но и этот звук был отвергнут. Он услышал крик совы, но и этот звук был отвергнут.
Более чем десять раз приходил Тойо к Мокураю с различными звуками, всё было неправильно.
Почти год обдумывал он, что же может быть хлопком одной ладони. Hаконец, маленький Тойо достиг подлинной медитации и перешёл пределы звуков. «Я больше не мог собирать их, — объяснил он позже, — поэтому я достиг беззвучного звука».
Тойо уразумел хлопок одной ладони.
Хлопок одной ладони — это канал от менеджера для менеджеров.
Тут будут мои мысли, чужие мысли, мой опыт, чужой опыт, моя боль, чужая боль, мои ошибки, чужие ошибки, продолжите ряд. Все это в форме заметок, ссылок, репостов и прочих легальных форматов. Преимущественно все будет в мире IT и технологий, но часть будет применима и для других сфер, так как они уже или очень скоро тоже будут про IT и технологии.
Я не люблю догмы и секты. Не верю, что в управлении возможны единственно правильные решения и подходы. Как и в жизни вообще. Но текст и человеческое восприятие обязательно сделают своё дело, поэтому любые утверждения воспринимайте со скепсисом.
Верю больше в:
⁃ принципы, чем правила и регламенты
⁃ людей, чем инструменты (по крайней мере до предстоящего восстания ИИ)
⁃ эксперименты, чем домыслы
И да, тут в куче будет и про проекты, и про продукты, и про инженерные практики, и какого ещё только менеджерства не придумаешь. Поэтому, как говорила замечательная Масяня: «Добро пожаловать в наш дерьмовый мир обратно!»
Тут будут мои мысли, чужие мысли, мой опыт, чужой опыт, моя боль, чужая боль, мои ошибки, чужие ошибки, продолжите ряд. Все это в форме заметок, ссылок, репостов и прочих легальных форматов. Преимущественно все будет в мире IT и технологий, но часть будет применима и для других сфер, так как они уже или очень скоро тоже будут про IT и технологии.
Я не люблю догмы и секты. Не верю, что в управлении возможны единственно правильные решения и подходы. Как и в жизни вообще. Но текст и человеческое восприятие обязательно сделают своё дело, поэтому любые утверждения воспринимайте со скепсисом.
Верю больше в:
⁃ принципы, чем правила и регламенты
⁃ людей, чем инструменты (по крайней мере до предстоящего восстания ИИ)
⁃ эксперименты, чем домыслы
И да, тут в куче будет и про проекты, и про продукты, и про инженерные практики, и какого ещё только менеджерства не придумаешь. Поэтому, как говорила замечательная Масяня: «Добро пожаловать в наш дерьмовый мир обратно!»
Поесть блинчиков
В третьем фильме Men In Black, когда Уилл Смит и молодой Кей не знают, что делать дальше и как искать плохого чувака, Кей начинает диалог:
Young Agent K: We need pie.
Agent J: What?
Young Agent K: My grand daddy always said, if you got a problem that you can't solve, helps to get out of your head. Pie, it's good.
Agent J: Pie?
Young Agent K: Yeah.
Agent J: Your grand daddy, heavyset man?
Young Agent K: A little bit.
Agent J: Yeah, you know what? We've been doing smart stuff, we've been following clues, doing real police work. It might be time we do something stupid. Something that ain't got nothing to do with nothing. Ah, you know what? Now I want some pie, K. I want some pie. Let's go get some dumb-ass pie!
[J walks off]
Young Agent K: Sounds good.
Первый раз я смотрел фильм в кино и соответственно русском переводе. И вместо пирога там почему-то были блинчики. Про pie узнал через несколько лет, но было уже поздно.
К чему это всё? Выражение «поесть блинчиков» закрепилось в моём сознании и затем среди нескольких коллег как реакция на сложные моменты в работе. Совет агента MiB стал реально приносить пользу менеджерам и программистам. Не знаю, как остальные ребята, но я применяю его до сих пор.
- У тебя появилась проблема, которую ты не знаешь, как решить Сходи поешь блинчиков.
- Зашёл в тупик с реализацией алгоритма? Передохни, поешь блинчиков.
- Не знаешь, как правильно донести до сотрудника, что он лажает. Поешь блинчиков, ответ придёт. А лучше своди сотрудника поесть блинчиков тоже.
- Клиент выносит мозг и все переговоры заходят в тупик? Иди уже жри блины!
С одной стороны жалко, что пирог обделили. Но по факту красиво он звучит только на английском. В контексте русской речи блинчики — самое то.
https://youtu.be/yEXu6EfnAtA
В третьем фильме Men In Black, когда Уилл Смит и молодой Кей не знают, что делать дальше и как искать плохого чувака, Кей начинает диалог:
Young Agent K: We need pie.
Agent J: What?
Young Agent K: My grand daddy always said, if you got a problem that you can't solve, helps to get out of your head. Pie, it's good.
Agent J: Pie?
Young Agent K: Yeah.
Agent J: Your grand daddy, heavyset man?
Young Agent K: A little bit.
Agent J: Yeah, you know what? We've been doing smart stuff, we've been following clues, doing real police work. It might be time we do something stupid. Something that ain't got nothing to do with nothing. Ah, you know what? Now I want some pie, K. I want some pie. Let's go get some dumb-ass pie!
[J walks off]
Young Agent K: Sounds good.
Первый раз я смотрел фильм в кино и соответственно русском переводе. И вместо пирога там почему-то были блинчики. Про pie узнал через несколько лет, но было уже поздно.
К чему это всё? Выражение «поесть блинчиков» закрепилось в моём сознании и затем среди нескольких коллег как реакция на сложные моменты в работе. Совет агента MiB стал реально приносить пользу менеджерам и программистам. Не знаю, как остальные ребята, но я применяю его до сих пор.
- У тебя появилась проблема, которую ты не знаешь, как решить Сходи поешь блинчиков.
- Зашёл в тупик с реализацией алгоритма? Передохни, поешь блинчиков.
- Не знаешь, как правильно донести до сотрудника, что он лажает. Поешь блинчиков, ответ придёт. А лучше своди сотрудника поесть блинчиков тоже.
- Клиент выносит мозг и все переговоры заходят в тупик? Иди уже жри блины!
С одной стороны жалко, что пирог обделили. Но по факту красиво он звучит только на английском. В контексте русской речи блинчики — самое то.
https://youtu.be/yEXu6EfnAtA
Названия вредны
В математике определения однозначны в 99% случаев, их одинаково понимают все математики. Нет такого, что под интегралом или логарифмом понимают разный набор действий.
Менеджмент не такой. Определений, терминов, аббревиатур много. А понимает их каждый по-своему. Потому что люди. Потому что это не точная наука, если вообще это можно назвать наукой. Потому что нет отношения к точности определений как к чему-то безусловно необходимому. Спросите десять менеджеров, что такое LTV или agile. Трактовки будут отличаться, акценты будут отличаться, кто-то точно будет противоречить определению другого.
Поэтому названия часто вредят. Каждый понимает название по-своему вместо того, чтобы коммуницировать вокруг описания. Поэтому всегда лучше описывать.
Нет: мы верим в agile и используем scrum.
Да: у нас недельные итерации с общим планированием по понедельникам, мы не оцениваем задачи в стори поинтах и часах, а приоритезируем их по ценности для продукта и клиентов. Инструмент — трелло, доски разделены таким образом...
Нет: мы следим за показателем LTV
Да: мы отслеживаем изменения прогнозного LTV на 30, 60 и 365 дней в разрезе дневных когорт и каналов привлечения на основе данных 3, 7 и 11 дня используя вот этот самый алгоритм прогноза.
Круто, когда внутри компании есть свой «словарь». Тогда можно обходиться терминами. Но только вышел из здания, столкнулся с другим менеджером в баре — сразу надо всё уточнять.
В математике определения однозначны в 99% случаев, их одинаково понимают все математики. Нет такого, что под интегралом или логарифмом понимают разный набор действий.
Менеджмент не такой. Определений, терминов, аббревиатур много. А понимает их каждый по-своему. Потому что люди. Потому что это не точная наука, если вообще это можно назвать наукой. Потому что нет отношения к точности определений как к чему-то безусловно необходимому. Спросите десять менеджеров, что такое LTV или agile. Трактовки будут отличаться, акценты будут отличаться, кто-то точно будет противоречить определению другого.
Поэтому названия часто вредят. Каждый понимает название по-своему вместо того, чтобы коммуницировать вокруг описания. Поэтому всегда лучше описывать.
Нет: мы верим в agile и используем scrum.
Да: у нас недельные итерации с общим планированием по понедельникам, мы не оцениваем задачи в стори поинтах и часах, а приоритезируем их по ценности для продукта и клиентов. Инструмент — трелло, доски разделены таким образом...
Нет: мы следим за показателем LTV
Да: мы отслеживаем изменения прогнозного LTV на 30, 60 и 365 дней в разрезе дневных когорт и каналов привлечения на основе данных 3, 7 и 11 дня используя вот этот самый алгоритм прогноза.
Круто, когда внутри компании есть свой «словарь». Тогда можно обходиться терминами. Но только вышел из здания, столкнулся с другим менеджером в баре — сразу надо всё уточнять.
Стать ненужным
Когда я был молодым программистом, я думал, что менеджеры по сути не нужны. Казалось, что технических знаний у них не хватает, а вся их работа — это тасовать задачки и собирать совещания. Но было приятно, что можно на них слить всякие уточнения, встречи, составление формальных заданий или документации. Про продактов тогда вообще речи никто не вёл.
Когда я начинал бизнес, эта идея развилась. Идеальной командой казалась самоорганизующаяся группа профессиональных программистов, которая может и выяснить проблему, и договориться об условиях работы, и работать прозрачно в контакте с клиентом, и запилить всё технически, и аналитику вкрутить. Но оказалось, что таких программистов рожают и выращивают маловато.
Реальность доказала необходимость менеджеров, а потом беспощадно превратила в одного из них. Irony, bitch.
Но реальность одно, а видение и цель другое. Поэтому заблуждение стало некоторым принципом, на который можно ориентироваться в выстраивании любого процесса.
Как выстроить процесс работы в команде?
Так, чтобы стать ненужным.
Как организовать мониторинг за метриками?
Так, чтобы стать ненужным.
Как построить процесс обратной связи?
Так, чтобы ты стал ненужным.
По факту здесь будет как у Дали: «Не бойтесь совершенства. Вам всё равно никогда его не достичь». Сейчас я не вижу высокой вероятности того, что менеджеры останутся без работы в ближайшие десятилетия.
Но благодаря такому подходу выстроенные системы постепенно начнут избавляться от bus factor, команды постепенно станут проактивнее и осознаннее, доверие в команде и вовне будет повышаться, сна будет побольше, волосы будут мягкими и шелковистыми, кожа гладкая, а отпуск можно будет провести, не втыкая в телефон каждые 5 минут.
Когда я был молодым программистом, я думал, что менеджеры по сути не нужны. Казалось, что технических знаний у них не хватает, а вся их работа — это тасовать задачки и собирать совещания. Но было приятно, что можно на них слить всякие уточнения, встречи, составление формальных заданий или документации. Про продактов тогда вообще речи никто не вёл.
Когда я начинал бизнес, эта идея развилась. Идеальной командой казалась самоорганизующаяся группа профессиональных программистов, которая может и выяснить проблему, и договориться об условиях работы, и работать прозрачно в контакте с клиентом, и запилить всё технически, и аналитику вкрутить. Но оказалось, что таких программистов рожают и выращивают маловато.
Реальность доказала необходимость менеджеров, а потом беспощадно превратила в одного из них. Irony, bitch.
Но реальность одно, а видение и цель другое. Поэтому заблуждение стало некоторым принципом, на который можно ориентироваться в выстраивании любого процесса.
Как выстроить процесс работы в команде?
Так, чтобы стать ненужным.
Как организовать мониторинг за метриками?
Так, чтобы стать ненужным.
Как построить процесс обратной связи?
Так, чтобы ты стал ненужным.
По факту здесь будет как у Дали: «Не бойтесь совершенства. Вам всё равно никогда его не достичь». Сейчас я не вижу высокой вероятности того, что менеджеры останутся без работы в ближайшие десятилетия.
Но благодаря такому подходу выстроенные системы постепенно начнут избавляться от bus factor, команды постепенно станут проактивнее и осознаннее, доверие в команде и вовне будет повышаться, сна будет побольше, волосы будут мягкими и шелковистыми, кожа гладкая, а отпуск можно будет провести, не втыкая в телефон каждые 5 минут.
Апдейтнуть статус
Не помню, когда точно эта практика вжилась в ежедневную работу. Но точно знаю, что это одна из тех вещей, которая закрепляется через боль и страдания.
Однажды я вёл проект интеграции двух сервисов. На старте я пообещал владельцу одного из них, что каждую неделю на почте у всех будет апдейт по прогрессу. Я не пропустил ни одного письма за 3 месяца до успешного запуска. Позже тот же владелец сказал мне, что не поверил начальному обещанию, но именно эти апдейты сделали нас ключевым партнёром, так как другие не показывали даже близкой прозрачности и наглядности процесса по сравнению с нашей.
Несколько месяцев назад я начал работу в новой компании. Команда большая и распределённая. Мой наставник и менеджер в другом городе. Первые 2-3 недели я засылал ему в слак статус по своему прогрессу погружения в материалы и задачи каждые день-два. Он либо корректировал, либо плюсовал. После этот процесс переехал в отдельную доску в асане, к этому моменту уже выстроено доверие, есть взаимное понимание подходов к работе.
На любом проекте, крупной задаче, ключевом процессе надо апдейтить статус прогресса.
⁃ Апдейтить надо на всех участников процесса.
⁃ Апдейтить надо через канал связи, который используют и читают все (канал в слаке, email, задача в трекере).
⁃ Апдейтить надо регулярно. В особо критичных и срочных вопросах, либо на старте — раз в день. В нормальном режиме эмпирически выведенный интервал — раз в неделю.
Формат апдейта может быть произвольным, но как правило содержит:
⁃ что было сделано с прошлого апдейта, где смотреть результат
⁃ что сейчас в работе и когда ждать результат
⁃ какие следующие шаги и приоритеты
⁃ какие есть риски/проблемы/открытые вопросы
Апдейт это не отчётность одних перед другими. Это инструмент коммуникации, способ отслеживать своё продвижение, запрос обратной связи, точка синхронизации, поддержка ритма.
Апдейт можно слать клиентам, стейкхолдерам, начальникам, а можно команде. Лучше всем сразу.
Апдейт — это не замена демо, а дополнение. Не всегда есть материал для демо, не каждый процесс его подразумевает.
Можно проактивно написать апдейт, убедиться самому, что все на одной волне, и быть молодцом. А можно неделями тихо возиться с чем-то, дождаться, что спросят «че как?», и узнать, что делал бесполезную хрень.
Не помню, когда точно эта практика вжилась в ежедневную работу. Но точно знаю, что это одна из тех вещей, которая закрепляется через боль и страдания.
Однажды я вёл проект интеграции двух сервисов. На старте я пообещал владельцу одного из них, что каждую неделю на почте у всех будет апдейт по прогрессу. Я не пропустил ни одного письма за 3 месяца до успешного запуска. Позже тот же владелец сказал мне, что не поверил начальному обещанию, но именно эти апдейты сделали нас ключевым партнёром, так как другие не показывали даже близкой прозрачности и наглядности процесса по сравнению с нашей.
Несколько месяцев назад я начал работу в новой компании. Команда большая и распределённая. Мой наставник и менеджер в другом городе. Первые 2-3 недели я засылал ему в слак статус по своему прогрессу погружения в материалы и задачи каждые день-два. Он либо корректировал, либо плюсовал. После этот процесс переехал в отдельную доску в асане, к этому моменту уже выстроено доверие, есть взаимное понимание подходов к работе.
На любом проекте, крупной задаче, ключевом процессе надо апдейтить статус прогресса.
⁃ Апдейтить надо на всех участников процесса.
⁃ Апдейтить надо через канал связи, который используют и читают все (канал в слаке, email, задача в трекере).
⁃ Апдейтить надо регулярно. В особо критичных и срочных вопросах, либо на старте — раз в день. В нормальном режиме эмпирически выведенный интервал — раз в неделю.
Формат апдейта может быть произвольным, но как правило содержит:
⁃ что было сделано с прошлого апдейта, где смотреть результат
⁃ что сейчас в работе и когда ждать результат
⁃ какие следующие шаги и приоритеты
⁃ какие есть риски/проблемы/открытые вопросы
Апдейт это не отчётность одних перед другими. Это инструмент коммуникации, способ отслеживать своё продвижение, запрос обратной связи, точка синхронизации, поддержка ритма.
Апдейт можно слать клиентам, стейкхолдерам, начальникам, а можно команде. Лучше всем сразу.
Апдейт — это не замена демо, а дополнение. Не всегда есть материал для демо, не каждый процесс его подразумевает.
Можно проактивно написать апдейт, убедиться самому, что все на одной волне, и быть молодцом. А можно неделями тихо возиться с чем-то, дождаться, что спросят «че как?», и узнать, что делал бесполезную хрень.
Не делай сам
Есть крутое упражнение для тех, у кого проблемы с делегированием. На день, два, или вообще неделю надо забиться с самим собой не делать ничего самому. Всё должны сделать другие: написать письмо, сделать звонок, провести встречу, разгрести бэклог, составить роадмап, что угодно вообще.
Это сложно, поэтому в чистом виде никогда не получится, но фокус на том, как избавиться от работы появляется. От него появляются валидные мысли, что и как делегировать, как проверить результат, как вовремя дать обратную связь.
Местами может быть неловко, иногда больно, но того стоит. Ведь минздрав предупреждает: работа вредит вашему здоровью.
Есть крутое упражнение для тех, у кого проблемы с делегированием. На день, два, или вообще неделю надо забиться с самим собой не делать ничего самому. Всё должны сделать другие: написать письмо, сделать звонок, провести встречу, разгрести бэклог, составить роадмап, что угодно вообще.
Это сложно, поэтому в чистом виде никогда не получится, но фокус на том, как избавиться от работы появляется. От него появляются валидные мысли, что и как делегировать, как проверить результат, как вовремя дать обратную связь.
Местами может быть неловко, иногда больно, но того стоит. Ведь минздрав предупреждает: работа вредит вашему здоровью.
Прикинуться томатом
Реклама сока с детьми в костюмах фруктов породила множество посредственных анекдотов. Фразу «а я томат» должны помнить многие.
Я часто использую её, когда откровенно туплю и косячу. Признал себя томатом = быстро признал ошибку и двигаешь дальше.
Но вот ещё признание: иногда есть смысл прикинуться томатом специально. Например, чтобы помочь собеседнику самому дойти до нужной мысли или вывода, либо чтобы убедиться, что собеседник реально понимает, о чем говорит.
Также это созвучно с принципом «не в порядке» в системе ведения переговоров по Кемпу (и Синельникову). Если коротко, то другая сторона не должна чувствовать себя хуже на вашем фоне. Поэтому стоит быть немного, но заметно, несовершенным.
В некоторых ситуациях это манипуляция, и такое не рекомендуется повторять в домашних условиях. Для манипуляторов вообще в аду заготовлен отдельный котёл. Но круто, когда это внутреннее ощущение и искреннее желание помочь собеседнику или поддержать оппонента. Тогда это действительно работает.
https://youtu.be/mTW-HEz0TBM
Реклама сока с детьми в костюмах фруктов породила множество посредственных анекдотов. Фразу «а я томат» должны помнить многие.
Я часто использую её, когда откровенно туплю и косячу. Признал себя томатом = быстро признал ошибку и двигаешь дальше.
Но вот ещё признание: иногда есть смысл прикинуться томатом специально. Например, чтобы помочь собеседнику самому дойти до нужной мысли или вывода, либо чтобы убедиться, что собеседник реально понимает, о чем говорит.
Также это созвучно с принципом «не в порядке» в системе ведения переговоров по Кемпу (и Синельникову). Если коротко, то другая сторона не должна чувствовать себя хуже на вашем фоне. Поэтому стоит быть немного, но заметно, несовершенным.
В некоторых ситуациях это манипуляция, и такое не рекомендуется повторять в домашних условиях. Для манипуляторов вообще в аду заготовлен отдельный котёл. Но круто, когда это внутреннее ощущение и искреннее желание помочь собеседнику или поддержать оппонента. Тогда это действительно работает.
https://youtu.be/mTW-HEz0TBM
YouTube
А я томат...
Остальное тут: http://www.youtube.com/user/MKScongratzzz
Это вопрос, откройте
Почувствуйте разницу.
Нет: ты уже сделал эту задачу?
Да: какие есть сложности с этой задачей?
Нет: Мы сможем сдать проект вовремя?
Да: Что мы можем сделать, чтобы сдать проект вовремя?
Нет: Вам нравится наш продукт?
Да: Как вы используете наш продукт? Какие проблемы вы решаете с его помощью?
Нет: Любишь рэпчик?
Да: Что ты сделал для хип-хопа в свои годы?
Открытые вопросы — основа менеджерский гигиены, самый простой и действенный способ понять собеседника и узнать, что происходит на самом деле.
На практике это очень просто: задайте вопрос так, чтобы нельзя было ответить «да» или «нет», не давайте вариантов ответа. Самое сложное — вспомнить и поправить себя в нужный момент. Сначала немного зависаешь, спрашиваешь привычным образом, потом исправляешься. Со временем это переходит в привычку. Иногда из-за этого тебя принимают за сектанта, но в большинстве ситуаций всё ок.
Закрытые вопросы нужны, чтобы собрать статистику, подтвердить то, что вы и так знаете или думаете, что знаете. Открытые вопросы дают шанс узнать то, о чём вы и не подумали бы спросить. Поэтому открытые вопросы периодически открывают сознание.
Подробнее:
* в совете Бюро в контексте переговоров https://bureau.ru/bb/soviet/20170811/
* в статье в контексте User Research https://www.nngroup.com/articles/open-ended-questions/
Почувствуйте разницу.
Нет: ты уже сделал эту задачу?
Да: какие есть сложности с этой задачей?
Нет: Мы сможем сдать проект вовремя?
Да: Что мы можем сделать, чтобы сдать проект вовремя?
Нет: Вам нравится наш продукт?
Да: Как вы используете наш продукт? Какие проблемы вы решаете с его помощью?
Нет: Любишь рэпчик?
Да: Что ты сделал для хип-хопа в свои годы?
Открытые вопросы — основа менеджерский гигиены, самый простой и действенный способ понять собеседника и узнать, что происходит на самом деле.
На практике это очень просто: задайте вопрос так, чтобы нельзя было ответить «да» или «нет», не давайте вариантов ответа. Самое сложное — вспомнить и поправить себя в нужный момент. Сначала немного зависаешь, спрашиваешь привычным образом, потом исправляешься. Со временем это переходит в привычку. Иногда из-за этого тебя принимают за сектанта, но в большинстве ситуаций всё ок.
Закрытые вопросы нужны, чтобы собрать статистику, подтвердить то, что вы и так знаете или думаете, что знаете. Открытые вопросы дают шанс узнать то, о чём вы и не подумали бы спросить. Поэтому открытые вопросы периодически открывают сознание.
Подробнее:
* в совете Бюро в контексте переговоров https://bureau.ru/bb/soviet/20170811/
* в статье в контексте User Research https://www.nngroup.com/articles/open-ended-questions/
Дизайн-бюро Артёма Горбунова
Вы всё время учите задавать открытые вопросы. Я не понимаю, почему это так важно
Илья!
Вы всё время учите задавать открытые вопросы. Я не понимаю, почему это так важно. Ну то есть понятно, что клиент отвечает — и это хорошо. Но нормальный клиент и на закрытые вопросы отвечает. Да и даже вообще без вопросов тоже: типа «расскажите о вашей…
Вы всё время учите задавать открытые вопросы. Я не понимаю, почему это так важно. Ну то есть понятно, что клиент отвечает — и это хорошо. Но нормальный клиент и на закрытые вопросы отвечает. Да и даже вообще без вопросов тоже: типа «расскажите о вашей…
Цикл OPDCA: Observe-Plan-Do-Check-Adjust
Про цикл PDCA знаю давно, но осознанно применил как инструмент совсем недавно после поста в канале «Бабаева, к доске!» https://news.1rj.ru/str/changemarketing/419. Он просто очень вовремя попался, как раз к одной из текущих задач.
Используется цикл для организации процесса непрерывного улучшения и контроля качества. Известен также как цикл Деминга. Мне больше нравится версия с O, чем просто PDCA.
Суть проста:
⁃ Observe: наблюдение за текущим состоянием
⁃ Plan: постановка целей и определение процесса продвижения к ним
⁃ Do: проверка плана в бою
⁃ Check: сбор и анализ результатов Do, а также изменений с предыдущей итерации цикла
⁃ Adjust (по смыслу нравится мне больше, чем Act): подкрутка плана и процессов
Для меня такие инструменты — это способ перевести интуитивные решения в осознанные и структурированные.
Задача, к которой применил: проанализировать текущий процесс разработки в команде, разобраться, почему работы много, а ключевые вещи запускаются долго, починить это всё.
Я расписал по каждому этапу цикла, какие активности, встречи и ритуалы есть у нас в команде, а также какие проблемы сразу видны. Простое упражнение сразу показало:
⁃ у нас много Do: все фигачат и постоянно заняты
⁃ Plan недостаточно сфокусирован и структурирован, приоритеты для Do часто размытые
⁃ Check и Adjust не являются частью регулярного процесса, появляются эпизодически при наличии времени или факапа
Большая часть процесса в команде и компании сформировалась до меня, моё погружение в контекст ещё было неполным. Я честно не мог сформулировать проблему до конца, чтобы начать её решать полноценно. OPDCA помог начать.
Дальше подключились идеи Голдратта и некоторые другие инструменты. Первые результаты уже прорастают. А цикл теперь хочется приложить как подорожник к любому процессу.
https://en.m.wikipedia.org/wiki/PDCA
Про цикл PDCA знаю давно, но осознанно применил как инструмент совсем недавно после поста в канале «Бабаева, к доске!» https://news.1rj.ru/str/changemarketing/419. Он просто очень вовремя попался, как раз к одной из текущих задач.
Используется цикл для организации процесса непрерывного улучшения и контроля качества. Известен также как цикл Деминга. Мне больше нравится версия с O, чем просто PDCA.
Суть проста:
⁃ Observe: наблюдение за текущим состоянием
⁃ Plan: постановка целей и определение процесса продвижения к ним
⁃ Do: проверка плана в бою
⁃ Check: сбор и анализ результатов Do, а также изменений с предыдущей итерации цикла
⁃ Adjust (по смыслу нравится мне больше, чем Act): подкрутка плана и процессов
Для меня такие инструменты — это способ перевести интуитивные решения в осознанные и структурированные.
Задача, к которой применил: проанализировать текущий процесс разработки в команде, разобраться, почему работы много, а ключевые вещи запускаются долго, починить это всё.
Я расписал по каждому этапу цикла, какие активности, встречи и ритуалы есть у нас в команде, а также какие проблемы сразу видны. Простое упражнение сразу показало:
⁃ у нас много Do: все фигачат и постоянно заняты
⁃ Plan недостаточно сфокусирован и структурирован, приоритеты для Do часто размытые
⁃ Check и Adjust не являются частью регулярного процесса, появляются эпизодически при наличии времени или факапа
Большая часть процесса в команде и компании сформировалась до меня, моё погружение в контекст ещё было неполным. Я честно не мог сформулировать проблему до конца, чтобы начать её решать полноценно. OPDCA помог начать.
Дальше подключились идеи Голдратта и некоторые другие инструменты. Первые результаты уже прорастают. А цикл теперь хочется приложить как подорожник к любому процессу.
https://en.m.wikipedia.org/wiki/PDCA
Telegram
Бабаева, к доске!
Почему «точка оценки» должна быть местом и временем
Вот вы идете к какой-то цели и знаете цикл PDCA (plan-do-check-act), значит понимаете как важно оценивать сделанное за итерацию и корректировать план на следующий период.
Вы тратите время на plan и на…
Вот вы идете к какой-то цели и знаете цикл PDCA (plan-do-check-act), значит понимаете как важно оценивать сделанное за итерацию и корректировать план на следующий период.
Вы тратите время на plan и на…
Чем я могу помочь?
Сосредоточьтесь и попробуйте вспомнить, когда вы в последний раз задавали кому-то вопрос «чем я могу помочь?». И не с интонацией в стиле «разбирайтесь сами», а прям с тем самым желанием помочь.
Естественная реакция большинства менеджеров на проблему или затык — взять всё в свои руки и по шагам всем рассказать, что и как надо сделать. Микроменеджмент спешит на помощь! Часто я сам веду себя так, дефолтные реакции очень сложно осознать и побороть.
Есть ситуации, когда действительно надо быстро и четко отработать какую-то хрень. Но таких меньшинство. Обычно эта хрень не так критична, поэтому вместо раздавания приказов можно качнуть команду или человека простым вопросом: «чем я могу помочь?».
Крутая штука в том, что после этого вопроса вас перестают воспринимать как ещё одну угрозу и начинают думать более свободно. Часто в итоге человек или команда сами все делают или чинят. Если реакция не такая идеальная, а такое будет случаться регулярно, то всё равно советы и рекомендации зайдут уже намного лучше. Если находится, чем реально вы можете помочь, то ещё лучше. Поделать что-то руками, лучше понять, что и как происходит в команде, процессе, продукте — это офигенный бонус.
Сосредоточьтесь и попробуйте вспомнить, когда вы в последний раз задавали кому-то вопрос «чем я могу помочь?». И не с интонацией в стиле «разбирайтесь сами», а прям с тем самым желанием помочь.
Естественная реакция большинства менеджеров на проблему или затык — взять всё в свои руки и по шагам всем рассказать, что и как надо сделать. Микроменеджмент спешит на помощь! Часто я сам веду себя так, дефолтные реакции очень сложно осознать и побороть.
Есть ситуации, когда действительно надо быстро и четко отработать какую-то хрень. Но таких меньшинство. Обычно эта хрень не так критична, поэтому вместо раздавания приказов можно качнуть команду или человека простым вопросом: «чем я могу помочь?».
Крутая штука в том, что после этого вопроса вас перестают воспринимать как ещё одну угрозу и начинают думать более свободно. Часто в итоге человек или команда сами все делают или чинят. Если реакция не такая идеальная, а такое будет случаться регулярно, то всё равно советы и рекомендации зайдут уже намного лучше. Если находится, чем реально вы можете помочь, то ещё лучше. Поделать что-то руками, лучше понять, что и как происходит в команде, процессе, продукте — это офигенный бонус.
Шаблон организации проекта в Trello
Собрал в trello набор досок, которые частями или полностью использовал для организации уже приличного числа проектов в течение многих лет. И использую до сих пор. Изначальная идея была подсмотрена у замечательной компании thoughtbot, с неё же началась моя любовь к trello. Но основа — пост компании UserVoice.
Этот набор досок немного перекошен в сторону разработки и адаптирован под свои заморочки. Но легко применим для многих других случаев от дизайна до стройки.
В основе — канбан и идея конвеера, по которому движутся задачи. Для удобства понимания на досках в виде задач оставлены комментарии, чтобы вообще не приходилось думать.
Подробнее описал в посте https://telegra.ph/SHablon-organizacii-proekta-v-Trello-09-04
Сами доски собраны в одной команде в trello: https://trello.com/onehandclapping_demo
Собрал в trello набор досок, которые частями или полностью использовал для организации уже приличного числа проектов в течение многих лет. И использую до сих пор. Изначальная идея была подсмотрена у замечательной компании thoughtbot, с неё же началась моя любовь к trello. Но основа — пост компании UserVoice.
Этот набор досок немного перекошен в сторону разработки и адаптирован под свои заморочки. Но легко применим для многих других случаев от дизайна до стройки.
В основе — канбан и идея конвеера, по которому движутся задачи. Для удобства понимания на досках в виде задач оставлены комментарии, чтобы вообще не приходилось думать.
Подробнее описал в посте https://telegra.ph/SHablon-organizacii-proekta-v-Trello-09-04
Сами доски собраны в одной команде в trello: https://trello.com/onehandclapping_demo
Telegraph
Шаблон организации проекта в Trello
Описание набора канбан-досок в Trello для организации работы над проектом или продуктом. Доски можно посмотреть вживую и утащить себе, используя функцию Copy Board: https://trello.com/onehandclapping_demo Референсы Схема вдохновлена работой очень крутых ребят…