تحلیل مکنزی از ارتقاء بهره‌وری و اثربخشی توسعه نرم‌افزارهای کاربردی
کاربرد نرم‌افزار برای بیشتر سازمان‌های بزرگ به امری حیاتی تبدیل شده‌است. از این رو آنها باید استانداردهایی برای سنجش خروجی ناشی از به کار بردن این نرم‌افزار‌ها در اختیار داشته باشند، به عبارتی خروجی نرم‌افزار‌ها باید پاسخگوی الزاماتی باشد که موجب شده برای توسعه نرم‌افزار جدید اقدام‌گردد.
اکثر کمپانی‌های بزرگ سرمایه‌گذاری‌های سنگینی برای گسترش اپلیکشن‌‌ها و امکانات نرم‌افزاری خود می‌کنند، به این علت که فکر می‌کنند ممکن است مزیت رقابتی و حیات آینده آنها به این کار بستگی داشته‌باشد. نرم‌افزار مورد استفاده در ایالت متحده از ۳۲ درصد از کل سرمایه‌گذاری در بخش IT در سال ۱۹۹۰ به حدود ۶۰ درصد در سال ۲۰۱۱ افزایش یافته‌است و نشانگر این است که نرم‌افزار به تدریج به جزئی حیاتی در عملکرد هر سازمانی تبدیل شده‌است. اما با توجه به تجربه ما هنوز سازمان‌های کمی هستند که از ابزارهای مناسبی برای سنجش کیفیت خروجی پروژه‌های توسعه نرم‌افزار خود برخوردار هستند، در عوض بیشتر بر معیارهای مبتنی بر داده‌های ورودی تکیه دارند، مانند هزینه ساعتی توسعه‌دهندگان، واریانس مربوط به بودجه اختصاص یافته به این کار، یا درصد تحویل پروژه‌ها در موعد مقرر. اگرچه این معیار‌ها مفید هستند به این دلیل که نمایانگر میزان تلاش صرف‌شده در راستای گسترش نرم‌افزار هستند اما این معیار نمی‌تواند به‌درستی به این سوال پاسخ دهد که: یک تیم در مدت زمان مشخص چه سطحی از قابلیت‌های نرم‌افزار را می‌تواند ارائه کند؟ یا به عبارت دیگر گروه توسعه نرم‌افزار تا چه حد کارآمد است؟
پرواز کورکورانه
با وجود اینکه بحث سرمایه‌گذاری بالا و مزیت رقابتی شرکت‌ها در میان است، چرا بسیاری از سازمان‌های توسعه نرم‌افزار معیار مشخصی برای اندازه‌گیری میزان بهره‌وری خود ندارند؟
اکثر کمپانی‌های بزرگ سرمایه‌گذاری‌های سنگینی برای گسترش اپلیکشن‌‌ها و امکانات نرم‌افزاری خود می‌کنند، به این علت که فکر می‌کنند ممکن است مزیت رقابتی و حیات آینده آنها به این کار بستگی داشته‌باشد.
اولا؛ قرار دادن هر معیاری برای سنجش خروجی نیازمند افراد بالاسری است که به اندازه‌گیری و پیگیری آن معیار بپردازد که در برخی موارد هزینه‌های این پیگیری بیش از منافع حاصل از آن است. دوما؛ در بسیاری از سازمان‌های توسعه نرم‌افزار شیوه‌های استاندارد شده‌ای برای محاسبه این معیار‌ها وجود ندارد. برای مثال در صورتی که تیم‌های نرم‌افزار تحت روش‌های مختلفی برای دستیابی به الزامات عملکردی و فنی برای پروژه‌های خود فعالیت کنند، نهادینه‌کردن ارزیابی خروجی مشکل است. آخرین و شاید مهم‌ترین دلیل نیز این است که اغلب از سوی خود توسعه‌دهندگان نرم‌افزار نیز قدری مقاومت در برابر ارزیابی شدن وجود دارد. متخصصان حرفه‌ای IT اغلب از اینکه مرتبا نسبت به یک معیار درمورد میزان بهره‌وری خود پاسخگو باشند، راضی نیستند. به‌خصوص اگر احساس کنند این معیار بین پروژه‌های توسعه مختلف تفاوت قائل نیست. از این رو بسیاری از سازمان‌ها معتقدند معیار مناسبی برای سنجش میزان کارایی این پروژه‌ها وجود ندارد که فاقد ایرادات ذکر شده در بالا باشد.
با وجود اینکه تمام معیارهای سنجش مبتنی بر خروجی، ویژگی‌های مثبت و منفی خاص خود را دارند و می‌توانند در زمان اجرا چالش برانگیز باشند، ما اعتقاد داریم راه‌حل این مشکل استفاده ترکیبی از متد UCs) Use cases) – روشی برای جمع‌آوری الزامات مورد نیاز برای پروژه‌های توسعه نرم‌افزار- و متد UCPs) Use-case points) – یک معیار سنجش که کیفیت عملکرد نرم‌افزار در خروجی را محاسبه می‌کند- است.
برای بیشتر شرکت‌ها قرار گرفتن در این مسیر نیازمند یک دگرگونی دو مرحله‌ای است، ابتدا پذیرش UC و سپس UCP. اگرچه ممکن است در مسیر این تحول با مقاومت از سوی برخی همکاران خود و توسعه‌دهندگان نرم‌افزار مواجه شوید که تعداد آنها کم نیست، اما ما معتقدیم که ارزش تلاش کردن را دارد.
متد UCs) Use cases)
علاوه بر کمبود یک متد مناسب برای ارزیابی بهره‌وری، سازمان‌ها اغلب فاقد روشی مناسب برای جمع‌آوری و سازماندهی به الزامات تکنیکی و عملی برای پروژه‌های توسعه نرم‌افزار هستند و اغلب با لیستی ساختار نیافته مواجه‌اند.
در نتیجه این سازمان‌ها برای دستیابی به لیستی کامل و دقیق از الزامات موجود برای نرم‌افزارهای جدید با مشکل مواجه شده و نمی‌‌توانند آنها را با نیازهای مشتریان خود در یک سو قرار دهند. پروژه‌های توسعه نرم‌افزار آنها دچار ناکارایی است چراکه دائم مجبورند اولویت‌های خود را تغییر دهند، با درخواست تغییر در پروژه در آخرین دقایق تحویل آن مواجه هستند و در پایان نیز باعث نارضایتی کاربران کسبوکار می‌شوند. تجربه ما نشان میدهد اغلب این تغییرات برنامه‌ریزی نشده باعث میشود پروژه‌ها با هزینه‌هایی ۳۰ تا ۱۰۰ درصد بیش از آنچه برایشان برنامه‌ریزی شده مواجه شوند.
ما معتقدیم که UC یک روش ساختار یافته و منطقی برای سازماندهی به الزامات عملی موجود برای پروژه توسعه نرم‌افزار است. هر یوزکیس به توصیف دقیق نحوه تعامل کاربران با یک اپلیکشن می‌پردازد و در جریان این توصیف است که لیست دقیق الزامات موجود برای پروژه‌های توسعه نرم‌افزار شکل می‌گیرد. برای مثال UC برای یک نرم‌افزار بانکی آنلاین ممکن است به توصیف هر یک از مراحلی که مشتری بانک دنبال می‌کند تا وارد حساب کاربری خود شده و موجودی سرمایه خود را چک کند بپردازد و به موازات آن تمام تراکنش‌های درگیر در زمان فراخوانی اپلیکیشن مانند مراجعه به مرکز ذخیره داده‌ها و استخراج داده مورد نظر نیز توصیف میشود و یا یک UC دیگر درمورد این اپلیکیشن می‌تواند مربوط به نقل و انتقال وجهی باشد که توسط کاربر از حساب جاری به حساب ذخیره شده صورت می‌گیرد. به‌طور مشخص‌تر یوزکیس‌ها به توصیف «بازیگران» یک اپلیکشن می‌پردازند یعنی کاربران انسان یا سیستم‌هایی که با نرم‌افزار در تعامل هستند، همچنین به توصیف نحوه عملکرد و تعامل اپلیکشن با این بازیگران و روند اجرای یک فانکشن می‌پردازد.
UCهای مرتبط با هم باید به‌شکل منطقی سازماندهی شده و به‌همراه مندرجات مربوطه در کنار هم قرار گیرند تا ایجاد کنندگان و مشتریان یک اپلیکشن بتوانند به آسانی متوجه ساختار کلی آن شوند.
UCها اغلب بر اهداف کسبوکار و الزامات عملی برای ایجاد یک نرم‌افزار جدید تمرکز دارند و از این طریق هم مدیران کسبوکار و هم توسعه‌دهندگان نرم‌افزار می‌توانند به‌آسانی متوجه ساختار آن شوند و الزامات تکنیکی و سایر گزینه‌های تخصصی‌تر نیز می‌تواند در مراحل بعدی به این توصیفات افزوده‌شود. این روند باعث میشود فاز جمع‌آوری الزامات در جریان توسعه یک نرم‌فزار تسریع شود. همچنین ریسک اینکه توقعات کسبوکار از کارایی نرم‌افزار برآورده نشود، کاهش می‌یابد و به‌تبع آن میزان تقاضا برای تغییر در پروژه و دوباره‌کاری در فاز طراحی و ساخت، که اتفاقات بسیار هزینه‌بری هستند، نیز کاهش می‌یابد. همچنین استفاده از UC باعث میشود آسان‌تر بتوان موردهایی برای تست کاربردی نرم‌افزار نوشت، در نتیجه روند تست کردن نرم‌افزار در انتهای کار بسیار سریع‌تر میشود.
متد UCPs) Use-case points)
در این مرحله از اطلاعات حاصل از UC استفاده میشود. محاسبات UCP، تعداد تراکنش‌های اجرا شده توسط یک اپلیکیشن و تعداد گروه‌های مختلفی از انسان‌ها که با این اپلیکشن در تعامل هستند را نمایش میدهد و از این سرشماری خام برای تشخیص میزان پیچیدگی فنی نرم‌افزار و درصدی از کدهای آن که باید در آینده تغییر یابد استفاده میشود.
اخیرا اعضای یک گروه توسعه نرم‌افزار به محاسبه UCP برای ۱۲ پروژه از پروژه‌های تکمیل شده خود پرداختند، از طرفی مدیر این گروه نیز به‌طور مستقل به هر پروژه نمره‌ای اختصاص داد که نمایانگر میزان کارایی نرم‌افزار طراحی شده در عمل بود و مشاهده شد که یک همبستگی بالا میان محاسبات UCP و نمرات اختصاص یافته به هر پروژه وجود دارد (همبستگی بالا‌تر از ۸۰ درصد)، که این نشان میدهد UCP روشی قابل اطمینان برای ارزیابی خروجی حاصل از این دسته پروژه‌ها است و می‌تواند به‌عنوان معیاری برای صحت ارزیابی کارایی در میان تیم‌ها محسوب شود. براساس تجارب ما بهره‌وری میان تیم‌های توسعه نرم‌افزار می‌تواند بیش از ۵۰ درصد و اغلب تا ۱۰۰ درصد تفاوت داشته‌باشد. UCP به سنجش کارایی نرم‌افزار با دقت ۱۰ تا ۱۵ درصد می‌پردازد، در نتیجه این روش برای تشخیص کارایی تیم‌ها روشی مناسب است.
بعلاوه، UCP نیازمند زمان و مهارت زیادی برای محاسبات خود نیست، حتی برای پروژه‌های بزرگ نیز این محاسبات می‌تواند در کمتر از یک روز کامل شود. از این رو می‌توان در ابتدای چرخه عمر پروژه این محاسبات را انجام داد و سپس با مشخص شدن الزامات بیشتر و پیشروی در کار طراحی، محاسبات مربوطه را تصحیح کرد. در نتیجه UCP در روند برنامه‌ریزی پروژه، مدیریت کارایی و ارزیابی عملکرد گذشته‌نگر مفید است.
چالش‌های فراروی این تحول
سازمان‌هایی که با موفقیت می‌توانند این دو مرحله را در ساختار خود بپذیرند کار خود را با یک روند آزمایشی آغاز می‌کنند که شامل چندین تیم و گروهی از پروژه‌های جدید است. به این شکل که در روند انجام این پروژه‌های آزمایشی می‌آموزند که چگونه ابزار‌ها و مراحلی را طراحی کنند تا از آن طریق UC و UCP را برای خود قابل استفاده و عملیاتی سازند. برای مثال در این راستا تیم‌ها سعی می‌کنند به سوالاتی پاسخ دهد مانند اینکه: تیم باید از چه الگو و ابزارهایی برای دستیابی به یوزکیس‌ها و محاسبات UCP استفاده کند؟ سازمان چگونه می‌تواند اطمینان یابد که همه افراد فرآیندهای استاندارد را دنبال می‌کنند؟ و چگونه می‌توان معیارهای ارزیابی را برای همگان آشکار کرده و مورد بحث قرار داد؟
وقتی با استفاده از این روش یک پروژه تکمیل گردید، تیم‌های آزمایشی در روند پروژه با روش‌ها و ابزارهای جدیدی آشنا شده‌اند، همچنین این تیم‌ها می‌توانند از پروژه‌هایی که قبلا تکمیل شده برای تمرین در ساخت UC و محاسبات UCP استفاده کنند. در این زمان است که سازمان از تیم‌های آزمایشی در پروژه واقعی استفاده می‌کند تا به اصلاح فرآیند‌ها و ابزارهای موجود پرداخته و ایرادات موجود در طراحی را برطرف سازند. پس از اتمام مرحله آزمایشی، سازمان‌ها به گسترش این روند در سراسر سازمان می‌پردازند.
بسیار مهم است که در طول این فرآیند تیم آزمایشی به شرح منافع حاصل از به‌کارگیری این رویکرد جدید برای واحدهای مختلف کسبوکار بپردازد و مهم‌تر اینکه به‌احتمال زیاد مقاومت‌هایی از سوی افراد داخلی تیم‌های توسعه بوجود می‌آید، این افراد از اینکه مرتبا میزان بهره‌وری آنها مورد سنجش قرار گیرد ناراضی هستند.
آنچه برای پذیرش نهایی این روند در یک سازمان اهمیت دارد این است که مدیریت سازمان چگونه از آن استفاده می‌کند. توسعه‌دهندگان نرم‌افزار منطق استفاده از معیار‌ها برای شناسایی پروژه‌هایی که در معرض خارج شدن از مسیر خود هستند را کاملا درک می‌کنند، همچنین آنها منافع حاصل از تعیین دقیق‌تر منابع و جدول زمانی برای پروژه‌ها را می‌دانند. گاهی تیم توسعه نرم‌افزار مجبور است برای تحویل به موقع یک پروژه ساعات کاری خود را بسیار افزایش دهد اما آنچه برای اعضای تیم حتی از ساعات کاری زیاد نیز دشوار‌تر است، این است که در نهایت نرم‌افزاری را ارائه دهند که کسبوکار مورد نظر به آن احتیاج ندارد یا مطابق با نیازهای او نیست و تیم باید بسیاری از کارهای سخت خود را دوباره و با معیارهای جدید انجام دهند، در هر حال اگر از UC و UCP تنها برای جریمه یا پاداش توسعه‌دهندگان نرم‌افزار استفاده شود، احتمال بیشتری برای مقاومت علیه آن وجود دارد. اما در جهانی که توسعه نرم‌افزار کلید موفقیت برای هر سازمان بزرگی است، توصیه میشود سازمان‌ها مقدمات لازم برای این تحول را فراهم سازند.
منبع: مکنزی