Bagaimana cara menyelamatkan proyek yang muda dan sekarat?

Saya memposting ini secara anonim karena saya tidak ingin mendapat masalah potensial.
Aku punya masalah besar.
Saya baru-baru ini bergabung dengan tim yang berusia kurang dari setahun. Saya sudah di sini sejak satu bulan sebelum proyek dimulai. Struktur perusahaan terlihat seperti ini:

• Pemilik (non-teknis)
  • Manajer Proyek (non-teknis)
    • Memimpin Pengembang (Teknis, tetapi buruk dalam hal itu)

Proyek ini adalah situs web yang menggunakan ASP.Net yang dirancang oleh Pengembang Utama untuk arsitektur yang mengerikan. Anda harus mengambil kata-kata saya di itu, tetapi pada dasarnya, cara kami diminta untuk membangun halaman web memberi kami waktu memuat 3+ menit pada satu halaman web melalui VPN dalam mode Debug.

Ini telah melonjak ke titik di mana rekan kerja lainnya setuju bahwa mereka menghabiskan lebih banyak hari mereka menunggu halaman untuk memuat daripada pengembangan yang sebenarnya.

Sekarang masalah besar adalah ini. Manajer Proyek tidak mengetahui teknologi dan mengakuinya. Dia secara khusus menyatakan bahwa dia mempercayai Pengembang Utama untuk membuat pilihan yang benar pada arsitektur aplikasi.

Tidak seorang pun di tim tahu apa pendapat Pemilik, tetapi semua orang takut membuat gelombang dalam perekonomian ini (terutama saya sendiri).

Apa yang akan kamu lakukan?

Masalah ini dapat ditunjukkan kepada manajer proyek dalam istilah yang sangat non-teknis. Tempatkan situs Anda di jendela browser di depan PM dan minta dia untuk bermain-main dengannya sebentar. Setelah memuat sekitar dua halaman, pengembang utama harus dipanggil, jika semuanya seburuk yang Anda katakan.

PM mungkin tidak memiliki pengetahuan pengembangan khusus untuk memahami mengapa itu buruk, tetapi ia dapat melihat sendiri sebagai pengguna situs web umum. Situs lain yang menampilkan informasi serupa memuat dalam sepersekian waktu Anda, dan milik Anda memuat melalui jaringan lokal dari server di kamar sebelah.

Jika ini tidak terbang, maka pergi ke pemilik. Pemiliknya adalah seorang lelaki uang, tetapi dia akan dengan cepat dapat melihat bahwa situs web yang lambat itu tidak akan dikunjungi siapa pun == tanpa uang. Siapkan demonstrasi yang sama, dan sebelum halaman pertama dimuat, dia seharusnya memanggil KEDUA PM dan Pemimpin di atas karpetnya yang jauh lebih mewah.

Jika Anda khawatir satu orang membuat gelombang, maka dapatkan lebih dari satu pengembang yang bersedia menyuarakan keprihatinan mereka. Sejujurnya, di sebuah perusahaan selurus milik Anda, jika produk yang Anda kembangkan adalah bom, Anda kehilangan pekerjaan apakah Anda berbicara atau tetap diam. Jadi melihat seperti itu, Anda tidak akan rugi kecuali beberapa minggu atau bulan ekstra dengan perusahaan. Jika itu masalah, jadwalkan beberapa "janji dokter gigi" dan cari pekerjaan baru sebelum menyiarkan kekhawatiran Anda, jadi jika Anda kehilangan pekerjaan ini, Anda mulai hari Senin berikutnya.

Dengan asumsi pernyataan Anda akurat, Anda memiliki Pengembang Utama yang tidak kompeten dan Manajer Proyek yang tidak kompeten (setidaknya sampai pada taraf bahwa ia tidak dapat menilai keterampilan tim). Baik. Anda memiliki opsi yang sama persis dengan pengembang di setiap tim di mana pun di dunia.

1. Apakah Anda bekerja tanpa memperhatikan kesehatan perusahaan.

2. Cari pekerjaan di tempat lain.

3. Buat saran yang masuk akal kepada Pimpinan, PM, dan Pemilik dan harap mereka diadopsi.

Anda bebas melakukan kombinasi di atas secara bersamaan.

Jika Anda ingin secara agresif memastikan kesehatan proyek, Anda harus bekerja dengan pengembang lain untuk membuat kerangka kerja baru di waktu luang Anda dan menunjukkan kepada seluruh tim mengapa itu lebih unggul dan pekerjaan lama harus dibuang demi itu.

