Manajer terus mengubah spesifikasi kebutuhan setelah setiap demo [ditutup]

Latar belakang lingkungan kerja saya

Manajer saya tidak memiliki latar belakang atau pemahaman tentang komputer atau perangkat lunak apa pun. Sangat mungkin dia belum melihat kode dalam bentuk apa pun (bahkan dari jarak fisik 10 kaki atau kurang) dalam hidupnya.

Tidak ada orang yang mengerti kompleksitas dari apa yang saya minta untuk implementasikan. Sampai-sampai kalau saya semi-hardcode tidak ada yang akan tahu.

Pada tes Joel kami mencetak skor luar biasa 0.

Masalah

• Manajer dan terkadang "senior" lainnya terus mengubah spesifikasi kebutuhan. Perubahan yang, jika rekayasa yang baik dilakukan dan tidak "perbaikan" yang tambal sulam, membutuhkan perubahan dalam desain yang mendasarinya.
• Sama sekali tidak ada orang yang melihat kode (mungkin karena tidak ada yang tahu bagaimana melakukannya, atau bahkan jika itu harus dilakukan) yang berarti tidak akan ada yang bisa:
  • Hargai kompleksitas masalah atau keanggunan solusi.
  • Sarankan peningkatan pendekatan.
  • Hargai kualitas kode.
  • Tunjukkan di mana kode dapat ditingkatkan.
• Banyak jargon digunakan yang masuk akal secara gramatikal tetapi gagal untuk masuk akal dengan cara lain.
• Tidak merasa, berperilaku atau bekerja seperti perusahaan perangkat lunak.

Pertanyaan

Apa yang harus dilakukan? Terutama mengenai tidak ada orang yang akan menunjukkan perbaikan dalam kode saya.

Memperbarui

Untuk menjawab pertanyaan HLGEM (dan mungkin orang lain) tentang apa yang telah saya lakukan untuk mencoba dan memperbaikinya. Saya menawarkan untuk mengatur Redmine dan memperkenalkan kontrol sumber kepada semua orang. Saya katakan saya akan merekomendasikan didistribusikan (git atau lincah) tetapi juga akan berbicara tentang yang terpusat dan membiarkan tim memutuskan. Responsnya adalah bahwa segala sesuatu sedang dilakukan dan akan dilakukan dalam beberapa minggu. Saya belum pernah melihatnya dan saya juga tidak tahu apakah ada perusahaan lain yang menggunakannya.

Versi singkat :

Menjalankan.

Versi yang agak panjang :

Jika manajer tidak tahu bagaimana menjalankan suatu proyek, dan jika senior menyertainya, maka Anda tidak memiliki kesempatan untuk memperbaiki keadaan.

Untuk mengelola proyek perangkat lunak, seorang manajer perlu memahami sesuatu tentang perangkat lunak. Jika manajer tidak, mereka perlu belajar dulu. Apa peluang Anda sehingga Anda bisa meyakinkan manajemen dan senior Anda bahwa mereka semua salah? Apa kemungkinan Anda akan mengajari mereka sesuatu?

Saya pernah berada dalam situasi yang sama sekali (hanya saja tidak ada senior). Saya berhenti setelah tahun yang mengerikan, dan tidak pernah melihat ke belakang (kecuali dengan jijik).

... terus mengubah spesifikasi kebutuhan. Perubahan yang, jika rekayasa yang baik dilakukan dan tidak "perbaikan" yang tambal sulam, membutuhkan perubahan dalam desain yang mendasarinya.

Kedengarannya seperti dunia nyata. Ini terjadi setiap saat, di mana-mana. Ya itu menyebalkan, tapi lumayan dengan sikap tangkas. Selain itu, salah satu ukuran kebaikan perangkat lunak adalah sifat lunaknya. Anggap itu sebagai tantangan.

Banyak jargon digunakan yang masuk akal secara gramatikal tetapi gagal untuk masuk akal dengan cara lain.

Sekali lagi, tidak terdengar terlalu asing ;-)

Tidak ada orang yang mengerti kompleksitas dari apa yang saya minta untuk implementasikan.

