Как показать свою потребность в командном взаимодействии, не выглядя при этом бездельником?

Я работал на стажировках в течение последних 2 лет, и по крайней мере дважды я был в ситуации, когда у меня был свой собственный проект.

В первый раз, когда это случилось, я занимался тем, что мне нравилось гораздо больше (разработка программного обеспечения), и у меня был начальник, на которого я мог рассчитывать в любой момент.

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

Тем не менее, последние 4 месяца я работал над проектом, который долгое время был на заднем плане, и мне поручили запустить его, начав с «документирования». Однако, в отличие от моего первого опыта, мне не особенно нравится документировать документацию (особенно работу, которую не делаю я или кто-либо из моих близких), и у моего начальника, кажется, всегда есть что-то более важное.

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

Как я могу объяснить руководству/подрядчикам, что я лучше всего работаю в командной среде, и при этом не показаться предлогом, чтобы заставить кого-то выполнять мою работу?

"проект, который долгое время был на заднем плане, и мне поручено дать толчок его запуску, начиная с "документирования материала"" Я знаю это чувство, бро. Буквально то, чем я сейчас занимаюсь.
@JoeStrazzere Я имел в виду, что в следующих проектах я намерен ясно дать понять, что я полностью раскрываю свой потенциал, работая с коллегами над одним проектом, а не сижу в углу, пишу документы.
Если вы чувствуете боль от людей из TW, позвольте мне сказать: «Я чувствую вашу боль». У TW должны быть одни из наименее дружелюбных/конструктивных лицемеров в семье SE.
Кажется, я работал с кем-то вроде тебя. В команде он думал, что я должен делать документацию, потому что ему это не нравилось. Ну и я тоже! Я сделаю это, если это необходимо сделать, но я воздержусь, если вы просто пытаетесь получить все самое интересное для себя — это не командная работа.
OP означало «необходимость командного взаимодействия», а не «командную работу». Совершенно нормально отдавать предпочтение задачам с командным взаимодействием. Он не просил расслабиться.
Каждый может предпочесть те задачи, которые ему нравятся. Это не значит, что они всегда будут получать их. Как я сказал в комментариях к моему ответу, вполне приемлемо продолжить текущую задачу, хорошо поработать, а затем указать, что вы предпочитаете командные проекты. Все, что он сейчас говорит по этому поводу, звучит так, будто он хочет, чтобы его работу выполнял кто-то другой.
Хотя я уже выбрал один ответ, потому что считаю, что он лучше всего отвечает на конкретный вопрос, не стесняйтесь делиться своими мыслями по этому поводу. Даже ответы, которые не были приняты, помогли, так что спасибо и за это!

Ответы (10)

Держите это очень простым. Многие комментарии здесь оскорбительны, чрезмерно анализируют или незначительно оффтопичны. Вам не нужно сформулировать манифест для парного программирования и т. д. Однако вам нужно определить, в чем заключается ваша точка зрения, и кратко объяснить руководству, почему в их интересах давать вам такие задания. (Им все равно, весело вам или нет).

  • Вы имеете в виду «потребность во взаимодействии в команде», а не «работу в команде». Совершенно нормально предпочитать задачи с командным взаимодействием, а не сидеть в углу, работая в одиночку над проектом, который считается неважным.

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

  • Поэтому, когда вы разговариваете с руководством, вы хотите сказать что-то вроде:

> Проектное задание, которое мне больше всего понравилось, было командным проектом, в котором я мог сотрудничать и помогать другим (младшим?) людям.

>Я чувствовал, что многому научился (в частности, чему? психологии команды? управлению проектами? как наставлять? конкретным техническим вещам? и т. д. хорошо для них , а не только весело для вас.

Вы же не хотите просто сказать что-то расплывчатое и небрежно звучащее, например: «Мне нравится работать над задачами, изначально не поставленными передо мной». потому что из-за этого тобой трудно управлять.

Так в чем твой смысл?? Если свести все к минимуму, руководство будет заботиться о:

  • "Я преуспеваю в наставничестве младших сотрудников"?
  • «Я обнаружил, что хорошо разбираюсь в управлении проектами»?
  • или что? Вы должны понять это

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

Я думаю, что это (по иронии судьбы) правильно: я должен придерживаться прошлого опыта (и почему это сработало тогда) и какие преимущества это принесет (как с учетом моего удовлетворения, так и удовлетворения других коллег).
@ravemir: большинству работодателей плевать на то, насколько вы счастливы, поэтому фраза «Эй, чувак, я не чувствую стимула делать это» совсем не убедительна. В общем, вы должны убеждать людей в их терминах, а не в своих.
@smci Я бы сказал, что многие работодатели заботятся о вашем счастье ... до тех пор, пока это им ничего не стоит. (Тогда это зависит от вашей корпоративной культуры). Но да, во всех деловых взаимодействиях ваша цель — удовлетворить другого человека, надеюсь, таким образом, который удовлетворит вас. Поэтому, если вы хотите переключить передачу, вам нужно заставить их захотеть, чтобы вы переключили передачу, иначе вы просто будете вынуждены вернуться к тому, что, по их мнению, принесет им наибольшую пользу. (Печальный факт, очень немногим нравится документировать. В лучшем случае они принимают это как необходимость, чтобы избежать страданий в будущем. Хотя это также отличное место для обучения...)
@RualStorge: возможно, в других контекстах, но в контексте того, что некоторые малопонятные устаревшие POS необходимо задокументировать, и кто-то должен это сделать ...
@smci Я согласен, я имел в виду, что это похоже на бесчисленное множество других вещей, которые очень немногим нравятся, но понимание спасет их от горя позже. Когда это отстает, кто-то, к сожалению, должен сесть и сделать это. Хорошая новость заключается в том, что создание документации иногда является лучшим способом изучить все тонкости приложения.

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

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

Думаю, я неправильно сформулировал вопрос: как я могу сказать, что лучше всего работаю в командной среде, и при этом не прозвучать как предлог, чтобы заставить кого-то взять на себя мою работу?
Кроме того, у меня нет особой проблемы с документированием вещей (особенно не программных проектов): тот факт, что это устаревший, заброшенный проект, делает его немотивирующим. В общем, смотрите на эту старую никому не интересную коробку и описывайте все, что видите.
@ravemir: У каждой компании есть демотивационные проекты на втором плане. Именно поэтому они отодвинуты на второй план. И, как вы поняли, они идеально подходят для передачи стажерам, поскольку больше никто не хочет ими заниматься. Часто проекты не требуют команды. Я думаю, вам лучше всего преуспеть в этом дерьмовом проекте, а когда вы закончите, укажите, что, хотя вы, очевидно, способны работать над проектами в одиночку, вы предпочитаете командную среду.
Спасибо за совет! Часть меня просто боится, что я теряю поток в последние месяцы, наверное...
Вы не отвечаете на вопрос!
@martinfo На самом деле, я был, но он (она?) изменил это. Первоначальный вопрос был в основном «как мне заставить руководство сделать это командным заданием, не звуча как бездельник?» С правкой ОП пояснил, что он / она всегда предпочитает командную среду, а не только для нежелательных проектов.
Редактирование не имело отношения к тому, что ваш ответ не соответствует действительности. ОП спрашивает, как общаться, а не как лениться. Возможно , ОП «упускает из виду», но если вы игнорируете поставленный вопрос и предполагаете, что что-то другое более важно, вам действительно следует быть намного более вежливым / скромным.
Документирования может быть много, но я не думаю, что продуктивно поручать одному человеку «документирование материала» в течение четырех месяцев, особенно если он вообще не работал над проектом, и у него нет ни одного коллеги. Ни обратной связи, ни достижений, ни способа сказать, правильно ли вы это делаете, я не могу представить, чтобы кто-то хорошо справился с такой задачей.
Мой вопрос на самом деле относился к тому, как сформулировать этот аспект себя: что я лучше работаю со сверстниками, даже если они не работают над той же конкретной задачей, что и я (тот же проект или черт возьми, даже тот же предмет подойдет)
@ravemir (старая ветка, я знаю), если это так, вам следует уточнить вопрос. Это звучит как напыщенная речь о том, что вы не хотите выполнять нежелательную задачу. Откровенно говоря, ваш комментарий делает вопрос гораздо более разумным. Трудно быть изолированным, и вполне разумно просить, чтобы ваше рабочее пространство было, по крайней мере, вокруг других людей, работающих над аналогичными проектами (например, других разработчиков, других бухгалтеров и т. д.).

Возможно, вы могли бы поговорить с вашим менеджером и изъявить желание попробовать парное программирование .

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

Подойдите к этому так: «Я проводил некоторые исследования различных методологий разработки, и я думаю, что это могло бы повысить производительность, если бы мы приняли парное программирование. Было бы нормально, если бы я опробовал этот подход в течение нескольких недель с <name of предпочитаемый вами сверстник>?». Тогда вместо бездельника вы предстаете человеком, который 1) заинтересован в том, чтобы помочь компании стать более эффективной/продуктивной/успешной, 2) хорошо осведомлен об отрасли в целом и 3) готов экспериментировать с новыми вещами, чтобы увидеть, работают ли они. . Все это хорошо, особенно если вы хотите перейти от статуса «стажера».

LOL, менеджеру... "парное программирование = половина ресурсов"
Возможно, для наивного менеджера, который не умеет читать кейсы.
Это как... все они, верно? По крайней мере, в реальном мире.
Зависит от устремлений указанной компании. Я родом из места, где разработка программного обеспечения не является гламурной карьерой, но я все же обнаружил пару мест, где это было общепринятой практикой. Любопытно, что некоторые из этих примеров также более непосредственно заботились об удовлетворенности сотрудников (премиальное оборудование и окружающая среда, закуски, посещение конференций и т. д.). Я признаю, что они редки, хотя...

Я думаю, вам нужно более четкое объяснение «почему». Хотя бывают случаи, когда парное программирование считается идеальной установкой, оно не часто связано с потребностями в документации. А поручить работу по очистке документации — это честная работа в индустрии программного обеспечения. Это вообще не весело и не гламурно, и я не знаю никого, кто бы это любил, но в некоторых средах приходится работать.

Так что - я думаю, вам нужно ответить для себя - какую пользу даст пир? Будет ли это кто-то, у кого есть знания, которые вам нужны? Кто-то с другим набором навыков, который может помочь с более всесторонней и качественной продукцией? Ответ заключается в том, что не делается или не делается хорошо, потому что у вас нет ресурсов (времени, навыков, знаний, доступа) для этого?

К сожалению, «интерес» не входит в число причин, по которым вам может понадобиться партнер в усилиях. Скука — это часть работы, и только потому, что вам не нравится работа или она не интересна в данный момент, это не причина избегать ее. Если это действительно единственное, чего вам не хватает, вам придется найти способ мотивировать себя, чтобы пережить скучные времена... хотя будет справедливо спросить - если работа с документацией станет бесконечной - когда объем будет закончен, и когда вы сможете перейти к чему-то более веселому.

Другой трюк заключается в том, чтобы иметь возможность попросить что-то, что не так уж сложно выполнить. Хотя наличие технического писателя для проверки вашей работы может быть возможным в месте, где есть реальные инвестиции в людей с навыками письма, в компании, где всего несколько (или нет) технических писателей, это настоящая битва, а не та, которую вы скорее всего выиграют. Тем не менее, попросить кого-нибудь из QA дать обзор вашей работы или другого инженера, чтобы убедиться, что вы рассмотрели все аспекты, - это довольно простая просьба в большинстве команд...

К сожалению, я думаю, что дело обстоит именно так: я чувствую себя немотивированным, потому что моя работа выглядит скучной и неактуальной. Наличие коллеги помогло бы, потому что это дало бы мне кого-то, чтобы обсудить работу, которую нужно сделать, и чувство вовлеченности в целом. Это наивно/эгоистично?
Немного. Разговор на тему «Что нам НА САМОМ ДЕЛЕ нужно сделать?» это то, что вы должны иметь возможность быстро обсудить с вашим боссом, а не то, что требует дней и дней чьего-то времени. Это сводится к стоимости - если кто-то является вашим партнером в этом, то компания удвоила стоимость рабочей силы. Стоимость должна быть оправдана для компании, а не только для вас. Если два человека могут работать в течение Х дней, тогда как вам одному потребуется БОЛЕЕ 2Х дней, чтобы сделать это, то это полезная сделка. Если нет, то это становится предметом дискуссий.
Также – в жизнь каждого выпадет какая-то скучная, бесполезная работа. Лучший ответ из всех — если работа ДЕЙСТВИТЕЛЬНО бесполезна — сделайте ее быстро с минимальным необходимым минимумом. Тогда, по крайней мере, это заняло как можно меньше вашего времени на этой планете.
Итак, если я правильно понял вашу точку зрения, если я не могу понять смысл своей работы, я должен попытаться как можно больше прояснить это со своим боссом, верно? В идеале это должно привести к более четкому пониманию конечных целей или обоюдно согласованному направлению проекта к чему-то более полезному.

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

Разбивка моего аргумента (отнеситесь к этому с недоверием):

  • «долгое время отодвигается на второй план» -> Важные дела, как правило, выполняются. Если какое-то задание надолго зависает в резерве, значит, с ним что-то не так. Либо это не важно, либо это скучно, либо все знают, что их имена, связанные с этим, - это определенный убийца карьеры.

  • «Мне поручено запустить его» -> Важные вещи не передаются стажерам. Если они важны, над ними работают лучшие люди в команде. Слишком опасно рисковать неудачей, потому что над этим работает кто-то, у кого недостаточно опыта или знаний.

  • «документировать вещи» означает «сделать что-то. Я не знаю, что и как; вы разберетесь. А если вы этого не сделаете, то вы явно некомпетентны, поэтому я должен вас уволить».

Если мое предположение верно, то никакая командная работа вас не спасет.

Так что ты можешь сделать? Вот несколько предложений:

  • Поскольку проект обречен с самого начала, вы можете превратить его в обучающий опыт.
  • Попробуйте научиться задавать вопросы и писать документацию. Это не спасет проект, но пригодится вам позже, несмотря ни на что.
  • Научитесь собирать и представлять информацию. Начните с обзора, разбейте его на детали. Почувствуйте, как разбивать сложные вещи. Один из самых важных навыков в разработке программного обеспечения, IMO: способность объяснить что-то безумно сложное менеджеру.
  • Изучите новые инструменты: текстовые процессоры, инструменты отчетности, интеллект-карты. Все, что может помочь в вашем проекте, также всегда будет хорошим пунктом в вашем резюме.
  • Совершенствуйте свои языковые навыки. Вы хотите, чтобы я написал документацию? Есть этот хороший Оксфордский курс английского языка за $$$$! Нет? Может тот за $$$? Хороший! Еще один пункт для моего резюме.
  • Научитесь задавать вопросы. Если кто-то не может объяснить что-то сложное, нужно уметь задавать правильные вопросы. Это включает в себя обучение терпению и работу с трудными людьми (= люди с большим стрессом, мало времени, мало терпения, неуклюжие или не имеющие социальных навыков или просто не имеющие времени, чтобы быть милыми). Как мне получить эту информацию от мистера X, не теряя его времени?
  • Вы уже знаете все, что нужно знать для написания полезной документации? Если нет, то вам нужно научиться организовывать встречи, находить нужных людей для приглашения и т. д. Это тоже своего рода командная работа.

Чего не следует делать:

  • Скулить. Они платят тебе за это деньги, так что смирись с этим. А нытиков никто не любит.
  • Проводите 99% дня в Интернете. Это только навлечет на вас неприятности.
  • Перестаньте получать удовольствие от своей работы. Это было бы просто пустой тратой вашего времени.

Что вы можете сделать:

  • Спорить. Если у вас есть веские причины считать этот проект пустой тратой времени, возможно, вам стоит создать презентацию того, что вы узнали, и рассказать людям. «Я только что спас компанию $$$$»
