فصل ۳۰ — دوشنبه، ۳ نوامبر

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

«بله؟» جواب می‌دهد.

«Bill است،» می‌گویم. «به سرنخ‌های بیشتری نیاز دارم که لعنتی قرار است چه کار کنیم…»

«بیرون ساختمان ملاقاتم کن،» می‌گوید و قطع می‌کند.

وقتی بیرون می‌روم، باد تند و شدید است. چند لحظه دور و بر را نگاه می‌کنم، وقتی بوق می‌شنوم. Erik در یک BMW قرمز کروک convertible گران‌قیمت است، با سقف پایین. «بیا تو. عجله کن!»

«ماشین قشنگی است،» می‌گویم و سوار صندلی کنار می‌شوم.

«ممنون،» می‌گوید. «دوستم اصرار کرد تا وقتی در شهرم این را قرض بگیرم.»

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

«برمی‌گردیم MRP-8،» می‌گوید.

وقتی می‌خواهم سقف convertible را بالا ببرد، به من نگاه می‌کند و می‌گوید: «فکر می‌کردم ex-Marine وجود ندارد. شاید شماها را نرم‌تر از زمان من کرده‌اند.»

«تو هم در ارتش بودی؟» می‌پرسم و سعی می‌کنم دندان‌های به هم خورده‌ام را پنهان کنم.

می‌خندد. «بیش از بیست سال.»

«به‌عنوان افسر بازنشسته شدی، فکر می‌کنم؟» پرسیدم.

«Major، Special Forces، ارتش آمریکا،» جواب می‌دهد و به من نگاه می‌کند. امیدوارم چشمش را از جاده بردارد، با این سرعتی که می‌رویم.

در عوض ادامه می‌دهد: «همان شاخهٔ Steve، اما او به‌عنوان افسر پیوست. من مثل تو به‌عنوان سرباز ساده پیوستم.»

بیشتر فاش نمی‌کند، اما همین کافی است تا دوران نظامی‌اش را بفهمم. واضح بود NCO ارشد، مثل خیلی‌هایی که هر روز باید با آن‌ها سر و کله می‌زدم؛ حالا لحن و وقار آشنا را می‌شناسم. حتماً به‌عنوان یکی از آن افراد نادر با پتانسیل بالا توسط بالادستی‌ها شناسایی شده، روی آینده‌اش سرمایه‌گذاری کرده‌اند، به دانشگاه فرستاده و Officer Candidate School، بعد دوباره به صف‌ها برگشته به‌عنوان قدیمی‌ترین second lieutenant، احتمالاً ده سال بزرگ‌تر از بقیه.

برای رد شدن از آن مسیر باید آدم خاصی باشی.

در زمان رکورد به کارخانه می‌رسیم و حالا روی catwalk ایستاده‌ایم. سخنرانی‌ای را شروع می‌کند که انتظارش را داشتم. «کارخانهٔ تولید یک سامانه است. مواد خام از یک طرف شروع می‌شوند و میلیون چیز باید درست پیش برود تا در موعد به‌عنوان کالای نهایی از طرف دیگر خارج شود. همه با هم کار می‌کنند. اگر هر work center با work center دیگر در جنگ باشد، مخصوصاً اگر Manufacturing با Engineering در جنگ باشد، هر اینچ پیشرفت مبارزه خواهد بود.»

Erik به من برمی‌گردد و اشاره می‌کند: «باید فکر کردن مثل سرپرست work center را رها کنی. بزرگ‌تر فکر کن، مثل مدیر کارخانه. یا بهتر، مثل کسی که این کارخانه و همهٔ فرایندهایی که به آن وابسته است طراحی کرده. به کل جریان کار نگاه می‌کنند، محدودیت‌ها را پیدا می‌کنند و از هر فناوری و دانش فرایندی که دارند استفاده می‌کنند تا کار مؤثر و کارآمد انجام شود. inner-Allspaw خود را مهار می‌کنند.»

