Didedikasikan untuk manajer proyek (dan mereka yang bermimpi menjadi bos).
Menulis banyak kode itu sulit, tetapi mengelola orang jauh lebih sulit! Jadi, Anda hanya memerlukan buku ini untuk mempelajari cara melakukan keduanya.
Mungkinkah menggabungkan cerita lucu dan pelajaran serius? Michael Lopp (juga dikenal di kalangan sempit sebagai Rands) berhasil. Anda akan menemukan cerita fiksi tentang orang-orang fiksi dengan pengalaman yang sangat berharga (walaupun fiksi). Beginilah cara Rands membagikan berbagai pengalamannya, terkadang aneh, yang diperoleh selama bertahun-tahun bekerja di perusahaan IT besar: Apple, Pinterest, Palantir, Netscape, Symantec, dll.
Apakah Anda seorang manajer proyek? Atau ingin memahami apa yang dilakukan bos Anda sepanjang hari? Rands akan mengajari Anda cara bertahan hidup di Dunia Beracun Kalkun yang Meningkat dan berkembang dalam kegilaan umum orang-orang flamboyan yang tidak berfungsi dengan baik. Dalam komunitas aneh para jenius maniak ini terdapat makhluk yang bahkan lebih aneh lagi - manajer yang, melalui ritual organisasi mistis, telah memperoleh kekuasaan atas rencana, pemikiran, dan rekening bank banyak orang.
Buku ini tidak seperti naskah manajemen atau kepemimpinan mana pun. Michael Lopp tidak menyembunyikan apa pun, dia hanya menceritakan apa adanya (mungkin tidak semua cerita harus dipublikasikan :P). Tapi hanya dengan cara ini Anda akan memahami bagaimana bertahan hidup dengan bos seperti itu, bagaimana mengelola para geek dan nerd, dan bagaimana membawa “proyek sialan itu” ke akhir yang bahagia!
Kutipan. Mentalitas rekayasa
Pemikiran tentang: Haruskah Anda Terus Menulis Kode?
Buku Rands tentang aturan bagi manajer berisi daftar singkat "hal-hal yang harus dilakukan" manajerial modern. Ringkasnya daftar ini berasal dari fakta bahwa konsep "harus" adalah sesuatu yang mutlak, dan jika menyangkut manusia, hanya ada sedikit konsep yang mutlak. Metode manajemen yang berhasil bagi seorang karyawan akan menjadi bencana nyata bagi karyawan lainnya. Pemikiran ini adalah hal pertama dalam daftar “yang harus dilakukan” manajer:
Tetap fleksibel!
Berpikir bahwa Anda sudah mengetahui segalanya adalah ide yang sangat buruk. Dalam situasi di mana satu-satunya fakta yang konstan adalah bahwa dunia terus berubah, fleksibilitas menjadi satu-satunya posisi yang tepat.
Paradoksnya, item kedua dalam daftar ternyata tidak fleksibel. Namun, poin ini adalah favorit pribadi saya karena saya yakin ini membantu menciptakan landasan bagi pertumbuhan manajerial. Paragraf ini berbunyi:
Berhenti menulis kode!
Secara teori, jika Anda ingin menjadi seorang manajer, Anda harus belajar memercayai orang-orang yang bekerja untuk Anda dan menyerahkan coding sepenuhnya kepada mereka. Nasihat ini biasanya sulit dicerna, terutama bagi manajer baru. Mungkin salah satu alasan mereka menjadi manajer adalah karena produktivitas mereka dalam pengembangan, dan ketika ada masalah, reaksi pertama mereka adalah kembali ke keterampilan yang mereka yakini sepenuhnya, yaitu kemampuan menulis kode.
Saat saya melihat manajer baru “tenggelam” dalam menulis kode, saya katakan padanya: “Kami tahu Anda bisa menulis kode. Pertanyaannya adalah: bisakah Anda memimpin? Anda tidak lagi bertanggung jawab atas diri Anda sendiri, Anda bertanggung jawab atas seluruh tim; dan saya ingin memastikan bahwa Anda dapat membuat tim Anda menyelesaikan masalahnya sendiri, tanpa Anda harus menulis kodenya sendiri. Tugas Anda adalah mencari cara untuk meningkatkan skala diri Anda sendiri. Saya tidak ingin Anda hanya menjadi satu, saya ingin ada banyak orang seperti Anda.”
Saran yang bagus, bukan? Skala. Pengelolaan. Tanggung jawab. Kata kunci yang umum. Sayangnya saran tersebut salah.
Salah?
Ya. Nasihatnya salah! Tidak sepenuhnya salah, tapi cukup salah sehingga saya harus menelepon beberapa mantan kolega dan meminta maaf: “Ingat pernyataan favorit saya tentang bagaimana Anda harus berhenti menulis kode? Itu salah! Ya... Mulai pemrograman lagi. Mulailah dengan Python dan Ruby. Ya, saya serius! Karier Anda bergantung padanya!”
Ketika saya memulai karir saya sebagai pengembang perangkat lunak di Borland, saya bekerja di tim Paradox Windows, yang merupakan tim yang sangat besar. Ada 13 pengembang aplikasi saja. Jika Anda menambahkan orang-orang dari tim lain yang juga terus-menerus mengerjakan teknologi utama untuk proyek ini, seperti mesin database inti dan layanan aplikasi inti, Anda mendapatkan 50 insinyur yang terlibat langsung dalam pengembangan produk ini.
Tidak ada tim lain yang pernah saya tangani yang bisa mendekati ukuran ini. Faktanya, setiap tahun, jumlah orang di tim tempat saya bekerja secara bertahap berkurang. Apa yang sedang terjadi? Apakah kita para pengembang secara kolektif menjadi semakin pintar? Tidak, kami hanya berbagi beban.
Apa yang telah dilakukan pengembang selama 20 tahun terakhir? Selama waktu ini kami menulis banyak sekali kode. Lautan kode! Kami menulis begitu banyak kode sehingga kami memutuskan bahwa sebaiknya menyederhanakan semuanya dan menggunakan sumber terbuka.
Untungnya, berkat Internet, proses ini kini menjadi sesederhana mungkin. Jika Anda seorang pengembang perangkat lunak, Anda dapat memeriksanya sekarang! Cari nama Anda di Google atau Github dan Anda akan melihat kode yang sudah lama Anda lupakan, tetapi siapa pun dapat menemukannya. Menakutkan, bukan? Tahukah Anda bahwa kode itu hidup selamanya? Ya, dia hidup selamanya.
Kode ini hidup selamanya. Dan kode yang baik tidak hanya hidup selamanya, tetapi juga tumbuh karena mereka yang menghargainya terus-menerus memastikan bahwa kode tersebut tetap segar. Tumpukan kode berkualitas tinggi dan terpelihara dengan baik ini membantu mengurangi rata-rata ukuran tim teknik karena memungkinkan kami untuk fokus pada kode yang ada daripada menulis kode baru, dan menyelesaikan pekerjaan dengan lebih sedikit orang dan dalam jangka waktu yang lebih singkat.
Alasan ini terdengar menyedihkan, namun idenya adalah bahwa kita semua hanyalah sekelompok automata integrasi yang menggunakan lakban untuk menghubungkan bagian-bagian berbeda dari benda-benda yang ada bersama-sama untuk menciptakan versi yang sedikit berbeda dari benda yang sama. Ini adalah pemikiran klasik di kalangan eksekutif senior yang menyukai outsourcing. “Siapa pun yang tahu cara menggunakan Google dan mempunyai lakban dapat melakukan ini! Lalu mengapa kita membayar banyak uang untuk mesin kita?”
Kami membayar banyak uang kepada manajemen ini, tapi mereka menganggapnya omong kosong. Sekali lagi, poin kunci saya adalah bahwa ada banyak pengembang yang brilian dan pekerja keras di planet kita; mereka benar-benar cemerlang dan rajin, meskipun mereka belum menghabiskan satu menit pun duduk di universitas terakreditasi. Oh ya, sekarang jumlahnya semakin banyak!
Saya tidak menyarankan Anda mulai mengkhawatirkan tempat Anda hanya karena beberapa kawan brilian diduga memburunya. Saya sarankan Anda mulai mengkhawatirkan hal ini karena evolusi pengembangan perangkat lunak mungkin bergerak lebih cepat daripada Anda. Anda telah bekerja selama sepuluh tahun, lima di antaranya sebagai manajer, dan Anda berpikir: “Saya sudah tahu bagaimana perangkat lunak dikembangkan.” Ya, kamu tahu. Selamat tinggal…
Berhenti menulis kode, tapi...
Jika Anda mengikuti saran awal saya dan berhenti menulis kode, Anda juga akan secara sukarela berhenti berpartisipasi dalam proses pembuatan. Karena alasan inilah saya tidak aktif menggunakan outsourcing. Automata tidak menciptakan, mereka memproduksi. Proses yang dirancang dengan baik menghemat banyak uang, namun tidak membawa sesuatu yang baru ke dunia kita.
Jika Anda memiliki tim kecil yang melakukan banyak hal dengan sedikit uang, maka gagasan untuk berhenti menulis kode sepertinya merupakan keputusan karier yang buruk bagi saya. Bahkan di perusahaan raksasa dengan peraturan, proses, dan kebijakan yang tiada habisnya, Anda tidak berhak melupakan cara mengembangkan perangkat lunak sendiri. Dan pengembangan perangkat lunak terus berubah. Saat ini sedang berubah. Di bawah kakimu! Saat ini juga!
Anda mempunyai keberatan. Memahami. Mari dengarkan.
“Rands, aku sedang menuju kursi direktur! Jika saya terus menulis kode, tidak ada yang akan percaya bahwa saya bisa berkembang.”
Saya ingin menanyakan ini kepada Anda: sejak Anda duduk di kursi “Saya akan menjadi CEO!”, pernahkah Anda memperhatikan bahwa lanskap pengembangan perangkat lunak sedang berubah, bahkan di dalam perusahaan Anda? Jika jawaban Anda adalah ya, maka saya akan menanyakan pertanyaan lain: bagaimana sebenarnya perubahannya dan apa yang akan Anda lakukan terhadap perubahan ini? Jika Anda menjawab “tidak” pada pertanyaan pertama saya, maka Anda perlu pindah ke kursi lain, karena (saya yakin!) bidang pengembangan perangkat lunak sedang berubah saat ini. Bagaimana Anda bisa berkembang jika perlahan tapi pasti Anda lupa cara mengembangkan perangkat lunak?
Saran saya adalah jangan berkomitmen untuk menerapkan banyak fitur untuk produk Anda berikutnya. Anda harus terus-menerus mengambil langkah-langkah untuk terus mengetahui cara tim Anda membangun perangkat lunak. Anda dapat melakukan ini baik sebagai direktur maupun sebagai wakil presiden. Sesuatu yang lain?
“Ih, Rand! Tapi seseorang harus menjadi wasit! Seseorang harus melihat gambaran besarnya. Jika saya menulis kode, saya akan kehilangan perspektif."
Anda masih harus menjadi wasit, Anda masih harus menyiarkan keputusan, dan Anda masih harus berjalan mengelilingi gedung empat kali setiap Senin pagi bersama salah satu teknisi Anda untuk mendengarkan kata-kata kasar mingguannya "Kita semua dikutuk" selama 30 menit. ! Namun di luar semua itu, Anda harus mempertahankan pola pikir teknik, dan Anda tidak harus menjadi programmer penuh waktu untuk melakukan itu.
Kiat saya untuk menjaga mentalitas teknik:
- Gunakan lingkungan pengembangan. Ini berarti Anda harus memahami alat tim Anda, termasuk sistem pembuatan kode, kontrol versi, dan bahasa pemrograman. Hasilnya, Anda akan mahir dalam bahasa yang digunakan tim Anda ketika berbicara tentang pengembangan produk. Ini juga memungkinkan Anda untuk terus menggunakan editor teks favorit Anda, yang berfungsi dengan sempurna.
- Anda harus dapat menggambar diagram arsitektur terperinci yang menggambarkan produk Anda di permukaan apa pun dan kapan pun. Yang saya maksud bukan versi sederhana dengan tiga sel dan dua panah. Anda harus mengetahui diagram detail produk. Yang paling sulit. Bukan sembarang diagram yang lucu, melainkan diagram yang sulit dijelaskan. Ini harus berupa peta yang cocok untuk pemahaman lengkap tentang produk. Ini terus berubah, dan Anda harus selalu mengetahui mengapa perubahan tertentu terjadi.
- Ambil alih pelaksanaan salah satu fungsi. Saya benar-benar meringis saat menulis ini karena poin ini memiliki banyak bahaya tersembunyi, tetapi saya benar-benar tidak yakin Anda dapat mencapai poin #1 dan poin #2 tanpa berkomitmen untuk mengimplementasikan setidaknya satu fitur. Dengan mengimplementasikan sendiri salah satu fitur, Anda tidak hanya akan terlibat aktif dalam proses pengembangan, tetapi juga memungkinkan Anda beralih secara berkala dari peran “Manajer yang bertanggung jawab atas segalanya” ke peran “Orang yang bertanggung jawab mengimplementasikan satu fitur.” dari fungsinya.” Sikap rendah hati dan sederhana ini akan mengingatkan Anda akan pentingnya keputusan kecil.
- Seluruh tubuhku masih gemetar. Sepertinya seseorang sudah meneriaki saya: "Manajer yang mengambil sendiri implementasi fungsinya?!" (Dan saya setuju dengannya!) Ya, Anda masih manajernya, yang berarti fungsinya harus kecil, oke? Ya, masih banyak yang harus kamu lakukan. Jika Anda tidak dapat menerapkan fungsi tersebut, saya punya beberapa saran cadangan untuk Anda: perbaiki beberapa bug. Dalam hal ini, Anda tidak akan merasakan nikmatnya berkreasi, tetapi Anda akan memiliki pemahaman tentang bagaimana produk itu dibuat, yang berarti Anda tidak akan pernah kehilangan pekerjaan.
- Tulis tes unit. Saya masih melakukan ini di akhir siklus produksi ketika orang-orang mulai menjadi gila. Anggap saja sebagai daftar periksa kesehatan untuk produk Anda. Lakukan ini sesering mungkin.
Keberatan lagi?
“Rands, jika saya menulis kode, saya akan membingungkan tim saya. Mereka tidak akan tahu siapa saya—seorang manajer atau pengembang.”
Bagus
Ya, saya berkata, "Oke!" Saya senang Anda berpikir Anda dapat membingungkan tim Anda hanya dengan berenang di kolam pengembang. Sederhana saja: batasan antara berbagai peran dalam pengembangan perangkat lunak saat ini sangat kabur. Orang-orang UI melakukan apa yang secara luas disebut pemrograman JavaScript dan CSS. Pengembang belajar lebih banyak tentang desain pengalaman pengguna. Orang-orang berkomunikasi satu sama lain dan belajar tentang bug, tentang pencurian kode orang lain, dan juga tentang fakta bahwa tidak ada alasan yang baik bagi seorang manajer untuk tidak berpartisipasi dalam bacchanalia informasi yang masif, global, dan saling melakukan penyerbukan silang ini.
Selain itu, apakah Anda ingin menjadi bagian dari tim yang terdiri dari komponen-komponen yang mudah diganti? Hal ini tidak hanya membuat tim Anda lebih gesit, tetapi juga memberikan kesempatan kepada setiap anggota tim untuk melihat produk dan perusahaan dari berbagai sudut pandang. Bagaimana Anda bisa menghormati Frank, pria tenang yang bertanggung jawab atas pembangunan, seperti halnya setelah melihat keanggunan sederhana dari skrip pembangunannya?
Saya tidak ingin tim Anda menjadi bingung dan kacau. Sebaliknya, saya ingin tim Anda berkomunikasi lebih efektif. Saya yakin jika Anda terlibat dalam pembuatan produk dan mengerjakan fitur, Anda akan lebih dekat dengan tim Anda. Dan yang lebih penting, Anda akan semakin dekat dengan perubahan konstan dalam proses pengembangan perangkat lunak di organisasi Anda.
Jangan berhenti berkembang
Seorang kolega saya di Borland pernah menyerang saya secara verbal karena memanggilnya “pembuat kode”.
“Rands, pembuat kode adalah mesin yang tidak punya pikiran! Monyet! Pembuat kode tidak melakukan hal penting apa pun kecuali menulis baris-baris kode yang tidak berguna dan membosankan. Saya bukan seorang pembuat kode, saya seorang pengembang perangkat lunak!”
Dia benar, dia akan membenci nasihat awal saya kepada CEO baru: “Berhenti menulis kode!” Bukan karena saya menyarankan agar mereka adalah pembuat kode, tetapi lebih karena saya secara proaktif menyarankan agar mereka mulai mengabaikan salah satu bagian terpenting dari pekerjaan mereka: pengembangan perangkat lunak.
Jadi saya telah memperbarui saran saya. Jika Anda ingin menjadi pemimpin yang baik, Anda bisa berhenti menulis kode, tapi...
Bersikaplah fleksibel. Ingatlah apa artinya menjadi seorang insinyur dan jangan berhenti mengembangkan perangkat lunak.
Tentang penulis
Michael Lopp adalah pengembang perangkat lunak veteran yang masih belum meninggalkan Silicon Valley. Selama 20 tahun terakhir, Michael telah bekerja untuk berbagai perusahaan inovatif, termasuk Apple, Netscape, Symantec, Borland, Palantir, Pinterest, dan juga berpartisipasi dalam startup yang perlahan terlupakan.
Di luar pekerjaan, Michael menjalankan blog populer tentang teknologi dan manajemen dengan nama samaran Rands, di mana ia mendiskusikan ide-ide di bidang manajemen dengan pembaca, mengungkapkan keprihatinan tentang perlunya terus-menerus memantau perkembangan, dan menjelaskan bahwa, meskipun ada imbalan yang besar untuk menciptakan suatu produk, kesuksesan Anda hanya mungkin terjadi berkat tim Anda. Blognya dapat ditemukan di sini .
Michael tinggal bersama keluarganya di Redwood, California. Dia selalu meluangkan waktu untuk bersepeda gunung, bermain hoki, dan minum anggur merah, karena menjadi sehat lebih penting daripada sibuk.
»Detail lebih lanjut tentang buku ini dapat ditemukan di
»
»
Untuk Khabrozhiteley diskon 20% menggunakan kupon - Mengatur orang
Setelah pembayaran untuk buku versi kertas, versi elektronik buku tersebut akan dikirim melalui email.
PS: 7% dari harga buku akan digunakan untuk terjemahan buku komputer baru, daftar buku diserahkan ke percetakan .
Sumber: www.habr.com