Saya bekerja dalam situasi yang sama, di mana pengembang utama yang sebenarnya adalah mitra di perusahaan telah menciptakan "inti" dari perangkat lunak dan dengan pengecualian seorang teman dekat yang bekerja secara langsung dengannya, pengembang lain tidak diizinkan untuk menyentuh inti.

"Kekuatan yang ada" juga membuat aturan seperti setiap modul hanya dapat memiliki satu tabel database, karena lebih bersih seperti itu. Dan akibatnya, drop down yang ada dibuat dengan memilih "DISTINCT" dari tabel dalam database, daripada memiliki tabel terpisah.

Ada sejumlah tambalan buruk melayang karena tim pelaksana harus menyelesaikan pekerjaan, dan produk tidak akan berfungsi di luar kotak. Tambalan ini menyebabkan banyak masalah saat mereka diperbaiki dan dikustomisasi (diretas) untuk setiap pemasangan.

Pendekatan saya adalah mengambil satu bagian kecil dari spesifikasi yang tidak didukung inti dan menulis tambalan kecil, bagus, dan generik untuknya. Sesuatu yang memuaskan tim implementasi, tetapi tidak seancam seperti "Kita perlu mengubah pemikiran kita sepenuhnya". Karena permusuhan antara tim implementasi dan pengembang inti, butuh berbulan-bulan untuk meyakinkan tim implementasi bahwa pendekatan saya lebih baik daripada retas mereka. Tetapi begitu mereka melihat bahwa saya akan mendengarkan mereka dan menerapkan penyesuaian tambahan untuk mendukung mereka, mereka senang dan berada di pihak saya. Butuh satu bulan lagi bagi pengembang utama untuk menerima tambalan itu, tetapi begitu dia melakukannya, itu benar-benar membuka komunikasi di antara kita semua tentang cara-cara yang lebih baik untuk merancang bagian lain dari sistem.

Tidak pernah ada jalan pendek untuk mengubah pemikiran orang, terutama jika Anda perlu menjaga hubungan sipil dengan mereka. Tetapi jika Anda mendekatinya dengan benar, Anda bisa mendapatkan rasa hormat tanpa menghina bos Anda.

Semoga itu bisa membantu!

Jawaban dan solusi yang sangat sederhana. Tampaknya semua orang menyadari masalah ini. Dengan demikian, Anda berkeliling menunjukkan masalah tidak ada nilainya bagi siapa pun. Bahkan itu hanya membuat Anda terlihat seperti pelacur. Jika Anda ingin menambah nilai maka Anda perlu menunjukkan solusinya dan membangun kasus bisnis untuk berubah menjadi solusi Anda. Kemudian Anda bisa menunjukkan masalah dengan solusi yang sesuai. Demo juga akan sangat membantu dalam membuktikan solusi Anda. Tentu saja, ini mungkin berarti melakukan pekerjaan pada waktu Anda sendiri, tetapi itu semua tergantung pada seberapa pentingnya Anda juga.

Pertama-tama, saya sangat menyarankan agar Anda memastikan fakta bahwa ini adalah masalah arsitektur aplikasi dan bukan sesuatu dalam konfigurasi VPN. Saya telah melihat VPN yang dikonfigurasi dengan buruk menyebabkan masalah ini. Apakah Anda tahu pasti bahwa aplikasinya lambat di dalam kantor?

Jika Anda telah mengesampingkan jaringan, saya akan pergi dengan saran KiethS dan meminta PM menarik halaman.

Kedengarannya seperti bisnis, atau setidaknya proyek akan segera bangkrut. Tanpa berhenti, saya akan mencoba menjauhkan diri dari itu secepat mungkin misalnya. relawan / meminta pekerjaan pada proyek lain yang sedang berjalan. Semoga seiring waktu, Anda akan menghabiskan lebih sedikit waktu untuk bencana ini, dan lebih banyak pada proyek-proyek lain yang memiliki peluang untuk bekerja. Anda tidak ingin dianggap sebagai 'orang yang bekerja pada proyek yang tidak berhasil'. Ini semua tentang melindungi reputasi Anda.