می‌خواهم بپرسم Allspaw یعنی چه، وقتی دست تکان می‌دهد و سؤالم را رد می‌کند. «در تولید معیاری داریم به نام takt time، cycle time لازم برای هم‌گام ماندن با تقاضای مشتری. اگر هر عملیات در جریان کار بیشتر از takt time طول بکشد، نمی‌توانی با تقاضای مشتری هم‌گام بمانی.»

«پس وقتی دور می‌دوزی و فریاد می‌زنی: اوه نه! محیط‌های Phoenix آماده نیست! کمک، کمک! اوه نه! نمی‌توانیم deploy کنیم چون کسی دوباره محیط‌های Phoenix را خراب کرد!» با صدای زیر و دخترانه می‌گوید، «یعنی cycle time بعضی عملیات حیاتی در حوزهٔ مسئولیتت بیشتر از takt time است. به همین دلیل نمی‌توانی با تقاضای مشتری هم‌گام بمانی.

«به‌عنوان بخشی از Second Way باید حلقهٔ بازخوردی بسازی که تا اولین بخش‌های تعریف محصول، طراحی و توسعه برگردد،» می‌گوید. «با گفت‌وگوهایی که با Dick داری، شاید حتی بتوانی زودتر در فرایند بروی.»

به کف اشاره می‌کند و می‌گوید: «پایین را نگاه کن، ردیف طولانی تجهیزات بین نوار نارنجی روی کف. آن خط بعضی از سودآورترین اقلام ما را می‌سازد. اما سرنوشت این‌طور خواست که آن جریان کار دو عملیات با طولانی‌ترین setup time و process time را شامل شود: اعمال پوشش پودر رنگ و پخت در کورهٔ heat treat.»

سر بلند می‌کند، دست‌ها را باز می‌کند. «در گذشته cycle time آن دو عملیات آن‌قدر از takt time بزرگ‌تر بود که هرگز نمی‌توانستیم با تقاضای مشتری هم‌گام بمانیم. زندگی چطور می‌تواند این‌قدر unfair باشد؟ سودآورترین اقلام هر دو محدودیت ما را استفاده می‌کردند: کورهٔ heat treat و غرفه‌های رنگ! چه کار کنیم؟

«مشتریان حتی پول می‌ریختند سرمان، التماس می‌کردند widget بیشتر، اما مجبور بودیم ردشان کنیم. setup time هر job ساعت‌ها یا حتی روزها طول می‌کشید. مجبور بودیم batch size عظیم استفاده کنیم تا تقاضا را برآورده کنیم. سینی‌های بزرگ برای رنگ داشتیم و هر بار تا جایی که ممکن بود واحد می‌پختیم. می‌دانستیم باید batch size را کم کنیم تا throughput بهتر شود، اما همه می‌گفتند نمی‌شود.»

«راه حل Toyota برای این مشکل افسانه‌ای است،» می‌گوید. «در دههٔ ۱۹۵۰ فرایند stamping کاپوت داشتند که change-over time تقریباً سه روز بود. جابه‌جایی قالب‌های عظیم و سنگین چند تنی لازم بود. مثل ما، setup time آن‌قدر طولانی بود که batch size بزرگ لازم داشتند و نمی‌توانستند با یک ماشین stamping هم‌زمان چند مدل مختلف بسازند. نمی‌توانی یک کاپوت Prius بسازی و بعد یک کاپوت Camry اگر change-over سه روز طول بکشد، درست است؟

«چه کردند؟» به‌صورت بلاغی می‌پرسد. «همهٔ قدم‌های change-over را دقیق نگاه کردند و سری بهبود و آماده‌سازی گذاشتند که change-over time را به زیر ده دقیقه رساند. و البته از آنجاست که اصطلاح افسانه‌ای single-minute exchange of die می‌آید.

«همهٔ آثار Ohno، Spear و Rother را مطالعه کردیم. می‌دانستیم باید batch size را کم کنیم، اما با قالب stamping کاپوت سر و کار نداشتیم. با رنگ و پخت سر و کار داشتیم،» ادامه می‌دهد. «بعد از هفته‌ها طوفان فکری، بررسی و آزمایش با Engineering، ایدهٔ دیوانه‌وار داشتیم: شاید بتوانیم رنگ و پخت را در یک ماشین انجام دهیم. کوره‌ای دست‌ساز ساختیم که پودر رنگ را هم روی قطعات اعمال می‌کرد، قطعات با زنجیر و چرخ‌دنده‌ای که از دوچرخه برداشته بودیم کشیده می‌شدند.

