Desain dan Pengembangan Produk Elektronik vs Produk Digital

Saya beruntung mengembangkan dan mengelola pengembangan produk fisik dan produk digital. Ketika saya berbagi cinta dan semangat untuk keduanya, saya berpikir untuk menyajikan pandangan saya dan beberapa pengamatan tentang perbedaan dan persamaan antara proses perkembangan mereka.

Apa arti dari sebuah Produk untuk ...

Apa itu produk? Sesuatu yang diproduksi dan dijual, atau sesuatu yang menciptakan nilai bagi pengguna? Definisi pertama hanya berlaku untuk produk fisik dan mencerminkan apa yang kita lakukan dengan produk dan bagaimana kita membangunnya. Definisi kedua lebih terbuka dan modern dan mencerminkan mengapa kita membutuhkan produk. Produk fisik berwujud; pengguna dapat menyentuh mereka, melihat mereka, mencium dan merasakannya. Kami semua telah melihat video dari pabrik-pabrik besar dan kami dapat memahami betapa mahal dan rumitnya pembuatannya. Produk digital hidup di cloud atau di pusat data jarak jauh. Lebih sulit bagi kita untuk memahami ukuran, kompleksitas, dan apa artinya membangunnya. Misalnya, jika kita melihat di bagian depan Google Search, kita hanya dapat melihat satu baris pencarian, tetapi di belakang layar, di bagian belakang, ada ratusan ribu server yang berjalan dan miliaran baris kode.

Ketika pengembang perangkat lunak mulai membangun produk digital, sekitar 25 tahun yang lalu, mereka menggunakan proses dan alat serupa yang digunakan untuk membangun produk fisik. Proses yang paling terbukti untuk manajemen proyek, pada saat itu, adalah Air Terjun karena menjamin kesempurnaan sepanjang siklus proyek. Namun ketika manajer proyek digital memperoleh lebih banyak pengalaman dan gagal di hampir setengah dari proyek, mereka menyadari bahwa mereka membutuhkan perubahan. Mereka mulai membangun alat mereka sendiri dan muncul dengan proses unik mereka yang tidak konvensional. Sekitar tahun 2001, semakin banyak tim mulai menggunakan Scrum dan Kanban dan manifesto lincah muncul. Git diciptakan oleh Linus Torvalds pada tahun 2005 yang meletakkan dasar untuk proyek-proyek open source. Mungkin untuk kesempurnaan produk digital tidak sepenting kelincahan. Saat ini, 25 tahun kemudian proses pengembangan, alat, dan budaya kedua tim produk sangat berjauhan.

Selama lima tahun terakhir, menjadi sangat mudah dan murah untuk menanamkan elektronik dalam produk fisik dan menghubungkannya ke internet ke beberapa jenis aplikasi - tren yang disebut IOT (Internet of things). Biayanya sekitar $ 2 per produk untuk melakukannya sehingga menjelaskan mengapa kita melihat begitu banyak produk IOT baru muncul, beberapa di antaranya cukup lucu ... Pada tingkat tim produk, tren ini menyatukan dua jenis budaya, dua jenis proses dan dua jenis alat. Setiap kali dua budaya berbenturan, hal-hal menarik mulai terjadi. Perangkat keras open source ada di sekitar kita sekarang, dan beberapa orang mulai menyebut diri mereka pembuat. Apa perbedaan antara pembuat dan produsen? Apakah kita akan melihat konvergensi antara proses-proses ini? atau apakah kita dikutuk, sebagai CTO dan manajer produk IOT menjembatani antara budaya ini selamanya?

Saya harap Anda menemukan blog ini menarik dan bermanfaat dan itu akan membantu pengembang dari seluruh tumpukan untuk memahami tantangan satu sama lain.

Peran dan Keterampilan

Ada tren baru-baru ini bagi pengembang perangkat lunak untuk mengembangkan tumpukan perangkat lunak lengkap. Ini berarti mereka mengembangkan kedua kode backend: kode yang berjalan di server / cloud, dan kode frontend: kode yang berjalan di perangkat. Mereka bahkan mungkin mengambil peran DevOps: insinyur yang bertanggung jawab untuk mengatur sistem, mengonfigurasinya, mengamankannya dan kemudian mengotomatiskan proses perubahan. Bukan tidak mungkin bagi satu orang untuk membangun dan meluncurkan aplikasi digital atau permainan sederhana. Namun, ketika melihat produk IOT yang biasanya mencakup perangkat elektronik dan semacam aplikasi, tim teknologi membutuhkan lebih banyak keterampilan dan peran.

Pengembang tertanam bertanggung jawab atas kode yang berjalan pada perangkat dan desainer papan bertanggung jawab untuk mengembangkan papan elektronik.

Meskipun hari ini, dengan bantuan Espruino, pengembang Javascript secara teoritis dapat mengembangkan ketiga level kode: kode frontend, kode backend dan kode yang disematkan, mereka mungkin akan kesulitan dengan desain industri dan papan yang membutuhkan jenis keterampilan yang sama sekali berbeda. Saya telah melihat pengembang berbakat yang merupakan pelopor dari semua perdagangan, dan dapat dengan cepat beralih dari memodifikasi kelas CSS ke penulisan skrip migrasi untuk basis data mereka. Secara pribadi, saya berpikir bahwa pengembang profesional harus menguasainya pada titik waktu tertentu hanya pada satu lapisan. Ini bukan hanya tentang memiliki keterampilan dan teknik terbaik atau menerapkan fungsi yang diperlukan, tetapi juga tentang apa yang Anda pedulikan dan dengan kondisi pikiran seperti apa Anda melakukan pekerjaan Anda.

Saya telah berupaya untuk menggambarkan tanggung jawab setiap peran dalam tim. Saya menghargai bahwa saya memasuki wilayah berbahaya karena perannya mungkin sedikit berubah di tim yang berbeda, jadi tolong coba untuk melihat hutan dan bukan pohon.

Mengapa tidak satu orang yang peduli tentang itu semua? Karena ada pengorbanan dan konflik dalam pengembangan produk, dan Anda ingin mewakili setiap kebutuhan secara seimbang dan simetris.

Selama bertahun-tahun saya telah melihat rasa hormat di antara berbagai jenis pengembang, tetapi juga kurangnya pengetahuan. Saya telah melihat pengembang frontend yang berpikir bahwa backend itu mudah, dan pengembang backend yang berpikir bahwa frontend itu membosankan. Saya juga melihat pengembang tersemat yang tidak tahu apa itu REST. Saya sebutkan sebelumnya bahwa saya tidak percaya bahwa pengembang dan insinyur profesional harus menguasai lebih dari satu lapisan. Namun, saya sangat percaya bahwa mereka harus tahu apa artinya menjadi satu dan mungkin bahkan melangkah lebih jauh dan mengerjakan proyek sederhana yang akan memaparkan mereka pada berbagai tantangan dan proses yang berbeda. Pengetahuan luas dapat membantu meningkatkan komunikasi, rasa hormat, dan transparansi di antara anggota tim, dan juga akan meningkatkan kreativitas dan produktivitas tim secara keseluruhan.

Manajemen proyek

Apa perbedaan antara proyek dan produk? Proyek adalah rencana untuk mencapai tujuan atau ruang lingkup tertentu dalam waktu dan sumber daya yang terbatas. Sebuah proyek memiliki awal dan akhir. Jika Anda tidak memiliki tenggat waktu proyek, Anda mungkin tidak mengelola proyek. Ketika proyek berakhir, produk terus hidup.

Analisis Risiko: Mari kita membahas perbedaan dan persamaan antara manajemen proyek dari produk fisik dan yang digital. Secara pribadi, saya suka menganggap manajemen proyek sebagai proses yang digerakkan oleh risiko di mana saya terus-menerus mengidentifikasi risiko-risiko utama dan mencoba membuat rencana untuk meminimalkannya. Risiko proyek adalah segala sesuatu yang memengaruhi keberhasilan proyek, yaitu gagal memenuhi tujuan, tenggat waktu, ruang lingkup, biaya, atau kualitas akhir produk. Untuk produk digital, salah satu risiko terbesar adalah membangun produk yang tidak dibutuhkan atau disukai pengguna. Manajer produk digital membayangkan, percaya, berspekulasi dan menceritakan kisah yang baik, tetapi sampai pengguna mulai berinteraksi dengan produk, ini hanya asumsi. Untuk menguji asumsi, manajer produk harus mengirim cepat, menguji hipotesis mereka dan gesit. Untuk produk fisik, risiko terbesar adalah menemukan masalah yang tidak dapat diperbaiki pada tahap yang sangat terlambat, setelah ratusan dan ribuan produk sudah diproduksi. Manufaktur membutuhkan kesempurnaan, dan tanpanya proyek akan gagal. Untuk mengurangi risiko ini, manajer proyek fisik membangun proses peninjauan dan penandatanganan antara tahap yang disebut Air Terjun.

Setiap metode dirancang untuk mengurangi risiko yang berbeda, dan setiap manajer proyek harus memutuskan rencana proyek berdasarkan analisis risiko. Terkadang individu dan interaksi lebih penting daripada proses dan alat, dan terkadang proses lebih penting. Terkadang perangkat lunak yang berfungsi lebih penting daripada dokumentasi dan terkadang dokumentasi lebih penting. Terkadang kolaborasi pelanggan lebih penting daripada kontrak tertulis. Dan kadang-kadang kontrak tertulis dapat menyelamatkan perusahaan Anda. Terkadang menanggapi perubahan itu penting, tetapi terkadang mengikuti rencana lebih penting. Anda mengerti maksud saya.

Alat dan upacara tim: Manajer proyek harus menggunakan alat yang mengimplementasikan proses yang mereka inginkan untuk mengelola proyek. Microsoft Project adalah alat yang hebat untuk proyek air terjun. JIRA dan Trello adalah alat yang hebat untuk proyek tangkas dan proses pendukung seperti Kanban dan Scrum. Apa pun alatnya, ingatlah bahwa itu hanyalah alat dan bukan esensi. Tim juga memiliki upacara yang berbeda. Di Waterfall, tim bertemu sebelum setiap musim gugur dan meninjau dokumen, output yang dihasilkan CAD atau spesifikasi pengujian. Tim lincah mungkin bertemu setiap hari untuk standup harian dan setiap dua minggu untuk perencanaan sprint. Upacara-upacara ini menyelaraskan anggota tim pada rencana dan meningkatkan komunikasi di antara anggota tim.

Desain dan Prototyping

Desain: Apakah ada produk saat ini di mana desain tidak memainkan peran utama dalam keberhasilannya? Apa itu produk jika bukan sesuatu yang ingin kita jual? Sesuatu yang harus menarik dan estetika, yang bisa kita banggakan. Lewatlah sudah hari-hari di mana memiliki fungsi dan kinerja yang tepat sudah cukup baik. Untuk produk elektronik, desain industri harus mempertimbangkan tidak hanya interaksi manusia, kegunaan dan pengalaman pelanggan tetapi juga kondisi lingkungan di mana produk tersebut digunakan dan proses pembuatannya (DFM: desain untuk manufaktur). Untuk produk digital, desain juga harus membahas berbagai perangkat yang mungkin dijalankan oleh perangkat lunak (seluler, desktop, layar besar) dan semua jenis peran dan pengguna yang berinteraksi dengannya.

Berbagai jenis metodologi desain berlaku untuk berbagai jenis produk: Desain pengalaman memandang produk sebagai bagian dari pengalaman menyenangkan yang ingin kami ciptakan yaitu: "Kami tidak menjual permainan, kami menjual pengalaman keluarga satu jam". Desain layanan akan melihat produk sebagai bagian dari layanan ujung ke ujung antara penyedia layanan dan pengguna. "Dari saat Anda memutuskan untuk bepergian sampai tiba di tujuan", "Kami tidak menjual kamera keamanan, kami menjual perlindungan 24/7 kepada Anda".

Prototyping: Dengan bantuan printer 3D dan teknologi VR / AR, sangat mudah untuk membuat prototipe mekanik produk fisik Anda. Anda dapat menunjukkannya kepada klien Anda, menaruh beberapa stiker di atasnya, menghubungkan beberapa kabel dan LED, mereka akan segera memahami tujuannya dan Anda mungkin dapat meyakinkan mereka bahwa produk Anda siap dan komersial. Anda dapat menempatkannya di lingkungan nyata dan melihat apakah itu cocok secara mekanis dan apakah itu mudah dipegang. Anda dapat membuat sepuluh versi dan membandingkan di antara mereka dan memutuskan konfigurasi akhir. Tidak ada yang lebih kuat daripada memberi klien dan investor Anda sesuatu untuk dipegang. Orang-orang menyukai mainan dan benda-benda nyata dan meskipun desain mekanik kadang-kadang hanya 1% dari produk akhir dalam hal waktu pengembangan, orang akan percaya bahwa Anda telah menyelesaikan 80% dari itu. Dengan pembuatan prototipe perangkat lunak, tidak mudah untuk mencapai level ini. Sketsa dan InVision adalah alat yang hebat, tetapi pengguna segera memahami bahwa ini bukan produk nyata. Data itu statis dan interaksinya tidak berpengaruh padanya. Ini adalah bagian dari alasan mengapa manajer produk digital mengadopsi pendekatan gesit dan konsep MVP. Sangat sulit membayangkan bagaimana pengguna akan berinteraksi dan mencintai produk Anda sebelum siap dan memiliki data nyata sehingga Anda ingin mengirimkannya sesegera mungkin dan mulai mengumpulkan umpan balik nyata.

Prototipe Fisik dan Digital

Pengembangan

Keputusan awal memiliki dampak terbesar: Setiap kali saya memulai proyek baru, saya senang. Apa yang akan menjadi arsitektur yang tepat? teknologi mana yang paling cocok untuk itu? Haruskah kita memilih MCU 8 bit atau CPU 32 bit? Apakah ini proyek yang bagus untuk memperkenalkan GraphQL, atau haruskah kita tetap dengan REST lagi? Teknologi nirkabel mana yang paling cocok digunakan: Bluetooth 5 atau Narrowband IOT? Apa basis data yang tepat untuk digunakan? PostgreSQL atau mungkin basis data grafik kali ini? Keputusan ini sangat penting untuk keberhasilan proyek. Terkadang, kami membuat keputusan teknis terlalu cepat tanpa analisis yang tepat dan kemudian tiga bulan kemudian kami menyesalinya, menjadi terlalu sulit dan menyakitkan untuk mengubahnya, dan lebih mudah untuk melihat investasi teknologi sebagai aset dan bukan sebagai penghalang. Ini berlaku baik untuk produk elektronik maupun produk digital, meskipun mengubah jenis prosesor setelah mengirim produk Anda ke pelanggan Anda hampir merupakan tugas yang mustahil jika bukan yang memalukan.

Keputusan awal memiliki dampak terbesar

Pengembangan: Ada banyak perbedaan antara proses pengembangan produk elektronik dan produk digital, dan tidak ada banyak kesamaan. Sebagian besar waktu pengembangan untuk papan PCB digunakan untuk memilih komponen yang tepat dan merancang tata letak. Beberapa pekerjaan murni teknis, menghubungkan kabel dari komponen U1 pin 120 ke komponen U17 pin 12. Dan beberapa tugas memerlukan prototipe lengkap di sekitar tiga jenis sensor hanya untuk mengukur kebisingan dan konsumsi daya masing-masing. Pengembangan tersemat sulit untuk di-debug dan dioptimalkan, cukup umum untuk melihat pengembang tersemat menggunakan pin GPIO untuk mendeteksi apakah suatu fungsi dipanggil dan untuk mengukur berapa lama waktu yang diperlukan untuk menjalankan. Menggunakan FPGA dalam produk elektronik Anda adalah keputusan berani tetapi kadang-kadang adalah satu-satunya solusi untuk mencapai tujuan kinerja / biaya Anda. Pengembangan FPGA adalah wilayah yang benar-benar berbeda dan berada di antara pengembangan ASIC, pengembangan papan PCB, dan pengembangan yang disematkan. Untuk pengembang perangkat lunak, sebagian besar waktu diinvestasikan dalam ... menulis kode. Ada sesuatu yang sangat memuaskan dalam melihat pekerjaan harian Anda, semua baris kode, komit, dan permintaan tarik. Ini kedengarannya cukup sederhana, tetapi jumlah kode dan perubahan sangat besar, sehingga manajemen konfigurasi dan proses peninjauan yang tepat sangat penting untuk menjaga basis kode terorganisir, mengurangi hutang teknis, dan meningkatkan pengetahuan di seluruh tim.

