பணிகளுடனும் ஒப்புதலுடனும் கூடிய கோரிக்கைகள்

“ஒரு புதிய சக ஊழியர் பணியில் சேர்கிறார்” என்பது ஒரு டிக்கெட் அல்ல. அது ஒரு மடிக்கணினி, இரு கணக்குகள், ஒரு தொலைபேசி இணைப்பு, ஒருவேளை வெளியிலிருந்து அணுகல். ஒவ்வொரு பகுதியும் வெவ்வேறு குழுவுக்குச் சொந்தமானது, இருந்தும் விஷயம் எங்கே நிற்கிறது என்பதைச் சொல்லும் ஒரே வழக்கு உங்களுக்கு வேண்டும்.

ஒரு கோரிக்கை அதற்குத்தான். அது அளிக்கப்படும் அந்தத் தருணத்திலேயே தனது பணிகளை உருவாக்கும் ஒரு டிக்கெட், ஒவ்வொரு பணியும் அதைக் கையாளும் குழுவில் தனி டிக்கெட்டாகிறது.

ஒரு கோரிக்கை என்பது பராமரிக்க வேண்டிய இரண்டாவது விஷயம் அல்ல. அது ஒரு டிக்கெட் வார்ப்புருவில் வாழ்கிறது: “Settings → Request workflows” பகுதியில் ஒவ்வொரு டிக்கெட் வார்ப்புருவையும் காண்பீர்கள், அவற்றில் ஒன்றுடன் பணிகளை இணைக்கிறீர்கள்.

ஒவ்வொரு பணிக்கும் சில புலங்களை நிரப்புகிறீர்கள். “Task” என்பது கோரிக்கையாளர் படிக்கும் பெயர், “Handled by” என்பது அதைப் பெறும் குழு, “Ticket title” மற்றும் “What the team has to do” ஆகியவை அதிலிருந்து உருவாகும் டிக்கெட்டை நிரப்புகின்றன.

பல பணிகள் ஒரே குழுவைச் சுட்டலாம். அப்போது அந்தக் குழுவுக்குப் பல டிக்கெட்டுகள் கிடைக்கும், உள்ளே ஒரு பட்டியல் கொண்ட ஒரே டிக்கெட் அல்ல.

குழு இல்லாத ஒரு பணி வழங்கப்படுவதே இல்லை. அதைப் புலமே சொல்கிறது: “Not assigned yet — this task is not offered”. அதனால் இன்னும் முடியாத ஒரு திட்டத்தையும் சேமிக்க முடியும்.

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

“Ticket title” புலத்தின் முன்னால் “Parent ticket title -” என்ற நிலையான உரை நிற்கிறது. புதிய டிக்கெட் கோரிக்கையின் தலைப்புடன் தொடங்குகிறது, அதைத் தொடர்ந்து உங்கள் தலைப்பு வருகிறது, எடுத்துக்காட்டாக “New colleague in accounting - Set up notebook and docking station”. இதனால் ஒரு பணி எந்தக் கோரிக்கைக்குச் சொந்தமானது என்பதைச் சிறப்புக் குழு பார்க்கிறது. புலத்தைக் காலியாக விட்டால், அதற்குப் பதிலாகப் பணியின் பெயர் பின்தொடர்கிறது.

“Main category” மற்றும் “Subcategory” புதிய டிக்கெட்டின் வகையை முன்கூட்டியே நிரப்புகின்றன. “Handled by” இல் உள்ள குழுவின் வகைகள் மட்டுமே உங்களுக்குக் கிடைக்கும், ஏனெனில் டிக்கெட் அங்கேதான் உருவாக்கப்படுகிறது. குழுவை மாற்றினால், இரண்டு புலங்களும் காலியாக்கப்படும். இரண்டையும் அமைக்கிறீர்கள் அல்லது எதையும் அமைப்பதில்லை; அவை காலியாகவே இருந்தால், டிக்கெட் வகை இல்லாமல் உருவாக்கப்படும்.

