شتابدهنده هاردتک
فرایند توسعه محصول سخت افزاری

راهنمای توسعه محصول سخت افزاری – بخش اول، ایده پردازی

راهنمای فرآیند توسعه محصول سخت‌افزاری یک مجموعه چهار قسمتی است. این مجموعه شامل چهار بخش ایده‌پردازی، طراحی، مهندسی، و تایید اعتبار می‌باشد.

داشتن فرایند در توسعه محصول سخت افزاری برای استارتاپ ها ضروری است

مطلبی که در ادامه می‌خوانید، بخش اول از چهار بخش موجود در ارتباط با فرآیند توسعه محصول سخت‌افزاری است. اگر بخش‌های دوم (طراحی)، بخش سوم (مهندسی) و بخش چهارم (تائید اعتبار) بیشتر به کارتان می‌آیند، مستقیماً برای مطالعه به آن‌ها رجوع کنید.

ایجاد محصولی که مشتریان به آن عشق بورزند، تفاوتش بین یک شرکت یک میلیارد دلاری و یک شرکت کاملاً ورشکسته است. اما با وجود الزامات هزینه‌ای و زمانی دنیای سخت‌افزاری، استارت‌آپ‌ها واقعاً تنها یک فرصت برای ارائه محصولاتشان در اختیار دارند. شکست و تکرار گزینه پیشنهادی روی میز برای استارت‌آپ‌های نرم‌افزاری است، نه فعالان در حوزه سخت‌افزار.

اگر ایجاد یک محصول فوق‌العاده انقدر اهمیت دارد، چرا بیشتر استارت‌آپ‌های سخت‌افزاری که در موردشان صحبت می‌کنیم، هرگونه فرآیندی را برای توسعه محصول رد می‌کنند؟

این مجموعه مطالب برای روشن ساختن این مسئله طراحی شده تا نشان دهد یک فرآیند توسعه محصول استارتاپی سخت‌افزاری چگونه باید باشد. 

بله، شما یک فرآیند برای توسعه محصول در اختیار دارید.

به نظر می‌رسد استارت‌آپ‌ها نسبت به هر نظم و ترتیبی که به آن‌ها تحمیل شود، واکنش آلرژيک از خود نشان می‌دهند. این در حالی است که بیشتر استارت‌آپ‌های نرم‌افزاری از پذیرش فرآیند کتاب استارت‌آپ ناب – که امروزه بسیار مشهور و رایج شده است – که توسط نویسنده این کتاب اریک ریس پیشنهاد شده، استقبال کرده‌اند:

فرایند توسعه محصول نرم افزاری

حلقه بساز-بسنج-بیاموز با فرهنگ استارت‌آپی نرم‌افزاری عجین شده است، اما برای استارت‌آپ‌های سخت‌افزاری کاستی‌هایی دارد. بیشتر استارت‌آپ‌های سخت‌افزاری فرایند توسعه محصولی را می‌پذیرند که چیزی شبیه به مورد زیر باشد:

فرایند توسعه محصول سخت افزاری معمول

بیشتر استارت‌آپ‌ها فکر می‌کنند به‌کارگیری شیوه موی بر آتش (کنایه از جلب توجه و برانگیختن احساسات در فرد مقابل) سریع‌تر عمل خواهد کرد چون «هزینه سربار کمتری» به همراه دارد، اما در بلندمدت، این مسئله حقیقت ندارد.

اجزای فرانید توسعه محصول سخت افزاری

توسعه محصول سخت‌افزاری نیازمند برنامه‌ریزی بیشتری نسبت به توسعه نرم‌افزاری است؛ به این معنا که طیف بسیار زیادی از کارها، می‌بایست درست پیش از ارائه یک محصول سخت‌افزاری متصل (Connected Hardware) انجام شود. بسیاری از این کارها اگر به شکل نامناسبی انجام شوند، زمان‌های تدارک سفارش طولانی و هزینه‌های بالایی را به همراه خواهند داشت. یک اشتباه کوچک در طراحی یا یک روند کنترل کیفیت ضعیف می‌تواند شما را به ورشکستگی بکشاند.

فرآیند توسعه محصول

