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