மென்பொருள் உருவாக்கும் விந்தையுலகம் 2: மென்பொருள் தேவைகள் தெரிவது என்பது மூடுபனியில் நடப்பது போன்றது!

Agile/Scrum பற்றி தொடர் கட்டுரை – 2

 

பொதுவாக ஒரு மென்பொருள் உருவாக்கும் திட்டத்தில் பின்வரும் முக்கிய கட்டங்கள் உண்டு:

  1. தேவைப்பட்டியல் திரட்டுதல்

  2. வடிவமைத்தல்

  3. நிரலாக்கல்

  4. சோதித்தல்

  5. நிறுவுதல்

 

மென்பொருள் திட்டங்களில் பிரச்சினை முதல் கட்டத்திலேயே தொடங்குகிறது. முதல் கோணல் முற்றிலும் கோணல் என்ற பழமொழி இதற்கு முற்றிலும் பொருந்தும்.

 

கணினி தகவல் அமைப்புகள் இதழில் வெளியான ஆராய்ச்சியின்படி 90% பெரிய மென்பொருள் திட்டங்களில் தோல்விக்கு மூலகாரணம் மோசமான தேவைகள் பட்டியல் திரட்டுதல்தான்.

 

இம்மாதிரி மோசமான தேவைகள் திரட்டுதலின் முக்கிய விளைவு scope creep. PMBOK (Project Management Body of Knowledge) என்பது சுமார் 600 பக்கங்கள் கொண்ட திட்ட மேலாளர்கள் அடிக்கடி எடுத்து  படித்துப் பார்க்கும் பஞ்சாங்கம். PMBOK படி, scope creep-ன் வரையறை என்ன என்று பார்ப்போம். scope creep என்பது வாடிக்கையாளரின் எழுத்துமூல ஒப்புதல் இல்லாமலும் திட்டக்கெடு, செலவுகள், மற்றும் குழு உறுப்பினர்களின் வேலைச்சுமை மீது ஆகும் விளைவுகள் பற்றி ஆராயாமலும் மென்பொருளில் அம்சங்களை மேலும் மேலும் ஏற்பதேயாகும்.

 

திட்டத்தை ஆரம்பித்த பின் எந்த மாற்றங்களும் செய்யக்கூடாது என்று சொல்லவில்லை. வேலை செய்யத் தொடங்கியபின் மாற்றங்கள் செய்தால் செய்த வேலையை மாற்றி அதிக செலவில் மறுவேலை நிறைய செய்ய வேண்டி வரும். எனவே, மிகவும் அவசிய மாற்றங்கள் மட்டுமே கேட்க வேண்டும். முறையான வழி மூலம் கேட்க வேண்டும். மற்றும் திட்டக் குழுவிடம் இம்மாதிரி கோரிக்கைகளால் திட்டக்கெடு, செலவுகள், மற்றும் குழு உறுப்பினர்களின் வேலைச்சுமை மீது ஆகும் விளைவுகளை ஆராய்ந்து வாடிக்கையாளருக்கு மீண்டும் மதிப்பீடுகள் வழங்க ஒரு செயல்முறை இருக்க வேண்டும். இந்தக் கூடுதல் செலவையும், திட்டக்கெடுவில் தாமதத்தையும் வாடிக்கையாளர் ஏற்றுக்கொண்டால், திட்ட மேலாளர் அதன்படி திட்டத்தைத் திருத்தி அமைக்க வேண்டும்.

 

ஆனால் நடப்பதைப் பார்த்தால் இதெல்லாம் கனவுக்காட்சி போலில்லை?

 

ஆலோசனை நிறுவனம் Standish Group-ன் 2004 அறிக்கையின்படி தோல்வியுற்ற திட்டங்களில் 80% தேவைப்பட்டியல் திரட்டுதல் பிரச்சினையும் அதனால் வந்த scope creep-ம் தான்.

 

