+7 (499) 638-64-11
Попробовать
Постановка и автоматизация процессов разработки ПО

Лучше не писать техническое задание в Google Docs

05.09.2017 06:36

Многие подрядчики разрабатывающие гос. заказ, готовят техническое задание средствами коллективной работы с документами, Google Docs один из них. Дело в том, что оно конечно доступно (то есть бесплатно), позволяет вести обсуждения, хранить историю изменений, все заинтересованные лица имеют доступ к последней актуальной версии документа, по заявлению провайдера, документ не может потеряться.

С другой стороны, у данного способа совместной разработки ТЗ есть определенные недостатки, как и у любого другого инструмента.

Проблемы конфиденциальности

Высокий уровень защиты данных – очень дорогая роскошь. Google Docs ни раз демонстрировал уязвимости, которые позволяли любому желающему с навыкам воспользоваться чужими документами. Защищенность ваших данных успех работы коллег. Уровень защищенности ваших документов прямо зависит от грамотности ваших коллег в плане информационной безопасности. Регулярное администрирование доступа к документам необходимо.

Проблемы интернет-соединения

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

Проблемы согласования

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

Проблемы в управлении требованиями

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

Отсутствие интеграции с планировщиками задач не позволяют выстроить эффективный и прозрачный процесс управления командой аналитиков и проектировщиков.

Проблемы документирования требований

Google Docs и идентичные инструменты предоставляют совместное редактирование документов, но не системных требований. Вставка UML-диаграммы и любые правки невозможны для любого из членов команды. Математических формул это касается также. Повторное использование при разработке требований, при схожести продуктов – это путь к сокращению затрат. Online-документы не предоставляют никаких средств включения требований из других документов, либо использования шаблонов документов.

Проблемы качества

Монолитный документ ТЗ пригоден лишь для печати. Невозможность трассировки требований на исходные запросы, код, тестовую документацию и т.п. Это существенно усложняет оценку полноты и качества выполнения всех требований. Благодаря трассировкам (или отслеживаемости) производится объективная оценка стоимости изменений.

Еще интересные статьи на эту тему: