Saya seorang pemimpin tim dengan 5+ pengembang. Saya memiliki pengembang (sebut saja dia A ) yang merupakan programmer yang baik, yang menulis kode yang baik bersih, mudah dimengerti. Namun dia agak sulit dikelola, dan kadang-kadang saya bertanya-tanya apakah dia benar-benar berkinerja buruk atau tidak.

1. Perusahaan kami mengharuskan pengembang untuk menunjukkan kemajuan pekerjaan dalam pelacak bug yang kami gunakan, tidak hanya untuk memantau programer tetapi untuk membuat para pemangku kepentingan mengetahui perkembangannya. Masalahnya, A hanya memperbarui kemajuan tugas ketika selesai (mungkin 3 minggu setelah pertama kali dikerjakan) dan ini membuat semua orang bertanya-tanya apa yang sedang terjadi di tengah minggu pengembangan. Dia tidak akan mengubah kebiasaannya meskipun pemeriksaan berulang. (Tidak apa-apa, pengembang juga benci dokumen, saya juga)
2. Baru-baru ini 2-3 bulan dia cuti cukup sering karena berbagai peristiwa - entah dia sakit, atau harus menghadiri banyak acara pribadi dll.
3. Kami mendefinisikan sprint, atau peta jalan untuk setiap bulan. Dan di awal sprint, kita akan membahas jumlah pekerjaan yang harus dilakukan masing-masing pengembang dalam sprint dan pengembang dapat mengatur jumlah waktu yang mereka butuhkan untuk setiap tugas . Dia biasanya tidak akan bisa menyelesaikan semuanya. (Tidak apa-apa, para pengembang secara teratur kehilangan tenggat waktu bukan karena kesalahan mereka).
4. Saya berbasis di Singapura. Tidak yakin apakah itu penting. Ya, orang Asia dikenal pendiam, tetapi apakah itu penting?

Jika hanya satu atau dua peristiwa di atas terjadi, saya tidak akan merasa bahwa A sedang berkinerja buruk, tetapi semuanya terjadi bersamaan. Jadi saya merasa bahwa A sedang berkinerja buruk dan mungkin ... Tuhan melarang --- mengendur.

Ini hanya perasaan berdasarkan pengalaman saya sebagai programmer. Tapi saya bisa saja salah.

Sangat sulit untuk mengukur pekerjaan seorang programmer, mengingat bahwa tidak semua dua tugas sama, dan tidak ada tujuan standar untuk mengukur komitmen seorang programmer kepada perusahaan Anda. Sangat mustahil untuk mengatakan apakah programmer melakukan pekerjaannya atau mengendur. Yang bisa Anda lakukan, adalah mempercayai mereka - ya, percaya dan memberi mereka otonomi adalah cara terbaik bagi programmer untuk bekerja, saya tahu itu, jadi jangan memulai kuliah tentang mengapa Anda perlu mempercayai programmer Anda, terima kasih setiap banyak - tetapi jika mereka menyalahgunakan kepercayaan Anda, bisakah Anda tahu?

Hasil:

Saya sudah bicara langsung dengannya mengenai persepsi saya tentang penampilannya. Dia marah ketika saya menyarankan agar saya merasa dia tidak tampil pada level terbaiknya. Dia merasa bahwa ini adalah perasaan yang sama sekali tidak adil. Saya kemudian menjawab bahwa ini adalah perasaan saya dan saya tidak tahu apakah perasaan saya benar atau tidak. Dia tidak akan memiliki ini dan segera mengakhiri diskusi.

Sebelum pergi, dia berkata bahwa dia "akan mencoba memberi lebih banyak kepada perusahaan" dengan nada yang sangat dingin. Saya terkejut dengan reaksinya. Saya yakin bahwa saya menyinggung dia dalam beberapa hal. Namun, tidak terlalu yakin apakah itu hal yang benar untuk dilakukan agar aku terus terang padanya.

