Bagaimana saya bisa mengadvokasi jadwal rilis semi-ketat dalam lingkungan yang menghindari risiko?

12

Baru-baru ini saya semakin terganggu oleh apa yang harus saya gambarkan sebagai salah satu pengalaman saya yang paling membuat frustrasi dan membunuh semangat dalam profesi ini: Harus duduk pada rilis yang telah diuji, diuji ulang, dipentaskan, dan untuk semua maksud dan tujuan siap dikirim / digunakan .

Sebagai seorang pria solusi menyeluruh dan bukan hanya seorang hardcore coder, saya mengerti dan bahkan menganjurkan perlunya kontrol perubahan yang tepat. Tetapi akhir-akhir ini, keseimbangan renggang antara menutupi pangkalan kami dan pengiriman tepat waktu telah berjalan miring, dan saya hampir tidak berhasil mengembalikannya ke sesuatu yang waras.

Saya mencari argumen yang meyakinkan untuk membantu meyakinkan manajemen yang tidak mau mengambil risiko bahwa:

  1. Tim pengembang harus (atau harus) dapat mengatur jadwal rilisnya sendiri - tentu saja (1-3 bulan harus cukup konservatif untuk semua kecuali perusahaan-perusahaan Fortune 500 terbesar);

  2. Rilis perangkat lunak adalah tonggak penting dan tidak boleh diperlakukan dengan berani; dengan kata lain, penundaan / penghentian yang tidak perlu sangat mengganggu dan harus dianggap hanya sebagai upaya terakhir untuk beberapa masalah bisnis kritis; dan

  3. Entitas eksternal (non-dev / non-IT) yang ingin (atau menuntut) untuk dilibatkan sebagai pemangku kepentingan memiliki tanggung jawab untuk bekerja sama dengan tim pengembang untuk memenuhi jadwal rilis, terutama dalam minggu terakhir ini sebelum kapal yang direncanakan tanggal (yaitu pengujian / pementasan pengguna).

Pernyataan di atas adalah pernyataan yang benar bagi saya berdasarkan pengalaman, tetapi sepertinya saya sekarang harus membuktikannya - jadi saya meminta sesuatu yang sedikit lebih mudah di sini, jika hal seperti itu ada.

Adakah yang harus "menjual" ide siklus rilis yang tetap (atau mungkin semi-fleksibel) kepada manajemen memberikan beberapa petunjuk tentang argumen / strategi apa yang efektif atau persuasif dan mana yang tidak? Selain dari pertentangan jadwal yang jelas dan biaya yang hangus, apakah ada data / bukti keras yang akan berguna dalam membuat kasus bahwa pengiriman sebenarnya penting, bahkan dalam pengaturan "perusahaan"?

Sebagai alternatif, saya terbuka untuk mendengarkan argumen konstruktif tentang mengapa fleksibilitas jadwal (bahkan selama beberapa minggu / bulan) lebih penting daripada pengiriman sesuai jadwal; sulit bagi saya untuk percaya sekarang, tetapi mungkin mereka tahu sesuatu yang tidak saya ketahui.

Catatan kami telah melakukan rilis, dan ini melewati setiap tahap kecuali produksi. Masalah dilacak menggunakan pelacak bug komersial dan setiap masalah - 100% dari mereka - yang ditugaskan untuk rilis ini ditutup. Saya menyadari itu sulit untuk dipercaya dan itulah intinya - tidak masuk akal bahwa 100%, fitur lengkap, sepenuhnya diuji, disetujui oleh pemangku kepentingan akan ditunda oleh manajemen untuk alasan yang tidak dijelaskan, tetapi itulah yang terjadi, itulah yang sedang terjadi, itulah masalah yang harus dipecahkan.

