🧕🏿 ✌🏿 🤚 Dari pengembang ke manajer dan sebaliknya ⚡️ 🍇 👆🏾

Pada musim dingin 2012, seorang rekan menyarankan agar saya, seorang programmer C ++ dengan pengalaman lima tahun, menulis aplikasi pertama untuk Android. Setahun kemudian, saya mulai memimpin tim kecil pengembang seluler, dan sejak itu ukuran tim saya terus bertambah. Tapi tahun lalu, setelah 2 tahun mengelola departemen pengembangan ponsel, saya meniup debu lagi dengan IDE favorit saya.

Mari kita beri tahu Anda bagaimana hal itu terjadi di sisi lain, mengapa saya kembali ke pengembang pada usia 30+ (spoiler) dan tidak menyesalinya.

Jalan menuju Pengembang Android

Android, yang pada waktu itu merupakan tipu muslihat di kota provinsi saya, bagi saya merupakan “mainan” lain yang menyenangkan, dengan bermain yang Anda dapat dengan aman menjatuhkannya dan kembali ke Qt yang biasa. Dan begitulah semuanya dimulai: seorang teman memunculkan ide aplikasi sederhana untuk menghitung pendapatan dan pengeluaran, kami mulai melihatnya di waktu senggang kami, dan enam bulan kemudian MVP siap untuk dipublikasikan.

Money Keeper kami memiliki desain yang agak primitif, tetapi UX yang dipikirkan dengan matang: pendapatan atau pengeluaran dicatat dalam satu klik - ketuk ikon kategori segera membuka jendela untuk memasukkan jumlahnya.

Saya ingat betul bagaimana saya melihat statistik unduhan: orang pertama yang mengunduh aplikasi saya adalah seseorang dari Mesir. Dan yang ini tidak menghapus aplikasi pada minggu yang sama, tetapi terus menggunakannya!

Sedikit demi sedikit, beberapa lusin unduhan per hari, pemirsa bertambah, peringkat bertambah, ulasan positif pertama muncul. Mengatakan itu diilhami adalah mengecilkan. Saya menanggapi ulasan di pasar, merencanakan pengembangan lebih lanjut berdasarkan keinginan pengguna, hanya karena aplikasi saya dibutuhkan oleh pengguna, mereka berterima kasih dan memberi balita. Dan semua iklan kami berada dalam satu pos di w3bsit3-dns.com.

Itu juga mengejutkan berapa banyak pengembangan ponsel berbeda dari pengembangan sistem embedded dan aplikasi desktop yang saya kerjakan sebelumnya. Jalur aplikasi ke pengguna dan umpan baliknya sangat singkat. Penonton sangat besar, dan semua yang Anda lakukan, Anda harus melakukan setidaknya dengan baik, jika tidak aplikasi tidak akan dibutuhkan oleh siapa pun, dan semua pekerjaan dapat dibuang.

Bagaimana saya menjadi seorang pemimpin tim, "karena_to_to_someone_something_is due_"

Aplikasi tumbuh dan menjadi lebih rumit, versi berbayar dengan fungsi tambahan muncul. Sepasang tangan saya untuk pengembangan dua aplikasi sudah tidak cukup, terutama mengingat fakta bahwa saya menulisnya di waktu luang saya dari pekerjaan utama. Tidak ada anggaran khusus untuk mempekerjakan karyawan, karena monetisasi tidak mendatangkan begitu banyak pendapatan.

Kami menolak gagasan "membekukan" aplikasi gratis untuk yang berbayar, karena kami tidak ingin mengecewakan komunitas pengguna yang berterima kasih, yang darinya kami telah mengambil energi dan ide untuk pengembangan selama ini. Oleh karena itu, kami memutuskan untuk mengambil gaji kecil dua orang yang jauh dari pengembangan, dan membakar untuk menerimanya. Diputuskan untuk memimpin mereka di sepanjang jalan saya, tetapi dengan perbedaan yang signifikan: Saya harus mengajari mereka cara bergerak dan menavigasi dunia robot hijau dan menunjukkan kepada mereka semua gundukan dan lubang yang saya tahu di jalan ini.