Pertanyaan saya adalah: Bagaimana Anda bisa tahu apakah programer Anda kinerjanya rendah? Tentunya ada tim yang berpengalaman yang tahu lebih baik dari saya dalam hal ini? 

Catatan tambahan:

1. Saya benci pengelolaan mikro. Jadi semua yang kita miliki untuk proses perangkat lunak kita adalah Sprint (di mana tugas diprioritaskan dan ditugaskan, dan pada akhir bulan, tinjauan jumlah pekerjaan yang dilakukan). Pengembang akan perlu memperbarui tugas saat mereka melakukan setiap hari.
2. Tidak ada pertemuan standup, atau semacamnya. Terutama karena kita memiliki kebebasan untuk bekerja dari rumah dan semua orang menghargai kebebasan ini.
3. Meskipun saya orang yang menetapkan tenggat waktu, tetapi pengembang akan memberikan perkiraan untuk setiap tugas dan saya akan memutuskan - berdasarkan perkiraan - tugas-tugas yang masuk ke sprint tertentu. Jika mereka tidak dapat menyelesaikan tugas di akhir sprint, saya akan mendorong mereka ke yang berikutnya. Jadi secara teoritis seseorang hanya dapat melakukan 1 atau 2 tugas selama seluruh sprint dan kemudian mendorong 99 tugas yang tersisa ke sprint berikutnya dan tetap dia akan baik-baik saja selama membenarkan ini - dalam bentuk pembaruan kemajuan pekerjaan harian

Ini seharusnya menjadi masalah yang sangat mudah dipecahkan.

Lakukan pertemuan kedua dengannya. Katakan padanya bahwa Anda menerima bahwa mungkin persepsi Anda tentang kenyataan yang salah. Kalau begitu, berkualifikasi dengan "Namun, jika itu masalahnya maka kita perlu bekerja sama untuk meningkatkan persepsi saya." Akhirnya tantang dia untuk menyelesaikan masalah itu, jadi dia tidak merasa dikelola secara mikro.

Hal persis ini terjadi pada saya sejak lama. Bagi saya, masalahnya adalah bahwa saya tidak menyukai kemungkinan bahwa siapa pun mungkin berpikir saya mencari kredit tambahan untuk sekadar melakukan pekerjaan saya. Dan itu cukup adil, tetapi harus ada lingkaran umpan balik yang teratur antara setiap anggota staf dan manajer lini mereka.

Jika tidak ada maka Anda mendapatkan masalah ini.

Reguler, terencana, 1: 1 adalah ide bagus. Dan, seperti yang ditunjukkan orang, standup tidak perlu ortogonal untuk bekerja dari rumah. Tetapi mereka harus melibatkan tiga pertanyaan: Apa yang Anda lakukan kemarin? Apa yang akan kamu lakukan hari ini? Dan yang kebanyakan orang lupa ... Apa (jika ada) yang menahan Anda?

Yang mengatakan, Anda harus mencoba untuk mencegah situasi di mana anggota tim tidak pernah bekerja bersama. Saya telah bekerja dalam situasi itu sebelumnya dan itu menumbuhkan ketidakpercayaan di dalam tim dan di luarnya. Semoga hari Anda teratur datang ke kantor. Adakan pertemuan rutin di mana orang dapat menyuarakan beberapa ide untuk meningkatkan proses atau apa pun.

Jangan menjadikannya acara pelaporan garis. Jadikan itu kesempatan untuk hanya berbicara. Anda akan terkejut dengan apa yang Anda pelajari. Jika memungkinkan, ubah itu menjadi acara sosial, pergi untuk minum-minum di waktu kerja sebagai latihan ikatan.

Ada banyak saran bagus di sini, dan saya tidak ingin mengambilnya, jadi saya memposting ini sebagai jawaban terpisah.

