SPIEL BUCH

Ein Projekt beginnt mit der Analyse der Kundenanforderungen. Die Analyse der Anforderungen kann in die folgenden Phasen unterteilt werden:

1. Erfassen und Analysieren der Kundenanforderungen
2. Anforderungen dokumentieren
3. Schätzung des Projekts

Teammitglieder bei der Anforderungsanalyse:

• Projektleiter
• Verkaufsleiter
• Designer
• TeamLead und das Team der Entwickler

Erfassen und Analysieren von Kundenanforderungen

Die Phase des Erfassens und Analysierens der Kundenanforderungen ist der Schlüssel zum Projektentwicklungsprozess. Dauer und Qualität des Projekts hängen davon ab, wie gut diese Phase durchgeführt wird.

Anforderungen sind die Spezifikationen dessen, was implementiert werden muss. Das Sammeln von Anforderungen erfordert eine enge Kommunikation zwischen allen Beteiligten, vom Kunden bis zum PM.

Kundenanforderungen können funktional oder nicht-funktional sein. Funktionale Anforderungen spezifizieren das Verhalten des Systems und beantworten die Frage „Was soll das System in bestimmten Situationen tun?“. Nicht-funktionale Anforderungen beantworten die Frage „Wie soll das System funktionieren?“ und beschreiben, welche Eigenschaften oder Merkmale es haben muss.

Obwohl der PMBOK Guide viele Methoden der Anforderungserfassung enthält, verwendet unser Unternehmen nur die folgenden Methoden:

• Fragebögen und Umfragen
• Interviews
• Analyse der Dokumente
• Brainstorming
• Prototyping

Die Anforderungsanalyse trägt dazu bei, Probleme mit Mehrdeutigkeit, Unvollständigkeit und Inkonsistenzen zwischen einzelnen Anforderungen zu vermeiden. Softwareanforderungen sollten gut dokumentiert, realistisch und prüfbar sein und einen für die Projektentwicklung ausreichenden Detaillierungsgrad aufweisen.

Für eine erfolgreiche Arbeit in der Phase „Sammlung und Analyse der Kundenanforderungen“ muss der Manager über die folgenden Eigenschaften verfügen:

• Fachwissen
• Die Fähigkeit zuzuhören
• Die Fähigkeit, kompetente Fragen zu stellen
• Fähigkeiten zur Schaffung einer angenehmen Kommunikationsumgebung
• Die Fähigkeit zu beobachten
• Stressresistenz
• Die Fähigkeit, Informationen zu analysieren und zu verarbeiten
• Die Fähigkeit, Probleme zu lösen und Konflikte beizulegen
• Die Fähigkeit, mit einem Team zu arbeiten
• Kreativität

Anforderungen dokumentieren

Nach Abschluss der Phase „Erfassen und Analysieren der Kundenanforderungen“ muss der Manager sicherstellen, dass alle Kundenanforderungen sorgfältig analysiert und dokumentiert wurden.

Wir nennen dokumentierte Anforderungen in jeder Form eine RL (Requirements List).

In einer idealen Projektmanagement-Situation dokumentieren wir die Anforderungen und erstellen die Anforderungsliste selbst. Oft arbeiten wir jedoch mit bereits vorhandenen Anforderungslisten, die von Kunden zur Verfügung gestellt werden.

Die Selbstdokumentation von Anforderungen erfordert eine besondere Herangehensweise seitens des PMs. Außerdem erfordert sie Fähigkeiten, Erfahrung und Zeit.

Die gesamte Dokumentation wird vom PM zusammen mit dem TeamLead/TechLead und dem Entwicklungsteam vorbereitet, die auch mit dem Kunden kommunizieren, um das fertige Material zu arrangieren und zu bestätigen.

Da Unternehmen häufig die Projektmanagement-Methodik Agile verwenden, die an unsere Projekte und Kunden angepasst ist (d.h. nicht in ihrer ursprünglichen Form), wenden wir die entsprechenden Dokumentationsanforderungen an:

• SRS – Spezifikation der Softwareanforderungen
• Funktionsbeschreibung in beliebiger Form in einem Word-Dokument
• Interne Projektspezifikationen gemäß der Vorlage des Unternehmens

Nach der Genehmigung durch den Kunden wird die vorbereitete Dokumentation an das Team für die Schätzungsphase geschickt. Links zu den Dokumenten oder die Dateien selbst müssen in einem speziellen Abschnitt des WIKI in Redmine vorhanden sein und bei Bedarf vom Projektmanager aktualisiert werden.

Projekt-Schätzung

Nachdem wir die Anforderungen des Kunden erfasst und analysiert haben, übermitteln wir die dokumentierten Daten an das Entwicklerteam zur Schätzung. Der PM ist für die Projektschätzung (Kostenvoranschlag) verantwortlich, während die Entwickler und Designer maßgeblich an der Schätzung beteiligt sind.

Die Projektkalkulation in Redmine befindet sich in einem speziellen Projekt namens Quotes. Wir bewahren alle Berechnungen für Schätzungen in einem Google Sheet auf. Dieses Tabellenblatt hat ein spezielles Format, das intern von unserem Unternehmen entwickelt wurde.

Als Ergebnis der Arbeit der Entwickler in dieser Phase erhält der PM eine XLS-Datei mit einer detaillierten Schätzung der einzelnen Projektfunktionen. Der PM schickt diese Datei mit der Schätzung an den Kunden und bespricht die Angebote. Am Ende dieser Diskussion werden die finanzielle Schätzung des Projekts und ein geschätzter Zeitrahmen festgelegt.

Anforderungen sind die Spezifikationen der zu implementierenden Funktionen. In den Anforderungen werden die Funktionalität der Website oder des Moduls, die Benutzereigenschaften, die Kompatibilität mit Betriebssystemen und verschiedenen Geräten sowie eine Beschreibung des Verhaltens der verschiedenen Elemente des Projekts spezifiziert.

Der Zweck der Anforderungsanalyse besteht darin, so viele Informationen wie möglich über den Kunden und die Besonderheiten der Aufgaben zu erhalten, den Projektumfang zu spezifizieren, Risiken zu bewerten und eine Projektgruppe zu bilden, die für einen Großteil der zukünftigen Arbeit verantwortlich ist.

Beim Einholen und Analysieren der Kundenanforderungen sollten Sie alle Arten von Anforderungen berücksichtigen und sicherstellen, dass nichts Kritisches übersehen wird. Andernfalls könnten Schätzungen fehlerhaft sein, Bedingungen nicht eingehalten werden, Kunden frustriert werden und Fristen nicht eingehalten werden. Es empfiehlt sich, eine Checkliste für alle Arten von Anforderungen zu erstellen.

Arten von Anforderungen

Funktionale Anforderungen:

• Geschäftliche Anforderungen
• Benutzeranforderungen
• Systemanforderungen
• Anforderungen an die Funktionalität

Nicht-funktionale Anforderungen:

• Geschäftsregeln
• Externe Schnittstellen
• Qualitätsanforderungen
• Einschränkungen bei der Entwicklung

Mehr über funktionale Anforderungen

Geschäftliche Anforderungen. Was die zu entwickelnden Funktionen aus der Sicht der Geschäftsseite leisten sollen. Das Wort „Geschäft“ kann in diesem Zusammenhang als eng verwandt mit dem Wort „Kunde“ betrachtet werden. Betrachten Sie folgendes Beispiel: eine Werbeseite, die erstellt wird, um ein bestimmtes Publikum für das Produkt eines bestimmten Unternehmens zu gewinnen.

Benutzeranforderungen. Diese Anforderungen beschreiben die Ziele der Benutzer der Website, die sie auf der Website leicht erreichen oder ausführen können sollten. Diese Anforderungen werden oft in Form von Anwendungsfällen dargestellt. Mit anderen Worten, die Benutzeranforderungen beschreiben, was der Benutzer tun kann: sich registrieren, bestimmte Informationen anzeigen, Daten nach einem bestimmten Algorithmus neu berechnen usw.

Systemanforderungen. Diese Merkmale beschreiben sowohl die Anforderungen an die Hardware (z.B. Typ und Frequenz der CPU, Größe des Arbeitsspeichers, Festplattengröße) als auch die Anforderungen an die Softwareumgebung (z.B. Betriebssystem, installierte Systemkomponenten und Dienste usw.). In der Regel werden diese Anforderungen vom Hersteller oder dem Autor der Software festgelegt.

Anforderungen an die Funktionalität. Diese Anforderungen definieren die Funktionalität bzw. das Verhalten eines Softwaresystems. Sie sollten von den Entwicklern auf der Grundlage der Geschäftsanforderungen und im Kontext der Benutzeranforderungen skizziert werden. Mit anderen Worten: Diese Anforderungen sind das, was die Entwickler tun werden, um die Benutzeranforderungen umzusetzen.

Mehr über nicht-funktionale Anforderungen

Geschäftsregeln. Diese legen fest, warum das System genau so funktionieren soll, wie es geschrieben wurde. Diese Anforderungen können mit der Gesetzgebung oder mit internen Kundenvorschriften verknüpft sein, oder sie können verschiedene andere Faktoren beinhalten.

Externe Schnittstellen. Dazu gehören nicht nur Benutzeroberflächen, sondern auch Protokolle für die Anbindung an andere Systeme, wie CRM-Systeme oder externe Datenbanken.

Qualitätsanforderungen. Diese Anforderungen beziehen sich auf Fragen der Transparenz, Interaktion mit anderen Systemen, Integrität, Nachhaltigkeit usw. Sie umfassen:

• Benutzerfreundlichkeit
• Leistung
• Wartbarkeit
• Zuverlässigkeit
• Schnittstellen
• Skalierbarkeit
• Benutzer- und Software-Schnittstellen

Einschränkungen bei der Entwicklung. Die drei häufigsten Projektbeschränkungen sind Dauer, Kosten und Qualität, die auch als „Triple Constraints“ bezeichnet werden. Normalerweise können bei der Planung eines Projekts die Anforderungen für zwei dieser drei Einschränkungen erfüllt werden. Ein Projekt kann zum Beispiel schnell und effizient durchgeführt werden, aber es kann teuer sein. Ein Projekt kann kostengünstig und hochwertig sein, aber es kann ein langfristiges Projekt sein. Wenn der Kunde schnelle und kostengünstige Ergebnisse wünscht, kann die Qualität darunter leiden.

Eingabedaten:

• Die Ideen des Kunden
• Aufgabe des Kunden
• Die allgemeine Vision des Projekts

Teilnehmer:

• Projektleiter oder Business-Analyst
• TeamLead und das Team der Entwickler
• Kunde und seine Vertreter (Stakeholder)

Das Ergebnis:

Erfassen von Kundenanforderungen in Form von Notizen, Audioaufnahmen, Mockups und/oder UML-Modellen.

Erfassen von Anforderungen. Dies ist eine der wichtigsten Phasen eines jeden Webprojekts, sei es die Erstellung einer Website von Grund auf, das Design einer Website oder auch nur die Durchführung von Supportaufgaben. Bevor Sie mit dem Sammeln von Anforderungen beginnen, müssen Sie alle interessierten Parteien (Stakeholder) des Kunden oder diejenigen, die die Website nutzen werden, identifizieren. Je genauer diese Liste ist, desto umfassender werden die Anforderungen sein. Einer der Schlüssel zum Erfolg bei der Anforderungserhebung ist eine klare Vorstellung davon, wer wer ist. Es ist wichtig zu wissen, wer auf Kundenseite die Entscheidungen trifft und wer nur bei der Anforderungserhebung hilft und zusätzliche Informationen liefert.

Im PMBOK Guide (Project Management Body of Knowledge) werden 11 Techniken der Anforderungserhebung beschrieben:

1. Interviews
2. Fokusgruppen
3. Moderierte Workshops
4. Kreativitätstechniken in der Gruppe, von denen das Brainstorming die beliebteste ist;
5. Techniken zur Entscheidungsfindung in der Gruppe
6. Fragebögen und Umfragen
7. Beobachtungen
8. Prototypen
9. Benchmarking
10. Kontext-Diagramme
11. Analyse der Dokumente

Wir verwenden hauptsächlich die folgenden Methoden: Fragebögen und Umfragen, Interviews, Dokumentenanalyse, Brainstorming, Prototypen.

Mehr über verschiedene Methoden, die wir verwenden

Fragebögen

Diese Methode erfordert die Ausarbeitung eines Fragebogens (Formulare, Schriftsätze), der offene Fragen (bei denen die Befragten ihre eigenen Antworten formulieren müssen) und geschlossene Fragen (bei denen die Befragten eine Antwort aus einer Liste auswählen müssen) enthalten kann.

Die Umfrage dient dazu, zuvor formulierte Anforderungen zu bestätigen oder zu verfeinern und Optionen für Lösungen auszuwählen.

Das wohl bekannteste Beispiel für eine Umfrage zu diesen Zwecken ist der Webentwicklungsauftrag. Dabei handelt es sich um einen Fragebogen, der eine Liste mit grundlegenden Anforderungen und Informationen über die zukünftige Website enthält.

Interviews

Bei dieser Methode werden die Verhandlungen mit dem Kunden entweder persönlich oder per Telefon oder Skype geführt.

Sie müssen offene Fragen stellen, um Informationen zu erhalten, und geschlossene Fragen stellen, um bestimmte Versionen der Anforderungen zu bestätigen oder zu widerlegen.

Diese Methode wird hauptsächlich verwendet, um Informationen zu einem bestimmten Thema zu erhalten und/oder um bereits bestehende Anforderungen zu verfeinern.

Vor dem Gespräch müssen Sie sich vorbereiten, indem Sie eine Liste mit Fragen erstellen, die es Ihnen ermöglicht, eine erste Analyse der zuvor gesammelten Daten des Kunden durchzuführen. Außerdem müssen Sie das Profil der Kontaktperson auf LinkedIn studieren, falls möglich. Idealerweise sollten alle Gespräche aufgezeichnet werden (mit einem Dienst wie Uberconference). Unabhängig davon, ob das Gespräch aufgezeichnet werden kann oder nicht, sollten Sie dem Kunden anschließend eine kurze Zusammenfassung zukommen lassen. Dies kann in Form einer E-Mail mit einer bestimmten Struktur geschehen. Diese Nachricht muss Folgendes enthalten:

• das Datum und die Uhrzeit des Treffens
• eine Liste der Teilnehmer
• eine Liste von Problemen und Lösungen
• wenn möglich, das Datum und die Uhrzeit des nächsten Treffens

Brainstorming

Brainstorming ist die am häufigsten verwendete Methode, um Anforderungen zu erhalten, die mit neuen oder schlecht verstandenen Bereichen der Organisation des Kunden oder den Funktionen seines Standorts zusammenhängen.

Beim Brainstorming können in kürzester Zeit und praktisch ohne Kosten viele Ideen von verschiedenen Kundenvertretern gesammelt werden.

Bei Brainstorming-Sitzungen schlagen die Teilnehmer einfach alle Ideen vor, die sie zur Lösung eines Problems haben. Das Brainstorming kann mit dem Kunden und seinen Vertretern oder innerhalb eines Teams, das nach Lösungen sucht, durchgeführt werden.

Durch die Kombination von Techniken wird die Anforderungserhebung zu einem effizienten Prozess und verhindert, dass Anforderungen übersehen werden.

Eingabedaten:

Erfassen von Kundenanforderungen in Form von Notizen, Audioaufnahmen, Mockups und/oder UML-Modellen.

Teilnehmer:

• PM
• Entwickler
• Teamleiter/TechLead
• Kunde

Das Ergebnis:

Anforderungsliste (RS).

Bevor er mit der Arbeit beginnt, muss der PM sicherstellen, dass alle Kundenanforderungen nach einer gründlichen Analyse dokumentiert sind. Wir nennen dokumentierte Anforderungen in jeder Form eine RL (Anforderungsliste). Die Dokumentation der Anforderungen erfolgt vor der Schätzung des Projekts.

1. In der Referenzvariante für das Projektmanagement dokumentieren wir Anforderungen und erstellen Anforderungslisten selbst. Oft arbeiten wir jedoch auch mit bereits vorhandenen Anforderungslisten, die vom Kunden zur Verfügung gestellt werden.

Projektprinzipien auf der Grundlage der Anforderungen:

• Wenn die Projektanforderungen klar sind und die meisten Funktionen abdecken (es gibt eine RL oder eine Spezifikation), sollten wir uns an die konsequente Umsetzung dieser Anforderungen halten, um einen vollständigen Plan und Zeitplan zu erstellen. Die richtige Abfolge der Aufgaben spart Entwicklungszeit.
• Wenn die Projektanforderungen unklar sind und viele Lücken aufweisen, sollten wir gut dokumentierte Aufgaben identifizieren, die wir am besten verstehen, und diese in kleinen Portionen und in kurzen Zeitplänen (Phase, Sprint, Batch) bearbeiten. Dabei schließen wir jede Phase mit einer Demonstration für den Kunden ab, um sicherzustellen, dass wir in die richtige Richtung gehen. Um den Rest der Aufgabe zu erledigen, ist es notwendig, weitere Anforderungen zu sammeln und sie auf dem Weg in den Arbeitsprozess zu integrieren und einen neuen Zeitplan für die nächste Phase zu erstellen.
• Wenn die Anforderungen minimal sind oder es sich um ein Unterstützungsprojekt handelt, müssen die Aufgaben nacheinander ausgeführt werden, je nach den Prioritäten des Kunden, falls zutreffend. Eine Zeitplanung ist nicht erforderlich.

