5 Ängste vor Entwicklern, die wir überwunden haben

Halloween ist die Zeit, um über Ängste zu sprechen. Ich arbeite als Produktmanager in einem IT-Unternehmen, daher geht es um die Albträume von Entwicklern. Aber nicht gewöhnlich, sondern solche, die in Zeiten des Wandels auftreten.



Wenn sich ein Unternehmen entwickelt, ändert es seinen Entwicklungsansatz, erstellt neue Produkte und erweitert die Fähigkeiten der aktuellen, nimmt Dutzende von Mitarbeitern auf, und diejenigen, die auf die alte Art und Weise gearbeitet haben, können Schwierigkeiten beim Wiederaufbau haben. Wir freuen uns über die Veränderungen, aber manchmal, warum verstecken, haben wir Angst vor ihnen. Ich arbeite seit einem Jahr als Produktmanager und hatte in dieser Zeit fünf große Ängste in meinem Team. Heute werde ich über diese Ängste sprechen und wie wir es geschafft haben, sie zu überwinden.

1. Angst, alles fallen zu lassen

Testen ist ein sicherer Weg, um ein Produkt ohne Fehler freizugeben. Aber manchmal gibt es keine Ausrüstung, um den Code zu überprüfen.

Wir machen DCImanager zu einem Panel für die Verwaltung von Servern und Rechenzentren, und es ist oft unmöglich, Bedingungen zu erstellen, unter denen der Code in einer virtuellen Umgebung funktioniert. Zum Beispiel fügen wir dem Bedienfeld Unterstützung für das neue Switch-, Router- oder PDU-Modell hinzu, aber auf dem Prüfstand befinden sich keine derartigen Geräte.

In einigen Fällen können Tests vernachlässigt werden, unsere jedoch nicht. Der Fehler ist teuer. Sie initialisieren nicht nur eine Variable, und in der Hälfte der Fälle wird das Betriebssystem nicht mehr installiert. Sie irren sich in ein paar Codezeilen - und das Rechenzentrum wird sich „hinlegen“. Wie Sie wissen, möchte niemand für das „gefallene“ Rechenzentrum verantwortlich sein, daher steht diese Angst in meinem Team an erster Stelle (obwohl sie nicht mit Veränderungen im Unternehmen verbunden ist).

Wie man die Angst überwindet, alles fallen zu lassen

1. Alle Teamentwickler führen eine Codeüberprüfung für jede Funktion durch.
2. Wir führen Listen von Dingen, ohne die die Aufgabe nicht freigegeben werden kann.
3. Nach der Entwicklungsversion analysieren wir, dass wir dies nicht berücksichtigt haben. Wir beschreiben detailliert, was getan wurde und welches Verhalten beobachtet wurde, damit Sie jederzeit zur Aufgabe zurückkehren und alles im Speicher wiederherstellen können.
4. Ständige Aktualisierung der Wissensdatenbank. Wir widmen der Dokumentation für Entwickler Zeit und teilen ihr Wissen untereinander. Training und Stand-Ups.
5. Und zu guter Letzt. Wir testen kundenspezifische Entwicklungen für Kunden mit ihnen an den bereitgestellten Geräten.

Sobald wir die Portaggregationssteuerung für vorhandene Switches hinzugefügt haben. Wenn ein Fehler gemacht würde, würde der Betrieb der Netzwerkausrüstung im Rechenzentrum vollständig gestoppt. Der Kunde kam um drei Uhr morgens in seinem Rechenzentrum an und kontrollierte die Situation, sodass er in diesem Fall schnell zur alten Version zurückkehren und den Gerätebetrieb wieder aufnehmen konnte. Wir könnten den Fernzugriff verlieren und das Rechenzentrum wäre gelähmt.

2. Angst, ohne Tester zu bleiben

Unsere Entwickler schreiben Komponententests, und einzelne Personen führen manuelle Tests durch. Aber sobald es höhere Gewalt gab, blieb das Team ohne manuellen Tester. Wir konnten keine Funktionen veröffentlichen, daher mussten sich die Entwickler gegenseitig überprüfen.

Es war ein Schlag, stolz zu sein. So kam es, dass alle Programmierer meines Teams die Tester verlassen haben (manuell und automatisch). Gehen Sie zurück zum manuellen Testen für sie - machen Sie einen Schritt zurück. Die Jungs hatten Angst, dass die Tester nicht zu ihnen zurückkehren würden, wenn sie alleine zurechtkommen könnten. Aber die Angst stellte sich als unbegründet heraus, nach ein paar Sprints nahm der Tester seinen Platz im Team ein und aus der Erfahrung lernten wir viele nützliche Dinge.

