Seringkali seorang praktisi ilmu data menjadi manajer proyek secara tidak sengaja. Mungkin tim proyek mereka terlalu kecil untuk memiliki manajer proyek penuh waktu, atau mungkin, bahkan jika ada manajer proyek, ilmuwan data masih perlu menetapkan, dan bertanggung jawab atas, tugas-tugas terperinci yang terkait dengan proyek tingkat tinggi. tonggak pencapaian. Misalnya, dalam tim proyek besar, data scientist mungkin bertanggung jawab atas tugas “mengembangkan model penetapan harga prediktif”, yang terdiri dari tugas-tugas kecil, eksperimen, nuansa, dan ketergantungan yang terlalu terperinci untuk disesuaikan dengan struktur manajemen proyek tradisional.
Ketika tiba saatnya untuk bertindak sebagai “manajer proyek tidak resmi”, hal ini biasanya memerlukan navigasi beberapa bagian yang bergerak, seperti keterlibatan pemangku kepentingan, menetapkan ekspektasi, memahami nilai bisnis proyek atau tugas, dan menetapkan metrik keberhasilan. Dari pengalaman saya, data scientist dengan soft skill yang baik biasanya akan berhasil dalam hal di atas. Sebaliknya, salah satu faktor yang sering diremehkan oleh para data scientist adalah durasi suatu tugas.
Itu akan terjadi pada kita semua. Kita akan menjadi bersemangat mengenai sebuah proyek, ketika pemangku kepentingan utama dengan santainya berkata: “Menurut Anda, berapa lama waktu yang dibutuhkan untuk menyelesaikannya?”. Dan hampir selalu kita meremehkan waktu penyelesaiannya.
Di bawah ini adalah dua karakter fiksi berdasarkan kisah nyata yang memberikan contoh kesalahan umum dalam estimasi waktu.
Chris sang Pembuat Kode
Seorang pemangku kepentingan senior menginginkan rekan ilmu data (sebut saja dia Chris the Coder) untuk melatih model guna mengklasifikasikan artikel berita yang relevan dan tidak relevan dari database yang dibeli perusahaan mereka.
“Hai Chris, berapa lama waktu yang dibutuhkan untuk melatih model agar dapat mengidentifikasi berita yang relevan dan tidak relevan?”
“Yah, bergantung pada ukuran datanya, saya memerlukan satu hingga dua hari untuk memprosesnya, kemudian beberapa hari lagi untuk menyempurnakan modelnya (saya akan mulai dengan garis dasar). Dari situ, saya dapat menghasilkan prediksi, sehingga pemangku kepentingan utama dapat memeriksanya kembali, dan berdasarkan iterasi tersebut, beberapa hari lagi untuk penyesuaian dan 1 hari untuk mendokumentasikannya dan membungkusnya menjadi sebuah kode yang dapat digunakan kembali”
Berdasarkan perkiraan Chris, dibutuhkan waktu sekitar 7 hari untuk melatih model, atau mungkin 10 hari dengan faktor perkalian. Namun, proyek khusus ini memerlukan waktu lima bulan untuk diselesaikan dan memberikan hasil akhir, sehingga banyak pemangku kepentingan senior yang kecewa.
Bagaimana Chris bisa salah memperkirakan waktu penyelesaian proyek ini? Kebetulan, Chris mengabaikan aksioma manajemen proyek lama yang mengatakan bahwa pekerjaan berbeda dengan durasi. Chris memperkirakan berapa banyak waktu yang dibutuhkan pekerjaannya. Dia tidak memperkirakan fakta bahwa untuk mendapatkan data berita, dia perlu memiliki akses ke tabel yang hanya bisa diberikan oleh dua orang setelah mendapat persetujuan pada pertemuan teknik yang diadakan setiap kuartal. Dia tidak memperkirakan fakta bahwa, setelah dia mendapatkan kumpulan datanya, tabel-tabelnya menjadi sangat tidak teratur sehingga dia harus mengatur pertemuan dengan pemilik aset untuk mendapatkan penjelasan. Dia tidak memperkirakan fakta bahwa kumpulan data tersebut begitu besar sehingga bahkan memvisualisasikannya memerlukan waktu seharian penuh, jadi dia harus menggunakan salah satu “sekutu” pekerjaannya, seorang insinyur data yang sibuk, untuk memprosesnya terlebih dahulu. Pada akhirnya, dia tidak memperkirakan durasi ketergantungan, yang meningkatkan total waktu penyelesaian proyek sebesar urutan besarnya!
Ellie sang Pengukur
Contoh umum lainnya dari kesalahan memperkirakan durasi adalah ketika seseorang dibawa ke suatu proyek di tengah jalan untuk “membantu” rekan kerja yang mungkin akan cuti untuk waktu yang lama. Atau mungkin proyek lama yang perlu dihidupkan kembali, dan tim yang mengerjakannya sudah lama tiada. Skenario ini terjadi pada teman saya Ellie, yang dikenal ahli dalam manajemen proyek. Berikut percakapan dengan manajernya.
“Tahun lalu kami melakukan proyek tentang perkiraan tayangan berdasarkan waktu. Orang yang melatih model tersebut telah pindah, namun kini salah satu pemangku kepentingan senior ingin memperbarui proyek agar menyertakan data baru. Saya rasa ini hanya memakan waktu satu atau dua hari, bagaimana menurut Anda?”
“Saya perlu melihat proyek tersebut setidaknya selama dua hari untuk mencoba dan memahami langkah-langkah memperbarui data, dan kemudian saya dapat kembali kepada Anda dengan perkiraan.”
Jawaban Ellie menimbulkan sedikit kekecewaan pada manajernya, namun hal itu menghemat waktunya dalam jangka panjang. Apa yang terlihat seperti “membuang-buang waktu dua hari” hanya untuk mencoba memahami proyek tersebut, memberikan gambaran yang baik tentang tugas tersebut. Seandainya dia tidak “membuang dua hari”, dia tidak akan menyadari bahwa:
- Kode tersebut tidak memiliki dokumentasi yang jelas. Dia tidak begitu paham dengan model tersebut, dan presentasi power-point yang menyertainya tidak membantu memperjelas cara mereproduksi hasil.
- Beberapa fitur tampaknya telah dikodekan secara keras, dengan sedikit penjelasan mengapa fitur tersebut harus seperti itu
- Model yang dilatih tampaknya spesifik untuk tahun tersebut, dan perlu dilatih ulang jika dia ingin modelnya akurat
- Salah satu bagian dari kode tersebut berbunyi “diverifikasi secara manual oleh Carlos”, yang menyiratkan bahwa pemangku kepentingan lain harus memverifikasi data setelah diperbarui.
Masing-masing langkah tersebut mengantisipasi risiko dan menambah total durasi proyek (serta kemungkinan keberhasilan secara keseluruhan). Tak satu pun dari mereka yang merupakan penghambat total, namun mereka harus ditindaklanjuti. Dengan mengkomunikasikannya dengan jelas, dia dapat memberikan tenggat waktu yang lebih tepat kepada manajernya, sehingga mengurangi ekspektasi.
Kedua contoh ini menunjukkan kepada kita bahwa memperkirakan pekerjaan Anda sendiri biasanya hanya merupakan salah satu elemen dalam menilai durasi proyek Anda yang dikecualikan. Kami mengetahui berapa lama waktu yang kami perlukan untuk melatih model pembelajaran mesin, menghasilkan grafik, atau mengembangkan aplikasi browser dasar. Namun untuk memperkirakan durasi suatu tugas, kita perlu mempertimbangkan faktor-faktor yang sering kali berada di luar kendali kita. Berikut adalah daftar tema umum, yang tidak lengkap:
- Berapa lama waktu yang dibutuhkan untuk mendapatkan akses ke data?
- Apakah saya memiliki izin yang diperlukan? Siapa sajakah orang yang dapat memberi saya akses, dan seberapa cepat mereka dapat melakukannya?
- Seberapa terorganisir datanya? Apakah ada kamus? Apakah saya memiliki akses ke pemilik aset yang memahaminya?
- Ketika tiba di suatu proyek di tengah jalan, seberapa baik dokumentasi proyek tersebut?
- Jika orang lain di tim Anda harus memberikan masukan pada proses tersebut, seberapa sibuk mereka dan seberapa andal tenggat waktu mereka?
- Jika Anda membutuhkan masukan dari pemangku kepentingan, lakukan saja.
Seringkali berguna untuk menuliskan tugas ke dalam sebuah tabel, mengidentifikasi mana yang penting, sebuah alat yang biasa disebut oleh manajer proyek sebagai pemetaan ketergantungan. Perangkat lunak spesifik yang Anda gunakan tidak relevan — tim yang berbeda akan menggunakan perangkat lunak yang berbeda untuk mencatat tugas (atau jika Anda adalah orang yang suka melakukan post-it, lakukanlah!). Di bawah ini adalah contoh tingkat tinggi tentang bagaimana dependensi dapat dipertimbangkan:
Memiliki peta ketergantungan yang akurat adalah tugas yang sulit, dan Anda mungkin perlu memperbaruinya secara berkala, menyesuaikan dengan keadaan yang tidak terduga. Sebaliknya, tidak adanya peta berarti meremehkan durasi suatu proyek. Peta tersebut harus dapat dilihat oleh pemangku kepentingan utama dan mencerminkan perkiraan terbaik Anda untuk setiap tugas. Yakinlah bahwa waktu awal yang diinvestasikan untuk memikirkan tugas Anda adalah waktu yang dihabiskan dengan sangat baik!
Anda bisa menjadi ilmuwan data tercepat di dunia dalam hal menulis kode namun tidak memenuhi tenggat waktu jika Anda tidak memperhitungkan durasi ketergantungan Anda.
Jika Anda memiliki alat lain untuk membantu Anda memperkirakan durasi proyek ilmu data, silakan beri komentar di bawah!
Catatan: Istilah manajer proyek “tidak disengaja” atau “tidak resmi” berasal dari dua buku yang sangat saya rekomendasikan: Manajemen Proyek untuk Manajer Proyek Tidak Resmi oleh Kary Kagon, Suzette Blakemore dan James Wood dan Accidental Agile Manajer Proyek: Zero to Hero dalam 7 Iterasi oleh Ray Frohnhoefer dan penulis lainnya.
