توجه : برای دریافت بوم مدل عملیاتی می توانید به این لینک مراجعه فرمایید!

مقدمه

اجرای یک استراتژی کسب و کار شامل دو گام مهم تبدیل استراتژی به مدل کسب و کار و سپس تبدیل مدل کسب و کار به مدل عملیاتی یا اجرایی است.

یک ابزار عالی برای تبدیل استراتژی به مدل کسب و کار، بوم مدل کسب و کار یا Business Model Canvas نام دارد که توسط الکساندر اُستروالدر در سال 2010 پیشنهاد شد. این بوم شامل 9 قسمت است که به چهار بخش تقسیم بندی می‌شوند:

• بخش جلویی شامل مشتریان هدف، ارتباطات با مشتری و کانال ها

• بخش میانی شامل ارزش پیشنهادی یا Value Proposition

• بخش زیرساختی شامل فعالیت های کلیدی، منابع کلیدی و شرکای کلیدی

• بخش مدل مالی شامل جریان درآمدی و ساختار هزینه ها

حال می‌توان برای تبدیل مدل کسب و کار به یک مدل عملیاتی، ‌از بوم مدل عملیاتی یا Operating Model Canvas استفاده کرد.

بوم مدل عملیاتی چیست؟

بوم مدل عملیاتی یا Operating Model Canvas ابزاری برای بیان عملیات مورد نیاز جهت اجرایی کردن یک استراتژی کسب و کار است. این بوم از 6 بخش تشکیل شده که با واژه POLISM نیز شناخته می‌شود:

فرایندها یا Processes: یا همان زنجیره عرضه ارزش Value Delivery Chain؛ کارهای مورد نیاز جهت عرضه ارزش پیشنهادی محصول یا خدمت را مشخص می‌کند.

سازمان یا Organization: افرادی که باید کارهای فوق را انجام دهند و چگونگی سازماندهی آنها در قالب واحدهای اجرایی سازمان شما

مکان ها یا Locations: مکان هایی که باید کارها در آنجا انجام شود و دارایی ها و تجهیزات مورد نیاز در این مکانها

اطلاعات یا Information: سیستم های اطلاعاتی موردنیاز جهت پشتیبانی از کار

تامین کنندگان یا Suppliers: چه سازمان ها و شرکت هایی باید ورودی های لازم برای انجام کارها را برای ما مهیا ‌کنند و چه نوع ارتباطی با این سازمان ها داریم.

سیستم های مدیریتی یا Management Systems: فرایندهای برنامه‌ریزی، بودجه‌بندی، مدیریت کارایی، مدیریت ریسک، بهبود مستمر و مدیریت افراد. این سیستم‌ها متصل‌کننده سایر پنج بخش فوق هستند.

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

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

ارتباط بوم مدل کسب و کار و بوم مدل عملیاتی

همانطور که شاید شما هم متوجه شده باشید، بوم مدل عملیاتی در واقع نیمه سمت چپ یا همان بخش زیرساخت بوم مدل کسب و کار را توسعه می‌دهد:

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

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

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

چند مثال از بوم مدل عملیاتی

بوم مدل عملیاتی اوبر:

بوم مدل عملیاتی شرکت زارا:

بوم مدل عملیاتی اسنپ فیش:

منبع :

کتاب Operating Model Canvas ،نوشته Andrew Campbell و همکاران، انتشارات Van Haren

توجه : برای اطلاعات بیشتر در خصوص طراحی 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

مقدمه

چرا از هر 10 ایده محصول، 9 تای آنها شکست می‌خورند؟ و چگونه می‌توان از آن دوری جست؟

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

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

روش استارتاپ ناب یا همان Lean Startup یک راهکار علمی و پراستفاده برای توسعه و مدیریت مدل‌های کسب و کاری و محصولات نوآورانه مشتری-محور است. این روش کمک می‌کند تا با کمک تکنیک های چابک بتوان محصول را سریعتر در اختیار مشتری قرار داد.

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

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

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

شعار شماره 1: عدم قطعیت و ریسک ها را حذف کنید

ریسک ها و عدم قطعیت های زیادی در توسعه یک محصول جدید بوجود می‌آید. نوآوری به معنای آن است که شما باید مرتباً شکست بخورید، در واقع 90 درصد مواقع شکست خواهید خورد. بله، درست است؛ اما گزینه دیگری نیز وجود دارد …

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

ناب بودن فقط به معنای صرف هزینه کمتر یا شکست سریع و ارزان نیست؛ بلکه درباره استفاده از یک فرایند و یک متدولوژی برای توسعه کارآمد محصول موفق است.

بوم ناب (شکل زیر) به شما کمک می‌کند که محصول‌تان را ارائه کرده و ریسک های عمده و عدم قطعیت موجود در آن را شناسایی کنید و استراتژی کاهش آنها را مشخص نمائید.

شعار شماره 2: هوشمندانه‌تر کار کنید، نه سخت‌تر

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

آیا باید این محصول ساخته شود؟ آیا مشتری به آن نیاز دارد؟ آیا با این محصول یا خدمت، کسب و کار موفقی خواهیم داشت؟

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

در اینصورت زمانیکه به نقطه تناسب بازار یا market-fit برسید، محصول‌تان یک پایگاه خوب از مشتریان خواهد داشت، تقاضا برای آن وجود دارد و قادر است مشکلی از مشتری را برطرف سازد.

روش استارتاپ ناب به شما کمک می‌کند تا مطلوب بودن، ارزشمندی و عملی بودن یک محصول را مهیا سازید.

شعار شماره 3: یک کمّینه محصول پذیرفتی یا MVP بسازید

جزء کلیدی روش استارتاپ ناب، چرخه ای به نام ساخت-اندازه‌گیری-یادگیری یا build-measure-learn است. در اولین گام بایستی مشکل و یا مسئله ای را کشف کنید که باید حل شود. سپس این چرخه آغاز می‌شود …

در ابتدای چرخه یک کمیّنه محصول پذیرفنی یا Minimum Viable Product می‌سازید که مشکل یا مسئله مورد نظر را حل کند. هدف آن است که هر چه زودتر به فرایند یادگیری برسید. برای اندازه‌گیری و یادگیری، نیاز به شاخص‌های درستی دارید که به سوالات علت و معلولی شما پاسخ دهند.

برای اینکار معمولا از یک روش توسعه تحقیق به اسم “پنج چرایی” یا Five Why استفاده می‌شود. در این روش سوالات ساده ای پرسیده می‌شود تا چرایی مشکل مورد بررسی قرار گیرد.

اگر فرایند اندازه‌گیری و یادگیری را به درستی انجام دهید، مشخص می‌شود که آیا مدل کسب و کاری شما درست بوده است یا نه. اگر نه، شاید باید اصلاحاتی ساختاری در آن انجام دهید: برای مثال چرخش: تست یک فرضیه جدید در خصوص محصول، استراتژی آن و یا موتور رشد محصول.

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

شعار شماره 4: یادگیری اعتبارسنجی شده

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

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

چرخه ساخت-اندازه‌گیری-یادگیری را استفاده کرده و خوشحال باشید! زیرا این چرخه شما را به یک محصول موفق نزدیکتر می‌کنند.

جمع بندی

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

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

توسعه یک MVP کمک می‌کند تا با کمترین تلاش، محصول را در مراحل اولیه توسعه تست کرده و یک پایگاه اولیه از مشتریان (پذیرندگان اولیه محصول) ایجاد کنید.

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

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

منبع

From an Idea to a Successful Product, Amancio Bouza, 2018

توجه: این مقاله در سال 2017 و توسط رومن پیچلر نوشته شده است. برای اطلاعات بیشتر در خصوص مهارت‌های مطرح شده در این مقاله، به کتاب تدبیراندیشی برای محصول مراجعه کنید.

مقدمه

مدیریت محصول یک عنوان شغلی چند بعدی است. گرچه این شغل بسیار جالب و جذاب است، اما شناسایی مهارت هایی که برای توسعه بهتر محصول و مسئولیت پذیری بیشتر نیاز داریم نیز کار دشواری می باشد.

در این مقاله در خصوص متعادل ساختن مهارت های اختصاصی محصول-محور با توانمندی‌های عمومی مدیریت محصول صحبت خواهیم کرد. پیشنهاد میکنم که پروفایل مهارت های خود را به شکل T توسعه دهید تا مطمئن شوید که مهارت های ضروری و عمیقی برای پیشرفت محصول دارید و قادر هستید تا با چالش های مداوم پیش روی‌تان به خوبی مواجه شوید.

تعادل بین مهارت های عمومی و اختصاصی

برای انجام وظایف شغل بزرگی همچون مدیر محصول یا مالک محصول، شما به دو دسته مهارت‌ نیاز دارید: مهارتهای اختصاصی محصول و مهارتهای عمومی. توانمندیهای اختصاصی محصول، به یک محصول و یا یک سبد از محصولات مشخص مرتبط هستند. این مهارت ها شامل داشتن درک عمیقی از کاربران آن محصول و نیازهایشان، شناخت رقبا و روند بازار است. شما باید دانش دقیقی از خود محصول، ارزش پیشنهادی آن، ویژگی های کلیدی، سفر مشتریان یا user journey، اهداف کسب وکاری و شاخص های کلیدی عملکرد یا KPI محصول داشته باشید.

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

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

برقرای تعادل بین مهارتهای اختصاصی و عمومی منجر به شکل گیری پروفایل مهارتی T-شکل می شود و شما را تبدیل به یک مدیر محصول یا مالک محصول T-شکل همانند تصویر زیر می سازد:

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

رشد مهارتهای افقی شما

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

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

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

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

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

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

در اینجا چند سوال مطرح شده است که شما باید بعنوان یک مدیر محصول توانمند، توانایی پاسخ‌دهی به آنها را داشته باشید:

• چگونه می توان یک چشم‌انداز الهام‌بخش برای یک محصول ایجاد کرد؟

• چطور باید تصمیمات موثری بگیرید و پذیرش بیشتری برای محصول در مشتریان ایجاد کنید؟

• تکنیک‌های تقسیم بندی بازار کدامند؟

• استراتژی محصول چیست و عناصر کلیدی آن کدامند؟

• آیا می‌توانید مدل کسب‌وکار محصول خود را توضیح دهید؟

• چه زمانی و چطور باید نقشه راه محصول خود را بازبینی، تنظیم و یا تغییر دهید؟

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

• چگونه باید محصول خود را ارزیابی و اعتبارسنجی کرد (برای مثال کاربر و قابلیت های محصول)؟ آیا می‌دانید که چه موقع باید کدام تکنیک را انتخاب کنید؟

مهارت های عمودی خود را توسعه دهید

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

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

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

• از محصول خود استفاده کنید (یک اصطلاح معروف می گوید که «غذای سگ خودتان را بخورید!»). این موضوع به شما کمک می‌کند تا کاستی‌ها و فرصت‌های بهبود را کشف کرده و با کاربران همدلی کنید.

• در کنفرانس‌ها و نمایشگاه های تجاری شرکت کنید تا در بالای منحنی روند بازار بمانید. ببینید که سایر شرکت‌ها چه کار می‌کنند.

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

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

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

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

در نهایت، به ایمیلهای شرکت، روزنامه ها و مجلات توجه داشته باشید تا ببنید آیا تحولات شرکت شما (مانند تغییرات در مدیریت اجرایی، تغییرات در استراتژی کسب‌وکار و تغییرات در گروه توسعه) بر روی محصول شما تاثیر می‌گذارد یا نه.

توجه: این مقاله ترجمه ای آزاد از مجموعه مقالات مایکل ساهوتا (Michael Sahota) در خصوص تله‌های تحول چابک در سازمان‌ها است.

اولین تله: تمرکز بیش از حد روی فرایندها و راهکارهای عملی

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

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

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

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

دومین تله: طرح رونمایی برای تحول چابک

زمانیکه یک «طرح اجرایی سازی» برای تحول چابک ایجاد می‌کنیم، دو مشکل اساسی پدیدار می‌شود:

اولین چالش آن است که داشتن این طرح نشان می‌دهد که ما درک درستی از معنای واقعی دگرگونی نداشته ایم. دگرگونی یک تغییر اساسی در عملکرد است که با تغییر در ذهنیت و راهکارهای اجرایی ایجاد می‌شود. بنابراین بسیار خطرناک است که از واژه «اجرایی سازی» برای آن استفاده کنیم. این کلمه نشان دهنده این باور است که سیستم سازمانی و افراد درون آن را می‌توان همچون یک دستگاه کنترل کرد.

دومین چالش، استفاده از کلمه «طرح» است. زمانیکه ما به تعریف واژه «چابکی» در بیانیه چابک نگاه می‌کنیم، می‌بینیم که «پاسخگو بودن نسبت به تغییرات» باارزش‌تر از «دنبال کردن یک طرح و نقشه» است. البته تیم‌های چابک طرح هم دارند: یک شناخت مشترک از نیازهای مشتری و نحوه برآورده سازی آنها می‌باشند.

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

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

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

سومین تله: صدور دستورالعمل برای چابکی و اجباری کردن آن

چابکی یک روش واقعا شگفت انگیز است که نه تنها در پروژه‌های نرم افزار بکار گرفته می‌شود، بلکه راهکاری برای سازماندهی یک تیم حول هر نوع محصولی جهت افزایش بهره وری است. در اغلب موارد، تمایل به بهبود کارآمدی تیم‌ها و سازمان‌ها با یک جمله ساده آغاز می‌شود: “بیایید همه این کار را انجام دهیم!”

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

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

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

راهکار چیست؟ بجای در پیش گرفتن سیاست انجام یک “تغییر بزرگ” اجباری که هرکسی و هر تیمی ‌باید به سمت عملکرد چابک تغییر کند، کار را با تیم‌هایی شروع کنید که خودشان دوست دارند که تغییر کنند.

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

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

2. بصورت تکرار شونده عمل کنید: یک تیم ممکن است بخواهد کارش را با یکسری اصول چابکی شروع کند که برایش معنادار و ملموس باشند – و نه با همه چیزها. و سپس در طول زمان آنها را توسعه داده و تکمیل نماید. لذا تیم ممکن است در چرخه‌های متوالی تکامل پیدا کرده و راهکارهایی را بکار گیرد که باعث بهتر انجام شدن کارهایش می‌شود.

3. بصورت قدم به قدم و تدریجی عمل کنید: تیم را با استفاده از یک راهکار تدریجی با مفاهیم چابکی آشنا کنید. نیازی نیست که همه آنها را به یکباره برای تیم اجبار کنید. افراد زمانی از این اصول استفاده می‌کنند که آماده باشند. لذا سازمان بایستی تیم به تیم و قدم به قدم به سمت راهکارهای بهتری برای انجام کارها حرکت کند.

چهارمین تله: داشتن یک برنامه «دگرگونی»

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

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

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

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

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

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

زمانیکه تغییر را درون کارهایمان تجمیع کنیم، طبیعی‌تر و بهینه‌تر خواهد بود. در اینجا صحبت از یک بهبود مستمر یا فرهنگ یادگیری است…

پنجمین تله: «چابکی» یک هدف است!

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

هیچکس واقعا «چابکی» را نمی‌خواهد! در واقع سازمان‌ها به مزایای حاصل از چابکی نیاز دارند. تصویر زیر پاسخ افراد مختلف به این سوال است که: «چرا می‌خواهید چابک شوید؟» این سوال از افراد زیادی در سرتاسر دنیا پرسیده شده و پاسخ همیشه یکسان بوده است. در واقع مشخص شده است که هیچکس صرفا «چابکی» یا «DevOps» یا «Lean» را نمی‌خواهد.، بلکه افراد به مزایای این برنامه‌ها نیاز دارند.

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

راهکار چیست؟ از چابکی برای پشتیبانی از اهداف سازمان‌تان استفاده کنید. این راهکار بسیار ساده است: از اهداف کلیدی سازمان شروع کنید و بر روی کسب آنها تمرکز نمایید. البته مهم است که نه تنها اهداف ارائه ارزش به مشتریان، بلکه بهبود کارآمدی سازمان را نیز مدنظرقرار دهید.

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

در واقع می‌توان گفت که چابکی بایستی یک راهکار در نظر گرفته شود، نه یک هدف! دراینصورت است که افراد از چابکی برای کارآمدتر شدن و بهبود روش‌های انجام کارهایشان استفاده می‌کنند …

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

پیروی از اصل «برنامه ریزی برای عدم قطعیت» به سازمان این امکان را می‌دهد تا بین انعطاف پذیری کوتاه مدت و برنامه ریزی بلند مدت تعادل ایجاد نمایند. بیانیه چابک به ما یادآور می‌شود که “پاسخگویی به تغییر” ارزش بالاتری نسبت به “دنبال کردن یک برنامه از پیش مشخص” دارد. بنابراین چابکی راهکاری برای واکنش به تغییر در برنامه‌هایی که دنبال می‌کنیم را در اختیارمان می‌گذارد. راهکارهای عملی چابکی گام‌های ملموسی را در اختیار ما می‌گذارند تا بتوانیم انعطاف پذیرتر و پاسخگوتر باشیم. از سوی دیگر اصول چابکی چرایی استفاده از این راهکارها به منظور بهبود روش انجام کارها را نیز برایمان ترسیم می‌کنند.

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

بنابراین در خصوص سومین اصل چابکی …

شما در مسیر صحیح قرار دارید، اگر:
■ شما و تیم‌تان اغلب اوقات قدری عدم قطعیت و نداشتن آگاهی کامل را احساس می‌کنید.

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

✔ جلسات منظم «الهام بخشی» برگزار کنید تا اطلاعات و یافته‌های جدید درباره مشتریان و بازارتان را با افراد مختلف سازمان به اشتراک بگذارید.

✔ سوالاتی را در خصوص مشتریان از دیگر بخش‌های سازمان بپرسید، بدون اینکه حس مشخصی نسبت به پاسخ احتمالی به آن سوال داشته باشید.

✔ عادت کنید که برای یک مسئله، چندین راه حل داشته باشید و امکان شناخت مزایا و محدودیت‌های هر راهکار را فراهم سازید (بجای ارائه تنها یک راهکار “درست”).

■ بطور مرتب پروژه‌هایی که برای مشتریان‌تان ارزش ایجاد نمی‌کنند را متوقف می‌سازید.

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

✔ مدیران تیم‌ها و پروژه‌هایی که شجاعت کافی برای انطباق با شرایط جدید و متعاقبا تغییر مسیر یک پروژه در حال اجرا را دارند، شناسایی و از آنها تجلیل کنید.

✔ مطمئن شوید که موفقیت هر پروژه نه فقط با معیارها و شاخص‌های عملیاتی (مانند “سر وقت” یا “مطابق بودجه”)، بلکه با ارزشی که برای مشتریان فراهم می‌کند نیز سنجیده می‌شود.

✔ پرونده پروژه‌هایی که متوقف شده‌اند و دلیل توقف آنها را ثبت و نگهداری کنید تا بدون توجه به این موارد تصادفا دوباره در فاز اجرایی قرار نگیرند.

■ زمانیکه تعدادی راهکار چابکی برای تیم شما جواب نمی‌دهد، با کمک افراد تیم آنها را تغییر می‌دهید.

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

✔ اطلاعات در خصوص تکامل روش‌ها و تکنیک‌های چابکی‌تان را با سایر تیم‌ها به اشتراک بگذارید.

✔ مکالمات شفاف، صریح و صادقانه‌ای با تیم‌تان داشته باشید –هم به شکل گروهی و هم فرد به فرد- و با آنها در خصوص ارزش‌هایی که از راهکارهای چابکی کسب کرده اند، صحبت کنید.

 

✔ یک نام برای راهکارهایی که برای شما و تیم تان جواب داده است انتخاب کنید، مثلا مدل اسپاتیفای (در Spotify) یا تفکر طراحی سازمانی (در IBM)، تا یک حس مالکیت جمعی نسبت به راهکارهای مورد استفاده خود ایجاد نمائید.

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

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

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

✔ همیشه مواردی همچون “سوالاتی که نمی‌توانیم جواب بدهیم” یا “چیزهایی که ممکن است تغییر کنند” را به بخشی از فرایند برنامه ریزی پروژه‌های خود تبدیل کنید تا مشخص شود که این عدم قطعیت، اجتناب ناپذیر است و باید برای نتایج و دستاوردهای متفاوت آماده باشید.

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

■ اطلاعات مهم را تا زمان برنامه ریزی سالانه بعدی و یا جلسه بودجه بندی نزد خود نگه می‌دارید.

یکی از خطراتی که آهنگ‌های سازمانی یکنواخت و منظم دارند آن است که افراد را وادار می‌کنند که اطلاعات مهم را تا زمانیکه زمان و مکان رسمی‌ تائید و تصویب آنها فرا نرسد، نزد خود نگه داشته و از ارائه آنها خودداری نمایند. این اتفاق برای مثال ممکن است زمانی رخ دهد که مهندسان کارهای blocker را تا جلسه stand-up بعدی به اشتراک نگذارند، و یا بازاریاب‌ها بینش کسب شده از مشتری را تا چرخه بعدی برنامه ریزی بایگانی کنند. این تاخیر منجر به اتلاف منابع، از دست رفتن فرصتها و مشکلات فلج کننده ای می‌شود. برای جلوگیری از این اتفاق شما میتوانید:

✔ بررسی‌های متناوب بیشتری را بین جلسات‌تان برنامه ریزی کنید تا بتوانید پیشرفت تیم را دنبال کرده و اطلاعات جدید را به اشتراک بگذارید.

✔ با تیم تان در خصوص اینکه چه نوع اطلاعاتی باعث ایجاد “وضعیت اورژانسی” می‌شود و بلافاصله باید در خصوص آن گفتگو شود، صحبت کنید. همچنین مشخص کنید که این اطلاعات باید با چه کسی در میان گذاشته شود.

✔ یک الگو و یا یک راهکار عملی برای مدیریت و رسیدگی به اطلاعات “اورژانسی” که از مشتریان، کاربران و مدیران حاصل می‌شود، ایجاد نمائید. این موضوع به شما کمک می‌کند تا یک ساختار و رویه مشخص برای اینکار ایجاد کرده و در عین حال همچنان به این واقعیت توجه داشته باشید که اطلاعات جدید مهم ممکن است در هر زمانی پدیدار شوند.

■ شما طبق یک روش خاص کار می‌کنید زیرا این روش “چابک است”- و فقط همین روش!

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

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

✔ به دنبال معیارها و شاخص‌های کمّی مطلق برای انطباق با اصول چابکی نباشید (برای مثال 20 درصد پروژه‌های ما بایستی تا 5 سال آینده چابک باشد)، زیرا آنها می‌توانند به راحتی کل دنیای اصول و راهکارهای چابکی را تبدیل به یک “تیک” بی معنی کنند.

✔ یک تست محرومیت یا deprivation test اجرا کنید؛ تمام مراسم و آیین‌های چابکی را برای یک هفته متوقف کنید و ببینید چه اتفاقی رخ می‌دهد. سپس یک جلسه بازنگری یا همان Retro با تیم تان برگزار کنید و یک گفتگوی بی پرده در مورد چیزهایی که برای تیم جواب نمی‌دهد، داشته باشید. به این اتفاق به چشم فرصتی برای یک شروع مجدد بنگرید.

 

توجه: مطالب زیر برگرفته از کتاب «چابکی برای همه» نوشته مت لمی می باشد. بزودی ترجمه این کتاب در اختیار علاقمندان قرار خواهد گرفت.

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

در واقع بزرگترین چالش این اصل آن است که:

اینکه افراد در یک تیم درکنار هم باشند و با یکدیگر جلسه و ملاقات داشته باشند، الزاما بدین معنی نیست که با هم تعامل و همکاری دارند!

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

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

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

بنابراین در خصوص دومین اصل چابکی …

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

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

✔ مطمئن شوید که رهبران سازمان در این رخدادهای غیررسمی حضور داشته باشند.

✔ از ایده “گردونه نهار” (Lunch Roulette) برای ایجاد ارتباط غیررسمی بین بخش های مختلف سازمان استفاده کنید.

✔ جلسات “نهار-و-یادگیری” (Lunch-and-Learn) آزاد برگزار کنید تا افراد سازمان بتوانند ایده ها و نظرات شان را خارج از فعالیت های روزانه خود با یکدیگر به اشتراک بگذارند (برای مثال چگونه یک قهوه خوب در محل کارمان درست کنیم و یا چگونه در خصوص یک سفر تفریحی عالی برنامه ریزی نمائیم).

■ همکاری بایستی هم در خصوص استراتژی های بالادستی و هم تاکتیک های پایین دستی صورت گیرد.

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

✔ جلسات “دموی آزاد” برگزار کنید تا تیم های مختلف بتوانند کارهای «در دست انجام» خود را قبل از اتمام به بقیه همکاران نشان دهند.

✔ از رهبران پروژه ها بخواهید با کمک هم نحوه ارتباط پروژه هایشان را طرح ریزی کنند. اینکار بایستی در راستای نیازها و اهداف مشتری بوده و قبل از تائید و بودجه بندی پروژه انجام گیرد.

✔ هر پروژه جدید را با یک طرح کار شروع کنید که حاوی نقاط عطفی برای گرفتن بازخورد از کل سازمان باشد.

■ هیچکس نمی تواند به خاطر آورد که اولین بار چه کسی در سازمان «این ایده» به ذهنش خطور کرده است.

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

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

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

✔ تلاش برای همکاری و تعامل در سازمان را شناسایی کرده و تقویت کنید.

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

■ همه افراد تیم شما می توانند یک روز را مرخصی بگیرند، بدون اینکه کار دچار وقفه شود.

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

✔ در ابتدای هر روز جلسه stand-up را برگزار کنید تا افراد تیم در صورت لزوم تغییر آرایش داده و با شرایط خاص منطبق شوند.

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

✔ یکی از افراد تیم خود را برای یک روز یا یک هفته با فردی از یک تیم دیگر «معاوضه» کنید تا دانش و تجربیات تیم را توسعه داده و فراتر از مرزهای فعلی اش ببرید.

و شما به بیراهه رفته اید، اگر:
■ جلسات شما شبیه گزارش های کتاب های درسی ابتدایی است!

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

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

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

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

■ به اشتراک گذاری هر چیزی بین تیم ها زمانی اتفاق می افتد که آن چیز تکمیل شده و یا کاملا صیقل خورده باشد!

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

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

✔ جلسات طوفان فکری کوتاه اما پرانرژی را با افرادی از تیم های مختلف برگزار کنید تا در خصوص نیازها یا اهداف مشتری بحث کنید. می توانید از ابزارها یا راهکارهای عملی «تفکر طراحی» استفاده نمائید.

✔ ایده های جدید و کارهای در دست انجام را در معرض دید عموم قرار دهید تا بتوانید بازخوردهای مختلف را از همه افراد سازمان دریافت نمائید.

■ صندوق پست الکترونیک شما پر از ایمیل های درخواست برای گرفتن بازخورد است.

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

✔ دقیقا مشخص کنید که به بازخورد چه کسانی نیاز دارید و چرا. می توانید از چارچوب هایی مانند ماتریس واگذاری مسئولیت یا RACI استفاده کنید.

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

✔ نوع بازخورد مورد نیاز و تاریخ مورد نیاز دریافت بازخورد را در ایمیل خود ذکر کنید.

توجه: این مقاله در سال 2014 توسط رومن پیچلر نوشته شده است.

مقدمه

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

شکل زیر دیدگاه من از چارچوب مدیریت محصول است. این چارچوب دارای شش هسته اصلی دانش (به رنگ نارنجی) و شش حوزه پشتیبان (به رنگ بنفش) است.

شکل 1: چارچوب مدیریت محصول از دیدگاه Roman Pichler

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

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

زمینه های اصلی دانش

چشم انداز و رهبری:

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

مدیریت چرخه عمر محصول:

مدیریت موفق یک محصول چیزی فراتر از ساخت و انتشار آن است. شما باید مراحل چرخه عمر محصول و رویدادهای کلیدی در این چرخه مانند رونمایی، رسیدن به نقطه انطباق محصول—بازار یا Product-Market Fit و خاتمه فروش را بخوبی درک کنید. شما باید بدانید که چرخه عمر محصول چطور به شما کمک میکند تا بیشترین فایده از محصول را در تمام چرخه عمر آن بدست آورید؛ این موضوع شامل تاثیر چرخه عمر بر روی کارایی محصول (درآمد و سود)، اهداف محصول، قیمت گذاری و استراتژی بازاریابی، گزینه های در دسترس برای احیای رشد در زمان بالغ شدن محصول و افول آن و همچنین انتخاب بهترین و مناسب ترین راهکار در هر مرحله از چرخه عمر محصول می‌باشد (روش هایی تکرار شونده مانند استارتاپ ناب و اسکرام برای محصولات جوان؛ و روش کانبان برای محصولاتی که در مرحله بلوغ هستند.)

استراتژی محصول و تحقیقات بازار:

محصول شما قرار است به بازار یا بخشی از آن، و به افرادی که به آن نیاز دارند سرویس بدهد. بنابراین شما باید توانایی شناسایی کاربران هدف، مشتریان و بخش‌بندی بازار خود را داشته باشید. شما باید قادر باشید که بطور واضح ارزش پیشنهادی محصول خود را مشخص کنید و بگویید که چرا افراد باید محصول شما را استفاده کنند یا بخرند و به عبارتی محصول شما چه ارزشی برای آنها فراهم می سازد. شما باید قادر باشید رقبای خود را تحلیل کنید تا نقاط ضعف و قوت آنها را تشخیص دهید. شما باید قادر باشید جایگاه محصول خود را مشخص کرده و همچنین ارزشهایی که برند شما باید بوجود آورد را تعیین کنید. شما باید توانایی انجام تحقیقات لازم در خصوص بازار جهت تست ایده های خود، مفروضات مربوط به گروه هدف‌تان و همچنین ارزش پیشنهادی را داشته باشید. این کار با استفاده از روش های کمّی و کیفی مانند مصاحبه ها، مشاهدات مستقیم و ساخت کمیّنه محصول پذیرفتنی یا Minimum Viable Product حاصل می‌شود. شما باید توانایی اتخاذ تصمیم های درست بر اساس داده های دریافتی را داشته باشید. این موضوع شامل استفاده از ابزارهای تحلیل داده و تصمیم گیری در خصوص آن است که باید چرخش کرده (pivot) و در استراتژی خود تغییر ایجاد کنید، و یا به آن پایبند باشید و آنرا اصلاح نمایید.

مدل کسب و کار و مدل مالی:

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

نقشه راه محصول:

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

تجربه کاربری (UX) و بک لاگ محصول:

یک محصول عالی یک تجربه کاربری عالی دارد. شما باید بتوانید تجربه کاری مطلوب کاربران خود را مشخص نمایید. این موضوع شامل توصیف کاربران و مشتریان به عنوان پرسُنا (persona)، مشخص کردن نحوه تعامل کاربران با محصول، طراحی گرافیکی وجنبه های عملیاتی و غیر عملیاتی محصول و ارتباط بین آنها با کمک تیم محصول است (بخصوص کارشناسان خبره UX/UI باید جزو تیم محصول باشند). شما باید بتوانید سناریوها، اپیکها (epics)، داستان های کاربر (user stories)، استوری بوردها (storyboards) و استوری‌مپ ها (storymaps) و نمودارهای جریان کار را ایجاد کنید. شما باید توانایی کار با اسکچ های واسط کاربری (UI Sketch) و موکاپ‌ها (mock-up) را داشته باشید.

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

زمینه های پشتیبان

دانش عمومی بازار:

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

توسعه/تکنولوژیها:

همکار خوبی برای تیم توسعه/مهندسی باشید. به تکنولوژی های نرم افزاری علاقمند باشید. همکاری مناسبی با تیم فنی داشته باشید.

بازاریابی:

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

پشتیبانی و فروش:

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

مدیریت پروژه/ مدیریت انتشار:

قادر باشد فاکتورهای اصلی موفقیت برای هر نسخه از محصول را تعیین کنید. همچنین بتوانید میزان پیشرفت پروژه را تعیین نموده و یا پیشرفت آتی آن را با ابزارهایی مثل نمودار release burndown پیش بینی کنید. قادر باشد با Definition of Done کار کنید و بین محدوده، زمان و بودجه موازنه ایجاد کنید.

فرایند:

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

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

چارچوب پیشنهادی من به شما کمک می‌کند تا نقش های مختلف محصول را با در نظر گرفتن مهارتهای آنها تعریف کنید. برای مثال با استفاده از این چارچوب می‌توان نقش مالک محصول (product owner) را به صورت زیر تعریف نمود:

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

به عنوان مثال دیگر شما می توانید از این چارچوب برای تعریف وظایف و مهارتهای نقش مدیر محصول فنی (tech product manager) استفاده کنید. مدیر محصولی که به دنبال یک محصول فنی بوده و لذا بایستی مهارتهای توسعه/تکنولوژی داشته باشد. شکل زیر نحوه تعریف آن در چارچوب من را نشان می‌دهد.

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

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

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

تعیین معیار های یادگیری با استفاده از چارچوب

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

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

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

منبع :

https://www.romanpichler.com/blog/romans-product-management-framework

مقدمه

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

تفکر طراحی چارچوبی غیرخطی شامل پنج مرحله است:

1. همدلی

2. تعریف مسئله

3. ایده پردازی

4. نمونه سازی

5. آزمون

همدلی

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

برای ایجاد همدلی (Empathy) با کاربران بایستی 1) آنها را مشاهده کنید. در زمان مشاهده همیشه از تکنیک «چه؟ چگونه؟ چرا؟» برای درک عمیقتر نسبت به کاربران استفاده نمائید. بینش کسب شده از کاربر پس از مطرح کردن این «چرایی» و مشاهده رفتارهای او حاصل می شود. 2) با آنها همراه شوید و با آماده کردن سوالات مناسب، با آنها به گفتگو بنشینید. در زمان مصاحبه، چرایی انجام کارهایشان را از آنها بپرسید. آنها را تشویق کنید تا داستان‌شان را برای شما بگویند. برای مصاحبه یک طرح کلی داشته باشید و سوالات را از قبل طراحی و مرتب سازی کنید. سعی کنید پاسخی را به کاربر القا نکنید و پرسش ها را بدون جهت گیری خاصی مطرح نمائید. سوال های طولانی و خسته کننده و یا سوال هایی که پاسخ آنها فقط بله یا خیر است را نپرسید. 3) از کاربران بخواهید نشان بدهند که چگونه کاری را انجام می دهند. به حرف های آنها با دقت گوش بدهید و به تمام نکات مطرح شده توسط آنها توجه نمائید. به تناقض های بین گفتار و رفتارشان توجه کنید تا جزئیات بیشتری برای شما حاصل شود. به زبان بدن آنها دقت کنید. از ساکت شدن آنها نهراسید و قدری تامل کنید تا آنها افکارشان را سازماندهی نمایند. حتی محل کار و محیط زندگی آنها را بررسی کنید تا نکات و جزئیات زیادی در خصوص همدل شدن با آنها بدست آورید.

