Ich spare mir die schon 1000 mal zitierte Geschichte über den Misserfolg von Projekten aufgrund von Fehlplanungen, fehlenden oder nicht ausreichend definierten Anforderungen, mieser Qualitätssicherung, nicht adäquaten Projektmitarbeitern, dem Einsatz der falschen Technologien oder nicht zuletzt dem Spar-Bedürfnis des zentralen Einkaufs mit den dazugehörigen Folgen. Die Menge an Ressourcen, die verbraucht werden, und die Enttäuschung von Projektmitarbeitern, Kunden, Partnern etc. die damit einhergeht, ist untragbar. Wenn Du das nicht als Herausforderung, sondern als „damit-muss-man-halt-leben“-Gegebenheit ansiehst, dann hör an dieser Stelle auf zu lesen. Du bist nicht meine Zielgruppe. Sorry. Ich möchte etwas verändern und nicht missionieren.
Ich möchte gerne über Nachhaltigkeit schreiben. Über Nachhaltigkeit in der Produktentwicklung, wo Ressourcen berücksichtigt und in den Mittelpunkt gestellt werden müssen: Ich rede dabei nicht von Menschen, auch wenn die oft abstrakt als solche Ressource bezeichnet werden, sondern die Arbeit von Menschen und die investierte Lebenszeit der involvierten Menschen (sowohl als Projektmitarbeiter aber auch als Kunden), die eingesetzten Technologien sowie unsere Umwelt und die damit verbundene Zukunft. Ich möchte jedes Projekt zum Erfolg bringen bzw. den Weg dahin zumindest so ebnen, dass es mit sehr großer Wahrscheinlichkeit gelingen kann.
Jedes Projekt fängt mit einer Herausforderung an. Das Ziel ist, etwas zu verändern, etwas besser zu machen. Es geht immer um Ressourcen, Menschen, Umwelt und nicht zuletzt ums Geld. Vielleicht sogar um Macht in allen ihren Varianten und Ausprägungen. Nicht immer, aber oft. Jemand sieht diese Herausforderung und möchte sie gelöst haben oder macht sich selbst an die Lösung. So auch bei Softwareprojekten. Hier will man den aktuellen Status verändern, egal ob es sich um eine Ablösung oder eine Veränderung eines vorhandenen Systems oder die Schaffung eines neuen handelt. Man will eine Situation neu beherrschen. Innovation ist das Wort. Schon damals als die Cobol-Programme entstanden sind. Bei allen Softwaresystemen, die ich kenne, sind immer Menschen betroffen. Entweder intern im Unternehmen als diejenigen, die dann damit arbeiten müssen, oder extern als Kunden, also solche, die dafür bezahlen, damit arbeiten zu dürfen. Kunden, die Bedürfnisse haben. Wenn dem so ist, wieso involviert man Menschen dann nicht ausreichend und fortdauernd, damit das, was sie bekommen, das ist, was sie wollen und erfolgreich einsetzten können? Wir wollen diesen Ansatz für uns konsequent verfolgen, um am Ende ressourcenschonend immer genau das zu liefern, was die Kunden benötigen. Und um uns und unsere Produkte und Dienstleistungen mit dem Leben der Kunden zusammen weiterzuentwickeln.
Daher erfragen und hinterfragen wir zunächst immer die Bedürfnisse des Kunden, definieren und testen sie. Sie liefern uns validierte Anforderungen an unser Produkt, welche wir in unserem Backlog als User-Story definieren können. Als Methode nutzen wir hierfür die von Google Ventures hervorgebrachten Design Sprints, die inzwischen von vielen wie auch uns adaptiert, kondensiert und verbessert wurden. Der Kunde ist involviert in dieser Phase und erlaubt uns die zur Verfügung gestellten Ressourcen maßvoll einzusetzen sowie Menschen in angemessener Art und Weise einzubinden. Es wird nichts doppelt und nichts Überflüssiges erstellt. Erst validierte, zielgerichtete Ergebnisse erlauben es uns, im Anschluss in die nächste Phase einzusteigen. Erst wenn wir genau wissen, was der Kunde will, dann weiß auch das Entwickler-Team, was es tun muss, um diese Ergebnisse zu produzieren und vor allem hinreichend den Kundenbedürfnissen entsprechend zu testen. Der Kunde begleitet die Entwicklung und antwortet auf die gestellten Fragen, das Team kann keinen irrigen Weg nehmen. Am Ende haben wir die Funktionalität, die der Kunden haben will. In dieser konstanten Iteration zwischen Kunde und Team entsteht die Nachhaltigkeit in allererster Linie.
Nachdem wir dieses Feedback-PingPong oft genug angewendet haben, können wir selbstsicher die zur Verfügung gestellten Funktionalitäten als MVP (minimum viable product) in die Welt entlassen. Das heißt, das Produkt geht in Produktion. Dieser Schritt geschieht ebenfalls in Begleitung des Kunden, er übernimmt sämtliche Abnahmetests. Es kommt nichts auf den Markt, was vorher nicht ausführlich definiert, besprochen und mit dem Kunden getestet wurde. Alles in kleinen Schritten. Agilität in welcher Form und Ausprägung auch immer bildet die Basis für Kundennähe und Ressourcenbewusstsein.
Diese beständige Iteration aus Design Sprint, Entwicklung und Produktion hin zum nächsten Design Sprint nennen wir CustDevOps. Der Unterschied aus unserer Sicht zu BizDevOps ist, dass wir nicht das Geschäft, sondern den Kunden im Auge haben und dass dieser daher ein Teil des Buzzword sein muss: Vom Business (Biz) lenken wir den Fokus weg auf den Kunden (Customer, also Cust). Die Ergebnisse unserer Design Sprints liefern sehr wertvolle, validierte User Stories für die Entwicklung. Die enge Zusammenarbeit mit dem Kunden in der Entwicklungsphase und die enge Begleitung in die Produktion führt dazu, dass ein validiertes Produkt ressourcenschonend und menschenwertschätzend und arbeitsachtend erstellt wird. Es wird nichts Überflüssiges mehr geschaffen und es wird nichts für die Tonne erstellt. Alles scheint fast magisch zu sein. Theoretisch. Aber Achtung, wir arbeiten mit Menschen und mit Technologien und nicht zuletzt mit Methoden. Das Team muss zu dieser Arbeitsweise passen und diese auch zu einhundert Prozent leben und lieben. Das Team muss als Team agieren. Und der Kunde muss sich zu einhundert Prozent auch als Teil des Teams sehen. Die Erfolge müssen gefeiert werden und die Fehler müssen korrigiert und aus diesen gelernt werden. Es bedarf einiges hierzu! Aber es ist machbar und Du kannst es so wie wir angehen. Die Ergebnisse sind vielversprechend.
trendig
