Bagaimana cara bertahan ketika rekan kerja mengabaikan proses tersebut?

14

Masalah yang saya hadapi:

Anggota tim saya mulai mengerjakan proyek tanpa dokumen fungsional / teknis siap - bahkan jika proses perusahaan kami menentukan ini harus ada sebelum memulai.
Anggota tim saya menerima solusi yang murah dan tidak terstruktur dan akan menerapkan peretasan yang sangat buruk ke dalam perangkat lunak tanpa berpikir dua kali ketika manajemen proyek mencatat bahwa mereka memiliki 'waktu terbatas'.
Anggota tim saya mulai mengerjakan proyek yang bekerja sama dengan proyek yang belum selesai dari tim lain - yang belum diuji dan belum selesai. (menyebabkan banyak pekerjaan tambahan).
Perbaikan dan seluruh fase perangkat lunak tidak direncanakan dengan baik, dan seringkali mengakibatkan front-end / desain tidak selesai ketika pengembang back-end harus mulai bekerja.

Masalah-masalah ini telah dibahas berulang kali sejak saya mulai bekerja di sini. Semua orang setuju dan intinya adalah bahwa kita harus menegakkan proses, itu berarti pengembang back-end tidak akan memulai sampai semuanya diurus.

Masalah-masalah ini terus terjadi - dan saya benar-benar kehilangan motivasi sampai-sampai saya benar-benar kesal dengan pekerjaan itu sendiri dan beberapa rekan saya.

Anggota tim saya banyak mengeluh - tetapi hanya terhadap satu sama lain. They keep on going - whatever the situation is. Hasil?

Saya merasa tidak aman, mungkin ini saya?
Apakah ini yang seharusnya terjadi?

Pertanyaan saya? How can I say no against work ignoring the process if everyone else seems to mindlessly accept?.

Itu tanpa terlihat seperti beberapa pengembang menjengkelkan yang hanya mencari sesuatu untuk menggerutu sepanjang waktu.

project-management teamwork

— Wesley van Opdorp
sumber

Ini adalah tugas QA untuk memastikan bahwa prosesnya diikuti.

— mouviciel

Kami memiliki manajemen, penjualan, manajemen proyek, dan tim pengembangan. QA kurang - sayangnya.

— Wesley van Opdorp

Peran suatu proses tidak jelas untuk semua orang, dan karenanya tidak diterapkan sebagaimana mestinya. Inilah mengapa QA ada: untuk menegakkan penerapan proses. Mendefinisikan proses tanpa orang yang bertanggung jawab untuk menegakkannya seperti mendefinisikan hukum tanpa polisi dan hakim.

— mouviciel

Apa yang dikatakan bos Anda, ketika Anda membicarakan hal ini dengannya?

8

Apakah semua orang benar-benar setuju?

Saya pernah mengalami situasi di mana kami ingin meningkatkan proses. Kami membuat proposal dari Proses yang berbeda, dan semua orang tampaknya setuju.

Tapi kemudian, setiap kali saya ingin mengikuti proses ini, ada yang disebut pengecualian, karena 'hal yang lebih penting', yang selalu terdengar masuk akal pada pandangan pertama. Jadi, pada dasarnya, prosesnya tidak pernah mengikuti de-facto, tetapi semua orang berpikir 'pada prinsipnya, kami mengikuti prosesnya'.

Masalahnya adalah: jika Anda mengusulkan perbaikan, tidak ada orang yang tidak setuju (siapa yang tidak suka perbaikan?). Tetapi jika Anda menunjukkan biayanya, biasanya, ada banyak ketidaksepakatan. Dan kehilangan cara mudah untuk melakukan sesuatu adalah biaya besar bagi kebanyakan orang.

Untuk menunjukkan hal itu, saya mengutarakan Pertanyaan secara berbeda: 'Silakan memprioritaskan semua hal yang seharusnya saya lakukan (mengimplementasikan fitur, menghapus bug, mengikuti proses yang ditingkatkan, membersihkan meja, tiba tepat waktu)'.

Setelah Proses berakhir di belakang membersihkan meja dan tidak terlambat 5 menit. Jadi, pada dasarnya, mereka menyetujui sesuatu yang sama sekali berbeda dari yang saya usulkan.

Masalahnya mungkin, bahwa mereka tidak mau membayar biaya untuk kualitas. Itu mungkin membuat mereka merasionalisasi kritik Anda sebagai rengekan, tetapi menurut pengalaman saya, itu bukan. Utang teknis mungkin tidak terlihat, dan mudah untuk mengaitkannya dengan keadaan, tetapi akhirnya, kenyataan terjadi.

Semoga, sampai saat itu mereka menyadarinya, atau Anda berganti Jobs.

— keppla
sumber

2

'mengikuti proses yang ditingkatkan' adalah satu-satunya pilihan yang berorientasi pada tujuan sehingga hasilnya tidak terduga. Dalam konteks ini kedengarannya lebih seperti "ini mengikuti proses demi proses" dan bukan aktivitas yang berorientasi pada tujuan (kualitas lebih tinggi, produktivitas, dll.).

