Di mana kita mendapatkan botolnya?

Flowcon, atau teknik manajemen Botol, termasuk tugas. Aliran, proyek, pengembangan, fungsi rutin, reguler, dll.

Banyak orang, setelah belajar tentang metodologi dan solusi berdasarkan itu, mengajukan pertanyaan - apa, bagaimana, apa esensinya, berdasarkan apa "praktik dunia" dibuat, metrik apa yang digunakan, kepada siapa itu cocok, dari siapa itu cocok, dari mana asalnya. Saya menjawab masing-masing secara individu, tetapi memutuskan - semuanya, berhenti, lelah menulis hal yang sama seratus kali. Saya seorang programmer, atau siapa? Penggunaan kembali tidak hanya untuk kode, tetapi juga untuk informasi. Saya akan menulis sekali, saya akan mencoba menjawab semua pertanyaan dalam artikel, dan apa pun yang terjadi.

Yang terbaik dari semuanya, menurut saya, hadir dalam bentuk cerita, karena kelahiran botol sangat terkait dengan karier saya, begitulah. Saya akan melakukannya. Dikejar.

PMBOK

Proyek dan teknik manajemen tugas pertama yang saya tahu disebut PMBOK. Itu adalah tahun yang jauh di tahun 2006.

Pada masa itu, PMBOK hampir menjadi monopoli dalam manajemen proyek. Dalam resume dan lowongan, hanya terdengar PMBOK itu. Tidak ada metodologi fleksibel di udara saat itu, meskipun mereka sudah ada di suatu tempat.

PMBOK saat itu merupakan metode manajemen proyek yang murni mengalir, yaitu mengasumsikan struktur panggung dan tugas yang kaku, tenggat waktu, dan dependensi dari awal hingga awal. Dengan demikian, ia dengan cepat dan indah hancur menjadi fragmen-fragmen dalam proyek implementasi 1C pada waktu itu, karena pelanggaran terus-menerus dari aturan segitiga Anggaran-Waktu-Isi yang terkenal.

Pada masa itu, baik pelanggan maupun pelaksana tidak dapat membuat spesifikasi teknis yang masuk akal, menulis persyaratan fungsional, mensimulasikan pekerjaan perusahaan. Ya, dan konfigurasi, seperti SCP, terus-menerus memberikan kejutan - mereka berkembang. Akibatnya, daftar karya yang dikompilasi menjadi tidak relevan di suatu tempat sehari setelah dimulainya proyek.

Tetapi otak para programmer itu ingin tahu, dan mereka datang dengan kombinasi tertentu dari PMBOK dan Agile yang saat itu tidak dikenal. Kami menyebutnya Tepi Kuning. Dan saya juga terpaksa menjadi pembela dirinya.

Tepi Kuning

Tepi kuning didasarkan pada tahapan yang dibuat oleh PMBOK, hanya secara radikal menggantikan tujuan masing-masing. Apa tujuan PMBOK? Selesaikan semua tugas panggung.

The Yellow Edge datang dengan tujuan lain: menandatangani aksinya . Misalnya, ada tahap - "Penerapan akuntansi gudang". Pada tahap merancang dan menyusun TK, karya-karya tertentu muncul di dalamnya, seperti "Laporan materi", "Pelatihan pengguna", "Menetapkan hak akses", dll. - tergantung pada kedalaman studi pada tahap ujian kilat.

Daftar karya ini berfungsi sebagai starter kit untuk memulai dengan sesuatu. Seorang programmer datang ke kepala gudang, atau penjaga toko, atau akuntan materi, mulai berbicara kepada mereka, dan ternyata ... Yah, ada begitu banyak yang harus dipelajari bahwa notebook berakhir dengan kekuatan yang mengerikan.

Pada awalnya otak itu dimanjakan oleh PMBOK berkata: tidak! Itu tidak mungkin! Anda hanya perlu melakukan apa yang tertulis di TK! Dan manajer proyek mengadakan negosiasi negatif yang panjang dengan klien. Seseorang berhasil meyakinkan pelanggan untuk pekerjaan tambahan, tugas teknis tambahan dan sebagainya. Sebagian besar tidak. Pelanggan itu berkata: sial, teman-teman, saya tidak tahu apa itu TK, dan perbaikan apa yang perlu dilakukan dalam program Anda sehingga semuanya bekerja untuk saya, tetapi jika tidak berhasil, saya tidak akan menandatangani akta tersebut .

Realitas, utamanya, menang, dan proyek itu hidup dalam dua dimensi - rencana dan fakta. Tampaknya rencana itu dapat dibuang, tetapi ada hambatan - anggaran telah disusun sesuai dengan itu, yang dilindungi oleh manajer proyek di pihak pelanggan, dan Anda tidak dapat menyentuhnya. Tetapi faktanya tetap - perlu untuk membuat minimum dari apa yang diinginkan pelanggan untuk menandatangani undang-undang, jika tidak maka tidak akan ada pembayaran atau gaji.

Jadi di kepalaku ada model Edge, meskipun berwarna kuning. Botol mulai terbentuk, dan berisi dua praktik manajemen tugas. Tampaknya mereka saling bertentangan, tetapi mereka rukun dalam kehidupan.

INTI PM

Jadi, untuk heap saya akan menyebutkan. Melihat masalah dengan manajemen proyek di antara saya dan kolega, saya mulai memilih teori di luar PMBOK, dan menemukan sebuah buku di toko dengan judul "Manajemen Proyek" yang tidak rumit, yang ditulis oleh keempat Tates. Mereka menamakan metode mereka CORE PM.

Esensinya hampir sama dengan di PMBOK. Invariansi rencana disebut yang utama. Prosedur yang terpisah, besar, kompleks, dan birokratis secara langsung ditemukan, bagaimana membuat perubahan pada rencana.

Pada saat itu, setelah mengenali tepi kuning, saya tidak dapat menambahkan apa pun dari buku ini ke botol saya. Dan ini sangat bagus, karena saya sadari lagi bahwa tidak ada Paman Cerdas di dunia.

Paman pintar

Tentang fakta bahwa tidak ada Paman Cerdas di dunia, saya mengerti sejak lama, di institut, ketika saya menjalani latihan. Kemudian saya menyukai metode statistik manajemen kualitas produk, dan pergi ke pabrik, di mana saya menghabiskan satu bulan mengumpulkan data untuk diploma.