gambar

Saya tidak takut untuk mengambil tugas-tugas sulit)

saya inginkanorang lain berbagi antusiasme saya terhadap perkembangan ini, dan bahkan dua pasang tangan jelas tidak berlebihan bagi kami. Saya pergi ke rumah mereka, menjelaskan, mengajar, menasehati, membantu. Saya menetapkan tugas dan memeriksa implementasinya. Jadi saya diam-diam menjadi manajer kecil.

Namun, aplikasi tersebut harus ditutup ... Saya pergi ke startup, kemudian yang lain, kemudian datang ke pengembangan produk dalam bisnis besar. Di mana-mana di mana tidak ada cukup banyak orang untuk peran utama, ada skenario yang kira-kira serupa: “Anda menemukan bidang subjek, berteman dengan tim, tidak menentang pekerjaan kepemimpinan, dan apakah Anda bahkan memiliki pengalaman seperti itu? Mari kita coba mengatur tugas untuk orang lain. Setidaknya dalam sprint ini ... ”

Tetapi ada aspek penting lainnya: saya memikirkan masa depan - dan itu tampak berkabut.Beberapa waktu yang lalu saya menemukan sebuah artikel tentang usia rata-rata pengembang. Dikatakan bahwa "puncak karier" pengembang jatuh pada 27 tahun. Saya mulai memperhatikan artikel serupa - dan tanpa sadar bertanya-tanya: apa yang akan saya lakukan sebagai pengembang, misalnya, pada usia 32, ketika "sebuah omong kosong datang yang akan menghapus kita dari muka bumi"? Bukankah lebih baik perlahan-lahan menapak jalan ke manajer dan memecahkan "masalah 30 tahun" untuk Anda sendiri?

Prinsip saya sebagai Timlida

Pada saat saya meninggalkan C ++ dan pergi ke Android, saya sudah bekerja dengan berbagai pemimpin dan tahu persis seperti apa pemimpin yang saya inginkan. Dan kemudian, dalam tim yang sama sekali berbeda: produk (terdiri dari analis, desainer, pengembang, penguji) dan tim pengembangan - saya berusaha untuk tidak menyimpang dari prinsip saya.

Perlu bekerja dengan mereka yang ada

Seorang siswa dengan mata menyala-nyala, yang dikirim di jalur yang benar, setelah beberapa waktu mungkin mulai membawa lebih banyak manfaat bagi proyek daripada "bintang rock".

Di salah satu proyek, saya memutuskan bahwa sudah saatnya untuk beralih dari bundel MVP + Dagger + RxJava yang sudah dikenal, dan mencoba memproduksi alat-alat yang direkomendasikan Google gunakan untuk membuat aplikasi mobile modern. Kami berencana untuk mengimplementasikan arsitektur yang direkomendasikan hanya menggunakan Jetpack dan Kotlin dengan Coroutines.

Semua pengembang dan bos berpengalaman memutar jari mereka di kuil dan mengatakan bahwa dengan tim dua jones yang tidak pernah menggunakan apa pun dari tumpukan yang saya pilih, kami akan mengisi proyek dan tanggung jawab akan menjadi tanggung jawab saya pribadi. Tetapi kedua joon itu senang bahwa mereka akan bekerja dengan apa yang ditulis pengembang Android di blog baru kemarin.

gambar

Ya, tentu saja, kami menangkap banyak penyakit masa kanak-kanak versi perpustakaan alpha pada awalnya ...

Tapi orang-orang bekerja keras, naik ke sumber dan mempelajari masalah pada Github, diprofilkan pada malam hari, dan pada akhirnya kami dapatkan:

kode bersih, stabil dan mudah dirawat,
produk yang sukses dalam produksi,
dan banyak pengalaman yang tak ternilai.

Di proyek lain, seorang pengembang yang sangat keren datang ke tim, yang tidak segera berteman dengan seluruh tim, tetapi menyelesaikan tugas dengan sempurna. Orang-orang menghubunginya melalui rasa sakit, air mata dan bos, dan seseorang bahkan mengatakan bahwa akan lebih baik untuk mengambil Juni apa pun daripada dia, tetapi pada akhirnya saya mengurangi komunikasi langsung di antara mereka ke minimum yang diperlukan, dan semuanya menjadi tenang.

