Apa Perlu Disediakan Sebelum Perbualan Pertama Dengan Pembangun Perisian

Perbualan pertama dengan pembangun perisian berjalan paling baik apabila anda masuk dengan masalah sebenar, bukan pembentangan yang dilicinkan. Pembekal yang menyoal dengan baik boleh mengubah penerangan kasar dan jujur tentang apa yang menyakitkan hari ini menjadi skop tepat dan sebut harga adil; pembekal yang terkandas meneka senarai ciri yang dibayangkan biasanya menyebut harga dengan salah pada mana-mana arah — terlalu rendah, dan jurangnya muncul kemudian sebagai permintaan perubahan, atau terlalu tinggi, dilambakkan untuk menampung ketidakpastian.

Ini ialah senarai semak pra-pentauliahan praktikal: apa yang perlu dibawa, siapa yang perlu dilibatkan, dan apa yang pembangun sebenarnya perlukan daripada anda untuk menskop dan menyebut harga kerja itu dengan betul pada perbualan pertama, bukan yang ketiga. Ia mengandaikan anda sudah membuat keputusan bahawa sistem tersuai berbaloi untuk diterokai; jika anda masih memutuskan sama ada untuk membina langsung, lihat tanda-tanda perniagaan anda telah mengatasi helaian kerja dahulu. Setelah bersedia untuk mentauliahkan, berapa lama sistem tersuai sebenarnya mengambil masa dan siapa yang patut membinanya merangkumi soalan yang datang selepas ini.

Mengapa "kami mahu aplikasi" atau "kami mahu sistem" tidak cukup untuk sebut harga yang tepat

Pembangun tidak boleh menghargakan apa yang tidak dapat mereka bayangkan. "Kami mahu sistem untuk menguruskan pesanan" menerangkan kategori perisian, bukan projek — ia tidak menyatakan berapa banyak pesanan, siapa yang memasukkannya, apa yang berlaku apabila satu dibatalkan, atau sama ada hasilnya perlu bercakap dengan perisian perakaunan sedia ada anda. Dua perniagaan yang menyebut ayat yang sama boleh memerlukan binaan dan harga yang sangat berbeza.

Penyelesaiannya bukan belajar perbendaharaan kata teknikal sebelum pertemuan. Sebaliknya, datang dengan masalah sebenar dengan cukup butiran supaya orang yang tidak dikenali boleh mengikutinya, yang selebihnya panduan ini adalah senarai semak untuknya.

Mulakan dengan kesakitan, bukan senarai ciri

Sebelum memikirkan apa yang sistem baharu patut lakukan, namakan perkara khusus yang tidak kena hari ini. Bukan "kami perlukan pengurusan inventori yang lebih baik" tetapi "kami memasukkan semula kiraan stok yang sama ke dalam tiga helaian kerja setiap Isnin, dan ia biasanya salah menjelang Rabu." Versi kedua memberitahu pembangun dengan tepat apa yang perlu diperbaiki dan kira-kira sebesar mana pembaikan itu; versi pertama boleh bermaksud hampir apa-apa sahaja.

• Namakan satu tugas, bukan satu jabatan. "Jualan perlukan sistem" terlalu luas. "Wakil jualan menghantar pesanan melalui mesej teks kepada pejabat, yang ditaip ke dalam Excel secara manual" ialah brif.
• Nyatakan kekerapan ia berlaku dan berapa lama ia mengambil masa. Masalah yang mengambil sepuluh minit sekali seminggu ialah projek yang berbeza daripada yang mengambil dua jam setiap hari.
• Nyatakan apa yang berlaku apabila ia tersasar. Pesanan yang terlepas, pembayaran berganda, pelanggan yang tidak pernah diberitahu barangnya kehabisan stok — kos kesilapan semasa selalunya menjadi hujah perniagaan sebenar untuk projek itu.

Siapa yang benar-benar akan menggunakannya, dan apa setiap orang buat setiap hari

Sistem diskop mengikut orang yang akan menyentuhnya setiap hari, bukan pemilik yang mentauliahkannya. Sebelum pertemuan, tentukan:

• Siapa, mengikut peranan, bukan nama. Kakitangan kaunter, kakitangan gudang, seorang admin tunggal, pemilik yang menyemak laporan sekali seminggu — setiap peranan biasanya memerlukan paparan sistem yang sama secara berbeza.
• Berapa ramai dalam setiap peranan, secara kasar. Alat yang digunakan oleh dua orang boleh bertolak ansur dengan lebih geseran berbanding yang digunakan oleh dua puluh.
• Apa setiap peranan sebenarnya buat, langkah demi langkah, dengan alat semasa. Bukan apa yang anda harap mereka buat — apa yang mereka sebenarnya buat, termasuk jalan pintas yang tidak diakui secara terbuka.
• Siapa yang memutuskan jika sesuatu nampak salah. Orang yang pertama menyedari kesilapan selalunya bukan orang yang boleh membetulkannya, dan reka bentuk sistem yang baik mengambil kira jurang itu.

Ini penting kerana sistem yang dibina mengikut bagaimana pemilik membayangkan perniagaan berjalan selalunya ditolak secara senyap oleh kakitangan yang sebenarnya perlu menggunakannya setiap hari. Jika praktikal, bawa seorang yang akan benar-benar menggunakan sistem itu setiap hari ke perbualan pertama, atau sekurang-kurangnya sediakan jawapan mereka secara tidak langsung; pemilik dan pengguna harian sering menerangkan proses yang sama secara berbeza, dan pembangun mendapat manfaat mendengar kedua-dua versi sebelum menulis apa-apa.

Petakan proses semasa dengan tepat seperti ia berjalan sekarang, bukan bagaimana ia sepatutnya berjalan

Susuri proses semasa dari mula hingga akhir, mengikut urutan, termasuk bahagian yang janggal untuk diakui. Pembangun memerlukan versi sebenar, termasuk jalan pintas, kerana jalan pintas itu selalunya perkara tepat yang sistem baharu perlu gantikan atau serap.

• Dari mula hingga akhir, mengikut urutan. Apa perkara pertama yang berlaku, dan apa yang terakhir?
• Setiap serah tangan. Setiap kali kerja berpindah daripada satu orang, alat atau helaian kerja ke satu lagi ialah satu titik di mana sesuatu boleh hilang atau ditaip semula dengan kesilapan.
• Setiap jalan pintas. Nota pelekat, kumpulan WhatsApp berkongsi, helaian kerja yang tidak diketahui orang lain wujud — ini biasanya penting, dan sistem baharu yang mengabaikannya cenderung gagal secara senyap pada hari pelancaran.
• Apa yang "selesai" atau "betul" bermaksud sekarang. Jika tiada siapa boleh menyatakan bagaimana anda tahu pesanan dikendalikan dengan betul hari ini, itu sendiri maklumat yang berguna.

Ia membantu untuk benar-benar menuliskan ini sebagai senarai bernombor sebelum pertemuan, walaupun secara kasar. Pembangun yang membaca sepuluh ayat mudah mengikut urutan belajar lebih banyak daripada yang membaca satu perenggan yang dilicinkan.

Apa yang perlu disambungkan: alat, sistem dan data sedia ada

Sangat sedikit sistem tersuai wujud secara bersendirian. Senaraikan segala-galanya yang sistem baharu perlu baca daripada, tulis kepada, atau sekurang-kurangnya wujud bersama:

• Perisian perakaunan atau invois — adakah sistem baharu perlu mencipta atau membaca invois, atau sekadar membantu seseorang memasukkan data ke dalam alat perakaunan dengan lebih pantas?
• Platform titik jualan, e-dagang atau tempahan yang sudah digunakan.
• Helaian kerja yang menjadi "rekod rasmi" untuk sesuatu, walaupun secara tidak formal.
• Alat komunikasi yang perniagaan gunakan, seperti WhatsApp Business, di mana pesanan atau kelulusan berlaku sekarang.
• Akaun dan log masuk yang terlibat, dan siapa yang sekarang mengawalnya.

Anda tidak perlu tahu sama ada sambungan itu mungkin secara teknikal — itu soalan untuk pembangun jawab. Anda perlu tahu bahawa sambungan itu diperlukan, kerana sebut harga yang dibina tanpanya ialah sebut harga yang perlu disemak semula setelah jurang itu ditemui di tengah projek.

Bawa contoh sebenar, bukan penerangan

Dokumen sebenar lebih bernilai daripada penerangan teliti tentangnya. Bila mungkin, bawa benda sebenar daripada menerangkannya daripada ingatan.

Jika dokumen mengandungi butiran pelanggan atau kewangan sebenar, kosongkan nama dan nombor sebelum berkongsi; struktur dan medan jauh lebih penting berbanding nilai khusus.

Julat bajet kasar dan tarikh sasaran

Nyatakan julat, bukan angka tepat, dan nyatakan awal daripada menunggu untuk ditanya. Pembangun yang tahu anda memikirkan beribu rendah akan mencadangkan titik permulaan yang berbeza daripada yang mendengar berpuluh ribu, dan mengetahui jurang itu pada panggilan pertama menjimatkan cadangan yang terbuang untuk semua orang. Perkhidmatan Pembangunan Aplikasi & Sistem Gotka sendiri menyenaraikan harga permulaan indikatif RM8,000 untuk aplikasi web dan papan pemuka, RM12,000 untuk sistem perniagaan dan integrasi, dan RM15,000 untuk aplikasi mudah alih, setiap satu disahkan melalui sebut harga bertulis setelah skop difahami — berguna sebagai gambaran skala kasar walaupun sebelum anda memilih pembangun.

Tarikh sasaran penting atas sebab yang sama. "Sebelum musim sibuk kami dalam tiga bulan" menskop projek yang sangat berbeza daripada "bila-bila ia siap," dan pembangun perlu tahu yang mana anda maksudkan sebelum mencadangkan apa yang realistik. Tahan naluri untuk merendahkan angka itu bagi menguji kesan pada sebut harga; bajet yang dinyatakan dengan jujur membantu pembangun mencadangkan skop yang sesuai, sementara angka yang direndahkan untuk menguji mereka biasanya hanya menghasilkan cadangan yang perlu disemak semula setelah skop sebenar menjadi jelas.

Apa yang pembangun yang baik patut tanya anda, dan apa yang patut anda tanya mereka

Perbualan pertama berfungsi dua hala. Pembangun yang tidak bertanya tentang proses semasa, pengguna atau julat bajet anda sama ada sangat berpengalaman membaca di sebalik baris atau tidak menyoal cukup; walau apa pun, anda boleh menggalakkan perbualan itu sendiri dengan bahan dalam panduan ini, daripada menunggu untuk ditanya.

Soalan yang berbaloi ditanya balik, setelah mereka mendengar masalah anda:

• "Apa yang anda perlukan daripada saya untuk memberikan sebut harga yang tepat?" — ujian berguna sama ada mereka menskop dengan teliti atau meneka.
• "Apa bahagian paling berisiko atau paling tidak pasti daripada apa yang saya ceritakan?" — mendedahkan masalah sebelum ia menjadi permintaan perubahan.
• "Model harga apa yang akan digunakan untuk ini?" — lihat harga tetap atau kadar sejam untuk apa setiap jawapan bermaksud bagi risiko anda.

Setelah anda ada sebut harga bertulis di tangan, cara membandingkan dua sebut harga perisian tersuai bersebelahan merangkumi apa yang perlu disemak sebelum menandatangani, dan freelancer, pembangun dalaman atau syarikat pembangunan merangkumi siapa yang sepatutnya membinanya jika itu masih soalan terbuka.

Kesilapan biasa

• Memulakan dengan senarai ciri bukan masalah. Senarai ciri yang anda bayangkan diperlukan selalunya terlepas pembaikan sebenar dan menambah ciri yang tidak diminta sesiapa.
• Menerangkan proses "ideal" bukan yang sebenar. Jalan pintas yang anda malu untuk mengaku selalunya butiran paling berguna dalam bilik itu.
• Mengetepikan siapa yang benar-benar menggunakannya setiap hari. Sistem yang diskop mengikut pandangan pemilik selalunya ditolak oleh kakitangan yang menyentuhnya setiap hari.
• Terlupa satu alat yang sistem baharu perlu sambungkan, ditemui hanya di tengah projek.
• Menyembunyikan julat bajet untuk "lihat apa mereka cakap dahulu." Ia membuang satu pusingan menyebut harga daripada melindungi anda.
• Datang tanpa contoh sebenar — hanya penerangan. Sampel pesanan atau eksport helaian kerja menyatakan lebih banyak dalam dua minit berbanding sepuluh minit menerangkan.
• Berpura-pura ada jawapan daripada menyatakan "saya belum tahu."

Kedudukan Gotka Technologies

Perkhidmatan Pembangunan Aplikasi & Sistem Gotka merangkumi aplikasi mudah alih, aplikasi web dan sistem perniagaan, dengan harga permulaan indikatif RM8,000 untuk aplikasi web dan papan pemuka, RM12,000 untuk sistem perniagaan dan integrasi, dan RM15,000 untuk aplikasi mudah alih — setiap satu disahkan melalui sebut harga bertulis setelah proses, pengguna dan sambungan anda difahami. Masuk ke perbualan pertama itu dengan bahan yang panduan ini merangkumi (titik kesakitan sebenar, orang yang akan menggunakannya, apa yang perlu disambungkan, dan bajet serta tarikh kasar) adalah apa yang mengubah pertemuan pertama menjadi sebut harga tepat bukan tekaan.

Istilah utama dalam panduan ini

• Skop: penerangan bertulis tentang apa sebenarnya yang sistem akan lakukan, yang menjadi asas harga sebut harga.
• Penemuan: peringkat awal, kadangkala berbayar, di mana pembangun mengkaji proses anda secara terperinci sebelum menyebut harga atau membina.
• Rekod rasmi: helaian kerja, alat atau dokumen mana sahaja yang sekarang menyimpan versi "sebenar" maklumat, walaupun secara tidak formal.
• Integrasi: sambungan yang membolehkan sistem baharu membaca daripada atau menulis kepada alat sedia ada, seperti perisian perakaunan.
• Permintaan perubahan: ciri atau perubahan yang dibangkitkan selepas skop dipersetujui, biasanya dihargakan dan dijadualkan secara berasingan.
• Jalan pintas: pembaikan tidak formal, seperti helaian kerja berkongsi atau nota pelekat, yang orang gunakan kerana proses rasmi tidak merangkumi situasi sebenar.