چارچوبها و متدولوژیهای مدیریت محصول: اجایل، اسکرام، کانبان و تفکر طراحی
مقدمه: هیچ گلوله نقرهای وجود ندارد!
مدیران محصول و تیمها همیشه به دنبال یک «گلوله نقرهای» (راه حلی جادویی) برای ساخت محصولات موفق هستند و صنعت آموزش نیز همیشه آماده است تا با متدولوژیهای مختلف این نیاز را پاسخ دهد. اما واقعیت این است که هیچ گلوله نقرهای وجود ندارد. متدولوژیها صرفاً ابزارهایی در جعبهابزار شما هستند و شما باید بدانید که چگونه و کجا از آنها هوشمندانه استفاده کنید.
در این مقاله، چهار مورد از قدرتمندترین و رایجترین چارچوبهای فکری و اجرایی در مدیریت محصول را بررسی میکنیم: اجایل (Agile) و اسکرام، کانبان (Kanban)، متدولوژی ناب (Lean) و تفکر طراحی (Design Thinking). هدف این نیست که به صورت متعصبانه از یکی پیروی کنیم، بلکه میخواهیم با درک اصول آنها، بهترین فرآیند را برای تیم خود بسازیم.
۱. اسکرام (Scrum) و اجایل (Agile): حرکت از آبشار به سمت چابکی
برای درک ارزش اجایل، ابتدا باید مشکلی که سعی در حل آن دارد را بشناسیم. در روش سنتی «آبشاری» (Waterfall)، ایدهها ابتدا به نیازمندیها (Requirements) تبدیل میشوند، سپس تیم تجربه کاربری (UX) آنها را طراحی میکند و در نهایت مهندسان آن را میسازند. در این روش، تیم مهندسی در مراحل بسیار پایانی وارد فرآیند میشود. بزرگترین نقص روش آبشاری این است که تمام ریسکها در انتهای کار قرار دارند و اعتبارسنجی توسط مشتری زمانی انجام میشود که کار از کار گذشته است.
متدولوژی اجایل (چابک) برای حل این مشکل و افزایش سرعت و انعطافپذیری به وجود آمد. با این حال، بسیاری از شرکتها امروزه ادعا میکنند که اجایل هستند، اما در واقعیت یک فرآیند آبشاری را در قالب اجایل اجرا میکنند (Agile in name only). آنها تنها برای «تحویل محصول» از اجایل استفاده میکنند، اما بقیه بخشهای سازمان کاملاً سنتی عمل میکنند.
تیمهای قدرتمند محصول از روشهای سطحی عبور کرده و اصول واقعی اجایل را در سه محور زیر پیادهسازی میکنند:
-
تکل کردن ریسکها در ابتدای کار (Tackling Risks Up Front): به جای اینکه در انتهای کار متوجه شویم محصول کار نمیکند، تیمهای مدرن پیش از ساختن هر چیزی، ریسکهای ارزش (آیا مشتری آن را میخرد؟)، کاربردپذیری (آیا کاربر میتواند از آن استفاده کند؟)، امکانپذیری فنی (آیا مهندسان میتوانند آن را بسازند؟) و دوام تجاری (آیا برای کسبوکار سودآور است؟) را بررسی میکنند.
-
تعریف مشارکتی محصول: مدیر محصول، طراح محصول و مهندسان به صورت همزمان و در کنار هم برای یافتن راهحلها کار میکنند، نه به صورت ترتیبی و نوبتی.
-
تمرکز بر حل مشکل به جای ساخت فیچر: تیمهای قوی میدانند که هدف صرفاً پیادهسازی یک ویژگی نیست، بلکه حل مشکل اساسی کاربر و رسیدن به نتایج تجاری (Outcome) است.
نقش اسکرام در اجایل
اسکرام یکی از محبوبترین چارچوبهای اجرایی برای پیادهسازی اجایل است. در اسکرام، کارها به دورههای زمانی کوتاه و مشخصی به نام «اسپرینت» (Sprint) تقسیم میشوند (معمولاً یک تا چهار هفته).
- Product Owner (مالک محصول): نقشی در تیم اسکرام است که مسئولیت مدیریت بکلاگ (Backlog) محصول را بر عهده دارد. در شرکتهای محصولمحور، بسیار حیاتی است که مدیر محصول، نقش مالک محصول را نیز به طور همزمان بر عهده داشته باشد.
۲. آشنایی با کانبان (Kanban): جریان مداوم کار
در حالی که اسکرام بر پایه دورههای زمانی ثابت (اسپرینت) استوار است، کانبان (که ریشه در سیستم تولید تویوتا دارد) بر «جریان مداوم کار» (Continuous Flow) تمرکز دارد.
در چارچوب کانبان، هیچ اسپرینت زمانبندی شدهای وجود ندارد. به جای آن، ما از یک بورد بصری (Kanban Board) استفاده میکنیم که ستونهای مختلفی دارد (مانند: ایده، در حال انجام، تست، انجام شده).
اصول کلیدی کانبان:
- بصریسازی جریان کار (Visualize the Workflow): همه اعضای تیم میتوانند در یک نگاه ببینند چه کارهایی در چه مرحلهای قرار دارند.
- محدود کردن کارهای در حال انجام (Limit Work in Progress - WIP): این مهمترین قانون کانبان است. شما نمیتوانید در یک ستون (مثلاً در حال توسعه) بیشتر از یک تعداد مشخص تسک داشته باشید. این کار باعث میشود تیم روی تمام کردن کارهای نیمهتمام تمرکز کند تا اینکه مدام کارهای جدید را شروع کند.
- مدیریت جریان (Manage Flow): تمرکز تیم بر این است که زمان رسیدن یک تسک از ستون «ایده» به ستون «انجام شده» (Lead Time) را به حداقل برساند.
چه زمانی از کانبان استفاده کنیم؟ کانبان معمولاً برای تیمهایی که کارهای پشتیبانی، رفع باگ، یا عملیاتی دارند (که نیازمند پاسخگویی سریع به نیازهای پیشبینی نشده هستند) بسیار مناسبتر از اسکرام است.
۳. متدولوژی ناب (Lean Startup) و مفهوم MVP
متدولوژی استارتاپ ناب (Lean Startup) که توسط اریک ریس (Eric Ries) محبوب شد، یکی از مهمترین مفاهیم در دنیای محصول است. اگرچه این متدولوژی خدمات زیادی به تیمهای محصول کرده است، اما مفاهیم آن گاهی باعث سردرگمی سازمانها میشود.
اصول بنیادین متدولوژی ناب شامل موارد زیر است:
الف) یادگیری معتبر (Validated Learning)
در یک استارتاپ یا محصول جدید، واحد اندازهگیریِ پیشرفت «تعداد خط کد» یا «تعداد فیچرهای ساخته شده» نیست؛ واحد واقعی پیشرفت، یادگیری است.
-
شما باید ثابت کنید که فرضیاتتان درباره مشتری درست بوده است.
-
هر فعالیتی که به یادگیریِ معتبر درباره مشتری منجر نشود، در واقع زباله (Waste) و اتلاف منابع است.
ب) چرخه بازخورد: ساخت - اندازهگیری - یادگیری (Build-Measure-Learn)
این چرخه، موتور محرک متدولوژی ناب است. هدف شما این است که این چرخه را با کمترین زمان ممکن طی کنید:
-
ایده: یک فرضیه دارید.
-
ساخت: کوچکترین چیزی که این فرضیه را تست کند میسازید.
-
اندازهگیری: دیتای واقعی جمعآوری میکنید.
-
یادگیری: بررسی میکنید که آیا فرضیه درست بوده است یا باید مسیر را عوض کنید (Pivot).
ج) فرضیات جهش ایمان (Leap of Faith Assumptions)
هر محصولی روی دو فرضیه اصلی بنا میشود که باید سریعاً تست شوند:
-
فرضیه ارزش (Value Hypothesis): آیا این محصول واقعاً برای کاربر ارزش ایجاد میکند و مشکلش را حل میکند؟
-
فرضیه رشد (Growth Hypothesis): مشتریان جدید چطور این محصول را پیدا میکنند؟
در این راستا، باید از شاخصهای سطحی و فریبنده دوری کرد و روی شاخصهای قابل اتکا (Actionable Metrics) مانند نرخ بازگشت کاربر (Retention) یا نرخ تبدیل (Conversion) تمرکز کرد. این اعداد به شما میگویند که آیا محصول واقعاً بهتر شده است یا خیر.
د) حداقل محصول پذیرفتنی (MVP) و یک سوءتفاهم بزرگ!
در تعریف کلاسیک، MVP ارزانترین و سریعترین نسخهی محصول است که اجازه میدهد چرخه «ساخت-اندازهگیری-یادگیری» را طی کنید. هدف MVP فروش نیست، بلکه تست کردن فرضیات است (مثلاً برای تست نیاز به جابجایی، اول یک اسکوتر میسازید نه یک ماشین).
با این حال، مفهوم MVP یکی از گیجکنندهترین مفاهیم برای تیمهای محصول است. تیمهای زیادی ماهها وقت صرف ساختن یک MVP میکنند تا یادگیریای را به دست آورند که میتوانستند در عرض چند روز یا چند ساعت به آن برسند. همچنین، ارائه یک MVP ضعیف به بازار میتواند باعث خجالتزدگی تیم فروش و بازاریابی شده و به برند آسیب بزند.
نکته طلایی از نگاه مارتین اریکسون (Marty Cagan): در عبارت MVP، حرف P مخفف Product (محصول) است، اما یک MVP هرگز نباید یک محصول واقعی (با کدهای نهایی و مقیاسپذیر) باشد. ساختن یک محصول واقعی صرفاً برای یادگیری، منجر به اتلاف شدید زمان و پول میشود که کاملاً با روح فلسفه Lean در تضاد است. در عوض، MVP باید یک “پروتوتایپ” (Prototype) باشد، نه یک محصول نهایی. ما در مرحله «کشف محصول» از پروتوتایپها استفاده میکنیم و در مرحله «تحویل محصول» یک محصول واقعی میسازیم.
هـ) کاتای محصول (The Product Kata)
کاتای محصول یک تمرین تکرارشونده و بسیار کاربردی برای رسیدن به هدف است که شامل مراحل زیر میشود:
-
هدف نهایی چیست؟
-
الان کجا هستیم؟
-
بزرگترین مانع فعلی چیست؟
-
چه آزمایشی انجام دهیم؟
-
چه یاد گرفتیم؟
۴. تفکر طراحی (Design Thinking): همدلی با کاربر
تفکر طراحی یک متدولوژی حل مسئله است که تمرکز شدیدی بر روی انسان (کاربر) دارد. در محصولاتی که تجربه کاربری (UX) و تعامل انسان و کامپیوتر در آنها نقش پررنگی دارد، این چارچوب معجزه میکند.
تیمهای قوی میدانند که عملکرد (Functionality)، طراحی و تکنولوژی ذاتاً به هم گره خوردهاند. برخلاف مدلهای قدیمی که تکنولوژی صرفاً پیادهکننده طراحی بود، امروزه تکنولوژی باعث توانمندسازی طراحی میشود و طراحی، عملکرد را پیش میبرد. تفکر طراحی به تیم کمک میکند تا این همافزایی را شکل دهند. مراحل ۵ گانه تفکر طراحی عبارتند از:
-
همدلی (Empathize): خود را جای کاربر بگذارید. مصاحبه کنید، رفتارشان را مشاهده کنید و دردهایشان را عمیقاً درک کنید.
-
تعریف مشکل (Define): با استفاده از دادههای مرحله قبل، مشکل اصلی را به صورت شفاف تعریف کنید. عاشق مشکل شوید، نه راهحل!
-
ایدهپردازی (Ideate): حالا با تکنیکهای طوفان فکری، تا جای ممکن راهحلهای متنوع (بدون قضاوت اولیه) تولید کنید.
-
ساخت پروتوتایپ (Prototype): ایدههای برتر را به پروتوتایپهای ارزان و سریع تبدیل کنید تا بتوانید آنها را لمس کنید و به دیگران نشان دهید.
-
آزمون (Test): ایدههای خود را روی کاربران واقعی اعتبارسنجی کنید. ما پیشبینی میکنیم که بسیاری از ایدههایمان کار نخواهند کرد و آنهایی هم که کار میکنند نیاز به چندین بار تکرار و اصلاح دارند. این تستها به ما کمک میکنند تا ایدههای خوب را به سرعت از ایدههای بد جدا کنیم.
نتیجهگیری: ترکیب برندهها
یک مدیر محصول حرفهای، تعصبی روی یک متدولوژی خاص ندارد، بلکه بهترین بخشهای هر کدام را با هم ترکیب میکند:
- او از تفکر طراحی برای همدلی با کاربر و کشف مشکلات واقعی استفاده میکند.
- از متدولوژی ناب (Lean) و پروتوتایپها (به جای MVPهای سنگین) برای اعتبارسنجی سریع و ارزان فرضیات استفاده میکند تا ریسکها را قبل از کدنویسی کاهش دهد.
- و در نهایت از اجایل (اسکرام یا کانبان) برای تحویل سریع، منعطف و باکیفیت محصول نهایی به بازار بهره میبرد.
در بخشهای بعدی مستندات، ما وارد فاز اجراییتر خواهیم شد و خواهیم دید که چگونه با استفاده از این چارچوبها، استراتژی و چشمانداز محصول را تدوین کنیم.
گام بعدی مستندات: در بخش بعدی (۲.۱) وارد فاز استراتژی محصول شده و “چشمانداز و ماموریت محصول (Product Vision & Mission)” را بررسی خواهیم کرد.