Die Selbstdokumentation von Anforderungen erfordert einen besonderen Ansatz, Fähigkeiten, Erfahrung und Zeit. Die Feinheiten der Selbstdokumentation von technischen Anforderungen werden im Folgenden ausführlich dargestellt.

Die in unserem Unternehmen verwendeten Arten der Anforderungsdokumentation sind:

• SRS – Spezifikation der Softwareanforderungen
• Funktionsbeschreibung in beliebiger Form in einem Word-Dokument

Die vorhandene Dokumentation sollte leicht zugänglich sein und bei Bedarf aktualisiert werden. Meistens wird die Dokumentation in einer Word- oder Excel-Datei in einem Google Drive-Ordner gespeichert. Links zu Dokumenten oder Dateien müssen in dem entsprechenden Abschnitt des WIKI-Projekts in Redmine aufgeführt oder angehängt werden.

Lesen Sie unten mehr über die Verwendung der einzelnen Typen.

SRS – Spezifikation der Softwareanforderungen

Die Software-Anforderungsspezifikation wird vor allem für die Dokumentation der Anforderungen großer Projekte verwendet, z.B. für die Erstellung einer Website von Grund auf. Die Grundlagen für die Verwendung dieser Art von Dokumentation sind:

• Führen Sie eine Historie der RL-Versionen. Versionsnummern, Daten und Listen von Änderungen sollten dokumentiert werden. Bei großen Projekten werden sich die Anforderungen ständig ändern und ergänzt werden.
• Fügen Sie ein Inhaltsverzeichnis für eine schnelle und einfache Navigation hinzu. Es ist zu erwarten, dass die Inhaltsabschnitte lang sein werden. Wir können Links zu bestimmten Teilen des Inhalts hinzufügen, um die Navigation auf den RL-Seiten zu erleichtern.
• Die RL sollte von einem TechLead des Projekts oder Teams erstellt werden, der über ausreichende Englischkenntnisse verfügt. Dabei sollte es sich um ein Teammitglied handeln, das mindestens den Rang eines Projektmanagers hat.
• Die RL sollte sowohl für den Kunden als auch für das interne Team verfügbar sein.
• Die Beschreibung der Merkmale sollte ausführlich sein, und die Details sollten klar und sorgfältig beschrieben werden.
• Neben einer textlichen Beschreibung kann die RL durch grafisches Material, wie Screenshots, Diagramme, Tabellen, Mockups oder Design, ergänzt werden.

Merkmale Beschreibung in beliebiger Form in einem Word-Dokument

Diese Art der Anforderungsdokumentation wird am häufigsten für mittlere und kleine Projekte verwendet. Selten wird sie verwendet, wenn eine Website von Grund auf neu erstellt wird; häufiger wird sie für Verbesserungen bestehender Funktionen verwendet. Das Ausgangsmaterial ist eine leere Word-Datei in einem gemeinsamen Google Drive-Ordner, in der die Funktionen des Projekts schrittweise beschrieben werden.

Diese Art von RL wird von dem PM des Projekts erstellt.

Was wird beschrieben:

• das Verhalten der Elemente,
• die Beziehungen zwischen den Entitäten auf den Seiten/der gesamten Website,
• dynamischer visueller Effekt,
• die Eigenschaften eines benutzerdefinierten Schranks oder Eimers,
• Checkout-Arbeiten,
• Benutzerrechte, etc.

Im Vergleich zu SRS ist diese Art der Dokumentation weniger umfangreich und weniger detailliert.

Neben einer textlichen Beschreibung kann eine RL auch durch grafisches Material wie Screenshots, Diagramme, Tabellen, Mockups oder Design ergänzt werden. Eine RL sollte sowohl für den Kunden als auch für das Team verfügbar sein.

Unabhängig davon, ob der Kunde die RL geschickt hat oder wir sie selbst verfasst haben, muss der PM die internen Spezifikationen des Projekts gemäß der akzeptierten Vorlage erstellen . Dieses Dokument wird aktiv in den Arbeitsabläufen der Entwickler und Tester verwendet. Es ist auch möglich, alle genehmigten Änderungen an der RL in diesem Dokument zu dokumentieren.

Diese Dokumentation bezieht sich eher auf die Phase der Entwicklungsplanung und ist einer der Punkte auf der Checkliste des Managers, wenn alle Anforderungen geschätzt und vom Kunden bestätigt wurden und ein Budget und ein Entwicklungsteam festgelegt wurden.

Der PM ist für die Erstellung der internen Projektdokumentationsdatei nach einer Vorlage verantwortlich.

Eingabedaten:

• Die Notwendigkeit, ein Design zu erstellen
• Die Ideen des Kunden
• Mockups oder Wireframes (falls verfügbar)

Teilnehmer:

• Projektleiter
• Designer

Das Ergebnis:

• Mockups oder Wireframes (falls erforderlich)
• Entwurf im PSD-Format

Wenn der Kunde sagt, dass er ein Design braucht:

• Wir sollten klarstellen, dass der Kunde nur PSD-Dateien und keine funktionierende Website erhalten möchte. Wir sollten auch angeben, wer für das Layout und die Funktionalität des fertigen Designs verantwortlich sein wird.
• Wenn der Kunde nur ein Design benötigt, fragen wir nach Beispielen von Websites, die ihm gefallen, und legen ein Farbschema fest.
• Wenn es keine Spezifikation gibt, verlangen wir die Struktur der Website Seite für Seite (Mockups oder Wireframes) und die Beschreibung jeder einzelnen Seite nach Einheiten (d.h. welche Informationen vorhanden sein werden und wo sie platziert werden sollen).
• Unser Designer entwirft die Layouts aller Seiten, um die richtige Platzierung der geplanten Einheiten auf der Website zu koordinieren.
• Wir zeigen dem Kunden das Design, indem wir es ihm Seite für Seite zusenden.

Die Projektschätzung basiert auf den Ergebnissen der Analyse der Kundenanforderungen und allen vom PM gesammelten Dokumenten. An der Schätzung des Projekts ist das Team, bestehend aus dem PM, dem TeamLead und den Entwicklern, aktiv beteiligt.

Die Bewertungsphase des Projekts besteht aus 2 Schritten:

• Ein Angebot erstellen
• Vorbereitung eines kommerziellen Vorschlags (CP)

Während des Schritts Angebotserstellung erstellt der PM eine Aufgabe in Redmine, die durch eine detaillierte Beschreibung und alle vom Kunden erhaltenen Dateien und Informationen zum Projekt oder zur Aufgabe ergänzt wird. Das Entwicklerteam, das an dem Projekt arbeiten wird, studiert diese Informationen zusammen mit dem TeamLead sorgfältig. Bei der Besprechung der Details des Projekts kommen die Entwickler mit Fragen und Vorschlägen zu den Funktionen. Alle wichtigen Teile des Projekts werden in kleinere Teile aufgeteilt und von den Entwicklern geschätzt. Die Entwickler geben oft einen Min-Max-Plug an.

Als Ergebnis der Arbeit des Teams in der Phase Angebotserstellung erhält der Kunde eine XLS-Datei mit der Aufgabenliste und einer Schätzung der Leistung dieser Aufgabe in Stunden. Nachdem der Kunde diese Schätzung erhalten hat, kommuniziert er mit dem PM über die Schätzung und erstellt das Projektbudget, ausgedrückt in Stunden.

Nachdem der Kunde die Schätzung genehmigt hat, hat der PM die Möglichkeit, ein kommerzielles Angebot zu erstellen .

Ein Commercial Proposal (CP) ist ein Dokument, das auf einer Vorlage basiert und eine Beschreibung der Projektbedingungen sowie grundlegende Informationen über das Unternehmen enthält, um dem Kunden die Vorteile einer Zusammenarbeit aufzuzeigen. Ein CP wird auf dem Briefkopf des Unternehmens erstellt und dem Kunden als PDF-Datei zugesandt.

Die wichtigsten Komponenten des CP:

• Ein Projektüberblick. Dies ist eine kurze Beschreibung des Projekts, seiner Zielgruppe und seines Zwecks.
• Die Wahl der Plattform und/oder der technischen Lösungen. Hier wird beschrieben, welches CMS/Framework verwendet wird, welche Programmiersprachen zum Einsatz kommen, welche Komponenten verwendet werden und welche externen Datenbanken in dem Projekt zum Einsatz kommen.
• Eine Beschreibung des Arbeitsumfangs. Der PM beschreibt, welche Leistungen das Unternehmen in welchem Umfang erbringen wird.
• Die Kosten des Projekts und die Zahlungsbedingungen. Wir dokumentieren alle finanziellen Bedingungen der Zusammenarbeit mit dem Kunden: das Zahlungsmodell für das Projekt, die Stundensätze, die Arbeitsstufen und den Preis für die Durchführung jeder Stufe, die Bedingungen für die Gewährung von Rabatten, die Zahlungsbedingungen, die Zahlungsmodalitäten und die Folgen von Verstößen.
• Unterstützung für die Zeit nach dem Start des Projekts. Dies sind die Bedingungen für die Bereitstellung von Support im Falle von Fehlererkennung, Serverproblemen, erweiterten Funktionen usw.
• Abschnitt „Über“. Dies ist eine kurze Beschreibung von WEB4PRO, die unsere Wettbewerbsvorteile beschreibt und nützliche Fakten für den Kunden enthält (Unternehmensabteilungen, verwendete Programmiersprachen, angebotene Dienstleistungen usw.).
• Datum.
• Stempel und Unterschrift des Direktors.

Wenn die Spezifikation fertig ist und der Kostenvoranschlag vom Kunden genehmigt wurde, tritt das Projekt in die Planungs- und Entwicklungsphase ein. Dieser Prozess kann in drei Hauptphasen unterteilt werden:

1. Projektplanung
2. Entwicklung des Projekts
3. Technische Unterstützung

Die an der Planung und Entwicklung des Projekts beteiligten Mitarbeiter sind:

• Projektleiter (PM)
• Designer
• TeamLead und das Team der Entwickler
• Tester
• Kunde
• CTO des Unternehmens

Koordination und Entscheidungsfindung, Anträge auf Zugang zu Dateien und Ordnern sowie organisatorische Fragen werden standardmäßig von den Leitenden Abteilungsmanagern (oder anderen Mitarbeitern des Unternehmens, wenn die Vorschriften dies vorsehen) gelöst.

Lesen Sie unten mehr über die einzelnen Phasen.

Projektplanung

Die Planung ist eine der wichtigsten Phasen der Entwicklung. Im PMBOK heißt es: „Ein Projekt ist erfolgreich, wenn es in Übereinstimmung mit den genehmigten Kriterien Umfang, Zeit und Qualität abgeschlossen wird“, und diese Kriterien werden in der Planungsphase festgelegt.

Bei der Planung werden alle vorbereitenden Arbeiten vor der Entwicklung durchgeführt. Es wird eine Infrastruktur in den Arbeitsumgebungen des Projekts geschaffen, die technische Unterstützung wird überprüft, Teamsitzungen werden durchgeführt. Die Projektplanung wird vom Projektmanager durchgeführt.

Höhepunkte der Planung:

• Der PM sollte sich bei der Projektplanung an der Checkliste orientieren.
• Die Timeline ist das wichtigste Instrument für die Zuweisung von Ressourcen und die Bewertung des Arbeitsumfangs. Darüber hinaus hilft er bei der Überwachung dieser Faktoren.
• Die primäre Umgebung der Projektinfrastruktur ist Redmine und Bitbucket.

Die Kommunikation zwischen den Teammitgliedern findet hauptsächlich über Skype, Slack und E-Mails statt. Die primäre Projektinfrastrukturumgebung – Redmine – ist ein System zur Aufgabenverfolgung. Jeder Mitarbeiter hat Zugriff auf Redmine, das sowohl in einer Produktionsumgebung als auch von jedem Computer außerhalb des Büros zugänglich ist. Das Redmine-System ist sehr vielseitig und flexibel, was die Einstellungen angeht. Die wichtigsten Aspekte der Nutzung für den Manager sind in den Regeln für die Arbeit mit Redmine beschrieben.

Möglichkeiten innerhalb von Redmine während des Projektmanagements:

• Aufgaben erstellen und deren Ausführung überwachen
• Projektrisiken bewerten
• berechnen Sie die Projekteffizienz
• wichtige und notwendige Informationen an einem Ort aufbewahren – das Projekt-WIKI
• externe Benutzer mit dem Projekt verbinden

Redmine ist ein sehr effektives Werkzeug für PMs.

Entwicklung des Projekts

Die Projektentwicklung ist der wichtigste und entscheidendste Teil des Projekts. Dies ist aus vielen Gründen eine grundlegende, langfristige und kritische Phase im Lebenszyklus des Projekts. Die Ressourcenplanung und der Zeitplan werden in dieser Phase in der Regel validiert, und der Kunde sieht greifbare Ergebnisse und die Umsetzung seiner Ideen. Es können auch kritische Ereignisse höherer Gewalt eintreten. In dieser Phase werden die Schätzungen überprüft und die Teams untersucht.

Die Hauptaufgabe des PM in dieser Phase besteht darin, das Team, den Zeitplan, die Ressourcen, die Qualität, die Kosten und das Feedback des Kunden zu überwachen.

Die Entwicklung beginnt immer mit einer Teambesprechung, bei der das Team die Feinheiten des RL bespricht, die Aufgabenschätzungen bestätigt und gemeinsam die technischen Lösungen und die Architektur festlegt. Die Teilnehmer vereinbaren auch die Häufigkeit der zukünftigen Treffen.

In der Regel beginnt die Ausführung der Aufgaben nach der Durchführung dieser Sitzung. Der PM ist für die Arbeit rund um die Aufgaben und Phasen verantwortlich .

Eine Aufgabe ist das kleinste Element der Funktionalität des Projekts. Aufgaben können entweder zusammenhängend oder nicht zusammenhängend sein. Eine Phase ist eine Reihe von Aufgaben, die logisch und funktional miteinander verbunden sind und deren Ausführung an einen bestimmten Termin gebunden ist. Normalerweise zeigen wir dem Kunden das Ergebnis der Phasenausführung als Zwischenergebnis des Projekts. Der PM überwacht täglich die Bereitschaft der Aufgaben gemäß der Timeline, und somit wird auch die Bereitschaft der Phasen überwacht.

Abgeschlossene Aufgaben und Phasen werden obligatorischen Tests unterzogen, bevor sie dem Kunden vorgelegt werden. Für das Testen wird ein spezieller Mitarbeiter ernannt – der Software-Tester (QA). Der Tester interagiert mit dem Projekt gemäß den offiziellen Anweisungen.

Wenn wir an einem Projekt mit einem Festpreismodell arbeiten, ist es wichtig, sich an die vom Kunden genehmigten RL zu halten, um Probleme zu vermeiden, die zu Änderungen der Bedingungen und Zahlungen führen würden. Wenn der Kunde eine zusätzliche Aufgabe stellt, wäre es ideal, diese in eine separate Phase zu verschieben und nach der Erfüllung der vorgegebenen Ziele abzuschließen. Manchmal gibt es jedoch Ausnahmen.

Bevor die Arbeit an der zweiten Hälfte der Endphase des Projekts abgeschlossen wird, muss der PM verschiedene Aufgaben erledigen. So muss der PM das aktuelle Projekt, die Geschichte des Kunden, seine aktuellen Bedürfnisse und seine potenziellen zukünftigen Bedürfnisse analysieren. Außerdem muss der PM Verbesserungen für das Projekt vorschlagen.

Die Designphase gilt als abgeschlossen, wenn alle Aufgaben aus dem RL innerhalb der vereinbarten Kundenfristen ordnungsgemäß ausgeführt und vom Kunden bestätigt und bezahlt wurden. Danach kann das Projekt auf dem Live-Server des Kunden bereitgestellt werden.

Obligatorische Aufgaben des PM nach Projektabschluss sind:

1. Analyse nach der Fertigstellung, um eine Retrospektive durchzuführen
2. Um das Projekt dem internen Portfolio des Unternehmens hinzuzufügen

Technische Unterstützung

Der technische Support (tech support) ist eine Reihe von Diensten, die der Wartung, Aktualisierung und Verbesserung der Website dienen.

Die technische Unterstützung in unserem Unternehmen kann sowohl für interne Kunden, für die wir eine Website von Grund auf erstellt haben, als auch für externe Kunden, die mit fertigen Websites zu uns kommen, geleistet werden.

Der technische Support umfasst Folgendes:

• Technisches Audit der Website
• Aktualisierungen der Website
• Unterstützung der Website-Funktionalität
• Interaktion mit dem Hosting-Anbieter

Eingabedaten:

Eine Liste von Aufgaben, die vor Beginn des Projekts durchgeführt werden müssen

Teilnehmer:

• Projektleiter
• TeamLead und das Team des Projekts

Das Ergebnis:

Dokumentierter Nachweis, dass alle Bedingungen für einen erfolgreichen Projektstart erfüllt sind.

Projektprinzipien auf der Grundlage der Anforderungen:

• Wenn die Projektanforderungen klar sind und die meisten Funktionen abdecken (d.h. es gibt eine RL oder eine Spezifikation), sollten wir uns an die konsequente Umsetzung dieser Anforderungen halten, um einen vollständigen Plan und Zeitplan zu erstellen. Die richtige Abfolge der Aufgaben spart Zeit in der Entwicklungsphase.
• Wenn die Projektanforderungen unklar sind und es viele Lücken gibt, sollten wir gut dokumentierte Aufgaben identifizieren, die wir am besten verstehen, und mit ihnen in kleinen Portionen und in kurzen Zeitplänen (Phase, Sprint, Batch) arbeiten, wobei wir jede Phase mit einer Demonstration für den Kunden abschließen, um sicherzustellen, dass wir in die richtige Richtung gehen. Um den Rest der Aufgabe zu erledigen, ist es notwendig, weitere Anforderungen zu sammeln und sie auf dem Weg in den Arbeitsprozess zu integrieren und einen neuen Zeitplan für die nächste Phase zu erstellen.
• Wenn die Anforderungen minimal sind oder es sich um ein Unterstützungsprojekt handelt, müssen die Aufgaben nacheinander ausgeführt werden, je nach den Prioritäten des Kunden, falls zutreffend. Eine Zeitplanung ist nicht erforderlich.

Checkliste für die Projektplanung

1. Einigen Sie sich auf das endgültige Entwicklerteam und die Teamleiter, indem Sie die Team-Upload-Datei verwenden.
2. Erstellen Sie einen detaillierten Projektplan (Timeline), der die Arbeit in Aufgaben für jeden Projektteilnehmer unterteilt und die Ergebnisse termingerecht liefert.
3. Nachdem die TeamLeads und der Kunde den Projektplan genehmigt haben, füllen der PM und die TeamLeads die Upload-Datei aus.
4. Erstellen und füllen Sie die interne Dokumentationsdatei aus. Dies ist wichtig für große Projekte (z.B. solche, die mehr als 100 Stunden dauern), an denen mehrere Abteilungen beteiligt sind.
5. Legen Sie ein Projekt in Redmine an und übertragen Sie die Aufgabe mit dem Zitat aus dem Projekt Quotes in das neue Projekt.
6. Verbinden Sie das Team aus Entwicklern, Lead Manager und Tester mit einem Projekt in Redmine.
7. Weisen Sie den Personen die entsprechenden Rollen zu.
8. Vervollständigen Sie die Projektübersicht und fügen Sie ggf. eine Beschreibung des Projekts und Kundendaten hinzu. Wenn zum Beispiel mehrere Kunden mit dem Projekt verbunden sind, müssen Sie angeben, wofür jeder einzelne verantwortlich ist.
9. Füllen Sie die WIKI-Seite entsprechend dem Standard aus.
10. Fügen Sie die Version in den Projekteinstellungen hinzu. Der Versionsname hängt von den Projektspezifika ab.
11. Fügen Sie in den Projekteinstellungen Kategorien hinzu (falls erforderlich). Der Name der Kategorie hängt von den Projektspezifika ab.
12. Fügen Sie den Client hinzu, falls erforderlich.
13. Erstellen Sie ein Repository auf Bitbucket, um den Personen die erforderlichen Zugriffsrechte zu gewähren. Sie müssen den beteiligten TeamLeads Admin-Rechte gewähren.
14. Fügen Sie dem Projekt Aufgaben hinzu. Die Voraussetzungen für die Erstellung von Aufgaben werden in einem separaten Abschnitt beschrieben.

Eingabedaten:

• Vorbereitung einer Projektschätzung, die vom Kunden genehmigt wurde
• Anforderungen und/oder Wünsche des Kunden bezüglich der Bedingungen
• Ein ernanntes Projektteam

Teilnehmer:

Projektleiter

Das Ergebnis:

Fertiggestellte Timeline mit Fristen und einem Arbeitsplan für jedes Teammitglied. Festgelegte Projektkontrollpunkte.

Eine Zeitleiste ist eine Möglichkeit, eine Liste von Projektereignissen in chronologischer Reihenfolge darzustellen, manchmal auch als Projektartefakt bezeichnet. Es handelt sich dabei in der Regel um ein grafisches Design mit einem langen Balken, der die Zeit darstellt und auf dem Daten und Ereignisse beschriftet sind. (c) Wikipedia.

Bei der Planung des Projekts erstellt der PM einen detaillierten Projektplan (oder Zeitplan), der die Aufteilung der Arbeit in Aufgaben für jeden Projektbeteiligten und die Verteilung dieser Aufgaben nach einem Zeitplan enthält. PMs können Timelines sowohl für laufende Projekte mit Meilensteinen als auch für Projekte, die sich noch in der Angebotsphase befinden, erstellen. In der Regel ist es notwendig, dass der Kunde die Projektfrist kennt, bevor er einer Zusammenarbeit mit uns zustimmt.

Der Arbeitsplan, unterteilt in Aufgaben und Zeitspannen, muss von TeamLeads bestätigt werden, und die endgültigen Bedingungen müssen vom Kunden bestätigt werden.

Besonderheiten bei der Erstellung der Timeline:

• Die empfohlene Zeitspanne für eine Aufgabe beträgt nicht mehr als 8 Stunden, so dass es einfacher ist, den Ausführungsprozess zu kontrollieren. Es gibt einige Aufgaben, die sich nur schwer in kleinere Teile aufteilen lassen, und diese erfordern eine sorgfältigere und kontrollierte Ausführung.
• Das maximale Arbeitspensum des Entwicklers für das Hauptprojekt beträgt sechs Stunden pro Tag. Die restlichen zwei Stunden sind für Feedback zu anderen Projekten oder Aufgaben, Angebote, höhere Gewalt und andere unvorhergesehene Umstände vorgesehen.
• Bei großen Projekten (über 40 Stunden) werden die Aufgaben in Phasen oder Meilensteine unterteilt. Es kann viele Faktoren geben, die die Dauer einer Phase beeinflussen, z. B. die Anforderungen des Kunden, die Besonderheiten des Projekts, der Gesamtumfang der Arbeit, die Arbeitsbelastung der Entwickler usw. Daher kann die Dauer der Phasen für jedes Projekt unterschiedlich sein. Jede Phase sollte nicht länger als 3-4 Wochen dauern.
• Die für den Manager und den Kunden festgelegten Projektkontrollpunkte (CP) sind Zwischentermine, die es Ihnen ermöglichen, den Prozentsatz der ausgeführten Arbeiten zu überprüfen und auf Abweichungen vom Plan aufmerksam zu werden.

PM-Prüfpunkte sind auf der Zeitachse gelb markiert. Wenn weniger als 80% der Aufgaben von den Entwicklern erledigt wurden, sollte die Farbe des CP auf rot geändert werden. Wenn 80 % oder mehr der Aufgaben erledigt sind, sollte der CP auf grün geändert werden. Zwei rote CPs sind ein schlechtes Zeichen. Es bedeutet, dass das Projekt mit hoher Wahrscheinlichkeit scheitern wird und dringende Maßnahmen erforderlich sind, um es zu retten.

Wenn es um Kostenvoranschlag und Zeitplan geht, müssen Sie für die erfolgreiche Durchführung des Projekts genau wissen, in welcher Phase und in welchem Zustand sich das Projekt zu einem bestimmten Zeitpunkt befindet. Eine der Hauptaufgaben des PM ist die rechtzeitige Aktualisierung der Timeline.

Die Timeline muss auch für das Entwicklerteam, das an dem Projekt arbeitet, und für den Kunden verfügbar sein. Je nach den Besonderheiten des Projekts und seiner Schätzung kann die Timeline sowohl in einer gemeinsamen Datei als auch in separaten Dateien für die Entwickler und den Kunden erstellt werden.

Eingabedaten:

• Projekt RL
• Geordnete Projektinfrastruktur in Redmine
• Zeitplan des Projekts
• Design (falls zutreffend)

Teilnehmer:

• Projektleiter
• Teamleiter von Abteilungen und Entwicklern
• Tester

Das Ergebnis:

• Etablierte Kontakte im Projektteam (jeder im Team weiß, wer für was zuständig ist);
• Eine Liste der möglichen Risiken;
• Varianten von Aktionen im Falle von Hindernissen;
• Gut durchdachte technische Lösungen;
• Antworten auf die Fragen, die Sie benötigen, um mit der Arbeit an dem Projekt zu beginnen.

Bevor Sie mit dem Projekt beginnen, müssen Sie ein Treffen mit allen Projektbeteiligten abhalten. Ziele des Treffens:

• sich mit dem Team vertraut zu machen (dies ist besonders wichtig bei großen Projekten)
• diskutieren Sie die Nuancen des RL
• Fragen stellen und Antworten erhalten
• gemeinsam technische Lösungen und Architekturen definieren
• sich auf die Häufigkeit der Treffen zu einigen

Der Organisator des Treffens ist der Premierminister.

Die Teilnehmer sind die Entwickler, Teamleiter von Teams, PM und Tester.

Die Organisation kann über Google Calendar erfolgen.

Vor dem Treffen müssen die RL und das Design an alle versandt werden und es muss sichergestellt werden, dass jeder sie vor dem Treffen durchgesehen hat. Bei dem Treffen müssen Sie auch mehrere Kopien der gedruckten RL und, falls wir mit einem Entwurf arbeiten, gedruckte Entwurfsseiten dabei haben.

Bei großen Projekten (mehr als 100 Stunden) müssen Besprechungen in regelmäßigen Abständen stattfinden. Daher müssen Sie bei der ersten Sitzung festlegen, wie oft Sie sich treffen wollen und den Termin für die nächste Sitzung vereinbaren.

Wie üblich muss nach dem Treffen die endgültige Liste der besprochenen Themen und Lösungen an alle Teilnehmer verschickt werden.

Im Folgenden finden Sie eine Liste der wichtigsten Themen, die bei dem Treffen besprochen werden sollten. Diese Liste ist nicht abschließend und kann je nach Projekt und Situation noch erweitert werden.

• Wurden den Entwicklern vollständige und ausreichende Informationen über den Sprint oder die Aufgabe zur Verfügung gestellt?
• Was sind die Fragen des Teams zu den Aufgaben im aktuellen Sprint?
• Wie ist der Status aller Aufgaben zum Zeitpunkt des Meetings? Jeder Teilnehmer bringt das gesamte Team kurz auf den neuesten Stand, damit jeder weiß, was im Projekt vor sich geht.
• Gibt es Schwierigkeiten, die das Team daran hindern würden, die Aufgaben innerhalb der vorgeschriebenen Frist zu erfüllen, und wenn ja, welche Lösungen sollten umgesetzt werden?
• Welche allgemeinen Kommentare oder Beobachtungen hat das Team zum aktuellen Fortschritt oder Status des Projekts?

Eingabedaten:

• Das Projekt, das sich in einer aktiven Entwicklungsphase befindet
• Zeitplan des Projekts

Teilnehmer:

• Projektleiter
• Kunde
• TeamLeads und Entwickler des Projekts

Das Ergebnis:

• Keine Verzögerungen bei der Projektfertigstellung
• Verringerung des Risikos der Überschreitung von Quoten
• Minimale Verluste bei Überschreitung der Quoten
• Gute Kommunikation zwischen den Projektteilnehmern

Der PM beginnt seinen Tag, indem er seine E-Mails prüft und jedes Projekt nach offenen Aufgaben in Redmine durchsucht. Sie sollten prüfen:

• Status. Sie sollten vor allem auf Aufgaben mit dem Status „Anfrage“ achten. Wenn der Manager eine Aufgabe mit dem Status „Anfrage“ entdeckt, sollte er den Kunden benachrichtigen oder, falls der Kunde an dem Projekt beteiligt ist, ihn an die Probleme erinnern und ihm Links zu der Aufgabe schicken. Wenn der Kunde die Aufgaben nicht aktualisiert und den Status der Aufgaben nicht geändert hat, ändert der Manager den Status nach der Überprüfung in „Feedback“.
  • Wenn eine Aufgabe mit dem Status „Feedback“ länger als 1-2 Tage nicht mehr aktualisiert wurde, überprüfen wir die Frist der Aufgabe und erinnern den Entwickler erneut daran, entweder durch Aktualisierung der Aufgabe, durch Senden einer E-Mail oder durch Senden einer Skype-Nachricht.
  • Wenn eine Aufgabe mit dem Status „Neu“ seit mehr als 2-3 Tagen nicht mehr aktualisiert wurde, prüfen wir zunächst das Fälligkeitsdatum der Aufgabe. Die weiteren Aktionen hängen vom Fälligkeitsdatum ab.
  • Wenn eine Aufgabe mit dem Status „An den Kunden gesendet“ seit mehr als 2-3 Tagen nicht aktualisiert wurde, erinnern wir den Kunden daran.
• Aufgaben, deren Fälligkeitsdatum für den aktuellen Tag oder die nächsten Tage festgelegt ist.
• Zeitplan des Projekts. Es ist notwendig, die Relevanz der vor Ort durchgeführten Aufgaben, die vom Kunden bestätigt wurden, zu vermerken. Kontrollpunkte sollten überwacht und im Plan vermerkt werden. Ergreifen Sie je nach den Ergebnissen der Überwachung bestimmte Maßnahmen (wenden Sie sich an den TeamLead oder Entwickler, überprüfen Sie die Aufgabe usw.)
• Zeitaufwand für Aufgaben. Der Entwickler notiert in Redmine, wie viel Zeit er aufgewendet hat und welcher Prozentsatz der Aufgabe bereits umgesetzt wurde, und zwar jeden Tag. Die gesamte aufgewendete Zeit sollte in Tasks vermerkt werden.

Überwachung der Bereitschaft der Phasen

Einige Tage vor Abschluss einer Phase überprüft der PM die Aufgaben innerhalb der Phase und stellt sicher, dass alles nach Plan verläuft. Er muss auch sicherstellen, dass die Aufgabe für das Testen erstellt wurde und die Zeit des Testers eingeplant und in der Upload-Datei vermerkt ist. Die Tests und Fehlerbehebungen müssen vor Ablauf der Frist der Phase abgeschlossen sein.

Der Projekt-PM informiert den Kunden am Phasentermin oder früher über die Bereitschaft der Phase und bittet den Kunden, den Status der gemeldeten Probleme zu überprüfen und eventuell noch offene Fragen dazu zu stellen.

Techniken zur Überwachung

Einmal am Tag geht der PM zu den Entwicklern, um sich über den Fortschritt der Aufgaben zu informieren und zu fragen, ob es Probleme oder Fragen gibt. Wenn es Probleme oder Fragen gibt, benachrichtigt der PM den TeamLead und bittet ihn, sich zu melden und bei Bedarf zu helfen. Bei langwierigen Projekten wird an festgelegten Kontrollpunkten eine zusätzliche Überwachung durchgeführt (Häufigkeit – etwa einmal pro Woche).

Der Tester muss bereits in der Planungsphase der Entwicklung in den Arbeitsprozess eingebunden werden, um sicherzustellen, dass das Testen Teil des Entwicklungsprozesses ist und nicht als einer der letzten Schritte des Projekts belassen wird. Tester werden in drei Phasen in den Arbeitsprozess eingebunden:

Phase 1: Vorbereitungsphase (nach Erhalt eines Projekts).

Der Tester muss vor Beginn des Tests mit der Aufgabe Angebot verknüpft werden. Der Tester prüft die Informationen über das Projekt aus dem Angebot und wendet sich an den PM, wenn es Fragen gibt.

Checkliste für den Vorbereitungsprozess:

• Themenbereich (zum Beispiel Online-Shop für Bücher).
• Zielgruppe (das Land, für das die Website entwickelt wird, Durchschnittsalter der potenziellen Nutzer).
• Die Konkurrenz (falls es solche Informationen gibt).
• In dieser Phase muss der PM gefragt werden, wann der Tester in das Projekt einbezogen werden kann. Außerdem muss der Tester eine Liste mit Fragen vorbereiten, die bei der Besprechung mit dem Team besprochen werden sollen.

Es ist wichtig, dass die Vorbereitungsphase nicht mehr als 5 % der gesamten für die Tests vorgesehenen Zeit in Anspruch nimmt.

Phase 2: Erstellung der Aufgabe zum Testen (nach Abschluss einer oder mehrerer Projektaufgaben)

Notwendige Informationen für Tester in der WIKI des Projekts:

• Links zur Dokumentation mit Spezifikationen (oder anderen Projektunterlagen);
• Passwörter und Zugriffsregeln für alle Konten, die für die Tests benötigt werden (die Standardliste der Zugriffe sowie ggf. zusätzliche Zugriffe auf externe Ressourcen, die für die Tests benötigt werden);
• Entwurfsdokumentation (eine Beschreibung aller Änderungen am Entwurf);
• Das Entwicklungsstadium des Projekts und das geplante Veröffentlichungsdatum;
• Ein Link zu der internen Dokumentation, die der PM während der Entwicklung des Projekts verfasst.

PM-Checkliste für den Entwurf einer Aufgabe zum Testen:

• Beschreiben Sie die Aufgabe und geben Sie an, welcher Teil des Projekts getestet werden muss. Fügen Sie die Aufgabe des Entwicklers als verwandtes Problem hinzu.
• Geschätzte Zeit, die für die Tests in dieser Aufgabe vorgesehen ist.
• Fehlerpriorisierung, wobei Sie notieren, welche Fehler zuerst behoben werden müssen. Wenn z.B. die Schnittstelle in diesem Stadium für den Kunden nicht sehr wichtig ist, weisen Sie den Funktionsfehlern eine hohe Priorität zu und allen anderen Fehlern eine normale Priorität.
• Die Arten von Tests, die für das Projekt durchgeführt werden müssen (Funktionstests, Schnittstellentests, Lokalisierung, Benutzerfreundlichkeit, Kompatibilität, Integrationstests).

Funktionstests zielen darauf ab, die Durchführbarkeit der funktionalen Anforderungen zu prüfen. Mit anderen Worten: Der Tester muss prüfen, ob die entwickelte Software in der Lage ist, die Aufgaben zu erfüllen, für die sie geschaffen wurde. Der Tester muss auch prüfen, ob die Software die Bedürfnisse des Kunden oder Benutzers erfüllt. Jedes Projekt hat seine eigenen funktionalen Tests, da die Spezifikationen eines jeden Projekts einzigartig sind. Diese Art von Tests ist obligatorisch und sollte auf alle Aufgaben angewendet werden (mit der möglichen Ausnahme von Aufgaben zum Testen von Schnittstellen).

Usability-Tests sind eine Testmethode, die darauf abzielt, die Benutzerfreundlichkeit, die Verständlichkeit und die Attraktivität des entwickelten Projekts für die Benutzer festzustellen. Bei neuen Projekten sollte diese Art von Tests standardmäßig durchgeführt werden (denn die Benutzerfreundlichkeit ist ein wesentlicher Bestandteil der Qualität). Für Projekte, die Aktualisierungen fertiger Websites beinhalten, können wir nur Usability-Tests anbieten.

Das Testen der Lokalisierung ist der Prozess des Testens der lokalisierten Versionen der Website. Dazu gehören die Festlegung der Liste der unterstützten Sprachen, die Überprüfung der Korrektheit der Übersetzung entsprechend dem Thema der Website, die Überprüfung der Korrektheit der Übersetzung der Elemente der Benutzeroberfläche, die Überprüfung der Übersetzung von Systemmeldungen und Fehlern sowie die Überprüfung des Hilfebereichs und der Support-Dokumentation.

Bei Kompatibilitätstests wird geprüft, ob das Produkt in bestimmten Umgebungen (den vom Kunden gewünschten Geräte- und Betriebssystemversionen) korrekt funktioniert.

Schnittstellentests sind Tests, die darauf abzielen, die Konformität der implementierten Website-Schnittstelle und des Layouts, die vom Kunden bereitgestellt wurden, zu überprüfen. Es ist zwingend erforderlich, mit dem Kunden abzustimmen, ob das Projekt pixelgenau sein muss oder nicht.

Integrationstests sind die Tests eines Systems, das aus zwei oder mehr Modulen besteht. Das Hauptziel von Integrationstests ist die Aufdeckung von Fehlern bei der Implementierung der Schnittstelleninteraktion zwischen den Modulen.

Der zweite Schritt besteht darin, mit dem PM die Zeit zu besprechen, die für die Erstellung des Testplans und der Testfälle oder Checklisten benötigt wird.

Phase 3: Diskussion mit den Entwicklern (nach Abschluss einer oder mehrerer Projektaufgaben, kurz vor Beginn der Tests)

Wenn es aus technischen oder sprachlichen Gründen schwierig ist, mit den Entwicklern zu kommunizieren, werden diese Fragen vom PM beantwortet.

Checkliste mit Fragen an den Entwickler:

• Welche Komponenten sind vollständig fertig, welche nicht, und welche müssen weiterentwickelt werden? In den meisten Fällen macht es keinen Sinn, Komponenten zu testen, die noch nicht fertig sind und noch weiterentwickelt oder neu entwickelt werden müssen. Sie erfordern nicht viel Aufmerksamkeit, aber der Tester sollte sich ihrer bewusst sein.
• Werden die Platzhalter verwendet? Bereiche, in denen Platzhalter verwendet werden, sollten beim Testen berücksichtigt werden. Andernfalls wird Zeit mit Fragen und Fehlern im Zusammenhang mit nicht funktionierenden Schaltflächen verbracht, und es werden nicht implementierte Funktionen aus den Spezifikationen diskutiert.
• Welche Fehler sind derzeit bekannt, und sind sie im Bug-Tracking-System erfasst? Oftmals sind den Entwicklern, die an dem Projekt arbeiten, eine bestimmte Anzahl von Fehlern bekannt. Unser Team sollte auf jeden Fall alle bekannten Fehler im Bug-Tracking-System erfassen.

Am Ende der dritten Stufe beginnt die QA mit dem Testprozess.

Eingabedaten:

• Projekt RL
• Zeitplan des Projekts
• Die neuen Aufgaben des Kunden, die nicht in der RL enthalten sind

Teilnehmer:

• Projektleiter
• Kunde
• TeamLeads und Entwickler des Projekts

Das Ergebnis:

• Keine chaotischen Situationen
• Ein ruhiger und entspannter Kunde
• Die Fähigkeit, die Arbeitsbelastung des Teams so schnell wie möglich zu erhöhen

Wenn der Kunde während der Arbeit am Projekt zusätzliche Aufgaben stellt, wäre es ideal, diese in eine separate Phase zu verschieben und erst nach Erreichen der vorgegebenen Ziele auszuführen.

Der PM schätzt zunächst ein, wie kritisch die Durchführung der zusätzlichen Aufgaben im Rahmen der aktuellen Phase ist. Wenn es kritisch ist und die Aufgaben schätzungsweise nicht mehr als 1-2 Stunden in Anspruch nehmen, können sie zur Umsetzung der aktuellen Phase hinzugefügt werden. Es ist unwahrscheinlich, dass die Deadline der Phase verletzt wird, aber Sie müssen dies mit dem Entwickler und/oder TeamLead überprüfen und bestätigen. Wenn die neuen Aufgaben kritisch sind und die Schätzung zeigt, dass sie sich auf die endgültige Frist der Phase auswirken werden, dann:

1. Sie müssen den Kunden darüber informieren und ihn bitten, die Verschiebung zu bestätigen.
2. Nach der Bestätigung müssen Sie Anpassungen am Plan vornehmen und Aufgaben in Redmine erstellen.
3. Wenn es für den Kunden sehr wichtig ist, die neue Aufgabe auszuführen, und er das Phasendatum nicht verschieben möchte, sollten Sie die Möglichkeit in Betracht ziehen, eine oder mehrere Aufgaben mit der gleichen Anzahl von Arbeitsstunden wie die neue Aufgabe aus der Phase zu entfernen.

Denken Sie daran, dass sich der Endtermin des gesamten Projekts verschiebt, wenn wir eine neue Aufgabe in der Mitte der Phase oder des Projekts einfügen.

Die Schätzung neuer Aufgaben erfolgt durch den PM, der:

1. Erzeugt eine Aufgabe für ein Angebot im aktuellen Projekt oder Unterprojekt
2. Kommuniziert Fragen und Antworten zwischen dem Kunden und dem Programmierer
3. Vereinbart die Fristen und ändert die Timeline bei Bedarf
4. Übermittlung der endgültigen Informationen an den Kunden (Kostenvoranschlag, Laufzeit, Kosten)
5. Nach der Bestätigung des Projekts planen Sie es gemäß den festgelegten Prozessen

Eingabedaten:

• Projekt RL
• Zeitplan des Projekts

Teilnehmer:

• Projektleiter
• Kunde
• TeamLeads und Entwickler des Projekts

Das Ergebnis:

• Die Möglichkeit, das Arbeitspensum des Teams in Zukunft zu erhöhen
• Das Vertrauen und der Respekt des wachsenden Kunden

Bevor die Arbeit an der zweiten Hälfte der Endphase des Projekts abgeschlossen wird, muss der PM verschiedene Aufgaben erledigen. Der PM muss nämlich das aktuelle Projekt, die Geschichte des Kunden, seine aktuellen Bedürfnisse und seine potenziellen zukünftigen Bedürfnisse analysieren. Außerdem muss der PM Verbesserungen für das Projekt vorschlagen (z. B. eine mobile Version, optimiertes Laden der Seite, eine neue Zahlungsmethode usw.).

Diese Analyse wird durchgeführt, um die zusätzlichen Bedürfnisse des Kunden herauszufinden, die während der Arbeit an dem Projekt entstanden sind. Entwickler und Teamleiter können an der Analyse beteiligt werden. Dies muss im Voraus geschehen (vorzugsweise 2-3 Wochen vor dem Ende des Projekts), da eine gewisse Zeit für Schätzungen, Fragen, die Genehmigung des Budgets und das Schreiben der RL aufgewendet wird.

Eingabedaten:

• Abgeschlossenes und getestetes Projekt
• Kundenbestätigung der Überweisung
• Zugriff auf den Server des Kunden

Teilnehmer:

• Projektleiter
• Kunde
• TeamLeads und Entwickler des Projekts

Das Ergebnis:

Eine funktionierende Website auf einem Live-Client-Server.

Nachdem alle Arbeiten am Projekt abgeschlossen sind, übertragen wir die Änderungen auf den Live-Client-Server. In der Kalkulationsdatei wird diese Aktion als „Bereitstellung auf dem Produktionsserver“ bezeichnet. Um das Projekt bereitzustellen, erstellt der PM eine Aufgabe für einen Entwickler, die den Zugriff auf den Live-Server, eine Beschreibung der Aufgabe und ggf. die Feinheiten der Übertragung (Zeitlimit für Clients aus anderen Zeitzonen, die Bedingungen für die Datenbankübertragung usw.) und den Domänennamen (sofern vorhanden) enthält.

Das Ergebnis wird einen Link zur Website des Kunden enthalten. Außerdem müssen die Entwickler nach der Übertragung die internen Links, die Verfügbarkeit von Bildern, Logos, Favicons und das Verhalten der mobilen Website überprüfen.

Die folgenden Schritte müssen vor der Bereitstellung des Projekts durchgeführt werden:

1. Beantragung des Zugriffs auf den Live-Server des Kunden und Überprüfung der Kompatibilität mit den Funktionen der Website im Voraus (PHP-Version, erforderliche APIs). Um dies zu erreichen, erstellt der PM eine Aufgabe in Redmine für den Entwickler des Teams.
2. Vollständige Prüfung des Projekts, um sicherzustellen, dass das fertige Werk den Spezifikationen entspricht und die Probleme des Kunden löst. Der Kunde muss bestätigen, dass er mit den Ergebnissen zufrieden ist.
3. Erstellung eines Handbuchs für die Verwaltung neuer Funktionen über das Admin-Panel. Wenn das Projekt in Phasen unterteilt ist, erstellen wir normalerweise für jede Phase ein Benutzerhandbuch. Vor der Projektübergabe müssen wir sicherstellen, dass die Anleitung für alle zuvor abgeschlossenen Phasen noch relevant ist. Wenn es vorher keine Anleitungen gab, müssen sie von Grund auf neu erstellt werden.

Eingabedaten:

• Das abgeschlossene und vom Kunden genehmigte Projekt
• Statistik über verbrachte Stunden
• Schätzung des Projekts

Teilnehmer:

• Projektleiter
• Kunde
• TeamLeads und Entwickler des Projekts

Das Ergebnis:

• Google Doc mit gesammelten Rückmeldungen
• Schlussfolgerung nach der Analyse
• Eine Liste von Anpassungen und Verbesserungen für zukünftige Projekte

Nachdem ein Projekt abgeschlossen ist, muss es immer analysiert werden.

Der Zweck der Projektanalyse besteht darin, die Stärken und Schwächen eines Projekts zu ermitteln. Sie bewertet auch die wirtschaftliche Effizienz des Projekts für das Unternehmen und ermöglicht es, auf der Grundlage der gewonnenen Daten Anpassungen in den laufenden Prozessen vorzunehmen und so die Ergebnisse für zukünftige Projekte zu verbessern.

Etappen der Analyse:

Sammeln Sie das Feedback aller Projektteilnehmer. Dazu müssen Sie jedem Teilnehmer eine Liste mit Fragen zu den Vor- und Nachteilen des Projekts zukommen lassen.

Einholen von Feedback vom Kunden. Diese Fragen sind fast identisch mit denen, die den Projektteilnehmern auf unserer Seite gestellt werden. Kundenfeedback ist für uns sehr wichtig, denn die negativen Kommentare der Kunden helfen uns, uns zu verbessern. Fügen Sie alle Rückmeldungen zu einem Google Doc hinzu und teilen Sie sie mit dem Direktor und dem Senior Manager, falls zutreffend. Analysieren Sie das Feedback, ziehen Sie Schlussfolgerungen und nehmen Sie bei Bedarf Änderungen an den Arbeitsabläufen vor.

Schreiben Sie einen Brief mit diesen Schlussfolgerungen an alle Projektteilnehmer und kopieren Sie ihn an den Unternehmensdirektor und den leitenden Manager. Ein Beispiel für einen solchen Brief finden Sie in der Rubrik Links.

Bevor Sie mit dem nächsten Projekt beginnen, besprechen Sie in einer Besprechung die Probleme des vorherigen Projekts, falls es welche gab, und erklären Sie, was getan wurde, um sie zu beseitigen. Wenn es keine Probleme gab, geben Sie einfach an, welche Innovationen sich nach der Analyse des Projekts ergeben haben.

Diese Analyse muss für alle Projekte durchgeführt werden, auch für die, die der PM persönlich für erfolgreich hält, und selbst für kleine Projekte zwischen 20 und 40 Stunden. Die Erfahrung zeigt, dass der PM vielleicht nicht einmal einige kleine Punkte bemerkt, die den Entwicklern aufgrund ihrer unterschiedlichen Rollen auffallen. Wenn während des Projekts nichts Schlimmes passiert ist, können wir es beim nächsten Mal noch besser machen.

Eingabedaten:

• Arbeitsort
• Das Vorhandensein von Aufgaben zur Funktionserhaltung
• Bugs oder Probleme auf der Website

Teilnehmer:

• Projektleiter
• Kunde
• TeamLeads und Entwickler des Projekts
• Tester

Das Ergebnis:

• Funktionierende Website ohne Bugs oder Probleme
• Das Budget des Kunden wird wie geplant verwendet
• Das Arbeitspensum des Entwicklers wird wie geplant ausgeführt

Website-Support (technischer Support) ist eine Reihe von Dienstleistungen, die darauf abzielen, eine Website zu pflegen, sie zu aktualisieren und zu verbessern. Website-Support kann in unserem Unternehmen sowohl für interne Kunden, für die wir eine Website von Grund auf erstellt haben, als auch für externe Kunden, die mit fertigen Websites zu uns kommen, angeboten werden.

Es gibt zwei Arten von Website-Unterstützung:

1. Technisch
2. Informativ

Wir bieten unseren Kunden jede Art von Website-Support, einschließlich:

Technisches Audit der Website

Wir stellen technische Mängel der Website fest, prüfen die Download-Geschwindigkeit der Seiten, überprüfen die Richtigkeit des mobilen Layouts der Website und prüfen das Vorhandensein wichtiger Module und Updates. Wir beseitigen auch offensichtliche Fehler und bieten Lösungen für Probleme an.

Aktualisierungen der Website

Eine Website kann je nach Zielsetzung zu einem bestimmten Zeitpunkt fertiggestellt oder angepasst werden. Zum Beispiel kann ein Redesign implementiert werden, neue Seiten können hinzugefügt oder neue Module installiert werden.

Unterstützung der Website-Funktionalität

Beispiele für diese Art von Unterstützung sind: die Erstellung regelmäßiger Backups von Websites und Datenbanken, die Korrektur von Fehlern im Arbeitsprozess und das Scannen nach Viren und bösartigen Skripts.

Interaktion mit dem Hosting-Anbieter

Diese Unterstützung umfasst den Transfer der Website auf einen anderen Server, die Wiederherstellung der Website anhand von Backups, den Domaintransfer und die Auswahl eines neuen Hostings.

Die technische Unterstützung kann regelmäßig (auf Anfrage) oder laufend erfolgen.

Wenn wir auf Anfrage technische Unterstützung leisten, lösen wir in der Regel die spezifischen Probleme der Website. Wenn der Kunde an einer kontinuierlichen Unterstützung interessiert ist, legen wir die Anzahl der Stunden pro Monat und einen Festpreis für diese Stunden fest.

Bei der informatorischen Unterstützung geht es vor allem um die Bearbeitung von Website-Inhalten (Aktualisierung oder Hinzufügung von Texten, Bildern oder Videos) und manchmal auch um Hilfe bei der SEO-Promotion.