Как распознать недобросовестного сотрудника-разработчика
В наше время формат удаленной работы в IT индустрии становится все более и более популярным. При найме разработчиков возможность удаленной работы становится неоспоримым преимуществом, но что, если сотрудник воспользуется таким форматом в своих интересах? Уверены ли вы, что ваш сотрудник работает 6-8 часов, как и положено? Нет ли у него второй работы? Не занят ли он любимой видеоигрой в разгар рабочего дня?
Некоторые компании для избежания подобных случаев используют такие методы контроля, как трекинг времени, трекинг движений курсора или скриншоты экрана. Будет ли добросовестный сотрудник рад такому контролю? Нет. Будет ли он мотивирован на хороший результат? Точно нет. У каждого из нас бывают непродуктивные дни, когда средняя задачка может занять больше времени. И как будет неприятно, когда в такой день менеджер придет к сотруднику и обвинит его в низкой производительности. Кроме этого, излишний контроль ухудшает качество работы и снижает общую мотивацию команды. Что-же тогда делать?
Исходя из моего опыта я бы сформулировала следующие инструменты, которые могут помочь менеджеру в работе:
- Проводить оценку скоупа задач в команде разработчиков или 2 независимыми экспертам.
Предложите 2 и более разработчикам примерно с одинаковым профессиональным уровнем оценить задачи и сравните результаты. Если они похожие, без значительных перекосов во времени, значит разработчики честны перед вами. Если один из разработчиков завышает сроки выполнения по каждой или по большей части задач, значит он скорее всего он оставляет себе больше личного времени, чем положено по трудовому договору с компанией. Важно также отметить, что по некоторым задачам действительно могут быть разные сроки от разных разработчиков, так как опыт каждого уникален. В этом случае, надо узнать, почему разработчик ставит больший срок, и, если это действительно связано с отсутствием опыта, значит завышение срока оправдано. Этот инструмент хорош, так как вероятность попасть на 2 недобросовестных работников не велика. - Декомпозиция задач. Оценивая задачу, человек может ссылаться на 30-40 часов для ее выполнения, так как по описанию она выглядит сложной. Чтобы избежать необоснованного завышения сроков выполнения, нужно попросить сотрудника декомпозировать задачу на более мелкие, те, которые займут не более 2 дней. Да, это тоже займет время. Да, разработчик может отнекиваться, и просить оценить ее «по ходу дела». Но если он все-таки это сделает, то оценка будет точнее, а это минимизирует риск срыва дедлайна.
- Артефакт к каждой задаче. В работе часто бывают небольшие задачи, которые кажется можно доверить сотруднику и не проверять. Но как раз из-за этого разработчик может “выполнять” задачу больше времени, так как знает, что ее не проверят. Если разработчик потратил 3 дня и с гордостью показал вам 2 строчки кода, стоит c ним поговорить.
- Прислушиваться к словам сотрудника. Не позволяйте сотруднику словоблудить, просите цифры. В разработке нету места пустым словам. Только конкретные данные. Что будет выполнено, когда, и как проверять. Если человек говорит, что ему надо что-то немного доделать в задаче и все будет готово, не верьте. Если разработчики постоянно превышают сроки при оценке скоупа, систематически пропускают дедлайны, а в оправдание говорят много слов без указания конкретных причин, лучше не оставлять такого человека в команде. Даже, если он работает уже много лет, даже если это ваш лучший специалист и даже, если вам кажется, что это временно. Когда будет пропущен дедлайн, пострадают все.
- Собирать факты факапов. Привожу примерные цифры. Если в течении 2-3 месяцев у человека зафиксировано 30% овертайма или других факапов, значит этот сотрудник не подходит под данную должность. Здесь важно именно фиксировать провальные моменты, а не полгаться на свое субъективное ощущение. Срок и количество факапов устанавливается самостоятельно. Это зависит от уровня терпимости и веры в человека как в специалиста.
Что вы думаете об этих инструментах? Сталкивались ли вы с недобросовестными работниками?
А потом Екатерина узнает, что:
- если нанятый разработчик работает хотя бы 4 часа в день - это уже успех, и вам повезло
- если в результате трех дней работы вам показывают 3 строчки кода - то это лучше, чем если вам показывают 3к строк кода.
- если взять двух разработчиков с примерно одинаковой компетенцией и дать им оценить задачу - то их оценки далеко не всегда должны сходиться.
- если сотрудник делает задачи, которые закоммитился сделать в срок и с ожидаемым уровнем качества, то всем в принципе насрать сколько часов в день и на скольких работах он работает.
Большое спасибо за комментарий. Мне есть над чем еще подумать
Ещё в советской школе мне любезно сообщили, что согласно решению профсоюза программистов- не более 2 строчек в день.
И вообще писать матом, хоть и вражеским - плохой стиль.
Спасибо, что отметили про стиль. Учту
Комментарий недоступен
Что вы имеете в виду под "разобраться в рынке"?
Дедлайны ведь как раз и ставятся в зависимости от оцененных задач