Agile/Scrum பற்றி தொடர் கட்டுரை – 3
என் தந்தை ஒரு நெற்பயிர் விவசாயி. ஏதாவது முழுப் பரிமாணம் தெரியாத விஷயங்களைப் பற்றிப் பேசும்போது, “எருமை மாட்டைத் தண்ணீரில் போட்டு விலை பேசுவது போல” என்று உபமானம் கூறுவார். பெரும்பாலான மென்பொருள் மதிப்பீடும், பேரப் பேச்சும் எருமை மாட்டைத் தண்ணீரில் போட்டு விலை பேசுவது போலத்தான் நடக்கிறது. நீங்கள் ஒரு விற்பனையாளராக இருந்தால் அந்த திட்டத்தை மதிப்பீடு செய்தால்தான் நீங்கள் ஒரு விலை சொல்ல முடியும். நீங்கள் வாடிக்கையாளராக இருந்தால் இத்திட்டத்துக்கு ஆகும் முதலீடு என்ன, வருமானம் என்ன என்று பார்த்துத்தானே திட்டத்தைத் தொடருவதா வேண்டாமா என்று ஒரு முடிவு எடுப்பீர்கள்?
ஒரு கட்டிடத்தின் வடிவம், மாடிகள், அறைகள் எண்ணிக்கை மற்றும் வேறு பல மாறுபட்டாலும், பரவலாக இவைகளின் மத்தியில் ஒரு அலகு பொதுவாக உள்ளது. அது சதுர அடியில் கட்டிடத்தின் பரப்பளவு. வடிவமைப்பு செய்யும் முன்னரே ஒரு குறிப்பிட்ட இடத்தில் ஒரு குறிப்பிட்ட தரத்தில் கட்ட ஒரு சதுர அடிக்கு இன்னது செலவாகும் என்று தோராயமான மதிப்பீடு கட்டிடப் பொறியாளர்களால் தர முடியும். நாம் ஒரு கட்டிடத்தைக் கட்டுவது போல் மென்பொருள் திட்டங்களை மேலாண்மை செய்யப் போகிறோம் என்றால் நமக்கு ஒரு பொதுவான அலகு தேவை.
மென்பொருளுக்கு வெவ்வேறு பொது அலகுகள் முயற்சி செய்யப்பட்டன. அவற்றில் முதலில் வந்தது நிரலின் மூல வரிகள் SLOC (source lines of code). இது திட்டத்தின் மூல நிரலில் ஆவண வரிகளைத் தவிர்த்து மற்ற வரிகளின் எண்ணிக்கை. ஆனால் ஒரு மொழியில் 10 வரிகளில் எழுதுவதை மற்றொரு மொழியில் 15 வரிகளில் எழுத வேண்டியிருக்கலாம்.
மேலும் ஒரே மொழியில் திறமையான நிரலாளர்கள் குறைந்த வரிகள் கொண்டு அதே செயல்பாட்டை உருவாக்க முடியும். 1982-ம் ஆண்டு முதன்முதலில் செய்த ஆப்பிள் மேக் கணினி மென்பொருள் இறுதி வடிவம் கொடுக்கும் நேரம். திட்ட மேலாளர்கள் நிரலாளர்களை எழுதிய நிரல் வரிகளின் எண்ணிக்கையை ஒவ்வொரு வாரமும் சமர்ப்பிக்க வற்புறுத்தினர். பில் அட்கின்சன் இது அசட்டுத்தனம் என்று நினைத்தார். ஒரு வாரம் QuickDraw-வில் 2000 வரிகளைக் குறைத்து ஆறு மடங்கு வேகமாக ஓடச்செய்தார். அந்த வாரம் அவர் படிவத்தில் “-2000” என்று எழுதினார். அதன் பின் மேலாளர்கள் படிவத்தை நிரப்ப வேண்டும் என்று கேட்பதை நிறுத்தி விட்டனர்!
முயற்சியின் உள்ளீட்டு அளவுக்குப் பதிலாக முடித்த வேலையின் வெளியீட்டை அளவிடுவதே முக்கியம். செயல்பாட்டு புள்ளிகள் (Function Points) என்பது ஒரு செயலி ஒரு பயனருக்கு எவ்வளவு வேலைகள் செய்யப் பயன்படுகிறதோ அதன் அலகு. இதற்கு நன்கு நிறுவப்பட்ட தரங்கள், நல்ல குறிப்பு கையேடு, மற்றும் பயிற்சியாளர்களுக்கு சான்றிதழ் முதலியன உள்ளன. ஆனால் கடந்த 15 ஆண்டுகளில், செயல்பாட்டு புள்ளிகளை 10%-க்கும் குறைவான நிறுவனங்களும் திட்டங்களுமே பயன்படுத்துகின்றனர்.
மென்பொருளின் அளவை மதிப்பீடு செய்ய விற்பனையாளர் கணிசமான நேரமும் உழைப்பும் போட்டு ஈடுபட்டால் மட்டும் போதாது. வாடிக்கையாளரும் கணிசமான நேரமும் உழைப்பும் போட்டு ஈடுபட வேண்டும். முக்கியமாக வணிக பிரச்சினை என்ன, அந்த பிரச்சினையை தீர்ப்பதற்கு என்ன மென்பொருள் செயலி வேலைக்கு ஆகும் என்ற முன்யோசனை உள்ள மூத்த நிர்வாகிகள் தங்கள் தேவைகளை வழங்க கணிசமான நேரத்தை ஒதுக்க வேண்டும். இது பெரும்பாலும் நடப்பதில்லை. ஆனால் பெரும்பாலான மேல்மட்ட நிர்வாகிகளோ ரொம்பவும் மெனக்கெடாமல் நேரமும் எடுக்காமல் மந்திரக்கோலை அசைத்து உடன் மதிப்பீடு தரவேண்டும் என்று எதிர் பார்க்கிறார்கள்.
இந்த காரணத்தால் மென்பொருள் உருவாக்கும் முயற்சி அளவை மதிப்பிடுவது பெரும்பாலும் நிபுணர்கள்தான் குத்துமதிப்பாகச் செய்கிறார்கள் என்று வெளியிடப்பட்ட ஆய்வுகள் கூறுகின்றன. ஆனால் நிபுணர்கள் வெகுசீக்கிரம் வேலையை முடித்துவிட முடியும் என்ற தளரா நம்பிக்கையுடனே மதிப்பீடுகள் செய்கின்றனர். மேலும் பல நிரலாளர்கள் இயலக் கூடிய மதிப்பீடுகள் செய்தால் தாங்கள் சோம்பேறிகளாகவோ அல்லது திறனற்றவர்களாகவோ தோன்றலாம் என்று பயப்படுகிறார்கள் போலிருக்கிறது. அல்லது அவர்கள் கணக்கில், மென்பொருளை சோதிக்கவும், கண்காணிக்கவும், கட்டமைக்கவும், நிறுவவும், ஆவணப்படுத்தவும், பராமரிக்கவும் தேவைப்படும் உழைப்பையும் நேரத்தையும் எடுத்து கொள்வதில்லை போல் தெரிகிறது. நிரலாளர்களும் தொழில்நுட்ப நிபுணர்களும் திரும்பத் திரும்ப மென்பொருள் உருவாக்கத் தேவைப்படும் முயற்சியையும் நேரத்தையும் குறைத்தே மதிப்பீடு செய்கின்றனர்.
மேலும் தொழில்நுட்பம் மாறுவதால் பணித்திட்டத்துக்கு எழும் இடர்களை நிபுணர்கள் கணக்கில் எடுப்பதாகத் தெரியவில்லை. நிரல் எழுதத் தொடங்கிய பின்தான் நமக்கு வடிவமைப்பில் உள்ள தவறுகள் பெரும்பாலும் தெரிய வரும். இதைவிடக் கொடுமை என்னவென்றால் திட்ட இறுதியில் செயல்திறன் சோதனை தொடங்கிய பின் தெரிய வருவது. எடுத்துக்காட்டாக ஆயிரக்கணக்கான பயனர்களுக்கு ஆதரவு தரவேண்டிய ஒரு ஊதிய திட்டம். வெறும் பத்து பயனர்கள் கொண்டு சோதனை செய்தபோது ஆமை வேகத்தில்தான் நகர்ந்தது. முழுத் திட்ட வேலையும் செய்த பின், இரண்டு ஆண்டுகளாக வாடிக்கையாளர் மற்றும் விற்பனையாளர் இருவருக்கும் பெரும் இழப்பு ஆன பின், ரத்து செய்யப்பட்டது. தொழில்நுட்பங்கள் உயர்வதும் தாழ்வதும், இயக்கமுறைமை வெளியீடுகள், பாதுகாப்பு பிரச்சினைகள், சேவையளிக்கும் நிறுவனங்கள் வாங்கப்படுவதும் திவாலாவதும் முதலாக திட்டத்துக்கு இடராக வரக்கூடிய தொழில்நுட்ப நிகழ்ச்சிகள் அடிக்கடி நடந்துகொண்டுதானே இருக்கின்றன?
மேலும் மென்பொருள் நிரல்களின் ஒட்டுமொத்த அளவு சம்பந்தப்பட்டவர்களுக்கு மிகவும் புரியாத புதிராகவே இருக்கிறது. எடுத்துக்காட்டாக நீங்கள் ஒரு 6 அறைகள் உள்ள 2 மாடி வீடு கட்ட திட்டம் போடுகிறீர்கள் என்று வைத்துக்கொள்வோம். நீங்கள், உங்கள் கட்டிடக் கலைஞர், கட்டிடப் பொறியாளர், ஒப்பந்தக்காரர், ஆசாரி, கொத்தனார், சித்தாள் முதல் உங்கள் குடும்பத்தார் வரை எல்லோருக்கும் ஓரளவுக்கு அதே உத்தேச அளவுதான் மனதிலிருக்கும். ஆனால் மென்பொருள் உருவமில்லாதது, எளிதில் உணர்ந்தறிய முடியாதது.
மேலும் இதை சிக்கலாக்கும்படி, ஒரு ஒற்றை திறமையான நிரலாளர் இராப்பகலாக உழைத்து மிகவும் விரைவில் ஒரு மிகப் பெரிய முழு செயலியை உருவாக்க முடியும். ஒரு தொழிலாளி தனியாக ஒரு முழுக் கட்டடத்தையும் கட்ட முயலுவதை இத்துடன் ஒப்பிட்டுப் பாருங்கள். எவரும் 6 மாதங்களில் ஒரு பிரம்மாண்டமான கட்டிடத்தை கட்டச் சொல்லி ஒரு சிறிய ஒப்பந்ததாரரிடம் கேட்க மாட்டார்கள். ஆனால் இதன் விளைவாக வாடிக்கையாளர்கள் அடிக்கடி மென்பொருள் நிறுவனங்களை பிரம்மாண்டமான கட்டிடத்துக்குச் சமமான மென்பொருள் பணியை செய்ய எதிர்பார்க்கிறார்கள்.
ஆக மென்பொருள் திட்டங்களை மதிப்பீடு செய்யும் போதும், முதலீடு செய்ய முடிவெடுக்கும் போதும், பேரம் பேசும் போதும், ஒப்பந்தம் செய்யும் போதும் எருமை மாட்டைத் தண்ணீரில் போட்டு விலை பேசுவது மட்டும் அல்ல, அது எருமை மாடா, காண்டாமிருகமா, யானையா என்று கூட சரியாகத் தெரியாமல்தான் பேசிக்கொண்டிருக்கிறோம்!
இரா. அசோகன்
Ashok Ramachandran <ashokramach@gmail.com>
தொடரின் முந்தைய பதிவுகள்
மென்பொருள் உருவாக்கும் விந்தையுலகம் 1: மென்பொருள் திட்டங்கள் பாதிக்கு மேல் படுதோல்வி அடைகின்றன!