Wie kann man dem Kunden den geplanten Projektansatz zeigen?

Ich bin in eine Situation geraten, in der der Kunde mich die nächsten zwei Dinge fragt:

  1. Geben Sie mir Ihren Projektplan, wie Sie dieses Projekt angehen würden, um sicherzustellen, dass ich am Ende eines bestimmten Monats ein Ergebnis habe.

  2. Erläutern Sie, wie Sie den vorhandenen Code für das Front-End und das Back-End analysieren würden, um sicherzustellen, dass Sie verstehen, was die vorherigen Programmierer getan haben.

Dies ist aus einer freiberuflichen Perspektive, wo ich sowohl als PM als auch als Programmierer "agiere".

Welche Antwort sollte ich dem Kunden geben? Wir sind in der Phase, in der er sich für meine Dienstleistungen interessiert und wissen möchte, wie ich es machen würde.

Antworten (2)

Sie haben zwei Methoden, die Sie Ihrem potenziellen Kunden offenlegen müssen: 1) PM, 2) Software, SDLC. Diese beiden Methoden sind getrennt, müssen aber zusammenarbeiten.

Ich antworte auf Nr. 1 und überlasse Nr. 2 den eher technischen Leuten an diesem Austausch.

Ihr Kunde sucht danach, wie Sie das Projekt in Bezug auf das, was Sie am Ende des Projekts liefern werden, sowie Zwischenlieferungen während des Projekts abgegrenzt haben. Dies lässt sich am besten als Projektumfangserklärung darstellen, die häufig in einem Projektauftrag, aber auch in Ihrem Projektmanagementplan (PMP) sowie in einem anfänglichen Projektstrukturplan (WBS) und möglicherweise einem ersten PSP-Wörterbuch zu finden ist. Das ist das Was.

Ihr Kunde wird sehen wollen, wie Sie die Arbeit planen, welche Phasen Sie vorschlagen und wie viel Zeit Sie für die Lieferung benötigen. Dies wird am besten als Zeitplan auf hoher Ebene mit Meilensteinen angezeigt, z. B. als Gantt-Diagramm, aber Ihr Kunde möchte möglicherweise Ihren vorläufigen Zeitplan sehen, der Ihren WBS im Laufe der Zeit geladen zeigt. Dies ist das Wann.

Ihr Kunde wird die Kosten des Projekts sehen wollen. Dies wird am besten als Ihr Kostenvorschlag mit Preis vorgelegt, aber Ihr Kunde möchte möglicherweise auch sehen, wie viel Komponenten des Projekts kosten, was als Teil der Performance Measurement Baseline (PMB) und in Ihrem PSP-Wörterbuch angezeigt wird. Dies hängt jedoch von Ihrer Vertragsart mit Ihrem Auftraggeber ab.

Schließlich wird Ihr Kunde innerhalb Ihres PMP an Ihrem Managementansatz zur Verwaltung und Kontrolle des Projekts interessiert sein, der Themen wie Risiko, Qualität, Kommunikation mit Stakeholdern, Ihren Beschaffungsansatz für Materialien, die Sie benötigen werden, usw. abdeckt.

Dies sind viele Informationen, die Sie wahrscheinlich noch nicht alle sortiert haben, da Sie noch nicht einmal den Job haben. Skalieren Sie diese Informationen also entsprechend, dh zeigen Sie, was Sie auf einer höheren, strategischeren Art gesehen haben. Wahrscheinlich haben Sie zu diesem Zeitpunkt keine harten Kernpläne und Zeitpläne vorzuweisen, daher sollten Sie diese Informationen eher in einem Präsentationsformat bereitstellen. Die Kommunikationsbotschaft ist, dass Sie wissen, wie Sie Arbeiten organisieren, ausführen, verwalten und kontrollieren, um so effizient wie möglich ans Ziel zu kommen und frühzeitig und oft kommunizieren zu können, wenn es schlecht läuft.

Nun, nach meinem PM-Wissen sieht diese Antwort wie eine Million Dollar aus. Das was ich gemacht habe, habe ich täglich meinen Plan vorgelegt (Tag 1-2, Tag 2-5, etc..) und erklärt, dass ich im Moment weitere Einblicke in den Quellcode bekomme (die Software ist bereits entwickelt und die Kunde möchte es weiter ausbauen - was meine Aufgabe sein sollte) wird der Plan präziser. Vielen Dank.

Eine technische Perspektive:

Aus den von Ihnen bereitgestellten Informationen schließe ich, dass der Kunde technisch kompetent ist und die Risiken der Übertragung einer Codebasis an einen anderen Programmierer sehr gut versteht. Es ist ein häufiges Problem, dass Programmierer den Aufwand unterschätzen, in eine bestehende Codebasis einzutauchen.

Aus meiner Sicht wird es wichtig sein zu zeigen, dass Sie es nicht tun .

Faktoren, die den Aufwand zur Übernahme einer bestehenden Codebasis beeinflussen

Je nach Größe der Codebasis wird es sehr schwierig sein, eine vernünftige Schätzung abzugeben, da folgende Faktoren den erforderlichen Aufwand stark beeinflussen können:

  • Größe – grobe Metriken wie Dateien, Codezeilen
  • Technologische Basis: Basiert es auf einem bekannten Framework, das Sie vielleicht sogar schon kennen? Meiner Meinung nach würde dies das Vertrauen in Ihre Leistungsfähigkeit immens steigern.
  • Dokumentation, Kommentare im Code: Existieren diese und wurden sie gepflegt?
  • Fähigkeit der vorherigen Programmierer und Grund, warum sie das Projekt aufgegeben haben.
  • Alter der Software: Aus Erfahrung würde ich sagen, je älter die Codebasis wird, desto wahrscheinlicher wird es, dass man Hacks und Abkürzungen findet, es sei denn, die Entwicklung war sehr diszipliniert und Code wurde von Zeit zu Zeit umgestaltet.
  • Externe Abhängigkeiten (Bibliotheken): Sind sie ausgereift und stabil, überschaubar? Oder wurden einige obskure Vorabversionsbibliotheken verwendet.
  • Viel benutzerdefinierte Meta-Programmierung und "Rubinmagie", wie sie häufig in Rails-Projekten zu sehen sind, können sehr problematisch sein, wenn man versucht, die Interna zu verstehen
  • Testabdeckung

Ich würde Ihnen raten, möglichst viele solcher Metainformationen im Vorfeld zu erheben, um Ihre Kompetenz zu demonstrieren und Ihr Handeln zu planen.

Allgemeine Ansätze

Um in den Code einzusteigen, wäre es ideal, wenn Sie mindestens eine Überprüfung mit einem der ursprünglichen Programmierer vereinbaren könnten, damit er Ihnen ein Design auf hohem Niveau geben und seine Designentscheidungen erklären kann.

Ein weiterer gängiger Ansatz, um sich mit einer Codebasis vertraut zu machen, besteht darin, einen bestimmten Anwendungsfall auszuwählen und ihn von oben nach unten zu debuggen.

Abhängig von der Größe der Codebasis können Sie spezielle Tools zum Visualisieren von Objektabhängigkeiten, Analysieren der Codequalität und dergleichen in Erwägung ziehen.