В общем случае на этот вопрос, конечно же, ответа нет. Понятно, что под «делают сайт», можно подразумевать все, что угодно. Гугл, например, то же сайт. В крупных интернет-изданиях трудятся десятки, а иногда и сотни человек. Так что тему этой заметки я сужу так «какое оптимальное число человек должна работать в веб-студии над одним проектом?» Предположим, что существует некий заказчик, который берет на себя все вопросы, кроме непосредственно связанных с разработкой сайта. Допустим так же, что мы рассматриваем случай именно разработки сайта с самого начала и до запуска проекта. Так же оговоримся, что мы рассматриваем только «производственную часть», без различных менеджеров, переговорщиков и директоров. Все эти люди, безусловно, очень важны для проекта, но сегодня мне интересно порассуждать именно о технической стороне вопроса.

Что еще за проект?

С этими ограничениями строить какие-то предположения уже гораздо проще. Но все же, я ничего не сказал о масштабе проекта. А это ключевой вопрос, как кажется на первый взгляд. Давайте оговоримся, что проект, о котором мы говорим достаточно большой и сложный, так что бы не существовало готовых компонент, способных заменить бОльшую часть проекта в совокупности. Ну то есть отбросим те проекты, для которых половину функционала берет на себя какая-нибудь CMS «из коробки».

Итак, есть абстрактный «крупный проект». Сколько оптимально выделить людей для его осуществления? Еще раз оговорюсь, что рассматриваю абстрактный случай, в котором есть четкое ТЗ и оно не изменно от начала и до конца работ. Да, я знаю, что такого не бывает. Но, если все-же представить себе этот случай, то, скорее всего, такое ТЗ будет включать в себя уже разработаенный и тщательно продуманный дизайн. Так что говорить мы будем только о разработчиках.

Математический метод

Пойдем математическим путем. Мы точно знаем, что 0 разработчиков сделать сайт не могут и их эффективность ровно ноль. Так же мы точно знаем, что бесконечное число разработчиков будет искать способы взаимодействия бесконечно долго и иметь бесконечно малую ответственность, так что их эффективность то же нулевая. Учитывая тот факт, что сайты все же существуют мы можем сказать, что есть некое число разработчиков, эфективность которых отлична от 0. Из курса матанлиза нам известна теорема Ролля, согласно которой при таких условиях существует некое оптимальное число разработчиков, эффективность которых максимальна. Попробуем это число найти.

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

Упрощенная модель

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

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

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

Эта модель, конечно не учитывает, например деление компетенций на фронтэнд и бекэнд. Но в целом мы можем поделить проект на две части и к каждой применить такой вариант.
А вот что не учтено и существенно, так этот тот факт, что разработчикам нужно взаимодействовать друг с другом. В отсутствии тим-лида и системы контроля версий каждый разработчик должен взаимодействовать с каждым, а значит, расходы на взаимодествие растут квадратично. В хорошей же веб-студии время на взаимодействие растет линейно. Как это учесть? Попробуем построть графики с одним и двумя разработчиками. Вспомним, что один разработчик должен быть выше, чем максимальная сложность проекта, иначе он не доведет его до конца. (Затраты — площадь под зеленым графиком. Можно листать.)

Столбиком на границе разработчиков я обозначил затраты на взаимоействие. Извиняюсь, за кривые графики, но надеюсь всем видно, что два разработчика – оптимально. При трех величина «слолбиков» взаимодействия будет больше чем профит. Конечно, это все верно для нарисованного мной проекта и моих данных. Однако, если форма графика неизменна, то всегда 2 или 3 разработчика оказываются оптимальным числом.

Вспомним так, же, что я предложил делить разработку на фронтенд и бекенд. Часто слабый в бекенде разработчик может так же присоединится к фронтенду. Так что идельный размер команды минимум 3 (по два на каждом графике, но один из разработчиков один и тот же человек) и максимум 6 человек.

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