Софт для правильной разработки ТЗ

 Публичный пост

Уже который раз сталкиваюсь с большими ТЗ (от 100 страниц текста), которые разрабатываются просто ужасно: в оффлайн-ворде, комментариями внутри файла, кучей файлов без версионирования, которые пересылаются друг другу по почте. В итоге получается каша из стилей и графики, которая иногда не открывается в разных версиях приложения, в которой очень трудно искать различия между разными версиями.

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

А может, есть и то, и то? Чтобы и версии были, и обсуждение текста?

Связанные посты
20 комментариев 👇

Версионирование есть и в word и в open office и google docs("облачное решение, которое бы позволяло редактировать и оставлять комментарии из браузера") .
Проблема в людях - они им не пользуются, а пересылают файлы "Копия-Копия-Копия ТЗ.doc" в email без темы.

  Развернуть 1 комментарий

Дико плюсую. Качество ТЗ на 90% это работа составителя

  Развернуть 1 комментарий

  Развернуть 1 комментарий

@kellas, Да, я знаю про него, пользуюсь. На 100+ страницах с картинками и форматированием начинает тормозить, для больших проектов непригоден.

  Развернуть 1 комментарий

@vvzvlad, может есть смысл разбить на несколько документов ?

  Развернуть 1 комментарий

@kellas, Думал над этим, но в отличии от маркдауна, слить их автоматически нельзя. А хочется избежать всякой такой рутины

  Развернуть 1 комментарий

@vvzvlad, да можно при желании https://softgateon.herokuapp.com/mergedocs/ но зачем их сливать если они тормозят потом?

с git и разруливанием конфликтов тоже не мало рутины

  Развернуть 1 комментарий

@kellas, чтобы получить единый doc/pdf-файл. Тз в конце-концов требуется именно в таком виде.

  Развернуть 1 комментарий

@vvzvlad, разве есть какие-то нормативы требующие ТЗ в одном файле?
Ну и печтать более 100 страниц то же долгая нудная работа.
Так что просто потом один человек за 5-10 минут тупо копированием и вставкой объединит 10 документов в один.

И да, там ниже писали про инструменты для реально крупных проектов и весь confluence или какую-нибудь wiki тоже очень проблематично засунуть в один pdf )

  Развернуть 1 комментарий

@kellas, у заказчиков так принято. Один-то человек это сделает, но это буду я.

  Развернуть 1 комментарий

N

  Развернуть 1 комментарий

No.

  Развернуть 1 комментарий

Not

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий
  Развернуть 1 комментарий

До сих пор спасаюсь Гуглдоком.

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

  Развернуть 1 комментарий

Ещё призываю @Actinarium как мастера по Coda. Может она Грааль, который мы все ищем?

  Развернуть 1 комментарий

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

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

  Развернуть 1 комментарий

Confluence

  Развернуть 1 комментарий

Неплохо заходят:

  • Confluence или любой другой вики-движок (в Azure DevOps есть свой с маркдауном и мермейд для схем-как-текст, так что даже микроизменения в UML-диаграммах версионируются); конфлуенс хорошо плагинами для чего угодно (draw.io для диаграм)
  • SwaggerHub и другие OpenAPI дизайнеры (Apiary, Spotlight — много их), если в результате ваших спек будет RESTful API. Не годится для спецификаций GUI и сложной бизнес-логики)
  • Приснопамятный UML — типа Camunda Modeler — для визуализации бизнес-процессов; опенсорсный, результат в виде XML-файла.
  • ALM-софт. Но это может оказаться прямо ядрёной бомбой, не каждая компания переживёт его внедрение. Очень крутой — ALM Octane от Microfocus, но им нужно заменять Джиру. Из той же оперы связка из Broadcom Rally + Requirements Designer.
  • MS Word в режиме правки + Sharepoint для хранения и распространения, или Google Docs в целом тоже ОК.
  Развернуть 1 комментарий

Вот про Confluence интересная идея, да. Он все равно у нас развернут.

  Развернуть 1 комментарий

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб