Не будьте похожи на любую другую горошину в стручке
Для некоторых команд разработчиков утренняя встреча - единственное время, когда вы можете пообщаться с членами вашей команды вне обмена мгновенными сообщениями или электронной почты. Итак, важно быть подробным, вовлеченным и заинтересованным в цели, которую пытается достичь ваша команда.
Эти качества не только важны для хорошего разработчика, но и могут помочь вашей команде прийти к финишу тогда, когда они больше всего в этом нуждаются. Уверен, вы слышали поговорку, что одно плохое яблоко испортит всю гроздь ...
Что ж, верно и обратное. Если вы позитивно настроены, вовлечены и заинтересованы в том, что строит команда, то такое отношение, скорее всего, будет встречено взаимностью среди других членов команды.
Будьте подробны
Другие члены команды, должно быть, улавливают то, что вы откладываете. Например, если вы собираетесь рассказать об исправленной вами ошибке, не будьте одним из тех разработчиков, которые говорят: «Вчера я исправил ошибку».
Мой друг, вы разработчик, который, скорее всего, хорошо зарабатывает, вы можете добиться большего. Вот хороший пример паршивого примера выше:
«Вчера я работал над ошибкой № 2490 и смог доделать ее до обеда. Я столкнулся с некоторыми проблемами, но Эшли смогла объяснить несколько вещей, чтобы завершить задание.
После этого я перешел к задаче 5501, которая представляет собой изменение метки в меню навигации. Я буду работать над этим большую часть утра ».
Видите ли, это не только лучше звучит, но и информативно для всей команды. Никогда не знаешь, какие проблемы ты решил, детализировав.
В моих выступлениях были случаи, когда ошибка, над которой я работал, естественным образом решала проблему, над которой другой разработчик собирался начать работать в тот же день.
Блокировщики кода
Хотя нам неприятно это признавать, особенно если мы потратили много времени, пытаясь исправить конкретную проблему, блокираторы важно донести до других членов команды во время стендапа.
Чтобы продолжить и решить проблему потраченного впустую времени, не позволяйте себе зацикливаться на конкретной проблеме кодирования более 30 минут. Свяжитесь с членом команды, отправьте чат или напишите подробное электронное письмо после того, как вы исследовали и попытались решить проблему самостоятельно. В любом случае, да, блокираторы - отстой.
Есть две основные причины, по которым вы должны упоминать свои блокаторы во время стендапа.
- У других членов команды может быть быстрое и простое решение проблемы, на которой вы застряли. Еще лучше, они могли решить ту же проблему раньше и провести вас через процесс.
- Это позволяет руководителям и другим разработчикам знать, где вы находитесь в процессе разработки. Если вы упомянули блокировщик во время утреннего стендапа, то вы и другой разработчик потратите полдня, пытаясь его исправить, ваше время оправдано и учтено. Если вы потратите неделю, пытаясь обойти блокирующий, и никому не скажете, пока не станет слишком поздно, то вы будете считаться недостаточно эффективными.
Ага, я знаю, как это бывает. Вы думаете про себя: «Еще пять минут, и я решу эту проблему». Ну, это не всегда так.
Мы, конкурентоспособные разработчики, ненавидим просить о помощи, нам просто нужно сделать это ради доработки продукта и ради обучения у других разработчиков. Если вы никогда не задаете вопросов, как вы научитесь?
«Человек, который задает вопрос, - дурак на минуту, человек, который не спрашивает, - дурак на всю жизнь». - Конфуций
Справочные запросы на извлечение и номера ошибок
Вы оставили подробные комментарии и информацию об ошибках или запрос на включение, о которых стоит упомянуть?
Возможно, вы попросили ведущего разработчика во время стендапа просмотреть один из ваших запросов на включение.
Если есть еще один запрос на перенос, который необходимо выполнить перед этим, или если есть проблема, которую необходимо решить до того, как ваш запрос на перенос будет полностью завершен, укажите об этом. Назовите цифры, отправьте ссылку после того, как закончите стоять.
Все это сделано для того, чтобы облегчить работу другим членам команды. В конце концов, мы хотим работать вместе, чтобы сделать нашу жизнь проще, продуктивнее и эффективнее. Если цель не в этом, то зачем мы тратим время на настройку конвейеров и внедрение CI / CD?
Быть заинтересованным
Интерес к проекту, над которым вы работаете, является одним из мотивирующих факторов, которые заставят вас прилагать усилия в своей работе и делать все, что в ваших силах.
Многие люди согласны с тем, чтобы приходить на работу, мало что делать и получать зарплату… но какое качество жизни это даст вам?
Предложить улучшения
Будьте в восторге от того, что строит ваша команда! Есть ли улучшения, которые вы хотели бы предложить? Может быть, создаются какие-то компоненты, которые можно было бы построить лучше?
Может быть, членам команды следует начать линтинг своего кода перед открытием запроса на перенос, чтобы код был более эффективным, а время сборки сократилось? Может быть, вам стоит предложить руководство по стилю для создания поддерживаемого кода?
В конце концов, если код чистый, оптимизированный и безопасный, результаты конечного продукта последуют. Даже если остальная часть вашей команды ленива и разобщена, не бойтесь выделяться.
«Лучше принять дискомфорт от того, что ты отличался от других, чем удобство приспособления» - Огво Дэвид Эменике
Командные цели
Какие цели сейчас наиболее важны для вашей команды? Возможно, ведущему специалисту потребуется определенная функциональность, чтобы веб-приложение было завершено для демонстрации, которая состоится в эту пятницу.
Убедитесь, что вы понимаете цели, чтобы добиться прогресса и оправдать ожидания.
Я видел тысячу раз, когда разработчик просто не спрашивал, потому что боялся, что это потребует от них дополнительной работы или им действительно придется что-то делать для изменения.
Не будь таким разработчиком, который ни к чему не приведет ни в жизни, ни в карьере.
Протяни руку помощи
Если другой разработчик в команде упоминает, что он работает над определенной ошибкой, и у вас есть некоторый опыт в этой области приложения, сообщите об этом!
Дайте им знать, чтобы пинговать вас в Slack или отправить вам электронное письмо, если у них есть какие-либо вопросы. Это особенно важно, если это новый разработчик. Вы хотите, чтобы они знали, что каждый человек в команде работает не для себя.
Вы - команда, поэтому вы работаете вместе, чтобы вывести всех на финишную прямую.
Быть полмолвлеными
Честно говоря, вовлеченность - одна из черт многих успешных разработчиков. Разработчик может столкнуться с проблемой, и независимо от того, насколько она серьезна, он займется решением проблемы, задаст себе вопросы и в конечном итоге придет к решению.
Затем, придя к решению, они задействуют его, чтобы сделать его лучше, быстрее и сильнее. Я не прошу вас найти решение или решить проблему прямо сейчас, я просто прошу вас быть более вовлеченными во время выступления.
Задавать тон
Это может быть сложно, если ваша команда встает рано утром. Пусть это не звучит так, будто вы потеряли лучшего друга, а затем выпитый кофе вызвал взрывную диарею.
Во время стендапов создавайте воодушевляющую и амбициозную атмосферу, когда участвуете в разговоре. Даже если возникла проблема или вы столкнулись с блокировщиком, будьте оптимистичны по этому поводу.
Если вы устанавливаете плохой тон во время стенда, особенно утреннего стенда, то день, скорее всего, будет плохим.
Высказываться
Если вы выступаете с помощью голосовой связи, а не физически в конференц-зале, то объявите о себе, когда присоединитесь к разговору.
Например, когда я вызываю стенд-ап для своей команды, я говорю: «Доброе утро, Майкл здесь». Это звучит странно, но позволяет другим участникам вызова, которые, возможно, присоединились раньше, узнать, что это я на вызове, а не привидение.
Если вы заметили, что звонит кто-то новый, возможно, он только что присоединился к команде, представьтесь. Сообщите им, чем вы занимаетесь в команде, и дайте им знать, что если у них возникнут какие-либо вопросы, они могут свободно обратиться к вам.
Я лично поставил перед собой цель быть более вовлеченным в этом году, и это изменило мой подход к написанию кода, получению конструктивной критики и общению с товарищем по команде.
Видите ли, вовлеченность - это умение слушать, понимать и помогать другим. Небольшое замечание о том, как помогать другим ... не делайте этого во время выступления.
Часто у разработчиков возникают вопросы во время стендапов или у них есть блокировщик, с которым они имеют дело и нуждаются в вашей помощи. Вместо того, чтобы решать проблему во время стенда, пока другие люди ждут, попросите их передать вам сообщение.
Это имеет смысл, потому что стендапы - не место для решения возникших проблем и проблем, а также не место для того, чтобы зря тратить время других людей.
То же самое происходит, если вам нужна помощь другого разработчика. Не ждите, что кто-то поможет вам во время стендапа, если другой разработчик желает вам помочь и хочет, чтобы вы связались с ним после этого, обязательно свяжитесь с ним.
Заключение
Если вы сделаете то, что было упомянуто в других частях этой статьи, выделиться у вас будет естественно.
Если компания видит, что вы не заинтересованы и не воодушевлены тем, что строит ваша команда, то это настроение и мыслительный процесс в конечном итоге проявятся в готовом продукте.
Будьте как можно лучше и не бойтесь выделяться. Выдающиеся люди работают в лучших компаниях.
Единственная причина, по которой эти компании являются лучшими, заключается в том, что люди, работающие на них, хотят выделяться, они хотят, чтобы их команда выделялась, и они хотят, чтобы выделялась компания, в которой они работают.
Как я могу быть более вовлеченным, заинтересованным и подробным в своей работе?
Я задаю себе этот вопрос не реже одного раза в неделю. Это хорошая практика, потому что она помогла мне выделиться не только во время стендапов, но и с любым продуктом, к которому мои руки прикасаются.
