<\/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 iniziavamo con temi piuttosto ridicoli, per i quali ora proviamo un po' di vergogna. Pensavamo erroneamente 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 di come fare business e quali tecnologie siano necessarie al mondo.<\/p>\n
Alexander Batalov (CEO) allo stand dell'azienda durante la conferenza<\/i><\/p>\n
\u2014 (Sasha Batalov)<\/b> Oltre alle tecnologie, c'\u00e8 un'enorme area di marketing, vendite ed economia, di cui nessuno ci ha mai parlato, tranne durante i corsi all'universit\u00e0, ma non so quanto siano realmente applicabili e utili. <\/p>\n
Inizialmente pensavamo che tutto questo non fosse necessario, ma poi abbiamo dovuto imparare sul campo, leggere libri, a volte dopo aver gi\u00e0 commesso degli errori. In generale, abbiamo percorso un lungo e difficile cammino, provando un sacco di cose sbagliate. <\/p>\n
\u2014 (DS)<\/i> Ma gradualmente, con l'aumento delle competenze, ci siamo specializzati sempre di pi\u00f9 in Linux, e ora ci occupiamo solo di high-load e di progetti web ad alta intensit\u00e0. E quando \u00e8 arrivato Kubernetes, abbiamo capito rapidamente che era il fondamento di cui avevamo cos\u00ec 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. A me invece piaceva proprio Linux, per come \u00e8 strutturato tecnologicamente. E cos\u00ec \u00e8 nato un abbinamento: a Dima piace l'ideologia, e a me la tecnologia. Amo l'open source come idea, ma per me la parte tecnologica \u00e8 sempre stata pi\u00f9 importante.<\/p>\n
Einstein diceva: \u00abSi deve fare il pi\u00f9 semplice possibile, ma non pi\u00f9 semplice\u00bb. Linux \u00e8 costruito in modo cos\u00ec semplice, affidabile e trasparente che lo godo. A tutti noi piaceva, e ci siamo trasformati da un gruppo di studenti in una grande azienda. Ora siamo gi\u00e0 70. Per l'IT, per i servizi specializzati, \u00e8 abbastanza.<\/p>\n
\u2014 Com'era il periodo da studenti?<\/b><\/p>\n
\u2014 (DS)<\/i> Beh, come di solito accade agli studenti \u2014 divertente e vivace.<\/p>\n
\u2014 (SB)<\/i> Un'enorme quantit\u00e0 di altruismo, il desiderio di conquistare Internet, di raggiungere vette tecnologiche. Ci siamo tuffati in compiti molto complessi \u2014 ci siamo occupati di progetti seri (ma molto interessanti!) di integrazione di sistemi, realizzandoli a prezzi stracciati. Abbiamo cercato di creare i nostri framework, assimilavamo tutte le tecnologie che conoscevamo e subito cercavamo applicazioni per esse.<\/p>\n
\u2014 E dal punto di vista commerciale, tutto andava bene?<\/b><\/p>\n
\u2014 (DS)<\/i> S\u00ec, ma nelle fasi iniziali non avevamo bisogno di nulla. A quei tempi, 40.000 rubli per me erano un reddito assolutamente normale, mi permetteva di vivere bene.<\/p>\n
\u2014 (SB)<\/i> E io pensavo che per mille dollari si potesse fare qualsiasi sito tu potessi immaginare.<\/p>\n
\u2014 (DS)<\/i> Nel 2013 non avevamo soldi per assumere liberamente a Mosca. Tutti i conoscenti che potevamo prendere, 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 abbiamo capito che vivere con due uffici era difficile e abbiamo deciso di vivere senza uffici.<\/p>\n
Certo, abbiamo accumulato un sacco di cerotti. Solo nel 2016, con mio grande imbarazzo, ho letto Remote. Ho pianto e riso, perch\u00e9 avevamo percorso esattamente lo stesso cammino. 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 avere una gestione di qualit\u00e0 della produzione, servono 15-20 DevOps, specialisti in database, in Kubernetes, assistenza clienti e cos\u00ec via. E se l'azienda \u00e8 piccola, dove gli sviluppatori sono solo una ventina, questo \u00e8 impossibile. Ed eccoci qui, che arriviamo in soccorso. Per circa 150.000.<\/p>\n
In passato, la nostra missione era creare un'azienda in cui ci sentissimo a nostro agio a lavorare, per quanto possa sembrare sciocco. Ora che ci siamo riusciti, la missione \u00e8 rendere tecnologie a livello di Google e Facebook accessibili alle piccole imprese e alle startup in fase iniziale.<\/p>\n
Le persone possono concentrarsi sul proprio prodotto, piuttosto che affrontare problemi che potrebbero essere evitati.<\/p>\n
Molti dei ragazzi che si rivolgono a noi rimangono sorpresi da quanto sia variegata la nostra offerta e dalle diverse pressioni a cui siamo sottoposti. Abbiamo pi\u00f9 di 50 progetti in produzione e oltre 70 cluster Kubernetes. \u00c8 sempre possibile fare di pi\u00f9. Si apre uno strumento, si disegna un'architettura a microservizi, si compila un elenco di 200 tecnologie 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, e dall'altro un alto livello di innovazione. E siamo orgogliosi di saperlo fare. Lo facciamo ovunque e su larga scala, 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 nel proprio staff.<\/b><\/p>\n
\u2014 (SB)<\/i> \u00c8 chiaro che i grandi attori, come Avito o Badoo, possono assumere un team di DevOps. Anche le piccole aziende con enormi investimenti possono farlo, ma \u00e8 certo che riescano a gestirlo.<\/p>\n
Crediamo che anche le grandi aziende dovrebbero rivolgersi a esperti che hanno esperienza in questo campo. Le piccole aziende, che basano il loro business su soluzioni web, devono assolutamente contattare persone esperte. Perch\u00e9 ogni errore in un sistema chiave significa perdita di denaro.<\/p>\n
\u2014 (DS)<\/i> Sappiamo che in Russia le persone temono l'outsourcing, per esperienze negative e altre ragioni. Ma i nostri clienti non ci abbandonano. Negli ultimi dieci anni, ci hanno lasciato solo per due motivi: o ci hanno superato (ad esempio, sono stati acquistati e tutto \u00e8 stato ristrutturato), oppure hanno chiuso perch\u00e9 l'idea non ha funzionato.<\/p>\n
E chi vi contatta pi\u00f9 spesso \u2014 piccole aziende o grandi?<\/b><\/p>\n
\u2014 (DS)<\/i> Ora sono uguali. Ma le piccole aziende ci temono, pensano che noi\u2026 <\/p>\n
\u2014 (SB)<\/i>\u2026 siamo grandi, complicati, inaccessibili e viviamo tra le nuvole. <\/p>\n
\u2014 (DS)<\/i> Beh s\u00ec, passi davanti a un salone con una Maybach e non entri, non chiedi il prezzo, perch\u00e9 non pu\u00f2 essere che una Maybach costi 500 mila rubli. <\/p>\n
Certo che non pu\u00f2.<\/b><\/p>\n
\u2014 (SB)<\/i> Ma una volta che appare nel car-sharing, ci si pu\u00f2 permettere di viaggiare con esso. <\/p>\n
\u2014 (DS)<\/i> S\u00ec, non siamo un Maybach \u2014 siamo Ikea. Anche noi abbiamo trovato un modo semplice, affidabile e accessibile. In effetti, il numero di aziende che si rivolgono a noi tra le TOP 50 e le piccole imprese \u00e8 lo stesso. Tuttavia, ci aspettiamo principalmente dal piccolo business e lavoriamo principalmente con loro, evitando di collaborare con le grandi aziende. <\/p>\n
\u2014 Perch\u00e9?<\/b><\/p>\n
\u2014 (DS)<\/i> Tanta burocrazia.<\/p>\n
\u2014 (SB)<\/i> In una grande azienda ci sono molti livelli in cui \u00e8 distribuita la responsabilit\u00e0, il feedback \u00e8 molto lento e spesso le persone iniziano a complicare le cose: \"Ehi, pianifichiamo, scriviamo una strategia, un piano per un anno avanti, facciamo meglio in questo modo, \u00e8 pi\u00f9 bello per la cultura enterprise, cos\u00ec \u00e8 andata la nostra prassi\". Cos\u00ec iniziano a complicare questioni che potrebbero essere risolte con una strada semplice e diretta, portando a risultati in 80% dei casi gi\u00e0 domani. Seguono una strada lunga, dove non \u00e8 chiaro se funzioner\u00e0. <\/p>\n
Di conseguenza, invece di pratiche consolidate, stiamo reinventando la ruota, e il costo della soluzione tecnologica diventa incomparabilmente pi\u00f9 alto. E la qualit\u00e0 non \u00e8 necessariamente migliore. <\/p>\n
\nQuota per l'esternalizzazione<\/h2>\n \n
Tutti i ragazzi dell'azienda contribuiscono in un modo o nell'altro \u2014 mediante feedback, documentazione o codice. Riteniamo che sia la nostra quota per l'intero universo delle utilit\u00e0 open source che utilizziamo. E penso che la contribuiamo in modo adeguato.<\/p>\n
Lo chiamiamo condensazione dell'esperienza. Inizialmente, una persona ha imparato qualcosa, l'ha condiviso con i colleghi, e quell'esperienza \u00e8 diventata folklore. Poi abbiamo registrato la documentazione e infine l'abbiamo trasformata in utilit\u00e0, dimenticando la sua esistenza, poich\u00e9 non dobbiamo pi\u00f9 pensarci \u2014 tutto \u00e8 considerato automaticamente.<\/p><\/blockquote>\n
Popolarit\u00e0 delle tecnologie e tossicit\u00e0 degli sviluppatori<\/h2>\n \n\u2014 Perch\u00e9 proprio Ubuntu? Prima di sceglierla, quali altre opzioni sono state considerate?<\/b><\/p>\n
\u2014 (DS)<\/i> Eravamo un gruppo di studenti appassionati di Linux. Abbiamo a lungo utilizzato Gentoo, un sistema operativo basato sul codice sorgente, che necessitava di una compilazione da zero ogni volta. Quando abbiamo aggiunto un paio di centinaia di server, gli aggiornamenti richiedevano mesi. Naturalmente, inizialmente abbiamo cercato di automatizzare e ottimizzare il processo, ma alla fine abbiamo capito che era necessario un cambiamento. Consapevoli dei pro e dei contro delle diverse soluzioni, abbiamo scelto semplicemente la pi\u00f9 popolare. All'epoca ci sembrava intuitivo: se era la pi\u00f9 popolare, presumibilmente sarebbe stata quella con maggiori sviluppi futuri, e tutti i difetti sarebbero stati sistemati prima o poi. <\/p>\n
C'\u00e8 stata una base di dati chiamata Resync DB. Competendo con MongoDB, \u00e8 nata all'incirca nello stesso periodo. Per un lungo periodo, Resync era tecnologicamente superiore.<\/p>\n
Quando gli utenti interagivano, cercavano di risolvere i problemi interni del sistema, e in MongoDB questi venivano affrontati molto meno. Era possibile, in teoria, inserire una condizione if per apparire migliori nei test sintetici. Di conseguenza, la popolarit\u00e0 di MongoDB cresceva. Nei casi pi\u00f9 semplici, mostrava prestazioni migliori, ma internamente era carente. Resync DB, invece, era solido internamente, ma non guadagnava popolarit\u00e0.<\/p>\n
Alla fine, per MongoDB \u00e8 andato tutto bene, ma di Resync DB nessuno ricorda nulla. L'azienda \u00e8 fallita. Con Ubuntu si pu\u00f2 dire che la storia \u00e8 simile. Questa distribuzione ha molti punti di forza, quindi abbiamo deciso di utilizzarla.<\/p>\n
\u2014 Come vi sembrano i recenti cambiamenti politici, il CoC e tutto il resto?<\/b><\/p>\n
\u2014 (DS)<\/i> Beh... non c'\u00e8 niente di negativo, tutto ok, tutto chiaro. A volte faccio fatica a non offendere le persone. Per me, alcune cose sembrano ovvie, e comincio a essere terribilmente frustrato dal fatto che le persone non lo capiscano. Mi arrabbio e questo porta a un clima negativo (ma ci sto lavorando).<\/p>\n
Linus \u00e8 molto intelligente, in fin dei conti, lavora in questo settore da 30 anni. \u00c8 chiaro che \u00e8 un tipo diretto, non ha peli sulla lingua. La sua cortesia ne risente, e la comunit\u00e0 sta lavorando su questo. Lui stesso lo comprende e lo riconosce. <\/p>\n
\u2014 Ma, da quanto ho capito dalla reazione nei dibattiti, molte persone supportano l'idea di parlare in modo diretto e deciso, e se a qualcuno non piace \u2014 non \u00e8 un problema, non si scioglieranno.<\/b><\/p>\n
\u2014 (DS)<\/i> No, non \u00e8 cos\u00ec. Come persona che soffre per la mancanza di cortesia, capisco che sia molto sbagliato. Questo rovina la comunit\u00e0. Ci sono persone che non ci badano, ma per la maggior parte delle persone \u00e8 comunque importante avere un comfort emotivo.<\/p>\n
Nel codice c'\u00e8 un errore stupido. Si potrebbe dire: \u00abRagazzi, \u00e8 brutto che trascuriamo queste cose semplici, dobbiamo correggerlo\u00bb. Oppure si potrebbe dire: \u00abQuale idiota ha fatto questo?!\u00bb. Una frase. La persona che ha commesso questo errore potrebbe essere anche pi\u00f9 intelligente ed esperta di te, ma semplicemente non era nel mood quando ha sbagliato \u2014 chiss\u00e0 cosa gli \u00e8 successo. E per lui sar\u00e0 un'offesa diretta. A cosa serve tutto questo?<\/p>\n
Bisogna dire le cose in modo diretto, ma non dire \u00abQuale idiota l'ha scritto\u00bb. Non ha senso nascondere e avvolgere, ma nemmeno offendere le persone.<\/p>\n
Perch\u00e9 i DevOps devono riunirsi ogni giorno?<\/h2>\n \n(DS)<\/i> Attualmente abbiamo un piccolo ufficio dove ci sono documenti e un office manager che si occupa di questi documenti.<\/p>\n
Nell'azienda ci sono 70 persone. 20 di loro fanno parte del team OPS. 30 persone sono distribuite in tre team DevOps di circa 10 persone ciascuno. Le rimanenti 20 sono sviluppatori e vendite. Ci sono 8 sviluppatori, mentre il reparto R&D ha 4 persone. Le persone non tecniche nell'azienda sono 5-6.<\/p>\n
Le squadre di DevOps generano denaro chiave. I processi sono sempre gli stessi: ogni giorno una lunga riunione, di un'ora o un'ora e mezza. Ma l\u00ec si discutono tutte le questioni tecniche e il team decide come procedere. E poich\u00e9 tutti sono in remoto, \u00e8 un'opportunit\u00e0 per comunicare bene.<\/p>\n
\u2014 \u00c8 davvero necessario farlo 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, si sentono a loro agio. Ma in alcuni giorni la riunione pu\u00f2 durare anche 30 minuti. Nonostante l'intensa comunicazione su Slack, desideriamo ancora sincronizzarci bene, capire cosa \u00e8 successo ieri. Vogliamo capireci a vicenda, non solo toccare le attivit\u00e0. Questo \u00e8 un aspetto culturalmente importante.<\/p>\n
\u2014 (SB)<\/i> In ogni momento potrebbe accadere qualcosa, la situazione potrebbe cambiare. \u00c8 necessaria una costante correzione. <\/p>\n
\u2014 (DS)<\/i> Hai una buona barzelletta su questo tema.<\/p>\n
\u2014 (SB)<\/i> S\u00ec. Un cardiochirurgo va in un centro di riparazione auto e il meccanico gli dice: \"Ascolta, facciamo entrambi la stessa cosa, solo che tu operi il cuore di una persona, mentre io \u2014 il cuore dell'auto. Tu guadagni 10.000$ per l'operazione, mentre io ne guadagno 100 per la manutenzione.\"<\/p>\n
Il chirurgo chiede: \u00abVuoi guadagnare anche 10 mila per la riparazione?\u00bb Il meccanico risponde \u2014 certo. Il chirurgo si siede in macchina, accende e dice \u2014 \u00abcomincia a lavorare\u00bb.<\/p>\n
Vale anche per noi. Nello sviluppo puoi prendere un compito e portare un risultato dopo due settimane. Poi si pu\u00f2 correggere tutto, perch\u00e9 avanti e indietro di tre giorni non influisce su nulla. <\/p>\n
Nel nostro caso, ogni avviso mancante o una decisione errata su un avviso pu\u00f2 trasformarsi in un grande problema. Per evitarlo, \u00e8 necessaria una comunicazione stretta, rapida e costante.<\/p>\n
\n\u00c8 difficile passare al lavoro remoto?<\/h2>\n \n\u00c8 complicato gestire persone a distanza. Ma \u00e8 difficile finch\u00e9 sei in un ufficio e loro in un altro, e c\u2019\u00e8 una certa confusione mentale. Sei seduto a Mosca e ti sembra che i ragazzi di Nizhny stiano lavorando male, in modo inefficace. A Mosca vedi gli sforzi delle persone intorno, ma non quelli dei remote workers. Prendi solo il risultato. <\/p>\n
In ufficio ci sono molte comunicazioni che avvengono in modo informale \u2014 qualcuno ha detto qualcosa a qualcuno per strada verso la cucina. Le persone nell'altro ufficio non lo vedono, non lo sentono, e il contesto si perde.<\/p>\n
Quando stavamo per rinunciare all'ufficio, tutte le comunicazioni (anche tra colleghi nella stessa stanza) avvenivano tramite Google Meet. E quando abbiamo organizzato tutta la comunicazione a distanza, ha funzionato al 100%, tutti i barriere di incomprensione sono state abbattute.<\/p>\n
Costruire tutto \u00e8 complicato, ma se si fa nel modo giusto \u2014 funziona e non crea alcun disagio.<\/p><\/blockquote>\n
Come i team gestiscono autonomamente le proprie finanze<\/h2>\n \n\u2014 Il lavoro da remoto \u00e8 una questione controversa. A volte le aziende temono di lasciare le persone a casa, pensando di perdere il controllo su di loro. Ma quelle che lo fanno dicono anche che bisogna lavorare in modo completamente diverso.<\/b><\/p>\n
\u2014 (DS)<\/i> Abbiamo risolto questo problema essendo pronti a condividere le finanze con i team. La nostra economia e il sistema di motivazione sono quasi costruiti come una franchigia. Gli stipendi sono abbastanza alti e in pi\u00f9 lasciamo ai ragazzi dei fondi liberi.<\/p>\n
Il team gestisce un pool di progetti. Sanno quanto ciascuno di questi progetti genera in termini di entrate. Sanno esattamente qual \u00e8 la loro quota di questi guadagni. Tutti i soldi che restano oltre i loro stipendi rimangono nel team e vengono distribuiti secondo un determinato sistema. La motivazione \u00e8 chiara: se acquisisci un ulteriore progetto da 200 mila, ognuno pu\u00f2 guadagnare di pi\u00f9. Se commetti un errore, devi compensare il cliente.<\/p>\n
\u2014 (SB)<\/i> Se inizi a deludere i ragazzi, si sente subito. Ti privi della possibilit\u00e0 di avere un reddito extra. Il nostro sistema risolve completamente il problema del controllo. Ogni persona si pianifica il giorno e le riunioni quotidiane sono sufficienti per capire chi fa cosa.<\/p>\n
\u2014 (DS)<\/i> In situazioni di conflitto, i compagni di trincea non mentono. <\/p>\n
\u2014 Quindi, avete stipendi aperti? Tutti sanno quanto guadagna ognuno? <\/b><\/p>\n
\u2014 (DS)<\/i> Abbiamo chiuso gli stipendi qualche tempo fa. Ci sono differenze regionali. Anche se puntiamo a pagare salari che corrispondano a quelli di Mosca anche nelle regioni, ci sono comunque delle discrepanze.<\/p>\n
\u2014 (SB)<\/i> Ora tutti sanno quanti soldi ha il team. Vedono quale quota di bonus ricevono. <\/p>\n
\u2014 (DS)<\/i> Il team leader di ogni gruppo decide quanto guadagneranno i suoi ragazzi e come verranno distribuiti i bonus. Noi interveniamo solo con consigli, la decisione finale spetta sempre al team leader.<\/p>\nPerch\u00e9 le persone temono le offerte di lavoro?<\/h2>\n
\nCelebrazione del decennale dell'azienda nel 2018.<\/i><\/p>\n
\u2014 Ti bastano 70 persone?<\/b><\/p>\n
\u2014 (DS)<\/i> No. Abbiamo in programma di assumere almeno 20 ingegneri DevOps quest'anno. Ma \u00e8 molto difficile. Abbiamo un numero sufficiente di candidati, tutti ci conoscono in un modo o nell'altro. Ma qui la situazione \u00e8 simile a quella con i clienti. Molti dicono: 'temiamo di lavorare con voi, potrebbe essere troppo difficile'. Ma non riteniamo che abbiamo qualcosa di cos\u00ec impossibile.<\/p>\n
Corrispondenza con il candidato.<\/i><\/p>\n
\u2014 Come bisogna essere per riuscire?<\/b><\/p>\n
\u2014 (DS)<\/i> Teoricamente, una persona dovrebbe essere equilibratamente sviluppata sia nello sviluppo che nelle operazioni. Nella pratica, sono casi rarissimi nel mondo, per non parlare della Russia. Soprattutto per quelli che sono senior in entrambi i settori. Non mi considererei nemmeno tra loro.<\/p>\n
Nei nostri annunci di lavoro scriviamo sempre chiaramente cosa \u00e8 necessario sapere. Lavoriamo molto su di essi e cerchiamo di scrivere in modo pertinente.<\/p>\n
\u2014 Forse gli annunci scoraggiano davvero, se \u00e8 specificato quanto si deve sapere?<\/b><\/p>\n
\u2014 (DS)<\/i> No, no, no, non crediamo che sia necessario sapere molto. <\/p>\n
\u2014 (SB)<\/i> Ci interessa non tanto la conoscenza, quanto il pensiero, la capacit\u00e0 di trovare soluzioni.<\/p>\n
\u2014 (DS)<\/i> Siamo interessati all'esperienza in Linux e la verifichiamo con compiti abbastanza semplici \u2014 semplicemente con una grande quantit\u00e0. Il nostro test \u00e8 piuttosto lungo, per un candidato medio dura 8 ore. Alla fine, valutiamo come la persona affronta i problemi, come cerca su Google e qual \u00e8 il suo panorama.<\/p>\n
Le conoscenze possono essere acquisite molto rapidamente qui, grazie ai diversi progetti e ai colleghi esperti che sono sempre pronti a dare un consiglio. Pertanto, ci concentriamo prima di tutto su ragazzi che possono riflettere rapidamente e hanno esperienza.<\/p>\n
\u2014 Oltre al test, lo scoprite in qualche modo?<\/b><\/p>\n
\u2014 (DS)<\/i> Abbiamo tre fasi. Inizialmente parla il reclutatore, chiedendo di raccontare l'esperienza. Poi, coloro che piacciono al reclutatore, svolgono un compito di prova. Alla fine, i team leader si confrontano e comunicano al reclutatore le loro opinioni; se sono tutti concordi nel giudizio positivo, \u00e8 un motivo per fare un'offerta alla persona.<\/p>\n500 mila rubli per assumere il futuro supereroe<\/h2>\n
\n\u2014 (DS)<\/i> Abbiamo un approccio molto non convenzionale alla finanza, condividiamo con i team e non siamo avari. Inoltre, diamo al team 500.000 rubli per espandere il personale. In altre parole, \u00e8 una sovvenzione, affinch\u00e9 possano trovare una persona e insegnargli tutto mentre si integra.<\/p>\n
\u2014 500.000 per persona?!<\/b><\/p>\n
Affinch\u00e9 il team guadagni molti soldi, deve prendere pi\u00f9 progetti. Per fare ci\u00f2, hanno bisogno di pi\u00f9 persone. E per assumere pi\u00f9 persone \u2014 servono pi\u00f9 soldi. \u00c8 un circolo vizioso. Per spezzare questo ciclo, diamo soldi per una nuova persona. Finch\u00e9 si integra, possono prendere altri progetti e gi\u00e0 con quei soldi pagargli lo stipendio. In altre parole, \u00e8 una compensazione finch\u00e9 il novizio non porta denaro. <\/p>\n
\u2014 Non \u00e8 troppo per i devops? Sono sotto pressione ogni giorno, continuamente in condizioni critiche, e devono anche occuparsi della gestione finanziaria.<\/b><\/p>\n
\u2014 (DS)<\/i> A occuparsene \u00e8 il team leader, e lui non \u00e8 propriamente un devops. I team leader tendono piuttosto a cercare partnership per avere opzioni. Quindi noi riteniamo che sia normale per loro. A i membri normali del team questo non riguarda.<\/p>\n
In sostanza, sanno che se un collega se ne va, il mese successivo ricevono il suo stipendio. Certo, dovranno lavorare di pi\u00f9. E quando trovano una sostituzione, restituiscono quei soldi. <\/p>\n
E quando diamo ai team leader 500.000, non vogliono assumere qualcuno che non abbia successo. A volte \u00e8 pi\u00f9 semplice scremare 20 persone e prenderne una. Ci sono stati casi in cui hanno parlato con 100 persone, 30 di loro hanno affrontato il compito tecnico, 20 sono stati selezionati, e il team leader ha scartato tutti tranne uno. \u00c8 davvero difficile. I team leader temono molto di rischiare. Ne abbiamo parlato e sembrava che tutti avessero capito che era un errore. Molte persone si presentano ai colloqui in un modo diverso rispetto a come lavoreranno poi. Quindi bisogna dare una possibilit\u00e0 e rischiare.<\/p>\n
\u2014 E i team leader non iniziano ad abusare? Ricevi 500.000, non assumi per molto tempo, e poi ricevi altri 500.000.<\/b> <\/p>\n
\u2014 (DS)<\/i> Ricevono denaro una volta sola. Diciamo - \u00abadesso avete dieci persone, ma ne servono undici. C\u2019\u00e8 un piano di vendita, arriveranno altri progetti e dovete essere pronti. Ecco 500 mila per la undicesima posizione\u00bb. Non lo riceverai di nuovo. E se qualcuno se ne va, \u00e8 gi\u00e0 un problema per il team, che dovr\u00e0 risolvere la questione entro il proprio budget. <\/p>\n
\u00c8 come una partita a Monopoli.<\/p>\n
\u2014 (SB)<\/i> Crediamo che il team leader debba essere a conoscenza delle finanze. I nostri dipendenti ricevono il loro stipendio dai soldi che guadagnano. E il livello di spesa per il progetto \u00e8 molto importante. Il cliente arriva con un'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 adeguatamente i costi di gestione.<\/p>\n
\u2014 (DS)<\/i> Capita che il team combatta per mesi con i problemi del cliente, capendo che vengono pagati per questo un importo simbolico di cento mila, e questo non corrisponde affatto a ci\u00f2 che sta accadendo. E per quanto possa far male, devono aumentare il prezzo o separarsi. E i ragazzi prendono queste decisioni da soli. Nonostante il fatto che siano tutti in remoto. E riteniamo che questo sia un nostro grande successo. Abbiamo veri team autonomi e motivati.<\/p>\n
\u2014 S\u00ec. E da questo sembra che per lavorare da voi bisogna essere Superman. Serve sia abilit\u00e0 tecniche che autodisciplina e alfabetizzazione finanziaria.<\/b><\/p>\n
\u2014 (SB)<\/i> Da noi si pu\u00f2 diventare Superman. Ma anche i team leader che riescono a farlo hanno iniziato come ingegneri comuni. Ci vogliono uno o due anni per trasformarsi in quel tipo di Superman.<\/p>\n
\u2014 I team leader partner sono cresciuti da ingegneri comuni. Possono essere assunti subito per una posizione del genere?<\/b><\/p>\n
\u2014 (DS)<\/i> Questo non \u00e8 mai successo da noi, tutti sono cresciuti come ingegneri. Ma stiamo valutando l'idea di unirci a una piccola azienda, che diventer\u00e0 semplicemente un'altra nostra squadra. Vorremmo provare qualcosa del genere.<\/p>\n
\u2014 Potete prendere una persona se \u00e8 un buon ingegnere, ma non abbastanza organizzata per il livello di tali squadre?<\/b><\/p>\n
\u2014 (DS)<\/i> Non abbiamo paura delle persone disorganizzate, abbiamo un flusso costante di compiti. Viene rapidamente evidente se possiamo aiutare una persona a organizzarsi. Se ogni giorno racconta cosa ha fatto, senza realmente fare nulla, si sentir\u00e0 in imbarazzo. <\/p>\n
Quando vedi che tutti remano nella stessa barca, \u00e8 scomodo smettere di remare. In queste condizioni, anche le persone disorganizzate diventano organizzate. Altrimenti, se non lo sono, non lo sono.<\/p>\n
Non tolleriamo affatto la superficialit\u00e0 \u2014 nelle persone, negli affari e in noi stessi. Arrivando qui, le persone si sviluppano rapidamente, tre volte pi\u00f9 velocemente rispetto a qualsiasi altro luogo. Qui realmente si fa esperienza e si acquisiscono competenze in un anno che equivalgono a tre. <\/p>\n
Non amiamo affatto i professionisti intermedi superficiali. Dal nostro punto di vista, un professionista intermedio \u00e8 qualcuno che ha gi\u00e0 molte capacit\u00e0. Dico la verit\u00e0 \u2014 il mercato DevOps \u00e8 estremamente confuso. Ci sono intermedi che si considerano junior. Ci sono junior che si considerano senior. Chi viene da noi capisce molto rapidamente il proprio reale livello.<\/p>\n
Questo non significa che non accettiamo junior \u2014 anzi, siamo felici di farlo e continueremo a farlo. Stiamo gi\u00e0 creando un team speciale chiamato \"DevOps-acceleratore\" e assegnando progetti in cui si pu\u00f2 rischiare, dove il cliente \u00e8 disposto a fare investimenti. Probabilmente, emerger\u00e0 anche un servizio speciale per questo. Un tipo di \"Flant-light\".<\/p>\n
\u2014 Vorreste diventare una grande azienda?<\/b><\/p>\n
\u2014 (DS)<\/i> Ci piacerebbe, ma con una riserva. Non vogliamo assolutamente perdere la nostra cultura. Siamo certi che cresceremo, ma mantenere la nostra cultura tecnica e lavorativa \u00e8 persino pi\u00f9 importante dello sviluppo stesso.<\/p>\n
La vita \u00e8 unica, non si possono guadagnare tutti i soldi del mondo, ma si vuole viverla accanto a persone meravigliose. Rifiutiamo categoricamente la burocrazia e la simulazione di lavoro utile. Noi abbiamo davvero relazioni orizzontali. \u00c8 possibile esprimere le proprie idee al management anche in modo molto diretto: il contenuto \u00e8 pi\u00f9 importante delle formalit\u00e0.<\/p>\n
\u2014 (SB)<\/i> Ma per questo \u00e8 necessario avere argomenti molto validi.<\/p>\n
\u2014 (DS)<\/i> Certamente! E il lavoro da remoto \u00e8 altrettanto necessario, perch\u00e9 \u00e8 cos\u00ec che viviamo, cos\u00ec vediamo il mondo. Dima Shurupov vive in Thailandia, io in Germania. Sasha Batalov a Mosca, il direttore HR a Tyumen. <\/p>\n
Crediamo che vivendo su questo pianeta, si voglia vivere la vita esplorandola. Non \u00e8 necessario vivere in condizioni dove andare al lavoro \u00e8 spiacevole. Pertanto, desideriamo che ci sia voglia di andare a lavoro. \u00c8 sicuramente sgradevole avere conflitti sul lavoro, quindi facciamo in modo che non ci siano conflitti. Abbiamo dei dibattiti e delle battaglie, ma non conflitti. <\/p>\n
\u2014 Non credi che diventare grandi significhi non solo fornire servizi, ma anche produrre? Che non basta semplicemente vivere e vedere il pianeta, ma \u00e8 necessario lasciare qualcosa?<\/b> <\/p>\n
\u2014 (DS)<\/i> \u00c8 un tema molto delicato per noi, perch\u00e9 siamo un'azienda di servizi. Ma sviluppiamo molto software, e in definitiva il nostro prodotto \u00e8 un servizio con un'efficacia completamente diversa. Non abbiamo mai venduto ore o persone a nessuno. I clienti venivano sempre e chiedevano: \"\u00c8 possibile acquistare cento ore?\" No, non \u00e8 possibile, noi non vendiamo ore. <\/p>\n
Noi vendiamo risultati. Il risultato \u00e8 che abbiamo alleviato il dolore, risolto un problema. E risolviamo non come ci \u00e8 stato detto, ma come sappiamo fare. Il nostro prodotto \u00e8 la nostra esperienza. E sicuramente realizzeremo soluzioni pronte, prodotti SaaS, abbiamo molte idee. Ma non c'\u00e8 fretta. Davanti a noi ci sono 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
![\"\u00abUn](\"\/wp-content\/uploads\/2019\/03\/0ee82b86e0cbe70d8a1aff2db82c47cd.png\")