Offshoring Proyek Perangkat Lunak - Resolusi Konflik [ditutup]

Saya telah ditugaskan untuk mengelola proyek yang di-outsourcing-kan ke beberapa pengembang Ukraina.

Perusahaan mempekerjakan mereka melalui Elance dengan harga tetap . Pada saat itu bos saya meninggalkan saya sendirian untuk menangani mereka dan menyelesaikan pekerjaan. Saya membuat spesifikasi terperinci dari hal lengkap yang perlu dilakukan.

Proyek ini melibatkan berurusan dengan hal-hal seperti XMPP, RabbitMQ, dan Database. Dalam pertemuan pertama saya dengan mereka (selalu IM) saya menjelaskan dengan seksama apa yang harus mereka lakukan. Mereka tampaknya memahaminya - dan mereka sangat yakin bahwa itu akan dilakukan dengan mudah.

Sejauh ini bagus. Tetapi setelah satu minggu, ketika kami bertemu lagi, mereka penuh dengan kesalahpahaman tentang apa yang perlu dilakukan. Ketika saya bertanya kepada salah satu pengembang apakah dia mengenal XMPP, dia bilang dia bekerja dengannya untuk pertama kalinya. Pada pertemuan pertama kami, saya secara khusus menyebutkan kompleksitas proyek dan teknologi yang terlibat. Plus, saya telah berulang kali meminta mereka untuk menulis spesifikasi fungsional persis BAGAIMANA mereka akan melakukannya. Tetapi mereka mengatakan TIDAK, dan bersikeras bahwa mereka lebih suka menulis kode. Saya bilang OK.

Proyek selesai setelah 3 minggu dan mereka mengirimkan apa yang dibutuhkan. Pada saat itu saya mulai meninjau kode. Sebagian besar tidak apa-apa, tetapi ada beberapa masalah penting:

• mereka mengkodekan beberapa hal yang perlu dipisahkan menjadi file konfigurasi
• ada beberapa file konfigurasi yang perlu saya konsolidasi menjadi satu
• mereka menulis sama sekali TIDAK dokumentasi
• beberapa perubahan kecil lainnya

Saya meminta mereka untuk melakukan perubahan ini (kecuali dokumentasi) - Dan, kami memiliki argumen.

Mereka berkata, karena harganya sudah tetap, saya tidak adil dalam meminta mereka untuk melakukan perubahan begitu mereka menyelesaikan kode kerja. Bahwa mereka telah bekerja untuk waktu yang tidak masuk akal pada proyek dan sekarang benar-benar salah untuk meminta apa pun.

Akhirnya sekarang mereka telah membuat perubahan, dan proyek selesai. Tapi itu meninggalkan beberapa pertanyaan di benak saya ...

• Mereka melakukan apa yang dibutuhkan tetapi saya perlu melakukannya dengan benar , dan karenanya perubahan. apakah saya benar-benar tidak adil?

• Mengapa saya setuju membiarkan mereka kode tanpa spesifikasi fungsional?

• Mengapa saya tidak memastikan bahwa mereka memahami segalanya pertama kali?

Adakah yang menemukan diri mereka dalam posisi yang sama? Apakah Anda pikir ada cara yang lebih baik untuk mengelola proyek outsourcing?

- PEMBARUAN -

Terima kasih untuk semua pendapat - setelah merefleksikan seluruh pengalaman, saya dapat menyimpulkan ...

• Meskipun saya tidak samar-samar dalam spesifikasi dari sisi saya, saya pasti tidak membuatnya kaku seperti yang disarankan. Jadi kesimpulannya adalah: selalu sespesifik mungkin - baca spesifikasi Anda dari sudut pandang mereka juga dan lihat apakah Anda melewatkan sesuatu. Ulangi setidaknya tiga kali.

