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

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


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



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

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



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

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



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

Комментарии (5)


  1. Khaperets
    24.12.2015 19:32

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

    Та же самая ситуация была и сейчас происходит. Но все-равно подумываю о компаниях, так как и доход больше, и работа в офисе хорошо дисциплинирует человека.


    1. begemot_sun
      24.12.2015 20:58

      у вас какой-то неправильный фриланс. Фриланс по определению должен приносить бОльший доход, чем работа на дядю (если конечно посвящать ему достаточно времени).


      1. Fesor
        24.12.2015 22:53

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

        Ну и опять же начинающим полезно получить опыт работы в команде. На удаленной основе без опыта работы с реальными людьми сложно.


      1. mattheus
        25.12.2015 18:57

        У фриланса есть свои серьезные недостатки, мешающие высокой производительности труда и как следствие высокому заработку:

        • Часто на фриласн скидывают то, что не может сделать штатная команда (мы в компании так делали), получается фрилансер получается самое «муторное» задание за минимальные деньги (задания выдавались фрилансерам за меньшую стоимость в час чем получали штатные программисты)
        • Работая в компании над большим проектом, программист набирается опыта, формирует библиотеку/toolchain и т.д., т.е. проходит первый этап «въезжания» в проект и дальше работает «по накатаной» используя свои наработки, во фрилансе каждый проект — новый, старые наработки применимы ограниченно (не всегда и не везде применишь, а если ждать только очень похожих проектов, то долго ждать прийдется). Есть вариант будучи фрилансером работать на одного и того же заказчика над постоянным проектом, но чем тогда это сильно отличается от удаленки? Чуть более свободным графиком работы?


      1. VolCh
        28.12.2015 08:52

        Фриланс по определению должен приносить бОльший доход, чем работа на дядю (если конечно посвящать ему достаточно времени).


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