Setelah uji coba "panas" minggu lalu, otak tampaknya santai dan terperangkap dalam pertanyaan: "Apa yang seharusnya dilakukan agar semuanya berjalan lancar dan tanpa semua saraf ini?"
Pilihan jawaban yang dia hasilkan, saya akan coba gariskan.
Tentang diriku
9 tahun - konsultan TI SAP ERP. Tanggung jawab: desain, pemimpin tim, pengujian dan debugging, pelatihan, uji coba.
Kerangka kerja penerapan
Dia menulis berdasarkan proyek dari 3-4 bulan hingga 1 tahun dengan integrasi intersistem yang kompleks.
Setelah memutuskan untuk tidak mengambil risiko tenggelam dalam mencapai perfeksionisme, setelah kehilangan sumbu awal untuk menulis - saya harus meninggalkan klaim pada struktur tingkat tinggi, konsistensi dan kelengkapan. Untuk alasan yang sama, teks hanya ditulis "dari pengalaman pribadi", saya tidak membaca teks yang sesuai dengan topik sebelum publikasi.
Oleh karena itu, saya bergantung pada komentator sampai batas tertentu untuk mungkin menulis edisi kedua di mana kriteria di atas sudah sampai pada sasaran.
Glosarium
BA - analis bisnis
BZ - basis pengetahuan proyek
BT - persyaratan bisnis
TI - arsitek dan konsultan tim proyek
KP - pengguna utama
MK - konsultan junior, enikeyschik
PR - solusi desain
Prod - sistem produktif
Razrab - pengembang
ST - skrip uji
SK - senior konsultan, perancang
spesifikasi teknis - kerangka acuan
Kunci Sukses Proyek TI
Pesan umum adalah komunikasi yang lancar
Penting untuk mencapai sinkronisasi antara bisnis dan TI dalam persepsi persyaratan bisnis, skenario pengujian, keputusan desain dan bagaimana akan terlihat dalam implementasi.
BT yang terperinci dan penuh perhatian
BT harus memiliki pemahaman yang lengkap dan sinkron antara bisnis dan TI. Untuk melakukan ini, harus BA dan KP (idealnya, ketika BA adalah mantan KP).
Kumpulan skrip uji lengkap
Jumlah maksimum dari skenario yang paling terperinci harus diketahui dan dikerjakan sebelum menulis solusi. Naskah harus ditulis, mulai dari yang paling umum hingga yang paling langka. Yang terakhir, dalam hal otomatisasi mahal mereka, harus memiliki kontrol manual yang bijaksana.
Pembagian kerja dalam TI
Tim proyek harus memiliki divisi sesuai dengan kompleksitas intelektual pekerjaan. Adalah baik jika perancang memiliki keterampilan untuk merancang dokumentasi dengan gaya tanpa biaya tambahan. Kalau tidak, lebih baik memberikan panduan "kecantikan" kepada seseorang dengan posisi junior.
Hal yang sama berlaku untuk konten TK / PR dalam kondisi saat ini:
- Komite Investigasi menulis kepada pengembang tentang penyesuaian dan menempatkan MK dalam salinan
- MK mengumpulkan dan mencerminkan perubahan dalam mode edit menggunakan versi
- SC menerima pengeditan
- MK memperbarui dokumentasi dalam KB
Pengujian juga harus didelegasikan ke MC.
Saya tidak tahu bagaimana ini di luar SAP, tetapi prinsip konsultan-pemanen sering digunakan di sini, yang melakukan segalanya (desain, pengujian, dokumentasi penulisan).
Akibatnya, kualitas, persyaratan (dan "uang") menderita dan risiko yang terkait dengan segala sesuatu yang diikat untuk 1 orang.
Menguji skrip sebelum rilis
- Pengujian harus dilakukan di lingkungan yang dekat dengan lingkungan produk (idealnya dalam salinan penjual).
- Partisipasi orang yang akan langsung bekerja dengan fungsionalitas adalah wajib (disarankan untuk melakukan program pendidikan dengan keputusan sebelum itu).
Ruang bersama untuk tim yang mengintegrasikan sistem
Ketika ada integrasi yang kompleks dalam proyek, sangat penting untuk menciptakan bidang umum dari konteks proyek dan menyediakan "dekat dengan tubuh". Idealnya, seluruh tim proyek harus berada dalam satu ruangan. Jika tidak, Anda memerlukan orang yang terpisah atau alat yang nyaman yang akan memberikan sinkronisasi antar tim.
Tuan rumah kecukupan teknis
Persetujuan formal PR oleh bisnis adalah momok proyek. Pihak penerima harus sepenuhnya dan secara terperinci membayangkan solusinya. Jika proyek menyangkut modernisasi mendalam dari fungsi yang ada, maka bisnis harus mengetahuinya dengan sangat baik.
Ini sangat ideal jika tuan rumah adalah orang dengan pengetahuan bisnis yang sangat baik dengan logika yang konsisten dan terstruktur.
Pilot Moderator
Netral untuk IT dan pebisnis dengan bakat sebagai arbitrator. Menyusun rencana uji coba, menyusun protokol uji, melacak komentar dan koreksi mereka.
Jika ada terburu-buru, ada ide untuk menggambarkan masalah yang mungkin timbul jika rekomendasi yang dijelaskan tidak diikuti.