Что у вас за CMS такая, которую должны программисты настраивать? Установить, настроить так чтобы она сама по себе функционировала — да. Но какие модули где выводить — должен быть четкий, простой дружелюбный функционал, специально для контент-менеджеров. Задача программиста — сделать продукт под ключ, а не менять код каждый раз, когда требуется на главной выводить не две новости, а три. Такая настройка просто должна быть предусмотрена в административной панели.

А на моем опыте общения с менеджерами — такой подход как у вас стандартен. И нее верен. =) Программист пишет код. И реализует задачи. Проще говоря в описанном мною выше модуле реализует функционал. Контент менеджер должен уметь настроить структуру сайта, должен уметь забить туда контент, должен уметь даже настроить шаблоны отображения… Это все в случае нормальной полностью настраиваемой cms. А дальше как я и писал два варианта. Либо нетривиальный для этой cms функционал(на память… ну например — серьезное ограничение по функциональности для определенной группы пользователей. Хотя это тоже в рамках хорошей cms настраиваемо.). Программист дорабатывает функционал. И для доработки и внедрения фич ваше ТЗ описанное выше не подходит. Я об этом и пишу… Что либо вы не понимаете функциональных обязанностей программиста либо делаете исключительно тривиальные проекты и ваш программист выполняет по факту работу контент менеджера(во что я как и писал выше — не верю. Нетривиальщина присутствует в любом проекте).

И на тему сайтов региональных компания и прочих корпоративных порталов… Я такие делал. Реализовывать их на «внутренней cms» — мучение. Особенно когда менеджер не понимает что не малая часть функционала — дорабатывается программистом. Именно функционала. А хороших абстрактных и полностью кустомизируемых «внутренних cms» я не видел. И вряд ли увижу потому что это слишком серьезная инвестиция для «студии средней руки».

Я не скажу что в каждом проекте присутствует сложный функционал… Но скажем так. До 40 тыр(по питерским ценам прошлого года) — реализуемо в рамках имеющегося(я внутреннюю cms тогда писал сам.), от 40 до 80 — стопроцентно присутсвуе сложностей которые придется дописывать. Тут ваше ТЗ не подойдет. От 80 — эффективнее покупать коммерческую CMS. Вопрос с какой категорие вы работаете в первую очередь. В каждой из них есть «корпоративные сайты».

Это до того момента, пока ваша организация и клиент не подпишутся под данным документом.

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

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

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