Kapan Anda biasanya menulis modul perangkat lunak sendiri vs membeli produk yang sudah ada?


13

Saya mencoba mencari tahu alasan keputusan Anda tentang kapan melakukan apa. Saya senang memberikan lebih banyak konteks, tetapi saya ingin menjadikannya umum untuk saat ini.


Bagaimana dengan opsi # 3, "gunakan pustaka sumber terbuka?" Itu sebenarnya bisa menjadi kompromi, karena Anda dapat menyesuaikannya dengan kebutuhan Anda.
Nathan Long

@ NathanLong: ini poin yang bagus, tapi saya berharap jika OP menanyakan pertanyaan ini, itu berarti hanya skenario ini yang menarik. Juga, suatu produk dapat berupa open source dan masih dijual secara komersial, jadi saya pikir Anda bermaksud "perangkat lunak bebas". Dan tergantung pada jenis lisensi, Anda tidak dapat selalu mengubah jika untuk kebutuhan Anda (jika Anda berencana untuk menjual kembali dan itu tidak kompatibel, misalnya), jadi ada banyak faktor berbeda untuk melihat jalan ini kemudian. (tidak mengatakan itu saran yang buruk)
haylem

Jawaban:


17

Kurasa terlalu disederhanakan, tapi semacam itu berlaku sebagai pedoman umum:

Dalam Lingkungan Pribadi

  • Apakah saya senang mengodekannya?
  • ATAU apakah saya belajar sesuatu dari mengkodekannya?

DAN:

  • Apakah saya punya cukup waktu untuk mengkodekannya?

Jika ya, maka saya lebih suka menulisnya daripada membelinya.

Dalam Lingkungan Profesional

Jika total biaya kepemilikan produk (termasuk pengembangan, pengujian, pemeliharaan, dukungan atau pengeluaran terkait) lebih tinggi dari biaya produk, dan bahwa pengembalian investasi yang dihitung tidak akan mengimbangi biaya ini, maka Anda lebih baik membelinya dan pindah.


1
+1 sangat penting untuk sesekali mengkodekan beberapa hal sendiri, jika tidak, Anda hanya akan bergabung dengan satu hal seperti tukang ledeng Internet. Anda juga harus menyeimbangkan "belajar sesuatu darinya" dan menentukan apakah Anda ingin / perlu mempelajari sesuatu itu.
Gary Rowe

2
@GaryRowe: terima kasih. Harus menolak membuat lelucon tentang "Internet Plumber" dan tren web saat ini dan pasar kerja web dev. Arggghhhh, cukup menggoda ...
haylem

Dalam lingkungan profesional, bukan hanya biaya pengembangan, tetapi juga biaya pemeliharaan yang berkelanjutan dan waktu yang hilang dalam pengembangan.
Gilbert Le Blanc

1
@GilbertLeBlanc: benar itu, Gilbert. Saya agak memaksudkan biaya ujung ke ujung, tetapi saya akan mengklarifikasi seperti yang Anda sarankan, sebagaimana seharusnya mengenai TCO produk.
haylem

9

Hal-hal yang perlu dipertimbangkan untuk keputusan membuat-atau-beli

  • biaya pengembangan / biaya pemeliharaan vs biaya produk / biaya untuk kontrak perawatan: tentu saja, itu adalah hal yang jelas, tetapi itu sebenarnya bukan satu-satunya hal. Misalnya, jika saya akan menggunakan perangkat lunak tidak hanya untuk perusahaan saya sendiri, tetapi juga ingin menjualnya kepada orang lain, maka perhitungannya terlihat sangat berbeda.

  • Ketersediaan produk yang cocok. Untuk banyak proses bisnis, tidak ada standar perangkat lunak yang tersedia. Atau ada sesuatu yang tersedia, tetapi tidak cocok, karena berisi 100 fitur yang Anda perlukan hanya 3 dengan cara yang sedikit berbeda, sementara 2 fitur penting lainnya hilang.

  • Apakah seseorang ingin mendapatkan ketergantungan dari vendor pihak ketiga? Terutama vendor yang lebih kecil memberi Anda selalu risiko bahwa vendor menghilang dari pasar di masa depan, atau pengembangan lebih lanjut dari produk tidak berjalan ke arah yang Anda butuhkan. Untuk produk yang Anda miliki di bawah kendali Anda sendiri, Anda dapat mengarahkan arah pengembangan dengan lebih baik.

  • Kapan saya memerlukan perangkat lunak tertentu, dan apa yang lebih cepat: kembangkan sendiri, atau beli sesuatu, sesuaikan sampai cocok dengan proses saya dan jalankan? Membeli sesuatu dari rak mungkin tampak alternatif yang lebih cepat dan kadang-kadang lebih murah, tetapi saya pribadi telah melihat juga skenario di mana mengembangkan perangkat lunak tepat untuk kebutuhan perusahaan, menyesuaikan dengan proses bisnis yang ada, menghemat banyak waktu dibandingkan dengan membeli sesuatu dan mengajar beberapa ratusan pengguna melakukan pekerjaan mereka dengan cara yang baru dan berbeda, sehingga biaya pengembangannya terabaikan.


