Владимир Корниенко

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

Важный момент: "тратить на ФОТ меньше чем он реально того требует" - такая себе оптимизация бизнес-процессов. Это как заложить на аренду офиса 2000р когда она стоит 5000. от того что вы на бумаге выделили 2000 потому что "бюджета больше нет" - его вам автоматически за эту цену не сдадут.

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

Для разных языков существуют свои стандарты. Просто гуглите что-то вроде {language} style guides. Например для php это будут PSR, для js например гайд от airbnb или ideomatic.js.

Когда вы пользуетесь общепринятыми стандартами написания кода, все проще. В линтерах эти style guides априори уже есть. Внутри команды вы просто договариваетесь, каким будете следовать. Если хотите использовать что-то свое - расшариваете для членов команды кастомные конфиги.

Как называется такой документ? Наверное Code Style Guide. Возможно вы говорите о статье https://www.pullrequest.com/blog/create-a-programm...
Там же есть синонимы: coding guidelines, coding standards, or coding conventions.

Кто контролирует? Хорошо, если есть несколько уровней проверки кода:

• уровень разработчика - с помощью линтера в среде разработки кода
  
• уровень тимлида/старшего разработчика - в ходе выполнения кодревью
  
• уровень хендлеров в системе контроля версий - при выполнении push или merge (не прошло - получаем отказ)
  

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

НО!

Если у вас есть в команде какие-то боли то их надо решать. Надо определись больные места, найти причину этих болей (Five whys) и лечить это.

Вот как лечить - зависит от проблемы, условий и команды

Уже не первый год использую Trello именно с таким составом участников, как вы написали.

notion.so не "очень сложный", а просто не тудулист
так и Трелло и MS Project можно туду листами считать )

лучше RTM ничего нет (некоторым зашел Wunderlist), хотя загадка есть - почему ее не развивают,ответ, скорее всего - и так все есть, всего достаточно

в заметки хорошим тоном считается вставка ссылки на док с подробностями - ГуглДокс, Трелло, нотион со )))
а в туду листе ничего кроме текста и не нужно

т.е. Вы сами все нашли и юзаете что нужно