На многих проектах полагаются обязательные митинги (совещания), обсуждения или иные способы коммуникации. Иногда это вызвано методологией разработки, иногда избыточным количеством менеджеров, которым больше нечем заняться. Часто отказаться от участия в них просто нельзя, а порой они даже бывают полезны, но помните: ваш основной приоритет – работа над кодом.
Если вы понимаете, что излишняя коммуникация только вредит вашей работе, обсудите это с менеджером или старшими разработчиками. Скорее всего, вы сумеете договориться о возможности избегать непродуктивного общения, чтобы сосредоточиться на работе.
И наоборот: если вы понимаете, что регулярные обсуждения приносят вам пользу, позволяют лучше видеть мотивацию команды или коллег, – участвуйте в них. Правильным решением будет только то, которое подходит лично вам. Возможно, на этом этапе вам станет яснее, в каком направлении вы предпочтете развивать карьеру: будет ли это, например, совершенствование технических навыков или организация процессов разработки.
Это же относится и к общению в рабочих чатах, мессенджерах или в офисе: определите для себя комфортный уровень коммуникации и придерживайтесь его – отключайте чаты, попросите коллег не беспокоить вас, если понимаете, что они мешают сосредоточиться.
Тезисы
■ Оберегайте свое спокойствие и рабочий контекст.
■ Проанализируйте, нравится вам общение с коллегами или оно в основном лишь отвлекает от работы.
Задание
Попробуйте определить, какой уровень коммуникации на проекте вас больше всего устраивает. Старайтесь соблюдать баланс между полезной коммуникацией и сосредоточенностью на работе. Если вас отвлекают, не стесняйтесь сказать об этом. Обратите внимание и на коллег: какой уровень коммуникации для них предпочтителен?
История из жизни
Не буду скрывать – я всегда избегал лишнего общения, будь то состязание в остроумии у кулера или еженедельные совещания (о ежедневных летучках при мне даже не упоминайте). В работе я всегда был продуктивен только в одном состоянии – когда писал код. Но когда я начал руководить разработкой проектов, общению все же пришлось уделять больше внимания. Зато со временем я научился видеть в этом пользу.
Десять раз спроси, один – напиши
Разработчик почти всегда находится в поиске более качественного решения задачи, над которой работает. Если вы пишете код исключительно для себя, это отчасти упрощает задачу (или значительно усложняет, спасибо тебе, проклятый перфекционизм). Однако если вы разрабатываете код по чьим-то требованиям, то почти всегда будете располагать неполной информацией. У вас будет масса вопросов, непонятных или не до конца известных условий и особенностей продукта, которые необходимо выяснить.
Никогда не бойтесь и не стесняйтесь спрашивать обо всем, что считаете нужным при решении задачи. Нет ничего более полезного, чем полная информация о проблеме, которую вам необходимо решить. Любое предположение, не подкрепленное верными данными, может обернуться ошибкой. Любое белое пятно в требованиях может привести к необходимости выкинуть половину готового кода и начать писать его заново.
Обилие вопросов может смутить менеджеров, заказчика или старших разработчиков, но помните: вы занимаетесь разработкой не для того, чтобы о вас хорошо или плохо думали, а ради качества продукта, ради профессионализма и карьеры. Хирург не начинает операцию без знаний и опыта, точно так же и вы не можете приступить к работе, не выяснив досконально, с чем придется столкнуться.
Старайтесь упростить себе работу. Не заданный вовремя вопрос замедлит выполнение задачи либо в процессе самого решения, либо позже, когда вам надо будет вносить дополнения и изменения, которые, в свою очередь, могут спровоцировать новые ошибки.
Тезисы
■ Спрашивайте.
■ Спрашивайте.
■ Спрашивайте.