Lembaga ini mengajarkan algoritma, struktur data, OOP. Dalam kasus yang baik, mereka dapat berbicara tentang pola desain atau pemrograman multi-threaded. Tetapi saya tidak mendengar tentang cara mengevaluasi biaya tenaga kerja dengan benar.

Sementara itu, setiap programmer membutuhkan keterampilan ini setiap hari. Selalu ada lebih banyak pekerjaan daripada yang bisa dilakukan. Evaluasi membantu menetapkan prioritas dengan benar, dan mengabaikan beberapa tugas sekaligus. Belum lagi masalah rumah tangga seperti penganggaran dan perencanaan. Perkiraan yang salah, sebaliknya, menciptakan banyak masalah: situasi konflik yang terlalu rendah, pemrosesan dan lubang dalam anggaran, perkiraan yang berlebihan - membatalkan proyek atau mencari pemain lain.

Dalam keadilan, perlu dicatat bahwa kurang menghargai jauh lebih umum dalam pembangunan. Mengapa Seseorang berpikir bahwa programmer terlalu optimis . Saya akan menambahkan satu lagi alasan untuk ini: menjadi programmer yang baik dan menjadi penilai yang baik bukanlah hal yang sama. Untuk menjadi programmer yang baik, satu keinginan saja tidak cukup. Butuh pengetahuan dan latihan. Mengapa penilaiannya berbeda?

Dalam artikel ini saya akan berbicara tentang bagaimana sikap saya dalam menilai tugas telah berubah dan bagaimana proyek-proyek di perusahaan kami sedang dievaluasi. Dan saya akan mulai dengan bagaimana Anda tidak perlu mengevaluasi. Jika Anda sudah tahu bagaimana "tidak", langsung ke bagian kedua artikel .

Pola Anti Evaluasi

Sebagian besar evaluasi dalam proyek dilakukan pada awal siklus hidupnya. Dan ini tidak mengganggu kita sampai kita memahami bahwa perkiraan diperoleh lebih awal dari persyaratan yang ditentukan, dan, dengan demikian, lebih awal dari tugas itu sendiri dipelajari. Akibatnya, penilaian biasanya tidak dilakukan tepat waktu. Proses ini disebut dengan benar bukan penilaian, tetapi menebak atau prediksi, karena setiap tempat dalam persyaratan adalah permainan menebak. Seberapa besar ketidakpastian ini mempengaruhi hasil akhir penilaian dan kualitasnya?

Agak, tapi tidak menyenangkan

Misalkan Anda sedang mengembangkan sistem entri pesanan, tetapi Anda belum dapat mengembangkan persyaratan untuk memasukkan nomor telepon. Di antara ketidakpastian yang dapat memengaruhi evaluasi program, kami dapat segera menyoroti yang berikut:

Apakah klien memerlukan nomor telepon yang dimasukkan untuk diperiksa validitasnya?
Jika klien memerlukan sistem verifikasi nomor telepon, versi mana yang akan ia pilih - murah atau mahal?
Jika Anda menerapkan versi murah untuk memeriksa nomor telepon, apakah klien ingin beralih ke yang mahal nanti?
Apakah mungkin untuk menggunakan sistem yang sudah jadi untuk memeriksa nomor telepon atau, karena beberapa batasan desain, Anda perlu mengembangkan sendiri?
Bagaimana sistem verifikasi dirancang?
Berapa lama untuk memprogram sistem verifikasi nomor telepon?

Dan ini hanya beberapa pertanyaan dari daftar yang muncul di kepala seorang manajer proyek yang berpengalaman ... Seperti dapat dilihat bahkan dari contoh ini, perbedaan potensial dalam definisi, desain dan implementasi dari peluang yang sama dapat mengakumulasi dan meningkatkan waktu implementasi hingga ratusan kali atau lebih. Dan jika kita menggabungkannya dalam ratusan dan ribuan fungsi proyek besar, kita mendapatkan ketidakpastian yang sangat besar dalam penilaian proyek itu sendiri.

Contoh lain yang sangat baik dari "pembengkakan" tampaknya menjadi persyaratan dasar, baca di artikel " Bagaimana kabar dua minggu?! "

Kerucut Ketidakpastian

