🥇Bagaimana kami bekerja dengan ide, dan bagaimana LANBIX lahir

Ada banyak karyawan kreatif di LANIT-Integration. Ide-ide untuk produk dan proyek baru benar-benar menggantung di udara. Terkadang sangat sulit untuk mengidentifikasi yang paling menarik. Oleh karena itu, bersama-sama kami mengembangkan metodologi kami sendiri. Baca artikel ini tentang cara memilih proyek terbaik dan mengimplementasikannya.

Di Rusia, dan di dunia secara keseluruhan, sejumlah proses sedang berlangsung yang mengarah pada transformasi pasar TI. Berkat peningkatan daya komputasi dan munculnya server, jaringan, dan teknologi virtualisasi lainnya, pasar tidak lagi membutuhkan perangkat keras dalam jumlah besar. Vendor semakin memilih untuk bekerja dengan pelanggan secara langsung. Pasar TI sedang mengalami lonjakan outsourcing dalam segala bentuknya, mulai dari outsourcing klasik hingga gelombang baru outsourcing – “penyedia cloud.” Sistem dan elemen infrastruktur menjadi lebih mudah untuk dipelihara dan dikonfigurasi. Kualitas perangkat lunak meningkat setiap tahun dan tugas integrator diubah.

Bagaimana kita bekerja dengan ide

Arah permulaan produk masuk "Integrasi-LANIT" telah ada selama lebih dari setahun. Tujuan utama kami adalah menciptakan produk baru dan memasarkannya. Hal pertama yang kami mulai adalah mengatur proses pembuatan produk. Kami telah mempelajari banyak metodologi, dari yang klasik hingga yang hype. Namun, tidak satupun dari mereka memenuhi kebutuhan kami. Kemudian kami memutuskan untuk menggunakan metodologi Lean Startup sebagai dasar dan menyesuaikannya dengan tugas kami. Lean Startup adalah teori kewirausahaan yang diciptakan oleh Eric Ries. Hal ini didasarkan pada prinsip, pendekatan, dan praktik konsep seperti lean manufacturing, pengembangan pelanggan, dan metodologi pengembangan fleksibel.

Adapun pendekatan langsung terhadap manajemen pengembangan produk: kami tidak menemukan kembali roda, namun menerapkan metodologi pengembangan yang sudah ada SCRUM, menambah kreativitas, dan sekarang bisa disebut SCRUM-WATERFALL-BAN. SCRUM, meskipun fleksibel, merupakan sistem yang sangat kaku dan cocok untuk mengelola tim yang bertanggung jawab hanya pada satu produk/proyek. Seperti yang Anda pahami, bisnis “integrasi” klasik tidak melibatkan penugasan spesialis teknis penuh waktu untuk mengerjakan satu proyek (ada pengecualian, tetapi sangat jarang), karena selain mengerjakan produk, semua orang sibuk dengan proyek saat ini. Dari SCRUM kami membagi pekerjaan menjadi sprint, pelaporan harian, retrospektif, dan peran. Kami memilih Kanban untuk alur tugas kami dan terintegrasi dengan baik ke dalam sistem pelacakan tugas kami yang ada. Kami menyusun pekerjaan kami dengan mengintegrasikan secara mulus ke dalam tatanan yang ada.
Sebelum memasuki pasar, suatu produk melewati 5 tahap: ide, seleksi, konsep, MVP (lebih detail di bawah) dan produksi.

Ide

Pada tahap ini ada sesuatu yang fana – sebuah ide. Idealnya, sebuah ide untuk memecahkan masalah yang ada atau masalah klien. Kami tidak kekurangan ide. Menurut rencana awal, mereka harus dihasilkan oleh karyawan di bidang teknis. Agar suatu ide dapat diterima untuk dikembangkan lebih lanjut, penulis harus mengisi “Template Desain Ide”. Hanya ada empat pertanyaan: Apa? Untuk apa? Siapa yang butuh ini? Kalau bukan produk kita, lalu apa?

Источник

Pilihan

