📭 🕴🏿 ⛹🏿 Artikel non-teknis tentang artikel teknis 🕵🏻 📇 💵

Mereka sering memberi tahu saya - hei, di mana artikel teknisnya? Mengapa Anda menulis segala macam sampah tentang manajer, direktur, hubungan dengan staf, pertengkaran perusahaan, mengeluh tentang tidak ada artinya pekerjaan kami dan secara umum. Kami menginginkan artikel teknis!

Sejujurnya saya tidak mengerti apa itu "artikel teknis". Saya mengerti apa itu "tugas" dan apa "solusi" itu. Saya juga mengerti bahwa solusi untuk masalah yang sama dapat ditemukan di berbagai tingkatan - dari "besi" hingga filosofis. Level mana yang lebih benar - saya tidak tahu.

Untuk memahami, Anda membutuhkan bantuan Anda. Saya memiliki contoh ujung ke ujung yang bagus untuk menyelesaikan satu masalah pada tingkat yang berbeda. Saya segera memperingatkan Anda - sebuah contoh dari lingkup 1C, tetapi otak Anda yang cantik akan memiliki tempat untuk melamar. Mari kita cari tempat untuk "artikel teknis" di rantai ini.

Contohnya adalah kumpulan dari beberapa kisah nyata. Maksud saya, itu diulang beberapa kali, dengan aktor yang berbeda, menyalakan / mematikan tahapan yang berbeda, tetapi intinya sama. Dikejar.

situasi awal

Situasi awal sederhana: perhitungan biaya 1C tidak lengkap.

Bagi mereka yang jauh dari dunia kuning, saya akan jelaskan. Biaya adalah kira-kira operasi yang paling intensif sumber daya yang terjadi di 1C. Itu dilakukan pada akhir bulan, kadang-kadang, dengan cara lama, disebut "penutupan bulan."

Dalam sebulan, yang disebut "Dokumen primer" - penerimaan bahan, transfer antar gudang, rilis produk, penghapusan dari gudang ke produksi, penyesuaian, penerimaan biaya, distribusi, perakitan, dll.

Inti dari semua dokumen adalah sama: sesuatu mengalir di suatu tempat. Dari gudang ke gudang, dari gudang ke produksi, dari produksi ke gudang, dari satu bengkel ke bengkel lain, dari satu nomenklatur ke yang lain. Secara kasar, ada perubahan dalam kondisi persediaan dan biaya. Tidak ada apa-apa - itu menjadi materi. Ada materi - itu menjadi biaya. Itu adalah biaya - itu menjadi produk. Apakah produksi - menjadi materi lagi. Apakah produk - menjadi pendapatan. Itu listrik - itu menjadi biaya. Itu adalah biaya - termasuk dalam biaya produksi. Hanya perubahan dalam keadaan esensi, jika Anda secara abstrak beralasan.

Semuanya dicatat dalam satu bulan dalam satu tabel besar, yang kemudian diproses oleh perhitungan biaya. Dia memiliki dua tugas utama - untuk mengalokasikan biaya dan menyesuaikan biaya. Mendistribusikan biaya - ingin memasukkan semua biaya yang dikeluarkan untuk masalah ini dalam biaya produksi, seperti bahan, listrik, gaji, dll. (sebelum menghitung biaya, ini adalah entri tabel yang berbeda, rilis secara terpisah, biaya terpisah). Nah, untuk menyesuaikan biaya adalah memutuskan SLAE untuk membawa biaya ke strategi penghapusan yang diinginkan (rata-rata atau FIFO).

Jadi, anggaplah semua omong kosong ini tidak berhasil. Kita mulai, tunggu sehari, lalu jatuh. Diketahui bahwa perhitungan dilakukan pada server yang menjalankan Windows Server 2012, dalam satu proses rphost.exe, DBMS - MS SQL.

Tingkat lingkungan

Tingkat pertama adalah murni patsansky. Kami tidak ingin tahu apa pun tentang 1C, kami hanya melihat lingkungan. Apa, secara umum, yang penting bagi kami apa yang 1C malang ini lakukan di sana? Kita sudah tahu bahwa dia melakukan segalanya yang salah, tetapi entah bagaimana kita dapat melakukannya tanpa beralasan.

Bidang untuk eksperimen sangat besar. Serta bahan nyata, tanpa kutipan, artikel teknis.

Mari kita mulai dengan pilihan perangkat keras server. Bagaimanapun, ia mungkin dijemput oleh 1Sniks, yang tidak membatu dalam hal ini. Kami akan menulis tentang efek RAM pada kinerja operasi 1C yang berat, memeriksa hard drive dari berbagai desain fisik, melihat apa yang lebih penting - jumlah prosesor atau inti. Dalam praktik nyata, kami juga akan memesan server baru. Terutama mengingat kemunduran yang dibayarkan oleh penyedia server.

Selanjutnya, mari kita lihat OS. Tidak baik menyimpan server yang layak di bawah Windows? Terlebih lagi, 1C telah lama dapat bekerja di Linux. Dan, akhirnya, clustering didukung dalam 1C, dan kami, secara resmi, dapat memasok dua atau lebih server, bahkan di bawah sistem operasi yang berbeda. Ini akan menjadi ibu untuk artikel ini.

Yah, dan tentu saja, kami tidak akan mem-bypass DBMS. Kenapa semua orang mengalami MS SQL ini? Setidaknya, mari kita lihat Postgre, yang telah didukung 1C selama sekitar 100 tahun, bahkan di bawah Windows. Kami tidak hanya akan mencoba DBMS yang lain, kami juga akan menyesuaikannya sehingga suara itu tetap ada. Benar, banyak artikel telah ditulis tentang topik ini, termasuk Perusahaan 1C itu sendiri, tetapi kami pasti akan menemukan apa yang harus dikatakan dalam artikel teknis kami. Bagaimanapun, menarik untuk membaca pengalaman orang, bukan manual.

Akankah kita memecahkan masalah? Tidak dikecualikan. Praktek menunjukkan bahwa cukup banyak masalah yang diselesaikan pada tingkat ini - terutama, ketika masalah dengan perhitungan biaya, kejadian pertama, yaitu pada saat itu, ketika semua pengaturan baik OS dan DBMS default.

Tetapi kisah kami sedikit berbeda. Semua kemungkinan telah habis, pikiran terbaik kota muncul di server - apalagi, membeli tiga bulan lalu. Kemudian, segera setelah peluncuran, server memecahkan perhitungan biaya hanya dalam 16 jam. Dan sekarang, sayangnya, untuk beberapa alasan, dan untuk sehari tidak dapat mengatasinya.

Harus naik level.

Level 1C

Oke, jatuhkan setrika, naik ke program. Pengukuran kinerja yang sederhana menunjukkan bahwa 1C macet dan macet saat melakukan operasi alokasi biaya.

Sebenarnya, semuanya sederhana. Ada tabel di mana pada saat menghitung 8 juta catatan. Secara kasar, setengah dari mereka adalah biaya, setengah lainnya adalah basis distribusi. Itu Anda harus mengambil babak pertama, dan bergegas ke babak kedua.

Kami duduk dan berpikir - di mana akan jatuh, sayang? Pencarian dangkal, meskipun disertai dengan permintaan konstan ke database dengan penyimpanan hasil antara dalam tabel sementara. Yah, mungkin masalahnya adalah bahwa hasilnya tidak dapat direkam, mis. tambahkan sebanyak 8 juta catatan.

Tidak ada yang rumit, tetapi jatuh. Proses rphost.exe kehilangan sesuatu. Jadi, berhentilah ... Dan mengapa operasi yang begitu sederhana, dan, secara umum, tidak terlalu peka terhadap konteks, merupakan proses tunggal? Siapa yang mencegah membagi tabel menjadi dua, atau bahkan menjadi tiga bagian, dan mengeksekusi secara paralel? Bagaimanapun, 1C cukup mampu memulai setidaknya 20 proses, tetapi untuk beberapa alasan tidak. Jadi mengapa tidak? Atau tidak?

Ya, kami menemukan bahwa versi 1C kami sedikit ketinggalan jaman, dan dalam paralelisasi yang lebih modern dibuat langsung ke pengaturan - seseorang dapat mengetahui sebelumnya berapa banyak benang paralel dari "perhitungan" ini dapat dilakukan. Kekacauan!

