خلاصهٔ کتاب: پروژه ققنوس

1 معرفی

پروژه ققنوس توسط جین کیم[1]، کوین بر[2] و جورج اسپفورد[3]، سه نفر از رهبران فکری جنبش DevOps نوشته شده و در چند سال گذشته بسیار محبوب گشته است. این کتاب در قالب یک رمان به رشتهٔ تحریر درآمده که باعث می‌شود خواندن آن بسیار سرگرم‌کننده‌تر از خواندن بسیاری از کتاب‌های حرفه‌ای در این زمینه باشد.

پروژهٔ ققنوس با پیونددادن موضوعات میان‌رشته‌ای مختلف، راهی جذاب برای ظهور توانایی فناوری اطلاعات در کمک به رشد کسب‌وکارها به خواننده نشان می‌دهد. کتاب در رساندن این مفهوم بسیار عالی عمل کرده است و مفاهیم مختلفی را از زمینه‌های متفاوت به‌صورت منسجم، ترکیب می‌نماید. پروژهٔ ققنوس همچنین راهی سرگرم‌کننده برای یادگیری نحوهٔ بهبود فرایند کسب‌وکار و تحول فرهنگی در شرکت‌های بر پایهٔ فناوری اطلاعات است.

نوبودن این کتاب در بیان این ایده‌ها برای نخستین بار نیست. این ایده‌ها دهه‌ها قبل بیان شده و در عمل کارایی خود را در مسیر تولید در کارخانجات، رهبری، فرهنگ ایمنی، امنیت، عملیات فناوری اطلاعات و مهندسی نرم‌افزار نشان داده بودند؛ بااین‌حال هیچ‌وقت اینقدر هنرمندانه به هم پیوند داده نشده بودند.

دلیل محبوبیت این کتاب این است که با استفاده از مفاهیم آن می‌توان به هر سازمان مبنی‌بر فناوری اطلاعات کمک کرد تا با حفظ کیفیت، سرعت عملکرد خود را بسیار افزایش دهد. دست‌یابی به این مهم بسیار سخت بوده ولی دارای مزایای تجاری عظیمی خواهد بود. همچنین سبب ایجاد فرهنگی خواهد شد که بیشتر ما آرزوی داشتن آن را در هر سازمانی داریم.

2 خلاصهٔ داستان

روایت کتاب حول شخصیت یک مدیر IT به نام بیل پالمر[4] می‌چرخد که کارمند یک شرکت قدیمی تولیدکنندهٔ قطعات خودرو به نام Parts Unlimited است. داستان از این قرار است که شکست فاجعه‌بار دیگری در بخش فناوری اطلاعات شرکت باعث اخراج غیررسمی مدیران مافوق سابق بیل شده و وی ناگهان به سِمَت معاونت فناوری اطلاعات[5] سوق داده می‌شود. بیل سابقه خوبی در به‌نتیجه‌رساندن کارها به‌کمک استفادهٔ عملی از روال‌ها و هدایت عالی یک گروه کوچک از پرسنل را دارد. استیو مسترز[6]، مدیر عامل Parts Unlimited از بیل می‌خواهد تا به هرج‌ومرج در دپارتمان ITپایان دهد. باتوجه‌به افت قیمت سهام شرکت، تیتراخبارشدن شکست‌های شرکت و نمایش توانایی رقبا در نوآوری زودبه‌زودتر و کسب مشتریان بیشتر، وضعیت برای بیل بسیار وخیم به نظر می‌رسد. وی با اکراه این چالش را قبول می‌کند تا به نجات شرکت کمک کند.

طیف گسترده‌ای از شخصیت‌ها در این داستان وجود دارند که به‌احتمال‌زیاد خواننده را به یاد همکارانی – و یا حتی خودش – می‌اندازد که وضعیت کاری مشابهی دارند. تیم مدیریتی بیل از وز[7] و پتی[8] تشکیل شده است. وز مدیر پرانرژی سیستم‌های توزیع‌شده بوده و پتی[9] که بسیار در اجرای فرایندها جدی است، مدیر سرویس خدمات IT می باشد. همچنین چند مدیر ارشد در شرکت دارای قدرت می‌باشند و بیل آرام‌آرام درمی‌یابد که باید برای درک و پاسخ به نیاز آن‌ها سخت کار کند. شخصیت دیگر داستان برنت[10]، مهندس عملیات فوق‌العاده‌ای است که به‌دلیل نبوغ و دانش عمیقش پیرامون IT، در حیاتی‌ترین فرایندهای IT شرکت نقش اساسی دارد.

مشکلاتی که این شخصیت‌ها در طول داستان به آن برمی‌خورند، حتی آشناتر از تیپ این شخصیت‌هاست. درست مانند دنیای واقعی، ساختار سازمانی ضعیف، بدهی فنی و سیستم‌های به‌شدت به‌هم‌وابسته و درهم‌تنیده، بسیاری از این مشکلات را ایجاد می‌کنند. و باز هم درست مانند دنیای واقعی، خلاصی از این مشکلات، چالش‌برانگیز است؛ زیرا نیاز به سطح بالایی از خلاقیت، پشتکار و همکاری دارد.

دراین‌میان یکی از شخصیت‌های محوری داستان، دکتر اریک رید[11]، یکی از اعضای هیئت مدیره Parts Unlimitedاست که کاراکتری عجیب‌وغریب و تاثیرگذار دارد. با مربی‌گری بیل و دیگر همکارانش توسط اریک، به‌تدریج آشکار می‌گردد که وی دارای دانش عمیقی از IT و مهندسی سیستم‌ها است. در لحظات کلیدی، اریک مفاهیم جدیدی را معرفی می‌کند که بیل را قادر می‌سازد از آن‌ها در تلاش‌های خود برای جلوگیری از سقوط به‌ظاهر اجتناب‌ناپذیر شرکت استفاده کند.

این رمان، بسیار خواندنی است؛ بنابراین روال تعریف ادامهٔ داستان را در اینجا متوقف کرده و درعوض به مفاهیم زیربنایی کتاب خواهیم پرداخت.

3 مفاهیم

کتاب پروژهٔ ققنوس، مقدمهٔ فوق‌العاده‌ای برای چندین مفهوم کلیدی است. برای درک عمیق این مفاهیم، پیشنهاد می‌شود که متن کامل کتاب و مخصوصاً مطالب اضافی انتهای کتاب را خودتان مطالعه کنید و این متن را بیشتر به‌عنوان یک مرجع برای آشنایی اولیه با این مفاهیم در نظر بگیرید.

1-3 کارهای چهارگانه

اریک با بردن بیل به یک بازدید، شروع به معرفی چهار نوع کار IT می‌کند. بیل سه نوع اول را به‌نسبت سریع درک می‌کند ولی درک نوع چهارم برایش کاری دشوار است؛ تا‌این‌که ماهیت مشکل‌زای نوع چهارم در جریان تغییر عادت‌های کاری تیم، خود را نشان می‌دهد.

نوع اول کار، پروژه‌های کسب‌وکاری هستند. این نوع کارها، فرایندهای کسب‌وکار می‌باشند که معمولاً شامل ایجاد ویژگی‌های جدید با هدف ارائهٔ قابلیت یا افزایش کارایی موردنیاز مشتریانند. کارهای نوع اول توسط رهبران کسب‌وکار به پیش رانده می‌شوند و می‌توانند به‌عنوان پروژه‌هایی در شرکت تعریف شده و اهرم پیش‌راننده آن‌ها معمولاً مدیران داخل‌سازمانی می‌باشند که به نظرشان انجام آن کار، سرمایه‌گذاری مفیدی برای شرکت می‌باشد.

