Слышал байку, как одна британская ИТ-компания наняла индийца через онлайн-собеседование. Он блестяще прошел многоступенчатый отбор. Британцы выкатили оффер, приняли его в штат.
Но приехал другой индиец, которого был абсолютно проф-непригоден. Им понадобилось полгода, чтобы уволить его. Обратная сторона социальной защищенности))
Оказалось, схема такая: есть индийцы, которые проходят технические собесы. Потом другие индийцы идут в местный суд, меняют ФИО и приезжают к работодателю. Даже если их потом увольняют, то якобы полученный заработок позволяет кормить целую деревню
Да, соглашусь, что если эти переработки носят хронический характер, то скорее всего проблемы с планированием и ресурсами.
С другой стороны бывают внешние обстоятельства, например, тот же локдаун при ковиде, болезнь или увольнение сотрудников в самый ответственный момент проекта.
И если с последними обстоятельствами еще можно было работать на уровне риск менеджмента, то ковид - это форс-мажор. Тогда нужно было срочно в 2 дня переделывать инфраструктуру под массовую удаленку.
Спасибо вам большое за подробный и обстоятельный комментарий
В то время как более эффективна оценка, которую дал исполнитель и согласился с ней, поскольку сохраняется мотивация оправдать правильность оценки, против подтверждения навязанной
Вы подсветили важный аспект, что оценка времени являются на самом деле обещанием разработчика выполнить работу. Можно сказать другими слова: приложить все усилия и уделить 100% внимания на применение своих навыков для решения поставленной задачи за отведенный срок.
Для типовых задач уже наработана статистика времени, например создание простой синхронный CRUD REST API, добавление дополнительных атрибутов в существующий метод и т.д. Также смотрим Lead time для похожих фичей, чтобы примерно понимать, через сколько времени после старта работы команды Delivery фича окажется на прод-окружении.
Но таких задач не много, поэтому для большинства задач мы все же проводим оценку без оглядки на исторические данные.
Кейс, когда разработчики копируют друг у друга оценки умышленно, - это кейс взаимоотношения внутри коллектива и принципов, которые вы транслируете команде. Как бы это ни звучало пафосно, мы за честность.
Спасибо большое за важное уточнение! Действительно, лучше использовать относительные, а не абсолютные оценки в случае новых задах с высоким уровнем неопределенности.
Описанный мною способ решает проблему агрегации оценок времени без эффекта привязки для задач с "ясным" описанием:
Будем считать, что информация, описанная в постановке, достаточна для корректной оценки времени. Вопрос про полноту входных данных оставим за рамками данной статьи.
По большому счету сроки нужны прежде всего для того, чтобы синхронизировать работу составляющих производственной системы
Полностью согласен и рад, что здесь есть консенсус. При разработке зависимых микро-сервисов важно синхронно выкатывать функционал в прод. И, как вы правильно заметили, необходимо выравнивание загрузки.
Солидарен и с тем, что только время не должно быть единственным параметром при планировании.
чтобы заниматься гештальт-терапией, "мотивированием сотрудника" и прочих благоглупостей
Тоже согласен. Где-то здесь уже отвечал, что это плохой кейс, когда оценки времени становятся инструментом наказания.
Я понимаю ваше беспокойство. Примеры, о которых вы рассказываете, к сожалению, имеют место в жизни.
И хорошо, что тем не менее вы разделяете: перегибы и ценность практики. Потому что любую самую лучшую практику/принцип/институт в абсолюте можно довести до маразма.
Согласитесь, бывают несчастные браки, но из этого не следует, что ВСЕ люди несчастны в браке.
Наличие жен, любовниц и множество детей не говорит о том, что у человека есть личная жизнь.
Такой человек может видеть свою семью 2 часа в неделю. Будут ли взаимоотношения в семье качественными? Навряд ли.
Интересный кейс! А расскажите, если не секрет, как ваш руководитель сформулировал свои ожидания?
Менеджер разработчику: «Скажи, Евгений, ты не против поксенить в выходные?»)))
Все совпадения случайны))
Им предлагали тоже релокацию или удаленку?
Слышал байку, как одна британская ИТ-компания наняла индийца через онлайн-собеседование. Он блестяще прошел многоступенчатый отбор. Британцы выкатили оффер, приняли его в штат.
Но приехал другой индиец, которого был абсолютно проф-непригоден. Им понадобилось полгода, чтобы уволить его. Обратная сторона социальной защищенности))
Оказалось, схема такая: есть индийцы, которые проходят технические собесы. Потом другие индийцы идут в местный суд, меняют ФИО и приезжают к работодателю. Даже если их потом увольняют, то якобы полученный заработок позволяет кормить целую деревню
За достоверность байки не ручаюсь. Но смешно))
Неудавшийся деплой и авария на проде?
Да, но много людей за чертой бедности
70 часов - это, конечно, жесть))
А как он предлагает? Каждый день по 10 часов без выходных или по 14 часов в будни?
Да, соглашусь, что если эти переработки носят хронический характер, то скорее всего проблемы с планированием и ресурсами.
С другой стороны бывают внешние обстоятельства, например, тот же локдаун при ковиде, болезнь или увольнение сотрудников в самый ответственный момент проекта.
И если с последними обстоятельствами еще можно было работать на уровне риск менеджмента, то ковид - это форс-мажор. Тогда нужно было срочно в 2 дня переделывать инфраструктуру под массовую удаленку.
А как вы относитесь к оплачиваемым переработкам или отгулам за переработки?
Еееее! Моя статья в топе!! Спасибо большое, Хабр, за такое крутое комьюнити!
Очень приятно, что мою статью отобрали в шорт лист!
Сложность тоже выбирал исходя из сложности и доступности статьи))
Спасибо вам большое за подробный и обстоятельный комментарий
Вы подсветили важный аспект, что оценка времени являются на самом деле обещанием разработчика выполнить работу. Можно сказать другими слова: приложить все усилия и уделить 100% внимания на применение своих навыков для решения поставленной задачи за отведенный срок.
И, естественно, обещание, которое получено добровольно, намного ценнее для выстраивание доверия внутри команды, чем навязанное сверху. Об этом я писал в этой статье: https://companies.rbc.ru/news/gJvDSCK7EE/kak-prohodit-etap-turbulentnosti-pri-postroenii-komandyi/
Для типовых задач уже наработана статистика времени, например создание простой синхронный CRUD REST API, добавление дополнительных атрибутов в существующий метод и т.д. Также смотрим Lead time для похожих фичей, чтобы примерно понимать, через сколько времени после старта работы команды Delivery фича окажется на прод-окружении.
Но таких задач не много, поэтому для большинства задач мы все же проводим оценку без оглядки на исторические данные.
Кейс, когда разработчики копируют друг у друга оценки умышленно, - это кейс взаимоотношения внутри коллектива и принципов, которые вы транслируете команде. Как бы это ни звучало пафосно, мы за честность.
С ИИ не баловались для сбора статистики.
P.S. позвольте рекомендовать мою другую статью про планирование сроков https://habr.com/ru/articles/789414/
Спасибо большое за важное уточнение! Действительно, лучше использовать относительные, а не абсолютные оценки в случае новых задах с высоким уровнем неопределенности.
Описанный мною способ решает проблему агрегации оценок времени без эффекта привязки для задач с "ясным" описанием:
Полностью согласен и рад, что здесь есть консенсус. При разработке зависимых микро-сервисов важно синхронно выкатывать функционал в прод. И, как вы правильно заметили, необходимо выравнивание загрузки.
Солидарен и с тем, что только время не должно быть единственным параметром при планировании.
Тоже согласен. Где-то здесь уже отвечал, что это плохой кейс, когда оценки времени становятся инструментом наказания.
Ваш пример про подгонку еще одно подтверждение «эффекта привязки» :)))
С моей точки зрения, важно донести до команды, что поиск новых ИТ-решений и дополнительные доработки для достижения целей проекта допустимы, однако, при этом недопустимо уходить в бесконечный цикл работ. То есть все дополнительные активности должны выполняться в рамках других отдельных задач. Подробнее тут: https://companies.rbc.ru/news/Q1vEYxbaGU/kak-ponyat-chem-zanyatyi-vashi-razrabotchiki-i-chto-proishodit-na-proekte/
Я понимаю ваше беспокойство. Примеры, о которых вы рассказываете, к сожалению, имеют место в жизни.
И хорошо, что тем не менее вы разделяете: перегибы и ценность практики. Потому что любую самую лучшую практику/принцип/институт в абсолюте можно довести до маразма.
Согласитесь, бывают несчастные браки, но из этого не следует, что ВСЕ люди несчастны в браке.
Согласен, что точность оценки задачи напрямую зависит от полноты описания задачи.
Выбор тула - вторичен. Иногда какие-то вещи можно решить с помощью блокнота и ручки :)