این نوشته در ادامه نوشته قبلی در خصوص بخش اول کتاب الهام گرفته یا Inspired به صورت خلاصه به فارسی بازگردانده شده که شامل فصل پنجم تا پایان بخش اول که فصل هشتم کتاب میباشد تهیه شده است.
برای مطالعه بخش قبلی این مطلب به این صفحه https://vrgl.ir/OFRjC مراجعه کنید.
فصل پنجم: شرکت های بزرگ ، نوآوری در محصول به صورت منسجم
شرکت های قدرمتند مبتنی بر محصولات تکنولوژی محور ، اطمینان دارند که نیازمند نوآوری در محصول به صورت کاملا منسجم ، پیوسته و به صورت همیشگی هستند.
این به معنای ایجاد ارزش های جدید برای مشتریان و کسب و کار به صورت مستمر میباشد و نه تنها بهینه سازی محصول فعلی شان کارساز نخواهد بود بلکه نیازمند توسعه هر محصول تا مرحله دست یابی به تمام پتانسیل های آن محصول هستند.
به صورت کاملا غیر عامدانه ، حجم زیادی از منابع شرکت و ذینفعان صرف نگهداری چیزی میشود که کسب و کار از ابتدای شروع به کار خود خلق کرده است و متاسفانه این اتفاق به معنی خاموشی ابتکار عمل و ریسک پذیری برای خلق مجدد محصول میشود، به طوری که برای آن دسته از افرادی که برای پیشبرد کسب و کار به سمت یک مسیر جدید تمایل و توانایی دارند ایجاد موانع میکنند.
در چنین شرکت هایی اغلب نشانه هایی همچون کاهش روحیه ، کمبود نوآوری و سرعت بسیار پایین در بهره برداری مشتریان از خروجی تیم محصول به چشم میخورد. رهبران آنها احتمالا نا امید هستند و به فکر اکتساب شرکت های زیرمجموعه نوآور و یا تاسیس مراکز نوآوری در قلب شرکت خود هستند به امید گرفتن نتایج خوب در این محیط های حفاظت شده که متاسفانه به ندرت نتیجه ای حاصل میشود.
فصل ششم: دلایل اصلی شکست تلاش های محصولی
در گوشه کنار جهان و در هر سطحی از شرکت ها ، روش های پایه ای برای انجام کارها وجود دارد که این اصلا به سبک کار شرکت های تراز اول دنیا نزدیک نیست. این موضوع شاید شما رو کمی غمگین کند اما از شما میخواهم که تا پایان این بحث همراه من باشید.
همانطور که مشاهده میکنید همه چیز از ایده ها شروع میشود که از درون یا بیرون شرکت ها گرفته میشود. سپس اغلب شرکت ها تلاش میکنند تا ایده ها را در یک نقشه راه (Roadmap) قرار بدهند تا دو چیز شفاف بشود :
1- فعالیت و توسعه روی مهم ترین کارها در ابتدای راه
2- تخمین زمان آماده شدن هر بخش از کار
برای دست یابی به این نقشه راه ، جلسات سالانه یا فصلی با ذینفعان جهت بررسی ایده ها و قرارگیری در رودمپ برگزار میشود ، اما برای اولویت بندی آنها نیازمند توجیه قابل درک برای واحد کسب کار داریم که در نهایت به دو سوال زیر ختم میشود:
1- چقدر پول یا ارزش ایجاد خواهد کرد ؟
2- چقدر پول یا زمان صرف خواهد کرد ؟
در این مرحله می بایست مدیر محصول از بالاترین اولویت قرار گرفته در نقشه راه شروع کند به مذاکره با ذینفعان محصول تا از هر ایده یا هدف در نقشه راه ، لیستی از نیازمندی ها (Requirement) استخراج کند. منظور از نیازمندی ها میتواند داستان های کاربر (User Stories) و یا هر مشخصات عملکردی باشد که شما بتوانید با طراحان و مهندسین توسعه محصول جهت ساخت با آنها به اشتراک بگذارید.
سپس تیم طراحی رابط و تجربه کاربری نیازمندی ها را در قالب طرح های تعاملی بصری برای تیم مهندسی حاضر میکند. در این مقطع معمولا اسکرام وارد بازی میشود و تیم مهندسی آن ایده تبدیل شده به طرح بصری را به چند Itteration یا چرخه محصول که در اسکرام به آنها Sprint گفته میشود میشکند. خوشبینانه است که تصور کنیم وظایف تیم تضمین کیفیت یا QA هم در یکی از این چرخه ها گنجانده شده باشد تا از تطابق کار تیم مهندسی با نیازمندی های استخراج شده و عدم بروز پسرفت در فرایند توسعه این بخش اطمینان حاصل کند. در نهایت با چراغ سبز تیم تضمین کیفیت این بخش از محصول برای استفاده توسط مشتریان نهایی انتشار داده میشود.
ممکن است که حسی از اجایل یا اسکرام کرده باشید چون از اسکرام صحبت کردم ولی این فرایند یک ساختار کاملا آبشاری یا Waterfall هست که تا کنون باعث شکست بسیاری از پروژه های توسعه محصول شده است.
بسیاری از تیم ها با روند آبشاری محصول خود را توسعه میدهند در صورتی که در واقع اغلب آنها صرفا ادعا میکنند با فرایند های چابک (Agile) مشغول به کار هستند.
در ادامه به 10 مشکل بسیار اساسی در خصوص این نحوه کار اشاره خواهم کرد که هر کدام به تنهایی میتواند یک تیم را از مسیر اصلی خود خارج کند با اینکه خیلی از شرکت ها دچار چند مورد از آنها هستند.
1- مهم ترین مشکل ، منبع یا منشا بروز ایده هاست. در محصولاتی که ذینفعان صرفا ایده ها را ابلاغ میکنند که قطعا بهترین منشا ایده های محصول نیستند محصول دچار مشکلات فراوانی خواهد شد. پیامد دیگر آن عدم توانمند سازی تیم و تبدیل اجزای تیم صرفا به اجرا کنندگان(بله قربان گویان) دستورات ذینفعان است.
2- به هیچ عنوان در این روش ما نمیتوانیم به دو سوال "چقدر پول یا ارزش ایجاد خواهد کرد" و "چقدر پول یا زمان صرف خواهد کرد" پاسخ های درستی بدهیم. چون درک درستی از کیفیت محصول ایجاد شده در آینده نخواهیم داشت که ارزشی که قرار است ایجاد کنیم را مشخص کنیم. همچنین اغلب مهندسین با تجربه از تخمین دادن در این مرحله اجتناب میکنند و یا در نهایت زیر فشار شرکت ، تخمین های سنتی یا اصطلاحا T-shirt sizing میدهند که مثلا هزینه کوچک(small) ، متوسط ، زیاد و یا خیلی زیاد(extra large) خواهیم داشت.
یکی از مهمترین درس ها در زمینه مدیریت محصول این است که بدانیم چه چیزی را نمیتوانیم بدانیم !
3- مشکل بعدی این است که اغلب شرکت ها از نقشه راه محصول خود هیجان زده میشوند در صورتی که نقشه راه آنها صرفا لیستی از ویژگی ها و پروژه های محصول است. اجازه دهید دو حقیقت ناخوشایند در مورد محصول را شرح دهم :
اولا حداقل نیمی از ایده های ما بعد از اجرا کار نخواهند کرد! یکی از دلایلش این است که مشتریان به اندازه ما از ایده هایمان هیجان زده نخواهند شد و یا به سادگی مشکلات آنها را حل نمیکند.
دوما حتی ایده هایی که ثابت شده اند که پتاسیل خیلی بالایی دارند ، چند چرخه یا تکرار نیازدارند تا به طور کامل ارزش تجاری لازم را ایجاد کنند! که به آن اصطلاحا time to money میگوییم.
4- در این مدل کاری ، به مجری این پروسه نقش "مدیر پروژه" اطلاق میشود و نه یک "مدیر محصول" واقعی. صرفا تیمی یا شخصی نیازمندی ها را جمع آوری و برای تیم مهندسی مستند سازی میکند و این شرح شغلی کاملا مغایر با واقعیت یک "مدیر محصول دیجیتال" در دنیای مدرن است.
5- مشابه موضوع چهارم ، در خصوص طراح محصول نیز این موضوع صدق میکند. در این مدل کاری صرفا طراح محصول به نحوی کار میکند که به آن “lipstick on the pig" به معنای رژ لب برای خوک گفته میشود. یعنی به جای کار روی اصل تجربه کاربری روی زیباسازی ظاهری یک زیرساخت محصولی فاجعه بار کار میکند.
6- مشکل بعدی ورود دیر هنگام برنامه نویسان و مهندسین به فرایند توسعه محصول است. اگر صرفا از آنها برای کدنویسی استفاده میکنید نیمی از ظرفیت آنها را استفاده کرده اید.
راز کوچکی در دنیای محصول : مهندسین و برنامه نویسان معمولا بهترین و تنها منبع نوآوری در محصول هستند.
7- رویکرد اجایل نیز همچون مهندسین خیلی دیر وارد چرخه تولید محصول میشود و نهایتا 20 درصد از ارزش واقعی اجایل استفاده میشود و آن هم در مراحل delivery یا تحویل محصول است و سایر بخش ها از این رویکرد استفاده نمیکنند.
8- این مدل و رویکرد کاملا پروژه محور است ، معمولا تامین بودجه میکنیم ، نیروی انسانی تامین میکنیم ، پروژه را اجرا میکنیم و به مرحله تحویل میرسیم. متاسفانه "پروژه" ها تمرکز روی خروجی (outputs) دارند ولی "محصول" تمرکز رو نتایج (outcomes) دارد.
9- مشکل اصلی دیگر در تفکر سنتی آبشاری این است که ریسک ها در پایان مسیر قرار میگیرند ، به این معنا که customer validation یا اعتبار سنجی مشتری خیلی دیر رخ میدهد. در این روش با اتلاف منابع سازمان ما طراحی میکنیم ، میسازیم ، تست و منتشر میکنیم و در نهایت متوجه میشویم که این محصول نیاز مشتری را برطرف نمیکند. همچنین این روش بر خلاف ادعای تیم ها ، کاملا بر خلاف قواعد Lean است.
10- در مقابل همه تلاش هایی که در این روش انجام میدهیم سازمان در حال از دست دادن زمان و منابع مالی خود میباشد. شاید تلاش زیادی کردیم و محصولی ساخته ایم ولی آن حرکتی نبوده که بازگشت مالی خوبی برای شرکت داشته باشد. بسیار مهم است که شما درک عمیقی پیدا کنید که چرا شرکت شما باید نحوه عملکرد خود را تغییر دهد.
فصل هفتم: فراتر از لین و اجایل
افراد همیشه برای ساخت محصولات دیجیتال در کتاب ها ، آموزش ها و جلسات مشاوره در جست و جوی یک سلاح جادویی برای ساخت محصولات هستند.
شک ندارم که افراد بسیاری از نتیجه حاصل از پذیرش Lean و Agile در تیم های خود نا امید هستند و برای من قابل درک است اما من متقاعد شده ام که ارزش ها و اصول این دو باقی خواهند ماند و نمیخواهم از این جبهه عقب نشینی کنید.
آنها سلاح های جادویی نیستند و این شمایید که باید در استفاده از آنها هوشمند باشید. شرکت های بی شماری را میشناسم که ادعای چابک بودن دارد در صورتی که ماه هاست در تلاشند برای ساخت یک کمینه محصول پذیرفتنی یا همان MVP. بهترین تیم های محصولی که میشناسم از این اصول ، مشابه دیگر تیم هایی که این اصول را تمرین میکنند گذر کرده اند. این تیم ها گاهی نام گذاری های دیگری روی روش های کاری خود گذاشته اند اما در قلب همه آنها این 3 قاعده فراگیر به چشم میخورد:
1- مقابله با ریسک ها به جای انتهای مسیر در ابتدای کار انجام میشود
2- تعریف و طراحی محصولات به صورت همکاری تیمی و نه به صورت توالی مراحل پی در پی (آبشاری)
3- همه چیز حل مسئله است و نه پیاده سازی یک یا چند ویژگی از محصول
این 3 اصل بسیار مهم هستند و در سرار کتاب روی آن تمرکز خواهم کرد.
فصل هشتم: مفاهیم کلیدی
در این کتاب به مجموعه ای از مفاهیم کلیدی در دنیای محصول مدرن اشاره کرده ام که در این فصل به صورت مختصر به شرح آنها خواهم پرداخت :
1- محصول کل نگر یا Holistic Product:
وقتی حرف از محصول میزنیم صرفا منظور ما یک محصول ساخته شده با استفاده از تکنولوژی نیست. محصول شامل ویژگی ها و عملکرد آنها میشود و اینکه با چه تکنولوژی و روشی قادر به پیاده سازی آن ویژگی ها خواهیم بود. همچنین مباحثی همچون طراحی تجربه کاری ، نحوه درآمدزایی ، نحوه جذب کاربران و مشتریان در دو بخش آنلاین و آفلاین را نیز شامل میشود.
به طور مثال اگر شما یک فروشگاه آنلاین محصولات دارید ، فرایندهای فروش و برگشت از فروش یا مرجوعی نیز جزئی از محصول شما به شمار میرود.
به طور کلی در تجارت الکترونیک گستره محصول شما شامل هر چیزی میشود به جز آن کالایی که میفروشید! یا در یک شرکت رسانه ای محصول شما هر چیزی به جز محتوای قابل ارائه خواهد بود.
2- کشف و تحویل مستمر یا Continuous Discovery and Delivery:
کشف و تحویل مستمر در تیم های محصول دو فعالیت اصلی هستند که معمولا به صورت مداوم و موازی پیش میروند. ما نیاز دارم به طور مستمر کشف کنیم که چه محصولاتی ساخته شود و باید آن محصول را به بازار عرضه کنیم. بخش اول موضوعی است که مدیر و طراح محصول روی آن کار میکنند و بخش دوم نتیجه عملکرد مهندسین و برنامه نویسان خواهد بود.
3- کشف محصول یا Product Discovery:
هدف کشف محصول جداسازی سریع ایده های خوب از ایده های نامناسب میباشد و خروجی این فرایند یک انباشته ای از کارهای محصول (Product backlog) تایید شده است.
کشف محصول به چهار سوال اساسی زیر پاسخ خواهد داد:
3-1- کاربران آن را میخرند و یا از آن استفاده خواهند کرد ؟
3-2- کاربران چگونگی استفاده از آن را درک میکنند ؟
3-3- برنامه نویسان ما قادر به ساخت آن خواهند بود ؟
3-4- ذینفعان و مدیران ما قادر به پشتیبانی از آن خواهند بود ؟
4- نمونه های اولیه یا Prototypes:
کشف محصول شامل مجموعه ای از آزمایشات خیلی سریع خواهد بود که برای انجام این آزمایشات با صرف هزینه و زمان کم از نمونه های اولیه یا پروتوتایپ ها استفاده میکنیم. تیم های قدرتمند هر هفته 10 تا 20 ایده محصولی را با استفاده از انواع پروتوتایپ ها آزمایش میکنند.
5- تحویل محصول یا Product Delivery:
هدف از کشف و ساخت نمونه های اولیه این است که به سرعت به نتایجی دست یابیم که محصول ارزش ساخت دارد و اینکه آیا ما قادر به تحویل آن به مشتریان خود هستیم.
این بدین معناست که همه جوانب محصول اعم از عملکرد ، امنیت ، حریم خصوصی و قابل اتکا بودن محصول را سنجیده ایم و محصول ما طبق آگهی های تبلیغاتی ما کار میکند.
هدف از تحویل محصول یا Product delivery ، ساخت محصول فن آوارانه با کیفیتی است که شما بتوانید روی آن کسب و کاری سوار کنید و به مشتریان خود آن محصول را بفروشید.
6- محصول و تناسب بازار/محصول Products and Product/Market Fit:
از آنجا که وقت و هزینه خود را صرف ساخت محصول کرده ایم ، در دنیای محصول میکوشیم تا به مرحله تناسب بازار با محصول خود برسیم. این مرحله کوچکترین محصول واقعی خواهد بود که نیازهای بخش خاصی از مشتریان شما را برآورده میکند. پس بسازید ، آزمایش کنید و منتشر کنید!
7- چشم انداز محصول یا Product Vision:
چشم انداز در واقع اهداف بلند مدت محصول بین 2 تا 10 سال خواهد بود. چشم اندازی به چگونگی تحویل محصول مطابق بر ماموریت اصلی سازمان خواهد پرداخت.
و در نهایت کمینه محصول پذیرفتنی یا همان MVP :
مفهوم MVP یکی از مفاهیم مهم دنیای محصول میباشد. این عبارت توسط فرانک رابینسون در سال 2001 ابداع شد و به غیر از این کتاب ، اریک رایس در کتاب لین استارتاپ باعث فراگیری این مفهوم شد. در تیم های بسیاری دیده ام که در استفاده از این مفهوم دچار سردرگرمی شده اند. یک MVP هرگز چیزی نیست که :
یک MVP باید یک نمونه اولیه یا Prototype باشد نه یک محصول که در ادامه مطالب انواع پروتوتایپ ها را مورد بحث قرار خواهیم داد.