Segera setelah template yang sudah selesai sampai kepada kami, prosedur pemrosesan dan pemilihan dimulai. Tahap seleksi merupakan tahap yang paling memakan waktu. Pada tahap ini terbentuk hipotesis masalah (bukan tanpa alasan saya sebutkan di paragraf sebelumnya bahwa idealnya sebuah ide harus menyelesaikan masalah klien) dan nilai produk. Hipotesis skala terbentuk, yaitu. bagaimana bisnis kita akan tumbuh dan sejahtera. Wawancara masalah dan ahli dilakukan dengan calon pelanggan untuk memberikan konfirmasi awal bahwa kami akan menghasilkan sesuatu yang dibutuhkan. Setidaknya dibutuhkan 10-15 wawancara untuk menarik kesimpulan tentang kebutuhan produk.

Jika hipotesis dikonfirmasi, analisis keuangan awal dilakukan, perkiraan volume investasi dan kemungkinan pendapatan investor dinilai. Sebagai hasil dari tahap ini, lahirlah sebuah dokumen bernama Lean Canvas dan dipresentasikan kepada manajemen.

Konsep

Pada tahap ini, sekitar 70% ide dihilangkan. Jika konsep disetujui, barulah tahap pengembangan ide dimulai. Fungsionalitas produk masa depan dibentuk, jalur implementasi dan solusi teknis optimal ditentukan, dan rencana bisnis diperbarui. Hasil dari tahap ini adalah spesifikasi teknis pengembangan dan kasus bisnis yang rinci. Jika berhasil, kita lanjut ke tahap MVP atau MVP.

MVP atau MVP

MVP adalah produk minimum yang layak. Itu. sebuah produk yang belum sepenuhnya dikembangkan, tetapi sudah dapat memberikan nilai dan menjalankan fungsinya. Pada tahap pengembangan ini, kami harus mengumpulkan masukan dari pengguna sebenarnya dan melakukan perubahan.

Produksi

Dan tahap terakhir adalah produksi. Tidak lebih dari 5% produk mencapai tahap ini. 5% ini hanya mencakup produk yang paling penting, perlu, layak, dan fungsional.

Kami memiliki banyak ide dan telah mengumpulkan portofolio yang banyak. Kami menganalisis setiap ide dan melakukan segalanya untuk memastikan ide tersebut mencapai tahap akhir. Sangat menyenangkan bahwa rekan-rekan kami tidak tetap acuh tak acuh terhadap arah penelitian dan pengembangan kami dan mengambil bagian aktif dalam pengembangan dan implementasi produk dan solusi.

Bagaimana kami membuat LANBIX

Mari kita lihat pembuatan produk menggunakan contoh nyata - produk LANBIX. Ini adalah sistem perangkat lunak dan perangkat keras “kotak” yang dirancang untuk memantau infrastruktur TI kecil dan segera memperingatkan pengambil keputusan dan pengguna bisnis tentang malfungsi yang dikendalikan melalui chatbot. Selain fungsi pemantauan, LANBIX menyertakan fungsionalitas Help Desk. Produk ini eksklusif untuk segmen pasar yang kami bidik. Ini adalah keuntungan sekaligus penderitaan kami. Tapi hal pertama yang pertama. Saya akan segera mengatakan bahwa LANBIX adalah produk yang hidup (yaitu, belum final dalam pengembangannya dan berada pada putaran MVP berikutnya).

Jadi tahap pertama adalah ide. Agar sebuah ide bisa lahir, Anda memerlukan masalah, dan kamilah yang memilikinya, atau lebih tepatnya bukan kami, melainkan teman kami. Di bawah ini kita akan melihat beberapa situasi nyata yang terjadi di berbagai bidang bisnis.

Sebuah perusahaan manajemen kecil mengelola dua rumah di wilayah Moskow. Staf dengan PC sekitar 15 orang. Administrator sistem adalah pekerja lepas yang berkunjung (anak pintar dari salah satu penghuni yang peduli). Tampaknya aktivitas perusahaan manajemen sedikit bergantung pada TI, namun kekhasan bisnis ini adalah pelaporan bulanan ke banyak otoritas. Disk sistem pimpinan perusahaan (yang, seperti biasa, menggabungkan banyak peran) telah kehabisan ruang kosong. Tentu saja, hal ini tidak terjadi secara tiba-tiba; peringatan tersebut digantung selama sekitar 2 bulan dan terus-menerus diabaikan. Namun pembaruan telah tiba, OS telah diperbarui dan, semoga beruntung, OS terhenti di tengah pembaruan, mengeluh sebelum "mati" tentang disk yang sibuk. Komputer melakukan reboot siklik. Saat kami sedang menyelesaikan masalah dan mendapatkan laporan, kami melewatkan tenggat waktu pelaporan. Tampaknya kerusakan sepele telah menyebabkan berbagai masalah: mulai dari kerugian hingga litigasi dan tanggung jawab administratif.

Источник

Kejadian serupa terjadi di sebuah perusahaan induk besar, yang menyatukan banyak perusahaan kecil, dengan satu layanan dukungan teknis untuk seluruh kantor. Di salah satu departemen, komputer kepala akuntan rusak. Sudah lama diketahui bahwa komputer bisa rusak (komputer menjadi sangat lambat dan memanas), tetapi kepala akuntan tidak pernah sempat mengirimkan permintaan ke dukungan teknis. Tentu saja, itu rusak tepat pada hari gajian, dan karyawan departemen tidak punya uang selama beberapa hari.

Sebuah usaha kecil dalam perdagangan grosir kecil memiliki situs penjualan, yang dihosting di situs eksternal. Kami mengetahui tentang tidak tersedianya melalui telepon dari pelanggan tetap. Pada saat panggilan ditelepon, situs tersebut telah down selama sekitar tiga jam. Butuh beberapa jam lagi untuk menemukan orang yang bertanggung jawab atas situs tersebut, dan dua jam lagi untuk memperbaiki masalahnya. Oleh karena itu, situs tersebut tidak tersedia hampir sepanjang hari kerja. Menurut direktur komersial perusahaan, downtime ini merugikan mereka sekitar 1 juta rubel.

Saya sendiri mengalami situasi serupa ketika saya datang untuk membuat janji di klinik dan harus pergi ke pendaftaran VHI. Mereka tidak dapat mengirim saya ke dokter karena alasan sepele - ada lonjakan listrik di pagi hari, dan setelah kecelakaan itu, layanan pos mereka dan layanan tertentu untuk berkomunikasi dengan perusahaan asuransi tidak berfungsi. Menanggapi pertanyaan saya, di mana admin Anda, saya diberitahu bahwa admin mereka datang dan mengunjungi mereka seminggu sekali. Dan sekarang (saat itu sudah pukul 16) dia tidak mengangkat teleponnya. Setidaknya selama 00 jam, klinik tersebut terputus dari dunia luar dan tidak dapat memberikan layanan berbayar.

Apa persamaan dari semua kasus ini? Sebenarnya semua masalah sebenarnya bisa dicegah sebelumnya. Dengan respons yang tepat waktu dari orang-orang TI, kerusakan yang terjadi dapat dikurangi. Hal ini mungkin terjadi jika gejala awal diinterpretasikan dengan benar oleh pengguna.

Kami telah mengidentifikasi hipotesis masalah:

kerugian moneter dan reputasi yang signifikan karena rendahnya kecepatan respons terhadap kesalahan pada infrastruktur TI;
kesalahan penafsiran gejala awal kerusakan oleh pengguna.

Apa yang dapat dilakukan pelanggan terhadap hal tersebut, dan bagaimana cara menghindari situasi serupa di masa mendatang? Tidak banyak pilihan:

mempekerjakan administrator sistem yang berkualifikasi tinggi dan memaksanya bekerja dengan sungguh-sungguh;
melakukan outsourcing pemeliharaan TI ke perusahaan layanan khusus;
secara mandiri menerapkan sistem pemantauan dan pelaporan kesalahan;
memberikan pelatihan kepada pengguna/tenaga usaha tentang dasar-dasar literasi komputer.

Mari kita pilih opsi ketiga. Mari tawarkan sistem pemantauan kepada mereka yang tidak menggunakannya karena berbagai alasan.

