Banyak perusahaan IT besar lainnya memulai dengan startup, dan Badoo tidak terkecuali. Dalam beberapa tahun terakhir, perusahaan telah berubah dari beberapa lusin insinyur menjadi beberapa ratus. Nikolai Krapivny berada di garis depan pada sebagian besar jalan ini dan membuat keputusan: apa yang terbaik untuk dilakukan dan apa yang tidak boleh dilakukan, bagaimana mengatasi masalah. Laporannya tentang TeamLead Conf didedikasikan untuk pengalaman ini dan gambar dunia yang menghasilkannya.

Tentu saja, setiap perusahaan memiliki caranya sendiri , tetapi masalah komunikasi manusia kira-kira sama untuk semua orang. Pengalaman orang lain akan membantu Anda berpikir terlebih dahulu tentang masalah yang harus dihadapi pertumbuhan perusahaan. Bahkan jika nilai-nilai ini tidak secara langsung berlaku, itu akan memberi tahu Anda cara berpikir yang mana.



Ceritanya terdiri dari tiga bagian. Yang pertama adalah tentang komunikasi , tentang bagaimana mereka berubah dengan pertumbuhan perusahaan. Bagian kedua adalah tentang bagaimana, dengan peningkatan jumlah insinyur dalam tim, untuk mencoba mempertahankan kecepatan pengembangan . Dan bagian ketiga adalah mengapa Badoo tinggal di dua kantor , dan bagaimana cara mengatasi masalah komunikasi.

Ayo mulai!



Tentang pembicara: Nikolay Krapivny (@ cyberklin ) telah bekerja di Badoo selama delapan tahun terakhir, lima dari mereka terlibat dalam manajemen tim dan membangun proses pengembangan.


Sebelum menyelam ke bagian pertama, saya ingin mengatakan bahwa ini adalah kisah tentang jalan kami dan tidak mengklaim sebagai kebenaran absolut. Setiap perusahaan memiliki jalurnya sendiri, tetapi saya yakin bahwa pengalaman kami, nilai-nilai yang telah kami bentuk untuk diri kami sendiri, pengetahuan akan membantu Anda dalam pertumbuhan Anda, membantu Anda membangun proses yang tepat. Terlepas dari kenyataan bahwa Anda memiliki kekhususan yang berbeda, semuanya sedikit berbeda, saya harap ini akan bermanfaat bagi Anda.

Komunikasi

Untuk memulainya, mari kita bicara sedikit secara teoritis tentang apa yang terjadi pada komunikasi ketika perusahaan tumbuh.

Komunikasi adalah tentang bagaimana departemen berinteraksi satu sama lain, bagaimana orang berinteraksi satu sama lain, bagaimana komunikasi terjadi sehingga sesuatu dilakukan di perusahaan.

Pertimbangkan contoh yang agak basi, tetapi tetap vital: tim startup yang abstrak. Beberapa orang berkumpul, seseorang lebih dekat ke bisnis, dan seseorang yang lebih teknis. Tapi secara keseluruhan, ini adalah tim kecil yang melakukan sesuatu yang mungkin suatu hari nanti akan menjadi Facebook kedua. Dan di tim ini, semua pekerjaan dibangun di atas komunikasi. Tim ini kecil, dan tidak ada gunanya memperkenalkan proses apa pun. Semuanya berjalan seperti itu : seseorang berbicara dengan seseorang, mereka setuju untuk melakukan sesuatu dengan cepat, mereka melakukannya.

Terlepas dari kenyataan bahwa dalam proses, yang dibangun hanya berdasarkan komunikasi, pada percakapan: "Ayo lakukan," "Ayo lakukan lebih cepat," "Ayo lakukan seperti itu," ada masalah tertentu, tim seperti itu pasti memiliki kelebihan.

1. Pekerjaan cepat . Waktu dari sebuah ide hingga bagaimana ide ini tersedia bagi pengguna sangat kecil. Idenya datang, kami berbicara dengan seseorang bagaimana melakukannya lebih cepat, itu sudah dilakukan, sudah siap.
2. Itu fleksibel . Dalam tim kecil ini tidak ada hal seperti itu bahwa seseorang hanya terlibat dalam sesuatu yang spesifik, dan tidak dapat, jika perlu, terhubung ke tugas yang penting. Pada prinsipnya, semua orang melakukan segalanya, dan jika ada sesuatu yang penting bagi kami, maka setiap orang berusaha untuk melakukan ini.
3. Secara umum, karena kenyataan bahwa proses seperti itu belum dibangun, pekerjaan seperti itu cukup efektif . Kami tidak menghabiskan terlalu banyak waktu untuk biaya overhead, pada beberapa proses, pada beberapa skema formal yang dibangun.

Ini hanya nilai-nilai yang ingin dilihat oleh setiap bisnis: persamaan sumber daya yang paling fleksibel, waktu minimum ke pasar dan biaya operasi yang rendah.

Perusahaan ini tumbuh - komunikasi "sobek".

Ketika sebuah perusahaan tumbuh, keuntungan dari tim kecil, ketika semuanya bekerja dengan cepat, dalam interaksi, dalam percakapan, menjadi masalah. Beban komunikasi dari jumlah informasi yang ditransmisikan mulai bertambah, dan kita sampai pada kenyataan bahwa komunikasi itu “sobek” . Kita mulai kehilangan lebih banyak pada komunikasi daripada yang kita dapatkan. Kita perlu berbicara dengan terlalu banyak orang, di suatu tempat ada kesalahpahaman ketika mengirimkan informasi dari orang ke orang, di suatu tempat kita baru saja kehilangan sesuatu, di suatu tempat kita lupa. Dan segala sesuatu yang dibangun, yang memberi kecepatan, kita perlahan mulai kehilangan.



Jika Anda memperkirakan dan melihat model pengembangan perusahaan dalam interval waktu yang lama, maka itu terlihat seperti sebuah siklus. Jumlah orang bertambah, beban pada proses meningkat, komunikasi mulai terputus. Apa yang sebelumnya berhasil berhenti bekerja. Karena itu, kami terpaksa memperbaiki sesuatu di tempat-tempat ini. Seringkali ini terjadi di perbatasan departemen. Untuk memperbaikinya, Anda harus memformalkan proses komunikasi. Dan siklus ini berulang berkali-kali : jumlah orang bertambah, sesuatu mulai bekerja secara tidak efisien, kami memperkenalkan proses baru, entah bagaimana memformalkannya, kami mendapatkan pasokan baru untuk pertumbuhan hingga rusak di tempat lain dan seterusnya dan seterusnya. Ini seperti penskalaan suatu sistem, seperti kinerja: jika Anda menambah beban pada sistem - elemen terlemah, bagian paling lambat tidak akan tahan. Kami memperbaiki, entah bagaimana meningkatkan, sebuah jendela muncul di mana Anda dapat menambah beban pada sistem. Begitu juga dengan scaling perusahaan.

Itu adalah bagian teori pengantar kecil.

Sekarang mari kita lihat siklus apa yang kita lalui, masalah apa yang kita temui, dan bagaimana kita menyelesaikannya.

Kerangka Acuan

Sebagai contoh pertama, pertimbangkan tugas memformalkan hubungan antara bisnis dan tim teknik. Kerangka acuan, atau, demikian kami menyebutnya PRD, adalah permintaan untuk apa yang perlu diubah dalam hal fungsionalitas desain. Ini adalah formalisasi yang cukup jelas yang dilalui semua perusahaan. Saya pikir sebagian besar dari Anda bekerja di perusahaan di mana ada semacam proses formal untuk mentransfer tugas pengembangan. Dari tim produk, dari bisnis atau dari pelanggan eksternal - itu tidak masalah.



Kami mengalami beberapa bagian dari kerumitan proses ini. Awalnya kami baru aja. Ketika tim menjadi lebih besar daripada yang memungkinkan Anda melakukan bisnis hanya dengan berbicara di antara kami sendiri, kami mulai menulis semua ini dalam tugas. Tujuan dirumuskan sebagai "apa yang perlu dilakukan". Lebih lanjut, kompleksitas produk tumbuh, jumlah orang di perusahaan bertambah, dan kami sampai pada kesimpulan bahwa berguna untuk mempertahankan versi saat ini dari sistem kerja saat ini di satu tempat. Kami memindahkan semua ini ke Wikis, dan diskusi tentang perubahan pada komentar wiki sehingga semuanya ada di satu tempat. Langkah selanjutnya adalah memformalkan apa yang seharusnya dalam proses peninjauan PRD + PRD. Sekarang kami memiliki templat yang memperbaiki informasi apa yang harus ada dalam PRD, apa yang harus dijelaskan dan data apa yang harus dikumpulkan sebelum mulai bekerja. Misalnya, sekarang template PRD berisi blok berikut:

