Как стать автором
Обновить

Комментарии 175

Вы не будете против, если я некоторые гифки из вашей статьи включу в нормативную документацию нашей организации?
Ради бога
Вы же первую включите, да? )
Её я хочу логотипом сделать.
Какое-то странное ощущение, что я это уже читал давно где-то типа на мегамозге:) Прямо дежавю какое-то.
Не просто так 2.0 в конце названия :) Был с этой темой на конференции 1,5 года назад — конспект по выступлению публиковал здесь Битрикс, но по пути потерял в сочности и точности. И за год накопились ещё соображения — поэтому решил материал обновить и дополнить.
Как жаль, что далеко не все руководители знают, что должен быть не только кнут. Без пряника кнут — не наказание, а полнейшая демотивация для дальнейшей работы, что влечёт за собой новые наказания и так по наклонной.
Работал я как-то полторы недели у одного руководителя, который любил клавиатурами кидаться в подчинённых.
Ergo: специфика метода кнута и пряника в России в том, что у нас пряником тоже бьют.

©
> 5. Руководитель обязан наказать подчинённого, если тот нарушил установленные и доведённые до него правила.
> 23. Некоторых людей наказывать нельзя.
Список таких людей должен быть включён в регламенты? Иначе пункты противоречат друг другу.
Если человек понимает, что накосячил, сам себя за это изводит и в итоге совершенствуется и в будущем не повторяет ошибку — он относится к п.23. Таких людей нельзя наказывать, потому что они уже настрадались сами от себя. В итоге безнаказанными они все равно не остаются — просто руководитель в этом задействован минимально.
Это понятно, но в текущей формулировке есть противоречие «руководитель обязан наказать» — «наказывать нельзя». Выходит, что руководитель сам нарушит свой регламент, и по-хорошему должен будет себя наказать, а вдруг он такой «некоторый» человек, что его нельзя,…

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

Всех людей не получится наказать одинаково — на выговор одни обидятся, другие пропустят его мимо ушей. К проступку и человеку наказания нужно подбирать индивидуально. И в случае с людьми из п.23 — они ПОЛУЧАЮТ НАКАЗАНИЯ. Просто способом, в который руководитель вовлечён по минимуму — ему нужно только убедиться, что человек всё понял.

Ну а дыры есть везде — об этом и шла речь, но в другом контексте.

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

Касательно ситуации в отделе, про которую я писал выше:
  • тестирования нет
  • любой коммит в CVN — сразу па прод
  • менеджеров нет, задачи меняются на ходу
  • любой баг от разработчика — и он на доске позора
У нас не было в той команде самовлюбленных людей, неспособных к шуточной самокритике.
В дятла, по всей видимости.
Какой-то треш если честно.
Встречался с одной конторкой где руководитель отдела, менеджерам которые не выполнили план или ж накосячили лепил бейджик с надписью «Я плохой сотрудник» (или что то подобное — конкретно не помню). Так вот текучка кадров там была просто жесть.
Возник вопрос по поводу примера джуниора с сеньором — то что менеджер попросил (что значит «попросил» отдельный разговор, да вы и сами про жиру пишите) Петю пойти к Кате есть, а вот ставилась ли такая задача Кате? Потому как если задача не ставилась в явном виде даже если подразумевается что у Кати где-то в должностных инструкциях это записано, то ей придется списывать время потраченое на джуниора на какую-то еще задачу и обязательно рано или поздно возникнет вопрос «Вот ты за день обещал сделать, почему не сделал?». И ответ «я из 8 списанных часов 2 реально потратил на помощь джуниору» звучит отговоркой и далеко не всегда менеджеры его примут, особенно если если почему-то затеян разбор постфактум.
Пример абстрактный. Есть компании, где за опытным сотрудником закреплён начинающий — и учи его как хочешь, когда хочешь — твои проблемы. У себя мы это просекли и истребили уже давно: джуниору или стажёру ставится задача задавать вопросы наставнику в конкретное время, с 4 до 5, например. А у наставника задача с 4 до 5 на них отвечать. Но не везде так.
Правильнее ставить задачу сеньору — научить джуниора тому то и тому то.

Результатом должно стать выполнение джуниором какой-либо работы под руководством сеньора и какой-либо работы самостоятельно.
И критерий оценки работы по обучению сеньора именно такой «Выполнение джуниором таких то задач в такие то сроки и устная сдача этих задач независимому сотруднику, проводящего ревью»
НЛО прилетело и опубликовало эту надпись здесь
При условии, что сеньор выступает как тим-лид в данном случае или развивается в этом направлении.
Часто ему надо помочь хотя бы научиться делегировать задачи
НЛО прилетело и опубликовало эту надпись здесь
Тут уже всё зависит от конкретной команды и процессов.
Мне чаще встречалась структура, когда тим-лид чаще это тот, который раздаёт задачи всем — от джуниоров до сеньоров ( системный архитектор в стороне от всего этого действа и является неким техническим тимлидом для тимлидов, но не руководителем проектов)
Хотя вариант суб-тимлида тоже встречался, но всё зависит от конкретного сеньора
Потому что есть компании и спросил. Был когда-то опыт когда джуниор ходил ко мне чуть ли не сигнатуры функций узнавать (причем я и сам тогда был не сказать что сильно опытным разрабом), задолбался отправлять его читать хелп. Хорошо что таймтрекинга там не было.

Но стоит это как-то отобразить в статье, а то складывается впечатление что наказание Кати будет противоречить «Руководитель не имеет права наказывать подчинённого, если тот действовал не превышая своих полномочий»
Ваш пример ещё и некорректен тем, что тут явно ошибка коммуникаций. А в любой ошибке коммуникаций виноват менеджер.

Дали джуну задание, решить задачу с помощью Кати. Катя его отфутболивает. И тут ровно 2 варианта: решить задачу самому, или идти мучать менеджера. В первой ситуации можно наткнуться на вас, пытающегося все зарегламентировать и наказывающего за творческий подход фактически. А во второй, что чуть не более вероятно, наткнуться на «мы тебя задачи решать наняли, а не вопросы задавать» и тоже получить по шапке.

В вашем примере ничего не говориться про инструкции для решения, когда все пошло не по плану. Инструкции нет, исполнитель поступил на своё усмотрение, вы его хотите за это наказать?
>> Но со временем научитесь подбирать наказания соизмеримые с косяком
А можете привести несколько примеров наказаний разной степени тяжести из реальной практики? Вот сходу не могу придумать. Либо устный выговор, либо штраф, либо увольнение. Если будет по типу «косяк такой — наказание такое», будет вообще прям идеально.
Ну вы и лентяй :) Даю пример:
Как на счет посадить слишком сильно возмущающегося разработчика на месяц только сапортом и мелкими тикетами заниматься :) Как по мне — так это адская кара, хуже уж даже и не знаю что :))
А после этого месяца он поймёт бренность своего существования, разочаруется в компании, скажет «до свидания» и уйдёт в монастырь другую компанию.
И отработает месяц на саппорте там.
НЛО прилетело и опубликовало эту надпись здесь

Реальная ситуация у нас, одного выездного товарища, который не тянул, решили переквалифицировать в телефонную первую линию. Мол, нам всё равно нужно человека искать, решили найти среди своих, а так как выездному тебе всё равно не светит. Он отпирался, действительно увольняться хотел, но всё-таки попробовал. В итоге — уже года два так работает и доволен, понравилось.

А не дороговато для первой линии?
Штрафовать нельзя — можно лишать премии. У нас всё просто. Абсолютно вся деятельность регламентирована, от дисциплинарного регламента до бизнес-процессов. Ошибки не караются, а вот опаздания, забивания и работа спустя рукава караются вычетами из премии. Творчество, рационализаторство — поощряются.
НЛО прилетело и опубликовало эту надпись здесь
Так сложилось, что демократичный подход не сработал. А переход к тирании очень положительно отозвался, сам был в шоке. Ещё у нас в полном соответствии с ТК есть замечания, взыскания и выговоры.
НЛО прилетело и опубликовало эту надпись здесь
Просто бизнес не IT. Разные профессии требуют разной мотивации. На собственной шкуре понял, что мотивация программиста и, например, рабочего несколько отличаются. Рабочий может запить после аванса и не выйти на работу. Я не утверждаю, что все рабочие пьют или бездельничают, просто статистика показала разный подход к ответственности и разную частоту нарушений.
С программистами у меня проблем в жизни не было, вопрос о мотивации даже не стоял — и график свободный, и свобода в подходе к задачам.
В Inside Intel рассказывают, как опоздавших сотрудников заставляли раписывать в списке и даже это вызывало бурю негодования.

Кстати, если премия составляет бо́льшую часть зарплаты, то штрафы окажутся незаконными при разборках в трудовой инспекции, а символическая дисциплинарная премия воспринимается как абонемент из поста.
30% премиальных. Если нормативы не выполняются два месяца, то расстаёмся.
1. Самая противоречивая часть статьи в этом: «молодой руководитель» и само понимание проблемы наказания. Пока шишек не набьёт — не поймет.
Все описанное в статье требует взвешености, понимания системного результата и взаимосвязи неочевидных вещей. Это отсутствует как класс у указанной категории руководителей, зато есть амбиции, самоутверждение и доминирование.
Ваша статья — это самоучитель по плаванью на дне бассейна.
2. Вы описываете все это для регламентного управления, которое само по себе не панацея: случаи, когда все всё сделали правильно и по регламенту, а результата в лучшем случае нет — не то что не единичны, а скорее правило (тока про них не расказывают). Причина обычно в руководстве и изначальной постановке задачи. В малых и средних командах за счет отсутсвия иерархии и четких правил это могут компенсировать вовлеченностью и неравнодушностью персонала и авральным групповым натиском.
Для полноты эксперимента хотелось бы увидеть тоже самое для небольшого целеустремленного коллектива с нечеткими регламентами, действующими с учетом контекста отдельных задач.

