Согласования нужны не для штрафов и санкций, согласования нужны для информации о ходе проведения работ
Я и так знаю кто и что делает. Согласования в большинстве задач просто не нужны. Нужно доверять людям.
«Вы почему-то считаете что я обвиняю программиста в том, что к примеру, клиенты не похвалили его работу»
Я так считаю потому что вы сами это написали. Когда задали это как один из критериев качества его работы.
Похвала клиентов — это критерий качества. Но если похвалы нет, это не повод к обвинениям. Программист — не мелкий винтик в системе, программист — это обычный человек, способный разбираться в самых различных вопроса. Я не раз встречал и поощрал программистов, которые сами ставили себе задачи, сами их выполняли, сами общались с клиентами. Это одни из самых эффективных сотрудников. Таким не надо «ставить задачу», они сами поставят кому угодно задачу и будут правы. Что я делал? Просто доверял и всё. И основная проверка качества — как раз продажи клиентам.
Я не настаиваю, что этот метод подойдёт всем, но мне понравилось.
А если программист работает хорошо, но никак «не лезет» в общение с клиентами — пожалуйста. Это ему не в плюс, но и ругать его за это никто не будет.
«Лезу в код — там всё жутко сложно. Меняю код на простой и быстрый.»
А вот здесь не помешал бы пример. Люди, у которых мало опыта, обычно наоборот делают излишне просто, конкретно под задачу, без учета возможных изменений, и в дальнейшем это создает сложности при появлении новых требований.
На эту тему могу говорить вечно:) наболело…
Например, дана задача — запрограммировать кошку, которая мяукает.
Я пишу класс «кошка», добавляю в него нужные свойства и методы.
Плохой программист сделает сразу «на будущее» — классы млекопитающее -> кошачьи -> кошка. Отдельно будет класс, посвящённый мяуканию.
Далее приходит уточняюща задача — добавить машинку. Оказалось, что кошка — плюшевая, а машинка — пластмассовая.
Я меняю класссы
класс игрушка — от неё наследую пластмассовая и плюшевая, от них кошку и машинку. То есть я делаю полный рефакторинг.
Плохой программист подумает «ну нифигаш себе… не могли сволочи сразу пояснить что к чему » и он будет «решать» проблему либо:
— наследует машинку от кошки (самый быстрый метод достичь решения ТЗ)
— сделает вообще отдельный класс «машинка», никак не связанный с кошкой
— или еще что-нибудь.
главное — плохой программист оставит ошибочные классы, такие как «млекопетающее». Как раз этот плохой программист после будет говорить про «важность продумывания рефакторинга», хотя при правильной работе рефакторинг будет выполнен быстрее, чем разговоры о нём.
при дальнейших изменения ТЗ (добавить подарочные наборы из нескольких уже описанных игрушек) у плохого программиста всё усугубляется. У хорошего — кода всегда меньше. Хороший программист не «думает о будущем», не мусорит код, при этом он быстро меняет алгоритмы исходя из меняющегося настоящего. У него нет ничего лишнего. Я уже не говорю о названиях. Смотрю на код VCL / FMX Delphi и «читаю» его как книгу без документации. Всё просто и понятно. Так пишут профи. Смотрю на код горе-программистов в стиле KoefValue := MosArr.Add(MyList) и думаю… так я понял слово List — список… отлично. Больше пока ничего неясно. Через полчаса изучений оказываеся, что List — это «лист» бумаги на русском языке. Конечно, для новичков есть правила, читают выполняют. Но лишние усложнения там, где они не нужны — это «бич» многих начинающих.
p.s. весной я заменил код программистов (достаточно хороших) примерно 50К строк на 5К строк. Выкинул тьму «высокотехнологичных» наворотов вроде тех же хелперов/интерфейсов/фукнций как параметров, классов-менеджеров и много другого, заменил всё «простой и банальной» архитекурой ООП. Вместо прежних сложных наворотов и классов-менеджеров для работы с разными типами данных ( integer/double/string..) сделал классы для каждого типа (класс TInteger, TDouble… с наследованием от общего типа) с удобной обработкой каждого типа внутри этих классов. Итог: скорость обработки данных выросла в 5 раз, скорость восприятия кода в 10 раз (хотя бы потому что самого кода стало в 10 раз меньше).
Статья мне понравилась.
Есть ещё психологический приём:
Если руководитель сомневается в эффективности сотрудника, он должен задать себе вопрос: "как бы я поступил с этим сотрудником, если бы он пришёл устраиваться на работу?"
— В какие сроки можно реализовать?
…
— 2 месяца
— Почему так долго?
— Надо сначала сделать рефакторинг, у нас там весь код рассчитан только на ввод через интерфейсваши пользователя. Месяц на рефакторинг…
Вы говорите:
— Хорошо
Проходит месяц, рефакторинг не закончен. Программист говорит «очень сложный был код, не успеваю, нужно ещё пару недель». Через две недели тоже самое. Ваша реакция? Какие санкции вводить?
— На самом деле разговоры, подобные описанному Вами, у меня идут часто, но это неофициальное согласование сроков. Еще чаще я даю задачи вообще не указывая никаких сроков. Всё на доверии.
Я пробовал такой метод с формальными сроками однажды, мне не понравилось. Вот почему:
1. Очень сложно оценить время, особенно если это баги. Пару недель назад я решил примерно 10 багов, 9 из них за 5 часов, а 10й — за три дня. А на первый взгляд они все были похожие. Никогда бы не подумал, что придётся три дня заниматься с вроде бы простой проблемой. Меня как программиста за это как накажут?
2. непонятно, что делать, если программист просрочил задачу. Если это хороший программист, и были объективные причины. Просто простить? Если да, то в чём смысл согласований? А если реально накосячил программист, какие санкции будут применены? Какие будут доказательства его вины? Программист после такого просто будет стараться всегда завышать сроки.
3. большинство даже самых классных программистов абсолютно не умеют оценивать сроки. Поэтому, доверяя программистам я не доверяю срокам, которые они говорят.
4. обязательно появятся программисты, которые будут просить огромные сроки для элементарных задач. Почему бы и нет? Вы им не доверяете, почему программист должен доверять Вам? И вместо обсуждения того, как делать проект, идёт убивание времени на то, сколько времени его делать.
5. Лишние формальности — лишняя нагрузка на руководителя. Это само по себе управленческая ошибка. Руководитель должен стремиться к тому, чтобы делегировать задачи, а не мучаться вопросами «сложный ли был баг или нет, правильно ли оценили время или нет».
Правило тоже самое: хороший сотрудник экономит время начальника. Плохой сотрудник — тратит время начальника.
Возможно, где-то это и работает, даже интересно как. Какая по факту нагрузка на руководителя, как решаются вышеуказанные проблемы.
У меня метод простой. Дал задачу — вперёд. Через день (неделю, смотря как я занят) нет результата, разбираемся вместе. Может там реально жутко сложная задача и надо не ругать программиста, не долбить его сроками, а помочь её решить.
Со стороны управления. Независимо от точки зрения программиста и руководителя.
Когда человека обвиняют в том, что не является его ответственностью и не было оговорено заранее, когда вводят критерии качества работы, которые от человека не зависят, когда человек занимается фиг пойми чем, потому что ему разрешили, а потом ему за это предъявляют претензии, это неграмотное управление.
Вы почему-то считаете что я обвиняю программиста в том, что к примеру, клиенты не похвалили его работу… Это совершенно не так. Если воспитанник спортивной школы не стал чемпионом мира, его в этом не обвиняют, его скорее похвалят за то, что стал чемпионом района (программист быстро и качественно решил задачу). Вы обвиняете программистов, если они сорвали сроки? Я — нет. Я обвиняю программистов только в одном случае: если я сделал их работу лучше чем они. К сожалению, с новыми программистами это случалось десятки раз. Даю задачу, они делают неделю, еще две постоянно правят баги, в итоге жуткие тормоза и баги всё равно идут. Лезу в код — там всё жутко сложно. Меняю код на простой и быстрый. Замеряю потраченное мной время. Три дня.
И здесь я обвиняю программиста. Обвиняю постфактум, проверив все детали.
Что касается разговоров о рефакторинге, или «продумывании структуры классов» — это это маркеры плохих программистов. Это как отмаза опоздавшего таксиста «надо было на заправку съездить». Хорошие программисты делают рефакторинг и продумывают классы часто и делают это быстро. Для них это рутина, а не повод оправдать отсутствие результата.
— вот бизнес ставит задачу X, программист ее делает без багов, а продажи это не увеличивает. В итоге виноват программист?
Вы верно ставите вопрос. Причем учитываем, что может быть 1000 разных функций, а покупать будут лишь при совокупности их, поэтому оценить вклад конкретного программиста в продажи очень сложно, почти невозможно.
Поэтому очень полезно оценить насколько клиенты пользуются тем, что сделал программист. На самом деле программист делает работу не для начальника и даже не для своей фирмы, он делает это для клиентов. Кстати, если программист адекватный, то ему самому будет приятно, если его работу используют. А если его работу хвалят клиенты — это точно круче, чем похвала начальника.
Обычно программист делает много разных функций. И если мы сравниваем двух программистов, которые сделали по 50 разных функций и работу одного хвалят клиенты, а работу другого игнорят или ругают, то можно делать выводы:) Или вы считаете что начальник — должен быть главным супер-пупер экспертом? Это же ошибка руководства. Начальник не должен быть объективным оценщиком, он имеет полное право разбираться в работе подчиненных меньше, чем они сами.
— вот бизнес ставит задачу Y, программист смотрит на нее и говорит, что продаж от нее не будет, и смысла ее делать нет. Что тогда делаете? Отменяете ее?
Это точно поднимает авторитет программиста. Он смотрит на задачу с точки зрения клиента и предлагает варианты. Круто! Я точно выслушаю все доводы и даже если я не соглашусь и потребую выполнения задачи, мне как руководителю будет приятно, что программист беспокоится о результате. Думает не только о том, что ему скажу я, а о том, как это повлияет на бизнес.
Все сроки и проводимые работы согласовываются перед началом работ.
Вы точно программист?
В 90% сложных случаев я не могу указать сроки. Если задача простая, то я могу сделать так:
1. оцениваю, что я бы сделал это за 3 часа плюс столько же на отладку после тестов.
2. скажу менеджеру, который занимается с клиентом, что делать примерно неделю.
3. менеджер «от себя» накинет ещё неделю, итого две недели. В итоге если программист не справился, у меня всегда есть время подстраховать.
А если задача сложная — как вышеуказанные «чтение из gerber или битрикс»?
Какие работы я могу согласовать, какие сроки? Никто не знает ни того ни другого даже приблизительно! Это чистый RND. Чтобы мне приблизительно назвать сроки, мне нужно сесть и сразу начать изучать и программировать ( мне так проще, я сразу пишу код для проверки гипотез и главных проблемных частей проекта). В итоге когда более-менее я смогу назвать сроки и из чего будет состоять проект, мне будет проще самому его и доделать, так как самое главное в управлении — время — было потрачено моё а не программиста.
Программист не влияет на продажи и оценки, программист делает то, что ему сказал бизнес. Организовать продажи это ответственность бизнеса.
Много раз встречал таких программистов. Идеология «я — гений. разжуйте мне пожалуйста, не буду же я ваши битриксы-шмитриксы открывать, мне задачу дайте!» Для него нужен некий «слуга», который сможет во всём разобраться и описать ему задачу в деталях. Если этим слугой должен быть его непосредственный начальник, то снова те же грабли: вместо того, чтобы экономить время руководителя, такой программист тратит время руководителя, заставляя его не просто сделать задачу, но ещё и объяснять её данному горе-программисту. Я таких увольняю быстро. Мне нужны люди, которые не испугаются слова «salesforce», который они никогда ранее не слышали, сами найдут документацию и разберутся что к чему.
Если вы не хотите выполнять работу по контролю программистов, значит нанимаете человека, который будет этим заниматься, которому будете доверять в этих вопросах.
Да, я работаю только с теми, кому доверяю. Мне не нужны люди, работающие из под палки, лучше я уволю 80% персонала (примерно так и выходит) и оставлю самостоятельных и умных людей, чем буду тратить своё время на то чтобы объяснить программисту элементарные для меня, вещи.
Вот тут и заметен недостаток управления. Поставивший задачу не разбирается в проблеме,
В 90% случаев ни руководитель ни программист при постановке задачи не разбираются в ней. Естественно. Программист всегда делает новое, это не копание картофеля и не укладка плитки. Каждая задача уникальна и время на её качественный контроль сопоставимо с временем решения задачи. Мне проще дать задачу и заплатить за месяц работы программиста. Пусть делает «как видит». А после оценить — получилось или нет. Нет — до свидания.
выполняющий задачу не имеет свободы действий в принятии решений.
100% свобода действий. Понятно, что есть code rules, есть примеры хорошего кода (если к примеру Delphi, то это исходники самого Delphi — смотри и делай также).
Если вы изначально не написали в ТЗ требования к скорости, значит делаете другое ТЗ
ТЗ: добавить чтение сделок битрикса из портала xx.bitrix24.ru — логин и пароль прилагается.
всё! если нужно еще что-то добавить, то мне такой программист не нужен. Моё время дороже времени программиста. Вот если программист мне скажет — а я еще jira заодно прикручу — вот будет хороший программист.
Потому что может быть так, что это битрикс так медленно работает, и ничего тут не сделать.
Можно сделать. Дать другому программисту или самому почитать документацию, написать вопрос в поддержку битрикса (увы не все программисты пользуются такими банальными вещами). И ускорить чтение в 10 — 20 раз. А если это проблема на стороне битрикса, значит «добить» битрикс поддержку, чтобы признали проблему и поставили в список для решения. Работать нужно комплексно а не в стиле «мне дали задачу добавить кнопку расчета рабочего времени и я добавил. А зачем она нужна клиентам и как быстро это должно работать меня не касается, это начальника пущай думать. а мне денежку выдавать»
Почему вы даете задания программисту на реализацию функционала, которым клиент не будет пользоваться? Вы приняли решение сделать функционал, который не нужен клиенту, после реализации оказалось, что он действительно не нужен клиенту, а виноват в этом программист.
Частый пример: я даю задачу программисту, пока он её делает, клиент уже сливается (может ответить «нам больше не надо, мы передумали»). Задача при этом выполнена и может пригодиться другим клиентам. При этом обратную связь от первого уже не получить, поэтому функционал вливаем «как мы понимаем». Если он влит плохо, неудобно для клиента — то пользоваться им не будут.
Вот тут и заметен недостаток управления.
Недостаток с какой стороны? С точки зрения программиста, которого уволили или с точки зрения руководителя, который оставил себе таких сотрудников, которым он доверяет и которые экономят его время?
Как показала моя практика — надо давать сотрудникам максимальную свободу, пусть проявляют свои лучшие качества. В такой схеме 80% скорее проявят свои плохие качества — правило Парето 80/20. 80% увольняем, оставляем 20% и радуемся работе с профессионалами!
Делать «то, что можно пощупать» не является критерием качества работы программиста. Это просто факт, следующий из специфики программирования.
Эх, сколько раз мне попадались программисты, у которых этот «факт» шёл не сильно далее «hello world», сделанного с использованием функций-параметров и прочих атрибутов, за которыми скрывалось плохое понимание ООП и в целом программирования. Под пониманием я говорю не о знании технологий, а о методах их правильного использования. (крутейшая книга на эту тему – Гради Буч)
значит фиговый из вас программист
Хотелось бы, чтобы я, как руководитель, маркетолог, специалист с опытом прямых продаж в разные страны, разбирался в программировании хуже моих подчинённых, от которых кроме программирования ничего не требуется:)
«Рефакторинг ради рефакторинга как показала моя практика почти всегда был ухудшением кода.»
Либо у вас просто недостаточно компетенции, чтобы оценить пользу. Это в мировой практике случалось столько раз, что даже имеет свое название «эффект Даннинга — Крюгера».
Пользу рефакторинга не отрицаю. Более того — никто из программистов, с которыми я работал не занимался им так часто, как я. Около сотни раз я полностью переделывал код (по сути этот метод и называют сейчас «аджайл» — метод быстрых проб и ошибок).
Другое дело, что рефакторинг — это классическая уловка программистов. «Прежний код ужасен, я делаю его отличным, занимаюсь рефакторингом, и скоро Вы увидите кнопку X, ещё немного подождите» — скажет такой программист после месяца-другого работы.
Почему оплата труда программиста зависит от критериев, на которые он повлиять не может, и которые не связаны с его основной работой?
Положительный отзыв должен быть ровно один — от вас «задачу принимаю».
В общем последнее верно — главное решение за мной и именно от меня зависит зарплата программиста. Но как я приму решение? Что мне поможет? И как программисту донести, что мне нужно на самом деле? Мне нужен крутой код? Задача, выполненная в срок? Интерфейсы? Нет — мне нужны продажи! А продажи — это оценка клиентами работы программиста.
Почему вы даете задания программисту на реализацию функционала, которым клиент не пользуется?
А зачем делать функционал, которым клиент уже пользуется?:) Конечно, программисты делают то, что ещё никто не видел. И если функционал сделают плохо, то клиенты увидят и мимо пройдут.
То есть вы не дали программисту никакого задания, весь год его не контролировали, а потом оказалось, что он виноват
Конечно, если программист косячит, то я как руководитель виноват, это же я его взял на работу и я несу за него ответственность.
Использую простую система оценки эффективности сотрудников, неважно программисты или любые другие: чем больше моего времени сотрудник экономит, тем лучше. Чем больше моего времени сотрудник забирает, тем он хуже.
Я даю задачу: вот файл формата гербер, нужно его визуализировать. Или вот портал Битрикс, нужно прочитать оттуда данные. Ни, я ни программист понятия не имеют что такое гербер или битрикс — задача пришла от клиентов и надо изучать. Могу ли я изучить и написать детальное ТЗ? Конечно, могу. Потратив на это время. Но мне и нужен сотрудник, чтобы не я, а он сделал эту задачу, сэкономив моё время. Нелегко контролировать выполнение задачи, в которой я ничего не смыслю, поэтому да — периодически «упускаю» работу программистов и это мой косяк. Признаю 100%.
Качество работы программиста заключается в том, сколько времени и багов пройдет до достижения соответствия ТЗ, что и проверяют тестировщики.
А если ТЗ не достигнуто или мне не нравится, например, скорость, с которой идет чтение данных того же гербер или битрикс? ТЗ формально выполнено, но скорость такая, что пользоваться невозможно.
У меня есть «железный» метод проверки, правда времязатратный. Например — даю задачу программисту, он делает её месяц. Далее тьма багов, которые он правит еще месяц. В результате баги ещё идут, алгоритм работает медленно. Я чувствую неладное. Я не могу ругать программиста, так как не разбираюсь в проблеме. Что делать? Я начинаю делать данную задачу сам. Трачу неделю, делаю всё с нуля, вместо 5000 строк от программиста мне хватает одной тысячи, скорость увеличиваю в 10 раз. Задача решена, фактически рефакторинг проведён. Всё хорошо. Но я — потратил время и это огромный минус в карму программиста. Зачем мне нужен человек, за которого я делаю работу. Один раз можно, но при рецидиве — увольнение.
эффективность с точки зрения хабра это придерживание популярной точки зрения и отсутствия собственного мнения как такого
Вы озвучили моё предположение:)
Если так, давайте подумаем, как сделать лучше, как решить этот «баг», как изменить алгоритм?
Кармы-рейтинги позволяют убрать троллей, флуд, снизить количество глупых или некомпетентных постов. Я читаю посты к этой теме, сравниваю, предположим, с обычнми комментариями в ютубе и вижу, что задача решена — все комментарии сделаны явно грамотными и образованными людьми, имеющими определённые знания в данном вопросе.
Как сделать, чтобы люди, имеющие непопуляное мнение, не попали «под нож» алгоритма? Тем более, что наличие конструктивной дискуссии полезно для любого СМИ.
Как программист я думаю и… не знаю как решить эту проблему:) Как отличить «собственное мнение» от «некомпетентности», используя лишь полностью автоматизированные алгоритмы?
Я могу быть офигительным работником, но опаздывать на 5 минут каждый день. И мне это простят.
Никаких противоречий нет, я как раз про это и говорю. Правда, привык быть не тем, кого «прощают», а скорее тем, кто прощает:)
Я как раз против любых штрафов. Я против премий, в которых учитываются сложные алгоритмы, включая те же опоздания.
Опаздывает хороший сотрудник на 5, 10, 15 минут… ок. Не проблема. Опаздывает на час и другие, не такие хорошие сотрудники — берут пример. Это уже плохо. Это убивает корпоративную культуру.
Можно использовать много общих метрик, в итоге сотрудники будут знать, на что руководство обращает внимание. Например, два сотрудника занимаются продажами, один продаёт корпоративными клиентами, а другой частным. Понятно, что у первого суммы продаж будут выше, и «единым мерилом» их не измерить. В этом и суть. Невозможно сделать справедливые kpi (не беру простые физические работы).
И спасают тут kpi «условные», когда метрики есть, они важны, но… нет прямой алгоритмической связи между ними и зарплатой.
Начальник решает, что зп у Иванова будет 10 монет, а у Петрова 11 монет. Несмотря на то, что у Иванова почти все показатели лучше, но начальник понимает, что официальные kpi не идеальны, а Петров реально более профессионален и опытен. Затем надо оценить Сидорова, начальник его работу знает плохо. Что делать? Смотреть на показатели. Плохая система расчёта kpi лучше, чем полное отсутствие.
Другой момент: если премии зависят только от kpi, то снижается авторитет руководителя. Он просит сотрудника «сделай задачу X», а сотрудник думает «я потрачу время на X, это ухудшит мои показатели, мне понизят зарплату». И постарается поставленную задачу отложить или сделать быстро и плохо, лишь бы отвязались. А если зарплата в итоге зависит от мнения руководителя, где kpi — лишь помощь, то сотрудник сделает задачу X исключительно хорошо.
А ваш программист утверждал, что его важная и полезная работа заключается в количестве нового функционала и функций, по которым есть обратная связь от клиентов? Я что-то сомневаюсь.
Хорошие программисты показывали функционал. Где я мог нажать на кнопки и сказать «круто!!».
По плохим программистам приходилось подолгу ждать пока их «супекрутые новые технологии» придут в вид, который можно «пощупать».
Почему тогда эти числа были выбраны как оценка важности работы программиста?
Потому что так рекомендовано в книге «Бизнес с нуля» Эрика Риса. Её мне рекомендовали, когда был в ФРИИ. Классная книга, является современной классикой бизнеса. Рекомендую.
Посмотрим, как Вы запоете, когда минусы пробьют отметки -10...-20...-30 и отвечать Вы уже не сможете
А это будет… идеальным ответом на вопрос, потавленный в статье!
Тема статьи:
«Что делать с неэффективным сотрудником, который считает, что он отлично справляется»
Я являюсь типичным примером — считаю что отлично справляюсь, а с точки зрения хабра неэффективен.
И ответ прост — уволить! С точки зрения habr — снизить рейтинг до уровня «бана».
И либо они будут эбьюзить эту систему (нажимая кнопочку начала работы пораньше и удалённо), либо забьют. Ну, какая мне беда с того, что меня вывесят на доску позора? Премию срежут?
Из нашей практики. Сделали клиенту на монитор в офисе вывод показателей по просроченным сделкам. 7 худших отметили красным, а всего там около 100 менеджеров. Первый раз мы вывесили это утром, в тестовом режиме, никому ничего не поясняя, никаких премий штрафов никто за это не обещал.
Итог: в тот же день количество просрочек уменьшилось вдвое. Не руководители объясняли менеджерам «почему опять… сколько раз говорить… и т.д. » а сами менеджеры забегали. Худшие, самые апатичные менеджеры неожиданно проявили дикую активность.
Люди ценят хорошее отношение и никто не хочет быть крайним. Это как борьба за предпоследние места в спортивных лигах — никто не хочет вылететь, все работают на полную.
А если кому-то всё равно на это, то зачем такой сотрудник нужен? Вспомните Apple, Google, Amazon — среднее время работы не более трёх лет. Не надо держать тех, кого надо гнать.
Это даже хорошо — позволяет оценить методы управления сотрудниками с разных сторон.
Если представить, что мои посты — это «работа для хабра», где я являюсь «сотрудником», то вот что я могу подумать Как сотрудник
Я считаю, что низкие оценки — это несправедливо.
Как же так, я двадцать лет в теме, я лично назначал премии сотрудникам, лично слушал их жалобы «почему в этом месяце премия меньше, чем в том?», «почему в премии оценили проект X и не оценили проект Y?”, «что конкретно я должен сделать, чтобы получить премию??», бесконечные недовольства зарплатой, которую все считали несправедливой, ужасную корпоративную среду, которую можно было назвать «тихим бунтом». И я с этой проблемой правился. Обратился к специалистам, сходил на курсы управления, изучил литературу, особенно понравились статьи гарвардской школы бизнеса, слушал ted.com. В итоге принял ряд решений, убравших недовольства, повысивших уровень мотивации и корпоративной культуры, и главное – на порядок снизивших нагрузку на меня как на руководителя.
А сейчас мне ставят только минусы, ни одного плюса – это же несправедливо, неприятно… Хотя я делюсь реальным опытом, как я наступал на грабли и как решал проблемы, причём ничего действительно необычного и спорного в моих методах не было – просто научный подход и всё.
При этом к руководителям хабра у меня нет неприятных эмоций – да они создали эту систему, где мне ставят минусы, но они изначально «сняли с себя ответственность», указав, что оценки субъективны. Так что никаких претензий. Как руководитель
Я восхищаюсь автоматизацией и «самонастройкой управления», которую сделали на хабре (Wikipedia и некоторых других ресурсах). Какие бы ни были причины отрицательных оценок – они есть и это мои проблемы, а не проблемы руководителей! Может я плохо выражаю свои мысли и знания, может мои мысли идут в разрез с тем, как принято у других «сотрудников» хабра – это в целом не так важно, система не должна быть идеальной, она должна быть рабочей. И это habr удалось. И я хочу себе в компании настроить подобное «автоматическое» управление.
Обратите внимание – как сотрудник я не испытываю недовольство «начальством» в лице руководителей habr – а это само по себе огромный плюс такого вида «цифровой» мотивации.
в какой-то момент подчиненным не нужен будет руководитель
В самую точку! Руководитель — это организатор и чем лучше он организует работу, тем меньше он работает сам. Идеальный руководитель вообще не работает!
На практике лучшие руководители включаются в работу для того, чтобы решить конкретные проблемы, выходящие за рамки имеющихся бизнес-процессов, и правильным будет не решение конкретной ситуации, а решение улучшение бизнес-процессов в общем виде.
Пример: ряд сотрудников опаздывают на работу, никаких штрафов за это не предусмотрено. Руководитель вместо того, чтобы поругать опоздавших словами или деньгами, добавляет новый показатель для аналитики (которая идет по ТВ в офисе, рассылается всем на емайл, или вывешивается на доску) — где считаем баллы опазданий для трёх последних опоздавших (даже если опаздывает 100 человек — выделяем трёх худших, для психологии). Получается «доска позора». Никаких штрафов и премий не назначается, обычно «доски позора» достаточно. Это ни что иное как классическое наказание, в отличие от запрещённых по КЗОТ штрафов.
Один раз решив проблему, руководитель более к ней не возвращается.
В статье не хватает главного — конкретных зарплат рабочих, цитата из Forbes:
Выпускникам инженерных факультетов обещали платить 21 000 рупий в месяц, но их зарплата снизилась до 16 000 рупий, а в последние месяцы и до 12 000 рупий. Месячная зарплата сотрудников, не имевших инженерного образования, снизилась до 8000 рупий», — цитировало The Times of India одного из сотрудников фабрики.
Сегодняшний курс рупии к рублю = один к одному, то есть это фактически зарплаты в рублях.
Вот на таких «огромных» зарплатах сэкономили, при том что капитализация Apple составляет 2 трлн долларов или 146 631 000 000 000 рублей. 146,6 триллионов:)
Производственные и бытовые задачи не требуют создания универсального ИИ.
Скорее так: конкретные шаблонные, часто встречающиеся задачи проще решить через специализированные технологии. Проще сделать за 10 млн долларов робота, который прикручивает двери к автомобилям и это экономически выгодно, чем потратить 10 млрд на универсального робота, которого можно научить ставить те же двери, но и на обучение надо потратиться.
Проще — не значит лучше.
Когда-то у нас был телефон для разговоров, калькулятор для расчётов, фотоаппарат для съёмок, компьютер для интернета… а теперь всё внутри телефона. Так удобнее, хотя уместить всё в одном сложнее.
Безусловно именно универсальные роботы , которых можно будет научить различным работам — это важное направление развития ближайшего будущего. Купили робота, а далее либо покупаем для него программы либо сами учим — и суп варить и цветы поливать и плитку укладывать. Робот один — задач бесконечно много. Как с компьютером.
Ну тогда давайте платить программистам за звезды на гитхабе.
Общая идея — да, такая.
Но
1. звёзды, кармы, рейтинги прорабатывают для каждого бизнеса исходя из его особенностей. Не все программисты что-то выкладывают на гитхаб плюс оценка программистов должна включать оценку от «непрограммистов»: клиенты, техписатели, тестировщики.
2. также как на хабре — удобно иметь не одну, а набор оценок: обратная связь от клиентов, сколько функций описали техписатели и т.д. — разные цифры, так удобнее.
3.
Платить
— платить лучше исходя из субъективного мнения руководителя, на которое влияют те самые цифровые показатели. Плюс они мотивируют сотрудника их увелививать даже если руководитель о них молчит и даже не смотрит. Так как показатели видят все в компании, это сильнейший пример нематериальной мотивации. Например, руководители habr ничего не знают о моём рейтинге, хотя меня он мотивирует:) то есть я как «сотрудник» мотивирован, хотя «начальство» в виде руководителей хабра не потратило конкретно на меня ни секунды!
Как руководитель я восхищаюсь системой рейтингов хабра. И выстраиваю подобные рейтинги в своей компании и клиентам.
Начальник либо должен сам разбираться в технических аспектах работы программиста
Здесь мне повезло, я сам программист и меня «дженериками не запруфишь». Удивительно, но всегда, когда программист вместо того, чтобы показать мне новый функционал или ускорение предыдущего начинал рассказывать про «интефрейсы и рефакторинг», то почти ВСЕГДА — это был просто косяк программиста. Что выяснялось после, когда я влезал в детали был в шоке от бесполезных наворотов, которые наваяли такие «говоруны».
Обычно тестировщики, даже бесконечно далекие от архитектуры программирования, хорошо понимают, какой программист хороший, а какой плохой. Потому что они видят РЕЗУЛЬТАТ.
Вы похоже мало разбираетесь в технических аспектах
20 лет опыта программирования и управления программистами, общения с клиентами, тестирования, продаж программ в десятки стран…
При этом если он не успевает, это не значит, что он медленно работает, надо узнавать причины
ДА ДА ДА. Поэтому оценить работу программиста, который работет 1 месяц — тяжело. А вот если в годовом отчете программист пишет, что основное время он занимался РЕФАКТОРИНГОМ, то это «звоночек». Тут есть смысл ПОТРАТИТЬ ДОРОГОЕ ВРЕМЯ РУКОВОДИТЕЛЯ, вникнуть в детали этого рефакторинга. Сколько раз в моей практике этот рефакторинг оказывался мусорным усложнением прежней плохой архитектуры…
За полгода-год обычно набирается практика и понятно, хороший это программист или нет.
«количество функций, по которым была ОБРАТНАЯ СВЯЗЬ ОТ КЛИЕНТОВ»
А если клиенты не захотели оставить обратную связь, то все, программист значит не работал?
Программист работал и получил зарплату. А ещё он хочет премию и повышения зп и должности и вот здесь возникает данный показатель: есть ли положительные отзывы по твоему функционалу?? нет — увы… ждём. Положительным отзывом мы считаем не только «спасибо», любое подтверждение, что функционалом пользуется клиент.
И неважно, что клиенты этим функционалом пользуются, и никто не жалуется,
Если функционалом пользуются и он нравится, то ЖАЛОБЫ БУДУТ!!:)) или хотя-бы вопросы. А вот если функционал — сильно плох или непонятен, то жалоб не будет, обратной связи не будет.
А кроме реализации новых функций есть такая штука как рефакторинг. Она помогает в ускорении реализации следующих новых функций и в улучшении их качества (меньше багов). Она очень важна для проекта, но по обоим вашим показателям здесь 0.
Рефакторинг ради рефакторинга как показала моя практика почти всегда был ухудшением кода.
Сам я постоянно занимаюсь рефакторингом, ядро код нашей последней программы перепиывал раз десять, полностью меняя архитектуру классов важнейших модулей. И всегда я ставил и достигал конкретной цели, понятной пользовтелям. Примеры таких целей на выходе рефакторинга:
— ускорение
— новый фунционал, почти невозможный в прежней архитектуре
— новые настройки
(Цифры легко накручиваются, в итоге может стать только хуже, чем просто при субъективной оценке.)
Отличный пример цифровых оценок — habr. На сайте сразу написано, что оценки не всегда объективные, зато система крайне эффективна. Руководители habr ничего не делают с конкретными пользователями, при этом меняют алгоритмы, добавляют рейтинги и кармы, чтобы В ОБЩЕМ ВИДЕ решить обьективно-неразрешимую задачу оценки. Тот же подход используют поисковики и соцсети, и сейчас он всё более популярен в бизнесе, читаем статьи на тему "нематериальная мотивация"
Начальник: программист, когда закончишь функционал X?
Программист: уже многое сделано, использование интерфейсов дженериков показатело свою эффективность, а новый хелпер можно использовать для задач y, z, а внедренные классы-проперти… и тд "ля-ля" на полчаса
Начальник: тестировщик, ты смотрел фукционал X?
Тестировщик: Да, смотрел. Постоянно описываю проблемы.
Нач- тебе нравится этот X?
Тестер — идея хорошая, но реализация..
Посмотрите на проблему с точки зрения НАЧАЛЬНИКА. Он обычный человек, если он постарается все оценить "по справедливости ", влезая во все детали, он больше ничего не будет делать, и то его не хватит, и справедливости он не достигнет.
Кстати, это другой полезный общий показатель: чем меньше начальник влезает в детали работы подчинённого, тем лучше подчинённый выполнил свою работу. Он СЭКОНОМИЛ ВРЕМЯ руководителя.
Если от цифр зависят премии и штрафы, то их будут накручивать. Поэтому денежные kpi опасны (часто полезны, но опасны). А если мы просто выводим по каждому сотруднику набор показателей, где он где-то впереди, а где-то позади (часто зависит от специализации сотрудника), то проблем нет. Если мои подчинённые будут "накручивать " себе положительные оценки реальных клиентов — я не против:)
Главное здесь не обьективность оценки.
Главное:
Повышение эффективности сотрудников
Снижение сложности и обьема работы руководителя. Подчинённые должны ЭКОНОМИТЬ время руководителя, а не РАСХОДОВАТЬ его на попытки справедливых оценок.
Я и так знаю кто и что делает. Согласования в большинстве задач просто не нужны. Нужно доверять людям.
Похвала клиентов — это критерий качества. Но если похвалы нет, это не повод к обвинениям. Программист — не мелкий винтик в системе, программист — это обычный человек, способный разбираться в самых различных вопроса. Я не раз встречал и поощрал программистов, которые сами ставили себе задачи, сами их выполняли, сами общались с клиентами. Это одни из самых эффективных сотрудников. Таким не надо «ставить задачу», они сами поставят кому угодно задачу и будут правы. Что я делал? Просто доверял и всё. И основная проверка качества — как раз продажи клиентам.
Я не настаиваю, что этот метод подойдёт всем, но мне понравилось.
А если программист работает хорошо, но никак «не лезет» в общение с клиентами — пожалуйста. Это ему не в плюс, но и ругать его за это никто не будет.
На эту тему могу говорить вечно:) наболело…
Например, дана задача — запрограммировать кошку, которая мяукает.
Я пишу класс «кошка», добавляю в него нужные свойства и методы.
Плохой программист сделает сразу «на будущее» — классы млекопитающее -> кошачьи -> кошка. Отдельно будет класс, посвящённый мяуканию.
Далее приходит уточняюща задача — добавить машинку. Оказалось, что кошка — плюшевая, а машинка — пластмассовая.
Я меняю класссы
класс игрушка — от неё наследую пластмассовая и плюшевая, от них кошку и машинку. То есть я делаю полный рефакторинг.
Плохой программист подумает «ну нифигаш себе… не могли сволочи сразу пояснить что к чему » и он будет «решать» проблему либо:
— наследует машинку от кошки (самый быстрый метод достичь решения ТЗ)
— сделает вообще отдельный класс «машинка», никак не связанный с кошкой
— или еще что-нибудь.
главное — плохой программист оставит ошибочные классы, такие как «млекопетающее». Как раз этот плохой программист после будет говорить про «важность продумывания рефакторинга», хотя при правильной работе рефакторинг будет выполнен быстрее, чем разговоры о нём.
при дальнейших изменения ТЗ (добавить подарочные наборы из нескольких уже описанных игрушек) у плохого программиста всё усугубляется. У хорошего — кода всегда меньше. Хороший программист не «думает о будущем», не мусорит код, при этом он быстро меняет алгоритмы исходя из меняющегося настоящего. У него нет ничего лишнего. Я уже не говорю о названиях. Смотрю на код VCL / FMX Delphi и «читаю» его как книгу без документации. Всё просто и понятно. Так пишут профи. Смотрю на код горе-программистов в стиле KoefValue := MosArr.Add(MyList) и думаю… так я понял слово List — список… отлично. Больше пока ничего неясно. Через полчаса изучений оказываеся, что List — это «лист» бумаги на русском языке. Конечно, для новичков есть правила, читают выполняют. Но лишние усложнения там, где они не нужны — это «бич» многих начинающих.
p.s. весной я заменил код программистов (достаточно хороших) примерно 50К строк на 5К строк. Выкинул тьму «высокотехнологичных» наворотов вроде тех же хелперов/интерфейсов/фукнций как параметров, классов-менеджеров и много другого, заменил всё «простой и банальной» архитекурой ООП. Вместо прежних сложных наворотов и классов-менеджеров для работы с разными типами данных ( integer/double/string..) сделал классы для каждого типа (класс TInteger, TDouble… с наследованием от общего типа) с удобной обработкой каждого типа внутри этих классов. Итог: скорость обработки данных выросла в 5 раз, скорость восприятия кода в 10 раз (хотя бы потому что самого кода стало в 10 раз меньше).
Статья мне понравилась.
Есть ещё психологический приём:
Если руководитель сомневается в эффективности сотрудника, он должен задать себе вопрос: "как бы я поступил с этим сотрудником, если бы он пришёл устраиваться на работу?"
Проходит месяц, рефакторинг не закончен. Программист говорит «очень сложный был код, не успеваю, нужно ещё пару недель». Через две недели тоже самое. Ваша реакция? Какие санкции вводить?
— На самом деле разговоры, подобные описанному Вами, у меня идут часто, но это неофициальное согласование сроков. Еще чаще я даю задачи вообще не указывая никаких сроков. Всё на доверии.
Я пробовал такой метод с формальными сроками однажды, мне не понравилось. Вот почему:
1. Очень сложно оценить время, особенно если это баги. Пару недель назад я решил примерно 10 багов, 9 из них за 5 часов, а 10й — за три дня. А на первый взгляд они все были похожие. Никогда бы не подумал, что придётся три дня заниматься с вроде бы простой проблемой. Меня как программиста за это как накажут?
2. непонятно, что делать, если программист просрочил задачу. Если это хороший программист, и были объективные причины. Просто простить? Если да, то в чём смысл согласований? А если реально накосячил программист, какие санкции будут применены? Какие будут доказательства его вины? Программист после такого просто будет стараться всегда завышать сроки.
3. большинство даже самых классных программистов абсолютно не умеют оценивать сроки. Поэтому, доверяя программистам я не доверяю срокам, которые они говорят.
4. обязательно появятся программисты, которые будут просить огромные сроки для элементарных задач. Почему бы и нет? Вы им не доверяете, почему программист должен доверять Вам? И вместо обсуждения того, как делать проект, идёт убивание времени на то, сколько времени его делать.
5. Лишние формальности — лишняя нагрузка на руководителя. Это само по себе управленческая ошибка. Руководитель должен стремиться к тому, чтобы делегировать задачи, а не мучаться вопросами «сложный ли был баг или нет, правильно ли оценили время или нет».
Правило тоже самое: хороший сотрудник экономит время начальника. Плохой сотрудник — тратит время начальника.
Возможно, где-то это и работает, даже интересно как. Какая по факту нагрузка на руководителя, как решаются вышеуказанные проблемы.
У меня метод простой. Дал задачу — вперёд. Через день (неделю, смотря как я занят) нет результата, разбираемся вместе. Может там реально жутко сложная задача и надо не ругать программиста, не долбить его сроками, а помочь её решить.
Вы почему-то считаете что я обвиняю программиста в том, что к примеру, клиенты не похвалили его работу… Это совершенно не так. Если воспитанник спортивной школы не стал чемпионом мира, его в этом не обвиняют, его скорее похвалят за то, что стал чемпионом района (программист быстро и качественно решил задачу).
Вы обвиняете программистов, если они сорвали сроки? Я — нет. Я обвиняю программистов только в одном случае: если я сделал их работу лучше чем они. К сожалению, с новыми программистами это случалось десятки раз. Даю задачу, они делают неделю, еще две постоянно правят баги, в итоге жуткие тормоза и баги всё равно идут. Лезу в код — там всё жутко сложно. Меняю код на простой и быстрый. Замеряю потраченное мной время. Три дня.
И здесь я обвиняю программиста. Обвиняю постфактум, проверив все детали.
Что касается разговоров о рефакторинге, или «продумывании структуры классов» — это это маркеры плохих программистов. Это как отмаза опоздавшего таксиста «надо было на заправку съездить». Хорошие программисты делают рефакторинг и продумывают классы часто и делают это быстро. Для них это рутина, а не повод оправдать отсутствие результата.
Вы верно ставите вопрос. Причем учитываем, что может быть 1000 разных функций, а покупать будут лишь при совокупности их, поэтому оценить вклад конкретного программиста в продажи очень сложно, почти невозможно.
Поэтому очень полезно оценить насколько клиенты пользуются тем, что сделал программист. На самом деле программист делает работу не для начальника и даже не для своей фирмы, он делает это для клиентов. Кстати, если программист адекватный, то ему самому будет приятно, если его работу используют. А если его работу хвалят клиенты — это точно круче, чем похвала начальника.
Обычно программист делает много разных функций. И если мы сравниваем двух программистов, которые сделали по 50 разных функций и работу одного хвалят клиенты, а работу другого игнорят или ругают, то можно делать выводы:) Или вы считаете что начальник — должен быть главным супер-пупер экспертом? Это же ошибка руководства. Начальник не должен быть объективным оценщиком, он имеет полное право разбираться в работе подчиненных меньше, чем они сами.
Это точно поднимает авторитет программиста. Он смотрит на задачу с точки зрения клиента и предлагает варианты. Круто! Я точно выслушаю все доводы и даже если я не соглашусь и потребую выполнения задачи, мне как руководителю будет приятно, что программист беспокоится о результате. Думает не только о том, что ему скажу я, а о том, как это повлияет на бизнес.
Вы точно программист?
В 90% сложных случаев я не могу указать сроки. Если задача простая, то я могу сделать так:
1. оцениваю, что я бы сделал это за 3 часа плюс столько же на отладку после тестов.
2. скажу менеджеру, который занимается с клиентом, что делать примерно неделю.
3. менеджер «от себя» накинет ещё неделю, итого две недели. В итоге если программист не справился, у меня всегда есть время подстраховать.
А если задача сложная — как вышеуказанные «чтение из gerber или битрикс»?
Какие работы я могу согласовать, какие сроки? Никто не знает ни того ни другого даже приблизительно! Это чистый RND. Чтобы мне приблизительно назвать сроки, мне нужно сесть и сразу начать изучать и программировать ( мне так проще, я сразу пишу код для проверки гипотез и главных проблемных частей проекта). В итоге когда более-менее я смогу назвать сроки и из чего будет состоять проект, мне будет проще самому его и доделать, так как самое главное в управлении — время — было потрачено моё а не программиста.
Много раз встречал таких программистов. Идеология «я — гений. разжуйте мне пожалуйста, не буду же я ваши битриксы-шмитриксы открывать, мне задачу дайте!» Для него нужен некий «слуга», который сможет во всём разобраться и описать ему задачу в деталях. Если этим слугой должен быть его непосредственный начальник, то снова те же грабли: вместо того, чтобы экономить время руководителя, такой программист тратит время руководителя, заставляя его не просто сделать задачу, но ещё и объяснять её данному горе-программисту. Я таких увольняю быстро. Мне нужны люди, которые не испугаются слова «salesforce», который они никогда ранее не слышали, сами найдут документацию и разберутся что к чему.
Да, я работаю только с теми, кому доверяю. Мне не нужны люди, работающие из под палки, лучше я уволю 80% персонала (примерно так и выходит) и оставлю самостоятельных и умных людей, чем буду тратить своё время на то чтобы объяснить программисту элементарные для меня, вещи.
В 90% случаев ни руководитель ни программист при постановке задачи не разбираются в ней. Естественно. Программист всегда делает новое, это не копание картофеля и не укладка плитки. Каждая задача уникальна и время на её качественный контроль сопоставимо с временем решения задачи. Мне проще дать задачу и заплатить за месяц работы программиста. Пусть делает «как видит». А после оценить — получилось или нет. Нет — до свидания.
100% свобода действий. Понятно, что есть code rules, есть примеры хорошего кода (если к примеру Delphi, то это исходники самого Delphi — смотри и делай также).
ТЗ: добавить чтение сделок битрикса из портала xx.bitrix24.ru — логин и пароль прилагается.
всё! если нужно еще что-то добавить, то мне такой программист не нужен. Моё время дороже времени программиста. Вот если программист мне скажет — а я еще jira заодно прикручу — вот будет хороший программист.
Можно сделать. Дать другому программисту или самому почитать документацию, написать вопрос в поддержку битрикса (увы не все программисты пользуются такими банальными вещами). И ускорить чтение в 10 — 20 раз. А если это проблема на стороне битрикса, значит «добить» битрикс поддержку, чтобы признали проблему и поставили в список для решения. Работать нужно комплексно а не в стиле «мне дали задачу добавить кнопку расчета рабочего времени и я добавил. А зачем она нужна клиентам и как быстро это должно работать меня не касается, это начальника пущай думать. а мне денежку выдавать»
Частый пример: я даю задачу программисту, пока он её делает, клиент уже сливается (может ответить «нам больше не надо, мы передумали»). Задача при этом выполнена и может пригодиться другим клиентам. При этом обратную связь от первого уже не получить, поэтому функционал вливаем «как мы понимаем». Если он влит плохо, неудобно для клиента — то пользоваться им не будут.
Недостаток с какой стороны? С точки зрения программиста, которого уволили или с точки зрения руководителя, который оставил себе таких сотрудников, которым он доверяет и которые экономят его время?
Как показала моя практика — надо давать сотрудникам максимальную свободу, пусть проявляют свои лучшие качества. В такой схеме 80% скорее проявят свои плохие качества — правило Парето 80/20. 80% увольняем, оставляем 20% и радуемся работе с профессионалами!
Эх, сколько раз мне попадались программисты, у которых этот «факт» шёл не сильно далее «hello world», сделанного с использованием функций-параметров и прочих атрибутов, за которыми скрывалось плохое понимание ООП и в целом программирования. Под пониманием я говорю не о знании технологий, а о методах их правильного использования. (крутейшая книга на эту тему – Гради Буч)
Хотелось бы, чтобы я, как руководитель, маркетолог, специалист с опытом прямых продаж в разные страны, разбирался в программировании хуже моих подчинённых, от которых кроме программирования ничего не требуется:)
Пользу рефакторинга не отрицаю. Более того — никто из программистов, с которыми я работал не занимался им так часто, как я. Около сотни раз я полностью переделывал код (по сути этот метод и называют сейчас «аджайл» — метод быстрых проб и ошибок).
Другое дело, что рефакторинг — это классическая уловка программистов. «Прежний код ужасен, я делаю его отличным, занимаюсь рефакторингом, и скоро Вы увидите кнопку X, ещё немного подождите» — скажет такой программист после месяца-другого работы.
В общем последнее верно — главное решение за мной и именно от меня зависит зарплата программиста. Но как я приму решение? Что мне поможет? И как программисту донести, что мне нужно на самом деле? Мне нужен крутой код? Задача, выполненная в срок? Интерфейсы? Нет — мне нужны продажи! А продажи — это оценка клиентами работы программиста.
А зачем делать функционал, которым клиент уже пользуется?:) Конечно, программисты делают то, что ещё никто не видел. И если функционал сделают плохо, то клиенты увидят и мимо пройдут.
Конечно, если программист косячит, то я как руководитель виноват, это же я его взял на работу и я несу за него ответственность.
Использую простую система оценки эффективности сотрудников, неважно программисты или любые другие:
чем больше моего времени сотрудник экономит, тем лучше. Чем больше моего времени сотрудник забирает, тем он хуже.
Я даю задачу: вот файл формата гербер, нужно его визуализировать. Или вот портал Битрикс, нужно прочитать оттуда данные. Ни, я ни программист понятия не имеют что такое гербер или битрикс — задача пришла от клиентов и надо изучать. Могу ли я изучить и написать детальное ТЗ? Конечно, могу. Потратив на это время. Но мне и нужен сотрудник, чтобы не я, а он сделал эту задачу, сэкономив моё время. Нелегко контролировать выполнение задачи, в которой я ничего не смыслю, поэтому да — периодически «упускаю» работу программистов и это мой косяк. Признаю 100%.
А если ТЗ не достигнуто или мне не нравится, например, скорость, с которой идет чтение данных того же гербер или битрикс? ТЗ формально выполнено, но скорость такая, что пользоваться невозможно.
У меня есть «железный» метод проверки, правда времязатратный. Например — даю задачу программисту, он делает её месяц. Далее тьма багов, которые он правит еще месяц. В результате баги ещё идут, алгоритм работает медленно. Я чувствую неладное. Я не могу ругать программиста, так как не разбираюсь в проблеме. Что делать? Я начинаю делать данную задачу сам. Трачу неделю, делаю всё с нуля, вместо 5000 строк от программиста мне хватает одной тысячи, скорость увеличиваю в 10 раз. Задача решена, фактически рефакторинг проведён. Всё хорошо. Но я — потратил время и это огромный минус в карму программиста. Зачем мне нужен человек, за которого я делаю работу. Один раз можно, но при рецидиве — увольнение.
Вы озвучили моё предположение:)
Если так, давайте подумаем, как сделать лучше, как решить этот «баг», как изменить алгоритм?
Кармы-рейтинги позволяют убрать троллей, флуд, снизить количество глупых или некомпетентных постов. Я читаю посты к этой теме, сравниваю, предположим, с обычнми комментариями в ютубе и вижу, что задача решена — все комментарии сделаны явно грамотными и образованными людьми, имеющими определённые знания в данном вопросе.
Как сделать, чтобы люди, имеющие непопуляное мнение, не попали «под нож» алгоритма? Тем более, что наличие конструктивной дискуссии полезно для любого СМИ.
Как программист я думаю и… не знаю как решить эту проблему:) Как отличить «собственное мнение» от «некомпетентности», используя лишь полностью автоматизированные алгоритмы?
Никаких противоречий нет, я как раз про это и говорю. Правда, привык быть не тем, кого «прощают», а скорее тем, кто прощает:)
Я как раз против любых штрафов. Я против премий, в которых учитываются сложные алгоритмы, включая те же опоздания.
Опаздывает хороший сотрудник на 5, 10, 15 минут… ок. Не проблема. Опаздывает на час и другие, не такие хорошие сотрудники — берут пример. Это уже плохо. Это убивает корпоративную культуру.
Можно использовать много общих метрик, в итоге сотрудники будут знать, на что руководство обращает внимание. Например, два сотрудника занимаются продажами, один продаёт корпоративными клиентами, а другой частным. Понятно, что у первого суммы продаж будут выше, и «единым мерилом» их не измерить. В этом и суть. Невозможно сделать справедливые kpi (не беру простые физические работы).
И спасают тут kpi «условные», когда метрики есть, они важны, но… нет прямой алгоритмической связи между ними и зарплатой.
Начальник решает, что зп у Иванова будет 10 монет, а у Петрова 11 монет. Несмотря на то, что у Иванова почти все показатели лучше, но начальник понимает, что официальные kpi не идеальны, а Петров реально более профессионален и опытен. Затем надо оценить Сидорова, начальник его работу знает плохо. Что делать? Смотреть на показатели. Плохая система расчёта kpi лучше, чем полное отсутствие.
Другой момент: если премии зависят только от kpi, то снижается авторитет руководителя. Он просит сотрудника «сделай задачу X», а сотрудник думает «я потрачу время на X, это ухудшит мои показатели, мне понизят зарплату». И постарается поставленную задачу отложить или сделать быстро и плохо, лишь бы отвязались. А если зарплата в итоге зависит от мнения руководителя, где kpi — лишь помощь, то сотрудник сделает задачу X исключительно хорошо.
Хорошие программисты показывали функционал. Где я мог нажать на кнопки и сказать «круто!!».
По плохим программистам приходилось подолгу ждать пока их «супекрутые новые технологии» придут в вид, который можно «пощупать».
Потому что так рекомендовано в книге «Бизнес с нуля» Эрика Риса. Её мне рекомендовали, когда был в ФРИИ. Классная книга, является современной классикой бизнеса. Рекомендую.
А это будет… идеальным ответом на вопрос, потавленный в статье!
Тема статьи:
«Что делать с неэффективным сотрудником, который считает, что он отлично справляется»
Я являюсь типичным примером — считаю что отлично справляюсь, а с точки зрения хабра неэффективен.
И ответ прост — уволить! С точки зрения habr — снизить рейтинг до уровня «бана».
Из нашей практики. Сделали клиенту на монитор в офисе вывод показателей по просроченным сделкам. 7 худших отметили красным, а всего там около 100 менеджеров. Первый раз мы вывесили это утром, в тестовом режиме, никому ничего не поясняя, никаких премий штрафов никто за это не обещал.
Итог: в тот же день количество просрочек уменьшилось вдвое. Не руководители объясняли менеджерам «почему опять… сколько раз говорить… и т.д. » а сами менеджеры забегали. Худшие, самые апатичные менеджеры неожиданно проявили дикую активность.
Люди ценят хорошее отношение и никто не хочет быть крайним. Это как борьба за предпоследние места в спортивных лигах — никто не хочет вылететь, все работают на полную.
А если кому-то всё равно на это, то зачем такой сотрудник нужен? Вспомните Apple, Google, Amazon — среднее время работы не более трёх лет. Не надо держать тех, кого надо гнать.
Это даже хорошо — позволяет оценить методы управления сотрудниками с разных сторон.
Если представить, что мои посты — это «работа для хабра», где я являюсь «сотрудником», то вот что я могу подумать
Как сотрудник
Я считаю, что низкие оценки — это несправедливо.
Как же так, я двадцать лет в теме, я лично назначал премии сотрудникам, лично слушал их жалобы «почему в этом месяце премия меньше, чем в том?», «почему в премии оценили проект X и не оценили проект Y?”, «что конкретно я должен сделать, чтобы получить премию??», бесконечные недовольства зарплатой, которую все считали несправедливой, ужасную корпоративную среду, которую можно было назвать «тихим бунтом». И я с этой проблемой правился. Обратился к специалистам, сходил на курсы управления, изучил литературу, особенно понравились статьи гарвардской школы бизнеса, слушал ted.com. В итоге принял ряд решений, убравших недовольства, повысивших уровень мотивации и корпоративной культуры, и главное – на порядок снизивших нагрузку на меня как на руководителя.
А сейчас мне ставят только минусы, ни одного плюса – это же несправедливо, неприятно… Хотя я делюсь реальным опытом, как я наступал на грабли и как решал проблемы, причём ничего действительно необычного и спорного в моих методах не было – просто научный подход и всё.
При этом к руководителям хабра у меня нет неприятных эмоций – да они создали эту систему, где мне ставят минусы, но они изначально «сняли с себя ответственность», указав, что оценки субъективны. Так что никаких претензий.
Как руководитель
Я восхищаюсь автоматизацией и «самонастройкой управления», которую сделали на хабре (Wikipedia и некоторых других ресурсах). Какие бы ни были причины отрицательных оценок – они есть и это мои проблемы, а не проблемы руководителей! Может я плохо выражаю свои мысли и знания, может мои мысли идут в разрез с тем, как принято у других «сотрудников» хабра – это в целом не так важно, система не должна быть идеальной, она должна быть рабочей. И это habr удалось. И я хочу себе в компании настроить подобное «автоматическое» управление.
Обратите внимание – как сотрудник я не испытываю недовольство «начальством» в лице руководителей habr – а это само по себе огромный плюс такого вида «цифровой» мотивации.
В самую точку!
Руководитель — это организатор и чем лучше он организует работу, тем меньше он работает сам. Идеальный руководитель вообще не работает!
На практике лучшие руководители включаются в работу для того, чтобы решить конкретные проблемы, выходящие за рамки имеющихся бизнес-процессов, и правильным будет не решение конкретной ситуации, а решение улучшение бизнес-процессов в общем виде.
Пример: ряд сотрудников опаздывают на работу, никаких штрафов за это не предусмотрено. Руководитель вместо того, чтобы поругать опоздавших словами или деньгами, добавляет новый показатель для аналитики (которая идет по ТВ в офисе, рассылается всем на емайл, или вывешивается на доску) — где считаем баллы опазданий для трёх последних опоздавших (даже если опаздывает 100 человек — выделяем трёх худших, для психологии). Получается «доска позора». Никаких штрафов и премий не назначается, обычно «доски позора» достаточно. Это ни что иное как классическое наказание, в отличие от запрещённых по КЗОТ штрафов.
Один раз решив проблему, руководитель более к ней не возвращается.
Сегодняшний курс рупии к рублю = один к одному, то есть это фактически зарплаты в рублях.
Вот на таких «огромных» зарплатах сэкономили, при том что капитализация Apple составляет 2 трлн долларов или 146 631 000 000 000 рублей. 146,6 триллионов:)
Скорее так: конкретные шаблонные, часто встречающиеся задачи проще решить через специализированные технологии. Проще сделать за 10 млн долларов робота, который прикручивает двери к автомобилям и это экономически выгодно, чем потратить 10 млрд на универсального робота, которого можно научить ставить те же двери, но и на обучение надо потратиться.
Проще — не значит лучше.
Когда-то у нас был телефон для разговоров, калькулятор для расчётов, фотоаппарат для съёмок, компьютер для интернета… а теперь всё внутри телефона. Так удобнее, хотя уместить всё в одном сложнее.
Безусловно именно универсальные роботы , которых можно будет научить различным работам — это важное направление развития ближайшего будущего. Купили робота, а далее либо покупаем для него программы либо сами учим — и суп варить и цветы поливать и плитку укладывать. Робот один — задач бесконечно много. Как с компьютером.
Общая идея — да, такая.
Но
1. звёзды, кармы, рейтинги прорабатывают для каждого бизнеса исходя из его особенностей. Не все программисты что-то выкладывают на гитхаб плюс оценка программистов должна включать оценку от «непрограммистов»: клиенты, техписатели, тестировщики.
2. также как на хабре — удобно иметь не одну, а набор оценок: обратная связь от клиентов, сколько функций описали техписатели и т.д. — разные цифры, так удобнее.
3. — платить лучше исходя из субъективного мнения руководителя, на которое влияют те самые цифровые показатели. Плюс они мотивируют сотрудника их увелививать даже если руководитель о них молчит и даже не смотрит. Так как показатели видят все в компании, это сильнейший пример нематериальной мотивации. Например, руководители habr ничего не знают о моём рейтинге, хотя меня он мотивирует:) то есть я как «сотрудник» мотивирован, хотя «начальство» в виде руководителей хабра не потратило конкретно на меня ни секунды!
Как руководитель я восхищаюсь системой рейтингов хабра. И выстраиваю подобные рейтинги в своей компании и клиентам.
Здесь мне повезло, я сам программист и меня «дженериками не запруфишь». Удивительно, но всегда, когда программист вместо того, чтобы показать мне новый функционал или ускорение предыдущего начинал рассказывать про «интефрейсы и рефакторинг», то почти ВСЕГДА — это был просто косяк программиста. Что выяснялось после, когда я влезал в детали был в шоке от бесполезных наворотов, которые наваяли такие «говоруны».
Обычно тестировщики, даже бесконечно далекие от архитектуры программирования, хорошо понимают, какой программист хороший, а какой плохой. Потому что они видят РЕЗУЛЬТАТ.
20 лет опыта программирования и управления программистами, общения с клиентами, тестирования, продаж программ в десятки стран…
ДА ДА ДА. Поэтому оценить работу программиста, который работет 1 месяц — тяжело. А вот если в годовом отчете программист пишет, что основное время он занимался РЕФАКТОРИНГОМ, то это «звоночек». Тут есть смысл ПОТРАТИТЬ ДОРОГОЕ ВРЕМЯ РУКОВОДИТЕЛЯ, вникнуть в детали этого рефакторинга. Сколько раз в моей практике этот рефакторинг оказывался мусорным усложнением прежней плохой архитектуры…
За полгода-год обычно набирается практика и понятно, хороший это программист или нет.
Программист работал и получил зарплату. А ещё он хочет премию и повышения зп и должности и вот здесь возникает данный показатель: есть ли положительные отзывы по твоему функционалу?? нет — увы… ждём. Положительным отзывом мы считаем не только «спасибо», любое подтверждение, что функционалом пользуется клиент.
Если функционалом пользуются и он нравится, то ЖАЛОБЫ БУДУТ!!:)) или хотя-бы вопросы. А вот если функционал — сильно плох или непонятен, то жалоб не будет, обратной связи не будет.
Рефакторинг ради рефакторинга как показала моя практика почти всегда был ухудшением кода.
Сам я постоянно занимаюсь рефакторингом, ядро код нашей последней программы перепиывал раз десять, полностью меняя архитектуру классов важнейших модулей. И всегда я ставил и достигал конкретной цели, понятной пользовтелям. Примеры таких целей на выходе рефакторинга:
— ускорение
— новый фунционал, почти невозможный в прежней архитектуре
— новые настройки
(Цифры легко накручиваются, в итоге может стать только хуже, чем просто при субъективной оценке.)
Отличный пример цифровых оценок — habr. На сайте сразу написано, что оценки не всегда объективные, зато система крайне эффективна. Руководители habr ничего не делают с конкретными пользователями, при этом меняют алгоритмы, добавляют рейтинги и кармы, чтобы В ОБЩЕМ ВИДЕ решить обьективно-неразрешимую задачу оценки. Тот же подход используют поисковики и соцсети, и сейчас он всё более популярен в бизнесе, читаем статьи на тему "нематериальная мотивация"
Типичный диалог
Начальник: программист, когда закончишь функционал X?
Программист: уже многое сделано, использование интерфейсов дженериков показатело свою эффективность, а новый хелпер можно использовать для задач y, z, а внедренные классы-проперти… и тд "ля-ля" на полчаса
Начальник: тестировщик, ты смотрел фукционал X?
Тестировщик: Да, смотрел. Постоянно описываю проблемы.
Нач- тебе нравится этот X?
Тестер — идея хорошая, но реализация..
Посмотрите на проблему с точки зрения НАЧАЛЬНИКА. Он обычный человек, если он постарается все оценить "по справедливости ", влезая во все детали, он больше ничего не будет делать, и то его не хватит, и справедливости он не достигнет.
Кстати, это другой полезный общий показатель: чем меньше начальник влезает в детали работы подчинённого, тем лучше подчинённый выполнил свою работу. Он СЭКОНОМИЛ ВРЕМЯ руководителя.
Если от цифр зависят премии и штрафы, то их будут накручивать. Поэтому денежные kpi опасны (часто полезны, но опасны). А если мы просто выводим по каждому сотруднику набор показателей, где он где-то впереди, а где-то позади (часто зависит от специализации сотрудника), то проблем нет. Если мои подчинённые будут "накручивать " себе положительные оценки реальных клиентов — я не против:)
Главное здесь не обьективность оценки.
Главное: