Как всегда все сложно. Кого-то мотивирует на переход в состояние «работает» интерес, кого-то панический монстр, кого-то наблюдение за результатами его труда, кого-то ничего не мотивирует. И не всегда в последнем виноват только человек. То что в последнее время становиться все больше коллег, которые не умеют сами себя мотивировать, да, такое наблюдение есть. Но здесь ведь может быть и эффект, что раньше деревья были выше и небо голубее.
За статью спасибо, рад, что после длительного перерыва, опять появилось что-то в вашем исполнении на хабре.
В достаточно больших компаниях на первое собеседование приходит «ответственный за проверку на общую адекватность». И это не только в разработке. С ними, возможно, и нет смысла обсуждать эти вопросы. Но если их предложили задать, то почему не воспользоваться такой возможностью? Да, интервьюер может не знать ответа, скажет что не знает. Но с одной стороны, вы в любом случае покажете свой интерес, а с другой, очень интересные бывают ответы, когда HR знает.
Спросить о чем-то HR, менеджера, потенциального коллегу — это не просто хороший тон и возможность оставит нужное профессиональное впечатление о себе.
Ну а так, на часть вопросов может ответить и HR, особенно если он реально работает с командой, а не просто делопроизводитель/ответственный за проверку на общую адекватность соискателей. А разделы «Карьерный рост» и «Психологическая обстановка» практически на 100% именно к HR. И нужно будет насторожиться, если HR не может внятно ответить на вопрос «Почему на эту должность вы ищете внешних кандидатов?».
Внутренние посиделки очень хорошая тема. Тоже регулярно проводим, вот сейчас пишу эти строки, а соседней комнате собираются ребята послушать про секционирование в БД. Да, у нас это днем, вечером все разбегаются по семьям и делам.
Тут есть некоторая магия. Если у вас адекватный руководитель (ну или в компании очень хорошо выстроены процессы продвижения), то при вашей высокой эффективности вы будете лучшим кандидатом на следующую ступеньку, чем тот, кто за ту же зарплату делает меньше. Ну и бесплатный бонус от применения техник организации работы/времени, это не то, что вы делаете больше, а то, что вы делаете важное. В том числе и для вас важное.
У этого эффекта есть и обратная сторона. Если откладывать только одно дело, то да, можно получить некий положительный результат. «Темная сторона» заключается в том, что если таких дел накапливается достаточно много, то результат выполнения другой работы может существенно ухудшиться. А самое печальное в этом, что как показывают опыты, даже запоминание одного чего-то может оказаться много.
Именно, каждый должен отвечать за свою часть общего дела. В пьесе представлены менеджеры типа «передасты». Которые кроме как передавать от руководства хотелки на разработчика, а оценки разработчика руководству — ничего не могут. А в случае проблем или ответственности пытаются их спихнуть на других.
Я просто напомню с чего все началось.
> С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок?
Если менеджер не может организовать работу программиста чтобы он укладывался в срок. Обратите внимание, не программист должен это обеспечить, а менеджер. Если менеджер не может вовремя уволить человека который не укладывается в сроки (когда то что мешает программисту устраняется, а программист все равно халявит) и заменить его другим. Если менеджер не заложил буферы на то, что время от времени задачи даже выполняемые повторно будут занимать больше времени по объективным причинам.
То? При чем здесь программист?
Вы не подумайте, у меня в подчинении очень хорошие программисты, которые эффективно делают свою работу. Но если один из проектов, за которые я несу ответственность не будет соответствовать заявленным требованиям (функциональным, нефункциональным, по срокам реализации, по бюджету), то ответственность перед заказчиками несу в первую очередь я. передо мной несут ответственность руководители проектов. А если мне руководитель проекта придет и скажет, что проект сфейлился, потому что Вася уже три месяца не делает вовремя порученные ему задачи. То надо уволить этого менеджера, т.к. он не решил проблему за 3 месяца, ну и следом меня, т.к. о том что на проекте 3 месяца идет отставание по срокам я узнал в день релиза.
А теперь как только на задачи которые я оцениваю в два часа, я буду ставить три, то быстрее трех я ее делать не буду. Ведь так? А потом я буду на эту задачу (помня что она занимает три часа) говорить четыре. Да? И вас это будет устраивать?
Э… Я как разработчик должен организовать свою работу так, чтобы меня не дергали менеджеры, аналитики, тестировщики, заказчики. Точно? За это отвечает не менеджер? Т.е. я должен послать вас когда вы придете ко мне за оценкой? Так? Если да, то зачем вы пришли?
Я как разработчик должен договориться с отделом эксплуатации чтобы мне развернули нужный тестовый стенд или это ваша работа как менеджера?
Чтобы не было недоразумений, я уже лет 7 как менеджер, а первые подчиненные у меня появились лет 15 назад.
Мы живем в мире с высокой неопределенностью. Разработчик дал вам оценку в 16 часов. А потом у него подскочила температура и он ушел в больницу. Вы его не отпустите? Или это он виноват, что не решил задачу за 16 часов?
Я разработчик, я отвечаю за свои оценки. Приходит ко мне менеджер и говорит: «Сколько?»
Ну я же отвечаю, за свои оценки, поэтому я, прикинув, что задача на 2 часа, но придет менеджер Петя и попросит подсказать как сделано А, потом забежит аналитик Света и попросит посмотреть нормальное ли требование Б, потом может быть недоступен тестовый стенд, дам оценку в 10 часов.
Что скажет на это менеджер?
Э… Извините, что? Менеджер не знает, что такое иерархическое дерево работ? Да, для его построения ему нужен специалист в разработке, к которому он придет с верхнеуровневым деревом (эпики, фичи, стори), а тот уже разобьет на тривиальные оценки.
Правда, эта вся фигня с диаграммами Ганта выглядит красиво в ПМБуке, в Прожекте каком-нибудь, а вот в реальном проекте вдруг выясняется, что заказчик хотел не этого, а вот того. Это должно быть не так, а вот этак. Ну и все первоначальные оценки или идут в корзину, или идет торг на уровне «мы сделаем это, но выкинем вот это», или идет раздувание сроков-бюджетов. Там куча всяких интересных вариантов. Опять же будет своя специфика с внутренней разработкой, продуктовой, заказной. Не зря же пытаются всякие итеративные, инкрементальные способы разработки внедрять. Как раз из этих соображений, что самая адекватная оценка, это оценка полученная в процессе работы. Да и чем дольше идет проект, тем лучше предсказание рисков и все такое.
Если верить статистике, например вот от сюда, то в Москве примерно 30 дней в году будут с грозами. У тех кто захочет воспользоваться таким взрывателем достаточно большое пространство для маневра остается…
Я не призываю делать или не делать такие детонаторы (я к производству взрывчатки вообще никакого отношения не имею), просто всегда есть проблема, что вы ставите систему защиты, а злоумышленник ею и воспользуется. Из ярких примеров, 11 сентября, после которого в кабины самолетов стали ставить бронированные двери со сложным механизмом защиты от проникновения. Ну и что? В прошлом году А320 разбился как раз из-за того, что психически нездоровый второй пилот воспользовался всем этим чтобы совершить самоубийство…
К сожалению, это не фантазии, а то с чем сталкивается организация внедряющая систему материальной мотивации. И тут не важно, вашу или другую. Весь мир корпит на всякими ITSM-амим и прочими штуками, которые вроде как теоретически позволят бизнес-цели перенести в сервисное подразделение… А у вас уже есть стройная система, а все что в нее не вписывается — фантазии. Хм, или весь мир, или вы не правы. Да и, извините, Герцберга — пока вроде никто не опроверг.
Спасибо, вы составили приятный фон моему обеденному перерыву, но — нет. Слона вы так и не продали.
Да, хорошая статья. Читал когда она только вышла.
>> Бонус за выполненную задачу (2.1) = ЗатраченныеЧасы (2.1.1) * ТарифнаяСтавкаРазработчика (2.1.2) *
>> КоэффициентПриоритета (2.1.3) * КоэффициентОценкиЗаказчика (2.1.4) * КоэффициентОшибки (2.1.5) *
>> КоэффициентЗвездности (2.1.6) + МалусПросрочкиИсполненияЗаявки (2.1.7)
Разработчик открыл законодательство и в доступных выражениях объяснил, что реализовывать это нельзя. Заказчик не получил то что хотел, поставил низкий коэффициент, программист получил меньше денег, в следующий раз не будет высовываться и сделает то что написали, а там хоть трава не расти.
Другой сценарий. Заказчику нужно срочно реализовать фичу. Он согласен получить хоть что-то, с любыми багами, т.к. у него горит срок. Разработчик который возьмется за эту задачу при правильном решении, с минимумом багов получит ту-же низкую оценку от заказчика, т.к. не успел. При быстром и лишь бы работало, возникает проблема списания денег за ошибки. Куда не кинь, всюду клин. Разработчики эту задачу не берут. Вы, как написали в части 2,5 эскалируете проблему, обсуждаете с «верхним» представителем заказчика, а срок уже прошел.
Я все правильно рассказал про вашу систему?
>> Простите, но мы этим деньги зарабатываем.
Прошу прощения, но именно про это я и говорю. Пока идет предпродажная деятельность, все классно и красиво. По результатам внедрения неожиданно все скатывается в один из двух вариантов указанных мной в корне этой ветки комментариев.
>> Систему для разработчиков я выкладывал.
На вашем аккаунте две публикации: эта и предыдущая. В этой такого нет, или вы про «вредные советы»? Ну и комментариев три. Все в этой статье. Можно ссылку где вы их выкладывали?
За статью спасибо, рад, что после длительного перерыва, опять появилось что-то в вашем исполнении на хабре.
Ну а так, на часть вопросов может ответить и HR, особенно если он реально работает с командой, а не просто делопроизводитель/ответственный за проверку на общую адекватность соискателей. А разделы «Карьерный рост» и «Психологическая обстановка» практически на 100% именно к HR. И нужно будет насторожиться, если HR не может внятно ответить на вопрос «Почему на эту должность вы ищете внешних кандидатов?».
> С чего вдруг менеджер должен публично брать на себя косяки программиста, не уложившегося в срок?
Если менеджер не может организовать работу программиста чтобы он укладывался в срок. Обратите внимание, не программист должен это обеспечить, а менеджер. Если менеджер не может вовремя уволить человека который не укладывается в сроки (когда то что мешает программисту устраняется, а программист все равно халявит) и заменить его другим. Если менеджер не заложил буферы на то, что время от времени задачи даже выполняемые повторно будут занимать больше времени по объективным причинам.
То? При чем здесь программист?
Вы не подумайте, у меня в подчинении очень хорошие программисты, которые эффективно делают свою работу. Но если один из проектов, за которые я несу ответственность не будет соответствовать заявленным требованиям (функциональным, нефункциональным, по срокам реализации, по бюджету), то ответственность перед заказчиками несу в первую очередь я. передо мной несут ответственность руководители проектов. А если мне руководитель проекта придет и скажет, что проект сфейлился, потому что Вася уже три месяца не делает вовремя порученные ему задачи. То надо уволить этого менеджера, т.к. он не решил проблему за 3 месяца, ну и следом меня, т.к. о том что на проекте 3 месяца идет отставание по срокам я узнал в день релиза.
Я как разработчик должен договориться с отделом эксплуатации чтобы мне развернули нужный тестовый стенд или это ваша работа как менеджера?
Чтобы не было недоразумений, я уже лет 7 как менеджер, а первые подчиненные у меня появились лет 15 назад.
Мы живем в мире с высокой неопределенностью. Разработчик дал вам оценку в 16 часов. А потом у него подскочила температура и он ушел в больницу. Вы его не отпустите? Или это он виноват, что не решил задачу за 16 часов?
Ну я же отвечаю, за свои оценки, поэтому я, прикинув, что задача на 2 часа, но придет менеджер Петя и попросит подсказать как сделано А, потом забежит аналитик Света и попросит посмотреть нормальное ли требование Б, потом может быть недоступен тестовый стенд, дам оценку в 10 часов.
Что скажет на это менеджер?
Правда, эта вся фигня с диаграммами Ганта выглядит красиво в ПМБуке, в Прожекте каком-нибудь, а вот в реальном проекте вдруг выясняется, что заказчик хотел не этого, а вот того. Это должно быть не так, а вот этак. Ну и все первоначальные оценки или идут в корзину, или идет торг на уровне «мы сделаем это, но выкинем вот это», или идет раздувание сроков-бюджетов. Там куча всяких интересных вариантов. Опять же будет своя специфика с внутренней разработкой, продуктовой, заказной. Не зря же пытаются всякие итеративные, инкрементальные способы разработки внедрять. Как раз из этих соображений, что самая адекватная оценка, это оценка полученная в процессе работы. Да и чем дольше идет проект, тем лучше предсказание рисков и все такое.
Я не призываю делать или не делать такие детонаторы (я к производству взрывчатки вообще никакого отношения не имею), просто всегда есть проблема, что вы ставите систему защиты, а злоумышленник ею и воспользуется. Из ярких примеров, 11 сентября, после которого в кабины самолетов стали ставить бронированные двери со сложным механизмом защиты от проникновения. Ну и что? В прошлом году А320 разбился как раз из-за того, что психически нездоровый второй пилот воспользовался всем этим чтобы совершить самоубийство…
Спасибо, вы составили приятный фон моему обеденному перерыву, но — нет. Слона вы так и не продали.
>> Бонус за выполненную задачу (2.1) = ЗатраченныеЧасы (2.1.1) * ТарифнаяСтавкаРазработчика (2.1.2) *
>> КоэффициентПриоритета (2.1.3) * КоэффициентОценкиЗаказчика (2.1.4) * КоэффициентОшибки (2.1.5) *
>> КоэффициентЗвездности (2.1.6) + МалусПросрочкиИсполненияЗаявки (2.1.7)
Разработчик открыл законодательство и в доступных выражениях объяснил, что реализовывать это нельзя. Заказчик не получил то что хотел, поставил низкий коэффициент, программист получил меньше денег, в следующий раз не будет высовываться и сделает то что написали, а там хоть трава не расти.
Другой сценарий. Заказчику нужно срочно реализовать фичу. Он согласен получить хоть что-то, с любыми багами, т.к. у него горит срок. Разработчик который возьмется за эту задачу при правильном решении, с минимумом багов получит ту-же низкую оценку от заказчика, т.к. не успел. При быстром и лишь бы работало, возникает проблема списания денег за ошибки. Куда не кинь, всюду клин. Разработчики эту задачу не берут. Вы, как написали в части 2,5 эскалируете проблему, обсуждаете с «верхним» представителем заказчика, а срок уже прошел.
Я все правильно рассказал про вашу систему?
Прошу прощения, но именно про это я и говорю. Пока идет предпродажная деятельность, все классно и красиво. По результатам внедрения неожиданно все скатывается в один из двух вариантов указанных мной в корне этой ветки комментариев.
>> Систему для разработчиков я выкладывал.
На вашем аккаунте две публикации: эта и предыдущая. В этой такого нет, или вы про «вредные советы»? Ну и комментариев три. Все в этой статье. Можно ссылку где вы их выкладывали?