AD
@oneumyvakin , можешь поподробнее про личное лидерство? Незнакомый мне термин, хотелось бы ссылку или книжку какую, чтобы понять о чем это вообще.
+1
Size: a a a
2020 April 11
МС
Здравствуйте. Еще во время митапа хотел уточнить несколько моментов
1) Когда мы говорим о развитии, то вообще неплохо было бы обсудить, а какое оно бывает. Мы как-то, вроде, пошли только в "хардовое": автоматизация, нагрузка, безопасность, ну или смена деятельности уход в разработку, девопс. Но помимо этого, некоторым может было бы интересно узнать, а что и как качать если хочешь стать прОдуктом, или аналитиком.
2) Исходя из первого, к сожалению, ваш вектор развития не всегда может совпадать с возможностями компании и ее потребностями. Да, есть случаи "мы не знали, что автоматизация вообще существует, вот и не пробовали", или "ну, у нас есть условный Петя, он вроде делает все "технические" задачи, мы и не думали, что вам тоже может быть интеерсно". Но бывает и так, что некоторые вещи вообще нереализумы в рамках стратегии компании, или как с автоматизацией, не могут быть введены по ряду причин, о которых рядовой сотрудник может и не знать(элемнтарно, это экономическое обоснование), или в принципе сложность внедрения такого функционала в компании.(тот же девопс есть не у всех, и на хотелках иногда этого не сделаешь, к сожалению). Так что рекомендация "ставить вопрос ребром", касательно разговора с руководителем, может быть не лучшей в некоторых случаях.(я как номинальный руководитель не хотел бы потерять работника, только потому что он думает, что я не хочу его развивать, а не потому что он это знает). Но поговорить это хороший совет, но узнав все же, а что надо, и потом решив, хочется ли вам этого. Кстати, было бы неплохо обсудить, а с каким именно руководителем говорить менеджер/QA Lead/ руководитель R&D или его аналог.
3) Ну и да, что же делать, если ваши хотения и потребности компании расходятся. Соглашаться, на то что вам предлагают, или пробовать это обсудить с кем-то еще, ждать, или сразу пробовать уходить.
1) Когда мы говорим о развитии, то вообще неплохо было бы обсудить, а какое оно бывает. Мы как-то, вроде, пошли только в "хардовое": автоматизация, нагрузка, безопасность, ну или смена деятельности уход в разработку, девопс. Но помимо этого, некоторым может было бы интересно узнать, а что и как качать если хочешь стать прОдуктом, или аналитиком.
2) Исходя из первого, к сожалению, ваш вектор развития не всегда может совпадать с возможностями компании и ее потребностями. Да, есть случаи "мы не знали, что автоматизация вообще существует, вот и не пробовали", или "ну, у нас есть условный Петя, он вроде делает все "технические" задачи, мы и не думали, что вам тоже может быть интеерсно". Но бывает и так, что некоторые вещи вообще нереализумы в рамках стратегии компании, или как с автоматизацией, не могут быть введены по ряду причин, о которых рядовой сотрудник может и не знать(элемнтарно, это экономическое обоснование), или в принципе сложность внедрения такого функционала в компании.(тот же девопс есть не у всех, и на хотелках иногда этого не сделаешь, к сожалению). Так что рекомендация "ставить вопрос ребром", касательно разговора с руководителем, может быть не лучшей в некоторых случаях.(я как номинальный руководитель не хотел бы потерять работника, только потому что он думает, что я не хочу его развивать, а не потому что он это знает). Но поговорить это хороший совет, но узнав все же, а что надо, и потом решив, хочется ли вам этого. Кстати, было бы неплохо обсудить, а с каким именно руководителем говорить менеджер/QA Lead/ руководитель R&D или его аналог.
3) Ну и да, что же делать, если ваши хотения и потребности компании расходятся. Соглашаться, на то что вам предлагают, или пробовать это обсудить с кем-то еще, ждать, или сразу пробовать уходить.
МС
Извиняюсь, что много)
МС
Ну и да, касательно митапа про руководителей, интересно было бы узнать, будет ли там обсуждаться тоже вопрос развития? Чем выше ступень, тем иногда сложнее узнать что-то "новенькое", но иногда нет желания покидать компанию, а повышение ЗП хотелось бы. Есть и такие случаи. Что можно начать "продавать" и как подойти к этому вопросу. Увеличивать технические компетенции, брать на себя обучающие, руководящие функции(дополнительные) и как лучше подходить к этому вопросу
ОН
@sobolm
Ну и да, касательно митапа про руководителей, интересно было бы узнать, будет ли там обсуждаться тоже вопрос развития? Привет. Будет.2020 April 12
А
Здравствуйте. Еще во время митапа хотел уточнить несколько моментов
1) Когда мы говорим о развитии, то вообще неплохо было бы обсудить, а какое оно бывает. Мы как-то, вроде, пошли только в "хардовое": автоматизация, нагрузка, безопасность, ну или смена деятельности уход в разработку, девопс. Но помимо этого, некоторым может было бы интересно узнать, а что и как качать если хочешь стать прОдуктом, или аналитиком.
2) Исходя из первого, к сожалению, ваш вектор развития не всегда может совпадать с возможностями компании и ее потребностями. Да, есть случаи "мы не знали, что автоматизация вообще существует, вот и не пробовали", или "ну, у нас есть условный Петя, он вроде делает все "технические" задачи, мы и не думали, что вам тоже может быть интеерсно". Но бывает и так, что некоторые вещи вообще нереализумы в рамках стратегии компании, или как с автоматизацией, не могут быть введены по ряду причин, о которых рядовой сотрудник может и не знать(элемнтарно, это экономическое обоснование), или в принципе сложность внедрения такого функционала в компании.(тот же девопс есть не у всех, и на хотелках иногда этого не сделаешь, к сожалению). Так что рекомендация "ставить вопрос ребром", касательно разговора с руководителем, может быть не лучшей в некоторых случаях.(я как номинальный руководитель не хотел бы потерять работника, только потому что он думает, что я не хочу его развивать, а не потому что он это знает). Но поговорить это хороший совет, но узнав все же, а что надо, и потом решив, хочется ли вам этого. Кстати, было бы неплохо обсудить, а с каким именно руководителем говорить менеджер/QA Lead/ руководитель R&D или его аналог.
3) Ну и да, что же делать, если ваши хотения и потребности компании расходятся. Соглашаться, на то что вам предлагают, или пробовать это обсудить с кем-то еще, ждать, или сразу пробовать уходить.
1) Когда мы говорим о развитии, то вообще неплохо было бы обсудить, а какое оно бывает. Мы как-то, вроде, пошли только в "хардовое": автоматизация, нагрузка, безопасность, ну или смена деятельности уход в разработку, девопс. Но помимо этого, некоторым может было бы интересно узнать, а что и как качать если хочешь стать прОдуктом, или аналитиком.
2) Исходя из первого, к сожалению, ваш вектор развития не всегда может совпадать с возможностями компании и ее потребностями. Да, есть случаи "мы не знали, что автоматизация вообще существует, вот и не пробовали", или "ну, у нас есть условный Петя, он вроде делает все "технические" задачи, мы и не думали, что вам тоже может быть интеерсно". Но бывает и так, что некоторые вещи вообще нереализумы в рамках стратегии компании, или как с автоматизацией, не могут быть введены по ряду причин, о которых рядовой сотрудник может и не знать(элемнтарно, это экономическое обоснование), или в принципе сложность внедрения такого функционала в компании.(тот же девопс есть не у всех, и на хотелках иногда этого не сделаешь, к сожалению). Так что рекомендация "ставить вопрос ребром", касательно разговора с руководителем, может быть не лучшей в некоторых случаях.(я как номинальный руководитель не хотел бы потерять работника, только потому что он думает, что я не хочу его развивать, а не потому что он это знает). Но поговорить это хороший совет, но узнав все же, а что надо, и потом решив, хочется ли вам этого. Кстати, было бы неплохо обсудить, а с каким именно руководителем говорить менеджер/QA Lead/ руководитель R&D или его аналог.
3) Ну и да, что же делать, если ваши хотения и потребности компании расходятся. Соглашаться, на то что вам предлагают, или пробовать это обсудить с кем-то еще, ждать, или сразу пробовать уходить.
1) боюсь, что в сообществе QA мало кто может подсказать, какие скилы качать для продукта или аналитика :)
Чисто умозрительно, если есть культура и опыт QA, т.е. обеспечения качества, а не только его контроля, то многие функции что продакта, что аналитика и так уже должны выполняться (по крайней мере, из того, что я вижу со стороны, глядя на продактов, например). Довольно большая часть хард скилов на этих позициях будут плюс/минус общими, технологический стек, если смена позиции происходит в рамках одной компании/проекта так вообще один, поэтому сменить род деятельности не должно стать проблемой, а недостающие знания легко подтянуть по ходу дела.
Если есть опыт только контроля качества, то качать аналитику, инструменты моделирования, формирования и уточнения требованмй. Софт-скилы начинают иметь сильно большее значение- умение слышать, уточнять, доносить свою точку зрения и все, что с этим связано.
У нас в Плеске многие продакты это бывшие куашники, разработчики, а то и все вместе.
2) да, не везде могут пройти жесткие и затратные изменения, но это не повод не говорить об этом, а в идеале- сразу предлагать, заранее подготовив себе базу в виде конкретных предложений. Например, мы в команде начали пробовать менять процессы за полгода до того, как такой вопрос в принципе появился. И к моменту, когда изменения стали необходимы и востребованы всей командой, а не отдельными инженерами, у нас уже был этот опыт. Начать стоит с самого близкого и непосредственного руководителя, не стоит перескакивать через голову, это может вызвать конфликт, который врядли пойдет на пользу.
3) Если что-то предлагают- это уже прекрасно. Надо смотреть, насколько это совпадает с личными желаниями и как можно это совместить. Не предлагают- хуже. Но и это не повод. Если есть понимание того, что хочется, если что-то уже начал пробовать, то и развитие уже началось :) ну а дальше смотреть, если это никому не надо и текущее место в явном виде ограничивает, а то и запрещает, развитие и вариантов никаких, то тут поможет или участие в проекте "на стороне", ну или ничего уже тут не поможет.
"На стороне" может быть в том числе просто соседняя команда, где все то же самое, но совсем другое :)
Интересное предложение недавно видел, как раз на тему развития: если на текущем месте и в текущей компании нет того, у кого учиться, а менять компанию или проект не хочется, то попробовать найти ментора себе на стороне, с кем можно общаться, обсуждать и у кого учиться.
Чисто умозрительно, если есть культура и опыт QA, т.е. обеспечения качества, а не только его контроля, то многие функции что продакта, что аналитика и так уже должны выполняться (по крайней мере, из того, что я вижу со стороны, глядя на продактов, например). Довольно большая часть хард скилов на этих позициях будут плюс/минус общими, технологический стек, если смена позиции происходит в рамках одной компании/проекта так вообще один, поэтому сменить род деятельности не должно стать проблемой, а недостающие знания легко подтянуть по ходу дела.
Если есть опыт только контроля качества, то качать аналитику, инструменты моделирования, формирования и уточнения требованмй. Софт-скилы начинают иметь сильно большее значение- умение слышать, уточнять, доносить свою точку зрения и все, что с этим связано.
У нас в Плеске многие продакты это бывшие куашники, разработчики, а то и все вместе.
2) да, не везде могут пройти жесткие и затратные изменения, но это не повод не говорить об этом, а в идеале- сразу предлагать, заранее подготовив себе базу в виде конкретных предложений. Например, мы в команде начали пробовать менять процессы за полгода до того, как такой вопрос в принципе появился. И к моменту, когда изменения стали необходимы и востребованы всей командой, а не отдельными инженерами, у нас уже был этот опыт. Начать стоит с самого близкого и непосредственного руководителя, не стоит перескакивать через голову, это может вызвать конфликт, который врядли пойдет на пользу.
3) Если что-то предлагают- это уже прекрасно. Надо смотреть, насколько это совпадает с личными желаниями и как можно это совместить. Не предлагают- хуже. Но и это не повод. Если есть понимание того, что хочется, если что-то уже начал пробовать, то и развитие уже началось :) ну а дальше смотреть, если это никому не надо и текущее место в явном виде ограничивает, а то и запрещает, развитие и вариантов никаких, то тут поможет или участие в проекте "на стороне", ну или ничего уже тут не поможет.
"На стороне" может быть в том числе просто соседняя команда, где все то же самое, но совсем другое :)
Интересное предложение недавно видел, как раз на тему развития: если на текущем месте и в текущей компании нет того, у кого учиться, а менять компанию или проект не хочется, то попробовать найти ментора себе на стороне, с кем можно общаться, обсуждать и у кого учиться.
МС
Алексей
1) боюсь, что в сообществе QA мало кто может подсказать, какие скилы качать для продукта или аналитика :)
Чисто умозрительно, если есть культура и опыт QA, т.е. обеспечения качества, а не только его контроля, то многие функции что продакта, что аналитика и так уже должны выполняться (по крайней мере, из того, что я вижу со стороны, глядя на продактов, например). Довольно большая часть хард скилов на этих позициях будут плюс/минус общими, технологический стек, если смена позиции происходит в рамках одной компании/проекта так вообще один, поэтому сменить род деятельности не должно стать проблемой, а недостающие знания легко подтянуть по ходу дела.
Если есть опыт только контроля качества, то качать аналитику, инструменты моделирования, формирования и уточнения требованмй. Софт-скилы начинают иметь сильно большее значение- умение слышать, уточнять, доносить свою точку зрения и все, что с этим связано.
У нас в Плеске многие продакты это бывшие куашники, разработчики, а то и все вместе.
2) да, не везде могут пройти жесткие и затратные изменения, но это не повод не говорить об этом, а в идеале- сразу предлагать, заранее подготовив себе базу в виде конкретных предложений. Например, мы в команде начали пробовать менять процессы за полгода до того, как такой вопрос в принципе появился. И к моменту, когда изменения стали необходимы и востребованы всей командой, а не отдельными инженерами, у нас уже был этот опыт. Начать стоит с самого близкого и непосредственного руководителя, не стоит перескакивать через голову, это может вызвать конфликт, который врядли пойдет на пользу.
3) Если что-то предлагают- это уже прекрасно. Надо смотреть, насколько это совпадает с личными желаниями и как можно это совместить. Не предлагают- хуже. Но и это не повод. Если есть понимание того, что хочется, если что-то уже начал пробовать, то и развитие уже началось :) ну а дальше смотреть, если это никому не надо и текущее место в явном виде ограничивает, а то и запрещает, развитие и вариантов никаких, то тут поможет или участие в проекте "на стороне", ну или ничего уже тут не поможет.
"На стороне" может быть в том числе просто соседняя команда, где все то же самое, но совсем другое :)
Интересное предложение недавно видел, как раз на тему развития: если на текущем месте и в текущей компании нет того, у кого учиться, а менять компанию или проект не хочется, то попробовать найти ментора себе на стороне, с кем можно общаться, обсуждать и у кого учиться.
Чисто умозрительно, если есть культура и опыт QA, т.е. обеспечения качества, а не только его контроля, то многие функции что продакта, что аналитика и так уже должны выполняться (по крайней мере, из того, что я вижу со стороны, глядя на продактов, например). Довольно большая часть хард скилов на этих позициях будут плюс/минус общими, технологический стек, если смена позиции происходит в рамках одной компании/проекта так вообще один, поэтому сменить род деятельности не должно стать проблемой, а недостающие знания легко подтянуть по ходу дела.
Если есть опыт только контроля качества, то качать аналитику, инструменты моделирования, формирования и уточнения требованмй. Софт-скилы начинают иметь сильно большее значение- умение слышать, уточнять, доносить свою точку зрения и все, что с этим связано.
У нас в Плеске многие продакты это бывшие куашники, разработчики, а то и все вместе.
2) да, не везде могут пройти жесткие и затратные изменения, но это не повод не говорить об этом, а в идеале- сразу предлагать, заранее подготовив себе базу в виде конкретных предложений. Например, мы в команде начали пробовать менять процессы за полгода до того, как такой вопрос в принципе появился. И к моменту, когда изменения стали необходимы и востребованы всей командой, а не отдельными инженерами, у нас уже был этот опыт. Начать стоит с самого близкого и непосредственного руководителя, не стоит перескакивать через голову, это может вызвать конфликт, который врядли пойдет на пользу.
3) Если что-то предлагают- это уже прекрасно. Надо смотреть, насколько это совпадает с личными желаниями и как можно это совместить. Не предлагают- хуже. Но и это не повод. Если есть понимание того, что хочется, если что-то уже начал пробовать, то и развитие уже началось :) ну а дальше смотреть, если это никому не надо и текущее место в явном виде ограничивает, а то и запрещает, развитие и вариантов никаких, то тут поможет или участие в проекте "на стороне", ну или ничего уже тут не поможет.
"На стороне" может быть в том числе просто соседняя команда, где все то же самое, но совсем другое :)
Интересное предложение недавно видел, как раз на тему развития: если на текущем месте и в текущей компании нет того, у кого учиться, а менять компанию или проект не хочется, то попробовать найти ментора себе на стороне, с кем можно общаться, обсуждать и у кого учиться.
1) Ну, вдруг, тут есть бывшие куа, которые стали успешными аналитиками/управленцами) Но вообще это было больше для "относительно начинающих", но понявших, что увеличение хардовой составляющих для них не интересно, а иногда даже невозможно. Но в принципе работать в it нравится и хочется что-то читать и куда-то двигаться.
2) Да, поговорить это всегда хорошо. Основной посыл был, что бы настрой при этом был не самый воинственный) Не всегда злые капиталисты хотят держать вас на маленькой зарплате, не давай головы поднять, заставляя руками регрессить днем и ночью. Иногда они и не знают, что это можно оптимизировать и может будут даже благодарны за дельное предложение, а иногда могут пояснить точку зрения, после которой к вам придет понимание, что стоит выбрать что-то иное.
3) Интересная мысль про "на стороне", только если я такое предложу коллегам, то они могут туда и уйти 😅
2) Да, поговорить это всегда хорошо. Основной посыл был, что бы настрой при этом был не самый воинственный) Не всегда злые капиталисты хотят держать вас на маленькой зарплате, не давай головы поднять, заставляя руками регрессить днем и ночью. Иногда они и не знают, что это можно оптимизировать и может будут даже благодарны за дельное предложение, а иногда могут пояснить точку зрения, после которой к вам придет понимание, что стоит выбрать что-то иное.
3) Интересная мысль про "на стороне", только если я такое предложу коллегам, то они могут туда и уйти 😅
МС
А, ну да, потом, кстати, еще была мысль, что для qa часто неплохой прирост ЗП(как один из важных факторов для развития), может быть увеличение технической грамотности и кругозора, особенно относительно тех технологий, что используются в проекте. Понимание основ из разряда: поучить сети, поучить основы ЯП который у вас используется на вебе/беке(говорю про специфику своей компании), посмотреть инструментарий не только тестера, но и разраба, который, возможно позволит вам проводить более глубокую и качественную диагностику тех или иных проблем перед заведением. Вроде этого вопроса тоже не касались
А
1) Ну, вдруг, тут есть бывшие куа, которые стали успешными аналитиками/управленцами) Но вообще это было больше для "относительно начинающих", но понявших, что увеличение хардовой составляющих для них не интересно, а иногда даже невозможно. Но в принципе работать в it нравится и хочется что-то читать и куда-то двигаться.
2) Да, поговорить это всегда хорошо. Основной посыл был, что бы настрой при этом был не самый воинственный) Не всегда злые капиталисты хотят держать вас на маленькой зарплате, не давай головы поднять, заставляя руками регрессить днем и ночью. Иногда они и не знают, что это можно оптимизировать и может будут даже благодарны за дельное предложение, а иногда могут пояснить точку зрения, после которой к вам придет понимание, что стоит выбрать что-то иное.
3) Интересная мысль про "на стороне", только если я такое предложу коллегам, то они могут туда и уйти 😅
2) Да, поговорить это всегда хорошо. Основной посыл был, что бы настрой при этом был не самый воинственный) Не всегда злые капиталисты хотят держать вас на маленькой зарплате, не давай головы поднять, заставляя руками регрессить днем и ночью. Иногда они и не знают, что это можно оптимизировать и может будут даже благодарны за дельное предложение, а иногда могут пояснить точку зрения, после которой к вам придет понимание, что стоит выбрать что-то иное.
3) Интересная мысль про "на стороне", только если я такое предложу коллегам, то они могут туда и уйти 😅
2) я тоже против терроризма и насилия, но тут кто как умеет :)
3) а могут не уйти, а научиться, вдохновиться, приносить пользу и быть благодарными :)
Это же известная проблема- зачем давать развиваться людям, если они станут крутыми и уйдут? И это очень неправильная, на мой взгляд, точка зрения
3) а могут не уйти, а научиться, вдохновиться, приносить пользу и быть благодарными :)
Это же известная проблема- зачем давать развиваться людям, если они станут крутыми и уйдут? И это очень неправильная, на мой взгляд, точка зрения
МС
Не не, я не против развития, я конкретно про "на стороне") Иногда это кажется слишком опасным, отпустить своих птенчиков куда-то :D
А
Тогда и на конференции и на митапы отпускать нельзя? :))
Где разумная граница этого опасения?
Где разумная граница этого опасения?
МС
Знать бы ее) Всегда хочется работать с людьми интересующимися, да еще и так, что бы их потом не терять. Но понятно, что это не всегда возможно, к сожалению)
ОН
В итоге всё равно придется дать пинка под зад на развиваться дальше и уже в других проектах, компаниях, командах.
ОН
@kami_nary Alina Катя, Алина спасибо за вопрос. Я подумал на него ответ и это было удивительно интересно.
Термин "персональное лидерство" принят в русскоязычном тренерском сообществе, выделяет ту часть лидерства которое отделено от менеджмента.
Менеджер может использовать и развивать "лидерские" компетенции, а может не использовать и не развивать. Есть менеджеры не-лидеры и есть лидеры не-менеджеры.
Поэтому я использовал этот термин для отделения "лидерства" от "менеджмента".
Говорить о лидерстве в разрезе саморазвития меня подвигла книга Эдвардса Деминга "Выход из кризиса" 1986 г.
После прочтения книги до меня дошло почему выполнение целей менеджмента компании практически никогда не приводило к повышению зарплаты, но выполнение собственных целей практически всегда высоко оценивалось этим же самым менеджментом. Парадокс? Увы, но нет.
Причины я вижу две:
- менеджмент практически всегда фейлит постановку целей и задач, постановка задачи это скил, им нужно владеть и не забывать применять
- постановка собственных целей и задач с собственным определением времени и способа их выполнения всегда даёт лучший результат по времени и качеству, потому что "что делать", "когда делать" и "как делать" это 3 из 4(четвёртый это "с кем") составляющих удовлетворённости от работы и вовлеченность в работу, а так как время и качество лучше, то и оценка лучше.
Книга не новая и была написана под определённый исторический момент для руководства производственных предприятий США, то значительная часть вещей в ней для нас не актуальная, но вот тема лидерства похоже что актуальность не утратила.
И да, получается что лидерство это контринтуитивная практика, к которой не готов ни менеджер ни исполнитель.
Термин "персональное лидерство" принят в русскоязычном тренерском сообществе, выделяет ту часть лидерства которое отделено от менеджмента.
Менеджер может использовать и развивать "лидерские" компетенции, а может не использовать и не развивать. Есть менеджеры не-лидеры и есть лидеры не-менеджеры.
Поэтому я использовал этот термин для отделения "лидерства" от "менеджмента".
Говорить о лидерстве в разрезе саморазвития меня подвигла книга Эдвардса Деминга "Выход из кризиса" 1986 г.
После прочтения книги до меня дошло почему выполнение целей менеджмента компании практически никогда не приводило к повышению зарплаты, но выполнение собственных целей практически всегда высоко оценивалось этим же самым менеджментом. Парадокс? Увы, но нет.
Причины я вижу две:
- менеджмент практически всегда фейлит постановку целей и задач, постановка задачи это скил, им нужно владеть и не забывать применять
- постановка собственных целей и задач с собственным определением времени и способа их выполнения всегда даёт лучший результат по времени и качеству, потому что "что делать", "когда делать" и "как делать" это 3 из 4(четвёртый это "с кем") составляющих удовлетворённости от работы и вовлеченность в работу, а так как время и качество лучше, то и оценка лучше.
Книга не новая и была написана под определённый исторический момент для руководства производственных предприятий США, то значительная часть вещей в ней для нас не актуальная, но вот тема лидерства похоже что актуальность не утратила.
И да, получается что лидерство это контринтуитивная практика, к которой не готов ни менеджер ни исполнитель.
A
А я хочу сказать немного другое
Смотрите, Олег говорил про персональное лидерство
Таня Писчасова говорили про канбан "для себя" - про WIP лимиты, беклог и прочие техники, применяемые для себя
Я говорил про планирорование - с постановкой целей, работой с мотивацией и тоже в разрезе управления собой, а не командой
Кажется, что управление собой один из важнейший навык для развития себя 🙂
Смотрите, Олег говорил про персональное лидерство
Таня Писчасова говорили про канбан "для себя" - про WIP лимиты, беклог и прочие техники, применяемые для себя
Я говорил про планирорование - с постановкой целей, работой с мотивацией и тоже в разрезе управления собой, а не командой
Кажется, что управление собой один из важнейший навык для развития себя 🙂
ОН
Yep.
S
> - менеджмент практически всегда фейлит постановку целей и задач, постановка задачи это скил, им нужно владеть и не забывать применять
Очень сильное заявление. Я бы сказал, что очень самонадеянное. Если бы ты работал в индустрии лет 20 и сменил 5-7 компаний уровня плеск и выше, я бы готов был выслушать и поанализировать примеры. Но ты работаешь много лет в одной компании. которая между прочим вполне себе хорошо себя чувствует, не смотря на то что менеджмент "всегда фейлит постановку целей и задач". Возможно ты хотел сказать про микроменджмент и локальные задачи в которых ты более компетентен? Но очень глупо делать такое обобщение на весь менеджмент. Практически все решения под одну гребенку в категорию "фейлов". Делать такие заявления, будучи одним из лидеров сообщества, безответственно, что ли) Что же дальше будет?
Очень сильное заявление. Я бы сказал, что очень самонадеянное. Если бы ты работал в индустрии лет 20 и сменил 5-7 компаний уровня плеск и выше, я бы готов был выслушать и поанализировать примеры. Но ты работаешь много лет в одной компании. которая между прочим вполне себе хорошо себя чувствует, не смотря на то что менеджмент "всегда фейлит постановку целей и задач". Возможно ты хотел сказать про микроменджмент и локальные задачи в которых ты более компетентен? Но очень глупо делать такое обобщение на весь менеджмент. Практически все решения под одну гребенку в категорию "фейлов". Делать такие заявления, будучи одним из лидеров сообщества, безответственно, что ли) Что же дальше будет?
ОН
@configuru Да, Дёминг тоже, наверное, был очень самонадеянным 😊