Algoritma, Fisika, dan Ilmu Data: ini biasanya merupakan otak dari produk, di mana perusahaan cenderung mengklaim IP mereka. Perancang dewan bekerja dengan fisikawan untuk memilih sensor, untuk merancang AFE (ujung depan analog) di sekitar mereka atau untuk merancang antena khusus. Pengembang yang disematkan bekerja dengan insinyur dan matematikawan DSP untuk menanamkan algoritma DSP waktu-nyata dalam perangkat lunak mereka untuk menyaring sinyal, untuk mendeteksi pola, atau menerapkan beberapa rumus matematika yang dioptimalkan untuk memproses / menyandikan data. Waktu nyata berarti Anda harus menyelesaikan pemrosesan dalam jumlah siklus CPU tertentu, jika tidak, Anda tidak akan siap memproses sinyal berikutnya dan melewatkannya atau tidak akan dapat menampilkan peristiwa dalam latensi yang diperlukan. Pengembang Backend bekerja dengan para ilmuwan data untuk menerapkan proses batch untuk merekomendasikan produk baru, menemukan anomali, menyarankan teman, melatih model pembelajaran yang mendalam, menggunakan NLP untuk menganalisis teks, menilai halaman web, dll. Pengembang Frontend memiliki semua kesenangan. Mereka melakukan visualisasi data. Dengan perpustakaan seperti D3JS, mereka membuat visual yang luar biasa dan menyajikan data kepada pengguna dengan cara yang berguna dan agregat.

Di seberang tumpukan orang-orang ini akan peduli tentang mengurangi kebisingan, meningkatkan sinyal dan menemukan keseimbangan yang tepat antara deteksi salah (false negative) dan false alarm (false positive), mereka akan menangis bahwa mereka membutuhkan lebih banyak data atau melakukan lebih banyak eksperimen, dan mereka akan melompat senang jika mereka akan berhasil meningkatkan kinerja sebesar 5%. Keputusan produk yang menarik adalah memutuskan bagaimana membagi tugas-tugas ilmu data di seluruh tumpukan. Sebagai contoh, Alexa menyertakan array mikrofon di tingkat papan, beberapa kode DSP di tingkat firmware dan ilmu data canggih di tingkat backend untuk mengenali ucapan kita.

Alat: Bayangkan pengembang frontend dan pengembang tertanam membandingkan alat pengembangan mereka satu sama lain. Pengembang yang disematkan akan membawa pengembang frontend ke mejanya dan menunjukkan perbedaan antara catu daya, osiloskop, dan penganalisis logika. Pengembang frontend kemudian akan membawa pengembang tertanam ke tempat kopi terdekat. Mereka akan memesan kopi dan menemukan tempat yang tenang di mana mereka dapat menghabiskan beberapa jam bersama. Dia kemudian akan mengalihkan browser Chrome mereka ke mode pengembangan dan menunjukkan kepada pengembang tertanam cara melihat lalu lintas jaringan dan cara melihat gaya CSS dari elemen HTML tertentu.

Apa arti devtools untuk ...

Alat debug bervariasi dari pengembang ke pengembang dan menggunakannya secara efisien adalah tempat pengalaman nyata berada. Mengetahui secara naluriah di mana masalahnya, dan menggunakan alat Anda untuk mengatasinya adalah keterampilan pengembang yang paling penting. Saya telah melihat pengembang menghabiskan waktu berjam-jam men-debug masalah, dan kemudian meminta bantuan dari pengembang berpengalaman yang menemukan masalah dalam hitungan detik. Saya tidak bisa cukup menekankan hal ini, memiliki alat yang tepat untuk setiap tugas adalah apa artinya menjadi profesional. Dan itu berlaku untuk setiap profesi.

Apa arti alat debug dan pengujian untuk ...Pengembang perangkat lunak menganggap ini menakutkan

QA dan Pengujian

