Sugeng rawuh, Habr! Jenengku Lesha, aku analis sistem kanggo salah sawijining tim produk Alfa-Bank. Saiki aku ngembangake bank online anyar kanggo entitas legal lan wirausaha individu.
Lan nalika sampeyan analis, utamanΓ© ing saluran kuwi, sampeyan ora bisa menyang ngendi wae tanpa dokumentasi lan cedhak karya karo. Lan dokumentasi minangka perkara sing tansah nuwuhake pitakon. Napa aplikasi web ora diterangake? Yagene spesifikasi kasebut nuduhake carane layanan kasebut kudu ditindakake, nanging ora kaya ngono? Kok mung wong loro, siji sing nulis, sing bisa ngerti spesifikasie?
Nanging, dokumentasi ora bisa diabaikan amarga alasan sing jelas. Lan kanggo nggawe urip luwih gampang, kita mutusake kanggo ngevaluasi kualitas dokumentasi. Kepiye persis kita nindakake iki lan kesimpulan apa sing kita lakoni ing ngisor iki.
Kualitas dokumentasi
Supaya ora mbaleni "Bank Internet Anyar" kaping pirang-pirang ing teks, aku bakal nulis NIB. Saiki kita duwe luwih saka rolas tim sing nggarap pangembangan NIB kanggo para pengusaha lan entitas hukum. Kajaba iku, saben wong nggawe dokumentasi dhewe kanggo layanan utawa aplikasi web anyar saka awal, utawa nggawe owah-owahan menyang sing saiki. Kanthi pendekatan iki, bisa dokumentasi ing prinsip kualitas dhuwur?
Lan kanggo nemtokake kualitas dokumentasi, kita wis nemtokake telung ciri utama.
- Iku kudu lengkap. Iki muni kaya kapten, nanging penting kanggo dicathet. Sampeyan kudu njlèntrèhaké kanthi rinci kabeh unsur solusi sing dileksanakake.
- Iku kudu cocog. Yaiku, cocog karo implementasine solusi saiki dhewe.
- Iku kudu dingerteni. Supaya wong sing nggunakake ngerti persis carane solusi dileksanakake.
Kanggo ngringkes - dokumentasi lengkap, up-to-date lan bisa dingerteni.
Jajak Pendapat
Kanggo netepake kualitas dokumentasi, kita mutusake kanggo wawancara karo wong sing langsung nggarap: analis NIB. Responden dijaluk ngevaluasi 10 pernyataan miturut skema "Ing skala saka 1 nganti 5 (rampung ora setuju - setuju banget)."
Pernyataan kasebut nggambarake karakteristik dokumentasi kualitatif lan pendapat para kompiler survey babagan dokumen NIB.
- Dokumentasi kanggo aplikasi NIB paling anyar lan konsisten karo implementasine.
- Implementasi aplikasi NIB didokumentasikan kanthi lengkap.
- Dokumentasi kanggo aplikasi NIB mung dibutuhake kanggo dhukungan fungsional.
- Dokumentasi kanggo aplikasi NIB saiki nalika diajukake kanggo dhukungan fungsional.
- Pangembang aplikasi NIB nggunakake dokumentasi kanggo mangerteni apa sing kudu ditindakake.
- Ana dokumentasi sing cukup kanggo aplikasi NIB kanggo mangerteni carane dileksanakake.
- Aku langsung nganyari dokumentasi babagan proyek NIB yen wis rampung (dening timku).
- Pangembang aplikasi NIB mriksa dokumentasi.
- Aku duwe pangerten sing jelas babagan nyiapake dokumentasi kanggo proyek NIB.
- Aku ngerti nalika nulis / nganyari dokumentasi kanggo proyek NIB.
Cetha yen mung mangsuli "Saka 1 nganti 5" bisa uga ora mbukak rincian sing dibutuhake, mula wong bisa menehi komentar ing saben item.
Kita nindakake kabeh iki liwat Slack perusahaan - kita mung ngirim undhangan menyang analis sistem kanggo njupuk survey. Ana 15 analis (9 saka Moskow lan 6 saka St. Petersburg). Sawise survey rampung, kita ngasilake skor rata-rata kanggo saben 10 statement, sing banjur kita standar.
Mangkene kedadeyane.
Survei kasebut nuduhake manawa analis cenderung percaya yen implementasine aplikasi NIB wis didokumentasikake kanthi lengkap, nanging ora menehi persetujuan sing ora jelas (0.2). Minangka conto tartamtu, padha nuding metu sing sawetara database lan antrian saka solusi ana ora dijamin dening dokumentasi. Pangembang bisa ngandhani analis yen ora kabeh didokumentasikake. Nanging tesis sing pangembang mriksa dokumentasi uga ora nampa dhukungan sing jelas (0.33). Yaiku, risiko deskripsi sing ora lengkap babagan solusi sing ditindakake tetep.
Relevansi luwih gampang - sanajan ora ana persetujuan sing jelas (0,13), analis isih cenderung nimbang dokumentasi sing relevan. Komentar ngidini kita ngerti yen masalah karo relevansi luwih kerep ana ing ngarep tinimbang ing tengah. Nanging, dheweke ora nulis apa-apa marang kita babagan backing.
Minangka kanggo apa Analysts piyambak mangertos nalika perlu kanggo nulis lan nganyari dokumentasi, persetujuan luwih seragam (1,33), kalebu desain (1.07). Apa sing dicathet ing kene minangka ora nyaman yaiku kekurangan aturan seragam kanggo njaga dokumentasi. Mula, supaya ora ngaktifake mode "Sapa sing menyang alas, sing entuk kayu bakar", dheweke kudu kerja adhedhasar conto dokumentasi sing wis ana. Mula, kepinginan sing migunani yaiku nggawe standar manajemen dokumen lan nggawe template kanggo bagean kasebut.
Dokumentasi kanggo aplikasi NIB saiki ing wektu pengajuan kanggo dhukungan fungsional (0.73). Iki bisa dingerteni, amarga salah sawijining kritΓ©ria kanggo ngirim proyek kanggo dhukungan fungsional yaiku dokumentasi sing paling anyar. Sampeyan uga cukup kanggo mangerteni implementasine (0.67), sanajan kadhangkala ana pitakonan.
Nanging apa responden ora setuju karo (cukup unanimously) sing dokumentasi kanggo aplikasi NIB, ing asas, mung perlu kanggo support fungsi (-1.53). Analis disebutake paling asring minangka konsumen dokumentasi. Tim liyane (pangembang) - luwih asring. Kajaba iku, analis percaya yen pangembang ora nggunakake dokumentasi kanggo mangerteni apa sing kudu dileksanakake, sanajan ora bebarengan (-0.06). Iki, kanthi cara kasebut, uga dikarepake ing kahanan nalika pangembangan kode lan panulisan dokumentasi ditindakake kanthi paralel.
Apa garis ngisor lan kenapa kita butuh nomer kasebut?
Kanggo nambah kualitas dokumen, kita mutusake kanggo nindakake ing ngisor iki:
- Takon pangembang kanggo mriksa dokumen sing ditulis.
- Yen bisa, nganyari dokumentasi kanthi pas wektune, ngarep dhisik.
- Nggawe lan nganggo standar kanggo ndokumentasikake proyek NIB supaya kabeh wong bisa ngerti kanthi cepet unsur sistem lan kepiye carane kudu diterangake. Inggih, gawe template sing cocog.
Kabeh iki kudu mbantu ngunggahake kualitas dokumen menyang tingkat anyar.
Paling aku ngarep-arep.
Source: www.habr.com