Crie uma lista de verificação de passagem de projeto com responsáveis, locais e pendências

01Defina o que cada item da passagem deve responder

Uma checklist útil de handover deve informar à próxima pessoa o que é o item, quem é responsável por ele, onde está o material relevante, se o item está concluído e o que permanece sem solução. Uma nota como files are on the drive geralmente não é específica o suficiente para alguém que entrar no project mais tarde.

Este exemplo usa seis fields: item_id, handover_item, owner, location, status e open_issue. status pode ser READY ou OPEN. READY items devem ter o field open_issue vazio. OPEN items devem explicar o que permanece sem solução.

02Crie uma checklist sintética de passagem de projeto

A checklist a seguir é sintética e foi criada especificamente para este artigo. Salve-a como handover_items.csv. Ela contém cinco handover items, com dois problemas deliberados que devem ser detectados antes de a checklist ser aceita.

item_id,handover_item,owner,location,status,open_issue
H001,Source code,Min,repo/main,READY,
H002,Test dataset,Jae,shared-drive/project/data,READY,
H003,Calibration procedure,Min,shared-drive/project/docs/calibration.pdf,OPEN,Final approval is still pending
H004,Supplier contact list,,shared-drive/project/admin/suppliers.csv,READY,
H005,Open bug list,Jae,,OPEN,Two export bugs remain under review

H001 a H003 estão estruturalmente completos. H004 não tem owner, embora esteja marcado como READY. H005 descreve um open issue, mas não tem location para a bug list. Portanto, o exemplo contém dois validation problems.

03Revise primeiro a checklist manualmente

Os totais esperados são 5 checklist items, 3 valid items e 2 invalid items. Há 2 OPEN items, H003 e H005, e ambos contêm issue descriptions não vazias. Portanto, os problemas deste exemplo não são falta de issue text, mas falta de responsibility e location information.

Essa distinção é importante porque um project pode ter open issues legítimos e ainda estar pronto para handover se o trabalho não resolvido estiver claramente descrito, atribuído e localizável.

04Valide a checklist de passagem com Python

Salve o script a seguir como check_handover.py. Ele verifica required columns, duplicate IDs, owners, locations, allowed status values e se o field open_issue é consistente com o status. Ele grava um review report sem alterar a checklist original.

import csv
from pathlib import Path

SOURCE = Path("handover_items.csv")
OUTPUT_DIR = Path("outputs") / "handover_check_result"
REPORT = OUTPUT_DIR / "handover_review.csv"
REQUIRED_COLUMNS = [
    "item_id", "handover_item", "owner", "location", "status", "open_issue"
]
VALID_STATUS = {"READY", "OPEN"}


def add_issue(issues, row_number, item_id, issue):
    issues.append({
        "row_number": row_number,
        "item_id": item_id,
        "issue": issue,
    })


def main() -> None:
    if not SOURCE.is_file():
        raise FileNotFoundError(f"Source CSV not found: {SOURCE}")
    if OUTPUT_DIR.exists():
        raise FileExistsError(f"Output folder already exists: {OUTPUT_DIR}")

    issues = []
    seen_ids = set()
    item_count = 0
    open_count = 0

    with SOURCE.open("r", encoding="utf-8-sig", newline="") as stream:
        reader = csv.DictReader(stream)
        if reader.fieldnames != REQUIRED_COLUMNS:
            raise ValueError(
                f"Header mismatch. Expected {REQUIRED_COLUMNS}, got {reader.fieldnames}."
            )

        for row_number, row in enumerate(reader, start=2):
            item_count += 1
            item_id = row["item_id"].strip()
            handover_item = row["handover_item"].strip()
            owner = row["owner"].strip()
            location = row["location"].strip()
            status = row["status"].strip()
            open_issue = row["open_issue"].strip()

            if not item_id:
                add_issue(issues, row_number, item_id, "MISSING_ITEM_ID")
            elif item_id in seen_ids:
                add_issue(issues, row_number, item_id, "DUPLICATE_ITEM_ID")
            seen_ids.add(item_id)

            if not handover_item:
                add_issue(issues, row_number, item_id, "MISSING_ITEM_NAME")
            if not owner:
                add_issue(issues, row_number, item_id, "MISSING_OWNER")
            if not location:
                add_issue(issues, row_number, item_id, "MISSING_LOCATION")
            if status not in VALID_STATUS:
                add_issue(issues, row_number, item_id, "INVALID_STATUS")
            elif status == "OPEN":
                open_count += 1
                if not open_issue:
                    add_issue(issues, row_number, item_id, "MISSING_OPEN_ISSUE")
            elif open_issue:
                add_issue(issues, row_number, item_id, "READY_HAS_OPEN_ISSUE")

    OUTPUT_DIR.parent.mkdir(parents=True, exist_ok=True)
    OUTPUT_DIR.mkdir()
    with REPORT.open("x", encoding="utf-8", newline="") as stream:
        writer = csv.DictWriter(
            stream,
            fieldnames=["row_number", "item_id", "issue"],
        )
        writer.writeheader()
        writer.writerows(issues)

    affected_items = len({row["item_id"] for row in issues})
    print(f"Checklist items: {item_count}.")
    print(f"Open items: {open_count}.")
    print(f"Validation issues: {len(issues)}.")
    print(f"Affected items: {affected_items}.")
    print(f"Report: {REPORT.as_posix()}")


if __name__ == "__main__":
    main()

05Compare o relatório de revisão esperado

Como o CSV header é row 1, H004 é a physical row 5 e H005 é a physical row 6. O review report deve conter exatamente duas issue rows.

row_number,item_id,issue
5,H004,MISSING_OWNER
6,H005,MISSING_LOCATION

A saída esperada do console abaixo foi derivada manualmente a partir da synthetic checklist e do script. Não é um execution log capturado.

Checklist items: 5.
Open items: 2.
Validation issues: 2.
Affected items: 2.
Report: outputs/handover_check_result/handover_review.csv

06Verifique mais do que a presença dos arquivos

• Confirme que cada item tenha um owner claramente identificado, mesmo que ownership mude após o handover.
• Abra cada location listada e verifique se a próxima pessoa realmente consegue acessá-la.
• Para OPEN items, informe unresolved issue, current status e next expected action.
• Verifique se READY items não escondem unresolved work em comments, chat messages ou private notes.
• Registre credentials por meio de um password ou access-management process aprovado, em vez de colocar secrets na checklist.
• Execute o script novamente sem alterar OUTPUT_DIR. Ele deve parar com FileExistsError em vez de substituir a review anterior.

Um path pode estar sintaticamente presente e ainda ser inútil se faltarem permissions ou se o file referenciado estiver desatualizado. Portanto, a checklist deve ser revisada pela pessoa que recebe o project, e não apenas por quem está saindo.

07Reconheça falhas comuns de passagem

Não marque um item como READY apenas porque existe um file. Um handover utilizável também depende de access, documentação atualizada, ownership e de a pessoa que recebe compreender unresolved decisions.

08Expanda a checklist para projetos maiores

Um project real pode precisar de fields adicionais, como receiving_owner, due_date, repository branch, access_required, last_verified_date, dependency, contact person, equipment location, approval status e next milestone. Adicione fields apenas quando melhorarem a clareza da transferência.

Este script valida completeness e internal consistency, não se uma location é acessível ou se uma open issue description está tecnicamente correta. Access checks, file freshness, repository state, equipment condition e knowledge transfer exigem uma review separada.

A checklist deve ser versionada ou datada e mantida com os project records. Depois que a pessoa que recebe verificar o handover, registre essa acceptance separadamente em vez de reescrever silenciosamente o original transfer state.

Registro de execução e verificação

2026-09-20 · exemplo verificado manualmente · alvo: Python 3.12 · biblioteca padrão: csv, pathlib · sem execução

• Foram contados manualmente 5 synthetic handover items e 2 items com status OPEN.
• H001, H002 e H003 foram verificados manualmente como estruturalmente válidos.
• Foi identificado que H004 não tem owner e H005 não tem location.
• Foi confirmado que ambos os OPEN items contêm open_issue descriptions não vazias.
• As physical CSV rows esperadas foram derivadas como row 5 para H004 e row 6 para H005.
• O script foi inspecionado quanto a required headers, duplicate IDs, owner and location checks, status consistency, output collision protection e preservação do CSV original.

Princípios de redação e verificação de todo o site

Fontes de referência

As explicações e os exemplos são de elaboração própria. Os comportamentos e conceitos relacionados podem ser consultados nas fontes oficiais abaixo.

• Documentação oficial do Python 3.12 · csv ↗ (New tab)
• Documentação oficial do Python 3.12 · pathlib ↗ (New tab)