Когда переписка стала частью проекта: как фиксировать решения из чатов и писем без склада скриншотов
В рабочем чате заказчик пишет: «Да, оставляем согласование только у руководителя подразделения, второй уровень нам не нужен». Аналитик отвечает, что понял, разработчик ставит реакцию, после чего команда продолжает работу, а через несколько месяцев во время приемки другой сотрудник заказчика спрашивает, почему второй уровень согласования убрали. Найти исходное решение оказывается сложнее, чем казалось в момент обсуждения, потому что переписка давно ушла вверх, между нужными сообщениями накопились десятки организационных вопросов, а участники уже по-разному помнят, на чем именно остановились.
Такие истории возникают не потому, что команда плохо ведет документацию, а потому, что чаты и письма давно стали обычной частью проектной работы, где уточняются требования, выбираются варианты реализации, согласуются ограничения и меняется объем. Запретить принимать решения в переписке почти невозможно и вряд ли полезно, поскольку именно там многие вопросы закрываются быстрее всего, однако оставлять итог только внутри разговора тоже нельзя, если от него зависит дальнейшая работа.
Поэтому нужно разделять обсуждение и его результат: чат остается местом, где люди быстро уточняют детали и спорят о вариантах, а принятое решение переносится туда, где команда будет искать актуальную информацию через месяц, полгода или после смены участников проекта.
Фиксировать нужно решение, а не всю переписку
Самая очевидная крайность возникает тогда, когда аналитик начинает сохранять почти каждое обсуждение, потому что боится потерять договоренности, и в результате вместо нормальной проектной памяти появляется папка со скриншотами, выгрузками чатов и письмами, среди которых через несколько месяцев так же трудно найти нужный вывод, как и в исходной переписке.
Большая часть сообщений имеет ценность только в момент разговора: кто-то уточнил время встречи, попросил прислать файл, предложил промежуточный вариант, который не был принят, или написал, что вернется с ответом завтра. Если переносить все это в постоянную документацию, она перестает показывать текущее состояние проекта и превращается в подробную хронологию общения.
Чтобы понять, фиксировать ли решение из переписки, нужно задать вопрос: изменится ли что-нибудь в работе команды, если через месяц это сообщение никто не сможет найти? Если нет, отдельная фиксация чаще всего не нужна; если без него станет непонятно, почему поменялось требование, кто подтвердил новый объем или откуда взялся выбранный вариант, итог разговора нужно перенести в основной рабочий контур.
В первую очередь фиксируются изменения требований
Если в результате переписки изменился функциональный сценарий, обязательный реквизит, порядок согласования, состав пользователей или другое требование, оставлять итог только в чате нельзя, даже когда формулировка заказчика кажется однозначной, потому что спустя некоторое время разработчик или тестировщик откроет исходное ТЗ и будет ориентироваться именно на него.
В такой ситуации нужно обновить ТЗ и/или добавить новое требование в реестр, который команда использует как актуальное описание решения, а в истории изменений при необходимости указать дату и основание корректировки. Переписка остается подтверждением контекста, однако перестает быть единственным местом, где существует новое требование.
Отдельно фиксируются решения, которые меняют объем, сроки или стоимость
Особого внимания требуют сообщения, после которых меняется состав работ, поскольку именно вокруг таких договоренностей позже чаще всего возникают споры. Фраза «давайте заодно добавим еще аналогичный вид документа» в чате может выглядеть как небольшое уточнение, однако после оценки выясняется, что настройки реквизитов, права, печатные формы - все необходимо настраивать с нуля и совсем по другим правилам.
Если заказчик или РП подтвердил дополнительную работу, отказался от части объема либо перенес функцию на следующий этап, итог нужно перенести в тот инструмент, где ведется объем проекта: карточку изменения, реестр требований, план этапа или другой принятый документ. В этом рабочем документе можно сослаться на сообщение-источник, чтобы при необходимости восстановить историю.
Хорошая фиксация здесь должна быть ясной и предметной: что изменилось, кто подтвердил решение, когда оно принято и как повлияло на план.
Изменение ответственности тоже оставляет управленческий след
Помимо решений относительно проектных требований в переписках могут также приниматься организационные решения - например, перераспределение полномочий между сотрудниками заказчика, изменение спонсора проекта или РП, включение новых сотрудников в рабочую группу и т.д.
Такие сообщения могут восприниматься как менее значимые, хотя смена ответственного, порядка согласования или границы между командами напрямую влияет на дальнейшую работу.
Если такая договоренность останется только в переписке, через некоторое время часть сотрудников продолжит действовать по старой схеме, потому что новая ответственность известна только участникам конкретного разговора. Поэтому изменения ролей нужно переносить в матрицу ответственности, карточку проекта, план коммуникаций или другой документ, где команда привыкла проверять, кто за что отвечает.
Сообщение в чате может подтвердить причину изменения, однако действующая модель ответственности должна находиться не в истории переписки, а в актуальном проектном источнике.
Скриншот - подтверждение, но плохой источник истины
Скриншоты удобны тем, что их можно сделать за несколько секунд, однако именно поэтому они быстро накапливаются. Сначала в папке лежит одно изображение с важной договоренностью, затем появляется второе и третье, а через несколько месяцев среди файлов «чат_12.png» и «согласование_новое.png» уже никто не понимает, какое решение действует сейчас.
Другая проблема заключается в том, что скриншот невозможно нормально обновить. Если через неделю договоренность поменялась, старое изображение продолжает лежать рядом с новым, причем сотрудник, который не знает историю, легко примет первое за актуальное. Длинные выгрузки переписки страдают тем же недостатком, потому что хорошо сохраняют последовательность событий, но плохо показывают текущее состояние решения.
Поэтому скриншот нужен только как подтверждение там, где оно действительно требуется, а сам итог нужно переносить в структурированный источник. В большинстве обычных ситуаций достаточно сохранить дату, участника, подтвердившего решение, и при необходимости ссылку на обсуждение, не создавая отдельный архив изображений.
Куда переносить итог решения
Создавать универсальный журнал, куда переносится вообще все, нужно далеко не всегда, потому что тогда появляется еще один источник, который придется синхронизировать с ТЗ, задачами и планом проекта. Гораздо понятнее переносить итог туда, где он естественно должен жить после завершения обсуждения.
- Если изменилось требование - обновляется спецификация требования/ТЗ, реестр требований.
- Если изменился объем - реестр требований, карточка изменения или план этапа.
- Если выбран технический вариант - описание решения, схема или карточка задачи.
- Если поменялись роли - матрица ответственности, карточка проекта или план управления коммуникациями.
- Если принято отдельное управленческое решение, которому нет подходящего места - короткий реестр решений проекта или, если это применимо, устав проекта.
Смысл такого распределения в том, что человеку не приходится проверять четыре источника, чтобы понять актуальное состояние. Если решение относится к требованиям, оно должно находиться там, где читают требования; если оно относится к ролям, его ищут там, где описана ответственность.
Отдельный реестр решений нужен только для того, что некуда встроить
На больших проектах отдельный реестр может быть полезен, когда регулярно появляются управленческие договоренности, которые плохо укладываются в ТЗ или план работ. Например, стороны решили временно не переносить исторические данные, приняли ограничение первой очереди или договорились использовать ручной обход до следующего релиза.
Такой реестр должен оставаться коротким: дата, решение, небольшой контекст, кто подтвердил и ссылка на связанный документ или обсуждение. Его задача заключается не в том, чтобы заменить остальные проектные материалы, а в том, чтобы быстро восстановить несколько ключевых поворотов проекта.
После длинного обсуждения полезно сформулировать итог прямо в чате
Есть простой прием, который сильно упрощает дальнейшую фиксацию: после обсуждения один из участников пишет отдельное итоговое сообщение, например: «Итого: для первой очереди оставляем один уровень согласования, второй не реализуем; аналитик вносит изменение в ТЗ». Такая формулировка позволяет всем участникам сразу проверить, одинаково ли они поняли разговор, а человеку, который обновляет документацию, уже не приходится перечитывать двадцать сообщений.
Нельзя превращать предположение в принятое решение
Переписка содержит много промежуточных формулировок, которые выглядят достаточно уверенно, хотя участники еще только обсуждают вариант. Фраза «думаю, можно оставить один уровень согласования» не равна утверждению «оставляем один уровень», поэтому при переносе разговора в документы важно не повысить статус предположения до согласованного требования.
Если из контекста непонятно, принято ли решение окончательно, нужно сначала получить короткое подтверждение: «Правильно понимаю, что фиксируем вариант с одним уровнем согласования?». Такое уточнение занимает несколько минут, но убирает гораздо более дорогой спор о том, кто и что имел в виду. И опять же, возвращаясь к предыдущему пункту, важно (как для заказчика, так и для исполнителя) зафиксировать принятые договоренности в явном виде.
Сохранять нужно управленческий след, а не доказательство того, что люди разговаривали
Подводя итог всего вышеописанного, хотелось бы отметить, что чаты и письма давно стали частью проектной деятельности, поэтому проблема заключается не в самом канале, а в том, что итог разговора иногда может остаться только внутри этой переписки. Чтобы такого не допускать, достаточно соблюдать простое правило: если переписка изменила требования, объем, ответственность, выбранный вариант, которые влияют на дальнейшую работу, итог нужно оперативно перенести в соответствующий проектный документ. Если же разговор остался промежуточным и после него ничего не изменилось, он может спокойно оставаться в переписке.
Так сохраняется нормальный управленческий след без склада скриншотов и выгрузок писем: история обсуждения остается в чате, подтверждение при необходимости можно найти, а действующее решение находится там, где его будут искать люди, которым нужно работать с проектом дальше.