Как использовать свои ежедневные циклы обратной связи, чтобы быстрее достигать своих целей

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

• учусь,

• создание работающего приложения или

• зарабатывать деньги.

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

Чем быстрее тем лучше

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

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

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

Ваши ежедневные циклы обратной связи

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

Изменения кода

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

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

Ежедневная работа над тикетом

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

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

1. После того, как вы прочитали билет, перефразируйте его тому, кто хорошо понимает, о чем он. Если ваше понимание неверно, они смогут вас поправить.

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

1. Наиболее важным, однако, является обратная связь по логике программы. Попросите обзор, пока вы все еще обновляете тесты.

Версия приложения

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

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

Соответствие продукта рынку

Даже в большем масштабе это все еще применимо. Цель таких методологий, как Agile или Lean Startup, — как можно скорее выпустить свой продукт и получить отзывы от рынка.

А как насчет качества обратной связи?

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

В случае объективных входных данных, таких как:

• тесты не пройдены или функция работает не так, как ожидалось,

• приложения измеримо медленные, или

• остальные показатели эффективности находятся за пределами ожидаемых значений

Часто рекомендуется немедленно приступить к решению этой проблемы.

В случае субъективного мнения:

• подход к кодированию

• наименование переменных или методов

• любая другая вещь, которую эти разные разработчики могли исправить по-другому

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

А ты?

Получали ли вы когда-нибудь обратную связь, которая повлияла на вашу карьеру? Пожалуйста, поделитесь своей историей; Я хотел бы услышать это!