توجه : برای اطلاعات بیشتر در خصوص طراحی API به عنوان محصول به “کتاب API به عنوان محصول” مراجعه فرمایید!
مقدمه
توسعه محصول API با روش ناب برگرفته از متدولوژی استارتاپ ناب است که راهکاری انقلابی برای تولید محصولات و خدمات نوآورانه محسوب می‌شود. اصل اساسی این متدولوژی، چرخه “ساخت-اندازه‌گیری-یادگیری” یا Build-Measure-Learn است که برای توسعه محصولات و خدمات جدید تحت شرایط عدم قطعیت بکار برده می‌شود. در واقع این روش زمانی بسیار کاربردی است که در خصوص مسائل و مشکلات مشتری و نحوه انتقال ارزش به او اطلاعات کاملی نداشته باشیم.
استارتاپ ناب یک فرایند تکرار شونده برای ساخت و بهبود محصول و یا حتی چرخش در استراتژی آن (بسته به نیازمندی های بازار) است. در چرخه “ساخت-اندازه‌گیری-یادگیری” کار با یک ایده شروع می‌شود. این ایده پیاده سازی شده و در دسترس کاربران قرار داده می‌شود. داده های بازخورد کاربر اندازه‌گیری شده و بر اساس آن شناخت جدیدی از کاربر بدست می‌آید تا ایده های جدیدی در راستای بهبود محصول حاصل گردد. و چرخه ساخت-اندازه‌گیری-یادگیری دوباره ادامه می‌یابد…
متدولوژی استارتاپ ناب برای توسعه محصولات API یا همان Application Programming Interfaces نیز مناسب است. ماهیت API طوری است که به سرعت قابل توسعه بوده و اندازه‌گیری بازخوردهای استفاده کاربر از آن نیز ساده می‌باشد. اما بهرحال API ها واسط هایی فنی و قراردادی هستند. فرض کنید شما یک API را توسعه داده اید و یک برنامه نویس از این API استفاده کرده است تا یک برنامه کاربردی را تولید کند. این برنامه موبایل توسط کاربران مختلفی مورد استفاده قرار می‌گیرد. حال اگر شما مرتبا API های خود را تغییر دهید، برنامه نویس نیز باید برنامه اش را تغییر دهد و متعاقبا کاربران نیز بایستی برنامه های خود را به روزرسانی نماید. در نهایت این اتفاق باعث ایجاد یک تجربه مشتری ضعیف خواهد شد.
توسعه محصول API با روش ناب
چرخه “ساخت-اندازه‌گیری-یادگیری” سرعت بالا، هزینه کم و ریسک پایین را تضمین می‌کند. اما API ها واسط هایی فنی و در واقع توافقاتی قراردادی هستند. لذا اگر شما یک API بسازید و مرتبا بخواهید آن را تغییر دهید، قرارداد واسط را شکسته اید و مشتری نهایی ناراضی خواهد شد.
لذا بایستی چرخه “ساخت-اندازه‌گیری-یادگیری” را به شکل متفاوتی بکار ببریم.
تکنیک توسعه محصول API به روش ناب شامل دو چرخه متوالی “ساخت-اندازه‌گیری-یادگیری” است. با کمک این راهکار دو چرخه ای می‌توانیم در ابتدا به سرعت ایده هایمان را با کمترین تلاش و بدون شکستن قرارداد واسط API، اعتبارسنجی کنیم (انطباق مشکل/راه‌حل) . پس از اعتبارسنجی نیز می‌توان API را ساخته و بررسی کرد که ایده اعتبارسنجی شده چقدر خوب جواب می‌دهد (انطباق محصول/بازار).
چرخه اول برای اعتبارسنجی ایده بکار برده می‌شود. این چرخه تا زمانی ادامه می‌یابد که ما مسئله را درک کرده و یک راه‌حل عملی و کارآمد برای آن پیدا کرده باشیم. در این چرخه از راهکار مبتنی بر پروتوتایپ یا prototype-first استفاده می‌شود.
چرخه دوم نیز برای اعتبارسنجی راه‌حل بکار برده شده و تا زمانی ادامه می‌یابد که محصول کاملی ساخته باشیم که سودمند باشد. در این چرخه از راهکارهای تحلیلی استفاده می‌شود.
شکل زیر راهکار پیشنهادی توسعه محصول API با روش ناب را نشان می‌دهد:
اولین چرخه را سیکل نمونه سازی یا Prototyping Cycle و دومین چرخه را سیکل تحقق Realization Cycle نیز می‌نامیم. فلش آبی رنگ در شکل فوق نشان می دهد که هر دو چرخه، بخشی از یک فرایند متوالی از ایده اولیه تا محصول نهایی هستند. در واقع می‌توان گفت که فرایند فوق یک فرایند اعتبارسنجی-توسعه-تائید است.
چرخه مبتنی بر پروتوتایپ
در این چرخه ما مشتریان و کاربران اولیه را می‌شناسیم. در شروع ما فقط یک ایده از مشکلات واقعی مشتری و کاری که باید برایشان انجام شود، داریم. بنابراین در این چرخه تمرکز اصلی ما روی درک بهتر مشکل و یافتن راه‌حلی درست از طریق محصول API است. این موضوع تحت عنوان انطباق مشکل-راه‌حل نیز شناخته می‌شود. برای دستیابی به این هدف، از اصل “ساخت-اندازه‌گیری-یادگیری” استفاده می‌کنیم:
ساخت پروتوتایپ API:
در اولین قدم بایستی قابلیت های محصول که باعث شکل گیری ارزش پیشنهادی ما می‌شود را مشخص کنیم. با استفاده از قابلیت های محصول (که به آن قابلیت های کسب و کاری نیز گفته می‌شود) می‌توانیم قابلیت های فنی API را مشخص نمائیم. سپس می‌توانیم واسط API را طراحی کنیم. توجه کنید که اگرچه داشتن دانش عملیاتی در خصوص برنامه های زیرساخت یا backend اهمیت دارد، اما نباید قابلیت های واسط API را به قابلیت های واسط backendتان نگاشت کنید. بخاطر داشته باشید که در ابتدا باید مطمئن شوید API شما مشکل مشتری را حل کند. بنابراین می‌توانید بدون نیاز به دسترسی به backend، پروتوتایپ را با mock کردن خروجی مورد انتظار بوجود آورید.
عوامل اصلی موفقیت در پروتوتایپ سازی API سرعت و هزینه های پایین هستند. برای رسیدن به این هدف می‌توانید یک API قابل استفاده از روی توصیف API (برای مثال Swagger) ایجاد نمائید. در نتیجه شما یک توصیف از API، یک پروتوتایپ API برای عرضه به مشتری و مستنداتی برای به اشتراک گذاری با او در اختیار خواهید داشت
اندازه‌گیری با استفاده از بازخوردهای مشتری:
به دو دلیل می‌خواهیم بازخورد مشتری یا پذیرندگان اولیه API را در خصوص محصول‌مان گردآوری کنیم:
• درستی‌سنجی مسئله: آیا ما به درستی متوجه مشکل یا همان مسئله مشتری شده‌ایم؟
• درستی‌سنجی راه‌حل: آیا راه‌حل درستی برای مسئله مهیا کرده ایم؟
تجربه نشان می‌دهد که گرفتن بازخورد از مشتری به صورت رو-در-رو بسیار ضروری است. این موضوع به شما کمک می‌کند تا رابطه‌ای خوب و مبتنی بر اعتماد با مشتری ایجاد کرده و در فضایی شفاف با او به گفتگو بپردازید.
زمانیکه مشتری را ملاقات می‌کنید، مطمئن شوید که مناسب ترین فرد در گردآوری بازخورد از طرف مشتری حضور داشته باشد. ما نمی‌خواهیم زمان خودمان و آنها را با یک جلسه بی فایده هدر بدهیم. بنابراین از مشتری بخواهید که همیشه افراد زیر در گفتگوها حضور داشته باشند:
• مالک کسب و کار یا Business Owner: حضور او برای درک مسئله کسب و کاری لازم است.
• معمار سیستم: او راه‌حل شما، وابستگی های فنی و تاثیرات آنها را درک خواهد کرد.
• مهندس: او بایستی از API برای پیاده سازی برنامه کاربری استفاده کند. او می‌تواند سادگی استفاده از API و طراحی درست آن را بررسی نماید.
برای گردآوری مجموعه بازخوردهای مشتری بایستی قدم های زیر را بردارید:
1. سناریو یا Use Case را به نمایندگان مشتری ارائه دهید.
2. توضیح دهید که پروتوتایپ API چگونه بایستی استفاده شود تا مسئله مشتری مرتفع گردد.
3. از مشتری بخواهید تا یک بازخورد ساخت یافته از طریق یک فرم بازخورد را به شما ارائه دهد.
هدف از بازخورد ساخت یافته آن است که موارد زیر درستی‌سنجی شوند:
• آیا متوجه مشکل/مسئله مشتری شده ایم؟
• آیا «کاری که باید انجام شود» یا Job to be Done مشتری را فهمیده ایم؟
• آیا راه‌حل ما پاسخگوی این نیازها است؟
برای این منظور لازم است سوالات زیر را در فرم بازخورد از مشتری بپرسیم:
• این سناریو چقدر مرتبط با مشکل شماست؟ (از “نه چندان مرتبط” تا “خیلی مرتبط”)
• API چقدر خوب مشکل شما را حل می‌کند؟ (از “اصلا حل نمی‌کند” تا “بخوبی حل می‌کند”)
• با جزئیات بیشتری در خصوص پاسخ تان به دو سوال فوق توضیح دهید.
• سایر توضیحات
معمولا مشتریان دوست دارند بیشتر در خصوص سناریو بحث کنند تا اینکه توضیحاتی را برای ما بنویسند. اشکالی ندارد…
سعی کنید نکته های مشتری را یادداشت کنید. سوالات «چرا»ی زیادی از او بپرسید تا بتوانید اهداف و انگیزه های او را به درستی درک کنید. در غیراینصورت شما فقط «اسب سریعتری» پیاده سازی خواهید کرد:
“اگر از مردم می‌پرسیدم که چه می‌خواهند، آنها می‌گفتند یک اسب سریعتر – هنری فورد”
یادگیری از بازخورد مشتری:
اکنون زمان آن رسیده که با استفاده از بازخوردهای کسب شده، به شناخت و یادگیری از مشتریان اولیه برسید. توجه کنید که بازخورد مشتری یک مجموعه از نیازمندی ها نیست، بلکه هدف آن است که به شما کمک کند تا مسئله درست را حل کنید و محصول درستی را شکل دهید. بازخورد مشتری می‌تواند به شما کمک کند تا قابلیت ها را بر اساس ارزشی که ایجاد می‌کنند، اولویت بندی نمائید.
چرخه مبتنی بر تحلیل
هدف اصلی این چرخه، تائید کمّی میزان مطلوبیت و خوب بودن ارزش پیشنهادی محصول برای مشتریان است. برای دستیابی به این هدف نیز از اصل “ساخت-اندازه‌گیری-یادگیری” استفاده می‌کنیم:
ساخت:
اکنون شما می‌دانید که چگونه APIتان را با تکنولوژی‌هایی که در اختیار دارید و یا با پلتفرم مدیریت APIای انتخابی تان، پیاده سازی نمائید. در زمان ساخت API مطمئن شوید که شاخص های کلیدی را در Logهای مناسب ثبت می‌کنید تا بتوانید آنها را تحلیل نمائید
اندازه‌گیری با استفاده از تحلیل:
این اندازه‌گیری فقط در خصوص تعداد درخواست ها، نرخ درخواست های موفق و یا تعداد مشتریان نیست، بلکه در خصوص اندازه‌گیری ارزش مهیا شده برای مشتری در هر فراخوانی API می‌باشد.
هدف اصلی آن است که ببینیم چقدر خوب توانسته ایم ارزش پیشنهادی‌مان را به مشتریان منتقل سازیم. توجه کنید که نتایج عددی (برای مثال تعداد درخواست های موفق) بایستی برای کسب شناخت از مشتری و شناسایی فرصت‌های بهبود مورد استفاده قرار گیرند.
یادگیری:
برای یادگیری بایستی داده ها و شاخص های استخراج شده را تحلیل کنید. روش‌های بصری سازی یا Visualization برای درک داده و کسب بینش در خصوص مشتری بسیار مفید هستند. این شاخص ها را به شکل یک داشبورد در اختیار همه اعضای تیم قرار دهید تا در فرایند توسعه محصول API به روش ناب سهیم باشند.
منبع
Lean API Product Development , Amancio Bouza, March 2019
دیدگاه خود را ثبت کنید
تمایل دارید در گفتگو شرکت کنید؟نظری بدهید!