بهزاد مرادی

High Bus Factor: عاملی که باعث می‌شود شرکت‌های نرم‌افزاری از جانب دولوپرها آسیب ببینند

بهزاد مرادی مدرس، کپی‌رایتر و دولوپر

این محتوا بدون نظارت تیم سکان آکادمی تولید شده و صرفاً نظرات شخصی بهزاد مرادی می‌باشد.

عنوان این مقاله برگرفته از کتابی تحت عنوان 20 Patterns to Watch for in Your Engineering Team است که به صورت رایگان عرضه شده است. بحث اصلی نگارندهٔ این بخش از کتاب آن است که اگر توسعه‌دهنده یا توسعه‌دهندگان تیم فنی شما با اتوبوس تصادف کنند، تیم با چه چالش‌هایی مواجه خواهد شد؟

گرچه این موضوع کمی اغراق‌آمیز به نظر می‌رسد، اما اگر بخواهیم این موضوع را کمی به شرایط واقعی نزدیک‌تر گردانیم می‌باید سؤالاتی از این دست از خود،‌ به عنوان رهبر یک تیم نرم‌افزاری، بپرسیم:

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

تجربهٔ شخصی‌ام می‌گوید که هرچه تیم‌های توسعهٔ محصول کوچک‌تر باشند، با توجه به اینکه امکان جذب نیروهای زیاد هزینه‌بر خواهد بود، امکان High Bus Factor بیشتر می‌گردد و بالتبع وابستگی به دولوپر/دولوپرهای خاصی پررنگ‌تر شده و اینجاست که چالش‌های کار شروع می‌شوند. از طرفی، در تیم‌های بزرگ‌تر معمولاً بیش از یک توسعه‌دهنده روی بخش خاصی از نرم‌افزار کد می‌زنند و اینجاست که شاهد Low Bus Factor هستیم؛‌ به عبارتی، اگر هم بنا بر هر دلیلی یکی از اتفاق فوق رخ دهد (دولوپر تیم را ترک کند.) مشکل چندانی به وجود نخواهد آمد چرا که نیروی جایگزین از قبل برای کاور کردن نقش نیرویی که تیم را ترک کرده تربیت شده است.

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

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

ایدهٔ خود را در سکان‌پلاس بنویسید!

لیست نظرات
کاربر میهمان
دیدگاه شما چیست؟
کاربر میهمان
حسین قربانی
حسین قربانی
۱۳۹۸/۰۱/۱۸
آقای مرادی عزیز
سلام
1- هر چند این یادداشت شما کوتاه و مختصر بود، اما باید اعتراف کنم که خیلی خیلی نکته مهمی را عنوان کردید و واقعاً مفید بود. مخصوصاً برای کار مدیریتی.
2- تجربه شخصی بنده در این مورد از دید مدیریت نیست. تجربه بنده از دید، کسی است که همکار فرد کلیدی است. فرد کلیدی ناگهان از مجموعه جدا شد و کارهای آن فرد روی اعضای تیم سر شکن شد. شوک نبود یک فرد نه تنها برای مدیریت، بلکه برای همکاران هم یک موضوع جدی است. اشاره درست شما به مستند سازی و تمییز نوشتن کد، از این لحاظ خیلی خوب بود.
3- اصطلاح اتوبوسی که به کار بردید، من را یاد سقوط هواپیمای تیم منچستر یونایتد انداخت. تیمی که وضعیت خوبی هم در لیگ انگلستان و هم در اروپا داشت و در مونیخ دچار سانحه هوایی شد و هشت نفر از مهم‌ترین مهره‌های کلیدی خودشان را از دست دادند. آن‌قدر اوضاع وخیم بود که هیات مدیره منچستر یونایتد تصمیم گرفته بود کل باشگاه را منحل کند. اما خُب با وجود آکادمی بازیکنان این اتفاق نیفتاد.داستان بازگشت منچستر یونایتد از این بحران آموزنده است. این اتفاق تاکید دارد که حادثه هیچ وقت خبر نمی‌کند. حتی برای شما دولوپر عزیز.😂
4- در سرمایه‌گذاری هم اصطلاحی داریم که می‌گوید، همه تخم مرغها را در یک سبد نگذارید. اگر همه سرمایه معنوی و مادی یک کسب‌وکار به یک فرد وابسته باشد. مصداق همین ضرب‌المثل است و نتیجه به احتمال زیاد به شکست ختم خواهد شد.
موفق باشید
محمدامین عطائی
محمدامین عطائیبرنامه نویس جاوااسکریپت
۱۳۹۸/۰۱/۱۵
این میتونه یک مقاله ی جدی و در بخش اصلی وبلاگ سکان باشه به نظرم.. چون خیلی مهمه