Penyelenggaraan Perisian Selepas Pelancaran: Pepijat atau Permintaan Perubahan, dan Apa yang Patut Dilindungi Perjanjian Penyelenggaraan

Dua minggu selepas sistem perniagaan baharu mula digunakan, pemiliknya menghantar mesej WhatsApp: "Laporan ini salah, dan saya juga mahu ia menunjukkan angka tahun lepas." Pembangun menjawab bahawa bahagian kedua ialah ciri baharu dan akan disebut harga. Pemilik menjawab bahawa keseluruhan laporan itu memang sepatutnya berfungsi. Kedua-duanya separuh betul, dan tiada yang dapat membuktikannya, kerana tiada sesiapa menulis apa yang "laporan" itu patut lakukan atau bagaimana masalah akan dikelaskan.

Panduan ini untuk pemilik perniagaan yang telah membina sistem atau aplikasi tersuai, atau akan membinanya, dan ingin tahu apa yang perlu dijangka selepas ia beroperasi. Ia menerangkan perbezaan antara pepijat dan permintaan perubahan, cara melaporkan setiap satu supaya boleh ditindak, apa yang patut dan tidak patut dilindungi oleh perjanjian penyelenggaraan, dan cara menyemaknya setiap bulan. Ia panduan am, bukan nasihat undang-undang, dan tidak menerangkan terma mana-mana pembekal.

Pepijat, permintaan perubahan dan dua perkara yang kelihatan serupa

Hampir setiap aduan selepas pelancaran tergolong dalam salah satu daripada empat kumpulan. Pengelasan yang betul penting kerana setiap kumpulan dikendalikan, dan selalunya dicaj, secara berbeza.

• Pepijat (kecacatan). Sistem tidak berfungsi seperti yang dipersetujui. Tingkah laku itu tertulis dalam skop yang ditandatangani, sebut harga atau senarai semak penerimaan, tetapi sistem sebenar menyimpang daripadanya.
• Permintaan perubahan. Anda mahukan sesuatu yang tidak dipersetujui: medan, laporan atau langkah kelulusan baharu. Sistem berfungsi seperti yang dinyatakan.
• Soalan penggunaan. Sistem berfungsi seperti yang dipersetujui, tetapi seseorang tidak tahu cara menggunakannya atau tersalah memasukkan data. Penyelesaiannya latihan atau skrin yang lebih jelas.
• Perubahan luaran. Sesuatu di sekeliling sistem berubah: penyedia pembayaran mengubah sambungannya, kemas kini pelayar mengubah tingkah laku, atau pembaharuan pengehosan tamat tempoh.

Baris terakhir menunjukkan mengapa garisan itu kadangkala kabur. Apabila perjanjian tidak menyebutnya atau samar, label yang jujur ialah "tidak jelas, perlu diputuskan", dan keputusan itu harus direkodkan, bukan diperdebatkan dalam sembang.

Ujian satu minit: adakah ia dipersetujui?

Anda tidak memerlukan pengetahuan teknikal untuk mengelaskan masalah, hanya asas persetujuan dan beberapa soalan.

1. Cari asas persetujuan. Skop yang ditandatangani, huraian kerja dalam sebut harga dan senarai semak yang anda tanda semasa ujian penerimaan pengguna. Versi yang diterima ialah garis permulaan bagi segala-galanya selepas itu.
2. Adakah ia menyatakan bagaimana ini patut berfungsi? Jika ya dan sistem sebenar berbeza, laporkan pepijat dan petik baris yang anda rujuk.
3. Adakah ia tidak menyebutnya? Maka ia permintaan perubahan, walau betapa jelas rasanya. "Jelas" ialah titik permulaan perbalahan.
4. Adakah ia samar? Minta pembangun mencadangkan tingkah laku yang dimaksudkan dan sahkannya secara bertulis sebelum kerja bermula.

Mengapa takrifan dipersetujui sebelum pembinaan

Label itu selalunya menentukan siapa yang membayar, dan wang menukarkan soalan neutral menjadi pertengkaran. Cara termurah ialah menetapkan peraturan semasa tiada pihak mempunyai kepentingan dalam jawapannya.

• Takrifkan pepijat secara bertulis. Contohnya, "tingkah laku yang berbeza daripada spesifikasi atau senarai semak penerimaan yang ditandatangani", dengan tiga atau empat contoh daripada perniagaan anda sendiri.
• Takrifkan perubahan. Apa-apa yang baharu, atau perubahan kepada tingkah laku yang diluluskan, disebut harga sebelum kerja bermula.
• Nyatakan siapa memutuskan kes kelabu, dan dalam berapa lama. Seorang yang dinamakan di setiap pihak, dan peraturan seperti "perkara tidak jelas diputuskan dan direkodkan dalam seminggu".
• Nyatakan asas persetujuan. Sistem yang diterima pada tarikh yang direkodkan, dengan senarai semak penerimaan dilampirkan.
• Nyatakan tempoh pembetulan percuma. Sering dipanggil tempoh waranti atau pembetulan kecacatan. Laman vendor menyebut tempoh daripada kira-kira sebulan hingga beberapa bulan, tetapi tiada piawaian, jadi yang penting ialah ia tertulis, bila ia bermula (pelancaran atau penerimaan) dan apa yang berlaku apabila ia tamat.

Perkara ini patut ada dalam sebut harga atau kontrak, sebab itu membandingkan sebut harga perlu merangkumi apa yang dinyatakan tentang kehidupan selepas pelancaran. Cara perubahan dihargakan berkait dengan harga tetap berbanding kadar sejam, dan jadual sekitar pelancaran dengan tempoh membina sistem tersuai.

Cara melaporkan pepijat supaya boleh dibaiki

Pembangun tidak boleh membaiki "ia rosak". Laporan yang baik membolehkan seseorang mengulang masalah itu dalam beberapa minit tanpa menelefon anda:

• Apa yang anda lakukan. Langkah tepat: "Buka Sebut Harga, pilih Q-0231, klik Tukar kepada invois."
• Apa yang anda jangka, sebaiknya dengan baris persetujuan yang bercanggah.
• Apa yang berlaku. Salin mesej perkataan demi perkataan.
• Bukti. Tangkapan skrin yang menunjukkan seluruh tetingkap pelayar, atau rakaman skrin pendek.
• Bila dan kekerapan. Mula perasan bila, setiap kali atau kadangkala, seorang pengguna atau semua.
• Peranti dan pelayar. Telefon atau komputer, dan pelayar yang mana.
• Siapa terjejas, dan sejauh mana mendesak. Gunakan skala yang dipersetujui lebih awal.

Gunakan skala itu dengan jujur. Jika semuanya "terhenti", tiada apa yang terhenti. Laporan yang baik berbunyi: "12 November, 10:40, komputer riba, Chrome. Saya klik Tukar kepada invois pada sebut harga Q-0231 dan menjangka invois dengan baris yang sama. Mesej merah 'Something went wrong' muncul dan tiada apa dibuat. Tangkapan skrin dilampirkan. Ia berlaku tiga kali, dan rakan sekerja melihat perkara yang sama. Kami tidak dapat membil pelanggan ini hari ini, jadi ia tinggi."

Cara menghuraikan permintaan perubahan

Huraikan masalahnya, bukan hanya skrin yang anda bayangkan. "Tambah lajur tahun lepas" membuatkan pembangun meneka. "Setiap Isnin pengurus jualan kami membandingkan setiap bulan dengan bulan yang sama tahun lepas, menggunakan hamparan" membolehkan mereka mencari cara termudah memenuhi keperluan itu. Sertakan hasil yang anda perlukan, siapa menggunakannya dan kekerapannya, jalan penyelesaian sementara yang digantikannya, bagaimana anda tahu ia berjaya (satu ayat yang boleh disemak) dan sebarang tarikh akhir.

Jangka jawapan bertulis sebelum kerja bermula: sama ada ia boleh dilakukan, apa yang terjejas, berapa lama dan berapa kosnya, atau berapa jam termasuk yang akan digunakan. Jika jawapannya "ya" dalam mesej sembang, minta ia dicatat dalam senarai juga. Kelulusan lisan ialah punca utama bil yang tiada sesiapa ingat telah dipersetujui.

Simpan satu senarai berjalan

Masalah, idea dan soalan bertimbun dalam WhatsApp, e-mel dan panggilan telefon. Pilih satu senarai, seperti hamparan kongsi, dan letakkan semuanya di situ. Ia juga memberi anda fakta untuk semakan bulanan dan sebarang perselisihan kemudian.

Seorang di pihak anda memiliki senarai itu dan membaca setiap baris baharu. Satu item ditutup hanya apabila anda sendiri telah menguji pembetulannya, prinsip yang sama seperti semakan akhir sebelum penerimaan.

Mengapa perisian perlu diselenggara walaupun seperti tiada apa berubah

Sistem yang tidak anda sentuh tidak kekal statik. Pelayar dan telefon dikemas kini, komponen perisian yang membentuknya mengeluarkan pembaikan keselamatan, perkhidmatan yang disambungkan mengubah peraturan, dan data anda bertambah. Jurutera lazimnya mengumpulkan kerja ini kepada empat jenis: pembetulan (membaiki kerosakan), penyesuaian (mengikuti persekitaran), penambahbaikan (memperbaik yang sedia ada) dan pencegahan (kemas kini keselamatan, semakan sandaran, pemantauan). Perjanjian penyelenggaraan patut menyatakan yang mana satu termasuk. Pengabaian bukan percuma, kerana kerosakan kecil yang dibiarkan menimbun menjadikan setiap perubahan kemudian lebih perlahan dan berisiko.

Apa yang patut dilindungi oleh perjanjian penyelenggaraan

Perjanjian penyelenggaraan (retainer) ialah perjanjian, biasanya bulanan, yang mana pembekal memastikan sistem anda sihat dan memberi respons apabila anda memerlukan bantuan. Yang baik adalah khusus. Cari setiap perkara ini secara bertulis:

• Pembaikan pepijat. Sama ada kerosakan dibaiki dalam perjanjian, bermula bila, dan bagaimana ujian "adakah ia dipersetujui?" digunakan.
• Perubahan kecil. Bilangan jam yang dinyatakan, cara permintaan lebih besar disebut harga, dan sama ada jam tidak terpakai luput atau dibawa ke hadapan.
• Kemas kini keselamatan dan platform. Siapa menggunakan kemas kini pada rangka kerja, pustaka dan perisian pelayan, berapa kerap, dan bagaimana ia diuji sebelum dilancarkan.
• Sandaran dan ujian pemulihan. Apa yang disandarkan, berapa kerap, di mana salinan disimpan dan bukti bahawa pemulihan telah dicuba. Sandaran yang tidak pernah dipulihkan hanyalah harapan, bukan perlindungan. Panduan sandaran laman web menerangkan prinsipnya.
• Pemantauan. Apa yang dipantau (ketersediaan, ralat, ruang cakera, tarikh tamat sijil), siapa dimaklumkan dan apa yang berlaku seterusnya.
• Pembaharuan. Pengehosan, domain, sijil SSL dan sebarang perkhidmatan pihak ketiga berbayar: siapa menjejak tarikh, siapa membayar, dan atas nama siapa setiap satu. Pembaharuan yang tamat tempoh ialah punca biasa gangguan yang boleh dielakkan.
• Orang perhubungan yang dinamakan. Seorang individu, seorang pengganti, dan saluran untuk hal segera.
• Jangkaan respons. Waktu perkhidmatan, masa untuk mengakui laporan dan masa untuk memulakan kerja bagi setiap tahap segera, dan maksud "selesai". Mengakui laporan bukan membaikinya.
• Jam dan kerja tambahan. Apa yang termasuk setiap bulan, bagaimana kerja tambahan disebut harga dan diluluskan sebelum bermula, dan bagaimana jam yang digunakan dilaporkan.
• Serah terima dan penamatan. Dokumentasi, akses dan kod, seperti dalam siapa memiliki kod sumber perisian tersuai, supaya penamatan perjanjian tidak membiarkan anda terkandas.

Sama pentingnya ialah apa yang dikecualikan, dan pengecualian itu patut kelihatan sebelum anda menandatangani. Yang lazim ialah ciri baharu dan perubahan lebih besar (disebut harga berasingan), kerosakan akibat gangguan pihak ketiga atau perubahan pihak lain pada sistem, latihan untuk staf baharu dan pembersihan data, reka bentuk semula atau perpindahan platform utama, peranti dan rangkaian anda sendiri, serta yuran lesen pihak ketiga kecuali dikenakan kepada anda pada jumlah yang dinyatakan.

Perjanjian penyelenggaraan untuk laman web ialah produk yang berkaitan tetapi berbeza. Kos penyelenggaraan laman web di Malaysia dan mengapa laman web perlu penyelenggaraan berterusan membincangkannya, dan salinan staging turut membantu di situ. Sistem tersuai mempunyai pangkalan data, log masuk, peraturan perniagaan dan integrasinya sendiri, jadi senarainya berbeza.

Soalan untuk ditanya sebelum menandatangani

• Bagaimana anda mentakrifkan pepijat dan permintaan perubahan? Sila beri tiga contoh daripada perniagaan saya.
• Apakah tempoh pembetulan percuma, bila ia bermula dan apa berlaku selepas ia tamat?
• Berapa jam termasuk, apa berlaku kepada jam tidak terpakai, dan bagaimana kerja tambahan diluluskan?
• Apakah respons anda bagi setiap tahap segera, dalam waktu bekerja, dan siapa menggantikan apabila orang perhubungan saya bercuti?
• Bagaimana dan berapa kerap kemas kini dibuat, dan bilakah ujian pemulihan sandaran terakhir dijalankan?
• Siapa menjejak dan membayar pembaharuan, dan atas nama siapa?
• Siapa boleh melihat data langsung saya, dan bagaimana akses dihadkan?
• Apa yang saya terima apabila tamat, termasuk kod dan dokumentasi, dan apa yang tidak dilindungi?

Tanda perjanjian penyelenggaraan terlalu nipis atau kabur

• Tiada takrifan. "Sokongan" dan "penyelenggaraan" digunakan dengan longgar, tanpa garis antara pepijat dan perubahan.
• Tiada jangkaan respons, atau hanya janji membalas "secepat mungkin".
• Segala-galanya tanpa had. Perubahan tanpa had pada harga bulanan tetap, tanpa cara melihat apa yang dibuat, biasanya berakhir dengan perbalahan tentang apa yang munasabah.
• Tiada apa tentang kemas kini, atau sandaran tanpa ujian pemulihan.
• Tiada orang yang dinamakan, hanya peti masuk umum atau kumpulan sembang.
• Akaun atas nama pembekal, seperti domain, pengehosan atau akaun kedai aplikasi anda.
• Tiada pengecualian dan tiada terma penamatan. Had dan keterikatan disembunyikan dalam dokumen lain.

Rutin semakan bulanan yang mudah

Tetapkan slot berulang 30 minit, bersama orang perhubungan pembekal jika ada ringkasan bulanan. Gunakan agenda yang sama setiap kali.

1. Baca senarai. Apa yang baharu, apa yang terbuka, apa yang paling lama menunggu? Susun semula item "tidak jelas" dan rekodkan siapa memutuskan.
2. Semak jam. Bandingkan jam digunakan dengan jam termasuk, dan lihat item terbesar.
3. Cari perkara berulang. Aduan sama tiga kali menunjukkan perlunya perubahan, latihan atau pembaikan punca.
4. Semak tarikh. Pembaharuan dalam 90 hari akan datang, sijil hampir tamat, tempoh pembetulan yang hampir berakhir.
5. Minta bukti. Adakah kemas kini telah dibuat, dan adakah pemulihan diuji baru-baru ini?
6. Putuskan kerja bulan depan. Pilih ke mana jam digunakan dan catat apa yang anda tolak.

Sekali atau dua kali setahun, tanya sama ada sistem masih sesuai dengan cara anda bekerja. Jika tidak, itu perbincangan projek yang lebih besar.

Kesilapan biasa

• Menganggap setiap hasrat sebagai pepijat. Ia menghakis kepercayaan dan melambatkan kerosakan sebenar.
• Melapor hanya melalui nota suara. Tiada sesiapa boleh mencarinya, dan butiran hilang.
• Membiarkan tempoh pembetulan tamat tanpa disedari. Catat tarikh akhir dalam diari dan uji segala-galanya sebelum itu.
• Bersetuju dengan perubahan dalam sembang dan lupa bilnya. Dapatkan sebut harga bertulis dahulu.
• Menutup item yang belum anda uji.

Kedudukan Gotka Technologies

Perkhidmatan Pembangunan Aplikasi & Sistem Gotka membina aplikasi mudah alih, aplikasi web dan sistem perniagaan, bermula daripada RM8,000 (indikatif) untuk aplikasi web dan papan pemuka, RM12,000 untuk sistem perniagaan dan integrasi serta RM15,000 untuk aplikasi mudah alih, masing-masing disahkan melalui sebut harga bertulis selepas keperluan anda dikenal pasti. Panduan ini tidak menerangkan sebarang terma sokongan, tempoh pembetulan atau perjanjian penyelenggaraan Gotka, jadi minta mana-mana pembekal, termasuk Gotka, menulisnya sebelum anda menandatangani. Jika anda masih memilih pembina, lihat pekerja bebas, pembangun dalaman atau syarikat perisian dan apa yang perlu disediakan sebelum perbualan pertama. Gotka juga menawarkan pelan Care bulanan pilihan untuk laman web, diterangkan di halaman Care laman web; ia bukan perjanjian penyelenggaraan sistem perisian. Anda boleh menghubungi pasukan kami melalui halaman hubungi.

Istilah utama dalam panduan ini

• Pepijat (kecacatan): tingkah laku yang berbeza daripada apa yang dipersetujui.
• Permintaan perubahan: permintaan menambah atau mengubah tingkah laku yang tidak dipersetujui.
• Asas persetujuan (baseline): versi sistem yang diterima dan skop yang ditandatangani.
• Tempoh waranti (pembetulan kecacatan): tempoh dinyatakan yang mana pembina membaiki pepijat tanpa caj berasingan, seperti ditakrif kontrak.
• Retainer: perjanjian berulang, biasanya bulanan, untuk menyelenggara dan menyokong sistem.
• Ujian pemulihan: memulihkan sandaran untuk membuktikan ia berfungsi.
• Jalan penyelesaian sementara: cara sementara melakukan tugas semasa kerosakan dibaiki.
• Pengecualian: kerja yang dinyatakan perjanjian tidak dilindungi.