Bagaimana saya, pemimpin tim, mengevaluasi proyek

Timlid sering menghargai proyek, dan tidak semua orang melakukannya dengan baik. Di sini banyak tergantung pada kepribadian pemimpin tim itu sendiri, serta pada pemahamannya tentang tim. Ada banyak teknik untuk mengevaluasi proyek dari metode “dengan analogi” ke PERT. Tapi hari ini saya akan berbicara tentang bagaimana saya menggunakan poker perencanaan dan teknik lainnya untuk mengevaluasi lebih akurat dan dengan manfaat yang lebih besar.




Sebelum berbicara tentang pendekatan spesifik, ada baiknya untuk memikirkan kesulitan utama dari proses tersebut.

Selalu ada dua sisi untuk penilaian: tim dan klien. Karena berada di antara mereka, pemimpin tim atau manajer dipaksa untuk mencari keseimbangan kepentingan yang berlawanan. Tidak mungkin untuk melebih-lebihkan perkiraan, karena klien akan menolak untuk membayar lebih. Meremehkan juga tidak sepadan. Dalam hal ini, Anda harus mengganggu laju tim, mempertaruhkan kelelahan yang berlebihan, kelelahan, dan fakta bahwa kode masuk ke produksi tidak terkendali.

Kedalaman studi tentang tugas untuk evaluasi adalah pertanyaan filosofis. Tugas dapat didiskusikan untuk waktu yang lama, maka penilaian seluruh sprint akan tertunda. Tetapi jika Anda tidak mempelajari esensi, Anda dapat kehilangan sesuatu yang penting yang mempengaruhi tenggat waktu.

Pengembang yang lemah dan kuat bertindak secara berbeda. Jika pengembang yang kuat menghargai tugas, yang lemah tidak akan memenuhi tenggat waktu. Sebaliknya, yang kuat akan membuat tugas lebih cepat daripada yang lemah dihargai. Mempertimbangkan perbedaan dalam kecepatan pekerjaan, kesalahan "sosial" yang berbeda mungkin terjadi dalam penilaian, misalnya, ketika pengembang yang lemah akan "mengintip" pada waktu apa pengembang yang kuat mengevaluasi tugas, dan menetapkan tenggat waktu yang sama agar tidak menjelaskan mengapa "perkiraan" nya lebih panjang: " Dia menelepon minggu, tidak bisakah saya mengatakan bahwa itu akan memakan waktu tiga? Saya akan mengatakan setidaknya satu setengah ... ".

Yang disebut poker perencanaan membantu untuk mengatasi masalah ini, ketika seluruh tim berpartisipasi dalam penilaian, tidak tahu siapa tugasnya, dan mereka mengevaluasinya secara membabi buta, tidak melihat apa yang ditawarkan rekan kerja.


Penulis: Hkniberg dari Wikipedia bahasa Inggris - Dipindahkan dari en.wikipedia ke Wikimedia Commons., Public Domain Semua orang menjalankan

tugas di kepala mereka. Jika istilah yang dinyatakan oleh anggota tim sangat berbeda, diskusi dimulai. Pada saat-saat ini, biasanya tim tidak melihat adanya fitur yang harus diimplementasikan sebagai bagian dari tugas. Setelah itu, semua orang akan memilih ulang. Dan kemudian tidak ada klaim bahwa seseorang telah memperkirakan sesuatu yang salah - semua orang berpartisipasi. Bahkan jika ada kesalahan, tidak ada yang akan membuang waktu untuk mencari yang bersalah, akan ada percakapan yang lebih konstruktif tentang faktor-faktor baru apa yang telah muncul dan mengubah perataan (dan bagaimana memperhitungkannya di masa depan - memperbaiki kesalahan, saya menulisnya di artikel sebelumnya di paragraf 5 ).

Penilaian proyek yang lebih akurat membantu pertanyaan tambahan kepada klien. Tapi di sini Anda bisa dengan mudah melangkah terlalu jauh. Beberapa pengembang tidak diminta untuk penilaian justru karena mereka membombardir klien dengan sejumlah besar surat klarifikasi. Dari sudut pandang hubungan pelanggan, jumlah pertanyaan tambahan yang terbaik diminimalkan, dan ini meningkatkan ketidakpastian tugas.

Beberapa tips tentang cara menghindari kesalahan

Untuk meminimalkan kesalahan dalam penilaian, saya mengikuti beberapa aturan sederhana.

Saya memulai panggilan pengantar dengan klien sebelum membaca Kerangka Acuan. Pada panggilan ini, saya meminta Anda untuk berbicara tentang masalah dari sudut pandang burung: siapa yang akan menjadi pengguna akhir, bagaimana mereka akan menerapkan hasilnya, perangkat apa yang akan terlibat (dengan izin seperti itu), seperti apa tampilan backend jika sudah ada, dll. Setelah itu, Anda bisa mulai membaca TK.

Membaca ToR, saya membuat daftar pertanyaan untuk klien. Mempelajari tugas itu, di kepala Anda, Anda harus mencoba "menyandikan" seluruh proyek - bayangkan seperti apa bentuknya. Daftar pertanyaan harus sedemikian rupa sehingga, setelah menerima jawaban, dimungkinkan untuk membentuk penilaian yang andal.
Gagasan utama di sini adalah bahwa pertanyaan tidak boleh ditanyakan secara bertahap, tetapi pada suatu waktu. Dan seringkali lebih baik untuk memanggil daftar pertanyaan yang sudah disiapkan agar tidak memperpanjang korespondensi. Namun, teks tersebut menyampaikan informasi yang jauh lebih sedikit. Pada panggilan itu, Anda dapat menggeledah layar jika ini entah bagaimana menjelaskan situasi.

Jika menelepon tidak mungkin karena suatu alasan, saya mencari Dokumen Google, tempat saya akan menambahkan pertanyaan ini, dan pelanggan menjawabnya ketika saatnya tiba. Ini adalah cara yang lebih efektif untuk berkomunikasi pada tugas daripada obrolan pribadi atau surat. Dokumen ini selanjutnya dapat dikirim ke pengembang yang akan berpartisipasi dalam proyek - mereka tidak perlu mengajukan pertanyaan yang sama lagi.

Ngomong-ngomong, diharapkan bahwa orang yang bertanggung jawab atas proyek menjawab pertanyaan dari sisi klien, dan bukan mantan sekretaris direktur, yang hanya memainkan peran telepon yang rusak. Ini akan mengurangi risiko bahwa parameter proyek akan berubah secara langsung selama operasi.

Jika memungkinkan, saya membawa pengembang ke lapangan.Memahami bagaimana produk akan digunakan dalam kenyataannya membantu untuk titik "dan" dan meningkatkan skor. Misalnya, perangkat lunak untuk register kas sedang dikembangkan. Dan pengembang Anda telah duduk di depan komputer selama 15 tahun dan belum pernah melihat meja kas di mata mereka. Anda membawa mereka ke pengguna akhir, meminta untuk melakukan pembelian bukan di suatu tempat, tetapi secara khusus di toko ini. Dan mereka melihat bahwa Bibi Masha duduk di sana, yang menekan dua tombol bersamaan dengan jari-jarinya dan tidak dapat melihat huruf-huruf di kacamata di monitor. Akibatnya, banyak pertanyaan tentang proyek menghilang dengan sendirinya - font menjadi lebih besar, konfirmasi operasi ditambahkan. Sulit membayangkan hal-hal seperti itu di kepala saya. Dan perasaan kenyataan yang diterima dari kunjungan pribadi akan mendorong pengembang untuk satu tahun lagi.
Sayangnya, perendaman semacam itu tidak mungkin dilakukan di semua proyek.

Saya tidak mengevaluasi tugas jika kondisinya “dan” / “atau”. Misalnya, jika diusulkan untuk "melakukan otorisasi dan registrasi". Tidak ada masalah dalam memecah titik ini menjadi dua tugas dan mengevaluasi masing-masing secara individual. Penilaian semacam itu akan lebih akurat, karena Anda tidak akan mencampur entitas yang serupa, tetapi masih berbeda. Semakin baik dekomposisi, semakin akurat hasilnya.

"Atau" bahkan lebih buruk, itu selalu identik dengan TK kabur, dari mana tidak mungkin untuk membuat estimasi yang akurat. Apakah perlu atau tidak melakukan otorisasi melalui jejaring sosial? Bagaimana jika ada beberapa API khusus untuk backend? Jika Anda tidak tahu spesifiknya, Anda tidak bisa memberikan penilaian yang akurat.


Gambar: Michael Dubakov @ Medium

Tidak ada penilaian 40 jam untuk tugas tersebut.Ini adalah variasi lain dari aturan sebelumnya. Agile merekomendasikan penguraian proyek menjadi tugas yang tidak lebih dari 20 jam. Seharusnya tidak ada tugas yang tak terpisahkan selama seminggu kerja. Dalam porsi kecil, perkiraannya jauh lebih akurat.

Ketika menguraikan tugas, saya mencoba mencatatnya. Ini berguna sekaligus dari dua sudut.

Pertama, ini menyederhanakan proses. Segera setelah Anda mulai menuliskan pemikiran tentang suatu topik, otak mengembangkannya dengan senang hati. Ngomong-ngomong, itu sebabnya saya tidak merekomendasikan dekomposisi untuk dicampur dengan estimasi, yaitu pilih satu tugas dan evaluasi masing-masing dengan segera. Lebih baik memecah seluruh proyek menjadi komponen, memperbaikinya, dan kemudian mengevaluasinya sekaligus, sehingga tidak membuat kepala Anda bekerja dalam dua mode sekaligus.

Kedua, "log" dekomposisi membantu menjelaskan kemungkinan perbedaan antara perkiraan dan kenyataan di masa depan. Bahkan, Anda memiliki deskripsi lengkap tentang tugas yang sedang dibentuk - opsi apa yang Anda pertimbangkan. Sebagai contoh, Anda mempertimbangkan otorisasi akun dengan login dan kata sandi dengan token, token renew, dll, dan pelanggan, ternyata, masih menginginkan otorisasi melalui jejaring sosial, hanya saja tidak menulis tentang itu. Dekomposisi "log" Anda akan membantu melindungi tim dari klaim bahwa Anda menghargai sesuatu, tetapi tidak memenuhi tenggat waktu.

Saya mengajar tim untuk tidak mengambil tugas terkait sebelum mereka selesai.Pengembang menghabiskan banyak waktu untuk fitur tambahan. Mereka melakukan otorisasi, sepanjang cara mereka melihat bahwa sesuatu perlu diperbaiki di suatu tempat, dan menyelidiki proses samping ini. Saya mencoba memunculkan refleks: Saya melihat tugas yang menyertainya - membentuk tiket terpisah. Anda bahkan tidak harus menjalankan tugas melalui pemimpin tim atau manajer. Ketika pemimpin tim menganalisis tugas, dia sendiri akan melihatnya dan mengirimkannya untuk bekerja, jika perlu. Jadi Anda tidak perlu melepas siapa pun dari pekerjaan (membuat tugas dan melupakannya), dan keakuratan penilaian akan dipertahankan.

Saya menyediakan waktu untuk pengujian.Saat mengevaluasi, banyak yang melupakan penguji. Namun pada kenyataannya, tugas apa pun, terutama yang sulit, harus melalui pengujian oleh orang yang masih hidup - mereka harus memikirkannya, mencari bug. Jika mereka menemukan sesuatu, bug akan pergi ke pengembang yang sudah berhasil beralih ke konteks yang berbeda. Mereka harus menyelami topik itu lagi. Dan siklus ini dapat diulang lebih dari satu kali.
Waktu untuk pengujian harus ditentukan. Sebagai aturan, penilaian ini diberikan secara terpisah dari apa yang dikatakan pengembang.

Saya memperhitungkan waktu untuk pemrograman pasangan dan fitur-fitur lain dari pekerjaan ini.Pemrograman pasangan membantu untuk bertukar pengalaman dan memotivasi pengembang. Mereka duduk bersama atau mencari-cari di sekitar layar, mendiskusikan tugas dan alat yang digunakan, dan membuat beberapa perubahan pada gilirannya. Pendekatan ini bermanfaat bagi tim, tetapi dari sudut pandang pelanggan, tugas tidak bergerak dua kali lebih cepat. Pada proyek tempat saya bekerja, kami tidak berlatih pemrograman pasangan terus-menerus, tetapi beberapa tugas nyaman untuk melakukan hal itu. Dan kami memperhitungkan ini pada tahap penilaian.

Demikian pula, Anda perlu meluangkan waktu untuk demonstrasi kepada klien, menelepon, korespondensi, dll. Dan secara umum, agar sesuai dengan penilaian, pengembang harus bekerja secara efisien, dan untuk ini ia perlu cukup tidur, istirahat secara normal (dan bukan seluruh tim yang bertugas di akhir pekan produksi) dan tidak mendorong pekerjaan lebih cepat, lebih cepat. Oleh karena itu, evaluasi harus selalu didasarkan pada praktik kerja nyata, dan bukan pada perkiraan optimis bahwa kita semua akan duduk dan "membuat rencana lima tahun dalam tiga tahun".

Saya meluangkan waktu untuk perhitungan proyek. Ada empat jenis tegakan - pengembangan, pengujian, pra-produksi dan produksi. Lebih baik untuk memasang stan ini pada awal proyek dan segera berbaring untuk saat ini. Jika ini tidak dilakukan, sinkronisasi pengembangan, pengujian dan penyebaran akan terganggu, yang dapat berubah menjadi lelucon nyata.

Saya tidak membuat penilaian dari atas dan bawah - saya sebut istilah tertentu. Menurut aturan pemasaran, ketika pengembang mengatakan "dari 4 hingga 12 jam," ia berarti "melakukannya lebih cepat dari 12 jam." Klien mendengar "4 jam". Jika tugas selesai di 11, pengembang akan mempertimbangkan bahwa semuanya baik-baik saja, dan klien akan merasa tidak puas. Itu terjadi bahwa klien tidak bahagia, bahkan jika tugas selesai dalam 4 jam dan 15 menit. Oleh karena itu, bahkan jika label dibuat di dalam tim (perusahaan) dengan jangka waktu minimum dan maksimum, dan kemudian rata-rata dihitung (ada beberapa pengertian dalam pendekatan ini), hanya hasil akhir yang ditunjukkan kepada pelanggan.

Saya menyebutkan tanggal hanya dalam jam - bukan dalam hari atau bulan.Banyak orang berpikir bahwa jika proyek diperkirakan mencapai 96 jam, maka akan selesai dalam 12 hari selama 8 jam, dengan ketentuan bahwa satu orang mengerjakannya. Situasi ini dengan mudah diekstrapolasi ke dua pengembang, memberi peringkat 6 hari. Tetapi ini tidak benar. Ada banyak tugas yang saling bergantung. Pertama, pengembang tidak dapat mulai bekerja sampai templat proyek telah dibuat dengan semua sistem dan dudukan perakitan (dan dibuat 2-3 hari dengan mempertimbangkan keinginan klien). Kedua, semuanya berhenti ketika ada panggilan untuk perencanaan. Ketiga, ada pemblokiran bug yang mencegah Anda pindah. Dengan kata lain, 96 jam di tempat kerja tidak berarti sama sekali bahwa 100% dari waktu (8 jam sehari) akan dikhususkan untuk tugas-tugas ini. Untuk evaluasi dalam beberapa hari, kita dapat mengasumsikan bahwa pengembang belum 8, tetapi, katakanlah,6 jam kerja per hari (angka pasti harus ditentukan dari latihan).

Saya selalu bertanya kepada pengembang berapa jam tugas akan diambil dari komputer (dan bukan "setelah berapa lama akan siap"). Ini adalah konsekuensi dari paragraf sebelumnya. Berinteraksi dengan tim sebagai bagian dari penilaian, penting untuk merumuskan pertanyaan dengan benar.

Saya memperhitungkan "koefisien tim".Biasanya senior kemarin pergi ke timlids. Mereka mengevaluasi tugas berdasarkan pengalaman mereka, bahkan jika mereka memiliki middle di tim mereka. Mungkin senior tidak bekerja lebih cepat, tetapi setelah dia hampir tidak ada bug. Bagian tengah bukan kualitas seperti itu. Oleh karena itu, dalam Agile ada yang disebut "koefisien tim", yang menunjukkan perbedaan antara optimisme evaluator dan kehidupan nyata tim tertentu. Ini hanya dihitung dalam praktek: perkiraan teoritis dibandingkan dengan yang asli untuk sprint terakhir. Semakin baik pemimpin tim mengetahui timnya (dan semakin baik penilaiannya), semakin dekat koefisien ini ke 1.

Antara lain, "koefisien tim" juga memperhitungkan apa yang disebut "optimisme pengembang" ketika mengevaluasi. Tugas selalu dievaluasi berdasarkan tidak adanya kesalahan, kenyang dan suasana hati yang baik dari para pemain, tidak adanya masalah di lingkungan. Tetapi kenyataan penuh dengan kemungkinan dan tidak ada cara untuk melindungi diri Anda dari ini. "Rasio tim", dihitung selama periode waktu yang masuk akal, memungkinkan hal ini diperhitungkan.

Mencoba meletakkan pengaruh tim, terkadang dalam penilaian internal mereka beralih dari jam ke poin cerita. Mengetahui bahwa tugas akan mengambil 8 poin cerita, mereka ingat bahwa minggu lalu 1 poin cerita menghabiskan 8 jam. Dari sini diprediksi biaya tenaga kerja. Tetapi lebih mudah bagi saya untuk berpikir dalam hitungan jam.

Saya tidak memperkenalkan faktor tambahan agar tidak membingungkan peserta lain dalam proses ini.Saya sering melihat orang, melakukan penilaian di tingkat tim, meluangkan waktu untuk tawar-menawar di dalamnya. Tetapi unit evaluasi tidak boleh meletakkan stok ini atau mempertimbangkan hal-hal asing lainnya. Dan ternyata pengembang memberi nilai tugas pada jam 8, tetapi dikalikan dengan 2 untuk kesetiaan. Timlid menggandakan peringkatnya lagi, beradaptasi dengan tim. Dan manajer dari 32 jam menghasilkan 40 untuk klien (untuk akun genap atau hanya untuk tawar-menawar selama 30 jam kemudian). Ini lebih seperti meramal dengan alasan kopi. Ya, dan klien, melihat perkiraan 40 jam untuk tugas 8 jam, akan memutuskan bahwa tim tidak tahu caranya.

Seperti yang saya sebutkan di atas, di tingkat tim, Anda hanya perlu mempertimbangkan fitur-fitur tim itu sendiri, menyetujui siapa yang memasukkan force majeure dalam penilaian (dan harus diperhitungkan di sana, karena kami selalu mengevaluasi tugas, dengan asumsi bahwa editor kode tidak meminta lisensi, pengembang jangan sampai cuti sakit, dll.).

Tegas berdiri di tanah saya dalam membela penilaian. Akibat dari paragraf sebelumnya - saya selalu berdiri teguh pada penilaian saya. Jika saya tahu bahwa proyek akan dilakukan selama 6 bulan, dan mereka mengharapkan penilaian 3 dari saya, saya tidak akan pernah menyebutkan 4 bulan untuk "menyenangkan" pelanggan atau manajer.
Perlu dicatat bahwa kadang-kadang ada tawar-menawar internal. Ketika Anda tahu bahwa proyek itu harus siap untuk Tahun Baru, Anda secara tidak sadar mulai mencurangi hasil evaluasi untuk memenuhi sisa waktu. Otak memeras hal-hal ini dengan sempurna. Bahkan jika Anda memiliki daftar 200 subtugas di sana, mereka kemudian akan bertemu sedemikian rupa untuk memenuhi Malam Tahun Baru.

Terlepas dari semua ini, saya siap untuk penilaian berubah. Ini normal - proyek hidup, berkembang. Membentuk penilaian apa pun, saya mengerti bahwa ini adalah karakteristik proyek pada waktu tertentu.

Dan kata perpisahan terakhir: jangan memaksa pengembang yang tidak memenuhi tenggat waktu untuk menulis surat panjang kepada manajer tentang topik ini. Pertama, mereka cenderung pemalu. Kedua, manajer mungkin akan menanyakan sesuatu dan sekali lagi mengalihkan perhatian. Ketiga, surat penjelasannya hanya akan hilang dalam korespondensi. Saya biasanya meminta Anda untuk menulis komentar tentang tugas di Jira. Tanpa partisipasi dari orang yang hidup (manajer) biasanya lebih mudah dan lebih cepat. Dan selama tanya jawab itu akan mudah ditemukan. Dan timlidu plus - semua tugas yang tidak sesuai akan dikomentari. Sekali lagi, kerjakan bug untuk meningkatkan kualitas penilaian di masa depan.

Penulis artikel: Eugene Wetzel ( @imater )

PS Kami menerbitkan artikel kami di beberapa situs Runet. Berlangganan ke halaman kami diSaluran VK , FB , Instagram atau Telegram untuk mempelajari semua publikasi kami dan berita Maxilect lainnya.