Erstellung eines Budget- und Zeitplans für ein Softwareprojekt

Nehmen wir an, wir starten ein Projekt, haben aber noch keine Erfahrung mit der Budgetierung eines Softwareprojekts.

Was sollten die Leute, die an diesem Projekt arbeiten werden, tun, um eine anständige Budgetplanung zu erstellen?

Sollte bei diesem Prozess jede Bewegung berücksichtigt werden? Ich meinte die Codierung der Struktur und des Datenzugriffs, die Erstellung erholsamer Dienste, die Erstellung der Datenbankstruktur und -architektur und so weiter bei jeder Bewegung.

Wie soll der Zeitplanungsprozess ablaufen?

Wer wird die Software entwickeln? Ein externer Anbieter?
@stephan nein. die Jungs, die in der Firma arbeiten. Sie haben vollen Zugriff auf die Buchhaltung und alle anderen Dinge. Daher ist es für sie kein Problem, sich anzusehen, was das Unternehmen anbieten könnte. aber das Schätzen der Zeit ist hier ein echtes Problem.

Antworten (3)

Um das Budget und den Zeitplan eines Projekts zu definieren, ist das erste, was man wissen muss, der Umfang des Projekts. Das heißt: Sie müssen wissen, was nicht im Projekt ist.

Beginnend mit dem Umfang können Sie das Projekt grob in Hauptaufgaben herunterbrechen und erhalten eine erste Einschätzung der Planung und des Budgets des Projekts.

Denken Sie nur daran (und erinnern Sie die Beteiligten daran), dass es grob ist und verfeinert werden muss. Lassen Sie sich eine solche grobe Schätzung nicht auf einen Vertrag schreiben!

Zum Schätzen ist zunächst eine Zeitschätzung erforderlich, was meiner Meinung nach eher eine Frage der Erfahrung ist. Angesichts der Menge an Arbeit und der Kenntnis der Komplexität der Aufgabe muss ein PM in der Lage sein, die Zeit abzuschätzen, die zur Erfüllung der Aufgabe benötigt wird.

Danach sind die Kosten ziemlich einfach zu berechnen. Die Kosten hängen von den verbrauchten Ressourcen ab: Die Kosten für das Team sind offensichtlich die Hauptkosten. Und dann die Tools, die sie verwenden (Computer, Software usw.), die Dienste, die sie verbrauchen (Strom, Internetzugang, Telefon usw.). Vielleicht müssen Sie mit Auftragnehmern und Anbietern zusammenarbeiten. Usw...

Die Kosten sind natürlich die Summe aller Kosten für die Zeit des Projekts.

@Traroth danke für die Antwort. Wie Sie sehen können, habe ich einen Kommentar zum Beitrag von @ashes999 geschrieben, der auf meinen Gründungsplan hinweist. aber ich habe keine Ahnung, wie ich mit der Budgetierung beginnen soll. Ich weiß, dass ich zuerst einen anständigen Plan besorgen muss, von dem ich glaube, dass ich den Prototyp meines Plans wie oben habe. Aber da wir die eigentlichen Arbeiter der Firma sind (nicht die Leute, die außerhalb der Firma angestellt werden), werden wir kein Angebot machen. Dennoch müssen wir das Projekt budgetieren, indem wir uns überlegen: „Wie viel würden wir einem Unternehmen anbieten, wenn wir dieses Projekt für ein anderes Unternehmen bauen würden?“.
@Traroth mein eigentliches qu. Wie beginnt man nach der Planung mit der Budgetierung? Ich meine, sollten wir uns ein Stundenhonorar schaffen? zum Beispiel: „Ok, ich habe 3 Stunden hintereinander Code geschrieben, lasst uns 300 $ zum Budget unseres Projekts hinzufügen? und außerdem werde ich jetzt eine große Pizza bestellen. also füge auch $20 dafür hinzu.“ Art Budgetierung?
Ok, ich werde meine Antwort bearbeiten.
@Traroth, das wäre das Schönste, was mir heute passiert. Danke !
@Traroth danke für das Update. du hast es sehr ausführlich und ausführlich erklärt.
Ich habe eine Spin-of-Frage gestartet: pm.stackexchange.com/questions/1484/…

Die Antwort, nach der Sie wahrscheinlich suchen, ist , große Schätzbereiche (plus oder minus 50-100 % oder mehr) anzugeben und zu sagen: Das ist unsere Meinung. Weil du es nicht weißt.

Die Planung erfolgt wahrscheinlich am besten von oben nach unten, beginnend mit vagen Elementen (z. B. Merkmal X) und heruntergebrochen in kleinere Elemente.

Wenn Sie Ihre Anforderungen nicht gut kennen oder wenn sie sich ändern können und wenn Sie nichts Statisches wie einen Compiler bauen, würde ich vorschlagen, agile/scrum/xp/etc. ein Wirbel. Es ermöglicht Ihnen, die verbleibende Zeit bis zur Arbeit anhand der tatsächlichen Teamleistung in der Vergangenheit abzuschätzen , und Sie müssen nur einen Sprint (ca. 2 Wochen) warten, um echte Daten über Ihre Leistung zu erhalten.

PMI schlägt viele großartige Schätztechniken vor, die Sie wahrscheinlich verwenden können:

  • Schätzung basierend auf ähnlichen Projekten (wenn möglich)
  • Schätzung basierend auf ähnlichen Produkten/Stücken, die in verschiedenen Projekten gebaut wurden
  • Drei-Punkte-Schätzung (gewichteter Durchschnitt aus Best-Case, Worst-Case und Average-Case)
  • Top-down- und Bottom-up-Schätzung (ja, beides)

Ein Budget ist schwerer abzuschätzen. Ich habe nicht viel Erfahrung damit, also werde ich mich auf diesen Teil ducken. Der verdiente Wert ist im Allgemeinen schrecklich (aus meiner Sicht der Softwareentwicklung), obwohl es sehr nützlich ist, die erwarteten und die tatsächlichen Kosten bis heute zu verfolgen.

@ashes999 Danke für die Antwort. Ich habe darüber nachgedacht, mit der Planung zu beginnen, indem ich das Projekt in Bereiche aufteile. erstens Erstellen der Datenbankstruktur, zweitens Implementieren der Datenzugriffsschichten (möglicherweise Repository-Muster), drittens Erstellen der Serviceschichten (Zugriff auf die Daten mit Datenzugriffsschichten und Verarbeiten der Notwendigkeit), viertens Implementieren von Restful Services, fünftens Admin-Control-Panels und zuletzt Erstellen der Endbenutzeroberfläche. das ist mein Ziel hier. Natürlich werden diese Hauptabteilungen in ihre eigenen kleinen Kategorien unterteilt. meinst du ich bin hier richtig? schlagen Sie noch etwas vor?
@tugberk es ist wirklich schwer zu sagen, ohne mehr über dein Projekt zu wissen. Sie können das am besten beurteilen. Persönlich bevorzuge ich (stark) einen agilen Ansatz, bei dem Sie Funktionalität stückweise implementieren. Informieren Sie sich und probieren Sie es aus, es eignet sich hervorragend für die meisten Softwareprojekte. Jeder Teil der Arbeit würde Datenzugriff, Verarbeitung, ruhende Dienste usw. beinhalten. Andererseits müssen Sie Ihre Architektur zuerst planen.
@ashes999 Wir planen unsere Datenbankarchitektur auf sehr unprofessionelle Weise (es ist mir peinlich, aber mit Word-Dokument oder Excel-Dokument: S) Ich bin nicht stolz darauf, aber es hat bisher so gut funktioniert. aber (wieder) fühle ich, dass es der falsche Weg ist. wo könnten wir Ihrer Meinung nach neben der Datenbank auch die Architektur planen? Ehrlich gesagt (und wieder peinlich berührt) habe ich keine Erfahrung und kein Wissen über Agilität. Ich weiß, dass einige Firmen Lösungen dafür anbieten (z. B. TeamPulse von Telerik), wissen aber nicht, wie man sie effizient nutzt.
@tugberk Wenn es für Sie funktioniert, bleiben Sie dabei und ändern Sie es nicht, es sei denn, Sie sind sich zu 100% sicher, dass der Änderungsprozess der richtige Schritt ist. Word-Dokumente sind großartig; Ich mag Google Docs, weil sie online und kollaborativ sind. Verwenden Sie einfach diese und Sie sollten in Ordnung sein. Für Agilität einfach googlen und darüber lesen ...
@ashes999 Ich bin wirklich neugierig, wie die Jungs von Microsoft oder Orchale das machen. Glaubst du, sie verwenden Stift und Papier dafür? :) frage das nur aus neugier :)
@tugberk Ich habe eigentlich bei Oracle gearbeitet. Bei kleinen Projekten (10-40 Personen) haben wir einfach alles auf Papier gemacht und es dann in einem kollaborativen Wiki dokumentiert. Und leider verwenden sie ein Freigabesystem und haben viele Word-Dokumente an gemeinsam nutzbaren Orten. Also würde ich mir keine Sorgen um sie machen; tun, was für Sie funktioniert .
@ashes999 also habe ich den qu gefragt. an einen richtigen Mann, wie es passiert, ein ehemaliger Oracle-Mitarbeiter zu sein :) Diese Wiki-Sache denke ich auch (ich bin mir nicht sicher, ob Wiki hier das richtige Wort ist, aber) Glaubst du, dass ein Unternehmen seine eigene 'MSDN' erstellen muss?
@tugberk diese Frage wird unglaublich groß! Wikis sind ein großartiges Werkzeug für die Zusammenarbeit in Teams mit angemessener Größe (mehr als eine Person). Ich würde diese oder Google Docs oder eine andere kollaborative, online zugängliche Art der Bearbeitung verwenden, wenn ich könnte.
@ashes999 Sie haben Recht mit dem Thread-Wachstum. danke für die Unterstützung !

Als Erstes müssen Sie den Projektstrukturplan (PSP) bis auf Arbeitspaketebene erstellen . Der PSP beschreibt das Endprodukt, das Sie liefern müssen, sowie die Prozesse, die für die Lieferung erforderlich sind. Dies erfordert eine Reihe von Diskussionen mit Ihren Stakeholdern, um sicherzustellen, dass alles Erforderliche enthalten ist. Sie brauchen eine ziemlich gute Vorstellung davon, wie fertig aussieht.

Das Endergebnis sollte ausreichend detailliert in die funktionalen Komponenten aufgeschlüsselt werden, die zu den Fähigkeiten beitragen, die das Produkt unterstützen muss. Jedes wird ein Arbeitspaket sein.

Als nächstes muss jedes Arbeitspaket geschätzt werden. Ashes hat einige typische Methoden angegeben, um eine gültige Schätzung zu erhalten. Da das Schätzen ein Problem zu sein scheint, würde ich empfehlen, jedes Arbeitspaket (oder PSP-Element der niedrigsten Ebene) in alle Aufgaben zu entwickeln, die erforderlich sind, um das Ergebnis zu vervollständigen (= Aufgabendefinition ). Jede Aufgabe wird dann separat in ideale Arbeitsstunden oder -tage geschätzt. Das heißt, wenn jemand ununterbrochen an dieser Aufgabe arbeiten würde, würde er dafür x Stunden brauchen. Auch hier wird die Schätzung von Fachexperten und/oder den Personen vorgenommen, die sie durchführen.

Verwenden Sie keine Einzelpunktschätzungen, sondern eine Spanne (Höchstwahrscheinlich - Worst Case).

Das bedeutet, dass, anstatt zu schätzen, dass eine Aufgabe 10 Stunden dauern wird, die Schätzung im wahrscheinlichsten Aufwand von 8 Stunden und im schlimmsten Fall von beispielsweise 14 Stunden detailliert wird, da wir die Technologie XYZ nicht sehr gut kennen und es möglicherweise ein Stück ist Kuchen, aber wenn Faktor X nicht mit Y übereinstimmt, müssen wir Z neu konfigurieren, daher die 14 Stunden.

Wie viel Aufwand oder wie lange eine Aufgabe wirklich dauert, ist nicht deterministisch (10 Stunden), sondern folgt einer zu berücksichtigenden Wahrscheinlichkeitsverteilung. Denken Sie an Ihren täglichen Arbeitsweg: Dauert er jeden Tag genau gleich lang? Indem Sie den schlimmsten Fall berücksichtigen, können Sie eine Marge errechnen, aber Sie kommen gegen den wahrscheinlichsten zurecht (weil Murphy nicht immer einen Besuch abstattet und um das Studentensyndrom zu verhindern (nehmen Sie sich die ganze Zeit zugeteilt)).

Beachten Sie, dass Sie, wenn Sie sich noch nicht sicher sind, welche Technologie Sie verwenden sollen, entweder Annahmen treffen oder (besser) eine Schätzung für jede Möglichkeit vornehmen müssen.

Die Schätzung erfolgt am besten mit einer Gruppe von Personen, anstatt einzeln.

Wenn Sie all diese Schätzungen zusammenfassen, erhalten Sie das erforderliche Budget in Stunden oder Tagen für jedes Arbeitspaket und letztendlich für das gesamte Projekt sowie mögliche Ausführungsalternativen.

Erstellen Sie als nächstes Ihr Netzwerk aller Arbeitspakete (dies ist der Plan, dem Sie folgen werden) und planen Sie die Aufgaben und weisen Sie jedem von ihnen Personen oder Profile zu, damit Sie auch die Kostenschätzung und die Lieferzeit kennen .

Führen Sie eine Risikoidentifikation durch (verwenden Sie den PSP!) und fügen Sie bei Bedarf spezifische Aufgaben zur Risikominderung hinzu.

Überprüfen Sie jedes PSP-Element auf mögliche Risiken und erstellen Sie einen Risikoreaktions-/Minderungsplan: Diese „Maßnahmen“ Ihres Risikoreaktionsplans müssen irgendwo hinzugefügt werden, entweder in einem eigenen Arbeitspaket oder in den betroffenen Arbeitspaketen. Diese Aufgaben müssen dann ebenfalls geschätzt werden.

Stellen Sie sicher, dass diese Kostenpositionen identifiziert sind, damit Sie Ihr Notfallbudget kennen und wissen, wie es angewendet wird.

Der endgültige Zeitplan basiert auf den wahrscheinlichsten Schätzungen oder einer anderen Art der Berechnung (z. B. PERT), aber stellen Sie sicher, dass Sie auch eine gewisse Marge in Zeit und Geld einkalkulieren. Da das Schätzen ein Problem zu sein scheint, argumentieren Sie besser, um die Differenz zwischen dem wahrscheinlichsten (oder durchschnittlichen oder PERT oder was auch immer) und dem schlimmsten Fall zu nehmen. Da Sie gegen ersteres auskommen, sollte das ok sein.

Vergessen Sie nicht, Materialkosten, Lizenzen, ... hinzuzufügen, um Ihr Budget zu vervollständigen.

Hoffe das macht Sinn.

Ein letztes Wort: Fahrzeit!! Damit Sie es für das Projekt nach diesem verwenden können. Nicht nur, um mit zuvor realisierten Arbeitspaketen oder Aufgaben vergleichen zu können (wenn Sie die Zeit für dieses Detail verfolgen), sondern auch, um zu verfolgen, wie gut Sie die Schätzungen machen. Wenn Sie feststellen, dass Sie um einen bestimmten Prozentsatz unterschätzen, können Sie diesen „Beweis“ das nächste Mal als separate Marge verwenden oder sogar die wahrscheinlichsten Schätzungen anpassen.

Beeindruckend. danke herr. das ist wirklich hilfreich. Ich muss es mehrmals lesen, um es in meinem Kopf zu verankern. Ich habe ein paar Fragen: Können Sie diesen Satz genauer beschreiben, wenn es Ihnen nichts ausmacht Verwenden Sie keine Einzelpunktschätzungen, sondern eine Spanne (höchstwahrscheinlich - Worst Case) und können Sie mir ein Beispiel für diesen Satz geben (wieder wenn es Ihnen nichts ausmacht) Führen Sie eine Risikoidentifikation durch (verwenden Sie den PSP!) und fügen Sie bei Bedarf spezifische Aufgaben zur Risikominderung hinzu
Ich habe meine Antwort aktualisiert. Hoffe, es klärt die Dinge.