Kami terus membagikan cuplikan dari
panduan bertahan hidup untuk techlides pemula dari J.H. Rainwater. Pada seri pertama, kami berbicara tentang jenis pengembang yang biasanya harus dikerjakan oleh manajer; Sekarang mari kita coba memahami apa yang harus dilakukan dengan semua kebun binatang ini. Kegiatan organisasi dalam tim teknis dapat dibagi menjadi dua bagian - lebih atau kurang hal-hal asli (seperti tinjauan kode dan manajemen arsitektur) dan semua yang tidak disiapkan oleh kehidupan seorang programmer - yaitu, mengelola orang dan proses. Mari kita berurusan dengan orang asing terlebih dahulu.
Prioritas
Hal pertama yang biasanya merobohkan pemimpin yang baru dipanggang adalah longsoran informasi yang paling beragam. Keadaan ini cukup logis: orang yang menjadi ketua tim kurang tertutup dalam kerangka kerjanya dan terlibat dalam lebih banyak proses, tetapi tidak semakin mudah. Akibatnya, pemimpin teknis sering mulai bubar - mengingat tugasnya untuk menanggapi setiap sinyal, ia meraih semuanya sekaligus, melompat dari satu tugas ke tugas lain dan melewatkan apa yang paling membutuhkan perhatian.
Hanya ada satu jalan keluar - untuk menyaring arus informasi ini, memisahkan apa yang secara langsung terkait dengan tugas utama (merilis kode yang memenuhi persyaratan komersial, dengan tenggat waktu yang disepakati), dan mengirimkan yang utama ke tumpukan simpanan. Tetapi pada awalnya, kriteria untuk penyortiran seperti itu mungkin tidak jelas. Untuk pemula, semuanya tampak penting.
Hal-hal rumit adalah kenyataan bahwa banyak rangsangan merangsang emosi yang mengganggu menilai pentingnya dan urgensi suatu masalah. Sinyal yang masuk dapat menyebabkan ketertarikan (anomali yang aneh ditemukan dalam kode), rasa bersalah (perancang ingat bahwa ia telah meminta berkali-kali untuk mengimplementasikan fungsi yang ingin diimplementasikan), apprehension (pengguna menyatakan ketidakpuasan dengan pembaruan).
Agar lebih berhasil mensistematisasikan semua permintaan dan informasi, penulis menyarankan untuk menggunakan matriks berikut untuk memprosesnya:
- Bagaimana data baru memengaruhi ruang lingkup proyek, keputusan desain, dan batas waktu proyek?
- Apakah sumber informasi dapat dipercaya? Jika tidak, bisakah itu diabaikan?
- Haruskah saya bereaksi terhadap penerimaan informasi segera atau bisakah saya menunggu sebentar?
- Di mana dan bagaimana cara menyimpan informasi sehingga jika perlu dapat dengan cepat ditangani?
- Berapa periode validitas informasi? Kapan itu menjadi tidak relevan?
- Bagaimana informasi ini dibandingkan dengan apa yang sudah diketahui tentang proyek?
Seperti yang dapat Anda lihat, matriks ini membantu memisahkan biji-bijian dari sekam dalam beberapa hal: singkirkan informasi yang tidak berguna atau tidak dapat dipercaya secara jujur, menjauh dari apa lagi yang dapat dipindahkan, dan mengevaluasi pentingnya informasi hanya untuk proyek saat ini. Namun, pertanyaan tentang waktu dan metode penyimpanan mengisyaratkan fakta bahwa informasi yang tidak relevan saat ini tidak boleh dianggap sebagai tidak relevan pada prinsipnya - ini adalah ekstrem lain yang akan menyebabkan tim mengalami stagnasi dalam jangka panjang. Kita akan berbicara lebih banyak tentang ini nanti, ketika membahas konsep "kepemimpinan" dan "kepemimpinan".
Proyek yang luas
Titik nyeri berikutnya adalah penilaian volume dan ketentuan pekerjaan. Sekali lagi, untuk beberapa waktu, "berenang" di daerah ini hampir tidak dapat dihindari untuk pemula techlide - pengalaman diperlukan untuk dapat meninjau semua komponen proyek sekaligus, tidak melewatkan apa pun, dan dari upaya pertama yang ditetapkan untuk setiap jenis pekerjaan, termasuk ketentuan yang tidak familier dan memadai. Tetapi bahkan pengalaman yang diperoleh tidak menyelamatkan dari kesalahan tertentu, dan tidak mungkin untuk menguranginya menjadi nol. Akurasi ekstrem dalam perencanaan kerja terhalang oleh dua undang-undang yang dirumuskan dengan tepat oleh Humphrey:
Proses apa pun akan bertahan lebih lama dari yang Anda harapkan. Sesuatu selalu muncul yang belum pernah Anda pikirkan.
Berdasarkan semua ini, penulis menyerukan untuk memperlakukan masalah secara filosofis. Kemungkinan besar, sebagai perkiraan pertama, Anda tidak akan dapat memperhitungkan fungsi yang kurang jelas atau komplikasi yang tidak dapat diprediksi, dan mereka akan membutuhkan sumber daya tambahan yang tidak Anda hipotek. Untuk kejutan seperti itu, Anda harus siap dan mempersiapkan tim - untuk mengajar orang agar cepat membangun kembali agar "menutup lubang", untuk memberi mereka sedikit waktu sebagai cadangan untuk keadaan yang tidak terduga. Apa yang tidak dapat dilakukan dalam hal apapun adalah menganggap pertumbuhan alami sebagai keadaan darurat dan mencari yang bersalah, terutama di departemen lain (dan ini selalu terlihat sangat menggoda). Jadi Anda hanya menabur permusuhan antara tim dan tidak melakukan apa pun untuk menyelesaikan masalah.
Namun demikian, seseorang tidak boleh jatuh ke dalam fatalisme total: pertumbuhan proyek tetap merupakan hasil dari kekurangan dalam perencanaan. Anda tidak akan dapat sepenuhnya menghilangkannya, tetapi Anda dapat dan harus mengurangi konsentrasi.
Jika kita mentransfer hukum Humphrey ke realitas programmer, menjadi jelas bahwa perencanaan jeblok karena dua alasan: analisis rincian yang tidak memadai dan perkiraan yang terlalu optimis tentang durasi desain produk perangkat lunak. Optimisme di antara para manajer biasanya berkeliaran dengan cara alami: beberapa kali melanggar tenggat waktu, Anda akan mulai bermain aman. Adapun detailnya, keterampilan ini juga dilengkapi dengan pengalaman, tetapi bermanfaat sejak awal untuk mendapatkan gambaran umum tentang seperti apa peta jalan itu seharusnya.
Misalnya, jika Anda memulai proyek yang dipersenjatai dengan dokumen semacam itu, akan ada banyak bencana alam dan kerepotan di depan Anda:
Jika roadmap lebih mirip dengan sampel di bawah ini, peluang hasil yang bahagia meningkat secara signifikan:
Selain dua alasan ini, Rainwater mendaftar beberapa faktor risiko tambahan yang disoroti oleh Robert Glass, penulis buku sedih tentang proyek bencana di bidang TI,:
- Spesifikasi tujuan proyek yang tidak memadai
- Aplikasi teknologi baru untuk perusahaan ini
- Metodologi Manajemen Proyek Tahunan / Hilang
- Kurangnya pakar terkemuka dalam grup
- Gangguan perjanjian oleh produsen perangkat keras / perangkat lunak
Pencarian bahasa umum
Anda mungkin berpikir bahwa kita sedang berbicara tentang keterampilan komunikasi dari bakat komunikatif - tetapi tidak, arti dari judul itu jauh lebih literal. Di perusahaan yang berbeda, tim pemrogram dibentuk dengan alasan yang berbeda. Jika Anda beruntung, Anda mungkin bertanggung jawab atas orang yang bekerja dengan tumpukan teknologi asli Anda. Tetapi sangat sering tim campuran bertemu, di mana karyawan yang berbeda berbicara bahasa yang berbeda. Kebingungan seperti itu kadang-kadang membuat hidup sulit bagi pemimpin.
Salah satu tugas pemimpin adalah mengawasi semua aktivitas tim, untuk memastikan bahwa semua kode yang masuk ke dunia berfungsi, berkualitas tinggi, dan tanpa kompleksitas yang berlebihan. Jika Anda tidak terbiasa dengan alat yang digunakan bawahan Anda saat berkembang, maka tangan Anda terikat. Anda tidak dapat secara mandiri melakukan tinjauan kode, Anda akan belajar tentang kesalahan serius hanya pada tahap pengujian, yang meruntuhkan seluruh ritme kerja, dan, berbicara kasar, jauh lebih mudah untuk dikendarai oleh hidung.
Apa yang harus dilakukan dalam situasi ini? Secara umum, ada dua cara. Jika serangkaian bahasa dan teknologi tidak terlalu besar dan dapat diubah, Anda tidak dapat meluangkan waktu dan mencoba menguasainya setidaknya pada tingkat dasar. Ini mungkin jalan keluar terbaik - jadi Anda tidak harus bergantung pada siapa pun, Anda akan menerima informasi secara langsung, yang berarti Anda dapat menghindari "telepon mati" ketika membahas fungsionalitas, persyaratan, dan tenggat waktu.
Jika Anda tidak dapat mempelajari sendiri bahasa yang diperlukan, maka Anda harus mencari cara untuk mendelegasikan tanggung jawab ini. Bentuk inti asisten yang dapat memberi Anda umpan balik yang objektif dan jujur pada setiap teknologi yang tidak dikenal (jika hanya satu karyawan memilikinya, metode ini tentu saja tidak akan berhasil).
Memperdalam pengetahuan Anda dalam hal-hal yang berkaitan dengan teknologi dan peralatan juga berguna karena alasan lain - ini adalah satu-satunya cara untuk menjadi pemimpin teknis dalam arti kata yang lengkap. Dalam sistem terminologisnya, penulis membagi konsep "manajer" dan "pemimpin". Seorang manajer adalah orang yang mengorganisir pekerjaan, menyelesaikan masalah sehari-hari dan memastikan bahwa tugas saat ini selesai tepat waktu dan dengan benar. Seorang pemimpin adalah ahli strategi yang berpikir di luar tenggat waktu kontrol, menetapkan arah pergerakan umum untuk timnya, menaikkan standar, memikirkan kembali dan mengoptimalkan proses. Tentu saja, dalam tim pengembangan, pekerjaan visioner seperti itu membutuhkan kenalan yang baik dengan pasar teknologi. Di latar belakang, pemimpin teknis terus-menerus memperkirakan bahwa toolkit saat ini sudah ketinggalan zaman dan perlu diganti, memantau produk-produk baru dan pada saat yang sama memiliki pandangan yang cukup luas untuk menilai manfaat sebenarnya (dan tidak termasuk dalam sindrom Stunt).
Pada bagian pertama artikel ini, kita berbicara tentang fakta bahwa pemimpin tidak perlu khawatir bahwa dia akan berhenti bekerja dengan teknologi - dan bagi mereka yang menandai pemimpin, ini memang benar. Tetapi di sini masuk akal untuk mengulangi peringatan dari tempat yang sama: jangan berharap pada saat yang sama untuk menghindari tanggung jawab manajer. Manajemen melibatkan penyeimbangan antara dua peran, yang kadang-kadang bertentangan, tetapi tetap hampir sama (manajemen agak rendah) yang diperlukan untuk kelangsungan hidup tim. Asah keterampilan organisasi untuk keuntungan Anda - semakin sedikit waktu makan rutin, semakin cepat Anda akan tumbuh sebagai pakar teknis. Jika tugas sehari-hari dibiarkan kebetulan, kekacauan akan memerintah di mana tidak akan ada lagi strategi.
Pemetikan kawanan
Sekarang kita beralih ke blok masalah kedua - pekerjaan terkenal dengan orang-orang. Mari kita mulai dari awal: sebelum berbicara tentang bagaimana mengelola sumber daya manusia, Anda perlu mencari tahu di mana mendapatkannya. Bahkan jika Anda memiliki tim yang mapan, cepat atau lambat akan muncul pertanyaan tentang merekrut karyawan. Sebelumnya, kami menganalisis jenis-jenis programer dan menunjuk mereka yang seharusnya dikejar. Sekarang Anda perlu memahami cara bertindak untuk mengidentifikasi kualitas yang diperlukan pada kandidat dan tidak kecewa dengan pilihan mereka.
Penulis menawarkan rekomendasi berikut untuk wawancara:
- Berikan kandidat tugas ujian. Tetapkan calon karyawan tugas yang harus segera diselesaikannya, atau bawa ke rumahnya dan selesaikan pada waktunya.
- Pastikan untuk melakukan tes lisan dari keterampilan kandidat - sehingga Anda dapat mengevaluasi pengetahuan dan kemampuan untuk berpikir jernih dalam situasi yang penuh tekanan.
- Sebisa mungkin, tuliskan tugas-tugas karyawan yang diinginkan, semua tugas yang harus dia laksanakan, dan berikan daftar ini kepada kandidat untuk ditinjau. Jadi pembicaraan akan segera menjadi lebih objektif dan, sebagai aturan, lebih jujur.
- Jangan batasi diri untuk satu pertemuan. Akan sangat baik jika kandidat berkomunikasi tidak hanya dengan Anda, tetapi juga dengan "inti" yang disebutkan di atas - asisten, deputi, pengembang terkemuka dalam tim Anda. Tetapi mengatur pertunjukan dengan seluruh tim tidak layak, ini sudah terlalu banyak.
- Verifikasi kualitas pribadi, tes tipologis dan sejenisnya adalah mungkin, tetapi merupakan langkah opsional. Gunakan hanya jika kandidat tidak menentang dan Anda memiliki alat penilaian yang andal.
Berbicara tentang perekrutan, orang tidak bisa tidak menyebutkan sisi lain - pemecatan pekerja yang menarik tim ke bawah. Di sini Rainwater mengambil posisi yang agak sulit dan menyarankan tanpa ragu untuk menyingkirkan mereka yang telah menunjukkan diri mereka tidak kompeten atau bermasalah. Posisi terbaik adalah kebijakan satu peringatan: memberi seseorang peluang untuk meningkat, tetapi tidak mengizinkan penyalahgunaan hak ini. Jika seorang karyawan masuk ke dalam "daftar hitam" dan Anda berbicara dengannya, Anda perlu mengawasi keberhasilannya lebih lanjut dengan perhatian khusus. Ini membutuhkan upaya tambahan, sehingga memberi kesempatan ketiga sudah merupakan pemborosan yang tidak dapat dibenarkan.
Selain itu, tidak hanya "penyebab umum" abstrak biasanya menderita kelalaian anggota tim, tetapi juga orang-orang yang sangat spesifik yang harus memperbaiki kesalahannya atau menerima kenyataan bahwa ia merusak hasil pekerjaan mereka. Karena itu, kesenangan yang berlebihan dibayarkan dengan biaya mereka dan tidak mungkin memperkuat posisi kepemimpinan Anda.
Organisasi kerja karyawan
Lingkungan hidup yang nyamanBuku ini banyak memperhatikan aspek ini. Untuk mencapai produktivitas maksimum dari karyawan Anda adalah tanggung jawab langsung pemimpin, tetapi produktivitas tinggi memerlukan konsentrasi tinggi, dan konsentrasi tidak mungkin jika programmer dikelilingi oleh iritasi dari semua sisi. Karena itu, pemimpin harus melakukan segala daya untuk menyediakan kondisi kerja yang baik bagi tim.
Rekomendasi khusus untuk merancang kantor yang diberikan Rainwater di tempat-tempat terdengar agak idilis (misalnya, di kantor terpisah untuk saudara laki-laki), dan di tempat-tempat itu terdengar seperti gema dari masa lalu yang jauh dan sulit (setiap pengembang harus memiliki komputer sendiri). Tetapi prinsip umum masih tetap masuk akal dan berlaku: bagi programmer untuk berhasil dalam kegiatan mereka, mereka harus memiliki kesempatan, di satu sisi, untuk bekerja dalam tim untuk beberapa waktu, dan di sisi lain, untuk mencuci otak sendiri. Untuk yang pertama, Anda perlu tempat pelatihan yang dilengkapi: ruang pertemuan dengan proyektor, tim rekreasi (idealnya) dengan meja tenis terkenal atau konsol game. Untuk yang kedua, perlu untuk mengatur ruang yang tersedia sehingga orang-orang harus sesedikit mungkin terganggu oleh kebisingan, kerlipan, bau dan faktor-faktor lain yang mengganggu. Jika kondisinya buruk, biarkan karyawan, terutama mereka yang berharga dan dapat diandalkan, bekerja dari rumah.
Fasilitas minimum yang wajib juga mencakup peralatan modern dan berkualitas tinggi, yang dapat, dengan alasan, dikonfigurasikan oleh pengembang atas kebijakannya sendiri. Jika mobil lemah dan ketinggalan jaman, tidak perlu berbicara tentang terobosan teknologi, dan Anda tidak hanya memiliki operasi yang tenang dan bebas masalah. Untuk program pengujian, perangkat khusus harus dialokasikan yang mereproduksi karakteristik pengguna standar.
Jam kerjaTumpukan tugas penasihat teknis, yang kami uraikan, menunjukkan bahwa durasi hari kerjanya hampir dua kali lipat. Tapi di sini kamu harus hati-hati. Masalahnya adalah bahwa, dengan rezim kerjanya, manajer itu sendiri, dengan enggan, menentukan nada untuk seluruh departemen. Jika Anda duduk terlambat, pekerja akan menganggap bahwa sesuatu yang serupa juga diharapkan dari mereka. Akibatnya, pemrosesan dapat memasuki tubuh dan darah budaya lokal Anda - dan ini penuh dengan masalah.
Pertama, tidak semua orang akan senang dengan keadaan ini. Pertama-tama, pemrosesan akan menimpa mereka yang dibebani oleh kewajiban tambahan, misalnya, kewajiban keluarga. Jika ada banyak orang seperti itu, situasi di tim akan tegang. Nah, dan kedua, penulis, seperti banyak setelahnya, menunjukkan bahwa jam kerja ekstra lebih cenderung membahayakan produktivitas - baik karena kelelahan dan karena penurunan motivasi. Lebih bijak untuk menuntut pekerjaan yang efektif dari sekolah dalam pelajaran daripada menanamkan kebiasaan yang akan menyebabkan kelelahan.
Distribusi tugas dan pengawasanMari kita jujur: bahkan kondisi ideal dan jadwal yang lembut dalam diri mereka tidak akan mendorong orang untuk mengatur diri sendiri dan rajin bekerja. Antara lain, seorang bos diperlukan untuk mendistribusikan pekerjaan dan memastikan bahwa itu dilakukan. Beberapa bagian dari waktu Anda harus ditempati oleh kontrol - omong-omong, ini juga berkontribusi pada konsentrasi.
Penulis menyarankan untuk tidak membagi "periode pelaporan" terlalu banyak untuk bawahan, untuk tidak melumpuhkan mereka dengan pengamatan konstan dengan permintaan harian untuk hasil. Lebih bijaksana untuk menentukan daftar tugas untuk setiap minggu dan mengevaluasi jumlah pekerjaan yang dilakukan untuk periode yang sama. Dalam periode yang sangat panas, daftar harus disesuaikan bahkan pada interval kecil ini karena masalah mendesak yang muncul dan perubahan prioritas. Pemimpin harus mengingat semua perubahan ini (dan dalam realitas modern - dan membuatnya dalam sistem akuntansi yang sesuai).
Jika seorang pemimpin datang ke tim "asing" dengan ritme kerja yang sudah mapan, ada baiknya meminta setiap karyawan untuk melukis tugas-tugas biasa dengan cara yang sama. – , , .
, , . , – . . -, : - , - , , , . -, – . , .
. , , , , , , – , . , (, ). , , «» .
, . , , , . , – , . .
: , , - . . , , , . , .
, – , . ( ): , , , , .
, , . , : , , , , , . – , , . , – , .
, , , . , , .
– . , , , (, , «»). . – , . , , , .
, . – , -, , , , . : , . « » , . ( – ) – .