• В папке на сервере можно хранить разнообразные материалы примерно в таком виде:
• входящие
• рабочие
• исходящие

Каждая из подпапок может быть разбита по типам информации («дизайн», «текст», «требования»), а также по версиям.

Наполнение сайта лучше всего иметь в виде собранного прототипа сайта. Так всем понятнее и проще: гипертекст стоит готовить в среде гипертекста. Так может быть сложнее отловить незаполненные страницы, но для этого, наверно, можно использовать специальные служебные страницы, отображающие списки страниц сайта, требующих внимания.

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

Не очень понятно, что вы подразумеваете под «анализом переписки». Наверно, удобнее всего видеть переписку с одним клиентом в виде большой простыни, как в Гугль-мейле, по крайней мере, в одном из режимов. В другом режиме хорошо видеть все письма в виде списка заголовков, но с флажками, отмечающими ключевые письма, например, с отправленными эскизами или со списком замечаний клиента.

Комментарии

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

Креатив
— апрувд
— ввв

Девелопмент
— документация
— хтмл-темплейты
— техдизайн

Менеджмент
— баглист
— входящие
— исходящие
— контакты (профили)

Доступ к разделам можно регламентировать.

Удачи!

Александр!
Действительно ли менеджер проектов небольшой (по вашим словам) студии страдает от проблемы хранения, структуризации и передачи информации в рамках одного проекта?

Какая конкретно проблема стоит?

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

http://freemind.sf.net
великолепное решение подобных задач

Дмитрий!

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

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

Что касается электронного материала, то в корневой папке проекта достаточно создать папки для всех участников или отделов, по направлениям, далее по типам и т. д. и т. п.

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

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

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

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

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

Проблему усугубляет колоссальных размахов бардак в голове самих участников проектов, которые годами не знают что у них «оказывается есть еще диск D», а файловая структура представляет собой захламленный диск C, который содержит огромное количество бессмысленных директорий и файлов.

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

Возможно, в технологичных компаниях, где уровень участников проекта высок, где все с компьютером на «ТЫ» нужно идти дальше.

Хотел бы я работать в такой компании.

P.S. Пользуясь случаем, хочу сказать спасибо за опубликованные на сайте материалы.
P.P.S. Мельком видел на днях этот совет, перерыл «ководство» и вспомнил, что видел-то здесь =)

Средство управления версиями svn + tortoisesvn (http://tortoisesvn.net/)
Средство управления запросам trac (http://trac.edgewall.org/)