Mit einem Pflichtenheft und einem Lastenheft ist für den Unternehmer als auch für den Kunden alles klar geregelt. Missverständnisse können schon beim Beginn eines Projekts vorgebeugt werden.

Wer kennt das nicht: ein neues Projekt steht vor der Tür und mit ihm die verschiedenen Erwartungen des Kunden an den Programmierer.

In der Regel formuliert der Kunde seine Vorstellung vom Projekt und der Auftragnehmer informiert ihn über seinen Aufwand. Meistens sind die Wünsche des Auftraggebers jedoch sehr umfangreich und werden im ersten Gespräch meist verbal mitgeteilt.

Sollten diese Informationen nicht klar definiert und festgehalten werden, kann dies schwerwiegende Folgen für beide Seiten mit sich bringen.

Was verbal oder schriftlich klar kommuniziert wird, kann allerdings anders als erwünscht erfasst und in die Tat umgesetzt werden.

Dadurch können sich Projektlaufzeiten verdoppeln und andere Projekte dadurch gefährdet werden, weil die Arbeitskraft bei anderen Projekten fehlt. Besonders in der IT-Branche ist dies ein bekanntes Grundproblem.

Mit der Erstellung von einem Lastenheft (kurz ‚L‘) und einem Pflichtenheft ( kurz ‚P‘) kann man hier für mehr Klarheit schaffen.

Der kleine aber feine Unterschied

In der Umgangssprache werden diese beiden Begriffe gerne gleichwertig verwendet. Sowohl erfahrene Programmierer, Projektleiter als auch unerfahrene aus der Softwareentwicklungsbranche sind sich nicht immer ganz im Klaren was es mit den Dokumenten auf sich hat.

Gerne wird hier von einem „Anforderungsdokument“ gesprochen. Auch in der Praxis ist der Unterscheid zwischen den beiden Dokumenten sehr fließend. Und doch besteht eine gravierende Differenz, welche in diesem Artikel wiedergegeben werden.

Für beide Dokumente gilt, dass sie zur Grundlage der klaren Zusammenarbeit von Arbeitgeber und Arbeitnehmer bei einem neuen Projekt dienen.

Das Lastenheft hält die gesamten Anforderungen des Auftraggebers an den Auftragnehmer fest. Es handelt sich also um eine Kundenspezifikation. In der Regel wird dieser Beleg vom Kunden erstellt.

Das Pflichtenheft wird dagegen generell vom Auftragnehmer/ Dienstleister erstellt. Hier wird in konkreter Form dargestellt, wie und womit der Dienstleister das Projekt für den Kunden zur Verfügung stellen kann.

Erst nachdem der Arbeitgeber dem P zugestimmt hat, sollte mit der Umsetzungsarbeit des Projektes begonnen werden.

In der Praxis kommt es jedoch vor, dass der Kunde bei der Erstellung des Pflichtenhefts involviert ist. Deshalb ist der Übergang von L zu P generell sehr fließend und sicherlich auch ein Grund, warum viele mit diesen Begriffen gar nicht so viel anfangen können.

L – Die Wünsche und Erwartungen des Kunden

Im Lastenheft hat der Auftraggeber freie Bahn alle seine Vorstellungen, Wünsche und Erwartungen schriftlich festzuhalten. So erstellt der Kunde das Gesamtbild des Projektes in einem strukturierten Dokument, woraus ein Anforderungskatalog entsteht.

Was ist einem Lastenheft nicht fehlen darf:

• In einem Lastenheft sollte der jetzige IST-Zustand beschrieben werden. So kann nachvollzogen werden, welche Voraussetzungen bereits gegeben sind oder noch fehlen
• Detailliert sollte der Auftraggeber beschreiben, welcher SOLL-Zustand angestrebt wird. Die genaue Zielsetzung ermöglicht eine konkretere Lösung seitens des Dienstleisters
• Die genaue Beschreibung der Anforderung an den jeweiligen Funktionen
• Definition der Zuständigkeit. Im Vorfeld festlegen welche Instanz für welchen Bereich zuständig ist
• Zeitliche Vorgaben, Projektorganisation und Meilensteine sind ebenfalls wichtige Bestandteile des L

Je nach Anforderungen des Unternehmens, ist es besonders empfehlenswert eine Strategie in Sachen IT im Vorfeld mit den gewünschten Softwarelösungen festzuhalten, um somit die Rahmenbedingungen zu haben.

Dies erleichtert die Suche nach einem passenden Partner in der Softwareindustrie, da die Informationsgrundlage immer dieselbe bleibt, was bei einer mündlichen Kommunikation kaum möglich ist.

Mit einem Lastenheft lassen sich verschiedene Angebote bei potentiellen Auftraggebern einholen. Die klare Definition der messbaren Ziele ermöglichen auch aus Sicht des Softwarelieferanten eine klare Projektwiedergabe.

Generell werden Anforderungen in diesem Dokument durch Textbeschreibungen und Bildern wie Zeichnungen, Tabellen oder Ablaufdiagramme dargestellt.

In der Praxis kann beispielsweise man ein Google Doc erstellt werden, wo alle Teilnehmer des Projekts (seitens des Kunden und des IT-Dienstleisters) involviert sind. So können schnell und praktisch weitere Inputs hinzugefügt werden. So kann gegebenenfalls sogar aus dem Lastenheft das Pflichtenheft entstehen.

P – konkrete Lösungen für den Kunden

Nach dem nun der potentielle Kunde klar definiert hat, welche Zielgrößen erwartet werden, kann der Dienstleister im Pflichtenheft genau definieren wie die Lösung umgesetzt aussehen wird.

Dies stellt – generell zusammen mit einem Angebot – den vertraglichen Grundriss der zu erfüllenden Leistungen dar.

Auch aus diesem Grund ist es wichtig die detaillierte Formulierung von Zielen festzuhalten. Besonders in der IT und Softwareentwicklung gilt: Was sich einfach vom Kunden formulieren lässt, muss nicht unbedingt einfach in der Programmierung sein. Daher sollte gerade der Dienstleister prüfen ob die Anforderungen in der gewünschten Form, in einem akzeptablen Zeitrahmen, in guter Qualität geliefert werden können.

Die genaue Abgrenzung des Leistungsspektrums und der – nicht möglichen Ziele – sind essentiell zur Erfüllung des Projekts, die eine diskussionsfreie Ebene bei der Abgabe des fertigen Produkts/ Dienstleistung ermöglicht.

Zusammen mit dem Softwareanbieter wird der Leistungsumfang der beschriebenen Lösung mit dem L abgeglichen. Hierbei wird genauestens festgelegt welche Standards zum Einsatz kommen und wo gegebenenfalls individuelle Programmierungen notwendig sind.

Bei einer rein individuellen Lösung für das Unternehmen, ist es besonders wichtig im Vorfeld genau festzulegen, welche Ergebnisse erzielt werden sollen. Die genaue Beschreibung ist allgemein ein wichtiger Faktor, damit das Projekt erfolgreich abgeschlossen werden kann.

Ebenfalls ist zu beachten, wie sich die neue Software in die vorhandene IT-Systeme integriert und wie die genauen Schnittstellen aussehen sollen, damit ein problemfreier Informationsfluss möglich ist.

Die Notwendigkeiten an Hardware, Datenbank oder auch Netzwerke sollten ebenfalls im Pflichtenheft festgehalten werden.

Die klare Definition kann idealerweise spätere Nachbesserungen und Korrekturen vermeiden, die für den Dienstleister und den Kunden Zeit und Geld bedeuten.

Ist die Erstellung der Dokumente sinnvoll?

Grundsätzlich empfehlen sich diese Dokumente immer – besonders bei großen Projekten. Allerdings eignet es sich auch bei kleineren, nicht so umfangreichen Projekten. Da das P zu einer Leistung zählt, kommt es vor das dies ebenfalls berechnet wird.

Aus diesem Grund wird generell erst ab einer bestimmten Größe des Projekts ein Pflichtenheft in Auftrag gegeben.

In der Praxis ist der Übergang der beiden Dokumente meist fließend.

Es lohnt sich Zeit in die sorgfältige Erstellung eines Pflichtenhefts zu investieren, um damit das Projekt nach fest geplanten Zielen konkret zu erstellen und die genauen Erwartungen festgelegt werden können. Im Normalfall wird es zum Bestandteil des Kaufvertrages.

Das Lastenheft wiederum bietet die Möglichkeit, die genaue Vorstellung seitens des Kunden festzuhalten. Außerdem verfügt der Kunde über ein einheitliches Dokument, mit dem die Einholung von verschiedenen Angeboten um einiges erleichtert wird.

Interessante Beiträge:
Lastenheft_Pflichtenheft Induux geht auf das Lasten- und Pflichtenheft ein
Mehr Informationen zu den Unterschieden von beiden auf T3N

Flickr.com/ Laurie/ Kevin

Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.

So, Sie möchten einen Onlineshop. Gute Entscheidung!

Immer mehr Käufer sind Online unterwegs. Entweder kaufen sie vom Computer oder machen erste Recherchen via dem Mobil-Telefon.

Es lohnt sich also definitiv einen Onlineshop zu haben.

In den meisten Fällen wendet man sich an Agenturen oder IT Dienstleister, welche diese Aufgabe der Umsetzung übernimmt.

Jedoch gibt es hier einiges zu beachten.

Immer wieder sehe ich, dass es ein hohes Unwissen gibt zu den folgenden Bereichen:

Themenbereiche (bei Klick auf die Links, kommen Sie direkt auf den bestimmten Punkt):

• 1) Welche Technologie sollte man einsetzen?
• 2) Welchen Aufwand macht die Umsetzung eines Onlineshops
• 3) Anfangsaufwand: Workshop, Konzept, Lasten- und Pflichtenheft, Wireframes, Design in Photoshop, Umwandlung Photoshop Datei zu HTML
• 4) Welcher Zeitraum benötigt wird, um einen Webshop umzusetzen
• 5) Wie man einen erfolgreichen Onlineshop aufbaut und betreibt
• 6) Was für ein Aufwand steckt in der Wartung und Betreuung des Shops
• 7) Wie man mit dem Dienstleister kommuniziert, um eine gute Dienstleistung zu erhalten
• 8) Weitere Punkte die es zu beachten gibt (UX, UI, Usability, Conversion Rate Optimierung, Traffic Generierung, Bezahlte Suchmaschinenwerbung, Suchmaschinenoptimierung, Landingpages, Erklärvideos, Bilder, etc.)
• 9) Warenwirtschaft Anbindung/ weitere externe Anbindungen (API’s)
• 10) Texte (Produkttexte, Verkaufstexte, Landingpage Texte, etc.)
• 11) Bilder
• 12) Mobile Erreichbarkeit
• 13) Rechtliche Absicherung
• 14) Zahlungsabwicklung
• 15) Finanzierung: Eigenkapital vs. Fremdkapital vs. laufende Einnahmen vs. Start im Nebenerwerb vs. Bootstrapping
• 16) Agentur vs. Freelancer vs. eigene Mitarbeiter vs. selber machen
• 17) Lastenheft und Pflichtenheft
• 18) Agil vs Wasserfall Ansatz der Softwareentwicklung
• 19) Langfristige Entwicklung
• 20) Fazit

(Anstatt zu Scrollen können Sie auch die auf die Liste im “Themenbereich” klicken)

Die Liste ist noch um ein vielfaches länger. Dies sind jedoch einige der wichtigsten Punkte.

Im Folgenden gehe ich auf einige dieser Punkte ein und wie man gute Anfragen verfasst:

1) Welche Technologie sollte man einsetzen?

Eine Einmann/ Einfrau Show braucht keinen Shop basierend auf Magento oder Shopware. Hier würde beispielsweise eine einfache Lösung wie WooCommerce (basierend auf WordPress) mehr als ausreichend.

Bei kleineren Shops kann man sogar folgendes machen: Man nutzt einfach ein Plugin und fügt einen “Kaufen”-Button hinzu, welcher dann zu PayPal führt.

Möchte man mehrere Tausend Artikel vertreiben, dann machen komplexere Shopsysteme wie Magento, Shopware oder OXID Sinn.

Wenn man internationaler denkt, dann ist Magento der richtige Ansatz.

Möchte man vorwiegend in Deutschland und den angrenzenden Ländern Geschäfte machen, dann sind Shopware oder OXID ideal.

Manche Startups und grössere Unternehmen möchten ganz gross einsteigen und neue Ansätze schaffen. Hier machen individual Programmierungen Sinn. Beispiele sind Amazon und eBay.

Diese wurde mit Technologien wie C++, Java, Python, PHP (neben Custom PHP Entwicklungen, gerne auch PHP Frameworks wie Laravel oder Zend) und weiteren umgesetzt. Der Aufwand ist riessengross, dass lohnt sich also nur, wenn man entsprechende Budgets besitzt oder Investoren hat, welche diese Budgets zur Verfügung stellen. (Es ist sicherlich möglich auch kleinere Shops mit dem “Programmier”-Ansatz umzusetzen, hier muss man jedoch abwägen, wann es mehr Sinn macht als ein fertiges Onlineshopsystem wie OXID, Shopware, Magento, etc.)

Bei grossen Unternehmen welche bereits SAP als Software im Einsatz haben, macht Hybris Sinn, denn dieses Shopsystem ist für SAP abgestimmt.

Die Realität der Anfragen:

Die Realität sieht jedoch immer noch so aus, dass irgendjemand mal etwas von Magento gehört hat und dann am liebsten auf dieser Basis einen Onlineshop umgesetzt haben möchte.

Der Ansatz kann gelten, ist in den meisten Fällen jedoch nicht ideal. Man sollte sich zuerst die Anforderungen anschauen (beispielsweise “einfache Wartbarkeit im Backend”, “gleichzeitiger Zugriff von 1000 und mehr Nutzern pro Stunde”, “gleichzeitige Verarbeitung mehr als 100 Bestellungen pro Stunden”, “Verkauf der Produkte hauptsächlich in Deutschland”, etc.).

Wenn man die Anforderungen aufgelistet hat, dann kann man die passende Shoptechnologie auswählen.

In der Realität wird jedoch immer noch mit dem Ansatz “Ich hab da mal was von Magento (oder ein anderer Ansatz) gehört”. Und das ist dann die Strategie für den Shop…

2) Welchen Aufwand macht die Umsetzung eines Onlineshops

Dies ist auch ein Punkt an dem sich viele, sogar IT Dienstleister, unterschiedlicher Meinung sind.

Es gibt Online Angebote wo Pauschal 1899 Euro für die Umsetzung eines Onlineshops basierend auf WordPress genommen wird.

Jedoch auch hier: Ohne die Anforderung zu kennen, kann man solche Pauschalen gar nicht anbieten.

Grund: Bereits eine Individualprogrammierung kann mehrere Wochen dauern.

Ein Beispiel: Der Kunde möchte einen WordPress Shop basierend auf WooCommerce umgesetzt bekommen. Der Wunsch ist es jedoch auch, einen Produktkonfigurator zu haben, bei welchem sich die Besucher (Kunden/ Webseitenbesucher) die Angebote flexibel zusammenstellen können. Dies ist eine gute Idee, denn viele Onlineshops bieten eine solche Lösung an und ist zudem sehr hilfreich. Jedoch: Die Programmierung eines Produktkonfigurators basierend auf PHP (die Softwaretechnologie hinter WordPress) kann Wochen dauern und ist dementsprechend teuer. Beispielrechnung: Die Programmierung durch einen PHP Entwickler dauert 160 Stunden für den Produktkonfigurator. Bei einem Stundensatz von 100 Euro Brutto, käme man dann auf 16’000 Euro (100 Euro mal 160 Stunden), welche man als Kunde in Rechnung vom Dienstleister gestellt bekommt.

Der andere Ansatz wäre es natürlich, dann zu sagen: “Ok, dass ist ganz schön viel Geld. Lass uns lieber die Option ohne Produktkonfigurator umsetzen”

Problematisch ist natürlich, wenn der Kunde es nicht einsehen will, dass die Entwicklung eines Produktkonfigurators soviel Zeit in Anspruch nimmt. Aussagen kommen, wie:

a) “Nehmt doch ein Plugin, welches bereits auf dem Markt gibt”

(Antwort: Solche Plugins sind meistens nicht auf die Wünsche des Kunden abgestimmt. Erst nach der Umsetzung, des auf dem Markt erhältlichen Plugins, merkt der Kunde “Oh, das ist gar nicht was ich wollte, ich habe doch von Anfang an gesagt, dass ich den Produktkonfigurator in dieser Form möchte”. Die Erwartungshaltung ist dann, dass der Produktkonfigurator ohne Zusatzkosten programmiert und bereitgestellt wird)

b) “Das kann doch nicht so teuer sein. Das habe ich doch auch bei anderen kleineren Shops gesehen”

(Antwort: In vielen “klein” wirkenden Shops sitzen Vollzeitprogrammierer dran, welche immer wieder Erweiterungen schreiben und diesen Shop ständig betreuen. Was nach “wenig Aufwand” aussieht, kann also durchaus das Resultat von mehreren Monaten und Jahren an Vollzeit Programmierung sein)

c) “Andere Dienstleister bieten solche Produktkonfiguratoren viel günstiger an”

(Antwort: Wie schon gesagt, in vielen Fällen gibt es zwar bestehende Plugins, welche dann jedoch nicht auf die Bedürfnisse des Kunden abgestimmt sind. Dann ist es eigentlich egal, an welchen IT Dienstleister man sich wendet. Jeder von diesen muss das von Grund auf neu programmieren und hat damit den gleichen Aufwand)

Auch bei Shopsystemen wie Magento, Shopware oder OXID ist das der Fall. Besonders bei Shopware und OXID ist die Auswahl an Plugins und Erweiterungen eher gering, so dass dort sehr hohe Aufwendungen für “simpel” wirkende Funktionalitäten entstehen können.

3) Anfangsaufwand: Workshop, Konzept, Lasten- und Pflichtenheft, Wireframes, Design in Photoshop, Umwandlung Photoshop Datei zu HTML

Was auch einfach nicht eingesehen wird ist, dass bevor noch die erste Zeile Code des Onlineshops geschrieben ist, ein guter Aufwand entsteht.

Im ersten Schritt kommt vom Kunden eine Email an den Dienstleister mit (verständlicherweise) ganz rudimentären Anforderungen an den Shop.

Nun muss sich der Dienstleister mit dem Kunden austauschen und versuchen die Anforderungen zu verstehen. Dies kann über Excel Dateien, Workshops, Telefonate, Meetings, etc. geschehen.

Idealerweise wird ein Lastenheft vom Kunden erstellt und ein darauffolgendes Pflichtenheft (welches vom IT Dienstleister, mit Input vom Kunden erstellt wird).

Danach müssen Wireframes erstellt werden, um ein erstes Gefühl zu bekommen, wie der Shop später aussehen wird. Dadurch dass die Wireframes einfach erzeugt werden können, kann man auch schnell Änderungen daran vornehmen.

Danach setzt sich ein Designer hin und nutzt (meistens) Photoshop um die eins-zu-eins Bilder zu erstellen, welche dann von einem Webdesigner in HTML und CSS Dateien umgewandelt werden.

Diese Dateien werden dann an die Programmierer für die Implementierung weitergesendet.

Das bedeutet aber auch folgendes: Der Aufwand um solch eine Startphase von Anfrage, über das Lasten- und Pflichtenheft, dem Design, etc. umzusetzen ist relativ hoch.

Je nach umzusetzendem Shop, kann diese Startphase bereits 40 bis 80 Stunden und mehr Aufwand bedeuten.

80 bis 90 Prozent der Anfragenden für die Umsetzung von Onlineshops haben jedoch kein Interesse soviel Budget aufzuwenden, wenn man bis dahin nicht mal Ansatzweise einen programmierten Onlineshop bekommt.

Mein Tipp: Wenn man diese ganze Phase der Anforderungen und Designphase umgehen möchte, dann kann man auf Standard-Templates setzen, welche man auf unterschiedlichen Onlineplattformen gibt. Man muss sich jedoch auch über die Vorteile und Nachteile solcher Standard-Templates im klaren sein. Später soll dann nicht die Rückfrage vom Kunden kommen “Warum ist das alles so statisch, ich möchte das viel flexibler haben und das Kontaktformular muss sowieso überarbeitet werden, das Design passt sowieso nicht…”. Bei einem Standard-Template muss man sich mit Standardfunktionalitäten zufrieden geben.

4) Welcher Zeitraum benötigt wird, um einen Webshop umzusetzen

Wie im vorherigen Beispiel bereits erwähnt: Es braucht nur einmal zwei bis drei Wochen, bis die Anforderungen und das Design bestimmt sind.

Das setzt jedoch auch voraus, dass der Anfrage-Stellende jederzeit verfügbar ist für Rückfragen und auch die Projektleiter (für den Workshop und das Lasten- und Pflichtenheft) und der Designer (für die Wireframes und Photoshop Designs) und der Webdesigner (für die HTML/ CSS Umsetzung) jederzeit verfügbar sind. Das ist jedoch meistens nicht der Fall. Einmal hat der Kunde Urlaub, dann fehlt der Projektleiter, weil er/ sie gerade mit etwas anderem beschäftigt ist, undsoweiterundsofort.

Das bedeutet also, dass es im Idealfall (alle sind jederzeit verfügbar) nur zwei bis drei Wochen zu haben, bis man fertig mit den HTML/ CSS Dateien ist, im Normalfall jedoch etwas länger braucht.

Auch die Programmierung und Umsetzung des Shops selbst braucht mehrere Wochen.

