Collaboration Framework Webprojekt

Anforderungen Vorauswahl

• Projektumfang
• Über den Auftraggeber
• Fristen
• Entscheidung
• Entschädigung
• Nach dem Pitch

Anforderungen Vorauswahl

• Schriftliche Überlegungen zur Aufgabe
• 3 Arbeitsbeispiele
• Agenturporträt
• Schreiben zur Eignung der Agentur für die Aufgabe
• Entschädigung

Der Auftragnehmer  liefert im Zuge des Offert-Verfahrens der Phase eins bereits eine Leistung an den Auftraggeber, indem er sich detailliert vorstellt (Agenturpräsentation) und seinen Lösungsweg aufzeichnet. 
Der Auftraggeber soll in der ersten Phase keine detaillierten Kosten zu Projekten einfordern, die Agentur-Tarife und Stundenansätze dienen als Richtwerte. In der ersten Phase sollen auch keine strategischen Lösungswege oder kreativen Konzeptideen verlangt werden.

Anforderungen finale Auswahl

• Briefinggespräch
• Schulterblick/Rebriefing
• Ausfallhonorar
• Nachgespräch

Anforderungen finale Auswahl

• Briefing
• Schulterblick/Rebriefing
• Präsentation/Pitch

Es ist es wichtig zu verstehen, welche Vision die Applikation hat und was sie bewirken soll. Die Vision wird mit anhand der folgenden Ingredienzen definiert:

• Personas: Welches sind die Benutzer der zu erstellenden Anwendung? Hier muss präzise in der Form von Personas formuliert werden. Siehe Tipps. Zudem ist es gut, Personas zu priorisieren – welche ist uns am wichtigsten?
• Ziele: Was soll der Sinn der Anwendung sein? Was will man damit erreichen? Erfahrungsgemäss sind die Ziele meist zu ungenau definiert. Eine genaue Definition hilft jedoch, einen hohen ROI zu erhalten. Wichtig zu fragen ist auch: Warum hat die Auftraggeberin dieses Ziel? Das Warum gibt oft sehr schnell Aufschluss darüber, welche Priorität ein Ziel hat. Dies hilft wiederum (s. letzter Punkt), das Budget richtig zu investieren.
• Bedürfnisse der Personas: Welche Bedürfnisse haben die Personas.
• Ausblick: Der Auftraggeber  formuliert einen Ausblick auf die nächsten 3 bis 5 Jahre.
• USP: Die Auftraggeberin definiert, wie die Applikation im Vergleich mit der Konkurrenz wahrgenommen werden soll.
• Umsysteme und  Prozesse: Es wird erläutert, wie Prozesse im Hintergrund vernetzt werden sollen, um effizienter in den Geschäftsabläufen zu werden und welche Systeme Einfluss haben werden.
• Priorisierung: Bestimmen, welches die Ziele mit höchster Priorität sind. 
• Erwartungen: Es ist empfehlenswert, im Vorlauf zu klären, was die Auftraggeberin und den End-User begeistern oder enttäuschen würde.
• Workshops: Meist ist es einfacher und schneller, die Vision nicht schriftlich zu formulieren, sondern sie mit der Auftragnehmerin und der Auftraggeberin in einem Workshop zu klären. So verstehen alle Beteiligten die Vision und können sich damit bei der Entwicklung identifizieren. 

Damit die Auftragnehmerin das Vorhaben versteht und effizient arbeiten kann, ist sie darauf angewiesen, die «User Journey» zu kennen. Es wird empfohlen, dass die funktionalen Anforderungen gemäss der «User Journey» beschrieben werden.

Horizontal und vertikal definieren

• Horizontal: Auftragnehmerin und Auftraggeberin beschreibengemeinsam ganz grob (in ca. 5 bis 7 Punkten), welche Schritte die Benutzer in der Anwendung durchlaufen müssen. Dies könnte z.B. so aussehen: 
  Übersicht Home – Klick und Übersicht Job-Angebote – Suche mit Filter – Übersicht Resultate – Klick und Detail-Information für Job – Klick und Bewerbung erstellen und abschicken. 
  Es sind die ganz groben Brocken der Anforderungen an die Applikation (Epics).
   
