Pull to refresh

Comments 38

Я бы даже немного перефразировал: при выдаче обратной связи сотруднику надо говорить все «как есть», без прекрас. И если он работает хорошо — его надо хвалить, если работает плохо — его надо ругать и предлагать ему исправиться, если в целом все хорошо, но где-то косячит — надо указывать на болевые точки.

PS: про обязательность выдачи обратной связи сотруднику как минимум раз в год я уже молчу — это должно быть аксиомой.
а вот как ругать? Публично или приватно? Кто-то может обидеться на публичную критику, кто-то забьет, если она будет приватная.
Ругать надо приватно, ни в коем случае не прилюдно.
Если " кто-то забьет, если она будет приватная", то у него не должно быть «справедливого гнева» и пусть не обижается на увольнение. Был предупреждён.
Есть один способ отругать прилюдно и без обид — это отругать как бы в шутку.
Если конечно сложившиеся отношения внутри коллектива позволяют такое неформальное общение.

Это психологически проще как для руководителя так и для специалиста. А вот приватный вызов «на ковер» может быть стрессом для обоих, если это не происходит регулярно. А если регулярно — видимо в команде проблемы.
Понимаете, как показывает практика — некоторые люди воспримут «как бы в шутку» полностью несерьезно и не примут к сведению. А часто вы можете потом еще и услышать что-то вроде «ну ты же ни разу со мной это не обсуждал!»
Пока что для обсуждения проблем ничего лучше встречи один на один (или вы + программист + его непосредственный начальник).
Я бы не советовал если бы сам не пользовался такой практикой. Но нужна специфическая атмосфера в коллективе.

Представьте что старые друзья играют в боулинг, например. И самый среди них авторитетный говорит другому, по-отечески так «Эх ты, лошара, чуть на соседнюю дорожку не закатил». Все поржали, но выводы сделали. Вот примерно так.

Если коллектив настроен на работе чересчур серьезно, то конечно такой подход не будет работать. И да, не только коллектив, но и конкретные люди.
По-моему, вы приводите частный пример в качестве общей рекомендации. Мне все же кажется, что такую практику применять очень рисковано.
Конечно, может сложиться и коллектив, в котором подзатыльник может расцениваться нормально, но в 999 случаях из 1000 человеку подобная мера явно не понравится.
Это действительно частный пример, я написал что круг использования сильно ограничен.
Если под Вами есть руководители более низкого звена, то ни в коем случае нельзя их ругать в присутствии их подчиненных. Они с таким трудом завоёвывают авторитет! Один такой вынос при подчиненных может полностью его порушить. А подчиненный руководитель, который потерял авторитет у своих подчиненных, станет Вам совсем не нужен.

Если вы ругаете сотрудника за какую-то очевидную вещь, за опоздание например, по началу это можно делать приватно. Если приходится повторяться, то нужно усиливать эффект. Один из способов усиления – поругать при коллегах. Так же если вы ругаете сотрудника при коллегах, вы не только усиливаете эффект от этого и без того неприятного воздействия, а еще и даете другим знать: «У нас так не принято. За это ругают.»

Конечно, не стоит забывать, что бывают и исключения. Ценным сотрудникам имеет смысл прощать мелкие прегрешения в угоду того, что польза от их работы с лихвой перекрывает деструктивный эффект от их нарушений.
>ни в коем случае нельзя их ругать в присутствии их подчиненных. Они с таким трудом завоёвывают авторитет! Один такой вынос при подчиненных может полностью его порушить.

Мнение общераспространённое (хотя и не всегда выполняемое), но, по-моему, надуманное. Вы этих подчинённых держите за кого? Ведь для всех [подчинённых] очевидно, что основная цель существования промежуточных начальников в многоуровневой иерархии — подставлять вышестоящему начальству жо… э-э, быть прокладкой между подчинёнными и вышестоящим начальством. Прокладкой для битья. Или вы правда думаете, что они не в курсе. :)
Выше уже ответили: только в приватной беседе. Только в этом случае можно ожидать, что человек не начнет рефлекторно оправдываться. Тут мы конечно говорим про адекватного человека, который осознает что с ним разговаривает начальник, который зачастую имеет больший опыт и большую квалификацию.

