Saya bagian dari Grup Persetujuan Perangkat Lunak untuk perusahaan multi-nasional dan saya benar-benar akan menggemakan semua yang dikatakan Adam di atas.
Saya juga akan membuat poin-poin berikut, pertama selalu membayar semua "pajak pembangunan" Anda. Ini berarti memastikan bahwa aplikasi Anda berfungsi dengan baik di berbagai lingkungan yang mungkin tidak pernah Anda gunakan, tetapi kemungkinan besar akan menjadi pemecah kesepakatan untuk perusahaan besar, ini adalah hal-hal seperti memastikan bahwa aplikasi Anda bekerja dengan baik dengan roaming profil pengguna dan folder pengguna yang dialihkan (selalu menggunakan API Windows untuk menemukan folder pengguna dan profil, jangan pernah menganggap mereka di lokasi standar, atau bahkan pada drive lokal), pastikan itu berfungsi dengan baik di server Remote Desktop (di mana mungkin ada 100 salinan aplikasi Anda berjalan sekaligus, beberapa menggunakan koneksi sangat lambat), pada laptop dengan koneksi jaringan lambat atau baterai rendah dan sebagainya. Sebagai contoh, kami baru-baru ini menolak versi baru lebih dari satu perangkat lunak dari perusahaan yang sangat besar (dimulai dengan "A" dan terkenal dengan grafis) karena aplikasi mereka tiba-tiba tidak ada.
Bahkan untuk perangkat lunak sumber bebas / terbuka, pengguna akhir sering kali harus mengirimkan semacam formulir permintaan agar perangkat lunak diverifikasi dan disetujui.
Dari nada komentar Anda, sepertinya Anda pikir proses persetujuannya ada hubungannya dengan biaya? Dari sudut pandang kami, biaya per unit aplikasi bukanlah sesuatu yang akan kami pertimbangkan sama sekali dalam proses persetujuan. Pembenaran keuangan untuk aplikasi akan berhasil, persetujuan perangkat lunak semuanya dilakukan dari sudut teknis dan kemampuan dukungan. Perangkat lunak Gratis dan Sumber Terbuka umumnya lebih sulit melewati proses kami daripada aplikasi komersial yang dipatenkan. Seringkali ini hanya karena kurangnya akuntabilitas. Kepada siapa Anda pergi ketika ada masalah dengan aplikasi dan Anda memerlukan dukungan, apa SLA mereka? Siapa yang Anda tanyakan ketika Anda perlu mencari tahu apakah aplikasi akan bekerja dengan versi baru OtherApp vX, apakah mereka benar-benar memberi Anda jawaban aktual bahwa orang-orang benar-benar bekerja ke arah, atau apakah ini samar-samar "
Setelah proses diikuti dan perangkat lunak diinstal, peningkatan dapat menyulitkan - banyak organisasi cenderung tetap menggunakan versi perangkat lunak yang lebih lama (Windows XP, Office 2003, dll.) Karena takut akan masalah yang tidak diketahui.
Pembaruan perangkat lunak harus melalui proses yang sama dengan perangkat lunak yang sama sekali baru. Satu-satunya keuntungan yang mereka miliki adalah bahwa kita sudah tahu jawaban atas beberapa pertanyaan karena kita sudah mendukung perangkat lunak (ini mungkin bukan positif untuk perangkat lunak, tim pendukung telah memveto upgrade berdasarkan pengalaman dengan perusahaan).
Apakah Anda lebih suka perangkat lunak MSI atau xcopy-enabled?
Salah satu dari metode penyebaran itu bisa bagus, asalkan sudah dikemas dengan baik. Kalau tidak, kami kemungkinan besar akan mencabut pemasang Anda dan mengemas kembali perangkat lunak untuk penerapannya sendiri.
- Apa pun penginstal yang Anda gunakan, Anda harus memastikan bahwa Anda menghargai semua mode instalasinya yang diam dan tidak dijaga. Jika aplikasi Anda memerlukan pemasangan manual, yang merupakan pemecah kesepakatan instan, tidak ada cara praktis untuk melakukan itu di seluruh mesin di 5 benua yang mendapatkan semua dukungan non-perangkat keras dari kantor pusat.
- Diberi pilihan, saya lebih suka menginstal MSI yang dilakukan dengan baik untuk menginstal xcopy yang dilakukan dengan baik. Masalah dengan sebagian besar perangkat lunak yang mampu-Xcopy adalah ketika mereka mencoba untuk mengatur dan mendaftarkan diri pada saat pertama kali dijalankan. Saya sangat jarang menemukan aplikasi yang melakukan ini dengan benar dan tidak menimbulkan masalah di lingkungan pengguna / hotdesk roaming. Pemasang MSI (jika Anda tetap menggunakan API standar) tidak dapat melakukan kesalahan yang terlalu jauh.
- Pastikan instalasi diam Anda memberikan kemampuan untuk membuat semua perubahan konfigurasi yang dapat dilakukan dalam instalasi manual. Jika Anda menggunakan MSI dan tetap menggunakan API maka ini tidak masalah, kami dapat membuat transformasi MST dan melakukan semua ini tanpa masalah. Jika Anda menggunakan penginstal pihak ketiga yang berbeda, pastikan itu memungkinkan sesuatu seperti file "jawaban" atau file INI atau serupa. Uji pemasangan diam dan pastikan semua opsi berfungsi, saya telah menemukan produk yang dengan gembira mengumumkan opsi pemasangan diam mereka, tetapi mereka tidak pernah benar-benar menguji apakah semua opsi berfungsi.
- Lebih disukai memberi kami opsi tambahan dalam pemasangan diam yang memungkinkan kami mengatur banyak pengaturan yang biasanya diubah pengguna di panel Opsi. Ini bisa dengan beralih pada setup.exe, bisa dengan memiliki file INI yang didokumentasikan untuk pengaturan, dengan mendokumentasikan perubahan registri yang diperlukan, atau semua hal di atas. Namun demikian, kami ingin memastikan bahwa pengguna kami dapat bangkit dan menjalankan dengan perangkat lunak tanpa harus melakukan konfigurasi sendiri, yang penting di sini adalah lokasi default untuk file, nama server default, pengaturan proxy (jika aplikasi Anda berjalan melalui jaringan), dll.
Jika perangkat lunak memerlukan kerangka kerja (Java, .NET) apakah itu lebih atau kurang cenderung bermasalah?
Ini pasti lebih bermasalah. Versi dalam sebagian besar kerangka kerja dan kompatibilitas mundur / maju sangat mengerikan. Dengan Java pada khususnya banyak aplikasi (dan situs web) memerlukan versi utama dan minor Java yang diinstal dan tidak akan berfungsi dengan yang lain. Jika Anda perlu meletakkan tiga aplikasi berbeda di mesin yang semuanya membutuhkan versi Java yang berbeda, dan mereka tidak senang dengan cara-cara standar menyelubungi satu versi Java dengan yang lain, maka akan ada masalah. Net memiliki masalah sendiri dengan versi, tetapi dengan senang hati akan membiarkan Anda menginstal semua versi utama dari kerangka kerja pada saat yang sama.
Jika perangkat lunak mendukung pembaruan otomatis, apakah secara umum Anda mengizinkannya?
Tidak pernah. Ada terlalu banyak sakit kepala versi dan inter-operabilitas untuk memungkinkan aplikasi memperbarui sendiri tanpa peringatan. Pembaruan aplikasi membutuhkan pengujian dan perencanaan. Selain itu, pengguna dengan hak pengguna normal tidak dapat menerapkan pembaruan. Jika Anda menggunakan metode penyebaran yang memungkinkan penambalan (mis. Gunakan MSI dengan tambalan MSP) maka ini dapat membuat hal-hal seperti penambalan keamanan untuk aplikasi jauh lebih sedikit dari sakit kepala, dan kami dapat mengelola sendiri pemutakhiran otomatis menggunakan alat penyebaran kami (WSUS dan SMS ). Juga tim keamanan kami sangat curiga terhadap aplikasi apa pun yang "berbicara kembali ke pangkalan", mereka ingin tahu persis apa info yang dikirim dan mengapa perlu mengirim apa pun ke server yang tidak dikenal melalui internet.
Berapa lama biasanya?
Beberapa aplikasi sederhana, dan peningkatan versi dapat diputuskan selama diperlukan 6 orang untuk mengklik tombol voting "Setuju" di Outlook. Yang lebih kompleks atau kontroversial mungkin menunggu pertemuan kelompok kami setiap dua minggu. Beberapa aplikasi mungkin dibicarakan di lebih dari satu pertemuan ini karena tim mengambil pertanyaan tentang aplikasi yang jauh dan penelitian / pengujian.
Apa jenis model lisensi yang Anda sukai (dapat ditransfer, per kursi, per-CPU, di seluruh situs)?
Sangat tergantung pada bagaimana aplikasi akan digunakan, dan oleh berapa banyak orang. Yang paling penting adalah bahwa lisensi Anda didefinisikan dengan jelas. Kami harus mengirim karyawan kami ke kursus (meskipun gratis) untuk memahami lisensi Microsoft. Kami tidak akan repot melakukan itu untuk ISV.
Pertimbangkan kebutuhan pemasangan otomatis kami yang senyap dalam hal perizinan. Jika lisensi Anda memerlukan aktivasi, kami tidak ingin harus menelepon / mengirim email kepada Anda setiap kali kami menginstal ulang aplikasi pada PC. Jika setiap salinan aplikasi memerlukan kunci lisensi berbeda yang diketik secara terpisah, maka kami tidak dapat menerapkannya secara otomatis, sedangkan jika kami dapat membeli kunci massal (2, 10, 50, 500, dll.) Yang dapat disimpan dalam instalasi diam, maka kami senang. Lebih baik lagi jika kami dapat menghubungi Anda setahun kemudian dan bernegosiasi untuk memperluas jumlah lisensi kami tanpa harus mengubah kunci yang diketikkan ke dalam perangkat lunak.
Apa lagi yang bisa dilakukan ISV untuk meningkatkan peluang mereka agar perangkat lunak mereka disetujui?
Kami juga akan melihat hal-hal yang tidak sepenuhnya terkait dengan bagaimana aplikasi Anda saat ini. Ingatlah bahwa jika aplikasi Anda menjadi bagian dari alur kerja standar untuk salah satu area kami mungkin akan digunakan selama 10 tahun atau lebih, jadi seperti apa peta jalan produk Anda? Jika Anda belum mendukung versi baru-baru atau dalam pengembangan Windows, apakah Anda memiliki rencana kapan Anda akan melakukannya? Apakah Anda seperti menempel pada roadmap ini? Apakah terlihat seperti Anda memiliki rencana untuk perubahan drastis ke aplikasi Anda, baik cara kerjanya atau teknologi / kerangka kerja yang digunakannya? Apakah aplikasi Anda terhubung ke aplikasi lain, mis. MS Office atau IE, jika demikian seberapa tolerannya dari versi yang lebih lama atau yang lebih baru?