Pull to refresh

Работать в командах, или нет?

Reading time 5 min
Views 4.5K
работа в команде


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

Данную статью я разбиваю на четыре основных преимущества, которые явно видны и малооспоримы, основываясь на которых можно начать аргументированное внедрение командной работы в организации. На самаом же деле преимуществ значительно больше и работа по их описанию может служить подспорьем для создания целой серии книг.

И еще один момент. Альтернативную модель построения организации я буду называть моделью “одинокого программиста”.

Сплоченность коллектива

сплоченность коллектива


Начнем именно с этого преимущества работы в команде, по скольку любая организация — это прежде всего люди, и от того на сколько они будут чувствовать себя комфортно, на сколько они будут чувствовать себя частью чего-то большего и на сколько они буду помогать друг другу зависит эффективность работы всей организации.

Вместе — мы сила, по одиночке — мы никто. Работая в команде, задачи любой сложности выполняются быстрее, качественнее и веселее, чем в одиночку. И даже если возникает вопрос “не дороже ли использовать команду для конечного заказчика?” я с уверенностью отвечу — нет. Экспериментальным путем было выяснено, что если посчитать человеко-часы команды и одного программиста, при работе над одной и той же задачей, то команда потратит их меньше. Если не верите — можете проверить.

Работая изо дня в день с одними и теми же людьми, сотрудник сближается с командой, таким образом приобретая чувство постоянства на рабочем месте, которого так не хватает в модели “одинокого программиста”, и которое вызывает ненужные стрессы на работе. Конечно же уйдет некоторое время на “притирку” характеров, но оно не существенно по сравнения периодом после “притирки”.

В команде разработчик всегда может рассчитывать на поддержку и помощь товарища, в модели же “одинокого программиста” никогда нельзя такого делать, ведь твоего товарища в любой момент могут сорвать на дополнительные задачи, новый проект и т.д.

В команду легче вливается новый сотрудник, по скольку ему не нужно выбирать с каких задач начинать свою работу и как их выполнять, за него это сделает команда, соответственно у такого человека не будет возможности расслабиться на самом старте своей карьеры и такой сотрудник сможет развиваться гораздо быстрее.

Единство мышления

Единство мышления

Ни для кого не секрет, что разные разработчики могут решить одну и ту же задачу разными способами, и наверное каждый из разработчиков сталкивался с ситуацией, когда споры по поводу схемы решения задачи занимают куда больше времени, чем сама реализация такого решения. Эта ситуация с легкостью самоисключается из рабочего процесса, когда разработчики работают длительной время друг с другом, в таком случе они выберут единое решение и будут им пользоваться постоянно, не теряя время на ненужные споры. И еще одно замечание: решение команды всегда более объективное и оптимальное, поэтому и продукт разрабатываемый командой работет лучше.

А вот еще одна ситуация, которая достаточно часто встречается в повседневной жизни разработчика: тебе срочно нужно подправить часть проекта, которую делал другой разработчик и ты не имеешь ни малейшего понятия как это поправить. И что же происходит в модели “одинокого программиста”? В лучшем случае тебе на пальцах объясняют как это сделать и где, в худшем — ты сам ищешь, теряя большое количество времени. Данная задача снова самоисключается, если команда пользуется единым подходм в решении задач. Разработчик не ищет и не спрашивает — он просто делает.

И последнее — это вопрос коммуникации. Проработав с одними и теми же людьми большой промежуток времени разработчик может донести свое мнение в двух словах и понять своих коллег с полу слова, а это так важно в условиях экстремальной читуации на пректе.

Единые кодинг стандарты

Единые кодинг стандарты


А сколько споров и негодований в вашей организации посвященных некачественно написаному коду?
В процессе командной работы разработчики начинают не только мыслить одинаково, но и писать одинаковый код, и даже если у вас нет единых хорошо описанных кодинг стандартов, и нет возможности их описать в виду большой загрузки, или же отсутствия иницииатора, команда сам а выработает себе такие стандарты в процессе “притирки”, и будет беспрекословно им следовать и дополнять их, ведь понапрасну спорить не хочит никто — это факт.

Новые сотрудники так же смогут быстро понять и использовать эти стандарты, в виду присутствия кода с единым форматированием на всех проектах команды и старых сотрудников, активно обучающих новых, в виду нежелания переписывать чужой код.

Устойчивость к влиянию внешних факторов

Устойчивость к влиянию внешних факторов


Бывало ли у вас такое, что очень срочно нужно доделать какую-то вещь, но без верстальщика это просто невозможно сделать, а его нет? Я думаю что вы понимаете это неловкое чувство, когда администратора web сервера нет на месте в самый неподходящий момент, а нужно подправить htaccess. Или же frontend программист заболел, после неотдебаженного обновления приложения.
Так вот, если использовать подход кроссфункциональной команды — то вышеописанные ситуации не смогут остановить процесс разработки и поддержки приложения, а лишь немного его замедлят. Ведь в замкнутом обществе, которым является команда, сотрудники более активно делятся своими знаниями и опытом, развивая каждого члена команды в сфере своей специализации. В итоге, через некоторое время мы получаем команду, в которой каждый из сотрудников может выполнять разные роли, и при необходимости заменять заболевшего или отсутствующего колегу. Таким образом вопросы о выделении frontend разработчика или верстальщика отпадают сами по себе.
Необходимо упомянуть о том, что кросфункциональная команда с легкостью справляется с несколькими проектами одновременно, и при достаточном количестве сотрудников легко разрабатывает и поддерживает до пяти проектов. Это взято из личного опыта, и вы можете это проверить, если хотите.

Централизованность управления

Централизованность управления


Следить за достижениями и недостатками в работе сотрудника не сложно, пока таких сотрудников менее десяти, но когда их становится больше — нередки случаи того, что “подвиг на работе” или “явное послабление желания работать” останутся не замеченными. И чем больше штат компании — тем больше незамеченных людей. Это факт.

Но если перенести уровень ответственности с каждого сотрудника на командный — то именно команда будет тем стимулятором, который не даст сотруднику расслабиться. И куда проще увидеть достижения и недостатки среди нескольких команд, чем среди нескольких десятков сотрудников.
Таким образом разделив много сотрудников на несколько команд — работа руководства становится менее трудоемкой а сложный процесс поощрения и наказания — значительно упрощается.

Выводы

В нашем стремительно развивающемся мире побеждают те, кто более организован внутри и гибок снаружи, поэтому я считаю, что не стоит брезговать теми средствами, которые делают организацию еще более организованной и внедрять командную работу на уровне рядовых сотрудников. Данный пост не является руководством по внедрению команд, а лишь мои размышления о командной работе, поэтому не судите строго.

На последок хочу рекомендовать одно замечательное видео о преимуществе коллективизма:



Пробуйте, требуйте двигайтесь и достигайте!
Tags:
Hubs:
-10
Comments 11
Comments Comments 11

Articles