Kami menambahkan kode sederhana yang memotong tabel menjadi jumlah bagian yang diperlukan dan menjalankannya secara paralel. Biarkan saya mengingatkan Anda bahwa distribusi beberapa biaya tidak tergantung pada distribusi yang lain, dalam kerangka satu iterasi.

Yo! Menghasilkan! Perhitungan biaya gagal! Namun, terkadang ada kunci untuk menulis - tidak peduli, kami melampirkan tambalan dalam bentuk cache catatan dengan kunci yang dikontrol untuk penempatan selanjutnya dalam tabel utama. Kecantikan! Bekerja!

U, berapa banyak artikel yang bisa ditulis di sini! Teknis! Benar, dengan sedikit warna kuning. Meskipun, di sisi lain, di mana kita tidak menghilang? Apa, di lingkungan pengembangan Anda dan proyek Anda tidak perlu membagi catatan jutaan baris menjadi beberapa bagian sehingga DBMS tidak akan mati?

Segalanya, kemenangan, tampaknya. Tapi ada yang menggerogoti ... Biaya dihitung, tapi masih - terlalu lama. Pada hari yang sama, itu hanya berhenti jatuh - volume catatan belum hilang, kami hanya menulisnya menjadi beberapa bagian, paralel seadanya.

Perayapan lebih tinggi.

Tingkat pengaturan teknis 1C

Menganalisis algoritme, kami memahami bahwa masalahnya tidak hanya dalam jumlah catatan, tetapi juga dalam pemrosesan berganda. Secara teoritis, kami memahami bahwa untuk mendistribusikan 4 juta rekaman ke 4 juta lainnya, cukup untuk memenuhi kueri yang cocok dengan baris oleh analis yang diperlukan, dan kemudian merekam hasilnya.

Dan di sini kita melihat - neraka, dan ada sebuah siklus ... Sebuah siklus yang berjalan sesuai dengan tabel 4 juta baris. Dan ada siklus lain di dalamnya, dengan gangguan tanpa syarat menurut beberapa kondisi aneh. Dan tubuh loop bersarang mengeksekusi lebih dari 4 juta kali. Panekuk…

Melihat-lihat, kami menemukan tabel ketiga, yang menyimpan pengaturan distribusi. Secara kasar, ada perbandingan 4 juta catatan pertama dengan yang kedua. Tapi semuanya diatur di sana tidak ambigu, tetapi dengan penyempitan filter secara bertahap. Pada awalnya ditulis seperti "semua biaya dengan tampilan produksi umum secara kiasan bodoh untuk dirilis", kemudian "Tapi artikel ini juga untuk rilis", lalu "tapi artikel ini adalah keringat untuk departemen ini juga untuk rilis", kemudian ditentukan untuk grup item akuntansi, dll.

Yang terburuk adalah bahwa algoritma tidak menentukan pengaturan distribusi dalam satu pass, tetapi apakah itu secara siklis, secara bertahap mendekati tujuan. Terlepas dari kenyataan bahwa hasilnya, pada akhirnya, sama. Dan, tidak, ini bukan yang terburuk - ada 10 ribu catatan dalam tabel ini. Digerakkan secara eksplisit oleh tangan.

Kami ingat bagaimana akuntan bekerja dengan pengaturan ini. Pemrogram telah mendorong 4 baris ke tabel, dengan filter terluas. Dan para akuntan memiliki sesuatu yang “tidak ditutup” - mereka mampir dan menentukan filter untuk artikel tertentu dan departemen tertentu. Dan mereka melakukannya 10 ribu kali, selama bertahun-tahun.

Hasilnya, 4 juta rekaman kami dijalankan melalui 4 juta rekaman lainnya beberapa kali. Baiklah, kami berguling untuk keberanian dan pergi ke departemen akuntansi. Bukan untuk kepala akuntan - dia mungkin tidak tahu tentang pengaturan ini. Mari kita mulai dengan wakil kepala.

Kami datang, jelaskan arti dari tabel tala ini, dan beri tahu (sekali lagi) bagaimana cara menggunakannya. Kami yakin bahwa semuanya akan baik-baik saja. Kami mendirikan pusat pengujian, melakukan percobaan, setelah mengalahkan 10 ribu catatan, dan voila - perhitungan biayanya hanya 8 jam!

