Wie soll ich vorgehen, wenn ich den Verdacht habe, dass ein Projekt grob überschätzt wird? [geschlossen]

Praktisch alles, was mit dem Geschäftskern des Unternehmens zu tun hat, für das ich arbeite, hängt davon ab, dass einige Artikelnummern sequentiell generiert werden. Leider wurden diese Artikelnummern vor langer Zeit als Fixpunkt ohne Dezimalstellen definiert und es gehen ihnen die möglichen Nummern aus.

Natürlich waren einige Abteilungen schlau genug, diese als mindestens 32-Bit-Integer zu definieren, und können die Zunahme problemlos aufnehmen.

Ich arbeite derzeit für verschiedene Data Warehouse-Satellitenanwendungen und weiß, dass das Data Warehouse selbst die Änderung berücksichtigen muss. Data-Warehouse-Entwickler wurden gebeten, die Änderung abzuschätzen, und sie leisteten einen sehr großen Aufwand (ca. 800 Personentage). Diese Informationen werden zusammen mit den Schätzungen für alle beteiligten Geschäftseinheiten innerhalb einer internen Plattform bereitgestellt.

Nachdem ich an einer Anwendung gearbeitet habe, um automatische Tests für Data Warehouses bereitzustellen, weiß ich, was sie ändern müssen (z. B. Indizes löschen, Statistiken löschen, die Spalte ändern, Indizes neu erstellen, Statistiken neu erstellen, einige proprietäre Metadaten für alle beteiligten Tabellen aktualisieren, die Genauigkeit temporärer Tabellen überprüfen und ändern in manchen Skripten testen, ob alles noch funktioniert etc.) und deren Aufwandsschätzung meiner Meinung nach sehr groß ist.

Um einige Probleme in Kommentaren/vorhandenen Antworten zu beantworten: Ich kann dies mit Fakten wie der Anzahl der betroffenen Tabellen und der Anzahl der betroffenen Metadatendateien untermauern, da mir bewusst ist, dass es ohne dies keinen Sinn macht, dieses Problem zu diskutieren.

Außerdem gab es eine E-Mail, in der der Aufwand erklärt wurde, da sich einer der Product Owner auch darüber gewundert hatte. Der Aufwand ist hauptsächlich proportional zur Anzahl der betroffenen Objekte (Tabellen und Reports) und enthält keinen Hinweis auf obskure Komponenten oder eine große Reserve für "Unbekanntes".

Warum spielt es eine Rolle?

Da wir zum selben Geschäftsbereich gehören und dessen Budget begrenzt ist, erhält unser Team bei Genehmigung dieser Bemühungen ein kleines Budget für das nächste Geschäftsjahr. Dies ist wichtig, da wir Schwierigkeiten haben, ein zusätzliches Mitglied zu haben, um die Arbeitsbelastung zu decken.

Mir fallen nur zwei Personen ein, mit denen ich sprechen kann:

  • Personalmanager - sehr lose mit Data Warehouse-Leuten verbunden und auch sehr beschäftigt
  • der Product Owner für eines der Projekte, an denen wir arbeiten - ich habe eine sehr gute Beziehung zu ihm, aber er ist auch der Personalmanager für einige der an der Schätzung beteiligten Personen, daher sieht es nach einem "Interessenkonflikt" aus.

Frage: Wie soll ich vorgehen, wenn ich den Verdacht habe, dass ein Projekt grob überschätzt wird? (und das betrifft mich und mein Team)

Nur um die 800 Personentage zu verdeutlichen: Haben sie gesagt, dass die Änderung des Systems 3 Personen erfordert, die 3 Jahre lang Vollzeit arbeiten? vielleicht war es ein Tippfehler?
@Alex - ja, das ist im Allgemeinen eine gute Option. Es gibt jedoch eine schlechte Zusammenarbeit zwischen unserem Team und den Schätzern. Sie haben einfach alle unsere früheren Bedenken ignoriert und sie sind einfach nicht daran interessiert, solche Probleme mit uns zu diskutieren. Ein großer Aufwand ist für sie sehr bequem, da die Zeit/das Budget verwendet werden kann, um die Verzögerung anderer Projekte zu rechtfertigen.
@viorel - nein, da ist kein Tippfehler, da der Aufwand auch mit den geschätzten Kosten einhergeht und ich das noch einmal überprüfen könnte. Ja, deshalb habe ich "grob geschätzt" erwähnt. Ein Teil des Aufwands kann durch die Anzahl der betroffenen Objekte gerechtfertigt werden, da Items eine Dimension sind, die von vielen Faktentabellen verwendet wird, und durch die fehlende Testautomatisierung für Berichte. Trotzdem ist der Aufwand enorm.
Haben Sie tatsächlich mit dieser speziellen Codebasis gearbeitet oder evaluieren Sie auf der Grundlage eines anderen Systems? Sind Sie sich aller technischen Schulden bewusst, die von dieser Änderung über die von Ihnen beschriebene Arbeit hinaus beeinflusst werden können? Seien Sie vorsichtig, wenn Sie der Schätzung eines anderen widersprechen, wenn Sie nicht über spezifische Kenntnisse verfügen.
@cdkMoose - Codebase ist in diesem Fall nicht betroffen. Sie müssen in vielen Tabellen und Berichten lediglich eine Dimensionsspalte vergrößern. Es gibt also im Grunde eine sehr große DDL + einige Skripte ändern, die temporäre Tabellen verwenden + einige Berichte aktualisieren. Die DDL kann programmgesteuert erstellt werden, da die Spalte praktisch überall denselben Namen hat. Zwar gibt es eine große technische Schuld, aber zu ändernde Skripte können auch automatisch aufgelistet werden (ihre Änderung muss jedoch manuell durchgeführt werden).
Du weißt es nicht. Sie vermuten.
@paparazzo - ja, du hast recht. Ich habe die Frage korrigiert. Ich denke wie ein Ingenieur: Wenn ich mir bei etwas zu 95 % sicher bin, ist es nahe genug, um absolut sicher zu sein.
"Wie soll ich vorgehen, wenn ich den Verdacht habe, dass ein Projekt grob überschätzt wird?" - mit Ungläubigkeit. Jedes Projekt seit den Pyramiden wurde grob unterschätzt
Keine Antwort auf Ihre Frage, aber eine sehr wichtige Lektion für die Zukunft. Wenn Ihre Sprache es zulässt, verwenden Sie niemals Standardsprachtypen. Wenn Sie derzeit Hunderte (Tausende?) von uint8_t itemNumber;(ich hoffe, dass sie zumindest unsigniert sind) haben, denken Sie nur, wie einfach die Codeänderung wäre, wenn Sie typedef uint8_t indexNumber_t;. Sie würden einen satten Zeilenwechsel sehen. Jetzt ist es zu spät, ich weiß, aber wenn auch nur eine Person, die seine liest, eine Lektion lernt, ist meine Arbeit hier erledigt (wer war dieser maskierte Mann?)
@Mawg - wir sprechen hier über SQL, aber es unterstützt auch benutzerdefinierte Typen, die auf Standardtypen basieren. Was Sie sagen, macht durchaus Sinn, obwohl einige Datenbanken einige Einschränkungen haben (möglicherweise Verwendung in einigen temporären Tabellen, Verwendung in Indizes usw.). Wie auch immer, in unserem Fall ist das Design wirklich seltsam: Sie haben einen ganzzahligen Wert als numeric/decimal(x, 0) definiert, das ist eine Festkommazahl mit maximal x Ziffern und ohne Dezimalstellen.

Antworten (3)

Ein paar Dinge, die Sie beachten sollten: Betrachten Sie wirklich das Gesamtbild oder nur das, von dem Sie wissen? Sie können sehr gut in einer Position sein, in der Sie nicht wissen, was Sie nicht wissen. Das bedeutet, dass es möglicherweise eine Reihe von Skripten und/oder Anwendungen gibt, die möglicherweise überarbeitet werden müssen. Einige davon könnten eine große Menge an Tech-Schulden enthalten oder einfach „Black Boxes“ sein, da die Entwickler, die sie geschrieben haben, nicht mehr im Unternehmen sind und niemand sie sich jemals zuvor ansehen musste. Es könnte sein, dass sie nicht einmal wissen, was sie nicht wissen, und eine Umgebung aufbauen müssen, um alles zu testen, und selbst dann wissen sie möglicherweise nicht, was alles betroffen sein wird. Ganz zu schweigen davon, ob es kundenorientierte APIs gibt, die versioniert werden müssen, und vielleicht haben sie keine Möglichkeit, das System zu versionieren.

Es könnte eine Menge Dinge sein, dass Sie an diesem Punkt alles nur auf das zu stützen scheinen, was Sie über diese Seite des Geschäfts zu wissen glauben. Haben Sie sie tatsächlich gefragt, warum es so lange dauern wird?

Ja, Sie haben hier einen gültigen Punkt. Es wurde auch eine E-Mail verschickt, um den Aufwand zu begründen, ich werde die Informationen in der Frage ergänzen.

und ich denke, ihre Aufwandsschätzung ist sehr groß.

Können Sie das irgendwie mit Fakten und Daten belegen?

Wie soll ich vorgehen, wenn ich weiß, dass ein Projekt stark überschätzt wird?

Wenn Sie dies sachlich und mit Daten belegen können, wenden Sie sich an Ihren Vorgesetzten . Es liegt an ihnen, was mit den von Ihnen bereitgestellten Informationen zu tun ist. Vielleicht möchten Sie auch überlegen, was Ihre Lösung sein könnte.

Stellen Sie sicher, dass Sie Ihre Behauptung belegen können .

Lassen Sie mich damit beginnen, dass ich im Allgemeinen der Typ bin, der Leuten wie Ihnen die Schätzungen für Projekte wie diese zur Verfügung stellt, und selbst ich bezweifle die Gültigkeit einer 800-Stunden-Schätzung, aber ich würde nicht so weit gehen, sie zu beschuldigen noch maßlos überschätzt . Es gibt einige Dinge, die dazu führen können, dass eine scheinbar einfache Änderung wie diese viel länger dauert und viel komplizierter ist, als es zunächst den Anschein hat (z. B. Datensatzgröße, aktuelle Designbeschränkungen/-mängel, technisches Wissen, technologische Einschränkungen usw.).

Frage: Wie soll ich vorgehen, wenn ich weiß, dass ein Projekt stark überschätzt wird? (und das betrifft mich und mein Team)

Ehrlich gesagt denke ich, dass es absolut erlaubt ist, eine Arbeitsunterbrechung zu verlangen. Möglicherweise finden Sie tatsächlich andere Aufgaben, die Sie in Ihrem Projekt unterbringen müssen, an die noch nicht gedacht oder geplant wurde, und Sie sollten dies als den Grund erwähnen, warum Sie weitere Details benötigen. Menschen hassen es, Ziele zu sein, tragen aber gerne zu einer Lösung bei und haben das Gefühl, dass sie helfen.

Eigentlich sind es 800 Tage. 8-9 Jahre Arbeit für eine einzelne Person. Ich würde gerne die Aufschlüsselung dazu sehen.
Ha! Ich schätze, ich bin jetzt wirklich misstrauisch, aber vielleicht meint die Person, die den Kostenvoranschlag erstellt, Kalendertage statt Arbeitstage? Mein Ansatz ist dennoch derselbe, da er jedem helfen sollte, einem realistischeren Umfang und einer endgültigen Schätzung näher zu kommen.
Wie soll ich vorgehen, wenn ich den Verdacht habe, dass ein Projekt grob überschätzt wird? [geschlossen]
AntwortenHierDatenschutz-Bestimmungen1y, 0v