Teil 1: Qualitätsmerkmale von Websystemen

Qualität von Websites fassbar machen

Daniel Takai

© Shutterstock/Gustavo Frazao

Schnelle und schöne Websites sind heute die Regel. Auf den Schultern der Riesen moderner Frontend-Technologien lassen sich höchst ergonomische und hübsch anzusehende Oberflächen herstellen. Das Fach hat sich daran gewöhnt: Wird ein neues System bestellt, so soll es selbstverständlich flott, sicher und attraktiv sein, zusätzlich auch auf dem Tablet oder dem Smartphone, das erst kommenden Monat in den Handel kommt.

Dass schnelle, sichere, geräteunabhängige und schöne Websysteme aber nicht einfach zu entwickeln sind, sondern Investitionen benötigen, ist dabei nicht jedem klar. Der Aufwand, der betrieben werden muss, lässt sich hinter der adretten Oberfläche nur erahnen. Tatsächlich zeigt sich, dass die gewünschten Eigenschaften aber Kostentreiber in der Entwicklung und im Betrieb sind: Möchte man ein schnelles System, so muss gegebenenfalls ein Content Delivery Network her, damit der Content auch weltweit schnell geliefert werden kann. Ein sicheres System sollte auditiert und im Labor angegriffen werden, um Schwachstellen zu finden. Ein schönes System braucht ein gut gemachtes Design in Kombination mit durchdachter Bedienbarkeit, und hier sind Design- und Usability-Experten nötig. Diese Liste ließe sich endlos fortführen und die Kosten summieren sich, sodass es geraten erscheint, nur auf die Qualitätsmerkmale Wert zu legen, die für das vorliegende System wichtig sind.

Aber welche Merkmale gibt es überhaupt, und welche davon sind für mich wichtig? Und wie kann ich dem Auftraggeber den Zusammenhang zwischen Qualität und den Kosten am besten erklären? Diese Wechselwirkung und die griffige Beschreibung von Qualität ist das Thema dieser neuen Artikelserie.

Qualitätsmerkmale

Ein Qualitätsmerkmal ist eine Eigenschaft eines Softwaresystems. Merkmale werden auch nicht funktionale Anforderungen genannt, um sie von den funktionalen Anforderungen zu unterscheiden. Funktionale Anforderungen beschreiben, was ein System tun soll; ein Qualitätsmerkmal hingegen beschreibt eine gewünschte Eigenschaft des Systems, die messbar und/oder testbar sein sollte (wie schnell, wie sicher etc.). Es gibt verschiedene Qualitätsmodelle, welche die Merkmale gliedern und hierarchisch anordnen, d. h., Merkmale können Submerkmale haben. Ein paar Beispiele für Qualitätsmerkmale sind:

Die Wartbarkeit beschreibt die Anpassbarkeit einer Software über ihren Lebenszyklus. Sie beeinflusst die Kosten von Änderungen am System. Websysteme sollten sich leicht ändern lassen, da sie oft von Marketinganforderungen getrieben werden, die wechselhaft sind, da sich Märkte, bzw. der Wunsch nach ihrer Bewirtschaftung, beständig wandeln. Deswegen ist eine hohe Wartbarkeit für Websysteme von entscheidender Bedeutung, denn wir gehen davon aus, dass sich ein solches System innerhalb einer nützlichen Frist und zu vertretbaren Kosten anpassen lassen muss, ansonsten wird es ersetzt. Die Wartbarkeit lässt sich beispielsweise analysieren nach Prüfbarkeit, Änderbarkeit, Analysierbarkeit, Testbarkeit oder auch Flexibilität.

Die Performance beschreibt die Sparsamkeit in Bezug auf Rechenzeit und Speicherplatz einer Software (Effizienz), deren Dynamik (ob sich die Performance im Laufe der Zeit verändern soll), sowie das Antwortverhalten des Systems (die insbesondere bei Webanwendungen aufgrund der geografischen Verteilung wichtig ist). Im Allgemeinen ist die Performance neben der Verfügbarkeit für viele Stakeholder das wichtigste Thema, auch weil sie diese im Browser selbst sehr gut beurteilen können. Lädt eine Webseite zu langsam, so sinken Besucherzahlen und der Page Rank bei Google. Stellt man hingegen zu viel Kapazität zur Verfügung, so sind die Kosten im Betrieb unverantwortlich. Eine korrekte Erfassung der Performance ist also wichtig. Die Performance lässt sich nach Kapazität, Latenz oder Skalierbarkeit analysieren.

Die Sicherheit eines Systems beschreibt, wie es die legitimen Interessen Dritter vertreten soll. Speichert ein System personenbezogene Daten, so haben diese Personen ein Interesse daran, dass diese Daten nicht missbraucht werden, und wir müssen sie entsprechend schützen. Die Sicherheit eines Systems zu beschreiben, bedeutet also, sich darüber klar zu werden, welche Arten von Daten verarbeitet werden, wer auf diese Daten Zugriff erhält und wie sie manipuliert werden dürfen. Im Allgemeinen wird Sicherheit nach den drei Faktoren Vertraulichkeit, Verfügbarkeit und Integrität analysiert.

Die Portierbarkeit beschreibt die möglichen Umgebungen, auf denen die Software betrieben werden soll. In der Webentwicklung wird die Portierbarkeit gerne übersehen. Man meint, dass die Software nur auf einem Webserver laufen muss. Dies ist aber nicht der Fall, denn in den meisten Fällen ist die Entwicklungsumgebung verschieden von der Test- und Produktionsumgebung, sodass die Software in Wahrheit auf drei verschiedene Umgebungen portiert werden muss. Ebenfalls steht nicht immer fest, wer das System später installieren und welche Kompetenzen diese Personen haben soll. Hinzu kommt ein Zoo an verschiedensten Browsern auf unterschiedlichsten Endgeräten, von denen aus das System bedienbar sein muss. Zur Portierbarkeit gehören also neben der Geräteunabhängigkeit auch die Installierbarkeit.

Unter Transparenz fasse ich die Anforderungen an die Sichtbarkeit eines Systems zusammen. Da Software unsichtbar ist und Werkzeuge zur Beobachtung manchmal selbst hergestellt werden müssen, lauern hier versteckte Kosten, die es im Vorfeld zu klären gibt. So möchte der Betrieb die Last auf den Maschinen beobachten können: Es soll rechtzeitig Alarm geschlagen werden, bevor die Platte voll läuft. Oft sind hier schon Werkzeuge wie Nagios im Einsatz, die aber auch integriert werden möchten. Im Marketing und der Redaktion sind hingegen andere Monitore nötig. Hier möchte man den Erfolg einer Kampagne messen oder sehen, wie viele Benutzer gerade einen Artikel lesen. Auch das Marketing hat eventuell schon Werkzeuge hierfür bereit, die integriert werden möchten. Neben der Wartbarkeit stößt vor allem die Transparenz bei den Stakeholdern auf großes Interesse, da sie aus dieser große Vorteile ableiten können. Es ist sehr gut, wenn hierfür benötigte Etats im Vorfeld besprochen werden können.

Architektur

Qualitätsmerkmale haben Einfluss auf das Systemdesign und damit auch auf das notwendige Budget für die Systementwicklung und den Betrieb. Ein einleuchtendes Beispiel ist die Verfügbarkeit. Eine hohe Systemverfügbarkeit bedeutet den Betrieb von vielen Servern oder Serverinstanzen (wenn das System in einer Cloud deployt wird), vielleicht sogar an mehreren Standorten; eine niedrige Verfügbarkeit den Betrieb von wenigen Servern oder Instanzen. Natürlich kostet der Betrieb von mehr Servern an mehr Standorten auch mehr Geld.

Der Grad des Einflusses auf das Systemdesign ist unterschiedlich. Einige Qualitätsmerkmale bedeuten nur kleine Änderungen oder können sogar organisatorisch umgesetzt werden. Andere Merkmale haben jedoch weitreichende Konsequenzen, die alle Systemteile berühren und massive Kosten auslösen können. Dies zu beurteilen obliegt dem Architekten, der entscheiden muss, wie ein gewünschtes Merkmal erreicht werden kann. Dabei kommt ihm eine schwierige Rolle zu: Er muss es nicht nur schaffen, das Merkmal griffig fassbar zu machen, um mit dem Fach darüber sprechen zu können; er muss auch die Auswirkungen auf die Architektur und die damit verbundenen Kosten transparent und nachvollziehbar machen.

