Berurusan dengan perkiraan sebagai programmer junior

Saya telah bekerja selama beberapa bulan sekarang di sebuah perusahaan yang memperkirakan (untuk populasi umum, bukan junior khusus) tugas dan kemudian kita diberi tugas, menyelesaikannya, melewati dua tes dan pada akhirnya estimasi harus agak bertemu.

Saya sangat tertekan karena beberapa perkiraan tidak mungkin saya penuhi. Saya masih belum tahu keseluruhan sistem (karena itu cukup besar) jadi kadang-kadang separuh waktu dihabiskan untuk mencari tahu apa yang perlu saya lakukan dan di mana dan pada saat saya menyelesaikan kadang-kadang estimasi sudah berakhir dan masih ada pengujian untuk menjadi dilakukan (dan memperbaiki kesalahan jika ada).

Kedua kalinya saya harus berurusan dengan fungsionalitas yang sama, semuanya bekerja jauh lebih cepat, tetapi sejauh ini saya merasa seperti saya hanya buruk dalam pemrograman.

Apakah ada sesuatu yang Anda lakukan ketika Anda baru memulai yang membantu Anda melewati tahap ini? Saya menjadi sangat stres ketika saya melihat betapa sedikit waktu yang ada untuk kode yang kadang-kadang saya bahkan tidak bisa fokus dengan benar pada apa yang saya lakukan yang membuatnya semakin buruk.

• Banyak pengembang dengan sedikit pengalaman manajemen memperkirakan tugas menggunakan kecepatan mereka sendiri atau kecepatan pengembang "terbaik" dalam tim.

• Kecepatan bervariasi sesuai pengalaman. Pengembang senior dapat membutuhkan waktu 3 jam untuk menyelesaikan sesuatu, padahal dibutuhkan 2 hari kerja untuk menyelesaikan masalah yang sama.

• Stres jarang dapat dihindari ketika Anda mengambil pekerjaan baru. Setelah beberapa bulan biasanya menjadi lebih baik, dengan asumsi Anda melakukan pekerjaan yang cukup dan mengajukan banyak pertanyaan yang relevan.

• Para senior Anda mungkin tidak menyadari bagaimana perasaan Anda tentang perkiraan, oleh karena itu penting bagi Anda untuk bertanya kepada mereka apa yang mereka harapkan dari Anda.

Dari pengalaman saya:

• Saya pikir pengembang senior atau manajer harus dapat memperkirakan cerita pengguna (persyaratan bisnis) dalam hal ukuran t-shirt (XL, L, M, S, XS).

• Adalah tugas pengembang untuk memecah cerita pengguna menjadi tugas yang lebih kecil dan memperkirakannya. Tugas besar mungkin membutuhkan pengembang senior sehari untuk menyelesaikannya, ketika itu mungkin membutuhkan Anda seminggu penuh.

• Sangat penting untuk mencatat berapa lama waktu yang Anda butuhkan untuk menyelesaikan tugas.

• Manajer proyek atau pengembang senior yang baik akan terus mengumpulkan statistik ini. Ketika produktivitas Anda meningkat, mereka akan menyadarinya dan mereka akan mengirim lebih banyak pekerjaan dengan cara Anda.

Ini tidak hanya akan membuat hidup Anda tidak terlalu stres, tetapi juga akan memungkinkan departemen untuk mengelola sumber daya mereka secara efektif.

Bawa ini dengan pemimpin tim Anda, manajer proyek dan / atau siapa pun yang melakukan estimasi Anda; bukan kita. Orang-orang mengerti bahwa hal-hal tidak mengambil jumlah usaha yang sama untuk semua orang, dan mereka dapat bekerja untuk menyesuaikan taksiran ketika tugas ditugaskan atau paling tidak menghilangkan segala ketakutan yang Anda miliki tentang periode ulasan.

Ini, menurut pendapat saya, alasan bahwa perkiraan harus dilakukan oleh orang-orang yang ditugaskan tugas (dengan masukan / kolaborasi dari pemimpin / rekan kerja). Anda mendapatkan perkiraan yang lebih akurat untuk berapa lama pekerjaan itu benar-benar akan membuat orang melakukannya.

Saya tidak bisa membayangkan posisi yang lebih buruk untuk menempatkan pengembang junior daripada menetapkan harapan yang tidak bisa mereka pertahankan, kecuali tentu saja mereka melakukannya untuk menantang Anda. Apakah Anda memiliki dampak nyata untuk tidak memenuhi taksiran?

Saya katakan pertama, penting bagi Anda untuk belajar memperkirakan sendiri. Ketika Anda diberi tugas, segera perkirakan pada apa yang menurut Anda akan diambil, dan kemudian mulai menemukan delta di antara keduanya. Saya hampir bisa bertaruh bahwa kualitas sedang dikorbankan dalam perkiraan awal yang singkat. Jika mereka mengharapkan Anda untuk mendesain dan mengembangkan item lebih cepat daripada yang Anda bisa, Anda mungkin perlu mengobrol dengan seseorang untuk menyelesaikan masalah.