Bahkan kamu? Jika Anda mengerti itu, maka ada satu orang di cermin yang mengerti itu. Jadi, tanggung jawab Anda terhadap kesejahteraan perusahaan Anda mungkin lebih berat daripada yang disarankan jabatan formal Anda. Jika Anda benar-benar memahami masalah dan manajer Anda tidak, maka Anda bertanggung jawab untuk menjelaskan semuanya kepada manajemen sehingga mereka dapat mengarahkan perusahaan dengan semestinya. Mungkin masuk akal untuk mengasumsikan bahwa manajer terdekat Anda harus kompeten secara teknis (tidak harus sama kompetennya dengan Anda - selagi mereka manajer, Anda adalah ahli - tetapi setidaknya sedikit kompeten), tetapi jika mereka jelas tidak kompeten, dan Anda bisa membantu mereka, kenapa tidak?

Solusi pelarian sederhana adalah beralih perusahaan. Tetapi sebagai pilihan lain, pertimbangkan untuk mengimplementasikan item tes Joel. Meskipun item dari 5 pada membutuhkan lebih banyak kerjasama dengan manajemen, item 1-4 adalah sedemikian rupa sehingga Anda bisa mengaturnya tanpa bertanya kepada siapa pun.

Yang mengatakan, tidak ada seorang pun di sini di SE yang bisa mengetahui situasi Anda yang sebenarnya. Mungkin saja Anda berada di sebuah perusahaan yang penuh sesak oleh para brengsek yang tidak kompeten, dan membuat sesuatu yang baik dari kekacauan seperti itu bisa terlalu banyak bagi siapa pun. Anda harus menilai sendiri situasinya.

Anda mengatakan di salah satu komentar bahwa ini adalah pekerjaan pertama Anda. Manajer sering tidak teknis di mana pun kecuali toko perangkat lunak khusus dalam pengalaman saya. Ini adalah bagian dari kehidupan, biasakan saja.

Anda menangis dan merengek karena tidak ada yang menghargai keanggunan solusi Anda. Masalah sebenarnya di sini bukanlah bahwa tidak ada orang yang menghargai keanggunan solusi Anda, tetapi tidak ada yang mengajarkan Anda bahwa solusi Anda tidak sebagus yang Anda kira. Hampir semua programmer baru melebih-lebihkan keterampilan mereka yang sebenarnya. Tanpa mentor, tidak ada orang yang membantu Anda berlatih lebih baik. Jika tidak ada seorang pun di sana yang membimbing Anda, maka bergabunglah dengan grup pengguna lokal, berpartisipasi aktif, dan ajak seseorang ke sana untuk membimbing Anda. Bahkan lebih baik, itu akan membantu Anda menemukan pekerjaan yang lebih baik pada akhirnya.

Anda mendapat angka nol pada tes Joel? Jika Anda adalah satu-satunya pembuat kode (dan kedengarannya dari apa yang Anda tulis adalah Anda) mereka mengapa Anda tidak menggunakan kontrol sumber? Apa yang mencegah Anda? Jika Anda bukan satu-satunya pembuat kode, mengapa tidak ada orang yang dapat melakukan tinjauan kode? Semua pengembang kami melakukan review kode, itu bukan fungsi manajemen terutama ketika manajer non-teknis.

Persyaratan berubah di hampir semua tempat. Kebutuhan bisnis berubah terus-menerus dan yang bukan pemrogram sering kali tidak dapat memvisualisasikan apa yang akan dilakukan program sampai mereka menemukan sesuatu. Kemudian mereka menyadari itu bukan yang mereka butuhkan. Itu sebabnya Agile muncul benar-benar karena metode yang lebih tua tidak menangani perubahan itu dengan baik.

Siapkan pelacakan bug bahkan jika manajemen tidak ingin memasukkan data sendiri. Bertanggung jawab untuk memasukkan bug / fitur baru ketika seseorang menyebutkannya kepada Anda. Sangat membantu untuk dapat memberi tahu manajer ketika dia menginginkan perubahan bahwa Anda telah diberi 27 hal lain dan di sini adalah daftar, mana yang Anda ingin saya pindahkan ke daftar prioritas untuk mengakomodasi perubahan baru ini. Ini akan membantu pada waktu peninjauan karena Anda akan dapat menghitung jumlah perbaikan bug dan fitur yang Anda implementasikan. Jika semua orang tidak menggunakannya, setidaknya Anda bisa untuk pekerjaan Anda sendiri. Jika mereka tidak mengizinkan Anda menginstal perangkat lunak apa pun, gunakan spreadsheet Excel. Ambil inisiatif. Setelah Anda dapat menunjukkan hasil, orang lain akan lebih tertarik. Jika Anda berpikir ada terlalu banyak pekerjaan untuk satu orang, pelacak bug akan membantu Anda membuktikannya.

