Как повысить качество государственных сайтов?

Есть вот такая статья: Как повысить качество государственных сайтов?

Говорят, по ней не прошелся только ленивый. Поэтому я тоже не буду исключением.

Поскольку эта статья породила ряд других заметок и дискуссий, я свое мнение по ней хочу высказать по схеме "тезис - мое мнение". Итак, поехали.

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

Результат заказной разработки НИКОГДА не зависит только от вендора. Это же очевидно. В случае же, когда мы говорим о государственных структурах и им подобным, то там вполне распространена методология навязывания решений, известная как “я начальник, ты дурак” и никакой UX со знанием методологий и высочайшим уровнем квалификации команды преодолеть это бедствие не в состоянии. Я скажу больше - иногда стыдно указывать свое имя под тем, что можно было сделать очень классно, но волевые решения Заказчика убили всё.

Повышать культуру разработки ТЗ. «ТЗ и ЧТЗ по ГОСТу» все научились писать, потому что это очень легко: шаблон документа дает такой дикий объем, что о содержательной части можно особенно не беспокоиться.

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

Контрактное ТЗ должно более не менее однозначно отвечать на один вопрос - зачем веб-сайт нужен? Иными словами, оно должно формировать понимание по следующим позициям:

• кто является целевой аудиторией
• в чем заключается потребность Заказчика в сайте
• в чем заключается потребность целевой аудитории в сайте
• какова стратегия конверсии потребностей целевой аудитории в реализацию целей Заказчика

Это не большой документ, но это хорошая отправная точка для начала проектирования.

Проект и ТЗ необходимо делать отдельно от разработки по своему небольшому контракту.

Всеми руками "ЗА".  Но тут мне в статье не нравится то, что речь идет от ТЗ, т.е. о документе, а не об артефактах анализа - требованиях, моделях и т.п. Как бы есть большая разница - цели у них разные. Соответственно возникает вопрос - каковы цели такой предварительной фазы, точнее пред-проекта? Детальная проработка всего продукта? Ну скорее нет, поскольку сюда же приплетется UX, пойдут прототипы решения и аналитический проект незаметно пришьется к разработке. Сделать только концептуальное проектирование? Но оно не закроет риски, о которых говорит автор статьи, хотя с другой стороны - позволит сформулировать единое видение продукта у всех стейкхолдеров (что само по себе очень ценно).

Проработанное ТЗ снизит риски исполнителей, и они смогут не закладывать в цену неизбежные при непонятном техзадании переработки и переделки, на конкурс придут новые свежие игроки, готовые работать в прозрачной ситуации.

Нееет! Потому, что ТЗ - это документ, выпускаемый для определенных целей. Иными словами, ТЗ для утверждения стейкхолдерами и ТЗ для разработки в общем случае могут быть разными документами. Точнее даже - должны быть разными документами. При этом риски, закладываемые в оценку, связаны не только с неопределенностью задачи, но и с вероятностью изменения требований. А понимание масштабов изменения возникает тогда, когда можно потрогать дизайн и динамику поведения. Т.е. это далеко после проектирования. И именно поэтому для веб-разработки критично прототипировать больше и чаще, параллельно с проектированием продукта.

Ни один подрядчик не покроет все своими компетенциями, поэтому при выполнении крупных работ нужно быть готовыми к созданию объединенной команды из нескольких организаций-смежников. В этой ситуации особенно важно проработанное ТЗ и проектное управление.

Ну во первых есть подрядчики, которые покроют. Во-вторых, для этого важно не ТЗ, важно понимание результирующего продукта (vision), важно правильно выбрать методологии выполнения работ и грамотно засетапить проект. Факт наличия проработанного ТЗ на это влияет опосредованно. Да и получить проработанное ТЗ можно после достаточно серьезной фазы проектирования, когда уже может потребоваться организовать взаимодействие кучи субконтракторов.

Основная претензия к статье - бюрократическая точка зрения, от документа. Это не правильно.