Как стать автором
Обновить
105.3
Productivity Inside
Для старательного нет ничего невозможного

Расширение команды не всегда ведет к росту производительности

Время на прочтение 3 мин
Количество просмотров 2.8K
Автор оригинала: Elye
Когда появляется желание ускорить процесс разработки, первое, что приходит в голову – надо нанять больше людей. Допустим, в данный момент у нас над проектом работает один разработчик. Пусть теперь их станет двое.



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

Если нас в первую очередь интересует качество, можно организовать сеансы парного программирования, что позволит усовершенствовать код. Тогда объем кода не возрастет в той же мере, но мы всё-таки получим выгоду от пополнения в команде в виде более качественного итогового продукта.

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



С появлением третьего и четвёртого разработчиков мы по-прежнему наблюдаем прирост в производительности, однако в процентном отношении эффект уже не так велик, как было со вторым. Почему?

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

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

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



Как видите, чем больше сотрудников мы вводим, тем более сложной и разветвлённой становится система коммуникации. Всем нужно взаимодействовать со всеми.

В математическом выражении число направлений коммуникации возрастает по схеме, показанной на графике ниже.



2 человека = 1 x 2 = 2 связи
3 человека = 3 x 2 = 6 связей
4 человека = 6 x 2 = 12 связей
5 человек = 10 x 2 = 20 связей
6 человек = 15 x 2 = 30 связей
7 человек = 21 x 2 = 42 связей
8 человек = 28 x 2 = 56 связей


Издержки, связанные с коммуникацией, начинают тормозить процесс разработки.
  • Ресурс времени на написание кода сокращается, по мере того как возрастают временные затраты на собрания, обсуждения и планирование. Синхронизация обходится команде всё дороже и дороже.
  • Так как все работают на одном и том же проекте, люди всё чаще непредумышленно наступают друг другу на ноги.

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

Масштабирование не сводится к умножению числа разработчиков


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

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

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

На графике ниже эта схема представлена яснее.



В математическом выражении мы свели число связей к гораздо меньшему значению: вместо 56 связей теперь насчитывается 26. Сокращение более чем в два раза!

(Группа1) + (Группа2) + (Коммуникация между группами) => 12 связей + 12 связей + 2 связи = 26 связей

Это дает нам много преимуществ:
  • Требуется меньше синхронизации – теперь всем не нужно быть в курсе всего. Значит, больше времени можно тратить на написание кода.
  • Объем информации, с которым приходится работать каждому из разработчиков, уменьшается, и это упрощает им жизнь.
  • Из-за разделения ответственности по модулям, снижается риск того, что кто-то вторгнется на чужую территорию.

Если вкратце


Масштабирование проектов по созданию ПО – это не только бесконечный наем сотрудников. Необходима более тщательная предварительная подготовка к расширению, в частности, создание подходящей для роста структуры команды. Соответственно, разделение на модули представляет собой крайне важную составляющую масштабирования. Хотя сама идея, конечно, не нова – она применяется даже при делении клетки у живых организмов.
Теги:
Хабы:
+2
Комментарии 5
Комментарии Комментарии 5

Публикации

Информация

Сайт
productivityinside.com
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия