🌑 👧🏼 🍩 Saran buruk untuk majikan. Cara "benar" berinteraksi dengan pengembang ☂️ 🐭 👨🏿‍🚀

Saya beruntung akhir-akhir ini - saya bekerja untuk perusahaan di mana pengembang sangat dihormati. Tapi ini tidak selalu terjadi, saya harus berurusan dengan berbagai pendekatan interaksi. Saya ingin mengatakan bahwa "moral liar" adalah sesuatu dari masa lalu, tetapi kisah-kisah rekan-rekan saya tentang tempat kerja mereka sebelumnya dan pengamatan pasar saya membantah pernyataan ini.

Baiklah, mari kita bicara tentang cara "benar" berinteraksi dengan pengembang, misalnya, secara pribadi dengan saya ...

(Jika Anda pergi ke sungai bersama seluruh keluarga Anda,
jangan berhenti ayah dan ibu dari berjemur di pantai.
Jangan berteriak, beri istirahat pada orang dewasa.
Tanpa mengganggu siapa pun, cobalah tenggelam, - Grigory Oster) ...

Ketika Anda merencanakan jadwal saya ...

... ingat bahwa yang terbaik dari semuanya saya bekerja dalam mode darurat, tidur 3 jam setelah sesi pengkodean 40 jam kemarin. Pada saat inilah 2 monitor secara visual berubah menjadi 4, dan kode mulai menampilkan tarian penduduk asli Amerika dengan suara seragam rebana di kepala. Hanya dengan cara ini Anda akan menerima dari saya non-standar, bisa dikatakan, ide-ide brilian. Dalam keadaan darurat ini, kode mulai terlihat seperti mie panjang. Itu akan memiliki atribut file 'tulis saja' jika ada. Anda dapat membaca kode seperti itu hanya dengan terjun ke keadaan darurat yang sama dengan yang saya tulis.

Sayangnya, para pemimpin tim berusaha untuk meluangkan lebih banyak waktu ketika mengevaluasi proyek, dan ini mencegah pembentukan keadaan darurat. Oleh karena itu, cara terbaik adalah menghabiskan setengah dari waktu yang dinyatakan mengoordinasikan tanggal rilis dan mendiskusikan proyek "di atas meja" (diam-diam, tanpa meninggalkan jejak). Ingat, mendekode TK adalah hobi favorit saya, dan itu membuat saya terburu-buru.

Lebih dekat ke titik, saya sarankan untuk mengubah esensi tugas atau mentransfernya ke tim lain sama sekali - yang paling saya sukai adalah proyek yang tiba-tiba tiba yang tidak bisa ditangani oleh kontraktor sebelumnya, dan sekarang saya harus tepat waktu tidak peduli apa pun yang terjadi. Jadi, 5 hari terakhir sebelum rilis akan menjadi yang paling produktif!

Ngomong-ngomong, inilah satu "hack kehidupan" dari salah satu karya masa lalu Anda. Beberapa hari sebelum rilis, Anda dapat membuat aturan untuk terhubung dengan saya di Skype selama 18 jam sehari dan mendengarkan bunyi gemerincing kunci dan bergumam untuk memastikan bahwa saya belum tertidur dan menulis "kode", dan pelanggan berikutnya tidak akan menembak Anda.

Jika Anda tidak dapat memperketat tenggat waktu, maka setidaknya kurangi tim. Ingat: keadaan darurat dapat dilakukan dalam proyek apa pun, jika Anda dengan cepat dan diam-diam memecat setengah pengembang. Gagasan yang bahkan lebih menjanjikan adalah bahwa setelah memecat setengah, Anda dapat merekrut orang lain, tidak berpengalaman, dan semakin banyak semakin baik. Tapi saya juga bisa mengajar anak-anak dalam situasi darurat, sekaligus memperbaiki kode mereka dengan belahan bumi kedua.

Jangan lupa bahwa saya harus tetap dalam kondisi yang baik di semua tahap pekerjaan, termasuk selama perencanaan. Jika saya mengevaluasi tugas di empat jam kerja, jangan ragu untuk menghubungi pelanggan dua. Jelas bahwa saya telah menyediakan waktu untuk kemalasan.

