Bagaimana seorang manajer non-teknis memberi nilai tambah pada tim pengembang perangkat lunak yang memotivasi diri sendiri?

63

Saya melihat banyak programmer berpaling dari peran manajemen dan administrasi. Mereka ingin membangun barang. Dan sebagai hasilnya, banyak posisi ini diisi oleh orang-orang non-teknis. Saya gagal melihat bagaimana mereka menambah nilai. Apakah menjadwalkan rapat, memesan di luar kantor, dan pekerjaan administratif lainnya cukup untuk membenarkan peran mereka?

Senthil Kumaran
sumber
10
Berapa persen dari semua tim perangkat lunak yang menurut Anda dapat beroperasi seperti itu tanpa ego dan agenda yang menghalangi?
ozz
30
Dari Tao Pemrograman : Seorang pemula bertanya: "Di timur ada struktur pohon besar yang oleh orang-orang disebut 'Kantor Pusat Korporasi'. Bangunan ini membengkak tidak sesuai dengan wakil presiden dan akuntan. Ini mengeluarkan banyak memo ... Bagaimana bisa entitas yang tidak alami itu terjadi? " / Tuan itu menjawab: "Anda memahami struktur yang sangat besar ini dan merasa terganggu karena tidak memiliki tujuan rasional ... Apakah Anda tidak menikmati kemudahan pemrograman tanpa gangguan di bawah cabang-cabang yang berlindung? Mengapa Anda terganggu oleh ketidakgunaannya?"
apsillers
2
Tulisan Rands yang agak baru berkisar pada beberapa masalah ini; Saya memberikan segel rekomendasi. (Belum lagi ia juga memiliki banyak tulisan hebat tentang manajemen!)
Jari Keinänen

Jawaban:

112

Saya gagal melihat bagaimana mereka saat ini menambah nilai dan apakah menjadwalkan rapat, memesan di luar kantor, dan administrasi lainnya cukup untuk peran mereka?

Jangan meremehkan jumlah interaksi yang dilakukan manajer Anda dengan departemen lain. Mereka menangani anggaran, rencana pelatihan, dokumen SDM. Mereka melindungi pengembang agar tidak terjebak dalam pertemuan dengan departemen lain dan memberikan front terpadu untuk grup Anda.

Singkatnya, tugas mereka adalah melindungi para pengembang yang bermotivasi diri dari semua hal-hal yang mengurangi motivasi lain yang ada dalam bisnis.

Telastyn
sumber
4
Dan mereka akan melakukan pekerjaan yang lebih baik dalam mempertahankan gaji / kenaikan gaji.
JeffO
20
Sangat +1. Kami kadang-kadang mendapatkan "kebocoran" melalui sistem dan gagasan kecil tentang apa yang dialami manajer kami dan terutama Pemilik Produk kami. Saya tidak ingin berurusan dengan itu setiap hari.
Izkata
1
Saya tahu ini penting, tetapi saya tidak mendapatkan kepentingan relatif dalam tim pengembangan perangkat lunak dan nilai untuk ini.
Senthil Kumaran
17
@SenthilKumaran Sebagai pengembang, apakah Anda lebih suka menghabiskan dua jam dengan manajer dari departemen lain untuk membahas mengapa perangkat lunak tidak lengkap, atau apakah Anda lebih suka menghabiskan dua jam menulis kode? Anda tahu betapa sulitnya menjelaskan masalah teknis kepada manajer Anda. Bayangkan mencoba menjelaskannya kepada seseorang yang tahu bahkan kurang dari manajer non-teknis Anda. Manajer non-teknis terbaik mencegah pengembang mereka dari semua hal yang akan menyia-nyiakan waktu pengembang yang lebih baik menghabiskan pengkodean dan pengujian.
David Navarre
5
Ini berulang-ulang. Bahkan untuk seorang manajer teknis, ini masih merupakan bagian terbesar dari pekerjaan mereka.
Earlz
36

Manajer terbaik adalah pesulap. Mereka membuat sisa perusahaan menghilang untuk pengembang mereka. Saya tidak dapat mengingat kutipan persis dari Joel, tetapi itu adalah sesuatu yang menyatakan bahwa tugas manajemen adalah memastikan ada Internet Pipe yang gemuk, binatang buas dari mesin, dan banyak kafein sehingga semua pengembang harus khawatir tentang apa yang harus dilakukan. mereka melakukan yang terbaik.

Manajer yang baik adalah suara grup Anda ke seluruh perusahaan.

Michael Brown
sumber
29

Karena ini berlaku khusus untuk pengembangan perangkat lunak, ada dua jenis peran yang menambah nilai bagi para manajer: manajemen proyek dan pemimpin tim.

Seorang manajer proyek berinteraksi dengan klien dan manajemen menengah, yang merupakan penghemat waktu bagi pengembang. Seringkali ada klarifikasi atau perubahan ruang lingkup yang muncul dalam proyek, dan akan sangat membantu bagi klien dan manajer menengah untuk memiliki satu titik kontak. Mencoba menjawab pertanyaan dari setiap anggota tim pengembangan mengarah pada keputusan proyek yang tidak tercatat dan komitmen tidak berdokumen, kutukan manajemen ruang lingkup.

Di sisi lain, seorang pemimpin tim terlibat dengan pengembangan karier / keterampilan, memastikan beban kerja didistribusikan secara tepat di antara anggota tim, dan menyediakan sumber daya dan penghargaan yang sepadan dengan kontribusi dan kebutuhan individu.

Tidak satu pun dari peran-peran ini yang membutuhkan programmer head-down, pada kenyataannya agak sebaliknya. Seorang programmer sering kali beralih ke tugas penulisan kode sebagai respons pertama terhadap pertanyaan atau krisis, dan sangat membantu jika ada seseorang yang tugasnya menanyakan apakah tugas itu benar-benar perlu dilakukan.

hardmath
sumber
6
Pengembang melihat pohon. Manajer mereka melihat hutan.
David Navarre
9
@DavidNavarre - Manajer non-teknis IMO kesulitan melihat apa pun ...
Vektor
13
@Vektor: apa yang Anda maksud bukanlah manajer non-teknis, tetapi manajer yang tidak kompeten.
Lie Ryan
@ Vektor: Ini mengingatkan PHB Dilbert , tapi saya rasa ini tidak sama dengan manajer non-teknis.
hardmath
@hardmath - Saya mengerti :-) Jawaban Anda benar-benar termasuk dalam apa yang diberikan OP, sesuai hasil edit. Poin yang saya coba sampaikan adalah bahwa sejauh menyangkut hal-hal teknis, mereka perlu dihentikan. Saya memiliki pengalaman pahit dalam hal ini ... "Sedikit pengetahuan adalah hal yang berbahaya" - Saya yakin Anda mengerti maksud saya. Lihat jawaban saya.
Vektor
12

Seiring dengan manfaat lain yang disebutkan, manajer non-teknis dapat melakukan pekerjaan yang lebih baik dalam membuat keputusan akhir ketika ada jalan buntu di antara para ahli. Saya tahu ini kedengarannya kontra-intuitif, tetapi manajer non-teknis yang baik memahami kekuatan dan kelemahan orang-orang mereka.

Contoh: Dua programmer berdebat tentang server mana yang akan digunakan untuk suatu aplikasi. Dalam semacam demokrasi khayalan, mereka berdua mendapatkan satu suara, jadi tidak ada keputusan. Perang ini bisa berlangsung selamanya (dan dengan beberapa orang teknis itu akan terjadi). Seseorang harus turun tangan dan menengahi perselisihan ini dan menyelesaikan proyek. Seorang hakim yang baik akan bersandar pada pendapat orang yang paling ahli dalam bidang ini.

Hanya karena seseorang tidak memiliki bakat, keterampilan, atau pengetahuan dalam suatu bidang tidak berarti mereka tidak dapat mengidentifikasi mereka yang melakukannya. Mengenali bakat adalah bakat.

JeffO
sumber
1
Juga, seorang manajer non-teknis tersedia untuk memenuhi kebutuhan tim alih-alih menulis kode.
JeffO
1
"Seiring dengan manfaat lain yang disebutkan, manajer non-teknis dapat melakukan pekerjaan yang lebih baik dalam membuat keputusan akhir ketika ada jalan buntu di antara para ahli." Non-ahli memiliki paling sedikit info tentang topik tertentu. Ia hanya dapat mengambil "sisi" dengan pihak yang paling ahli di bidang ini (atau memilih solusi yang menurutnya terbaik). Tapi itu tidak berarti keputusannya benar. Solusi dari programmer yang kurang berpengalaman bisa lebih baik tetapi orang yang tidak ahli tidak bisa mengetahuinya. joelonsoftware.com/items/2006/08/08.html
Christian P
Dalam situasi seperti itu, bagian manajemen yang sering diremehkan tidak selalu membiarkan orang-orang terbaik mendapatkan jalannya sendiri. Manajer yang baik akan membaca situasi dengan baik dan akan membuat penilaian yang mungkin tidak benar secara teknis, tetapi secara politis benar. Jika argumennya bukan tentang sesuatu yang penting, manajer mungkin lebih suka orang yang membutuhkan lebih banyak dorongan atau sedang diganggu oleh pengembang lain. Ini panggilan penghakiman dan kadang-kadang sulit, tapi itu sebabnya mereka dibayar mahal.
Stephen
@Stephen setuju - manajer yang baik akan tahu bagaimana mengelola orang-orangnya (misalnya, seperti yang Anda katakan memberi dorongan kepada orang lain, dll). Tetapi jika kita berbicara secara tegas tentang membuat (penting) keputusan teknis, manajer memiliki info jumlah paling sedikit tentang masalah dan mungkin orang yang salah membuat keputusan itu.
Christian P
@Stephen: tetapi akan benar secara politis - itu seringkali merupakan cara yang sangat baik bagi manajer non-teknis untuk kehilangan semua kredibilitas dengan staf teknis. IMO sangat berisiko.
Vektor
2

Apakah menjadwalkan rapat, memesan di luar kantor, dan pekerjaan administratif lainnya cukup untuk peran mereka?

Iya. Cukup sempurna. Mereka juga baik untuk memanggil manajemen gedung ketika ada masalah dengan panas, AC, dll; memastikan mesin penjual otomatis dan pendingin air memiliki persediaan dan perawatan yang baik; membawa barang-barang khusus untuk digosipkan; menjaga kantor tetap bersih dan teratur ...

Lakukan yang terbaik untuk memikirkan tugas-tugas lain seperti itu untuk membuat mereka sibuk dan keluar dari masalah ...

Peran mereka yang paling penting? Tetap keluar dari jalan dan tidak bergaul dengan programmer, dan memastikan bahwa orang-orang non-teknis melakukan hal yang sama.

Pertimbangkan tim pengembangan seperti klub bola MLB (analoginya cukup bagus dengan IMO): Para manajer selalu mantan pemain - hanya mereka yang tahu bagaimana menangani 'tangan manajemen' dari tim yang sangat terampil, kutu buku, istimewa, profesional, yang melakukan hal-hal yang kebanyakan 'orang biasa' tidak bisa.

Vektor
sumber
Anda juga mendapatkan banyak Manajer Olahraga yang bukan mantan pemain, atau mantan pemain yang tidak terlalu baik - Arsene Wenger, Jose Mourinho, Andre Villas-Boas, siapa saja? yang berubah menjadi manajer yang sangat baik. Anda membutuhkan keterampilan interpersonal dan orgranisasional yang kuat untuk menjadi PM yang baik yang TIDAK mengkode.
bobo2000
@ bobo2000 - Saya sebutkan MLB , bukan olahraga pada umumnya.
Vektor
-1

Dalam pengalaman saya, manajer non-teknis paling cocok untuk peran ini, selain menambahkan nilai dengan menghindari hal-hal perusahaan yang mengganggu kerja pengembang, mereka mendorong kemitraan antar pengembang (karena sudah diketahui bahwa pengembang introvert http://www.unwesen.de/ 2012/03/16 / introversi-produktivitas-kerja-lingkungan / ), yang bagus biarkan tim bekerja sesuai ritme mereka tetapi peduli dengan visibilitas.

cesarggf
sumber
2
Jawaban Anda akan lebih kuat jika Anda mengutip beberapa referensi eksternal atau memperluas prinsip Anda. Menyatakan cause it's well know[n]adalah bentuk bukti yang lemah.