Kedua, pahami bahwa kualitas adalah fitur yang dapat diputuskan oleh pemegang saham, bos Anda, untuk membayar. Ini mungkin sesuatu yang harus Anda korbankan sedikit untuk memenuhi persyaratan pada waktu yang Anda miliki.

Either way, menghilangkan stres, itu tidak menyenangkan terus merasa seperti Anda selalu di belakang menulis kode yang buruk. Semoga ini membantu.

Ini biasa.

Secara umum, lebih baik memberikan perkiraan yang lebih besar, daripada yang lebih kecil (Lagi pula, sebagian besar waktu Anda akan melampaui taksiran). Saya menyarankan Anda untuk memotong tugas menjadi subtugas sekecil mungkin dan memperkirakannya dengan masing-masing tugas tidak lebih dari 4 jam.

Jika suatu tugas dapat memakan waktu lebih dari 4 jam, pilah menjadi beberapa subtugas. Tambahkan juga buffer persentual untuk tugas-tugas yang tidak dapat Anda ramalkan sekarang (preferensi pribadi saya adalah 1 tugas tak terduga untuk setiap 2 tugas yang diperkirakan dengan setiap tugas tak terduga mengambil 2 - 4 jam tergantung pada sistem yang Anda gunakan untuk bekerja).

Setelah itu tambahkan waktu yang Anda pikir akan diperlukan untuk pengujian, komunikasi, analisis dll.

Pertama: Jika Anda mendapatkan lebih cepat dengan setiap upaya pada suatu masalah, Anda mungkin bukan programmer yang buruk. Jadi mari kita singkirkan pemikiran itu.

Saya akan menyarankan ini adalah kegagalan manajer Anda, tetapi itu dan akan selalu menjadi tugas Anda untuk mengelola harapan.

Daripada menyalahkan diri sendiri karena tidak dapat memenuhi tenggat waktu yang tidak realistis, mengukur berapa hari kerja yang dapat Anda lakukan dalam seminggu. Kemudian jelaskan kepada pimpinan tim Anda bahwa Anda baru dalam pengembangan bisnis dan perangkat lunak dan Anda hanya dapat diharapkan agar n hari kerja pengembang senior menjadi minggu standar. Setidaknya mereka harus memahami ini, bahkan jika mereka tidak menyukainya.

Beri tahu mereka bahwa Anda berharap untuk terus meningkatkan dan menunjukkan kepada mereka bagaimana Anda bisa mengukur peningkatan itu. Dan setuju dengan mereka bahwa Anda tidak mengharapkan upah senior sampai Anda dapat melakukan 5 hari kerja pengembang senior dalam seminggu. Tetapi juga Anda tidak mengharapkan tanggung jawab yang sama dengan seorang senior ketika Anda tidak dibayar hampir sebanyak itu.

Untuk mengambil ini lebih jauh, inilah sebabnya saya seorang pendukung kuat menggunakan poin cerita daripada jam untuk estimasi. yaitu. Setiap pekerjaan mendapat sejumlah poin, dan tim memperkirakan berapa banyak poin yang bisa mereka raih dalam periode waktu tertentu. Periode berikutnya, perkiraannya sama dengan yang sebenarnya dari periode sebelumnya, disesuaikan dengan faktor-faktor yang diketahui seperti bulan libur berat atau cuti pengembang.

Sebagai seorang manajer, ketika pengembang baru masuk (junior atau senior), saya menjelaskan kepada bisnis bahwa kami tidak akan meningkatkan perkiraan pada contoh pertama. Pengembang itu diharapkan akan mengambil banyak waktu dari pengembang lain saat mereka menghemat. Pengembang baru mungkin akan melakukan yang lebih baik dari itu, tetapi di bawah-janji dan pengiriman berlebihan adalah mantra.

Pengembang akan meningkat seiring waktu, lebih cepat dari senior junior, dan "kecepatan" tim - perkiraan bulan ke bulan - akan meningkat seiring dengan itu.

Tetap tenang dan terus berjalan. Jika masalah Anda yang tidak memenuhi perkiraan itu pernah muncul, katakan saja kepada mereka hal-hal yang sama dengan yang Anda tulis di pos Anda, atau jika Anda merasa tidak aman, bicarakan dengan mentor / pimpinan tim Anda sendiri.

Estimasi hanya itu, perkiraan. Mereka bisa dan akan pergi, lebih-lebih ketika Anda belajar tali. Dan sebagai junior, kemungkinan Anda mempelajari tali sebagai anggota tim pada proyek khusus itu, sebagai seorang programmer yang menggunakan teknologi apa pun yang Anda gunakan dan sebagai karyawan di perusahaan Anda. Dan jika Anda bekerja dengan orang-orang yang masuk akal, mereka berharap Anda akan tidak sesuai dengan perkiraan.

Anda cenderung melihat tugas-tugas yang Anda dapatkan "dari bawah ke atas". Tugas Anda lebih penting bagi Anda daripada gambaran besar proyek yang sedang Anda kerjakan - itu bisa dimengerti. Anda melihat perkiraan sebagai batasan yang diberikan pada Anda dan jelas-jelas mulai cemas ketika Anda tidak memenuhinya.

Tetapi ketika Anda melihat gambaran besar, Anda akan melihat bahwa perkiraan, bahkan lebih dari 'target' untuk pengembang, adalah 'sinyal' untuk lead / manajer proyek. Memecah pekerjaan menjadi tugas dan memperkirakannya adalah cara untuk mengurangi kerumitan dalam mengelola dan memperkirakan keseluruhan proyek. Melacak pekerjaan aktual yang dilakukan vs perkiraan adalah cara untuk melacak bagaimana kinerja proyek, tetapi hanya salah satu metrik yang dapat diterapkan. Ketika perkiraan tidak terpenuhi secara teratur, itu merupakan sinyal bagi manajer bahwa ada sesuatu yang salah dengan proyek tersebut. Namun dalam setiap proyek yang masuk akal, itu tidak akan menjadi kenyataan bahwa ada pengembang junior di tim yang tidak memenuhi estimasi.

Izinkan saya memperkenalkan Anda kepada dua teman saya, WAG dan SWAG

Yaitu, 'Tebak Assed Liar' dan 'Tebak Assed Liar Ilmiah'

Percaya atau tidak, saya tidak mengada-ada. Mereka sebenarnya sangat umum dalam bisnis. Lihatlah artikel ini untuk melihat apa yang saya maksud.

Idealnya, yang terbaik adalah membuat estimasi yang kuat tetapi jika Anda tidak bisa, lebih baik untuk menyatakan bahwa estimasi tersebut kasar karena data yang tidak lengkap daripada berbohong.

Kuncinya adalah, bisnis bukan pemrograman komputer. Mengelola harapan lebih penting daripada presisi. Sangat penting untuk menilai waktu yang Anda pikir perlu ditambah 10% sebagai kemungkinan untuk menebus masalah yang tidak terduga.

Jika Anda melebih-lebihkan, mereka akan senang ketika Anda selesai dengan waktu luang. Jika Anda meremehkan, mereka tidak akan kecewa jika Anda memenuhi tenggat waktu atau sangat kecewa jika terjadi kesalahan.

Bisnis adalah area abu-abu yang beberapa orang rasakan secara intuitif dari waktu ke waktu. Fakta bahwa mereka meminta pengembang junior untuk membuat keputusan semacam ini secara mandiri mengatakan satu hal. Entah mereka tidak memiliki siapa pun yang tersedia yang lebih mampu membuat keputusan semacam itu atau manajer tidak ingin bertanggung jawab atas kegagalan.

Saya akan menaruh uang saya pada yang terakhir jika Anda bekerja untuk organisasi besar. Ketika model bisnis hierarkis tumbuh cukup besar, puncaknya sangat jauh dari bawah sehingga atasan hanya bisa mengukur kemajuan dengan apa yang mereka terima di atas kertas. Ini adalah lingkungan yang mengerikan karena promosi biasanya diberikan untuk tidak membuat kesalahan. Tetapi orang-orang yang mendapatkan promosi menghindari kegagalan dengan mendorong tanggung jawab mereka pada orang lain (yaitu ketidakmampuan buta) dan mengambil pujian untuk keberhasilan orang-orang yang lebih rendah dalam rantai.

Sayangnya, programmer adalah sasaran empuk untuk melempar 'di bawah bus' karena tidak peduli seberapa besar masalahnya, kami akan mencoba mencari solusinya. Kuncinya adalah, jangan menghabiskan lebih banyak waktu untuk menentukan bagaimana memperkirakan masalah daripada Anda menerapkan solusi.

Itu tempat yang sulit. Kedengarannya seperti Anda terjebak dalam tahap "hanya harus menyampaikan" pipa itu.

Selama bertahun-tahun saya telah memperhatikan hal berikut tentang estimasi: Kualitas estimasi dapat ditentukan dengan menjawab (dengan nama yang tepat) tiga pertanyaan berikut.

• Siapa yang membuat desain?
• Siapa yang membuat estimasi?
• Siapa yang melakukan implementasi?

Kualitas estimasi berbanding terbalik dengan jumlah individu yang disebutkan. Sebagai contoh: estimasi terbaik adalah ketika orang yang sama telah melakukan ketiga tugas di atas, estimasi yang lemah adalah ketika satu orang melakukan desain / estimasi dan yang lain akan melakukan implementasi, dan estimasi terburuk adalah di mana ketiga pertanyaan dijawab dengan nama yang unik.