release release-management scheduling Aaronaught
sumber
Semoga berhasil. Sebagai pengembang di perusahaan sebelumnya, kami bertempur dari arah sebaliknya. Kami memiliki penyebaran karena keinginan karena bisnis membutuhkan perbaikan bug dan peningkatan "segera". Saya berharap yang terbaik dalam usaha Anda.
TheDevOpsGuru
Apakah manajemen Anda pernah mempelajari biaya peluang untuk menunggu rilis?
chrisaycock
@ chrisaycock: Saya ragu mereka telah mempelajari atau benar-benar memahami biaya peluang dari sudut manapun . Namun, hanya mengatakan ungkapan "biaya peluang" tidak akan mempengaruhi siapa pun; Saya perlu sesuatu yang spesifik untuk ditunjukkan.
Aaronaught
Mengapa Anda tidak dapat mulai bekerja pada versi perangkat lunak Anda yang berikutnya sambil menunggu yang sekarang dirilis?
krlmlr
@ user946850: Secara teori saya bisa. Itu tidak mengubah apa pun yang dikatakan dalam pertanyaan ini. Itu tidak meniadakan efek demoralisasi dari tangan seseorang diikat dan bekerja pada sesuatu yang tidak akan dilepaskan, atau efek yang sangat mengganggu dari berurusan dengan rilis pertengahan siklus.
Aaronaught

Jawaban:

7

Joel Spolsky mengatakan bahwa tim pengembangan perangkat lunak adalah skema untuk mengubah modal (uang) menjadi perangkat lunak yang berfungsi. Jujur, dari pertanyaan Anda, sepertinya tim Anda ahli dalam hal itu: Anda mendapatkan perangkat lunak yang layak untuk jumlah uang yang diinvestasikan.

Sekarang, tentu saja langkah selanjutnya adalah menempatkan perangkat lunak ke dalam layanan. Sampai perusahaan Anda memilih untuk melakukan itu, tidak ada cara bagi mereka untuk memanen pengembalian investasi modal mereka. Perangkat lunak yang ada di rak yang siap digunakan adalah jenis inventaris yang serupa di ruang stok: biayanya hangus, uang modal perusahaan sudah dihabiskan. Ada juga biaya peluang: grup Anda memilih untuk melakukan proyek ini daripada yang lain.

Terlebih lagi, nilai dari perangkat lunak yang baru dikembangkan di rak adalah seperti nilai dari sepiring keju yang berada di lemari es restoran: Perlahan-lahan membusuk. Nilainya menurun karena pesaing Anda mengejar ketinggalan. Ini juga menurun karena semakin sulit dan berisiko untuk menempatkan perangkat lunak baru ke dalam layanan sebagai pengembangnya beralih ke hal-hal lain. Setelah beberapa tahun di rak, itu mungkin sebenarnya tidak berharga. Dalam hal ini, perusahaan Anda telah memilih untuk membuang modal yang mereka investasikan dalam mengembangkannya. Mungkin saja pemilik perusahaan - pemegang saham - akan tidak senang dengan hal ini.

Ada satu hal yang Anda, sebagai pengembang, harus cari tahu. Apakah perangkat lunak Anda benar-benar, benar-benar, siap digunakan pada akhir siklus rilis yang Anda usulkan? Apakah sudah siap untuk pergi, atau ada banyak pekerjaan yang harus dilakukan dan uang untuk dibelanjakan ketika perusahaan Anda memasukkannya ke dalam produksi? Apakah perusahaan Anda memiliki lisensi server dan perangkat lunak yang Anda perlukan untuk meluncurkan perangkat lunak Anda? Apakah produk kerja Anda menyertakan paket penerapan? Sudahkah pengguna akhir dilatih? Apakah data produksi telah dikonversi? Jika perangkat lunak baru Anda melibatkan perubahan cara perusahaan Anda melakukan bisnis, apakah perusahaan siap untuk melakukan perubahan itu? Sudahkah Anda membuat skema untuk menjalankan berbagai hal secara paralel, untuk memastikan barang baru berfungsi sebaik barang lama?

Semua biaya peluncuran dapat dengan mudah mengecilkan biaya hanya mengembangkan perangkat lunak. Tim manajemen proyek yang bijak melakukan yang terbaik untuk merencanakan, menganggarkan, dan menjadwalkan semua hal itu. Sudahkah Anda melakukan pekerjaan itu? Sudahkah Anda menjelaskannya kepada manajemen? Jika tidak, mungkin mereka bijaksana untuk memperlambat peluncuran Anda.

Mungkin saja jadwal peluncuran perangkat lunak gesit modern tidak selaras dengan kecepatan perubahan yang diharapkan perusahaan Anda. Pengguna akhir Anda - pemangku kepentingan Anda - mungkin tidak dapat menyerap perubahan pada tingkat yang dapat dihasilkan oleh tim Anda.