Was ist der Vorteil von Kreuztests?

1. Sie erinnerten sich an „Jugend“ und betrachteten erneut die Entwicklung von der Seite des Testers. In einigen Fällen wurden zusätzliche Aktionen hinzugefügt, um dem Tester das Leben zu erleichtern. Zum Beispiel das Generieren von Statistiken zur Überprüfung.
2. Sie bestätigten die seit langem bekannte Tatsache, dass der Entwickler seinen Code nicht testen kann, da er einige Dinge ignoriert. Deshalb haben die Jungs den Code des anderen getestet.
3. Wir waren erneut davon überzeugt, dass Tester ein wichtiger Teil des Teams sind. Sie sind für die Qualität der in der Version veröffentlichten Funktionen verantwortlich.

3. Angst, in ein anderes Team zu kommen

DCImanager wurde 2013 veröffentlicht. Seit sechs Jahren hat sich die Technologie geändert, es ist Zeit, eine neue Version zu erstellen. Wir haben uns dazu entschlossen, dies von Grund auf neu zu tun. Wir haben Prototypen gezeichnet, MVP bestimmt und Prioritäten gesetzt. Die Entwicklung der alten Version war eingefroren, aber sie konnten die neue nicht starten - zwei neue Produkte wurden bereits für die Veröffentlichung vorbereitet, alle Kräfte waren ihnen gewidmet, wir mussten etwas warten. Während der Pause sollten meine Entwickler das Projektteam von BILLmanager werden , unserem anderen Produkt für die Hosting-Automatisierung.

Und dann zeigte sich eine andere Angst. Die Entwickler von Engineering im wahrsten Sinne des Wortes Produkt hatten Angst, die Abrechnung aufzunehmen. Es schien ihnen, dass dies nicht ihr Gebiet war, dass es uninteressant war, einen Haufen Konten zu verstehen. Ich war besorgt, dass es meine Entwickler demotiviert. Im Gegensatz zu uns freute sich das Abrechnungsteam über das Entladen.

Für ein paar Sprints haben wir an BILLmanager gearbeitet, und diese Erfahrung war auch nützlich.

Kurz darüber, wie die Implementierung stattgefunden hat

1. Um den Stress beim Wechsel zu einem anderen Produkt zu minimieren, blieb das Team ein Team und war nicht auf die Mitarbeiter von BILLmanager angewiesen.
2. Die Aufgaben wurden nach dem Prinzip "müssen gestern erledigt werden, aber nicht genug Hände" ausgewählt. Produktologen diskutierten die Aufgaben und übersetzten sie bei der Planung des nächsten Sprints in das Team.
3. Die Entwickler von BILLmanager waren unsere Mentoren. Der Rezeptionist beantwortete alle Fragen und der Teamleiter erklärte, was und wie es funktionieren sollte
4. Wir hatten zwei Standups. Zuerst gingen wir zur Abrechnung, dann diskutierten wir die Ergebnisse in unserem Team.

Welche Vorteile haben die Entwickler aus der Einführung in ein anderes Team gebracht?

1. Ein anderes Produkt ist der Code eines anderen, den Sie verstehen müssen. plus andere Arbeitslogik zu verstehen. Dank des Mentorings des Teamleiters und der Geduld des Endmanagers haben wir uns erfolgreich an die Abrechnung gewöhnt, neue Fähigkeiten gepumpt und die Verbesserungen recht schnell durchschaut.
2. Natürlich haben wir ausspioniert, wie manche Dinge in einem anderen Team funktionieren. Es mag scheinen, dass für alle gleich ist, aber egal wie. Die Unterschiede liegen im Detail. Sie nahmen in der Regel das Beste und Bequemste für sich selbst (zum Beispiel spionierten sie aus und begannen, nachdem sie sich leicht verändert hatten, ein Scrum Board zu verwenden, einige Punkte im Codestil zu übernehmen usw.).

4. Angst, Mentor zu werden / ohne Teamleiter zu bleiben

Das Unternehmen benötigt so viele starke Programmierer wie möglich. Wenn ein Entwickler seine Fähigkeiten verbessert und auf die mittlere Ebene wechselt, liegt seine Verantwortung in der Ausbildung von Anfängern. Das gesamte Mentoring liegt jedoch normalerweise beim Teamleiter. So war es in unserem Team, bis die Erfahrung eines führenden Entwicklers in einem anderen Produkt dringend benötigt wurde. Die Programmierer, die ohne Teamlade blieben, mussten das Training sowohl für Anfänger als auch für einander übernehmen.

