IT திட்டத்தில் ஒரு குழுவில் பணிப்பாய்வு அமைப்பு

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

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

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

ஒரு காலத்தில், நான் அத்தகைய திட்டத்தில் இறங்கினேன், அங்கு இந்த மகிழ்ச்சிகள் அனைத்தும் இருந்தன.

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

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

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

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

இது எனது திட்டத்தில் வேலை செய்வதால், இது ஒருவருக்கும் உதவியாக இருக்கும். எனவே, செயல்முறையே, திட்டத்தைச் சேமிக்க எங்களுக்கு உதவியது:

"எனக்கு பிடித்த திட்டம்" திட்டத்தில் குழு வேலை செய்யும் செயல்முறை

அ) குழு செயல்முறைக்குள் (டெவலப்பர்களுக்கு இடையே)

  • அனைத்து பணிகளும் ஜிரா அமைப்பில் உருவாக்கப்படுகின்றன
  • ஒவ்வொரு பணியும் முடிந்தவரை விவரிக்கப்பட வேண்டும், மேலும் கண்டிப்பாக ஒரு செயலைச் செய்ய வேண்டும்.
  • எந்தவொரு அம்சமும், அது மிகவும் சிக்கலானதாக இருந்தால், பல சிறிய பணிகளாக உடைக்கப்படும்
  • குழு அம்சங்களில் ஒரு பணியாக செயல்படுகிறது. முதலில், நாங்கள் ஒரு அம்சத்தை ஒன்றாகச் செய்கிறோம், அதை சோதனைக்குக் கொடுத்து, அடுத்ததை எடுத்துக்கொள்கிறோம்.
  • ஒவ்வொரு பணியும் பின்தளம் அல்லது முன்பக்கம் என்று பெயரிடப்பட்டுள்ளது
  • பணிகள் மற்றும் பிழைகள் வகைகள் உள்ளன. நீங்கள் அவற்றை சரியாகக் குறிப்பிட வேண்டும்.
  • பணி முடிந்ததும், அது குறியீட்டு மதிப்பாய்வு நிலைக்கு மாற்றப்படும் (அதன் சக ஊழியருக்கு இழுக்க கோரிக்கை உருவாக்கப்பட்டது)
  • பணியை முடித்தவர் உடனடியாக இந்த பணிக்கான நேரத்தைக் கண்காணிக்கிறார்
  • குறியீட்டைச் சரிபார்த்த பிறகு, PR அங்கீகரிக்கப்பட்டது, அதன் பிறகு, இந்த பணியைச் செய்தவர் அதை முதன்மை கிளையில் இணைக்கிறார், அதன் பிறகு அது தேவ் சேவையகத்திற்கு வரிசைப்படுத்தத் தயாராக உள்ளது.
  • தேவ் சேவையகத்திற்கு அனுப்பத் தயாராக உள்ள அனைத்து பணிகளும் குழுத் தலைவரால் (அவரது பொறுப்பின் பகுதி), சில நேரங்களில் ஒரு குழு உறுப்பினர், ஏதாவது அவசரமாக இருந்தால். வரிசைப்படுத்தலுக்குப் பிறகு, பயன்படுத்துவதற்குத் தயாராக இருந்து dev வரை அனைத்து பணிகளும் நிலைக்கு மாற்றப்படும் - dev இல் சோதனைக்குத் தயார்
  • அனைத்து பணிகளும் வாடிக்கையாளரால் சோதிக்கப்படுகின்றன
  • டெவெலரில் வாடிக்கையாளர் பணியைச் சோதித்தவுடன், அவர் அதை உற்பத்திக்கு அனுப்பத் தயாராக உள்ள நிலைக்கு மாற்றுவார்.
  • உற்பத்திக்கு வரிசைப்படுத்துவதற்கு, எங்களிடம் ஒரு தனி கிளை உள்ளது, அங்கு வரிசைப்படுத்தலுக்கு சற்று முன்பு மாஸ்டரை ஒன்றிணைக்கிறோம்
  • சோதனையின் போது வாடிக்கையாளர் பிழைகளைக் கண்டறிந்தால், அவர் பணியைத் திருப்பித் தருகிறார், அதன் நிலையை மறுபரிசீலனைக்காகத் திருப்பித் தருகிறார். சோதனை செய்யப்படாதவற்றிலிருந்து புதிய பணிகளை இப்படித்தான் பிரிக்கிறோம்.
  • இதன் விளைவாக, அனைத்து பணிகளும் உருவாக்கத்தில் இருந்து முடிவடையும் வரை செல்கின்றன: செய்ய வேண்டியவை → வளர்ச்சியில் → குறியீடு மதிப்பாய்வு → டெவெலப்பில் → QA க்கு தயார் வரிசைப்படுத்தல் → (dev க்கு திரும்பவும்) → தயாரிப்புக்கு தயார் வரிசைப்படுத்தல் → தயாரிப்பில் QA → முடிந்தது
  • ஒவ்வொரு டெவலப்பரும் தளத்தின் பயனர் உட்பட, தனது குறியீட்டை சுயாதீனமாகச் சோதிக்கின்றனர். குறியீடு செயல்படும் என்பது உறுதியாகத் தெரிந்தால் தவிர, முக்கிய கிளையுடன் ஒரு கிளையை இணைக்க அனுமதிக்கப்படாது.
  • ஒவ்வொரு பணிக்கும் முன்னுரிமை உண்டு. முன்னுரிமைகள் வாடிக்கையாளர் அல்லது குழுத் தலைவரால் அமைக்கப்படுகின்றன.
  • டெவலப்பர்கள் முதலில் முன்னுரிமைப் பணிகளைச் செய்கிறார்கள்.
  • கணினியில் வெவ்வேறு பிழைகள் கண்டறியப்பட்டால் அல்லது ஒரு பணி பல நிபுணர்களின் பணியைக் கொண்டிருந்தால் டெவலப்பர்கள் ஒருவருக்கொருவர் பணிகளை ஒதுக்கலாம்.
  • வாடிக்கையாளர் உருவாக்கும் அனைத்து பணிகளும் குழுத் தலைவருக்கு அனுப்பப்படும், அவர் அவற்றை மதிப்பீடு செய்து வாடிக்கையாளரிடம் அவற்றை இறுதி செய்யும்படி கேட்கிறார் அல்லது குழு உறுப்பினர்களில் ஒருவருக்கு ஒதுக்குவார்.
  • dev அல்லது prod க்கு அனுப்பத் தயாராக இருக்கும் அனைத்து பணிகளும் குழுத் தலைவரிடம் செல்கிறது, அவர் எப்போது, ​​எப்படி வரிசைப்படுத்த வேண்டும் என்பதை சுயாதீனமாக தீர்மானிக்கிறார். ஒவ்வொரு வரிசைப்படுத்தலுக்குப் பிறகு, குழுத் தலைவர் (அல்லது குழு உறுப்பினர்) வாடிக்கையாளருக்கு இதைப் பற்றி அறிவிக்க வேண்டும். மேலும், டெவ்/ப்ராடில் சோதனைக்குத் தயாராக உள்ள பணிகளுக்கான நிலைகளை மாற்றவும்.
  • ஒவ்வொரு நாளும் ஒரே நேரத்தில் (எங்களிடம் 12.00 மணிக்கு உள்ளது) நாங்கள் அனைத்து குழு உறுப்பினர்களுக்கும் இடையே ஒரு பேரணியை நடத்துகிறோம்
  • அணித்தலைவர் உட்பட பேரணியில் உள்ள அனைவரும் நேற்று அவர் என்ன செய்தார், இன்று என்ன செய்ய திட்டமிட்டுள்ளார் என்று தெரிவிக்கின்றனர். எது வேலை செய்யாது, ஏன். இதனால், யார் என்ன செய்கிறார்கள், எந்த கட்டத்தில் திட்டம் உள்ளது என்பது முழு குழுவிற்கும் தெரியும். தேவைப்பட்டால், நமது மதிப்பீடுகள் மற்றும் காலக்கெடுவைக் கணிக்கவும் சரிசெய்யவும் இது நமக்கு வாய்ப்பளிக்கிறது.
  • கூட்டத்தில், குழுத் தலைவர் திட்டத்தில் உள்ள அனைத்து மாற்றங்களையும் வாடிக்கையாளரால் கண்டுபிடிக்கப்படாத தற்போதைய பிழைகளின் அளவையும் அறிவிக்கிறார். அனைத்து பிழைகளும் வரிசைப்படுத்தப்பட்டு அவற்றைத் தீர்க்க ஒவ்வொரு குழு உறுப்பினருக்கும் ஒதுக்கப்படும்.
  • பேரணியில், டெவலப்பர்களின் தற்போதைய பணிச்சுமை, அவர்களின் தொழில்முறை பயிற்சியின் நிலை மற்றும் டெவலப்பர் தற்போது என்ன செய்கிறார் என்பதற்கு ஒரு குறிப்பிட்ட பணியின் அருகாமையை கணக்கில் எடுத்துக்கொண்டு, குழுத் தலைவர் ஒவ்வொன்றிற்கும் பணிகளை ஒதுக்குகிறார்.
  • கூட்டத்தில், குழுத் தலைவர் கட்டிடக்கலை மற்றும் வணிக தர்க்கத்திற்கான பொதுவான உத்தியை உருவாக்குகிறார். அதன் பிறகு, முழு குழுவும் இதைப் பற்றி விவாதித்து, மாற்றங்களைச் செய்யலாமா அல்லது இந்த உத்தியைப் பின்பற்றலாமா என்று முடிவு செய்கிறது.
  • ஒவ்வொரு டெவலப்பரும் குறியீட்டை எழுதுகிறார்கள் மற்றும் ஒரு கட்டிடக்கலை மற்றும் வணிக தர்க்கத்தில் சுயாதீனமாக அல்காரிதம்களை உருவாக்குகிறார்கள். ஒவ்வொருவரும் செயல்படுத்துவது பற்றிய தங்கள் பார்வையை வெளிப்படுத்தலாம், ஆனால் யாரும் யாரையும் இந்த வழியில் செய்ய கட்டாயப்படுத்தவில்லை, இல்லையெனில் அல்ல. ஒவ்வொரு முடிவும் நியாயமானது. ஒரு சிறந்த தீர்வு இருந்தால், ஆனால் இப்போது அதற்கு நேரமில்லை என்றால், குறியீட்டின் ஒரு குறிப்பிட்ட பகுதியை எதிர்காலத்தில் மறுசீரமைப்பதற்காக, கொழுப்பில் ஒரு பணி உருவாக்கப்படுகிறது.
  • ஒரு டெவலப்பர் ஒரு பணியை மேற்கொள்ளும்போது, ​​அவர் அதை வளர்ச்சி நிலைக்கு நகர்த்துகிறார். வாடிக்கையாளருடனான பணியை தெளிவுபடுத்துவது தொடர்பான அனைத்து தகவல்தொடர்புகளும் டெவலப்பரின் தோள்களில் விழுகின்றன. தொழில்நுட்ப கேள்விகளை குழு தலைவர் அல்லது சக ஊழியர்களிடம் கேட்கலாம்.
  • டெவலப்பர் பணியின் சாராம்சத்தை புரிந்து கொள்ளவில்லை என்றால், மற்றும் வாடிக்கையாளர் அதை புத்திசாலித்தனமாக விளக்க முடியவில்லை என்றால், அவர் அடுத்த பணிக்கு செல்கிறார். குழுத் தலைவர் தற்போதைய ஒன்றை எடுத்து வாடிக்கையாளருடன் விவாதிக்கிறார்.
  • ஒவ்வொரு நாளும், டெவலப்பர் கிளையண்டின் அரட்டையில் அவர் நேற்று என்ன பணிகளைச் செய்தார், இன்று என்ன பணிகளைச் செய்வார் என்பதைப் பற்றி எழுத வேண்டும்.
  • பணிப்பாய்வு ஸ்க்ரம் அடிப்படையிலானது. எல்லாம் ஸ்பிரிண்டுகளாக பிரிக்கப்பட்டுள்ளது. ஒவ்வொரு ஸ்பிரிண்ட் இரண்டு வாரங்கள் நீடிக்கும்.
  • ஸ்பிரிண்ட்ஸ் குழுத் தலைவரால் உருவாக்கப்பட்டு, நிரப்பப்பட்டு மூடப்படும்.
  • திட்டத்திற்கு கடுமையான காலக்கெடு இருந்தால், எல்லா பணிகளையும் தோராயமாக மதிப்பிட முயற்சிக்கிறோம். அவர்களிடமிருந்து ஒரு ஸ்பிரிண்ட் சேகரிக்கிறோம். வாடிக்கையாளர் ஸ்பிரிண்டில் கூடுதல் பணிகளைச் சேர்க்க முயற்சித்தால், நாங்கள் முன்னுரிமைகளை அமைத்து, வேறு சில பணிகளை அடுத்த ஸ்பிரிண்டிற்கு மாற்றுவோம்.

b) வாடிக்கையாளருடன் பணிபுரியும் செயல்முறை

  • ஒவ்வொரு டெவலப்பரும் வாடிக்கையாளருடன் தொடர்பு கொள்ள முடியும்
  • வாடிக்கையாளரை விளையாட்டின் சொந்த விதிகளை விதிக்க நீங்கள் அனுமதிக்க முடியாது. நாங்கள் எங்கள் துறையில் வல்லுநர்கள் என்பதை வாடிக்கையாளருக்கு தெளிவுபடுத்துவது கண்ணியமான மற்றும் நட்பான முறையில் அவசியம், மேலும் நாங்கள் மட்டுமே பணி செயல்முறைகளை உருவாக்கி அதில் வாடிக்கையாளரை ஈடுபடுத்த வேண்டும்.
  • எந்தவொரு செயல்பாட்டையும் செயல்படுத்துவதற்கு முன், ஒரு அம்சத்திற்காக (பணிப்பாய்வு) முழு தருக்க செயல்முறையின் பாய்வு விளக்கப்படத்தை உருவாக்குவது அவசியம். மற்றும் உறுதிப்படுத்தலுக்கு வாடிக்கையாளருக்கு அனுப்பவும். இது சிக்கலான மற்றும் வெளிப்படையான செயல்பாட்டிற்கு மட்டுமே பொருந்தும், எடுத்துக்காட்டாக, கட்டண முறை, அறிவிப்பு அமைப்பு போன்றவை. இது வாடிக்கையாளருக்கு என்ன தேவை என்பதை இன்னும் துல்லியமாகப் புரிந்துகொள்ளவும், அம்சத்திற்கான ஆவணங்களைச் சேமிக்கவும், மேலும் வாடிக்கையாளர் அவர் கேட்டதை நாங்கள் செய்யவில்லை என்று எதிர்காலத்தில் கூறக்கூடும் என்பதற்கு எதிராக உங்களை காப்பீடு செய்யவும் அனுமதிக்கும்.
  • அனைத்து வரைபடங்கள்/பாய்வு விளக்கப்படங்கள்/தர்க்கம் போன்றவை. நாங்கள் Confluence/Fat இல் சேமிக்கிறோம், எதிர்காலச் செயலாக்கத்தின் சரியான தன்மையை உறுதிசெய்ய வாடிக்கையாளரிடம் கருத்துக்களில் கேட்கிறோம்.
  • தொழில்நுட்ப விவரங்கள் மூலம் வாடிக்கையாளரை சுமக்காமல் இருக்க முயற்சிக்கிறோம். வாடிக்கையாளர் எப்படி விரும்புகிறார் என்பதைப் பற்றிய புரிதல் நமக்குத் தேவைப்பட்டால், வாடிக்கையாளர் புரிந்து கொள்ளக்கூடிய மற்றும் எல்லாவற்றையும் சரிசெய்ய / மாற்றியமைக்கக்கூடிய ஒரு பாய்வு விளக்கப்படத்தின் வடிவத்தில் பழமையான வழிமுறைகளை வரைவோம்.
  • வாடிக்கையாளர் திட்டத்தில் பிழையைக் கண்டால், அதை ஃபேட்டில் விரிவாக விவரிக்குமாறு கேட்டுக்கொள்கிறோம். சோதனையின் போது வாடிக்கையாளரால் எந்த சூழ்நிலையில் இது நடந்தது, எப்போது, ​​என்ன வரிசை நடவடிக்கைகள் மேற்கொள்ளப்பட்டன. ஸ்கிரீன்ஷாட்களை இணைக்கவும்.
  • டெவ் சர்வரில் வரிசைப்படுத்த ஒவ்வொரு நாளும், அதிகபட்சம் ஒவ்வொரு நாளும் முயற்சி செய்கிறோம். வாடிக்கையாளர் அதன் செயல்பாட்டைச் சோதிக்கத் தொடங்குகிறார், மேலும் திட்டம் செயலற்றதாக இல்லை. அதே நேரத்தில், வாடிக்கையாளருக்கு இந்த திட்டம் முழு வளர்ச்சியில் உள்ளது மற்றும் யாரும் அவருக்கு விசித்திரக் கதைகளைச் சொல்லவில்லை.
  • வாடிக்கையாளர் தனக்கு என்ன தேவை என்பதை முழுமையாக புரிந்து கொள்ளாதது பெரும்பாலும் நிகழ்கிறது. அவர் தனக்கென ஒரு புதிய வணிகத்தை உருவாக்குவதால், இதுவரை பிழைத்திருத்தம் செய்யப்படாத செயல்முறைகளுடன். எனவே, மிகவும் பொதுவான சூழ்நிலை என்னவென்றால், குறியீட்டின் முழுத் துண்டுகளையும் குப்பையில் எறிந்து, பயன்பாட்டு தர்க்கத்தை மறுவடிவமைக்கும் போது. எல்லாவற்றையும் சோதனைகள் மூலம் மறைக்க வேண்டிய அவசியமில்லை என்பது இதிலிருந்து பின்வருமாறு. சோதனைகள் மற்றும் பின்னர் முன்பதிவுகளுடன் முக்கியமான செயல்பாட்டை மட்டும் மறைப்பது அர்த்தமுள்ளதாக இருக்கிறது.
  • நாங்கள் காலக்கெடுவிற்கு பொருந்தவில்லை என்பதை குழு உணரும் சூழ்நிலைகள் உள்ளன. பின்னர் நாங்கள் பணிகளை விரைவாக தணிக்கை செய்கிறோம், உடனடியாக அதைப் பற்றி வாடிக்கையாளருக்கு தெரிவிக்கிறோம். சூழ்நிலையிலிருந்து வெளியேறும் விதமாக, முக்கியமான மற்றும் முக்கியமான செயல்பாட்டை சரியான நேரத்தில் தொடங்கவும், மீதமுள்ளவற்றை வெளியீட்டிற்குப் பின் விட்டுவிடவும் பரிந்துரைக்கிறோம்.
  • வாடிக்கையாளர் தனது தலையில் இருந்து வெவ்வேறு பணிகளைக் கொண்டு வரத் தொடங்கினால், அவரது விரல்களில் கற்பனை செய்து விளக்கத் தொடங்கினால், முழு தளவமைப்பு மற்றும் அதன் கூறுகளின் நடத்தையை முழுமையாக விவரிக்கும் தர்க்கத்துடன் பக்க அமைப்பை எங்களுக்கு வழங்குமாறு அவரிடம் கேட்டுக்கொள்கிறோம்.
  • எந்தவொரு பணியையும் மேற்கொள்வதற்கு முன், இந்த அம்சம் எங்கள் ஒப்பந்தம் / ஒப்பந்தத்தின் விதிமுறைகளில் சேர்க்கப்பட்டுள்ளதா என்பதை உறுதிசெய்ய வேண்டும். இது எங்கள் ஆரம்ப ஒப்பந்தங்களுக்கு அப்பாற்பட்ட ஒரு புதிய அம்சமாக இருந்தால், இந்த அம்சத்தை ((தோராயமான முன்னணி நேரம் + 30%) x 2) கண்டிப்பாக மதிப்பிட்டு, அதை முடிக்க எங்களுக்கு இவ்வளவு நேரம் ஆகும் என்பதை வாடிக்கையாளரிடம் குறிப்பிட வேண்டும், மேலும் காலக்கெடுவை மதிப்பிடும் நேரத்தை இரண்டால் பெருக்கினால் மாற்றப்படும். பணியை விரைவு படுத்துவோம் - அருமை, அனைவரும் இதன் மூலம் மட்டுமே பயனடைவார்கள். இல்லையெனில், நாங்கள் காப்பீடு செய்யப்பட்டுள்ளோம்.

c) அணியில் நாங்கள் ஏற்றுக்கொள்ளாதவை:

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

மேலும் பல கேள்விகள் / ஆய்வறிக்கைகள் சில சமயங்களில் எனது வாடிக்கையாளரிடம் அனைத்து தவறான புரிதல்களையும் நீக்குமாறு கேட்கிறேன்:

  1. உங்கள் தர அளவுகோல்கள் என்ன?
  2. ஒரு திட்டத்தில் சிக்கல்கள் உள்ளதா இல்லையா என்பதை எவ்வாறு தீர்மானிப்பது?
  3. சிஸ்டத்தை மாற்றுவது/மேம்படுத்துவது குறித்த எங்களின் பரிந்துரைகள் மற்றும் ஆலோசனைகள் அனைத்தையும் மீறினால், எல்லா ஆபத்துகளையும் நீங்கள் மட்டுமே ஏற்கிறீர்கள்
  4. எந்தவொரு பெரிய திட்ட மாற்றங்களும் (உதாரணமாக, அனைத்து வகையான கூடுதல் ஓட்டம்) பிழைகள் சாத்தியமான தோற்றத்திற்கு வழிவகுக்கும் (நிச்சயமாக, நாங்கள் அதை சரிசெய்வோம்)
  5. திட்டத்தில் என்ன வகையான சிக்கல் ஏற்பட்டது என்பதை ஓரிரு நிமிடங்களுக்குள் புரிந்து கொள்ள முடியாது, மேலும் அதை அங்கேயே சரிசெய்வது
  6. நாங்கள் ஒரு குறிப்பிட்ட தயாரிப்பு ஓட்டத்தில் வேலை செய்கிறோம் (ஜிராவில் பணிகள் - மேம்பாடு - சோதனை - வரிசைப்படுத்துதல்). அரட்டையில் உள்ள கோரிக்கைகள் மற்றும் புகார்களின் முழு ஓட்டத்திற்கும் எங்களால் பதிலளிக்க முடியாது என்பதே இதன் பொருள்.
  7. புரோகிராமர்கள் வெறும் புரோகிராமர்கள், தொழில்முறை சோதனையாளர்கள் அல்ல, மேலும் திட்டச் சோதனையின் சரியான தரத்தை உறுதிப்படுத்த முடியாது
  8. இறுதிச் சோதனைக்கான பொறுப்பு மற்றும் விற்பனையில் பணிகளை ஏற்றுக்கொள்வது முற்றிலும் உங்களுடையது
  9. நாங்கள் ஏற்கனவே ஒரு பணியை மேற்கொண்டிருந்தால், தற்போதைய ஒன்றை முடிக்கும் வரை உடனடியாக மற்றவர்களுக்கு மாற முடியாது (இல்லையெனில் இது இன்னும் அதிகமான பிழைகள் மற்றும் வளர்ச்சி நேரத்தை அதிகரிக்க வழிவகுக்கிறது)
  10. குழுவில் குறைவான நபர்கள் உள்ளனர் (விடுமுறைகள் அல்லது நோய்கள் காரணமாக), மேலும் அதிக வேலை உள்ளது, மேலும் நீங்கள் விரும்பும் அனைத்திற்கும் பதிலளிக்க எங்களுக்கு நேரமில்லை.
  11. டெவெலப்பில் சோதிக்கப்பட்ட பணிகள் இல்லாமல் தயாரிப்பில் ஈடுபட உங்களைக் கேட்பது உங்கள் ஆபத்து மட்டுமே, டெவலப்பர் அல்ல
  12. நீங்கள் தெளிவற்ற பணிகளை அமைக்கும் போது, ​​சரியான ஓட்டம் இல்லாமல், வடிவமைப்பு தளவமைப்புகள் இல்லாமல், இதற்கு எங்களிடமிருந்து அதிக முயற்சி மற்றும் செயலாக்க நேரம் தேவைப்படுகிறது, ஏனெனில் உங்களுக்குப் பதிலாக நாங்கள் கூடுதல் வேலைகளைச் செய்ய வேண்டும்.
  13. பிழைகள் பற்றிய எந்தப் பணிகளும், அவற்றின் நிகழ்வு மற்றும் ஸ்கிரீன்ஷாட்கள் பற்றிய விரிவான விளக்கம் இல்லாமல், என்ன தவறு நடந்தது மற்றும் இந்தப் பிழையை எவ்வாறு வெளியிடலாம் என்பதைப் புரிந்துகொள்ள எங்களுக்கு வாய்ப்பளிக்காது.
  14. செயல்திறன் மற்றும் பாதுகாப்பை மேம்படுத்த திட்டத்திற்கு நிலையான சுத்திகரிப்பு மற்றும் மேம்பாடுகள் தேவை. எனவே, இந்த மேம்பாடுகளுக்காக அணி தனது நேரத்தைச் செலவிடுகிறது.
  15. எங்களிடம் கூடுதல் நேர வேலை நேரம் (அவசர திருத்தங்கள்) இருப்பதால், மற்ற நாட்களில் அவற்றை ஈடுகட்ட வேண்டும்.

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

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

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

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

என் உள்ள ஆதாரம் வலைப்பதிவு இடுகை.

ஆதாரம்: www.habr.com