Mungkin juga tim manajemen Anda tidak berfungsi. Apakah tim Anda mengembangkan sesuatu yang tidak diinginkan oleh perusahaan lain? Apakah barang baru Anda mengancam tim penjualan atau produksi Anda? Jika demikian, beberapa eksekutif mungkin mentorpedo dengan mengatakan itu terlalu berisiko untuk diluncurkan. Tidak ada yang bisa Anda lakukan kecuali Anda adalah CEO.

Anda meminta argumen yang meyakinkan untuk peluncuran perangkat lunak yang tepat waktu. Ada satu argumen yang sangat meyakinkan: laba atas investasi. Perusahaan memilih untuk berinvestasi dalam perangkat lunak ini, dan sekarang mereka memilih untuk membuang investasi karena perangkat lunak Anda perlahan membusuk di rak.

Argumen sekunder untuk peluncuran yang tepat waktu adalah semangat tim Anda. Terburu-buru dan menunggu bukanlah cara yang baik untuk memotivasi pengembang kreatif untuk melakukan pekerjaan dengan baik. Anda mungkin kehilangan tim Anda jika mereka tidak puas melihat pekerjaan mereka masuk ke dalam layanan.

O. Jones
sumber
1
Jawaban yang bagus Yang lucu, dalam kasus saya, adalah bahwa bahkan biaya peluncuran pada dasarnya telah dihabiskan. Kami hanya perlu membalik saklar! Kecuali itu, secara metaforis, kita memerlukan switch-flipper serikat untuk benar-benar membalik saklar dan tidak ada yang tersedia selama 7 minggu ke depan.
Aaronaught
1
Wow! Masalah ini dikenal ilmu kedokteran sebagai inversi kraniorektal manajerial. Apakah Anda perlu bekerja di tempat lain?
O. Jones
5

Pertama, tonton video ini:

http://the99percent.com/videos/5822/Seth-Godin-Quieting-the-Lizard-Brain

Ringkasan bisnis plan:

Cara Anda mengirim tepat waktu dan sesuai anggaran adalah ini: ketika Anda kehabisan waktu atau kehabisan uang, Anda mengirim. Itu dia.

Alasan kebanyakan proyek tidak mengirimkan tepat waktu adalah karena seseorang datang dengan "hanya satu fitur atau perbaikan" untuk dimasukkan ke dalam rilis, tepat sebelum Anda siap untuk mengirim, pada suatu waktu dalam siklus pengembangan ketika sumber daya Anda paling langka, dan sekarang Anda harus berebut. Ini disebut meronta-ronta, dan itu terjadi karena selama Anda tidak mengirim, Anda tidak perlu khawatir orang mengatakan produk Anda payah.

Cara Anda menyembuhkan labrakan adalah dengan memaksa orang untuk melakukannya pada awal siklus pengembangan produk , bukan pada akhirnya.

Membuat perubahan produk pada minggu-minggu sebelum tanggal rilis sangat mengganggu, karena alasan yang jelas. Ini benar apakah perubahan itu fitur baru, perubahan pada proses pengembangan perangkat lunak, atau upaya untuk memperbaiki bug lama yang tidak ada dalam jadwal pengembangan.

Ketika seseorang datang kepada saya untuk memperbaiki atau mengubah di akhir siklus pengembangan, saya selalu bertanya kepada mereka: "Apa yang Anda inginkan agar saya tidak selesai sehingga saya bisa menyelesaikan pekerjaan Anda?"

Jika Anda membutuhkan motivator uang, inilah: studi membuktikan bahwa semakin lama Anda menunggu dalam siklus hidup perangkat lunak untuk mengimplementasikan fitur atau memperbaiki, semakin mahal harganya. Secara eksponensial. Tidak sulit untuk membuktikan ini.

Robert Harvey
sumber
1
Ini semua saran yang bagus, tetapi saya tidak berpikir itu benar-benar relevan; Saya jelas tidak mengatakan dan tidak bermaksud mengatakan bahwa perubahan lingkup menit terakhir menyebabkan penundaan. Yang saya bicarakan adalah hambatan birokrasi yang dilontarkan oleh orang-orang yang hanya menolak perubahan apa pun terhadap lingkungan produksi, terutama apa pun yang dihadapi klien.
Aaronaught
Pikiran Anda, membaca kembali pertanyaan saya, saya kira saya tidak berbuat banyak untuk menjelaskan bahwa ada tidak perubahan ruang lingkup, jadi saya tidak bisa benar-benar kesalahan jawaban ini baik.
Aaronaught
4