கோரிக்கையின் பெயர் பணிகளுக்கு மேலே நிற்கிறது. அதன் அருகில் உள்ள பென்சிலைக் கொண்டு அதன் பெயரை மாற்றுங்கள். அந்தப் பெயர் டிக்கெட் வார்ப்புருவுக்குச் சொந்தமானது, அதனால் அது “Settings → Templates” பகுதியிலும் புதிய டிக்கெட் படிவத்திலும் மாறுகிறது.

புதிய டிக்கெட் படிவத்தில் யாராவது அந்த வார்ப்புருவைத் தேர்ந்தெடுக்கும்போது, ஒவ்வொரு பணிக்கும் ஒரு வரியுடன் “What is needed?” பெட்டி தோன்றுகிறது.

மூன்று வகைகள் உள்ளன, ஒவ்வொரு பணிக்கும் அமைக்கப்படுகின்றன. “Selectable, off by default” காலியாகத் தொடங்குகிறது, “Selectable, on by default” தேர்ந்தெடுக்கப்பட்டே தொடங்குகிறது, அதைத் தேர்வு நீக்கவும் முடியும், “Always — cannot be deselected” எப்போதும் இயங்குகிறது.

எப்போதும் இயங்கும் ஒரு பணியும் காட்டப்படுகிறது, “(always included)” எனக் குறிக்கப்பட்டு. எப்படியும் என்ன நடக்கும் என்பதைக் கோரிக்கையாளர் பார்க்க வேண்டும்.

அந்தப் பெட்டிக்குக் கீழே, அதிலிருந்து என்ன உருவாகும் என்பதைப் படிக்கிறீர்கள்: “Each selected item becomes its own ticket for the team that handles it.”

வார்ப்புரு வாடிக்கையாளர்களுக்கு விடுவிக்கப்பட்டிருந்தால், ஒரு வாடிக்கையாளரும் ஒரு கோரிக்கையை அளிக்கலாம். அதற்கான நிலைமாற்றி வார்ப்புருவிலேயே இருக்கிறது.

அப்போது வாடிக்கையாளருக்குத் தமது சொந்தக் கோரிக்கை மட்டுமே தெரியும். சிறப்புக் குழுக்களில் உள்ள டிக்கெட்டுகள் அவரிடமிருந்து மறைந்தே இருக்கும், அவரது கோரிக்கை அவற்றை உருவாக்கியிருந்தாலும் கூட — அந்த டிக்கெட்டுகள் அணுகல் விவரங்களையும் உள்ளக் குறிப்புகளையும் சுமக்கின்றன. அவற்றின் உள்ளக் குறிப்புகள் கோரிக்கையின் வரலாற்றிலும் தோன்றுவதில்லை. ஒரு சிறப்புக் குழு தனது டிக்கெட்டை மூடும்போது, அதன் இணைப்புகள் “Internal” குறிச்சின்னத்துடன் கோரிக்கைக்குள் நகலெடுக்கப்படுகின்றன; வாடிக்கையாளர் அவற்றைப் பார்க்கவும் முடியாது, பதிவிறக்கவும் முடியாது.

ஒரு கோரிக்கை மின்னஞ்சல் வழியாக வந்தால், அது ஒரு சாதாரண டிக்கெட்டாக மாறுகிறது. அப்போது பணிப்பாய்வைப் பின்னர் தொடங்குகிறீர்கள். டிக்கெட்டின் தலைப்புப் பகுதியில் உள்ள “Start workflow” பொத்தான் அதைச் செய்கிறது.

உரையாடல் பெட்டியில், “Template” இன் கீழ் பொருத்தமான வார்ப்புருவைத் தேர்ந்தெடுக்கிறீர்கள். அதற்குக் கீழே, புதிய டிக்கெட் படிவத்தில் உள்ள அதே “What is needed?” பெட்டி உங்களுக்குக் கிடைக்கும். கோரிக்கை கேட்பதைத் தேர்ந்தெடுங்கள்.

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

“Start” உடன், படிவத்திலிருந்து வரும் கோரிக்கையைப் போலவே பணிகள் உருவாக்கப்படுகின்றன. வார்ப்புருவுக்கு ஒப்புதல் தேவைப்பட்டால், அது கிடைக்கும் வரை டிக்கெட்டும் அதன் பணிகளும் பூட்டப்பட்டிருக்கும்.

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