Pada awalnya, tujuannya adalah tepatnya pengumpulan data yang saya dan guru ingin putar dalam perangkat lunak khusus (Statistika?). Tampaknya idenya adalah untuk membangun model matematika dari produksi konveyor untuk memahami pengaruh berbagai tahap pada kualitas produk akhir.

Guru, sebelum perjalanan, memberi saya beberapa buku tentang peta Shekhart, pengendalian proses statistik (SPC), manajemen kualitas umum (TQM). Rupanya, dia sendiri tidak membacanya - kalau tidak, dia tidak akan menawarkan untuk membangun tikar. model produksi. Mereka cocok, misalnya, untuk sensor tekanan, di mana pembangunan model dan analisis regresi Draper adalah dasar kalibrasi, tetapi tidak untuk industri otomotif.

Dan saya membaca buku. Segalanya begitu sederhana di sana sehingga sangat mempesona. Dan pabrik juga memiliki Paman Cerdas dalam layanan manajemen kualitas. Mereka tahu konsep dasar dari buku-buku ini, tetapi, yang sangat mengejutkan saya, mereka tidak pernah menggunakan tidak hanya metode untuk meningkatkan kualitas, tetapi bahkan formula paling sederhana untuk menilai kondisi proses teknis saat ini.

Dan formula itu sangat sederhana. Anda mengambil seratus detail, mengukur, memasukkan angka dalam Excel, menghitung rata-rata, standar deviasi (sigma yang sama), dan menampilkan indikator yang sederhana dan mudah dipahami - indeks kesesuaian, atau indeks reproduksibilitas (jika prosesnya stabil). Sebenarnya, indikator ini dengan jelas mengatakan apakah semuanya normal dengan prosesnya atau tidak.

Ketika saya menghitung angka ini, mereka terkejut. Dan dari kenyataan bahwa mereka akhirnya melihat sosok ini, dan dari betapa mengerikannya itu ternyata. Mereka meminta untuk menghitung beberapa suku cadang dan mesin lagi - tetapi bagaimana dengan saya?

Kemudian ada banyak hal menarik, termasuk upaya sederhana, selama kehadiran saya, untuk secara radikal meningkatkan kualitas produksi. Tapi bukan itu intinya.

Suatu pemikiran kunci datang kepada saya saat itu: Paman yang pandai tahu banyak, tetapi jangan melakukan apa-apa .

Metode-metode tersebut lengkap - baik dalam manajemen kualitas, dan dalam tugas / manajemen proyek, dan dalam manajemen umum. Tanyakan kepada manajer yang efektif - Saya akan memberi Anda ceramah tentang bagaimana dan apa yang harus dilakukan sesuai dengan teknik ini dan itu. Dan tanyakan secara singkat - apakah dia melakukan apa yang tertulis dalam metodologi? Buah ara di sana.

Botol itu diperkaya dengan pengetahuan yang sangat berguna. Semuanya harus dilakukan dan diperiksa sendiri, tidak ada yang bisa dipercaya, terutama mereka yang tidak bisa menunjukkan hasil dalam praktek.

Model manajemen Rusia

Menyadari bahwa saya harus memahami semuanya sendiri, saya memutuskan untuk membaca sesuatu yang lain. Saya ingin tidak belajar teknik baru yang sudah jadi, tetapi untuk memahami sesuatu yang lebih mendasar. Buku "Model Manajemen Rusia" oleh Alexander Prokhorov menarik perhatian saya.

Mengatakan bahwa buku itu brilian adalah tidak mengatakan apa-apa. Anda harus membacanya jika Anda bekerja di Rusia. Untungnya, tidak ada resep siap pakai di sana, tetapi semua alasan dasar mengapa kita memiliki semuanya karena dilukis dengan elegan.

Saya tidak akan melukis untuk waktu yang lama, saya hanya akan menyebutkan beberapa pemikiran utama yang penting dalam konteks materi ini.

Yang pertama adalah bahwa pekerjaan orang Rusia harus diukur sehingga mereka tidak berputar. Karena kita sudah terbiasa menipu sistem apa pun yang kita lakukan secara tidak sadar. Kami tidak menerima aturan, batasan, dan hukum. Lebih tepatnya, kita menganggukkan kepala, setuju, dan diri kita sendiri sudah berpikir bagaimana cara menipu.

Yang kedua - orang Rusia bekerja paling baik dalam apa yang disebut sel klaster yaitu tim kecil tidak dikontrol terlalu ketat. Ruang terbuka bukan untuk kita. Seperti yang Anda pahami, prinsip yang sama tercantum dalam scrum.

Ketiga, orang-orang Rusia tidak melakukan apa-apa seperti yang diperintahkan. Ini adalah ide kunci ketika menerapkan metodologi apa pun. Anda memberikan instruksi tentang cara bertindak, membebaskan orang dan menunggu hasilnya, tetapi ternyata tidak. Karena orang-orang membuang instruksi Anda dan melakukan seperti dulu.

Botol setelah buku ini sangat diperkaya. Benar, metode pemecahan masalah "Rusia" ini harus dicari sendiri. Saya menemukan mengendalikan.

Mengontrol

Mengontrol adalah kontrol berbasis angka. Salah satu teknik favorit saya. Saya menekankan hal utama: mengendalikan bukanlah kontrol. Ini manajemen.

Jika tidak ada angka, kontrol dilakukan secara membabi buta, berdasarkan informasi tidak langsung. Ketika Anda bekerja dengan tugas, ini terutama benar, karena sistem untuk mengukur tugas pada umumnya tidak berharga. Biasanya ini adalah biaya tenaga kerja dalam hitungan jam, tenggat waktu (dan masuk ke dalamnya) dan, pada kenyataannya, potongan tugas diselesaikan. Tidak mungkin mengelola secara efektif berdasarkan data ini.

Bagian pengendalian yang merumuskan persyaratan informasi, yaitu ke angka, metode untuk memperolehnya, kemampuan reproduksi, kualitas, kedalaman studi, dll.

Sosoknya harus berkualitas tinggi, tetapi Anda jarang melihat yang seperti itu. Saya sudah menulis beberapa artikel tentang ini, saya tidak akan mengulangi lagi. Ambillah kata-kata saya untuk itu - Anda tidak akan menemukan angka berkualitas sangat tinggi dengan mengontrol kriteria sangat sering. Mungkin karena tidak ada yang membaca artikel Mengontrol di Wikipedia.

Jadi, kontrol muncul di botol. Ini bersifat universal, dan untuk selanjutnya mengendalikan pembentukan angka apa pun yang diperlukan oleh teknik apa pun.

Manajemen batas

Manajemen batas, atau manajemen perbatasan, adalah sedikit ilmu yang diketahui tentang mengubah sistem bisnis. Meskipun, mungkin, sesuatu telah berubah sekarang - saya mempelajarinya beberapa tahun yang lalu, menurut artikel tentang karya Eric Trist dan orang lain, saya tidak ingat nama belakang. Sekarang Internet mengatakan bahwa ada semacam buku berbahasa Inggris tentang topik ini - saya tidak bisa mengatakan apa-apa, saya belum membacanya.

Intinya sederhana: batas . Di dalam sistem bisnis, proses, bahkan dalam satu orang - banyak batasan. Fisik, emosional, energi, dll.

Perbatasan itu buruk dan baik, bermanfaat dan berbahaya. Beberapa mengganggu proses normal, yang lain membagi aliran campuran menjadi dua bagian, membantu memprosesnya lebih cepat. Beberapa mengisolasi seseorang dari informasi yang diperlukan, sehingga sulit untuk bereaksi dalam waktu, sementara yang lain melindunginya dari informasi yang tidak perlu, memungkinkan Anda untuk tidak terganggu.

Singkatnya, perbatasan dan manajemennya sangat keren. Untuk memahami ini, Anda perlu mencoba. Untuk orang pintar seperti Anda, cukup memahami prinsip utama untuk mulai menerapkannya. Sisanya memerlukan studi kasus dan praktik khusus, dan sebenarnya ada banyak di antaranya. Hanya saja mereka tidak ada di Internet, tetapi kita harus menciptakannya sendiri.

Saya datang dengan beberapa, dari diterbitkan - Gunung Es dan metode jalur renang .

Manajemen batas memiliki pengaruh yang sangat kuat pada botol, dan hampir semua bagiannya - pada manajemen siklus hidup tugas, pada organisasi prioritas, pada manajemen reguler.

Do-it-yourself sih

Dia menyebut bagian ini sama dengan publikasi dengan nama yang sama. Ini adalah pengalaman pertama dalam membangun sistem untuk mengelola pesanan, memo, rencana dan proyek berdasarkan akumulasi pengetahuan.

Pengalamannya agak sukses, walaupun artikelnya terdengar lebih negatif. Ketika membangun sistem, prinsip-prinsip pengendalian, manajemen batas dan Iceberg (dari pemrograman bisnis) terutama digunakan. Tentu saja, itu ternyata terlalu teknokratis, tetapi pengalaman itu, dalam kegunaannya, sangat besar.

Pertama, itu adalah sistem untuk seluruh perusahaan, dan bukan untuk tim kecil programmer. Kedua, sistem mencapai tujuannya - itu meningkatkan disiplin eksekutif ke ketinggian yang sebelumnya belum pernah terjadi sebelumnya.

Tetapi hal utama bagi saya adalah penggunaan praktis bagian-bagian botol dalam skala besar, dan bukan pada programmer, tetapi pada orang biasa. Sesuatu, menurut hasil, harus dikeluarkan dari metodologi, tetapi beberapa metode terbukti efektif. Sebagian besar, tentu saja, mengendalikan.

Pemikiran sistemik

Ini bukan untuk saya, tetapi tentang bidang pengetahuan yang disebut pemikiran sistemik. Penuh dengan buku dan kasing, jadi saya tidak akan menceritakan kembali. Saya perhatikan hanya satu prinsip yang sangat penting, yang sangat memengaruhi botol - sifat muncul atau muncul. Ini adalah sifat apa pun dari sistem yang hanya dapat dilihat pada keadaan aktif.

Saat Anda duduk jauh dari sistem dan berfantasi tentang cara kerjanya, Anda tidak melihat sifat yang muncul. Anda dapat mendesain, menggambar, memprogram, menguji, bahkan di depan umum, tetapi ketika Anda memulai sistem dalam pekerjaan nyata, properti yang muncul akan mulai bekerja.

Anda, misalnya, berasumsi bahwa satu orang mengajukan tugas, dan yang lain berjanji untuk melaksanakannya. Baik, baik. Orang kedua mungkin tidak melihat tugasnya. Dan jika dia melihat, dia tidak akan membaca. Dan jika dia membaca, dia akan mengatakan bahwa dia tidak membaca. Atau tidak mengerti. Atau itu bukan pekerjaannya. Dll

Atau Anda berpikir bahwa dalam tim koordinator adalah bos. Mereka memberinya AWP, dengan daftar tugas masuk yang akan dia bagikan kepada para pemain. Mulai sistem, dan Anda menemukan bahwa dia tidak mendistribusikan apa pun, tetapi hanya berjalan di sekitar pertemuan dan pihak perusahaan. Dan tugas-tugas itu didistribusikan oleh seorang lelaki yang tampak pendiam dan tidak mencolok yang duduk di sudut - seorang pemimpin yang tersembunyi. Dan dia, tersinggung pada kenyataan bahwa dia tidak diperhatikan, juga akan mulai menyabot pelaksanaan sistem Anda.

Ini adalah sifat yang muncul. Mereka tidak terlihat selama desain spekulatif, mereka muncul ketika sistem mulai bekerja.

Jelas bahwa "properti yang muncul" hanyalah sebuah abstraksi sehingga seseorang datang dengan menyebutkan sebuah fenomena yang dapat dimengerti oleh semua orang - Anda perlu memulai sistem, dan sesuatu yang lain akan keluar darinya, dari kesalahan desain arsitektur hingga bug yang sepele.

Tetapi dalam hal manajemen tugas, kami selalu berurusan dengan sistem yang kompleks yang terdiri dari otomatisasi, manajemen, orang-orang dengan hubungan mereka, dan tujuan tim, pelanggan, manajer, dll. Keberhasilan manajemen tugas tergantung pada semua komponen, meskipun pada tingkat yang berbeda-beda, dan tidak satupun dari mereka dapat diabaikan.

Dan jika, misalnya, Anda adalah seorang programmer yang mengotomatiskan manajemen tugas, Anda tidak hanya bisa, tetapi juga akan mengabaikan banyak hal. Lebih mudah. Karena itu, sistem mungkin dan tidak akan berfungsi. Tidak akan ada bug, tetapi juga tidak masuk akal.

Dan saya ingin itu berhasil. Karena itu, saya menambahkan pemikiran sistemik ke botol - baik sebagai salah satu prinsip dasar, dan sebagai aksen dan praktik khusus.

