Bagaimana menjadi direktur teknis, apa yang harus dilakukan dalam situasi darurat, bagaimana mencapai gaji yang lebih tinggi dan pertumbuhan karir, serta bagaimana pengembangan Am.ru bekerja - kita membicarakan hal ini dalam edisi keempat belas talkshow untuk programmer "Oh, My Code".
Tuan rumah dari program ini adalah Pavel Shcherbinin, direktur teknis proyek media, tamu - Alexander Melnichuk, direktur teknis Am.ru.
Ceritakan sedikit tentang diri Anda.Saya lulus dari ITMO. Dia mencoba belajar di sekolah pascasarjana, terlibat dalam difraksi sinar-X sudut kecil. Kemudian era Internet dimulai, semua orang mulai membuat portal. Pada tahun 2009, seorang teman saya menelepon dan mengatakan bahwa temannya Oleg ingin memulai proyeknya dan mengumpulkan tim di St. Petersburg. Kami bertemu di kereta bawah tanah. Sejak itu saya bekerja di am.ru. Selama pertemuan pertama, Oleg segera merekrut dua orang: saya, kemudian manajer pengembangan, dan Sergey, pengembang utama. Artinya, kami menulis baris kode pertama.
"Datang ke direktur teknis kami?" - "Dan berapa banyak orang yang akan kita tundukkan?" "Sejauh ini, hanya kamu."Tidak ada yang berbicara tentang direktur teknis itu. "Direktur Teknis" umumnya posisi yang sangat aneh. Di satu sisi, ini adalah semacam manajemen, di sisi lain - seorang spesialis teknis. Ada variasi yang berbeda. Misalnya, ketika seorang CTO menulis banyak kode. Sebenarnya, ini adalah pengembang utama. Kemudian dia biasanya memiliki ketidakpuasan serius atas berbagai pekerjaan manajerial. Dalam kasus saya, yang terjadi adalah yang sebaliknya. Saya mengelola tim 100% dari waktu saya. Saya berhenti menulis kode dari sekitar 2009, karena tidak ada waktu untuk ini. Saya bisa menulisnya, tetapi kemudian saya harus mengirim saya ke tim musuh.
Tapi tetap saja Anda adalah direktur teknis. Anda harus menyadari perkembangan teknologi, tahu bagaimana frontend, backend berkembang.Saya terus membaca, menonton, berkomunikasi dengan pengembang. Saya mengerti apa yang dilakukan dan bagaimana caranya. Dan kemudian, sebelum itu selama 8 tahun, saya sendiri menulis sesuatu. Tentu saja, ini bukan ilmu roket. Tapi saya bisa membaca kodenya sekarang.
Bagaimana cara menjadi direktur teknis?Pertama-tama, Anda harus ingin menjadi satu. Ini bukan untuk mengatakan bahwa CTO adalah sesuatu yang sangat keren, lebih baik daripada yang lainnya. Semua profesi baik. Anda bisa menjadi pengembang yang bahagia dan menikmatinya. Anda harus menjadi direktur. Mengolah tugas manajerial adalah keterampilan tertentu. Anda perlu memahami bahwa dalam kebanyakan kasus Anda tidak akan menulis kode. Terkadang di lowongan mereka menunjukkan bahwa Anda memerlukan direktur teknis dengan pengetahuan tentang Symfony, dan bahkan jarak jauh. Secara umum, semacam neraka. Orang-orang ini menipu diri mereka sendiri. Dan kadang-kadang seorang arsitek dipahami sebagai "direktur teknis," dan ini juga cukup umum.
Berapa banyak orang di tim Anda sekarang, dan apa strukturnya?43 orang. Strukturnya datar, yaitu, semua orang ini secara administratif berada di bawah saya. Kami tidak memiliki manajer proyek dan pemimpin tim. Tetapi struktur logis yang cukup berkembang dari 5 tim yang terpisah, baik profil sempit dan profil lebar, yang terlibat dalam beberapa bidang sekaligus. Semua tim sepenuhnya independen, bekerja di lokasi proyek mereka. Mereka memiliki pemerintahan sendiri, dan ini sangat bagus.
Apakah tugas melewati Anda atau langsung ke tim?Tentu saja langsung ke tim. Jika mereka melewati saya, maka saya mungkin sudah lama meninggal, karena aliran tugas sangat besar. Fungsi saya adalah untuk mengurangi komunikasi ke minimum yang diperlukan. Jika seseorang membutuhkan sesuatu, ia harus tahu di mana mendapatkan pengetahuan ini, dengan siapa berbicara langsung.
Tentunya banyak pembaca kami akan memiliki pertanyaan: mengapa Anda membutuhkan Anda? Tugas langsung ke tim, tim keren, mengatur diri sendiri. Tampaknya direktur teknis bahkan tidak ada.Seorang teman saya pernah berkata bahwa tugas direktur adalah membangun kerja tim sehingga ia dapat dengan mudah dipecat. Kami sedang berjuang untuk ini, tetapi belum mencapai.
Dorongan yang menarik untuk dipecat.Mimpi, Mimpi ...
Tidakkah Anda berpikir bahwa banyak orang yang menginginkan posisi pimpinan dan direktur dengan tujuan bekerja lebih sedikit?Kemarin saya pergi kerja sekitar 22 jam. Menjadi seorang CTO, saya sering iri pada pengembang. Ini luar biasa: itu datang, Anda memiliki tugas yang Anda sukai, Anda memilihnya sendiri, melakukannya, melihat efeknya. Semuanya super. Lelah - minum kopi, bermain, beristirahat. Jika Anda mengalami kesulitan, bicarakan dengan rekan kerja Anda dan selesaikan tugas. Anda dapat mengenakan headphone, mendengarkan musik favorit, dan melakukan pekerjaan. Jika Anda merasa tidak enak, Anda bisa bekerja di rumah, Anda bisa membuat sesuatu di malam hari.
Direktur teknis benar-benar salah. Hari saya yang biasa dimulai dengan selembar kertas A4, di mana saya menuliskan apa yang ingin saya lakukan hari ini. Saya menuliskannya. Lalu tetap ini, ini, lalu aku ambil lembar kedua, lalu yang ketiga. Saya menghapus tugas di siang hari. Ada banyak dari mereka, mereka kecil, mereka terus berubah. Ketika Anda melakukan satu hal, yang berikut, dan yang berikut, muncul.
Kadang-kadang ternyata di malam hari Anda harus menyelesaikan sesuatu, dan satu jam sebelum itu, pesan pengantar baru muncul. Dan Anda perlu memutar ulang semuanya. Ini adalah dunia yang terus berubah. Ini adalah masalah utama. Saya tidak punya satu tugas besar, saya punya banyak tugas kecil yang saya harus terus membuat keputusan. Ini rumit.
Bisakah Anda berbicara tentang tugas yang paling sering diulang atau, misalnya, sesuatu yang menarik dari kemarin? Apa yang termasuk dalam tugas utama Anda?Tugas utama adalah agar semuanya berfungsi, agar kita dilepaskan tanpa penundaan, sesuai jadwal, untuk memenuhi tugas yang ditetapkan oleh manajemen produk, sehingga proyek-proyek disampaikan tepat waktu. Bagaimana saya akan melakukannya adalah kesulitan saya. Kesulitan sangat berbeda. Misalnya, orang-orang datang ke pusat data untuk membongkar server, dan loader tidak diizinkan masuk, karena ia memiliki paspor yang mencurigakan. Atau petugas keamanan meminta beberapa informasi, dan Anda perlu menemukan seseorang yang akan memberikan informasi ini. Atau produk berubah, masing-masing, tugas baru dan tenggat waktu muncul, Anda perlu mengintegrasikan tugas-tugas ini ke dalam rencana dan menyelesaikannya.
Bagaimana Agile masuk ke dalam sistem pengembangan Anda?Kita hidup sepenuhnya di Agile. Kami memiliki tim yang mengerjakan Scrum, dan ada tim yang bekerja di Kanban. Aku bahkan tidak tahu bagaimana kita bisa melakukannya tanpanya. Sekali waktu, ketika saya masih tidak tahu istilah ini, kami mencoba membangun sistem yang sama, tetapi kami tidak berhasil karena itu adalah inisiatif tanpa buku teks, di atas bakat. Misalnya, sudah lama ada "alergi" bagi manajer proyek dan orang-orang yang harus membagikan tugas dan mengecat kotak. Saya tidak pernah memiliki manajer proyek.
Bagaimana cara kerja tim?Kami memiliki CPO (pemilik produk utama. - kira-kira Ed.) Yang mengatakan bagaimana produk akan berkembang. Selanjutnya ada sejumlah APO (Area product owner -. Kira-kira Ed.), Yang bertanggung jawab untuk area mereka. Faktanya, struktur organisasi sedikit lebih rumit, tetapi saya menggambarkan logika. Setiap arah memiliki tim yang terpisah. Tim mengambil tugas dari APO, dan terkadang mengatur sendiri. Tugas ditambahkan ke backlog umum, kemudian sprint backlog terbentuk dan kemudian mereka selesai.
Di awal setiap sprint, perencanaan dilakukan. Secara terpisah di semua tim. Timbul pertanyaan: "Bagaimana dengan koordinasi tujuan bersama?" Ada perencanaan umum di tingkat pemilik produk. Inilah tugas-tugas yang sebelumnya dikoordinasikan antar arah. Selain itu, kami membutuhkan koordinasi teknis, yang dilakukan dalam beberapa cara.
Jika seorang karyawan membutuhkan koordinasi dengan tim lain, maka dia datang ke stand-up dan mengatakan bahwa mereka memiliki masalah ini dan itu, meminta bantuan. Kami menyebut karyawan tersebut sebagai "pengintai".
Selain itu, kami memiliki pertemuan teknis umum Master Sync, yang menyatukan pengembang dan perwakilan dari semua tim, tanpa pemilik produk. Di atasnya, kami hanya memecahkan masalah teknis, membahas cara menyelesaikannya dengan benar, cara menyinkronkan teknologi umum. tugas antar tim. Terkadang, di Master Sync, tugas dirumuskan yang dilakukan oleh karyawan dari dua tim atau lebih atau ditempatkan dalam tumpukan umum untuk solusi bersama lebih lanjut.
Untuk menyusun rencana, PBR (Penyempurnaan jaminan simpanan produk -. Approx.ed) dilakukan. Pengembang mengevaluasi tugas dan membantu pemilik produk membuat rencana dan memprioritaskannya. PBR dapat terjadi baik dalam satu tim, dan antara beberapa tim. Terkadang perencanaan dilakukan dengan tim eksternal, jika produk melibatkan integrasi.
Itu berakhir dengan demonstrasi produk mingguan. Siapa pun yang ingin bisa datang. Kami menyiarkan secara online. Pemilik produk menonton, menonton CPO, terkadang pemasaran, tenaga penjualan, dukungan. Tim berbicara tentang fitur yang diimplementasikan, API, dokumentasi, tes, dan semua yang telah dilakukan. Mereka yang terlibat dalam arsitektur atau administrasi dapat berbicara tentang keputusan dan rencana mereka. Artinya, demo adalah semacam tonggak umum yang menunjukkan hasil kerja seluruh tim dalam satu atau dua minggu, tergantung pada durasi siklus tim.
Selanjutnya, setiap tim melakukan retrospektif sendiri, di mana masalah organisasi dibahas. Jika tim tidak dapat memutuskan sesuatu di dalam dirinya sendiri, maka pertanyaan diajukan ke retro antar tim. Kami melakukannya setiap dua minggu sekali dan memutuskan apa yang berlaku untuk semua tim, seluruh kantor dan seluruh produk. Menurut hasil dari retro, setiap tugas ditugaskan orang yang bertanggung jawab yang dapat menyelesaikannya atau mengikuti keputusannya, jika itu tergantung pada layanan eksternal. Untuk retro atau Master Sync berikutnya, mereka yang bertanggung jawab memberi tahu apa yang mereka lakukan atau tidak, untuk alasan apa, keuntungan dan kerugian apa yang terungkap.
Ceritakan tentang situasi tak terduga dan tidak normal.Situasi abnormal terjadi, tetapi semakin sedikit. Sebagai contoh, sekali di situs kami semua JS di desktop berhenti berfungsi. Yang paling penting adalah menemukan penyebab masalah dan menyelesaikannya. Berbicara dalam istilah ilmiah, kami menggunakan metodologi Andon: kami menghentikan semua proses, seluruh tim mencari alasan. Ditemukan cukup cepat. Diperlukan lebih banyak waktu untuk menyelesaikan masalah.
Apa alasannyaTambahkan sedikit minyak ke api. Di ujung depan, kami tidak memperbarui apa pun. Dan mengapa semuanya hancur, tidak ada yang mengerti. Tapi segera pecah di mana-mana. Ternyata kami telah merilis alat utilitas kecil, yang menarik perpustakaan JS pihak ketiga, yang memiliki kesalahan. Perpustakaan ini segera diganti dalam semua kode. Akibatnya, JS menghujani. Tidak ada yang berharap bahwa alat yang sama sekali asing di panel admin sistem kontrol dapat merusak segalanya.
Anda menyebutkan metodologi Andon. Apa iniSetiap orang memiliki spesialisasi. Saya adalah direktur teknis, ada pengembang front-end, pengembang ponsel, administrator sistem, DevOps, dll. Tampaknya jika saya seorang programmer C ++, saya akan menulis dalam C ++. Tetapi jika frontend rusak JS? "
Apa itu JS? Sesuatu yang tidak dapat dipahami dari humaniora, saya tidak akan melakukannya. - Tapi saya umumnya seorang administrator sistem atau DevOps. Saya tidak ada hubungannya dengan itu, tarik JS Anda sendiri . "
Andon dirancang untuk mencegah situasi seperti itu. Proyek kami macet, itu proyek kami bersama. Kita semua mulai mencari di mana itu pecah. Dalam kasus yang saya jelaskan, alasannya ditemukan oleh pengembang backend biasa, yang baru saja duduk dan mulai mencari, tanpa mengatakan bahwa dia tidak menulis di JS, bahwa dia tidak tahu sesuatu. Yaitu, Andon terletak pada kenyataan bahwa semua orang menyerah dan mulai memecahkan masalah sebanyak yang mereka bisa.
Anda mengatakan bahwa masalah muncul karena beberapa jenis utilitas sistem internal. Anda tidak menggunakan containerisasi, yang sekarang sangat populer?Tidak.
Apakah Anda sekarang memiliki buruh pelabuhan dalam produksi?Ya
Artinya, Anda aktif beralih ke Docker dan menggunakannya?Ini adalah salah satu arahan utama pekerjaan kami.
Apa kesan Anda?Bagus Saya bahkan tidak tahu bagaimana kita akan hidup tanpanya. Sebelumnya, kami memiliki PHP - mari kita singkirkan skrip, dan itu dimulai. Dan sekarang Anda tidak bisa hidup tanpa wadah dengan cara apa pun.
Anda, sebagai direktur teknis, terlibat dalam "kesehatan" tim. Ceritakan sedikit tentang itu.Salah satu kualitas utama saya: Saya suka mendengarkan orang. Saya mencoba untuk menempatkan diri saya di tempat mereka, ini memungkinkan untuk memahami suasana hati mereka, masalah, mengapa mereka membuat keputusan tertentu, mengapa mereka merasa begitu. Dan ini membantu saya menemukan jalan keluar yang tepat dari situasi, membuat keputusan yang tepat. Bagi saya, “kesehatan” tim, “kesejahteraan” setiap orang adalah sangat penting: apakah itu baik baginya, apakah ia nyaman dalam tim, tujuan apa yang ia tuju, apa yang ingin ia capai.
Suatu kali seorang pengembang mengatakan dalam percakapan pribadi: “
Saya dulu bermimpi menjadi seorang teknisi atau direktur teknis untuk mendapatkan lebih banyak uang, memiliki kekuatan, dan sebagainya. Sekarang saya bekerja dalam struktur datar, kami tidak memiliki techlide. Tetapi ada direktur teknis yang melakukan tugas manajerial, dan pengembang membuat keputusan teknis. Di mana saya harus membidik? Bagaimana saya hidup? Prinsip hidup rusak. Tidak jelas ke mana harus melangkah lebih jauh . "
Perlahan-lahan, saya menyadari bahwa bukan itu intinya. Seorang pria harus bahagia. Tugas yang dia lakukan, dia harus suka. Dan dia dapat memilihnya untuk dirinya sendiri. Tangga karier memberikan pertumbuhan finansial, tetapi dapat dicapai dengan cara lain: Anda memecahkan masalah yang lebih kompleks, membantu orang lain, tim Anda bekerja lebih cepat, Anda memberikan fitur kompleks lebih cepat. Begitu banyak untuk pertumbuhan karier, upah, tingkat tumbuh. Perubahan dalam buku kerja adalah sekunder. Bekerja dengan baik - Anda mendapatkan kesenangan darinya. Dan jika ini akan mempengaruhi produk secara positif, maka gaji akan meningkat, dan posisi dalam buku kerja akan berubah.
Bagaimana cara menjadi pemimpin tim?Anda mungkin tidak. Arti kerja tim adalah melakukan apa yang Anda suka. Dalam praktik saya, ada beberapa kasus ketika seseorang diresepkan timlid atas permintaannya. Nah, kami menulis memo, kami mengubah entri dalam persalinan, menambah gaji. Pada saat yang sama, orang tersebut mengatakan bahwa dia adalah seorang pemimpin tim, tetapi tim tersebut tidak mengenalinya.
Itu terjadi sebaliknya: seseorang menjelaskan kepada tim bagaimana melakukan sesuatu, dan tim mengenalinya. Ini adalah pemimpin tim terbaik. Jika Anda ingin menjadi pemimpin tim, Anda akan menjadi. Dan jika Anda tidak mau, maka Anda tidak akan melakukannya.
Anda mengatakan bahwa Anda suka mendengarkan pengembang, Anda memberikan banyak contoh ketika mereka memberi tahu Anda sesuatu. Tetapi pengembang biasanya introvert, menarik sepatah kata dari mereka terkadang sulit. Bagaimana Anda menangani ini? Bagaimana cara berbicara dengan pengembang?Semua introvert. Semua orang membenci orang. Bukan itu intinya. Kami bekerja bersama. Saya mencoba berbicara dengan orang satu lawan satu dari waktu ke waktu. Sangat berguna untuk mendapatkan umpan balik. Suatu kali saya tidak bisa mengerti apa yang terjadi pada seseorang. Kemudian kami sepakat bahwa kami akan bertemu dua minggu sekali dan berbicara. Dan setelah itu, semuanya berjalan lancar. Saya mengatakan kepadanya bahwa saya tidak menyukainya, dia mengatakan kepada saya bahwa dia tidak menyukainya. Kami menemukan poin-poin umum, membuat keputusan, mendiskusikan apa yang akan kami lakukan selanjutnya seperti ini. Dan bergerak maju. Ini bekerja dengan sangat baik. Kita perlu lebih banyak berkomunikasi.
Survei blitz kecil kami. OS mana yang akan Anda pilih?OS Mac
Apa IDE terbaik?JetBrains
Aplikasi terakhir, situs web, startup yang mengesankan Anda?Mobile Banking dari Tinkoff Bank.
Mana yang lebih baik: startup atau perusahaan besar?Jika Anda hanya ingin hidup dengan nyaman dan mendapatkan bayaran, maka pergilah ke perusahaan besar. Jika Anda terus-menerus marah, Anda menginginkan gerakan, adrenalin, petualangan, maka startup adalah segalanya bagi Anda. Tidak perlu pergi ke startup jika Anda hanya ingin banyak uang. Ini bukan seperti itu.
Kemarin, trennya adalah mobile dulu. Hari ini adalah pembelajaran mesin pertama. Apa yang akan terjadi besok?Pada satu pelatihan mereka mengatakan bahwa ada orang-orang istimewa yang menentukan apa yang akan terjadi besok, bahkan menggambar kartu pada subjek ini dan menjualnya untuk mendapatkan uang. Pembelajaran mesin adalah semacam hype. Ada juga data besar, realitas virtual, nano dan bioteknologi. Saya melihat peta yang serupa: semacam jalinan ikatan kusut yang bergerak ke arah yang berbeda. Prediksi di tingkat astrologi. Saya akan mengatakan bahwa besok tidak akan ada pembelajaran mesin, tetapi data besar. Banyak yang sudah diketahui tentang orang yang online. Anda hanya perlu belajar cara menggunakannya dengan benar. Pengetahuan ini dikumpulkan, diproses, adalah sumber pendapatan.
Kapan robot akan menggantikan Anda?Kita dapat mengatakan bahwa mereka sudah diganti. Saya membeli penyedot debu robot.
Bagaimana Anda menghargai tugas: dalam jam atau dalam Poin Cerita?Baik dalam Story Points, dan dalam jam. Siapa yang mau.
Apa hal terakhir yang Anda tidak mampu?Pendakian Subaru.
Berapa banyak bitcoin yang Anda miliki?Nol
Tidak tertarik dengan topik ini?Ini hype.
Apa yang paling sering ditanyakan teman Anda tentang am.ru?Saat kita mengambil alih dunia.
Dan kapan?Segera hadir.