Wenn man dann fertigt ist, muss man das System jedoch ausgiebig testen, so dass man sich sicher sein kann, dass der Shop beim Kundenkontakt auch eine gute Performance liefert und es keine Herausforderungen gibt. Auch das Testing kann mehrere Tage, und eventuell Wochen, dauern.

Tipp: Einiges an Zeit mitbringen. In den meisten Fällen sollte man jedoch schon mindestens von 6 Monaten ausgehen (Start der Anfrage, bis zum fertigen Onlineshop). Bei grösseren Shops dementsprechend länger.

5) Wie man einen erfolgreichen Onlineshop aufbaut und betreibt

Wie bei allen Geschäftsvorhaben auch: Meistens kann man nicht einfach etwas bauen und kann dann hoffen das alles von alleine läuft.

Die Realität sieht so aus:

• Der Shop sollte fortlaufend optimiert werden (Conversion Rate Optimierung, Performance Optimierung)
• Man sollte neue Funktionalitäten testen (Beispielsweise der Einbau eines Produktkonfigurators)
• Traffic Generierung über Suchmaschinenoptimierung (SEO), Suchmaschinenwerbung (SEM), Social Media Marketing, etc.
• A/B Testing der unterschiedlichen Seiten
• Ein guter Onlinesupport

D.h. mann muss fortlaufend Änderungen vornehmen, die Prozesse verbessern, weitere Zahlungsfunktionalitäten hinzufügen, Geschwindingkeitsoptimierungen vornehmen und einges weitere.

Auch wenn man diese ganzen Massnahmen unternimmt, kann es mitunter Monate und länger dauern, bis man wirklich erfolgreich wird und gute Umsätze erzielt.

6) Was für ein Aufwand steckt in der Wartung und Betreuung des Shops

Rechtliche Bestimmungen ändern sich ständig. Zum Beispiel muss man bald den Anforderungen von DSVGO gerecht werden. Dies bedeutet unter anderem dass ein Onlineshop auf HTTPS umgestellt werden muss. Der Aufwand kann hier bereits hoch sein, je nachdem wie gross der Shop ist.

Bestimmungen ändern sich also.

Auch die Anforderungen und Wünsche der Kunden ändern sich. Waren Kunden lange Zeit zufrieden, über den Desktop zu bestellen, wollen viele das gleiche Nutzererlebnis (UX) auch auf Smartphones und Tablets haben.

Die Umstellung von einem Desktop-Browser Onlineshop hin zum Responsive Onlineshop der auch auf Smartphones und Tablets läuft kann einen hohen Aufwand bedeuten.

In manchen Fällen sollte man auch gleich einen Shop basierend auf Android und einen basierend auf iOS anbieten.

Und die Umsetzung von sogenannten Nativen Apps für Android und iOS sind wahrlich nicht simple.

Gleichzeitig müssen solche Webshops auch Upgegraded werden. Bei Shops welche stark verändert (in der Fachsprache: Customized) wurden, dann ist ein solcher Upgrade eine Aufgabe welche viel Zeit in Anspruch nimmt.

Diese Aufwand wird oftmals unterschätzt. Die Hoffnung ist meistens, dass, wenn der Shop erstellt ist, alles von alleine läuft.

7) Wie man mit dem Dienstleister kommuniziert, um eine gute Dienstleistung zu erhalten

Nur weil man eine technisch kompetente Agentur findet, bedeutet das nicht, dass diese dann sofort den “Next Level” Onlineshop umsetzen werden.

Auch das ständige Feedback vom Kunden ist notwendig, so dass die Agentur weiss, an was sie arbeiten soll.

Gleichzeitig ist es sinnvoll jemanden im eigenen Team zu haben, der sich mit der Technologie hinter dem spezifischen Onlineshop auskennt.

So kann das eigene Team auch die Qualität der Programmierung, welches der Dienstleister von Zeit zu Zeit bereitstellt, überprüfen. Auch kann sichergestellt werden, ob die Dokumentation richtig vorgenommen wurde.

Tipp: Es macht Sinn gemeinsam mit dem Dienstleister ein Pflichtenheft zu erstellen. Dies ist in den meisten Fällen bereits kostenpflichtig. Das Resultat, das Pflichtenheft, kann jedoch auch von anderen Unternehmen umgesetzt werden. Daher kann sich eine solche Pflichtenhefterstellung lohnen.

8) Weitere Punkte die es zu beachten gibt (UX, UI, Usability, Conversion Rate Optimierung, Traffic Generierung, Bezahlte Suchmaschinenwerbung, Suchmaschinenoptimierung, Landingpages, Erklärvideos, Bilder, etc.)

• Bilder: Man kann zwar generische Bilder nehmen, welche man von Produktherstellern bekommt oder Online findet. Es kann aber auch sinnvoll sein, in manchen Fällen, einen professionellen Fotografen zu engagieren, welcher auf den Onlineshop abgestimmte Fotos aufnimmt. Gute Bilder können eine sehr grosse Wirkung auf das Gesamtbild des Shops haben.
• UX/ UI/ Usability: Die UBER App oder Amazon sind Beispiele für eine starke Usability (Einfachheit der Nutzung) und UX (Nutzererlebnis), User Interface Design (Oberflächen-Design). Dies sind Gebiete die immer wichtiger werden. Früher konnte man noch eine statische Website bauen, die Kunden waren trotzdem zufrieden. Heutzutage wollen die Nutzer eine einfache Bedienung, schnelle Ladezeiten und eine intuitive Nutzeroberfläche. Das sind Punkte die Allzuoft nicht beachtet werden.
• Erklärvideos: Es ist immer sinnvoll Erklärvideos zu erstellen, besonders wenn es um Erklärungsbedürftige Dienstleistungen handelt. Diese können dann im Onlineshop genutzt werden. Kurze und einfache solcher Clips kosten zirka 2000 Euro (eine Minute Länge). Die Preise hängen aber auch von der Qualität der Umsetzung ab.
• Suchmaschinenwerbung (SEM): Was für einen Sinn macht es, wenn man einen Onlineshop hat, aber dieser nicht gefunden wird? Nur Wenn Nutzer auf die Seite kommen, dann entstehen auch potenzielle Umsätze. Dementsprechend sollte man sein Budget auch nicht komplett auf die Umsetzung des Shops alleine setzen. Auch SEM Massnahmen sollte man dementsprechend einkalkulieren und umsetzen. Dabei handelt es sich um bezahlte Werbung. Meistens sind es Anzeigen in der organischen Suche.
• Suchmaschinenoptimierung (SEO): Hierbei zahlt man nicht für Werbung, sondern erzeugt Texte auf dem Onlineshop, welche dann online gefunden werden. Es gibt professionelle SEO Schreiber, welche solche Texte erstellen. Für 1000 Wörter kostet das im Schnitt 100 bis 200 Euro.
• Landingpages: Webshops und einzelne Seiten innerhalb dieser Shops richten sich immer mehr nach dem Prinzip der Landingpages. Die Conversion Rate (also der Anteil an Besuchern, welcher eine bestimmte Aktion durchführt, wie beispielsweise ein Kontaktformular ausfüllen) ist in diesem Zusammenhang auch wichtig. Die meisten Online Experten sind überzeugt, dass man verstärkt Landingpages nutzen sollte.

9) Warenwirtschaft Anbindung/ weitere externe Anbindungen (API’s)

Ein wichtiger Punkt der übersehen wird, ist die Anbindung externer Services oder Software.

Die besten Beispiele sind Warenwirtschaftssysteme (kurz WaWi). Die Anbindung dieser kann jedoch in manchen Fällen so komplex sein (und Wochen und Monate dauern), dass es sich in vielen Fällen lohnt, keine Anbindung im ersten Schritt vorzunehmen, sondern die Systeme separat laufen zu lassen. Die Daten können dann manuell via Excel Download, beziehungsweise Excel Upload, bereitgestellt werden. Später kann die WaWi dann schrittweise an das Shopsystem angebunden werden.

Auch API’s zu externen Services, wie Webservices kann komplex werden. In manchen Fällen bestehen bereits Plugins oder API Anbindungen, dann verringert sich der Aufwand. Sollten diese jedoch nicht vorhanden sein, dann braucht es dementsprechend länger. Auch hier muss dann eine Abwägung gemacht werden, ob sich eine direkte Anbindung von Anfang an lohnt.

10) Texte (Produkttexte, Verkaufstexte, Landingpage Texte, etc.)

Die Produkte und Dienstleistungen welche auf dem Webshop angepriesen werden, müssen auch Texte haben.

Die Frage: “Wer erstellt diese ganzen Texte” sollte auch vorab beantwortet werden.

Kauft man sich diese extern ein? Zum Beispiel von einem Content Writer. Und die Verkaufstexte von einem Copywriter. Oder lässt man diese intern von einem Mitarbeiter schreiben, oder schreibt der Gründer diese eventuell sogar selbst?

Je nachdem wieviele Artikel im Shop sind, ist das dann auch keine kleine Aufgabe.

11) Bilder

Das Thema Bilder wurde hier bereits in Punkt 8 angerissen. Hier nochmal ausführlich, da dass wirklich unterschätzt wird.

Wenn Anfragende Beispielseiten schicken, dann merken diese oftmals folgendes nicht: Die Bilder sind oftmals nicht einfach irgendwo herauskopiert oder gekauft worden.

In vielen Fällen hat ein professioneller Fotograf mehrere Bilder der unterschiedlichen Produkte (jedes einzelnen Produktes) oder Dienstleistungen aufgenommen.

Danach wurden diese Bilder professionell bearbeitet.

All das kann alleine bereits mehrere Mann/ Frau-wochen und Mann/ Frau-monate an Aufwand bedeuten.

Das Besondere daran ist auch: Ob man nun Standardbilder vom Hersteller verwendet oder gar Bilder von sogenannten Bilderverkaufsseiten (Stockphotos) nutzt, macht einen sehr grossen Unterschied und wirkt sich stark auf den Gesamteindruck des Onlineshops aus.

Professionelle Bilder sind zu empfehlen. Der Aufwand dafür sollte jedoch nicht unterschätzt werden.

Hinweis: In manchen Fällen wird die Oberfläche von Onlineshops geradezu bestimmt von Fotos. Hier sollte man sich wirklich Gedanken machen, ob es denn nicht sinnvoller wäre professionelle Bilder zu verwenden. Dies ist jedoch sicherlich auch eine Kosten/ Nutzen-Frage.

12) Mobile Erreichbarkeit

Heutzutage besuchen Onlinenutzer nicht nur den für den Desktop-Browser optimieren Shop, sondern informieren sich zunehmend über deren Smartphones.

Die sogenannte User Experience (Nutzererlebnis) unterscheidet sich jedoch bereits stark von dem was man am Desktop vorfindet.

Der Onlineshop muss also auf diese Bedürfnisse angepasst werden. Hierfür gibt es wiederum unterschiedliche Möglichkeiten.

