Apa cara terbaik untuk memungkinkan klien berkontribusi pada proyek?

Kami telah membangun CRM untuk klien. Sekarang setelah fase utama pertama telah selesai, dan yang kedua disepakati, klien ingin mengambil beberapa pekerjaan, membuat sedikit perubahan pada skema database dan proses bisnis fase pertama sementara kami membangun yang kedua .

Saya ragu-ragu apakah ini memang praktis, tetapi dengan asumsi itu, saya ingin beberapa petunjuk yang dapat diambil langkah-langkah untuk membuat ini sama sekali bisa diterapkan. Inilah yang saya dapatkan sejauh ini:

• Sampai sekarang, sebagian besar klien telah melihat proyek dari sudut pandang pengguna; jelas, seminar dua bagian harus diadakan di tempat kami memperkenalkannya pada pekerjaan batin:

  • pertama, menunjukkan skema database yang ada dan, sebagai contoh, memperluasnya,
  • kemudian, menunjukkan beberapa kode sampel, dan menulis proses bisnis baru untuk peningkatan skema.
• Kode saat ini berada di repositori Subversion internal. Sementara kita bisa mendirikan satu publik atau satu di nya jaringan (yang kita dapat VPN ke), saya merasa sistem terdistribusi akan bekerja lebih baik. Namun, saya tampaknya menjadi satu-satunya yang merasa demikian, sehingga saya dapat menggunakan beberapa argumen yang meyakinkan.

• Saya tidak yakin bagaimana mengamanatkan / memastikan bahwa kode yang berjalan dalam produksi berkomitmen. Sepertinya "x melakukan perubahan kritis, tidak berdokumen tepat sebelum pergi berlibur; sekarang Anda sedang mencoba mencari tahu bug ini yang telah terjadi sejak" bencana tidak bisa dihindari. Idealnya, semua perubahan, sebelum penempatan, akan:

  • didokumentasikan dalam sistem pelacakan masalah,
  • terjadi pada lingkungan pengujian terpisah terlebih dahulu, dan
  • harus lulus tes otomatis.

  Sayangnya, saya ragu disiplin untuk siapa pun dari mereka yang akan menang.

Asumsikan bahwa arsitektur plug-in atau proyek terpisah bukan pilihan yang layak, karena 1) yang sebelumnya tidak ada, dan 2) yang terakhir akan melarang klien dari melihat dan mungkin memodifikasi kode yang ada, suatu kemampuan yang saya percaya dia akan lakukan bersikeras.

Ini akan menjadi jawaban yang paling tidak disukai - tapi tetap saja ini dia!

Ini berisiko (sebanyak membiarkan seorang pemula mengendarai mobil baru) - tetapi itu bukan ide yang buruk.

Pahami mengapa mereka ingin melakukan ini: ini bukan karena mereka memiliki sumber daya cadangan, itu hanya untuk membuat diri mereka merasa terkendali.

Yang perlu Anda lakukan adalah mengikuti:

1. Mendidik klien Anda - perangkat lunak lebih dari sekadar kode. Jika mereka ingin berpartisipasi, biarkan mereka terlebih dahulu meninjau aspek arsitektur, desain, dan sebagainya. Sampaikan pertanyaan kepada mereka dan tunjukkan pada mereka implikasi dari pilihan yang mereka buat sebelumnya.

2. Anda harus selalu kembali dengan opsi tentang pro / kontra tentang pendekatan (dan mendokumentasikan pertemuan ini dengan baik) tetapi Anda harus membiarkan mereka mengambil beberapa pengambilan keputusan. Setidaknya mereka akan mulai menghargai bahwa mereka tidak tahu banyak - atau akan mengambil kepemilikan pada diri mereka sendiri.

3. Anda dapat membuat ruang terpisah - seperti cabang sehingga mereka harus dapat kode apa pun yang mereka inginkan - hal-hal yang harus diuji sebelum melakukan atau menggabungkan.

