Wie kann ich einen besseren Prozess vorschlagen, ohne „der Typ zu werden, der diesen Prozess durchführt“?

Ich bin ein Junior-ish-Programmierer. Ich habe in letzter Zeit einige Probleme bemerkt, die meiner Meinung nach durch einen Continuous Integration Server (CI) gelöst werden könnten. Ich habe vor, in naher Zukunft zu meinem Vorgesetzten zu gehen und so etwas zu sagen wie: „Wir hatten diese Probleme, hier ist, wie es uns beeinflusst hat, mit Jenkins würden wir uns nie wieder mit so etwas auseinandersetzen müssen. Kann ich einen Jenkins-Server bekommen? damit ich ein CI für diese Projekte einrichten kann?"

Meine Befürchtung ist, dass das nächste Mal, wenn jemand ein Problem mit CI hat, die Antwort lautet: „JETM hat ein gutes System für uns eingerichtet; sprechen Sie mit ihm.“ Und fünf Jahre später bin ich zum DevOps-Typen geworden.

Ich hasse es, mit DevOps zu arbeiten. Ich tue gerne das Richtige und baue die Infrastruktur auf, damit die Projekte meines Teams reibungsloser ablaufen, aber ich wünsche mir in dieser Hinsicht nicht wesentlich mehr Verantwortung, als ich bereit bin, ehrenamtlich zu leisten.

Wie kann ich die Verbesserung vorschlagen und gleichzeitig klarstellen, dass ich nicht "der Jenkins-Typ" sein möchte?

(Hinweis für technisch nicht versierte Leser: CI steht für Continuous Integration. Jenkins ist ein gängiges Tool für CI.)

Vielleicht gibt es Teammitglieder, die auch gerne Jenkins einrichten möchten, die einfach nur Aufmunterung brauchen und keine Angst haben, sich in einen Devops-Typen zu verwandeln?
Haben Sie bereits einen „DevOps“-Typen in Ihrem Team? Ist das Problem größer, als Sie annehmen – es ist nicht nur CI, sondern andere DevOps-Dinge, die durch das Raster fallen? Vielleicht sollte Ihr Vorschlag eher im Sinne von "Wir brauchen, dass diese Art von Aufgaben jemandem zugewiesen werden" statt nur dieses Problem zu beheben?
@dwizum Wir haben derzeit niemanden, der DevOps durchführt.

Antworten (3)

Sie müssen entscheiden, wie viel von der unangenehmen Nebenarbeit Sie bereit sind, auf sich zu nehmen.

Du bist Programmierer. Das bedeutet, dass es viele Nebenarbeiten gibt , die sich natürlich zum Job addieren. Die Leute werden wollen, dass Sie CI-Arbeiten und Testarbeiten sowie Dokumentations- und Datenbankarbeiten erledigen. Sie könnten am Ende versuchen, Sie in Richtung Projektmanagement, Computersicherheit und/oder Angebotserstellung zu drängen. Je mehr davon Sie bereit sind zu tun, und je mehr Sie bereit sind, sie zu tun, desto wertvoller sind Sie als Mitarbeiter. Für jeden von ihnen möchten Sie den Schieberegler in Ihrem Kopf einstellen.

1 - Sie könnten entscheiden, dass Sie Thing X lieben und es zu einem Schwerpunkt Ihrer Karriere machen möchten. Um dies zu tun, bekunden Sie mündlich Ihr Interesse, studieren es zu Hause und melden sich offen und enthusiastisch, wann immer es verfügbar ist. (in diesem Fall nicht erwünscht)

2 - Sie könnten entscheiden, dass Sie mit Thing X einverstanden sind, und es Ihnen nichts ausmachen, in diese Richtung geschoben zu werden, wenn es das ist, was erforderlich ist. Um dies zu tun, geben Sie dies offen zu, melden Sie sich freiwillig, wenn Sie die richtige Person für den Job zu sein scheinen, und stellen Sie sicher, dass Sie auf dem Laufenden bleiben.

3 – Du könntest entscheiden, dass es für dich in Ordnung ist, dies einige Male zu tun, aber du möchtest nicht, dass es zu dem wird, was du tust. Um dies zu tun, erkennen Sie Bereitschaft und Fähigkeit an, akzeptieren Sie ein angemessenes Maß an Aufgaben (was auch immer für Sie angemessen ist - oft am besten als Prozentsatz der Gesamtarbeitszeit ausgedrückt), machen Sie deutlich, dass Sie Grenzen haben (in Bezug auf Bereitschaft und/oder Eignung), und drängen Sie zurück, wenn sie versuchen, Sie zu weit zu drängen.

4 - Sie könnten entscheiden, dass Sie Sache X überhaupt nicht tun wollen. Um dies zu tun, weigern Sie sich rundweg, anzuerkennen, dass Sie unter allen Umständen überhaupt dazu in der Lage sind.

