وقتی یک دوربین، ۲۰ سال در کشوی میز خاک خورد؛ ماجرای واقعی مردی که آینده را ساخت و سازمانش نخواستش

زمستان سال ۱۹۷۵. یک مهندس ۲۴ ساله به اسم استیو ساسون، در آزمایشگاه شرکت کداک، دستگاهی به اندازه‌ی یک توستر نان با 8 کیلو وزن ساخت. یک لنز از دوربین‌های سوپر-۸ به آن وصل کرده، یک نوار کاست هم پشتش گذاشته. دکمه را می‌زند. بیست و سه ثانیه طول می‌کشد تا یک عکس سیاه‌وسفید، با کیفیتی معادل یک صدم مگاپیکسل، روی نوار ضبط شود.

این، اولین دوربین دیجیتال تاریخ بود.

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

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

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

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

نقشه‌ای از سرزمین فریم‌ورک‌ها: چرا این‌همه مدل مختلف وجود دارد؟

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

دسته‌ی اول: فریم‌ورک‌هایی که «جهت» می‌دهند

این‌ها به شما می‌گویند اصلاً داریم کجا می‌رویم و چرا.

North Star Metric یک عدد واحد است که کل تیم دورش جمع می‌شود؛ مثلاً اسپاتیفای به‌جای اینکه دنبال «تعداد دانلود» باشد، دنبال «زمان گوش‌دادن» رفت، چون آن عدد بود که واقعاً نشان می‌داد کاربر عاشق محصول شده یا نه.

OKR (Objectives and Key Results) یعنی یک هدف کیفی و چند نتیجه‌ی قابل‌اندازه‌گیری برایش تعریف کنید. مثل این‌که بگویید «هدف: کاربر تازه‌وارد را عاشق اپ کنیم»، و نتیجه‌ی کلیدی‌اش باشد «درصد کاربرانی که هفته‌ی اول برمی‌گردند، از ۲۰ به ۳۵ درصد برسد». نکته‌ی مهم درباره‌ی OKR این است که خیلی راحت به یک تشریفات اداری تبدیل می‌شود؛ تیم‌ها اهدافی می‌نویسند که از قبل می‌دانستند می‌خواهند همان کار را انجام دهند، فقط برایش قالب رسمی درست می‌کنند. OKR واقعی، همسویی واقعی بین منافع متفاوت آدم‌ها می‌خواهد، وگرنه فقط یک سند زیبا در یک پوشه‌ی گوگل‌درایو می‌شود.

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

دسته‌ی دوم: فریم‌ورک‌هایی که باعث «شناخت و فهم» کاربر می‌شوند.

Jobs To Be Done (JTBD) می‌گوید کاربر محصول شما را «استخدام» می‌کند تا یک کار مشخص برایش انجام دهد؛ مثلاً کسی که میلک‌شیک می‌خرد، شاید واقعاً دنبال یک صبحانه‌ی سریع و بی‌دردسر برای رانندگی صبح‌گاهی‌اش است، نه دنبال یک نوشیدنی خنک. این فریم‌ورک وقتی خوب کار می‌کند که تیم واقعاً بروند مصاحبه کنند، نه اینکه فقط یک جمله‌ی «وقتی [موقعیت]، می‌خواهم [انگیزه]، تا [نتیجه]» را پر کنند و اسمش را تحقیق بگذارند.

Kano Model ویژگی‌های محصول را به سه دسته تقسیم می‌کند: چیزهایی که نبودشان کاربر را عصبانی می‌کند اما بودشان هیجان‌زده نمی‌کند (مثل ترمز ماشین)، چیزهایی که هرچه بیشتر باشند بهتر است (مثل سرعت اینترنت)، و چیزهایی که کاربر اصلاً انتظارشان را نداشت ولی وقتی می‌بیند ذوق می‌کند (مثل همان لحظه‌ای که اسنپ برای اولین بار موقعیت راننده را زنده روی نقشه نشان داد).

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

دسته‌ی سوم: فریم‌ورک‌هایی که قدرت «انتخاب» می‌دهند

وقتی صد ایده روی میز است و بودجه برای پنج‌تا هست، این‌ها به کار می‌آیند.

RICE هر ایده را از نظر Reach (چند نفر را تحت‌تاثیر قرار می‌دهد)، Impact (چقدر اثر می‌گذارد)، Confidence (چقدر مطمئنیم) و Effort (چقدر زمان می‌برد) نمره می‌دهد و یک عدد نهایی می‌سازد. طبق برخی نظرسنجی‌های صنعتی، RICE پرکاربردترین مدل کمّی اولویت‌بندی در بین تیم‌های محصول است. دام رایج این مدل، بازی‌کردن با عدد «اطمینان» است؛ خیلی‌ها اطمینان بالای ۸۰ درصد می‌دهند بدون این‌که حتی یک آزمایش کوچک انجام داده باشند.

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

