Das Treffen fand im Rahmen der Reihe „Engineer Walks in a Bar“ statt, in der Ingenieure verschiedener IT-Unternehmen über professionelle nicht-technische Themen sprechen. Eine Reihe von Veranstaltungen wurde von Ingenieuren der Firma Miro mit Unterstützung des DolRushev- und Storozhilov DevRel-Büros organisiert .
Das zweite Treffen der Serie findet am 20. August statt. Das Thema ist Toxizität in Teams, Unternehmen und der Industrie. Referenten - Ingenieure und technische Leiter von Miro, SEMrush, Parma TG, Xsolla. Die Registrierung ist bereits offen .
Inhaltsverzeichnis:
- Die Besonderheiten des Unternehmens und das derzeitige System der beruflichen Entwicklung von Ingenieuren
- Herausforderungen in aktuellen Entwicklungssystemen
- Wie man eine Entwicklungskultur zu Beginn eines neuen Teams implementiert
- Heiße Frage zum Geld
- Wie argumentieren Sie für ein Unternehmen, dass Mitarbeiter einen Prozentsatz ihrer Zeit für Bildung und Entwicklung benötigen?
- Umfrage zu Tools für die berufliche Entwicklung
Die Besonderheiten des Unternehmens und das derzeitige System der beruflichen Entwicklung von Ingenieuren
Artyom Susekov, Leiter Product Software Engineering, Miro. Wir erstellen ein Produkt für die Online-Zusammenarbeit von Teams, eine Online-Whiteboard-Plattform für die Zusammenarbeit. Das Unternehmen beschäftigt 400 Mitarbeiter, etwas weniger als die Hälfte sind Ingenieure. Produktentwicklungsbüros in Perm und Amsterdam. Die Teams sind funktionsübergreifend: Ingenieure, Produktmanager, Designer und gegebenenfalls Vermarkter. Sie verwenden Scrum, einige verwenden Kanban. Für die Planung - OKRs auf Kampagnenebene und auf der Ebene der einzelnen Teams.
Wir haben Noten, Erwartungen von jedem werden in Form spezifischer Verhaltensbeispiele (Verhaltensmuster) formuliert. Dies geschieht, um nicht nur auf formale Erwartungen einzugehen ("um so viele Aufgaben zu erledigen, so und so ein Zertifikat zu erhalten"). Es ist wichtiger, dass das gewonnene Wissen in der täglichen Arbeit angewendet wird. Genau dies wird in den spezifischen Beispielen gezeigt, die für jede der Klassen beschrieben werden.
Standardnoten: Junior, Middle, Senior, jede Klasse besteht aus mehreren Schritten. Nach Senior gibt es die Möglichkeit, sich zu einem technischen Spezialisten zu entwickeln oder Teamleiter und dann Richtungsmanager zu werden.
Es gibt eine Leistungsbeurteilung, die wir zweimal im Jahr durchführen. Währenddessen erhalten Sie Feedback von Ihren Teamkollegen, Teamleiter erhalten Feedback von denen, die direkte Berichte für sie sind. Darüber hinaus schreibt der Mitarbeiter eine Selbstbewertung, dh er bewertet seine Arbeit unabhängig.
Die Ergebnisse werden zusammengefasst, wonach ein Karrieregespräch geführt wird: Was ist gut gelaufen, was ist großartig geworden, was sollte in Zukunft betont werden, woran sollte gearbeitet werden. Anschließend hilft der Manager bei der Erstellung eines Entwicklungsplans für die nächsten sechs Monate oder ein Quartal.
Career onversation ( , , ), : , , .Alexander Borisov, Leiter des Innopolis Technology Competence Center der X5 Retail Group. Wahrscheinlich ist fast jeder mit X5 vertraut. Wir besitzen die Ketten Perekrestok, Pyaterochka und Karusel. Wenn wir vor drei Jahren ein Unternehmen waren, das Tomaten verkauft, und jetzt streben wir danach, ein IT-Unternehmen zu werden, das Tomaten verkauft.
Der größte Teil des Gewinns stammt aus unseren IT-Dienstleistungen. Wie Pyaterochka funktioniert und welche Preise es bietet, möglicherweise aufgrund einer gut organisierten Logistik und eines Managementsystems für diesen großen Prozess. Wir haben mehr als zweitausend IT-Spezialisten im Unternehmen, allein in Innopolis sind fast 150 Mitarbeiter beschäftigt.
Im vergangenen Jahr hat sich all dies von einem Abteilungsformat zu einem Produktteamformat gewandelt. Wir haben Services und Produkte in Microservices und Unterprodukte unterteilt, für die ein Team verantwortlich sein kann. Wir haben jetzt Product Owners für jedes Produkt, funktionsübergreifende Teams, von denen jedes Entwickler, Tester, Analysten und einen Teil der Funktionen hat, in denen sich Menschen überlappen können.
Natürlich haben wir Einzelgespräche, OKRs und 360-Grad-Feedback. Interessant ist die Funktion des Ressourcenpoolbesitzers. Dies sind die Personen, die für den Java-, JS-, Python-, Test-, Analyse- usw. Pool verantwortlich sind. Jeder Ingenieur im Unternehmen hat einen Unternehmensleiter (Product Owner), der versteht, wie viel eine Person in ein Produkt investiert und wie viel Gewinn seine Arbeit bringt, und es gibt eine Person, die in ihrer spezifischen Kompetenz für die technische Entwicklung verantwortlich ist.
Wir haben die Formalisierung des Übergangs zwischen den Klassenstufen wie „Um von Junior Plus zu Middle Minus zu wechseln, müssen Sie dies und das tun“ aufgegeben. Wir befürchten, dass die Menschen zu formal vorgehen, wenn wir klare Kriterien für den Übergang festlegen. Aber die Formalität ist hier schädlich, weil in jedem Team alles sehr individuell sein kann: Ein und dieselbe Person kann mehr Verantwortung übernehmen und sich dadurch entwickeln oder ein enges Segment von Technologien einpumpen, die für uns spezifisch sind und aufgrund dessen werden wertvoller für das Geschäft.
Für leitende Positionen ist die Verbreitung von Wissen eine wichtige Voraussetzung für Wachstum. Sie sind kein Senior in einem Vakuum, Sie teilen Ihre Erfahrungen mit dem Team und ziehen andere mit.
Sergey Averyanov, CTO, Funbox. Wir entwickeln seit über 10 Jahren Software für die drei großen Betreiber. Derzeit haben wir ungefähr zweihundert Entwickler verschiedener Profile und eine ziemlich große Anzahl technischer Spezialisten für technischen Support.
Einerseits haben wir kein einziges Produkt, an dem das gesamte Team beteiligt ist, und andererseits gibt es keinen großen Fluss von Projekten und Aufgaben wie beim Outsourcing. Hier wächst unsere spezifische berufliche Entwicklung von Ingenieuren. Wir haben bewusst auf formale Bewertungssysteme verzichtet: Vielleicht möchten das Management und die Mitarbeiter selbst dies, aber dies ist ein äußerst unflexibles System, das versucht, alle mit demselben Pinsel zu stylen, was in der Praxis nicht immer möglich ist. Stattdessen verwenden wir ziemlich übliche Dinge: regelmäßige Bewertung des Fortschritts des Mitarbeiters und Einzelgespräche. Wir haben die Möglichkeit, den Beitrag jedes einzelnen von Task Tracker objektiv zu bewerten. All dies zusammen gibt uns ein Verständnis für das Niveau jedes Ingenieurs.
Andererseits ist es eines unserer Hauptziele, jedem Menschen verständlich zu machen, wie und wo er sich entwickeln kann. Wir versuchen zu berücksichtigen, dass alle Menschen unterschiedlich sind: Jemand ist daran interessiert, als technische Experten zu arbeiten, nur minimal mit Menschen zu kommunizieren und nicht in administrative Dinge einzutauchen; jemand möchte kommunizieren, mit Menschen arbeiten, an der Entwicklung von Kollegen teilnehmen. All dies ist normal, alle Entwicklungsoptionen sind möglich.
Wir versuchen, ein System aufzubauen, mit dem wir das Niveau der Ingenieure erhöhen und ihnen klare Anweisungen geben können, was das Unternehmen von ihnen will und wohin sie als nächstes gehen können. Wir achten auch sehr auf das interne Wachstum. Ich und das gesamte Team glauben, dass der beste Spezialist der Spezialist ist, den wir im Team erzogen haben. Deshalb investieren wir aktiv in die interne Entwicklung, in Meetups, interne und externe Konferenzen. Dies ist auch eines der Hauptziele - die vollständige und qualitativ hochwertige Entwicklung aller unserer Ingenieure.
Eine abstrakte Entwicklungsabteilung sollte nicht in die Mitarbeiterentwicklung einbezogen werden. Dies ist eine der Aufgaben des Vorgesetzten.
Dieser Ansatz gibt uns und den Mitarbeitern selbst ein Plus. Einerseits haben wir ein konstantes organisches Wachstum unter den Mitarbeitern. Auf der anderen Seite können wir aus ehemaligen Junioren Senior-Junioren und Teamleiter machen, und der Mitarbeiter selbst sieht, dass sein direkter Vorgesetzter derjenige ist, der vor vier Jahren Junior bei diesem Projekt war, was bedeutet, dass vor der Zusammenarbeit jetzt die gleichen Chancen und verständlichen Schritte für Wachstum.
Mikhail Mazein, technischer Leiter, ManyChat.Wir entwickeln eine SaaS-Marketingplattform, mit der Sie die Kommunikation zwischen Unternehmen und ihren Kunden arrangieren können. Das Unternehmen wächst aktiv: Vor drei Jahren waren 15 Mitarbeiter im Team, heute sind es mehr als 120. In den ersten Phasen haben wir mit klassischen Funktionsteams zusammengearbeitet: Backend, Frontend, Test, Designteams. Jedes Team hatte einen Teamleiter, der für die Sprintplanung und die Aufgabenzerlegung verantwortlich war.
Im Zuge des Wachstums stellten wir fest, dass dies uns daran hinderte, uns mit der gewünschten Geschwindigkeit zu bewegen, und formatierten die Arbeit in funktionsübergreifende Teams um. Jetzt haben wir neun solcher funktionsübergreifenden Teams, es gibt keine Teamleiter, da sich herausstellte, dass die Teams selbst organisiert sind und für ihre Arbeitsweise verantwortlich sein können.
Um funktionale Dinge zu synchronisieren, entwickeln wir gemeinsame Ansätze, damit aus Entwicklung keine Anarchie wird. Dies ist beispielsweise erforderlich, wenn Backend-Entwickler auf verschiedene Teams verteilt sind, jedoch mit einem Projekt und einer Codebasis arbeiten und dort Code festschreiben. Wir organisieren funktionale Gemeinschaften, um diese Probleme anzugehen. Im Laufe der Zeit treten informelle Führungskräfte in Gemeinschaften auf, die Prozesse und Kommunikation vorantreiben. Das Ergebnis ist eine flache Struktur, die die Rolle des Entwicklers nicht auf die Rolle eines Ingenieurs beschränkt, der nur Code schreibt, sondern es Ihnen ermöglicht, verschiedene Dinge zu tun, die für das Unternehmen nützlich und gleichzeitig für die Person selbst interessant sind.
Da wir die Rolle des Teamleiters aufgegeben haben, brauchten wir einen Prozess, mit dem wir klar und transparent Wachstumspfade für Ingenieure erstellen können. Dazu verwenden wir ein Mentorensystem: Jeder Mitarbeiter hat einen Mentor, der für sein Wachstum und seine Entwicklung im Unternehmen verantwortlich ist.
Sie können nicht einfach auf eine zufällige Person zugehen und sagen: "Lassen Sie Sie ein Mentor sein." Zunächst müssen mehrere Faktoren erfasst werden: das Verlangen der Person selbst; hohes Vertrauen in das Team gegenüber der Person; Vertrauen vom Unternehmen selbst und vom Management. Eine der Aufgaben eines Mentors ist es, neue Mentoren zu gewinnen. Es stellt sich heraus, dass es von Mentor zu Mentor so aufkeimt.
Wir unterscheiden drei Hauptvektoren der Entwicklung:
- Der erste große Weg ist eine tiefere Arbeit im Produktteam für die Produktentwicklung mit einem tieferen Verständnis der Geschäftswerte und Metriken.
- – , , .
- – , .
Wir haben auch versucht, ein Bewertungssystem zu erstellen: Wir können noch nicht alle Noten formal beschreiben, daher wird das System auf der Ebene des Beitrags einer Person, der Ebene des Teams und der Ebene des gesamten Unternehmens aufgebaut. Wir haben die Erwartungen auf jeder Ebene, den Verantwortungsbereich oder den Einflussbereich, den wir von einer Person erwarten, anhand klarer Beispiele beschrieben. Der Mentor hingegen kann einer Person sagen, welche Fähigkeiten gepumpt werden müssen, um zum gewünschten Punkt zu gelangen.
Anton Grishin, Entwicklungsleiter, MadRobots. Auf den ersten Blick ist unser Unternehmen ein E-Commerce, der sich mit Gadgets befasst, aber im Allgemeinen beschäftigen wir uns mit dem Vertrieb in Russland und der Entwicklung von Marken für coole Dinge.
Unser Team hat sich vor relativ kurzer Zeit versammelt, sodass wir noch keine Kopfschmerzen haben, die mit der Entwicklung von Ingenieuren innerhalb des Unternehmens verbunden sind. Vor Madrobots war ich 6 Jahre im Outsourcing tätig, von denen drei direkt für die Produktion in der Agentur verantwortlich waren, und ich möchte Ihnen mehr über diese Erfahrung erzählen.
Beim Outsourcing war unser Schmerz ein großer Fluss von Projekten und Fluktuation, beim Outsourcing ist dies immer der Fall. Wir beschlossen, dies irgendwie zu überwinden, und begannen, in die Entwicklung der Mitarbeiter zu investieren.
Ja, wir hatten ein Bewertungssystem. Einmal alle sechs Monate erhielt eine Person Feedback von einem technischen Manager, der für die nächsten sechs Monate seinen eigenen Weg mit ihm baute.
, . , . , , , .
Anschließend hatten wir einen weiteren Schmerz. In dem Strom von Projekten, von denen es oft einige gab, verloren die Menschen den Fokus auf die persönliche Entwicklung. Dies geschah nicht, weil sie nicht genug Zeit hatten, sondern weil sie die Anzahl der Aufgaben satt hatten, auf die sie springen mussten. Wir haben die Praxis von Einzelgesprächen einmal im Monat eingeführt, die darauf abzielen, mit einer Person zu sprechen und sie daran zu erinnern, dass Sie einen Entwicklungsplan haben und dieser wirklich eingehalten werden sollte. Wenn Sie dafür etwas Zeit benötigen und von der Routine oder der ständigen Abwesenheit außerhalb des Standorts befreit sein sollten, lassen Sie uns darüber sprechen, da sich Ihr Kontrollpunkt nähert und Sie etwas dagegen tun müssen. Das hat geholfen. Dies wurde in der Regel von den PMs der Teams durchgeführt, denn wer, wenn nicht sie, wusste es besser, Ressourcen für die Zukunft zu planen.
Herausforderungen in aktuellen Entwicklungssystemen
Artem Susekov, Miro. Es ist schwierig, das Bewertungssystem sofort auszugleichen, daher bewegen wir uns in Iterationen. Zum Beispiel stellte sich heraus, dass die erste Version der Spur des Teamleiters überlastet war: zu hohe Erwartungen, ein universeller Supersoldat, der im Leben kaum möglich ist.
Wir versuchen derzeit, den Schwellenwert für den Eintritt in die Teamleiterrolle zu vereinfachen, um den Mitarbeitern den Wechsel von einer rein technischen zu einer Manager-Niederlassung zu erleichtern. Ich möchte die Messlatte nicht überschätzen, wir brauchen eine Gelegenheit, um reibungslos in dieses neue Tätigkeitsfeld einzusteigen.
Eine weitere Schwierigkeit ist die übermäßig formale Herangehensweise an den Prozess. Zum Beispiel: "Ich habe 8 von 10 Punkten im Plan erzielt, was bedeutet, dass ich die Erwartungen erfülle und zum nächsten Level übergehen kann." Wir möchten all dies nicht in eine Checkliste verwandeln, die Sie nur schließen müssen, um zum nächsten Level zu gelangen, wie in einem Spiel.
Ich möchte, dass die Menschen auf der Grundlage des Plans über Perspektiven nachdenken können, unabhängig über Bereiche nachdenken können, die für sie interessant sind, dh dass sie damit als Strategie und nicht als Liste formaler Aufgaben arbeiten.
Alexander Borisov, X5 Retail Group. Menschen verstehen oft nicht genau, wie sie in einem Unternehmen wachsen sollen, weil es keine klaren Algorithmen gibt. Gleichzeitig finden Menschen, die wirklich schon befördert werden können, Dinge, in denen sie wachsen können und sollten, jene Dinge, die auf sich genommen und verbessert werden können. Aber es kommt vor, dass man „einfach wachsen“ muss. Aber es ist wahrscheinlich unmöglich, einfach so im Unternehmen zu wachsen, weil Sie wachsen wollen.
Sie wachsen nur, wenn Sie mehr Verantwortung übernehmen, neue Projekte übernehmen.
Sergey Averyanov, Funbox . Seit wir viele Jahre arbeiten, hatten wir viele Probleme und Herausforderungen. Eine der ersten ist zu verstehen, mit wem wir arbeiten wollen, mit wem wir uns entwickeln wollen. Infolgedessen kamen wir zu dem Schluss, dass wir mit Menschen zusammenarbeiten wollen, die wissen, wie man etwas gut macht, und es spielt keine Rolle, worauf es ankommt. Wir nehmen bereitwillig Spezialisten von jedem Stapel, die bereit sind, das zu verwenden, was wir verwenden. Dies stellte sich als ziemlich erfolgreiche Praxis heraus: Es ist immer angenehm und bequem, Menschen zu entwickeln, die bereits über Kompetenzen in einem verwandten Fachgebiet verfügen. Die Wissenslücke, die sie haben, ist kein schwerwiegender Fehler, sondern eine neue Motivation für eine Person, das Studium eines neuen Tätigkeitsfeldes.
Die zweite Herausforderung besteht darin, zu verstehen, wie Ingenieure im Unternehmen wachsen können. Für die Entwicklung müssen Sie komfortable Arbeitsbedingungen schaffen: ein normales Büro, verständliche, einfache, aber strenge Verfahren und Arbeitsvorschriften, Einhaltung des Arbeitsgesetzbuchs, Abneigung gegen Überarbeitung. All dies gibt einem Menschen das Vertrauen, dass er sein Niveau ohne Probleme und ohne Eile erhöhen kann. Sie werden es ihm zeigen, ihm sagen, ihm helfen.
Sie können die Kartoffeln so oft anschreien, wie Sie möchten: „Kartoffeln, wachsen! Tomaten, komm schon! “- aber sie werden nicht daraus wachsen. Sie brauchen guten Boden und Bewässerung.
Die letzte Herausforderung besteht darin, dass nicht alle Menschen dort wachsen wollen, wo wir wollen, dass sie wachsen. Es kommt vor, dass ein starker Spezialist unter keinen Umständen den Verwaltungsaufwand bewältigen und mit jüngeren Kollegen zusammenarbeiten möchte. Hier geht es nicht um formale Dinge, nicht um das Gehalt, sondern nur darum, wofür eine Person ein Interesse und eine Neigung hat. Deshalb legen wir bei allen Ingenieuren Wert auf Leidenschaft, die Fähigkeit, eine komplexe Aufgabe zu übernehmen und sie von Anfang bis Ende in einem mehrstufigen Prozess durchzuführen. In der Regel ist jeder Ingenieur, der dazu in der Lage ist, für uns interessant und angenehm. Gleichzeitig lassen wir aber immer die Möglichkeit für eine Person, ein technischer Experte zu werden, ohne in Verwaltungs- und Managementfunktionen einzutauchen.
Mikhail Mazein, ManyChat... Es ist schwierig genug, die Anforderungen für Noten zu formalisieren, und wir haben auch nicht versucht, sie starr zu formalisieren, sondern uns auf Beispiele für Erwartungen an das konzentriert, was wir von einem Ingenieur in verschiedenen Entwicklungsstadien erwarten würden. All dies war mit einer spezifischen Auswirkung verbunden, die Mitarbeiter auf Team- oder Unternehmensebene auf Prozesse ausüben.
Dies schafft Schwierigkeiten. Einerseits beschränken wir das Wachstum der Menschen nicht, es erscheint eine leere Leinwand vor ihnen, auf der sie ihre Entwicklungsspur zeichnen können. Das Zeichnen eines neuen Bildes auf ein leeres Blatt Papier ist jedoch viel schwieriger als das Bewegen auf dem ausgetretenen Pfad. Wir lösen dieses Problem durch Mentoring. Mentoren helfen dabei, Tracks zu erstellen, die auf den Wünschen der Menschen basieren und diese mit den Bedürfnissen des Unternehmens synchronisieren. Wir versuchen auch, die Denkweise der Problemsuche so zu entwickeln, dass Ingenieure Probleme in den Prozessen erkennen und versuchen, ihre Lösung selbst zu initiieren. Auch hier helfen Mentoren.
Anton Grishin, MadRobots.Es gibt Menschen, für die Wachstum ihr eigenes Bedürfnis ist, und es gibt Menschen, die wachsen, weil es so etabliert ist und dafür die Bedingungen geschaffen wurden. Aber alle haben regelmäßig eine Frage - wofür? Die persönliche Motivation, neue Dinge zu lernen, sich weiterzuentwickeln, geht verloren, weil dies in der gegenwärtigen Realität oder bei gegenwärtigen Kollegen möglicherweise nicht anwendbar ist.
Als eine der Lösungen haben wir interne Meetups abgehalten, jedoch nicht als Hobbygruppe, sondern als interne Konferenz, um ein neues Thema wirklich vorzubereiten. Daraus entstand eine positive Geschichte. Die Jungs begannen untereinander zu verstehen, dass wir, Designer und Designer, unsere Ansätze überdenken und neue Tools ausprobieren können, wenn beispielsweise Frontends etwas Neues tun können. Es stellt sich heraus, dass die natürliche Motivation des anderen, gemeinsam etwas Neues zu versuchen.
Schmerz bewirkt immer die persönliche Herangehensweise jedes Einzelnen an seine eigene Entwicklung.
Wie man eine Entwicklungskultur zu Beginn eines neuen Teams implementiert
Sergey Averyanov, FunBox: Die Tatsache des Unternehmenswachstums hat uns geholfen. Wenn es nicht viele Ingenieure gibt, kochen sie alle zusammen, kennen sich alle und erledigen die gleiche Aufgabe. Und sobald sich verschiedene Arten von Projekten und Rollen in ihnen aneinanderreihen, werden alle Menschen mit unterschiedlichen Befugnissen ausgestattet. Jemand erledigt Aufgaben, jemand ist an Bereitstellungen beteiligt, Cluster, jemand ist am Produktdesign beteiligt.
Für uns ist es wichtig, dass jedes Teammitglied versteht, was es aktualisieren muss, um von einem Entwickler zu einem übergeordneten Entwickler oder Teamleiter zu gelangen.
, 125 , , , , .
Interne Meetups sind sehr nützlich. Wenn ein Unternehmen viele Teams und mehrere Produkte hat, kochen die Leute jeweils in ihrer eigenen Sauce und bei Meetups reden sie, erzählen, was für coole Dinge sie tun, tauschen Wissen aus. Dies schafft keinen Wettbewerb zwischen den Teams, sondern das Streben nach Spitzenleistungen.
Artem Susekov, Miro: In einer Phase des Teamwachstums helfen verschiedene Gilden, die sich um Technologien bilden: Backend, Frontend, QA. In Gilden wird Wissen zwischen verschiedenen Teams ausgetauscht.
Interne Ereignisse helfen auch: Meetups, öffentliche Sprint Reviews, bei denen Teams einen gemeinsamen Kontext haben, sprechen über Ergebnisse. Hier ist es wichtig, den Ingenieuren bei der Vorbereitung auf solche Leistungen zu helfen.
Alexander Borisov, X5 Retail Group:Sie können nicht hoffen, dass Sie sagen, dass Meetups benötigt werden und die Leute beginnen, sich selbst zu organisieren. Sie müssen auch behandelt werden. Bei unserer Skala ist es sinnvoll, verantwortliche Personen auszuwählen, die sie organisieren. Teams haben oft coole Dinge in sich, aber sie kochen in sich selbst. Sie haben einfach nicht genug Zeit, um ein Treffen zu organisieren und ihre Best Practices auszutauschen. Es scheint, wir hätten eine halbe Stunde gebraucht, uns in einem Besprechungsraum versammelt und verbracht, aber nein. Es gibt einige Nuancen.
Mikhail Mazein, ManyChat: Ein gut strukturierter Onboarding-Prozess für neue Mitarbeiter ermöglicht es Ihnen, ihnen die allgemeinen Prinzipien und Ansätze zu vermitteln, um sich ein korrektes Bild vom Team und vom Projekt zu machen. So wird sich die Kultur mit der Ankunft neuer Menschen ansammeln und weitergegeben.
Heiße Frage zum Geld
Eine Frage eines Zuschauers: „Sie berühren nicht die finanzielle Solidität der Organisation. Wie wird der Anteil der Unternehmensausgaben ermittelt, damit der Mitarbeiter während der Arbeitszeit Bücher lesen kann? Das zweite Beispiel ist, dass die Lösung eines Problems für einen Entwickler, der ein solches Problem bereits gelöst hat, 80 Stunden dauert, und 150 Stunden für einen Entwickler, der mit dem Kontext nicht vertraut ist, die Lösung desselben Problems, aber gleichzeitig aufwächst und pumpt. Die Frage ist, wer die Differenz von 70 Stunden für die Entwicklung bezahlen wird. "
Alexander Borisov, X5 Retail Group:In unserem Fall gibt es keinen Kunden. Wir haben begonnen, aktiv ein internes Team aufzubauen, anstatt einige Dinge weiter auszulagern, da wir verstehen, dass Kompetenz für uns sehr teuer ist und zu den endgültigen Kosten für die Erhöhung der Marginalität des Geschäfts eines bestimmten Pyaterochka bei Ihnen zu Hause führt. Es ist eine Investition in die Zukunft.
Wenn jedoch eine Person, anstatt 150 Stunden lang drei Stunden lang eine Aufgabe zu erledigen, ein Buch liest, stellt sich die Frage nur vom Eigentümer des Produkts oder vom Eigentümer des Ressourcenpools. Wenn dies eine verständliche Investition in die Tatsache ist, dass eine Person gewachsen ist, dann ist dies wiederum auf der Ebene dieser beiden Personen leicht zu lösen. Zum Beispiel einen Plan für einen Sprint, in dem wir etwas festgelegt haben, das gelesen werden muss, und wir passen hinein, dies ist eine normale Geschichte.
Artem Susekov, Miro:Auf Unternehmensebene besteht eine Vereinbarung, dass wir Ingenieuren bei der Entwicklung mithilfe von Kursen und Workshops helfen, die innerhalb der Arbeitszeit stattfinden. Das heißt, das Unternehmen zahlt dafür, es ist eine Investition in jedes Teammitglied, da wir glauben, dass diese Art von Investition dem gesamten Team helfen wird, in Zukunft schneller voranzukommen.
Die spezifische Zeit, die dem Ingenieur für die Sprintausbildung vorbehalten ist, wird auf der spezifischen Teamebene besprochen. Hier ist es wichtig, dass es keine Verzerrungen in die andere Richtung gibt, dass wir nur die ganze Zeit während des Sprints lernen und nichts anderes tun.
Sergey Averyanov, FunBox:Ich denke, dass die Frage nach 80 und 150 Stunden für das Outsourcing akuter ist, wenn Sie fragen können: Warum sollte ein unerfahrener Entwickler 150 Stunden für mich als Kunden tun, wenn ein erfahrener Entwickler dasselbe für mich über 80 getan hat? Wie Outsourcing dies löst, kann ich nicht sagen, weil wir nicht auslagern. Im Rahmen eines Produktunternehmens wird dies durch die Tatsache gelöst, dass das Budget konsolidiert wird und die Arbeitskosten für die Entwicklung im Gewinn ausgedrückt werden, da ein Teammitglied sein Niveau erhöht und besser und schneller zu arbeiten beginnt.
Über das Lesen von Büchern während der Arbeitszeit. Wir haben die Praxis, dass die Notwendigkeit, etwas zu lernen, ein ganz natürlicher Schritt bei der Arbeit an einem Problem ist. Wir werfen den Entwickler nicht in einen Strudel und stellen Aufgaben wie: "Lies ein Buch" oder "studiere eine Technologie, die kein endgültiges Ziel hat". Es sollte nicht so sein, dass eine Person sitzt und denkt - habe ich die Technologie bereits studiert oder muss ich mehr lernen? Eine Aufgabe außerhalb des Kontexts, außerhalb eines Ziels führt zu einem Aufschub, zu der Tatsache, dass eine Person das Selbstvertrauen verliert und nicht weiß, wann sie etwas tun soll.
Das Recherchieren und Lesen von Literatur, das Studium von allem sollte Teil der Aufgabe sein, aber es sollte ein konkretes Endziel geben, für das diese Studie angewendet werden kann.
Anton Grishin, MadRobots: Ich komme aus der Welt, in der jede Stunde jemand verdient und jemand Geld verloren hat. In der Regel wird dem Kunden ehrlich gesagt: "Wir werden kein Geld mehr von Ihnen nehmen, aber wir werden die Aufgabe länger erledigen." Das Unternehmen, sein Arbeitgeber, zahlt ohnehin für die Entwicklung eines Ingenieurs. Der Kunde wartet einfach etwas länger, aber in Zukunft merkt er, dass jetzt nicht einer, sondern zwei Entwickler an der Entwicklung seines Produkts beteiligt sind, alles schneller gelöst wird, der Umfang der Implementierung zunimmt.
In Studios und Agenturen, in denen normalerweise Prozesse erstellt werden, wird der Entwickler niemals in ein Projekt einbezogen, das ihn objektiv nicht anzieht, da er dem Unternehmen mehr Verluste bringt, als er durch die Entwicklung verdient.
Alexander Borisov, X5 Retail Group:Zusätzlich zu meiner Arbeit bei X5 habe ich ein eigenes kleines Outsourcing-Studio. Ich verstehe seine Wirtschaft sehr gut. Wir haben 80 bezahlte Stunden festgelegt, aber wir haben verstanden, dass es 150 waren, und die Anzahl der bezahlten Stunden und die Entwicklungszeit waren sehr oft unterschiedlich. Wir haben immer eine Art Aktie genommen und diese Aktie einfach aus unserem eigenen Geld bezahlt. Wenn es irgendwo eine Art höhere Gewalt gibt, bedeutet dies, dass sie aus ihrem eigenen Geld bezahlt wird.
Mikhail Mazein, ManyChat: Die Produktentwicklung, bei der wir keinen externen Kunden haben, löst diesbezüglich unsere Hände erheblich. Im Allgemeinen verfolgen wir nicht die Leistung jedes Einzelnen, sondern messen die Leistung des Teams.
Jedes Team hat seine eigene Kapazität und Geschwindigkeit, sie können sehr unterschiedlich sein, aber im Allgemeinen konzentrieren wir uns auf die Leistung des gesamten Teams als Ganzes. Wie viel Freizeit ein bestimmter Ingenieur im aktuellen Sprint hat, ist für uns als Unternehmen nicht sehr wichtig. Diese Zeit bleibt immer für das Training und ist von Sprint zu Sprint grundsätzlich für jeden Ingenieur unterschiedlich. Irgendwo im Sprint wird das Frontend stärker belastet, im nächsten Sprint wird das Backend stärker belastet, und diese ganze Geschichte wird sich auf lange Sicht ausgleichen.
Wenn wir über die Bewertung der Leistung jeder einzelnen Person sprechen, ist das Team selbst dafür verantwortlich, es ist wie eine selbstregulierende Struktur. Es gibt Situationen, in denen beispielsweise der Mentor dieser Person Feedback gibt, dass etwas mit der Leistung nicht stimmt, oder von seinen Kollegen aus der Funktionsgemeinschaft.
, ?
, Miro: , , . , , … , .
Sergey Averyanov, FunBox: Ich denke, dass es Unternehmen geben kann, die sich auf Spezialisten auf festem Niveau konzentrieren. Sie haben immer den gleichen Job mit den gleichen Qualifikationen, sie wollen niemanden großziehen. Dies wird durch die Tatsache gelöst, dass es einen großen Umsatz gibt und Mitarbeiter, die erwachsen werden könnten, neue Jobs finden. Entweder investieren wir in die Entwicklung der Mitarbeiter und die Expansion des Unternehmens oder wir haben einen Umsatz.
Artem Susekov, Miro: Dies kann bereits berechnet werden. Wenn wir über Umsatz sprechen, werden wir uns an diese Metrik halten, wenn es um Geld geht, oder? Die Kosten für die Gewinnung jeder neuen Person, wie viel Zeit für Personalvermittler aufgewendet wird, wie viel wir für das Onboarding ausgeben und wie viel wir dann, wenn die Person abreist, die Stelle wieder schließen. All dies kann in Geld gezählt werden.
Sergey Averyanov, FunBox:Ein interessanter Indikator, der sogar für sich selbst nützlich ist, ist übrigens die mittlere Arbeitszeit im Unternehmen. Es ermöglicht uns, den Umsatz zu schätzen, dh wie viele Personen in unserem Median arbeiten. Wenn Sie sehen, dass der Median groß ist und an den Rändern dieser Verteilung Menschen stehen, die acht bis zehn Jahre gearbeitet haben, nicht ausgebrannt sind, es ihnen gut geht und alle glücklich miteinander sind, macht mich das glücklich.
Anton Grishin, MadRobots: Es scheint mir, dass das Unternehmen dies jetzt nicht mehr erklären muss. Es ist offensichtlich, dass die Notwendigkeit der Selbstentwicklung den Menschen innewohnt, die intellektuelle Produkte herstellen. Daher kann ich mir nicht einmal Beispiele vorstellen, bei denen Spezialisten des gleichen Niveaus benötigt werden, da genau die Technologien, die wir verwenden, uns vorschreiben, dass wir entwickeln müssen.
Mishan Storozhilov, DevRel-Büro:Es scheint mir, dass es nicht nur um Menschen mit fester Leistung und festen Technologien geht. Ich denke, in dieser Geschichte geht es auch um große Umgestaltungen, große technische Schulden. Wir arbeiten mit Unternehmen zusammen, die die Notwendigkeit verstehen, Ingenieure zu entwickeln, aber die Frage nach der Rechtfertigung der Kosten für Bildung und Entwicklung stellt sich immer wieder.
Sergey Averyanov, FunBox:Hier klang das Wort "Refactoring", und die Einstellung dazu kann interessant sein. Viele Leute denken fälschlicherweise, besonders nicht-technische Spezialisten, dass dies einige seltsame Gesten von Typen in Pullovern sind, die nichts tun und Geld ausgeben. Hier liegt das Problem genau in der Kommunikation, dh der Manager muss verstehen, dass das Refactoring, das heute nicht stattgefunden hat, die verlängerte Entwicklungszeit von morgen ist. Heute werden wir einige Arbeitsstunden sparen und morgen werden wir sie ausgeben.
Wir haben intern vereinbart, dass der Teamleiter das Recht hat zu sagen, dass eine notwendige Voraussetzung für die Erfüllung der Aufgabe die Durchführung eines Refactorings ist. Ohne ihn bekommen wir solchen Unsinn, dass es unmöglich ist, mit ihm zu arbeiten.
Natürlich ist dies letztendlich eine Frage der Einigung, aber wir betrachten Refactoring nicht als Nebenaktivität und Verschwendung von Ressourcen, sondern als Teil des Workflows.
Artem Susekov, Miro: Wenn wir über Produktentwicklung sprechen, sind Vereinbarungen wichtig. Beispielsweise legt der Produktmanager die Prioritäten basierend auf der Bewertung fest, und das Team oder die Stimme des Teams, des technischen Leiters oder des Teamleiters bestimmt genau, wie dies zu tun ist. Das Produkt sagt, was jetzt am wichtigsten ist, der Ingenieur sagt, wie wir es machen werden.
Refactoring ist ein natürlicher Prozess. Das heutige Refactoring kostet uns viel billiger als das Refactoring in einem Viertel. Es ist wie mit einem Kredit - wenn Sie nicht zahlen, müssen Sie das nächste Mal mehr bezahlen.
Alexander Borisov, X5 Retail Group: Es gibt einen Begriff "technische Verschuldung", und gerade in der Phase der Kommunikation zwischen dem Team und dem Produkt verstehen wir, dass dies eine technische Verschuldung ist, wenn wir dies jetzt nicht tun. Dementsprechend wird die technische Verschuldung durch den Sprint höher sein, in sechs Monaten wird sie sogar noch höher sein und Sie müssen mit diesem Prozentsatz bezahlen. Genau wie bei einem regulären Kredit verhandelt das Team auf die gleiche Weise mit dem Produkt, wenn Sie möchten, entweder schneller oder menschlicher. Wenn es schneller ist, müssen Sie eines Tages viel mehr bezahlen. Wie bei einem Darlehen.
Mishanya Storozhilov, DevRel-Büro: Entweder wird diese Schuld einfach zu einer "technischen Hypothek".
Wir haben fünf Ingenieure zusammengebracht, die nur anderthalb Stunden miteinander gesprochen haben und bereits über Refactoring gesprochen haben.
* * * Das
zweite Treffen der Serie findet am 20. August statt . Das Thema ist Toxizität in Teams, Unternehmen und der Industrie. Referenten - Ingenieure und technische Leiter von Miro, SEMrush, Parma TG, Xsolla.
Die Registrierung ist offen .