Как перестать переусложнять и начать жить

#почитать

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

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

2. Концепция MVP. Аргументированно объяснить, что проекты (сервисы) живут 2 года и РПС будет 2.5, а не 2500. Указать на то, что это MVP, что важно как можно раньше выпустить приложение и понять в реальности как оно живет на проде и какой отклик от юзеров.

3. Призвать руководителя. Если у вас хорошие доверительные отношения с руководством и вы на хорошему счету - часто работает просто ему все объяснить. Указать, что в целом все проработано и оно соберется.

4. Техдолг. Иногда работает то, что можно сказать, что ничего не мешает сделать проект способным держать 5000 РПС через техдолг задачи. Дескать сейчас мы соберем рабочий вариант, уложимся в сроки, а потом уже в более спокойной обстановке сделаем супер пупер конфету. С вер-стью 99.99% эти задачи никто конечно же делать не будет и не будет не по потому что лень, а потом что они никогда не получат приоритет, так как 5000 РПС там никогда не будет.

5. Сервис живет 2 года. Любой сервис живет 2, максимум 4 года. Если проекту больше 2 лет, значит скорее всего половины кто его писал уже в команде нет, проект сильно устарел и его поддержка стоит огромных усилий. Платформы меняются, меняются либы, гайдлайны, какие-то проекты взлетают, а какие-то нет. Надо попытаться объяснить, что нет смысла пилить проекты на 100 лет.

⏱Читать статью