نوع دوم کار، پروژه‌های داخلی بخش IT هستند. این‌ها عمدتاً کارهای روزمرهٔ کوچک‌تری هستند که در طول زمان روی هم انباشته می‌شوند: نگهداری و به‌روزرسانی سیستم‌های موجود، بازنشسته‌کردن فناوری‌های قدیمی، اعمال وصله‌های امنیتی و غیره. این‌قبیل کارها، باعث می‌شوند شرکت سرپا بماند و می‌توانند برنامه‌ریزی شده و در صف کارها قرار بگیرند.

تغییرات، سومین نوع کار می‌باشند که شامل رفع باگ‌ها، به‌روزرسانی نسخه‌ها و هر بهبودی هستند که از دل کارهای نوع اول و دوم ایجاد می‌شوند. این‌ها به‌روزرسانی‌ها و پشتیبانی‌های روتینی هستند که به‌علت وجود برنامه‌ها و زیرساخت‌های مختلف ایجاد می‌شوند.

چهارمین و مضرترین نوع کار، کارهای پیش‌بینی‌نشده می‌باشند. این کارها باعث می‌شوند باقی کارها دوباره انجام شوند؛ زیرا انواع برنامه‌ریزی‌ها را به آشوب کشیده و مختل می‌کنند. کارهای پیش‌بینی‌نشده به‌شدت موذی و نامرئی هستند و انجام سایر تعهدات برنامه‌ریزی‌شده را ناممکن می‌نمایند؛ زیرا باعث کندی یا مسدودشدن روال دیگر انواع کار هستند. به‌دلیل تاثیر مخرب آن‌ها بر سه نوع دیگر، باید به‌هرقیمتی از آن‌ها اجتناب کرد.

هدف از معرفی این کارهای چهارگانه این است که برای بیل روشن شود که قابل‌دیدن‌کردن کارها، اولین گام برای شروع درک درست هر کاری است. اگر جزئیات روال‌های کاری داخل سازمان درک نشوند، نمی‌توان آن‌ها را برنامه‌ریزی کرد و مطمئن بود که اولویت‌های درون و بیرون سازمان به‌درستی دیده می‌شوند.

2-3 کار در جریان[12]

اریک به بیل می‌آموزد که کار در جریان (WIP) یکی از دلایل اصلی مشکلات مزمن در تحویل محصول و کیفیت آن است. عدم کنترل WIPمنجر به مرگ تدریجی و اجتناب‌ناپذیر بهره‌وری در سازمان خواهد شد.

پروژهٔ ققنوس، اثباتی است از این که چگونه مفاهیمی مانند تولید ناب[13] یا سیستم تولید تویوتا بسیار بیشتر از آن چیزی که متخصصین مهندسی نرم‌افزار فکر می‌کنند به توسعهٔ نرم‌افزار ارتباط دارد. درحال‌حاضر نسلی از مهندسین نرم‌افزار این ایده‌ها را پذیرفته‌اند و از نظر بهره‌وری و کیفیت، دستاوردهای قابل‌توجهی داشته‌اند. بسیاری از متدولوژی‌های توسعه نرم‌افزار چابک مانند اسکرام نیز این مفاهیم را در دل خود جا داده‌اند.

داشتن WIP به تمرکز یا عدم وجود آن خلاصه می‌شود؛ بدین‌معنی‌که به‌جای این که به‌صورت همزمان روی چند موضوع کار کنید، در یک زمان فقط روی یک کار تمرکز کنید و آن را خوب انجام دهید. بدین‌ترتیب اشتباهات کم‌تری اتفاق می‌افتند و بنابراین کارهای کم‌تری باید دوباره انجام شوند. هر اقدامی که باید تکرار شود، اضافه‌کاری تلقی می‌شود؛ زیرا باعث می‌شود کار اول را دور بریزیم. تفکر ناب حول این ایده شکل گرفته است که سازمان‌ها باید دائماً این اضافه‌کاری‌ها را کاهش دهند تا منابع ذخیره‌شده ازاین‌طریق صرف دیگر موضوعات مانند کارامدترکردن فرایندها، بهبود ابزارها و روال‌ها و انجام تست برای خلق ویژگی‌ها یا محصولات جدید شوند.

