Привет! На связи Митя Кожевников и Юра Соколов из Mindbox, и это вторая часть гайда по софтам для джунов. В первой части мы говорили о том, что значит «приносить пользу» в разработке, а в этой поговорим об ориентации на результат.

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

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

Кому читать. Этот гайд — для джунов, которые хотят сделать софты своим конкурентным преимуществом. Если джун ответственно выполняет работу, умеет самостоятельно обучаться и не проходит мимо говна, его готовы оторвать с руками, даже если ему не хватает знаний. К тому же советы из этого гайда помогут быстрее закрепиться в команде и вырасти. Пользуйтесь!

Что такое результат

Результат — это изменение, полезное для пользователя.

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

Не результат	Результат
Вмерженный пул-реквест	В продакшен-админке клиент нажал кнопку, и она ожидаемым образом отработала
+1000 строк кода
10 часов работы
Новая кнопка, которая срабатывает не так, как нужно
Новая кнопка, но не сейчас, а через месяц

Ответственность за результат несет исполнитель — тот, кто пишет код. Есть три совета, которые помогут вам отвечать за результат.

Совет 1. Выполнять обещания

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

Чтобы быть предсказуемым, важно думать о том, что конкретно, когда и кому вы обещаете сделать.

Помнить про сроки

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

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

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

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

Продумать реализуемость

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

Понять, что ваше обещание реально выполнить, помогают два вопроса.

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

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

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

Митя Кожевников

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

Юра Соколов

Однажды я взялся за задачу, решение которой представлял лишь примерно. Назвал срок — пять дней.
В процессе обнаружил много подводных камней, пришлось разбираться с новой технологией и тестировать гипотезы. Я постепенно сдвигал срок и каждый раз обещал принести результат завтра. На десятый день ребята из команды почувствовали неладное и объяснили, что так работать с ожиданиями нельзя. Но так как никто не мог перехватить задачу, я продолжил работать над ней.
В итоге на решение ушло 20 дней вместо 5 запланированных. Из-за того, что я задержал задачу, мы не успели к публичному обновлению SLA — до следующего пришлось ждать полгода. Команда осталась недовольна, а я навсегда научился внимательно относиться к обещаниям, которые даю.

Совет 2. Не ждать, когда дадут, — брать самому

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

Заинтересованность проявляется в мелочах:

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

Лайфхак

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

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

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

Юра Соколов

Есть наглядный пример, когда моя торопливость обернулась проблемой для нескольких человек.
Я завершил задачу в пятницу ближе к концу рабочего дня. Мне было прекрасно известно, что в это время не стоит ничего выкладывать, но я очень торопился быстрее увидеть результат. Выкатил обновление и сломал метрику.
Запаниковал, пытался найти проблему, но ничего не находил. Откатил изменения — не помогло. Привлек на помощь коллегу, который уже собирался уходить, — он тоже не смог решить. Пришлось звонить суперколлеге: он пришел, обругал нас, но помог починить.
Было так стыдно, что из-за моей поспешности одному коллеге пришлось задержаться на работе, а второму сорваться с выходных. Больше никогда не хочу такой опыт повторять.

Совет 3. Быть требовательным

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

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

Писать прочный и понятный код:

Проводить ревью своего кода — проверять понятность, правильность бизнес-логики, корнер-кейсы и производительность.
Не оставлять в итоговой версии ToDo и закомментированный код. Если они появляются в процессе работы — это нормально. Но по завершении важно навести порядок: вынести ToDo в карточки или инбокс команды, а закомментированный код — удалить.
Сразу писать тесты. Это гарантия, что весь написанный код решает задачу и нет лишнего.

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

Юра Соколов

Когда я только начинал работу в Mindbox, мы готовились опубликовать фичу на замену старой. Все было готово, оставалось нажать кнопку и выкатить изменения.
Я заметил, что старый функционал не скрыт. Возможно, так и было задумано, но я решил написать об этом продакту и архитектору. Оказалось, что это ошибка. Я взял задачу на себя: отодвинул планируемые задачи и всё поправил за 3–4 часа.
В итоге релиз выкатили вовремя, ребята похвалили меня за то, что не просто сообщил о проблеме, а сам вызвался и исправил ее, — в командной работе такая инициативность важна.

Чек-лист, чтобы проверить ответственность за результат

Задайте себе или обсудите со своим ведущим несколько вопросов:

Когда я в последний раз не сделал, что обещал? Почему? Что я сделал, чтобы это не повторилось?
Сколько раз за месяц я переносил сроки? Когда из-за этого кто-то пострадал?
Если я столкнулся с проблемой, зову ли на помощь? Как долго пытаюсь разобраться сам?
Когда я в последний раз получил обратную связь по своей задаче? Что поменял в работе? Просил ли повторную ОС после изменений?
Был ли я недоволен работой другого, но промолчал?

Это статья в трех частях. Вы прочитали вторую. Первую можно найти в блоге Mindbox на Хабре. Последняя появится позднее — следите за публикациями.

Бонус: что почитать, чтобы прокачать софт-скилы

Чтобы организовать работу над задачами и не сливать сроки, рекомендуем прочитать:

— Книгу «Getting things done» Дэвида Аллена.

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

— Статью IT-Agency «План обучения джедаев».

Как джуну отрастить софты: советы и реальные истории. Часть 2. Отвечать за результат