• Tujuannya, mengapa kita melakukan fungsi ini.
• Platform, produk, dan negara apa yang kami rencanakan untuk diluncurkan.
• Deskripsi fungsional dalam format kasus penggunaan: kasus utama + daftar "kasus rumit" yang telah ditetapkan sebelumnya yang dilupakan oleh semua orang.
• Token (diproses secara terpisah oleh copywriter).
• Komunikasi: apakah akan ada email / pemberitahuan push untuk fungsi ini, dan jika demikian, yang mana.
• Rencana rilis, tergantung pada pemasaran / proyek lain di perusahaan.
  
• Analisis: bagaimana kita akan mengevaluasi hasil, metrik bisnis mana yang perlu kita tambahkan untuk menilai keberhasilan perubahan.

Dengan demikian, dalam bentuk saat ini, interaksi antara produk dan tim teknis diformalkan cukup kuat dan membantu kita untuk tidak kehilangan beberapa poin penting dalam proses mentransfer tugas untuk bekerja.

Klien server

Kami tumbuh lebih jauh, pengembangan ponsel muncul dan menjadi salah satu bidang utama. Titik berikut muncul di mana komunikasi "terputus". Ini adalah titik di persimpangan antara klien dan server . Ini adalah tentang bagaimana klien harus berinteraksi dengan server di tingkat protokol, di tingkat hubungan. Ini diputuskan oleh percakapan antara orang-orang klien dan orang-orang server. Tetapi jumlah tim bertambah, jumlah orang di tim ini bertambah. Dan fakta bahwa informasi tentang interaksi klien dan server disimpan hanya di kepala pengembang mulai menimbulkan masalah.

Dokumentasi

Masalah yang kami temui cukup sederhana dan jelas. Hubungan klien-server tidak hanya protokol, tetapi juga skema komunikasi sesuai dengan protokol ini. Perintah apa yang harus dikirim dan kapan, bagaimana klien harus meminta sesuatu, bagaimana aplikasi dimulai - semuanya harus mengikuti protokol.

Misalnya, pengembang bagian klien menyelesaikan masalah dan percaya bahwa API memiliki perintah yang sesuai yang dapat dipanggil dan semuanya akan baik-baik saja. Klien ini dilepaskan dan menciptakan masalah di server, karena tim terlalu berat untuk itu dan membutuhkan terlalu banyak sumber daya. Selain itu, iOS dan Android memahami API sedikit berbeda, dan mengimplementasikannya dengan cara yang berbeda, karena itu kami tidak dapat dengan cepat membuat perubahan pada API. Jadi, kita sampai pada kesimpulan bahwa protokol perlu didokumentasikan.

Lepaskan tidak kembali

Keunikan platform seluler adalah bahwa rilis tidak dapat dikembalikan. Jika aplikasi diletakkan di toko dan pengguna telah menginstalnya, maka kemungkinan besar akan memakan waktu yang sangat lama untuk hidup dengan versi klien ini. Kesalahan pada tahap merancang protokol, pada tahap menentukan interaksi antara klien dan server, sayang. Di Badoo untuk satu atau dua tahun lagi , kami harus mendukung aplikasi apa pun yang dirilis hingga jumlah pengguna turun hingga batas tertentu.



Untuk mengatasi masalah ini, kami memutuskan untuk mengalokasikan tim MAPI terpisah, yang akan mendokumentasikan protokol, dan akan menjadi titik pertukaran pengetahuan antara klien dan server . Tim ini mencakup karyawan dari pengembangan klien dan server. Tim campuran ini mengubah persyaratan produk menjadi memodifikasi protokol dan dokumentasinya. Karena kesalahan pada tahap implementasi protokol cukup mahal bagi kami, proses dalam tim ini sedikit lebih rumit dan lebih sulit daripada yang lainnya. Mereka menggunakan tinjauan kode ganda, berusaha menghilangkan kemungkinan kesalahan sebanyak mungkin.

Tim ini dengan cepat menjadi pusat untuk berbagi pengetahuan. Seringkali ada situasi ketika pengembang klien dan server tidak bisa sepakat tentang bagaimana mereka harus berinteraksi. Misalnya, iOS mungkin satu-satunya cara, tetapi untuk Android itu tidak cocok. Tim baru menyelesaikan masalah kontroversial ini dan, jika perlu, mengumpulkan orang yang tepat untuk membuat keputusan yang tepat.