Pertama, jelas bagi saya (dan tampaknya orang lain) bahwa Anda belum menemukan akar masalahnya . Anda sedang menatap suatu gejala dan berusaha menyembuhkannya. Anda perlu mencari tahu apa yang menyebabkan begitu banyak gesekan antara diri Anda dan pengembang ini. Mungkin Anda terlalu berwibawa (Pemilik Produk saya baru-baru ini menggambarkan dirinya memiliki "Kekuatan Tak Terbatas" atas sebuah proyek dan itu menyinggung perasaan saya, meskipun dia tertawa ketika mengatakannya). Mungkin dia mengalami masalah keluarga yang parah (akan menjelaskan sepanjang waktu dari pekerjaan). Ada masalah root di sini, dan sampai Anda menemukannya, ini tidak akan diperbaiki.

Tangkapan yang bagus!

Jika kinerjanya bisa lebih baik, itu bagus karena Anda telah menentukan itu. Ingat juga, bahwa jika kinerjanya yang buruk masih merupakan kinerja yang baik sebagai perbandingan, maka Anda perlu melangkah hati-hati untuk menghindari kehilangan pengembang yang baik. Pengembang yang baik sulit didapat, dan pengembang yang baik membutuhkan serangkaian hal yang sangat spesifik. Mungkin lihat Tes Joel untuk melihat apakah kebutuhannya terpenuhi.

Temukan Sumber Masalahnya

Jika dia tidak senang dengan sesuatu yang berkaitan dengan pekerjaan yang dia lakukan, maka Anda hanya dapat memperbaikinya dengan menentukan sumber masalahnya. Biarkan saya jelas, Anda mengatakan programmer Anda menulis kode yang bagus. Itu artinya dia suka pemrograman. Lebih dari jelas bahwa dia frustrasi di tempat kerja (dari uraian pertemuan Anda), dan Anda mungkin benar bahwa kinerjanya di bawah di mana seharusnya, tetapi jangan berasumsi . Ingatlah bahwa banyak programmer tidak memiliki keterampilan sosial.

Anda juga tidak sempurna

Ingatlah bahwa kadang-kadang Anda akan mengalami konflik kepribadian, terutama dengan introvert . Jika ini ternyata merupakan konflik kepribadian, pertimbangkan seberapa jauh Anda bersedia untuk mendapatkan peningkatan kinerja (lihat 1)

Semua Itu Berkata

Saya menulis posting blog tentang Mengelola Pemrogram. Saya pikir Anda harus membacanya.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

Saya tidak bisa cukup menekankan bagian terakhir dari posting itu.

Jika pengembang Anda bagus, mereka ingin membuat kode.

Programmer Anda, meskipun dia malas, tidak ingin malas. Anda harus menemukan akar masalah ini, dan itu bisa berubah menjadi sesuatu yang tidak bisa diperbaiki dan dia harus dilepaskan, tetapi apa pun itu, Anda tidak dapat membuat keputusan tanpa informasi tanpa menentukannya.

Ketika merasa seseorang "agak sulit dikelola" seperti yang Anda gambarkan, untuk lebih memahami bagaimana kinerja seseorang dan apakah ada masalah (obyektif atau subyektif) yang memengaruhi produktivitas anggota tim pengembang, pertimbangkan untuk membuat praktik 1: 1 secara teratur bersama Anda anggota tim, sebagaimana disajikan dalam artikel yang luar biasa The Update, The Vent, dan The Disaster :

... Saya tidak menyarankan bahwa setiap 1: 1 adalah urusan berliku-liku untuk menemukan bencana yang muncul sangat tersembunyi, tetapi Anda ingin membuat tempat mingguan di mana ketidakpuasan mungkin diam-diam muncul. A 1: 1 adalah kesempatan Anda untuk melakukan pemeliharaan preventif mingguan sambil juga memahami kesehatan tim Anda.

