<\/a><\/noindex><\/p>\nUn gruppo di studenti appassionati di Linux<\/h2>\n \nDmitry Stolyarov (CTO) durante la sua presentazione<\/i><\/p>\n
\u2014 (Dima Stolyarov)<\/b> Ci siamo sempre occupati di Linux e open source, ma abbiamo iniziato con un argomento piuttosto ridicolo, per cui ora ci vergogniamo un po'. Per qualche motivo pensavamo che fosse necessario implementare Linux negli uffici al posto di Windows. Il primo nome dell'azienda era TrueOffice \u2014 \"ufficio vero\". Poi abbiamo capito che a nessuno interessava. Era il 2006, avevo 19 anni. Solo nel 2012-13 \u00e8 arrivata la consapevolezza su come fare business e quali tecnologie servissero al mondo.<\/p>\n
Alexander Batalov (CEO) allo stand dell'azienda durante la conferenza<\/i><\/p>\n
\u2014 (Sasha Batalov)<\/b> Oltre alla tecnologia, c'\u00e8 un'enorme area di marketing, vendite ed economia, di cui nessuno ci ha mai insegnato nulla, tranne i corsi all'universit\u00e0, ma non so quanto siano applicabili e utili. <\/p>\n
All'inizio pensavamo che tutto questo non fosse necessario, ma poi ci siamo trovati a doverlo apprendere sul campo, leggendo libri, a volte gi\u00e0 dopo aver accumulato qualche esperienza. In generale, abbiamo percorso una strada lunga e tortuosa, provando un sacco di cose sbagliate. <\/p>\n
\u2014 (DS)<\/i> Ma gradualmente, con l'aumento delle competenze, ci siamo specializzati in Linux e ora ci occupiamo solo di high load, progetti web ad alta richiesta. E quando \u00e8 arrivato Kubernetes, abbiamo subito capito che era il fondamento di cui avevamo tanto bisogno. <\/p>\n
\u2014 Perch\u00e9 c'era tanto interesse per Linux? Ideologico o tecnologico?<\/b><\/p>\n
\u2014 (DS)<\/i> L'azienda ha due fondatori: Dima Shurupov e io. Dima Shurupov era pi\u00f9 interessato all'open source, mentre a me piaceva proprio Linux, tecnologicamente, com'\u00e8 strutturato. Cos\u00ec \u00e8 emersa una combinazione: a Dima piace l'ideologia, a me la tecnologia. Amo l'open source come idea, ma ho sempre ritenuto pi\u00f9 importante l'aspetto tecnologico.<\/p>\n
Einstein diceva: \u00abFai le cose il pi\u00f9 semplicemente possibile, ma non pi\u00f9 semplicemente\u00bb. Ecco, Linux \u00e8 costruito in modo cos\u00ec semplice, affidabile e trasparente che ne godo. A tutti noi piaceva, e siamo passati da un gruppo di studenti a una grande azienda. Ora siamo gi\u00e0 70. Per il settore IT e per servizi specializzati, \u00e8 abbastanza.<\/p>\n
\u2014 Com'era tutto ai tempi del gruppo di studenti?<\/b><\/p>\n
\u2014 (DS)<\/i> Beh, come di solito accade con gli studenti: divertente e vivace.<\/p>\n
\u2014 (SB)<\/i> Un'enorme quantit\u00e0 di altruismo, il desiderio di conquistare internet, di scalare vette tecnologiche. Ci immischiavamo in compiti molto complessi \u2014 prendevamo a cuore progetti seri (ma molto interessanti!) nel campo dell'integrazione di sistemi, realizzando tutto a prezzo stracciato. Tentavamo di creare i nostri framework, assorbivamo tutte le tecnologie che scoprivamo, e cercavamo subito di applicarle.<\/p>\n
\u2014 E dal punto di vista commerciale, andava bene?<\/b><\/p>\n
\u2014 (DS)<\/i> S\u00ec, ma nelle fasi iniziali non avevamo bisogno di nulla. A quei tempi, per me 40 mila rubli erano un guadagno assolutamente normale, mi sembrava di vivere come un re.<\/p>\n
\u2014 (SB)<\/i> E io pensavo che con mille dollari si potesse fare qualsiasi sito immaginabile.<\/p>\n
\u2014 (DS)<\/i> Nel 2013 non avevamo soldi per assumere liberamente a Mosca. Tutti i conoscenti che potevamo reclutare, li avevamo gi\u00e0 presi. Abbiamo deciso di aprire un ufficio a Nizhny Novgorod. Siamo andati l\u00ec, abbiamo aperto, abbiamo iniziato a assumere. Poi ci siamo resi conto che vivere con due uffici era difficile, e abbiamo deciso di vivere senza uffici.<\/p>\n
Certo, abbiamo fatto molti errori. Solo nel 2016, con mio grande imbarazzo, ho letto Remote. Ho pianto e riso, perch\u00e9 abbiamo percorso la stessa strada. Ogni paragrafo si sovrapponeva alla mia esperienza personale. <\/p>\n
\u2014 (SB)<\/i> In ogni paragrafo c'erano le nostre cicatrici.<\/p>\n\nCosa fa Flant<\/h2>\n \n
Per formare una gestione di alta qualit\u00e0 della produzione, servono 15-20 DevOps, specialisti di database, di Kubernetes, supporto tecnico e cos\u00ec via. Se l'azienda \u00e8 piccola, dove ci sono solo un paio di decine di sviluppatori, \u00e8 impossibile. E qui arriviamo noi e salviamo. Per circa 150.000.<\/p>\n
In passato avevamo come missione quella di creare un'azienda in cui ci sarebbe stato comodo lavorare, per quanto possa suonare sciocco. Ora che ci siamo riusciti, la missione \u00e8 rendere tecnologie di livello Google e Facebook accessibili a piccole imprese e startup nelle fasi iniziali.<\/p>\n
Le persone possono concentrarsi sul loro prodotto, invece di superare problemi che non dovrebbero affrontare.<\/p>\n
Molti ragazzi che vengono da noi sono sorpresi da quanto \u00e8 vario e quante sono le pressioni. Abbiamo oltre 50 progetti in produzione, pi\u00f9 di 70 cluster Kubernetes. Ogni volta si pu\u00f2 sempre inventare qualcosa. Ho aperto un disegnatore, ho tracciato un'architettura a microservizi, ho fatto un elenco di 200 tecnologie \u2014 e si parte. Ma questo porta sempre a problemi e conseguenze. <\/p>\n
La chiave \u00e8 garantire da un lato la massima stabilit\u00e0, affidabilit\u00e0 e semplicit\u00e0, dall'altro un alto livello di innovazione. Ecco, siamo orgogliosi di saperlo fare. Lo facciamo ovunque e a livello massivo, come una sorta di Ikea.<\/p><\/blockquote>\n
A chi servono i DevOps in outsourcing<\/h2>\n \n\u2014 Mi sembra che le grandi aziende preferiscano avere i DevOps in-house.<\/b><\/p>\n
\u2014 (SB)<\/i> \u00c8 chiaro che grandi attori come Avito o Badoo possono assumere i loro DevOps. Anche le piccole aziende con enormi investimenti possono farlo \u2014 tuttavia possono assumerli, ma non \u00e8 detto che abbiano la forza per gestirli.<\/p>\n
Riteniamo che anche le grandi aziende dovrebbero rivolgersi a esperti che conoscono realmente il settore. Le piccole aziende, il cui business \u00e8 basato su soluzioni web, devono assolutamente affidarsi a persone esperte. Perch\u00e9 qualsiasi semplice errore in un sistema chiave equivale a una perdita di denaro.<\/p>\n
\u2014 (DS)<\/i> Sappiamo che le persone in Russia temono l'outsourcing \u2014 sia per esperienze negative che per altre ragioni. Ma i nostri clienti non ci lasciano. Negli ultimi dieci anni, se ne sono andati solo per due motivi: o ci hanno superato (ad esempio, sono stati acquisiti e hanno ristrutturato tutto), o hanno chiuso perch\u00e9 l'idea non ha funzionato.<\/p>\n
\u2014 E chi viene da voi pi\u00f9 spesso \u2014 piccole aziende o grandi?<\/b><\/p>\n
\u2014 (DS)<\/i> Al momento, entrambi. Ma le piccole hanno paura di noi, pensano che noi\u2026 <\/p>\n
\u2014 (SB)<\/i>\u2026 siamo grandi, complessi, inaccessibili e voliamo tra le nuvole. <\/p>\n
\u2014 (DS)<\/i> Certo, passi davanti a un concessionario con una Maybach e non entri, non chiedi il prezzo, perch\u00e9 una Maybach non pu\u00f2 costare solo 500 mila rubli. <\/p>\n
\u2014 Certo che no.<\/b><\/p>\n
\u2014 (SB)<\/i> Ma non appena appare nel car sharing, puoi permetterti di guidarla. <\/p>\n
\u2014 (DS)<\/i> S\u00ec, certamente non siamo una Maybach \u2014 siamo Ikea. Anche noi offriamo qualcosa di semplice, affidabile e accessibile. In generale, il numero di aziende che si rivolgono a noi tra le TOP-50 e le piccole aziende \u00e8 lo stesso. Ma ci concentriamo principalmente sulle piccole imprese e lavoriamo principalmente con loro, cercando di evitare collaborazioni con le grandi. <\/p>\n
\u2014 Perch\u00e9?<\/b><\/p>\n
\u2014 (DS)<\/i> C'\u00e8 molta burocrazia.<\/p>\n
\u2014 (SB)<\/i> In una grande azienda ci sono molti livelli in cui \u00e8 suddivisa la responsabilit\u00e0, il feedback \u00e8 molto lento e spesso le persone iniziano a complicare le cose: \"Facciamo delle valutazioni, scriviamo una strategia, un piano per l'anno prossimo, facciamo le cose in modo che sia migliore per la cultura enterprise, cos\u00ec abbiamo lavorato fino adesso\". Cominciano a complicare questioni che potrebbero essere risolte con un approccio semplice e diretto, portando il 80% del risultato gi\u00e0 domani. Si prendono il percorso lungo dove non si sa nemmeno se funzioner\u00e0. <\/p>\n
Di conseguenza, invece di pratiche consolidate, reinventiamo continuamente la ruota, e il costo della soluzione tecnologica diventa enormemente pi\u00f9 alto. E la qualit\u00e0 non \u00e8 garantita migliore. <\/p>\n
\nCosto per l'outsourcing<\/h2>\n \n
Tutti i ragazzi in azienda contribuiscono in un modo o nell'altro \u2014 con feedback, documentazione o codice. Crediamo che sia il nostro tributo per tutto quel ricco mondo di utilit\u00e0 open source che utilizziamo. E penso che stiamo contribuendo in modo adeguato.<\/p>\n
Chiamiamo questo processo la condensazione dell'esperienza. Inizialmente, una persona ha imparato qualcosa, l'ha condiviso con i colleghi e quell'esperienza \u00e8 diventata folklore. Poi abbiamo scritto la documentazione e successivamente l'abbiamo trasformata in utilit\u00e0, dimenticando la sua esistenza, perch\u00e9 non ci pensiamo pi\u00f9 \u2014 tutto viene registrato automaticamente.<\/p><\/blockquote>\n
La popolarit\u00e0 delle tecnologie e la tossicit\u00e0 degli sviluppatori<\/h2>\n \n\u2014 Perch\u00e9 proprio Ubuntu? Cosa avete considerato prima di sceglierla?<\/b><\/p>\n
\u2014 (DS)<\/i> Eravamo un gruppo di studenti che amava Linux. Abbiamo usato a lungo Gentoo \u2014 \u00e8 una distribuzione basata sul source, che deve essere compilata da zero ogni volta. Quando abbiamo avuto un paio di centinaia di server, l'aggiornamento richiedeva mesi. Inizialmente, abbiamo automatizzato e ottimizzato tutto, ma alla fine ci siamo resi conto che dovevamo cambiare qualcosa e, conoscendo i pro e i contro delle diverse soluzioni, abbiamo semplicemente scelto il pi\u00f9 popolare. All'epoca era intuitivo \u2014 se era il pi\u00f9 popolare, allora si svilupper\u00e0 meglio e tutti i difetti saranno corretti prima o poi. <\/p>\n
C'era un database chiamato Resync DB. Competivano con MongoDB e sono nati pi\u00f9 o meno nello stesso periodo. Per molto tempo, Resync era tecnologicamente migliore.<\/p>\n
Quando arrivavano gli utenti, cercavano di risolvere i problemi sistemici interni, mentre in MongoDB questi problemi venivano risolti molto meno, ma potevano impostare una condizione if per performare meglio nei test sintetici. Per questo motivo, la popolarit\u00e0 di MongoDB cresceva. Nei casi pi\u00f9 semplici si comportavano meglio, ma internamente erano scadenti. Resync DB, d'altra parte, internamente era buono, ma non cresceva in popolarit\u00e0.<\/p>\n
Alla fine, per MongoDB tutto \u00e8 migliorato, mentre nessuno si ricorda di Resync DB. L'azienda \u00e8 andata in bancarotta. Ecco, la stessa storia riguarda Ubuntu. Questo sistema operativo ha molta attenzione, quindi abbiamo deciso di usarlo.<\/p>\n
\u2014 Cosa ne pensi degli ultimi cambiamenti politici, CoC e simili?<\/b><\/p>\n
\u2014 (DS)<\/i> Beh\u2026 non c'\u00e8 nulla di negativo, va tutto bene, \u00e8 tutto chiaro. Anch'io soffro per il fatto che a volte ferisco le persone. A me, ad esempio, una cosa sembra ovvia, e comincio a infastidirmi terribilmente quando le persone non la capiscono. Mi arrabbio, e si crea una negativit\u00e0 (ma ci sto lavorando).<\/p>\n
Linus \u00e8 molto intelligente, dopo tutto lavora a questo da 30 anni. \u00c8 chiaro che \u00e8 una persona brusca, non le manda a dire. La sua cortesia ne risente, e la comunit\u00e0 sta lavorando su questo. Lui comprende tutto e lo ammette. <\/p>\n
\u2014 Ma, come ho capito dalla reazione nelle discussioni, molte persone supportano l'idea di parlare in modo diretto e brusco, e se a qualcuno non piace \u2014 non \u00e8 zucchero, non si scioglie.<\/b><\/p>\n
\u2014 (DS)<\/i> No, non \u00e8 cos\u00ec. Io, essendo una persona che soffre per la mancanza di cortesia, capisco che sia molto male. Questo rovina la comunit\u00e0. Ci sono persone a cui non importa, ma per la maggior parte delle persone \u00e8 comunque importante avere un comfort emotivo.<\/p>\n
Ecco, nel codice c'\u00e8 un errore stupido. Si potrebbe dire: \u00abRagazzi, \u00e8 brutto che trascuriamo tali cose semplici, dobbiamo correggerle\u00bb. Oppure si potrebbe dire: \u00abQuale idiota ha fatto questo?!\u00bb. Una frase. Quella persona che ha commesso questo errore potrebbe anche essere pi\u00f9 intelligente ed esperta di te, ma semplicemente non era dello spirito giusto quando ha sbagliato \u2014 chiss\u00e0 cosa gli \u00e8 successo. E per lui sar\u00e0 un'offesa diretta. A che serve?<\/p>\n
Bisogna dire le cose direttamente, ma non bisogna dire \u00abQuale idiota l'ha scritto\u00bb. Non ha senso nascondere e avvolgere, ma non bisogna ferire le persone.<\/p>\n
Perch\u00e9 i DevOps devono chiamarsi ogni giorno?<\/h2>\n \n(DS)<\/i> Adesso abbiamo un piccolo ufficio, dove ci sono documenti e un office manager che si occupa di questi documenti.<\/p>\n
In azienda ci sono 70 persone. 20 persone fanno parte del team OPS. 30 persone sono tre team DevOps di circa 10 persone ciascuno. Le restanti 20 sono sviluppatori e vendite. 8 sviluppatori, il reparto R&D \u2014 4 persone. Persone non tecniche in tutta l'azienda sono 5-6.<\/p>\n
I soldi chiave li guadagnano tre team DevOps. I processi sono gli stessi ovunque \u2014 ogni giorno c'\u00e8 una lunga riunione, che dura un'ora o un'ora e mezza. Ma l\u00ec si trattano tutte le questioni tecniche, e i ragazzi decidono cosa fare dopo. E poich\u00e9 tutti sono in remoto \u2013 \u00e8 un'opportunit\u00e0 per comunicare adeguatamente.<\/p>\n
\u2014 \u00c8 davvero necessario ogni giorno?<\/b><\/p>\n
\u2014 (DS)<\/i> S\u00ec.<\/p>\n
\u2014 Tutti sono d'accordo su questo?<\/b><\/p>\n
\u2014 (DS)<\/i> S\u00ec, tutti sono d'accordo e tutti si sentono a proprio agio. Ma in alcuni giorni l'incontro pu\u00f2 durare anche 30 minuti. Nonostante la comunicazione molto intensa su Slack, si desidera comunque sincronizzarsi bene e capire cosa \u00e8 successo ieri. Vogliamo capirci a vicenda, non semplicemente fare clic su compiti.<\/p>\n
\u2014 (SB)<\/i> In ogni momento pu\u00f2 succedere qualcosa, la situazione pu\u00f2 cambiare. \u00c8 necessaria una continua correzione. <\/p>\n
\u2014 (DS)<\/i> Hai una buona barzelletta su questo tema.<\/p>\n
\u2014 (SB)<\/i> S\u00ec. Un cardiochirurgo arriva in un centro auto e il meccanico gli dice: \u00abSenti, ci occupiamo della stessa cosa, solo che tu operi il cuore di una persona e io quello di un'auto. Tu guadagni 10.000$ per un'operazione, mentre io per un servizio prendo 100 rubli.<\/p>\n
Il chirurgo chiede: \u00abVuoi anche tu guadagnare 10.000 per una riparazione?\u00bb Il meccanico risponde \u2014 certo. Il chirurgo si siede in macchina, la avvia e dice \u2014 \u00abfacciamo il lavoro\u00bb.<\/p>\n
Anche da noi. Nello sviluppo puoi prendere un compito e portare il risultato dopo due settimane. Poi tutto pu\u00f2 essere corretto, perch\u00e9 pi\u00f9 o meno tre giorni non influenzano nulla. <\/p>\n
Nel nostro caso, ogni allerta ignorata o decisione sbagliata riguardo a un allerta pu\u00f2 diventare un grande problema. Per evitare ci\u00f2, \u00e8 necessaria una comunicazione stretta, veloce e costante.<\/p>\n
\n\u00c8 difficile passare al lavoro da remoto?<\/h2>\n \n\u00c8 difficile gestire le persone da remoto. Ma \u00e8 difficile finch\u00e9 sei in un ufficio e loro in un altro, e c'\u00e8 una certa confusione mentale. Sei a Mosca e ti sembra che quelli di Nizhny stiano lavorando male, in modo inefficace. A Mosca vedi gli sforzi delle persone intorno, mentre non vedi quelli dei remote worker. Prendi solo il risultato. <\/p>\n
In ufficio molte comunicazioni avvengono in modo informale \u2014 qualcuno dice qualcosa a qualcuno mentre passa sulla cucina. Le persone in un altro ufficio non vedono, non sentono, e il contesto si perde.<\/p>\n
Quando eravamo gi\u00e0 pronti a rinunciare all'ufficio, tutte le comunicazioni (anche tra i dipendenti nello stesso ambiente) avvenivano attraverso Google Meet. E quando abbiamo organizzato tutta la comunicazione da remoto, ha funzionato al 100%, tutte le barriere di incomprensione sono state rimosse.<\/p>\n
Organizzare tutto \u00e8 difficile, ma se fai tutto nel modo giusto \u2014 funziona e non causa alcun disagio.<\/p><\/blockquote>\n
Come gestiscono autonomamente i loro soldi le squadre?<\/h2>\n \n\u2014 Il lavoro a distanza \u00e8 una questione controversa. A volte le aziende temono di lasciare le persone a casa perch\u00e9 pensano di perdere il controllo su di esse. Ma coloro che lasciano andare, dicono anche che bisogna lavorare in modo completamente diverso.<\/b><\/p>\n
\u2014 (DS)<\/i> Abbiamo risolto questo problema offrendo di condividere i soldi con i team. La nostra economia e il sistema di incentivazione sono costruiti quasi come una franchigia. Gli stipendi sono abbastanza alti, oltre a lasciare ai ragazzi una parte di denaro libero.<\/p>\n
Il team gestisce un insieme di progetti. Sanno quanto guadagna ciascuno di questi progetti. Sanno esattamente la loro quota di questi soldi. Tutti i soldi che rimangono oltre il loro stipendio restano nel team e vengono divisi tra di loro secondo un certo sistema. La motivazione \u00e8 assolutamente diretta: prendi un progetto per ulteriori 200.000, aumenti di dieci in stipendio. Fai un errore \u2014 devi risarcire il cliente.<\/p>\n
\u2014 (SB)<\/i> Se inizi a deludere i ragazzi, questo si sente subito. Ti privi della possibilit\u00e0 di ricevere un reddito aggiuntivo. E il nostro sistema risolve completamente il problema del controllo. Ogni persona pianifica la propria giornata e le riunioni quotidiane sono sufficienti per capire chi sta facendo cosa.<\/p>\n
\u2014 (DS)<\/i> In condizioni di guerra, i compagni in trincea non mentono. <\/p>\n
\u2014 Quindi, avete stipendi trasparenti? Tutti sanno quanto guadagna ciascuno? <\/b><\/p>\n
\u2014 (DS)<\/i> Abbiamo chiuso gli stipendi qualche tempo fa. C'\u00e8 una differenza regionale. Nonostante ci sforziamo di pagare integralmente gli stipendi di Mosca nelle regioni, c'\u00e8 comunque un certo dissonanza.<\/p>\n
\u2014 (SB)<\/i> Ora tutti sanno quanto denaro c'\u00e8 in totale per il team. Vedono quale quota dei bonus ricevono. <\/p>\n
\u2014 (DS)<\/i> Il team lead di ogni squadra decide quanto guadagneranno i suoi ragazzi e come distribuire i bonus. Ci interferiamo nella questione solo con dei consigli, la decisione rimane sempre al team lead.<\/p>\nPerch\u00e9 le persone hanno paura delle posizioni aperte<\/h2>\n
\nCelebrazione del decimo anniversario dell'azienda nel 2018<\/i><\/p>\n
\u2014 70 persone sono sufficienti per voi?<\/b><\/p>\n
\u2014 (DS)<\/i> No. Il nostro piano \u00e8 di assumere almeno 20 ingegneri DevOps nell'arco di un anno. Ma \u00e8 molto difficile. Abbiamo un buon numero di candidati, tutti sanno in qualche modo di noi. Ma qui la situazione \u00e8 simile a quella con i clienti. Molti dicono: 'abbiamo paura di lavorare da voi, magari non ce la facciamo'. Ma non consideriamo di avere qui cose super complicate.<\/p>\n
Corrispondenza con un candidato<\/i><\/p>\n
\u2014 Come bisogna essere per farcela?<\/b><\/p>\n
\u2014 (DS)<\/i> Teoricamente, una persona dovrebbe essere sviluppata in modo uniforme nello sviluppo e nell'operazione. Nella pratica, tali persone nel mondo sono rare, per non parlare della Russia. Soprattutto quelli che sono senior in entrambi gli ambiti. Non mi considererei nemmeno tra di loro.<\/p>\n
Nelle nostre offerte di lavoro \u00e8 sempre ben scritto cosa \u00e8 necessario sapere. Ci lavoriamo molto e cerchiamo di essere concreti.<\/p>\n
\u2014 Forse le offerte di lavoro spaventano davvero se scritto quanto sia necessario sapere?<\/b><\/p>\n
\u2014 (DS)<\/i> No-no-no, non crediamo che sia necessario sapere molte cose. <\/p>\n
\u2014 (SB)<\/i> Siamo interessati non alle conoscenze, ma al pensiero critico e alla capacit\u00e0 di trovare soluzioni.<\/p>\n
\u2014 (DS)<\/i> Ci interessa l'esperienza in Linux, e la verifichiamo con compiti abbastanza semplici \u2014 semplicemente un gran numero di compiti. Il nostro test \u00e8 piuttosto lungo, per un candidato medio dura 8 ore. E alla fine guardiamo come la persona ha affrontato i problemi, come cerca su Google, quale \u00e8 la sua visione del mondo.<\/p>\n
Le conoscenze si possono acquisire molto rapidamente, perch\u00e9 abbiamo molti progetti diversi e colleghi esperti che sono sempre disponibili a suggerire. Quindi guardiamo prima di tutto per vedere se i ragazzi capiscono rapidamente e hanno esperienza.<\/p>\n
\u2014 Oltre al test, come lo individuate?<\/b><\/p>\n
\u2014 (DS)<\/i> Abbiamo tre fasi. Inizialmente parla il reclutatore, chiedendo di raccontare l'esperienza. Poi quelli che piacciono al reclutatore svolgono un compito di prova. Alla fine parlano i team leader e danno le loro opinioni al reclutatore, e se sono tutte positive \u2014 \u00e8 l'occasione per fare un'offerta.<\/p>\n500 mila rubli per assumere il futuro supereroe<\/h2>\n
\n\u2014 (DS)<\/i> Abbiamo un approccio molto atipico verso le finanze, condividiamo con i team e non siamo avari. E poi diamo al team 500 mila rubli per espandere il personale. Cio\u00e8, \u00e8 una sovvenzione affinch\u00e9 possano trovare una persona e insegnarle tutto, mentre si integra.<\/p>\n
\u2014 500 mila per persona?!<\/b><\/p>\n
Per far guadagnare molto denaro al team, devono assumere pi\u00f9 progetti. Per questo hanno bisogno di pi\u00f9 persone. E per assumere pi\u00f9 persone \u2014 servono pi\u00f9 soldi. Questo \u00e8 un circolo vizioso. Per rompere questo circolo, diamo soldi per una nuova persona. Finch\u00e9 si integra, possono prendere altri progetti e gi\u00e0 con quei soldi pagargli lo stipendio. Cio\u00e8, \u00e8 una compensazione, finch\u00e9 il nuovo non porta denaro. <\/p>\n
\u2014 E non \u00e8 troppo per i DevOps? Sono sotto pressione ogni giorno, sempre in condizioni operative, e devono anche occuparsi della gestione finanziaria.<\/b><\/p>\n
\u2014 (DS)<\/i> Questo \u00e8 compito del team leader, che non \u00e8 pi\u00f9 del tutto un DevOps. I team leader tendono piuttosto verso il partnership per avere opzioni. Pertanto, riteniamo che sia normale per loro. Gli altri membri del team non ne sono coinvolti.<\/p>\n
In parole povere, sanno che se un collega si ritira, il mese successivo riceveranno il suo stipendio. Ovviamente, dovranno lavorare di pi\u00f9. E quando trovano una sostituzione, restituiscono indietro quei soldi. <\/p>\n
Quando diamo ai team leader 500.000, non vogliono assumere qualcuno che non sia all'altezza. A volte \u00e8 pi\u00f9 semplice scartare 20 persone e prenderne una. \u00c8 successo che con l'HR abbiano parlato con 100 persone, 30 di loro hanno seguito un compito tecnico, 20 hanno passato, e tutti tranne uno sono stati scartati dal team leader. \u00c8 andata cos\u00ec. I team leader temono molto di rischiare. Abbiamo discusso di questo tema e sembrava che tutti avessero capito che era un errore. Molte persone si mostrano in modo diverso durante il colloquio rispetto a come si comporteranno nel lavoro. \u00c8 quindi necessario dare una possibilit\u00e0 e assumere dei rischi.<\/p>\n
\u2014 I team leader non abusano della situazione? Ricevi 500.000, non assumi per molto tempo, ricevi altri 500.000.<\/b> <\/p>\n
\u2014 (DS)<\/i> Ricevono i soldi una sola volta. Diciamo: \u00abAvete attualmente dieci persone, ma ne servono undici. C'\u00e8 un piano di vendita, arriveranno altri progetti e dovete essere pronti. Ecco 500.000 per l'undicesima posizione\u00bb. Non li riceverai una seconda volta. Se qualcun altro se ne va, \u00e8 gi\u00e0 un problema del team; devono risolvere la questione nei loro budget. <\/p>\n
\u00c8 come giocare a Monopoli.<\/p>\n
\u2014 (SB)<\/i> Riteniamo che un team leader debba essere coinvolto nelle finanze. Da noi, le persone ricevono il proprio stipendio dai soldi che guadagnano. E il livello di spesa del progetto \u00e8 molto importante. Un cliente arriva con una certa infrastruttura, e dopo un anno la sua infrastruttura \u00e8 dieci volte pi\u00f9 grande. E se il team leader non partecipa alle finanze, non sar\u00e0 in grado di valutare correttamente il costo di manutenzione.<\/p>\n
\u2014 (DS)<\/i> A volte, il team combatte per mesi con i problemi del cliente, comprendendo che vengono pagati per questo circa cento mila, e ci\u00f2 non corrisponde affatto a quanto sta accadendo. E, per quanto possa fare male, devono decidere se alzare il prezzo o separarsi. E i ragazzi prendono queste decisioni da soli. Considerando che lavorano tutti da remoto. E riteniamo che questo sia un nostro grande traguardo. Abbiamo team veramente autonomi e motivati.<\/p>\n
\u2014 S\u00ec. E da questo sembra che bisogna essere Superman per lavorare qui. Serve sia abilit\u00e0 tecniche, sia autodisciplina, sia conoscenza finanziaria.<\/b><\/p>\n
\u2014 (SB)<\/i> Da noi puoi diventare Superman. Ma anche i team leader che sanno farlo sono partiti come normali ingegneri. Bastano uno o due anni per diventare un supereroe di questo tipo.<\/p>\n
\u2014 I team leader partner sono cresciuti da ingegneri normali. Possono essere assunti direttamente per una posizione del genere?<\/b><\/p>\n
\u2014 (DS)<\/i> Non \u00e8 mai successo da noi, tutti sono cresciuti come ingegneri. Ma stiamo considerando l'idea di unirci a una piccola azienda che diventer\u00e0 semplicemente un altro nostro team. Vorremmo provare una cosa del genere.<\/p>\n
\u2014 Puoi prendere una persona se \u00e8 un buon ingegnere, ma non \u00e8 abbastanza organizzato per il livello di tali team?<\/b><\/p>\n
\u2014 (DS)<\/i> Non temiamo le persone disorganizzate, abbiamo un flusso costante di compiti. Si capisce molto rapidamente se si pu\u00f2 aiutare una persona a organizzarsi. Se racconta ogni giorno cosa ha fatto, senza fare niente di concreto, si sentir\u00e0 in imbarazzo. <\/p>\n
Quando vedi che tutti sono sulla stessa barca e remano, ti senti a disagio a lasciare l'ancora. In tali condizioni, anche le persone disorganizzate diventano organizzate. E se no, non lo saranno.<\/p>\n
Non tolleriamo affatto la superficialit\u00e0 \u2014 n\u00e9 nelle persone, n\u00e9 nelle cose, n\u00e9 in noi stessi. E venendo qui, le persone si sviluppano molto rapidamente, tre volte pi\u00f9 veloci che altrove. Qui davvero si accumula esperienza e competenze al ritmo di un anno ogni tre. <\/p>\n
Non ci piacciono affatto i mid-level superficiali. Dal nostro punto di vista, un mid pu\u00f2 gi\u00e0 fare molte cose. Dico come stanno le cose \u2014 il mercato del DevOps \u00e8 estremamente frastagliato. Ci sono mid che si considerano junior. Ci sono junior che si considerano senior. Una persona che arriva da noi comprende molto rapidamente il proprio livello reale.<\/p>\n
Ci\u00f2 non significa che non assumiamo junior \u2014 li prendiamo con piacere e ne assumeremo ancora di pi\u00f9. Stiamo gi\u00e0 creando un team speciale chiamato 'DevOps-Accelerator' e assegneremo progetti a cui possiamo rischiare, dove il cliente \u00e8 disposto a farci correre dei rischi. Probabilmente nascer\u00e0 anche un servizio speciale per questo. Qualcosa come 'Flant-Light'.<\/p>\n
\u2014 Vorreste diventare una grande corporation?<\/b><\/p>\n
\u2014 (DS)<\/i> Ci piacerebbe, ma con una condizione. Non vogliamo perdere la nostra cultura. Cresceremo di certo, ma mantenere la cultura tecnica e di lavoro \u00e8 anche pi\u00f9 importante dello sviluppo stesso.<\/p>\n
La vita \u00e8 una sola, comunque non si possono guadagnare tutti i soldi del mondo e si desidera viverla accanto a persone buone. Siamo categoricamente contrari alla burocrazia e alla simulazione di lavoro utile. Abbiamo relazioni assolutamente orizzontali. \u00c8 possibile esprimere anche il proprio pensiero alla direzione in modo molto diretto: l'essenza \u00e8 pi\u00f9 importante delle formalit\u00e0.<\/p>\n
\u2014 (SB)<\/i> Ma per questo \u00e8 necessario avere argomenti molto solidi.<\/p>\n
\u2014 (DS)<\/i> Sicuramente! E il lavoro a distanza \u00e8 necessario, perch\u00e9 viviamo cos\u00ec, vediamo il mondo in questo modo. Dima Shurupov vive in Thailandia, io in Germania. Sasha Batalov a Mosca, il direttore delle risorse umane a Tyumen. <\/p>\n
Riteniamo che vivendo su questo pianeta, si desideri vivere la vita, osservandola. Vivere in condizioni in cui andare a lavoro \u00e8 sgradevole \u2014 non \u00e8 necessario. Ecco perch\u00e9 vogliamo che si desideri andare al lavoro. Conflittare a lavoro \u2014 \u00e8 sicuramente sgradevole, quindi facciamo in modo che non ci siano conflitti. Abbiamo discussioni e battaglie, ma non conflitti. <\/p>\n
\u2014 Non pensa che diventare grandi significhi non solo fornire servizi, ma anche produrre. Che non basta vivere la vita e vedere il pianeta, ma \u00e8 necessario anche lasciare qualcosa?<\/b> <\/p>\n
\u2014 (DS)<\/i> \u00c8 una questione molto delicata per noi, perch\u00e9 siamo un'azienda di servizi. Ma facciamo molto software, e in sostanza il nostro prodotto sono servizi con un'efficacia completamente diversa. Non abbiamo mai venduto ore o persone a nessuno. I clienti venivano sempre e chiedevano \u2014 \"\u00e8 possibile acquistare cento ore\"? No, non \u00e8 possibile, non vendiamo ore. <\/p>\n
Noi vendiamo risultati. Il risultato \u00e8 che alleviamo il dolore, risolviamo un problema. E noi risolviamo non come ci hanno detto, ma come sappiamo fare. Il nostro prodotto \u00e8 la nostra esperienza. E sicuramente faremo soluzioni pronte, prodotti SaaS, ci sono molte idee. Ma non c'\u00e8 fretta. Davanti abbiamo molti decenni.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
![\"\u00abApproccio](\"\/wp-content\/uploads\/2019\/03\/0ee82b86e0cbe70d8a1aff2db82c47cd.png\")