Pengembangan perangkat lunak - dan banyak proyek lainnya - terdiri dari ribuan solusi. Para peneliti menemukan bahwa perkiraan proyek pada berbagai tahap melekat pada tingkat ketidakpastian yang diproyeksikan. Kerucut ketidakpastian menunjukkan bahwa perkiraan menjadi lebih akurat ketika proyek berlangsung. Harap dicatat bahwa pada tahap konsep awal (di mana perkiraan sering dibuat dan kewajiban dibuat), kesalahannya bisa 400% (empat ratus persen, Karl!). Optimal untuk membuat komitmen setelah selesainya desain terperinci.

Manusia bulan-mitis

Masih ada eksekutif yang percaya bahwa jika fungsionalitasnya diperbaiki secara kaku, pengurangan waktu dapat dicapai kapan saja dengan menambahkan staf yang akan melakukan lebih banyak pekerjaan dalam waktu yang lebih singkat. Kesalahan dari alasan tersebut terletak pada unit pengukuran yang digunakan dalam penilaian dan perencanaan: man-month. Biaya benar-benar diukur sebagai produk dari jumlah karyawan dan jumlah bulan yang dihabiskan. Tetapi hasilnya tidak tercapai. Oleh karena itu, penggunaan man-bulan sebagai unit pengukuran volume pekerjaan adalah kesalahpahaman yang berbahaya. Semua peneliti sepakat bahwa mengurangi periode nominal meningkatkan jumlah total pekerjaan. Jika jangka waktu nominal untuk grup 7 orang adalah 12 bulan, maka peningkatan sederhana pada staf menjadi 12 orang tidak akan mengurangi periode menjadi 7 bulan.

Dalam kelompok besar, biaya koordinasi dan manajemen meningkat, dan jumlah jalur komunikasi bertambah. Jika semua bagian dari tugas harus dikoordinasikan secara terpisah di antara mereka sendiri, maka biaya komunikasi tumbuh secara kuadratik, dan "kekuatan" tim tumbuh secara linear. Tiga pekerja memerlukan komunikasi berpasangan tiga kali lebih banyak dibandingkan dua, empat untuk enam.

gambar

Tim proyek berusaha untuk mengatasi masalah // Ivan Aivazovsky, 1850

Jika 8 orang bisa menulis program dalam 10 bulan, bisakah 80 orang menulis program yang sama dalam satu bulan? Inefisiensi tenggat waktu pengetatan ekstrem menjadi sangat jelas dalam kasus-kasus ekstrem - seperti 1.600 orang yang perlu menulis sebuah program dalam satu hari. Baca lebih lanjut tentang ini di buku dengan nama yang sama oleh Frederick Brooks .

Pola Evaluasi

Jadi, dengan masalah semuanya jelas. Apa yang bisa dilakukan?

Dekomposisi

Daripada mengevaluasi tugas besar, lebih baik membaginya menjadi banyak tugas kecil, mengevaluasinya, dan mendapatkan nilai akhir sebagai jumlah dari nilai awal. Jadi, kami segera membunuh sebanyak empat burung dengan satu batu:

Kami lebih memahami ruang lingkup pekerjaan. Untuk menguraikan tugas, Anda harus membaca persyaratan. Tempat yang tidak bisa dijelaskan akan segera muncul. Risiko salah menafsirkan persyaratan berkurang.
Selama analisis analisis persyaratan yang lebih terperinci, proses pemikiran untuk mensistematisasikan pengetahuan secara otomatis dimulai. Ini mengurangi risiko melupakan beberapa bagian dari pekerjaan, seperti refactoring, otomatisasi pengujian, atau upaya ekstra untuk meletakkan dan menggunakan
Hasil dekomposisi dapat digunakan untuk manajemen proyek, asalkan untuk kedua proses satu alat digunakan (masalah ini dibahas secara lebih rinci nanti dalam teks).
Jika kita mengukur kesalahan rata-rata dari estimasi setiap masalah yang diperoleh selama dekomposisi dan membandingkan kesalahan ini dengan kesalahan total estimasi, ternyata total kesalahan kurang dari rata-rata. Dengan kata lain, penilaian semacam itu lebih akurat (lebih dekat dengan biaya tenaga kerja riil). Sepintas, pernyataan ini kontra-intuitif. Bagaimana penilaian akhir bisa lebih akurat jika kita membuat kesalahan dalam mengevaluasi setiap masalah yang terurai? Pertimbangkan sebuah contoh. Untuk membuat formulir baru, Anda perlu: a) menulis kode di backend, b) membuat tata letak dan menulis kode di frontend, c) tes dan lay out. Tugas A dievaluasi pada 5 jam, tugas B dan C masing-masing 3 jam. Total skor adalah 11 jam. Pada kenyataannya, backend dilakukan dalam 2 jam, formulir mengambil 4, dan pengujian dan memperbaiki bug mengambil 5. lain. Total beban kerja adalah 11 jam. Ideal untuk dinilai. Selain itu, kesalahan dalam mengevaluasi tugas A adalah 3 jam, tugas B adalah 1 jam, dan C adalah 2 jam. Kesalahan rata-rata adalah 3 jam. Faktanya adalah bahwa kesalahan dari mengecilkan dan melebih-lebihkan perkiraan membatalkan satu sama lain. 3 jam yang disimpan di backend dikompensasi untuk keterlambatan 1 dan 2 jam di front-end dan tahap pengujian. Persalinan yang sebenarnya adalah variabel acak yang tergantung pada banyak faktor. Jika Anda sakit, maka akan sulit bagi Anda untuk berkonsentrasi dan bukannya tiga jam mungkin butuh enam. Atau beberapa bug tak terduga akan muncul yang harus dicari dan diperbaiki sepanjang hari. Atau, sebaliknya, ternyata alih-alih menulis komponen Anda sendiri, Anda dapat menggunakan yang sudah ada, dll. Penyimpangan positif dan negatif akan membatalkan satu sama lain. Dengan demikian, total kesalahan akan berkurang.

Fitur dan Tugas

Inti dari dekomposisi yang kami miliki adalah Fitur. Fitur adalah unit pengiriman fungsionalitas yang dapat diproduksi secara terpisah dari yang lain. Kadang-kadang level ini disebut User Story, tetapi kami sampai pada kesimpulan bahwa User Story tidak selalu cocok untuk mengatur tugas, jadi kami memutuskan untuk menggunakan formulasi yang lebih umum.

Satu anggota bertanggung jawab untuk satu fitur. Seseorang dapat membantunya dengan implementasi, tetapi satu orang lolos pengujian. Tugas itu juga dikembalikan kepadanya untuk direvisi. Bergantung pada organisasi tim, ini dapat berupa pemimpin tim atau langsung pengembang.

Sayangnya, terkadang ada fitur besar. Butuh waktu yang sangat lama untuk bekerja sendiri pada volume seperti itu. Dan untuk waktu yang lama Anda harus menguji dan menerapkan proses penerimaan. Lalu kami mengubah jenis tugas ke Epic. Epik hanyalah fitur yang sangat tebal. Kami tidak memulai sesuatu lebih dari epik. Yaitu epos bisa jadi besar, besar atau raksasa. Bagaimanapun, epik dikirim dalam bagian (fitur) ke penerimaan.

Untuk mengevaluasi lebih akurat, fitur diuraikan menjadi beberapa subtugas (Tugas) terpisah. Misalnya, fitur dapat berupa pengembangan antarmuka CRUD baru. Struktur tugas dapat terlihat seperti ini: "menampilkan tabel dengan data", "kencangkan penyaringan dan pencarian", "kembangkan komponen baru", "tambahkan tabel baru ke dalam basis data". Struktur tugas biasanya sama sekali tidak menarik untuk bisnis, tetapi sangat penting bagi pengembang.

Evaluasi dalam kelompok, perencanaan poker

Programmer terlalu optimis tentang jumlah pekerjaan. Menurut berbagai sumber, undervaluasi paling sering bervariasi dalam kisaran 20-30%. Namun, dalam kelompok kesalahan berkurang. Ini karena analisis yang lebih baik karena sudut pandang yang berbeda dan mengevaluasi temperamen.
Praktik yang paling umum dengan popularitas Agile yang semakin meningkat adalah praktik “ perencanaan poker .” Namun, dua masalah terkait dengan penilaian grup:

Tekanan sosial
Biaya waktu

Tekanan sosial

