Wie können wir Projekte unter Berücksichtigung von Supportproblemen realistisch planen?


13

Wir haben ein Problem bei der Arbeit: Wir versuchen, die Arbeit so zu planen, dass wir Zeitskalen einschätzen und Stichtage erhalten können.

Das Problem ist, dass es schwierig ist, ein Projekt zu planen, ohne zu wissen, was alles passieren wird.

Derzeit haben wir beispielsweise alle unsere Projekte bis Anfang Dezember geplant. In dieser Zeit werden jedoch verschiedene interne und externe Besprechungen, Telefonkonferenzen und zusätzliche Arbeiten stattfinden. Es ist schön und gut zu sagen, dass ein Projekt drei Wochen dauern wird, aber wenn in dieser Zeit eine Unterbrechungswoche ansteht, wird der Fertigstellungstermin um eine Woche verschoben.

Das Problem ist dreifach:

  1. Wenn wir Projekte planen, werden die Zeitskalen wörtlich genommen. Wenn wir drei Wochen veranschlagen, wird die Frist auf drei Wochen festgesetzt, der Kunde wird informiert, und es besteht kein Raum für eine Verlängerung.

  2. Zwischenarbeiten und dergleichen bedeuten, dass wir produktive Zeit für die Arbeit am Projekt verlieren.

  3. Manchmal haben Kunden nicht die Zeit, die wir brauchen, um die Arbeit zu erledigen, deshalb kommen sie manchmal zu uns und sagen, dass sie bis Ende des Monats ein Projekt erledigen müssen, auch wenn wir glauben, dass die Arbeit zwei Monate dauern wird - ganz zu schweigen davon, dass wir bereits arbeiten müssen.

Wir haben ein Gantt-Diagramm, das wir versuchen, mit allen Projekten auszufüllen, die wir haben, und wir füllen Arbeitszeittabellen aus, aber sie werden überhaupt nicht mit dem Gantt-Diagramm verglichen. Das macht es schwierig zu sagen, "Nun, wir haben 3 Wochen für dieses Projekt eingeplant, aber wir haben hier eine Woche verloren, daher muss die Frist um eine Woche verschoben werden."

Es ist auch nicht professionell, Termine, die wir dem Kunden mitgeteilt haben, nicht einzuhalten.

Wie gehen andere mit dieser Situation um? Wie managen Sie die Planung von Projekten? Wie viel "zusätzliche" Zeit planen Sie in ein Projekt ein, um Nicht-Projektarbeit zu berücksichtigen, die während eines Projekts auftritt? Wie gehst du mit Support-Problemen, Bugs und anderen Dingen um? Dinge, die Sie bei der Planung nicht berücksichtigen können?

AKTUALISIEREN

Viele gute Antworten danke.


1
Werfen Sie einen Blick auf Liquid Planner ( liquidplanner.com ). Sie können optimistische und "realistische" Arbeitsstunden für eine Aufgabe eingeben und ein geschätztes Veröffentlichungsdatum berechnen (mit einer Genauigkeit von 50%, 90%, 98%). Und es macht noch viel mehr. Wenn ich Sie wäre, würde ich eine Demo versuchen
jao

2
Aus Ihrem Profil sehe ich, dass Sie ein Entwickler sind. Ihr Management muss sich damit und mit dem Kunden auseinandersetzen. Ihre Aufgabe ist es, Schätzungen zu erstellen, wie viel es kostet, und transparent zu kommunizieren, wenn etwas schief geht. Das Management nimmt es von dort.
JohnDoDo

1
Zu Punkt 3: Erklären Sie Ihrem Kunden das Projektdreieck : Günstig, gut, schnell: Wählen Sie zwei aus.
Mouviciel

1
Mouviciel - das ist theoretisch gut, aber in der Praxis leider nicht. das haben wir schon vor.
Thomas Clayson

3
@ThomasClayson Das ändert nichts an der Tatsache, dass das Projektdreieck die Wahrheit ist. Wenn Ihr Unternehmen einfaches Projektmanagement nicht versteht, ist es möglicherweise Zeit zu gehen.
Thomas Owens

Antworten:


14

Das Problem ist jedoch, dass es schwierig ist, ein Projekt zu planen, ohne zu wissen, was alles passieren wird.

Das ist der Punkt des Risikomanagements. Sie können nicht alles wissen, also planen Sie basierend auf Ihren Kenntnissen und identifizieren, welche Dinge den größten Einfluss auf Ihren Plan haben könnten und wie wahrscheinlich dies ist. Bewerten Sie auch die möglichen Auswirkungen des Zeitplans, indem Sie angeben, dass der Zeitplan bei Auftreten von X um geschätzte (Schlüsselwort - geschätzt) Y Tage oder Wochen verschoben wird.

Es ist schön und gut zu sagen, dass ein Projekt 3 Wochen dauern wird,

Niemals eine so genaue Schätzung abgeben. Geben Sie einen Bereich an oder quantifizieren Sie die Wahrscheinlichkeit, diese Schätzung zu treffen. Sagen Sie zum Beispiel "Dieses Projekt dauert 2-5 Wochen" oder "Dieses Projekt wird mit einer Wahrscheinlichkeit von 85% in 3 Wochen und mit einer Wahrscheinlichkeit von 95% in 4 Wochen durchgeführt".

Es ist für den Kunden auch nicht professionell zu behaupten, wir hätten eine Frist verpasst.

Wahr. Sie mischen jedoch die Begriffe "Schätzung", "Zeitplan" und "Frist". Ihre Schätzung ist eine ungefähre Abschätzung, wie lange es dauern wird, bis eine bestimmte Aufgabe oder ein bestimmtes Projekt abgeschlossen ist, und wie wahrscheinlich es ist, dass Sie diese erfüllen. Die Frist ist ein vom Kunden festgelegter Termin, an dem das Projekt durchgeführt werden muss, um Mehrwert zu schaffen. Der Zeitplan ist, wie Sie Ihre verfügbaren Ressourcen verwenden, um Ihre Frist einzuhalten.

Es gibt Zeiten, in denen es einfach nicht möglich ist, die zugewiesene Arbeit innerhalb einer Frist zu beenden, und alle Schätzungen und Planungen in der Welt werden keinen Unterschied machen.

Also meine Frage ... wie machen das andere Leute? Wie managen Sie die Planung von Projekten? Wie viel "zusätzliche" Zeit planen Sie in ein Projekt, um alles zu berücksichtigen, was in der Zwischenzeit passiert?

Ich empfehle, zwei Bücher von Steve McConnell zu lesen: Software Estimation: Demystifizierung der schwarzen Kunst und Rapid Development: Zähmung wilder Software-Pläne . Bei Software Estimation geht es darum, Ihre Schätzungen zu erstellen, den Kunden vorzustellen und einige Aspekte der Verhandlung und des Umgangs mit unrealistischen Erwartungen zu berücksichtigen. Rapid Development ist das allgemeine Projektmanagement, das sich mit Entwicklungslebenszyklen, Planung, Ressourcenzuweisung und der bestmöglichen Planung und Budgetierung von Projekten zur Einhaltung Ihrer Schätzungen und Fristen befasst.


sehr nützlich und sehr gute einblicke. :) vielen Dank. Werde mir diese Bücher ansehen danke.
Thomas Clayson

4

Ich würde vorschlagen, die Details des Scrum-Entwicklungsprozesses zu untersuchen . Es deckt solche Ablenkungsaktivitäten anhand der focus factorMetrik ab. Grundsätzlich müssen Sie 2-3 Sprints / Iterationen durchführen und dann den Fokusfaktor Ihres Teams messen (und für jedes Mitglied wäre dies ebenfalls hilfreich). Danach können Sie genauere Schätzungen vornehmen, die die tägliche Aktivität abdecken.

Schauen Sie sich diesen Artikel an - "Der Fokusfaktor"

Wenn jemand von Ihnen mit der agilen Entwicklung vertraut ist, haben Sie wahrscheinlich von dem Fokusfaktor (oder dem Produktivitätsfaktor) gehört. Es wird für die Planung verwendet, um zu bestimmen, wie viele "echte Stunden" Sie an etwas arbeiten müssen. Es ist der Unterschied zwischen "echten Stunden" und "idealen Stunden".

Bildbeschreibung hier eingeben


3
Es ist gefährlich, eine bestimmte SDLC vorzuschlagen, ohne die Art des Projekts und des Teams zu kennen (z. B. ist Scrum für ein Team mit weniger als 5 oder mehr als 10 Mitarbeitern ungeeignet), und in Scrum einzusteigen, ohne entsprechende Nachforschungen anzustellen, sich zu beteiligen und Kulturanpassungen richten Projekte auf Misserfolg ein. Die Diskussion über die Messung des Fokusfaktors ist jedoch in der Tat relevant und könnte in jeder Methodik, einschließlich plangesteuerter Methoden, nützlich sein.
Thomas Owens

@Thomas Owens: OP konnte nur einen Blick darauf werfen und vielleicht bekam er Einblicke, wie man so etwas oder irgendwelche anderen Gedanken
misst

Danke, ich werde mir das alles auf jeden Fall ansehen. Wir haben wirklich ein Dreierteam, aber in der Praxis arbeiten wir sowieso selbst an Projekten. Das Argument des Fokusfaktors ist interessant. :) Danke.
Thomas Clayson

1

Die Sache mit Unterbrechungen ist, dass bestimmte Personen oder Teams dazu neigen, innerhalb eines relativ kleinen Bereichs von Wahrscheinlichkeiten vorzukommen. Beispielsweise haben Sie ungefähr dieselbe Anzahl von Besprechungen pro Woche oder ungefähr dieselbe Anzahl von Stunden, die Sie für dringende Fehlerbehebungen pro Monat aufgewendet haben, oder dieselbe Zeit, die Sie für die Beantwortung von Fragen für Personen aufgewendet haben, die an Ihrem Schreibtisch vorbeikommen eine lange Zeitspanne.

Viele moderne Planungstechniken berücksichtigen dies. Scrum berücksichtigt die Geschwindigkeit. Die evidenzbasierte Planung verwendet auch eine Geschwindigkeit mit einem Konfidenzintervall für eine bestimmte Schätzung. Pomodoro berücksichtigt Unterbrechungen, wenn Sie entscheiden, mit wie vielen "Pomodoros" Sie in einer bestimmten Woche rechnen können. All dies hängt davon ab, ob Sie historische Messungen Ihrer Unterbrechungen nachverfolgen und diese in Ihre Schätzungen einbeziehen. Ich empfehle Ihnen, sich alle anzuschauen und eine Technik zu entwickeln, die für Ihr Team funktioniert.


Das ist die Sache, aber unsere Unterbrechungen passieren nicht so. Zum Beispiel hätte ich diese Woche X machen sollen, aber ich habe 80% meiner Zeit mit Unterbrechungen verbracht. Diese Woche gab es mehr Meetings als normal und viel Unterstützung. Außerdem wurde ich gezwungen, einige Websites zu erstellen, die diese Woche veröffentlicht wurden, und ich musste einen Entwicklungsserver einrichten und technischen Support für den Rest des Büros bereitstellen. Nächste Woche könnte es keine Treffen und keine Unterstützung geben. Oder ich könnte die Router aktualisieren oder einen Laptop oder etwas sichern müssen. Hier gibt es eine große Auswahl an Probs.
Thomas Clayson

1
Über eine Woche oder einen Tag haben Sie Recht, dass es unvorhersehbar ist, aber wenn Sie es Monat für Monat oder länger nachverfolgen, werden Sie wahrscheinlich feststellen, dass es sich ausgleicht. Wenn Sie wirklich wilder als normal sind, werfen Sie einen Blick auf die Konfidenzintervall-Idee von EBS. Es berücksichtigt historische Wahrscheinlichkeiten wie "90% der Zeit habe ich 5 Stunden am Tag ununterbrochener Arbeit, aber die anderen 10% erledige ich nicht den ganzen Tag." Aus diesem Verlauf erhalten Sie anstelle von harten Daten die Ausgabe "In einem Monat werden wir mit einer Wahrscheinlichkeit von 85% fertig, aber mit einer Wahrscheinlichkeit von 99% in 6 Wochen."
Karl Bielefeldt

1

Rundum gute Ratschläge.

Eine andere Sache, die für die Behandlung von Support-Problemen hilfreich sein kann, ist, Leute zu beschäftigen, die sich auf einer festen "Round-Robin" -Basis um den Support kümmern.

Wenn Sie beispielsweise 5 Entwickler haben, weisen Sie jedem Wochentag einen zu. Wenn dieser Tag kommt, arbeitet der zugewiesene Entwickler NUR für diesen Tag im Support. Am nächsten Tag übernimmt ein anderer Entwickler den Support. Auf diese Weise hat jeder die Chance, in seinem "Flow" zu bleiben, jeder bekommt einen Vorgeschmack auf das Hundefutter.

Wie Sie sich WIRKLICH dafür entscheiden, die reguläre Supportarbeit aufzuteilen, spielt keine Rolle (das Round-Robin- Verfahren an Wochentagen ist nur ein Beispiel). Es kommt darauf an, die Support-Zeit auf feste regelmäßige Intervalle zu beschränken. Dies macht die Entwicklungszeit vorhersehbarer, da nicht jeder "alles fallen lassen" kann, um Support-Probleme zu lösen.


0

Dies ist eine Fähigkeit, die wirklich mit Erfahrung einhergeht, und oft werden Leute gefragt, bevor sie in der Lage sind, so etwas genau zu beurteilen. Ich habe immer in einer ziemlich engen Gruppe mit einem informellen Stil gearbeitet, aber wir entwickelten ein paar Faustregeln, die gut zu halten schienen.

Erstens dauert keine Aufgabe weniger als eine Woche. Schätzen Sie immer in Wochen, auch wenn eine Aufgabe nur wenige Tage in Anspruch nehmen würde. Es wird einen Grund geben, warum dies nicht vor Ende der Woche geschehen wird.

Zweitens, geben Sie Ihr Bestes, um die Zeit zu schätzen, die die Aufgabe in Anspruch nehmen wird, einschließlich Unterbrechungen, Kundenunterstützungsproblemen, Tests usw. Verdoppeln Sie nun diese Anzahl. Das ist Ihre Schätzung (in Wochen).

Stellen Sie drittens sicher, dass Ihr Manager Ihre Schätzungen nicht bereits aufpolstert. Unser Team hatte einen Manager, der sich über unsere Schätzungen beschwerte. Es stellte sich heraus, dass er es bereits mit 2,1 multiplizieren würde (seine empirisch abgeleitete Auffüllschätzung), und wir hatten es bereits verdoppelt, bevor wir es ihm sagten.

Es ist kein ausgefallenes Werkzeug und möglicherweise keine perfekte Methode, funktioniert aber überraschend gut.


0

Die Leute, die die Schätzung vornehmen, müssen verstehen, dass kein Team jemals zu 100% an einem Projekt beteiligt ist. Sie haben Krankenurlaub, Urlaub, Jury-Pflicht, Trauerurlaub, erforderliche HR-Besprechungen (es ist Zeit für Vorteile!), Teambesprechungen, die nicht projektbezogen sind, unvermeidbare Verzögerungen, Badezimmerpausen, Unterstützung bei der Arbeit an bereits in Produktion befindlichen Artikeln, Umgang mit E-Mails, , Konfigurieren des neuen Computers nach dem Tod des alten, Beantworten von Fragen zur zukünftigen Arbeit und Vornehmen von Schätzungen für diese Arbeit, Mentoring von Junioren usw., die berücksichtigt werden müssen. Es ist unverantwortlich, dass ein Schätzer mehr als 6 von 8 Stunden einnimmt Verfügbar pro Tag. Dies ist eine Garantie dafür, dass die Frist nicht eingehalten werden kann. Wenn Sie garantieren, dass die Frist nicht eingehalten werden kann, garantieren Sie einem unglücklichen Kunden.


0

Sie haben vollkommen recht - es ist schwierig, ein Projekt zu planen, ohne zu wissen, was alles passieren wird. Es ist jedoch sehr wichtig, den Überblick zu behalten, was eine Norm ist, sowie die Aufgaben, die Sie vorhersehen. Hier spielt die Terminverwaltung eine Rolle. Ich habe das Microsoft-Projektmanagement (Standardversion) verwendet, für das auch Funktionen enthalten sind, die Teil einer Projektmanagement-Planungssoftware sind.

Weitere Informationen finden Sie unter http://www.microsoft.com/project/en/us/schedule-management.aspx .


-1

Es scheint, als würden Ihre Projektteams eine Menge versteckter Anstrengungen unternehmen, durch die Sie den Fokus und die Geschwindigkeit verlieren. Es könnte von Vorteil sein, die zu erledigende Aufgabe tatsächlich zu trennen

..support Probleme und Bugs und so?

an eine bestimmte Personengruppe, damit sich die anderen Teammitglieder auf die neuen Entwicklungsaufgaben konzentrieren können. Dadurch kann die Gesamtproduktion etwas sinken, aber die Qualität wird verbessert, weil weniger Ablenkung herrscht. Im Gegenzug wird die Anzahl der Bugs reduziert, sodass A-hoc-Arbeiten den Weg in Ihre Projekte finden.

Was den Planungsteil betrifft, stimme ich der Antwort von Thomas Owens vollkommen zu.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.