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

ساعت ۱۲:۱۳ بعدازظهر است و وارد جلسهٔ آغاز تیم SWAT می‌شوم. موهایم هنوز خیس است و پیراهنم از سوار شدن در convertible Erik خیس شده. Chris دارد حرف می‌زند: «—و Steve به این تیم کوچک اجازه داده قابلیت promotion را تحویل دهد و هر کاری لازم است بکند تا روی فصل خرید تعطیلات اثر مثبت بگذارد.»

Chris به من برمی‌گردد و به ته اتاق اشاره می‌کند. «برای شروع ناهار برای همه سفارش دادم. برو و—چه اتفاقی برایت افتاده؟»

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

Brent جواب می‌دهد: «دوباره توضیح بده چرا اینجا هستم؟»

«برای همین اینجاییم،» Wes با جدیت می‌گوید. «تو هم به اندازهٔ ما می‌دانی. یکی از اعضای بالقوهٔ هیئت‌مدیره اصرار کرده بخشی از این تیم باشی. راستش، آن‌قدر دفعات کافی درست گفته که بهش اعتماد دارم، حتی اگر اصلاً نمی‌فهمم چرا.»

Patty وسط حرف می‌زند. «خب، چند سرنخ هم داد. گفت مشکلاتی که باید روی آن‌ها تمرکز کنیم، فرایند deployment و نحوهٔ ساخت محیط‌هاست. به نظر می‌رسد فکر می‌کند اساساً چیزی را اشتباه انجام می‌دهیم، چون از هر deployment پروژه Phoenix این همه هرج‌ومرج درست می‌شود.»

در حالی که ساندویچم را باز می‌کنم می‌گویم: «تازه از جلسه با او برگشتم. یک عالمه چیز نشانم داد و توضیح داد چطور در Toyota single-minute exchanges of die انجام می‌دهند. فکر می‌کند باید توانایی ده deploy در روز را بسازیم. نه فقط اصرار دارد ممکن است، بلکه می‌گوید از چرخه‌های deploy قابلیت‌هایی که کسب‌وکار نیاز دارد پشتیبانی می‌کند، نه فقط برای بقا، بلکه برای پیروزی در بازار.»

شگفت‌آور این است که Chris تندتر از همه حرف می‌زند. «چی؟ اصلاً چرا باید ده deploy در روز داشته باشیم؟ sprint intervalهای ما سه هفته‌اند. چیزی نداریم که ده بار در روز deploy کنیم!»

Patty سر تکان می‌دهد. «مطمئنی؟ رفع باگ چطور؟ بهبود performance وقتی سایت مثل آنچه در دو launch بزرگ اخیر اتفاق افتاد قفل می‌کند چطور؟ دوست نداری این نوع تغییرات را به‌صورت روتین در production انجام دهی، بدون اینکه برای emergency change مجبور شوی همهٔ قوانین را بشکنی؟»

Chris چند لحظه فکر می‌کند و بعد جواب می‌دهد: «جالب است. معمولاً آن نوع fixها را patch یا minor release می‌نامم. اما حق با توست—آن‌ها هم deployment هستند. عالی می‌شد اگر fixها را سریع‌تر rollout می‌کردیم، اما بابا، ده deploy در روز؟»

با فکر کردن به حرف Erik اضافه می‌کنم: «چطور Marketing را قادر کنیم خودشان تغییرات content یا business rule بدهند، یا آزمایش و A/B split testing سریع‌تر برای دیدن کدام offer بهتر جواب می‌دهد؟»

Wes هر دو دستش را روی میز می‌گذارد. «حرفم را یادتان باشد. نمی‌شود. اینجا با قوانین فیزیک طرفیم. فراموش کنید الان چقدر طول می‌کشد، که بیش از یک هفته آماده‌سازی و بیش از هشت ساعت برای خود deployment لازم دارد! bitها را فقط به این سرعت می‌توانی روی دیسک بنویسی.»