• Vertikal: Von nun an gehen Auftragnehmerin und Auftraggeberin gemeinsam ins Detail der einzelnen Epics und formulieren –aber nur dort, wo es wirklich geschäftsrelevant ist –, was genau für die Umsetzung der Epic benötigt wird. Zum Beispiel:
  • Übersicht Resultate
    • Die Resultate werden von einer Datenbank eines Dritt-Partners gezogen.
    • Es ist wichtig, dass das Branding jeder Firma mit einem Job-Angebot herausstechen kann.

Insgesamt entsteht somit ein Anforderungskatalog, der einerseits horizontal – die Reise des End-Users in Schritten von links nach rechts durch die Applikation – und andererseits vertikal -– wie gehen die Benutzer bei jedem Schritt in die Tiefe. Dadurch entsteht quasi eine Karte der Applikation, die es der Auftragnehmerin erlaubt, die Gedankengänge und Wünsche der Auftraggeberin zu verstehen.

Es ist sehr wichtig, dass die Auftraggeberin der Auftragnehmerin alle möglichen Informationen übermittelt. Dabei darf man nicht arbeitsscheu sein, denn es schadet sonst der Qualität der zu entwickelnden Applikation.

Unklare Aussagen

Unklare Aussagen bergen ein hohes Risiko in der Entwicklung und sind meistens vom Aufwand her nicht einschätzbar. Sie können das Projekt also gefährden.

Es empfiehlt sich also:

• einen transparenten Zugang zu den Informationen möglich zu machen
• Budget einzuplanen für Spikes oder Proof-of-Concept – siehe Definitionen.

Hier zu sparen ist riskant. Böse Überraschungen später im Projekt kommen teuer zu stehen.

Welche Geräte werden vom End-Kunden genutzt – Mobile (native? web-app? responsive?), Tablet, Desktop? Damit wird bestimmt, auf welche Arten die Applikation designt und programmiert wird.

Die Aufraggeberin sollte definieren:

1. in welchen Browsern soll die Applikation laufen (inkl. Mobile Anforderungen)
2. auf welchen Browser-Versionen sie laufen soll (älteste, noch gewollte Version angeben)
3. auf welchen Browser-Versionen eine perfekte Programmierung ausgewiesen werden soll (jeder Fehler muss pixel-perfekt korrigiert werden);
4. auf welchen Browser-Versionen eine optimale Programmierung ausgewiesen werden soll (man lässt gewisse Ungereimtheiten zu)

Die meisten Web-Entwicklungsfirmen bieten heute kein Hosting mehr an, da dies eine hohe Expertise verlangt – auch in Bezug auf die Sicherheit und Laufzeiten.Trotzdem kann die Auftraggeberin Auskunft geben über:

• Hoster, denen sie vertraut
• das passende Dienstleistungspaket beim Hoster gemäss Anforderungen der Anwendung
• die ideale Entwicklungsumgebungen, sodass die Entwicklung auf verschiedenen Ebenen optimal zusammenspielt und auch in der Abnahme durch die Auftraggeberin oder beim Go-Live keine Probleme entstehen.
• Cloud ja oder nein

Der Grad an Sicherheit, der von der Auftraggeberin definiert wird, hängt extrem stark vom Ziel der Applikation ab. Je nach dem ist auch die Vernetzung der Systeme, die sich hinter der vom Nutzer bedienten Applikation verbirgt, die sicherheitstechnisch relevante Frage (oft der Fall bei Corporate Seiten mit einem Login auf andere Services).

Achtung: Mai 2018 trat GDPR (General Data Protection Regulation) der EU in Kraft, dieser gilt auch für die Schweiz. Siehe dazu den Wikipedia Artikel GDPR.

Barrierefreiheit ist eine Chance, denn eine Applikation, die barrierefrei ist, hat per se eine bessere Benutzererfahrung (User Experience) und ist damit eine bessere Applikation für alle Benutzer.

Mehr zum Thema im Wikipedia-Artikel zu barrierefreiem Internet und konkrete Standards und Informationen auf der Webseite für barrierefreie Technologienutzung.

