از هفتاد و چهار روز تا حد فیزیکی: تفکر "سرعت نور" Jensen Huang چه چیزی را در مهندسی تغییر می‌دهد؟
مقدمه: چرا پیش از درک برنامه زمانی، آن را بهبود دهیم؟
تیمی می‌گوید یک فرایند هفتاد و چهار روز طول می‌کشد. پیشنهاد می‌دهد آن را به هفتاد و دو روز کاهش دهد. پیشنهاد شبیه پیشرفت است. اما اگر کار اصلی با ترتیبی متفاوت در شش روز قابل‌انجام باشد چه؟
این اعداد نمونه‌ای برای توضیح یک روش‌اند، نه وعده‌ای درباره پروژه‌ای مشخص. Jensen Huang از تفکر "سرعت نور" برای توصیف جست‌وجوی حد بنیادی استفاده می‌کند، پیش از آنکه فرایند موجود را نقطه آغاز بپذیریم.
پرسش مهم این نیست که چگونه از همان افراد تلاش بیشتری بخواهیم. پرسش این است که چگونه کار ضروری را از تأخیر به‌ارث‌رسیده متمایز کنیم.
1. فرایند موجود یک شاهد است، نه قانون طبیعت
یک برنامه زمانی تثبیت‌شده ممکن است شامل چیزهای بسیار متفاوتی باشد: کار فیزیکی، انتظار، تأییدها، تحویل کار میان افراد، پردازش دسته‌ای [Batching] و مصالحه‌هایی که به دلایلی انجام شده‌اند که دیگر معتبر نیستند.
بهبود مستمر [Continuous Improvement] از همین ترتیب موجود آغاز می‌کند. می‌پرسد چگونه می‌توان فرایند را کمی بهتر کرد.
استدلال بر پایه اصول اولیه [First-principles Reasoning] پرسشی مقدم‌تر مطرح می‌کند. واقعا چه چیزی باید رخ دهد و چه چیزی مانع رخ دادن آن به شکلی متفاوت است؟
این کار تجربه را بی‌ارزش نمی‌کند. افراد باتجربه اغلب دقیقا می‌دانند چرا یک مرحله دشوار وجود دارد. نکته، بازیابی آن دلایل است، نه اینکه خود برنامه زمانی را توضیح بدانیم.
2. حد هر بُعد مهم را پیدا کنید
"سرعت نور" تعبیری کوتاه برای حد ممکن در چارچوب محدودیت‌های مربوط است. معنایش این نیست که هر فعالیت تجاری واقعا به سرعت حرکت نور محدود است.
در رایانش، این ابعاد ممکن است شامل جابه‌جایی داده حافظه [Memory Movement]، انرژی، تأخیر پاسخ [Latency]، نرخ پردازش [Throughput]، هزینه و زمان ساخت باشند. یک طراحی ممکن است در یک بُعد به حد خود نزدیک باشد، اما در بُعد دیگر مجال قابل‌توجهی باقی بگذارد.
تفکیک این ابعاد مفید است. سامانه‌ای که یک پاسخ را سریع ارائه می‌کند ممکن است با سامانه‌ای که برای پردازش کارآمد درخواست‌های بسیار طراحی شده متفاوت باشد. بهینه‌سازی [Optimising] یکی، دیگری را خودبه‌خود بهینه نمی‌کند.
پیش از ترکیب همه چیز در طراحی نهایی، تیم باید بداند هر هدف چه می‌طلبد.
3. خط مبنای آرمانی تعیین کنید، سپس فاصله را توضیح دهید
مثال شش‌روزه فقط زمانی ارزشمند می‌شود که شصت و هشت روز باقی‌مانده بررسی شوند.
بخشی از آن فاصله ممکن است موجه باشد. فرایند کندتر شاید هزینه کمتری داشته باشد، از تجهیزات کمیاب عادلانه‌تر استفاده کند یا امکان بازرسی ضروری را فراهم سازد. تأخیرهای دیگر ممکن است از تصمیم‌های تکراری یا ترتیبی ناشی شوند که اخیرا کسی آن را زیر سؤال نبرده است.
این تمرین آن انتخاب‌ها را آشکار می‌کند. تیم می‌تواند به جای بحث بر سر اینکه آیا دو روز قابل‌صرفه‌جویی است، بررسی کند چرا فاصله بسیار بزرگ‌تری از خط مبنای بنیادی را می‌پذیرد.
بنابراین حداقل فیزیکی نقطه مرجعی برای قضاوت است. خودبه‌خود ضرب‌الاجل تجاری درست نیست.
4. سادگی یعنی حذف پیچیدگی غیرضروری
یک سامانه رایانشی پیشرفته می‌تواند بخش‌های متعامل بسیاری داشته باشد و همچنان هدف ساده‌ای را دنبال کند. پیچیدگی وقتی مشکل می‌شود که بدون خدمت به آن هدف وجود داشته باشد.
روش Huang این است که بپرسیم آیا یک جزء، مرحله یا وابستگی [Dependency] ضروری است. اگر ضروری است، آن را بفهمید. اگر نیست، بپرسید چرا باقی مانده است.
این با حذف بخش‌های سامانه تا جایی که دیگر نتواند کارش را انجام دهد متفاوت است. تأمین برق، خنک‌سازی، آزمون و قابلیت اطمینان، صرفا به دلیل پیچیده کردن نمودار اختیاری نمی‌شوند.
هدف مفید، طراحی‌ای با پیچیدگی کافی برای برآوردن الزامات است، بدون پیچیدگی اضافه‌ای که فقط عادت را حفظ می‌کند.
5. رهبران باید محل اجرای کار را درک کنند
گزارش پروژه ممکن است تأخیر را شرح دهد و علت آن را پنهان کند. در جایی که کار انجام می‌شود، توضیح می‌تواند بسیار روشن‌تر باشد.
کابل چگونه نصب می‌شود؟ چرا یک جزء منتظر می‌ماند؟ کدام تصمیم وظیفه بعدی را متوقف کرده است؟ این پرسش‌ها سامانه گسترده را به اقدام‌های کوچکی وصل می‌کنند که آن را می‌سازند.
فوریت زمانی مفید می‌شود که مانع واقعی را بردارد. تکرار ضرب‌الاجلی سخت‌گیرانه‌تر بدون درک کار، پیشرفت مهندسی ایجاد نمی‌کند.
رهبری باید به آشکار کردن محدودیت، گرد آوردن تخصص درست و تصمیم‌گیری درباره مصالحه‌های قابل‌قبول کمک کند.
نتیجه‌گیری: پیش از جشن گرفتن بهبود، خط مبنا را زیر سؤال ببرید
قدرت تفکر "سرعت نور" در انضباط پرسیدن چرا است. چرا این ترتیب؟ چرا این دوره انتظار؟ چرا این طراحی؟ کدام محدودیت‌ها از فیزیک می‌آیند و کدام از انتخاب‌ها؟
وقتی این پاسخ‌ها روشن شوند، بهبود مستمر [Continuous Improvement] پایه بهتری پیدا می‌کند. تیم می‌تواند به جای آراستن فرایندی که به ارث برده، فرایندی را بهبود دهد که می‌فهمد.
این روش وعده نمی‌دهد که هر پروژه هفتاد و چهارروزه شش روز طول خواهد کشید. از تیم می‌خواهد بداند چرا چنین نمی‌شود. این دانش کیفیت همه تصمیم‌های پس از آن را تغییر می‌دهد.
Powered By K7