Второй мозг для работы. Как приручить ChatGPT для проектов, писем и решений

Глава 1. Проект как отдельная комната

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

В обычной жизни проект редко похож на аккуратную схему из учебника. Чаще это папка с говорящим названием, еще одна папка с почти таким же названием, переписка в почте, два сообщения в мессенджере, заметка в телефоне, фотография доски после встречи, чей-то файл под именем final, потом final new, потом final really last. И где-то рядом человек, который уверен, что присылал вам нужную версию, хотя прислал ее совсем другому человеку. Вот в такой каше многие и живут. Не потому, что они неорганизованные. Просто проект растет быстрее, чем человек успевает раскладывать его по полкам.

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

Это звучит просто, но именно простота и ценна. Руководство, на которое я опираюсь, показывает проектный режим без лишнего театра: создать отдельный проект, положить туда файлы, добавить инструкции, вести разговоры внутри него, просить расписания, отчеты, бюджеты, материалы для команды. В этой логике помощник не заменяет менеджера. Он убирает мелкую мутную работу, из-за которой менеджер вечером сидит с красными глазами и пытается вспомнить, почему в таблице появились две разные даты запуска.

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

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

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

Я часто видел, как люди пытаются использовать помощника слишком поздно. Проект уже горит, сроки поехали, документы разъехались, команда устала, и тут кто-то говорит: может, спросим чат, что делать. Спросить можно, но чудес не будет. Инструмент сильнее всего в начале и в середине, когда еще есть время привести хаос в порядок. В конце он тоже полезен, например для отчета или списка срочных действий, но он уже не вернет те дни, которые потеряли из-за мутного старта.

Представьте запуск благотворительного забега в городском парке. Вроде бы простое дело: маршрут, регистрация, волонтеры, вода, медпункт, афиша, партнеры, разрешения. Но через неделю появляются детали. Нужно понять, кто встречает участников у входа. Где будет место для сумок. Кто отвечает за детей, которые пришли с родителями. Что делать, если дождь. Как объяснить маршрут людям, которые никогда не были в этом парке. Кто напишет посты. Кто распечатает номера. Кто привезет скотч, а кто уверен, что скотч всегда появляется сам.

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

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

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

Второй прием: храните список решений отдельно от списка задач. Это кажется мелочью, пока проект не начинает спорить сам с собой. Задача отвечает на вопрос, что надо сделать. Решение отвечает на вопрос, что уже принято и больше не обсуждается без причины. Мы запускаем не три тарифа, а два. Мы печатаем листовки до пятницы. Мы не меняем маршрут после согласования с парком. Мы показываем заказчику черновой вариант, а не финальную красоту. Если решения не записаны, команда снова и снова возвращается к одним и тем же развилкам.

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

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

Есть еще одна ловушка: люди кидают в проект все подряд и думают, что теперь порядок наступит сам. Не наступит. Папка с мусором остается папкой с мусором, даже если сверху сидит умный помощник. Иногда перед загрузкой надо сделать грубую уборку. Убрать старые версии, переименовать файлы, написать короткую заметку, какой документ главный. Да, это скучно. Но пять минут уборки часто экономят час споров. Машина не обязана угадывать, какой из трех файлов окончательный, если человек сам не знает.

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

Отдельно полезно задать стиль. Не литературный стиль, а стиль работы. Коротко или подробно. В виде таблицы или абзацев. Для руководителя или для команды. С вариантами или с одним лучшим предложением. Сначала факты, потом мнение. Сначала риски, потом план. Многие ответы кажутся плохими не потому, что в них мало смысла, а потому, что они не в том виде. Человеку нужен список на утреннюю встречу, а он получает длинное рассуждение. Или нужен аккуратный текст письма, а он получает сухую таблицу. Формат надо просить прямо.

В хорошей работе с проектным чатом есть ритм. Вы не пишете один огромный запрос и не ждете спасения. Вы ведете серию коротких разговоров. Сначала вводите контекст. Потом просите структуру. Потом проверяете. Потом добавляете файлы. Потом просите список дырок. Потом формируете расписание. Потом просите отчет. Потом снова исправляете. Такой разговор похож на работу с ассистентом, которому вы постепенно объясняете дело. За один заход он не станет частью команды. За несколько заходов может стать полезной памятью.

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

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

Когда чат предлагает расписание, не принимайте его сразу. Он не знает вашей команды так, как знаете вы. Он может поставить на один день три задачи для одного человека. Он может не учитывать, что бухгалтер отвечает только по вторникам, а дизайнер уходит в отпуск. Он может забыть, что согласование у юриста занимает не час, а два дня, потому что юрист тоже живой человек. Поэтому после первого графика надо задать второй запрос: проверь расписание как человек, который знает, что люди заняты, устают и отвечают не сразу; добавь запас; покажи перегруженные места.

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

Бюджет в проекте часто портится не из-за больших решений, а из-за мелочей, которые никто не записал. Доставка, упаковка, запасные кабели, печать, комиссии, платные шрифты, дополнительные часы подрядчика, кофе для волонтеров, такси после поздней встречи. По отдельности смешно. Вместе неприятно. Попросите помощника пройтись по смете как вредный администратор: какие расходы могли забыть; какие расходы вырастут при задержке; где нужен запас; какие позиции лучше подтвердить письменно. Это не заменит бухгалтера, но поможет поймать очевидные дыры.

В проектном управлении есть скучная, но спасительная привычка: каждый пункт должен иметь владельца. Не отдел, не команда, не все вместе, а конкретный человек. Если задача ничья, она лежит спокойно, пока не начнется паника. Чат может после списка задач добавить колонку: владелец, срок, зависимость, признак готовности. Последняя колонка особенно полезна. Задача закончена не тогда, когда кто-то сказал готово, а когда есть проверяемый результат. Текст опубликован. Счет оплачен. Файл отправлен. Маршрут согласован. Таблица обновлена.

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

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

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

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

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

При этом не стоит превращать помощника в почтовый пулемет. Если он за вас пишет всем подряд, а вы не успеваете думать, проект быстро заполняется аккуратными, но пустыми сообщениями. Перед каждым письмом спросите себя: что должно измениться после отправки? Человек должен подтвердить дату, прислать файл, выбрать вариант, оплатить счет, предупредить о риске. Если письму нельзя назначить действие, возможно, его не надо отправлять. Чат может помочь сформулировать просьбу, но смысл просьбы должен быть ваш.

Хороший проектный чат удобен еще и тем, что в нем можно держать историю сомнений. Не только решения, но и причины, почему отказались от других вариантов. Через месяц это спасает. Кто-то спросит: почему мы не взяли более дешевый зал? И вы не будете вспоминать по лицам на встрече. Вы попросите сводку: какие варианты площадок рассматривались и почему выбрали этот. Если вы раньше записали причины, помощник быстро соберет ответ. Если не записали, он может только красиво предположить, а это уже опасно.

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

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

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

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

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

В ревизии важно отмечать устаревшее. Старые решения опасны тем, что выглядят как настоящие. В проекте лежит документ с датой первой версии, кто-то находит его через месяц и действует по нему. Потом выясняется, что все поменялось. Просите чат в сводках отдельно писать: что больше не действует. Это грубая, но сильная защита. Старое надо не просто забыть. Его надо пометить старым.

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

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

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

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

Если у вас маленький проект, не усложняйте. Достаточно одного чата, одной сводки, одного списка задач и одного правила: все важные решения записывать. Не надо строить систему управления космическим кораблем для ремонта ванной или семейной поездки. Искусственный помощник должен уменьшать тяжесть, а не добавлять новый слой работы. Если вы тратите больше времени на обслуживание системы, чем на сам проект, система раздулась.

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

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

Можно сделать вариант для сайта. Ты помощник проекта по запуску интернет-витрины. Главная цель - открыть рабочую версию к указанной дате, а не собрать идеальный бренд. Следи за страницами, текстами, фото, оплатой, доставкой, юридическими текстами и проверкой заказов. Все предложения дели на обязательно к запуску и можно после запуска. Когда я добавляю новый список задач, ищи перегруженных людей и зависимости. В отчетах не прячь риски за мягкими словами. Это уже похоже на нормального координатора.

Можно сделать вариант для семейного дела. Ты помощник по переезду. Помоги не забыть документы, коробки, оплату, адреса, детей, животных, отключение услуг, передачу ключей, уборку, транспорт, аптечку и вещи на первые сутки. Не предлагай дорогие решения без просьбы. Делай списки короткими. Каждый день показывай только ближайшие шаги. Если я перегружаю день, скажи прямо. Такой помощник не станет родственником, но может избавить семью от трех вечерних ссор из-за забытых коробок.

Самый частый вопрос: где грань между полезным и лишним? Я бы отвечал так: если после работы с чатом проект стал яснее, вы на верном пути. Если появились новые вкладки, новые списки, новые правила, но никто не понимает, что делать завтра, вы ушли в украшение системы. У проекта есть простой судья - следующий шаг. Хорошая работа с помощником делает следующий шаг видимым. Кто делает, к какому сроку, что значит готово. Все остальное вторично.

Есть еще человеческий эффект. Когда проект разложен на экране, у людей меньше поводов обвинять друг друга по памяти. Видно, что обещали. Видно, что не решено. Видно, где зависло. Это не делает команду добрее, но делает разговор честнее в обычном смысле: меньше ухода от фактов, больше предмета. Иногда одного этого хватает, чтобы снизить шум. Люди спорят не о том, кто что имел в виду, а о записанной задаче.