Uh, gay! Sungguh artikel yang keren yang bisa Anda tulis sekarang! Apakah hanya teknis? Yah, saya tidak tahu ... Untuk komunitas kuning tertentu, mungkin ya. Oke, biarlah teknis dan metodologis. Pada saat yang sama, tambahkan beberapa paragraf tentang apa yang akuntan bodoh.

Dan inilah pemikirannya - karena saya berhasil masuk ke akuntansi, mungkin sesuatu yang lain untuk dipilih? Misalnya, untuk memahami mengapa ada 8 juta entri dalam tabel dan yang paling penting, mengapa ada lebih banyak dari itu setiap bulan.

Kami mencoba untuk naik ke level yang lebih tinggi.

Tingkat akuntansi

Jelas bagi kita programmer bahwa jumlah baris dalam tabel ditentukan oleh lebar analitik yang digunakan, dan bukan oleh volume output. Selain itu, kita tahu bahwa output perusahaan asli, seperti lini produknya, tumbuh jauh lebih lambat daripada ukuran tabel kami.

Misalnya, jika divisi kami adalah satu-satunya analisis masalah, maka jumlah baris dalam tabel tidak akan lebih dari 2 * jumlah divisi yang berbeda (setengah untuk rilis, setengah untuk biaya). Perpecahan ini ada bersama kita, dilarang Tuhan, seratus.

Jika kita menambahkan, misalnya, analitik "Item biaya", maka jumlah catatan akan (Jumlah unit) * (Jumlah artikel) + (Jumlah unit), karena paruh kedua tabel (rilis) tidak berisi analitik artikel (sebagai aturan, jika tidak ada transfer produk setengah jadi dari unit ke unit tanpa menggunakan gudang). Hal terburuk dalam persamaan ini adalah *, mis. perkalian. 100 divisi dan 100 artikel - sudah 10 ribu catatan.

Lalu kita kalikan dengan jumlah nomenklatur, karakteristik, pesanan untuk produksi, kelompok nomenklatur, sial ... Jadi itu mendapatkan 8 juta.

Atau tidak mendapatkan? Kami menghitung ulang pada kalkulator - tidak, bukan ara. Lebih tepatnya, bahkan tanpa kalkulator jelas bahwa jumlah catatan tidak boleh tumbuh begitu cepat, dari bulan ke bulan.

Kami memperluas laporan saldo dalam konteks semua analis yang digunakan, dan - bah! - Yah itu, anjing, bodohnya tidak menutup! Biarkan saya menjelaskan apa artinya "menutup" - ini adalah saat saldo rekrutmen analis datang, dan pada akhir bulan dia pergi. Tapi itu tidak menutup - ketika itu tidak tersisa. Dengan demikian, pekerjaan dalam proses terbentuk, dengan kata lain, pekerjaan dalam proses.

Dan itu tidak menutup persis menurut satu analisis - pesanan untuk produksi. Untuk setiap kumpulan produk, dokumen tertentu disiapkan yang memisahkan kumpulan jenis ini dari yang lain. Biaya dikirim ke sana (paruh pertama tabel), output tercermin padanya (paruh kedua tabel), dan semuanya harus ditutup. Tetapi tidak menutup.

Wakil akuntan kepala, yang duduk di dekatnya, juga kaget. Saya tidak tahu bahwa itu tidak menutup - itu ahtung! Mengaduk-aduk, mencari tahu - mereka, akuntan, hanya melihat laporan tanpa memperhitungkan pesanan akun. Semuanya ditutup tanpa analitik ini, tetapi tidak dengan itu.

Dan kuncir kuda ini - jumlah yang tidak tertutup untuk pesanan produksi - juga termasuk dalam 8 juta baris, ini adalah saldo masuk dari awal bulan yang harus ditutup pada bulan berjalan (pada prinsipnya, ini terjadi jika produksi berlangsung beberapa bulan, tetapi tidak kasus kami). Masalahnya adalah bahwa mereka tidak dapat ditutup dengan kami, karena tidak akan ada lagi rilis atas perintah bulan lalu, dan biaya dipaksa untuk menambah keberadaan menyedihkan selama 1 juta tahun lagi, terus-menerus meningkatkan jumlah entri dalam tabel distribusi.

Kami berlari ke basis pengujian kami, menghapus semua ekor, dan - makan kaki Anda! - Catatan dalam perhitungan menjadi 1 juta! Perhitungan sudah pas dalam 2 jam!

Dan kami sudah memiliki antusiasme seorang peneliti - setelah semua, materi seperti itu untuk artikel teknis mematuk! Kami menghapus ekornya, dan bulan ini analitik pesanan masih ada. Oke, Che, basis tes - kami memotong pesanan secara umum, dan meja runtuh menjadi 400 ribu catatan.

Perhitungannya 1 jam. 1 jam, Karl! Kami telah mengurangi waktu perhitungan hingga 24 kali! Baiklah sekarang kita akan menulis artikel tachen, hampir teknis, yang akan Anda unduh!

Benar, itu masih menjelaskan kepada akuntan kepala bahwa analitik pesanan berlebihan. Kami berguling juga merangkak ke lantai dua.

Tingkat Strategi Akuntansi

Kami menghibur diri dengan harapan bahwa semuanya akan berjalan baik. Pada akhirnya, kami telah memecahkan masalah penghitungan biaya produksi - dan bagaimana! Kami berasumsi bahwa kepala akuntan tidak mengetahui sama sekali tentang pengaturan untuk rincian perhitungan, dan seseorang hanya pernah memasukkan analitik pesanan, biarkan seperti itu.

Tapi tidak. Begitu kepala akuntan mendengar "matikan analitik pesanan", dia benar-benar marah. Saya mulai menggerakkan tentang kebutuhan luar biasa bagi perusahaan untuk memiliki gambaran lengkap tentang biaya produksi, dan, yang paling penting, untuk membandingkan angka-angka secara tepat dalam konteks pesanan, dalam satu rekanan, dan bulanan.

Kami mengumpulkan seluruh udara dan mengajukan pertanyaan utama: apakah ini, Marivanna, apakah Anda pernah melakukan analisis seperti itu? Dengan kehendak bebas Anda sendiri, atau atas perintah unit lain?

Nah, selama beberapa menit kita mendengarkan berbagai kata sifat dan kata benda, terutama berasal dari hanya empat kata yang hebat dan kuat. Ingat secara mental alamat situs dengan lowongan. Tetapi kami memutuskan untuk pergi sampai akhir.

Kami tidak membiarkan kepala akuntan selesai, kami mengatakan bahwa ini baik-baik saja, tetapi saya ingin mencari sumber permintaan ini. Akuntan kepala ketakutan dan mengirim ke direktur keuangan, yang adalah bosnya, dan ekonom.

Orang-orang itu lebih sederhana, dan alkohol dalam darah sudah cukup untuk mengobrol dengan mereka. Sementara kita pergi, kita berpikir - apa yang dapat Anda tulis tentang petualangan ini? Tidak ada yang teknis, jelas. Meskipun masalah terlihat dengan mata telanjang. Baik i.e. jelas bahwa pada semua level di bawah ini kami sedang memecahkan masalah yang tidak ada.

Level Permainan Korporat

Dan finder adalah teman kita. Kami banyak membantu dengan bibi yang menyenangkan ini dengan otomatisasi. Oleh karena itu, kami bertanya di dahi - untuk apa akuntansi membuat catatan dengan analisis yang luas? Ya, sangat menyebalkan.

Bibiku segera menempel pada kata "menyebalkan" - apa yang menyebalkan, di mana menyebalkan, apakah itu benar-benar menyebalkan? Ya, kita katakan menyebalkan, benar-benar menyebalkan. Karena itu, departemen TI tidak tidur selama beberapa malam, mencoret-coret banyak artikel teknis dan umumnya terbakar.

Bibi mengambil banteng dengan tanduk dan meminta untuk menyatakan semuanya secara tertulis - apa yang salah, mengapa dan bagaimana saya sampai pada ini. Oke, kami berjanji untuk menyatakannya. Tetapi, sekali lagi, kita pergi sampai akhir. Apa, kita katakan, akuntan kepala terlibat dalam sampah seperti itu, apalagi, dengan kedok seorang pencari, yaitu apakah kamu bibi

