Solcept Workflow: Die Schritte eines Projektes

Diese erste Phase ergibt für Sie typischerweise folgende Abläufe und Informationsflüsse:

1. Geheimhaltungserklärung
   • gemeinsam unterzeichnen wir ein NDA, damit Ihre Informationen geschützt sind
2. Projektinformationen/ Lastenheft
   • in einem ersten gemeinsamen Workshop nehmen wir Ihre Projektinformationen auf
   • zusätzlich übergeben Sie uns Ihre Dokumente (PDF): Lastenhefte, bestehende Produkte, technische Informationen...
3. Entwurf gemeinsames Projektverständnis
   • da es uns sehr wichtig ist, Ihre Bedürfnisse genau zu verstehen, dokumentieren wir alle Informationen über das Projekt gemäss dem Workshop und Ihren Anforderungs-Dokumenten in einem gemeinsamen Projektverständnis ("Common Understanding")
   • Sie bekommen ein PDF zur Review
4. Feedback
   • Sie geben uns zu diesem Entwurf Feedback, um sicherzustellen, dass wir Ihre Ziele richtig verstanden haben
   • in der Form, wie es für Sie am einfachsten geht, entweder direkt im PDF, als Email oder in einer Telefonkonferenz
5. finale Version des gemeinsamen Projektverständnis inkl. detaillierten Aufwände und erste Planung
   • sobald alle Differenzen ausgeräumt sind, schätzen wir die Entwicklungsaufwände, planen grob das Projekt und erstellen damit die finale Version des Projektverständnisses
   • diese Abschätzung und das finale gemeinsame Projektverständnis stellen wir Ihnen in einem Workshop vor
   • Sie bekommen die detaillierte Abschätzung und das gemeinsame Projektverständnis als PDF
6. Offert- und Bestellprozess
   • dieser findet nach Ihren Vorgaben und Prozessen statt

Diese erste Phase und die dabei erstellten Dokumente sind für Sie kostenlos.

Graphisch sieht das so aus:

Die regelmässigen Projektauswertungen für jeden Sprint, d.h. alle vier Wochen ergeben im Normalfall folgende Informationsflüsse:

1. Projektstatus-Report
   • wir erstellen für Sie einen Projektstatus mit unter anderem folgenden Informationen:
     • technische Zielerreichung und Planung
     • Aufwände
     • Risiken und Aktionen zur Risikobegrenzung
     • Offene Punkte
   • Sie bekommen den Bericht als PDF und er wird auf unserem Wiki abgelegt
2. Projektstatus-Besprechung
   • Ihr Projektsteuerungs-Team diskutiert den Bericht mit unserem Projektleiter in einer Telefonkonferenz und setzt die technischen Ziele für die nächsten Sprints fest

Sitzungen werden möglichst nur bei Bedarf durchgeführt und erzeugen folgende Informationsflüsse:

1. Einladung/ Agenda-Entwurf
   • wir erstellen einen Entwurf der Agenda
   • Sie können die Agenda auf unserem Wiki anpassen
2. Sitzung
   • Ihre und unsere Spezialisten entscheiden über die Punkte der Agenda und über Massnahmen
   • Entscheide und Massnahmen werden gerade im Wiki dokumentiert
3. Protokoll
   • wir stellen das Protokoll mit Entscheiden und Massnahmen fertig
   • Sie können das Protokoll auf unserem Wiki reviewen

Wenn Sie Fehler in den Resultaten der Sprints entdecken oder Änderungen implementiert haben möchten, dann ergeben sich typischerweise folgende Abläufe und Informationsflüsse:

1. Customer Request/ Kundenanforderung
   • Sie dokumentieren das technische Verhalten, das Sie geändert haben möchten
   • in einem "Customer Request" Ticket in unserem Ticket-System
2. Technische Klärung
   • gemeinsam mit Ihnen klären wir das technische Verhalten, wann und wie es auftritt
   • die technische Lösung wird im "Customer Request" Ticket dokumentiert