Jangan memprovokasi demo mencari dipoles! Demo harus terlihat seolah-olah dituliskan dalam pena di selembar kertas. Semakin halus tampilan antarmuka, semakin banyak orang non-teknis berpikir itu selesai.

Meskipun tidak ada yang akan tahu jika Anda tidak mengikuti praktik terbaik dan kode semi_hard misalnya, Anda akan tahu dan Anda akan menjadi kebiasaan buruk yang ceroboh. Itu tidak akan membantu Anda dengan baik dalam pekerjaan Anda berikutnya. Jadi lakukan hal-hal yang sedekat mungkin dengan cara yang Anda bisa lakukan dalam situasi seperti itu. Pastikan untuk menulis tes (anggap saja ini sebagai bagian dari waktu pengembangan dan luangkan waktu untuk melakukannya dalam estimasi yang Anda berikan kepada manajemen bahkan jika Anda tidak secara spesifik mengatakan bahwa itu adalah bagian dari estimasi) dan gunakan tes tersebut untuk memastikan perubahan selanjutnya tidak merusak sesuatu yang lain.

Anda perlu melihat ini sebagai kesempatan yang tak ternilai untuk tumbuh dan berkembang. Anda memiliki lebih banyak kebebasan dalam pengkodean aktual daripada yang dimiliki banyak orang pada tahap karier Anda. Jadi pertimbangkan ini kesempatan untuk membuat portofolio proyek yang berhasil dilaksanakan. Ketika Anda mencari pekerjaan berikutnya, bisa menunjukkan pencapaian seperti kontrol sumber yang dilembagakan, pelacakan bug yang dilembagakan, menciptakan sejumlah X implementasi proyek yang sukses, dll, akan membuat Anda menonjol dari yang lain.

Anda juga memiliki peluang besar di sini untuk mempelajari cara mengelola harapan ke atas. Ini adalah askill yang akan berguna selama sisa karir Anda. Anda tidak akan rugi dalam mencoba melakukan ini di sini, semuanya sudah tidak baik. Tetapi Anda dapat mempelajari keterampilan politik yang akan membantu Anda di tempat yang lebih baik nanti. Belajarlah untuk melakukan analisis biaya-manfaat. Belajarlah untuk menggarisbawahi domain bisnis sehingga Anda dapat meyakinkan ketika Anda berbicara dengan mereka. Belajarlah berbicara dalam hal keuntungan bagi perusahaan dan keuntungan. Lakukan estimasi untuk setiap tugas yang ditugaskan kepada Anda dan bahkan jika mereka tidak cocok dengan apa yang manajemen berikan kepada Anda, catatlah apa yang Anda perkirakan dan apa yang sebenarnya dibutuhkan untuk meningkatkan kemampuan Anda sendiri dalam memperkirakan pekerjaan. Setelah Anda dapat menunjukkan bahwa perkiraan Anda secara historis lebih akurat daripada estimasi manajemen, mereka akan lebih cenderung mendengarkan ketika Anda memberi tahu mereka bahwa perkiraannya terlalu rendah. Tetapi Anda harus membangun rekam jejak pertama dari kedua estimasi yang lebih akurat dan yang paling penting, kemampuan untuk memberikan proyek dan membuatnya bekerja. Sekali lagi ini adalah keterampilan yang baik untuk dimiliki saat Anda bergerak maju dalam karier.

Yang terpenting, jangan pasif dan mengharapkan peningkatan datang dari atas.

Jika saya jadi Anda, saya akan mencoba mencari pekerjaan lain. Mengapa? Saya pikir Anda tahu bahwa, sayangnya, manajer Anda, "tidak baik". Anda harus mencoba menyelesaikan beberapa hal dengan manajer Anda.

