☀️ 👨🏾‍🔬 👋🏾 Bagaimana cara menghindari pemrograman yang menjengkelkan? Kiat Integrator 🎧 🚴 🤯

Dalam artikel sebelumnya tentang masalah memperkenalkan ERP di perusahaan industri sebagai studi kasus, salah satu poin dibawa ke "kekacauan terprogram."

Kami memiliki pelanggan yang karyawannya sekarang, mengirimkan kepada kami persyaratan yang meragukan, menentukan apakah ini merupakan pelanggaran hukum terprogram. Dan beberapa tidak menentukan, tetapi membuatnya.

Topiknya relevan, dan saya memutuskan untuk menulis artikel terpisah tentangnya.

Apa itu?

Jenis lukisan apa yang dilukis oleh imajinasi Anda ketika Anda mendengar ungkapan "pelanggaran hukum terprogram"?

Seorang lelaki berjanggut dengan wajah pintar termenung menghantam akuntan kepala yang menangis dengan volume Knut, mengatakan: "Kopek, Anda mengatakan Anda belum menyetujui faktur? Penerima tidak muat di dalam sel? Sekarang kita akan mencapnya dengan buku dan semuanya akan cocok! "

, - . , : « 10 , ? ? , ?» — , - … : « – : , . : … …»

Fenomena ini kurang berwarna daripada yang bisa Anda bayangkan, tetapi lebih mengerikan. Pada akhirnya, kepala akuntan dapat tenang, menghapus air mata dan mengirim ke psikolog, para master dapat dilepaskan dari kursi dan dikirim untuk bekerja. Tapi kurva posting di InventTrans dan rusak karena kesalahan perhitungan dalam arsitektur solusi dan perbaikan yang tidak perlu, psikolog tidak akan memperbaiki perencanaan ringkasan.

Pelanggaran hukum terprogram adalah situasi ketika sebagai akibat dari pemrograman, yang tujuannya adalah untuk memecahkan masalah-masalah tertentu dari suatu bisnis, yang lain, seringkali lebih serius, masalah-masalah untuk bisnis diciptakan.

Biarkan saya memberi Anda beberapa contoh:

, , . - , .
. , , «» . . , , .

Saya ingin menamai artikel itu "kekacauan Programmer. Integrator Menangis ”, tetapi menyadari bahwa tidak ada yang peduli dengan air mata kita. Tetapi tips tentang cara menghindari situasi seperti itu mungkin berguna.

Saya akan mencoba untuk menguraikan batas-batas rekomendasi saya di muka - kita berbicara tentang:

programmer yang terlibat dalam implementasi atau pemeliharaan sistem ERP. Saya pikir mereka memiliki persyaratan yang sedikit berbeda dari, misalnya, pengembang produk atau teknologi baru;
programmer yang bekerja dengan klien. Pengembang integrator kurang rentan terhadap "kemarahan."

Jadi apa penyebab dari fenomena ini dan apa yang bisa dilakukan untuk itu?

Keengganan atau ketidakmampuan untuk melihat esensi dari proses

Saya sering melihat ini dengan analis dan pemrogram pemula. Mereka hanya menjawab pertanyaan yang diajukan pelanggan. Mereka tidak memikirkannya - mengapa dia bertanya tentang itu, apakah dia benar-benar membutuhkannya? Seiring waktu, ini berlalu, tetapi pada awalnya Anda harus menangkap dan menjelaskan.

"Dan bisakah kamu meningkatkan jumlah tempat desimal untuk koefisien ini menjadi 4?" - "Tentu saja". Tetapi tidak ada koefisien yang digunakan untuk mengindeks parameter, yang memiliki akurasi 1 desimal, dan nilainya tidak melebihi 50? Semua akurasi koefisien akan masuk ke pembulatan. Jadi mungkin lebih baik tidak melakukan ini?

"Tambahkan bidang baru jenis ini ke referensi tata nama" - "Bagus. Kompleksitasnya 15 menit. " Jadi, mengapa Anda membutuhkan bidang ini dalam nomenklatur? Ini adalah karakteristik yang bervariasi dari satu pihak ke pihak lainnya. Mungkin lebih baik menambahkan bidang ini ke direktori partai?

Pengembang dalam ERP tidak harus hanya pelaksana perubahan yang dilakukan pengguna. Dia perlu memahami logika sistem dan bertindak sebagai pelindung terhadap semua omong kosong. Untuk melakukan ini, alangkah baiknya untuk memahami proses bisnis setidaknya pada tingkat akal sehat dan dapat mengajukan pertanyaan tidak nyaman kepada pengguna.

Oleh karena itu, jika salah satu pengguna tidak pernah menggunakan Anda dengan keluhan tentang kecerobohan seorang programmer yang menolak untuk mengimplementasikan Wishlist nya, pengembang ini harus melihat lebih dekat. Mungkin dia hanya melakukan apa yang mereka katakan. Dan ini jarang berakhir dengan sesuatu yang baik.

Kurangnya stamina dalam perang melawan keinginan untuk meninggalkan segalanya dengan cara lama

Ini adalah kasus ketika programer mess tidak dibuat oleh pengembang, tetapi dengan kenyamanan mereka.

Setiap produk serius tidak hanya membawa serangkaian fungsi tertentu, tetapi juga ideologi, praktik terbaik. Dan orang-orang ingin bekerja dengan cara lama. Dan mereka memberi tekanan pada programmer untuk memberinya kesempatan ini. Dan jika dia tidak dapat membuktikan bahwa ini tidak boleh dilakukan, maka semuanya bisa berakhir dengan sedih.

, , , . . : « 1974 , , ». , , , , . « , , – ». , , , . , . , , . : , , - , . : «».

Apa yang bisa dilakukan dengan ini? Untuk mulai dengan, jangan bawahkan programmer ke layanan ekonomi. Dia harus bekerja di unit lain dan memiliki kebebasan dari manajemen departemen yang pekerjaannya otomatis.

Alangkah baiknya menambahkan satu tautan ke rantai ini: setiap perbaikan serius harus disetujui tidak hanya oleh kontraktor, tetapi juga oleh seseorang yang memahami bisnis perusahaan secara keseluruhan dan memiliki kekuatan. Orang seperti itu pasti bisa mengatakan: "Tidak."

Kebiasaan memecahkan semua masalah dengan pemrograman

Kecintaan pada otomatisasi mengarah pada kemajuan, tetapi terkadang merugikan. Saya telah menyaksikan bagaimana, alih-alih menginstruksikan orang untuk secara manual memasukkan data ke dalam sistem, input ini otomatis. Otomatis, lupa beberapa detail atau fitur yang perlu diperhatikan, dibahas, dan kemungkinan besar diperbaiki dengan entri manual. Jadi - semua orang yakin bahwa tidak ada kesalahan, tetapi setelah beberapa saat konsekuensinya keluar secara massal, yang sudah jauh lebih sulit untuk diperbaiki daripada penyebab dasarnya.

, , . , , , . . , . , , . : .

Oleh karena itu, ketika seorang programmer diminta untuk menulis skrip untuk memperbaiki 200 kesalahan yang muncul karena fakta bahwa pengguna tidak bekerja sesuai dengan instruksi, ia tidak boleh terburu-buru masuk ke keyboard. Kita perlu memperkirakan berapa banyak waktu yang diperlukan untuk memperbaiki satu kesalahan secara manual, dan jika waktu untuk memperbaiki semua kesalahan secara manual tidak melebihi kompleksitas penulisan skrip dengan urutan besarnya, membuat pengguna untuk memperbaiki kesalahan ini sendiri: ada lebih banyak kesempatan bahwa mereka akan bekerja sesuai dengan instruksi di masa depan. Ini harus diperkenalkan sebagai aturan, tergantung di dinding dekat programmer sehingga ia dapat menyodok semua pengunjung ke dalam kertas ini.

Selain itu, untuk beberapa alasan kami berpikir bahwa jika orang dibebaskan dari pekerjaan rutin karena otomatisasi, mereka akan melakukan sesuatu yang bermanfaat: mereka akan mulai menawarkan ide untuk meningkatkan proses bisnis, mengoptimalkan pelaporan, dan melatih kolega yang kurang berpengalaman. Tetapi kemungkinan besar mereka hanya akan memiliki lebih banyak waktu untuk minum teh, merokok dan internet di tempat kerja. Jadi, apakah itu layak?

Percaya diri

Ada fungsi yang tidak boleh dimodifikasi. Dalam Axapt, ini, misalnya, perencanaan induk. Dalam ingatanku, kami menyentuhnya hanya 2 kali. Dan setiap kali itu tidak menanamkan dalam kode, tetapi semacam "noda" - fungsi yang dilakukan sebelum atau setelah perencanaan konsolidasi. Meski begitu, saya ingat perbaikan ini dengan kerinduan.

Ada tempat-tempat yang kurang jelas di mana Anda tidak boleh memanjat. Dan cara yang bagus untuk membedakan seorang programmer yang berpengalaman dari seorang pemula adalah menawarkan untuk memperbaiki fungsi seperti itu: yang berpengalaman akan terkejut dan menolak, dapat menyarankan untuk mengoptimalkan proses bisnis, dan pemula akan berkata: "Ayo."

Di sini satu hal yang dapat disarankan: mempekerjakan orang dengan pengalaman yang, sudah dari pelanggan lain atau pada proyek lain, mendapatkan semua benjolan yang, pada prinsipnya, dapat diisi.

Kurangnya peraturan pembangunan

Ketika kami mengambil proyek untuk dukungan, salah satu dokumen pertama yang kami tanyakan kepada pelanggan adalah peraturan pengembangan yang menggambarkan lingkungan pengembangan, aturan untuk penamaan objek, larangan dan pembatasan. Hal yang paling aneh adalah terkadang hal itu tidak terjadi. Dan ini adalah pertanda pasti - akan ada sampah dalam kode: mulai dari kurangnya komentar klasik dan berakhir dengan situasi ketika nilai-nilai spesifik dari direktori untuk berbagai cabang algoritma ditulis langsung dalam teks. Dan sampah dalam kode adalah langkah pertama menuju masalah dengan bisnis.

Karena itu, jangan berbicara tentang fakta bahwa “pemrograman adalah seni. Ini tidak diatur "," tapi bagaimana dengan lincah? " dan itu saja. Jika Anda berkembang, maka harus ada regulasi. Dan ini bukan 3 poin:

pengembangan dilakukan pada aplikasi dev;
pengujian dilakukan pada aplikasi pengujian;
Kode harus memiliki komentar.

Ini harus berupa dokumen lengkap dengan sepuluh halaman dengan bagian:

Persyaratan untuk pengembangan aplikasi.
Persyaratan untuk menulis pernyataan masalah.
Persyaratan untuk menulis kode.
Persyaratan pengujian.
Persyaratan migrasi antar aplikasi.

Sebagai aturan, seluruh hardcode dilakukan sesuai dengan prinsip "Mari kita lakukan dengan cepat, dan kemudian lakukan secara normal". Ini dilakukan dengan cepat, dan kemudian dilupakan ... Dan ketika ada dokumen yang ditandatangani yang menyatakan bahwa ini tidak dapat dilakukan, Anda selalu dapat menyodok ke dalamnya dan memberi tahu pengguna: "Tidak akan berhasil dengan cepat, saya dilarang bekerja seperti itu. Maaf, Alevtina Svetozarovna, saya akan senang mengomentari semua cek pada pekerja, tetapi kemudian mereka akan memecat saya. "

Kesepian dan kurangnya kontrol

Seorang programmer yang kesepian itu jahat. Harus selalu ada seseorang yang berkata: "Nah, apa yang telah kamu, bodoh lakukan?" - Kalau tidak, pengembang santai, lupakan aturan, lupakan tanggung jawab. Di sinilah hardcode dimulai, keputusan arsitektur yang meragukan, kesalahan yang memengaruhi bisnis.

Secara cerdik, ini disebut "tinjauan kode" dan ini adalah sesuatu yang harus selalu sejalan dengan peraturan pembangunan. Setelah setiap revisi, sebelum mengujinya, harus ada pemeriksaan kepatuhan kode dengan peraturan pengembangan dan praktik terbaik. Ulasan kode akan memungkinkan:

mengontrol kualitas pembangunan;
melatih programmer yang kurang berpengalaman.

Oleh karena itu, pengembang harus setidaknya 3 buah (dua akan selalu setuju bahwa Anda tidak dapat melakukan apa-apa, pihak ketiga pada sistem akan secara signifikan mengurangi kemungkinan kolusi). Dan mereka harus bekerja sesuai dengan peraturan internal, salah satu poin utama di antaranya adalah tinjauan kode wajib.

Kesimpulan

Dengan demikian, untuk mengurangi kemungkinan "pelanggaran hukum terprogram", perlu untuk membentuk departemen pengembangan internal Anda sendiri sesuai dengan aturan berikut:

Ini harus tim minimal 3 orang.
Setidaknya satu dari tim ini harus memiliki pengalaman dalam menerapkan atau memelihara sistem ERP, itu harus menjadi proyek ke-n, di mana n> 3.
Departemen pengembangan idealnya harus melaporkan langsung ke CEO.
Pengguna akhir terkadang harus mengeluh bahwa programmer menolak untuk mengimplementasikan beberapa persyaratan mereka.
Bahkan untuk departemen sekecil itu, peraturan harus dikembangkan, untuk pelanggaran yang harus dihukum.

Secara alami, ini adalah visi saya. Dapat diperdebatkan, pada setiap poin ini bahkan saya dapat memberikan contoh tandingan dari pengalaman saya ketika persyaratan tidak terpenuhi, tetapi semuanya sempurna. Tetapi rekomendasi ini dapat digunakan sebagai titik awal untuk pembentukan prinsip-prinsip mereka dalam memerangi pelanggaran hukum program.

Bagaimana cara menghindari pemrograman yang menjengkelkan? Kiat Integrator