Penyimpangan liris. Berbagai sistem untuk memantau layanan TI di pasar perusahaan telah digunakan sejak lama, dan manfaatnya tidak diragukan lagi. Saya berbicara dengan perwakilan perusahaan besar, melihat bagaimana hubungan antara bisnis dan TI dibangun. Direktur teknis sebuah perusahaan pembuat mesin besar telah mengalihkan pemeliharaan infrastruktur TI ke perusahaan eksternal, namun dia sendiri tetap mengetahui segala hal. Di kantornya tergantung layar sistem pemantauan besar dengan indikator status layanan TI. Yang paling penting termasuk dalam sistem. Kapan saja, direktur teknis dapat mengetahui kondisi infrastruktur, apa yang terjadi, di mana permasalahannya, apakah pihak yang bertanggung jawab sudah diberitahu, dan apakah permasalahannya sudah teratasi.

Kisah-kisah di atas membuat tim kami berpikir tentang bagaimana menciptakan sistem pemantauan yang optimal untuk perusahaan kecil. Hasilnya, lahirlah LANBIX - sebuah sistem pemantauan yang dapat digunakan oleh siapa saja tanpa pengetahuan TI apa pun. Tujuan utama dari sistem ini sederhana, seperti semua sistem yang bertujuan untuk meningkatkan kontinuitas dan ketersediaan - mengurangi kerugian moneter dan kerugian lainnya jika terjadi downtime yang tidak direncanakan. Perangkat ini dirancang untuk meminimalkan waktu antara “ada yang rusak” dan “masalah telah diperbaiki”.

Untuk mengkonfirmasi hipotesis, wawancara masalah dilakukan. Saya tidak dapat membayangkan berapa banyak orang yang bersedia memberi tahu tanpa berusaha menjualnya kepada mereka. Setiap percakapan berlangsung setidaknya 1,5 jam, dan kami menerima banyak informasi berguna untuk pengembangan lebih lanjut.

Mari kita rangkum hasil dari tahap ini:

ada pemahaman tentang masalahnya,
pemahaman tentang nilai - ada,
Ada ide untuk solusinya.

Tahap kedua lebih detail. Berdasarkan hasil tersebut, kami harus mempresentasikan kepada manajemen, yang pada dasarnya berperan sebagai investor, sebuah kasus bisnis (Lean Canvas yang sama) untuk membuat keputusan tentang nasib produk di masa depan.

Kami memulai dengan riset pasar dan analisis persaingan untuk mengetahui siapa, apa, dan yang terpenting, bagaimana kinerja mereka di pasar ini.

Ternyata sebagai berikut.

Tidak ada sistem pemantauan kotak siap pakai di pasar untuk segmen kami (usaha kecil), kecuali beberapa atau tiga, yang tidak akan saya bicarakan karena alasan yang jelas.
Pesaing utama kami, anehnya, adalah administrator sistem dengan skrip buatan sendiri dan “add-on” untuk sistem pemantauan sumber terbuka.
Ada masalah yang jelas dalam penggunaan sistem pemantauan sumber terbuka. Ada sistemnya, ada banyak sekali informasi tentang cara bekerja dan memodifikasi sistem sesuai kebutuhan Anda. Dari para pengurus yang saya wawancarai, banyak yang mengakui bahwa mereka tidak memiliki kompetensi yang cukup untuk menerapkan ide-ide mereka sendiri. Namun mereka tidak bisa mengakui hal ini kepada manajemen karena takut dipecat. Ternyata itu adalah lingkaran setan.

Kami kemudian melanjutkan untuk menganalisis kebutuhan pelanggan potensial kami. Kami telah mengidentifikasi sendiri segmen organisasi kecil yang karena alasan tertentu tidak memiliki layanan TI sendiri, di mana administrator sistem, pekerja lepas, atau perusahaan jasa bertanggung jawab atas TI. Bukan sisi TI yang memutuskan untuk masuk, namun sisi bisnis, yang menawarkan kepada para pendiri dan pemilik bisnis alat untuk meningkatkan kualitas layanan infrastruktur TI. Sebuah produk yang seharusnya membantu pemilik mengamankan bisnisnya, namun pada saat yang sama akan menambah pekerjaan bagi orang-orang yang bertanggung jawab di bidang TI. Produk yang menyediakan alat bagi bisnis untuk memantau kualitas dukungan TI.