Anda juga perlu bekerja dengan "bintang rock", tidak peduli betapa sulitnya kadang-kadang.

Tentu saja, ada orang yang tidak sengaja melakukan pekerjaan mereka: seseorang berpikir bahwa ia mendapat ke "bos yang akan melakukan segalanya untuk saya", seseorang ia tidak bisa atau tidak mau bekerja. Jika percakapan dan waktu tidak membantu, Anda tidak perlu takut untuk berpisah dengan ini.

Saya bekerja bukan dengan bawahan, tetapi dengan orang-orang

Masing-masing memiliki keadaan, kebutuhan, temperamen dan suasana hati sendiri. Suatu ketika, sebelum melewati sprint yang sulit, seorang gadis penguji, dari siapa semua orang menunggu hasil pengujian produk akhir, datang untuk bekerja marah karena skandal dengan suaminya yang tidak dapat menemukan kaus kaki bersih. Tenggat, ini bukan hari pertama pengujian intensif, tapi ini dia. Dia tidak punya mood untuk bekerja sama sekali. Dalam situasi ini, adalah mungkin untuk menghancurkan, menuntut, dan mengancam. Tapi saya mencoba memahaminya dan mendistribusikan kembali sumber daya penguji lain sedemikian rupa untuk menutupi kesenjangan. Setelah setengah hari, dingin dan kami berhasil berinvestasi dalam waktu.

gambar

Siapa yang sebelum liburan tidak duduk di situs lain selama jam kerja, biarkan yang pertama melempar monitor kepada saya)

Atau cerita lain: seorang kolega berhenti melakukan sesuatu beberapa hari sebelum liburan, hanya karena dia sibuk dengan pertemuan terakhir untuk perjalanan bersepeda ke Eropa, yang telah dia persiapkan selama hampir setahun. Sepanjang tahun ini ia dengan cermat melakukan tugas pekerjaan, dan di sini - sebagai gantinya. Dan saya memberinya dua hari ini. Setelah liburan dua minggu, dia kembali beristirahat dan mulai bekerja dengan kecepatan yang sama, tetapi saya berhasil tidak merusak hubungan dalam tim.

Dalam situasi yang sulit, tidak ada yang akan maju kecuali saya memimpin

Dalam satu tim DevOps yang baru bagi saya, selama beberapa bulan saya “dinamisasi” dengan penerapan CI, dan pengembang secara terbuka menyabot penerapannya, tidak setuju dengan argumen tentang kegunaannya. Bukan karena mereka malas tingkat kemunduran, sepertinya bagi saya bahwa mereka tidak bekerja di lingkungan tempat CI dipersiapkan dengan benar.

Memeluk Google, saya duduk di malam hari dan memilih pengaturan. Secara bertahap, DevOps dan pengembang terlibat dalam proses tersebut. Sebagai hasilnya, kami dapat mengonfigurasi CI dan ikatan yang diperlukan untuk membangun dan mendistribusikan aplikasi, yang dengan cepat dan diam-diam menjadi standar untuk tim yang berbeda di perusahaan.

Apakah saya menutup lubang dalam organisasi proses dengan intervensi pribadi dan manajemen mikro? Mungkin. Tetapi, bagi saya, dalam situasi yang macet, ada dua ekstrem: "kencangkan sekrup", semakin banyak menjauh dari tim dan menjadi "bos", atau mencoba membantu seseorang ketika sulit baginya, bahkan setelah menyelesaikan pekerjaannya, menjadi "miliknya". Tetapi mereka tidak membiarkan "milik mereka" dalam masalah.

Anda perlu mengembangkan diri dan mengembangkan semua orang di tim

Tempat kerja khas seorang pemimpin.

Semakin lama saya duduk di sebuah proyek, semakin saya merasa bahwa perkembangan modern melayang melewati saya. Setumpuk teknologi, bahasa, dan kerangka kerja dipilih beberapa tahun yang lalu, dan tidak berubah secara signifikan sejak saat itu. Ini karena tanggal pembakaran abadi, minat bisnis yang lemah, tetapi yang paling penting - ketakutan para pengembang akan sesuatu yang baru, ketika ada yang sudah lama dikenal.

Sampai pada titik bahwa pengembang yang baru diterima dilarang untuk menulis di Kotlin, karena programmer terkemuka tidak mengenalnya dan tidak menemukan waktu (tidak ingin menemukan?) Untuk mengajarinya. Masalah-masalah ini diselesaikan dengan cukup sederhana: Saya mengadakan pembicaraan teknologi, pertemuan dan kursus tentang topik-topik yang menarik bagi seluruh tim. Lebih mudah dan lebih menarik bagi pengembang untuk memilah-milah teknologi pada proyek hewan peliharaan selama seminggu dan menceritakan sisanya tentang hal itu daripada menyeretnya ke dalam produksi.

Dan lebih mudah bagi bisnis untuk membenarkan kenaikan gaji bagi seseorang yang sedang mempelajari dan memperkenalkan sesuatu yang baru dan berguna bagi seluruh perusahaan.

Seseorang tidak bisa jauh dari masalah pembangunan

Segera setelah Anda tidak lagi memahami masalah pengembang dengan utang teknis, fitur platform, dan interaksi antara berbagai bagian sistem, persentase sprint terbang turun.

Ada kasus ketika manajer benar-benar terkejut bahwa tidak mungkin untuk mempublikasikan aplikasi iOS pada Malam Tahun Baru karena pengulas Apple telah pergi berlibur. Desainer terkadang tidak memahami masalah pengembang Android dengan pengaturan huruf pada layar yang berbeda. Pendukung yang belum pernah bekerja dengan klien seluler sebelumnya harus menjelaskan bahwa mereka tidak perlu memberikan kesalahan halaman HTML alih-alih JSON.

Dan jika Anda "melihat" saat-saat seperti ketika mengembangkan sistem atau bagiannya, konsekuensi untuk tenggat waktu bisa sangat menyedihkan.

gambar

Oh, betapa banyak yang dapat dicapai hanya dengan mengambil solusi teknis. Dan bahkan jika mereka memberikan tugas untuk didistribusikan - Anda dapat menggulung gunung!

Apakah saya berhasil memimpin?

Saya tidak berani mengatakan bahwa ini adalah prinsip yang benar. Saya bahkan tidak tahu apakah mereka sesuai dengan apa yang mereka tulis dalam buku-buku tentang manajemen personalia, karena saya belum membaca satupun dari mereka. Saya menilai dengan beberapa fakta:

Hubungan dalam tim meningkat. Jika sebelum saya ada skandal dengan klarifikasi hubungan dengan pihak berwenang, maka dengan saya - maksimum pertempuran kecil.
Secara umum, kami cocok dengan sprint. Bahkan yang mustahil. Dan jika mereka tidak cocok, maka tidak terlalu banyak pelanggan marah. Tentu, ini adalah kelebihan tim. Tapi mungkin sedikit milikku. Saya selalu mencoba untuk memperhitungkan semua risiko dan melaksanakan perencanaan tugas dengan memperhitungkannya.
Kami terus-menerus memperbarui dan memperbaiki produk dan proses pengembangan, hutang teknis berkurang.
Pengembang tumbuh dalam peringkat dan gaji.
Bimbingan langsung saya juga cantik.

Oke, bagaimana dengan kelemahan kepemimpinan?

Bagi saya mereka adalah:

Semakin Anda seorang manajer, semakin sedikit pengembang. Tidak peduli bagaimana Anda mencoba melacak seluk-beluk bagian teknis dari proyek, mereka menghindari Anda setiap hari semakin jauh. Dan semakin besar tim dan semakin aktif pengembangannya, semakin cepat. Secara bertahap, volume informasi baru yang diterima tentang Android dan iOS dikurangi menjadi membaca catatan rilis versi baru sistem operasi dan beberapa artikel tentang Habré per bulan.
. — , . , “” . .
. . , . - - , .
. , . , 2-3 . - — 70-80% !

!

Tidak peduli bagaimana Anda menyukainya di suatu tempat, Anda harus pergi kapan-kapan. Dan pada titik tertentu saya mulai mencari pekerjaan baru. Bisa ditebak, saya ingin masuk ke bisnis yang lebih besar untuk melanjutkan pengembangan.

Wawancara Skype berikutnya sedang berlangsung: 10 pewawancara, 2 jam , persyaratan - pengetahuan tentang bagian teknis tingkat Pengembang Senior dan kemampuan untuk mengelola orang. Dan setelah 2 jam, saya menyadari bahwa dalam mengelola orang, saya hampir tidak tahu apa-apa. Setidaknya saya tidak tahu teorinya, dan hanya didasarkan pada prinsip dan pengalaman saya.

Itu terlihat seperti ini:

— ?

— .

— ?

— , . , .

— ?

— …

— , scrum kanban?

— .

— ?

— …

Baik dan sebagainya. Saya gagal teorinya. Entah bagaimana saya berhasil menerapkan, tetapi untuk menjelaskan prinsip-prinsip dasar mengapa satu atau lain cara harus dilakukan - tidak. Setelah wawancara, saya menyadari bahwa saya telah mencapai langit-langit di liga manajemen amatir dan lebih jauh duduk di dua kursi tidak akan berhasil. Untuk berkembang, perlu memutuskan ke mana saya ingin pergi.

gambar

Ini adalah tim tandang saya saat ini untuk pekerja jarak jauh. Setidaknya satu orang lagi di dalamnya pergi dengan cara yang sama: pergi ke pemimpin tim dan secara sadar kembali ke pengembang.

Cara pertama adalah manajer. Tetap saja, baca buku-buku yang sangat benar. Mulai menonton video dan menghadiri konferensi manajemen, perencanaan, dan motivasi. Liga manajerial profesional memiliki aturan dan spesifiknya sendiri.

Cara kedua- libatkan diri Anda dalam pengembangan, jika mungkin mengejar ketinggalan selama bertahun-tahun manajemen.

Nah, opsi ketiga, kompromi, adalah "menarik" teorinya dan mencoba untuk terus "berada di tengah", menggantung "dalam amatir" selama beberapa tahun lagi.

Dan kemudian saya ingat bagaimana semuanya dimulai. Dengan perasaan bahwa Anda mengubah dunia, melakukan sesuatu yang bermanfaat bagi orang lain. Bahkan jika Anda melukis tombol hijau, dan itu menjadi sedikit lebih bagus untuk ribuan pengguna. Bahkan jika saya memperbaiki kesalahan ketik. Dan jika Anda telah menghapus fitur yang sudah lama diharapkan oleh pengguna, dan Anda berterima kasih karenanya di komentar - ini hanyalah ledakan emosi dan suasana hati yang baik selama beberapa hari!

Sudahkah saya mengalami perasaan yang kuat dari bekerja sebagai manajer? Saya pikir tidak. Bahkan ketika pelanggan, tim, dan pemimpin memuji Anda. Dan ketika pengguna memuji fitur yang diharapkan, maka ini, tentu saja, terutama disebabkan oleh orang yang menyiapkan, menggergaji, menguji dan menampilkannya. Dan sedikit - saya sebagai manajer.

Oleh karena itu, saya menemukan tempat yang menyenangkan untuk bekerja, saya menulis kode dan sejauh ini saya tidak menyesal.
Apakah ada kehidupan di pengembang di 32? Ada!

PS

Apa yang telah memberi saya sebagai pengembang pengalaman kepemimpinan?

Sekarang saya lebih memahami bisnis dan PMA, bahkan tanpa kata-kata. Seringkali saya tahu pertanyaan apa yang ingin mereka tanyakan kepada saya.
Saya merencanakan waktu dan tugas dengan lebih kompeten dengan mempertimbangkan risiko.
Kontras. Setelah melihat bagaimana rasanya di sisi lain, saya menyadari apa yang saya sukai dari yang ini.

Dari pengembang ke manajer dan sebaliknya