Маразм в технических заданиях

[Xeon303]

Маразм в технических заданиях

Приветствую всех.

Вчера искал различный материал по CMF и случайно наткнулся на «техническое задание» на создание такой системы. На его второй строке было написано такое: «CMS – Интерфейс построения CMS», что уже не вписывается ни в какие рамки CMF. Если основа CMS – то я понимаю, а уж интерфейс – это что-то за гранью реальности.

Второй абзац в этом техническом задании еще раз подчеркивает абсолютное непонимание предметной области (сразу хочу сказать, что заявленный проект должен быть выполнен на PHP):

(Орфография и пунктуация сохранена во всех цитатах)

Разработка конструктора сущностей

Таким образом работа заключается в написании конструктора, который на базе компонентного подхода (типа выбрал объект из панели объектов, перенес на экран, определил свойства поведения и визуальные свойства) позволял бы конструировать сущности (такие как гостевые книги, магазины, каталоги и проч.), и помещать их в репозиторий сущностей. Должна быть возможность визуально задавать связи между объектами, примеры – MS Visio,ERWin, Adobe GoLive.

И как это интересно так можно сделать? Визуально задать связи, как в этих программах, можно, только если писать отдельное приложение для Windows, которое написано никак не на PHP или JavaScript.

Также должна быть возможность подключать модули, разработанные сторониими разработчиками по принципу черного ящика (добавил новую сущность типа нестандартный указал файл php с реализацией этой нестандартной сущности, файл php с реализацией модуля настройки этой сущности для cms. Кстати, должна иметься возможность, подключать нестандартные модули, написанные не только на пхп но и на других языках.

Да... не знал, что в PHP можно подключать модули на других языках. Может быть, на C# тоже можно. Вдруг разработчики PHP включили в него .NET и среду выполнения программ CLR

Предлагаю, всем самим посмотреть это «техническое задание», там еще много чего интересного.

http://weblancer.com.ua/project_files/18/1871/1871_1.doc

Добивает то, что заказчик больше не описывает проблему, которую ему нужно решить (собственно за этим и пишется тех. задание), а описывает визуальное представление, что задача уже для дизайнеров, спецов по юзабилити и других. Например, в том же тексте написано, что везде должны быть использованы значки

К чему я пишу это? Бесит полное непонимание предметной области, непонимание собственной задачи, тупое описание не сути проекта, а его деталей. Скорее всего, что человек, который примется за это задание не выполнит его или сделает не то, что хотел заказчик. В итоге, результатом такой работы будет потеря времени и средств.

Обращаюсь к заказчикам: если вы хотите, чтобы вам был изготовлен качественный проект, который удовлетворяет Ваши потребности, не пишите чушь в таких важных документах.

 

[Rammstein]

Поясняю на пальцах: заказчика мало в душе волнует какая там архитектура и т.п. Его интересует функционал, я бы даже сказал, функционал админки. В этом нет ничего странного.
На C можно модули подключать, с дот нет PHP тоже можно сдружить.
Конечно, на счёт CMF ошиблись. Тут явно CMS.
Кстати, достаточно подробное ТЗ. Бывают намного хуже

 

[Xeon303]

Это еще не самое плохое...

Да, не думал, что еще и хуже есть. То что задача разработчика понять заказчика - это одно дело, а когда заказчик сам не понимает чего он хочет и даже не мог удосужиться и оценить возможности того же PHP, веб-приложений и узнать немного про предметную область (то бишь CMF, если она ему на самом деле нужна), то такого человека, по-моему, даже специалист по сбору требований не спасет.

В любом случае, из такого проекта ничего хорошего не получится...

 

[kruglov]

Бывает, что заказчик намучался с каким-то кривым/примитивным решением и пытается его усовершенствовать, не выходя, однако же, за его пределы.

Например, у меня был клиент, у которого сайт был устроен так: картинки-прайсы закачивались через FTP в одну папку, а потом с разных страниц на них прописывались ссылки. Через некоторое время в этой папке с файлами наступил бардак, когда непонятно кто куда вставлен, что можно, что нельзя удалить, что используется на сайте, что уже нет.

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

Нами было предложено более логичное и менее запутанное решение присваивать файлы объектам (новостям, страницам, прайслистам) на уровне CMS, закачивая их кнопочкой Browse при редактировании этих объектов. Так что при вставке ссылки в первую очередь появлялся список файлов только этого объекта. С чем он и согласился потом.