В заметке CMS для разработчиков я пообещал, что рассмотрю более подробно выбор CMS для подхода «Инструменты для удобства разработки». Пока я обдумывал, что написать по этому вопросу, пришел к выводу, что не смогу вести разговор без единого понятийного аппарата, иными словами без «системы координат». Кроме того, вопрос показался мне слишком сложным для одной заметки.
Продолжая эти мысль, я решил не писать сразу о выборе такого многопланового инструмента, как CMS, а остановиться, для начала, на конкретных компонентах. Сегодня таким компонентом станет шаблонная система.

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

PHP, как шаблонная система

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

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

Такого метода придерживаются многие популярные CMS системы — WordPress, 1C-Bitrix, NetCat (частично) и другие.

Что в этом методе хорошего?

• Не надо обучать разработчиков отдельно шаблонной системе. Они уже знают php и смогут быстро включится в проект.
• Разработчик всегда может найти в коде конкретную переменную или функцию и посмотреть откуда она берется или что делает.
• Это быстрее работает, т.к. нет лишнего звена между интерпретатором языка и шаблоном.

Что тут не так?

• Велик соблазн вставить кусок логики в шаблон. Такие действия не пресекаются на уровне системы.
• Больше мусора. Как минимум открывающий и закрывающий теги его создают.
• Вывод в шаблон привязан к особенностям системы. Если мы поменяем функцию, то нам придется менять её и в шаблоне. Мы открываем свой «внутренний мир» тому, кто привязывает шаблон к бекэнду.
• Если ошибка произойдет прямо в шаблоне то нам сложно будет её найти и разобрать. Это связано с тем, что часть страницы на тот момент уже выведется и мы можем на понять, что ошибка произошла перед каким-нибудь закрывающим тегом из-за чего у нас полная каша.

Отдельная шаблонная система

По моему опыту, все же хорошо, когда есть отдельная шаблонная система. Основная идея тут простая. Разработчики заранее договариваются, какими метками в HTML-верстке обозначить места для вывода той или иной информации. Эта договоренность может быть разовая для конкретного случая, или общая для всего проекта (а в идеале и для всех последующих проектов, но это утопия). Метки могут быть самыми разными от маркеров вида:

%title%

до блоков типа:

{foreach from=$myArray item=foo}
{$foo}
{/foreach}

При определенном идет таких договоренностей верстальщик может сразу сделать из HTML-верстки нужный шаблон для внедрения. Ну или по крайней мере подготовить его к этому. Это экономически целесообразно, хотя на практике целиком такое получается крайне редко. Такого подхода придерживатся: Umi.cms , Drupal(опционально), Symfony framework и многие другие проекты.

Что в этом методе хорошего?

• Пропадает необходимость контролировать разработчиков по разделению логики представления от бизнес-логики. Используя «шаблонизатор» мы точно уверены, что никакая часть бизнес-логики не «просочится» в шаблон.
• Шаблон в итоге выглядит чище. Это не абсолютное правило, но тенденция.
• Мы можем разделить права. К примеру дать кому-то права изменять только шаблоны и мы будем уверены, что он не «докопается» до базы данных, например.

Что тут не так?

• Меньше скорость работы. Однако, при использовании кеширования этот минут сходит на нет.
• Требует отдельного изучения. Правда, как правило, структура шаблона достаточно простая для понимания разработчиками.

Вывод

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

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

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

Начинаем работу

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

1. У каждого товара может быть мало (3-4) или много (10-15) различных характеристик.
2. Характеристики почти полностью повторяются внутри группы товаров. То есть, если у одного “метиза” есть диаметр, длинна и шаг резьбы, то у другого, скорее всего, то же. Группа верхнего уровня может включать или не включать эти характеристики.
3. У разных групп товаров свойства могут быть совсем разные. Однако, часто можно выделить блоки характеристик. Такие блоки полностью повторяются у одних групп товаров и отсутствуют у других. Большинство блоков “наследуются” в дочерних группах, но иногда появляются только в конечной группе. Например блок, который можно назвать “размеры” (ширина, высота, длинна) есть и у москитных сеток и у дюбелей, но совершенно не важен для монтажной пены или клея.

С другой стороны

