Saya berbicara dengan pendiri startup ElectroNeek: Sergey (CEO), Dmitry (CIO) dan Mikhail (CTO). Di akhir wawancara - video tempat robot dirakit secara langsung.
- Dmitry, tolong kirim foto untuk KDPV, dimana kalian semua berada.
- Percaya atau tidak, kita belum pernah bertemu selama dua tahun ini)
ElectroNeek mengembangkan ekosistem produk perangkat lunak yang dapat digunakan untuk membuat robot yang mengulangi tindakan apa pun dari karyawan kantor di komputer dengan aplikasi apa pun yang diinstal di dalamnya. Dengan demikian, dimungkinkan untuk melakukan robotisasi sepenuhnya atau sebagian proses di perusahaan. ElectroNeek berspesialisasi dalam bekerja dengan integrator sistem dan tim IT yang membuat pusat kompetensi RPA, dengan kata lain, produk mereka ditujukan bagi mereka yang mengembangkan robot dalam jumlah besar, dan tidak menyelesaikan beberapa masalah otomasi lokal tertentu.
RPA (Robotic Process Automation) adalah teknologi yang membantu mengotomatiskan tugas harian dan berulang. RPA memungkinkan Anda untuk benar-benar meniru tindakan pengguna biasa di komputer. Anda mengarahkan mouse ke tombol dan mengklik, lalu memasukkan teks dengan keyboard dan menekan "Enter". Inilah tepatnya RPA. Seiring dengan meningkatnya permintaan, vendor RPA mulai mengembangkan solusi mereka untuk menyediakan mekanisme otomatisasi yang lebih fleksibel. Ada integrasi dengan bahasa pemrograman, dengan teknologi seperti OCR, mereka secara serius berpikir untuk memperkenalkan pembelajaran mesin. Robot sekarang dapat diluncurkan secara bersamaan, sesuai jadwal, dari jarak jauh, dll. Contoh kasus: satu , dua , tiga , empat, lima .
- Apa itu robot?
Mikhail: Robotisasi adalah tiruan seseorang. Seseorang dapat ditiru dalam berbagai samaran. Anda bisa secara fisik. Robot itu berjalan seperti manusia. Robot itu mengklik monitor seperti manusia. Mengetik seperti manusia. Tidak pernah ada tiruan manusia yang lengkap. Namun aspek persaingan manusia adalah robotisasi.
- Mikhail, Yandex memburu Anda, tetapi Anda masih memutuskan untuk bekerja di ElectroNeek, apa motivasi Anda untuk bekerja di perusahaan rintisan, dan bukan dalam pekerjaan yang dijamin hangat?
Mikhail: Ketika Anda bekerja di sebuah startup, Anda sendiri adalah penempa dari kebahagiaan Anda sendiri, tetapi di perusahaan Anda terbatas.
- Michael, bagaimana kamu bisa tertangkap?
Mikhail: Pada saat itu, saya telah meninggalkan Akronis selama setahun, saya berhenti melihat vektor pengembangan saya, saya ingin mempelajari berbagai teknologi, melakukan proyek hewan peliharaan. Saya ingin melakukan sesuatu sendiri dan saya sedang mencari tim. Sementara itu, Dimitri dan Sergei sedang mencari CTO dan berteriak pada kenalan mereka. Saya mengenal Dmitry dari universitas, meskipun kami tidak banyak berkomunikasi, jadi kami berkumpul. Saya siap untuk proposal ini.
Saya perlu memahami apakah saya percaya pada proyek ini atau tidak. Kami bertemu dengan Sergei di sebuah kafe, dia dengan sangat dangkal menjelaskan kepada saya apa itu Electroneek, dan setelah pertemuan saya secara mandiri mempelajari topik RPA secara lebih rinci, melihat para pesaing.
Kami menelepon lagi, kami sudah bertiga. Sergey dan saya duduk bersebelahan, dan Dmitry sedang berada di Amerika pada saat itu. Kami berbicara tentang produk, bagaimana mereka melihatnya, di mana mereka berencana untuk mengembangkannya, untuk siapa produk itu, bagaimana kami akan menonjol dan mengapa ada “satu lagi pembuat robot” di pasaran.
Saya melihat ada permintaan, setidaknya di Rusia. Dmitry berbicara tentang pasar global, khususnya tentang Amerika Serikat. Dia sebelumnya bekerja di Ernst & Young dan menjalankan RPA untuk perusahaan Fortune 500 di sana, jadi dia tahu permintaannya dengan baik.
Sergey dan Dmitry memutuskan untuk membedakan diri mereka dari pesaing dengan UX yang sederhana dan nyaman, untuk membuat robotisasi lebih mudah diakses oleh perusahaan dalam berbagai ukuran. Saya perlu tahu apakah calon pendiri saya memahami seperti apa antarmukanya, apa sebenarnya kesejukannya. Saya mendengar jawaban jujur, "Kami tidak tahu." Orang-orang saat ini tidak tahu persis apa yang seharusnya, tetapi mereka berencana untuk mencoba dan mencari tahu.
Kejujuran dan keterbukaan seperti itu penting bagi saya. Saya suka mereka jujur tentang situasinya. Ini penting untuk hubungan di masa depan. Mengatakan segala sesuatu sebagaimana adanya, dan jika seseorang memadai, dia akan mengerti. Jika Anda jujur, jika kusen keluar di suatu tempat, Anda dapat langsung melihat cara menyelesaikan masalah, terlepas dari siapa yang mengacaukannya.
- Seperti apa penampilan Electroneek sebelum Anda bergabung dengan proyek?
Michael:Sebelum saya, ada prototipe kerja yang bisa ditampilkan. Itu adalah proyek di GitHub untuk menunjukkan apa yang akan mereka lakukan.
Ketika saya tiba, mereka menunjukkan kepada saya sebuah prototipe, menceritakan tentang para pesaing, tentang tugas-tugas yang perlu diselesaikan dan diminta untuk dikerjakan dengan baik . Bukan di atas lutut, tapi untuk waktu yang lama, supaya bisa berkembang. Tetapi tidak ada waktu untuk duduk dalam waktu lama untuk berkembang, perlu untuk berperang lebih cepat. Itu perlu untuk lari ke klien, itu perlu untuk menarik uang. Oleh karena itu, sejak hari pertama saya mulai menulis kode. Saya sudah familiar dengan Electron saat itu. (Elektron adalah kerangka kerja yang memungkinkan Anda menulis aplikasi desktop menggunakan tumpukan teknologi web.)
- Apa yang membuat pengembangan produk RPA berbeda dari yang lain?
Sergey:Apa perbedaan antara pengembangan platform RPA dan produk "dalam dirinya sendiri"? Platform RPA, khususnya ElectroNeek, adalah alat pengembangan. Sarana untuk menciptakan sesuatu dengan berinteraksi dengan sesuatu yang ketiga. Ini bukan produk terpisah seperti CRM, yang dengan sendirinya dan hanya terkadang melalui API berinteraksi dengan sesuatu yang lain.
Pengguna berbasis ElectroNeek membuat solusi perangkat lunak (robot) yang akan berinteraksi dengan produk lain yang terus berubah: browser, desktop. Anda tidak mengontrol lingkungan tempat hasil pengembangan akan berinteraksi. Hal ini membebankan tuntutan yang sangat besar pada kualitas, UX, dan pengembangan solusi produk.
- Mengapa produk RPA lain ada di pasaran?
Sergey:orang sering datang kepada kami dan berkata: "Mengapa Anda mengembangkan saat Anda dapat membuka beberapa situs web, mengunduh modul pengklik RPA yang sudah jadi, dan membuatnya?" Ya, dia bisa membuka buku catatan, merasa nyaman dengan penjelajah Internet, membuka Google. Tetapi begitu Anda melangkah lebih jauh (segera setelah XPath atau penyeleksi muncul), varian situs yang berbeda, ekosistem pemerintah atau SaaS, Anda akan menghadapi kenyataan bahwa itu belum siap dan tidak berfungsi. Dan kemudian, jika Anda mengembangkan platform Anda sendiri, Anda perlu beradaptasi dengan perubahan, dan jika semuanya sudah terprogram, maka Anda tidak dapat secara fleksibel beradaptasi dengan perubahan. Kami memilikinya di pilot.
- Bagaimana Anda memilih tumpukan teknologi?
Michael:Proyek ini menyiratkan bahwa akan ada desktop dan komponen web, bagian depan klasik, bagian belakang klasik, dan aplikasi desktop. Dan pada awalnya, proyek tersebut tidak melibatkan tim besar. Saya mengerti bahwa beberapa bulan pertama saya akan sendirian, kami tidak berencana untuk berkembang dengan kecepatan tinggi.
Saya perlu menyediakan semacam multi-stasiun sehingga 1-3 orang bisa melakukan semuanya. Itulah mengapa kami memilih Electron. Ini memungkinkan Anda untuk menulis aplikasi desktop, backend dan frontend dalam bahasa yang sama (kami memilikinya TypeScript).
Di masa depan, Anda dapat membuat spesialisasi, tetapi pada awalnya sangat nyaman ketika semua orang dapat melakukan segalanya.
Biasanya, ada masalah dalam mengalihkan konteks dari backend ke frontend. Misalnya, mendukung dengan python, depan dalam JavaScript, kombinasi populer. Dan bahkan jika satu orang menggabungkan ini dalam dirinya sendiri, akan mahal dan sulit baginya untuk beralih dari satu bahasa ke bahasa lain. Dan ketika Anda menyelesaikan satu masalah, Anda sering beralih, itu tidak nyaman. Kami menyingkirkan ini, tidak ada yang berubah saat beralih: satu bahasa, satu pendekatan, bahkan semuanya terlihat sama.
Kemudian saya mencari perpustakaan yang dapat segera menutup beberapa tugas saya, dan tidak mencoba menulis semuanya sendiri.
Pada awalnya, Anda tidak perlu mencoba mengendarai sesuatu. Ambil yang sudah jadi jika sesuai dengan kebutuhan Anda. Mungkin kemudian Anda benar-benar harus menarik bagian ini dan menggantinya dengan milik Anda sendiri. Tetapi pada saat yang sama, Anda akan segera memiliki benda kerja.
Saya mengambil perpustakaan yang sudah jadi untuk visualisasi. Produk utama kami adalah lingkungan pengembangan, dan ada visualisasi diagram alur. Secara alami, saya tidak menulisnya sendiri, tetapi mengambil perpustakaan joinjs open source. Ini memungkinkan Anda untuk bekerja di tingkat svg. Gambarlah antarmuka menggunakan gambar vektor.
Kami sudah lama duduk di atasnya. Terkadang kami berpikir kami akan menyingkirkannya, ini bisa dilakukan kapan saja, tetapi sejauh ini dia melakukan semua tugas dan menahan beban.
Penting untuk menulis semuanya secara modular sehingga Anda dapat membuang beberapa bagian dan tidak bingung di web kode Anda sendiri. Pendekatan modular memungkinkan Anda membuang pustaka dengan cepat.
Program kami bukan hanya editor diagram alur, tetapi juga memecahkan masalah tertentu - program ini mengotomatiskan desktop. Anda menggunakannya untuk mengelola aplikasi desktop.
Bagian penting dari program kami adalah perpustakaan tingkat rendah untuk berinteraksi dengan aplikasi, cara menekan tombol, menghitung gambar, membuat tangkapan layar.
Saya mengambil UIAvtomation library C # standar, yang juga digunakan oleh pesaing kami saat itu. Kami baru-baru ini menggantinya dengan yang lebih modern.
Pustaka ini memiliki pembungkus, API yang agak sempit yang kami gunakan. Kemudian kami dapat membuang pustaka ini, melampirkan yang baru dan merekatkannya dengan adaptor ke API ini. Itu terjadi dengan cepat dan tanpa rasa sakit, dan itu harus dilakukan.
- Bagaimana fitur diterapkan?
Mikhail: Saya berbicara dengan para pendiri, mereka memiliki pengalaman dalam mengintegrasikan solusi pesaing, mereka memahami fitur apa yang dibutuhkan. Mereka memberi saya daftar fitur yang sering mereka gunakan. Saya mulai membuatnya satu per satu.
Secara harfiah satu atau dua bulan kemudian, kami mulai melakukan proyek percontohan untuk Pos Rusia.
Kami telah memecahkan masalah otomatisasi bongkar muat untuk mereka. Mereka memiliki aplikasi HR desktop untuk manajemen resume. Tidak ada antarmuka, dan Anda harus mengeluarkan semua resume dari sana. Tidak ada API, tidak ada database, dan mereka tidak dapat menariknya keluar.
Kami baru saja mengklik aplikasi ini, mengambil data dari sana dan memasukkannya ke dalam disk.
Solusi utama tidak sulit, saya menulis algoritme dalam beberapa jam, tetapi iblis ada dalam detailnya. Banyak nuansa: jenis dokumen yang berbeda, beberapa jenis bidang mungkin tidak ada, dll. Saya menghabiskan lebih banyak waktu untuk menyelesaikan.
Untuk setiap fitur, saya bertanya pada diri sendiri solusi apa yang saya butuhkan sekarang agar di masa mendatang saya dapat menyelesaikan masalah semacam ini. Jika sebuah fitur lolos dari filter ini, saya menambahkannya. Pada awalnya, fitur ditambahkan tanpa banyak diskusi. Basis kode kecil, ditambahkan, dicoba, dihapus, itu mudah.
Saat aplikasinya sudah besar, setiap fitur perlu dibahas. Apa pengaruh fitur tersebut, apakah itu merusak sesuatu, dan apakah kita memiliki cara lain. Pada awalnya, mudah untuk melihat fitur, mereka tidak merusak apa pun, karena masih tidak ada yang rusak.
- Berapa skala pekerjaan untuk Pos Rusia?
Mikhail: Aplikasi tersebut berisi semua karyawan Pos Rusia di seluruh negeri. Tidak mungkin untuk meneriakkannya dengan tangan Anda.
Apa yang dilakukan robot kami. Dia memasuki pencarian dengan filter kosong. Hasilnya adalah daftar semua karyawan dengan scrolling di beberapa layar. Anda perlu mengklik setiap elemen daftar di lembar, jendela terbuka, ada bagian dari data dan beberapa tombol yang membuka jendela lain. Semua jendela harus dibuka, semua data harus digabungkan, jendela harus ditutup kembali dan pergi ke item berikutnya dalam daftar. Dan dengan iterasi seperti itu untuk mencuri segalanya. Berikut ringkasan kasar dari prosesnya.
Pilot itu saling bebas dan kami tidak membawanya ke status produksi. Untuk diri kami sendiri, kami membuat bukti konsep: di platform Anda dapat menyelesaikan masalah ini dan itu, Anda dapat menggunakan ini untuk mengumpulkan uang, Anda dapat menjual ke pelanggan dan menyelesaikannya saat dalam perjalanan. Inilah yang mulai kami lakukan.
- Bagaimana Anda menarik investasi?
Michael:Kami membutuhkan prototipe yang berfungsi yang akan membuat investor terkesan. Antarmuka solusi untuk Pos Rusia tidak cantik, ini dibuat oleh saya, dan saya bukan seorang desainer. Saya membuat sendiri, mode Gelap IDE WebStorm.
Tahap awal prototipe
ElectroNeek di tahun 2021
Investor tahu cara menggunakan imajinasi. Anda dapat menunjukkan kepada mereka prototipe yang bengkok dan memberi tahu mereka bagaimana itu akan berubah dan mereka akan mengerti. Prototipe bahkan mungkin buggy dan buggy, tetapi yang utama adalah menunjukkan sebutir makna sehingga investor dapat memahami esensinya. Klien perlu menunjukkan produk yang sudah jadi dan cantik. Orang yang memadai memahami perbedaan antara MVP dan produk akhir. Dan lebih baik tidak bekerja dengan yang tidak memadai. Anda mengambil investor untuk waktu yang lama, menyenangkan bekerja dengan orang-orang yang memadai.
- Seperti apa demonstrasi kepada investor?
Michael:Katakanlah saya menulis fungsi baru, dan besok pagi perlu ditunjukkan kepada investor. Saya mengerti bahwa itu tidak dapat ditampilkan dalam formulir ini. Mungkin ada sesuatu yang masuk, mungkin tidak ada contoh yang baik untuk menunjukkan fungsionalitasnya. Saya duduk di sana selesai pada malam hari, memberikan contoh, menangkap serangga sehingga terlihat bagus di pagi hari. Di pagi hari saya datang tanpa tidur untuk peragaan. Saya tunjukkan produk kepada investor. Hampir tanpa tidur, tapi berhasil.
Pada awalnya, tidak mungkin tanpa itu. Tidak ada proses pengembangan normal jika ada lingkungan dev yang lengkap, lingkungan pengujian, klasemen, produksi. Hanya ada satu lingkungan, itu untuk Anda berdiri dan produksi. Anda adalah satu-satunya dan tugas Anda adalah melakukannya lebih cepat. Dan Anda bekerja sebagai ahli bedah yang baru saja bersiap untuk operasi dan "membuka" kodenya, dan mereka berkata kepadanya: "Baiklah, ayo kita menjahitnya lebih cepat dan ayo pergi."
Saya harus melakukan segalanya dan mengikutinya. Selama aplikasinya kecil, itu pas di kepala, pengembang yang baik dapat melakukan semuanya sendiri dan tidak melewatkan apa pun. Ketika aplikasi berkembang, tidak mungkin dilakukan tanpa QE.
Sergei: Kami memiliki sumber daya yang terbatas, kami hanya menerima 150.000 dolar, 70.000 di antaranya berupa uang tunai. Ini semua yang diperlukan untuk menyelesaikan prototipe menjadi produk normal dan menunjukkan penjualan pertama di Rusia dan AS. Kemudian mereka mengumpulkan $ 0,5 juta. Kami menunjukkan penjualan yang cepat. Investor percaya pada kami.
Michael:Begitu uang muncul, mereka mulai memperluas tim untuk membuat produk yang bagus secepat mungkin. Apa artinya "baik"? Anda tidak membutuhkan produk yang sempurna sejak dini, meski bisa dibuat. Ini salah. Banyak orang tahu bagaimana melakukannya dengan sempurna, tetapi itu membutuhkan waktu lama. Jika cepat dan bagus, maka terlalu mahal. Semuanya tidak mungkin sekaligus. Oleh karena itu, harus dilakukan dengan cukup baik di sini . Cukup bagus untuk dijual.
Anda dapat membuat produk dengan bug, jika tidak kritis, tidak menembak di kaki, dan Anda dapat menambahkan fitur lebih cepat. Orang-orang membeli produk dengan bug, mereka melihat bug, melaporkannya, kami memperbaikinya di sana. Orang melihat umpan balik. Tidak ada masalah.
- Bagaimana Anda mempekerjakan pengembang?
Michael:Saya lebih fokus pada kemampuan daripada pengalaman. Pengalaman itu penting, tetapi perkembangan adalah sesuatu yang mengharuskan Anda terus-menerus mempelajari sesuatu. Ketika Anda harus menyeret perpustakaan baru ke dalam proyek, kemungkinan Anda mengetahuinya tidak akan terlalu tinggi. Pengetahuan dasar itu penting. Kami membutuhkan pengetahuan tentang TypeScript, butuh waktu lama untuk berlatih kembali ke bahasa lain. Kerangka ingin diketahui. Kami menggunakan dari Angular.
Penting bagi kami bahwa seseorang dapat dengan cepat menyelesaikan masalah yang kompleks tanpa kesalahan, atau dengan kesalahan yang mudah diperbaiki, yang akan keluar selama proses berjalan. Seseorang harus bisa banyak berpikir. Jika dia mampu memikirkan banyak hal, untuk memahami jenis kasing sudut yang ada secara umum, maka ini keren.
Sering terjadi bahwa orang menulis program, tetapi mereka tidak memikirkan beberapa kasus. Dan siapa yang akan dia pikirkan tentang mereka? QA mungkin juga tidak memikirkannya. Dan kemudian mereka menembak. Pada saat yang sama, data awal cukup untuk memprediksi kasus-kasus sudut ini. Bagi saya, inilah perbedaan antara pengembang yang menjanjikan dan yang tidak menjanjikan: berapa banyak kasus sudut di awal yang mampu ia antisipasi.
- Berapa banyak orang sekarang?
Mikhail: Enam orang - pengembangan inti, yang membuat platform secara langsung. Empat orang yang aktifjadikan platform solusi yang dapat digunakan kembali. Mereka menggunakan platform, ditambah alat tambahan dalam bahasa skrip, dan membuat proyek tertentu. Saya hanya berbicara tentang pengembang sekarang. Ada juga departemen QA, tim produk terpisah.
- Bagaimana Anda beralih dari pengkodean ke tanggung jawab manajerial sebagai CTO?
Mikhail: Setelah menerima investasi, saya aktif menulis kode selama beberapa bulan. Meskipun kami mempekerjakan QA, saya tidak terlalu yakin dengan mereka. Saya menulis review kode sendiri.
Kemudian saya melihat di papan kanban bahwa leher saya sempit. Dan saya mengerti bahwa inilah saatnya melepaskan kendali, untuk menerima bahwa masalah akan berlalu begitu saja dalam produksi.
Saya meninjau hal-hal yang paling kritis. Mulai mengandalkan QA. Itu adalah proses bertahap untuk melepaskan kendali. Ketika Anda melewati semuanya melalui diri Anda sendiri, Anda yakin akan hasilnya. Anda melihat semuanya, Anda dapat menangkap semua masalahnya sendiri. Tapi ini bukanlah cerita yang dapat diskalakan. Dia bagus pada awalnya, maka Anda harus menyingkirkannya secara diam-diam. Jadi saya secara bertahap melepaskan, mengulas hanya tempat-tempat kritis, dan kemudian berhenti menulis dan mengulas sama sekali. Sekarang semua orang melakukannya tanpa saya.
- Sekarang Anda sudah sepakat dengan penurunan kualitas, apa selanjutnya?
Mikhail: Begini, saya tidak lagi memiliki opsi untuk meninjau kode, kami telah melalui ini. Apa lagi yang bisa saya lakukan? Sekarang Anda dapat menyesuaikan prosesnya.
Katakanlah pengembang menggabungkan fitur berkualitas tidak terlalu tinggi ke dalam cabang utama. Mungkin ada yang salah dengan ulasannya. Kita lihat saja nanti. Anda melihat apa yang orang-orang ulas. Aha, untuk menarik perhatian orang-orang ini. Anda pergi ke instruksi. Proses debugging. Mencari titik lemah. Anda tidak mencoba melakukan pekerjaan, Anda menciptakan proses.
Di sinilah para pengembang mengulas, tetapi fitur-fiturnya masih belum terlalu digabungkan. Mari tambahkan uji fitur sebelum menggabungkannya. Ditambahkan. Apa yang terjadi? Sekarang QA tidak punya waktu untuk mengujinya. Oke, mungkin tidak semua fitur perlu diuji dengan cara ini, tetapi hanya fitur paling berbahaya yang memengaruhi keseluruhan proyek. Anda menyeimbangkan
Tidak ada templat untuk perusahaan yang berbeda, tetapi pendekatan umumnya sama - untuk menguji sistem Anda dan memperbaiki kemacetan secara prosedural. Maka itu sudah menjadi cerita yang dapat diskalakan.
Tugas saya adalah menemukan kemacetan di mana masalah proses berada, berbicara dengan orang-orang dan menerapkan solusi yang berfungsi.
Idealnya, jika saya minggir, maka semuanya bekerja. Itu tidak mungkin pada awalnya. Minggir, semuanya rusak. Dan sekarang seharusnya aku pergi selama sebulan dan tidak ada yang rusak.
- Bagaimana memahami kapan harus mempekerjakan orang yang spesial?
Mikhail: Apakah cukup untuk leher sempit pria ini? Jika seseorang setidaknya 70% sibuk dengan tugas ini, maka Anda dapat menyewa. Jika Anda membutuhkan seseorang 5% dari waktu, maka Anda mungkin bisa mengatasinya sendiri.
- Apa yang kamu lakukan sekarang?
Mikhail: Saya masih bertanggung jawab atas prosesnya. Dan saya akan berurusan dengan mereka untuk waktu yang lama.
Saya membahas fitur-fitur, seperti Sergey. Di sinilah produk kami tumbuh. Dia melewati itu melalui prisma sendiri, aku melalui milikku.
Kami adalah pengembang yang menulis alat pengembang. Saya tidak dapat melacak semua fitur yang kami lakukan, tetapi saya menganalisis yang penting, kompleks, kritis atau menarik dan memberikan umpan balik kepada tim produk, yang akan mengoptimalkan fitur berdasarkan fitur tersebut. Saya tidak dalam urusan mendeskripsikan, tetapi mendengarkan apa yang akan mereka lakukan dan memberikan umpan balik. Sergey melakukan hal yang sama dalam hal fitur. Ini adalah sesuatu yang pasti tidak akan kami lepaskan. Penting untuk memahami ke mana produk bergerak, ke mana kita mengembangkannya.
- Bagaimana kamu belajar?
Michael:Pertama, saya menyatakan masalahnya dengan jelas. Pengalaman hidup sudah memungkinkan Anda untuk memutuskan banyak hal. Saya sudah tahu lebih banyak daripada ketika saya lulus dari universitas, tetapi masih ada masalah yang saya tidak mengerti bagaimana menyelesaikannya.
Pertama, saya mencari tahu apa masalahnya. Katakanlah saya tidak punya alat. Saya mencari di Google, menonton YouTube atau kursus tertentu, mencari tahu bagaimana para profesional di bidang tertentu melakukannya.
Misalnya, bagaimana Anda menguji aplikasi besar ketika ada banyak pengujian manual? Kami tidak punya waktu, apa yang harus dilakukan?
Jika Anda bukan QA yang keren di masa lalu, maka Anda secara tidak langsung memahami apa itu, tetapi Anda mungkin tidak tahu beberapa perbedaannya. Saya membuka YouTube, mendengarkan ceramah QA selama satu jam dengan pengalaman bertahun-tahun, saya memahami bahwa apa yang saya dengar dapat diterapkan, saya coba, saya analisis. Jika cocok, saya tinggalkan.
Tidak mungkin untuk mengetahui segalanya. Tugas setiap manajer adalah mempelajari segala sesuatu yang mungkin, mendelegasikan dan mempertahankan fungsi kontrol.
Tetapkan kerangka kerja tempat orang bekerja, dan kendalikan hasilnya dalam kerangka ini. Mereka membuat keputusan sendiri.
Jika ada masalah di pasar, keputusan bisa dibuat tanpa saya. QA mengatakan bahwa tugas tersebut penting dan mungkin memutuskan untuk membatalkannya. Saya tidak perlu bangun untuk ini. Hal utama adalah orang memahami kerangka kerja.
- Nasihat untuk diri Anda sendiri di masa muda Anda?
Michael:Pada awalnya saya merasa bahwa pada awalnya saya harus belajar banyak. Sesuatu yang saya belum tahu. Saya tidak bisa menulis situs web, saya tidak bisa menulis backend. Saya ingin mengambil kursus atau menyelesaikan universitas. Tidak juga. Ambil dan cobalah. Google adalah alat yang hebat, semuanya ada di sana. Pecahkan masalah dengan tepat. Anda tidak tahu bagaimana untuk melakukannya secara khusus, dan belajar untuk melakukan itu secara khusus . Anda tidak tahu cara mengkonfigurasi nginx, jadi pelajari ini secara khusus.
Anda tidak bisa mempelajari semuanya. Terlalu memakan waktu untuk mengikuti kursus pemrograman beberapa minggu. Lebih baik mulai pemrograman. Masalah-masalah yang akan muncul untuk Anda, dan menyelesaikannya. Lebih cepat seperti ini. Dan bahkan lebih tenggelam dalam masalah daripada membaca buku. Jika Anda membaca 600 halaman dari sampul ke sampul, maka pengetahuannya akan menjadi dangkal. Pengetahuan lebih dalam pada pengalaman.
Saya "menemukan Google" dalam arti bahwa saya dapat, dengan pengetahuan saya, melakukan hal-hal rumit, mencari di Google, dan menemukan solusi titik untuk colokan. Inilah cara saya berkembang di masa depan.
Saya membaca buku dengan selektif. Ketika saya sedang memecahkan masalah, saya menemukan sebuah fragmen yang menjelaskan solusinya. Artikelnya sama. Anda juga tidak bisa menonton ceramah secara utuh. Kuliah selama 4 jam. Temukan kode waktu, lihat saja bagian yang menarik, mungkin cukup.
- Beritahu kami tentang Service Organization Controls (SOC)?
Sergey: Jika Anda ingin membuat aplikasi SaaS di pasar Amerika, terutama sesuatu yang akan bekerja di perusahaan dengan lebih dari 200-500 orang, pertanyaan tentang SOC (Security Organization Control) akan segera muncul. Meskipun Anda tidak memilikinya, semua orang bertanya padanya. Ini adalah cerita yang menyisir kebijakan organisasi, distribusi berdasarkan tingkat hak dan akses, bagaimana merancang kode, auditor datang dan memeriksa.
Sampai Anda memilikinya, semua klien biasa akan memintanya dan tidak menandatangani kontrak. Segera setelah muncul, dan Anda berkata "ini dia, jika Anda ingin mengirim laporan", klien menjawab bahwa itu tidak perlu, "kami tidak ingin membaca laporan tersebut".
Ini memakan waktu empat bulan, dibereskan, dan sedang diperiksa. Serangkaian aktivitas yang memengaruhi seluruh tumpukan teknologi. Michael tahu, dia yang mendorong proses ini sepenuhnya.
Mikhail: Kami adalah organisasi yang menyediakan layanan kepada klien. SOC adalah tentang alat apa yang kita miliki di dalam diri kita untuk memastikan keamanan, ketersediaan, dan kontinuitas layanan serta keamanan data. Semua hal yang menarik minat klien besar dan sedikit minat untuk organisasi kecil.
Jika klien kami adalah organisasi besar, maka kurangnya SOC mungkin menjadi masalah bagi mereka. Peraturan mereka tidak mengizinkan bekerja dengan Anda. Oleh karena itu, pada saat tertentu hal itu muncul ke permukaan bagi kami.
Entah Anda memiliki sertifikasi ini, SOC (masih mahal untuk pemula yang baru mulai), atau perusahaan mengirimkan kuesioner multi-halaman tentang keamanan Anda. Anda membacanya dan Anda tidak mengerti setengahnya.
Anda bisa mengisinya untuk waktu yang lama, karena tidak selalu jelas tentang apa pidato itu. Plus, saat Anda mengisi, Anda memahami bahwa kami tidak memiliki ini. Dan bukan ini masalahnya. Dan ini juga tidak ada. Dan tidak ada gunanya mengirimkan kuesioner ini. Dan tampaknya tidak terlalu sulit untuk mewujudkannya. Tapi ini harus dilakukan.
Pada titik tertentu, kami menyadari bahwa klien seperti itu datang kepada kami, kami mengisi kuesioner mereka untuk waktu yang lama, tetapi sebagai hasil dari transaksi tidak ada. Kami memutuskan untuk menangani masalah ini.
Sertifikasi ini adalah proses pemantauan dan berkelanjutan. Bukan berarti Anda melakukannya sekali dan hanya itu. Anda harus meletakkan beberapa jenis "kotak centang" secara teratur. Data Anda selalu dienkripsi selama transmisi. Anda memiliki data yang selalu dienkripsi di server, jika data itu hilang di suatu tempat di hard drive, tidak ada yang akan menarik apa pun dari sana. Ada banyak contoh dan contoh yang lebih canggih juga.
Saat Anda mulai googling cara melakukan ini, Anda menemukan lembar A4 60-lembar, apa yang harus dilakukan dan bagaimana melakukannya. Dan setiap poin perlu dibongkar, karena Anda tidak memahaminya. Sepertinya pekerjaan yang sangat lama.
Oke, ini adalah jalan yang akan kita tempuh untuk waktu yang lama. Atau mungkin kita bisa menemukan perusahaan yang akan membuat hidup kita lebih mudah? Perusahaan kita. Saat itu kami sudah berada di Y Combinator. Kami menanyakan pertanyaan ini kepada orang-orang dari sana, kami diminta oleh alumni YC yang akan mengotomatiskan cerita ini. Layanan ini tidak gratis, tetapi kami membeli layanan dari mereka. Ini adalah semacam panel admin tempat Anda mengintegrasikan semua layanan Anda. JetSuit, Bitbucket, Gitlab, Jira, AWS, Azure, siapa yang memiliki apa. Program itu sendiri mempelajari di mana Anda memiliki pengaturan apa, dan mengatakan apa dan di mana Anda hilang. Anda memperbaikinya dengan tepat dan semua item di sheet ini akan ditutup secara otomatis.
Setelah itu, auditor diundang, yang menegaskan bahwa semuanya benar-benar ada dan menetapkan "tes". Inilah cara kami menyederhanakan hidup kami.
Untuk perusahaan besar, ini adalah formalitas, tanpanya mereka tidak dapat melangkah lebih jauh dan bekerja sama dengan kami. Nah, sebagai nilai tambah, peningkatan nyata dalam keamanan pelanggan.
- Beritahu kami tentang Y Combinator dari sudut pandang pengembang?
Mikhail: Saya tidak begitu mengerti untuk apa YC itu. Jelas bahwa ini adalah gengsi. Dan tujuan spesifiknya sulit untuk saya pahami. Saya membaca tentang bagaimana itu bisa ada di sana. Sulit bagi saya untuk membayangkan pengalaman bermanfaat seperti apa yang bisa didapat seseorang di sana. Saya cukup skeptis tentang fakta bahwa saya akan meningkat sebagai seorang profesional. Tetapi saya mengerti bahwa ini adalah pencapaian yang berguna bagi perusahaan secara keseluruhan.
Jika kita berbicara tentang hasilnya. Kami mendapat lebih banyak keuntungan bisnis. Mereka juga membantu dengan sumber daya teknis dan masih membantu. Kami membuat infrastruktur yang lebih tepat di cloud.
Kesimpulan utama dari cerita ini adalah jika Anda siap menggunakan produk yang disediakan YC, siap untuk menggali lebih dalam pemahaman mereka, maka ini akan menjadi nilai tambah yang besar.
Kami menyelesaikan YC pada Maret 2020, menutup putaran dengan $ 2,5 juta. Pertumbuhan yang signifikan dari tim pengembangan dan tugas dimulai.
- Bagaimana Anda bisa bergabung dengan tim produk saat ini?
Mikhail: Produk kami cukup kompleks, Anda perlu menjadi pengembang untuk memahami produk untuk pengembang. Anda perlu memahami dari sudut pandang pengembang fitur apa yang akan diterapkan, bagaimana klien kami menggunakannya. Di sisi lain, penting untuk menjadi pengusaha yang baik, peneliti pasar. Gabungkan semua kompetensi ini. Ada beberapa kesulitan dengan ini.
Sergey:Selama 4-5 bulan terakhir dari Maret hingga Agustus, pertama-tama kami mempekerjakan satu manajer produk yang memiliki pengalaman dalam RPA. Kami bekerja dengannya selama beberapa bulan dan tidak mendapatkan hasil apa pun. Kami tidak mempekerjakan manajer produk dari seri "Kami akan mempekerjakan Anda dan emas akan segera mengalir", kami ingin memahami dengan jelas fitur apa yang kami lakukan, fitur tersebut diperlukan untuk menangkap pasar di masa depan, untuk menyelesaikannya masalah klien tertentu, untuk upselling. Kami mengambil produk untuk metrik yang cukup terukur dan mendiskusikannya. Sayangnya, kedua produk itu bergulir. Ini salah kita juga. Kami mempekerjakan orang yang menawarkan untuk membuat fitur tersebut, "karena itu indah". Berapa banyak uang yang akan dia bawa? Yah, sulit untuk menghitung ... Siapa yang akan dia bantu? Bagaimana ini bisa membantu Anda memenangkan perdagangan saat ini, atau setidaknya tidak kehilangannya? Kami tidak berhasil membangun cerita seperti itu.
Apa yang akhirnya kita dapatkan. Skema yang sangat nyaman bagi kami, ini sangat mendorong perusahaan kami.
Kami memiliki manajer produk UX, manajer produk teknologi, kami memiliki Kepala Teknik, kami memiliki CTO, dan kami memiliki CEO sebagai perwakilan bisnis. Kami telah membentuk kantor grosir di mana produk "dipotong" menjadi beberapa bagian. UX, analisis fitur baru, rekayasa. Mikhail dan saya berperan sebagai fasilitator dalam hal pembuatan prioritas. Saya juga bertanggung jawab atas fitur penjualan. Dmitry melihat bagaimana fitur produk atau dapat diterjemahkan ke dalam peluang dan alat pemasaran seperti perpustakaan bot global kami yang dibuat oleh pelanggan dan mitra.
Kami memiliki sesi spontan untuk membahas masalah serius. Kami juga memiliki panggilan setengah jam mingguan di mana kami merencanakan sprint berikutnya, yang telah diprioritaskan di dalam perusahaan. Fitur baru muncul dalam tiga jalur: bug - kami memperbaiki sesuatu yang tidak berfungsi, memperlambat penjualan, atau mengganggu pelanggan saat ini; UX - kami memperbaiki yang sekarang, karena kami tahu bahwa produk selalu dapat ditingkatkan; kami menambahkan sesuatu yang baru pada produk, yang akan memungkinkan kami menjadi lebih efektif di masa mendatang. Kami bekerja dalam kerangka seperti itu. Kami ingin membahas satu orang yang terlibat dalam keseluruhan produk, tetapi sejauh ini tampaknya sulit bagi kami.
Saya ingin menyarankan wirausahawan masa depan, terutama teknisi, untuk tidak mencoba hanya mempertimbangkan satu opsi (bahwa CEO harus menemukan pemilik produk), tetapi ada format interaksi terdistribusi yang memberikan hasil.
- Apakah mungkin dengan bantuan robot Anda bertani di game komputer, klik di YouTube?
Dmitry: Di markas kami, satu klien membuat robot yang menyalakan ketel.
Sergey: Robot dapat menekan tombol apa saja. Kami memberikan alat pengembangan. Apa yang dibangun klien di atasnya adalah tanggung jawab orang. Anda dapat membangun apapun yang Anda inginkan.
Sergey:Kami punya satu cerita. Klien membeli layanan tersebut, dan kemudian menulis: “Saya secara khusus memilih gadis yang paling tidak berkembang di bidang IT di perusahaan kami, Olya. Maka "Olya" bisa membuat robot dengan bantuan ElectroNeek. Jika "Olya" bisa melakukannya, siapa pun di perusahaan saya bisa. Saya membeli produk dari Anda! " Ini adalah indikator kemudahan penggunaan yang tinggi. Meski kebanyakan developer junior atau menengah menggunakan kami. Mereka menerima produk, di tumpukan apa pun (web, desktop, apakah ada API atau tidak), membuat aplikasi (robot?), Ini adalah kebebasan yang diberikan produk kami.
Dmitriy:Ketika suatu produk sampai ke investor pada tahap awal, cerita dengan Olya terulang di sana, ada Oli di antara investor. Ada situasi ketika mitra dana top Amerika masuk ke produk (Gary Ten dari Inisialisasi, mantan mitra YC dan investor di Coinbase dan Instacart). Rekannya mulai merakit robot dengan tangannya.
Bonus: mengumpulkan robot secara langsung
Baca lebih banyak
- Luncurkan HN: ElectroNeek (YC W20) - Secara otomatis mencari dan mengotomatiskan pekerjaan rutin
- Bagaimana empat orang Rusia menciptakan pabrik "karyawan digital" dan menghasilkan $ 1 juta darinya
- electroNeek RPA - robot perangkat lunak membantu orang
- Tentang robotisasi bisnis dengan Farida Roslovets dan direktur electroNeek perusahaan RPA