... Suara yang mengelilingi rejimen sukses 1: 1 adalah diam. Semua mendengarkan, bertanya, dan diskusi yang terjadi selama 1: 1 adalah pemeliharaan preventif manajerial. Anda akan melihat ketika minat pada suatu proyek mulai berkurang dan mengambil tindakan sebelum menjadi ketidakpuasan kerja. Anda akan mendengar tentang ketegangan antara dua karyawan dan memoderasi diskusi sebelum menjadi pertandingan yang seru dalam rapat. Imbalan Anda untuk budaya 1: 1 yang sehat adalah kurangnya drama .

_{Poin yang sangat kuat dari artikel yang disebutkan adalah bahwa artikel itu mandiri , dalam arti bahwa selain menjelaskan manfaat, artikel ini juga memberikan serangkaian rekomendasi praktis yang pada dasarnya memungkinkan seseorang untuk mulai berlatih secara teratur 1: 1 tanpa menggali ke sumber lain (walaupun mencari informasi tambahan tidak akan sakit, Anda tahu).}

Jelas, ada masalah komunikasi utama di sini. Dia mungkin melakukan pekerjaan yang fantastis tetapi jika Anda punya perasaan bahwa Anda tidak tahu apa yang dia lakukan maka itu dengan sendirinya merupakan masalah. Dan jika Anda tidak tahu apa yang dia lakukan, maka rekan kerjanya mungkin juga tidak. Hal ini dapat menyebabkan masalah ketika dia memeriksa kode lamanya dua minggu. Terutama jika ada orang yang bekerja di area yang sama.

Anda selalu dapat menyarankan agar dia memeriksa / menyediakan pembaruan secara lebih teratur untuk meminimalkan konflik semacam ini. Ini dapat memungkinkan Anda untuk menulis permintaan Anda dalam hal membantu tim daripada "Saya tidak tahu apa yang Anda lakukan".

Saya tahu standups mendapatkan banyak kebencian tetapi sebenarnya tidak harus ditahan di ruangan yang sama. Panggilan cepat atau pembaruan Skype grup sekali sehari sangat cepat dan membuat semua orang di halaman yang sama.

Saya saat ini bekerja dari India dengan sebuah tim di Irlandia dan saya tidak bisa membayangkan tidak berkomunikasi dengan mereka masing-masing setiap hari dan saya tahu secara kasar apa yang mereka lakukan atau saya dapat mengetahuinya dengan sangat cepat.

Tak berarti

Pembaruan status harian tidak ada gunanya. Memiliki orang-orang melaporkan 'hari ini saya 2,5% selesai', 'hari ini saya 3,74% selesai' adalah konyol.

Ini tidak memberikan nilai bagi para pemangku kepentingan, dan mengganggu orang yang melakukan pekerjaan.

Biarkan mereka bekerja, tidak terganggu.

Tanpa dasar

Atas dasar apa menurut Anda bahwa pengembang A 'berkinerja buruk'? Jika pekerjaannya dilakukan tepat waktu, itu seharusnya cukup baik.

Anda mengatakan bahwa Anda membenci manajemen mikro, namun apa yang telah Anda jelaskan persis seperti itu.

Perusahaan kami mengharuskan pengembang untuk menunjukkan kemajuan pekerjaan dalam pelacak bug yang kami gunakan, tidak hanya untuk memantau programer tetapi untuk membuat para pemangku kepentingan tahu tentang kemajuan tersebut. ... Pengembang akan perlu memperbarui tugas yang mereka lakukan setiap hari.

Ini tidak ada gunanya (lihat di atas) omong kosong. Tim Anda tidak membalik burger, mereka sedang menyusun solusi teknis. Kemajuan tidak linier, juga tidak mudah diukur atau bahkan diperkirakan. Sekalipun demikian, pengukuran atau estimasi harian semacam itu tidak memiliki nilai.

Berbahaya