கோரிக்கையிலேயே பணிகள் “Workflow tasks” இன் கீழ் பட்டியலிடப்படுகின்றன, அதன் அருகில் எண்ணிக்கையுடன், எடுத்துக்காட்டாக “1 of 4 done”.

ஒவ்வொரு வரியும் பணியின் பெயரையும், அதன் டிக்கெட் எண்ணையும், குழுவையும், பொறுப்பாளரையும் காட்டுகிறது; அந்தப் பெயர் அந்த டிக்கெட்டுக்குள் செல்லும் ஒரு சுட்டி.

“Done” என்பது ஒரு தனித் தேர்வுக் குறியீட்டிலிருந்து அல்ல, டிக்கெட்டின் நிலையிலிருந்தே வருகிறது. டிக்கெட் பட்டியலில் எது மூடப்பட்டதாகக் கணக்கிடப்படுகிறதோ அதுவே இங்கே முடிந்ததாகக் கணக்கிடப்படுகிறது — ஒரே விஷயத்திற்கு இரண்டு கணக்கீட்டு முறைகள் இருந்தால் அவை என்றாவது ஒருநாள் விலகிப் போகும்.

இந்தத் தொகுதி ஒரு கோரிக்கையில் மட்டுமே தோன்றும். ஒரு சாதாரண டிக்கெட் அதைக் காட்டுவதில்லை.

ஒரு சிறப்புக் குழு தனது டிக்கெட்டை மூடும்போது, அதன் “Closing comment” கோரிக்கைக்கு வந்து சேர்கிறது. அது அங்கே ஓர் உள்ளகக் குறிப்பாக நிற்கிறது, அதன் முதல் வரி பணியின் எண்ணையும் பெயரையும் குறிப்பிடுகிறது. வாடிக்கையாளர் இந்தக் குறிப்பைப் பார்ப்பதில்லை.

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

ஓர் ஒப்புதல் ஒவ்வொரு தனிப் பணிக்கும் அல்ல, கோரிக்கை முழுவதற்கும் பொருந்தும். எட்டுப் பயன்பாடுகள் என்பது மேலாளருக்கு எட்டு அஞ்சல்கள் அல்ல, ஒரே அஞ்சல்.

அதே திட்டத்தில் “Approvals” இன் கீழ் இதை அமைக்கிறீர்கள், அதற்கு மேலே உள்ள வாக்கியம் விதியைச் சொல்கிறது: “One approval covers the whole request. Add a second stage only when single tasks need their own release.” ஒவ்வொரு நிலைக்கும் ஐந்து புலங்கள் உள்ளன: “Name” நிலையின் பெயர், எதற்குப் பொருந்தும் என்பதை “Covers” சொல்கிறது, ஒப்புதல் அளிப்பவர் எங்கிருந்து வருகிறார் என்பதை “Decided by” சொல்கிறது, அந்த நபரை “Approver” கொண்டிருக்கிறது, நினைவூட்டலை “Remind after (hours)” அமைக்கிறது.

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

அந்த அஞ்சலில் ஒரு பக்கத்திற்கான சரியாக ஒரே ஒரு சுட்டி இருக்கிறது. அஞ்சலுக்குள்ளேயே ஒப்புதல் அல்லது மறுப்புப் பொத்தான்கள் வேண்டுமென்றே இல்லை: ஒவ்வொரு சுட்டியையும் திறக்கும் ஒரு வைரஸ் சோதனையாளர் இல்லையேல் ஒப்புதல் அளித்துவிடும்.

அந்தப் பக்கம் நிலையின் பெயரைத் தலைப்பாகக் கொண்டுள்ளது. அது கோரிக்கையின் எண்ணையும் தலைப்பையும், கோரிக்கையாளரையும், “This decision covers” இன் கீழ் இந்த முடிவு எந்தப் பணிகளைப் பற்றியது என்பதையும், அதற்குக் கீழே ஒரு கருத்துப் புலத்தையும் இரு பொத்தான்களையும் காட்டுகிறது.

