توجه: این مطلب ترجمه ای از دو مقاله Release Planning Advice و Product Roadmap Prioritisation در خصوص مدیریت محصول و نوشته رومن پیچلر می باشد. برای مطالعه نکات و مطالب تکمیلی تر در خصوص موضوع این مقالات به کتاب تدبیراندیشی برای محصول نوشته رومن پیچلر که توسط گروه ذهن چابک ترجمه شده است، مراجعه نمائید.

مقدمه

برنامه ریزی جهت انتشار محصول یا همان Release Planning فعالیت مهمی برای افراد محصول (مدیران و مالکان محصول) است که با تیم های چابک همکاری می کنند: انجام این کار باعث می شود که آنها اطمینان حاصل کنند محصول در مسیر صحیح قرار دارد. برنامه انتشار محصول، استراتژی و تاکتیک ها را به هم مرتبط می سازد. علارغم اهمیت این موضوع، به نظر من برنامه ریزی انتشار محصول در تیمها همیشه به طور مؤثری انجام نمی شود. این مقاله قصد دارم توصیه هایی در خصوص برنامه ریزی انتشار محصول و بهبود آن با شما مطرح کنم.

برنامه ریزی برای انتشار محصول چیست و چه اهمیتی دارد؟

گرچه واژه های «انتشار» و «برنامه ریزی برای انتشار» اصطلاحات متداولی هستند، اما به نظر من افراد مختلف برداشتهای متفاوتی از آنها دارند. من «انتشار» را یک نسخه از یک محصول می دانم، برای مثال Mac OS X Catalina و یا Windows 10. انتشار محصول به دو شکل است: انتشارهای اصلی یا major مانند iOS 13 و انتشارهای جزئی یا minor مانند iOS 13.3.

«برنامه ریزی جهت انتشار» فرایند تعیین نتایج مطلوب از عرضه یک یا چند انتشار اصلی و به حداکثر رساندن شانس دستیابی به آن نتایج است. این برنامه ریزی شامل موارد زیر است:

• تعیین اهداف شفاف، مشخص و قابل اندازه گیری: اینها را اهداف محصول یا اهداف انتشار می نامیم و آنها را در نقشه راه محصول مشخص می کنیم.

• تعیین کارهایی که باید انجام شود: مشخص کردن این کارها به طور معمول همراه با تخمین های سطح بالا و نادقیقی است که تیم توسعه باید مشخص کند.

• شناخت محدودیت های زمانی و بودجه: آیا مهلت های دقیقی وجود دارد که باید رعایت شوند؟، و یا آیا بودجه ثابت است؟

• فرایند نظارت بر پیشرفت محصول در هر اسپرینت و انجام اصلاحات لازم در صورت نیاز: برنامه ریزی انتشار محصول در اسکرام بطور تکرار شونده یا iterative و اغلب در انتهای یک اسپرینت انجام می شود (زمانیکه مشخص شد چقدر پیشرفت حاصل شده است).

برنامه ریزی انتشار به شرکتها کمک می کند تصمیمهای سرمایه گذاری خود را به شکلی درست و آگاهانه بگیرند؛ باعث مشخص شدن انتظارات می شود، و ذینفعان محصول و تیم های توسعه را همسو و هم جهت می سازد؛ و به افراد محصول این امکان را می‌دهد که فعالیت های تیم توسعه را راهبری و هدایت کنند.

بنابراین شما -به عنوان فرد مسئول محصول- بایستی مطمئن شوید که برنامه ریزی انتشار محصول بطور موثر و درستی اجرا شود. این امر مستلزم آن است که به جای واگذاری اینکار به تیم توسعه یا اسکرام مستر، خودتان به صورت جدی در این کار فعال باشید.

استفاده از نقشه راه محصول برای برنامه ریزی چندین انتشار

برنامه ریزی انتشار در دو سطح انجام می شود: در سطح چندین انتشار اصلی و یا درون یک انتشار. اولی را می توان با نقشه راه محصول انجام داد. ترجیح من این است که با نقشه راه هدفگرا یا Go Product Roadmap کار کنید (برای اطلاعات بیشتر در خصوص این نقشه، به کتاب تدبیراندیشی برای محصول مراجعه کنید). این نقشه مزایا یا نتایج مطلوب هر انتشار اصلی را برای 12 ماه آینده بیان می کند (شکل زیر). این اهداف می تواند جذب کاربران جدید، افزایش نرخ تبدیل کاربر، کاهش هزینه و یا حذف بدهی فنی برای محصول آتی باشد.

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

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

اولویت بندی نقشه راه محصول

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

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

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

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