А вот если человек забивает на то, что говорит его начальство относительно качества его работы, то значит этому человеку плевать вообще на качество своей работы и ему наверняка не по пути с компанией.
Вы не скажете, а нафига нужен проджект-менеджер, который «обратную связь» от начальства или заказчика говорит «как есть»? Может быть его можно заменить авто-форвардингом на сервере электронной почты? Может быть проджект-менеджер для того и нужен, чтобы в каждом конкретном случае определять, кто виноват, кому сказать «как есть», кому отфильтровать, а когда и самому заказчику неаргументированную предъяву завернуть?
Верно. Но я писал несколько о других вещах. Конечно, ПМ должен быть своеобразным файерволом между командой, заказчиком и начальством. Девелоперы — нежные, творческие существа. Не нужно им слышать, как заказчики орут матом.
>Не нужно им слышать, как заказчики орут матом.

Иногда нужно. Иначе слишком сильно отрываются от реальности :)
Вы не совсем поняли про какую обратную связь я говорил. Я имел ввиду не обратную связь по качеству разрабатываемого продукта, а обратную связь по качеству работы конкретного программиста, которую, как уже упомянули выше, надо сообщать приватно.

Обратная связь по качеству работы программиста != обратная связь от заказчика. Заказчик зачастую не может знать о том какой программист какой баг родил в системе. Так же и вышестоящий начальник может не знать какой программист сегодня, как впрочем уже целый месяц подряд, опаздывает на scrum meeting.

А вот обратную связь от заказчика в общем ПМ не должен выдавать разработчикам «как есть» (хотя тут зависит от команды и от ситуации и в некоторых случаях это будет нормально).
Все-таки тоже зависит от ситуации. Например бывают люди, склонные регулярно ломать билд. Как показывает практика, зачастую ни приватные беседы, ни статьи на вики об элементарных шагах, предотвращающих это не помогают. В одной компании где я работал это решили практикой «сломал билд — приноси тортик». Первый месяц торты ели каждый день, потом перестали.
Раз в год сотрудник и так это поймет по размерам бонусов :)
По размерам бонусов сотрудник не поймет где именно он накосячил или за что именно его поощрили. Это, кстати, тоже надо обязательно обговаривать.
«Раз в год» — не слишком большая задержка реакции? Ошибки нужно стремиться замечать сразу и реагировать незамедлительно. Иначе человек успеет еще много раз наошибаться и приумножить ущерб.
Конечно же все зависит от критичности ошибки. Иногда надо реагировать немедленно, а иногда можно раз в год обсудить что да как.
Напомнило один рассказ из детсва:)

