Что может быть лучше Basecamp?

«О, вы тоже используете Basecamp? Отлично!» — отвечают нам новые клиенты, получившие приглашение. Basecamp стал стандартом де-факто. Когда мы начали использовать Basecamp, сперва возникло ощущение, что мы попали в рай. Система просто делала свое дело, и не заставляла нас предполагать, что мы слишком тупы, чтобы ею пользоваться. Полное отсутствие каких-либо возможностей настройки (кроме, разве что, перекраски интерфейса) обернулось огромным плюсом: не надо тратить время и энергию на эту самую настройку. Садись — и работай. Однако по прошествии года активного использования Basecamp (несколько десятков завершенных проектов) мне начало казаться, что пора взглянуть на эту систему более трезвым взглядом.

Проект в Basecamp по структуре в своей основе напоминает блог. Категории, сообщения, комментарии… Структура хорошо знакомая пользователям — это плюс. Но идеально ли блоговая структура подходит для управления проектами? Ведение блога — процесс непрерывный, обычно без четкой цели. Напротив, менеджер проекта, в отличие от автора блога, обычно надеется, что проект будет рано или поздно завершен. Благополучное завершение проекта — цель, к которой стремятся все его участники, и все их действия обычно нацелены на выполнение конкретных задач, связанных с этой целью. Только всеобщим блогопомешательством можно объяснить, почему инструмент для ведения проектов решили уподобить блогу. Впрочем, я слышал, что в некоторых компаниях в качестве системы совместной работы и вовсе используют MovableType.

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

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

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

Жёлтым цветом выделены те сообщения, которые должны показываться на заглавной странице проекта. Один взгляд на такую страницу позволит оценить текущие состояние всех задач. А развернув любую цепочку, можно ознакомиться с предысторией, вплоть до изначальной постановки задачи.Как видите, предложенная модель ничуть не сложнее, чем та, на которой основан Basecamp. Но она гораздо лучше соответствует нашим потребностям. Неужели я хочу слишком многого?

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