دقیقاً همین را قبل از بازدید کارخانه با Erik می‌گفتم.

با جدیت می‌گویم: «ببینید، شاید حق با شما باشد، اما یک لحظه با من همراه شوید: در کل فرایند end-to-end deployment چند مرحله داریم؟ بیست مرحله، دویست، یا دو هزار؟»

Wes لحظه‌ای سرش را می‌خاراند و می‌گوید: «تو چی فکر می‌کنی Brent؟ فکر می‌کردم حدود صد مرحله…»

«واقعاً؟» Brent جواب می‌دهد. «فکر می‌کردم بیشتر شبیه بیست مرحله است.»

William وسط حرف می‌زند: «مطمئن نیستم از کجا شمارش می‌کنید، اما اگر از جایی شروع کنیم که Development کد را commit می‌کند و آن را «release candidate» label می‌زند، احتمالاً می‌توانم صد مرحله پیدا کنم، حتی قبل از اینکه به عملیات IT بدهیم.»

اوه‌اوه.

Wes قطع می‌کند: «نه، نه، نه. Bill گفت «مراحل deployment». لطفاً قوطی… را باز نکن—»

وقتی Wes حرف می‌زند، به Erik فکر می‌کنم که از من خواست مثل مدیر کارخانه فکر کنم نه مثل سرپرست work center. ناگهان می‌فهمم احتمالاً منظورش این بود که باید مرزهای بخش Development و عملیات IT را در بر بگیرم.

«هر دو درست می‌گویید،» می‌گویم و Wes و William را قطع می‌کنم. «William، لطفاً همهٔ مراحل را روی whiteboard بنویسی؟ پیشنهاد می‌کنم از «code committed» شروع کنی و تا تحویل به گروه ما ادامه بدهی.»

سر تکان می‌دهد، به whiteboard می‌رود و شروع می‌کند جعبه می‌کشد و همزمان مراحل را توضیح می‌دهد. در ده دقیقهٔ بعد ثابت می‌کند احتمالاً بیش از صد مرحله هست، از جمله تست‌های خودکار در محیط Dev، ساخت محیط QA مطابق Dev، deploy کد در آن، اجرای همهٔ تست‌ها، deploy و migrate به staging تازه‌ای که با QA یکی است، load testing، و بالاخره تحویل به عملیات IT.

وقتی William تمام می‌کند، سی جعبه روی تخته است.

به Wes نگاه می‌کنم و می‌بینم به‌جای عصبانیت، عمیق در فکر است، چانه را می‌مالد و به نمودار نگاه می‌کند.

به Brent و Wes اشاره می‌کنم یکی از آن‌ها جایی که William رها کرده ادامه دهد.

Brent بلند می‌شود و جعبه می‌کشد برای packaging کد جهت deployment؛ آماده‌سازی instanceهای سرور جدید؛ بارگذاری و پیکربندی سیستم‌عامل، پایگاه داده و applicationها؛ همهٔ تغییرات شبکه، firewall و load balancer؛ و بعد تست برای اطمینان از موفقیت deployment.

به کل نمودار نگاه می‌کنم که شگفت‌آور شبیه کف کارخانه است. هر کدام از این مراحل مثل یک work center است، هر کدام با machine، man، method و measure متفاوت. کار IT احتمالاً خیلی پیچیده‌تر از کار تولید است. نه‌تنها کار نامرئی است و ردیابی سخت‌تر می‌شود، بلکه چیزهای بیشتری می‌تواند اشتباه برود.

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

حتی یک اشتباه کوچک می‌تواند همه‌چیز را down کند. حتماً یعنی حتی بیشتر از تولید به rigor، discipline و planning نیاز داریم.

نمی‌توانم صبر کنم این را به Erik بگویم.

با درک اهمیت و عظمت چالش پیش‌رو، به whiteboard می‌روم و ماژیک قرمز را برمی‌دارم. می‌گویم: «روی هر مرحله‌ای که در launchهای قبلی مشکل داشتیم یک ستارهٔ قرمز بزرگ می‌گذارم.»

