Wie gehe ich mit dem Management von Altsystemen um?


14

Ich bin derzeit in einem bezahlten Praktikum und habe die Aufgabe, ein veraltetes System zu warten, das in den letzten 5 Jahren von mehreren Entwicklern (zu unterschiedlichen Zeiten) entwickelt wurde. Das Management stimmt zu, dass das "System lebenserhaltend ist", und ich erhalte regelmäßig Fehlerberichte von Endbenutzern, die das System derzeit verwenden.

Das Management will das Projekt nun um ein weiteres Jahr verlängern und dabei die Nutzerbasis nahezu verdreifachen.

Wie kann ich als Praktikant (oder als Anfänger) "zurückschieben"? Ich habe bereits einen Bericht geschrieben, in dem meine Bedenken dargelegt werden, allerdings in einem unbefristeten Dokument. Gibt es ein Protokoll oder einen Dokumenttyp, um Änderungen vorzuschlagen? Bin ich in der Lage, Vorschläge zu machen, oder sollte ich einfach weiterhin das alte System unterstützen?

  • Die Softwareentwicklung ist nicht das Hauptgeschäft meines Unternehmens. Als solche existieren keine internen Protokolle. Darüber hinaus verfügt das Projekt über keinerlei formale Dokumentation und auch keine Anforderungsdokumente. Die Entwicklung ist sehr ad hoc.

6
Ich sympathisiere mit Ihrem Problem. Leider gibt es keinen einfachen Weg, und ich bin sicher, dass Ihre Frage zuvor auf viele verschiedene Arten gestellt wurde. Eine Sache, die ich empfehlen würde, ist zu vermeiden, einen Bericht mit "offenen" Bedenken zu schreiben. Manager (insbesondere nicht-technische) HASSEN es , ob sie es direkt sagen oder nicht. Wenn Sie sich über etwas beschweren, müssen Sie konkrete und praktische Empfehlungen abgeben, um es zu verbessern.
Angelo

3
@ James, das Format des Dokuments ist in Ihrem Kontext völlig irrelevant. Was zählt, ist, dass Sie 1) die Änderungen identifizieren, die Sie vornehmen müssen, 2) einen konkreten Plan für deren Umsetzung beschreiben und 3) die Beteiligten überzeugen, dem Plan zuzustimmen. In einer Umgebung, in der die Dinge "ad-hoc" sind, bedeutet formale Dokumentenstruktur nichts.
Angelo

7
Sofern sich kein Ersatzsystem in der aktiven Entwicklung befindet, würde ich argumentieren, dass das derzeitige nicht "auf Lebenserhaltung" basiert. Vor allem, wenn das Unternehmen es in zukünftige Pläne miteinbezieht.
TMN

7
Seit wann ist ein 5 Jahre altes System "Legacy"?
Marjan Venema

1
@ James - Das ist nicht die Definition eines Legacy-Systems. Vermächtnis wird dadurch definiert, dass eine (eindeutig) neuere oder effizientere Technologie verfügbar ist, nicht das Scheitern interner Prozesse oder die Mitarbeiterbindung.
Jon Hopkins

Antworten:


23

Ich bin derzeit in einem bezahlten Praktikum und habe die Aufgabe, ein veraltetes System zu warten, das in den letzten 5 Jahren von mehreren Entwicklern (zu unterschiedlichen Zeiten) entwickelt wurde. Das Management stimmt zu, dass das "System lebenserhaltend ist", und ich erhalte regelmäßig Fehlerberichte von Endbenutzern, die das System derzeit verwenden.

Das System ist nicht veraltet, wenn es noch verwendet wird, und es unterstützt die Geschäftsaktivitäten. Da es immer noch verwendet wird, kann das Unternehmen es nicht einfach wegwerfen - es muss solange unterstützt werden, bis das System nicht mehr benötigt wird. Dies kann eine Änderung der Geschäftsziele sein, oder es wurde ein neues System entwickelt, getestet und erfolgreich für die Endbenutzer bereitgestellt.

Wirklich, 5 Jahre sind nicht so lang. Ich habe mit Code gearbeitet, der 10 Jahre alt war. Wenn es immer noch den Bedürfnissen des Benutzers dient, warum sollte es dann weggeworfen werden? Das wirft eine Menge Geld weg, um es zu entwickeln. Solange eine Wartung aufgrund steigender Kosten oder sich drastisch ändernder Anforderungen nicht möglich ist, gibt es keinen geschäftlichen Grund, sie wegzuwerfen.

