هزینههای تولید و نگهداریِ نرمافزارِ شما میتواند به شکل چشمگیری کاهش یابد!
تولید نرمافزارِ باکیفیت، فرایندی پُرهزینه و گرانقیمت است. اما میتوان با روشهایی اصولی و بهینه آن را مدیریت کرد تا با کمترین هزینه بیشترین ارزش را خلق کنید. میتوان اثربخشتر و کارامدتر کار کرد، تا هزینههای نگهداری نهتنها بیشتر از تولید نشود، که تا حد خوبی کاهش یابد.
- رضایت کارکنان افزایش مییابد
- سریعتر به بازار میرسید
- برند شما به کیفیت شناخته میشود
علیرقم هزینهی بالای تولید و نگهداری، نرخِ شکست پروژههای نرمافزاری همچنان بالاست!
از گذشته تا امروز نرخِ شکستِ پروژههای نرمافزاری بالا بوده است. اگرچه این نرخ در سالهای اخیر کمی بهتر شده است، اما همچنان ۶۵-۸۰ درصد از پروژههای صنعتِ IT نمیتوانند به اهدافِ مقررِ خود برسند؛ یا دیرتر از موعد اجرایی میشوند و یا هزینهها بیش از پیشبینیِ اولیه میشوند و یا بطور کلی لغو میشوند.
نه تنها هزینهی تولیدِ نرمافزار بسیار بالاست، بلکه از لحاظِ ریسک (احتمالِ شکست) قابلِ مقایسه با دیگر صنایع نیست. این واقعیت، برخلافِ ظاهرِ صنعتِ نرمافزار و باورِ عموم است. عدم درکِ درست تفاوتِ بین ابزار و محصولِ نرمافزاری به این اشتباه دامن میزند. نگاهِ سادهانگارانه به نرمافزار عاقبتی جز شکست یا تولیدِ محصولی پُرایراد و پرهزینه ندارد. عاقبتی که در کشورِ ما غریب نیست.
عواملِ شکستِ پروژههای نرمافزاری
عواملِ زیادی وجود دارد، از عدمِ شفافیت در نیازمندیها بگیرید تا مسائلِ فرهنگیِ یک سازمان. برخی از این عوامل پُررنگتر و برخی کماثرتر هستند. از طرفی برای برخی از عوامل پُراثرتر، موانعِ کمتری برای برطرف کردن آنها وجود دارد. به عنوان مثال «داشتنِ معماریِ مناسب» شدنیتر و کممانعتر از تغییرِ فرهنگِ سازمانی است، ولی تاثیرِ بسزایی در موفقیت و نگهداریِ محصولِ نرمافزاری دارد.
- مسائلِ مرتبط با برنامهریزی و درکِ نیازمندی
- چالشهای فنی نظیر طراحیِ ضعیف و عدمِ دانشِ کافی
- رهبریِ ضعیف در هدایتِ پروژه
- مسائلِ مرتبط با تضمینِ کیفیت و امنیت
- چالشهای زیرساختی و عملیاتی
- مسائلِ مرتبط با فرهنگ سازمانی
جهانِ اول در تکاپوی یافتن راههایی بهینهتر است تا از هزینهی تولیدِ نرمافزار بکاهد و ریسکِ آن را کمتر کند.
کشورهای پیشرفته برای کاهشِ هزینههای تولید و نگهداریِ نرمافزار و همچنین کمکردنِ ریسک آن، بطورِ جدی در پِی یافتن راههایی برای اثربخشیِ بیشتر هستند. سالانه بنیادهای تحقیقاتی نظیر DORA بواسطهی پژوهشگرانِ مجرب به طُرق مختلف تیمهای موفق و ناموفق نرمافزاری را بررسی و تحلیل میکنند تا متوجه شوند که چگونه میشود بدونِ کاستی از کیفیت، از هزینهها کم کرد و محصول را مطابقِ با نیازمندی واقعی سریعتر به بازار رساند.
کمکردنِ هزینه به روشِ افزایشِ بهرهوری و کاهشِ احتمالِ شکست. نه زدن از کیفیت!
کمتر کردنِ هزینه یعنی در کمترین زمانِ ممکن، محصولی باکیفیت تولید کنید و از هزینههای نگهداری آن کم کنید. خیلی از اوقات هزینههای نگهداریِ نرمافزار بیش از هزینهی تولیدِ اولیه میشود.
با تمرکز بر اتوماسیونِ فرایندهای تولید و استقرار، ایجادِ کد ماژولار و قابلِ نگهداری و همچنین استفاده از روشهای درستِ توسعه، میتوان هزینههای تولید و نگهداری را کاهش داد.
رسالتِ جنبشِ دواپس کمکردنِ هزینهها و ریسکِ پروژه است
استفاده از روشهای اصولیِ فنی و مدیریتی، منطبق با نیاز و ساختارِ سازمان، کلیدِ کمکردن هزینههای تولید و نگهداری است. دقت بفرمایید با ارزشترین داراییِ یک تیمِ نرمافزاری، توسعهدهندگان آن است. روشهای جدید و مهندسی شده، رضایتِ توسعهدهندگان را نیز به همراه دارد و سازمان را به محلی جذاب برای کار کردن تبدیل میکنند و از burn out نیروهای فنی جلوگیری میکند.
الزاماتِ فنیِ توسعهی باکیفیت و مطمئن
همه چیز بحثِ مدیریت و رهبری نیست. در واقع به نظر من، حلقهی گمشدهی متدولوژیهایی نظیرِ اجایل و اسکرام، کمتوجهی به روشهای فنی است که میتوانند سرعت و دقتِ توسعه را بیشتر کنند و چرخهی بازخورد را کوتاه کنند. سریعتر کردن بازخورد یعنی تضمینِ مسیرِ درستِ توسعه. و در مقابل بیتوجهی به آن و فقط تاکید بر سِرمونیهای اجایل و اسکرام، آن آوردهای (outcome) که انتظار میرود را نخواهد داشت. حال فارغ از اینکه برای مدیریتِ پروژه از متدولوژیِ خاصی استفاده شود یا نه، داشتنِ یک زیرساختِ فنیِ خوب، تضمینی برای توسعهی باکیفیت و فنی است. در لیستِ زیر کُدِ باکیفیت لحاظ نشده است و کاملا به روشهای دواپسی اکتفا شده است.
- منطبق با Git Workflow
- اتوماتسازی کامل (End-to-End Automation)
- پشتیبانی از Rollback
- قابلیت Idempotency
- Self-Healing
- Cross-platform Builds
- اجرای تستهای امنیتی (SAST)
- بهروزرسانی دیتابیس (Migrations)
- اجرای تستهای عملکردی
- مانیتورینگ whitebox و blackbox
- google four golden signals
- مدیریت اخطار (alert)
- تمام اتوماتیک، بدون دخالت انسان
- مدیریت تنظیمات (Configuration Management)
- رصد تغییرات و کنترل نسخه
- خودکارسازیِ environment provisioning
- کمکردن خطای انسانی
- سازگاری و تکرارپذیری
- مقیاسپذیری سریع
- بازیابی سریع در مواقع بحرانی
- On-demand self-service
- Broad network access
- Resource pooling
- Rapid elasticity
- Measured service
- C4 Model
- PlantUML
- Doumentation as Code
- تغییرات به شکل Declarative
- ثبتِ همهی تغییرات
- Managed Kubernetes
- Helm Chart
- Docker
- Istio Service Mesh
- Rancher
- Openshift
- SAST
- DAST
- CIS Benchmark
- OWASP
- SonarQube
- Postmortem
الزاماتِ غیرفنی
گرچه الزاماتِ فنی از اهمیت زیادی برخوردار هستند، اما عموما این سطح از بروز بودن فنی در سازمانهایی که فرهنگِ مُولد ندارند بسیار سخت است. فرهنگِ سازمانی نقشِ تعیین کنندهای در موفقیتِ تیمهای نرمافزاری بازی میکند. بقدری که گاها جملهی اشتباهِ «دواپس یعنی فرهنگ» را میشنویم. اگرچه دواپس معادل فرهنگ نیست، اما فرهنگ یکی از ارکانِ اصلیِ آن است.
فرهنگِ سازمانی
رویکردهای متنوعی برای مُدل کردن یا الگوسازیِ «فرهنگ سازمانی» وجود دارد. بهعنوان مثال، فرهنگِ سازمانی را میتوان صرفا «ارزشهایی (values)» دانست که رفتارِ تیمها را میسازند. یا آنکه از جنبههای مختلفتری به آن نگاه کرد. فرهنگِ سازمانی را میتوان با سه سطح در سازمان تعریف کرد: ۱.مفروضاتِ بنیادین، ۲.ارزشها، و ۳.مصنوعات. بحثهایی که در جمعهای دواپسی در خصوص اهمیتِ مقولهی فرهنگِ سازمانی میشود، در سطحِ دوم (ارزشها) است. الگو و مُدلی که برای بیان و تفسیر این سطح من درنظر میگیرم مُدلِ جامعهشناسی بنامِ Ron Westrum است. ایشان در سال ۱۹۸۸ گونهشناسیِ (typology) فرهنگهای سازمانی را در ۳ دسته ایجاد کرد. اول، بیمارگونه (Pathological) (قدرت محور)، دوم، بوروکراتیک (Bureaucratic) (قانون محور) و سوم، مُوَلِد (Generative) (شایستهسالار). وِستروم معتقد بود که فرهنگِ سازمانی، تعیین کنندهی «نحوهی جریان اطلاعات (information flow)» در سازمان است. و سه خصیصه برای «اطلاعاتِ خوب (good information)» معرفی کرد: ۱.ابهامِ پرسشکننده را کامل برطرف میکند. ۲.همواره در دسترس است. ۳.در قالبی است که استفادهکننده میتواند به بهترین نحو از آن استفاده کند.
جریانِ «اطلاعاتِ خوب»، امری حیاتی برای داشتنِ عملکردِ «درست» و «مطمئن» در محیطهای حساس است. محیطهای عملیاتیِ محصولاتِ نرمافزاری یکی از همین محیطهای حساس است که هر تغییری میتواند پیامدهای گسترده (high-consequence) داشته باشند.
بودجهی خطا
به عنوان کسی که مسئولیتِ محیطهای عملیاتی حساس را بهدوش داشتهام، توصیه میکنم که پیش از هرچیز با مدیرانِ سازمان (یا مدیرِ فنی) در خصوصِ بودجهی خطای تیمِ عملیات صحبت کنید و ظرفیتِ تیم را برای خطا مشخص کنید.
یکی از مشکلاتی که در سازمانهای مختلف تجربه کردهام، عدمِ درکِ درستِ محیطِ عملیاتی توسطِ مدیران و توسعهدهندگان است. تیم عملیات نیازمند یک بودجهی خطا است تا بتواند با فراغبال و برنامهریزی شده تغییرات را در محیط عملیاتی اعمال کند. مسئلهی وجود «بودجهی خطا» یک چیز است، پذیرش آنکه سرویس در محیط عملیاتی، پایداری ۱۰۰ درصدی ندارد و عملیات نیازمند زمانی برای اعمال تغییرات و مانورهای عملیاتی است، چیز دیگری است. عموما در پیشفرض ذهنی مدیرانِ سازمانهای ایرانی، بودجهی خطا جایی ندارد و لازم است بواسطهی افرادِ عملیاتی در این خصوص فرهنگسازی شود.
بودجه خطا مقدار مشخصی از خطا یا عدم دسترسی است که برای یک سیستم در یک بازه زمانی مشخص قابلقبول در نظر گرفته میشود. این مفهوم بر اساس توافق سطح خدمات (SLA/SLO) تعریف میشود. اگر مثلاً سطح توافقشده برای در دسترس بودن سیستم ۹۹.۹٪ باشد، بودجه خطا ۰.۱٪ زمان عدم دسترسی در آن بازه زمانی است. البته قابل ذکر است که بودجهی خطا برای نسخهگذاری نیز درنظر گرفته میشود، اما این مقوله راحتتر توسط سازمان پذیرفته میشود تا تغییرات و مانورهای عملیاتی.
رهبری
رهبری در توسعهی نرمافزار نقشِ کلیدی در موفقیتِ پروژهها و تیمها دارد. این نقش فراتر از مدیریتِ پروژه یا کنترلِ وظایف است و بر ایجاد انگیزه، انسجامِ تیمی، و ارائهی چشمانداز برای دستیابی به اهداف تمرکز دارد. یک رهبر خوب میتواند با تعریفِ اهداف روشن و نقشهی راه برای تیم، اعضا را در راستای دستیابی به این اهداف هدایت کند. این چشمانداز باعث میشود تیم بداند چرا کاری انجام میشود. رهبر تیم با ایجاد فرهنگِ شفافیت و برقراریِ ارتباطاتِ مداوم، اطمینان حاصل میکند که همه اعضای تیم اطلاعاتِ کافی و یکسان دارند. رهبر با الهامبخشی و حمایت از تیم، انگیزه آنها را برای مواجهه با چالشها و ادامهی مسیر تقویت میکند. در تیمهای نرمافزاری، تعارضها اجتنابناپذیر هستند. رهبر باید تواناییِ شناسایی و حل تعارضها را داشته باشد و محیطی مثبت برای کارِ تیمی ایجاد کند. یک رهبر موفق به اعضای تیم فرصتِ یادگیری و رشد میدهد. این امر نه تنها باعث بهبود مهارتهای فنی و غیر فنی اعضا میشود، بلکه حسِ مسئولیتپذیری و مشارکتِ آنها را نیز افزایش میدهد. رهبریِ قوی نه تنها به اجرای بهتر پروژههای نرمافزاری کمک میکند، بلکه باعث میشود تیمها با انگیزهتر، کارآمدتر و خلاقتر عمل کنند. رهبرانِ موثر نه تنها مدیرانی خوب هستند، بلکه الهامبخش و حامیِ رشد فردی و گروهی تیم نیز محسوب میشوند.
رهبری امری یادگرفتنی است، ذاتی نیست. وبسایت متمم محل مناسبی برای تقویت مهارتهای نرم، منجمله رهبری است.
اندازهگیریِ بهبودِ عملکردِ تیم نرمافزاری
مهندس یعنی اندازهگیر. یکی از پُرچالشترین اقداماتِ یک تیم مهندسی نرمافزار، اندازهگیریِ کمّی عملکردِ تیمِ نرمافزاری است. پیشنهاد من ۴ متریک متعالیِ DORA میباشد که در بحث اندازهگیریِ عملکرد مطرح است. توضیحاتِ بیشتر در این خصوص خارج حوصله بحث است، برای اطلاعات بیشتر به کتاب Accelerate یا مقالهی من در ویرگول مراجعه کنید.
- متریکِ مدت زمان تحویل - Lead Time
- متریکِ تعدد نسخهگذاری - Deployment Frequency
- متریکِ زمان بازیابی - Mean Time to Restore
- متریکِ نرخ شکست - Change Fail Percentage
بهبودِ تجربهی توسعهدهندگان (DevEx)
تجربهی توسعهدهنده (Developer Experience یا DevEx) به احساسی که توسعهدهندگان نسبت به کارِ خود دارند، طرز فکر آنها و ارزشی که برای کارشان قائل هستند، اشاره دارد. در پژوهشهای انجام شده، بیش از ۲۵ عاملِ اجتماعی-فنی شناسایی شده که بر تجربه توسعهدهنده تأثیر میگذارد. به عنوان مثال، وقفههای مکرر (interruptions)، ضربالاجلهای غیرواقعی، و ابزارهای نامعقول توسعه میتوانند تاثیر بسیار منفی داشته باشند. در مقابل، وظایف مشخص، کدهای سازمانیافته، و فرآیندهای دیپلوی بدون دردسر تجربه مثبتتری ایجاد میکنند.
یک تصور اشتباه رایج این است که تجربه توسعهدهنده (DevEx) بیشتر تحتِ تأثیرِ ابزارها قرار دارد. اما تحقیقات نشان میدهد که عوامل انسانی مانند داشتن اهدافِ روشن برای پروژهها و احساسِ امنیتِ روانی در تیم تأثیرِ قابلتوجهی بر عملکردِ توسعهدهندگان دارند. بهبودِ تجربهی توسعهدهنده نه تنها بهرهوری را افزایش میدهد، بلکه باعث افزایشِ رضایت، تعامل و ماندگاریِ کارکنان نیز میشود.
روشهای مدرن توسعهی نرمافزار چیست؟
مدرن نه به معنای جدید، به معنای آنکه در دنیای مدرن این روشها به عنوان practiceهای مطمئن و آزموده شده پذیرفته شده است. البته که برخی از این روشها عمر نسبتا کوتاهی هم دارند، اما به عنوان یکی از پایههای توسعهی مدرن درنظر گرفته میشوند.
اُپنسورس به معنای مجانی نیست!
در خلاف ظاهر ماجرا، محصولات اُپنسورس «رایگان» نیستند، و مشمول هزینههای پنهانی میشوند که سازمان در طول زمان مجبور به پرداخت آن است. برای راهاندازی و نگهداریِ محصولات اُپنسورس زمان زیادی صرف میشود (در نسبت با محصولات تجاری) و نیازمند نیروی گران متخصص هستند. علیرغم اینها، هزینهی تعمیر و بهبود خرابی موقت این ابزارها ممکن است بیش از هزینهی خرید ابزار تجاری بشود، که در صورت خرابی توسط شرکت ارائه دهنده اصلاح میشوند.
خیلی اوقات، خصوصا استارتاپها، بهتر است که سراغ سرویسها و زیرساختهای ابری-مدیریتشده بروند تا هزینهی نیروی متخصص را بدهند. این مسئله میتواند تیم نرمافزاری را از چالش جذب نیروی این روزهای ایران هم تا حد خوبی در امان بگذارد.