• Responsive: Bei dieser Umsetzungsmethode werden die Webseiten einfach so verändert, dass diese auch im mobilen Browser passend angezeigt werden. Je nachdem welche Bildschirmgrösse der Browser hat (Beispielsweise Smartphone, “Note” oder Tablet Grösse), wird der Shop unterschiedlich angezeigt. Dies ist mit relativ geringem Aufwand umzusetzen. Der grosse Nachteil. Die Nutzererfahrung ist durchschnittlich. Die Seiten werden höchstwahrscheinlich nicht schnell geladen und auch viele weitere Funktionalitäten werden nicht flüssig dargestellt.
• Native: Das ist immer noch der Klassiker. Basierend auf, meistens, Android und iOS werden hier separate Versionen des Onlineshops erstellt. Dies lohnt sich jedoch nur bei sehr grossen Vorhaben, denn der Entwicklungsaufwand ist pro Plattform (Android, iOS) sogar noch höher als für die Desktop Variante.
• Cross Plattform: Dieser Ansatz kommt nicht so oft vor im Bereich Webshops. Der grosse Vorteil ist bei diesem Ansatz jedoch, dass man nur einmal entwickeln muss und die Software dann auf allen Plattformen läuft (so die Theorie). Dies wird ermöglicht durch Technologien wie Xamarin, welche auf C# basieren.
• Web App: Hierbei handelt es sich im Grunde genommen um eine Website, in welcher HTML5, CSS und JavaScript zum Einsatz kommen. Mit dem Unterschied zur normalen Website, dass diese speziell für die Bedürfnisse von Mobilen Browsern wie Chrome oder Safarie abgestimmt sind. Man erkennt solche Seiten oftmals daran, dass diese mit einem “m” anfangen. Beispielsweise m.onlineshop.de.
• Hybrid App: Das ist fast das Gleiche wie eine Cross Plattform Anwendung, nur das auch hier wie bei der Web App HTML5, CSS und JavaScript die Haupt-Technologien sind. Mit Software wie Cordova oder dem Ionic Framework werden dann “quasi” Native Apps erstellt. Es werden Apps erstellt, die Anwendung selbst läuft jedoch innerhalb einer sogenannten “WebView” innerhalb der App.

Oftmals ist es dann auch eine Budget-Frage/ Kosten-Nutzen-Rechnung, welchen Ansatz man fährt.

13) Rechtliche Absicherung

Datenschutz (z.B. DSVGO), Cookie Abfragen, Impressum, AGB, Kontaktformulare, Newsletter, als das und noch viel mehr müssen vorsichtig gehandhabt werden.

Bereits kleinere Verstösse kosten jeweils mehrere Tausend Euro an Bussgeld.

Hier lohnt es sich einen Anwalt für Onlineshop/ Internet-Recht hinzuzuziehen. Auch hier: Eine gute Internetagentur hat Zugriff zu einem solchen.

14) Zahlungsabwicklung

Eine weiterer Punkt der schnell übersehen werden kann, ist die Zahlungsanbindung. Welche Funktionalitäten werden umgesetzt?

Beispiele:

• PayPal
• Sofortüberweisung
• Kreditkarte
• Auf Rechnung
• etc.

Wenn man Online nach Beispielen sucht, dann sieht man: Viele der Kaufabwicklungen sind sehr individuell gestaltet und laufen nicht 08/15 ab. Hier muss man auch die Entscheidung fällen, ob man am Anfang nicht zuerst mit einer einfachen Zahlungsabwicklung und geringeren Auswahlmöglichkeiten startet. Weitere Zahlungsmethoden kann man immer hinzufügen.

15) Wie wird das Ganze finanziert?

Wenn Anfragen gestellt wird, ist oftmals noch gar nicht die Frage geklärt “Wie wird das Vorhaben eigentlich finanziert?”.

• Eigenkapital/ Erspartes: Eine weniger gute Idee ist es, mehrere 10’000 Euro erspartes zu nehmen, um dann einen neuen individuell programmierten Onlineshop zu erstellen. Das kann sich bei Unternehmen lohnen, welches ihr Eigenkapital nutzen und bei denen es nicht so schlimm ist, wenn das Vorhaben nicht zum Erfolg wird (Stichwort: Trial and Error). Jedoch sollte das keine Option für einen Gründer sein, der sein Erspartes nutzt.
• Fremdkapital: Auch hier: Vorsichtig. Ein Bankkredit kann eine Option für Unternehmen sein, die bereits über einen bestimmten Cashflow verfügen, und den Kredit auch anderweitig bedienen können, ohne auf Profite vom Onlineshop angewiesen zu sein. Was jedoch spannend sein kann ist, wenn ein Investor (zum Beispiel Angel Investor, etc.) einsteigt und das Geld als Risikokapital bereitstellt. Wenn der Shop zum Erfolg wird, gewinnen alle. Wenn nicht, verliert lediglich der Investor sein Geld (dass hört sich zwar schlimm an, wenn man aus Sicht des Investors denkt, jedoch geht dieser sicherlich auch von diesem Risiko aus, sonst würde es ja auch nicht Risikokapital heissen).
• Laufende Einnahmen: Das ist einer der beliebtesten Ansätze. Hier setzen Unternehmer/ Unternehmen die Profite/ Einnahmen von bestehenden Geschäftstätigkeiten ein, um den Shop aufzubauen und langsam aber sicher zum Erfolg zu führen. Sicherlich auch einer der besten Wege, um die Finanzierung durchzuführen.
• Start im Nebenerwerb: Viele können neben ihrem eigentlich Job einen Shop starten. Dabei zeigt man monatlich vom Gehalt etwas ab und investiert es in den Aufbau des Onlineshops. Lösungen wie Shopify (Onlineshopbaukästen) oder aber auch Lösungen wie WooCommerce kann man hierfür nutzen. Weitere Profite kann man dann in den weiteren Ausbau stecken. Bis man dann in der Lage ist, auf Vollzeit in die Shopbetreuung und den Ausbau einzusteigen.
• Bootstrapping: Auch dies ist eine beliebte Methode. Hierbei steigt man bereits Vollzeit ein, versucht aber so wenig Geld wie möglich auszugeben. Man kann hierbei auch bei Freunden und Bekannten nach Unterstützung fragen. Der Unterschied zum Ersparten ist, dass man beim Bootstrapping eben nicht Unsummen investiert, sondern in kleinen Schritten und vorsichtig vorgeht.

Alles sind legitime Vorgehensweisen. Die Besten sind jedoch die, in welchen das Risiko minimiert wird und es Möglichkeiten für Veränderungen der Strategie, neue Ansätze, etc. gibt.

16) Agentur vs. Freelancer vs. eigene Mitarbeiter vs. selber machen

Schlussendlich sollte man auch entscheiden, wer den Shop denn nun umsetzen soll.

Hier die unterschiedlichen Möglichkeiten:

• Agentur: Eine Agentur hat meistens bereits Designer, Webdesigner, Entwickler, Projektleiter, SEO-Experten, Social Media Manager und einige mehr. Zudem verfügen diese Zugang zu einem weiteren Netzwerk an spezialisierten Freelancern und Partnern (zum Beispiel für das Schreiben der Texte, der Aufnahme der Bilder, der Erstellung der Erklärvideos, etc.). Man bekommt alles aus einer Hand.
• Freelancer: Der Freelancer ist meistens auf eine Sache spezialisiert. Oftmals ist er gut im Bereich Backendentwicklung und kann beispielsweise den Produktkonfigurator bauen. Ob dieser in der Lage sein wird das ganze Projekt zu stemmen, hängt davon ab, dieser, wie die Agentur auch, über ein gut ausgebautes Partnernetzwerk verfügt, welche die anderen Bereichen übernehmen können.
• Eigene Mitarbeiter: Es kann auch sinnvoll sein eigene Mitarbeiter zu haben, welche den Shop mit aufbauen. Dieser kann die Zusammenarbeit mit der Agentur koordinieren und auch später die weitere Betreuung übernehmen, sobald die Agentur oder der Freelancer/ die Freelancerin das Projekt übergeben hat.
• Selber machen: Dies lohnt sich für kleinere Vorhaben. Es gibt Lösungen wie Shopify, welche es auch einem Unerfahrenen die Möglichkeit gibt, eine professionell aussehende Onlinepräsenz aufzubauen. Aber vorsichtig: Die Optionen sind hier eingeschränkt, da man zum Beispiel wenige Möglichkeiten für eigene Entwicklungen hat. Andere Bereiche sind die Suchmaschinenoptimierung, auch hier sind die Fertiglösungen meistens nicht ganz so stark.

17) Übung: Lastenheft und Pflichtenheft

Auch ist es sinnvoll vor dem Projektstart ein Lastenheft und ein Pflichtenheft zu erstellen. Viele empfinden das als lästig. Dennoch: Es kann dazu führen, dass der Aufwand während des Projektes um einiges sinkt. Denn dann hat man einen Fahrplan an welchen man sich halten kann. Dieser Fahrplan lässt sich zudem verändern, Punkte können hinzugefügt werden oder entfernt werden.

Das Lastenheft wird vom Anfragenden erstellt. Das Pflichtenheft vom Dienstleister. Wobei in der Praxis das Pflichtenheft, in zusammenarbeit mit dem Kunden erstellt wird.

Diese Dokumente werden, wenn diese erzeugt werden, Teil des späteren Vertrages.

18) Agile oder Wasserfall?

Agiler Ansatz?

In diesem Zusammenhang kann auch ein Agiler Ansatz Sinn machen.

Der Vorteil: Man erhält von Anfang an funktionierende Funktionalitäten bestimmten Zeiträumen (zum Beispiel einmal in zwei Wochen oder einmal monatlich).

Zudem kann man das Projekt jederzeit Anhalten, wenn man denkt, dass man das Ganze überdenken oder neu planen muss.

Auch hat man die Möglichkeit während der Entwicklung mit neuen Ideen zu kommen. Das ist die Stärke des Agilen Ansatzes: Auch mitten in der Programmierung können Änderungen vorgenommen werden (zumindest zum Ende eines Sprints (Sprint = Entwicklungszyklus der üblicherweise zwischen einer Woche und einem Monat liegt)).

Wasserfall Ansatz?

Der traditionelle Wege ist immer noch der Wasserfall Ansatz (Waterfall Method) der Softwareentwicklung. Hierbei werden alle Anforderungen bereits zum Anfang festgehalten und neue Funktionalitäten werden erst hinzugefügt, wenn die initialen Anforderungen umgesetzt sind. In diesem Fall braucht es definitiv ein gut ausgearbeitetes Pflichtenheft.

19) Langfristige Entwicklung

Erfolgreiche Onlineshops zeichnen sich vor allem dadurch aus, dass diese ständig weiterentwickelt wurden.

