Projectafsluiting

Uit De Vliegende Brigade
(Doorverwezen vanaf Projectafronding)
Ga naar: navigatie, zoeken

Projectafsluiting, projectbeëindiging, projectafronding, project completion of project conclusion is verbazend lastige materie. Maar nu niet meer, dankzij dit artikel!

De uitdaging lijkt te zijn, om alle data die betrekking heeft op een project, op een compacte manier op te slaan, zonder dat het in de weg zit en op zo'n manier, dat de resultaten herbruikbaar zijn. Dat laatste is het lastigste: Hoe zorg ik ervoor dat ik over bv. 3 jaar iets terugvind waarvan ik nu niet weet wat het is? Het is moeilijk om me voor te stellen dat ik over een paar jaar niet meer weet waar project Example.com over ging, of dat het eigenlijk project TestProjectKippen heette en later van naam is veranderd.

BTW: Afsluiting is niet hetzelfde als oplevering of delivery. Meestal vind afsluiting later plaats. Regelmatig overkomt het me, dat ik een project pas een jaar na oplevering of beëinding afsluit. Ik schrijf dit in juli 2021. Op dit moment ben ik zo'n 10 'zombie-projecten' aan het afsluiten. En om daar een positieve noot aan te geven: Ik weet van al deze projecten nog waar het over gaat! Dat had heel anders gekund (ok, met één uitzondering: Ik wist niet dat ik voor BrushTour dingen nodig had uit EanSku - En over dit soort zaken gaat dit artikel!)

Uitgangspunten

Digitale gegevens

Het gaat om digitale gegevens. Dus bits & bytes. Ik heb bijna nooit met fysieke artefacten te maken.

Mappen & bestanden

De basis van een project bestaat uit mappen & bestanden. Deze staan in m'n Dropbox-map. Dus niet dingen die online staan. Zie Projectmanagement » Mappen & bestanden voor achtergrondinfo. De truuk is daarom, om eventuele online gegevens, te incorporeren in deze mappen-en-bestanden-structuur.

Zo'n verzameling mappen-en-bestanden noem ik projectboom. De root of wortel is meestal gewoon de naam van het project.

Doorzoekbaarheid

grep -rn . -e "zoektekst" is voor mij de universele manier om gegevens terug te vinden. Dit is een belangrijke reden waarom bestanden & mappen de basis van mijn 'gegevensorganisatie' is. Waar ik zoal in kan zoeken met dit grep-commando:

  • Database-backups (vermits ze niet zijn gecomprimeerd)
  • JSON-backups van Trello-boards
  • Complete websites (vermits er een niet-gecomprimeerde backup van de db aanwezig is) - Dit is echt krachtig, bv. om een onvertaalde string terug te vinden
  • Kopieën van wiki-artikelen en andere websites: Ik heb nog niet de gewoonte om kopieën van relevante wiki-artikelen of sites te incorporeren in de backup rondom projectafsluitingen, maar dat zou wel handig zijn (compleetheid). Én doorzoekbaar! Dat geldt misschien niet als ik wiki-artikelen als PDF-bestanden zou opslaan.

Compleetheid - Self-containing

Idealiter is de data die bij een projectafsluiting verzameld wordt, compleet oftewel self-containing: Je zou het hele project (minus dingen waarvan je zeker weet dat ze niet relevant zijn, zoals klad-aantekeningen en eindeloze backups) weer aan de praat moeten kunnen krijgen mbv. alleen de afronding-data.

Dit impliceert dat allerlei bijkomstige data dus ook geïncorporeerd moet worden in de afronding. Bv.:

  • Database dwh_org of andere projectdatabases
  • Als er een map Data Sources ofzo was, dan zou deze behouden moeten worden.

Opgeleverde projecten staan nog steeds op m'n computer

Er was een tijd dat ik opgeleverde projecten verhuisde van m'n laptop naar backup-harde schijven, om een aantal redenen:

  • Overzicht: Hoe minder data op m'n laptop, hoe gemakkelijker
  • AVG: Hoe minder data op m'n laptop, hoe veiliger
  • Onderhoud: Ingebruikname van bv. een nieuwe laptop is veel gemakkelijker als ik niet eerst een halve TB aan data hoef over te fietsen, waarvan ik het grootste gedeelte toch niet meer gebruik.

In 2020 ben ik hier van afgestapt:

  • Als digitale nomade vind ik het rete-onhandig dat m'n backup-harde schijven in een kluis in Amsterdam liggen, op het moment dat ik daar zelf niet ben.
  • Use it or loose it: Backups hebben de neiging om vanzelf te verdwijnen. Da's waarschijnlijk om een hele simpele reden: Als je iets niet gebruikt, verdwijnt het. Rust roest of use it or loose it.

Sindsdien staan opgeleverde projecten nog steeds in m'n Dropbox-map op m'n laptop. Alleen per klant in een andere submap. Bv.:

  • Projecten
  • Projecten - Niet-actief.

Projectdatabases

Wat te doen met projectdatabases? Hoe houd ik alle data beheersbaar? Hoe zorg ik voor unit tests? Hoe zorg ik ervoor dat ik dingen kan terugvinden? En zonder tot in de lengte van jaren in de war te raken omtrent wat de juiste versie van een object is?

De resultaten van dit hoofdstuk, vind je hierboven terug in de checklist.

Het probleem

Meestal werk ik met projectdatabases. Gedurende een project onstaan daar steeds meer tabellen en sprocs (en incidenteel views & functies). Een deel van deze objecten wordt geïmporteerd uit database dwh_org.

Zo'n project produceert vaak tabellen die de moeite waard zijn om daarna in dwh_org te bewaren. Probleem: Steeds onduidelijk waar de meest recentelijke versie van zo'n tabel staat: In dwh_org of in de projectdatabase? (concurrency-probleem)

Als het project is afgerond:

  • Hoe voorkom ik dat concurrency-probleem tot in de lengte van dagen actief blijft?
  • Kan ik zo'n projectdatabase verwijderen? Dat scheelt afleiding en verwarring
  • Hoe zorg ik dat unit tests beschikbaar blijven?

Oplossing

  • Maak aan het begin van de afronding een backup van de database
  • Verplaats alle relevante tabellen naar dwh_org. Verwijder de rest
  • Behoud de sprocs, views & functies in de projectdatabase
  • Zorg dat de unit tests werken op deze nu lege projectdatabase. Eventueel de testcode uitbreiden met importeren van tabellen uit dwh_org.
  • Desgewenst kan de projectdatabase nu offline gehaald worden.

Checklist projectafronding

Dit is work-in-progress! Minder-uitgewerkte nieuwe dingen, staan onderaan dit hoofdstuk.

ReadMe.txt

Maak bestand ReadMe.txt aan in de root van het project. Als een txt-bestand te beperkt is, gebruik dan een tekstverwerkersbestand (odt-formaat).

Wat ik zoal in zo'n ReadMe.txt bestand onderbreng:

  • Naam van het project + uitleg, want na 6 maanden zijn heel veel projectnamen echt niet meer te begrijpen
  • Context: Waar pastte dit project in het grote geheel? Belangrijk, want ook dat weet ik over 6 maanden niet meer
  • Inventaris: Zie verderop
  • Leerpunten: Zie verderop
  • Unit tests: Zie verderop
  • Zoektermen: Zie verderop.

Inventaris

Inventaris: Waar staat alles. Dit lijstje is meestal onderdeel van het ReadMe.txt-bestand. Denk aan:

  • Mappen & bestanden. Dit is vaak alleen de naam van de map onder Projecten en/of Projecten - Non-active (de namen kunnen verschillen in deze twee situaties)
  • Trello-boarden: Hiervan vermeld ik vaak beide URL's: De 'gewone' en de URL die je ziet als je via het menu aan de rechterkant de 'permanente' URL opvraagt
  • Wiki-artikelen
  • Websites (dus sites die geproduceerd zijn als onderdeel van het project): Naam en evt. locatie.

Leerpunten

Leerpunten kunnen ook positieve zaken zijn. Bv. dat de kostprijsberekening verbazend accuraat was.

Aanbevelingen

  • Als ik dit project opnieuw zou doen, wat zou ik anders doen?
  • Hoe kan ik opvolgende projecten handiger doen?

Zoektermen - Keywords

Termen waarop ik in de toekomst misschien zou zoeken naar dingen uit dit project.

Maak backups

Maak in de root van het project een map aan voor backups. Deze map krijgt gewoon een volgnummer zoals bijna alle mappen. Bv. 500 - Backups at project completion - 2021.07.13.

Wat meestal in deze map belandt, mogelijk in submappen:

  • Project-database: Complete versie van vóór de projectafsluiting. Meestal comprimeer ik database-backups, ook al maakt ze dat niet-doorzoekbaar
  • Project-database: Lege versie met alleen nog sprocs, views en functies, geschikt voor executie van unit tests
  • Overige databases, bv. dwh_org of dwh_process
  • JSON-backups Trello-boards. Let op: Afbeeldingen worden niet meegenomen in deze backups
  • Backups van web sites?
  • Backups van wiki-artikelen?

Voeg timestamp toe aan projectnaam

Voorzie in de volgende situaties de projectnaam van een timestamp:

  • Projectmap. Bv. 2021.07.13 - Example.com - In de map Projects - non-active (of zoiets) staan oude projecten op deze manier chronologisch
  • Trelloboard. Bv. 2021.07.13 - Example.com - Ik heb tientalle gesloten Trello-boards dus een timestamp helpt met zoeken.

Bepaling datum timestamp:

  1. Datum waarop het laatst een document is aangepast. Als dat niet is te achterhalen (bv. omdat de boom met bestanden & mappen is gekopiëerd):
  2. Schatting van beëindiging van het project. Als ook dat niet lukt (bv. omdat het - jawel! - soms niet eens een duidelijk project betreft:
  3. Datum van vandaag.

Sluit Trello-board

Sluit het bijbehorende Trello-board (of -boarden), maar gooi ze niet weg.

Redenen om deze te sluiten:

  • In de gratis versie van Trello mag je sinds 2000 nog maar een beperkt aantal boards per team hebben
  • Overzichtelijker
  • De zoekfunctie van Trello werkt ook in gesloten boards.

Verplaats projectmap

Verplaats de complete projectmap van zoiets als Projecten naar Projecten - Niet-actueel.

Opruimen

Denk aan:

  • Webserver: Sites, host-definities, hosts-entries. De overige zaken spelen op m'n laptop:
  • Sites: Bestanden, databases, host-definities, hosts-entries
  • Aliassen in .bashrc
  • Links in thuismap
  • Bookmarks in Google Chrome
  • Databases: Zie elders voor details
  • Trello-boards: Zie elders voor details
  • Eindeloze backups. Meestal gewoon in de project-map. Soms daarbuiten.

AVG & NDA

  • Verwijder persoonsgegevens uit backups, waar relevant
  • Een enkele keer heb ik een NDA getekend. Effe checken of er specifieke procedures of eisen zijn (bv. dat ik de klant inlicht dat data is vernietigd en procedures zijn doorlopen).

Unit tests (work-in-progress)

Unit tests zijn er op twee niveau's:

  • project-specifiek: Invoegen in de projectboom van het project. Gewoon in een map met een volgnummer (want het komt regelmatig voor dat er later nog zo'n map komt). Bv. 1560 - Unit tests at project completion - 2021.07.14
  • Algemeen-relevant: Zorg dat het werkt vanaf dwh_org en op z'n minst, dat ze vermeld worden in de betreffende map. In dit geval belandt de data dus op twee plekken.

Originele data

Als er data is die voldoende 'origineel' is, dan zorgen dat deze op een begrijpelijke manier is opgeslagen. Weer:

  • Project-specifiek: Invoegen in de projectboom
  • Algemeen-toepasbaar: Daaro invoegen. In dit geval belandt de data dus op twee plekken - Het zij zo

Te veel backups?

Bij afsluiting lijkt er een handjevol mappen te ontstaan met redelijk overeenkomstige data:

  • In de projectboom zitten regelmatig backups, bv. een db-backup voorafgaand aan iets ingewikkelds en risicovols
  • Originele data - Mogelijk op twee locaties
  • Afsluiting-backups
  • Unit tests - Mogelijk op twee locaties
  • Backups in de root van deze klant (dat komt voor!)
  • Externe reguliere backups
  • Externe niet-reguliere backups (daar heb ik nu geen goede naam voor paraat).

Ik weet niet goed hoe hier mee om te gaan (juli 2021). Het idee komt dan snel bij me op, om al die data op een of andere manier samen te voegen - Maar dat is waarschijnlijk niet handig qua overzicht. Redundantie is in dit geval secundair.

Database-documentation

Sinds 2020 houd ik in de projectboom een map Database-documentation bij. Da's heel handig. Deze krijgt geen numeriek voorvoegsel, want écht tijdloos ipv. momentopname. Belangrijk om bij projectafsluiting rekening mee te houden.

Zie ook