Jika Anda tidak ingin pergi, dan / atau Anda tidak akan berbicara dengan siapa pun, maka Anda harus menemukan sesuatu sendiri. Jika tidak ada seorang pun di perusahaan yang tahu tentang kode Anda, bagaimana manajer Anda seharusnya tahu Anda memenuhi persyaratan? Hanya mengatakan.

Bicaralah dengan manajer Anda dan para senior tentang hal ini. Jelaskan masalah Anda dan sarankan solusi. Persiapkan pembicaraan sedikit sehingga Anda tahu pesan umum yang ingin Anda sampaikan.

Setelah bicara, berikan waktu . Lihat apakah semuanya berubah atau tidak. Jika tidak, cobalah untuk menerapkan perubahan sendiri dan tunjukkan kepada manajer dan senior hasil positif dari perubahan Anda .

Jika pembicaraan tidak membantu dan perubahan Anda diberhentikan, Anda harus mengevaluasi sendiri seberapa besar Anda ingin bekerja di tempat itu. Ya, pekerjaannya mungkin buruk, tetapi mungkin bayarannya bagus dan Anda hanya memiliki perjalanan 5 menit? Apakah aspek positif dari pekerjaan Anda lebih penting daripada yang negatif? Jika tidak, saya akan mulai mencari pekerjaan baru.

Masalah Anda adalah bahwa sistem tiket dan kontrol versi adalah masalah TEKNIS dan Anda harus melakukan ini terlepas dari input manajer non-teknis. Ini harus dianggap sebagai praktik terbaik secara teknis dan jika mereka tidak memiliki pengaturan ini maka Anda harus melakukannya sendiri untuk mewujudkannya.

Anda tidak dapat mengharapkan manajer non-teknis untuk memahami manfaat pelacakan cacat, kontrol sumber, dan integrasi berkelanjutan. Inilah sebabnya mereka non-teknis, mereka tidak seharusnya tahu atau peduli tentang itu, mereka adalah ahli domain dan pengetahuan bisnis. Satu-satunya hal yang harus mereka sediakan adalah arahan dan persyaratan tingkat tinggi.

Saya memiliki manajer non-teknis juga dan dapat meningkatkan skor Tes Joel dari 4 menjadi 8 hanya karena saya pergi dan melakukannya dan tidak meminta izin.

Grup Anda membutuhkan pemimpin teknis yang kuat dan tidak ada yang naik ke piring.

Lihat http://community.rallydev.com/ mereka memiliki edisi komunitas yang melakukan pekerjaan yang sangat baik dalam manajemen proyek Agile dan pelacakan Cacat. Itu saja akan meningkatkan skor Joel Anda dan Anda tidak perlu ruang server atau waktu sama sekali untuk menyiapkannya.

Jika ini adalah toko kecil tempat Anda dan "senior" lainnya pada dasarnya adalah satu-satunya orang yang melakukan pengkodean, maka sebenarnya Anda bertanggung jawab untuk menunjukkan kepada manajer apa yang perlu dilakukan untuk memenuhi "Tes Joel".

Perubahan persyaratan akan selalu ada, dan tugas Anda adalah merangkulnya, yang merupakan salah satu prinsip dasar pengembangan tangkas :

Selamat datang perubahan persyaratan, bahkan terlambat dalam pengembangan. Proses tangkas memanfaatkan perubahan untuk keunggulan kompetitif pelanggan.

Tetapi beradaptasi dengan perubahan persyaratan berarti mengikuti prinsip gesit lainnya juga. Pada tingkat manajemen, ini berarti manajer harus dapat secara transparan menyampaikan kepada pelanggan bahwa semua perubahan tersebut menimbulkan biaya: apakah ruang lingkup proyek harus diubah untuk memenuhi tenggat waktu, atau tenggat waktu harus digeser (yang terakhir tidak direkomendasikan).

Jika ini adalah semacam proyek di mana manajer Anda adalah orang yang datang dengan semua persyaratan, maka Anda harus bertindak seolah-olah dia adalah pelanggan tangkas Anda, dan menjelaskan hal yang sama kepada mereka (ruang lingkup <--> kompromi tenggat waktu ).