فرآیندی که از آن استفاده می‌کنیم، پیوندزنی فرآیندهای بسیار مؤثر تعیین‌شده توسط انجمن تولید/کیفیت و فرایندهای کوتاه مورد استفاده بسیاری از متخصصین طراحی است. این فرایند به چهار مرحله اصلی تقسیم می‌شود: ایده‌پردازی، طراحی، مهندسی و تائید اعتبار.

فرایند توسعه محصول سخت افزاری

برای بهتر به تصویر کشیدن این فرایند، ما از یک محصول خاص که با استفاده از این روش طراحی شده است، کار را دنبال می‌کنیم: دیپجر (DipJar)

محصول پایانی فرایند توسعه محصول دیپجار
اولین نسخه تولیدی دیپجر

دیپجر یک استارت‌آپ‌ جوان است که محصولی ساده را ایجاد کرده تا از کارت‌های اعتباری، انعام (Tip) و اعانه قبول کند (به‌جای پول نقد). دیپجر محصولش را یکجا به فروش نمی‌رساند: هر مشتری به طور ماهانه هزینه‌ای ثابت را به ازای هر محصول در کنار درصد کمی از هر تراکنش را پرداخت می‌کند.

این شرکت توسط رایدر کسلر (Ryder Kessler) و جوردن بار اَم (Jordan Bar Am) در شهر نیویورک تأسیس شد و سرمایه نسبتاً کمی را جمع‌آوری کرد. با این‌حال، آن‌ها به طرز موفقیت‌آمیزی محصولات بسیاری را به دست مشتریان رساندند و به ‌تناسب بازار- محصول (Product/Market Fit) دست یافتند. بخش زیادی از این موفقیت اولیه مستقیماً به تمرکز این شرکت بر توسعه مشتری‌محور و تکرار ارتباط دارد.

بخش اول فرایند توسعه محصول: ایده‌پردازی

مرحله اول توسعه محصول سخت افزاری ایده پردازی

ایده‌پردازی با تعریف شفاف حوزه مسئله آغاز می‌شود و با یک نمونه اولیه اثبات مفهوم (Proof-of-Concept Prototype) (پروتوتایپ یک بازنمایی با وفاداری نسبتاً بالا از محصول نهایی است که تعاملات کاربر را شبیه‌سازی می‌کند. پروتوتایپ باید به کاربر اجازه بدهد: از طریق رابط کاربر، تجربه خود از محتوا و اثرات متقابل آن را در اختیار دیگران قرار بدهد و تعاملات اصلی را به شیوه‌ای مشابه پروژه نهایی تجربه کند) به پایان می‌رسد. اختصاص زمان بیشتر در این مرحله، متضمن پایه و اساسی قدرتمند برای ادامه کار توسعه محصول توسط موسسین است.

پژوهش مسئله

فرایند توسعه محصول سخت افزاری بخش پژوهش مسئله

هر تصویر در این مجموعه همواره نمایانگر این است که ما در کجای فرآیند توسعه محصول (بالا سمت چپ) و حجم تقریبی زمان طی شده (بالا سمت راست) حضور داریم.

اغلب مؤسسان مهندس، بدون تعریف دقیق مسئله‌ای که در حال کار بر روی آن هستند، مستقیماً به سمت ایجاد محصول یورش می‌برند. در ابتدا فضای مسئله‌تان را با مصاحبه‌های توسعه مشتری، درک کنید.

زمانی که با مشتریان بالقوه مصاحبه می‌کنید:

  • مکالمه‌های انعطاف‌پذیر و از پیش تعیین نشده داشته باشید و نسبت به مسیری که ممکن است شما را به آن سوق دهد، با ذهن باز پذیرایش باشید.
  • در ارتباط با محصول یا راه‌حلتان صحبت نکنید.
  • یادداشت‌های با جزئیات بردارید یا برای داشتن یک پایگاه داده منسجم، صدایشان را ضبط کنید.
  • تا آنجایی کار کنید که بتوانید بیش از ۳ پرسونای مشتری (Customer Persona) (اگر مجموعه‌ای از ویژگی‌ها و ترجیحات و الگوهای فکری و رفتاری مخاطب فرضی را گردآوری کنیم، به این مجموعه پرسونای مخاطب گفته می‌شود) ایجاد کنید.
  • تنها بر چیزی که افراد می‌گویند تمرکز نکنید، به شکلی که آن را بیان می‌کنند، توجه کنید.

