Мысль о том, что лучше работать в команде, с точки зрения обычного разработчика, с командами, с точки зрения проджект менеджера и оперировать командами, с точки зрения организации возникает достаточно часто, но адекватной практической аргументации данным утверждениям мало. Поэтому я хочу восполнить данный пробел и попытаться аргументированно доказать преимущества команд.
Данную статью я разбиваю на четыре основных преимущества, которые явно видны и малооспоримы, основываясь на которых можно начать аргументированное внедрение командной работы в организации. На самаом же деле преимуществ значительно больше и работа по их описанию может служить подспорьем для создания целой серии книг.
И еще один момент. Альтернативную модель построения организации я буду называть моделью “одинокого программиста”.
Сплоченность коллектива.
Начнем именно с этого преимущества работы в команде, по скольку любая организация — это прежде всего люди, и от того на сколько они будут чувствовать себя комфортно, на сколько они будут чувствовать себя частью чего-то большего и на сколько они буду помогать друг другу зависит эффективность работы всей организации.
Вместе — мы сила, по одиночке — мы никто. Работая в команде, задачи любой сложности выполняются быстрее, качественнее и веселее, чем в одиночку. И даже если возникает вопрос “Не дороже ли использовать команду для конечного заказчика?” я с уверенностью отвечу — нет. Эксперементальным путем было выяснено, что если посчитать человеко-часы команды и одного программиста, при работе над одной и той же задачей, то команда потратит их меньше. Если не верите — можете проверить.
Работая изо дня в день с одними и теми же людьми, сотрудник сближается с командой, таким образом приобретая чувство постоянства на рабочем месте, которого так не хватает в модели “одинокого программиста”, и которое вызывает ненужные стрессы на работе. Конечно же уйдет некоторое время на “притирку” характеров, но оно не существенно по сравнения периодом после “притирки”.
В команде разработчик всегда может рассчитывать на поддержку и помощь товарища, в модели же “одинокого программиста” никогда нельзя такого делать, ведь твоего товарища в любой момент могут сорвать на дополнительные задачи, новый проект и т.д.
В команду легче вливается новый сотрудник, по скольку ему не нужно выбирать с каких задач начинать свою работу и как их выполнять, за него это сделает команда, соответственно у такого человека не будет возможности расслабиться на самом старте своей карьеры и такой сотрудник сможет развиваться гораздо быстрее.
Единство мышления.
Ни для кого не секрет, что разные разработчики могут решить одну и ту же задачу разными способами, и наверное каждый из разработчиков сталкивался с ситуацией, когда споры по поводу схемы решения задачи занимают куда больше времени, чем сама реализация такого решения. Эта ситуация с легкостью самоисключается из рабочего процесса, когда разработчики работают длительной время друг с другом, в таком случе они выберут единое решение и будут им пользоваться постоянно, не теряя время на ненужные споры. И еще одно замечание: решение команды всегда более объективное и оптимальное, поэтому и продукт разрвабвтываемый командой работет лучше.
А вот еще одна ситуация, которая достаточно часто встречается в повседневной жизни разработчика: тебе срочно нужно подправить часть проекта, которую делал другой разработчик и ты не имеешь ни малейшего понятия как это поправить. И что же происходит в модели “одинокого программиста”? В лучшем случае тебе на пальцах обьясняют как это сделать и где, в худшем — ты сам ищешь, теряя большое количество времени. Данная задача снова самоисключается, если команда пользуется единым подходм в решении задач. Разработчик не ищет и не спаршивает — он просто делает.
И последнее — это вопрос коммуникации. Проработав с одними и теми же людьми большой промежуток времени разработчик может донести свое мнение в двух словах и понять своих коллег с полу слова, а это так важно в условиях экстремальной читуации на пректе.
Единые кодинг стандарты.
А сколько споров и негодований в вашей организации посвященных некачественно написаному коду?
В процессе командной работы разработчики начинают не только мыслить одинаково, но и писать одинаковый код, и даже если у вас нет единых хорошо описанных кодинг стандартов, и нет возможности их описать в виду большой загрузки, или же отсутствия иницииатора, команда сам а выработает себе такие стандарты в процессе “притирки”, и будет безпрекословно им следовать и дополнять их, ведь понапрасну спорить не хочит никто — это факт.
Новые сотрудники так же смогут быстро понять и и спользовать эти стандарты, в виду присутсвия кода с единым форматированием на всех проектах команды и старых сотрудников, активно обучающих новых, в виду нежелания переписывать чужой код.
Устойчивость к влиянию внешних факторов.
Бывало ли у вас такое, что очень срочно нужно доделать какую-то вещь, но без верстальщика это просто невозможно сделать, а его нет? Я думаю что вы понимаете это неловкое чувство, когда администратора web сервера нет на месте в самый неподходящий момент, а нужно подправить htaccess. Или же frontend программист заболел, после неотдебаженного обновления приложения.
Так вот, если использовать подход кроссфункциональной команды — то вышеописанные ситуации не смогут остановить процесс разработки и поддержки приложения, а лишь немного его замедлят. Ведь в замкнутом обществе, кторым является команда, сотрудники более активно делятся своими знаниями и опытом, развивая каждого члена команды в сфере своей специализации. В итоге, через некоторое время мы получаем команду, в которой каждый из сотрудников может выполнять разные роли, и при необходимости заменять заболевшего или отсутствующего колегу. Таким образом вопросы о выделении frontend разработчика или верстальщика отпадают сами по себе.
Необходимо упомянуть о том, что кросфункциональная команда с легкостью справляется с несколькими проектами одновременно, и при достаточном количестве сотрудников легко разрабатывает и поддерживает до пяти проектов. Это взято из личного опыта, и вы можете это проверить, если хотите.
Централизованность управления.
Следить за достижениями и недостатками в работе сотрудника не сложно, пока таких сотрудников менее десяти, но когда их становится больше — нередки случаи того, что “подвиг на работе” или “явное послабление желания работать” остануться не замеченными. И чем больше штат компании — тем больше незамеченных людей. Это факт.
Но если перенести уровень ответственности с каждого сотрудника на командный — то именно команда будет тем стимулятором, который не даст сотруднику роасслабиться. И куда проще увидеть достижения и недостатки среди нескольких команд, чем среди нескольких десятков сотрудников.
Таким образом разделив много сотрудников на несколько команд — работа руководства становится менее трудоемкой а сложный процесс поощрения и наказания — значительно упрощается.
Выводы.
В нашем стремительно развивающемся мире побеждают те, кто более организован внутри и гибок снаружи, поэтому я считаю, что не стоит брезговать теми средствами, которые делают организуцию еще более организованной и внедрять командную работу на уровне рядовых сотрудников. Данный пост не явлется руководством по внедрению комманд, а лишь мои размышления о коммандной работе, поэтому не судите строго.
На последок хочу порекоммендовать одно замечательное видео о преимуществе коллективизма:
Пробуйте, требуйте двигайтесь и достигайте!
Автор: sirko_el
