Offshoring Proyek Perangkat Lunak - Resolusi Konflik [ditutup]


11

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.


1
Saya belum pernah melihat proyek lepas pantai berjalan dengan baik. Saya pikir saya ada dalam cerita perang ketika saya mulai membaca ini.
smp7d

Jawaban:


13

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.


2
Anda lupa fase 3 dan fase 4: ??? dan Untung :-)
Ramhound

3
Bagaimana Anda bisa meminta entitas luar untuk menulis spesifikasi fungsional Anda? Spesifikasi fungsional adalah persyaratan dari proyek yang Anda ingin mereka kerjakan. Kalau tidak, Anda memberi mereka uang dan mengatakan kepada mereka, "Selesaikan masalah, ... Saya tidak tahu, mencari tahu apa yang harus dilakukan perangkat lunak, saya tidak dapat diganggu."
maple_shaft

1
@maple_Shaft Poin bagus, Pengumpulan persyaratan adalah bagian dari Fase 1. Saya akan memperbarui jawaban saya.
Moron

1
-1 untuk omong kosong Dogma Waterfall yang usang

3
@JarrodRoberson Saya bukan penggemar tentang metodologi tertentu. Masing-masing memiliki kelebihan, tetapi mengatakan mereka gagal hanya karena mereka tidak menggunakan Agile itu salah.
Moron

17

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.


2
Saya tidak setuju dengan "Jika Anda ingin itu dilakukan dengan benar, jangan sumber itu".
Moron

1
@Monsons Hak Anda tentu saja, itu hal yang malas untuk dikatakan. Saya hanya gagal dalam kerangka berpikir itu karena perusahaan yang paling tertarik dengan prospek offshoring adalah mereka yang paling tidak memiliki disiplin untuk melakukannya dengan benar. Jika mereka memecahkan masalah internal mereka ke tempat mereka dapat melakukannya dengan benar, maka mereka mungkin akan memiliki lebih sedikit kebutuhan untuk lepas pantai di tempat pertama.
maple_shaft

3
Itu harus mengatakan "Jika Anda ingin dilakukan dengan benar, jangan mengharapkan kualitas dari penawar terendah" , seorang teman yang adalah seorang fotografer freelancer mengatakan "Pelanggan termurah, memiliki

1
Saya juga tidak setuju dengan pernyataan itu, Anda dapat memiliki masalah yang sama persis dengan tim internal atau toko pengembangan lokal.

7

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.


3

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


1

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.


1
companies are starting to realize having to pay ... to do it 3 and 4 times is more expensive then doing it right once.Lebih dari ini, saya hanya berpikir bahwa fase bulan madu industri dengan pengembangan perangkat lunak offshoring akan segera berakhir dan lebih banyak perusahaan mulai menyadari bahwa itu bukan anak lembu emas yang mereka pikir akan menjadi ( atau diberitahu itu akan oleh konsultan ). Kebanyakan manajemen menyebalkan dan mereka tidak tahu mengapa, jadi mereka mencari solusi untuk menyelesaikan semua masalah mereka. Offshoring itu bagus jika Anda melakukannya dengan benar, tetapi sebagian besar tidak memiliki disiplin semacam itu.
maple_shaft
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.