Wie bewerte ich als angehender Praktikant, wie einfach es für mich wäre, die Praktiken eines Teams zu verbessern?

Wie kann ich am besten einschätzen, wie schnell ein Team auf meine Versuche reagieren wird, seine Gewohnheiten zu ändern, bevor ich überhaupt eingestellt werde? Ist es angemessen, einfach nur zu fragen? Wenn ja, gibt es eine Möglichkeit, die Frage zu formulieren, um ehrlichere, realistischere und durchdachtere Antworten zu fördern?

Die kurze Antwort ist, dass es dafür keine halbwegs zuverlässige Methode gibt. Der beste Weg, dies zu beurteilen, ist die Erfahrung, die Sie nicht haben (und warum Sie diese Frage überhaupt stellen), aber das bedeutet nicht, dass Sie nichts tun können:

NICHT

Fragen Sie offen – Sie riskieren, sie in die Defensive zu drängen (mit der impliziten Kritik an ihren aktuellen Arbeitspraktiken) und arrogant zu wirken. Auch wenn sie es nicht so nehmen und alles richtig sagen, wie Sie sagen "Reden ist billig", das Richtige zu sagen, selbst wenn es von den besten Absichten unterstützt wird, bedeutet nicht, dass Taten folgen werden.

TUN

Fragen Sie sie, was ihrer Meinung nach ihre aktuellen Probleme in ihrem Entwicklungsprozess sind. Wenn sie etwas auflisten, das durch die Implementierung von Git oder einer der anderen Praktiken, die Sie einführen möchten, gelöst werden kann, können Sie dies als Vorschlag verwenden. Es ist keineswegs eine Gewissheit, dass sie dies durchziehen werden, aber es ist ungefähr so ​​​​ein guter Indikator, wie Sie bekommen werden.

Als allgemeine Faustregel gilt, dass es schlechte Geschäftspraktiken ist, Prozesse zu ändern, ohne eine ziemlich genaue Vorstellung davon zu haben, welche Art von Verbesserungen Sie daraus ziehen werden. Das Ändern von Prozessen führt fast immer zu einem kurzfristigen Produktivitätsabfall, selbst wenn die gesamte Implementierungsarbeit vollständig von Ihnen selbst durchgeführt wurde, wird es eine Phase der Anpassung für das etablierte Team geben, das es gewohnt ist, so zu arbeiten, wie es im Moment ist, das heißt Sie werden Zeit damit verbringen, sich an den neuen Prozess zu gewöhnen (Zeit, die sie sonst damit verbracht hätten, "produktiv" zu sein), und jeder neue Prozess wird wahrscheinlich kurzfristig zu einer Erhöhung der Fehlerquote führen, da Personen, die mit a Es ist wahrscheinlicher, dass der Prozess Fehler macht, und dann geht mehr Zeit verloren, während der Fehler korrigiert wird.

Eine weitere gute Faustregel im Geschäftsleben (und glauben Sie mir, ich versuche nicht, hart zu klingen, wenn ich das sage) ist, dass Sie im Allgemeinen keine wesentlichen Änderungen an Ihren Geschäftsprozessen vornehmen, nur auf Anraten von unerfahrenen Praktikanten, also würde ich das sagen Wenn Sie auch nur die geringste Hoffnung haben wollen, eine dieser Änderungen durchzubringen, brauchen Sie die Unterstützung von einem oder mehreren Mitgliedern des bestehenden Entwicklungsteams - und um ehrlich zu sein, es klingt nicht so, als hätten Sie sie. Hätte ein oder mehrere Mitglieder des bestehenden Teams auf Ihre Git-Frage mit etwas wie geantwortet

Gott ja ... die Implementierung von Git wäre großartig, es würde mein Leben so viel einfacher machen!

dann wäre das ermutigend gewesen, denn wenn der Manager sein Gehalt wert ist, bevor er einen Ihrer Vorschläge umsetzt, wird er sich mit seinem bestehenden Team beraten, um zu sehen, ob dieser Praktikant, den sie kaum kennen, eine Ahnung davon hat, wovon sie sprechen, oder weniger als Die enthusiastische Reaktion wird diese Idee wahrscheinlich genau dort zunichte machen.

Arbeiten Sie so, wie Sie arbeiten möchten, solange sich dies nicht negativ auf die Produktivität Ihres Teams auswirkt. Natürlich nur mit Erlaubnis des Teamleiters.

Wenn Sie es auf diese Weise tun, bedeutet dies, dass Sie dem Team keine aggressiven Arbeitspraktiken aufzwingen und es an ihnen liegt, sich anzusehen, was Sie tun, und alle guten Punkte, die sie sehen, einzubeziehen (oder sie nach eigenem Ermessen zu verwerfen).

Beachten Sie, dass gut geschriebener Code nicht unbedingt überall Kommentare benötigt (ich weiß nicht, wie dieser Code aussieht, daher könnte dies subjektiv sein). Erstellen Sie Ihre eigene Dokumentation und reichen Sie diese mit Ihrer Arbeit ein. Für einen Bug-Tracker würde ich zu Beginn einfach eine Tabelle verwenden und die Leute dazu ermutigen, sich diese anzusehen, um Ihren Fortschritt bei der Fehlersuche zu verfolgen. Die Leute können glauben und der Tabelle Fehler hinzufügen, wenn Sie sie anleiten (aber erzwingen Sie das Problem nicht).

Niemand mag es, wenn ein neuer Mitarbeiter aufdringlich ist, aber es ist gut zu sehen, dass bewährte Praktiken demonstriert werden, und sie sind einfacher zu übernehmen, wenn sie nachweislich Ihrer eigenen Produktivität helfen.

Es ist 2018 und sie verwenden kein Quellcode-Kontrollsystem. Meine Erinnerung reicht vielleicht nicht weit genug zurück, aber ich habe 1996 die Quellcodeverwaltung (damals SCCS) verwendet. Sie sind 22 Jahre im Rückstand. Es tut mir leid, das sagen zu müssen, aber Sie haben nicht die geringste Chance, das zu ändern, was sie tun.