Selamat Hari Programmer! Cintai pengembang Anda

Hari ini adalah hari programmer, hari ke 256 dalam setahun. Dan kami memutuskan untuk menulis posting bukan untuk sesama pengembang kami, tetapi untuk mereka yang berada di sebelah mereka dan bersama kami. Bagi mereka yang membuat kita kepanasan, itu membuat kita merebus otak kita, mengeluarkan uap dan berbicara dengan gugup tentang esensi, antarmuka, dan alasan tenggat waktu yang rusak. Untuk Anda, manajer terkasih, pengusaha, analis, manajer tanpa latar belakang IT dan teman kantor lainnya.

Jika Anda membaca Habr, kemungkinan besar Anda harus berkomunikasi dengan programmer, minta mereka untuk menyelesaikan frontend atau backend situs, mengubah kode analitik, menggantung fragmen kode selanjutnya di header situs, melakukan perbaikan pada perangkat lunak klien, dan banyak lagi. Lantas bagaimana menemukan bahasa yang sama dengan pengembang, agar tidak bertengkar? Kami tahu sesuatu tentang ini.


Jadi, langsung dari daftar.

Nyatakan dengan jelas persyaratan Anda. Selalu: tidak masalah apakah Anda meminta untuk membuat pilihan kecil dari database atau menyiapkan proyek perangkat lunak yang serius untuk klien. Tidak ada deskripsi tugas dalam bentuk "Buatkan saya kartu acara sebagai profil VKontakte" (ada banyak programmer yang bekerja di VKontakte, pekerjakan jumlah yang sama dan lakukan itu), "Yah, Anda melakukan segalanya, dan saya akan memilih" (membuat beberapa opsi untuk program itu mahal, Anda CEO setuju?), “Ayo buat bola seperti itu” (ini adalah pita dan perpustakaan khusus diperlukan untuk implementasinya). Pertama-tama, Anda harus memahami apa yang ingin Anda terima, dan itulah yang perlu disiarkan oleh programmer. Merumuskan persyaratan dalam bahasa Rusia, tanpa kantor dan pernyataan teknis semu - dan ya, lebih disukai secara tertulis.

Berbicara tentang menulis. Ini adalah penemuan terbesar dalam sejarah umat manusia, saat ini dioptimalkan oleh komputer. Jangan ragu menggunakan kertas dalam percakapan dengan pengembang:

• buat sketsa dan prototipe dari apa yang ingin Anda lihat (jika kita berbicara tentang suatu program atau antarmuka terpisah) - hari ini ada banyak alat untuk ini
  
• gunakan peta pikiran untuk merencanakan pekerjaan dan membuat rencana proyek
  
• menggambarkan fungsi yang diinginkan sesederhana dan serinci mungkin
  
• membuat kerangka acuan (TOR).
  

Jika ini tampak seperti ilmu yang rumit bagi Anda, cari tahu apa yang dilakukan oleh seorang analis sistem dan apa yang ia gunakan dalam pekerjaannya - banyak yang bisa digunakan.

Anda tidak perlu menggunakan diagram UML, diagram alur, dan kodesemu jika Anda tidak memilikinya. Dalam perjalanan ada lebih dari satu manajer yang terpesona oleh diagram UML dan menggambarkan semua yang dia butuhkan: dari rencana pertemuan hingga deskripsi kampanye pemasaran. Memang, alat itu tampak logis dan nyaman, namun - kejutan - UML dibuat untuk merancang arsitektur perangkat lunak, dan setiap penunjukan tidak hanya panah atau lingkaran, tetapi komponen yang sangat bermakna. Selain itu, programmer Anda mungkin tidak tahu UML dan baginya itu akan menjadi blok yang sama sekali tidak berarti.

Cerita yang sama dengan diagram blok di mana berbagai bentuk blok ada bukan untuk kecantikan, tetapi dengan pseudo-code. Tidak perlu menulis dalam gaya: " JIKA bulan = April, MAKA bidang data plat 1 bidang 2 bidang 3 ". Ini hanya omong kosong yang tidak dapat dibaca yang tidak akan menaklukkan layanan TI, tetapi pada tawa terbaik.

Jawab pertanyaan tepat waktu. Semua orang tahu bahwa pemrogram adalah pemalas, mereka duduk dan melihat kode mereka, mereka tidak akan pernah mencapai manajer dengan seratus tugas. Ok Tapi tetap saja, ketika Anda melakukan proyek, Anda bertanggung jawab untuk itu, dan Anda menyerahkan tugas kepada programmer, memiliki hati nurani untuk menjawab pertanyaan pada waktunya. Tidak perlu menghindari panggilan dan obrolan, tandai email sebagai penting dan letakkan di folder terpisah. Programmer menghabiskan waktu kerja untuk berinteraksi dengan Anda, ia mungkin memiliki yang sederhana karena pertanyaan yang belum terjawab - dan ini adalah kesalahan Anda. Harap tetap berhubungan selama jam kerja untuk masalah yang Anda ajukan di depan sesama pengembang. Omong-omong, ini juga berlaku untuk pelanggan pihak ketiga.

Namun - jika Anda diminta untuk melihat apa yang terjadi, mengevaluasi prototipe atau menguji fungsi apakah memenuhi persyaratan Anda, jangan pergi ke sepuluh karyawan tetangga dan jangan melakukannya bersama-sama. Jadi, Anda secara signifikan meningkatkan waktu hingga selesainya versi final.



Menuju "Sopan santun mereka." Bandingkan pertanyaan serupa dalam bahasa Rusia dan Inggris. Bekerja, cinta, uang - semuanya seperti orang lain. Tetapi yang paling penting, bagaimana mereka melihat pengguna?

Jangan salahkan pengembang untuk semua masalah. "Layanan IT telah bekerja pada kode begitu lama", "Orang-orang TI kehilangan tenggat waktu sesuatu", "Sesuatu programmer telah menggali ke dalam TK begitu lama" - apakah itu familiar? Mudah untuk menyalahkan masalah pada orang yang berinteraksi dengan teknologi - yah, ada sesuatu yang salah di sana. Tidak, simpan catatan waktu yang ketat, catat fakta transfer tugas (Anda dapat melakukan ini, misalnya, dalam CRM atau pada bagan Gantt), biarkan semua orang hanya bertanggung jawab atas pekerjaan mereka.

Ekstrim lain - dalam kasus ketidakpuasan pelanggan, taburkan abu di kepala Anda dan berteriak: “Apa yang kamu lakukan! Mencari kritik dan terjemahkan pada Anda! Kami kehilangan uang dan reputasi! Segera! " Panik mudah ditangkap oleh kolega dan manajemen, saraf programmer berada pada batasnya. Tetapi pada kenyataannya, ternyata port klien telah jatuh atau kecepatan koneksi telah turun. Belajarlah untuk tidak menyalahkan tetapi bertanya: “Vasya, Volga LLC menghadapi masalah: tidak ada koneksi ke database. Tidak bisakah Anda memberi tahu saya apa yang bisa, di mana untuk menggali? " Rasakan bedanya?

Jangan menarik ide-ide dari seluruh dunia ke dalam konsep kerja. Google menambahkan filter ke pencarian, Yandex menyalakan Alice, Habr meluncurkan versi mobile baru, Salesforce menyalakan kecerdasan buatan, RegionSoft merilis CRM v.7 dan sekarang Anda bergegas menyusuri koridor untuk menawarkan untuk memperkenalkan teknologi ini ke dalam proyek perusahaan Anda, karena itulah yang mereka lakukan Raksasa IT. Namun, setiap perubahan harus diperkenalkan dalam hal kelayakan, relevansi, dan pengembalian. Dan jika perbaikan tidak menguntungkan pengguna akhir dan tidak menghasilkan keuntungan, implementasi mereka akan menjadi beban tambahan bagi pengembang. Persiapkan pembenaran, perhitungan, hitung biaya pengenalan fitur dan baru setelah itu membuat keputusan untuk mulai membahas masalah tersebut.

Jangan mengevaluasi kompleksitas programmer jika Anda bukan pemimpin tim. "Kami membutuhkan modul untuk menghitung volume kotak untuk mengirim parsel, ini urusan setengah hari, mari kita duduk!" - Pemasar Optimis Masha memanggil dan bergegas untuk minum teh sebelum pertemuan ketiga. Pada saat yang sama, Masha sendiri tidak tahu dari mana ia mendapat tingkat waktu seperti itu. Programmer memiliki tugas-tugas kerja, masalah saat ini, pelacak bug menggantung di atasnya dan backlog berkedip di samping, jadi di antara mereka itulah dia akan mencari waktu untuk menyelesaikan masalah. Dan bukan fakta bahwa masalah yang diselesaikan dalam 15 baris kode dapat diselesaikan selama rangkaian baris ini - waktu mengambil pilihan algoritme, menemukan solusi, memilih pustaka, kode debug, autotest, dll.

Yang terbaik dari semuanya, jika Anda memiliki peraturan perusahaan yang mengatur prosedur untuk mengajukan penyelesaian / pembongkaran / penempatan luar biasa, dll. Dalam hal ini, semua orang akan merasa percaya diri dan mengetahui perkiraan tenggat waktu untuk menyelesaikan masalah. Dan ya, tetapkan ketentuan nyata.



Jangan mencoba mempengaruhi tumpukan teknologi pengembangan jika Anda sendiri tidak mengembangkan apa pun. Situasinya dangkal: manajer pergi ke konferensi IT intergalaksi berikutnya, mendengarkan laporan dan otaknya tiba-tiba terputus bahwa ada suara di mana-mana di sekitar Go, dan kemudian ia disajikan dengan Gopher yang mewah. Dan sekarang dia berdiri di depan departemen TI, membelai gopher yang ditemukan dan berbicara tentang keuntungan yang telah Go dengar dan bagaimana menggunakannya di perusahaan kami yang berdarah.

Jawabannya sederhana. Pemrogram adalah orang yang sangat ingin tahu dan belajar tentang bahasa pemrograman, DBMS, OS baru, perpustakaan dan kerangka kerja jauh lebih awal daripada peserta konferensi lainnya menulis laporan tentang mereka. Pada saat yang sama, mereka tidak hanya ingin tahu, tetapi mencari untuk melihat apakah teknologi ini atau itu dapat cocok untuk memfasilitasi pekerjaan dan memperkuat kepercayaan pada produk (karena programmer juga sangat malas dalam arti kata yang baik). Oleh karena itu, terserah kepada mereka untuk memutuskan apa yang akan diseret ke tumpukan pengembangan, dan apa yang harus dibiarkan beristirahat sampai waktu yang lebih baik dan tugas baru. Dan Anda tidak mungkin melampaui mereka dalam hal ini.

Berhati-hatilah dalam menulis , itu tidak menyampaikan intonasi (namun, ini berlaku untuk semua kolega dan orang lain pada umumnya). Jika Anda menulis "Dan lakukan pembongkaran dalam satu jam))))))))))))))) atau " Saya akan menerapkannya dengan lebih baik, menurut saya itu melambat))))))))))))))))) " , Kurung tidak akan menyelamatkan Anda - pesan utama akan dibaca. Jelaskan pertanyaan pekerjaan dengan jelas dan tidak emosional. Jika Anda menyukai pekerjaan itu, Anda bisa memberikan cokelat :-)



Setelah permintaan "mengapa programmer Rusia begitu baik" mereka pergi dengan bangga

Jangan memaksakan metode komunikasi Anda. Hari ini, masing-masing dari kita yang menggunakan PC dan telepon seluler memiliki selusin alat komunikasi: Telegram, Skype, SMS, telepon, Viber, mail, Slack, Jira ... Dan masing-masing dari mereka memiliki lingkaran tugas dan pelanggan masing-masing. Oleh karena itu, jika pemrogram meminta akhir pekan untuk menulis hanya di kereta, menetapkan tugas hanya di Jira, dan menelepon hanya di Skype, ia memiliki alasan yang bagus untuk ini: ia tahu pasti bahwa ia tidak akan lupa untuk melakukan pekerjaan yang terkait dengan kontak ini. Tetapi SMS Anda "Mulai hari Senin laporan pembayaran untuk paruh pertama tahun ini" akan hilang di utas diskusi kampanye Minggu. Oleh karena itu, lebih baik menulis tentang ini dalam program kerja dan tidak menganggap diri Anda luar biasa dan paling efisien dalam berkomunikasi dan menetapkan tugas. Percayalah, ini tidak sulit.

Jika Anda bekerja dengan programmer dan membuat program untuk pelanggan eksternal, berikan rilis. Artinya, pada saat program siap dan diluncurkan dalam produksi, Anda harus memiliki semua materi promosi, visual, presentasi, perjanjian, dan sebagainya. Ini menghormati pekerjaan pengembang - karena di perusahaan seperti itu ia melakukan fungsi unit produksi. Jika Anda mengkustomisasi pemrogram, mereka melakukan segalanya tepat waktu, dan rilis ditunda selama tiga bulan, ini adalah pendemotivasi yang hebat dan mendevaluasi tim seperti itu. Jarang ada seorang programmer yang tidak peduli apa yang akan terjadi pada programnya di masa depan dan tidak tertarik pada bagaimana itu berperilaku di pasar dan dengan pelanggan.





Yandex Domestik memiliki pandangan yang sama sekali berbeda: bahkan Ada Lovelace diperingkat di antara programmer 1C, dan di lowongan teratas adalah Assembler dan Delphi (jika ada, kami mencari di browser anonim). Tapi yang utama adalah ada 256 hari - dan hari ini :-)

Belajarlah dari programmer dan pelajari terminologi. Seseorang yang tahu bagaimana memprogram, berpikir secara sistematis dan logis, tahu bagaimana memprioritaskan, melihat esensi hal-hal dan mengetahui subjek dengan sempurna (tidak, yah, untuk menghormati liburan, Anda bisa melebih-lebihkan sedikit!). Dia memiliki banyak hal untuk dipelajari - terutama karena Anda bekerja di bidang IT, Anda memerlukan perintah yang layak dari perangkat konseptual dan kosa kata profesional. Berkomunikasi di tempat kerja, klarifikasi masalah kontroversial, tanyakan, ingat istilah dan definisi mereka - ini pasti tidak akan mengganggu karir Anda. Tetapi pemahaman dengan seorang programmer pasti akan lebih baik.

Setidaknya Anda tidak akan menulis di portal perusahaan "Happy Programmer's Day", tetapi Anda dapat menulis sesuatu seperti ini:

"Teman-teman! Selamat Hari Programmer! Sangat menyenangkan bahwa ada Anda yang melakukan kode tepat waktu, refactor dan membuat perangkat lunak kami lebih cepat dan lebih intuitif, mengumpulkan build tepat waktu dan menjalankannya dalam produksi. Saya berharap Anda berhasil, perpustakaan yang andal, kerangka kerja yang nyaman dan kami, pengguna yang memadai. Anda membuat dunia masa kini sedikit masa depan. Dan kami mencintaimu! "

Nah, sudahkah Anda mempelajari pelajaran kecil kami? Sekarang, selamat untuk pengembang Anda.

Selamat berlibur, teman-teman! Studio Pengembang Tim RegionSoft , pengembang CRM yang kuat dan perangkat lunak lain untuk bisnis, yang tahu banyak tentang komunikasi antara pengguna dan pemrogram

---

Saluran Telegram Kami

Kami menyapa saluran Nizhny Novgorod utama tentang acara IT dan situs web mereka it52.info . Pergi ke acara, jadilah subjek.