Am Ende muss der Architekt dann die Entscheidungen auf Basis seiner Abstimmungen fällen. Hat man sich dann z. B. für AngularJS entschieden, wird das System auch bis an sein Lebensende mit diesem Framework auskommen müssen, da ein Umbau voraussichtlich enorme Kosten gemessen am Geschäftsnutzen auslösen würde. Dabei sind die Kosten nicht nur finanzieller Natur: Ein Umbau benötigt eben auch Ressourcen, die in dieser Zeit keine anderen Aufgaben wahrnehmen können, und somit kann die Zeitplanung durcheinander geraten. Ein weiteres Kostenkriterium ist auf der fachpolitischen Ebene auch das Renommee des Architekten: Man wird ihn daran messen wollen, ob seine Entscheidungen zu Projektbeginn richtig und vorausblickend genug waren.

Zusätzlich zu den Qualitätsmerkmalen werden auch Informationen zur gewünschten Funktionalität benötigt. Hier werden Sie möglicherweise bombardiert: 350 Seiten Grobkonzept, dazu 2 500 Seiten Feinkonzept, die die fachlichen Anforderungen aus dem 800 Zeilen langen Anforderungs-Excel abbilden. Von den 800 Anforderungen sind circa 700 als kritisch eingestuft, der Rest ist dem Fach lediglich wichtig. Schon auf den ersten Blick fallen Ihnen Wiedersprüche auf. Aus diesem Wust an Informationen haben Sie nun die Aufgabe, die wesentlichen Informationen zu extrahieren, die Ihnen erlauben, einen Architekturvorschlag zu konstruieren. Geben Sie also die Dokumente sofort zurück! Verlangen Sie vom Anforderungsingenieur eine Zusammenfassung der Geschäftsziele, die mit dem System erreicht werden sollen und lassen Sie Epics erstellen, die die Anforderungen auf einer hohen Abstraktionsebene bündeln. So haben Sie eine Chance zu verstehen, was mit dem System erreicht werden soll und kommen in der Architektur weiter. Meiden Sie Detaildiskussionen zu funktionalen Anforderungen, denn diese sind in der Regel nicht relevant für die Architektur [1]. Sehr schöne Diskussionen zu architekturrelevanten Anforderungen und zum Vorgehen finden Sie übrigens in [2] und [3].

Einen weiteren Einflussfaktor stellen die Rahmenbedingungen dar. Darunter verstehen wir allfällige Vorgaben, die wir bei unseren Entscheidungen in der Architektur berücksichtigen müssen. Beispiele für Rahmenbedingungen sind das verfügbare Budget, die Ausbildung der Projektmitarbeiter oder Compliance-Regulierungen, denen das Geschäft des Kunden unterliegt. Rahmenbedingungen sind in der Regel nicht durch uns veränderbar, aber sie müssen nicht notwendigerweise statisch sein. So kann es sein, dass sich eine Compliance-Regulierung im Laufe des Projekts verändert. Eine disziplinierte Dokumentation der Rahmenbedingungen kann wichtig sein, um Entscheidungen später verstehen zu können.

Abb. 1: Einflussfaktoren und Ergebnisse der Architektur

Abb. 1: Einflussfaktoren und Ergebnisse der Architektur

Die Erhebung von Qualitätsmerkmalen ist nicht nur für korrekte Architekturentscheidungen bedeutend, sondern auch ein wichtiger Faktor im Erwartungs- und Risikomanagement. Wie eingangs erwähnt, erwartet der Kunde im Regelfall ein schnelles, sicheres und schönes System, das sich gut warten lässt. Erwartet hingegen der Kunde keine hohe Wartbarkeit, so ist er später nicht überrascht, wenn sie zusätzliches Geld kostet. Wenn Sie also die gewünschten Qualitäten im Vorfeld besprechen, gibt es am Ende für alle Beteiligten keine Überraschungen mehr. Denken Sie immer daran: Die stillschweigende Erwartung des Fachs ist, dass das System schnell wie Google, sicher wie Fort Knox und schön wie die Mona Lisa wird. Wenn Ihr Entwurf auf Basis des verfügbaren Budgets diese Erwartungen nicht erfüllen kann und Sie dies kommunizieren, dann wissen das alle.

Gegebenenfalls identifizieren Sie dabei aber ein echtes Problem, beispielsweise wenn die Bedienbarkeit aufgrund der Kosten nicht erreicht werden kann; oder, was häufig vorkommt, die Anforderungen an die Wartbarkeit nicht mit der Releaseplanung vereinbar sind. Oft wünscht der Kunde einen Go-Live in drei Monaten, aber um die Wartbarkeit herzustellen, werden sechs Monate benötigt. Es lohnt sich an dieser Stelle, die Qualitätsmerkmale mit Projektrisiken in Beziehung zu setzen und an die Projektsteuerung zur Lösung zu übergeben. Eine strukturierte Ausweisung der Projektrisiken über die gewünschten Systemqualitäten, die zu einer rationalen Diskussion mit den Sponsoren führt, zeugt von einer hohen Maturität im Architekturprozess.

