Введение
Как на смену ручному производству пришло конвейерное, так на смену программисту-одиночке пришли команды. Современные программы создаются командами, а не одиночками. Как таковое понятие гения программиста одиночки изолированного от мира и разрабатывающего что-то у себя в компьютере сейчас устарело и вымерло. Создание конкурентоспособного ПО в современном мире возможно только командами. Человек может быть превосходным программистом знать множество парадигм, языков, паттернов, но ужасно работать в команде, постоянно спорить, быть трудным в общении, что в целом дает нам посредственного члена команды, который скорей будет замедлять команду, чем двигать ее вперед.
В данной статье я хотел бы сделать краткий пересказ двух книг, которые, по моему мнению, наиболее полно отражают эту идею и дают хорошие рекомендации по коммуникации в командах, решению разногласий среди членов команды и организации такой команды в целом.
Основные принципы
Уважение, скромность, доверие - принципы, которые должны быть основой любой командной работы.
Уважение
Вы искренне проявляете внимание к тем, с кем работаете. Вы обращаетесь с ними как с людьми и цените их способности, достижения, пытаетесь понять их позицию и аргументы. Критикуя решения другого человека, вы сосредотачиваетесь не на его характере, а на желании разработать наиболее удачный продукт. Важно услышать позицию и аргументы разработчика. Так к менее уверенным в себе людям стоит применять более мягкий подход. Например основывать свои замечания на сложности восприятия для вас. То есть, не стоит подходить к коллеге и говорить: "Ну и ошибок же тут наделал, лучше было бы сделать вот так". Это может спровоцировать негативные эмоции по отношению к вам, хотя вы и были настроены на улучшение качества кода. В подобной ситуации были задеты чувства коллеги, и скорее всего он будет ощущать себя дураком. Лучше выразить эту мысль так: "Я не совсем понял поток команд, может быть стоило использовать стандартный шаблон, чтобы в дальнейшем с ним было проще разобраться и работать?". В данном примере проблема исходит от вас, это вы не понимаете код, а человек здесь не при чем. Важно не требовать, чтобы коллега обязательно поправил данный участок, а только предложить возможность улучшения для повышения читаемости при дальнейшем развитии проекта.
Скромность
Вы — не центр вселенной и тем более не пуп земли. Вы не являетесь всезнающим и непогрешимым. Важно это понимать, быть открытым к изменениям, самосовершенствоваться и уметь признавать свои ошибки. Никто не хочет работать с человеком, который думает, что он самый умный. Даже если вы считаете себя таковым, не стоит на этом акцентировать внимание и тем более бросать свою убежденность в этом людям в лицо. При совместной работе люди сами смогут по достоинству оценить ваши знания. Задумайтесь, как часто у вас есть желание высказывать свое мнение по каждому поводу, хочется ли вам прокомментировать результаты каждой выполненной задачи или обсуждения? Стоит отметить, что проявление скромности не должно затрагивать вашу уверенность в себе, просто не нужно производить впечатление всезнайки.
Доверие
Вы верите в то, что другие люди компетентны и действуют в правильном направлении. Для вас не проблема передать им инициативу, когда это возможно. Вы воспринимаете чужую критику как попытку улучшить ваши подходы и разрабатываемый вами программный продукт, а не как личную критику. Второе является проявлением мелочности и не должно иметь место в культуре профессиональных разработчиков ПО. Учитесь уважать коллег и критикуйте их конструктивно и вежливо. Также важно уметь принимать критику. Это подразумевает не только скромность по отношению к собственным навыкам, но и доверие к тому, что другой человек искренне неравнодушен к вашим ключевым интересам и интересам вашего проекта, и не считает вас идиотом.
Соблюдая эти принципы при работе в команде, можно добиться больших результатов от взаимодействия с ее членами. Люди начнут чаще идти на контакт с вами, обмениваться опытом, просить помощи, советоваться. Конечно, принципы не отменяют необходимости хороших знаний в выбранном языке программирования, архитектуре, алгоритмах и так далее. Но стоит помнить, что один отличный программист, пренебрегающий требованиями командной работы, будет скорей замедлять команду, чем двигать ее вперед.
Я — незаменим
Практически любой программист в тот или иной момент времени начинает считать себя незаменимым. "Вот если я завтра уйду, компания загнется. Они ничего без меня не смогут, они поймут какого ценного работника потеряли!". В действительности это, как правило, не так. Люди увольняются с работы каждый день. Многих увольняют. Многие увольняются сами. Но покидаемые ими фирмы крайне редко ощущают последствия их ухода. В большинстве случаев, даже когда речь идет о ключевых сотрудниках, эффект оказывается на удивление слабым. Ваше присутствие в фирме подобно ведру воды с камешками. Вы выполняете свои обязанности, вносите свой вклад в общее движение фирмы. Да, от одного камешка общий уровень воды будет выше, но если убрать из ведра один камешек и посмотреть на поверхность воды, вряд ли кто-то сможет увидеть разницу. Это не значит, что твоя роль в компании не ценится. Для успешной работы всем необходимо чувство значимости и полезности. Это лишь говорит о том, что не стоит смотреть на работу фирмы только с точки зрения своего "я". Вокруг вас такие же люди, которые вносят свой вклад в развитие компании и хорошо выполняют обязанности. Как правило, если вы уволитесь, то это произведет такой же эффект, как если бы это сделал кто-нибудь из ваших коллег.
Скромность — путь к развитию
Помни о том, как ослепляет собственный успех.
Как правило, чувство вашей незаменимости является плохим симптомом и заключается в обладании не столько исключительными навыками в программировании, сколько в обладании контекстом о программе и ее бизнес логике. Можно привести множество примеров того, как собственный успех ослеплял разработчика. Его повышали, он начинал всем раздавать советы и делиться опытом, но из-за своей самоуверенности со временем терял позиции. Его знания неизбежно устаревали, он понимал, что находится уже не на гребне последних течений в разработке, а далеко позади. И такая участь может постигнуть любого человека, поверившего в свою непогрешимость и исключительность. Хорошей практикой является поиск новых более глобальных уровней качества архитектуры и производительности. На локальном уровне, допустим внутри компании, в которой работаете, вы можете быть одним из лучших разработчиков. Но, чем больше вы будете расширять область видимости, тем более реальную картину о своем уровне знаний вы получите. Повышая свой уровень относительно более глобальной области знаний в разработке, вы тем самым будете повышать и уровень разработчиков вокруг себя. Это также благотворно скажется на вашем дальнейшем развитии, так как сильные разработчики притягивают других сильных разработчиков.
Будьте скромными и не останавливайтесь на локальных достижениях и сравнивайте себя со специалистами мирового уровня. Это поможет вам постоянно развиваться и не останавливаться на достигнутом.
Заключение
Разработка ПО в рамках хорошо сплоченной команды, как правило, протекает быстрее и надежнее. Разработчики чаще делятся опытом и знаниями, последними новостями о проделанных изменениях и возникших проблемах. Такая обстановка способствует обмену идеями и повышает общую осведомленность о ходе работы. Поэтому созданию культуры скромности, доверия и уважения стоит уделить не меньше внимания, чем интеллектуальным способностям разработчиков. Разработчик должен быть не только отличным мастером своего дела, но еще и хорошим командным игроком.
Список литературы
1. Программист-фанатик. - Фаулер Ч. ISBN 978-5-4461-0846-6
2. Идеальная IT-компания. Как из гиков собрать команду программистов. - Фитцпатрик Б., Коллинз-Сассмэн Б. ISBN 978-5-496-00949-2
