Manajer terus mengubah spesifikasi kebutuhan setelah setiap demo [ditutup]


21

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.


36
untuk mendapatkan jawaban yang jelas: LARI !!
keppla

3
Kecuali ada sesuatu yang utama, Anda tidak memberi tahu kami untuk mulai mencari pekerjaan baru.
Zachary K

11
"Manajer dan terkadang" senior "lainnya terus mengubah spesifikasi kebutuhan." Nah, memiliki spec akan memberi Anda skor 1 pada tes Joel. : P
R. Martinho Fernandes

11
Tidak ada skor organisasi kurang dari 2 pada Tes Joel murni karena manajer non-teknis. Ada beberapa hal yang dapat Anda dan anggota teknis lainnya tim lakukan tanpa masukan dari manajer non-teknis untuk meningkatkan skor Anda. Anda tidak punya alasan untuk menyalahkan itu semata-mata pada manajer.
maple_shaft

6
Sepertinya Anda memiliki tim penjualan sebagai manajemen perangkat lunak juga, saya bersimpati.
wildpeaks

Jawaban:


30

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).


3
+1 untuk kutipan ini: "Jika manajer tidak tahu cara menjalankan program, dan jika senior menyertainya, maka Anda tidak memiliki kesempatan untuk memperbaiki hal-hal."
maple_shaft

17

... 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.


Bagaimana dengan seseorang yang menunjukkan kesalahan saya? Membantu saya meningkat dan belajar.
Jungle Hunter

4
@Jungle Hunter: Tentu saja akan lebih mudah untuk berada di perusahaan di mana semuanya telah siap, semua orang sudah mengikuti setiap praktik terbaik yang bisa dibayangkan, dll. Sehingga Anda bisa menjadi pekerja magang dan meniru orang lain. Tetapi Anda juga dapat meningkatkan dan belajar banyak dengan mengambil tanggung jawab dan menjadi diri sendiri aktif dalam meningkatkan perusahaan Anda. Meningkatkan dan belajar pada akhirnya ada di tangan Anda sendiri. Orang lain dapat membantu, tetapi bos Anda tidak harus menjadi salah satu dari mereka.
Joonas Pulakka

Ya kamu benar Saya berusaha untuk meningkatkan tetapi usaha saya saya pikir terlihat lebih banyak mengeluh daripada upaya untuk meningkatkan. Sejujurnya usaha saya sama-sama, tapi mari kita lihat apakah saya bisa membuat mereka melihat paruh kedua - upaya untuk meningkatkan.
Jungle Hunter

@Jungle Hunter: Begitu, garis antara mengeluh dan meningkatkan bisa kabur . Tetapi tidak ada salahnya untuk bersandar ke sisi konstruktif.
Joonas Pulakka

4
@Joonas: Saya telah berada di perusahaan tempat saya memperkenalkan VCS, ulasan kode, memberikan seminar C ++, dan yang lainnya, untuk meningkatkan kualitas kode. Dan saya telah berada di sebuah perusahaan seperti yang dijelaskan OP. Jika ini adalah kasus tanpa harapan, Anda harus mengakui kekalahan dan mencari pekerjaan di mana perjuangan Anda dihargai dengan membiarkan Anda berhasil.
sbi

16

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.


1
Jawaban ini memiliki bagian yang sangat berguna. Dan beberapa hal yang saya rasa salah tentang memahami situasi saya. Seperti, saya menyebutkan kedua kasus, tidak ada yang menghargai ketika itu baik. Tidak ada yang menunjukkan ketika saya salah. Saya menggunakan kontrol sumber, tetapi dalam tim 2-3 tidak ada orang lain yang melakukannya. Kode, saat dibagikan dibagikan menggunakan pendrives dan menggunakan Airdrop. Jika Anda membaca komentar saya pikir saya juga sudah menyebutkan saya sudah Redmine setup pada laptop saya yang akhirnya hanya digunakan oleh saya. Dan sama dengan git. Mencoba menerapkan ini untuk semua orang. Level saya, baru lulus kuliah. Senior seharusnya kode tetapi tidak.
Jungle Hunter

Saya akan mengambil saran tentang membangun rekam jejak. Saya akan ingat saya memiliki lebih banyak kebebasan di panggung saya daripada secara umum. Saya bisa belajar mengelola harapan dan keterampilan politik dan lunak lainnya.
Jungle Hunter