3. Triage/ Aufwandschätzung
   • Fehler und kleine Änderung werden direkt implementiert
   • grössere Änderungen werden zuerst abgeschätzt, damit Sie über den Aufwand entscheiden können
   • der Aufwand wird im "Customer Request" Ticket dokumentiert
4. Implementationsentscheid
   • Sie entscheiden über die Implementation: 'Implement' oder 'Do Not Implement'
   • im "Customer Request" Ticket
5. Implementation
   • wir implementieren die gewünschte Lösung

Graphisch sieht das so aus:

Wenn unser Risikomanagement entdeckt, dass wichtige Entscheide zu Risiken des Produktes zu treffen sind, dann ergeben sich diese Interaktionen und Informationsflüsse:

1. Risikoeinschätzung
   • gemeinsam mit Ihren Spezialisten diskutieren wir die Risikoeinschätzung
2. Substantial Decision 
   • wenn die Risikoeinschätzung bzw. Lösungen zwischen unseren und Ihren Spezialisten stark auseinanderliegen, dokumentieren wir die verschiedenen Einschätzungen
   • als "Substiantial Decision" Ticket in unserem Ticket System
3. Mitigationsentscheid
   • Sie entscheiden über die gewünschte Lösung
   • im "Substiantial Decision" Ticket
4. Implementation
   • wir implementieren die Lösung, für die Sie sich entschieden haben

Als erster Schritt für eine Entwicklung erstellen wir die erste Spezifikation und Systemarchitektur mit den Schlüsselkomponenten, dabei entstehen für Sie diese Interaktionen und Informationsflüsse:

1. Lastenheft/ technische Informationen und Anforderungen
   • Ihre Informationen aus der Projektentwicklungsphase und zusätzliche Dokumente werden gesammelt
   • nach Bedarf werden offene Fragen in Workshops geklärt
2. Entwurf Pflichtenheft (technische Spezifikation)
   • in den Systemspezifikationen dokumentieren wir alle Ihre Anforderungen und die noch offenen Punkte
   • Sie bekommen ein PDF ( auch auf unserem Wiki) für Reviews und als Grundlage für eventuelle Workshops
3. Entwurf Systemarchitektur
   • wir erstellen sobald wie möglich die grundlegende Struktur des Produktes und wählen die Schlüsselkomponenten und -technologien aus
   • wir prüfen die Auswirkungen dieser Architektur auf die Anforderungen und das Pflichtenheft
   • Sie bekommen ein PDF ( auch auf unserem Wiki) für Reviews und als Grundlage für eventuelle Workshops
4. Feedback/ Workshops
   • Sie geben uns Feedback zu beiden Dokumenten, bis ein genügend stabiler Stand für den Start der Implementation erreicht ist, dieser Stand hängt hauptsächlich vom gewählten Projekttyp ab:
     • für klassisch mit agiler Abwicklung muss mehr Stabilität erreicht werden, v.a. wenn der Aufwand oder die Termine fix sind
     • für voll agil, werden alle vorhandene Informationen aufgenommen und es müssen in dieser Phase keine zusätzlichen Entscheide zu Anforderungen getroffen werden
5. Freigabeentscheid
   • Sie geben die Systemspezifikation und evtl. die Systemarchitektur frei, sobald die Projektrisiken genügend gemindert sind

Die Entwürfe der Systemspezifikation (des Pflichtenheftes) und der Systemarchitektur werden von uns als Grundlage der Implementation während des ganzen Projektes nachgeführt, die aktuelle Version steht Ihnen auf unserem Wiki als PDF zur Verfügung.

Graphisch sieht das so aus:

Nach einer Anfangsphase ("Inception") ergeben sich pro vierwöchigen Sprint für Ihre Software typischerweise diese Interaktionen und Informationsflüsse in denen wir schrittweise und iterativ Ihre optimale Lösung erarbeiten:

1. Software-Implementation
   • wir entwickeln und verifizieren einen neuen (Zwischen-) Release für Ihre Software basierend auf der Systemarchitektur und dem abgemachten Backlog
   • diesen Release stellen wir Ihnen zusammen mit den Testresultaten auf unserem Wiki zum Download bereit
