Александр Хван @RunMile
Технический менеджер проектов
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Registered
- Activity
Specialization
Release Manager | Delivery Manager
Project management
Planning
Optimization of business processes
People management
Negotiation
Agile
Organization of business processes
Building a team
Scrum
Development management
Наличие жен, любовниц и множество детей не говорит о том, что у человека есть личная жизнь.
Такой человек может видеть свою семью 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/
Я понимаю ваше беспокойство. Примеры, о которых вы рассказываете, к сожалению, имеют место в жизни.
И хорошо, что тем не менее вы разделяете: перегибы и ценность практики. Потому что любую самую лучшую практику/принцип/институт в абсолюте можно довести до маразма.
Согласитесь, бывают несчастные браки, но из этого не следует, что ВСЕ люди несчастны в браке.
Согласен, что точность оценки задачи напрямую зависит от полноты описания задачи.
Выбор тула - вторичен. Иногда какие-то вещи можно решить с помощью блокнота и ручки :)