3
Berhenti memberi kode pada pendrives. Jika mereka menginginkan kode Anda, beri tahu mereka kode itu ada dalam kendali sumber dan tunjukkan kepada mereka cara menggunakannya.
Hugo

1
@JungleHunter Ketika mereka meminta kode Anda, beri tahu mereka bahwa perubahan Anda di tengah jalan tidak akan berjalan, tetapi mereka bisa mendapatkan versi stabil terakhir dari kontrol sumber.
Kirk Broadhurst

1
@HLGEM "Kamu menangis dan merengek"? Terlalu keras, tidak mendukung hal itu sendirian.
Ben H

6

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.


Dia hanya melihat demo. Katanya, mari kita ubah ini dengan cara ini dan itu ke cara itu. Dan kemudian ada banjir jargon.
Jungle Hunter

2
@ Jungle, saya hampir tidak akan melakukan pekerjaan apa pun dalam demo karena mereka pasti akan berubah dengan liar begitu dia melihat mereka. Dia terdengar seperti orang visual pertama dan terutama. Sudahkah Anda mencoba membuat cuplikan layar dari berbagai kasus penggunaan untuknya? Ini bisa menjadi jauh lebih mudah untuk disatukan daripada prototipe fungsional.
maple_shaft

@maple_shaft: Saya pikir itu ide yang bagus.
Jungle Hunter

1
@maple_shaft: Atau mungkin alih-alih memberikan banyak sebelumnya, pengiriman hanya menjelang akhir. ;)
Jungle Hunter

1
Saran pekerjaan dari seorang siswa sekolah menengah ...

4

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.


1
Saya berbicara. Saya menawarkan untuk membuat sistem tiket, kontrol versi memperkenalkan tetapi dia tidak peduli. Atau mengerti. Atau keduanya. Saya sudah bertanya berbicara dengannya tentang memiliki spesifikasi yang dapat diandalkan dan dia setuju. Meskipun demikian mengubahnya. Dia tidak didorong data. (Oh dan menghilangkan penekanan pada teks dari pertanyaan saya.)
Jungle Hunter

2
@Jungle: Lalu jalankan SECEPATNYA.
sbi

1
Saya setuju dengan sbi, jika Anda belum diminta untuk ditembak jatuh Anda bisa saja keluar dan melakukan ini sendiri. Anda telah kehilangan ruangan dan jika saya berada dalam situasi Anda, saya akan mulai mencari.
maple_shaft

3

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.


Iya nih! Itu saya pikir masalah utama. Kami tidak memiliki pemimpin teknis yang kuat.
Jungle Hunter

2

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 ).


Untuk "keunggulan kompetitif pelanggan" adalah kuncinya. Kemudian hari ini saya bertanya kepadanya mengapa dia melakukan ini, katanya, untuk mengesankan klien. : |
Jungle Hunter

Saya memiliki git / lincah di tempat untuk diri saya sendiri. Tapi saya melakukan pengujian secara manual sekarang. Saya harus memeriksa unit test otomatis.
Jungle Hunter

1

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.


"Tinggal jauh dari detail teknis." Saya akan mencoba melawan. ;) Terima kasih telah menunjukkannya.
Jungle Hunter

0

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.


Saya telah berpikir untuk mengubah tim saya menjadi tim yang memiliki orang-orang yang dapat melihat kode saya. Atau coba hubungi orang-orang di sana untuk meninjau kode saya. Seperti yang saya katakan di pertanyaan, saat ini tidak ada yang bisa melakukan itu.
Jungle Hunter

0

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'


Sebelum saya "lari" saya akan melakukan hal itu. Jika mereka ingin perubahan, saya akan memberi tahu mereka bahwa itu bukan perubahan kecil di sana-sini sehingga akan membutuhkan lebih banyak waktu. Ketika pelanggan tidak terdengar senang, mereka tidak akan mengeluh karena saya memberi mereka apa yang mereka inginkan.
Jungle Hunter

@jungle hunter - Tidak semua orang memiliki pilihan untuk berhenti dari pekerjaan mereka, kadang-kadang Anda harus mengatasi situasinya. Saya telah menemukan cara terbaik untuk menangani kegilaan adalah dengan mengembalikannya pada orang-orang gila. Hanya orang yang sangat gila yang bisa membantah kegilaan mereka sendiri. semoga berhasil.
jqa
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.