Meine erste Erfahrung als Projektmanager
Meine erste Erfahrung als Projektleiter begann ganz unerwartet. Zu Beginn meines Praktikumsprogramms bei CodeCoda wurden zehn andere Praktikanten und ich gebeten, ein Produkt mit unserem Design zu entwickeln. Die Projektrollen wurden auf der Grundlage dessen verteilt, was jeder von uns bald sein möchte. Zu diesem Zeitpunkt ging ich davon aus, dass ich dem Entwicklungsteam beitreten würde, einfach weil ich als Softwaretechnik-Student die meiste Zeit mit der Programmierung und Entwicklung der Benutzeroberfläche verbracht habe.
Software Entwicklung ist das, womit ich am meisten Erfahrung habe, und dabei fühle ich mich natürlich am wohlsten. Als ich jedoch nach meinen Vorlieben gefragt wurde, erklärte ich zuversichtlich, dass ich offen für neue Erfahrungen sei. Und so passte die Rolle des Projektmanagers perfekt zu mir. Überrascht und immer noch an der Coder-Mentalität festhaltend, rief ich aus: “Nur?!!”. (offensichtlich ohne zu wissen, was meine Verantwortung als PM beinhaltete). Nach meiner anfänglichen Überraschung nahm ich die Herausforderung an, nur Manager zu sein. Ich tröstete mich mit dem Gedanken, dass ich auch Frontend-Aufgaben übernehmen könnte, während die anderen beschäftigt sind und es nichts zu verwalten gibt. Oh, diese Naivität!
DIE APP
Bei Lavina dreht sich alles um Aktion und Verbindung. Es geht um Initiation und Interaktion von Angesicht zu Angesicht. Hätte es sie schon vorher gegeben, hätte sie ein Problem lösen können, auf das wir alle mindestens einmal gestoßen sind. Nämlich, dass eine Veranstaltung durch einen Mangel an Menschen ruiniert wird Während der Diskussion über die Idee stellte sich heraus, dass jedes Teammitglied eine andere Geschichte für die gleiche Situation hatte und ich weiß, dass Sie auch eine haben. Sei es ein ruiniertes Kartenspiel aufgrund eines fehlenden Partners, ein Fußballspiel, bei dem ein Spieler fehlt, oder jemand um sich einer Gruppe anzuschließen - das Problem ist dasselbe, und wir beschlossen, es selbst in die Hand zu nehmen.
Schon kurz nach der ersten Idee hatten unsere Köpfe zahlreiche Szenarien entworfen, in denen eine solche Plattform ein absolutes Novum darstellen würde. Sie könnte sich für Veranstaltungen jeder Art und Größe als nützlich erweisen. Ob Sie eine helfende Hand brauchen, um die alte Kommode aus dem Haus zu holen, Plätze für ein Gruppenprojekt oder was sonst noch einem einfällt, Lavina wird die Lage retten.
Wir mussten sicherstellen, dass die Benutzer leicht durch alle Zufallsereignisse navigieren und genau das finden, was sie brauchen, also beschlossen wir, sie zu kategorisieren. Aus dieser Lösung ergab sich jedoch ein weiteres Problem, denn wir konnten nie alle möglichen Szenarien vorhersagen, in denen die Benutzer die Plattform nützlich finden könnten, also einigten wir uns darauf, ihnen die Freiheit zu geben, benutzerdefinierte Kategorien zu erstellen. Dadurch, dass wir den Benutzern die Möglichkeit geben, die App auf ihre Bedürfnisse zuzuschneiden, machen wir sie auch zu einem Teil unserer Teamarbeit, besonders wenn man bedenkt, wie wir alle gemeinsam zur Erstellung der App beigetragen haben.
Indem wir dem Benutzer das richtige Werkzeug an die Hand geben, um schnell lokale Gruppenveranstaltungen zu initiieren, wollen wir solche Zusammenkünfte populär machen und ihnen damit helfen, genügend Trägheit für eine Aktivitätslawine zu gewinnen.
DER PROZESS
In der ersten Woche haben wir nur geplant und diskutiert. Erst danach haben wir mit der Kodierung begonnen. Sieben Tage zuvor hatte ich noch keine einzige Zeile Code geschrieben. Da ich so wenig an eine solche Disposition gewöhnt war, fühlte ich mich (irgendwie) nutzlos und so beschloss ich, mich in eine Projektverwaltende interaktive Gummiente zu verwandeln.
Von diesem Zeitpunkt an bis zum Ende des Projekts sprang ich von einer Person zur nächsten und fragte sie, woran sie gerade arbeiteten und ob sie irgendwelche Probleme damit hatten. Scheinbar unbedeutende Veränderungen, aber ich fühlte mich dadurch viel nützlicher. So konnte ich sicherstellen, dass alle genau wussten, was sie zu tun hatten, während ich ihnen gleichzeitig half, sich auf das zu konzentrieren, woran sie gerade arbeiteten. Dieser Ansatz hat uns auch dabei geholfen, Probleme mit Agilität zu lösen, da bekanntlich zwei Köpfe besser sind als einer.
Es folgten einige idyllische Tage; die Sonne schien, die Vögel sangen, Back-end Developer wirkten ihre Magie, Front-end Developer und QA lernten, was sie zu tun hatten, und ich - beaufsichtigte, teilte Aufgaben zu und versuchte, den Entwicklern bei der Lösung ihrer Probleme zu helfen. Bis uns klar wurde, dass wir einen Designer für das Frontend mit mehr Leichtigkeit und weniger Änderungen brauchten, sowie einen Dev-Ops, der das Projekt andockte, da wir beschlossen, es mit mehreren Mikrodiensten zu bauen. Wir hatten keine andere Wahl, als denen, die die noch unentdeckten Talente einiger Teammitglieder und einige wenige helfende Hände von den Profis in der Firma nutzten, den Weg zu ebnen. Und das ist uns gelungen.
WAS ICH GELERNT HABE
Manchmal ist es besser, nicht zu abgehoben zu sein
Da wir keinen eigentlichen Kunden hatten, mit dem wir arbeiten konnten, waren wir diejenigen, die die Anforderungen für die App definiert haben. Es war so verlockend, darüber zu fantasieren, was wir daraus machen könnten, dass wir uns einbildeten, wir hätten die Grundlage bereits geschaffen, aber den Kontakt zur Realität zu verlieren, konnte uns nur dazu verleiten, Ressourcen für die Implementierung unnötiger Funktionen zu verschwenden, was zur Verschiebung der ersten Veröffentlichung führte. Um diese Verzögerung zu verhindern, mussten wir zwischen Ideen für die unmittelbare und zukünftige Entwicklung unterscheiden. Und es war meine Aufgabe, dafür zu sorgen, dass wir es richtig machten.
Man kann es nicht allen recht machen
Wenn es um die Entscheidungsfindung geht, versuche ich, das ganze Team in den Prozess einzubeziehen. Ich mag es, wenn jeder seine Meinung äußern und Wissen austauschen kann, weil dies einen starken Sinn für Teamarbeit und Verständnis fördert. Außerdem gibt dieser Ansatz dem Team einen besseren Einblick in zukünftige Aktionen, warum und wie sie ausgewählt wurden. Ich glaube, wenn man Transparenz und Einbeziehung in den Entscheidungsprozess bietet, reagieren die Menschen mit viel mehr Enthusiasmus, weil dieser Ansatz ein größeres Gefühl von Fairness und Autonomie fördert, als wenn man ihnen eine endgültige Entscheidung übergibt, die hinter verschlossenen Türen getroffen wird. Trotzdem werden Sie am Ende des Tages nicht alle zufrieden gestellt haben und Sie sollten nicht danach streben. Wenn Sie in einer Gruppe arbeiten, sollte Ihr Ziel niemals sein, es allen recht zu machen, sondern stattdessen auf das Wohl Ihrer Gruppe hinzuarbeiten. Ersteres wird sowieso nie passieren.
Wiederholung ist kein Tabu
Die ersten Male, als ich die Leute dazu bringen musste, ihre Arbeit neu zu machen, fühlte ich mich irgendwie unbehaglich, weil ich dachte, ich hätte meinen Standpunkt vielleicht gar nicht richtig verstanden. Das hätte natürlich genauso gut nicht der Fall sein können, aber sei es ein Kommunikationsproblem, eine schlechte Planung oder ein Missverständnis, den Leuten zu sagen, dass sie Zeit damit verbracht haben, das Falsche zu tun, ist für beide Seiten unangenehm. Obwohl es sehr oft vorkommt, ob man allein oder im Team arbeitet. Um Ihres Projekts willen sollten Sie lernen, damit umzugehen. Das Projekt zu kompromittieren, indem Sie an den Ecken sparen, um sich selbst oder dem Team etwas zusätzliche Arbeit zu ersparen, ist auf lange Sicht vielleicht nicht der beste Ansatz. Ein bisschen sofortige Genugtuung zu bekommen, klingt nicht nach einer schlechten Idee, bis Sie erkennen, dass dies auf Kosten eines gescheiterten Projekts gehen könnte.
IM GROßEN UND GANZEN
Insgesamt bin ich mit meiner ersten PM-Erfahrung zu 100% zufrieden. Nicht weil es ein Kinderspiel war, sondern gerade weil es kein Kinderspiel war. Die guten Zeiten, die ich genossen habe, die schwierigen Zeiten, von denen ich hoffe, dass ich daraus gelernt habe. Glücklicherweise sind die Lektionen, die ich gelernt habe, weit mehr als drei, aber das ist der Betrag, den ich in Worte fassen konnte.
Tatsächlich ist die Menge an neuen Informationen, die ich während des Praktikums bei Code Coda gelernt habe, erstaunlich, wenn man bedenkt, dass es nur einen Monat dauerte. Abgesehen von mir und den Bedürfnissen meines Teams führe ich das auch auf die super hilfsbereiten Leute bei Code Coda zurück. Sie waren immer bereit, über ihre Erfahrungen mit dem Thema zu berichten, mit dem Sie gerade kämpfen, Ratschläge zu erteilen ODER Sie an jemanden zu verweisen, der sich vielleicht mit etwas Ähnlichem befasst hat.
Farbenfroh. Wenn ich ein Wort wählen müsste, um die teamübergreifende Erfahrung zu beschreiben, dann wäre es dieses. Wenn man elf Menschen mit völlig unterschiedlichen Interessen, Bestrebungen, Kompetenzen und vor allem Persönlichkeiten zusammenbringt, erhält man genau das - eine farbenfrohe Erfahrung. Eines hatten wir jedoch alle gemeinsam - wenig bis gar keine Erfahrung mit der Arbeit in einem Team von mehr als zwei Personen. Wir haben uns alle überraschend schnell und mühelos an die Arbeit im Team gewöhnt. Das heißt aber nicht, dass wir keine Rückschläge erlitten haben. Natürlich hatten wir unsere Höhen und Tiefen, aber was noch wichtiger ist, ist, dass wir durch beides zusammengehalten haben. Wenn jemand mit einem Problem konfrontiert war, haben wir versucht, es gemeinsam zu lösen. Wenn jemand etwas erfolgreich abgeschlossen hat oder eine großartige Idee hatte, haben wir uns mit ihm gefreut. Wir standen nicht in Konkurrenz zueinander. Wir konkurrierten mit unserer bisherigen Arbeit und versuchten, sie jeden Tag zu verbessern. Das ist das Ziel, nach dem ich strebe, wenn ich im Team arbeite und ich bin sehr stolz darauf, dass wir es erreicht haben!
