Как вы сбалансируете задачи в спринт по одинаково важным проектам? Первоначальную разработку еще можно выстроить в очередь, но ведь будут приходить и собственно задачи на анализ и проектирование, и баги - они все могут одновременно прийти в один день и час внутри спринта (как подзадачи к истории, например), и какие-то будут отложены. Тот проект, по которому они будут отложены - поедет по срокам, либо будут заложены риски на оба, но все равно общая скорость проекта будет медленнее при такой расфокусировке. Можете почитать про Канбан, если не знакомы.
И еще один момент. Есть большая разница - делаешь ли ты задачи, кем-то другим декомпозированные, контролируемые по срокам и зависимостям и в целом не погружаешься вширь. Или же тебе нужно сделать какой-то результат в проекте, а задачи ты себе ставишь сам, общаешься со смежниками, описываешь документацию и так далее. Первое - при нормальном управлении делать можно на нескольких проектах, но будет хуже контекст у исполнителя, и тогда крайне важно, чтобы этот контекст кто-то имел на детальном уровне (тимлид, менеджер, аналитик). Иначе постоянно будет ситуация "претензии к пуговицам есть?" - то есть пуговицы будут идеальные, но стыковаться все это не будет, если этого не было детально описано в задаче. И виной исполнителя это не будет - он просто не мыслит категорией проекта, а мыслит категорией задачи. А вот если нужно именно второе, полностью доводить задачи силами исполнителя до конечного результата - то параллелить проекты крайне тяжело и качество страдает. Потому что человек и так держит в голове, чтобы достигнуть цели, очень много параметров одного проекта. А мозг ограничен у человека, и держать в голове несколько проектов он не в состоянии на должном уровне.
Вообще, любое переключение между проектами снижает как минимум скорость реализации этих проектов. Сейчас вовлечена в несколько - а так как я, как и любой человек, одновременно делать задачи все таки не могу физически, то задачи разных проектов выстраиваются в какую-то очередность. Если оба проекта важные, а по ним есть одновременно срочные задачи (а у меня такое есть постоянно), то какой-то проект начнет страдать, а потом, чтобы нагнать отставание по второму проекту - перестаешь делать задачи по первому, и уже там упускаешь ситуацию. Если ты начал отставать по какому-то проекту, то начинаешь спешить, устаешь, и конечно делать ошибки, в лучшем случае жертвовать мелкими неприоритетными задачами (просаживаясь по качеству).
Другое дело, если есть основной приоритетный проект, и побочная неприоритетная задача, которую без проблем можно двигать по срокам. Тут проще, где-то даже комфортнее, так как можно заполнить дырки и делать что-то полезное, ожидая смежников.
И это плохая новость, то что усложняются такие разводки, и рано или поздно появится правдоподобный и для опытного в ИТ сценарий. Потому что даже уже на этом кейсе чисто теоретически - можно было бы представить, когда реально платят чисто за установку apk и прокликивание стандартного сценария - например, тестирование под разные виды устройств и операционки. Т.е. если бы поставили цену пониже и предварили соответствующим текстом - то отличить и заподозрить разводку - было бы вообще очень сложно.
Тут надо другого видимо добиваться - чтобы такие разводки стали опасными для мошенников, потому что их моментально бы находили или возвращали бы деньги как минимум (например, все подобные сделки были бы, например, через отзываемые и контролируемые платежи). При текущих технологиях теоретически возможно, и тогда сам факт предложения сделать перевод не через этот сервис - был бы сигналом для человека.
Не знаю, насколько это свойственно рынку в целом, может быть это специфика моей компании, но я наблюдаю совсем другую проблему.
В погоне за эффективностью фич команды:
1) собирают "легкие плоды" - мелкие улучшения, простые с точки зрения разработки, и вроде бы обещающие денег тактически
2) делают всякие регуляторные, но бессмысленные финансово задачи (потому что продавливают методологи, регуляторы, комплаенс, ИБ и прочие подобные участники).
Проблема в том, что легкое редко приносит много денег (это бывает, но требует очень грамотного знания бизнеса и удачи), а регуляторка максимум спасет от убытков. А сложные фундаментальные задачи, без которых никогда не будет профита у компании в будущем - делаются очень тяжело. И через год-два-три накапливается тот техдолг, те недоработки - которые принесут компании в будущем очень большие убытки или будет упущенная прибыль.
Что еще хуже, такие сложные проекты разучились делать...
Я сейчас работаю в такой команде, где лидер команды - не технарь и не процессник, а продакт-мотиватор с базовым ИТ бэкграундом.
Что могу сказать - схема рабочая, но только при важных "НО":
Первое "НО":
1) либо это должна быть сработавшаяся команда мотивированных профессионалов (все слова важны), которые по сути дела внутри себя поделили как-то роль техлида и при этом достаточно компетентны, чтобы не завести систему в тупик. Ну т.е. не команда джунов :)
2) либо в команде должен быть все таки еще и техлид, также с хорошими софт-скиллами, погруженный в техническую часть, и заинтересованный в том, чтобы развивать систему долгосрочно.
Иначе - максимум год-два и система станет неуправляемой, а люди накапливать усталость и процессные ошибки. Как правильно сказано - продакт-нетехнарь - он и непроцессник тоже. А значит если он мотивировал команду работать на продукт - то она почти неизбежно встанет на сторону бизнеса и будет пытаться сделать быстро, копя технический долг. Если в ней мало или отсутствуют опытные специалисты уровня синьора (или сеньоры даже есть - но не хотят или не умеют делиться опытом) - она начнет наступать на грабли и изобретать велосипеды в коде и в процессах, и некому будет подсказать, что все это уже имеет общепринятое решение.
В статье есть тимлид - значит схема рабочая. У нас от тимлидов одно время отказывались, и, на мой взгляд, последствия этого в некоторых командах не очень. (
Второе "НО":
"Нетехнарь" должен хорошо знать свой продукт и бизнес, иметь авторитет на уровне руководства, но при этом понимать, что "есть только одно правильное мнение и оно мое" - это не для такой схемы управления, досконально погружаться в вопросы команды по бизнес-части, не давать невыполнимых обещаний за команду и понимать, что команда не может давать хоть сколько-то вменяемые оценки задачи по ее заголовку. Т.е. быть хорошим продактом и умным человеком :)
Плюсы в схеме с продактом-нетехнарем, которые вижу:
1) я работала на подобной роли, будучи технарем. Так вот, 30-40% времени вынужденно занимало общение с топ-менеджментом, руководством и коллегами со смежных подразделений. С учетом того что на продумывание тактических планов и стратегии нужно тоже 20-30% времени хотя бы, по факту на взаимодействие с командой оставалось не так много времени, половина из которой уходило на рутину. Этого не хватало на нормальное выстраивание технических процессов, то есть по итогу мой технический бэкграунд все равно давал не так много профита именно для этой роли, но и второго лида-технаря в команде не было. А так - имеем двух лидеров, каждый фокусируется на своей части и теоретически успевает ее проработать качественно.
2) нетехнарь имеет мышление ближе к пользовательскому и если команда пытается сделать быстрее, но неудобно для пользователя - то техлид может это упустить, а хороший продакт не должен
Минусы: мало хороших продактов встречала. Сейчас работаю в подобной схеме, и считаю что нашей команде повезло, а вот в других командах наблюдала полный треш с такой схемой (((, когда либо продакт сильно давит на команду (не понимая границы реализуемости), либо не уделяет времени команде, либо даже просто не понимает бизнес-задачи. Т.е. нельзя путать "продакта-нетехнаря" с "любой человек с любым образованием, разберется по ходу что там делать". Это тоже профессия, которая тоже требует ИТ-бэкграунда, просто другого.
Жизнь есть жизнь, бывают срочные задачи, не всегда вообще понятно что делать на 2 недели вперед, если динамика продукта требует менять состав задач - на мой взгляд не надо быть фанатиком, и менять. Например, из недавнего опыта в команде - то ли надо будет делать регуляторные требования с дедлайном 2 недели, то ли нет, узнаем через пару дней после начала "спринта".
Но в этой ситуации, на мой взгляд, менеджмент также должен быть честен и признаться что это не спринт, например перейти на Канбан ))))
Scrum вообще далеко не везде можно натянуть на компанию, процессы и команды, и пытаться не надо, если не лезет.
Хм, а что, никогда не бывает шестой причины сопротивления изменениям - потому что они объективно ухудшают процесс работы в команде (или на языке статьи - потребности работать в эффективном и осмысленном процессе, а не копать яму и потом ее закапывать каждый день без смысла)? Хотя конечно, такого же быть не может, бред какой-то :)
Конечно же, и то что пишете - тоже может быть. Но на моей практике, чаще сопротивление встречают непродуманные изменения (когда с высоты птичьего полета все красиво, а при реальной эксплуатации куча вопросов и проблем), или изменения которые заведомо дают профит на уровне вне команды (компании в целом, топ-менеджмента, лида), но в команде ситуацию либо ухудшают, либо в лучшем случае не меняют (но надо адаптироваться к новой парадигме).
Вторые изменения конечно же надо внедрять, если они реально нужны. Но обманывать себя в том, что сопротивление происходит исключительно потому что "люди такие люди", и хотят чего-то на эмоциональном, а не логическом уровне... ну в общем, такое себе. Честно признаемся - команде станет хуже, но это надо по какой-то другой причине. Иногда, если так честно и сказать людям, и еще и объяснить причину, они побухтят, но смирятся.
Первые же изменения - это крайне интересная штука, команда не всегда находит слова, почему так нельзя. Ну просто потому что надо объяснить иногда очень спефицические вещи, и кажется что сопротивление просто так. И на мой взгляд крайне важно уметь понять эту ситуацию, иначе всегда будете "эффективным менеджером", а не реально полезным менеджером. Потому что иначе не очень принципиальная команда на самом деле в итоге примет ситуацию, и вы обрадуетесь, что все, победили сопротивление. Только вот результат по факту ухудшится, может не сразу, или несущественно (поэтому будет не так заметно).
Хм, а не приходило в голову то, что придумать идею просто тупо легче, чем ее реализовать? И сгенерировать 1000 идей в бэклог можно за пару недель, 10-50 из них будут даже реально ценными, а сделать одну более-менее приличную идею (а не мелкое улучшение) в лучшем случае месяц-два?
Ну то есть никто не спорит, что команда важна, и если команда хронически не делает то, что сама (без давления) обещала, то возможно им действительно не хватает опыта (и то возможно, что не опыта, а например каких-то инструментов, утыкаются в какие-то внешние аспекты).
Но если бэклог проекта растет быстрее чем решается, это означает только одно - генератор идей хочет реализовать все, не учитывая, какими ресурсами обладает. И даже суперкоманда имеет ограниченную пропускную способность, выше которой не прыгнуть.
Стресс больше всего вызывала всегда несправедливость и агрессивная некомпетентность, неважно чья и от кого. Все остальное можно пережить. Когда работала на менеджерской позиции, все время был сплошной стресс, так как там этого полно. К счастью, сбежала обратно в специалисты, и безумно довольна.
Проблема с оценкой сроков - в том, что это приемлимо для типовых задач с относительно достаточными вводными и всеми выделенными вовремя ресурсами.
Ну т.е. если опытную секретаршу попросили перепечатать с рукописи книгу, при этом показали ее, и дали компьютер - то названный ей срок относительно реален.
А если спросили построить дом, по которому нет ни проекта, ни графика поставок материалов, а есть только картинка внешнего вида?
Я не отрицаю, что какие-то оценки сроков нужны даже по таким задачам, чтобы как-то ориентироваться на стыковку с другими делами. Но совершенно точно не вина сотрудника, если он ошибся.
Я точно знаю, что если в моей компании отменят удаленку, я буду искать другую работу, а не читать хабр по дороге :) . Удаленка - единственный вариант уравнять сельского ит-шника с москвичом. Ограничивать себя в месте жительства только локациями близко к крупным хабам - очень плохой вариант. Муж успешно проходил до оффера в Яндекс, не пошёл по своим причинам - сейчас подтверждается, что не зря...
Я не в Яндексе, но тоже в большой компании. Увы, такие решения часто топы принимают из моды или эмоций, а не со смыслом. Прочитали статью, что Маск так делает (и не важно, что там другие условия). Или другой гендир вашему гендиру в кулуарах сказал, что своим отменит удаленку. Или ваш гендир посмотрел что ближний круг подчинённых действительно расслабился, но экстраполировал на всех, а не только на провинившихся. В лучшем случае - сравнил показатели эффективности до удаленки и после, увидел реальную отрицательную динамику, но цифры же надо интерпретировать (а динамика, например, из-за стресса от событий в стране, и удаленка не причём).
Дело усугубляет то, что топы действительно менее эффективны на удаленке, так как их работа - общение между собой, и договориться с другим подразделением сложнее без живого контакта. Но редко думают, что специфика работы разная, и экстраполируют это на всех.
А ещё - может быть хотят посмотреть вживую на настроения сотрудников. Думают, что на это как то можно повлиять.
В общем, на самом деле это плохо. Эффективность в Яндексе конечно не поднимется, так как не удаленка тому виной, а скорее мотивация, компетенции, действия самих руководителей итп. Но вот если крупняк так начнёт делать (а дурное дело заразительно), то упадёт уровень жизни у сотрудников за счёт сгорания времени на дорогу, и повысится конкуренция за удалённые места. В проигрыше и компания, и люди. В выигрыш компании - не верю.
Подскажите, вы отвечаете за некий бизнес блок, и я так понимаю - за вами закреплены несколько ИТ команд. Но, предполагаю, что эти команды развивают конкретные сервисы и системы. А, вероятно, бывает что ваши заказчики хотят чего-то, что не относится к сфере работы ваших команд. Как вы такие задачи разруливаете? Передаёте полностью коллегам, или курируете все же сами или как-то ещё? И второй вопрос, вытекающий из первого. Если есть задачи или подзадачи, которые зависят от других команд - как вы решаете конфликты приоритетов?
Как вы сбалансируете задачи в спринт по одинаково важным проектам? Первоначальную разработку еще можно выстроить в очередь, но ведь будут приходить и собственно задачи на анализ и проектирование, и баги - они все могут одновременно прийти в один день и час внутри спринта (как подзадачи к истории, например), и какие-то будут отложены. Тот проект, по которому они будут отложены - поедет по срокам, либо будут заложены риски на оба, но все равно общая скорость проекта будет медленнее при такой расфокусировке. Можете почитать про Канбан, если не знакомы.
И еще один момент. Есть большая разница - делаешь ли ты задачи, кем-то другим декомпозированные, контролируемые по срокам и зависимостям и в целом не погружаешься вширь. Или же тебе нужно сделать какой-то результат в проекте, а задачи ты себе ставишь сам, общаешься со смежниками, описываешь документацию и так далее. Первое - при нормальном управлении делать можно на нескольких проектах, но будет хуже контекст у исполнителя, и тогда крайне важно, чтобы этот контекст кто-то имел на детальном уровне (тимлид, менеджер, аналитик). Иначе постоянно будет ситуация "претензии к пуговицам есть?" - то есть пуговицы будут идеальные, но стыковаться все это не будет, если этого не было детально описано в задаче. И виной исполнителя это не будет - он просто не мыслит категорией проекта, а мыслит категорией задачи. А вот если нужно именно второе, полностью доводить задачи силами исполнителя до конечного результата - то параллелить проекты крайне тяжело и качество страдает. Потому что человек и так держит в голове, чтобы достигнуть цели, очень много параметров одного проекта. А мозг ограничен у человека, и держать в голове несколько проектов он не в состоянии на должном уровне.
Вообще, любое переключение между проектами снижает как минимум скорость реализации этих проектов. Сейчас вовлечена в несколько - а так как я, как и любой человек, одновременно делать задачи все таки не могу физически, то задачи разных проектов выстраиваются в какую-то очередность. Если оба проекта важные, а по ним есть одновременно срочные задачи (а у меня такое есть постоянно), то какой-то проект начнет страдать, а потом, чтобы нагнать отставание по второму проекту - перестаешь делать задачи по первому, и уже там упускаешь ситуацию. Если ты начал отставать по какому-то проекту, то начинаешь спешить, устаешь, и конечно делать ошибки, в лучшем случае жертвовать мелкими неприоритетными задачами (просаживаясь по качеству).
Другое дело, если есть основной приоритетный проект, и побочная неприоритетная задача, которую без проблем можно двигать по срокам. Тут проще, где-то даже комфортнее, так как можно заполнить дырки и делать что-то полезное, ожидая смежников.
И это плохая новость, то что усложняются такие разводки, и рано или поздно появится правдоподобный и для опытного в ИТ сценарий. Потому что даже уже на этом кейсе чисто теоретически - можно было бы представить, когда реально платят чисто за установку apk и прокликивание стандартного сценария - например, тестирование под разные виды устройств и операционки. Т.е. если бы поставили цену пониже и предварили соответствующим текстом - то отличить и заподозрить разводку - было бы вообще очень сложно.
Тут надо другого видимо добиваться - чтобы такие разводки стали опасными для мошенников, потому что их моментально бы находили или возвращали бы деньги как минимум (например, все подобные сделки были бы, например, через отзываемые и контролируемые платежи). При текущих технологиях теоретически возможно, и тогда сам факт предложения сделать перевод не через этот сервис - был бы сигналом для человека.
Ага, а еще на них уже нет денег, потому что фрукты закончились...
Не знаю, насколько это свойственно рынку в целом, может быть это специфика моей компании, но я наблюдаю совсем другую проблему.
В погоне за эффективностью фич команды:
1) собирают "легкие плоды" - мелкие улучшения, простые с точки зрения разработки, и вроде бы обещающие денег тактически
2) делают всякие регуляторные, но бессмысленные финансово задачи (потому что продавливают методологи, регуляторы, комплаенс, ИБ и прочие подобные участники).
Проблема в том, что легкое редко приносит много денег (это бывает, но требует очень грамотного знания бизнеса и удачи), а регуляторка максимум спасет от убытков. А сложные фундаментальные задачи, без которых никогда не будет профита у компании в будущем - делаются очень тяжело. И через год-два-три накапливается тот техдолг, те недоработки - которые принесут компании в будущем очень большие убытки или будет упущенная прибыль.
Что еще хуже, такие сложные проекты разучились делать...
Я сейчас работаю в такой команде, где лидер команды - не технарь и не процессник, а продакт-мотиватор с базовым ИТ бэкграундом.
Что могу сказать - схема рабочая, но только при важных "НО":
Первое "НО":
1) либо это должна быть сработавшаяся команда мотивированных профессионалов (все слова важны), которые по сути дела внутри себя поделили как-то роль техлида и при этом достаточно компетентны, чтобы не завести систему в тупик. Ну т.е. не команда джунов :)
2) либо в команде должен быть все таки еще и техлид, также с хорошими софт-скиллами, погруженный в техническую часть, и заинтересованный в том, чтобы развивать систему долгосрочно.
Иначе - максимум год-два и система станет неуправляемой, а люди накапливать усталость и процессные ошибки. Как правильно сказано - продакт-нетехнарь - он и непроцессник тоже. А значит если он мотивировал команду работать на продукт - то она почти неизбежно встанет на сторону бизнеса и будет пытаться сделать быстро, копя технический долг. Если в ней мало или отсутствуют опытные специалисты уровня синьора (или сеньоры даже есть - но не хотят или не умеют делиться опытом) - она начнет наступать на грабли и изобретать велосипеды в коде и в процессах, и некому будет подсказать, что все это уже имеет общепринятое решение.
В статье есть тимлид - значит схема рабочая. У нас от тимлидов одно время отказывались, и, на мой взгляд, последствия этого в некоторых командах не очень. (
Второе "НО":
"Нетехнарь" должен хорошо знать свой продукт и бизнес, иметь авторитет на уровне руководства, но при этом понимать, что "есть только одно правильное мнение и оно мое" - это не для такой схемы управления, досконально погружаться в вопросы команды по бизнес-части, не давать невыполнимых обещаний за команду и понимать, что команда не может давать хоть сколько-то вменяемые оценки задачи по ее заголовку. Т.е. быть хорошим продактом и умным человеком :)
Плюсы в схеме с продактом-нетехнарем, которые вижу:
1) я работала на подобной роли, будучи технарем. Так вот, 30-40% времени вынужденно занимало общение с топ-менеджментом, руководством и коллегами со смежных подразделений. С учетом того что на продумывание тактических планов и стратегии нужно тоже 20-30% времени хотя бы, по факту на взаимодействие с командой оставалось не так много времени, половина из которой уходило на рутину. Этого не хватало на нормальное выстраивание технических процессов, то есть по итогу мой технический бэкграунд все равно давал не так много профита именно для этой роли, но и второго лида-технаря в команде не было. А так - имеем двух лидеров, каждый фокусируется на своей части и теоретически успевает ее проработать качественно.
2) нетехнарь имеет мышление ближе к пользовательскому и если команда пытается сделать быстрее, но неудобно для пользователя - то техлид может это упустить, а хороший продакт не должен
Минусы: мало хороших продактов встречала. Сейчас работаю в подобной схеме, и считаю что нашей команде повезло, а вот в других командах наблюдала полный треш с такой схемой (((, когда либо продакт сильно давит на команду (не понимая границы реализуемости), либо не уделяет времени команде, либо даже просто не понимает бизнес-задачи. Т.е. нельзя путать "продакта-нетехнаря" с "любой человек с любым образованием, разберется по ходу что там делать". Это тоже профессия, которая тоже требует ИТ-бэкграунда, просто другого.
Жизнь есть жизнь, бывают срочные задачи, не всегда вообще понятно что делать на 2 недели вперед, если динамика продукта требует менять состав задач - на мой взгляд не надо быть фанатиком, и менять. Например, из недавнего опыта в команде - то ли надо будет делать регуляторные требования с дедлайном 2 недели, то ли нет, узнаем через пару дней после начала "спринта".
Но в этой ситуации, на мой взгляд, менеджмент также должен быть честен и признаться что это не спринт, например перейти на Канбан ))))
Scrum вообще далеко не везде можно натянуть на компанию, процессы и команды, и пытаться не надо, если не лезет.
Хм, а что, никогда не бывает шестой причины сопротивления изменениям - потому что они объективно ухудшают процесс работы в команде (или на языке статьи - потребности работать в эффективном и осмысленном процессе, а не копать яму и потом ее закапывать каждый день без смысла)? Хотя конечно, такого же быть не может, бред какой-то :)
Конечно же, и то что пишете - тоже может быть. Но на моей практике, чаще сопротивление встречают непродуманные изменения (когда с высоты птичьего полета все красиво, а при реальной эксплуатации куча вопросов и проблем), или изменения которые заведомо дают профит на уровне вне команды (компании в целом, топ-менеджмента, лида), но в команде ситуацию либо ухудшают, либо в лучшем случае не меняют (но надо адаптироваться к новой парадигме).
Вторые изменения конечно же надо внедрять, если они реально нужны. Но обманывать себя в том, что сопротивление происходит исключительно потому что "люди такие люди", и хотят чего-то на эмоциональном, а не логическом уровне... ну в общем, такое себе. Честно признаемся - команде станет хуже, но это надо по какой-то другой причине. Иногда, если так честно и сказать людям, и еще и объяснить причину, они побухтят, но смирятся.
Первые же изменения - это крайне интересная штука, команда не всегда находит слова, почему так нельзя. Ну просто потому что надо объяснить иногда очень спефицические вещи, и кажется что сопротивление просто так. И на мой взгляд крайне важно уметь понять эту ситуацию, иначе всегда будете "эффективным менеджером", а не реально полезным менеджером. Потому что иначе не очень принципиальная команда на самом деле в итоге примет ситуацию, и вы обрадуетесь, что все, победили сопротивление. Только вот результат по факту ухудшится, может не сразу, или несущественно (поэтому будет не так заметно).
Хм, а не приходило в голову то, что придумать идею просто тупо легче, чем ее реализовать? И сгенерировать 1000 идей в бэклог можно за пару недель, 10-50 из них будут даже реально ценными, а сделать одну более-менее приличную идею (а не мелкое улучшение) в лучшем случае месяц-два?
Ну то есть никто не спорит, что команда важна, и если команда хронически не делает то, что сама (без давления) обещала, то возможно им действительно не хватает опыта (и то возможно, что не опыта, а например каких-то инструментов, утыкаются в какие-то внешние аспекты).
Но если бэклог проекта растет быстрее чем решается, это означает только одно - генератор идей хочет реализовать все, не учитывая, какими ресурсами обладает. И даже суперкоманда имеет ограниченную пропускную способность, выше которой не прыгнуть.
Стресс больше всего вызывала всегда несправедливость и агрессивная некомпетентность, неважно чья и от кого. Все остальное можно пережить. Когда работала на менеджерской позиции, все время был сплошной стресс, так как там этого полно. К счастью, сбежала обратно в специалисты, и безумно довольна.
Проблема с оценкой сроков - в том, что это приемлимо для типовых задач с относительно достаточными вводными и всеми выделенными вовремя ресурсами.
Ну т.е. если опытную секретаршу попросили перепечатать с рукописи книгу, при этом показали ее, и дали компьютер - то названный ей срок относительно реален.
А если спросили построить дом, по которому нет ни проекта, ни графика поставок материалов, а есть только картинка внешнего вида?
Я не отрицаю, что какие-то оценки сроков нужны даже по таким задачам, чтобы как-то ориентироваться на стыковку с другими делами. Но совершенно точно не вина сотрудника, если он ошибся.
Я точно знаю, что если в моей компании отменят удаленку, я буду искать другую работу, а не читать хабр по дороге :) . Удаленка - единственный вариант уравнять сельского ит-шника с москвичом. Ограничивать себя в месте жительства только локациями близко к крупным хабам - очень плохой вариант. Муж успешно проходил до оффера в Яндекс, не пошёл по своим причинам - сейчас подтверждается, что не зря...
Я не в Яндексе, но тоже в большой компании. Увы, такие решения часто топы принимают из моды или эмоций, а не со смыслом. Прочитали статью, что Маск так делает (и не важно, что там другие условия). Или другой гендир вашему гендиру в кулуарах сказал, что своим отменит удаленку. Или ваш гендир посмотрел что ближний круг подчинённых действительно расслабился, но экстраполировал на всех, а не только на провинившихся. В лучшем случае - сравнил показатели эффективности до удаленки и после, увидел реальную отрицательную динамику, но цифры же надо интерпретировать (а динамика, например, из-за стресса от событий в стране, и удаленка не причём).
Дело усугубляет то, что топы действительно менее эффективны на удаленке, так как их работа - общение между собой, и договориться с другим подразделением сложнее без живого контакта. Но редко думают, что специфика работы разная, и экстраполируют это на всех.
А ещё - может быть хотят посмотреть вживую на настроения сотрудников. Думают, что на это как то можно повлиять.
В общем, на самом деле это плохо. Эффективность в Яндексе конечно не поднимется, так как не удаленка тому виной, а скорее мотивация, компетенции, действия самих руководителей итп. Но вот если крупняк так начнёт делать (а дурное дело заразительно), то упадёт уровень жизни у сотрудников за счёт сгорания времени на дорогу, и повысится конкуренция за удалённые места. В проигрыше и компания, и люди. В выигрыш компании - не верю.
Подскажите, вы отвечаете за некий бизнес блок, и я так понимаю - за вами закреплены несколько ИТ команд. Но, предполагаю, что эти команды развивают конкретные сервисы и системы. А, вероятно, бывает что ваши заказчики хотят чего-то, что не относится к сфере работы ваших команд. Как вы такие задачи разруливаете? Передаёте полностью коллегам, или курируете все же сами или как-то ещё? И второй вопрос, вытекающий из первого. Если есть задачи или подзадачи, которые зависят от других команд - как вы решаете конфликты приоритетов?