Setelah menetapkan tugas, ingat bahwa saya perlu terganggu setidaknya setiap 5 menit sekali. Jika saya duduk di headphone, maka saya perlu meminta mereka untuk lepas landas. Lagipula, jika Anda tidak memeriksa apa yang saya lakukan, saya tidak akan bekerja atau saya akan merasa ditinggalkan dan kesepian! Saya juga dapat curiga bahwa Anda tidak melakukan apa-apa, karena Anda tidak khawatir dengan nasib proyek.

Cara termudah adalah dengan mendaftarkan saya untuk semua surat Jira, semua saluran publik Slack, dan pemberitahuan lain yang tersedia (tidak ada banding). Tolong beri saya daftar semua saluran komunikasi yang diperlukan. Dan jangan lupa bawa ponsel saudara saya, kalau tidak saya tidur nyenyak.

Karena Anda memiliki tugas untuk "melakukan ping" secara teratur ke seluruh tim, biasakan menulis sesuatu seperti @chanel atau pesan apa pun di Slacksemuasehingga semua orang menerima pemberitahuan terlepas dari pengaturan klien. Dan menuntut jawaban selambat-lambatnya 5 menit kemudian (siapa yang tidak menjawab, Anda dapat menelepon telepon)! Kalau tidak, bagaimana tim akan hidup tanpa melaporkan bahwa kucing sekretaris itu berulang tahun hari ini?

Omong-omong, Anda perlu bekerja dengan saluran secara komprehensif. Ada dua strategi optimal: tidak berbagi apa pun dalam arti, mendiskusikan semuanya dengan semua orang dalam satu jendela, atau menggunakan fakta bahwa program modern memungkinkan Anda membuat ribuan saluran, dan mencoba untuk menempatkan setiap masalah secara terpisah. Hal utama - jangan hapus maka saluran yang tidak digunakan. Dan kemudian tiba-tiba pelanggan mereka ingin merasa terlibat, tetapi secara sadar menikmati kesunyian?

Jika Anda tidak tahu cara memotivasi saya ...

... buat alasan untuk setiap bug yang ditemukan selama pengujian.

Ini jelas, jika saya berada di suatu tempat dekat kode, meskipun saya tidak naik ke dalamnya, maka saya memecahkannya! Jangan mencari-cari kesalahan git, di sana Anda dapat menemukan pembuat sebaris kode. Dan kemudian Anda akan menghilangkan kesenangan reposting di Instagram karya lain dengan pikiran gembira: "Ini bukan saya."

Tetapi hal utama di sini adalah tidak melangkah terlalu jauh. Jika Anda curiga saya benar-benar kacau, cobalah untuk tetap diam sebaliknya. Kalau tidak, bagaimana saya bisa merasakan kelemahan semua hal (termasuk kesia-siaan pekerjaan saya sendiri)?

Ya, dan lupakan mantra "semua kode proyek adalah umum", itu menyinggung penulis sejati dan melanggar hak kepemilikan pribadi.

Untuk meningkatkan produktivitas, Anda juga dapat membawa saya ke beberapa klien yang memalukan, sehingga dia akan mengungkapkan semua yang dia pikirkan di hadapan saya tentang rilis terbaru. Strata manajer dalam hal ini akan merusak perasaan kelincahan yang tidak akan mungkin terjadi tanpa pelecehan yang baik di pagi hari. Minta klien terlebih dahulu untuk mentransfer tagihan mereka kepada individu tersebut. Yang utama adalah memastikan bahwa ulasan pelanggan tidak positif, kalau tidak saya akan santai dan umumnya berhenti bekerja.

Jika klien menolak memberikan umpan balik kepada pengembang, sampaikan semua negativitas sendiri. Pada saat yang sama, diinginkan untuk sedikit memperindah. Ingat - motivasi dibentuk dari kata "mat". Dalam kasus ekstrem, Anda dapat memanggil penguji emosional yang hanya melihat bug dalam karyanya dan dengan senang hati memberi tahu perkembangan seberapa buruk aplikasi yang kami tulis. Dan kemudian (lihat di atas) saya akan santai.

Saya menulis kode sempurna untuk kode sempurna. Saya sama sekali tidak tertarik pada bagaimana kode ini kemudian digunakan dan apakah itu digunakan sama sekali. Tidak perlu mengalihkan perhatian saya dengan reaksi positif atau bahkan lebih negatif terhadap fungsi yang kita lakukan. "Saya menulis dan lupa" - slogan saya. Mengapa saya perlu terima kasih dari pengguna? Mungkin bahkan memberi mereka tanda tangan?

Bagikan pintasan ke semua karyawan. Biarkan Anda memiliki Petya, yang "selalu bekerja lambat", dan Vasya, yang "selalu memotong rumput". Dan harus ada Maxim yang melakukan "modul XXX" ini, dan hanya dia yang bisa membuat perubahan di sana. Jika tidak, bagaimana karyawan baru akan menavigasi tim?

Lebih sering mengingatkan Anda bahwa Petya lambat, memarahi Petya di depan umum, sehingga semua orang mengerti mengapa. Ingat: karyawan tidak berubah dan tidak berkembang - tidak masuk akal untuk memeriksa apakah Petya yang sama diperbaiki setelah satu tahun bekerja di perusahaan. Jika tiba-tiba Petya melakukan tugas dengan cepat, lebih baik pujilah dia tetet-à-tetet. Dan tiba-tiba rekan-rekan lupa bahwa Petya masih lambat? Nah, secara umum, dimarahi di depan umum, dan pujian di PM.

Temukan hewan peliharaan di tim dan pujilah martabatnya lebih banyak, bahkan jika dia tidak memenuhi bahkan setengah dari tugas yang diberikan kepadanya. Biarkan dia mendapatkan tugas yang paling menarik. "Tangan kanan" seperti itu harus ada di setiap bos. Tetapi bagaimana Anda bisa bertahan di posisi kepemimpinan tanpa dukungan?

Guncangan hebat - pembayaran tertunda. Jika uang tidak tiba tepat waktu, saya pasti akan ingat bahwa saya bekerja untuk uang itu, saya akan menimbun pikiran saya dan mulai bekerja lebih baik. Efeknya akan lebih besar jika Anda menyembunyikan berita tentang perusahaan dengan hati-hati. Biarkan semua orang di sekitar berpikir bahwa sesuatu sedang terjadi, tetapi tidak ada yang bisa mengerti apa sebenarnya. Dan dukung mereka yang, dengan bantuan imajinasi mereka, membuat situasi semakin buruk. Semakin banyak desas-desus yang mengerikan tentang masa depan proyek yang berjalan dalam tim, semakin tenang pengembangnya bekerja, yang memiliki hipotek selamanya dan seorang istri dengan anak-anak kecil di belakangnya.

Jika proyek berakhir, tetap diam tentang hal itu sampai yang terakhir. Tiba-tiba biayanya dan pelanggan memutuskan untuk mengulangi hal yang sama, menulis ulang pada kerangka kerja yang modis lagi?

Tetapi secara umum, motivasi adalah tantangan saya. Tugas Anda adalah secara mendasar tidak memperhatikan saya, atau menarik diri dari zona nyaman, sebagaimana disarankan oleh Internet. Bagaimana lagi yang akan saya kembangkan? Jika Anda melihat bahwa saya tidak suka mitaps dan pihak pemrograman, buat saya pergi ke mereka. Dan sebaliknya, begitu saya memiliki kecenderungan untuk hobi seperti itu, memuat dengan pekerjaan sehingga tidak ada waktu tersisa untuk pesta. Zona nyaman tidak akan pergi sendiri!

Jika Anda ingin memberi saya tugas ...

... merumuskan TK sesingkat mungkin. Ingat: singkatnya adalah saudara perempuan yang berbakat, karena saya bisa menebak semua detail pada tiga liter bubuk kopi yang tersisa dari rilis tanpa tidur terakhir. Kata-kata yang ideal: "Semuanya harus baik-baik saja!"

