😶‍🌫️ Как работать продуктивно на новом месте работы?

У многих вкатунов часто возникает один и тот же вопрос: «Вот дали мне задачу, а что потом? Я ваще хз что делать»

Давай разберемся!

6️⃣Определи всего ли тебе в этой задаче хватает, чтобы сделать ее в соответствии со всеми ожиданиями.

Здесь тебе нужно проверить дизайны, если задача про UI, посмотреть в описание задачи и убедиться, что там написано достаточно, чтобы взять и делать, готов ли уже бэкенд, и уточнить будет ли тут какая-либо аналитика.

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

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

Если не готов бэкенд, то узнай как сделать задачу с помощью моков у коллег.

Нужно добавить аналитику? Разузнай как ведется работа с ней в приложении.

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

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

2️⃣ — Оценка задачи.

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

Твоя задача — смотреть и наблюдать за тиммейтами.

🖍️Обращай внимание на то, как они оценивают задачи в реальном времени: на что обращают внимание при своих рассуждениях.

Подними прошлые задачи коллег, посмотри на оценки и подумай почему именно в столько сторипоинтов/часов оценил ее твой коллега.

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

Таким образом, повышая насмотренность в оценках задач, ты быстро поймешь, как оценивают задачи в этой компании.

3️⃣ — Не знаешь с чего начать в решении задачи.

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

➡️Новые фичи — смотришь как устроена организация кода для создания нового модуля (экрана), есть ли шаблоны, делаешь по аналогии, только с вводными твоей задачи.

➡️Фикс багов — воспроизводишь сначала у себя по шагам, описанным QA. Если не получается воспроизвести, топай к тестировщику, воспроизводите вместе. Когда воспроизведешь, бери в руки автомат с брейкпоинтами и воспроизводи баг с подключенным дебаггером в Xcode. Если не знаешь как отлаживать код при помощи брейкпоинтов — вперед на ютуб, там море докладов на тему отладки кода и поиска багов.

➡️Инфраструктурные задачи. Даже если ты продуктовый разработчик не из Core-команды, могут прилетать задачи на улучшение кодовой базы (тесты, CI, новые утилиты, рефакторинг легаси-кода) или на создание каких-либо общих переиспользуемых компонентов (UI-элементы для использования на разных экранах, общие кнопки и т.д.). Не нужно их бояться, но такие задачи менее понятны, чем другие.

А если ты не iOS-разработчик, то эти правила применимы ко всем специальностям, но чуть поменяй под себя.

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

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

Как искать такую информацию — вопрос на другую тему, но думаю разобрать вопрос гуглинга.

#старт #софты #мысли