Jika Anda melihat diagram proses kami, maka tim Mobile API adalah tautan perantara antara saat persyaratan siap dan kapan pengembangan dimulai. Itu adalah:

• dari tim produk menerima tugas mengembangkan TK (PRD);
• tim desain protokol menyusun dokumentasi;
• pengembangan bagian klien dan server sesuai dengan dokumentasi dimulai.

Dengan proses seperti itu, pengembangan server dan klien dapat berjalan secara mandiri, dan kami sering menggunakannya.

Masalah statistik

Perusahaan terus tumbuh dan berkembang, ada lebih banyak orang dan proyek. Perlahan, kami sampai pada titik bahwa tim terpisah telah muncul yang berhubungan dengan data, statistik, dan membantu tim produk menganalisis bagaimana pengguna merespons perubahan. Seperti yang saya katakan, masalah muncul di persimpangan tim . Kami memiliki tim baru, dan setelah beberapa saat sendi ini juga mulai bekerja secara tidak efisien.

Faktanya adalah bahwa analis memerlukan data yang baik untuk mengidentifikasi pola dan menjawab pertanyaan produk yang rumit. Data yang baik berarti bahwa semua statistik harus berada di bawah satu bahasa. Ketika kita berbicara tentang statistik dan tentang produk kita, kita perlu berbicara satu bahasa.

Sebelum ini, dalam setiap tugas teknis, manajer produk menjelaskan prinsip pengumpulan statistik dengan kata-kata: untuk tombol ini, Anda perlu mengukur rasio klik, untuk layar ini - konversi. Tetapi kemudian pengembang sendiri yang memutuskan acara mana yang akan dilacak, bagaimana mengukur (dari klien atau server), grafik mana yang akan digambar, dan misalnya, bagian mana yang akan ditambahkan ke acara tersebut. Pengembang dapat membuat grafik dipotong berdasarkan jenis perangkat, menambah jenis kelamin, mengumpulkan statistik berdasarkan negara. Data yang berbeda ini datang ke departemen analitis, tetapi atas dasar mereka tidak mungkin untuk secara akurat menilai kualitas solusi dalam produk. Sebagai akibatnya, poros tugas terbalik muncul: kami melakukan perubahan, perubahan ini diterapkan, manajer produk meminta analisis, tim statistik meminta data tambahan, tugas berjalan untuk revisi, statistik sedang difinalisasi, kami menunggu lagi ... Ini memperpanjang siklus produk dan ini menjadi masalah bagi kami.

Proses pengumpulan dan analisis statistik perlu diformalkan.



Kami memutuskan bahwa persyaratan untuk statistik akan dicatat dalam Kerangka Acuan, dan pemilik pengetahuan tentang persyaratan tersebut akan menjadi analis. Analis, pada tahap mentransfer pekerjaan pada TK untuk pembangunan, mengatakan statistik apa yang dibutuhkan, peristiwa apa yang harus dilacak, oleh irisan apa untuk memecah data. Jika analis meminta untuk memperluas statistik yang ada atau menambah yang baru, maka kami menambahkan fungsionalitas baru atau memodifikasi yang sudah ada. Untuk melakukan ini, kami meresmikan bekerja dengan data dalam kode. Kami membuat API tunggal, yang tidak memungkinkan pengiriman data yang tidak memadai atau data yang tidak valid.

Secara paralel, dari sudut pandang alat, kami memiliki alat Microstrategy cepat untuk visualisasi data dan alat kami sendiri untuk pengujian A / B. Pemilik semua pengetahuan tentang cara menggunakan alat ini dengan benar adalah analis.



Tahap lain ditambahkan ke diagram proses. PRD melewati tahap koordinasi di departemen analitik, dan hanya setelah itu dipindahkan ke MAPI dan pengembangan. Jadi itu berfungsi sekarang.

Muat pembagian

Masalah selanjutnya terkait dengan peningkatan beban dan interaksi dalam satu departemen. Saya memimpin tim pengembangan backend untuk produk-produk kami, dan pada contohnya saya akan menggambarkan masalah apa yang muncul dengan peningkatan jumlah karyawan dalam satu tim.



Dalam tim yang terdiri dari hingga 15 orang, semuanya cukup sederhana. Kami percaya bahwa semua orang melakukan segalanya dan mendistribusikan tugas terutama berdasarkan siapa yang bebas sekarang - itulah yang dia lakukan. Mengapa sampai 15?