Jika pengantar datang dari analis yang terlalu bisa dimengerti, jangan ragu untuk memotong! Hanya teks, tanpa tangkapan layar. Bahkan lebih baik - video di Viber, di mana Anda, saat mengemudi, berbicara selama 20 menit tentang situasi di jalan, dan di menit terakhir dengan cepat hanya melaporkan keberadaan tugas.
Jika Anda tiba-tiba harus melampirkan tautan ke beberapa tata letak atau dokumentasi untuk tugas tersebut, cobalah menghubungkannya dengan proyek yang berbeda secara fundamental, paling buruk - dengan versi berbeda dari satu proyek. Kalau tidak, itu akan terlalu mudah. Dan pengembangan seperti apa tanpa pencarian di awal?

Dalam TK, dalam hal apapun tidak boleh ada informasi tentang versi yang tepat dari browser atau sistem operasi, tidak ada tautan ke dokumen di mana kesalahan terjadi.

Tidak ada yang lebih berharga daripada komunikasi manusia. Anda akan menghibur saya jika Anda mengirimnya ke perancang untuk mock-up, untuk detail tugas - kepada analis, untuk spesifikasi API - ke klien. Meskipun dia tidak ada di tim kami, dia juga bosan dan ingin bicara.

Ngomong-ngomong, lebih baik mempersiapkan langkah ini terlebih dahulu. Dalam kasus apapun jangan membahas rincian tugas di saluran umum, tetapi hal-hal baik apa yang akan saya pelajari terlalu banyak dan tidak akan langsung ke kolega dengan pertanyaan. Selain itu, setelah melihat komunikasi dari task manager di saluran umum, saya mungkin berpikir bahwa PM sibuk ... dan apakah ini mungkin? Selalu gunakan hanya pesan pribadi - sehingga fragmentasi pengetahuan tentang proyek lebih tinggi!

Untuk alasan yang sama, Anda tidak boleh secara mandiri memberi saya aliran tugas untuk pengembangan. Tugas harus diperoleh - temukan dari perancang, analis, atau penguji yang sama. Ngomong-ngomong, bagian dari tugas analis dan penguji yang sama ini masih bisa disalahkan pada saya. Sudah diterima secara umum bahwa itu adalah pengembang yang menulis dan mendukung pengujian otomatis UI! Tapi perkembangannya bisa dihilangkan dari saya. Saya suka mulai melakukan tugas, dan kemudian memberikannya kepada "belum selesai" seperti yang diarahkan oleh pihak berwenang!

Tugas apa pun untuk saya harus disertai dengan birokrasi yang maksimal. Bagaimana lagi saya yakin itu benar-benar penting?

Pelaporan pekerjaan yang dilakukan harus sedetail mungkin. Jika saya tidak perlu dicatat dalam beberapa sistem pelacakan waktu (tim dan perusahaan, misalnya), saya akan merasa bahwa tidak ada yang menghargai upaya saya. Hanya duplikasi informasi yang akan memastikan tingkat keamanan yang tepat! Diinginkan bahwa formulir pelaporan berbeda.

Perlu disepakati bahwa durasi tugas yang dilakukan per minggu tidak boleh kurang dari 40 jam. Pastikan untuk mempertimbangkan semuanya, bahkan istirahat 2 menit. Jika saat ini karyawan tidak menghentikan pelacak - tindakan disipliner!

Periksa laporan waktu setidaknya sekali seminggu, mengatur panggilan umum untuk menganalisis setiap baris. Dan akhirnya, hitung kecepatan rata-rata pembuat enkode - semua orang tahu bahwa durasi tugas berbanding lurus dengan jumlah baris kode yang ditulis!

Tetapkan kondisi untuk mencocokkan kecepatan ini sebagai KPI pengembang, sehingga gaji juga bergantung padanya. Dan kemudian percakapan sederhana yang tugasnya lebih lama dari yang diharapkan tidak memungkinkan Anda untuk merasakan pentingnya proses.

