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

Disclaimer

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

Проект - это конфликт

Проект - это здоровый конфликт интересов его участников:

  • Продакт оунер хочет, чтобы time-to-market был минимален, а конверсия и воронка - прямыми, как труба.
  • Проджект менеджер хочет уложиться в срок при минимальных затратах
  • О качестве думают программисты, тестировщики и другие участники.

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

Разработчики - это единственные в проекте, кто будет топить за качество. “Да, конечно, давайте сделаем все по СОЛИДу и паттернам, пусть это займет три недели вместо двух дней”, - не скажет ни один ПМ в мире. Получается, что только от нас и зависит качество построенной системы.

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

А зачем делать вещи правильно?

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

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

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

А причем здесь конфликт?

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

(c) Клоук и Голдсмит, “Resolving conflicts at work”

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

А как делать правильно?

Об этом мы сейчас и поговорим.

Jira development first

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

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

  • Вопросы по задачам задаем через комментарии. Любой увидит историю переписки и поймет, почему вдруг стори-поинты поменяли и на какие критерии приемки стоит обратить внимание.
  • Просите ставить задачи вам. Тестировщик пишет по поводу ошибки - попросите багрепорт с шагами воспроизведения. Бэкендер пишет вам, что параметры эндпоинта поменялись - попросите задачу с примером тела запроса. Нужна помощь девопса - ставьте задачу. Таким образом, ни вы, ни тиммейт не забудете о том, что нужно сделать, а ПМ оценит ваш вклад в прозрачность процессов.
  • Обновляйте статусы задач. Закончили ревью - переведите в QA или Develop сами, переназначьте ответственного. Не ждите, что ПМ это сделает на дэйлике. Он скажет вам спасибо.
  • Храните информацию в задаче и документацию там же. Тогда, если вам нужен внезапный дэйофф или срочный отпуск, то никто не будет вас дергать. Никто от вашего личного присутствия не зависит, вас никто не ждет, вы - свободны.

Как убедить коллег?

  • Не забывайте обновлять статусы задач. Не ждите, что кто-то другой обновит. Блокированы - ставьте задачу в блок и пишите комментарий почему. Поменяли ответственного - пишите комментарий почему.
  • Задавайте вопросы только в Jira. Не читают? Присылайте ссылку на комментарий в слак.
  • Обсудили что-то с коллегой - добавьте комментарий с резюме созвона, что обсудили и к чему пришли. Тегните ПМа, пусть он будет в курсе. Так вы убедитесь, что поняли с коллегой одно и то же.

Written communication first

Не просто так я упомянул, что вопросы нужно писать. В письменной коммуникации вы получаете некий контракт взаимодействия: кто что сказал, о чем договорились. Таким образом, вы всегда можете вернуться к тексту, если вдруг забудете что-то. Если вы интегрируетесь с другой командой, то пишите письма. Описывайте протокол взаимодействия, задавайте вопросы “а как тут сделать Х и У”. Письма - ваш контракт и подстраховка, если вдруг что-то пойдет не так.

Когда нужно обсудить задачу с коллегой, то подготовьте вопрос, предложите варианты решений, объясните, почему не можете выбрать что-то одно. Не стоит задавать вопросы типа “не понимаю как сделать, помоги”. Не нужно никаких meta-вопросов и тем более не нужно писать “привет” и ждать. Так можно сидеть до понедельника.

Созванивайтесь только в том случае, если другие варианты не подходят. Слишком долго обсуждаете интеграцию или способ воспроизвести ошибку очень сложный? Окей, это весомая причина для звонка, однако даже после таких встреч должен быть осязаемый результат: заметка-резюме в Jira или meeting notes.

Очевидные вещи нужно проговаривать и прописывать. Используйте формулировки типа “Правильно ли я понимаю, что …”, “Мне нужно сделать так и так. Верно?”, “Насколько я понял из ответа, мне нужно то-то и то-то?”. Пусть собеседник или подтверждает ваши предположения, или дает корректировки. Так собеседнику легче дать вдумчивый ответ.

