Get best of the week

Kontrak pengembangan elektronik. Perhitungan proyek




Setiap bulan, puluhan aplikasi untuk pengembangan elektronik datang kepada kami. Dan setiap pelanggan potensial ingin mengetahui biaya penyelesaian masalahnya, terlepas dari seberapa baik ia memahaminya. Bisakah pengembang kontrak menyenangkan semua orang? Bagaimana menyingkirkan "harapan" di muka? Bagaimana cara mengevaluasi proyek-proyek yang memiliki peluang pengembangan? Ini artikel baru kami.

Proyek apa yang tidak boleh dipertimbangkan


Ketika kami pertama kali mulai, setiap aplikasi dalam surat sepertinya hadiah takdir. Kami duduk bersama seluruh tim kecil kami dan menemukan betapa kerennya kami melaksanakan proyek ini. Tampaknya perlu memberikan detail maksimal kepada setiap pelanggan potensial. Penting untuk memilih solusi teknis utama, memecah pekerjaan menjadi beberapa tahap, ke tugas-tugas individu, menggambar grafik Gantt, menghitung biaya produk dan menggambarkan semua ini sedetail mungkin dalam proposal komersial (KP). Kami menghabiskan setiap CP hingga beberapa hari, dan pelanggan terus mempertimbangkannya untuk selamanya. Seiring berjalannya waktu, muncul pemahaman bahwa Anda tidak dapat membuang waktu insinyur dan menyaring proyek tanpa masa depan


bahkan sebelum menyelam ke detail teknis. Pertama-tama, perlu untuk memahami keseriusan niat Pelanggan masa depan. Sayangnya, permintaan seperti "Saya melihat kemarin di Internet perangkat untuk 50.000 rubel, lakukan saya sama untuk 30.000 rubel" lebih umum daripada yang kita inginkan.

Apa yang perlu kita tanyakan untuk menilai peluang proyek untuk berhasil?


  1. Mengapa organisasi membutuhkan produk tertentu (tujuan penciptaan produk)? Kita perlu mengetahui formulasi tugas bisnis yang paling akurat, jadi kita menyaring pemimpi dengan "ide cemerlang" berikutnya dari keset kamar mandi otomatis, dengan bluetooth dan aplikasi seluler.
  2. Siapa pemrakarsa proyek (DM)? Kami mencari tahu siapa yang bertanggung jawab atas teknologi dan siapa yang mengalokasikan anggaran. Biasanya ini adalah orang yang berbeda, dan mereka membutuhkan pendekatan yang berbeda dalam hal penjualan.
  3. ( )?
  4. . : , , , .?
  5. ( , )?
    . , , , .
  6. ( )? , , , . « » =)
  7. ( .., )?
  8. ?

    • — :
      1. (, )?
      2. ?
      3. (), ? -? ?
    • — : . , , . « », , .
    • ? ? ? — .
  9. ? — :
    • (, )?
    • (, )?
    • ?
    • , ?
    • ( )?
  10. () ( )? «», - . , 9 .
  11. ? , . , , .
  12. (, , , )? « , ». , -.
  13. ? : , .
  14. ? – .
  15. ? (, , , , ). . ?
  16. ? ?
  17. (, , )?
  18. ? .


-




Jadi, klien dan proyek memenuhi semua persyaratan, kami memulai penilaian. Penilaian ini tidak akurat dan tidak layak. Jika kita belum memiliki TK, kita mendapatkan penilaian tidak layak dengan spread besar. Menulis TK - menerima penilaian yang tidak akurat. Tanpa TK, skor memiliki toleransi ± 400% atau lebih. Ini disebut kerucut ketidakpastian: Grafik tentang antarmuka, tetapi esensi pada proyek yang berbeda adalah sama. Semakin banyak kita tahu, semakin sedikit ketidakpastian. Jangan luangkan waktu dan tenaga untuk TK.




Pertemuan penilaian proyek kami memiliki nama tidak resmi "Vanga Club". Peserta membiasakan diri dengan materi tentang proyek terlebih dahulu. Pada jam yang ditentukan, Klub menerima: seorang pengusaha, seorang manajer proyek, seorang insinyur sirkuit terkemuka, seorang programmer terkemuka. Kadang-kadang spesialis tambahan dengan keahlian sempit diundang, serta perwakilan dari kontraktor. Begitu banyak orang diperlukan untuk tinjauan komprehensif proyek. Pedagang senang dengan keberuntungannya dan berusaha untuk memuaskan klien dengan menyederhanakan persyaratan. Manajer proyek harus menghidupkan proyek, ia akan bertanggung jawab atas waktu, biaya, dan jumlah pekerjaan. Keinginannya adalah untuk meletakkan cadangan, memperhitungkan risiko. Insinyur ingin melakukan yang lebih baik dari kemarin. Mereka dapat dengan mudah menolak opsi yang sederhana, tetapi "tidak menarik". Tanpa manajer proyek, Anda dapat mengambil pesanan yang diremehkan, karena seorang pengusaha sangat fasih berbicara.Tanpa pedagang, Anda dapat menghitung begitu banyak sehingga klien bahkan tidak menjawab surat itu.



Pertemuan dimulai dengan diskusi umum tentang masalah untuk membentuk pemahaman bersama oleh semua peserta. Kemudian, struktur kerja hierarkis ( WBS ) dibangun untuk proyek tersebut .
Untuk satu perangkat, bagian perangkat lunak dan perangkat keras dialokasikan. Untuk sistem, bagian yang berbeda ditambahkan seperti perangkat lunak uji, simulator, bagian server, dll. Bagian yang dihasilkan dibagi menjadi bagian yang lebih kecil, misalnya, cabang perangkat keras menjadi dua revisi dari PCB dan Desain. Tahap selanjutnya adalah memecah bagian-bagian menjadi tugas yang terpisah. Jika semuanya jelas dengan implementasi, tugas harus kecil. Tugas "Tulis firmware" pasti tidak cocok. Kami mempertimbangkan tugas-tugas spesifik normal dengan peringkat kecil, misalnya: "Driver MCU I2C", "Naikkan Proyek", "Skema E3".
Anda tidak boleh mengevaluasi kompleksitas tugas sebelumnya, karena kompleksitas dan hubungannya akan menjadi jelas hanya ketika semuanya ditulis di papan tulis.

Semua tugas diberikan kerja dalam hitungan jam. Metode ini merupakan penilaian ahli . Jam dapat mengambil nilai dari sejumlah kekuatan dua: 2, 4, 8, 16, 32, 64, 128 ... Tugas dengan penilaian 128 jam atau lebih muncul ketika pelaksanaannya tidak jelas. Ini berarti bahwa ada baiknya melakukan pekerjaan untuk mengklarifikasi persyaratan, memverifikasi penerapan teknologi, dan kadang-kadang bahkan hanya membubarkan dan menghisap google.
Menurut pengamatan saya, dimungkinkan untuk meningkatkan akurasi penilaian, pertama-tama, meminta pendapat pengembang yang kurang berpengalaman. Jadi mereka belajar untuk mengevaluasi tugas dengan lebih cepat sendiri. Jika seorang insinyur yang memiliki reputasi baik telah berbicara, semua orang cenderung setuju dengan pendapatnya. Dan ketika pekerjaan pada proyek dimulai, tugas-tugas yang kemungkinan besar akan diselesaikan bukan olehnya, tetapi oleh mereka yang tidak mengatakan apa-apa. Kami masih akan mendengar penilaian mereka, tetapi tidak pada saat yang tepat.
Ketika semua tugas dievaluasi, kami merangkum hasilnya dan menambahkan 30% ke perangkat lunak untuk debugging dan 30% lainnya untuk pengujian perangkat lunak. Angka-angka ini diambil dari statistik pada proyek yang diselesaikan.
Hasilnya, gambar berikut muncul di papan tulis:



Penilaian biasanya disertai dengan diskusi yang tajam tentang perinciannya, karena ada banyak pilihan untuk menyelesaikan masalah. Jadi tidak kurang dari satu jam. Mengingat waktu untuk mempersiapkan, bahkan penilaian awal proyek dapat memakan waktu 5-20 jam pengembang terkemuka.

Kita semua ingin membuat produk yang sukses, elektronik yang akan menguntungkan orang. Kami membahas bagaimana hasil penilaian (garis waktu, sumber daya) konsisten dengan tujuan proyek secara keseluruhan. Mungkin ada baiknya menawarkan pelanggan dengan cara lain. Misalnya, untuk memotong fungsionalitas untuk MVP, atau untuk mengambil perangkat keras yang lebih mahal demi pengembangan yang lebih murah. Berguna untuk secara kasar menghitung ekonomi keseluruhan proyek untuk tahapan selanjutnya: produksi, produksi, dukungan. Angka-angka ini menunjukkan bobot relatif sumber daya dan waktu untuk tahap-tahap proyek dan dapat secara signifikan mengubah persepsi mereka (baik kita maupun pelanggan).

Peringkat yang diterima dari Wang Club dimasukkan dalam Redmine. EasyWBS cocok untuk menambahkan tugas dengan cepat dalam bentuk visual:




Untuk menentukan waktu pengembangan, kami membangun tugas besi dengan rantai (air terjun). Kami mendapatkan Gantt ini: Untuk perangkat lunak, kami membagi intensitas tenaga kerja menjadi produktivitas dari jumlah orang yang dapat terlibat dalam proyek pada saat yang sama. Seperti yang Anda ketahui, apa yang dilakukan oleh satu programmer dalam sebulan, dua programmer lakukan dalam dua bulan. Jadi Anda tidak harus memperhitungkan semua sumber daya personel Anda saat menghitung. Juga, tidak di setiap pemrogram proyek dapat mulai bekerja dari awal. Kebetulan Anda perlu menunggu untuk besi, milik Anda atau dibeli. Penundaan yang sama dapat terjadi di persimpangan tahapan dan revisi besi. Untuk menginformasikan kepada pelanggan, tanggal yang diterima tidak dapat diambil. Kecuali dengan awalan "ramalan optimis." Lebih baik memberi margin kecil. Dia akan berguna.






Dalam modul Perhitungan, tarif untuk spesialis ditambahkan dan biaya untuk co-kontraktor, produksi, bahan, perangkat, dll ditambahkan. Penawaran komersial yang sangat baik untuk pelanggan.pdf yang kami buat langsung dari sini. Baca bagaimana kolega kami mengevaluasi proyek secara berbeda menggunakan contoh permintaan tunggal. Analitik kecil dari dua belas KP . Jadi, proyek diterima, dievaluasi. Tetap menandatangani kontrak - dan lanjutkan, menulis ulang tugas, mengubah solusi teknis, memperluas persyaratan, mengubah proyek di luar pengakuan!









Bagi kami tidak ada pertanyaan apakah akan mengevaluasi proyek atau tidak, karena kami melakukan proyek untuk klien, itu tidak akan berhasil untuk mendapatkan kontrak tanpa evaluasi. Tetapi dengan proyek internal di perusahaan, situasinya berbeda. Seringkali, proyek internal tidak dievaluasi. Dan sangat sia-sia. Konsekuensi dari pendekatan ini adalah meremehkan waktu dan sumber daya. Baik tim maupun manajemen tidak dapat mengevaluasi kemajuan proyek saat ini. Karenanya kesalahpahaman dan demoralisasi tim.

Dan sekarang - mari kita bahas di komentar pendekatan Anda untuk evaluasi proyek!

More articles:


All Articles