Hai Nama saya Oleg, dan saya adalah pengembang frontend di Alfa Bank. Saya ingin menceritakan sedikit kisah filosofis - tentang pendekatan rekayasa untuk pengembangan, tentang pekerjaan pertama saya dan penggaruk yang saya kumpulkan di sana, tentang mengapa checklist sangat penting (dan menyelamatkan nyawa).
Dan juga tentang bagaimana terus bekerja secara produktif dan tidak menggali banyak tugas kecil dan tidak terlalu banyak.
Semuanya dimulai dengan kekacauan.
Pada pekerjaan pertama saya (bukan Alpha, tidak) saya entah bagaimana diambil dan segera dilemparkan ke dalam lubang, kata mereka, teman, sekarang Anda melakukan CRM, perusahaannya ada di sana. Apa yang harus dilakukan dan bagaimana melakukannya - saya tidak mengerti sama sekali. Apa yang biasanya mereka lakukan dalam situasi seperti itu? Itu benar - mereka lari ke kolega mereka dan mulai memeriksa dengan mereka cara mengirimkan kode ke server, bagaimana hal-hal dengan git, praktik apa yang kita gunakan, dan mana yang tidak, dan sebagainya. Pendekatan ini membantu saya, dan saya terus-menerus menyarankan orang lain untuk melakukannya. Ajukan, ajukan pertanyaan, bahkan jika itu tampak jelas bagi Anda, tentukan apa yang perlu diklarifikasi. Ini normal. Tidak normal untuk tidak bertanya.
Langkah saya selanjutnya adalah menggunakan buku. Karena ketika saya mengembalikan pertanyaan dan mendapatkan jawaban seperti "Yuzay linter", saya mendapati diri saya berpikir bahwa saya tahu bagaimana melakukan semua ini, tetapi saya tidak mengerti mengapa. Saya sungguh-sungguh tertarik untuk mengetahui di mana kaki tumbuh dalam semua proses, dan saya memutuskan untuk mencari bantuan dalam buku-buku. "Kode murni", "Kode sempurna" - secara umum, saya pergi ke set standar, di mana mereka mengatakan bahwa fungsinya tidak boleh lebih dari 30 baris. Saya harus segera mengatakan bahwa itu tidak membantu untuk memahami segalanya dan mengendalikan kekacauan.
Ya, saya mulai menulis dengan lebih bersih, tetapi kekacauan dalam bentuk tumpukan tugas, yang biasanya tidak bisa saya selesaikan, tidak hilang. Kolega memutuskan untuk membantu dengan nasihat bijak seperti "Bung, Anda hanya tidak memiliki cukup keunggulan, mari kita baca tentang keunggulan di sini dan semuanya akan keren dengan Anda, jika Anda juga memberikan Scrum-master."
Ya benar. Agile sendirian adalah hal yang baik. Tetapi ketika Anda bekerja dalam sebuah tim. Dan Edge satu muka sedikit aneh. Saya mulai menggali lebih jauh, menemukan buku-buku kaizen. Dan kemudian saya bertemu dengan teori pembatasan sistem dan buku "Tujuan". Banyak yang mungkin membacanya, jadi saya hanya akan mencatat secara singkat bahwa salah satu pesan utama di sini bukan untuk memperbaiki semuanya di mana saja sekaligus, tetapi pertama-tama menemukan satu masalah dan memperbaikinya. Memperbaiki - mencari yang berikutnya dan memperbaikinya. Penulis datang ke ini melalui pendekatan teknik, karena insinyur melakukan sesuatu seperti ini - mereka mencari masalah dan menyelesaikannya.
Oke, ini lirik, mari kita lebih dekat ke latihan.
Dalam hidup
Misalkan Anda memiliki semacam proses bola dalam ruang hampa di mana ada desainer, front-end dan tester. Perancang menggambar tata letak dan tombol dalam satu hari, ujung depan bekerja dalam tiga hari dengan ini, dan tester membutuhkan dua hari. Tampaknya menjadi skema sederhana dan segera jelas di mana harus meningkatkan proses - di front-end, karena pekerjaannya paling banyak memakan waktu. Maksudnya, titik optimasi adalah untuk menemukan tahap paling lambat dalam proses.
Tapi ini adalah contoh sederhana dengan tiga variabel. Tentu saja, pekerjaan seringkali berbeda. Dan jauh berbeda. Proses menjadi rumit ketika Anda memiliki backend, dokumentasi, CI / CD dan alat penting lainnya.
Dan kemudian tidak akan mungkin untuk segera mengambil dan mengatakan proses mana yang paling lambat dan di mana untuk memulai. Di sini, proses mengoptimalkan tahap paling lambat akan terlihat seperti ini:
- Kita harus menemukan batasannya, paling lambat.
- Putuskan bagaimana menggunakannya sebanyak mungkin.
- Subordinasikan segalanya ke keputusan.
- Untuk mengembangkan (memperluas) pembatasan.
- Kembali dan ulangi.
Mungkin terdengar berantakan, jadi saya akan menulis lebih detail.
Apa yang harus dilakukan, apakah Anda memiliki tugas paralel yang sibuk dengan Anda?
Dalam hal ini, Anda akan mencari rute terpanjang berdasarkan hari secara total. Pada gambar di atas sekitar 6 hari. Mulailah dengan itu, dengan proses terpanjang ini. Ternyata dalam contoh ini Anda akan meningkatkan backend, karena dibutuhkan 4,5 hari. Ini juga tidak begitu sulit, tetapi ketika Anda sampai pada hal ini dan mulai melakukannya, Anda memperhatikan bahwa hidup menjadi lebih mudah.
Saya akan kembali ke contoh kekacauan kerja saya. Saya mendapat banyak tugas dan saya tidak punya waktu. Saya menyadari bahwa ada batasan di frontend (yaitu, pada saya), bahwa masalahnya bukan pada tester, karena dia menemukan bug, yaitu di sisi saya. Untuk melakukan sesuatu, saya mulai berpikir bagaimana cara menggunakan batasan ini.
Dan dia memutuskan bahwa kita perlu mengubah prosesnya sehingga hanya ada satu titik masuk - satu orang yang membuat keputusan tentang apakah kita akan melakukan tugas atau tidak. Karena ada kasus ketika satu orang datang dan berkata, Oleg, kita perlu memindahkan tombol di sini sedikit ke kanan. Dan satu lagi. Dan dalam setengah jam orang lain dengan tugas serupa. Dan tampaknya itu hal-hal kecil dan sampah, tetapi pada akhirnya saya menjahit sepenuhnya, mencoba untuk menyenangkan semua orang.
Sekarang saya mencoba melakukan tidak lebih dari 2 tugas secara paralel (paralel, dan tidak bersamaan). Sebelumnya, saya bisa memberi tugas pada tester dan melakukan yang berikut, tetapi jika tester menemukan bug, saya harus memeriksa, mengingat, dan beralih ke kode apa yang ditulis di sana, yang lebih sulit daripada yang terdengar ketika Anda sering berganti. Dan secara umum, beralih itu mahal. Cobalah untuk tidak melakukan lebih dari 2 tugas secara paralel. 3 tugas sudah menjadi cara untuk menjahit.
Mari kita pikirkan tentang bagaimana menundukkan segala sesuatu yang lain pada keputusan. Tampaknya terdengar logis, ya, bahwa jika ada begitu banyak tugas, maka Anda tidak perlu membuang slide? Misalnya, Anda mengharapkan seseorang untuk melakukan tiga tugas dengan kompleksitas yang kira-kira sama dalam tiga hari. Jika dalam dua hari dari tiga ia hanya melakukan satu tugas, kemungkinan besar ia tidak cocok dengan rencana, jadi melempar lebih banyak tugas dari atas adalah hal yang sedikit menurunkan motivasi.
Lebih lanjut tentang batasan
Tentu saja, pembatasan dapat diperluas. Dalam contoh kami, sewalah front lain. Ini juga logis, lebih banyak front - mereka akan punya waktu untuk menyelesaikan lebih banyak tugas. Maka pembatasan akan ditransfer ke tempat lain.
Ada juga pendekatan di mana mereka memperluas bukan jumlah unit, tetapi kompetensi mereka. Saya punya contoh hidup - tester dapat membantu saya di ujung depan jika saya tahu ujung depan. Bagi kolega saya, master scrum mulai menulis frontend sendiri, karena ia tertarik, ia melakukan beberapa fitur di sana dengan binar, dan ia bersenang-senang dan tim membantu. Saya tidak mendesak untuk melakukan ini di rumah, karena hasilnya bisa sangat berbeda, tetapi sebagai contoh, ada pendekatan seperti itu - ya, dan kadang-kadang berhasil.
Daftar periksa
Daftar-pembanding sangat membantu membuat hidup lebih mudah.
Daftar periksa untuk Alfa-Bank ini sekarang banyak membantu dalam pekerjaan saya
, di mana ada beberapa tahapan yang perlu diselesaikan.
Cheklists bahkan menyelamatkan nyawa, saya akan memberikan kutipan kecil dari buku
"Memahami risikonya. Bagaimana memilih kursus yang tepat ":
Pada awal penerbangan, pilot terbang di pesawat yang tidak dilengkapi dengan peralatan teknis seperti sekarang. Daftar periksa mulai digunakan di Angkatan Udara AS hanya setelah menjadi jelas bahwa pesawat pembom B-17 terlalu besar dan tidak dapat dikendalikan oleh hanya satu orang. Pada tahun 2009, ketika kedua mesin berhenti pada penerbangan US Airways 1549 segera setelah lepas landas dari Bandara La Guardia, para pilot melakukan semua tindakan daftar periksa dalam keadaan darurat seperti itu, termasuk upaya untuk menyalakan kembali mesin. Pramugari, sekali lagi sesuai dengan daftar periksa, secara ketat memonitor persiapan penumpang yang tepat untuk pendaratan darurat. Daftar periksa seperti ini adalah cara sederhana dan murah untuk meningkatkan keamanan.
Dalam dunia kedokteran, gambaran yang berbeda diamati. Setiap tahun, penyalahgunaan kateter vena sentral menyebabkan sekitar 80 ribu kasus infeksi aliran darah, dan sebagai hasilnya, sekitar 28 ribu orang meninggal di unit perawatan intensif di rumah sakit Amerika. Dan pasien yang berhasil bertahan hidup menghabiskan satu minggu tambahan tambahan rata-rata dalam perawatan intensif. Total biaya untuk mengobati infeksi tersebut diperkirakan $ 2,3 miliar per tahun. Apa yang bisa menyelamatkan orang-orang ini? Obat yang lebih baik untuk mengobati infeksi, teknologi yang lebih baik? Jawabannya adalah: meningkatkan budaya kesalahan.
Pada tahun 2001, Peter Pronovost dari Rumah Sakit Johns Hopkins menyusun daftar periksa sederhana untuk dokter ruang gawat darurat untuk memeriksa apakah langkah-langkah ini dapat mengurangi penyebaran infeksi. Berikut adalah lima langkah berturut-turut yang dirancang untuk mencegah bakteri berbahaya memasuki pasien:
1) mencuci tangan dengan sabun;
2) rawat kulit pasien dengan antiseptik klorheksidin;
3) tutupi pasien dengan lembaran steril;
4) kenakan masker, topi, celemek dan sarung tangan steril;
5) oleskan bahan steril di atas kateter setelah kateter dimasukkan ke dalam vena.
Dalam daftar ini, masing-masing tindakan perlindungan diketahui dengan baik, tidak mengandung sesuatu yang baru. Pronovost meminta perawat yang bekerja di unit perawatan intensifnya untuk melihat apakah dokter mengikuti 5 aturan ini. Perawat melaporkan bahwa ketika memasang kateter, lebih dari sepertiga dari semua pasien memiliki satu atau lebih dari aturan ini yang tidak diikuti. Tingkat infeksi aliran darah di rumah sakit saat itu adalah 11%.
Pronovost meyakinkan administrasi rumah sakit untuk mengizinkan perawat menghentikan dokter jika mereka melewatkan salah satu dari lima langkah yang ditentukan. Inovasi revolusioner ini melanggar struktur hierarkis di mana personel paramedis (terutama wanita) tidak memiliki hak untuk memberikan instruksi kepada ahli bedah (terutama pria). Setelah satu tahun, selama instruksi ini diikuti secara ketat, tingkat infeksi aliran darah pada pasien rumah sakit menurun dari 11% menjadi 0 (!). Dan selama 15 bulan ke depan, hanya 2 kasus infeksi tersebut yang dicatat. Di rumah sakit ini saja, daftar instruksi mencegah 43 infeksi, 8 kematian, dan menghemat $ 2 juta.
Untuk menunjukkan bahwa efek dari menggunakan daftar periksa tidak terbatas pada rumah sakitnya, Pronovost meyakinkan lebih dari seratus unit perawatan intensif di Michigan untuk berpartisipasi dalam studi bersama skala besar. Penting untuk dicatat bahwa masing-masing dari mereka mengembangkan daftar tindakan mereka sendiri yang paling relevan dengan budaya mereka.
Unit perawatan intensif yang berpartisipasi dalam penelitian ini melaporkan bahwa sebelumnya mereka memiliki total 695 kasus infeksi aliran darah karena penggunaan kateter. Hanya 3 bulan setelah dimulainya penggunaan daftar periksa di sebagian besar departemen, tingkat infeksi pasien turun menjadi nol. Unit perawatan intensif yang tersisa juga berhasil mengurangi indikator ini secara signifikan selama satu setengah tahun selama penelitian dilakukan. Program skala besar untuk menyelamatkan nyawa ini dilaksanakan tanpa menggunakan teknologi mahal dan tanpa menambah jumlah staf rumah sakit.Artinya, masing-masing poin ini diketahui, ini bukan semacam hal baru atau sesuatu yang lain. Peter hanya mendesainnya dalam format checklist dan membuatnya wajib. Itu saja.
Kami mencoba untuk meningkatkan tidak hanya hasil kami, tetapi juga hasil orang lain, jadi kami terus memperbarui daftar periksa kerja kami. Jika tiba-tiba saya lupa sesuatu dan tidak melakukan sesuatu dalam proses itu, saya letakkan di daftar periksa agar tidak lupa di lain waktu. Sebelumnya, model sering dikembalikan ke perancang untuk dikerjakan ulang, meskipun dia mengatakan bahwa dia segera memahami segalanya dan akan melakukannya dengan benar, dan setelah itu dia hanya meminta kami untuk daftar periksa, saya membuang sebagian untuk desain, dan itu menjadi lebih mudah.
Saya mengurutkan daftar periksa saya dengan tindakan - 1 tindakan = 1 item daftar periksa. Hal utama di sini adalah tidak beristirahat dengan kuat dan tidak masuk ke daftar periksa demi daftar periksa. Riasan Halaman adalah poin yang bagus. "Kontrol make up" - bahkan lebih, akan membantu untuk tidak melupakan kontrol dan nuansa mereka.
Daftar periksa dapat berupa hierarki: tata letak halaman -> tata letak halaman -> tata letak halaman.
Mengapa hanya coding saja tidak cukup
Tes diperlukan. Tetapi mereka tidak selalu dibutuhkan. Misalnya, Anda melakukan pendaratan satu kali, dan tidak berencana untuk mengembalikannya nanti - maka tidak ada gunanya mendorongnya dengan keras. Anda dapat menutupi penyeleksi dengan unit atau menggunakan end2end, tetapi tes unit untuk sisanya adalah buang-buang waktu.
Tapi itu sebabnya pengkodean tidak cukup. Sekali lagi, contoh dari pekerjaan pertama - saya harus mengubah sesuatu, saya pergi ke rekan kerja dan membicarakannya, mereka menjawab bahwa mereka sibuk. Dan sprint saya terbakar. Dan tidak ada yang membantu. Akibatnya, ia mulai memahami dirinya dalam kompetensi tambahan.
Misalkan Anda memiliki keterampilan yang baik, misalnya, bekerja dengan CI / CD. Perancang memberi Anda tata letak dan pergi berlibur, Anda memiliki beberapa suntingan atau pertanyaan, tetapi sampai dia kembali dari liburan, itu saja, prosesnya sepadan. Perluas keterampilan Anda, karena jika titik lemah dalam prosesnya adalah di sisi desain, yah, perancang dijahit karena sejumlah alasan, Anda dapat membantunya. Ini adalah seperangkat pengetahuan tambahan, tetapi bisa dikuasai. Tentu saja, saya tidak berbicara tentang mengganti sepenuhnya dan sepenuhnya spesialis, saya berbicara tentang keterampilan dasar.
Kesimpulan
Sangat berguna untuk mendekati masalah ini sebagai seorang insinyur. Bahkan jika pekerjaan Anda tidak bersifat rekayasa. Ini memungkinkan Anda untuk tidak memperkenalkan segala sesuatu secara berurutan, tetapi untuk menemukan masalah dan hanya memperkenalkan apa yang berkontribusi pada solusinya.
Perlu berkomunikasi dan mendiskusikan solusi. Komunikasi pada prinsipnya sulit ditaksir terlalu tinggi. Terkadang masalah muncul karena apa yang disebut inisiatif bisu. Kami memiliki kasus ketika kami diberi pengembang .Net dan tugas sederhana baginya untuk menulis tes. Dia dengan cepat menulis semuanya, tes, tes unit, seleksi, dan kemudian untuk beberapa alasan mulai melakukan sesuatu di luar apa yang ada di tugas. Ternyata, dengan keyakinan bahwa ini akan bermanfaat bagi kita. Akibatnya, semua yang dia lakukan membuat kami menghabiskan banyak waktu untuk sinkronisasi tambahan, dan semua ini pada dasarnya menjadi sampah pada dasarnya. Hanya karena masalah komunikasi dasar. Jangan lakukan itu.
Nah, daftar buku yang bermanfaat:
- Teori Pembatasan Sistem (E. Goldratt)
- Manajemen proyek rantai kritis (E. Goldratt)
- Gemba kaizen - cara untuk mengurangi biaya dan meningkatkan kualitas (M. Imai)
- Manajemen Agile: Kepemimpinan dan Manajemen Tim (A. Jürgen)
- Penjelasan Pemrograman Ekstrim (K. Beck)
Presentasi terperinci dapat ditemukan di
sini .
Apakah Anda menggunakan daftar periksa, apakah Anda menganggapnya perlu? Jika Anda memiliki pendekatan untuk mempertahankan atau membuat daftar periksa, silakan bagikan dalam komentar.