ام‌بی‌ای چه چیزی را در نحوه‌ی ساختن نرم‌افزار تغییر داد

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

این چیزی است که واقعاً در کارم تغییر کرد.

شروع کردم به قیمت‌گذاریِ آنچه نمی‌ساختم

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

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

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

«کار می‌کند» با «سود می‌دهد» یکی نیست

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

این تصمیم‌های معماری را هم عوض می‌کند. انتخاب «مقیاس‌پذیر» آن نیست که میلیون‌ کاربری را که ندارید مدیریت کند — آن است که منحنی هزینه‌اش با منحنی درآمد واقعی‌تان بخواند. در پروژه‌ی IP Check، یک روش ساده‌ی polling روزانه حدود ۱۷۰ هزار درخواست به ازای هر کاربر تولید می‌کرد — به‌قدری زیاد که خودِ سرویسِ چک را ریت‌لیمیت یا بن می‌کرد. تغییر به تشخیص رویدادمحور همان کار را با هزینه‌ی واقعی به‌جای هزینه‌ی فرضی انجام داد.

تصمیم به نکردن، خودِ کار است

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

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

صحبت‌کردن با کسب‌وکار، نه برای آن

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

سنتز

مهندسیِ خوب و درکِ کسب‌وکارِ خوب متضاد نیستند؛ دو نیمه‌ی ساختنِ چیزی ماندگارند. کیفیت کد شما را در مقیاس زنده نگه می‌دارد. قضاوت کسب‌وکار مطمئن می‌شود که رسیدن به مقیاس ارزشش را دارد. بهترین کاری که حالا می‌کنم دقیقاً همان‌جاست که این دو به هم می‌رسند.

پرسش‌های پرتکرار

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

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

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

---

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