فرایند توسعه محصول سخت افزاری بخش پژوهش مسئله - نمونه

تقریباً هر شرکت کارش را با یک لحظه «آهان» آغاز می‌کند – قصه‌ای که تجربه مؤسس را به مسئله‌ای که در حال حلش هستند، متصل می‌کند. برای دیپجر، آن لحظه در یک کافی‌شاپ بود. رایدر در زمان دانشجویی‌اش، چندین بار در روز به یکی از شعبه‌های استارباکس می‌رفت و با کارکنان باریستای (کافی‌مَن) آنجا دوست شده بود. در یکی از بعدازظهرها آنجا بسیار شلوغ شد و کارکنان فلاکت‌زده به نظر می‌رسیدند. رایدر به باریستای آنجا گفت: «حداقلش این است که شما در این وضعیت، انعام زیادی به جیب می‌زنید». اما باریستا پاسخ داد: «در واقع، هیچ‌کس دیگر به علت وجود کارت‌های اعتباری انعام نمی‌دهد. ما ترجیح می‌دهیم مغازه خلوت باشد».

رایدر با صحبت با افراد دیگر متوجه شد، فقط باریستاکاران نیستند که از کاهش این تراکنش‌های نقدی ناراضی‌اند. رایدر با موسیقی‌دانان (خصوصاً آن‌هایی که اجرای خیابانی دارند)، ارائه‌دهندگان خدمات (مانند آرایشگران) و خیریه‌ها صحبت کرد.

فرایند توسعه محصول سخت افزاری بخش پژوهش مسئله - نمونه2

مکالمه‌های این‌چنینی پایه و اساس ایجاد پرسوناهای مشتری هستند که پروفایل‌های ساختگی و کلی کاربران ایده‌آل شما هستند. هرچه تعداد این مکالمه‌ها بیشتر باشد، شما را مجهز به قصه‌ها و حکایت‌هایی می‌کند تا بتوانید به سمت ادامه فرآیند توسعه محصول پیش بروید.

فرایند توسعه محصول سخت افزاری بخش پژوهش مسئله - نمونه پرسونا

ما عاشق صحبت با شرکت‌هایی هستیم که پرسوناهای این‌چنینی (سمت راست تصویر) را ایجاد کرده‌اند. این مورد نشان‌دهنده داشتن دانش عمیق نسبت به فضای یک مسئله است.

یک پژوهش مسئله خوب معمولاً از چک‌لیست زیر پیروی می‌کند:

  • اگر با یک مشتری سازمانی (B2B) سروکار دارید: شما میدانید که کدام سهامدار یا ذی‌نفع در شرکت نقش تصمیم‌گیرنده را ایفا می‌کند، چگونه محصولاتی مانند محصولات شما را خریداری می‌کنند، و چرا این محصول برای آن‌ها در اولویت بالا قرار دارد؟
  • اگر با یک مشتری مصرف‌کننده (B2C) سروکار دارید: شما میدانید آن‌ها با چه برندهایی شناسایی می‌شوند، با چه مشخصه‌های بازاریابی در تعامل‌‎اند و عادات خریدشان چه چیزهایی هستند.
  • شما در ارتباط با اینکه آن‌ها حاضرند چقدر برای محصول شما هزینه پرداخت کنند، تحقیق کرده‌اید.
  • شما مشتریان اولیه و بازار ساحلی (Beachhead Market) خود را مشخص کرده‌اید و اندازه کل مشتریانتان را در اختیار دارید.
  • اگر برای دریافت سرمایه برنامه‌ریزی کنید، شما میدانید که چگونه این اعداد در ۵ سال آینده به ۱۰۰ میلیون دلار درآمد می‌رسد.

اگر شما بتوانید هر یک از این موارد را انجام دهید، آماده‌اید تا در ارتباط با چگونگی حل این مسئله فکر کنید.

 نمونه اولیه اثبات مفهوم

فرایند توسعه محصول سخت افزاری بخش نمونه اولیه اثبات مفهوم

نمونه اولیه اثبات مفهوم (اغلب از مخفف آن یعنی POC استفاده می‌شود)، نمونه‌های اولیه‌ای هستند که هدفشان تائید اعتبار فرضیات اساسی است که پژوهش مسئله شما آن را آشکار ساخته است. تیم دیپجر، سؤالات بزرگی در ذهن داشت که باید پاسخ می‌داد:

  • آیا مردم می‌توانند نحوه استفاده از دیپجر را در کمتر از ۵ ثانیه در پیشخوان، حین انجام یک تراکنش متوجه شوند؟
  • آیا جمع‌آوری پول نقد در کنار کارت‌های اعتباری اهمیت دارد؟
  • آیا مغازه‌دارها و کارکنانشان نسبت به داشتن یک دیپجر در پیشخوانشان رضایت دارند و با روی باز آن را می‌پذیرند؟

فرایند توسعه محصول سخت افزاری بخش نمونه اولیه اثبات مفهوم - دیپجر

این موارد، سؤالات اساسی برای امکان‌پذیری دیپجر به‌عنوان یک کسب‌وکار هستند. آن‌ها سریعاً نمونه‌های اولیه‌ای را برای مورد آزمون قرار دادن این فرضیات ایجاد کردند. سه نمونه اولیه بالا تنها در ظرف مدت چند روز با استفاده از قطعات موجود در بازار (Off-the-shelf) ساخته شدند (یک مدار الکترونیکی، یک جفت شناساگر/ساتع‌کننده مادون قرمز، تعدادی لوله آلومینیومی، و تعدادی پلاستیک با اسپری رنگ شده).

با وجود اینکه هدف اولیه دیپجر پرداخت از طریق کارت‌های اعتباری بود، آن‌ها فرصت کافی برای پیاده‌سازی آن را نداشتند (برای موردآزمون قرار دادن فرضیاتشان نیز ضروری نبود). بنابراین این نمونه‌های اولیه اثبات مفهوم کارت‌خوان نداشتند، و تنها راهکاری برای شناسایی تعداد دفعات وارد شدن یک کارت اعتباری و شمارش آن دفعات بودند.

فرایند توسعه محصول سخت افزاری بخش نمونه اولیه اثبات مفهوم - دیپجر2

تیم دیپجر، نمونه اولیه را در محل مشتریان هدف، برای یک روز کامل قرار دادند. زمانی که نمونه‌های اولیه اثبات مفهوم جمع‌آوری شدند، تیم دیپجر می‌توانستند بگوید که کدام‌یک کارآمدتر بوده‌اند.

مشخص شد که:

  • افراد به‌آسانی دریافتند که یک دیپجر چیست و در اولین استفاده، متوجه شدند که چطور کار می‌کند.
  • بیشتر مشتریان ترجیح دادند که پول نقد را در شیشه‌های خودشان جمع‌آوری کنند (و «سبد» پول نقد در دیپجر هرگز نتوانست بیشتر از یک نمونه اولیه عمل کند و در مراحل بعد حذف شد).
  • مالکین و کارمندان نسبت به تخصیص فضای پیشخوان در عوض دریافت انعام بیشتر موافق بودند.

همانند هر فرایند ساخت نمونه اولیه، ایجاد یک نمونه اولیه اثبات مفهوم، نیز روندی تکرارشونده است. نکاتی در ارتباط با این فرایند قابل توجه است:

  • پیش از ساخت هر چیز، ایده‌های زیادی داشته باشید و بهترینشان را برای نمونه اولیه ارزیابی و انتخاب کنید. برخی مؤسسین استفاده از ابزارهای رسمی (ایجاد نقشه ذهنی، ایده‌پردازی گروهی، طوفان فکری و …) را دوست دارند. من متوجه شدم که این تکنیک‌ها نسبت به ابزارهای غیررسمی (مکالمه‌ها، نمونه اولیه و جستجوی محصولات موجود)، کارآمدی کمتری دارند.
  • تمرکز بر موردآزمون قرار دادن فرضیات
  • اولویت‌بندی سرعت نسبت به کیفیت (انجام این کار برای مهندسین بسیار دشوار است، اما در این مرحله ضروری است)
  • استفاده از قطعات موجود در بازار در مقابل ساختن قطعات از نو

حال که ما درک مناسبی از مسئله را به دست آوردیم و متوجه شدیم که چگونه باید آن را حل کرد، وقت آن رسیده تا راهکارمان را بهینه‌سازی کنیم تا مشتریان بتوانند از آن استفاده کنند. به بخش دوم: طراحی می‌رویم.

 

نظر دهید