Комментарии 52
Понравился эвфемизм "его пришлось отпустить". Прямо детство вспомнилось, фильм "Коммандос" со Шварцнеггером:
– Что ты сделал с Салли?
– Я его отпустил.
На мой взгляд наиболее частая проблема это крайне не компетентный менеджер который не может оценить работу сотрудников и делает это в силу своих знаний по принципу кто ему лучше втерся в доверии и соответсвует его субьекивныйм целям и ожиданиям.
Хороший руководитель, увидев проблему, переведёт проблему в ЧИСЛО и это число само "накажет" плохого сотрудника.
Пример: есть программист, утверждающий, что он делает бесконечно важную, полезную и грандиозную работу. Руководитель не видит достаточных для него результатов, но это ведь "субъектив", который програмиист с радостью "объяснит" рассказами о суперновых примененных им технологиях.
Как я это исправлял?
Вводил числа:
- количество нового ОПИСАННОГО функционала
- количество функций, по которым была ОБРАТНАЯ СВЯЗЬ ОТ КЛИЕНТОВ
и всё… никаких споров не надо.
Если новые функции сданы и описаны, то можно обсудить их с техписателем, у него более объективный взгляд, он погружён в детали. По сути, руководитель ДЕЛЕГИРУЕТ оценку программиста техписателям и клиентам.
Другой пример: менеджер по продажам продал двум крупным клиентам и доволен- план выполнен, всё хорошо. А руководитель видит, что менеджер откровенно забил на всех остальных клиентов. Решение: считать конверсию в продажи в процентах, увидеть ЦИФРУ. И если она низкая, то менеджера надо НАКАЗАТЬ.
Как НАКАЗАТЬ?
Да просто распечатайте на стену или высылайте каждому на почту таблицы таких показателей. Без ЛИЧНОЙ оценки каждого. Наказание здесь — это оценка КОЛЛЕГ, которые увидят чужие оцифрованные косяки.
Одно дело — оправдаться перед начальником, и другое — защитить авторитет в коллективе, где все видят цифры проблемного менеджера.
Цифры легко накручиваются, в итоге может стать только хуже, чем просто при субъективной оценке.
(Цифры легко накручиваются, в итоге может стать только хуже, чем просто при субъективной оценке.)
Отличный пример цифровых оценок — habr. На сайте сразу написано, что оценки не всегда объективные, зато система крайне эффективна. Руководители habr ничего не делают с конкретными пользователями, при этом меняют алгоритмы, добавляют рейтинги и кармы, чтобы В ОБЩЕМ ВИДЕ решить обьективно-неразрешимую задачу оценки. Тот же подход используют поисковики и соцсети, и сейчас он всё более популярен в бизнесе, читаем статьи на тему "нематериальная мотивация"
Ну тогда давайте платить программистам за звезды на гитхабе.
Ну тогда давайте платить программистам за звезды на гитхабе.
Общая идея — да, такая.
Но
1. звёзды, кармы, рейтинги прорабатывают для каждого бизнеса исходя из его особенностей. Не все программисты что-то выкладывают на гитхаб плюс оценка программистов должна включать оценку от «непрограммистов»: клиенты, техписатели, тестировщики.
2. также как на хабре — удобно иметь не одну, а набор оценок: обратная связь от клиентов, сколько функций описали техписатели и т.д. — разные цифры, так удобнее.
3.
Платить— платить лучше исходя из субъективного мнения руководителя, на которое влияют те самые цифровые показатели. Плюс они мотивируют сотрудника их увелививать даже если руководитель о них молчит и даже не смотрит. Так как показатели видят все в компании, это сильнейший пример нематериальной мотивации. Например, руководители habr ничего не знают о моём рейтинге, хотя меня он мотивирует:) то есть я как «сотрудник» мотивирован, хотя «начальство» в виде руководителей хабра не потратило конкретно на меня ни секунды!
Как руководитель я восхищаюсь системой рейтингов хабра. И выстраиваю подобные рейтинги в своей компании и клиентам.
вам насыпали мотивирующих минусов в карму
Это даже хорошо — позволяет оценить методы управления сотрудниками с разных сторон.
Если представить, что мои посты — это «работа для хабра», где я являюсь «сотрудником», то вот что я могу подумать
Как сотрудник
Я считаю, что низкие оценки — это несправедливо.
Как же так, я двадцать лет в теме, я лично назначал премии сотрудникам, лично слушал их жалобы «почему в этом месяце премия меньше, чем в том?», «почему в премии оценили проект X и не оценили проект Y?”, «что конкретно я должен сделать, чтобы получить премию??», бесконечные недовольства зарплатой, которую все считали несправедливой, ужасную корпоративную среду, которую можно было назвать «тихим бунтом». И я с этой проблемой правился. Обратился к специалистам, сходил на курсы управления, изучил литературу, особенно понравились статьи гарвардской школы бизнеса, слушал ted.com. В итоге принял ряд решений, убравших недовольства, повысивших уровень мотивации и корпоративной культуры, и главное – на порядок снизивших нагрузку на меня как на руководителя.
А сейчас мне ставят только минусы, ни одного плюса – это же несправедливо, неприятно… Хотя я делюсь реальным опытом, как я наступал на грабли и как решал проблемы, причём ничего действительно необычного и спорного в моих методах не было – просто научный подход и всё.
При этом к руководителям хабра у меня нет неприятных эмоций – да они создали эту систему, где мне ставят минусы, но они изначально «сняли с себя ответственность», указав, что оценки субъективны. Так что никаких претензий.
Как руководитель
Я восхищаюсь автоматизацией и «самонастройкой управления», которую сделали на хабре (Wikipedia и некоторых других ресурсах). Какие бы ни были причины отрицательных оценок – они есть и это мои проблемы, а не проблемы руководителей! Может я плохо выражаю свои мысли и знания, может мои мысли идут в разрез с тем, как принято у других «сотрудников» хабра – это в целом не так важно, система не должна быть идеальной, она должна быть рабочей. И это habr удалось. И я хочу себе в компании настроить подобное «автоматическое» управление.
Обратите внимание – как сотрудник я не испытываю недовольство «начальством» в лице руководителей habr – а это само по себе огромный плюс такого вида «цифровой» мотивации.
Обратите внимание – как сотрудник я не испытываю недовольство «начальством» в лице руководителей habr – а это само по себе огромный плюс такого вида «цифровой» мотивации.
Посмотрим, как Вы запоете, когда минусы пробьют отметки -10...-20...-30 и отвечать Вы уже не сможете
Это не к тому, что я к Вам испытываю негатив (или позитив). А очевидно, что Ваша модель поведения не соответствует чему-то за что Вам минусы и лепят
Посмотрим, как Вы запоете, когда минусы пробьют отметки -10...-20...-30 и отвечать Вы уже не сможете
А это будет… идеальным ответом на вопрос, потавленный в статье!
Тема статьи:
«Что делать с неэффективным сотрудником, который считает, что он отлично справляется»
Я являюсь типичным примером — считаю что отлично справляюсь, а с точки зрения хабра неэффективен.
И ответ прост — уволить! С точки зрения habr — снизить рейтинг до уровня «бана».
эффективность с точки зрения хабра это придерживание популярной точки зрения и отсутствия собственного мнения как такого
Вы озвучили моё предположение:)
Если так, давайте подумаем, как сделать лучше, как решить этот «баг», как изменить алгоритм?
Кармы-рейтинги позволяют убрать троллей, флуд, снизить количество глупых или некомпетентных постов. Я читаю посты к этой теме, сравниваю, предположим, с обычнми комментариями в ютубе и вижу, что задача решена — все комментарии сделаны явно грамотными и образованными людьми, имеющими определённые знания в данном вопросе.
Как сделать, чтобы люди, имеющие непопуляное мнение, не попали «под нож» алгоритма? Тем более, что наличие конструктивной дискуссии полезно для любого СМИ.
Как программист я думаю и… не знаю как решить эту проблему:) Как отличить «собственное мнение» от «некомпетентности», используя лишь полностью автоматизированные алгоритмы?
На сайте сразу написано, что оценки не всегда объективные, зато система крайне эффективна.
Я бы на вашем месте был бы предельно осторожен в оперировании словами а-ля "эффективно", когда речь идёт про, скажем, хаброкарму.
Про хаброкарму можно достоверно сказать только то, что она вообще работает. Как именно она работает и насколько хорошо — сказать совершенно определенно нельзя, так как сравнительные эксперименты никто никогда не проводил и не будет.
Возвращаясь к изначальной теме — это как раз отлично показывает проблему любого рода численных оценок, введенных исключительно для обоснования некоторой качественной гипотезы: какое число бы вы в итоге не получили, им можно будет обосновать любой вывод, который вы желаете сделать. Равно как и для хабра числом в карме можно обосновать и неадекватность и неуместность отдельных людей для хабра, и зашоренность и элитарность аудитории хабра — всё зависит только от того, что именно вы хотите обосновать.
есть программист, утверждающий, что он делает бесконечно важную, полезную и грандиозную работу.
Руководитель не видит достаточных для него результатов, но это ведь "субъектив"
Как я это исправлял?
Вводил числа:
количество нового ОПИСАННОГО функционала
количество функций, по которым была ОБРАТНАЯ СВЯЗЬ ОТ КЛИЕНТОВ
Но ведь это и есть "достаточные для руководителя результаты", то есть тот же самый субъектив. И числа, которые программист должен достичь, тоже задаются на основании субъективных предпочтений руководителя. Где тут исправление?
А ваш программист утверждал, что его важная и полезная работа заключается в количестве нового функционала и функций, по которым есть обратная связь от клиентов? Я что-то сомневаюсь. Почему тогда эти числа были выбраны как оценка важности работы программиста?
Типичный диалог
Начальник: программист, когда закончишь функционал X?
Программист: уже многое сделано, использование интерфейсов дженериков показатело свою эффективность, а новый хелпер можно использовать для задач y, z, а внедренные классы-проперти… и тд "ля-ля" на полчаса
Начальник: тестировщик, ты смотрел фукционал X?
Тестировщик: Да, смотрел. Постоянно описываю проблемы.
Нач- тебе нравится этот X?
Тестер — идея хорошая, но реализация..
Посмотрите на проблему с точки зрения НАЧАЛЬНИКА. Он обычный человек, если он постарается все оценить "по справедливости ", влезая во все детали, он больше ничего не будет делать, и то его не хватит, и справедливости он не достигнет.
Кстати, это другой полезный общий показатель: чем меньше начальник влезает в детали работы подчинённого, тем лучше подчинённый выполнил свою работу. Он СЭКОНОМИЛ ВРЕМЯ руководителя.
Он обычный человек, если он постарается все оценить "по справедливости ", влезая во все детали, он больше ничего не будет делать
Начальник либо должен сам разбираться в технических аспектах работы программиста, чтобы оценить его эффективность, либо нанять человека, которому он будет доверять в этих вопросах, например начальника IT-отдела.
Использование "интерфейсов дженериков и хелперов" для задач y, z это и есть основная часть работы программиста. Если вы в ней не разбираетесь, вы не сможете правильно оценить ее важность и полезность.
он больше ничего не будет делать
Это не значит, что надо вводить неправильные метрики, лишь бы что-то было.
Вы похоже мало разбираетесь в технических аспектах, давайте я подробнее объясню.
"количество нового ОПИСАННОГО функционала"
Этот показатель вообще не должен зависеть от программиста. Придумывать функционал должен бизнес. Он говорит программисту "нужен функционал X, Y, Z, в какие сроки можно реализовать", программист говорит "X, Y неделя, Z пока непонятно, надо изучить документацию библиотеки W, может быть там уже это есть". Критерий тут может быть только правильность оценки программиста. При этом если он не успевает, это не значит, что он медленно работает, надо узнавать причины. Возможно в библиотеке есть баг, на поиск которого ушло 2 дня. Нет, без библиотеки на этот функционал ушло бы 2 месяца.
"количество функций, по которым была ОБРАТНАЯ СВЯЗЬ ОТ КЛИЕНТОВ"
А если клиенты не захотели оставить обратную связь, то все, программист значит не работал? И неважно, что клиенты этим функционалом пользуются, и никто не жалуется, никто спасибо не сказал, значит программист ничего не сделал, так что ли?
А кроме реализации новых функций есть такая штука как рефакторинг. Она помогает в ускорении реализации следующих новых функций и в улучшении их качества (меньше багов). Она очень важна для проекта, но по обоим вашим показателям здесь 0. Да, она как раз и заключается в вынесении "интерфейсов дженериков" и прочих подобных штуках. Также есть написание документации, тестов, изучение сторонних библиотек. Это все не влияет на ваши показатели или уменьшает их, но помогает в реализации следующих функций и при введении в проект новых программистов. Не факт, что ваш программист все это делает, но ваши оценки не становятся от этого более правильными.
Начальник либо должен сам разбираться в технических аспектах работы программиста
Здесь мне повезло, я сам программист и меня «дженериками не запруфишь». Удивительно, но всегда, когда программист вместо того, чтобы показать мне новый функционал или ускорение предыдущего начинал рассказывать про «интефрейсы и рефакторинг», то почти ВСЕГДА — это был просто косяк программиста. Что выяснялось после, когда я влезал в детали был в шоке от бесполезных наворотов, которые наваяли такие «говоруны».
Обычно тестировщики, даже бесконечно далекие от архитектуры программирования, хорошо понимают, какой программист хороший, а какой плохой. Потому что они видят РЕЗУЛЬТАТ.
Вы похоже мало разбираетесь в технических аспектах20 лет опыта программирования и управления программистами, общения с клиентами, тестирования, продаж программ в десятки стран…
При этом если он не успевает, это не значит, что он медленно работает, надо узнавать причиныДА ДА ДА. Поэтому оценить работу программиста, который работет 1 месяц — тяжело. А вот если в годовом отчете программист пишет, что основное время он занимался РЕФАКТОРИНГОМ, то это «звоночек». Тут есть смысл ПОТРАТИТЬ ДОРОГОЕ ВРЕМЯ РУКОВОДИТЕЛЯ, вникнуть в детали этого рефакторинга. Сколько раз в моей практике этот рефакторинг оказывался мусорным усложнением прежней плохой архитектуры…
За полгода-год обычно набирается практика и понятно, хороший это программист или нет.
«количество функций, по которым была ОБРАТНАЯ СВЯЗЬ ОТ КЛИЕНТОВ»
А если клиенты не захотели оставить обратную связь, то все, программист значит не работал?
Программист работал и получил зарплату. А ещё он хочет премию и повышения зп и должности и вот здесь возникает данный показатель: есть ли положительные отзывы по твоему функционалу?? нет — увы… ждём. Положительным отзывом мы считаем не только «спасибо», любое подтверждение, что функционалом пользуется клиент.
И неважно, что клиенты этим функционалом пользуются, и никто не жалуется,
Если функционалом пользуются и он нравится, то ЖАЛОБЫ БУДУТ!!:)) или хотя-бы вопросы. А вот если функционал — сильно плох или непонятен, то жалоб не будет, обратной связи не будет.
А кроме реализации новых функций есть такая штука как рефакторинг. Она помогает в ускорении реализации следующих новых функций и в улучшении их качества (меньше багов). Она очень важна для проекта, но по обоим вашим показателям здесь 0.
Рефакторинг ради рефакторинга как показала моя практика почти всегда был ухудшением кода.
Сам я постоянно занимаюсь рефакторингом, ядро код нашей последней программы перепиывал раз десять, полностью меняя архитектуру классов важнейших модулей. И всегда я ставил и достигал конкретной цели, понятной пользовтелям. Примеры таких целей на выходе рефакторинга:
— ускорение
— новый фунционал, почти невозможный в прежней архитектуре
— новые настройки
К сожалению, вынужден согласиться, что реальный мерилом эффективности может быть только тот код, который уже реально работает, а не этот вот бесконечный рефакторинг. Лучше код, хромающий на обе ноги, чем идеальный код, который при столкновении с реальностью сломается.
И это идёт очень хорошо с концепцией эджайл/девопс — это всего, когда команда ПОЛНОСТЬЮ ответственна за результат своей работы. Побочным эффектом может быть снижение качества продукта — я имею в вижу таких параметров, как обслуживаемость, модернизируемость НА ДОЛГОСРОКЕ. Потому что к моменту, когда понадобится новый функционал, может все поменяться ровно наоборот (внешняя среда очень изменчива, а заложить все необходимые точки расширения — очень дорого). Но при этом именно эти методики позволяют получать более качественный результат в среднем, чем без них. И это тоже понятно — идут более активные и полезные циклы обратной связи от стейкхолдеров и коррекция плана работ по ходу дела.
С излишней гибкостью кода можно облажаться только или непраильно поняв требования и/или «угадав» неподходящий набор паттернов. Тут лекарство просто в KISS пока нет опыта, а он появится если следовать как ниже.
Ведь рефакторинг нужен прежде всего чтобы частую задачу Х делать за Y времени(ценой рефакторинга в 5Y) а не за 2Y. А на типовых задач уже знаешь: щас вот опять кучу раз похожие апи запросы… вот тут гибкость и нужна. Ну и правило, что если появилась копипаста — то улучшаем гибкость из-за этого(если только предполагаем + скорее всего та задача достанется сокоманднику, то не надо, так как сокомандник может не увидеть). К сожалению — это опыт на java, где тяжело написать что-то мудреное настолько, чтобы рефакторить было дороже чем добавлять аналогичный функционал в середине или начале разработки.
Все плевки в сторону, что архитектура зло и т.п. обычно из-за непонимания, что существует такая точка зрения. При таком подходе можно любую абстракцию превратить в реальность быстро, если клюнет жаренный петух. Кстати маркер — для такого подхода можно делать ветку для быстрого релиза с частью костылей, которые не мерджить в будущие версии. Правда маркер не сработает, если код заполняет хранилище с данными и их нужно перенести в будущие версии.
И как следствие — такой вопрос, а как оценивать тех кто работает в таком стиле? Вот один писал все абстракции, отдал любителю довести до конца. Кто из них справляется лучше, и кто ценный? Тот кто умеет писать абстракции ценный в этом плане, но эта ценность конечна, кто-то может забивать гвозди так быстро и эффективно, что будет ценней. Но где мера? И давайте не будем что процесс надо сделать менее эффективным, чтобы честнее оценивать.
Ну и ещё момент с гибкостью кода. god objects не нужны. Выносите все гибкие сами по себе детали из них в утилитные функции, хелперы и т.п. И когда требования поменяются на 180* переписываете только ту часть, которой нет в ваших хелперах. При таком подходе мне кажется риски и затраты балансны т.к. накладных затрат, кроме как вылизывать эти функции локально, и искать их при новых реализациях — нет.
Тут код может быть и лапшой и смешением стилей, но всегда есть компоненты, которые гибкие как кирпичи(из них можно всё построить) или как лом. Это ли не идеальный код? (здоровое значение термина)
А про эджайл — коллективной ответственности не существует. Можно требовать только текущих задач, и всё что я описал выше не будет работать, даже если требовать, так как выгоднее упорно не замечать гибкость где она есть, и приводить всякие выдуманные примеры, про то что если начать универсализировать какую-то хрень, которую в здравом уме не будешь — то всё будет очень плохо. Т.е. если вместо команды посадить одного человека, то чтобы как-то ускориться — он будет вынужден гибко писать код в этих же местах, если опыт позволяет осознать. Или если опять отказываемся от эджайла, где все взаимозаменяемые и даём людям в ответственнось свою область, очерчивая границы по очевидным границам компонентов. Т.е. процесс и опыт отдельных людей очень сильно влияет на оптимальность подхода. И чем больше людей втянуто в параллельную работу в одном месте, тем меньше суммарная эффективность.
А ваш программист утверждал, что его важная и полезная работа заключается в количестве нового функционала и функций, по которым есть обратная связь от клиентов? Я что-то сомневаюсь.
Хорошие программисты показывали функционал. Где я мог нажать на кнопки и сказать «круто!!».
По плохим программистам приходилось подолгу ждать пока их «супекрутые новые технологии» придут в вид, который можно «пощупать».
Почему тогда эти числа были выбраны как оценка важности работы программиста?
Потому что так рекомендовано в книге «Бизнес с нуля» Эрика Риса. Её мне рекомендовали, когда был в ФРИИ. Классная книга, является современной классикой бизнеса. Рекомендую.
Хорошие программисты показывали функционал. Где я мог нажать на кнопки и сказать «круто!!»
приходилось подолгу ждать пока их «супекрутые новые технологии» придут в вид, который можно «пощупать».
Здесь мне повезло, я сам программист и меня «дженериками не запруфишь»
20 лет опыта программирования
Что-то непохоже. Давайте я еще раз объясню, вы видимо не поняли, о чем написано в моем комментарии. Делать "то, что можно пощупать" не является критерием качества работы программиста. Это просто факт, следующий из специфики программирования. Из чего следует, что раз вы считаете это криетрием, значит фиговый из вас программист. Это подтверждается вашими комментариями и вашей статьей про ИИ.
А вот если в годовом отчете программист пишет, что основное время он занимался РЕФАКТОРИНГОМ, то это «звоночек».
Это звоночек некомпетентности руководителя этого программиста. Программист основное время должен заниматься тем, что ему сказал руководитель, что в конечном итоге сводится к задачам, которые ставит бизнес. Вы говорили ему, чем он должен заниматься? Из этой фразы следует, что нет. То есть вы не дали программисту никакого задания, весь год его не контролировали, а потом оказалось, что он виноват в том, что не угадал ваши мысли о том, какой должен быть результат.
Потому что они видят РЕЗУЛЬТАТ.
РЕЗУЛЬТАТ они должны видеть только тот, который в ТЗ. ТЗ должно исходить от бизнеса, то есть в данном случае от вас. Качество работы программиста заключается в том, сколько времени и багов пройдет до достижения соответствия ТЗ, что и проверяют тестировщики. То есть процесс, а не результат.
Тут есть смысл ПОТРАТИТЬ ДОРОГОЕ ВРЕМЯ РУКОВОДИТЕЛЯ
Давайте я и это еще раз объясню. Либо проверять программиста это ваша обязанность, либо вы нанимаете человека, которому ее делегируете и которому доверяете в этом вопросе. В обоих случаях время на это заложено в планирование, и выделен бюджет на оплату этого времени.
Что выяснялось после, когда я влезал в детали был в шоке от бесполезных наворотов, которые наваяли такие «говоруны».
Сколько раз в моей практике этот рефакторинг оказывался мусорным усложнением прежней плохой архитектуры…
Рефакторинг ради рефакторинга как показала моя практика почти всегда был ухудшением кода.
Либо у вас просто недостаточно компетенции, чтобы оценить пользу. Это в мировой практике случалось столько раз, что даже имеет свое название "эффект Даннинга — Крюгера".
Тем, у кого мало опыта, все эти интерфейсы, паттерны, и DI-контейнеры как раз и кажутся бесполезными наворотами.
А ещё он хочет премию и повышения зп и должности и вот здесь возникает данный показатель: есть ли положительные отзывы по твоему функционалу??
Почему оплата труда программиста зависит от критериев, на которые он повлиять не может, и которые не связаны с его основной работой?
Положительный отзыв должен быть ровно один — от вас "задачу принимаю".
Положительным отзывом мы считаем не только «спасибо», любое подтверждение, что функционалом пользуется клиент.
Почему вы даете задания программисту на реализацию функционала, которым клиент не пользуется?
И всегда я ставил и достигал конкретной цели, понятной пользовтелям.
Рефакторинг делается для целей, понятных программистам. Часть из них включают цели, которые пользователи могут оценить, часть нет. Потому что рефакторинг это понятие, которое применяется к коду и к управлению кодом. "Уменьшение числа багов при реализации нового функционала" это пример цели, которую пользователи оценить не могут.
Делать «то, что можно пощупать» не является критерием качества работы программиста. Это просто факт, следующий из специфики программирования.
Эх, сколько раз мне попадались программисты, у которых этот «факт» шёл не сильно далее «hello world», сделанного с использованием функций-параметров и прочих атрибутов, за которыми скрывалось плохое понимание ООП и в целом программирования. Под пониманием я говорю не о знании технологий, а о методах их правильного использования. (крутейшая книга на эту тему – Гради Буч)
значит фиговый из вас программист
Хотелось бы, чтобы я, как руководитель, маркетолог, специалист с опытом прямых продаж в разные страны, разбирался в программировании хуже моих подчинённых, от которых кроме программирования ничего не требуется:)
«Рефакторинг ради рефакторинга как показала моя практика почти всегда был ухудшением кода.»
Либо у вас просто недостаточно компетенции, чтобы оценить пользу. Это в мировой практике случалось столько раз, что даже имеет свое название «эффект Даннинга — Крюгера».
Пользу рефакторинга не отрицаю. Более того — никто из программистов, с которыми я работал не занимался им так часто, как я. Около сотни раз я полностью переделывал код (по сути этот метод и называют сейчас «аджайл» — метод быстрых проб и ошибок).
Другое дело, что рефакторинг — это классическая уловка программистов. «Прежний код ужасен, я делаю его отличным, занимаюсь рефакторингом, и скоро Вы увидите кнопку X, ещё немного подождите» — скажет такой программист после месяца-другого работы.
Почему оплата труда программиста зависит от критериев, на которые он повлиять не может, и которые не связаны с его основной работой?
Положительный отзыв должен быть ровно один — от вас «задачу принимаю».
В общем последнее верно — главное решение за мной и именно от меня зависит зарплата программиста. Но как я приму решение? Что мне поможет? И как программисту донести, что мне нужно на самом деле? Мне нужен крутой код? Задача, выполненная в срок? Интерфейсы? Нет — мне нужны продажи! А продажи — это оценка клиентами работы программиста.
Почему вы даете задания программисту на реализацию функционала, которым клиент не пользуется?
А зачем делать функционал, которым клиент уже пользуется?:) Конечно, программисты делают то, что ещё никто не видел. И если функционал сделают плохо, то клиенты увидят и мимо пройдут.
То есть вы не дали программисту никакого задания, весь год его не контролировали, а потом оказалось, что он виноват
Конечно, если программист косячит, то я как руководитель виноват, это же я его взял на работу и я несу за него ответственность.
Использую простую система оценки эффективности сотрудников, неважно программисты или любые другие:
чем больше моего времени сотрудник экономит, тем лучше. Чем больше моего времени сотрудник забирает, тем он хуже.
Я даю задачу: вот файл формата гербер, нужно его визуализировать. Или вот портал Битрикс, нужно прочитать оттуда данные. Ни, я ни программист понятия не имеют что такое гербер или битрикс — задача пришла от клиентов и надо изучать. Могу ли я изучить и написать детальное ТЗ? Конечно, могу. Потратив на это время. Но мне и нужен сотрудник, чтобы не я, а он сделал эту задачу, сэкономив моё время. Нелегко контролировать выполнение задачи, в которой я ничего не смыслю, поэтому да — периодически «упускаю» работу программистов и это мой косяк. Признаю 100%.
Качество работы программиста заключается в том, сколько времени и багов пройдет до достижения соответствия ТЗ, что и проверяют тестировщики.А если ТЗ не достигнуто или мне не нравится, например, скорость, с которой идет чтение данных того же гербер или битрикс? ТЗ формально выполнено, но скорость такая, что пользоваться невозможно.
У меня есть «железный» метод проверки, правда времязатратный. Например — даю задачу программисту, он делает её месяц. Далее тьма багов, которые он правит еще месяц. В результате баги ещё идут, алгоритм работает медленно. Я чувствую неладное. Я не могу ругать программиста, так как не разбираюсь в проблеме. Что делать? Я начинаю делать данную задачу сам. Трачу неделю, делаю всё с нуля, вместо 5000 строк от программиста мне хватает одной тысячи, скорость увеличиваю в 10 раз. Задача решена, фактически рефакторинг проведён. Всё хорошо. Но я — потратил время и это огромный минус в карму программиста. Зачем мне нужен человек, за которого я делаю работу. Один раз можно, но при рецидиве — увольнение.
Хотелось бы, чтобы я, как руководитель, маркетолог, специалист с опытом прямых продаж в разные страны, разбирался в программировании хуже моих подчинённых
20 лет опыта программирования и управления программистами, общения с клиентами, тестирования, продаж программ в десятки стран…
Ну вот насчет продаж верю, а насчет программирования нет. Факты в виде ваших комментариев говорят об обратном.
Потому что так рекомендовано в книге «Бизнес с нуля» Эрика Риса.
Книга платная, мне не удалось ознакомиться с текстом, но на Хабре есть краткое изложение.
Так вот, судя по тому, что там написано, это книга про стратапы, и указанные вами критерии это метрика успешности стартапа. То есть вас, как его директора. Эти метрики это показатель качества вашей работы, а не работы программиста. И нужны они в первую очередь для анализа ситуации, а не для мотивации сотрудников.
Другое дело, что рефакторинг — это классическая уловка программистов. «Прежний код ужасен, я делаю его отличным, занимаюсь рефакторингом, и скоро Вы увидите кнопку X, ещё немного подождите» — скажет такой программист после месяца-другого работы.
Вы действительно не понимаете, что я вам пишу. При правильном управлении вообще не должно быть такой ситуации, когда программист может так сказать. Все сроки и проводимые работы согласовываются перед началом работ. Если у вас нет начальника IT-отдела, то его обязанности должны выполнять либо вы, либо программист. Если вы хотите сами управлять работой программиста, то это от вас должна быть задача "сделаем рефакторинг, срок 1 месяц", а уже потом другая задача "сделаем кнопку X". Подчеркиваю — обе от вас. Если же вы предоставляете принятие таких решений программисту, значит не можете предъявлять претензии "почему ты делал рефакторинг". Он его делал, потому что решил, что это нужно для работы. В этом случае от вас должна быть одна задача "сделаем кнопку X, какие сроки решения", а от программиста ответ "2 месяца на рефакторинг, 2 дня на реализацию кнопки". Ситуация, когда проводившиеся 2 месяца работы по проекту являются новостью для кого-то заинтересованного, это признак неграмотного управления. Тем более в стартапе.
Но как я приму решение? Что мне поможет?
Я же написал — от вас должна быть задача программисту "делаем то-то". Поможет вам сравнение того, что сделал программист, с тем, что вы хотели получить.
И как программисту донести, что мне нужно на самом деле?
Написать текстом в задаче "делаем то-то".
Мне нужен крутой код? Задача, выполненная в срок? Интерфейсы? Нет — мне нужны продажи! А продажи — это оценка клиентами работы программиста.
Программист не влияет на продажи и оценки, программист делает то, что ему сказал бизнес. Организовать продажи это ответственность бизнеса.
любое подтверждение, что функционалом пользуется клиент.
Почему вы даете задания программисту на реализацию функционала, которым клиент не пользуется?
А зачем делать функционал, которым клиент уже пользуется?
Раз вы решили в буквоедство поиграть, переформулирую более точно.
Почему вы даете задания программисту на реализацию функционала, которым клиент не будет пользоваться? Вы приняли решение сделать функционал, который не нужен клиенту, после реализации оказалось, что он действительно не нужен клиенту, а виноват в этом программист.
Конечно, если программист косячит, то я как руководитель виноват, это же я его взял на работу и я несу за него ответственность.
Нет, я говорю не про это. Я говорю, что в описанном примере программист не косячит.
Но мне и нужен сотрудник, чтобы не я, а он сделал эту задачу, сэкономив моё время.
В этом случае вы предоставляете сотруднику полномочия самому определять, нужен рефакторинг или нет, и соответственно не можете предъявлять ему претензии по этому поводу.
Нелегко контролировать выполнение задачи, в которой я ничего не смыслю, поэтому да — периодически «упускаю» работу программистов и это мой косяк.
Ваш косяк в том, что вы не наняли человека, который будет контролировать работу программистов за вас, будет этим постоянно заниматься, и следовательно будет смыслить в задаче.
А если ТЗ не достигнуто или мне не нравится, например, скорость, с которой идет чтение данных того же гербер или битрикс? ТЗ формально выполнено, но скорость такая, что пользоваться невозможно.
Если вы изначально не написали в ТЗ требования к скорости, значит делаете другое ТЗ, где они будут. Итерации, agile, и все такое. В результате выполенения задачи программист должен либо увеличить скорость обработки данных, либо написать причину, почему это сделать невозможно. Потому что может быть так, что это битрикс так медленно работает, и ничего тут не сделать.
Но я — потратил время и это огромный минус в карму программиста. Зачем мне нужен человек, за которого я делаю работу.
Давайте я и в третий раз напишу. Если вы не хотите выполнять работу по контролю программистов, значит нанимаете человека, который будет этим заниматься, которому будете доверять в этих вопросах. Раз у вас есть только вы и программист, и вы этим не занимаетесь, значит вы делегировали эту обязанность самому программисту. Программист у вас контролирует сам себя. И следовательно вы не можете предъявлять ему претензии, так как сами разрешили ему так делать.
Например — даю задачу программисту
Я не могу ругать программиста, так как не разбираюсь в проблеме.
Вот тут и заметен недостаток управления. Поставивший задачу не разбирается в проблеме, выполняющий задачу не имеет свободы действий в принятии решений. Нужен человек, в котором объединяются эти ответственности — либо вы, либо программист, либо кто-то третий.
Все сроки и проводимые работы согласовываются перед началом работ.
Вы точно программист?
В 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% и радуемся работе с профессионалами!
Вы точно программист?
В 90% сложных случаев я не могу указать сроки.
Чтобы мне приблизительно назвать сроки
А вы точно читаете, что я пишу, или просто отдельные предложения выдергиваете для цитат?
"В этом случае от вас должна быть одна задача "сделаем кнопку X, какие сроки решения", а от программиста ответ "2 месяца на рефакторинг, 2 дня на реализацию кнопки"".
Слово "согласовываются" означает ровно то, что оно означает. Что обе стороны согласны с результатом обсуждения. Оно не означает, что вы должны задавать срок программисту, с которым он должен беспрекословно соглашаться.
оцениваю, что я бы сделал это за 3 часа
Какое значение имеет ваша оценка, если делать будете не вы?
Какие работы я могу согласовать, какие сроки? Никто не знает ни того ни другого даже приблизительно! Это чистый RND.
Слушайте, ну вы как маленький прямо, все вам надо объяснять. Хвалитесь всякими книжками, а того, что там написано, не знаете.
Вы даете задачу "Сделать чтение из битрикс". Спрашиваете:
— В какие сроки можно реализовать?
Программист говорит:
— Не знаю, я с ним не работал, надо изучить документацию
— Сколько надо времени на это?
— Не знаю точно, пусть будет 3 дня
Вы говорите:
— Хорошо
Через 3 дня спрашиваете:
— Что удалось узнать?
— Нашел документацию по организации обмена данными, со стороны битрикса надо сделать то-то и то-то, с нашей стороны то-то и то-то.
— В какие сроки можно реализовать?
— 2 месяца
— Почему так долго?
— Надо сначала сделать рефакторинг, у нас там весь код рассчитан только на ввод через интерфейс пользователя. Месяц на рефакторинг, 2 недели на реализацию чтения данных, 2 недели на проверку.
Вы говорите:
— Хорошо
Ситуации "скоро Вы увидите кнопку X, ещё немного подождите — скажет такой программист после месяца-другого работы" при таком подходе просто не возникает.
Если же вы не хотите разбираться с этими деталями, значит этим должен заниматься другой человек — начальник IT-отдела или какой-нибудь менеджер проекта. Он же должен и предъявлять претензии программисту, если он затягивает сроки или делает не то, что нужно для задачи. Если вы предоставляете эти полномочия самому программисту, то и претензии он может предъявлять только сам к себе.
Мне нужны люди, которые не испугаются слова «salesforce», который они никогда ранее не слышали, сами найдут документацию и разберутся что к чему.
Мне проще дать задачу и заплатить за месяц работы программиста. Пусть делает «как видит». А после оценить — получилось или нет.
Я уже несколько раз дал ответ на эту ситуацию. Если вы предоставляете программисту полномочия принимать такие решения, значит не можете предъявлять претензии, что он делал рефакторинг. Он принял решение, что для "salesforce" нужен рефакторинг, поэтому занимался рефакторингом. А вы сначала говорите "делай что хочешь", а потом "ты сделал не так, как мне надо".
Да, я работаю только с теми, кому доверяю.
100% свобода действий.
Нет. Если у вас претензии к тому, что человек 2 месяца делал рефакторинг, значит вы не доверяете ему в том, что это рефакторинг нужен.
Претензия "почему ты 2 месяца делал рефакторинг" это не 100% свобода действий.
ТЗ: добавить чтение сделок битрикса из портала xx.bitrix24.ru — логин и пароль прилагается.
всё!
И? Как это противоречит моей фразе, которую вы процитировали?
Работать нужно комплексно а не в стиле
Как это противоречит моей фразе, которую вы процитировали?
А зачем она нужна клиентам и как быстро это должно работать меня не касается, это начальника пущай думать
А вы предоставляете работникам долю в бизнесе? Если нет, тогда да, ваш бизнес их не касается. Они наемные работники, их дело выполнять работу по найму. Развитие бизнеса — это не работа программиста, для этого другие специалисты есть. И я сильно сомневаюсь, что эти обязанности у вас прописаны в договоре с программистами.
Частый пример: я даю задачу программисту, пока он её делает, клиент уже сливается (может ответить «нам больше не надо, мы передумали»)
Вот, тут мы как раз и подбираемся к сути. Задачу дали вы, передумал клиент, а виноват почему-то программист. Результат работы соответствует требованиям, которые вы написали в задаче? Да. Будьте добры оплатить работу. Да, даже если она больше никому не нужна. Да, и на принятие решений о премиях, повышении зп и должности ненужность работы тоже не должна влиять. Потому что это не вина программиста, что вы такие задачи ему даете.
Недостаток с какой стороны?
Со стороны управления. Независимо от точки зрения программиста и руководителя.
Когда человека обвиняют в том, что не является его ответственностью и не было оговорено заранее, когда вводят критерии качества работы, которые от человека не зависят, когда человек занимается фиг пойми чем, потому что ему разрешили, а потом ему за это предъявляют претензии, это неграмотное управление.
— В какие сроки можно реализовать?
…
— 2 месяца
— Почему так долго?
— Надо сначала сделать рефакторинг, у нас там весь код рассчитан только на ввод через интерфейсваши пользователя. Месяц на рефакторинг…
Вы говорите:
— Хорошо
Проходит месяц, рефакторинг не закончен. Программист говорит «очень сложный был код, не успеваю, нужно ещё пару недель». Через две недели тоже самое. Ваша реакция? Какие санкции вводить?
— На самом деле разговоры, подобные описанному Вами, у меня идут часто, но это неофициальное согласование сроков. Еще чаще я даю задачи вообще не указывая никаких сроков. Всё на доверии.
Я пробовал такой метод с формальными сроками однажды, мне не понравилось. Вот почему:
1. Очень сложно оценить время, особенно если это баги. Пару недель назад я решил примерно 10 багов, 9 из них за 5 часов, а 10й — за три дня. А на первый взгляд они все были похожие. Никогда бы не подумал, что придётся три дня заниматься с вроде бы простой проблемой. Меня как программиста за это как накажут?
2. непонятно, что делать, если программист просрочил задачу. Если это хороший программист, и были объективные причины. Просто простить? Если да, то в чём смысл согласований? А если реально накосячил программист, какие санкции будут применены? Какие будут доказательства его вины? Программист после такого просто будет стараться всегда завышать сроки.
3. большинство даже самых классных программистов абсолютно не умеют оценивать сроки. Поэтому, доверяя программистам я не доверяю срокам, которые они говорят.
4. обязательно появятся программисты, которые будут просить огромные сроки для элементарных задач. Почему бы и нет? Вы им не доверяете, почему программист должен доверять Вам? И вместо обсуждения того, как делать проект, идёт убивание времени на то, сколько времени его делать.
5. Лишние формальности — лишняя нагрузка на руководителя. Это само по себе управленческая ошибка. Руководитель должен стремиться к тому, чтобы делегировать задачи, а не мучаться вопросами «сложный ли был баг или нет, правильно ли оценили время или нет».
Правило тоже самое: хороший сотрудник экономит время начальника. Плохой сотрудник — тратит время начальника.
Возможно, где-то это и работает, даже интересно как. Какая по факту нагрузка на руководителя, как решаются вышеуказанные проблемы.
У меня метод простой. Дал задачу — вперёд. Через день (неделю, смотря как я занят) нет результата, разбираемся вместе. Может там реально жутко сложная задача и надо не ругать программиста, не долбить его сроками, а помочь её решить.
Со стороны управления. Независимо от точки зрения программиста и руководителя.
Когда человека обвиняют в том, что не является его ответственностью и не было оговорено заранее, когда вводят критерии качества работы, которые от человека не зависят, когда человек занимается фиг пойми чем, потому что ему разрешили, а потом ему за это предъявляют претензии, это неграмотное управление.
Вы почему-то считаете что я обвиняю программиста в том, что к примеру, клиенты не похвалили его работу… Это совершенно не так. Если воспитанник спортивной школы не стал чемпионом мира, его в этом не обвиняют, его скорее похвалят за то, что стал чемпионом района (программист быстро и качественно решил задачу).
Вы обвиняете программистов, если они сорвали сроки? Я — нет. Я обвиняю программистов только в одном случае: если я сделал их работу лучше чем они. К сожалению, с новыми программистами это случалось десятки раз. Даю задачу, они делают неделю, еще две постоянно правят баги, в итоге жуткие тормоза и баги всё равно идут. Лезу в код — там всё жутко сложно. Меняю код на простой и быстрый. Замеряю потраченное мной время. Три дня.
И здесь я обвиняю программиста. Обвиняю постфактум, проверив все детали.
Что касается разговоров о рефакторинге, или «продумывании структуры классов» — это это маркеры плохих программистов. Это как отмаза опоздавшего таксиста «надо было на заправку съездить». Хорошие программисты делают рефакторинг и продумывают классы часто и делают это быстро. Для них это рутина, а не повод оправдать отсутствие результата.
Программист говорит «очень сложный был код, не успеваю, нужно ещё пару недель». Через две недели тоже самое. Ваша реакция? Какие санкции вводить?
При чем тут санкции? Это был ответ на ваш вопрос "Какие работы я могу согласовать, какие сроки?". Вот такие и можете.
Про то, кто и как должен контролировать работу программиста, я уже писал. Не хотите сами, нанимаете человека, либо всегда верите самому программисту на слово.
Если это хороший программист, и были объективные причины. Просто простить? Если да, то в чём смысл согласований?
В том, чтобы не было ситуаций "«Прежний код ужасен, я делаю его отличным, занимаюсь рефакторингом, и скоро Вы увидите кнопку X, ещё немного подождите» — скажет такой программист после месяца-другого работы".
Согласования нужны не для штрафов и санкций, согласования нужны для информации о ходе проведения работ. Чтобы все знали, кто что делает и почему, а не занимались 2 месяца неизвестно чем.
Очень сложно оценить время, особенно если это баги.
Да. Появились сложности, скорректировали сроки. Нет такой цели точно оценить срок перед выполнением задачи и больше его не менять. Я не знаю, с чего вы решили, что надо так делать.
Меня как программиста за это как накажут?
Никак. Почему у вас обязательно надо кого-то наказывать?
большинство даже самых классных программистов абсолютно не умеют оценивать сроки. Поэтому, доверяя программистам я не доверяю срокам, которые они говорят.
И не надо. Важно, что те N дней, которые уже согласованы, всем будет известно, кто чем занимается. Чтобы для вас через 2 месяца не было сюрпризом, что программист занимался рефакторингом.
Вы почему-то считаете что я обвиняю программиста в том, что к примеру, клиенты не похвалили его работу
Я так считаю потому что вы сами это написали. Когда задали это как один из критериев качества его работы. Если показатель маленький, значит работа сделана некачественно. Это и есть обвинение "ты сделал работу некачественно".
Даю задачу, они делают неделю, еще две постоянно правят баги, в итоге жуткие тормоза и баги всё равно идут.
А это говорит о том, что у вас в проекте кривая архитектура, и все разваливается от малейшего изменения, а новым людям очень сложно разобраться в коде.
Лезу в код — там всё жутко сложно. Меняю код на простой и быстрый.
А вот здесь не помешал бы пример. Люди, у которых мало опыта, обычно наоборот делают излишне просто, конкретно под задачу, без учета возможных изменений, и в дальнейшем это создает сложности при появлении новых требований.
Для них это рутина, а не повод оправдать отсутствие результата.
Вы о чем-то своем говорите, игнорируя то, что я пишу. Еще раз — при правильном управлении причина "проведение рефакторинга" в принципе не может быть поводом оправдать отсутствие результата. Так как все заинтересованные лица в курсе, что 2 месяца программист делает рефакторинг. Завершение рефакторинга это и есть результат, который надо достичь. А внедрение функционала X, для которого делался этот рефакторинг, это другой результат, которого надо достичь после первого.
Согласования нужны не для штрафов и санкций, согласования нужны для информации о ходе проведения работ
Я и так знаю кто и что делает. Согласования в большинстве задач просто не нужны. Нужно доверять людям.
«Вы почему-то считаете что я обвиняю программиста в том, что к примеру, клиенты не похвалили его работу»
Я так считаю потому что вы сами это написали. Когда задали это как один из критериев качества его работы.
Похвала клиентов — это критерий качества. Но если похвалы нет, это не повод к обвинениям. Программист — не мелкий винтик в системе, программист — это обычный человек, способный разбираться в самых различных вопроса. Я не раз встречал и поощрал программистов, которые сами ставили себе задачи, сами их выполняли, сами общались с клиентами. Это одни из самых эффективных сотрудников. Таким не надо «ставить задачу», они сами поставят кому угодно задачу и будут правы. Что я делал? Просто доверял и всё. И основная проверка качества — как раз продажи клиентам.
Я не настаиваю, что этот метод подойдёт всем, но мне понравилось.
А если программист работает хорошо, но никак «не лезет» в общение с клиентами — пожалуйста. Это ему не в плюс, но и ругать его за это никто не будет.
«Лезу в код — там всё жутко сложно. Меняю код на простой и быстрый.»
А вот здесь не помешал бы пример. Люди, у которых мало опыта, обычно наоборот делают излишне просто, конкретно под задачу, без учета возможных изменений, и в дальнейшем это создает сложности при появлении новых требований.
На эту тему могу говорить вечно:) наболело…
Например, дана задача — запрограммировать кошку, которая мяукает.
Я пишу класс «кошка», добавляю в него нужные свойства и методы.
Плохой программист сделает сразу «на будущее» — классы млекопитающее -> кошачьи -> кошка. Отдельно будет класс, посвящённый мяуканию.
Далее приходит уточняюща задача — добавить машинку. Оказалось, что кошка — плюшевая, а машинка — пластмассовая.
Я меняю класссы
класс игрушка — от неё наследую пластмассовая и плюшевая, от них кошку и машинку. То есть я делаю полный рефакторинг.
Плохой программист подумает «ну нифигаш себе… не могли сволочи сразу пояснить что к чему » и он будет «решать» проблему либо:
— наследует машинку от кошки (самый быстрый метод достичь решения ТЗ)
— сделает вообще отдельный класс «машинка», никак не связанный с кошкой
— или еще что-нибудь.
главное — плохой программист оставит ошибочные классы, такие как «млекопетающее». Как раз этот плохой программист после будет говорить про «важность продумывания рефакторинга», хотя при правильной работе рефакторинг будет выполнен быстрее, чем разговоры о нём.
при дальнейших изменения ТЗ (добавить подарочные наборы из нескольких уже описанных игрушек) у плохого программиста всё усугубляется. У хорошего — кода всегда меньше. Хороший программист не «думает о будущем», не мусорит код, при этом он быстро меняет алгоритмы исходя из меняющегося настоящего. У него нет ничего лишнего. Я уже не говорю о названиях. Смотрю на код VCL / FMX Delphi и «читаю» его как книгу без документации. Всё просто и понятно. Так пишут профи. Смотрю на код горе-программистов в стиле KoefValue := MosArr.Add(MyList) и думаю… так я понял слово List — список… отлично. Больше пока ничего неясно. Через полчаса изучений оказываеся, что List — это «лист» бумаги на русском языке. Конечно, для новичков есть правила, читают выполняют. Но лишние усложнения там, где они не нужны — это «бич» многих начинающих.
p.s. весной я заменил код программистов (достаточно хороших) примерно 50К строк на 5К строк. Выкинул тьму «высокотехнологичных» наворотов вроде тех же хелперов/интерфейсов/фукнций как параметров, классов-менеджеров и много другого, заменил всё «простой и банальной» архитекурой ООП. Вместо прежних сложных наворотов и классов-менеджеров для работы с разными типами данных ( integer/double/string..) сделал классы для каждого типа (класс TInteger, TDouble… с наследованием от общего типа) с удобной обработкой каждого типа внутри этих классов. Итог: скорость обработки данных выросла в 5 раз, скорость восприятия кода в 10 раз (хотя бы потому что самого кода стало в 10 раз меньше).
Похвала клиентов — это критерий качества.
Это критерий качества вашей работы, а не работы программиста. Это вы изучаете рынок и придумываете, что нужно клиентам.
Я не раз встречал и поощрал программистов, которые сами ставили себе задачи, сами их выполняли, сами общались с клиентами.
Это означает лишь то, что у вас один человек совмещает несколько ответственностей, а значит вы экономите на специалистах. Возможно у вас проект настолько маленький, что у программистов есть время и желание этим заниматься. В больших проектах у программистов на это просто нет времени, всегда есть задачи конкретно по программированию.
Например, дана задача — запрограммировать кошку, которая мяукает.
"Пример" означает не аналогию, а пример. Конкретный пример с конкретным кодом, который был у вас в работе, как было и как стало. Возможно с замененными названиями классов и переменных, если это коммерческая тайна. Ну не хотите, дело ваше, просто ваше утверждение как вы клево делаете рефакторинг останется недоказанным, и нет причин ему доверять.
KoefValue := MosArr.Add(MyList)
Через полчаса изучений оказываеся, что List — это «лист» бумаги на русском языке.
А, так у вас и код-ревью никто не проводит. Неудивительно, что у вас баги при каждом изменении.
Я и так знаю кто и что делает.
Противоречит вашему утверждению "занимаюсь рефакторингом, и скоро Вы увидите кнопку X, ещё немного подождите» — скажет такой программист после месяца-другого работы". В нем вы говорите, что не знали, что программист 2 месяца занимался рефакторингом.
Раз вы противоречите сами себе, не вижу смысла дальше это обсуждать.
Нет — мне нужны продажи! А продажи — это оценка клиентами работы программиста.
— вот бизнес ставит задачу X, программист ее делает без багов, а продажи это не увеличивает. В итоге виноват программист?
— вот бизнес ставит задачу Y, программист смотрит на нее и говорит, что продаж от нее не будет, и смысла ее делать нет. Что тогда делаете? Отменяете ее?
— вот бизнес ставит задачу X, программист ее делает без багов, а продажи это не увеличивает. В итоге виноват программист?
Вы верно ставите вопрос. Причем учитываем, что может быть 1000 разных функций, а покупать будут лишь при совокупности их, поэтому оценить вклад конкретного программиста в продажи очень сложно, почти невозможно.
Поэтому очень полезно оценить насколько клиенты пользуются тем, что сделал программист. На самом деле программист делает работу не для начальника и даже не для своей фирмы, он делает это для клиентов. Кстати, если программист адекватный, то ему самому будет приятно, если его работу используют. А если его работу хвалят клиенты — это точно круче, чем похвала начальника.
Обычно программист делает много разных функций. И если мы сравниваем двух программистов, которые сделали по 50 разных функций и работу одного хвалят клиенты, а работу другого игнорят или ругают, то можно делать выводы:) Или вы считаете что начальник — должен быть главным супер-пупер экспертом? Это же ошибка руководства. Начальник не должен быть объективным оценщиком, он имеет полное право разбираться в работе подчиненных меньше, чем они сами.
— вот бизнес ставит задачу Y, программист смотрит на нее и говорит, что продаж от нее не будет, и смысла ее делать нет. Что тогда делаете? Отменяете ее?
Это точно поднимает авторитет программиста. Он смотрит на задачу с точки зрения клиента и предлагает варианты. Круто! Я точно выслушаю все доводы и даже если я не соглашусь и потребую выполнения задачи, мне как руководителю будет приятно, что программист беспокоится о результате. Думает не только о том, что ему скажу я, а о том, как это повлияет на бизнес.
Если от цифр зависят премии и штрафы, то их будут накручивать. Поэтому денежные kpi опасны (часто полезны, но опасны). А если мы просто выводим по каждому сотруднику набор показателей, где он где-то впереди, а где-то позади (часто зависит от специализации сотрудника), то проблем нет. Если мои подчинённые будут "накручивать " себе положительные оценки реальных клиентов — я не против:)
Главное здесь не обьективность оценки.
Главное:
- Повышение эффективности сотрудников
- Снижение сложности и обьема работы руководителя. Подчинённые должны ЭКОНОМИТЬ время руководителя, а не РАСХОДОВАТЬ его на попытки справедливых оценок.
Это не так. Только денежные показатели могут быть единственной единой базой для оценки. Приносишь мало денег — на мороз, либо ищи способы повышения своей эффективности в рамках тех традиций и тем нормативки, которая принята в твоей среде или компании.
Потому что измерять качество по тому же покрытию юнит тестами — это такая лажа… которую любой нормальный человек легко заэбюзит.
сли от цифр зависят премии и штрафы, то их будут накручивать
Ну, так нужно строить модель, в которой участнику системы не будет выгодно накручивать в краткосроке за счёт будущего, в котором это вылезет техдолгом и прочими неприятными штуками. Все мы знаем про «эффективных» менеджеров с «золотыми» парашютами. И вся их деятельность — это срубить максимум сейчас, а что после — хоть потоп.
в какой-то момент подчиненным не нужен будет руководитель
В самую точку!
Руководитель — это организатор и чем лучше он организует работу, тем меньше он работает сам. Идеальный руководитель вообще не работает!
На практике лучшие руководители включаются в работу для того, чтобы решить конкретные проблемы, выходящие за рамки имеющихся бизнес-процессов, и правильным будет не решение конкретной ситуации, а решение улучшение бизнес-процессов в общем виде.
Пример: ряд сотрудников опаздывают на работу, никаких штрафов за это не предусмотрено. Руководитель вместо того, чтобы поругать опоздавших словами или деньгами, добавляет новый показатель для аналитики (которая идет по ТВ в офисе, рассылается всем на емайл, или вывешивается на доску) — где считаем баллы опазданий для трёх последних опоздавших (даже если опаздывает 100 человек — выделяем трёх худших, для психологии). Получается «доска позора». Никаких штрафов и премий не назначается, обычно «доски позора» достаточно. Это ни что иное как классическое наказание, в отличие от запрещённых по КЗОТ штрафов.
Один раз решив проблему, руководитель более к ней не возвращается.
где считаем баллы опазданий для трёх последних опоздавших (даже если опаздывает 100 человек — выделяем трёх худших, для психологии).
И что? Получили фуфло. Объясню. Люди не Идиоты. И либо они будут эбьюзить эту систему (нажимая кнопочку начала работы пораньше и удалённо), либо забьют. Ну, какая мне беда с того, что меня вывесят на доску позора? Премию срежут? Так ее и по 100 других причин может не быть. А самое мерзкое, что в такую игру сами руководители обычно не играют — а правила должны быть одинаковые для всех. Иначе они реально перестают работать.
Хотя именно на психологическом уровне Ваш руководитель (из примера) молодец — на ровном месте устроил психологическое давление на сотрудников. Ога-ога. Остаётся только посчитать как это сказалось в целом на эффективности работы коллектива и псих. здоровье его участников
И либо они будут эбьюзить эту систему (нажимая кнопочку начала работы пораньше и удалённо), либо забьют. Ну, какая мне беда с того, что меня вывесят на доску позора? Премию срежут?
Из нашей практики. Сделали клиенту на монитор в офисе вывод показателей по просроченным сделкам. 7 худших отметили красным, а всего там около 100 менеджеров. Первый раз мы вывесили это утром, в тестовом режиме, никому ничего не поясняя, никаких премий штрафов никто за это не обещал.
Итог: в тот же день количество просрочек уменьшилось вдвое. Не руководители объясняли менеджерам «почему опять… сколько раз говорить… и т.д. » а сами менеджеры забегали. Худшие, самые апатичные менеджеры неожиданно проявили дикую активность.
Люди ценят хорошее отношение и никто не хочет быть крайним. Это как борьба за предпоследние места в спортивных лигах — никто не хочет вылететь, все работают на полную.
А если кому-то всё равно на это, то зачем такой сотрудник нужен? Вспомните Apple, Google, Amazon — среднее время работы не более трёх лет. Не надо держать тех, кого надо гнать.
Вы не понимаете. Я могу быть офигительным работником, но опаздывать на 5 минут каждый день. И мне это простят. За все остальные заслуги и эффективность работы. Не то лечите. И не теми методами. Опоздания — они могут работать только с линейным персоналом, который работает с клиентами. Но никак не для инженеров. А такими метриками испортить мотивацию — легко. В результате инновации будет делать кто угодно другой, но не Ваша компаняи
Я могу быть офигительным работником, но опаздывать на 5 минут каждый день. И мне это простят.
Никаких противоречий нет, я как раз про это и говорю. Правда, привык быть не тем, кого «прощают», а скорее тем, кто прощает:)
Я как раз против любых штрафов. Я против премий, в которых учитываются сложные алгоритмы, включая те же опоздания.
Опаздывает хороший сотрудник на 5, 10, 15 минут… ок. Не проблема. Опаздывает на час и другие, не такие хорошие сотрудники — берут пример. Это уже плохо. Это убивает корпоративную культуру.
Можно использовать много общих метрик, в итоге сотрудники будут знать, на что руководство обращает внимание. Например, два сотрудника занимаются продажами, один продаёт корпоративными клиентами, а другой частным. Понятно, что у первого суммы продаж будут выше, и «единым мерилом» их не измерить. В этом и суть. Невозможно сделать справедливые kpi (не беру простые физические работы).
И спасают тут kpi «условные», когда метрики есть, они важны, но… нет прямой алгоритмической связи между ними и зарплатой.
Начальник решает, что зп у Иванова будет 10 монет, а у Петрова 11 монет. Несмотря на то, что у Иванова почти все показатели лучше, но начальник понимает, что официальные kpi не идеальны, а Петров реально более профессионален и опытен. Затем надо оценить Сидорова, начальник его работу знает плохо. Что делать? Смотреть на показатели. Плохая система расчёта kpi лучше, чем полное отсутствие.
Другой момент: если премии зависят только от kpi, то снижается авторитет руководителя. Он просит сотрудника «сделай задачу X», а сотрудник думает «я потрачу время на X, это ухудшит мои показатели, мне понизят зарплату». И постарается поставленную задачу отложить или сделать быстро и плохо, лишь бы отвязались. А если зарплата в итоге зависит от мнения руководителя, где kpi — лишь помощь, то сотрудник сделает задачу X исключительно хорошо.
Саммари
На каком это языке?
Статья мне понравилась.
Есть ещё психологический приём:
Если руководитель сомневается в эффективности сотрудника, он должен задать себе вопрос: "как бы я поступил с этим сотрудником, если бы он пришёл устраиваться на работу?"
Что делать с неэффективным сотрудником, который считает, что он отлично справляется