Saya telah mengerjakan proyek baru. Proyek ini bekerja seperti ini: Pengguna akhir dapat mengakses aplikasi web menggunakan tautan dan dia dapat menambahkan beberapa sistem di jaringannya dan mengelola detail sistem tertentu. Bagian saya melibatkan ujung depan dan server web, yang dilakukan dengan python. Python saya sebenarnya berkomunikasi dengan proyek lain yang seluruhnya dilakukan dalam c & c ++. Proyek c / c ++ adalah aplikasi utama yang melakukan semua fungsi. Python saya mengirimkan permintaan pengguna ke sana dan menampilkan respons darinya kepada pengguna.
Saya sangat akrab dengan pekerjaan saya dan saya akan segera menyelesaikannya. Karena itu tidak banyak pekerjaan di dalamnya. Dan saya adalah orang yang suka bekerja. Saya menghabiskan sebagian besar waktu di kantor dan hanya pulang ketika saya merasa mengantuk.
Aplikasi c / c ++ dikelola oleh kolega lain yang memiliki pengalaman 5+ tahun dan dapat melakukan banyak hal lebih cepat dari saya, tetapi dia tidak pernah melakukannya. Mungkin dia tidak suka melakukannya. Aplikasinya sering macet ketika python saya berkomunikasi dengannya atau mengembalikan nilai yang salah. Penuh dengan bug. Karena aplikasi saya bergantung padanya, saya kesulitan membangunnya. Alih-alih memperbaiki bug, dia meminta saya untuk memperlambat pekerjaan saya. Dia meminta saya untuk memberi tahu manajer bahwa pekerjaan saya membutuhkan banyak waktu. Dia meminta saya untuk menipu manajer dan bahkan memaksa saya untuk bekerja perlahan seperti dia.
Selama pertemuan proyek, ketika manajer bertanya kepadanya tentang bug, dia mengatakan bahwa dia memperbaiki semuanya dan itu berfungsi dengan baik. Karena dia adalah kolega saya, saya tidak bisa mengatakan apa pun kepada manajer. Saya jelas perlu memiliki hubungan yang baik dengan kolega saya lebih dari manajer saya, karena sebagian besar waktu kita akan bersama kolega kita, bukan dengan manajer.
Saya tidak dapat memberi tahu manajer tentang hal ini, karena jika manajer bertanya mengapa, maka dia mungkin berpikir saya mengeluhkannya kepada manajer. Dan dia terus berbaring di rapat. Dan karena dia memperbaiki bug secara perlahan, itu bahkan memperlambat pekerjaan saya. Sekarang saya berpikir untuk bekerja di bagian ujung depan aplikasi saya dan menyelesaikannya sehingga sementara itu ia dapat membuat proyeknya stabil. Sekarang dia meminta saya untuk memberi tahu manajer bahwa bagian ujung depan saya memerlukan banyak pekerjaan dan saya mungkin memerlukan lebih banyak waktu, hanya agar ia dapat menarik proyek ke bawah. Dan yang menyedihkan adalah manajer kami yang sebenarnya telah pergi ke AS, jadi kami memiliki manajer sementara dan orang ini tidak terlalu mengenal proyek ini, jadi c, c ++ hanya membodohinya.
Adakah yang bisa menyarankan saya bagaimana saya menangani ini? Saya ingin menyelesaikan proyek ini segera. Bagaimana saya bisa membuatnya bekerja bahkan dengan mempertahankan hubungan yang baik dengannya?
Tanggapan terhadap komentar:
Jika dia benar-benar sengaja menyesatkan perusahaan, Anda harus melaporkannya kepada manajemen.
Saya baru di perusahaan ini dan orang lain telah ada di sana selama bertahun-tahun. Dan saya baru saja mulai mengenal kolega saya. Jika saya langsung pergi dan mengeluh padanya, saya tidak berpikir saya bisa menjalin hubungan yang baik dengan rekan-rekan saya yang lain. Bahkan dia memiliki kekuatan untuk menyesatkan mereka. Saya tidak mengatakan bahwa dia adalah orang jahat, dia bisa melakukan pekerjaan itu, tetapi dia tidak melakukannya.
Apakah perusahaan Anda tidak memiliki sistem pelacakan bug?
Di sini, sistem pelacakan bug sebenarnya tidak ada. Perusahaan mencoba menyelesaikan proyek secepat mungkin dan memberikannya kepada QA. Dan kemudian memperbaiki bug yang dilaporkan oleh QA.
Inilah sebabnya mengapa perusahaan harus memberi karyawan saham / opsi atau semacam kepemilikan. Dengan begitu Anda dapat benar-benar memberi tahu orang itu "Anda membuat saya mengalami pertumbuhan moneter ... tidakkah Anda ingin menghasilkan uang juga?".
Perusahaan memiliki opsi saham yang mereka berikan kepada saya 2.500 saham, sebagian besar dia juga akan mendapat lebih banyak.
Senioritas memang pantas mendapat manfaat dari keraguan. Anda benar-benar perlu berbicara dengannya terlebih dahulu dan mencoba memahami masalahnya. Dia mungkin berada di luar kedalamannya, Anda mungkin dapat membantunya, mungkin ada variabel yang tidak Anda sadari. Mungkin sulit sekarang, tetapi Anda dapat dengan mudah membuat situasinya jauh lebih buruk dengan melompat pistol.
Saya bahkan melakukannya, pertama aplikasinya tidak menangani beberapa permintaan sekaligus, dia menggunakan antrian untuk menangani permintaan yang saya kirim kepadanya. Saya bahkan menyarankan kepadanya beberapa ide saya tentang itu. Dia bilang dia sudah punya ide-ide ini, dan akan mengeksekusi mereka. Penjelasannya adalah: "Segala sesuatu membutuhkan waktu tertentu untuk dilakukan dan ini adalah proyek yang mungkin perlu dua tahun untuk menyelesaikan dan kami diminta untuk menyelesaikannya dalam dua bulan". Saya dulu mengalami kesulitan coding selama beberapa minggu pertama karena bug ini. Tapi sekarang dia memperbaikinya. Tapi dia menggunakan antrian tunggal untuk permintaan pengguna dan itu sekarang memperlambat aplikasi, karena memproses satu permintaan pada suatu waktu.
Apa yang dilakukan QA sepanjang waktu ini? Mengapa mereka tidak melaporkan / mengkonfirmasi status proyek?
Manajer adalah orang yang memutuskan kapan harus memberi kepada QA. Sampai sekarang belum diberikan kepada QA. Dia mengatakan kita harus memberikannya pada akhir bulan ini.
Jawaban:
Anda berada dalam situasi yang buruk, saya tidak ingin berada di posisi Anda. Tidak mungkin Anda bisa menyelesaikannya tanpa terlibat konflik dengan kolega Anda.
Inilah yang akan saya lakukan:
Jangan menjadi rekannya dalam kejahatan. Tolak berbohong tentang status proyek Anda atau proyeknya.
Terapkan (di waktu luang Anda jika perlu) pelaporan bug ke aplikasi Anda, sehingga semua bug dikirim melalui email ke rekan kerja Anda dan ke manajer Anda. Jika bug disebabkan oleh aplikasinya, buat itu terlihat di email (masukkan [XYZ APP BUG] ke subjek email atau sesuatu).
Menjaga basis data bug (selain mengirim bug melalui email). Anda dapat mengatakan bahwa tujuan utamanya adalah melacak bug Anda , padahal sebenarnya Anda akan melacak sebagian besar bug- nya . Antara lain, ia harus melacak berapa lama untuk memperbaiki bug tertentu.
Semua komunikasi antar-proses dengan aplikasinya ditutupi dengan tes ("ketika saya mengirim ini kepada Anda, Anda harus mengembalikan gaya itu kepada saya"). Anda dapat mengatur tugas cron yang menjalankan tes ini setiap hari dan jika gagal, email dikirim ke semua orang.
Pada dasarnya, cobalah untuk tidak membuang waktu Anda berdebat dengannya tentang bug dan fokus pada pekerjaan Anda saja. Jika aplikasinya rusak dan karenanya Anda tidak dapat mengerjakan aplikasi dan manajer Anda tidak melakukan apa-apa dengannya - yah, itu adalah masalah manajemen dan Anda dilindungi dengan basis data bug, email, dan laporan pengujian.
Namun, waspadalah dan jangan meremehkannya. Pemalas lama seperti dia mungkin memiliki satu atau dua trik di lengan bajunya. Dia dapat mengubah seluruh tim melawan Anda atau sesuatu, tetapi itu tergantung pada situasi spesifik Anda dan itu agak di luar cakupan pertanyaan ini.
sumber
Saya akan memberikan pandangan yang sedikit kontroversial: Anda mengatakan bahwa Anda bekerja berjam-jam agar Anda tetap terjaga. Jadi mungkin dia tidak terlalu tidak adil untuk mengatakan "kamu membuatku terlihat buruk dan aku benar-benar bekerja berjam-jam seperti yang aku mau." Mungkin dia pernah ke sana dan melakukan itu dan mungkin dia kelelahan. Saya berjanji kepada Anda bahwa Anda akan melakukannya jika Anda terus melakukannya.
Pergi keluar untuk minum bersamanya suatu malam dan lihat apakah Anda tidak dapat membangun hubungan pribadi yang lebih baik yang menjadi dasar profesional Anda. Mungkin dengan persetujuannya untuk memasukkan sedikit lebih banyak dan Anda setuju untuk memasukkan sedikit lebih sedikit, Anda berdua bisa bekerja sama jauh lebih baik.
Jika saya jadi Anda, saya juga akan sangat berhati-hati terhadap seluruh sikap "pekerjaan saya, pekerjaan Anda" ini. Di antara Anda berdua, Anda memiliki produk untuk keluar dan ini tidak mungkin baik untuk produk itu, yang pada gilirannya tidak baik untuk perusahaan atau pelanggan dan mereka membayar Anda berdua untuk bekerja .
Namun, saya masih setuju dengan pandangan lain bahwa Anda perlu meninjau kembali pentingnya hubungan Anda dengan manajer Anda dan Anda harus berhati-hati mempercayai kolega Anda. Saya hanya mengatakan bahwa mungkin, mungkin saja, Anda perlu melihat tindakan Anda sendiri dan juga tindakannya.
sumber
Simpan catatan. Dokumentasikan setiap kesalahan yang Anda dapatkan saat berkomunikasi dengan pihaknya, ketika Anda memintanya untuk memperbaikinya dan kapan (jika pernah) ia melakukannya. Itulah satu-satunya cara saya tahu untuk menghadapi situasi ini. Jadi, ketika manajer Anda mendatangi Anda untuk bertanya mengapa hal-hal tidak mengalami kemajuan, Anda dapat dengan jelas menunjukkan tanpa terlihat sebagai perengek atau kolega yang buruk.
sumber
Saya ingin menunjukkan kemungkinan lain yang belum muncul. Anda mengatakan bahwa dia ingin Anda memperlambat pekerjaan Anda. Apakah maksud Anda secara harfiah dia mengatakan "bekerja lebih sedikit" atau bahwa dia mengatakan "tulis beberapa tes, tes lebih banyak ini, tulis beberapa dokumentasi" dan hal-hal lain yang menurut Anda akan memperlambat Anda? Saya telah melihat orang-orang baru berlarian menulis kode selama 16 jam sehari dan kemudian mengeluh bug dalam kode yang mereka panggil padahal sebenarnya mereka melewati parameter yang tidak valid, mereka tidak memeriksa nilai balik, dan sebagainya. Saya tidak dapat mengesampingkan bahwa rekan kerja Anda memikirkan hal-hal ini.
Lain kali Anda berada di sebuah pertemuan dan dia mengatakan semua kode nya baik-baik saja, katakan "oh, bagus, hal yang saya katakan sekitar satu jam yang lalu, di mana meledak ketika saya menelepon XYZ dengan tanggal yang bukan hari kerja, sudah diperbaiki sekarang? " Satu dari tiga hal akan terjadi:
Anda mungkin mengetahui bahwa hari-hari pengkodean cepat Anda yang lama tidak menghasilkan kode yang baik, dan seseorang (mungkin manajer Anda) mungkin menerjemahkan untuk pengembang lain untuk menjelaskan kepada Anda apa masalahnya. Atau, Anda mungkin belajar bahwa Anda bekerja dengan ular berbaring yang akan membuat Anda terlihat buruk untuk melindungi posisinya yang nyaman. Membawa hal-hal ke tempat terbuka tidak bisa benar-benar memperburuknya. Atau, Anda mungkin mendapat cukup gerakan dari dia sehingga Anda bisa tahan, tanpa terjebak dalam politik.
sumber
Apa yang Anda miliki adalah masalah politik. Pertama, pendapat manajer Anda jauh, jauh lebih penting daripada yang tampaknya Anda pikirkan. Orang ini menyalahkan Anda atas keterlambatan dan Anda membiarkannya. Anda adalah orang yang akan dipecat jika seseorang terlempar ke bawah bus. Sejauh yang diketahui manajer, Anda adalah orang yang tidak mampu melakukan pekerjaan dengan tepat waktu.
Lindungi diri Anda dengan cara apa pun yang Anda bisa, melalui pelacakan bug, email dll, tetapi JANGAN berpura-pura ini adalah penundaan Anda bukan miliknya. Jangan pernah memberi laporan status palsu kepada bos, itu akan kembali menggigit Anda. Katakan pada bos kebenaran tentang masalah yang Anda miliki (dan tunjukkan bukti) dengan kode-nya tidak berfungsi.
Orang ini yang meminta Anda untuk mengendur sehingga ia tidak terlihat buruk adalah ular (yah itu penghinaan terhadap komunitas ular (referensi Firefly yang halus), maaf untuk semua ular yang sebenarnya di luar sana). Dia akan melakukan apa saja untuk melemparmu ke bawah bus, bukan dia. Jangan percaya dia.
sumber
Pertama dan terutama:
Anda benar-benar dapat dan harus memastikan manajer Anda mengetahui kebenarannya, bahkan jika rekan kerja Anda berbohong. Jika Anda tidak ingin mengatakan apa pun dalam pertemuan dengan Anda bertiga di ruangan itu, itu benar-benar dapat dimengerti. Tetapi Anda setidaknya harus menarik manajer Anda (yang asli, bukan hanya sementara) dan biarkan mereka tahu bahwa pekerjaan Anda hampir selesai dan sedang menunggu perbaikan bug dari ujung pengembang lain sebelum seluruh aplikasi siap untuk prime-time. . Jangan menuduh rekan kerja Anda berbohong, tetapi jangan duduk di sana dan biarkan bos Anda beroperasi dengan informasi yang tidak lengkap.
Laporkan status Anda dengan jujur. Jika pekerjaan Anda ditahan oleh bug di ujung pengembang lain, dokumentasikan bahwa Anda telah menemukan bug di C / C ++ dan telah melaporkannya (tolong katakan padaku Anda menggunakan beberapa bentuk dokumentasi yang meninggalkan jejak kertas).
Sementara itu, lanjutkan dan selesaikan pekerjaan Anda, dan beri tahu atasan Anda kapan Anda selesai. Jika manajer Anda ingin tahu mengapa sisa proyek belum berjalan, Anda dapat merujuknya ke pengembang lain, dan mungkin menyebutkan bahwa itu mungkin sangat rumit / besar / memerlukan banyak pengujian / pengembang lain sangat sibuk / dll. Jika Anda tahu C / C ++, Anda dapat menawarkan bantuan pada logika aplikasi utama untuk membuat semuanya bergerak juga. Ya, Anda akan melakukan pekerjaan orang lain, tetapi jelaslah bahwa Anda adalah karyawan yang bekerja keras dan menjadi produktif, dan orang lain tidak, apalagi membuat Anda lebih berharga bagi bos Anda. Bahkan mungkin memberi tekanan pada pengembang lain untuk meningkatkan dan menyelesaikannya lebih cepat.
sumber
If you know C/C++, you can offer to help on the main application logic to get things moving with that as well.
Ada sejumlah masalah di tempat kerja. Ketahuilah bahwa:
Karena itu, ketika mempresentasikan status proyek Anda:
sumber
Ini tidak sehat dan tidak dapat diharapkan oleh kolega, kecuali Anda diberi kompensasi sampai mampu mengambil tahun libur karena kelelahan yang tak terelakkan. (Sesuatu seperti> 10% kepemilikan di perusahaan atau di atas $ 200 juta tahun). Mempertahankan keahlian untuk mencapai titik di mana ia dapat berkembang dengan sangat cepat membutuhkan waktu. Sebagian waktu Anda harus dikhususkan untuk mengembangkan keahlian.
Python adalah bahasa yang lebih gesit daripada C / C ++. Aplikasinya tampaknya berisi semua fungsi; aplikasi Anda hanya UI. Lebih mungkin daripada tidak, ini tidak sama dalam kesulitan. Dia mungkin tidak memproduksi kode dengan cepat; tetapi pengkodean kualitas jauh lebih baik daripada pengkodean kuantitas. Anda mungkin memiliki harapan yang tidak realistis untuk seberapa cepat dia dapat mengkodekan dalam jam yang dia inginkan / harapkan untuk bekerja (biasanya ~ 40 jam seminggu; dan ingat jika dia sudah ada di sana selama bertahun-tahun, dia kemungkinan mengumpulkan tugas-tugas lain seperti mengelola orang lain atau membantu mempertahankan usia yang lebih tua proyek yang mengambil bagian penting dari minggu kerja).
Jangan bohongi dia; tapi sekali lagi jangan mengkritiknya juga. Bicara tentang bagaimana sistemnya hebat; diberikan itu membutuhkan lebih banyak pekerjaan sampai selesai. Berikan pembaruan status akurat kepada manajer Anda tanpa menyebut nama / menyalahkan. Tulis versi tiruan dari sistemnya yang sesuai dengan standar yang sama dengan sistemnya. Pastikan sistem Anda berfungsi dengan baik dengan sistem mocked-up Anda dengan test suite otomatis. Kemudian sistem Anda dapat diselesaikan (mis. Sinkronisasi sempurna dengan mock-up), bahkan jika sistem live masih bermasalah.
Kemudian Anda dapat menulis suite pengujian otomatis untuk sistemnya yang disebut eksternal yang sesuai dengan standar yang disepakati. Misalnya, tes dari Foo (1,2,3) memberikan respons "Bar 4 5 6". Ini bisa membantunya mengidentifikasi bug dan mempercepat perkembangannya (dan tidak perlu dipusingkan dengan kodenya). Setelah hal-hal itu selesai, Anda dapat beralih ke proyek / tugas lain (seperti membantunya dengan bagian C / C ++).
sumber
Seperti yang disebutkan orang lain, berperilaku profesional adalah hal terpenting untuk karier jangka panjang Anda. Dan jujur, selama Anda berperilaku profesional, Anda akan berada dalam kondisi yang cukup baik, tidak peduli bagaimana orang-orang di sekitar Anda berperilaku.
Dalam situasi ini, ada beberapa pertimbangan yang perlu Anda perhitungkan.
Pertama, Anda perlu memahami bahwa Anda bertanggung jawab untuk program Anda bekerja dengan spesifikasi yang diinginkan, dengan tenggat waktu yang diberikan. Jika program Anda bekerja sama dengan program orang lain, Anda juga bertanggung jawab untuk memastikan bahwa program lain juga bekerja dengan tenggat waktu yang sama. Untuk menempatkan ini secara berbeda: Jika orang lain melewatkan tenggat waktu mereka, maka Anda juga telah melewatkan tenggat waktu Anda, bahkan jika bagian Anda sendiri dari proyek tepat waktu. Dalam istilah manajemen, ini disebut memiliki input .
Anda telah mencatat dengan benar bahwa ketika kolega Anda menyatakan dalam rapat bahwa bug programnya sudah diperbaiki, bahwa Anda tidak dapat segera mendeklarasikan dia sebagai manajer yang tidak benar (manajer Anda akan melihat bahwa sebagai "melempar rekan kerja Anda di bawah bus"; langkah karir yang sangat buruk). Yang lain, di sisi lain, telah menunjukkan bahwa tidak profesional untuk tidak menyatakan keadaan sebenarnya dari proyek kepada manajer. Kedua belah pihak sepenuhnya benar.
Jadi, jika buruk untuk bertentangan dengan rekan Anda di depan manajer, dan juga buruk untuk tidak menentangnya, lalu apa yang Anda lakukan?
Jawabannya sebenarnya cukup sederhana: Anda perlu berbicara dengan kolega Anda jauh sebelum pertemuan dengan manajer, dan biarkan mereka tahu bahwa pada pertemuan mendatang Anda perlu memberi tahu manajer tentang masalah yang Anda alami dengan program mereka, dan itu memengaruhi kemampuan Anda untuk menyelesaikan proyek Anda tepat waktu, dan apakah ada yang bisa Anda lakukan untuk membantu mereka mengatasi masalah yang Anda alami. Anda perlu melakukan percakapan ini setidaknya dua hari penuh sebelum pertemuan di mana Anda akan memberi tahu manajer, dan lebih baik seminggu penuh di muka.
Dalam kebanyakan kasus, hanya memberi tahu kolega Anda bahwa Anda harus mendaftarkan program mereka sebagai risiko pada pertemuan tertentu akan membuat mereka termotivasi untuk mengatasi masalah yang Anda hadapi, dan Anda tidak perlu berbicara dengan manajer sama sekali. . Di tempat lain, di mana masalahnya lebih digerakkan oleh jadwal, kolega itu akan sering setuju dengan Anda, dan Anda berdua bisa pergi ke manajer bersama.
Saya belum pernah memiliki kolega yang tidak cepat memperbaiki keadaan untuk saya atau setuju dengan keprihatinan saya, ketika diungkapkan dengan cara ini. Tetapi jika hal itu terjadi, dengan memberi peringatan terlebih dahulu kepada kolega Anda, Anda masih akan berada dalam posisi yang lebih baik ketika berbicara dengan manajer. Karena Anda berbicara dengan kolega Anda dan mencoba mencari solusi sendiri, dan memperingatkan mereka sebelumnya bahwa Anda perlu mengemukakan masalah pada pertemuan ini, kolega Anda tidak akan terkejut ketika mereka melakukannya, dan manajer menang berpikir bahwa Anda hanya mencoba mengalihkan kesalahan.
Harap ingat bahwa ketika Anda menyatakan kekhawatiran Anda, baik kepada kolega atau manajer, bahwa kekhawatiran Anda adalah tentang program kolega Anda yang mengembalikan data buruk (atau apa pun yang dilakukan); ini adalah hal-hal yang dapat diukur yang dapat diverifikasi dan diperbaiki. Kekhawatiran Anda bukan tentang kolega Anda yang lambat atau tidak didedikasikan; ini bukan hal-hal yang dapat diukur, yang mungkin atau mungkin tidak benar, dan yang tidak mungkin diperbaiki dengan membawa mereka dalam rapat di depan bos.
sumber
Sistem pelacakan bug apa yang Anda gunakan? Saya berharap bahwa setidaknya untuk menyoroti di mana bug tidak diperbaiki pada waktunya. Di mana kode Anda menunggu input dari lapisan lain, penundaan harus disorot dalam dokumentasi pelacakan proyek. Apakah ini tidak terjadi juga?
Bagi saya sepertinya ada manajemen proyek yang tidak memadai di sini. Anda perlu a) melacak bug yang memengaruhi Anda dan b) menindaklanjuti diskusi secara tertulis.
Kolega Anda seharusnya tidak meminta Anda untuk mengembang waktu pengembangan Anda untuk menutupi kekurangannya. Pada titik tertentu, ini adalah sesuatu yang harus ditangani dengan manajer Anda. Seperti yang terjadi, Anda menutupi rekan Anda dan itu hampir pasti akan menjadi bumerang.
sumber
Tidak ada salahnya berpegang teguh pada kolega, tetapi bagi seseorang yang mengharapkan Anda berbohong kepada bos Anda setiap hari harus dilakukan. Saya tidak bisa menghormatinya sebagai pribadi dan tidak ingin memiliki orang ini sebagai kenalan biasa. Dia ingin menjadi musuh, mewujudkannya.
Bagaimana Anda bisa berdebat penundaan pada lapisan aplikasi karena ujung depan? Itu sebabnya Anda melakukan ini sehingga mereka dapat terpisah. Apa selanjutnya, ia bahkan memiliki lebih banyak keterlambatan karena seseorang ingin membangun ujung depan mobil?
Selesaikan pekerjaan Anda. Dokumentasikan segala masalah yang Anda alami dengan kegagalan pada aplikasinya. Dan kemudian pulang! Saya tidak peduli apakah Anda mengantuk atau tidak. Temukan beberapa teman yang layak dimiliki.
sumber
Saya baru saja membaca "The Clean Coder" oleh RC Martin (Paman Bob). Poin utama buku ini adalah bahwa para programmer pada umumnya tidak mendapatkan banyak rasa hormat karena mereka tidak berperilaku profesional . Itu berarti terutama bahwa mereka tidak berkomunikasi secara efektif dengan manajemen tentang status proyek.
Berbohong tentu saja merupakan bentuk komunikasi yang sangat buruk. Rekan Anda menjadi sangat tidak profesional dan Anda juga. Anda berdua tidak melakukan hal yang baik untuk meningkatkan persepsi programmer.
Saya akan menyarankan Anda untuk segera pergi ke manajemen. Namun, saya mendapat masalah di masa lalu karena terlalu "jujur" (dalam beberapa situasi yang tidak berhubungan), jadi saya tidak yakin Anda harus menerima saran saya. Juga, seperti yang telah ditunjukkan banyak orang, mungkin persepsi Anda tentang situasinya tidak seakurat yang Anda pikirkan.
sumber
Sulit dan tidak masuk akal untuk memperkirakan upaya relatif dan kompleksitas proyek lain jika Anda tidak terbiasa dengan basis kode. Anda mengatakan kodenya rawan kesalahan, tetapi bisa saja dalam kondisi sangat baik dengan semua masalah yang tersisa pada tingkat abstraksi yang sangat tinggi ... Masalahnya, itu adalah satu - satunya kode yang dibutuhkan oleh ujung depan Anda!
Atau, mungkin dia karyawan yang buruk dan membawa perusahaan untuk naik. Saya tidak bisa mengatakan, dan Anda mungkin tidak memiliki semua informasi yang perlu Anda ketahui dengan percaya diri.
Saya menyarankan taktik di tengah jalan. Lain kali Anda bertemu, bawalah beberapa detail bug utama dalam kodenya yang memengaruhi Anda. Ketika dia mengatakan semuanya baik-baik saja, dengan sopan katakan ada satu masalah besar yang menghalangi kemajuan Anda.
Secara politis, mengatakannya seperti itu, mari Anda menegaskan bahwa ia tidak sepenuhnya benar, sambil masih memberinya celah untuk bermain bodoh dan tidak bersikap defensif.
Manajer Anda harus bertanya pada rapat berikutnya apakah sudah diperbaiki. Jika tidak, tekanan jatuh pada dirinya untuk memperbaiki satu bug. Jika sudah diperbaiki, ucapkan terima kasih, itu berfungsi baik sekarang, dan Anda menemukan pemblokir baru. Jika Anda ingin bersikap baik, katakan Anda bertemu dengannya sesaat sebelum pertemuan.
Anda tidak berbohong, tidak juga memihak. Anda bermain politik dengan memperhatikan masalah dan membiarkan rekan Anda menyelamatkan muka jika segalanya benar-benar tidak berjalan dengan baik.
Sangat menggoda untuk hanya berbicara dengan manajer Anda, tetapi jangan lupa yang mana dari mereka yang paling sering bekerja dengan Anda.
sumber
Jawaban Pat luar biasa. Saya setuju 100%. Jangan pergi menyelinap rapat dengan bos. Bawalah bersama kolega Anda di antara 4 mata atau lakukan dengan Anda bertiga. Tetapi saran Pat untuk fokus pada masalah kode dan bukan pada orang-orang adalah cara yang tepat.
Btw, 40 jam / minggu sudah cukup bung. Anda perlu menjaga motivasi Anda tetap tinggi!
sumber
Minta beberapa yang lain untuk membantu Anda berdua dalam pengujian integrasi. Orang tersebut harus dapat mengatakan di mana masalah tersebut terjadi. Seperti yang ditunjukkan temptar saya bertanya-tanya mengapa bahkan tidak ada yang unggul untuk melacak masalah! karena tidak ada pelacakan, seperti setiap kali orang lain melarikan diri dengan mengatakan semuanya baik-baik saja seperti sekarang! tidak berhasil seperti itu!
Ini modul Anda jika Anda harus menyelesaikannya, Anda perlu menaikkan bendera merah pada apa yang menyebabkan keterlambatan di sisi Anda. Pengalaman di MERE Years tidak ada hubungannya, hanya pengetahuan dan itulah yang harus ditekankan oleh manajer Anda. Seperti yang saya katakan bahkan saya merasa ada manajemen proyek yang buruk terjadi di sini.
sumber
Manajer Anda mungkin tidak cukup teknis untuk mencari tahu siapa yang memperlambat proyek, tetapi mereka mungkin cukup pintar untuk mengenali bahwa pengembang yang secara aktif mencari tugas baru sedang mencari-cari melalui tugas mereka saat ini. Ini akan mengarah ke percakapan di mana Anda bisa menjelaskan bahwa Anda sedang menunggu perbaikan bug dari orang lain pada tugas Anda saat ini. Kerangka diskusi dalam hal bagaimana Anda dapat menambahkan nilai tambahan ke organisasi dengan efisien menggunakan waktu luang Anda, bukan bagaimana rekan Anda terlalu lambat dengan perbaikan bug-nya.
sumber