شروع می‌کنم روی whiteboard علامت می‌زنم و توضیح می‌دهم: «چون محیط QA تازه‌ای در دسترس نبود، از نسخهٔ قدیمی استفاده کردیم؛ به‌خاطر همهٔ test failureها، تغییرات کد و محیط در QA دادیم که هرگز به Dev یا Production برنگشت؛ و چون هرگز همهٔ محیط‌ها را sync نکردیم، دفعهٔ بعد هم همان مشکلات را داشتیم.»

ردی از ستاره‌های قرمز می‌گذارم و وارد جعبه‌های Brent می‌شوم. «چون دستورالعمل deployment درست نداشتیم، پنج بار طول کشید تا packaging و deployment script درست شود. این در production منفجر شد چون محیط اشتباه ساخته شده بود، که قبلاً گفته‌ام.»

حتی اگر عمدی نبود، وقتی تمام می‌کنم تقریباً همهٔ جعبه‌های William و Brent ستارهٔ قرمز کنارشان دارند.

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

Patty می‌گوید: «می‌دانی، این یاد چیزی می‌افتد که بچه‌های کف کارخانه مدام استفاده می‌کنند. اگر یکی از آن‌ها وارد می‌شد، حدس می‌زنم فکر می‌کردند داریم «value stream map» می‌سازیم. اشکالی دارد چند عنصر اضافه کنم؟»

ماژیک whiteboard را به او می‌دهم و می‌نشینم.

برای هر جعبه می‌پرسد هر عملیات معمولاً چقدر طول می‌کشد و عدد را بالای جعبه می‌نویسد. بعد می‌پرسد آیا معمولاً در این مرحله کار باید منتظر بماند و قبل از جعبه مثلث می‌کشد که work in process را نشان می‌دهد.

لعنتی. برای Patty شباهت deploymentهای ما به خط کارخانه سؤال آکادمیک نیست. با deployment ما مثل یک خط کارخانه واقعی رفتار می‌کند!

از ابزارها و تکنیک‌های Lean که مردم manufacturing برای مستندسازی و بهبود فرایندها استفاده می‌کنند بهره می‌برد.

ناگهان می‌فهمم Erik وقتی از «deployment pipeline» حرف زد چه می‌گفت. حتی اگر کارمان را مثل کارخانه نبینی، باز هم value stream است.

اصلاح می‌کنم. value stream ماست، و مطمئنم لبهٔ فهمیدن چطور جریان کار را از آن به‌شکل چشمگیر افزایش دهیم هستیم.

بعد از اینکه Patty مدت زمان مراحل را ثبت کرد، جعبه‌ها را با labelهای کوتاه دوباره می‌کشد. روی whiteboard جداگانه دو bullet می‌نویسد: «environments» و «deployment».

به آنچه نوشته اشاره می‌کند و می‌گوید: «با فرایند فعلی، دو مسئله مدام تکرار می‌شود: در هر مرحله از deployment، محیط‌ها وقتی لازم داریم در دسترس نیستند، و حتی وقتی هستند، rework زیادی لازم است تا همه با هم sync شوند. درسته؟»

Wes خرخر می‌کند: «جایزه‌ای برای گفتن چیز واضح نیست، اما حق با توست.»

ادامه می‌دهد: «منبع دیگر واضح rework و setup time طولانی در فرایند packaging کد است، جایی که عملیات IT آنچه Development در version control check in می‌کند می‌گیرد و deployment package می‌سازد. اگرچه Chris و تیمش تا جایی که می‌توانند کد و configuration را document می‌کنند، همیشه چیزی از قلم می‌افتد که فقط وقتی کد بعد از deployment در محیط run نمی‌شود exposed می‌شود. درسته؟»