«چهار work center را در یکی ادغام کردیم، بیش از سی قدم دستی و مستعد خطا حذف شد، چرخهٔ کار کاملاً خودکار شد، single-piece flow حاصل شد و همهٔ آن setup time از بین رفت. Throughput از سقف رد شد.

«مزایا عظیم بود،» با افتخار می‌گوید. «اول، وقتی نقص پیدا می‌شد فوراً درست می‌کردیم و لازم نبود همهٔ قطعات batch را scrap کنیم. دوم، WIP پایین آمد چون هر work center هرگز overproduce نمی‌کرد تا فقط در صف work center بعد بماند. اما مهم‌ترین مزیت این بود که lead time سفارش از یک ماه به کمتر از یک هفته رسید. هرچه و هرچندتا مشتری می‌خواست می‌ساختیم و تحویل می‌دادیم و هرگز انبار پر از آشغالی نداشتیم که باید با fire-sale price liquidate کنیم.

«حالا نوبت توست،» با لحن سخت می‌گوید و انگشتش را به سینه‌ام می‌زند. «باید بفهمی changeover time را چطور کم کنی و cycle time استقرار سریع‌تر را ممکن کنی.

«فکر می‌کنم هدفت باید…» مکث می‌کند. «ده deploy در روز باشد. چرا نه؟»

آرواره‌ام می‌افتد. «غیرممکن است.»

«واقعاً؟» بی‌تفاوت می‌گوید. «بگذار یک داستان بگویم. سال ۲۰۰۹ عضو هیئت‌مدیره یک شرکت فناوری بودم؛ یکی از engineerها به Velocity Conference رفت و مثل دیوانه برگشت، پر از ایده‌های خطرناک و غیرممکن. presentation John Allspaw و همکارش Paul Hammond را دید که دنیا را وارونه کرد. Allspaw و Hammond گروه‌های IT Operations و Engineering در Flickr را اداره می‌کردند. به‌جای جنگ مثل گربه و سگ، دربارهٔ کار با هم برای انجام روتین ده deploy در روز حرف زدند! در دنیایی که بیشتر سازمان‌های IT عمدتاً استقرار فصلی یا سالانه داشتند. تصور کن. deploy با نرخی هزار برابر سریع‌تر از state of the art قبلی.

«بگذار بگویم،» ادامه می‌دهد، «همه فکر می‌کردیم آن engineer عقلش را از دست داده. اما فهمیدم شیوه‌هایی که Allspaw و Hammond تبلیغ می‌کردند پیامد اجتناب‌ناپذیر اعمال Three Ways روی value stream IT است. کاملاً نحوهٔ مدیریت IT ما را عوض کرد و شرکتمان را نجات داد.

«چطور انجام دادند؟» با بهت می‌پرسم.

«سؤال خوبی است،» جواب می‌دهد. «Allspaw به ما آموخت Dev و Ops با هم، همراه QA و کسب‌وکار، یک super-tribe هستند که کارهای شگفت‌انگیز می‌کنند. همچنین می‌دانستند تا وقتی کد در production نباشد، ارزش واقعی تولید نمی‌شود، چون فقط WIP گیرکرده در سامانه است. مدام batch size را کم کرد، جریان feature سریع را ممکن کرد. بخشی از این کار با اطمینان از در دسترس بودن محیط‌ها وقتی لازم بود بود. build و deployment را خودکار کرد، با این درک که infrastructure مثل کد application که Development ship می‌کند قابل treat as code است. این به او اجازه داد فرایند یک‌مرحله‌ای ساخت محیط و deploy بسازد، دقیقاً مثل راهی که ما برای رنگ و پخت یک‌مرحله‌ای پیدا کردیم.

