خیلی وقت ها نمی دونیم که الان باید کدوم متدلوژی رو باید انتخاب کنیم.یکی از راه هایی که میشه فهمید اینه که بریم و بخونیم و درموردشون کلی چیز بفهمیم که این متدلوژی ها چیهستن و به چه دردی میخورن و در ادامه ببینیم که در دنیای دیزاین به چه درد ما میخورن.اما تو این مطلب به طور اجمالی و سریع طبق چند پارامتر درمورد مساله ای صحبت میشه که میتونه کمک کنه کمی بیشتر در موردشون بدونیم و بفهمیم.
بسیاری از افراد هستند که تحت تاثیر این متدلوژی ها قرار میگیرند و سوالاتی مانند سوالات زیر براشون پیش میاد:
نکته حائز اهمیت این هست که این سوالات و خیلی بیشتر از این ها سوالات متداولی هستن که ممکن است برای افراد حرفه ای هم پیش بیاد.
وقتی این سوالات رو در اینترنت دنبال کنیم متوجه میشیم که خیلی ها دنبال پیدا کردن جواب هستن و خیلی های دیگه با توجه به تجربیات و دانششون جواب هایی هم به اونا دادن.
گارتنر (Gartner) در حرکتی جالب تلاش کرده تا روشهای مختلفی مانند Design Thinking ، Lean ، Design Sprint و Agile رو به خوبی نسبت به یک دیگر نشون بده.در شکل زیر همونطور که میبینیم یک سری دایره تو در تو و رنگی کنار هم قرار دارند که نشان میده در هر مرحله ،کدام متدلوژی و چطوری در کنار هم و با هم و در هم استفاده میشن .خیلی از این طلاقی ها و در هم تنیده شدگی ها جای بحث داره که چطوری این اتفاق افتاده.
اگه به تصویر زیر دقیق نگاه کنیم در هم پیچیدگی ها،همپوانی ها و حلقه های تو هم رفته زیادی میبینیم که
متشکل از چندین متدلوژی هستن.اینکه چرا و چطور این پیچیدگی ها و همپوشانی ها بوجود میاد هم بحث مفصلی داره.
خیلی منطقی هست که به هر یک از این متدلوژی ها فقط به عنوان یک دسته از ابزار ها و تکنیک هایی نگاه کنیم که میتونن به تنهایی کاری برای ما انجام دهند و نه اینکه کنار هم یا با ادغام هم در موردش بحث کنیم.دلیلش هم بسیار واضحه ، چون هرکدام در یک طیف و شرایط خاصی باعث نواوری و ارزش افزوده به محصول و فرایند های توسعه محصول می شوند. ابتکارات نوآوری میتونه از ریسرچ کردن توی یک فضایی که کاملا نسبت به اون نا اشنا هستیم شروع بشه و با داده هایی که داریم کم کم به سمت آزمایش ایده ها و راه حل هایی که پیدا میکنیم بریم و این کار رو تا زمانی که به بهبود مداوم محصول و راه حل ها منجر بشه ادامه میدهیم.
اما این فرایندی که به اجمال گفتم چطور ممکنه که اتفاق بیافته و اصلا یعنی چی؟
خوب و بادقت به این تصویر زیر نگاه کنین:
حالا به پارامتر ها و فاکتور هایی که در اون قرار داره به دقت فکر کنین.
مدل تجاری و کسب و کاری جنبه ای هست که بنظر میرسه خیلی وقت ها نادیده گرفته میشه درحالی که مهمترین پارامتر برای بلوغ سازمان و کسب و کار هست.شاید بشه گفت در 90% مواقع کسب و کارها بدون مدل تجاری شروع به کار میکنن که فی النفسه اصلا چیز بدی نیست،هرچند داشتنش بسیار مفید هست؛اما در خیلی مواقع ما تنها ایده ای در مورد یک سری مساله، مشکل یا حتی فراتر از آن داریم. در مدل نوآوری معروف مکنزی در بخش 1 و 2 آن مدل های تجاری اغلبا به خوبی درک میشن .برای شروع نوآوری هایی که عمدتا در یک کسب وکار مخربن.
در استارتاپ ها و شرکت های نوآوری که ایده ایی دارند که ممکن است مخرب باشن اونهم در یک تجارت زنده و درحال کار ، مدل تجاری باید از طریق ریسرچ و داده و تست های مدل کسب و کاری آزموده بشن و با نتایج دقیق این آزمایشات تأیید بشن.
میدونیم که هرکدوم از این متدلوژی ها بحث های سنگین و تخصصی خودش رو داره؛اما به اختصار کمی درموردشون توضیح میدیم.
وقتی در یک فضای نا مفهوم و مبهم هستیم و قصد داریم تا قدم به قدم فضای مشکلات و متقاضیان اولیه کسب و کار و محصول رو بشناسیم ،گزینه تفکر دیزاین بهترین گزینه است.یعنی "میدونیم" که یک سری چیز ها رو "نمیدونیم" و برای "دونستن " این "نمیدونیم ها " باید دست به تحقیق و ازمایش بر اساس تفکر طراحی بزنیم."تفکر طراحی " اختصاصا برای دیزاینر ها مطرح نشده و بیشتر برای مدیران کسب وکارها تعبیه شده و انواع مختلفی دارد.اما همه این مدل ها از منطق حل مساله و دو الماس (دابل دیاموند ) پیروی می کنند.
به طور ساده ،الماس اول(بخونین فاز اول-discover-define) با تفکر واگرایی شروع می شود و بینشی برای جمع آوری اطلاعات از طریق انواع مصاحبه ها مانند مصاحبه با ذینفعان هدف، مصاحبه با کاربران و سایر روش های تحقیقاتی به ما میده و به دنبال آن با استفاده از تفکر همگرا،شروع به انالیز از طریق دسته بندی و معماری این بینش ها و داده ها و شناسایی نقاط کلیدی درد، مشکلات و انگیزه ها و کارهایی که باید انجام شود،می کنیم.
در الماس دوم(بخونین فاز دوم -develeop-deliver)، هم در ابتدا با تمرین تفکر واگرایی،شروع میکنیم ایده ها و راه حل هایی که در دیامون و الماس اول پیدا کردیم رو قبل از نمونه سازی تست کنیم و به نتایج ایده ال تری برسیم و بعد با تفکر همگرایی به نتیجگیری و نهایتا به دیزاین پروتوتایپ و نمونه اولیه درستی میرسیم که میتونن راه حل ها و سولوشن های ما رو مطرح کنن.
نکته خیلی مهمی که باید بهش خیلی دقت کنیم اینه که طراحی تفکر عمدتا روی بینش ها و مساله هایی بسیار کاراست که می خواهیم بصورت کیفی بررسیش کنیم نه کمی.طبق شکل بالا ( از no business model و problem تا solution) میتونیم بفهمیم که تفکر طراحی دقیقا روی چه فضایی بدرد ما میخوره.
مثلا برای طراحی محصولی که بازار موجود داره و کاربران حاضر هستن نباید سراغ تفکر طراحی بریم مگر اینکه بخواییم مساله و مشکلی رو از ریشه حل کنیم.
تفکر ناب یا لین ،تقریبا با تفکر طراحی هم راستاست.تنها تفاوت اندکی که باهم دارن اینه که ایده از قبل یکم واضح تر هست.ممکنه شرکت،صاحب ایده،کافرما یا تیم در مورد مساله و حتی بیزینس اطلاعاتی دارن یا به عبارتی در فاز (un-validated business model) هستن.یعنی میدونن مدل کسب و کارشون چی هست.طبق تصویر بالا وسعت لین استارتاپ میگه ما یسری راه حل و سولوشن داریم و تقریبا مارکت رو هم داریم، میدونیم چطوری باید بیزینس کنیم ولی نسبت به کاربرا و ایده هاو اتفاقا عمیق نیستیم.به عبارتی دادههایی داریم که خیلی ولید یا معتبر نیستن و نیاز داریم که به یه دادهای قابل اتکاء و معتبری برسیم.
در تفکر ناب ما معمولا همه چیز رو به عنوان یک فرضیه می دونیم تا زمانی که اون ها رو بر اساس متد ها و روش ها معتبر بشن و تصدیق کنیم.پس حتی اگر بگیم ما از مساله و فضاییک هتوش هستیم درک خوبی داریم ولی داده ای نداریم که اونا رو اثبات کنه فقط یک فرض هست.به عبارت دیگه ما فکر میکنیم که میدونیم و فرض میکنیم که از فضای کسب و کار مطلع هستیم.اما لین با مشخص کردن فرضیات مبر روی بوم مشتری(lean canvas) و اولویت بندی و بعد اعتبار دهی مفروضات بر اساس بالاترین ریسک برای کل محصول کار رو شروع میکنه. در ادامه فرایند هایی تعبیه میکنیم که شروع به اعتبار سنجی فرضیه ها میکنه.برای اینکار ابتدا برای پیدا کردن فرضیاتمون فرایند تحقیق رو شروع میکنیم و بعد فرایند تست و ولیدیت کردن راه حل هایی که داریم رو برای چیزی که ساختیم(create solution) تعیین میکنیم و بعد با آزمایش راه حل هامون و اندازه گیری با متغییر های موفقیتمون(KPI success) فرضیاتمون رو رد یا اثبات می کنیم.
لین از فرایند های کیفی در همون ابتدا برای تعیین فرضیه ها استفاده میکنه،اما در ادامه مجبور میشیم که داده های خودمون رو به کیفی تبدیل کنیم تا در مرحله اندازه گیری و ولیدیت کردن ایده قابل اندازه گیری باشه تا میزان کارامدی برای حل مسئله مشخص بشه و اینکه ایا استراتژی رشد و تولید محصولی که در حال اجراست قابل قبول هست یا نه.اما بدیهی هست که همون اصل دستیابی به مشتریان در این جا هم صدق کنه و فرقی نمی کنه که با تفکر طراحی کار می کنیم یا دیزاین اسپرینت یا لین و اجایل. در همه این متدلوژی ها فهم مساله و حل کردن اون ها اصل داستان و هدف اصلی هست.
دیزاین اسپرینت یک روشی هست که ظاهرا از Google Venture ایده گرفته شده که ریشه در لین یوایکس داره قدرت اصلی این متدولوژی این هست که میتونیم یک مفهوم و مساله رو در 5 روز حل کنیم.(مساله رو تا حد ممکن باید کوچیک و کوچیک کرد).ایده دیزاین اسپرینت اینه که در 5 روز می تونیم بینش و مساله و به اشتراک گذاشته ،ایده پردازی کنیم وبعد پروتوتایپ کنیم و بعد از آزمایش به یک مفهوم برسیم که میتوان بر اساس اون دیزاین سولوشن رو انجام بدیم.با توجه به بازه زمانی کوتاه فقط و فقط بر روی بخشی خاص از مساله و راه حل ها تمرکز میکنیم، اما این یک راه عالی برای فهمیدن و یادگیری سریع هست که ببینیم در مسیر درستی هستیم یا نه.
در این متدلوژی همچنان تحقیق و ریسرچ،ایده پردازی،اسکچ و وایرفریم و نمونه سازی اولیه و تست پا برجاست.
بررسی اجایل خیلی مفصل تر از این هست که ما در موردش به این راحتی صحبت کنیم؛اما تا حد ممکن فرایند رو ساده و کلید واژه ای میگم.
هر وقت با مساله هایی رو برو هستیم که عدم قطعیت در مسئله،راه حل و فرضیات بازار در آن مطرح می شه و از طرفی توسعه سریع مد نظر بیزینس هست؛ عموما سراغ اجیال میرن.یعنی وقتی می خواییم چیزی رو بسازیم که "نمی دونیم دقیقا چی هست" و "نمی دونیم کجای مارکتیم " و "نمیدونیم چی داریم" ولی "میدونیم یک مدل کسب و کار معتبر" وجود داره اجایل میتونه کمکمون کنه که سریع چیزی رو که میخواییم رو بسازیم و بریم و یاد بگیریم و بهینه کنیم .در این حالت توسعه چابک راهی عالی برای مقابله با اشتباه هات در مقابل عدم اطمینان و عدم قطعیت در توسعه محصول است.
در توسعه چابک نیاز نیست که از همون ابتدا همه جزئیات محصول رو مشخص کنیم،چون ما فرضیات زیادی داریم که ممکنه عدم قطعیت رو در توسعه محصول مشخص کنه.
اجایل یک راه و متدلوژی خیلی خوب برای ساختن و اندازه گیری و تایید اعتبار فرضیاتی است که ما در مورد محصول داریم.(build-measure-learn and validate assumptions)
اگر محصولی داریم که مشکلات متعددی داره،می تونیم با اجایل سریعا مشکلات اون رو پیدا کنیم و سریعا بر طرف کنیم تا حالش رو بهتر کنیم و اگر محصول ما زنده هست و کاربر فعال داره میتونیم بریم با ابزار های ترکینگی مانند گوگل انالیتکس و هاتجر و.. کاربر رو ترک کنیم و ببینیم در محصول ما چه رفتار هایی دارن و مشکلات محصول رو با اونا شناسایی و برطرف کنیم.به عبارت دیگه مفهوم MVP در اجایل و لین کاملا متفاوت هست و روش ساختشون هم متفاوت هست.
در این روش باید مقدار داده های پشتیبانی رو داشته باشیم تا از ارزش بیزینس طبعیت کنه و در طراحی اسپرینت هایی که بصورت کوتاه مدت تنظیم میکنیم در نظر بگیریم.این داده ها باید قابل اندازه گیری و مشخص باشه تا بشه به راحتی مشکل و مساله ور تعریف و اولویت بندی کنیم
ما باید در backlog محصول میزانی از تسک هایی که شامل مسئله ها و مشکلات و فرضیاتی که لازم است تا در اسپرینت های کوچک تر انحام دهیم رو تعریف کنیم و بعد از اولویت بندی و زمان بندی درست آنها رو ریسرچ و تست و بهینه میکنیم تا بتوانیم میزان ارزش هر اسپرینت و میزان پیشرفت بهینه شدن محصول رو بفهمیم.
اجایل یوایکس رو میتونیم در محصولات خیلی گسترده هم استفاده کنیم
مطمئن هستم که با خوندن این مطلب به تمامی سوالاتی که ابتدا گفتم پاسخی داده نشده و حتی سوالای زیاد تری هم براتون ایجاد شده باشه اما دوست داشتم در این مورد بنویسم تا هم ذهنم رو خالی کنم و هم شاید باب سوالای بیشتر و جواب های بهتری باز بشه و باشن کسایی که بخوان و بتونن تجربه های خودشون رو باهامون به اشتراک بذارن.
اما باید این رو هم درنظر بگیریم که هیچ قاعده خاصی برای شروع کار و اینکه از کجا و به چه شکلی کنیم وجود نداره.توی طراحی مهمترین نکته فهمیدن درست "مساله" و "حل کردن" و ارائه "راه حل" درست هست.همینطور نکته قابل توجه دیگه اینکه همپوشانی هایی وجود داره که دچار سردرگمی بیشتری میشیم و همین همپوشانی ها هستند که باعث میشه یک سری تعصبات و جبهه گیری ها در مورد روش ها بوجود بیاد و یکی بگه روش "X" خوبه یکی دیگه بگه روش "Y".
به هرحال بیشتر این متدلوژی های نوآور می توانند ارزش بسیار زیادی برای توسعه محصول داشته باشن و این واثعا بر عهده تیم هاست تا بتوانند با دلیل و چرایی واقعا مستدل یکی یا حتی ترکیبشون رو باهم انتخاب کنند و بفهمن که چه زمانی و چه تکنیکی بارای ادامه کارشون لازم هست.نکته مشترکی که بین همه تیم های محصول وجود داره اینه که نباید عاشق و متعصب نسبت به متد خودمون عمل کنیم و باید با توجه به فرایند محصول و استراتژی هامون منعطق باشیم.ممکنه جایی از روی فیدبک ها و یادگیری هایی که از مخاطبان و کاربران و حتی استکهولدرها بدست میاریم مجبور باشیم که مسیر و متد خودمون رو تغییر بدیم.
اگه بازم حوصله همچین بحثی رو داشتم درمورد هرکدوم بیشتر توضیح میدم
میتونین از لینک های زیر به منابع بیشتری دسترسی داشته باشین:
Creative Confidence, Lean Startup, Running Lean, Sprint, Dual Transformation, Lean UX, Lean Enterprise, Scaling Lean …
podcast : Innovation@50x
ممنون که تا اینجا با من همراه بودین.
موفق باشین