8

Apa pun yang ada hubungannya dengan kriptografi. Ada 100.000 cara untuk melakukan kesalahan dan mengekspos perangkat lunak Anda terhadap kerentanan keamanan serius dan hanya beberapa cara untuk melakukannya dengan benar. Dibutuhkan keahlian tinggi untuk ini.



Ini poin yang bagus, meskipun saya pikir ada banyak hal lain yang juga layak untuk dicantumkan di bawah label "jangan main-main dengan ini". Namun, untuk penggunaan pribadi (dan selama tidak ada eksposur dan itu bukan untuk data sensitif), memberikan suntikan pada diri Anda sendiri tetap menyenangkan dengan crypto. Saya menerapkan kembali beberapa sandi untuk bersenang-senang dan belajar mandiri beberapa tahun yang lalu. Banyak masalah besar untuk dilihat, bersenang-senang melakukannya, dan belajar banyak.
haylem

Saya akan menghindari membeli crypto. Pustaka crypto tepercaya biasanya open source atau bagian dari OS. Saya mempercayai kode saya sendiri di sebagian besar pustaka sumber tertutup. Saya tidak akan menggunakan perpustakaan apa pun yang setidaknya tidak menerbitkan spesifikasi yang jelas dan lengkap tentang cara kerjanya kode kripto.
CodesInChaos

@CodesInChaos beberapa paket komersial "sumber tertutup" memberikan Anda kode sumber.
Pieter B

Sebenarnya saya pikir kode peer review lebih baik, dan dengan asumsi bahwa penyerang tidak tahu algo adalah kesalahan. Tetapi mengapa Anda bahkan menghubungkannya dengan kriptografi?
Ramzi Kahil

0
  • upaya tinggi waktu, produk pas yang ada >> membeli produk
  • minat pribadi pada teknik atau tidak ada produk yang sesuai dengan semua persyaratan >>
    kembangkan sendiri

0

Pada tingkat pribadi, saya mengembangkan kombinasi aneh dari apa yang saya inginkan dan apa yang akan menarik untuk ditulis.

Pada tingkat profesional, @haylem membuat poin keseluruhan yang bagus tentang kapan membeli dan kapan harus menulis. Saya akan mengatakan bahwa ada elemen besar yang diabaikan: kesempatan. Bagi perusahaan yang lebih besar, menurut saya, masuk akal untuk menulis lini inti aplikasi bisnis (tidak semua lini aplikasi bisnis) ketika melakukan hal itu membuat perusahaan lebih gesit. Ada biaya peluang yang terkait dengan pembelian perangkat lunak karena dengan demikian perusahaan Anda (bukan hanya TI Anda) dikunci ke cara vendor memandang domain Anda.

Untuk kebanyakan hal, itu tidak masalah. Sistem akuntansi Anda sebaiknya tidak kreatif. Pengolah kata Anda akan sama dengan yang lainnya. Tetapi hal-hal yang membuat Anda menjadi lebih baik ditulis di rumah sehingga dapat beradaptasi dengan apa yang ingin dicapai oleh bisnis Anda.


0

Ini, seperti hampir semua jawaban lain katakan, keputusan biaya-manfaat:

  • Berapa biayanya saya dalam jam kerja, bahan, dll untuk memberikan proyek ini kepada pengembang in-house, atau kontraktor eksternal, untuk pengembangan kustom? (biasanya tinggi; menghitung porsi overhead mereka, ditambah gaji dan tunjangan, pengembang yang berpengalaman akan dikenakan biaya sekitar satu ribu per hari; mungkin sedikit lebih atau kurang tergantung pada keuangan yang terlibat)
  • Berapa biayanya saya untuk membeli produk yang diketahui dari rak? (Tergantung pada produk; program penggunaan umum seperti editor teks biasanya murah, bahkan gratis, sedangkan program khusus seperti produk desain jalur sirkuit dapat menghabiskan biaya jutaan)
  • Apa manfaat yang akan saya dapatkan dari solusi yang dikembangkan khusus? (Biasanya solusi khusus lebih cocok untuk bisnis Anda dan dengan demikian dapat mengotomatisasi atau setidaknya mendigitalkannya)

Ini berujung pada apakah biaya, yang diimbangi dengan manfaat, dari solusi yang dikembangkan sesuai pesanan lebih kecil daripada biaya produk yang tidak tersedia.

Ada juga biaya peluang untuk dipertimbangkan. Memahami bahwa ini tidak termasuk dalam biaya riil pengembangan vs pembelian, tetapi di dunia yang lebih luas, Anda harus mempertimbangkannya. Jika staf pengembangan in-house Anda mengerjakan satu proyek ini, mereka tidak mengerjakan proyek lain; itu berarti jika ada proyek lain dalam daftar yang membebani Anda uang setiap hari itu tidak dilakukan, itu mungkin menjadi prioritas yang lebih tinggi yang menyebabkan Anda menangguhkan atau bahkan membatalkan pengembangan kustom dan pergi dengan paket off-the-shelf. Namun, jika tidak melakukan proyek ini berarti staf di rumah Anda duduk di tangan mereka, biaya pengembang hangus; Anda membayar staf pengembangan Anda apakah mereka bekerja atau tidak, sehingga Anda akan dikenakan biaya keseluruhan lebih sedikit jika Anda menggunakannya untuk potensi mereka.


0

Saya berasumsi Anda bertanya dalam konteks profesional, komersial, dan bahwa kita sedang berbicara tentang bagian utama dari sistem Anda daripada perpustakaan tunggal.

Buat atau Beli vs. Buat atau Kustomisasi

Ada situasi ketika organisasi Anda dapat menggunakan produk yang tidak tersedia. Misalnya, beberapa orang akan menulis pengolah kata mereka sendiri - mereka menggunakan MS Word, atau OpenOffice, atau apa pun. Sama untuk spreadsheet. Perhatikan bahwa Anda mungkin "menyesuaikan" pengolah kata Anda dengan template atau makro Anda sendiri, tetapi orang-orang tidak menganggapnya pengubahsuaian. Itu hanya "menggunakan" pengolah kata, seperti yang mereka lihat.

Dimungkinkan untuk menggunakan sistem yang lebih rumit dengan cara yang sama, dari webshop ke sistem ERP. Tetapi akan ada titik di mana desainer Anda atau orang-orang pengembangan bisnis akan menginginkan perubahan yang tidak termasuk dalam standar. Desain ulang halaman checkout, mungkin, atau cara baru untuk menghitung penawaran diskon.

Jika Anda tahu itu dari awal, maka keputusan Anda benar-benar Membuat atau Menyesuaikan . Hanya Beli tidak lagi menjadi pilihan. Dan bahkan jika tidak ada persyaratan seperti itu saat ini, apakah Anda mengharapkan kolega Anda datang dengan mereka nanti?

  • Apakah Anda diizinkan untuk menyesuaikan sistem, di luar mengunggah logo perusahaan Anda di tempat yang tepat?
  • Seberapa sulit, dan dapatkah itu dilakukan oleh staf Anda atau Anda harus mengontrakkannya kepada vendor? Perhatikan bahwa ada perusahaan yang seluruh model bisnisnya menyediakan layanan premium untuk perangkat lunak gratis yang mereka kembangkan.
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.