Apakah daftar perilaku manajemen ini benar-benar menarik bagi pengembang perangkat lunak? [Tutup]

Saya menemukan daftar perilaku manajemen ini ( http://suven.posterous.com/dos-and-donts-leading-software-development-te ).

Saya pikir itu memiliki beberapa permata, tetapi saya tidak 100% pada beberapa dari mereka. Saya telah menandai orang-orang dengan huruf miring dan nama saya.

Apakah Anda, sebagai pengembang perangkat lunak, berpikir bahwa ini menarik? Tiga yang mana yang akan menjadi TOP Anda "harus memilikinya" dari manajemen Anda?

Jangan

Jangan skala tim secara vertikal dengan menambahkan lebih banyak orang
Jangan membuat tim dengan lebih dari 10 orang
Jangan menyebut sumber daya orang, itu tidak keren dan benar-benar menyinggung
Jangan berasumsi bahwa orang-orang dalam tim dapat dipertukarkan
Jangan membandingkan tim satu sama lain ketika menyoroti kelemahan
Jangan saling melempar tim satu sama lain
Jangan buat tenggat waktu palsu
Jangan memaksakan standarisasi alat dan proses lintas tim (saya pikir ini bisa diperdebatkan untuk beberapa situasi - Todd)
Jangan mempekerjakan manajer produk yang tidak memiliki petunjuk tentang pengembangan perangkat lunak
Jangan hanya menggunakan KPI untuk mengarahkan tim Anda (Tidak hanya itu tidak efektif, tetapi pengembang akan menemukan cara untuk mendorong metrik KPI - "Anda ingin baris kode? Saya punya baris kode Anda!" - Todd)
Jangan memaksa tim Anda untuk bekerja lembur, bahkan meminta terikat akan membuat ketegangan
Jangan berasumsi bahwa menggandakan orang sama dengan separuh waktu

Melakukan

Lakukan skala secara horizontal dengan membuat lebih banyak tim yang terdiri dari 5-8 orang
Miliki visi untuk produk dan tim
Sangat menghargai bahwa setiap tim berbeda, jadi alokasikan proyek dengan tepat
Jangan memotivasi tim Anda (Wow - itu salah satu yang licin, sulit untuk didefinisikan. Saya setuju dengan sentimen, tapi itu seperti mengatakan "Jadilah efektif" tanpa pedoman. -Todd)
Izinkan orang untuk berpindah antar tim
Apakah ada sesi untuk membahas visi produk, strategi, teknologi, dan proses
Libatkan tim saat menentukan nama tim / produk
Biarkan tim Anda membuat keputusan sendiri terutama jika merekalah yang memiliki keahlian
Libatkan tim Anda pada keputusan apa pun yang memengaruhi cara atau apa yang mereka kerjakan
Dorong metodologi pengembangan yang cocok dengan tim dan proyek
Perhatikan rencana pengembangan pribadi setiap individu

management

— Todd Williamson
sumber

Yang saya benar-benar memiliki masalah adalah melibatkan tim dengan nama produk. Ini adalah subjek di mana setiap orang memiliki pendapat tetapi sebenarnya ada orang-orang di bidang pemasaran (atau setidaknya di departemen pemasaran yang layak) yang tahu lebih banyak tentang hal ini daripada hanya memiliki pendapat. Jika Anda ingin keterampilan Anda dihormati, Anda juga harus menghormati keterampilan orang lain.

— Jon Hopkins 8-10

Ini daftar yang luar biasa! Dari mana novel fiksi ilmiah ini?

— Rob

Dugaan saya adalah daftar ini benar-benar menarik bagi pengembang perangkat lunak karena ini memvalidasi citra diri mereka sebagai diva kreatif yang dimanjakan daripada pemecah masalah yang sulit (seperti Winston Wolf) dan berharap untuk diperlakukan secara profesional sebagai hasilnya.

Saya juga curiga jika kami meningkatkan teknik pengembangan perangkat lunak ke titik di mana perdagangan kami dapat disertifikasi seperti arsitek, pengacara, profesional medis, dan sejenisnya, kami akan lebih mampu mengarahkan bagaimana pengembang perangkat lunak dikelola.

— Huperniket
sumber

Tampaknya ada dikotomi antara persepsi pengembang bahwa mereka memiliki diri sendiri versus manajer. Saya pikir dalam kedua kasus Anda perlu melihat pengembang sebagai individu dan mengenali perbedaan individu lebih dari yang Anda butuhkan untuk membuat generalisasi menyeluruh tentang suatu grup. Saya pikir Anda benar tentang teknik yang ditingkatkan tetapi saya tidak berpikir bahwa Anda akan pernah melihat sertifikasi lintas papan yang diterima secara universal. Yang ada di luar sana adalah berbasis vendor atau berfokus pada jenis pengembangan tertentu.

— Todd Williamson

Stereotip, atau generalisasi menyeluruh, adalah bagian dari proses pemikiran kita. Inilah sebabnya mengapa sistem stereotip seperti jabatan dan program sertifikasi (seperti gelar sarjana) digunakan. Tetapi sertifikasi suatu industri bukan untuk mengelola perbedaan antara individu, tetapi proses untuk menghasilkan produk tertentu.

— Huperniketes

Saya menduga bahwa jika mungkin untuk meningkatkan teknik pengembangan perangkat lunak ke titik di mana kerajinan kami dapat disertifikasi (misalnya seperangkat aturan "ideal ideal"), maka mungkin juga untuk menulis perangkat lunak yang mengembangkan perangkat lunak (menggunakan yang sama " ideal dikenal "seperangkat aturan) dan kerajinan kita akan menjadi tidak berharga.

— Brendan