Teknologi adalah Masa Depan, Tapi Bagaimana Cara Mempelajarinya? Berbicara dengan Pengembang adalah Awal yang Baik

Tampaknya pemasar yang ingin mempelajari True Digital (rahasia server, API, SDK, dan artefak perangkat lunak lainnya) tidak memiliki cara lain selain berteman dengan pengembang . Meskipun tidak ada jalan pintas di sini – Anda perlu membangun dan memelihara hubungan – saya telah mengumpulkan beberapa petunjuk tentang cara meletakkan dasar untuk menjalin ikatan dengan insinyur perangkat lunak.

Dan jika Anda berteman, keahlian teknologi Anda akan tumbuh sepuluh kali lipat sebelum Anda menyadarinya.

Habitat alami pengembang

Secara sepintas, para insinyur tampak seperti jenis yang spesifik. Jenis yang disinyalir perlu perlakuan khusus, bahkan ada yang mengatakan jenis pemarah. Saya sepenuh hati tidak setuju dengan klaim ini. Saya tidak memiliki gelar master dalam sosiologi atau psikologi, tetapi saya tahu satu atau dua hal tentang ini. Saya dulu seorang insinyur perangkat lunak dan saya juga pernah menjadi pemasar. Terlebih lagi, hari ini saya hidup dengan menjual platform perangkat lunak yang membantu pemasar dan pengembang mengubur kapak.

Jadi, apa yang telah saya pelajari tentang membuat interaksi pemasar-pengembang lebih mudah? Dari sudut pandang pemasar, ini tentang memahami habitat alami pengembang — wilayah yang belum dipetakan bagi orang-orang yang memulai karir mereka.

Itu sebabnya saya menyusun peta rutinitas dan keinginan pengembang dan saya harap ini akan membantu Anda menavigasinya, yang pada akhirnya mengarah pada hubungan yang berkembang.

Ini tidak semudah kedengarannya. Sebagai pengembang mengakui diri mereka memiliki reputasi untuk mengatakan "tidak", untuk memperdebatkan detail bertele-tele, dan berpikir kita tahu bagaimana melakukan pekerjaan semua orang lebih baik daripada yang mereka bisa. Tetapi jika Anda melakukannya dengan benar, pengembang akan menjadi sumber pengetahuan utama Anda — seperti yang dapat kita pelajari dari Kate, dalam kisahnya tentang seorang pemasar digital yang menjadi manajer produk TI.

Jadi, mari kita mulai dengan mengatasi salah satu hambatan paling populer dalam berteman dengan pengembang.

Mengapa pengembang sering marah-marah?

Akar penyebab reputasi pengembang yang pemarah membutuhkan penjelasan yang lebih panjang. Jika Anda ingin memahaminya secara rinci, Anda harus membaca formulir panjang ini oleh Nicholas (lihat saja berapa banyak pengembang yang setuju dengan klaimnya di bagian komentar). Jika Anda kekurangan waktu, saya akan mencoba merangkum fenomena ini dalam 8 poin:

1. Pengembang adalah penerjemah ide Anda menjadi kenyataan . Mereka membuatnya bekerja. Mereka membuatnya bekerja dengan cepat. Mereka membuatnya kuat dan dapat diandalkan untuk pengguna Anda. Insinyur perangkat lunak adalah minyak ekonomi digital.
2. Dan mereka dibayar dengan baik untuk ini, keterampilan unik yang menggabungkan kreativitas dan pemikiran logis.
3. Tapi mereka sering diperlakukan oleh departemen lain seperti pembangun reproduksi, bukan seperti pencipta.
4. Menyebut mereka pembangun tidak adil. Tetap dalam metafora industri konstruksi, pengembang sebenarnya adalah arsitek bukan pembangun. Tugas mereka bukanlah membangun gedung (atau gedung-gedung) secara fisik tetapi mengumpulkan persyaratan . Persyaratan berupa kode.
5. Sekarang, bayangkan fase desain dari sesuatu yang kompleks seperti Sydney Opera atau Spodek di Katowice tetapi dengan sedikit perbedaan — para pemangku kepentingan dapat mengubah hampir segalanya saat bangunan tersebut lama dibangun. Meski begitu, pengembang tetap bisa memastikan gedung tersebut bisa digunakan dan tidak roboh.
   
6. Tapi di mana pembangun yang sebenarnya? Mereka sepenuhnya otomatis . Pengembang telah cukup pintar untuk membuat alat seperti kompiler, server penyebaran berkelanjutan, atau server di cloud yang membuat proses konstruksi cepat dan lebih penting dapat diperkirakan.
7. Jika Anda pernah bertanya-tanya mengapa pengembang tidak dapat memperkirakan berapa lama fase pembangunan akan berlangsung, Anda sekarang melihat bahwa apa yang sebenarnya Anda tanyakan adalah fase arsitektur. Anda menanyakan berapa lama waktu yang dibutuhkan untuk menulis perangkat lunak seperti mengatakan kepada kontraktor bangunan berapa lama waktu yang dibutuhkan untuk merancang setiap detail blok kota termasuk mengumpulkan semua persyaratan.
8. Dan bagian bangunan yang sebenarnya mudah . Setelah Anda memiliki persyaratan yang ditulis, itu dapat diperkirakan dengan akurasi kedua.

Jadi, pengembangan perangkat lunak sebenarnya adalah penelitian yang disamarkan sebagai rekayasa

Anda tidak boleh melihat pengembang sebagai juru masak pesanan singkat industri. Seperti yang dikatakan Nicolas “ insinyur perangkat lunak tidak masuk ke pengkodean karena mereka ingin seseorang memberi tahu mereka apa yang harus dilakukan, mereka masuk ke dalamnya karena mereka menemukan bahwa mereka dapat membuat sesuatu yang berguna. Setiap insinyur perangkat lunak jatuh cinta dengan pengkodean karena dia membuat program kecil yang berguna sejak awal dan ketagihan. ”

Setelah Anda memahami ini dan mengubah pendekatan Anda terhadap pengembang, Anda sedang dalam perjalanan untuk disukai oleh mereka.

Tetapi bergaul dengan pengembang bukan hanya masalah pola pikir. Ada hal yang lebih praktis yang bisa Anda lakukan untuk mendapatkan teman developer sejati.

Dengarkan dan biarkan mereka mengirim

Pengetahuan bahwa pengembang memengaruhi kehidupan orang-orang adalah pendorong paling kuat bagi pengembang. Baik itu skrip internal yang membantu tim pemasaran mencapai tujuan mereka atau back-end lengkap yang melayani miliaran transaksi setiap hari, kode yang bekerja "di produksi" yang membuat pengembang datang ke kantor setiap hari.

Pengembang menyukai kerja keras . Mereka bisa duduk berjam-jam di depan keyboard memecahkan masalah orang — terutama jika waktu untuk tugas yang mereka perkirakan hampir habis (dan nak.. mereka meremehkan , tapi itu sesuatu untuk artikel terpisah).

Apa yang mereka tidak tahan adalah arahan perubahan-dengan-angin dan bukan pengiriman .

Pengembang tidak mengirim saat terganggu. Seperti yang dikatakan Nicholas, itu terjadi ketika:

• Permintaan datang terlambat selama pengembangan dan tidak ada cukup waktu untuk menyesuaikannya sebelum batas waktu.
• Permintaan tersebut membatalkan satu atau lebih asumsi yang dibuat di awal proses untuk membuat proyek bergerak.
• Permintaan tersebut merupakan kebalikan dari persyaratan sebelumnya .
• Permintaan sebaliknya meningkatkan jumlah pekerjaan yang harus diselesaikan sebelum batas waktu.

Dengan mengingat hal ini, inilah yang dapat Anda lakukan untuk membiarkan mereka mengirim dengan mulus:

• Pahami kendala engineering sejak dini.
• Lengkapi persyaratan Anda (dua yang pertama ini adalah sesuatu yang ingin kami ajarkan kepada Anda di sini di 200 OK).
• Bekerja sangat erat dengan seorang insinyur.
• Bantu mereka memahami seberapa akhir desain pada tahap tertentu — akui ketika Anda tidak yakin tentang sesuatu dan bahwa Anda ingin menguji sesuatu.
• Bersikap baik — (tidak hanya dalam kasus ini) orang sering melupakannya sementara analisis yang dimulai oleh Google menemukan bahwa ini adalah kunci kerja tim yang baik.

Secara keseluruhan, programmer tidak menjadi pemarah tanpa alasan. Bukan karena mereka membenci kerja keras atau jam kerja yang panjang; mereka benci ketika itu tidak membuahkan hasil (dan saya tidak berbicara tentang uang di sini). Jadi ketika Anda membiarkan mereka melakukan pekerjaan mereka, mereka menjadi kurang pemarah dan menjadi lebih membantu.