Одновременно с работой проектировщика, свою работу над характеристиками начала дизайнер проекта. Она изучила множество отечественных и зарубежных интернет магазинов, а так же ассортимент нашего заказчика. Выяснила, что пользователю, как правило, удобно выбирать из представленных вариантов (белый, черный или коричневый цвет), либо указывать диапазон значений (цена от 100 до 300 рублей). Другие варианты подбора по параметрам в этой отрасли встречаются реже. Из этого понимания появился дизайн-макет фильтров на странице группы товаров.
Заказчик согласует дизайн-макет и таким образом “бетонирует” решения дизайнера. Дальше от них отступать нельзя.

Пишем ТЗ

С оглядкой на дизайн-макет, проектировщик принимается, за написания технического задания. Ему нужно понять, в каком виде можно хранить информацию. “Любое свойство продукта состоит из пары ключ-значение.” – решает проектировщик, для начала. Название у характеристики есть всегда, а вот со значением несколько хитрее.
По некоторым характеристикам нужно сделать возможность выбора диапазона – от максимального значения, до минимального. Такие свойства нужно явно задать числовыми, иначе мы не сможем проводить с ними математические операции, если пользователь введет что-то не числовое. Программисты попросили так же для увеличения производительности поделить числовые свойства на целые числа и дробные. А еще стало очевидно, что у числовых свойств будут еще единицы измерения. Так появились первые два типа характеристик.
Потом проектировщик стал обдумывать фильтры по таким свойствам, как цвет или тип крепления. Понятно, что можно дать администратору сайта вводить эти значения вручную, а пользователю потом предлагать выбрать из многих вариантов. Проектировщик уже имел опыт с таким решением и знал, что в этом случае скорее всего появятся такие варианты, как “Белый”, “белый‘, ‘светлый’, ‘белесый’, ‘white’. Все они, возможно, различаются для заполняющих сайт. но никак не различаются для пользователя. По этому нужно администратора ограничить. Пусть главный администратор вводит варианты цветов, а все остальные только выбирают из предложенного. Так мы избежим этой путаницы. Программисты так же отметили, что это целых два типа характеристик описано: в первом у товара есть только один вариант у списка(цвет только один), а во втором может быть несколько вариантов одновременно (сразу несколько вариантов креплений).
Изучая другие магазины подобной тематики, проектировщик отметил, что есть свойства, у которых может быть только два значения: есть или нету. эти свойства он вынес в отдельный тип.
Ну а все характеристики, которые нельзя будет отнести к этим типам оставим в виде текстового названия и текстового значения.

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

Смотрим со всех сторон

Начнем оценку нашего решения со стороны разработчика. Давайте представим, что мы приступили к написанию поиска по характеристикам. Тут то и становится понятно, что всего в проекте предполагаются десятки тысяч характеристик и десятки тысяч товаров. А это значит, что при поиске по одной характеристики серверу предстоит обработать около ста миллионов операций сравнения. Кроме того, стоит учитывать, что пользователь может задать одновременно фильтр по многим характеристикам. А пользователей, надеемся, будет много. Выдержит ли сервер такие нагрузки? Предварительное нагрузочное тестирование показывает, что нет.
Зовем программистов на совет. Цель: не меняя дизайн макет и внешнюю структуру сайта что-то придумать с производительностью. Вместе они еще раз открывают список, составленный проектировщиком в самом начале и решают, что каждую характеристику можно отнести не ко всему интернет-магазину сразу, а только к конкретной группе товаров. Таким образом количество характеристик уменьшится до сотен и товары, среди которых стоит искать так же ограничатся одной группой, то есть то же порядок ‘сотни’. Так мы снизим количество операций с сотен миллионов до десятков тысяч. Правда, при таком решении предполагаемый срок разработки увеличился до 40 часов.

Теперь давайте посмотрим на наш план глазами администратора сайта. Руководитель проекта шутит, что через месяц заполнения сайта администратор придет к нам в офис с бейсбольной битой. ‘Почему? Да потому, что администратор сайта чекнется вносить длину, ширину и высоту, для нескольких десятков групп товаров. А цвет и бренд для всех почти.’ – говорит он. ‘И это еще пол беды. Допустим, есть две похожие группы ‘метизы’ и ‘дюбели’, в обеих есть длинна. Клиент хочет подобрать и то и другое под диаметр. Получается, вы его заставите сначала в одной группе фильтры забивать, потом в другой. Как ваша интеллектуальная система длину оттуда с длинной отсюда сопоставлять будет? ’.
Мысль здравая. После тщательного обдумывания всех нюансов, принято решение разбить характеристики на блоки. А потом добавить возможность прикреплять эти блоки к разным группам товаров. Важно так же учесть, что у одной группы может быть любое число таких блоков. Оценка работ увеличилась до 60 часов.

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

