In un mondo in cui solo la propria attività può renderti veramente ricco, le persone continuano a cercare lavoro dipendente. In primo luogo, non tutti sono felici di essere imprenditori, e bisogna pur vivere. In secondo luogo, sul posto di lavoro tutto è chiaro e sicuro: svolgi la tua funzione e la maggior parte dei rischi viene gestita da altri. Da qui derivano i conflitti di sempre: i proprietari vogliono che i dipendenti siano motivati come se il lavoro fosse la loro personale attività; i dipendenti desiderano semplicemente svolgere il compito per cui sono pagati e niente di più.
Questi classici rapporti hanno delle varianti — opzioni, percentuali, bonus — che ricordano un po' che proprietari e dipendenti sono nella stessa barca. Ma ci sono anche situazioni più atipiche.
L'azienda Flant è composta da diversi team di DevOps che gestiscono progetti di terzi chiavi in mano. Sono nati da un gruppo di studenti entusiasti e appassionati di Linux e ora hanno costruito una struttura di «aziende all'interno di un'azienda», semplicemente perché è più comodo e onesto. Dima Stolyarov e Sasha Batalov ci hanno spiegato come funziona.
Flant si è classificata tra i migliori datori di lavoro IT del 2018 con 4.68. Secondo le recensioni su ‘Myo Krug’, i dipendenti credono che l'azienda stia rendendo il mondo migliore e apprezzano Flant per le sfide interessanti, le buone relazioni all'interno del team, le tecnologie moderne e il rapporto con il top management.
Un gruppo di studenti appassionati di Linux
Dmitry Stolyarov (CTO) durante la sua presentazione
— (Dima Stolyarov) 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 — 'ufficio vero'. Poi abbiamo capito che a nessuno interessava. Era il 2006, avevo 19 anni. Solo nel 2012-13 è arrivata la consapevolezza di come fare business e quali tecnologie siano necessarie al mondo.
Alexander Batalov (CEO) allo stand dell'azienda durante la conferenza
— (Sasha Batalov) Oltre alle tecnologie, c'è un'enorme area di marketing, vendite ed economia, di cui nessuno ci ha mai parlato, tranne durante i corsi all'università, ma non so quanto siano realmente applicabili e utili.
Inizialmente pensavamo che tutto questo non fosse necessario, ma poi abbiamo dovuto imparare sul campo, leggere libri, a volte dopo aver già commesso degli errori. In generale, abbiamo percorso un lungo e difficile cammino, provando un sacco di cose sbagliate.
— (DS) Ma gradualmente, con l'aumento delle competenze, ci siamo specializzati sempre di più in Linux, e ora ci occupiamo solo di high-load e di progetti web ad alta intensità. E quando è arrivato Kubernetes, abbiamo capito rapidamente che era il fondamento di cui avevamo così tanto bisogno.
— Perché c'era tanto interesse per Linux? Ideologico o tecnologico?
— (DS) L'azienda ha due fondatori: Dima Shurupov e io. Dima Shurupov era più interessato all'open source. A me invece piaceva proprio Linux, per come è strutturato tecnologicamente. E così è 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 è sempre stata più importante.
Einstein diceva: «Si deve fare il più semplice possibile, ma non più semplice». Linux è costruito in modo così 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à 70. Per l'IT, per i servizi specializzati, è abbastanza.
— Com'era il periodo da studenti?
— (DS) Beh, come di solito accade agli studenti — divertente e vivace.
— (SB) Un'enorme quantità di altruismo, il desiderio di conquistare Internet, di raggiungere vette tecnologiche. Ci siamo tuffati in compiti molto complessi — 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.
— E dal punto di vista commerciale, tutto andava bene?
— (DS) Sì, 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.
— (SB) E io pensavo che per mille dollari si potesse fare qualsiasi sito tu potessi immaginare.
— (DS) Nel 2013 non avevamo soldi per assumere liberamente a Mosca. Tutti i conoscenti che potevamo prendere, li avevamo già presi. Abbiamo deciso di aprire un ufficio a Nizhny Novgorod. Siamo andati lì, abbiamo aperto, abbiamo iniziato a assumere. Poi abbiamo capito che vivere con due uffici era difficile e abbiamo deciso di vivere senza uffici.
Certo, abbiamo accumulato un sacco di cerotti. Solo nel 2016, con mio grande imbarazzo, ho letto Remote. Ho pianto e riso, perché avevamo percorso esattamente lo stesso cammino. Ogni paragrafo si sovrapponeva alla mia esperienza personale.
— (SB) In ogni paragrafo c'erano le nostre cicatrici.
Cosa fa Flant
Gestiamo produzioni ad alto carico chiavi in mano. Questo è diverso dal normale outsourcing, perché viviamo con i clienti a lungo e interagiamo molto da vicino, le persone ci affidano una delle loro cose più importanti. Il nostro modo di lavorare influisce notevolmente sul loro business.Per avere una gestione di qualità della produzione, servono 15-20 DevOps, specialisti in database, in Kubernetes, assistenza clienti e così via. E se l'azienda è piccola, dove gli sviluppatori sono solo una ventina, questo è impossibile. Ed eccoci qui, che arriviamo in soccorso. Per circa 150.000.
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 è rendere tecnologie a livello di Google e Facebook accessibili alle piccole imprese e alle startup in fase iniziale.
Le persone possono concentrarsi sul proprio prodotto, piuttosto che affrontare problemi che potrebbero essere evitati.
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ù di 50 progetti in produzione e oltre 70 cluster Kubernetes. È sempre possibile fare di più. 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.
La chiave è garantire da un lato la massima stabilità, affidabilità e semplicità, 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.
A chi servono i DevOps in outsourcing?
— Mi sembra che le grandi aziende preferiscano avere i DevOps nel proprio staff.
— (SB) È 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 è certo che riescano a gestirlo.
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é ogni errore in un sistema chiave significa perdita di denaro.
— (DS) 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 è stato ristrutturato), oppure hanno chiuso perché l'idea non ha funzionato.
E chi vi contatta più spesso — piccole aziende o grandi?
— (DS) Ora sono uguali. Ma le piccole aziende ci temono, pensano che noi…
— (SB)… siamo grandi, complicati, inaccessibili e viviamo tra le nuvole.
— (DS) Beh sì, passi davanti a un salone con una Maybach e non entri, non chiedi il prezzo, perché non può essere che una Maybach costi 500 mila rubli.
Certo che non può.
— (SB) Ma una volta che appare nel car-sharing, ci si può permettere di viaggiare con esso.
— (DS) Sì, non siamo un Maybach — 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 è lo stesso. Tuttavia, ci aspettiamo principalmente dal piccolo business e lavoriamo principalmente con loro, evitando di collaborare con le grandi aziende.
— Perché?
— (DS) Tanta burocrazia.
— (SB) In una grande azienda ci sono molti livelli in cui è distribuita la responsabilità, il feedback è 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, è più bello per la cultura enterprise, così è andata la nostra prassi". Così iniziano a complicare questioni che potrebbero essere risolte con una strada semplice e diretta, portando a risultati in 80% dei casi già domani. Seguono una strada lunga, dove non è chiaro se funzionerà.
Di conseguenza, invece di pratiche consolidate, stiamo reinventando la ruota, e il costo della soluzione tecnologica diventa incomparabilmente più alto. E la qualità non è necessariamente migliore.
Quota per l'esternalizzazione
Abbiamo molti progetti su GitHub, contribuiamo attivamente alla storia dell'open source. Non solo ai nostri — ma anche a quelli degli altri. Ci impegniamo a condividere gli strumenti che utilizziamo ogni giorno. Crediamo sia un nostro dovere e ci fa piacere farlo.Tutti i ragazzi dell'azienda contribuiscono in un modo o nell'altro — mediante feedback, documentazione o codice. Riteniamo che sia la nostra quota per l'intero universo delle utilità open source che utilizziamo. E penso che la contribuiamo in modo adeguato.
Lo chiamiamo condensazione dell'esperienza. Inizialmente, una persona ha imparato qualcosa, l'ha condiviso con i colleghi, e quell'esperienza è diventata folklore. Poi abbiamo registrato la documentazione e infine l'abbiamo trasformata in utilità, dimenticando la sua esistenza, poiché non dobbiamo più pensarci — tutto è considerato automaticamente.
Popolarità delle tecnologie e tossicità degli sviluppatori
— Perché proprio Ubuntu? Prima di sceglierla, quali altre opzioni sono state considerate?
— (DS) 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ù popolare. All'epoca ci sembrava intuitivo: se era la più popolare, presumibilmente sarebbe stata quella con maggiori sviluppi futuri, e tutti i difetti sarebbero stati sistemati prima o poi.
C'è stata una base di dati chiamata Resync DB. Competendo con MongoDB, è nata all'incirca nello stesso periodo. Per un lungo periodo, Resync era tecnologicamente superiore.
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à di MongoDB cresceva. Nei casi più semplici, mostrava prestazioni migliori, ma internamente era carente. Resync DB, invece, era solido internamente, ma non guadagnava popolarità.
Alla fine, per MongoDB è andato tutto bene, ma di Resync DB nessuno ricorda nulla. L'azienda è fallita. Con Ubuntu si può dire che la storia è simile. Questa distribuzione ha molti punti di forza, quindi abbiamo deciso di utilizzarla.
— Come vi sembrano i recenti cambiamenti politici, il CoC e tutto il resto?
— (DS) Beh... non c'è 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).
Linus è molto intelligente, in fin dei conti, lavora in questo settore da 30 anni. È chiaro che è un tipo diretto, non ha peli sulla lingua. La sua cortesia ne risente, e la comunità sta lavorando su questo. Lui stesso lo comprende e lo riconosce.
— 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 — non è un problema, non si scioglieranno.
— (DS) No, non è così. Come persona che soffre per la mancanza di cortesia, capisco che sia molto sbagliato. Questo rovina la comunità. Ci sono persone che non ci badano, ma per la maggior parte delle persone è comunque importante avere un comfort emotivo.
Nel codice c'è un errore stupido. Si potrebbe dire: «Ragazzi, è brutto che trascuriamo queste cose semplici, dobbiamo correggerlo». Oppure si potrebbe dire: «Quale idiota ha fatto questo?!». Una frase. La persona che ha commesso questo errore potrebbe essere anche più intelligente ed esperta di te, ma semplicemente non era nel mood quando ha sbagliato — chissà cosa gli è successo. E per lui sarà un'offesa diretta. A cosa serve tutto questo?
Bisogna dire le cose in modo diretto, ma non dire «Quale idiota l'ha scritto». Non ha senso nascondere e avvolgere, ma nemmeno offendere le persone.
Perché i DevOps devono riunirsi ogni giorno?
— (DS) Attualmente abbiamo un piccolo ufficio dove ci sono documenti e un office manager che si occupa di questi documenti.
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.
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ì si discutono tutte le questioni tecniche e il team decide come procedere. E poiché tutti sono in remoto, è un'opportunità per comunicare bene.
— È davvero necessario farlo ogni giorno?
— (DS) Sì.
— Tutti sono d'accordo su questo?
— (DS) Sì, tutti sono d'accordo, si sentono a loro agio. Ma in alcuni giorni la riunione può durare anche 30 minuti. Nonostante l'intensa comunicazione su Slack, desideriamo ancora sincronizzarci bene, capire cosa è successo ieri. Vogliamo capireci a vicenda, non solo toccare le attività. Questo è un aspetto culturalmente importante.
— (SB) In ogni momento potrebbe accadere qualcosa, la situazione potrebbe cambiare. È necessaria una costante correzione.
— (DS) Hai una buona barzelletta su questo tema.
— (SB) Sì. 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 — il cuore dell'auto. Tu guadagni 10.000$ per l'operazione, mentre io ne guadagno 100 per la manutenzione."
Il chirurgo chiede: «Vuoi guadagnare anche 10 mila per la riparazione?» Il meccanico risponde — certo. Il chirurgo si siede in macchina, accende e dice — «comincia a lavorare».
Vale anche per noi. Nello sviluppo puoi prendere un compito e portare un risultato dopo due settimane. Poi si può correggere tutto, perché avanti e indietro di tre giorni non influisce su nulla.
Nel nostro caso, ogni avviso mancante o una decisione errata su un avviso può trasformarsi in un grande problema. Per evitarlo, è necessaria una comunicazione stretta, rapida e costante.
È difficile passare al lavoro remoto?
È complicato gestire persone a distanza. Ma è difficile finché sei in un ufficio e loro in un altro, e c’è 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.
In ufficio ci sono molte comunicazioni che avvengono in modo informale — 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.
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.
Costruire tutto è complicato, ma se si fa nel modo giusto — funziona e non crea alcun disagio.
Come i team gestiscono autonomamente le proprie finanze
— Il lavoro da remoto è 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.
— (DS) 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ù lasciamo ai ragazzi dei fondi liberi.
Il team gestisce un pool di progetti. Sanno quanto ciascuno di questi progetti genera in termini di entrate. Sanno esattamente qual è 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 è chiara: se acquisisci un ulteriore progetto da 200 mila, ognuno può guadagnare di più. Se commetti un errore, devi compensare il cliente.
— (SB) Se inizi a deludere i ragazzi, si sente subito. Ti privi della possibilità 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.
— (DS) In situazioni di conflitto, i compagni di trincea non mentono.
— Quindi, avete stipendi aperti? Tutti sanno quanto guadagna ognuno?
— (DS) 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.
— (SB) Ora tutti sanno quanti soldi ha il team. Vedono quale quota di bonus ricevono.
— (DS) 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.
Perché le persone temono le offerte di lavoro?
Celebrazione del decennale dell'azienda nel 2018.
— Ti bastano 70 persone?
— (DS) No. Abbiamo in programma di assumere almeno 20 ingegneri DevOps quest'anno. Ma è molto difficile. Abbiamo un numero sufficiente di candidati, tutti ci conoscono in un modo o nell'altro. Ma qui la situazione è 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ì impossibile.
Corrispondenza con il candidato.
— Come bisogna essere per riuscire?
— (DS) 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.
Nei nostri annunci di lavoro scriviamo sempre chiaramente cosa è necessario sapere. Lavoriamo molto su di essi e cerchiamo di scrivere in modo pertinente.
— Forse gli annunci scoraggiano davvero, se è specificato quanto si deve sapere?
— (DS) No, no, no, non crediamo che sia necessario sapere molto.
— (SB) Ci interessa non tanto la conoscenza, quanto il pensiero, la capacità di trovare soluzioni.
— (DS) Siamo interessati all'esperienza in Linux e la verifichiamo con compiti abbastanza semplici — semplicemente con una grande quantità. Il nostro test è piuttosto lungo, per un candidato medio dura 8 ore. Alla fine, valutiamo come la persona affronta i problemi, come cerca su Google e qual è il suo panorama.
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.
— Oltre al test, lo scoprite in qualche modo?
— (DS) 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, è un motivo per fare un'offerta alla persona.
500 mila rubli per assumere il futuro supereroe
— (DS) 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, è una sovvenzione, affinché possano trovare una persona e insegnargli tutto mentre si integra.
— 500.000 per persona?!
Affinché il team guadagni molti soldi, deve prendere più progetti. Per fare ciò, hanno bisogno di più persone. E per assumere più persone — servono più soldi. È un circolo vizioso. Per spezzare questo ciclo, diamo soldi per una nuova persona. Finché si integra, possono prendere altri progetti e già con quei soldi pagargli lo stipendio. In altre parole, è una compensazione finché il novizio non porta denaro.
— Non è troppo per i devops? Sono sotto pressione ogni giorno, continuamente in condizioni critiche, e devono anche occuparsi della gestione finanziaria.
— (DS) A occuparsene è il team leader, e lui non è 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.
In sostanza, sanno che se un collega se ne va, il mese successivo ricevono il suo stipendio. Certo, dovranno lavorare di più. E quando trovano una sostituzione, restituiscono quei soldi.
E quando diamo ai team leader 500.000, non vogliono assumere qualcuno che non abbia successo. A volte è più 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. È 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à e rischiare.
— E i team leader non iniziano ad abusare? Ricevi 500.000, non assumi per molto tempo, e poi ricevi altri 500.000.
— (DS) Ricevono denaro una volta sola. Diciamo - «adesso avete dieci persone, ma ne servono undici. C’è un piano di vendita, arriveranno altri progetti e dovete essere pronti. Ecco 500 mila per la undicesima posizione». Non lo riceverai di nuovo. E se qualcuno se ne va, è già un problema per il team, che dovrà risolvere la questione entro il proprio budget.
È come una partita a Monopoli.
— (SB) 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 è molto importante. Il cliente arriva con un'infrastruttura, e dopo un anno la sua infrastruttura è dieci volte più grande. E se il team leader non partecipa alle finanze, non sarà in grado di valutare adeguatamente i costi di gestione.
— (DS) 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ò 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.
— Sì. E da questo sembra che per lavorare da voi bisogna essere Superman. Serve sia abilità tecniche che autodisciplina e alfabetizzazione finanziaria.
— (SB) Da noi si può 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.
— I team leader partner sono cresciuti da ingegneri comuni. Possono essere assunti subito per una posizione del genere?
— (DS) Questo non è mai successo da noi, tutti sono cresciuti come ingegneri. Ma stiamo valutando l'idea di unirci a una piccola azienda, che diventerà semplicemente un'altra nostra squadra. Vorremmo provare qualcosa del genere.
— Potete prendere una persona se è un buon ingegnere, ma non abbastanza organizzata per il livello di tali squadre?
— (DS) 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à in imbarazzo.
Quando vedi che tutti remano nella stessa barca, è scomodo smettere di remare. In queste condizioni, anche le persone disorganizzate diventano organizzate. Altrimenti, se non lo sono, non lo sono.
Non tolleriamo affatto la superficialità — nelle persone, negli affari e in noi stessi. Arrivando qui, le persone si sviluppano rapidamente, tre volte più velocemente rispetto a qualsiasi altro luogo. Qui realmente si fa esperienza e si acquisiscono competenze in un anno che equivalgono a tre.
Non amiamo affatto i professionisti intermedi superficiali. Dal nostro punto di vista, un professionista intermedio è qualcuno che ha già molte capacità. Dico la verità — il mercato DevOps è 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.
Questo non significa che non accettiamo junior — anzi, siamo felici di farlo e continueremo a farlo. Stiamo già creando un team speciale chiamato "DevOps-acceleratore" e assegnando progetti in cui si può rischiare, dove il cliente è disposto a fare investimenti. Probabilmente, emergerà anche un servizio speciale per questo. Un tipo di "Flant-light".
— Vorreste diventare una grande azienda?
— (DS) 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 è persino più importante dello sviluppo stesso.
La vita è 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. È possibile esprimere le proprie idee al management anche in modo molto diretto: il contenuto è più importante delle formalità.
— (SB) Ma per questo è necessario avere argomenti molto validi.
— (DS) Certamente! E il lavoro da remoto è altrettanto necessario, perché è così che viviamo, così vediamo il mondo. Dima Shurupov vive in Thailandia, io in Germania. Sasha Batalov a Mosca, il direttore HR a Tyumen.
Crediamo che vivendo su questo pianeta, si voglia vivere la vita esplorandola. Non è necessario vivere in condizioni dove andare al lavoro è spiacevole. Pertanto, desideriamo che ci sia voglia di andare a lavoro. È sicuramente sgradevole avere conflitti sul lavoro, quindi facciamo in modo che non ci siano conflitti. Abbiamo dei dibattiti e delle battaglie, ma non conflitti.
— Non credi che diventare grandi significhi non solo fornire servizi, ma anche produrre? Che non basta semplicemente vivere e vedere il pianeta, ma è necessario lasciare qualcosa?
— (DS) È un tema molto delicato per noi, perché siamo un'azienda di servizi. Ma sviluppiamo molto software, e in definitiva il nostro prodotto è un servizio con un'efficacia completamente diversa. Non abbiamo mai venduto ore o persone a nessuno. I clienti venivano sempre e chiedevano: "È possibile acquistare cento ore?" No, non è possibile, noi non vendiamo ore.
Noi vendiamo risultati. Il risultato è che abbiamo alleviato il dolore, risolto un problema. E risolviamo non come ci è stato detto, ma come sappiamo fare. Il nostro prodotto è la nostra esperienza. E sicuramente realizzeremo soluzioni pronte, prodotti SaaS, abbiamo molte idee. Ma non c'è fretta. Davanti a noi ci sono molti decenni.
Fonte: habr.com