Pengujian lingkungan: Saat kami menguji produk kami, kami ingin memverifikasi bahwa ia berfungsi dengan benar di semua konfigurasi dan lingkungan yang berbeda yang diharapkan pengguna untuk menggunakannya. Untuk produk fisik, lingkungan biasanya berarti suhu (sangat dingin, sangat panas), getaran (bayangkan produk otomotif), goncangan (jatuh dari tangan Anda ke lantai beton), kelembaban, UV dan radiasi matahari, ESD (penerangan kecil yang datang dari pelepasan elektro-statis), EMI / RFI, dll. Untuk lingkungan produk digital biasanya berarti jenis peramban (Chrome, Internet Explorer, Firefox ..), OS (Android, IOS, OSX, Windows), Perangkat (Ponsel, Desktop, Konferensi Layar) dan tingkat konektivitas Jaringan (4G, Wifi, Offline). Kami biasanya tidak menguji pada setiap kombinasi yang mungkin karena tidak mungkin untuk melakukannya, jadi kami datang dengan serangkaian konfigurasi yang diharapkan akan mencakup skenario yang cukup untuk mendeteksi masalah dalam spesifikasi produk.

Apa arti dari lingkungan eksternal untuk ...

Keandalan / Daya Tahan (Uji Siklus Hidup): Ini adalah tes yang mencoba mensimulasikan apa yang terjadi pada produk selama masa pakainya. Ini lebih relevan dengan produk fisik di mana bahan mencapai titik kegagalannya. Ada peraturan tertentu yang dibuat industri untuk membantu kami mempercepat usia produk dengan memaparkannya ke kondisi lingkungan yang ekstrem. Pada dasarnya, untuk menguji apakah suatu produk berfungsi dengan benar setelah lima tahun pada suhu kamar, kita dapat mengujinya pada 70 derajat dan getaran 10g untuk satu hari (contoh saja !!!). Ini disebut tes HALT (kehidupan sangat dipercepat)

Pengujian kondisi ekstrem (Muat, Tepi): Ini adalah tes yang menguji perilaku produk dalam kondisi ekstrem atau tepi. Misalnya, jika produk elektronik bekerja pada 5V, kami akan mengujinya pada 4,5V dan 5,5V, kami bahkan dapat menyuntikkan lonjakan tegangan setinggi 25V atau -5V untuk melihat apakah produk ini tahan terhadap kesalahan pengguna atau lonjakan listrik. Untuk produk digital, kami mungkin menantang bidang input dengan nilai yang tidak masuk akal. Sebagai contoh, kita dapat memasukkan nama yang panjangnya 1000 karakter, atau memiliki simbol yang tidak berarti. jika kami merancang produk untuk beban tertentu (50 pengguna bersamaan), kami akan menguji perilakunya di bawah 100 pengguna bersamaan. Gagasan tes ini terutama untuk mengungkap mode kegagalan baru. Kami tidak mengharapkan produk bekerja dengan sempurna, tetapi kami mungkin menemukan masalah penting, perilaku tak terduga atau hambatan yang relevan juga dengan kondisi normal.

Tes Kepatuhan / Keamanan: Kedua jenis produk ini kadang-kadang diperlukan untuk memenuhi standar dan mematuhi mereka. Produk elektronik harus aman, aman, dan andal serta melindungi pengguna dari sengatan listrik atau panas berlebih (UL, CE, FCC ..), mereka juga harus mematuhi standar nirkabel tertentu seperti Wifi atau Bluetooth. Produk digital yang menangani informasi pengenal pribadi (PII) seperti nomor kartu kredit (PCI, ISO / IEC 27001, NIST) atau nomor jaminan sosial (GDPR) harus melindungi data terhadap semua jenis serangan dan kelalaian karyawan. Untuk kedua produk, proses kepatuhannya mahal dan panjang, tetapi ada cara untuk mengurangi biaya dan menggunakan modul dan layanan yang disetujui sebelumnya.

Apa arti kepatuhan terhadap ...

Cakupan Tes: Sebagai perancang papan, Anda tidak pernah dapat memastikan bahwa proses pembuatannya tanpa cacat. Dalam beberapa kasus, ada celana pendek kecil di antara jejak yang berdekatan yang hanya bisa Anda lihat dengan mikroskop. Dalam kasus lain, komponen elektronik tidak cukup andal atau bahkan mungkin komponen palsu. Sebagai bagian dari proses kualitas, desainer papan dan pengembang tertanam harus bekerja bersama untuk menulis alat pengujian yang memverifikasi bahwa setiap koneksi dan setiap komponen berfungsi seperti yang diharapkan dengan cakupan 100%. Saya sudah bekerja pada pengujian JIG yang mensimulasikan setiap sensor dan setiap input ke papan untuk mencapai cakupan 100%. Ini juga merupakan praktik yang baik untuk menjalankan tes ini secara paralel dengan tes skrining sangat dipercepat (HASS) di mana papan terkena getaran dan siklus termal.