Новые фичи

Проект стартует и разработка идет своим чередом. На очередном совещании по сделанному, руководитель проекта предлагает добавить к текущему этапу выгрузку из складского учета (1с) заказчика. По тому, что иначе очень трудно будет понять какие функции сайта на реальных данных как себя ведут. Сроки на этот момент мы немного опережали и очень хотели порадовать заказчика дополнительным функционалом, который не должен был входить в этот этап.
Предполагается, что будут выгружены только структура групп товаров, названия товаров и их цена. Это предположение было предварительно согласовано с заказчикам еще до написания подробной документации. После чего, у заказчика запрашивается выгрузка всех его текущих товаров. Тут надо отметить, что в нам повезло: быстро удалось найти общий язык со специалистами 1с со стороны заказчика.

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

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

И что будем делать?

Что ж, проект все равно делать надо. Проектировщик вместе с программистами придумывают «интеллектуальный» алгоритм, который пытается сам определить тип характеристики. Так же сам пытается отделить значение от единицы измерения или записать варианты значений. Реализация такого алгоритма увеличивает оценку до 100 часов.
Такое увеличение уже не взять на себя без потерь качества или диких срывов сроков и руководитель проекта это понимает. Теперь приходится вести переговоры с клиентом о том, что бы урезать какой-то менее важный компонент на первом этапе или увеличить общий бюджет этапа. Но это уже другая история.

Вместо итога

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

1. Всегда прежде чем называть сроки/стоимости клиенту возьмите паузу и еще раз взгляните на компоненты проекты со всех точек зрения. В нашем случае, это сторона программистов, сторона администратора сайта, сторона конечного пользователя-покупателя и сторона бизнеса, конечно. Не сделав этого, мы могли ошибиться в 4 раза.
2. При ведении переговоров с клиентами старайтесь охватить все аспекты. Конечно, что-то учесть не удастся, но чем четче были обозначены ранее принятые решения, тем проще будет договариваться дальше.
3. Старайтесь составить четкий чек лист, что бы клиент мог в любой момент видеть входит в данный этап, что что в последующие. В этом проекте мы этого не сделали и еще больше запутали клиента, когда брали на себя дополнительные обязательства по этапу. В дальнейшем постараемся прописывать и проговаривать все более четко.

В прошлой своей заметке я обещал, что отдельно остановлюсь о выборе CMS системы с точки зрения разаботчика. Эта тема очень объемна и сегодня я хочу поговорить о подходах к выбору инструментов разработки. Разработчиком я буду называть человека или группу людей, которые «на входе» получают ТЗ, а «на выход» отдают сайт. Далеко не всегда это программисты. Об этом далее.

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

Ищем инструмент под задачу

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

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

Часто этот подход выбирают исходя из команды разработчиков. Например, для того что бы завести блог на Эгее не нужно быть программистом. Для того, что бы развернуть WordPress, выбрать тему и прикрутить пару плагинов достаточно посвятить изучению этого процесса неделю, но нет необходимости 5 лет учится на мехмате, а потом 10 лет работать в закрытом НИИ. Для того, что бы сделать презентационный одностраничник на Тильде не надо учить С++ за 21 день.

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

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

С этим подходом, правда очень легко попасть в ловушку. Например, согласно Российской бизнес-газете в год в рунете открываются несколько тысяч интернет-магазинов. Отсюда можно сделать вывод, что задача создания интернет-магазина типовая, а значит к ней хорошо применим ход рассуждений «Ищем инструмент под задачу». Такой вывод — огромная ошибка, которую допускают постоянно. Это связано с тем, что в отличае от блога, сценариев взаимодействия авторов и читателей с котором не так уж и много, в интернет-магазине таких сценариев тысячи, хоть так и не кажется на первый взгляд. Я участвовал в разработке около 20 интернет-магазинов (насчитал сейчас 16, но мог что-то упустить. Честно говоря, далеко не везде я был «на главных ролях», так что может кто-то скажет, что и лишку посчитал) и ни разу логика расчета цен не повторилась точь-в-точь. Даже в очень похожих друг на друга по ассортименту и бизнес-модели магазинах находилась разница. А это всего один из десятков или сотен компонент.

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

Инструменты для удобства разработки

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