Meskipun saya tahu komplikasi mungkin terjadi, setiap masalah adalah peluang. Jika semuanya berjalan dengan baik, klien Anda akan lebih menghargai masalah internal, dan akan mengembangkan kepercayaan yang lebih baik karena mereka tahu (bagaimana) Anda telah melakukan pekerjaan dengan baik!

PS: Untuk memberi Anda wawasan - saya dari India; dan saya tahu banyak toko IT di mana manajemen tidak memiliki banyak petunjuk. Mereka biasanya tidak keberatan (bahkan merasa senang) bahwa klien menempatkan sumber daya tambahan untuk memastikan proyek tidak masuk ke tempat sampah! Ini sangat bagus untuk mereka; mereka semua pergi dengan satu pola pikir "Apa pun yang Anda katakan pak!". Ini bukan untuk merendahkan bangsaku sendiri - tetapi untuk menunjukkan bahwa pengembangan bersama bukanlah ide yang buruk. Bagaimanapun, yang digambarkan oleh banyak guru manajemen adalah " pendekatan prosumer " untuk masalah bisnis.

Aduh ... Anda punya ide yang tepat tetapi saya telah melihat betapa berantakannya ini bisa berubah, dan kedua belah pihak sangat menderita. Saya memelihara aplikasi semacam itu saat ini.

Cari tahu alasan sebenarnya mengapa klien merasa perlu untuk berkontribusi langsung ke proyek. Apakah mereka sekarang ingin agar proyeknya selesai lebih cepat daripada yang realistis yang bisa Anda lakukan? Apakah mereka sudah menginginkan perubahan tetapi takut dikenai biaya tambahan dari Anda untuk melakukan perubahan spesifik atau meminta fitur tambahan? Apakah ada pergulatan politik dalam organisasi mereka di mana sumber daya pengembangan internal ingin lebih banyak kontrol dan input dalam proyek atau di mana mereka mencari pekerjaan yang sibuk untuk pengembang internal? (Yang terakhir ini dekat dengan rumah bagi saya)

Temukan apa motivasi mereka yang sebenarnya dan tangani mereka jika memungkinkan. Fakta bahwa mereka bahkan menyarankan itu adalah tanda peringatan besar bahwa ada masalah di jalan. Cobalah untuk meringankan kekhawatiran mereka yang sebenarnya sebelum menyetujui hal seperti itu karena kemungkinan besar apa yang akan terjadi adalah bahwa mereka akan memperkuat kontrol proyek dan menghentikan Anda, atau mereka akan menyebabkan kekacauan besar dan proyek yang gagal.

EDIT: Sayangnya kapal itu berlayar untuk Anda, tetapi jangan putus asa dulu. Masih ada hal-hal yang dapat Anda lakukan untuk meminimalkan rasa sakit yang akan datang. Tidak peduli apa pun, pastikan bahwa mereka adalah SATU DAN SATU-SATUNYA MANAJER PROYEK dan PEMILIK PRODUK dan bahwa orang ini terkait dengan organisasi / perusahaan Anda. Orang ini harus memiliki kemampuan untuk merencanakan sprint, memasukkan atau menghapus cerita pengguna dan menugaskan tugas ke sumber daya di perusahaan Anda serta perusahaan klien Anda. Apa pun yang terjadi, pastikan bahwa sumber daya pengembangan di perusahaan Anda tidak bekerja secara terpisah dari sumber daya klien Anda dan bahkan yang lebih penting JANGANmemungkinkan pengembang di perusahaan Anda untuk melaporkan kepada manajer proyek atau pemilik produk mereka! Mereka akan mengambil keuntungan penuh dari pekerjaan gratis yang tidak tercakup oleh kontrak atau mereka akan menolak Anda dari proyek Anda sendiri. Itu adalah suatu kepastian.

Dari sudut pandang hukum, Anda pada dasarnya bertanya, "Apa cara terbaik untuk mengendarai keledai yang ditutup matanya melalui ladang ranjau?"

Dari perspektif pemrograman, saya akan meminta lebih banyak informasi - dapatkah klien meminta untuk diimplementasikan menggunakan semacam sistem EAV yang ditentukan pengguna atau dengan kait yang dapat ditambahkan ke sistem? Idealnya, saya ingin menjaga kode klien terpisah dari Anda mungkin karena berbagai alasan.

Seseorang yang biasanya berperan sebagai klien di sini menimpali. Sejujurnya saya tidak akan memiliki masalah ini karena jika sampai sejauh ini Anda akan berada dalam kendali sumber saya, menggunakan pengaturan CI saya dan pengaturan QA saya untuk menguji sesuatu. Pengaturan ini bisa sangat sulit untuk diatur - saya mendapatkan banyak pushback dari konsultan, terutama menyelesaikan pekerjaan. Tampaknya proses mengganggu jam yang dapat ditagih.

Saya pikir perspektif Anda agak jujur. Pertama, perlu diingat bahwa ini bukan basis kode Anda melainkan basis kode kami. Kedua adalah bahwa, dalam banyak kasus, toko IT di sisi klien memiliki motivasi yang jauh lebih besar untuk memastikan produk ini berfungsi sebagaimana dirancang dan mudah untuk mempertahankan, mengelola, dan mendukung ke depan. Menyelam kembali untuk memperbaiki bug tidak lebih banyak waktu yang dapat ditagih kepada kami tidak seperti kebanyakan konsultan. Selain itu, membangun berbagai hal agar mudah dikonfigurasi dan gagal dengan cara yang dapat diprediksi jauh lebih penting ketika Anda memiliki sisi operasi mata uang juga. Anda mungkin saja berakhir dengan proyek berkualitas lebih tinggi karena bagian dari staf pengembangan tidak dibatasi oleh jam yang dapat ditagih.

Sejauh bagaimana cara membuatnya bekerja, DCVS jelas merupakan cara untuk pergi jika itu dapat dibuat terjadi. Memilih sesuatu yang netral (bitbucket, github) dapat membantu. Memiliki CI di tempat juga merupakan anugerah di sini - lebih sulit untuk hal-hal untuk keluar dari pukulan ketika semua orang tahu itu keluar dari pukulan pada komit terakhir. Jika Anda dapat memaksa hal-hal untuk digunakan melalui CI - sesuatu yang biasanya harus kami paksakan kepada vendor - Anda benar-benar dapat memastikan semua perubahan dilakukan. Dari segi pelatihan, sudahkah Anda mempertimbangkan berpasangan dengan klien selama beberapa hari? Itu mungkin cara yang baik untuk membangun ikatan lateral yang Anda butuhkan. Secara keseluruhan, taruhan terbaik adalah meyakinkan semua orang bahwa mereka berada di tim yang sama. Karena mereka berada di tim yang sama.

Sepertinya ini adalah masalah manajemen karena ini masalah teknis. Saya sudah berurusan dengan situasi seperti ini di perusahaan konsultan dan perangkat lunak. Dari keseluruhan "Berapa nilai yang akan diperoleh pelanggan dari perangkat lunak?" dan "Berapa banyak upaya yang saya perlukan untuk mempertahankannya pasca produksi?" ini sebenarnya situasi yang baik untuk Anda. Banyak klien bersikeras agar orang mereka terlibat. Ini akan membutuhkan banyak pekerjaan.

Dimulai dengan akhir dalam pikiran, yang Anda butuhkan adalah Pernyataan Kerja yang baik . Ini akan mencantumkan apa tujuan Anda, dan apa tujuan mereka. Sebuah Peran dan Tanggung Jawab matriks adalah dokumen kurang legalistik yang menggambarkan siapa yang memiliki setiap item, siapa yang terlibat, dan yang hanya perlu diinformasikan. Kedua hal ini mengasumsikan bahwa Anda memiliki Struktur Perincian Kerja yang terdefinisi dengan baik yang mencantumkan pada level rendah (cukup rendah untuk memperkirakan) apa tugas masing-masing.

Dalam hal penciptaan, biasanya urutan terbalik: Lingkup (yang sudah jelas Anda miliki) -> WBS (yang mungkin Anda miliki) -> Matriks Peran dan Tanggung Jawab -> SOW.

Setelah kepemilikannya jelas, saatnya untuk mengelola kode dan lingkungan. Saya cukup agnostik pada alat manajemen kode. Apa yang akan saya katakan adalah penting untuk melakukan tinjauan kode untuk semua yang dilakukan oleh seseorang di luar tim inti. Jika alat yang Anda gunakan menandai ini, semuanya lebih baik. Anda ingin menghindari seseorang menjepit sesuatu yang bertentangan dengan keputusan arsitektur kunci yang telah dibuat sebelumnya. Konsep 4 mata (2 mata tambahan meninjau segalanya) adalah satu-satunya keputusan taktis paling penting yang dapat Anda buat.

Lingkungan juga sulit dikelola. Biasanya saya pernah mengalami situasi di mana "Kami melakukan pekerjaan kami di lingkungan kami, ketika kami selesai itu pergi ke Anda" dan kedua vendor dan klien berjuang melalui. Situasi Anda terdengar lebih rumit. Saya menyarankan untuk mencoba dan menemukan cara bagi mereka untuk bekerja di lingkungan Anda sampai proyek selesai. Jika Anda dapat menemukan cara untuk melatih klien dalam mengelola lingkungan mereka (jangan menganggap mereka ahli dalam hal ini) maka semuanya akan lebih baik.

Beberapa peringatan lainnya ...

1. Jangan menganggap klien memiliki produktivitas yang sama dengan tim Anda. (Anda akan mendapatkan kejutan ke atas tentang pengetahuan domain, kejutan ke bawah pada kecepatan khusus untuk perangkat lunak Anda.)

2. Jangan menganggap klien tahu metodologi Anda.

3. Jangan menganggap klien membagikan soal kerja tim Anda. (Saya telah melihat kejutan ke atas dan ke bawah.)

4. Habiskan banyak waktu pelatihan dan co-locating.

5. Setiap jam yang dihabiskan untuk mengajar klien untuk memecahkan masalah akan menghemat banyak hari di masa depan.

6. Manfaatkan klien untuk bekerja melalui organisasi internal mereka untuk Anda, dan temukan pakar dalam konten dan pertanyaan domain.

7. Memanfaatkan klien untuk menjual melatih organisasi mereka.

8. Secara default melibatkan klien dalam proses pengembangan Anda akan memaksa Anda untuk berpikir seperti perusahaan layanan profesional. David Maister menulis buku terbaik tentang topik ini. Meskipun hanya 20% yang relevan dengan Anda, ada baiknya dibaca.

Terlepas dari semua peringatan ini, termasuk klien di tim Anda dapat melakukan keajaiban untuk membawa Anda lebih dekat dengan pembeli Anda. Klien-klien ini adalah yang paling mungkin menjadi referensi di masa depan. Semoga berhasil dalam membuat yang terbaik dari situasi ini!

Klien Anda pasti harus diberi panduan tentang bagaimana semuanya diatur, itu harus menjadi persyaratan untuk keluar pada tahap pertama. Anda harus mendorong kembali pada memungkinkan klien Anda untuk mengedit apa pun secara langsung, ia harus mengisi permintaan perubahan yang dimasukkan ke dalam sistem pelacakan masalah Anda dan diprioritaskan dengan sisa pekerjaan. Terserah Anda dan klien Anda untuk memutuskan permintaan mana yang berada di luar cakupan kontrak. Bagaimana ini terjadi harus dirancang dalam semacam alur kerja / dokumen manajemen perubahan, jika tidak ada, saya sangat menyarankan Anda membuatnya dan membuat klien Anda setuju bahwa ini adalah proses di mana ia dapat mengubah sesuatu, dan mendapatkan ini dalam penulisan. Kalau tidak, tidak banyak yang dapat Anda lakukan selain berdoa tidak ada yang salah.