Вы можете писать программное обеспечение в составе команды, не создавая себе препятствий
Известная пословица звучит примерно так: Хочешь идти быстро — иди один; если хочешь идти далеко, иди с другими. Как разработчики программного обеспечения, мы знаем, что работа с другими людьми требует усилий. Даже ваши самые близкие друзья и коллеги не знают автоматически то же, что и вы, и требуется время, чтобы объясниться с ними.
По мере того, как ваша команда разработчиков программного обеспечения становится больше, каждый разработчик тратит все больше и больше времени на объяснение. Если вы посмотрите на действительно большой распределенный проект, такой как база кода Microsoft DotNet, вы можете увидеть важные проблемы и запросы на вытягивание, которые обсуждались в течение лет. Иногда это просто цена, которую вы платите за тонкое, но важное исправление чего-то значительного.
К счастью, большинству из нас не приходится иметь дело с огромными кодовыми базами или гигантскими распределенными по всему миру командами. Сегодня я хотел бы поделиться техникой, которую использую при работе с командами среднего размера — от пяти до пятидесяти человек. Я называю это предвзятостью к действию, и вот как это работает.
Как мне обратиться за помощью к другим разработчикам?
Любой разработчик, работающий над проектом, иногда должен обратиться за помощью к старшему члену команды или архитектору. Они могут столкнуться с ошибкой в коде, или не знать, какую библиотеку использовать, или не знать об официальном стандарте внедрения зависимостей.
В подобной ситуации разработчик часто говорит: «Мне нужна помощь по теме. Кто мне ответит на это?» Если разработчик получит помощь сразу, отлично!
Но что происходит, когда помощь оказывается не сразу? Разработчик застрял в ожидании. Они могут продолжать спрашивать в каналах группового чата или по электронной почте, но пока не придет помощь, они будут заблокированы.
Что, если они попробуют другой подход?
Рассмотрим эти два способа, которыми разработчик может обратиться за помощью:
- «Мне нужно выяснить, какую библиотеку использовать для проекта Y. Я просмотрел X и Z. Может ли кто-нибудь помочь мне выбрать правильную?»
- «Я планирую использовать библиотеку X для проекта Y. Если у кого-то есть идеи получше, не могли бы вы сообщить мне об этом до вторника? Если к тому времени у меня не появится идея получше, я начну использовать X».
Первый пример здесь — вежливая просьба, но из-за нее другим разработчикам сложно помочь. У коллеги может не хватить времени для оценки библиотек X и Z, или он может чувствовать, что знает достаточно, чтобы ответить на вопрос.
Второй пример демонстрирует склонность к действию. Вы установили путь переадресации по умолчанию в случае отсутствия ответа. Вы начнете использовать библиотеку X во вторник, но другие разработчики могут внести свой вклад и повлиять на ваше направление, если захотят.
Почему никто не ответил? Может быть, нужный член команды уехал в отпуск. Возможно, вы задали хороший вопрос, и никто не знает правильного ответа. Возможно, оба подхода верны. Неважно, какая причина вызвала отсутствие ответа; когда наступит вторник, вы разблокируетесь. Тем не менее, даже если вы не получите ответа, вы все равно создадите возможности для совместной работы.
Выход из тупика комитета с уклоном в сторону действий
Такой же подход может быть полезен, когда вы работаете в правлении или комитете над сложной темой. Часто случается, что проблема возникает сама собой, и несколько человек в команде имеют разные мнения о ее решении.
Но как выбрать путь вперед, когда у всех разные предпочтения? Некоторые члены команды внимательно выслушивают аргументы и работают над тем, чтобы прийти к соглашению. Другие упираются и не принимают ничего, кроме своего первого выбора.
Подходя к этой проблеме с уклоном в сторону действия, мы можем представить два разных способа представить эту проблему вашему совету или комитету:
- «Мы столкнулись с проблемой доставки электронной почты; десять процентов не доставляются из-за блокировщиков спама. Как мы можем решить эту проблему и повысить проходимость?»
- «У нас возникла проблема с доставкой электронной почты, и наш руководитель производства хочет передать систему электронной почты компании X за 500 долларов в месяц. Кто-нибудь видит лучший путь вперед?»
В обоих случаях мы обращаемся за советом к комитету, но в одном случае мы устанавливаем путь вперед по умолчанию, который команда может принять, если не существует лучшей альтернативы.
С предвзятостью к действию комитет может сколько угодно не соглашаться. Если обсуждение приведет к лучшему решению, прекрасно. Если это не так, в какой-то момент следует принять план действий по умолчанию.
Ключевым отличием предвзятого подхода к действию является предположение о пути вперед по умолчанию. Вместо того, чтобы сказать: «Я прекращу работу и подожду ответа, прежде чем двигаться дальше», вы говорите: «Я собираюсь сделать это, но я открыт для того, чтобы меня убедили в обратном».
Обработка подписей с уклоном в сторону действия
Аналогичный подход можно использовать для управления выходами из проекта. В современном бизнесе вы можете использовать подход к управлению людьми, такой как RACI, когда люди разделены на тех, кто несет ответственность, подотчетен, консультируется и информируется о конкретной части работы.
Трудно управлять работой, которая требует десятков подписей. На самом деле, многие практики RACI не одобряют практику, когда более одного человека подписывает конкретный проект. Но в действительности мы часто сталкиваемся с ситуацией, когда нам необходимо проконсультироваться с несколькими людьми и получить их отзывы.
Что происходит, когда один из этих людей отказывается дать своевременный отзыв? Вот два способа попросить подпись:
- «Мне нужно ваше одобрение для запуска проекта X. Не могли бы вы просмотреть этот документ и отправить мне свое одобрение как можно скорее?»
- «Мы запускаем проект X к 20-му числу месяца, и нам нужно, чтобы все возражения были поданы до 13-го числа. Вы можете подать свое возражение здесь, или, если мы не получим ответ к этой дате, мы пометим вас как одобренных по умолчанию».
Если у вас мало времени, вы можете пойти дальше и запросить у членов команды одобрение до обязательного окончания срока. В вашем сообщении может быть сказано: «Мы запустим релиз через 7 дней после того, как все отделы одобрят выпуск». С этой стратегией вы потенциально можете выйти раньше 20-го числа, если все отделы быстро реагируют.
Стоит ли сдерживать пулреквест?
Программисты хотят быть уверены, что их код правильный. Я встречал многих программистов, у которых есть идея, как решить конкретную задачу, но когда последствия ошибок серьезны, они могут попросить других членов команды подтвердить, что они поступают правильно.
Это часто происходит, когда программисты работают над конфиденциальным фрагментом кода, связанным с безопасностью, платежами или электронной почтой. Смотреть на что-то и думать о том, как все может пойти не так, может быть нервно. Такие программисты часто блокируются в ожидании поощрения.
Требуются усилия, чтобы убедить обеспокоенного программиста в правильности его решения. Что, если вместо того, чтобы ждать, пока вас кто-нибудь успокоит, вы запустите свой пулл-реквест и пометите его как черновик? Затем вы можете обсудить это в ежедневном стендапе, запросить отзыв или отправить приглашение на встречу другому товарищу по команде, чтобы обсудить его подробно.
Важно задокументировать свои опасения. Какая бы часть кода ни вызывала у вас ужас, добавьте к ней комментарий: «Я не уверен, что это правильный способ сделать X. Метод А кажется мне правильным; но меня беспокоит риск R». Этот тип комментария помогает другим сузить свою работу до той области, которая имеет значение.
В ответ вы можете увидеть одно из следующего:
- Если есть ошибка, член команды может заметить ее и сообщить вам, что позволит вам разблокировать ваш запрос на вытягивание.
- Если вы поднимаете интересное беспокойство, другие программисты могут извлечь из этого уроки и выработать лучшие привычки.
- Если ваш код на самом деле правильный, вы не заблокировали себя, и в конечном итоге запрос на извлечение будет выполнен.
Лучшая часть этого подхода заключается в том, что у вашей команды есть шанс помочь вам в конкретном вопросе, который в первую очередь вызвал беспокойство. По моему опыту, инженеры гораздо лучше умеют читать запрос на включение и давать предложения по чему-то конкретному, чем обсуждать смутные проблемы, не связанные с реальным кодом.
Когда уместно использовать уклон в сторону действия?
Концепция предвзятости к действию не меняет нашу работу, это просто другой способ привлечь к участию других. Вместо того, чтобы говорить У меня есть идея, но я не буду ее реализовывать, пока мне не ответят, вы прокладываете путь вперед и говорите: вот что я сделаю, может ли кто-нибудь сделать это лучше?
Я должен предупредить вас, что склонность к действию можно злоупотреблять негативным образом. Если вы создадите слишком много кода, прежде чем пригласить других оставить отзыв, они могут расстроиться, работая с вами. Большие запросы на вытягивание часто являются проблемой — возможно, вам следует отдавать предпочтение небольшим изменениям?
В идеале у вас должно быть интуитивное понимание того, когда необходим разговор — например, перед началом большого проекта или перед выполнением огромного количества рефакторингов. Вам нужно найти правильный баланс.
Если вы просто работаете над небольшим проектом, вы должны интуитивно понимать, что вред от быстрого продвижения невелик. Вы должны быть свободны в предвзятости к действию, чтобы сохранить импульс. Это же правило не распространяется на большую работу — вы не можете стать магазином из одного человека, доставляя код без консультации.
Здесь есть два риска, каждый из которых является противоположной стороной одной медали:
- Если вы будете слишком долго ждать, прежде чем начать работу, проект может быть парализован, выйти за рамки срока или выйти за рамки бюджета.
- Если вы начнете работу слишком рано, возможно, вам придется переделывать часть работы или разрешать конфликты с членами команды, которые не согласны с подходом.
У вас должно быть планирование, а у вашей команды должны быть обсуждения. Вы не должны предвзято относиться к действию, чтобы избежать этих вещей. Но когда вы обнаружите, что регулярно блокируетесь из-за мелочей, возможно, пришло время подумать об этом.
Как часто ваша команда говорит такие вещи? Все это признаки того, что, возможно, пора задуматься о переходе к действию:
- «Я написал запрос на вытягивание для X две недели назад, но я жду, пока человек P поговорит со мной, чтобы подтвердить, что это правильно, прежде чем я отправлю его».
- «Я все еще заблокирован на задаче T. Мне нужно, чтобы менеджер М сказал мне, какого провайдера использовать, когда я пишу виджет».
- «Я написал некоторый код, но я не уверен, соответствует ли он лучшим практикам. Мне нужно, чтобы архитектор команды посмотрел на это и сказал, можно ли его отправить».
Если ваша команда регулярно оказывается в тупике или неуверенности и не может добиться прогресса, возможно, пришло время предложить другой способ сделать что-то.
Тед Спенс возглавляет разработку в ProjectManager.com и преподает в Bellevue College. Если вы интересуетесь разработкой программного обеспечения и бизнес-анализом, я буду рад услышать от вас на Mastodon или LinkedIn.
