<\/a><\/noindex><\/p>\nEine Gruppe von Linux-Studierenden<\/h2>\n \nDmitrij Stoljajow (technischer Direktor) w\u00e4hrend seines Vortrags<\/i><\/p>\n
\u2014 (Dima Stoljajow)<\/b> Wir haben uns immer mit Linux und Open Source besch\u00e4ftigt, begannen jedoch mit einem Thema, \u00fcber das wir jetzt etwas besch\u00e4mt sind. Irgendwie dachten wir, dass es notwendig sei, Linux anstelle von Windows in B\u00fcros einzuf\u00fchren. Der erste Name des Unternehmens war TrueOffice \u2014 \u201eechtes B\u00fcro\u201c. Dann haben wir verstanden, dass das niemand braucht. Das war 2006, als ich 19 Jahre alt war. Erst 2012-13 kam das Bewusstsein, wie man ein Gesch\u00e4ft aufbaut und welche Technologien die Welt ben\u00f6tigt.<\/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, Vertrieb und in der Wirtschaft, den uns nie jemand beigebracht hat, au\u00dfer den Kursen an der Universit\u00e4t, aber ich wei\u00df nicht, wie anwendbar und n\u00fctzlich die \u00fcberhaupt sind. <\/p>\n
Zun\u00e4chst dachten wir, all das sei unn\u00f6tig, aber dann mussten wir es praktisch lernen, B\u00fccher lesen, manchmal erst nachdem wir bereits Fehler gemacht hatten. Insgesamt gingen wir einen langen, beschwerlichen Weg und probierten eine Menge falscher Ans\u00e4tze aus. <\/p>\n
\u2014 (DS)<\/i> Doch mit der steigenden Qualifikation spezialisierten wir uns zunehmend auf Linux und besch\u00e4ftigen uns jetzt ausschlie\u00dflich mit Highload, also stark belasteten Web-Projekten. Als Kubernetes aufkam, verstanden wir schnell, dass dies die Grundlage war, die uns so lange gefehlt hatte. <\/p>\n
\u2014 Warum war das Interesse an Linux so gro\u00df? War es ideologisch oder technologisch?<\/b><\/p>\n
\u2014 (DS)<\/i> Das Unternehmen hat zwei Gr\u00fcnder \u2014 Dima Schurupov und mich. Dima Schurupov hatte mehr Interesse an Open Source. Ich hingegen mochte besonders Linux, technologisch, wie alles aufgebaut ist. So entstand eine Kombination: Dima interessiert sich f\u00fcr die Ideologie, w\u00e4hrend ich mich f\u00fcr die Technologie begeistere. Ich liebe Open Source als Idee, aber mir war immer die technologische Seite wichtiger.<\/p>\n
Einstein sagte: \u201eMan sollte es so einfach wie m\u00f6glich machen, aber nicht einfacher\u201c. Linux ist so einfach, zuverl\u00e4ssig und transparent aufgebaut, dass ich es genie\u00dfe. Wir alle mochten es und verwandelten uns von einer Gruppe Studenten in ein gro\u00dfes Unternehmen. Jetzt sind wir bereits 70. F\u00fcr die IT und spezialisierte Dienstleistungen ist das schon recht viel.<\/p>\n
\u2014 Wie war es in den Zeiten der Studentengruppe?<\/b><\/p>\n
\u2014 (DS)<\/i> Nun, wie es bei Studenten so \u00fcblich ist \u2013 fr\u00f6hlich und lebhaft.<\/p>\n
\u2014 (SB)<\/i> Eine riesige Menge an Altruismus, der Wunsch, das Internet zu erobern und technologische H\u00f6hen zu erklimmen. Wir haben uns auf sehr komplizierte Aufgaben eingelassen \u2013 in der Tat haben wir ernsthafte (aber sehr interessante!) Projekte im Bereich Systemintegration \u00fcbernommen, und das zu einem Spottpreis. Wir versuchten, unsere eigenen Frameworks zu entwickeln, saugten alle Technologien auf, die wir erfuhren, und suchten sofort nach Anwendungsbereichen.<\/p>\n
\u2014 Hat es sich kommerziell ausgezahlt?<\/b><\/p>\n
\u2014 (DS)<\/i> Ja, aber in den fr\u00fchen Phasen brauchten wir nicht viel. Damals war ein Einkommen von 40.000 Rubel f\u00fcr mich absolut normal, ich lebte gut davon.<\/p>\n
\u2014 (SB)<\/i> Ich dachte, man k\u00f6nnte f\u00fcr tausend Dollar jede erdenkliche Website erstellen.<\/p>\n
\u2014 (DS)<\/i> Im Jahr 2013 hatten wir nicht genug Geld, um in Moskau problemlos Personal einzustellen. Alle, die wir h\u00e4tten einstellen k\u00f6nnen, hatten wir bereits engagiert. Wir beschlossen, ein B\u00fcro in Nischni Nowgorod zu er\u00f6ffnen. Wir fuhren hin, er\u00f6ffneten und begannen mit der Einstellung. Dann wurde uns klar, dass es schwierig ist, mit zwei B\u00fcros zu leben, und wir entschieden uns, ganz ohne B\u00fcros zu leben.<\/p>\n
Nat\u00fcrlich haben wir eine Menge Fehler gemacht. Erst 2016, zu meinem Bedauern, las ich das Buch \"Remote\". Ich weinte und lachte, denn wir hatten den gleichen Weg eingeschlagen. Jeder Absatz spiegelte meine pers\u00f6nlichen Erfahrungen wider. <\/p>\n
\u2014 (SB)<\/i> In jedem Absatz waren unsere Narben.<\/p>\n\nWas macht Flant<\/h2>\n \n
Um eine qualitativ hochwertige Betriebsf\u00fchrung f\u00fcr die Produktion aufzubauen, ben\u00f6tigt man 15-20 DevOps, Datenbankspezialisten, Kubernetes-Experten, einen Support-Service und so weiter. Und wenn das Unternehmen klein ist, mit nur zwei bis drei Dutzend Entwicklern, 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 wir selbst gerne arbeiten w\u00fcrden, so seltsam das auch klingen mag. Jetzt, wo uns dies gelungen ist, besteht unsere Mission darin, Technologien auf dem Niveau von Google und Facebook kleinen Unternehmen und fr\u00fchen Startups zug\u00e4nglich zu machen.<\/p>\n
Die Menschen k\u00f6nnen sich auf ihr Produkt konzentrieren, anstatt sich mit Problemen auseinanderzusetzen, die vermieden werden k\u00f6nnen.<\/p>\n
Viele Leute, die zu uns kommen, sind \u00fcberrascht, wie viel es gibt, welche Belastungen \u00fcberall vorhanden sind. Wir haben \u00fcber 50 Projekte in der Produktion und mehr als 70 Kubernetes-Cluster. Dabei kann man immer etwas aufbauen. Ich habe einen Entwurfseditor ge\u00f6ffnet, eine mikroservicebasierte Architektur skizziert und eine Liste von 200 Technologien erstellt \u2013 und dann ging es los. Aber das f\u00fchrt immer zu Problemen und Konsequenzen. <\/p>\n
Es geht darum, einerseits maximale Stabilit\u00e4t, Zuverl\u00e4ssigkeit und Einfachheit zu gew\u00e4hrleisten und andererseits ein hohes Ma\u00df an Innovationen zu bieten. Wir sind stolz darauf, dass wir das k\u00f6nnen. Wir tun dies \u00fcberall und in gro\u00dfen Mengen, wie das bedingte Ikea.<\/p><\/blockquote>\n
Wer braucht ausgelagerte DevOps?<\/h2>\n \nIch glaube, gro\u00dfe Unternehmen ziehen es vor, ihre DevOps intern zu halten.<\/b><\/p>\n
\u2014 (SB)<\/i> Es ist klar, dass gro\u00dfe Unternehmen wie Avito oder Badoo sich ein Team von DevOps-Experten leisten k\u00f6nnen. Auch kleinere Firmen mit gro\u00dfen Investitionen k\u00f6nnen das \u2014 sie stellen ein, aber ob sie die Ressourcen haben, um damit umzugehen, ist fraglich.<\/p>\n
Wir sind der Meinung, dass auch gro\u00dfe Unternehmen besser auf Experten zur\u00fcckgreifen sollten, die \u00fcber umfangreiche Erfahrung verf\u00fcgen. Kleine Firmen, deren Gesch\u00e4ft auf Web-L\u00f6sungen basiert, m\u00fcssen sich unbedingt an erfahrene Fachleute wenden. Denn jeder einfache Fehler in einem Schl\u00fcssel-System bedeutet Geldverlust.<\/p>\n
\u2014 (DS)<\/i> Wir wissen, dass die Menschen in Russland der Auslagerung misstrauen \u2014 aus negativen Erfahrungen und anderen Gr\u00fcnden. Doch unsere Kunden bleiben bei uns. In zehn Jahren haben wir nur aus zwei Gr\u00fcnden Kunden verloren: Entweder haben sie uns \u00fcberholt (zum Beispiel wurden sie \u00fcbernommen und alles wurde umstrukturiert) oder sie mussten schlie\u00dfen, weil die Idee nicht funktionierte.<\/p>\n
\u2014 Und wer kommt h\u00e4ufiger zu Ihnen \u2014 kleine Unternehmen oder gro\u00dfe?<\/b><\/p>\n
\u2014 (DS)<\/i> Momentan ist es gleichm\u00e4\u00dfig verteilt. Aber kleine Unternehmen haben einfach Respekt vor uns und denken, dass wir\u2026 <\/p>\n
\u2014 (SB)<\/i>\u2026 gro\u00df, komplex, unerreichbar sind und in den Wolken schweben. <\/p>\n
\u2014 (DS)<\/i> Ja, man geht an einem Autohaus mit Maybach vorbei und geht nicht hinein, fragt nicht nach dem Preis, denn ein Maybach kann niemals 500.000 Rubel kosten. <\/p>\n
Nat\u00fcrlich kann er das nicht.<\/b><\/p>\n
\u2014 (SB)<\/i> Sobald er im Carsharing verf\u00fcgbar ist, kann man es sich leisten, damit zu fahren. <\/p>\n
\u2014 (DS)<\/i> Ja, wir sind nat\u00fcrlich nicht Maybach \u2013 wir sind Ikea. Auch bei uns ist es einfach, zuverl\u00e4ssig und erschwinglich geworden. Insgesamt haben wir die gleiche Anzahl von Anfragen sowohl von Unternehmen der Top 50 als auch von kleinen Firmen. Allerdings konzentrieren wir uns haupts\u00e4chlich auf kleine Unternehmen und arbeiten \u00fcberwiegend mit ihnen zusammen; mit gro\u00dfen Unternehmen versuchen wir, nicht zu kooperieren. <\/p>\n
\u201eWarum?\u201c<\/b><\/p>\n
\u2014 (DS)<\/i> Es gibt viel B\u00fcrokratie.<\/p>\n
\u2014 (SB)<\/i> In gro\u00dfen Unternehmen gibt es viele Ebenen, auf denen die Verantwortung verteilt ist, das Feedback ist sehr lange, und oft beginnen die Leute, sich mit Technologien zu befassen: \u201eLass uns w\u00e4gen, lass uns eine Strategie schreiben, einen Plan f\u00fcr das n\u00e4chste Jahr aufstellen, lass uns besser so machen, das ist sch\u00f6ner f\u00fcr die Enterprise-Kultur, so hat sich unsere Praxis entwickelt\u201c. Und so beginnen sie, Dinge zu komplizieren, die man einfach und direkt l\u00f6sen k\u00f6nnte, sodass 80 % des Ergebnisses schon morgen da sein k\u00f6nnten. Sie w\u00e4hlen den langen Weg, bei dem unklar ist, ob es \u00fcberhaupt funktionieren wird. <\/p>\n
Infolgedessen erfinden wir die R\u00e4der statt bew\u00e4hrte Praktiken neu, und die Kosten f\u00fcr technologische L\u00f6sungen steigen ins Unermessliche. Dabei ist es fraglich, ob die Qualit\u00e4t tats\u00e4chlich besser wird. <\/p>\n
\nBeitrag f\u00fcr Outsourcing<\/h2>\n \n
Alle Mitarbeiter in der Firma bringen auf die eine oder andere Weise Beitr\u00e4ge ein \u2013 sei es durch Feedback, Dokumentation oder Code. Wir betrachten dies als unseren Beitrag f\u00fcr die vielf\u00e4ltige Welt der Open-Source-Tools, die wir nutzen. Und ich denke, dass wir diesen Beitrag w\u00fcrdig leisten.<\/p>\n
Wir nennen es die Verdichtung von Erfahrungen. Anf\u00e4nglich hat eine Person etwas gelernt, es mit Kollegen geteilt, und das Wissen wurde folkloreartig. Sp\u00e4ter haben wir die Dokumentation festgehalten und dann in Tools umgesetzt, sodass wir dar\u00fcber vergessen konnten, weil alles automatisch erfasst wird.<\/p><\/blockquote>\n
Die Popularit\u00e4t von Technologien und die Toxizit\u00e4t von Entwicklern<\/h2>\n \n\u2013 Warum gerade Ubuntu? Welche anderen Optionen wurden vorher in Betracht gezogen?<\/b><\/p>\n
\u2014 (DS)<\/i> Wir waren eine Gruppe von Studenten, die Linux mochten. lange Zeit nutzten wir Gentoo \u2013 eine source-basierte Distribution, die wir jedes Mal von Grund auf neu kompilieren mussten. Als wir einige Hundert Server hatten, dauerte es Monate, um ein Update durchzuf\u00fchren. Nat\u00fcrlich haben wir zun\u00e4chst alles automatisiert und optimiert, aber schlie\u00dflich haben wir erkannt, dass wir etwas \u00e4ndern mussten. Mit dem Wissen \u00fcber die Vor- und Nachteile verschiedener L\u00f6sungen entschieden wir uns einfach f\u00fcr das beliebteste. Damals war es intuitiv \u2013 wenn es das beliebteste ist, wird es sich am besten weiterentwickeln, und all die Nachteile werden 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 Nutzer kamen, versuchten sie, interne Systemprobleme zu l\u00f6sen, w\u00e4hrend in MongoDB diese viel seltener angegangen wurden. Sie konnten hypothetisch gesehen if-Bedingungen verwenden, um in synthetischen Tests besser abzuschneiden. Daher wuchs die Popularit\u00e4t von MongoDB. In den einfachsten Anwendungsf\u00e4llen schnitten sie besser ab, w\u00e4hrend die interne Qualit\u00e4t minderwertig war. Resync DB hingegen hatte eine gute interne Struktur, aber es konnte nicht an Popularit\u00e4t gewinnen.<\/p>\n
Am Ende l\u00e4uft es bei MongoDB gut, aber an Resync DB kann sich niemand erinnern. Das Unternehmen ist pleite. Mit Ubuntu ist es ungef\u00e4hr so \u00e4hnlich. Auf dieser Distribution liegt viel Fokus, weshalb wir uns entschieden haben, sie zu nutzen.<\/p>\n
\u2014 Was halten Sie von den letzten politischen Ver\u00e4nderungen, dem CoC und so weiter?<\/b><\/p>\n
\u2014 (DS)<\/i> Naja\u2026 es gibt keinen negativen Tenor, alles ist okay, alles ist klar. Ich selbst habe das Problem, dass ich manchmal Leute verletze. Manchmal scheint mir etwas offensichtlich zu sein, und ich werde extrem frustriert, wenn die Leute es nicht verstehen. Ich werde w\u00fctend und das f\u00fchrt zu negativem Feedback (aber ich arbeite daran).<\/p>\n
Linus ist wirklich intelligent, schlie\u00dflich arbeitet er schon seit 30 Jahren damit. Es ist klar, dass er ein direkter Typ ist, der keine Scheu hat, seine Meinung zu sagen. H\u00f6flichkeit leidet dabei und die Community arbeitet daran. Er ist sich der Problematik bewusst und erkennt sie an. <\/p>\n
\u2014 Aber, wie ich an den Reaktionen in den Diskussionen verstanden habe, unterst\u00fctzen viele Menschen die Idee, direkt und klar zu sprechen. Und wenn es jemanden st\u00f6rt \u2014 das ist kein Zucker, der wird nicht schmelzen.<\/b><\/p>\n
\u2014 (DS)<\/i> Nein, das ist nicht so. Ich, als jemand, der an mangelnder H\u00f6flichkeit leidet, verstehe, dass das sehr schlecht ist. Es schadet der Community. Es gibt Leute, die ist das egal, aber f\u00fcr die meisten Menschen ist es dennoch wichtig, dass emotionaler Komfort besteht.<\/p>\n
Im Code gibt es einen dummen Fehler. Man k\u00f6nnte sagen: \u201eLeute, es ist bedauerlich, dass wir solche einfachen Dinge \u00fcbersehen, das sollten wir \u00e4ndern.\u201c Oder man k\u00f6nnte sagen: \u201eWelcher Idiot hat das gemacht?!\u201c Die eine Aussage schadet. Der Mensch, der diesen Fehler gemacht hat, k\u00f6nnte sogar kl\u00fcger und erfahrener sein als du, k\u00f6nnte aber einfach nicht in der Stimmung gewesen sein, als der Fehler passierte \u2014 man wei\u00df ja nie, was ihm widerfahren ist. Und f\u00fcr ihn w\u00e4re das eine direkte Beleidigung. Weshalb das Ganze?<\/p>\n
Man sollte die Dinge klar ansprechen, aber man muss nicht sagen: \u201eWelcher Idiot hat das geschrieben.\u201c Verstecken und umschmeicheln macht auch keinen Sinn, aber man sollte die Leute nicht verletzen.<\/p>\n
Warum m\u00fcssen DevOps jeden Tag telefonieren?<\/h2>\n \n(DS)<\/i> Wir haben jetzt ein kleines B\u00fcro, in dem die Dokumente aufbewahrt werden und wo ein B\u00fcro-Manager sitzt, der sich um diese Dokumente k\u00fcmmert.<\/p>\n
In der Firma arbeiten 70 Personen. 20 Personen sind das OPS-Team. 30 Personen teilen sich in drei DevOps-Teams, jeweils etwa 10 Personen. Die restlichen 20 sind Entwickler und im Vertrieb. Es gibt 8 Entwickler, und die R&D-Abteilung hat 4 Personen. Es gibt 5-6 nicht-technische Mitarbeiter in der ganzen Firma.<\/p>\n
Wichtige Entscheidungen treffen die drei DevOps-Teams. Die Prozesse sind \u00fcberall gleich \u2013 jeden Tag ein langes Meeting, eine bis eineinhalb Stunden. Dort werden alle technischen Fragen besprochen, und die Teams entscheiden, wie es weitergeht. Und da alle remote arbeiten, ist es eine Gelegenheit, um richtig zu kommunizieren.<\/p>\n
\u2014 Ist das wirklich jeden Tag notwendig?<\/b><\/p>\n
\u2014 (DS)<\/i> Ja.<\/p>\n
\u2014 Sind sich damit alle einig?<\/b><\/p>\n
\u2014 (DS)<\/i> Ja, alle sind einverstanden, es f\u00fchlt sich f\u00fcr jeden angenehm an. Aber an manchen Tagen kann das Meeting auch nur 30 Minuten dauern. Trotz der sehr intensiven Kommunikation \u00fcber Slack wollen wir uns gut synchronisieren und verstehen, was gestern passiert ist. Wir m\u00f6chten einander verstehen und nicht einfach Aufgaben abarbeiten. Das ist ein kulturell wichtiger Punkt.<\/p>\n
\u2014 (SB)<\/i> Im jeden Moment kann etwas passieren, die Situation kann sich \u00e4ndern. Es bedarf st\u00e4ndiger Anpassung. <\/p>\n
\u2014 (DS)<\/i> Du hast einen guten Witz zu diesem Thema.<\/p>\n
\u2014 (SB)<\/i> Ja. Ein Herzchirurg kommt ins Autohaus, und der Mechaniker sagt ihm: \u201eH\u00f6r zu, wir machen dasselbe, nur dass du das Herz eines Menschen operierst und ich das Herz eines Autos. Du bekommst f\u00fcr die Operation 10.000 $, w\u00e4hrend ich f\u00fcr die Wartung 100 Rubel bekomme.\"<\/p>\n
Der Chirurg fragt: \u201eM\u00f6chtest du auch 10.000 f\u00fcr eine Reparatur verdienen?\u201c Der Mechaniker antwortet \u2014 nat\u00fcrlich. Der Chirurg setzt sich ins Auto, startet es und sagt \u2014 \u201eLegen Sie los.\u201c<\/p>\n
So ist es auch bei uns. In der Entwicklung kannst du eine Aufgabe \u00fcbernehmen und nach zwei Wochen ein Ergebnis liefern. Danach kann alles angepasst werden, denn plus-minus drei Tage machen keinen Unterschied. <\/p>\n
In unserem Fall kann jeder vers\u00e4umte Alert oder falsche Entscheidung zu einem erheblichen Problem f\u00fchren. Um das zu vermeiden, ist eine enge, schnelle und st\u00e4ndige Kommunikation notwendig.<\/p>\n
\nIst es schwer, remote zu arbeiten?<\/h2>\n \nEs ist schwierig, Menschen aus der Ferne zu leiten. Aber es bleibt schwierig, solange du in einem B\u00fcro bist und sie in einem anderen B\u00fcro, und die Sicht verwischt. Du sitzt in Moskau und es scheint dir, dass die Jungs aus Nischni Nowgorod schlecht und ineffizient arbeiten. In Moskau siehst du die Anstrengungen der Menschen um dich herum, die Anstrengungen von Remote-Mitarbeitern jedoch nicht. Du nimmst nur das Ergebnis wahr. <\/p>\n
Im B\u00fcro finden viele Kommunikationsprozesse informell statt \u2014 jemand hat auf dem Weg zur K\u00fcche etwas gesagt. Menschen im anderen B\u00fcro sehen das nicht, f\u00fchlen es nicht, und der Kontext geht verloren.<\/p>\n
Als wir bereits bereit waren, das B\u00fcro aufzugeben, liefen alle Kommunikationen (sogar unter Mitarbeitern im selben Raum) \u00fcber Google Meet. Und als wir die gesamte Kommunikation remote aufbauten, funktionierte das zu 100 %. Alle Missverst\u00e4ndnisse wurden ausger\u00e4umt.<\/p>\n
Alles aufzubauen ist schwierig, aber wenn man es richtig macht, funktioniert es und verursacht keinen Unbehagen.<\/p><\/blockquote>\n
Wie Teams selbst mit ihrem Geld umgehen<\/h2>\n \nHomeoffice ist eine kontroverse Frage. Manchmal haben Unternehmen Angst, die Leute nach Hause zu lassen, weil sie denken, sie w\u00fcrden die Kontrolle \u00fcber sie verlieren. Aber diejenigen, die es tun, sagen auch, dass man ganz anders arbeiten muss.<\/b><\/p>\n
\u2014 (DS)<\/i> Wir haben das Problem gel\u00f6st, indem wir bereit sind, unser Geld mit den Teams zu teilen. Unsere gesamte Wirtschaft und das Anreizsystem sind fast wie eine Franchisestruktur aufgebaut. Die Geh\u00e4lter sind ziemlich hoch, und wir lassen den Leuten zus\u00e4tzliches Geld zur Verf\u00fcgung.<\/p>\n
Das Team betreut einen Pool von Projekten. Sie wissen, wie viel jedes dieser Projekte einbringt. Sie kennen genau ihren Anteil an diesem Geld. Alles, was \u00fcber ihre Geh\u00e4lter hinaus \u00fcbrig bleibt, bleibt im Team und wird nach einem bestimmten System unter ihnen aufgeteilt. Die Motivation ist v\u00f6llig klar: Ein zus\u00e4tzliches Projekt im Wert von 200.000 bringt jedem eine Gehaltserh\u00f6hung von zehn. Ein Fehler muss dem Kunden kompensiert werden.<\/p>\n
\u2014 (SB)<\/i> Wenn du anf\u00e4ngst, deine Teamkollegen h\u00e4ngen zu lassen, merkt man das sofort. Du beraubst dich der M\u00f6glichkeit, zus\u00e4tzliches Einkommen zu erzielen. Unser Kontrollsystem l\u00f6st dieses Problem vollst\u00e4ndig. Jeder plant seinen Tag selbst, und die t\u00e4glichen Meetings reichen aus, um zu verstehen, wer was macht.<\/p>\n
\u2014 (DS)<\/i> In Kriegszeiten l\u00fcgt man seinen Kameraden im Graben nicht an. <\/p>\n
\u2014 Das hei\u00dft, bei euch sind die Geh\u00e4lter \u00f6ffentlich? Jeder wei\u00df, wer wie viel verdient? <\/b><\/p>\n
\u2014 (DS)<\/i> Wir haben die Geh\u00e4lter vor einiger Zeit geschlossen. Es gibt regionale Unterschiede. Obwohl wir bestrebt sind, in den Regionen das volle Moskauer Gehalt zu zahlen, gibt es immer noch gewisse Diskrepanzen.<\/p>\n
\u2014 (SB)<\/i> Jetzt wei\u00df jeder, wie viel Geld das Team insgesamt hat. Sie sehen, welchen Anteil an den Pr\u00e4mien sie erhalten. <\/p>\n
\u2014 (DS)<\/i> Der Teamleiter jeder Gruppe entscheidet, wie viel seine Mitglieder verdienen und wie die Boni verteilt werden. Wir gehen in diese Frage nur beratend ein, die Entscheidung liegt immer beim Teamleiter.<\/p>\nWarum haben Menschen Angst vor Stellenangeboten?<\/h2>\n
\nFeier zum 10-j\u00e4hrigen Jubil\u00e4um des Unternehmens im Jahr 2018<\/i><\/p>\n
\u2014 Reichen Ihnen 70 Personen?<\/b><\/p>\n
\u2014 (DS)<\/i> Nein. Wir planen, im Laufe des Jahres mindestens 20 DevOps-Ingenieure einzustellen. Aber das ist sehr schwierig. Wir haben einen ausreichend gro\u00dfen Pool an Kandidaten, alle haben irgendwie von uns geh\u00f6rt. Aber hier ist es \u00e4hnlich wie bei den Kunden. Viele sagen: 'Wir haben Angst, bei euch zu arbeiten, was ist, wenn wir es nicht schaffen.' Doch wir sehen nicht, dass bei uns super anspruchsvolle Aufgaben warten.<\/p>\n
Korrespondenz mit einem Kandidaten<\/i><\/p>\n
\u2014 Wie sollte man sein, um das Niveau zu erreichen?<\/b><\/p>\n
\u2014 (DS)<\/i> Theoretisch sollte eine Person gleichm\u00e4\u00dfig in der Entwicklung und im Betrieb ausgebildet sein. In der Praxis gibt es solche Menschen weltweit nur sehr wenige, ganz zu schweigen von Russland. Besonders die, die in beiden Bereichen Senior sind. Ich w\u00fcrde mich nicht einmal dazu z\u00e4hlen.<\/p>\n
In unseren Stellenangeboten steht immer klar, was man wissen muss. Wir arbeiten viel daran und bem\u00fchen uns, konkret zu sein.<\/p>\n
\u2014 K\u00f6nnte es sein, dass Stellenangebote wirklich abschreckend sind, wenn so detailliert aufgef\u00fchrt ist, was alles Wissen erfordert?<\/b><\/p>\n
\u2014 (DS)<\/i> Nein, nein, nein, wir glauben nicht, dass man viel wissen muss. <\/p>\n
\u2014 (SB)<\/i> Uns interessiert nicht das Wissen, sondern das Denken, die F\u00e4higkeit des Menschen, L\u00f6sungen zu finden.<\/p>\n
\u2014 (DS)<\/i> Wir interessieren uns f\u00fcr Erfahrung mit Linux, und wir pr\u00fcfen dies mit relativ einfachen Aufgaben \u2013 einfach in gro\u00dfer Anzahl. Unser Test ist ziemlich lang und dauert im Durchschnitt 8 Stunden f\u00fcr einen Kandidaten. Am Ende schauen wir, wie die Person mit Problemen umgegangen ist, wie sie googelt und welches Wissen sie hat.<\/p>\n
Das Wissen kann man bei uns sehr schnell aufbauen, denn es gibt viele verschiedene Projekte und erfahrene Kollegen, die immer helfen. Deshalb achten wir haupts\u00e4chlich darauf, dass die Leute schnell denken und Erfahrung haben.<\/p>\n
\u2014 Neben dem Test, erkennt ihr das auch anders?<\/b><\/p>\n
\u2014 (DS)<\/i> Wir haben drei Phasen. Zuerst spricht ein HR-Manager und bittet um einen Erfahrungsbericht. Dann machen die, die dem HR-Manager gefallen haben, eine Testaufgabe. Am Ende kommunizieren die Teamleiter und teilen dem HR-Manager ihre Meinungen mit. Wenn sie sich einig sind, dass es positiv ist, ist das ein Grund, um der Person ein Angebot zu machen.<\/p>\n500.000 Rubel f\u00fcr die Einstellung eines zuk\u00fcnftigen Superhelden<\/h2>\n
\n\u2014 (DS)<\/i> Wir haben eine sehr untypische Haltung zu Finanzen, wir teilen mit den Teams und sind nicht geizig. Au\u00dferdem stellen wir dem Team 500.000 Rubel f\u00fcr die Erweiterung des Personals zur Verf\u00fcgung. Das ist ein Zuschuss, damit sie eine Person finden und sie alles beibringen k\u00f6nnen, w\u00e4hrend sie sich einarbeiten.<\/p>\n
\u2014 500.000 pro Person?!<\/b><\/p>\n
Damit das Team viel Geld verdient, m\u00fcssen sie mehr Projekte annehmen. Daf\u00fcr brauchen sie mehr Leute. Um mehr Leute anzuheuern, braucht man mehr Geld. Das ist ein Teufelskreis. Um diesen Kreis zu durchbrechen, geben wir Geld f\u00fcr neue Mitarbeiter. W\u00e4hrend sie sich einarbeiten, k\u00f6nnen sie weitere Projekte annehmen und bereits aus diesen Einnahmen ihm sein Gehalt zahlen. Das ist also eine Kompensation, bis der Neue Geld einbringt. <\/p>\n
\u2014 Ist das nicht zu viel f\u00fcr DevOps? Sie sind jeden Tag ausgelastet, in einem t\u00e4glichen Einsatz, und m\u00fcssen sich auch noch um Finanzmanagement k\u00fcmmern.<\/b><\/p>\n
\u2014 (DS)<\/i> Das \u00fcbernimmt der Teamleiter, der nicht mehr genau ein DevOps ist. Teamleiter streben eher eine Partnerschaft an, um Optionen zu haben. Daher halten wir das f\u00fcr normal. Die Junior-Mitarbeiter im Team sind davon nicht betroffen.<\/p>\n
Im Grunde wissen sie: Wenn ein Kollege ausf\u00e4llt, bekommen sie im n\u00e4chsten Monat dessen 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 den Teamleitern 500.000 geben, wollen sie oft keine Person einstellen, die nicht \u00fcberzeugt. Manchmal ist es ihnen einfacher, 20 Kandidaten auszuschlie\u00dfen und einen auszuw\u00e4hlen. Es kam vor, dass der Personalverantwortliche mit 100 Personen sprach, 30 zum technischen Test kamen, 20 bestanden und der Teamleiter alle au\u00dfer einem ausschloss. Das ist hart. Die Teamleiter haben gro\u00dfe Angst, Risiken einzugehen. Wir haben das Thema besprochen und alle schienen zu verstehen, dass das ein Fehler ist. Viele Menschen pr\u00e4sentieren sich im Vorstellungsgespr\u00e4ch nicht so, wie sie sp\u00e4ter arbeiten werden. Daher sollten wir Chancen geben und Risiken eingehen.<\/p>\n
\u2014 Missbrauchen die Teamleiter das nicht? Du erh\u00e4ltst 500.000, stellst sehr lange nichts ein und bekommst noch einmal 500.000.<\/b> <\/p>\n
\u2014 (DS)<\/i> Sie erhalten einmal Geld. Wir sagen: \u201eSie haben jetzt zehn Personen, aber es m\u00fcssen 11 sein. Es gibt einen Verkaufsplan, es werden weitere Projekte kommen, und Sie m\u00fcssen bereit sein. Hier sind 500.000 f\u00fcr die elfte Position.\u201c Beim zweiten Mal bekommen Sie es nicht mehr. Und wenn jemand geht, ist das ein Problem des Teams, das sie innerhalb ihres Budgets l\u00f6sen m\u00fcssen. <\/p>\n
Es ist wie ein Spiel Monopoly.<\/p>\n
\u2014 (SB)<\/i> Wir sind der Meinung, dass der Teamleiter in die Finanzen eingebunden sein sollte. Unsere Mitarbeiter erhalten ihr Gehalt aus dem Geld, das sie verdienen. Und das Ma\u00df der Projektkosten ist sehr wichtig. Ein Kunde kommt mit einer gewissen Infrastruktur, und nach einem Jahr ist seine Infrastruktur zehnmal gr\u00f6\u00dfer. Wenn der Teamleiter nicht in die Finanzen involviert ist, kann er die Kosten f\u00fcr den Service nicht angemessen einsch\u00e4tzen.<\/p>\n
\u2014 (DS)<\/i> Es kommt vor, dass das Team monatelang mit den Problemen des Kunden k\u00e4mpft und erkennt, dass sie daf\u00fcr hypothetisch hunderttausend bekommen, was \u00fcberhaupt nicht dem entspricht, was mittlerweile 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 sind sie alle remote. Und wir sehen das als eine gro\u00dfe Errungenschaft an. Wir haben wirklich autonome, motivierte Teams.<\/p>\n
\u2014 Ja. Das klingt so, als m\u00fcsste man ein Superheld sein, um hier arbeiten zu k\u00f6nnen. Sowohl technische F\u00e4higkeiten als auch Selbstdisziplin und finanzielle Kenntnisse sind erforderlich.<\/b><\/p>\n
\u2014 (SB)<\/i> Bei uns kann man zum Superhelden werden. Doch selbst die Teamleiter, die das k\u00f6nnen, haben als ganz normale Ingenieure angefangen. Ein bis zwei Jahre braucht man, um sich in einen solchen Superhelden zu verwandeln.<\/p>\n
\u2014 Teamleiter-Partner sind aus gew\u00f6hnlichen Ingenieuren hervorgegangen. K\u00f6nnen sie direkt f\u00fcr eine solche Position eingestellt werden?<\/b><\/p>\n
\u2014 (DS)<\/i> So etwas hatten wir bisher noch nicht, alle sind aus der Ingenieurswelt gewachsen. Wir ziehen jedoch in Betracht, uns mit einem kleinen Unternehmen zusammenzuschlie\u00dfen, das einfach nur ein weiteres Team von uns werden k\u00f6nnte. Das w\u00fcrden wir gerne ausprobieren.<\/p>\n
\u2014 K\u00f6nnen Sie jemandem eine Chance geben, wenn er ein guter Ingenieur ist, aber nicht genug organisiert f\u00fcr das Level dieser Teams?<\/b><\/p>\n
\u2014 (DS)<\/i> Wir haben keine Angst vor unorganisierten Menschen, schlie\u00dflich gibt es bei uns einen st\u00e4ndigen Aufgabenfluss. Sehr schnell zeigt sich, ob man jemandem helfen kann, sich zu organisieren. Wenn er jeden Tag berichtet, was er gemacht hat, ohne tats\u00e4chlich etwas zu erreichen, wird ihm das peinlich sein. <\/p>\n
Wenn du siehst, dass alle im gleichen Boot sitzen und rudern, f\u00fchlt es sich unbehaglich an, das Ruder wegzugeben. Unter solchen Bedingungen werden selbst Menschen, die im Leben unorganisiert sind, organisiert. Wenn nicht, dann eben nicht.<\/p>\n
Wir k\u00f6nnen Oberfl\u00e4chlichkeit - sei es bei Menschen, in Gesch\u00e4ften oder in uns selbst - \u00fcberhaupt nicht ausstehen. Wenn Menschen hierher kommen, entwickeln sie sich sehr schnell, etwa dreimal schneller als an jedem anderen Ort. Bei uns macht man tats\u00e4chlich in einem Jahr drei Jahre an Erfahrung und F\u00e4higkeiten. <\/p>\n
Oberfl\u00e4chliche Mid-Level-Entwickler m\u00f6gen wir gar nicht. Aus unserer Sicht ist ein Mid-Level jemand, der schon viel kann. Um es klar zu sagen \u2013 der DevOps-Markt ist extrem fragmentiert. Es gibt Mid-Levels, die sich wie Juniors f\u00fchlen. Und es gibt Juniors, die sich f\u00fcr Seniors halten. Wenn jemand zu uns kommt, erkennt er sehr schnell sein tats\u00e4chliches Niveau.<\/p>\n
Das bedeutet nicht, dass wir keine Juniors einstellen \u2013 ganz im Gegenteil, wir nehmen sie gerne und werden noch mehr einstellen. Wir erstellen bereits ein spezielles Team namens \u201eDevOps-Akzelerator\u201c und weisen dort Projekte zu, bei denen man Risiken eingehen kann, wo der Kunde bereit ist, dass wir Risiken eingehen. Wahrscheinlich wird es sogar einen speziellen Service daf\u00fcr geben. Etwas wie \u201eFlant-Light\u201c.<\/p>\n
\u2014 M\u00f6chten Sie eine gro\u00dfe Corporation werden?<\/b><\/p>\n
\u2014 (DS)<\/i> Wir w\u00fcrden gerne, aber mit einer Einschr\u00e4nkung. Wir m\u00f6chten unsere Kultur nicht verlieren. Wir werden sicherlich wachsen, aber die Erhaltung unserer technischen und Arbeitsethik ist wichtiger als das Wachstum selbst.<\/p>\n
Das Leben haben wir nur einmal, all das Geld l\u00e4sst sich sowieso nicht verdienen, und wir m\u00f6chten es in der N\u00e4he guter Menschen verbringen. B\u00fcrokratie und die Simulation von n\u00fctzlicher Arbeit sind f\u00fcr uns absolut inakzeptabel. Unsere Strukturen sind vollkommen horizontal. Man kann seine Meinung selbst in sch\u00e4rfster Form dem Management mitteilen: Der Inhalt ist wichtiger als Formalit\u00e4ten.<\/p>\n
\u2014 (SB)<\/i> Daf\u00fcr braucht man allerdings sehr gute Argumente.<\/p>\n
\u2014 (DS)<\/i> Unbedingt! Auch in der Fernarbeit sehen wir eine Notwendigkeit, da wir so leben und die Welt wahrnehmen. Dima Schurupov lebt in Thailand, ich in Deutschland. Sascha Bat\u0430\u043b\u043e\u0432 ist in Moskau, der HR-Direktor ist in Tjumen. <\/p>\n
Wir sind der Ansicht, dass man in diesem Leben die Welt sehen m\u00f6chte. Unter Bedingungen zu leben, unter denen man nicht gerne zur Arbeit geht, ist nicht notwendig. Daher m\u00f6chten wir, dass man gerne zur Arbeit kommt. Konflikte am Arbeitsplatz sind definitiv unerfreulich, weshalb wir daf\u00fcr sorgen, dass es keine Konflikte gibt. Es gibt Debatten und Auseinandersetzungen, aber keine Konflikte. <\/p>\n
\u2014 Denken Sie nicht, dass es beim Wachstum nicht nur um Dienstleistungen geht, sondern auch um Produktion? Es geht darum, nicht nur ein Leben zu f\u00fchren und den Planeten zu sehen, sondern auch etwas zu hinterlassen?<\/b> <\/p>\n
\u2014 (DS)<\/i> Das ist ein sehr schmerzhaftes Thema f\u00fcr uns, da wir ein Dienstleistungsunternehmen sind. Aber wir entwickeln eine Menge Software, und letztlich sind unsere Produkte Dienstleistungen mit einer ganz anderen Effizienz. Wir haben nie Zeit oder Menschen verkauft. Die Kunden kamen immer und fragten: \u201aKann man hundert Stunden kaufen?\u2018 Nein, das geht nicht, wir verkaufen keine Zeit. <\/p>\n
Wir verkaufen Ergebnisse. Das Ergebnis besteht darin, dass wir Schmerzen lindern und Probleme l\u00f6sen. Und wir tun das nicht so, wie es uns gesagt wurde, sondern so, wie wir es wissen. Unser Produkt ist unsere Erfahrung. Wir werden definitiv fertige L\u00f6sungen und 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
![\"\u201eUnkonventioneller](\"\/wp-content\/uploads\/2019\/03\/0ee82b86e0cbe70d8a1aff2db82c47cd.png\")