Umgang mit unflexiblen Programmierern

Manchmal werden Programmierer, die lange Zeit an einem Projekt arbeiten, unflexibel und es wird schwierig, mit ihnen zu argumentieren. Selbst wenn es uns gelingt, sie zu überzeugen, ist es unwahrscheinlich, dass sie unsere Vorschläge umsetzen.

Ich bin zum Beispiel kürzlich einem Projekt beigetreten, bei dem der Build & Release-Prozess zu kompliziert ist und unnötige Hindernisse aufweist.

Ich schlug vor, den Entwicklungsaufwand (z. B. das Ausfüllen einiger Tabellenkalkulationen) durch die Integration von Tools für das Fehlermanagement und die Versionskontrolle zu verringern (beides sind IBM-Rational-Tools, sodass die Integration ein sehr einfacher einmaliger Aufwand sein kann). Wenn wir Tools wie Maven & Ant verwenden (das Projekt beinhaltet Java und einige COTS-Produkte), kann Build & Release vereinfacht werden, was manuelle Fehler und Eingriffe reduzieren dürfte.

Es ist mir gelungen, andere zu überzeugen, und ich bin bereit, mich für die Entwicklung eines Proof-of-Concept einzusetzen. Aber der "Senior" -Entwickler ist nicht bereit, möglicherweise, weil der aktuelle Prozess ihn wertvoller macht.

Wie gehen wir mit dieser Situation um, ohne dass es zu Reibungsverlusten im Team kommt?

Sie sind das neue Teammitglied und möchten einige grundlegende Aspekte der Teamarbeit ändern. Viel Glück, ich spüre ein glückliches Team in Ihrer Zukunft.

Ok, einige praktische Ratschläge:

Beweisen Sie sich im Team. Sie müssen dies aus technischer und zuverlässiger Sicht tun. Wenn Sie möchten, dass die Leute Ihnen folgen, müssen Sie ihnen einen Grund dafür geben.

Verstehen Sie die Geschichte der Methodik. Warum existiert es? Welches Problem löste es zu der Zeit? Stellen Sie sicher, dass Ihre Lösung dem Team wirklich zugute kommt. Vielleicht sind Ihre Änderungen besser, aber sie lösen möglicherweise kein Problem, das das Team hat.

Lernen Sie Ihre Straßensperren kennen. Finde die Gründe für ihren Widerstand heraus und arbeite an diesen Gegenständen.

Wenn Sie ein Agent der Veränderung sein möchten, lernen Sie, wie Sie ein erfolgreicher Agent der Veränderung sein können . Dutzende Bücher und andere Quellen bieten Ihnen weitaus mehr Informationen, als Sie hier erhalten.

Und ja, ich wünsche Ihnen viel Glück. Aber bitte, seien Sie klug, um Ihr Glück und das Glück Ihres Teams zu gewährleisten. Ihr Wunsch, einen Prozess zu ändern, ohne die Energie zu investieren, um den richtigen Weg zu finden, könnte weit mehr schaden als nützen.

Ich war in der Position, die Sie erwähnt haben. Ich verbrachte Jahre als Java-Entwickler und ging schließlich zu einem Job, bei dem alle Smalltalk verwendeten. Meine erste Reaktion war "OMG, sie verwenden diese veraltete Technologie" und ich fing an, Smalltalk-spezifische Probleme mit Java-Lösungen zu lösen. Ich kann mir nur vorstellen, was für Kopfschmerzen ich den anderen Entwicklern bereitet haben muss, und sie hassten Java leidenschaftlich.

Erst als ich ein mittelgroßes Projekt bekam, an dem ich arbeitete, als ich von zwei erfahrenen Entwicklern im Laufe einiger Monate betreut wurde, fing ich an, die Sprache Smalltalk zu verstehen und zu lernen, sie zu mögen. Seit ich diesen Job verlassen und wieder Java-Entwicklung betrieben habe, fühle ich mich viel flexibler, da ich ein Projekt in jeder Sprache des Unternehmens implementieren kann. Das Wichtigste, um diese Menschen zum Verstehen zu bringen, ist, dass die Sprache nichts anderes als das Medium ist. Ich habe mir auch die Zeit genommen, mir Lisp und Erlang beizubringen, aber das funktioniert möglicherweise nicht bei allen.