Diyakini bahwa satu atau pemimpin tim atau pemimpin teknis harus memimpin tim yang terdiri dari hingga 7 hingga 9 orang. Ini adalah jumlah bawahan yang cukup secara empiris.

Kami memiliki pemimpin tim dan wakilnya, jadi bersama-sama kami mengendalikan 14-15 orang. Dengan pertumbuhan lebih lanjut, beberapa divisi tambahan menjadi perlu. Alur tugas pembangunan harus seimbang. Kami telah mengidentifikasi persyaratan utama untuk proses ini: kami membentuk spesialisasi . Setiap bagian dari kode akan memiliki pakar, 1-2, dan lebih disukai 3, yang paling tahu kode ini dan yang mendukung kode ini. Tetapi pada saat yang sama, ada persyaratan ortogonal: untuk mempertahankan fleksibilitas . Misalnya, jika lima orang mendukung pembawa pesan, dan terlalu banyak tugas mendesak telah tiba, maka mereka tidak boleh menganggur. Jika tim memiliki sumber daya gratis, mereka harus dimasukkan dalam kinerja tugas orang lain. Persyaratan ini saling bertentangan, tetapi kami masih ingin mencoba untuk mencapai ini.



Kami membagi tim besar menjadi kelompok pengembangan yang terdiri dari 4-9 orang. Di kepala masing-masing kelompok adalah pemimpin teknis dan dia adalah pemimpin langsung tim. Kami memperkenalkan konsep seperti itu sebagai komponen. Komponen adalah bagian dari kode yang diselesaikan dalam hal fungsi produk. Setiap komponen ditugaskan ke grup tertentu. Setiap komponen dalam grup memiliki 1-2-3 orang yang ahli dalam bagian ini, dan terlibat dalam pengembangan dan dukungannya.

• Dalam hal pembagian beban, setiap tugas memiliki komponen.
• Tugas-tugas hutang teknis dan dukungan didistribusikan dalam kelompok "pribumi" - yang menjadi tugas komponen ini.
• Kami mencoba mendistribusikan fungsionalitas baru di grup "asli". Tetapi hanya jika kita memiliki kesempatan seperti itu.
• Untuk menjaga fleksibilitas, kami tidak mengecualikan situasi di mana satu kelompok membantu yang lain dan melakukan sesuatu yang tidak terhubung dengan komponen-komponennya.
• Dalam hal ini, baik penugasan penugasan teknis atau peninjauan kode dilakukan - ini dilakukan oleh kelompok "asli".

Dalam opsi ini, kami sedang bekerja sekarang. Tim ini memiliki 30 orang, 5 kelompok, dan 22 komponen yang kami bagikan di antara mereka. Meskipun kami tidak melihat batas untuk pertumbuhan lebih lanjut dalam format ini, kami akan mematuhinya pada skala tertentu.



Efek samping yang menarik: apa yang terjadi dalam tim ketika jumlah proyek, jumlah orang, jumlah perubahan tumbuh cukup kuat. Kita dihadapkan dengan fakta bahwa ada begitu banyak jumlahnya sehingga sulit untuk memahami alasan spesifik untuk suatu perubahan.

Saya akan memberikan contoh pertumbuhan dalam pendaftaran pengguna baru di Brasil. Alasannya mungkin: bot spam yang mendaftarkan akun baru dan merusak kehidupan kita; masalah dengan sesi; hanya kampanye promosi; peluncuran gelombang pemasaran baru di Brasil. Perubahannya terlihat pada grafik, dan kami ingin memahami dengan sedikit usaha apa yang terjadi.



Kami membuat sendiri alat yang disebut WTF. Ini adalah salah satu alat yang mengumpulkan sendiri dari semua jenis subsistem dan bagian-bagian produksi sesuatu yang entah bagaimana dapat mempengaruhi metrik. , . , (, ), ( ).



: — , - . .

:

• . .
• , .
• , , — .
• .

:

• .
• BI, ;
• MAPI .
• , — .

200 . , , . , :)

. , , .



Time-to-marker . .



. , , , - . , , .



: . , , . - . . : — . . , , . , .

-, , . - .

• . - . .
• . 10 , . : . . .
  
• - . bus- , . , , , .
  

, ( — ), . , OX . . OY .

, .



. - — . - , time-to-market , . - , , - , - , . , , . .



. - . , , . . , workflow. (, ) . - . , , .



, . , , , . , — . . — 2 , . , . , , . - - , - , .

. , , .



70–80 . , , . , . , - , .



.

— , - — .