Demikian pula dengan perangkat lunak, praktik yang baik adalah menulis kode pengujian yang mencakup setidaknya 99% dari kode Anda. Sebelum menyebarkan kode baru ke lingkungan produksi alat otomatisasi menjalankan rangkaian kode pengujian dan memverifikasi bahwa apa yang pernah bekerja sebelumnya, masih berfungsi. Untuk kedua kasus bekerja pada alat pengujian ini harus mulai bersama dengan pengembangan produk (kadang-kadang bahkan sebelum: TDD) dan harus sumber daya yang tepat.

Ulasan Desain / Kode: Orang membuat kesalahan. Siapa pun yang mengira mereka tidak, tidak cukup berpengalaman atau memiliki ingatan pendek. Khususnya, ketika merancang tata letak papan PCB dan menempatkan komponen baru, sangat mudah untuk membuat kesalahan mengenai konfigurasi pinout dan dimensi fisik komponen baru. kesalahan Anda hanya akan menemukan minggu atau bulan kemudian. Anda bisa melihat desain, dan memverifikasi terhadap lembar data, melihat lagi, dan memverifikasi lagi, dan dalam kedua kasus, Anda akan melewatkannya. Untuk alasan ini, peninjauan dan penandatanganan independen adalah praktik standar dalam pengembangan produk elektronik. Pengembang perangkat lunak sering membuat kesalahan berkaitan dengan keamanan. Misalnya, mereka sering memasukkan kunci sensitif dalam repositori kode publik atau diekspos ke klien. Permintaan tarik adalah metode untuk memberi tahu anggota tim lainnya tentang perubahan Anda sebelum Anda mengkomitnya. Mereka melayani berbagai tujuan: Untuk mendeteksi cacat dan masalah, untuk meningkatkan keterbacaan dan dokumentasi kode, dan untuk berbagi pengetahuan di seluruh tim. Pemrograman pasangan adalah metode lain yang digunakan oleh pengembang perangkat lunak untuk berbagi pengetahuan dan meninjau kode masing-masing.

Manajemen Konfigurasi: CM adalah praktik penanganan perubahan secara sistematis. Ini digunakan untuk mendokumentasikan versi produk dan untuk melacak perubahan yang diterapkan di antara versi. Sistem manajemen konfigurasi yang baik akan memungkinkan Anda untuk membuat dan menguji versi produk apa pun hanya menggunakan artefak yang ada di dalamnya tanpa pengetahuan eksternal lainnya. Insinyur DevOps menggunakan alat SCM (Manajemen konfigurasi perangkat lunak) seperti GIT, Ansible, Terraform, Chef untuk merekam kode, konfigurasi, dan infrastruktur produk. Mereka mungkin juga mengikat perubahan ini dengan masalah JIRA untuk mendokumentasikan hubungan antara permintaan bug / cacat / fitur dan perubahan aktual yang dihasilkan dari itu. Insinyur elektronik menggunakan alat yang kadang-kadang disebut PLM (manajemen siklus hidup produk) dan terkadang HCM (manajemen konfigurasi perangkat keras). Pada dasarnya mereka melayani tujuan yang sama, tetapi mereka mencakup berbagai integrasi dan proses. Misalnya, sistem PLM juga dapat berintegrasi ke dalam sistem ERP Anda untuk menunjukkan bagian mana dari BOM produk yang ada dalam inventaris Anda.

Manufaktur dan Produksi

Anda harus melihat produsen Anda sebagai mitra Anda dan bukan sebagai pemasok Anda. Bagaimanapun, Anda memberi pabrik Anda aset Anda yang paling sensitif: semua yang dibutuhkan untuk membangun produk Anda! Pabrik Anda akan membantu Anda untuk memperkenalkan metode manufaktur baru, mengurangi cacat, meningkatkan efisiensi proses dan dalam beberapa cara akan berbagi beberapa risiko dan manfaat produk.

Lean Lean adalah segala sesuatu yang berkaitan dengan penghematan biaya. Untuk produk fisik, lean berarti:

  • Nol keterlambatan melalui semua tahapan jalur produksi
  • Cacat Bayar, Kualitas tertinggi untuk setiap produk akhir
  • Mesin / Orang digunakan 100%
  • Umpan balik pengetahuan: Setiap pelajaran dan wawasan meningkatkan proses
  • Hanya dalam waktu pembuatan: Setiap produk dijual, tanpa limbah

Untuk produk Digital lean artinya:

  • Penskalaan otomatis: skala sumber daya komputasi berdasarkan pada beban
  • Bayar per jam

Pabrikan Jalur Pipa: Menyiapkan jalur perakitan tidak terlalu berbeda dengan mengatur jalur pipa CI / CD perangkat lunak (Integrasi berkelanjutan / Pengiriman berkelanjutan). Jika Anda telah membaca buku proyek Phoenix, Anda mungkin akan ingat bagaimana beberapa konsep lean dan DevOps diturunkan dalam buku dari garis manufaktur fisik. Kedua pipa menangani semua yang diperlukan untuk membangun, menguji dan mengirimkan produk Anda. Ketika Anda menambahkan lebih banyak otomatisasi, Anda dapat mengirim lebih cepat. Untuk produk elektronik ini berarti mengurangi biaya dan cacat dan meningkatkan kapasitas, untuk produk digital, ini berarti pengujian pengguna yang lebih cepat dan desain adaptif.

Pengiriman seluruh dunia: Ada kesamaan yang menarik antara jaringan pengiriman konten (CDN) yang digunakan untuk mengirimkan aset web kepada pengguna berdasarkan lokasi geografis mereka, dan bagaimana manufaktur didistribusikan di seluruh dunia untuk mengurangi biaya pengiriman dan untuk melokalkan produk. Caching konten dapat dilihat sebagai gudang lokal atau layanan pemenuhan seperti Amazon. Untuk kedua jenis produk, kehadiran lokal meningkatkan pengalaman pelanggan secara keseluruhan di seluruh dunia

Tampaknya kehadiran di seluruh dunia lebih sulit untuk produk fisik, namun, peraturan perlindungan data dan lokalisasi bahasa juga membutuhkan upaya yang signifikan

Layanan cloud: Layanan cloud luar biasa, Anda dapat membangun produk digital Anda dalam hitungan detik dengan memilih dari ratusan layanan web. Beberapa klik dan itu akan berjalan secara otomatis di lebih dari 20 pusat data di seluruh dunia dan skala berdasarkan permintaan. Tidak ada yang seperti itu di bidang manufaktur tetapi ini mungkin merupakan revolusi industri berikutnya. Bayangkan sebuah produk digital di mana Anda dapat mengatur pipa manufaktur menggunakan modul yang telah dikonfigurasi sebelumnya seperti pencetakan 3D, manufaktur PCB, sumber komponen, perakitan papan dan kabel, menjalankan tes dan pengiriman langsung ke klien Anda dari lantai manufaktur otomatis lokal. Selain itu, layanan ini akan memungkinkan pengguna akhir untuk menyesuaikan warna produk, bentuk dan fitur personalisasi lainnya. Ini seperti mimpi, tetapi saya yakin bahwa di suatu tempat di seluruh dunia Amazon sedang mengerjakan layanan semacam itu (Setidaknya saya harap mereka melakukannya).

Kesimpulan

Ada banyak perbedaan antara proses pengembangan produk elektronik dan digital, tetapi melihat dari perspektif 20 tahun, Sungguh menakjubkan melihat berapa banyak prinsip desain dan proses produk digital yang sekarang digunakan oleh manajer produk fisik. AWS baru-baru ini mengumumkan tentang FreeRTOS untuk sistem embedded. Saya memperkirakan bahwa dalam 10-20 tahun tidak akan ada perbedaan yang signifikan antara proses pengembangan produk digital dan fisik.

Jika Anda ingin mengetahui lebih banyak tentang perjalanan saya, dan bagaimana mengelola tim yang tinggal di kedua dunia, jangan ragu untuk menghubungi saya secara langsung.