Erst wenn die erste Version Online ist, kann man Feedback von den Nutzern bekommen. Zu diesem Zeitpunkt fällt auch erst auf, was denn alles noch an Funktionalitäten notwendig sind, oder welche Funktionalitäten man aus dem Shop entfernen kann.

Mit jedem Feinschliff (Weiterentwicklung/ Programmierung) des Onlineauftritts wird dieser auch besser.

Erst nach mehreren Monaten und eventuell Jahren an Weiterentwicklung wird die Plattform so richtig wertvoll für die Besucher.

Gleichzeitig erarbeitet man sich mit der Zeit auch einen Unterscheidungsmerkmal zu anderen Shops.

Das heisst: Wenn die ersten Version des Shops entwickelt ist und online ist, fängt die Arbeit erst an

Ps: Diese langfristige Entwicklung sollte man auch in seine Planung zum Start des Projektes, d.h. bei der Anfrage einbeziehen. Weiss man beispielsweise, dass man nur mit 10 oder 20 Produkten startet, man jedoch weiss, dass man später Tausende Produkte Online haben wird, dann sollte man nicht mit kleinen Lösungen wie WooCommerce starten, denn diese sind nicht darauf ausgelegt, hohe Besucherzahlen gut zu handeln. Besser sind da Onlineshopsysteme wie Magento oder Shopware. Auch wenn der Anfangsaufwand höher ist. Die Skalierbarkeit zu mehr Webseitenbesuchern und mehr Bestellungen ist gegeben.

Fazit

Man sieht, ein Onlineshop ist umfangreich. Es hat viele Teilbereiche. Die Realität ist also auch: Die Internetagentur oder der IT Dienstleister bei dem man anfrägt, hat höchstwahrscheinlich nicht Kapazitäten/ Ressourcen/ Fähigkeiten in allen diesen Bereichen, sondern arbeitet selbst oftmals mit kompetenten Partnern zusammen, welche diese Aufgaben ausführen.

Alleine die Koordination der einzelnen Teilbereiche (wie zum Beispiel SEO, SEM (SEO Agentur), Landingpage Erstellung (Conversion Rate Optimierungs Agentur), Bilder (Fotograf), Texte (Content Writer), Erklärvideo (Animationsstudio), Internetrecht, Design (UX/ UI Designer, Webdesigner), Programmierer (Erstellung individueller Plugins, Erweiterungen und Anpassungen des Shops), etc. etc. braucht einiges an Zeit.

Für die Planung alleine sollte man sich daher bereits einiges an Zeit einkalkulieren.

Standardaussagen wie “Der Shop soll in 2 bis 3 Monaten stehen” sind meistens nicht durchführbar, ausser es handelt sich wirklich um einen Webshop mit minimalen Anforderungen, wie zum Beispiel eine WooCommerce Umsetzung mit 100 Artikeln, welcher nur von 100 bis bis 500 Besuchern pro Tag aufgesucht wird.

Hinweis: Einschränkung der Funktionalitäten am Anfang sinnvoll

Es macht Sinn am Anfang die Anforderungen herunterzuschrauben.

Man wird schnell merken dass ein Shop mit all den Funktionalitäten aus diesem Leitfaden viel zu Aufwändig und ein Mammut Projekt wird.

Anstatt dessen sollte man eine Minimalversion (MVP = Minimum Viable Product) bauen. Beispielsweise kann man auf folgende Bereiche verzichten:

• Erklärvideo
• Fotografen (anstatt dessen Stock Photos)
• SEM Massnamen (anstatt dessen SEO, welches oftmals kostengünstiger ist)
• Anbindungen der WaWi und externen Servicen
• Undsoweiterundsofort

Diese Punkte kann man im Zeitverlauf auch peu a peu umsetzen.

Ein Onlineshop ist ein gutes Investment für die meisten Unternehmen, welches Produkte und Dienstleistungen verkaufen. Der Aufwand ist jedoch nicht immer so gering wie man denkt. Es lohnt sich zwar, man sollte sich jedoch mit den realen Bedingungen auseinandersetzen.

Welche Punkte gibt es Ihrer Meinung noch zu beachten? Ich freue mich über Ergänzungen in den Kommentaren und einen Austausch.

6 Zusatztipps:

1) Geben Sie der Agentur Zeit

Lassen Sie der Agentur Zeit bei der Umsetzung.

Manchmal werden Sie (oder im gegebenen Fall Ihr Teammitglied) gerade keine Zeit haben Feedback zu geben. Oder ein Entwickler oder ein anderer im Projekt involvierten Personen fällt, aus welchen Gründen auch immer aus. Oder die Auslastung steigt auf ein zu hohes Mass (d.h. sehr viele Projekte kommen rein).

Aus unterschiedlichsten Gründen können sich Termin/ Abgabezeiträume verschieben. Zeigen Sie dafür Verständnis und verlangen Sie nicht das Unmögliche (oder was immer Sie als “gaanz einfach” empfinden). Es wird immer gute Gründe geben, warum die Agentur oder der IT Dienstleister nach mehr Zeit fragt.

2) Zeigen Sie Verständnis für technologisch umsetzbare und nicht-umsetzbare Funktionalitäten

Manche Dinge lassen sich einfach nicht technisch umsetzen. Ok, in den meisten Fällen schon. Die Frage ist jedoch ob die Kosten-Nutzen das rechtfertigen.

Wenn also die Agentur sagen sollte, dass der Aufwand zu hoch ist oder zu komplex, dann sollte man darauf hören.

Man kann immer noch ein separates Projekt auflegen, wo diese eine Funktionalität umgesetzt wird.

So reduziert man zudem die Komplexität des laufenden Projektes (Stichwort: Minimum Viable Product).

3) Fordern Sie transparenz ein

Wenn Sie nicht sicher sind, warum etwas so lange dauert, oder warum das soviel Aufwand erzeugt, dann fragen Sie nach bei Ihrem Dienstleister.

Zeigen Sie sich jedoch verständnisvoll, sollte der Dienstleister alle Arbeitsaufwendungen offenlegen.

4) Stellen Sie jemanden mit technischen Kenntnissen auf Ihrer Seite bereit

Erwarten Sie nicht, dass die Agentur und die Mitarbeiter dort die 100 Prozent perfekte Lösung liefern.

Beispielsweise kann ein Entwickler, der auf Ihrer Seite arbeitet herausfinden, dass eine Dokumentation fehlt oder der Architektur Ansatz nicht passt.

Die Agentur wird das und andere Punkte höchstwahrscheinlich, oder besser gesagt “oft”, nicht berücksichtigen.

Nur durch ein Feedback durch den Kunden lassen sich diese Punkte ausbessern.

5) Leiten Sie das Projekt

Übergeben Sie nicht die komplette Leitung der Agentur. Haben Sie jemanden auf Ihrer Seite, welcher die notwendigen Anweisungen gibt, um das Projekt weiterzuführen.

Dafür kann man sich in regelmässigen Abständen mit der Agentur abstimmen.

6) Subject Matter Experts make the Decisions

Lassen Sie sich vom Englischen nicht abschrecken. Dies bedeutet einfach dass der jeweilige Experte in seinem Bereich die strategischen Entscheidungen treffen sollte.

Beispiele:

• Ein Datenbankexperte übernimmt die Entscheidungen zur Datenbankstruktur und nicht der direkte Manager.
• Ein Photoshop-Designer erstellt die Designs und der Kunde hört auf die Ideen und Möglichkeiten.
• Etc.

Wenn der Subject Matter Experte sagt, dass es nicht der ideale Weg ist, sollte man darauf hören.

7) Simple ist oftmals besser

Wo auch immer möglich, wird Ihnen die Agentur Vorschläge machen, wie man den Entwicklungsaufwand reduzieren, die Skalierbarkeit erhöht und die Wartbarkeit sicherstellt.

Hören Sie auf diese Ratschläge, diese sind oftmals besser als die eigenen Ansätze.

Bilder: Canva.com/ kostenfreie Lizenzen

Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.

Folgendes sind Anfragen die ich immer wieder mal bekomme und die manchmal schon schwer zu verdauen sind

Ich hab da mal eine Idee – “Ich hab da mal eine Idee für eine Software. Soll so ähnlich sein wie XYZ (Amazon, Facebook, Whatsapp oder irgendeine andere grosse Plattform einsetzen)”

Warum das so schlimm ist: Eine einzelne Funktionalität, zum Beispiel ein Einkaufsbutton bei Amazon, hat meistens ein eigenes Team an Programmierern und Online Experten, welche daran seit Jahren arbeiten.

Man kann mich solch einer Anfrage nicht viel anfangen.

Die meisten die solche Anfragen stellen, haben irgendwo mal was aufgeschnappt. Man sollte sich jedoch vorher informieren, welche Aufwände sich hinter der Entwicklung solcher Portale verstecken.

Was kostet das? “Ich habe da eine Idee für eine App, wieviel kostet das?”

Jede Antwort mit einem Euro Betrag wäre komplett daneben. Man kann eine App Projekt nicht mit wenigen Informationen abschätzen.

Man braucht mindestens die Infos zu den Grundfunktionalitäten als auch idealerweise die Wireframes.

Die Wireframes kann zwar der Designer im App Entwickler Team umsetzen, dafür fallen jedoch meistens 20 bis 40 Stunden an Arbeit an, welche natürlich vergütet werden müssen. Jedoch: Diese Informationen kann man dann auch für weitere Anfragen nutzen, sollte man das Gefühl haben, dass das Projekt irgendwo anders besser aufgehoben ist.

Im Idealsten Fall lässt man sich auch ein Pflichtenheft erstellen. Dies benötigt jedoch auch einiges an Zeit, Geld und auch den Willen die notwendigen Inputs zu geben.

“Sowas wie Amazon” reicht leider nicht aus.

Für alle Plattformen – “Ich möchte die App für iOS, Android, Windows Phone, Web und MAC OS”

Meistens besteht kein Hintergrund in der App Entwicklung. Aber der Anfragende möchte gleich mal für alle Plattformen entwickelt haben.

Die Problematik ist Folgende: Zum Teil muss für jede dieser Plattformen separat entwickelt werden. Für die iOS App braucht es einen iOS/ Objective-C/ Swift Entwickler, für die Android App braucht es einen Android Entwickler (oder Entwicklerin), für Windows Phone braucht es einen .NET/ C# Entwickler, für die Web Applikation braucht es einen PHP/ Ruby On Rails/ ASP.NET Entwickler.

Es bräuchte also gut und gerne mal 4 Entwickler, nur mal um die Expertise für die grundlegenden Plattformen zu erhalten.

Dann stellt sich jedoch noch die Herausforderung der unterschiedlichen Gerätetypen. Die Komplexität, die sich aus den unterschiedlichen mobilen Endgeräten (Android Bildschirmgrössen, zum Beispiel und deren unterschiedliche Konfigurationen, zum Beispiel die Speichergrösse, die CPU, etc.) ergeben, ist nicht gering. Der Testing Aufwand erhöht sich in das fast unendliche (etwas übertrieben gesagt )

