Nama saya Alexandra Kamzeeva, saya telah bekerja sebagai analis sistem selama 9 tahun, 3,5 tahun di Lamoda. Saya banyak membaca, menganalisis dokumentasi saat ini dan membuat yang baru. Dalam pekerjaan saya, saya selalu menyusun informasi dan membuatnya senyaman mungkin.
Kelebihan dari deskripsi sistem yang baik adalah:
- membantu Anda menemukan informasi yang Anda butuhkan dengan lebih cepat dan mudah daripada dalam deskripsi yang tidak terstruktur;
- mengurangi risiko kegagalan proyek;
- memudahkan karyawan untuk bergabung.
Kami membuat template untuk deskripsi yang dapat digunakan oleh tim mana pun. Pada artikel ini, saya akan memberi tahu Anda dengan contoh-contoh apa yang mendorong kami untuk membuat templat deskripsi sistem, riwayat pembuatannya, dan cara penggunaannya sekarang di Lamoda.
Apa itu template dan mengapa itu dibutuhkan
Pertama, saya akan menjelaskan pemahaman saya tentang polanya. Anggap saja saya perlu menemukan mobil kecil di ruangan yang tidak rapi. Bukan fakta bahwa saya bisa mengatasinya. Tapi saya bisa tanpa sengaja menginjak bagian Lego.
Sekarang mari kita bayangkan bahwa semua mainan diletakkan di tempatnya dan disortir. Saya dapat melihat sebelumnya di kotak mana semua mobil berada, saya akan menemukan yang saya butuhkan dengan lebih cepat, lebih mudah dan saya tidak akan menyia-nyiakan keberanian untuk itu.
Begitu juga dengan dokumentasinya. Template adalah perintah seperti itu. Kami telah membuat kerangka kerja untuk mendeskripsikan sistem yang dapat digunakan oleh tim mana pun.
Dalam kondisi apa kami bekerja dengan dokumentasi
Lamoda memiliki lebih dari 100 sistem yang mengotomatiskan pengiriman pesanan, pusat kontak, gudang, studio foto, serta proses operasional dan bisnis lainnya. Lebih dari 300 insinyur terlibat dalam pengembangan dan dukungan. Salah satu dari mereka mungkin memerlukan deskripsi dari salah satu dari 100 sistem ini.
Setiap tim secara independen mendeskripsikan sistem mereka di ruang terpisah di Confluence. Pimpinan teknis harus terlibat dalam pendokumentasian, karena dia berkewajiban mencatat informasi. Selain itu, sistem dijelaskan oleh penguji dan pengembang aktif yang merasa menyesal karena kehilangan pengetahuan mereka. Dan, tentu saja, analis, karena dokumentasi adalah salah satu alat utama kami.
Tampaknya kebebasan ini mengarah pada kekacauan. Tetapi tidak demikian, karena kami memiliki budaya perusahaan: sikap bertanggung jawab terhadap dokumentasi, berbagi pengetahuan terbuka, kebiasaan merekam proyek dan artefak sistem. Tradisi ini berkembang sebagian karena proyek yang tidak berhasil. Insiden tersebut membuktikan kepada tim pengembangan betapa pentingnya mendokumentasikan proses dan fungsionalitas sistem.
Di bawah ini saya akan menyoroti beberapa kasus di mana dokumentasi yang membingungkan atau kurangnya dokumentasi menyebabkan masalah.
Cukup tambahkan dua tombol
Masalah pertama yang mendorong kami untuk membuat template - kami tidak memiliki penjelasan tentang beberapa sistem, yang menyebabkan kegagalan dan peningkatan.
Kami memiliki proyek Self Order Management (SOM). Kami memutuskan untuk menambahkan dua tombol ke akun pribadi klien: "Tanggal transfer pengiriman" dan "Batalkan pesanan". Sebelumnya, klien hanya dapat membatalkan atau menjadwal ulang pesanan dengan menghubungi contact center. Jelas terlihat bahwa beberapa pembeli tidak punya waktu atau keinginan untuk berkomunikasi dengan operator. Akibatnya, perwakilan penjualan dapat membawa pesanan yang tidak perlu atau tidak menemukan klien di rumah. Dalam kasus seperti itu, Lamoda menanggung biayanya. Proyek itu perlu dan penting.
Tampaknya akan menambahkan dua tombol! Faktanya, ada banyak logika di belakang mereka dalam keempat sistem tersebut. Mengubah pesanan melewati sistem pemrosesan - sebuah monolit besar tempat Anda dapat menyentuh sesuatu di satu tempat dan memotret di tempat lain. Sayangnya, seluk-beluk karyanya tidak dijelaskan dalam dokumentasi, mereka tidak memperhatikan hal ini selama desain proyek. Setelah rilis, tombol tidak berfungsi seperti yang diharapkan dan digulung kembali. Akibatnya, alih-alih dua bulan kerja, proyek ini memakan waktu enam bulan.
Tentu saja, kami mendapatkan hasil ini bukan hanya karena kurangnya dokumentasi. Tetapi jika kami memiliki gambaran yang jelas tentang proses pembatalan dan pengalihan pesanan, maka mungkin hasilnya akan berbeda.
Orientasi yang kompleks
Masalah kedua yang membuat kami membuat template adalah kompleksitas onboarding. Saya bekerja untuk tim sistem pemrosesan pesanan. Untuk pencelupan, saya membaca dokumentasi di ruang sistem dan di tiga bagian saya menemukan tiga deskripsi berbeda tentang esensi utama sistem kami - status pesanan.
Dalam kasus ini, tidak berhasil membuat orientasi menjadi lebih mudah. Dokumentasi semacam itu tidak membantu mentransfer pengetahuan ke kolega yang sebelumnya tidak pernah menggunakan sistem kami.
Masalah batu tulis kosong
Prasyarat ketiga untuk pembuatan template adalah masalah slate kosong. Untuk setiap sistem baru, pimpinan teknis harus membuat ruang yang sesuai dari awal. Pimpinan Teknis memikirkan bagian mana yang akan dibuat. Sebelum membuat templat, karyawan mempelajari ruang lain dan melihat bagian mana yang digunakan dan akan berguna untuk sistemnya. Ini biasanya memakan waktu lama.
Bagaimana kami membuat template dan apa yang terjadi
Setiap minggu, analis sistem mengadakan stand-up dan membahas masalah yang dihadapi pada proyek dan tidak hanya. Dan lebih dari sekali rekan kerja mengeluhkan betapa sulitnya menemukan informasi dan memahami ruang dari berbagai sistem. Karena kami terus-menerus terbakar karena ini, kami memutuskan untuk mengambil sendiri deskripsi sistem tempat kami terhubung. Dan kemudian akan jelas apa yang harus dilakukan.
Pertama, kami mengidentifikasi atribut template yang baik:
- .
- . , , . , . .
- . , , , .
- .
Selanjutnya, kami menganalisis deskripsi terkini dari berbagai sistem dan mengidentifikasi bagian umum:
Di bagian proyek dan fitur, terdapat spesifikasi untuk mengembangkan proyek. Bagian Pengembangan dan QA berisi informasi khusus untuk pengembangan dan penguji. Di bagian insiden, insiden yang terjadi di sistem dan solusinya dijelaskan.
Kami berbagi ide templat dengan rekan kerja lainnya pada pertemuan informal (makan siang di dapur, stand-up, tim tetangga yang Anda ajak bicara secara berkala) dan membuat kelompok kerja sukarelawan. Mereka adalah perwakilan dari berbagai kompetensi: dua manajer, tiga pimpinan teknis, dan dua penguji. Mereka menambahkan bagian berikut ke template:
Selanjutnya, kami menguji template deskripsi sistem dengan kolega yang memiliki kompetensi luas: kepala departemen TI, pimpinan teknologi berpengalaman, dan pimpinan pengujian proyek integrasi besar. Mereka akhirnya menambahkan beberapa bagian yang lebih berguna:
Memeriksa kualitas template
Kami memeriksa dokumen yang dihasilkan dengan definisi kami tentang template yang baik di Lamoda:
- Ini membantu Anda menemukan informasi yang Anda butuhkan dengan lebih cepat dan mudah. Kami memiliki struktur yang nyaman: Saya bergerak di sepanjang pohon dan memahami apa yang lokasinya dan di mana. Jika Anda memerlukan informasi tentang proses sistem (misalnya, membatalkan pesanan), maka saya pergi ke "Deskripsi proses utama".
- Informasi sistem tidak digandakan karena atomisitas dari partisi. Misalnya, Anda dapat mendeskripsikan barang cetakan dalam satu bagian, lalu menautkannya dari bagian "Deskripsi proses utama" sehingga informasi tidak terulang.
- . Lamoda, . , -. — .
- . .
Kami membuat template yang bagus untuk menggambarkan sistem Lamoda. Saya berharap perusahaan lain akan merasakan manfaatnya juga. Saya secara khusus ingin menyoroti tiga bagian berikut:
Deskripsi proses utama sistem . Ya, tampaknya jelas bahwa bagian ini diperlukan. Tetapi untuk beberapa alasan itu tidak selalu ada, seperti halnya dengan kami dengan tombol untuk membatalkan dan mentransfer pesanan. Jika kami telah menjelaskan proses pembatalan dan penjadwalan ulang sebelumnya, risiko kegagalan proyek akan berkurang.
Daftar periksa- Bagian yang mengingatkan tentang yang paling penting dalam proses reguler. Misalnya, kami memiliki "Daftar periksa untuk menghubungkan metode pembayaran baru" dalam deskripsi sistem pengelolaan metode pembayaran. Dikatakan bahwa kita harus mengoordinasikan penambahan atau perubahan metode pembayaran dengan departemen akuntansi, dengan pusat kontak, dengan pengiriman dan dengan unit bisnis lainnya.
Suatu ketika kami lupa memberi tahu contact center tentang perubahan metode pembayaran. Dan ketika klien menelepon pusat kontak kami dan menanyakannya, operator tidak dapat berkata apa-apa. Hal ini menyebabkan konflik antara contact center dan tim pengembangan yang bertanggung jawab atas metode pembayaran. Setelah insiden ini, kami membuat daftar periksa untuk peluncuran proyek utama, menghubungkan mitra baru, dll.
Halaman beranda luar angkasa- bagian dengan informasi tentang mengapa sistem ini diperlukan, tentang komposisi tim dan pemangku kepentingan. Kita harus mengoordinasikan perubahan sistem dan pengembangan sumber daya dengan pemangku kepentingan. Jadi, sangat bagus jika Anda bisa mendapatkan informasi ini hanya dengan melihat Confluence.
Di sana kami menunjukkan informasi tentang komposisi tim untuk memahami siapa yang harus dihubungi dengan pertanyaan tentang sistem. Ini juga membantu pemula dengan kepala bengkak. Sangat menyenangkan ketika seorang karyawan baru dapat memata-matai siapa yang baru saja dia ajak bicara, siapa orang ini, apa perannya dan siapa namanya.
Bagaimana saya mulai menggunakan template di sistem saya
- Pertama-tama, saya membuat bagian template yang diperlukan tanpa mengisi. Mudah dan tidak lebih dari 30 menit.
- Kemudian hal yang paling sulit adalah: kami mengadakan pertemuan rutin dengan pimpinan bagian teknis, di mana kami mulai menganalisis dokumentasi sistem kami. Pada pertemuan pertama, kami membagi halaman saat ini menjadi tiga tumpukan.
Kami mengirim semua yang tidak relevan dan tidak perlu ke tumpukan pertama. Kami menghapus halaman-halaman ini atau mengirimkannya ke arsip.
Tumpukan kedua diperlukan, tetapi tidak relevan. Kami menandai halaman tersebut sebagai tidak relevan, membuat tugas di Jira, dan kemudian memperbarui informasi ini sesuai dengan backlog kami.
Tumpukan ketiga adalah yang paling sederhana. Jika semuanya jelas, bagian tersebut menjadi relevan - kami baru saja memindahkannya ke tempat yang tepat.
Sebelum pertemuan ini, deskripsi proses dan arsitektur, catatan dari penguji dan pengembang, serta insiden tersebar di seluruh ruang. Juga tidak ada halaman muka.
Selama 6 jam pertemuan, kami mendapatkan hasil yang sangat baik. Dari kekacauan, kami telah membentuk struktur dan ketertiban. Sekarang Anda dapat mencari tahu di mana menemukan deskripsi proses, informasi tentang arsitektur, dan tentang insiden. Dan yang terpenting, sekarang kami memiliki halaman beranda. Di sini tertulis mengapa diperlukan sistem pemrosesan pesanan dan siapa pemangku kepentingannya.
Sistem besar kami terlibat di hampir semua lini bisnis. Namun sebelumnya kami tidak memiliki pemangku kepentingan sendiri. Saat kami melakukan halaman beranda, kami berdiskusi dengan CTO dengan siapa untuk mengoordinasikan perubahan sistem. Maka, ditentukan seorang kolega, yang memprioritaskan perbaikan. Sekarang sepertinya fakta yang menyenangkan bahwa pembuatan halaman rumah menyebabkan munculnya pemangku kepentingan.
Bagaimana Kami Mendistribusikan Template
Hasil serupa pada penggunaan template diterima oleh analis lain yang menerapkannya ke arah mereka sendiri. Jadi, kami telah mencakup sebagian besar sistem yang telah terlibat secara aktif dalam banyak proyek integrasi.
Kami memiliki tim yang sistemnya sering terlibat dalam proyek integrasi, tetapi tidak ada cukup deskripsi tentang mereka. Biasanya ada kebutuhan untuk dokumentasi, jadi tidak perlu menjual idenya.
Kami menunjukkan pengalaman sukses dalam menerapkan templat kepada pimpinan teknis dan manajer tim tersebut. Beberapa tim, berdasarkan contoh kami, merapikan dokumentasi mereka sendiri, yang lain meminta bantuan analis.
Umpan balik tentang template
Template kami bukan deskripsi sistem wajib atau wajib. Rekan kerja mengambil template sebagai dasar, jika mereka membutuhkannya, dan mengeditnya sesuai dengan kebutuhan mereka. Misalnya, mereka mentransfer pertukaran dari sub-bagian ke bagian jika sistem utamanya terdiri dari mereka.
Semua sistem kami memiliki deskripsi yang berbeda, tetapi struktur umum dan logika umum masih dipertahankan. Sekarang kita dapat lebih mudah mencari informasi tentang terdiri dari proses apa sistem, tentang arsitektur sistem, dan sebagainya.
Di Lamoda kami senang berbagi pengetahuan. Kami memiliki proyek integrasi besar yang memotivasi hal ini. Kami mengirim tautan ke deskripsi sistem terbaru, dan kolega menerima informasi yang diperlukan tanpa pertanyaan tambahan kepada pimpinan teknis yang sudah dimuat.
2 tahun setelah membuat template, saya mewawancarai rekan kerja dan menerima umpan balik yang baik dari mayoritas. Mereka menggunakan template, mengedit struktur sesuka mereka.
Tapi ada juga yang menganggap kita tidak butuh dokumentasi dan template. Pada dasarnya, ini adalah alasan tim dari sistem tersebut di mana sekarang tidak ada kebutuhan mendesak untuk mendokumentasikan sesuatu.
Mereka bekerja pada sistem yang hampir tidak berubah: tidak ada proyek integrasi, tidak perlu memberi tahu kolega lain tentang sistem ini, dan karenanya, tidak ada keinginan untuk mendokumentasikan.
Saya rasa sebelum memulai proyek besar, budaya kita dan masalah besar akan mengingatkan Anda untuk mendokumentasikan proses utama, dan mereka akan berubah pikiran.
Nasihat untuk diri Anda sendiri dan mereka yang ingin mengulangi jalan kami
- , , , , . , .
- . , . , .
- , , . : , , . . , .