هر روز، هزاران نفر در صنعت هواپیمایی کاری را تکرار می‌کنند که پیش از آن‌ها، نفر دیگری هم انجامش داده و بعد از آن‌ها هم، نفر دیگری دوباره از صفر شروع می‌کند.

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

این‌ها کارهای بی‌ارزش نیستند، اما بیشترشان کارهایی هستند که باید یک‌بار به‌درستی ساخته شوند، نه هزاران بار تکرار.

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

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

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

سه ویژگی، صنعت هواپیمایی را از بسیاری صنایع دیگر متمایز می‌کند.

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

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

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

سه گروه، یک زبان مشترک

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

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

مدل پرواز محصول

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

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

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

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

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

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

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

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

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

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

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

فریب یک ایده‌ی «به‌نظر خوب»

یک کارمند پشتیبانی در یک پلتفرم سفر را تصور کنید که هر روز به ده‌ها سوال دربارهٔ چرا بلیتم کنسل شد پاسخ می‌دهد. یک روز به ذهنش می‌رسد، چرا یک ربات این را جواب ندهد؟

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

سه پرسشی که پیش از برخاست باید جواب داده شوند

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

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

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

چرا بیشتر ایده‌های خوب دقیقاً همین‌جا شکست می‌خورند

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

اگر ایده‌ای در ذهن دارید، پیش از هر قدم بعدی، این سه جمله را با صدای بلند تمام کنید:

«این کار، حداقل چه تعداد بار در چه بازه‌ی زمانی تکرار می‌شود؟»
«الگوی ثابت این کار چیست؟»
«اگر فردا این کار خودکار نشود، کسی که بیشترین آسیب را می‌بیند، چه کسی است و چرا؟»

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

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

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

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

چرا آدم‌ها به‌جای پرش کوچک، مستقیم می‌پرند وسط آسمان

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

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

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

باند کوتاه، آزمایش کوچک

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

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

سه نشانه‌ی یک باند کوتاه خوب

در کمتر از دو هفته قابل اجراست. بیشتر از این، دیگر آزمایش نیست، پروژه است.

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

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

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

در فصل بعد: چرا ساختن برای «همه‌جا» خطرناک‌تر از برخاستن است؟

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

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

پارادوکس موفقیت زودهنگام

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

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

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

قانون اوج‌گیری کنترل‌شده: یک متغیر در هر بار

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

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

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

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

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

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

چرا «کارکردن» با «کارکردنِ پایدار» فرق دارد

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

سه چیزی که در پرواز کروز باید پایش شوند

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

مسیر، آیا محصول هنوز همان مسئله را حل می‌کند؟ نشانه‌ی انحراف معمولاً واضح نیست؛ کسی رسماً شکایت نمی‌کند، فقط کم‌کم سراغ محصول کمتر می‌رود.

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

پارادوکس کروز، پایداری خودش یک ویژگی است

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

در فصل بعد: چگونه یک محصول را به‌درستی تثبیت کنیم، بدون این‌که در جا بزند؟

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

دو اشتباه رایج فرود

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

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

فرود درست، سه چیزی که باید پیش از تثبیت آماده باشند

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

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

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

فرود، پایان مسیر نیست

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

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