Durch die Komplexität der unterschiedlichen Plattformen steigert sich auch der Kommunikationsaufwand.

Besser ist also immer folgendes: Zuerst für eine Plattform bauen. Zum Beispiel für iOS iPhones. Wenn man das fertig entwickelt hat und alles gut funktioniert, kann man zur nächsten Plattform, zum Beispiel Android übergehen.

Indien fast kostenfrei – “In Indien ist das sicherlich günstiger”

Klar kann man im Ausland günstiger entwickeln. Das bedeutet jedoch nicht, dass die Gesetze der Marktwirtschaft nicht mehr gelten!

Wichtig ist zu verstehen, dass Softwareentwicklung immer Zeit benötigt, egal wo man das macht.

40 Stunden in Europa sind auch 40 Stunden in Asien. Der Asiate kann das, was der Europäer macht, nicht in der Hälfte der Zeit umsetzen.

Das bedeutet auch, wenn ein Projekt in Europa 10000 (Zehntausend) Stunden dauert, dann dauert es auch in Asien 10000 (Zehntausend) Stunden.

Die Hoffnung bei Anfragenden ist immer (sicherlich auch unterbewusst), dass die Zauberasiaten alles supergünstig und ohne Aufwand erstellen können. Das ist sicherlich nicht der Fall.

Wenn man mit Outsourcing nach Indien erfolgreich sein will, dann sollte man zumindest starke Kenntnisse von qualitativ hochwertigem Softwarecode haben (d.h. die Möglichkeit haben, die erstellte Arbeit gegenzuchecken), Englischkenntnisse (um sich mit dem indischen Entwickler direkt austauschen zu können), Projektmanagementwissen (wie kann man IT Projekte umsetzen und leiten) und einiges mehr.

In den meisten Fällen lohnt sich ein Freelancer oder eine Agentur aus Deutschland mehr! Besonders wenn man selbst keine Expertise in der Softwareentwicklung hat und fast die komplette Verantwortung für die Entwicklung abgeben möchte.

Kleines Projekt – “Ich hab da mal ein kleines Projekt”

Entweder entpuppt sich das Projekt als Mammut-Aufgabe, welche im Grunde genommen mehrere Monate Aufwand bedeutet, an welchem mehrere Entwickler gleichzeitig arbeiten müssten oder eben um ein wirklich kleines Projekt, mit nur 8 bis 10 Stunden Aufwand maximal.

Das mit dem Mammut-Projekt entsteht, wie vorher bereits angesprochen aus Unwissen (zumindest wenn man es “kleines Projekt” beschreibt).

Und wenn es wirklich kleinteilige Aufgaben sind, dann sollte man auf den Freelancer seines Vertrauens setzen, welcher vielleicht einen höheren Stundensatz hat, dafür aber eine saubere Arbeit abliefert.

Lasst Euch Zeit – “Lasst Euch Zeit, ich brauche das erst in zwei Monaten”

In den meisten Fällen braucht die Eruierung der Anforderungen bereits ein bis zwei Wochen, wenn nicht sogar länger.

Die Erstellung eines Lasten- und Pflichtenheftes zum Beispiel braucht einiges an Zeit.

Danach oder davor hat man noch Workshops, in welchen die Anforderungen besprochen werden. Nur mal einen Termin zu erhalten, wo beide Seiten (Kunde und Ansprechpartner bei dem Dienstleister) Zeit haben, dauert meistens mehrere Tage und manchmal Wochen.

Dann müssen noch die Wireframes (grobe Zeichnungen der unterschiedlichen Seiten der Website/ App) und dann das Design zum Beispiel in Photoshop erstellt werden.

Auch dies kann mehrere Tage und Wochen dauern. Entsprechend der Schnelligkeit des Feedbacks des Kunden und auch der Verfügbarkeit des Designers auf Seiten des Dienstleisters.

Und dann kommen noch die Vertraglichen Details (Unterschrift Vertrag, Überweisung des initialen Betrages, etc.). Alles das braucht Zeit.

Wenn die erste Zeile Code geschrieben ist, kann somit bereits ein Monat und mehr ins Land verstrichen sein.

Wenn man jetzt noch hinzunimmt, dass unterschiedliche Versionen (z.B. Android und iOS) verlangt werden, dann ist das Zeit-Dilemma komplett. Es wird niemals möglich sein, in so einer kurzen Zeit (z.B. 2 Monate) eine fertige App oder Software zu haben.

Tipp: Man sollte genug Zeit einplanen. Nur mal das Testing auf Seiten des Dienstleisters kann einiges an Zeit benötigen. Und dann sollte man auch noch Endnutzer Tests durchführen. In vielen Projekten kann das alleine (Beta-Phase) mehrere Monate dauern.

Fazit

Die Liste lässt sich noch beliebig weiterführen. Das waren jedoch die Klassiker. Diese, werden in der einen oder anderen Form bei mir, gefühlt, jeden Tag nachgefragt.

Ich weiss auch gar nicht mehr wie ich darauf antworten soll. Man möchte ja auch nicht als unfreundlich rüberkommen. Zeit ist auch ein Thema, will man sich wirklich die Zeit nehmen, um zu erklären, wie das in der Softwareentwicklung funktioniert. Sozusagen die Basics? Das ist definitiv ein zusätzliches Dilemma für mich.

Wie handhabt Ihr das? Wie geht ihr mit solchen Anfragen um?

Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.

Neben dem Lastenheft, welches vom Auftraggeber erstellt wird, ist auch das Pflichtenheft, welches vom Auftragnehmer erstellt wird, wichtig.

In diesem Beitrag finden Sie eine Vorlage für solch ein Dokument, als auch ein paar Informationen hierzu.

Wozu braucht man dieses Dokument?

Ein Grossteil der IT Projekte scheitert. Dabei erscheinen, je nach Quelle, Zahlen von 30 bis 70 Prozent. In den meisten Fällen werden Budgets überschritten, die Abgabedaten nicht eingehalten oder das Projekt schlägt komplett fehl.

Der Grund liegt oftmals auch an der Weise wie die Projektbeschreibung geschieht.

Auf der Kundenseite steht oftmals ein Nicht-IT-Experte, welcher einfach eine “Software” benötigt.

Auf der Auftraggeber steht meistens ein IT Fachman/ -frau/ Firma.

Der Kunde hat oftmals die Tendenz, seine Projektanforderung in Emails und verbal weiterzugeben. Unterschiedliche IT Unternehmen/ potenzielle Auftragnehmer, werden diese unvollständigen Projektanforderungen in unterschiedlicher Weise aufnehmen und stark voneinander abweichende Angebote abgeben.

Das Projekt, aus Sicht des Kunden ist zwar immer das Gleiche, was beim Anbieter ankommt, ist jeweils immer etwas anders, weil zum Teil unterschiedliche Fragen gestellt werden, beziehungsweise unterschiedliche Antworten auf die gleichen Fragen gegeben werden.

Zwischenschritt Lastenheft

Um hier eine Basis zu schaffen, braucht es ein Lastenheft, welches vom Kunden erstellt wird. In diesem Dokument werden alle Anforderungen in einfacher Sprache verfasst.

Diese Zusammenfassung des IT Projektes können dann an alle potenziellen Auftragnehmer versendet werden. Auch weitere Ausführungen sollten in diesem Dokument aktualisiert und jeweils an alle Anbieter verteilt werden.

Hierdurch hat jedes Unternehmen die gleiche Anforderung vorliegen und man bekommt ein Angebot, welches mit anderen Offerten vergleichbar ist.

Vor dem Angebot selbst erstellen die IT Unternehmen meistens ein Pflichtenheft, um das Verstandene mit dem Auftraggeber abzugleichen.

Das steht in diesem Dokument

Das Pflichtenheft beschreibt, was das IT Unternehmen verstanden hat. Es berührt Punkte wie Ziele, Risiken, Systemumgebung, verwendete Technologien und auch Nicht-Ziele, also Bereiche welche nicht Teil des Projektes sind.

Das Dokument hilft später auch bei der Abnahme des Projektes durch den Kunden. Sollten weitere Änderungen gewünscht werden, kann auf das Pflichtenheft verwiesen werden.

Vorteile dieser Vorgehensweise

Hier einige Vorteile, welche man durch diese Herangehensweise hat:

• Besseres Verständnis der Anforderungen: Das gleiche Wort oder der gleiche Satz kann eine unterschiedliche Bedeutung für einen Nicht-IT’ler und einen IT’ler haben. Durch den schriftlichen Austausch kann sichergestellt werden, dass beide Seiten das Gleiche verstehen.
• Das Projekt kann besser abgesteckt werden: Der Projektumfang wird für beide Seiten klarer. Der Auftragnehmer kann im Dokument idealerweise umschreiben, was nicht Teil des Projektes sein wird. Der Auftraggeber kann seinerseits Einwände geben, falls es hier ein unterschiedliches Verständnis gibt.
• Aufwand kann reduziert oder erhöht werden: Sieht der Kunde, dass das Budget weit überschritten wird, kann man unwichtigere Teile des Projektes herausnehmen, in dem man das Dokument dementsprechend ändert.
• Das Angebot ist genauer: Das Pflichtenheft wird meistens Teil des Angebotes und damit ist das Angebot auch viel genauer, als ohne ein solches Dokument.

Der Nachteil:

Ein Nachteil eines solchen Dokumentes, ist der zeitliche Aufwand, welches dieses erzeugt. Besonders die Kundenseite, welches sich mit IT Projekten nicht wirklich auskennt, wird die Wichtigkeit von diesem höchstwahrscheinlich unterschätzen und sich den Aufwand für die Erstellung ersparen wollen.

Hier muss dem Kunden klar gemacht werden, dass die Erstellung von diesen beiden Dokumenten (Lastenheft/ Pflichtenheft) sinnvoll ist.

Fazit

Die Erstellung einer genauen Beschreibung der Anforderungen kann spätere Missverständnisse vermeiden, die Projektabwicklung beschleunigen und das Budget besser bestimmen lassen.

Es lohnt sich in fast allen IT Projekten, besonders aber bei solchen, welche sich über mehrere Mannmonate erstrecken.

Hier kostenfreie Vorlagen und Informationen:
Kostenfreies Muster
Eine Checkliste

Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt.

In most our projects and engagement the developers need to gather the requirements from the German client. This is not without pitfalls. Especially because of the different cultural background. But guess what: -> With the right process for gathering those information, this cultural gap can be easily overcome.

In the following we will give some practical advice to gather requirements from clients in Germany.

Have a first meeting

In the first step, have a short meeting with the client, asking some basic things about the project. The question can include:

“Who are the users of the system?”

“Kindly tell me more about the client who has ordered this system.”

“What modules will be in this software?”

“What technologies are to be used?”

“What are the requirements for documentation for the software?”

“Will other people also be working on the software for development?”

“Who is giving input regarding the requirements, except you? Is there someone from the customer side involved?”