Tetapi pada tingkat pengembang di sebuah perusahaan kecil, saya akan mengatakan bahwa itu adalah tanggung jawab Anda adalah untuk memastikan bahwa bagian pengkodean sesuai dengan rekomendasi tangkas.

Ini adalah beberapa langkah yang benar - benar perlu Anda lakukan, dan mungkin Anda harus melakukannya sendiri:

• Anda harus memiliki sistem kontrol versi (membutuhkan satu hari untuk mengaturnya untuk tim kecil)
• Anda harus membuat skrip untuk memastikan bahwa Anda dapat membuat rilis sesering mungkin (cukup cepat untuk mengaturnya)
• Anda harus menggunakan tes unit otomatis (ini adalah cara pengkodean, dan ini menentukan seluruh desain Anda secara radikal, sehingga mungkin sulit untuk menambahkannya di tengah-tengah proyek yang digabungkan secara ketat)
• Anda juga dapat mengatur sistem integrasi berkelanjutan untuk memastikan build dan tes otomatis, serta tes fungsional dan GUI (yang sedikit lebih sulit untuk ditulis)

Ingatlah bahwa Anda dapat memiliki repositori SVN secara lokal di mesin Anda sendiri. Daftar TODO sederhana mungkin berfungsi sebagai sistem pelacakan bug orang miskin (agak ekstrem, tapi hei). Dan tidak ada alasan untuk tidak membangun skrip.

Juga, sebelum membuat pernyataan tentang kompromi ruang lingkup / tenggat waktu, seseorang juga perlu membuat prediksi tentang berapa lama waktu yang dibutuhkan fitur tertentu. Ini biasanya dilakukan dalam "hari ideal" di dunia yang gesit, yang berarti Anda harus melakukan yang terbaik untuk memprediksi upaya relatif dari setiap fitur, dan kemudian menggunakan kecepatan koding Anda yang sebenarnya untuk melihat seberapa baik Anda memprediksi (dan skala "kurva" sesuai ).

Saya pikir ada lapisan tanggung jawab yang hilang di tim Anda. Harus ada manajer proyek, analis sistem, analis bisnis, dan pengembang. Peran Manajer Proyek bertanggung jawab untuk mendefinisikan dan menegakkan strategi komunikasi proyek-pelanggan (di antara tugas-tugas lain).

Manajer tidak diharuskan memahami kode atau kompleksitas. Kebutuhan untuk memahami, sumber daya, biaya dan risiko.

Versi kode sumber, kualitas kode, kompleksitas, dll. Merupakan tanggung jawab PM atau Pengembang Senior.

Solusi adalah untuk:

1-Tentukan struktur tim proyek dan tanggung jawabnya

2-Didik manajer jika terjadi kegagalan perangkat lunak yang menyebabkan manajemen buruk - Jauhi detail teknis. Anda dapat menemukan beberapa contoh dengan googling.

Terutama mengenai tidak ada orang yang akan menunjukkan perbaikan dalam kode saya.

Tidak bisakah Anda mencoba mengatur ulasan kode sehingga ada orang yang melihat kode itu? Apakah ada konvensi dan standar yang akan membantu memberi kode beberapa struktur? Ini anggap Anda bukan satu-satunya pengembang di sana tentu saja.

Meskipun Anda mungkin berada di tempat yang kurang bagus, apakah kelihatannya ia bekerja pada akhirnya? Apakah proyek sedang dikerjakan dan segala sesuatunya bergerak maju? Apakah semuanya sudah selesai? Programmer Lakban akan menjadi artikel Joel yang mungkin ingin Anda baca.

Opsi 1 - beri tahu mereka 'dengan semua perubahan yang Anda lakukan pada proyek ini, pada saat kami menyebarkannya, sistem akan berjalan sangat lambat' atau 'pelanggan tidak akan dapat mengetahuinya'. Manajer Anda tidak peduli dengan kode spageti tetapi mereka peduli dengan pelanggan. Kendurkan masalahnya kepada mereka dalam hal apa yang mereka pahami, bukan dalam hal penulisan kode.

Opsi 2 - beri mereka apa yang mereka inginkan. Ketika mereka mengeluh tentang sesuatu yang Anda katakan 'tapi itu yang Anda minta'