Самописаные CMS — или студийные, как их еще называют — вселенское зло. Объективно, не может компания-разрабочик сайтов с тремя программистами сделать качественную CMS. Не может! Почему?

Причина 0

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

Причина 1

Наплевательское отношение к безопасности. Во главу угла ставится работоспособный код. Код работает — отлично, идем дальше. Никто не задумывается, что код дырявый. Дырявый на столько, что даже пользователь это видит: залогинился на десктопе, и автоматом залогиненый на телефоне.

Причина 2

Медленное внедрение новых фич. Отказ от внедрения новых возможностей. Отмазка — это не надо пользователям, это и нет так уж и важно.

Причина 3

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

Причина 4

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

Причина 5

Нет внятной лицензии на объект интеллектуальной собственности. Юридически нет прав на CMS, либо права так зажаты, что нельзя дорабатывать сайт на этой CMS.

Многие менеджеры проектов скажут вам, что разработчик-перфекционист это очень плохо. Действительно, разработка ПО (особенно заказного) — это коммерческая деятельность. Она должна быть рентабельной. Поэтому негласно действует правило — доводим разработку до 80% готовности. Пилить дальше — это дорого, а часто и невозможно. Ошибки все не исправишь. Есть даже термин — showstoppers — ошибки, которые препятствуют выходу релиза. Например, если вы разрабатываете браузер и он зависает каждые 10 минут — это showstopper. Эксплуатация браузера невозможна. А вот если браузер не умеет распечатать страницу сайта — это не шоустоппер, ведь страницы печатают далеко не все пользователи.

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

Поэтому грамотный project manager заботится выполнить каждую фичу программы на «чуть более 80% готовности», убрать ошибки-шоустопперы и выкатить новую версию. Затем собрать жалобы пользователей и исправить еще одну порцию ошибок. Грамотный проджект-менеджер стучит линейкой по рукам перфекционистов, когда они слишком закапываются в код.

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

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

Дизайнер была перфекционисткой. Заядлой и фанатичной. Она посмотрела на макет и сказала: «Да, эта идея мне нравится, она классная и решает множество проблем с дизайном. Я сегодня ночью перерисую его полностью».

Утром был новый дизайн. Я был счастлив. Перфекционизм дизайнера сыграл мне на руку. Она сделал эти правки в силу своего характера — во внерабочее время и без дополнительной оплаты. Тогда-то я и полюбил перфекционистов. Главное уметь направить их в нужное русло.

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

Вторая ошибка — мы взяли слишком мало денег. Мы позарились, что сможем быстро собрать апликейшен с имеющимся дизайном. В итоге оказалось, что проект надо было оценивать в минимум 4 раза больше. Зафиксировали колоссальный убыток. :(

За время выполнения проекта сменили три команды разработчиков. Только с четвертой удалось довести проект до конца.

Но я в целом доволен данной ситуацией. Самое главное решение, которое я принял и которым горжусь — отказаться от дизайна клиента и разработать его самим. Это дало невероятный буст проекту и мы смогли его завершить за 3 месяца от начала и до конца.

Самое главное, что клиент невероятно доволен. Он уже две неделе пишет мне в скайп, как круто работает его приложение и благодарит программиста.

Когда я смотрю на эту картину, у меня слезы на глаза наворачиваются.

Это простой сайт каталога продукции. Категории, карточки товара, кнопка купить. Вот зачем разработчик подключил столько скриптов и внешних шрифтов? Как он вообще смог создать css на 360 килобайт? В итоге страница, контент которой занимает от силы 500 килобайт, «весит» 2.6 мегабайта.

Ужас и мрак.