Als Teambildungsstrategie würde ich Sieben Sprachen in sieben Wochen den Leuten empfehlen, mit denen Sie Probleme haben.

Ich denke, es kommt auch darauf an, wie viel Zeit diese Leute bereit sind, in die Flexibilisierung zu investieren. Das Problem mit den meisten Universitäten (zumindest denen, die ich gesehen habe) ist, dass sie auf eine bestimmte Sprache eingestellt sind und ihre Studenten, wie Sie erwähnt haben, "institutionalisiert" werden. Ich denke, ein Teil Ihrer Strategie sollte darin bestehen, die Flexibilität in Ihrem Team zu fördern. Dies könnte durch die domänengetriebene Entwicklung ergänzt werden .

(1) Modellieren einer Domäne (Eine einfache) (2) Implementieren Sie sie in zwei verschiedenen Sprachen (z. B. Java und Lisp).

Auch dies unter der Annahme, dass sie motiviert sind, dies zu tun, und bereit sind, ihre eigene Zeit zu investieren, um dies zu erreichen.

Hoffe das hilft

Ich könnte hier auf einem völlig falschen Weg sein, aber es scheint mir, dass die gleichen Probleme in größerem Maßstab häufig sind und sich auf den menschlichen Konservatismus beziehen. Menschen weigern sich oft, die bekannten Verhaltensmuster zu ändern, aus Gründen, die zu zahlreich sind, um sie zu erwähnen.

Ich bin ein russischer Entwickler (und sehe daher weniger einen rationalen westlichen Pragmatismus) und sehe die praktischen Argumente als weit weniger überzeugend an, als wenn ich versuche, in den Schuhen eines anderen zu laufen.

Mit anderen Worten, Sie haben erwähnt, dass der leitende Programmierer seine eigene Position in Bezug auf das aktuelle Arbeitsschema schätzt. Vielleicht sollten Sie ihn davon überzeugen, dass die neue Art, Dinge zu tun, seine Position noch wertvoller macht, und es gibt viele Möglichkeiten, dies zu tun. Zum Beispiel können Sie ihn veranlassen, Ihre Idee tatsächlich auszusprechen und dafür Anerkennung zu erhalten, oder Sie können einen bestimmten Punkt in dem Prozess finden, den er exklusiv kontrollieren kann usw.

Ich glaube, dass Flexibilität außerhalb der offensichtlichen Vorteile Ihrer Idee Ihr Zauber sein könnte.

Es ist mir gelungen, andere zu überzeugen, und ich bin bereit, mich für die Entwicklung eines Proof-of-Concept einzusetzen. Aber der "Senior" -Entwickler ist nicht bereit, möglicherweise, weil der aktuelle Prozess ihn wertvoller macht.

Anstatt über den Charakter des Senior-Entwicklers nachzudenken (schlechter Zug), sollten Sie vielleicht versuchen zu verstehen, warum er nicht begeistert ist:

• Vielleicht denkt er, Sie gehören zu denen, die ihre Ideen übertreiben. Vielleicht bezweifelt er, dass Sie sie liefern können.

• Vielleicht denkt er, Sie übertreiben die Probleme. (Sie können nicht so schlimm sein ...)

• Vielleicht glaubt er, dass Sie die technischen Risiken nicht vollständig verstehen.

• Vielleicht denkt er (weiß), dass es momentan wichtigere Dinge zu tun gibt.

• Vielleicht reiben Sie ihn einfach falsch herum.

Mein Rat wäre, sich ihm zu beweisen. Zum Beispiel, indem Sie die Projekte ausführen, die Sie tatsächlich erhalten haben. Wenn er mehr auf Ihre Fähigkeiten und Ihr Urteilsvermögen vertraut, dann gehen Sie noch einmal auf dieses Thema ein.

