In dem Artikel werde ich über meine Erfahrungen als Teamleiter in einem Standortentwicklungsunternehmen sprechen. Damit es für alle nützlicher und leichter zu lesen ist, ist der Artikel in Kapitel unterteilt, in denen jeweils ein einzelnes Problem und seine Lösung beschrieben werden. Die Chronologie der Ereignisse bleibt jedoch nach Möglichkeit erhalten.
Ich hoffe, dass die unten beschriebene Erfahrung zum Rechen eines anderen wird, und in den Kommentaren werde ich selbst etwas von erfahreneren Kollegen ziehen.
Aber keine Namen, Firmen, Kunden, Namen von Kollegen. Geheimhaltungsvereinbarung, alles.
Hintergrund. Wie und wo bin ich Teamleiter geworden?
Dies ist das erste Unternehmen, bei dem ich sofort einen Teamleiter bekam. Für mich war es ein Quantensprung in Bezug auf das Karrierewachstum. Ich kam zum letzten Job (1,5 Jahre) als Mittelsmann und wuchs dort zum Senior auf. Die Abstufungen der Entwickler sind jedoch zu subjektiv und hängen oft nur von dem Unternehmen ab, in dem sie arbeiten. Für eine Weile habe ich mich intensiv mit der Frage der Bewertung von Programmierern befasst, und im Grunde kam es darauf an, dass ich, wenn sie Mittel / Senior / Senior nahmen, Mittel / Senior / Senior wurde. Als ich anfing, Arbeit zu suchen, hätte ich genug von einer leitenden Position gehabt (und ich suchte danach), aber das Angebot von Timlidismus überbot mich und war ein wenig geschmeichelt.
Als ich nach offenen Stellen suchte, wurde ich am zweiten Tag zu einem Großstadtunternehmen gelockt, das Websites auf Bitrix entwickelt (also geschieht alles vor dem Hintergrund der Entwicklung von Websites auf Bitrix). Im Gegenteil, ich habe lange davon geträumt, Bitrix zu verlassen, aber die Gelegenheit, mein Potenzial in einer neuen Qualität und einem guten Gehalt auszuschöpfen, ließ mir keine Chance, dies abzulehnen.
Lustige Tatsache: Die einzige Bedingung für die Einstellung war, dass ich den technologischen Stack selbst auswählen kann, aber auf keinen Fall sollte ich Bitrix ablehnen, wenn der Kunde darauf besteht.
An einem neuen Ort
An dem neuen Ort befanden sich ein sehr guter technischer Chef, ein schlechter Manager, June, Middle und mehrere wirklich große Projekte auf Bitrix. Es ist eine ziemlich seltsame Situation und ich verstehe immer noch nicht, wie sie sich entwickelt hat und nicht sofort zusammengebrochen ist. Aber vielleicht wurde ich nur eingeladen, um die Dinge in Gang zu bringen.
In den ersten Tagen waren viele Probleme mit „Kindern“ auffällig:
- Projektinformationen wurden in den Köpfen von ein oder zwei Personen und nirgendwo anders gespeichert. Es gab auch keine Anweisungen und Unterlagen, und um herauszufinden, wie diese oder jene Funktion funktionierte, war es notwendig, denjenigen zu foltern, der sie erstellt hat, wenn wir sie überhaupt erstellt haben
- Es gab keine etablierten Systeme und Prozesse, alles wurde "irgendwie", "aus Gewohnheit" gemacht. Daher Eitelkeit, Verwirrung, Nichteinhaltung von Fristen, Stress
- Aufgaben wurden in Worten betrachtet. Die Tracker hatten nur die Namen der Aufgaben, nur um irgendwo Zeit reservieren zu können (man musste 40 Stunden pro Woche eingeben)
- Die Entwicklung selbst war auch nicht so heiß:
- Irgendwo wurde sogar außerhalb der Gita etwas entwickelt
- Irgendwo bearbeiteten Programmierer abwechselnd Dateien auf einem Server
- Irgendwo gab es Teststellen, aber irgendwo nicht (aber auf jeden Fall haben sie nicht viel geholfen)
- Außerdem gab es überall einen sehr, sehr viel Govnokod. Bitrix selbst nimmt die Kommentare vorweg und hat leider nichts damit zu tun.
- Die gesamte Kommunikation fand über Skype statt. Aber ich habe nur eine persönliche Abneigung gegen ihn
Im Allgemeinen ist offensichtlich alles schlecht, Verbesserungen können sofort beginnen, ohne Vorstudien durchzuführen. Das hat mich sogar einigermaßen glücklich gemacht, da Sie die Indikatoren von den ersten Monaten an beeinflussen können. Sie wurden wirklich noch nicht berücksichtigt, aber aufgrund von Pareto ist dies noch nicht wichtig.
Zu meiner Enttäuschung bewegten sich die Prozesse in den ersten Monaten eher langsam. Erstens musste ich selbst als Programmierer 8 Stunden am Tag an Kundenaufgaben arbeiten, weil ich einfach nicht genug Hände hatte. Zweitens war es unter den Bedingungen eines solchen Zeitdrucks ziemlich gefährlich, große Änderungen vorzunehmen, die zu Verwirrung und Verlust von Code oder Zeit führen konnten.
Nun gehen wir direkt zum Artikel und zur Problemlösung. Das erste in der neuen Firma war, sich irgendwie zu orientieren.
Informationen aus den Zielen der Mitarbeiter ziehen
Als ich ankam, wusste ich absolut nichts über Projekte oder Kunden, und diese Informationen wurden nicht gespeichert.
Nirgendwo in Textform. Daher begann ich als erstes, Informationen aus den Zielen der Kollegen in den Texten zu ziehen.
Im Wesentlichen verfügt eine Entwicklungsfirma über zwei große Untergruppen wichtiger und / oder nützlicher Texte:
- Anweisungen, Vorschriften, Artikel, Funktionsbeschreibungen, User Stories, ...
- Aufgaben mit Namen, Beschreibung, Kommentaren, Zeitprotokollen, Signaturen für Commits, Kommentaren im Code, Autotests, ...
Am Anfang habe ich nur meine neuen Kollegen gebeten, bestimmte Dinge aus dem ersten Absatz für mich aufzuschreiben, aber natürlich waren alle faul, zumal das Schreiben von Anweisungen kein zu schneidendes Feature ist. Aber da ich anfangs immer noch ein rauchfreies Aussehen hatte und die Projekte studieren musste, um sie zum ersten Mal zu sehen, begann ich gerade, meine Recherchen in Text zu übersetzen, um Anweisungen und Beschreibungen der Funktionalität zu erstellen.
Es war auch ein Glück, dass das Unternehmen zur gleichen Zeit aktiv auf Scrum umstieg (nur ein Zufall), funktionierende Software sich änderte (auch ein Zufall) bzw. Geschäftsprozesse von Grund auf neu erstellt wurden. Und aus irgendeinem Grund hatte ich anfangs große Autorität in den Augen meiner Kollegen. Deshalb habe ich gerade angefangen, die Regeln selbst zu schreiben (innerhalb der Kompetenz) und die Jungs darauf neu aufzubauen, das heißt, ich diktiere nur die Regeln und bin ein Beispiel für ihre Implementierung.
Die Lösung des Problems bei der Formulierung und Verwaltung von Aufgaben verzögerte sich um mehr als einen Monat. Dies stellte sich als Engpass heraus und in den folgenden Kapiteln werde ich dieses Thema mehr als einmal ansprechen.
Zu Beginn meiner Arbeit stellte der Manager schreckliche Aufgaben. Beispiel: Der Name der Aufgabe lautet "Fehler auf der Site beheben" und das war's: Keine Beschreibung, keine Screenshots, nur der Name und der Verweis auf das Projekt. Natürlich gab es Versuche, dem Manager die Prinzipien von SMART und die Wichtigkeit der Beschreibung der Aufgaben zu vermitteln, aber alle Verpflichtungen wurden auf "Ich habe keine Zeit, Aufgaben zu malen" aufgeteilt.
Einmal habe ich versucht, mich an der Verantwortung für das Festlegen von Aufgaben zu beteiligen, aber es ist ironisch, dass ich auch nicht genug Zeit dafür hatte, da ich fast die ganze Zeit Code geschrieben habe.
Aufgrund des damit verbundenen Problems, jederzeit den aktuellen Status der Aufgaben zu erhalten, haben wir uns entschlossen, diese durch Koordinierungsanweisungen und Tagespläne zu umgehen.
Nachschub der Mitarbeiter, Teamintegration
Fast anfangs war klar, dass es den Menschen schmerzlich fehlte (ich selbst habe den Vollzeitcode geschrieben, aber wir hatten immer noch keine Zeit).
Die ersten entschieden sich für die Front, da beide Proger im Unternehmen Backs waren (und ich mich auch mehr mit dem Backend identifizierte) und es genügend Aufgaben gab, insbesondere im Layout, und Aufgaben in Bezug auf Reaktion und Vue begannen sich am Horizont abzuzeichnen.
Es war ein großes Glück, dass ich eine Freundesfront hatte (und habe), die gleichzeitig darüber nachdachte, freiberuflich tätig zu werden, sodass wir die freie Stelle schnell besetzen konnten, und ich erhielt einen Bonus dafür, dass ich zuvor einen Mitarbeiter (ein weiteres Plus an die Behörden) mitgebracht hatte gesehen hr-Auszeichnungen).
Fast unmittelbar nach der Front wurden 2 Becks gefunden. Und irgendwo zur gleichen Zeit ging der Joon (dessen Code mich einige Monate nach seiner Abreise stieß).
Insgesamt entwickelte sich folgende Situation:
- ein "alter Mann"
- ich
- drei absolute Anfänger
- Arbeit ist noch nicht etabliert
- Einige Kenntnisse sind bereits verloren
Es ist natürlich, dass Dutzende von Fragen von Neuankömmlingen als Teamleiter sofort auf mich herabregneten. Grundsätzlich handelte es sich dabei um Fragen zum Lebenszyklus des Codes (wo Code geschrieben werden soll, wie gezeigt werden soll, wohin er später gesendet werden soll, wie das Release gesammelt werden soll), zur Aufgabenverwaltung (wie Aufgaben in die Arbeit übernommen werden, wie der Status angezeigt wird, wie Prioritäten festgelegt werden) und zur Arbeit mit Git . Außerdem versuchten die Jungs immer noch, die Fragen zu stellen: "Wie funktioniert A?", "Haben wir ein B auf unserer Website?", Aber fast alles in diesem Moment wurde nur auf die Notwendigkeit reduziert, den Code zu studieren.
Zunächst war es wichtig, Programmierern grundsätzlich die Möglichkeit zu geben, selbstständig zu arbeiten und Code zu schreiben. Ich führte einführende Gespräche mit ihnen und beantwortete ihre Fragen. Dann beschloss ich natürlich, alle Fragen und Schemata in einen Artikel zu reduzieren, der dann zu einem Vortrag und dann zu einem völlig neuen Arbeitsschema im Unternehmen wurde, das ich im nächsten Kapitel diskutieren werde.
Hier lohnt es sich, ein paar Worte über den Einstellungsprozess in unserem Unternehmen zu sagen, der noch funktioniert.
Einstellungsprozess
Erstens haben wir einen Bonus für die Gewinnung eines Mitarbeiters, was eine ziemlich gute Praxis ist.
Zweitens haben wir uns entschlossen, keine Prüfung beim Interview zu arrangieren, sondern eine sehr umfangreiche Aufgabe zu geben, die unseren alltäglichen nahe kommt. Dies ist insofern praktisch, als der Zeitaufwand für die Einstellung nur so lange reduziert wird, bis die Suche nach geeigneten Lebensläufen und ein einfaches Interview mit Bewerbern durchgeführt werden, um die Angemessenheit und eine Geschichte über die Testaufgabe zu überprüfen und natürlich die Aufgabe direkt zu überprüfen.
June kann das Problem tatsächlich an ein paar Abenden lösen, voluminös macht es viel Freiheit bei der Implementierung, Verbesserungen und offensichtlichen Chips. Es ist diese Flexibilität der Implementierung, die uns hilft, das Niveau des Antragstellers zu bewerten. Wir sagen sofort, dass es für uns am wichtigsten ist, die Fristen für die Lösung des Problems einzuhalten (der Testamentsvollstrecker ruft sich selbst an) und am Ende den Arbeitscode im Repository anzuzeigen. Wir schreiben keine Verwendung von Ansätzen und Technologien vor, sie werden vom Darsteller ausgewählt, aber um sich zu treffen und Tipps zu geben, haben wir mögliche Verbesserungen in der Liste aufgeführt, wie Aufgaben mit einem Sternchen, z. B. Arbeiten mit Ajax, ext. Rückvalidierung, Spamschutz, Moduldesign, Verwendung von D7, ...
Gesamt:
- Anhand der Zusammenfassung und des Interviews können wir die Art der Person beurteilen
- Bis zum Stichtag für die Erledigung der Aufgabe, der Tatsache, dass der Kodex funktioniert und die Gita verwendet wird, treffen wir die Entscheidung über die Einstellung
- Anhand der Leistungsqualität bestimmen wir das Niveau und dementsprechend das Gehalt, das wir anbieten können
- Außerdem zeigen wir bereits bei der Testaufgabe, welche Aufgaben an einem neuen Ort gelöst werden müssen
Einrichtung eines Codeentwicklungs- und -lieferungssystems
Zu dieser Zeit hatten wir mehrere Projekte, die ziemlich zufällig entwickelt wurden:
- Irgendwo in der Schlacht gab es einen Meister, irgendwo anders einen Zweig
- Irgendwo gab es Teststellen, irgendwo nicht
- und wenn ja, dann sind alle Adressen unterschiedlich
- Git wurde im Prinzip schwach und knarrend eingesetzt
- manuelle Datenbankänderungen
- ...
Zuerst habe ich versucht, die Situation in kleinen Portionen zu korrigieren, so dass Programmierer weniger zum Neulernen brauchten, und war dementsprechend verwirrt. Zum Beispiel habe ich den Bitrix-Ordner unter der Gita herausgenommen und den Hauptzweig wieder in Master umbenannt.
Aber als eine große Wiederauffüllung zu uns kam, wurde die Situation kritisch. Ich musste viel erklären, daran erinnern und unlogische Anweisungen schreiben, da die aktuelle Entwicklungsstruktur überhaupt nicht sehr intuitiv war.
Ich bin kein Fan von Anweisungen als solche. Ich glaube, dass ihre Anwesenheit ein Indikator für das Problem an sich ist. Daher wurde beschlossen, ein gemeinsames System für alle Projekte zu schaffen, das einmal verstanden werden muss und das aufgrund seiner Struktur viele Probleme und Fragen beseitigt.
Das System ist wie folgt:
- Jeder Entwickler verfügt über eine Remote-Arbeitsplattform, auf der er arbeitet
- Es gibt eine Plattform, auf der Funktionen für die nächste Version gesammelt werden
- Bei Bedarf gibt es eine Demonstrationsplattform, auf der alle Anfänge der Funktionalität demonstriert werden können
- Der gesamte Code für eine Aufgabe wird in einem separaten Zweig gespeichert, wobei der Name des Zweigs dem Namen der Aufgabe im Tracker entspricht
- Um den Code auf einer gemeinsamen Plattform zu füllen, müssen Sie nur den Zweig irgendwo halten und drücken
- Änderungen an den Datenbanken werden als Migrationsdateien im Taskzweig gespeichert
Ich habe einen großen Vortrag zum Thema dieses Systems gehalten, und wir haben einen Pilotübergang bei einem Projekt begonnen, bei dem wir gerade den neu erworbenen Senior geworfen haben.
Der Prozess der Übertragung aller Projekte auf dieses System hat sich natürlich verzögert (zum Beispiel konnten wir bei einem Projekt beim ersten Mal nicht mystisch zum Master wechseln), und er wird immer noch fortgesetzt, aber als Ergebnis haben wir zumindest Folgendes erhalten:
- die Fähigkeit, nur die erforderlichen Aufgaben freizugeben und nicht die unvollendete Funktionalität zusammen mit nützlichem Code freizugeben
- Führen Sie eine Aufgabenfreigabe durch, ohne einen Code-Autor einzubeziehen
- parallele Arbeit an einem Projekt zwischen Darstellern
- Code nicht verlieren
- Testen Sie die von einem anderen isolierte Funktionalität und stoppen Sie die Arbeit des Programms nicht
All dies gab es vorher einfach nicht. Außerdem müssen Sie neuen Programmierern jetzt nicht mehr die zusätzlichen Details der Arbeit mit Git- oder Testseiten erklären, da alles universell und intuitiv ist.
Scrum, Kommunikation, Vorschriften
Natürlich wollte ich in dem Artikel darüber sprechen, wie ich als Teamleiter zur Entwicklung des Unternehmens beigetragen habe, aber Sie können nicht über die Entwicklung unseres Unternehmens sprechen, ohne unseren Chef und seine Initiative zu erwähnen, sonst wird es nicht ganz ehrlich sein.
Erstens führte er Scrum ein, und zum Zeitpunkt meiner Ankunft wurden die Prozesse im Unternehmen aktiv neu gestaltet. Auch in diesem Moment übertrug sie von Bitrix24 zu Jira.
Scrum brachte sicherlich mehr Rhythmus in die Firma und reduzierte das Chaos. Die Umschulung von Managern, die Ausführung von Koordinierungsaufrufen, das Öffnen / Schließen / Planen von Sprints wurde vom Leiter selbst als Senior in diesem Link überwacht.
Er hat auch viel an den Managern selbst gearbeitet, insbesondere daran, wie sie mit Kunden und Programmierern kommunizieren, da der größte Teil ihrer Arbeit (aber natürlich nicht beschränkt auf) in der Kommunikation besteht: Programmierer von Kunden isolieren, Kundenwünsche an Aufgaben im Backlog und in Sprints finden und erzählen User Stories. All dies führte zu vielen Vorschriften: zur Kommunikation mit Kunden, zum Festlegen von Aufgaben, zum Arbeiten mit einem Rückstand, zum Akzeptieren von Fehlern bei der Arbeit. Die Kommunikation wurde stark betont und die Managementverbindung zeigte wirklich Fortschritte.
Der Übergang zu Scrum selbst ist natürlich sehr schwierig, und zum Zeitpunkt des Schreibens dieses Artikels sind wir noch nicht zu seinen Fachleuten geworden, obwohl dies alles dazu gehört. Und ich bin sehr froh, dass ich viele neue Kenntnisse über die flexiblen Methoden und Produkte von Atlassian erhalten habe.
Neuer Manager. Texte, Aufgabenstellung, Rückstand
Irgendwann kam eine andere Person, um uns zu helfen, einen Quantensprung zu machen - ein neuer Manager (davor hatten wir einen).
Ich habe diesen Moment nicht erwartet, da wir nicht so viele Projekte und Programmierer hatten und theoretisch nur ein Manager hätte ausreichen sollen. Diese Verbindung war eine Schwachstelle im Unternehmen, aber wir haben versucht, dieses Problem durch die Entwicklung vorhandener Mitarbeiter zu lösen. Es ist einfach so passiert, dass ein ausgezeichneter Manager, den ich gut kenne, beschlossen hat, den Job zu wechseln. Mein Chef hat davon erfahren, als sie plötzlich unsere Auftragnehmer interviewte und ich diesen lustigen Vorfall erwähnte, und wir haben sie zu uns gerufen. Eine weitere Auszeichnung)
Zuerst wiederholte die neue Managerin einen Teil meines Weges, da sie mit denselben Problemen konfrontiert war (sie weiß nichts und kann nirgendwo lesen) und von vorne anfing, aber mit dem Unterschied, dass sie den Code, die Entwicklungsinfrastruktur und die Programmfähigkeiten nicht berührte, sondern damit arbeitete Ziele setzen, mit Kunden kommunizieren, den Rückstand bereinigen und auch fleißig Informationen vom Leiter des alten Managers abrufen. Das erste, was ich herausgezogen habe, ist die Kontaktliste der Kunden und Auftragnehmer.
Das Team kannte sie bereits, als wir sie einmal als Dozentin einluden, um uns über Zeitmanagement zu erzählen. Außerdem wurden die Aufgaben des Stahls detaillierter gestellt, sie fügte keine Negativität hinzu und übertrug sie nicht vom Kunden, der Status der Aufgaben wurde zu jeder Zeit relevanter. Deshalb haben wir sofort große Hoffnungen auf sie gesetzt.
In den ersten Wochen räumten er und sein Chef den Rückstand bei einem Projekt auf, insbesondere fanden sie eine überfällige Periode von 2 Monaten und ein Epos, das noch nicht begonnen hatte. Darüber hinaus sind im Prinzip viele Aufgaben aufgetaucht, die vor einem Monat erledigt werden mussten. Es ist natürlich gut, dass der Rückstand bereinigt wurde, aber es wurde zu spät gemacht.
Sie selbst hat wirklich „aufgelegt“ und wiederholt versucht zu gehen, aber wir haben die Verbindung zum Management auf die eine oder andere Weise verbessert. Es ist weniger wahrscheinlich, dass Aufgaben im Backlog verloren gehen, und es ist weniger wahrscheinlich, dass Programmierer erneut fragen.
Die Moral der Geschichte wird am Ende sein.
Die Krise
Fast ein halbes Jahr nach Arbeitsbeginn musste ich Urlaub machen. Übrigens habe ich mich auch bei der Bewerbung für einen Job auf einen Urlaub geeinigt, da dieser als Flitterwochen geplant war, so dass die Zeit meiner Abwesenheit sehr im Voraus bekannt war. Aber natürlich war ich bis zuletzt nervös, weil wir erst vor kurzem aufgehört haben, „für Abnutzung“ zu arbeiten.
In der Woche vor den Feiertagen beendete ich das Delegieren von Aufgaben, brachte ausgewählten Personen bei, bestimmte Aufgaben außerhalb des Codes auszuführen, wies jedem Programmierer die Verantwortung für ein bestimmtes Projekt zu, erledigte oder übertrug alle meine aktuellen Aufgaben (ich programmierte den größten Teil des Tages noch). Mitte Juli gab es keine Katastrophen.
Und auch in den ersten Urlaubstagen deutete nichts auf Ärger hin.
Und dann gab es eine Krise.
Bei einem Projekt hatte der Kunde keine Geduld mehr, da seine Erwartungen an Aufgaben (Fristen, Liste, Prioritäten) nicht dem Fall entsprachen. Wir selbst haben dies vor nicht allzu langer Zeit mit der vollständigen Bearbeitung des Rückstands und der aktiven Kommunikation mit dem Kunden bemerkt (Kapitel über den neuen Manager), aber es war zu spät.
Und beim zweiten Projekt haben sie endlich eine sehr große und lang erwartete Aufgabe angenommen, die Tests abgeschlossen und freigegeben. Aber die neue Funktionalität hat die Kampfstelle plötzlich unter schwerer Last niedergeschlagen, und die mittlere und vordere Mitte konnten eine Woche lang nichts dagegen tun. .
, . , . , , .
vue, ( , ).
— , , , - , “ / / / ”.
, , , , .
, , , , , .
, . , - . , - .
. ( ), - :
- , - , - , . .
, . , , , .
. , , , . , , .
, vue, .
, - 5. -, . , .
, : , , , .
, - , - . , , , , , .
.
. , , , - , , .
, , , 1 , - , , , , , . , .
,
. .
, , 3-4 “ 3 ”, 40.
, , .
/ — ( ). , . , . , , -, 8 .
. :
- :
( ), :
— . :
:
, . , .
, . .
—
, , , , , “ ” , .
, , “” - .
, , , , , 2 . , , .
, , / , . , , .
, . , , / - , , - .
(, )
- . , , , , , , , .
, , . , , .
: , , , , . , .
, - , . , .
:
, , , .
, , , ( ), , , .
, ( , 2 , ).
, , . “ ”, :
, .
Teil 2
Dieser Artikel behandelte ungefähr sechs Monate meiner Arbeit in einer neuen Position. Im zweiten Teil möchte ich darüber sprechen, wie wir uns mit Hilfe von:
- Autotests, die wir gerade erst implementieren. Seltsam, aber aus irgendeinem Grund gibt es keine würdigen Beispiele für Bitrix.
- Vererbung im Code loswerden
- die Entwicklung weiter beschleunigen und vereinfachen
- was ich aus den Kommentaren lernen werde
- viele andere geheime Dinge (plötzlich lesen mich meine Jungs)
Vielen Dank für das Lesen. Ich würde mich sehr freuen, dies zu kommentieren, insbesondere wenn Sie optimalere Möglichkeiten zur Lösung der aufgetretenen Probleme kennen.
Viel Glück und Freude an alle in Arbeit und Leben!