Programmer tidak menyelesaikan masalah bisnis. Mereka membuat dan meningkatkan produk perangkat lunak sesuai dengan spesifikasi teknis pelanggan. Meyakinkan semua orang, dan dirinya sendiri, termasuk bahwa ini adalah solusi untuk masalah bisnis.
Ketika Anda tiba di layanan mobil, apakah Anda menulis TK? Tentu saja, banyak dari Anda yang berpengalaman dalam mobil, dan di antara teman-teman saya ada orang-orang yang dapat dengan mudah membongkar dan merakit kembali gearbox. Tetapi, bagaimanapun, sebagian besar dari kita mengatur tugas dalam bentuk "sesuatu mengetuk ketika saya mengemudi lebih cepat dari 40 km / jam" atau "bertiup buruk dari deflektor, mungkin AC, atau, saya tidak tahu apa yang ada di sana".
Jika seorang master dalam layanan mobil mengatakan sesuatu seperti "katakan secara spesifik apa yang perlu dilakukan dengan mesin Anda" untuk pertanyaan seperti itu, apakah Anda akan terus menggunakan layanannya? Saya kira tidak. Sebagian besar dari kita tidak membeli mobil untuk memahaminya, dan tidak hanya pirang dari lelucon, atau Rusia baru yang (dalam lelucon yang sama) mengubah mobil mereka ketika asbak penuh, lakukan saja.
Dalam bekerja dengan programmer, bisnis tidak punya pilihan. Dan semakin jauh, semakin buruk. Para pengrajin yang antusias belum diterjemahkan untuk siapa mereka bisa menyelesaikan masalah sendirian, tetapi pembagian kerja umum dan dominasi pendekatan hukum-birokrasi terhadap bisnis dengan cepat dan andal membunuh antusiasme semacam itu.
Jika Anda berpikir tentang bagaimana perwakilan bisnis dapat - direktur, kepala departemen, penjual, akuntan, dll. - menyusun tugas teknis untuk pengembangan produk perangkat lunak? Jelas bahwa beberapa dokumen akan dilahirkan bersama, tetapi apa kualitasnya? Bahkan jika Anda memiliki arsitek cerdas yang dapat menganalisis persyaratan bisnis dan menerjemahkannya ke dalam bahasa pemrogram, dapatkah Anda yakin bahwa mereka memahami dengan benar kebutuhan bisnis apa?
Persyaratan yang disuarakan oleh bisnis jelas baginya. Kerangka acuan, yang ditulis oleh programmer untuk persyaratan bisnis, tidak lagi dipahami olehnya. Bisnis hanya percaya programmer bahwa perbaikan yang direncanakan akan menyelesaikan masalahnya.
Anda juga percaya master dalam layanan mobil, ketika dia mengatakan "Anda perlu mengisi AC dan mengganti filter di kabin, dan itu akan meledak secara normal." Tetapi dalam kasus layanan mobil, risikonya rendah - beberapa jam waktu dan beberapa ribu rubel, dan hasilnya akan segera terlihat.
Dalam kasus programmer, risikonya selalu lebih tinggi - persyaratannya lebih lama dan anggaran lebih gemuk. Dan apa pun hasilnya, bisnis harus menerimanya, karena dalam banyak kasus tidak hanya membayar pengembangan, tetapi juga implementasi. Hasil kerja programmer pada saat penerimaan sudah duduk di dalam bisnis, dan tidak dapat dibuang tanpa rasa sakit.
Akan sangat bagus, tentu saja, jika para programmer membuat sistem robek yang akan dilihat oleh bisnis dari samping dan memutuskan apakah akan menerimanya atau tidak. Dalam hal ini, semua risiko ada pada programmer. Tapi ini jarang terjadi, karena programmer juga punya bisnis, apa pun yang dikatakan orang.
Bisnis harus menerima pekerjaan, dengan satu atau lain cara. Dengan pemesanan, dengan daftar persyaratan tambahan, tetapi terima. Dan gunakan itu.
Hambatan bahasa
Ada batas antara bisnis dan programmer - hambatan bahasa. Bisnis tidak mengerti bahasa sistem informasi, programmer tidak mengerti bahasa bisnis. Agar entah bagaimana ada, dan setidaknya untuk melakukan sesuatu, kedua belah pihak menciptakan bahasa pengganti - semacam analog Esperanto yang sama-sama dimengerti dan tidak dapat dipahami oleh kedua belah pihak.
Esperanto, secara umum, tidak buruk, tetapi sangat buruk - ia memiliki kosakata yang sangat kecil, yaitu kosakata. Sebuah bisnis dapat mengatakan dalam Esperanto: "Saya ingin formulir ini sehingga ada dua tombol, sebuah meja dengan barang, itu berisi barang dan harga", atau "Saya ingin laporan yang menunjukkan piutang yang telah jatuh tempo". Istilah "piutang jatuh tempo" dalam bahasa Esperanto tidak diungkapkan dengan baik, sehingga programmer akan mengajukan beberapa pertanyaan klarifikasi untuk menerjemahkan tugas menjadi tugas mereka sendiri, Klingon.
Bisnis tidak dapat mengungkapkan semua kebutuhannya di Esperanto, hanya seperangkat yang sangat sedikit. Tidak mungkin untuk mengatur tugas bagi programmer untuk "mengoptimalkan akuntansi sehingga dua akuntan dapat dipecat" atau "membuatnya sehingga tidak ada kekurangan". Esperanto, sebagai pintu gerbang komunikasi Anda, tidak akan dapat menyampaikan arti tugas-tugas ini kepada Klingon.
Meskipun, kita semua tahu contoh ketika tugas serupa diselesaikan dengan otomatisasi. Jadi, pada prinsipnya, bahasa Klingon mampu mengekspresikan konstruksi kompleks seperti itu. Tetapi bagaimana cara kerjanya?
Jarang, tetapi itu juga terjadi - seorang perwakilan bisnis mengenal Klingon. Pertama, dia mungkin mantan programmer. Saya, dan Anda juga, telah bertemu orang-orang seperti itu di berbagai posisi - kepala akuntan, direktur keuangan, manajer, penjual, dan pemasok bahkan pernah bertemu. Kedua, ada orang - terutama direktur dan pemilik usaha kecil, yang, karena keingintahuan alami, telah menggali dan terus mengembangkan pengetahuan mereka di bidang teknologi informasi. Tapi ini agaknya pengecualian.
Aturannya adalah menerjemahkan "puisi tinggi" persyaratan bisnis ke dalam bahasa primitif - formulir, laporan, proses, dokumen, direktori, register, layanan web, halaman, dll.
Saya harus segera mengatakan bahwa saya sama sekali tidak mengurangi keindahan Klingon. Bahkan ada lebih banyak puisi dan keindahan di dalamnya daripada dalam, katakanlah, bahasa bisnis elf. Tetapi puisi tidak melewati gerbang, hanya primitif.
Untuk bersenang-senang, coba terjemahkan google translate ke dalam puisi bahasa Inggris, misalnya, seperti ini:
Badai menutupi langit dalam kegelapan
Snow whirling whirling.
Cara dia menaklukkan binatang itu
Itu akan menangis seperti anak kecil.
Apa yang akan terjadi
Kegelapan badai menutupi langit,
Angin puyuh berputar.
Lalu saat dia menyesali binatang itu,
Itu akan menangis seperti anak kecil.
Saya tidak tahu bahasa Inggris dengan baik, jadi bagi saya terjemahan ini seperti Klingon. Sepertinya itu benar. Beberapa kata sudah biasa, seperti garis dan koma. Mungkin terjemahannya benar. Bagaimana cara mengeceknya? Mari kita coba kembali, dari bahasa Inggris ke bahasa Rusia:
Kegelapan badai menutupi langit
Pusaran berputar.
Kemudian, ketika dia berduka atas binatang itu,
Itu akan menangis seperti bayi.
Ada yang salah ... Gerbang tidak berfungsi dengan baik, meskipun suasana umum sepertinya ditransmisikan dengan benar. Namun dalam detail, pengertian, puisi, teks telah kehilangan hampir segalanya.
Sebuah contoh, tentu saja, dari ranah humor, tetapi dalam bahasa Esperanto kami semuanya terjadi dengan cara yang sama. Semuanya tampak jelas, temanya basi, dan semua orang mengingat gambar indah dari ayunan di atas pohon. Tapi kita hidup entah bagaimana? Apa yang salah, apa yang terlampir?
Konsekuensinya
Konsekuensi dari hambatan bahasa, pada kenyataannya, mengerikan bagi kedua belah pihak. Hampir semua otomatisasi yang sekarang sedang diproduksi adalah hasil dari penerapan primitif, tim dasar, tugas-tugas membosankan dan tujuan kecil.
Tidak ada puisi, karya seni, efek wow dan saling mencintai bisnis dan TI. Berbicara terus terang, tidak ada solusi TI yang benar-benar membantu bisnis.
Ada solusi IT keren, teknologi, kerangka kerja yang awalnya dibuat di Klingon. Tetapi hanya sedikit orang yang berhasil menerjemahkannya ke Elven. Ternyata tipu muslihat manajerial cocok dengan keputusan ini dengan bisnis, tetapi mereka tetap berada di Klingon - kompleks, tidak bisa dipahami, indah, seperti pesawat ruang angkasa dari masa depan. Hanya tidak jelas apa yang harus dilakukan dengan mereka.
Ada juga solusi bisnis keren yang dibuat tanpa menggunakan IT. Ada banyak legenda tentang para manajer yang telah “mengangkat mereka”, “proses yang disederhanakan”, “menciptakan rantai pasokan yang cerdik” di lingkungan bisnis - yang tidak kalah menarik daripada tentang para pengembang teknologi keren di bidang TI. Tetapi di tengah, di perbatasan, dalam persatuan - ada sedikit solusi.
Akibatnya, bisnis tidak puas dengan programmer, meskipun terpaksa menanggungnya sebagai kejahatan yang tak terhindarkan. Lagi pula, ada pembukuan dan akuntansi pajak, dan negara yang membawa semua birokrasi ini perlu. Ada "aturan kekanak-kanakan", seperti kebutuhan untuk memiliki situs web, IP-telephony, publik di jejaring sosial dan akun EDI. Kecil, membosankan, tidak memberikan teknologi apa pun.
Dan para programmer bergerak semakin jauh dari bisnis, menutup dan mempersulit Esperanto yang sudah tidak dapat dipahami. Tuhan melarang, jika Anda memiliki cukup antusiasme untuk ekspresi kreatif di Klingon Anda, sehingga jiwa menemukan setidaknya beberapa jalan keluar, di suatu tempat di antara keduanya. Dan di waktu utama - upaya selanjutnya untuk mengotomatisasi semua omong kosong ini.
Kedua belah pihak menderita, dan kedua belah pihak saling menyalahkan atas ketidakberuntungan mereka. Meskipun, tidak, mereka tidak lagi menyalahkan mereka - mereka sudah terbiasa, entah bagaimana, kurang lebih mengingat Esperanto ini, dan sudah percaya bahwa memang seharusnya begitu. Apakah begitu untuk semua orang? Setelah semuanya, itu berarti bahwa semuanya beres dengan kita. Nah, Anda berkata, ini semua jelas tanpa Anda. Lakukan apa?
Ya, Anda sudah tahu apa yang harus dilakukan. Belajar bahasa. Dan Esperanto yang sempurna.
Belajar bahasa
Agar dua penutur bahasa yang berbeda dapat berbicara secara normal, informatif dan menarik, seseorang perlu tahu dua bahasa - bahasa sendiri dan lawan bicaranya. Pertanyaannya adalah siapa yang harus menjadi yang pertama "bergerak".
Opsi pertama adalah membiarkan bisnis mempelajari Klingon. Bagaimana Anda menyukai opsi ini? Jika Anda seorang programmer, maka Anda mungkin menyukai opsi ini. Meskipun, tidak, itu penuh - jika bisnis memahami teknologi informasi, maka Anda, apa pun yang dikatakan orang, harus bekerja secara nyata. Sekarang, dengan satu atau lain cara, Anda bisa bersembunyi - dan peluang, dan solusi, dan tiang tembok.
Tetapi opsi ini, murni dalam hal efisiensi, tidak cocok. Terlalu banyak belajar. Jika Anda, sekali lagi, adalah seorang programmer, Anda akan setuju: bahkan Anda, apa pun yang Anda pikirkan tentang diri Anda, hanya tahu sebagian kecil tentang IT. Hanya saja pengetahuan di bidang teknologi informasi dilahirkan lebih cepat daripada yang dapat dicerna seseorang, tidak peduli berapa banyak bentang di dahinya yang dia miliki.
Anda dapat mengatakan - oke, bahkan jika bisnisnya tidak mengetahui detailnya, tetapi bisakah ia mencapai puncaknya? Dan menjaga relevansi pengetahuan ini. Mungkin, tentu saja, hanya Esperanto yang sama. Ini sudah kami lewati.
Jauh lebih mudah untuk melakukan yang sebaliknya - seorang programmer untuk mempelajari bahasa bisnis.
Saya menyebut bahasa bisnis Peri, meskipun saya harus, pada kenyataannya, menyebutnya bahasa Yunani, karena itu adalah bahasa mati yang sulit berkembang. Oke, biarlah elf - apakah orang-orang ini berlayar jauh dari Dunia Tengah dulu?
Segala sesuatu, atau hampir semua yang berguna dalam bahasa bisnis, telah lama ditemukan. Tentu saja, jenis bisnis baru, cara interaksi baru, produk baru, atau bahkan kelas produk muncul, tetapi konsep dasar tetap ada.
Pertama-tama, ini adalah proses. Segala sesuatu yang perlu Anda ketahui tentang proses telah lama ditemukan - kembali pada abad kedua puluh. Semua teknik modern, dan tidak demikian - misalnya, teori pembatasan, pengendalian, Lean, Scrum, dll. - ini hanya variasi, proses templat, atau pola untuk menggambar proses baru. Pada dasarnya, esensi proses tidak berubah - tindakan, kondisi, subproses. Ngomong-ngomong, semua ini adalah konsep yang dipahami dengan baik oleh programmer.
Setiap matematika bisnis juga diserap oleh programmer. Akuntansi, manajemen, akuntansi internasional dan pajak, laba rugi, arus keuangan, metode berbeda dalam menilai keadaan bisnis hanyalah formula yang berbeda yang mempertimbangkan angka yang sama berdasarkan angka lainnya.
Sistem manajemen, sebagai subkelas dari proses, juga tidak mewakili sesuatu yang rumit. Selain itu, bisnis dalam sistem manajemen itu sendiri tidak terlalu berpengalaman. Ini mudah diverifikasi - cobalah untuk menemukan setidaknya satu proses manajemen di perusahaan Anda. Tentu saja, jika Anda menerapkan ISO, artinya ada proses seperti itu - "Manajemen Organisasi", tetapi kami tidak akan mempertimbangkannya, itu hanya selembar kertas birokratis. Temukan instruksi untuk pemimpin, yang mengatakan apa, kapan dan bagaimana yang harus dia lakukan. Mereka tidak, karena penciptaan sistem kontrol adalah area yang relatif baru yang tidak akan keluar dari perut manajemen, karena itu juga akan menghancurkannya.
Sekilas, bidang yang lebih spesifik adalah sistem motivasi. Tetapi, pada kenyataannya, ini adalah salah satu bidang pengetahuan paling sederhana dalam bisnis. Ada beberapa pilihan templat yang gagal mencoba menanamkan SDM di semua perusahaan, tidak memahami esensi motivasi.
Dalam bisnis, tentu saja, tidak hanya ada bidang pengetahuan yang terdaftar. Misalnya, ada pasar, produk, pemasaran, merger dan akuisisi, IPO, dll. Pengetahuan ini dapat dengan aman diserahkan kepada bisnis, dan tidak untuk mempelajari bagian-bagian yang relevan dari bahasa elf. Setidaknya sampai Anda memutuskan untuk membuat bisnis sendiri.
Mengapa
Ada dua pertanyaan sekaligus: mengapa ini untuk bisnis dan mengapa untuk programmer.
Dengan bisnis jelas. Ini adalah kebutuhan vital. Dunia IT sedang bergerak ke arah model seperti itu - integrasi kompetensi, karena jika tidak, percakapan para tuna rungu dengan tuna netra akan berlanjut tanpa batas waktu.
Bisnis sering memahami masalahnya, tetapi tidak tahu solusinya, tidak melihatnya. Sekarang tahu dan lihat. Tetap hanya mengatur proses ini dengan benar - melatih programmer dalam bahasa Elf. Anda bisa melakukannya sendiri, hanya akan ada sedikit akal. Untuk mengajar Klingon Elven, Anda perlu tahu kedua bahasa, tetapi ini tidak. Meskipun, entah bagaimana Tarzan diajari. Jika Anda ingat, baca dalam bahasa Inggris, dan berbicara dalam bahasa Prancis.
Mengapa ini untuk programmer? Nah, pertama, jika bisnis tempat para programmer duduk dengan kompeten mengambil masalah, maka mereka tidak punya tempat untuk pergi. Kecuali, pergi ke pekerjaan lain, di mana mereka belum mendengar tentang tren ketinggalan jaman baru.
Tetapi Anda dapat mengatur ulang awal proaktif di departemen TI. Tidak ada yang melarang programmer untuk mengembangkan kompetensi di bidang terkait? Misalnya, pelajari elf. Dan kemudian, di antara, menyatakan, dan lebih baik untuk menunjukkan dalam mempraktikkan keterampilan baru mereka. Bisnis, menghargai manfaatnya, akan menjadikan pemrogram bilingual sebagai standar di perusahaan mereka. Pada saat yang sama, dan akan mengusir para penerjemah kesedihan, seperti analis bisnis.
Anda hanya perlu memahami bahwa otomatisasi bisnis sekarang, di Esperanto, hanyalah gelembung sabun. Dan itu akan meledak hanya di satu sisi - di mana perwakilan penting dari bahasa Klingon duduk. Bisnis tidak ke mana-mana, dia hidup selama berabad-abad dan akan terus hidup. Pada skala sejarah bisnis, hanya ada segmen kecil yang disebut "antusiasme untuk teknologi informasi" yang mulai menyenangkan dan menarik, dan berubah menjadi penipuan global.
Cepat atau lambat, bisnis akan menemukan jalan keluar. Lebih baik baginya untuk menyarankan jalan keluar ini - bermanfaat bagi elf dan Klingon.
Latihan
Anda, dalam hal artikel, kemungkinan besar berbicara bahasa Klingon. Saya akan mencoba menulis beberapa frasa di Elven, dan jika Anda mau, berlatih terjemahannya - baik dalam bahasa Klingon, atau setidaknya dalam bahasa Elf.
"Saya ingin tahu bagaimana otomatisasi memengaruhi perubahan dalam bisnis saya."
"Apa yang bisa diotomatisasi untuk mengurangi jumlah akuntan?"
"Apakah mungkin untuk membubarkan semua manajer yang tidak menjual apa pun, tetapi hanya mengarahkan pesanan dari selembar kertas?"
"Bisakah kamu entah bagaimana membuatnya sehingga tidak ada defisit?"
"Bagaimana cara menyingkirkan departemen dealer, yang hanya berurusan dengan itu, yang mengatur interaksi dengan mitra?"
"Bisakah sesuatu dilakukan dengan kesenjangan uang tunai?"
“Bagaimana saya meningkatkan kualitas produksi? Sekarang ini hanya bencana. "
“Saya sangat marah dengan semua ekonom yang menyiapkan laporan untuk saya. Bisakah Anda entah bagaimana menyingkirkannya tanpa kehilangan laporan ini? ”
“Dan berapa biaya akuntansi saya? Setidaknya untuk mengetahui nomornya, saya tidak berbicara tentang optimasi ... ".
“Bagaimana saya memastikan bahwa saya, dan para pemimpin lainnya, belajar tentang masalah sebelumnya? Sehingga Anda dapat merespons tepat waktu. "
Bisakah Anda menerjemahkan?