Читать книгу Идеальная IT-компания. Как из гиков собрать команду программистов - Брайан Фитцпатрик - Страница 16

Джо получил новую работу программистом. Через неделю он стал внимательно изучать базу исходных текстов. Живо интересуясь происходящим, он деликатно расспрашивал своих коллег по команде о плодах их творчества. Он рассылал по электронной почте рецензии на коды, вежливо интересуясь о принятых допущениях и указывая на фрагменты, логику которых можно было улучшить. Через пару недель директор вызвал его к себе в кабинет. «Что случилось? – спросил Джо. – Я сделал что-то не так?» Директор выглядел обеспокоенным: «Мы получили много жалоб на твое поведение, Джо. Очевидно, что ты занял очень жесткую позицию по отношению к своим коллегам, критикуя их направо и налево. Они недовольны. Необходимо, чтобы ты стал мягче». Джо пришел в полное замешательство. В корпоративной культуре, основанной на скромности, уважении и доверии, коллеги Джо должны были приветствовать и ценить анализ кода, который он делал. Тем не менее в данном случае Джо слишком сильно воздействовал на чувство незащищенности команды и ему следовало вводить анализ кода в командную культуру более деликатными методами.

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

С другой стороны, вам также необходимо учиться принимать критику. Это подразумевает не только скромность по отношению к собственным навыкам, но и доверие к тому, что другой человек искренне неравнодушен к вашим ключевым интересам (и интересам вашего проекта!) и не считает вас идиотом. Программирование – такой же навык, как и любой другой. Он совершенствуется с практикой. Если коллега указал вам на то, как можно усовершенствовать ваши приемы, то воспримете ли вы это как нападки на ваш характер и попытку унизить ваше достоинство? Надеемся, что нет. Аналогичным образом, ваша самооценка не должна быть связана с кодом, который вы пишете. Вы и ваш код – не одно и то же. Повторяйте это снова и снова. Вы и ваш код – не одно и то же. Вы должны не только сами поверить в это, но и заставить поверить в это ваших коллег по работе.

Не отождествляйте самооценку с качеством вашего кода

Например, при работе с коллегой, которому не хватает уверенности в себе, следует избегать фраз типа «Приятель, ты наделал ошибок в потоке команд этого метода. Тебе стоит воспользоваться стандартным шаблоном кода, как поступают все». Такая реакция состоит из нежелательных приемов: вы говорите коллеге, что он «наделал ошибок» (как будто мир состоит из черного и белого), требуете, чтобы он что-то изменил, и обвиняете его в том, что он создал нечто, идущее вразрез с результатами других людей (тем самым заставляя его чувствовать себя дураком). Скорее всего, вы вызовете у коллеги негативную эмоциональную реакцию и заставите его занять оборонительную позицию.

Вот более удачный способ выразить ту же самую мысль: «Приятель, я не очень хорошо понимаю поток команд в этой части кода. Может быть, с ним будет проще разобраться и работать в дальнейшем, если воспользоваться стандартным шаблоном?» Обратите внимание на то, как вы, проявляя скромность, ставите вопрос о себе, а не о нем. Он не совершил ошибку – вы просто не понимаете код. Предложение нацелено на то, чтобы вашей скромной персоне все стало ясно и, возможно, поспособствовало бы устойчивому развитию проекта в долгосрочной перспективе. Вы также ничего не требуете и даете коллеге возможность спокойно отклонить ваше предложение. Обсуждение не выходит за рамки кода и не касается чьего-либо достоинства или навыков программирования.