Di hampir semua kelompok, pengalaman dan keefektifan pribadi para peserta akan bervariasi. Jika tim memiliki tim / teknologi yang kuat - pemimpin / pemimpin program, anggota lain mungkin merasa tidak nyaman dan dengan sengaja meremehkan nilai: “Yah, bagaimana bisa Vasya melakukannya, tetapi apakah saya lebih buruk? Saya bisa melakukannya juga! " Alasannya mungkin berbeda: keinginan untuk terlihat lebih baik daripada yang sebenarnya, kompetisi atau hanya konformisme. Hasilnya adalah satu: penilaian kelompok kehilangan semua kelebihannya dan menjadi individu. Timlid memberi tanda, dan sisanya hanya menyetujuinya.

Untuk waktu yang lama saya memberi tekanan pada tim untuk mendapatkan peringkat yang lebih konsisten dengan harapan saya. Ini selalu menyebabkan penurunan kualitas dan gangguan dalam hal. Akibatnya, saya mengubah sikap dan sekarang peringkat saya sering kali terbesar. Selama diskusi, saya menunjukkan potensi masalah yang muncul di pikiran: "di sini refactoring tidak akan sakit, di sini struktur basis data kami berubah, perlu untuk melakukan uji regresi."

Ada beberapa rekomendasi utama:

Sebagian besar peringkat diremehkan. Tidak dapat memilih di antara dua peringkat? Ambil satu yang lebih besar.
Tidak yakin dengan evaluasi - buang kartu "?" atau peringkat yang bagus. Mungkin hampir tidak pernah membawa.
Selalu membandingkan rencana dan fakta. Jika Anda tahu bahwa Anda tidak cocok dua kali, berikan perkiraan dua kali lebih tinggi dari yang Anda pikirkan. Mulai melebih-lebihkan? Lipat gandakan dalam pikiran Anda dengan satu setengah. Setelah beberapa kali pengulangan, kualitas nilai Anda akan meningkat secara signifikan.

Biaya waktu

Anda tahu ungkapan "Apakah Anda ingin bekerja?" Kumpulkan rapat! " Tidak hanya satu programmer mencoba untuk memprediksi masa depan alih-alih menulis kode. Sekarang seluruh kelompok melakukannya. Selain itu, membuat keputusan dalam suatu kelompok adalah proses yang jauh lebih lama daripada membuat keputusan individu. Dengan demikian, penilaian kelompok adalah proses yang sangat mahal. Perlu melihat biaya-biaya ini dari sisi lain. Pertama, dalam proses penilaian, kelompok dipaksa untuk mendiskusikan persyaratan. Ini artinya Anda harus membacanya. Sudah tidak buruk. Kedua, mari kita bandingkan biaya-biaya ini dengan biaya-biaya yang dikeluarkan perusahaan karena terlalu rendahnya perkiraan proyek.

Bertahun-tahun yang lalu, suatu hari di bulan November, saya mengubah pekerjaan saya menjadi perusahaan besar. Segera menjadi jelas bagi saya bahwa pekerjaan itu berjalan lancar. Setengah dari perusahaan bekerja untuk merilis produk sebelum akhir tahun. Tetapi setelah sekitar satu minggu, saya merasa bahwa pada akhir tahun mereka tidak akan punya waktu. Dengan setiap hari berikutnya, peluang keberhasilan perusahaan ini menjadi semakin ilusif ... Proyek ini benar-benar disampaikan pada bulan Desember, meskipun pada tahun berikutnya. Saya belajar banyak tentang ini nanti, karena di musim panas masalah dimulai dengan pembayaran upah kepada karyawan dan saya berhenti bersama dengan sekitar setengah dari staf. Anda bisa mengatakan "baik, tentu saja, manajer itu bodoh, Anda harus bermain aman." Mereka mengasuransikan diri mereka sendiri. Enam bulan tidak ada masalah dengan pembayaran upah. Menyimpan persediaan modal kerja selama setengah tahun bukanlah tugas yang mudah. Saya pikir jika penilaian lebih akurat, akan ada keputusan manajemen lainnya di tingkat manajemen puncak.

Jika kita menganggap investasi dalam penilaian sebagai investasi dalam penerapan keputusan manajemen yang baik, maka mereka berhenti tampak begitu mahal. Ukuran kelompok adalah masalah lain. Tentu saja, tidak perlu memaksa seluruh tim untuk mengevaluasi seluruh jumlah pekerjaan. Jauh lebih masuk akal untuk membagi tugas menjadi ~~modul~~ , ahem, layanan mikro dan memberikan otonomi kepada tim. Dan pada level yang lebih tinggi, gunakan estimasi yang diperoleh oleh masing-masing tim untuk menyusun rencana proyek. Yang dengan lancar membawa kita ke topik paragraf selanjutnya.

Tata Letak Ketergantungan, Gantt Charts

Jika programmer biasanya memberikan penilaian, maka menyusun rencana proyek adalah banyak manajer menengah. Ingat, saya menulis bahwa orang-orang ini dapat dibantu jika satu alat digunakan untuk dekomposisi dan manajemen proyek. Evaluasi dan waktu kalender bukan hal yang sama. Misalnya, untuk menampilkan tabel data sederhana, Anda perlu:

Tabel DB
Kode backend
Kode Frontend

Melakukan tugas dalam urutan ini paling mudah dari sudut pandang teknis. Namun, pada kenyataannya ada spesialisasi yang berbeda. Spesialis front-end mungkin dijadwalkan untuk bebas lebih awal. Alih-alih diam, lebih logis untuk mulai mengembangkan UI dengan mengganti permintaan server dengan data tiruan atau hardcoded. Kemudian pada saat API siap, tetap hanya untuk mengganti kode dengan panggilan ke metode nyata ... dalam teori. Dalam praktiknya, level paralelisme maksimum dapat dicapai sebagai berikut:

Pertama kami cepat-cepat menyombongkan diri untuk menyetujui spesifikasi API
Kemudian hardcode data di belakang atau di depan, tergantung siapa yang ada di tangan.
Pada saat yang sama, kami melakukan database, backend, dan front-end. Basis data dan backend sebagian memblokir satu sama lain, tetapi paling sering kompetensi ini digabungkan dalam satu orang dan pekerjaan sebenarnya berjalan secara berurutan: pertama database, lalu backend
Kami mengumpulkan semuanya dan menguji
Kami memperbaiki bug dan menguji lagi

Adalah penting bahwa langkah 1, 4, dan 5 dijalankan secepat mungkin untuk mengurangi jumlah kunci. Selain keterbatasan teknologi dan pembatasan pada ketersediaan spesialis dari kompetensi yang diperlukan, masih ada prioritas bisnis! Dan ini berarti bahwa setelah tiga minggu demonstrasi telah dijadwalkan untuk klien penting dan dia ingin meludahi bagian pertama dari rencana proyek Anda. Dia ingin melihat hasil akhir, yang akan tersedia tidak lebih awal dari dua bulan kemudian. Nah, maka Anda harus menyiapkan rencana terpisah untuk demonstrasi ini. Kami menambah rencana untuk memalu data database yang diperlukan, menyisipkan tautan baru untuk transisi ke UI, dll. Juga diharapkan bahwa pada akhirnya perlu untuk membuang persen 20% dari kode, dan tidak semua demonstrasi ini.

Pemotongan artistik dari rencana semacam itu bukanlah tugas yang mudah. Membangun ketergantungan sangat menyederhanakan proses. Sebelum melanjutkan ke modul laporan, Anda perlu membuat modul input data. Apakah ini logis? Tambahkan ketergantungan. Ulangi untuk semua tugas terkait. Percayalah, banyak ketergantungan akan mengejutkan Anda.

Dalam tugas mengotomatisasi proses bisnis, seseorang biasanya memperoleh beberapa "ular" panjang dari tugas-tugas terkait dengan beberapa node penguncian besar. Paling sering, rencana awal tidak efektif dalam hal pemanfaatan sumber daya dan / atau terlalu lama dalam hal kalender. Revisi penilaian biaya tenaga kerja akan terjadi lebih cepat - bukan pilihan. Penilaian, oleh karena itu, kemungkinan besar optimis. Kita harus kembali ke dekomposisi, mencari rantai yang terlalu panjang dan menambahkan "garpu" tambahan untuk meningkatkan derajat paralelisme. Dengan demikian, karena peningkatan total biaya tenaga kerja (lebih banyak orang bekerja secara bersamaan dalam satu proyek), periode kalender proyek berkurang. Ingat "bulan mitos manusia"? Kecil kemungkinan bahwa suatu rencana akan menyusut lebih dari 30%. Agar anggaran dan tenggat waktu disepakati, rencana tersebut dapat ditinjau beberapa kali. Ada beberapa trik untuk membuat proses lebih cepat dan lebih mudah.

Kunci tugas

Alasan pertama untuk pemblokiran - dependensi - telah kami pertimbangkan.Selain itu, mungkin ada persyaratan yang tidak dapat dipahami / tidak akurat. Diperlukan alat untuk memblokir tugas dan mengajukan pertanyaan. Dengan spesifikasi persyaratan, Anda dapat membuka kunci tugas dan menyesuaikan kelas. Omong-omong, proses ini hampir selalu berlangsung selama proyek, dan tidak sebelum itu.

Jalan kritis, risiko di depan

. , ( ), , , , . , , , , , , . , .

Singkatnya, jika Anda mengacaukan struktur database, Anda harus menulis ulang kembali, jangan menghitung beban, Anda mungkin harus mengubah teknologi sama sekali. Saya menulis secara rinci tentang risiko pekerjaan desain di artikel " Kode Biaya Efektif ". Semakin cepat risiko di jalur kritis terwujud, semakin baik. Bagaimanapun, masih ada waktu dan sesuatu dapat dilakukan. Bahkan lebih baik jika mereka tidak terwujud sama sekali, tetapi mari kita bersikap realistis.

Oleh karena itu, Anda harus mulai dengan tugas-tugas yang paling berlumpur, rumit dan tidak menyenangkan, menempatkannya dalam status "diblokir" dan mengklarifikasi, menilai kembali dan menghapus dependensi sedapat mungkin.

Kriteria penerimaan, kasus uji

Bahasa alami: Rusia, Inggris atau Cina - itu tidak masalah - itu bisa berlebihan dan tidak akurat. Kasus uji mengatasi keterbatasan ini. Ini juga merupakan alat komunikasi yang baik antara pengembang, pengguna bisnis dan departemen kualitas.

Manajemen proyek

Apakah Anda ingin membuat Tuhan tertawa? Ceritakan padanya tentang rencanamu. Bahkan jika sebuah keajaiban terjadi dan Anda mengumpulkan dan mengklarifikasi semua persyaratan sebelum mulai bekerja, Anda memiliki cukup banyak orang yang kompeten, rencana tersebut memungkinkan Anda untuk melakukan sebagian besar pekerjaan secara paralel, Anda masih tidak kebal dari penyakit karyawan, kesalahan dalam mengevaluasi dan mematerialisasikan risiko lain. Karena itu, perlu memperbarui rencana secara berkala dan membandingkannya dengan fakta. Dan untuk ini, akuntansi waktu kerja adalah penting.

Pelacakan waktu alias pelacakan waktu

Waktu dan kehadiran telah lama menjadi standar de facto di industri. Sangat diinginkan untuk diproduksi dalam alat yang sama dengan penilaian. Ini memungkinkan Anda untuk melacak penyimpangan waktu aktual yang dihabiskan dari perkiraan. Baik jika alat ini juga digunakan oleh manajer proyek. Maka semua keterlambatan jalur kritis akan segera terlihat. Varian dengan alat yang berbeda juga mungkin, tetapi akan membutuhkan biaya tenaga kerja yang jauh lebih besar untuk melayani proses, yang berarti bahwa akan ada godaan untuk bermain-main. Kita sudah tahu bagaimana ini berakhir. Kami menggunakan YouTrack . Segala sesuatu yang saya tulis dalam artikel saat ini tersedia di luar kotak, meskipun memerlukan sedikit penyesuaian.

Kesimpulan

Evaluasi itu sulit
Dekomposisi memungkinkan Anda menemukan celah dalam persyaratan dan meningkatkan kualitas penilaian
Skor grup lebih akurat daripada skor individual, gunakan poker
Blocker, test case dan kriteria penerimaan formal meningkatkan komunikasi, yang pada gilirannya meningkatkan peluang keberhasilan proyek
Anda harus mulai dengan tugas-tugas paling berisiko di jalur kritis proyek
Evaluasi bukanlah tindakan satu kali, tetapi suatu proses yang tidak dapat dipisahkan dari manajemen proyek
Tanpa memperhitungkan waktu kerja, tidak mungkin untuk tetap memperbarui status proyek dan menyesuaikan perkiraan Anda

Ingin tahu lebih banyak tentang evaluasi proyek?

Baca buku Steve McConnell " Berapa biaya proyek perangkat lunak " dan artikel lain tentang hal ini di Habré:

Tentang Evaluasi dan Manajemen Pengembangan Produk Perangkat Lunak