Привет, сейчас я расскажу тебе, что будет с перспективным проектом, если с самого начала обратиться к готовым решениям а-ля Wordpress, Open Cart и любым CMS, думая, что это и есть MVP. Основываться буду на трёхмесячном опыте работы на одном из проектов, в GitHub которого за предыдущие 8 месяцев так и не упало ни одного коммита в production ветку.

Рецепт раздутого ВП/OC/CMS до геостационарной орбиты

1. Выбираем любую готовую CMS

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

2. Запрещайте документировать что бы то ни было

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

3. Зовите ГУРУ!

После того, как фиксы конфликтов между 234 и 417 плагином стали занимать хотя бы в 10 раз больше времени, чем внедрение новых функций, ваш верный путь — искать ГУРУ, умудрённого опытом, который без особых усилий за неделю отрефакторит (перепишет) немножко кода, и очередные 500 плагинов займут законное место. К слову, мне и «посчастливилось» побывать в роли гуру, который вертит технологиями, а потому это реальная история болезни.

4. Ваш проект должен состоять из одной зоны ответственности

На микросервисы мы благополучно и осознанно положили с самого начала, и через 5 месяцев пора нанять нового программиста. И пусть он будет отвечать за вёрстку. Ну и ещё чуть-чуть за backend, ведь они у нас перемешаны. Ну и за базы данных, ведь как отвечать за backend без баз данных. Ну и за фиксы пусть ещё отвечает. И ещё… и ещё… и ещё…

5. Trello + Jira + Slack + Excel +… + Skype

Благодаря добрым полутора тысячам плагинов, которые УЖЕ есть, примерно каждый день находится по 5 ошибок, разрешение которых требует по 2 дня. Скорость написания фич падает в геометрической прогрессии. Очевидно, что нас кидают на время разрабы. И нужно ввести третий менеджер задач. (Да, клинические проекты обычно имеют от двух менеджеров задач). Trello, Jira и Excel — это лишь фундамент контроля. Некоторые мастера пользуются ещё и внутри-корпоративными task менеджерами, закреплёнными сообщениями в чатах и внеплановыми внезапными указаниями.

6. Стенограммы голосовых конференций

Разрабы водят нас за нос, а потому все голосовые конференции по согласованию багфиксов необходимо архивировать, сохранять на облако и регулярно переслушивать. Ведь дело всегда в разрабах…

Совет 1: Тестирование прошло успешно — срочно выбрасывай готовые решения и пиши подходящую архитектуру.

Совет 2: Если ты не просто замотивированный стартапер и имеешь либо ресурсы, либо финансовую стратегию, то обязательно включай в неё именно написание с нуля. Да и вообще отдай это дело профессионалам или техническому директору. (Важно, чтобы это был программист, а не профессор из НИИ, иначе перфокарт не оберёшься)

Что делать, если УЖЕ и ты главный?
– Переписывать.

Что делать, если УЖЕ и ты не главный?
– Объяснить суть проблемы руководству и переписывать.

P.S. В проекте использовался Yii2, но даже с ним были эти проблемы. Что происходит с WP – это катастрофа вовсе.

P.P.S. Причина, конечно же, в некомпетентности менеджмента, хотя монолитная архитектура также не стоит в стороне.