— MaR

'perbaikan proses' adalah istilah singkat untuk hal-hal seperti 'test setidaknya dangkal sebelum menyebarkan', dan bahwa adalah tujuan berorientasi: tujuannya adalah untuk mengurangi neccessary bekerja untuk hal-hal yang bersih setelah itu, yang adalah apa yang pasti terjadi. Bukannya saya menarik proses dari udara tipis dan membuatnya menjadi dogma. Itu berasal dari masalah berulang yang mempengaruhi produktivitas. Apa yang saya sebut 'proses' dalam posting ini kurang lebih mengikuti 2 atau tiga item tes joel.

— keppla

1

apa yang ingin saya tunjukkan adalah penting bagaimana Anda menjual "proses". Saya akan mengatakan "tes setidaknya secara dangkal sebelum digunakan" akan skor jauh lebih baik daripada "mengikuti proses yang ditingkatkan" dibandingkan dengan "meja pembersih".

— MaR

@ MAr: Saya setuju, saya mengabaikan aspek itu di posting saya. Di tempat kerja, saya tidak mengatakan 'tolong ikuti prosesnya', tetapi lebih seperti 'kami sepakat, bahwa kami harus menguji terlebih dahulu, untuk menghindari mengganggu pelanggan lebih jauh dengan layanan yang rusak, lagi. Kenapa kita sekarang mengabaikan itu? '

— keppla

3

Mungkin itu kamu

Anda tampaknya menyukai cara pengkodean yang sangat terstruktur dan terorganisir, rekan tim Anda tampaknya memiliki pendekatan yang lebih "menyelesaikan sesuatu". Sekarang Anda menyebutkan bahwa itu mengarah ke banyak "waktu terbuang" jadi mungkin beberapa struktur sudah beres dan tidak ada alasan untuk pekerjaan ceroboh. Namun, proyek perangkat lunak cenderung lancar dan menegakkan terlalu banyak struktur juga akan menyebabkan banyak overhead organisasi.

Mungkin Anda semua harus bertemu di tengah dan mencoba pendekatan yang lebih gesit dan interatif, tetapi terstruktur.

— Homde
sumber

1

Jika rekan satu tim tidak menyukai pendekatan 'nya', mengapa mereka setuju sejak awal? Membaca postingnya, saya tidak mendapatkan kesan, bahwa itu adalah lamarannya sendiri. Dan, bahkan pendekatan cairan tidak bekerja tanpa spesifikasi, perbedaannya menurut saya bukan ketidakhadiran, tetapi karakter sementara yang eksplisit dari spesifikasi.

— keppla

Pertama, tidak setuju dengan sesuatu tidak sama dengan melakukan sesuatu :) Mungkin rekan satu timnya tidak melihat alternatif lain. Sekalipun prosesnya adalah ide manajemen, mungkin perlu adaptasi dengan kenyataan untuk memastikan keterlibatan semua pihak. Saya setuju bahwa perlu ada beberapa spesifikasi tetapi sayangnya kadang-kadang menentukan sesuatu bisa sesulit membangunnya. Proses lincah, iteratif dapat memungkinkan spesifikasi untuk mengkristal saat mereka berjalan

— Homde

Dia menyatakan secara eksplisit, bahwa timnya setuju, bukan bahwa mereka tidak setuju. Tolong jangan salah paham, saya tidak menentang proses gesit, tetapi mereka juga hanya itu: proses, yang membutuhkan setidaknya komitmen dasar. Jika semua orang mengabaikan Standup, tidak ada yang menyimpan Backlog, 'spesifikasinya' hanyalah 'omong-omong ...' yang terus didapat saat melewati manajer, bahkan proses yang gesit mati. Dan, pengalaman saya, itu bahkan tidak melukis gambar hitam. Tidak semua perusahaan adalah google. Sebagian besar tampaknya lebih teliti dilbert.

— keppla

2

Saya setuju, mereka perlu menemukan proses yang dapat dibeli oleh semua orang. Perjanjian singkat tidak berarti apa-apa. Mereka mungkin perlu bereksperimen dan melihat apa yang bekerja untuk mereka, baik itu atau rekan satu timnya tidak kompeten dan perlu dipecat :) Saya telah memperhatikan satu hal tentang proses meskipun bahwa bahkan jika ada keterlibatan di sana sering harus minimal satu "proses-nazi" yang memastikan proses menjadi kebiasaan. Hanya berfungsi jika prosesnya

— mendukung

... Btw, saya tidak akan menggunakan google sebagai contoh proses yang baik. Mereka tampaknya menderita kasus insinyur yang parah karena banyak overhead struktural. Terakhir saya dengar mereka mencoba untuk kembali ke akar startup mereka

— Homde

2

Siapa yang bertanggung jawab atas orang-orang ini? Seseorang menyewa mereka dan seseorang dapat memecat mereka / meminta pertanggungjawaban mereka.

"Perusahaan saya membutuhkan ..." tidak ada artinya tanpa penegakan hukum.