اگر پاسخ این سوالات را نمی دانید، ابتدا فرایند کشف و تعیین استراتژی محصول را انجام دهید و سپس به سراغ اولویت بندی نقشه راه بروید. در غیر اینصورت نقشه راه تان بر اساس فرضیات اشتباهی ساخته می شود.

برای اطلاعات بیشتر در این خصوص به کتاب تدبیراندیشی برای محصول مراجعه کنید.

روایتی قانع کننده بسازید

برای اولویت بندی نقشه راه، مشخص کنید که محصول شما در چه مرحله ای از چرخه عمرش قرار دارد. تا زمانیکه محصول به بلوغ نرسیده باشد، باید دائماً رو به جلو حرکت کند: در ابتدا باید به بازار عرضه شود، سپس به تناسب بازار و محصول دست یابد و در نهایت به رشدی پایدار برسد.

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

• تعیین کنید که چگونه می توانید اهداف کاربر و کسب و کار که در استراتژی محصولتان نیز بیان شده است را برآورده سازید. بهترین راه برای دستیابی به آنها چیست؟ چگونه می توانید آنها را به اهداف کوچکتری تقسیم کنید؟

• اهداف ایجاد شده در مرحله قبل را مرتب کنید، به گونه ای که هر یک از آنها پیشرفت منطقی و یک گام رو به جلو در جهت برآورده ساختن اهداف کلی کاربر و کسب و کار باشند (با در نظر گرفتن هر نوع وابستگی بین اهداف).

برای محصول یک بِرند جدید، این موضوع بدان معنا است که شما باید بسته به مدل کسب و کاری محصول تان، کار را با مرحله جذب کاربر شروع کنید و سپس به سراغ مراحل فعال سازی کاربر، بازگشت کاربر و در نهایت کسب درآمد از کاربر بروید. برای محصولی که در مرحله رشد قرار گرفته، ممکن است ابتدا بخواهید بدهی فنی آن را حذف کنید، قبل از اینکه تجربه کاربری یا UX محصول را بهبود داده و بخواهید نرخ تبدیل مشتری به خریدار را افزایش دهید.

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

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

مشخص کردن هزینه تاخیر

وقتی محصول شما وارد مرحله بلوغ خود شد، معمولاً نمی خواهید آن را به یک سفر بزرگ دیگر ببرید، مگر اینکه تصمیم بگیرید چرخه عمر آن را تمدید کنید! در واقع شما در نقطه ای قرار دارید که می خواهید جایگاه محصولتان را در بازار حفظ کرده و بازدهی آن را به حداکثر می رسانید.

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

در مواجهه با چنین چالشی، توصیه می کنم برای انجام اولویت بندی مناسب، از مفهوم هزینه تأخیر یا cost of delay استفاده کنید. به بیان ساده تر، از خود بپرسید چنانچه در هر یک از موارد نقشه راه تأخیر بوجود آید، ضرر و زیان ناشی از آن چقدر بزرگ است؟ به عنوان مثال، اگر مطمئن نیستید که ابتدا باید تجربه کاربری را برای تثبیت تعامل با مشتری بهبود دهید و یا اینکه رفع اشکالات فنی را بخاطر جلوگیری از ریزش مشتریان در اولویت قرار دهید، ابتدا تاثیر به تاخیر انداختن هر هدف را شناسایی کنید.

وقتی هزینه به تعویق انداختن هر یک از موارد را تعیین کردید، آنها را از بزرگترین تا کوچکترین هزینه اولویت بندی کنید.

اجازه ندهید که ذینفعان قدرتمند، اولویتهای خودشان را به شما دیکته کنند

در دو راهکاری که در بالا توضیح داده شد، فرض بر این است که نیازهای کاربر و کسب و کار همراه با مرحله ای که چرخه عمر محصول در آن قرار دارد، اولویت بندی نقشه راه محصول شما را مشخص کنند؛ و نه نظر بالاترین مقامی که بودجه محصول را تامین می کند!

اشتباه نکنید: من اعتقاد زیادی به ترسیم نقشه راه محصول بصورت مشارکتی دارم. ذینفعان اصلی و اعضای تیم توسعه را به طور فعال در این کار مشارکت دهید، افراد را ترغیب کنید که ایده ها و دغدغه هایشان را با شما به اشتراک بگذارند، با دقت به آنها گوش دهید و تا آنجا که ممکن است یک توافق مشترک بین همه ایجاد کنید.

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

تبدیل شدن به یک فرد حرفه ای در محصول، به معنای گرفتن تصمیمات دشوار است. و اولویت بندی به معنای گفتن «نه» می باشد. این موضوع بخش مهمی از کار شما بعنوان فرد مسئول محصول است، حتی اگر آن را دوست نداشته باشید!

عوامل موفقیت برای انتشارهای خود را اولویت بندی کنید

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

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

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

استفاده از روش های درست تخمین

تخمین هزینه انتشارها در نقشه راه محصول در تامین بودجه مورد نیاز تاثیرگذار است. حتی اگر بودجه ثابت باشد نیز این تخمین هزینه به شما کمک می کند تا بفهمید که آیا نقشه راه واقع بینانه و عملی است یا نه -آیا تیم توسعه واقعاً می تواند محصول را پیاده سازی کند؟ تخمین های سطح بالا و نادقیق معمولاً برای رسیدن به این هدف کافی هستند.

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

اگر باور دارید که تخمین های حاصل شده خیلی مبهم هستند، می توانید راهکار جایگزینی را در نظر بگیرید: تجزیه قابلیتهای نقشه راه محصول به اپیک ها Epics و داستان های کاربر User Stories؛ که البته اینکار منجر به بک لاگ محصول طولانی و پر از جزئیاتی می شود که نگهداری و اصلاح آن دشوار خواهد بود. علاوه بر این، این فرایند ممکن است روزها -و در برخی موارد هفته ها- طول بکشد و با وجود اینکه تخمین های با جزئیات بیشتری بدست آورده اید، اما باز هم آنها در این مرحله دقیق نخواهند بود.

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

تخمین اقلام موجود در بک لاگ محصول را می توان با استفاده از استوری پوینت و روش پلنینگ پوکر انجام داد. برای اطلاعات بیشتر به کتاب Agile Estimating and Planning نوشته مایک کوهن مراجعه کنید.

استفاده از نمودار Burndown انتشار برای پیگیری میزان پیشرفت

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

اولین نقطه داده نمودار، تخمینی از میزان کار لازم برای توسعه اقلام این انتشار قبل از شروع کار توسعه است. برای رفتن به نقطه داده بعدی، میزان کار باقی مانده در بک لاگ محصول در انتهای اولین اسپرینت را تعیین کنید. سپس یک خط بین دو نقطه بکشید. این خط burndown نامیده می شود که نرخ پیشرفت انجام اقلام بک لاگ محصول را نشان می دهد. دو عامل روی این نمودار تاثیرگذار هستند: 1) تغییر در بک لاگ محصول و 2) سرعت یا همان velocity (که توانایی تیم توسعه برای پیش بردن کارها را نشان می دهد). امتداد دادن خط burndown تا محور افقی به شما این امکان را می دهد که پیش بینی کنید فعالیتها و کارهای تیم توسعه احتمالا چه زمانی به پایان می رسد (و یا اینکه چه زمانی به اهداف انتشار می رسید و تمام اقلام مرتبط در بک لاگ را تحویل می دهید).

 

 

 

نمودار burndown انتشار در شکل بالا دو خط را نشان می دهد: خط ممتد، burndown واقعی است که پیشرفت تا به امروز و میزان کار باقی مانده را ثبت می کند. خط نقطه چین نیز پیشرفت پیش بینی شده بر اساس تجربه burndown کنونی را مشخص می کند. توجه کنید که burndown در دومین اسپرینت یک خط صاف افقی است که احتمالا نتیجه اضافه شدن اقلام جدید به بک لاگ محصول و یا بازنگری تیم توسعه در تخمین ها است.

برای دستیابی به یک پیش بینی تا حد امکان دقیق، سه نکته زیر را مدنظر داشته باشید:

1. پیش بینی خود را بیشتر بر اساس روند انجام دهید، نه بر اساس فقط یک اسپرینت. برای این منظور معمولا باید دو یا سه اسپرینت جلو بروید تا بتوانید اولین پیش بینی را برای یک انتشار انجام دهید.

2. به این موضوع توجه داشته باشید که burndown اسپرینت های قبلی چقدر روی پیش بینی اسپرینت های باقیمانده تاثیرگذار هستند. در مثالی که در بالا نشان داده شد، دومین اسپرینت دارای یک burndown مسطح بود. این اتفاق ممکن است به دلیل اضافه شدن یکسری اقلام به بک لاگ محصول (بر اساس نتیجه اولین جلسه بررسی اسپرینت) و یا تخمین مجدد اقلام بک لاگ توسط تیم توسعه بوجود آمده باشد. برای رسیدن به یک پیش بینی درست، باید در نظر بگیرید که چقدر احتمال دارد که یک burndown دیگر به این شکل اتفاق بیفتد و تا چه میزان روی پیش بینی شما تاثیرگذار خواهد بود. اگر فکر می کنید احتمال تکرار مجدد آن خیلی ضعیف است، پیش بینی شما در نمودار بالا احتمالاً شیب تندتری خواهد داشت.

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

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

توجه داشته باشید که اگر مجبور بودید تاریخ انتشار را به عقب بکشید و یا تغییر بزرگتری در هدف انتشار بدهید، این موضوع ممکن است در نقشه راه محصول تأثیر داشته باشد و لازم است آنرا اصلاح کنید.

