فصل ۲: نقطه عزیمت تحول؛ انتخاب جریان ارزش، درک کار جاری و طراحی سازمان محصول‌محور

یکی از حیاتی‌ترین تصمیمات استراتژیک برای رهبران فناوری، انتخاب اولین جریان ارزش برای شروع تحول دواپس است. اغلب مدیران تصور می‌کنند که پروژه‌های زمین بکر (Greenfield) — سیستم‌های کاملاً جدیدی که بدون میراث کدهای قدیمی از صفر نوشته می‌شوند — تنها بستر مناسب برای دواپس هستند. هرچند پروژه‌های بکر مقاومت کمتری ایجاد می‌کنند، اما ارزش واقعی و اثبات کارایی دواپس زمانی رخ می‌دهد که آن را بر روی سیستم‌های زمین ساخته‌شده یا میراثی (Brownfield) — همان سامانه‌های حیاتی، قدیمی و پر از بدهی فنی که شریان درآمدی سازمان به آن‌ها وابسته است — پیاده کنیم.

علاوه بر این، سازمان‌ها اغلب سرویس‌های خود را به دو دسته سیستم‌های ثبت (Systems of Record) مانند هسته بانکی یا ERP که نیازمند دقت و پایداری مطلق هستند، و سیستم‌های تعامل (Systems of Engagement) مانند اپلیکیشن‌های موبایل و وب‌سایت‌های فروشگاهی که نیازمند تغییرات سریع هستند، تقسیم می‌کنند (مدلی که گارتنر آن را IT دووجهی یا Bimodal IT می‌نامد). نویسندگان کتاب به شدت با جداسازی دائمی این دو مخالف‌اند؛ چرا که طبق قانون محدودیت‌ها، سرعت کل زنجیره ارزش به کندترین حلقه آن وابسته است و بهبود سیستم‌های تعامل بدون مدرن‌سازی سیستم‌های ثبت، خیلی زود به بن‌بست می‌رسد.

پیش از نوشتن حتی یک خط اسکریپت اتوماسیون، تیم‌ها باید درک مشترکی از نحوه جاری شدن کار در سازمان پیدا کنند. ابزار اصلی برای این کار، برگزاری کارگاه ترسیم نقشه جریان ارزش (Value Stream Mapping) با حضور نمایندگان تمام تیم‌های درگیر (محصول، توسعه، تست، امنیت، شبکه و عملیات) است. هدف این نیست که صدها صفحه مستندات فرآیندی بنویسیم، بلکه هدف شناسایی بزرگ‌ترین گلوگاه‌هایی است که در آن‌ها کار برای هفته‌ها متوقف می‌ماند و شاخص درصد کامل و دقیق بودن (%C/A) سقوط می‌کند.

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

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

برای غلبه بر پیامدهای مخرب قانون کانوی، کتاب «مانور معکوس کانوی» (Inverse Conway Maneuver) را پیشنهاد می‌دهد: تغییر ساختار تیم‌ها از آرایش وظیفه‌محور و هزینه‌محور (Functional-Oriented) به آرایش بازارمحور و محصول‌محور (Market-Oriented). در ساختار وظیفه‌محور، متخصصان بر اساس مهارت (تیم DBA، تیم QA، تیم لینوکس) دسته‌بندی می‌شوند و مدیران بر کاهش هزینه هر واحد تمرکز دارند. اما در ساختار بازارمحور، تیم‌های چندتخصصی و مستقل حول یک محصول یا سرویس شکل می‌گیرند و مالکیت کامل چرخه حیات آن سرویس را از طراحی تا اجرا در محیط عملیاتی بر عهده دارند.

هیچ تحول سازمانی بدون اختصاص زمان مشخص برای بهسازی زیرساخت‌ها و بازآرایی کد (Refactoring) دوام نمی‌آورد. اگر ۱۰۰ درصد ظرفیت مهندسان صرف توسعه فیچرهای تجاری جدید شود، بدهی فنی به صورت تصاعدی رشد کرده و به زودی سرعت تحویل فیچرها را به صفر می‌رساند (همان پدیده‌ای که در HP رخ داد). بنابراین رهبران فناوری و محصول باید به یک توافق استراتژیک دست یابند که در آن حداقل ۲۰ درصد از ظرفیت تمام چرخه‌های کاری (Sprints) تیم‌های توسعه و عملیات، به طور غیرقابل مذاکره به کاهش بدهی فنی، خودکارسازی تست‌ها و بهبود معماری اختصاص یابد.