Periksa kembali dasar untuk 'perasaan' Anda bahwa pengembang A 'berkinerja buruk'. Anda pikir dia bisa berbuat lebih baik, tetapi atas dasar bukti apa?

Tidak bahagia! = Kinerjanya buruk

Lanjutkan seperti yang dijelaskan, dan pada titik tertentu, pengembang A kemungkinan akan memutuskan bahwa ia kurang dihargai, telah memberikan cukup kepada perusahaan, dan akan menemukan perusahaan lain. Meremas upaya 0,01% terakhir dari karyawan jauh lebih penting daripada mempertahankannya untuk jangka panjang.

Pengembang mungkin membenci upaya mendokumentasikan apa yang mereka lakukan dan memperbarui status - tapi itu bagian dari menjadi pengembang profesional. Saya menyarankan agar Anda dapat mencoba menunjukkan kepadanya bahwa keterlambatan pembaruan log masalah Anda menyebabkan persepsi negatif yang tidak perlu tentang karyanya. Jika dia tidak melihat bahwa kegagalannya berkomunikasi adalah masalah kinerja - yah, Anda adalah pemimpin timnya; katakan padanya itu.

Mengenai estimasi - itu masalah klasik. Saya sarankan membaca "Estimasi Perangkat Lunak - Demistifying the black art" oleh Steve McConnell. Dalam hal ini, Anda memberi kesan bahwa sebagian besar pengembang Anda di bawah perkiraan. Ini, anehnya, normal, dan jarang ditanggapi. Saya menyarankan agar Anda memiliki masalah dengan proses estimasi itu sendiri, daripada individu yang satu ini.

Cobalah untuk 'menutup loop' dari taksiran-taksiran-ulasan dan tingkatkan. Kemudian, jika pengembang Anda datang tepat waktu secara lebih teratur dan yang satu ini tidak, Anda dapat mempertimbangkan apa yang harus dilakukan tentang dia.

Akhirnya, adakan pertemuan berdiri. Bahkan jika itu melalui Pesan Instan. Yang Anda inginkan adalah semua orang tahu "apa yang saya lakukan, apa yang saya lakukan hari ini, masalah apa pun". Dan jika ada masalah, bawa offline untuk diskusi nanti. Itulah yang telah saya lakukan sebelumnya, dan itu berhasil untuk tim itu.

Hal pertama, mengapa sprint Anda selama itu? Sprint tidak boleh melebihi dua minggu. Saya pikir sebagian besar masalah Anda ada di sana. Saya akan merekomendasikan Anda untuk mempersingkat waktu sprint berdasarkan uji coba dan kemudian menganalisis pertanyaan Anda lagi.

Bagaimana dengan kode check-in? Apakah dia memeriksa kodenya setiap saat? Saya pribadi berpikir bahwa programmer tidak benar-benar orang manajemen dan semakin Anda mencoba untuk mengelola, semakin mereka akan frustrasi. Bahkan, saya benci melakukan tugas-tugas pembaruan itu dan mungkin itu sebabnya PM dan Leads ada untuk itu. Tetapi pada saat yang sama, saya memberikan status selama rapat scrum atau setiap kali kami bertemu. Sekarang ketika Anda menetapkan tugas, apakah mereka berkomitmen untuk timeline atau apakah Anda yang memberikan mereka timeline?

Oleh karena itu, satu-satunya cara saya dapat mengetahui apakah seseorang sedang dalam performa adalah memetakan garis waktu yang dilakukan untuk% pekerjaan yang dilakukan. Sekarang tentu saja, jika seseorang mengatakan bahwa dia perlu waktu dua hari untuk menulis metode yang menambahkan dua angka, Anda tahu ada masalah sehingga waktu harus sesuatu yang realistis dan disepakati oleh kedua belah pihak.

