Предлагаю вашему вниманию перевод третьей части цикла статей «Becoming PHP professional».
Первая часть. «Недостающее звено»
Вторая часть. «Важность других людей»

Поскольку мы уже обсудили общий курс по достижению уровня «среднячок» в сфере РНР разработки, а также роль окружающих людей, в этой статье мы сфокусируемся на социальных аспектах работы в команде и инициативе. Эта статья послужит вступлением к следующей, где мы углубимся в это понятие.
Важно заметить, что когда я говорю «работа в команде», я не имею в виду только большие команды – корпорации или компании, где вы всего лишь на вторых ролях. Командой может быть также группа фрилансеров, работающих над проектом – находясь рядом или удаленно. Когда вы работаете с кем-то над чем-либо, вы – команда. Небольшая, но, тем не менее, команда.

Знайте свою роль

Ни для кого не секрет, что мы, разработчики, имеем склонность быть самовлюбленными. Это проявляется во всех сферах нашей жизни, не только в программировании, в особенности, когда вам поручили (или вы преуспели) задание средней или высокой важности. Это завышает нашу самооценку и мы забываем, что никто не может знать всего на свете.
И это вполне естественно, когда мы считаем себя более важными, чем на самом деле являемся. В таких случаях необходимо остыть и умерить пыл, посмотреть на вещи под другим углом. Встаньте на место других членов команды и взгляните на себя со стороны. Осознайте, почему вы здесь и что от вас требуется, и уважайте других членов команды, ведь их роль так же важна, как и ваша.
Вы можете преуспевать в фронт-энд разработке больше, чем тот, кто за это отвечает в команде, но если ваша задача – РНР, то подумайте, нужно ли говорить об этом. В то время как фронт-энд может быть посредственной задачей, вы также можете быть посредственным – без опыта работы над разными проектами вы так и будете стоять на месте. Кроме того, какая польза от того, что вы замените вышеупомянутого члена команды? Если он действительно плохо справляется со своей работой и вредит проекту, во всех смыслах, нужно довести это до лидера команды. Но если он просто делает свою работу на «ОК», то его замена негативно скажется на прогрессе и станет причиной ненужных задержек в разработке.
Однако, молчать об этом тоже не стоит, ведь это ни к чему хорошему не приведет. Начнутся разногласия в команде, другие разработчики примут позицию, противоположную вашей из-за того, что вы что-то скрываете и хитрите. Также, коллектив может поддержать вас и ополчиться против человека, с которым вы не поладили. Всё это негативно сказывается на атмосфере в коллективе. Самое рациональное и безопасное для духа команды решение — это помочь человеку советом и по-дружески всё обсудить.
Но что, если лидер проекта именно тот, кто вредит проекту? Что ж…

Уважайте начальство. До определенного момента

Начальник — он как пожилой человек. Его нужно уважать, но до определенного момента. Конечно, я прислушаюсь к своей бабушке. Она многое повидала, и за свои годы набралась мудрости, которой может поделиться. Но, если она попробует промыть мне мозги своими старыми привычками и манерами, то её слова вряд ли я восприму с уважением и всерьёз.
С начальством точно так же. Уважайте их решения, прислушивайтесь к советам. Если кто-то выше вас по служебной лестнице или позиции в команде — это неспроста. И, как это часто бывает, дело вовсе не в навыках и опыте, как многие считают. Учитывайте тот факт, что любой человек знает то, чего вы можете не знать. Старайтесь прислушиваться к их мнению, даже если оно расходится с вашим, ведь и из этого можно извлечь пользу. Обсудите обе позиции, вашу и вашего собеседника, если они лишь слегка разные, и вы со 100% вероятностью узнаете что-то новое!
Определенно, есть и обратная сторона медали. Бывает так, что единственная причина, почему ваш начальник выше вас по служебной лестнице — он лучше знаком с владельцем проекта, чем вы. Поначалу, вы можете этого и не замечать, однако, со временем, всё становится ясно и прозрачно. Исходя из опыта, некомпетентность таких людей может проявиться, например, из-за отказа перейти на PHP 5.2 при разработке совершенно нового проекта в 2012 году (PHP 5.2 вышла в 2006 году, прим. Переводчика). Или же противоречивые задачи по проекту лишь для того, чтобы прикрыть свои пробелы в знаниях. Для того, чтобы такие вещи действительно навредили проекту много времени не нужно. Очень скоро все успехи по проекту будут присуждаться им, а все провалы спихнут на местного козла отпущения. Такие люди виртуозно рассеивают ваше внимание или же дают неверные указания. И всё лишь для того, чтобы как можно дольше просидеть в своем кресле начальника, поскольку начальство имеет свои привилегии в виде бонусов. И даже если проект неожиданно проваливается, это лишь капля в море, по сравнению с их банковским счетом и влиянием.
Если вы заметили такого человека, то лучше даже не пытаться что-то исправить. Обращаться к владельцу проекта бессмысленно, поскольку он может быть родственником, другом, или же ваш CEO (главный исполнительный директор, прим. переводчика) может быть просто глупцом. И последнее — самое худшее, ведь чем дольше такое будет происходить, тем меньше желания у начальства понять, что всё это время их дурачили. Такие проекты, в большинстве своём, проваливаются, так что…

Не бойтесь уйти

Когда вы поймете, что всё-таки пора, не бойтесь уйти на вольные хлеба. Временная уверенность, которую даёт работа на данном этапе, лишь временная. Запомните, проект рано или поздно, но провалится! Это лишь вопрос времени. Ситуацию можно исправить лишь сменой начальства, а такие глобальные перемены редко когда случаются.
Вы всегда должны быть начеку, вдруг появится предложение получше. Но если ситуация критическая — начинайте активно искать другое место работы. Проходите собеседования, присоединяйтесь к существующим стартапам. Не следует сидеть сложа руки. Это тяжело, если у вас есть такие коллеги, и потеря очередного ежемесячного чека с зарплатой может выйти вам в убыток, но поверьте, оставаться в таком проекте даже больше бьет по кошельку, и не только вам, он и окружающим.
Я всё это беру не с потолка, а говорю из своего опыта. Я был вынужден уволиться точно из-за такой ситуации, но вместо того, чтобы устроиться в очередную IT компанию с такой же зарплатой, я решил перейти на фриланс. Это позволило мне выбирать проекты и клиентов, выбирать технологии и инструменты, с которыми мне удобно и которые мне интересны. Фриланс дал мне намного больше знаний и опыта, чем я бы получил, находясь в провальном проекте.