Comments 27
В российской культуре, к сожалению, не принято спрашивать разрешение дать совет и от одаривания, как правило, невозможно отказаться
Ахахаха, прямо по больному!
Я для себя выработал алгоритм для таких случаев. Особенно хорошо он работает для бытовых, а не для рабочих вопросов.
- Скажи, что ты думаешь о <…>?
- Ты действительно хочешь знать мое мнение/спрашиваешь моего совета?
- Да.
- Ну тогда лови!
Вот реально, я забил себе в голову такой автоматический дисклаймер и выдаю его каждый раз. И вы знаете, после того, как я переспрашиваю про желание узнать мое мнение, далеко не все продолжают настаивать, что да, хотят. Видимо, что-то у меня в голосе такое :). А те, кто возжелал и услышал что-то неприятное или просто не совпадающее с их точкой зрения, могу обижаться только на себя.
Ведь я их предупреждал...
Довольны этим?
Вообще шикарно.
Давать советы (даже хорошие и взвешенные) - рискованная задача: всегда что-то может пойти не так, а виноват советчик. Так что снижение количества спрашивающих совета - это благо для меня.
Подчеркну: я говорю именно о бытовых советах (как быть, как жить), а не о профессиональных вещах типа "ой, а почему в Экселе два числа не складываются"
Я для себя вывел правило: не просят, не лезь со своим мнением. Было немного трудно поперву, но оказалось, что никого и не интересует твоё мнение ))) Обычно все своё высказать хотят ))
В итоге иногда слушаешь собеседника, думаешь, я бы тут поступил такто, но молчишь.
Ну как-то все черно-белое.
Я пришёл в крупную компанию из другой отрасли. Вроде, опытный, но в подобном бизнесе не участвовал. Моими руководителями были главы департаментом (мне "повезло" с матричный системой). Задачи ставились, примерно, так:
Ты туда не ходи, ты сюда ходи. Ступай и да прибудет с тобой сила.
Тот парень уже когда-то делал подобное, он тебе все расскажет.
На сервере есть папка с документами за прошлый период. Надо сделать такое же "только с перламутровыми пуговицами". Если не понятно, говори.
Если уже взяли в компанию, то никто не устраивал тестирования или обучения на ошибках. Задача должна быть решена. Если задача критичная, есть промежуточные чекпоинты.
Странно, но как-то совсем упущен вариант: "Спросить почему и зачем и вообще, как он дошел до такой жизни/решения?" Вполне может оказаться, что "провал" только в голове у подглядывающего, в силу бОльшей квалификации у Исполнителя.
P.S. По жизни, встречал не единожды:
-"Блин, вот чО он делает? Провалит степик же.."
.. через пару недель, ковыряясь в коде автора:
-"Хм. Работает.. и так работает .. и тут. Очень шустро.. а что так можно было?"
Полностью согласен. Первая автоматическая мысль спросить "а зачем?". В конце-концов, "дурак" тут может быть с обеих сторон. Если уж я действительно "мимокрокодил", то логично по дороге зайти к непосредственному лиду этого разработчика и передать информацию, дальше сами разберутся.
По мне так это единственный правильный вариант, а не вот это всё с кучей букв...
У самого сейчас два студента на практике. Единственная моя политика - задавать простые вопросы, пока либо мне не станет ясно, что студент прав (пара случаев из ста), либо студенту не станет понятна глубина его незнания и заблуждения. "Подсматривать" и за работой таких сотрудников, считаю необходимым, но не всё время, а когда иду с кофием мимо них.
При таком подходе быстро становится понятно, кто осознано работает, а кто просто что-то тыкает, перебирая варианты - тоже вариант работы, но менее эфективный
ага, согласен, можно было добавить вариант вроде "устроить внезапную проверку промежуточных результатов, потребовав объяснений что делает сотрудник". Тоже распространенный, судя по комментариям, вариант.
А зачем внезапную?
Я откуда знаю) но именно это предлагают комментаторы выше: увидев потенциальную проблему, подойти к сотруднику, отвлечь его от работы, начать задавать вопросы зачем и почему он делает, то что делает. Для сотрудника эта "планерка" явно будет выглядеть внезапной.
Такая "проверка" не является внезапной и не является отвлечением. Потому что эта практика регулярная и ты его просто просишь озвучить, что и почему он делает, если потребуется, то уточняются дальнейшие действия. Человек не отвлекается на другую работу, а формулирует текущую работу. По тому как человек может сформулировать эти моменты, понятно - на сколько он сам понимает, что делает. Опять же, я не буду трогать человека просто так, только если вижу, что он застрял или делает что-то чего я в процессе не ожидаю
Сам иногда, когда понимаю, что начинаю тупить, отлавливаю проходящего коллегу, когда он идёт с перекура (или чего похуже), и проговариваю ему проблему, варианты решения которые есть и которые не работают. Часто именно в этот момент приходит понимание, что и почему не так
Я бы просто спросил не нужна ли ему помощь (если откажется то настаивать не надо).
Бывает что сотрудник видит что выходит фигня, однако считает что делает все как надо (например не правильно понял архитектора) и это всего лишь из за того что работа не доделана а он слишком "юн" и не понимает великий архитекторский замысел.
Сам навык спрашивать помощь вовремя это то, что у многих не развито и он плохо развивается на разборе полетов.
В описанной ситуации все варианты исходят из одной проблемы: менеджер не удостоверился, что его вообще поняли, и не узнал, что в итоге будет делать подчинённый.
не понятные условия какие-то, менеджер странный, варианты ответов абсолютно не универсальные. если сесть со стажером и полностью сделать вместе кусок работы - это нормально, они вам будут только благодарны. то можно только представить направления куда вы должны пойти по мнению профессионала, если попытаетесь вот так влезть в его работу.
оптимальный результат - позволить сделать ошибку? чтобы что? чтобы потом прийти и сказать "вот ты дурачек, да, три дня потратил вообще не на то"? а потом вы сдвигаете дедлайны задачи в два раза потому что "я позволил совершить ошибку, ведь промежуточный результат в других руках может казаться стремным". или все-таки конечный результат оказался удобоваримым? ну тогда и ошибки получается нет, в чем тогда проблема?
и с каких пор ученикам нельзя пошагово говорить что делать? вот ко мне пришел человек на проект, которому около 10 лет, код база огромная. мне нужно корректировать его и подсказывать куда смотреть, иначе он просто утонет. теряет ли работник ответственность за проделанную работу? нет, код ведь не я пишу, баги за ним не я чиню, мы вместе обсуждаем лучшее решение и подходы.
интересно, что выводов нет вообще никаких, ведь в любом варианте, виноваты вы. или заставили бедного стажера грызть ногти от мысли "я неправильно понял задачу, я некомпетентен, меня уволят" или профессионала думать, что менеджмент не может говорить ртом при постановке задачи.
Ты поставил подчиненному задачу, описал цель...
Изложение мыслей и постановка задач подчиненным - это умения, которые не появляются с момента коронации. Даже сам вопрос вызывает непонимание. Что скрывается за словами "описал цель"?
"Описал цель" - это показатели, на основании которых можно сделать вывод об успешном выполнении задачи? Тогда как можно на полпути до контрольной точки рассуждать о достижении этих показателей? Нет ли здесь микроменеждмента? Я выбрал бы второй вариант в изложении "ничего не делать." без суждения об ошибочности.
"Описал цель" - это показатели и конкретные способы достижения показателей. Тогда уже на этапе постановки задачи опять появляется микроменеджмент. Тогда несколько слов о микроменеждменте...
Микроменеждмент - верный спутник несоответствия квалификации в связке начальник-подчиненный, пропорции несоответствия - разные и зависят от ситуации.
Можно, конечно, привести массу примеров за и против, но... Развитие умений и подчиненного, и руководителя происходит именно на основании собственного опыта. С разной скоростью усвоения этого опыта т.к. идеальные подчиненные и руководители бывают только в книжках про успешный успех. А в жизни, вы и сами все видите как происходит, особенно если не носите розовые очки.
Думаю вариант стоит оценивать исходя из задачи и уровня подчинённого, как по мне главное чтобы он понимал, что не один и может рассчитывать на помощь ?
Бывает, что человек просто боится спросить как правильно, хотя понимает, что что-то не так, в итоге потеряно и время в процессе разработки, и время в намеченной точке контроля, ещё и приходится ещё одну такую точку планировать, если изменения требуются не маленькие.
Возможно не надо смотреть как кто то работает?
Что делать, если подчиненный делает не то, что нужно
Рискну предположить, что нужно:
1) уметь выбить из клиента, что клиенту действительно нужно (оно, как правило, сильно отличается от того, что у него из ротового отверстия проистекает);
2) понимать, что вообще реально возможно (см. "семь перпендикулярных красных линий") и соответственно уметь отказывать клиенту, когда ;
3) уметь донести воспринятое от клиента на шаге 1 до собственно прогаммиста.
Как мы шутим, "по большому счёту, менеджер — это переводчик с человеческого на программистский".
Спасибо за наблюдения) Как минимум, можно выбрать для себя подходящий вариант реагирования. И на десерт, мнения в комментариях)
У нас был руководитель, на вопрос, ЗАЧЕМ это делать, и щачем это делать ТАК, говорил: ты не понимаешь...
Спрашиваешь: ну так объясните? : -нет, ты не понимаешь, иди отсюда... )))
В итоге все "не понимающие" и ушли )))
Что делать, если подчиненный делает не то, что нужно