Представляем перевод статьи Кайла Стефенса на dev.to.
Теперь, когда новый год уже наступил, праздники закончились и вы начали возвращаться к повседневной рутине, вас могут охватить подспудные сомнения насчет вашей работы.
Может, это просто посленовогодняя хандра? Как на самом деле узнать, когда наступает пора уходить?
Я подсчитал, что за последние пять лет работал с восемью разными командами. Они отличались размерами и охватом, от самой маленькой, состоящей из 3 дизайнеров и 1 разработчика, занимавшихся поставкой продукции для оффшорного центра доставки программного обеспечения, до самой большой, состоящей из 16 разработчиков и 8 QA, работавших с отделом разработки отдельных продуктов UX-исследователей и UI-дизайнеров.
Однако я не серийный «летун». Большую часть времени я тогда проводил работая в качестве консультанта одной фирмы. Это позволяло мне менять роли и испытывать на себе различные культуры компаний без, собственно, смены работы. Я получил опыт действий в многочисленных рабочих ситуациях, как приятных, так и не очень. В качестве стороннего наблюдателя я также был свидетелем трех массовых исходов, «утечки мозгов», когда за 1-2 месяца уходит больше 50% команды.
Я изобразил некоторые из этих ситуаций, чтобы поделиться своими наблюдениями и побудить вас задуматься о счастье на рабочем месте.
Проекты «тише едешь — дальше будешь»
Это проекты, в которых жизнь течет очень спокойно (некоторые могут сказать, что нудно), без содержательных технических задач, над которыми надо биться. В таких проектах вы вдруг обнаруживаете, что активно пытаетесь найти, чем заняться. Дни тянутся, и вы все время поглядываете на часы.
Если вам нравится неспешный темп и товарищи по команде, вы, пожалуй, сможете вполне комфортно и с удовольствием ковылять по этому пути некоторое время.
Однако, если вами движет желание личностного роста и обучения путем нахождения решений рабочих задач, вам такая обстановка вряд ли понравится. В подобной ситуации вы можете назначить встречу с менеджером, чтобы попросить дать вам большую ответственность или перевести в другую команду, если есть такая возможность. Вы также можете заняться какими-то личными проектами, учебными или же для подработки, или присоединиться к опенсорс-сообществам.
Если вы все это испробовали, но все равно не в восторге от своей работы, пожалуй, пора здесь закругляться и двигаться дальше.
Проекты «марши смерти»
В плане ежедневного темпа работы это противоположность предыдущего сценария.
Я уверен, большинству разработчиков знакома шутка о менеджменте проектов: «Я назначил день свадьбы. Предложение я пока не делал».
Проект становится «маршем смерти». Когда менеджер проекта (если речь идет о бизнесе) или отдел продаж (если речь о работе с клиентами) без предварительных консультаций с командой инженеров устанавливают объем проекта и сроки, которые являются либо наивными, либо очень амбициозными.
Эти проекты обычно бросают новые вызовы, давая вам шанс продемонстрировать свои способности и позволяя вам ставить перед собой максимальные цели, расширяя границы ваших возможностей.
Однако подобные проекты могут привести разработчиков к выгоранию, а команду – к невозможности работать под давлением временных рамок.
Если вы хотите принять участие в таком проекте, нужно учесть ряд переменных. Например, сколько времени по-вашему займет этот проект, и будет ли постоянным подобный темп. Также вам стоит задаться вопросом, есть ли возможности продвижения по службе после успешного завершения проекта, а также будут ли у вас новые интересные задачи или просто однообразная работа в сжатых временных рамках.
Если вы оценили эти моменты и думаете, что лично для вас овчинка стоит выделки, я советую вам браться за проект. Вы можете сами удивиться достигнутому. Если же вы не готовы к подобным вызовам или чувствуете, что запросы необоснованны, возможно, пришла пора прощаться и идти дальше.
Игнорирование мнений/соображений
Стив Джобс однажды сказал: «Нет никакого смысла нанимать умных людей и говорить им, что делать; мы нанимаем умных людей, так что они могут говорить нам, что делать».
Это не значит, что мы как разработчики должны всегда получать самые последние инструменты и технологии просто потому что они круто выглядят или удовлетворяют нашу жажду экспериментов и изучения. Однако, когда люди работают в среде, где их навыки и специализация не имеют большого значения, поскольку их данные, соображения и работа аннулируются мнением вышестоящих лиц, раздражение будет быстро нарастать и в конце концов эти люди уйдут.
Например, мне однажды довелось видеть, как за месяц улетучилась целая исследовательская команда с суммарным опытом работы, превышающим 30 лет. Это произошло потому, что вся их работа – мастерклассы по UX, интервью с пользователями, прототипирование и валидация – постоянно подавлялась старшими руководителями, которые отвергали планы и соображения команды, основанные на полученных данных, и заменяли их своими решениями и компромиссами, что было плохо для продукта и в итоге для конечного пользователя.
Отсутствие подходящих процедур
Я говорю «подходящих» процедур, ведь то, что подходит для одного набора обстоятельств, может не подходить для другого. Например, большой правительственный проект скорее всего будет иметь много наборов сдержек и противовесов, поскольку требует безопасности и стабильности . С другой стороны, в зарождающемся стартапе с командой из 3-4 человек их может быть мало или не быть вовсе, поскольку там все постоянно развивается и меняется.
Проблема возникает тогда, когда принятый метод не подходит для конкретных обстоятельств. В частности, это распространенный случай, когда стартап становится успешным, расширяет команду и вдруг обнаруживается, что работавшее раньше совершенно необязательно будет работать и дальше.
Возможно, вы оказывались в ситуации, когда ваша команда описывает свой подход как agile, но в реальности это просто слово, которым обозначают постоянное тушение пожаров? Менеджеры проекта обвиняют разработчиков в опозданиях с поставками? QA травят разработчиков за баги? Вы посреди шторма из хаоса и неразберихи.
О рабочем месте можно судить по тому, сколько времени занимает выполнение чего-то простого. Когда по непонятным причинам невозможно сделать что-то, ранее с легкостью выполнявшееся в другом окружении, – вы находитесь в глубоко неэффективной рабочей обстановке.
Если вы хотите попробовать повлиять на изменения к лучшему в своей команде, возможно, вы можете отнестись к этому как к возможности расширить свои лидерские навыки, взяв на себя роль agile coach.
Если вы уже попытались, но не встретили понимания в руководстве, возможно, дисфункция охватила всю организацию, и значимые изменения могут идти только сверху. В таком случае, если вы считаете, что больше не можете работать в подобном стиле, может быть, пора откланяться и идти дальше.
Работа не соответствует обещанному
Вам обещали систематизированное agile-окружение с хорошо организованными спринтами, полным набором тестов и адекватной документацией, но обнаружилось, что реальность сильно отличается? См. пункт выше о процедурах!
Возможно, вы были разочарованы, узнав, что этот супер-захватывающий проект по разработке, который вам обещали, так и не материализовался, и вместо этого вы обнаружили себя исправляющим баги в устаревшей системе?
Если вы работаете в большой организации, потерпите: иногда такие вещи требуют времени. Однако дайте знать менеджменту, что вы недовольны ситуацией. Возможно, они смогут ее прояснить или изменить что-то. Я видел ситуации, когда у нас были только что нанятые люди, которых привлекли к работе без определения конкретного места или роли, забыв об их навыках, а оказалось, что они как раз были очень нужны нашей команде для нашего текущего проекта!
Если, несмотря на заверения, ничего так и не изменится, возможно, придется задуматься о смене работы.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]