Nehmen wir nun einmal an, ein Kunde wünscht sich ein System, das nur eine bestimmte Aufgabe in einem bestimmten Zeitraum erfüllen soll, beispielsweise ein Christmas-Special: Der Auftragnehmer soll es so bauen, dass möglichst wenig Kosten bei der Entwicklung entstehen. Er gibt an, dass Änderungen an der Software nicht notwendig sein werden, und dementsprechend auf Code-Reviews oder Lesbarkeit der Quelltexte verzichtet werden kann. Auch automatische Tests sollen nicht entwickelt werden, weil die Software nur ein einziges Mal getestet werden muss. Dies kann der Auftragnehmer leisten und das Ergebnis ist funktional in Ordnung.

Entscheidet sich der Kunde jedoch später doch noch für Änderungen, so sind diese ungleich teurer, weil der Quelltext nicht lesbar ist und keine Tests existieren. Die Anwendung ist nicht wartbar, weil der Kunde dies nicht finanzieren wollte. Wurde dies vorgängig dokumentiert, so sind spätere Mehrkosten leicht zu begründen. Andernfalls kann dies negativ auf den Auftragnehmer zurückfallen, weil der Kunde stillschweigend davon ausgeht, dass die Wartbarkeit gegeben ist. Idealerweise hatte der Projektleiter die fehlende Wartbarkeit als Risiko geführt, sodass es auch im Steuerungsausschuss ein präsentes Thema war.

Websysteme

In dieser Artikelserie werden Qualitätsmerkmale anhand von Websystemen erläutert. Man nennt ein solches System auch ein sozio-technisches Feedbacksystem: Es handelt sich um ein von Menschen genutztes Informationssystem, das sich über die Zeit durch Feedback der Stakeholder verändert. Solche Systeme sind genau dann erfolgreich, wenn sie die Anforderungen der Stakeholder erfüllen, die das System verwenden. Dabei ändern sich die Anforderungen der Stakeholder stetig, da sich die Welt, insbesondere im Marketing, sehr schnell dreht. Websysteme haben also zumeist eine hohe Änderungsrate, und deswegen spielt die Wartbarkeit bei ihnen eine wichtige Rolle. Ein Websystem besteht typischerweise aus vier Schichten, wie Abbildung 2 zeigt. Ich werde im Verlauf dieser Serie immer wieder auf diese allgemeine Architektur zurückgreifen, um Qualitätsmerkmale zu diskutieren.

Abb. 2: Generische Architektur eines Websystems

Abb. 2: Generische Architektur eines Websystems

Die Benutzerschnittstelle heißt heute Frontend und lebt im Browser. Oft wird gewünscht, dass das Frontend auf allen Browsern laufen soll, was aber nicht möglich ist, da wir nicht alle Browser kontrollieren können (es ist eine Rahmenbedingung, dass sich Browser und Endgeräte stetig ändern). Wir können es aber selbstverständlich auf verschiedenen Browsern und Endgeräten testen, mit linearem Aufwand.

Das Frontend wird vom Backend geladen und bezieht auch seine Daten von diesem. Das Backend ist nur selten eine einzige Komponente, sondern besteht aus mehreren Einzelteilen mit sehr unterschiedlichen Aufgaben wie Authentifizierung, Caching oder Load Balancing. Wichtig ist dabei, dass es sich hierbei um unsere eigentliche Webanwendung handelt, die sich im Laufe der Zeit verändert.

Die Integration modelliere ich als dedizierte Schicht, die sich um die Anbindung von Daten- und Geschäftsdiensten kümmert. Dabei kann die Integrationsschicht auch selbst Teile der Geschäftslogik implementieren, ihre Hauptaufgabe ist aber die Entkopplung der Dienste, was Auswirkungen auf Wartbarkeit, Verfügbarkeit, Sicherheit usw. haben kann. Die Dienste selbst sind zumeist REST- oder SOAP-Services und gehören in der Regel nicht zu unserem System, sondern bestehen bereits und können konsumiert werden. Die Qualität der zu integrierenden Dienste hat einen erheblichen Einfluss auf die Qualität unseres Systems, zum Beispiel die Performance. Es ist heute eher selten, die Integrationsschicht als eigene Systemkomponente vorzufinden, sie ist zumeist ein Teil des Backends (siehe auch Point-2-Point als Anti-Pattern).

Nicht dargestellt ist die Entwicklungsinfrastruktur, die aber aufgrund der hohen Anforderungen an die Wartbarkeit ein wichtiger Bestandteil der Architektur ist. Eine ausführliche Diskussion wird es hierzu in einem Folgeartikel über Änderbarkeit geben.

Qualitätsszenarien

Wie bei Anforderungen üblich, ist die Messbarkeit ein wichtiger Faktor, damit objektiv festgestellt werden kann, ob ein System die gewünschten Qualitätsmerkmale tatsächlich erfüllt. Die Messkriterien von Qualitätsmerkmalen verlangen ein hohes Maß an technischer Kompetenz (Antwortzeiten, Last und Kapazität, Usability-Heuristiken usw.). Da dieses Verständnis auf der Fachseite nicht vorausgesetzt werden kann, braucht es also eine Brücke zwischen den notwendigen technischen Entscheidungsgrundlagen und dem fachlichen Verständnis auf der anderen Seite. Hierfür eignen sich Qualitätsszenarien als Kommunikationsmittel. Diese Szenarien beschreiben als hypothetische Aufeinanderfolge von Ereignissen das Verhalten des Systems in einer Art und Weise, die für das Fach verständlich ist und bilden damit eine gute Diskussionsgrundlage.

Die Erhebung der Szenarien ist schwierig. Oft müssen diese zu einem Zeitpunkt erhoben werden, an denen die Stakeholder noch gar kein klares Bild von der zukünftigen Lösung haben. Sie sind zudem sehr abstrakt, sodass sich auch ein erfahrener Entwickler oft nichts Konkretes unter ihnen vorstellen kann. Es bedarf also einer gute Kommunikationskompetenz, um die Merkmale verständlich beschreiben zu können, sowie einer sorgfältigen Dokumentation, um die Ergebnisse der Erhebung so zu formulieren, dass sie auch tatsächlich bei Architekturentscheidungen hilfreich sind. Der Architekt sorgt dafür, dass die Szenarien möglichst „spitz“ formuliert sind und sich stets auf nur ein einziges Qualitätsmerkmal beziehen. Eine Menge von Qualitätsszenarien beschreibt dann das Qualitätsmerkmal aus unterschiedlichen Perspektiven und erlaubt so eine ausreichende Definition derselben.

Ein Qualitätsszenario [1] beschreibt also eine bestimmte Systemqualität an einem fachlichen Beispiel, welches für den Stakeholder verständlich und beurteilbar ist. Ein solches Szenario entspricht dem Schema in Abbildung 3.

Abb. 3: Schema eines Qualitätsszenarios

Abb. 3: Schema eines Qualitätsszenarios

Die Quelle des Stimulus gibt an, woher der Reiz kommt (Benutzer, Administrator, externe Schnittstelle). Der Stimulus beschreibt eine spezifische Zusammenarbeit der Quelle mit dem System. Die Umgebung beschreibt den Zustand des Systems zu einem bestimmten Zeitpunkt. Das Artefakt ist in der Regel ein Funktionsblock oder ein anderer Baustein. Die Antwort wird über das Messkriterium überprüfbar gemacht.

Die folgenden Beispiele sind nach diesem Schema geschrieben und verständlich. Sie können sich als Übung Gedanken über mögliche Lösungsoptionen und damit verbundene Kosten in der Entwicklung machen:

  • Ein entfernter Benutzer sendet bei Hochauslastung des Systems eine Suchanfrage und erhält innerhalb von 5 Sekunden die erste Seite des Suchergebnisses.
  • Ein Entwickler kann während der Wartungsphase automatische Testfälle erstellen, die auch das Buchungssystem betreffen.
  • Ein Servicemitarbeiter kann auf die persönlichen Daten eines Kunden während des regulären Systembetriebs nicht zugreifen, sofern er nicht auch der Rolle „Kundendienst“ angehört.
  • Ein neuer Entwickler kann während der Systemevolution innerhalb von zwei Tagen Änderungen am System selbstständig durchführen.
  • Ein Administrator kann zu Spitzenzeiten die Kapazität des Systems selbstständig anpassen, ohne dass der Betrieb unterbrochen werden muss.