Anda tidak dapat membuat tuntutan waktu yang tidak memungkinkan untuk proses produksi.

Sepertinya ini kurangnya kontrol dan harapan yang tidak realistis adalah alasan untuk kualitas yang buruk.

Anda dapat: pergi, menjadi pengembang utama, tidak melakukan apa-apa, atau mulai bekerja dengan mereka yang merasakan cara Anda melakukannya. Pastikan semua orang tahu Anda akan mengikuti prosedur yang benar sampai seseorang menemukan cara yang lebih baik dan mengubahnya. Kedengarannya seperti "Aturan Rumah Cider."

— JeffO
sumber

2

Sepertinya Anda tidak ingin rekan kerja Anda mengikuti proses yang sama sekali berbeda, Anda hanya ingin mereka membuat keputusan yang berbeda di dalamnya. Tentu, ada aturan (pedoman?) Tentang apa yang harus mereka lakukan, dan mereka mengabaikannya. Tetapi masalah yang Anda jelaskan adalah mereka harus membuat keputusan (untuk mulai mengerjakan proyek atau menolak spesifikasi) dan mereka memutuskan untuk terus berjalan. Keputusan itu tidak akan berubah jika Anda terus mengingatkan mereka tentang aturan; mereka hanya tidak terlalu peduli dengan aturan seperti Anda . Mereka ingin merasa bermanfaat, dan mengatakan tidak tidak membuat mereka merasa berguna .

Jika Anda ingin perilaku mereka berubah, maka terus-menerus mengingatkan mereka tentang aturan mungkin tidak terlalu efektif; itu lebih cenderung menyebabkan mereka mengabaikan Anda. Cobalah untuk menemukan cara untuk mengubah proses agar mereka merasa lebih berguna sambil tetap mengikuti proses. Bisakah Anda menerapkan semacam tinjauan kode, memeriksa kode masing-masing dan belajar dari satu sama lain untuk mencegah peretasan membuat kode produksi? Bisakah Anda mengubah cara spesifikasi (docs / ext.interfaces / front-end) ditangani dari keputusan hitam-putih jadi / tidak jadi ke proses yang lebih kooperatif, di mana mendekati akhir spesifikasi yang diminta pengembang bantu selesaikan? (Dan, Anda harus menerima bahwa persyaratan akan berubah)

Sebagian besar itu bukan Anda, itu bukan mereka, itu prosesnya. Jika Anda (dan PM Anda) dapat menemukan beberapa cara untuk mengatur hal-hal di mana orang tidak harus terlalu menentang karakter mereka, prosesnya akan diikuti jauh lebih cepat.

— Jaap
sumber

2

Ini tentang titik di mana saya akan check-in dengan sesi tertutup dengan pemimpin tim saya. Semoga Anda memiliki hubungan kerja yang cukup baik dengan pimpinan yang bisa Anda buat sangat informal.

Tujuan dari pertemuan ini adalah untuk mencari tahu mengapa tim melakukan hal-hal seperti yang mereka lakukan. Jika semua orang berkumpul, mengangguk, tersenyum dan menyetujui proses baru, lalu mengapa mereka masih tidak berubah? Peluangnya bagus karena berjalan jauh lebih dalam daripada tidak peduli atau tidak kompeten. Kemungkinan ada driver di tempat kerja yang tidak terlihat dengan mata telanjang.

Mulailah rapat dengan anggapan bahwa rekan kerja Anda akan, jika mereka bisa, mengikuti proses yang mengarah pada lebih sedikit kepanikan, hutang teknis yang lebih rendah, dan kualitas produk yang lebih baik - lagi pula, siapa yang tidak menginginkan itu? Jadi apa kekuatan yang tak terlihat?

Kedengarannya seperti ada banyak implementasi / integrasi sebelum pekerjaan dimuka desain dan prototipe UI. Apakah perusahaan kekurangan orang yang dapat melakukan pekerjaan di muka itu? Mungkin Anda bisa menjadi sukarelawan. Apakah ada masalah mendapatkan konsensus dengan pemangku kepentingan? Mungkin tim Anda dapat menemukan cara baru untuk berkomunikasi dengan mereka atau dapat mengambil pendekatan baru untuk mendokumentasikan asumsi.

Jika Anda mulai dengan satu lawan satu di mana Anda bertanya mengapa, maka Anda dapat membuka pintu untuk diskusi yang menghindari pertahanan dan berfokus pada masalah dan solusi.

Trik lain mungkin dengan bertanya apakah Anda dapat merintis cara baru dalam melakukan sesuatu. Dapatkan dukungan dari pimpinan tim Anda untuk sedikit memaksa masalah ini dan membiarkan Anda mengambil pendekatan yang Anda anjurkan - mungkin akan muncul masalah saat Anda melawan "sistem", sehingga Anda ingin manajemen mendukung Anda. Tetapi jika Anda berubah menjadi lebih produktif dan bebas stres, Anda memberikan alasan yang baik untuk mengubah cara hal-hal, dan Anda cenderung memenangkan advokat.

— bethlakshmi
sumber