Показаны сообщения с ярлыком Процедуры. Показать все сообщения
Показаны сообщения с ярлыком Процедуры. Показать все сообщения

24 марта 2011 г.

«Ох уж эти сказочки, ох уж эти сказочники...». Часть II

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

5.     Собственно, к «разбору полетов» как раз подошел и анализируемый пост:
Представители «Эпсилона» выходят на подрядчиков, компанию «Бетта». Объясняют, что работать невозможно, нужно срочно доделывать все «по уму».
Что значит «выходят на подрядчиков» и «объясняют, что работать невозможно»? Это должно было быть объяснено подрядчикам еще в ходе приемочных испытаний – с фиксированием всех недостатков в протоколе испытаний, с предъявлением (если необходимо) претензий в соответствии с уставом проекта (его же так долго согласовывали...) и выставлением штрафных санкций в соответствии с договором. Все перечисленное – азы проектного управления и соблюдения договорных обязательств.

Из «Бетты» отвечают: «Наша компания является организационным Центром управления проектами, наши консультанты провели обследование, написали ИТ-стратегию и Методологию, а непосредственные разработчики – компания «Гамма». Пишите им официальную претензию, и все исправим».
Вот он – апофигей бреда! Что ни фраза, то бред на бреде сидит и бредом погоняет!
Какая ИТ-стратегия? Напоминаю затравку сюжета – «Эпсилону» понадобилось расширить функционал существующей системы. Т.е., проект – чисто программерский. Тут стратегические распальцовки не канают – думать некогда, нужно трясти, т.е. код кропать.
Какое «написание методологии»?? В проектах по программной разработке методологии не пишут, методологиями (готовыми и давно проверенными-откатанными!) пользуются.
Какое – «пишите претензию разработчикам»??? Договор заключен между «Эпсилоном» (заказчиком) и «Беттой» (исполнителем-генподрядчиком). При чем тут «Гамма»? Отношения генподрядчика со своими субподрядчиками – внутреннее дело стороны, исполняющей договорные обязательства. Заказчик может и должен предъявлять все претензии только второй стороне по договору – исполнителю. А основная обязанность исполнителя – соблюдать договорные обязательства и нести перед заказчиком полную ответственность. Это такие азы договорных отношений, что мне даже неудобно, что приходится об этом писать.

23 марта 2011 г.

«Ох уж эти сказочки, ох уж эти сказочники...». Часть I

Выполняю обещание, данное в комментах к одному из постов в ЖЖ-сообществе ecm_community и попробую сейчас объяснить, почему все написанное там я назвал бредом. Ну, возможно, «бред» это было очень сильное определение - «сказочка» подойдет, пожалуй, лучше. В принципе, очень коротко я пояснил там же: «Из отдельных деталей, действительно имеющих место быть в отдельных проектах (и именно поэтому порождающих эффект узнавания), сооружена абсолютно неправдоподобобная конструкция». Сейчас буду разбирать подробно. Тем, кто не читал исходный пост, подвергающийся сейчас моему критическому анализу, рекомендую все-таки сначала его прочесть – чтобы было понятно, о чем идет речь (сначала я хотел сделать краткий пересказ сюжета здесь, но потом понял, что все равно практически весь «исходник» процитирую в процессе критики).
И необходимый дисклеймер. Поскольку я знаю, кто является автором критикуемого поста (авторесса и сама не очень-то скрывает свою identity), где она работает и чем занимается, я буду стараться быть максимально корректным в высказываниях – nothing personal, only business :). Но ежели все-таки какие-то из моих оценок покажутся обидными, заранее за них прошу прощения.

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

9 декабря 2009 г.

Хронология разработки стандарта ODF

Для того, чтобы картина противостояния двух форматов была более полной, нужно иметь больше деталей – и не обязательно с «военным уклоном». Этот пост посвящен хронологии разработки стандарта ODF в OASIS.
Собственно, вся хронология укладывается в приведенный ниже график.


Источник: блог Роба Вейра

Как написать стандарт (если вам очень нужно)

Еще прекрасное из блога Роба Вейра. Я только перевел.

Стандарты в целом являются плохой идеей. Они уменьшают свободу действий и ограничивают выбор. Но иногда вам нужно иметь один, чтобы успокоить регулятора, настроенного против бизнеса, или бюрократа социалистического толка. Итак, что нужно делать, если вы неожиданно обнаруживаете, что вам нужно срочно обратиться в Департамент по стандартам? Безусловно, создать стандарт и сделать это быстро! Я предлагаю здесь некоторые обобщения передового опыта, а также проверенные и надежные советы, как сделать стандарт быстро, с минимальными заморочками или риском.

Сначала небольшой ликбез. Написание стандартов, как это обычно делается, представляет собой многосторонний, совещательный процесс, в котором рассматриваются и обсуждаются несколько точек зрения - до тех пор, пока консенсус не будет достигнут и задокументирован. Этого нужно избежать любой ценой. Задержки, обусловленные таким  процессом консенсуса, весьма значительны, и результаты такого процесса не оправдывают затраченного на них времени. Если у вас уже есть монополия, зачем терять время в поисках консенсуса? Вспомните известные неудачи XHTML, XForms, SVG, XSLT и т.д. Посмотрите на несколько реализаций этих стандартов, в том числе пиратские и незащищенные авторскими правами продукты. Вы действительно хотите, чтобы эта тенденция сохранилась?

Рекорды стандарта OOXML

Пока длинный-длинный пост про процесс «быстрой» стандартизации все еще пишется, я решил опубликовать своего рода «трейлер» к этому посту.

Еще только появившись в качестве стандарта Ecma International, спецификация OOXML успела поставить сразу два мировых рекорда – по объему стандарта (6546 страниц) и по скорости разработки стандарта в рамках Технического Комитета Ecma TC45 – 357 дней с момента передачи первого чернового варианта спецификации в TC45 до момента утверждения в качестве стандарта ECMA-376.

На графике внизу представлены данные по скорости утверждения в ранге стандартов ряда других спецификаций:
- OASIS OpenDocument Format (ODF)
- OASIS Darwin Information Typing Architecture (DITA)
- W3C Extensible Stylesheet Language (XSL)
- W3C XHTML
- W3C Scalable Vector Language (SVG)
- W3C Simple Object Access Protocol (SOAP)
- IETF MIME
- Ecma C#
- Ecma C++/CLI
Горизонтальная ось – размер отпечатанной спецификации в страницах A4, вертикальная ось – количество календарных дней, проведенных спецификацией в рамках соответствующего Технического Комитета.


 Источник: блог Роба Вейра

2 декабря 2009 г.

Порядок разработки стандартов ISO

Поскольку при рассмотрении истории утверждения OOXML в качестве стандарта ISO/IEC важно понимание всей процедуры разработки, рассмотрения, утверждения и публикации стандартов, еще один предварительный информационный пост я решил посвятить обзору данной процедуры.
Полное описание процедуры приведено (на английском языке) на сайте ISO – (см. «Stages of the development of International Standards» - http://www.iso.org/iso/standards_development/processes_and_procedures/stages_description.htm).
Подробное изложение данной процедуры на русском языке имеется в русской Википедии - http://ru.wikipedia.org/wiki/ISO.
При создании данного поста использовались оба вышеназванных источника.