Im Allgemeinen werden Sie nicht versuchen wollen, bei allem mit #4 zu gehen, es sei denn, Sie sind ein hervorragender Programmierer. Ein gewisses Maß an Flexibilität und Anpassungsbereitschaft ist sehr hilfreich, um die Führung davon zu überzeugen, dass Sie ein Teamplayer sind. Es hört sich so an, als ob Sie sich in Ihrem speziellen Fall für # 3 entscheiden möchten, was cool ist, aber Tatsache ist, dass es nicht sicher ist. Es hängt davon ab, ob sich Ihr Management tatsächlich um Ihre Vorlieben kümmert und / oder ob Sie in der Lage sind, ihnen ab und zu "Nein" zu sagen.

Also ... vorausgesetzt, Ihr Management ist einigermaßen vernünftig/hilfreich, Sie müssen es nur klar darstellen. CI ist etwas, das Ihnen nicht gefällt, aber Sie können sagen, dass Sie in diesem speziellen Fall viel verschwendete Zeit und Energie sparen könnten, um dieses Ding einzurichten. Sie sind bereit, den Einrichtungsaufwand (auch wenn es Ihnen nicht gefällt) und den (hoffentlich minimalen) Wartungsaufwand (dies ist notwendig) zum Wohle des Unternehmens zu investieren, aber Sie wurden als Programmierer eingestellt, und das ist es auch wichtig für dich, dass du ein Programmierer bleibst. Dann seien Sie bereit. Sechs Monate später, wenn sie versuchen, Ihnen mehr CI-Arbeit aufzuzwingen, als Sie damit einverstanden sind (wie viel das auch ist), müssen Sie zurückdrängen und ihnen sagen, dass Sie mit dem Ausmaß, in dem es ist, nicht zufrieden sind Ihren Job übernommen. Erkennen Sie, dass Sie möglicherweise aufhören müssen, wenn die Managementsituation toxisch genug ist.

Das ist wirklich alles, was Sie tun können ... bei all diesen Dingen.

Ich mag diese Antwort. Meiner Erfahrung nach gibt Jenkins im Alltag einen moderaten Effizienzschub, kann aber zu ungünstigen Zeiten auch sehr bedürftig werden. Ich mag es vielleicht nicht, wenn ein Kollege Jenkins ins Team drängte, aber dann verschwinden wollte, wenn irgendein fieses Berechtigungsproblem oder TLS-Versionskonflikt oder was auch immer seinen hässlichen Kopf aufrichtete. Und ich habe mich schon früher gefragt, ob Jenkins wirklich genug mehr tut (z. B. im Vergleich dazu, nur Build-Skripte zu haben), um seine Pflege und Fütterung zu rechtfertigen. Wahrscheinlich tut es das in einigen Läden/Situationen, aber nicht in anderen. Ich jedenfalls würde dafür nicht evangelisieren.

Meine Befürchtung ist, dass das nächste Mal, wenn jemand ein Problem mit CI hat, die Antwort lautet: „JETM hat ein gutes System für uns eingerichtet; sprechen Sie mit ihm.“

Ja. Das wird passieren. Zum größten Teil ist es eine gute Sache, weil es bedeutet, dass Sie viel Einfluss darauf haben, Dummheiten vorzubeugen, und es erhöht auch Ihre Sichtbarkeit.

Aber als der Typ, der den CI-Server vorher eingerichtet hat und der es jetzt ab und zu macht, ist es kaum ein Vollzeitjob. Alle paar Jahre ein paar Wochen.

Wenn es tatsächlich Gefahr läuft, ein Vollzeitjob zu werden, dann denken Sie an den Satz: „Das ist eine grundlegende Fähigkeit, die Ihr Team haben muss. Ich habe einen Tagesjob. Ich würde Ihnen gerne das Fischen beibringen, aber ich tue es nicht Ich habe nicht die Zeit, das ganze Angeln für dich zu erledigen.“

Wenn Sie feststellen, dass immer mehr Ihrer Zeit dafür verwendet wird, machen Sie Ihrem Projektleiter (und/oder Manager) klar, dass Ihr Projekt zu Tode geknabbert wird, indem Sie von anderen Projekten abgelenkt werden. Dasselbe wie immer, wenn Sie feststellen, dass Sie von anderen Projekten oder anderen Managern gestohlen werden.

Whoa, Ninja'ed zweimal.
Ihre hat den Vorteil direkt anwendbarer persönlicher Erfahrungen.

Wenn es sich durchsetzt und genutzt wird, ist es im Interesse des Unternehmens, eigene Prozesse zu entwickeln. Zumindest würde das bedeuten, mehr Leute mit Administratorrechten und genügend Wissen zu bekommen, damit Sie nicht zum Engpass werden – wenn Sie im Urlaub sind und ein Build stecken bleibt, an wen werden sie sich wenden?

Wenn Sie initiativ werden wollen, schlagen Sie im Erfolgsfall eine Probezeit mit „Übergabe“ vor. Die Übergabe besteht darin, dass mindestens eine, besser zwei Personen so weit in das System eingeführt werden, dass Sie sie zu Administratoren machen können, und alle Notizen, die sie machen, irgendwo archivieren, wo sie später gefunden werden können, falls das Unternehmen jemals mehr Leute bringen muss auf Hochtouren.