Samurai Codex dan Book of Five Rings

Kedengarannya aneh, tetapi buku-buku inilah yang membuat botol itu menjadi botol. Saya akan jelaskan secara singkat sekarang.

Seorang samurai yang layak dalam kehidupan melakukan ini. Awalnya saya pergi belajar seni bela diri dengan beberapa master. Dia belajar sampai dia melampaui dia. Dan di sini kita memiliki samurai yang baik yang memiliki teknik sekolah tertentu (dengan analogi - PMBOK).

Dia meninggalkan sekolah, dan berjalan pergi di Jepang kuno, mencari tantangan baru. Saya pergi ke sekolah yang berbeda, memanggil master lokal untuk duel, dan membuat keputusan berdasarkan hasil. Jika tuannya lebih lemah dari samurai - yah, bukan nasib. Jika samurai hilang, maka dia berlutut dan meminta untuk membawanya sebagai murid. Dan dia belajar sampai dia kembali unggul master.

Ini berlangsung beberapa kali. Dan pada suatu saat tertentu, samurai memiliki gayanya sendiri.

Secara umum, dia tidak dilahirkan untuk semua orang, ini normal. Beberapa tetap "tanpa wajah", hanya master dari beberapa sekolah terkenal (MBA jenis ini).

Dan beberapa datang dengan gaya mereka sendiri bahkan sebelum memasuki sekolah pertama. Misalnya, salah satu pahlawan nasional Jepang Miyamoto Musashi, penemu gaya dua pedang dan penulis Buku Lima Cincin. Atau Masutatsu Oyama, warga negara Korea, pencipta sekolah karate Kyokushinkai. Yang satu dan yang lain menemukan metode mereka di suatu tempat di awal karier, dan kemudian mengasahnya. Baik itu, dan yang lain dalam perjalanan bertemu dengan tuan yang lebih kuat, dan tetap belajar dari mereka.

Tapi tak satu pun dari mereka meninggalkan peralatan mereka untuk menggantikannya dengan orang asing yang tampak lebih kuat pada saat tertentu. Mereka hanya memperkaya teknik mereka.

Dan, pada akhirnya, seorang samurai yang baik, yang mengalahkan semua orang di dunia, membuka sekolahnya sendiri. Dan samurai lain datang kepadanya, seseorang menang dan pergi, seseorang kalah dan tetap tinggal. Demikian seterusnya ad infinitum. Jadi, Masutatsu Oyama, tidak menemukan lawan di antara orang-orang, mulai, untuk beberapa alasan, untuk membunuh sapi jantan.

Jadi, setelah membaca buku ini, saya lebih dulu mengerti apa yang saya lakukan. Saya, seperti seorang samurai yang baik, mulai dengan sekolah yang berada sangat dekat dengan PMBOK. Kemudian dia mulai menambah sekolah lain. Benar, saya sering membuat kesalahan tidak senonoh untuk seorang samurai yang layak - saya tidak menggabungkan latihan, tetapi menggantikan satu sama lain, dalam mencari peluru perak. PMBOK tidak cocok - kita membuangnya, mengambil INTI PM, itu tidak berhasil - kita membuangnya lagi, melemparkan diri kita ke dalam scrum, dan seterusnya. Oleh karena itu, saya mengubah taktik saya - saya mulai menerapkan praktik baru sebagai percobaan, melihat apa yang terjadi, dan meninggalkan solusi yang paling sukses di dalam botol.

Pemrograman bisnis

Pemrograman bisnis adalah serangkaian metode dan praktik sederhana untuk meningkatkan bisnis. Setidaknya keseluruhan, setidaknya bagian tertentu.

Kebetulan pemrograman bisnis berkembang secara paralel dengan botol, dan objek perbaikan adalah segalanya, kecuali untuk departemen TI asli.

Tetapi, pada saat-saat tertentu, pemahaman tiba-tiba datang. Yah, aku tidak benar. Saya tahu bagaimana meningkatkan proses apa pun, dan saya menyiksa proses asli saya dengan beberapa metode asing.

Secara umum, saya menerapkan pemrograman bisnis, dan untuk pertama kalinya dalam hidup saya, saya menerima peningkatan yang terukur dalam efisiensi programmer, dan segera - dua kali. Perubahan tersebut menyangkut proses, motivasi, tujuan, sistem manajemen, dan otomatisasi. Secara umum, kelima komponen yang bekerja dengan pemrograman bisnis. Kami membangun sendiri pekerjaan kami.

Hasilnya mengesankan saya, dan programmer, dan manajemen, dan spesialis dalam sistem motivasi. Tetapi saya, tidak menjadi samurai yang baik, membuang semua hasil di tempat sampah, karena pada penjualan saya membeli sebuah buku tentang scrum.

Scrum

Ada dua skram di dunia ini - benar dan salah. Yang benar dijelaskan dalam sebuah buku karya Jeff Sutherland. Salah - dalam apa yang disebut panduan scrum, dan penulis masih daftar Jeff Sutherland yang sama.

Scrum yang benar mengatakan: adalah mungkin dan perlu untuk mempercepat pekerjaan sebanyak 4 kali. Yang salah tidak mengatakan apa-apa, hanya memberi Anda beberapa aturan.

Scrum yang benar secara jujur ​​memberikan referensi ke metode manajemen kualitas Jepang, menyebutnya sebagai salah satu dasar filosofi scrum. Secara khusus, ia merekomendasikan menggunakan aturan samurai yang layak - mengambil scrum sebagai dasar, dan membuat teknik Anda sendiri. Scram yang salah mengatakan - lakukan seperti yang kita tulis di sini. Dan jika Anda melakukannya secara berbeda, maka ini bukan scrum.

Secara umum, saya mengambil buku itu dan melakukan segalanya seperti yang tertulis. Papan, stiker, aksi unjuk rasa, retrospektif, dll. Hasilnya memenuhi semua harapan - kami menggandakan kecepatan, yaitu, kami mulai menghasilkan dua kali lebih banyak hasil per unit waktu.

Namun, scrum dalam bentuk murni harus dibuang karena satu alasan sederhana - tim programmer tersebar ke kantor yang berbeda, dan kesempatan untuk menggunakan satu papan hilang. Mereka menderita selama beberapa waktu menggunakan dua papan, tetapi ada juga aksi unjuk rasa, retrospektif yang membutuhkan partisipasi pribadi. Karena itu, scrum ditinggalkan.

Tapi yang terbaik tersisa di botol. Apa yang terbaik dalam scrum? Itu benar, sistem pengukuran tugas adalah perencanaan poker. Tidak ada yang lebih layak untuk mengevaluasi tugas-tugas programmer di dunia kita.

Sistem jam yang digunakan sebelumnya jauh lebih buruk, karena inflasi atau deflasi estimasi terus-menerus muncul. Poin jauh lebih stabil.

Dari elemen scrum yang tersisa dalam botol, mungkin, hanya sprint yang tersisa, sebagai salah satu opsi perencanaan. Siapa pun yang bekerja dengan 1C tahu bahwa sprint adalah perencanaan ruang-kalender yang paling umum, mis. sejumlah produk yang perlu dijual / dibeli / diproduksi untuk jangka waktu tertentu.

Jadi, terima kasih, scrum, untuk semua yang Anda ajarkan kepada kami, tetapi Anda sendiri yang menggali kubur sendiri, dengan panduan scrum Anda. Kami hanya mengambil yang terbaik.

Stream scrum

Kemudian saya memiliki pengalaman seperti menerapkan strategi perusahaan. Pengalaman ini unik untuk seorang programmer - kita dapat mengatakan bahwa saya sangat beruntung. Itu perlu untuk mengubah pekerjaan sebagian besar departemen perusahaan, dan, seperti yang Anda tahu, berbagai metode.

Salah satu unit yang bermasalah adalah pasokan. Saya masih tidak mengerti mengapa ini sangat sulit - fungsinya sederhana. Kemudian saya masih tertarik pada scrum, dan memutuskan untuk menggunakannya untuk pengadaan.

Tetapi dia segera mengalami kontradiksi metodologis. Programmer adalah satu hal - setiap tugas unik di sana, dan cukup layak untuk ditulis pada stiker dan ditangguhkan di papan tulis. Dan apa tugas para pemasok? Beli seratus busing? Dan besok - lagi untuk membeli seratus bushing? Dan lusa?

Singkatnya, stiker bukan itu. Dan diagram pembakarannya bukan itu. Scrum dirancang untuk implementasi proyek, dan apa itu proyek? Ini adalah semacam kegiatan yang suatu hari nanti akan berakhir. Ini harus berakhir, dalam pengertian ini, inilah tujuannya.

Dan di sini - pembelian. Bisakah pembelian berakhir? Ya, hanya dengan perusahaan. Lalu apa pembeliannya? Bukan proyek, tetapi sebuah proses. Tetapi prosesnya adalah kata yang biasa saja, karena itu juga memberikan kelengkapan tertentu, dan ada awal dan akhir untuk itu. Dan di antara mereka - asap, Internet dan komunikasi di dapur.

Bapak Presiden memberikan jawaban ketika dia berbicara tentang pekerjaannya sebagai perdana menteri pada 2008-2012. Dia berkata: untuk menjadi perdana menteri - bagaimana berdiri di bawah air terjun tugas, masalah, dan tujuan yang tak berkesudahan. Pekerjaan tidak pernah berakhir. Berapa banyak yang tidak mencoba, akan selalu ada sesuatu untuk dilakukan.

Apa itu air terjun? Ini adalah aliran. Jadi ide aliran muncul. Terima kasih, Vladimir Vladimirovich.

Karena saya sangat menyukai scrum pada waktu itu, saya tidak ingin menyebut nama ini, dan saya menyebut metodologi rantai pasokan terlebih dahulu “scrum Jerman” (karena sangat terlibat dalam pengendalian, yang lebih disukai orang Jerman daripada yang lain), kemudian - "Kazakh Scrum" (jadi, untuk tawa), dan, akhirnya, "streaming Scrum".

Intinya sederhana.Tugas untuk pemasok selalu datang dari luar - dari kebutuhan penjualan dan produksi. Sistem prioritas untuk tugas-tugas ini sangat sederhana. Dan esensi dari pekerjaan ini bahkan lebih sederhana - dari pagar hingga makan siang.

Ada kebutuhan untuk busing - busing pesanan. Kami membutuhkan baut - yah, Anda tahu apa yang harus dilakukan. Dan seterusnya, hingga tak terbatas. Karena mengalir.

Dan pengendalian, yang telah lama dan tertahan dengan kuat dalam botol, memberikan metrik dan indikator individu yang benar. Dengan cepat menjadi jelas bahwa pemasok lama yang sudah berpengalaman, sayangnya, bekerja jauh lebih buruk daripada "gadis-gadis" yang hanya mengambil dan melakukan, dan tidak berbicara tentang "bagaimana dulu."

Hasilnya menakjubkan dalam kualitas dan kecepatan pencapaian - dalam sebulan mereka mengisi gudang konsinyasi ke tingkat yang sebelumnya tidak dapat dicapai selama tahun-tahun manajemen "biasa".

Nah, di sini, di beberapa titik, saya sadar bahwa tidak ada proyek pada otomasi internal, tetapi ada aliran. Perincian otomatisasi internal ke dalam proyek adalah konvensi yang telah datang sebagai warisan cinta besar 1Snikov terhadap PMBOK. Proyek diperlukan di mana ada uang, jadwal, anggaran, formalitas, dan birokrasi. Jika semua ini dalam otomasi internal, maka jelas sesuatu perlu dilakukan.

Secara umum, aliran dan manajemen mereka dengan kuat memasuki botol. Ke depan, saya akan mengatakan bahwa nama Flowcon berasal dari frase flow control.

Teori Kendala Sistem (CBT)

Teori Goldratt tentang kendala sistem adalah prinsip yang mengatakan bahwa dalam sistem apa pun ada kendala, tautan paling lambat, kecepatannya menentukan kecepatan keseluruhan sistem. Nah, banyak metode berdasarkan prinsip ini telah dikembangkan oleh Goldratt sendiri dan para pengikutnya. Misalnya, teknik Velocity yang dijelaskan dalam buku "The New Goal" melibatkan TOC dan Lean.

Tentu saja, prinsip utama masuk dari CBT ke dalam botol - memahami keberadaan pembatasan, dan cara bekerja dengannya. Saya tidak secara sadar menulis "menghapus batasan", karena CBT tidak hanya melibatkan penghapusan, tetapi juga perlindungan pembatasan, dan terkadang penciptaan buatan mereka.

TOC yang membuat saya melihat tidak hanya pada fase tugas, tetapi juga pada "kit" - apa yang terjadi sebelum dan sesudah pekerjaan pelaksana langsung. Bukan rahasia lagi bahwa seringkali dibutuhkan waktu 15 menit untuk menyelesaikan tugas, dan perlu beberapa hari untuk menerima, mengoordinasikan, menerima hasilnya. Dan selama beberapa hari ini, pelanggan, atau pemrakarsa tugas, sedang menunggu.

Tahapan birokrasi ini, dalam siklus hidup tugas, dapat dianalisis dari berbagai sudut. TOC akan mengatakan bahwa ini adalah keterbatasan karena mereka mengambil yang paling jauh dari kecepatan menghasilkan unit target. Manajemen batas yang sama akan mengatakan bahwa masalahnya adalah adanya batas tambahan, dalam hal ini, antara orang-orang yang terlibat dalam koordinasi. Banyak waktu dihabiskan untuk mengatasi batas-batas ini.

Sudut pandangnya berbeda, tetapi hasilnya adalah satu - tugasnya diselesaikan dengan sangat lama. Dan penyelarasan hanyalah satu contoh. Dan bagaimana dengan pilihan tugas programmer ketika "buletin" terlalu panjang? Apakah ini bukan batasan? Dan bagaimana dengan pilihan yang salah dari seorang eksekutor, ketika tugas-tugas dengan tipe yang sama selalu sampai pada eksekutor yang sama, dan antrian yang sangat panjang dibangun di depannya?

Metode khusus dari TOC juga masuk ke dalam botol, misalnya, menggunakan buffer untuk menentukan kapan tugas harus mulai bekerja jika memiliki tenggat waktu. Tetapi hal utama dalam CBT, tentu saja, adalah prinsip, bukan metode. Goldratt sendiri menulis tentang ini dalam artikel "Berdiri di atas pundak para raksasa."

Berdiri di atas bahu raksasa

Ini adalah artikel yang sangat terkenal oleh Goldratt, di mana ia meletakkan segalanya di tempatnya, termasuk - dengan kata-kata Goldratt yang ia ceritakan siapa samurai yang baik ini. Saya tidak akan menceritakan kembali artikel itu, ini tersedia untuk umum di Internet.

Saya hanya akan memberikan kutipan kunci.

“Ada perbedaan antara solusi yang diterapkan (aplikasi) dan konsep dasar yang menjadi dasar solusi ini. Konsep bersifat umum, solusi yang diterapkan adalah adaptasi konsep ke lingkungan tertentu. Seperti yang telah kita lihat, adaptasi semacam itu tidak sederhana dan membuatnya perlu untuk mengembangkan elemen-elemen tertentu dari solusi. Kita harus ingat - solusi yang diterapkan didasarkan pada premis awal (terkadang tersembunyi) tentang lingkungan tertentu. Anda tidak boleh berharap bahwa solusi aplikasi ini akan bekerja di lingkungan yang premis aslinya tidak benar. "Kami dapat menghemat banyak upaya dan menghindari kekecewaan jika kami dengan hati-hati merumuskan premis-premis awal ini."

Jika dengan kata-kata Anda sendiri, maka Goldratt mengatakan hal yang sama dengan pemikiran samurai dan sistemik: tidak perlu berfantasi, tidak perlu meneriakkan "scrum selamanya" atau "TOS - omong kosong", karena Anda akan selalu salah. Ambil dan coba, dan jangan lupa bahwa tidak ada metode murni yang cocok untuk Anda. Semua sama, Anda harus mengamati, berpikir dan menyesuaikan diri.

Pengamatan

Memperkenalkan botol di tim yang berbeda, saya banyak menonton. Ternyata ini tidak hanya sederhana dan menarik, tetapi juga bermanfaat. Jadi botol itu diperkaya dengan banyak metode, praktik, dan peretasan kehidupan dari penemuan saya sendiri. Sejujurnya saya mengerti bahwa saya tidak menemukan sesuatu yang baru, dan mungkin beberapa metode menggambarkan metode tersebut, tetapi membaca semua buku tidak akan memiliki kehidupan yang cukup.

Sebagai contoh, banyak yang telah ditulis tentang destruktifitas memilih tugas. Dan jika tugas dipilih, tetapi perlu untuk memutuskan bagaimana mengimplementasikannya, maka programmer, misalnya, dapat menghabiskan banyak waktu sampai waktunya tepat, dan dia tidak akan mengambil opsi pertama yang tersedia.

Seperti Maxim Dorofeev, penulis teknik Jedi, menulis dalam gambar yang lucu, apa gunanya menunggu batas waktu dilakukan melalui * opu, jika Anda dapat segera melakukan melalui * opu, tetapi apakah akan ada waktu untuk memperbaiki semuanya?

Saya telah berulang kali melihat, baik dalam diri saya maupun orang lain, bahwa pilihan solusi untuk suatu masalah bisa memakan waktu berhari-hari. Selain itu, opsi dapat sepenuhnya identik dalam kinerja, optimalitas, dan kenyamanan pengguna. Tetapi sesuatu tidak membuat keputusan apa pun, dan hanya itu. Bekerja - selama 15 menit, dan refleksi - seolah-olah Anda sedang membangun roket.

Ada banyak contoh seperti itu, dan semuanya mempengaruhi botol. Dan mereka terus mempengaruhi, karena setelah mengerti bahwa pengamatan saya sendiri tidak lebih buruk dari buku, saya tidak bisa lagi berhenti - tidak ada batas untuk kesempurnaan.

Otomasi Tanpa Batas

Suatu ketika, setelah mengumpulkan semua pengetahuan saya dalam tumpukan, saya membuat versi baru dari sistem manajemen tugas, mulai menerapkan semua pengetahuan tentang botol, dan mendapatkan hasil yang tidak terduga - produktivitas tim pemrogram meningkat 4 kali. Mungkin, hanya yang malas belum menonton video laporan saya tentang topik ini - sekali dan dua kali .

Sebenarnya, pengalaman ini mendorong saya untuk mendistribusikan botol sebagai teknik. Saya mulai mensistematisasikan informasi dan metode, menulis artikel tentang botol dan metodenya, dan berbicara tentang latihan saya.

Pengaturan untuk sistem baru

Setelah pengalaman itu, saya pindah ke perusahaan perangkat lunak murni, dan, tentu saja, melanjutkan praktik menggunakan botol. Tetapi saya menghadapi tantangan yang menarik - saya tidak memiliki sistem manajemen tugas dengan saya, yang saya dapatkan akselerasi 4 kali.

Pertama, saya duduk dan membuat analog yang disederhanakan, dalam 1-2 hari. Saat Anda mengetahui tekniknya, ini bukan masalah, terutama jika Anda tidak harus memilih kenyamanan, antarmuka, dll.

Tetapi saya tidak harus bekerja dengan sistem ini lama, karena perusahaan kami berkomunikasi dengan pelanggan melalui GitHub. Jika Anda tahu, ada juga beberapa jenis manajemen tugas yang disebut Masalah.

Tantangannya menjadi lebih menarik. Ini adalah satu hal untuk membuat sistem sendiri, dari awal, dan itu adalah hal lain untuk mengadaptasi yang sudah ada sehingga memenuhi persyaratan metodologi. Terlepas dari kenyataan bahwa Anda tidak dapat mengubah apa pun di dalamnya, hanya antarmuka standar dan API yang tersedia.

Jadi saya mulai dengan API. Bukan untuk mengatakan bahwa itu benar-benar chic, tetapi memberikan data yang cukup. Masalah pertama ternyata adalah ketidakmungkinan menunjukkan penilaian masalah dalam bentuk angka. Saya harus keluar melalui label (label) - mereka adalah tipe string, tetapi dapat diubah menjadi angka dengan skrip eksternal. Saya menulis skrip ini, dan menggunakannya selama beberapa bulan - ia membuat grafik efektivitas.

Tetapi ada masalah yang tidak bisa saya selesaikan di GitHub. Misalnya, memprioritaskan. Ada tag, ada tonggak sejarah, ada proyek. Secara teoritis, dengan bantuan mereka adalah mungkin untuk mengidentifikasi tugas mana yang lebih penting, tetapi menggunakan informasi ini sangat merepotkan - Anda tidak dapat mengurutkan berdasarkan label. Saya harus membuat skrip lain yang menarik tugas melalui API, mengurutkan dan menampilkan daftar yang benar.

Secara umum, cabang itu ternyata jalan buntu. Saya mencari-cari melalui sistem manajemen tugas online lainnya - masalahnya mirip. Di mana-mana ada kemampuan untuk memasukkan dan menyimpan data, tetapi sangat sedikit alat konfigurasi - yaitu, konfigurasi mengubah data menjadi sistem kontrol. Di mana-mana ada API, dan melaluinya Anda dapat membangun sistem Anda, tetapi kemudian pertanyaannya adalah - mengapa sistem mereka? Sama seperti sumber data?

Dilema ini ada di benak saya selama beberapa bulan. Melakukan atau tidak? Adaptasi teknik ini ke GitHub dengan membuat noda Anda sendiri? Atau ke sistem lain? Dalam bentuknya yang murni, tidak ada yang cocok, tetapi tidak ada yang bisa beradaptasi, dalam waktu yang wajar. Ya, dan gunakan skrip eksternal yang sudah muak.

Namun, terlepas dari dilema, pengalaman itu berhasil. Botol itu bekerja dengan sangat baik untuk dirinya sendiri, meskipun pada sistem yang berumur pendek, dan itu mempercepat kerja - pada awalnya 4 kali, kemudian 6, mencapai 10. Jelas bahwa koefisien tergantung pada titik referensi, tapi saya berhenti mengkhawatirkan hal ini untuk waktu yang lama - saya botol sudah membuktikan segalanya.

Mentransfer ke sistem baru lain

Lalu saya ingat bahwa ada 1C di dunia, dan produk yang luar biasa seperti 1C: Workflow. Jika ada yang tidak tahu, ini adalah program di mana Anda dapat mengkonfigurasi proses apa pun. Dengan demikian, itu tidak mengandung metodologi apa pun dalam dirinya sendiri, hanya teknik, dan seseorang harus mengatakannya teknik.

Di sini, hanya, orang-orang pergi ke konferensi 1Snu berikutnya, dan saya memutuskan untuk berpartisipasi di sana. Saya mengambil standar, kosong 1C: Aliran dokumen, dan mulai mengatur metodologi saya sendiri di dalamnya - botol. Kehormatan dan pujian 1C: Manajemen dokumen - butuh beberapa jam untuk menyiapkan, dan kami mendapat sistem manajemen tugas yang lumayan sesuai dengan botol.

Pada konferensi yang dibicarakannya, orang-orang menyukainya, banyak yang tertarik dengan teknik ini. Benar, ternyata beberapa orang menggunakan 1C: Manajemen dokumen untuk manajemen tugas - ini merupakan kejutan bagi saya. Mereka mengambil beberapa sistem online di mana tidak ada yang dapat dikonfigurasi dengan benar, dan tidak ada metodologi yang dapat dipahami di dalamnya, serta konsep efisiensi. Oh baiklah

Hasilnya masih positif. Dia, ditambah dengan penggunaan tugas di GitHub, menunjukkan bahwa botol itu dapat diintegrasikan sepenuhnya ke dalam sistem lain. Jadi kami mendapat konsultasi, dan beberapa proyek untuk mempercepat tim di sistem mereka sendiri.

Sistem sendiri

Konsultasi tentu saja menyenangkan, tetapi panjang dan mahal. Kebanyakan orang tidak terlalu menyesal untuk membuang sistem manajemen tugas lama mereka, yang tidak banyak berguna. Nah, orang ingin dua dalam satu - dan metodologi, dan program, di mana "semuanya sesuai dengan metodologi."

Oleh karena itu, kami duduk untuk menulis program manajemen tugas kami, jelas diasah di bawah botol. Ada beberapa pengaturan, karena pengaturan dapat mengeluarkan botol dari program, dan ini akan menjadi sistem manajemen tugas berikutnya, lebih seperti notebook.

Menariknya, pengembangan program segera mulai memberikan umpan balik kepada metodologi. Beberapa hal harus dibuang dari botol, beberapa - tambah, sesuatu - berubah. Tentu saja, kami sendiri dengan cepat pindah dari GitHub ke Flowcon.

Dan mengalir lagi

Saya belum pernah menjalankan perusahaan sebelumnya. Sebenarnya, saya masih tidak bisa mengatakan bahwa saya yang bertanggung jawab - ada kita berdua di sini, dan hak dan tanggung jawab dibagi kira-kira setengah. Tetapi kita harus berurusan dengan semua masalah kehidupan perusahaan, dan bukan hanya pengembangan atau implementasi.

Kami memiliki pengembangan perangkat lunak dan layanan, menyelesaikan produk lama, memperkenalkan pelanggan baru, penjualan bersih tanpa layanan, mendukung pelanggan lama, pemasaran, negosiasi, pameran dengan seminar, masalah rumah tangga, seperti uang, dll. Singkatnya, kami adalah perusahaan mini.

Keadaan ini membuat kami mempertimbangkan kembali botol dan memperkenalkan dua entitas baru ke dalamnya - aliran dan keseimbangan.

Setiap jenis aktivitas yang harus saya lakukan adalah streaming. Sebagai contoh, saya perlu memprogram produk baru, dan menyelesaikan masalah pelanggan pada implementasi, dan menulis artikel. Saya adalah orang yang bersemangat, seperti programmer mana pun, jadi tidak begitu sulit, tetapi saya sangat enggan untuk beralih di antara utas-utas ini.

Saya ingin duduk, misalnya, untuk mengembangkan produk baru, dan tidak keluar selama seminggu. Apa yang akan terjadi Tidak akan ada uang, karena iblis tahu produk baru ketika mulai menjual. Kita harus beralih bekerja dengan klien.

Jika Anda terbawa kerja dengan klien, keruntuhan juga akan terjadi, karena membangun bisnis di layanan yang sama cukup berisiko.

Nah, terlibatlah dalam menulis artikel - umumnya hanya meludah. Tetapi kemudian tidak akan ada produk, tidak ada uang. Karena itu, Anda harus menahan diri. Awalnya dia melakukannya dengan firasat, dia sering keliru, dibawa pergi, dan menerima kegagalan. Dan kemudian saya menyadari bahwa ini adalah arus, dan semuanya jatuh ke tempatnya.

Ada aliran yang bisa diukur dan direncanakan. Misalnya, 100 jam sebulan - untuk layanan, 300 poin - untuk pengembangan produk baru, dan di antara - 4 artikel. Setiap aliran memiliki unit dan metode pengukuran sendiri, dan tujuannya sendiri. Dan botol harus menyeimbangkan aliran ini, memastikan pengembangan perusahaan yang seragam.

Tentu saja, tidak ada tiga aliran, tetapi lebih - baik bersama kami dan dengan Anda. Dan perlu untuk menyeimbangkan semuanya bagi mereka yang menginginkan pembangunan berkelanjutan, dibangun di atas strategi, dan bukan pada konteks saat ini dan memadamkan api.

Jadi botol telah berkembang dari teknik manajemen tugas ke teknik manajemen perusahaan. Ya, itu belum berbelok lurus - proses ini masih berlangsung, tetapi hasilnya mengesankan.

Manajemen pengembangan

Sebelumnya, saya tidak harus berurusan dengan pengembangan produk perangkat lunak, kotak, atau layanan penggunaan massal. Karena itu, botol tidak mengandung metode khusus untuk jenis kegiatan ini.

Kesenjangan muncul ketika kami memiliki masalah - kami bekerja banyak dan cepat, dan produk tidak masuk pasar. Seperti yang mereka katakan dalam lelucon tentang scrum, masih harus dipahami omong kosong seperti apa yang kita lakukan dengan kecepatan seperti itu.

Saya harus menyesuaikan botol - untuk memperkenalkan konsep rilis, dan membangun kembali sistem penentuan prioritas berdasarkan pada mereka. Lagi pula, rilis bukanlah proyek, dan bukan tugas, tetapi semacam wadah tugas lain yang perlu dilakukan agar rilis dapat berlangsung. Dan rilisnya, terutama yang pertama, adalah akses ke pasar. Sampai itu terjadi, tidak ada yang akan melihat produk dan, karenanya, tidak akan ada umpan balik atau uang.

Siapa lagi yang lupa?

Saya merasa ini saatnya untuk mengakhiri. Jika Anda membaca ke tempat ini, maka Anda memiliki banyak rasa hormat. Saya belum banyak menulis, tetapi hal utama, seperti, tercermin dalam materi ini.

Masih ada banyak teknik dan praktik yang mempengaruhi botol, tetapi saya tidak akan mencantumkannya. Mungkin suatu hari nanti saya akan melakukan sesuatu seperti glosarium, atau daftar referensi - bagi mereka yang sangat menghormati segala macam pendekatan ilmiah, indeks kutipan, dan "mengandalkan metode yang terkenal di dunia".

Ya, penulis terkasih metode dari mana saya mengambil sesuatu yang berguna untuk botol, tetapi tidak menyebutkan dalam artikel ini, saya minta maaf untuk itu.

Apa hasilnya?

Sebagai hasilnya, kami memiliki botol - campuran eksplosif dari praktik manajemen terbaik yang meningkatkan efisiensi. Dan itu ada persis untuk meningkatkan efisiensi.

Yang penting bagi saya pribadi adalah campuran, set, bukan urutan. Anda dapat menerapkan semua metode, Anda bisa - hanya satu, atau setengah, dari pilihan Anda. Metode apa pun, dengan sendirinya, memberikan peningkatan efisiensi. Satu lagi, yang lain lebih sedikit.

Seperti yang telah disebutkan dalam artikel, selama bertahun-tahun berlatih, saya telah mencoba bagian-bagian dari botol di berbagai perusahaan dan, yang lebih penting, dalam berbagai jenis aktivitas manusia. Ada programmer, insinyur desain, dan layanan berkualitas, dan pasokan, dan penjualan, dan produksi, dan akuntan, dan ekonom, dan manajer, dan siapa yang tahu siapa lagi.

Jelas bahwa setiap profesi membutuhkan serangkaian metode sendiri untuk botol, dan otomasi sendiri. Tetapi Anda dapat memilih kit yang tepat untuk semua orang. Tetapi yang paling penting - botol berkembang, dan dengan kecepatan yang dipercepat. Karena dia melampaui batas praktik saya, dan mulai dengan cepat memperkaya dengan umpan balik dari orang lain, perusahaan, dan profesi.

Bahkan ada orang yang telah mengambil satu atau dua ide dari materi yang diterbitkan, dan mempraktikkannya. Yang sangat menarik adalah bahwa mereka tidak menulis kepada saya tentang hal ini, tetapi jika mereka secara tidak sengaja menyeberang di suatu forum atau konferensi, mereka dengan jujur ​​berbicara tentang pengalaman mereka dan tidak malu untuk mengatakan bahwa mereka mengambil ide dari botol.

Jadi, semuanya akan baik-baik saja.