W świecie, w którym tylko własny biznes może uczynić cię naprawdę bogatym, ludzie nadal wybierają pracę na etacie. Po pierwsze, nie każdy chce być przedsiębiorcą, a z czegoś trzeba żyć. Po drugie, na etacie wszystko jest jasne i bezpieczne — wykonujesz swoje obowiązki, a większość ryzyk biorą na siebie inni. Stąd biorą się stare, oklepane konflikty: właściciele chcą, by pracownicy byli zmotywowani tak, jakby firma była ich własna; pracownicy chcą robić to, za co im płacą, i nic ponadto.
Te klasyczne relacje mają swoje odmiany — opcje, udziały, premie — które trochę przypominają, że właściciele i pracownicy płyną w jednej łodzi. Zdarzają się jednak również bardziej nietypowe sytuacje.
Firma Flant składa się z kilku zespołów DevOps, które kompleksowo obsługują cudze środowiska produkcyjne. Wyrośli z grupy entuzjastycznych studentów i fanów Linuxa, a dziś zbudowali strukturę „biznesów w biznesie”, po prostu dlatego, że tak jest wygodniej i uczciwiej. Dima Stoliarow i Sasza Batałow opowiedzieli nam, jak to działa.
Flant trafił do grona najlepszych pracodawców IT 2018 według 4.68. Sądząc po ocenach firmy na „Moim Kręgu”, pracownicy wierzą, że firma czyni świat lepszym, a ponadto cenią Flant za ciekawe zadania, dobre relacje w zespole, nowoczesne technologie i kontakt z kadrą zarządzającą.
Grupa studentów zakochanych w Linuksie
Dmitrij Stoliarow (dyrektor techniczny) podczas swojego wystąpienia
— (Dima Stoliarow) Zawsze zajmowaliśmy się Linuksem i open source, ale zaczynaliśmy od bardzo zabawnego pomysłu, którego dziś trochę się wstydzimy. Z jakiegoś powodu wydawało nam się, że trzeba wdrażać Linuxa w biurach zamiast Windowsa. Pierwsza nazwa firmy brzmiała TrueOffice — „prawdziwe biuro”. Później zrozumieliśmy, że nikomu nie jest to potrzebne. Był rok 2006, miałem wtedy 19 lat. Dopiero około 2012–2013 roku przyszło zrozumienie, jak prowadzić biznes i jakie technologie są światu naprawdę potrzebne.
Aleksandr Batałow (dyrektor generalny) przy stoisku firmy na konferencji
— (Sasza Batałow) Poza technologiami istnieje ogromny obszar związany z marketingiem, sprzedażą i ekonomią, którego nikt nas nigdy nie uczył poza zajęciami na uczelni, ale nie wiem, na ile w ogóle są one praktyczne i użyteczne.
Na początku wydawało nam się, że to wszystko nie jest potrzebne, ale potem trzeba było uczyć się tego w praktyce, czytać książki, czasem dopiero wtedy, gdy już zdążyliśmy popełnić błędy. Krótko mówiąc, szliśmy długą i wyboistą drogą, testując mnóstwo niewłaściwych rozwiązań.
— (DS) Ale stopniowo, wraz ze wzrostem kwalifikacji, wszyscy specjalizowaliśmy się już w Linuxie, a dziś zajmujemy się wyłącznie highloadem, czyli wysoko obciążonymi projektami webowymi. Gdy pojawił się Kubernetes, szybko zrozumieliśmy, że to właśnie ten fundament, którego tak bardzo brakowało.
— Skąd takie zainteresowanie Linuxem? Z powodów ideologicznych czy technologicznych?
— (DS) Firma ma dwóch założycieli — Dimę Shurupova i mnie. Dima Shurupov bardziej interesował się open source. Mnie z kolei pociągał sam Linux, od strony technologicznej, to, jak wszystko jest w nim zbudowane. Wyszło więc takie połączenie: Dima lubi ideę, a ja technologię. Lubię open source jako koncepcję, ale dla mnie zawsze ważniejsza była strona technologiczna.
Einstein mówił: „Wszystko należy upraszczać tak bardzo, jak to możliwe, ale nie bardziej”. Linux jest właśnie zbudowany tak prosto, niezawodnie i przejrzyście, że korzystanie z niego daje mi prawdziwą satysfakcję. Wszyscy to lubiliśmy i z grupy studentów stopniowo stawaliśmy się dużą firmą. Teraz jest nas już 70. Jak na IT i usługi specjalistyczne to całkiem dużo.
— Jak wyglądały czasy, gdy byliście jeszcze grupą studentów?
— (DS) Jak to zwykle bywa u studentów — było wesoło i z energią.
— (SB) Było w nas mnóstwo altruizmu, chęć podbicia internetu i zdobywania technologicznych szczytów. Wchodziliśmy w bardzo trudne zadania — zdarzało się, że podejmowaliśmy się poważnych (ale bardzo ciekawych!) projektów z zakresu integracji systemów, realizując je za grosze. Próbowaliśmy tworzyć własne frameworki, chłonęliśmy wszystkie technologie, o których się dowiadywaliśmy, i od razu szukaliśmy dla nich zastosowania.
— A od strony komercyjnej wszystko się spinało?
— (DS) Tak, ale na wczesnym etapie niczego więcej nam nie było trzeba. W tamtych czasach 40 tysięcy rubli było dla mnie całkowicie normalnym dochodem, żyłem za to naprawdę wygodnie.
— (SB) A ja myślałem, że za tysiąc dolarów można zrobić dowolną stronę, jaką tylko da się wymyślić.
— (DS) W 2013 roku nie mieliśmy pieniędzy, żeby swobodnie zatrudniać w Moskwie. Wszystkich znajomych, których mogliśmy zatrudnić, już zatrudniliśmy. Postanowiliśmy otworzyć biuro w Niżnym Nowogrodzie. Pojechaliśmy tam, otworzyliśmy je i zaczęliśmy rekrutację. Potem zrozumieliśmy, że funkcjonowanie z dwoma biurami jest trudne, i postanowiliśmy działać już całkowicie bez biur.
Oczywiście, zaliczyliśmy mnóstwo bolesnych lekcji. Dopiero w 2016 roku, ku własnemu wstydowi, przeczytałem „Remote”. Płakałem ze śmiechu i wzruszenia, bo przeszliśmy dokładnie tę samą drogę. Każdy akapit pokrywał się z moim osobistym doświadczeniem.
— (SB) W każdym akapicie były nasze blizny.
Czym zajmuje się Flant
Kompleksowo obsługujemy wysoko obciążone środowiska produkcyjne. Różni się to od zwykłego outsourcingu, bo z klientami współpracujemy bardzo długo i bardzo blisko — powierzają nam jeden z najważniejszych obszarów swojego biznesu. Od tego, jak pracujemy, w dużej mierze zależy ich działalność.Aby zbudować u siebie wysokiej jakości utrzymanie produkcji, potrzeba 15–20 DevOpsów, specjalistów od baz danych, Kubernetes, zespołu wsparcia i tak dalej. Jeśli firma jest niewielka i ma tylko kilkunastu czy kilkudziesięciu programistów, to jest to po prostu niemożliwe. Wtedy wchodzimy my i ratujemy sytuację. Za jakieś 150 tysięcy.
Kiedyś naszą misją było zbudowanie firmy, w której sami chcielibyśmy pracować, choć brzmi to może naiwnie. Teraz, gdy to się udało, naszą misją jest udostępnianie technologii na poziomie Google i Facebooka małym firmom oraz startupom na wczesnym etapie rozwoju.
Dzięki temu ludzie mogą skupić się na swoim produkcie, zamiast pokonywać problemy, których wcale nie muszą pokonywać.
Wielu ludzi, którzy do nas trafiają, jest zaskoczonych tym, jak wiele różnych rzeczy się u nas dzieje i jak duże są wszędzie obciążenia. Mamy ponad 50 projektów na produkcji i ponad 70 klastrów Kubernetes. Oczywiście zawsze można to niepotrzebnie skomplikować. Otworzyć narzędzie do diagramów, narysować architekturę mikroserwisową, rozpisać listę 200 technologii — i ruszamy. Tyle że to zawsze prowadzi do problemów i konsekwencji.
Sztuka polega na tym, by z jednej strony zapewniać maksymalną stabilność, niezawodność i prostotę, a z drugiej utrzymywać wysoki poziom innowacyjności. I właśnie z tego jesteśmy dumni — potrafimy to robić. Robimy to wszędzie i na dużą skalę, trochę jak IKEA.
Komu potrzebni są DevOpsi na outsourcingu
— Wydaje mi się, że duże firmy wolą zatrudniać DevOpsów na etacie.
— (SB) To jasne, że duzi gracze, tacy jak Avito czy Badoo, mogą zbudować własny zespół DevOpsów. Mniejsze firmy z ogromnym finansowaniem też mogą — ale samo zatrudnienie ludzi nie oznacza jeszcze, że starczy im sił, by to wszystko udźwignąć.
Uważamy, że nawet duże firmy powinny korzystać z pomocy ekspertów, którzy naprawdę znają się na rzeczy. Małe firmy, których biznes opiera się na rozwiązaniach webowych, wręcz muszą współpracować z doświadczonymi specjalistami. Bo każdy przestój w kluczowym systemie to po prostu strata pieniędzy.
— (DS) Wiemy, że w Rosji ludzie obawiają się outsourcingu — z powodu negatywnych doświadczeń i z różnych innych przyczyn. Ale od nas klienci nie odchodzą. Przez dziesięć lat zdarzały się tylko dwa powody odejścia. Albo nas przerastali (na przykład firma została przejęta i wszystko zorganizowano od nowa), albo zamykali działalność, bo pomysł się nie sprawdził.
— Kto częściej do was trafia — małe firmy czy duże?
— (DS) Obecnie po równo. Ale małe firmy po prostu trochę się nas obawiają, myślą, że jesteśmy…
— (SB)… duzi, skomplikowani, nieosiągalni i bujamy w obłokach.
— (DS) No właśnie, mijasz salon z Maybachem i nie wchodzisz do środka, nie pytasz o cenę, bo przecież Maybach nie może kosztować 500 tysięcy rubli.
— Oczywiście, że nie może.
— (SB) Ale kiedy pojawia się w carsharingu, możesz sobie pozwolić, żeby się nim przejechać.
— (DS) Tak, tylko że my oczywiście nie jesteśmy Maybachem — jesteśmy jak IKEA. U nas też udało się połączyć prostotę, niezawodność i dostępność. Ogólnie liczba firm z TOP-50 i małych przedsiębiorstw, które się do nas zgłaszają, jest mniej więcej taka sama. Ale stawiamy przede wszystkim na mały biznes i głównie z nim pracujemy, a ze współpracy z dużymi firmami raczej rezygnujemy.
— Dlaczego?
— (DS) Za dużo biurokracji.
— (SB) W dużej firmie odpowiedzialność jest rozłożona na wiele poziomów, na feedback czeka się bardzo długo, a do tego często ludzie zaczynają bawić się technologią: „A może to przeanalizujmy, napiszmy strategię, plan na rok do przodu, może lepiej zrobić to tak, bo będzie bardziej odpowiednie dla kultury enterprise, bo taką mamy praktykę”. I wtedy zaczynają komplikować rzeczy, które można rozwiązać prostą, krótką drogą, tak że 80% efektu da się osiągnąć już jutro. Zamiast tego wybierają długą ścieżkę, przy której nie wiadomo nawet, czy w ogóle zadziała.
W efekcie zamiast korzystać ze sprawdzonych praktyk, na nowo wynajdujemy koło, a koszt rozwiązania technologicznego rośnie niewspółmiernie. Przy tym wcale nie ma pewności, że jakość będzie lepsza.
Cena outsourcingu
Mamy na GitHubie mnóstwo projektów i od dawna aktywnie dokładamy się do open source. Nie tylko do własnych, ale też do cudzych. Staramy się udostępniać narzędzia, z których sami korzystamy na co dzień. Uważamy, że to nasz obowiązek, a przy okazji sprawia nam to dużą satysfakcję.W firmie praktycznie każdy w jakiś sposób dokłada się do open source — poprzez opinie, dokumentację albo kod. Traktujemy to jako formę rewanżu za całe bogactwo narzędzi open source, z których korzystamy. I moim zdaniem wywiązujemy się z tego uczciwie.
Nazywamy to kondensacją doświadczenia. Na początku jedna osoba czegoś się nauczyła, podzieliła się tym z zespołem i wiedza zaczęła funkcjonować jak firmowy folklor. Potem spisaliśmy to w dokumentacji, a następnie przenieśliśmy do narzędzi i przestaliśmy o tym myśleć, bo wszystko jest już uwzględniane automatycznie.
Popularność technologii i toksyczność deweloperów
— Dlaczego akurat Ubuntu? Co jeszcze braliście pod uwagę, zanim padł wybór na ten system?
— (DS) Byliśmy wtedy po prostu grupą studentów, którym podobał się Linux. Przez długi czas używaliśmy Gentoo — to dystrybucja source-based, którą za każdym razem trzeba kompilować od zera. Gdy mieliśmy już kilkaset serwerów, aktualizacja zajmowała miesiące. Oczywiście najpierw wszystko zautomatyzowaliśmy i zoptymalizowaliśmy, ale ostatecznie doszliśmy do wniosku, że trzeba coś zmienić. Znając plusy i minusy różnych rozwiązań, wybraliśmy po prostu to najpopularniejsze. Wtedy kierowaliśmy się intuicją: skoro coś jest najpopularniejsze, to będzie rozwijane najlepiej, a wszystkie wady prędzej czy później zostaną naprawione.
Była kiedyś taka baza danych jak Resync DB. Konkurowała z MongoDB i startowała mniej więcej w tym samym czasie. Przez długi okres Resync była technologicznie lepsza.
Kiedy przychodzili użytkownicy, skupiali się na rozwiązywaniu wewnętrznych problemów systemowych, podczas gdy w MongoDB takich rzeczy rozwiązywano znacznie mniej, za to można było na przykład dodać kilka ifów, żeby lepiej wypadać w testach syntetycznych. Dlatego popularność MongoDB rosła. W najprostszych zastosowaniach wypadała lepiej, ale wewnętrznie była słaba. Z kolei Resync DB miała dobre wnętrze technologiczne, ale nie zyskiwała popularności.
Ostatecznie MongoDB dopracowało wszystko od środka, a o Resync DB nikt już nie pamięta. Firma zbankrutowała. Z Ubuntu było mniej więcej podobnie. Wokół tej dystrybucji skupiało się dużo uwagi, dlatego zdecydowaliśmy się właśnie na nią.
— Jak oceniacie ostatnie zmiany polityczne, CoC i tym podobne?
— (DS) Cóż… nie ma żadnego negatywu, wszystko jest w porządku, wszystko jest zrozumiałe. Sam mam ten problem, że czasem urażam ludzi. Na przykład coś wydaje mi się oczywiste i zaczyna mnie strasznie irytować, że inni tego nie rozumieją. Złoszczę się i wychodzi z tego sama negatywna energia (ale pracuję nad tym).
Linus jest bardzo inteligentny, w końcu pracuje z tym od 30 lat. Jasne, że to bezpośredni gość, który mówi, co myśli. Z kulturą wypowiedzi bywa u niego różnie, a społeczność nad tym pracuje. On sam wszystko rozumie i to przyznaje.
— Ale z tego, co zrozumiałem po reakcjach w dyskusjach, wiele osób popiera pomysł, żeby mówić wprost i ostro, a jeśli komuś się to nie podoba — nie jest z cukru, nie rozpuści się.
— (DS) Nie, to nie tak. Ja, jako osoba, której też brakuje czasem uprzejmości, rozumiem, że to bardzo źle. To psuje społeczność. Są ludzie, którym to obojętne, ale dla większości jednak ważny jest komfort emocjonalny.
Oto w kodzie jest głupi błąd. Można napisać: „Ludzie, niedobrze, że przepuszczamy tak proste rzeczy, trzeba to poprawić”. A można napisać: „Jaki idiota to zrobił?!”. Jedno zdanie. Osoba, która popełniła ten błąd, może być nawet mądrzejsza i bardziej doświadczona od ciebie, ale po prostu miała gorszy dzień, kiedy się pomyliła — różne rzeczy mogły się wydarzyć. Dla niej będzie to po prostu bezpośrednia zniewaga. Po co to komu?
Trzeba mówić wprost, ale nie trzeba mówić: „Jaki idiota to napisał”. Nie ma też sensu niczego ukrywać ani owijać w bawełnę, ale nie trzeba również obrażać ludzi.
Po co DevOpsom codzienne spotkania
— (DS) Obecnie mamy jedno małe biuro, w którym przechowywane są dokumenty i pracuje office manager, zajmujący się tymi dokumentami.
W firmie pracuje 70 osób. 20 osób to zespół OPS. 30 osób to trzy zespoły DevOps, po około 10 osób każdy. Pozostałe 20 to programiści i dział sprzedaży. 8 programistów, dział rnd — 4 osoby. W całej firmie jest tylko 5–6 osób nietechnicznych.
Główne pieniądze zarabiają trzy zespoły DevOps. Procesy wszędzie są takie same — codziennie odbywa się długie spotkanie, trwające od godziny do półtorej. Omawiane są tam wszystkie kwestie techniczne, a zespół decyduje, co robić dalej. A ponieważ wszyscy pracują zdalnie, jest to też okazja, żeby normalnie porozmawiać.
— Czy to naprawdę jest potrzebne codziennie?
— (DS) Tak.
— Wszyscy się z tym zgadzają?
— (DS) Tak, wszyscy się zgadzają, wszystkim to odpowiada. Ale bywają dni, kiedy taki meeting trwa nawet 30 minut. Mimo bardzo intensywnej komunikacji na Slacku i tak chcemy dobrze się zsynchronizować, zrozumieć, co wydarzyło się wczoraj. Chcemy się nawzajem rozumieć, a nie tylko odhaczać zadania. To ważny element kultury pracy.
— (SB) W każdej chwili coś może się wydarzyć, sytuacja może się zmienić. Potrzebna jest ciągła korekta.
— (DS) Masz dobry dowcip na ten temat.
— (SB) Tak. Kardiochirurg przyjeżdża do warsztatu samochodowego, a mechanik mówi mu: „Słuchaj, robimy w zasadzie to samo: ty operujesz ludzkie serce, a ja — serce samochodu. Ty za operację dostajesz 10 000 $, a ja za serwis — 100 rubli.”
Chirurg pyta: „Też chcesz dostawać 10 tysięcy za naprawę?” Mechanik na to — jasne. Chirurg siada do samochodu, odpala silnik i mówi: „No to rób remont.”
U nas jest podobnie. W developmentcie możesz wziąć zadanie i po dwóch tygodniach dostarczyć wynik. Potem wszystko da się poprawić, bo plus minus trzy dni nie mają większego znaczenia.
Ale w naszym przypadku każdy przeoczony alert albo błędna decyzja związana z alertem może skończyć się bardzo poważnym problemem. Żeby do tego nie dopuścić, potrzebna jest bliska, szybka i stała komunikacja.
Czy trudno przejść na pracę zdalną
Trudno zarządzań ludźmi zdalnie. Ale jest to trudne tylko wtedy, gdy ty jesteś w jednym biurze, a oni w drugim i pojawia się zniekształcona perspektywa. Siedzisz w Moskwie i wydaje ci się, że chłopaki z Niżnego pracują słabo, mało efektywnie. W Moskwie widzisz wysiłek ludzi wokół siebie, a wysiłku osób pracujących zdalnie już nie. Oceniasz wyłącznie rezultat.
W biurze bardzo dużo komunikacji odbywa się w nieformalny sposób — ktoś coś komuś powiedział po drodze do kuchni. Ludzie w innym biurze tego nie widzą ani nie czują, przez co ginie kontekst.
W momencie, gdy byliśmy już gotowi zrezygnować z biura, cała komunikacja (nawet między pracownikami siedzącymi w tym samym pomieszczeniu) odbywała się przez Google Meet. I kiedy ułożyliśmy całą komunikację zdalnie, zaczęło to działać w 100% — wszystkie bariery niezrozumienia zniknęły.
Trudno to wszystko poukładać, ale jeśli zrobić to dobrze, działa i nie powoduje żadnego dyskomfortu.
Jak zespoły samodzielnie zarządzają swoimi pieniędzmi
— Praca zdalna to kwestia budząca sporo kontrowersji. Czasem firmy boją się pozwolić ludziom pracować z domu, bo sądzą, że stracą nad nimi kontrolę. Ale ci, którzy to robią, też mówią, że wtedy trzeba pracować zupełnie inaczej.
— (DS) Rozwiązaliśmy ten problem, bo jesteśmy gotowi dzielić się z zespołami pieniędzmi. Cała nasza ekonomika i system motywacyjny są zbudowane niemal jak franczyza. Wynagrodzenia są wystarczająco wysokie, a dodatkowo zostawiamy zespołom swobodę dysponowania dodatkowymi środkami.
Zespół obsługuje pulę projektów. Wie, ile pieniędzy przynosi każdy z nich. Dokładnie zna swój udział w tych przychodach. Wszystkie środki, które zostają ponad ich pensje, pozostają w zespole i są dzielone między jego członków według określonego systemu. Motywacja jest całkowicie bezpośrednia: pozyskali projekt za kolejne 200 tysięcy — do pensji dochodzi jeszcze po 10 tysięcy. Popełnili błąd — trzeba zrekompensować to klientowi.
— (SB) Jeśli zaczynasz zawodzić zespół, od razu to widać. Odbierasz sobie możliwość uzyskania dodatkowego dochodu. A nasz system całkowicie rozwiązuje problem kontroli. Każdy układa sobie plan na każdy dzień, a codzienne spotkania w zupełności wystarczają, by rozumieć, kto czym się zajmuje.
— (DS) W warunkach działań wojennych nie okłamuje się towarzyszy z okopu.
— Czyli u was wynagrodzenia są jawne? Wszyscy wiedzą, kto ile zarabia?
— (DS) Jakiś czas temu zrezygnowaliśmy z jawności wynagrodzeń. Występują różnice regionalne. Mimo że staramy się płacić w regionach pełne moskiewskie stawki, i tak czasem pojawia się pewien dysonans.
— (SB) Teraz wszyscy wiedzą, ile pieniędzy ma łącznie zespół. Widzą też, jaki udział w bonusach otrzymują.
— (DS) Team leader każdego zespołu decyduje, ile dostaną jego ludzie i jak rozdzielić bonusy. Wtrącamy się w tę kwestię wyłącznie doradczo, a decyzja zawsze należy do team leadera.
Dlaczego ludzie boją się ofert pracy
Obchody 10-lecia firmy w 2018 roku
— Wystarcza wam 70 osób?
— (DS) Nie. W ciągu roku planujemy zatrudnić co najmniej 20 inżynierów DevOps. Ale to bardzo trudne. Mamy dość dużą pulę kandydatów, wszyscy w taki czy inny sposób o nas wiedzą. Ale tutaj sytuacja jest podobna jak z klientami. Bardzo wiele osób mówi: „boimy się u was pracować, bo może sobie nie poradzimy”. A my nie uważamy, że robimy tu jakieś superkosmiczne rzeczy.
Korespondencja z kandydatem
— Jakim trzeba być, żeby dać sobie radę?
— (DS) Teoretycznie człowiek powinien być równie mocny zarówno w developmentcie, jak i w operations. W praktyce takich osób na świecie jest garstka, nie mówiąc już o Rosji. Zwłaszcza takich, które są seniorami w obu obszarach. Nawet siebie niespecjalnie bym do nich zaliczał.
W naszych ogłoszeniach o pracę zawsze jasno opisujemy, co trzeba umieć. Dużo nad nimi pracujemy i staramy się pisać konkretnie.
— Może takie ogłoszenia naprawdę odstraszają, skoro jest w nich rozpisane, ile rzeczy trzeba wiedzieć?
— (DS) Nie, nie, nie, nie uważamy, że trzeba wiedzieć bardzo dużo różnych rzeczy.
— (SB) Interesuje nas nie tyle wiedza, co sposób myślenia i umiejętność szukania rozwiązań.
— (DS) Liczy się doświadczenie z Linuksem i sprawdzamy je dość prostymi zadaniami — po prostu jest ich dużo. Nasz test jest dość długi, przeciętnemu kandydatowi zajmuje 8 godzin. Na końcu patrzymy, jak dana osoba radziła sobie z problemami, jak szuka informacji w Google i jak szerokie ma horyzonty.
Wiedzę można u nas bardzo szybko nadrobić, bo mamy wiele różnych projektów i doświadczonych kolegów, którzy zawsze podpowiedzą. Dlatego w pierwszej kolejności patrzymy na to, czy kandydaci szybko myślą i mają doświadczenie.
— Poza testem jakoś jeszcze to weryfikujecie?
— (DS) U nas są trzy etapy. Najpierw odzywa się HR i prosi o opowiedzenie o swoim doświadczeniu. Potem osoby, które zainteresują HR, przechodzą zadanie testowe. Na końcu rozmawiają z nimi team leaderzy, przekazują HR-owi swoje opinie i jeśli wszyscy są zgodni, że są one pozytywne, to jest to podstawa, by złożyć kandydatowi ofertę.
500 tysięcy rubli na zatrudnienie przyszłego supermana
— (DS) Mamy bardzo nietypowe podejście do finansów: dzielimy się z zespołami i nie skąpimy środków. Dodatkowo przeznaczamy dla zespołu 500 tysięcy rubli na powiększenie składu. To swego rodzaju grant, dzięki któremu mogą znaleźć odpowiednią osobę i wszystkiego ją nauczyć, zanim w pełni wdroży się do pracy.
— 500 tysięcy na jedną osobę?!
Żeby zespół zarabiał dużo pieniędzy, musi brać więcej projektów. Do tego potrzebuje więcej ludzi. A żeby zatrudnić więcej ludzi, potrzeba więcej pieniędzy. To błędne koło. Właśnie po to, żeby je przerwać, dajemy środki na nową osobę. Zanim się wdroży, zespół może pozyskać kolejne projekty i już z tych pieniędzy wypłacać jej pensję. To po prostu rekompensata za okres, w którym nowa osoba jeszcze nie przynosi przychodu.
— Czy to nie za dużo jak na devopsów? Są codziennie obciążeni, codziennie działają w warunkach produkcyjnych, a do tego jeszcze muszą zajmować się finansami.
— (DS) Zajmuje się tym team lead, a to już nie do końca rola DevOps. Team leadzi częściej idą w stronę partnerstwa, żeby mieć opcje. Dlatego uważamy, że to dla nich normalne. Zwykłych osób w zespole to nie dotyczy.
Mówiąc wprost, wiedzą, że jeśli wypada kolega z zespołu, to w następnym miesiącu dostają jego pensję. Oczywiście będą musieli pracować więcej. A kiedy znajdą zastępstwo, oddają te pieniądze tej osobie.
A kiedy dajemy team leadom 500 tysięcy, nie chcą zatrudniać kogoś, kto się nie sprawdzi. Czasem łatwiej jest im odsiać 20 osób i wziąć jedną. Bywało tak, że z HR rozmawiało 100 osób, 30 z nich przechodziło do zadania technicznego, 20 je zaliczało, a team lead odrzucał wszystkich poza jedną osobą. To już przesada. Team leadzi bardzo boją się ryzyka. Omówiliśmy ten temat i wszyscy chyba zrozumieli, że to błąd. Wiele osób wypada na rozmowie inaczej niż potem pracuje. Dlatego trzeba dawać szansę i podejmować ryzyko.
— A team leadzi nie zaczynają tego nadużywać? Dostajesz 500 tysięcy, bardzo długo nikogo nie zatrudniasz i dostajesz kolejne 500 tysięcy.
— (DS) Pieniądze dostają tylko raz. Mówimy: „Macie teraz dziesięć osób, a potrzebujecie 11. Jest plan sprzedaży, będą dochodzić kolejne projekty i trzeba, żebyście byli gotowi. Oto 500 tysięcy na jedenaste stanowisko”. Drugi raz już tego nie dostaną. A jeśli ktoś odchodzi, to jest już problem zespołu i rozwiązują go w ramach własnego budżetu.
To jak gra w Monopoly.
— (SB) Uważamy, że team lead powinien być zanurzony w finansach. U nas ludzie dostają pensję z pieniędzy, które sami wypracowują. I poziom kosztów projektu ma ogromne znaczenie. Klient przychodzi z jedną infrastrukturą, a po roku jego infrastruktura jest 10 razy większa. Jeśli team lead nie uczestniczy w finansach, nie będzie w stanie właściwie wycenić kosztu utrzymania.
— (DS) Zdarza się, że zespół przez kilka miesięcy walczy z problemami klienta, widzi, że dostaje za to umowne sto tysięcy i że to zupełnie nie odpowiada temu, co dzieje się teraz. I choć bywa to bolesne, trzeba albo podnieść cenę, albo się rozstać. Chłopaki same podejmują te decyzje. Mimo że wszyscy pracują zdalnie. I uważamy to za nasze największe osiągnięcie. Mamy naprawdę autonomiczne i zmotywowane zespoły.
— Tak. I przez to brzmi to tak, jakby trzeba było być supermanem, żeby u was pracować. I umiejętności techniczne, i samodyscyplina, i ogarnięcie finansowe.
— (SB) U nas można zostać supermanem. Ale nawet ci liderzy zespołów, którzy to dziś potrafią, przyszli do nas jako zwykli inżynierowie. Rok czy dwa wystarczą, żeby człowiek zmienił się w takiego supermana.
— Liderzy zespołów będący partnerami wyrośli ze zwykłych inżynierów. A czy można od razu zostać zatrudnionym na takie stanowisko?
— (DS) Czegoś takiego jeszcze u nas nie było, wszyscy wyrośli z roli inżyniera. Ale rozważamy scenariusz połączenia z małą firmą, która stałaby się po prostu kolejnym naszym zespołem. Chcielibyśmy tego spróbować.
— Czy możecie zatrudnić kogoś, kto jest dobrym inżynierem, ale nie jest wystarczająco zorganizowany na poziom takich zespołów?
— (DS) Nie boimy się osób, którym brakuje organizacji — mamy przecież stały strumień zadań. Bardzo szybko wychodzi na jaw, czy da się komuś pomóc lepiej się zorganizować. Jeśli ktoś będzie codziennie opowiadał, co zrobił, a w rzeczywistości nie będzie robił nic, po prostu będzie mu wstyd.
Kiedy widzisz, że wszyscy siedzą w jednej łódce i wspólnie wiosłują, trudno ci odłożyć wiosło. W takich warunkach nawet ludzie na co dzień mało zorganizowani stają się zorganizowani. A jeśli nie, to nie.
Strasznie nie znosimy powierzchowności — w ludziach, w pracy i w nas samych. Kiedy ktoś do nas trafia, rozwija się bardzo szybko, nawet trzy razy szybciej niż gdziekolwiek indziej. U nas to naprawdę trzy lata doświadczenia i rozwoju kompetencji w jeden rok.
Bardzo nie lubimy powierzchownych midów. Z naszego punktu widzenia mid to osoba, która naprawdę sporo już potrafi. Powiem wprost — rynek DevOps jest strasznie, strasznie rozmyty. Są midzi, którzy uważają się za juniorów. Są juniorzy, którzy uważają się za seniorów. Kiedy ktoś do nas trafia, bardzo szybko rozumie, jaki jest jego realny poziom.
Nie oznacza to, że nie zatrudniamy juniorów — wręcz przeciwnie, robimy to chętnie i będziemy zatrudniać ich jeszcze więcej. Już tworzymy specjalny zespół „DevOps-akcelerator” i wydzielamy do niego projekty, w których można podjąć ryzyko, gdzie klient jest gotów, byśmy to ryzyko podjęli. Pewnie pojawi się nawet dedykowana usługa. Coś w rodzaju „Flant-light”.
— Czy chcielibyście stać się dużą korporacją?
— (DS) Chcielibyśmy, ale z jednym zastrzeżeniem. Bardzo nie chcemy stracić naszej kultury. Na pewno będziemy rosnąć, ale zachowanie kultury technicznej i kultury pracy jest dla nas nawet ważniejsze niż sam rozwój.
Mamy tylko jedno życie i i tak nie da się zarobić wszystkich pieniędzy świata, więc chcemy przeżyć je wśród dobrych ludzi. Zdecydowanie nie akceptujemy biurokracji ani pozorowania pożytecznej pracy. U nas relacje są całkowicie horyzontalne. Swoją opinię można przekazać kierownictwu nawet w bardzo bezpośredni sposób: istota sprawy jest ważniejsza niż formalności.
— (SB) Ale do tego trzeba mieć naprawdę mocne argumenty.
— (DS) Zdecydowanie tak! Praca zdalna też jest nam potrzebna, bo tak właśnie żyjemy i tak postrzegamy świat. Dima Shurupov mieszka w Tajlandii, ja w Niemczech. Sasza Batałow jest w Moskwie, a dyrektor HR w Tiumeniu.
Uważamy, że skoro żyjemy na tej planecie, to warto przeżyć życie, naprawdę ją poznając. Nie ma sensu żyć w warunkach, w których chodzenie do pracy jest nieprzyjemne. Dlatego chcemy tworzyć miejsce, do którego chce się przychodzić. Konflikty w pracy są zdecydowanie nieprzyjemne, więc robimy wszystko, aby ich nie było. Zdarzają się u nas spory i zażarte dyskusje, ale nie konflikty.
— Czy nie uważa Pan, że bycie dużą firmą oznacza nie tylko świadczenie usług, ale też tworzenie czegoś własnego? Że nie chodzi tylko o to, by przeżyć życie i zobaczyć świat, ale też coś po sobie zostawić?
— (DS) To dla nas bardzo drażliwy temat, bo jesteśmy firmą usługową. Tworzymy jednak dużo oprogramowania i w gruncie rzeczy naszym produktem są usługi o zupełnie innej efektywności. Nigdy nikomu nie sprzedawaliśmy godzin ani ludzi. Klienci zawsze przychodzili i pytali: „czy można kupić sto godzin”? Nie, nie można, my nie sprzedajemy godzin.
Sprzedajemy rezultat. Rezultat polega na tym, że zdejmujemy z klienta ciężar problemu i go rozwiązujemy. I robimy to nie tak, jak nam powiedziano, lecz tak, jak sami wiemy, że trzeba. Naszym produktem jest nasze doświadczenie. Na pewno będziemy tworzyć gotowe rozwiązania i produkty SaaS, mamy wiele pomysłów. Ale nie ma pośpiechu. Przed nami jeszcze wiele dekad.
Źródło: habr.com
