Поиск пропущенных задач и зависимостей в плане проекта с Gemini

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

• согласование;
• передача работ подрядчику;
• доступ к данным;
• юридическая проверка;
• передача материалов;
• обучение;
• тестирование;
• предварительное завершение работ другой командой.

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

С помощью ИИ можно заранее проверить, учтены ли такие условия в плане.

Проверку можно провести в несколько этапов:

Метод из учебных материалов Google

В основе статьи — практическое задание из официального курса Google «AI for Brainstorming and Planning» на Coursera. Оно посвящено поиску пропущенных работ и связей между задачами проекта. Gemini сравнивает предоставленные планы и помогает заметить, что в них не учтено. Затем найденные пробелы нужно проверить с командой. Подтверждённые задачи добавляют в график с нужными сроками и ответственными. Первые три шага взяты из задания. Затем мы добавляем проверки, которые помогают разобраться в рисках реального проекта.

Шаг 1. Найдите пропущенные зависимости

Передайте Gemini документы, в которых описаны разные части проекта.

Например:

• краткое описание целей и задач проекта;
• записка о запуске;
• график со сроками, отсчитанными от даты завершения проекта;
• план этапов;
• план выполнения работ;
• документ с требованиями.

Затем попросите Gemini сравнить их.

You are a [persona].

My company is launching a [product, service or initiative].

I've attached [document 1] and [document 2].

Are there any dependencies missing from the plan?

Например:

You are a project manager.

My company is launching a new subscription service.

I've attached the launch memo and launch workback schedule.

Are there any dependencies missing from the plan?

В одном документе может быть требование, которое забыли внести в другой. Сравнение помогает заметить такие расхождения. Основной вопрос:

Что такое зависимость?

Зависимость — это условие для начала или завершения работы. Например, чтобы выполнить задачу, нужно получить согласование, данные или результат другой команды.

Например:

Чтобы запустить кампанию, сначала нужно выполнить условие:

А для согласования сообщений нужно завершить предыдущий этап:

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

Gemini помогает найти такие связи, сопоставляя предоставленные документы.

Шаг 2. Оцените последствия пропуска

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

Let's focus on [missing dependency from the previous response].

How do they affect the [overall project goal]?

Например:

Let's focus on legal approval and final creative asset delivery.

How do they affect the product launch?

После поиска пробелов нужно оценить их последствия:

Возможные последствия:

• следующая задача не сможет начаться;
• этап придётся перенести;
• часть работы нужно будет переделать;
• на согласование останется меньше времени;
• подрядчик не успеет передать результат;
• часть запланированных работ придётся исключить из запуска.

Проверьте предложенные последствия с командой: модель может не знать часть условий проекта.

Шаг 3. Добавьте недостающую работу в график

После подтверждения пробела включите недостающие задачи в план.

Create a timeline listing key milestones for [the missing dependency].

Flag what might be missing from my current plan.

Например:

Create a timeline listing key milestones for legal review and approval.

Flag what might be missing from my current plan.

В результате предположение о пропуске станет перечнем работ, которые можно проверить и назначить ответственным. Одного предположения о пробеле недостаточно:

После проверки добавьте недостающую работу в график:

Теперь можно рассчитать сроки этих работ от даты запуска.

Что ИИ может узнать о зависимостях

ИИ видит только предоставленные ему сведения. О внутренних договорённостях компании он может не знать.

В документе могут не упоминаться:

• участник, который должен согласовать работу;
• срок поставки;
• внутренняя проверка безопасности;
• требования к закупке;
• доступность нужного сотрудника.

Gemini может выявить:

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

Часть найденных связей будет лишь предположениями: их нужно подтвердить у ответственных. В ответе должно быть ясно, к какой группе относится каждая находка:

Дополнение M2B2: запрашивайте подтверждения из документов

Попросите Gemini показывать, в каком документе он нашёл основание для замечания.

You are reviewing the attached project-planning documents.

My goal is to identify missing dependencies before execution begins.

Compare all attached documents against each other.

Create a dependency review with these columns:

- dependency
- task or milestone that depends on it
- where it appears in the documents
- whether it is explicitly scheduled
- responsible owner, if stated
- due date, if stated
- status

Use exactly these status categories:

- Explicit and planned
- Explicit but not scheduled
- Implied
- Potentially missing
- Cannot determine

Rules:

1. Base factual statements on the attached documents.
2. Do not invent owners, dates, or requirements.
3. If you infer a dependency from normal project logic rather than the documents, label it "Potentially missing".
4. Explain the reasoning for every inferred dependency.
5. Highlight contradictions between documents.

Do not update the timeline yet.

Так будет видно, на чём основан каждый вывод и что ещё нужно подтвердить.

Какие зависимости подтверждены, а какие пока предполагаются

Представьте, что в записке проекта сказано:

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

Другой пример: в проекте подключают внешнюю систему, но ни в одном документе не упомянута проверка безопасности.

Gemini может предположить:

Документы это требование не подтверждают. В этом случае речь идёт о другом статусе:

Требование из документа и предположение модели должны быть помечены по-разному.

Проверяйте несколько типов зависимостей

Чтобы не упустить важное, отдельно проверьте несколько условий выполнения работ.

Порядок работ

Задача B не может начаться до завершения задачи A.

Согласования

Работа не может продолжиться без чьего-либо согласования.

Ресурсы

Нужны свободный сотрудник или команда, бюджет, оборудование либо доступ к рабочей системе.

Технические зависимости

Прежде чем начать работу, нужно подготовить данные, настроить связь между программами или запустить приложение.

Внешние зависимости

Часть работ зависит от подрядчика, поставщика, партнёра, регулятора или клиента.

Информационные зависимости

Задачу нельзя выполнить, пока не принято решение или не получены нужные сведения.

Подготовка к запуску

К запуску сотрудники должны быть обучены, инструкции готовы, а поддержка — знать, как принимать работу.

Попросите Gemini отдельно проверить каждый тип зависимостей.

Review the project for missing dependencies in these categories:

- sequencing
- approvals
- people and resources
- technical
- vendors or external parties
- data or information
- operations and handoff

For each category:

1. List dependencies explicitly documented.
2. List dependencies that appear implied.
3. List potential gaps that require confirmation.

Do not assume a potential dependency actually applies unless the documents support it.

Дополнение M2B2: отделите последствия от вероятности

После выявления зависимости оцените, на что она может повлиять. Даже серьёзные последствия не показывают, насколько вероятна сама задержка.

Легко спросить ИИ:

Если нет данных о похожих проектах или другого надёжного основания, число вроде 70% будет предположением модели.

Лучше попросить модель разобрать последствия и недостающую информацию:

Assess the potential impact of this dependency:

[dependency]

Based only on the project documents, explain:

1. Which tasks or milestones rely on it.
2. What could happen if it is delayed.
3. Whether the delay could propagate to later milestones.
4. What decisions would become blocked.
5. What evidence would be needed to estimate likelihood.

Classify potential impact as:

- Low
- Medium
- High
- Cannot determine

Explain the basis for the classification.

Do not assign a numerical probability unless the supplied data supports one.

Так вы получите описание последствий и список сведений, которые нужны для оценки риска.

Проверьте последствия за пределами графика

Пропущенная зависимость может повлиять не только на график.

Например:

Для более полной проверки можно использовать такой запрос:

For this dependency, assess potential impact on:

- schedule
- cost
- scope
- quality
- compliance
- operations
- customer experience

Use only categories that are relevant.

For each one, explain the mechanism of impact.

Do not manufacture costs or delay durations.

Проследите всю последовательность работ

Один пропущенный пункт может затронуть несколько последующих задач. Например:

Пройдите по всей последовательности: какие работы придётся перенести, если предыдущая задержится?

Спросите:

Trace the downstream dependency chain for:

[dependency]

Show:

dependency
→ directly blocked task
→ next affected milestone
→ any further downstream work

For every connection, state whether it is:

- explicitly documented
- logically inferred

Do not infer dates that are not present in the project plan.

Это особенно полезно в больших планах, где последствия одной задержки трудно увидеть сразу.

Ищите противоречия между документами

Сравнение планов также помогает найти противоречия в сроках и условиях.

Например:

Если читать документы отдельно, это противоречие легко пропустить. Используйте:

Compare all dates, milestones, owners, and dependencies across the attached documents.

Create a contradiction report with:

- topic
- document A
- document B
- conflicting information
- why the conflict matters
- clarification required

Do not resolve the conflict by choosing one version.

Flag it for human confirmation.

Последняя инструкция просит сохранить расхождение между документами. Выбрать верную дату и исправить план должна команда.

Дополнение M2B2: составьте график недостающих работ

После проверки и подтверждения пробелов обновите график.

Create an updated workback timeline for the confirmed missing dependency:

[dependency]

Include:

- milestone
- prerequisite
- owner, only if known
- duration, only if known
- target date, only if supported by the project information
- output or completion criteria
- downstream milestone affected

If a duration or date is unknown, write "TBD".

Do not invent timing to make the schedule look complete.

Also identify:

- steps that need an owner;
- milestones that need dates;
- unresolved approvals;
- external dependencies;
- points where the schedule has no buffer.

Keep inferred items clearly labeled.

Проверьте предложенные задачи и сроки с командой, затем включите их в план проекта.

Добавьте критерии завершения

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

К нему полезно добавить критерий завершения:

Так видно, какой результат нужно получить, прежде чем считать этап завершённым.

Можно спросить:

For each dependency milestone, define a clear completion criterion.

The criterion should answer:

"What evidence tells the project team that this dependency is actually complete?"

Do not invent formal approval requirements that are not supported by the project documents.

Flag anything that needs clarification.

Спросите, кто кого ждёт

Проверьте, кто передаёт результат работы и кто должен его получить.

Create a dependency handoff table.

For every major dependency include:

- upstream owner
- deliverable
- downstream owner
- next task
- required date
- status
- unresolved issue

Use "Unknown" where the project documents do not identify an owner or date.

Do not fill missing ownership with assumptions.

Эта проверка помогает найти ситуацию:

Определите, как снизить подтверждённый риск

Когда зависимость подтверждена, можно обсуждать способы снизить риск.

Например:

For each confirmed high-impact dependency, suggest possible mitigation options.

Separate them into:

- prevent the dependency from being late;
- detect problems earlier;
- reduce downstream impact if it is late.

For every suggestion, label it as a proposed mitigation, not an existing part of the project plan.

Do not assume additional budget, staff, or authority unless I provide it.

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

Превратите проверку в реестр рисков

Соберите подтверждённые риски в таблицу: что может задержаться, кто за это отвечает и что нужно сделать.

Gemini может помочь создать эту структуру:

Using only confirmed risks and dependencies from our review, create a project risk register.

Include:

- risk or dependency
- affected milestone
- potential impact
- owner
- target date
- mitigation
- status
- unresolved question

Do not include speculative risks unless they are clearly labeled "Needs confirmation".

Представьте, почему проект мог не достичь цели

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

Попросите модель назвать события, которые могли бы привести к такому исходу, и проверьте их по плану.

Run a pre-mortem on this project plan.

Scenario:

The project missed its planned launch date.

Using the attached project documents, identify plausible contributing factors related to:

- missing dependencies;
- sequencing;
- approvals;
- handoffs;
- resources;
- external parties;
- testing;
- operational readiness.

Separate:

1. Risks directly supported by the documents.
2. Plausible risks that require confirmation.

Do not invent events and present them as things that actually happened.

For each item, suggest what could be checked now before execution begins.

Такой разбор помогает найти вопросы, которые могли остаться без внимания при обычном планировании.

Шаблон промпта для проверки проектных рисков

В одном запросе можно объединить весь порядок проверки:

You are helping me pressure-test a project plan before execution.

I have attached the available planning documents.

Do not rewrite the plan immediately.

Work in stages.

STAGE 1 — EXTRACT

Identify:

- milestones
- dates
- owners
- deliverables
- approvals
- dependencies

Show which document each item comes from.

Do not invent missing values.

STAGE 2 — CROSS-CHECK

Compare the documents.

Flag:

- contradictory dates
- inconsistent milestones
- missing owners
- unclear handoffs
- prerequisites that are mentioned but not scheduled

Do not resolve contradictions automatically.

STAGE 3 — DEPENDENCY REVIEW

Review these categories:

- sequence dependencies
- approvals
- resources
- technical dependencies
- external parties
- data and information
- operational readiness

Classify each finding as:

- Explicit and planned
- Explicit but not scheduled
- Implied
- Potentially missing
- Cannot determine

STAGE 4 — IMPACT

For every confirmed or potentially missing dependency, identify:

- affected milestone
- downstream tasks
- possible schedule impact
- possible cost, scope, quality, compliance, or operational impact

Do not assign numerical probability unless supporting data exists.

STAGE 5 — GAPS

List what still needs confirmation from the project team.

Examples:

- owner
- timing
- required approval
- lead time
- completion criteria

STAGE 6 — TIMELINE

For confirmed gaps only, propose milestones that should be added to the project timeline.

Use "TBD" for unknown dates or durations.

Do not silently fill gaps.

STAGE 7 — RISK REGISTER

Create a final table containing:

- dependency or risk
- affected milestone
- impact
- owner
- target date
- mitigation
- status
- unresolved question

Keep assumptions visibly separate from documented facts.

Этот запрос задаёт порядок проверки и требует оснований для выводов. В общем вопросе таких условий нет:

Что остаётся за пределами проверки ИИ

Gemini может проверить только ту информацию, которая ему доступна.

Допустим, финансовый отдел требует оформить заказ на закупку при превышении определённой суммы, но в документах проекта этого правила нет. Gemini может предположить, что потребуется согласование закупки, но может и пропустить его. Чтобы учесть ваш внутренний порядок работы, модели нужен источник:

• описание в загруженных документах;
• ваше пояснение;
• другой подключённый материал с нужной информацией.

Результаты ИИ нужно сопоставлять с:

• оценкой руководителя проекта;
• комментариями участников проекта;
• технической проверкой;
• юридической проверкой и требованиями к проекту;
• подтверждением подрядчика;
• знаниями команды о работе организации.

Ответственные за проект проверяют результаты и решают, что изменить в плане.

Проверяйте большие комплекты документов по частям

Gemini Apps позволяет работать с несколькими загруженными файлами. Но если материалов слишком много, модель может упустить детали и связи между ними. Из-за этого в проверке могут остаться незамеченными важные условия начала работ. Например, условие в одном документе может определять срок этапа в другом.

Для большого проекта полезно:

• выбрать документы, которые относятся к проверяемому вопросу;
• разбить проверку по этапам проекта;
• запросить ссылки на источники;
• вручную проверить значимые выводы.

Так будет проще проследить связи между задачами и проверить их по документам.

Что должно попасть в обновлённый план

Общего вопроса о рисках недостаточно:

Проверка начинается со сравнения документов:

При проверке нужно сопоставить:

• Этапы: что нужно выполнить.
• Зависимости: что должно быть готово до начала следующей работы.
• Ответственных: кто обеспечивает результат.
• Сроки: когда работа должна быть закончена.
• Критерии завершения: по каким признакам результат готов.

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

Если в плане чего-то не хватает, сохраняйте пробел видимым:

Если ответственный неизвестен, оставьте поле незаполненным. Если дата не согласована, укажите «Будет определено». Предполагаемую зависимость так и пометьте. Эти пробелы покажут команде, что нужно уточнить перед обновлением плана.

Источник

На основе официального курса Google «AI for Brainstorming and Planning» на Coursera.