Anda telah dengan jelas menggambarkan masalah yang Anda hadapi, namun apa yang saya tidak jelas tentang mengapa para manajer bersikap seperti ini. Bisakah Anda mengklarifikasi? Misalnya, Anda yakin siap untuk digunakan, apakah seseorang tidak setuju, jika demikian siapa dan mengapa? Apakah mereka mantan beaurocrat

Ini terdengar seperti masalah kemampuan vs penyelarasan keinginan, Anda memiliki keinginan untuk melepaskan, tetapi tidak kapabilitas (otoritas), mereka yang memiliki otoritas tidak memiliki keinginan.

Anda perlu mencari tahu mengapa mereka tidak memiliki keinginan - itu adalah alasan pemasaran (pertahankan untuk satu tahun lagi sementara kami memerah versi lama lebih lama), apakah itu takut / percaya diri (Jika memiliki bug, itu akan membuat kita terlihat buruk , biaya kami uang ...., kekurangan sumber daya (Tidak mampu membayar biaya pengiriman / pengemasan / hal-hal PR), apakah itu bersifat komersial di mana sebagian uang Anda yang tidak jelas tenggelam dengan keuntungan berlebih yang buruk dan mereka tidak ingin Anda menghasilkan uang ( Tidak sebodoh kedengarannya).

Saya juga curiga ada sedikit rasa hormat antara pihak-pihak yang terlibat, oleh karena itu diskusi orang dewasa yang wajar tidak terjadi.

Maaf - bukan jawaban spesifik yang Anda minta, semoga beberapa hal untuk dipikirkan.

mattnz
sumber
1
Paragraf kedua hingga terakhir adalah analisis masalah yang cukup bagus - ini masalah politik, bukan teknis. Tentunya karena alasan privasi saya tidak bisa masuk ke detail yang jauh lebih rumit, dan saya tidak berpikir itu benar-benar berkaitan dengan solusinya. Terlepas dari siapa yang "menghalangi" dan mengapa, saya pikir bahwa satu-satunya solusi jangka panjang adalah meyakinkan manajemen atas bahwa tim pengembang perlu mengendalikan proses dan khususnya proses yang melibatkan tanggal kapal yang direncanakan sebelumnya.
Aaronaught
3
Satu hal yang perlu diperhatikan: Dev tidak bertanggung jawab atas tanggal pengiriman. Dev memiliki input ke dalam tanggal-tanggal ini, tetapi tanggal kecuali ditetapkan untuk alasan bisnis, daripada alasan teknis, bisnis berada dalam masalah.
mattnz
Anda membuat poin yang baik dengan menyoroti kehalusan di sini - ini lebih tentang mendapatkan komitmen eksekutif di balik tanggal kapal reguler daripada tentang memiliki kontrol penuh atas jadwal. Tentu saja bisnis pada akhirnya akan memutuskan kapan dan seberapa sering mengirim, tetapi ini harus diputuskan jauh sebelumnya, dengan tim pengembang memiliki masukan yang signifikan , dan yang paling penting dari semuanya, mereka tidak dapat diperdebatkan 2 minggu sebelumnya (atau lebih buruk lagi) , 2 minggu setelah ) tanggal pengiriman yang diharapkan kecuali ada alasan bisnis yang sehat, dengan tanggung jawab untuk memblokirnya.
Aaronaught
Proses lain, bagi saya, hanyalah kekacauan. Jika Anda tidak tahu kapan proyek Anda benar-benar akan dikirim maka hampir tidak mungkin untuk melakukan pelingkupan atau desain yang tepat.
Aaronaught
2
@Aaronaught - Mungkin sesederhana politik / kolaborasi. Anda bisa mendapatkan diri Anda dalam air panas yang berusaha melindungi Anda dari manajemen Anda. Izinkan saya menyarankan logika ini - asumsikan bahwa pengiriman tidak dalam kepentingan terbaik bisnis dalam setiap kasus. Oleh karena itu harus ada beberapa alasan / situasi di mana kepentingan bisnis tidak dikirim. Tidak mengetahui situasi penuh dari atas ke bawah tidak membuat Anda salah, itu juga tidak membuat manajemen salah juga.
jasonk
2

