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