Soll ich meinem Team/Manager mitteilen, dass die aktuelle mobile Anwendung schlecht ist?

Ich denke, etwas zu sagen ist eine gute Idee, aber wie du es sagst, wird genauso wichtig sein wie das, was du sagst.

Wie Sie in Ihrer Frage geschrieben haben, wollen Sie Ihr Team nicht schlecht machen (was ausgezeichnet ist), und ich bin sicher, Sie werden nicht hineingehen und einfach sagen: „Die App ist scheiße, sehen Sie sich meine Version an, die großartig ist, und ich habe sie geklopft bis in ein paar Wochen", aber Sie möchten wirklich jeden Ansatz vermeiden, der so interpretiert werden könnte.

Sie müssen bedenken, dass es einige große potenzielle Faktoren und Herausforderungen gibt, die dazu beigetragen haben könnten, dass die bestehende App so lange braucht, um sich zu entwickeln und zu funktionieren und so auszusehen, wie sie es tut, von denen Sie viele noch nicht gesehen haben in deinem umschreiben:

1. Erfahrung – Es hört sich so an, als hätten Sie bereits Erfahrung mit der Entwicklung mobiler Apps, und es hört sich so an, als ob dies bei den Entwicklern, die die vorhandene App geschrieben haben, nicht der Fall war. Ich habe im Laufe der Jahre eine Menge nicht großartigen Code geschrieben, von dem ich weiß, dass ich ihn aus dem Park hauen würde, wenn ich zurückgehen und ihn jetzt noch einmal machen würde.

2. Stakeholder – Sie hatten keine, Sie haben in einem Vakuum gearbeitet und sich nur selbst verantwortet, während die ursprünglichen Entwickler wahrscheinlich an den Anforderungen und Vorlieben der Personen gearbeitet haben, die das Projekt vorantreiben. Diese schreckliche Benutzeroberfläche, die Sie hassen? Es ist wahrscheinlich schrecklich - aber seine Schrecklichkeit hätte leicht von Stakeholdern und Produktbesitzern beharrt werden können (Sie sollten einige der absoluten Abscheulichkeiten sehen, die ich im Laufe der Jahre produzieren musste, weil es der PO oder einem Direktor so gefiel). Das Gleiche gilt für funktionale Anforderungen – Sie kannten von Anfang an einen vollständigen Funktionsumfang, da Sie eine vorhandene vollständige App hatten, mit der Sie arbeiten konnten. Beim ursprünglichen Entwicklungsprozess ging es höchstwahrscheinlich sowohl darum, herauszufinden, was sie tun sollten, als auch darum, es zu tun.

Grundsätzlich müssen Sie ihnen etwas Nachsicht einräumen und ihnen den Vorteil des Zweifels geben, dass sie unter schwierigeren Umständen ihr Bestes gegeben haben, als Sie es erlebt haben, und dies während des Gesprächs im Hinterkopf behalten.

Wie gehen Sie also vor?

Mit einem Wort – bescheiden würde ich ein persönliches Treffen mit Ihrem Vorgesetzten vereinbaren und ihm erklären, dass Sie nach dem Betrachten der bestehenden App während der letzten Arbeiten der Meinung waren, dass es eine nützliche Übung wäre, sie in Ihrer Freizeit neu zu erstellen ( stellen Sie sicher, dass Sie diesen Teil betonen – Sie möchten nicht so gesehen werden, als würden Sie Ihre zugewiesene Arbeit vernachlässigen) als eine Möglichkeit, Ihre eigenen Fähigkeiten in der Entwicklung mobiler Apps zu verbessern, und dass Sie Ihren Vorgesetzten bitten möchten, einen Blick darauf zu werfen, um zu sehen, was er davon hält und ein Feedback bekommen. Wenn Ihre Version eine so große Verbesserung ist, wie Sie sagen (und ich habe keinen Grund, an Ihnen zu zweifeln), dann wird dies für sich sprechen, wenn sie sie verwenden und sich den Code ansehen. Wenn sie die Unterschiede in der Benutzeroberfläche kommentieren, sagen Sie, dass Sie so sindes nach freiem Ermessen getan hätte, und dass Sie verstehen, dass es nicht unbedingt mit dem Aussehen und Verhalten der App übereinstimmen muss, die das Unternehmen haben möchte. Wenn sie den Code-Unterschied kommentieren, sagen Sie, dass Sie so gearbeitet haben, wie es Ihnen beigebracht wurde, aber dass Sie offen für Vorschläge sind, wie es besser sein könnte.