Die Auftraggeberin hat sich also zu entscheiden, sie Standard A, AA oder AAA will (bei öffentlichen Institutionen ist AA obligatorisch). 

Wie schnell eine Applikation ist, kann für den Geschäftserfolg grundlegend sein. Natürlich ist der Benutzer heutzutage an schnellere Systemantworten also noch vor ein paar Jahren gewohnt. Im Sinne des Ziels der Applikation sollte definiert werden, was Schnelligkeit der Systemantwort für das Geschäft bedeutet.

Die Architektur, die für die Applikation gewählt wird, und deren angehängte Systeme, haben einen enormen Einfluss auf die Performanz der Applikation.

SEO und Analytics sind erfolgsrelevant und sollten von Anfang an in die Überlegungen miteinbezogen werden. Ein Workshop ist hilfreich, um Leitplanken und messbare Ziele zu setzen.

Der heutige User ist an Applikationen wie Airbnb, YouTube, und andere ähnliche gewohnt. Sie alle haben eine einfache und intuitive Benutzerführung. Das setzt heute den Standard. Eine gut geplante und vor allem getestete Benutzerführung ist ein Muss. Sie beeinflusst nicht nur direkt den Erfolg der Applikation, sondern auch den Ruf der Marke.

Gute User Experience wird anhand von Methoden definiert, die auch Benutzer-Recherche sowie Benutzer-Testing beinhalten.

Applikationen mit einer guten User Experience werden vor allem durch objektive Massstäbe (wie Recherchen, Testings, etc.) definiert. 

Die Frage bei der Entwicklung des Visual Designs lautet: «Was braucht meine Persona?» Potenzielle Kundinnen für ein Luxusprodukt erwarten ein anderes visuelles Design als Lageristen, die eine Anwendung für Logistik-Informationen bedienen müssen. 

Es ist empfehlenswert, Code Qualität und Wünsche zur Dokumentation zu besprechen und eventuell auch abzumachen (über eine «Definition of Done»). Wieso?

• Eventuell möchte die Auftraggeberin die Weiterentwicklung einer Applikation an einen neuen Auftragnehmer vergeben.
• Als Agentur betonen, dass es wichtig ist, dass sich die Entwickler Zeit nehmen, um sauber zu programmieren. Kosten für Fehlerbehebung und Wartung sind dadurch tiefer.

Wie wird eine gute Code-Qualität sichergestellt?

Meist ist die Auftraggeberin selbst keine Entwickler inund hat daher Schwierigkeiten, zu überprüfen, ob die Code-Qualität stimmt. Anhand der folgenden Anforderungen kann sichergestellt werden, dass Prozesse, die zu einer guten Code-Qualität führen, eingehalten werden.

• Code Review durch einen anderen Entwickler. Dabei werden Fehler gefunden, die der Entwickler selbst während der Erarbeitung übersehen hat.
• Automatisierte Tests: Der Auftraggeberin muss klargemacht werden, dass dies für die Nachhaltigkeit der Applikation und der Investition ein Muss ist.
• Manuelle Tests: Jede durch die Auftragnehmerin umgesetzten Anforderung muss durch die Auftraggeberin kurz nach der Entwicklung getestet und freigegeben werden. 

Wichtig ist die Durchmischung, das heisst:

• gute Verteilung von Senior- und Junior-Kräften. Es ist wichtig, dass Senior-Kräfte mit im Team sind, um gemachte Erfahrungen wiederholen zu können – oder eben auch nicht. Es ist aber ebenso wichtig, dass Junior-Kräfte im Team sind, denn sie bringen oft neuartige Ideen ein.
• cross-funktionales Team (z.B. Entwickler, User-Experience-Spezialist, Projektleiter, Analytics-Spezialist, Visual Designer etc.). Wenn verschiedene Experten zusammen arbeiten, wird eine vollumfassende Lösung der Applikation die Folge sein.
• ein fixes Team, mindestens für die Dauer des Projektes. So geht während der Entwicklung kein Knowhow verloren. Zudem behält das Team den Fokus auf das Ziel der Applikation.
• Diversität von Geschlecht, Nationalität, andere Kriterien. Bei einer barrierefreien Applikation mit Standard AAA ist es wichtig, dass ein Mitglied selbst diese Benachteiligung hat. Oder bei einem Shop, der Frauenkleider verkauft, ist es wichtig, beim Design und auch in der Entwicklung einen hohen Frauenanteil zu haben. Diverse Teams machen bessere Applikationen, weil sie als Team die Mini-Welt der Applikation repräsentieren.

