Hai Nama saya Alexey Pyankov, saya adalah kepala programmer di Sportmaster. Saya akan segera mengatakan bahwa "utama" tidak berarti "yang paling penting dari semua programmer", tidak, itu hanya sebuah nama, terjemahan yang sangat menarik untuk "Senior +" ".
Saya telah bekerja di Sportmaster sejak 2012, dan selama ini tim pengembangan telah membuat banyak keputusan yang menarik dari sudut pandang teknis. Tetapi hari ini saya ingin berbicara tentang pekerjaan kami dengan lebih menekankan pada bagaimana kami beralasan dalam situasi ambigu tertentu.
Artikel ini tidak akan memiliki solusi teknis khusus (dan memang sesuatu yang teknis) yang harus diambil dan diterapkan dalam proyek Anda. Sebaliknya, ini adalah refleksi dari pekerjaan yang dilakukan. Ada momen spesial yang memengaruhi kami sebagai tim - bangkit, marah, dan diuji kekuatannya. Saya akan mencoba untuk memberi tahu Anda tentang momen-momen ini, tentang suasana kerja tim, tentang rake kami dan sejumlah perangkap psikologis yang kadang-kadang mendorong kami.
Dan saya akan mulai pada 2012.
Saya datang pada tahun 2012 dengan tujuan utama pada saat itu - bekerja di situs web utama kami. Pada waktu itu itu adalah "monster Frankenstein": bagian dari tim bekerja dengan sistem lama kami, yang tidak menangani dengan baik muatan (Bitrix), di bagian lain dari tim (di mana saya termasuk) mereka mencoba memperkenalkan sistem baru, yang dipilih sesuai dengan kriteria "Sekali ini adalah e-commerce termahal di dunia, kami ambil. " Merekalah yang "mencoba menerapkan" - karena sistem itu mati-matian menolak, dan untuk setiap saat ternyata itu diselesaikan, ada "kejutan" sebagai respons. Mereka banyak bekerja, tetapi maju dengan kecepatan siput.
Bagi saya pribadi, sedotan terakhir berkenalan dengan kode satu metode dalam "e-commerce termahal di dunia" ini, ketika beberapa jam pekerjaan terkonsentrasi pada bug yang rumit mengarah pada fakta bahwa alasannya ditemukan di suatu tempat di label kustom, yang berfungsi saat generasi html di jsp. Tugas tag-kustom ini adalah untuk menampilkan jumlah dari beberapa nilai. Ini tidak buruk, tag khusus dimaksudkan untuk ini. Tapi kejutannya menyembunyikan fakta bahwa beberapa data dalam database berubah, perilaku pada halaman-halaman berikut terkait dengannya, dan jika Anda menekan F5, panggilan itu diulang, ini melanggar konsistensi data. Selain itu, itu melanggar sedemikian rupa sehingga hanya muncul setelah beberapa langkah, pada halaman ke-3 dari urutan. Tidak, saya tidak keberatan bahwa "master ninja" itu ada di tim dan dengan kodenya mendukung perhatian rekan-rekan dalam kondisi yang baik. Tapi begitu saja, dalam sistem yang paling mahal!
Itu hari Jumat. Dan seorang kolega dan saya menghabiskan hari Sabtu dan Minggu di kantor untuk mencari tahu tugas apa yang diajukan perusahaan untuk sistem hari ini dan tugas apa yang bisa muncul dalam setahun. Dengan demikian, bagaimana kita menyelesaikannya, jika kita tidak didorong ke dalam kerangka menggunakan sistem yang paling mahal dan paling hemat biaya ini.
Tidak lebih cepat dikatakan daripada dilakukan. Kami membuat pilot di mana kami meletakkan dasar untuk pengembangan situs web Sportmaster baru. Banyak dari ide-ide ini telah berakar dan sekarang kelanjutannya secara aktif berputar di situs.
Fase dan kerangka waktu pilot
2 hari Kami membuat mikrotrototipe - selama akhir pekan kami menyalip basis kami di ElasticSearch, kami melakukan pencarian segi. Woah la! Dalam sistem yang dibeli yang sama, pengaturan seperti itu "memakan" 2 minggu. Dan di sini - hanya dalam beberapa jam! Ya, dan itu bekerja lebih cepat. Dan lebih cepat dengan perintah.
2 minggu. Kami menggergaji prototipe, menambahkan fungsionalitas untuk pengiriman pribadi yang memadai.
Misalnya, pengguna memiliki beberapa diskon dan promosi yang relevan khusus untuknya - kemudian dalam hasil pencarian pada produk Anda perlu menampilkan dengan tepat harga yang dapat diperoleh dengan menggunakan semua roti yang tersedia dengan cara yang paling menguntungkan.
Dengan saham, semuanya tidak begitu sederhana. Sebagai contoh, saya membeli ski, sekarang ada diskon 40% untuk sebuah topi, tetapi pada saat yang sama, diskon selamat datang 10% untuk seluruh pesanan dibatalkan. Ya, ya, ini adalah kasus nyata :) Dan untuk mengatur promosi seperti itu dalam sistem pembelian, 3 konsultasi dengan pemasok dibayarkan, sehingga kami mendapat banyak contoh tentang bagaimana membuat berbagai promosi lainnya. Sangat diplomatis dan, mengingat biaya konsultasi, sangat bagus secara ekonomi.
Menunjukkan demo rinci kepada bisnis. Mereka berjanji untuk segera mengumpulkan pilot dan segera mulai bekerja.
2 bulan. Proyek percontohan - kami membuatnya dalam bentuk situs langsung dengan pencarian direktori. Cari dengan aspek, hasil pencarian - dengan diskon pribadi, pilot terlihat hampir seperti situs Sportmaster, dan kami mengisi produk yang sama. Sayang!
Kami menambahkan "Eloquence: 100" kepala departemen kami, dan presentasi untuk bisnis berlangsung di Hore! Mereka memberi kami carte blanche untuk mengembangkan platform eCommerce sendiri.
Dan itu berarti, pertahankan, teman, tim, teman, anggaran. Keren!
2 tahun Penarikan situs web dalam produksi. Ya, waktu yang lama. Semua yang kami tahu saat itu, kami hanya mencoba pada skala prototipe. Dua orang dengan mudah membentuk tim yang kompak. Dan tugas-tugas yang kami "hentikan" - pada umumnya, ini adalah dopila kecil "Hello World" dalam teknologi baru. Kami dengan mudah membuat hipotesis baru, dengan cepat mengujinya, tidak punya waktu untuk terikat, dan karenanya, tanpa penyesalan, mereka "membunuh" mereka. Ketika kami menjadi 10 orang, kami inersia mengekstrapolasi kecepatan kerja kami kepada orang lain. Dan mereka menjanjikan tenggat waktu untuk tugas itu, yang setara dengan gagasan si cantik, dikalikan oleh antusiasme kita.
Situasi yang biasa? :)
Lalu, apakah Anda sudah tahu apa yang akan terjadi selanjutnya?
Perangkap No. 1. "Ekstrapolator tangguh"
Jelas bahwa teknologi baru terlihat sangat keren dalam presentasi dan menunjukkan hasil yang sangat baik dalam aplikasi kategori "Hello World". Tetapi kenyataan biasanya sedikit lebih jauh dari ini.
Jadi disini. Kami mengambil perpustakaan, menulis banyak kode aplikasi. Kami menganggap unit test sebagai beban (kami keren dan kami membajak supersonik di sini, kode ini modern dan lebih banyak lagi). Kami terus mengubah dan memodifikasi API saat bepergian - yah, tes seperti apa yang ada, dengan serius. Dan semua ini di bawah panji “optimalisasi proses pengembangan” (ya, sekarang menakutkan untuk menggambarkannya).
Dan kemudian semuanya sangat jelas.
Kami meluncurkan bangunan baru di uat. Orang-orang dari bisnis dengan ceria pergi untuk menguji semua ini dan menekan tombol. Terkadang mereka menekan dengan cukup kreatif - sesuatu jatuh. Lalu pergi dan cari tahu apa yang mereka lakukan untuk ini. Tetapi di sisi lain dari monitor bukanlah penguji yang membosankan yang menggelar semua karakteristik lingkungan untuk Anda, dengan mempertimbangkan cuaca di wilayah tersebut, tetapi pelanggan keluar dari bisnis. Dia hanya "tidak bekerja." Jadi, dia tidak bahagia. Tanyakan padanya - dan dia akan sangat tidak bahagia!
Kemudian, untuk mereproduksi bug, Anda harus masuk dan melakukan semuanya. Tentu saja, kami tidak mengabaikan satu keluhan pun dan memperbaiki semuanya. Mereka melempar tugas yang direncanakan, tetapi "memadamkan api."
Jadi kami menggali lubang berikutnya.
Perangkap nomor 2. "Stakhanovets"
Anda tidak mendapatkan bug yang paling menyenangkan. Anda mulai mengerti. Itu tidak berhasil - kemarahan - upaya untuk mengatasinya lagi - gelandangan lain - Anda menentukan segala sesuatu yang mungkin - sekali lagi bukan karena Anda memikirkan fakta bahwa Anda sudah tua dan setiap orang punya anak dan hipotek - Anda coba lagi - tidak lagi. Beberapa cangkir kopi, dan semuanya berulang. 12-14 jam berturut-turut hampir menjadi norma. Dan sekarang, ketika semuanya sudah pada batasnya - bang, inspirasi!
Mungkin, dari luar, penilaian untuk efektivitas hari seperti itu terlihat dengan baik dan benar. Tetapi dari dalam - itu bisa berbeda.
Dalam kasus saya, kesan pekerjaan seperti itu adalah "Saya sudah selesai, saya keren, saya menarik keluar." Tidak selalu secara sadar, tetapi secara tidak sadar - selalu!
Dan duduklah di situ, jangan bercanda. Ternyata metrik internal keberhasilan gerakan digeser dari hasil ke jumlah upaya yang diterapkan dan tingkat prestasi apa yang Anda capai, seberapa banyak Anda menderita, berusaha menyelesaikan masalah.
Ini mungkin jebakan terburuk.
Selanjutnya akan lebih mudah dan lebih menyenangkan :)
Perangkap nomor 3. "Kekuatan Hello world"
Tumpukan teknologi kami pada periode itu: ElasticSearch, Hazelcast, Pentaho, freemarker (dan Java, Spring, Tomcat, nginx) yang terbukti. Freemarker tidak melaporkan pesan kesalahan dengan sangat informatif. Tapi ElasticSearch, Hazelcast, Pentaho harus ditambal beberapa kali - kami dengan berbakat menemukan kasus di mana mereka tidak bekerja seperti yang ditentukan oleh dokumentasi.
Awal yang mudah dan roti jahe cepat dari penggunaan teknologi baru itu bagus, tetapi mereka memperkenalkan ke dalam euforia dan mengurangi kewaspadaan. Karena teknologi baru ini mengandung bug, itu tentu mengandung bug. Dan jika Anda belum menulis tentang mereka - bersukacitalah, terserah Anda untuk menjadi perintis yang mengambil sesuatu yang bengkok dan tetap menggunakan google atau SO. Tentu saja, "bengkok" dapat ditemukan dalam produk yang terbukti, tetapi dalam yang baru itu jauh lebih mudah.
Terlepas dari semua kesulitan, kami mulai berproduksi. Ya, dengan keterlambatan. Ya, tidak terlalu stabil. Tetapi pada umumnya - tidak ada bencana.
Secara total, saya mencatat sekali lagi jebakan di mana persepsi yang sehat tentang proses kerja terdistorsi.
- "Extrapolator-tough" . Terkesan oleh keberhasilan saat ini, kami pergi dan dengan gembira memperkirakan kecepatan pengembangan untuk proyek yang akan datang.
- "Stakhanovets . " Kami bekerja untuk keausan, kami puas dengan diri kami sendiri, tetapi kami tidak memperhatikan bahwa masalah yang kami selesaikan adalah konsekuensi dari kesalahan / kekurangan / kelalaian pribadi kami. Pekerjaan tidak harus dilakukan.
- "Kekuatan Hello world . " Kami segera memperkenalkan semua yang terbaru dan paling menarik dalam produksi.
Mengapa itu berhasil?
Tentu saja, saya tidak mencantumkan semua kesalahan yang kami miliki selama ini, tetapi yang paling umum, kemungkinan untuk proyek spesifik. Memperbaiki kesalahan ini membantu menghindarinya di masa mendatang.
Sedikit tentang bagaimana kami secara umum berhasil menciptakan startup mini di dalam perusahaan dan meyakinkan bisnis untuk beralih dari sistem yang sudah dibeli ke sesuatu yang sejenisnya.
Ketentuan No. 0 . Iklim sehat di perusahaan. Ini bukan hanya "mata yang terbakar" dari karyawan dan kemampuan bersosialisasi dalam kondisi ekstraksi cookie, tidak. Ini tentang semua interaksi.
Ketentuan No. 1 . Percayalah pada apa yang Anda lakukan. Serius, saya tidak berpikir bahwa kita akan memiliki setidaknya beberapa kesempatan jika kita mengambil pilot tanpa harus memahami sistem yang dibeli "dengan baut" —yaitu, mundur dan tanpa sadar mengetahui bahwa sistem ini lebih dingin dan ditempati bersama kita.
Apa yang kami lakukan: 1) menemukan sistem pembelian, dengan bantuannya menyelesaikan permintaan dasar dari bisnis 2) membuat daftar tugas yang tidak hanya ada sekarang, tetapi akan berada di masa mendatang 3) kami memilih solusi yang lebih sesuai. Dan kemudian, penilaian kami terhadap keputusan - itu adalah penilaian para ahli.
Apakah mereka akan memberi kita sesuatu jika kita hanya datang dan berkata, "teman-teman, semua sampah ini, kita tidak ingin berurusan dengan ini dan memutuskan untuk melakukan hal kita dari awal"? Hampir tidak. Dan jawabannya akan diterima dalam bentuk yang diingat dengan baik :)
Ketentuan No. 2 . Langkah pertama kecil. Kami menghasilkan hipotesis pertama dan memverifikasi. Anda dapat menghabiskan waktu pribadi Anda untuk ini. Jika Anda tidak ingin membuang-buang waktu, maka Anda tidak boleh melakukan hal itu sama sekali. Dan jika Anda tidak ingin menguji hipotesis kecil, tetapi ingin segera melakukannya dengan dingin dan cemerlang, jauhi orang-orang seperti itu!
Kami beruntung, dan hipotesis pertama berhasil. Tetapi ini tidak selalu terjadi. Misalnya, dalam salah satu proyek berikut, ketika admin dipromosikan sebagai bagian dari pilot serupa, hanya opsi ke-18 yang bekerja untuk kami. Dan 17 pendekatan pertama untuk proyektil itu sia-sia. Ngomong-ngomong, dalam cerita dengan penciptaan wilayah admin, plot twists dan ternyata berada di tingkat seri Brasil, karena tim terdiri dari orang-orang, pada saat itu sudah veteran, "parut kalachs" nyata.
Ketentuan No. 3 . Kami melakukan MVP dan mencari rasa sakit di pengambil keputusan. Tentu saja, kengerian dapat tercermin di wajahnya sudah dari kenyataan bahwa Anda membawanya semacam usaha untuk ketiga puluh kalinya. Tapi tetap saja. Dan pastikan untuk menunjukkan bagaimana tepatnya kita menyelesaikan masalahnya dengan produk kita.
Ketentuan No. 4 . Berlutut kami dengan cepat membuat pilot yang terlihat seperti hasil akhir. Membuat semuanya benar-benar keren memang menggoda, tetapi Anda bisa mengalami perfeksionisme, karena itu ternyata bukan pilot yang Anda ingin tunjukkan versi pilot dari produk yang sudah ideal. Tetapi mereka tidak ada. Jadi, setidaknya buatlah tongkat.
Ketentuan No. 5 . Produk. Proyek ini berkembang, mendapatkan keuangan, para ahli datang dengan pengalaman yang solid.
Dan jika Anda adalah startup klasik, maka inilah saat ketika Anda perlu disalahkan dengan peluit. Karena penerbangan ringan di bagian paling atas dan perasaan kebaikan umum tentang apa yang terjadi dengan cepat tersebar.
Masuk ke produk adalah tabrakan dengan muatan nyata, integrasi dengan selusin sistem, dan ketika Anda membuat fungsionalitas baru, Anda akan menyelesaikan versi lama sebagai bagian dari pemeliharaan. Semua ini adalah tantangan yang jauh lebih serius daripada muncul dengan ide dan penyelesaian, meskipun, tetapi hanya satu masalah klien.
Ini adalah tantangan, dan pertumbuhan keterampilan - terjadi tepat pada tahap ini.
Terima kasih sudah membaca. Selamat Kode Baru!