Berbicara tentang panggilan telepon dan demonstrasi ... harus ada sebanyak mungkin! Untuk setiap pertanyaan, kumpulkan seluruh tim! Dan selalu setidaknya sedikit, tetapi terlambat. Jujur, saya tidak tahu cara lain untuk menekankan kepentingan awal saya. Jangan mencoba memperingatkan orang yang ditambahkan ke panggilan, yang akan dibahas. Biarkan dia menunjukkan bagaimana dia tahu cara melompat dari satu tempat ke tempat penggalian lainnya. Biarkan mereka mendapatkan tautan ke topik apa pun di muka dan menyulapnya secara instan. Atau biarkan dia mencari mereka dalam kesunyian yang menyakitkan dalam pesan pribadi dengan sang desainer, sisanya akan menunggu. Sisanya umumnya dapat kode selama panggilan.

Selama pertemuan, diskusikan semua masalah yang muncul di benak Anda. Jika bahkan ketidakkonsistenan pribadi, yang biasanya diselesaikan secara tatap muka, diangkat untuk didiskusikan, hari itu akan lebih produktif. Jadi, misalnya, pada siang hari Anda dapat mengajukan semua pertanyaan tentang tugas saat ini dari setiap karyawan. Dengan demikian, dari 10 menit waktu harian dapat diregangkan menjadi 2 jam.

Dan untuk mendapatkan kesempatan mengadakan pertemuan tentang masalah yang sama lagi, tidak pernah, pada akhirnya, merumuskan keputusan apa pun (bagaimana jika harus dilaksanakan?). Risalah rapat? Untuk apa? Penyelidik memiliki protokol, dan kami “trendun” yang damai. Jika Anda masih mengabaikan dan seseorang merumuskan tindakan ini sebelum Anda, cobalah untuk mengabaikannya.

Jika Anda merencanakan rilis ...

... ingat bahwa waktu terbaik untuk menggunakan adalah Jumat malam. Semua sama, semua orang memiliki hari libur, jadi kami akan segera memperbaiki semua kesalahan pada produksi sebelum memulai sprint berikutnya.

Dan jangan lupa menyerahkan nomor telepon pribadi seluruh tim kepada pelanggan. Mereka yang memperkenalkan praktik kewajiban salah. Pada akhir pekan setelah rilis, seluruh tim akan menantikan panggilan pelanggan. Waktu terbaik untuk ngobrol adalah 23:59 pada hari Jumat, ketika saya mulai menderita karena pekerjaan selesai dan ada akhir pekan di depan. Beristirahat dengan keluarga adalah hal yang gratis, saya akan senang untuk memindahkannya.

Semua orang tahu bahwa perlu merilis solusi dalam produksi pada hari yang sama dengan rilis beberapa API penting yang terlibat dalam solusi ini. Bagian belakang harus bertemu dengan bagian depan yang lebih dekat dengan produksi, integrasi adalah kata yang tidak dapat dipahami. Dan jangan dengarkan mereka yang mengatakan bahwa pengembangan adalah hal tim. Desainer, analis, dan penguji dalam proyek pada tahap awal tidak ada hubungannya. Hubungkan mereka di akhir, lebih baik - satu atau dua hari sebelum rilis. Ngomong-ngomong, sprint berikutnya, bahkan untuk mereka, tidak bisa mulai memasak sebelum kita menyelesaikan ini.

Bangun prosesnya sehingga saya perlu mengganti konteks sesering mungkin. Biarkan antrian pengujian menjadi maksimum sehingga permintaan kumpulan saya diuji tidak lebih awal dari beberapa minggu setelah saya melewatinya. Koreksi hanya akan lebih baik jika saya mendekati setiap bug, seperti untuk pertama kalinya.

Dalam hal apapun jangan membuat tribun terpisah untuk cabang-cabang pengembangan yang berbeda. Bagaimana lagi Anda memeriksa pengaruh timbal balik dari berbagai perubahan pada rilis? Dan pastikan untuk digunakan dalam pengembangan database dengan produksi. Hanya dengan cara ini seluruh tim akan merasakan adrenalin yang kuat. Nah, para penguji hanya akan senang bersantai setelah "komit pembunuh" dari berdiri menjengkelkan dan hanya.

Jika Anda secara tidak sengaja mendapatkan ...

... dalam hal apapun jangan biarkan dia melakukan tugas-tugas biasa. Jauh lebih efektif untuk mempekerjakannya 10 Jones sebagai "murid" sehingga ia mengubah mereka menjadi perantara dalam beberapa bulan. Dia spesial, jadi dia akan berhasil! Pertimbangkan untuk mendapatkan seluruh tim dengan uang yang sama. Dengan segala cara yang mungkin, hentikan dia dari mengambil tugas dan menulis kode sendiri, bahkan jika layang-layang terbang di atas arsitektur proyek dan melihat proyek hanya dengan bantuan review. Tunda ulasan kode selama beberapa minggu, jangan terburu-buru, tidak ada waktu untuk menjelaskan alasannya.

Hal utama - jangan meningkatkan gaji profesional terlatih. Ini adalah langkah yang tepat untuk meningkatkan tim. Mengapa tidak "menekan" yang sudah terlatih dan tidak memaksa senior untuk belajar pesta baru? Darah segar dalam tim selalu membantu. Dan perusahaan lain akan tahu bahwa Anda benar-benar bentukan personel. Mereka menghargainya, percayalah.

Jika tidak ada jones, ya sudah, berikan dia semua wawancara dan tugas yang paling menarik. Anggota tim lainnya akan senang bahwa mereka tidak harus melakukannya sendiri. Bagaimanapun, semua orang senang dengan rutinitas ini!

Modul-modul yang akan ditulis oleh senior ini hanya akan tetap ada padanya - tidak ada yang berhak untuk menyentuhnya. Mengapa harus meninjau dan refactor jika Anda memiliki yang ideal di tangan Anda? Dan jangan tampilkan kode ini ke pemula. Dan kemudian tiba-tiba mereka memahami sesuatu di sana atau menyinggung senior dengan bantuan ulasan? Cewek-cewek - dan untuk tuan.

Jika Anda ingin meningkatkan tumpukan teknologi ...

... pikirkan: semakin baru teknologinya, semakin diragukan. Tidak perlu terburu-buru untuk beralih ke versi dan bahasa baru jika setidaknya setengah dari industri belum melakukannya. Biarkan orang lain membuat barang migrasi sendiri. Mereka mengatakan kebenaran - teknologi baru lebih mudah daripada yang lama. Tapi kami profesional! Kita dapat mengerjakan yang sulit! Anda tidak mendapatkan yang terbaik untuk menghabiskan uang dan waktu pada penyederhanaan. Jika pengembang telah bekerja untuk waktu yang lama, ikat mereka dengan fakta bahwa teknologi lama dan terkenal tidak diminati di pasar. Bingo!

Dan jika Anda memilih teknologi modern untuk proyek baru, bagaimana pelanggan memahami bahwa kami adalah tim pro? Dan jika Anda memiliki kerangka kerja Anda sendiri dan banyak perpustakaan kode, konstruktor konstruktor universal, maka Anda tidak akan pernah dapat diperbarui sama sekali.

Jika pengembang mencoba mempelajari sesuatu tentang teknologi baru di belakang Anda, mengembangkan proyek kesayangan, cobalah memuat tugas utamanya lebih keras. Saya mengembangkan ke arah teknis hanya untuk menjauh dari Anda untuk banyak uang (dan lebih cepat).

Omong-omong, lupakan tentang refactoring proyek. Kami, para pengembang, datang dengan kata-kata ini untuk menghibur kebanggaan kami. Dan jangan mencari kode baru dari anggota tim lain atau dari tim tetangga. Seperti yang saya katakan, kami menulis kode sempurna demi kode sempurna. Tidak perlu ditinjau. Bahkan jika pengembang bekerja sendiri dan tidak melihat kode orang lain, kode miliknya akan sempurna. Jika tinjauan tetap diperlukan oleh pelanggan, buat prosedur ini sepenuhnya formal. Biarkan peninjau memiliki kesempatan untuk mengklik tanda centang hijau tanpa membaca intinya. Jangan mencoba untuk membuat tugas untuk menutup hutang teknis dan refactoring, ini adalah pemborosan sumber daya.