کتاب پروژهٔ ققنوس فقط لایهٔ رویی تفکر ناب را آشکار می‌کند؛ زیرا تنها اعمال این اقدامات را در توسعه نرم‌افزار نشان می‌دهد.

3-3 بردهای کانبان[14]

درنهایت بیل و همکارانش با ایجاد کانبان برای تیم‌های خود با اثرات WIPبیش‌ازحد مقابله کرده و درنتیجه کارهای خود را قابل‌مشاهده می‌کنند. این موضوع به آن‌ها اجازه می‌دهد که کارهای خود را اولویت‌بندی کرده و به باارزش‌ترین آن‌ها بپردازند. به‌طورخاص، زمان برنت به‌شدت زیر ذره‌بین قرار می‌گیرد تا او بتواند همواره روی کاری با بالاترین اولویت تمرکز کند.

کانبان در زبان ژاپنی به معنای «بیلبورد» است. ایدهٔ اصلی آن، ایجاد یک بورد است که تمام قسمت‌های روال شما به‌ترتیب در ستون‌های آن علامت‌گذاری شده‌اند. هر کار به‌وسیلهٔ یک کارت نشان داده می‌شود که مربوط به شخص یا اشخاص مسئول آن کار می‌باشد. با اتمام یک قسمت از کار، کارت آن، یک ستون جلوتر می‌رود تا هنگامی که به ستون «تکمیل‌شده‌ها» برسد.

مفهوم اصلی کانبان این است که قابل‌مشاهده‌کردن هر کار به تیم اجازه می‌دهد که تصویر کلی مراحل انجام آن کار را در یک نما ببیند؛ بدین‌ترتیب روند پیگیری فرایندها بسیار آسان شده، همکاری بهتری ایجاد و WIP بسیار واضح می‌گردد.

4-3 ده استقرار در روز

با افزایش بهره‌وری و بهبود خط‌لوله توسعه، تیم Parts Unlimited به جایی می‌رسد که می‌تواند بسیار سریع‌تر از بازه‌های سه‌ماهه‌ای که با آن شروع کرده بود، نسخه جدید ارائه کند؛ اگرچه ده نسخه در روز هنوز برای تیم دورازدسترس به نظر می‌رسد. درنهایت، آن‌ها آرام‌آرام متوجه می‌شوند که ارائه نسخه‌های جدید با سرعت بیشتر اما با تغییرات کوچک‌تر، توان عملیاتی شرکت را بیشینه کرده و انعطاف‌پذیری لازم را برای پاسخگویی سریع به درخواست مشتریان عملی می‌سازد.

«ده استقرار در روز» یکی از شعارهای معروف جنبش DevOps است. این شعار به توانایی اعمال تغییرات در تولید، با تواتر چندین بار در روز به‌جای سه‌ماهه، ماهیانه و یا هفتگی اشاره می‌کند. اگرچه قرار نیست سرعت اعمال تغییرات به‌معنای واقعی کلمه این مقدار باشد؛ ولی این شعار نشان‌دهندهٔ امکان رسیدن به یک سرعت رقابتی مناسب است. شرکت‌های یونیکورن مانند آمازون و گوگل، مشهور به انتشار با فرکانس هزاران یا صدهاهزار بار در روز هستند.

یک نکتهٔ ظریف این است که این شعار لزوماً به معنای استقرار واقعی نیست؛ بلکه به معنای توانایی آن می‌باشد. استقرار مداوم ممکن است همواره همراه با ویژگی‌های جدید نباشد؛ اما رفع اشکال یا وصله‌های حیاتی، انواع به‌روزرسانی‌هایی هستند که باید به‌سرعت و بدون ایجاد مشکل برای سایر قسمت‌ها، در سیستم اعمال شوند.

