Crie uma lista de verificação de passagem de projeto com responsáveis, locais e pendências
Transforme notas de passagem de projeto em uma lista estruturada que registre o que precisa ser transferido, quem é responsável, onde está armazenado e o que permanece sem solução. Um pequeno exemplo sintético mostra como detectar responsáveis, locais e detalhes de pendências ausentes antes da passagem.
Conteúdo verificado 2026.09.20Inclui código de exemplo
Ver o sumário
A tradução foi feita com IA. Confira o código, as unidades e os valores junto com o original. A revisão por falantes nativos de cada idioma ainda não foi concluída. English
Para quem éEste guia é voltado a equipes que transferem um projeto entre pessoas e precisam de uma lista de verificação que deixe explícitos ownership, locais dos arquivos e trabalho não resolvido.
Preparação
Python 3.12 e um comando de terminal que inicie essa versão.
Um editor de texto ou programa de planilhas capaz de salvar arquivos CSV em UTF-8.
Uma pasta de trabalho em que o script possa criar uma nova pasta dentro de outputs.
É necessária apenas a biblioteca padrão do Python: csv e pathlib.
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.
csv
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
item_id
Resultado esperado
Motivo
H001
PASS
Owner e location estão presentes; READY não tem open issue
H002
PASS
Owner e location estão presentes; READY não tem open issue
H003
PASS
O OPEN item inclui owner, location e unresolved issue
H004
FAIL
Owner ausente
H005
FAIL
Location ausente
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.
python
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.
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
Entrada fraca de handover
Por que é insuficiente
Owner: Team
Responsibility fica pouco clara se nenhuma person ou defined role for responsável.
Location: Drive
A pessoa que recebe ainda precisa procurar o file ou folder real.
Status: Done
Done é ambíguo a menos que a definição de completion da equipe esteja clara.
Open issue: Needs work
O problem e a next action não são específicos o suficiente.
Credentials included in CSV
Uma checklist geral de handover não é um local apropriado para passwords ou secrets.
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.
A saída do console correspondeu exatamente: 5 itens de checklist, 2 itens em aberto, 2 problemas de validação, 2 itens afetados e o caminho de relatório informado.
O relatório gerado continha exatamente row 5 H004 MISSING_OWNER e row 6 H005 MISSING_LOCATION.
O arquivo de origem handover_items.csv permaneceu idêntico byte por byte após a execução.
A única saída do artigo gerada foi outputs/handover_check_result/handover_review.csv.
Uma segunda execução foi interrompida com FileExistsError porque outputs/handover_check_result já existia, portanto o relatório anterior não foi sobrescrito.
Limites da verificação
O ambiente Python emitiu no stderr um aviso não relacionado de aquecimento do ambiente de planilhas; isso não afetou a execução nem os resultados do script.
As URLs de documentação externa não foram verificadas porque a tarefa de verificação se concentrava no exemplo executável do artigo.
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.
Em vez de parar em mais um resumo da reunião, separe o trabalho acordado dos itens em aberto. Transforme notas sintéticas de reunião em uma lista com responsáveis, prazos, entregáveis e evidências de conclusão, e escreva uma solicitação para IA que ajude na mesma tarefa.
Gerencie cada artigo como uma linha e separe redação, revisão, aprovação e publicação. Abrange importação de um CSV local, listas suspensas, filter views, permissões de compartilhamento e histórico de versões, além de configurar um fluxo para atualizar manualmente os arquivos do site após a aprovação.
Defina uma convenção simples de nomes de arquivos para a equipe, teste-a em uma pasta sintética e gere um relatório de revisão sem renomear nem excluir nada. O verificador separa erros estruturais, datas inválidas e extensões não suportadas.
Transforme release notes brutas em uma entrada de changelog que separe mudanças de ações obrigatórias do usuário e etapas de verificação. Uma atualização sintética de software mostra como tornar uma nota de versão útil para alguém que não fez a alteração.