Wenn Sie jetzt die Linie "Prozessverbesserung" verfolgen möchten, ist mein Ratschlag, dies langsam und in kleinen Schritten zu tun.

Bedenken Sie, dass die von Ihnen vorgeschlagenen Änderungen zweifellos die Produktivität Ihrer Gruppe und sogar deren Fähigkeit, vorhandene Software zu warten, massiv beeinträchtigen können. In diesem Fall wird die verantwortliche Person wahrscheinlich die meisten Informationen von der Geschäftsleitung erhalten.

Über was insbesondere institutionalisiert? Technologien, Muster, Praktiken?

Wenn sie schon lange in der Organisation / im Projekt sind, sind sie wahrscheinlich leitende Entwickler und haben die Verantwortung / Erfahrung, diese Anrufe zu tätigen, und haben Erfahrungen im Projekt gesammelt, anstatt nur wie beim 5-Affen-Experiment konditioniert zu werden .

Die Lösung, um sie zu überzeugen, wird davon abhängen, um welches Thema es sich handelt, denn wenn bereits ein Muster / eine Technologie ausgewählt wurde, wird es einen guten Grund geben, und es wird einen besseren Grund geben, sich zu ändern, um das Wegwerfen von Arbeit und das Umgewöhnen usw. Zu rechtfertigen Wenn ja, ist eine Lösung für einen Architekten / leitenden Entwickler, der ein Meeting organisiert, um demokratisch über die beste Lösung zu entscheiden.

Wenn das Team wirklich unnötige Straßensperren hat, sind sie wahrscheinlich am glücklichsten, wenn Sie ihnen bei der Behebung helfen. Beachten Sie jedoch, dass es sehr gute Gründe dafür geben könnte, und Sie werden dumm aussehen, wenn Sie sagen müssen: "Oh, meine fantastische Idee funktioniert dann nicht", nachdem Sie sie für eine lange Zeit an alle verkauft haben.

Untersuchen Sie zuerst und treten Sie dann vor. Beachten Sie auch, dass es viel besser ist, zu ZEIGEN, wie Sie es für besser halten, als von Hand zu winken.

Ich bin geneigt zu sagen, dass Sie derjenige sind, der der "unflexible Programmierer" ist. Sie sind neu im Projekt, bestehen jedoch darauf, dass Ihre Idee am besten ist, und derjenige, der das Projekt leitet, der länger ist und das System in- und auswendig kennt, ist einfach von seiner Wippe.

Ich bin ziemlich erfahren und sehr angesehen und werde häufig beauftragt, schwierige Projekte als Tiger-Teammitglied zu reparieren. Selbst dann nehme ich mir noch die Zeit, um das Wie, Warum, die Dynamik des Teams, das Projekt und ihre Praktiken zu lernen und nicht wild darauf einzugehen und ihnen zu sagen, wie dies und das falsch ist. Eigentlich sage ich nie, dass das, was sie tun, falsch ist, weil es nicht die gewünschte Antwort gibt und normalerweise ist das, was sie tun, nicht falsch, es muss nur etwas optimiert werden.

Jedes Projekt ist einzigartig. Jedes Team ist einzigartig. Ihre Lösung ist möglicherweise besser für Sie und die Entwickler, aber nicht besser für den Lead, den Kunden, das Unternehmen oder das Projekt. Da Sie jedoch nicht die Erfahrung mit dem Projekt haben, es besser zu wissen, würden Sie es nicht wissen die antwort darauf.

Der beste Weg, um Leute dazu zu bringen, das zu tun, was Sie wollen, besteht darin, sie glauben zu lassen, alles sei ihre Idee. Präsentieren Sie also Optionen, anstatt direkt Vorschläge zu machen. Wenn Ihre Ideen eindeutig besser sind als die Alternativen, geben Sie dem leitenden Entwickler die Möglichkeit, sie herauszusuchen und sie sich zu eigen zu machen. Mach dir keine Sorgen um Kredit. Die Leute, die wichtig sind, werden wissen, was los ist.