Sebagai hasil dari pemrosesan data yang diterima, daftar persyaratan pertama (semacam simpanan kasar) untuk produk masa depan lahir:

sistem pemantauan harus didasarkan pada solusi sumber terbuka dan, akibatnya, murah;
mudah dan cepat untuk dipasang;
seharusnya tidak memerlukan pengetahuan khusus di bidang TI, bahkan seorang akuntan (saya sama sekali tidak ingin menyinggung perwakilan profesi ini) harus dapat menerapkan dan mengkonfigurasi sistem;
harus secara otomatis mendeteksi objek untuk dipantau di jaringan;
harus secara otomatis (dan idealnya secara otomatis) menginstal agen pemantauan;
harus dapat memantau layanan eksternal, minimal sistem CRM dan website penjualan;
harus memberi tahu pihak bisnis dan administrator sistem mengenai masalah;
tingkat kedalaman dan “bahasa” peringatan harus berbeda untuk administrator dan bisnis;
sistem harus disuplai dengan perangkat kerasnya sendiri;
besi harus dapat diakses semaksimal mungkin;
sistem harus independen mungkin dari faktor eksternal.

Selanjutnya, investasi dalam pengembangan produk dihitung (termasuk biaya tenaga kerja untuk karyawan departemen teknis). Sketsa model bisnis disiapkan dan unit ekonomi produk dihitung.

Hasil tahap:

simpanan produk tingkat tinggi;
model bisnis yang dirumuskan atau hipotesis skala yang belum diuji dalam praktik.

Mari kita beralih ke tahap berikutnya - konsep. Di sini kita, sebagai insinyur, menemukan diri kita dalam elemen asli kita. Ada “wish list” yang diuraikan menjadi komponen/subsistem/fitur, lalu diubah menjadi spesifikasi teknis/cerita pengguna, lalu menjadi proyek, dll. Saya tidak akan membahas secara rinci proses penyiapan serangkaian pilihan alternatif; mari kita langsung ke persyaratan dan metode yang dipilih untuk penerapannya.

Permintaan
keputusan

Ini harus menjadi sistem pemantauan terbuka;

Kami mengambil sistem pemantauan sumber terbuka.

Sistem harus sederhana dan cepat untuk dipasang;
tidak memerlukan pengetahuan TI khusus. Bahkan seorang akuntan harus mampu menerapkan dan mengkonfigurasi sistem.

Kami menawarkan sistem terinstal sehingga pengguna hanya perlu menyalakan perangkat dan sedikit mengkonfigurasinya, mirip dengan router.

Mari tutup interaksi dengan perangkat menjadi sesuatu yang sederhana dan dapat dimengerti oleh semua orang.

Mari kita buat chatbot kita sendiri untuk salah satu pengirim pesan instan terkenal dan transfer semua interaksi dengan sistem ke dalamnya.

Sistem harus:

secara otomatis mendeteksi objek yang diperlukan untuk pemantauan di jaringan;
secara otomatis menginstal agen pemantauan;
Mampu memonitor layanan eksternal, minimal sistem CRM dan website penjualan.

Kami menulis add-on untuk sistem pemantauan untuk:

deteksi objek otomatis;
instalasi otomatis agen;
memantau ketersediaan layanan eksternal.

Sistem harus:

memberi tahu pihak bisnis dan administrator sistem mengenai masalah;
dapat memantau layanan eksternal, setidaknya sistem CRM dan situs penjualan. Tingkat kedalaman dan “bahasa” pemberitahuan harus berbeda untuk administrator dan bisnis.
Sistem tidak memerlukan pengetahuan TI khusus; bahkan seorang akuntan pun harus mampu menerapkan dan mengkonfigurasi sistem.

Mari tambahkan berbagai jenis notifikasi untuk berbagai jenis pengguna. Mereka berbeda dalam nada dan kedalaman. Pengguna bisnis akan menerima pemberitahuan seperti “semuanya baik-baik saja, tetapi komputer Ivanov akan segera mati.” Administrator akan menerima pesan lengkap tentang kesalahannya, siapa, bagaimana dan apa yang terjadi atau bisa terjadi.
Mari tambahkan kemampuan untuk menggunakan surat dari orang yang bertanggung jawab tambahan, sehingga jika terjadi gangguan dia akan menerima pesan.
Mari tambahkan interaksi dengan penyedia layanan eksternal berdasarkan pengiriman email dengan teks yang sudah disiapkan sebelumnya, karena Email itulah yang menyebabkan insiden tersebut.
Semua interaksi dengan sistem akan terhubung ke chatbot; komunikasi dilakukan dengan gaya dialog.

Tambahan:

Mari tambahkan fungsi "mengobrol dengan administrator" sehingga pengguna dapat mengirim pesan kepada administrator yang menjelaskan masalahnya secara langsung.

Sistem harus disuplai pada perangkat kerasnya sendiri.
Besi harus tersedia.
Sistem harus sedapat mungkin mandiri dari lingkungan.

Mari kita ambil komputer Raspberry PI yang sudah jadi dan murah.
Kami akan merancang papan catu daya yang tidak pernah terputus.
Mari tambahkan modem agar tidak bergantung pada status jaringan lokal.
Kami akan merancang bangunan yang indah.

Kami sekarang memiliki tiga subsistem dengan persyaratan dan visi implementasinya masing-masing:

subsistem perangkat keras;
subsistem pemantauan;
subsistem interaksi pengguna.

Kami mengembangkan desain awal untuk subsistem perangkat keras. Ya ya! Setelah melanggar semua aturan agile, kami mengembangkan dokumen, karena pabrik bekerja dengan dokumen. Untuk subsistem lainnya, kami mengidentifikasi pengguna (orang), menyiapkan cerita pengguna, dan menulis tugas untuk pengembangan.

Ini mengakhiri tahap konsep, dan hasilnya adalah:

proyek untuk platform perangkat keras;
merumuskan visi dalam bentuk cerita pengguna untuk dua subsistem yang tersisa;
prototipe perangkat lunak yang diimplementasikan sebagai mesin virtual;
prototipe perangkat keras, diimplementasikan dalam bentuk stand, di mana solusi perangkat keras benar-benar diuji kekuatannya;
pengujian dilakukan oleh admin kami.

Permasalahan pada tahap ini sebagian besar bersifat organisasional dan terkait dengan kurangnya pengetahuan staf teknik dalam aspek hukum dan akuntansi penjualan. Itu. Mencari tahu apa dan bagaimana cara menjualnya adalah satu hal, dan menghadapi mesin hukum yang kejam adalah hal lain: paten, tugas pengembangan, pendaftaran, EULA, dan banyak lagi yang pada awalnya tidak kita perhitungkan, sebagai orang kreatif.

Belum ada masalah, melainkan kesulitan yang terkait dengan desain selungkupnya. Tim kami hanya terdiri dari para insinyur, jadi versi pertama casing ini “dibuat” dari kaca plexiglass oleh spesialis elektronik kami.

Bodinya terlihat agak kontroversial, terutama bagi masyarakat yang dimanjakan oleh teknologi modern. Tentu saja ada penikmat "Kulibins" di kalangan generasi tua - bangunan itu membangkitkan perasaan nostalgia dalam diri mereka. Diputuskan untuk memproduksi dan mendesain kasing baru, karena yang lama, selain kelemahan estetika, juga memiliki kelemahan struktural - kaca plexiglass tidak mentolerir perakitan dan pembongkaran perangkat dengan baik dan cenderung retak. Saya akan memberi tahu Anda tentang produksi kasus ini lebih lanjut.

Dan sekarang kita hampir mencapai garis finis - MVP. Tentu saja ini belum menjadi produk produksi akhir, namun sudah bermanfaat dan berharga. Tujuan utama tahap ini adalah meluncurkan siklus “buat-evaluasi-belajar”. Inilah tahapan LANBIX saat ini.

Pada tahap "buat", kami membuat perangkat yang menjalankan fungsi yang dinyatakan. Ya, ini belum sempurna, dan kami terus mengusahakannya.

Mari kita kembali ke pembuatan bodi, yaitu. untuk tugas mengubah perangkat kita dari nostalgia menjadi modern. Pada awalnya, saya menjelajahi pasar untuk mencari produsen kabinet dan jasa desain industri. Pertama, tidak banyak perusahaan yang memproduksi casing di pasar Rusia, dan kedua, biaya desain industri pada tahap ini sangat tinggi, sekitar 1 juta rubel.

Mereka menghubungi departemen pemasaran kami untuk desainnya; desainer muda siap untuk eksperimen kreatif. Kami menguraikan visi kami tentang lambung kapal (setelah sebelumnya mempelajari contoh terbaik konstruksi lambung kapal), dan dia, pada gilirannya, mengubahnya menjadi sebuah karya seni. Yang tersisa hanyalah memproduksinya. Kami, bangga dengan desain kami, beralih ke mitra kami. CEO mereka segera menghancurkan fantasi kami dengan menunjukkan, sepenuhnya gratis, hal-hal yang tidak dapat diproduksi dengan cara yang kami pilih. Casingnya bisa diproduksi, dan tidak akan lebih buruk dari Apple, tapi biaya casingnya akan tiga sampai empat kali lebih mahal dari semua komponen elektronik. Setelah serangkaian operasi dan persetujuan, kami telah merancang perumahan yang dapat diproduksi. Ya, ini tidak seindah yang kami rencanakan, tapi ideal untuk mencapai tujuan saat ini.

Hasil tahapan: kumpulan perangkat pertama yang siap untuk pertempuran dan pengujian.

Dan sekarang yang paling sulit adalah tahap “evaluasi”, dan dengan produk kami, kami berada tepat di titik ini. Kami hanya dapat mengevaluasi berdasarkan hasil penggunaan oleh pelanggan nyata dan tidak ada asumsi yang berlaku di sini. Kami membutuhkan “pengguna awal” untuk memberikan masukan dan melakukan perubahan pada produk yang benar-benar dibutuhkan. Timbul pertanyaan: dari mana mendapatkan pelanggan dan bagaimana meyakinkan mereka untuk ikut serta dalam eksperimen?

Dari semua opsi yang memungkinkan, kami memilih seperangkat alat digital klasik: halaman arahan dan kampanye iklan di jejaring sosial.

Prosesnya telah diluncurkan, namun masih terlalu dini untuk membicarakan hasilnya, meskipun sudah ada tanggapan dan kami telah menerima konfirmasi atas banyak hipotesis kami. Kejutan yang menyenangkan adalah reaksi dari perwakilan segmen bisnis yang sangat berbeda, jauh lebih besar dari yang kami harapkan. Akan sangat bodoh jika mengabaikan perkenalan baru ini, dan berdasarkan hasil wawancara, diputuskan untuk meluncurkan lini LANBIX paralel yang disebut LANBIX Enterprise. Kami telah menambahkan dukungan untuk infrastruktur terdistribusi, memantau jaringan Wi-Fi dengan pemecahan masalah dan lokalisasi, serta memantau kualitas saluran komunikasi. Perusahaan jasa menyatakan minat terbesarnya terhadap solusi ini. Pada saat yang sama, perangkat yang telah kami kembangkan memainkan peran penting dalam pengoperasian solusi.

Apa yang akan terjadi selanjutnya

Apa yang akan terjadi selanjutnya dengan LANBIX asli akan menjadi jelas berdasarkan hasil kampanye. Jika hipotesis kami tidak terkonfirmasi, menurut metodologi Lean, kami akan membuangnya dengan kejam atau mengubahnya menjadi sesuatu yang baru, karena tidak ada yang lebih buruk daripada membuat produk yang tidak dibutuhkan siapa pun. Namun sekarang kami dapat mengatakan bahwa pekerjaan yang dilakukan tidak sia-sia dan berkat itu, seluruh cabang produk paralel telah muncul, yang sedang kami kerjakan secara aktif. Jika berhasil, LANBIX akan berpindah dari tahap MVP ke tahap akhir dan akan berkembang sesuai dengan hukum klasik pemasaran produk yang dapat dipahami.

Saya ulangi, sekarang kami ingin mencari pengguna awal, perusahaan yang dapat memasang produk kami untuk mengumpulkan masukan. Jika Anda tertarik untuk menguji LANBIX, tulis di komentar atau pesan pribadi.

Источник

Sumber: www.habr.com

Bagaimana kami bekerja dengan ide dan bagaimana LANBIX lahir