Arbeit als Team im Jahr 2018

    In dem Artikel werde ich über meine Erfahrungen als Teamleiter in einer Website-Entwicklungsfirma sprechen. Um es für alle lesbarer zu machen, ist der Artikel in Kapitel unterteilt, von denen jedes über ein bestimmtes Problem und dessen Lösung spricht. Obwohl möglich, wird die Chronologie der Ereignisse beibehalten.


    Ich hoffe, dass die unten beschriebene Erfahrung der Schwarm eines anderen wird, und in den Kommentaren werde ich selbst etwas von erfahreneren Kollegen bekommen.


    Aber keine Namen, Firmen, Kunden, Namen von Kollegen. Geheimhaltungsvereinbarung, alle Angelegenheiten.


    Vorgeschichte Wie und wo bin ich Teamleiter geworden?


    Dies ist das erste Unternehmen, bei dem ich sofort zum Teamleiter ging. Für mich war es ein qualitativer Sprung in Bezug auf die Karriereentwicklung. Beim letzten Job (1,5 Jahre) bin ich in die Mitte gekommen und dort zum Lord aufgewachsen. Die Abstufungen von Entwicklern sind jedoch zu subjektiv und hängen oft nur von dem Unternehmen ab, in dem sie arbeiten. Eine Weile habe ich mich intensiv mit der Bewertung von Programmierern beschäftigt, und in der Tat drehte sich alles um die Tatsache, dass "wenn sie Mittel / Senor / Ältere nahmen, sie Mittler / Senor / Ältere wurden". Als ich anfing, nach einem Job zu suchen, reichte mir die Position des Lords (und ich suchte danach), aber das Angebot der Leitung brachte mich heraus und war etwas schmeichelhaft.


    Auf der Suche nach freien Stellen wurde ich am zweiten Tag zu einer Kapitalgesellschaft gelockt, die Websites auf Bitrix entwickelt (damit alles vor dem Hintergrund der Entwicklung von Websites auf Bitrix geschieht). Ich habe im Gegenteil schon lange davon geträumt, Beatrix zu verlassen, aber die Gelegenheit, mich in einer neuen Eigenschaft und einem guten Gehalt zu erkennen, ließ mir keine Chance zu verweigern.


    Eine lustige Tatsache: Die einzige Voraussetzung für die Annahme, dass ich mich auf der Arbeit durchsetzen konnte, war, dass ich den technologischen Stapel selbst wählen konnte, aber ich konnte Beatrix auf keinen Fall ablehnen, wenn der Kunde darauf besteht.


    An einem neuen Ort


    Am neuen Ort gab es einen sehr guten technischen Manager, einen schlechten Manager für Juni, Mitte und mehrere wirklich große Projekte bei Bitrix. Eine seltsame Situation, und ich verstehe immer noch nicht, wie es gebildet wurde und nicht sofort zusammenbrach. Aber vielleicht haben sie mich eingeladen, alles zu reparieren.


    In den ersten Tagen fielen mir viele „kindliche“ Probleme auf:


    • Informationen zu Projekten wurden in den Köpfen von ein oder zwei Personen gespeichert und an keinem anderen Ort. Es gab auch keine Anweisungen und Dokumentation, und um herauszufinden, wie diese oder jene Funktionalität funktioniert, musste die Person, die sie gemacht hat, gefoltert werden, wenn wir sie überhaupt erstellt haben.
    • Es gab keine etablierten Systeme und Prozesse, alles wurde "irgendwie", "nach Gewohnheit" erledigt. Daher Eitelkeit, Verwirrung, Terminbruch, Spannung
    • Aufgaben wurden in Worten gezählt. Es gab nur Aufgabennamen in den Trackern, nur um sich irgendwo einloggen zu können (Sie mussten 40 Stunden pro Woche wählen)
    • Die Entwicklung selbst war auch nicht so heiß:
      • irgendwo wurde etwas außerhalb der Gita entwickelt
      • irgendwo haben Programmierer auf einem Server Regeldateien abgelegt
      • Irgendwo gab es Teststandorte, aber irgendwo waren sie nicht (aber auf jeden Fall haben sie nicht viel geholfen)
      • Darüber hinaus gab es überall viel Govnokod. Vorweggenommene Kommentare, Bitrix selbst hat leider nichts damit zu tun

    • Die gesamte Kommunikation fand in Skype statt. Aber zu ihm habe ich nur eine persönliche Abneigung

    Im Allgemeinen ist alles offensichtlich schlecht, Verbesserungen können sofort gestartet werden, ohne Voruntersuchungen durchzuführen. Dies hat mich sogar einigermaßen erfreut, da die Indikatoren bereits in den ersten Monaten beeinflusst werden können. Sie sind wirklich nicht in Betracht gezogen worden, aber wegen Pareto ist es noch nicht wichtig.


    Zu meinem Entsetzen bewegten sich die Abläufe der ersten Monate eher langsam. Erstens musste ich als Programmierer acht Stunden am Tag an Kundenaufgaben arbeiten, weil ich einfach nicht genug Hände hatte. Zweitens war es unter solchen Zeitdrucken ziemlich gefährlich, große Änderungen vorzunehmen, die zu Verwirrung und Verlust von Code oder Zeit führen könnten.


    Nun kommen wir direkt zum Artikel und zur Problemlösung. Zunächst musste das neue Unternehmen irgendwie navigieren.


    Informationen von den Mitarbeiterköpfen abrufen


    Als ich ankam, wusste ich nichts über Projekte oder Kunden und diese Informationen wurden
    nirgendwo in Textform gespeichert . Deshalb habe ich als erstes angefangen, Informationen aus den Köpfen der Kollegen in den Texten zu ziehen.


    In der Tat, das Unternehmen in der Entwicklung tätig, gibt es zwei große Untermengen von wichtigen und / oder nützlichen Texten:


    1. Anweisungen, Vorschriften, Artikel, Funktionsbeschreibungen, User Stories, ...
    2. Aufgaben mit Name, Beschreibung, Kommentaren, Zeitprotokollen, Überschriften für Commits, Kommentaren im Code, Autotests, ...

    Zuerst habe ich gerade neue Kollegen gebeten, einige spezifische Dinge aus dem ersten Absatz für mich zu malen, aber sie waren natürlich zu faul, zumal die Anweisung, zu schreiben, nicht darin besteht, die Funktionen abzuschneiden. Da ich aber anfangs noch völlig unbeeindruckt war und die Projekte zum ersten Mal sehen musste, habe ich gerade angefangen, meine Recherchen in Text zu übersetzen und so Anweisungen und Beschreibungen der Funktionen zu erstellen.


    Es war auch ein Glück, dass sich das Unternehmen zur gleichen Zeit aktiv zu Scrum bewegte (nur ein Zufall), die Arbeitssoftware geändert wurde (auch ein Zufall) und Geschäftsprozesse von Grund auf neu erstellt wurden. Und aus irgendeinem Grund hatte ich zunächst eine große Autorität in den Augen meiner Kollegen. Deshalb habe ich einfach angefangen, die Vorschriften selbstständig (im Rahmen meiner Kompetenz) zu schreiben und ihnen Kinder wieder aufzubauen, das heißt, im Wesentlichen einfach die Vorschriften zu diktieren und ein Beispiel für ihre Ausführung zu sein.


    Die Lösung des Problems bei der Formulierung und Verwaltung von Aufgaben wurde um mehr als einen Monat verzögert. 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 die Aufgaben schrecklich. Beispiel: Der Name der Aufgabe lautet "Fehler in der Site beheben" und das ist alles: keine Beschreibung, keine Screenshots, nur Name und Verweis auf das Projekt. Es gab natürlich Versuche, die Prinzipien von SMART und die Bedeutung der Beschreibung der Aufgaben an den Manager zu vermitteln, aber alle Unternehmen waren in "Ich habe keine Zeit, um die Aufgaben zu zeichnen".


    Ich habe einmal versucht, einen Teil der Verantwortung für die Festlegung der Aufgaben zu übernehmen, aber es war ironisch, dass ich auch nicht genug Zeit dafür hatte, da ich fast immer Code geschrieben habe.


    Aber das nebenstehende Problem, den aktuellen Status der Aufgaben zu einem beliebigen Zeitpunkt zu erhalten, haben wir beschlossen, durch Abstimmungsanfragen und Tagespläne zu umgehen.


    Personal aufladen, Teamintegration


    Fast von Anfang an war klar, dass es einen katastrophalen Mangel an Menschen gab (ich selbst habe den Code in Vollzeit geschrieben, aber wir hatten immer noch keine Zeit).


    Wir entschieden uns, zuerst an die Spitze zu gehen, da die beiden Progers im Unternehmen beide waren (und ich identifizierte mich auch mehr mit dem Backend), und es gab genügend Aufgaben, insbesondere im Layout, und am Horizont zeichneten sich auch die Aufgaben von Vue und Reactor ab.


    Es war ein großes Glück, dass ich eine befreundete Front hatte (und habe), die gleichzeitig darüber nachdachte, Freelancer zu verlassen. So konnten wir die Vakanz schnell schließen, und ich gewann eine Auszeichnung für die Anstellung eines Angestellten (ein weiterer Pluspunkt bei den Behörden). sah hr-awards).


    Fast unmittelbar nach der Front gab es 2 Beks. Und irgendwann zur selben Zeit war June weg (dessen Code mich noch ein paar Monate nach seiner Abreise gefahren hat).


    Insgesamt in der Entwicklung der folgenden Situation:


    • ein "alter Mann"
    • ich
    • drei absolute Anfänger
    • Arbeit ist noch nicht etabliert
    • einiges Wissen ist bereits verloren gegangen

    Es ist natürlich, dass Dutzende von Fragen von Neuankömmlingen sofort als Tam-Leopard auf mich fielen. Hierbei handelte es sich hauptsächlich um Fragen zum Lebenszyklus des Codes (wo Code geschrieben wird, wie er später gesendet wird, wie das Release abgerufen wird), wie Aufgaben verwaltet werden (wie Aufgaben ausgeführt werden, wie Status angezeigt wird, wie Prioritäten festgelegt werden) und wie mit git gearbeitet wird . Außerdem versuchten die Jungs immer noch, Fragen zu stellen: „Wie funktioniert A?“, „Haben wir B auf unserer Website?“. Aber zu diesem Zeitpunkt war fast alles darauf beschränkt, den Code zu studieren.


    Zunächst war es wichtig, den Programmierern grundsätzlich die Möglichkeit zu geben, selbstständig Code zu schreiben und zu schreiben. Ich führte mit ihnen einführende Gespräche, beantwortete ihre Fragen und entschied mich dann natürlich, alle Fragen und Pläne in einen Artikel zu bringen, der dann zu einer Vorlesung wurde und dann im Allgemeinen zu einem völlig neuen Arbeitsplan im Unternehmen, den ich im nächsten Kapitel besprechen werde.


    Hier ist es wert, ein paar Worte zum Einstellungsprozess in unserem Unternehmen zu sagen, der noch läuft.


    Rekrutierungsprozess


    Erstens haben wir einen Bonus für die Einstellung eines Mitarbeiters, was ziemlich gute Praxis ist.


    Zweitens haben wir beschlossen, beim Interview keine Prüfung zu arrangieren, sondern eine sehr umfangreiche Aufgabe zu erledigen, die unseren alltäglichen Aufgaben nahe kommt. Dies ist insofern günstig, als die Zeit für das Einstellen nur reduziert wird, bevor nach geeigneten Lebensläufen und einfachen Interviews mit Bewerbern gesucht wird, um die Angemessenheit zu prüfen und über die Testaufgabe zu sprechen und natürlich die Aufgabe direkt zu überprüfen.


    Das Problem kann bis Juni an einigen Abenden gelöst werden, während das Volumen durch die Freiheit zur Implementierung, Verbesserung und Nachfrage nach Chips erhöht wird. Diese Flexibilität bei der Implementierung hilft uns dabei, das Niveau des Bewerbers zu beurteilen. Wir sagen sofort, dass es für uns am wichtigsten ist, die Fristen zur Lösung des Problems einzuhalten (ruft den Sänger selbst an) und zeigen am Ende den Arbeitscode im Repository an. Wir legen keine Verwendung von Ansätzen und Technologien fest, der Performer wählt sie aus, aber um zum Meeting zu gehen und Hinweise zu geben, haben wir mögliche Verbesserungen in der Liste aufgeführt, z. B. Aufgaben mit einem Sternchen, zum Beispiel die Arbeit mit Ajax, ext. Validierung auf der Rückseite, Spam-Schutz, Design in Form eines Moduls, Verwendung von D7, ...


    Gesamt:


    • In Lebensläufen und Interviews können wir den Charakter einer Person beurteilen
    • Entsprechend der Frist für die Ausführung der Aufgabe, der Tatsache, dass der Code funktioniert und der Verwendung der Gita, treffen wir unsere eigene Entscheidung über die Einstellung
    • Für die Qualität der Leistung bestimmen wir die Höhe 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 Code-Entwicklungs- und Bereitstellungssystems


    Zu dieser Zeit hatten wir mehrere Projekte, die ziemlich chaotisch entwickelt wurden:


    • irgendwo in der Schlacht befand sich ein Meister, irgendwo in einem anderen Zweig
    • Irgendwo gab es Teststandorte, irgendwo nicht
    • und wenn es welche gäbe, dann sind die Adressen von allen verschieden
    • git wurde prinzipiell schlecht und schwer eingesetzt
    • Datenbankänderungen wurden manuell vorgenommen
    • ...

    Zuerst habe ich versucht, die Situation in kleinen Portionen zu korrigieren, so dass Programmierer weniger umschulen mussten und entsprechend verwirrt wurden. Zum Beispiel habe ich den Bitrix-Ordner unter dem Git herausgenommen und den Hauptzweig wieder in Master umbenannt.


    Als jedoch eine große Auffüllung zu uns kam, wurde die Situation kritisch. Wir mussten viel erklären, erinnern und unlogische Anweisungen schreiben, da die derzeitige Struktur der Entwicklung überhaupt nicht intuitiv war.


    Ich bin kein Fan von Anweisungen als solcher, ich glaube, dass ihre Anwesenheit an sich ein Indikator für ein Problem 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 löst.


    Das System ist wie folgt:


    • Jeder Entwickler hat eine Remote-Arbeitsplattform, auf der er arbeitet
    • Es gibt eine Plattform, auf der die Funktionalität für die nächste Version gesammelt wird.
    • Bei Bedarf gibt es eine Demonstrationsplattform zur Demonstration aller Ansätze des Funktionsbereichs
    • 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 in den allgemeinen Bereich hochzuladen, müssen Sie nur die Verzweigung irgendwo verzweigen und beginnen
    • Änderungen in Datenbanken werden als Migrationsdateien im Aufgabenzweig gespeichert.

    Ich hielt einen großen Vortrag über dieses System und wir begannen einen Pilot-Übergang zu einem Projekt, bei dem der neu erworbene Seigneur gerade geworfen wurde.


    Die Übertragung aller Projekte auf dieses System verzögerte sich natürlich (z. B. konnten wir bei einem Projekt beim ersten Mal auf mysteriöse Weise nicht zum Master wechseln), und es geht immer noch weiter, aber am Ende bekamen wir mindestens:


    • die Möglichkeit, nur die erforderlichen Aufgaben freizugeben und nicht die nicht abgeschlossene Funktionalität mit dem nützlichen Code freizugeben
    • Geben Sie die Aufgabe ohne den Autor des Codes frei
    • parallel die Arbeit an dem Projekt zwischen den Darstellern
    • Code nicht verlieren
    • Testen Sie die Funktionalität getrennt vom anderen und stoppen Sie nicht während des Prog

    Das alles vorher war einfach nicht. Außerdem ist es nicht notwendig, neuen Progern die zusätzlichen Feinheiten der Arbeit mit Git oder Testseiten zu erklären, da alles universell und intuitiv ist.


    Scrum, Kommunikation, Vorschriften


    In dem Artikel wollte ich natürlich darüber sprechen, wie ich als Teamleiter zur Entwicklung des Unternehmens beigetragen habe, aber wir können nicht über die Entwicklung unseres Unternehmens sprechen, ohne unseren Chef und seine Initiative zu erwähnen. Andernfalls wird es nicht ganz fair sein.


    Erstens implementierte er Scrum und zum Zeitpunkt meiner Ankunft begannen die Prozesse im Unternehmen sehr aktiv zu werden. In diesem Moment verlegte sie sie auch von Bitrix24 nach Djira.


    Natürlich brachte Scrum dem Unternehmen mehr Rhythmus und reduzierte das Chaos. Während der Umschulung von Managern, der Durchführung von Koordinierungsanrufen, dem Öffnen / Schließen / Planen von Sprints beobachtete der Leiter selbst als Senior in diesem Zusammenhang.


    Er hat auch viel an den Managern selbst gearbeitet, insbesondere bei der Kommunikation mit Kunden und Programmierern, da ein großer Teil ihrer Arbeit (aber natürlich nicht darauf beschränkt ist) zu kommunizieren: Programmierer von Kunden zu trennen, die Wünsche der Kunden zu verbreiten Aufgaben in Backlog und Sprints finden Sie User Storys. All dies führte zu vielen Regelungen: zur Kommunikation mit den Kunden, zur Festlegung von Zielen, zur Arbeit mit Rückständen und zur Annahme von Fehlern. Die Kommunikation stand im Vordergrund, und der Verwaltungsrat zeigte wirklich Fortschritte.


    Der Übergang zu Scrum selbst ist natürlich sehr schwierig und zum Zeitpunkt der Abfassung dieses Artikels sind wir noch nicht zu seinen Profis geworden, obwohl es sich hier um alles handelt. Ich bin sehr froh, dass ich viel neues Wissen über flexible Methoden und Produkte des Atlassian erhalten habe.


    Neuer Manager Texte, Einstellungsaufgaben, Rückstand


    Irgendwann kam eine andere Person, die uns helfen sollte, einen qualitativen Sprung zu machen - einen neuen Manager (davor hatten wir einen).


    Ich habe nicht mit diesem Moment gerechnet, da es nicht so viele Projekte und Programmierer gab und theoretisch nur ein Manager hätte. Diese Verbindung war ein Schwachpunkt im Unternehmen, aber wir haben versucht, dieses Problem durch die Entwicklung des vorhandenen Personals zu lösen. Es war nur zufällig so, dass ein ausgezeichneter Manager, den ich gut kenne, beschloss, den Job zu wechseln, mein Chef erfuhr davon, als sie plötzlich unsere Auftragnehmer interviewte, und ich sprach über diesen lustigen Vorfall und wir riefen sie zu uns an. Ein weiterer Bonus)


    Zu Beginn wiederholte die neue Managerin einen Teil meines Weges, da sie vor den gleichen Problemen stand (sie weiß nichts und kann nicht lesen) und begann alles auf eine neue Art und Weise, aber mit dem Unterschied, dass sie den Code, die Entwicklungsinfrastruktur und die Fähigkeiten der Programmierer nicht anrührte, sondern mit ihnen arbeitete Setzen Sie Aufgaben, kommunizieren Sie mit Kunden, bereinigen Sie den Rückstand, und ziehen Sie fleißig Informationen aus dem Kopf des alten Managers. Insbesondere wurde zunächst eine Liste mit Kontakten von Kunden und Auftragnehmern erstellt.


    Das Team war bereits damit vertraut, da wir sie einmal zu einem Dozenten eingeladen hatten, um uns etwas über die Zeitsteuerung zu erzählen. Außerdem werden die Aufgaben des Stahls detaillierter dargestellt, es wurde nicht negativ hinzugefügt und nicht vom Kunden übertragen, der Status der Aufgaben wurde zu einem bestimmten Zeitpunkt relevanter. Deshalb haben wir sofort große Hoffnungen gesetzt.


    In den ersten Wochen ordneten er und sein Chef bei einem Projekt den Rückstand auf, insbesondere fanden sie ein Epos, das um 2 Monate überfällig war und noch nicht begonnen hatte. Darüber hinaus haben sich im Prinzip viele Aufgaben ergeben, die vor einem Monat erledigt werden mussten. Der Rückstand wurde zwar bereinigt, aber zu spät erledigt.


    Sie selbst hat wirklich "aufgehängt" aus dem Schlamassel und hat nicht nur schnell gehen müssen, sondern der Management-Link, wir haben uns irgendwie sehr verbessert. Aufgaben gehen seltener im Rückstand verloren, Programmierer fragen seltener danach.


    Die Moral der Geschichte wird am Ende sein.


    Die Krise


    Fast sechs Monate nach Arbeitsbeginn musste ich in den Urlaub fahren. Übrigens stimmte ich den Feiertagen zu, auch wenn ich zur Arbeit kam, da dies als Hochzeitsreise geplant war, so dass die Zeit meiner Abwesenheit lange vorher bekannt war. Trotzdem war ich natürlich bis zuletzt nervös, weil wir erst vor kurzem aufgehört haben, auf Abnutzung zu arbeiten.


    Eine Woche vor den Feiertagen habe ich die Delegation der Verantwortlichkeiten abgeschlossen, ausgewählten Leuten beigebracht, bestimmte Aufgaben außerhalb des Kodex auszuführen, jedem Programmierer die Verantwortung für ein bestimmtes Projekt zugewiesen, abgeschlossen oder alle meine aktuellen Aufgaben übertragen (ich habe den Großteil des Tages noch programmiert). Nichts deutete auf Probleme Mitte Juli hin.


    Und auch in den ersten Urlaubstagen war nichts ein Zeichen für den Ärger.


    Und dann gab es eine Krise.


    Bei einem Projekt war der Kunde nicht in Geduld, da seine Erwartungen an die Erledigung von Aufgaben (Fristen, Listen, Prioritäten) nicht der Ursache entsprachen. Wir selbst haben dies vor nicht allzu langer Zeit mit der vollständigen Verarbeitung des Rückstandes und der aktiven Kommunikation mit dem Kunden (dem Kapitel über den neuen Manager) bemerkt, aber es war zu spät.


    Und beim zweiten Projekt haben wir endlich eine sehr lange und lang erwartete Aufgabe angenommen, die Tests beendet und veröffentlicht. Aber die neue Funktionalität brachte die Kampfstelle plötzlich unter schwerer Last zum Einsturz, und die mittlere Front der Woche konnte nichts dagegen tun. Natürlich hat dieser Kunde auch angefangen, unlautere Sprache zu verwenden und über den Verzicht auf unsere Dienste nachzudenken.


    Das erste Problem hatte nicht direkt mit der Entwicklung zu tun, daher habe ich mich aktiv an der Korrektur der Situation des zweiten Projekts beteiligt. Ich konnte zwar nicht wesentlich helfen, da ich in einem anderen Land ohne Internet und Laptop war. Das Maximum meiner Hilfe bestand in der Beratung von Progern, vor allem als ich das Internet bereits gekauft hatte.


    Die für das Projekt verantwortliche Unterstützung wurde jeden Tag eine ganze Woche überarbeitet, um eine neue Funktion im Kampfumfeld zu schaffen, und sie befassten sich zusammen mit der Front mit der Code-Base vue, bei der die meisten von ihnen nicht geschrieben wurden (ich übrigens).


    Der Kollege geriet in eine schreckliche Situation - er arbeitete bis ein Uhr die ganze Woche, er war sehr gestresst, aber alle Beulen hingen an ihm, vor allem aufgrund der Tatsache, dass er immer wieder sagte: "Ich werde es zum Abendessen / Ende des Tages / Nächte / Morgen. "
    Die Situation konnte korrigiert werden, aber all dies führte dazu, dass er selbst, während wir über sein Schicksal entschieden hatten, einen Rücktrittsbrief schrieb, da er solchen Stress satt hatte.


    Das Merkwürdigste war, dass die Kommunikation mit den Jungs die ganze Zeit über richtig funktionierte und sogar recht schnell einen problematischen Ort fand, aber die Lösung dauerte Dutzende Stunden und viel später, um die Ausfälle der sekundären Funktionalität zu beheben.


    Wir haben viel darüber nachgedacht, warum sich diese Situation entwickelt hat und wie wir sie in Zukunft verhindern können. Offensichtlich hat sich gezeigt, dass es an Fachkenntnissen und Fertigkeiten bei der Beurteilung von Aufgaben fehlt. Daher haben wir uns für die Prävention entschieden, freiwillig einen freiwilligen Einsatz von Programmierern innerhalb des Unternehmens einzuführen. Die Notwendigkeit hierfür wurde auch durch die Beobachtung angedeutet, dass Progers mit Nebenprojekten keine ähnlichen Probleme hatten.


    Programmierer Entwicklung


    Von entscheidender Bedeutung war die Verbesserung der Fähigkeiten von Programmierern. Stagnation ist im Grunde ein kleiner Tod (und schon ein echter Präzedenzfall für die Entlassung), zudem haben sich Probleme bereits aufgrund fehlender Kenntnisse oder Fähigkeiten manifestiert:


    • technische Schulden angehäuft
    • Jungs beschwerten sich oft über Probleme mit dem Git
    • Das Beheben von unvorhergesehenen Fehlern hat viel Zeit gekostet
    • Neue Technologien wurden sehr hart eingeführt
    • Das Treffen mit dem Code einer anderen Person war ein echtes Hindernis

    Jemand entwickelte sich unabhängig, jemand hat es nicht getan, und jemand ging sogar falsch in diese Wildnis, obwohl es nützlich sein kann. Daher war es notwendig, Programmierer zentral vom Unternehmen zu entwickeln.


    Codream


    Ich habe versucht, den Code öfter zu überarbeiten, aber der Auspuff davon war nicht genug. Die Jungs lasen natürlich meine Kommentare, aber die Kommentare wurden immer wieder wiederholt.


    Vorträge


    Eine andere Idee war, Vorträge zu halten. Zum Beispiel habe ich einmal alle Beispiele von govnokod, die ich während eines Codierungstests gefunden hatte, in einer großen Datei mit Erläuterungen zu jedem Fall gesammelt und ihnen in einer Reihe davon erzählt. Ein solches direktes Training war natürlich sinnvoller.


    Übrigens habe ich den Jungs im Vorlesungsformat beigebracht, wie man mit vue arbeitet, was wir später viel benutzten.


    Insgesamt haben wir nicht viele Vorlesungen verbracht, irgendwo um die 5. Zunächst hat keiner der anderen Programmierer seine Vorlesung vorbereitet. Und es hat die Probleme mit govnokod und das Überschreiten der Bewertungen nicht gelöst, aber sie waren die wichtigsten.


    Gemeinsame Sitzungen


    Ich war besonders verärgert über das Problem mit git, ich hatte noch nie zuvor so viele davon gesehen: Merdzhe führte zu Code-Verlust, manchmal löste die Konfliktlösung die Seite auf, Dateien in Commits wurden manchmal als komplett neu geschrieben, und im Prinzip waren Commits und Mitteilungen an sie völlig uninformativ .


    Ich dachte, es liegt daran, dass die Jungs mit Git über die Konsole oder etwas anderes auf ihre Art arbeiten. Dies führte zu der Idee, nicht nur Vorlesungen aufzurufen und zu geben, sondern auch Code aufzurufen und zu schreiben, zu zeigen, wie man in Storm arbeitet, Commits zu machen, Konflikte über eine praktische Benutzeroberfläche zu lösen, Code zwischen den Fällen umzuwandeln und jeden Programmierer zu diskutieren.


    Und dieses Format wird gedreht.


    Wir versuchen jeden Freitag zusammen zu kommen. Wir zeigen uns alle Arten von Chips in Storm, wo das gesamte Team sich dank des Telefonierens endlich bewegte, Fragen zur Gita löste und die Qualität der Entwicklung verbesserte.


    Darüber hinaus glaube ich, dass solche wöchentlichen Programmierer den Geist der Programmierer ansprechen, da wir nicht nur verstehen, warum der falsche Preis von 1c kam, oder einen anderen Abschnitt mit Anteilen zur Website hinzufügen, sondern dass wir uns irgendwie entwickeln und ohne Manager und Kunden in der Nähe kommunizieren. Er teilt ein bisschen Erfahrung und interessiert sich für ihn, wir analysieren die technischen Probleme, die entstanden sind, wir ziehen die Nachzügler nach oben. Und nicht nur ich führe sie, im Gegenteil, oft gebe ich die Initiative und die Jungs selbst senden nützliche Dinge.


    Teameffektivität, Aufgabenbewertung


    Eines der größten Probleme im Unternehmen war die ständige Aktualität der Aufgaben. Manchmal wurde der durchschnittliche Überschuss pro Stunde zweimal erreicht.


    Das Problem trat besonders während meines Urlaubs auf, als die Aufgabe von Anfang an um eine ganze Woche um einige Stunden vorverlegt wurde, das heißt, alle 3-4 Stunden hieß es "Sie brauchen weitere 3 Stunden", und es dauerte dann fast 40.


    Dank der Führung waren wir wiederum nicht negativ und haben niemanden entlassen, aber die Aufgaben zu streichen, hat uns zumindest die Boni weggenommen und könnte maximal zu Verlusten führen.


    Wir nannten die Tatsache / Bewertung der Arbeitsleistung in Stunden - die Effizienz (gut, wie sie es nannten). Die Effizienz des gesamten Teams wurde zu meinem KPI als Hauptaufgabe des Teamleiters. Ich war froh, dass ich einen numerischen KPI hatte. Meine Freude verstärkte sich dadurch, dass ich gleichzeitig täglich 8 Stunden mit dem Programmieren aufhörte und mich nun voll auf Timlide-Angelegenheiten einlassen konnte.


    Wir haben so viel über das Problem der Effizienz nachgedacht. Es gab keine offensichtlichen Lecks:


    • Programmierer bewerteten die Aufgaben als ziemlich gesund
    • wirklich an ihnen gearbeitet, und nicht nur den Timer eingestellt
    • Es gab keine Probleme mit der Kommunikation

    Aber dann ging immer etwas schief und jedes Mal war anders:


    • Es gab eine Falle
    • Die endgültige Entscheidung entsprach nicht dem Kunden
    • Einige verwandte Funktionen fielen ab
    • Beim Testen wurde etwas bestanden und anschließend überarbeitet
    • verlorene Zeit bei der Suche nach einigen Zugriffen
    • ...

    Ich entschied (nicht ohne ein Interview mit jedem Programmierer separat), dass die Probleme in folgenden Punkten begründet sind:


    • Qualitätsbewertungsaufgaben, die die Jungs oft noch falsch berechneten
    • in der Programmierer-Ebene selbst, durch die „Schwarze Löcher“ Aufgaben gebildet werden und die Korrektur von Fehlern durch die Uhr verzögert wird. Es kann auch zu Betäubung beim Treffen mit unbekannten Technologien führen.
    • Govnokode, Code-Konnektivität. Obwohl sich dieses Problem indirekt mit dem vorherigen überschneidet
    • Bei der Formulierung von Aufgaben, da ich oft Beschwerden über die Unvollständigkeit der Informationen in der Beschreibung hörte, konnte dieser Moment zu unnötigen Änderungen führen

    Dann entschied ich mich für eine Studie - ich überprüfte alle Zeitprotokolle in allen Aufgaben mit einer Überschreitung der aktuellen Bewertung. Und es brachte einige neue Entdeckungen:


    • ursprünglich um genau 1 Uhr bewertete Aufgaben wurden fast immer übertroffen
    • Das Testen der Aufgabe wurde fast nie in das Assessment einbezogen, und oft wurde es übertroffen
    • unerwartet und unangenehm, aber Probleme mit Git wurden oft in den Protokollen der Zeit erwähnt. Und große Protokolle, manchmal für anderthalb Stunden

    Auf der Grundlage all dieses Wissens haben wir Gegenmaßnahmen getroffen:


    • Ich persönlich überprüfe jeden Tag alle Bewertungen und die Formulierung aller neuen Aufgaben, natürlich schenke ich kleinen Aufgaben besondere Aufmerksamkeit. Wir kämpfen also mit der Unzulänglichkeit der Bewertung und der Unvollständigkeit der Aussage
    • Übersetzen Sie alle Jungs im Sturm, damit sie zumindest nicht mehr mit den Zusammenführungen in der Konsole herumspielen
    • Bei allen Aufgaben geben wir Zeit für Test, Kommunikation und Lieferung an den Kunden
    • Wir führen wöchentliche Anrufe mit einem engen Programmierkreis durch, in dem wir gemeinsam programmieren, Wissen teilen, Tricks teilen, lernen, Konflikte zu lösen und Code dazwischen umzuwandeln

    Dies alles begann ziemlich schnell Früchte zu tragen, insbesondere Programmiererrufe. Zum Beispiel waren nach dem zweiten Telefonat die Probleme mit git verschwunden.
    Die Effizienz begann sich zu verbessern, wenn auch nicht sehr schnell. Im Moment sind wir noch sehr bemüht und hören nicht auf, dieses Thema zu studieren.


    Was ich in dem neuen Beitrag gelernt habe


    Frames - das Wichtigste


    Sie können alle Produkte von Atlassian und Jetbroins kaufen, kluge Dinge erzählen, eine Reihe von Vorschriften einführen, mit den Kunden die Aufgabensysteme vereinbaren. Wenn Ihre Kollegen jedoch die Vorschriften sabotieren, „aus Gewohnheit“ arbeiten und keine neuen Werkzeuge einsetzen, dann haben Innovationen keinen Sinn.


    Außerdem unterscheidet sich eine proaktive Person immer nur von einem guten Arbeiter, auch wenn sie sich aus ihrem „legitimen“ Verantwortungsbereich herausbewegt und das Stehenbleiben der Aufgabe verhindert oder eine allgemeine Verbesserung bietet, ohne von oben zu fragen.


    Persönliche Qualitäten sind wichtiger als berufliche.


    Zum Beispiel können Sie einen coolen Spezialisten haben, der immer die Fristen einhält, jedes Problem lösen kann, den idealen Code schreibt, aber er erscheint in Verbindung mit Gott, verbietet 2 Stunden pro Tag oder nimmt plötzlich mitten in der Woche einen Tag frei. Dies bringt unvergleichlich mehr Probleme als Gutes, besonders wenn Fehler in seinen Aufgaben entdeckt werden.


    Oder Sie können sich eine Situation vorstellen, in der es zwei identische Angestellte gibt, von denen einer Fachliteratur liest und / oder persönliche Projekte leitet und der zweite nicht. Anfangs sind sie in Bezug auf Gehalt und Fähigkeiten gleich, aber nach einer Weile beginnt der zweite, das Unternehmen herunterzuziehen und zu packen, und der erste erledigt weiterhin seine Aufgaben oder überholt erfahrene Kollegen.


    Die Momente, in denen Menschen sich weigern, Verantwortung zu übernehmen, sind auch sehr schädlich. Dies führt dazu, dass Anweisungen sabotiert werden oder das Anhalten der Aufgaben gestoppt wird, wenn keine Verbindung zum ursprünglichen Bearbeiter besteht und / oder wenn Sie etwas Gefährliches tun müssen, um beispielsweise einen Konflikt zu lösen oder Aktionen auf der Kampfwebsite auszuführen.


    Emotionen von Kollegen beeinflussen viel (mehr als ich bisher gedacht habe)


    Viele mögen ihren Job nicht wegen Stress. Stress kann zum Beispiel durch die Höhe des Gehalts, die Giftigkeit der Kollegen, die Dummheit der Kunden, die teure Arbeit, die Arbeit, eine Million andere Gründe verursacht werden.


    Neuer Arbeitsstress kann Kunden, unvorhergesehene Umstände, Kollegen bringen. Aber von der ersten kann man abstrahieren, die zweite kann lösen, aber Sie werden jeden Tag ewig jammern und depressive Kollegen sehen.


    Im Allgemeinen, damit wir es nicht tun: Code schreiben, entwerfen, mit Buchhaltung arbeiten, wir arbeiten trotzdem mit Menschen zusammen, und sie sind es, die unsere Stimmung am meisten beeinflussen. Möglicherweise entscheidet die Kommunikation mit dem Team, ob sich eine Person im Unternehmen verspätet oder nicht.


    Sitzen Sie nicht auf zwei Stühlen


    Das erste Mal, als ich den ganzen Tag den Code schreiben musste, weil ich dachte, ich hätte keine Zeit für meine reinen Timlide-Pflichten, half ich dem Team als Ganzes mehr oder weniger, die Fristen einzuhalten. Aber so wird ein viereckiges Rad gerollt, als Sie gefragt wurden, es zu schleifen.


    Populärere schädliche Beispiele für Mischpflichten:


    • Programmierer kommunizieren lange mit Kunden und passen danach nicht in die Fristen
    • Die Manager sind mit der Verteilung aller Aufgaben unter den ausübenden Künstlern beschäftigt, was die ganze Zeit frisst
    • Inhaltsmanager versuchen, den Code zu bearbeiten und die Website zu brechen
    • Der Manager versucht, dem Programmierer eine Beschwerde mit dem Code an einen anderen Programmierer zu übermitteln
    • Ich versuche, eine gute Lösung zu finden

    Natürlich gibt es keine Postulate über die Bedeutung der Selbstentwicklung oder beispielsweise der Gesundheit am Arbeitsplatz, sondern nur, weil dies keine neue Erfahrung ist, die ich entdeckt habe.


    Pläne


    Als ich gerade anfing, über einen Jobwechsel nachzudenken, wollte ich nach Zypern gehen, weil ich von ihm die Sonne erwartete (Stereotype über Peter sind keine Klischees), Ruhe, gutes Gehalt, interessante Herausforderungen und Stress.


    Aber Moskau bot mir Bedingungen an, die ich nicht ablehnen konnte (Karrierewachstum, zwei Mal das aktuelle, eine Plattform für Experimente und nahezu vollständige Handlungsfreiheit).


    Andererseits, wenn Sie darüber nachdenken, sind wir auch Europa. Deshalb möchte ich "Zypern hierher bringen", dh zu befehlen:


    • weniger gestresst bei der arbeit
    • blieb wildmüde stehen
    • das Negative von Kollegen und Kunden loszuwerden
    • Ich hatte die Gelegenheit, stolz auf meine Arbeit zu sein, das heißt, auf die Korrektur von Fehlern und das Falschen von Fakaket zu verzichten, und sah etwas Cooles
    • Bitrix hat immer neue Technologien eingesetzt.
    • Nun, natürlich erhöhte Gewinne

    Nun, das ist alles, was wir von der schönen Ferne erwarten.


    Teil 2


    Dieser Artikel behandelte etwa sechs Monate meiner Arbeit in einer neuen Position. Im zweiten Teil möchte ich mit Hilfe von:


    • Autotesting, den wir gerade erst implementieren. Merkwürdig, aber aus irgendeinem Grund gibt es auf Beatrix keine anständigen Beispiele
    • Legacy-Code loswerden
    • die Entwicklung weiter beschleunigen und vereinfachen
    • die Tatsache, dass ich aus den Kommentaren ziehe
    • viele andere geheime Dinge bis jetzt (plötzlich lesen mich meine Jungs)

    Vielen Dank fürs Lesen. Ich würde mich sehr über einen Kommentar freuen, vor allem, wenn Sie optimale Lösungen für die Lösung der Probleme kennen.


    Viel Glück und Freude an Arbeit und Leben!


    Jetzt auch beliebt: