Что делать после того, как я закончу все свои задачи, а у моего менеджера нет задач, чтобы дать мне? [дубликат]

Иногда, после того как я выполняю все свои задачи, у моего начальника нет задач, которые можно было бы мне дать. Вот сижу и плохо себя чувствую, что ничего не делаю. Кроме того, я не уверен, могу ли я работать в Интернете и заниматься своими делами или выглядеть занятым?

Что стандартно делать в этой ситуации, когда у меня нет задач от моего менеджера?

Этот вопрос очень похож на ваш: worker.stackexchange.com/questions/3408/…
Спросите своего босса, что вы должны делать в свободное время.

Ответы (4)

Есть множество вещей, которые вы могли бы сделать, я перечисляю те, о которых я подумал ниже. Комбинация может быть лучшим способом пойти.

  • Вы можете разработать или улучшить документацию и/или процедуры о том, как вы выполняете свою работу, как используются ваши продукты и т. д. Это улучшит ваши знания в этих вещах, а также может порадовать руководство, поскольку им будет более комфортно знать, что кто-то другой может работать с этой документацией, если это необходимо.
  • Как говорится в ответе alroc , вы можете заниматься профессиональным развитием. Это может быть самостоятельное обучение чему-то, чем вы сейчас занимаетесь, или чему-то, к чему вы могли бы перейти. Например, разработчик программного обеспечения может улучшить свои знания методологии разработки, языка программирования или другой технологии. Или он/она может узнать об управленческой практике, если движение в этом направлении представляет интерес. Это подготовит вас к будущему (и сделает вас более привлекательным для других работодателей).
  • Вы можете просмотреть вещи в своей организации и посмотреть, сможете ли вы их улучшить. Придерживаясь примера разработки программного обеспечения, вы можете найти некоторый код, который нуждается в улучшении, и отрефакторить его. Это улучшит работу вашей организации
  • Узнайте что-нибудь о другой области вашей организации. Это улучшит ваше общее понимание того, как все работает там, где вы работаете, что может быть полезно для решения организационных проблем, получения продвижения по службе и т. д.
  • Общайтесь внутри своей организации, чтобы у вас было больше людей (и вы лучше знали, к кому обратиться), чтобы помочь вам, когда вам это нужно.
  • Потратьте некоторое время на наставничество нового человека. Это создаст для вас союзника, а также сделает вашу организацию лучше.
  • И, конечно же, ничего. Если вы иногда работаете дополнительное время, вы можете рассматривать это как время простоя, чтобы компенсировать дополнительное время. Если вас беспокоит внешний вид, вы можете приходить немного позже, чем обычно, немного дольше обедать и уходить немного раньше, чем когда вы полностью заняты работой. Если это вас не беспокоит, возьмите выходной и займитесь чем-нибудь, что вам нравится. Это поможет вам расслабиться и лучше работать, когда придет время.

Если в вашем отделе нет другой работы, найдите время для «профессионального развития» — освойте новые навыки (или более глубоко изучите свои текущие навыки), чтобы стать лучше.

Пожалуйста, расширьте свой ответ и объясните, почему это лучше, чем другие альтернативы. Однострочные ответы, которые просто говорят, что это за ответ, обычно не являются хорошими ответами. Даже если вы можете дать «правильные» ответы, которые объясняют, почему помогают другим лучше понимать и принимать лучшие решения при столкновении со связанными проблемами.

Предложите помощь одному из ваших коллег. Рабочие нагрузки не всегда точно сбалансированы. Вам не нужно делать это все время и давать кому-то предлог, чтобы не делать свою справедливую долю работы. Если вы новичок в этой работе, лучше взять на себя больше ответственности.

  • Развивайте себя. Изучите кодовую базу, изучите используемые ею фреймворки, изучите язык, на котором она написана. Узнайте о других широко используемых языках и фреймворках. Узнать об оборудовании; каковы современные достижения клиентских рабочих станций, какова в настоящее время средняя вычислительная мощность рабочих станций, находящихся в эксплуатации? Что нового в серверной архитектуре?
  • Выполните общее техническое обслуживание. Если вы кодер, просмотрите кодовую базу и сделайте общий обзор кода. Если вы сталкиваетесь с чем-то, что никто активно не разрабатывает и что, по вашему мнению, можно улучшить, проведите его рефакторинг. Я говорю это, предполагая, что у вас есть хорошо проработанная кодовая база (модульные тесты, выполняющие не менее 95% общего объема операций) и, следовательно, вы можете убедиться, что ваша рефакторинговая версия соответствует всем тем же функциональным требованиям, что и оригинал. Я также предполагаю, что ваша кодовая база достаточно велика, чтобы вы могли найти что-то для улучшения, которое не подвергнет кого-то еще PMS (болезненному синдрому слияния) при следующем коммите. Наконец, я предполагаю, что вы достаточно опытны в своей кодовой базе и в общепринятых методологиях программирования, таких как GRASP/SOLID, которые вы рефакторите, а не "рефакторинг".
  • Обратитесь к собственному рабочему пространству. Приведите в порядок свой стол, организуйте материалы и т. д. Многие разработчики ценят чистоту рабочего места, в котором нет отвлекающих факторов, но у них редко есть время на его активное поддержание. Вы сказали время.
  • Помогайте своим коллегам. Если у вас недостаточно для работы, а у кого-то слишком много, спросите, может ли ваш коллега что-то разделить и дать вам, или он хочет спарить. Если вы новичок в программировании, объединение в пару позволит вам освоить новые вещи, затрачивая минимум дополнительного времени на человека, с которым вы работаете в паре. Если вы старше, вы можете распространять свои знания и обучать окружающих лучше программировать, работая в паре. Будьте осторожны, чтобы не наступить на пальцы ног; парный процесс требует определенного уровня поддержки со стороны всех участников и их руководителей, и если этого не будет, вы можете просто раздражать.
  • Поспрашивать. Если вы занимаетесь внутренней разработкой, как правило, вы можете найти, над чем поработать, спросив конечных пользователей внутреннего программного обеспечения о проблемах, с которыми они столкнулись. Соберите «требования» для будущих изменений и определите любые легко висящие плоды, которые принесут значительную выгоду при небольших затратах.
Каждый пункт в этом ответе предполагает, что читатель занимается разработкой программного обеспечения. Я понимаю, что в профиле ОП сказано, что он занимается разработкой программного обеспечения, и в моем собственном ответе это используется в качестве примера в нескольких местах. Тем не менее, я думаю, мы должны иметь в виду, что этот сайт предназначен для всех рабочих мест , а не только для магазинов программного обеспечения.
Ваш второй пункт предполагает, что у OP есть разрешение на это. В моей организации я не могу вносить изменения в код без авторизованного запроса на изменение, исходящего из бизнес-требований или обязательного изменения технической среды.
Оба они верны; Я подошел к своему ответу из собственного опыта. Большинство из этих пунктов можно обобщить и применить к чему угодно, за исключением, возможно, выполнения общего обслуживания. Re: разрешение на изменение кодовой базы, это полностью зависит от среды. В более традиционной модели разработки, где изменения требуют ручного тестирования, и поэтому внесение фундаментальных скелетных изменений по неоплачиваемым причинам не одобряется, я полностью это понимаю. В более автоматизированной среде доступны приемочные тесты для быстрого применения изменений, а рефакторинг стиля/структуры приветствуется.