Эта мысль настолько важна, для понимания разницы между подходами, что я переформулирую её еще раз. Разработка при таком подходе стоит дешевле, но при этом нет заранее готовых компонент. Это значит, что все, что можно было бы этими компонентами собрать будет оплачено заказчиком, в отличие от первого подхода. Но, зато все, что «сверху» готового материала, будет стоит дешевле и разрабатываться быстрее.

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

Третий подход?

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

Чем больше готовых компонент, тем меньше возможностей для их изменения. Это «закон природы», от которого не убежать. Понятно, что можно достичь некоторого равновесия, например 30% первого подхода и 70% второго. Проблема в том, что это только откладывает выбор того или иного подхода. Это временное перемирие, но не завершение войны.

Я не против такого микса, но только в том случае, если все участники процесса четко понимают, что для одних компонент выбран подход «Ищем инструмент под задачу», а для других «Инструменты для удобства разработки» и нет никакого третьего варианта.

Итог

Выбор CMS для первого подхода — задача рутинная. А вот для второго и для синтетического варианта — не тривиальная. Я постараюсь высказать свои мысли о её решении в одной из следующих заметок.

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

Часто я слышу от клиентов такие слова, как «движок», «ядро», «Цеэмэска». Как правило под всем этим подразумевается некая web-система, которую можно поставить платно либо бесплатно и которая уже сделала за программиста половину его работы. Обратите внимание, для многих клиентов сайт делает программист. На самом деле, конечно в процессе создания сайт может участвовать множество людей, часть из которых — разработчики. Это дизайнеры, верстальщики, фронт- и бекенд программисты и все, кто создает сайт и хочет называть себя разработчиком. Такое понимание, конечно же, в корне не верное.

Начну с того, что тут не так. С точки зрения разработчика, как я уже отмечал, CMS система — одна из компонент проекта. При этом, далеко не всегда это «основа». «Ядром», или лучше сказать основной разработки, может послужить фраемворк, может совокупность отдельных готовых модулей. Это может быть даже одна отдельно взятая библиотека или же такой основы может вовсе не быть. Все это должно волновать заказчика в последнюю очередь, так же, как и стул, на котором сидит дизайнер или текстовый редактор, которым пользуется менеджер проекта. Все это — внутренние вопросы, которые помогают или мешают исполнителям решать проблему заказчика.

Так почему же заказчики часто настаивают на использовании готовых многофункциональных CMS систем? Существует несколько причин. Разберу основные.

Экономия

Вполне логично предположить, что если разработчики будут пользоваться готовыми компонентами, то работы окажется меньше, а следовательно стоить она будет дешевле. Тут есть здравое зерно. Однако, первое, что стоит понимать, что это, возможно, экономия для разработчиков, но не для клиента. Цена проекта будет такой, на которую вы договоритесь и никакие внутренние процессы на нее не повлияют. Ни разу не слышал, что бы клиент предлагал разработчику перейти на выбранную им CMS и цена сайт падала, скорее в жизни бывает наоборот. Если разработчики смогли где-то сэкономить, то это их личная победа, так же, как и обратная ситуация — если у разработчиков внутри ваших договоренностей что-то пошло не так, то это не должно лечь на плечи клиента. По крайней мере и то и другое — предмет переговоров, но никак не снижение/повышение цены автоматом.
Тут есть и второй момент. Заключается он в том, что упросить ли использование каких-то готовых компонент разработку зависит от конкретных разработчиков и от конкретного проекта. Любой профессиональный веб разработчик способен, в итоге, разобраться в любом чужом компоненте, но сколько уйдет на это времени и как конкретно он поможет проекту вопрос сложный и всегда открытый.

Страх выбора плохого разработчика

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

Опыт работы

Часто заказчики говорят, что уже имели дело с сайтами на какой-то CMS системе и, так как их все устраивает, не хотели бы её менять. Пожалуй, это самая существенная причина из всего списка. Конечно, если имеется ввиду, что со стороны клиента есть штат людей, обученных администрировать сайты на какой-то платформе. В этом пункте замечу только, что обычно даже у очень сложных сайтов механизмы администрирования достаточно просты и люди переучиваются за 2-3 дня. Ну, конечно, исключая какие-то особые случаи.

Функциональность будущего сайта

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

Откуда ноги ростут

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

P.S. Для тех, кто не знает о ком я, посмотрите рейтинг CMS рунета. На картинке рейтинг платных CMS по версии iTrack.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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