Bertamasya ke masa lalu
Saya telah bekerja untuk Layanan ICL selama lebih dari 4 tahun dan mulai sebagai spesialis dukungan teknis pada sebuah proyek besar. Sekarang saya memimpin grup ITSM ke arah Meja Layanan - kompetensi saya terkonsentrasi pada penerapan dan konfigurasi sistem ITSM, manajemen proses TI (Insiden, Perubahan, Manajemen Masalah). Bahkan, saya dapat mengatakan tanpa melebih-lebihkan: orang-orang paling terampil di bidang SD bekerja dalam kelompok saya.
Keunikan sebuah perusahaan besar, yang saya temukan setelah bekerja di dalamnya selama sekitar enam bulan sejak bekerja, adalah sebagai berikut: orang jarang membagikan praktik terbaik mereka. Bukan karena mereka tamak, tetapi hanya karena mereka terlalu malas untuk menjelaskan kepada rekan kerja apa manfaatnya. Bagaimanapun, seperti yang sering terjadi, sebagian besar, semua orang di sini adalah teknisi dengan hubungan jangka panjang.
Dan kemudian saya datang - dan saya melihat bahwa yang satu memiliki skrip cantik yang memungkinkan beberapa pekerjaan dilakukan secara otomatis, yang lain membuat jadwal shiftnya di aplikasi cloud dan tidak pernah membingungkan shiftnya (dan di saat-saat padat itu kami masih menggunakan Excel), yang ketiga menulis sederhana aplikasi web yang menampilkan semua bidang aplikasi dalam satu layar agar tidak membuang waktu untuk berpindah tab di sistem ITSM dan membukanya saat memeriksa aplikasi.
Namun perkembangan ini tetap bersifat individual dan tidak dibagikan dengan seluruh tim proyek, belum lagi implementasi apa pun pada proyek serupa. Seperti yang dikatakan pemimpin saya, kami selalu menemukan kembali sepeda kami sendiri - dan saya benar dalam kasus ini. Tentu saja, ada juga faktor manusia: misalnya, ada seseorang yang lebih berpengalaman, dan dia tidak dapat menggunakan praktik terbaik dari "muda". Dan klasik khusus - "tetapi dengan dia kami memiliki konflik pribadi, saya tidak akan menggunakan alat yang dia gunakan . "
Itu berhasil bagi saya, dan secara umum untuk seluruh departemen kami, pendekatan baru untuk proses diperkenalkan dan diuji. Banyak dokumentasi, lolongan dari pengguna dan kelompok pendukung - semuanya seperti biasa. Saya berhasil mendorong peningkatan yang saya lihat, tetapi yang terpenting, saya berhasil melibatkan hampir semua orang untuk bekerja sama dalam layanan tersebut. Lagipula, Anda tahu apa kemampuan tim yang bersatu melawan suatu masalah? Masalahnya tidak mungkin. Pelanggan memperkenalkan indikator baru - persentase kesalahan saat mengisi aplikasi. Pada awalnya, sekitar 10% per tim, artinya, sekitar 200 aplikasi memiliki kesalahan kecil dan signifikan.
Pimpinan lini dan proyek berkata, "tidak mungkin mengurangi persentase kesalahan lebih banyak lagi - orang adalah manusia, dan mereka akan selalu salah . " Kami mereplikasi aplikasi web yang ditulis oleh spesialis terkemuka kami, menetapkan titik kontrol dan secara teratur mengambil informasi tentang indikator ini, menangani kasus-kasus tertentu: ketika sistem ITSM itu sendiri menggantikan bidang yang diperlukan dari Active Directory, apa yang harus dicari. Hasilnya tidak lama lagi - dalam enam bulan kami membawa% kesalahan per bulan ke level paling rendah 0-0,6% per tim.
Dan sekitar titik ini dalam karir saya, saya menyadari dua hal:
- Saya ingin bekerja dalam tim yang keren , dan hasil kerja integralnya jauh lebih baik daripada yang dapat dilakukan oleh karyawan paling cerdik sekalipun. Keputusan ini pasti akan membawa saya ke manajemen nanti.
- Saya ingin menggabungkan prestasi berbakat, keren orang-orang ke dalam satu sistem yang lebih baik, lebih dapat diandalkan, lebih cepat daripada yang Anda miliki sebelumnya.
Proyek dimulai
Pada tahun 2019, saya ditawari untuk memimpin proyek Digital SD, di mana kami harus membuat layanan kami lebih kompetitif dengan bantuan teknologi modern: Pembelajaran Mesin, berbagai bot suara dan teks, platform omnichannel, klasifikasi otomatis, dan aplikasi penyelesaian otomatis. Dengan kata lain, semua hal yang membawa pengalaman klien ke tingkat yang baru tanpa meningkatkan biaya tenaga kerja untuk menyediakan layanan.
Sejujurnya: setelah melihat kembali seluruh hype seputar AI, pada awalnya saya sangat skeptis tentang tugas tersebut. Dan tampaknya arahnya benar, dan tujuannya bagus, tetapi ada yang salah di sini.
Dan hasil tangkapannya adalah tidak ada yang tahu persis apa yang perlu dikembangkan. Ada banyak petunjuk arah, apa yang harus diambil? Biasanya pada saat-saat seperti itu dalam artikel atau buku mereka dengan percaya diri menulis: "bahkan saat itu kami tahu bagaimana dan ke mana harus pindah." Jadi, ini bukan tentang kita. Saya berdiri bersama pemilik produk dan membuat daftar pertanyaan yang perlu kami jawab saat mendesain produk:
- Fungsionalitas bermanfaat apa yang kami berikan kepada pengguna dan pelanggan?
- Bagaimana ini terintegrasi ke dalam layanan saat ini?
- Bagaimana Anda perlu mengubah alur kerja Anda saat ini agar ini berfungsi dan bermanfaat?
- Bagaimana dan pada teknologi apa ini harus dilakukan?
- Bagaimana seharusnya model solusi ekonomi dibangun?
Tapi kami melakukannya dengan sangat hati-hati: kami mengumpulkan sekelompok ahli dari SD dari antara manajer proyek, manajer lini, pakar teknis, menuliskan cerita pengguna, membuat peta nilai - inilah sebagian kecilnya:
Secara paralel, bersama dengan pengembang, kami mendeskripsikan arsitektur tingkat atas, sehingga mendapatkan titik awal dalam proyek ...
Pekerjaan SCRUM
Demikian perkenalan kami: Pemilik Produk, PM, Scrum Master, dan Tim Pengembang. Sprint kerja yang berlangsung selama 2 minggu. Tugasnya adalah mengatur proses rilis produk sedemikian rupa sehingga ...
Tapi serius, perlu mempertimbangkan persyaratan semua pemangku kepentingan, mengatasi rasa sakit dan memahami apa yang benar-benar perlu dilakukan, apa yang bisa dilakukan nanti, dan apa yang tidak boleh dilakukan sama sekali.
Kami memiliki 3 area aktivitas yang luas:
- . , , , .
- . , «» .
- . HR, , IT, . .
Kami berhasil membangun pekerjaan normal hanya pada sprint ke-3: kami kurang lebih menyadari bahwa kami perlu fokus pada area 1 dan 2, karena manajer proyek berbicara tentang rasa sakit, dan kepala layanan pendukung berbicara tentang keinginan.
Saya tidak akan meregangkan artikel dan memberi tahu Anda betapa kerennya Agile itu sendiri dan bagaimana hal itu sangat membantu. Tapi inilah yang benar-benar dapat saya katakan setelah bekerja dalam mode ini selama sekitar 30 sprint:
- Scrum adalah pendekatan kerja. Anda memasukkan sumber daya dan metodologi, dan Anda mendapatkan pengiriman.
- – . , , , . , , , , « », – .
- . , , . , , – . PM – , , , – , – .
Saya memiliki lebih sedikit pengalaman semacam ini, jadi beban yang besar dan berat ini jatuh ke tingkat yang lebih besar pada Pemilik Produk: untuk membandingkan harapan pemangku kepentingan dengan kenyataan, memahami dengan jelas kemampuan tim saya, memiliki pandangan yang bersih, memahami situasi pasar, keseimbangan antara mengarahkan sumber daya ke fungsi yang berguna, eksperimen dan "kejahatan yang diperlukan" - keamanan solusi, organisasi arsitektur layanan, lingkungan, dokumentasi.
- PM . , . -. Devops , , : , /. , , Agile - , : , , .
- - – . , -. , . , PM -, . , . , , !
Kami tidak memulai pengembangan dari awal. Kami memiliki banyak perkembangan di perusahaan yang dapat digunakan dalam satu bentuk atau lainnya - hanya ada dua pengklasifikasi otomatis.
Saya merasa déjà vu ketika saya mengumpulkan semua ini dari berbagai proyek, divisi, karena saya pernah mengumpulkan perkembangan pada proyek pertama saya.
Kami mulai mengembangkan sistem dialog dengan beberapa pustaka sumber terbuka - dan salah satunya adalah DeepPavlov. Kami tidak memiliki banyak pengalaman dengannya, dan pada tugas kami kualitas pengenalannya ternyata biasa-biasa saja. Segera kami beralih ke Rasa, dan semuanya berjalan jauh lebih baik - dan setelah melatih model pada data spesifik kami, kami mendapat pengenalan dialog yang baik dan percaya diri.
Tata letak dialognya sendiri dilakukan secara manual - pada saat itu ada orang-orang di SD yang melakukan tugas ini. Pengembang Python utama kami dengan cepat menulis program markup, dan kami memberikan model tersebut beberapa puluh ribu percakapan. Fragmen diambil agak pendek, masing-masing 3 detik - dengan cara ini hasilnya keluar lebih baik.
Awalnya, kami memiliki 2 mesin virtual di Windows dan di Linux, beberapa layanan hanya dapat berfungsi di bawah Windows. Tetapi ketika kami mulai membawa pengembangan pertama ke uji coba, kami segera menyadari bahwa 2 mesin virtual untuk satu proyek terlalu mahal, kami perlu mengulanginya. Sekarang kami menggunakan satu mesin virtual di Ubuntu untuk produksi. Tentu saja, mereka semua terisolasi dan setiap proyek memiliki wilayahnya sendiri-sendiri.
Kami juga segera menyadari bahwa menyiapkan dua mesin virtual, menaikkan dan men-debug semua layanan, membuka porta, dan pengaturan lainnya membutuhkan waktu yang tidak senonoh. Kemudian kami membuat solusi CI / CD berdasarkan Docker - baik untuk kode utama maupun untuk bagian ML.
Di suatu tempat dalam sprint 9-10, kami dihadapkan pada permintaan dari banyak pelanggan untuk membuat sistem pengenalan suara mereka sendiri. Sebagian besar pelanggan sama sekali tidak siap untuk mentransfer informasi rahasia mereka ke "awan" kepada pihak ketiga. Jadi, kami membuat sistem seperti itu dan sekarang kami dapat menawarkannya di tempat yang penting untuk memiliki seluruh arsitektur dalam batas keamanan - misalnya, untuk perusahaan yang terkait erat dengan negara. Atau letakkan di infrastruktur kami, karena tahu pasti bahwa data sensitif tidak akan sampai ke pihak ketiga.
Kami menerapkan sistem pemantauan komponen, menyiapkan pemeriksaan kesehatan, dan mengintegrasikan sistem dengan saluran obrolan di Telegram.
Dan terakhir, saya akan memberi tahu Anda satu lagi kehalusan yang mungkin berguna bagi seseorang saat merancang bot obrolan mereka. Awalnya, semua kode kami cukup monolitik dan sulit untuk mengubahnya. Kami telah membagi chatbot menjadi dua bagian besar: bot dasar dan penyesuaian. Kami harus menulis ulang logikanya - tetapi berkat pemisahan ini, kami dapat dengan cepat menerapkan komponen dasar dan umum dari bot dan hanya mengedit yang khusus untuk setiap proyek tertentu.
Hasil proyek
Kami memahami dengan jelas ceruk sejarah kami: kami tidak akan dapat bersaing dengan produk kemasan yang telah dikembangkan selama belasan tahun, dan hal ini juga tidak diperlukan. Niche kami adalah menyediakan alat otomatisasi pada setiap tahap proyek layanan, mulai dari pra-penjualan hingga kedaluwarsa kontrak. Dengan kata lain, awalnya kami tidak memiliki tujuan untuk membuat Google - tetapi tujuannya adalah untuk membuat seorang desainer yang akan membantu menjual Service Desk, membantu mengurangi biaya penyediaan layanan, dan memberikan kesempatan tambahan kepada pelanggan dan bisnis mereka.
Saya juga mencatat satu hal yang menarik untuk diri saya sendiri: jarang solusi kotak di pasar dapat sepenuhnya menutupi rasa sakit pelanggan dan pada saat yang sama mengatur harga. Baik pelanggan membayar lebih untuk fungsionalitas tersebut, yang tidak akan dia gunakan nanti, atau beberapa perbaikan harus dilakukan oleh spesialis atau spesialis dari vendor yang dipilih, jika dia mengambilnya.
Dan di sini kami memiliki tugas integrasi yang menarik dan agak sulit, selain menawarkan solusi otomatisasi murni kami sendiri, untuk membangun sistem bagi pelanggan dari pengembangan kami dan solusi pihak ketiga yang sudah ada di pasar, sesuai dengan fungsionalitas pelanggan dan memelihara sistem seperti itu sebagai layanan. Mungkin saya akan berbicara tentang hasil pekerjaan ini di artikel berikutnya, jika ada minat.
Sebagian besar alat dan pengembangan kami telah diimplementasikan dalam layanan saat ini, kami sedang melakukan uji coba, dan kami akan menyempurnakan beberapa di BAU. Chatbot masih terasa paling buruk, hari ini paling tidak berguna untuk proyek - mungkin karena ekspektasi sekarang cukup tinggi. Semua orang menginginkan bot pintar yang dapat melihat ucapan manusia, menjawab dengan tenang semua pertanyaan pengguna, mampu menangani interupsi, memiliki integrasi ke semua sistem, belajar sendiri tanpa campur tangan manusia, dan seiring waktu mengenali semakin banyak maksud.
Tetapi setiap pengembang yang berpengalaman dalam topik ini memahami betapa sulitnya tugas ini - lagipula, bahkan dengan meningkatkan fungsionalitas dan meningkatkan jumlah niat yang dapat dikenali bot, kami dapat memperburuk pengakuan atas niat yang ada. Tetapi ini adalah penyimpangan - secara keseluruhan, bagi saya tampaknya kami telah mengelola tugas utama proyek tersebut.
Apa yang terjadi di pintu keluar
1. Asisten suara dan perancang naskah yang cerdas untuk itu. Menutup kebutuhan untuk otomatisasi aliran panggilan masuk, mengenali ucapan pengguna, suara ke teks, dan mengirimkannya ke email, obrolan, sistem ITSM, tergantung pada pengaturan. Itu dapat berintegrasi dengan banyak sistem yang berbeda, baik dengan konektor yang sudah jadi, atau dengan yang kami tulis.
2. Dialer dengan mesin dari asisten suara.Menutup kebutuhan untuk memanggil kumpulan nomor yang ditentukan dan kemudian mengumpulkan tanggapan pengguna bergantung pada skenario. Panggilan biasa dimungkinkan, ada pengaturan untuk jumlah pertanyaan berulang untuk mengklarifikasi berapa kali dan setelah jam berapa harus menelepon kembali. Menyimpan data tentang panggilan yang dilakukan bersama dengan hasil panggilan dan rekaman panggilan. Sekarang ini digunakan untuk mengingatkan para insinyur tentang penambalan untuk proyek yang dilaksanakan untuk pengecer makanan internasional besar, di departemen SDM saat mengatur wawancara untuk posisi massal, dalam rencana untuk mengumpulkan informasi tentang kualitas aplikasi yang diselesaikan di rantai restoran cepat saji besar.
3. Chatbot untuk membuat aplikasi, mengatur ulang kata sandi dan desainer skrip untuk itu.Tahu cara meminta informasi utama untuk mendaftarkan permintaan, mendaftarkan permintaan di sistem ITSM, dan mengembalikan nomor permintaan. Pada saat artikel diterbitkan, itu akan belajar untuk menunjukkan daftar aplikasi yang terbuka dengan kemampuan untuk menambahkan informasi atau menutupnya. Itu dapat terhubung ke sistem ITSM yang berbeda, dengan atau tanpa akses api.
4. Alat untuk pengendalian kualitas. Sejauh ini dia tahu sedikit: dia melacak panggilan, mengenali apakah operator telah menyapa atau tidak, mengidentifikasi kata-kata yang menimbulkan konflik, sobat dalam dialog, memiliki antarmuka lengkap untuk pengontrol kualitas. Mereka melakukannya untuk diri mereka sendiri, tetapi itu bisa berguna di CC.
5. Pengklasifikasi otomatis.Dia mampu mengurai aplikasi di sistem ITSM, mengisinya, dan mengirimkannya ke grup solusi yang diperlukan. Mungkin mempertimbangkan ketersediaan, beban kerja, dan spesialisasi teknisi. Misalnya, Anda dapat mengatur logika bahwa semua aplikasi EDS harus dikirim ke spesialis utama Vasily atau Andrey: jika Vasily tidak bertugas, aplikasi akan masuk ke Andrey, dan sebaliknya. Jika tidak keduanya, tiket akan ditambahkan ke lini umum dukungan aplikasi bisnis. Jika Vasily punya 2 aplikasi, dan Andrey punya 1, aplikasi baru akan dikirim ke Andrey. Anda dapat dengan percaya diri melatih model, meningkatkan keakuratan. Kerugian dari sistem adalah intinya.Anda tidak boleh mengharapkan akurasi 100% dari model atau bekerja pada seluruh volume aplikasi. Pada sampel uji, kami melakukan akurasi 90% untuk 50% aplikasi dengan data yang sangat konsisten, tempat pengguna terbiasa bekerja dengan template. Kerugian kedua adalah volume pesanan. Tidak masuk akal untuk melatih model jika Anda memiliki kurang dari 1000 aplikasi per bulan.
6. Alat untuk aplikasi pemecahan otomatis.Ini adalah seperangkat alat dari GUI dengan skrip yang mengotomatiskan tindakan standar agen dukungan teknis: mengumpulkan log dari sistem, mengambil tangkapan layar, termasuk dalam mode bayangan, memperbarui kebijakan, dan hal-hal lain yang spesifik untuk setiap proyek. Alat kedua adalah otomatisasi aplikasi-aplikasi yang memerlukan persetujuan. Alat itu sendiri menghasilkan surat kepada pemberi persetujuan dengan tautan untuk menyetujui / menolak dan, berdasarkan hasil, dengan sendirinya memberikan perintah untuk memberikan akses, atau menghasilkan surat dengan penolakan.
Bukannya selamat tinggal
Musim dingin akan datang, proyek ditutup pada akhir tahun ini, saya
Terima kasih atas minat dan waktu Anda, jangan sakit!