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

работа в команде


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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


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

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

Выводы

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

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



Пробуйте, требуйте двигайтесь и достигайте!

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 11

    +8
    «Команда» пишется таки с одной «м». Ваш граммар-наци.
      0
      Спасибо, поправил.
        0
        А в рсс осталось :(
      +2
      невозможно читать статью из-за количества ошибок
        –7
        К сожалению, уважаемый Dimond17 придется ответить на ваш коммент, хоть и не хотелось. Как говорится «В чужом глазу соринку видит, а в своем бревна не замечает».
        Я вполне нормально отношусь к критике, если она конструктивна, но если коммент написан для того, чтобы написать (потролить), или для того чтобы поднять карму, или еще из каких-то субьективных соображений — то мне, как и многим здесь неприятно читать такие комменты. Так что-же более достойно, писать смысловые посты с ошибками и исправлять их, или писать комменты без смысла?
          +3
          Если вы приходите в банк с целью сделать крупный вклад, а там столы обшарпаные, везде мусор, девочки-операторы в углу шепчутся и вас игнорируют — вы будете делать вклад в этом банке? Не думаю. Точно так же никто не будет всерьез воспринимать статью, в заголовке которой «коммандный», а в тексте — «Данную статью я разбиваю на четыре основных преимущества».

          Никто про троллинг и карму не говорит. Просто серьезные вещи должны серьезно подаваться.
            –6
            К сожалению, моя задача не состоит в том, чтобы навязать Вам кредит (естественно немного заработав на Вас), а является лишь безкорыстным поступком, причем первым поступком такого рода. Поэтому давайте относиться к этим вещам по-разному.
            И по поводу поста. Серьезном его назвать сложно, ведь он являеться лишь наброском, и это написано в последнем абзаце.
        +1
        Попробуйте, для начала, русский подучить, а в коММанде или нет сами решайте
          –1
          Подучить — то можно, но от механических ошибок никто не застрахован.
          +4
          Вообще, статья очень напоминает не слишком удачный перевод. Особенно ужасной подборкой клипарта
            0
            Это не перевод, а личные размышления. С картинками действительно не хорошо получилось, учту в следующих постах.

          Only users with full accounts can post comments. Log in, please.