Как убедить коллег?

  • Бывает, что коллега попался такой, которого хлебом не корми, а дай созвониться. Мягко скажите ему, что если он напишет вопрос, то вы подготовите ответ лучше, чем в прямом эфире.
  • Начинайте с себя - пишите подробные вопросы. Сначала будет тяжело, но чем больше практики, тем легче.
  • Скажите коллегам, что асинхронное общение дает возможность заниматься другими задачами вместо ожидания созвона.
  • Если и это не поможет, на ретро скажите, что звонки “на пять минут” редко умещаются в пять минут и выбивают из колеи, а текстовые сообщения напомнят о важном.

Tutorials first

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

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

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

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

Как убедить и внедрить?

  • Нашел хак, как легче настроить инфраструктуру - напиши туториал.
  • Закончил задачу - подскажи тестировщику, как пройтись по Happy path, какие эндпоинты после каких выполнить. Остальные пограничные кейсы он уже найдет сам.
  • Туториалы - это емкий и эффективный ответ на вопрос, если коллеге нужна помощь.

Code quality first

Качественный код должен быть привычкой, написание тестов - тоже. Не стоит рассматривать качество как некую отдельную задачу. Напомню, что только разработчики фокусируются на качестве. Да, продакт тоже не хочет, чтобы баги с прода сыпались каждые пять минут, однако он не знает, что такое юниттесты, паттерны проектирования и состояния нормализации баз данных. На планировании мы вместе найдем баланс между time-to-market и качеством

Качество само по себе не появится. Его нужно обеспечивать и контроллировать.

(c) Егор Бугаенко, Code Ahead.

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

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

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

(с) Р. Мартин

Юниттесты - это must-have. Как иначе вы покажете, что ваш код работает? Начинайте с Happy path, дальше добавляйте пограничные кейсы, которые приходят вам в голову. Не рассматривайте время, которое нужно на тесты, как отдельную задачу. Сразу закладывайте их в оценку.

Напомню, что, согласно статистике от Kolesa Zerttey 2022 и StackOverflow, только половина разработчиков пишет тесты. Умение тестировать код сделает вас более конкурентным специалистом.

Как убедить и внедрить?

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

Interface first

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

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

Точно так же сделан и пульт от Apple - только самые необходимые кнопки.

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

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

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

Clarity first

Уверен, что многие встречали такого коллегу, который на каждом дэйли-статусе про каждую свою задачу говорит “Work in progress”. А что именно происходит - пойди разбери. Для того, чтобы к вам было доверие, нужно быть открытым.

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

Когда что-то рассказываете коллеге или делитесь фидбеком, то говорите простыми формулировками. Двузначно трактовать ваши слова нельзя. Тут речь идет не о токсичности - вы говорите факт, а затем как бы вы поступили на месте человека и почему.

Когда вы делитесь знаниями, вы объясняете простыми словами и аналогиями. Если чего-то не понимаете, то так и говорите - я этого не понимаю.

С чего начать?

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

  1. Обновляйте статусы в Jira. Избавьте вашего ПМа от необходимости спрашивать вас, какой статус там. Если есть изменения по задачам, то в комментариях поясняйте, что произошло и почему.
  2. Пишите туториалы для себя и коллег. Рассматривайте любой вопрос типа “а как сделать Х и Y” как возможность написать туториал.
  3. Пишите тесты, начните хотя бы с Happy path.
  4. Пишите подробные вопросы коллегам. Созванивайтесь только если это действительно необходимо. Учитесь писать понятные предложения, не думайте, что собеседник читает ваши мысли. Очевидные вещи надо проговаривать.

  1. Соблюдай правила
  2. Нарушай правила
  3. Создавай свои правила

(с) цитата в интернете.

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

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