etc.

etc.

etc.

These questions and many more should be asked, to get a feeling what the project is all about and also prepare mentally for the challenge. Also note down the points which are mentioned by the client. Usually one forgets most of the mentioned things after the first day after the meeting.

Repeat what the client has said

After hearing an answer or several answers, it’s always best to repeat in own words what has been understood.

For example: The client has been talking for a while about the project. Now the developer says: “Kindly let me repeat what you have said, so that we are on the same page. The system should be build in PHP and has 4 modules, which include the Customer Relationship Management, Human Resource Management, a Finance module, Travel Cost Calculator. The Customer Relationship Management Module should have the following functionalities……………………………………………………………”

Best would be to repeat the complete list of functionalities and the understanding about the project. This way the client in Germany is sure, that the developer in India has understood the requirement.

If that repetition is not done by the developer, then there will be always a doubt at the client side, whether the requirement has been understood clearly by the developer. The reason for this is also because sometimes the phone line is not clear in voice, the difference in accents (German Accent versus Indian Accent), the difference in perceptions (German Culture versus Indian Culture), the educational background (The client from Germany might be an MBA graduate, while the developer from India might be an Engineering graduate).

Therefore try to repeat at the end or during the meeting what the opposite side has said, so that all sides are sure about what everyone involved is speaking about.

Here a simple example to make this clear:
Client says: “I want this system to be programmed in PHP 5.4. The framework to be used is YII. The special thing about this software is, that it has an online calculator which takes its input from a server which will provide the information from an API, which will be provided by us”.

Developer says: “Thank you for telling about the requirement. Let me repeat this, so that it is clear that I have understood this properly. You want a system, which has to be programmed in PHP 5.4. The framework to be used is YII. The software also includes an online calculator which gets its information from an API, which will be provided by you. Is that correct so far?”

This might be a simple example. But this already shows that there could be a misunderstanding. Did the client mean by “provided by us” -> provided by the client company? Or did he mean “provided by the developer”. By repeating the requirements, the client will hear that the developer said “…API, which will be provided by you” and will intervene. The client will then say for example “Thank you for repeating the requirement. Most of it is correct. Only one point is not exact. The API has to be developed by you and will not be provided by us”.

So repeating the requirement will always help to clarify requirements and bring everyone in the project to the same page.

Ask for the requirement in writing

Especially in outsourcing projects to India (or any other country for that matter) it always makes sense to have the requirement in writing.

The client could be sending a first draft of the requirement as a Word file. Then the developer could ask questions regarding that requirement by writing the questions below the points which are in doubt. Through that, there would be a back and forth (sending Email back and forth with the Word document) where the document would become a fully fledged requirement document which can help as a guide during the development of the software.

Therefore: After the first meeting, ask the client to give the requirement in writing. Sometimes also the client will ask the developer to write down, what he has understood from the previous and current meetings so far, so that this becomes the document, on which future discussions can be based.

Use an online project management tool

Another very good way to gather the requirements properly is to use an online project management tool.

The developer would regularly post on which tasks he/ she is currently working on and also updating about the progress of each task.

By doing that, the client can from time to time check into the project management tool and see how far things have progressed. The advantage of that is also, that the client can intervene or can ask clarifying questions, if he sees developments which may go into the wrong direction.

A further advantage is also, that when the client writes directly into the project management tool, that the issue/ information is given in writing and can also be used for future reference.

Have a weekly meeting

A weekly short meeting can help to get both sides (the client from Germany and the developer/ developers from India) on the same page. It will also strengthen the relationship between both. The other person does not become a “stranger” with time.

It will also help to correct the path on which the developer is going. It could also correct misconceptions of the development which the client might have got.

Have a daily report

The daily report from the developer from India could be just an Email, updating about the current developments. Sometimes challenges will be encountered during development, these can be clarified with the client and solutions can be decided upon.

Have a hourly report

In some engagements it can make sense for the client in Germany to ask the developer in India, to give a short hourly report, which can be just one or two sentences, on what has been done in the previous hour.

Use common sense during requirement gathering

Sometimes it’s good not to always look at requirements from a technical point of view. Sometimes it makes more than sense to look at it from a business perspective.

One example:

——————————

Currently we work on project, where the client is insisting on a solution where he can measure the behavior of visitors to his premises. The current solution involves a plugin which does the calculations for measuring the visitors behavior. Unfortunately the plugin does not show the results in a manner how the client wants it. Now the developers are desperately trying to change that plugin, so that it works according to the clients requirement.

But in this case it would be better to look at the client requirement from a business perspective than from an IT perspective. By looking at the challenge from a business perspective it becomes quite clear, that the requirement cannot be solved by the current plugin, and that a individual programming of a solution becomes necessary which is not dependent on the current plugin.

If the programming of an individual solution would consume too much time and thus too much budget, then the decision could be made to try to get the best out of that currently used plugin.

——————————

The above example might not be the best one. But it shows on how the client side and the programmer side can sometimes fix their eyes on a solution which is based on their needs. The client wants to exactly see what the visitor is doing (business perspective) and the developer desperately tries to make this solution work via the plugin (technology perspective) which is available and also by configuring the plugin, so that it does what the client requires.

By using common sense (which can bring together the business perspective and the technology perspective) the client and the developer can speak about a solution which is feasible (i.e. can be developed with technology), is doing what it is supposed to be (i.e. measuring the visitors properly) and is also able to be developed in a specific timeframe (i.e. a timeframe which justifies the costs involved for the development and the subsequent benefit arrived from the programming).

Check in detail whether a requirement is implementable or not

Before starting to program it is also more than advisable to check, whether the task given by the client in Germany is implementable in that way or not.

Similar to the plugin example above, its always good to get a basic idea about the feasibility of the development part.

One example:

——————————

One client wanted to have a HTML5 plugin to be developed which would work on almost all mobile browsers. The issue here was that HTML5 is not a fully developed technology and has therefore many defects which sometimes cannot be easily solved.

For example, HTML5 plugins are not as fast on Android device browsers, as they are on iOS device browsers. The reason for this: Android is based on the programming language C. On top of that sits a Virtual Java Engine and in that the HTML5 plugin is executed. This long process makes the plugin very slow in Android device browsers.

In iOS device browsers, the HTML5 plugin is directly run on C, therefore the performance will be much better on iOS.

Only after several developments and customer feedback a possible solution was found. In the end, one HTML5 plugin was developed for the Android version and one HTML5 plugin for the iOS version. The system would recognize from which device (Android, iOS or WindowsPhone) the application would be called and accordingly the specific version would be handed out to the browser.

——————————

From the above example it becomes clear, that it is always a good advice to check the feasibility of the requirement and to inform in advance of possible advantages (in this case: Fast on iOS browsers) and disadvantages (in this case: Slow on Android devices).

Be open (i.e. openly say what is the challenge, do not hide it)

In the engagement model, which YUHIRO is pursuing, i.e. the client hires a developer full time and long-term, it’s not necessary for the developer to hide any thoughts regarding the developments (I would not say that it is required to hide any thoughts in other engagement models But in our case it is really not necessary).

Let’s just take the example with the evaluation of visitors in the above example. As long as the client does not know, that a Plugin is used for the development of the solution, he (the client) won’t be able to understand, that another solution might be difficult to arrive at, because it would consume a lot of time and effort.

So once the developer tells the client openly, that a plugin is being used, so as to make the development easier, then it will be also easier for the client to understand why there is so much reluctance to completely change the development by the developer.

By being open, the developer and the client can arrive more quickly at a possible decision and subsequently on a solution which will solve the issue.

Think about long term solutions

Especially in short outsourcing projects, there is a strong tendency to go for “quick fixes”. These “quick fixes” include Hard Coded variables, Unnecessary Code, An Overload In Plugins, the list goes on…

In projects with German clients its mostly about solutions which can be maintained, expanded and scaled in the future. i.e. the solutions should be able to be maintained and additional functionalities should be able to be implemented even many years down the line.

Therefore short term “quick fixes” should be avoided and always the strong, reliable and scalable long term solution preferred.

This long term thinking should be always kept in mind when speaking to clients from Germany.

It would be also Ok, to openly ask the client whether “Quick fixes” are allowed in a specific case, or whether this is a long term project (Sometimes our clients have themselves clients which give very short term projects, in these, it might be helpful not to go for elaborate solutions as the budgets will be usually be very small).

Build to hand over

Another point which should be kept in mind is: Develop the software in such a way, that a third developer would be always able to look into the code quickly and he/ she would be able to continue where you left off.

This might not be always in the best interest of the developer (at least when looking at the short term effects: The Developer can be replaced easily). But when looking at it in a long term perspective it makes more than sense to “Build to hand over”. The code will be more readable, well documented and easy to build upon. Even for the developer himself who programs on it, it will be easier in the future. May be he/ she will be required to look into the very code which was coded by him/herself and might not be able to understand what to do, if not programmed in a way “to hand over”.

Not only for one’s own purpose is it good to build the software in such a way, that it is possible to build on top of it easily. Also the persons involved with the developer will get a very good impression of him/ her. He/ she will be seen as an expert who writes re-usable code. With time the developer from India will get a very high status.

The advantages do not stop here. Usually clients in Germany will have additional developers which will work locally on the software code developed by the developer in India. They will get a positive experience by using a readable code, instead of one, which is impossible to decipher.

Conclusion

To sum it up: Honesty, trustworthiness and openness are all very important when working together with German clients in long term engagements. Especially when developers are dedicatedly working only for this one client.

Furthermore the points mentioned in this text can definitely help to make the client-developer relationship stronger and foster a culture were world-class (or at least German-Quality-class ) solutions can be developed.

Pictures: Flickr.com/ Downey/ Mann

The author: Sascha Thattil works at YUHIRO and supports companies from Germany to establish software teams in India. YUHIRO a German-Indian IT company, which provides software developers for IT companies, agencies and IT departments.

Für uns IT Unternehmen ist es oft schwer zu verstehen, was denn eigentlich die Anfragenden genau möchten. Der Grund liegt meist darin, dass es ein Kommunikationsproblem gibt. Die meisten wissen nicht genau, welche Informationen wir brauchen, um effizient zu arbeiten. Und wir als IT Unternehmen wollen auf der anderen Seite auch nicht zu aufdringlich sein.

Jedoch benötigen IT Unternehmen und Agenturen bestimmte Details des Projektes, sei es App-, Onlineshop- oder Software-Projekte, um gute Lösungen vorschlagen zu können.

In diesem Beitrag schreibe ich daher darüber, wie Anforderungen an ein IT Projekt formuliert werden können, so dass es für den Empfänger einfacher ist, das Projekt einzuordnen.

Wer ist der Anfragende?

Um einen ersten Einblick über das Projekt zu bekommen, kann es sinnvoll sein, zu beschreiben, wer der Anfragende überhaupt ist. Folgende Fragen können im Anforderungspapier stehen:

• Wer sind wir? (zum Beispiel: Stahlverarbeitendes Unternehmen, gegründet im Jahr 1976, Kaptialgesellschaft)
• Wo ist unser Firmensitz?
• Wieviele Mitarbeiter haben wir?
• Wieviel Umsatz haben wir im Jahr?
• Wieviele Standorte gibt es?

Grundinformationen zum Projekt

Auch hier geht man noch nicht auf das eigentliche Projekt ein, sondern umschreibt die weiteren Informationen, welche für das Projekt gelten.

• Wie hoch ist das Budget?
• Wer sind die Projektverantwortlichen?
• Warum soll das Projekt umgesetzt werden?
• Bis wann soll das Projekt fertig gestellt werden und was ist der Grund warum es bis dahin fertig gestellt werden soll?

Thema Budget

Beim Thema Budget, sind die meisten vorsichtig, da man die Befürchtung hat, dass das Angebot dem Budget angepasst wird. Der Gedanke liegt nahe „Wenn ich das Budget nicht nenne, dann bekomme ich es eventuell günstiger.“

Die Problematik liegt hierbei, dass ein Projekt auf verschiedenste Weisen ausgeführt werden kann. Man kann unterschiedliche Technologien, unterschiedliche Softwareentwicklungsprozesse, unterschiedliche Experten und noch viele weitere unterschiedliche Ansatzpunkte für das Projekt einsetzen. Jedoch hat alles das, einen Einfluss, auf den Aufwand für den Auftrag.

Weiss das IT Unternehmen also das Budget nicht, dann kann es nur schwer eine Aufwandskalkulation machen, welche auch dem Auftraggeber passt.

Weiss das Unternehmen oder die Agentur zum Beispiel, dass nur ein sehr geringes Budget X für diesen Auftrag bestehen, dann kann es von Anfang an, auf zum Beispiel, eine aufwendige Konzeption oder ein elaborates Design verzichten. Auch können weitere Ansatzpunkte gefunden werden, um das Projekt im vorgegebenen Budget zu entwickeln.

Ohne das Wissen über das Budget, ist das wie ein Dart-Spieler, der seinen Pfeil mit verbundenen Augen auf eine Dartscheibe wirft. Er kann zwar werfen, ob er trifft, ist in diesem Fall (ohne das Budget zu wissen) Zufall.

Nennen Sie also das Budget, welches Sie bereit sind, für dieses Projekt zu verwenden. Das wird eine optimale Ausgangssituation für alle Parteien bedeuten.

Die Softwareanforderung selbst

Jetzt kommt ein weiterer interessanter Teil. Die Anforderungen an die Software.

Es ist so, dass die meisten von uns wenig Interesse am Thema „Schreiben“ haben. Daher machen wir die Erfahrung, dass für die meisten Software-, Onlineshop- oder App-Projekte keine Anforderung in Schriftform besteht.

Es gibt jedoch einige Punkte, warum eine Anforderung in Schriftform so sinnvoll ist:

1. Jeder im Team, sei es auf Kundenseite (Projektmanager, Auftraggeber, etc.) oder IT Unternehmen (Softwareprogrammierer, IT Projektleiter, Management, etc.), kann die Anforderung bei Fragen hervorholen, und diese im Detail nachlesen.

   Falls diese Beschreibung nicht besteht, dann werden die gleichen Fragen, in alle Richtungen (Projektmanager zu Programmierer, Programmierer zu Auftraggeber, Management zu Projektleiter, etc.) gestellt, und die Fragen werden meistens nur zum Teil, oder gar unterschiedlich beantwortet. Was wiederum nur zu einem schlussendlich schlechten Software Code führt.

   Mit einer Anforderungen die im Detail in Schriftform beschrieben ist, sind alle Projektbeteiligten, wie man im Englischen so schön und passend sagt „On the same Page“, d.h. alle lesen und verstehen das Gleiche.

2. Am Anfang niedergeschriebene Punkte können relativ einfach, während der Erstellung des Dokumentes, umgeschrieben werden.

   Zum Beispiel könnte der Programmierer schreiben: „Die Software soll eine Datei in eine PDF Datei umwandeln“. Nach dem Gegenlesen, merkt der Auftraggeber, das da etwas fehlt und schreibt das um als „Die Software soll eine Datei in eine PDF umwandeln, der Nutzer hat optional die Möglichkeit die Datei in eine Excel Datei umzuwandeln.“ Daraufhin kann wiederum der Programmierer seinen Input zu diesem Satz geben. Eventuell ist das ja so, nicht einfach umsetzbar.

   Jetzt könnte man sage: So ein hin und her ist ziemlich zeitaufwendig.

   Was man hierbei jedoch vergisst ist, was wäre wenn der Programmierer die Anforderung, so wie er sie am Anfang verstanden hat, umsetzt. Das heisst, „Die Software soll eine Datei in eine PDF Datei umwandeln“. Erst nach der umgesetzten Software wird der Auftraggeber feststellen, das etwas fehlt. Die Iterationen im Software-Code umzusetzen, kann mehrere Tage oder gar Wochen, mit den verbundenen Kosten, dauern.

   Auf der anderen Seite lässt, sich in einer, zum Beispiel, Word Datei, die Anforderung sehr einfach mit der Rücktaste löschen und erneut schreiben.

   Es ist also schon ein Unterschied, ob man Tage oder Wochen programmiert, was ja auch bezahlt werden muss, oder ob man die Anforderung relativ schnell in einem Text-Editor ausbessert und erst nach der Beschreibung der Anforderungen an die Software, mit dem Programmieren anfängt.

3. Die Anforderungen können, durch die schriftliche Beschreibung, zeitlich besser, vom IT Unternehmen eingeschätzt werden.

   Die Anforderung „Die Software soll eine Datei in eine PDF umwandeln“ benötigt eventuell 4 Stunden. Die Anforderung „Die Software soll eine Datei in eine PDF umwandeln, der Nutzer hat optional die Möglichkeit die Datei in eine Excel Datei umzuwandeln.“ benötigt eventuell 8 Stunden.

   Ohne diese Aufstellung wird sich der Kunde auch fragen, warum er denn jetzt 8 Stunden Aufwand zahlen soll, wenn er oder sie vielleicht nur die erstere Anforderung, welche 4 Stunden dauert, umgesetzt haben will.

   Daher schafft eine genau beschriebene Anforderung auch Vertrauen zwischen den Parteien.

4. Auch ein Zeitplan kann aufgrund der Beschreibung erstellt werden.

   Es wird dem IT Unternehmen gut möglich sein, einen Zeitplan zu erstellen, und diesen auch einzuhalten, wenn die Beschreibung genau vorgenommen wurde.

   Auf der anderen Seite, kann man ein IT Unternehmen, nicht darauf hinweisen, dass der Zeitplan nicht eingehalten wird, wenn von Anfang an gar nicht feststeht, was zu entwickeln ist.

5. Das Testteam kann die Beschreibung nutzen, um zu Wissen, welche Funktionalitäten es zu prüfen gibt.

   Ohne die Beschreibung, müssen die Tester immer wieder beim Programmierer oder beim Programmierteam nachfragen, welche Funktionalitäten es nun zu testen gibt. Hiermit werden auch die Programmierer nicht zufrieden sein, denn sie möchten nicht immer wieder in ihrer Arbeit gestört werden.

   Dieses ständige Nachfragen vom Test-Team kann auch zu internen Konflikten führen, denn die Entwickler werden sich höchstwahrscheinlich an das Management richten, und Nachfragen, weniger Fragen vom Test-Team zu bekommen. Dies führt wiederum zu einer Negativ-Spirale. Wenn sich die Tester nicht mehr trauen, oder nicht mehr in der Lage sind, bei den Programmiereren nachzufragen, dann werden die Tests nicht vollständig und gut durchgeführt, was zu vielen Fehlern im schlussendlichen Software-Code und zu Frustration beim Auftraggeber und bei den Nutzern der Software führt.

   Durch eine Niederschrift der Anforderungen, können die Tester, anstatt an die Entwickler heranzutreten, einfach die Beschreibung lesen, und genau wissen, was zu testen ist und was nicht.

6. Spätere Änderungen werden durch die genaue Beschreibung einfacher möglich.

   Software ist meistens nicht statisch, dass heisst, nach einer Weile möchte man den Software-Code erweitern, so dass es weitere Funktionalitäten abdeckt. In dem bisherigen Beispiel könnte eine weitere Funktionalität sein „Die Software soll nun auch Bild Dateien in JPEG Dateien umwandeln“.

   Wenn das jetzige IT Unternehmen, oder ein anderes IT Unternehmen, die frühere Beschreibung liest, dann weiss es, was bereits umgesetzt wurde, und welche Anforderungen nun umgesetzt werden müssen.

Fazit

Viele Auftraggeber scheuen sich, eine genaue Beschreibung der Anforderungen zu erstellen. Dies liegt an verschiedensten Gründen:

a) Scheu vor dem Schreiben – Schreiben gefällt den wenigsten, auch erfahrenen Managern oder anderen Personen

b) Keine Zeit – Man möchte sich die Zeit nicht nehmen, um die Anforderungen zu formulieren. Man hat das Gefühl, das sei Zeitverschwendung. Der Gedanke liegt nahe „In der Zeit könnte die Programmierung schon beginnen, und dann sind wir schneller am Ziel“

Das sind natürlich nicht die einzigen Gründe, für das nicht Schreiben der Spezifikationen. Jedoch sind dies, unserer Meinung nach, die Hauptgründe.

Falls es „Scheu vor dem Schreiben gibt“ sollte man Anfangen, sich das Schreiben anzugewöhnen. Dies kann man zum Beispiel durch einen Blog schaffen, aber auch Briefe an Verwandte und Freunde können ein Einstieg sein, um sich diese Angewohnheit anzueignen.

Der Punkt „Keine Zeit“ wurde bereits im Beitrag erwähnt. Durch die anfänglich „gesparte“ Zeit, wird das Projekt selbst, sehr komplex, und der Aufwand, das Projekt umzusetzen, steigt oftmals um ein vielfaches.

Nehmen Sie sich also die Zeit die Anforderungen genauestens, oder zumindest so genau wie möglich zu beschreiben, bevor Sie ein IT Projekt starten. Dadurch sparen Sie sich Zeit, Geld, Nerven und sind gleichzeitig besser für die Zukunft gerüstet.

Was ist Ihre Erfahrung mit der Formulierung von Anforderungen an App-, Onlineshop- oder Softwareprojekte? Ich freue mich auf einen Austausch.

Der Autor: Sascha Thattil arbeitet bei YUHIRO und hilft Unternehmern und Unternehmen beim einfachen Aufbau von Programmier-Teams in Indien. YUHIRO ist ein deutsch-indisches Unternehmen welches IT Firmen, Agenturen und IT Abteilungen Softwareentwickler bereitstellt und Softwareprojekte abwickelt.