Das Management will das Projekt nun um ein weiteres Jahr verlängern und dabei die Nutzerbasis nahezu verdreifachen.

Wenn das Management feststellt, dass dieses System lebenserhaltend ist, warum versuchen sie es dann weiter zu implementieren? Es ist üblich, dass Wartungsaktivitäten auf einem Altsystem fortgesetzt werden, bis es ersetzt wird. Wenn sich ein System jedoch am Ende der Lebensdauer befindet, wird es in der Regel nicht mehr für mehr Personen bereitgestellt. Das Verlängern der Wartung ist eine Sache, aber das Hinzufügen von Benutzern, die sich auf das System verlassen, ist insgesamt eine andere Situation.

Für mich hört sich das so an, als wäre es nicht das Ende der Lebensdauer, sondern eine Wartungsphase, die so lange andauert, bis das System die Anforderungen der Benutzer nicht mehr erfüllt.

Wie kann ich als Praktikant (oder als Anfänger) "zurückschieben"? Ich habe bereits einen Bericht geschrieben, in dem meine Bedenken dargelegt werden, allerdings in einem unbefristeten Dokument. Gibt es ein Protokoll oder einen Dokumenttyp, um Änderungen vorzuschlagen? Bin ich in der Lage, Vorschläge zu machen, oder sollte ich einfach weiterhin das alte System unterstützen?

Sie müssen das alte System weiterhin unterstützen. Später erwähnen Sie, dass Software nicht das Hauptgeschäft Ihres Unternehmens ist. In einem solchen Umfeld besteht die Aufgabe von Software-Teams darin, das Hauptgeschäft des Unternehmens zu unterstützen. Die Software-Teams müssen jedoch auch die Geschäftsziele im Auge behalten.

In der Zwischenzeit sollten Sie Ihre Vorschläge auf eine Weise festhalten, die nicht überheblich ist. Weisen Sie auf andere Technologien oder Techniken hin, die in das System integriert sein oder verwendet werden können, wenn ein neues System erstellt wird, und auf deren Vor- / Nachteile. Wie Sie dies tun, hängt vom Unternehmen ab, aber wenn Sie einige spätere Punkte berücksichtigen, ist es möglicherweise hilfreich, ein Wiki oder eine andere Website für die Zusammenarbeit einzurichten.

In einem Nicht-Software-Geschäft sind Softwarekosten und die Softwareteams (insbesondere die Softwareprojekt- / Programmmanager) sollten daran arbeiten, die Kosten für die Erstellung und Wartung von Softwaresystemen so gering wie möglich zu halten und gleichzeitig die Anforderungen der Endbenutzer zu erfüllen . Das Wegwerfen von Software, die (soweit ich das beurteilen kann) den Bedürfnissen der Benutzer entspricht, verstößt gegen das, was im besten Interesse des Softwareteams liegt.

* Zur Verdeutlichung ist die Softwareentwicklung nicht das Hauptgeschäft meines Unternehmens. Als solche existieren keine internen Protokolle. Darüber hinaus verfügt das Projekt über keinerlei formale Dokumentation und keine Anforderungsdokumente. Die Entwicklung ist sehr ad hoc.

Für mich ist das das Problem. Das Fehlen einer Dokumentation, das Entwickeln nach einer Spezifikation und ein Mangel an Konsistenz erhöhen tendenziell die Kosten für die Entwicklung von Software. Es wäre meine höchste Priorität, darauf hinzuarbeiten, dies zu beheben, und ich würde dies tun, indem ich an Dingen wie einem Codierungsstandard, einer Versionskontrolle, der Erstellung von selbstdokumentierendem Code und Designdokumenten, der Fehlerverfolgung und Anforderungsspezifikationen arbeite.


9
I've worked with code that was 10 years old before Wie wäre es mit 25 Jahren :) Erfüllte immer noch die Anforderungen des Unternehmens und leistete hervorragende Arbeit, obwohl das Berühren des Codes ungefähr so ​​angenehm war wie das Schwimmen in der Arktis.
maple_shaft

@maple_shaft Nichts 25 Jahre alt. Ich glaube, der älteste Code, den ich je gesehen habe, war ungefähr 10-15 Jahre alt. Es ist nicht angenehm, aber der Benutzer kümmert sich nicht um sauberen Code. Sie legen Wert darauf, Software zu verwenden, die das tut, was sie benötigt, um das Geschäft zu unterstützen.
Thomas Owens