3. «Самое хардкордное — это увольнение.»
а) в реальном мире за очень многие вещи есть уголовная ответственность. И руководителя тоже. Начиная с техники безопасности и заканчивая причинением ущерба на круглые суммы. Программистам пока очень везет, что для них ещё не сформулирована ответственность за кривой код. Но лет через 10-20 думаю будет — когда простые механические вещи получат программную начинку. Вон компании-разработчику для Теслы хватило 3 ДТП и 1 трупа, чтобы заявить о прекращении сотрудничества по автопилоту. (Кстати, интересно почитать юзерское соглашение от Теслы, где разрешается самоубиваться с автопилотом).
б) вы наверное не в курсе ситуаций, когда бывший уже сотрудник переписывает машину или подписывает нотариально обязательство. И это даже без «терморектального криптоанализа»
б) вы наверное не в курсе ситуаций, когда бывший уже сотрудник переписывает машину или подписывает нотариально обязательство. И это даже без «терморектального криптоанализа»

А можно поподробней с этого места?
Если сотрудник — материально ответственное лицо, признал недостачу и погашает её тем или иным способом (в том числе и по решению суда) — всё в рамках закона.
В остальных случаях «переписывание машины» попахивает уже статьёй 163 УК РФ («Вымогательство») и мы из правового поля переходим на несколько иной уровень, где к вам могут подойти на улице и предложить отдать все деньги под угрозой «отправить в гости к пра-пра-пра-дедушке».

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

Если у вас есть идеи как всё-же это чётко расписать — поделитесь со всеми, будет реально круто.
По материальной ответственности сотрудников.
Есть компании, где очень большое сотрудников материально ответственные. И первое, что приходится делать для перевода вопроса в правовое поле — это официальная выплата ЗП в полном объёме. В противном случае обе стороны действуют в «серой зоне» между законом и чистым криминалом. И решения в правовом поле могут быть не выгодны даже виновной стороне. Попробуйте подать в суд на офшорного программиста и типа того.

По ответственности за качество ПО.
За посление 40 лет, как появился рынок бытового ПО, решения об ответственности программиста за результат работы ещё не найдено. Я сейчас за 5 минут не решу этот философский вопрос.
Однако, прецеденты уже есть в корпоративном секторе. Тот же скандал с Фольксвагеном в США. Если бы вдруг выяснилось, что изменение программы бортового компьютера — частная инициалива программистов, то их бы засудили на 3 поколения вперед. Но в этом случае, как вы написали, да и я отмечал — вопрос в изначальной поставновке задачи менеджентом.
Поэтому первое что может случиться — это ответственность компаний-заказчиков и топ менеджеров в отраслях, затрагивающих реальный мир, а фотки котиков…
А далее — вся индустрия ПО держится на том, что везде прописано, что никто ни за что не отвечает.
Кстати, есть здоровенный сектор программирования, где вопрос об ответственности программистов давно решен. Путем их полного отсутствия. Это финансовые (в основном) расчеты в экселе, где человек практически нулевой программистской подготовки на примитивном техническом уровне, но глубоко в предметной теме, создает продукты довольно большой сложности. При этом он сам же продукт тестирует. И несет ответственность за его работу вплоть до увольнения.
Значительная часть такиех продуктов не позубам программистам, потмоу что сначала надо понять предметную область.

Да фигня с фольксвагеном, вы Therac-25 вспомните. И сразу появляется понимание, почему нужна и будет ответственность программистов за качество ПО.

Вы так легко пишите про материальную ответственность. Вы в курсе почему на западе такие дорогие мед. услуги? Как минимум — потому что нужно платить адскую страховку, ведь всякое бывает. Риск должен быть оправдан.

А теперь представьте что программисты стали отвечать «за все». Вы согласитесь на (цены сегодня) х 5?

В принципе, "ответственность за всё (в рамках закона)" для программистов существует и существовала всегда.
Закон обладает высшей юридической силой среди всех остальных источников права (http://www.webarhimed.ru/page-220.html).
Следовательно, что бы там ни писали в различных пользовательских соглашениях и лицензиях — всё из написанного, что будет противоречить нормам закона будет считаться юридически ничтожным, недействительным (http://dom-i-zakon.ru/articles/inoe/78758374587438765734657834657/).
Отсюда следует, что, если в случае с Фольксвагеном, нарушившим экологические нормы, удар пришелся по менеджменту компании потому, что инженеры сумели что то предъявить при разбирательстве, доказывающее вину менеджмента, хотя тот и пытался "повесить" все на инженеров; но, в следующий раз менеджеры ошибку не повторят и инженерный состав, выполнявший преступные указания, но не сумевший доказать отсутствие своей вины, "присядет" — сначала на скамью подсудимых, а потом и на скамью в местах отбывания наказания.
Так что программисту всегда стоит помнить, что он и так отвечает "за всё (предусмотренное законом)" и не питать иллюзий, что, написав в пользовательском соглашении наивное "я ни за что не отвечаю — я в домике" он будет защищён — он защищён не более, чем "голый король".
Например, занимающемуся разработкой игр для детей человеку, стоит помнить, что существует Федеральный закон Российской Федерации от 29 декабря 2010 г. N 436-ФЗ «О защите детей от информации, причиняющей вред их здоровью и развитию» (нормативный акт, предусматривающий отнесение информационной продукции к одной из пяти категорий, и запрещающий её распространение среди детей в зависимости от их возраста) и существуют многочисленные общественные организации по защите детей и детства, которые без колебаний применят этот закон, если разработчик нанесет вред детям, даже случайно или не неумышленно.
Отсюда вывод — программист сейчас несет ответственность на общих основаниях с людьми иных профессий и имеет массу шансов стать, как минимум, "подозреваемым" со всеми вытекающими — подозреваемым признается лицо: в отношении которого возбуждено уголовное дело по основаниям и в порядке, которые установлены главой 20 УПК; которое задержано в соответствии со ст. 91 и 92 УПК; к которому применена мера пресечения до предъявления обвинения в соответствии со ст. 100 УПК; которое уведомлено о подозрении в совершении преступления в порядке, установленном ст. 223.1 УПК (ст. 46 УПК РФ) (http://isfic.info/urpro/ugcou30.htm; смотреть осторожно: https://www.youtube.com/watch?v=zdOwiKwV1DI).
И, между прочим, цены в х5 не выросли :)...

Не понял пример про детей
нормативный акт… запрещающий её распространение среди детей
Если это обычный исполнитель (кодер), то где тут распространение? Если это одиночка, публикующий свои игры в сторе, то он ответит не как программист, а как предприниматель.

Тут все тоньше — согласно ч. 1 ст. 24 УК виновным в преступлении признается лицо, совершившее деяние умышленно или по неосторожности.
Например, инженером был сделана игра для детей, в процессе работы в компании, которая была признана слишком жестокой для использования детьми. Хитрый менеджер повесил вину на инженера сказав — вот внутренний приказ организации, в котором только говориться о разработке данного программного продукта, но ничего не говорится о том, как конкретно её разрабатывать (нет указаний от организации совершать противоправные действия), — значит, все действия при разработке, вызвавшие вопросы у правоохранителей инженер, [УМЫШЛЕННО] совершил сам! — с него и спрашивайте — незнание законов не освобождает его от ответственности!!!
У этого ФЗ следующая сфера действия:
"1. Настоящий Федеральный закон регулирует отношения, связанные с защитой детей от информации, причиняющей вред их здоровью и (или) развитию, в том числе от такой информации, содержащейся в информационной продукции".
Смысл в том, что сначала к организации, распространяющей программу, придут на основании этого ФЗ заинтересованные лица, а уж потом, когда будут грамотно переведены стрелки и заинтересованные лица познакомятся с разработчиком лицо в лицо, то уже к разработчику будут применять другие законодательные акты.

Насколько я понял из ст. 6 и 17 436-ФЗ, должна быть проведена классификация и экспертиза продукции перед выпуском её в оборот. Причём требования к эксперту в ст. 17 достаточно жёсткие и им не может быть программист (необходимо высшее профессиональное образование и обладающие специальными знаниями, в том числе в области педагогики, возрастной психологии, возрастной физиологии, детской психиатрии). В любом случае, если в должностых обязанностях исполнителя не указаны работы по возрастной классификации, то какие претензии, что эта работа не выполнялась?
ч. 1 ст. 24 УК виновным в преступлении признается лицо, совершившее деяние умышленно или по неосторожности
Какое деяние? Распространение разработчик не совершал умышленно или по неосторожности. А за создание недетского контента не предусмотрено наказание, как это есть, например, для вирусов или троянов.

А разве производство недетского контента в виде компьютерной программы не будет есть "создание, использование и распространение вредоносных программ для ЭВМ"
стр. 123
http://www.e-reading.mobi/bookreader.php/134825/Kovaleva_-_Informacionnoe_pravo_Rossii.pdf

Если открыть эту статью и прочитать ее, то можно увидеть, что деяние описывается следующим образом:
> Создание, распространение или использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации

Каким образом недетский контент заведомо предназначен для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации?
Конечно, программа «для взрослых» не является вредоносной (например, игра Doom с рейтингом 18+)
Да, закон имеет выслую силу. Но вы о другом.

Ни раз не слышал что из-за ошибки в ПО самолета судили программистов.
НЛО прилетело и опубликовало эту надпись здесь
>вопрос ответственности очень сложный:
Ничего сложного.
В первом случае стрелочником будет тот несчастный, которого поставили руководителем. И более никто.
Во втором случае отвечать будут сбившие водители. Каждый по своему трупу, и более никто.
В третьем случае о какой-либо ответственности кого бы то ни было речи не зайдет вообще. Бездействие вообще крайне плохо доказуемо и наказуемо, разве что Лонгрена можно было под эту статью подвести, он для такого обоснования все сам сделал.
НЛО прилетело и опубликовало эту надпись здесь
В первом случае наниматель может понести ответственность тогда и только тогда, когда будет доказана заранее известная недееспособность нанятого руководителя. То есть если бомж орал, отбивался и размахивал справками из псих- и наркодиспансера, что он там на учете, позавчера из Кащенки, а вчера из ЛТП: и самое главное, если при этом бомжу удастся доказать, что наниматель видел эти справки до заключения договора. Все, что произошло после подписания, проходит под соусом «введение нанимателя в заблуждение», и отягчает ответственность бомжа. А вы думали, откуда пошла поговорка про стрелочника?

Во втором случае очевидно, что ответственности не несет никто. Если очень хочется, то по каждому делу можно вешать ответственность на сбитого пешехода, но это потребует дополнительных юридических усилий.
>> Вроде бы Петя хорошее дело сделал: прокачался сам и выполнил задачу. Но в системе регулярного менеджмента его нужно наказать.

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

Может я раскрою великую тайну, но как поступать в таких ситуациях у нас учат ровно в одном месте и большинство разработчиков туда не страмиться.
О как. Теперь у нас еще и «творческий подход» нарисовался :-)

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

В том и дело, что правильный один. А вот какой именно, зависит от политики руководства. И даже в регламентированном случае не всегда есть возможность связаться с менеджером. Он «внезапно» может быть занят. Тогда задача не будет выполнена совсем?
:-) Вариант ровно один _вообще_. Ибо своевременное информирование руководства — это вообще-то та основа, на которой строится делегирование полномочий вообще.

Понятно, что ожидать от «Пети» — просто в силу его проф. опыта — варианта: «Катя занята. Пока пытаюсь разобраться сам. Тогда-то тогда-то отчитаюсь по ситуации» — так себе вариант :-) Но это абсолютно не значит, что «Пете» такое не информирование должно «сойти с рук».

Ведь, вообще говоря, то, что «Петя» таки «закрыл таску» совсем не означает, что достигнуты те цели, которые вы, как руководитель, ставили, давая «Пете» эту задачу :-)
Другими словами, вы допускаете, что Петю никто не учил как вести себя в этой ситуации. Руководитель не разъяснил до конца задачу, но Петя виноват, и его надо наказать?

Не научили — не виноват. А за ошибки не наказывают.
>Руководитель не разъяснил до конца задачу, но Петя виноват, и его надо наказать?

Я извиняюсь, Вы о чем вообще?! Задачу «Пете», судя по всему, «разъяснили». И, в конце концов, он же её выполнил. И выполнил хорошо. За это его как раз «хвалят».
За это его как раз «хвалят».
Ну вот в статье наказывают.

Задачу «Пете», судя по всему, «разъяснили».
Допустим, менеджер поставил задачу junior-программисту Пете, чтобы он спроектировал базу данных. И, так как он только учится, менеджер просит, чтобы Петя позвал на помощь опытного программиста Катю. Пусть посидит рядом, поможет-подскажет.

Из формулировки не ясно, сказали ему это делать строго под присмотром Кате, или просто обратиться к Кате за помощью.

В первом случае Петя не прав. (И может быть даже виноват, если формулировка понятная и он как в армии повторил своими словами)
а во втором случае не виноват вообще.
Наказывать рублем можно. Для этого существует «премиальная часть» заработной платы. У нас практикуется как ее уменьшение в связи с проступками, так и ее увеличение в связи с особыми заслугами (например в течение месяца перевыполнили план по задачам, узкая тропа конечно, могут начать завышать сроки изначально, но для этого есть тимлиды и другие руководители, чтобы валидировать).

Очень интересная тема и статья, спасибо. Можно еще затронуть целеполагание и ответственность (постановка задачи или делегирование задачи) в 3.0 версии.

Можно лишить премии, да. Но будет ли это наказанием, которое не обидит, в следствии которого человек поймёт:
а) где был неправ;
б) какие неприятные последствия его проступок повлёк за собой;
в) почему в будущем так делать нельзя.
Все это легко может скатиться в «начальник — жлоб, и я с этим ничего не сделаю». В интеллектуальной среде, как показывает практика, моральные наказания намного эффективнее материальных.
Если существуют руководители, которые просто лишают премии молча, то нужно их всех сжечь! :) Конечно же сначала нужно поговорить с сотрудником и объяснить ему свою позицию и ситуацию в целом. Вот тут как раз и полезно было бы объяснить границу ответственности сотрудника между поставленной задачей и делегированной. Если я ставлю задачу разработчику мигрировать данные из одной бд в другую и он не справился в срок с этой задачей, то тут виноват я сам и в первую очередь мне нужно решить как ставить этому разработчику задачи чтобы он делал то что мне нужно и когда мне это нужно (если это сделать во время дачи обратной связи, то может оказаться что и наказывать не за что). С другой стороны, если я делегирую ему эту задачу, то:
1) Мне нужно донести до сотрудника что теперь это его ответственность и любой факап какой бы то ни был будет на его совести (премии). И вот тогда мне уже точно нужно наказывать когда чтото пойдет не так. По другому задача не делегируется.
2) Дать ему полномочия для решения этой задачи. Например для мигрирования данных нужно тормознуть продакшн серваки на какоето время, и если ответственные этого не сделают то мой разработчик будет вправе лишить их премии или заставить носить клоунские носы несколько дней.
3) Мотивировать сотрудника. Отдельно это выделил, так как при делегировании, мне кажется, нужно этому моменту уделить больше внимания. Ты как руководитель уже мотивируешь не тому, чтобы человек выкладавался в рамках заданного процесса, а чтобы он сам этот процесс построил и добился результата (более бизнесового чтоли).
Мотивировать сотрудника

Мотивировать руководителя сотрудника на построение бизнес-задачи и построению процесса. А заодно донести до каждого руководителя, что именно ОН отвечает не только за задачи, а и за мотивацию сотрудников, а не кто то иной

PS. Есть интересная книга (бизнес-роман) — «Патрика Ленисони — 5 пороков команды. Притчи о лидерстве» и там есть очень хороший подход по поводу мотивации команды и её проблем:

image
Немного Вас не понял. Вы хотите сказать, что пример с делигированной задачей неверный? Нужно такие задачи ставить руководителям, а не подчиненным?
Насчет ответственности за задачи и мотивацию я с Вами полностью согласен.

P.S. Спасибо за книгу, почитаем. А пирамида прям как по Маслоу :)
Пример как раз верный, но, на мой личный взгляд, задачи надо ставить непосредственным подчинённым — а их подчинённые это вопрос уже самих руководителей ( я не имею ввиду общие вопросы, которые относятся в равной степени ко всем сотрудникам)
Но с другой стороны, даже из премии вычитать не стоит ничего.
Те же штрафы за опоздания для разработчиков, если он не работает на поддержке с жёсткими SLA — это очень и очень грустно.
Можно же и мотивировать — например, "+25% в составе премии за 5 и менее багов с важностью выше X" и т.д.
Не выполнил — не заработал.
Я согласен с принципом HR-ов, что надо добавлять, а не вычитать
Согласен, что за опоздания глупо штрафовать. Но если из-за его опоздания ктото не смог блокирующий баг пофиксить и компания потеряла деньги, то тут уж извините.
Принцип только добавления хорош, но в меру :) У меня должен быть инструмент в руках, которым я могу не просто высказать свое недовольство, но и прямо ударить по больному. Как ядерный чемоданчик :)
Когда-то давно я работал в одной аутсорсинговой компании. Каждое утро я имел наглость опаздывать на десять минут. Руководили компанией молодые ребята на пару лет старше меня, однажды они обрадовали фирму, что за опоздания отныне будет штраф сто рублей. Первое, что я сделал — при всех полез за сторублевкой и попытался всучить ее руководителю. Второе — поинтересовался, можно ли заплатить за месяц вперед две тыщи и они от меня отстанут? Больше этот вопрос не поднимался, штраф не прижился. Пикантности ситуации добавляли постоянные переработки и задержки у клиента, причем переработки могли быть как утром, так и вечером (к примеру, поезда в другую область к восьми утра при том, что рабочий день начинается с девяти, или убытие с дальней точки по окончанию рабочего дня). Начать же рабочий день с полдевятого рядом с домом они вообще считали нормой («ну, тебе же не надо ехать до работы, а хочешь, приезжай — и потом езжай к клиенту». Я хотел, да). Еще запомнился эпизод, когда компания потеряла крупного и важного клиента, по этому поводу собрали весь коллектив и руководители долго распалялись, как они нас разгонят и наймут новых. На тот момент я, к примеру, ни одной заявки с этой компании ни разу не закрывал и не очень понимал, что я тут делаю и в чем моя вина.

Обычно возникает вопрос, а что я там работал? Все очень просто: на тот момент так сложились обстоятельства, что это была стабильная работа, дающая регулярную наличность, и очень сложная жизненная ситуация. Когда проблемы разрешились, свалил оттуда, перед уходом высказав все, что думаю, в глаза руководству, без истерики, но указав конкретные пробелы в работе с клиентами и персоналом. Они, правда, обиделись, но это тоже нормально — на тот момент квалифицированных людей осталось очень мало, а для своей зарплаты я очень много заявок закрывал, не всегда соответствующих уровню квалификации.

Что порадовало: у них было явно заготовлено для меня предложение о повышении зарплаты, когда приду увольняться, прямо с готовностью предложили поднять зарплату на треть. А пока работал — поднимать мысли не было, я же и так тружусь. Но я ушел, о чем не жалею. Фирма поныне существует, даже открыла новое направление и вышла на федеральный уровень. Я же вынес оттуда опыт того, как не надо работать с подчиненными (опыт, как надо, у меня был), на следующем месте стал начальником айти-подразделения через четыре месяца и применил его сполна, реализовав большой проект. Сам подчиненных никогда не ругал, если случился косяк, вместе его разбирали. Косяки ни разу не повторялись, в целом, их было очень мало.
Сам подчиненных никогда не ругал, если случился косяк, вместе его разбирали. Косяки ни разу не повторялись, в целом, их было очень мало.

Хорошо когда так (
Справедливости ради, был человек, который категорически решил ничему не учиться, а просто просиживать штаны. Мои указания (строго в рамках обязанностей) или саботировались, или исполнялись с пятого пинка. Ситуация осложнялась тем, что он находился на удаленной площадке, и не было возможности стоять над душой. Предложил уволиться добровольно — не захотел. Видимо, был уверен, что я в силу молодости не придумаю, что с ним сделать, вероятно, раньше, в других организациях такое поведение прокатывало. Права свои он знал хорошо, время тянул профессионально. Через неделю после вынесения мной представления о предупреждении он срулил.

Брал я его на работу сам, это было мое неудачное кадровое решение (надеялся, что научится, условия для этого были, да и не шли особо на нашу работу за ту зарплату желающие табуном). Человек сделал свой выбор, пришлось с ним расстаться.
В таких случаях есть интересный вариант как зарплата: 10% оклад + 90% надбавка. Если хорошо знает свои права и сам по добру не хочет тогда пускай поживёт на 10к в месяц. Для особо упоротых самое верное средство, можно даже работой не грузить.
На условия «мы тебе будем платить от 10% до 100%, в зависимости от желания нашей левой пятки», адекватные разработчики пойдут уж в очень безнадёжной ситуации.
Ну скажем так. Платить будут то, что обещают, но именно в таком соотношении и это достаточно частая практика. В хороших НИИ или ФГУП оклад может быть меньше десятки, но при этом сама зарплата будет приближаться к сотке и переходить за неё. И такое вполне распространенная практика, особенно в госорганизациях и это вполне нормально.
Ну если разработчик одновременно хороший и адекватный, и если речь идет о городе с большим выбором работодателей, то он прекрасно понимает, что может покинуть компанию, как только она перестанет выполнять договоренности. Так что, в худшем случае, он рискует 90% от одной зп. При этом если зп получается значительно больше чем в других местах работы, то это вполне компенсирует риски.
В моем случае человек хорошо знал свои права, и не знал больше ничего. Ну как, ему казалось, что он хорошо знал свои права, как показало время, я в его правах разбирался лучше него. Тем более, там у нас был сильный отдел кадров, сильный юридический отдел, грамотное руководство — я по всем прошелся и согласовал свою позицию, препятствий мне не было.

С зарплатами крутиться было нельзя, да и не имело смысла: человек полностью отказался от самообучения и занял странную позицию, что ты меня нанял, ну и терпи теперь, а так как я ничего не могу делать и не могу учиться, то будет вот так.

Я в таких случаях считаю, что подобных людей нужно из коллектива убирать: любое нытье неизбежно сказывается на атмосфере, а человек, который ничего не делает, провоцирует других к подобному поведению. Ну и, в конце концов, плохо это, когда саботируются указания руководителя, для авторитета неправильно.
Очень понравилась статья, отправил в закладки для регулярного перечитывания…
Также присоединяюсь к просьбе
Можно еще затронуть целеполагание и ответственность (постановка задачи или делегирование задачи) в 3.0 версии
Интересно то что Вы трактуете корректирующую обратную связь исключительно как наказание. Само это слово-«наказание» выбрано крайне неудачно по моему, потому что ассоциируется с социальными институтами, построенными на насилии и эксплуатации: пенитенциарная система, детские сады, школы, спорт. Не думаю, что новые сотрудники Вашей организации обрадуются, когда узнают что у вас наказывают. Человек с достаточно высоким уровнем самооценки с настороженностью отнесется к таким наказаниям
>>> root cause-анализ… Их суть — погрузить человека в анализ своих поступков и поведения, чтобы он нашёл недоработки и косяки. По результату — предложил меры, чтобы предотвратить повторение кризиса в будущем.
=> Звучит как попытка некомпетентного руководителя, который косячит с планированием и управлением командой не приходя в сознание, переложить ответственность и работу по анализу последствий собственных ошибок на подчиненных. Т.е. выглядит жалко и непрофессионально.

>>> Что нужно делать, так это задавать неудобные вопросы. Спросите и ждите ответа. Не дайте уклониться или перевести тему. Ваша задача — добиться того, чтобы человек увидел ситуацию под правильным углом. Он попытается извернуться, начнёт придумывать отговорки или ссылаться на то, что «другие так тоже делают». Не дайте себя запутать. Поверните человека мордочкой к зеркалу и заставьте смотреть. Дополнительные техники и приёмы (голос, тембр, взгляд, мимика, жесты, позы) усилят эффект.
=> При попытке повернуть меня куда то, в мордочку получит «руководитель». Голос, тембр, мимика, жесты, позы — это все автоматически возбуждает в человеке встречную агрессивность. И даже если ты реально накосячил и был готов признать это вплоть до отработать сверхурочно, от самого факта подобного поведения руководителя по отношению к тебе немедленно вспыхнет абсолютное отрицание. Поскольку оставаться адекватным с явно неадекватным руководителем очень сложно. Чаще это после пары таких концертов заканчивается заявлением на увольнение по собственному желанию, и е@#сь оно конем. Если руководитель не может в случае ошибки/конфликта вести себя как нормальный человек — нафиг оно вообще тебе сдалось? На рынке дефицит кадров, тебя заваля вакансиями через пару минут как обновишь резюме.

>>> Ошибка — задавать вопрос и не оставлять паузу для ответа на него, а сразу переходить к чтению морали. Спросите и молчите. Если ответа нет — напомните, что вы его ждете. Не давайте себя запутать и увести в несущественные детали или излишние сущности. Отсекайте лишнее.
=> Ошибка — задавать тупые вопросы, ждать от них адекватных ответов и еще и напоминать, что вы их ждете. Ты — руководитель, он — подчиненный. Твоя задача объяснить ему как надо поступать в ситуации, научить если не умеет или заставить, если не хочет. Подход «Кто у нас плохой мальчик, а Карл?» — это подход дегенератов с IQ уходящим в такие дали, что минус бесконечность никогда там не бывала. А порой и вовсе воспринимается как насмешки/оскорбления. Здесь бизнес, а не театр драмы и комедии — скажи человеку где он накосячил и чего ты от него хочешь, а не превращай разбор полетов в что? где? когда?

>>> Наказывать нужно только наедине. На публике сотрудник может войти в роль. Это подорвёт ваш авторитет, если у вас нет навыка и внутренней силы осадить человека одной фразой. Ну и это просто неприятно. Наша с вами задача — изменить в будущем паттерн поведения сотрудника, сделать его лучше. Поэтому неприятная для обеих сторон процедура должна проходить только наедине.
=> О да, если доведенный до крайней степени раздражения сотрудник бросит заявление об увольнении и хлопнет дверь прилюдно, есть шансы что остальная команда просто встанет и повторит. Тогда не самолюбие, а сама карьера руководителя может быть завершена.

В общем резюмируя, я не согласен практически со всем, что написано в статье. Судя по всему, она описывает опыт западной цивилизации и ее корпоративной культуры. Т.е. опыт, чуть более чем бесполезный (фатально вредный) в отечественной среде.

Приведу простой пример — когда здесь, на хабре, карма падает ниже определенной отметки, у тебя пропадает панель редактора при написании комментариев (без тегов). Ты больше не можешь выделять шрифт жирным или курсивом, не можешь выделять код или цитаты, не можешь вставлять ссылки и картинки. Это — наказание за низкую карму… за то, что нашлось несколько людей, не согласных с твоим мнением. Или за то, что ты где-то выразил, что не согласен с мнением, которое описано в статье, вот как здесь.

Воспримет ли пользователь наказание за то, что мыслит иначе чем все? Он что, перестанет от этого писать комментарии? Придумать это мог только клинический дегенерат с нарушениями психики, интеллектом астрального боброзяблика, воспитанный вот как раз в духе описанной в статье западной корпоративной культуры, с ее идиотскими перегибами, гиперболами и тупостью.

P.S: А вы, коллеги, я уверен, читая мой комментарий, наслаждаетесь последствиями этого «наказания», вместо того чтобы читать приятно оформленный текст. Чтож, прочувствуйте всю силу и мощь подобных «наказаний» +))

P.P.S: И берегите глаза коллеги!) Делайте гимнастику для глаз!) Они нас кормят!)
По поводу вывода с root-cause анализом — не соглашусь.
Руководитель далеко не всегда эксперт в той области, в которой его подчинённый разбирается детально и если есть косяк, то нужно разбирать его с теми самыми людьми, которые лучше всего в теме. Нередко, косяк допускается тем самым человеком:)

Если 2 совершенно разных подхода к решению проблем:
Негативный: давайте найдём виновного и будем его пилить.
Позитивный: ребята, у нас косяк, это свершившийся факт. А теперь давайте сядем, выясним причины и сделаем так, чтобы в будущем никогда-никогда такого не повторилось.

Вы, видимо, рассматриваете анализ причин при «негативном» подходе. Если же на ситуацию смотреть с «позитивной» стороны, то это чуть ли не самый эффективный способ недопущения проблем в будущем. Люди уже сами видят последствия, сами понимают, какие шаги привели к таким последствиям — осталось только продумать процедуру, которая позволит избежать их в будущем.
Спросите и ждите ответа. Не дайте уклониться или перевести тему.
Спросите и молчите. Если ответа нет — напомните, что вы его ждете.
Это паттерны поведения очень плохого учителя или воспитателя детского сада. Очень плохого. Некомпетентного, и к тому же получающего удовольствие от проявления власти: особенно в этом стиле любят задавать сугубо риторические вопросы. Представить себе, как вот эти вот напоминания про ожидание ответа могут использоваться в позитивном ключе, мне не хватает фантазии.
Подтверждаю реакцию: максимум два таких эпизода — и лично я заявление на стол.
Извините, а как правильно? Вот у нас есть человек, который накосячил, но не хочет это признавать. Мы должны показать ему его ошибку и добиться, чтобы эта ошибка у него (а лучше — в коллективе) не появилась вновь. Какие могут быть причины у такого поведения:
1. Человек не включил мозг при решении задачи, написав работающую реализацию в соответствие с буквой задания.
— Не использовал имеющийся инструмент, написав портянку-велосипед
— Наоборот, притащил стороннюю огромную библиотеку ради пары функций, таким образом усложнив развертывание и поддержку
— Написал грязный код, который ломает или может поломать место вне непосредственной задачи
— Написал переусложненный код, который никто, кроме него не сможет понять. Например, на перле с кучей спецсимволов или регексп на экран без единого комментария
2. Не следовал правилам команды. Например, нарушил code style или внутренние соглашения об иерархии классов, вызовах функции или документривания
3. Пробил сроки
4. Сломал отлаженный процесс работы команды или согласования изменений

Человек в этой ситуации может заявить, в зависимости от текущего состояния и ЧСВ, от «А разве это важно?» до «Так лучше. Это настолько очевидно, что я не вижу смысла это обсуждать», и от «Фигасе я понаписал!» до «Отвали, не до тебя». Руководителю и, возможно, большинству команды, косяк очевиден, а человеку, пока не укажешь (или даже после этого) ошибка не видна. Как поступить в этой ситуации руководителю?
Эти ситуации характеризуют руководителя, а не сотрудника. У вас митапы есть? Есть. План проекта есть? Есть. Проектирование осуществили? Осуществили. В YouTrack/Jira/Redmine декомпозированный на таски проект со сроками забили? Забили. Разделение и взаимодополнение ролей сотрудников прописали? Прописали. Канбан-доски висят? Висят. В бюджет и сроки риски заложили? Заложили. Правила команды в WIKI описаны? описаны. Сотрудники подписались под тем, что они их прочитали и обязуются выполнять? Подписались. Мидлы контролируют джунов, а сеньоры мидлов, а тимлиды сеньоров, а тимлидов архитектор и рук, а их топ-менеджмент? Контролируют.

Ну так как один сотрудник может каким-то действием разрушить настолько прочно выстроенную систему? Вы издеваетесь? Если бы вещи происходили так, как вы описали, бизнес был бы невозможен в принципе, как концепция.

Из моего опыта, если рабочий процесс отлажен, вне зависимости от действий отдельных сотрудников, признаки назревающего п#$&@ца видно еще на берегу, задолго до BIG BADABOOM. Если «Вася» — джун, «Васе» нужно давать поток небольших, мелких, хорошо декомпозированных задач. Чтобы «Вася» набивал руку, привыкал к культуре кода держа на втором мониторе открытую WIKI с примерами. И чтобы старшие наставники обучали «Васю», а «Васе» нужно доходчиво донести, что когда он сдаст экзамен на мидла, это + к з/п. А не лишать его через месяц премии, за то что «Вася» не справился с проектированием трех слоев абстракций метабазы, потому что он видит Postgres второй раз в жизни, IDEF? ARIS? Не, не слышал.

P.S: «Как правильно» — напишу чуть позже. Я из-за кармы пишу раз в час.
Тут я вижу 4 варианта, в 3, имхо, возможен сценарий наказания, но можно обойтись без увольнения:
1. Коллектив и продукт молодые, всё перечисленно только формируется, регламенты пишутся, методология разработки внедряется. Или новый человек в состоявшемся коллективе всё никак не может перестроиться.
2. Сотрудник ведёт себя (изредка) по-скотски: нарушает обещания и регламенты, мешает сотрудникам на бытовом уровне: опаздывает на совместные мероприятия, громко слушает музыку, грузит коллег в курилке проблемами разработки своего компонента, отвлекает разговорами коллег, задалбывает вопросами сеньора
3. Нарушенная или формальная обратная связь. Да, обычно это некомпентность руководства, административного или технического, и тут разраба наказывать по сути не за что: ошибка в архитектуре, декомпозиции, распределении или сроках. В итоге человек «не тянет» и пытается сделать хоть как-то, чтоб работало
4. Избыточный и/или неоднозначный регламент. Регламент всегда или недостаточный, когда есть место натупить, или избыточный, где не вздохнуть и тольком не упомнить. Тут зависит от кадров.
Gryphon88, все 4 перечисленных вами сценария можно рассматривать и интерпретировать с разных позиций. А часто перечисленные вами варианты присутствуют одновременно. Но вернемся к тому, что мы выше обозначили «как правильно».

Итак, первое, что я считаю правильным — это руководить, а не доводить до наказаний и не ждать, когда кто-то накосячит. У нас уже был в истории дебил, который считал что «Солдаты сами знают как воевать». Забыли? Ну так я напомню — тогда все закончилось сожжением Москвы войсками Наполеона. А солдатам потом пришлось подвигами расплачиваться за некомпетентность руководителя… ничего не напоминает?

Косячат люди или нет — очень сложно оценить. Выполняют они приказы или нет — намного проще. Научитесь командовать и вам некого будет винить за проколы, кроме себя. Армейская система в этом отношении идеальна. Приказ считается выполненным не тогда, когда он выполнен, а когда «Вася» доложил и отчитался, что он выполнен. Управляйте людьми и они будут отчитываться перед вами за решенные задачи, а не за идиотскую самодеятельность. Ваши люди должны знать что им делать, они ждут этого от вас.

В то же время, надо быть уверенным в людях, которыми командуешь. Правильная тема здесь — это институт наставничества, когда за «Васей» закрепляется конкретный мидл/сеньор/лид который обучает его и следит за его работой и ростом. И работают они вместе, пока «Вася» учится. Это можно отлично мотивировать как + к з/п за «Васю» этому лиду, если они вдвое за определенный срок начинают выдавать двойную эффективность работы. Если же «Вася» косячит и не хочет учиться, «Васю» всегда можно просто уволить на основании невыполненных задач. Ведь в лиде то своем вы уверены, раз уж он у вас лид. Что? У лида нет педагогического таланта? Отайте «Васю» другому лиду или мидлу, наймите тренинг-менеджера, в чем проблема?

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

1) Джун «Вася» опоздал на работу 2 раза в году — из-за своих свадьбы и рождения первенца. Это происходит в жизни людей всего несколько раз, по пальцам пересчитать (за редким исключением). Но формально по описанным в статье предложениям, «Вася» все-равно должен быть наказан.
2) Джун «Вася» начал бухать и опаздывает на работу систематически, трезвея по мере чтения тасков. Нужно ли наказать «Васю»? Я считаю, что «Васе» в такой ситуации нужно не наказание, а корпоративный психолог. Потому что вероятно, «Вася» уже не воспринимает реальность.
3) Джун «Вася» притащил в проект огромную либу ради одной функции. А почему он не сказал об этих своих планах на планерке или митапе? «Вася» же в курсе порядка действий в такой ситуации? А куда смотрел мидл, отвечающий за Васю? И как коммит «Васи» вообще прошел через Мидла, не вызвав у последнего вопросов? А «Васе» вообще рассказали про принятый технологический стек? Ну когда он устраивался на работу-то должны же были? У «Васи» в тасках вообще инструкции или полет мысли по сферическому дереву в варпе? Тимлид то сам вообще читает таски, которые мидлы ставят «Васе»? Ведь он же знает что «Вася» джун и пока еще может косячить просто по незнанию.

И чтобы быть точным в выражениях — я никого не призываю заставлять своих сотрудников делать строго то что велено. Я призываю к тому, что сотрудники всегда должны точно знать, что от них требуется, когда это требуется и почему это важно. 10 отдельных тасков на создание модуля намного проще проконтролировать чем «Вася! Нет времени объяснять! Нам нужен модуль вчера!»
Откуда столько злобы и ненависти. Смею предположить вас частенько увольняют. А если это было не один раз может стоит сесть и подумать, вдруг проблема не внешняя.
malvina8, а я расскажу откуда) Меня еще ни разу не увольняли, я ухожу в другую кампанию если там есть карьерный/зарплатный/скилловый рост, которого я не могу получить там, где работаю. Я никогда не сбегаю от трудностей и не работаю на отъе&$сь.

И в 90% случаев, моя работа на новом месте начинается с того, чтобы разгрести бардак, который породили руководившие до меня му#@&и. Я написал все выше не столько как рядовой сотрудник, сколько с точки зрения руководителя из младшего руководства, с позиции тимлида/рук. отдела.

Я получал в наследство команды, которые предлагалось разогнать и собрать заново, в комплекте с дефицитом бюджета и сорванными сроками. И в первый же месяц источник проблем обнаруживается ровно один и тот же.

И это не ненависть, это раздражение. Хочешь руководить людьми — не относись к ним как к вещам. Они такие же люди, у них те же слабости и они так же хотят кушать. Хотя, последнее время я стал хладнокровнее, то ли привык, то ли неравный бой — моя стихия))
Заставить отрабатывать в нерабочее время — нельзя (да-да-да, хорош овертаймить!)


У нас была очень вежливая и харизматичная начальница, ей отказывать в плане переработок как-то даже и не хотелось, наоборот, хотелось её порадовать. А если ну не мог выйти в выходной, то подробно объяснял причину и подбадривал, только чтобы она не расстраивалась. В результате много кто перерабатывал. К тому же, у нас и приплачивали за это в соответствии с ТК (за выходные и за ночные часы положен двойной оклад).

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

Договорились не коммитить в транк или не деплоить в пятницу вечером на продакшн после третьего литра пива? Получай в дыню :)
Наказывать же нужно за ПРОСТУПОК.

Какой, извините, «проступок» на работе? Мы в детском саду что ли? Или кто-то закон нарушил?

не деплоить в пятницу вечером на продакшн

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

Извинил. Тот самый проступок, например, когда человек пообещал и не сделал (и не предупредил что не сделает). Например.

>> По хорошему инфраструктура должна
По хорошему — должна. По хорошему договоренности в конечном итоге должны быть спущены до уровня IT-регламентов, запрограммированные и автоматизированы, во избежание. К сожалению, не все-то можно так просто автоматизировать. И уж точно не у всех оно автоматизированно.

А по реальному — если с человеком договорились, он подтвердил что «да, все разумно, так и будет», а потом раз — и нету — это повод поговорить с ним о добре и зле.
Какой, извините, «проступок» на работе? Мы в детском саду что ли? Или кто-то закон нарушил?

Пришёл на работу после обеда без веской причины… Пол-дня шпилил в танки… Забил на таск… это так, на вскидку.
Если всё так плохо, то это уже вопрос в профпригодности ( читать как нарушение должностной инструкции) и разговора с руководителем совместно с HR и, как следствие — повод для увольнения
Не всегда. Это может быть отличный специалист, но со своими «творческими» тараканами. Например, «избыточный перфекционизм», когда программер срывает все сроки в вылизывании продукта до недостижимого идеала. Или пример из моей жизни — вполне годный инженер-разработчик, но «сова» настолько, что на работу приходил к часу дня. Да, он сидел на работе часов до 8-9 вечера, но взаимодействие с остальной командой было на соответственно низком уровне.

Это дискриминация сов жаворонками!

Если человека наказывать за перфекционизм — ничего хорошего из этого не выйдет. Даже не так, «если человека наказывать — ничего хорошего из этого не выйдет». По поводу «совы» — с командой выходит часов 5 как минимум, этого мало? И опять же, вы предлагаете наказывать человека за его режим дня? Если он «годный разработчик», значит справляется с работой (иначе к чему его называть годным), а если справляется с работой, то в чем проблема?
Если человека наказывать за перфекционизм — ничего хорошего из этого не выйдет.

Сам по себе перфекционизм — штука хорошая, но фактически лучше выпустить и начать зарабатывать на продукте сейчас, пусть он и не идеален, чем запоздало выйти на уже занятый рынок с очень хорошим продуктом, или не выйти вообще, т.к. идеала не существует.

По поводу «совы» — с командой выходит часов 5 как минимум, этого мало?

5 минус 1 час обеда (да-да, война войной, а обед обязателен). Минус кофе-брейки, минус перекуры. Стоит заметить, что команда состоит не совсем из программистов. Это и электронщики, макетчик, конструктор, технический писатель. Т.е. итоговый продукт является результатом работы всех сотрудников, а когда один работает в качестве члена группы меньше половины рабочего дня это сказывается на производительности всего отдела.
Программисту нужно постоянно общаться со всеми этими людьми? Если да, то почему он программист вообще, если занимается непонятно чем, если нет, то почему нельзя назначить митинги (которые могут выпасть и на утро, да).
Программисту нужно постоянно общаться со всеми этими людьми?

Где я сказал, что он программист? Я говорил: «Инженер-разработчик» ©. Схемотехника + ПО нижнего уровня. Соответственно, итоговый продукт представляет собой систему железо + ПО нижнего уровня + ПО верхнего уровня + полный комплект КД и ПД.
Не совсем понял из статьи идею с наказанием Пети. Петю наказали за то что он нарушил регламент? Т.е. регламент важнее, чем решение проблемы?
В строго регламентированных формальных сообществах именно так, как это ни печально.
Т. е. идея статьи что так и надо делать? А как тогда должен был поступить Петя (не увидел этого в статье). Петя должен быть наказан, но как он должен поступать в будущем?
Нет, одна из идей статьи в том, что не надо увлекаться регламентацией и что у неё тоже есть тёмные стороны
Ну Петя сам себе злобное буратино, так как должен был в первую очередь поговорить с тем кто поставил задачу о сложившейся ситуации. А тот кто ставил задачу уже должен был принять меры к Катерине или найти другое решение (вообще это хуже так как развращает Катю >_< ).
Проблема зачастую в том, что есть «боязнь спросить». Лучше в таких ситуациях потратить минут 10 на разъяснения подойдя к старшему и просто сказав: не понял, не знаю и т. д. Это намного лучше чем наколбасить килограмм говнокода или «прикинув по луне» написать алгоритм, а потом закономерно получить по шее.
Хотя и тут есть один нюанс… Если человек будет постоянно «недопонимать» сразу надо решать, что с ним делать. Иначе это выльется в ненависть.
Ну Петя сам себе злобное буратино, так как должен был в первую очередь поговорить с тем кто поставил задачу о сложившейся ситуации

Перевожу на русский :) Пожаловаться менеджеру на Катю? И что дальше? Наказание Кати? И как бы потом после этого относились в команде к новичку Пете?
Или второй вариант Катю не наказали?
Это называется «деликатность». А почему Кате должно всё сойти с рук? Она получается увиливает от работы. И с каких пор новичок должен отвечать за чужие косяки? В данной ситуации это вполне нормально, дальнейшее зависит от менеджера, если он что называется «вздрючит» Катю по полной за мелочность проступка тогда имеет место несоответствие проступка наказанию и Катя с коллективом конечно имеют право обидеться и на менеджера и даже на Петю (хотя это уже не верно по отношении к Пети). Если подойдёт к наказанию более верно, тогда Катя должна понять, что она не права и ни какой обиды не должно быть, и уж тем более от коллектива. А если коллектив обижается на такое и защищает Катю, то тут пардон шалман какой то и его надо разгонять, так как коллектив получается поощряет невыполнение своей работы. На кой тогда нужен такой коллектив и как он вообще до сих пор существует?
Если с Катей были четкие договоренности что она должна помогать новичкам и это входит в ее обязанности, то я с вами согласен. В статье я кстати этого не увидел. Но даже допустим если договоренности такие были.
И она мягко посылает Петю уйти прочь, ибо ей некогда.
Формально она не отказала Пете. Она сказала что ей некогда. А дальше идет притягивание за уши
А у Кати в голове гуляет весенний ветер и полное «не хочу думать — хочу платьице»
— это всего лишь домыслы.
В конфликтной ситуации это будет выглядеть примерно так… Рук-ль: Почему не помогла Пете? Катя: Была занята срочной задачей для важного клиента, которую вы же мне и поставили.
Ну Вы же сами видите, что тут множественная трактовка ситуация из-за незнания всех исходных и конечных. Так что тут можно устроить полемику на миллион ситуаций, а что если так или иначе. Не будет же автор описывать абстрактный пример, как ТЗ на телескоп Хабл.
В этом абстрактном примере Петя виноват только в одном случае: если руководитель зарание сказал, по всем спорным ситуациям обращаться к нему. Если не было это явно донесено до Пети — он действавал в рамках дырки в регламенте. И виноват в этом сугубо руководитель.
Я извиняюсь, но почему именно «пожаловаться»?!
Когда я учился на «Менеджменте» в США, у нас была тема: Мотивация сотрудников. Полчаса нам рассказывали про виды пряников. Я спросил — а что насчёт кнута? Мне ответили что это в прошлом, доказало неэффективность и больше не используется.
Вот и весь сказ.
Логика пряников работает хорошо и она заключается в следующем:
  • работник сделал работу хорошо — $10
  • работник сделал работу быстро и хорошо — $20
  • работник побил месячный рекорд скорости выполнения задачи не уронив планку качества — $30 + выходной


но!
  • дать просраться всему отделу, что бы не расп*здяйничали — бесплатно и так же эффективно!


Вспомнил анекдот в тему:
— Вы используете метод кнута и пряника?
— Да, но больше кнута.
— Почему?
— Пряником бить неудобно.
дать просраться всему отделу, что бы не расп*здяйничали — бесплатно и так же эффективно!
И в чем по вашему это будет выражаться?
>дать просраться всему отделу, что бы не расп*здяйничали — бесплатно и так же эффективно!

Эффективность поиска новой работы увеличилась вдвое! Соблюдением сроков и качеством работы больше никто не заморачивается! Бесплатно и эффективно!
Еще один вопрос к автору по ситуации с Петей.
И, так как он только учится, менеджер просит, чтобы Петя позвал на помощь опытного программиста Катю

Какие конкретно в данном случае договоренности нарушил Петя?
Для компаний, практикующих регулярный менеджмент, Пётр нарушил еще одно иравило: «Столкнулся с трудностью, препятствующей выполнению поручения с установленным качеством и к нужному моменту — доложи руководителю.»
Ок Понял А как определить тогда грань когда сотрудник сам должен решать трудность а когда обращаться к руководителю? Так ведь можно по каждой мелочи дергать руководителя?
Если трудности превышают выделенные полномочия сотрудника для достижения необходимого результата.
И только в том случае, если до Пети это донесли зарание.

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

Вот представьте… ходит «Петя» такой довольный собой, результатом своей деятельности (причем, действительно же — есть чем). Его уже похвалили… сказали: «молодец»… денег — вполне вероятно — опять же дали за «подвиг». И тут его вызывает к себе «Начальство» и спрашивает, так серьезно…

«Петя», ты же думал над тем, что делать, если у тебя не получится «самому»? Да?

И смотрит так пристально :-)
Представил :) А какой результат от таких вопросов? И в чем наказание? Ну допустим ответ Пети если бы не получилось, то обратился бы к Кате
> А какой результат от таких вопросов?
?! Как минимум, вы, как руководитель, будете иметь представление «о мотивах». А «Петя» узнает ваше мнение о.

>И в чем наказание?
Естественно, в стрессе. В чем же еще?!

>Ну допустим ответ Пети если бы не получилось, то обратился бы к Кате
:-) «Петя», извини, что перебиваю… а _когда_ бы ты понял, что у тебя «не получилось»?

P.S. Вы, похоже, все же не понимаете, за что именно «наказывают» «Петю» :-) Попробуйте все же посмотреть на ситуацию, именно как руководитель…
Уже была подобная статья на хабре, там тоже упоминался битрикс. Совпадение?

Наказать можно только неквалифицированного специалиста, так как любой другой отдаст весло и пойдёт грести на другую галеру, рабов уже давно не приковывают к веслу. Другое дело если ты работаешь на государственной пилораме вроде битрикс проектов, где скот нужен лишь для массовости, там да, любой погонщик может возомнить себя королём, т.к. ценность кадров небольшая.

Наказание может быть только одно — увольнение, любое другое значит, что несмотря на косяки он все же ценен для команды.
От гифок браузер завис, имейте совесть, я открывал Хабр а открыл Пикабу…
Лучше вы комп помощнее имейте. Мы эти гифки пол дня рисовали :)
Напишите книгу!
Менее адаптированные под задачи ИТ, в отличие этой статьи, возьму смелость рекомендовать книги Владимира Тарасова и (в том числе аудиокниги) Александра Фридмана.
Весьма развернуто и детализированно, с примерами и пояснениями.

Извините не удержался…
Есть ещё один тип (очень редкий) людей, помимо гиперответственных.
Часто ими становятся гиперответственные люди, битые жизнью и пробретшие её мудрость избежав разочарования, вместе с умением не пилить себя а разумно критиковать — в соответствии с тяжестью своей вины. Если практикующий хансей человек "ставит себя в угол", то этот человек — не ставит, а начинает планомерно работать над собой, так как понимает — упущенного не вернешь, но нужно исправить последствия и принять меры, чтобы не повторить неверных действий и он не теряет времени зря на стояние в углу и печаль а работает.
Картинка для такого человека будет такая — https://my.mail.ru/community/cool_narnia/photo/51/54.html
А руководитель его — весьма счастливый человек.

Очень интересное наблюдение, как после этого не начать верить в гороскопы?

В чеклисте пункта 12 нет…
интересно одно — тот кто это писал, сам код писал сложнее сайтов на битриксе? или это для каких то специфичных не ит компаний руководство?
Вся эта тема чисто о российских реалиях. Будучи в России у меня тоже были порой проблемы с мотивацией.
Но в Штатах все решается просто — очень хорошей зарплатой. Тогда сразу становишься суперответственным и опережающим все графики. А все потому, что ЗАРПЛАТА и ПРЕМИИ. Это лечит любую лень.
А иначе лишишься и хороших денег и репутации. Так что в Штатах все подобного рода темы — никому не интересный мусор. Некогда прокрастинировать и дурака валять на рабочем месте.
Поосторожнее с такими словами!) Я в другой теме ранее выразил, что бабло — это главное. Меня заминусовали фхлам))
Не поленился найти, что вы такое написали. Там вы предлагаете больше работать за те же деньги (не увеличивается часовая ставка), а тут предлагают больше платить в час. Очевидно, какой коммент получит положительный эмоциональный отклик, а какой — отрицательный.
>что ЗАРПЛАТА и ПРЕМИИ. Это лечит любую лень.
Для меня это мотивация только если на жизнь не хватает ЗП без премии. Не все мотивируются деньгами.
Мне всегда нравился пример с мотивацией Open Source, но не всегда найдется работа по душе.

Да ладно, тут все очень медленно. В смысле какой смысл делать работу за 10 часов когда ее же можно сделать за 40? Если не верите — можете вызвать мастера ремонта кондиционеров, как пример.

Понятно что в гуглах/эплах/майкрософтах может и за 150к в год мотивации хватает, но про все штаты не надо.
Длинная статья, а вся суть вопроса, в том, что наказания эффективны когда:
1) за проступком следует наказание
2) виновный осознал и признал свой поступок
3) накозание соразмерно проступку по мнению виновного и остального коллектива.
Если эти пункты не соблюдаются, то наказание преврашается в мотивирование не диверсию.
Одного так и не понятно — а как именно наказывать? А то штрафовать — плохо, читать морали — плохо, грозить увольнением — плохо. А что хорошо?
Платить сильно больше рынка И грозить увольнением?
Это больше похоже на совет «как максимально быстро избавиться от команды программистов и при этом профукать бюджет» :D
То-то я замечаю как толпами бегут разработчики из мест где хорошо платят. :)

Насчет бюджета — ну в том же США зарплаты побольше наших, но разработчики есть. ЗП разработчиков — это обычно далеко не первый пункт в топе расходов проекта.

Если сотруднику хорошо платят, нормально относятся, не парят мозг ненужными ему корпоративными игрищами, дают нормальные задачи и т.д., то он будет держаться за такое место работы. Как результат будет стремится хорошо работать.

Если же компания предпочитает быть «средней по рынку», то нет ничего удивительно, что её сотрудники не будут ценить такое место работы, ведь на рынке полно таких же. А если человек не ценит свое место работы, то и 100% отдачи от него не дождаться.
Более бесполезного способа, чем грозить увольнением сложно даже придумать в применении к хорошим программистам.
Я еще ни разу не видел, чтобы такое работало, даже если у программиста ЗП в данной компании на 20-30% выше рынка.
Мой вопрос был именно про то, как наказывать за разные косяки. Отдача ниже 100% это не косяк и вообще другая тема.
Увольнение это крайняя мера, и очень глупо грозить им при каждом случае. Точно так же, как с пистолетом — лучше не вытаскивать, если не решился стрелять.
Более бесполезного способа, чем грозить увольнением сложно даже придумать в применении к хорошим программистам.
Зачем наказывать хорошего программиста?

Тут простая логика — если сотрудник иногда косячит по мелочи, то какой вообще смысл его наказывать? Косячат все, без исключений.

Увольнение это крайняя мера, и очень глупо грозить им при каждом случае. Точно так же, как с пистолетом — лучше не вытаскивать, если не решился стрелять.
Я и не говорил обратного :)
Если вы грозите сотруднику увольнением, значит вы готовы его уволить и никак иначе. Сотрудник, который хочет работать у вас в компании не будет доводить до такой ситуации.

Если сотрудник не устраивает работодателя, то его увольняют. Или предлагают измениться. И в этом нет ничего плохого.
Да, такая логика не работает со звездными сотрудниками, но прекрасно работает с рядовыми, просто потому что они заменяемые. И большинство разработчиков и позиций как раз рядовые. Просто зачастую компания хочет и платить человеку по минималке и чтобы к ним очередь нормальных разработчиков стояла. Но так не бывает.
В целом, понятно, что вы и понятия не имеете, как грамотно дисциплинарно воздействовать на сотрудника, чтобы это было для него не обидой, а стимулом исправиться. У вас почему-то только два варианта — либо человек идеален и не косячит (или косячит по незначительным мелочам), либо человек сразу списывается в утиль и ему как кирпич на голову сваливается угроза об увольнении. Но ведь есть еще куча промежуточных вариантов. Обратимся к реальной жизни — если человек украл пачку сигарет, это не значит, что его нужно сразу сажать в тюрьму на 10 лет, но и не значит, что нужно говорить «бери на здоровье» и отпускать просто так.
Да, есть хорошие программисты, но с отвратительным характером\привычками, которые иногда надо немного корректировать дисциплинарно (но это не значит, что их нужно увольнять). А сидеть и пускать все на самотек не представляется достойным вариантом для человека, который считает себя хорошим руководителем.
У вас почему-то только два варианта — либо человек идеален и не косячит (или косячит по незначительным мелочам), либо человек сразу списывается в утиль и ему как кирпич на голову сваливается угроза об увольнении.
Ну не надо мне приписывает чужие идеи. Я даже прямым текстом писал, что некосячащих людей не бывает.

Я похоже сильно сложно пошел выражать свою мысль. В результате чего получился какой-то спор ниочем и полный оффтоп.
Суть моих мыслей такова: Метод наказания работает только в случае если наказующий имеет значительную власть над наказуемым. В отношениях работодатель-работник такое возможно разве что в ситуации, когда работник финаносово зависим от работодателя (например на работнике висят кредиты/ипотеки, и выплатить их он способен работая только на текущем месте рабты). Если же вы попытаетесь наказать работника, над которым ваша власть незначительна, то он вас пошлет и просто свалит в другую контору (и будет прав).

Задумайтесь, почему вы решили, что имеете право наказывать взрослого, постороннего вам человека? И что вас на самом деле интересует — наказть сотрудника или как-то его изменить?

Обратимся к реальной жизни — если человек украл пачку сигарет, это не значит, что его нужно сразу сажать в тюрьму на 10 лет, но и не значит, что нужно говорить «бери на здоровье» и отпускать просто так.
Вот кстати действительно отличный пример. В реальной жизни тюрьмы могут выступать в двух качествах. Как исправительное учереждение и как наказательное (более удачного слова придумать не смог). Практика показывает, что если тюрьма — это наказание, то из неё выходят преступники (что логично, приходят туда преступники и предпосылок для исправления нет). Поэтому в таком качестве она работает только в случае пожизненных сроков, когда преступник уже не вовращается в социум. В нашей аналогии пожизненный срок — это и есть увольнение.

Другими словами если человек не исправляется, то его наказывают — увольняют. Любые другие наказания порождают появление сотрудника, который в лучшем случае просто от вас уйдет, в худщем будет действовать по принципу «косячить можно, а вот попадаться — нет».

Да, есть хорошие программисты, но с отвратительным характером\привычками, которые иногда надо немного корректировать дисциплинарно
Вот представьте, что он не ваш сотрудник, а, например, сосед. Вы бы стали наказывать соседа за его характер/привычки?
Метод наказания работает только в случае если наказующий имеет значительную власть над наказуемым.

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

Задумайтесь, почему вы решили, что имеете право наказывать взрослого, постороннего вам человека? И что вас на самом деле интересует — наказть сотрудника или как-то его изменить?

Если вы являетесь менеджером над командой программистов, то они вам совсем не посторонние люди — от них зависит в том числе и ваша будущая судьба в компании. Что бы мне было интересно прочитать в данной статье, так это примеры наказаний (ну, или дисциплинарных мер и воздействий — называть можно как угодно), которые, как я писал выше, мотивируют сотрудника быть лучше, стараться как можно меньше повторять свои косяки. Не банальнейших угроз увольнением или выговоров на ковре, а мер, применение которых начинается в правильного выстраивания культуры в компании, мер, которые могут выводить человека из зоны комфорта, но при этом вызывать мысли не сбежать в другую компанию, а стать лучше и больше не косячить. Вот, про что, действительно, было бы интересно почитать.
В качестве примера: если в футбольном матче вы получите предупреждение за фол, вы ведь будете стараться играть аккуратнее в будущем, а не посчитаете это демотиватором и причиной вообще уйти из игры.

Вот представьте, что он не ваш сотрудник, а, например, сосед. Вы бы стали наказывать соседа за его характер/привычки?

Думаю, что каждый здравомыслящий человек что-то предпринял, если бы сосед своими действиями напрямую стал ухудшать качество его жизни.
Я не знаю, какие вы имеете в виду наказания, для которых нужно тотальное превосходство и власть, но я имею в виду некие меры, которые будут мотивировать сотрудника не повторять своих косяков.
По вашему получается, что практически любое обучение — это наказание. А я имею ввиду что-то в духе определения из вики — применение каких-либо, правовых или неправовых, неприятных или нежелательных мер в отношении человека, животного или их групп в ответ на неповиновение или на неугодное или морально неправильное поведение.

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

Если вы являетесь менеджером над командой программистов, то они вам совсем не посторонние люди — от них зависит в том числе и ваша будущая судьба в компании.
Как это связано с вашим правом их наказывать? Еще ваша судьба от в компании от вашего начальника зависит, его тоже наказывать будете? То что вы от чего-то там зависите — это ваши личные проблемы. Это не дает вам никаких прав.

Не банальнейших угроз увольнением или выговоров на ковре, а мер, применение которых начинается в правильного выстраивания культуры в компании, мер, которые могут выводить человека из зоны комфорта, но при этом вызывать мысли не сбежать в другую компанию, а стать лучше и больше не косячить.
А зачем человека выводить из зоны комфорта? Вы определитесь уже чего вам надо — сделать человеку неприятно или чтобы человек стал лучше и больше не косячил.
Как это связано с вашим правом их наказывать? Еще ваша судьба от в компании от вашего начальника зависит, его тоже наказывать будете? То что вы от чего-то там зависите — это ваши личные проблемы. Это не дает вам никаких прав.

Безусловно, можно вот так вот философствовать про права и обязанности и про сущность бытия. А можно просто взять и построить хорошую и справедливую систему кнута и пряника, имея те полномочия, которые имеет управленец по отношению к команде. Я еще раз повторю, что под наказанием я не имею в виду наказания уровня средневековой инквизиции. Что я имею в виду, я писал выше.

А зачем человека выводить из зоны комфорта? Вы определитесь уже чего вам надо — сделать человеку неприятно или чтобы человек стал лучше и больше не косячил.

Да потому что такова природа человека. Пока он находится в зоне комфорта и нет никаких рисков выхода из нее, мало что поменяется. Сама история развития человечества это подтверждает.

Мне, честно говоря, поднадоела эта дискуссия. Я просто высказал, о чем бы мне было интересно прочитать в статье и чего здесь не хватает по моему мнению. Не стоит меня убеждать, что есть только пряник, а кнут не имеет смысла (в таком случае и вся эта статья не имеет смысла). Я работал в компаниях, где было довольно приемлемо организовано и то, и другое. Главное тут, чтобы каждый сотрудник заранее знал, за какие косяки и что именно может быть. А не так, чтобы это сваливалось как снег на голову.
Методы унижения персонала (как обязательная часть регулярного менеджмента), так любимые господином Фридманом, весьма хороши для управления низкоквалифицированными служащими массовых профессий. Винтиками. Например поварами в mc donalds, специалистами 1й линии какого н-ть сотового оператора, продавцами селедки и т.д. В общем теми, кого много, кого легко заменить, от кого многое не ожидается, да и не требуется. Продает себе селедку и продает.
В компаниях, нацеленных на достижение максимальной эффективности мотивируют через вовлеченность и позитивную корпоративную Культуру (именно Культуру, а не «культуру крысятничества»). В такие компании чаще приходят и задерживаются классные специалисты, которые (при наличии не менее классного менеджмента) и делают успех компании.
Хм, всё хорошо, вот только обидеть человека нельзя. Обидеться — можно. Принципиальная разница.
Зато человека можно оскорблять и унижать.
Это сколько угодно. :) Хотя… Это скорее из сферы духовного развития.
Просветлённого можно сколько угодно оскорблять и унижать. А он не оскорбится и не унизится.
Вот только, где-ж столько просветлённых взять :))))
Вы про это?

Проходил как-то Будда со своими многочисленными учениками одной деревней.
Собралось несколько человек — его противников — и принялись они горячо и зло оскорблять Будду. Он очень спокойно молча слушал. И из-за этого спокойствия им стало как-то не по себе. Возникло неловкое чувство: они оскорбляют человека, а он слушает их ругательства, как музыку.
Тут что-то не так.
Один из них обратился к Будде:
— В чем дело? Ты что, не понимаешь, что мы про тебя говорим?
— Именно при моем понимании возможно такое глубокое молчание, — ответил им Будда. — Приди вы ко мне десять лет назад, и я бы бросился на вас.
Тогда у меня не было понимания, теперь же я понимаю. И из-за вашей глупости не наказываю себя. Ваше дело — решить, оскорблять меня или нет, но принимать ваши оскорбления или нет — в этом-то и состоит моя свобода. Вы не можете насильно навязать мне оскорбления. Я от них просто отказываюсь: они того не стоят. А сейчас мои ученики дадут вам люлей.
>>Дао Тойоты
Я бы не стал у поминать Тойоту применительно к разработке софта, в январе 2010 года акции Тойоты упали на 15% и Тойота выплатила 2.47 миллиарда $ на территории США из-за говнокода, из отчета НАСА «Toyota did not follow best practices for real time life critical software» (ссылка). Не соблюдался стандарт разработки на С, не всегда соблюдались правила разработки принятые внутри Тойоты, для части кода не возможно написать юнит тесты в принципе, спагетти код, 11 тысяч глобальных переменных (ссылка)
Но машины не плохи ведь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории