🦁 🔎 🕐 Saran buruk untuk pengembang: apa yang harus dilakukan untuk “tolong” manajemen 👨🏼‍🤝‍👨🏻 🚙 👩🏼‍🤝‍👨🏿

Seperti yang dijanjikan dalam artikel sebelumnya , kami mengubah situasi ke arah yang berlawanan. Saya kebetulan bukan hanya pengembang, tetapi juga pemimpin di berbagai tingkatan. Saya telah menyebutkan bahwa belakangan ini saya beruntung untuk tim dan kolega. Tapi sepanjang waktu semuanya terjadi.

(Grigory Oster)

Mari kita bicara tentang pengembang mana yang diimpikan oleh manajemen. Kali ini saya akan bertindak sebagai manajer abstrak ...

Pada awal setiap proyek ...

Tahukah Anda bahwa keterampilan tertinggi seorang manajer adalah membuat keputusan dengan informasi awal yang minimal. Jangan menghentikan kami, para pemimpin, dari melatih keterampilan ini. Ikuti taktik ini:

Beri nama kurma yang berkabut, tetapi jangan membicarakannya sama sekali.
Ketika kami bertanya apakah perbaikan yang diusulkan tidak akan merusak modul yang ada, diam, dalam keadaan darurat, buat ekspresi wajah yang misterius!
Berbicara tentang masalah proyek yang akan datang, jangan pernah menawarkan solusi Anda, ingat, kami membutuhkan pertanyaan orang, bukan solusi orang.
— , , ? 48- , 10 , .
— , .

Jika pada tahap pengaturan tugas Anda diterima klien untuk menanyakan pertanyaan klarifikasi, belajar dari serangan DDoS - berikan semua yang terbaik. Klien mengharapkan dari Anda setidaknya 50 pesan dengan pertanyaan, lebih disukai secara detail - dia akan menghargai kinerja Anda dalam genre epistolary. Anda tidak perlu melampirkan tangkapan layar atau video apa pun - biarkan mereka mendekripsi pesan Anda, meskipun hanya berisi "Halo!" dan panjang "mengetik ...".

Ingat: klien dan pengguna akhir adalah orang yang berbeda. Jangan pernah berkomunikasi dengan pengguna akhir dan jangan mencoba membayangkannya! Jika Bibi Masha di kasir akan melihat 25 baris teks pada monitor, letakkan dengan tenang tanpa melihat ukuran layar. Biarkan kaca pembesar ambil jika dia tidak suka.

Jangan pernah memberi tahu kami tugas spesifik apa yang akan diselesaikan dalam proyek. Bicara hanya tentang metode solusi. Dan itu diinginkan dalam semua detail - bagaimana lagi CTO akan tidur nyenyak malam ini?

Dalam cerita Anda, sama sekali tidak menyebutkan uang, waktu, atau metrik lain yang dipahami orang lain. Lagipula, bahkan sekretaris direktur dapat menerjemahkan cerita tentang struktur abstrak yang digunakan dalam skenario pengguna dan jumlah pasti keuntungan yang kita dapatkan. Jadi ketika mengevaluasi tugas, gunakan sistem kuantitas yang paling abstrak. Ingat, 1 boa constrictor adalah 38 beo!

Memanen kejutan sebanyak mungkin. Biarkan selain waktu untuk menyelesaikan masalah, itu juga akan memerlukan langganan atau alat berbayar, yang kita tidak akan tahu sampai saat terakhir. Kami menyukai jebakan dan akan dengan senang hati mencari jalan keluar dari jalan buntu sebelum rilis. Klien saya dan saya senang meningkatkan anggaran yang dialokasikan setiap minggu, terus-menerus mengoordinasinya melalui semua contoh. Dorong Ivan Tsarevich melalui iterasi baru dari awal kisah setelah setiap pembaruan informasi tentang di mana kematian Koshcheev disimpan.

Kode sempurna ...

Cobalah untuk menulis hanya kode yang sempurna untuk kode yang sempurna. Tidak perlu melakukan ini pertama kali. Jika terburu-buru, tulis dengan cepat, ulangi dan ulangi lagi. Ingat: pengulangan adalah ibu belajar. Jika kode telah ditulis ulang tiga kali dan setidaknya sedikit berbeda dari yang ideal, segera mulai refactoring sebagai bagian dari tugas kecil yang tidak berlaku untuk ini. Lebih baik lagi, transfer kode Anda ke pustaka atau kerangka kerja lain. Biarkan kode menjadi modis dan awet muda. Yang utama adalah bahwa dalam semua kasus, semua proses ini tidak dapat dirumuskan sebagai tugas yang terpisah. Dan kemudian tiba-tiba kita menebak bahwa ada sesuatu yang tidak ideal pada proyek itu? Hal-hal seperti ini sebaiknya dilakukan sesaat sebelum rilis. Pada saat ini, seluruh tim bekerja lebih cepat!

Berbicara tentang refactoring. Ini akan bekerja lebih efisien jika Anda secara bersamaan mengubah mekanisme dalam kode - agar tidak naik ke sana dua kali. Ingat, proses tersebut harus memengaruhi komponen sebanyak mungkin. Mengapa menghabiskan waktu memetik dalam modul individual? Hanya dengan cara ini Anda akan berakhir tampak seperti pahlawan yang menyelamatkan semua orang! Pengembang lain akan dengan senang hati menemukan kejutan dari mekanisme baru ketika mereka menembak mereka di kaki.

Kode yang sempurna harus diformat dengan benar. Cobalah untuk membuat file dengan ukuran maksimum, menempati banyak layar dan memuat beberapa komponen sekaligus. Mengikuti gaya desain ini, Anda dapat mengatasi konflik penggabungan secara heroik dan untuk waktu yang lama setuju dengan kolega yang pengeditannya lebih penting. Kode harus menyerupai mie terpanjang, tidak perlu membuang waktu untuk membuat file kecil yang tidak penting. Demi satu fungsi, buatlah nama file - apa yang bisa lebih menyakitkan?

Kode sempurna yang Anda buat tidak perlu ditutup dengan tes. Anda hanya dapat berbicara tentang perlunya membawa cakupan ke 100%, tetapi pada kenyataannya 10% sudah cukup. Untuk mengikuti Anda, tambahkan beberapa tes yang sebenarnya tidak memeriksa apa pun, maka mereka tidak harus diperbarui.

Jika tiba-tiba ternyata solusi cepat yang ditulis tidak berfungsi atau tidak berfungsi seperti yang diharapkan, silakan menyalahkan arsitek sistem, API, administrator server, dll untuk semuanya. Jelas bahwa kode ideal Anda tidak bisa tidak berfungsi. Ingat hal utama: kami, seperti Anda, tahu bahwa seorang programmer ideal hanya dapat bekerja dalam ruang hampa dalam kondisi ideal. Dan jika Anda terganggu, jangan memberikan informasi tepat waktu, menulis TK yang tidak dapat dipahami, maka Anda umumnya tidak dapat bertanggung jawab atas kenyataan bahwa modul yang diterapkan tidak memenuhi tugas bisnis. Benar, bisnis adalah tanggung jawab kita. Dianjurkan untuk menjaga semua nama faktor bersalah sampai batas waktu, mereka akan diperlukan nanti, sekarang jangan mengalihkan perhatian para pemimpin.

Ketika kita berbicara tentang perlunya merilis MVP dengan cepat, jangan ragu untuk mengabaikan upaya kita untuk mempercepat proyek sehingga merugikan kualitas dan kecepatan. Meskipun demikian, mereka tahu bahwa dengan ide yang bagus, Anda dapat memulai di pasar kapan saja. Waktu tidak memainkan peran apa pun. Biarkan para pesaing buang air besar, dan ketika Anda menulis kode yang sempurna, MVP kami akan melambung dalam 5 tahun. Dan selama ini, investor akan dengan senang hati membayar untuk menciptakan karya besar dengan uang mereka.

Urutan dalam proyek ...

Tugas Anda adalah kepribadian Anda. Kekacauan kreatif akan menambah bobot bagi mata kita. Kemampuan untuk membangun kekacauan dan mempertahankannya dalam keadaan yang agak kacau sangat berharga sehingga kami bahkan mentransfer proyek dari tangan ke tangan untuk meningkatkan tingkat gangguan. Begitu kekacauan mencapai maksimum, kami akan memberi Anda hadiah dengan proyek baru!

Jika Anda memahami bahwa kekacauan penuh telah terjadi pada proyek, tetapi Anda belum dipindahkan, mulailah menggali utang teknis Anda dengan cakarnya, atau minta proyek lain sendiri. Mungkin kami tidak melacak situasinya.

Segala sesuatu yang terjadi di dalam tim harus melalui kita. Bahkan jika Anda memutuskan untuk keluar untuk merokok dengan tester, pastikan untuk setuju dengannya melalui manajer proyek, tetapi lebih baik untuk melibatkan CTO dalam hal ini. Kami merasa tidak perlu jika tidak ada yang mengeluh tentang kolega kami, tidak berbalik untuk menyelesaikan perselisihan dalam kelompok kerja atau memperkenalkan beberapa aturan kerja.

Pada masalah desain, disarankan bagi kita untuk menulis hanya di PM. Ini akan menyembunyikan semua jejak aktivitas kami dari manajemen yang lebih tinggi, dan pada saat yang sama akan memaksa kami untuk menceritakan kembali solusi yang dikerjakan kepada peserta lain dalam proses. Kami sangat menyukainya!

Penyelesaian masalah ...

Setelah Anda menyelesaikan masalah atau memperbaiki bug, jangan pernah periksa solusi Anda. Serukan “Hore” dan lari dari tempat kerja secepat dan sejauh mungkin! Jadi, Anda akan menyerahkan tugas dengan lebih cepat dan menemukan pelajaran bagi tim untuk paruh pertama sprint berikutnya - Anda akan memperbaiki tiang-tiang tugas yang baru saja disampaikan. Yang penting, Anda juga tidak menghalangi pekerjaan sesama penguji. Satu set bug yang disebabkan oleh kruk baru dalam solusi adalah hadiah terbaik pada Jumat malam! Periksa dalam kode Anda hanya satu kasus yang berhasil, Anda optimis.

Urutan tindakan yang benar saat memecahkan masalah:

baca TK, abaikan catatan,
merokok untuk melupakan detailnya,
cepat dan tanpa ragu menerapkan hanya fungsi dasar,
lewati tugas sama cepatnya
Dapatkan revisi dengan dekripsi jelas dari catatan TK yang belum dibaca,
jadi itu, perbaiki masalah dalam 3-4 iterations.

Tidak ada refactoring di belakang, tidak ada combing kode. Biarkan variabel disebut sebagai kaki kiri Anda inginkan pada saat wawasan, dan kode tetap buruk dibaca. Bukan untuk Anda memahaminya nanti! Nah, latih untuk mengambil kode Anda untuk ditinjau segera - Anda pria yang baik, tetapi sensitif.

Pada tahap ini, tidak mungkin untuk membuat bukti bahwa tugas telah selesai (atau kadang-kadang akan muncul dengan video untuk menulis pada proyek bagaimana modul dimulai ...). Mungkin penguji tidak akan melihat adanya perbedaan dengan TOR, atau tugas akan dikirim ke yang lain, sementara untuk saat ini Anda dapat bersantai dengan tugas baru.

Jika ada momen-momen ambigu dalam tugas tersebut, misalnya, tidak diketahui apakah bidang input harus hanya menerima huruf bahasa Inggris atau Rusia pada saat yang sama, jangan ragu untuk menjawab pertanyaan sendiri, sesuai dengan selera dan pengalaman hidup Anda. Karena tidak tertulis dalam pernyataan kerja, ini harus jelas bagi semua orang!

Dan jangan pernah menguji hipotesis apa pun pada sebagian kecil tugas, jika tidak rekan kerja Anda akan berpikir bahwa Anda ragu!

Jika Anda terburu-buru dengan tugas untuk rilis dan memahami bahwa beberapa fungsionalitas perlu diselesaikan nanti, Anda tidak perlu menghabiskan waktu untuk menetapkan tugas dalam sistem manajemen proyek. Lebih baik membuat catatan langsung di komentar pada kode dan tidak memberi tahu siapa pun tentangnya. Jadi akan lebih menarik untuk menangkap hutang teknis. Akan ada perasaan bahwa ada banyak dari mereka dan Anda masih sangat dibutuhkan dalam proyek ini.

Simpan tidak lebih dari setengah file di repositori proyek! Tidak heran begitu banyak lokasi penyimpanan yang berbeda telah ditemukan di dunia. Penting untuk menempatkan file yang tersisa secara merata di antara repositori pribadi karyawan dan, misalnya, dokumentasi (bahkan tidak harus untuk proyek saat ini). Jadi "pengetahuan rahasia" tentang proyek akan dibagi secara merata dalam tim dan semua orang tidak akan tergantikan. Dan kemudian beberapa pendatang baru di proyek akan datang dan mencari tahu dengan cepat di yang sudah diterapkan. Sesuatu yang tidak bisa Anda tolak di tempat mereka - semua orang akan langsung diganti dengan jones yang lebih murah.

Setiap proyek harus memiliki pengetahuan rahasia yang diwariskan dari mulut ke mulut. Hanya dengan cara ini Anda dapat mendesah gambar dan, meludah, mengatakan: "Oh, ini junes telah bekerja selama seminggu, tetapi mereka tidak tahu apa-apa tentang proyek ini. Mundur, lakukan sendiri! ”

Jika Anda berjanji untuk melakukan tugas apa pun dari Jira, sama sekali tidak wajib untuk menandainya. Kami adalah medium - kami akan menebak apa yang Anda lakukan sekarang, tetapi pada saat yang sama kami akan menebak keadaan proyek saat ini. Ngomong-ngomong, kami dapat melakukan ini dengan waktu yang dihabiskan - kami tidak perlu menulis apa pun di mana pun, kami akan mengetahui jumlah jam kerja dan menghitung gaji Anda.

Komunikasi pada proyek ...

Pernahkah Anda mendengar tentang omnichannel? Komunikasi tanpa membagi menjadi saluran yang berbeda adalah tren terbaru. Jadilah tren! Untuk pertanyaan apa pun, tulis PM ke beberapa kurir, itu lebih baik untuk pribadi, bukan pekerja - sehingga dia tahu bahwa Anda tidak berada di belakang tren terbaru dunia ini. Tetapi tim proyek di Slack dan utusan lainnya paling baik digunakan untuk mengirim gambar lucu dengan kucing dan percakapan pribadi.

Terlambat untuk rapat rutin 15-20 menit. Lebih baik lagi, bawa mikrofon era Soviet dan Wi-Fi dari tempat kerja. Biarkan semua orang mendengarkan suara serak Anda, itu seperti lukisan abstrak - semua orang mendengar apa yang ingin didengarnya. Dan di Daily, Anda dapat menanyakan semua pertanyaan yang Anda miliki tentang proyek tersebut. Jika tidak ada masalah desain yang cukup, tambahkan lebih banyak offtopic. Paling buruk, Anda selalu bisa menanyakan sesuatu yang abstrak. Contoh yang baik seperti itu paling mencerminkan mengapa Anda tidak suka menelepon dan mengapa Anda tidak hadir.

Nah, jangan lupa, setiap orang memiliki bluetooth berkecepatan tinggi di kepalanya. Karena itu, jika Anda sudah membayangkan semua yang ada di kepala Anda, maka cukup transfer gambar ini. Kata-kata hanya dapat menjelaskan detail kecil yang tidak terlihat dalam gambar. Biarkan mereka mencoba memahami Anda, ini pekerjaan mereka.

Ngomong-ngomong, ada baiknya terlambat ke kantor jika Anda bekerja di wilayah kami. Ini adalah satu-satunya cara untuk menciptakan kesan pentingnya Anda. Dan jangan pernah memperingatkan tentang terlambat. Ini akan menunjukkan bahwa Anda sedang terburu-buru, yaitu merusak citra Anda tentang seorang guru yang tenang.

Jika Anda meninggalkan tempat kerja, Anda tidak perlu repot dengan pengaturan status di Slack atau pesan instan lainnya. Siapa pun yang menulis dalam ketidakhadiran Anda (dan memulai pemberitahuan) akan memberikan alasan untuk kutukan yang panjang dan bijaksana bahwa Anda sedang terganggu dalam waktu pribadi Anda. Di mana lagi Anda akan menemukan alasan seperti itu? Dan biarkan manajer dan kolega belajar untuk mengumpulkan pertanyaan cepat mereka sebelum dimulainya hari kerja resmi Anda (akan ada sesuatu untuk didiskusikan pada hari itu).

Pertukaran pengalaman itu berlebihan. Oleh karena itu, jika Anda masih memposting tautan apa pun ke artikel atau kerangka kerja ke saluran Pendidikan di Slack, Anda tidak perlu membuat deskripsi apa pun untuk itu. Biarkan itu menjadi pencarian rekan kerja. Mereka menginginkan pengetahuan baru - biarkan mereka tegang dan mengerti apa yang Anda berikan kepada mereka. Dan tidak masalah bahwa ini mungkin bukan area mereka. Dan jangan pernah berbagi pengamatan proyek Anda, keputusan menarik, bug dan kesimpulan instruktif. Pengembang ke pengembang serigala. Anda harus bersaing, dan tidak menumbuhkan pengalaman tim bersama! Dan ya, saya hampir lupa! Jika Anda menemukan artikel yang panjang, maka jangan membacanya sendiri, cukup bagikan kepada kolega Anda, mungkin mereka akan tertarik.

Pekerjaan sesama pengembang dapat dan harus dikritik. Anda harus menemukan kesalahan pada setiap hal kecil. Hanya saja, jangan bingung kritik dan ulasan. Penting untuk mengkritik secara luas dan dengan selera (dan lebih disukai seabstrak mungkin, misalnya: "Kode Anda mengerikan"), tetapi lakukan tinjauan secepat mungkin - klik tanda centang hijau tanpa melihat kode dan tidak meninggalkan komentar. Dan kemudian beberapa alasan konstruktif untuk ketidakpuasan harus dirumuskan.

Transfer kepada kami semua tanggung jawab untuk motivasi dan pelatihan lanjutan Anda. Kami sudah beristirahat untuk Anda, bahkan foto helm dari berbagai resor. Biarkan kami juga memunculkan motivasi untuk Anda sendiri. Sudah jelas bahwa pada proyek semua tugas itu menarik dan hanya dari bahaya kita menemukan rutinitas untuk Anda. Dan kami sengaja mengatur penyelesaian, karena Anda bekerja lebih baik dalam mode ini. Namun, kami tidak mendaftarkan Anda dalam kursus baik dari bahaya. Anda mentransfer semua kebutuhan Anda kepada kami melalui bluetooth, yang tertanam di otak Anda, kami menerimanya, tetapi abaikan saja. Tidak perlu mengubahnya menjadi kata-kata, kita tetap merasakannya.

Menjelang akhir proyek ...

Ketika kami meminta Anda untuk menunjukkan proyek kepada pelanggan, jangan sekali-kali mempersiapkan demonstrasi terlebih dahulu. Jelas bagi semua orang: jika proyek dimulai pada laptop Anda, itu berarti 100% berfungsi dan akan dimulai di mana saja. Kita semua beruntung!

Jika, menurut hasil demonstrasi, pelanggan tidak bahagia, Anda akan merasakan konflik yang akan datang, Anda harus mengirim pelanggan ke neraka. Dia tidak mengerti apa-apa. Dan tidak perlu memberi tahu manajer. Omong-omong, konflik dengan klien adalah alasan terbaik untuk meminta kami lebih banyak uang. Kami dengan senang hati akan setuju!

Tanggal rilis adalah fiksi. Kami hanya senang menandai tanggal ini di kalender. Faktanya, manajer, terutama pada remote, benar-benar kekurangan komunikasi. Dan menunda tanggal rilis adalah cara terbaik untuk dengan cepat mengadakan 3-5 pertemuan yang orang tidak akan menolak untuk hadir.

Ketika situasi pada proyek memanas, saatnya untuk membubarkan rumor bahwa semuanya akan segera runtuh. Luangkan sebanyak mungkin kolega untuk asumsi Anda, sebarkan lebih banyak hal negatif. Jika desas-desus itu dibenarkan, distribusinya memotivasi kami untuk memperbaiki situasi dengan gelombang tongkat sihir. Dan jika tidak dibenarkan, kami senang Anda masih dalam kondisi yang baik.

Ngomong-ngomong, jika rumor tidak membantu, mulailah panik dengan paduan suara. Ini adalah solusi paling konstruktif. Pada titik ini, Anda dapat mulai membicarakan hal-hal buruk tentang perusahaan, tidak hanya di dalam, tetapi juga di luar (misalnya, saat wawancara). Ini pasti akan membantu menyamakan situasi keuangan dan menjadikan diri Anda rekan kerja yang kuat dalam diri rekan kerja Anda!

Menjelang akhir proyek, Anda dapat meninggalkannya dengan keras dan efektif, mengartikulasikan alasan untuk pergi sebagai gaji yang terlalu rendah, terlepas dari kenyataan bahwa Anda telah berada di proyek selama bertahun-tahun dan demi kita jangan menyentuh teknologi baru. Jangan ragu untuk pergi ke pesaing - mereka akan menghargainya. Pencarian favorit kami adalah mencari spesialis baru seminggu sebelum rilis. Ketika Anda pergi ke perusahaan lain, jangan lupakan kami.

Beri tahu semua orang tentang satu sisi masalahnya. Diamlah tentang "eksploitasi" Anda, beri tahu kami tentang manajer mana yang tidak adil. Jangan mencoba memahami kami, beri tahu orang luar. NDA datang dengan pengecut!

Semua perangkap harus dilaporkan hanya sebagai upaya terakhir - jika proyek tidak dapat dimasukkan ke dalam produksi. Ini adalah pembangunan tim terbaik ketika tim bersama-sama "memadamkan api" pada malam sebelum rilis penting atau sudah di produksi. Jangan biarkan diri Anda dan tim kesenangan ini!

Jika Anda masih mengalami rilis di tim dan ada yang salah, Anda dapat dengan aman menempatkan bug pada produksi di akhir antrian. Mereka harus memiliki prioritas yang sama dengan orang lain. Biarkan mereka mengantre!

Nah, dan ketahuilah bahwa pada malam setelah pengembang ditunjuk untuk posisi stasiun layanan, metamorfosis mendalam terjadi bersamanya. Dia lupa semua kebutuhan pengembang, menjadi picik, otoriter, bodoh dan tidak bisa diakses. Oleh karena itu, kami - manajer, manajer, dan stasiun layanan - sangat tidak memahami Anda, para pengembang.

Penulis artikel: Eugene Wetsel (imater)

PS Seperti terakhir kali , cerita saya hanya kebetulan kebetulan dengan kenyataan. Dan moralnya adalah ini: mari kita memperhitungkan semua sarkasme ini, membangun hubungan dalam tim.

PPS Kami menerbitkan artikel kami di beberapa situs Runet. Berlangganan ke halaman kami di VK, FB, Instagram atau saluran Telegram untuk mempelajari semua publikasi kami dan berita Maxilect lainnya.