Apakah pemilik menginginkan produk yang bagus atau tidak? Saya sangat curiga bahwa jawabannya adalah "Ya" ... dan karena itu, Anda perlu berbicara. Anda perlu mendokumentasikan arsitektur saat ini dan kemudian (dengan data imperial yang baik), tunjukkan bagaimana produk tidak memenuhi harapan kinerja yang tepat. Anda mengatakan bahwa rekan kerja Anda semua tahu kinerjanya buruk - baik ... bagaimana dengan pelanggan? Apa yang mereka katakan? Gunakan alat pengukuran kinerja dan tentukan apa yang perlu waktu lama. Banyak alat bahkan akan turun untuk menunjukkan kepada Anda berapa lama setiap panggilan fungsi berlangsung. Dari semua data ini, Anda harus memiliki cukup amunisi untuk berbicara dengan manajer proyek Anda dan pimpinan teknis tentang mengapa segala sesuatunya tidak seperti yang seharusnya dan bagaimana beberapa refactoring besar mungkin diperlukan untuk mempercepat kecepatan produk.

Kemudian (hanya setelah berbicara dengan PM dan memimpin), ini HARUS cukup untuk mulai membuat beberapa perubahan. Jika PM tidak yakin pada saat itu, maka Anda perlu memutuskan apakah ini benar-benar tempat yang Anda inginkan. Jika demikian, maka mungkin pertemuan dengan pemilik. Jika tidak, siapkan resume itu.

Pastikan Anda mendokumentasikan setiap langkah di setiap langkah.

Dalam istilah teknis saya setuju dengan saran di atas. Di sisi lain, saya merasa itu lebih seperti masalah hubungan daripada masalah teknis.

Jika Anda ingin mengambil rute yang mulus, berbicara dengan pengembang utama akan menjadi pilihan yang cocok. Saya tidak akan berbicara di kantor. Minum kopi di luar akan membuat hal-hal sedikit informal dan lebih santai.

Jika itu tidak berhasil, Anda dapat mencoba berbicara dengan PM dan kemudian pemiliknya.

Jika tidak ada yang berhasil, saya sarankan Anda mencari pekerjaan baru.

Kejujuran - dan sebanyak mungkin kebijaksanaan yang bisa Anda kumpulkan.

Mulailah dengan pengembang utama dan tingkatkan langkah Anda jika perlu. Cobalah untuk melibatkan sisi yang lebih baik dari kepribadian mereka - Jika Anda memimpin dev suka menyelesaikan masalah / suka menyelamatkan hari / suka menjadi efisien / dll. Frase masalah dalam hal itu - Tidak ada salahnya untuk menunjukkan contoh di mana mereka telah sukses di masa lalu sebagai motivasi tambahan.

Jika Anda tidak membuat beberapa gelombang Anda mungkin mati di dalam air.

Apakah mungkin untuk membawa masalah kembali ke tingkat yang dapat diukur dan secara non-teknis sehingga manajer proyek dan pemilik dapat memahami.

Sebagai contoh, Anda menyebutkan waktu buka lambat selama 3+ menit, saya akan berasumsi bahwa ada persyaratan kinerja di suatu tempat dalam spesifikasi, sesuatu yang sederhana seperti "halaman yang akan dimuat dalam 1sec". Sesuatu seperti ini bisa diukur dan tidak bisa disangkal. Jika akar penyebab masalah ini ditemukan adalah arsitektur yang cerdik, maka manajer proyek dan / atau pemilik harus melangkah untuk memaksa beberapa perubahan.

Jika tidak, maka Anda memiliki masalah sistematis di perusahaan Anda di mana analisis awal dilakukan dengan buruk dan tidak ada cukup proses untuk menangkap jenis masalah ini. Pertimbangkan untuk melompat kapal!

Pria sejati berbicara tanpa dendam atau emosi. Itulah triknya.

Satu-satunya alasan yang sah seseorang mungkin marah dengan Anda untuk berbicara, adalah jika Anda merasa sebal:

THE LEAD DEVELOPER TIDAK PUNYA PETUNJUK APA YANG DIA LAKUKAN. Saya tahu ini akan terjadi, tetapi tidak ada yang mendengarkan saya, bla bla.

dimana sebagai

Model kode salah karena sulit untuk mempertahankan dan memperlambat. Kita harus strategis tentang langkah maju ini, dan memperbaiki dua masalah ini.

Yang pertama adalah pertempuran untuk dihancurkan, yang terakhir adalah pertempuran untuk perdamaian, dan dalam jangka panjang akan mengumpulkan Anda rasa hormat yang didapat seseorang karena jujur.

Jika pemimpin proyek menganggap ini sebagai penghinaan, yang tentu saja mungkin mempertimbangkan untuk dipecat, maka katakan saja,

Jangan menganggap saya bertanggung jawab atas hal-hal yang saya tidak bertanggung jawab untuk implementasi. Saya hanya jujur.