1
@ James Nicht wirklich. Wenn es sich um eine Softwareverbesserung oder einen Softwarefehler handelt, für den einige Änderungen am vorhandenen System erforderlich sind, wird dies in einem Fehlerverfolger nachverfolgt, wo es priorisiert und zugewiesen wird. Wenn es sich um einen Prozess, eine Methodik oder einen Hinweis für ein zukünftiges Projekt handelt, wird dies entweder durch ein Machbarkeitsprojekt erfasst, in dem die Lösung als Prototyp erstellt wird, oder durch ein technisches Memo.
Thomas Owens

1
Ich arbeite an einem 15 Jahre alten System und es ist eine Freude. Ja, es gibt Teile, die einer Verbesserung bedürfen, aber dies können alte Teile oder Teile sein, die vor nur sechs Monaten geschrieben wurden. Wie bei Menschen: Das Alter ist unbedeutend. Es ist die Sorgfalt, die bei der Entwicklung der Software aufgewendet wurde, und wie viel technische Schulden bei dieser Entwicklung entstanden sind, die bestimmt, wie viel oder wie wenig Freude Sie daran haben können.
Marjan Venema

1
@ James Der SRS ist technisch. Wenn Sie direkt mit dem Management zu tun haben und die Softwareentwicklung nicht das Hauptgeschäft des Unternehmens ist, müssen Sie dies geschäftlich ausdrücken. Da es keine Projektdokumentation usw. gibt, beginne ich mit einem Business Case oder Projektplan oder einer Optionsanalyse für das Reengineering vor einem SRS. Eine Sache, die Manager und Unternehmen verstehen, sind die Kosten. Ein vollständiges Umschreiben kann schwierig sein, seien Sie also vorsichtig.
Jason S

7

Ich habe bereits einen Bericht geschrieben, in dem meine Bedenken dargelegt werden

Gut. Das ist ungefähr das Ausmaß dessen, was Sie als Praktikant tun können. Zum späteren Nachschlagen beim Verfassen solcher Berichte lege ich Wert darauf, harte Fakten unvoreingenommen und professionell darzustellen, ohne emotionale Vorurteile. Sie wissen nicht, wer den Bericht lesen wird, möglicherweise jemand, der einige der von Ihnen beschriebenen Probleme verursacht hat oder nicht, oder der Entscheidungen getroffen hat, die zu diesen Problemen geführt haben. Alles andere als kalte Tatsachen könnten von solchen Leuten als Affront oder Beleidigung aufgefasst werden und dazu führen, dass sie Sie nicht mögen und möglicherweise nichts davon ernst nehmen.

Das Management will das Projekt nun um ein weiteres Jahr verlängern und dabei die Nutzerbasis nahezu verdreifachen

Denken Sie daran, dass solche Geschäftsentscheidungen getroffen werden, weil sie versuchen, die ihnen zur Verfügung stehenden Ressourcen zu nutzen. Ich bin mir sicher, dass das Management die Probleme mit der alten Software und die Beschwerden der Benutzer wahrscheinlich kennt. Verfügen sie jedoch über die verfügbaren Ressourcen für die Softwareentwicklung, um das Refactoring oder ein Umschreiben zu bewältigen?

Meistens ist dies nicht der Fall, insbesondere wenn Software nicht das A und O des Unternehmens ist und die Qualität und die Zufriedenheit der Benutzer mit der Software keinen direkten Einfluss auf das Geschäftsergebnis haben. Solche Entscheidungen zu treffen ist manchmal der Grund, warum Manager scheiße sind, weil Sie sich häufig in einer Situation befinden, in der Sie verlieren, egal was Sie tun.

Aufrechterhaltung eines veralteten Systems, das in den letzten 5 Jahren von mehreren Entwicklern (zu unterschiedlichen Zeiten) entwickelt wurde

Während des gesamten Projekts wurden Fehler gemacht, die zu diesem Punkt führten. Mangelnde solide Benutzereingaben oder Anforderungen, mangelnde ordnungsgemäße Produktverwaltung und Änderungskontrolle zur Verwaltung sich ändernder Anforderungen und Bedürfnisse sowie fehlende technische Ressourcen zur Implementierung verursachten die Probleme, wie sie heute existieren. Ich weiß aber nicht, ob veraltet das richtige Wort ist. Ist die zugrunde liegende Technologie auf nicht unterstützten Frameworks und Technologien aufgebaut, oder handelt es sich einfach nicht um die neuesten oder idealen Technologien?

