⌛ اصول نرمافزارهای انترپرایز یا Enterprise Software Principles
⌛ اصول نرمافزارهای انترپرایز یا Enterprise Software Principles
💡 بررسی از دریچهی آسیبشناسی شکستها
بخش صفر: مقدمه و آسیبشناسی
این موضوع اینقدر گسترده است و بستهبهسازمان متفاوته که کتابهای متنوعی از منظرهای مختلف بهش پرداختن، از مطالب تئوری محض، تا تجربیات افراد در سازمانهای بزرگ و انترپرایزها. با این حال بد نیست به برخی اصول و تفاوتهای اثرگذار روی ساختار و رویهها بپردازیم. و باید این رو مد نظر قرار بدیم که هر سازمان، مختصات خاص خودش رو داره، و مثل همیشه، نسخه جهانشمول برای همه وجود نداره!
✏️ این مطلب، مقدمهای از یک بحث مفصل است که در صورت اقبال دوستان، در بخشهای بعدی گامبهگام تکمیل میشه.
قبل از پرداختن به الزامات و اصول نرمافزار در انترپرایزها خوبه تا به «برخی» تمایزهای محیط انترپرایز با شرکت کوچک (چند ده یا چند صد نفره) و استارتاپها بپردازیم. البته تاکید میکنم که تمایزها رو به صورت تدریجی و به فراخور موضوع عرض خواهم کرد، و این تعداد محدود، همه ماجرا نیست.
۱: فرق نرمافزار انترپرایز با یک استارتاپ چیه (۱)؟
استارتاپها رو به تغییرات سریع در بازه زمان کوتاه میشناسیم. و اگر یک استارتاپ طی ۵ سال ۲ نسل از نرمافزار خودش رو توسعه بده، چیز دور از ذهنی نیست، در حالیکه یک انترپرایز شاید طی یک دهه، فقط یک نسل از یک سیستم رو تجربه کنه و به صورت گاهی مرتب، گاهی دیربهدیر، تغییراتی رو روی همون نسل اعمال میکنه، پس یک گروه از از تفاوتها رو میشه به «عمر مفید نرمافزار» و «سرعت و تناوب تغییرات» نسبت داد.
همچنین تیم و ساختار فنی و محصول، گاهی برای سالها ثابت میمونه، گاهی بعد از مدتها ثبات، به یکباره تغییرات اساسی میکنه (ادغام/تجزیه تیم، دامین، یا حتی سازمان، برونسپاری یا حتی آفشور توسعه و نگهداری یا...)
پس ماهیت اصلی نرمافزارهای انترپرایز، عمر طولانی، پیچیدگی سازمانی و هزینهی نگهداشت است؛ و نه صرفاً تکنولوژی.
💡حالا با همین چند پیشفرض، به نظرتون میشه بدون «ساختار و سازماندهی تولید» سراغ تولید رفت؟
بله میشه رفت! ولی نتیجهاش میشه صدها «سامانه» با باگهای تمومنشدنی، فاصله داشتن با زمانه و نیازهای روز در حوزههای سازمانی، بانکی و دانشگاهی و... سازمانهایی که فاقد ساختار مشخص برای توسعه، مالکیت یا نگهداری نرمافزار هستند؛ چه به عنوان توسعهدهنده، چه بهرهبردار، چه مالک محصول؛ در عمل محصولاتی با ویژگیهای زیر تولید میکنند:
- نرخ Technical debt بالا (هزینه نگهداری ۳-۵ برابر توسعه اولیه)
- فقدان documentation قابل استفاده
- وابستگی به افراد خاص (bus factor پایین)
- دشواری یا عدم امکانپذیری scale یا refactor
- زمان onboarding طولانی، در عین تسلط کم دولوپر جدید روی سیستم
- نارضایتی و ناکارآمدی رو به رشد طی حتی زمان کوتاه
و این الگو رو اینقدر طی دو دهه مشاوره، تدریس و همکاری با صنایع مختلف، در مقیاسها و ساختارهای متنوع دیدهام که میتونم با اطمینان به عنوان نتایج تقریبا حتمی فقدان ساختار و سازمان توسعه نرمافزار بیان کنم. (صنایع: از نفت، گاز، مخابرات، آیتی، بانک، خودرو، تا پخش، تولید و... یا ساختارهای متنوع مثل دولتی، خصولتی، خصوصی، استارتاپ، رانتی و...، یا در مقیاسهای مختلف از چند دههزار نفر نیرو تا کمتر از انگشتان دو دست).
شما برای سازمان متوسط یا بزرگتر، اگر آخرین تکنولوژی و زبان و معماری رو هم به کار بگیرید، تمام مفاهیم مایکروسرویس و آخرین نسخه کوبرنتیز رو استفاده کنید؛ ولی اگر زیرساخت و ساختار توسعه نرمافزار رو به عنوان پیمانکار محصول یا سازمان بهرهبردار محصول نداشته باشید، طی مدت کوتاهی درگیر چرخه تولید بدهی فنی و ساختاری خواهید شد. این یعنی چیزی که نگهداری و توسعهاش همیشه با کلی سوال و مشقت و ابهام روبرو است، بهروزرسانیاش معمولا با تاخیر و کلی دردسر انجام میشه، توسعهدهنده هر بار برای درک قوانین بیزنسی توی کد باید خطبهخط بخونه تا بفهمه چیبه چیه و دچار کلافگی و خستگی میشه. آپدیت یه کتابخونه حتی اگر با هزار مشکل انجام بشه، هیچ چشمانداز شفافی وجود نخواهد داشت که کجای نرمافزار شاید فردا صبح کار نکنه و خطا بده! یا حتی چقدر محتمله خطا رو کسی از تیم محصول یا فنی ببینه! چون احتمال داره فقط کاربری که به اجبار و از روی نیاز با سیستم تعامل داره، با ایرادها مواجه شه و باز هم چرخهی نارضایتی و تجربه تلخ رقم میخوره!
ادامه (مولفههای موثر بر سازماندهی و توسعه) در بخش ۲