👊🏻 👉🏿 💆 Mulai di dalam korporasi 👺 🏈 🧒🏻

Hai, nama saya Andrey Vanin dan saya sedang mengembangkan dan meluncurkan produk broker dan fintech. Hari ini tepat satu tahun sejak saya bekerja di BCS, di mana dalam tim yang terdiri dari delapan orang kami sedang mengembangkan proyek fintarget.ru.

Di bawah ini adalah (bukan) cerita besar tentang bagaimana mengimplementasikan sebuah startup di sebuah perusahaan besar, merilisnya ke pasar dan pada saat yang sama tidak hangus di antara banyak memo dan persetujuan.

gambar

Intro

Lupakan semua manifestasi Agile dan ciptakan lingkungan kerja yang nyaman jika Anda ingin mencapai hasil. Dalam pengelolaan proyek-proyek yang tidak ada harapan, bukanlah kehadiran kantor PlayStation dan ritual scrum wajib yang datang ke depan, tetapi ambisi tim dan motivasi pribadi.

Jika pengembang Anda ingin menjadi yang terbaik, ia tidak akan bermain hoki udara dan ia tidak peduli jika ada kamar kecil di kantor (ada spoiler). Jika proyek Anda ingin mencapai rasa hormat, ia akan belajar berjalan di atas kepalanya dan menyelesaikan masalah apa pun, apakah itu pekerjaan lain yang tidak dapat dipahami untuk mengganti kursi yang rusak atau kebutuhan untuk mengoordinasikan proses yang tidak ada di sana.

Jika penyedia front-end memiliki hipotek yang beredar - tawarkan padanya pilihan - baik PS4, atau plus bonus dalam jumlah jumlah yang sama. Tugas Anda bukanlah menjadi pengasuh dalam proyek, tetapi untuk memastikan hasilnya sedemikian rupa sehingga tim dan pelanggan puas. Bahkan jika itu tidak mungkin.

Pada tanda Anda

Saya bergabung dengan perusahaan pada awal April 2019. Dua pengembang duduk di kantor, seorang pelanggan dan setengah manajer proyek yang belum pernah terlibat dalam proyek pengembangan. Kami harus cepat mengembangkan sistem dari awal, yang mereka coba lakukan tiga atau empat kali sebelumnya, tetapi dalam lima tahun tidak ada yang bisa membawa produk yang waras dan ramah pengguna ke pasar.

Di meja saya ada cetakan presentasi lima slide - bagaimana semuanya akan baik-baik saja, bagaimana kelihatannya, arsitektur teoretis, berapa banyak uang yang harus dibawa dan berapa banyak uang yang diperlukan. Dan tidak sepatah kata pun tentang produk, tidak satu pun menyebutkan unit terkait, bukan proses tunggal dan memahami bagaimana semua ini harus lepas landas.

Tetapi tenggat waktu diumumkan - untuk rilis pada bulan September. Dan kami duduk untuk bekerja.

Poros ganda

Versi pertama dari produk menyiratkan penciptaan infrastruktur internal tanpa solusi front-end sendiri. Diasumsikan bahwa produk akan disajikan di rak aplikasi seluler, dan dua pengembang saya hanya akan mendukung backend dan logistik arus informasi. Pendekatan ini menjamin kegagalan proyek sudah pada bulan Juni, karena dalam arah bisnis paralel, tim aplikasi mulai mengalami perubahan signifikan dan jaminan simpanan hingga akhir tahun sangat berkabut. Dan kami memutuskan untuk membuat produk MVP di bagian depan web perusahaan saat ini. Ini giliran pertama.

Solusi paling sederhana dalam situasi ini adalah melakukan outsourcing desainer UX dan desainer tata letak, menggambar tata letak pensil, mendapatkan desain dan memberikannya kepada pengembangan. Tetapi hanya startup independen yang bisa. Kami adalah perusahaan baru di sebuah perusahaan besar, di mana desainer tidak dapat membayar tunai, dan semua pekerjaan depan harus dilakukan melalui koordinasi dengan pemasaran dan pengacara. Itu lebih sulit, tetapi tidak menghentikan pengembangan kernel, jadi kami pergi ke pemasaran.

gambar

Hampir segera, masalah stratifikasi dari gambaran keseluruhan muncul - pemasaran tidak tahu apa yang kami lakukan secara teknis, dan pengembang tidak mengerti bagaimana seharusnya semua itu terlihat. Sebelum liburan Mei, pertama-tama kami membuka pertemuan dan duduk untuk menggambarkan layar.

Hingga pertengahan Mei, pemahaman terperinci tentang bagaimana produk seharusnya bekerja hanya ada di kepala saya dan sekitar lima puluh halaman yang menggambarkan algoritme dan layar. Itu adalah risiko besar (triknya dilakukan oleh para profesional! Jangan ulangi - itu berbahaya!), Tetapi pada saat yang sama setiap anggota tim tahu apa yang harus dilakukan dan sarat dengan pekerjaan dua bulan sebelumnya.

Proyek merokok, mengoordinasikan versi arsitektur berikutnya dan interaksi sistem, pimpinan tim masuk dan mulai mengambil kode, dan pengembang ketiga (dipekerjakan dengan saya pada hari yang sama) hampir sebulan memahami mekanisme integrasi. Dan itu adalah bagian tersulit. Perusahaan ini memiliki dua lusin sistem, dengan enam yang perlu kami integrasikan.
Pada titik tertentu, menjadi jelas bahwa pemimpin tim yang ditunjuk tidak sesuai dengan kecepatan tim dan harus diganti. Pengembang kedua mengambil tempat, dan untuk lowongan kosong kami mengambil seorang programmer dengan latar belakang calon ilmu fisika. Ke depan, saya akan mengatakan bahwa itu menyelamatkan kita.

Namun, segera menjadi jelas bahwa kami juga tidak akan dapat masuk ke dalam rangkaian web internal, dan pelanggan menyetujui satu-satunya solusi penghematan pada saat itu - kami membuat bagian depan produk berbasis web kami sendiri dengan tim branding dan dukungan kami. Di dalam departemen, kami buru-buru mengumumkan kompetisi untuk nama produk dan akhirnya memilih opsi yang disuarakan oleh yang pertama, karena ada satu domain bagus di celengan pribadi saya, dan tidak ada yang lebih baik bagi semua orang untuk memilih dan kreatif. Jadi merek fintarget.ru muncul. Dan itu adalah giliran kunci kedua.

Tentang tim

Jutaan buku tentang manajemen pengembangan memberi Anda templat kerja tim standar dan proses standar, lupa bahwa setiap tim unik dan memerlukan pendekatan individual.

Banyak faktor yang dapat memengaruhi pekerjaan dan komunikasi dalam tim: usia, status perkawinan, dan bahkan preferensi dalam musik. Namun demikian, hampir tidak pernah produk memperhatikan hal ini, dan, sebagai aturan, fokus pada faktor samping - lokasi dan ukuran meja, tirai di jendela, headphone dengan ventilasi dan hal-hal kecil lainnya yang "tidak mengganggu."

Bintang-bintang bersatu dan kami berhasil menemukan rantai hubungan di mana masing-masing dan setiap orang selalu memiliki sesuatu untuk dibicarakan selain pekerjaan. Dan ketika Anda telah membangun komunikasi - Anda dapat dengan tenang menangani pembagian peran.

Pada tahap proses tim debug, kami telah membentuk skema hibrid sedemikian rupa sehingga tidak cocok dengan salah satu templat yang ada.

Pertama , kami meninggalkan analis. Benar. Peran analis didistribusikan antara pemimpin tim dan pemilik produk, dan detail proses dimodernisasi dan diperbaiki selama pengujian layanan. Ini adalah peningkatan berkelanjutan dari produk yang suka dibicarakan oleh para pendukung Edge.

Kedua, kami telah menghapus garis antara kekuatan manajer produk pada pribadi pelanggan dan pemilik produk. Dua karyawan melakukan dua peran online, tanpa membatasi wewenang dan tidak takut tanggung jawab dalam pengambilan keputusan. Sangat menarik untuk menonton pengembang yang melihat bagaimana pemilik dan manajer dengan kasar berdebat tentang CJM atau tata letak halaman. Omong-omong, ini sangat mempengaruhi keterlibatan tim.

Ketiga , pada tahap pengembangan kernel, kami benar-benar meninggalkan sprint dengan backlog yang keras dan menggunakan pendekatan berulang berdasarkan perbaikan dan penambahan fungsionalitas selama pengembangan. Ingat bagaimana gambar jpeg dimuat di browser pada awal abad ini? Itu tentang cara yang sama kami mengembangkan inti produk.

Keempat, kami (dengan terpaksa) membatasi dengan ketat fungsionalitas pengembang. Pengembang layanan-mikro yang terpisah dialokasikan untuk setiap sektor, yang hanya bertanggung jawab untuk segmennya. Kami memiliki lima segmen dalam proyek: integrasi dengan sistem internal, integrasi dengan sistem pertukaran, algoritma produk kernel, OpenAPI, dan bagian depan.

Dan kelima , semua sumber daya dari manajer proyek departemen kami yang kami miliki bertujuan semata-mata untuk mengelola tim eksternal yang bertanggung jawab untuk menyelesaikan sistem yang kami butuhkan untuk diintegrasikan, dan untuk menerapkan semua prosedur untuk mengoordinasikan dan mengintegrasikan startup ke dalam infrastruktur perusahaan.

Selama tiga bulan, pahlawan proyek ini menghabiskan lebih dari satu setengah ratus layanan yang berbeda, mendeskripsikan dan mendokumentasikan selusin proses baru, dan dialah yang dalam praktiknya membantah teori populer tentang ketidakmungkinan membuat startup di perusahaan besar.

Pendekatan ini memungkinkan kami untuk merencanakan kumpulan tugas, memperbaiki semua persyaratan untuk MVP, dan secara keseluruhan, ketika menjadi jelas bahwa mekanismenya bekerja, saya, sebagai tukang ojek, pergi berlibur dengan tenang. Saat itu bulan Juli, dan seperti yang tertulis dalam satu novel manajemen proyek terkenal, ketika semua proses didefinisikan, tugas dan tenggat waktu diketahui, Anda hanya perlu menonton.

Pada tanggal 1 Agustus kami memiliki kernel dari sistem berkumpul, hampir semua pekerjaan persiapan dilakukan, versi beta OpenAPI dirakit, bagian depan dibuat dan dibuat dan masih ada satu minggu tersisa untuk memoles algoritma dan menunggu front-end untuk bekerja, yang “hanya untuk” mengumpulkan semuanya Ini adalah MVP yang berfungsi.

Pohon acara

Dimungkinkan untuk mengumpulkan infrastruktur proyek startup dalam loop tes tertutup sebanyak yang Anda suka, tetapi proyek tidak akan pernah lepas landas tanpa integrasi dengan sistem utama perusahaan. Ini adalah masalah utama pekerjaan startup di perusahaan: lebih dari 80% proyek mati tanpa menemukan peluang untuk berintegrasi dan mematuhi semua persyaratan dan peraturan perusahaan.

Ada beberapa sistem seperti itu dalam bisnis broker: sistem perdagangan dan akuntansi, bus integrasi, CRM, katalog layanan, dan selusin sistem dan mekanisme lainnya yang sangat ketat diatur dan dipantau oleh layanan keamanan informasi.
Integrasi tanpa berlebihan adalah ujian paling serius untuk proyek dan tim, dan kami harus membunuh total sekitar tiga bulan kerja orang di dalamnya.

Peran kunci dalam proses ini dimainkan oleh aturan "pertama melanggar semua aturan". Kami memprakarsai beberapa skenario integrasi paralel sekaligus - dari yang paling resmi (melalui Paspor Proyek, mengoordinasikan arsitektur, membuat sirkuit uji dan mentransfer semua instruksi untuk kebijakan rilis dan dukungan) ke yang paling tidak resmi - kami mengembangkan di sirkuit pertempuran, ditutup dari luar dan menguji sistem sendiri. akun pialang.

Detail cerita ini layak mendapat artikel terpisah, tetapi kunci yang telah dicapai terdiri dari beberapa poin:

. « – – crm– – – – », , ,
- « - », « » .
Pendekatan pengujian "preprod" telah sangat meningkatkan keterlibatan pengembang, memungkinkan untuk menguji UX dalam praktek sebelum merilis produk ke dunia luar dan, yang paling penting untuk proyek, untuk men-debug operasi yang benar dari algoritma sistem pada pasar nyata dan data klien.

Dan yang paling penting - jangan pernah menganggap waktu terbuang pada proses paralel selama integrasi. Seperti dalam anggaran iklan, Anda masih tidak pernah tahu setengah dari anggaran yang Anda habiskan dengan sia-sia. Hanya membangun pohon opsi dan memulai proses: beberapa cabang akan menghilang dengan sendirinya tanpa harapan, beberapa akan bergabung menjadi satu, dan ketika salah satu dari mereka membawa Anda ke hasilnya, itu hanya akan menjadi Champion Path Anda. Karena di proyek lain, skenario yang sama mungkin tidak berfungsi.

gambar

Apa hasilnya

MVP kerja proyek ini dikumpulkan pada akhir Agustus, secara paralel, versi emulator untuk mengakreditasi program di NAUFOR dilaksanakan dan seratus lima puluh halaman dokumentasi pendukung untuk mendaftarkan perangkat lunak ditulis. Transaksi nyata pertama pada sistem dengan teriakan gembira tim terjadi pada 31 Agustus. Perubahan hukum pada dokumen perusahaan dan peraturan klien mulai berlaku pada 1 September, dan sebelum sistem terakreditasi, kami punya waktu untuk melakukan debug dan menjilat antarmuka.

Di MVP, kami tidak memiliki akun mata uang, atau futures, atau bahkan akun broker kami sendiri, tetapi tugas utama selesai - infrastruktur diimplementasikan, preprod menjadi prod, layanan pelanggan diimplementasikan.

Pada 17 September, perangkat lunak Fintarget ditambahkan ke dalam daftar program ikuti otomatis terakreditasi, dan hari berikutnya kami melihat pelanggan pertama yang terhubung ke sistem. Masih ada banyak pekerjaan untuk memperluas fungsionalitas dan membawa MVP ke keadaan produk yang lengkap dan mandiri, tetapi ini adalah cerita yang sama sekali berbeda dan kurang menarik: rilis, sprint, backlog, dan analisis klien yang tak ada habisnya.