После обсуждения общих рекомендаций по достижению уровня Intermediate + в разработке PHP в части 1 и важности окружающих вас людей в части 2 , эта статья будет сосредоточена на социальных аспектах командной работы и инициативы и послужит введением в более конкретную и Практическая командная статья скоро появится.
Важно отметить, что когда я говорю «командная работа», я имею в виду не только команды, работая на более крупную компанию — корпорацию или компанию, в которой вы являетесь небольшой подгруппой. Команда — это также группа фрилансеров, работающих вместе над проектом — либо рядом, либо удаленно. Всякий раз, когда вы работаете с кем-то в любом качестве — это команда. Свободная команда, но, тем не менее, команда.
Знай свою роль
Ни для кого не секрет, что мы, разработчики, склонны иногда быть крупными — во всех сферах жизни, а не только в кодировании, — особенно когда им дают (или преуспевают) задачу среднего или высокого уровня важности. Это дает нам ощущение ложной безопасности, и мы склонны забывать, что на самом деле мы не знаем всего .
Вполне естественно, что мы чувствуем, что мы важнее, чем позволяет наша назначенная командная роль. В такие времена важно отступить, остыть и посмотреть на вещи с другой точки зрения. Поставьте себя на место других членов команды и посмотрите на себя издалека. Поймите, почему вы там и что вы должны делать, и уважайте тот факт, что у каждого члена команды есть определенная цель.
Возможно, вы лучше разбираетесь во внешнем проектировании, чем член команды, которого они наняли на эту должность, но если вы там работаете с PHP, подумайте о том, как добиться публичного объявления такого факта. Хотя передний конечный разработчик может быть посредственным, вы были посредственны и в одном — без опыта работы над различными проектами вы никогда бы не переросли посредственность. Кроме того, что можно получить путем замены указанного члена? Если участник действительно плохо выполняет свою работу и наносит ущерб проекту, во что бы то ни стало, это должно быть доведено до сведения руководителя группы. Но если он просто «в порядке», замена его может фактически оказать негативное влияние на ход работы, вызывая ненужные задержки.
Если публично не заявить об этом факте, это может привести к еще худшим последствиям — это может посеять несогласие в рядах, заставив других членов команды занять оборонительную позицию против вас из-за вашей закулисности или занять агрессивную позицию по отношению к человеку, с которым у вас возникли проблемы. Опять же, это не здорово для команды в целом. Самым здоровым решением, безусловно, является дружеское обращение к человеку, предоставление советов и все открытые обсуждения.
Но что, если это руководитель проекта, который настолько плох, что наносит вред проекту? Что ж…
Уважать начальство — до некоторой степени
Начальники как старейшины — их нужно уважать, но в определенной степени. Конечно, я послушаю, что скажет моя бабушка. Она была здесь намного дольше, она, по крайней мере, пассивно впитала некоторую мудрость, которую она может передать. Но если она начнет пытаться промыть мне мозги со старыми привычками и взглядами, ее близость сделает меня невосприимчивым к ее словам.
То же самое с начальством в команде. Уважайте их решения, принимайте их советы. Если кто-то выше на корпоративной или командной лестнице, чем вы, есть причина для этого — и чаще всего это на самом деле умение и опыт, вопреки убеждениям многих людей. Имейте в виду, что все, кого вы встречаете, знают что-то, чего вы не знаете, и будьте восприимчивы к их мнению, даже если вы с ними не согласны — зачастую из несогласия можно узнать больше, чем согласие. Небольшая разница во мнениях может быть исследована и обсуждена продуктивно, и кто-то гарантированно выйдет из ситуации со знаниями, которых у него не было раньше.
Правда, есть и темная сторона. Временами единственная причина, по которой кто-то превосходит вас, заключается в том, что они лучше связаны с владельцем проекта. Эти обстоятельства обычно сначала не очевидны, но со временем они всегда становятся полностью прозрачными. Исходя из опыта, симптомы некомпетентности могут быть любыми: от отказа от перехода с PHP 5.2 в 2012 году на совершенно новый проект до противоречия с самим собой в задачах, просто чтобы скрыть предыдущие ошибки в суждениях. Скоро их плохие звонки начнут наносить ущерб проекту — достаточно скоро, все, что идет хорошо, будет таинственно приписано им, и все, что пойдет не так, потребует козла отпущения в команде. Этот тип людей, как правило, отлично отвлекает внимание и вводит в заблуждение, чтобы сохранять свою позицию как можно дольше, потому что его высокий рейтинг обычно включает в себя бонусы или другие привилегии — и если проект в конечном итоге проваливается, это всего лишь одно черное пятно в их резюме , но толстый банковский счет и много влияния.
Когда вы обнаруживаете такую среду, нет рационального способа ее починить. Переход к владельцу проекта, как правило, не имеет смысла, потому что они либо слишком привязаны к человеку (кровные родственники, личные друзья), либо полностью одурачены — и последний, как правило, хуже, потому что чем дольше длится ситуация, тем меньше желание генерального директора или владелец проекта начинает признавать, что его все время обманывали. Подобные проекты обычно рушатся и горят после длительного состояния плато, так что…
Не бойся уходить
Когда вы понимаете, что это может быть так, важно не бояться уходить. Временная защита, которую предлагает работа на этом этапе, просто временная. Помните, проект рухнет и сгорит, несомненно, это всего лишь вопрос времени. Ситуация не может быть исправлена без смены руководства, а изменения в менеджменте происходят не так часто.
Вы всегда должны быть в поисках лучших предложений, но когда вы окажетесь в сложной ситуации, начните активно искать. Ходите на собеседования, подайте заявку на проекты, просто не будьте пассивны. Трудно, когда у вас есть иждивенцы, и риск потери регулярной зарплаты может быть очень тяжелым для психики, но поверьте мне, когда я говорю, что пребывание в такой среде может быть еще более тяжелым, не только для вас, но и для окружающих и вам того же.
Я пишу из личного опыта. Я был вынужден оставить свою работу из-за этих точных условий, но вместо того, чтобы согласиться на аналогичную оплату с другой ИТ-компанией, я решил пойти на внештатную работу. Работа на фрилансе позволила мне выбирать свои собственные проекты и клиентов, выбирать технологии, которые мне нравятся или интересуются, и узнавать больше, чем я мог бы узнать, оставаясь в неудачной команде.
Вывод
Хотя эта статья имеет мало общего с PHP, это мнение и опыт специалиста по PHP. Это также предшествует следующей статье о командной работе, которая будет охватывать удаленную работу, парное программирование, работу с различиями часовых поясов, типы командной работы и многое другое.
Что бы я хотел, чтобы вы отняли у этой части, — не будьте рабом обстоятельств. Будьте вежливы, профессиональны и честны, но не бойтесь покидать ядовитую среду — это вредит вам, людям, которые вас любят и поддерживают, и, наконец, проекту, над которым вы работаете. Я ушел, и лично мне еще только предстоит оглянуться назад.
У вас есть какие-нибудь командные страшилки? Истории успеха возможно? Отношение отличается от представленных в этой статье? Позвольте мне знать в комментариях ниже.