Ambillah dengan cara ini- Jika Anda dapat menulis sepotong kode dalam satu jam, beri dia satu jam + beberapa buffer. Jika dia memberikan itu kepadamu dalam waktu sebanyak itu, aku pikir maka kalian baik-baik saja. Jika dia tidak maka tanyakan padanya dan nanti terserah Anda untuk memutuskan apakah dia memberikan penjelasan yang masuk akal atau tidak.

Satu hal yang dapat Anda lakukan adalah mengintegrasikan sesuatu seperti XPlanner dengan alat versi.

Saya tidak berpikir profesi pemrograman secara inheren berbeda dari profesi lain ketika datang untuk mengidentifikasi seseorang yang malas. Anda mungkin harus pergi dengan usus Anda.

Saya pribadi merasa aneh jika A menolak memberikan pembaruan selama berminggu-minggu. Saya seorang programmer yang bekerja dari rumah, dan ada kontrak implisit antara saya dan majikan saya bahwa saya perlu memberikan pembaruan harian tentang kemajuan saya. Ini bukan pembaruan "resmi", ini hanya email pendek atau IM yang memberi tahu dia apa yang terjadi dengan perangkat lunak yang saya bayar untuk membuat. Pembaruan membutuhkan waktu kurang dari satu atau dua menit untuk menulis, dan menawarkan penutupan bagi kami berdua. Untuk perbaikan bug, saya menandai tiketnya sebagai terselesaikan di pelacak bug kami pada akhir hari. Ini bukan prosedur yang sulit bagi saya, meskipun saya menikmati lingkungan kerja yang santai dengan sedikit dokumen.

Bahkan pembaruan biasa akan dihargai datang darinya, saya yakin. Anda terdengar sangat, sangat lunak dalam posting Anda. Jika Anda curiga dia malas untuk waktu yang lama, Anda tidak perlu alasan lain untuk mengatasinya.

Standup harian meskipun melalui Skype atau di ruang obrolan adalah cara untuk mengatasi hal ini tetapi tidak jika Anda memperlakukannya sebagai pembaruan untuk pemangku kepentingan. Ketika sekali sehari seluruh tim hanya memeriksa untuk mengatakan apa yang telah mereka kerjakan, tantangan apa yang mereka hadapi dan apa yang mereka rencanakan selanjutnya, Anda mendapatkan beberapa kemenangan:

• Apakah Anda membuang-buang waktu untuk alasan yang baik atau buruk, bahwa sesuatu terlalu lama akan menjadi lebih transparan, mendorong devs Anda untuk meminta bantuan ketika mereka membutuhkannya dan tidak berlebihan dalam penelitian yang mungkin tidak perlu terjadi atau memecahkan masalah untuk tantangan itu ketika masukan dari anggota tim lainnya akan membantu mereka mengalahkannya lebih cepat.

• Anda, sebagai manajer dapat melihat di mana orang paling sering menghadapi penghalang jalan, yang membantu Anda memperkirakan lebih baik dan mungkin menyelesaikan masalah mendasar yang menghabiskan waktu / uang.

• IMO, itu benar-benar membantu tim belajar untuk melakukan estimasi yang kurang baik ketika mereka dapat melihat berapa lama biasanya bagi setiap orang untuk menyelesaikan sesuatu yang relatif mudah sekalipun.

• Anda akan sering diingatkan tentang hal-hal yang perlu dikomunikasikan dalam hal memprioritaskan kembali ketika anggota tim Anda memberi tahu Anda apa yang mereka rencanakan untuk dilakukan selanjutnya.

Jadi, lupakan '% selesai.' Buat saja proses untuk membuat semua orang jujur ​​dengan diri mereka sendiri seperti halnya dengan orang lain, membuat perkiraan yang lebih baik / lebih dapat diandalkan karena mereka mendapatkan lebih banyak pengalaman dalam hal itu, dan memberi orang lebih banyak motivasi untuk memiliki kemajuan untuk melaporkan tanpa membuatnya berubah pikiran. Latihan mematikan untuk meletakkan nomor pada sesuatu yang Anda benar-benar tidak bisa.

Sepertinya manajemen tingkat atas memahami bahwa tenggat waktu tidak selalu mendapat untung. Melakukan standup harian akan memberi Anda lebih banyak amunisi di bagian depan itu karena Anda akan memiliki ide yang lebih spesifik tentang mengapa mereka tidak tertabrak.

Dan jangan lakukan itu dulu. Selalu kesalahan IMO. Orang-orang perlu waktu untuk menenggelamkan gigi mereka kembali ke masalah sebelum mereka dapat dengan lebih andal melaporkan apa semua masalah itu, IMO.

Standup cepat yang lebih tentang komunikasi daripada akuntabilitas, dan hanya menetapkan tujuan, lebih dari apa pun yang membuat pekerjaan tangkas menurut saya. Sisanya yang bisa saya ambil atau tinggalkan, terutama Scrum, yang saya anggap sebagai minyak ular eksekutif / pemangku kepentingan.

Berperforma buruk?

Intensitas surut dan mengalir selama karier seseorang. Jika dia bernilai lebih dari yang dia bayar, maka berbicaralah dengannya dan cobalah untuk membuat pekerjaannya lebih mudah. Atau mulai mencari pengganti.

Komunikasi

Jangan mengandalkan pertemuan mingguan. Kebanyakan orang tidak akan melakukan braindump lengkap. Jadwalkan lebih banyak 1: 1s. Tanyakan kepada mereka bagaimana keadaannya, apa yang dapat Anda lakukan lebih baik, dan apa yang Anda rasa mereka bisa lakukan dengan lebih baik. Terkadang, tidak ada yang perlu dibicarakan, tapi itu tidak masalah. Dengan memiliki lebih banyak 1: 1, Anda meningkatkan kemungkinan mereka akan ingat untuk menyebutkan sesuatu.

Memiliki sarana komunikasi yang lebih gigih

Anda dapat memperoleh lebih banyak informasi dari orang-orang jika Anda tidak membuatnya merasa seperti pekerjaan tambahan. Jika semuanya jauh, minta mereka menggunakan program obrolan dengan kemampuan logging seperti Hipchat atau IRC. Memiliki sarana komunikasi yang lebih gigih mendorong orang untuk berbicara lebih banyak. Pimpin dengan memberi contoh dan sering berbicara, untuk mendorong orang lain melakukan hal yang sama. Setidaknya sekali sehari, minta orang mengatakan di mana mereka berada dengan proyek mereka. Terkadang, hanya dengan melihat obrolan, Anda dapat merasakan bagaimana berbagai hal berkembang.

Kontrol sumber

Mintalah setiap orang memeriksa kode mereka setiap hari. Jika Anda menggunakan git, minta mereka mendorong ke cabang mereka sendiri di repo perusahaan. Dengan melihat komitmen, Anda dapat mengetahui bagaimana kinerja mereka.

Pisahkan alat dari ujung

Para pemangku kepentingan ingin diperbarui? Hadapi sendiri para pemangku kepentingan. Bagian dari pekerjaan Anda sebagai manajer adalah menjadi payung sial, sehingga coder Anda dapat fokus pada pekerjaan mereka. Lihat log obrolan dan lakukan, kemudian tulis ringkasan tentang bagaimana keadaannya.

Ini saran saya:

1. Inovasi: Imajinasi dan kreativitas digunakan untuk menurunkan biaya dan memperbaiki situasi saat ini.

2. Korporasi: Kesediaan untuk membantu orang lain mencapai tujuan mereka

3. Inisiatif: Mencoba pekerjaan dan tugas non-rutin.

4. Kehadiran: Tidak ada atau terlambat, Di bawah standar.

5. Kewaspadaan: Kemampuan untuk dengan cepat memahami informasi dan situasi baru

6. Keakuratan dan Kualitas: Ulasan kode, tepat waktu, tingkat masalah).