Mentor zu sein ist beängstigend. Sie müssen von Ihren Aufgaben abgelenkt sein, sich auf eine andere Person einstellen, erklären, was Sie selbst manchmal auf der Ebene der Intuition verstehen, und so erklären, dass es verstanden wird. Wenn der Padawan nicht verstanden hat, ist dies Ihr Problem. Wenn er einen Fehler gemacht hat und Sie es nicht bemerkt haben, antworten Sie.

Ich werde keinen Rat geben, wie man ein guter Mentor wird, dies ist ein Thema für einen separaten Artikel. Aber wir haben es geschafft und aus dieser ziemlich stressigen Erfahrung haben wir Folgendes gelernt:

1. Bei der Erklärung muss mehr Kontext angegeben werden. Alles ist schön im Kopf, und wenn man es erzählt, stellt sich heraus, dass es herausgerissen und unverständlich ist.
2. Man sollte sich nicht nur einen Code in einer Rezension ansehen, sondern auch verstehen, was eine Person versucht hat, mit diesem Code zu lösen. Dann ist es einfacher, die Logik zu verstehen und Fehler zu finden.
3. Wissensaustausch ist hilfreich: lernen, Gedanken zu formulieren; stelle alles in die Regale in deinem Kopf; Während Sie erklären, finden Sie die beste Lösung für das Problem.

5. Angst, keine neuen Technologien zu lernen

Wenn die Pause vorbei ist, ist es Zeit, eine neue Version des DCImanager-Produkts zu starten. Es scheint, dass hier der lang erwartete Moment ist. Jetzt, mit einem Team voller ehrgeiziger Leute, werden wir alles von vorne beginnen - ohne alte Fehler und historisch entwickelte seltsame Abhängigkeiten im Code zu betrachten. Aber es gab einen Platz für Angst.

Seit einigen Jahren ist die Technologie weit fortgeschritten. Wir haben die alte Version in C ++ 11 geschrieben und mit make für die neue Version C ++ 17, CMake, Conan und Docker gewählt. Das Team muss all dies lernen und lernen, sich zu bewerben. Der nächste Weg aus der Komfortzone, die Herausforderung und der Gedanke "Was ist, wenn ich nicht schlechter sein kann und werde als die anderen?", "Was ist, wenn mehr Probleme auf mich warten? Ich werde es nicht herausfinden und mich rausschmeißen." Wir beherrschen immer noch neue Technologien und der Kampf gegen diese Angst ist noch im Gange.

Wie man neue Technologien schneller lernt

1. Seien Sie nicht schüchtern, ältere und erfahrene Kollegen zu fragen, haben Sie keine Angst dumm zu wirken.
2. Dokumentieren, um den Prozess des Eintauchens von Neuankömmlingen zu beschleunigen und nicht zehntausend Mal dasselbe zu erzählen. Pflegen Sie eine Wissensbasis.
3. Okay, Google ist immer da, um zu helfen. Wenn es nicht funktioniert, siehe Punkt 1.

Keine Ängste, sondern Herausforderungen

Ich nehme Experimente zum Anlass, neue Dinge zu lernen, besser zu werden, und ich versuche, mein Team dazu zu bringen, auch ihre Ängste zu betrachten. Ich denke, dass die Stimmung der Jungs sehr von mir abhängt. Wenn Sie an ein Produkt und an Entwickler glauben, ihnen im Stand-up zuhören und Probleme im Nachhinein analysieren, sie in Schwierigkeiten unterstützen und die Notwendigkeit von Änderungen erklären, ist es für sie einfacher, Ängste zu überwinden.

Aber seien wir ehrlich, wir haben immer noch ein paar unbesiegte Phobien auf Lager. Zum Beispiel Angst vor Fristen oder Angst, mit Anfängern nicht klar zu kommen. Bisher scheint es, dass nichts dagegen unternommen werden kann - nur aufstellen. Aber vielleicht wird sich unsere Sichtweise mit der Zeit ändern.

Warum hast du Angst?

PS Wenn Sie der Erste sein möchten, der die Demoversion von DCImanager sieht, senden Sie Kontakte an bizdev@ispsystem.com mit dem Betreff „Ich möchte den neuen DCImanager sehen“. Wenn es fertig ist, werden wir Ihnen schreiben. Oder wenn Sie ein Produkt für die Serververwaltung benötigen, der aktuelle DCI-Manager jedoch aus irgendeinem Grund nicht passt und es keine geeignete Lösung auf dem Markt gibt, schreiben Sie Ihre Wünsche für eine solche Software. Vielleicht nehmen wir etwas in den Entwicklungsplan auf.