Wir sind ein kleines Team, das kurz vor dem Start einer neu gestalteten Website steht, die einem umfassenden Facelifting unterzogen wird. Aufgrund der Art des Zeitrahmens habe ich weniger Arbeitsbelastung und mein Manager möchte, dass ich die Dinge teste, um sicherzustellen, dass alles in Ordnung ist. Wir haben auch einen Vollzeit-Tester. Beim Testen habe ich festgestellt, dass es einige Probleme gibt, die zuerst nicht da waren. Sie waren entweder das Ergebnis der Fahrlässigkeit meines Managers oder eines anderen Entwicklers, aber es fällt mir zu, da es mit dem Frontend zusammenhängt. Zum Beispiel habe ich die Website auf dem Handy überprüft und das Menü wird nicht geladen, aber auf dem Desktop schon. Das bedeutet, dass sie ihre Arbeit getan haben, um das Menü dynamisch zu machen, aber nicht das andere bisschen und mir nichts gesagt haben.
Im Laufe der Zeit hat mein Team meine Arbeit mit allem verschmutzt, was sie werfen und sehen können, was hängen bleibt, weil sie denken, dass sie meinen Job gut kennen.
Wenn ich etwas, das mir zugewiesen wurde, nicht erledige oder mir etwas Zeit nehme, wirft mein Vorgesetzter schnell Probleme auf oder lässt andere Entwickler bei mir sitzen, um die Aufgabe zu erledigen.
Bei einem so großen Problem wie dem nicht geladenen Menü auf Mobilgeräten geht der IT-Direktor davon aus, dass der Typ, der für ein Frontend eingestellt wurde (ich), nicht gut in seinem Job ist. In Wirklichkeit hat die Person, die an der Speisekarte gearbeitet hat, nicht auf dem Handy gearbeitet. Wenn die Änderung etwas im Backend ist, ist der Manager schnell aufgeregt und fragt mich, warum , und sein Gedächtnis ist mir gegenüber nicht allzu gut.
Meine Frage ist, wie viel Recht ich als Untergebener habe, meinem Vorgesetzten zu sagen, dass mein Design in Ordnung war, aber nachdem er oder ein anderer Entwickler daran gearbeitet hat, es ruiniert wurde und dass die richtige Person es reparieren sollte?
Der andere Entwickler entfernte schnell die SVN-Geschichte, sodass man nicht wissen kann, wer was vor ein paar Monaten getan hat, also ist es ein Krieg der Worte
Sie haben die Aufgabe zu testen, und während Ihrer Tests finden Sie Fehler? ... dafür ist das Testen da. Sie melden die Fehler und dann können sie behoben werden. Das Point-the-Finger-Spiel zu spielen ist nicht sehr konstruktiv. Wenn Sie richtig dokumentieren, sollte Sie das nicht beunruhigen.
Ich behebe meinen Lebensunterhalt (keine Software). Der professionelle Weg, damit umzugehen, besteht darin, einen Bericht darüber zu erstellen, was nicht richtig funktioniert, mögliche Untersuchungslinien zur Lösung der Probleme zu erstellen und sich auf Lösungen statt Schuldzuweisungen zu konzentrieren.
Die Leute sollten sich nicht mit der Versionskontrolle herumschlagen, aber das scheint nicht Ihre Rolle zu sein. Das ist ein Thema für sich und ich würde wie folgt einen Bericht darüber machen, ohne die Schuldzuweisungen zu machen.
„Bei der Untersuchung der Ursache des X-Problems habe ich festgestellt, dass frühere Versionen nicht verfügbar sind, was es schwierig macht, die Ursache zu lokalisieren. Dies kann auf ein Problem mit dem Versionskontrollsystem oder eine absichtliche Manipulation hindeuten. In Zukunft habe ich XX und XY als Hauptgründe für das Scheitern von YY identifiziert, wenn eine WW-Situation eintritt. etc, .... (dann auf Lösungsstrategien hinarbeiten).'
Da Software deterministisch ist und es genügend Tools gibt, um Änderungen zu verfolgen, sollte dies wirklich einfach zu lösen sein.
Die Verwendung eines solchen Systems (auf manipulationsfreie Weise) legt die Beweislast für einen Ausfall so ziemlich auf das Unternehmen.
Bugs zu haben, die es bis zur Produktion schaffen, weist auch auf einige andere Probleme in den Prozessen hin. (Testen und Bereitstellen)
Beginnen Sie mit der Verbesserung der Prozesse Ihres Teams, um in Zukunft aus solchen Situationen herauszukommen und in ein konstruktives Arbeitsumfeld zu gelangen.
Daniel
Benutzer44108
Rat
Benutzer15704
Benutzer15704
Donald
MaxW