به‌طورکلی، پروژهٔ ققنوس این مفهوم را با ظرافت تمام با نمایش مشکلاتی نشان می‌دهد که در راه رسیدن به چنین اهدافی در تقابل بین تعهد به رسیدن به «ده استقرار در روز» و داشتن پروسهٔ روان برای دست‌یابی به آن بروز می‌کنند.

5-3 نظریه محدودیت‌ها

تا زمانی که بیل شروع به درک نظریهٔ محدودیت‌ها[15]نکرده است، نمی‌تواند سازمان را در جهت درست هدایت کند. این عدم توانایی به این دلیل است که تا وقتی که بسیاری از اقدامات اصلاحی گروه او فقط موقتی هستند - بدون تغییر در نحوه کار سازمان، همان مشکلات دوباره دیریازود رخ خواهند داد.

آن‌ها با اعمال نظریهٔ محدودیت‌ها، تنگناهای واقعی سیستم را شناسایی کرده و شیوه‌ها و فرایندهایی را برای بهبود مستمر جریان کار و اتخاذ رویکردی با استراتژی بهتر معرفی می کنند.

نظریهٔ محدودیت‌ها به فرایند شناسایی و حذف مستمر تنگناها در هر سیستم معین اشاره دارد. برای این کار، باید درک درستی از خود سیستم به دست آورد. این به معنای درک هر مرحله از فرایند است. از آنجا که این مراحل اغلب در ضمیر افراد پنهان شده است، این کار برخلاف ظاهر ساده آن، بسیار دشوار می‌باشد. تا زمانی که این مراحل به‌ترتیب، فهرست، درک و ترسیم نشده باشند، ایجاد یک فرایند تکرارپذیر که ثبات و کیفیت لازم را ایجاد کند، به‌راحتی قابل دستیابی نیست.

معمولاً عملی به نام نقشه‌برداری جریان ارزش[16]، اولین گام در اعمال نظریهٔ محدودیت‌هاست. این دقیقاً همان چیزی است که بیل و همکارانش برای درک جریان کار از آن استفاده کردند. با این نقشه‌برداری، آن‌ها توانستند به اندازهٔ کافی نقاط انسداد سیستم را برطرف سازند و بدین‌ترتیب جریان کار را تسریع کنند.

6-3 استفاده از راه‌های سه‌گانه

اریک بخش زیادی از کتاب را صرف راهنمایی بیل برای درک و به کارگیری راه‌های سه‌گانه می‌کند؛ مدلی که نقطهٔ قوت کتاب پروژهٔ ققنوس است.

به گفته یکی از نویسندگان، راه‌های سه‌گانه عبارتند از:

... اصولی که همهٔ الگوهای DevOps را می‌توان از آن‌ها استخراج کرد، که هم در کتاب «راهنمای DevOps[17]» و هم در کتاب «پروژهٔ ققنوس: رمانی درباره IT، DevOps، و کمک به پیروزی کسب‌وکار شما» استفاده می‌کنیم. ما ادعا می‌کنیم که راه‌های سه‌گانه، ارزش‌ها و فلسفه‌هایی را توصیف می‌کنند که فرایندها، روال‌ها، عملکردهای DevOps و همچنین مراحل اثبات‌شده در طول زمان را چارچوب می‌دهند.

برای درک این مدل تصور کنید هر کاری، از آغازبه‌کار تا تحویل محصول نهایی، به عنوان یک‌سری مراحل از چپ به راست جریان دارد. این «کار» به‌معنای تحویل یک ارزش به مشتریان می‌باشد. مفهوم «ارزش» نیز موارد مختلفی را در بر می‌گیرد: می‌تواند یک برنامه، یک سرویس یا یک محصول فیزیکی باشد - اساساً، هر چیزی که مشتری آن را مفید قلمداد کند. این جریان ازچپ‌به‌راست، به عنوان جریان ارزش نامیده می‌شود.

راه‌های سه‌گانه روشی است برای بیشینه‌کردن ارزش تحویلی از طریق بهینه‌سازی فرایند رساندن ارزش به مشتری، به‌دست‌آوردن بینش سریع‌تر و عمیق‌تر با قراردادن مکانیسم‌های نظارتی، و بهبود و خلق ارزش‌های جدید از طریق آزمایش.

راه‌های سه‌گانه را می‌توان به‌این‌صورت بیان کرد:

1. راه اول - به طور مداوم راه‌هایی برای بهبود تحویل پیدا کرده و اجرا کنید. این مترادف با مفهوم کایزن[18]است.

2. راه دوم - به‌سرعت بازخورد دریافت کنید و به‌گونه‌ای کار کنید که اگر در ابتدا بازخوردهایی درباره مشکلات بزرگ دارید، پس از مدتی و با حل آن‌ها به بازخوردهایی درباره مشکلات کوچک‌تر و کوچک‌تر برسید تا درنهایت به وضعیت دریافت بازخوردهای مشکلات درمورد کیفیت محصول دست یابید.

3. راه سوم - از کارایی ناشی از راه اول و بدون‌باگ‌بودن منتج از راه دوم استفاده کنید تا جهت خلق دستاوردهای کیفی، برای هر چیزی دست به آزمایش فوری آن بزنید.

ایدهٔ اصلی این است که با پیروی از راه‌های سه‌گانه، شرکت شما به‌مراتب از رقبا پیشی گرفته و با خلق ارزش برای مشتریان، سهم بیشتری از بازار را به خود اختصاص خواهد داد.

4 نتیجه‌گیری

درهم‌تنیدگی و تحت‌یک‌مدل‌ذهنی‌درآوردن چنین ایده‌هایی برای اولین بار در کتاب پروژهٔ ققنوس انجام گرفت. این مدل توضیح می‌دهد که این ایده‌ها هر کدام چه هدفی دارند و چگونه به هم مربوطند. قبل از نگارش این کتاب، ایده‌های مطرح‌شده در آن وجود داشتند ولی هیچ‌وقت به‌صورتی یک‌جا بیان نشده بودند که چنین جذابیتی داشته باشند.

به‌علاوه کتاب به‌گونه‌ای نوشته شده است که تمام شخصیت‌ها، موقعیت‌ها و انتخاب‌ها برای خواننده آشنا به نظر برسد. این نحوهٔ نوشتن باعث می‌شود خواننده بتواند ارتباط عمیقی با آموزه‌های کتاب برقرار کند؛ زیرا قصهٔ کتاب، یک داستان ساده نیست؛ بلکه یک درام است که با روایت نحوهٔ کار گروهی شخصیت‌ها برای فرار از پرتگاه سقوط، خواننده را وارد یک رابطه احساسی و حس همدردی با آن‌ها می‌کند.

در مجموع، کتاب پروژهٔ ققنوس یک مقدمهٔ عالی برای مفاهیم DevOps است. این کتاب می‌تواند به هر فرد حرفه‌ای درگیر در جنبه‌های مختلف فناوری اطلاعات کمک کند که بفهمد یک سازمان مبتنی بر فناوری اطلاعات چگونه باید کار کند و تصویر کلی‌تری از آن را ببیند.

[1] Gene Kim

[2] Kevin Behr

[3] George Spafford

[4] Bill Palmer

[5] VP of IT

[6] Steve Masters

[7] Wes

[8] Patty

[9] Patty

[10] Brent

[11] Dr Eric Reid

[12] Work in Process (WIP)

[13] Lean manufacturing

[14] Kanban Boards

[15] The Theory of Constraints (TOC)

[16] Value-Stream Mapping

[17] DevOps Handbook

[18] 改善