Wie kann ich als Praktikant (oder als Anfänger) "zurückschieben"?

Sie sind in einer Position der geringsten Macht und Sie sind dabei vorübergehend. Es ist egal, ob Sie Recht haben, ich würde nicht erwarten, dass ein Praktikant mich jemals "zurückdrängt". Ich erwarte, dass sie lernen, Probleme besprechen, wenn sie sie sehen, und Anweisungen befolgen. Das ist alles. Sobald ein Auftrag erteilt wurde, erwarte ich, dass er nach besten Kräften ausgeführt wird, da die Zeit für Diskussionen zu diesem Zeitpunkt abgelaufen ist.


Vielleicht war die Verwendung des Begriffs "Vermächtnis" falsch. Derzeit ist die Technologie, die das System antreibt, VBA und klassisches ASP. Die Codebasis wurde in der Vergangenheit von mehreren rotierenden Praktikanten erstellt. Wikipedia identifiziert ein Altsystem als eines, das nicht mehr verstanden wird. Solche Situationen treten auf, wenn das System nicht dokumentiert ist und / oder die ursprünglichen Entwickler das System verlassen haben. Außerdem steht "Zurückschieben" in Anführungszeichen, weil ich ein persönliches Motto habe: "Geben Sie sich niemals mit Mittelmäßigkeit zufrieden", und als solches kann ich mich nicht zurücklehnen und keine Bedenken äußern. Ich habe das Gefühl, nicht hilfreich zu sein
James

@James Es ist gut, Bedenken auszusprechen, aber mach es einmal, mach es komplett, präsentiere eine gangbare Alternative und lass es dann dabei. Wenn Sie sich mehr als einmal zu demselben Thema äußern, werden Sie als Jammern wahrgenommen, und Jammern sind nicht hilfreich. Wenn Sie es nicht verstehen und niemand im Haus es wirklich technisch versteht, dann ist es in der Tat Vermächtnis, dass Sie Recht haben.
maple_shaft

7
James, es mag sein, dass Sie mit der Mittelmäßigkeit nie zufrieden sind, aber aufgrund dieses Austauschs erwecken Sie den Eindruck, dass Sie das Gesamtbild, wie Software das Geschäft unterstützt und welche Geschäftsprioritäten sich von Ihren unterscheiden, nicht gut verstehen.
Versuch

2
"Wikipedia identifiziert ein Altsystem als ein System, das nicht mehr verstanden wird". Nun, wenn Sie es verstehen und dokumentieren, so wird es verstanden, dann wird es kein Legacy-System mehr sein.
DJClayworth

2
"Geben Sie sich niemals mit Mittelmäßigkeit zufrieden" ist ein gutes Motto, aber es gilt nur für Dinge, die Sie selbst kontrollieren können. Wenn Sie eine mittelmäßige Codebasis verwenden und diese in eine gut dokumentierte, einfach zu wartende Codebasis verwandeln, ist dies eine hervorragende Arbeit, auf die Sie stolz sein sollten.
DJClayworth

5

Du bist ein Praktikant. Ich bezweifle sehr, dass Sie mit den alltäglichen geschäftlichen Erfordernissen als Ganzes auch nur annähernd vertraut sind, und wie andere Leute bemerkt haben, ist eine 5 Jahre alte Codebasis nicht wirklich so alt.

Entscheidungen über den Austausch von Altsystemen sind nicht immer technisch bedingt. Sie basieren auf sich ändernden Geschäftsanforderungen. Eingaben in diese können Schwierigkeiten im Zusammenhang mit der Wartung sein; Aber am Ende des Tages müssen Sie erkennen, dass Ihre Position nicht unbedingt bedeutet, dass Sie über alle verfügbaren und erforderlichen Kenntnisse verfügen. Ich würde so weit gehen zu sagen, dass Sie tatsächlich nur sehr wenig über das erforderliche Wissen verfügen, um den Anruf bei dem derzeit besten Schritt zu tätigen.

Mein Rat an Sie lautet: Lernen Sie aus den Erfahrungen und hören Sie auf, davon auszugehen, dass Ihr Wissen das der Menschen übertrifft, die das Geschäft tagtäglich führen müssen.

Ihre Aufgabe ist es, das System am Laufen zu halten und keinen glänzenden neuen Ersatz vorzuschlagen.

Es scheint mir, dass viele junge Programmierer nicht erkennen, dass die Wartung älterer Systeme einen größeren Teil der Programmierarbeit ausmacht als das Entwerfen glänzender neuer Systeme.


