Mengapa Anda tidak pernah mendapatkan sebanyak yang Anda rencanakan? [Tutup]


26

Saya selalu memulai hari dengan berpikir "Saya akan dengan mudah menyelesaikan ini pada akhir hari" dan menetapkan apa yang tampak seperti target yang realistis.

Jadi mengapa saya tidak pernah memukulnya? Tugas selalu berakhir memakan waktu 3x lebih lama karena bug yang tidak terduga, perubahan menit terakhir dll.

Apakah hanya saya? Saya sepertinya tidak menjadi lebih baik dalam memprediksi apa yang dapat dilakukan dalam sehari.


8
Bukan hanya kamu. Lihat hukum Hofstadter .
Peter Boughton

18
Karena Anda membuang-buang waktu untuk mengajukan pertanyaan pada P.SE, alih-alih melakukan pekerjaan Anda :) :)
Jas

2
Lain kali Anda memperkirakan tugas, gandakan hasilnya dengan 3, dan Anda aman;)

3
Saya tidak berencana melakukan apa pun, dan saya selalu menang. Saya mengukur semua bug saya sebagai tak terbatas, jadi kecepatan saya selalu tidak terdefinisi.
Ayub

1
Bos lama saya dulu mengatakan bahwa kutipan waktu saya ada di tahun kucing . Saya pikir dia baru saja memindahkan setiap kutipan dengan satu urutan besarnya. Jam -> Hari; Hari -> Minggu; Minggu -> Bulan; Bulan -> Pengembalian Dana Klien.
Orbling

Jawaban:


17

Karena Anda tidak pernah diajari cara merencanakan.

Perencanaan adalah keterampilan , seperti halnya menulis atau menulis. Namun, entah bagaimana, hal itu ditinggalkan hampir di setiap kurikulum.

Itu perlu dipelajari dan dipraktikkan, dan perkiraan kemampuan Anda sendiri perlu terus diperbarui. Inilah sebabnya mengapa praktik kerja seperti Agile menekankan untuk mengukur pekerjaan aktual Anda di masa lalu dan membandingkannya dengan perkiraan Anda, sehingga Anda dapat meningkatkan kemampuan perencanaan Anda.

Seperti yang orang lain katakan, Anda perlu memperhitungkan tidak hanya untuk tugas itu, tetapi untuk semua pendahulunya, tugas yang menyertainya (misalnya, belajar bagaimana melakukan X), dan Anda harus menyadari bias mental internal Anda sendiri yang akan mencegah Anda dari menghitung dengan benar cara Anda benar-benar bekerja.

Berlatihlah, dan siapa tahu, Anda mungkin menjadi lebih baik.


8
Selain tidak merencanakan untuk semua pemakan waktu kecil dalam sehari membuat perencanaan sulit, perencanaan juga merupakan keterampilan yang tidak menyenangkan untuk dipelajari. Ketika Anda membuat kesalahan pengkodean, Anda mendapatkan bug dan Anda memperbaikinya dan Anda belajar pelajaran. Ketika Anda mendapatkan kesalahan perencanaan, ANDA GAGAL !!! Melewati tenggat waktu membuat Anda merasa buruk dan itu membuat Anda merasa gagal, begitu banyak orang yang tidak merencanakannya. Untuk mengatasi ini, saya mulai membuat daftar todo yang sangat terperinci dan terperinci, tetapi saya selalu memberi saya waktu ekstra yang bodoh. Maka saya merasa sangat berhasil karena saya selalu di bawah anggaran tepat waktu!
CodexArcanum

@ Codex, poin bagus. Ada beberapa cara untuk membuat "kegagalan perencanaan" menjadi sesuatu yang bisa Anda 'kode perbaikan'. Setiap kegagalan perencanaan adalah kesempatan untuk belajar. Lihatlah ke dalam teknik seperti Root Cause Analysis untuk membantu memahami konteks kegagalan, sehingga Anda dapat merencanakan lebih baik lain kali dan memperkenalkan langkah-langkah penanggulangan khusus yang akan mencegah kegagalan di masa depan.
Alex Feinman

1
Bukan saja tidak menyenangkan untuk dipelajari, sering kali terasa seperti buang-buang waktu. Saya menyebutnya "metawork" - menghabiskan waktu menganalisis atau mengatur tubuh kerja Anda. Ketika ada banyak hal yang harus dilakukan, metawork dapat merasa seperti Anda membangun sendiri sebuah gua terisolasi di bawah longsoran salju bukannya mencoba menggali diri sendiri, tetapi sebenarnya yang Anda lakukan adalah mempertajam alat Anda dalam persiapan untuk pekerjaan yang akan datang.
nlawalker

Pada tulisan ini, ada 11 orang yang telah mengangkat jawaban ini. Yang berarti ada 11 orang yang berada di bawah khayalan bahwa sebenarnya ada rencana yang akan memperkirakan waktu yang dibutuhkan dengan tepat.
Robert Harvey

@nlawalker: Tidak menyenangkan untuk dipelajari? Jika saya tidak belajar sesuatu yang baru dalam satu hari, neraka dalam setiap jam di hari bangun, saya menganggap hari itu sebuah kegagalan.
Orbling

26

Sulit dipercaya bahwa belum ada yang menyebut hukum Hofstadter .

Saya pikir jawaban sebenarnya adalah bahwa perencanaan Anda selalu mengasumsikan skenario terbaik, seolah-olah semuanya berjalan dengan segera dan tidak pernah terjadi gangguan. Dalam kehidupan nyata, Anda mulai mengkodekan, kemudian telepon berdering, Anda terganggu selama 5 menit, menghabiskan 15 menit lagi di stackoverflow atau programmer .stackexchange untuk tenang dan fokus kembali, melakukan beberapa koding, mengalami perilaku tak terduga dari beberapa API, lakukan beberapa Google, menghabiskan 2 jam untuk menguji solusi yang mungkin, dll.

Dengan kata lain: "kasus terbaik" hanya terjadi dalam mimpi Anda.


1
Lihat komentar @Peter Broughton (5 jam sebelum jawaban Anda!).
ChrisF

Ya, Anda benar, ChrisF. Pasti ketinggalan yang itu.
user281377

+1. Ini pada dasarnya mengapa saya menjalankan aturan "buat perkiraan yang masuk akal, lalu gandakan". Itupun seringkali butuh waktu lebih lama. Salah satu dosen saya di uni biasa mengatakan "tiga kali lipat". Jadi saya kira saya baik-baik saja. :)
Bobby Tables

10

Setiap programmer, sesekali senang, memiliki hari yang sempurna. Anda bangun 5 menit sebelum alarm Anda berbunyi hebat. Sarapan dibuat dan di meja, bersama dengan kopi segar, sehingga Anda dapat mengambil sesuatu dan keluar dari pintu. Selama perjalanan Anda, Anda menekan setiap lampu hijau, dan lalu lintas tampaknya sangat ringan. Merenungkan hari di depan Anda, Anda dapat sepenuhnya memahami desain dan konsekuensi dari tugas di depan Anda, yang telah direncanakan dengan baik dengan persyaratan perusahaan.

Anda mulai bekerja dan Anda menemukan bahwa Anda tidak memiliki email penting, tidak ada voicemail menunggu, dan rekan kerja Anda keluar atau dalam rapat yang tidak harus Anda hadiri. Anda menjalankan editor Anda dan langsung berada di zona tersebut, Anda dapat merasakan struktur kode dan melihat struktur data dan algoritme Anda masuk ke tempatnya dalam keseluruhan yang indah dan kohesif. Pikiran mengalir melalui tangan Anda ke keyboard, memasukkan kode yang terbentuk sempurna yang elegan, dapat dipelihara, dan tanpa bug yang dapat ditemukan.

Pada siang hari Anda bekerja tanpa gangguan, kantor menjadi sunyi dan Anda begitu fokus sehingga Anda tidak pernah tergoda untuk menghabiskan waktu mengejar berita, blog, dll. Saat Anda menyusun dan menjalankan tes, Anda menemukan bahwa semuanya bekerja tanpa hambatan, tentu saja Anda tahu itu akan terjadi, dan pada akhirnya Anda berkomitmen tanpa konflik. Melirik jam pada jalan keluar Anda menyadari Anda memasukkan dalam 12 jam dan rasanya seperti sesi coding 20 menit singkat.

Hari itu, hari yang sempurna, adalah apa yang kita asumsikan akan kita miliki setiap kali kita harus memperkirakan sesuatu.


7

Jangan lupa tentang rapat, orang-orang mengganggu Anda, dll. Bug yang tidak terduga sulit diprediksi, tetapi seiring waktu Anda harus bisa mengetahui berapa banyak bug yang Anda temukan dalam jangka waktu tertentu. Ketika memperkirakan berapa lama sesuatu akan terjadi, Anda harus mempertimbangkan konteksnya. Yaitu "Dengan asumsi saya tidak mendapatkan gangguan atau mengungkap bug saya harus dapat melakukan sesuatu dalam jumlah waktu X"

Sebagai sedikit latihan untuk diri sendiri, pertimbangkan untuk melakukan hal berikut:

  • Di awal hari, tuliskan apa tujuan Anda dan perkiraan waktu untuk itu.
  • Pada setiap gangguan (rapat, rekan kerja berbicara, dll.), Catat perkiraan lama waktu
  • Setiap kali Anda menemukan bug baru, catat sebagai tugas yang tidak direncanakan bersama dengan kira-kira berapa lama untuk mengembangkannya.

Anda akan menemukan beberapa pola mulai muncul, dan dapat merencanakan sesuai untuk itu. Setiap kali Anda memberi tahu manajer Anda perkiraan waktu penyelesaian, anggap saja dengan asumsi di paragraf pertama. Anda mungkin akan terkejut seberapa akurat perkiraan Anda ketika Anda menghapus waktu yang dihabiskan untuk gangguan dan bug.

Ketika Anda bekerja ke daftar bug atau daftar fitur, Anda mungkin sudah melakukan poin pertama dan ketiga. Latihan kecil itu akan memberi tahu Anda ke mana semua waktu Anda pergi, dan Anda mungkin akan terkejut dengan jawabannya.


+1 Jika saya mencatat setiap gangguan yang saya terima, selain dari kebutuhan untuk memesan alat tulis lebih sering, saya akan kehilangan bagian yang cukup besar dari hari ke notasi.
Orbling

3

Anda mungkin ingin memperluas jangka waktu prediksi. Bisakah Anda menentukan apa yang bisa Anda lakukan dalam seminggu? Jika setiap tugas memakan waktu tiga kali lebih lama dari yang Anda pikirkan, sepertinya Anda cukup konsisten untuk dapat diprediksi. Anda hanya perlu menyesuaikan 3x;)


+1 Secara konsisten salah masih konsisten! Hasil.
Orbling

2

karena Anda mengabaikan fakta bahwa bug yang tidak terduga dapat terjadi.

Lakukan beberapa statistik pada rata-rata waktu yang Anda habiskan untuk bug, dan pertimbangkan waktu itu ketika Anda membuat rencana.


1

Karena Anda tidak merencanakan dengan benar. Aduh .

Saya bertaruh jika Anda memiliki total jumlah yang Anda lewati (bahkan di atas kertas), kemudian sesuaikan perkiraan Anda dengan% itu, Anda akan dapat merencanakan dengan benar.

FWIW, perangkat lunak terkenal sulit untuk diperkirakan. McConnell (dari Code Complete fame) bahkan memiliki buku di dalamnya.


1

Sesuatu yang sering saya temukan sedang terganggu oleh hal-hal acak yang tidak terkait dengan apa yang saya lakukan. Daftar todo dapat membantu hal itu; ketika Anda memikirkan sesuatu, tulis dan lakukan setelah Anda menyelesaikan apa yang ada di depan Anda.



1

Matriks Penting / Penting mungkin perlu dipertimbangkan untuk melihat ke mana perginya hari Anda. Apakah ini pada hal-hal yang mendesak tetapi tidak penting seperti pertemuan dan interupsi yang tidak siap? Apakah itu pada hal-hal penting dan penting yang tidak Anda ketahui di awal hari? Hanya latihan untuk mempertimbangkan kemana waktu Anda pergi.


Saya cenderung berpikir bahwa hal yang paling menarik itu penting atau mengapa mereka menarik? Hanya pemikiran saja.


1
Masalah saya dengan teknik itu adalah "dimensi ketiga" yang tak terlihat: bagaimana MENARIK sesuatu. Sayangnya, bagi saya, ketertarikan mengalahkan urgensi dan kepentingan setiap saat.
timday

0

Itu pertanyaan yang bagus dan satu yang terus saya renungkan. Saya cenderung berpikir begitu

  • sangat mudah untuk salah menilai jumlah fitur yang akan diambil oleh X.
  • Saya tidak pernah merencanakan bug atau perjalanan ke ketel.
  • baik Anda mendapatkan banyak dilakukan dengan kode kecil atau tidak dilakukan banyak akan dan tampaknya tidak ada di antara keduanya.
  • terkadang Anda kehilangan 'zona' Anda, terkadang hal-hal perlu dipikirkan.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.