Какие инструменты для совместной работы эффективны для работы с нетехническими людьми?

Question

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

Вопрос этого вопроса заключается не в «заботе и питании» этих групп, а просто о том, какие инструменты были найдены для содействия сотрудничеству и необходимому взаимодействию? Я размышляю о линиях IM по сравнению с wikis по сравнению с традиционными списками рассылки электронной почты или корпоративного портала sharepoint, но задаюсь вопросом, что другие нашли для работы.

Answer 1

Basecamp - это радость в использовании, и его основное внимание уделяется управлению проектами посредством сотрудничества.

Answer 2

Здесь мы используем Quickbase. Отвечает всем нашим целям.

Answer 3

Вы можете взглянуть на эти продукты:

• FogBugz - детище StackOverflow соучредитель Джоэл Спольски. Обрабатывает отчеты об ошибках, запросы функций, вики и многое другое. Раньше я использовал FogBugz, и он был довольно прочным, несмотря на то, что он был written in its own language.
• BaseCamp - флагманский продукт 37-х сигналов. Я лично не пробовал этого, но он получил восторженные отзывы от некоторых людей, которых я знаю и уважаю.

Answer 4

Мы установили wiki для общих документов, памяток, отчетов о состоянии и т. Д. Для обучения всего персонала потребовалось около часа, но это того стоило.

Answer 5

При создании вики вы должны договориться о том, какая информация идет туда.

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

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

Я реализовал это для крупного проекта и имел статус RAG для непрерывных сборок и регрессионных тестов.

Нажав на индикаторы RAG, вы узнали больше деталей. Это повторялось для нескольких уровней, поэтому на верхнем уровне у вас был индикатор RAG.

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

Это было весело для реализации.

веселит,

Роб

Answer 6

Я слышал анекдотические доказательства (оксюморон, конечно), что они хорошо ладят с Вики, при условии, что у них есть визуальный редактор.

(я использовал, чтобы принять участие в проекте TWiki.org, и я знаю, что они имеют WYSIWYG Plugin, но я уверен, что «другие варианты».)