Buku “Cara mengurus intelek. Saya, kutu buku dan geek"

Didedikasikan kepada pengurus projek (dan mereka yang bermimpi untuk menjadi bos).

Menulis banyak kod adalah sukar, tetapi mengurus orang adalah lebih sukar! Jadi anda hanya perlukan buku ini untuk belajar cara melakukan kedua-duanya.

Adakah mungkin untuk menggabungkan cerita lucu dan pelajaran yang serius? Michael Lopp (juga dikenali dalam kalangan sempit sebagai Rands) berjaya. Anda akan menemui cerita fiksyen tentang orang fiksyen dengan pengalaman yang sangat bermanfaat (walaupun fiksyen). Beginilah cara Rands berkongsi pengalamannya yang pelbagai, kadangkala pelik yang diperolehi selama bertahun-tahun bekerja di syarikat IT besar: Apple, Pinterest, Palantir, Netscape, Symantec, dsb.

Adakah anda seorang pengurus projek? Atau mahu memahami apa yang bos sialan anda lakukan sepanjang hari? Rands akan mengajar anda cara untuk terus hidup dalam Dunia Toksik Turki Kembung dan berkembang maju dalam kegilaan umum orang yang tidak berfungsi dengan flamboyan. Dalam komuniti pelik otak gila ini terdapat makhluk yang lebih asing - pengurus yang, melalui ritual organisasi mistik, telah mendapat kuasa ke atas rancangan, pemikiran dan akaun bank ramai orang.

Buku ini tidak seperti mana-mana manuskrip pengurusan atau kepimpinan. Michael Lopp tidak menyembunyikan apa-apa, dia hanya memberitahunya seperti itu (mungkin tidak semua cerita harus didedahkan kepada umum: P). Tetapi hanya dengan cara ini anda akan memahami bagaimana untuk terus hidup dengan bos seperti itu, bagaimana untuk menguruskan geek dan kutu buku, dan bagaimana untuk membawa "projek terkutuk itu" kepada pengakhiran yang bahagia!

Petikan. Mentaliti kejuruteraan

Fikiran tentang: Perlukah Anda Teruskan Menulis Kod?

Buku Rands tentang peraturan untuk pengurus mengandungi senarai ringkas "wajib" pengurusan moden. Laconicism senarai ini berpunca daripada fakta bahawa konsep "mesti" adalah sejenis mutlak, dan apabila ia datang kepada orang, terdapat sangat sedikit konsep mutlak. Kaedah pengurusan yang berjaya untuk seorang pekerja akan menjadi bencana sebenar bagi yang lain. Pemikiran ini ialah item pertama dalam senarai "mesti buat" pengurus:

Kekal fleksibel!

Berfikir bahawa anda sudah mengetahui segala-galanya adalah idea yang sangat buruk. Dalam keadaan di mana satu-satunya fakta yang berterusan ialah dunia sentiasa berubah, fleksibiliti menjadi satu-satunya kedudukan yang betul.

Secara paradoks, item kedua dalam senarai itu sangat tidak fleksibel. Walau bagaimanapun, perkara ini adalah kegemaran peribadi saya kerana saya percaya ia membantu mewujudkan asas untuk pertumbuhan pengurusan. Perenggan ini berbunyi:

Berhenti menulis kod!

Secara teorinya, jika anda ingin menjadi pengurus, anda perlu belajar mempercayai mereka yang bekerja untuk anda dan menyerahkan pengekodan sepenuhnya kepada mereka. Nasihat ini biasanya sukar dihadam, terutamanya bagi pengurus yang baru dicetak. Mungkin salah satu sebab mereka menjadi pengurus adalah kerana produktiviti mereka dalam pembangunan, dan apabila berlaku masalah, reaksi pertama mereka adalah untuk kembali kepada kemahiran yang mereka yakini sepenuhnya, iaitu keupayaan mereka untuk menulis kod.

Apabila saya melihat bahawa pengurus yang baru dicetak "tenggelam" dalam menulis kod, saya memberitahunya: "Kami tahu bahawa anda boleh menulis kod. Persoalannya ialah: bolehkah anda memimpin? Anda tidak lagi bertanggungjawab untuk diri sendiri sahaja, anda bertanggungjawab untuk keseluruhan pasukan; dan saya ingin memastikan bahawa anda boleh mendapatkan pasukan anda untuk menyelesaikan masalah mereka sendiri, tanpa anda perlu menulis kod itu sendiri. Tugas anda adalah untuk memikirkan cara untuk mengukur diri anda. Saya tidak mahu awak menjadi seorang sahaja, saya mahu ramai seperti awak.”

Nasihat yang baik, bukan? Skala. Pengurusan. Tanggungjawab. Kata-kata yang begitu biasa. Sayang sekali nasihat itu salah.

tak betul?

Yeah. Nasihat itu salah! Tidak salah sepenuhnya, tetapi cukup salah sehingga saya terpaksa menghubungi beberapa bekas rakan sekerja dan meminta maaf: “Ingat kenyataan kegemaran saya tentang bagaimana anda harus berhenti menulis kod? Ia salah! Ya... Mulakan pengaturcaraan semula. Mulakan dengan Python dan Ruby. Ya, saya serius! Kerjaya anda bergantung padanya!”

Apabila saya memulakan kerjaya saya sebagai pembangun perisian di Borland, saya bekerja pada pasukan Windows Paradox, yang merupakan pasukan yang besar. Terdapat 13 pembangun aplikasi sahaja. Jika anda menambah orang daripada pasukan lain yang juga sentiasa mengusahakan teknologi utama untuk projek ini, seperti enjin pangkalan data teras dan perkhidmatan aplikasi teras, anda mendapat 50 jurutera yang terlibat secara langsung dalam pembangunan produk ini.

Tiada pasukan lain yang pernah saya kerjakan malah mencapai saiz ini. Malah, dengan setiap tahun yang berlalu, bilangan orang dalam pasukan yang saya bekerjasama semakin berkurangan. Apa yang sedang berlaku? Adakah kita pembangun secara kolektif semakin pintar dan lebih pintar? Tidak, kami hanya berkongsi beban.

Apakah yang telah dilakukan oleh pemaju selama 20 tahun yang lalu? Pada masa ini kami menulis banyak kod. Laut kod! Kami menulis begitu banyak kod sehingga kami memutuskan bahawa adalah idea yang baik untuk memudahkan segala-galanya dan menggunakan sumber terbuka.

Nasib baik, terima kasih kepada Internet, proses ini kini menjadi semudah mungkin. Jika anda seorang pembangun perisian, anda boleh menyemaknya sekarang! Cari nama anda di Google atau Github dan anda akan melihat kod yang telah lama anda lupakan, tetapi sesiapa sahaja boleh mencari. Menakutkan, bukan? Tidakkah anda tahu bahawa kod hidup selama-lamanya? Ya, dia hidup selamanya.

Kod itu kekal selama-lamanya. Dan kod yang baik bukan sahaja kekal selama-lamanya, ia berkembang kerana mereka yang menghargainya sentiasa memastikan ia kekal segar. Longgokan kod berkualiti tinggi dan diselenggara dengan baik ini membantu mengurangkan purata saiz pasukan kejuruteraan kerana ia membolehkan kami menumpukan pada kod sedia ada dan bukannya menulis kod baharu dan menyelesaikan tugas dengan lebih sedikit orang dan dalam jangka masa yang lebih singkat.

Garis penaakulan ini kedengaran menyedihkan, tetapi ideanya ialah kita semua hanyalah sekumpulan automata integrasi yang menggunakan pita pelekat untuk menyambungkan bahagian yang berbeza daripada perkara sedia ada bersama-sama untuk mencipta versi yang sedikit berbeza bagi perkara yang sama. Ini adalah garis pemikiran klasik di kalangan eksekutif kanan yang suka penyumberan luar. “Sesiapa sahaja yang tahu cara menggunakan Google dan mempunyai pita pelekat boleh melakukan ini! Jadi mengapa kita membayar banyak wang kepada mesin kita?”

Kami membayar orang pengurusan ini dengan wang yang sangat besar, tetapi mereka menganggap perkara yang tidak masuk akal. Sekali lagi, perkara utama saya ialah terdapat banyak pembangun yang cemerlang dan sangat bekerja keras di planet kita; mereka benar-benar cemerlang dan rajin, walaupun mereka tidak menghabiskan satu minit pun duduk di universiti bertauliah. Oh ya, kini semakin ramai!

Saya tidak mencadangkan anda mula bimbang tentang tempat anda hanya kerana beberapa rakan yang cemerlang didakwa memburunya. Saya cadangkan anda mula bimbang tentangnya kerana evolusi pembangunan perisian mungkin bergerak lebih pantas daripada anda. Anda telah bekerja selama sepuluh tahun, lima daripada mereka sebagai pengurus, dan anda fikir: "Saya sudah tahu cara perisian dibangunkan." Ya, awak tahu. selamat tinggal…

Berhenti menulis kod, tetapi...

Jika anda mengikut nasihat asal saya dan berhenti menulis kod, anda juga secara sukarela akan berhenti mengambil bahagian dalam proses penciptaan. Atas sebab inilah saya tidak aktif menggunakan penyumberan luar. Automata tidak mencipta, mereka menghasilkan. Proses yang direka dengan baik menjimatkan banyak wang, tetapi ia tidak membawa sesuatu yang baharu kepada dunia kita.

Jika anda mempunyai pasukan kecil melakukan banyak untuk wang yang sedikit, maka idea untuk menghentikan menulis kod kelihatan seperti keputusan kerjaya yang tidak baik kepada saya. Walaupun dalam syarikat raksasa dengan peraturan, proses dan dasar yang tidak berkesudahan, anda tidak berhak untuk melupakan cara membangunkan perisian sendiri. Dan pembangunan perisian sentiasa berubah. Ia berubah sekarang. Di bawah kaki anda! Pada saat ini!

Anda mempunyai bantahan. faham. Jom dengar.

“Rands, saya dalam perjalanan ke kerusi pengarah! Jika saya terus menulis kod, tiada siapa yang akan percaya bahawa saya boleh berkembang.”

Saya ingin bertanya kepada anda ini: sejak anda duduk di kerusi "Saya bakal menjadi CEO!", adakah anda perasan bahawa landskap pembangunan perisian berubah, walaupun dalam syarikat anda? Jika jawapan anda adalah ya, maka saya akan bertanya kepada anda soalan lain: bagaimana sebenarnya ia berubah dan apakah yang akan anda lakukan terhadap perubahan ini? Jika anda menjawab "tidak" kepada soalan pertama saya, maka anda perlu berpindah ke kerusi yang berbeza, kerana (saya yakin!) bidang pembangunan perisian berubah pada saat ini. Bagaimanakah anda akan berkembang jika anda perlahan-lahan tetapi pasti lupa cara membangunkan perisian?

Nasihat saya ialah jangan komited diri anda untuk melaksanakan banyak ciri untuk produk anda yang seterusnya. Anda perlu sentiasa mengambil langkah untuk mengetahui cara pasukan anda membina perisian. Anda boleh melakukan ini sebagai pengarah dan sebagai naib presiden. Sesuatu yang lain?

“Ugh, Rands! Tetapi seseorang harus menjadi penimbang tara! Seseorang perlu melihat gambaran besar. Jika saya menulis kod, saya akan kehilangan perspektif."

Anda masih perlu menjadi pengadil, anda masih perlu menyiarkan keputusan, dan anda masih perlu berjalan di sekitar bangunan empat kali setiap pagi Isnin dengan salah seorang jurutera anda untuk mendengar kata-kata mingguannya "Kita semua ditakdirkan" selama 30 minit.! Tetapi di luar semua itu, anda perlu mengekalkan minda kejuruteraan, dan anda tidak perlu menjadi pengaturcara sepenuh masa untuk melakukannya.

Petua saya untuk mengekalkan mentaliti kejuruteraan:

1. Gunakan persekitaran pembangunan. Ini bermakna anda harus biasa dengan alatan pasukan anda, termasuk sistem binaan kod, kawalan versi dan bahasa pengaturcaraan. Hasilnya, anda akan menjadi mahir dalam bahasa yang digunakan oleh pasukan anda apabila bercakap tentang pembangunan produk. Ini juga akan membolehkan anda terus menggunakan editor teks kegemaran anda, yang berfungsi dengan sempurna.
2. Anda mesti boleh melukis gambar rajah seni bina terperinci yang menerangkan produk anda pada sebarang permukaan pada bila-bila masa. Sekarang saya tidak bermaksud versi mudah dengan tiga sel dan dua anak panah. Anda mesti tahu gambarajah terperinci produk. Yang paling susah. Bukan sebarang rajah comel, tetapi rajah yang sukar untuk dijelaskan. Ia mestilah peta yang sesuai untuk pemahaman lengkap tentang produk. Ia sentiasa berubah, dan anda harus sentiasa tahu mengapa perubahan tertentu berlaku.
3. Mengambil alih pelaksanaan salah satu fungsi. Saya benar-benar merengek semasa saya menulis ini kerana titik ini mempunyai banyak bahaya tersembunyi, tetapi saya benar-benar tidak pasti bahawa anda boleh mencapai titik #1 dan titik #2 tanpa komited untuk melaksanakan sekurang-kurangnya satu ciri . Dengan melaksanakan salah satu ciri itu sendiri, bukan sahaja anda akan terlibat secara aktif dalam proses pembangunan, ia juga akan membolehkan anda beralih secara berkala daripada peranan "Pengurus yang bertanggungjawab ke atas segala-galanya" kepada peranan "Lelaki yang bertanggungjawab melaksanakan satu daripada fungsi tersebut.” Sikap rendah hati dan bersahaja ini akan mengingatkan anda tentang kepentingan keputusan kecil.
4. Saya masih terketar-ketar. Nampaknya seseorang sudah menjerit kepada saya: "Pengurus yang mengambil sendiri pelaksanaan fungsi itu?! (Dan saya bersetuju dengannya!) Ya, anda masih pengurus, bermakna ia sepatutnya menjadi beberapa fungsi kecil, okay? Ya, anda masih banyak yang perlu dilakukan. Jika anda tidak dapat melaksanakan fungsi tersebut, maka saya mempunyai beberapa nasihat ganti untuk anda: betulkan beberapa pepijat. Dalam kes ini, anda tidak akan merasai kegembiraan penciptaan, tetapi anda akan mempunyai pemahaman tentang cara produk itu dicipta, yang bermaksud anda tidak akan pernah diketepikan dari kerja.
5. Tulis ujian unit. Saya masih melakukan ini lewat dalam kitaran pengeluaran apabila orang mula menjadi gila. Anggap ia sebagai senarai semak kesihatan untuk produk anda. Lakukan ini dengan kerap.

Bantahan lagi?

“Rands, jika saya menulis kod, saya akan mengelirukan pasukan saya. Mereka tidak akan tahu siapa saya—seorang pengurus atau pembangun.”

Baiklah.

Ya, saya berkata, "Baiklah!" Saya gembira anda fikir anda boleh mengelirukan pasukan anda hanya dengan berenang di kolam pemaju. Ia mudah: sempadan antara peranan yang berbeza dalam pembangunan perisian pada masa ini sangat kabur. Orang UI melakukan apa yang secara umum boleh dipanggil pengaturcaraan JavaScript dan CSS. Pembangun sedang belajar lebih banyak tentang reka bentuk pengalaman pengguna. Orang ramai berkomunikasi antara satu sama lain dan belajar tentang pepijat, tentang kecurian kod orang lain, dan juga tentang fakta bahawa tidak ada sebab yang kukuh untuk pengurus tidak mengambil bahagian dalam bacchanalia maklumat pendebungaan silang yang besar-besaran, global ini.

Selain itu, adakah anda ingin menjadi sebahagian daripada pasukan yang terdiri daripada komponen yang mudah diganti? Ini bukan sahaja menjadikan pasukan anda lebih lincah, ia akan memberi setiap ahli pasukan peluang untuk melihat produk dan syarikat dari pelbagai perspektif. Bagaimanakah anda boleh menghormati Frank, lelaki yang tenang yang menjaga binaan, lebih daripada selepas melihat keanggunan ringkas skrip binaannya?

Saya tidak mahu pasukan anda menjadi keliru dan huru-hara. Sebaliknya, saya mahu pasukan anda berkomunikasi dengan lebih berkesan. Saya percaya bahawa jika anda terlibat dalam mencipta produk dan mengusahakan ciri, anda akan lebih dekat dengan pasukan anda. Dan yang lebih penting, anda akan lebih dekat dengan perubahan berterusan dalam proses pembangunan perisian dalam organisasi anda.

Jangan berhenti berkembang

Seorang rakan sekerja saya di Borland pernah menyerang saya secara lisan kerana memanggilnya "pengekod."

“Rands, pengekod adalah mesin yang tidak berakal! Monyet! Pengekod tidak melakukan apa-apa yang penting kecuali menulis baris membosankan kod yang tidak berguna. Saya bukan pengekod, saya pembangun perisian!”

Dia betul, dia pasti membenci nasihat awal saya kepada CEO baharu: "Berhenti menulis kod!" Bukan kerana saya mencadangkan bahawa mereka adalah pengkod, tetapi lebih kerana saya secara proaktif mencadangkan bahawa mereka mula mengabaikan salah satu bahagian terpenting dalam tugas mereka: pembangunan perisian.

Jadi saya telah mengemas kini nasihat saya. Jika anda ingin menjadi pemimpin yang baik, anda boleh berhenti menulis kod, tetapi...

Jadilah fleksibel. Ingat apa erti menjadi seorang jurutera dan jangan berhenti membangunkan perisian.

Mengenai pengarang

Michael Lopp ialah pembangun perisian veteran yang masih belum meninggalkan Silicon Valley. Sepanjang 20 tahun yang lalu, Michael telah bekerja untuk pelbagai syarikat inovatif, termasuk Apple, Netscape, Symantec, Borland, Palantir, Pinterest, dan juga mengambil bahagian dalam permulaan yang perlahan-lahan terapung ke dalam kelalaian.

Di luar kerja, Michael mengendalikan blog popular tentang teknologi dan pengurusan di bawah nama samaran Rands, di mana dia membincangkan idea dalam bidang pengurusan dengan pembaca, menyatakan kebimbangan tentang keperluan berterusan untuk mengekalkan jarinya pada nadi, dan menerangkan bahawa, walaupun ganjaran yang besar untuk mencipta produk, kejayaan anda hanya mungkin berkat pasukan anda. Blog boleh didapati di sini www.randsinrepose.com.

Michael tinggal bersama keluarganya di Redwood, California. Dia sentiasa meluangkan masa untuk berbasikal gunung, bermain hoki dan minum wain merah, kerana sihat adalah lebih penting daripada sibuk.

» Butiran lanjut tentang buku boleh didapati di laman web penerbit
» jadual kandungan
» Petikan

Untuk Khabrozhiteley diskaun 20% menggunakan kupon - Mengurus Orang

Selepas pembayaran untuk versi kertas buku, versi elektronik buku akan dihantar melalui e-mel.

PS: 7% daripada harga buku akan pergi ke terjemahan buku komputer baru, senarai buku diserahkan kepada percetakan di sini.

Sumber: www.habr.com