Was tun, wenn Ihr „scheiterndes“ Projekt tatsächlich „erfolgreich“ ist?

Was würden Sie tun, wenn Sie in einer Situation wären, in der das Projekt, an dem Sie arbeiten, offensichtlich schlecht gebaut ist und in der Zukunft Fehler haben wird, und ein Alptraum zu sein, der gewartet werden muss? sind fröhlich?

Sollte es mich einfach nicht interessieren? Ist es in Ordnung, dass die Kunden nicht einmal realisieren, dass sie eine bessere Anwendung als diese haben könnten?

Ab wann kümmere ich mich nicht mehr darum, es richtig zu bauen und gehe einfach mit dem Fluss?

Wenn die Kunden zufrieden sind, machen Sie etwas richtig. Viele Leute mögen Hot Dogs, ohne zu wissen, wie sie hergestellt werden ...

Wenn die App eine gute Lösung für das Problem ist, Sie jedoch befürchten, dass die Grundlage fehlerhaft ist, finden Sie heraus, wie Sie die Dinge schrittweise verbessern können, und stellen Sie einen Plan auf, um diese Verbesserungen zu implementieren, während Sie das Produkt aktualisieren. Inkrementell ist der Schlüssel: Wenn es Sie juckt, ganze Teile davon neu zu schreiben, wird Ihr Manager zu Recht sagen, dass dies unvernünftig ist. Das Vollkommene kann Feind des Guten sein. Nachsehen Sie sich die Geschichte von jwz an, wie Netscape IE die Führung übernehmen ließ, weil sie Navigator "umschreiben" mussten.

Wenn die Benutzeroberfläche der App selbst ein Durcheinander ist, sind die Kunden möglicherweise immer noch glücklich, weil sie es mit "the hard way" vergleichen und sogar ein fehlerhaftes Programm kann meilenweit besser sein. Sie vergleichen es mit einem Ideal, das Sie sich aufgrund Ihres Hintergrunds und Ihrer Fähigkeiten vorstellen können. Überlegen Sie sich erneut, wie Sie die Dinge schrittweise verbessern können, und werfen Sie dies als Teil des Plans auf.

Hören Sie nicht auf, sich zu sorgen: Sie möchten, dass Ihre Arbeit so gut wie möglich ist. Denken Sie aber auch daran, dass der Kunde Ihre Rechnungen bezahlt und Sie Software für ihn schreiben, nicht für Sie.

Es ist kein Albtraum für sie. Es wird ein Albtraum für Sie und sie scheinen zu glauben, dass Sie wissen, was Sie tun, damit es behoben wird. Würden Sie lieber Leute, die keine Programmierkenntnisse haben, denken, dass Ihre App schlechter ist als sie tatsächlich ist? Dies ist keine Ausnahme. Genieße es, solange du kannst. Du solltest besser hoffen, dass der Client aus dieser App herauswächst. Sie können als Unternehmen so weit in eine andere Richtung gehen, dass dies absolut nutzlos ist. Sie könnten es aus ganz anderen Gründen umschreiben, als Sie denken.

Ich denke nicht, dass Sie jemals aufhören sollten, sich zu kümmern, auch wenn es so aussieht, als hätte das obere Management aufgehört. Ich denke, das Wichtigste, was Sie aus dieser Erfahrung herausholen sollten, ist, sich all die Dinge zu merken und zu dokumentieren, die Ihrer Meinung nach schief gelaufen sind. Das Vermeiden dieser Fehler in der Zukunft wird schließlich erkannt, wenn nicht diese aktuelle Gruppe von Managern, vielleicht die nächste Gruppe von Managern, für die Sie arbeiten.

Ich würde anfangen, Ideen für die nächsten Entwicklungsschritte vorzustellen, die ein Re-Factoring zur Verbesserung der Codequalität beinhalten. Vermeiden Sie es, sich mit technischen Details zu befassen, und weisen Sie darauf hin, wie die von Ihnen vorgeschlagenen Korrekturen fortgesetzt werden Kundenzufriedenheit führen. Seien Sie darauf vorbereitet, Bereinigung mit neuen Funktionen zu kombinieren, da das Management immer nach etwas Neuem zum Verkaufen sucht.

Im Allgemeinen kümmern sich Kunden nicht um die Wartung, bis etwas schief geht. Idealerweise kümmert sich Ihr Unternehmen um die Reputation und möchte diese durch die Pflege des Codes schützen.

Wenn dieses Produkt jedoch als sehr kurzfristig angesehen wird, kann es sein, dass es keinen Mehrwert bietet, wenn Sie es richtig machen. In diesem Fall - suchen Sie nach den billigen Lösungen - die Dinge mit geringem Aufwand, die einen großen Wert für die Vernunft der Entwickler haben.

Das tust du nicht. Sie nutzen den Erfolg, um die Finanzierung / Erlaubnis / das Buy-in zu sichern, und beginnen mit dem Refactoring in Richtung technisch korrekt und wartungsfreundlich. Oder Sie nutzen den Erfolg, um aus der Abteilung "Ich muss die alte Codebasis beibehalten" herauszukommen.

Vielleicht ist Ihre Priorität / Sichtweise falsch.

Das Wichtigste an jedem Softwareprojekt ist, dass es die Anforderungen der Benutzer erfüllt.

Dies ist eine millionenfach wichtigere Tatsache, als der C / S-Designmode zufolge "korrekt" zu sein.

Ja, Sie sollten korrekte Entwurfsmuster verwenden, die Technologie korrekt anwenden usw. usw. aber nur insofern, als es einfacher ist, die Benutzeranforderungen auf robuste und wartbare Weise umzusetzen.

Ein wirklich schlecht geschriebenes System, das tatsächlich ein Geschäftsbedürfnis erfüllt, ist immer besser als ein wunderbar geschriebenes, schön dokumentiertes Stück Code, das niemand verwenden möchte oder hat.

Versuchen Sie, mit den aktuellen Benutzern zu kommunizieren, und fragen Sie sie, welche Aspekte Ihrer Meinung nach verbesserungswürdig sind. Dann könnten Sie einige Aspekte verbessern, die Ihrer Meinung nach verbesserungswürdig sind, und Sie könnten auch die von den Benutzern vorgeschlagenen Aspekte verbessern. Sie können Ihre Verbesserungen als "erforderlich für die Implementierung der vom Benutzer vorgeschlagenen Verbesserungen" begründen.

Zum Beispiel: Wenn Benutzer denken, dass die Suchfunktion langsam ist. Sie können dies verbessern, indem Sie eine bessere Datenebene erstellen, die offensichtlich mehr als nur der Suche dient, aber Sie können dann die aufgewendete Zeit begründen.