In der Entwicklung von Projekten geht es vordergründig um die eingesetzte Technologie, die Umsetzung und die Einbindung in existierende Strukturen. Das konzeptionelle Arbeiten im Vorfeld kommt oftmals zu kurz. Die Ereignisse sind absehbar. Wichtige Überlegungen werden nachträglich in einem späten Stadium des Projektes angestellt und später Entscheidungen getroffen. Wenn man dies agile Entwicklung nennt, hat man das Projektgeschäft noch nicht verstanden. Ziel eines Softwareprojektes ist es, eine Idee, einen Plan umzusetzen. Es hat nicht das Ziel einen Plan während der Entwicklung zu fassen. Aber welche Möglichkeiten hat man ein Konzept zu erstellen.

Hier sind 5 wichtige Tipps:

  • Einen Rahmen schaffen
  • Betriebsblindheit eliminieren
  • Verständnis schaffen
  • Bewusste Lücken zulassen
  • Einen Abschluss finden

Betrachten wir die einzelnen Schlüsselelemente etwas genauer:

Einen Rahmen schaffen

Definieren Sie Ihre Aufgabe genau und in möglichst kurzen Sätzen. Beschreiben Sie aus fachlicher Sicht das Ergebnis.

Dies könnte so aussehen

Unsere geplante Software soll alle Prozesse, Richtlinien und Arbeitsanweisungen des Unternehmens revisionssicher und dauerhaft verwalten. Die Anzeige muss von jedem Arbeitsplatz aus möglich sein. Eine Volltextsuche ist erforderlich.

oder so

Für die Einführung unseres neuen Produktes soll ein B2B- Shop im Internet geschaffen werden, der den komplexen Produktkatalog einfach und übersichtlich darstellt und direkte Bestellungen ermöglicht.

Dieser Rahmen bildet die Leitlinie der weiteren Arbeit. Auf dieser Basis können Anforderungen erhoben, User-Stories verfasst und Randbedingungen erkannt werden. Oftmals ändert sich der Rahmen in einer frühen Phase des Projektes, da Projektbestandteile ohne Diskussion vorausgesetzt wurden oder Anforderungen falsch verstanden wurden.

Betriebsblindheit eliminieren

Suchen Sie sich ein Team an externen Unterstützern, die Ihnen helfen, die schnell aufkommende Betriebsblindheit zu reduzieren beziehungsweise zu eliminieren.

Diese müssen keine externen Berater sein (das wäre toll für Scandio). Oft genügt es im eigenen Unternehmen nach Unterstützung aus anderen Abteilungen zu fragen. Diese kann man in Brainstorming-Sessions und Feedback-Runden als Qualitätssicherung ansehen. Je mehr man sich selbst durch die Hinzunahme anderer Personen hinterfragt, desto genauer kennt man die Materie und ist auf Stolpersteine vorbereitet. Auch finale Reviews können wichtige Punkte ans Tageslicht bringen, die in einer späteren Phase das Projekt massiv stören würden.

Verständnis schaffen

Um während der Konzeptionsphase ein Verständnis für das zu planende System zu schaffen, ist alles erlaubt. Es gibt nicht gut und nicht böse. Nicht jeder kann ein UML-Diagramm lesen - Entwickler schon - aber die kommen erst einen Schritt später zum Projekt. Also kann der Kunde zu diesem Zeitpunkt keinen Nutzen daraus ziehen. Hat es Sinn, dies in eine spätere Phase zu schieben? Was nützen 200 tabellarische Use-Cases, die keiner liest, weil deren Inhalte gegen Null gehen? Genügt im ersten Schritt eine Auflistung der Anforderungen und gewünschten Funktionen in Wiki Seiten und ein klärender Diskussionsbaum darunter?

Wichtig ist, dass die Projektbeteiligten sich am Ende ein Bild von der Anwendung machen können und das Geschriebene mit gutem Gewissen bestätigen. Im Rahmen unserer Arbeit hat sich die gemeinsame Konzeption in Confluence und die Backlog-Planung mittels JIRA als vorteilhaft erwiesen. Für die Schaffung eines gemeinsamen Verständnisses über die Funktion nutzen wir massiv Mockups als Diskussionsgrundlage. Ein Projekt mit 100 Mockups oder mehr ist keine Seltenheit.

Bewusste Lücken zulassen

Lücken in der Konzeption sind akzeptabel, sofern man diese kennt. Es gibt konzeptionelle Elemente, die kann man erst nach Abschluss eines Sprints, einer Iteration klären. Ein gutes Konzept zeigt die Lücken auf und ermöglicht eine spätere Klärung. Lücken, die nicht bewusst wahrgenommen werden, müssen vermieden werden. Daher nehmen wir unklare Punkte bewusst mit in das Konzept auf. Dabei ist es nicht relevant, ob diese im ersten Schritt bearbeitet werden sollen oder nicht. Es gibt immer eine Stufe 2.

Einen Abschluss finden

Konzepte müssen fertig werden! Ein Konzept ist nicht der Versuch alle Unmöglichkeiten zu bewerten und aus dem Weg zu räumen. Das ist nicht möglich. Speziell in der Softwareentwicklung müssen Konzepte viel leisten. Der Funktionsumfang, die Kosten, der Zeitplan und die Beteiligten sollen möglichst früh feststehen. Um ein Konzept zu finalisieren, ist es notwendig Ergebnisbereiche zu definieren, die nicht in allen Punkten in Stein gemeißelt sind. Wenn der Fertigstellungstermin wichtig ist, dann muss Spielraum im ersten Funktionsumfang sein. Sind die Kosten fixiert, kann man das durch die Reduzierung des Leistungsumfangs und die Zeitplanung in den Griff bekommen.

Nur die Qualität ist eine nicht veränderbare Konstante.