Позвольте, но бывает еще и третий вариант (помимо мудаковатости и нужности). Называется он умным словом «форс-мажор». Только вот этот самый форс-мажор бывает разный. В частности, случаются такие ситуации, когда форс-мажорные обстоятельства не могут быть подтверждены никакими государственными органами…
Пример из жизни:
Совсем недавно один их моих заказчиков задержал оплату очередного этапа разработки интернет-магазина на целых 3 недели. Причиной тому послужило внеплановое вторжение на территорию компании большой группы лиц в масках и с автоматами. Якобы по причине торговли контрафактными игровыми приставками и дисками…
Тем не менее, через 3 недели заказчик реабилитировался и возобновил оплату по договору. Думаю, что в подобных ситуациях совсем ни к чему названивать заказчикам с требованиями выполнения договорных сроков оплаты, считать их мудаками или сомневаться в собственной «нужности»…
Но ведь и исполнитель в этом случае ничего не получит за проделанный объем работ. А самое распространенное основание отказа от оплаты, как правило, одно – «денег, простите, нет»…
Здесь немного непонятно, с какой целью заказчик попросил удалить первый пункт. Вроде бы это совсем не в его интересах.
Что же касается добавления второго пункта – я не вижу в этом ничего предосудительного. Гарантийные обязательства обязательно должны предоставляться. Другое дело, что формулироваться все это должно несколько по-иному:
«РАЗРАБОТЧИК» обязуется безвозмездно устранять любые обнаруженные «ЗАКАЗЧИКОМ» в процессе эксплуатации веб-сайта недостатки и дефекты, если характер работ по их устранению не выходит за рамки утвержденного технического задания на разработку веб-сайта (Приложение №1). Данные гарантийные обязательства аннулируются в случае вмешательства «ЗАКАЗЧИКА» в программный код веб-сайта.
Если же проектная документация изначально не составлялась и не утверждалась – это уже проблема компании-исполнителя, но никак не заказчика…
Боюсь, что если заказчик никак не хочет платить вовремя, вряд ли можно эффективно решить эту проблему. Тема пеней уже неоднократно обсуждалась: далеко не каждого заказчика они устраивают при подписании договора. Что же касается приведенных «методов борьбы» – они, конечно, весьма оригинальны, определенно могут «браться на вооружение», но все же это не панацея. Кроме того, для солидной компании-исполнителя не всегда приемлемо «действовать заказчику на нервы» (даже если он принципиально нарушает оговоренные сроки оплаты).
На мой взгляд, необходимый минимум – это составление грамотного договора, согласно которому работа выполняется поэтапно (разработка концепции дизайна, верстка статических прототипов веб-страниц, разработка программных компонентов и модулей, информационное наполнение), причем каждый такой этап оплачивается предварительно и только после принятия заказчиком предыдущего этапа. Что касается проведения проектных работ – они вообще должны оплачиваться отдельно от стоимости разработки веб-сайта (и тоже только предварительно), поскольку результат проектирования (техническое задание) является приложением к основному договору.
Кроме того, некоторое время назад я взял на вооружение следующую «изюминку»:
В случае приостановления выполняемых по настоящему договору работ по инициативе «ЗАКАЗЧИКА» денежные средства, полученные «РАЗРАБОТЧИКОМ» за выполненные этапы работ, «ЗАКАЗЧИКУ» не возвращаются. При этом исключительные права на разработанную концепцию дизайна веб-сайта, сверстанные статические прототипы веб-страниц, а также программные компоненты и модули остаются у «РАЗРАБОТЧИКА».
Не Бог весть какое удовольствие для компании-исполнителя, но все же...)
Итак стал я все ковырять изучать и смотреть насколько предлагаемые рынком системы удовлетворяют моим потребностям.
Вашим потребностям? Не слабо.) Мне почему-то всегда казалось, что предлагаемые рынком системы должны в первую очередь удовлетворять потребностям программистов и контент-менеджеров (конечных пользователей), но никак не потребностям руководителей проектов, основной задачей которых является подбор исполнителей, контроль качества и информационная поддержка заказчика в процессе реализации проекта.
А задача то стояла простая, найти готовую систему которая бы не отнимала времени у сотрудников на создание однотипного функционала.
Смею Вас заверить, что ни одна (даже самая паршивая и кривая система) не может отнимать у сотрудников много времени на создание однотипного функционала. Условия здесь только два:
1. Этот «однотипный функционал» уже должен быть создан сотрудниками (хотя бы один раз).
2. Сотрудники являются программистами и не заканчивают при этом 5 класс общеобразовательной школы.
Например новости: заголовок, краткое содержание, подробное содержание и еще миллиард параметров. Ну нахера?
И ведь действительно, нахера? Какой заголовок? Какое нахер краткое содержание? Возьмите, например, NetCat и создайте свой собственный программный компонент с необходимым именно Вам индивидуальным набором полей. Там это делается буквально в несколько щелчков мыши. Разве это не гибкость и кастомизация, которой Вам так не хватает? Не нужен миллиард параметров? В чем проблема?)
Во всех этих системах видно главенство программистов.
И так и должно быть, поскольку подавляющее большинство современных систем построения и поддержки веб-сайтов являются ни чем иным как своеобразными платформами-фреймворками, которые создаются программистами для программистов. Что же касается конечных пользователей и руководителей проектов – их должен волновать только лишь удобный пользовательский интерфейс, позволяющий легко и непринужденно наполнять веб-сайт необходимой информацией. Но никак не кастомизация программных модулей или написание нового функционала...)
А бредовость отдельных модулей вообще поражает, например: каталог ссылок. Что это и нахера?
Это – каталог ссылок. Весьма полезная вещь в определенных ситуациях. Если же Вам не нравится какой-то стандартный модуль – удалите его и поставьте задачу программистам, чтобы они написали другой, свой, который не будет Вам казаться бредовым. Один раз и навсегда.
А эти ужасные WYSIWYG
Эта проблема, по правде говоря, к CMS имеет отношение весьма и весьма косвенное. Другими словами, наплодить говнокод/говноконтент можно и не прибегая к помощи CMS и WYSIWYG-редакторов. Тут все дело в сложившихся стереотипах и традициях, которые имеют много исторических причин возникновения. Бороться с этим злом определенно стоит, но только не посредством громких заявлений о том, что все российские коммерческие CMS – «говно редкостное»…
Идеальных систем не бывает. Основная на то причина – коллективный труд. Когда систему разрабатывает не один человек, а команда разработчиков (а в некоторых случаях по-другому и быть не может), каждый участник старается привнести в код что-то свое – неповторимое и мегаоригинальное с его точки зрения.
Тем не менее, по моему скромному мнению, NetCat CMS – очень даже неплохая платформа. По крайней мере она имеет весьма развитый и удобный API, предоставляет полный контроль над HTML-шаблонами, не «поганит» HTML-разметку и позволяет разрабатывать безупречные синтаксически и семантически корректные интернет-ресурсы, соответствующие всем современным веб-стандартам.
На мой взгляд, единственная серьезная проблема программного комплекса NetCat – отсутствие поддержки UTF-8.
На мой взгляд весь сыр-бор по большей части происходит из-за того, что все свалено в одну кучу...
Блочная верстка – это совсем не обязательно XHTML.
Сравнивать, наверное, нужно было по отдельности следующее:
1. Табличная верстка vs Блочная верстка (не важно – HTML или XHTML).
2. HTML vs XHTML (не важно – табличная верстка или блочная верстка).
У XHTML определенно есть некоторые преимущества. Но рассматривать эти преимущества необходимо вне контекста CSS-верстки. Потому как блоками можно совершенно спокойно верстать и с "чистым" HTML...
Пример из жизни:
Совсем недавно один их моих заказчиков задержал оплату очередного этапа разработки интернет-магазина на целых 3 недели. Причиной тому послужило внеплановое вторжение на территорию компании большой группы лиц в масках и с автоматами. Якобы по причине торговли контрафактными игровыми приставками и дисками…
Тем не менее, через 3 недели заказчик реабилитировался и возобновил оплату по договору. Думаю, что в подобных ситуациях совсем ни к чему названивать заказчикам с требованиями выполнения договорных сроков оплаты, считать их мудаками или сомневаться в собственной «нужности»…
Что же касается добавления второго пункта – я не вижу в этом ничего предосудительного. Гарантийные обязательства обязательно должны предоставляться. Другое дело, что формулироваться все это должно несколько по-иному:
Если же проектная документация изначально не составлялась и не утверждалась – это уже проблема компании-исполнителя, но никак не заказчика…
Боюсь, что если заказчик никак не хочет платить вовремя, вряд ли можно эффективно решить эту проблему. Тема пеней уже неоднократно обсуждалась: далеко не каждого заказчика они устраивают при подписании договора. Что же касается приведенных «методов борьбы» – они, конечно, весьма оригинальны, определенно могут «браться на вооружение», но все же это не панацея. Кроме того, для солидной компании-исполнителя не всегда приемлемо «действовать заказчику на нервы» (даже если он принципиально нарушает оговоренные сроки оплаты).
На мой взгляд, необходимый минимум – это составление грамотного договора, согласно которому работа выполняется поэтапно (разработка концепции дизайна, верстка статических прототипов веб-страниц, разработка программных компонентов и модулей, информационное наполнение), причем каждый такой этап оплачивается предварительно и только после принятия заказчиком предыдущего этапа. Что касается проведения проектных работ – они вообще должны оплачиваться отдельно от стоимости разработки веб-сайта (и тоже только предварительно), поскольку результат проектирования (техническое задание) является приложением к основному договору.
Кроме того, некоторое время назад я взял на вооружение следующую «изюминку»:
В случае приостановления выполняемых по настоящему договору работ по инициативе «ЗАКАЗЧИКА» денежные средства, полученные «РАЗРАБОТЧИКОМ» за выполненные этапы работ, «ЗАКАЗЧИКУ» не возвращаются. При этом исключительные права на разработанную концепцию дизайна веб-сайта, сверстанные статические прототипы веб-страниц, а также программные компоненты и модули остаются у «РАЗРАБОТЧИКА».
Не Бог весть какое удовольствие для компании-исполнителя, но все же...)
Вашим потребностям? Не слабо.) Мне почему-то всегда казалось, что предлагаемые рынком системы должны в первую очередь удовлетворять потребностям программистов и контент-менеджеров (конечных пользователей), но никак не потребностям руководителей проектов, основной задачей которых является подбор исполнителей, контроль качества и информационная поддержка заказчика в процессе реализации проекта.
Смею Вас заверить, что ни одна (даже самая паршивая и кривая система) не может отнимать у сотрудников много времени на создание однотипного функционала. Условия здесь только два:
1. Этот «однотипный функционал» уже должен быть создан сотрудниками (хотя бы один раз).
2. Сотрудники являются программистами и не заканчивают при этом 5 класс общеобразовательной школы.
И ведь действительно, нахера? Какой заголовок? Какое нахер краткое содержание? Возьмите, например, NetCat и создайте свой собственный программный компонент с необходимым именно Вам индивидуальным набором полей. Там это делается буквально в несколько щелчков мыши. Разве это не гибкость и кастомизация, которой Вам так не хватает? Не нужен миллиард параметров? В чем проблема?)
И так и должно быть, поскольку подавляющее большинство современных систем построения и поддержки веб-сайтов являются ни чем иным как своеобразными платформами-фреймворками, которые создаются программистами для программистов. Что же касается конечных пользователей и руководителей проектов – их должен волновать только лишь удобный пользовательский интерфейс, позволяющий легко и непринужденно наполнять веб-сайт необходимой информацией. Но никак не кастомизация программных модулей или написание нового функционала...)
Это – каталог ссылок. Весьма полезная вещь в определенных ситуациях. Если же Вам не нравится какой-то стандартный модуль – удалите его и поставьте задачу программистам, чтобы они написали другой, свой, который не будет Вам казаться бредовым. Один раз и навсегда.
Эта проблема, по правде говоря, к CMS имеет отношение весьма и весьма косвенное. Другими словами, наплодить говнокод/говноконтент можно и не прибегая к помощи CMS и WYSIWYG-редакторов. Тут все дело в сложившихся стереотипах и традициях, которые имеют много исторических причин возникновения. Бороться с этим злом определенно стоит, но только не посредством громких заявлений о том, что все российские коммерческие CMS – «говно редкостное»…
Тем не менее, по моему скромному мнению, NetCat CMS – очень даже неплохая платформа. По крайней мере она имеет весьма развитый и удобный API, предоставляет полный контроль над HTML-шаблонами, не «поганит» HTML-разметку и позволяет разрабатывать безупречные синтаксически и семантически корректные интернет-ресурсы, соответствующие всем современным веб-стандартам.
На мой взгляд, единственная серьезная проблема программного комплекса NetCat – отсутствие поддержки UTF-8.
Впрочем, Ваше утверждение уже опровергли соответствующим образом...
Блочная верстка – это совсем не обязательно XHTML.
Сравнивать, наверное, нужно было по отдельности следующее:
1. Табличная верстка vs Блочная верстка (не важно – HTML или XHTML).
2. HTML vs XHTML (не важно – табличная верстка или блочная верстка).
У XHTML определенно есть некоторые преимущества. Но рассматривать эти преимущества необходимо вне контекста CSS-верстки. Потому как блоками можно совершенно спокойно верстать и с "чистым" HTML...