Pull to refresh

Comments 14

Microsoft и так хорошо рекламирует свои продукты ;)
А вариант 2 планировался? Или только вариант 1 и сразу выводы?
То что вы описали вполне возможно реализовать с помощью любого wiki-движка. При этом не будет проблемы поиска, которые вы описали.

Хотя с другой стороны этот подход «несколько сложнее» в реализации =)))
… то вам нужен более продвинутый инструмент. Для себя мы нашли его в Вики.
Как раз хотел процитировать последний абзац. Рад, что дочитали до конца :)
Вариант №2 таки планировался. Как раз про вики. Сейчас пишется.
Инструмент — это, конечно, самое главное в создании спецификаций.
Затруднена совместная работа.
Нет истории изменений.
Настройте SVN. TortoiseSVN вполне прост в обращении и позволяет сравнивать документы внешними программами, обзор которых был недавно на 3dnews. На сколько помню, там нашлись довольно удобные именно для doc-файлов.
Затруднен поиск.
Лично у нас данную проблему решили установкой поиска от Яндекса на собственном домене. Правда, с индексацией doc-файлов возникли какие-то проблемы, но на сколько знаю, их удалось решить, хотя бы частично.
Проблема истории изменений doc-документов в том, что кроме самого Microsoft Word'а нет ни одной программы, которая бы могла правильно сравнить и отобразить изменения в файле :\
Сейчас перепроверил, и убедился, что TortoiseSVN doc-файлы сравнивает Word-ом ;)
Как раз это я и называю — задача затруднена. Не невозможна в принципе, а решается с помощью других инструментов, призванных компенсировать недостатки основного.

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

Но мы сделали только несколько шагов в этом направлении и свернули с половины пути. Мы начали с самых простых средств, которые могли себе представить. Потому что, как правильно заметил г-н. beskov, это лишь средства. А цель была шире — запустить сам процесс написания спецификаций. Как писать, что писать, и в последнюю очередь — в чем писать.

Научились (ну я надеюсь). При этом попутно мы поняли, а чего собственно, мы хотим от нашего идеального инструмента, что было удобно а чего не хватало. И эти знания послужили основой для следующего витка инструментария.
Сейчас это вики. Соответствующим образом настроенная под наши задачи. О чем скоро я надеюсь рассказать.
Заменяем «Microsoft Office» на «бумагу и карандаш», а «сервер» на «шкаф» и не видим разницы никакой в посте. Итого: выбранный вами инструмент вы не используете по назначению, аки микроскопом гвозди. А ведь Офис — это и Visio и Exchange, например.
1. Не всегда девелоперы дефолтны рядом со шкафом.
2. Визио и эксчейндж не дефолтные части офиса.
Разница есть. Если плясать от моих требований к инструменту, то бумага и карандаш решают только одно — удобство правки. Удобство чтения (с моим-то почерком) страдает. не говоря уже о поиске.
При подготовке достаточно большого документа в MS Word (более 60 страниц) применение множества перекрестных ссылок в рамках одного документа приводит к тому, что часто после редактирования документа ссылки «слетают» и приходится снова заниматься вычиткой документа и проверкой что ссылки после обновления служебных полей будут указывать туда куда нужно.

Поэтому считаю что для составления перекрестных ссылок данный формат слабо подходит. Кроме того и функционал выбора ссылки очень неудобен, что приводит к большим потерям времени при форматировании документа.
Эта беда нас миновала. Мы принципиально следуем правилу не писать развесистых документов. Одна задача — один документ. 10 страниц для спецификации — уже слишком много. Средний объем спецификации — 5 страниц. При этом половина из них — это всякие рисунки: диаграммы классов или эскизы экранов.
Sign up to leave a comment.

Articles