Wie erklärt man, dass die Stichprobengröße keinen Einfluss auf die Projektlänge hat?

Wir haben große Unternehmensprojekte, bei denen normalerweise Daten aus einer Quellendatenbank in eine Zieldatenbank kopiert und dann eine Reihe zusätzlicher Anwendungen eingerichtet werden, die diese Daten usw. synchronisieren.

Das letzte Projekt enthielt 250.000 Elemente (Datenzeilen). Das nächste Projekt wird nur 4.000 Elemente enthalten. Projektmanager / Geschäftsleute sind der Meinung, dass das Projekt zu 1/10 der Zeit abgeschlossen sein sollte, da es nur einen Bruchteil der Größe des letzten Projekts ausmacht.

Was eine gute Analogie ist, die ich verwenden kann, um zu erklären, dass das Schreiben von Code zum Übertragen von Daten von einem System zu einem anderen unabhängig von der Anzahl der Elemente dieselbe Menge erfordert - das Schreiben für 1 Element oder für 100.000.000 dauert bei einer Programmierung ungefähr genauso lange Perspektive.

Sagen Sie ihnen, es ist wie der Bau einer neuen vierspurigen Autobahn in einen entlegenen Teil des Landes. Unabhängig davon, ob diese Straße von 100 Autos pro Tag oder von 1000 Autos pro Tag genutzt wird, wird der Aufwand für die Erstellung der Straße in etwa gleich sein.

Zugegeben, wenn es 1.000.000 Autos pro Tag unterstützen soll, müssen Sie die Straße etwas robuster machen, aber trotzdem müssen Sie die gleichen Bäume fällen, durch die gleichen Berge schießen und die gleiche Menge nivellieren von Schmutz, und diese Aktivitäten sind so ziemlich feste Kosten, egal wie viele Autos die Straße benutzen.

Geben Sie ihnen einen Taschenrechner und bitten Sie sie, 1238783423 bis 9858238483 hinzuzufügen, wie lange es dauert. Bitten Sie sie dann, 3423 bis 8483 hinzuzufügen, und teilen Sie ihnen mit, dass Sie die Antwort etwa 100000 Mal schneller erwarten.

Sie könnten auch die Menge der Daten erklären (wahrscheinlich) die Länge der Zeit bewirkt die Software nehmen läuft nicht die Entwicklungszeit.

Setzen Sie es in den Manager zu sprechen.

Wenn Sie einen Computer erstellen, um Widgets mit 1 Widgets pro Sekunde zu erstellen, spielt es keine Rolle, ob Sie ihn zum Erstellen von 100 Widgets oder 10000 Widgets verwenden. Der Computer selbst benötigt dieselbe Zeit zum Erstellen.

Der Unterschied liegt in der Laufzeit, nicht in der Build-Zeit.

Alle Managementklassen arbeiten mit solchen Problemen in hypothetischen Widget-Fabriken.

Verwenden Sie keine Analogie. Erkläre es einfach.

• Für eine sehr kleine Anzahl von Artikeln (10?) Ist es am billigsten, manuell zu konvertieren. Schreibe überhaupt kein Programm.
• Für eine kleine Anzahl von Artikeln (100?) Lohnt es sich, ein Programm zu schreiben. Möglicherweise können Sie Einsparungen erzielen, indem Sie einige theoretisch mögliche Permutationen der Daten ignorieren, die jedoch in der Praxis in der kleinen Datenmenge nicht angezeigt werden. Oder erscheinen in so kleinen Zahlen, dass das Programm sie ablehnen kann und sie manuell konvertiert werden können. Es ist möglich, die Daten schnell zu analysieren, um zu überprüfen, ob Eckfälle tatsächlich in den Daten enthalten sind. Wenn sie nicht angezeigt werden, können sie ignoriert werden.
• Sobald Sie diesen Punkt überschritten haben, hat die tatsächliche Größe der Daten keine Auswirkungen mehr. Sie müssen ein seriöses Programm schreiben, das alle möglichen Eingaben verarbeiten kann. Das Programm kann 1.000 Elemente oder 100.000 verarbeiten. Es dauert nur länger zu laufen.

Bildung ist besser als Nachreden :)

Keine wirkliche Analogie, aber ich glaube immer noch, dass es eine gute Möglichkeit ist, mit diesem Argument umzugehen: Zeigen Sie, dass darin ein schwerwiegender Fehler liegt.

Ihr vorheriges Projekt beinhaltete das Kopieren von Daten mit einigen Änderungen.

Wenn ich es richtig verstanden habe, ist das etwas, was ein Team von beispielsweise 100 Buchhaltern in wenigen Monaten tun kann. Warum haben sie dann Softwareentwickler auf das Problem aufmerksam gemacht?

Weil es der von Ihnen erstellten Software egal ist, ob sie 10 oder 10 Millionen Daten verarbeitet (nicht genau, aber ich bezweifle, dass Ihre Manager auf O(n)Komplexität achten ). Somit war es wahrscheinlich billiger, schneller und sauberer (weniger fehleranfällig).

Wenn Sie radikaler sind, können Sie sogar vorschlagen, dass das Software-Team die Buchhalter immer per Hand hinzuzieht, wenn sie nicht mögen, wie schnell sie arbeiten.

Dies hat Ihren Managern das Leben bei der Entwicklung des letzten Projekts erheblich erleichtert. Wenn sie nun die gleiche Logik anwenden müssen, um die nächste Software herauszufinden, ist es auch egal, ob sie mit 10 Millionen oder 4 Millionen funktionieren wird 000 Zeilen vergessen sie plötzlich.

Ich denke, in Ihrem Fall spielen die Manager einfach ein Schätzungsspiel und versuchen, das Team zu einer schnelleren Arbeit zu zwingen, indem sie auf den Unterschied zwischen 4000 und 250000 hinweisen und auf eine gewisse "Schuld" hoffen. Ich könnte mich irren, aber ich habe das schon mal gesehen.

Es ist eine schreckliche Art, ein Team von Programmierern (eigentlich jede Art von Kreativteam) zu managen, und es hilft niemandem.

Ich weiß, dass Sie nach einer Analogie gefragt haben, aber ich denke, das ist die falsche Technik.

Ich glaube, wie andere im Vorbeigehen erwähnt haben, dass Sie betonen müssen, dass die Datengröße die Laufzeit und nicht die Erstellungszeit beeinflusst .
Also, zerlegen Sie es für sie - Sie haben tatsächlich zwei Unterprojekte, das Bauen und das Laufen. Das Bauprojekt sollte (größtenteils) keine Rolle spielen, auf wie vielen Daten es ausgeführt wird, es kommt nur auf die Datentypen an.
Was die Laufzeit angeht, so können sie dies je nach Datengröße berücksichtigen (ohne nicht triviale Fixkosten).

Es ist, als müsste man nach Melbourne fahren - aber zuerst muss man das Auto bauen.
Sicher, nach Sydney zu fahren ist vielleicht schneller - aber das Fahrzeug zu bauen dauert genauso lange.
_{Okay, ich habe dir doch eine Analogie gegeben.}

Vielleicht ein Telefon? Ihr Kunde möchte ein maßgeschneidertes Telefon. Wenn er 0 Anrufe pro Tag oder 100 Anrufe pro Tag tätigt, dauert das Erstellen seines Telefons genauso lange.

Die Daten, die ein Telefon überträgt, entsprechen den Daten, die von Ihrem Programm kopiert wurden.

Ihre Manager scheinen die Entwicklungszeit mit der tatsächlichen Laufzeit des Programms zu verwechseln. Ihr Missverständnis mag jedoch anders sein. Sie können davon ausgehen, dass weniger "Felder" betroffen sind. Nicht nur weniger Datensätze. Wenn es 100000 einzelne Datenfelder gibt, wäre dies ein enormer Entwicklungsaufwand im Vergleich zu nur 10 Feldern. Mehr Mapping-Arbeit von System zu System. In diesem Fall sind sie zwar korrekt, aber es ist immer noch ein konstanter Overhead erforderlich, und Sie können nicht einfach durch die Anzahl der Felder dividieren, um die Zeit zu ermitteln.

Wie ich es beschreiben möchte, haben Daten 2 Dimensionen Länge und Breite. Länge ist die Anzahl der Datensätze, Breite ist die Gesamtzahl der Spalten in allen Tabellen

Wenn Sie jetzt Daten importieren möchten, ist das so, als würden Sie einen Block durch ein Loch führen. Sie müssen ein Loch machen, das groß genug für die kleinste Abmessung ist, und dann den Block durchtragen

jetzt mit 10 Millionen und 10 Tausend ist die kleinste Abmessung immer noch die Breite. Es ist also die Breite, die entscheidet, wie lange es dauert, das Loch zu machen.

Um die Metapher zu vervollständigen, müssen Sie die Daten nur manuell eingeben

Ich importiere jede Woche Hunderte von Client-Dateien.

Eine Sache, die ich festgestellt habe, ist, dass die kleinen Dateien im Allgemeinen länger brauchen, um den Datenimport zu entwickeln, weil:

• Es ist weniger wahrscheinlich, dass sie den Regeln folgen (wir haben Standarddateistrukturen, ich habe noch nie einen kleinen Kunden gesehen, der uns die Daten in dem von uns angeforderten Standardformat gibt, aber große verstehen, warum das wichtig ist).
• Sie neigen dazu, mehr Datenintegritätsprobleme zu haben, insbesondere wenn sie aus einer Excel-Datei stammen und nicht aus einer Datenbank (aus der die großen Dateien stammen), in die bereits Datenintegritätsregeln integriert waren
• Es ist weniger wahrscheinlich, dass sie jedes Mal im gleichen Format bereitgestellt werden.

Wir haben festgestellt, dass wir viel Zeit bei der Entwicklung sparen, indem wir ein übergeordnetes untergeordnetes SSIS-Paket erstellen, das über einen standardmäßigen untergeordneten Prozess verfügt. Alle erforderlichen Manipulationen, um die Daten in Form des Standards abzurufen, können im übergeordneten System durchgeführt werden. Auf diese Weise geht es weniger darum, wie viele Datensätze wir schätzen, sondern darum, wie nah der Standard an der Datei ist, die wir erhalten. Wir bekommen jetzt nicht mehr so ​​viele Beschwerden, wenn die Entwicklung kleinerer Dinge länger dauert, weil sie nicht dem Standard entsprechen.

Das Schreiben eines Programms ähnelt dem Einstellen eines neuen Mitarbeiters. Sie müssen ihnen beibringen, wo sie die Daten finden, was Sie damit tun und wie Sie die Ergebnisse erhalten. Sie müssen sie eine Weile im Auge behalten, um sicherzustellen, dass sie es richtig machen. Es kann etwas länger dauern, sie zu schulen, wenn sie einen komplizierten / wichtigen Job haben oder sehr viel arbeiten werden, aber es dauert eine beträchtliche Menge an Zeit, egal was passiert.

Viele Manager sind mit dem Aufwand für die Schulung eines neuen Mitarbeiters vertraut, daher kann dies für sie sinnvoll sein.

(Die Analogie bricht zusammen, da Ihr neuer Mitarbeiter ein superpowered Roboter ist, der die Arbeit in einer trivialen Zeit erledigen kann, egal wie viele Datensätze Sie auf sie werfen, aber hoffentlich haben Sie bis dahin Ihren Standpunkt klargestellt.)