تفکر محصول محور نسبت به برنامه API به معنای طراحی و عرضه API با داشتن نگاه ایجاد ارزش و در نهایت بهبود در خواستههای مشتریان است. لذا زنجیره ارزش API چگونه بایستی شکل بگیرد و به عبارتی ویژگیهای تفکر محصول محور در خصوص API چیست؟ چه ارتباطی بین استارتاپ ناب و توسعه API وجود دارد؟
به کارگیری API به عنوان محصول
تفکر محصول-محور در خصوص API، به معنی طراحی و عرضه API با نگاهی بلند مدت به ایجاد ارزش از طریق آن و در نتیجه تغییر در خواستههای مشتری است. جزء کلیدی این تفکر، طراحی API با روشی مشابه با طراحی سایر محصولات دیجیتال است. چگونگی طراحی API میتواند بر روی میزان سادگی استفاده از آن توسط توسعه دهندگان و برنامه نویسان (به عنوان مشتریان محصول شما) و در نتیجه بهکارگیری در دراز مدت تاثیرگذار باشد.
اگر API تنها برای برقراری ارتباط درون محدوده یک پروژه طراحی و پیادهسازی شده باشد، به احتمال زیاد هیچ مستندسازی درستی نداشته و استانداردهای طراحی، نسخه بندی، امنیت و سایر عوامل تاثیرگذار در موفقیت در آینده نیز در آن لحاظ نشده است. در مقابل اگر طراحان API نگاهی محصول-محور به آن داشته باشند، سادگی استفاده را در اولویت بالا قرار داده و به دنبال افزایش ارزش استراتژیک API و توسعه آن در آینده هستند.
معمولا سازمانهايی که عادت کردهاند تا APIهای مورد نیازشان را خودشان درون پروژهها بسازند، برای حرکت به سمت این تفکر و ساخت و مدیریت محصولات API دچار مشکل میشوند. در بسیاری از این سازمانها تیمهای هر پروژه کتابخانهها و روشهای پیاده سازی خاص خودشان را انتخاب کردهاند و لذا تغییر لازم در APIها پیچیده و پرهزینه خواهد بود. ساخت API بر اساس نیازهای یک پروژه خاص باعث میشود تا قابلیت توسعه API محدود گردد. درواقع چون این APIها درست طراحی نشده اند، اعمال تغییرات در آنها پیچیده و هزینهبر بوده و لذا سودآوری خود را از دست خواهند داد.
ویژگیهای تفکر محصول محور در خصوص API
محصولات API بایستی طوری طراحی شوند که توسعه دهندگان بتواند به سادگی از آنها استفاده کنند. همچنین بایستی ملاحظات امنیتی و دغدغههای مستندسازی و نمونه کد نیز در آنها لحاظ شده باشد. در واقع APIها تکنولوژی مرکزی در زنجیره ارزش دیجیتال هستند، بنابراین بایستی ویژگیهای مشخصی داشته باشند تا برای برنامههای کاربردی ایجاد ارزش کنند: طراحی خوب، امنیت مستحکم، ارزشمندی تجاری واقعی، کارایی بالا و سرعت مناسب در دسترسی به داده مناسب در سیستمهای زیرساخت.
در زمان طراحی API، سادگی استفاده در آینده را همیشه مد نظر داشته باشید. هدف این نیست که API را برای تمام نیازها طراحی کنیم، بلکه هدف ما ارائه ارزش به توسعه دهندگان است. با این هدف میتوان از آنها بازخورد گرفت و توسعه آینده را برنامه ریزی نمود. تفکر محصول-محور در خصوص API نیاز به رفتاری محصول-محور با API دارد. بایستی یک مدیر یا مالک محصول برای آن وجود داشته باشد، نه یک مدیر پروژه که تنها هدفش تولید لیستی از نیازمندیها است.
مدیر محصول بایستی نیازهای مشتریان برای محصول را شناخته و مسئولیت ترجمه آنها به محصول و تعیین مسیر راه محصول را بر عهده بگیرد. برای رسیدن به این مسیر، مدیر محصول بایستی با دیگر مدیران کسبوکاری و فنی همسو باشد. آنها بایستی از ابزارهای مدیریت API برای مدیریت استفاده از محصول، تامین توافقات سطح سرویس (SLA) و اطمینان از اینکه محصول نیازمندیهای مشتری را برآورده میسازد، استفاده نمایند.
شرکتهای موفق به APIهایشان به دید یک محصول و یک کانال ارتباط با مشتری مینگرند و با این نگرش، طرحریزی لازم برای ورود به بازار را انجام میدهند. بنابراین به حداکثر رساندن ارزش برای محصولات API نه تنها شامل نکات فنی و تکنولوژیک است، بلکه سه نکته عملیاتی نیز بایستی مد نظر قرار گیرد:
- اتخاذ رویکرد از بیرون-به-درون
- تمرکز روی بهبود زمان رساندن محصول به بازار
- ایجاد فرهنگ یادگیری و تکرار
اتخاذ رویکرد از-بیرون-به-درون
این رویکرد در ایجاد برنامه API شامل توجه به نیازمندیها و ترجیحات مشتری برای هدایت استراتژی محصول است. چشم انداز بیرون-به-درون داده-محور بوده و به جای گمانه زنی در خصوص مشتری، هم توسعه دهندگان (به عنوان مشتریان مستقیم API) و هم کاربران نهایی که توسعه دهندگان به آنها خدمات ارائه میکنند را در نظر میگیرد. این راهکار در نقطه مقابل روش درون-به-بیرون میباشد که تنها به استراتژیهایی بر اساس منابع موجود و یا پیش انگاری در خصوص نیاز توسعه دهندگان و کاربران متکی هستند.
میتوان گفت که در زمان ساخت برنامه API بایستی در ابتدا به نیازهای مشتری، سپس به برنامههای کاربردی که این نیازها را پوشش میدهند و در نهایت به اینکه چگونه APIهای ما به ساخت این برنامهها کمک میکنند، بیاندیشیم. بنابراین یک پلتفرم API زمانی به موفقیت میرسد که توسط یک مدیر اجرایی که نگاهی «از بیرون-به-درون» دارد، حمایت شود و همچنین مدیر محصول API بودجه و قدرت لازم برای انجام تغییر در نگرش سازمان را در اختیار داشته باشد.
نگاه «از-درون-به-بیرون» و یا تفکر «محصول را بساز و مشتري خودش از راه میرسد» راه به جایی نخواهد برد. مسیر موفقیت، شناسایی نیازهای مشتری و تجربه دیجیتالی مورد نیاز اوست. تفکر محصول-محور بیانگر آن است که آینده یک محصول ممکن است در مواجه با کاربران دچار دگرگونی شود. بنابراین پیش از تولید محصول، مدیر محصول بایستی مشکلات توسعه دهندگان را درک کرده و آنها را کاهش دهد و یا برطرف سازد. یک تیم محصول API میتواند با داشتن اطلاعات مناسب (برای مثال کدام APIها استفاده شده؟، کدام APIها بیشترین فراخوانی را داشته؟، یا کدام APIها بیشتر در برنامه ها استفاده شده؟) رفتارهای مشتری را فهمیده و از این رفتارها چرخههای بعدی توسعه محصول استفاده نماید.
یک محصول API زمانی در مسیر درست موفقیت در کسبوکار قرار میگیرد که عرضهکننده آن درک درستی از رفتار مشتری داشته باشد. در واقع میتوان گفت که موفقیت یا شکست یک محصول API به پذیرفته شدن آن توسط کاربران بستگی دارد. اگر به API به دید یک تاکتیک و نه یک استراتژی نگاه شود، آنگاه هیچگونه هدف یا شاخصی برای ارزیابی ارزش عرضه شده به مشتری و درآمد حاصل شده از API تعریف نخواهد شد.
تمرکز روی بهبود زمان رساندن محصول به بازار
کمّینه محصول پذیرفتنی یا MVP، حداقلی برای محصول/سرویس شماست که قابل عرضه به مشتری باشد. توجه کنید که MVP به صورت افزایشی و تکرار شونده تکامل پیدا میکند. در واقع هدف آن است که شما بتوانید در مدت زمان کوتاهی، چیزی شبیه به این داشته باشید تا بازخوردهای لازم را از توسعه دهندگان دریافت کرده و به طور پیوسته محصول خود را ارتقا دهید.
برخی از شرکتها از زیرساختهای موجود خود برای ارائه اولیه API استفاده کرده و سپس به صورت افزایشی و تکرارشونده آن را ارتقا میدهند. برخی دیگر نیز از ابتدا شروع به طراحی معماری و یا بازنویسی برخی از سرویسها با تکنولوژیهای جدید میکنند. اما به هرحال این موضوعات به لایه API ارتباطی ندارد. نکته اینجاست که بایستی معماری شما تابآوری کافی برای پاسخدهی را داشته باشد.
شرکتهای با ذهنیت محصول-محور، معمولا بهترین راه برای ورود به بازار را شروع با یک کمّینه محصول پذیرفتنی یا MVP و سپس تکرار کردن سریع بر اساس بازخورد مشتری میدانند. این ذهنیت باعث میشود تا سازمان ایدههای بیشتری را با سرعت بالاتری ارزیابی کرده و با دریافت بازخورد مناسب، بررسی کند که کجا محصولات طبق انتظار عمل کرده و کجا نیاز به اصلاح یا بهبود دارند. در واقع هدف از عرضه MVP آنست که به سرعت تکرار انجام گیرد و محصول ارتقا یابد. این موضوع مستلزم هماهنگیهای مناسب در سازمان است.
یکی از مزایای استفاده از سیستمهای مدیریت API آن است که به این امر کمک میکنند. البته یک کسب و کار فقط با اینکه در حال ساخت API است، موفق محسوب نمیشود و مسائل فروش و بازاریابی نیز مهم هستند. همچنین فرایندهای عرضه API، نسخه بندی، اندازهگیری شاخصها و گزارشدهی نیز همگی باید بخشی از چشم انداز محصولات API باشند. لذا بایستی تمامی نقشها در یک تیم API با یکدیگر همسو بوده و با توسعه دهندگان و واحدهای کسبوکاری نیز در ارتباط باشند تا بتوانند یک جریان پایدار از ایدههای مختلف برای محصول را ایجاد کنند که به سرعت به بازار معرفی شده و بازخوردهای لازم برای توسعههای آتی دریافت گردد.
ایجاد فرهنگ یادگیری و تکرار
عرضه کنندگان محصول-محور API میتوانند با استفاده از یک پروسه متوالی تولید فرضیه، آزمایش و کشف، بک-لاگ (backlog) محصول خود را مرتب سازند .در واقع آنها بایستی همپای نیازمندیها و ترجیحات توسعه دهندگان بوده و تجارت مفید و دلپذیری را برای آنها مهیا سازند. در نتیجه شرکتهای با طرز فکر محصول-محور، هم میتوانند محصول مناسبی به بازار عرضه کرده و هم سریعتر چرخه تکرار را انجام دهند. آنها از ابتدا برنامه ریزی کردهاند که یک MVP خواهند داشت، فرایندهای عملیاتی مستمر انجام خواهد گرفت و مدیر محصول کسی است که مسئولیت اندازهگیری و هدایت موفقیت محصول را بر عهده خواهد داشت.
یک برنامه موفق API نیاز به افرادی حرفهای و بودجه اختصاصی برای حمایت از این فرایند تکرار و مدیریت مستمر دارد. دادن شعار رفتار استارتاپی بدون سرمایه گذاری اختصاصی برای پشتیبانی از چشم انداز محصول، بیهوده خواهد بود. همچنین برای تضمین این بودجه، مدیر محصول بایستی سنجههای لازم برای ارزیابی ارزش پیشنهادی را در اختیار داشته باشد.
استارتاپ ناب و توسعه API
متدولوژی استارتاپ ناب یک فرایند تکرار شونده برای ساخت محصولات و بهبود (یا حتی چرخش در استراتژی ساخت آن) بر اساس بازخوردها و نیاز بازار است. این متدولوژی شامل سه مرحله ساخت، اندازهگیری و یادگیری است. اریک ریس در سال ۲۰۱۱ در کتابش این روش را معرفی نمود.
متدولوژی با یک ایده آغاز شده و سپس آن ایده پیاده سازی میشود. در ادامه محصول پیاده سازی شده (در شروع کار MVP)، در اختیار کاربران قرار گرفته و بازخوردهای لازم اندازه گیری میشود تا سپس یادگیری و بهبود حاصل شود. متدولوژی استارتاپ ناب برای تولید محصولات API نیز مناسب است، زیرا API به سرعت قابل توسعه و عملکردش قابل اندازه گیری است.
چرخه ساخت-اندازهگیری-یادگیری دارای سرعت بالا، هزینه پایین و ریسک کم است. اما به هرحال APIها واسطههای فنی مبتنی بر SLA با توسعه دهنده هستند. اگر شما یک API را در اختیار توسعه دهنده قرار دهید اما مرتبا آن را تغییر دهید، مشتری نیز مرتبا باید برنامهاش را با API جدید شما سازگار کند و لذا تجربه ارزشمندی برایش ایجاد نخواهد شد.
راهکار حل این مشکل ابداع یک متدولوژی توسعه محصول API ناب است که در آن از دو چرخه متوالی ساخت-اندازهگیری-یادگیری استفاده میشود (شکل زیر). در چرخه اول در ابتدا یک پروتوتایپ ساخته شده و با ارائه به توسعه دهنده، بازخوردهای لازم از او دریافت می شود (برای مثال اینکه API چقدر با مسئلهاش مرتبط بوده و چقدر خوب مشکل او را حل کرده است؟) تا بهبودهای لازم اعمال گردد. برای عملیاتی ساختن عرضه پروتوتایپ، میتوان از روی توصیف API، یک موکاپ ایجاد نموده و آن را در اختیار توسعه دهندگان اولیه قرار داد. پس از اتمام این فاز سریع اعتبارسنجی، چرخه اصلی آغاز میشود تا محصول واقعی به کلیه توسعه دهندگان عرضه شده و نحوه استفاده آنها مورد تجزیه و تحلیل قرار گیرد.
ادامه دارد …
این سری مقالات برگرفته از کتاب «API به عنوان یک محصول» نوشته حامد شیدائیان است.
«معرفی API «API به عنوان محصول – بخش اول
«پیادهسازی API «API به عنوان محصول – بخش سوم
