چرا این چهره مهم است؟
لیزا سو در روایت فناوری به خاطر مهندسی نیمه‌هادی و رهبری AMD شناخته می‌شود. اما ارزش مطالعهٔ این مسیر فقط در نام شرکت‌ها یا محصول‌ها نیست. سؤال جذاب‌تر این است که چه مسئله‌ای انتخاب شد، چه محدودیت‌هایی وجود داشت و کدام تصمیم توانست یک مسیر را از پروژه‌ای محدود به اثر گسترده‌تر تبدیل کند. در این پروفایل تلاش می‌کنیم سهم فرد را از کار تیم، شرایط بازار و پیشرفت‌های موازی جدا کنیم؛ چون تاریخ فناوری وقتی مفید است که نه به اسطوره‌سازی تبدیل شود و نه نقش تصمیم‌های شخصی را نادیده بگیرد. برای خوانندهٔ فنی، هدف استخراج الگویی است که بتواند در پروژهٔ امروز خود به‌کار ببرد.
نقطهٔ عطف
یکی از نقاط عطف مهم در مسیر لیزا سو، تمرکز دوبارهٔ AMD روی roadmapهای معماری و محصولات رقابتی در سال‌های پس از پیوستن او به شرکت بود. نقطهٔ عطف لزوماً لحظه‌ای نیست که نتیجهٔ نهایی دیده می‌شود؛ معمولاً زمانی است که تیم روی یک جهت پرریسک سرمایه‌گذاری می‌کند و باید مدت زیادی بدون تضمین موفقیت ادامه دهد. در چنین تصمیمی سه چیز اهمیت دارد: مسئله باید ارزش حل‌کردن داشته باشد، feedback loop باید آن‌قدر کوتاه باشد که خطا زود دیده شود و سازمان باید توان تحمل iteration را داشته باشد. از بیرون، موفقیت اغلب خطی به نظر می‌رسد؛ از داخل، مجموعه‌ای از trade-off، شکست، بازطراحی و زمان‌بندی است.
اثر فنی و صنعتی
اثر قابل مشاهدهٔ این مسیر را می‌توان این‌طور خلاصه کرد: بازگشت AMD به رقابت جدی در CPU و گسترش حضور در دیتاسنتر و شتاب‌دهنده‌های محاسباتی. نکتهٔ مهم این است که اثر صنعتی معمولاً از یک invention تنها نمی‌آید. فناوری زمانی مقیاس می‌گیرد که tooling، زنجیرهٔ تأمین، سرمایه، documentation، developer experience و عملیات نیز با آن رشد کنند. اگر فقط breakthrough فنی وجود داشته باشد اما deployment دشوار یا هزینه غیرقابل‌پیش‌بینی باشد، adoption کند می‌شود. بنابراین هنگام مطالعهٔ مشاهیر، فقط به «چه چیزی ساخت؟» نگاه نکنیم؛ ببینیم چگونه یک ایده به سیستم، platform یا اکوسیستم تبدیل شد.
مدیریت عدم‌قطعیت
فناوری‌های بزرگ با uncertainty ساخته می‌شوند. roadmap ممکن است عوض شود، هزینه بیشتر از انتظار باشد، رقیب مسیر دیگری باز کند یا محدودیت فنی دیر آشکار شود. آنچه در مسیر لیزا سو ارزش بررسی دارد، تصمیم‌گیری در چنین محیطی است. تیم باید بتواند بین vision بلندمدت و evidence کوتاه‌مدت رفت‌وبرگشت کند. vision بدون اندازه‌گیری تبدیل به شعار می‌شود و metric بدون جهت بلندمدت تیم را در بهینه‌سازی محلی گرفتار می‌کند. برای مدیر یا مهندس، هنر اصلی پیدا کردن آزمایشی است که با کمترین هزینه بیشترین عدم‌قطعیت را کم کند.
یک سوءبرداشت رایج
موفقیت یک شرکت semiconductor حاصل کار هزاران مهندس، زنجیرهٔ تأمین و شریک تولید است؛ نقش مدیرعامل را باید در جهت‌دهی و execution سازمان دید، نه طراحی انفرادی همهٔ تراشه‌ها. این تمایز مهم است چون تاریخ فناوری را اغلب به داستان «یک نابغه و یک لحظهٔ جادویی» تقلیل می‌دهیم. در عمل، محصول پایدار نتیجهٔ هزاران تصمیم کوچک، review، عملیات، test و اصلاح است. نسبت‌دادن همهٔ موفقیت به یک نفر هم سهم تیم را حذف می‌کند و هم درس فنی را ضعیف می‌کند. بهتر است نقش فرد را در انتخاب جهت، ساختن تیم، طراحی بخش مشخص، ایجاد platform یا تغییر مدل سازمانی دقیق‌تر ببینیم. این نگاه هم منصفانه‌تر است و هم قابل استفاده‌تر.
درس برای تیم‌های فنی
اگر بخواهیم از این مسیر یک درس عملی بیرون بکشیم: turnaround فنی با یک محصول اتفاق نمی‌افتد؛ roadmap، اولویت‌بندی و تحویل منظم چند نسل پشت سر هم لازم است. برای یک تیم کوچک، این جمله باید به رفتار تبدیل شود. یک مسئلهٔ واقعی انتخاب کنید، success criteria را قبل از ساخت بنویسید، تغییر را به iterationهای قابل‌اندازه‌گیری بشکنید و بعد از هر iteration تصمیم بگیرید چه چیزی باید حذف، حفظ یا بازطراحی شود. اگر پروژه فقط feature جمع می‌کند ولی uncertainty کم نمی‌شود، احتمالاً feedback loop درست نیست. همچنین documentation تصمیم‌ها را جدی بگیرید؛ تیم آینده باید بداند چرا مسیر امروز انتخاب شد.
چطور این مسیر را عمیق‌تر مطالعه کنیم؟
به‌جای خواندن فقط biography، سه نوع منبع را کنار هم بگذارید: یک منبع دربارهٔ خود لیزا سو، یک منبع فنی دربارهٔ محصول یا حوزهٔ اصلی، و یک منبع منتقد یا تاریخی که محدودیت‌ها را هم نشان دهد. سپس یک timeline بسازید و milestoneهای محصول را کنار تغییرهای فناوری و بازار قرار دهید. این روش جلوی hindsight bias را می‌گیرد؛ چیزی که امروز واضح به نظر می‌رسد ممکن است هنگام تصمیم اولیه بسیار نامطمئن بوده باشد. برای هر milestone بنویسید چه چیزی در آن زمان معلوم بود و چه چیزی هنوز معلوم نبود.
تمرین IROSG
یک پروژهٔ کوچک از حوزهٔ مهندسی نیمه‌هادی و رهبری AMD انتخاب کن. در یک صفحه بنویس: مسئله چیست، محدودیت اصلی چیست، چه metricی موفقیت را نشان می‌دهد و کوچک‌ترین آزمایش یک‌هفته‌ای چیست. بعد فرض کن آزمایش شکست خورده؛ چه evidenceای لازم داری تا بفهمی ایده اشتباه بوده یا فقط implementation مشکل داشته است؟ در پایان، یک تصمیم حذف هم بنویس: کدام feature یا فرضیه را حاضر هستی کنار بگذاری تا تمرکز تیم حفظ شود؟ این تمرین کمک می‌کند درس مشاهیر از نقل‌قول الهام‌بخش به روش تصمیم‌گیری مهندسی تبدیل شود.
جمع‌بندی
داستان لیزا سو زمانی ارزشمند است که آن را نه نسخهٔ آمادهٔ موفقیت، بلکه مجموعه‌ای از انتخاب‌ها در شرایط خاص ببینیم. حوزه، سرمایه، زمان و تیم امروز ما متفاوت است، بنابراین تقلید مستقیم معنی ندارد. چیزی که قابل انتقال است روش پرسیدن سؤال است: مسئلهٔ باارزش کدام است؟ کدام ریسک باید زودتر آزمایش شود؟ چه چیزی باید اندازه‌گیری شود؟ چه زمانی باید جهت را عوض کرد؟ و چگونه موفقیت را به سیستم و تیم نسبت دهیم، نه فقط به یک چهره. با این نگاه، مطالعهٔ تاریخ فناوری تبدیل به ابزار طراحی آینده می‌شود.
