в статье я пытаюсь разложить эту "человечность" на некие понятные составляющие - думаю, это полезно тем, кто не знает с какого конца подойти. то, что вы пишете, очень здраво и логично для руководителя зрелого, сложившегося.
социофобия сама по себе - это механизм, который сформировался в ответ на что-то. если это что-то не решено другим образом, то конечно, вряд ли бессознательное, - которое, как мы знаем, мудро и автономно, - просто поднимет лапки и механизм отпустит.
и опять же: нужно ли лично вам что-то менять? есть ли мотивация? или вторичные выгоды от социофобии превышают потенциальный профит от "выхода в люди"? я бы просто подумала в эту сторону в такой ситуации, как вы описываете.
великолепно! ждала когда же будет такой комментарий ) в одной статье меня записывают в HR'ы, здесь откуда-то взялся коучинг - про который в статье ни слова.
если бы вы читали внимательно, то в первом абзаце могли увидеть, что моё основное образование - социологическое. при этом я работаю на разных ролях в ИТ 10 лет.
в случае, если для вас социология и коучинг - одно и то же, возможно, стоит обратить внимание на общий кругозор )
и да и нет: поскольку автоматическая реакция проходит мимо рацио - то при достаточно пугающем / сильном стимуле даже и от знакомого человека мы реагируем теми же бей/беги (/замри).
тут скорее - в целом про наличие механизма сознательного включения в реакцию, который нарабатывается тренировкой - та же медитация как раз про это.
спасибо за комментарий. да, это - не самая простая тема. на конференции говорила как раз о том, что обсуждение - не обязательно для начинающего, а для того, что понял, что что-то лыжи не едут ) потому что без запроса на решение копаться в таком - мучение.
мне кажется, можно начать с выступления Келли Макгонигал про стресс на TED (https://www.ted.com/talks/kelly_mcgonigal_how_to_make_stress_your_friend ). она в первой части рассказывает про типичную человеческую реакцию на такие стимулы.
я бы ещё поискала видео или статьи Вячеслава Дубынина на тему "мозг и стресс" - он много об этом говорит с точки зрения нейробиологии.
в целом это следует из того, что обычных реакций - две: бей или беги. есть ещё поздняя (эволюционно) реакция "замри". но реакция подумай-откройся-признай свою уязвимость-действуй в нас не заложена: вероятно, мы бы с такой автоматической реакцией вымерли бы. мозг ведь заточен на выживание, а не на продуктивность / счастье / удовлетворённость.
они просто не могли это сделать. хотя некоторым удавалось - та же история побега с корабля и затем вплавь до берега... почитайте, много нового для себя узнаете.
Много говорю с водителями (т.к. много езжу): комфорт и комфорт+ от 90 до 150к в месяц, если голова есть. Так понимаю, что при + можно и больше - упирается в здоровье исключительно.
Спасибо за ваш комментарий — он поднимает важный момент с представлением о принципиальном качественном отличии технической деятельности от «что там у всех этих гуманитариев» (потому что иначе объяснить себе присутствие HR-специалистов в первом предложении вашего замечания я не могу: ведь HR — так же не моя область, как консультанта, как и непосредственное написание кода; и потом почему мы исходим из предположения, что HR — в его качественном, профессиональном исполнении — это раз плюнуть? неясно).
Давайте оставим за бортом позицию «никто, даже заказчики этой же компании, не имеют права оценивать ИТ» как заведомо ведущую к очень тяжёлым последствиям на уровне всей организации от обособления ИТ специалистов в свой мир, максимально оторванный от реальности, в которой существует разрабатываемый ими продукт, до возведения техники в культ и вещь в себе, понятную лишь избранным.
Также стоит заметить, что здесь мы выводим за скобки те редкие на текущий день отрасли, где можно себе позволить работать по waterfall. Мы говорим в рамках продуктового подхода.
Давайте вместе посмотрим на аспекты деятельности сеньора, которого вы приводите в качестве примера, чтобы понять есть ли в ней элементы, которые мы — в данном случае консультанты, как правило, с опытом в менеджменте/управлении ИТ, — можем браться диагностировать:
— непосредственное написание кода в рамках бизнес-задачи поставленной заказчиком.
Сам код, как вы правильно отметили, мы открыть и оценить не можем — диагностика не код-ревью, мы — не разработчики. Но у нас есть косвенные признаки, собрав которые совместно с самой диагностируемой командой — тут важно отметить, что диагностика без сотрудничества самой команды смысла не имеет, — мы можем составить представление о качестве работы. К примеру, как часто возвращаются задачи конкретного разработчика с этапа ревью или этапа тестирования; насколько учитываются функциональные требования; можем ли мы судить по конечному результату и последующим задачам о том, что идёт закладка на будущее (под масштабирование и прочие штуки).
— приёмка требований от бизнеса. На исторических данных мы вполне можем проанализировать насколько эффективно происходит процесс передачи требований и какую роль в нём играет разработчик: это могут быть примеры конкретных бизнес задач, на которых мы можем увидеть было ли сделано всё для сохранения основной ценности или что-то потерялось; насколько приёмка в команду оформлена в процесс; проявила ли команда или конкретный разработчик критерии, на основании которых бизнес может понять, что вот — штука готова к занесению в команду и т.п.
— консультирование в рамках своей экспертизы. Если мы говорим о сеньоре, то с большой долей вероятности он либо обладает богатой экспертизой в продукте, либо непосредственно отвечает за какую-то часть ИТ ландшафта компании (что не исключает, а дополняет первую опцию). И тогда к такому специалисту по мере необходимости будут обращаться коллеги — возможно, из соседних продуктов / систем компании, либо других департаментов. Мы можем — да, косвенно, но всё же, — судить о ясности понимания своего продукта специалистом и готовности использовать это понимание на пользу компании в целом.
Есть и другие аспекты деятельности, вероятно не имеет смысла перечислять их все. Мне хотелось донести основную логику: мы оцениваем не непосредственные харды сеньора — как вы правильно заметили, это сделать сложно независимо от профессиональной области (не взялась бы оценивать HR, хоть вы и предлагаете :) ), — мы оцениваем скорее вклад в продукт, в команду, в компанию, эффективность взаимодействий, участие в процессах вокруг продукта и тому подобные вещи, которые интересуют руководство компании или руководителя команды, имеющих намерение выйти на качественно лучший уровень эффективности.
И здесь касание такой диагностикой эффекта Д-К при составлении многомерного изображения команды является интересным побочным, но приятным бонусом.
Спасибо за замечание. В данной статье я опираюсь на предположение, что (а) этот эффект (или что-то на него похожее и проявляющееся как описано) имеет место быть и (б) местами мешает взаимодействию и продуктивной совместной работе, а значит стоит рассмотрения в практическом ключе.
Вопрос с существованием эффекта, имхо, куда более фундаментальный и требует детального научного исследования, а не формата статьи. То есть возможно это исследование надо повторить, углубив его и перенеся из лабораторий со студентами куда-то в реалии жизни вокруг нас. С этим соглашусь.
спасибо за комментарий :) действительно так.
в статье я пытаюсь разложить эту "человечность" на некие понятные составляющие - думаю, это полезно тем, кто не знает с какого конца подойти. то, что вы пишете, очень здраво и логично для руководителя зрелого, сложившегося.
социофобия сама по себе - это механизм, который сформировался в ответ на что-то. если это что-то не решено другим образом, то конечно, вряд ли бессознательное, - которое, как мы знаем, мудро и автономно, - просто поднимет лапки и механизм отпустит.
и опять же: нужно ли лично вам что-то менять? есть ли мотивация? или вторичные выгоды от социофобии превышают потенциальный профит от "выхода в люди"? я бы просто подумала в эту сторону в такой ситуации, как вы описываете.
можно ли отнести статью к коучинговому приёму - вопрос )) в любом случае пока что коучем я не являюсь, такой специализации у меня нет.
великолепно! ждала когда же будет такой комментарий ) в одной статье меня записывают в HR'ы, здесь откуда-то взялся коучинг - про который в статье ни слова.
если бы вы читали внимательно, то в первом абзаце могли увидеть, что моё основное образование - социологическое. при этом я работаю на разных ролях в ИТ 10 лет.
в случае, если для вас социология и коучинг - одно и то же, возможно, стоит обратить внимание на общий кругозор )
и да и нет: поскольку автоматическая реакция проходит мимо рацио - то при достаточно пугающем / сильном стимуле даже и от знакомого человека мы реагируем теми же бей/беги (/замри).
тут скорее - в целом про наличие механизма сознательного включения в реакцию, который нарабатывается тренировкой - та же медитация как раз про это.
спасибо за комментарий. да, это - не самая простая тема. на конференции говорила как раз о том, что обсуждение - не обязательно для начинающего, а для того, что понял, что что-то лыжи не едут ) потому что без запроса на решение копаться в таком - мучение.
мне кажется, можно начать с выступления Келли Макгонигал про стресс на TED (https://www.ted.com/talks/kelly_mcgonigal_how_to_make_stress_your_friend ). она в первой части рассказывает про типичную человеческую реакцию на такие стимулы.
вот ещё есть статья - опять же со ссылкой на книгу Келли: https://theoryandpractice.ru/posts/15713-bey-ili-begi-kak-ustroen-stress-i-pochemu-on-delaet-nas-silnee
я бы ещё поискала видео или статьи Вячеслава Дубынина на тему "мозг и стресс" - он много об этом говорит с точки зрения нейробиологии.
в целом это следует из того, что обычных реакций - две: бей или беги. есть ещё поздняя (эволюционно) реакция "замри". но реакция подумай-откройся-признай свою уязвимость-действуй в нас не заложена: вероятно, мы бы с такой автоматической реакцией вымерли бы. мозг ведь заточен на выживание, а не на продуктивность / счастье / удовлетворённость.
соглашусь с вами. это - часть культурного бессознательного, с которой нам ещё долго работать.
done
да, сейчас добавлю в конце статьи.
тут ориентировалась на: https://ru.wikipedia.org/wiki/Кайдзен
Всё так: без "слушать" ( что первично ) не будет "слышать" )) мне хотелось подчеркнуть двойное действие: слушать и услышать.
они просто не могли это сделать. хотя некоторым удавалось - та же история побега с корабля и затем вплавь до берега... почитайте, много нового для себя узнаете.
Много говорю с водителями (т.к. много езжу): комфорт и комфорт+ от 90 до 150к в месяц, если голова есть. Так понимаю, что при + можно и больше - упирается в здоровье исключительно.
да, тут я с вами совершенно согласна. мой комментарий - это скорее риторическое изумление и возмущение, чем пожелание ))
а Яндекс не хочет пересмотреть свои конские комиссии, из-за которых страдают и таксисты, и пассажиры? поднимать цены - единственная идея? )
то самое приложение, которое даже после отмены подписки и письма в поддержку регулярно пытается снять средства с карты? прекрасно ))
Давайте оставим за бортом позицию «никто, даже заказчики этой же компании, не имеют права оценивать ИТ» как заведомо ведущую к очень тяжёлым последствиям на уровне всей организации от обособления ИТ специалистов в свой мир, максимально оторванный от реальности, в которой существует разрабатываемый ими продукт, до возведения техники в культ и вещь в себе, понятную лишь избранным.
Также стоит заметить, что здесь мы выводим за скобки те редкие на текущий день отрасли, где можно себе позволить работать по waterfall. Мы говорим в рамках продуктового подхода.
Давайте вместе посмотрим на аспекты деятельности сеньора, которого вы приводите в качестве примера, чтобы понять есть ли в ней элементы, которые мы — в данном случае консультанты, как правило, с опытом в менеджменте/управлении ИТ, — можем браться диагностировать:
— непосредственное написание кода в рамках бизнес-задачи поставленной заказчиком.
Сам код, как вы правильно отметили, мы открыть и оценить не можем — диагностика не код-ревью, мы — не разработчики. Но у нас есть косвенные признаки, собрав которые совместно с самой диагностируемой командой — тут важно отметить, что диагностика без сотрудничества самой команды смысла не имеет, — мы можем составить представление о качестве работы. К примеру, как часто возвращаются задачи конкретного разработчика с этапа ревью или этапа тестирования; насколько учитываются функциональные требования; можем ли мы судить по конечному результату и последующим задачам о том, что идёт закладка на будущее (под масштабирование и прочие штуки).
— приёмка требований от бизнеса. На исторических данных мы вполне можем проанализировать насколько эффективно происходит процесс передачи требований и какую роль в нём играет разработчик: это могут быть примеры конкретных бизнес задач, на которых мы можем увидеть было ли сделано всё для сохранения основной ценности или что-то потерялось; насколько приёмка в команду оформлена в процесс; проявила ли команда или конкретный разработчик критерии, на основании которых бизнес может понять, что вот — штука готова к занесению в команду и т.п.
— консультирование в рамках своей экспертизы. Если мы говорим о сеньоре, то с большой долей вероятности он либо обладает богатой экспертизой в продукте, либо непосредственно отвечает за какую-то часть ИТ ландшафта компании (что не исключает, а дополняет первую опцию). И тогда к такому специалисту по мере необходимости будут обращаться коллеги — возможно, из соседних продуктов / систем компании, либо других департаментов. Мы можем — да, косвенно, но всё же, — судить о ясности понимания своего продукта специалистом и готовности использовать это понимание на пользу компании в целом.
Есть и другие аспекты деятельности, вероятно не имеет смысла перечислять их все. Мне хотелось донести основную логику: мы оцениваем не непосредственные харды сеньора — как вы правильно заметили, это сделать сложно независимо от профессиональной области (не взялась бы оценивать HR, хоть вы и предлагаете :) ), — мы оцениваем скорее вклад в продукт, в команду, в компанию, эффективность взаимодействий, участие в процессах вокруг продукта и тому подобные вещи, которые интересуют руководство компании или руководителя команды, имеющих намерение выйти на качественно лучший уровень эффективности.
И здесь касание такой диагностикой эффекта Д-К при составлении многомерного изображения команды является интересным побочным, но приятным бонусом.
Вопрос с существованием эффекта, имхо, куда более фундаментальный и требует детального научного исследования, а не формата статьи. То есть возможно это исследование надо повторить, углубив его и перенеся из лабораторий со студентами куда-то в реалии жизни вокруг нас. С этим соглашусь.