Kita semua kira-kira membayangkan seperti apa perkembangan di sebuah perusahaan besar dan bagaimana perkembangan kecil bisa berbeda dari itu. Tetapi apa yang terjadi jika ukuran perusahaan berubah dengan cepat dan jumlah karyawan meningkat sepuluh kali lipat selama beberapa tahun? Ketika sebuah startup tumbuh dengan cepat, dan Anda perlu beradaptasi dengan keadaan baru saat bepergian, bagaimana hal ini memengaruhi segalanya (dari proses hingga teknologi)?
ManyChat akan berpartisipasi dalam konferensi HolyJS kami, dan itulah yang sebenarnya terjadi. Oleh karena itu, kami meminta dukungan teknis untuk pengembangan frontend
Evgeny Kuvshinov dan secara khusus tentang ManyChat, dan secara umum tentang bagaimana rasanya melakukan pengembangan (front-end) dalam sebuah startup.
- Pertama, beri tahu kami secara singkat apa yang Anda lakukan di ManyChat dan apa yang dilakukan perusahaan itu sendiri.- Saya datang ke perusahaan hanya sebagai pengembang front-end, enam bulan kemudian saya tumbuh sebagai pemimpin tim front-end. Kemudian kami masih memiliki tim fungsional seperti - depan, belakang, pengujian, produk. Dan setelah kami membangun kembali semua proses kami di LeSS, saya kembali ke pengembangan, dan saya hampir tidak punya tugas organisasi sebelumnya. Saya terlibat dalam pengalaman pengguna, saya mencoba untuk berhubungan dengan bagian produk, sebagian tumbuh sebagai manajer produk, tetapi pada saat yang sama terus-menerus menulis kode.
Sebagai perusahaan, kami membantu bisnis menggunakan saluran komunikasi yang relatif baru, Facebook Messenger. ManyChat adalah platform untuk membuat obrolan bot Chat dengan cepat dan mudah. Ini bukan tentang kecerdasan buatan, bukan tentang upaya untuk meniru komunikasi manusia, tetapi tentang skenario di mana ini tidak diperlukan. Dengan bantuan bot kami, Anda hanya dapat membuat buletin, dan Anda dapat mengatur hal-hal interaktif yang lebih kompleks seperti pesanan, pemesanan, program loyalitas. Mereka juga dilakukan secara visual dan jelas, dan ini dapat dilakukan baik oleh pemilik bisnis yang cukup maju atau pemasar tanpa keterampilan pemrograman.
Anda dapat melihat bagaimana bot bekerja di Messenger secara umum, menggunakan contoh spesifik: pada waktunya untuk HolyJS, kami membuat
bot khusus .
- Tentunya Anda terus-menerus mendengar kata-kata "Tapi bot obrolan gagal beberapa tahun yang lalu." Apakah pengalaman Anda menunjukkan bahwa, secara umum, dalam konteks tertentu, apakah mereka cukup tepat?- Ya. Mungkin yang terpenting, kemanfaatan terbukti tidak hanya oleh kasus kami, tetapi oleh platform WeChat. Ini adalah messenger yang digunakan hampir semua orang di China, ada banyak bisnis di dalamnya, dan hal-hal seperti memesan pizza atau taksi di China sekarang aktif terjadi melalui WeChat. Dan ini menunjukkan bahwa skenario interaktif tertentu dari komunikasi manusia dan bisnis benar-benar berfungsi dengan baik, mudah bagi kedua belah pihak.
Dan kegunaan yang muncul beberapa tahun yang lalu - seperti Anda dapat berkomunikasi dengan bot sebagai pribadi dan ia akan menawarkan versi terbaik dari penerbangan ke pesawat - yah, itu benar-benar tidak bekerja dengan baik.
Dan kami menerapkan sesuatu yang dekat dengan WeChat, tetapi di pasar lain: di tempat pertama, di AS, meskipun di seluruh dunia juga. Kami memiliki jumlah pelanggan yang cukup besar dari Eropa, dan di negara-negara dekat China, banyak juga yang sekarang menggunakan Facebook Messenger.
- Beralih ke topik pertumbuhan: berapa lama perusahaan muncul, dan bagaimana perkembangannya dari saat itu ke zaman kita?- Perusahaan muncul pada tahun 2015. Itu dimulai dengan fakta bahwa co-founder-nya Mikael Jan perlu membuat buletin tentang Telegram (maka belum ada saluran di sana). Dia menyadari bahwa itu cukup rumit, dan alat khusus akan berguna. Akibatnya, Michael dan Anton Gorin pertama kali membuat platform untuk membuat bot di Telegram. Platform mulai tumbuh cukup cepat, mereka menekan akselerator startup di Lembah.
Dan saat mereka berada di akselerator, Facebook membuka API untuk Messenger. Dan itulah saat ketika mereka memutuskan untuk membuat poros tajam, untuk membuat produk baru khusus untuk Facebook Messenger. Penonton bulanan Messenger adalah 1,4 miliar orang, dan di Facebook banyak perusahaan memiliki perwakilan mereka dalam bentuk halaman resmi. Dan untuk halaman ini Anda dapat membuat bot.
Awalnya, ada tiga karyawan: Michael, Anton dan pengembang lain yang membuat versi pertama dari frontend. Pada musim gugur tahun yang sama, investasi pertama diterima dan menjadi jelas bahwa Anda dapat mulai memperluas tim. Lalu saya dan tiga pengembang lain datang ke perusahaan, jadi pada akhir 2016 ada tujuh dari kami. Dan sekarang, dua tahun kemudian, sudah ada lebih dari lima puluh dari kita, dan pertumbuhan terus berlanjut.
Jika Anda melihat jumlah platform itu sendiri, maka kami sudah memiliki lebih dari 400.000 bot yang terhubung. Dan kami tumbuh dengan baik dalam hal indikator keuangan: sudah pada saat ini kami adalah perusahaan yang menguntungkan, sementara kami terus mencari investasi untuk tumbuh lebih aktif. Tahun depan kami berencana untuk menggandakan setidaknya dalam hal jumlah orang.
- Startup adalah bidang yang sangat eksperimental di mana banyak dilakukan dengan coba-coba (seperti pivot yang disebutkan, ketika kita mulai dengan satu konsep, dan kemudian berubah saat bepergian). Bagaimana ini mempengaruhi perkembangan? Apakah ini berarti Anda harus selalu siap menghadapi situasi "fitur yang Anda terapkan akan dibuang"?- Memang, ada hal seperti itu yang dapat Anda lakukan beberapa fitur, tetapi pada akhirnya itu tidak akan diminati oleh pengguna, itu akan memiliki adopsi rendah. Atau dia mungkin tidak dapat produksi sama sekali, karena kita sendiri, melihat apa yang terjadi, akan mengerti bahwa kita tidak menyukainya.
Untuk meminimalkan jumlah situasi seperti itu, hal pertama yang kita pikirkan (bahkan tidak selama pengembangan, tetapi pada awal pengembangan produk dari fitur) adalah motivasi. Mengapa kita melakukannya, untuk siapa, seberapa besar pengaruhnya terhadap pengguna yang ada, seberapa kita menyukainya sendiri (apakah kita akan senang dan bangga bahwa hal seperti itu telah muncul dalam produk kita). Setelah memutuskan motivasi, mungkin dengan melakukan survei di komunitas pengguna kami atau wawancara lain dengan pengguna kami, kami mulai berkembang. Selanjutnya, kami menyiapkan fitur untuk sprinting, proses seperti itu disebut PBR (Product Backlog Refinement): pertama masuk ke backlog, kemudian naik ke sana di peringkat, dan pada titik tertentu, sudah dijelaskan dengan baik, mungkin jatuh ke dalam sprint.
Langsung di sprint, hal pertama yang kita lakukan adalah jika kita tidak mengerti bagaimana tampilannya, kita membuat beberapa mock-up dan prototipe. Tapi, betapapun anehnya kedengarannya, terkadang sudah dilakukan dengan pengembangan. Karena terkadang sangat sulit untuk memahami bagaimana perasaan pengguna dengan antarmuka, hanya dengan membuat semacam tata letak dan menggambar ilustrasi.
Cukup sering, di ujung depan, kami membuat prototipe atau fitur interaktif yang, pada prinsipnya, sudah berfungsi, Anda dapat mengklik dan merasakannya. Dan kemudian, dalam kerja sama yang erat dengan desainer, kami membawa prototipe ini ke opsi yang akan diproduksi. Namun, bagaimanapun, ketika membuat prototipe ini di sini, itu juga tidak biasa ketika Anda membuatnya, lihat, dan Anda memahami diri sendiri "tidak, itu tidak akan berhenti, itu tidak nyaman". Kami mencoba menggunakan produk kami sendiri, membuat bot, sehingga bahkan sebelum pengguna kami mengetahui di mana beberapa masalah mungkin timbul. Secara umum, kami fokus pada pengalaman pengguna, kami mencoba membangun platform yang paling mudah digunakan.
- Dengan pertumbuhan perusahaan yang cepat, Anda mungkin menemukan fakta bahwa proses yang berhasil bagi beberapa orang berhenti bekerja ketika pindah ke lusinan orang. Bagaimana perkembangan Anda berubah dari sudut pandang organisasi?- Itu sulit. Pada awal tahun, kami memiliki situasi yang agak sulit, ketika kami melakukan beberapa fitur selama beberapa bulan, mereka terus-menerus dapat "menyelesaikannya sedikit dan membuatnya menjadi produksi", tetapi ini "masih sedikit" tidak datang.
Ketika kami pertama kali mulai, ada tujuh dari kami. Kami memiliki scrum, ada sprint, semuanya dibangun dan berjalan cukup baik. Ketika kami tumbuh hingga 20-30 orang, kami, seperti di banyak perusahaan, muncul tim fungsional: backend, frontend. Dengan prosesnya sendiri, dengan sprintnya sendiri di dalam, dengan antrian tugasnya sendiri. Dan kami tidak melakukan tugas yang secara khusus disebut "fitur ini dan itu yang akan membawa manfaat ini dan itu untuk pengguna ini dan itu." Tugas masing-masing tim dipanggil dalam semangat "frontend: untuk mengatur ulang antarmuka seperti itu jadi, tambahkan beberapa tombol".
Dan itu buruk karena banyak alasan. Pertama-tama, ketika kita memiliki banyak antrian dan potongan tugas bisnis yang sama, mereka memiliki prioritas yang berbeda, menjadi hampir mustahil untuk memahami kapan tugas akan sepenuhnya siap. Dan menjadi lebih sulit bagi pengembang tertentu untuk memahami apa yang dia lakukan. Karena dia membuat beberapa bagian yang dideskripsikan untuknya, dan bagaimana pengguna kemudian akan bersukacita pada hasilnya, dia tidak tahu, karena dia bahkan mungkin tidak tahu dalam banyak hal mengapa semua ini diperlukan.
Pada titik tertentu, kami menyadari bahwa ini tidak mungkin berikutnya. Ya, Anda dapat menyetel sedikit, iterate, terus melakukan sprint dan stand-up harian (yang mulai memakan waktu lebih dari setengah jam, karena mereka dihadiri oleh seluruh tim, tetapi yang tidak memberikan apa-apa). Tapi ini adalah tindakan kosmetik yang tidak menyelesaikan masalah utama.
Dan pada saat itu salah satu dari orang-orang di perusahaan memberi tahu kami bahwa ada sesuatu yang disebut LeSS atau Scrum Skala Besar: scrum untuk tim yang sudah besar dan berkembang. Setelah duduk beberapa malam di ruang rapat, mendiskusikan segala sesuatu yang terjadi dengan kami, CEO dan CTO (Mika dan Anton) membuat keputusan bisnis yang sangat sulit: kami akan membuang seluruh proses pengembangan (bagaimana kami merancang fitur, mengimplementasikan dan meluncurkan) ke tempat sampah. Kami akan menyelesaikan sprint sekarang, dan kemudian kami akan membangun semuanya lagi.
Keputusan itu sulit, dan menyadari bahwa kami melakukan ini, kami berpikir untuk waktu yang lama: "Sial, apakah akan berhasil atau tidak?" Tetapi kami memutuskan untuk mencoba semuanya, beralih ke buku tentang LeSS dan pelatih yang bersertifikat. Mereka memulai dengan cara baru, membuat tim lintas fungsi - pada awalnya ada tiga dari mereka. Kami meluncurkan sprint mingguan pendek sesuai dengan aturan LeSS (aturan dalam arti set pertemuan apa yang seharusnya dilakukan pada sprint ini). Saya tidak akan memberi tahu semua perinciannya, tetapi untuk sprint mingguan pertama dari delapan tugas yang tampaknya tidak dapat kami lakukan selama beberapa bulan, kami memulai produksi, jika tidak semua, maka sebagian besar. Dan kami tidak mengerti apa yang sedang terjadi. Bagaimana bisa begitu? Kenapa kita tidak bisa melakukan ini sebelumnya? Dan mengapa itu terjadi? Itu sangat keren dan kami mulai bergerak, mengambil tugas baru, menyelesaikannya dalam tim lintas fungsi jauh lebih cepat.
Tentu saja, ada beberapa kesulitan dan kesalahpahaman juga. Tetapi secara keseluruhan, mungkin, bagi sebagian besar tim, proses yang muncul sangat populer, karena waktu untuk memasarkan fitur kami telah berkurang secara signifikan, Anda dapat melakukan segalanya dengan sangat cepat, mulai memproduksi. Selain itu, kami mencoba menyampaikan umpan balik dari pengguna kami sehingga pengembang dapat melihat seberapa banyak orang menyukai apa yang mereka lakukan.
Hal lain yang menarik adalah bagaimana kita menggelar frontend setelah kita beralih ke LeSS. Kami menyadari bahwa kami sekarang dibagi menjadi tim lintas fungsi yang terpisah, dan pertama kali (setidaknya sebelum komunitas front-end mulai bekerja), kami akan berkomunikasi jauh lebih sedikit. Dan kami belajar untuk menggulirkan frontend kapan saja “dengan satu klik jari”, ketika kami membutuhkannya ... Kami memiliki satu pertemuan tunggal sebelum dimulainya sprint baru, di mana kami mengatakan bahwa kami memiliki cabang utama kami, dan itu dapat diluncurkan kapan saja . Sebelum itu, saya memiliki pemikiran bahwa kita harus membangun sistem tes UI integrasi yang akan memeriksa setiap perakitan, bahwa harus ada persentase besar dari cakupan, dan hanya jika "hijau" kita dapat menggulung. Tapi itu adalah mimpi pipa, karena produk ini tumbuh sangat cepat, dan dalam hal ini, tidak peduli seberapa keras Anda mencoba, Anda masih tidak akan dapat mempertahankan persentase cakupan yang besar. Sebagai hasilnya, setelah setuju dengan semua pengembang dan memberi mereka tanggung jawab ini, kami berhasil membuatnya sehingga sekarang kode dari cabang utama kami benar-benar selalu berfungsi dan kami selalu dapat mengambil dan meluncurkan semua perakitan yang kami butuhkan dari sana.
- Wow, terima kasih atas jawaban terinci. Saya ingin berasumsi bahwa, di samping transisi yang dijelaskan, seharusnya juga ada transisi dari penumpukan penuh ke spesialisasi yang sempit: ketika hanya sedikit orang yang melakukan segala sesuatu dalam proyek, mau tidak mau harus melakukan berbagai hal, dan ketika lebih dari lima puluh, setiap orang memiliki lingkaran yang jelas tugas. Benarkah begitu?- Ketika kami masih sedikit, kami benar-benar harus menyelesaikan banyak masalah dari berbagai bidang. Sebagai contoh, untuk beberapa waktu saya terlibat dalam administrasi sistem dan mengatur sistem CI. Dan sekarang, dengan transisi ke LeSS, ini jauh lebih sedikit.
Tetapi ini tidak berarti bahwa sekarang semua orang terkunci dalam peran yang sempit. Ketika Anda datang ke perusahaan, Anda memiliki kompetensi utama (baik itu setidaknya back-end, setidaknya seorang desainer), dan tidak ada yang akan menghentikan Anda dari memompa vertikal ini ke ruang angkasa, tetapi pada saat yang sama, LeSS memberikan kesempatan (hanya kesempatan) untuk berkembang ke arah terkait .
Kami dibagi menjadi tim scrum standar kecil di mana ada enam (plus atau minus tiga) orang yang berkumpul bersama dan duduk di sebelah meja yang berdekatan. Ini berarti bahwa front-end selalu dapat berkomunikasi dengan back-end dan desainer. Selain fakta bahwa komunikasi keren dibangun dengan cara ini, Anda juga dapat belajar dari orang-orang ini. Dan kami menyambut jika orang yang terlibat di depan, misalnya, untuk sprint ini ingin mengambil tugas backend kecil dan memompa area ini. Karena semakin banyak pengetahuan yang Anda miliki dari berbagai bidang, semakin banyak Anda fokus pada keseluruhan produk, dan kemudian Anda lebih berhasil mengatasi masalah Anda. Ketika Anda mulai memahami mengapa desainer melakukan ini, mengapa ahli produk melakukannya, kadang-kadang Anda dapat mulai membangun antarmuka sendiri, yang kemudian Anda tunjukkan kepada mereka, dan mereka berkata "ya, keren." Dan, karenanya, Anda dapat melakukan pekerjaan Anda lebih cepat.
- Startup berada di garis depan kemajuan. Apakah ini berarti bahwa ketika memilih teknologi, Anda dapat dengan mudah menyeret sesuatu yang benar-benar baru ke dalam produksi? Dan adakah tindakan pencegahan agar ini tidak berubah menjadi pengejaran “hal-hal baru yang mengkilap” yang dapat membahayakan perusahaan?- Jawaban singkatnya adalah ya, supernova, keren dan menarik mungkin, kami menyambut ini dengan segala cara. Tapi, tentu saja, ada kriteria tertentu untuk pengenalan teknologi baru.
Jika Anda menemukan teknologi yang menarik minat Anda, maka Anda harus membawanya ke komunitas. Meskipun kami tidak lagi memiliki tim front-end di perusahaan kami, ada komunitas front-end di mana kami secara berkala mengumpulkan dan mendiskusikan masalah-masalah seperti itu. Di sana Anda dapat memberi tahu semua orang mengapa itu hebat dan mengapa akan lebih mudah untuk hidup dengannya di masa depan. Beberapa perusahaan mungkin memiliki semacam sistem seleksi khusus, tabel rumit dengan perbandingan yang perlu diisi. Kami tidak memiliki hal seperti itu, semua keputusan dibuat pada tingkat sensasi yang sangat subyektif, tetapi pada saat yang sama, teknologi yang sangat bagus dan menarik muncul cukup cepat.
Terkadang ada hal-hal yang belum mencapai rilis. Kami mulai menggunakan perpustakaan untuk membuat panel di Bereaksi, ketika masih cukup mentah, dan, sejauh yang saya ingat, bahkan ada sedikit yang disumbangkan. Kami mulai menggunakan Babel 7 dengan semacam beta karena memungkinkan kami membangun proyek sedikit lebih cepat dari yang sebelumnya.
Dan, mungkin, tidak ada seorang pun di tim yang pernah mengeluh bahwa dia menginginkan hal keren baru, tetapi mereka berkata kepadanya: "Tidak, kami memiliki kebijakan seperti itu, kami tidak akan melakukan itu." Dan sementara saya tidak dapat mengingat satu masalah yang akan menyebabkan pendekatan seperti itu, menyambut teknologi baru yang menarik. Sangat aneh bagi saya, karena, dalam pengalaman saya sebelumnya, saya membuat banyak keputusan yang salah pada level ini. Tetapi di ManyChat, mungkin hanya dengan bantuan komunitas, mungkin karena alasan lain, kami tidak memiliki file-file ini ketika kami memilih sesuatu, dan kemudian kami harus mengambil dan menulis ulang setengah basis kode ke teknologi lain, karena yang ini belum masuk.
- Lebih lanjut tentang "ujung kemajuan": Saya ingin berasumsi bahwa startup memungkinkan Anda untuk dengan tenang bernapas "Anda tidak harus berurusan dengan kode warisan." Benarkah begitu?- Nah, semua orang mengerti kata "warisan" dengan caranya sendiri. Jika kita maksud dengan itu, misalnya, kode yang lebih tua dari tiga tahun, maka di perusahaan di bawah tiga tahun, tentu saja tidak. Tetapi Anda dapat memperketat konsep ini, maka kami akan memiliki beberapa persentase kode lama. Dari sudut pandang bahwa itu ditulis bukan tiga tahun yang lalu, tetapi hanya beberapa bulan yang lalu, tetapi kemudian kita tidak tahu bagaimana melakukan sesuatu dengan benar, tetapi sekarang kita telah belajar, kita dapat melakukan seratus baris alih-alih seribu, dan mereka akan melakukan hal yang sama bahkan lebih dapat diandalkan. Kode seperti itu, tentu saja, tidak bisa dihindari. Tapi tidak ada yang harus kita cari beberapa "pengembang berjanggut", karena hanya mereka yang tahu bahasa pemrograman ini, dan kita tidak bisa menolaknya.
- Seberapa besar kontribusi pengembangan startup terhadap “pembangunan sepeda”? Sementara perusahaan raksasa melakukan semuanya di dalam, bukankah Anda sanggup melakukannya? Atau apakah startup hanyalah tempat di mana setiap orang melakukan hal mereka sendiri?- Bagi kami, nilai bisnis adalah yang utama. Kita sudah menguntungkan, tetapi jika kita melambat dan mulai kehilangan seseorang, itu akan sangat menyakitkan. Karena itu, jika pengembangan pihak ketiga konsisten dengan persyaratan bisnis, menyelesaikan masalah bisnis, dan tidak memiliki masalah besar, maka kita dapat dengan aman mengambil dan menggunakannya. - - , , . — - .
— , ? , - «»?— , — . , , , , - , - . : , .
. ManyChat React, Baobab. , React . view React, store Baobab. , , .
2017 . React, Redux middleware – Thunk Fetch API. , . , , , , .
— , , , . -, «» ?— c , Flow, — Flow Builder. , :
, , 2D-. Flow Builder PixiJS — WebGL/Canvas.
. , . PixiJS requestAnimationFrame . , , , , . ( 12- MacBook, , ). , , , .
, , -, - , - , , , . 2D-.
— «»? , , ?— , , , , , … , HTML, Canvas WebGL , . Pixi, .
: , Canvas, - WebGL. Pixi , , . , - . , issue,
GitHub , , , .
, , , Canvas , HTML CSS. , Flexbox layout', . . Canvas, : Canvas, textarea, CSS scale , : Canvas - , HTML.
, . , Pixi - , , Flow Chart . - - , : , . , , , , . .
— . , , , . - , - ?— , , . , - , . , - , .
: - -, - - , , , . , , . , , - -. , , , , . -, , , , .
