🧑‍💻 Прозрачность как инструмент карьерного роста

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

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

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

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

Отчёты о проделанной работе

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

TODO image

Письменные отчеты похожи на дневник/заметки, которые я рекомендую писать тем, кто пока учится, но преследуют немного иные цели:

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

Я советую писать 300-500 слов на каждые 6-8 часов активной работы. Публиковать в командный канал мессенджера или лиду лично, как договоритесь.

Ситуация #1

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

Частые ошибки и заблуждения:

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

Пример дневного отчета для ситуации #1 для воображаемой задачи - “разработка системы ролей для интернет магазина”:

Сегодня я приступил к реализации системы ролей на нашем сайте. Пример - пользователи могут совершать покупки, контент менеджеры могут редактировать товары. Реализация этой задачи связана с тем, как у нас уже организована авторизация. Так как мы уже используем Spring Boot и JWT, рационально воспользоваться Spring Security для аутентификации действий пользователей.

Через коллекцию ролей пользователя и аннотации @HasRole на методах контроллеров мы сможем декларативно объявить правила, описывающие, какие роли необходимы для вызова тех или иных методов API. В случае, если у текущего юзера нет прав для вызова того или иного метода, Spring Security автоматически вернет ошибку с кодом 403.

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

Необходимо принять решение о том, хранить ли роли в самом токене, или читать их из БД при каждом запросе.

Если мы храним их в самом токене, то придется инвалидировать его, если у пользователя поменялись роли после выдачи токена. Если мы читаем их из БД при каждом запросе - это увеличивает количество обращений к базе. Второй вариант является более гибким, предлагаю начать с него. Не будет проблемой изменить подход, если возникнет необходимость. Можем обсудить это на следующем созвоне. Завтра я обновлю интеграцию токенов со Spring Security. При каждом HTTP запросе к API будем читать роли из БД, что позволит Spring Security принимать решения о доступах к методам, исходя из аннотаций @HasRole(’’).

Здесь я:

• Описал, что делаю сейчас
• Раскрыл мотивацию принятых решений, описал альтернативные подходы
• Сформулировал дальнейший план действий

Ситуация #2

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

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

Пример того, как можно подсветить проблему и вынести её на обсуждение:

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

Для отправки емейлов я воспользовался модулем Spring Email, который умеет отправлять письма по протоколу Smtp. Логином и паролем к Smtp является наша пара ключей к сервису Mailjet, через который мы совершаем рассылки.

В процессе работы я столкнулся с проблемой. Примерно 1 раз из 100 отправка емейла завершается неудачей. Я не знаю с чем это связано, потому что ошибка приходит от внешнего сервиса. Spring Mail бросает исключение MailSendException.

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

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

Здесь я:

• Описал проблему со всеми известными на данный момент деталями
• Вынес на обсуждение варианты возможного решения
• Дал понять, что не буду закапываться в проблему, а продолжу работу над функционалом

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

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