https://habr.com/ru/company/quarkly/blog/513168/

• Блог компании Quarkly
• JavaScript
• Карьера в IT-индустрии
• Программирование
• Учебный процесс в IT

Привет, Хабр! Представляем вашему вниманию перевод статьи фронтенд-разработчика из MediaMonks Рональда Мендеса. Будучи родом из Венесуэлы, Рональд перебрался в Аргентину и построил успешную карьеру, а благодаря своему большому интересу к дизайну и анимации стал одним из членов жюри престижной премии FWA (вручается с 2000 года).

В этой заметке, которая показалась нам интересной, Рональд рассуждает о том, как фронтендеру найти свое место под солнцем и эффективнее взаимодействовать со своей командой.

Рональд Мендес. О роли фронтенд-разработчика

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

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

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

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

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

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

Но нам всё ещё есть куда стремиться: к сожалению, работа некоторых фронтендеров, обладающих удивительными навыками, до сих пор сводится к верстке из PSD-макетов в HTML. Других устаивает свое положение в команде, но им бы хотелось играть более активную роль и продвигать свои идеи при разработке проекта.

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

Мой путь

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

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

Маленькие шаги в маленькой команде

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

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

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

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

Выход на большую сцену

Когда моя карьера начала стремительно развиваться, я оказался вдали от того маленького офиса на пять человек, где всё начиналось. Теперь я работал с гораздо более многочисленной командой, и проблемы были совершенно другими. Сначала меня очень удивило то, как они подходят к рабочему процессу: у всех членов команды была сильная техническая подготовка, в отличие от других команд, с которыми я когда-либо работал. Это делало сотрудничество очень эффективным. У меня не было никаких претензий к качеству дизайна, с которым я работал. На самом деле, в течение первых нескольких месяцев меня постоянно выталкивали из зоны комфорта и постоянно проверяли мои навыки.

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

Как команда разработчиков мы перешли на современные JavaScript-библиотеки. Это привело к тому, что при работе с нашими приложениями мы использовали исключительно компонентный подход. И несмотря на то, что мы медленно меняли наш образ мышления, мы не изменили способ сотрудничества с творческой половиной нашей команды. Создать эту связь между командами и стало моей новой целью.

Я был в восторге от концепции Брэда Фроста «Cмерть водопаду»: идея в том, что команды UX, визуального дизайна и разработчиков должны работать параллельно: это приведет к более высокому уровню итерации в ходе проекта.

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

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

Как завоевать место под солнцем

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

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

Перемены в жизни разработчика

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

• Не молчи. В многопрофильных командах разработчики известны своей высокоаналитичностью, критичностью и логичностью, но не коммуникабельностью. Я видел многих разработчиков, которые тихо жаловались и утверждали, что у них есть идеи получше о том, что и как делать, но они скрывали свои мысли и переходили к другой работе. После того, как я начал высказывать свои мысли и предлагать новые идеи, я увидел небольшие изменения в моей команде, и у меня неожиданно сильно повысилась мотивация. Более того я заметил, что другие начинают смотреть на мою роль в команде по-другому.
• Всегда будь в курсе того, какие идеи есть у остальных членов команды. Одна из наиболее распространенных ошибок, которые мы часто совершаем, это сосредоточиться только на своей работе. Чтобы быть на одной волне со своей командой и улучшить свою роль, мы должны понимать цели компании, навыки членов нашей команды, наших клиентов, и любой другой аспект сферы, где мы работаем, и на который, как мы привыкли думать, разработчик не должен тратить время. Как только я начал лучше понимать процесс дизайна, общение с моей командой начало улучшаться. То же самое относится и к дизайнерам, которые начали больше узнавать о процессах фронтенд-разработки.
• Прокачивай ключевые навыки. Сегодня наши обязанности расширяются, и перед нами постоянно ставят задачу вести свою команду вперед к ещё неизведанным технологиям. Как фронтенд-разработчикам, нам нередко ставят задачу исследовать такие технологии, как WebGL или VR, и ознакомить с ними остальных членов команды. Мы должны быть в курсе последних достижений в наших технических областях. Наша репутация ставится на карту каждый раз, когда требуется наш вклад, поэтому мы всегда должны стремиться быть лучшими разработчиками в своей отрасли.

Перемены в рабочем процессе в компании

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

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

• Привлекай разработчиков к проектам с самого начала. Многие компании придерживаются высоких стандартов, когда речь заходит о найме разработчиков, но не в полной мере используют их талант. У большинства из нас логический тип мышления, поэтому так полезно привлекать разработчиков ко многим аспектам проектов, над которыми мы работаем. Мне часто приходилось делать первый шаг, чтобы меня ввели в курс дела в самом начале проекта. Но как только я начал прилагать усилия, чтобы внести ценный вклад в процесс, команда начала автоматически привлекать меня и других разработчиков к работе на стадии дизайна новых проектов.
• Запланируй обсуждение проекта. Проблемы часто возникают, когда во время первых обсуждений проекта с клиентом присутствует не вся команда, которая будет работать над проектом. Как только клиент что-то подпишет, внедрять новые идеи может быть рискованным, какими бы ценными и полезными они ни были. Разработчики, дизайнеры и другие ключевые фигуры должны собраться вместе, чтобы вместе обсудить проект и затем перейти к следующему этапу. Как разработчику, возможно, вам иногда придется тратить часть своего времени, чтобы помочь товарищам по команде просмотреть их работу перед тем, как они её представят.
• Собери людей работать вместе. Если это возможно, собери людей в одной комнате. Мы предпочитаем полагаться на технологии и настаиваем на общении только через чат и электронную почту, но в личном общении есть свои плюсы. Всегда полезно, чтобы разные члены команды сидели вместе, или, по крайней мере, достаточно близко друг к другу, чтобы регулярно общаться друг с другом лично: так легче делиться идеями в ходе проекта. Если ваша команда работает удаленно, вам придется искать альтернативы для достижения того же эффекта. Периодические созвоны могут помочь командам делиться мыслями, комментариями и взаимодействовать друг с другом в режиме реального времени.
• Найдите время для образования. Из всех команд, с которыми я работал, как правило, эффективнее работают те, в которых поощряют культуру обмена знаниями. Простые и непринужденные презентации коллег из разных сфер могут внести огромный вклад в формирование разнообразных навыков в команде. Поэтому важно поощрять членов команды к тому, чтобы они преподавали и учились друг у друга.
  
  Когда мы приняли решение использовать только компонентно-ориентированную архитектуру, мы подготовили для команды дизайнеров простую презентацию, которая дала им представление о том, как мы все выиграем от изменений в нашем рабочем процессе. Вскоре после этого команда начала предоставлять макеты дизайна, которые соответствовали нашему новому подходу.

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

В качестве постскриптума

Спасибо за прочтение материала. В конце нам бы хотелось добавить несколько слов от себя.

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

На правах небольшой нагловатой рекламы (да простит нас Рональд): один из таких конкурсов стартовал сейчас у нас. Если вы знакомы с React или видите силы попробовать себя в написании компонентов для React, приглашаем принять участие по ссылке.

Прием работ продлится до 28 августа.