Hal pertama yang harus dipertimbangkan adalah memastikan rilis Anda tidak berisiko tinggi .

Idealnya, permintaan perubahan Anda harus memiliki bagian yang disebut seperti Mitigasi Risiko , yang berisi instruksi tentang cara mengembalikan ke versi sebelumnya jika terjadi kesalahan. Dari segi risiko, tidak ada jumlah pengujian sebelumnya yang dapat menggantikan opsi sederhana untuk mengembalikan perubahan.

  • Dalam lingkungan yang menghindari risiko, saya tidak bisa membayangkan cara untuk membuat perubahan yang tidak dapat dikembalikan tanpa rasa sakit.
    Jika banyak / sebagian besar rilis Anda termasuk dalam kategori ini, Anda mungkin ingin mempertimbangkan kembali arsitektur Anda.

The risiko TIDAK merilis harus terkena, jika Anda ingin jadwal tim dev untuk diperlakukan secara serius.

Jika rilis Anda memberikan perbaikan untuk masalah produksi / dukungan dan pemadaman, ini cukup mudah dilakukan dengan hanya mendaftar ini dan menunjukkan bahwa produksi berisiko mengulangi ini kecuali itu ditingkatkan.

Sebuah langkah yang sangat efektif tersedia untuk tim pengembang untuk melawan pelepasan slippage untuk memastikan bahwa risiko tidak melepaskan meningkat seiring waktu . Ini dapat dicapai dengan rilis internal berjalan pada jadwal tetap, memberikan daftar "kumulatif" solusi untuk masalah produksi.

  • Sederhananya, orang-orang yang memblokir rilis Anda XXperlu menyadari tidak hanya bahwa mereka menanggung risiko memiliki Njenis masalah produksi untuk tetap tidak terselesaikan, tetapi juga pada minggu (atau bulan) nanti, mereka akan memiliki rilis XX+1dalam antrian persetujuan mereka, memblokir yang akan menanggung risiko N+Mjenis masalah produksi tetap belum terselesaikan - dan bahwa ini juga akan menjadi masalah dengan XX+2dan selanjutnya rilis "internal" yang disediakan oleh tim pengembang.

Cara yang dijelaskan di atas pada dasarnya membuat hubungan yang lebih ketat dan lebih eksplisit antara pembaruan aplikasi Anda dan masalah produksi.

Karena itu, Anda dapat mengharapkan lebih banyak keterlibatan dalam eskalasi masalah produksi . Anda dapat menggunakan ini sebagai kesempatan untuk mempromosikan visi Anda tentang pembaruan terjadwal yang lebih ketat. Anda bahkan dapat memicu beberapa peningkatan diri sendiri untuk mempercepat proses mengadopsi pendekatan yang Anda inginkan.

  • "... rekomendasikan untuk mempertimbangkan untuk memutakhirkan aplikasi ke versi yang lebih baru ( XXatau lebih baru). Yang saat ini digunakan untuk lingkungan Anda ( XX-2) sudah sangat ketinggalan zaman - dua rilis utama di belakang basis kode saat ini. Akibatnya, rincian untuk kegagalan sederhana seperti itu adalah sangat tersembunyi di dalam log dan sampah yang tidak dapat diuraikan dilaporkan oleh aplikasi kepada klien alih-alih deskripsi kegagalan yang jelas - menyebabkan pengguna dan dukungan untuk membuang waktu menyelidiki masalah yang benar-benar sangat sederhana "
     
    Di atas adalah komentar yang saya tambahkan beberapa waktu lalu di pelacak masalah dukungan untuk tiket terkait dengan insiden produksi tertentu. Segera setelah itu, "para pemangku kepentingan" menghubungi tim pengembang menanyakan bagaimana cara melacak rilis kami dan bagaimana mereka dapat membantu dalam penyebaran ke lingkungan mereka. Oh dan mereka juga dengan cepat ditingkatkan dariXX-2versi juga. :)

Ketika eskalasi produksi terjadi, Anda sebaiknya bersiap untuk menyajikan visi Anda dengan cepat dan jelas.

Satu hal yang menurut Anda berguna adalah memilih dan melacak siapa yang bertanggung jawab atas slippage rilis tertentu. Pada dasarnya, Anda harus dapat dengan cepat dan jelas menjawab pertanyaan seperti "siapa yang bertanggung jawab atas kenyataan bahwa pembebasan yang direncanakan tidak terjadi?" Jika Anda tidak siap, mereka mungkin memilih jalan yang paling tidak menentang dan menyalahkan Anda. Seperti yang ditunjukkan dalam komentar untuk jawaban lain , "Anda bisa mendapatkan diri Anda dalam air panas yang berusaha melindungi Anda dari manajemen Anda."

Terakhir tapi tidak sedikit,

itu akan memakan waktu

(Anda mungkin sudah tahu itu, tetapi itu terlihat layak dinyatakan secara eksplisit)

Apa yang Anda cari dapat digambarkan sebagai perubahan sikap, dari "berisiko untuk dilepaskan " menjadi "berisiko tidak dilepaskan ". Perubahan sikap jarang terjadi dalam semalam, kesabaran mungkin diperlukan untuk menyelesaikan shift.

agas
sumber
1

Ada tanda tanya besar yang menggantung di atas pertanyaan Anda, dan itulah sebabnya perusahaan Anda tidak ingin merilis perangkat lunak. Ini tidak selalu hanya kasus sederhana penghindaran risiko. Seringkali ada penyebab lain yang mendasari yang tidak sering diturunkan dari ketinggian manajerial yang tinggi. Jadi pertanyaan saya kepada Anda adalah, "Sudahkah Anda duduk dengan bos Anda dan bertanya kepadanya mengapa rilis produk ditahan?".

Ada perbedaan besar antara mengelola risiko, dan menghindarinya. Mungkin ada alasan hukum atau pemasaran untuk menunda peluncuran produk. Ini bisa menjadi masalah kepercayaan antara manajemen dan tim pengembangan. Produk mungkin tidak sesuai dengan kebutuhan pelanggan, bahkan jika itu persis seperti yang diminta pelanggan selama berbulan-bulan yang lalu. Ini bahkan bisa menjadi kasus seseorang dalam manajemen yang secara serius menutupi masalah ketika mencoba mengalihkan kesalahan atas keterlambatan di tempat lain, atau bahkan penundaan oleh pihak ketiga yang diperlukan untuk menyelesaikan sesuatu sebelum produk Anda dikirimkan. Saya bisa membuat lusinan skenario. Cukup sering pengembang menganggap keengganan risiko tanpa memahami sisi lain dari persamaan yang belum terlihat. Di sisi lain, itu mungkin hanya rasa puas diri, konflik antara individu dalam perusahaan,

Dalam semua kasus, penting untuk memiliki lebih banyak informasi tentang alasan keterlambatan dalam rilis produk, dan untuk menggunakan informasi itu untuk membuat case untuk merilis produk Anda sesegera mungkin. Ya, ini bisa sangat membuat frustrasi, tetapi ada cara lain untuk menghadapi situasi ini tanpa mempertaruhkan konfrontasi dengan bos Anda, atau kelelahan. Dalam situasi yang sama, saya sendiri telah mengumpulkan informasi, mendokumentasikan kemajuan apa pun yang telah saya buat, dan kemudian jika lebih buruk menjadi lebih buruk, cukup simpan proyek dan pindah ke sesuatu yang lain. Di mana saya bisa mendapatkan proyek kembali ke jalur untuk rilis biasanya merupakan hasil dari membuat kasus bisnis yang sehat berdasarkan informasi yang saya terima sebagai umpan balik untuk pertanyaan yang saya ajukan. Di mana saya tidak dapat meyakinkan manajemen bahwa produk tersebut harus dikirim, Saya telah mendokumentasikan keengganan untuk mengirim hanya sebagai kasus proyek selesai, dan menunggu persetujuan rilis oleh manajemen. Saya kemudian memastikan bahwa manajer saya menandatangani dokumen saya sebagai diterima dan dipahami oleh manajemen sehingga pantat saya sendiri terlindungi jika mereka harus berusaha untuk menyalahkan saya nanti karena tidak dirilis.

Anda selalu perlu menyodorkan I dan cross T Anda untuk menghindari keterlambatan pengiriman yang kemudian menyalahkan Anda (tidak peduli seberapa tidak adil), dan juga penting untuk menghindari menjadi terlalu terikat secara emosional dengan masalah seperti itu kecuali jika Anda menyukai ide borok yang diperoleh dengan baik. Dengan melihat situasi Anda sendiri dengan detasemen profesional tertentu, Anda dapat menemukan solusi muncul dengan sendirinya karena Anda telah secara efektif menempatkan diri Anda pada "jarak" yang lebih besar daripada dari masalah. Jika Anda tidak dapat membuat kasus Anda, Anda mungkin harus membiarkannya untuk sementara waktu, tetapi untuk membuat kasus Anda di tempat pertama, Anda harus terlihat profesional, dan memiliki argumen berdasarkan informasi yang terkait erat dengan perusahaan Anda dan cara kerjanya.

Hal lain yang baru saja saya pikirkan yang mungkin bisa membantu Anda, mungkin membaca Lean Software Development , dan melihat apakah ada sesuatu yang berharga di sana yang mungkin terkait dengan situasi perusahaan Anda, terutama dalam beberapa bab pertama. Saya pikir itu adalah bab 4 yang membahas masalah pengiriman secepat mungkin dan memiliki sesuatu yang berkaitan dengan biaya keterlambatan.

S.Robins
sumber
1
Tidak ada tanda tanya. Saya tidak menyebutkan salah satu skenario ini karena tidak setiap yang bersangkutan. Tentu saja apa yang Anda katakan di sini akan masuk akal tanpa konteks, tetapi pertanyaan itu ditulis dengan asumsi bahwa orang akan mempercayai saya ketika saya mengatakan bahwa saya telah menghabiskan semua jalan penyelidikan.
Aaronaught
@Aronaught Dalam konteks jawaban saya, ini bukan pertanyaan tentang tidak mempercayai Anda. Seringkali ketika kita berpikir bahwa kita telah melakukan segalanya, masih ada pilihan lain untuk dicoba, atau jika tidak ada manfaatnya meminta orang lain menyuarakan sesuatu dengan harapan hal itu mungkin secara langsung relevan bagi Anda, bahkan jika itu menyatakan yang sudah jelas. Mungkin saja orang lain menemukan diri mereka dalam situasi yang sama, dan jawaban ini mungkin berlaku lebih dekat dengan mereka (itulah tujuan dari situs ini). Terlepas dari paragraf terakhir saya tetap relevan, meskipun saya akan menawarkan sedikit suntingan sebagai tambahan.
S.Robins
0

Saya akan mengatakan cara termudah / paling efektif untuk menjual rilis adalah dengan menurunkan alat untuk sementara waktu ketika siap untuk digunakan. Lakukan sesuatu yang lain, mulai proyek baru, kerjakan bug untuk proyek yang ada. Jangan lakukan hal ini lagi sebelum dikirim keluar - setelah semua, mengapa repot-repot melakukannya jika tidak pergi ketika sudah siap.

tetapi di dunia nyata, rilis yang sebenarnya adalah masalah orang lain, Anda harus mengirimkannya kepada mereka dan kemudian memperlakukannya sebagai rilis. Setelah keluar dari pintu Anda, dikirim. Jika mereka hanya duduk di atasnya, itu bukan masalah Anda (pada kenyataannya, itu bagus, tidak ada bug yang dilaporkan! W00t! Bonus untuk rilis bebas bug semua;))

Jadi Anda tetap membutuhkan sistem kontrol perubahan, dan manajer rilis. Maka itu semua mudah (kecuali Anda memang perlu mengelola kontrol perubahan, jadi kontrol sumber plus pembangunan penyebaran sangat diperlukan. Ini membutuhkan organisasi, tetapi jika Anda teratur, mudah).

gbjbaanb
sumber
Saya khawatir dengan bagian pertama dari jawaban Anda [alat bawah] tetapi ketika saya membaca sisanya, saya pikir ini adalah cara yang baik untuk mengatasinya.
jasonk
0

Saya tidak bisa membayangkan bahwa menempatkan tim Dev sebagai penanggung jawab bisnis seperti yang Anda gambarkan adalah "hal yang baik" Ini mungkin menutupi masalah sebenarnya, tetapi kecuali tim Dev berada di posisi yang tepat untuk menimbang masukan dari penjualan, pemasaran , dll. Anda berisiko melepaskan alasan yang salah (dan berpotensi buruk).

Jika saya memahami masalah Anda - Anda telah menyelesaikan proyek dan memiliki hasil yang Anda tidak dapat tunjukkan kepada siapa pun di luar perusahaan Anda. (Saya harap ini merangkumnya, saya membaca seluruh utas dan saya mengalami kesulitan meletakkan jari saya di atasnya)

Sudahkah Anda mencoba:

  1. Mintalah manajemen untuk pelanggan atau sekelompok pelanggan untuk bertindak sebagai pemangku kepentingan selama pengembangan? Biasanya Anda dapat menemukan satu pelanggan untuk mengambil rilis lanjutan dan memberikan umpan balik. Mereka bisa menjadi pembela yang hebat ketika tiba saatnya untuk dibebaskan. Bahkan "rilis terbatas" untuk satu pelanggan mungkin cukup untuk membantu manajemen bergoyang
  2. Membangun rencana rilis termasuk rilis poin. Artinya, Anda dapat merilis 3.4 hari ini karena rilis 3.4.1 direncanakan untuk hari ini + 1 bulan. Ini bersama dengan ide bagus yang telah Anda sebutkan bahwa irama rilis membantu pesan ini.
  3. Dapatkan dukungan, penjualan, atau pemasaran di pihak Anda. Bangun perbaikan yang akan menyelesaikan 3 permintaan dukungan teratas dan Anda bisa mendapatkan sekutu dari departemen lain. Jika Anda tidak bisa mendapatkan pemangku kepentingan pelanggan seperti di # 1, coba dengan beberapa tenaga penjualan. Tawarkan untuk hadir dalam pertemuan penjualan dan bawa produk. Ketika Anda berada di jalan, tunjukkan orang penjualan Anda dengan produk (dalam keadaan apa pun itu) membuat mereka menarik untuk Anda.

Untuk menjawab pertanyaan Anda yang lain tentang "mengapa manajemen harus menunggu rilis?" Perusahaan melakukan ini sepanjang waktu di bidang non SW dan saya pikir itu belum pernah terjadi sebelumnya. Misalnya, Anda memiliki rilis baru yang siap untuk digunakan, semuanya telah diuji dan dilakukan. Namun versi lama belum tergusur oleh kompetisi. Setelah kompetisi merilis produk pesaing Anda versi lama, manajemen merilis versi menunggu di rak dan mengganggu pasar, mengatur kembali kompetisi dan mempertahankan penjualan dan reputasi sebagai pemimpin pasar. Melepaskan terlalu cepat memberi petunjuk kepada para pesaing yang mungkin memiliki gagasan yang lebih baik tentang peta jalan Anda dan mencoba untuk mengalahkan Anda hingga akhir pertandingan.

Dengan semua yang dikatakan ... Hanlon's Razor mungkin jawaban yang tepat :-)

Al Biglan
sumber
-1

Pergi dari perusahaan itu, mereka tidak mengerti perangkat lunak. Tetapi serius, perangkat lunak adalah apa yang membuat sistem bekerja, bayangkan jika Anda membuat mobil, apakah pabrik mobil lambat? apakah mereka menunggu rilis mobil? Apakah mereka bersifat inkremental dan birokratis? Tidak, mereka mencoba melakukan hal-hal dengan cara tercepat dan terbersih. Anda memiliki masalah manajemen dan Anda harus mengatasinya sebagai konflik manajemen, cobalah untuk berbicara dalam istilah mereka. Tanyakan apa artinya risiko bagi mereka, kemudian cobalah untuk meminimalkannya. Perasaan devs Anda juga penting, karena mereka harus mengatasi keputusan yang akan dibuat oleh intervensi Anda. Apakah mereka senang melakukan semua nighters untuk mengirim tepat waktu? Apa hadiah / hukumannya? Dll. Sekarang saya akan memberi Anda pendekatan praktis untuk masalah ini, agak ekstrem, tetapi meminta audit.

alfa64
sumber