, . , , - , , — - . , , — . .

—

, , . , . , .



. , . , , , . , - , , , server-side , . , , - , . , server-side, , . 14 , . - , server-side. , server-side 50/50. , , , . , , , - , , . , , .



.

— , . , , - , , .

. , , , , . « ».

. , — , , , . 50/50 10- .



, — . , . , 3 . - , 12 . 3 — , . , , , , , , , - , . — . . 11:00, — 9:00. , .

, — , 2 , , . , — , , - , -, , . , - , .



, , « ». - , , - . :

• : — , ..
• Mentor - peran operasional, jangka pendek, pada kenyataannya, itu adalah: "Saya akan mengajari Anda untuk bertarung sekarang." Bagaimana berperilaku untuk menyelesaikan masalah saat ini.

Peran strategis dapat dilakukan dari jarak jauh dengan beberapa kunjungan dan percakapan berkala, karena itu strategis dan tidak perlu ada intervensi konstan dalam pekerjaan. Peran mentor, manajemen operasional, cukup sulit untuk dilakukan dari jarak jauh. Oleh karena itu, bagi kami sendiri, kami telah mengembangkan aturan bahwa untuk semua karyawan muda, baru, pendampingan teknis terjadi secara lokal. Ada beberapa orang dalam tim yang mengambil tanggung jawab seorang pemimpin yang membimbing orang tersebut dalam masalah yang muncul secara lokal. Dalam hal ini, pemimpin masih dapat melakukan pekerjaan yang berkaitan dengan pertumbuhan strategis seseorang.



Tidak ada yang membatalkan fakta bahwa Anda hanya perlu bertemu lebih sering . Semuanya standar di sini:

• Kami melakukan perjalanan bisnis satu sama lain. Bertemu tentang pekerjaan desain.
• Sekali seperempat ada tinjauan kinerja. Semua manajer yang memiliki bawahan di kantor lain harus datang untuk berbicara satu lawan satu. Tetap saja, berbicara melalui konferensi video sama sekali tidak seperti berbicara langsung dengan seseorang.
• Karyawan baru harus mengunjungi kantor yang berbeda - untuk mengenal satu sama lain, melihat cara kerja tim lain, mengenal seorang manajer produk untuk seorang insinyur, atau sebaliknya.
• Kami melakukan pertemuan kelompok. Departemen ini dibagi menjadi beberapa kelompok, dan masing-masing kelompok berkumpul bersama sekali seperempat. Apalagi di berbagai kota pada gilirannya. Pertama, satu kelompok berkumpul di Moskow, para karyawan melakukan sesuatu bersama, entah bagaimana berinteraksi, melalui semacam pembangunan tim.
• Sekali setahun kami mencoba melakukan pertemuan umum departemen dalam suasana informal. Biasanya ini adalah akhir pekan di mana Anda dapat melakukan sesuatu yang bermanfaat, membahas masalah, tetapi pada saat yang sama hanya berbicara "seumur hidup". Sangat membantu untuk merasa bahwa kita sedang melakukan satu hal yang sama.

Kami juga memiliki acara untuk seluruh perusahaan, yang disebut "All Hands". Sekali seperempat, semua karyawan perusahaan berkumpul, dan seseorang berbicara tentang apa yang telah kita capai belakangan ini. Untuk mengurangi jarak antar kantor, pertemuan ini diadakan di Moskow atau di London. Dalam seperempat, setiap orang yang seharusnya berbicara datang ke Moskow, dan sebuah konferensi video berlangsung di London. Kuartal berikutnya, sebaliknya, ada pertunjukan di London, dan di Moskow, hanya konferensi video.

Begitulah cara kami hidup di Badoo.

Kami mengundang Anda untuk memata-matai bagian baru dari pengalaman organisasi orang lain di Saint TeamLead Conf . Program ini mencakup pidato dari perusahaan yang sangat terkenal: Sberbank-Technologies, Avito, JetBrains, Spotify ... ya mereka semua keren!

Laporan ini adalah satu dari lusinan laporan, jika Anda tidak ingin menunggu sampai kami dapat mendekripsi dan mempublikasikannya di Habré, kemudian tonton daftar putar konferensi di saluran YouTube kami.

Agar tidak ketinggalan apa pun, berlanggananlah milis khusus. Kami mencoba menghemat waktu Anda dan menerbitkan berita bermanfaat: ulasan transkrip, video terkini, laporan terpilih dari konferensi mendatang.