அந்தச் சுட்டி என்றென்றும் நீடிப்பதில்லை, கெடுவை அந்தப் பக்கமே பெயரிட்டுச் சொல்கிறது: “Please decide by …”. அது 14 நாட்களுக்குச் செல்லுபடியாகும். அதன் பிறகு, சுட்டி செல்லாதது அல்லது காலாவதியானது என்று மட்டுமே பக்கம் சொல்லும், ஒரு நிர்வாகி “Reassign” மூலம் கோரிக்கையை மீண்டும் அனுப்புகிறார்.

ஒரு முடிவைத் திரும்பப் பெற முடியாது, அதன் பிறகு அந்தப் பக்கம் அதைச் சொல்கிறது: “A decision cannot be changed.”

சில பணிகளுக்குத் தனி விடுவிப்பு தேவை. வெளியிலிருந்து அணுகல் என்பது ஒரு மடிக்கணினியைப் போன்றது அல்ல.

அதற்காக இரண்டாவது ஒரு நிலையைச் சேர்த்து, பணியில் “Extra approval” இன் கீழ் அதைத் தேர்ந்தெடுக்கிறீர்கள். அது “None — the request approval is enough” எனச் சொல்லும் வரை, கோரிக்கையின் விடுவிப்பே போதும். இரு நிலைகளும் ஒன்றன் பின் ஒன்றாக அல்ல, ஒரே நேரத்தில் கேட்கப்படுகின்றன. தேர்ந்தெடுக்கப்பட்ட பணிகளில் ஒன்று ஒரு நிலையைத் தொட்டால் மட்டுமே அந்த நிலை கேட்கப்படுகிறது. முழுக் கோரிக்கைக்கான நிலை எப்போதும் கேட்கப்படுகிறது.

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

அதுவரை அந்தப் பணி பூட்டப்பட்டிருக்கும். அதன் டிக்கெட் “Waiting for approval” இல் இருக்கும், அதற்குப் பொறுப்பாளர் இல்லை. நிலைப் பொத்தான்களுக்குப் பதிலாக அட்டை “This ticket is waiting for approval and cannot be worked on yet.” எனப் படிக்கிறது. அதற்கு முன் எந்த வழியும் அதற்குப் பொறுப்பாளரைத் தருவதில்லை.

டிக்கெட் பட்டியலில் மொத்த நடவடிக்கைகளுக்கும் அந்தப் பூட்டு பொருந்தும். அங்கே அத்தகைய ஒரு டிக்கெட்டைத் தேர்ந்தெடுத்தால் காரணத்தைப் படிக்கிறீர்கள்: “This ticket is waiting for approval and cannot be worked on yet.”

அப்படியும் டிக்கெட் உடனடியாகவே உருவாக்கப்படுகிறது, அதனால் என்ன வரப்போகிறது என்பதைச் சிறப்புக் குழு பார்க்கிறது, யாரும் கோரிக்கையைக் கண்காணித்துக்கொண்டிருக்க வேண்டியதில்லை.

ஒவ்வொரு நிலைக்கும் ஒரு நினைவூட்டலை மணி நேரங்களில் அமைக்கலாம்.

பதில் வரவில்லை என்றால், அந்த நேரத்திற்குப் பிறகு அதே அஞ்சல் மீண்டும் வெளியே செல்கிறது, முதலாவது சுமந்த அதே சுட்டியுடன். முதல் அஞ்சலை வைத்திருப்பவர் அதையே இன்னும் பயன்படுத்தலாம்.

நினைவூட்டல் இல்லாமல் கோரிக்கை வெறுமனே காத்திருக்கும், மீண்டும் கேட்காமல்.

இல்லாதது எதுவென்றால், கால முடிவால் வரும் விடுவிப்பு. புலத்திற்குக் கீழே அது வெளிப்படையாகவே சொல்லப்படுகிறது: “A request is never approved automatically. If nobody reacts, it keeps waiting.” தானாகவே ஒப்புக்கொள்ளும் ஒரு கெடு, ஒப்புதலாக இருக்காது, ஒரு சம்பிரதாயமாகவே இருக்கும்.