Jika Anda membawa saya ke kantor ...

... jangan menghabiskan uang ekstra untuk furnitur. Saya bisa duduk di kursi seharga 500 rubel. VHI adalah - maka kita akan mendukung kita.

Dan jangan menaruh batang horizontal dan treadmill di kantor. Dan kemudian para pengembang akan menjadi pelari alih-alih merokok produktif. Apa kode sempurna ketika mereka telah menyelinap selama berhari-hari?

Memikirkan jadwal, cobalah membuatnya seketat mungkin. Apakah pengembang suka tidur di pagi hari? Tidak ada yang santai! Biarkan semua orang datang jam 8:00. Apakah Anda menemukan orang yang menyukainya? Ubah jadwalnya. Sekarang, biarkan semua orang datang pada 10:00 - melalui kemacetan lalu lintas. Hal utama adalah bahwa setiap orang harus merasa sama buruknya - itu menggerakkan tim! Kami sudah mengatakan bahwa saya harus senyaman mungkin. Grafik dalam pengertian ini meninggalkan bidang yang luas untuk manuver. Hukuman karena terlambat, berpacu di depan pintu kantor - apa yang bisa lebih menyenangkan? Berikan satu hari untuk pekerjaan jarak jauh kepada pekerja kantor? Fuh, mimpi buruk, tidak ingat.

Jika Anda mempekerjakan saya untuk bekerja dari jarak jauh ...

... cobalah untuk menghubungi saya sesedikit mungkin! Pekerjaan jarak jauh diciptakan agar tidak berbicara dengan Homo Sapiens lainnya.

Ngomong-ngomong, aku pergi ke udalenka tepatnya untuk tidak berkomunikasi dengan bagian tim yang masih ada di kantor. Biarkan mereka membuat keputusan desain di ruang merokok dan lebih baik tanpa saya. Mengapa saya harus berpartisipasi dalam ini?

Jangan biarkan saya menentukan sendiri jam kerjanya. Jika semua rekan kantor datang jam 12, maka pekerja jarak jauh harus meninggalkan tempat kerja jam 12. Lalu apa udalenka ini, jika Anda tidak mengubah jadwal untuk malam itu?

Hal utama adalah memberi kebebasan yang lebih sedikit kepada pemecah dalam memilih jam tangan. Saya hampir tidak bisa menghargai keseriusan majikan jika dia tidak bisa memaksa kondisinya. Dan ingat, remote adalah orang yang selalu ada di depan komputer. Ini nyaman, jangan melihat jam kerja, mereka tidak mematuhinya. Jika Anda tidak mengganggu pekerja jarak jauh di malam hari, mereka mungkin memiliki sesuatu untuk memulai. Misalnya keluarga atau anak-anak.

Penulis artikel: Eugene Wetzel ( @imater )

PS Kisah saya hanya kebetulan secara kebetulan dengan kenyataan. Jujur, saya telah mengalaminya untuk beberapa waktu dalam dosis homeopati, terutama karena saya belum menjadi pengembang biasa untuk beberapa waktu. Tetapi saya benar-benar mengingat perasaan dan pikiran saya.

Dan moral di sini sederhana: jika kita memikirkannya dan mencoba untuk mengambil "tips" ini (dengan tanda yang tepat, tentu saja) menjadi pertimbangan ketika merencanakan pekerjaan, semua orang akan merasa sedikit lebih nyaman. Dan kemudian, untuk melihat semua ini dari perspektif yang berbeda, kami akan memberikan saran berbahaya kepada programmer dari perusahaan ... di artikel selanjutnya.

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.

Saran buruk untuk majikan. Cara "benar" berinteraksi dengan pengembang