Egor Levchenko

Заметка

Вы устраиваетесь джуном?

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

Да, пост будет именно про web-разработчиков, но он так же применим и к другим специальностям.

Что вам нужно знать 🔗

Когда вы приходите на работу в новый коллектив или только подбираете вакансию под себя, вам нужно определить:

  • будете ли вы работать один или в команде?
  • кто вам будет ставить задачи?
  • как вам будут ставить задачи?
  • каким образом задачи проверяются и принимаются?
  • каким образом происходит доработка задач после принятия?

Давайте попробуем с этим разобраться.

Будет ли команда 🔗

Большинству junior frontend-разработчиков я бы рекомендовал искать работу в команде, потому что у команд обычно есть «тимлид», который взаимодействует с другими подразделениями и ставит задачи на своих специалистов, понимая, что они знают и умеют. Ещё в командах всегда есть возможность менторства и код-ревью.

Минусы у работы в команде тоже есть: устаревшие технологии и практики. Многие разработчики придерживаются метода: «работает — не трожь» — если вы будете работать не в одиночку, вам будет сложнее принести что-то новое.

Если команды у вас не будет, вы сможете сильнее влиять на постановку задач.

Кто ставит задачи 🔗

Практика показывает, что задачи ставит либо один человек, либо несколько.

Если задачи ставит один человек, то он точно знает, что вам потребуется, чтобы решить вашу задачу, будет грамотно рассчитывать время, общаться с коллегами за вас. Обычно это принято в командах, а задачи ставит «тимлид», но бывает и специальный «продуктовый менеджер», который станет вашим «секретарём».

Главный минус в таком подходе — «сломанный телефон». Всегда, абсолютно всегда между постановкой задачи и началом работы есть человек, который эту задачу не будет решать. Всегда есть время, которое будет потрачено не на решение задачи. Например, ваш «менеджер» уйдёт на больничный или в отпуск, получит слишком много задач, которые не успеет вовремя обработать, или что-то пропустит. Или «тимлид» решит, что эта задача менее приоритетна, а потому вы будете делать что-то сложное и долгое, а задача на две минуты отложится на неопределённый (для вас) срок. Если вам потребуется что-то уточнить, тоже придётся ждать, потому что вы можете не знать, кто на самом деле принимает задачу.

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

Как вам ставят задачи 🔗

Признайтесь, мало кому нравятся таск-менеджеры.

Именно поэтому очень много небольших продуктовых компаний, работает вовсе без таск-менеджеров! Задачи и вопросы попросту валятся вам на почту, в telegram, skype или того хуже whatsapp, а то и во все мессенджеры разом.

Задач становится всё больше, ответственные теряются, регулярно вносятся правки и дополнения, которые уже просто невозможно отследить... Особенно, если задачи вам ставят несколько человек, среди которых может оказаться кто-то «самый главный» (например, владелец бизнеса или генеральный директор, который внезапно решил «порулить»).

Вывод прост: всегда пользуйтесь таск-менеджером, но если ваша компания ещё им не пользуется, у вас есть отличная возможность выбрать тот, который будет по душе именно вам. Дизайнерам подойдёт basecamp или asana, разработчикам jira, redmine или яндекс.трекер, менеджерам два последних.

Как задачи будут проверяться и дополняться 🔗

Да, вы уже наверняка читали мою статью «6 причин, почему не стоит идти в код-ревьюеры», и тем не менее, я убеждён, что код-ревью — это важно, начинающим (и не только) разработчикам, стоит идти в компанию, где такое ревью есть.

Однако будем честны: в большинстве продуктовых компаний, где ваша работа не будет самой главной и определяющей, её будут принимать спустя рукава. Сделал? Дал ссылку на страницу? Отлично, работай дальше, галеры ждут.

Самое главное в такой работе — понимание, что написанный вами «говнокод» (в лучших традициях agile-модели и rad-методологии) поддерживать тоже вам. Пишите качественный код, документируйте всё то, что не понятно с первого раза и обязательно отмечайте и сохраняйте, кто и когда принял вашу задачу.

Большинство компаний, где результат не проверяется, будут хотеть от вас «доделок», «переделок», «улучшений», «исправлений», которые могут в корне поменять изначальную задачу. Стоит ли добавлять, что эти компании будут страстно желать за такую работу не заплатить?

Так как же начать работать без боли? 🔗

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

Что вам нужно от трекера 🔗

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

  • Категории разработки
  • Дедлайны
  • Описания задач
  • Файлы, которые вы будете получать от других сотрудников (например, от дизайнера)

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

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

Не забудьте отметить обязательные поля — так вы не будете бегать за менеджером с запросами «забытых» файлов.

Ваше мнение имеет значение 🔗

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

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

Заручитесь поддержкой руководства и гните свою линию.

Если вам отказали в введении трекера для компании, всё равно его введите и заполняйте самостоятельно. Получили задачу? Завели её в трекер. Чего-то не хватает? Сразу скажите об этом постановшику задачи. И самое главное — пока вам не дадут всё, что необходимо для работы, не выполняйте задачу.

Ведите поэтапную разработку и организуйте работу по какой-нибудь системе, например SCRUM 🔗

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

  • Создание сайта
    • Создание дизайна
      • Десктопная версия
      • Планшетная версия
      • Мобильная версия
    • Написание контента
    • Вёрстка
    • Размещение

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

Вы web-разработчик 🔗

Не забывайте напоминать об этом всем тем, кто почему-то «забыл».

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

Вы не дизайнер, а потому не можете дорисовать что-то за художника.

Вы не SEO-специалист или контенщик, а потому не можете написать новые тексты, взамен старых.

Вы не музыкант и не монтажёр, а потому не можете создать новый видеоряд с музыкой на заднем фоне.

Даже, если у вас хобби такое, даже если вам обещают «накинуть» или дополнительно заплатить.

Не беритесь за эту работу, пока вы выполняете задачи web-разработчика.

Хотите больше денег? Вам поможет отдельный контракт с чётким описанием задач и денег, которые вы за эту задачу получите. Но учтите, что ваш заказчик будет иметь полное право требовать от вас выполнение этой работы на самом высоком уровне. Правда, тут стоит успокоиться, обычно такие задачи ставятся не потому что дизайнер или контентщик заняты, а потому что за выполнение «сверхурочки» им придётся больше платить, или придётся платить «фрилансерам», которые будут им помогать, а вам можно «накинуть» гораздо меньшие деньги.

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

Вместо заключения 🔗

Вам могло показаться, что я ставлю web-разработчиков на самое главное и неприкасаемое место в компании, но это не так.

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

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

Чтобы решать задачи бизнеса разработчику надо понимать, как этот бизнес работает, и попытаться организовать вокруг себя максимально комфортную среду. Таск-менеджер, отчётность, умение сказать: «Нет» — и строго определённые задачи позволят вам получать честные деньги за вашу работу. Если же ваш работодатель с вами не согласен, так может это не лучшая работа на свете?