it-swarm-id.com

Membuat non-programmer memahami proses pengembangan

Ketika memulai sebuah proyek untuk sebuah perusahaan yang bukan terutama perusahaan pemrograman, salah satu harapannya adalah bahwa ada produk jadi pada akhirnya bebas dari semua bug dan melakukan semua yang dibutuhkan segera. Namun, itu jarang terjadi.

Apa sajakah cara untuk mengelola harapan dan menjelaskan kepada non-programmer bagaimana pengembangan perangkat lunak berbeda dari jenis pengembangan produk lainnya?

66
user8

Hampir semua orang dengan komputer telah menemukan konsep "bug" akhir-akhir ini, jadi Anda bisa memulainya. "Apa cara paling menjengkelkan dari aplikasi yang pernah gagal padamu? Lipat gandakan dengan sepuluh, dan kamu akan memiliki pengalaman pengguna kami jika kami tidak mencurahkan cukup sumber daya untuk pengujian dan pemeliharaan."

Dan jangan meremehkan nilai membangun hubungan kerja yang baik dengan non-programmer. Jika Anda dapat memastikan bahwa penilaian Anda dapat dipercaya, mereka akan menganggap Anda serius ketika Anda membunyikan alarm bahwa X akan gagal secara spektakuler jika Anda tidak melakukannya, bahkan jika mereka tidak sepenuhnya memahami alasan Anda.

34
BlairHippo

Salah satu pendekatan yang saya temukan sukses adalah ini:

Kita semua tahu bahwa komputer hanya melakukan dan melakukan apa yang diperintahkan.

Pemrograman adalah cara kita memberi tahu komputer sekarang apa yang harus kita lakukan nanti .

Ini berarti bahwa perilaku Anda berperilaku sekarang disebabkan oleh niat gabungan dari semua orang yang menulis salah satu kode yang berjalan pada mesin Anda. Ketika Anda mempertimbangkan kompleksitas sistem operasi, driver, lingkungan pemrograman, perpustakaan dan sebagainya, mudah untuk melihat bahwa di sebagian besar sistem harus ada lebih dari 20k orang yang terlibat, dan mungkin ada lebih dari 100k.

Kode yang ditulis oleh setiap orang mencerminkan pemahaman, motivasi, niat, dan kemampuan mereka sendiri. Mengingat bahwa operasi tanpa cacat dari sistem mensyaratkan bahwa semua dari kode yang ditulis oleh 20k orang ini berinteraksi tanpa kesalahan - bahwa semua dari kode harus menyetujui makna dan interpretasi dari diperlukan perilaku, fakta yang mengejutkan bukan bahwa kita memiliki bug, tetapi kita memiliki sedikit dari mereka.

28
Bevan

IMO, saya telah menemukan bahwa transparansi yang ditawarkan oleh proses gesit (mis. Scrum, Crystal, dll.) Berjalan jauh untuk menunjukkan bagaimana pembangunan bekerja pada pemangku kepentingan rata-rata.

12
Brandon

Penjelasan dengan metafora adalah abstraksi yang bocor, tetapi di sini ada beberapa ide yang sering bekerja untuk saya:

Perhatikan bahwa tidak satu pun dari penjelasan ini yang bisa dimaafkan.

Pikirkan program komputer sebagai mesin, di mana setiap variabel adalah bagian yang bergerak. Itu bahkan membuat program sepele mesin yang terdiri dari ratusan bagian yang bergerak.

Ketika itu gagal, saya kembali pada kenyataan bahwa meskipun secara matematis dimungkinkan untuk membuktikan bahwa suatu program tidak memiliki kesalahan, dibutuhkan banyak waktu dan tidak akan sepadan dengan usaha.

Akhirnya, saya bertanya apakah Intel dan Microsoft tidak dapat menghindari bug, bagaimana mereka mengharapkan kami?

3
KevDog

Cara tradisional untuk menyatakannya adalah Segitiga Manajemen Proyek: tiga kriteria ruang, biaya, dan jadwal yang bersaing; biasanya dinyatakan sebagai "murah, cepat, bagus - pilih dua".

Pada akhir dari proses desain, pengembangan dan penyebaran, harapan bahwa suatu produk relatif bebas dari cacat desain dan beroperasi dengan fungsi yang ditentukan sangat masuk akal. Harapan yang sama benar-benar tidak masuk akal sehubungan dengan proyek, proses, atau profesi.

Apa yang profesional berdasarkan ilmu, keras atau lunak, tidak melalui proses eksplorasi, membentuk konseptualisasi yang tidak akurat dan tidak tepat, mengikuti taktik yang kurang optimal (atau hanya salah), menemukan apa yang berhasil melalui coba-coba, dan mengulangi proses berulang-ulang sampai sumber daya habis atau tingkat kinerja yang memadai tercapai?

Tidak ada proses yang bebas dari kesalahan, meskipun secara asimptotik dapat mendekati tingkat kualitas yang lebih tinggi.

Itu berlaku untuk profesi medis di mana taktik sering kali melibatkan dugaan dan protokol, dan sebagian besar aktivitas pada dasarnya adalah debugging mesin yang kebanyakan basah. Memang benar untuk teknik sipil dan arsitektur di mana aplikasi bahan rekayasa baru harus divalidasi di lapangan dan dapat gagal secara tiba-tiba setelah bertahun-tahun pelayanan meskipun kepatuhan ketat terhadap standar. Memang benar dalam bidang otomotif di mana usia dan perubahan dalam kondisi operasi biasanya memengaruhi kinerja hingga titik kegagalan, bukan karena kesalahan teknik atau layanan perbaikan yang diterapkan. Pengembangan perangkat lunak tidak pada dasarnya berbeda dari profesi-profesi ini dalam hal-hal seperti itu, hanya saja sebagian besar dari fokusnya terlibat dalam pembuatan novel, mesin-mesin yang bertujuan.

2
jerseyboy

Saya telah menjawab pertanyaan serupa lebih terinci , tetapi intinya adalah, "Pemrograman seperti membangun pabrik atau jalur perakitan."

2
Huperniketes

Anda dapat membandingkannya dengan sesuatu yang dapat mereka lihat dan jika mungkin, gunakan setiap hari.

Misalnya, mobil. Mobil memulai perangkat yang jauh lebih halus dan dapat diandalkan daripada yang kita miliki saat ini. Sementara mobil telah dibuat selama lebih dari 100 tahun, tetapi perangkat lunak mungkin sekitar setengahnya. Mobil tersedia dengan kustomisasi yang signifikan, beberapa termasuk dalam harga (seperti pilihan warna), yang lain seperti ukuran mesin, tipe transmisi, roda/ban, trim level adalah driver biaya yang signifikan.

Ada banyak fitur, kualitas, dan driver biaya untuk mobil, dan untuk perangkat lunak. Kemudian Anda dapat mendiskusikan bagaimana teknologi perangkat lunak, ketersediaan keahlian, bahkan mungkin di mana ia dibangun akan membuat perbedaan besar. Siklus pengembangan yang tepat (misalnya, model tahunan dengan perubahan kecil, perubahan bodi/engine/platform setiap tiga tahun) didorong oleh kombinasi kebutuhan pelanggan dan proses desain yang kompleks. Beberapa produk mulai kecil dan tampak gemuk (pikirkan Honda Accord), tetapi ditingkatkan setiap tahun sampai mereka berperingkat teratas.

Mobil memiliki penarikan (seringkali jauh lebih mahal daripada peningkatan perangkat lunak) dan peningkatan tambahan dalam bentuk menjalankan perubahan pada daftar komponennya (berpikir perbaikan bug), dan sering kali mereka membutuhkan dukungan jangka panjang (pikirkan kompatibilitas ke belakang/ke depan). Sebagian besar biaya mobil Anda datang setelah Anda membawanya pulang. Sebagian besar biaya perangkat lunak muncul setelah rilis produk awal saat Anda memperbarui dan meningkatkan pelanggan.

Dalam beberapa kasus, Anda dapat merujuk produk terkenal yang menyertakan perangkat lunak atau produk perangkat lunak lainnya. Misalnya, ponsel memiliki siklus rilis dan pembaruan serta metode penambahan fungsionalitas setelah penjualan awal untuk menghasilkan lebih banyak pendapatan. Telepon adalah ilustrasi yang bagus tentang kompatibilitas maju/mundur. Terlalu banyak, dan orang tidak akan membuang yang lama untuk membeli yang baru. Terlalu sedikit, dan pelanggan putus asa untuk memiliki telepon yang tidak akan mereka benci sebelum kontraknya habis.

Produk seperti Windows, Microsoft Office, browser web, dan halaman web adalah semua perangkat lunak yang dapat digunakan dalam diskusi. Mereka telah diperbarui pada siklus tahunan atau tiga tahun, tetapi mungkin memiliki pembaruan otomatis lebih sering. Mereka memiliki bug dan lubang keamanan yang memengaruhi pelanggan hingga derajat yang bervariasi, tetapi merupakan bagian dari lanskap meskipun kami telah berupaya sebaik mungkin. Pelanggan dapat memperoleh perbaikan secara gratis, tetapi umumnya membayar untuk peningkatan, seringkali sebagai satu bundel, kadang-kadang sebagai modul individual atau melalui kunci lisensi.

Para pemimpin industri seperti Microsoft, Apple, Google, dan Amazon semuanya memberikan pelanggan yang relatif murah kepada pengguna. Tetapi mereka memiliki biaya besar yang memungkinkan produk-produk itu. Pengalaman mereka menunjukkan bahwa perangkat lunak itu mahal, tetapi berharga dan menguntungkan. Mereka sering berkompromi antara kualitas, memiliki semua fitur yang mereka inginkan, dan masuk ke pasar ketika waktunya tepat. Tidak setiap produk yang mereka hasilkan adalah sukses, dan mereka terkadang mengubah anjing menjadi pemenang dengan mengganti nama, meningkatkan pemasaran dan penjualan, atau memotong kerugian mereka dan menggunakan apa yang mereka pelajari dalam produk selanjutnya.

0
DeveloperDon

Jika Anda terbiasa dengan pengembangan perangkat lunak hi-rel, seperti untuk kontrol reaktor nuklir, komunikasi luar angkasa, atau perangkat implan medis (dll.), Anda dapat menjelaskan bagaimana struktur biaya dan waktu pengiriman untuk tingkat manajemen priject dan QA mungkin besarnya lebih besar dari apa yang bisa dilakukan bisnis pada proyek perangkat lunak mereka.

0
hotpaw2

Mungkin mencoba menuntun mereka, satu-satu atau dalam kelompok-kelompok kecil idealnya, menggunakan kasing perangkat lunak yang harus Anda kembangkan. Ketika mereka menggambarkan kasus penggunaan, identifikasi poin dalam kasus di mana hal-hal yang berbeda dapat terjadi (kasus yang tidak terduga tetapi tidak masuk akal). Mulailah menghitungnya, meminta klarifikasi, dan mengilustrasikan semua keputusan dan arahan yang perlu dibuat atau diselesaikan, dan trade-off yang dilakukan dalam melakukannya. Terus sampai mereka bingung dan tidak bisa memberi Anda jawaban. Buat mereka mengerti bahwa, apa yang Anda lakukan sekarang dengan mereka, adalah persis apa yang Anda lakukan sepanjang hari, mungkin sendiri, mungkin dengan arah yang kurang jelas, baik memutuskan kursus dan menulis kode, untuk ratusan atau ribuan menggunakan kasus-kasus yang mungkin atau mungkin tidak ditata oleh siapa pun. Dan ketika ada kasus yang Anda tidak memikirkan diri sendiri, Anda tidak dapat menjamin apa yang akan dilakukan program. Mungkin itu hal yang "benar", mungkin perlu diperhatikan. Dan itulah bugnya. Dan itu sebabnya menulis perangkat lunak membutuhkan waktu. Semakin sedikit waktu yang Anda miliki, semakin sedikit kasus yang Anda punya kesempatan untuk mempertimbangkan dan mengakomodasi, dan semakin besar kemungkinan program tidak akan melakukan hal yang "benar" dalam keadaan yang tidak diketahui.

0
huntmaster

Biaya dan Waktu.

Wakt

Tetapkan harapan bahwa Anda akan memberikan jumlah waktu X dalam Y. Tidak akan ada yang lebih, tidak kurang. Lalu beri tahu mereka apa versi berikutnya akan memiliki dalam waktu apa. Pada awalnya mereka mungkin akan terkejut untuk percaya bahwa membangun X membutuhkan jumlah waktu Y - ini adalah di mana Anda menjelaskan waktu yang diperlukan dan kompleksitas membangun perangkat lunak. Jika mereka tidak terkejut, baik Anda memperkirakan waktu yang sangat sedikit atau mereka tahu lebih baik daripada yang Anda pikirkan tentang membangun perangkat lunak.

Biaya

Ini dari buku Code Compete karya Steve McConnel (mengutip dari memori, jadi maafkan saya jika saya tidak bisa menyampaikannya dengan efek yang sama) - Sangat mudah bagi pelanggan untuk meminta fitur baru. Sebagai manajer produk, Anda tidak boleh mengatakan apa yang diminta pelanggan. Anda harus memperkirakan berapa banyak usaha dan biaya yang diperlukan untuk membangun fitur baru itu. Mereka perlahan-lahan akan mengerti bahwa fitur baru tidak benar-benar sepadan dengan uang/waktu atau mungkin mereka bahkan tidak memerlukannya. Saya tidak menyarankan agar Anda menggunakan senjata ini untuk menakut-nakuti mereka, tetapi gunakan dengan jujur ​​dan itu bisa membantu dalam mengarahkan poin.

0
Sundeep