Kami mendapat jawaban di dahi - dan biarkan itu menyiksamu, reptil. Nefig cerdas dalam rapat. Mengatakan bahwa tidak ada yang lebih penting daripada akuntansi. Menegaskan bahwa salah jika menugaskan akuntan kepala menjadi bawahan adalah salah. Membawa omong kosong tentang fakta bahwa kepala akuntan adalah orang kedua dalam perusahaan, setelah direktur.

Dan mengapa, katakanlah, jangan memecatnya? Tapi kamu tidak bisa, kata bibi. Yah itu akan terlihat seperti penghapusan keberatan - seperti, bibiku salah, dan segera keluar dari pekerjaan. Lonceng yang tidak menyenangkan akan menjadi untuk direktur. Ini akan mulai mempelajari bagaimana orang menyimpan catatan.

Dan sekarang - lukisan cat minyak. Akuntan kepala tidak mengatasi akuntansi. Letakkan alas di sisinya. Jadi jika itu tidak berguna untuk bisnis, saya tidak akan mengatur akuntansi biaya normal untuk pesanan.

Di antaranya, kami bertanya - dan Anda, bibi, untuk apa akuntansi pesanan ini, dan bahkan dalam akuntansi? Dia menjawab di dahi - dia tidak menggali padaku di mana pun. Baik ekonom maupun pemodal tidak menggunakan angka akuntansi. Hanya dokumen primer.

Eh, bilang begitu? Dan dari mana Anda mendapatkan harga biaya? Nah, Anda tidak bisa menghitung untung tanpanya.

Sami, kata, kami mempertimbangkan biayanya. Dengan menggunakan metode tunai, kami mengumpulkan biaya bahan dengan harga beli, dan mendistribusikannya secara exel, menggunakan metode boiler, menggunakan tingkat konsumsi bahan, disesuaikan dengan fakta hanya dengan jumlah.

Karena, sayangku, tugas kami dalam hal biaya adalah memberikan kepada direktur selembar format A4 yang disebut "Pernyataan Untung dan Rugi", di mana semua biaya dibagi menjadi sepuluh kelompok yang berkorelasi buruk dengan item-item akuntansi biaya.

Secara kasar, segala sesuatu yang dilakukan akuntansi tidak perlu bagi siapa pun kecuali akuntansi. Dan akuntansi, akuntansi biaya diperlukan dalam analitik yang sangat singkat - bahkan yang ada dalam akun akuntansi. Dan di sana, Tuhan melarang, jika tiga analis diketik.

Kami meninggalkan kantor pencari dengan perasaan campur aduk. Di satu sisi, tampaknya, mereka menemukan segalanya - tidak perlu menyelesaikan masalah sama sekali, dan masalah menghitung harga biaya akan hilang selamanya. Di sisi lain, mereka tertarik dengan permainan perusahaan.

Sekarang bagaimana. Anda akan menulis selembar kertas tentang akuntan kepala - Anda akan menjadi musuh mereka selamanya. Jika Anda tidak menulis, Anda akan kehilangan persahabatan dengan pencari, dan Anda tidak akan cocok dengan orang tuli. Dia tidak akan mempercayainya, jika Anda menceritakan sebuah kisah seperti, "Saya diminta untuk meneteskan cairan pada Anda, tetapi saya menolak."

Dan tidak ada yang menulis artikel teknis tentang. Umumnya. Meskipun, Anda sudah mengerti bahwa untuk menyelesaikan semua masalah di tingkat bawah bukan berarti tidak berguna - itu berbahaya. Lagi pula, semua usaha dan uang (ingat server baru yang baru saja dibeli?) Tidak pergi untuk kepentingan perusahaan, tetapi untuk kepentingan satu bibi yang berteman dengan yang lain.

Moodnya kotor, dan kemudian sutradara menangkap pandangan saya. Lebih tepatnya, kita menangkap matanya. Pria itu baik-baik saja, melihat suasana hati yang buruk, dan segera menelepon ke kantornya.

Kami naik ke level yang lebih tinggi.

Tingkat burung

Kami memutuskan untuk menceritakan semuanya. Dari atas ke bawah, tanpa hiasan. Tentang semua orang. Tidak ada ruginya.

Dan tentang server untuk 1 juta rubel, yang sekarang tidak diperlukan. Dan tentang staf akuntan yang membengkak, yang diperlukan untuk mempertahankan akuntansi yang begitu rumit, yang, ternyata, tidak ada yang perlu. Dan tentang staf programer yang membengkak, yang dibutuhkan hanya untuk menemani akuntansi yang gila. Dan tentang bibi-pencari, yang memainkan permainannya dengan mengorbankan perusahaan.

Direktur mendengarkan dengan penuh perhatian, kadang-kadang mengajukan pertanyaan yang bersifat teknis dan metodologis. Dia langsung meresapi seperti itu, dengan cepat dia menyadari bahwa dia pernah bekerja sebagai programmer.

Dan dia menulis semua angka di selembar kertas.

Kami mencurahkan seluruh jiwa programmer. Tentang fakta bahwa kita dilahirkan untuk menyelesaikan masalah teknis, dan tidak berpartisipasi dalam permainan perusahaan. Tentang fakta bahwa tingkat teknis dari solusi harus menjadi yang terakhir, ketika semua metode lain telah habis - organisasi, metodologis, strategis, dan apa lagi yang ada. Tentang sifat kreatif, pemikiran abstrak, introvert, dan kisah pemrograman lainnya.

Dan dalam perjalanan, kami pikir artikel yang keren itu apa. Hanya tidak teknis. Dan di mana menempatkannya? Juga masalah. Berpura-pura dalam artikel bahwa semuanya diputuskan pada tingkat teknis, dan terbatas pada itu? Tapi itu tidak benar. Tetapi jika Anda mengatakan bahwa Anda telah mencapai direktur, mereka tidak akan percaya. Tempat programmer di pabrik dekat ember, permisi.

Direktur dengan sopan mendengarkan sampai akhir, kemudian menarik garis di bawah angka-angkanya, dan memberi: sobat, Anda telah mengungkapkan masalah yang menghabiskan biaya 1 juta rubel per bulan. Terima kasih banyak. Benar seperti itu, tanpa tanda seru.

Sekarang, katanya, itu akan terjadi. Kami memulai proyek membawa akuntansi ke dalam urutan. Anda akan menjadi pemimpin. Saya memecat CIO, Anda menggantikannya. Saya akan menginstruksikan layanan keamanan untuk memeriksa apakah dia menerima suap untuk pembelian peralatan.

Saya menantikan rencana yang jelas untuk akuntansi, dan akuntansi, dan manajemen. Sehingga semuanya indah dan saling berhubungan, tetapi hanya dalam analitik yang tepat. Anda akan mengimplementasikan rencana ini. Setiap perubahan dalam akuntansi sekarang akan diterapkan hanya setelah persetujuan Anda.

Dalam hal akuntansi harus dilakukan perhitungan jumlah spesialis yang diperlukan. Ekstra - kita akan menembak tanpa mengolesi ingus. Segera pikirkan tentang bagaimana Anda dapat mengotomatiskan kegiatan yang tersisa - mungkin ada terlalu banyak, jika Anda melakukan pendekatan dengan bijak.

Jangan sombong, kawan. Anda bekerja untuk saya sekarang. Anda akan menjadi mata dan otak teknis saya. Tidak ada permainan - tidak dengan saya, atau dengan orang lain.

Kami pergi, dengan kaki terhuyung-huyung, dan merangkak ke ruang bawah tanah kami. Kepalanya berputar - entah dari kebahagiaan, atau dari ketakutan. Saya ingin melarikan diri, seolah-olah dari mimpi yang aneh, hanya untuk kembali ke kenyataan saya yang biasa. Benarkah begitu?

Tidak, tidak. Mereka tidak akan percaya. Dan Anda tidak akan menulis artikel tentang itu. Mereka akan mematuk, mematuk dan mengirim artikel ke Cosmopolitan untuk menulis tentang IT Cinderella. Dan dia tidak akan percaya itu. Lebih tepatnya, saya akan mengatakan bahwa saya tidak percaya, hanya saja tidak mengakui bahwa saya takut untuk keluar dari lubang saya dan bertanya, "haruskah saya bercinta dengan omong kosong ini?" Meskipun pada tingkat teknis yang brilian.

Sebenarnya pertanyaannya

Di mana level teknis di sini? Apa yang menarik dan bermanfaat tentang menulis dan membaca artikel teknis? Ini adalah contoh langsung.

Artikel non-teknis tentang artikel teknis