Get best of the week

Bagaimana seorang insinyur tumbuh menjadi techlida

Siapa pemimpin tim, arsitek atau QA dan apa yang mereka lakukan, dalam TI, hampir semuanya dibayangkan. Tetapi dengan pemahaman tentang siapa ahli teknis itu, apa yang dia bertanggung jawab dan bagaimana menjadi satu, kesulitan muncul. Kami melakukan lusinan wawancara dengan spesialis dari perusahaan besar dan mengetahui bahwa ini adalah insinyur yang memulai proses: menghubungkan orang-orang dan alat-alat dengan tujuan organisasi. Dia mengambil inisiatif dan tanggung jawab untuk pengembangan teknologi produk dan peduli terhadap kualitas solusi teknis. Selain itu, kualitas tidak hanya pengujian, tetapi arsitektur, desain, praktik dan eksperimen teknik, bekerja dengan hutang teknis dan peningkatan teknis perusahaan secara keseluruhan.



Kami juga menemukan bahwa ada banyak konferensi untuk techlides. Tapi hampir semuanya fokus pada alat, bukan praktik dan proses rekayasa. Itulah mengapa kami meluncurkan konferensi TechLead Conf 2020 Online yang baru - bagi mereka yang ingin menjadi pakar teknis dan memahami kualitasnya. 

Di TechLead Conf 2020 Online, pertanyaan kedua adalah "Alat teknis apa yang digunakan untuk menyelesaikan masalah?". Konferensi ini adalah untuk mereka yang berjuang untuk kualitas solusi teknis dan bertanggung jawab atas pengembangan teknologi produk. Dari 8 hingga 10 Juni, kami akan mempelajari pengalaman menerapkan dan menggunakan praktik, teknologi, dan manajemen proses di perusahaan. Kami akan memberi tahu Anda lebih banyak tentang program ini dan apa yang akan kami bicarakan di acara tersebut.

Program singkat


Program TechLead Conf 2020 Online beranjak dari membahas pengembangan techlide ke penerapan DDD dan terdiri dari beberapa blok.

  • Memetakan pengembangan teknis . Masih ada sedikit pemahaman tentang siapa ini dan apa fungsinya. Dan pertanyaan-pertanyaan tentang bagaimana tumbuh menjadi techlide dan apa yang seharusnya dapat dilakukan semakin jarang ditanyakan, jadi pada blok pertama kita akan membahas siapa itu dan bagaimana menjadi satu. 
  • . — , -, « ». , — : , . « ». , MVP.
  • Efek praktik rekayasa yang tertunda . Dalam bekerja dengan kode, umpan baliknya cepat: ditulis, diuji, disebarkan, berfungsi. Namun di dunia teknis, hasil karyanya baru terlihat setelah berbulan-bulan. Oleh karena itu, kami menambahkan laporan pada semua tahap siklus hidup praktik rekayasa: munculnya ide, MVP, pencegahan kesalahan dan pengukuran hasil setelah peluncuran yang sukses pada kasus nyata.

Juga diskusikan: 


Kami akan memberi tahu lebih detail tentang setiap blok dan melaporkannya.

Peta Pengembangan Techlide


Tehlid adalah peran seorang insinyur yang mengelola proses. Biasanya, ini adalah insinyur setidaknya senior: pengembang, arsitek, otomatisasi, SRE, CTO lebih jarang. Terkadang mereka bisa menjadi pemimpin tim. Tetapi pemimpin tim membangun tim, mengelola orang dan perkembangan mereka.
Tehlid membangun proses: membuat keputusan teknis yang memengaruhi pengembangan produk dalam menghadapi ketidakpastian.
Oleh karena itu, konferensi tidak akan memiliki laporan tentang manajemen dan motivasi orang, tetapi hanya topik tentang manajemen teknologi, kepemimpinan teknis dan pembangunan proses rekayasa. Dan hal pertama yang harus dipelajari adalah bagaimana menjadi techlide yang baik.

Keberhasilan perusahaan tergantung pada ketersediaan spesialis yang kuat. Kami telah menggambarkan bagaimana techlide berbeda dari profesi lain, dan Vladimir Gorovoy , Manajer Produk Ilmu Data di Yandex.Verticals , memberi tahu Vladimir Gorovoy tentang perbedaan antara techlide yang baik dari profesi lain . Dari laporan “ Bagaimana Menjadi Techlide yang Baik»Cari tahu di mana memulai pengembangan kami, keterampilan dan kualitas apa yang harus dipompa. Vladimir akan berbagi pengalamannya yang kaya dalam berpartisipasi dalam pembuatan Yandex.Travel, Yandex.Real Estate dan proyek Yandex.Market untuk mengilustrasikan tesis.

Semakin kuat keterampilan, semakin mudah untuk mengatasi tugas Anda. Tetapi rasa sakit tidak pergi ke mana pun - mereka hampir sama untuk semua techlide.

  • Menulis kode atau terlibat dalam strategi pengembangan teknologi untuk produk dan tim?
  • Selesaikan sendiri masalah teknis yang rumit atau delegasikan?
  • Bagaimana tidak terpecah antara penulisan kode kualitas dan fitur peluncuran?

Konflik ini dan lainnya akan diselesaikan oleh Evgeny Korytov . Dalam laporan " Masalah teknologi teknis dan bagaimana menyelesaikannya? "Eugene akan memberitahumu bagaimana cara mengatasi tugas dan masalah para pemimpin, dengan bantuan kerangka kerja yang" memecahkan masalah. "

Menggabungkan bisnis dan pengembangan


Mempertahankan kode berkualitas tinggi dan membuat keputusan teknis yang tepat bukanlah keseluruhan pekerjaan. Anda juga harus terus membuktikan kepada bisnis dan pelanggan kebutuhan untuk menginvestasikan waktu dan energi dalam tugas arsitektur dan teknis. Alexey Deryushkin dari Better Life Company tahu dari pengalaman seperti apa itu: 15 tahun kepemimpinan tim dan 5 tahun pengalaman konsultasi. Dalam laporan " Cara 'Menjual' Tugas Teknis ke Bisnis ", ia akan menunjukkan cara melakukan dialog dengan bisnis untuk membuat fitur keren dan tidak melupakan kualitas menggunakan contoh kehidupan.

Perjuangan antara bisnis dan pengembangan merupakan masalah standar dalam proyek-proyek TI. Seringkali bisnis tidak memiliki TK, tetapi hanya "ide" dan permintaan. Ini mengarah pada keputusan yang salah yang harus diperbaiki selama berbulan-bulan atau dipertahankan selama bertahun-tahun dengan tongkat penyangga. Bagaimana menemukan keseimbangan antara pengembangan dan bisnis, Arthur Dementyev akan berbagi dalam laporan " Antara Dua Lampu: Pengembangan dan Bisnis ". Arthur di bidang TI sejak 2009, pada contoh cerita dari praktik, akan mengilustrasikan pendekatan yang berbeda untuk implementasi fitur MVP.

Ketika bisnis dan pengembangan telah sepakat, sekarang saatnya untuk melanjutkan ke tahap berikutnya. Sekarang techlide memiliki beberapa bulan untuk memperkenalkan produk baru. Paling sering, dalam situasi seperti itu produk uji hipotesis kerja minimum (MVP) dibuat. Segera setelah pengujian, kode prototipe dibuang dan aplikasi tersebut ditulis "sebagaimana mestinya." Tapi apa yang harus dilakukan ketika peluncuran uji berhasil, dan pengguna nyata sudah tinggal di "kerajinan"? Kami belajar dari Maxim Arshinov dari laporan " Cara meluncurkan MVP dan tidak mengubahnya menjadi utang teknis ".

Kami memilih dan menerapkan praktik rekayasa


Selalu sulit untuk menerapkan sesuatu yang baru, MVP, PL atau kerangka kerja yang sama. Kebaruan mungkin berubah menjadi "mentah" dan tidak memenuhi harapan. Cara membuat pilihan yang tepat dan “ Memperkenalkan teknologi baru dan tidak membuang-buang semua polimer, ” kata Pavel Mineev , pemimpin tim dari Rocketbank.

Untuk pengenalan produk baru, optimal untuk menggunakan tata kelola sebagai pendekatan kode. Dengan pendekatan ini, semua aturan memiliki siklus hidup mereka sendiri, mereka dapat diuji dan tidak berbeda dari produk perangkat lunak biasa. Dari laporan Alexander Tokarev “ Tata Kelola sebagai kode: bagaimana mematuhi standar pengembangan dan tidak memperlambat penyampaian fitur»Kami mempelajari cara menerapkan pendekatan ini: bagaimana dan apa yang harus diperiksa selama proses pengembangan perangkat lunak, bagaimana pendekatan ini memungkinkan Anda untuk mengembangkan aplikasi yang lebih aman dan berkualitas tinggi. 

Ketika standar diterapkan, saatnya untuk mengujinya, misalnya, pada skala besar - untuk membuat platform teknologi. MTS adalah perusahaan IT besar yang mengimplementasikan proyek-proyek dari telemedis ke IoT. Setiap proyek baru merangsang permintaan untuk yang berikut dan mengurangi biaya pembuatannya. Ini hanya dimungkinkan melalui penerapan praktik rekayasa terbaik. Tetapi ada kesulitan: ratusan tim dengan tingkat dan proses yang berbeda, warisan, kebutuhan untuk "menjual" ide-ide ke bisnis. Bagaimana perusahaan mengatasi tugas-tugas ini, kita belajar dari laporan " Apa yang harus kita buat platform teknologi?" Panduan langkah demi langkah dari ide hingga implementasi . " Menceritakan Rahasia Philipp Bocharov- Manajer Proyek untuk Pengembangan di MTS IT.

Setelah pemilihan dan implementasi praktik-praktik teknik, pekerjaan baru saja dimulai - Anda perlu mengevaluasi hasilnya. Ini akan membantu metrik: penting untuk memahami tidak hanya apa yang terjadi dengan infrastruktur dan perangkat keras, tetapi juga bagaimana masing-masing fitur bekerja, untuk menemukan kemacetan dan menghapusnya dalam waktu. Laporan " Atur pemantauan dan apa selanjutnya?" » Mikhail Mazein akan membagikan metrik pada contoh ManyChat - platform tempat sejuta bisnis aktif berkomunikasi dengan 800 juta pelanggan mereka. Apa yang harus dipertimbangkan:

  • cara bekerja dengan metrik di bawah beban berat dan dengan rilis reguler;
  • mana yang harus dipantau terlebih dahulu;
  • bagaimana membangun proses respons yang cepat dan belajar tentang masalah dalam layanan sebelum pengguna.

Tim platform


Kembali ke platform. Beberapa tim yang berbeda mengerjakan pengembangan dan dukungan mereka. Mereka bertanggung jawab atas zona mereka, tetapi tidak ada yang bertanggung jawab atas semuanya - ada rasa sakit "melalui". Masalah-masalah ini diselesaikan oleh tim platform: mereka menciptakan infrastruktur untuk mengembangkan aplikasi dan pekerjaan mereka pada produksi, membantu untuk bekerja lebih cepat dan lebih baik, bertanggung jawab atas segalanya. Cara membuat tim seperti itu dan menerapkan pemikiran produk, kata Dmitry Vishin , kepala kelompok pengembangan platform goods.ru, dalam laporannya “ Tim platform penting. Mengapa? "

Membuat tim platform tidak cukup. Anda harus tidak dapat memecahnya sebelum seseorang mulai menggunakan platform. Di jalan ini, rakun jahat dapat ditemukan. Ya, itu rakun. Di mana rakun berasal dan bagaimana mereka terkait dengan stabilisasi tim platform ? Kami belajar dari pengembang utama di MTS, Elizabeth Golenok, dari laporan " Tim Platform dan 4 Rakasa Jahat ".

Laporan akan dilengkapi dengan diskusi meja bundar " Tim Platform: manfaat atau bahaya ". Selama meja bundar, Philip Uvarov (Spotify) dan Andrei Alexandrov (Mafin) akan membahas beberapa masalah.

  • Mengapa perintah-perintah ini diperlukan dan apakah mereka dibutuhkan sama sekali?
  • Mengapa membuatnya modis untuk membuatnya?
  • Apakah ada gunanya bagi mereka atau itu hype?
  • « », ?


Terlepas dari semua praktik rekayasa dan bantuan tim, techlide menulis kode. Bagaimana menulis sedemikian rupa sehingga kode dapat dibaca dan didukung, dan tidak menulis ulang semuanya dalam setahun? Dua laporan akan menjawab pertanyaan ini.

Yang pertama adalah " Cara Menulis Kode yang Dapat Dibaca, " oleh Grigory Petrov , Kepala Hubungan Pengembang di Evrone. Gregory mengorganisasi pengembangan, konferensi ( Moscow Python Conf ++ ), hackathons, generalis, dan neurofisiologis amatir. Akibatnya, laporan itu akan memiliki banyak neurofisiologi, intuisi kognitif dan sosial. Tetapi yang utama adalah bahwa Gregory akan memberi tahu Anda dari mana kompleksitas kode berasal, mengapa itu tidak dapat dihapus dan bagaimana hidup dengannya.

Yang kedua adalah laporan “ Neraca kontradiksi. Pilihan praktik terbaik dalam kode dan dalam tim » Gleb Lobastov. Gleb adalah penasihat teknis dan pemimpin tim pengembangan di OneTwoTrip dengan pengalaman 10 tahun. Laporan ini akan berbagi pendekatan untuk menulis kode "baik" - dapat dimengerti dan nyaman untuk didukung, dan akan menjawab beberapa pertanyaan:

  • apa yang harus dipertimbangkan ketika menerapkan praktik terbaik dari sudut pandang proyek dan tim;
  • musuh utama kode yang baik dan cara menghadapinya;
  • kontradiksi dalam praktik penulisan kode yang baik.

Semua ini dengan contoh, dengan seperangkat prinsip dan praktik untuk menulis kode yang dapat Anda banggakan.

Warisan dan refactoring


Topik kode, atau lebih tepatnya kode lama, akan terus di blok pada warisan dan refactoring. Banyak yang akrab dengan analisis statis sebagai alat yang praktis. Tetapi kadang-kadang kesulitan muncul, misalnya, ketika proyek memiliki basis data besar kode warisan. Ketika analisis statistik menemukan kesalahan, apa yang harus dilakukan dengan mereka? Bagaimana menyeimbangkan koreksi kesalahan lama dan menangkap kesalahan baru? Kami belajar dari laporan " Bagaimana memperbaiki ratusan kesalahan dalam kode warisan dan tidak mati (misalnya, Unreal Engine 4) " oleh George Gribkov .
Anda dapat memperbaiki tidak hanya kode, tetapi juga arsitektur, infrastruktur, dan proses.
Setiap perusahaan IT berumur panjang dihadapkan dengan perlambatan dalam proses produksi. Ini dipicu oleh banyak faktor, misalnya, kompleksitas teknologi dan peningkatan jumlah karyawan. Ini mengarah pada fakta bahwa koordinasi tertunda, tidak ada yang memikul tanggung jawab, dan sistem menjadi rapuh. Lev Goncharov (T-Systems) dalam laporannya " Perjanjian sebagai Kode: bagaimana cara memperbaiki proses dan tidak memecah " akan berbagi cerita dari 14 tahun pengalaman yang akan membantu mempercepat proses infrastruktur dan membuatnya secara eksplisit.

Setelah refactoring proses infrastruktur, Anda dapat melanjutkan untuk membakukannya. Misalnya, singkirkan "kebun binatang" teknologi. Bagaimana melakukan ini pada contoh pengalaman standardisasi infrastruktur dari satu aplikasi besar tertentu, Ilya Mitrukov akan memberi tahu- Manajer Infrastruktur (Petugas Keamanan Informasi Teknis) dari Pusat Teknologi Deutsche Bank. 

Laporan “ Bukan para dewa membakar pot. Standardisasi infrastruktur ”tidak akan ada peningkatan teknologi, solusi inovatif, teknologi“ Cosmos ”atau pipa CI / CD. Hanya akan ada kehidupan infrastruktur selama beberapa tahun proyek, meminimalkan biaya dan mendukung pengembangan bisnis.

Dari kode, proses, dan infrastruktur, mari beralih ke refactoring teknologi. Bagaimana cara menerjemahkan proyek yang melakukan 70 orang sehari untuk Bereaksi dan Mengetik Script sehingga tidak ada yang memperhatikan? Kami akan meminta Yandex, atau lebih tepatnya Evgeny Dashkevich , kepala grup Yandex. Dalam laporan tersebut “ Bagaimana cara pindah ke teknologi baru sehingga 70 pengembang tidak memperhatikan apa pun"Eugene akan membagikan sejarah terjemahan dan alasan untuk memperbarui tumpukan teknis dalam proyek, yang menghasilkan jutaan kombinasi berbeda dari hasil pencarian per hari.

DDD, Event Storming dan Manajemen Pengetahuan


Di bagian konferensi ini, kita akan berbicara tentang desain, menggunakan pendekatan dan praktik DDD - Desain Berbasis Domain (desain spesifik domain). Seringkali ditinggalkan karena fakta bahwa ini adalah metodologi tanpa indikasi yang jelas tentang apa dan bagaimana melakukannya. Tetapi Raiffeisenbank telah menggunakan praktik-praktik DDD di berbagai proyek selama 5 tahun untuk menguraikan sistem menjadi layanan-layanan mikro, berkomunikasi dengan pelanggan dan dalam tim, dan membuat aplikasi yang tidak menolak persyaratan baru. Cara menerapkan pendekatan, yang praktik untuk menggunakan dan menghindari kesalahan, kita belajar dari laporan Konstantin Gustov " Cara menjinakkan DDD ".

Ada banyak praktik di DDD. Salah satunya adalah Event Storming. Ini memfasilitasi pekerjaan lebih lanjut di bidang desain DDD dan microservice. Saat membuat sistem pada layanan microser, Anda dapat dengan mudah membuat monolit terdistribusi. Event Storming tidak melindungi dari ini sebesar 100%, tetapi secara signifikan dapat mengurangi risiko. Tentang bagaimana, dengan contoh-contoh praktis, dalam laporan Sergey Baranov (ScrumTrek) " Pemodelan layanan microser menggunakan Event Storming ".

Ketika kami mengetahui apa yang dilakukan techlide, bagaimana mengembangkan dan menerapkan praktik-praktik teknik, kami beralih ke penyimpanan, manajemen, berbagi pengetahuan, dan pelacakan solusi teknis dalam sebuah tim. Misalnya, manajemen pengetahuan diperlukan ketika pengembang membuat fungsionalitas serupa di berbagai bagian satu proyek besar. Mereka menghabiskan banyak waktu dan sumber daya untuk hal ini daripada jika mereka menggabungkan upaya mereka.

Ilya Kashlakov mengepalai departemen pengembangan front-end dari 50 orang di Yandex.Money. Dengan begitu banyak pengembang, sangat penting untuk berbagi pengetahuan dan mengawasi arsitektur. Laporan “ Tinjauan Logika - sebagai alat untuk membuat keputusan teknis yang rumit"Ilya akan berbicara tentang alat ini: bagaimana mereka menghasilkan Logic Review, metrik apa yang mereka kumpulkan dan bagaimana mereka menentukan keberhasilan proses ini. Semua ini dengan contoh masalah, deskripsi perubahan yang telah terjadi dalam proses dari awal hingga saat ini.

Untuk implementasi proyek kami membutuhkan banyak dokumentasi. Untuk menyimpannya gunakan, misalnya, bahasa markup ringan: Markdown, reStructuredText, Asciidoc. Mereka mudah ditulis, dan file disimpan dengan nyaman di repositori. Di lokakarya “ Bagaimana cara mempublikasikan penurunan harga dan RST? Tinjau alat dokumentasi modern ”kita akan berbicara tentang cara menerapkannya ke techlides:

  • Konstantin Valeev (Rostelecom IT) akan berbagi cara untuk membuat PDF dan HTML yang disesuaikan dari sumber penurunan harga;
  • Semen Faktorovich (documentat.io) akan berbicara tentang "pisau Swiss" dari Pandoc dan bagaimana cara mengalahkan generasi DOCX dengan itu;
  • Nikolai Volynkin (Plesk) - cara membuat portal HTML besar menggunakan Sphinx-doc.

Tiga pembicara akan membagikan pengalaman mereka dan semua orang akan dapat mengajukan pertanyaan mereka sendiri tentang topik tersebut.

TechLead Conf 2020 Online untuk mereka yang ingin tumbuh menjadi techlida


Konferensi TechLead Conf 2020 Online untuk tehlidov dan mereka yang ingin menjadi insinyur, pengembang, pemimpin tim, dari QA, manajer pengembangan. Bahkan jika Anda belum menjadi techlide, datanglah ke konferensi dan kumpulkan instruksi untuk Anda bagaimana menjadi satu - peta kompetensi teknis. 

Seluruh konferensi akan diadakan dalam format baru - online. Berkat ini, kami menambahkan lebih banyak konten dalam tiga hari acara daripada offline: lebih dari 30 laporan, pembicaraan kilat (laporan singkat dengan jawaban atas pertanyaan), OST untuk pertukaran pengalaman, meja bundar, dan berbagai format jaringan. Kami telah menyiapkan jadwal untuk program ini - lihat, tandai laporan favorit Anda atau kelas master di kalender agar tidak ketinggalan.

Format baru - harga baru, sehingga bahkan di masa-masa aneh ini Anda dapat terus mengembangkan dan memelihara kontak dengan kolega dari perusahaan lain. Pesan tiket - harga 5900 untuk perorangan akan membantu mengikuti perkembangan produk baru di industri atau mendapatkan profesi baru.

Semua peserta konferensi online di Akun Pribadi dapat menawarkan pertanyaan mereka untuk diskusi, meminta bantuan dalam tugas kerja atau memulai diskusi yang menarik dan relevan. Di sana Anda dapat langsung memilih topik menarik. Penulis ide terbaik akan menerima tiket gratis ke konferensi yang dipilih, tempat diskusi yang diusulkan akan diselenggarakan.

29 18:00 -. , maturity model.

. . live-, Spring Cloud Contract Pact. , .

More articles:


All Articles