Arsitektur tanpa server secara mendasar memengaruhi faktor pembatas yang menghambat pengembangan produk.Manajer produk dalam organisasi bertindak dalam berbagai peran. Kadang-kadang mereka disebut "suara pelanggan", kadang-kadang mereka memainkan peran
"bahaya kucing perusahaan" . Mereka adalah saudara-saudara yang berkulit tebal, orang-orang yang mau tidak mau menuntun Anda untuk mengirimkan produk, terlepas dari etika atau alasan apa pun. Seorang manajer produk yang baik jarang menjadi idola orang lain, tetapi berkat karya orang-orang seperti itu, sebagian besar solusi teknologi yang pernah Anda gunakan diwujudkan.
PM selalu mencari alat berkualitas tinggi untuk menyelesaikan masalah. Kita tahu bahwa pesaing terus-menerus menginjak tumit mereka, pelanggan sudah bosan menunggu, jadi kita harus terus bertindak lebih pintar, lebih cepat dan lebih efisien. Dengan munculnya teknologi tanpa server, tidak segera jelas bagaimana mereka akan masuk ke daftar keinginan manajemen produk. Namun, setelah bekerja dengan teknologi ini selama setahun, saya melihat bahwa mereka memecahkan beberapa masalah pengembangan perangkat lunak yang bagi kami terasa selamanya.
Paradox: ukuran dan kinerja tim
Aturan pertama manajemen produk mengatakan: jumlah pekerjaan yang dilakukan terus meningkat. Backlog terus membengkak, dan runtuh ke nol hanya dalam satu kasus: ketika produk dihilangkan. Hal yang paling sulit adalah mengubah elemen terpenting dari jaminan simpanan Anda menjadi produk yang siap dikirim. Semua hal lain dianggap sama, diyakini bahwa hubungan berikut harus diperhatikan:
Jika satu penggali dapat mendaur ulang 1 ton tanah per hari - diasumsikan bahwa 10 penggali dapat mendaur ulang 10 ton. Sebagai aturan, manajemen sumber daya di perusahaan dibangun berdasarkan prinsip ini: jika Anda ingin meningkatkan penjualan - merekrut lebih banyak orang penjualan. Ketika mengembangkan perangkat lunak, ketika tumpukan simpanan tumbuh, godaan adalah hanya meningkatkan tim. Namun, dalam kasus dengan produk dan layanan yang kompleks, kira-kira jadwal berikut ini biasanya muncul seiring waktu:
Jarang melihat bagaimana tim besar bekerja dengan kecepatan Stakhanov; tetapi sering terjadi bahwa sebuah tim kecil dengan keteguhan yang patut ditiru berkembang dengan pesat.
Banyak startup yang memiliki kesalahan seperti ini: begitu produknya menjadi sukses, lebih banyak pengembang dan manajer baru ditambahkan ke staf. Segera tiba-tiba ternyata kecepatan mulai turun. Ada apa? Bahwa pengembang pertama lebih berbakat, birokrasi tumbuh di perusahaan, dan bagaimana arsitektur direncanakan?
Saya pikir semua ini hanya gejala, bukan akar masalahnya. Masalahnya sendiri berujung pada interaksi tiga faktor kritis, hanya dua di antaranya yang dapat langsung dikendalikan:
- Kerapuhan adalah efek dari perubahan baru. Jika fitur baru hanya memengaruhi sebagian mesin, maka mudah untuk menguji dan menerapkannya. Jika itu mempengaruhi semua elemen mesin, maka pengujian menjadi lebih sulit dan pada saat yang sama lebih penting, dan implementasi membutuhkan urutan besarnya lebih banyak waktu.
- Volume pekerjaan adalah bagian terkecil dari pekerjaan yang dapat dilakukan oleh tim dan memberikan fitur yang produktif pada output. Misalnya, hasilnya adalah "Bayar dengan Alexa" daripada "berkumpul dan diskusikan bagaimana melakukan pembayaran dengan Alexa".
- Kompleksitas - seberapa banyak pengetahuan yang diperlukan untuk mengimplementasikan fitur. Apakah pengembang yang tahu cara menulis fitur yang mampu melakukan hal yang sama dalam organisasi? Perubahan tambahan apa yang harus terjadi agar kemajuan melambat secara bertahap, dan produk berhenti tumbuh dengan fitur-fitur yang berharga dari sudut pandang klien?
Saya terutama tertarik pada mengapa, pada awal keberadaan, semua faktor ini seimbang secara optimal: tidak ada yang rapuh, jumlah pekerjaan tidak terlalu besar (dan Anda biasanya bisa setuju dengan pelanggan), dan kompleksitasnya praktis tidak ada. Jadi, jika tim perlu membuat situs yang sesuai dengan GDPR, maka mereka akan punya waktu untuk meneliti masalah ini, keputusan akan dibuat dengan cepat, dan tim akan yakin bahwa situs tersebut bekerja persis seperti yang direncanakan.
Di perusahaan yang lebih besar, faktor-faktor ini digabungkan, menghasilkan ukuran tim yang tumbuh, dan volume pekerjaan yang dilakukan berkurang. Untuk membuat situs web yang kompatibel dengan GDPR di perusahaan seperti itu, Anda memerlukan tanda tangan pengacara, persetujuan pemasar, persetujuan proyek di tingkat dewan direksi, pengujian A / B dari implementasi yang paling tidak mengganggu, koordinasi gangguan pengembangan dengan tim admin, koordinasi dengan rencana penempatan yang diadopsi oleh tim lain - daftar berjalan. Bahkan dengan jumlah kontrol dan jumlah proses ini, tim jauh lebih tidak yakin bahwa itu akan berhasil, karena kerapuhan seluruh sistem dan banyak yang tidak diketahui dalam ekosistem.
Memperluas contoh ini ke ukuran proyek nyata, di mana mungkin ada puluhan fitur dan ratusan perubahan, mudah untuk memahami bagaimana, karena pengaruh faktor-faktor ini, grafik rasio "ukuran tim / volume kerja" berubah dari yang pertama ke yang kedua. Seiring pertumbuhan tim, Anda akan ditakdirkan untuk melakukan lebih sedikit pekerjaan per unit waktu, tidak peduli bagaimana Anda mencoba mengecoh raksasa organisasi. Atau sepertinya begitu - tetapi kemudian, apa yang harus dilakukan?
Cara meretas ketiga faktor tersebut
Masalah ini telah menghantui saya selama bertahun-tahun, yang mendorong saya untuk mempelajari penyebabnya. Apakah mungkin bagi startup untuk membuat kemajuan pesat? Untuk sementara, saya hanya berpikir begitu, dihadapkan dengan kesulitan manajemen produk di organisasi besar. Namun, kemudian saya melihat ketiga faktor lebih dekat.
Kerapuhan selalu merugikan Anda - hal itu memicu utang teknis yang terus tumbuh dalam proyek apa pun dengan ukuran berapa pun. Situasi ini mengingatkan pada “paruh pada yang sebaliknya”: setiap elemen program tumbuh seiring waktu dan karena ini (selama pengembangan) ia menjadi lebih rapuh, dan semua ini diperparah dengan setiap baris kode baru.
Jumlah pekerjaan tidak terkait dengan fitur spesifik dari produk ("Bayar dengan Alexa"), tetapi lebih kepada perbedaan dalam garis besar infrastruktur jika kita membandingkan negara bagian "sebelum" dan "setelah". Semakin sulit "setelah" menjadi, semakin banyak jumlah pekerjaan yang dilakukan berkurang. Itulah sebabnya di banyak perusahaan, ketika merencanakan pekerjaan, penekanannya bergeser dari kebutuhan klien ("Bayar dengan Alexa") ke kebutuhan organisasi ("Temui dan bahas siapa yang harus terlibat dalam implementasi fitur" Bayar dengan Alexa ").
Kompleksitas adalah kombinasi faktor sosial, organisasi, dan teknis yang secara langsung memengaruhi durasi pencarian pengembang yang cocok, kemampuan memperlakukan pemrogram sebagai orang yang memiliki banyak tugas yang dapat dipercayakan dengan pekerjaan apa pun. Selain itu, ini adalah kompleksitas - aspek yang sangat mungkin tetap tidak terlihat, tidak berdokumen dan disalahpahami. Pengembang dapat menulis aplikasi Bereaksi di rumah dan merilisnya sendiri, tetapi di organisasi ia harus mengambil selusin langkah tambahan yang akan memakan waktu, dan fitur yang menarik bagi pengguna tidak akan berubah sama sekali. Programmer akan menghabiskan sebagian besar hari mereka.
Bersama-sama, ketiga faktor ini membentuk lingkaran setan, sehingga jumlah pekerjaan yang dilakukan berkurang, kerapuhan meningkat, pengembang berhasil menyelesaikan lebih sedikit fitur, dan produk Anda ditumbuhi kompleksitas sebagai lumpur yang tak terlihat. Akibatnya, pertumbuhan tim tidak membantu, dan kecepatan hanya dapat ditingkatkan secara sadar dengan kelicikan dengan angka dan indikator. Gejala klasik: posisi "rapat diadakan" muncul dalam laporan sprint.
Di perusahaan besar, saya harus mengamati beberapa pendekatan cacat yang dirancang untuk memutus siklus ini. Yang pertama adalah "Agile Skala Besar", menghasilkan pertemuan besar di mana mutlak semua peserta dalam pengembangan fitur tertentu berpartisipasi dan upaya dilakukan untuk mengoordinasikan pekerjaan. Jadi cobalah mengoordinasikan pekerjaan dan memahami kerumitannya. Pendekatan seperti itu baik untuk perusahaan distribusi makanan yang memberikan makan siang yang mempesona, tetapi dalam kasus kami tidak berhasil. Faktanya adalah bahwa ketika ukuran kelompok proyek prioritas meningkat, itu menjadi lebih dan lebih banyak, dan mereka sendiri berkurang. Oleh karena itu, tidak mungkin untuk secara fundamental menyelesaikan masalah kerapuhan dan kompleksitas. Seiring waktu, Agile skala besar memberikan daftar tugas taktis yang menyerupai daftar belanja, dan semakin kurang seperti jalur holistik dari satu fitur yang bijaksana ke yang lainnya.
Kedua, "kelompok inovasi" intra-perusahaan sering mencoba untuk mendorong perubahan periferal, dengan harapan bahwa pekerjaan ini akan berakar pada mesin yang rapuh, dan seluruh struktur akan berubah menjadi lebih baik. Pendekatan ini memberikan efek samping yang aneh: keyakinan dikonsolidasikan bahwa hanya "kelompok inovator" tersebut yang memiliki hak untuk melakukan perubahan pada proses. Oleh karena itu, metode serupa juga tidak menyelesaikan masalah dengan kompleksitas organisasi.
Setelah melihat bertahun-tahun dari berbagai kegagalan, saya sampai pada kesimpulan bahwa perlu untuk meretas ketiga faktor untuk mencegah efek gabungan mereka pada pekerjaan yang dilakukan dan untuk mengatasi inersia:
- Kerapuhan tidak boleh meningkat di versi mendatang atau seiring bertambahnya usia produk.
- Karya harus tidak kurang dari apa yang diperlukan untuk membuat fitur yang signifikan dari sudut pandang pengguna.
- Kompleksitas seharusnya tidak memengaruhi pekerjaan pengembang tunggal.
Jika Anda berhasil mengadopsi ide-ide ini, maka Anda akan dilindungi dari rock, yang mengejar semua produk perangkat lunak dalam sejarah umat manusia. Kedengarannya hebat, tetapi bagaimana ini bisa dicapai?
Jika Anda berhasil mengadopsi ide-ide ini, maka Anda akan dilindungi dari rock, yang mengejar semua produk perangkat lunak dalam sejarah umat manusia. Kedengarannya hebat, tetapi bagaimana ini bisa dicapai?
Teknologi Serverless Mematahkan Batasan
Berkat kemunculan teknologi cloud, dimungkinkan untuk membuka jalan penting ke kondisi "diretas" yang baru. Secara umum, dengan munculnya cloud, proses pengiriman produk perangkat lunak menjadi lebih ringkas, karena penyedia mulai melakukan banyak hal rutin untuk Anda. Sebelum awan muncul, jika Anda perlu menerapkan fitur pengguna baru, Anda harus memesan server, memasang peralatan di rak, menyetujui meletakkan jaringan di pusat data, dan kemudian memelihara peralatan ini, yang usang seiring waktu. Di cloud, semua ini bisa disewa, sehingga menyingkirkan puluhan item organisasi dan menghemat seluruh bulan.
Selain itu, dengan menghilangkan kebutuhan untuk meningkatkan peralatan di pusat data dan menyediakan akses ke perangkat keras sesuai permintaan, kami mengurangi kerapuhan dan kompleksitas. Menempatkan program untuk digunakan jauh lebih mudah daripada di masa lalu. Namun, seiring waktu, beban mengelola infrastruktur virtual yang luas telah meningkat secara signifikan, dan banyak metode pengiriman yang ketinggalan zaman tetap tidak berubah. Dengan menggunakan awan, tim dapat ditingkatkan secara signifikan sebelum pekerjaan mulai melambat - namun, ia mulai melambat, dengan satu atau lain cara.
Teknologi tanpa server secara radikal mengubah dinamika ini. Aplikasi tanpa server terdiri dari potongan-potongan kecil kode yang ditulis oleh tim Anda (yang disebut "lem") dan "kotak hitam" fungsional yang dikelola oleh penyedia cloud. Kotak hitam hanya menerima konfigurasi dan bereaksi terhadap perubahan. Dalam aplikasi dengan arsitektur berkualitas tinggi, bagian standar dari pekerjaan operasional yang terkait dengan pengoperasian aplikasi berada pada kotak hitam standar. Aplikasi itu sendiri bukan lagi fungsi monolitik, tetapi struktur fungsi federal dan kotak hitam.
Dalam praktiknya, ini secara dramatis mempengaruhi tiga faktor yang saya sebutkan di atas:
- Kerapuhan berkurang karena nol biaya manajemen infrastruktur dan ikatan yang lemah. Dalam proyek kami sendiri, diamati bahwa basis kode sebagai akibat dari perubahan tersebut kadang-kadang dapat dikurangi sepuluh kali lipat.
- Ukuran "karya" biasanya sebanding dengan biaya pembuatan fitur baru, karena menjadi sepele untuk membuat versi fungsi baru atau fungsi yang sama sekali baru yang sebelumnya tidak diperlukan.
- Kompleksitas tidak memengaruhi pengembang - jika ia dapat menulis fungsi yang memproses pembayaran kartu kredit, maka praktis tidak ada yang bisa dilakukan selain kode ini dalam aplikasi tanpa server, tidak ada pembungkus organisasi dan tidak ada pertimbangan ekosistem, karena pekerjaan yang dapat melambat.
Saat mengelola aplikasi tanpa server yang sangat besar sekalipun, mudah bagi manajer produk untuk melihat lebih dekat pada beberapa elemen yang dipengaruhi oleh perubahan yang dilakukan. Selain itu, mudah untuk meluncurkan dua versi secara kompetitif dengan menempatkan bendera fitur. Selain itu, biasanya bahkan tidak perlu untuk menghancurkan kode versi lama.
Dalam aplikasi tanpa server, infrastruktur selalu dibangun di pinggiran, dan Anda hanya menulis kode minimum yang diperlukan yang menggabungkan layanan yang dikelola sepenuhnya. Anda tidak perlu memikirkannya dari sudut pandang operasional. Kami tidak mencoba mengendalikan monolit, membersihkan kode lama, atau melihat keseluruhan sistem dari pandangan mata burung.
Mengapa ini sangat penting
Seiring laju perubahan meningkat, menjadi semakin sulit untuk memprediksi bagaimana program Anda akan terlihat di masa depan atau apa yang diinginkan pengguna dari Anda. Oleh karena itu, upaya untuk menulis kode "selama berabad-abad", sehingga harus bekerja di masa depan, meskipun ada perubahan, menjadi semakin sia-sia. Kami telah melihat betapa buruknya penggunaan kembali kode di sebagian besar perusahaan, dan bagaimana kepatuhan terhadap platform usang memperlambat kemajuan.
Sekarang semuanya diatur sehingga sistem lama dikembangkan dan dipelihara selama mungkin, sampai dukungannya mulai mengambil dari programmer hampir sepanjang waktu. Setelah itu, perusahaan memulai dari awal lagi dengan sistem baru, dengan sungguh-sungguh berjanji untuk tidak mengulangi kesalahan yang dibuat dalam yang lama. Ketika tiga faktor cepat atau lambat mencekik sistem baru, ada "kebakaran hutan" teknologi, setelah itu Anda harus mulai dari awal lagi.
Kita dihadapkan pada perjuangan melawan gejala kompleksitas, itulah sebabnya begitu banyak paradigma datang dan pergi, tanpa meninggalkan jejak yang berarti dalam sejarah manajemen produk. Pengembangan tanpa server, pada gilirannya, memungkinkan tim untuk meminimalkan peningkatan kompleksitas dan terus memberikan produk yang berharga pada kecepatan yang adil, tanpa jatuh ke dalam perangkap klasik yang selama beberapa dekade tetap menjadi momok dari setiap pengembangan perangkat lunak.
Paradigma tanpa server baru saja mulai berkembang, tetapi tampaknya sudah sangat menjanjikan. Pada saat klien mengharuskan Anda untuk memiliki fitur baru yang belum pernah ada sebelumnya, manajer produk akhirnya dapat memperoleh platform yang memungkinkan Anda untuk berpikir secara tepat berdasarkan persiapan fitur baru. Proses ini tidak terhalang oleh meningkatnya kompleksitas organisasi, dan juga tidak berhenti karena kerapuhan yang berlebihan.