Es kann gar nicht genug betont werden, wie wichtig eine hürdenlose, präzise Kommunikation zwischen dem umsetzendem Team und der Auftraggeberin ist. Eines vorab: E-Mail-Kommunikation reicht nicht. Webprojekte brauchen Kommunikationsinstrumente, die auf die Bedürfnisse von solchen Projekten ausgerichtet sind und die von allen einfach und schnell bedient werden können. In solchen Instrumenten werden auch Entscheidungen dokumentiert, die für die Applikation erfolgsbestimmend sind und auch nach dem Projektabschluss als Wissensbasis dienen. Daher reichen E-Mail oder Telefon nicht aus. Die folgenden Instrumente sind empfohlen:

• Atlassian Confluence: Damit werden Konzepte dokumentiert, wie nicht-funktionale Anforderungen, Definition of Done, Projektorganisation etc.
• Atlassian Jira: Damit wird der ganze Katalog der Arbeiten dokumentiert. Beide, d.h. Auftragnehmer und Auftraggeber haben darauf Zugriff. Dort werden die einzelnen Teilaufgaben definiert, diskutiert, kommentiert und schliesslich auch abgenommen.
• Slack oder ähnliches Chat-Tool: Es erlaubt einen sehr schnellen Austausch zwischen Auftragnehmerin und Auftraggeberin. Hier müssen ein paar Regeln gelten, die die Partner untereinander abmachen sollten, damit die Arbeiten nicht dauernd gestört werden.  Trotz dieses Risikos überwiegen die Vorteile.
• Regelmässige Sitzungen, an denen wichtige Entscheide und nächste Projektschritte im persönlichen Austausch getroffen werden (siehe dazu auch «Vorgehen»).

Prinzipiell gibt es zwei Methoden: Wasserfall oder Agil

Gemäss dem Trends & Benchmarks Report 2016 von Swiss Q, sind die agilen Projekte zu 60 % erfolgreich, bei der Wasserfallmethodik nur zu 45 %.

Software-Entwicklung ist – in der grossen Mehrheit – eine komplexe und daher nicht im Voraus planbare Aufgabe. Die Wasserfall-Methode eignet sich für komplexe Vorhaben nicht.

Die agile Methode verspricht – auch wenn Sie sich zu Beginn etwas komisch anfühlt – einen höheren Projekterfolg, einen besseren Return on Investment, einen schnelleren Go-to-Market, eine bessere Code-Qualität sowie eine auf den Benutzer besser abgestimmte Applikation.

Wie gesagt: Die grosse Mehrheit der Software-Entwicklungsprojekte sind komplex, mit sehr vielen Unbekannten, und verlangen daher nach der agilen Methode.

Bereits beim Auswahlverfahren der Auftragnehmerin können spätere Support- und Wartungsleistung definiert werden. Daraus wird auch ersichtlich, wie die Applikation während der Entwicklung dokumentiert wird: Nur eine gut dokumentierte Applikation kann einwandfrei in den Support übergeben werden. Je komplexer die Applikation ist, umso höher werden die Kosten der Wartung sein.

Wichtige Punkte im SLA sind:

• Wie werden Updates der Versionen gehandhabt?
• Wie werden Einsatzzeiten gehandhabt (Pikett am Wochenende oder nur Bürozeiten)?
• Wie werden die Kriterien für den Support definiert (Kritikalität der Störungen)?
• Wie werden kleine oder grosse Erweiterungen der Applikation gehandhabt?

Die Auftragnehmerin sollte der Auftraggeberin schon in der Offert-Phase ein Muster vom Support und Wartungs-Vertrag zeigen und eine grobe Kostenschätzung machen können.