این بار Wes فوراً جواب نمی‌دهد. Brent زودتر می‌گوید: «زدی تو خال. William احتمالاً با این مشکلات ارتباط دارد: دستورالعمل release هرگز به‌روز نیست، پس همیشه scramble می‌کنیم، سعی می‌کنیم futz کنیم، مجبور می‌شویم installer script را بازنویسی کنیم و بارها نصب کنیم…»

«آره،» William با تأکید سر تکان می‌دهد.

«پیشنهاد می‌کنم روی آن دو حوزه تمرکز کنیم،» می‌گوید، به تخته نگاه می‌کند و دوباره می‌نشیند. «ایده‌ای دارید؟»

Brent می‌گوید: «شاید William و من با هم deployment run book بسازیم تا همهٔ درس‌های اشتباهاتمان را capture کنیم؟»

سر تکان می‌دهم و به ایده‌های همه گوش می‌دهم، اما هیچ‌کدام مثل breakthrough بزرگی که لازم داریم به نظر نمی‌رسند. Erik کاهش setup time برای فرایند door stamping را توضیح داده بود. به نظر می‌رسید مهم است. اما چرا؟

«اینکه هر گروه محیطی را patchwork بسازد واضحاً کار نمی‌کند. هر کاری بکنیم باید قدم بزرگی به سمت هدف «ده deploy در روز» باشد،» می‌گویم. «یعنی automation زیادی لازم داریم. Brent، برای اینکه بتوانیم فرایند مشترک ساخت محیط داشته باشیم، طوری که همزمان Dev، QA و Production را بسازیم و sync نگه داریم، چه لازم است؟»

«ایدهٔ جالبی است،» Brent می‌گوید و به تخته نگاه می‌کند. بلند می‌شود و سه جعبه با label «Dev»، «QA» و «Production» می‌کشد. زیرشان جعبهٔ دیگری با label «Build Procedure» و فلش به هر سه جعبه بالا.

«این واقعاً brilliant است Bill،» می‌گوید. «اگر build procedure مشترک داشتیم و همه با این ابزارها محیط می‌ساختند، developerها واقعاً در محیطی کد می‌نوشتند که حداقل شبیه Production بود. همین به‌تنهایی بهبود عظیم بود.»

درپوش ماژیک را از دهانش درمی‌آورد. «برای ساخت محیط Phoenix از bunchی script که نوشته‌ایم استفاده می‌کنیم. با کمی documentation و cleanup، شرط می‌بندم در چند روز چیزی usable سرهم کنیم.»

به Chris برمی‌گردم و می‌گویم: «امیدوارکننده به نظر می‌رسد. اگر محیط‌ها را standardize کنیم و Development، QA و عملیات IT روزانه از آن‌ها استفاده کنند، اکثر varianceای که این همه grief در deployment ایجاد می‌کند حذف می‌شود.»

Chris هیجان‌زده به نظر می‌رسد. «Brent، اگر برای تو و بقیه مشکلی نیست، دوست دارم تو را به sprintهای تیم دعوت کنم تا ساخت محیط را هرچه زودتر در فرایند development ادغام کنیم. الان بیشتر روی داشتن کد deployable در پایان پروژه تمرکز می‌کنیم. پیشنهاد می‌کنم آن requirement را عوض کنیم. در هر sprint interval سه‌هفته‌ای، نه‌تنها باید کد deployable داشته باشیم بلکه دقیقاً همان محیطی که کد در آن deploy می‌شود، و آن را هم در version control check in کنیم.»

Brent از پیشنهاد لبخند پهنی می‌زند. قبل از اینکه Wes جواب دهد می‌گویم: «کاملاً موافقم. اما قبل از ادامه، می‌توانیم مسئلهٔ دیگری که Patty highlight کرد را بررسی کنیم؟ حتی اگر پیشنهاد Chris را بپذیریم، هنوز مسئلهٔ deployment scriptها هست. اگر چوب جادو داشتیم، هر وقت محیط QA تازه‌ای داریم، چطور باید کد را deploy کنیم؟ هر بار deploy، مدام کد، script و خدا می‌داند چه چیز دیگری بین گروه‌ها ping-pong می‌شود.»

