Bagaimana Anda membantu sesama programmer untuk tumbuh?

Sebagai pemimpin tim, bagaimana Anda dapat membantu programmer Anda untuk tumbuh?

Alasan saya menanyakan hal ini adalah karena ada beberapa programmer yang bekerja dengan saya, dan saya benar-benar ingin "mengubah mereka", untuk menyadari potensi maksimal mereka, dan untuk membuat mereka bahagia.

Tapi saya tidak tahu bagaimana melakukan ini, saya harus

1. Sering berinteraksi dengan mereka, atau memberi mereka waktu tenang, membuat mereka tidak terganggu?
2. Minta mereka untuk mengikuti pedoman pengkodean, seperti menegakkan pengujian unit, gaya pengkodean, atau membiarkan mereka melakukan apa pun yang mereka inginkan?
3. Bersabarlah dengan mereka. Seperti tidak peduli apakah mereka benar-benar berkuasa selama 8 jam atau 4 jam, atau perlu menegakkan beberapa "disiplin" di tempat kerja?

Coba tebak, setiap posisi memiliki poin mereka sendiri, dan orang yang berbeda akan berdebat untuk hal yang berbeda. Kebingungan semacam itu membuat mengelola orang tanpa batas menjadi lebih sulit.

Apa yang kamu pikirkan?

Itu garis yang sangat bagus yang harus Anda jalani.

Pada akhirnya, keputusan teknis apa pun yang Anda buat adalah keputusan yang tidak harus Anda jalani. Jadi, buat sesedikit mungkin dari mereka, biarkan orang-orang yang memang harus hidup dengan mereka membuat pilihan sendiri. Namun, bimbinglah mereka jika Anda pikir mereka akan menempuh jalan yang buruk.

Di sisi lain, pilihan proses adalah milik Anda. Dalam keputusan itu, biarkan tim membimbing Anda tetapi pada akhirnya Anda harus membuatnya. Setidaknya pada awalnya.

Bacalah Tiga Tahapan Kedewasaan Roy Osherove dari Tim Perangkat Lunak dan lihat apakah Anda bisa mengetahui tahap apa tim Anda saat ini berada. Ini harus memengaruhi cara Anda bertindak. Semakin kacau, semakin banyak Anda harus menempatkan kontrol pada tempatnya. misalnya. Dalam tim yang sangat kacau, Anda harus mulai dengan meninjau semua kode yang dilakukan. Tetapi saat Anda melakukan itu, luangkan waktu untuk mengajar mereka meninjau kode masing-masing.

Dan jika Anda berhasil menarik tim dari Chaos ke Midlife, ubah perilaku Anda pada saat itu, jika tidak mereka tidak akan bergerak lebih jauh (ini yang terakhir dari pengalaman pribadi).

Ya, mengelola orang jauh lebih sulit daripada mengelola komputer atau perangkat lunak, justru karena setiap orang berbeda, dan kami dapat berubah setiap hari. Jadi tidak ada jawaban universal. Saya percaya Anda hanya perlu berkomunikasi banyak dengan pengembang Anda untuk mengenal mereka dan memahami kekuatan / kelemahan masing-masing, sikap mereka untuk bekerja dan belajar, dll. Anda dapat mempelajari masing-masing dari mereka, apakah dia lebih suka banyak komunikasi dan lokakarya, atau belajar sendiri di sudut yang sunyi.

Pengembang IMHO dalam keadaan normal memiliki keinginan alami untuk belajar (kecuali jika mereka telah terbakar atau letih oleh pengalaman kerja yang buruk sebelumnya). Jadi yang perlu Anda lakukan adalah memahami apa dan bagaimana mereka ingin belajar, dan memberi mereka alat dan waktu untuk melakukannya (tentu saja dalam batas yang masuk akal).

Misalnya dalam tim kami, kami dapat dengan bebas menentukan tugas belajar untuk diri kami sendiri, asalkan ini terkait (baik secara langsung atau tidak langsung) dengan proyek. Tugas-tugas ini biasanya beberapa jam hingga satu hari per sprint (tidak di setiap sprint). (Contoh baru-baru ini: Saya mendapat tugas untuk belajar dan bereksperimen dengan Scala diterima, atas dasar bahwa ini - dan pendekatan fungsional secara umum - mungkin membantu menyederhanakan bagian kompleks kode Java kami.) Ini kemudian diprioritaskan dan dijadwalkan menjadi Sprint, sama seperti tugas biasa. Hal ini juga didorong dan diharapkan untuk melakukan demo / ceramah tentang apa yang kami pelajari, untuk mentransfer pengetahuan kepada anggota tim lainnya (dan bahkan berpotensi untuk pengembang di tim yang berbeda).

Minta mereka untuk mengikuti pedoman pengkodean, seperti menegakkan pengujian unit, gaya pengkodean, atau membiarkan mereka melakukan apa pun yang mereka inginkan?

Ketika bekerja dalam tim, mengikuti proses pengembangan yang sama adalah suatu keharusan. Tentu saja, proses itu harus menjadi hal paling sederhana yang mungkin bisa berhasil, bukan sesuatu yang dijelaskan dalam manual 600 halaman. Dan prosesnya harus didefinisikan dan terus disesuaikan dengan situasi oleh tim itu sendiri . Jadi, jika tim telah menyetujui standar pengkodean, dan TDD, mereka harus mengikutinya.

Bersabarlah dengan mereka. Seperti tidak peduli apakah mereka benar-benar berkuasa selama 8 jam atau 4 jam, atau perlu menegakkan beberapa "disiplin" di tempat kerja?

Jika Anda tidak mengenal pengembang, adalah normal untuk mengikuti lebih dekat apa yang dia lakukan, pengirimannya, ritme kerjanya, dll. Anda juga boleh meninjau kode itu (baik Anda sendiri, atau tim yang berpengalaman dan tepercaya anggota). Begitu dia mendapatkan kepercayaan, dia secara bertahap bisa mendapatkan lebih banyak kebebasan. Tapi kepercayaan itu harus diperoleh terlebih dahulu. Tentang jam kerja, dalam pengalaman saya, jam fleksibel sangat bagus hingga batasnya, yaitu baik untuk memiliki minimum yang disepakati bersama, seperti setiap hari antara pukul 11 ​​pagi dan 14:00, ketika pengembang (biasanya) dapat ditemukan di tempat kerja mereka, sehingga mereka dapat didekati dengan pertanyaan, atau diundang ke pertemuan. Tapi selain itu, tidak ada gunanya bersikap ketat.

OK sebagai petunjuk, itu tugas Anda untuk menyelesaikan proyek. Jadi, Anda harus menjadi orang yang menegakkan standar, ulasan kode, meminta laporan kemajuan dan semua hal itu ketika pengembang lebih suka Anda meninggalkannya sendirian. Hal-hal ini hanyalah persyaratan manajemen dan kecuali untuk tinjauan kode tidak benar-benar meningkatkan keterampilan karyawan.

Namun, Anda ingin membantu mereka tumbuh yang merupakan atribut hebat dalam diri seorang pemimpin.

Ulasan kode tentu saja merupakan langkah pertama, mereka akan membantu Anda melihat siapa yang kurang dari ketenaran bintang dan perlu peningkatan untuk bahkan memiliki kinerja satsifactory. Mereka akan membantu para pengembang melihat cara-cara lain untuk melakukan sesuatu dan untuk memahami bagian-bagian berbeda dari basis kode daripada yang mereka kerjakan secara pribadi. Menurut pendapat saya, tinjauan kode paling baik dilakukan secara langsung di ruang konferensi dengan pengembang dan peninjau (yang harus menjadi pengembang lain jika mungkin tidak selalu memimpin, meninjau kode orang lain juga merupakan keterampilan yang perlu dikembangkan) dan Anda sebagai seorang moderator. Anda harus mencatat apa yang perlu diubah untuk mengidentifikasi tren. Apa yang sebenarnya Anda cari bukanlah kesalahan atau perubahan (kode semua orang dapat ditingkatkan), tetapi kegagalan yang konsisten untuk belajar dari kesalahan. Jangan memberi tahu manajemen tingkat atas bahwa Anda menyimpan catatan ini atau Anda akan terpaksa menggunakannya sebagai ukuran dalam proses peninjauan kinerja yang dengan jujur ​​mengalahkan tujuan tersebut. Jika beberapa pengembang membuat kesalahan yang sama, sesi pelatihan atau entri wiki tentang cara melakukan X mungkin berurutan.

Sekarang untuk tumbuh wakil sampai ke level minimal. Pertama, Anda perlu tahu keahlian apa yang dimiliki para pengembang dan keterampilan apa yang berguna bagi mereka dan apa yang mungkin menarik untuk mereka ketahui. Anda perlu berbicara dengan mereka dan meninjau resume mereka dan memahami apa yang mereka bohongi dan tidak suka melakukannya.

Jangan berikan semua tugas menarik hanya untuk yang paling terampil. Itu tidak membantu yang lain untuk mempercepat masalah dan teknologi baru. Anda tidak dapat beralih dari menjadi pria paling junior yang hanya mendapatkan tugas terkecil dan paling tidak penting untuk pria senior kecuali seseorang mengambil kesempatan dan memberikan pekerjaan yang lebih sulit kepada Anda. Yang mengatakan, yang kurang berpengalaman mungkin perlu ditugaskan terlebih dahulu untuk memasangkan program dengan senior untuk mendapatkan keterampilan yang lebih maju. Memasukkan junior dalam ulasan kode juga akan memaparkan mereka pada teknik yang lebih maju.

Pertama, beri mereka kesempatan untuk memecahkan masalah sendiri. Tetapi kadang-kadang orang terjebak dan tidak tahu harus mulai dari mana (keterampilan yang juga perlu Anda kembangkan terutama pada programmer baru) atau apa yang harus dilakukan untuk menyelesaikan masalah.

Jika Anda memberi mereka beberapa hari untuk meneliti sesuatu dan mereka masih belum memiliki arahan untuk bagaimana mereka akan melakukan sesuatu, maka Anda mungkin perlu melakukan intervensi dengan beberapa saran. Jika Anda teknis sendiri, Anda dapat memberi mereka beberapa ide tentang bagaimana menyelesaikan masalah. Jika tidak, pertemuan dengan beberapa orang tempat Anda bertukar gagasan dapat membantu jika orang tersebut macet. Atau meminta orang yang lebih berpengalaman untuk memberikan beberapa saran. Apa yang tidak ingin Anda lakukan adalah mengambil masalah dari mereka dan menyelesaikannya sendiri. Tetapi Anda harus menyeimbangkan menyelesaikan proyek dengan ego programmer dan kadang-kadang Anda perlu mengirim mereka ke arah tertentu. Jika ia memiliki solusi yang buruk dan itu perlu diperbaiki, hal terburuk yang dapat Anda lakukan adalah memberikannya kepada orang lain kecuali jika Anda berniat memecat programmer.

Saya telah melihat programmer yang buruk dimanja, di mana orang lain harus memperbaiki hampir semua yang mereka lakukan. Pemrogram lain membenci ini dan hanya ingin orang itu keluar dari kehidupan mereka. Coddling seorang programmer yang buruk menyebabkan programmer baik meninggalkan. Anda harus menemukan garis antara keterampilan memanjakan dan mengasah. Jika Anda memberi seseorang beberapa peluang dan dia tidak pernah menjadi lebih baik, maka potong dia.

Bagi para senior yang sudah kompeten dalam keahlian mereka saat ini, segalanya lebih mudah. Biasanya Anda hanya perlu memberi mereka kesempatan untuk melakukan sesuatu yang baru dan mereka melompat masuk dan mempelajarinya. Pastikan saja peluang menarik menyebar dan jangan semua pergi ke Joe the Wonder Programmer yang bisa memperbaiki apa pun. Anda ingin berakhir dengan sepuluh Joes bukan hanya satu.

Cara lain untuk mengembangkan keterampilan adalah memiliki sesi pelatihan 1 jam setiap minggu. Buat setiap devloper bertanggung jawab atas topik tertentu. Ini akan membantu mereka menjadi lebih baik dalam berkomunikasi, akan membuat mereka meneliti sesuatu secara mendalam dan akan memberi semua orang manfaat dari penelitian mereka. Beberapa topik harus diberikan kepada orang-orang yang tidak terbiasa dengan topik tersebut untuk memaksa mereka menumbuhkan pengetahuan di dalamnya dan beberapa harus ditugaskan kepada orang-orang yang Anda kenal adalah pakar lokal tentang topik itu. Topik harus merupakan kombinasi dari hal-hal yang Anda perlukan agar orang-orang pandai di bidang furture atau sekarang dan beberapa liputan teknologi mendatang yang tidak Anda gunakan saat ini tetapi orang-orang tertarik untuk belajar melihat apakah mereka bisa berguna. Tetapi semua orang termasuk yang paling junior harus diberi topik.

Bergantung pada bagaimana waktu pengembang Anda ditagih (ini lebih sulit dalam situasi penagihan pelanggan), biasanya layak bagi pengembang untuk memiliki 4-8 jam seminggu untuk mengerjakan proyek pribadi. Mereka akan senang melakukan ini. Orang-orang terbaik akan ingin bekerja di sana dan mereka akan belajar banyak yang akan berguna untuk masa depan. Sulit bagi penghitung kacang untuk memahami kebutuhan akan hal ini, tetapi kali ini akan dibayar kembali berkali-kali dalam kepuasan karyawan, fitur baru atau perangkat lunak yang tidak diperlukan oleh siapa pun (atau yang akan membantu mengotomatisasi beberapa pekerjaan yang membosankan) dan pengembangan yang lebih cepat karena teknik baru yang dipelajari. Beberapa pengembang akan menggunakan waktu ini secara ketat untuk proyek-proyek pribadi yang tidak terkait dengan apa yang Anda lakukan (dan itu bagus, mereka masih akan mendapatkan keterampilan dan senang atas kesempatan itu), tetapi banyak orang lain akan menggunakannya untuk menyelesaikan masalah yang terus-menerus itu, karena sifat dari bagaimana proyek dikelola, ndbody punya waktu untuk memperbaiki sebelumnya. Jadi, Anda mungkin mendapatkan refactoring yang menguntungkan semua orang; beberapa orang mungkin menulis tes untuk meningkatkan cakupan tes untuk membuatnya lebih mudah untuk refactor; beberapa yang lain mungkin menjelajahi beberapa fitur baru yang mungkin membuat perangkat lunak Anda lebih bermanfaat bagi pelanggannya. Secara umum, jika Anda dapat membujuk penghitung kacang, tidak ada cara untuk kehilangan dengan memberikan mereka kebebasan ini.

Anda harus belajar bagaimana menyeimbangkan dengan membiarkan orang lain mengembangkan keterampilan mereka dan menjaga proyek tetap pada jalurnya. Semakin kurang berpengalaman pengembang, semakin banyak seseorang yang perlu memeriksa kemajuan terutama pada tahap awal ketika mengubah arah lebih mudah. Orang yang tidak berpengalaman mungkin berjuang dan takut untuk berbicara. Orang-orang ini cenderung pergi tepat sebelum peluncuran dan Anda merasa bagian dari proyek mereka tidak mendekati selesai. Berhati-hatilah untuk memeriksa kemajuan pada siapa pun yang Anda miliki yang sering berganti pekerjaan (kecuali mereka adalah kontraktor karena itu adalah sifat kontrak).

Yang lebih berpengalaman umumnya dapat dipercaya untuk memberi tahu Anda ketika mereka kesulitan menemukan solusi dan membutuhkan bantuan dari seseorang yang memiliki lebih banyak pengetahuan di bidangnya atau mereka akan mencari orang itu dan mendapatkan transfer pengetahuan. Jadi mereka tidak perlu dipantau secara dekat dalam fase awal mempelajari keterampilan baru untuk suatu proyek. Mereka akan menemukan cara untuk menyelesaikan proyek. Mereka yang memiliki rekam jejak pengiriman biasanya dapat dibiarkan sendirian kecuali untuk laporan kemajuan minimal (Anda biasanya harus melaporkan kepada manajemen Anda juga dan dengan demikian memerlukan beberapa informasi).

1. Berikan tim Anda pekerjaan yang menantang dan alat untuk menyelesaikannya. Bahkan jika Anda melihat pekerjaan Anda sebagai hal biasa karena Anda hanya mendukung sistem warisan, dorong semua orang untuk membuatnya lebih baik.
2. Tim Anda harus mengembangkan standar pengkodean. Tugas Anda adalah membantu mereka menegakkan dan menyesuaikan standar.
3. Bekerja dengan tim Anda untuk mengembangkan sistem estimasi. Tugas Anda adalah membantu mengoordinasikan upaya ini dengan tim dan memberikan penegakan hukum. Pasukan luar mengharapkan kode kualitas tepat waktu dan mereka tidak selalu memiliki logika atau memberikan logika untuk permintaan mereka. Anda tidak dapat menghindari ini, tetapi Anda harus mengelola kedua belah pihak. Setelah tim Anda membangun reputasi untuk menyelesaikan sesuatu, semua orang akan lebih menerima perkiraan waktu Anda. Mereka perlu tahu bahwa Anda akan mendukung mereka jika mereka melakukan upaya.

Ketika saya mengatakan tugas Anda adalah menegakkan, saya tidak bermaksud mengambil gaya kepemimpinan Draconian. Ketika sekelompok individu yang cakap memiliki masukan tentang bagaimana mereka akan berperilaku, mereka juga harus menyetujui konsekuensi karena tidak mengikuti aturan. Seseorang pada akhirnya bertanggung jawab dan karena Anda adalah pemimpin tim, itulah Anda.

Sering berinteraksi dengan mereka, atau memberi mereka waktu tenang, membuat mereka tidak terganggu?

Sering berinteraksi dengan mereka. Jelas bukan titik mengganggunya tetapi sebagai manajer Anda, Anda harus melakukan percakapan teratur dengan mereka tentang bagaimana keadaan dan lebih banyak obrolan genral chatting. Kira-kira sekali setiap beberapa jam terdengar frekuensi yang tepat tetapi memutarnya.

Minta mereka untuk mengikuti pedoman pengkodean, seperti menegakkan pengujian unit, gaya pengkodean, atau membiarkan mereka melakukan apa pun yang mereka inginkan?

Anda harus mengharapkan mereka bekerja dengan standar yang persis sama dengan yang Anda lakukan. Jika Anda melakukan tes unit dan mengikuti pedoman maka mereka harus melakukannya. Mereka perlu belajar bagaimana kode dengan baik dan tanggung jawab Anda untuk mengajari mereka itu.

Bersabarlah dengan mereka. Seperti tidak peduli apakah mereka benar-benar berkuasa selama 8 jam atau 4 jam, atau perlu menegakkan beberapa "disiplin" di tempat kerja?

Saya akan lebih disiplin pada awalnya tetapi santai ketika mereka membuktikan bahwa mereka dapat dipercaya. Memberi orang kepercayaan untuk bekerja selama 4 jam sejak saat itu adalah masalah tetapi membiarkan karyawan yang dihargai yang secara teratur bekerja lembur memiliki kelonggaran di antara proyek itu baik-baik saja.

Terkait dengan tiga poin Anda:

Sering berinteraksi dengan mereka, atau memberi mereka waktu tenang, membuat mereka tidak terganggu?

Saya akan mengatakan bahwa itu sangat tergantung pada tipe orang yang bekerja dengan Anda. Beberapa orang lebih suka berdiskusi pada waktu kopi tetap (sekitar jam 10 pagi) dan jika tidak bekerja sendirian, tidak terganggu. Dengan mereka (OK, saya akui, saya persis seperti itu), saya biasanya mengirim email (bahkan ketika mereka berada di dekat saya, seperti 2-3 meter jauhnya) sehingga Anda dapat membiarkan mereka memilih ketika mereka membaca informasi Anda . Dan omong-omong, jangan tanya mereka apakah mereka "mendapatkan memo Anda" :-) Dan tentu saja, beberapa "perlu" lebih banyak bimbingan, lebih banyak interaksi.

Minta mereka untuk mengikuti pedoman pengkodean, seperti menegakkan pengujian unit, gaya pengkodean, atau membiarkan mereka melakukan apa pun yang mereka inginkan?

Adapun pedoman berikut, cukup jelas bagi saya. Jika Anda menetapkan pedoman yang terkait dengan gaya pengkodean, aturan kasus-selalu-berikan-uji, dll, maka Anda harus menegakkannya jika Anda adalah pengembang utama. Untuk proyek yang Anda kelola, setiap pengembang harus mengikuti panduan Anda, tidak terkecuali, bahkan untuk " bintang ".

Bersabarlah dengan mereka. Seperti tidak peduli apakah mereka benar-benar berkuasa selama 8 jam atau 4 jam, atau perlu menegakkan beberapa "disiplin" di tempat kerja?

Jika Anda sudah tahu bagaimana orang bekerja dan percaya diri daripada mereka tidak akan merusak kepercayaan diri Anda, Anda bisa rileks disiplin. Tapi saya pikir untuk poin ini aturan (atau tidak ada aturan) yang Anda tetapkan harus berlaku untuk semua orang. Yang penting adalah bahwa tidak boleh ada pengecualian. Saat ini saya sangat senang bekerja untuk seorang manajer proyek yang hanya mengatakan "selama Anda melakukan 40 pekerjaan Anda per minggu dan pekerjaan selesai, tidak apa-apa". Dengan begitu Anda bisa datang terlambat pada suatu pagi, bekerja hanya 6 jam dan dua hari berikutnya bekerja selama 9 jam. Tidak masalah "selama pekerjaan itu selesai". Saya suka aturan itu.

Saya akan mengatakan bahwa jumlah pengalaman (tidak hanya pemrograman, tetapi juga dalam lingkungan bisnis) yang dimiliki pengembang Anda adalah elemen kunci dalam berapa banyak waktu yang Anda habiskan bersama mereka. Saya saat ini bekerja dengan beberapa pengembang yang baru lulus sekolah, dan saya menemukan bahwa mereka membutuhkan lebih banyak panduan dalam cara bekerja dengan orang lain, tidak hanya dalam cara mendokumentasikan / menguji / standar, tetapi juga dengan cara interpersonal (kapan harus panggilan di telepon atau bertemu langsung, bukan hanya mengirim email). Pengetahuan tentang bisnis kami juga merupakan hal utama untuk dipelajari, karena banyak dari kata yang sama digunakan sangat berbeda dalam konteks bisnis kami daripada dalam konteks pengembangan perangkat lunak. Dan ini sebelum kita sampai pada akronim ...

Tapi saya tidak tahu bagaimana melakukan ini, saya harus

1. Sering berinteraksi dengan mereka, atau memberi mereka waktu tenang, membuat mereka tidak terganggu?
2. Minta mereka untuk mengikuti pedoman pengkodean, seperti menegakkan pengujian unit, gaya pengkodean, atau membiarkan mereka melakukan apa pun yang mereka inginkan?
3. Bersabarlah dengan mereka. Seperti tidak peduli apakah mereka benar-benar berkuasa selama 8 jam atau 4 jam, atau perlu menegakkan beberapa "disiplin" di tempat kerja?

Saran saya adalah untuk melakukan beberapa percakapan tentang gaya apa yang paling cocok untuk individu itu dan selaras dari waktu ke waktu. Beberapa orang mungkin ingin bertemu sekali sehari untuk meninjau kembali bagaimana keadaannya sementara yang lain mungkin menemukan sekali seperempat untuk menjadi berlebihan. Beberapa orang mungkin menginginkan tinjauan kinerja tertulis secara formal setiap bulan dan yang lain mungkin hanya ingin mengobrol tentang kinerja. Kuncinya adalah membawa hubungan ke tahap di mana Anda bisa jujur ​​tentang apa yang berhasil dan tidak berhasil untuk seseorang.

Sisi sebaliknya dari ini adalah mempelajari filosofi pengembangan pribadi meskipun ini bisa menjadi jalan yang sulit jika seseorang dianalisis secara tidak benar. Jika Anda menginginkan beberapa contoh filosofi seperti itu, Anda dapat melihat Myers-Briggs, Enneagram, dan Strengths Finder 2.0 untuk beberapa contoh.

Anda bertanya kepada mereka bagaimana mereka lebih suka bekerja.
Apa yang ingin mereka ubah dan sebagainya.

Tidak semuanya sekaligus. Hanya ... saat semuanya muncul.
Tetap alami. (atau mereka akan mencium bau ketakutan)

Dan kemudian ... Anda bahkan dapat belajar hal-hal dari mereka . Jika Anda tidak berpikir itu akan terjadi, (terlalu jauh jarak dalam pendidikan dan pengalaman) tidak benar-benar berusaha untuk membuat mereka tumbuh dewasa, itu hanya akan membingungkan mereka.

(Dalam kasus khusus itu, menyerah dan memerintah dengan tangan besi , itu lebih jujur ​​daripada memalsukan bunga yang tidak Anda miliki di dalamnya)

Menetapkan proses yang demokratis , memberikan suara, membahas masalah.

Seperti setiap presiden di luar sana, Anda memegang kata terakhir: hak veto .
Sisanya terserah kelompok.

Salah satu cara untuk membantu orang-orang Anda tumbuh adalah dengan membiarkan mereka melakukan yang terbaik.

Jika Anda beruntung, Anda akan memiliki satu atau dua programmer yang standar "pengujian" pribadinya lebih ketat daripada standar departemen secara keseluruhan. Dalam hal itu, Anda dapat menempatkan mereka di "sistem kehormatan" untuk masalah-masalah itu, atau bahkan mengadopsi metode mereka.

Dengan "waktu fleksibel," Anda dapat memberi lebih banyak kelonggaran bagi pekerja Anda yang lebih produktif. Selama mereka menyelesaikan pekerjaan, saya tidak akan terlalu khawatir dengan jam kerja mereka. Beberapa orang masuk, memasukkan 5-6 jam "nonstop", dan mencapai lebih dari yang lain yang menggunakan 10 jam berjalan lambat.

Tapi salah satu pekerjaan Anda sebagai manajer adalah mengoreksi KELEMAHAN. Artinya, Anda harus BERUANG pada programmer yang ceroboh yang standar pengujiannya tidak memadai, atau orang yang tidak cukup produktif - karena mereka tidak menghitung waktu.