Благодарю за обратную связь. Действительно, предложенный вариант не является серебряной пулей, а скорее набором приемов и практик из собственного опыта, который не всегда и не везде применим. Однако лично я стараюсь придерживаться именно этих правил (хотя бывали и осечки в случаях с чрезмерно авторитарным стилем управления, как Вы и подметили верно).
Абсолютно согласен. Ошибки- наши учителя, но только в том случае, когда мы их анализируем, ищем причины, исправляем и не допускаем в будущем. В противном случае, если сгружаем ответственность за них на карму, судьбу, дядю Васю, то ошибки нас ничему не научат. Я как раз об этом.
Если сотрудник переживает за судьбу проекта, то безусловно его самоотдача примечательна и похвальна, ровно до того момента, когда она становится разрушительной для самого человека, его проекта и компании. Безусловно, вовремя остановиться не всегда получается (см.выше), все ошибаются, важно извлечь урок из этого и в следующий раз быть более осторожным, дабы радение за проект не сделало ему еще хуже.
В свое время один из моих бывших (и лучших) руководителей danikin написал своего рода библию для разработчика высконагруженного проекта. Был там блок и про QA, один из пунктов которого гласил «Никогда не верь разработчику», а вслед за ним еще один «Никогда». И это при том, что код автора я сам когда-то тестировал, когда он программировал. Но это не означало, что я «ничего не делал», это подталкивало каждый раз находить способ максимально объективного взгляда на вещи. Например, нет доверия, что разработчик не катит что-то в прод без ведома QA, настроить в CI автоматический запуск тестов с репортингом ответственным лицам. Или нет доверия, что разработчик исправил баг и не сломал ничего вокруг, сделай верификацию дефекта и достаточные регрессы вокруг. А если вдруг ошибся, то (см.выше), снова анализировать причины, исправлять ошибку, искать способы недопущения в будущем.
Абсолютно согласен с мыслью не бояться совершать ошибки. Воспитываю детей именно в этой парадигме, акцентируя их на здоровой рефлексии на них. Увы, наша школьная система категорически против такого подхода. Дети боятся получить плохую оценку, которую мало того, что нельзя исправить («пятерка» после «двойки» превращается в тройку), так за неё ещё и осудят, а порой ещё и публично. Как итог, часто дети, да и мы взрослые, впадаем в ступор перед потенциальными ошибками и в попытке избежать оных либо ничего не делаем, либо увиливаем ответсвенности. И мой посыл в этом контексте как раз попытаться разглядеть здоровый потенциал в сотруднике на такие случаи.
Согласен. И безусловно изучаю полезное в работе, а статьи/доклады в целом такая же работа, ведь компания и команда с них также имеет бенефит, как с проведенной планерки, обсуждения, планирования и т.п. задач.
Это гиперболы для контрастного описания приемов. Правильно отработав по потребностям сотрудника (не только кнутом, но и пряником, там ведь в продолжении «давай вместо игр изучишь ЯП и разовьешься до Лида команды»), они действительно станут не только заняты делом, но еще и мотивированы на него. Ну а высвобожденное время от делегирования каждый тратит по-своему, я, например, предпочитаю изучить что-то новое для себя в общении с коллегами или обобщить и структуризировать накопленные знания в виде статьи/доклада.
ps: У нас в компании, кстати, один проект игровой («поиграть в игрушки»), а второй UGC на мемчиках. Так что тут примеры вполне рабочего характера:)
Тут претензии никакой и нет, ни к работе, ни тем паче к человеку. И «как правильно» тут не бывает. Там же чуть дальше про востребованность обоих типов сотрудников.
Результат-ориентированные даже в 12 часовой медитации найдут способ выделить достижения (улучшил самоконтроль и выдержку, преодолел внутреннюю планку на концентрацию (раньше мог не больше 6 часов, теперь могу 12), разобрался в себе и смог выйти из внутреннего кризиса, ответив на сложные для себя вопросы). Процесс-ориентированные скорее констатируют сам процесс (12 часов сидел молча и не двигаясь, контролируя дыхание и мысли).
И в этом нет ничего плохого. Это скорее разные полюса одной личностной характеристики, не более.
Согласен. Это же гиперболизированные примеры для наглядности, очевидно, что в реальной жизни не всё так контрастно. Кроме того важно комбинировать «карающую длань» с «кормящей рукой», на одних пряниках тоже далеко не уедешь. А то закормив сладостями команда потом заберётся на шею и свесив ножки будет толкать шефу управленческих обезьян, а тот их вешать будет одну за другой. Гармония и тут важна.
Ну такое. Речь не о том, чтобы всегда себя во всём винить, а в том, чтобы искать свой промах, понимать его причины, как его исправить и как недопустить в будущем.
Неполнота и недостоверность данных не снимает с исполнителя ответственности за контроль этих вводных данных и запросы на уточнение. Хорошо, если после фейла человек понял, что причина в отсутствии проверки и уточнения вводных, еще лучше, если он понял как это исправить, ну и вообще прекрасно, когда он смог придумать решение, которое снизит риск повторения инцидента к минимуму или вообще избавит от повторения.
Тоже самое и со стрессом. В конечном итоге решение принимает сам сотрудник, если он при этом в стрессе от 20-ти часового рабочего дня, у него ложные и неполные данные, то это не снимает с него ответсвенности за это самой решение. Безусловно он разделит её с руководством, допустившим подобную ситуацию, но не избавит – факт.
Можно конечно сложить ручки и плыть по течению, оговаривая всё вокруг «не я такой, жизнь такая», но как говорили современные классики «не стоит прогибаться под изменчивый мир, пусть лучше он прогнется под нас» и «нет другой судьбы, кроме той, что творим мы сами»;)
То, что человек молчит о проблеме- не значит, что он стрессоустойчивый. Скорее это уровень радикальности рефлексии на раздражитель. Один побурчит за кружкой пива в пятницу, другой вломится в офис с оружием.
Ну и я не утверждал, что их меньше это напрягает, а лишь говорил о том, что стрессоустойчивые люди менее этому подвержены. Боль чувствуют все, но в зависимости от болевого порога реакция у каждого своя.
И тут вопрос не в овертаймах и авралах, не в отношении к ним, и уж тем более не в пофигизме. А в том, что если у двух людей в топе потребностей физическое удобство ОТ (например, близость офиса к дому) и удобство психологическое ОТ (неконфликтная среда единомышленников), то переезд офиса в отдаленный район и вынужденная борьба за место под солнцем (например, под угрозой увольнения) в свете кризиса, на сотрудниках с разной стрессоустойчивостью подействует по разному. Один откроет резюме и тут же пойдёт искать способ удовлетворить свои потребности, а второй стерпит и «перезимует» неприятности, если понимает, что они временные.
И я считаю, что задача руководителя/нанимателя, определив потребности будущего сотрудника дать себе и кандидату честный ответ, смогут ли потребности человека в этом месте удовлетворяться полностью, и вот если смогут лишь частично или вовсе не смогут, то тут и станет критичной пресловутая стрессоустойчивость, так как именно она будет определяющим фактором продолжительности продуктивной работу сотрудника в компании.
Иногда стрессоустойчивостью можно пренебречь, а иногда она становится определяющим фактором для успеха. Выгорание- действительность, с которой сталкиваются многие, но стрессоустойчивые подвержены этой истории в меньшей степени. Если для бизнеса это критично, то да, стоит брать стрессоустойчивых, а можно и не брать. Если компания адекватно отдаёт себе отчёт, что сможет удовлетворять потребности сотрудника в течении продолжительного времени.
Благодарю за лестный отзыв, старались сделать митап действительно интересным. Доклад за жизнь и о наболевшем, потому таким и получился. Следите за обновлениями, будем стараться держать марку;)
Отличная статья, Денис. В лучших традициях того, чему я у тебя в своё время учился!Сразу вспомнилась твоя «Библия разработчика высоконагруженного сервиса». Буду ждать вторую статью и цикла.
Такие проекты есть, уверен. Возможно, там не все кусочки паззла собраны, но зато самые нужные в конкретном месте.
Про стандарт, очень хотелось бы, чтобы в профессию приходили замотивированные, увлечённые и склонные к самообучению люди, однако, в индустрии полно и аморфных тюленей с сомнительной денежной или имиджевой мотивации, а то и вовсе людей, которые просто хотят быть на хайпе.
Выгорание на работе происходит у всех, даже у самых замотивированных, увы. Причем по личному опыту, чем более мотивированным был человек, тем громче и с бОльшими последствиями он демотивируется. В духе поговорки про «чем больше шкаф, тем громче падает»:( Знаю немало кейсов переходов в тестирование из разработки и наоборот, универсальной профессии не существует. Рад, что в итоге обрели свое место и задачи, которые не вызывают печали и ужаса.
С удовольствием прочитал бы такую статью в разрезе различных специальностей/направлений, ведь разработкой хотят заниматься десятки тысяч людей, но сталкиваются с такой же проблемой, что и тестировщики, то есть не понимают, что именно нужно учить для каждого конкретного профиля в первую очередь, а что можно отложить на потом или не изучать вовсе.
Отчасти для конкретизации направлений и писал эту статью, позволит не искать сферического супер-тестировщика-всезнайку, а найти специалиста в нужном профиле.
Ну это скорее список ингредиентов для горячего самобытного коктейля специалиста. Все знать совсем необязательно. Каждый выберет свой состав и соберёт профессиональный портрет, что ближе лично ему.
Если сотрудник переживает за судьбу проекта, то безусловно его самоотдача примечательна и похвальна, ровно до того момента, когда она становится разрушительной для самого человека, его проекта и компании. Безусловно, вовремя остановиться не всегда получается (см.выше), все ошибаются, важно извлечь урок из этого и в следующий раз быть более осторожным, дабы радение за проект не сделало ему еще хуже.
В свое время один из моих бывших (и лучших) руководителей danikin написал своего рода библию для разработчика высконагруженного проекта. Был там блок и про QA, один из пунктов которого гласил «Никогда не верь разработчику», а вслед за ним еще один «Никогда». И это при том, что код автора я сам когда-то тестировал, когда он программировал. Но это не означало, что я «ничего не делал», это подталкивало каждый раз находить способ максимально объективного взгляда на вещи. Например, нет доверия, что разработчик не катит что-то в прод без ведома QA, настроить в CI автоматический запуск тестов с репортингом ответственным лицам. Или нет доверия, что разработчик исправил баг и не сломал ничего вокруг, сделай верификацию дефекта и достаточные регрессы вокруг. А если вдруг ошибся, то (см.выше), снова анализировать причины, исправлять ошибку, искать способы недопущения в будущем.
Абсолютно согласен с мыслью не бояться совершать ошибки. Воспитываю детей именно в этой парадигме, акцентируя их на здоровой рефлексии на них. Увы, наша школьная система категорически против такого подхода. Дети боятся получить плохую оценку, которую мало того, что нельзя исправить («пятерка» после «двойки» превращается в тройку), так за неё ещё и осудят, а порой ещё и публично. Как итог, часто дети, да и мы взрослые, впадаем в ступор перед потенциальными ошибками и в попытке избежать оных либо ничего не делаем, либо увиливаем ответсвенности. И мой посыл в этом контексте как раз попытаться разглядеть здоровый потенциал в сотруднике на такие случаи.
Это гиперболы для контрастного описания приемов. Правильно отработав по потребностям сотрудника (не только кнутом, но и пряником, там ведь в продолжении «давай вместо игр изучишь ЯП и разовьешься до Лида команды»), они действительно станут не только заняты делом, но еще и мотивированы на него. Ну а высвобожденное время от делегирования каждый тратит по-своему, я, например, предпочитаю изучить что-то новое для себя в общении с коллегами или обобщить и структуризировать накопленные знания в виде статьи/доклада.
ps: У нас в компании, кстати, один проект игровой («поиграть в игрушки»), а второй UGC на мемчиках. Так что тут примеры вполне рабочего характера:)
Результат-ориентированные даже в 12 часовой медитации найдут способ выделить достижения (улучшил самоконтроль и выдержку, преодолел внутреннюю планку на концентрацию (раньше мог не больше 6 часов, теперь могу 12), разобрался в себе и смог выйти из внутреннего кризиса, ответив на сложные для себя вопросы). Процесс-ориентированные скорее констатируют сам процесс (12 часов сидел молча и не двигаясь, контролируя дыхание и мысли).
И в этом нет ничего плохого. Это скорее разные полюса одной личностной характеристики, не более.
Неполнота и недостоверность данных не снимает с исполнителя ответственности за контроль этих вводных данных и запросы на уточнение. Хорошо, если после фейла человек понял, что причина в отсутствии проверки и уточнения вводных, еще лучше, если он понял как это исправить, ну и вообще прекрасно, когда он смог придумать решение, которое снизит риск повторения инцидента к минимуму или вообще избавит от повторения.
Тоже самое и со стрессом. В конечном итоге решение принимает сам сотрудник, если он при этом в стрессе от 20-ти часового рабочего дня, у него ложные и неполные данные, то это не снимает с него ответсвенности за это самой решение. Безусловно он разделит её с руководством, допустившим подобную ситуацию, но не избавит – факт.
Можно конечно сложить ручки и плыть по течению, оговаривая всё вокруг «не я такой, жизнь такая», но как говорили современные классики «не стоит прогибаться под изменчивый мир, пусть лучше он прогнется под нас» и «нет другой судьбы, кроме той, что творим мы сами»;)
Ну и я не утверждал, что их меньше это напрягает, а лишь говорил о том, что стрессоустойчивые люди менее этому подвержены. Боль чувствуют все, но в зависимости от болевого порога реакция у каждого своя.
И тут вопрос не в овертаймах и авралах, не в отношении к ним, и уж тем более не в пофигизме. А в том, что если у двух людей в топе потребностей физическое удобство ОТ (например, близость офиса к дому) и удобство психологическое ОТ (неконфликтная среда единомышленников), то переезд офиса в отдаленный район и вынужденная борьба за место под солнцем (например, под угрозой увольнения) в свете кризиса, на сотрудниках с разной стрессоустойчивостью подействует по разному. Один откроет резюме и тут же пойдёт искать способ удовлетворить свои потребности, а второй стерпит и «перезимует» неприятности, если понимает, что они временные.
И я считаю, что задача руководителя/нанимателя, определив потребности будущего сотрудника дать себе и кандидату честный ответ, смогут ли потребности человека в этом месте удовлетворяться полностью, и вот если смогут лишь частично или вовсе не смогут, то тут и станет критичной пресловутая стрессоустойчивость, так как именно она будет определяющим фактором продолжительности продуктивной работу сотрудника в компании.
заинтригован, чем оно вызвано?
Отличная статья, Денис. В лучших традициях того, чему я у тебя в своё время учился!Сразу вспомнилась твоя «Библия разработчика высоконагруженного сервиса». Буду ждать вторую статью и цикла.
Про стандарт, очень хотелось бы, чтобы в профессию приходили замотивированные, увлечённые и склонные к самообучению люди, однако, в индустрии полно и аморфных тюленей с сомнительной денежной или имиджевой мотивации, а то и вовсе людей, которые просто хотят быть на хайпе.
Выгорание на работе происходит у всех, даже у самых замотивированных, увы. Причем по личному опыту, чем более мотивированным был человек, тем громче и с бОльшими последствиями он демотивируется. В духе поговорки про «чем больше шкаф, тем громче падает»:( Знаю немало кейсов переходов в тестирование из разработки и наоборот, универсальной профессии не существует. Рад, что в итоге обрели свое место и задачи, которые не вызывают печали и ужаса.
Ну это скорее список ингредиентов для горячего самобытного коктейля специалиста. Все знать совсем необязательно. Каждый выберет свой состав и соберёт профессиональный портрет, что ближе лично ему.