Yak Shaving (پَشم‌تراشی گاومیش) به صورت خلاصه به مجموعه‌ دومینوواری از فعالیت‌های ناخواسته گفته می‌شود که ممکن است برای انجام بسیاری از کارهای روزانه خود درگیر آن‌ها شده و پس از صرف زمان و هزینه زیادی، متوجه شویم که بدون کسب نتیجه‌ای مناسب، نه تنها از هدف اولیه خود بسیار دور شده‌ایم، بلکه به انجام فعالیت کاملاً نامرتبطی مثل تراشیدن پشم‌های یک گاومیش مشغول هستیم (لازم به ذکر است که معنی لغوی Yak گاومیش است.) سَندروم یاک شیوینگ به دلیل ارتباط بسیار زیاد اجزای زندگی امروزی با یکدیگر، چالشی است که بسیاری از افراد به صورت روزانه با آن مواجه می‌شوند که در این مقاله قصد داریم در قالب مثال‌هایی ملموس، مفهوم آن را بیشتر توضیح دهیم.

از آبیاری درختان باغچه تا تراشیدن پشم گاومیش!

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

مسلما این کار به سادگی ممکن نیست زیرا قسمتی از این بالش به دلایلی نامعلوم آسیب دیده و پیش از تحویل، حتما باید ترمیم شود و از آنجایی که این بالش با پشم گاومیش پُر شده بود، شما مجبور می‌شوید به این در و آن در زده تا یک Yak (گاومیش) یافته و مقداری پشم گاومیش برای این کار تهیه کنید؛ این در حالی است که روز به پایان رسیده و شما به جای آبیاری درختان، مشغول تراشیدن پشم گاومیش هستید!

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

شیوع سندرم Yak Shaving در میان دولوپرها

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

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

لذا تصمیم می‌گیریم وارد اکانت گیت‌هاب خود شویم اما از آنجا که مدت زمان زیادی است وارد گیت‌هاب نشده‌ایم، رمزعبور آن را فراموش کرده‌ایم؛ لذا از قابلیت فراموشی رمزعبور استفاده می‌کنیم و در این میان متوجه می‌شویم که پسورد ایمیل‌مان را نیز در اولین پنجشنبه ماه می و روز جهانی پسورد تغییر داده‌ایم و از آنجا که سعی کرده‌ بودیم پسوردی دشوار و غیرقابل‌هَک انتخاب کنیم، آن را نیز به یاد نداریم!

خبر ناامیدوارکننده اینکه پاسخ هیچ‌گونه از پرسش‌های امنیتی را نیز به یاد نداریم، اما از آنجا که اَکانت ما نسخه پریمیوم از یک سرویس ایمیل است، می‌توانیم با ارائه شماره کارت اعتباری، پسورد را ریست نماییم اما یادمان می‌آید که چون در زمان پرداخت کارت اعتباری نداشتیم و یکی از دوست‌تان‌مان این کار را برایمان انجام داده بود، پس تصمیم می‌گیریم با وی تماس بگیریم و ادامه ماجرا ... (جالب است بدانیم که در فضای استارتاپی نیز این سندرم بسیار شایع است. پرداختن به فعالیت‌هایی که باعث می‌شود نسخه اولیه محصول پس از صرف هزینه‌های زیاد بسیار دیرتر از زمان متناسب با بازار به مخاطب ارائه شده و دیگر فرصتی برای ایجاد تغییرات اساسی در آن وجود نداشته باشد.)

گاهی پشم‌تراشی به یک «ضرورت» تبدیل می‌شود!

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

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

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

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

دلیل اصلی ایجاد این سندروم چیست؟

شاید از خودتان بپرسید: «چرا یک تغییر کوچک در کد، باید چنین دومینوی وحشتناکی راه بیندازد؟» واقعیت این است که در دنیای مهندسی نرم‌افزار، این سندروم از سه منبع اصلی تغذیه می‌کند:

1. کمال‌گرایی افراطی یا حواس‌پرتی‌های ذهنی

گاهی مشکل اصلی نه در خود کد، بلکه در ذهن ماست که نمی‌تواند همزمان تعداد زیادی مسئله را مدیریت کند. وقتی با یک چالش سخت در کار اصلی روبه‌رو می‌شویم، ذهن‌مان برای فرار از فشار شناختی به سراغ کارهای کوچک‌تر و ساده‌تر می‌رود؛ مثل مرتب کردن وسواسی فایل‌ها یا اصلاح جزئیات کم‌اهمیت. انجام این کارها حس «کاذبِ» مفید بودن می‌دهد، اما در واقع ما را از هدف اصلی دور می‌کند و انرژی زیادی می‌گیرد. این همان نوع یاک تراشی است که می‌تواند کار اصلی را لابه‌لای پشم‌های گاومیش گم کند (مثل همان ضرب‌المثل معروف: آفتابه‌لگن هفت دست، شام و ناهار هیچی!).

2. بدهی فنی (Technical Debt)

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

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

3. کوپلینگ بالا (High Coupling)

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

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

برای درمان این سندروم چه می‌توان کرد؟

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

۱. مدل ذهنی «سه پرسش کلیدی»

هر وقت حس کردید درگیر کاری شده‌اید که مستقیما به هدف اصلی مربوط نیست، یک لحظه مکث کنید و از خودتان سه سؤال ساده بپرسید:

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

پاسخ این پرسش‌ها معمولا روشن می‌کند که آیا مسیر را ادامه بدهید یا بهتر است توقف کنید و دوباره اولویت‌ها را بررسی کنید.

۲. تکنیک جعبه زمانی (Time-boxing)

روش دیگری که می‌تواند کمک کند، محدود کردن زمان برای کارهاست. فرض کنید برای پیشبرد یک تسک، پیش‌نیازی به وجود آمده ؛ یک تایمر کوتاه (مثلا 2 ساعت) تنظیم کنید و سعی کنید در این بازه فقط همان کار را انجام دهید. اگر وقت تمام شد و هنوز درگیر بودید، دست نگه دارید! با تیم خود مشورت کنید و در نهایت وضعیت را دوباره ارزیابی کنید.

۳. هنر استفاده از راه‌حل‌های موقت هوشمندانه

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

۴. تبدیل حواس‌پرتی به بک‌لاگ شخصی

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

جمع‌بندی

همواره سعی کنید تا هدف اصلی با ساده‌ترین و کم‌هزینه‌ترین حالت ممکن (البته با کیفیت مناسب) و در سریع‌ترین زمان محتمل محقق شود (در ارتباط با اولین مثال فرضی، شاید آبیاری درختان با سطل نیز می‌توانست راه‌کار مناسبی باشد، زیرا در آن صورت هدف نهایی نیز به خوبی انجام شده بود.) همچنین به خاطر داشته باشید که پیش‌نیازهای غیرضروری را بدون تردید حذف کنید و سَبک‌ترین حالت ممکن را انتخاب کنید به طوری که Eric Ries، کارآفرین آمریکایی و نویسنده کتاب The Lean Startup، می‌گوید:

بزرگ فکر کن اما کوچک شروع کن!

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

نظر شما درباره این سندرم چیست و آیا تجربه‌ای از این سندروم داشته‌اید؟ نظرات، دیدگاه‌ها و تجربیات خود را با دیگر کاربران سکان آکادمی به اشتراک بگذارید.

Yak Shaving: سَندرمی که برخی دولوپرها به آن دچار می‌شوند