У нас дома жили-были клопы. А дядя Лёша в гости пришёл.
— Как клопов извести? — спрашивает его папа.
— Очень даже просто, — отвечает дядя Лёша. — Надо отловить клопового царя, поставить его перед открытой дверью и сказать «Вон!» Вслед за царём уйдут и остальные.
— А который из клопов царь? — спрашивает папа.
— Который самый жирный, тот и царь, — подсказывает дядя Лёша и строго предупреждает. — Только смотри не засмейся, когда выгонять будешь.
— Ещё чего! — говорит папа. — Я же серьёзный человек.
И стал папа царя клопов ловить. Только ему всё мелочь попадалась. Худые какие-то и горбатые. В общем, папа совсем измаялся, надежду на царя потерял. Тут-то царь ему и попался.
Поставил папа царя всех клопов перед открытой дверью и говорит:
— Вон!
— Шутишь? — спрашивает его клоп с надеждой.
— Вон!!! — кричит папа и пальцем грозит.
Царь клопов вздохнул, свистнул своим и поплёлся. Вслед за ним поплёлся и весь клоповник. Самым последним шёл маленький, хромой, кривоногий клопик. Он переваливался с боку на бок и крутил задом.
Глядя на него, папа не выдержал и улыбнулся. И клопик тоже не выдержал и оглянулся. Да как крикнет:
— Хлопцы, он же добрый! Шутит он!
— Шутит! Шутит! — завопил весь клоповник и ломанулся назад в квартиру.
Хотел папа дверь захлопнуть, да разве против такой оравы устоишь?! Клопы дверь с петель сорвали, папу уронили, всем клоповником по нему пробежались.
Я помог папе подняться, а он и говорит:
— С детства, сынок, надо силу воли тренировать. Чтоб не улыбаться, когда не надо. Понял?
— Понял, — говорю я. А сам на папу смотрю и улыбаюсь. Он смешной такой, весь клопами истоптанный.
Интересно видеть такой заголовок статьи в блоге компании, на собеседовании в которой меня встречали словами «не важно как меня зовут» и «здесь я задаю вопросы».
Видно ваши ПМ-ы следуют описанному принципу, но правда перегибая.
Мы провели внутреннее расследованию по этому факту.
К сожалению, приходится признать, что примерно полтора года назад такой неприятный инцидент имел место.
Мы нашли сотрудника, который повел себя по хамски, но переучить его больше нет возможности. Он у нас больше не работает.
От лица нашей Компании приношу официальные извинения за неуместное поведение нашего бывшего сотрудника.
Есть о чем задуматься. Хорошие мысли.
Если шпынять людей, то они научатся лучше создавать видимость работы, но лучше работать не станут. А еще, взрослые люди не меняются. Работа — не то место, где уместно кого-то воспитывать. Проще расстаться, причем для обоих сторон.
Человек может не замечать каких то недостатков или слабых сторон в своей работе. Если ему на них указывать — от каких то недостатков, снижающих его эффективность точно избавится. Речь же не о воспитании каких то абстрактных человеческих качеств, а конкретно — про рабочие моменты.
Хвалить-ругать, гнать таких менеджеров нужно. Они изобретают велосипеды вместо того чтобы освоить методологию типа скрама и избавиться вовсе от хвалить-ругать. Нужно проводить ретроспективы, где обсуждают успехи и неудачи, определяются причины и что нужно сделать чтобы сохранить положительное и избавиться от негатива.
Scrum — отличная методология, и мы ее успешно используем. Тем не менее, я стараюсь не использовать слово «ругать», а стараюсь применять «указывать на недостатки». Указывать на недостатки — это самая что ни на есть прямая обязанность Scrum mastera. Он обязан учить команду и обеспечивать следование Scrum-у. Не указывая на недостатки, этот механизм не отточить. При этом каждый разработчик самоорганизующейся команды в праве и даже должен указывать на недостатки другим.
В тексте 7 раз было использовано слово «ругать», что меня очень удивило. При наличии в методологии ретроспектив, после каждого спринта все сами спокойно рассказывают что по их мнению было не так, люди сами ищут свои ошибки, становятся самоарганизованными и им ненужен ни менеджер, ни скрам мастер, ни тим лиды. Собственно менеджера у разработчиков вовсе быть не должно, как и любых других руководителей.
Только в плохих кампаниях ПМ является руководителем для программистов. У нас, например, менеджеры и разработчики — это два тесно связанных отдела, но каждый со своей иерархией подчинения. И это правильно.
От размера и типа проекта зависит. А также от конкретных личностей. Универсального решения нет.
Самое плохое, когда программиста некому контролировать, никто в команде не знает больше него и соответственно никто не может указать на ошибки или дать пинка.
Был случай, когда в районы отправил результаты ГИА на 50 тыщ человек неправильные, ибо ночью ошибся в запросе.
Отправка официальная, за подписью Министерства образования области.
Но проверить меня было некому, утром нашел баг, поднял всех на уши, хорошо еще данные в школы не ушли, успел обновить и до всех дозвониться (70 районов).
В итоге меня некому было ругать, ибо даже начальник мой и тем уж более Минобр не понимал в чем была ошибка. Если бы не обнаружил или захотел «сховаться» — порядка 20% детей получили бы на 1-2 балла ниже заработанных.
Причина — штат не имел средств для найма квалифицированного программиста (а надо двух), потому я исполнял роль человека-оркестра.
Вывод — не экономьте на кадрах.
>Если бы не обнаружил или захотел «сховаться» — порядка 20% детей получили бы на 1-2 балла ниже заработанных.
Вы молодец, раз рискнули своей репутацией ради испровления ошибки.
Топикастер, Вы описываете судьбу конкретного прогграммиста или гипотетического?
Вы про «загубленного программиста»? К сожалению, да, этому мне пришлось учиться на реальных событиях.
И какой вывод Вы для себя сделали? Будете теперь требовать от нового менеджера отчетов в том, как он видит Вашу эффективность?
Совершенно верно.
Когда мы только начинаем работать, я первым делом выясняю, чего же мой руководитель от меня ждет.
Далее, если он не заботится сам, я периодически запрашиваю у него фидбек о моей работе и, главным образом, негативный. Далее, довожу до него, что я из этого понял, какие выводы сделал и как буду улучшаться. И работаю в этом направлении.
Это позволяет мне надеяться, что мой руководитель мной действительно доволен.
Sign up to leave a comment.