Хлопок одной ладони — это канал от менеджера для менеджеров.
Тут будут мои мысли, чужие мысли, мой опыт, чужой опыт, моя боль, чужая боль, мои ошибки, чужие ошибки, продолжите ряд. Все это в форме заметок, ссылок, репостов и прочих легальных форматов. Преимущественно все будет в мире 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 Референсы Схема вдохновлена работой очень крутых ребят…
Конспект курса «Управление проектами, людьми и собой» Николая Товеровского
Последние несколько месяцев часто обращаюсь к записям, которые делал на курсе Товеровскго уже больше 3 лет назад. Оказалось, что в моей новой команде не все знают, что такое флексить, зачем нужно прибивать гусеницу и фиксировать дедлайн, почему именно исполнитель понимает задачу, что на самом деле значит «сделать», почему важно делать не в притык и концентрироваться на пользе.
Это нормально, хоть и непривычно. Раньше я работал преимущественно в разработке на заказ или маленьких продуктовых командах, где эти принципы и подходы часто были необходимы для выживания и развития. В функциональном отделе большой успешной компании вопрос о выживании как правило не стоит очень остро, но повышение качества и скорости работы всегда актуально.
Про "fixed price, fixed budget, flexible scope" (ФФФ) я впервые прочитал у 37signals (теперь просто basecamp), но в России именно Бюро Горбунова, их статьи и курсы — один из основных распространителей подхода.
Курс Николай проводит до сих пор. Это не реклама, но я искренне до сих пор советую его всем, кто причастен к управлению в IT, а иногда советую и тем, кто не причастен, но хочет сделать свою работу лучше.
Оцифрованный конспект доступен по ссылке, все три дня в виде коротких заметок и цитат.
https://telegra.ph/Konspekt-kursa-Upravlenie-proektami-lyudmi-i-soboj-Nikolaya-Toverovskogo-09-01
Последние несколько месяцев часто обращаюсь к записям, которые делал на курсе Товеровскго уже больше 3 лет назад. Оказалось, что в моей новой команде не все знают, что такое флексить, зачем нужно прибивать гусеницу и фиксировать дедлайн, почему именно исполнитель понимает задачу, что на самом деле значит «сделать», почему важно делать не в притык и концентрироваться на пользе.
Это нормально, хоть и непривычно. Раньше я работал преимущественно в разработке на заказ или маленьких продуктовых командах, где эти принципы и подходы часто были необходимы для выживания и развития. В функциональном отделе большой успешной компании вопрос о выживании как правило не стоит очень остро, но повышение качества и скорости работы всегда актуально.
Про "fixed price, fixed budget, flexible scope" (ФФФ) я впервые прочитал у 37signals (теперь просто basecamp), но в России именно Бюро Горбунова, их статьи и курсы — один из основных распространителей подхода.
Курс Николай проводит до сих пор. Это не реклама, но я искренне до сих пор советую его всем, кто причастен к управлению в IT, а иногда советую и тем, кто не причастен, но хочет сделать свою работу лучше.
Оцифрованный конспект доступен по ссылке, все три дня в виде коротких заметок и цитат.
https://telegra.ph/Konspekt-kursa-Upravlenie-proektami-lyudmi-i-soboj-Nikolaya-Toverovskogo-09-01
Telegraph
Конспект курса «Управление проектами, людьми и собой» Николая Товеровского
Конспект курса «Управление проектами, людьми и собой» Николая Товеровского в апреле 2016 года. Записи делались для себя, частично отредактированы. Сам курс оставил очень приятное впечатление, как и сам Николай. Пользы было много, советую сходить даже тем…
Про стори поинты от создателя стори поинтов
Я всегда не любил стори поинты, как и оценки для задач и проектов. Если только задуматься, насколько целая индустрия полагается на умение (точнее неумение) угадывать будущее, то сразу отчаяние накатывает. Про движение #NoEstimates и то, как оно немного сдвинуло моё сознание в отношении эстимейтов, я расскажу отдельно. Сегодня хочу поделиться замечательной статьёй про стори поинты от их непосредственного создателя.
В статье прекрасно всё с первого предложения: "I like to say that I may have invented story points, and if I did, I’m sorry now."
Рон Джеффрис рассказывает, как концепт родился в их тусовке XP из идеальных дней, которые домножали на коэффициент, чтобы не путать стейкхолдеров. Как он должен был восстановить равновесие силы, а не ввергнуть её во мрак. Как неплохая идея в итоге чаще всего используется неправильно.
Ключевые моменты:
⁃ стори поинты нельзя использовать, чтобы предсказать, когда что-то будет сделано
⁃ трекать, насколько оценка в стори поинтах, соотнеслась с затратами времени бесполезно
⁃ сравнивать команды на основе умения делать оценки вредно
⁃ эстимейты чаще всего являются попыткой угадать, нельзя воспринимать их как обещание и коммит
⁃ важнее определять самые важные и приоритетные вещи для работы и делать их быстро
⁃ чтобы это было возможно надо резать задачи на кусочки, каждый из которых несёт ценность; стори поинты и оценки в этом не помогают
⁃ Рон идет дальше и говорит, что идеи итераций и спринтов также вторичны и не особо нужны перед знанием, какие следующие фичи принесут наибольшую ценность
⁃ честный ответ на «когда это будет сделано?» при фиксации списка фич «никто на самом деле не знает»
⁃ гораздо лучше идти от обратного: выбрать дату релиза пользователям и до неё сделать как можно больше полезного; оценки и стори поинты тут опять не помогают
Несколько цитат
> The best way to deliver value isn’t more, more, more, it’s to do small valuable things frequently. If instead of estimating stories, we slice them down to “small enough”, we can come to a smooth flow of value, delivering all the time.
> I’ll go further: I’d prefer to avoid iteration or Sprint planning entirely. We wouldn’t work to fill up a budget for the next few weeks: we’d work to have a list of the few most important next things to do.
> It is common practice to make a list of essential features, think about them for a while, and then decide that they define the next release of our product. The next question, of course, is “when will all this be done?”
> The answer is that no one knows.
> It’s far better to pick a close-in date for the next release to customers, and pick as much good stuff into that release as possible. Estimating, be it in story points or gummi bears or even time, gets in the way of this. Where possible, in my opinion, it’s best avoided.
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
Я всегда не любил стори поинты, как и оценки для задач и проектов. Если только задуматься, насколько целая индустрия полагается на умение (точнее неумение) угадывать будущее, то сразу отчаяние накатывает. Про движение #NoEstimates и то, как оно немного сдвинуло моё сознание в отношении эстимейтов, я расскажу отдельно. Сегодня хочу поделиться замечательной статьёй про стори поинты от их непосредственного создателя.
В статье прекрасно всё с первого предложения: "I like to say that I may have invented story points, and if I did, I’m sorry now."
Рон Джеффрис рассказывает, как концепт родился в их тусовке XP из идеальных дней, которые домножали на коэффициент, чтобы не путать стейкхолдеров. Как он должен был восстановить равновесие силы, а не ввергнуть её во мрак. Как неплохая идея в итоге чаще всего используется неправильно.
Ключевые моменты:
⁃ стори поинты нельзя использовать, чтобы предсказать, когда что-то будет сделано
⁃ трекать, насколько оценка в стори поинтах, соотнеслась с затратами времени бесполезно
⁃ сравнивать команды на основе умения делать оценки вредно
⁃ эстимейты чаще всего являются попыткой угадать, нельзя воспринимать их как обещание и коммит
⁃ важнее определять самые важные и приоритетные вещи для работы и делать их быстро
⁃ чтобы это было возможно надо резать задачи на кусочки, каждый из которых несёт ценность; стори поинты и оценки в этом не помогают
⁃ Рон идет дальше и говорит, что идеи итераций и спринтов также вторичны и не особо нужны перед знанием, какие следующие фичи принесут наибольшую ценность
⁃ честный ответ на «когда это будет сделано?» при фиксации списка фич «никто на самом деле не знает»
⁃ гораздо лучше идти от обратного: выбрать дату релиза пользователям и до неё сделать как можно больше полезного; оценки и стори поинты тут опять не помогают
Несколько цитат
> The best way to deliver value isn’t more, more, more, it’s to do small valuable things frequently. If instead of estimating stories, we slice them down to “small enough”, we can come to a smooth flow of value, delivering all the time.
> I’ll go further: I’d prefer to avoid iteration or Sprint planning entirely. We wouldn’t work to fill up a budget for the next few weeks: we’d work to have a list of the few most important next things to do.
> It is common practice to make a list of essential features, think about them for a while, and then decide that they define the next release of our product. The next question, of course, is “when will all this be done?”
> The answer is that no one knows.
> It’s far better to pick a close-in date for the next release to customers, and pick as much good stuff into that release as possible. Estimating, be it in story points or gummi bears or even time, gets in the way of this. Where possible, in my opinion, it’s best avoided.
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
Что впитывать начинающему менеджеру
Последние несколько недель среди прочего постепенно перевожу одного из специалистов QA в роль лида команды тестировщиков. Помимо основной работы на него ложится часть менеджерских забот и хлопот.
В процессе возник вопрос: что можно почитать и где подучиться? Я уже несколько раз отвечал на него для разных людей, но каждый раз вспоминал и составлял список заново. В этот раз зафиксировал, в будущем буду дополнять или изменять.
Речь именно про часть управления процессами и людьми, а не продуктами. Отмечу, что в моём идеальном мире с радугами и пони эти знания полезны не только менеджерам и руководителям, а всем ребятам, кто работает с проектам и людьми, не ограничиваясь сферой IT.
1. Книги https://basecamp.com/books, блог https://m.signalvnoise.com/ и подкаст https://rework.fm/ от компании Basecamp (ex 37signals). Советую, т.к. во многом разделяю их философию. Не везде и не всё применимо в наших реалиях, но вектор правильный. Недавно они выложили в паблик новую книгу https://basecamp.com/shapeup, изучаю прямо сейчас.
2. Курс Товеровского и Бюро https://bureau.ru/educenter/fff/ — как правило советую всем, кто относится к работе в IT, даже если не руководитель, но последним особенно. В сети есть множество неплохих конспектов, мой есть выше в этом канале, на сайте бюро много советов, а у Николая выходит книга на базе курса https://bureau.ru/books/fff/demo/3
3. Для академических целей можно почитать Голдратта. Например, «Цель». Это классика, но с ней надо аккуратно в интерпретациях. На идеях Голдратта организовано много управленческих подходов. Мне нравится ментальная модель конвеера для процессов разработки, но не все её разделяют.
4. Книга "No Estimates" https://oikosofyseries.com/no-estimates-book-order. Интересна для понимания, что можно делать по-другому, и опыт десятилетий в индустрии не обязательно гарантирует, что какая-либо практика полезная и хорошая.
5. По работе с людьми всегда и всем советовал книгу «Общаться с ребёнком. Как?» Гиппенрейтер. Давно не перечитывал, но в своё время много откровений получил оттуда.
6. Ещё в сторону понимания людей и себя: «The Power of Habit» by Charles Duhigg.
7. Советую критично относиться к разрозненным статьям, блогам и телеграм-каналам (такая вот ирония), больше доверять авторскому опыту, но использовать это всё как поддержку для книг, а не замену.
Последние несколько недель среди прочего постепенно перевожу одного из специалистов QA в роль лида команды тестировщиков. Помимо основной работы на него ложится часть менеджерских забот и хлопот.
В процессе возник вопрос: что можно почитать и где подучиться? Я уже несколько раз отвечал на него для разных людей, но каждый раз вспоминал и составлял список заново. В этот раз зафиксировал, в будущем буду дополнять или изменять.
Речь именно про часть управления процессами и людьми, а не продуктами. Отмечу, что в моём идеальном мире с радугами и пони эти знания полезны не только менеджерам и руководителям, а всем ребятам, кто работает с проектам и людьми, не ограничиваясь сферой IT.
1. Книги https://basecamp.com/books, блог https://m.signalvnoise.com/ и подкаст https://rework.fm/ от компании Basecamp (ex 37signals). Советую, т.к. во многом разделяю их философию. Не везде и не всё применимо в наших реалиях, но вектор правильный. Недавно они выложили в паблик новую книгу https://basecamp.com/shapeup, изучаю прямо сейчас.
2. Курс Товеровского и Бюро https://bureau.ru/educenter/fff/ — как правило советую всем, кто относится к работе в IT, даже если не руководитель, но последним особенно. В сети есть множество неплохих конспектов, мой есть выше в этом канале, на сайте бюро много советов, а у Николая выходит книга на базе курса https://bureau.ru/books/fff/demo/3
3. Для академических целей можно почитать Голдратта. Например, «Цель». Это классика, но с ней надо аккуратно в интерпретациях. На идеях Голдратта организовано много управленческих подходов. Мне нравится ментальная модель конвеера для процессов разработки, но не все её разделяют.
4. Книга "No Estimates" https://oikosofyseries.com/no-estimates-book-order. Интересна для понимания, что можно делать по-другому, и опыт десятилетий в индустрии не обязательно гарантирует, что какая-либо практика полезная и хорошая.
5. По работе с людьми всегда и всем советовал книгу «Общаться с ребёнком. Как?» Гиппенрейтер. Давно не перечитывал, но в своё время много откровений получил оттуда.
6. Ещё в сторону понимания людей и себя: «The Power of Habit» by Charles Duhigg.
7. Советую критично относиться к разрозненным статьям, блогам и телеграм-каналам (такая вот ирония), больше доверять авторскому опыту, но использовать это всё как поддержку для книг, а не замену.
Basecamp
Books we’ve written
On top of making Basecamp, we write books about what we’ve learned running our own business. They’re filled with practical advice you won’t find anywhere else.
Выживают наиболее приспособленные
В эволюционном процессе выживает не сильнейший, а тот, кто адаптировался быстрее и лучше. Survival of the fittest.
Точно так же выживают компании и команды, которые лучше адаптируются к реальности, к изменениям, будь это изменения требований, начальства, рынка, трендов. Их процесс более устойчив, неизбежность перемен для них норма. Привет Таллебу и его антихрупкости.
Крутая команда строит свой процесс так, что адаптация и постоянное улучшение становятся частью ежедневной деятельности. В прошлое такая команда смотрит для анализа и выводов, чтобы не наступать на прежние грабли.
Обречённая команда не хочет менять процесс, считая его подходящим. Она фокусируется не на бизнес-ценности, а, например, абстрактном качестве и ненужных деталях или только на себе. В прошлое такая команда смотрит с ностальгией, но не делает выводов, поэтому грабли повторяются.
Адаптация — это не «прогибаться под изменчивый мир», а про осознанность, честность перед собой, умение спорить и договариваться, ясная оценка происходящего, принимать решения и их последствия, признавать риски, учиться на ошибках. И в результате меняться, эволюционировать.
Обречённая команда может стать крутой и выжить. Это не просто и требует сдвигов сознания, ломки, местами признания слабости и просьбы помощи. Но выживание того стоит.
В эволюционном процессе выживает не сильнейший, а тот, кто адаптировался быстрее и лучше. Survival of the fittest.
Точно так же выживают компании и команды, которые лучше адаптируются к реальности, к изменениям, будь это изменения требований, начальства, рынка, трендов. Их процесс более устойчив, неизбежность перемен для них норма. Привет Таллебу и его антихрупкости.
Крутая команда строит свой процесс так, что адаптация и постоянное улучшение становятся частью ежедневной деятельности. В прошлое такая команда смотрит для анализа и выводов, чтобы не наступать на прежние грабли.
Обречённая команда не хочет менять процесс, считая его подходящим. Она фокусируется не на бизнес-ценности, а, например, абстрактном качестве и ненужных деталях или только на себе. В прошлое такая команда смотрит с ностальгией, но не делает выводов, поэтому грабли повторяются.
Адаптация — это не «прогибаться под изменчивый мир», а про осознанность, честность перед собой, умение спорить и договариваться, ясная оценка происходящего, принимать решения и их последствия, признавать риски, учиться на ошибках. И в результате меняться, эволюционировать.
Обречённая команда может стать крутой и выжить. Это не просто и требует сдвигов сознания, ломки, местами признания слабости и просьбы помощи. Но выживание того стоит.
"Shape Up" by Ryan Singer from Basecamp
Слежу за тем, что делают ребята из Basecamp (ex. 37signals) уже лет 10, если не больше. Во многом разделяю их идеи и философию.
Shape Up прочитал с огромным удовольствием. Некоторые идеи уже применял в работе раньше, что-то начал внедрять в процессе прочтения, до некоторых вещей еще предстоит дорасти.
Книга очень практичная, описывает конкретные процессы, которые команда Basecamp использует в своей работе, и принципы, на которых базируются эти процессы.
Собрал ключевые идеи, принципы и цитаты.
https://telegra.ph/Recenziya-na-knigu-Shape-Up-by-Ryan-Singer-from-Basecamp-10-20
Слежу за тем, что делают ребята из Basecamp (ex. 37signals) уже лет 10, если не больше. Во многом разделяю их идеи и философию.
Shape Up прочитал с огромным удовольствием. Некоторые идеи уже применял в работе раньше, что-то начал внедрять в процессе прочтения, до некоторых вещей еще предстоит дорасти.
Книга очень практичная, описывает конкретные процессы, которые команда Basecamp использует в своей работе, и принципы, на которых базируются эти процессы.
Собрал ключевые идеи, принципы и цитаты.
https://telegra.ph/Recenziya-na-knigu-Shape-Up-by-Ryan-Singer-from-Basecamp-10-20
Telegraph
Рецензия на книгу "Shape Up" by Ryan Singer from Basecamp
Shape Up рассказывает в деталях и по шагам, как налажен процесс работы над продуктом в Basecamp от идеи до реализации. Таким образом, чтобы делать действительно ту работу, которая имеет смысл и значение, и делать её вовремя. "Stop Running in Circles and Ship…
Работать нормально
В одной из своих рассылок vas3k (@vas3k_channel) написал:
> «Палю моднейший тренд в айти: работать нормально.»
Фраза меня зацепила. Далее по тексту было пояснение в контексте статьи про 10x engineers. Моё «нормально» созвучно, но всё-таки отличается.
В реальности большинство людей хотят работать нормально. Только это «нормально» у каждого своё. Это как многие злодеи в фильмах думают, что творят добро, только по-своему.
Мне стало любопытно, и я спросил несколько друзей: что для них значит «работать нормально»? Формат ответа был любой, никаких ограничений.
Получилось любопытно. По ссылке несколько ответов и в конце мой.
https://telegra.ph/CHto-znachit-rabotat-normalno-10-28
В одной из своих рассылок vas3k (@vas3k_channel) написал:
> «Палю моднейший тренд в айти: работать нормально.»
Фраза меня зацепила. Далее по тексту было пояснение в контексте статьи про 10x engineers. Моё «нормально» созвучно, но всё-таки отличается.
В реальности большинство людей хотят работать нормально. Только это «нормально» у каждого своё. Это как многие злодеи в фильмах думают, что творят добро, только по-своему.
Мне стало любопытно, и я спросил несколько друзей: что для них значит «работать нормально»? Формат ответа был любой, никаких ограничений.
Получилось любопытно. По ссылке несколько ответов и в конце мой.
https://telegra.ph/CHto-znachit-rabotat-normalno-10-28
Telegraph
Что значит «работать нормально»
Эта фраза в одной из рассылок vas3k'а меня зацепила. Далее по тексту было пояснение в контексте статьи про 10x engineers. Я тут же понял, что моё «нормально» созвучно, но всё-таки отличается.
Конспект PM Starter Pack
https://pmstarterpack.onfielder.com/ — этот небольшой гайд запустился на Product Hunt в мае и ссылку на "Practical guide on how to get started in product management" можно было увидеть во многих околопродуктовых каналах и рассылках.
На прошлой неделе добрался посмотреть, что же там внутри. К сожалению practical этот гайд назвать можно с трудом. Внутри достаточно общие и абстрактные истории. Вместо конкретики в большинстве ситуаций подборки ссылок на статьи. Ryan Hover в комментарии на странице гайда на PH просто написал, что советует начинающим продактам копать свои сайд проекты, и он прав.
Сделал одностраничный конспект. Рекомендую только действительно начинающим ребятам.
https://telegra.ph/Konspekt-PM-Starter-Pack-10-31
https://pmstarterpack.onfielder.com/ — этот небольшой гайд запустился на Product Hunt в мае и ссылку на "Practical guide on how to get started in product management" можно было увидеть во многих околопродуктовых каналах и рассылках.
На прошлой неделе добрался посмотреть, что же там внутри. К сожалению practical этот гайд назвать можно с трудом. Внутри достаточно общие и абстрактные истории. Вместо конкретики в большинстве ситуаций подборки ссылок на статьи. Ryan Hover в комментарии на странице гайда на PH просто написал, что советует начинающим продактам копать свои сайд проекты, и он прав.
Сделал одностраничный конспект. Рекомендую только действительно начинающим ребятам.
https://telegra.ph/Konspekt-PM-Starter-Pack-10-31
Onfielder
VIKINGTOTO > Situs Toto Online Terpercaya Amanah Pasti Bayar
VIKINGTOTO adalah situs toto online yang terkenal dengan kepercayaan dan amanah serta memiliki banyak pilihan game gacor dengan kategori slot, casino hingga togel populer yang memiliki hadiah terbesar di Indonesia hari ini.
«Хьюстон, у нас всё хорошо (на самом деле нет)»
Писать в канал после 5 месяцев тишины — почти восстать из мёртвых.
Нет, работы не стало меньше, скорее наоборот. Нет, это не из-за самоизоляции, хоть она и немного способствует.
Просто изменилась структура времени и следом за ним внимания. Хотя чаще происходит наоборот.
Возвращение в поток началось с ревизии, приведения в порядок и разбора старых записей. Поэтому сегодня делюсь заметками с лекции Людвига Быстроновского, которую посетил ещё в 2015-м.
Её название удивительно созвучно текущему времени. Но мы же тут про менеджмент, поэтому не буду слишком обобщать.
Людвиг очень круто мыслит, выступает и пишет. Вот несколько отличных цитат:
> Я могу пойти в настройки и сказать уведомлению: «а ну-ка иди нахуй»
> Как избавиться от микроменеджмента: надо дать людям обосраться
> Вы не можете контролировать ситуацию. Единственное, что вы можете контролировать — это себя
На днях поделюсь конспектом с ещё одной лекции Людвига.
И да, в дополнение к каналу теперь есть простой сайт. Или в дополнение к сайту теперь остался канал. Как пойдёт.
https://onehandclapping.ru/ldwg-houston-we-are-fine-or-not.html
Писать в канал после 5 месяцев тишины — почти восстать из мёртвых.
Нет, работы не стало меньше, скорее наоборот. Нет, это не из-за самоизоляции, хоть она и немного способствует.
Просто изменилась структура времени и следом за ним внимания. Хотя чаще происходит наоборот.
Возвращение в поток началось с ревизии, приведения в порядок и разбора старых записей. Поэтому сегодня делюсь заметками с лекции Людвига Быстроновского, которую посетил ещё в 2015-м.
Её название удивительно созвучно текущему времени. Но мы же тут про менеджмент, поэтому не буду слишком обобщать.
Людвиг очень круто мыслит, выступает и пишет. Вот несколько отличных цитат:
> Я могу пойти в настройки и сказать уведомлению: «а ну-ка иди нахуй»
> Как избавиться от микроменеджмента: надо дать людям обосраться
> Вы не можете контролировать ситуацию. Единственное, что вы можете контролировать — это себя
На днях поделюсь конспектом с ещё одной лекции Людвига.
И да, в дополнение к каналу теперь есть простой сайт. Или в дополнение к сайту теперь остался канал. Как пойдёт.
https://onehandclapping.ru/ldwg-houston-we-are-fine-or-not.html
Хлопок Одной Ладони
«Хьюстон, у нас все хорошо (на самом деле нет)», лекция Людвига Быстроновского
Ниже мои заметки-конспект с лекции Людвига Быстроновского «Хьюстон, у нас всё хорошо (на самом деле нет)» про наведение порядка в дизайн-проектах (и не только). Я посещал лекцию в Петербурге весной 2015 года.
«Дизайн+1»
Продолжаю разбирать конспекты и записи. Эту лекцию Людвига Быстроновского я лучше всего помню по новому для себя факту: если в меню ресторана есть салат «Цезарь», его берут чаще остальных в 8 раз.
Но лекция, конечно, не про салаты. А про профессионализм. И не только дизайнеров а вообще всех. Вот, например, несколько мыслей:
> Чтобы научиться делать проекты, надо делать проекты.
> Не надо останавливаться на технологии, останавливаться надо на решении задач.
> Если люди делают хорошо, хули лезть.
> Можно за 15 минут сделать много, если ты умный, но если ты 8 часов как чмо, то и письмо напишешь как чмо.
Как и в прошлый раз советую посмотреть видео. И помните: «Просто надо хуячить».
https://onehandclapping.ru/ldwg-design-plus-one.html
Продолжаю разбирать конспекты и записи. Эту лекцию Людвига Быстроновского я лучше всего помню по новому для себя факту: если в меню ресторана есть салат «Цезарь», его берут чаще остальных в 8 раз.
Но лекция, конечно, не про салаты. А про профессионализм. И не только дизайнеров а вообще всех. Вот, например, несколько мыслей:
> Чтобы научиться делать проекты, надо делать проекты.
> Не надо останавливаться на технологии, останавливаться надо на решении задач.
> Если люди делают хорошо, хули лезть.
> Можно за 15 минут сделать много, если ты умный, но если ты 8 часов как чмо, то и письмо напишешь как чмо.
Как и в прошлый раз советую посмотреть видео. И помните: «Просто надо хуячить».
https://onehandclapping.ru/ldwg-design-plus-one.html
Хлопок Одной Ладони
«Дизайн+1», лекция Людвига Быстроновского
Ниже мои заметки-конспект с лекции Людвига Быстроновского «Дизайн+1» про работу суммы навыков и про общие черты хороших дизайнеров (и не только). Я посещал лекцию в Петербурге весной 2015 года.
Rams
Продолжительное время я считал, что не предрасположен к пониманию и тем более созданию дизайна. Постепенно осознал, что это не совсем так, и на самом деле мне очень важен дизайн вещей и инструментов, которые меня окружают. Более того, в некоторых случаях я оказался крайне замороченным.
В этом контексте мне очень понравился фильм Rams независимого режиссёра Gary Hustwit. Личность немецкого дизайнера Дитера Рамса привлекла внимание, а его философия "less, but better" оказалась очень созвучна с моим ощущением дизайна и мира.
Дитер Рамс известен как дизайнер множества продуктов фирмы Braun, мебели от компании Vitsœ, а также автор 10 принципов хорошего дизайна. Его работа стала вдохновением для многих поколений дизайнеров.
> "Less, but better" is not just a design concept, it's also about our behavior. Less would be better everywhere.
Посмотрите обязательно.
https://onehandclapping.ru/rams
Продолжительное время я считал, что не предрасположен к пониманию и тем более созданию дизайна. Постепенно осознал, что это не совсем так, и на самом деле мне очень важен дизайн вещей и инструментов, которые меня окружают. Более того, в некоторых случаях я оказался крайне замороченным.
В этом контексте мне очень понравился фильм Rams независимого режиссёра Gary Hustwit. Личность немецкого дизайнера Дитера Рамса привлекла внимание, а его философия "less, but better" оказалась очень созвучна с моим ощущением дизайна и мира.
Дитер Рамс известен как дизайнер множества продуктов фирмы Braun, мебели от компании Vitsœ, а также автор 10 принципов хорошего дизайна. Его работа стала вдохновением для многих поколений дизайнеров.
> "Less, but better" is not just a design concept, it's also about our behavior. Less would be better everywhere.
Посмотрите обязательно.
https://onehandclapping.ru/rams
Хлопок Одной Ладони
Rams и 10 принципов хорошего дизайна
Про фильм о немецком дизайнере Дитере Рамсе и его философии “Less but better”