Computerworld செய்தி இதழ் எடுத்த கருத்துக் கணிப்பில் 160 தகவல் தொழில்நுட்ப நிபுணர்களில் 80% நபர்கள் scope creep “எப்போதும்” அல்லது “அடிக்கடி” வந்துவிடுகிறது என்று குறிப்பிட்டுள்ளார்கள். அவர்கள் கொடுத்த காரணங்கள் (பல தேர்வு):

  • 44% மோசமான தேவைகள் பட்டியல்.

  • 36% புதிய செயலியில் பயனர்களுக்குப் பரிச்சயமில்லை.

  • 28% திட்டங்கள் நீண்ட காலம் எடுத்ததால் தேவைகளே மாறிவிட்டன.

  • 22% பயனர் எதிர்பார்ப்பை தயார் செய்யத் தவறியது.

  • 19% ஆரம்ப கட்டங்களில் பயனர்களை ஈடுபடுத்தத் தவறியது.

 

பயனர்களிடமிருந்து நல்ல உள்ளீடு இருந்தாலும் அவற்றை நன்கு பகுப்பாய்வு செய்தாலும் ஒன்று மட்டும் நிச்சயம். பயனர்கள் தங்களுக்கு என்ன வேண்டும் என்று தெரியும் என்று நினைக்கிறார்கள். ஆனால் அவர்கள் செயலியைப் பார்த்து பயன்படுத்தத் தொடங்கும்போதுதான் தங்களுடைய தேவை உண்மையில் என்ன என்று புரிந்து கொள்ள ஆரம்பிக்கிறார்கள். மென்பொருள் தேவைகள் தெரிவது என்பது மூடுபனியில் நடப்பது போன்றது. தூரத்திலிருந்து பார்த்தால் மங்கலாகத்தான் தெரியும். அருகில் நெருங்க நெருங்க மிகத் துல்லியமாகத் தெரியத் தொடங்கும்.

மூடுபனியில் நடப்பது போன்றது!

அவர்கள் முன்னர் பயன்படுத்தாத ஒரு புதிய செயலி உருவாக்கும் போது இது குறிப்பாகப் பொருந்தும். வரைபட பயனர் இடைமுகப்பு (GUI) இருந்தால் இன்னும் மிக்கப் பொருந்தும். பெரும்பாலும் எல்லா மென்பொருள் திட்டங்களும் இந்த இரண்டில்தானே அடங்குகின்றன?

 

பல மென்பொருள் திட்டங்களில் நாம் எதிர்கொள்கின்ற இக்கட்டான நிலைமை இதுதான். புதிதாகத் தெரியவந்த தேவைகளைப் புறக்கணித்து விட்டு ஒப்பந்த ஆவணங்கள் படி செய்து பயனர்களுக்கு மிகத் தேவையான அம்சங்களை விட்டு விடுவதா? அல்லது தேவையான மாற்றங்கள் செய்து திட்டத்தின் செலவும் அதிகமாகி திட்டக்கெடுவில் முடிக்கவும் முடியாமல் திணறுவதா?

 

நான் திட்டத்தின் முதல் கட்டத்தில் பிரச்சினை தொடங்குகிறது என்றா சொன்னேன்? உண்மையில் திட்டம் துவங்கும் முன்னரே, திட்டத்துக்கு ஒப்புதல் பெற மதிப்பீடு தயாரிப்பதிலேயே சிக்கல் ஆரம்பம். அது எப்படி என்று அடுத்த கட்டுரையில் காண்போம்.

 

scope creep-க்கு தமிழாக்கம் தேவை. Feature creep, scope change என்றும் சொல்கிறார்கள். இதோ இரண்டு முயற்சிகள்:

  • நகரும் குறியிலக்கு: ‘moving target’-க்கு அருகில் வருகிறது.

  • ஊதிப் பெருக்கும் செயற்பரப்பு: Ballooning scope. இது ‘creep’ ஒத்த குறையான உட்பொருளை வழங்குகிறது. ஆனால், சிறிது நீளமாக இல்லை?

கீழே உள்ள கருத்துப்பெட்டியில் உங்கள் பரிந்துரைகளைப் பகிர்ந்து கொள்ளுங்கள். குழுச் சிந்திப்பில் பொருத்தமானதொரு சொற்றொடர்  உருவாக்குவோம்.

இரா. அசோகன்

Ashok Ramachandran <ashokramach@gmail.com>

தொடரின் முந்தைய பதிவுகள்

Agile/Scrum பற்றி தொடர் கட்டுரை – 1

%d bloggers like this: