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