🔊 ⭐️ 👿 Bagaimana membuat tetangga bekerja di proyek mereka, atau InnerSource untuk bank 🐮 💆🏿 🕴️

Apa pengembangan di Sber? Di mata seorang spesialis TI biasa: "Di sinilah kode itu ditulis, pergi ke sana!" Tapi ini sudah lama menjadi stereotip, dan itu tidak baik. Perkembangan open source yang cepat membuktikan bahwa budaya seperti itu telah lama menjadi usang, dan perusahaan (jika cerdas) telah lama merevisi pendekatan berbasis silo untuk pembangunan. Mempublikasikan semua perangkat lunak perbankan dalam open source adalah cara yang ~~efektif untuk bunuh diri,~~ keputusan yang agak kontroversial, dan semacam tahap perantara diperlukan. Dengan skala bank, kita dapat meluncurkan open source internal kita, daripada mencoba untuk memeriksa apa yang bisa kita tunjukkan kepada semua orang dan mengguncang ketakutan akan rahasia besar kecil kita.

Apa itu InnerSource?

Pada tahun 2000, Tim O'Reilly menggambarkan istilah sumber dalam sebagai langkah yang mungkin menuju perusahaan tertutup memasuki dunia open source yang indah. Ini adalah penerapan praktik terbaik dari sumber terbuka dalam korporasi: dari keterbukaan umum dan bantuan timbal balik proaktif hingga pembentukan pasar untuk solusi terbaik. Perusahaan terus menulis kode hak milik, tetapi setiap karyawannya memiliki kesempatan untuk memperbaiki sistem internal apa pun.

Kelebihan InnerSource dapat didaftarkan untuk waktu yang lama: mengurangi waktu ke pasar, meningkatkan kualitas kode, mengganti perekrutan eksternal dengan internal, meningkatkan interaksi lintas tim, dan sebagainya.

Kesulitannya terletak pada kenyataan bahwa segala sesuatu yang dijelaskan di atas memerlukan perubahan dalam budaya komunikasi antara karyawan dan tim, dan ini tidak begitu mudah dilakukan dalam organisasi yang telah bekerja secara berbeda selama beberapa dekade.

Tentu saja, Sberbank bukan satu-satunya perusahaan yang pernah melakukan hal seperti ini. Pada 2015, komunitas InnerSource Commons dibuat , yang mempopulerkan pendekatan dan menghilangkan kesenjangan dari istilah untuk membuatnya lebih mudah ditemukan di mesin pencari. Komunitas ini telah mengumpulkan pengalaman puluhan perusahaan dan membuat rekomendasi yang efektif untuk mengimplementasikan InnerSource di perusahaan Anda, dan mengadakan konferensi pertukaran pengalaman dua kali setahun. Masih banyak perusahaan teknologi terkenal yang telah melakukan ini ~~sejak Pechenegs dan Polovtsy~~ sebelum menjadi arus utama.

Di Rusia, sejauh yang kami tahu, hanya satu pengecer besar di pasar jasa konstruksi dengan logo hijau yang secara aktif terlibat dalam implementasi sengaja dari InnerSource, perusahaan lain tidak mengiklankan pengalaman mereka atau tidak berpartisipasi dalam komunitas.

Masing-masing perusahaan memiliki pengalaman positif dan negatif sendiri. Kesimpulan keseluruhan dalam kasus ini sangat mirip: manfaat yang paling lezat hanya dapat diperoleh dengan partisipasi mayoritas.

Mengapa saya mengumpulkannya?

Hampir setiap percakapan tentang pengembangan di Sberbank datang ke pertanyaan "berapa banyak programmer yang Anda miliki di sana?". Di seluruh negeri, kami memiliki lebih dari sepuluh ribu di antaranya, mereka secara aktif mengerjakan ribuan komponen, sistem, perpustakaan, dan lainnya seperti mereka. Sebagai konsekuensi dari volume seperti itu, setiap hari kita harus menyelesaikan masalah pengelolaan ketergantungan pada tim terkait, hubungan kepemimpinan dan fase Merkurius.

Pada akhir survei tentang apa yang melukai para insinyur, pada akhir 2018 di Sber, diputuskan untuk membuat SberWorks suku, yang mengambil alih segala sesuatu yang berkaitan dengan proses dan alat untuk memproduksi perangkat lunak di bank. Tugas dan sasaran unit hampir sepenuhnya diikuti dari daftar penderitaan pengembang yang dikumpulkan.

Saya malu mengakui bahwa rasa sakit terbesar pada akhir tahun lalu adalah kurangnya pengetahuan tentang apa yang dilakukan tetangga di bengkel atau bahkan di blok tetangga di ruang terbuka. Karena itu, kami tidak hanya menemukan roda, tetapi juga dua (mengganti nomor yang diinginkan) dari roda yang sama di unit yang berbeda, baik di kota yang berbeda maupun di tempat kerja yang berdekatan. Akibatnya, memiliki sumber daya yang besar di perusahaan, sering alih-alih terbang ke Mars, tim kami berlari garu, tidak tahu bahwa garu tetangga sudah lama dikumpulkan.

Apa yang harus dilakukan dengan semua ini?

Waktu. Untuk mengatasi masalah integrasi dan menemukan orang yang tepat, buat satu registri API untuk semua sistem bank dengan banyak otomatisasi: pembuatan panggilan, penghentian untuk versi API berikutnya, versi dan sejenisnya. Sekarang registri ini telah berubah menjadi produk keren yang terpisah, yang jelas layak untuk artikelnya, tapi itu cerita lain.

Dua. Buat semacam "payung" dengan mesin pencari tunggal di atas semua alat teknik (JIRA, Confluence, Bitbucket, Nexus), menggabungkan segmen internal dan eksternal (ya, alpha dan sigma terkenal).

Tiga. Kode, backlog, dan artefak, kecuali yang secara eksplisit melarang keamanan untuk dibuka, harus terbuka untuk semua karyawan perusahaan.

Apa yang disarankan?

Dalam proses berkomunikasi dengan pengembang, kami mengidentifikasi alasan utama untuk tim tertutup dalam diri kami: cara interaksi saat ini antara produk. Setiap diskusi tentang penyempurnaan sistem terkait berjalan sesuai dengan salah satu dari tiga skenario.

"Tunggu"

Cara paling umum untuk berinteraksi. Tim yang berdekatan menetapkan batas waktu, itu biasanya cocok untuk kami, kami menunda tugas lebih dalam ke dalam tumpukan.
Secara umum, opsi yang dapat diterima. Tetapi jika rantai memiliki ketergantungan pada beberapa tim, dan fitur, seperti biasa, perlu ditampilkan dalam produksi kemarin, maka Anda perlu mencari kompromi.

Kompromi

Populer, metode ini disebut eskalasi. Bawalah manajer yang lebih substansial bersamamu dan datanglah ke tim yang berdekatan untuk memindahkan tugas Anda lebih tinggi di dalam simpanan. Kelemahan dari pendekatan ini jelas: sebagian besar tim dapat memainkan kartu ini hanya beberapa kali, setelah itu hubungan antara tim memburuk.

“Temporary stub permanen” Lihat

sepeda Frankenstein Anda dengan tongkat dan bazoka sementara yang menduplikasi fungsi sistem tempat kecanduan itu muncul. Yang paling menyedihkan, karena hampir selalu tetap untuk waktu yang lama (jika tidak selamanya), menghasilkan duplikasi kode, dan tim dipaksa untuk mendukung solusi kruk.

Kami mengusulkan cara keempat. Persempit dalam basis kode tim yang berdekatan di bawah pengawasan sensitif mereka, mengurangi waktu eksekusi.

Sumber Daya Dalam

Setelah menyelesaikan interaksi ini, tim "A" dari gambar menerima umpan balik yang berharga, memupuk keahlian di bidang yang berdekatan dan mengurangi TTM penyempurnaannya. Ke depan, di bank interaksi seperti itu dengan cepat memperoleh format barter dari berbagai jenis: tim "A" menutup tugas dari hutang teknis tim "B" sementara mereka melakukan penyempurnaan yang diperlukan.

Jalan kita

Pada awalnya, tampaknya bagi kita bahwa kita perlu menemukan tempat di mana InnerSource akan berada dalam permintaan maksimum sekarang. Sementara kami memikirkan bagaimana melakukan ini, tanpa jatuh ke dalam siklus jajak pendapat tanpa akhir, kepemimpinan yang bijak menghargai gagasan itu dan mengusulkan untuk memastikan kesiapan 100% dari seratus persen sistem Sberbank pada akhir tahun. Kami tegang, manajer kami bertanya "apa itu seratus persen?", Dan jumlah sistem berkurang sekitar 20 kali menjadi modern dan / atau kritis untuk bisnis.

Setelah itu, proses rutin untuk mengedarkan latihan ini dalam tim dimulai, pada akhirnya kami melihat padang rumput tertutup dengan daftar repositori dan aturan untuk bekerja dengan masing-masing dari mereka.

Kami mengadakan banyak pertemuan di berbagai tingkatan, pertama dengan para pemimpin teknis departemen, kemudian dengan para pemimpin tim dan pemilik layanan, dan akhirnya dengan anggota tim. Kami meminta perwakilan layanan untuk memberikan informasi tentang sistem itu sendiri, tumpukan pengembangan, dan tautan ke repositori, jaminan simpanan, dan dokumentasi. Pada pertemuan yang sama, kami bisa mendapatkan informasi nyeri tangan pertama: backlog yang tak ada habisnya, kurangnya sumber daya, tumpukan teknologi lama (misalnya, Delphi).

Dalam proses sirkulasi, kami telah membentuk pemahaman tentang hubungan yang kuat dan lemah di bank. Ada tim yang sangat matang (misalnya, pengembangan ponsel) yang sudah bekerja pada prinsip-prinsip InnerSource pada skala industri dan berbagi sejumlah besar kerucut dan pendekatan. Tetapi ada beberapa tim (halo ke Pechenegs) yang membuat kami patah semangat karena kurangnya tes otomatis, pencatatan dan praktik tinjauan kode.

Di antara tim kami ada kesenjangan budaya yang besar antara "unit militer saya mengerjakan tugas yang paling benar" dan "mari kita lakukan bersama-sama keren." Sebagian besar reaksi sangat monoton: "kami tidak ingin mengambil kode orang lain dan kemudian menjawabnya", "kami tidak ingin memberikan pengembang kami karena mereka akan pergi, tetapi bagaimanapun juga tidak ada sumber daya". Pada titik ini, diputuskan untuk berinvestasi dalam budaya lebih dari pada teknologi:

HR : Google, , 10 % .
PR : Microsoft, open source.
: , - Delphi GraphQL, 10 % , !
, API, JIRA- .

Dengan beberapa kesalahan, kami belajar melacak interaksi antar tim yang terjadi di BitBucket dan menerima informasi bahwa kami memiliki sekitar 30-50 penulis baru perubahan InnerSource yang ditambahkan setiap bulan. Angka dalam hal jumlah pengembang di bank tidak terlalu mengesankan, tetapi ini hanya peningkatan pada tugas bisnis.

Diharapkan, perubahan berbasis data di berbagai bus integrasi dan layanan ETL menjadi sangat populer. Ini mudah dijelaskan oleh sejumlah besar tugas dan biaya perbaikan yang rendah.

Kami dengan cermat mempelajari perbaikan seperti itu pada contoh ESB kami. Transisi ke solusi baru direncanakan untuknya dalam waktu dekat, jadi tidak ada sumber daya tambahan yang dialokasikan untuk tim, sementara permintaan revisi hanya bertambah. Di InnerSource, orang-orang melihat keselamatan, dengan cepat gelisah dan mengumpulkan prioritas yang meningkatkan tugas Anda sebanyak mungkin jika Anda siap melakukannya sendiri. Secara angka, terlihat seperti ini: pada Oktober-November, hampir setengah (101 dari 209) permintaan revisi diselesaikan oleh tim sendiri. Ini menghasilkan pengurangan waktu tunggu empat kali lipat dari 2,5 bulan menjadi 2,5 minggu.

Secara tak terduga, desainer mengambil bagian aktif, yang dengan senang hati membantu tim terkait ketika yang terakhir kekurangan sumber daya atau membutuhkan tampilan yang segar. Ternyata, ada beberapa tim yang dapat memanfaatkan desainer 100%, dan mereka sendiri kreatif dan suka mengubah fokus ke beberapa produk baru.

Kata penutup

Langkah pertama dalam memperkenalkan transparansi dan interaksi antara tim dalam perusahaan yang terbiasa dengan hukum perusahaan selalu yang paling sulit. Kita dapat dengan aman mengatakan bahwa tembok pertama telah ditembus dan cukup banyak kisah-kisah InnerSource yang berhasil telah diakumulasikan sehingga gerakan di dalam Sberbank akan mendapatkan momentum.

Tantangan utama di masa depan yang kita lihat adalah menghindari hukum Goodhart . Dalam perusahaan menengah dan besar, efisiensi harus diukur: menghasilkan angka dan membuatnya tumbuh. Pada sebuah konferensi di Baltimore musim gugur yang lalu, beberapa kasus disajikan di mana menetapkan tujuan untuk kesiapan tim dan jumlah perbaikan menyebabkan sabotase metrik dan kelelahan pemimpin gerakan.

Kami percaya bahwa manfaat yang dihasilkan sepenuhnya mencegah upaya yang diinvestasikan, dan keterbukaan itu sendiri memiliki banyak sekali manfaat. Kami siap memberi tahu jalan kami secara lebih terperinci dan bertukar pengalaman, tulis-menelepon - innersource@sberbank.ru . Ciuman, Sberbank.