Buku “Bagaimana mengelola intelektual. Saya, kutu buku dan Geeks "

Didedikasikan untuk manajer proyek (dan mereka yang bermimpi menjadi bos).

Menulis banyak kode sulit, dan mengelola orang bahkan lebih sulit! Jadi, Anda hanya perlu buku ini untuk mempelajari cara melakukan keduanya.

Apakah mungkin untuk menggabungkan cerita keren dan pelajaran serius? Michael Lopp (juga dikenal di kalangan sempit sebagai Randes) berhasil. Cerita-cerita fiksi tentang orang-orang fiksi dengan pengalaman yang sangat berguna (walaupun fiksi) menunggu Anda. Inilah bagaimana Randy berbagi pengalamannya yang beragam, 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 mengerti apa yang bosmu lakukan sepanjang hari? Rand akan mengajarkan Anda bagaimana cara bertahan hidup di Dunia Beracun Kalkun Inflated dan berkembang dalam kegilaan umum orang-orang bersemangat yang disfungsi. Dalam komunitas aneh ini, bahkan ada makhluk aneh - manajer yang melalui ritual organisasi mistis telah memperoleh kekuasaan atas rencana, pemikiran, dan rekening bank banyak orang.

Buku ini tidak seperti naskah tentang manajemen atau kepemimpinan. Michael Lopp tidak menyembunyikan apa pun, ia hanya menceritakan segalanya apa adanya (mungkin tidak semua berita harus dipublikasikan: R). Tapi hanya dengan cara ini Anda akan mengerti bagaimana Anda bisa bertahan hidup dengan bos seperti itu, bagaimana mengelola Geeks dan kutu buku, dan bagaimana membawa "proyek sialan itu" ke akhir yang bahagia!

Kutipan. Mentalitas teknik

Pikiran tentang topik: apakah Anda perlu terus menulis kode

Ada daftar singkat manajer modern yang harus dilakukan di buku Rands tentang aturan kepemimpinan. Singkatnya daftar ini bermula dari fakta bahwa konsep "harus" adalah semacam absolut, dan ketika menyangkut orang, maka ada sangat sedikit konsep absolut. Metode yang berhasil dalam mengelola satu karyawan akan menjadi bencana nyata bagi karyawan lainnya. Gagasan ini adalah item pertama pada daftar "harus-lakukan" manajerial:

Tetap fleksibel!

Mempertimbangkan bahwa Anda sudah tahu segalanya adalah ide yang sangat buruk. Dalam situasi di mana satu-satunya fakta yang tidak berubah adalah fakta bahwa perubahan terus-menerus terjadi di dunia, fleksibilitas menjadi satu-satunya posisi yang sebenarnya.

Secara paradoks, item kedua dalam daftar secara mengejutkan tidak fleksibel. Namun, item ini adalah favorit pribadi saya, karena saya percaya itu membantu untuk menciptakan fondasi bagi pertumbuhan manajerial. Paragraf ini berbunyi:

Berhenti menulis kode!

Secara teoritis, jika Anda ingin menjadi seorang pemimpin, Anda harus belajar untuk memercayai mereka yang bekerja untuk Anda, dan sepenuhnya menyerahkan penulisan kode kepada mereka. Nasihat ini biasanya sulit untuk "dicerna", terutama oleh para pemimpin baru. Mungkin salah satu alasan mengapa mereka menjadi pemimpin adalah produktivitas mereka dalam pembangunan, dan ketika segalanya serba salah, reaksi pertama mereka adalah menggunakan keterampilan yang membuat mereka benar-benar percaya diri, yaitu, kemampuan mereka untuk menulis kode.

Ketika saya melihat bahwa pemimpin yang baru dicetak "jatuh" sebelum menulis kode, saya katakan kepadanya: "Kami tahu bahwa Anda dapat menulis kode. Pertanyaannya berbeda: apakah Anda tahu cara memimpin? Anda tidak lagi bertanggung jawab untuk diri sendiri, Anda bertanggung jawab untuk seluruh tim; dan saya ingin memastikan bahwa Anda dapat membuat tim Anda untuk menyelesaikan masalah sendiri, tanpa harus menulis kode sendiri. Tugas Anda adalah mencari tahu bagaimana mengukur diri sendiri. Saya ingin Anda tidak menjadi satu-satunya, saya ingin begitu banyak orang seperti Anda. "

Saran yang bagus, bukan? Skala. Manajemen Tanggung jawab Kata kunci yang umum. Sangat disayangkan bahwa saran itu salah.

Salah

Ya Nasihatnya salah! Bukan berarti itu sepenuhnya salah, tetapi cukup salah sehingga saya harus memanggil beberapa mantan rekan kerja dan meminta maaf: "Ingat pernyataan favorit saya bahwa Anda harus berhenti menulis kode? Itu salah! Ya ... mulai pemrograman lagi. Mulai dengan Python dan Ruby. Ya saya serius! Karir Anda tergantung padanya! "

Ketika saya memulai karir saya sebagai pengembang perangkat lunak di Borland, saya bekerja di tim Paradox untuk Windows, dan itu adalah tim yang sangat besar. Hanya satu pengembang aplikasi adalah 13 orang. Jika kami menambahkan orang-orang dari tim lain yang juga terus-menerus bekerja pada teknologi utama untuk proyek ini, seperti mesin basis data utama dan layanan aplikasi utama, kami melibatkan 50 insinyur yang terlibat langsung dalam pengembangan produk ini.

Tidak ada tim lain yang pernah bekerja untuk saya yang memiliki ukuran yang hampir sama. Bahkan, setiap tahun, jumlah orang di tim tempat saya bekerja semakin berkurang. Apa yang sedang terjadi Apakah kita para pengembang secara kolektif menjadi semakin pintar dan pintar? Tidak, kami hanya mendistribusikan beban.

Apa yang telah dilakukan pengembang selama 20 tahun terakhir? Selama ini, kami menulis banyak kode omong kosong. Lautan kode! Kami menulis begitu banyak kode sehingga kami memutuskan: alangkah baiknya untuk menyederhanakan semuanya dan beralih ke kode sumber terbuka.

Untungnya, berkat Internet, proses ini sekarang menjadi sesederhana mungkin. Jika Anda seorang pengembang perangkat lunak, Anda dapat memeriksanya sekarang! Cari nama Anda di Google atau di Github, dan Anda akan melihat kode yang sudah lama Anda lupakan, tetapi siapa saja yang ingin dapat menemukannya. Menakutkan, ya? Anda tidak tahu bahwa kode itu hidup selamanya? Ya, dia hidup selamanya.

Kode itu hidup selamanya. Kode yang baik tidak hanya hidup selamanya, tetapi juga tumbuh, karena mereka yang menghargainya selalu menjaga agar kode tersebut tidak kehilangan kesegarannya. Kumpulan kode berkualitas tinggi dan terawat baik ini membantu mengurangi ukuran rata-rata tim teknik, karena memungkinkan kita untuk fokus bukan pada penulisan kode baru, tetapi pada kode yang ada dan untuk bekerja dengan lebih sedikit orang yang terlibat dan dalam waktu yang lebih singkat.

Garis pemikiran ini terdengar menyedihkan, tetapi idenya adalah bahwa kita semua hanyalah sekelompok mesin integrasi yang menggunakan lakban untuk menghubungkan potongan-potongan berbeda dari benda-benda yang ada bersama-sama untuk membuat versi yang sedikit berbeda dari hal yang sama. Ini adalah garis pemikiran klasik untuk manajemen puncak yang menyukai outsourcing. “Ini bisa dilakukan oleh siapa saja yang tahu cara menggunakan Google dan yang memiliki pita perekat! Lalu mengapa kita membayar banyak uang ke mesin penjual otomatis kita? "

Kami membayar eksekutif jenis ini uang sangat besar, dan mereka menganggap omong kosong seperti itu. Sekali lagi: ide utama saya adalah bahwa ada banyak pengembang yang brilian dan sangat rajin di planet kita; mereka benar-benar brilian dan bersemangat, meskipun mereka belum menghabiskan satu menit pun duduk di universitas terakreditasi. Oh ya, sekarang mereka semakin banyak!

Saya tidak menyarankan agar Anda mulai khawatir tentang tempat Anda hanya karena beberapa kawan cemerlang seharusnya memangsa dia. Saya sarankan Anda mulai mengkhawatirkannya, karena evolusi pengembangan perangkat lunak mungkin bergerak lebih cepat daripada Anda. Anda telah bekerja selama sepuluh tahun, dimana lima tahun sebagai pemimpin, dan Anda berpikir: "Saya sudah tahu bagaimana perangkat lunak dikembangkan." Ya kamu tahu Sampai jumpa ...

Berhenti menulis kode, tetapi ...

Jika Anda mengikuti saran awal saya dan berhenti menulis kode, maka pada saat yang sama Anda akan secara sukarela berhenti berpartisipasi dalam proses pembuatan. Karena alasan inilah saya tidak terlalu aktif dalam outsourcing. Mesin tidak membuat, mereka menghasilkan. Proses yang dirancang dengan baik dapat menghemat banyak uang, tetapi mereka tidak akan membawa sesuatu yang baru ke dunia kita.

Jika Anda memiliki tim kecil dan itu menghasilkan banyak uang, maka gagasan untuk berhenti menulis kode sepertinya keputusan karir yang buruk. Bahkan di perusahaan monster dengan peraturan, proses, dan kebijakan mereka yang tiada akhir, Anda tidak punya hak untuk melupakan bagaimana mengembangkan perangkat lunak sendiri. Dan pengembangan perangkat lunak terus berubah. Dia berubah sekarang. Di bawah kakimu! Detik ini juga!

Anda keberatan. Saya mengerti Mari kita dengarkan.

"Randy, aku sedang menuju kursi direktur!" Jika saya terus menulis kode, tidak ada yang akan percaya bahwa saya dapat tumbuh. "

Saya ingin bertanya kepada Anda: sejak Anda duduk, “Saya akan segera menjadi direktur!”, Pernahkah Anda memperhatikan bahwa bidang pengembangan perangkat lunak berubah bahkan di dalam perusahaan Anda? Jika jawaban Anda adalah ya, maka saya akan mengajukan pertanyaan lain: bagaimana tepatnya hal itu berubah dan apa yang akan Anda lakukan sehubungan dengan perubahan ini? Jika Anda menjawab "tidak" untuk pertanyaan pertama saya, maka Anda perlu pindah ke kursi lain, karena (saya beri gigi!) Ruang lingkup pengembangan perangkat lunak berubah saat ini juga. Bagaimana Anda akan tumbuh sama sekali jika Anda perlahan tapi pasti lupa bagaimana mengembangkan perangkat lunak?

Saran saya adalah jangan mempercayakan diri Anda dengan banyak fitur untuk produk Anda berikutnya. Anda harus terus-menerus mengambil langkah-langkah untuk tetap diperbarui tentang bagaimana tim Anda menciptakan perangkat lunak. Anda dapat melakukan ini baik sebagai direktur dan sebagai wakil presiden. Sesuatu yang lain

“Uh, Randy! Tetapi seseorang harus menjadi wasit! Seseorang harus melihat gambaran besarnya. Jika saya menulis kode, saya akan kehilangan prospek. "

Anda masih harus tetap wasit, Anda masih harus menyiarkan keputusan, dan Anda masih harus berkeliling gedung empat kali setiap Senin pagi dengan salah satu insinyur Anda untuk mendengarkan omelan mingguannya selama 30 menit: “Kita semua dikutuk ! " Tetapi di samping semua ini, Anda harus menjaga cara berpikir teknik dalam diri Anda, dan untuk ini Anda tidak harus menjadi programmer penuh waktu.

Saran saya tentang menjaga mentalitas teknik:

1. Gunakan lingkungan pengembangan. Ini berarti Anda harus terbiasa dengan alat tim Anda, termasuk sistem pembuatan kode, kontrol versi, dan bahasa pemrograman. Sebagai akibatnya, Anda akan fasih dalam bahasa yang digunakan oleh tim Anda ketika berbicara tentang pengembangan produk. Ini juga akan memungkinkan Anda untuk terus menggunakan editor teks favorit Anda yang berfungsi dengan baik.
2. Anda harus dapat menggambar diagram arsitektur terperinci yang menjelaskan produk Anda di permukaan apa pun dan kapan saja. Sekarang saya tidak bermaksud versi yang disederhanakan dengan tiga sel dan dua panah. Anda harus mengetahui diagram produk terperinci. Yang paling sulit. Bukan sembarang skema cantik, tapi skema yang sulit dijelaskan. Ini harus berupa kartu yang cocok untuk pemahaman lengkap tentang produk. Itu terus berubah, dan Anda harus selalu tahu mengapa ini atau perubahan lainnya terjadi.
3. Ambil implementasi salah satu fungsi. Saya benar-benar gemetar ketika saya menulis ini, karena paragraf ini penuh dengan banyak bahaya tersembunyi, tetapi saya benar-benar tidak yakin bahwa Anda dapat memenuhi paragraf 1 dan paragraf 2 tanpa mengambil setidaknya satu fungsi . Berkat implementasi independen dari salah satu fungsi, Anda tidak hanya akan secara aktif berpartisipasi dalam proses pengembangan, itu juga akan memungkinkan Anda untuk secara berkala beralih dari peran "Manajer yang bertanggung jawab atas segalanya" ke peran "Orang yang bertanggung jawab atas implementasi salah satu fungsi". Posisi sederhana dan tidak bersahaja ini akan mengingatkan Anda akan pentingnya keputusan kecil.
4. Saya masih gemetaran. Sepertinya seseorang sudah meneriaki saya: “Pemimpin yang mengambil alih pelaksanaan fungsi ?! (Dan saya setuju dengan dia!) Ya, Anda masih tetap seorang pemimpin, yang berarti harus ada fungsi kecil, oke? Ya, masih banyak yang harus Anda lakukan. Jika Anda tidak bisa menerapkan fungsi dengan cara apa pun, maka saya punya tip cadangan untuk Anda: berurusan dengan beberapa bug. Dalam hal ini, Anda tidak akan merasakan kegembiraan penciptaan, tetapi Anda akan memiliki pemahaman tentang bagaimana produk itu dibuat, yang berarti Anda tidak akan pernah kehilangan pekerjaan.
5. Tulis tes unit. Saya masih melakukan ini pada tahap akhir dari siklus produksi, ketika orang-orang mulai menjadi gila. Anggap saja sebagai daftar periksa kesehatan untuk produk Anda. Sering melakukannya.

Keberatan lagi?

“Rand, jika aku menulis kodenya, maka aku akan membingungkan timku. Mereka tidak akan tahu siapa saya, pemimpin atau pengembang. "

Bagus

Ya, saya berkata, "Bagus!" Saya senang Anda percaya bahwa Anda dapat membingungkan tim Anda hanya dengan berenang di kolam pengembang. Semuanya sederhana di sini: batas-batas antara berbagai peran di bidang pengembangan perangkat lunak saat ini sangat kabur. Para pengguna UI sedang melakukan apa yang secara umum dapat disebut pemrograman JavaScript dan CSS. Pengembang semakin banyak belajar tentang merancang interaksi pengguna. Orang-orang berkomunikasi satu sama lain dan belajar tentang kesalahan, pencurian kode orang lain, dan juga bahwa tidak ada alasan yang baik bagi pemimpin untuk tidak dapat berpartisipasi dalam bacchanalia informasi yang besar, global, dan diserbuki silang ini.

Juga, apakah Anda ingin menjadi bagian dari tim yang terdiri dari komponen yang mudah diganti? Ini tidak hanya akan membuat tim Anda lebih gesit, itu akan memberikan masing-masing anggotanya kesempatan untuk melihat produk dan perusahaan dari berbagai sudut pandang. Bagaimana Anda masih bisa menghormati Frank, pria keren yang bertanggung jawab atas tata letak, jika tidak setelah Anda melihat keanggunan sederhana dari skrip perakitannya?

Saya tidak ingin kebingungan dan kekacauan berkuasa di tim Anda. Sebaliknya, saya ingin komunikasi di tim Anda menjadi lebih efektif. Saya yakin bahwa jika Anda sendiri terlibat dalam menciptakan produk dan mengerjakan fitur, Anda akan lebih dekat dengan tim Anda. Dan yang lebih penting, Anda akan lebih dekat dengan perubahan konstan dalam proses pengembangan perangkat lunak dalam organisasi Anda.

Jangan berhenti berkembang

Seorang kolega saya di Borland pernah secara verbal menyerang saya karena memanggilnya "pembuat kode".

"Rand, pembuat enkode adalah mesin yang tidak punya otak! Monyet Encoder tidak melakukan apa pun selain menulis baris membosankan dari kode yang tidak berguna. Saya bukan pembuat kode, saya seorang pengembang perangkat lunak! "

Dia benar, dia akan membenci saran awal saya kepada para pemimpin baru: "Berhenti menulis kode!" Bukan karena dengan ini saya seharusnya menganggap bahwa mereka adalah coders, tetapi lebih karena saya secara proaktif menyarankan agar mereka mulai mengabaikan salah satu bagian terpenting dari pekerjaan mereka - pengembangan perangkat lunak.

Jadi, saya menyelesaikan saran saya. Jika Anda ingin menjadi pemimpin yang baik, maka Anda dapat berhenti menulis kode, tetapi ...

Jadilah fleksibel. Ingat apa artinya menjadi seorang insinyur, dan jangan berhenti mengembangkan perangkat lunak.

Tentang penulis

Michael Lopp adalah veteran pengembang perangkat lunak yang masih belum meninggalkan Lembah Silikon. Selama 20 tahun terakhir, Michael berhasil bekerja di berbagai perusahaan inovatif, termasuk Apple, Netscape, Symantec, Borland, Palantir, Pinterest, dan juga berpartisipasi dalam startup yang perlahan-lahan mulai terlupakan.

Selain karyanya, Michael mengelola blog populer tentang teknologi dan manajemen di bawah nama samaran Rands, di mana ia membahas ide-ide manajemen dengan pembaca, menyatakan keprihatinan tentang kebutuhan yang konstan untuk terus mengikuti dan menjelaskan bahwa, meskipun imbalan yang murah hati untuk produk yang dibuat, kesuksesan Anda hanya mungkin terjadi. terima kasih untuk tim kamu. Blog dapat ditemukan di www.randsinrepose.com .

Michael tinggal bersama keluarganya di Redwood, California. Dia selalu menemukan waktu untuk naik sepeda gunung, bermain hoki dan minum anggur merah, karena menjadi sehat lebih penting daripada sibuk.

»Informasi lebih lanjut tentang buku ini dapat ditemukan di situs web penerbit
» Isi
» Kutipan

Kupon diskon 20% untuk penjaja - Mengelola Manusia

Setelah pembayaran versi kertas buku, versi elektronik buku dikirim melalui email.

PS: 7% dari biaya buku akan masuk ke terjemahan buku komputer baru, daftar buku yang diserahkan ke percetakan ada di sini .