Ich glaube, Sie behaupten zu Recht, dass ich das Gesamtbild nicht verstehe, da ich mit dem mit der internen Softwareentwicklung verbundenen Overhead nicht vertraut bin. Die Ausbildung, der ich bisher ausgesetzt war, befasste sich hauptsächlich mit formalen Prozessen oder zumindest mit Softwareentwicklung als Hauptgeschäft
James,

4

Schieben Sie nicht zurück. Das einzige, was Sie tun sollten, ist Ihre Bedenken klar und präzise auszudrücken. Tatsache ist, dass die meisten Unternehmen, in denen Sie in Zukunft arbeiten werden, über Legacy-Systeme verfügen. Diese Altsysteme müssen gewartet werden, da in vielen Fällen ein Austausch zu teuer ist.

In vielen Fällen haben Sie vielleicht sogar die besten Absichten, das aktuelle System durch ein besseres System zu ersetzen. Sie können jedoch nur neue und andere Fehler einführen. Wenn Sie das System verlassen, wird es schnell wieder zu einem Altsystem, und das Unternehmen wird es sei an der gleichen Stelle wie zuvor. Nichts ist veraltet, bis es seinen Zweck nicht mehr erfüllt oder vollständig mit modernen Systemen nicht kompatibel ist. Meine Firma hat ein über 20 Jahre altes System, das wir gerade auf ASP.NET umstellen. Das System läuft noch, aber die Unterstützung für die alte Technologie schwindet und die Arbeit mit modernen Webbrowsern wird immer zeitaufwendiger.

Was du tun kannst:

Lassen Sie die Dinge sauberer

Wenn Sie etwas warten, lassen Sie es sauberer als zu Beginn. Beheben Sie das Problem, aber bereinigen Sie es auch, damit es beim nächsten Mal leichter verständlich wird, wenn jemand Änderungen vornehmen muss.

Dokumentation erstellen

Wenn die fehlende Dokumentation ein Problem darstellt, erstellen Sie die Dokumentation. Wenn Sie an einem bestimmten Teil des Systems arbeiten, dokumentieren Sie ihn.

Mach es weniger schmerzhaft

Wie ich bereits sagte, können Sie Ihre Bedenken äußern, aber Ihr Bestes geben, indem Sie fleißig am System arbeiten und es besser machen, für die nach Ihnen zu arbeiten. Beheben Sie die Fehler richtig. Dokumentieren. Ausbreitungscode riecht. Mache es besser. Und wenn Sie diese Dinge tun, teilen Sie dies Ihren Vorgesetzten mit. Sagen Sie ihnen, dass Sie X, Y und Z tun, um den Entwicklungsprozess zu verbessern. Das stärkt die Glaubwürdigkeit und wird Ihnen und Ihrem Unternehmen auf lange Sicht mehr als alles andere helfen.


1
Eines der wichtigsten Dinge, die als X, Y oder Z ausgeführt werden können, ist das Schreiben von Komponententests. Durch Tests wird die Arbeit mit Legacy-Code, der jederzeit in irgendeiner Weise fehlerhaft sein kann, viel stressfreier.
Kevin Vermeer

3

SIE NICHT !!! Dies ist eine großartige Gelegenheit!

Du bist ein Praktikum zum Lernen! Dieses Projekt ist eine echte Welt, wie es nur geht.

Sie haben großes Glück, es zu haben. Die Tatsache, dass Sie nicht qualifiziert sind, ist nicht Ihr Anliegen. (Wenn das Management dies merkt, haben Sie eine ganze Menge gewonnen.)

Wenn Sie mit diesem Praktikum fertig sind, werden Sie qualifiziert sein. Und das sind großartige Neuigkeiten.

PS: Machen Sie Backups religiös, stellen Sie sicher, dass ALLES, was Sie tun, rückgängig gemacht werden kann. Beginnen Sie mit den Problemen, bei denen es sich um "einfache Lösungen" handelt. Die Benutzer haben jedoch große Probleme. Mach kleine Schritte.


Das andere, wofür sich Praktika eignen, ist die Entscheidung, ob Sie für ein Unternehmen arbeiten möchten oder nicht, und (für sie), ob sie möchten, dass Sie für sie arbeiten. Dies ist eine viel bessere Situation, als wenn das OP als Vollzeitbeschäftigter angestellt worden wäre und besorgt wäre, den ersten Arbeitsplatz zu behalten oder schnell zu gehen.
Kevin Vermeer

