Bagaimana mengatasi masalah pemrograman

Halo semuanya!

Hari ini, perhatian Anda diundang untuk menerjemahkan, dengan caranya sendiri, sebuah artikel yang tak tergantikan yang akan membantu Anda untuk mendekati dengan benar bahkan TK yang paling berbahaya dan tidak sepele, yang pada awalnya Anda tidak mengerti. Hal utama adalah jangan menyerah dan merumuskan pertanyaan secara cerdas. Mr. Justin Fuller dari Bank of America dengan ramah menguraikan cara melakukannya dengan benar.



Selamat membaca!

Jadi hari ini telah tiba. Mungkin ini adalah hari kerja pertama Anda, atau mungkin Anda telah bekerja di tempat ini selama sepuluh tahun - tidak masalah. Ini terjadi pada semua orang: Anda akhirnya menemukan tugas yang tidak Anda mengerti.

Apa yang harus dilakukan Mulai saja dan harap semuanya berjalan dengan baik? Atau mengakui kepada bos bahwa Anda tidak bisa melakukan ini, karena Anda tidak mengerti?

Saya pikir Anda menebak bahwa jawaban yang benar bukanlah satu atau dua!

Saya perhatikan bahwa dalam pemrograman, seperti dalam profesi lain, hampir tidak mungkin untuk menjalani satu minggu kerja (dan kadang-kadang satu hari kerja) tanpa harus menghadapi tugas yang sama sekali tidak bisa dipahami.

Tapi jangan khawatir! Ada berita bagus. Anda tidak hanya dapat menyelesaikan masalah ini - selain itu, ini juga dapat menguntungkan Anda.

Bagaimanapun, dalam melakukan itu, Anda harus memperluas pengetahuan dan keterampilan Anda dibandingkan dengan semua yang Anda lakukan dan ketahui sebelumnya.

Selanjutnya, saya akan memberi tahu Anda bagaimana menjembatani kesenjangan antara persyaratan yang telah ditetapkan untuk Anda dan pengetahuan yang Anda butuhkan untuk menyelesaikan tugas.

Tentang "persyaratan"

Seperti yang sudah Anda perhatikan, saya menggunakan kata "persyaratan". Bergantung di mana tepatnya Anda bekerja, kata ini mungkin memiliki konotasi tertentu.

Dalam pengalaman saya, di perusahaan besar mereka menyukai persyaratan, dan di perusahaan kecil mereka kadang-kadang "tidak menuntut." Saya pikir ini yang harus kita bicarakan di sini.

Faktanya adalah bahwa, pada akhirnya, semua programmer melakukan hal yang sama: mereka menyelesaikan masalah.
Anda bisa mendapatkan TK seratus halaman lengkap tentang cara mengatasi masalah ini (saya pernah menghadiri pertemuan selama satu jam tentang teks pada tombol). Atau mungkin begini: CEO berjalan melewati meja Anda dan seolah-olah secara tidak sengaja bertanya - "apakah Anda akan menyelesaikan tugas ini pada hari Jumat?"
Dalam kedua kasus - tugas diatur untuk Anda, dan Anda harus yakin bahwa Anda sepenuhnya memahaminya; satu-satunya cara Anda dapat mendekatinya dengan benar!

Tentang tahapannya

Tidak semua langkah yang tercantum di bawah ini akan diperlukan untuk tugas apa pun. Hanya tugas yang paling rumit yang mungkin membutuhkan penyelesaian semua langkah yang akan dibahas dalam artikel ini dengan cermat.

Ada kemungkinan bahwa banyak pertanyaan tidak dapat dijawab hanya berdasarkan persyaratan yang disuarakan atau karena kurangnya pengalaman pribadi Anda.

Anda mungkin perlu berkonsultasi dengan pengembang lain, pemimpin tim, pemilik produk, analis bisnis, atau bahkan nenek! Dan mungkin dengan masing-masing dari mereka, sebelum masalahnya dapat diselesaikan!

Namun, ini normal. Ini berarti bahwa Anda akan mengumpulkan pengetahuan yang berbeda dan mengumpulkannya menjadi satu kesatuan - sehingga Anda dapat mencapai hasil terbaik!

Akhirnya, peringatan terakhir: jangan berlebihan dengan formalisasi! Hal terpenting di sini adalah memahami tugas dengan cepat. Tidak diperlukan penghalang buatan dan pita merah! Yang diperlukan hanyalah rencana sistematis untuk menyelesaikan masalah yang saat ini tidak Anda pahami.

Tahap Satu: Analisis Masalahnya

