<\/a><\/noindex><\/p>\nEine Gruppe von Studenten-Linux-Fans<\/h2>\n \nDmitri Stolyarov (Technischer Direktor) w\u00e4hrend seiner Pr\u00e4sentation<\/i><\/p>\n
\u2014 (Dima Stolyarov)<\/b> Wir haben uns immer mit Linux und Open Source besch\u00e4ftigt, aber begonnen haben wir mit einem ziemlich lustigen Thema, f\u00fcr das wir uns jetzt ein wenig sch\u00e4men. Wir dachten irgendwie, dass wir Linux anstelle von Windows in B\u00fcros einf\u00fchren sollten. Der erste Name der Firma war TrueOffice \u2014 \"echt B\u00fcro\". Dann haben wir verstanden, dass das niemand braucht. Das war 2006, ich war 19 Jahre alt. Erst 2012-13 kam das Bewusstsein, wie man ein Gesch\u00e4ft macht, welche Technologien die Welt braucht.<\/p>\n
Alexander Batalov (Gesch\u00e4ftsf\u00fchrer) am Stand des Unternehmens auf der Konferenz<\/i><\/p>\n
\u2014 (Sascha Batalov)<\/b> Neben den Technologien gibt es einen riesigen Bereich im Marketing, Sales und der Wirtschaft, den uns niemand jemals beigebracht hat, au\u00dfer den Kursen an der Universit\u00e4t, aber ich wei\u00df nicht, wie anwendbar und n\u00fctzlich die tats\u00e4chlich sind. <\/p>\n
Zun\u00e4chst dachten wir, dass das alles nicht notwendig ist, aber sp\u00e4ter mussten wir es in der Praxis lernen, B\u00fccher lesen, manchmal schon nachdem wir Fehler gemacht hatten. Insgesamt gingen wir einen langen, steinigen Weg und probierten eine Menge falscher Dinge aus. <\/p>\n
\u2014 (\u0414\u0421)<\/i> Aber allm\u00e4hlich, mit dem Wachstum unserer Qualifikationen, spezialisierten wir uns immer mehr auf Linux, und jetzt besch\u00e4ftigen wir uns nur noch mit Highload, hochbelasteten Webprojekten. Und als Kubernetes auftauchte, verstanden wir schnell, dass es das Fundament war, das uns so gefehlt hat. <\/p>\n
\u2014 Warum gab es so ein Interesse an Linux? Ideologisch oder technologisch?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Die Firma hat zwei Gr\u00fcnder \u2013 Dima Schurupow und mich. Dima Schurupow hatte mehr Interesse an Open Source. Und ich mochte Linux gerade aus technologischer Sicht, wie alles dort aufgebaut ist. Daraus entstand eine Kombination: Dima mag die Ideologie, und ich die Technologie. Ich liebe Open Source als Idee, aber mir war die technologische Seite immer wichtiger.<\/p>\n
Einstein sagte: \u201eMan muss es so einfach wie m\u00f6glich, aber nicht einfacher machen.\u201c Genau so ist Linux aufgebaut \u2013 so einfach, zuverl\u00e4ssig und transparent, dass ich es genie\u00dfe. Wir alle mochten es, und wir verwandelten uns von einer Gruppe Studenten in ein gro\u00dfes Unternehmen. Jetzt sind wir schon 70. F\u00fcr die IT und spezialisierte Dienstleistungen ist das ziemlich viel.<\/p>\n
\u2014 Wie war es in den Zeiten der Studentengruppe?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Wie das bei Studenten \u00fcblicherweise so ist \u2013 lustig und lebhaft.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Eine riesige Menge an Altruismus, der Wunsch, das Internet zu erobern, technologische H\u00f6hen zu erklimmen. Wir st\u00fcrzten uns in sehr komplexe Aufgaben \u2013 manchmal nahmen wir uns ernsthafte (aber sehr interessante!) Projekte im Bereich Systemintegration vor, und das f\u00fcr einen minimalen Preis. Wir versuchten, unsere eigenen Frameworks zu entwickeln, nahmen alle Technologien auf, die wir kennenlernen konnten, und suchten sofort nach deren Anwendung.<\/p>\n
\u2014 Hat es kommerziell funktioniert?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Ja, aber in den fr\u00fchen Phasen brauchten wir nichts. Damals war ein Einkommen von 40.000 Rubel f\u00fcr mich absolut normal, ich lebte gut davon.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Ich dachte, dass man f\u00fcr tausend Dollar jede Website machen kann, die man sich nur vorstellen kann.<\/p>\n
\u2014 (\u0414\u0421)<\/i> Im Jahr 2013 hatten wir kein Geld, um in Moskau frei einzustellen. Alle Bekannten, die wir nehmen konnten, hatten wir bereits genommen. Wir entschieden uns, ein B\u00fcro in Nischni Nowgorod zu er\u00f6ffnen. Wir fuhren dorthin, er\u00f6ffneten es und begannen, einzustellen. Sp\u00e4ter verstanden wir, dass es schwer ist, mit zwei B\u00fcros zu leben, und entschieden uns, ganz ohne B\u00fcros zu leben.<\/p>\n
Nat\u00fcrlich haben wir eine ganze Menge Fehler gemacht. Nur im Jahr 2016 habe ich zu meinem Bedauern Remote gelesen. Ich habe geweint und gelacht, weil wir den gleichen Weg gegangen sind. Jeder Absatz \u00e4u\u00dferte sich zu meinen pers\u00f6nlichen Erfahrungen. <\/p>\n
\u2014 (\u0421\u0411)<\/i> In jedem Absatz waren unsere Narben.<\/p>\n\nWas macht Flant<\/h2>\n \n
Um eine qualitativ hochwertige Produktion zu gew\u00e4hrleisten, braucht man 15-20 DevOps, Datenbankspezialisten, Kubernetes-Experten, einen Support-Service und so weiter. Und wenn das Unternehmen klein ist, wo nur zwei bis drei Dutzend Entwickler arbeiten, ist das unm\u00f6glich. Hier kommen wir ins Spiel und retten die Situation. F\u00fcr etwa 150.000.<\/p>\n
Fr\u00fcher war es unsere Mission, ein Unternehmen zu schaffen, in dem es uns selbst angenehm ist zu arbeiten, so dumm das auch klingen mag. Jetzt, wo wir das erreicht haben, besteht unsere Mission darin, Technologien auf dem Niveau von Google und Facebook kleinen Unternehmen und Startups in fr\u00fchen Phasen zug\u00e4nglich zu machen.<\/p>\n
Die Menschen k\u00f6nnen sich auf ihr Produkt konzentrieren, anstatt Probleme zu \u00fcberwinden, die man nicht \u00fcberwinden muss.<\/p>\n
Viele Jungs, die zu uns kommen, sind \u00fcberrascht, wie viel es gibt, welche Lasten \u00fcberall anliegen. Wir haben \u00fcber 50 Projekte in Produktion und mehr als 70 Kubernetes-Cluster. Man kann immer etwas drehen. Man \u00f6ffnet den Zeichenbereich, skizziert eine microservice Architektur, erstellt eine Liste von 200 Technologien \u2013 und los geht's. Aber das f\u00fchrt immer zu Problemen und Konsequenzen. <\/p>\n
Das Besondere ist, auf der einen Seite maximale Stabilit\u00e4t, Zuverl\u00e4ssigkeit und Einfachheit zu gew\u00e4hrleisten, auf der anderen Seite ein hohes Ma\u00df an Innovation. Wir sind stolz darauf, dass wir das k\u00f6nnen. Wir machen das \u00fcberall und in gro\u00dfem Ma\u00dfstab, wie ein gewisses Ikea.<\/p><\/blockquote>\n
Wem braucht Outsourcing-DevOps<\/h2>\n \nMir scheint, gro\u00dfe Unternehmen ziehen es vor, DevOps in der eigenen Belegschaft zu halten.<\/b><\/p>\n
\u2014 (\u0421\u0411)<\/i> Es ist klar, dass gro\u00dfe Akteure wie Avito oder Badoo sich eine DevOps-Abteilung aufbauen k\u00f6nnen. Kleine Unternehmen mit riesigen Investitionen k\u00f6nnen das auch \u2013 aber sie k\u00f6nnen zwar DevOps einstellen, es ist jedoch nicht sicher, dass sie die Ressourcen haben, um den Herausforderungen gewachsen zu sein.<\/p>\n
Wir sind der Meinung, dass selbst gro\u00dfe Unternehmen besser Experten konsultieren sollten, die auf diesem Gebiet viel Erfahrung haben. kleinen Unternehmen, die im Webbereich t\u00e4tig sind, ist es einfach notwendig, sich an erfahrene Fachleute zu wenden. Denn jede einfache Entscheidung in einem zentralen System ist eine Geldverschwendung.<\/p>\n
\u2014 (\u0414\u0421)<\/i> Wir wissen, dass die Menschen in Russland Angst vor Outsourcing haben - aufgrund negativer Erfahrungen und anderer Gr\u00fcnde. Aber unsere Kunden wechseln nicht zu anderen Anbietern. In den letzten zehn Jahren haben nur aus zwei Gr\u00fcnden Kunden gek\u00fcndigt. Entweder sind sie gewachsen (zum Beispiel wurden sie \u00fcbernommen und alles wurde umstrukturiert), oder sie mussten schlie\u00dfen, weil die Idee nicht funktioniert hat.<\/p>\n
\u2014 Und wer kommt h\u00e4ufiger zu Ihnen \u2014 kleine Unternehmen oder gro\u00dfe?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Momentan ist es gleich. Aber kleine Unternehmen haben einfach Angst vor uns, sie denken, dass wir\u2026 <\/p>\n
\u2014 (\u0421\u0411)<\/i>\u2026 gro\u00df, kompliziert, unerreichbar und in den Wolken schwebend sind. <\/p>\n
\u2014 (\u0414\u0421)<\/i> Nun ja, man geht an einem Autohaus mit einem Maybach vorbei und fragt nicht nach dem Preis, weil man denkt, dass ein Maybach nicht 500.000 Rubel kosten kann. <\/p>\n
\u2014 Nat\u00fcrlich kann er das nicht.<\/b><\/p>\n
\u2014 (\u0421\u0411)<\/i> Aber sobald er im Carsharing verf\u00fcgbar ist, kann man sich eine Fahrt damit leisten. <\/p>\n
\u2014 (\u0414\u0421)<\/i> Ja, wir sind nat\u00fcrlich kein Maybach \u2014 wir sind Ikea. Bei uns ist es auch einfach, zuverl\u00e4ssig und erschwinglich. Insgesamt ist die Anzahl der Unternehmen, die sich an uns wenden, bei den TOP-50 und kleinen Unternehmen gleich. Aber wir konzentrieren uns haupts\u00e4chlich auf kleine Unternehmen und arbeiten haupts\u00e4chlich mit ihnen, w\u00e4hrend wir bem\u00fcht sind, nicht mit gro\u00dfen Unternehmen zusammenzuarbeiten. <\/p>\n
\u2014 Warum?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Viel B\u00fcrokratie.<\/p>\n
\u2014 (\u0421\u0411)<\/i> In einem gro\u00dfen Unternehmen gibt es viele Ebenen, auf denen die Verantwortung verteilt ist, das Feedback dauert sehr lange, und oft fangen die Leute an, mit Technologien zu spielen: \u201eLasst uns das abw\u00e4gen, lasst uns eine Strategie schreiben, einen Plan f\u00fcr das kommende Jahr erstellen, lasst uns das besser machen, das sieht sch\u00f6ner f\u00fcr die Unternehmenskultur aus, so ist unsere Praxis gewachsen\u201c. Und so beginnen sie, Dinge zu komplizieren, die man einfach und effektiv l\u00f6sen k\u00f6nnte, sodass 80% des Ergebnisses bereits morgen verf\u00fcgbar sind. Sie nehmen den langen Weg, bei dem unklar ist, ob es \u00fcberhaupt funktioniert oder nicht. <\/p>\n
Infolgedessen erfinden wir anstelle von bew\u00e4hrten Praktiken das Rad neu, und die Kosten f\u00fcr die technologische L\u00f6sung steigen unvergleichlich an. Dabei ist nicht einmal garantiert, dass die Qualit\u00e4t besser wird. <\/p>\n
\nKosten f\u00fcr Outsourcing<\/h2>\n \n
Alle Leute im Unternehmen tragen auf die eine oder andere Weise bei \u2013 sei es durch R\u00fcckmeldungen, Dokumentation oder Code. Wir betrachten das als unseren Beitrag zu der reichen Welt der Open-Source-Tools, die wir verwenden. Und ich denke, wir leisten diesen Beitrag auf w\u00fcrdige Weise.<\/p>\n
Wir nennen es die Kondensation von Erfahrungen. Anfangs hat eine Person etwas gelernt und es mit den Kollegen geteilt, die Erfahrung wurde folkloristisch. Dann haben wir die Dokumentation aufgezeichnet und sp\u00e4ter in Tools extrahiert und vergessen, weil wir nicht mehr daran denken \u2013 alles wird automatisch erfasst.<\/p><\/blockquote>\n
Die Popularit\u00e4t der Technologien und die Toxizit\u00e4t der Entwickler<\/h2>\n \n\u2014 Warum gerade Ubuntu? Was wurde bevor es gew\u00e4hlt wurde noch in Betracht gezogen?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Wir waren eine Gruppe von Studenten, die Linux mochten. Und wir haben lange Gentoo verwendet \u2013 das ist eine source-basierte Distribution, die man jedes Mal von Grund auf kompilieren muss. Als wir ein paar hundert Server hatten, dauerte das Update Monate. Zuerst haben wir alles automatisiert und optimiert, aber schlie\u00dflich haben wir erkannt, dass wir etwas \u00e4ndern m\u00fcssen, und in Anbetracht der Vor- und Nachteile der verschiedenen L\u00f6sungen haben wir einfach das beliebteste genommen. Damals schien es intuitiv \u2014 wenn es das beliebteste ist, wird es sich am besten entwickeln, und schlie\u00dflich werden alle M\u00e4ngel fr\u00fcher oder sp\u00e4ter behoben. <\/p>\n
Es gab eine Datenbank namens Resync DB. Sie konkurrierten mit MongoDB und wurden ungef\u00e4hr zur gleichen Zeit gegr\u00fcndet. Lange Zeit war Resync technologisch \u00fcberlegen.<\/p>\n
Als die Benutzer kamen, versuchten sie interne Systemprobleme zu l\u00f6sen, w\u00e4hrend in MongoDB diese viel weniger angegangen wurden, sie konnten jedoch bedingt ein if einf\u00fcgen, um in synthetischen Tests besser abzuschneiden. Daher wuchs die Popularit\u00e4t von MongoDB. In den einfachsten F\u00e4llen schnitten sie besser ab, waren aber intern schlecht. Resync DB war intern gut, hatte jedoch nicht die gleiche Popularit\u00e4t.<\/p>\n
Letztendlich wurde es intern bei MongoDB gut, w\u00e4hrend sich niemand mehr an Resync DB erinnert. Das Unternehmen ist bankrott gegangen. So eine Geschichte ist es auch mit Ubuntu. Auf dieser Distribution liegt viel Fokus, daher haben wir uns entschieden, sie zu verwenden.<\/p>\n
\u2014 Was halten Sie von den letzten politischen Ver\u00e4nderungen, CoC und all dem?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Nun\u2026 es gibt keinen Negativ, alles ist in Ordnung, alles ist klar. Ich selbst leide darunter, dass ich manchmal Menschen verletze. Mir erscheint eine Sache offensichtlich, und es f\u00e4ngt an, mich zu w\u00fctend, dass Menschen es nicht verstehen. Ich werde w\u00fctend, und es entsteht negative Stimmung (aber ich arbeite daran).<\/p>\n
Linus ist sehr intelligent, schlie\u00dflich arbeitet er seit 30 Jahren damit. Es ist klar, dass er ein scharfer Typ ist, der nicht um den hei\u00dfen Brei redet. Seine H\u00f6flichkeit leidet, und die Community arbeitet daran. Er versteht selbst alles und erkennt es an. <\/p>\n
\u2014 Aber wie ich aus der Reaktion in den Diskussionen verstanden habe, unterst\u00fctzen viele Menschen die Idee, direkt und hart zu reden, und wenn es jemandem nicht gef\u00e4llt \u2014 nicht zuckerhaltig, schmelzen nicht.<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Nein, das ist nicht so. Ich, als jemand, der an der Abwesenheit von H\u00f6flichkeit leidet, verstehe, dass das sehr schlecht ist. Es schadet der Community. Es gibt Menschen, denen es egal ist, aber f\u00fcr die meisten Menschen ist es dennoch wichtig, emotionalen Komfort zu haben.<\/p>\n
Da ist ein dummer Fehler im Code. Man k\u00f6nnte sagen: \u201eLeute, es ist schlecht, dass wir solche einfachen Dinge \u00fcbersehen, wir m\u00fcssen das korrigieren.\u201c Man k\u00f6nnte aber auch sagen: \u201eWelcher Idiot hat das gemacht?!\u201c. Ein Satz. Die Person, die diesen Fehler gemacht hat, k\u00f6nnte sogar schlauer und erfahrener sein als du, war aber einfach nicht in der Stimmung, als der Fehler passierte \u2014 man wei\u00df nie, was ihm passiert ist. Und f\u00fcr ihn wird es eine direkte Beleidigung sein. Warum braucht man das?<\/p>\n
Man muss Dinge direkt ansprechen, aber man muss nicht sagen: \u201eWelcher Idiot hat das geschrieben\u201c. Es macht auch keinen Sinn, alles zu verbergen und zu umschreiben, aber man sollte die Menschen nicht beleidigen.<\/p>\n
Warum m\u00fcssen sich DevOps jeden Tag zusammenschalten?<\/h2>\n \n(\u0414\u0421)<\/i> Momentan haben wir ein kleines B\u00fcro, in dem Dokumente liegen und ein Office-Manager sitzt, der sich um diese Dokumente k\u00fcmmert.<\/p>\n
In der Firma arbeiten 70 Personen. 20 Personen sind im OPS-Team. 30 Personen sind in drei DevOps-Teams, die jeweils etwa 10 Personen haben. Die restlichen 20 sind Entwickler und im Vertrieb. 8 Entwickler, im rnd-Team sind 4 Personen. Nicht-technische Personen in der gesamten Firma sind 5-6.<\/p>\n
Die wichtigsten Gelder werden von den drei DevOps-Teams verdient. Die Prozesse sind \u00fcberall gleich \u2014 jeden Tag ein langes Meeting, eine bis eineinhalb Stunden. Dort werden alle technischen Fragen gekl\u00e4rt, und die Leute entscheiden, was als N\u00e4chstes zu tun ist. Da alle remote arbeiten \u2014 ist es eine M\u00f6glichkeit, normal zu kommunizieren.<\/p>\n
\u2014 Ist das wirklich jeden Tag notwendig?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Ja.<\/p>\n
\u2014 Sind sich alle dabei einig?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Ja, alle sind einverstanden, alle f\u00fchlen sich wohl. Aber an manchen Tagen kann das Meeting auch nur 30 Minuten dauern. Trotz der sehr intensiven Kommunikation in Slack m\u00f6chte man sich trotzdem gut synchronisieren und verstehen, was gestern passiert ist. Wir wollen einander verstehen, und nicht nur Aufgaben abarbeiten. Das ist ein kulturell wichtiger Punkt.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Es kann jederzeit etwas passieren, die Situation kann sich \u00e4ndern. Eine st\u00e4ndige Anpassung ist notwendig. <\/p>\n
\u2014 (\u0414\u0421)<\/i> Hast du einen guten Witz zu diesem Thema?<\/p>\n
\u2014 (\u0421\u0411)<\/i> Ja. Ein Herzchirurg kommt in eine Werkstatt, und der Mechaniker sagt zu ihm: \u201eH\u00f6r mal, wir machen dasselbe, nur du operierst das Herz eines Menschen, und ich das Herz eines Autos. Du bekommst 10.000 $ f\u00fcr die Operation, w\u00e4hrend ich f\u00fcr den Service 100 Rubel bekomme.<\/p>\n
Der Chirurg fragt: \u201eWillst du auch 10.000 f\u00fcr die Reparatur bekommen?\u201c Der Mechaniker antwortet: \u201eNat\u00fcrlich.\u201c Der Chirurg setzt sich ins Auto, startet es und sagt: \u201eMach mal.\u201c<\/p>\n
So ist es auch bei uns. In der Entwicklung kannst du eine Aufgabe \u00fcbernehmen und nach zwei Wochen ein Ergebnis pr\u00e4sentieren. Danach kann alles angepasst werden, denn plus\/minus drei Tage haben keinen Einfluss. <\/p>\n
In unserem Fall kann jeder vers\u00e4umte Alert oder falsche Entscheidung zu einem gro\u00dfen Problem f\u00fchren. Um das zu vermeiden, ist eine enge, schnelle und st\u00e4ndige Kommunikation notwendig.<\/p>\n
\nIst es schwierig, auf Homeoffice umzusteigen?<\/h2>\n \nEs ist schwierig, Menschen aus der Ferne zu f\u00fchren. Aber es ist nur so lange schwierig, bis du in einem B\u00fcro bist und sie in einem anderen, und man hat einen Tunnelblick. Du sitzt in Moskau und denkst, die Jungs aus Nischni Nowgorod arbeiten schlecht und ineffizient. In Moskau siehst du die Anstrengungen der Menschen um dich herum, aber die der Remote-Mitarbeiter siehst du nicht. Du akzeptierst nur das Ergebnis. <\/p>\n
Im B\u00fcro gibt es sehr viel Kommunikation in informalisierter Form \u2014 jemand hat auf dem Weg zur K\u00fcche jemandem etwas gesagt. Menschen im anderen B\u00fcro sehen das nicht, f\u00fchlen es nicht, und der Kontext geht verloren.<\/p>\n
Zu dem Zeitpunkt, als wir bereit waren, auf das B\u00fcro zu verzichten, wurde die gesamte Kommunikation (selbst zwischen Mitarbeitern im selben Raum) \u00fcber Google Meet abgewickelt. Und als wir die gesamte Kommunikation remote aufbauten, funktionierte das zu 100 %, alle Barrieren des Missverst\u00e4ndnisses wurden abgebaut.<\/p>\n
Es ist schwierig, alles aufzubauen, aber wenn alles richtig gemacht wird, funktioniert es und verursacht keinerlei Unbehagen.<\/p><\/blockquote>\n
Wie Teams selbst ihre Finanzen verwalten<\/h2>\n \n\u2014 Homeoffice \u2014 ein umstrittenes Thema. Manchmal haben Unternehmen Angst, Mitarbeiter nach Hause zu schicken, weil sie denken, sie verlieren die Kontrolle \u00fcber sie. Aber die, die es tun, sagen auch, dass man ganz anders arbeiten muss.<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Wir haben dieses Problem gel\u00f6st, indem wir bereit sind, mit den Teams Geld zu teilen. Unsere gesamte Wirtschaft und das Anreizsystem sind fast wie eine Franchise aufgebaut. Die Geh\u00e4lter sind ziemlich hoch, plus wir lassen den Leuten etwas freies Geld.<\/p>\n
Das Team betreut einen Pool von Projekten. Sie wissen, wie viel jedes dieser Projekte einbringt. Sie wissen genau, welchen Anteil sie an diesem Geld haben. Alles Geld, das \u00fcber ihre Geh\u00e4lter hinaus \u00fcbrig bleibt, bleibt im Team und wird nach einem bestimmten System unter ihnen aufgeteilt. Die Motivation ist absolut direkt \u2014 ein Projekt f\u00fcr 200.000 Euro akquiriert, die Geh\u00e4lter steigen um zehn Euro. Einen Fehler gemacht \u2014 man muss den Kunden entsch\u00e4digen.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Wenn du anf\u00e4ngst, die Leute im Stich zu lassen, merkt man das sofort. Du versperrst dir die M\u00f6glichkeit, zus\u00e4tzliches Einkommen zu erzielen. Unsere Systeml\u00f6sung f\u00fcr das Kontrollproblem ist vollst\u00e4ndig. Jeder plant seinen Tag selbst, und t\u00e4gliche Meetings reichen aus, um zu verstehen, wer was macht.<\/p>\n
\u2014 (\u0414\u0421)<\/i> In Kriegszeiten l\u00fcgen Kameraden im Sch\u00fctzengraben nicht. <\/p>\n
\u2014 Habt ihr also offene Geh\u00e4lter? Jeder wei\u00df, wer wie viel verdient? <\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Wir haben die Geh\u00e4lter vor einiger Zeit geschlossen. Es gibt regionale Unterschiede. Obwohl wir bestrebt sind, in den Regionen die vollen Moskauer Geh\u00e4lter zu zahlen, gibt es dennoch gewisse Diskrepanzen.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Jetzt wissen alle, wie viel Geld das Team insgesamt hat. Sie sehen, welchen Anteil sie an den Boni erhalten. <\/p>\n
\u2014 (\u0414\u0421)<\/i> Der Teamleiter jedes Teams entscheidet, wie viel seine Leute bekommen und wie die Boni verteilt werden. Wir mischen uns nur mit Ratschl\u00e4gen ein, die Entscheidung liegt immer beim Teamleiter.<\/p>\nWarum Leute Angst vor Stellenangeboten haben<\/h2>\n
\nFeier zum 10-j\u00e4hrigen Bestehen des Unternehmens im Jahr 2018<\/i><\/p>\n
\u2014 Reichen Ihnen 70 Personen?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Nein. Wir planen, in einem Jahr mindestens 20 DevOps-Ingenieure einzustellen. Aber das ist sehr schwierig. Wir haben einen gro\u00dfen Pool an Kandidaten, alle wissen irgendwie von uns. Aber hier ist es wie bei Kunden. Viele sagen: \u201eWir haben Angst, bei euch zu arbeiten, was, wenn wir nicht mithalten k\u00f6nnen?\u201c Aber wir glauben nicht, dass wir hier etwas Superbesuchen haben.<\/p>\n
Korrespondenz mit einem Kandidaten<\/i><\/p>\n
\u2014 Wie muss man sein, um mitzuhalten?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Theoretisch sollte ein Mensch gleichm\u00e4\u00dfig in der Entwicklung und Nutzung sein. In der Praxis gibt es solche Menschen auf der Welt nur in Einzelf\u00e4llen, ganz zu schweigen von Russland. Besonders von denen, die sowohl senior sind als auch dort. Ich w\u00fcrde mich sogar selbst nicht unbedingt zu ihnen z\u00e4hlen.<\/p>\n
In unseren Stellenanzeigen steht immer klar, was man wissen sollte. Wir arbeiten viel daran und versuchen, konkret zu schreiben.<\/p>\n
\u2014 Ziehen die Stellenanzeigen vielleicht wirklich ab, wenn aufgeschrieben wird, was man alles wissen muss?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Nein, nein, nein, wir glauben nicht, dass man viel wissen muss. <\/p>\n
\u2014 (\u0421\u0411)<\/i> Uns interessieren nicht die Kenntnisse, sondern das Denken, die F\u00e4higkeit des Menschen, L\u00f6sungen zu finden.<\/p>\n
\u2014 (\u0414\u0421)<\/i> Wir interessieren uns f\u00fcr Erfahrung mit Linux und pr\u00fcfen diese mit ausreichend einfachen Aufgaben \u2014 nur in gro\u00dfer Anzahl. Unser Test dauert ziemlich lange, im Durchschnitt ben\u00f6tigt ein Kandidat daf\u00fcr 8 Stunden. Und am Ende schauen wir, wie der Mensch mit Problemen umgegangen ist, wie er googelt und wie breit sein Horizont ist.<\/p>\n
Das Wissen kann man bei uns sehr schnell erwerben, da es viele verschiedene Projekte und erfahrene Kollegen gibt, die immer helfen k\u00f6nnen. Daher schauen wir in erster Linie, dass die Kollegen schnell denken und Erfahrungen haben.<\/p>\n
\u2014 Neben dem Test erkennt ihr das auch auf andere Weise?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Wir haben drei Phasen. Zuerst spricht der HR-Mitarbeiter und bittet um einen Erfahrungsbericht. Dann durchlaufen diejenigen, die dem HR-Mitarbeiter gefallen, eine Testaufgabe. Am Ende kommunizieren die Teamleiter und geben dem HR-Mitarbeiter ihre Meinungen. Wenn sie einstimmig positiv sind, ist das ein Grund, dem Kandidaten ein Angebot zu machen.<\/p>\n500 Tausend Rubel f\u00fcr die Einstellung des zuk\u00fcnftigen Superhelden<\/h2>\n
\n\u2014 (\u0414\u0421)<\/i> Wir haben eine sehr untypische Einstellung zu Finanzen, wir teilen sie mit den Teams und sind nicht geizig. Au\u00dferdem stellen wir dem Team 500 Tausend Rubel zur Verf\u00fcgung, um den Personalbestand zu erweitern. Das hei\u00dft, das ist ein Zuschuss, damit sie jemanden finden und ihn alles lehren k\u00f6nnen, w\u00e4hrend er sich eingew\u00f6hnt.<\/p>\n
\u2014 500 Tausend pro Person?!<\/b><\/p>\n
Damit das Team viel Geld verdienen kann, muss es mehr Projekte annehmen. Daf\u00fcr braucht es mehr Leute. Und um mehr Leute zu bekommen, ben\u00f6tigt man mehr Geld. Das ist ein Teufelskreis. Um diesen Kreis zu durchbrechen, geben wir Geld f\u00fcr eine neue Person. Solange er sich eingew\u00f6hnt, k\u00f6nnen sie noch mehr Projekte annehmen und bereits aus diesem Geld sein Gehalt zahlen. Das hei\u00dft, es ist eine Entsch\u00e4digung, bis der Neue Geld bringt. <\/p>\n
\u2014 Ist das nicht zu viel f\u00fcr DevOps? Sie sind jeden Tag belastet, jeden Tag in der Einsatzumgebung, und m\u00fcssen sich auch noch um das Finanzmanagement k\u00fcmmern.<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Das \u00fcbernimmt der Teamleiter, der nicht mehr ganz im DevOps t\u00e4tig ist. Teamleiter neigen eher dazu, Partnerschaften einzugehen, um Optionen zu haben. Daher halten wir es f\u00fcr normal, dass dies f\u00fcr sie in Ordnung ist. Die regul\u00e4ren Teammitglieder sind davon nicht betroffen.<\/p>\n
Gro\u00df gesagt wissen sie \u2014 wenn ein Kollege ausf\u00e4llt, bekommen sie im n\u00e4chsten Monat sein Gehalt. Nat\u00fcrlich m\u00fcssen sie mehr arbeiten. Und wenn sie einen Ersatz finden, geben sie ihm das Geld zur\u00fcck. <\/p>\n
Wenn wir Teamleitern 500.000 geben, wollen sie keinen Menschen einstellen, der nicht funktioniert. Manchmal ist es einfacher f\u00fcr sie, 20 Personen auszusieben und einen auszuw\u00e4hlen. Es war so, dass sie mit dem Personalvermittler mit 100 Personen gesprochen haben, 30 davon gingen zur technischen Aufgabe, 20 bestanden, und alle au\u00dfer einem wurden vom Teamleiter ausgesiebt. Das ist heftig. Teamleiter haben gro\u00dfe Angst zu riskieren. Wir haben das Thema diskutiert und alle schienen zu verstehen, dass es ein Fehler ist. Viele Menschen zeigen sich im Interview nicht so, wie sie sp\u00e4ter arbeiten werden. Daher muss man Chancen geben und Risiken eingehen.<\/p>\n
\u2014 Aber missbrauchen die Teamleiter das nicht? Du bekommst 500.000, stellst sehr lange niemanden ein, bekommst noch einmal 500.000.<\/b> <\/p>\n
\u2014 (\u0414\u0421)<\/i> Sie erhalten das Geld nur einmal. Wir sagen: \u201eAktuell habt ihr zehn Personen, aber ihr braucht 11. Es gibt einen Verkaufsplan, es werden weitere Projekte kommen, und ihr m\u00fcsst bereit sein. Hier sind 500.000 f\u00fcr die elfte Position.\u201c Ein zweites Mal bekommt ihr das nicht. Und wenn jemand geht, ist das ein Problem des Teams; sie l\u00f6sen die Angelegenheit im Rahmen ihres Budgets. <\/p>\n
Es ist wie ein Monopoly-Spiel.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Wir sind der Meinung, dass der Teamleiter in die Finanzen eingebunden sein sollte. Bei uns erhalten die Leute ihr Gehalt aus dem Geld, das sie verdienen. Und der Grad der Ausgaben f\u00fcr das Projekt ist sehr wichtig. Der Kunde kommt mit einer Infrastruktur, und nach einem Jahr hat seine Infrastruktur das Zehnfache davon. Wenn der Teamleiter nicht an den Finanzen beteiligt ist, kann er die Kosten f\u00fcr den Support nicht angemessen einsch\u00e4tzen.<\/p>\n
\u2014 (\u0414\u0421)<\/i> Es kommt vor, dass das Team mehrere Monate lang mit den Problemen des Kunden k\u00e4mpft und versteht, dass sie daf\u00fcr eine hypothetische Summe von hunderttausend erhalten, die nicht mit dem \u00fcbereinstimmt, was gerade passiert. Und so schmerzhaft es auch sein mag, sie m\u00fcssen entweder den Preis erh\u00f6hen oder sich trennen. Und die Leute treffen diese Entscheidungen selbst. Dabei arbeiten sie alle remote. Und wir glauben, dass das unser gr\u00f6\u00dfter Erfolg ist. Bei uns gibt es wirklich autonome, motivierte Teams.<\/p>\n
\u2014 Ja. Und es klingt so, als m\u00fcsste man ein Superheld sein, um hier zu arbeiten. Sowohl technische F\u00e4higkeiten als auch Selbstdisziplin und finanzielle Bildung sind notwendig.<\/b><\/p>\n
\u2014 (\u0421\u0411)<\/i> Hier kann man ein Superheld werden. Aber selbst die Teamleiter, die das tun k\u00f6nnen, haben als gew\u00f6hnliche Ingenieure angefangen. Normalerweise braucht es ein bis zwei Jahre, um sich in einen solchen Superhelden zu verwandeln.<\/p>\n
\u2014 Teamleiter-Partner sind aus normalen Ingenieuren geworden. K\u00f6nnen sie sofort f\u00fcr eine solche Position eingestellt werden?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> So etwas gab es bei uns noch nie, alle sind aus Ingenieuren hervorgegangen. Aber wir ziehen in Betracht, uns mit einem kleinen Unternehmen zusammenzuschlie\u00dfen, das einfach ein weiteres Team von uns wird. Wir m\u00f6chten so etwas ausprobieren.<\/p>\n
\u2014 K\u00f6nnen Sie jemanden einstellen, wenn er ein guter Ingenieur ist, aber nicht genug organisiert f\u00fcr das Niveau solcher Teams?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Wir haben keine Angst vor unorganisierten Menschen, schlie\u00dflich haben wir einen Strom von Aufgaben. Es stellt sich sehr schnell heraus, ob man einer Person helfen kann, sich zu organisieren. Wenn er jeden Tag erz\u00e4hlt, was er gemacht hat, aber in der Realit\u00e4t nichts tut, wird er sich sch\u00e4men. <\/p>\n
Wenn du siehst, dass alle in einem Boot sitzen und rudern, f\u00fchlt es sich unbehaglich an, das Paddel wegzulegen. In solchen Bedingungen werden selbst unorganisierte Menschen organisiert. Wenn nicht, dann eben nicht.<\/p>\n
Wir k\u00f6nnen Oberfl\u00e4chlichkeit bei Menschen, bei Gesch\u00e4ften und bei uns selbst nicht ertragen. Wenn man hierher kommt, entwickelt man sich sehr schnell, dreimal schneller als an jedem anderen Ort. Bei uns z\u00e4hlt ein Jahr als drei Jahre an Erfahrung und F\u00e4higkeiten. <\/p>\n
Wir m\u00f6gen oberfl\u00e4chliche Mid-Level-Entwickler \u00fcberhaupt nicht. Aus unserer Sicht ist ein Mid-Level ein Mensch, der bereits viel kann. Um es direkt zu sagen: Der DevOps-Markt ist extrem verw\u00e4ssert. Es gibt Mid-Levels, die sich wie Junioren sehen. Es gibt Junioren, die sich wie Senioren betrachten. Wenn ein Mensch zu uns kommt, versteht er sehr schnell sein tats\u00e4chliches Niveau.<\/p>\n
Das bedeutet nicht, dass wir keine Junioren einstellen \u2014 wir tun es gern und werden sogar noch mehr einstellen. Wir gr\u00fcnden gerade ein spezielles Team, den \u201eDevOps-Beschleuniger\u201c, und vergeben dort Projekte, bei denen wir Risiken eingehen k\u00f6nnen, wo der Kunde bereit ist, dass wir Risiken eingehen. Wahrscheinlich wird es sogar eine spezielle Dienstleistung daf\u00fcr geben. Irgendetwas wie \u201eFlant-Light\u201c.<\/p>\n
\u2014 M\u00f6chten Sie ein gro\u00dfes Unternehmen werden?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Wir m\u00f6chten es, aber mit einer Vorbedingung. Wir wollen unsere Kultur auf keinen Fall verlieren. Wir werden auf jeden Fall wachsen, aber die technische und arbeitliche Kultur zu bewahren, ist sogar wichtiger als die Entwicklung selbst.<\/p>\n
Wir haben nur ein Leben, man kann nicht alles Geld der Welt verdienen, und man m\u00f6chte es mit guten Menschen verbringen. Wir lehnen B\u00fcrokratie und Scheinl\u00f6sungen kategorisch ab. Bei uns gibt es absolut horizontale Verbindungen. Man kann seine Meinung auch in der deutlichsten Form dem Management mitteilen: Der Inhalt ist wichtiger als die Formalit\u00e4ten.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Aber daf\u00fcr braucht man sehr gute Argumente.<\/p>\n
\u2014 (\u0414\u0421)<\/i> Nat\u00fcrlich! Und Homeoffice ist ebenfalls wichtig, denn so leben wir und so sehen wir die Welt. Dima Schurupow lebt in Thailand, ich in Deutschland. Sasha Batalov ist in Moskau, der Personalchef in Tyumen. <\/p>\n
Wir sind der Meinung, dass man, solange man auf diesem Planeten lebt, das Leben so leben sollte, dass man es gesehen hat. In Bedingungen zu leben, in denen einem der Weg zur Arbeit unangenehm ist, ist nicht n\u00f6tig. Deshalb wollen wir, dass man gerne zur Arbeit kommt. Konflikte am Arbeitsplatz sind definitiv unangenehm, also sorgen wir daf\u00fcr, dass es dort keine Konflikte gibt. Wir haben Meinungsverschiedenheiten und Debatten, aber keine Konflikte. <\/p>\n
\u2014 Finden Sie nicht, dass gro\u00df zu werden bedeutet, nicht nur Dienstleistungen anzubieten, sondern auch zu produzieren? Dass man nicht nur das Leben leben und den Planeten sehen, sondern auch etwas hinterlassen sollte?<\/b> <\/p>\n
\u2014 (\u0414\u0421)<\/i> Das ist ein sehr schmerzhaftes Thema f\u00fcr uns, weil wir ein Dienstleistungsunternehmen sind. Aber wir entwickeln viel Software, und im Grunde sind unsere Dienstleistungen von ganz anderer Effizienz. Wir haben niemals Zeit oder Menschen verkauft. Kunden kamen immer und fragten \u2013 \"Kann man hundert Stunden kaufen?\" Nein, das geht nicht, wir verkaufen keine Stunden. <\/p>\n
Wir verkaufen Ergebnisse. Das Ergebnis ist, dass wir das Problem gel\u00f6st haben und den Schmerz beseitigt haben. Und wir l\u00f6sen es nicht so, wie man uns gesagt hat, sondern so, wie wir es wissen. Unser Produkt ist unsere Erfahrung. Und wir werden definitiv fertige L\u00f6sungen, SaaS-Produkte entwickeln, es gibt viele Ideen. Aber es gibt keinen Grund zur Eile. Vor uns liegen viele Jahrzehnte.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412 \u043c\u0438\u0440\u0435, \u0433\u0434\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0441\u0432\u043e\u0439 \u0431\u0438\u0437\u043d\u0435\u0441 \u043c\u043e\u0436\u0435\u0442 \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0442\u0435\u0431\u044f \u043f\u043e-\u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u043c\u0443 \u0431\u043e\u0433\u0430\u0442\u044b\u043c, \u043b\u044e\u0434\u0438 \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u0438\u0434\u0443\u0442 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043f\u043e \u043d\u0430\u0439\u043c\u0443. \u0412\u043e-\u043f\u0435\u0440\u0432\u044b\u0445, \u043d\u0435 \u0432\u0441\u0435 \u0441\u0447\u0430\u0441\u0442\u043b\u0438\u0432\u044b \u0431\u044b\u0442\u044c \u0431\u0438\u0437\u043d\u0435\u0441\u043c\u0435\u043d\u0430\u043c\u0438, \u0430 \u0436\u0438\u0442\u044c \u043d\u0430\u0434\u043e. \u0412\u043e-\u0432\u0442\u043e\u0440\u044b\u0445, \u043d\u0430 \u0440\u0430\u0431\u043e\u0442\u0435 \u0432\u0441\u0435 \u043f\u043e\u043d\u044f\u0442\u043d\u043e \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e \u2014 \u0442\u044b \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0448\u044c \u0441\u0432\u043e\u044e \u0444\u0443\u043d\u043a\u0446\u0438\u044e, \u0430 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u0440\u0438\u0441\u043a\u043e\u0432 \u0431\u0435\u0440\u0443\u0442 \u043d\u0430 \u0441\u0435\u0431\u044f \u0434\u0440\u0443\u0433\u0438\u0435. \u041e\u0442\u0441\u044e\u0434\u0430 \u0440\u0430\u0441\u0442\u0443\u0442 \u0441\u0442\u0430\u0440\u044b\u0435 \u0437\u0430\u043c\u0443\u0441\u043e\u043b\u0435\u043d\u043d\u044b\u0435 \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u044b: \u0432\u043b\u0430\u0434\u0435\u043b\u044c\u0446\u044b \u0445\u043e\u0442\u044f\u0442, \u0447\u0442\u043e\u0431\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-30046","post","type-post","status-publish","format-standard","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"\u201eUntypische](\"\/wp-content\/uploads\/2019\/03\/0ee82b86e0cbe70d8a1aff2db82c47cd.png\")