Bitte beachten Sie, dass ich nicht behaupte, dass Ihre Version schlechter ist als die vorhandene - Sie argumentieren ziemlich gut, dass Ihre Version besser ist, und ich habe keinen Grund, an Ihnen zu zweifeln. Diese Demut ist im Wesentlichen eine Möglichkeit, nicht arrogant zu wirken – was nicht gut aussieht, besonders wenn Sie noch keine Erfolgsbilanz im Unternehmen haben, um dies zu belegen.

Rufen Sie sie nicht an, was Sie tun würden. Stellen Sie stattdessen Fragen.

„Warum ist die Benutzeroberfläche so? Wäre es nicht üblicher, ____ zu machen?“

„Ich wette, wir könnten viel stabileren Code bekommen, wenn wir _____ machen würden“

Die traurige Tatsache ist jedoch, dass Sie 23 Jahre alt sind. 4-5 Jahre mögen Ihnen viel erscheinen, aber es ist wirklich nicht, wenn Sie bedenken, dass einige von uns es seit über 30 Jahren tun. Da Sie erst 23 Jahre alt sind, Ihre Ideen werden eher entlassen. Deshalb schlage ich den Ansatz der bescheidenen Suggestion vor. Formulieren Sie Fragen so, dass sie sie dazu zwingen, sie zu erklären, ohne wirklich herauszufordern oder konfrontativ zu sein.

Sollte ich erwähnen, dass es der Anwendung an UI-Design und Codequalität mangelt? Wenn ja, an wen?

Ich denke, Sie sollten dies mit Ihrem Vorgesetzten besprechen. Sie wurden als Mobile Developer eingestellt, daher besteht ein Teil Ihrer Verantwortung darin, sich um jedes mobile Projekt zu kümmern, das Sie möglicherweise haben, und zu warnen.

Sie denken vielleicht, dass dies ein schlechtes Licht auf das Team werfen wird, aber die Nachteile, dies nicht früher zu melden, werden auf lange Sicht schlimmer sein. Stellen Sie nur sicher, dass Sie Alternativen und Lösungen bereit haben, wenn Sie sagen, was verbessert werden könnte (was Sie anscheinend bereits haben).

deswegen habe ich mich entschieden die app in meiner privaten zeit von null neu zu erstellen - das hat bei mir 2/3 wochen gedauert und es war geschafft.

Dies kann hier für Sie nützlich sein, damit Sie die Anerkennung erhalten, die Sie für Ihre Arbeit verdienen, und gleichzeitig dazu beitragen, eine insgesamt bessere App zu entwickeln. Auch wenn das, was Sie sagen, völlig richtig ist, besteht die Möglichkeit, dass Sie für 2,5 Jahre einige komplexe Aspekte übersehen haben. Seien Sie also auch offen für Korrekturen und Änderungen .

Ich muss sagen, dass dies ein verrückter mutiger Schritt von Ihnen war, aber wenn Sie es tatsächlich richtig gemacht haben, können Sie dies sicherlich zu Ihren Gunsten ausarbeiten. Ich schlage vor, dass Sie sich persönlich mit Ihrem Vorgesetzten treffen , wo Sie Ihre Bedenken hinsichtlich der aktuellen Version der App und der von Ihnen vorgeschlagenen Lösung und Vorgehensweise darlegen können.

