Apa yang terjadi selama otomatisasi normal? Tugas teknis, persyaratan fungsional, arsitektur, dan banyak kertas lainnya disusun. Ini menjelaskan semua kondisi, batasan, algoritme kerja tergantung pada lingkungan, penampilan formulir, validasi data, dll. Seringkali, desain dan koordinasi potongan kertas ini membutuhkan waktu lebih lama daripada otomasi itu sendiri.
Sebuah proyek muncul, jadwal, dekomposisi tugas, manajer proyek tertentu, atau bahkan beberapa. Formalitas mengambil alih, mis. bentuk, bukan konten.
Jelas bahwa dalam beberapa situasi ini adalah cara untuk bertindak. Misalnya, jika perusahaan eksternal bergerak di bidang otomatisasi, ia tidak akan bertahan tanpa surat-surat tersebut. dia hanya akan mengejar setelah mencapai persyaratan pelarian. Makalah menjamin stabilitas, kepastian pembayaran dan pengiriman pekerjaan. Tetapi bagi pelanggan, kertas-kertas ini hanya menjamin satu hal - proyek panjang dan membosankan yang tidak akan membawa manfaat apa pun.
Dalam pemrograman bisnis, pendekatan ini tidak cocok. Biarkan saya mengingatkan Anda bahwa pemrograman bisnis adalah perubahan yang kompleks, pada saat yang sama untuk proses, motivasi, tujuan, sistem manajemen, didukung oleh otomatisasi.
Misalnya, Anda memutuskan untuk mengubah prosesnya. Tidak ada yang mempengaruhi ribuan orang - tidak ada solusi di lutut Anda. Prosesnya, misalnya, menyangkut lima orang dari satu departemen. Semua orang ini, seperti pemimpin mereka, duduk di sebelah Anda - di sini mereka, agak jauh. Dan Anda memutuskan, bersama mereka, untuk mengubah prosesnya. Mereka duduk, berbicara, mencari tahu, berpikir, dan memutuskan. Misalnya, Anda butuh satu hari untuk mengubah prosesnya.
Dalam kebanyakan kasus, setelah mengubah proses, Anda perlu otomatisasi - Anda perlu membuat perubahan pada sistem informasi. Jika Anda mengatakan - Anda memerlukan tugas teknis, jadwal, proyek dengan pemimpin, kurator dan sponsor, maka itu saja. Di sinilah perubahan Anda akan berakhir. Proyek otomasi yang panjang dengan formalitas akan meniadakan perubahan proses.
Yang sangat penting: perubahan dalam proses adalah eksperimen. Anda, bahkan sebagai programmer bisnis yang canggih, tidak dapat mengetahui dengan pasti apakah perubahan Anda akan berhasil atau tidak. Metode yang dipilih dapat menunjukkan dirinya dengan baik dalam proses lain, atau bahkan dalam persis sama, tetapi di perusahaan yang berbeda, tetapi dalam konteks ini mungkin berubah menjadi tidak beroperasi.
Karena ini adalah percobaan, ia memiliki batas waktu - hari ini dipikirkan, diluncurkan besok, kami melihatnya selama seminggu dan membuat keputusan. Jika semuanya baik-baik saja, pergi. Jika tidak, kami berpikir lebih jauh - baik membatalkan perubahan, atau memperbaiki dan memperbaikinya.
Apa yang akan terjadi pada otomasi minggu ini? Jika Anda memilih jalur tradisional, maka dalam seminggu Anda hanya akan memiliki tugas teknis, dan kemudian dalam kasus terbaik. Dengan demikian, implementasi perubahan harus dilakukan secara manual, tanpa otomatisasi. Nah, jika Anda melakukan perubahan seperti itu yang tidak memerlukan otomatisasi - Anda dapat memeriksa "dengan mata". Dan jika tidak?
Di sinilah prinsip otomatisasi cepat diperlukan. Sebenarnya, esensinya terletak pada nama - perubahan pada sistem harus dilakukan dengan cepat, tanpa koordinasi dan persyaratan, tepat sejauh yang diperlukan untuk menguji hipotesis utama yang Anda ajukan dengan mengubah proses.
Anda tidak perlu terlalu khawatir tentang antarmuka, memeriksa data input, optimalitas kode, struktur data, dan pilar otomatisasi "kanan" lainnya. Tugas Anda adalah untuk secara otomatis mendukung otomatisasi perubahan dalam proses untuk memeriksa apakah mereka berfungsi atau tidak.
Prinsip otomatisasi cepat diketahui oleh semua programmer. Hanya mereka yang mengetahuinya bukan sebagai prinsip, tetapi sebagai kejahatan besar - diyakini bahwa ketidaktahuan, biasa-biasa saja, dan pemula terlibat dalam otomatisasi semacam itu.
Sebagian programmer benar. Tetapi mereka memiliki konteks yang berbeda secara fundamental. Biasanya, bagaimana ini dilakukan? Ada beberapa "curang" - analis bisnis, pengguna, dan pemimpin mereka. Mereka datang dengan sesuatu di sana, dan mereka berkata - jadi, cepat buatkan saya bentuk / bidang / jendela. Apa, bagaimana, mengapa, mengapa - jangan jelaskan. Masih menambahkan - cepat ayo, boot. Apa yang tersisa untuk programmer? Jika ada kesempatan, ia akan mulai mengerut - katakan bahwa itu tidak mungkin sehingga Anda memerlukan tugas teknis, arsitektur yang bijaksana, refactoring, dll. Tetapi, sebagai suatu peraturan, tidak ada kemungkinan untuk menipu, dan programmer hanya melakukannya dengan cepat, "pada lututnya", dalam mode pemrograman ekstrim.
Yah, semacam, dan oke, persetan dengan dia, kan? Saya mengusulkan hal itu - dengan cepat, tanpa masalah, jika saja itu berhasil?
Momen kunci muncul ketika "pengkhianat" melihat tidak ada artinya perubahan. Programmer bisnis hanya membatalkan perubahan tersebut, dan meminta programmer untuk menghapus potongan kode yang diperkenalkan. Bagaimana dengan "penipu"? Atau, lebih tepatnya, "penipu kesedihan"?
Dia tidak akan membatalkan apa pun. Biarkan saja apa adanya, dan, paling banter, terus buat perubahan. Apakah kamu mengerti Tanpa membatalkan yang sebelumnya, itu akan menghasilkan yang baru, lebih dan lebih.
Ada momen politis, terutama jika kepala departemen muncul dengan perubahan. Sangat penting baginya untuk tidak terlihat bodoh, oleh karena itu, tidak peduli apa pun omong kosong yang ia temukan, ia tidak akan membatalkannya. Selain itu, jika Anda mendorongnya ke dinding, itu akan melindungi perubahannya.
Paling sering itu terjadi bahwa tidak ada yang akan menggunakan perubahan yang dilakukan. Jika Anda seorang programmer, maka situasi ini mungkin tidak asing bagi Anda. Mereka bertanya, memerintahkan, menuntut untuk membuat semacam sistem, dan kemudian mereka tidak menggunakannya. Bahkan dapat dilakukan tidak pada "lutut", tetapi biasanya, sesuai dengan semua persyaratan dan kondisi otomatisasi "benar", tetapi mereka tetap tidak menggunakannya. Sekarang kamu tahu kenapa. Dan mengapa tidak ada yang menghapus fungsi ini dari sistem - Anda juga tahu sekarang.
Ini adalah bagaimana lapisan berlapis dari otomatisasi tambal sulam berubah dan tumbuh. Pemrogram tertawa, tetapi melakukan apa yang mereka katakan. Kotoran, non-optimalitas, struktur kurva dan arsitektur tumbuh seperti bola salju. Dan semakin jauh, semakin sulit untuk menghentikan proses ini dan membalikkannya.
Masalah lain adalah tidak masuk akalnya perubahan yang diusulkan secara keseluruhan.
Dalam pemrograman bisnis, setiap perubahan memiliki tujuan yang dipahami semua peserta. Prosesnya harus menjadi lebih cepat, atau lebih dapat diandalkan, atau lebih terkontrol. Oleh karena itu, baik tujuan perubahan maupun kriteria untuk mengevaluasi efektivitasnya selalu jelas.
Tetapi ketika perubahan dibuat "hanya seperti itu", atau "untuk membuatnya lebih nyaman bagi saya", atau "well, sama baiknya!", Tidak mungkin untuk mengevaluasi hasilnya. Oleh karena itu, perubahan, tidak peduli betapa tidak berartinya mereka, tetap hidup - baik dalam proses maupun dalam otomatisasi.
Sekarang Anda mengerti apa masalahnya - kesenjangan antara perubahan proses dan otomatisasi. Ketika beberapa orang muncul dengan perubahan dalam proses, dan kemudian mengatur tugas otomatisasi kepada orang lain, tanpa menjelaskan arti dan esensi, kita mendapatkan kekacauan normal yang tidak menguntungkan siapa pun.
Dengan standar pemrograman bisnis, pekerjaan dilakukan dalam satu tim - ada orang-orang dari proses dan orang-orang dari otomatisasi. Bahkan lebih baik, ketika pekerjaan ini dipimpin oleh satu orang - seorang programmer bisnis. Bahkan lebih baik ketika dia melakukan otomatisasi sendiri.
Dalam hal ini, kami memahami dan mengelola siklus hidup dari perubahan sementara - mengapa mereka dibuat, ketika mereka mulai, dan, yang paling penting, kapan dan dalam kondisi apa mereka berakhir.
Misalkan perubahan itu salah - ini normal, tidak ada yang salah dengan itu. Kemudian para programmer memiliki pekerjaan yang tidak biasa - untuk menghapus perubahan dalam sistem. Tentu saja, mereka terkadang melakukan pekerjaan seperti itu sendiri - refactoring, misalnya. Tetapi dalam kasus pemrograman bisnis, pekerjaan seperti itu harus dilakukan secara berkala.
Dan jika perubahannya benar? Kemudian semua keterampilan otomatisasi "benar" ikut berperan, yang sangat dibanggakan oleh programmer. Anda perlu memperkirakan arsitektur, struktur data, algoritma, verifikasi data yang dimasukkan, antarmuka, dll. Tapi apa bedanya, lihat?
Perbedaan dalam bentuk pernyataan masalah. Biasanya ini adalah tugas teknis, yaitu selembar kertas. Dalam kasus kami, tugasnya adalah prototipe. Seorang pekerja yang telah menunjukkan kegunaan dan keefektifannya, diuji, sehingga untuk berbicara, dalam pertempuran. Anda hanya perlu mengingatnya. Anda tidak benar-benar perlu mengoordinasikan dan mendiskusikan apa pun - ambil saja dan buat sistem sesuai dengan aturan dan standar lingkungan tempat program itu dibuat.
Jika Anda terlibat dalam pemrograman cepat setiap saat, Anda akan dengan cepat memperoleh keterampilan - segera lakukan sehingga Anda dapat memperbaikinya nanti. Di sini "kemalasan yang tepat" dari programmer akan bermain ke tangan kita - dia tidak akan mau menyelesaikan masalah yang sama dua kali, dan dia akan datang dengan cara cepat membuat prototipe dan mengubahnya menjadi solusi lengkap dengan upaya minimal. Meskipun, dalam pemrograman bisnis, tentu saja, tidak ada solusi lengkap.
Sekarang sudah menjadi praktik umum seperti prototyping dan pemodelan, ketika sebelum memulai proyek otomatisasi besar, dengan cepat, dengan upaya minimal, tanpa masalah dengan antarmuka, mereka membuat prototipe tertentu dari sistem masa depan. Seperti yang Anda tahu, ini sangat mirip dengan prinsip otomatisasi cepat, meskipun intinya, tentu saja, bukan bagaimana prototipe itu dibuat, tetapi bagaimana ia akan beradaptasi dengan lingkungan yang berubah.
Jika prototyping hanyalah taktik pemasaran dari perusahaan integrator, dan kemudian muncul secarik kertas besar, seperti tugas teknis, maka ini hanyalah sebuah trik. Ini menciptakan ilusi pelanggan bahwa "semuanya akan seperti yang saya butuhkan," tetapi, sayangnya, itu tidak akan terjadi dalam hidup. Prototipe tidak akan hidup lama dan akan menghilang menjadi tidak jelas.
Dan sekarang Anda mengerti mengapa. Otomasi hampir selalu merupakan kereta, bukan kuda. Kuda itu adalah perubahan dalam proses, dan kereta mengikuti. Namun hanya wahana jika menempel pada kuda.
Kuda itu berbalik, kereta itu mengikuti. Dengan penundaan, dengan serangan balik dan drift, tetapi berbalik. Dan jika masing-masing kuda dan gerobak menjalani hidup mereka sendiri, maka gerobak harus dibawa oleh programmer yang tidak bahagia. Prototipe besar sistem besar yang dibuat sebelum proyek otomasi besar adalah snapshot, snapshot dari kuda yang diikat ke kereta. Semuanya indah, semua orang bahagia, semua orang menyukainya, tetapi satu hari, atau seminggu, atau bahkan sebulan berlalu, dan kuda itu melempar gerobak, dan pergi ke tempat yang diperlukan. Dan gerobak itu indah, anggun, dibuat sesuai dengan semua kanon, ia tetap berdiri sendiri di lapangan.
Karenanya, prototipe "besar" tidak sepadan. Serta otomatisasi "besar". Untuk memulai dan melaksanakan proyek otomasi besar, seseorang harus memiliki pikiran yang luar biasa, pandangan ke depan dan bakat luar biasa dalam manajemen. Jika kata-kata ini tentang Anda, maka saya dengan tulus mengucapkan selamat kepada Anda dan berharap Anda setiap kesuksesan.
Saya merekomendasikan yang lain untuk menggunakan prinsip otomasi cepat.
Dan sekali lagi saya mengingatkan Anda: otomatisasi mengikuti perubahan proses. Tidak sebelum perubahan, bukan perubahan, tidak terpisah dari perubahan. Mereka mengubah proses, dengan cepat terotomatisasi, melihat hasilnya. Bagus - cepat pikirkan. Tidak bagus - buang saja.