Pada tahap ini, kami mencoba memahami apa yang diminta Anda lakukan. Sampai kita mencoba memutuskan bagaimana kita akan melakukannya!

Penting untuk menangkap perbedaan ini. Mungkin berbahaya untuk beralih ke karier tanpa menyadari semua konsekuensinya atau, lebih buruk lagi, tidak sepenuhnya memahami apa sebenarnya yang diminta Anda lakukan.

Kami mengklasifikasikan masalahnya

Untuk mengklasifikasikan tugas berarti menentukan pekerjaan apa yang harus dilakukan untuk menyelesaikannya. Berikut ini beberapa contoh jenis tugas:

• Perbaikan bug
• Fitur baru
• Aplikasi baru
• Tugas penelitian
• Optimalisasi kinerja

Ingat bahwa daftar opsi ini tidak terbatas.

Dalam hal ini, kami harus memutuskan pekerjaan seperti apa yang diharapkan dari Anda. Ini penting karena secara langsung akan memengaruhi pekerjaan seperti apa yang akan Anda lakukan.

Tahap ini sangat penting dengan persyaratan fuzzy, misalnya: "Kami membutuhkan cara untuk menghapus cache klien kami setelah memperbarui situs."

Berikut adalah beberapa kemungkinan interpretasi dari persyaratan ini.

1. Anda harus segera menerapkan mekanisme tertentu untuk membersihkan cache, sehingga klien selalu menerima pembaruan terkini.
2. Penting untuk mempelajari semua cara menyimpan cache klien ini dan menentukan opsi terbaik untuk menyingkirkan cache ini setelah setiap pembaruan situs.
3. Tembolok klien seharusnya sudah dihapus, dan Anda harus menemukan dan memperbaiki bug yang mencegahnya.

Pada tahap ini, jika Anda tidak benar-benar yakin apa arti penafsiran, Anda perlu mencari klarifikasi, dan baru kemudian terus bekerja.

Merumuskan esensi masalah dalam bentuk satu atau dua pernyataan sederhana.

Ringkaslah persyaratan yang rumit, seolah menjawab pertanyaan "apa yang Anda kerjakan hari ini?" Ini mungkin tidak begitu sederhana, tetapi Anda harus mencoba dan mengurangi esensi masalah menjadi satu atau dua kalimat.

Jika meringkas tugas dengan cara ini gagal, ini mungkin berarti bahwa itu harus dibagi menjadi beberapa subtugas. Pada prinsipnya, langkah ini berubah menjadi tes lakmus, menandakan apakah Anda berhasil mengatur tugas-tugas Anda dalam bentuk fragmen yang cukup kecil.

Berikut adalah contoh ringkasan yang bagus: "Saat memperbarui situs, kami melampirkan nomor unik untuk file, sehingga browser memahami bahwa itu harus menggunakan versi terbaru dari kode."
Tugas ini lulus "tes lakmus" untuk kesederhanaan dan, mungkin, tidak diperlukan untuk memecahnya menjadi fragmen yang lebih kecil.

Dan ini adalah contoh buruk: "Saat memperbarui situs, kami melampirkan nomor unik untuk file, sehingga browser memahami bahwa itu harus menggunakan versi terbaru dari kode. Kami juga harus mengirim pesan ke CDN kami, memberitahukannya dengan cara ini tentang perlunya memperbarui file. Penting juga untuk membayangkan bahwa aplikasi untuk iOS dan Android mengirimkan pembaruan ke pasar aplikasi. Lebih lanjut ... "

Dalam hal ini, tes pasti gagal. Banyak pekerjaan yang diperlukan, dan mungkin setiap tugas perlu diidentifikasi dan dilacak secara terpisah.

Sorot detail penting

Sekarang Anda harus (dalam bentuk bebas, yang paling nyaman bagi Anda) membuat daftar hal-hal utama yang perlu dilakukan.

Ini, sekali lagi, harus diperas sangat sederhana dari masing-masing tahap utama.

Ini bukan panduan langkah-demi-langkah atau pemecahan masalah terperinci.

Ingat itu sambil terus menganalisis tugas yang diberikan kepada Anda. Pada tahap ini, saya sarankan untuk membuat catatan tertulis. Secara pribadi, saya menggunakan aplikasi Notes untuk ini.

Tugas caching kami sangat sederhana dan, sangat mungkin, tidak perlu menguraikannya dengan cara ini. Mari kita lihat contoh yang lebih kompleks dalam kasus ini.

Tugas kami selanjutnya adalah mewujudkan peluang baru: “Setiap pengguna harus menerima iklan tertarget dari produk internal kami. Iklan ini harus disesuaikan dengan kebutuhan pengguna berdasarkan data yang kami kumpulkan. "

Untuk mengisolasi elemen-elemen utama dari tugas ini, kita harus dengan jelas membayangkan apa yang perlu dilakukan untuk mengimplementasikan setiap elemen.

• Iklan kami yang ada perlu didistribusikan sedemikian rupa sehingga mereka berkorelasi dengan beberapa parameter pengguna tertentu.
• Untuk departemen pemasaran kami, kami perlu menyediakan cara yang memungkinkan kami untuk menghubungkan iklan baru dengan satu atau lebih data pengguna (dalam hal ini, pemasar tidak boleh memprogram apa pun!)
• Sistem harus mengumpulkan parameter pengguna yang relevan dalam konteks iklan kami.
• Terakhir, Anda perlu membuat semacam sistem yang akan menerima ID pengguna dan menampilkan iklan.

Keindahan daftar tersebut adalah bahwa mereka dapat dengan cepat disepakati dengan tim atau bos! Jadi, dalam contoh ini, Anda dapat menunjukkan daftar ini kepada pemimpin tim Anda, dan dia memutuskan bahwa ada satu poin penting yang hilang dari daftar:

• Pengguna harus dapat memberi tahu kami bahwa mereka tidak lagi ingin melihat iklan tertentu.

Lagipula, pada akhirnya, hal terakhir yang kami ingin ganggu adalah pengguna favorit kami! Meluangkan waktu dan merenungkan tugas hanya beberapa menit, kita akan menyelamatkan diri dari masalah berjam-jam di masa depan. Jadi, penting untuk merumuskan dan merencanakan tugas penting, dan baru kemudian melanjutkan ke kode.

Sebelum melanjutkan, saya ingin menjawab kemungkinan kritik Anda.

Mungkin Anda berpikir: "Dalam bisnis yang biasanya dikirim, pekerjaan seperti ini harus dilakukan sebelum persyaratan diletakkan di atas meja untuk pengembang" - dan saya sangat setuju dengan Anda!

Namun, sayangnya, dunia kita tidak sempurna. Kadang-kadang persyaratan yang jatuh ke pengembang sama sekali tidak diletakkan di rak. Oleh karena itu, kita harus melakukan segala upaya untuk menilai persyaratan dengan benar sebelum memulai pengembangan.

Identifikasi masalah yang ingin Anda selesaikan.

Jawab pertanyaan: "mengapa ada orang yang harus menggunakan ini?" atau "Apa masalah nyata atau yang dirasakan yang saya coba untuk perbaiki dalam kasus ini?"

Semoga jawabannya jelas. Dalam contoh pertama kami, diberikan di sini, jawabannya adalah: "pengguna akan selalu melihat pembaruan terbaru." Dalam kasus kedua, dengan iklan, "pengguna akan selalu melihat pemberitahuan yang relevan, bukan yang tidak menarik minat mereka."

Penggunaan kedua jawaban ini harus jelas! Dengan pemahaman yang lebih mendalam tentang tugas dan sasarannya, Anda dapat membuat keputusan yang lebih masuk akal dan membuat implementasi yang akan memenuhi sasaran bisnis Anda dengan benar. Jika dimungkinkan untuk mengidentifikasi solusi buruk dan tugas yang tidak berarti, maka akan mungkin untuk tidak membuang waktu dan energi dalam pencarian yang, menurut definisi, tidak akan membantu menyelesaikan masalah.

Tahap dua: menafsirkan dan mengevaluasi persyaratan

Pada tahap ini, Anda harus sudah membayangkan apa yang harus Anda lakukan dan mengapa.
Selanjutnya, Anda perlu memahami detail dari apa yang akan Anda lakukan, bagaimana Anda akan melakukannya dan mengapa Anda akan melakukannya dengan cara itu.
Hapus istilah-istilah penting yang terkait dengan tugas Anda.

Langkah ini mungkin lebih penting bagi pengembang pemula sebagai bagian dari tim, atau jika Anda bekerja di perusahaan besar. Dalam kedua situasi ini, sangat mungkin Anda menemukan persyaratan yang tidak dikenal dalam persyaratan.

Ini mungkin konsep bisnis, seperti nama produk, pelanggan, atau proses. Mungkin ada istilah yang terkait dengan pengembangan - misalnya, nama alat, aplikasi, model, layanan, atau perpustakaan.

Anda perlu memastikan bahwa Anda memahami semua istilah penting dengan sangat jelas, sehingga Anda dapat yakin bahwa Anda menerapkan tugas dengan benar.

Mungkin Anda sudah mengerti bahwa Anda perlu menemukan cara untuk mengakses informasi pengguna teragregasi, tetapi apakah Anda mengerti apa artinya "menambahkannya ke dao"?
Anda mungkin mengerti bahwa Anda perlu memformat data periklanan, tetapi apakah Anda tahu apa itu "MADF" (markup untuk feed berita iklan)?

Saya tidak mengerti satu atau yang lain.

Itu sebabnya Anda perlu mengisolasi dan mendefinisikan semua istilah penting. Bingung dalam definisi adalah cara yang tepat untuk menyelesaikan masalah secara tidak benar.

Putuskan bagaimana tugas harus dilakukan.

Pada tahap ini, Anda harus sudah mengetahui bagaimana tugas akan dilakukan. Detail dari proses ini dapat sangat bervariasi tergantung pada tempat Anda bekerja dan tugas spesifik apa yang Anda tetapkan.

Di beberapa tim, tidak ada yang akan menjelaskan kepada Anda bagaimana menerapkan persyaratan, mereka hanya akan mengatakan fungsionalitas apa yang harus diperoleh pada output.

Di langkah lain, setiap langkah yang Anda ambil akan dirinci.

Kemungkinan besar, Anda akan berada dalam semacam situasi menengah.

Jika tim tidak memberi Anda instruksi, maka pada tahap ini Anda tidak akan bisa melakukan apa pun. Jika Anda telah menerima instruksi, maka mulailah berkenalan dengan tahapan yang harus Anda lalui.

Langkah ini tampaknya sepenuhnya alami, tetapi penting untuk memperhatikan dengan tepat urutan di mana kita melanjutkannya.

Secara alami, kami ingin terjun ke semua detail tugas sekaligus dan mempelajarinya sampai tujuan yang kami tetapkan benar-benar jelas bagi kami.

Namun, karena Anda telah meluangkan waktu untuk memahami masalah, Anda sekarang harus memiliki gagasan yang lebih jelas tentang keseluruhan masalah, mengevaluasi langkah-langkah yang perlu diambil untuk mencapainya.

Tentukan apakah tugas sedang ditangani.

Pada tahap ini, tahapan analisis dan interpretasi bergabung bersama. Pada fase analisis, Anda fokus pada gambaran holistik dan tujuan skala besar - apa yang kami lakukan dan mengapa.

Pada fase interpretasi, fokuslah pada detail - bagaimana kita melakukannya.

Tahap kedua disebut "interpretasi dan evaluasi", karena sekarang Anda dapat menghubungkan "bagaimana" dan "apa dan mengapa." Anda menginterpretasikan detail berdasarkan gambar keseluruhan. Anda mengevaluasi detail dan menentukan apakah masalah asli telah diatasi.

Tanyakan kepada diri sendiri: akankah langkah-langkah yang saya perintahkan untuk mengarahkan pada hasil, yang ditetapkan sebagai tujuan akhir dari tugas? Apakah hasil yang direncanakan benar-benar menyelesaikan masalah aslinya?

Jika Anda yakin bahwa semua masalah dapat diselesaikan, dan detailnya bermakna, maka Anda bisa mulai bekerja! Kalau tidak, maka perlu untuk pergi ke tahap ketiga untuk menyelesaikan semua jenis konflik.

Tahap Tiga: Kami Mendekati Masalah dengan Kritis

Pada tahap ini, Anda harus dapat dengan yakin menyatakan bahwa Anda memahami tugas dan solusinya. Yang masih harus dilihat adalah apakah keputusan ini benar.

Untuk menciptakan produk dengan kualitas terbaik, kita semua harus dapat mengambil tanggung jawab dan berbicara jika beberapa hal jelas salah.

Di sisi lain, kami tidak akan membuat klaim yang tidak pantas. Orang tidak dapat mengatakan bahwa ada sesuatu yang salah, karena "sepertinya begitu" atau "tidak suka". Argumen yang konkret dan dirancang dengan baik harus diajukan.

Jadi, kami menguraikan aturan dasar ketidaksetujuan yang kompeten

Tahu kapan harus tidak setuju

• Ketidaksepakatan tidak dapat diterima, sampai saya menemukan masalahnya secara menyeluruh.
  Mengatakan "ini salah" hanya mungkin dengan kepastian absolut bahwa Anda memahami apa yang tidak Anda setujui /
  Jika Anda tidak dapat dengan yakin merumuskan masalah dan solusi yang direncanakan, maka Anda tidak dapat tidak setuju. Jika Anda tidak yakin bahwa Anda memahami semuanya dengan benar, Anda tidak dapat tidak setuju. Hanya dengan memastikan bahwa Anda memahami masalah dengan detail terkecil, Anda mampu untuk tidak setuju.
  Jika Anda merasa tidak memiliki semua informasi yang diperlukan, mungkin sudah saatnya untuk berhenti dan meninjau semua langkah yang telah diselesaikan sebelum mengklaim bahwa persyaratannya salah.
• Seseorang tidak bisa tidak setuju untuk alasan subyektif. Cari potensi masalah asli.
  "Saya tidak suka bagaimana ini dilakukan" adalah penilaian subyektif. "Ini akan menyebabkan masalah kinerja karena begitu banyak operasi yang terlibat" adalah alasan objektif. Contoh alasan subyektif lainnya: "Dan pada proyek lain kami melakukannya secara berbeda" atau "Saya akan menerapkan solusi ini sedikit berbeda, tetapi ini, tentu saja, adalah masalah selera."
• Anda harus memiliki penjelasan matang yang siap mendukung klaim Anda.
  Jika Anda tidak dapat menjelaskan mengapa ada sesuatu yang salah - dapatkah Anda yakin benar? Saya menyarankan Anda untuk menuliskan alasan mengapa keputusan itu keliru bagi Anda, dan merumuskan bagaimana hal itu dapat diperbaiki.

Jika Anda tidak dapat menawarkan solusi seperti itu, katakan padaku dengan jelas sejak awal.

Berhati-hatilah saat tidak setuju dengan orang lain. Dibutuhkan banyak waktu untuk mendengarkan semua orang dan memahami segalanya - dan hanya dengan begitu Anda tidak bisa setuju.

Jika sampai titik ini Anda dengan cermat mengikuti semua langkah yang dijelaskan, maka sangat mungkin Anda berpengalaman dalam segala hal. Namun, cobalah untuk tidak mengunci diri sendiri dalam perhitungan Anda - Anda bisa melewatkan sesuatu!

Saya suka memulai diskusi dengan kata-kata: "Bukannya saya tidak setuju dengan Anda, saya hanya belum mengerti." Kemudian, jika perlu, ketidaksepakatan yang kuat dapat diungkapkan, tetapi sebagai permulaan - untuk mencari tahu.

Ketahui cara tidak setuju dengan benar

Untuk menjamin bahwa ketidaksetujuan kami akan objektif, kami akan mengambil sejumlah langkah yang akan membantu kami memahami apakah argumen kami sah atau tidak.

Ketidaksepakatan obyektif memungkinkan kita untuk menunjukkan setidaknya satu dari fakta-fakta berikut:

• Keputusan tidak diinformasikan dengan baik
• Keputusan salah informasi
• Tugas atau solusi itu tidak logis
• Solusi tidak lengkap

Kurangnya informasi bukan alasan untuk kebencian; itu hanya berarti bahwa ketika membuat solusi, Anda berasal dari data yang tidak lengkap. Mungkin para perancang TK tidak tahu tentang sistem yang sudah ada, mampu melakukan tindakan yang diperlukan.

Informasi yang salah berarti menciptakan solusi berdasarkan informasi yang salah.

Ini adalah kasus ketika, menurut pendapat para perancang TK, sistem yang ada dapat melakukan sesuatu, tetapi dalam kenyataannya kemungkinan ini tidak disediakan di dalamnya. Misalnya, tim SEO meminta Anda membuat Google mengindeks halaman tersebut dengan akun pengguna di aplikasi Anda. Google tidak dapat melakukan ini. Ini artinya seokhniki Anda salah memahami fungsi robot pencarian Google.

Tugas yang tidak masuk akal atau solusi tidak logis sama sekali tidak berarti. Contoh khas (dari sudut pandang pengembang) adalah untuk mengimplementasikan fitur yang akan menurunkan beberapa fitur lainnya. Persyaratan seperti itu dapat dianggap tidak logis, karena lebih cenderung membahayakan daripada membantu.

Solusinya tidak lengkap, dan kadang-kadang dilakukan dengan sengaja. Dalam pengembangan perangkat lunak, kami sering mencoba membuat MVP (produk minimum yang layak) untuk memulai. Ini berarti bahwa dalam operasi pertama, Anda dapat dengan sengaja menunda implementasi fungsional yang tidak mutlak diperlukan.

Bahkan, sebuah keputusan dapat dianggap tidak lengkap hanya jika itu tidak menyelesaikan masalah yang Anda tetapkan, atau jika langkah-langkah di atas tidak cukup untuk menciptakan produk yang bisa diterapkan atau peluang penuh.