Patty وسط حرف می‌زند. «در کف manufacturing، هر وقت کار به عقب برود، rework است. وقتی این اتفاق می‌افتد، مطمئن باش documentation و جریان اطلاعات pretty poor است، یعنی چیزی reproducible نیست و با سریع‌تر رفتن بدتر می‌شود. به این «non-value-add» activity یا «waste» می‌گویند.»

به whiteboard اول با همهٔ جعبه‌ها نگاه می‌کند و می‌گوید: «اگر فرایند را redesign کنیم، باید افراد درست از اول درگیر باشند. مثل گروه manufacturing engineering که مطمئن می‌شود همهٔ partها برای manufacturing بهینه طراحی شده‌اند و خطوط تولید برای partها بهینه‌اند، ideally در single-piece flow.»

سر تکان می‌دهم و به شباهت آنچه Patty پیشنهاد می‌دهد با آنچه Erik امروز گفته بود لبخند می‌زنم.

به William و Brent برمی‌گردم و می‌گویم: «باشد بچه‌ها، چوب جادو دست شماست. جلوی خط هستید. بگویید خط تولید را چطور design می‌کنید که کار هرگز به عقب نرود و جریان سریع و کارآمد جلو برود.»

وقتی هر دو نگاه خالی به من می‌اندازند، با کمی عصبانیت می‌گویم: «چوب جادو دارید. استفاده کنید!»

«چوب جادو چقدر بزرگ است؟» William می‌پرسد.

همان چیزی را که به Maggie گفتم تکرار می‌کنم: «چوب جادوی خیلی قدرتمندی است. هر کاری می‌تواند بکند.»

William به whiteboard می‌رود و به جعبه‌ای به نام «code commit» اشاره می‌کند. «اگر این چوب جادو را تکان بدهم، این مرحله را عوض می‌کنم. به‌جای گرفتن source code یا compiled code از Dev از طریق source control، می‌خواهم کد packaged که آمادهٔ deploy است.»

«و می‌دانی،» ادامه می‌دهد، «این را آن‌قدر می‌خواهم که خوشحال volunteer می‌کنم مسئولیت package creation را بگیرم. دقیقاً می‌دانم چه کسی assign می‌کنم. او مسئول Dev handoff خواهد بود. وقتی کد «ready to test» label می‌خورد، packaged code را generate و commit می‌کنیم که automated deployment به محیط QA را trigger کند. و شاید بعداً Production هم.»

«واو. واقعاً این کار را می‌کنی؟» Wes می‌پرسد. «عالی می‌شود. انجامش بدهیم—مگر Brent واقعاً بخواهد packaging را نگه دارد؟»

«شوخی می‌کنی؟» Brent می‌پرسد و می‌خندد. «برای بقیهٔ سال برای هر کسی که این کار را بکند drink می‌خرم! عاشق این ایده‌ام. و می‌خواهم در ساخت deployment toolهای جدید کمک کنم. گفتم bunchی tool نوشته‌ام که می‌توانیم starting point بگیریم.»

انرژی و هیجان اتاق را حس می‌کنم. شگفت‌زده‌ام چقدر سریع از باور به اینکه هدف «ده deploy در روز» fantasy delusional است به اینکه فکر می‌کنیم چقدر نزدیک می‌شویم رفتیم.

ناگهان Patty سر بلند می‌کند و می‌گوید: «صبر کنید. این کل ماژول Phoenix با customer purchase data سروکار دارد که باید محافظت شود. نباید کسی از تیم John هم بخشی از این effort باشد؟»

همه به یکدیگر نگاه می‌کنیم و موافقیم که باید درگیر باشد.

و باز هم تحت‌تأثیر قرار می‌گیرم که چقدر به‌عنوان سازمان عوض شده‌ایم.