Zeitschätzungen der Dauer, bis Projektteile fertiggestellt sein würden, gestalteten sich stets als schwierig. Nicht nur die schiere Größe des Projektes, bedingt durch die zum professionellen Einsatz nötige Tiefe der Anforderungen jedes Projektteils, sondern ebenfalls fehlende Erfahrungswerte bezüglich der Schätzung als Werkstudent trugen maßgeblich dazu bei. Insbesondere dann, wenn man wie ich bei der Bearbeitung universitärer Projekte gerne die Zeit außer Acht lässt und davon unabhängig arbeitet bis ein Projekt einen akzeptablen Stand erreicht. Zusätzlich nahmen etwa Fragen des Deployments in den jeweiligen Produktionsumgebungen, beispielsweise zur Sicherheit und Ausfallsicherheit, viel Zeit in Anspruch, ohne ein für technisch Außenstehende offensichtliches Ergebnis zu erzielen. Trotz dieses intransparenten Fortschritts lohnte sich der Fokus auf das Minimum Viable Product (MVP), auch wenn das Funktionalitätsspektrum bis zur „vollständigen Implementierung“ der Grundfunktionen nicht wuchs. Die letztendlich benötigte Zeit lag meist ein gutes Stück über der ursprünglichen Schätzung, hauptsächlich mit Blick auf die zur Verfügung stehenden Wochenstunden und die daraus resultierende absolute Dauer. Hier lohnte es sich, präventives Erwartungsmanagement mit Bezugnahme auf diese lediglich 10 in der Woche zur Verfügung stehenden Stunden vorzunehmen, um offene und ehrliche Kommunikation zu wahren.
Um grundsätzlich möglichst schnellen Fortschritt zu erzielen, Softwareunterstützung zu erfahren und IT-Sicherheit zu gewährleisten, rentierte sich in allen Fällen eine Recherche nach den aktuellen Best Practices und Standardlösungen, wie der für jede Kommunikation genutzten mTLS-Verschlüsselung. Ebenfalls gaben Industrienormen und technische Standards weiteren Aufschluss über die Handhabe üblicher Problemstellungen, welche sich häufig auch auf andere Bereiche des Systems übertragen ließen. So lieferten etwa standardisierte Datenaustauschmodelle für Energiesystemkomponenten Inspiration für die Modellierung von Zeitreihendatenpunktarten. Typische Anbindungsprotokolle zwischen Gateway und Geräten waren meist von der Industrie genormte, teilweise jedoch proprietäre Protokolle, die eher schlecht als recht dokumentiert waren und keinen Best Practices, wie etwa der Protokollversionierung, folgten, was für deutlichen Zeitaufwand auf meiner Seite sorgte. Falls möglich, lässt sich empfehlen, von der Verwendung proprietärer Schnittstellen abzusehen. In der Architektur etwa ersetzte eine Standardlösung die anfänglich gRPC-basierte Custom-Implementierung eines Persistent-Queue Services. Der eingesetzte Message Broker standardisierte effektiv und zeiteffizient das Protokoll, die Autorisierung und die Zuordnung unterschiedlicher Datenströme zu entsprechenden Services, während gleichzeitig Durability sichergestellt wurde. Wo möglich, lohnte es sich in jeder Situation, Standardkomponenten einzusetzen. Insbesondere in sicherheitsfokussierten Bereichen, wie etwa des Identity & Access Managements, der Zertifikatsverwaltung und auf der Nutzungsseite in der Authentifizierung und Autorisierung. Für diese sicherheitskritischen Systembestandteile sollte wenn möglich immer auf bereits bestehende Software zurückgegriffen werden, um Sicherheitslücken zu vermeiden.
]]>Damit die Konzeption gestartet werden konnte, benötigte ich zuerst ein Verständnis über die Domain und die möglichen Anforderungen. Ich führte dazu Recherchen und Gespräche mit Stakeholdern durch, die entsprechendes Domain-Knowledge besaßen, mit dem Ziel, einen Anforderungskatalog zu erstellen. Gleichzeitig bat ich diese, sowie Personen mit Informatikbackground der Hagen GmbH, um die Niederschrift einiger Anforderungen, die sie persönlich für wichtig erachteten. Es entstand ein ungeordneter Anforderungskatalog, der sich grob in zwei Kategorien untergliedern ließ: Anforderungen auf Basis des Domain-Knowledge und technische Anforderungen an das System. Der Katalog gab mir einen groben Überblick über das Projekt, obwohl er weder komplett noch detailliert genug war, um ein vollständiges System-Design abzuleiten. Dies stellte sich im Nachhinein nicht als Nachteil dar, fehlte dieser Momentaufnahme nicht nur der Blick in die Zukunft, die neue Anforderungen und Prioritätsänderungen brachte, sondern auch mir die zeitlichen Möglichkeiten, bedingt durch die Wochenarbeitszeit, alle Anforderungen umsetzen zu können.
Durch die Änderung der Prioritäten einzelner Anforderungen und dem Hinzufügen neuer Anforderungen über die Zeit in Kombination mit der zur Verfügung stehenden geringen Wochenstundenzahl mussten Designentscheidungen flexibler Natur getroffen werden, um einen anpassungsfähigen Systemkern zu schaffen. Dies möchte ich am Beispiel des Schema-Designs der Datenbank verdeutlichen:
Für den Start des Schema-Designs erwies sich die allseits bekannte ER-Modellierung als sehr nützlich, um erste Ideen zu skizzieren und stets eigene Gedankengänge selbstkritisch beleuchten zu können. Implizit wurde so nach und nach ebenfalls das möglichst kleinste Universe of Discourse festgelegt, um keine unnötige Komplexität einzubringen. Doch trotz guter Modellierung wurden Auswirkungen mancher Abwägungen erst durch die sukzessive Implementierung des Gesamtsystems deutlich. Hierbei musste das Datenbankschema häufiger iterativ angepasst werden, da sich Edge Cases zeigten. So war beispielsweise ein teilweises Redesign des Schemas nötig, um zeitpunktgenaue Neuzuweisungen von Gateways zu Installationen und an den Gateways angeschlossenen Geräten zu diesen Installationen darstellen zu können. Das Problem, dass Geräte und Gateways, die von einer Installation zur anderen wechseln können, deren bereits produzierte Daten jedoch im System mit der korrekten Zuordnung verbleiben sollten, musste abstrakt genug gelöst werden, um auch zukünftigen Gerätetypen, unbekannter Art und Konfiguration, Sorge zu tragen, sowie Daten korrekt zuordnen zu können, die aufgrund von Teilsystemausfällen unbekannter Art noch nicht (vollständig) übermittelt wurden. Diese iterative Entwicklungsarbeit an der Datenbank wurde durch das Führen eines statischen, versionsverwalteten DDL-Skripts zur Erstellung des Schemas beschleunigt. So konnten Änderungen, die das Schema offen für spätere Erweiterungen machten, schneller erprobt werden.
]]>Mein Name ist Jens, ich studiere Wirtschaftsinformatik im Master und arbeite seit über 2 Jahren als Werkstudent bei der HE – HagEnergy GmbH in Peine. Das auch Hagen Energiesysteme & Gebäudetechnik genannte Unternehmen wurde erst 2023 von Torben und Christian Hagen ausgegründet. Es ist ein Handwerksbetrieb mit etwa 30 Mitarbeitern. Wesentliche Unternehmenszwecke sind die Installation von Solar- und Energiesystemen bis in den Megawattbereich sowie die Bereitstellung weiterer Dienstleistungen innerhalb dieses Gebietes. Die länger existierende Schwesterfirma Hagen GmbH, die Unternehmen bezüglich der Arbeitssicherheit berät, entwickelt bereits seit einigen Jahren eigene digitale Systeme für beispielsweise das technische Prüfmanagement, Unterweisungsmanagement und Gefahrenstoffverzeichnis.
Mit Blick auf immer stärker vernetzte Energiesystemkomponenten und steuerbare Verbrauchseinrichtungen suchte die HE – HagEnergy GmbH einen Werkstudenten zur Entwicklung eines Energiemanagementsystems.
Das zu entwickelnde Energiemanagementsystem sollte insbesondere Möglichkeiten der Remote-Datenerfassung bieten. Potenzielle weitere Einsatzfelder lagen in den Bereichen des dynamischen Lastmanagements von Ladepunkten und der Verbrauchs- und Einspeiseoptimierung. Während der gesamten Zeit wurden mir große Lern- und Gestaltungsfreiräume von der Konzeption und dem Anforderungsmanagement über die Systemarchitektur und der Implementierung bis hin zum Minimum Viable Product (MVP) gewährt. Innerhalb dieser Bereiche bot sich mir eine fachliche Breite und Tiefe, die ich bei anderen Unternehmen, aufgrund von Bereichsspezialisierungen und fehlender persönlicher Autonomie, nicht hätte einsehen können. Dies ermöglichte mir eine signifikante und eigenständige persönliche Weiterentwicklung, die mir als eher autodidaktisch veranlagtem Menschen sehr zugute kam. Meine wöchentliche Arbeitszeit belief sich aufgrund eigener Entscheidung, vorwiegend wegen des Zeitaufwands für das Studium, auf verhältnismäßig geringe 10 Wochenstunden, von denen seit einem Jahr auch ein kleiner Teil für Entwicklungen innerhalb der Hagen GmbH aufgewendet wurde. Beide Firmen boten aus meiner Sicht stets ein sehr gutes Arbeitsklima. Die Möglichkeit zum Home-Office, kurze Dienstwege und persönlicher Umgang ließen insbesondere das Vorantreiben des Projektes meist weniger als einsame Arbeit, sondern eher als ein gemeinsames Ziel erscheinen.
In den folgenden zwei Blog-Beiträgen möchte ich euch meine Learnings und Erfahrungen aus der eigenständigen Konzeption und Entwicklung des Systems näher bringen. Dazu findet ihr im nächsten Beitrag Learnings, die das Anforderungsmanagement und die Konzeption betreffen. Der darauffolgende Beitrag beschreibt meine Erfahrungen zu Zeitschätzungen und der Nutzung von standardisierten Elementen.
]]>in diesem letzten Beitrag möchte ich darüber sprechen, wie ich das Insolvenzverfahren von Vizavy erlebt habe und wie ich rückblickend meine persönliche Entwicklung einschätze. Ich möchte betonen, dass es sich hier um meine eigene Perspektive handelt – sie ist subjektiv und kann natürlich Lücken haben.
Wir hatten unser Produkt am 15. September 2023 veröffentlicht. Es gab noch ein paar Fehler zu beheben, deshalb wollten wir zunächst einen internen Early Access durchführen, bevor wir das Produkt an Kunden herausgeben. Doch dazu kam es nicht mehr. Am 02.10.2023 stellte Vizavy den Insolvenzantrag. Die Nachricht erreichte uns in einem unternehmensweiten Call. Uns wurde versichert, dass keine Gefahr bestehe, dass das Unternehmen schließen müsse.
Ich war unglaublich stolz auf mein Team. Statt sich entmutigen zu lassen, haben sie die Situation als Chance gesehen, sich zu beweisen. Das Entwicklungstempo blieb hoch, niemand hat nachgelassen. Alle zwei Wochen hatten wir einen Call mit dem Insolvenzverwalter – Herr Walter, ja, wirklich so hieß er – und bekamen Updates zum Verfahren. Leider wurden die Nachrichten jedes Mal schlechter. Die Geschäftsführung versuchte zunächst, Investoren zu finden. Als das scheiterte, sollten die Produkte an andere Unternehmen verkauft werden. Am Ende wurde uns mitgeteilt, dass Vizavy im März schließen würde. Ich selbst bin im Dezember ausgestiegen. Ich war mit einigen Entscheidungen der Geschäftsführung nicht einverstanden und wollte die Zeit lieber für meine Klausuren nutzen.
Was mir bis heute nachgeht: wie sehr ich dieses Team vermisse. Das System der Vizcademy – ein Team aus Studierenden und Umschülern, das aber volle Verantwortung trägt – hat dazu geführt, dass ich eine enorme persönliche Entwicklung durchlaufen habe. Mit der Unterstützung meines Mentors habe ich Zusammenhänge verstanden, über die ich vorher nie nachgedacht hätte. Ich musste meinen Führungsstil anpassen, je nachdem, was das Projekt gerade brauchte. Ich habe gelernt, mein Team gegenüber Stakeholdern zu vertreten und zu schützen. Die Vizcademy war für mich das Beste, was das Unternehmen geschaffen hat, und ich werde meinem Mentor und meinem Vorgesetzter immer dankbar sein.
Gleichzeitig hatte das Unternehmen auch Erwartungen an uns, die über das Projekt hinausgingen. Persönliche Weiterentwicklung war ausdrücklich gewünscht, genauso wie das Erwerben von Zertifizierungen, die für die eigene Zukunft wichtig sein könnten. Diese würden auch vom Unternehmen finanziert.
Ich bin traurig, weil ich bezweifle, jemals wieder in einem so besonderen Umfeld arbeiten zu können. Aber ich weiß auch: Wenn ich irgendwann die Möglichkeit habe, ein ähnliches System in einem Unternehmen einzuführen, würde ich es ohne zu zögern tun.
Ich hoffe, dass diese drei Blogs euch einen Einblick geben konnten – oder euch zumindest eine angenehme und vielleicht sogar interessante Lesezeit beschert haben.
Viele Grüße,
Jaime
]]>Ich bin im Mai 2023 bei Vizavy eingestiegen und hatte zunächst zwei Monate Zeit, um alles von meinem Vorgänger zu lernen. Für mich war das eine intensive Phase: Ich musste erst einmal verstehen, wie sich die Aufgaben eines Product Owners von denen eines Scrum Masters unterscheiden, wo die Grenzen liegen und welchen Platz ich in der Unternehmenshierarchie einnehme. Gleichzeitig habe ich Scrum von Grund auf gelernt – nicht nur theoretisch, sondern direkt im praktischen Umfeld. Ausserdem wurde mir ein Mentor zur Seite gestellt, was sich als sehr wertvoll herausgestellt hat.
Im Unternehmen haben wir das Atlassian‑Ökosystem genutzt, vor allem Jira und Confluence. Jira diente uns als Kanban‑Board, über das wir den Status unserer Aufgaben, Abhängigkeiten und Kommentare im Blick behalten konnten. Confluence war unser zentraler Ort für Dokumentation – nicht nur für die Software selbst, sondern auch für interne Prozesse wie unseren Social Contract oder die Erwartungen der Stakeholder.
Mein Team hatte bereits vor meiner Zeit mit Planning Poker gearbeitet, um den Schwierigkeitsgrad von Aufgaben einzuschätzen. In den ersten Wochen habe ich viel Zeit damit verbracht zu verstehen, wo die Grenzen und Herausforderungen meines Teams lagen. Auf dieser Basis habe ich einen Plan entwickelt, wie wir diese Probleme langfristig angehen können.
Als ich die Rolle schließlich vollständig übernommen hatte, bestand mein Alltag aus einer Mischung aus Stakeholder‑Meetings, Board‑Pflege, Sprint‑Planung, enger Kommunikation mit meinem Team und der Abstimmung mit unserer Scrum Masterin. Gemeinsam haben wir Probleme im Prozess identifiziert, Prioritäten gesetzt und die Ziele des Projekts geschärft. Ein größerer Teil meiner Verantwortung war außerdem, die Monetarisierung unseres Produkts komplett neu zu strukturieren – aus meiner Sicht wäre das Produkt ohne diese Anpassung kaum wirtschaftlich tragfähig gewesen.
Gegen Ende meiner Zeit kamen weitere Aufgaben hinzu: die Vorbereitung des Produkt‑Releases, das Setzen eines Meilensteins für den zukünftigen Support der Software und der Besuch von Messen, um unser Produkt vorzustellen.
Neben der Vizcademy war ich außerdem für zwei kleinere Teams verantwortlich. Eines arbeitete an einer internen Softwarelösung, bei der wir klassisches Projektmanagement statt Scrum nutzten. Das andere Team betreute einen Kurs, den wir an Volkshochschulen angeboten haben – eine Art „Schnupper‑Scrum“, bei dem Teilnehmende die Grundlagen des Frameworks kennenlernen konnten.
]]>In diesem ersten Blog möchte ich genau darüber sprechen: über das Unternehmen und die besondere Atmosphäre, die Vizavy geprägt hatte. Die nächsten beiden Beiträge werden sich dann mit meinen konkreten Aufgaben sowie meiner persönlichen Entwicklung – gerade auch während der schwierigen Phase der Insolvenz – beschäftigen
Vizavy selbst war das Ergebnis einer Fusion zweier Software‑Consulting‑Unternehmen: Moxxco aus Bad Nauheim bei Frankfurt und Codefrog aus Braunschweig. In seiner stärksten Phase beschäftigte Vizavy rund 120 Mitarbeitende und war besonders auf die Digitalisierung von Geschäftsprozessen spezialisiert. Die Mischung aus zwei Standorten und zwei Unternehmenskulturen hat Vizavy zu einem spannenden, auch wenn manchmal komplizierten, Umfeld gemacht. Wichtig dabei ist zu sagen, dass alle die Möglichkeit hatten von Zuhause zu arbeiten.
Eine Besonderheit innerhalb des Unternehmens war die Vizcademy. Diese Abteilung hatte die Aufgabe, nachhaltigen Nachwuchs für Vizavy aufzubauen. Das Team bestand idealerweise ausschließlich aus Studierenden und Umschülern – also Menschen, die noch am Anfang ihrer beruflichen Laufbahn standen. Der Team würde von 8 bis 12 Entwickler*innen, 1 Scrum Masterin und 1 Product Owner (ich) zusammengebaut.
Anders als in vielen anderen Unternehmen war die Vizcademy aber nicht nur ein Ausbildungsprogramm, sondern ein vollwertiges Team mit echter Produktverantwortung. Wir hatten dieselben Aufgaben, dieselben Erwartungen und dieselben Verantwortlichkeiten wie jedes andere Team im Unternehmen. Genau das machte die Arbeit dort so besonders: Man lernte nicht nur theoretisch, sondern trug von Anfang an Verantwortung für ein echtes Produkt.
Besonders stolz bin ich darauf, dass ich mich in relativ kurzer Zeit zu einem festen Bestandteil des Teams entwickeln konnte. Anfangs ging es natürlich vor allem darum, mich in das Projekt, die Prozesse und die technische Umgebung einzuarbeiten. Mit der Zeit konnte ich jedoch immer selbstständiger arbeiten, eigene Aufgaben verantworten und schließlich auch wichtigere Themen mittragen. Gerade in Phasen, in denen aufgrund von Urlaub oder Krankheit nur wenige Entwickler verfügbar waren, habe ich gemerkt, wie viel Verantwortung ich inzwischen übernehmen konnte. Gegen Ende meiner Zeit war ich sogar einer der erfahrensten Entwickler im Projekt, sodass vieles fachlich über mich lief und sich das Team in mehreren Bereichen auf mich verlassen hat.
Ein weiterer besonderer Schritt war für mich die Einarbeitung neuer Kolleginnen und Kollegen. Dass ich sogar eine Vollzeitkraft einarbeiten durfte, war für mich ein starkes Zeichen des Vertrauens und hat mir gezeigt, wie sehr ich mich fachlich und persönlich weiterentwickelt hatte. Gleichzeitig habe ich dabei gelernt, dass Verantwortung nicht nur bedeutet, eigene Aufgaben gut zu erledigen, sondern auch Wissen weiterzugeben und andere zu unterstützen.
Auch sozial habe ich in dieser Zeit viel gelernt. Die Zusammenarbeit mit Kolleginnen und Kollegen, Vorgesetzten und Kunden hat mir gezeigt, wie wichtig gute Kommunikation im Berufsalltag ist. Dabei geht es nicht nur um positive Abstimmung, sondern auch darum, offen mit Problemen, Missverständnissen oder unterschiedlichen Sichtweisen umzugehen. Gerade Formate wie Retrospektiven haben mir verdeutlicht, wie wichtig es ist, Dinge ehrlich anzusprechen und gemeinsam an Verbesserungen zu arbeiten.
Für mich persönlich war die Zeit bei der ITUC deshalb besonders prägend, weil sie mir gezeigt hat, was mir im Berufsleben wichtig ist. Ich habe gemerkt, dass mir Softwareentwicklung sehr viel Freude bereitet, vor allem dann, wenn am Ende etwas Greifbares und Sinnvolles entsteht. Gleichzeitig habe ich festgestellt, dass mir auch der Kontakt mit Kunden und die Zusammenarbeit im Team besonders wichtig sind. Insgesamt hat mich diese Tätigkeit fachlich sicherer, persönlicher selbstbewusster und beruflich orientierter gemacht. Dafür bin ich sehr dankbar.
]]>