• Hanya menentukan apa yang harus dilakukan kode itu tidak cukup. Anda harus menentukan seperti apa kode itu seharusnya. Akan seperti apa struktur direktori; bahkan nama file jika memungkinkan. Ini akan menyelamatkan Anda dari banyak gangguan nanti. Tentukan dengan jelas pedoman pengkodean, konvensi penamaan variabel, format dokumentasi internal, dll. Pastikan bahwa mereka mematuhi pedoman tersebut, dan jika tidak, teriak.

• Menuntut spesifikasi fungsional dari pihak mereka - bersikeras bahwa itu ditulis sebelum kode apa pun. Ini akan menghilangkan banyak kebingungan dan kesalahpahaman.

• Tinjau kode yang sedang dikembangkan sehingga Anda mengidentifikasi anomali sebelumnya dan memperbaikinya. Bicaralah dengan mereka setidaknya sekali setiap hari.

• Terakhir, cobalah membuat hubungan yang baik dengan mereka. Buat mereka merasa bahwa Anda menghargai pekerjaan mereka. Jangan memaksakan mereka secara berlebihan agar sesuai dengan pedoman Anda - sebaliknya minta mereka untuk melakukannya dan katakan pada mereka bahwa itu akan membuat pemeliharaan kode jauh lebih mudah bagi Anda setelah mereka menyelesaikan proyek.

Pertama, ini bukan masalah off shoring, ini masalah manajemen vendor

Ya, Anda membuat banyak kesalahan ...

Mereka melakukan apa yang dibutuhkan tetapi saya perlu melakukannya dengan benar, dan karenanya perubahan. apakah saya benar-benar tidak adil?

Ya, itu wajar, Jika Anda menginginkannya dilakukan dengan cara tertentu, Anda seharusnya mengatakan bahwa sebelum harga disepakati, sehingga mereka dapat mengajukan penawaran yang sesuai.

Mengapa saya setuju membiarkan mereka kode tanpa spesifikasi fungsional? Karena Anda tidak ingin MEMBAYAR untuk spec! Dokumentasi memakan waktu dan mahal, haruskah mereka melakukannya secara gratis?

Mengapa saya tidak memastikan bahwa mereka memahami segalanya pertama kali?

Mereka mengerti. Tetapi pada pertemuan pertama Anda SETELAH kontrak itu ditandatangani (dan harga tetap disepakati) adalah ketika Anda DIPERLIHATKANNYA! Jadi perlu untuk memotong biaya (jam) di mana setiap mereka bisa .. Pada dasarnya hanya dengan mengadakan satu pertemuan seminggu, tidak memberikan opsi confutation.

Berikut adalah cara melakukan ini di lain waktu ... Dalam Dua fase ...

Fase 1: Minta mereka Kumpulkan persyaratan, lakukan analisis sistem dan tulis Desain Teknis dan \ atau Spesifikasi fungsional (Atau tulis sendiri). Setujui harga untuk Fase ini. Pastikan untuk menjelaskan tidak ada komitmen di pihak Anda untuk memberi mereka tahap pengembangan. Pastikan untuk memasukkan waktu untuk rapat dalam harga.

Fase 2: Minta mereka untuk mengajukan tawaran berdasarkan spesifikasi yang sekarang mereka (dan Anda) miliki, dan benar-benar tahu upaya yang dilakukan. Sekali lagi pastikan untuk memasukkan waktu untuk rapat dalam harga. Karena untuk memasukkan anggaran opsional kecil untuk perubahan.

Sunting: Saya ingin menambahkan poin tambahan .. Vendor juga salah di sini, bagian dari pekerjaan di sana juga membantu memandu Anda dengan manajemen proyek, dan memberi tahu Anda di mana ada kekurangan dalam prosesnya.

Saya membutuhkannya dengan benar

Maka jangan outsourcing, atau jika Anda melakukannya pastikan mereka bekerja di tim proyek Anda dan bahwa Anda berpartisipasi dalam ulasan kode pada saat itu.

Proyek selesai setelah 3 minggu dan mereka mengirimkan apa yang dibutuhkan. Pada saat itu saya mulai meninjau kode.

Sekali lagi, Anda seharusnya meninjau kode selama proyek, bukan setelahnya.

Mereka berkata, karena harganya sudah tetap, saya tidak adil dalam meminta mereka untuk melakukan perubahan begitu mereka menyelesaikan kode kerja.

Anda membayar mereka harga tetap untuk kode kerja. Ups. Itu bukan kesalahan mereka, itu milikmu. Bayar waktu mereka untuk berpartisipasi dalam sprint yang Anda kontrol dan Anda tidak akan mengalami masalah ini. Anda harus membayar mereka untuk waktu dan cerita pengguna yang diterima, bukan untuk kode.

Dalam pertemuan pertama saya dengan mereka (selalu IM) saya menjelaskan dengan seksama apa yang harus mereka lakukan. Mereka tampaknya memahaminya - dan mereka sangat yakin bahwa itu akan dilakukan dengan mudah.

Ketika berurusan dengan proyek yang sepenuhnya outsourcing, Anda perlu memastikan spesifikasi Anda sangat ketat. Jika Anda harus menjelaskan sesuatu yang membutuhkan waktu lebih dari beberapa kalimat, maka spesifikasi Anda tidak lengkap. Inilah sebabnya mereka berbelok dari spec.

Ketika saya bertanya kepada salah satu pengembang apakah dia mengenal XMPP, dia bilang dia bekerja dengannya untuk pertama kalinya.

Adalah umum ketika outsourcing ke negara-negara offshoring berbiaya rendah bagi pengembang untuk meningkatkan resume dan keterampilan mereka hanya untuk mendapatkan pekerjaan. Mereka sering tidak khawatir tentang kemampuan mereka sampai mereka mendarat, karena banyak dari mereka hanya melanjutkan membangun untuk mendarat pertunjukan yang benar-benar membayar upah hidup yang nyaman.

Mengapa saya setuju membiarkan mereka kode tanpa spesifikasi fungsional?

Hanya Anda yang bisa menjawabnya sendiri, tetapi menganggapnya sebagai pengalaman belajar untuk waktu berikutnya.

Perusahaan mempekerjakan mereka melalui Elance dengan harga tetap. Pada saat itu bos saya meninggalkan saya sendirian untuk menangani mereka dan menyelesaikan pekerjaan. Saya membuat spesifikasi terperinci dari hal lengkap yang perlu dilakukan.

Jadi Anda berdua pertama membuat kontrak dan kemudian mereka membiarkan Anda menulis spec, dan mereka menerima bahwa spesifikasi untuk menjadi bagian dari kontrak Anda? Jika memang begitu, maka itu bukan kesalahan Anda, itu kesalahan kontraktor Anda. Anda bisa dengan mudah menulis spec yang memberi mereka 3 bulan kerja, bukannya 3 minggu - semuanya dengan harga yang sama.

Sebagian besar tidak apa-apa, tetapi ada beberapa masalah penting:

• mereka mengkodekan beberapa hal yang perlu dipisahkan menjadi file konfigurasi
• ada beberapa file konfigurasi yang perlu saya konsolidasi menjadi satu
• mereka menulis sama sekali TIDAK dokumentasi
• beberapa perubahan kecil lainnya

Apakah ini bagian dari spec Anda? Jika mereka, itu adalah kesalahan mereka. Jika tidak, itu milikmu. Jika tidak benar-benar jelas apakah hal-hal ini terkandung dalam spesifikasi, maka itu juga salah Anda, karena Anda menulis dokumen. Cobalah untuk menulis spesifikasi yang lebih baik lain kali.

Saya melakukan presentasi beberapa waktu lalu tentang offshoring. Itu disebut "Global Outsourcing, 10 tips untuk memberdayakan bisnis Anda". Berikut ini adalah ringkasan dari 10 tips (ini berasal dari hingga 400 proyek outsourcing):

Sebuah pilihan

1. Hindari penawar terendah dan tertinggi . Ini hanya jelas, Anda tidak ingin mengambil risiko dengan penawar yang lebih rendah dan penawar tertinggi cenderung kurang bernilai (nilai / harga) daripada median.

2. Periksa peringkat (atau referensi) . Saya selalu memeriksa referensi & peringkat.

3. Prioritaskan motivasi . Dengan harga yang sama, saya memilih tawaran yang termotivasi. Misalnya meminta penawar berbicara tentang proyek Anda dengan benar adalah pertanda baik.

B. Pengawasan

1. Lindungi kekayaan intelektual Anda . Ini adalah salah satu kesalahan terbesar. Biasanya ditangani oleh platform yang Anda gunakan (seperti vworker atau elance).

2. Tolak kerangka kerja khusus . Atau Anda berisiko terikat dengan itu, atau lebih khusus untuk pengembang yang menulisnya;)

3. Menerapkan standar . Terkait dengan tip sebelumnya. Menggunakan standar meningkatkan nilai kode sumber Anda karena dapat dipahami oleh sejumlah besar pengembang.

4. Tinjau lebih awal, sering tinjau . Sebagian besar masalah dapat "disesuaikan" jika Anda meninjau kode sumber setelah minggu pertama atau pekerjaan.

C. Strategi

1. Uji penyedia dengan proyek-proyek kecil . Sebelum saya memberikan proyek besar kepada penyedia, saya mengujinya dengan satu atau dua proyek yang lebih kecil.

2. Terima beberapa penawar untuk mengurangi risiko . Untuk proyek kritis, saya memilih dua atau tiga penawar kemudian saya mengambil implementasi terbaik. Bekerja paling baik dengan proyek kecil (di bawah $ 5.000).

3. Merakit komponen . Strategi lain adalah melakukan outsourcing komponen yang Anda rakit nanti. Satu keuntungan adalah bahwa Anda dapat dengan mudah beralih di antara penyedia dan tidak ada yang benar-benar mendapatkan akses ke semuanya (mengurangi risiko kekayaan intelektual).

Saya sepenuhnya setuju dengan jawaban maple_shaft.

Anda menerima kode dan saya menganggap menulis cek, lalu meninjau kode, Anda semacam melakukan semuanya mundur.

Mengapa saya setuju membiarkan mereka kode tanpa spesifikasi fungsional?

Karena Anda tidak menuliskannya dalam kontrak. Karena Anda ingin pekerjaan selesai, Anda menerima alasan mereka, meskipun justru itulah yang membuat Anda kesulitan.

Mengapa saya tidak memastikan bahwa mereka memahami segalanya pertama kali?

Anda harus memberi mereka desain yang Anda rasa akan berhasil. Maka tidak masalah jika mereka tidak mengerti sepenuhnya. Maksud saya Anda tidak membayar mereka untuk melakukannya sehingga siapa yang akan melakukannya? Bagaimana kode ini akan dipertahankan tanpa dokumentasi dan spesifikasi desain. Jawabannya kemungkinan tidak akan .

Mereka berkata, karena harganya sudah tetap, saya tidak adil dalam meminta mereka untuk melakukan perubahan begitu mereka menyelesaikan kode kerja.

Anda beruntung mereka membuat perubahan yang Anda inginkan. Mereka bisa mengatakan: nasib sial

Adakah yang menemukan diri mereka dalam posisi yang sama? Apakah Anda pikir ada cara yang lebih baik untuk mengelola proyek outsourcing?

Tentu saja orang lain berada di posisi Anda sebaliknya, seluruh industri "outsourcing" tidak akan merugikan, banyak perusahaan mulai menyadari harus membayar (atau menunggu) untuk melakukannya 3 dan 4 kali lebih mahal daripada melakukannya dengan benar sekali .

Setidaknya dengan melakukannya sendiri, Anda dapat memeriksa status proyek setiap hari. Jika Anda berada di belakang ada hal-hal yang dapat Anda lakukan untuk mengendalikan kerusakan, setidaknya secara teori.