பிடிபட்ட பஞ்சு: பெரிய நிறுவனங்களில் சாப்ட்வேர் மாற்றமும், காகிதப்பள்ளியும்
தம்பி, ஒரு நாள் ஒரு பெரிய கம்பெனியில் சாப்ட்வேர் மாற்றம் நடந்த கதை கேட்டேன். அந்தக் கதையை கேட்டபோது நம்ம ஊர் அரசு அலுவலகத்தில் ஒரு சின்ன வாரிசு கடிதத்துக்காக ஓடியாடி அலைந்த அனுபவம் நினைவுக்கு வந்தது! நம்ம ஊர் போலவே, வெளிநாட்டிலும் பெரிய நிறுவனங்களில் "ரெட் டேப்" – அதாவது அந்த ஏழாயிரம் காகிதப் பூரிப்பும், மேலாளர்களின் ஒப்புமையும், ஒவ்வொரு கட்டத்திலும் அனுமதி வாங்குவதும் – பெரிய சோதனையே.
வாங்க, அந்தக் கதையை நமக்குரிய ஸ்டைலில் சொல்லிக்கறேன்.
கதை நடக்கிறது ஒரு அமெரிக்கா Fortune 100 நிறுவனத்தில். அந்தக் காலத்தில் "கிளவுட்" (Cloud) என்றால் ரஜினி ஸ்டைல் மாஸ்! எல்லாரும் AWS-க்கு (Amazon Web Services) தங்கள் சாப்ட்வேர் நகர்த்த சொன்னாங்க. நாயகன் இருக்கிறது ஒரு சின்ன டீம் – நாலு பேர் தான். நம்ம ஊர் IT-யில் சின்ன நிறுவனங்கள் நடக்குற மாதிரி, உத்தமம், ஒழுங்கு எல்லாம் தவிர்த்து, எப்படியோ வேலை முடிச்சு போற மாதிரி.
நம்ம டீம் தான் முதலாளி, ஏனென்றால் பெரியவர்கள் கணக்கில் முக்கியமில்லாதவர்கள். AWS-ல் புதிய infrastructure உருவாக்கினோம். பழைய data center-லும், புதுசா AWS-லும் இரண்டிலும் ஒரே சமயம் host பண்ணி, "கட் ஓவர்" (Cutover) செய்ய தயாரா இருக்கோம்.
அப்போ தான், அந்த மரபணு முறையில் நுழைந்த மேலாளர்கள், project managers, architects எல்லாரும் வர ஆரம்பித்தாங்க. "Deployment process-ஐ document பண்ணுங்க" – அதாவது, நம்ம கேட்குற மாதிரி, "சாப்ட்வேர் எப்படி போடுறீங்க?" என்ற கேள்விக்கு, "Deploy button-அ அழுத்துறோம்" என்ற பதில் போதாதாம். "Rollback process-ஐ எழுதுங்க" – அதாவது, பாதி வழியில் ஏதாவது பிரச்சனை வந்தா எப்படி திரும்புறீங்க? நம்ம டீம் தான், "பிரச்சனை வந்தா, code-ல் மாற்றி மீண்டும் deploy பண்ணி விடுறோம்" என்று.
அதெல்லாம் போகட்டும். "Business contact யார்?", "Technical contact யார்?", "Architect யார்?" என்று கேட்க ஆரம்பித்தாங்க. நாலு பேர்தான் டீமில், பெரிய கம்பெனி மாதிரி ஒவ்வொரு பொறுப்புக்கும் தனியாக பேர் சொல்லணுமாம்! "நானே technical contact, approval நான்தான்", "Manager-ஐ business contact-ஆ எழுதிக்கலாம்" – எல்லாம் போட்டாலும், project manager-க்கு திருப்தி இல்லை. "நீங்களே உங்கள் deployment-க்கு approval குடுக்க முடியாது!" என்று பதற ஆரம்பித்தாங்க.
கடைசியில், deploy பண்ணும் பையன் வேறொருத்தர், approve பண்ணும் பையன் வேறொருத்தர், architect-ஆ இன்னொரு பேரை போட்டோம். அந்த "architect" க்கு அந்த வார்த்தை job title-ல் இல்லையேனு project manager-க்கு வேற வேதனை! ஆனா, எப்படியோ, எல்லா column-ஐயும் பூரிக்க, எங்க வேலை tracking software-ல் user story போட்டோம். அந்த project manager-க்கு அந்த software-க்கு access இல்ல, அதனால் அது change request-ஆ இல்லென்று தெரியாமல் போனது.
இதில ஒரு வீணான irony – ஒரே deployment-க்கு இந்தளவு paperwork, அந்த process-ஐயும் argue பண்ணி, முடிவில் அந்த deployment நேரம் வந்து, எல்லாரும் call-ல் வந்து, "Boss, approval இருக்கு இல்ல?", "ஆமாம்", "Technical owner, நாங்கள் OK சொல்லலாமா?", "ஆமாம்", "Coworker, deployment-ஐ ஆரம்பிக்கவும்!" – அப்புறம் 90 நொடிகள் ஒரு மூச்சு விடாம காத்திருக்க, deploy முடிஞ்சு விட்டது.
இது தான் climax! எதுவும் நடக்கலை. சும்மா, "போங்கடா, அடுத்த டீம் வேலை பண்ணட்டும்" என்று போனாங்க. ஆனா, அந்த பெரிய "migration"-க்கு, paperwork-ல் செலவழித்த நேரம் தான் அதிகம்!
நம்ம ஊர் அலுவலகம் போல, "அந்த file-ஐ மூன்று பேர் கையெழுத்து போடணும்", "section head-க்கு approval", "manager-க்கு approval", "superintendent-க்கு approval" என்று ஓடும் கலாசாரம், அங்கும் இருக்கிறது.
பிறகு, அந்த கதைக்கு கீழே Reddit-ல் வந்த comments-ல் சில மாஸ் கருத்துக்கள் இருந்தது. ஒருத்தர் சொன்னார், "Rollback process இல்லைன்னா, 'git revert' பண்ணிட்டு deploy பண்ணுங்க – அதுவும் rollback தான்!" நம்ம ஊர் software கூட்டத்தில் ஒருவரும் அவ்வளவு சிம்பிளா சொல்ல மாட்டாங்க. இன்னொருத்தர், "Database-க்கும் சுற்றிப் போன schema-க்கும் rollback process வேணும்; இல்லனா, பெரிய கஷ்டம்!" என்று practical advice.
ஒரு commenter-ன் கிண்டல்: "Architect-ன் title இல்லென்றால், அவங்கக்கு promotion குடுங்க!" – நம்ம ஊரில் departmental test இல்லாம கூட promotion கேட்பது போல!
இன்னொரு funny comment – "ITIL zombies" வந்துட்டாங்கன்னு! நம்ம ஊர் அரங்கத்தில் எல்லாம், "ISO audit" வந்தா என்ன மாதிரி பயம் இருக்குமோ, அங்க ITIL process-க்கு அஞ்சுறாங்க. ஒருத்தர் சொல்லுறாங்க, "ஒரு $20 software renewal-க்கு கூட risk assessment, vendor review, dependency review – எல்லாம் செய்யணுமாம்!" நம்ம பக்கத்து tea kadai-ல் கடன் வாங்கினாலும் இவ்வளவு process இல்லை.
முதல் commenter சொன்னது, "ஒரு ஒரு change-க்கும், paperwork-க்கு செலவழிக்கும் நேரம், actual code change-க்கு செலவழிக்கும் நேரத்த விட அதிகம்!" – நம்ம ஊர் "file ல் noting போடுற நேரம், வேலை செய்யுற நேரத்த விட அதிகம்" என்ற பழமொழியோடு ஒப்பிடுங்க.
கடைசியில், இந்த கதையில் இருந்து எடுத்துக்கொள்ள வேண்டியது – பெரிய நிறுவனங்களின் process, paperwork, approval என்று எல்லாம் நமக்கு சிரமமா தோன்றினாலும், சில சமயங்களில் அவை அவசியமான பாதுகாப்பாக இருக்க முடியும். ஆனா, கடைசியில், "நாலு பேரு இருந்தாலும், நிறைய பேர் வேலை பண்ணுற மாதிரி காட்டணும்" என்ற அவசியம், நம்ம ஊர் mentality-க்கும் அங்கியும் ஒன்று தான்!
நீங்க என்ன நினைக்கிறீங்க? உங்கள் அலுவலக அனுபவங்களில் இதுபோன்ற "red tape" சந்தைச்சீங்கனா, கமெண்ட்ல பகிருங்க. உங்க experience-யும், இந்த கதையும், நம்ம ஊர் அலுவலக கலாசாரத்தோட ஒப்பிட்டு ரசிக்கலாமா!
அசல் ரெடிட் பதிவு: Red tape: Software cutover edition