Comments 66
UFO just landed and posted this here
Винтик заело — меняем всю машину? Или: у сотрудника горе — увольняем нафиг — потому что он не хочет работать, когда его личный мир рушится.
ОКЭЙ, сэр.
Ну тогда нужно применить это же самое правил на самих, менеджеров высшего звена:
Почему менеджеры высшего звена не адаптируются к своему стратегическому ресурсу (что не приводит к повышению эффективности работы этого самого стратегического ресурса — людей) для повышения эффективности его работы?
Схлоапываем все 4 пункта, по аналогии — вывод: не хотят!
Батенька, вы не в нефтянке менеджером случайно работаете, чтобы так транжирить ресурсы?
ОКЭЙ, сэр.
Ну тогда нужно применить это же самое правил на самих, менеджеров высшего звена:
Почему менеджеры высшего звена не адаптируются к своему стратегическому ресурсу (что не приводит к повышению эффективности работы этого самого стратегического ресурса — людей) для повышения эффективности его работы?
Схлоапываем все 4 пункта, по аналогии — вывод: не хотят!
Батенька, вы не в нефтянке менеджером случайно работаете, чтобы так транжирить ресурсы?
Мда. Как-то уж слишком непрофессионально все описано. Такое ощущение, что автор никогда не работал менеджером. Стратоплан упал в моих глазах.
1 «Итак, если человек не делает того, что вы от него хотите...»
А с чего вы вообще взяли, что человек будет делать то, что от него хотите вы? Любой человек делате только то, что хочет сам.
Один из трех хабов статьи это «управление проектами», но все равно этого слишком мало, чтобы интерперетировать вашу фразу как «Итак, если подчиненный не делает то, что хочет от него менеджер...» Согласитесь, разница в есть.
2 Он не понимает, что то, как он работает — это плохо.
Что еще за критерий «то, как он работает — это плохо». Вы его сами придумали?
Можно ведь сказать, что «качество ниже ожидаемого» или «сроки больше приемлемых». Но «то, как ты работаешь — это плохо» — это очень плохая характеристика работы человека. Во-первых, в ней нет конкретики. Во-вторых, в ней не заложено решение. Если человек работал медленно, ему надо работать быстрее. А если все что он делает — это плохо, то что ему делать? Работать хорошо? Так может говорить ребенок 5 лет, но не менеджер.
3 Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться
Идеальный сотрудник бы переспросил и/или уточнил задание. Но идеальном сотрудникам, которые все делают правильно, менеджер вообще не нужен. Менеджер нужен т.к. сотроудники не идеальны. Автор не просто отказываеться признавать свои ошибки, похоже, что он действительно не понимает, что это именно его вина.
Задача менеджера — это дать задание, контролировать его исполнение и принять результат. Задание нужно давать максимально четко, со сроками и критериями приемки (что не было сделано), а так же контролировать процесс его исполнения, чтобы убедиться, что все идет как задумано (что тоже не было сделано).
И этот человек учит нас менеджменту?
1 «Итак, если человек не делает того, что вы от него хотите...»
А с чего вы вообще взяли, что человек будет делать то, что от него хотите вы? Любой человек делате только то, что хочет сам.
Один из трех хабов статьи это «управление проектами», но все равно этого слишком мало, чтобы интерперетировать вашу фразу как «Итак, если подчиненный не делает то, что хочет от него менеджер...» Согласитесь, разница в есть.
2 Он не понимает, что то, как он работает — это плохо.
Что еще за критерий «то, как он работает — это плохо». Вы его сами придумали?
Можно ведь сказать, что «качество ниже ожидаемого» или «сроки больше приемлемых». Но «то, как ты работаешь — это плохо» — это очень плохая характеристика работы человека. Во-первых, в ней нет конкретики. Во-вторых, в ней не заложено решение. Если человек работал медленно, ему надо работать быстрее. А если все что он делает — это плохо, то что ему делать? Работать хорошо? Так может говорить ребенок 5 лет, но не менеджер.
3 Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться
Идеальный сотрудник бы переспросил и/или уточнил задание. Но идеальном сотрудникам, которые все делают правильно, менеджер вообще не нужен. Менеджер нужен т.к. сотроудники не идеальны. Автор не просто отказываеться признавать свои ошибки, похоже, что он действительно не понимает, что это именно его вина.
Задача менеджера — это дать задание, контролировать его исполнение и принять результат. Задание нужно давать максимально четко, со сроками и критериями приемки (что не было сделано), а так же контролировать процесс его исполнения, чтобы убедиться, что все идет как задумано (что тоже не было сделано).
И этот человек учит нас менеджменту?
Справедливо. Особенно по 3 пункту. У нас менджер так и не научился за пол года, после первого замечания, ставить нормально задачи. Причем, ему об этом напоминают регулярно, но в итоге в JIRE один заголовок. И по каждой задаче идут уточнения.
Спасибо за комментарий. Понял, что мысль свою не донес, а напротив представил себя героем, который скидывает с себя всякую ответственность. :) А это совсем не то, что хотел донести, вообще писал не про это. Написал по этому поводу постскриптум в статье.
По поводу «хотите» и «хорошо-плохо» — это статья задумывалась (и по факту является) одной из цикла. И про все эти вещи подробно говорил в предыдущих статьях. Наверное, надо доуточнить формулировки прямо здесь, подумаю, как лучше это сделать.
Пока оставлю как есть — все равно конечная идея сделать из этого единую книгу. Там, по идее, должно быть все связано и корректно. Если согласитесь выступить ревьюером книги — буду отдельно благодарен. Хочется профессионализм материала не ронять. :)
По поводу «хотите» и «хорошо-плохо» — это статья задумывалась (и по факту является) одной из цикла. И про все эти вещи подробно говорил в предыдущих статьях. Наверное, надо доуточнить формулировки прямо здесь, подумаю, как лучше это сделать.
Пока оставлю как есть — все равно конечная идея сделать из этого единую книгу. Там, по идее, должно быть все связано и корректно. Если согласитесь выступить ревьюером книги — буду отдельно благодарен. Хочется профессионализм материала не ронять. :)
Нечеткая цель — это всегда, безоговорочно вина того и только того, кто эту цель ставит. А уж та задача из примера — эталон того, как делать нельзя. Говорю это как обитающий с обеих сторон баррикад.
Позволю себе усомниться во «всегда, безоговорочно». Есть такой вид начальников, которые во всём разбираются и любого подчинённого за пояс заткнут. И подчинённые им нужны лишь в виде недостающих рук, анецефалов.
Но вполне заслуживает права на жизнь ситуация, когда специалисты набираются для решения проблем в той области, в которой «плавает» руководитель команды. Здесь подчинённый должен сам поучаствовать в постановке задачи.
Но вполне заслуживает права на жизнь ситуация, когда специалисты набираются для решения проблем в той области, в которой «плавает» руководитель команды. Здесь подчинённый должен сам поучаствовать в постановке задачи.
Тут надо четко разделять цели и методы их достижения. Цель должна быть кристально ясна всем участвующим в рабочем процессе, и ответственность здесь лежит на руководители. А вот уж как до нее добраться — тут профессионалы и нужны.
В примере с Максом я бы сделал так же. Потому что правильная задача должна была звучать «посмотри статические анализаторы и прикрути какой-нибудь». Ожидать телепатических способностей от подчиненных крайне неразумно со стороны руководителя.
В примере с Максом я бы сделал так же. Потому что правильная задача должна была звучать «посмотри статические анализаторы и прикрути какой-нибудь». Ожидать телепатических способностей от подчиненных крайне неразумно со стороны руководителя.
Я всё-таки не про Максима, а про «всегда, безоговорочно». Меня смущает именно эта категоричность и безапелляционность.
Если говорить про цели, то мне привычней думать о SMART-целях. В таком случае, среди прочего, цель должна быть чётко сформулирована и измеряема. А это уже работа специалиста.
Если говорить про цели, то мне привычней думать о SMART-целях. В таком случае, среди прочего, цель должна быть чётко сформулирована и измеряема. А это уже работа специалиста.
Кстати, конкретно Максиму цель вообще не озвучили, а поставили задачу. Задача != цель ))))
Если человек может рассказать, как делать задачу — это безусловно лучше, чем если он не может рассказать. Но это не является гарантией того, что он умеет. Я могу достаточно подробно рассказать. как ломать кирпичи рукой. Но в реальности, боюсь, победит все равно кирпич.
Отлично. В цитатник. И как аргумент в очередном споре когда всё отдаётся на откуп человек, который не имеет опыта, но «сто пудов сделает как надо, ты чо очкуешь, он ведь красиво расписал путь решения, ну и что, что даже близко подобного опыта не было», за которым потом приходится разгребать.
Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться :)
[...]
Делегирование задачи — это всегда игра двух или большего количества людей. И если бы я уточнил у Макса, как оно понял задание, этой ситуации бы не возникло. Но если бы Макс сам переуточнил бы у меня постановку задачи — этой ситуации тоже бы не возникло.
Таки вы сами себе противоречите. Всё-таки виноваты, но виноваты тоже, а не только вы. ;-)
Ну и плюс, вы ведь менеджер, руководитель. Для вас умение четко ставить задачу — одно из ключевых. Т.е., виноваты оба, но вы — в большей степени. Значительно большей.
Таки вы сами себе противоречите. Всё-таки виноваты, но виноваты тоже, а не только вы. ;-)
Ну и плюс, вы ведь менеджер, руководитель. Для вас умение четко ставить задачу — одно из ключевых. Т.е., виноваты оба, но вы — в большей степени. Значительно большей.
Спасибо за комментарий. Конечно, виноват. Просто хотел подчеркнуть, что ответственность за четкость понимания задачи — она всегда на мне, независимо от того, какую роль я играю — менеджера, сотрудника или бизнес-партнера.
Но подчеркнул, как умею, коряво. :) Написал проясняющий постскриптум.
Так и не понял из статьи, о каком вообще «инструменте» идёт речь? Что это вообще за управленец, который не может сформулировать задачу, не может выбрать из сотрудников наиболее компетентного для её выполнения, и не может предоставить ресурсов под неё? Нужно начинать с того, в чём вообще этот менеджер видит своё предназначение?
«Но если бы Макс сам переуточнил бы у меня постановку задачи — этой ситуации тоже бы не возникло.»
А с чего ему уточнять, если он решил, что всё понял абсолютно правильно?
А с чего ему уточнять, если он решил, что всё понял абсолютно правильно?
что всё понял абсолютно правильно?
Программист не понял главного: что должно быть результатом его работы, а значит нужно было уточнить. Имхо.
Для того, что бы захотеть уточнить у него должны были появиться сомнения. А он был уверен в правильности своего понимания задачи.
Классический случай, когда лажанулись оба — и программист и менеджер.
Когда программист пишет функцию — он должен понимать, что у неё на входе и что будет на выходе. Если он не понимает, что функция должна вернуть — это повод подняться на уровень выше и выяснить это. Когда программист делает работу, он должен понимать, что должно быть на выходе — прототип, готовый код, юнит-тест или может быть документация. Если программист не знает чётко, что ему поручено — он должен уточнить.
Аналогично, когда менеджер ставит задачу — должно чётко прозвучать, что надо на выходе. Не «посмотри», а «прикрути анализатор к нашей системе контроля версий». Не «проверь», а «проверь и напиши мне к вечеру письмо по результатам». Не «подумай какой вариант быстрее работает», а «напиши тесты и пришли мне результаты до пятницы». Если менеджер не сказал чётко, что ему нужно — может получить что угодно, от чертежей адронного коллайдера до открытки с розовым пони.
Когда программист пишет функцию — он должен понимать, что у неё на входе и что будет на выходе. Если он не понимает, что функция должна вернуть — это повод подняться на уровень выше и выяснить это. Когда программист делает работу, он должен понимать, что должно быть на выходе — прототип, готовый код, юнит-тест или может быть документация. Если программист не знает чётко, что ему поручено — он должен уточнить.
Аналогично, когда менеджер ставит задачу — должно чётко прозвучать, что надо на выходе. Не «посмотри», а «прикрути анализатор к нашей системе контроля версий». Не «проверь», а «проверь и напиши мне к вечеру письмо по результатам». Не «подумай какой вариант быстрее работает», а «напиши тесты и пришли мне результаты до пятницы». Если менеджер не сказал чётко, что ему нужно — может получить что угодно, от чертежей адронного коллайдера до открытки с розовым пони.
Классический случай, когда лажанулись оба — и программист и менеджер.
Если в коллективе есть менеджер, то постановка задачи так, чтобы она не подразумевала многоликости трактовки — это его работа. Если разработчик будет включать своё воображение вперемешку с паранойей и додумывать стопицот потенциальных трактовок задачи, которые были бы валидны с позиции некой извращённой логики — то в итоге он первый кандидат на то, чтобы тот же самый менеджер вписал его в, прости господи, low-performer'ы. Ибо фигли он столько вопросов задаёт и придумывает какие-то странные непонятные сценарии, когда должен код строчить.
Если в коллективе есть менеджер, то постановка задачи так, чтобы она не подразумевала многоликости трактовки — это его работа.
Не все задачи поддаются 100% формализации, все равно будут темные области. Как бы вы ни расписывали задачу — все равно найдется один-два-три ключевых момента, которые будут поняты неправильно.
Постановка цели должна в первую очередь опираться на исполнителя. Кому-то достаточно сказать «поищи статистические анализаторы» и он в контексте общей проблемы поймет что нужно сделать, а другому нужен пошаговый алгоритм.
Но для того чтобы избежать проблемы недопонимания — исполнитель обязательно должен уточнить правильно ли он понял задачу, пересказав ее своими словами. Я когда разговариваю с заказчиками стараюсь делать именно так и хотел бы чтобы члены моей команды поступали так же.
А вот если не последовало уточняющих вопросов или пересказа — вот тогда менеджеру 100% нужно вмешиваться и вытаскивать из исполнителя клещами, как тот понял задачу. Проблемы как правило возникают именно здесь.
1. Он не понимает чего ты от него хочешь. Ты ему говоришь: “Переуточняй постановку задачи”?
2. Идем дальше. Если человек никогда не переуточнял постановку задачи, то как он её переуточнит сейчас? Может быть, он попробовал, увидел, что получается какая-то ерунда, и даже еще раз пробовать не стал.
3. Как у человека с загрузкой по времени? Ты, наверное, от него еще релизов каких-то требуешь? Как у него со временем?
4. Человек вообще хотел переуточнять постановку задачи?
2. Идем дальше. Если человек никогда не переуточнял постановку задачи, то как он её переуточнит сейчас? Может быть, он попробовал, увидел, что получается какая-то ерунда, и даже еще раз пробовать не стал.
3. Как у человека с загрузкой по времени? Ты, наверное, от него еще релизов каких-то требуешь? Как у него со временем?
4. Человек вообще хотел переуточнять постановку задачи?
Но если бы Макс сам переуточнил бы у меня постановку задачи — этой ситуации тоже бы не возникло.
Согласен.
Если программист додумывает формулировку задачи за менеджера, вместо того, чтобы уточнить, то он[программист] берет на себя часть ответственности за правильное выполнение задачи.
Имхо, проблема не в расплывчатой формулировке задачи на входе, а в том, что изначально отсутствовал диалог (или обратная связь) между менеджером и программистом.
UFO just landed and posted this here
В нечетких задачах можно обвинять менеджера, когда вы являетесь сотрудником. Но когда задачу ставят вам, не всегда можно сказать своему начальнику потом: ну ты там как-то соберись, научись нормально задачи-то ставить…
Делегирование задачи — это всегда игра двух или большего количества людей. И если бы я уточнил у Макса, как оно понял задание, этой ситуации бы не возникло. Но если бы Макс сам переуточнил бы у меня постановку задачи — этой ситуации тоже бы не возникло.
Максу платят за то, чтобы он [эффективно] прикручивал статические анализаторы. Вам платят за то, чтобы вы [эффективно] ставили ему задачи. Тот факт, что в каких-то компаниях придерживаются принципа «Я начальник — ты дурак», сути не меняет.
И хочется заметить, что в этом плане подход в Японии гораздо более правильней. В том что подчиненный не справился всегда виноват начальник, который поставил перед ним такую задачу. Почему он не справился ( не правильно понял, не хватает опыта, времени) не важно. Спрашивать причину провала следует всегда с руководителя, он ведь в конце концов за эту ответственность получает вполне солидную зарплату.
Друзья, спасибо за первые комментарии. Понял, что случай с Максом и кто же на самом деле был там виноват — важный вопрос. :) Добавил посткриптум в статью, надеюсь, что мысль пояснил. Спасибо за комментарии!
Александр, извини, не смог удержаться :) Влезу со своим ИМХО.
Причиной дискуссии про Макса стала путаница с понятиями цель и задача. Задача != цель.
Это не цель. Это задача. Задача отвечает на вопрос «что надо сделать?». Цель — «зачем?»
Задача без цели, как правило, смысла не имеет. Цель без задачи имеет смысл.
В данном случае цель, видимо, была повысить качество кода. Ты ее не озвучил — твоя ошибка.
Макс не спросил: «а на фига?». ИМХО, проявление непрофессионализма с его стороны.
Как-то, так.
Причиной дискуссии про Макса стала путаница с понятиями цель и задача. Задача != цель.
говорю своему сотруднику: Макс, посмотри статические анализаторы.
Это не цель. Это задача. Задача отвечает на вопрос «что надо сделать?». Цель — «зачем?»
Задача без цели, как правило, смысла не имеет. Цель без задачи имеет смысл.
В данном случае цель, видимо, была повысить качество кода. Ты ее не озвучил — твоя ошибка.
Макс не спросил: «а на фига?». ИМХО, проявление непрофессионализма с его стороны.
Как-то, так.
Александр, вы явно хотели подчеркнуть, что людям всегда следует придерживаться внутреннего локуса контроля, не зависимо от того на какой должности они находятся. А большинство поняли это так, будто вы хотите свалить ответственность на подчиненного. Так и напишите, возможно станет понятнее
Когда-то на тренингах по корпоративному управлению учили всегда уточнять задачу, пересказав ее своими словами. Стараюсь использовать в работе с заказчиками — сильно помогает. А вот если уточняющих вопросов от исполнителя не поступило — повод задуматься и постараться их вытянуть…
НО степень детализации задачи должна зависеть от уровня исполнителя. Кому-то достаточно сказать «поищи статистичекие анализаторы» и он в контексте проблемы сразу поймет о чем речь, а кому-то потребуется пошаговый алгоритм.
НО степень детализации задачи должна зависеть от уровня исполнителя. Кому-то достаточно сказать «поищи статистичекие анализаторы» и он в контексте проблемы сразу поймет о чем речь, а кому-то потребуется пошаговый алгоритм.
Менеджер был бы не менеджером, не пытайся он каждый раз оправдывать свою лень, глупость, некомпетентность и поиск виновников вокруг себя.
Цель (важно умение четко ее сформировать) +структура (тут важно правильно сформировать порядок выполнения задачи) +мотивация (здесь комментарии не нужны) = ожидаемый результат от работника.
Что касается самих работников, то нужно уметь планировать пути достижения цели.
Я например использую miniplan.ru и др напоминалки — помогает.
Что касается самих работников, то нужно уметь планировать пути достижения цели.
Я например использую miniplan.ru и др напоминалки — помогает.
>Помню, еще в Intel говорю своему сотруднику: Макс, посмотри статические анализаторы. Макс говорит, мол не вопрос, и уходит.
>Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться :)
>Мне нужно было, чтобы человек нашел бесплатный статический анализатор Java кода и прикрутил его к нашей системе контроля версий.
Вы разберитесь, посмотреть или посмотреть и прикрутить. Видимо у Макса telepat.dll непропатченный.
Бородатый анекдот:
Жена мужу-программисту: иди в магазин и купи палку колбасы, а если будут яйца, то купи десяток.
…
Муж приходит с 10 палками колбасы.
P.S. Муж понял задачу однозначно. Зачем что-то уточнять? =))
>Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться :)
>Мне нужно было, чтобы человек нашел бесплатный статический анализатор Java кода и прикрутил его к нашей системе контроля версий.
Вы разберитесь, посмотреть или посмотреть и прикрутить. Видимо у Макса telepat.dll непропатченный.
Бородатый анекдот:
Жена мужу-программисту: иди в магазин и купи палку колбасы, а если будут яйца, то купи десяток.
…
Муж приходит с 10 палками колбасы.
P.S. Муж понял задачу однозначно. Зачем что-то уточнять? =))
Есть старое армейское правило: получил приказ — повтори своими словами.
Сталкивался с людьми, считающими что опыт командования в армии делает их очень компетентными управленцами — и крайне счастлив, что армейские правила в общей массе так в армии и остаются.
В армии своя специфика и другие внешние условия в чем-то они проще, в чем-то сложнее. Кроме того, там тоже есть хорошие и плохие управленцы. Что-то мне подсказывает, что хорошие командиры в армии не менее хороши и в жизни.
Тем не менее правило придумано как раз чтобы обезопасить всех от случаев недопонимания. Там цена вопроса существенно выше. Хотя, конечно, все случаи оно тоже не покрывает.
Тем не менее правило придумано как раз чтобы обезопасить всех от случаев недопонимания. Там цена вопроса существенно выше. Хотя, конечно, все случаи оно тоже не покрывает.
11 палок колбасы муж должен был купить.
Я с такими управленцами, которые говорят «посмотри список _», а потом пропадают на 3 (!!!) дня, а потом появляются (!!!) и спрашивают «а почему сайт ещё не готов?» (какой сайт? почему он должен быть готов? почему задача поставлена устно, а не в трекере?) я встречаюсь регулярно. Но самая печаль в том, что они считают, что так и надо, да ещё и не готовы признать свою неправоту. Менеджер, который не умеет и не хочет общаться с командой, потому что он всегда прав — это что-то эпическое.
Если бы я был в такой ситуации и менеджер через 3 дня «чуть не убил», я бы уволился, а заодно в подробностях рассказал об этом менеджере и о его управленческих возможностях вышестоящему начальству.
Вы говорите одно, а думаете совсем другое. Если вы сказали «хочу диван с розовой спинкой», это значит, что вы хотите диван, у которого, очевидно, розовая спинка. Если вы при этом подумали, что на самом деле то вы хотите чашку кофе и яблоко, то совершенно очевидно и никаких сомнений, разночтений, вариантов «а кто виноват, что я без яблока» нет и быть не может. Я бы охарактеризовал такое как саботаж.
В остальном, очень похоже на опыт работы во некоторых местах. В том смысле, что я часто сталкиваюсь с отсутствием менеджмента. Как в статье — приходит Вася (менеджер проектов) раз в неделю и говорит «а чо у нас с задачами то?». Вот тут и Васю должны уволить к чертям. Ведь сам факт, того, что он приползает и задаёт такой вопрос, говорит о том, что процесс неуправляем. А Васе ответ всегда один — «что-то делается»
Если есть таск трекер и люди делают задачи, которые им ставят, то непонятность формулировок лежит тяжким грузом на тех, кто эти задачи описывает. «Не умею», «не хочу» и «не могу» говорят о том, что люди не имею квалификации для этой работы и возникает совершенно справедливый вопрос HRам (и техническим специалистам, которые участвовали в собеседованиях) — почему же их взяли на работу?
Если бы я был в такой ситуации и менеджер через 3 дня «чуть не убил», я бы уволился, а заодно в подробностях рассказал об этом менеджере и о его управленческих возможностях вышестоящему начальству.
Вы говорите одно, а думаете совсем другое. Если вы сказали «хочу диван с розовой спинкой», это значит, что вы хотите диван, у которого, очевидно, розовая спинка. Если вы при этом подумали, что на самом деле то вы хотите чашку кофе и яблоко, то совершенно очевидно и никаких сомнений, разночтений, вариантов «а кто виноват, что я без яблока» нет и быть не может. Я бы охарактеризовал такое как саботаж.
В остальном, очень похоже на опыт работы во некоторых местах. В том смысле, что я часто сталкиваюсь с отсутствием менеджмента. Как в статье — приходит Вася (менеджер проектов) раз в неделю и говорит «а чо у нас с задачами то?». Вот тут и Васю должны уволить к чертям. Ведь сам факт, того, что он приползает и задаёт такой вопрос, говорит о том, что процесс неуправляем. А Васе ответ всегда один — «что-то делается»
Если есть таск трекер и люди делают задачи, которые им ставят, то непонятность формулировок лежит тяжким грузом на тех, кто эти задачи описывает. «Не умею», «не хочу» и «не могу» говорят о том, что люди не имею квалификации для этой работы и возникает совершенно справедливый вопрос HRам (и техническим специалистам, которые участвовали в собеседованиях) — почему же их взяли на работу?
«Чуть не убил» — это ж было шутейное обозначение моей эмоциональной реакции. Прежде всего на себя, потому что понятно же, что моя вина, что цель так нечетко поставил.
Отчасти соглашусь. Однако после того, как человека взяли на работу, его легко могли перевести на другой проект, где нужных умений у него ПОКА нет. Потом они появятся, когда он научится, но пока нет.
Не могу — вопрос не про собеседования, а про наличие ресурсов.
Не хочу — мотивационные факторы можно проверить на собеседовании (обычно никто не проверяет, но это тема отдельно статьи :). Но у человека они со временем меняются. И отношение к работе меняется. Мы про это достаточно подробно писали вот тут.
«Не умею», «не хочу» и «не могу» говорят о том, что люди не имею квалификации для этой работы и возникает совершенно справедливый вопрос HRам (и техническим специалистам, которые участвовали в собеседованиях) — почему же их взяли на работу?
Отчасти соглашусь. Однако после того, как человека взяли на работу, его легко могли перевести на другой проект, где нужных умений у него ПОКА нет. Потом они появятся, когда он научится, но пока нет.
Не могу — вопрос не про собеседования, а про наличие ресурсов.
Не хочу — мотивационные факторы можно проверить на собеседовании (обычно никто не проверяет, но это тема отдельно статьи :). Но у человека они со временем меняются. И отношение к работе меняется. Мы про это достаточно подробно писали вот тут.
Хорошая и очень годная статья.
И тем более поэтому хочется осветить один момент по «ту сторону баррикад», сторону разработки.
Я, как менеджер-гуманитарий, иногда ставлю задачи на отдел нашей внутренней разработки. И столкнулся с такой проблемой: люди читают таск, и начинают программировать, несмотря на мои 100500 просьб в мессенжере «позови меня перед тем как будешь делать», «при любом вопросе смело меня дергай, чтобы потом не переделелывать», «я в любой момент готов подойти и рассказать на пальцах, чего же я хочу на самом деле».
В результате задача сделана в меру понимания программистом того, как это должно работать. Без учета того, что этим функционалом будут пользоваться люди «гуманитарного склада ума» (С). Без учета понятия «удобство». В общем, как в классических случаях, когда интерфейсы делают программисты: на стороне сервера всё вроде бы написано хорошо, но пользоваться этой штукой невозможно.
Однако в нашей же игровой студии, находящейся несколькими этажами в здании ниже, программист никогда не начнет программировать, получив таск. Благо, что люди сидят на одном этаже — он подойдет к заказчику, и спросит "- Ты хочешь что бы эта штука работала так-то и так-то? Ок, это сделаю за 10 дней. Однако могу сделать за 5 дней, если вот ту штуку не трогать, она все равно устареет в следующем релизе". «О, отличная мысль. Тогда сейчас откомменчу таск, и делай».
То есть убедиться, что ты находишься с заказчиком на одной волне — общее правило, позволяющее сэкономить кучу времени избежав переделок.
Вот где-нибудь программистов учат такому?
(п.с. К слову, из-за этого в ту игровую студию практически невозможно попасть программисту, который хоть и гениален, но не имеет желания развивать свои коммуникативные навыки — ибо в этом случае он всегда будет источником проблем из-за дискоммуникации. А одними «автономными» задачами его нагружать будет крайне сложно.)
И тем более поэтому хочется осветить один момент по «ту сторону баррикад», сторону разработки.
Я, как менеджер-гуманитарий, иногда ставлю задачи на отдел нашей внутренней разработки. И столкнулся с такой проблемой: люди читают таск, и начинают программировать, несмотря на мои 100500 просьб в мессенжере «позови меня перед тем как будешь делать», «при любом вопросе смело меня дергай, чтобы потом не переделелывать», «я в любой момент готов подойти и рассказать на пальцах, чего же я хочу на самом деле».
В результате задача сделана в меру понимания программистом того, как это должно работать. Без учета того, что этим функционалом будут пользоваться люди «гуманитарного склада ума» (С). Без учета понятия «удобство». В общем, как в классических случаях, когда интерфейсы делают программисты: на стороне сервера всё вроде бы написано хорошо, но пользоваться этой штукой невозможно.
Однако в нашей же игровой студии, находящейся несколькими этажами в здании ниже, программист никогда не начнет программировать, получив таск. Благо, что люди сидят на одном этаже — он подойдет к заказчику, и спросит "- Ты хочешь что бы эта штука работала так-то и так-то? Ок, это сделаю за 10 дней. Однако могу сделать за 5 дней, если вот ту штуку не трогать, она все равно устареет в следующем релизе". «О, отличная мысль. Тогда сейчас откомменчу таск, и делай».
То есть убедиться, что ты находишься с заказчиком на одной волне — общее правило, позволяющее сэкономить кучу времени избежав переделок.
Вот где-нибудь программистов учат такому?
(п.с. К слову, из-за этого в ту игровую студию практически невозможно попасть программисту, который хоть и гениален, но не имеет желания развивать свои коммуникативные навыки — ибо в этом случае он всегда будет источником проблем из-за дискоммуникации. А одними «автономными» задачами его нагружать будет крайне сложно.)
Тоже с таким сталкивался регулярно. Программисты начинают делать, не выяснив все подробности у заказчика.
Вообще, это означает, что задача не сформулирована четко.
Требования юзабилити можно рассказывать не только устно, их вполне можно изложить в трекере, а еще лучше нарисовать мокап. Но для менеджера это, очевидно, напряг, которого он пытается избежать путем устных переговоров. Для программиста же напряг ровно в противоположном — обсуждать по десять раз устно вместо того, чтобы прочесть четко изложенное требование и вернуться к нему в любой момент времени.
Вот вам и конфликт интересов из-за разницы психотипов.
Вообще, это означает, что задача не сформулирована четко.
Требования юзабилити можно рассказывать не только устно, их вполне можно изложить в трекере, а еще лучше нарисовать мокап. Но для менеджера это, очевидно, напряг, которого он пытается избежать путем устных переговоров. Для программиста же напряг ровно в противоположном — обсуждать по десять раз устно вместо того, чтобы прочесть четко изложенное требование и вернуться к нему в любой момент времени.
Вот вам и конфликт интересов из-за разницы психотипов.
Я склонен считать, что лучше всего найти понимание через обсуждение, а не через 10 вот таких итераций:
— «ты опять сделал не так»
— «я сделал всё как в таске написано»
— «так ведь ведь в таске не написано было делть эту фичу вот так»
— «поэтому я и сделал так, как считал правильным»
— «ну какое же это правильно, если мне надо было наоборот»
— «так надо было написать в таск, что надо наоборот»
— «ок, напишу»
(все расходятся недовольные тупизной друг друга, и история повторяется через два дня с новой «фичой не как в таске»)
Одна плохая крайность — «Я же тебе рассказал чего я хочу, неужели так просто взять и сделать безо всяких там ТЗ..?»
Вторая плохая крайность — «Да прочитал я что в таске написано, зачем тратить время на говорильню, сделаю к пятнице..»
Ведь программисту ничего, по-идее, не мешает выяснить «истинные» потребности заказчика, и согласовав их с ним, зафиксировать в таск-трекере в удобном для себя виде? Он не робот, и
— «ты опять сделал не так»
— «я сделал всё как в таске написано»
— «так ведь ведь в таске не написано было делть эту фичу вот так»
— «поэтому я и сделал так, как считал правильным»
— «ну какое же это правильно, если мне надо было наоборот»
— «так надо было написать в таск, что надо наоборот»
— «ок, напишу»
(все расходятся недовольные тупизной друг друга, и история повторяется через два дня с новой «фичой не как в таске»)
Одна плохая крайность — «Я же тебе рассказал чего я хочу, неужели так просто взять и сделать безо всяких там ТЗ..?»
Вторая плохая крайность — «Да прочитал я что в таске написано, зачем тратить время на говорильню, сделаю к пятнице..»
Ведь программисту ничего, по-идее, не мешает выяснить «истинные» потребности заказчика, и согласовав их с ним, зафиксировать в таск-трекере в удобном для себя виде? Он не робот, и
программист, это инженер. Если вы хотите получить полностью разжёванную задачу, то честно называйте себя кодером.
что мешает после первого же обсуждения записать это самому, если это не было произведено изначально?
источник: "Искусство программирования?"
Для программиста же напряг ровно в противоположном — обсуждать по десять раз устно вместо того, чтобы прочесть четко изложенное требование и вернуться к нему в любой момент времени.
что мешает после первого же обсуждения записать это самому, если это не было произведено изначально?
Даже если программисту не выдают грамотно составленное ТЗ — нужно обозначить себе четкое понимание того, что будет в итоге.
источник: "Искусство программирования?"
>> программист, это инженер. Если вы хотите получить полностью разжёванную задачу, то честно называйте себя кодером.
Обратите внимание, такому менеджеру не нравится не то, что нужно давать разжеванные задачи. С этим как раз все в порядке — ему в напряг разжевывать. Но решения, которые принимает программист, ему перманентно не нравятся. Он считает, что при каждом вопросе программист должен выйти из потока и найти незаменимого менеджера, который все пояснит на словах. Пользуясь вашей терминологией, такому менеджеру нужен именно кодер.
Обратите внимание, такому менеджеру не нравится не то, что нужно давать разжеванные задачи. С этим как раз все в порядке — ему в напряг разжевывать. Но решения, которые принимает программист, ему перманентно не нравятся. Он считает, что при каждом вопросе программист должен выйти из потока и найти незаменимого менеджера, который все пояснит на словах. Пользуясь вашей терминологией, такому менеджеру нужен именно кодер.
Прочитал статью дважды, но не нашёл ответа на вопрос из заголовка: “Как раскачать low-performer’а”
Увидел описание причин первого порядка что результат не получен в срок и в необходимом объеме, но не ясно как выявлять причины второго порядка и что с ними делать.
А еще есть потрясающие случаи, когда человеку не хватает собранности и усидчивости. Короткие задачи он делает прекрасно, а на длинных начинает отвлекаться и постоянно движется «не туда». С одной стороны надо почти непрерывно контролировать такого работника, это микро-менеджмент, который негативно влияет как на менеджера, так и на исполнителя. А с другой стороны ослабление контроля ведет к падению производительности. При этом человек и умеет, и хочет, и может, и понял. У программистов такое встречается очень часто.
Увидел описание причин первого порядка что результат не получен в срок и в необходимом объеме, но не ясно как выявлять причины второго порядка и что с ними делать.
А еще есть потрясающие случаи, когда человеку не хватает собранности и усидчивости. Короткие задачи он делает прекрасно, а на длинных начинает отвлекаться и постоянно движется «не туда». С одной стороны надо почти непрерывно контролировать такого работника, это микро-менеджмент, который негативно влияет как на менеджера, так и на исполнителя. А с другой стороны ослабление контроля ведет к падению производительности. При этом человек и умеет, и хочет, и может, и понял. У программистов такое встречается очень часто.
UFO just landed and posted this here
Возможно, разработчик иррационал. Тогда кроме варианта с разбиения задачи, есть другой. Такому разработчику можно помимо основной задачи дать ещё несколько мелких, и разрешить переключаться на них, когда большая достала. При переключении между задачами разработчик будет чувствовать прилив сил от результатов.
Спасибо за комментарий. Мысль была в том, что перед раскачкой надо таки провести анализ. А дальше в зависимости от причин. Скорее всего, это будет обратная связь, где человеку нужно будет «продать проблему» с его низкой производительностью по алгоритму, который мы разбирали вот здесь и здесь. И вместе с ним смотреть, будут ли изменения.
Да, распространенная ситуация. :)) Тут опять же, если обе стороны согласны с тем, что присутствует такая, скажем так, особенность в работе, и согласовали частоту и степень контроля — то это не будет восприниматься как микроменеджмент. Микроменеджмент — это в том числе, несогласованный, неожиданный тип контроля.
А еще есть потрясающие случаи, когда человеку не хватает собранности и усидчивости. Короткие задачи он делает прекрасно, а на длинных начинает отвлекаться и постоянно движется «не туда». С одной стороны надо почти непрерывно контролировать такого работника, это микро-менеджмент, который негативно влияет как на менеджера, так и на исполнителя. А с другой стороны ослабление контроля ведет к падению производительности. При этом человек и умеет, и хочет, и может, и понял. У программистов такое встречается очень часто.
Да, распространенная ситуация. :)) Тут опять же, если обе стороны согласны с тем, что присутствует такая, скажем так, особенность в работе, и согласовали частоту и степень контроля — то это не будет восприниматься как микроменеджмент. Микроменеджмент — это в том числе, несогласованный, неожиданный тип контроля.
То есть описанные причины не являются исчерпывающими для определения в чем проблема? И как же в этом случае ответить на вопрос «как раскачать low performer_а»?
Имхо пока с человеком не начнешь общаться, полного списка причин не составишь. То, что написано в статье — возможные причины, которые мне сразу бросились в глаза при анализе ситуации. В разговоре может вылезти все, что угодно — от неприятия инженером конкретного менеджером до личных проблем.
Через это и станет ясно, что делать для «раскачки». А может быть, все кончится вообще расставанием.
Через это и станет ясно, что делать для «раскачки». А может быть, все кончится вообще расставанием.
Для меня ситуация с Максов очень странная и непонятная. Что значит сказал своему разработчику? Получается, если менеджеров несколько, Макс должен учить наизусть, то что ему говорят все менеджеры, и такая ошибка очень распространена в среде менеджмента. В не правильной, не точной постановке всегда виноват менеджер. Работа программиста — писать код. Работа менеджера — ставить задачи(формализовать требования бизнеса, объяснить задачу исполнителю, проконтролировать сроки выполнения, корректировать и консультировать исполнителя) и если он с этой работой не справился — обвинять в чем-либо программиста не правильно. Программист может подойти и уточнить, что же именно необходимо бизнесу. Но ему не за это платят деньги.
>Макс, посмотри статические анализаторы.
вообще-то Макс все правильно сделал. Глагол смотреть несет смысл мониторинга, а не воздействия на объект. В отличие от «прикрутить».
>Я чуть его не убил.
Думаю, он тоже
вообще-то Макс все правильно сделал. Глагол смотреть несет смысл мониторинга, а не воздействия на объект. В отличие от «прикрутить».
>Я чуть его не убил.
Думаю, он тоже
Вспомнилась примерно такая история, дословно не нашел, так что по памяти.
«У нас тут лампочка периодически в коридоре вырубается. Оставили заявку „Прийти и посмотреть, что за фигня“. Инженеры пришли, посмотрели, сказали, „да, фигово“ и ушли. Надо похоже следующую заявку четче сформулировать»
«У нас тут лампочка периодически в коридоре вырубается. Оставили заявку „Прийти и посмотреть, что за фигня“. Инженеры пришли, посмотрели, сказали, „да, фигово“ и ушли. Надо похоже следующую заявку четче сформулировать»
UFO just landed and posted this here
С философской точки зрения, да. Потому что сначала должна расти ответственность, а потом зарплата — когда станет понятно, что с ответственностью ты справляешься.
С практической точки зрения, тоже да. Потому что если происходящее касается тебя — то варианта два. Либо начать что-то делать по этому поводу, либо ждать, пока кто-то другой сделает. Я стараюсь не ждать.
Но это мои убеждения, мои, так сказать, тараканы. :) И это то, что принято в нашей компании. Другая точка зрения, вероятно тоже имеет право на жизни в каких-то компаниях.
С практической точки зрения, тоже да. Потому что если происходящее касается тебя — то варианта два. Либо начать что-то делать по этому поводу, либо ждать, пока кто-то другой сделает. Я стараюсь не ждать.
Но это мои убеждения, мои, так сказать, тараканы. :) И это то, что принято в нашей компании. Другая точка зрения, вероятно тоже имеет право на жизни в каких-то компаниях.
«Я чуть его не убил. Мне нужно было, чтобы человек нашел бесплатный статический анализатор Java кода и прикрутил его к нашей системе контроля версий.
Макс понял задачу по-своему — что нужно провести сравнительный анализ доступных статических анализаторов. Человек скачал и установил все эти анализаторы, придумал метрики для сравнения, нашел тестовые примеры. Три дня он занимался довольно осмысленной деятельностью. А я, как его менеджер, в итоге остался недоволен.
Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться :)»
Щито?
Классика перевода стрелок и оправдания собственной промашки.
Если вы над Максом ходите, то вы по определению должны иметь больше опыта, уточнять неточности, и ловить ошибки Макса, а не наоборот. Есть конечно проактивные люди, которые не отходя от кассы вас расспросят (например я вас бы сразу задержал вопросом «И когда вы говорите посмотри, вы имеете ввиду...?», потому что я ненавижу нечёткие задания), но ожидание такого подхода от каждого работника как-то бредово звучит, особенно от вас — человека, который позиционирует себя как менеджер.
Если честно, только байки и понравились. Хороший опыт и своевременный [само]анализ.
Макс понял задачу по-своему — что нужно провести сравнительный анализ доступных статических анализаторов. Человек скачал и установил все эти анализаторы, придумал метрики для сравнения, нашел тестовые примеры. Три дня он занимался довольно осмысленной деятельностью. А я, как его менеджер, в итоге остался недоволен.
Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться :)»
Щито?
Классика перевода стрелок и оправдания собственной промашки.
Если вы над Максом ходите, то вы по определению должны иметь больше опыта, уточнять неточности, и ловить ошибки Макса, а не наоборот. Есть конечно проактивные люди, которые не отходя от кассы вас расспросят (например я вас бы сразу задержал вопросом «И когда вы говорите посмотри, вы имеете ввиду...?», потому что я ненавижу нечёткие задания), но ожидание такого подхода от каждого работника как-то бредово звучит, особенно от вас — человека, который позиционирует себя как менеджер.
Если честно, только байки и понравились. Хороший опыт и своевременный [само]анализ.
понравилось,
постоянно сталкиваюсь с третьей причиной, загружают народ на полную катушку, а потом удивляются, что все застопорилось.)
в таких случаях напоминаю заказчику сказку про шапки, когда сначала просили сделать одну шапку из куска шкуры, а потом раскатали губы на семь штук и в результате получили семь, но крохотных шапочек.)
постоянно сталкиваюсь с третьей причиной, загружают народ на полную катушку, а потом удивляются, что все застопорилось.)
в таких случаях напоминаю заказчику сказку про шапки, когда сначала просили сделать одну шапку из куска шкуры, а потом раскатали губы на семь штук и в результате получили семь, но крохотных шапочек.)
Есть ровно один случай, когда мы на 100% можем быть уверены, что человек умеет что-то делать. Если он уже неоднократно успешно (тут важны оба слова) делал аналогичные задачи, и вы это видели.
Невозможно уметь всё.
Если я сейчас спрошу вас, кто виноват в этой ситуации, вы, вероятно, обвините меня. И здесь позвольте не согласиться :)
Не сомневайтесь, тут только ваша вина и кивание на Максима — «мог бы и переуточнить» — признак инфантильности сознания.
Если не понятно, то поясняю — Максим считал, что он понял задачу и у него не было вопросов к тому, что он понял. И если он не дурак, то уже в следующий раз, зная что начальник плохо объясняет задачи и не способен убедиться в правильности понимания задачи подчиненным, предпримет попытку уточнить совпадение понимания обеих сторон. Говоря прямо — возьмёт часть обязанностей менеджера на себя.
Бывают ситуации, когда начальнику лучше помочь: начальник в мыле разгребает завалы, старается выполнять свои обязанности и т.п. Но обвинять подчинённого в том, что он не взял добровольно на себя часть твоей работы это — свинство.
Sign up to leave a comment.
4 причины, почему люди чего-то не делают или “Как раскачать low-performer’а”