Wir wollen euch heute einen Einblick in eine holprige Phase unseres Projekt geben. Denn zur Umsetzung eines Projekts im Rahmen der Netidee gehört nicht nur offener Quellcode, sondern auch eine gute Organisation und Projektmanagement. Gerade im März und April gab es einige Hürden auf unserem Weg zum wichtigen 50%-Meilenstein, die wir mittlerweile gut im Griff haben, oder sogar komplett beseitigt sind. Uns ist es aber wichtig auch anderen einen Einblick in unseren Projektablauf zu geben. So könnt ihr euch vielleicht in eurem Netidee-Projekt einige stressige Momente oder gröbere Umplanungen ersparen.
Detailliertere Risikoabschätzung
Im Antrag wurde zwar nach Risiken gefragt, jedoch handelt es sich hier um einen leicht unterschätzbaren Unterpunkt. Das kann zu einer verkürzten Risikoabschätzung verleiten. Wir haben für SharedMobility.ai folgende Risiken angegeben:
- Es wird kein passendes Vorhersagemodell gefunden (was aber auch in gewisser Weise positiv wäre, zu wissen, was nicht funktioniert hat)
- Zu wenige Datensätze für einzelne Anbieters
- Bike-Sharing-Partner stellen Dienst ein (unwahrscheinlich)
Durch äußere Umstände und einen erhöhten Reparaturaufwand über einen längeren Zeitraum ist der zweite Risikofall in unserem Projekt eingetreten. Wir sind allerdings erst im Zuge der intensiven Datenanalyse kurz vor Halbzeit auf dieses Problem aufmerksam geworden. Die Anzahl der aktiven Leihräder sank so stark, dass unzureichende Daten für ein Vorhersagemodell über einen längeren Zeitraum vorlagen.
Gerade bei datenintensiven Projekten sollte unbedingt ein laufendes Daten-Controlling eingeführt werden. Von Beginn an muss es regelmäßige qualitative Kontrollen geben, nicht nur quantitative Checks. Das verhindert unangenehme Überraschungen und man reagiert schneller auf geänderte Rahmenbedingungen.
Wir hatten im Übrigen zwei Skripte im Einsatz, die das Funktionieren des Daten-Collectors überwachten, allerdings prüften diese nur a) die syntaktische Korrektheit der JSON-Dateien und b) das Funktionieren der API des Mobilitätsanbieters. Wir hätten noch eine inhaltliche Prüfung + Alarmierung bei der Unterschreitung von Schwellenwerten implementieren müssen. So haben wir zwar Daten gesammelt, allerdings sind diese über einen längeren Zeitraum leider wertlos für unser finales Produkt.
Mehr Weitblick bei der Projektplanung
Als wir den Projektzeitplan ausarbeiteten, gingen wir von gleichbleibenden Lebensumständen bei allen Beteiligten aus. Bisher haben wir nur mehrwöchige Projekte geplant, nicht aber über ein ganzes Jahr laufende Vorhaben. Um einen raschen Projektfortschritt zu erzielen, haben wir Pufferzeiten bewusst gering gehalten. Was wir dabei nicht bedacht haben: Es kann sich schnell einmal das Leben bei einzelnen Projektpartnern in eine neue Richtung verändern. So sind Jobwechsel oder Umzüge in andere Städte zwar nicht hochwahrscheinlich, aber durchaus bei allen Beteiligten möglich.
In unserem Fall hat sich im Laufe des Projektstarts Nachwuchs beim Projektleiter angekündigt. Wir hätten hier großzügiger darauf reagieren müssen, statt weiter am ursprünglichen Zeitplan festzuhalten und nur Arbeitspakete zu verdichten. Zu einer sorgfältigen und verantwortungsvollen Zeitplanung gehört auch großzügigere Ausfallszeiten für Eltern vorzusehen, wenn man diese nicht durch eine große Projektstruktur auffangen kann. Kleinkinder werden nun einmal im Winter häufiger krank und benötigen umfangreiche Fürsorge. Das Problem sind hier aber nicht Kinder, sondern eine in diesem Punkt ignorante Projektplanung, gerade bei derart personenzentrierten Projekten wie unserem. Größere Projekte gleichen dieses Risiko über die höhere Mitarbeiterzahl aus und Ausfälle verteilen sich gleichmäßiger über den Gesamtzeitraum.
Zeits- und Aufwandsschätzung ist schwierig
Einige werden den Satz kennen: „Für diesen Teil brauche ich nur ein paar Stunden!“ Am Ende landet man aber dann bei ein paar Tagen, vielleicht sogar Wochen. Software-EntwicklerInnen sind meist furchtbare Schätzer. Im Kopf zimmert man sich schon eine Lösung zusammen, nur um nach ¾ des Weges alles wieder zu verwerfen, weil man in einer Sackgasse gelandet ist. Statt bekannter Techniken und eingeübten Patterns setzt man auf neue Technologien, die man spannend bzw. moderner als bereits bekannte findet. Außerdem vergisst man schnell den Overhead rund um Projektmanagement und Kommunikation. Dazu kommt die Selbstüberschätzung: Fast jeder schätzt sich selbst besser und schneller ein als man im Rückblick objektiv feststellt. Man geht bei der eigenen Schätzung nämlich davon aus, dass man alles unter Kontrolle hat – externe Faktoren blendet man aus – und dann kommen äußere Einflüsse und entreißen einem das Steuerrad.
Remote Work und Meeting-Kultur
Weronika sitzt in Warschau, Lisa in Ottakring und Philipp in der Seestadt. Wir haben alle unterschiedliche Zeitpläne und haben uns anfangs primär über eine Facebook Messenger Gruppe unterhalten. Das macht es zwar leicht zu unterschiedlichen Zeiten miteinander zu kommunizieren, allerdings bestehen auch die üblichen Herausforderungen von chatbasierter Teamkommunikation. Wir hätten von Beginn an stärker auf fest Jour Fixe Termine und Videokonferenzen setzen sollen. Diese Meetings brauchen eine gewisse Struktur. Zuerst kurz den aktuellen Status mit der Netidee besprechen, dann erst ins eigentliche Projekt wechseln. Außerdem kann man durch Screensharing auch konkreten Code besprechen, statt ihn nur allgemein im Chat zu dokumentieren. Um effizienter zu agieren, haben wir für die nächsten Arbeitspakete auch gemeinsame Meetings in Wien vereinbart, wobei hier die aktuell gut Fernverbindung nach Warschau sehr hilfreich ist. In diesen Meetings halten wir auch Code Sprints ab, in denen gemeinsam an problematischen Stellen gearbeitet wird. Je früher man diese Code Sprints festlegt, umso einfacher und günstiger wird auch die Reiseplanung.
Fazit / Lessons Learned
Die Netidee verlangt für die Auszahlung der ersten Förderrate einen vollständigen Projektplan mit entsprechenden Arbeitspaketen und Meilensteinen. Plant auf alle Fälle einige Checkpoints für die anfangs definierten Risikofaktoren ein, wobei nicht nur auf die Quantität, sondern auch die Qualität geachtet werden muss. Reagiert früh auf kleinere Verschiebungen und Ausfallzeiten und geht nicht davon aus, dass diese leicht wieder reingeholt werden können. Besser defensiv denken und rechtzeitig in kleineren Schrittchen umplanen, als optimistisch und am Ende etwas zerknirscht den Projektplan in einem großen Schritt nach hinten verschieben. Checkt auch regelmäßig die Ist-Stundenlisten und ob eure initiale Planung damit gut übereinstimmt. Meldet euch aktiv bei absehbareren längeren Verzögerungen. Wenn jemand für mehrere Wochen ausfällt, meldet euch proaktiv bei der Netidee mit einer kurzen Information und plant anschließend im Team um.
Wir befinden uns jetzt wieder auf einem guten Weg und haben einen adaptierten Zeitplan gefunden. Auch wenn die letzten beiden Monate etwas holprig waren, so haben wir doch als Team einiges daraus gelernt. „netidee steht für Offenheit, Transparenz und Sharing.“ – wir hoffen, dass wir euch hier ein bisschen für eure eigenen Einreichungen geholfen haben!