Я на 100% согласен с вашими предположениями, и я бы добавил к списку вещей, которые он может сделать: фактически дать толчок проекту . Узнайте, кто на самом деле хочет этот проект и почему, и сделайте этих людей своими «товарищами по команде» (просто говорите с ними при каждом удобном случае). Подумайте, что действительно необходимо сделать, чтобы сдвинуть проект с мертвой точки, и приведите его в движение. Запишите больше, чем обычно, чтобы у вас была документация, на которую можно указать. В худшем случае вы можете выяснить, почему необходимо начинать с документирования.
Хороший ответ и комментарии. Кроме того, вчера я узнал, что документ, который я частично написал еще в январе, может быть снова полезен, поскольку кому-то удалось убедить моего менеджера принять подход, который я предложил ему еще в январе. Наконец, найти кого-то, кто хочет взять это со мной, может быть сложно в моем окружении, но это, безусловно, хорошая идея.
@RemcoGerlich: +1 Это важный момент, который я полностью упустил :-)

Создать/быть себе равным?

Используйте гибкий подход, выберите часть работы с документацией, разбейте ее на задачи, пока у вас не будет достаточно для спринта, и сосредоточьтесь на выполнении/завершении работы небольшими шагами.

Работа в одиночку требует гораздо большей самодисциплины, легче «бродить» и не сосредотачиваться на том, что нужно сделать. Что-то вроде гибкой методологии может помочь вам сосредоточиться, и вы получите опыт, ценный для вашего резюме, когда вы подаете заявку на новую работу, где вы действительно работаете часть своего времени, а не сидите в углу, бормоча себе под нос.

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

И не заводите меня на шум XML-комментариев, массово производимых в коде, чтобы констатировать очевидное, когда ваши методы и классы правильно названы.

Мне понравилась гибкая методология, и я думаю, что она может помочь мне преодолеть «блуждающую» колею. Я думаю, я мог бы просто сделать это. Спасибо, это может не ответить на исходный вопрос, но все же полезно.

Попросите разнообразить свой способ работы.

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

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

Судя по всему, «запуск» процесса документирования кода означает «никто на самом деле не хочет этим заниматься, поэтому ПОЖАЛУЙСТА, начните, чтобы другие могли последовать за вами».

Я храню документ обо всех изменениях моего кода, обновляемых при каждой новой сборке кода, которую мы делаем, и я знаю, что мой коллега делает то же самое. Проще говоря, это задача, которую вы должны выполнить, и, вполне возможно, задача, которую можете выполнить ТОЛЬКО вы (по какой бы причине ни подумал ваш босс), поэтому есть ряд причин, по которым вам может понадобиться выполнить ее в одиночку.

Разве его не просят документировать чужой код?
Хорошая мысль... так что, если это так, любой другой ДОЛЖЕН иметь возможность это сделать... редактирование
В том-то и дело: часть проекта включает в себя PHP-портал, разработанный собственными силами несколько лет назад. Но в целом это устройство брандмауэра VM, разработанное сообществом FOSS.

Я думаю, что вы "переосмысливаете" это. Дело в том, что вы хотите хорошо справляться со своей работой, а ваш начальник хочет хорошо справляться со своей работой.

Поэтому вам нужно донести до него информацию, которую вы считаете важной для работы менеджера. Вы думаете о том, как приукрасить его.

Здесь используются следующие метрики менеджера:

А и Б вместе выполняют больше дел, чем А и Б, выполняя отдельные задачи. Это метрика того, позволять ли людям объединяться.

Разница между тем, что А сделает вместе с Б, и тем, что А может сделать в одиночку, более ценна, чем зарплата Б. Это показатель того, не проще ли просто отпустить Б.

У вас есть соответствующий опыт для этого. Своевременное предоставление этой информации менеджеру помогает ему более эффективно нанимать вас. Он все еще может рисковать, и вам нужно убедиться, что вы не превращаете свои прогнозы в самоисполняющиеся пророчества, превращая их в «я же вам говорил».

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

Так что это хорошая идея найти кого-то, кто действительно оценит идею командной работы здесь.

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

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

Как показать свою потребность в командном взаимодействии, не выглядя при этом бездельником?
СпросиСетьПолитика конфиденциальности1y, 0v