மறுப்பதற்குக் காரணம் தேவை. உரை இல்லாமல் அந்தப் பக்கம் மறுப்பை ஏற்காது.

அந்த உரை எங்கே செல்கிறது என்பதைப் புலம் சொல்கிறது: “Comment (required when you reject — the requester will see it)”. உள்ளகக் குறிப்பு இங்கே சேராது.

கோரிக்கையாளர் காரணத்துடன் ஒரு மின்னஞ்சலைப் பெறுகிறார், எதுவும் நகராதது ஏன் என்று அவர் கேட்க வேண்டியதில்லை.

ஒப்புதல் அளிப்பதற்குக் காரணம் தேவையில்லை. அதுவே எதிர்பார்க்கப்படும் முடிவு.

இரண்டாவது நிலை மட்டும் மறுத்தால், அந்த மறுப்பு அந்த நிலையின் பணிகளுக்கு மட்டுமே பொருந்தும். கோரிக்கையின் மீதிப் பகுதி தொடர்ந்து நடக்கும்.

மறுக்கப்பட்ட ஒரு பணிக்கு “Rejected” நிலை கிடைத்து, அது முடிந்ததாகக் கணக்கிடப்படுகிறது, எனவே ஒருபோதும் வராத ஒன்றுக்காகக் கோரிக்கை என்றென்றும் தொங்கிக்கொண்டிருப்பதில்லை.

கோரிக்கை மறுக்கப்பட்டவுடன், மற்ற ஒப்புதல் அளிப்பவர்களுக்கு இனி அஞ்சல்கள் வராது. அப்போது அவர்களின் சுட்டியில் “This request has already been rejected. Your decision is no longer needed.” என்று இருக்கும். டிக்கெட்டில் உள்ள பட்டியலில் அவர்களின் நிலை “No longer needed: the request was rejected.” எனக் காட்டுகிறது.

கோரிக்கையில், “Approvals” ஒவ்வொரு நிலைக்கும் ஒரு வரியை ஒப்புதல் அளிப்பவருடனும், நிலையுடனும், நிலுவையில் உள்ள ஒரு கோரிக்கைக்கு எவ்வளவு நேரமாகக் காத்திருக்கிறது என்பதுடனும் காட்டுகிறது.

முடிவுக்குப் பிறகு அந்த வரி, அது எப்போது எடுக்கப்பட்டது, எந்தக் கருத்துடன் என்பதைக் காட்டுகிறது. அதுவே தணிக்கைத் தடம், அது வழக்குடனேயே தங்கிவிடுகிறது.

ஒப்புதல் அளிப்பவர் விடுமுறையில் இருந்தால், ஒரு நிர்வாகி கோரிக்கையை வேறொரு முகவரிக்கு நகர்த்துகிறார். அந்தப் பொத்தான் “Reassign” எனப்படுகிறது, கோரிக்கை நிலுவையில் இருக்கும்போது மட்டுமே அது தோன்றும்.

ஒரு நிர்வாகி மட்டுமே இதைச் செய்யலாம். மறு ஒதுக்கீடு செய்யக்கூடிய ஒரு முகவர், தமக்கே மறு ஒதுக்கீடு செய்துகொண்டு பிறகு முடிவெடுக்க முடியும்.

மறு ஒதுக்கீடு ஒரு புதிய சுட்டியை உருவாக்குகிறது, பழையது உடனடியாகச் செயலிழக்கிறது — யாராவது அதை முன்னனுப்பியிருந்தாலும் கூட.

அந்த நகர்வும் அதே பட்டியலில் தோன்றுகிறது: யார் நகர்த்தினார், எப்போது, யாரிடமிருந்து யாருக்கு.

இன்னொருவரின் பெயரில் யாரும் முடிவெடுக்க முடியாது. அந்தச் சுட்டியே ஒரே வழி, அது யாருக்குக் கிடைத்தது என்பது வழக்கில் பதிவாகிறது.