2. Integration, Test und Feedback
   • Sie testen die Software auf der Hardware und in Ihrem System
   • Sie geben uns Fehler und Änderungswünsche bekannt als "Customer Request" Tickets in unserem Ticket System
3. Backlog-Entscheid
   • Zusammen mit Ihnen entscheiden wir in einer Besprechung (z.B. mit MS Teams) über die Features, Änderungen und Fehlerkorrekturen, die im nächsten Sprint implementiert werden

Diese Zyklen führen wir gemeinsam bis zur Seriefreigabe durch.

Die Elektronikentwicklung folgt mit der Produktion von Prototypen langsameren Zyklen (normalerweise 2..3 bis zur Serie) als die Software, Sie erleben typischerweise ähnliche Interaktionen und Informationsflüsse:

1. Hardware-Implementation
   • wir entwickeln und verifizieren einen neuen Prototypen für Ihre Elektronik basierend auf der Systemarchitektur
   • die Fabrikationsdaten (Gerber, Bestückungsdaten als Spreadsheets) stellen wir auf unserem Wiki für Sie oder den Leiterplattenhersteller und Bestücker (EMS: Electronic Manufacturing Service) bereit
2. Produktion
   • die Leiterplatten werden hergestellt und bestückt
3. Produktions-Feedback
   • der Leiterplattenhersteller und der Bestücker geben zur Produzierbarkeit der Elektronik Feedback
     • darum versuchen wir, die Prototypen bei Ihrem Seriehersteller fertigen zu lassen
4. Verifikation
   • wir testen die Elektronik auch zusammen mit der Software aus
   • Sie haben auf unserem Wiki Zugriff auf alle Herstellinformationen, Schemas und Testresultate
   • Sie bekommen die Prototypen
5. Integration, Test und Feedback
   • Sie testen die Hardware mit der Software und in Ihrem System
   • Sie geben uns Fehler und Änderungswünsche bekannt als "Customer Request" Tickets in unserem Ticket System
6. Backlog-Entscheid
   • Zusammen mit Ihnen entscheiden wir in einer Besprechung (z.B. mit MS Teams) über die Features, Änderungen und Fehlerkorrekturen, die im nächsten Prototypen implementiert werden

Diese Zyklen führen wir gemeinsam bis zur Seriefreigabe durch.

Wenn wir mit Elektronik und Software die Tests für Zertifizierung und (Vor-) Seriefreigaben durchführen, sehen die Interaktionen und Informationsflüsse so aus:

1. Release Kandidat
   • wir erstellen und testen die Elektronik und Software
   • entweder bauen wir diese in Ihr System ein oder wir liefern Ihnen die Platinen für den Einbau
   • Sie haben Zugriff auf alle Testdaten, Schemas und Herstelldaten auf unserem Wiki
2. (Pre-) Compliance Tests 
   • je nach Risikoeinschätzung führen Sie, wir oder ein Testlabor die Konformitätstests durch
   • die Testresultate sammeln wir auf unserem Wiki
3. Validierung/ Feldtests: Freigabe
   • Sie führen mit dem gesamten System die Validierung durch
   • Sie geben per Email die (Vor-) Serie frei
4. Entwicklungsdaten
   • Sie bekommen von uns alle Entwicklungsdaten
   • als Head Revision des Subversion Repositories, in dem wir alle Entwickungs-Artefakte ablegen

Diese Tests und Freigaben werden gemäss Ihren Anforderungen, bzw. denen Ihres Projekt-/ Programm-Managements durchgeführt, typischerweise zumindest zwei Mal, zuerst für die Pre-Compliance und dann für die finale Konformität (Compliance).

Während der Phase der Produktpflege, nach dem Seriestart bleibt unser Ticket System für Sie zugänglich. Dadurch können Sie Probleme, Änderungswünsche oder Obszoleszenzen als "Customer Requests" melden.

Je nach (Zero-Cost-of Ownership) Garantie und Service Level die wir vereinbart haben, lösen wir die Probleme für Sie.