Bagaimana memahami tugas pemrograman apa pun

Hari itu akhirnya tiba. Apakah ini hari pertama Anda bekerja, atau apakah Anda sudah melakukan ini selama sepuluh tahun? Tidak masalah. Kita semua akhirnya menemukan diri kita dengan tugas yang tidak kita mengerti.

Jadi apa yang harus kamu lakukan? Haruskah Anda memulai dan berharap ini berhasil? Haruskah Anda segera memberi tahu atasan Anda bahwa Anda tidak dapat melakukan ini karena Anda tidak mengerti?

Saya membayangkan bahwa Anda tahu jawabannya bukan keduanya!

Dalam pemrograman, seperti halnya profesi lain, saya telah menemukan bahwa hampir tidak mungkin melewati seminggu (dan terkadang bahkan tidak sehari) tanpa menemukan beberapa masalah yang tidak saya mengerti.

Tapi jangan khawatir! Saya punya kabar baik. Anda tidak hanya dapat memperbaiki masalah ini, tetapi juga bisa menjadi hal yang baik.

Ini berarti bahwa dalam beberapa cara Anda mengembangkan keterampilan dan pengetahuan Anda melebihi apa yang telah Anda lakukan dan ketahui sebelumnya.

Dalam beberapa paragraf berikutnya saya akan menjelaskan secara rinci bagaimana Anda dapat menjembatani kesenjangan antara persyaratan yang telah Anda terima, dan pengetahuan yang Anda butuhkan untuk menyelesaikan tugas yang telah diberikan kepada Anda.

Tentang 'persyaratan'

Anda mungkin telah memperhatikan bahwa saya menggunakan kata "persyaratan". Kata itu mungkin memiliki konotasi tertentu tergantung tempat Anda bekerja.

Menurut pengalaman saya, perusahaan besar menyukai persyaratan dan perusahaan kecil terkadang "tidak memenuhi persyaratan". Saya pikir ini baik-baik saja untuk tujuan kita di sini.

Itu karena pada akhirnya yang kami lakukan sebagai insinyur perangkat lunak adalah memecahkan masalah.

Anda dapat menerima laporan seratus halaman ekstensif tentang cara mengatasi masalah itu (saya pernah mengadakan rapat selama satu jam tentang teks untuk sebuah tombol). Atau mungkin CEO Anda akan berbondong-bondong ke meja Anda dan dengan santai bertanya apakah Anda bisa menyelesaikan masalah pada hari Jumat.

Apa pun itu - Anda telah diberi tugas, dan Anda harus yakin bahwa Anda benar-benar memahami masalah itu untuk mengatasinya dengan benar!

Tentang langkah-langkahnya

Tidak semua langkah yang diberikan di bawah ini diperlukan untuk setiap masalah. Hanya masalah tersulit untuk dipahami yang mengharuskan Anda untuk melanjutkan dengan hati-hati melalui semua langkah yang akan dibahas dalam artikel ini.

Banyak dari pertanyaan yang mungkin tidak dapat dijawab melalui persyaratan yang telah Anda berikan, atau melalui pengalaman pribadi Anda sendiri.

Anda mungkin harus bertanya kepada pengembang lain, pimpinan tim Anda, pemilik produk, analis bisnis, atau bahkan nenek Anda. Mungkin Anda harus menanyakan semuanya pada saat Anda selesai!

Tidak apa-apa. Ini berarti Anda akan mengambil pengetahuan yang tersebar dan memadatkannya untuk ditempatkan di satu tempat. Tempat itu ada di dalam diri Anda dan sekarang Anda akan dapat memberikan hasil yang terbaik!

Peringatan terakhir sebelum Anda mempelajari langkah-langkahnya: jangan terlalu memformalkan proses ini. Intinya di sini adalah untuk membantu Andamemahami masalah dengan cepat . Seharusnya tidak menciptakan hambatan atau birokrasi! Alih-alih, laporan itu harus memberi Anda rencana sistematis untuk mengatasi masalah yang tidak Anda pahami.

Langkah pertama: Menganalisis tugas

Pada langkah ini, Anda akan berusaha memahami apa yang diminta untuk Anda lakukan. Anda belum mencoba mencari cara untuk melakukannya!

Perbedaan di sini penting. Berbahaya untuk langsung menerapkan tanpa memikirkan semua konsekuensinya, atau lebih buruk lagi, tanpa mengidentifikasi dengan tepat apa yang diminta untuk Anda lakukan.

Klasifikasikan tugas

Untuk mengklasifikasikan tugas berarti menentukan jenis pekerjaan yang akan Anda lakukan untuk memecahkan masalah ini. Berikut beberapa contoh jenis tugas:

  • Perbaikan bug
  • Fitur baru
  • Aplikasi baru
  • Penugasan Penelitian
  • Peningkatan performa

Ingatlah bahwa ini bukan semua opsi yang memungkinkan.

Tujuannya di sini adalah untuk menentukan jenis pekerjaan apa yang diharapkan untuk Anda lakukan. Hal ini penting karena memiliki efek langsung pada apa yang bekerja Anda lakukan.

Langkah ini sangat penting untuk persyaratan yang tidak jelas. Contoh dari persyaratan yang tidak jelas adalah: "Kami membutuhkan cara untuk membersihkan cache klien kami setelah situs diperbarui."

Ada beberapa kemungkinan interpretasi.

  1. Anda perlu segera menerapkan beberapa mekanisme pembersihan cache agar klien selalu melihat pembaruan terkini.
  2. Anda perlu meneliti semua cara penyimpanan cache klien dan menentukan cara terbaik atau cara untuk memecahkan cache tersebut setelah setiap pembaruan situs web.
  3. Cache klien sudah seharusnya dibersihkan dan Anda perlu menemukan dan memperbaiki bug yang mencegah mereka untuk membersihkannya.

Pada titik ini, jika Anda tidak benar-benar yakin arti mana yang digunakan, Anda harus meminta klarifikasi sebelum melanjutkan.

Sebutkan tugas apa dalam satu atau dua kalimat sederhana.

Ringkas persyaratan yang rumit seolah-olah Anda telah ditanyai apa yang Anda kerjakan hari ini. Mungkin tidak sesederhana itu, tetapi Anda harus bisa meringkasnya menjadi satu atau dua kalimat.

Jika Anda tidak dapat meringkas tugas, itu mungkin berarti Anda harus membaginya menjadi beberapa tugas. Jadi pada dasarnya langkah ini menjadi tes lakmus untuk menentukan apakah Anda telah mengatur tugas-tugas Anda menjadi bagian-bagian yang cukup kecil.

Berikut adalah contoh ringkasan yang bagus: "Saat kami memperbarui situs, kami menambahkan nomor unik ke file sehingga browser tahu bahwa ia perlu menggunakan kode terbaru."

Tugas ini lolos uji lakmus kesederhanaan dan Anda mungkin tidak perlu membuat banyak tugas.

Contoh yang buruk mungkin terlihat seperti: Saat kami memperbarui situs, kami menambahkan nomor unik ke file sehingga browser tahu itu perlu menggunakan kode terbaru. Kami juga harus mengirim pesan ke CDN kami yang memberi tahu bahwa CDN perlu memperbarui file. Aplikasi iOS dan Android juga perlu memiliki pembaruan yang dikirim ke toko aplikasi. Juga…"

Yang ini jelas gagal dalam ujian. Ada banyak pekerjaan yang harus dilakukan dan mungkin perlu diidentifikasi dan dilacak secara terpisah.

Buat garis besar bagian-bagian utama

Dalam bentuk apa pun yang paling nyaman bagi Anda, sekarang Anda harus membuat daftar hal-hal utama yang harus dilakukan.

Ini tetap harus menjadi ringkasan yang sangat sederhana dari setiap langkah utama.

Ini tidak boleh menjadi panduan langkah demi langkah atau panduan mendetail tentang cara memperbaiki masalah.

Ingatlah bahwa Anda masih menganalisis tugas yang diberikan kepada Anda. Saya akan merekomendasikan menulis ini entah bagaimana caranya. Saya pribadi merekamnya di aplikasi Catatan saya.

Tugas caching kami sangat sederhana dan mungkin tidak membutuhkan garis besar. Untuk contoh ini, kami akan mempertimbangkan masalah yang lebih kompleks.

Tugas kita selanjutnya adalah fitur baru: “Setiap pengguna harus diperlihatkan iklan yang ditargetkan untuk produk internal. Iklan ini harus disesuaikan dengan kebutuhan masing-masing berdasarkan data yang kami kumpulkan. "

Untuk menguraikan bagian-bagian utama, Anda perlu memikirkan dengan jelas tentang apa yang akan Anda lakukan di setiap bagian persyaratan.

  • Iklan kami saat ini perlu dipecah sedemikian rupa sehingga dapat berkorelasi dengan beberapa metrik pengguna tertentu.
  • Perlu ada cara bagi tim pemasaran kami untuk memetakan iklan baru ke sebagian atau bagian data pengguna (tanpa coding!)
  • Sistem perlu mengumpulkan metrik tentang pengguna yang relevan dengan iklan kami.
  • Terakhir, Anda perlu membuat beberapa jenis sistem yang menerima id pengguna dan mengeluarkan iklan.

Keindahan daftar seperti ini adalah dapat digunakan untuk memverifikasi dengan cepat dengan tim atau atasan Anda! Jadi dalam contoh ini, mungkin Anda telah menjalankannya oleh pemimpin tim Anda dan dia memutuskan bahwa perlu ada satu bagian penting lagi:

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

Karena bagaimanapun, kami tidak ingin mengganggu pengguna yang kami cintai! Dengan meluangkan waktu untuk memikirkan tugas kita hanya dalam beberapa menit, kita telah menghemat berjam-jam atau berhari-hari nanti dengan mengidentifikasi dan merencanakan tugas penting sebelum memulai dengan pengkodean.

Sebelum kita melanjutkan, saya ingin membahas kemungkinan kritik yang mungkin Anda miliki.

Anda mungkin berpikir: “Dalam bisnis yang tepat, ini adalah jenis pekerjaan yang harus dilakukan sebelum persyaratan mencapai pengembang”, dan saya sangat setuju dengan Anda!

Namun, sayangnya kita tidak hidup di dunia yang sempurna. Terkadang persyaratan tidak selalu diselesaikan sepenuhnya sebelum diterima oleh pengembang. Ini berarti kita semua harus melakukan yang terbaik untuk mengevaluasi persyaratan dengan benar sebelum pengembangan dimulai.

Definisikan masalah yang Anda coba selesaikan.

Jawab pertanyaan, "mengapa seseorang akan menggunakan ini?", Atau "Apa masalah dunia nyata atau nyata yang sedang saya coba perbaiki?"

Semoga jawabannya jelas. Untuk contoh cache kami, Anda dapat mengatakan, "pengguna akan selalu melihat update terbaru". Untuk contoh iklan, "pengguna akan melihat iklan yang relevan, bukan iklan yang tidak mereka pedulikan".

Jika jawabannya tidak jelas maka mungkin inilah saatnya untuk bertanya kepada seseorang mengapa Anda melakukan tugas ini! Mengajukan pertanyaan ini akan membuat Anda memiliki pemahaman yang lebih jelas tentang tugas yang ada, atau akan menuntun pada pemikiran ulang tentang apa yang diminta untuk Anda lakukan.

Semoga Anda melihat manfaat dari salah satu jawaban itu! Pemahaman yang lebih dalam tentang masalah dan tujuan akan memungkinkan Anda untuk membuat keputusan dalam implementasi yang benar-benar memenuhi tujuan bisnis. Mengidentifikasi solusi buruk atau masalah yang tidak masuk akal akan menghindari usaha yang sia-sia pada pekerjaan yang tidak akan pernah menyelesaikan masalah pada akhirnya.

Langkah kedua: Menafsirkan dan mengevaluasi persyaratan

Pada titik ini Anda harus memiliki pemahaman tentang apa yang akan Anda lakukan dan mengapa Anda melakukannya.

Langkah Anda selanjutnya adalah memahami detail dari apa yang Anda lakukan, bagaimana Anda diharapkan melakukannya, dan mengapa Anda melakukannya dengan cara itu.

Perjelas semua istilah penting yang terkait dengan tugas Anda.

Anda mungkin menemukan bahwa langkah ini lebih penting jika Anda adalah pengembang baru di tim atau jika Anda bekerja di perusahaan besar. Kedua situasi tersebut membuat Anda lebih mungkin menemukan istilah yang tidak dikenal dalam persyaratan Anda.

Istilah dapat berupa istilah bisnis, seperti nama produk, pelanggan, atau proses. Mereka juga bisa menjadi istilah pengembangan seperti nama alat, aplikasi, model, layanan, atau pustaka.

Anda harus yakin untuk memahami semua istilah penting, tanpa ketidakjelasan, sehingga Anda dapat yakin bahwa Anda melaksanakan tugas Anda dengan benar.

Anda mungkin memahami bahwa Anda perlu membuat cara untuk mengakses informasi pengguna yang dikumpulkan, tetapi apakah Anda memahami apa artinya menambahkannya ke "dao"?

Anda mungkin memahami bahwa Anda perlu memformat data iklan, tetapi apakah Anda memahami apa itu "MADF" (Menandai umpan data iklan)?

Saya juga tidak.

Inilah mengapa Anda harus mengidentifikasi dan mendefinisikan semua istilah penting. Anda memiliki peluang lebih besar untuk mengimplementasikan tugas secara tidak benar jika Anda salah menentukan definisi.

Identifikasi bagaimana tugas harus dilakukan

Pada titik ini Anda sekarang harus mulai melihat bagaimana tugas itu harus dilakukan. Langkah ini bisa sangat bervariasi tergantung di mana Anda bekerja dan tugas tertentu yang diberikan kepada Anda.

Pada beberapa tim, Anda tidak akan diberi tahu cara menerapkan persyaratan, Anda hanya akan diberi tahu fungsionalitas apa yang harus Anda dapatkan.

Orang lain akan merinci setiap langkah yang harus Anda ambil.

Kemungkinan besar pengalaman Anda berada di tengah-tengah.

Jika tim Anda belum memberikan instruksi, Anda tidak dapat berbuat banyak pada langkah ini. Jika Anda telah diberi instruksi, maka pada tahap ini Anda ingin mulai terbiasa dengan langkah-langkah yang perlu Anda ambil.

Langkah ini tampaknya cukup jelas, tetapi urutannya adalah sesuatu yang harus Anda perhatikan secara khusus.

Kecenderungan alami adalah menyelami semua detail tugas sebelum memastikan bahwa tujuan tugas dipahami.

Karena Anda telah meluangkan waktu untuk memahami tugas Anda terlebih dahulu, Anda sekarang akan memiliki tujuan yang lebih jelas dalam pikiran saat mengevaluasi langkah-langkah yang perlu Anda ambil.

Tentukan apakah masalah telah terpecahkan

Di sinilah tahap analisis dan tahap interpretasi bersatu. Dalam tahap analisis, Anda berfokus pada gambaran besar tujuan dan hasil, apa dan mengapa .

Pada langkah interpretasi, Anda fokus pada detail, caranya .

Alasannya disebut interpretasi dan evaluasi adalah sekarang Anda akan membandingkan bagaimana dengan apa dan mengapa. Anda menafsirkan detailnya dengan mempertimbangkan gambaran yang lebih besar. Anda akan mengevaluasi detailnya dan menentukan apakah masalah asli telah terpecahkan.

Tanyakan pada diri Anda: Apakah langkah-langkah yang diberikan kepada saya akan memberikan hasil yang diharapkan dari tugas Anda? Akankah hasil ini benar-benar menyelesaikan masalah aslinya?

Jika Anda merasa yakin bahwa semua masalah telah terpecahkan, dan semua detail masuk akal, Anda siap untuk memulai pekerjaan Anda! Jika tidak, Anda harus pindah ke tahap ketiga untuk menyelesaikan konflik apa pun.

Langkah ketiga: Berpikir kritis

Pada tahap ini Anda harus dapat dengan percaya diri menyatakan bahwa Anda memahami masalah dan solusinya. Langkah terakhir adalah memastikan bahwa Anda memiliki solusi yang tepat .

Untuk menciptakan produk terbaik, kita semua harus merasa memiliki tanggung jawab untuk angkat bicara ketika ada sesuatu yang tidak masuk akal.

Di sisi lain, kami tidak ingin berselisih begitu saja. Anda tidak boleh mengatakan sesuatu yang salah karena "rasanya salah" atau karena "Saya tidak suka". Anda harus memiliki alasan yang konkrit dan dipikirkan dengan matang.

Jadi mari kita buat beberapa aturan dasar tentang ketidaksepakatan.

Ketahui kapan harus tidak setuju

  • Jangan tidak setuju sampai Anda mengerti sepenuhnya.

Jangan pernah mengatakan bahwa ada sesuatu yang salah sampai Anda benar-benar yakin Anda memahami apa yang tidak Anda setujui.

Jika Anda tidak dapat dengan yakin menyatakan masalah dan solusi yang diinginkan, Anda tidak boleh tidak setuju. Jika Anda belum memverifikasi pemahaman Anda, Anda tidak boleh tidak setuju. Hanya ketika Anda tahu Anda memiliki pemahaman yang paling lengkap, barulah Anda mulai tidak setuju.

Jika ternyata Anda tidak memiliki semua informasi yang Anda butuhkan, mungkin inilah saatnya untuk berhenti dan meninjau kembali langkah-langkah sebelumnya sebelum Anda memberi tahu seseorang bahwa persyaratannya salah.

  • Jangan tidak setuju tentang hal-hal subjektif. Fokus pada masalah potensial yang sebenarnya.

“Saya tidak suka bagaimana ini dilakukan” adalah subjektif. "Ini akan menyebabkan masalah kinerja karena jumlah operasi yang terlibat." adalah alasan obyektif. Contoh lain dari alasan subjektif mungkin termasuk, "Ini bukan cara saya melakukannya di tempat lain" dan "Saya akan merancang solusi ini sedikit berbeda, tetapi hanya karena preferensi pribadi."

  • Siapkan penjelasan yang masuk akal tentang ketidaksepakatan Anda untuk disajikan.

Jika Anda tidak dapat menjelaskan mengapa ada sesuatu yang salah, dapatkah Anda benar-benar mengatakan bahwa Anda benar-benar tahu itu salah? Saya akan menyarankan untuk menuliskan alasan mengapa ada sesuatu yang salah dan apa yang dapat dilakukan untuk memperbaikinya.

Alternatifnya, jika Anda tidak punya solusi untuk memperbaikinya, nyatakan dengan jelas di awal bahwa Anda tidak tahu.

Berhati-hatilah saat Anda tidak setuju dengan orang lain. Sebagian besar waktu Anda harus dihabiskan untuk memahami dan mendengarkan sebelum Anda tidak setuju.

Jika Anda mengikuti semua langkah hingga saat ini, kemungkinan besar Anda memiliki pemahaman yang baik. Tetapi berhati-hatilah untuk tetap berpikiran terbuka bahwa Anda mungkin melewatkan sesuatu!

Saya suka memulai percakapan dengan mengatakan, "Saya tidak setuju dengan Anda, saya hanya tidak mengerti." Nanti muncul ketidaksepakatan jika perlu, tapi mudah-mudahan tidak pernah sebelum memahami.

Ketahui cara untuk tidak setuju

Untuk memastikan bahwa kami tidak setuju secara obyektif, berikut beberapa langkah yang akan membantu Anda menentukan apakah ketidaksetujuan Anda valid.

Ketidaksepakatan objektif melakukan satu atau beberapa hal berikut:

  • Tunjukkan bahwa solusinya kurang informasi.
  • Tunjukkan bahwa solusinya salah informasi.
  • Tunjukkan bahwa masalah atau solusinya tidak logis.
  • Tunjukkan bahwa solusinya tidak lengkap.

Menjadi kurang informasi bukanlah penghinaan, tetapi itu berarti bahwa informasi kurang ketika solusi dibuat. Mungkin mereka tidak mengetahui tentang sistem yang ada saat ini dan dapat melakukan tindakan yang diperlukan.

Menjadi salah informasi berarti solusi berasal dari informasi yang salah.

Dalam hal ini mereka mungkin berpikir sistem yang ada melakukan sesuatu yang sebenarnya tidak dilakukannya. Misalnya, mungkin tim SEO (pengoptimalan mesin telusur) meminta Anda agar Google mengindeks laman masuk di aplikasi Anda. Google tidak bisa melakukan itu. Mereka salah informasi tentang apa yang dilakukan crawler Google.

Masalah atau solusi yang tidak logis adalah masalah yang tidak masuk akal. Sebagai pengembang, saya pikir permintaan tidak logis umum yang mungkin Anda lihat adalah untuk satu fitur yang dapat merusak fitur lain. Dapat dianggap tidak masuk akal untuk melakukan itu karena itu akan menyakitkan, daripada membantu.

Solusi yang tidak lengkap mungkin sebenarnya dimaksudkan. Dalam pengembangan perangkat lunak kami sering mencoba memulai dengan membuat MVP (produk minimum yang layak). Ini berarti bahwa kami mungkin, pada awalnya, dengan sengaja mengabaikan fungsionalitas yang tidak mutlak diperlukan.

Alih-alih, Anda sebaiknya hanya menganggap solusi tidak lengkap jika tidak segera menyelesaikan masalah yang diminta untuk Anda perbaiki, atau jika langkah-langkah yang diberikan tidak cukup untuk membuat produk atau fitur yang berfungsi.

Ringkasan

Ingat, jangan terlalu memformalkan proses ini. Ini harus cepat dan mungkin terdiri dari menuliskan beberapa pemikiran di aplikasi Notes Anda. Kemudian, ini mungkin mengarah ke beberapa percakapan dengan rekan kerja Anda untuk mengklarifikasi apa yang seharusnya Anda lakukan. Itu saja!

Berikut adalah daftar langkah-langkah yang disederhanakan:

Langkah 1 - Analisis

  • Menggolongkan
  • Ringkasan
  • Garis besar
  • Tentukan masalahnya

Langkah 2 - Menafsirkan dan Mengevaluasi

  • Memperjelas istilah
  • Identifikasi tugas
  • Tentukan apakah masalahnya akan terpecahkan

Langkah 3 - Berpikir Kritis

  • Ketahui kapan harus tidak setuju
  • Ketahui cara untuk tidak setuju

Hai, saya Justin Fuller. Saya sangat senang Anda membaca posting saya! Saya perlu memberi tahu Anda bahwa semua yang saya tulis di sini adalah pendapat saya sendiri dan tidak dimaksudkan untuk mewakili majikan saya dengan cara apa pun . Semua sampel kode adalah milik saya, dan sama sekali tidak terkait dengan kode Bank Of America.

Saya juga ingin mendengar dari Anda, jangan ragu untuk terhubung dengan saya di LinkedIn, Github, atau Medium. Sekali lagi terima kasih telah membaca!