Crear una lista de verificación para el traspaso de proyectos con responsables, ubicaciones y asuntos abiertos

01Definir qué debe responder cada elemento del traspaso

Una lista de verificación útil para el traspaso debe indicar a la siguiente persona qué es el elemento, quién es responsable, dónde se encuentra el material relevante, si el elemento está completo y qué sigue sin resolverse. Una nota como files are on the drive normalmente no es suficientemente específica para alguien que se incorpore al proyecto más adelante.

Este ejemplo utiliza seis fields: item_id, handover_item, owner, location, status y open_issue. status puede ser READY u OPEN. Los READY items deben tener vacío el field open_issue. Los OPEN items deben explicar qué sigue sin resolverse.

02Crear una lista sintética de traspaso de proyecto

La siguiente checklist es sintética y fue creada específicamente para este artículo. Guárdala como handover_items.csv. Contiene cinco handover items, con dos problemas deliberados que deberían detectarse antes de aceptar la checklist.

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án estructuralmente completos. H004 no tiene owner aunque está marcado como READY. H005 describe un open issue pero no tiene location para la bug list. Por tanto, el ejemplo contiene dos validation problems.

03Revisar primero la lista manualmente

Los totales esperados son 5 checklist items, 3 valid items y 2 invalid items. Hay 2 OPEN items, H003 y H005, y ambos contienen issue descriptions no vacías. Por tanto, los problemas de este ejemplo no son textos de incidencia ausentes, sino información ausente de responsibility y location.

Esta distinción importa porque un proyecto puede tener open issues legítimos y aun así estar listo para handover si el trabajo no resuelto está claramente descrito, asignado y localizable.

04Validar la lista de traspaso con Python

Guarda el script siguiente como check_handover.py. Comprueba required columns, duplicate IDs, owners, locations, allowed status values y si el field open_issue es coherente con el status. Escribe un review report sin modificar la 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()

05Comparar el informe de revisión esperado

Como el CSV header es row 1, H004 es la physical row 5 y H005 es la physical row 6. El review report debería contener exactamente dos issue rows.

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

La salida de consola esperada que aparece a continuación se obtuvo manualmente a partir de la synthetic checklist y el script. No es un execution log capturado.

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

06Comprobar algo más que la existencia de archivos

• Confirma que cada item tenga un owner claramente identificado, aunque ownership vaya a cambiar después del handover.
• Abre cada location indicada y verifica que la siguiente persona pueda acceder realmente a ella.
• Para los OPEN items, indica el unresolved issue, current status y next expected action.
• Comprueba que los READY items no oculten unresolved work en comments, chat messages o private notes.
• Registra credentials mediante un password o access-management process aprobado, en lugar de poner secrets en la checklist.
• Ejecuta de nuevo el script sin cambiar OUTPUT_DIR. Debería detenerse con FileExistsError en lugar de sustituir la review anterior.

Un path puede estar presente sintácticamente y seguir siendo inútil si faltan permissions o si el file referenciado está desactualizado. Por tanto, la checklist debe ser revisada por la persona que recibe el proyecto, no únicamente por quien lo abandona.

07Reconocer fallos comunes en un traspaso

No marques un item como READY únicamente porque exista un file. Un handover utilizable también depende del access, documentación actualizada, ownership y de que la persona receptora entienda las unresolved decisions.

08Ampliar la lista para proyectos más grandes

Un project real puede necesitar fields adicionales como receiving_owner, due_date, repository branch, access_required, last_verified_date, dependency, contact person, equipment location, approval status y next milestone. Añade fields únicamente cuando mejoren la claridad de la transferencia.

Este script valida completeness e internal consistency, no si una location es accesible ni si una open issue description es técnicamente correcta. Access checks, file freshness, repository state, equipment condition y knowledge transfer requieren una review separada.

La checklist debe versionarse o fecharse y conservarse con los project records. Después de que la persona receptora verifique el handover, registra esa acceptance por separado en lugar de reescribir silenciosamente el original transfer state.

Registro de ejecución y verificación

2026-09-20 · ejemplo revisado manualmente · objetivo: Python 3.12 · biblioteca estándar: csv, pathlib · sin ejecución

• Se contaron manualmente 5 synthetic handover items y 2 items con status OPEN.
• Se comprobaron manualmente H001, H002 y H003 como estructuralmente válidos.
• Se identificó que H004 carece de owner y H005 carece de location.
• Se confirmó que ambos OPEN items contienen open_issue descriptions no vacías.
• Se obtuvieron las physical CSV rows esperadas como row 5 para H004 y row 6 para H005.
• Se revisó el script para required headers, duplicate IDs, owner and location checks, status consistency, output collision protection y conservación del CSV original.

Criterios de redacción y verificación de todo el sitio

Fuentes de referencia

Las explicaciones y los ejemplos son de elaboración propia. Puedes consultar los comportamientos y conceptos relacionados en las siguientes fuentes oficiales.

• Documentación oficial de Python 3.12 · csv ↗ (New tab)
• Documentación oficial de Python 3.12 · pathlib ↗ (New tab)