3

In einem sehr theoretischen Sinne gibt es wohl kein so genanntes Legacy-System . Ich habe ein sehr altes Telefon (ein altes System) und heutzutage gibt es gute Android-Telefone (moderne Plattformen), aber mein Telefon funktioniert und macht das, was ich brauche. Warum sollte ich das wegwerfen?

Alle Systeme, die Sie heute als "Legacy" bezeichnen, waren eines Tages auf dem neuesten Stand der Technik. Es ist nur die Zeit, die wir brauchen. Auch wenn umfangreiche Arbeiten vorhanden sind, bedeutet dies nicht, dass das gesamte Material auf modernen Plattformen erneut ausgeführt wird, sondern dass es automatisch fehlerfrei (oder schmerzfrei) ist.

Folgendes empfehle ich Ihnen:

  1. Lassen Sie zuerst Ihre Abneigung gegen "Legacy-System" hinter sich. Dies macht Sie sehr kontraproduktiv.

  2. Beginnen Sie zu dokumentieren, was Sie jetzt tun und was Sie denken. Wenn auch Schritt für Schritt. Es gibt keinen besseren Zeitpunkt für die Dokumentation als den, bei dem Sie feststellen, dass Sie einen benötigen.

  3. Anstatt zu versuchen, die Weiterentwicklung des "Legacy-Systems" zurückzudrängen, sollten Sie versuchen, den Pfad für dessen reibungslosen Abschluss zu definieren. Versuchen Sie zu sehen, dass Sie das Management davon überzeugen können, dass neuere Entwicklungen, die isoliert werden können, Schritt für Schritt auf neueren Plattformen durchgeführt werden können, ohne die Interoperabilität mit alten Systemen zu beeinträchtigen. Wenn sich die Dinge weiterentwickeln (und das wird sehr langsam sein), würde die Notwendigkeit, das Altsystem beizubehalten, verschwinden. Nur so kann man sich von einem alten System verabschieden.

Dipan.


2

Die Wahrheit ist, dass niemand Praktikanten die Arbeit gibt, die sie tun möchten. Wenn Sie die jüngste Person sind, bekommen Sie die am wenigsten aufregende Arbeit. Wie gut Sie persönlich damit umgehen, sagt der Organisation viel darüber aus, ob sie darauf vertrauen können, dass Sie mehr für die aufregende Arbeit tun.

Hier ist also eine unbezahlbare Gelegenheit, um zu zeigen, dass Sie durch das Durchführen von Fehlerkorrekturen liefern können, dass Sie die Umgestaltung durchführen können, indem Sie jeden Teil des Codes, den Sie berühren, ein wenig besser machen, dass Sie Komponententests erstellen können, indem Sie damit beginnen, sie für dieses System zu erstellen und dass Sie dokumentieren können, indem Sie eine Dokumentation für die nächste arme Seele erstellen, die in diesem System steckt. Sie haben auch die Möglichkeit zu zeigen, dass Sie effektiv mit Benutzern umgehen können (um detailliertere Informationen zu gemeldeten Fehlern zu erhalten) und deren Anforderungen zu erfüllen. Befindet sich das Projekt nicht in der Quellcodeverwaltung, legen Sie es dort ab. Wenn die Fehler nicht in einem Bug-Tracker verfolgt werden, starten Sie einen. Diese Arten von Aktionen zeigen Ihnen, wie Sie professionell arbeiten.

Oder Sie gehen den umgekehrten Weg und schimpfen nur darüber, wie schlecht das Projekt ist und wie cool es wäre, es zu ersetzen. In diesem Fall wird Ihnen nach Ihrem Praktikum mit ziemlicher Sicherheit keine Stelle in diesem Unternehmen angeboten.


1

Sie haben wahrscheinlich nicht genügend Informationen, um zu bestimmen, ob ein weiteres Jahr kostengünstig ist oder nicht. Es wäre interessant, das Unternehmen und die Gründe für das Hinzufügen von Benutzern zu verstehen. Es scheint, als ob ein gewisses Wachstum im Gange ist und sie es sich einfach nicht leisten können, finanziell oder unter bestimmten zeitlichen Einschränkungen einen Schritt zurückzutreten, um eine neue App zu erstellen. Das Erstellen einer neuen App ist sowieso selten die beste Wahl. 5 Jahre sind nicht so alt, es sei denn, sie haben es auf alten Technologien aufgebaut.

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.