همکاری و تعامل در انجام برنامه ریزی انتشار

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

 

 

این همکاری تضمین می کند که تصمیمات بلند مدت و کوتاه مدت برنامه ریزی برای انتشارها با کمک ذینفعان محصول و تیم توسعه گرفته شده است و در نهایت منجر به برنامه های بهتر، همسویی بیشتر و افزایش تعهد به اجرای تصمیمات خواهد شد.

توجه: برای کسب اطلاعات بیشتر در خصوص تحوّل دیجیتال API محور می توانید کتاب «API بعنوان محصول» را مطالعه کنید.

آیا می دانید که تحوّل دیجیتال نیاز به دگرگونی در فرهنگ نیز دارد؟

آیا در خصوص نقش API در تحوّل دیجیتال چیزی شنیده اید؟

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

راهکار API یا محصول API؟

امروز همه در مورد API حرف می زنند. زمانیکه شما نیز سفر APIتان را آغاز کرده و سرویس های خود را می سازید، به سرعت متوجه می شوید که واقعیت آن چیزی که انتظار داشته اید، نیست. برای مثال ممکن است APIهایی بر روی زیرساخت بیمه ای یا بانکی شرکت خود ایجاد کنید، اما در نهایت توسعه دهندگان و استارتاپ ها علاقه ای به آن نشان ندهند. مشکل چیست؟

در پاسخ به این سوال باید گفت دو نگاه به API وجود دارد : راهکار API یا API Solution و محصول API یا API Product.

ایجاد ارزش توسط این دو مفهوم برای یک سازمان تفاوت های اساسی دارد. در ادامه در خصوص هرم تحوّل دیجیتال و ارتباط آن با برنامه API صحبت می کنیم و توضیح خواهیم داد که این تفاوت بنیادین چیست.

هرم تحوّل دیجیتال

هرم تحوّل دیجیتال شامل سه سطح است:

دیجیتالی سازی اطلاعات (digitization)، دیجیتالی سازی فرآیندها (digitalization) و تحوّل دیجیتال (digital transformation).

در ادامه می خواهیم ببینیم که این سه واژه به چه معناست و چگونه با فناوریهای دیجیتالی مانند API مرتبط است.

 

دیجیتالی سازی اطلاعات

واژه Digitization به معنای عرضه دیجیتالی اشیاء فیزیکی است. برای مثال شما می توانید یک سند کاغذی را اسکن کرده و بعنوان یک سند دیجیتال با فرمت PDF بر روی کامپیوترتان ذخیره کنید. بعبارت دیگر دیجیتالی سازی اطلاعات، تبدیل چیزی غیر دیجیتال به دیجیتال است تا سیستم های کامپیوتری بتوانند از آن استفاده کنند.

دیجیتالی سازی یک تحوّل نیست و یک انتقال از یک وضعیت سنتی به وضعیتی جدید است. اطلاعات به تنهایی هیچ ارزش کسب و کاریی ندارد، اما نقشی اساسی را در کسب و کارهای داده-محور بازی می کند. بعبارت دیگر تسهیل کننده‌ای برای ساخت ارزش تجاری بر مبنای داده است.

همچنین یک API فرایند دیجیتالی سازی اطلاعات را انجام نمی دهد و فقط می تواند نقش یکپارچه سازی و ارتباط بین دو سیستم نرم افزاری را بازی کند.

دیجیتالی سازی فرآیندها

واژه Digitalization به فراهم ساختن، بهبود و یا تغییر فرآیندهای کسب و کاری با استفاده از فناوریهای دیجیتال (مانند APIها) و داده‌های دیجیتالی اشاره دارد.

برای مثال شرکتی یک کارمند جدید استخدام کرده تا با یک گوشی موبایل بتواند با تیم و مشتریان شرکت در ارتباط باشد. این کارمند در ابتدا باید یک درخواست ایمیلی برای سیم کارت و گوشی به مدیر تدارکات بفرستد. مدیر تدارکات اطلاعات کارمند را با فکس به یک شرکت اپراتور موبایل ارسال می کند. نماینده مشتری در شرکت اپراتور اطلاعات فکس را در سیستم وارد کرده و ثبت سفارش می کند. پس از چند روز گوشی موبایل، سیم کارت و رسید به شرکت متقاضی ارسال شده و در اختیار کارمند مربوطه قرار می گیرد.

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

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

سه ارزش کسب و کاری برای مثال فوق قابل ذکر است:

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

2. مدیر تدارکات بطور خودکار از استخدام کارمند جدید و ثبت درخواست برای او مطلع شده و می تواند بر روی پشتیبانی کارمند جدید تمرکز کند، بجای اینکه درگیر فرایند ثبت سفارش برای او شود.

3. هزینه های شرکت اپراتور در فرایند ثبت سفارش کاهش می یابد. مسئول دریافت سفارشات اکنون می تواند بر روی خلق ارزش برای مشتری و خلق تجربه بهتر برای او تمرکز کند.

در نهایت فرایند آماده به کار شدن کارمند جدید بهبود یافته و با خودکار شدن آن، هزینه های کار دستی نیز حذف شده است.

تحوّل دیجیتال

واژه Digital Transformation به معنای تحوّل و دگرگونی بنیادین در فعالیتها و مدل های کسب و کاری یک شرکت است تا بطور کامل بتواند از مزایای فناوریهای دیجیتال بهره برداری کند.

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

تغییر از گام دیجیتال سازی اطلاعات به دیجیتالی سازی فرآیندها معمولا ساده بوده و به سرعت قابل انجام است، اما رسیدن به گام دگرگونی دیجیتال واقعاً یک تحوّل تدریجی می باشد.

دو نوع API و پارادایم تغییر

پیتر دروکر یک مدل تغییر را برای سازمانها پیشنهاد داده که می خواهیم در اینجا از آن برای حوزه API استفاده کنیم. او پیشنهاد می دهد که مدل تغییر در یک سازمان شامل سه بخش است:

• استراتژی: سازمان می خواهد به چه چیزی برسد؟ استراتژی ماهیتی تحوّل گرا دارد.

• تاکتیکها: سازمان چگونه می خواهد به اهدافش برسد؟ تاکتیک ها از جنس گذار می باشند.

• عملیات: سازمان بطور مرسوم باید چه کاری انجام دهد؟

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

هر سازمانی که بخواهد کسب و کارش از لحاظ عملیاتی به درستی انجام گیرد، باید فرآیندهای خود را استاندارد کرده و آنها را از لحاظ زمان، هزینه و کیفیت بهینه سازد. این سازمان باید بتواند برای حل مسائل کسب و کاری اش از تفکر نقادانه یا Critical Thinking استفاده کند. در این نوع تفکر، فرآیندهای کسب و کاری تجزیه و تحلیل شده و بر اساس واقعیات در خصوص بهبود یا تغییر آنها تصمیم گیری می شود. لذا راهکار API از نوع عملیات است و بنابراین با هدف کاهش هزینه ها، بهبود کیفیت فرآیندهای سازمان و در نهایت استانداردسازی آنها ایجاد می شود.

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

درست است که وجود یک استراتژی خوب همیشه ضروری است، اما اجرای درست آن بدون داشتن تاکتیک های مناسب، همواره چالش برانگیز است. در واقع هدف روشن است اما مسئله ای که باید حل شود شفاف نیست! اینجا جایی است که تفکر طراحی یا Design Thinking به کمک ما می آید تا بتوانیم مناسب ترین راهکارها برای برآورده سازی استراتژی مان را با توجه به محدودیت های سازمان و نیازهای مشتریان بیابیم. در واقع داشتن تفکر طراحی در کسب و کار به ما کمک می کند تا بتوانیم نیازمندی های مشتریان را با استراتژی کسب و کارمان و آنچه از لحاظ فناوری در سازمان ما شدنی است، تطبیق دهیم تا در نهایت برای مشتری خلق ارزش کنیم. محصولات API در رسیدن به این هدف به ما کمک خواهند کرد. آنها می توانند نیازهای مشتری را برآورده ساخته و برای سازمان خلق ارزش کنند.

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

یک سناریو برای ایجاد تحوّل دیجیتال در یک NGO

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

سوال این است که چرا این NGO باید به سمت دیجیتالی شدن حرکت کند؟ دو دلیل را می توان برای این موضوع ذکر کرد:

1. سه دسته افراد هستند که داوطلب کمک به NGO مورد نظر ما می شوند یا مبالغی را به آن اهدا می کنند: افراد مسنی که دارایی های خود را در اختیار این NGO می گذارند و هر طور که شده می خواهند از آن حمایت کنند.؛ جوانانی که اولویتهای متفاوتی دارند و دغدغه اصلی آنها تغییرات آب و هوایی است؛ و افراد میانسالی که وابستگی عاطفی شدیدی به NGO ندارند، اما نگران آینده جامعه هستند. مسئله اینجاست که این پایگاه اجتماعی به شدت در حال کاهش است و داوطلبان نیز اصرار دارند که کمک آنها حتما بر روی زندگی افراد نیازمند تاثیرگذار باشد. اما فرایند داوطلب شدن معمولاً یکسری کاغذ بازی های طولانی دارد. لذا دیجیتالی شدن فرصتی مناسب برای بهبود این تجربه خواهد بود.

2. هر کسب و کاری نیاز به ساختار شکنی دارد و NGO ها نیز از این قاعده مستثنی نیستند! شرکت اوبر دو محصول دارد که با خدمات امدادرسانی در حمل و نقل این NGO رقابت می کند: Uber WAV و Uber Health. برای مثال با کمک Uber WAV افراد ویلچری می توانند به راحتی سفر کنند (با کمک خودروهایی که ویلچر در آنها قرار می گیرد) و رانندگان این خودروها نیز برای کمک به مسافران آموزش دیده اند. لذا این NGO با رقبای تازه ای مواجه است که برهم زننده بازار هستند و لذا باید راهکار تازه ای برای کسب درآمد و کمک به افراد پیدا کند.

خدمات سنتی امدادرسانی حمل و نقل

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

مدل درآمدی این NGO از 4 بخش اصلی تشکیل شده است: کاربر نهایی، خیّرین داوطلب، شعبات و دفتر مرکزی. شکل زیر این مدل را نشان می دهد:

در مدل فوق مشتری یک سرویس امدادرسانی حمل و نقل به مرکز درمانی می گیرد و بابت آن پول پرداخت می کند:

• مشتری نهایی: یک سرویس حمل و نقل را جهت رفتن از منزلش به مرکز درمانی، به شعبه منطقه ای درخواست می دهد. او سرویس مورد نظر را می گیرد و هزینه ای را بابت آن به شعبه پرداخت می کند.

• شعبه: وظیفه هماهنگی داوطلبان و بکارگیری آنها در قالب راننده را برعهده دارد. شعبه باید هزینه سرویس را از مشتری دریافت کرده و مبلغی را به راننده و مبلغی را به دفتر مرکزی (بابت استفاده از برنامه نرم افزاری) پرداخت نماید.

• داوطلبان: آنها وظیفه رانندگی و رساندن مشتری به مقصد و بازگرداندن او را برعهده دارند. یک فرم گزارش را پر کرده و به شعبه می فرستند و منتظر پرداخت مبالغی که هزینه کرده اند (مانند قبض بنزین و رسید پارکینگ) می مانند.

• دفتر مرکزی: برنامه نرم افزاری را در اختیار شعبات می گذارد و در عوض مبلغی را بعنوان هزینه استفاده از آن از شعبه دریافت می کند.

خدمات امدادرسانی حمل و نقل بعنوان یک راهکار API

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

راهکار API: یک برنامه گزارش دهی

می توانیم یک APP موبایل تولید کنیم که داوطلبان با کمک آن از درخواست سفر توسط یک متقاضی مطلع شوند و فرایند گزارش دهی مسافت و مدت سفر نیز بصورت خودکار و از طریق Reporting API انجام شود. این APP گزارش گیری، جایگزین فرم های گزارش می شود (مفهوم digitization) و فرایند گزارش گیری را نیز خودکار خواهد ساخت (digitalization). علاوه بر دیجیتالی سازی گزارش، راهکار فوق باعث کاهش هزینه ها شده و تغییری در سازمان و ساختار کار نیز داده نشده است.

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

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

• مشتری نهایی: یک سرویس حمل و نقل را برای رفتن از منزلش به مرکز درمانی، به شعبه منطقه ای درخواست می دهد. سرویس مورد نظر را می گیرد و هزینه ای را بابت آن به شعبه پرداخت می کند.

• شعبه: وظیفه هماهنگی داوطلبان و بکارگیری آنها در قالب راننده را برعهده دارد. شعبه باید هزینه سرویس را از مشتری دریافت کرده و مبلغی را به راننده و مبلغی را به دفتر مرکزی (بابت استفاده از برنامه نرم افزاری) پرداخت نماید.

• داوطلبان: آنها وظیفه رانندگی و رساندن مشتری به مقصد و بازگرداندن او را برعهده دارند. آنها از یک APP موبایل برای گزارش دهی استفاده می کنند تا بطور خودکار گزارشات خود را به برنامه دفتر مرکزی ارسال نمایند.

• دفتر مرکزی: برنامه نرم افزاری را در اختیار شعبات می گذارد. همچنین فرایند گزارش دهی را با ایجاد یک APP گزارش دهی موبایل برای داوطلبان فراهم ساخته است. در عوض مبلغی را بعنوان هزینه استفاده از آن از شعبه دریافت می کند.

اگر فرض کنیم 12 شعبه منطقه ای داشته باشیم و هزینه خدمات دهی برنامه 600 دلار در ماه باشد، از هر راننده فعال در ماه 6 دلار گرفته شود و 1600 راننده فعال داشته باشیم، در اینصورت 200 هزار دلار درآمد در سال برای دفتر مرکزی حاصل می شود.

خدمات امدادرسانی حمل و نقل بعنوان یک محصول API

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

محصول API: حمل و نقل برای حوزه سلامت

می توانیم یک محصول API حمل و نقل برای حوزه سلامت طراحی کنیم که امکان ثبت و مدیریت درخواستهای حمل و نقل متقاضیان را در اختیار مراکز درمانی قرار دهد. APP موبایل گزارش گیری از همین API بجای API گزارش گیری استفاده می کند. محصول API امدادرسانی حمل و نقل، به مراکز درمانی کمک می کند تا سرویس بهتری به مشتریان خود بدهند. این سناریو، یک مدل کسب و کاری دیجیتال جدید است و به معنای تحوّل دیجیتال در کسب و کار NGO می باشد.

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

• مرکز درمانی: از APIهای امدادرسانی حمل و نقل جهت ثبت سفارش ماشین برای مشتریانش استفاده می کند. مرکز باید هزینه استفاده از سرویس را به دفتر مرکزی بپردازد.

• مشتری نهایی: درخواست یک سرویس حمل و نقل را برای رفتن از منزلش به مرکز درمانی می دهد.

• شعبه: وظیفه هماهنگی داوطلبان و بکارگیری آنها در قالب راننده را برعهده دارد. شعبه باید مبالغ را از دفتر مرکزی دریافت کرده و هزینه داوطلبان را پرداخت کند.

• داوطلبان: آنها وظیفه رانندگی و رساندن مشتری به مقصد و بازگرداندن او را برعهده دارند. آنها از یک APP موبایل برای گزارش دهی استفاده می کنند تا بطور خودکار گزارشات خود را به برنامه دفتر مرکزی ارسال نمایند و در پایان ماه مبالغی که هزینه کرده اند (بنزین و پارکینگ) را دریافت خواهند کرد.

• دفتر مرکزی: API های لازم را در اختیار مراکز درمانی قرار می دهد. یک برنامه نرم افزاری مدیریت حمل و نقل و گزارش دهی دیجیتال را در اختیار شعبات و یک برنامه گزارش دهی را نیز در اختیار داوطلبان می گذارد تا فرایند گزارش دهی آنها نیز به شکل خودکار قابل انجام باشد.

اگر فرض کنیم که میزان صرفه جویی مراکز درمانی به دلیل استفاده از این سیستم 12 میلیون دلار باشد و ما 1 میلیون دلار آن را بعنوان کارمزد دریافت کنیم، در اینصورت 5 برابر بیشتر از راهکار API قبلی (200 هزار دلار) درآمد کسب کرده ایم.

این تفاوت عمده بین دو نگاه به API است: محصول API و راهکار API.

عوامل تسهیل کننده و بازدارنده در تحوّل دیجیتال

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

فناوریهای جدید باعث ایجاد ظرفیت های تازه و خلق ارزش کسب و کاری می شوند. در مثال NGO، ما از فناوری API برای ایجاد یک مدل کسب و کاری دیجیتال جدید بر اساس محصول API امدادرسانی حمل و نقل استفاده کردیم. اما تاکنون به یک نکته توجهی نکرده ایم: زمینه اجتماعی یا خود سازمان. این نکته ممکن است باعث تسهیل و یا بازدارندگی در خلق ارزش کسب و کاری از طریق API شود …

 

تحوّل دیجیتال یک پروژه نرم افزاری نیست و چیزی فراتر از فناوری می باشد. تحوّل دیجیتال ایجاد سازمانی است که آماده بکارگیری مزایای حاصل از ظرفیت های فناوری است. لذا زمینه اجتماعی یا همان سازمان، به دو صورت ممکن است بر روی تحوّل دیجیتال تاثیرگذار باشد:

1. عوامل بازدارنده: عواملی که اثربخشی ظرفیت های فناوری در سازمان شما را بر ارزش کسب و کاری تان کاهش داده و یا متوقف می سازند. حذف این عوامل را در اولویت کاری خودتان قرار دهید:

• ایجاد API بعنوان پروژه: گاهی اوقات یک سازمان API هایش را بصورت یک پروژه نرم افزاری در نظر می گیرد. این دیدگاه در زمان دیجیتالی سازی خوب است و باعث افزایش کارایی و صرفه جویی در هزینه ها می شود، اما پروژه ها فاقد ظرفیت ایجاد یک چشم انداز و ترسیم یک نقشه راه و یادگیری در مسیر این نقشه می باشند. بعبارت دیگر API بعنوان پروژه برای خلق ارزش دیجیتال و یا ساخت یک اکوسیستم دیجیتالی مناسب نیست. شما بایستی رویکردی محصول محور به API داشته باشید.

• نداشتن استراتژی API و یا همسو نبودن این استراتژی با استراتژی های سازمان: نداشتن استراتژی به معنای عدم تمرکز و نداشتنKPI است. اگر نتوانید میزان پیشرفت تان را اندازه گیری کنید، نمی دانید که آیا به موفقیت رسیده اید یا نه. همچنین اگر استراتژی شما با استراتژی سازمان همسو نباشد، پشتیبانی لازم را از مدیریت دریافت نخواهید کرد.

• نداشتن مسئولیت پذیری و پاسخگویی: یک نفر (برای مثال مدیر محصول API) باید در سازمان شما تصمیمات لازم درباره برنامه APIتان را مطابق با چشم انداز آن بگیرد و مسئول این محصول باشد. مطمئن شوید که تیمی که ایده پردازی، طراحی و ساخت برنامه API را انجام می دهد نیز پاسخگوی آن است.

• نبود نظارت کافی بر برنامه API: اگر نقشها و وظایف لازم در فرایند عملیاتی سازی برنامه API روشن نباشد و یا وظایف به درستی بین افراد تقسیم نشده باشد، برنامه API با مشکل مواجه خواهد شد. برای مثال کسی که نیاز و مسائل مشتری را می فهمد، باید APIهای لازم را طراحی نماید.

2. عوامل تسهیل کننده: این عوامل باعث سهولت در تاثیرگذاری ظرفیت های فناوری محور بر ارزش کسب و کاری می شوند. برخی از آنها عبارتند از:

• استخدام مدیر محصول API: این فرد چرایی و چگونگی محصول API را می داند. وظیفه اوست که تحقیقات بازار را انجام داده و فرصتها را شناسایی کند؛ نیازها و مشکلات مشتری را مشخص کرده و محصول دیجیتال را به بالاترین ظرفیت عملیاتی اش برساند. او می داند که چگونه باید مشتریان، کسب و کار و فناوری را به هم متصل سازد.

• استفاده از BizDevOps: تیم محصول API باید شامل افراد کسب و کاری، توسعه دهندگان و تیم عملیات باشد (مدیر محصول، برنامه نویس، مهندس DevOps، تحلیل گر کسب و کار و غیره). این گروه با یکدیگر تعامل و همکاری دارند تا بتوانند به شکل موثری برای توسعه دهندگان و مشتریان نهایی خلق ارزش کنند.

• از ساختمان خارج شوید: ساخت محصولات بدون صحبت با مشتریان و درک آنها با شکست مواجه خواهد شد. با آنها صحبت کنید تا نیازمندی ها و کاری که باید برایشان انجام دهید (jobs-to-get-done) را شناسایی کنید. آنگاه می توانید راهکار درستی برای حل مشکل آنها پیدا کنید.

• تحلیل-محور باشید: محاسبه تعداد فراخوانی APIها ارزشی برای شما به دنبال ندارد. در عوض KPI های مناسب را پیدا کنید. این KPIها به شما کمک خواهند کرد تا بینش لازم در خصوص بهبود محصول APIتان را بدست آورید. تحلیل اطلاعات و داده های درست کمک می کنند تا تصمیمات درستی بگیرید.

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

• از ظرفیت سازمان کمک بگیرید: از توانمندی و ظرفیت تیم فروش و بازاریابی تان در عرضه محصولات API استفاده کنید. آنها می توانند بازخوردهای مشتری (بخصوص از شرکای تجاری) را به شما منتقل سازند.

جمع بندی

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

همچنین توضیح دادیم که محصولات API چگونه باعث ایجاد مدل های نوآورانه کسب و کاری دیجیتال می شوند. اما بهرحال زمینه اجتماعی یا سازمان ممکن است تبدیل مزایای فناوری به ارزش های کسب و کاری را محدود سازد.

تحوّل دیجیتال یک پروژه نرم افزاری نیست و موضوعش فقط محصولات دیجیتال نمی باشد، بلکه آماده سازی سازمان برای بهره برداری از مزایای ظرفیتهای فناوری محور است.

بکوشید تا موانع سر راه تان در تحوّل دیجیتال و بهره گیری از ظرفیت های فناوری محور سازمان را برطرف سازید. برای مثال برنامه API را فقط یک پروژه نرم افزاری نبینید و محصولات APIتان را با استراتژی های سازمان همسو سازید.

در نهایت سعی کنید یکسری عوامل تسهیل کننده را در تحوّل دیجیتال API-محور بکارگیرید. برای مثال یک مدیر محصول API استخدام کنید، تیم های BizDevOps شکل دهید و ذهنیتی استارتاپی را در تیم APIتان شکل دهید.

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

منبع: مجموعه مقالات Amancio Bouza در خصوص مدیریت محصول API و تحوّل دیجیتال API محور