Добрый день, меня зовут Павел Поляков, я Principal Engineer в каршеринг компании SHARE NOW, в Гамбурге в ???????? Германии. А еще я автор телеграм канала Хороший разработчик знает, где рассказываю обо всем, что обычно знает хороший разработчик.

Сегодня хочу поговорить о принципах лидерства в Amazon. Что это такое и как они помогают разработчикам в Amazon делать свою работу эффективно? Это перевод оригинальной статьи.

Как разработчику применять принципы лидерства Amazon

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

16 принципов лидерства

Принципы лидерства это ДНК Amazon, они определяют как Amazon работает в целом. Можно сказать, что 16 принципов это столпы, на которых строится работа Amazon. Простой пример — представим, что идет обычная дискуссия о том, как решить какую-то проблему. Команда состоит из множества людей и у всех разная экспертиза. Конечно же, рано или поздно встретятся разногласия. Чтобы разрешить эти разногласия, сотрудники Amazon, прямо во время дискуссии, будут ссылаться на принципы лидерства. И это поможет разрешить спор. Прежде всего стоит сказать, в технологических компаниях как Amazon, люди стремятся завершить дискуссию составлением какого-то плана действий. Дискуссия может продолжаться, но люди будут фокусироваться на задачах, которые можно сделать, чтобы исследовать предмет дискуссии дополнительно или решить проблему. Такой подход базируется на принципе лидерства Действуй, который говорит что действие лучше бездействия.

На данный момент определено 16 принципов лидерства:

• Одержимость клиентом (Customer Obsession)

• Владей (Ownership)

• Изобретай и упрощай (Invent and Simplify)

• Быть правым часто (Ara Right, A Lot)

• Учись и будь любопытным (Learn and Be Curious)

• Нанимай и развивай лучших (Hire and Develop the Best)

• Настаивай на высоких стандартах (Insist on the Highest Standards)

• Мысли масштабно (Think Big)

• Действуй (Bias for Action)

• Бережливость (Frugality)

• Заработай доверие (Earn Trust)

• Погружайся глубоко (Dive Deep)

• Имей принципы (Have Backbone)

• Не согласись, но участвуй (Disagree and Commit)

• Приноси результаты (Deliver Results)

• Стремление быть лучшим работодателем в мире (Strive to be Earth’s Best Employer)

• Успех и масштаб это большая ответственность (Success and Scale Bring Broad Responsibility)

Пару лет назад этот список состоял из 14 пунктов. Но потом Amazon добавила еще два принципа Стремление быть лучшим работодателем в мире и Успех и масштаб это большая ответственность. Актуальные принципы можно найти здесь.

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

Что разработчики делают на работе

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

Митинги, менеджмент и операционная деятельность

• Обсуждение продукта

• Обсуждение технологий

• Написание документации

• Организация технической работы

• Планирование технических проектов

• Работа над метриками, создание дэшбордов

• Исследования, чтобы понять как реализовать новую фичу

• Участие в интервью с кандидатами

Поддержка кода

• Работа с техническим долгом

• Обеспечение надежности системы

• Просмотр merge request

Тестирование

• Написание тестов

• Мануальное тестирование

• Интеграционное тестирование

Безопасность

• Тестирование с точки зрения безопасности

Написание кода

• Реализация новых фич

• Исправление багов

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

Как применять принципы лидерства в ежедневной работе

Создание фич или исправление багов

Обычно когда мы делаем фичи или исправляем баги, то речь в первую очередь идет о программировании. Здесь могут помочь несколько принципов лидерства.

Изобретай и упрощай

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

Настаивай на высоких стандартах

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

Приноси результаты

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

Обсуждение продукта и технологий

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

Быть правым часто, Одержимость клиентом

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

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

Мысли масштабно и бережливость

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

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

Не согласись, но участвуй

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

Наверное это наиболее неоднозначный принцип лидерства, когда дело идет о принятии решений. У всех есть свое мнение. Особенно у разработчиков. Я участвовал в дискуссиях, где основная тема практически ускользала, потому что люди спорили про специфические технические или продуктовые решения. Иногда лучше просто уступить, сказать "как хотите" и последовать решениям твоих коллег. В конце концов мы можем измерять результаты и узнать, будут ли они удовлетворительными. Либо даже провести A/B тестирование и узнать что сработает лучше. После решения каждый открыт к получению обратной связи, ты тоже должен быть готов ее получить в случае чего.

Написание документации

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

Одержимость клиентом, Погружайся глубоко

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

Владей

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

Заработай доверие

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

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

Планирование проектов

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

Владей

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

Действуй

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

Бережливость, Приноси результаты

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

Успех и масштаб это большая ответственность

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

Резюмируем

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

Принципы лидерства на Performance Review

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

Этот процесс очень сложный. Представьте, что вам нужно самостоятельно оценить свои достижения за прошлый год, основываясь на принципах, о которых мы говорили в этой статье. Вам будет это сложно сделать, мне будет это сложно сделать, это в целом сложно. Потому что наш мозг не может все это держать в голове. Есть инструмент, который может вам помочь — brag document. Лично я веду список всего хорошего, что я сделал на getworkrecognized. Я ставлю тэги на свои достижения, а потом могу посмотреть на картину в целом и соотнести свои достижения с принципами лидерства. Это очень помогает мне при составлении самостоятельной оценки.

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

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

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

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

А еще...

Здесь говорю опять я, Павел. В конце еще раз приглашу вас в свой Telegram-канал. На канале Хороший разработчик знает я минимум три раза в неделю простым языком рассказываю про свой опыт, хард скиллы и софт скиллы. Я 15+ лет в IT, мне есть чем поделиться. Все это нужно разработчику, чтобы делать свою работу хорошо, работать в удовольствие, быть востребованным на рынке и получать высокую компенсацию.

А для любителей картинок и историй есть ???? Instagram.

Спасибо ????