Александр Комаченко
12 апреля 2007

Добрый день, Артем.

Меня зовут Александр, я — начинающий руководитель проектов в небольшой студии в Екатеринбурге.

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

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

Подскажите направление движения для решения этой проблемы.



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

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

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

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

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

P. S.

Дата следующего набора в Школу стажёров пока неизвестна.

 
Мы напишем вам, когда будет открыт набор. Без спама.

Поделиться

Комментарии

Анатолий Юдов
13 апреля 2007

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

Хансенн
13 апреля 2007

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

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

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

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

Удачи!

Константин Гарин
13 апреля 2007

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

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

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

Dmitry
13 апреля 2007

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


13 апреля 2007

Дмитрий!

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

RHD
14 апреля 2007

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

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

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

Денис
18 июня 2007

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

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

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

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

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

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

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

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

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

Сергей Стасенко
25 июля 2007

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


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

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

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

Вот такой веб 2.0.

Вы не обязаны соглашаться Как вести документацию по дизайну Как флексить. Перенести на следующую итерацию Как флексить. Не выходить в надсистему




Недавно всплыло

3 1 У меня остаётся ощущение, что я идиот, «рассыпала бобы», но на конкретных ошибках не могу себя поймать 3 Как написать заказчику, что я установлю модуль на его сайт после окончательной оплаты, и при этом не обидеть его? 2