Nicht alle Eigenschaften können per Szenario beschrieben werden. Ein Rechte- und Rollenkonzept wird meistens als Matrix zwischen Berechtigungen und Ressourcen geführt. Dieses in Form von Qualitätsszenarien zu dokumentieren, ist unübersichtlich und wird deswegen nicht empfohlen. Auf diese Besonderheiten komme ich bei der Diskussion der einzelnen Qualitätsmerkmale zurück.

Rechtliches

Werden Qualitätsszenarien erhoben, so könnte man aus deren Messbarkeit ableiten, dass die gewünschten Werte immer erreicht werden können. Leider ist dies nicht der Fall. Es ist also für alle Beteiligten wichtig zu verstehen, dass Qualitätsmerkmale keine Verträge darstellen, sondern eine schwer messbare Beschreibung der Produkteigenschaften sind, von denen nicht immer klar ist, ob sie überhaupt eingehalten werden können.

Für eine Performanceanforderung wurde eine maximale Antwortzeit für einen gewissen Prozentsatz an Anfragen an das unter Last stehende System vorgegeben. Eine Messung würde voraussetzen, dass man ein zweites System, das mit der Produktionsumgebung identisch ist, zur Verfügung hat und dieses ausschließlich für die Tests zur Verfügung stellt, da Performancetests nicht auf einem Produktionssystem durchgeführt werden können. Es müsste zudem ein Eingabemuster entwickelt werden, das alle möglichen Kombinationen von Anfragen enthält. Beides ist technisch theoretisch möglich, aber nur schwierig finanzierbar.

Viele Qualitätsmerkmale sind auch methodische Absichtserklärungen und dienen der Vollständigkeit in Design und Planung des Systems oder um Erwartungen auf der politischen Ebene zu kanalisieren. Nehmen Sie das Beispiel von oben, bei dem sich ein Entwickler innerhalb von zwei Tagen in das System einarbeiten können muss. Da müssten Sie dann viele Abgrenzungen einfließen lassen, bevor sie das als Vertrag unterschreiben möchten.

Vertraglich relevant sind Qualitätsmerkmale hingegen insofern, als dass ihre Umsetzung aufwändig sein kann. Eine Diskussion dieser Merkmale lenkt also auch die Aufmerksamkeit des Kunden weg von der reinen Funktionalität hin zu Themen, die in vielen Fällen für den Erfolg des Systems relevanter sind, als eine große Menge von Funktionen in der Software.

Schlussendlich kann über den Erfüllungsgrad der Anforderungen die Qualität der Architektur in Bezug auf die fachlichen Wünsche aber durchaus gemessen werden. Hiervon geht beispielsweise die ATAM-Methode (Architecture Tradeoff Analysis Method) aus. In den wenigsten Fällen basieren diese Messungen jedoch auf harten Daten, sondern werden per Gutachten oder Heuristik interpretiert. Es ist üblich, an dieser Stelle auch auf weiche Indikatoren zu setzen. Stefan Toth hat in seinem Buch über Vorgehensmuster in der Architektur hierfür ein paar gute Beispiele [4].

Fazit

Die Erhebung der Qualitätsmerkmale ist essenziell, wenn man ein passendes System entwerfen möchte, mit dem der Auftraggeber am Ende zufrieden ist. Ein System kann funktional fehlerfrei sein und doch den Kunden maßlos enttäuschen, weil seine stillschweigenden Erwartungen nicht erfüllt wurden. Dem Architekten kommt die schwierige Rolle zu, diese Erwartungen im Rahmen des vorhandenen Budgets über die Qualitätsmerkmale zu verhandeln. Dafür benötigt er neben Kommunikationskompetenz und Weitsicht auch ein gutes Stück Gelassenheit. Belohnt wird diese offene und transparente Arbeit durch ein nützliches System, mit dem der Kunde glücklich sein kann.

Aufmacherbild: Hand with marker von Shutterstock / Urheberrecht: Gustavo Frazao

Verwandte Themen:

Geschrieben von
Daniel Takai
Daniel Takai
Daniel Takai ist Enterprise-Architekt, arbeitet in der Schweiz und ist auf die digitale Transformation spezialisiert. Er berichtet regelmäßig im Java Magazin über seine Erfahrungen und Erkenntnisse. Im Frühling 2016 erscheint sein Buch über Methoden der Entwicklung von Cloud-basierten und serviceorientierten Websystemen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: