PM entscheidet sich für ein zu komplexes Setup, mit dem niemand Erfahrung hat [closed]

Vor kurzem habe ich ein Projekt gestartet, das nicht allzu schwierig zu sein schien. Das Konzept war eine ziemlich einfache Anwendung, die hin und wieder Eingaben akzeptieren musste (vielleicht 10x am Tag) und versuchte, einige Operationen an ihnen durchzuführen und alle Ergebnisse zu sammeln Am Ende. Diese Anwendung würde dann ein Front-End-Webportal erhalten, über das die Kunden die Ergebnisse anzeigen könnten, nicht gerade Rocket Science.

Zu diesem ThreadPoolExecutorZweck habe ich zunächst die in Python integrierten Parallelbibliotheken ( ) intelligent genutzt und eine benutzerfreundliche Bibliothek für das Front-End verwendet (ich habe Flask ausgewählt, da es für Anfänger einfach und relativ einfach zu warten und zu testen ist).

Als wir in der Mitte des Projekts waren, gab der Premierminister an, dass wir die Message Queue-Funktionen von Drittanbietern anstelle von Threads verwenden und den Lastenausgleich implementieren mussten. Schließlich passierte es, dass wir schließlich mit Sellerie, Redis, RabbitMQ, Nginx und uWSGI zusammenarbeiteten und eine Reihe anderer großer Drittanbieter, mit denen niemand echte Erfahrung hatte.

Am Ende führte dies zu einer Menge Spaghetti-Code, nicht überprüfbaren Aufgaben (aufgrund der Komplexität der Bibliotheken von Drittanbietern funktionierte das Patchen des Codes nicht einmal) und einer Menge Kopfzerbrechen, da niemand überhaupt wusste, welchen Mehrwert diese Dienste hatten .

Bevor Sie "Ja, Sie sollten diese Dienste nutzen" sagen, denken Sie daran, dass niemand weiß, wie man diese verwendet, oder sogar weiß, was sie tun, abgesehen davon, dass sie rennbedingten Code einführen.

Was soll ich dagegen tun? Zu diesem Zeitpunkt wäre es einfach zu kostspielig, auf das zurückzugreifen, was wir hatten, und der PM ist nicht mehr in der Lage, diese Dienste zu nutzen, obwohl das Endprodukt jetzt schlechter gestellt ist als zu Beginn. Kann man das überhaupt mit ihm besprechen? Bitte ich um mehr zeit Oder die harsche Antwort: Bin ich für meinen Job einfach zu dumm?

Nach der Hälfte des Projekts gab der PM an, dass anstelle von Threads Nachrichtenwarteschlangenfunktionen von Drittanbietern verwendet und ein Lastenausgleich implementiert werden müssen

Dies ist keine angemessene Sache für einen Premierminister, um einseitig zu "behaupten". Zwei Gründe:

1. Konstruktionsentscheidungen sollten von einer technischen Ressource und nur in Reaktion auf NFR getroffen werden . Fragen Sie daher höflich Ihren Premierminister, ob es eine neue NFR gibt und ob Sie Einzelheiten dazu haben könnten.

2. Wenn ein NFR zur Hälfte des Projekts eingeführt wird, sollte dies wahrscheinlich über eine Änderungskontrolle erfolgen . Die Änderungskontrolle ist aus Governance-Sicht sehr wichtig. Dies ist nicht nur eine Eingabe für Ihre Anforderungen, sondern auch eine wichtige Eingabe für die Testfälle von QA, das Bereitstellungs- und Supporthandbuch für den Betrieb und (hier der wirklich wichtige Teil) den Zeitplan des PM . Wenn die neue Anforderung mehr Arbeit einführt, sollte das Entwicklungsteam die Möglichkeit haben, neue Entwicklungsschätzungen mitzuteilen, und der PM muss entscheiden, ob er mit dem neuen Datum leben, mehr Ressourcen hinzufügen oder den eingeführten Stakeholder zurückdrängen kann die NFR.

Wenn nun wirklich ein vertrauenswürdiger NFR vorliegt und es keine Umgehung gibt, ist es möglicherweise auch angebracht, neue oder andere Ressourcen anzufordern, die mit den eingeführten Technologien vertraut sind, oder ein Schulungsbudget für einige Ihrer vorhandenen Ressourcen anzufordern Ressourcen. Es gibt also auch einen Kostenaspekt .

Wenn Sie die Sprache des PM sprechen - Zeitplan und Kosten -, werden Sie meiner Meinung nach mehr Aufmerksamkeit erhalten, als darüber zu sprechen, wie Entwickler das resultierende Design bewerten. Diese Dinge haben echte Auswirkungen.

Ein Premierminister sollte es besser wissen, als solche Dinge im laufenden Betrieb ohne Governance, ohne Kontrollen und ohne Konsens einzuführen. Wenn sie es einfach nicht verstehen, müssen Sie möglicherweise zum Produkt- oder Programmmanagement übergehen, da er die Qualität und den Zeitplan unnötig gefährdet.

Was dumm wäre, ist sich den Tod marschieren zu lassen .

Sie beschreiben, dass Sie das kritische Gefühl verloren haben. Es gibt kein Gefühl der Kontrolle und keinen klaren Weg zurück.

Das Letzte, was Sie tun sollten, ist hart zu arbeiten, den Kopf gesenkt zu halten und leise zu leiden, bis sie schließlich zugeben, dass das Projekt zum Scheitern verurteilt ist.

Was Sie tun sollten, ist sehr gründlich darüber nachzudenken, was Sie zu Recht erwarten dürfen.

Wenn sie möchten, dass Sie Technologien verwenden, die Sie nicht verstehen, sollten Sie mit der Zeit rechnen, um sie zu erlernen. Schäme dich nicht für das, was du nicht weißt. Verwenden Sie Ihre Unwissenheit als Knüppel. Wenn sie verlangen, dass Sie etwas verwenden, fragen Sie warum. Akzeptiere nicht "weil". Akzeptieren Sie keine "modernen Best Practices". Akzeptieren Sie keine Skalierbarkeit, ohne echte, überprüfbare Erwartungen zu haben.

Mit testbar meine ich, sie MÜSSEN Ihnen sagen, wie viele Anfragen pro Tag / Stunde / Minute sie möchten, dass es in der Lage ist, dies zu tun. Machen Sie deutlich, dass Sie beabsichtigen, etwas zu bauen, um dieses System gemäß diesen Spezifikationen zu betreiben.

Auf diese Weise können Sie eine kostenlose 30-Tage-Testversion nutzen, um zu beweisen, dass es sich lohnt, das neueste Wiz-Bang-Produkt zu kaufen, oder sich an das zu halten, was Sie bereits wissen.

Denken Sie jetzt daran. Es sind nicht die Werkzeuge, die den von Rassenbedingungen geplagten Code eingeführt haben. Ihr habt das getan. Sie müssen lernen, wie Sie das getan haben, damit Sie das rückgängig machen können.

Und nein. Es ist nicht zu kostspielig, auf das zurückzugreifen, was Sie hatten. Der Premierminister kann nicht haben, was er will, nur indem er es verlangt. Sie müssen zurückschieben, bis Sie effektiv nutzen können, was der PM will oder beweisen, dass es nicht das ist, was das Projekt benötigt.

Nur dem nachzugeben ist unprofessionell und tödlich für das Projekt.

Ich war hier, Mann. Mehr als einmal. Man fühlt sich dumm. Das ist es wirklich nicht. Du bist einfach verloren.

Sprich mit der PM. Ehrlich. Alles auslegen. Zeigen Sie, dass Sie lernbereit sind, aber nicht mitgenommen werden möchten. Niemals jemals auf Glauben basierendes Design oder Code. Lassen Sie sich von der PM zeigen, wie Sie tun, was sie wollen. Tu nicht so, als würdest du es verstehen, wenn du es nicht tust. Sag nicht, dass es gemacht wird, wenn es nicht so ist. Wenn Sie an etwas glauben wollen, glauben Sie an sich. Sie müssen bereit sein, NEIN zu sagen.

Wenn das nicht funktioniert, polieren Sie den Lebenslauf, weil Sie ihn bald brauchen werden. In gewisser Weise.

Dies sollte eigentlich auf arbeitsplatz.stackexchange.com sein, da das Problem nicht wirklich eine Frage der Softwareentwicklung ist, sondern die Beziehung zum Arbeitsplatz.

Wenn Sie sicher sind, dass Ihre einfache Herangehensweise schnell funktioniert und zu einem guten Ergebnis geführt hätte, ist Ihre PM eine zerstörerische Kraft in Ihrem Unternehmen, die beseitigt werden sollte. Finden Sie heraus, wie Sie die Nachrichten auf ein höheres Niveau bringen können: Dass Ihr Team eine einfache, funktionierende Lösung hatte, die gute Fortschritte gemacht hatte, und aus Gründen, die niemand erklären kann, hat Sie Ihr PM gezwungen, eine viel komplexere Lösung mit einer Vielzahl von Methoden zu versuchen von Tools, die niemand kennt, niemand versteht, niemand weiß, ob sie überhaupt nützlich sind, und diese unergründliche Entscheidung Ihres PM verursachte Ihnen alle Schwierigkeiten und führte dazu, dass das Projekt zu spät kam und nicht funktionierte.

Ohne den Kontext und die Produktstrategie Ihres Managements zu kennen, ist es schwierig, Ihre Frage objektiv zu beantworten.

Hier einige objektive Argumente. Es ist jedoch möglich, dass es nicht das ist, was Sie erwartet haben:

• „ Denken Sie daran , dass niemand weiß , wie diese Produkte zu verwenden , noch “.
• Die Verwendung von nur perfekt bekannten Werkzeugen und Techniken gewährleistet eine hohe Produktivität. Dies wird jedoch die Innovationsfähigkeit erheblich einschränken. In einigen Märkten kann dies für Ihr Produkt tödlich sein. Vor fast 30 Jahren schlug ich beispielsweise vor, mit Windows 3.0 eine neue Version eines CAD-Produkts zu entwickeln, das unter MS-DOS erfolgreich war. Der Produktmanager beanstandete, dass dies keine bewährte Umgebung sei, dass es zu komplex und zu schwer für das Team zu erlernen sei und dass " Windows niemals eine Mainstream-Umgebung sein werde " sein Produkt 2 Jahre später.
• Es ist alles eine Frage von Kosten und Nutzen. Die Kosten für Experimente im Vergleich zu den Vorteilen einer Skalierbarkeit und Bereitstellbarkeit, die von einem Drittanbieter bereitgestellt werden, der Erfahrung mit riesigen Installationen und hoher Arbeitsbelastung hat.
• Die Nachteile des Hinzufügens einer neuen Technologie können bei entsprechender Schulung oder anfänglichem Support / Coaching durch einen erfahrenen Berater behoben werden.

Letztendlich liegt die wirtschaftliche Entscheidung in der Verantwortung Ihres Produktmanagers. Besprechen Sie mit ihm die Vor- und Nachteile, um sicherzustellen, dass er eine fundierte Entscheidung trifft und die zusätzliche Komplexität nicht unterschätzt. Und wenn er auf seinem Weg bleibt, versuchen Sie, Ihr Bestes zu geben: Sie haben nichts zu verlieren und im schlimmsten Fall haben Sie eine neue Technologie in Ihrem Lebenslauf.

Es gibt zwei Ansätze für Bibliotheken von Drittanbietern (und andere Komponenten):

1. Verwenden Sie so viele wie möglich
2. Verwenden Sie so wenig wie möglich davon

Mein Ansatz ist (2). Es hört sich so an, als wäre auch Ihr Ansatz (2), aber der Projektmanager mag den Ansatz (1).

Es gibt drei Möglichkeiten, mit dieser Situation umzugehen. Entweder lassen Sie den PM tun, was der PM will, Sie versuchen, den PM zu überzeugen, den Ansatz für Bibliotheken von Drittanbietern zu ändern, oder Sie stimmen mit den Füßen ab und wählen einen anderen Job aus.

Wenn Sie den PM davon überzeugen möchten, den Ansatz zu ändern, sollten Sie die folgenden Argumente berücksichtigen:

• Zeit zu lernen. Jede externe Bibliothek benötigt Zeit zum Erlernen. In dieser Zeit kann ein kompetenter Programmierer die gewünschte Funktionalität schreiben, insbesondere wenn eine große Bibliothek ausgewählt wurde, um eine sehr einfache Aufgabe zu erfüllen, die in wenigen Hunderten von Codezeilen ausgeführt werden kann.
• Austauschbarkeit.Wenn Sie eine externe Bibliothek haben, wie stellen Sie sicher, dass Sie diese bei einer Unterbrechung der Entwicklung durch eine andere ähnliche Bibliothek ersetzen können? Meine Lösung besteht darin, externe Bibliotheken zu vermeiden, wann immer ich kann und wann immer es nicht machbar ist. Ich schreibe einen einfachen Wrapper, um den gewünschten Teil der Programmierschnittstelle zu abstrahieren. Normalerweise ist die Schnittstelle, die ich möchte, viel einfacher als die Schnittstelle, die die Bibliothek bietet. Dann greift mein Code nur über diesen Wrapper auf die externe Bibliothek zu, was das Ersetzen erleichtert. Das Erstellen Ihrer gesamten Anwendung auf einem Framework ist ein großes No-No. Servlets? Ja, sie sind schon lange hier und bleiben auf absehbare Zeit hier. Template-Engines? Ja, obwohl sie nicht genau austauschbar sind (Sie wählen normalerweise eine aus und bleiben dabei), ist der Wert, den sie bringen, riesig. Wählen Sie also sorgfältig aus - und denken Sie daran, dass Sie beim Wechseln der Template-Engines zwei Template-Engines in derselben Anwendung haben können, in der Regel jedoch nicht zwei Frameworks in derselben Anwendung. Apache Struts? Nein, Frameworks kommen schnell in Mode und verschwinden schnell, und normalerweise können nicht zwei Frameworks in derselben Anwendung vorhanden sein.
• Version Hölle. Wenn Sie eine externe Bibliothek auswählen, müssen Sie diese aktualisieren, um Sicherheitslücken zu vermeiden, und die Aktualisierung kann zu Problemen führen. Gut gestaltete Komponenten (wie Java JRE) sind mit verschiedenen Versionen kompatibel, aber ich habe die Erfahrung gemacht, dass die meisten Bibliotheken Mist sind, weil sie eine riesige Versionshölle auferlegen. Außerdem erfordert Komponente X möglicherweise Z Version 1 und Komponente Y möglicherweise Z Version 2, und Sie können möglicherweise nicht unbedingt Z Version 1 und Z Version 2 in derselben Anwendung verknüpfen.
• Sicherheitslücken. Durch die Auswahl einer externen Bibliothek erhöht sich die Anzahl der leicht ausnutzbaren Sicherheitslücken für Ihre Anwendung. Einige könnten behaupten, dass selbst entwickelter Code der Sicherheit durch Verschleierung gleicht, aber andererseits würde ich sagen, dass dies immer noch eine Form der Sicherheit ist.
• Lizenzprobleme. Jede externe Bibliothek legt für Teile Ihres Programms eine eigene Lizenz fest. Zum Beispiel können GPL-Bibliotheken nicht in Nicht-GPL-Programmen verwendet werden, und LGPL-Bibliotheken erfordern auch die Verteilung des Quellcodes zusammen mit Binärdateien, was erhebliche Bandbreiten in Anspruch nehmen kann.
• Startzeit der Anwendung. Jede große externe Bibliothek verlangsamt die Startzeit Ihrer Anwendung. Indem Sie eine einfache, schlanke Bibliothek im Haus erstellen, können Sie die Startzeit Ihrer Anwendung erheblich verkürzen.
• Speicherbedarf. Wenn für X Y erforderlich ist, für Z A erforderlich ist, für B, müssen Sie gleichzeitig X + Y + Z + A + B im Speicher haben. Wenn Sie nur das Äquivalent von X implementieren, nennen wir es X ', intern benötigen Sie nur X' im Speicher. Und normalerweise ist der Speicherbedarf von X 'geringer als der Speicherbedarf von X.
• Fehlerrisiko. Je mehr Zeilen sich in der externen Komponente befinden, desto höher ist das Risiko, dass Sie auf einen Fehler stoßen, der sich aufgrund der großen Menge an Code, die Sie verstehen müssen, nur schwer beheben lässt. Wenn Sie die Sache im eigenen Haus erledigen, tun Sie dies normalerweise mit weniger Codezeilen (um genau das zu tun, was Sie brauchen, sonst nichts) und damit mit einem geringeren Fehlerrisiko.
• Anpassbarkeit. Wenn ich selbst SQL-Abfragen schreibe, weiß ich, wie die Abfrage aussieht und wie gut sie für ein bestimmtes Datenbankmodul und einen bestimmten Satz von Indizes ausgeführt wird. Wenn andererseits die SQL-Abfrage von einer externen Komponente geschrieben wird, weiß ich nichts über ihre Leistung. Ich habe in einer Firma gearbeitet, in der das Abrufen jeder Webseite mehrere Sekunden dauerte. Ich hatte den Verdacht, dass die von ihnen verwendete Bibliothek im Ruhezustand zu viele Daten automatisch aus der Datenbank abgerufen hat, wenn Sie nur einen Artikel und nicht alle mit diesem bestimmten Artikel zusammenhängenden Artikel benötigten. Ich verließ das Unternehmen, bevor ich die wahre Ursache für die Langsamkeit entdeckte, weil mir der Ansatz, eine große Anzahl vorhandener Bibliotheken zu verwenden, nicht gefiel.

Seien Sie besonders vorsichtig, wenn eine Bibliothek sich selbst als Framework bezeichnet . Dies bedeutet, dass Sie für die Bibliothek Ihre gesamte Anwendung um sich selbst herum erstellen müssen. Im Allgemeinen können nicht zwei Frameworks in derselben Anwendung vorhanden sein. Sie werden miteinander kämpfen, ohne friedlich zusammen zu existieren. Web Development Utility-Bibliothek? Ja, bitte, es gibt zu wenige davon. Wenn ich jemals eine bessere Bibliothek finde als die, die ich jetzt verwende, kann ich die neu gefundene Bibliothek in neuem Code verwenden, während ich weiterhin die alte Bibliothek in altem Code verwende. Webentwicklungs-Framework? Ein großes Hupen NEIN!

Ich denke, Ihr PM zielt auf ein schwer zu verwaltendes System ab, das viele Wartungsarbeiten im laufenden Betrieb erledigt und so Ihr Einkommen sichert.

Persönlich scheinen Sie mit Python nicht klar zu kommen, vergessen Sie Python nur für eine Weile, programmieren Sie ein Jahr lang kein Python, lernen Sie neue Dinge, Sie werden sehen, dass es andere Sprachen gibt, die das Gleiche tun können und wahrscheinlich auch besser.

Wie bereits erwähnt, sollten Sie sich mit den Tools vertraut machen, bevor Sie mit ihnen programmieren. Schlagen Sie vielleicht vor, dass es gut wäre, den erforderlichen Stapel zusammen zu bewerten, basierend auf der Erforschung verschiedener Werkzeuge, die für die Aufgabe geeignet erscheinen. Oder vielleicht fragen, wie er auf diese Liste gekommen ist, er hätte Hilfe von jemandem bekommen können, der auf dem neuesten Stand ist.

Entwickler sollten keine Angst haben, den Umgang mit neuen Bibliotheken, Frameworks, Technologien usw. zu erlernen. Dies ist ein zentraler Bestandteil der Aufgabenbeschreibung eines Entwicklers, und es ist durchaus sinnvoll, dass jemand dem Team vorschlägt, mit Dingen von Drittanbietern zu arbeiten, über die niemand verfügt Erfahrung mit dem Team haben oder sogar verlangen, dass es dies tut, wenn es in der Lage ist, maßgebliche technische Entscheidungen für das Team zu treffen.

Es ist jedoch nicht zu erwarten, dass Sie einfach eine neue Technologie abrufen können (geschweige denn mehrere neue Technologien auf einmal) in Ihrem Stapel und machen Sie Fortschritte. Es sollte eine beträchtliche Zeit eingeplant werden, um die Grundlagen des neuen Ansatzes zu erlernen und ein gutes Design zu finden, um die neuen Teile einzubeziehen, während dessen keine wirklichen Fortschritte beim eigentlichen Produkt zu erwarten sind (von den Personen, die diese Lern- / Designarbeit ausführen) (Dies kann das gesamte Team sein oder auch nicht, aber wenn dies nicht der Fall ist, müssen die Leute, die gelernt haben, Wissen an den Rest des Teams weiterzugeben, wahrscheinlich später mehr Zeit einplanen.) Das sind die Kosten für diese Art von großen Veränderungen. Das Erlernen neuer Technologien gehört zum Job des Entwicklers, ist aber nicht einfach nur zeitsparend.

Es hört sich so an, als wäre das aus der Frage nicht geworden. Die Leute versuchten, gute Implementierungen auf Technologien aufzubauen, die sie selbst nicht verstanden hatten. Natürlich ist der resultierende Code schrecklich.

Versuchen Sie , Ihre Uhr zu überzeugen , dass das Unternehmen wird mehr Zeit brauchen , auf diese zu verbringen. Es wird entweder die Form haben, jetzt anzuhalten, die neuen Technologien zu lernen und zu bewerten, ein gutes Design zu finden und das derzeitige Durcheinander bei der Implementierung zu beseitigen. Oder es wird mehr Zeit für Fehler, Wartung, kostspieligere Entwicklung usw. verschwendet.

Es ist unmöglich zu sagen, ob die in der Frage beschriebenen technischen Optionen (Lastenausgleich, Nachrichtenwarteschlangen usw.) tatsächlich angemessen sind. Ich glaube nicht , dass „niemand im Team Erfahrung mit dieser hat zu arbeiten , bevor“ ist ein guter Grund, unbedingt eine Entscheidung ausschließen, aber es ist erhöht die kurzfristig Kosten ein solche Entscheidung (die das ändern kann " beste "Entscheidung für den Kontext), und wenn Ihr Ministerpräsident dies nicht berücksichtigt und erwartet, dass das Team sofort so produktiv wird, wie erfahrene Leute es tun würden, sollten Sie sich aus diesen Gründen zurückziehen; Sie werden sehr unrealistische Projektpläne aufstellen, was nicht im besten Interesse von jedermann ist.