Нужно ли ставить программистам время в задачах?
Дебаты про тайм-трекинг не утихают в IT-сообществе с момента его возникновения. Жесткий контроль приводит к недовольству и текучке кадров. Отсутствие контроля - к снижению эффективности. Основатель KR Digital Сергей Ковалев размышляет о том, как найти золотую середину.
17K17K показов
2.9K2.9K открытий
Прекрасно работает схема, когда разработчик не на зарплате а получает, как фрилансер, деньги за закрытые задачи. Конечно стоимость задачи должна быть консенсусом между разработчиком и заказчиком.
Но в любом случае такая схема держит разработчика в тонусе.
Но пока еще не все созрели к выводу разработчиков из штата, хотя, если подумать, штат совершенно никаких плюсов работодателю не даёт. Да и разработчику тоже. Вообще.
Я немного работал по такой схеме на Upwork. Пришёл к выводу, что если делать задачу качественно как требуют того в компаниях — то оплата едва покрывает затраты на еду, съеденную за время работы. Зато если писать сложный говнокод без документации — то к тебе приходят заново как к обладателю сакрального знания, и ты диктуешь цену по $100 за багфикс в 1 строчку и час работы.
Т.е. проблема в том, что в "acceptance criteria" не пропишешь "добавленный техдолг". Одну и ту же задачу можно "решить" за 2 часа и +100 попугаев техдолга (которые потом всплывут как 10 новых задач), а можно за 20 часов и -100 попугаев техдолга (попутно закрыв класс ещё не всплывших проблем). И в долгосрочной перспективе, когда релиз не горит — выгоднее идти по п.2, согласуя это с грамотным менеджером.
Издержки будут расти. Да и вам нужно прокачивать скилл, чтобы проводить ревью согласно стандарту.
тогда нет смысла делать задачи качественно, выгоднее найти нового работодателя.