Kano که بالاتر گفتیم، در تصمیم اولویت‌بندی هم کاربرد دارد.

دسته‌ی چهارم: فریم‌ورک‌هایی که «اجرا» را می‌سازند

• Scrum رایج‌ترین فریم‌ورک در ایران است؛ اسپرینت‌های کوتاه، جلسات روزانه، نقش‌های مالک محصول و اسکرام مستر.
• Shape Up که بیس‌کمپ ابداعش کرد، برعکس اسکرام عمل می‌کند؛ به‌جای بک‌لاگ بی‌پایان، یک «چرخه‌ی شش‌هفته‌ای» تعریف می‌کند و تیم را در آن قاب زمانی آزاد می‌گذارد که خودش راه‌حل را کشف کند.
• Spotify Model یعنی تیم‌های کوچک و خودمختار (اسکواد) که هرکدام مسئول یک بخش از تجربه‌ی کاربری‌اند.
• SAFe برای سازمان‌های خیلی بزرگ ساخته شده. نکته‌ی مهم این است: یکی از تولیدکنندگان محتوای مدیریت محصول تعریف می‌کند که سازمانش یک‌بار SAFe را روی همه‌چیز، حتی جاهایی که اصلاً برایش طراحی نشده بود، پیاده کرد؛ نتیجه‌اش بوروکراسی بود، نه چابکی. این نکته‌ی مهمی است که چند خط پایین‌تر دوباره سراغش می‌رویم.

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

نه. و دقیقاً همین‌جا اولین دیوار نامرئی سر راهتان سبز می‌شود.

چرا دانستن اسم یک فریم‌ورک، شما را استراتژیست نمی‌کند

یک پیانوی گران‌قیمت را تصور کنید که در گوشه‌ی پذیرایی خانه‌ای گذاشته‌اند. صاحب‌خانه نُت‌ها را بلد است، تئوری موسیقی هم خوانده، حتی می‌تواند برای مهمان‌هایش توضیح دهد که فرق دو آکورد ماژور و مینور چیست. اما وقتی می‌نشیند پشت پیانو، دست‌هایش گیر می‌کند. چون دانستن تئوری موسیقی، با بلد بودن نواختن، دو مهارت کاملاً متفاوت‌اند.

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

این جای تعجب هم ندارد. فریم‌ورک، برخلاف چیزی که در پست‌های لینکدین نشان می‌دهند، یک فرمول ریاضی نیست که همیشه یک جواب درست بدهد. یک RICE برای دو نفر می‌تواند دو خروجی کاملاً متفاوت بدهد، چون نمره‌ی «اطمینان» یا «اثر» را باید از تجربه‌ی واقعی با کاربر دربیاورید، نه از حدس. یک JTBD خوب، به مهارت مصاحبه‌کردن نیاز دارد؛ باید بدانید کِی سکوت کنید تا کاربر ادامه‌ی حرفش را بزند. این مهارت‌ها را از خواندن مقاله یاد نمی‌گیرید. از تمرین‌کردن، خراب‌کردن، و شنیدن یک نفر که بگوید «اینجا اشتباه رفتی، چون…» یاد می‌گیرید.

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

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

اگر تازه دارید می‌فهمید مشکل واقعی کاربرتان چیست، وقت JTBD و مصاحبه است، نه RICE. اگر مشکل را فهمیدید ولی صد راه‌حل احتمالی دارید و باید یکی را انتخاب کنید، وقت Kano یا مقایسه‌ی ارزش در برابر تلاش است. اگر جهت کلی گم شده و تیم نمی‌داند اصلاً چرا این کار را می‌کند، وقت North Star یا OKR است، نه یک فریم‌ورک اجرایی مثل Scrum. و اگر جهت و اولویت مشخص است ولی تیم در اجرا کند و نامنظم است، آن‌وقت سراغ Shape Up یا Scrum بروید.

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

چرا خیلی از تیم‌های ایرانی زیر بار فریم‌ورک نمی‌روند؟

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

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

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

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

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

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

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

وقتی سازمان زیر پای استراتژی را خالی می‌کند

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

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

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

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

جمع‌بندی: دوربینی که این‌بار در کشو نمی‌ماند

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

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

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

دوربین بعدی که می‌سازید، هرچه هست، نگذارید در کشوی کسی بماند.