Bagaimana kita dapat merencanakan proyek secara realistis sambil memperhitungkan masalah dukungan?

Kami mengalami masalah di tempat kerja: kami mencoba menjadwalkan pekerjaan agar kami dapat menilai skala waktu dan mendapatkan tanggal tenggat waktu.

Masalahnya adalah sulit untuk merencanakan suatu proyek tanpa mengetahui semua yang akan terjadi.

Misalnya, saat ini kami telah merencanakan semua proyek kami hingga awal Desember, namun pada saat itu kami akan mengadakan berbagai pertemuan internal dan eksternal, telekonferensi, dan pekerjaan tambahan. Semuanya baik dan bagus untuk mengatakan bahwa sebuah proyek akan memakan waktu tiga minggu, tetapi jika ada gangguan selama seminggu, maka tanggal penyelesaiannya akan didorong mundur satu minggu.

Masalahnya adalah 3 kali lipat:

1. Ketika kami menjadwalkan proyek skala waktu diambil secara harfiah. Jika kami memperkirakan tiga minggu, batas waktu ditetapkan untuk waktu tiga minggu, klien diberitahu, dan tidak ada ruang untuk perpanjangan.

2. Pekerjaan sementara dan dengan demikian berarti kita kehilangan waktu produktif mengerjakan proyek.

3. Kadang-kadang klien tidak memiliki waktu yang kami butuhkan untuk melakukan pekerjaan itu, sehingga mereka kadang-kadang datang kepada kami dan mengatakan mereka membutuhkan proyek yang dilakukan pada akhir bulan bahkan ketika kami berpikir bahwa pekerjaan itu akan memakan waktu dua bulan - Belum lagi kami sudah memiliki pekerjaan yang harus dilakukan.

Kami memiliki bagan Gantt yang kami coba isi dengan semua proyek yang kami miliki dan kami mengisi lembar waktu, tetapi mereka tidak dibandingkan dengan bagan Gantt sama sekali. Ini membuatnya sulit untuk mengatakan, "Yah, kami menjadwalkan 3 minggu untuk proyek ini, tetapi kami telah kehilangan satu minggu di sini sehingga batas waktu harus mundur seminggu."

Juga tidak profesional untuk tidak memenuhi tenggat waktu yang telah kami komunikasikan kepada klien.

Bagaimana orang lain menghadapi situasi seperti ini? Bagaimana Anda mengelola perencanaan proyek? Berapa banyak waktu "ekstra" yang Anda jadwalkan untuk proyek untuk menjelaskan pekerjaan non-proyek yang terjadi selama proyek? Bagaimana Anda menangani masalah dukungan, bug, dan lainnya? Hal-hal yang tidak dapat Anda pertanggungjawabkan selama perencanaan?

MEMPERBARUI

Banyak jawaban bagus terima kasih.

Masalahnya adalah bahwa sulit untuk merencanakan suatu proyek tanpa mengetahui semua yang akan terjadi.

Itulah poin manajemen risiko. Anda tidak dapat mengetahui segalanya, jadi Anda merencanakan berdasarkan pada apa yang Anda ketahui dan mengidentifikasi hal-hal apa yang paling berdampak pada rencana Anda dan seberapa besar kemungkinan hal itu terjadi. Nilai dampak jadwal potensial juga dengan mengatakan bahwa jika X terjadi, itu akan menyebabkan jadwal untuk tergelincir oleh perkiraan (kata kunci - diperkirakan) Y hari atau minggu.

Itu semua baik dan pepatah mengatakan bahwa proyek akan memakan waktu 3 minggu,

Jangan pernah memberikan perkiraan spesifik seperti itu. Berikan rentang atau kuantifikasi probabilitas mengenai perkiraan itu. Misalnya, katakan "proyek ini akan memakan waktu 2-5 minggu" atau "ada kemungkinan 85% proyek ini akan selesai dalam 3 minggu dan kemungkinan 95% akan dilakukan dalam 4 minggu".

Juga tidak profesional bagi klien untuk terus mengatakan kami telah melewati tenggat waktu.

Benar. Namun, Anda mencampurkan konsep "perkiraan", "jadwal", dan "tenggat waktu". Perkiraan Anda adalah perkiraan berapa lama untuk menyelesaikan tugas atau proyek yang diberikan dan probabilitas untuk memenuhi itu. Batas waktu adalah tanggal yang ditentukan pelanggan di mana proyek harus dilakukan untuk menambah nilai. Jadwalnya adalah bagaimana Anda menggunakan sumber daya yang tersedia untuk memenuhi tenggat waktu Anda.

Ada kalanya tidak mungkin menyelesaikan pekerjaan yang ditugaskan dalam tenggat waktu dan semua estimasi dan penjadwalan di dunia tidak akan membuat perbedaan.

Jadi pertanyaan saya ... bagaimana orang lain melakukan ini? Bagaimana Anda mengelola perencanaan proyek? Berapa banyak waktu "ekstra" yang Anda jadwalkan dalam sebuah proyek untuk memperhitungkan segala sesuatu yang terjadi dalam waktu yang berarti?

Saya merekomendasikan membaca dua buku, baik oleh Steve McConnell: Estimasi Perangkat Lunak: Demistifying the Black Art dan Rapid Development: Taming Wild Software Schedule . Estimasi Perangkat Lunak adalah tentang membuat perkiraan Anda, menyajikannya kepada klien, dan beberapa aspek negosiasi dan berurusan dengan harapan yang tidak realistis. Rapid Development adalah manajemen proyek umum, yang berurusan dengan siklus pengembangan, penjadwalan, alokasi sumber daya, dan cara menjadwalkan proyek dengan anggaran terbaik untuk memenuhi perkiraan dan tenggat waktu Anda.

Saya akan menyarankan untuk menggali rincian proses pengembangan Scrum . Ini mencakup kegiatan sidetracking oleh focus factormetrik. Pada dasarnya Anda harus bekerja 2-3 sprint / iterasi dan kemudian mengukur faktor fokus tim Anda (dan untuk setiap anggota itu akan sangat membantu juga). Setelah ini, Anda akan dapat memberikan perkiraan yang lebih akurat yang mencakup aktivitas harian.

Lihatlah artikel ini - "Faktor fokus"

Jika ada di antara Anda yang terbiasa dengan pengembangan Agile, Anda mungkin pernah mendengar tentang faktor fokus (atau faktor produktivitas). Ini digunakan untuk perencanaan untuk membantu menentukan berapa "jam nyata" Anda harus mengerjakan sesuatu. Ini perbedaan antara "jam nyata" dan "jam ideal".

Hal tentang gangguan adalah bahwa untuk individu atau tim tertentu mereka cenderung terjadi dalam kisaran probabilitas yang relatif kecil. Misalnya, Anda memiliki jumlah rapat yang sama setiap minggu, atau sekitar jumlah jam yang sama dihabiskan untuk perbaikan bug mendesak setiap bulan, atau jumlah waktu yang sama dihabiskan untuk menjawab pertanyaan bagi orang-orang yang mampir di meja Anda, terutama ketika dirata-rata lebih dari waktu yang lama.

Banyak teknik penjadwalan modern memperhitungkannya. Scrum faktor menjadi kecepatan. Penjadwalan berbasis bukti juga menggunakan kecepatan dengan interval kepercayaan untuk setiap perkiraan yang diberikan. Pomodoro memperhitungkan gangguan saat Anda memutuskan berapa banyak "pomodoros" yang bisa Anda andalkan dalam satu minggu tertentu. Semua ini tergantung pada pelacakan pengukuran historis gangguan Anda dan memasukkannya ke dalam perkiraan Anda. Saya sarankan Anda melihat semuanya dan menyusun teknik yang akan bekerja untuk tim Anda.

Nasihat bagus di sekitar.

Satu hal lain yang mungkin berguna untuk menangani masalah dukungan adalah mendedikasikan orang untuk mendukung secara "round-robin".

Misalnya, jika Anda memiliki 5 pengembang, tetapkan satu untuk setiap hari dalam seminggu. Ketika hari itu tiba, pengembang yang ditugaskan bekerja untuk hari itu HANYA dengan dukungan. Hari berikutnya, pengembang lain mengambil alih dukungan. Dengan cara ini setiap orang memiliki kesempatan untuk tetap berada dalam "aliran" mereka, semua orang dapat merasakan makanan anjing.

Bagaimana Anda SEBENARNYA memilih untuk membagi pekerjaan pendukung reguler tidak terlalu penting (robin sepanjang hari dalam seminggu hanyalah sebuah contoh). Yang penting adalah membatasi waktu dukungan untuk menetapkan interval reguler. Ini membuat waktu pengembangan lebih mudah diprediksi dengan trade-off yang Anda tidak bisa minta "semua orang meninggalkan segalanya" untuk menangani masalah dukungan.

Ini adalah keterampilan yang benar-benar disertai dengan pengalaman, dan seringkali orang ditanya sebelum mereka dapat menilai hal semacam itu secara akurat. Saya selalu bekerja dalam kelompok yang sangat dekat dengan gaya informal, tetapi kami mengembangkan beberapa aturan praktis yang tampaknya bertahan dengan baik.

Pertama, tidak ada tugas yang membutuhkan waktu kurang dari seminggu. Selalu perkirakan dalam minggu, bahkan jika tugas hanya tampak seperti itu akan membutuhkan beberapa hari untuk menyelesaikannya. Akan ada beberapa alasan mengapa hal itu tidak akan dilakukan sebelum akhir minggu.

Kedua, Berusahalah sebaik mungkin dalam memperkirakan jumlah waktu tugas yang akan diambil, termasuk gangguan, masalah dukungan pelanggan, menyelesaikannya melalui pengujian, dll. Sekarang, gandakan jumlahnya. Itu perkiraan Anda (dalam minggu).

Ketiga, pastikan manajer Anda belum menambahkan padding pada estimasi Anda. Tim kami memiliki manajer yang mengeluh tentang perkiraan kami. Ternyata dia sudah akan melipatgandakannya dengan 2.1 (perkiraan padding yang diturunkan secara empiris) dan kami telah menggandakannya sebelum memberitahunya.

Ini bukan alat yang mewah, dan mungkin bukan metode yang sempurna, tetapi ternyata bekerja dengan sangat baik.

Orang-orang yang melakukan estimasi perlu memahami bahwa tidak ada tim yang 100% mengerjakan proyek. Anda memiliki cuti sakit, liburan, tugas juri, cuti berkabung, diperlukan pertemuan SDM (ini adalah waktu manfaat!), Pertemuan tim yang tidak terkait dengan proyek, keterlambatan yang tidak dapat dihindari, istirahat di kamar mandi, mendukung pekerjaan pada barang-barang yang sudah dalam produksi, berurusan dengan email, , mengkonfigurasi komputer baru setelah yang lama mati, menjawab pertanyaan tentang pekerjaan di masa depan dan melakukan perkiraan untuk pekerjaan itu, membimbing junior, dll. yang harus diperhitungkan. Adalah tidak bertanggung jawab bagi penduga untuk mengasumsikan lebih dari 6 dari 8 jam tersedia per hari. Itu jaminan batas waktu tidak bisa dipenuhi. Jika Anda menjamin tenggat waktu tidak dapat dipenuhi, Anda menjamin pelanggan yang tidak bahagia.

Anda sepenuhnya benar - sulit untuk merencanakan proyek tanpa mengetahui semua yang akan terjadi. Tetapi sangat penting untuk melacak hal-hal yang merupakan norma dan juga tugas-tugas yang Anda inginkan. Di sinilah manajemen jadwal berperan. Saya telah menggunakan manajemen proyek Microsoft (versi standar) yang juga mencakup fitur yang menjadi bagian dari perangkat lunak penjadwalan manajemen proyek.

Anda dapat mengunjungi http://www.microsoft.com/project/en/us/schedule-management.aspx untuk informasi lebih lanjut.

Sepertinya ada banyak upaya tersembunyi yang diambil dari tim proyek Anda di mana Anda kehilangan fokus dan kecepatan. Mungkin bermanfaat untuk benar-benar memisahkan tugas untuk berurusan dengan

masalah ..support dan bug dan hal-hal?

kepada sekelompok orang tertentu sehingga anggota tim lainnya dapat fokus pada tugas pengembangan baru. Melalui ini produksi keseluruhan mereka mungkin turun sedikit tetapi kualitas akan meningkat karena ada sedikit gangguan. Sebagai gantinya ini akan mengurangi jumlah bug, karenanya pekerjaan a-hoc yang membuat itu jalan ke proyek Anda.

Sedangkan untuk bagian perencanaan, saya sepenuhnya setuju dengan jawaban Thomas Owens.