Dazu empfehle ich Ihnen , Ihre Vorschläge sorgfältig zu formulieren . Anstatt zu sagen „Ich denke, X zu verwenden ist schlecht, und wir sollten Y verwenden“ , versuchen Sie es so zu formulieren: „Wie ich sehe, verwenden wir X in diesem Teil des Codes, könnten Sie die Vorteile davon erläutern?“ ... auf diese Weise zeigen Sie nicht mit dem Finger auf Sie, behalten eine Lerneinstellung bei und können Ihre Vorschläge trotz Ihres "Junior" -Zustands effektiv machen.

Sie können dann als Proof-of-Concept erwähnen, dass Sie während Ihrer Freizeit an einem Projekt gearbeitet haben, und mit der Präsentation Ihrer App fortfahren. Wenn das, was Sie beschreiben, zutrifft, wird Ihr Vorgesetzter höchstwahrscheinlich beeindruckt sein und die von Ihnen vorgeschlagenen Änderungen wahrscheinlich in Betracht ziehen.

Das Gute ist, dass die "Nachteile" hier minimiert werden, da Sie sich bereits die Zeit genommen haben, diese Alternativen zu recherchieren und zu codieren. Stellen Sie nur sicher, dass Sie dies in Ihrer Freizeit tun (also keine Firmenzeit "verschwenden"). Ich hoffe, Sie können das zu Ihren Gunsten regeln.

Es ist ein Rätsel.

Fairerweise muss man sagen, dass Sie angesichts der Zeit, die für die Erstellung des Codes benötigt wurde, möglicherweise nicht alle oder kleinere wichtige Aspekte des Codes vollständig verstanden haben. Oder Sie könnten einfach besser sein als der Rest Ihres Teams. Sie nehmen Sie beim Wort, Sie haben eine mögliche Lösung geschaffen, indem Sie es wiederholt haben, aber Sie haben auch zwei schwerwiegende interne Probleme hervorgehoben, veraltete, einfallslose oder uniformierte Entwickler und einen Manager, der das zweieinhalb Jahre lang nicht wusste. ..

Ihre Herangehensweise hier ist entscheidend für Ihre Langlebigkeit bei dieser Firma.

Ich würde Ihnen empfehlen, das Beste zu hoffen, aber das Schlimmste zu planen. Gehen Sie den Code in den nächsten zwei Wochen bei der Arbeit durch, um Dinge zu finden, die Sie vielleicht übersehen haben. in der Zwischenzeit decke deine a$$ in deiner Freizeit ab. Dokumentieren Sie alles, woran Sie von Ihrem Heimcomputer aus arbeiten, Screenshots, alles und jedes, nur für den Fall des rechtlichen Worst-Case-Szenarios. Gehen Sie Ihre neue und verbesserte App durch und testen Sie jeden Aspekt, den Sie können, überprüfen Sie alles doppelt dreifach.

Machen Sie in zwei Wochen den letzten Schritt. Vereinbaren Sie einen Gesprächstermin mit Ihrem Vorgesetzten. Zeigen Sie ihnen Ihre App neben dem aktuellen Angebot. Wow, er. Verblende ihn. Schlagen Sie ihn mit Ihrem coolen neuen UI-Design und Ihrer Code-Stabilität um.

Bieten Sie an, ihm den Code vollständig, kostenlos und klar zu geben. Sie werden ihm für alle Änderungen die volle Ehre geben. Im Gegenzug akzeptieren Sie freundlicherweise die Beförderung zum Senior-Entwickler mit der entsprechenden Gehaltserhöhung. Danach werden Sie mit Ihrer anhaltenden harten Arbeit sein Vertrauen in Sie beweisen. Darüber hinaus unterzeichnen Sie bei Bedarf gerne eine entsprechende Vereinbarung.

Schachmatt

Gehen groß oder nach Hause gehen. Wenn Sie es ihnen einfach geben, besteht eine hohe Wahrscheinlichkeit, dass sie es stehlen und Sie entlassen, um einfach die riesigen „Probleme“ zu vertuschen, die Sie möglicherweise aufgedeckt haben. Oder sie könnten dich für zu übermütig halten und dich entlassen. Wenn sie es tun, gehen Sie davon weg, dass Sie sie in Ihrem Alter outcodieren können. Ihre nächste Gelegenheit wird immer da sein, wenn Sie Ihr Spiel weiter verbessern.

Es ist so oder so ein Glücksspiel. Viel Glück.

T

Ich würde empfehlen, dass Sie mit dem Ende im Hinterkopf beginnen – was ist das Ergebnis, das Sie sehen möchten? Wenn ich deine Frage lese, vermute ich, dass es ungefähr so ​​​​aussieht:

• Eine bessere Benutzeroberfläche, die sich besser an die UI-Richtlinien für die beteiligten mobilen Plattformen hält
• Eine besser strukturierte Codebasis mit weniger Cruft und besser erkennbaren Architekturmustern
• Anerkennung Ihres Einflusses auf das Erreichen dieser Ziele

Unabhängig davon, ob dies die vollständige Liste ist, die eigentliche Herausforderung hier ist das Änderungsmanagement , d. muss:

• Identifizieren Sie „wichtige Stakeholder“: Wer wird am meisten von der angestrebten Zukunft profitieren? Wer wird die meisten Veränderungen erleiden? Wer wird sich am meisten darum kümmern, unabhängig davon, ob sie zu den anderen beiden Gruppen gehören? Dies sind die Leute, die Sie an Ihrer Seite brauchen, wenn es an der Zeit ist, Änderungen vorzuschlagen, und wenn es an der Zeit ist, mit der Umsetzung zu beginnen.
• Verstehen Sie Ihre Stakeholder und Ihr Unternehmen besser: Sie wissen wahrscheinlich viel über Ihren Raum und die mobile Entwicklung. Erfahren Sie mehr über Ihr Team, wie es zu dem geworden ist, was es ist und wo es sich befindet, und über Ihre Codebasis. Ist es Java-orientiertes Objective C, weil das das Paradigma war, das sie hatten, oder weil die erste Person, die es erstellte, schnell ging und niemand jemals Zeit hatte, es neu zu schreiben? Wie ist die Testabdeckung und können Sie sie verbessern? Dieses Verständnis ist von unschätzbarem Wert, wenn es an der Zeit ist, einen Plan für die gewünschten Änderungen zu erstellen, und der Prozess, es zu bekommen, wird die Beziehungen aufbauen, die Sie benötigen, um es umzusetzen.
• Schaffen Sie ein gemeinsames Verständnis und einen gemeinsamen Appetit auf die Veränderung: Fangen Sie an, mit diesen Leuten und anderen über den zukünftigen Zustand zu sprechen, den Sie sich erhoffen. Es muss sich nicht unmittelbar auf Ihre App beziehen; Tatsächlich ist es oft besser, in Bereichen zu beginnen, die eindeutig davon getrennt sind, um Bedenken und Abwehrreaktionen zu vermeiden. Sie könnten beispielsweise regelmäßig einige Zeit damit verbringen, eine andere App zu dekonstruieren und zu diskutieren, die Ihrer Meinung nach wirklich gut gemacht ist, insbesondere in Bezug auf Aspekte, die Ihrer Meinung nach auf Ihre eigene App anwendbar wären. Es ist nicht wichtig, diese Gespräche mit "... also sollten wir das auch tun" zu beenden. Sie erforschen gemeinsam, und Sie werden gemeinsam die Dinge schätzen lernen, die am wichtigsten sind.
• Klein anfangen, Schwung aufbauen:Schlagen Sie weder einen Zweijahresplan vor, um die gesamte Codebasis zu übergeben, noch ein „Stoppen Sie die Welt, während wir umschreiben“-Projekt. Suchen Sie stattdessen nach einer Reihe von Änderungen, die Sie angehen können, um die App für eine bessere Zukunft weiterzuentwickeln und gleichzeitig die Funktionsentwicklung fortzusetzen. Wählen Sie kleine Dinge, die große positive Auswirkungen haben, und packen Sie sie zuerst an, wenn Sie können; Sie werden Ihnen sowohl helfen, Ihre Richtung zu testen, als auch Ihnen durch Erfolge Impulse geben. Vielleicht sind die wichtigsten Ausgangspunkte einige kleine Refactorings, die es einfacher machen, einige wichtige Features gut bereitzustellen; Vielleicht ist es die Neuarchitektur eines Teils der App auf eine bessere Grundlage, damit sie nicht so oft kaputt geht (weil es einfacher ist, sie gut zu testen, oder? ;) Was auch immer es ist, machen Sie sie klein und inkrementell, damit Sie '

In diese Situation werden Sie im Laufe Ihrer Karriere immer wieder geraten. Der Aufbau starker Change-Management-Fähigkeiten – die Fähigkeiten, Veränderungen auf eine Weise herbeizuführen, die das Team und das Unternehmen stärkt und die Moral und Beziehungen aufbaut, anstatt sie zu zerstören – ist enorm wertvoll und bringt Sie weiter als fast alle technischen Fähigkeiten, die Sie entwickeln können.

Viel Glück!

Technische Schulden

https://www.techopedia.com/definition/27913/technical-debt

Sobald ein Unternehmen in die Kategorie der technischen Schulden fällt, kann es sich in einer schwierigen Situation wiederfinden. Es ist ein sehr häufiges Problem und kann durch Politik, Prozesse und kurzfristige Ziele verschlimmert werden.

Technische Schulden sind unvermeidlich. Der Schlüssel ist, es zu verwalten.

• Unit-Tests schreiben
• Verwenden Sie Codeabdeckungstools, um Codeänderungen zu überwachen
• Verwenden Sie Quellcode-Linting-Tools
• Verfolgen Sie die Häufigkeit von Fehlern (Indikator für technische Schulden)

Es sei denn, alle fangen an, zusammenzuarbeiten, um technische Schuldenprobleme zu lösen. Nichts, was Sie als Programmierer tun, hat die Hoffnung, die Ursachen zu beheben. Sie könnten es umschreiben, umgestalten, umgestalten oder einfach mit einem Hammer zerschlagen.

Technische Schulden werden sich schnell wieder in den Quellcode zurückkriechen.

Ich würde zu Ihrem Vorgesetzten gehen und diese Art von Gespräch mit ihm führen.

Hallo, ich bin erst seit kurzem hier. In dieser Zeit habe ich festgestellt, dass das Hinzufügen neuer Funktionen, das Beheben von Fehlern und das Befolgen Ihrer benutzerdefinierten Ansätze für das UI-Design viel länger dauert, als ich denke, dass sie sollten. Obwohl mir die Erfahrung fehlt, genau zu bestimmen, warum dies der Fall ist. Es ist mir unangenehm. Wussten Sie, dass wir hier technische Schuldenprobleme haben?

Entweder weiß er, dass es da ist, oder er untersucht das Problem. Der Schlüssel ist, einfach ein freundliches Gespräch darüber zu beginnen und Anschuldigungen über Ursache und Wirkung zu vermeiden. Man hat im Grunde das Gefühl, dass es da ist, aber man weiß nicht genau wo.

Bring das Thema immer wieder hoch. Das ist ungefähr alles, was Sie tun können.

Es sollte die Rolle eines leitenden Entwicklers sein, sicherzustellen, dass Unit-Tests, Code-Coverage, Quellcode-Linting und andere analytische Praktiken befolgt werden. Alles, was Sie tun können, ist darauf hinzuweisen, dass Sie sie brauchen.

Ermutigen Sie die Menschen, offener über technische Schulden zu sprechen. Fragen Sie herum, was jede Person denkt. Versuchen Sie, Gespräche darüber zu beginnen.

Aber seien Sie immer freundlich, hören Sie anderen zu und hinterfragen Sie nicht, was sie sagen, und hoffen Sie, dass Sie mit der Zeit als Team zusammenkommen, um diese Schulden zu bekämpfen.