نقشه همدلی ابزاری بصری جهت ترسیم شناخت حاصل شده از کاربر می باشد. در این نقشه باید به چهار مشخصه در خصوص کاربر پاسخ بدهیم: 1) گفته های کاربر 2) حرکات و رفتارهای کاربر 3) افکار کاربر 4) احساسات کاربر. همچنین در این بوم مشخص می کنیم که کاربر در محیط اطراف خود چه می بیند و چه صحبت هایی را در محیط اطرافش می شنود که بر روی تفکر و تصمیماتش موثر است. در بخش پایینی این نقشه مشخص می شود که کاربر به دنبال چیست (دستاوردی که از محصول ما انتظار دارد) و مشکلاتش چه می باشد (درد و رنج های او).

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

تعریف مسئله

پس از شناخت کاربر و نیازهای او بایستی «دیدگاه» و نگرش کاربر را استخراج کنیم تا تعریف مسئله آشکار شود. برای این منظور باید چالش مورد نظر را چارچوب بندی کنیم تا دیدگاهی که منعکس کننده چشم انداز طراحی باشد، حاصل گردد. ساختار کلی این دیدگاه به این شکل است: «]کاربر[ نیاز دارد به ]نیاز[ زیرا ]بینش کاربر[». پس از استخراج دیدگاه کاربر، می توانیم یک تصویر کلی از مسئله بدست آوریم. لذا بایستی بر اساس شناخت حاصل شده در خصوص نیازهای مهم کاربران، چالش آنها را در قالب صورت مسئله مشخص نمائیم. این مرحله تاثیر زیادی روی دیدگاه ما نسبت به چالش کاربر دارد و بیان دقیق مسئله، در یافتن راه حل مناسب بسیار کمک کننده است و باعث منسجم شدن یافته های پراکنده می شود. بنابراین مؤلفه های تعریف یک مسئله عبارتند از: 1) شناخت کاربر 2) نیازهای کاربر که برآورده ساختن آنها اهمیت بالایی دارد. 3) بینشی که از بررسی اطلاعات همدلی حاصل می شود. ترکیب این سه مؤلفه مشخص کننده مسئله ای می باشد که قرار است حل شود.

ایده پردازی

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

نمونه سازی

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

آزمون

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

جمع بندی

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

منابع :

1. تفکر طراحی: خلاقیت و نوآوری برای همه، یحیی تابش، انتشارات فاطمی، 1398

2. The Design Thinking Playbook: Mindful Digital Transformation of Teams, Products, Services, Businesses and Ecosystems, Micheal Lewrick, Patrick Link, Larry Leifer, 2018, Wiley

طراحی محصول درباره حل مسائل از طریق ساخت اشیاء، تجربیات و سیستم‌ ها است. با این نگاه می‌توان گفت که هر کسی یک طراح است؛ زیرا همه ما حل‌کنندگان مسائل هستیم. یک راهکار عالی برای بیان مسئله طراحی، آن است که از مدل «کارهایی-که-انجام-می‌شود» (Jobes-To-Be-Done) استفاده کنیم. آلن کلمنت، نویسنده و مشاور کسب و کار، این واژه را بر اساس بینشی که در تیم محصول Intercom وجود دارد، پیشنهاد داده است. ایده اصلی در این مدل به شکل زیر خلاصه می‌شود:

زمانیکه —–، من می‌خواهم که —–، بنابراین من می‌توانم —–

یک مثال از مدل فوق به این شکل است: «زمانیکه صبح از خواب برمی‌خیزم، می‌خواهم بدانم که آیا امروز باران خواهد آمد یا نه، بنابراین اگر این اتفاق بیفتد می‌توانم یک چتر بردارم». واژه “زمانیکه” شرایط موجود را نشان می‌دهد. واژه “من می‌خواهم” انگیزه‌ها، نیازها و اهداف مطلوب که مرتبط با شرایط جدید است را مشخص می‌کند. واژه “من می‌توانم” نیز خروجی‌های مورد انتظار یا اهداف واقعی را مشخص می‌سازد که ممکن است پنهان بوده و مستقیما قابل کشف نباشد. استفاده از این مدل باعث می‌شود که بتوانیم در خصوص اینکه نتیجه و پیامد مسئله طراحی ما چه چیزی باید باشد، تصمیم‌گیری کنیم. بر اساس این نتیجه و با استفاده از فرایند مهندسی معکوس می‌توان محصول و کارهای مورد نیاز برای ساخت آن را به صورت مرحله به مرحله مشخص نمود.

ایده دیدن کسب و کار یا مسائل طراحی بعنوان “کارها”، اولین بار توسط کلی کریستنسن، استاد مدرسه کسب و کار دانشگاه‌ هاروارد، مطرح شد. او در سخنرانی خود در سال 2007، مدل فوق را برای بیان این مثال استفاده نمود که چگونه مک‌دونالد فروش شیربستنی خود را افزایش داده است. فروش شیربستنی‌ها بر اساس بازخوردهای مشتریان بهبود یافته بود.

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

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

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

مدل «کاری-که-انجام-می‌شود» همچنین از منظر اهداف و تجربیات نیز قابل بررسی است. محصول همیشه بایستی اهداف واقعی کاربر را مدنظر قرار داده و تجربه ایده‌آلی را برای او مهیا سازد.