«پس حالا می‌دانیم Allspaw و Hammond آن‌قدر دیوانه نبودند. Jez Humble و Dave Farley مستقل به همان نتیجه رسیدند و بعد شیوه‌ها و اصولی که استقرار چندبار در روز را ممکن می‌کند در کتاب بنیادین Continuous Delivery codify کردند. Eric Ries بعد نشان داد این قابلیت چطور می‌تواند به کسب‌وکار در یادگیری و پیروزی در کار Lean Startup کمک کند.»

وقتی Erik حرف می‌زند از همیشه پرانرژی‌تر است. سر تکان می‌دهد و با لحن سخت به من نگاه می‌کند.

«قدم بعدی‌ات باید حالا واضح باشد، grasshopper. برای هم‌گام ماندن با تقاضای مشتری، که شامل comradeهای upstream در Development هم می‌شود،» می‌گوید، «باید آنچه Humble و Farley deployment pipeline نامیدند بسازی. کل value stream از code check-in تا production. این هنر نیست. این production است. باید همه‌چیز در version control باشد. همه‌چیز. نه فقط کد، بلکه هرچه برای ساخت محیط لازم است. بعد باید کل فرایند ساخت محیط را خودکار کنی. deployment pipeline لازم داری که بتوانی محیط‌های test و production بسازی و کد را در آن‌ها deploy کنی، کاملاً on-demand. این‌طور setup time را کم و خطا را حذف می‌کنی تا بالاخره با هر نرخ تغییری که Development tempo را تعیین می‌کند هم‌گام بمانی.»

«صبر کن،» می‌گویم. «دقیقاً چه چیزی را باید خودکار کنم؟»

Erik با لحن سخت به من نگاه می‌کند. «برو از Brent بپرس. او را به تیم جدید assign کن و مطمئن شو حواسش پرت نشود. حالا بیش از همیشه، تا build process خودکار نشود، او bottleneck توست. چیزهایی که در سرش است را در build procedureها encode کن. آدم‌ها را از business استقرار خارج کن. بفهم چطور به ده deploy در روز برسی.»

نمی‌توانم بدبینی‌ام را رها کنم. «ده deploy در روز؟ مطمئنم کسی این را نمی‌خواهد. آیا هدفی بالاتر از نیاز کسب‌وکار تعیین نمی‌کنی؟»

Erik آه می‌کشد و چشم می‌غلتاند. «تمرکز را از نرخ هدف استقرار بردار. چابکی کسب‌وکار فقط سرعت خام نیست. دربارهٔ این است چقدر خوب تغییرات بازار را detect و respond می‌کنی و می‌توانی ریسک‌های بزرگ‌تر و محاسبه‌شده برداری. دربارهٔ آزمایش مداوم است، مثل کاری که Scott Cook در Intuit کرد، جایی که در اوج فصل اظهارنامهٔ مالیاتی بیش از چهل experiment انجام دادند تا بفهمند چطور نرخ تبدیل مشتری را maximize کنند. در اوج فصل اظهارنامهٔ مالیاتی!

«اگر نتوانی در time to market و چابکی از رقبا experiment بیشتر کنی و ببری، غرق می‌شوی. featureها همیشه قمارند. اگر شانس داشته باشی، ده درصد مزایای مطلوب را می‌گیرند. پس هرچه سریع‌تر featureها را به بازار برسانی و تست کنی، بهتر. ضمناً سرمایه را هم سریع‌تر به کسب‌وکار برمی‌گردانی، یعنی کسب‌وکار هم زودتر پول درمی‌آورد.

«Steve کل بقایش را روی توانایی تو در اجرا و deploy سریع‌تر قابلیت‌ها شرط بسته. پس برو با Chris کار کن بفهمید در هر مرحله از فرایند agile development نه فقط کد shippable داشته باشید، بلکه محیط کاری که بتواند در آن deploy شود!»

«باشد، باشد،» می‌گویم. «اما چرا مرا تا اینجا در سرمای آوردی؟ توضیح روی whiteboard کافی نبود؟»

«فکر می‌کنی IT Operations نسبت به manufacturing علم موشک است. چه مزخرف مطلقی،» با تحقیر می‌گوید. «از جایی که من نشسته‌ام، مردم این ساختمان خیلی خلاق‌تر و شجاع‌تر از هرچه تا حالا از شما IT guyها دیده‌ام بوده‌اند.»