softosaur
Редакционный анализ
Менеджер по маркетингу не просто предложил новое приложение. Директор по маркетингу поддержал идею внедрить Notion. Менеджер часами выстраивал рабочие процессы, упрощал систему и созванивался с коллегами один на один. А через полгода, по его рассказу, команда вернулась к таблицам, почте и разрозненным сообщениям.
В этой истории на r/projectmanagement узнаётся особенно досадный исход внедрения: система есть, людям показали, как она работает, а её создателю по-прежнему приходится собирать сведения, которые она должна была упорядочить.
Это рассказ одного человека; версия команды нам неизвестна. Установить, почему внедрение забуксовало, мы не можем. Но вместе с другими публичными обсуждениями и исследованиями совместной работы он ставит полезный вопрос для тех, кто выбирает командное ПО: что происходит между выполнением работы и обновлением общей системы?
Создатель системы и его коллеги решают разные задачи
Для менеджера проблема была очевидна. Решения и подробности кампаний терялись среди документов, встреч и сообщений. На сбор информации могли уходить часы. В личных проектах Notion уже помогал, поэтому распространить его на команду казалось разумным.
Но для коллеги важнее может оказаться более узкий вопрос: что я смогу сделать дальше благодаря тому, что внесу это обновление?
Участник под ником BrIDo88 предлагает именно такую трактовку: новый процесс может выглядеть как помощь его инициатору за счёт всех остальных. Другие комментаторы делают упор на поддержку руководства или обязательность использования. Это разные объяснения; собственная версия команды в обсуждении отсутствует.
В другом обсуждении отказа от новой системы то же расхождение описано ещё резче. Автор, чей аккаунт теперь удалён, пишет, что новый проектный инструмент со временем превращается в систему, которую руководитель проекта обновляет для руководства, пока сама работа продолжается в Slack. Комментаторы спрашивают, решает ли система реальную задачу и есть ли причина пользоваться ею у кого-то, кроме организатора.
Повторяется вопрос: кому настолько нужна общая информация, что он будет поддерживать её в полезном состоянии? Эти обсуждения подтверждают наличие вопроса, но не показывают, насколько распространена проблема.
Дополнительная работа всё равно достанется кому-то
У этого вопроса есть и исследовательская история. В статье i-com 2024 года Melanie Duckert и Pernille Bjørn возвращаются к трудностям создания ПО для совместной работы, опираясь на этнографическое исследование двух организаций, проведённое в 2023 году. Одна из трудностей — неравномерное распределение усилий, необходимых для работы общей технологии, и пользы от неё.
Их наблюдения не касаются Notion. В одном из случаев речь идёт о Workplace от Meta, который использовался наряду с уже привычным Microsoft Teams. Сотрудникам приходилось помнить, в каких ситуациях нужна другая платформа, отдельно публиковать сообщения и следить за обновлениями. Частичное совпадение задач двух систем было частью проблемы.
Исследователи оговаривают важное ограничение: они пришли в организации, когда системы уже использовались, поэтому могли лишь ограниченно наблюдать их первоначальное внедрение. Это качественные данные о конкретных организациях, а не статистика неудач командного ПО.
Такой взгляд помогает поставить вопрос о Notion, но не даёт окончательного ответа. Обновление может быть полезно человеку, который готовит сводный отчёт по проектам, и обременительно для того, кто уже объяснил то же самое в другом месте. Оба опыта могут сосуществовать в системе, которую вначале все одобрили.
Вторая таблица может помогать не терять работу из виду
В ещё одном обсуждении управления проектами человек, ведущий несколько программ, рассказывает об использовании Todoist, Favro, Excel и Word. Задачи он отслеживает и в Favro, и в таблицах: в таблице нужные сведения проще найти повторно, чем в архивных карточках.
Позднейшие ответы уточняют его затруднение. Он перестаёт понимать, где искать актуальную информацию. Отделы по-разному следят за ходом проектов. Ему нужен понятный порядок управления работой, а не ещё один набор документов, которые придётся поддерживать.
Эта деталь меняет постановку задачи. Если просто удалить таблицу, исчезнет место, на которое человек пока полагается, чтобы видеть происходящее. Перенос всего в новое приложение сам по себе не объяснит, где потом искать завершённую задачу и какая запись главнее, если две версии расходятся.
У разных инструментов могут быть разные роли: обсуждение, подробное ведение задач, финансовый анализ или долговременное хранение сведений. Присмотреться стоит к тому месту, где эти роли пересекаются. Если одно решение нужно вручную внести в две системы учёта задач, кому-то придётся их сверять. За удобной сводной панелью эта работа может быть не видна, хотя без неё панель не обходится.
Общая запись в Notion не требует одинакового вида для всех
Технические возможности здесь тоже важны. В документации Notion об источниках данных объясняется, что связанный источник можно показать в другой базе. Представления, фильтры, сортировка и группировка могут отличаться, а изменения свойств или страниц источника отражаются в оригинале. Доступ по-прежнему определяется правами исходной базы.
Это позволяет по-разному показывать одну и ту же работу, не поддерживая отдельные копии внутри Notion. Рабочее представление исполнителя и общий обзор руководителя не обязательно должны становиться двумя списками задач, которые обновляют независимо. Согласовывать отдельную таблицу или переписку в чате с этой записью — отдельная задача.
Notion также поддерживает комментарии на страницах и в записях баз, а упоминания помогают направить коллег к конкретному обсуждению. В документации о совместной работе указано существенное исключение: если упомянуть человека на странице, к которой у него нет доступа, уведомление ему не придёт.
Помогли бы эти функции той команде, неизвестно. Для покупателя практический вопрос — может ли обычный участник найти нужную запись, внести полезное изменение и увидеть его результат.
Прежде чем менять инструмент, проследите путь одного обновления
Команде в такой ситуации может помочь разбор одного недавнего изменения в текущей системе работы. Где о нём впервые договорились? Кто внёс его в систему учёта задач? Пришлось ли кому-то внести его повторно? Откуда следующий участник взял данные, прежде чем действовать?
Возьмём условный перенос даты запуска. Коллега согласовывает новую дату в чате. Кто-то меняет таблицу; от другого человека ждут обновления Notion. На следующей встрече руководитель открывает рабочее пространство и видит старую дату. Команда договорилась, но общая запись неверна.
Теперь изменим маршрут: дату правят в записи проекта, а обсуждение в чате ссылается на эту запись. Чтобы такой порядок заработал, людям нужны доступ, понятный ответственный за обновление и причина в следующий раз обратиться к записи. Сам по себе перенос разговора этих условий не создаёт.
Путь одного реального изменения может обнаружить недостающие права, непонятное представление, лишнее поле, отчётную задачу без ответственного или процесс, который два отдела понимают по-разному. Каждая из этих находок требует своих изменений.
В истории заброшенной системы менеджера по маркетингу эти вопросы остаются без ответа. Покупка другого инструмента тоже не ответит на них, если при выборе не учитывать людей, которые поддерживают информацию, и тех, кто на неё опирается.
Сравнивая программы для управления проектами, проверяйте всю эту последовательность. Какое существующее обновление заменяет новая система? Кому от этого станет легче? Где будет принято следующее решение? Рабочее пространство становится частью работы, когда поддерживать его в актуальном состоянии — значит помогать делу двигаться дальше.