ഒരു ടീമിലെ വൈരുദ്ധ്യ മാനേജ്മെന്റ് - ഒരു ബാലൻസിങ് ആക്ട് അല്ലെങ്കിൽ ഒരു സുപ്രധാന ആവശ്യകത?

എപ്പിഗ്രാഫ്:
ഒരിക്കൽ, മുള്ളൻപന്നിയും ചെറിയ കരടിയും കാട്ടിൽ കണ്ടുമുട്ടി.
- ഹലോ, മുള്ളൻപന്നി!
- ഹലോ, ലിറ്റിൽ ബിയർ!
അങ്ങനെ, വാക്കിന് വാക്കിന്, തമാശയ്ക്ക്, മുള്ളൻപന്നിയുടെ മുഖത്ത് ലിറ്റിൽ ബിയർ അടിച്ചു ...

ജോലി വൈരുദ്ധ്യങ്ങളുടെ പ്രത്യേകതകളെക്കുറിച്ചും അവ കൈകാര്യം ചെയ്യുന്നതിനുള്ള സാധ്യമായ രീതികളെക്കുറിച്ചും ഞങ്ങളുടെ ടീം ലീഡറിൽ നിന്നും RAS പ്രൊഡക്റ്റ് ഡെവലപ്‌മെന്റ് ഡയറക്ടർ ഇഗോർ മർനാറ്റിൽ നിന്നുമുള്ള ഒരു ചർച്ച ചുവടെയുണ്ട്.

ജോലിസ്ഥലത്ത് ഞങ്ങൾ നേരിടുന്ന മിക്ക വൈരുദ്ധ്യങ്ങളും മുകളിലെ എപ്പിഗ്രാഫിൽ വിവരിച്ചതിന് സമാനമായ ഒരു സാഹചര്യത്തിനനുസരിച്ച് വികസിക്കുന്നു. തുടക്കത്തിൽ പരസ്പരം അനുകൂലമായി പെരുമാറുന്ന നിരവധി പങ്കാളികളുണ്ട്; അവർ ചില പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ ശ്രമിക്കുന്നു, പക്ഷേ അവസാനം പ്രശ്നം പരിഹരിക്കപ്പെടാതെ തുടരുന്നു, ചില കാരണങ്ങളാൽ ചർച്ചയിൽ പങ്കെടുക്കുന്നവർ തമ്മിലുള്ള ബന്ധം വഷളായി.

ജീവിതം വൈവിധ്യപൂർണ്ണമാണ്, മുകളിൽ വിവരിച്ച സാഹചര്യത്തിൽ വ്യതിയാനങ്ങൾ സംഭവിക്കുന്നു. ചിലപ്പോൾ പങ്കാളികൾ തമ്മിലുള്ള ബന്ധം തുടക്കത്തിൽ അത്ര നല്ലതല്ല, ചിലപ്പോൾ നേരിട്ട് പരിഹാരം ആവശ്യമുള്ള ഒരു പ്രശ്നം പോലും ഉണ്ടാകില്ല (ഉദാഹരണത്തിന്, എപ്പിഗ്രാഫിൽ), ചിലപ്പോൾ ചർച്ചയ്ക്ക് ശേഷവും ബന്ധം ആരംഭിക്കുന്നതിന് മുമ്പുള്ളതുപോലെ തന്നെ തുടരും, പക്ഷേ ആത്യന്തികമായി പ്രശ്നം പരിഹരിച്ചിട്ടില്ല.

ജോലി വൈരുദ്ധ്യത്തിന്റെ ഒരു സാഹചര്യം എന്ന് നിർവചിക്കാവുന്ന എല്ലാ സാഹചര്യങ്ങളിലും പൊതുവായുള്ളത് എന്താണ്?



ഒന്നാമതായി, രണ്ടോ അതിലധികമോ വശങ്ങളുണ്ട്. ഈ കക്ഷികൾക്ക് ഓർഗനൈസേഷനിൽ വ്യത്യസ്ത സ്ഥലങ്ങൾ കൈവശം വയ്ക്കാനും സമത്വ ബന്ധത്തിലാകാനും (ഒരു ടീമിലെ സഹപ്രവർത്തകർ), അല്ലെങ്കിൽ ശ്രേണിയുടെ വിവിധ തലങ്ങളിൽ (ബോസ് - കീഴ്വഴക്കം), വ്യക്തി (തൊഴിലാളി) അല്ലെങ്കിൽ ഗ്രൂപ്പ് (ഒരു വ്യക്തിക്ക് ഇടയിൽ സംഘർഷമുണ്ടായാൽ) ആകാം. ജീവനക്കാരനും ഒരു ടീമും അല്ലെങ്കിൽ രണ്ട് ടീമുകളും), തുടങ്ങിയവ. സംഘട്ടനത്തിന്റെ സാധ്യതയും അതിന്റെ പരിഹാരത്തിന്റെ എളുപ്പവും പങ്കാളികൾ തമ്മിലുള്ള വിശ്വാസത്തിന്റെ നിലവാരത്തെ വളരെയധികം സ്വാധീനിക്കുന്നു. കക്ഷികൾ പരസ്പരം നന്നായി അറിയുന്നു, വിശ്വാസ്യതയുടെ നിലവാരം ഉയർന്നതാണ്, അവർ ഒരു കരാറിലെത്താനുള്ള സാധ്യത കൂടുതലാണ്. ഉദാഹരണത്തിന്, ഒരിക്കലും മുഖാമുഖം ഇടപഴകാത്ത ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് ടീമിലെ അംഗങ്ങൾ, ചുരുങ്ങിയത് കുറച്ച് മുഖാമുഖം ഇടപഴകിയ ആളുകളേക്കാൾ ലളിതമായ ഒരു ജോലി പ്രശ്നത്തിൽ സംഘർഷം ഉണ്ടാകാനുള്ള സാധ്യത കൂടുതലാണ്. അതിനാൽ, വിതരണം ചെയ്ത ടീമുകളിൽ പ്രവർത്തിക്കുമ്പോൾ, എല്ലാ ടീം അംഗങ്ങളും ഇടയ്ക്കിടെ പരസ്പരം കണ്ടുമുട്ടുന്നത് ഉറപ്പാക്കേണ്ടത് വളരെ പ്രധാനമാണ്.

രണ്ടാമതായി, ജോലിസ്ഥലത്ത് സംഘട്ടനത്തിന്റെ സാഹചര്യത്തിൽ, ഒരു കക്ഷിക്ക്, ഇരുവർക്കും അല്ലെങ്കിൽ സംഘടനയ്ക്ക് മൊത്തത്തിൽ പ്രധാനപ്പെട്ട ചില പ്രശ്‌നങ്ങൾ പരിഹരിക്കാനുള്ള സാഹചര്യത്തിലാണ് കക്ഷികൾ. അതേസമയം, സാഹചര്യത്തിന്റെ പ്രത്യേകതകൾ കാരണം, കക്ഷികൾക്ക് സാധാരണയായി അത് പരിഹരിക്കാൻ മതിയായ സമയവും വൈവിധ്യമാർന്ന വഴികളും ഉണ്ട് (ഔപചാരിക, അനൗപചാരിക, മീറ്റിംഗുകൾ, കത്തുകൾ, മാനേജ്മെന്റ് തീരുമാനങ്ങൾ, ടീമിന്റെ ലക്ഷ്യങ്ങളുടെയും പദ്ധതികളുടെയും സാന്നിധ്യം, ഒരു ശ്രേണിയുടെ വസ്തുത മുതലായവ). ഒരു ഓർഗനൈസേഷനിലെ ഒരു ജോലി (അല്ലെങ്കിൽ ജോലി ചെയ്യാത്ത) പ്രശ്നം പരിഹരിക്കുന്ന സാഹചര്യത്തിൽ നിന്ന് ഇത് വ്യത്യസ്തമാണ്, ഉദാഹരണത്തിന്, ഒരു പ്രധാന ചോദ്യം പരിഹരിക്കൽ: "ഏയ്, കുട്ടി, നിങ്ങൾ ഏത് മേഖലയിലാണ്?!" തെരുവിൽ, അല്ലെങ്കിൽ എപ്പിഗ്രാഫിൽ നിന്നുള്ള സംഘർഷം. ഒരു ജോലി പ്രശ്നം പരിഹരിക്കുന്ന കാര്യത്തിൽ, ജോലി പ്രക്രിയയുടെ ഗുണനിലവാരം, ടീം വിഷയത്തിൽ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള സംസ്കാരം.

മൂന്നാമതായി, സംഘട്ടനത്തിന്റെ നിർണ്ണായക ഘടകം (ഞങ്ങളുടെ ചർച്ചയുടെ വീക്ഷണകോണിൽ നിന്ന്) പ്രക്രിയയിലെ കക്ഷികൾക്ക് എല്ലാ കക്ഷികൾക്കും അനുയോജ്യമായ പ്രശ്നത്തിന് സ്വതന്ത്രമായി ഒരു പരിഹാരത്തിലേക്ക് വരാൻ കഴിയില്ല എന്നതാണ്. സാഹചര്യത്തിന് ഒരു മൂന്നാം കക്ഷിയുടെ ഇടപെടൽ ആവശ്യമാണ്, ഒരു ബാഹ്യ മദ്ധ്യസ്ഥൻ. ഈ പോയിന്റ് വിവാദമായി തോന്നാം, പക്ഷേ, ചുരുക്കത്തിൽ, ഒരു ബാഹ്യ മദ്ധ്യസ്ഥന്റെ ഇടപെടലില്ലാതെ സംഘർഷ സാഹചര്യം വിജയകരമായി പരിഹരിച്ചാൽ, പ്രശ്നം വിജയകരമായി പരിഹരിച്ചു, കക്ഷികളുടെ ബന്ധം വഷളായില്ല, ഇതാണ് നമ്മൾ പരിശ്രമിക്കേണ്ട സാഹചര്യം. . അത്തരമൊരു വൈരുദ്ധ്യത്തെക്കുറിച്ച് ഞങ്ങൾക്ക് മിക്കവാറും അറിയില്ല, അല്ലെങ്കിൽ അത് പരിഹരിച്ചതിന് ശേഷം ഞങ്ങൾ ആകസ്മികമായി കണ്ടെത്തും. ഒരു ടീമിന് സ്വന്തമായി പരിഹരിക്കാൻ കഴിയുന്ന കൂടുതൽ പ്രശ്നങ്ങൾ, അത് കൂടുതൽ ഫലപ്രദമാകും.

സംഘർഷത്തിന്റെ മറ്റൊരു സവിശേഷത സ്പർശിക്കേണ്ടതാണ്, തീരുമാനത്തിലെ വൈകാരിക തീവ്രതയുടെ അളവാണ്. സംഘർഷം ഉയർന്ന വൈകാരിക തലവുമായി ബന്ധപ്പെട്ടിരിക്കണമെന്നില്ല. സാരാംശത്തിൽ, ഒരു സംഘട്ടനമാകാൻ, പങ്കെടുക്കുന്നവർ നിലവിളിക്കുകയും കൈകൾ വീശുകയും ചെയ്യേണ്ടതില്ല. പ്രശ്നം പരിഹരിച്ചിട്ടില്ല, ഒരു പ്രത്യേക വൈകാരിക പിരിമുറുക്കം നിലവിലുണ്ട് (ഒരുപക്ഷേ അത് ബാഹ്യമായി പ്രകടിപ്പിക്കുന്നില്ല), അതിനർത്ഥം ഞങ്ങൾ ഒരു സംഘട്ടന സാഹചര്യത്തെ അഭിമുഖീകരിക്കുന്നു എന്നാണ്.

സംഘർഷസാഹചര്യങ്ങളിൽ ഇടപെടേണ്ടത് ആവശ്യമാണോ, അതോ അവരുടെ പ്രമേയം അതിന്റെ ഗതി സ്വീകരിക്കാൻ അനുവദിക്കുകയും പ്രശ്നം സ്വയം പരിഹരിക്കപ്പെടുന്നതുവരെ കാത്തിരിക്കുകയും ചെയ്യുന്നതാണോ നല്ലത്? വേണം. പൊരുത്തക്കേട് പൂർണ്ണമായും പരിഹരിക്കുന്നത് എല്ലായ്പ്പോഴും നിങ്ങളുടെ ശക്തിയിലോ കഴിവിലോ അല്ല, എന്നാൽ ഏത് സാഹചര്യത്തിലും, ഏത് സ്കെയിലിലെയും വൈരുദ്ധ്യത്തിൽ, നിങ്ങൾക്ക് പ്രായപൂർത്തിയായ ഒരു സ്ഥാനം എടുക്കാം, അതുവഴി നിങ്ങൾക്ക് ചുറ്റുമുള്ള നിരവധി ആളുകളെ അതിലേക്ക് കൊണ്ടുവരിക, പ്രതികൂലമായ പ്രത്യാഘാതങ്ങൾ ലഘൂകരിക്കുക. പൊരുത്തക്കേടും അതിന്റെ പരിഹാരത്തിന് സംഭാവന നൽകുകയും ചെയ്യുന്നു.

സംഘർഷ സാഹചര്യങ്ങളുടെ ഏതാനും ഉദാഹരണങ്ങൾ നോക്കുന്നതിന് മുമ്പ്, എല്ലാ വൈരുദ്ധ്യങ്ങൾക്കും പൊതുവായുള്ള ചില പ്രധാന പോയിന്റുകൾ നോക്കാം.

ഒരു വൈരുദ്ധ്യം പരിഹരിക്കുമ്പോൾ, പോരാട്ടത്തിന് മുകളിലായിരിക്കേണ്ടത് പ്രധാനമാണ്, അതിനുള്ളിലല്ല (ഇതിനെ "മെറ്റാ-പൊസിഷൻ" എന്നും വിളിക്കുന്നു), അതായത്, പരിഹാര പ്രക്രിയയിലെ കക്ഷികളിൽ ഒരാളുടെ ഭാഗമാകരുത്. അല്ലാത്തപക്ഷം, തീരുമാനത്തെ സഹായിക്കാൻ ഒരു ബാഹ്യ മദ്ധ്യസ്ഥൻ ഉണ്ടായിരിക്കുന്നത് മറ്റേ കക്ഷിക്ക് ദോഷം വരുത്തുന്ന ഒരു കക്ഷിയുടെ സ്ഥാനം ശക്തിപ്പെടുത്തും. ഒരു തീരുമാനം എടുക്കുമ്പോൾ, അത് എല്ലാ കക്ഷികളും ധാർമ്മികമായി അംഗീകരിക്കേണ്ടത് പ്രധാനമാണ്, അവർ പറയുന്നതുപോലെ, "വാങ്ങി". അതിനാൽ, എടുത്ത തീരുമാനത്തിൽ പാർട്ടികൾക്ക് സന്തോഷമില്ലെങ്കിലും, അത് നടപ്പിലാക്കാൻ അവർ ആത്മാർത്ഥമായി സമ്മതിച്ചു. അവർ പറയുന്നതുപോലെ, വിയോജിക്കാനും പ്രതിബദ്ധത പുലർത്താനും കഴിയും. അല്ലാത്തപക്ഷം, സംഘർഷം അതിന്റെ രൂപം മാറ്റും, പുകയുന്ന തീ തത്വം ചതുപ്പിനു കീഴിൽ നിലനിൽക്കും, ഒരു ഘട്ടത്തിൽ അനിവാര്യമായും വീണ്ടും ജ്വലിക്കും.

രണ്ടാമത്തെ കാര്യം, ആദ്യത്തേതുമായി ഭാഗികമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, പൊരുത്തക്കേട് പരിഹരിക്കുന്നതിൽ പങ്കെടുക്കാൻ നിങ്ങൾ ഇതിനകം തീരുമാനിച്ചിട്ടുണ്ടെങ്കിൽ, ആശയവിനിമയത്തിന്റെയും സന്ദർഭം പഠിക്കുന്നതിന്റെയും വീക്ഷണകോണിൽ നിന്ന് കഴിയുന്നത്ര ഗൗരവമായി എടുക്കുക എന്നതാണ്. ഓരോ കക്ഷികളുമായും വ്യക്തിപരമായി സംസാരിക്കുക. ഓരോന്നിനും വെവ്വേറെ, തുടക്കക്കാർക്കായി. മെയിലിൽ തളരരുത്. ഒരു വിതരണം ചെയ്ത ടീമിന്റെ കാര്യത്തിൽ, വീഡിയോ ലിങ്ക് വഴിയെങ്കിലും സംസാരിക്കുക. കേട്ടുകേൾവികളും ദൃക്‌സാക്ഷി റിപ്പോർട്ടുകളും കൊണ്ട് തൃപ്തിപ്പെടരുത്. കഥ മനസ്സിലാക്കുക, ഓരോ കക്ഷിയും എന്താണ് ആഗ്രഹിക്കുന്നത്, അവർക്ക് അത് എന്തിനാണ്, അവർ എന്താണ് പ്രതീക്ഷിക്കുന്നത്, അവർ ഈ പ്രശ്നം പരിഹരിക്കാൻ മുമ്പ് ശ്രമിച്ചിട്ടുണ്ടോ, അത് പരിഹരിച്ചില്ലെങ്കിൽ എന്ത് സംഭവിക്കും, എന്ത് പരിഹാരങ്ങളാണ് അവർ കാണുന്നത്, അവരുടെ സ്ഥാനം എങ്ങനെ സങ്കൽപ്പിക്കുന്നു മറുവശത്ത്, അവർ എന്താണ് ചിന്തിക്കുന്നത്, ശരിയോ തെറ്റോ മുതലായവ. എല്ലാവരും ശരിയാണെന്ന് കരുതി, തുറന്ന മനസ്സോടെ സാധ്യമായ എല്ലാ സന്ദർഭങ്ങളും നിങ്ങളുടെ തലയിൽ കയറ്റുക. നിങ്ങൾ സംഘട്ടനത്തിനുള്ളിലല്ല, നിങ്ങൾ അതിന് പുറത്താണ്, ഒരു രൂപാന്തരത്തിലാണ്. സന്ദർഭം ഒരു പോസ്റ്റ് ത്രെഡിൽ മാത്രമേ ലഭ്യമാണെങ്കിൽ, ചുരുങ്ങിയത് അത് മുഴുവനായും അതുമായി ബന്ധപ്പെട്ട ത്രെഡുകളും രേഖകളും വായിക്കുക. നിങ്ങൾ അത് വായിച്ചതിനുശേഷം, നിങ്ങളുടെ ശബ്ദത്തിൽ സംസാരിക്കുക. മെയിലിൽ ഇല്ലാത്ത പ്രധാനപ്പെട്ട എന്തെങ്കിലും നിങ്ങൾ കേൾക്കുമെന്ന് ഏതാണ്ട് ഉറപ്പാണ്.

മൂന്നാമത്തെ പ്രധാന കാര്യം ആശയവിനിമയത്തിനുള്ള പൊതു സമീപനമാണ്. ഇവ സാധാരണ കാര്യങ്ങളാണ്, കോസ്മിക് ഒന്നുമില്ല, പക്ഷേ അവ വളരെ പ്രധാനമാണ്. ഞങ്ങൾ സമയം ലാഭിക്കാൻ ശ്രമിക്കുന്നില്ല, പങ്കെടുക്കുന്ന എല്ലാവരുമായും ഞങ്ങൾ സംസാരിക്കുന്നു, ഞങ്ങൾ വ്യക്തിയെ വിമർശിക്കുന്നില്ല, പക്ഷേ അവന്റെ പ്രവർത്തനങ്ങളുടെ അനന്തരഫലങ്ങൾ ഞങ്ങൾ പരിഗണിക്കുന്നു (“നിങ്ങൾ പരുഷമായി” അല്ല, പക്ഷേ “ഒരുപക്ഷേ ആൺകുട്ടികൾ അസ്വസ്ഥരായേക്കാം. ഈ കാര്യം”), മുഖം രക്ഷിക്കാൻ ഞങ്ങൾ അവസരം നൽകുന്നു, ഞങ്ങൾ വ്യക്തിപരമായി ചർച്ചകൾ നടത്തുന്നു, വരിയുടെ മുന്നിലല്ല.

സാധാരണയായി രണ്ട് കാരണങ്ങളിൽ ഒന്ന് കൊണ്ടാണ് സംഘർഷങ്ങൾ ഉണ്ടാകുന്നത്. സംഘട്ടനസമയത്ത് ഒരു വ്യക്തി മുതിർന്നയാളുടെ സ്ഥാനത്താണോ അതോ കുട്ടിയുടെ സ്ഥാനത്താണോ എന്നതുമായി ബന്ധപ്പെട്ടതാണ് ആദ്യത്തേത് (ഇതിൽ കൂടുതൽ താഴെ). ഇത് അവന്റെ വൈകാരിക പക്വത, അവന്റെ വികാരങ്ങൾ കൈകാര്യം ചെയ്യാനുള്ള കഴിവ് എന്നിവ മൂലമാണ് (അത്, എല്ലായ്പ്പോഴും അവന്റെ പ്രായവുമായി ബന്ധപ്പെട്ടതല്ല). രണ്ടാമത്തെ പൊതു കാരണം, ജോലി പ്രക്രിയയുടെ അപൂർണ്ണതയാണ്, ഇത് ചാരനിറത്തിലുള്ള പ്രദേശങ്ങളുടെ സാഹചര്യങ്ങൾ സൃഷ്ടിക്കുന്നു, അതിൽ പങ്കെടുക്കുന്നവർക്കിടയിൽ ഉത്തരവാദിത്തം വ്യാപിക്കുന്നു, കക്ഷികളുടെ പ്രതീക്ഷകൾ പരസ്പരം സുതാര്യമല്ല, പ്രക്രിയയിലെ റോളുകൾ മങ്ങുന്നു.

അതനുസരിച്ച്, ഒരു വൈരുദ്ധ്യം (അതുപോലെ മറ്റേതൊരു പ്രശ്‌നവും) പരിഹരിക്കുമ്പോൾ, മാനേജർ മൂന്ന് വീക്ഷണങ്ങൾ മനസ്സിൽ സൂക്ഷിക്കണം: ഹ്രസ്വകാല - ഇവിടെയും ഇപ്പോഴുമുള്ള പ്രശ്നം/സംഘർഷം പരിഹരിക്കാൻ, ഇടത്തരം - മറ്റൊരു സംഘർഷം ഉണ്ടാകാനുള്ള സാധ്യത കുറയ്ക്കുന്നതിന്. അതേ കാരണത്താൽ, ദീർഘകാലം - ടീം വ്യക്തിയിൽ മുതിർന്നവരുടെ സംസ്കാരം വളർത്തിയെടുക്കാൻ.

നമ്മിൽ ഓരോരുത്തർക്കും ഏകദേശം മൂന്നോ നാലോ വയസ്സുള്ള ഒരു ആന്തരിക കുട്ടിയുണ്ട്. ജോലിസ്ഥലത്ത് അവൻ മിക്ക സമയത്തും ഉറങ്ങുന്നു, പക്ഷേ ചിലപ്പോൾ ഉണരുകയും നിയന്ത്രണം ഏറ്റെടുക്കുകയും ചെയ്യുന്നു. കുട്ടിക്ക് അവരുടേതായ മുൻഗണനകളുണ്ട്. ഇതാണ് അവന്റെ സാൻഡ്‌ബോക്‌സ്, അവന്റെ അമ്മ അവനെ കൂടുതൽ സ്നേഹിക്കുന്നു, അവന്റെ മെഷീൻ മികച്ചതാണ് (ഡിസൈൻ മികച്ചതാണ്, അവൻ മികച്ചതാണ്, ...) എന്ന് നിർബന്ധം പിടിക്കേണ്ടത് പ്രധാനമാണ്. ഒരു സംഘട്ടന സാഹചര്യത്തിൽ, ഒരു കുട്ടിക്ക് കളിപ്പാട്ടങ്ങൾ അമർത്താനും കാലുകൾ ചവിട്ടാനും സ്പാറ്റുല പൊട്ടിക്കാനും കഴിയും, എന്നാൽ മുതിർന്നവരുടെ പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ അവന് കഴിയില്ല (പരിഹാര വാസ്തുവിദ്യ, യാന്ത്രിക പരിശോധനയ്ക്കുള്ള സമീപനങ്ങൾ, റിലീസ് തീയതികൾ മുതലായവ), അവൻ ആനുകൂല്യങ്ങളുടെ കാര്യത്തിൽ ചിന്തിക്കുന്നില്ല. ടീമിനായി. സംഘട്ടനത്തിലായ കുട്ടിയെ പ്രോത്സാഹിപ്പിക്കുകയും ആശ്വസിപ്പിക്കുകയും അവന്റെ മുതിർന്നവരെ വിളിക്കാൻ ആവശ്യപ്പെടുകയും ചെയ്യാവുന്നതാണ്. ഒരു സംഘട്ടന സാഹചര്യത്തിൽ ഒരു ചർച്ച ആരംഭിക്കുന്നതിന് മുമ്പ്, നിങ്ങൾ ഒരു മുതിർന്നയാളോടാണ് സംസാരിക്കുന്നതെന്ന് ഉറപ്പുവരുത്തുക, ഒരു കുട്ടിയല്ല, നിങ്ങൾ തന്നെ മുതിർന്നയാളുടെ സ്ഥാനത്താണ്. ഗുരുതരമായ ഒരു പ്രശ്നം പരിഹരിക്കുക എന്നതാണ് നിങ്ങളുടെ സത്യസന്ധമായ ലക്ഷ്യമെങ്കിൽ, നിങ്ങൾ ഒരു മുതിർന്ന വ്യക്തിയുടെ സ്ഥാനത്താണ്. നിങ്ങളുടെ പാദങ്ങൾ ചവിട്ടി, തോളിൽ ബ്ലേഡ് പൊട്ടിക്കുക എന്നതാണ് നിങ്ങളുടെ ലക്ഷ്യമെങ്കിൽ, ഇത് ഒരു ബാലിശമായ സ്ഥാനമാണ്. നിങ്ങളുടെ ഉള്ളിലെ കുട്ടിയെ കിടക്കയിലേക്ക് അയച്ച് മുതിർന്ന ഒരാളെ വിളിക്കുക, അല്ലെങ്കിൽ ചർച്ച വീണ്ടും ഷെഡ്യൂൾ ചെയ്യുക. ഒരു വ്യക്തി വൈകാരികമായ ഒരു തീരുമാനം എടുക്കുന്നു, തുടർന്ന് അതിന് യുക്തിസഹമായ ന്യായീകരണത്തിനായി നോക്കുന്നു. കുട്ടികളുടെ മുൻഗണനകളെ അടിസ്ഥാനമാക്കി ഒരു കുട്ടി എടുക്കുന്ന തീരുമാനം ഒപ്റ്റിമൽ ആയിരിക്കില്ല.

സംഘട്ടനസമയത്ത് പെരുമാറ്റത്തിന് പുറമേ, ഒരു വ്യക്തി സ്വയം ഏറ്റെടുക്കാൻ തയ്യാറായ ഉത്തരവാദിത്തത്തിന്റെ നിലവാരവും കുട്ടിയുടെയോ മുതിർന്നവരുടെയോ സ്ഥാനത്തിന്റെ സവിശേഷതയാണ്. അതിന്റെ അങ്ങേയറ്റത്തെ പ്രകടനങ്ങളിൽ, ഞാൻ ഒന്നിലധികം തവണ കണ്ടുമുട്ടിയ ഒരു പ്രോഗ്രാമറുടെ ബാലിശമായ സ്ഥാനം ഇതുപോലെ കാണപ്പെടുന്നു: ഞാൻ കോഡ് എഴുതി, അവലോകനത്തിനായി അയച്ചു - എന്റെ ജോലി പൂർത്തിയായി. നിരൂപകർ അത് അവലോകനം ചെയ്ത് അംഗീകരിക്കണം, QA ഇത് പരിശോധിക്കണം, പ്രശ്‌നങ്ങളുണ്ടെങ്കിൽ, അവർ എന്നെ അറിയിക്കും. വിചിത്രമെന്നു പറയട്ടെ, വളരെ പക്വതയുള്ളവരും പരിചയസമ്പന്നരുമായ ആളുകൾ പോലും ചിലപ്പോൾ ഈ രീതിയിൽ പെരുമാറുന്നു. സ്കെയിലിന്റെ മറുവശം, ഒരു വ്യക്തി തന്റെ കോഡ് പ്രവർത്തിക്കുന്നുവെന്നും, ടെസ്റ്റുകൾ മുഖേനയുള്ളതാണെന്നും, അവൻ വ്യക്തിപരമായി പരിശോധിച്ചിട്ടുണ്ടെന്നും, അവലോകനം വിജയകരമായി വിജയിച്ചുവെന്നും ഉറപ്പുവരുത്തുന്നതിന് സ്വയം ഉത്തരവാദിയാണെന്ന് കരുതുന്നു (ആവശ്യമെങ്കിൽ, റിവ്യൂവർമാരെ പിംഗ് ചെയ്യുന്നതിനും പ്രശ്നങ്ങൾ ചർച്ച ചെയ്യുന്നതിനും ഒരു പ്രശ്നവുമില്ല. വോയ്‌സ്, മുതലായവ) കൂടാതെ അടിച്ചമർത്തപ്പെട്ടു , ആവശ്യമെങ്കിൽ QA സഹായം നൽകും, ടെസ്റ്റ് സാഹചര്യങ്ങൾ വിവരിക്കും തുടങ്ങിയവ. സാധാരണ സന്ദർഭങ്ങളിൽ, പ്രോഗ്രാമർ ഒന്നുകിൽ സ്കെയിലിന്റെ മുതിർന്നവരുടെ അറ്റത്തോട് അടുത്ത് തുടങ്ങുന്നു, അല്ലെങ്കിൽ അനുഭവം നേടുന്നതിനനുസരിച്ച് അവിടേക്ക് നീങ്ങുന്നു (ടീമിനുള്ളിൽ ശരിയായ സംസ്കാരം വളർത്തിയെടുത്താൽ). അങ്ങേയറ്റത്തെ സന്ദർഭങ്ങളിൽ, അവൻ ജോലിയിൽ തുടരുന്നു, സാധാരണയായി ബാലിശമായ സ്ഥാനം എടുക്കുന്നു, തുടർന്ന് അവനും ടീമിനും ഇടയ്ക്കിടെ പ്രശ്നങ്ങളും പൊരുത്തക്കേടുകളും ഉണ്ട്.

ഒരു ടീമിൽ ശരിയായതും പക്വതയാർന്നതുമായ സംസ്കാരം വളർത്തിയെടുക്കുക എന്നത് ഏതൊരു മാനേജർക്കും ഒരു പ്രധാന കടമയാണ്. ഇതിന് വളരെയധികം സമയവും ദൈനംദിന പരിശ്രമവും ആവശ്യമാണ്, പക്ഷേ ഫലം അത് വിലമതിക്കുന്നു. ടീം സംസ്കാരത്തെ സ്വാധീനിക്കാൻ രണ്ട് വഴികളുണ്ട് - ഉദാഹരണത്തിലൂടെ നയിക്കുക (അത് തീർച്ചയായും പിന്തുടരും; ടീം എല്ലായ്പ്പോഴും നേതാവിലേക്ക് നോക്കുന്നു) ശരിയായ പെരുമാറ്റം ചർച്ച ചെയ്യുകയും പ്രതിഫലം നൽകുകയും ചെയ്യുക. ഇവിടെയും അസംബന്ധമോ വളരെ ഔപചാരികമോ ഒന്നുമില്ല, പ്രശ്‌നങ്ങൾ ചർച്ച ചെയ്യുമ്പോൾ, ഇവിടെ എന്തെങ്കിലും ചെയ്യാൻ കഴിയുമായിരുന്നുവെന്ന് ശ്രദ്ധിക്കുക, അത് ശരിയായി തീരുമാനിച്ചപ്പോൾ നിങ്ങൾ ശ്രദ്ധിച്ചുവെന്ന് ഊന്നിപ്പറയുക, പ്രശംസിക്കുക, റിലീസ് അവലോകന സമയത്ത് ശ്രദ്ധിക്കുക തുടങ്ങിയവ.

ലളിതവും സങ്കീർണ്ണവുമായ നിരവധി സാധാരണ സംഘർഷ സാഹചര്യങ്ങൾ നമുക്ക് പരിഗണിക്കാം:

ജോലി പ്രശ്നങ്ങളുമായി ബന്ധമില്ലാത്ത വൈരുദ്ധ്യങ്ങൾ

പലപ്പോഴും ജോലി പ്രശ്നങ്ങളുമായി ബന്ധമില്ലാത്ത ജോലിയിൽ വൈരുദ്ധ്യങ്ങൾ ഉണ്ടാകാറുണ്ട്. അവ സംഭവിക്കുന്നതും പരിഹരിക്കാനുള്ള എളുപ്പവും സാധാരണയായി പങ്കെടുക്കുന്നവരുടെ വൈകാരിക ബുദ്ധിയുടെ നിലവാരം, അവരുടെ പക്വതയുടെ നിലവാരം എന്നിവയുമായി നേരിട്ട് ബന്ധപ്പെട്ടിരിക്കുന്നു, മാത്രമല്ല ജോലി പ്രക്രിയയുടെ പൂർണതയുമായോ അപൂർണ്ണതയുമായോ ബന്ധപ്പെട്ടിട്ടില്ല.

സാധാരണ ഉദാഹരണങ്ങൾ: ഒരാൾ വാഷിംഗ് മെഷീനോ ഷവറോ ആവശ്യത്തിന് ഉപയോഗിക്കാറില്ല, മറ്റുള്ളവർക്ക് അത് ഇഷ്ടമല്ല, ഒരാൾ മയക്കത്തിലാണ്, മറ്റുള്ളവർ ജനൽ തുറന്നാൽ കാറ്റ് വീശുന്നു, ആരെങ്കിലും വളരെ ശബ്ദമുണ്ടാക്കുന്നു, മറ്റുള്ളവർക്ക് ജോലി ചെയ്യാൻ നിശബ്ദത ആവശ്യമാണ്, കൂടാതെ ഉടൻ. ഇത്തരത്തിലുള്ള സംഘർഷങ്ങൾ പരിഹരിക്കാൻ കാലതാമസം വരുത്താതിരിക്കുകയും അവരുടെ വഴിക്ക് അവരെ അനുവദിക്കാതിരിക്കുകയും ചെയ്യുന്നതാണ് നല്ലത്. അവർ സ്വയം പരിഹരിക്കില്ല, മാത്രമല്ല നിങ്ങളെ എല്ലാ ദിവസവും ജോലിയിൽ നിന്ന് വ്യതിചലിപ്പിക്കുകയും ടീമിലെ അന്തരീക്ഷത്തെ വിഷലിപ്തമാക്കുകയും ചെയ്യും. ഭാഗ്യവശാൽ, അവ പരിഹരിക്കുന്നത് സാധാരണയായി ഒരു വലിയ പ്രശ്നമല്ല - ശുചിത്വം അവഗണിക്കുന്ന ഒരു സഹപ്രവർത്തകനോട് ശാന്തമായി സംസാരിക്കുക (തീർച്ചയായും ഒന്ന്, തീർച്ചയായും) നിശബ്ദത/തണുപ്പ് ഇഷ്ടപ്പെടുന്ന ആളുകൾക്ക് സുഖപ്രദമായ ഇരിപ്പിടം നൽകുക, ശബ്ദം ആഗിരണം ചെയ്യുന്ന ഹെഡ്‌ഫോണുകൾ വാങ്ങുക അല്ലെങ്കിൽ പാർട്ടീഷനുകൾ ഇൻസ്റ്റാൾ ചെയ്യുക. , തുടങ്ങിയവ.

എന്റെ ജോലിക്കിടയിൽ ഞാൻ പലതവണ നേരിട്ട മറ്റൊരു ഉദാഹരണം ടീം അംഗങ്ങളുടെ മാനസിക പൊരുത്തക്കേടാണ്. ചില കാരണങ്ങളാൽ, ആളുകൾക്ക് ഒരുമിച്ച് പ്രവർത്തിക്കാൻ കഴിയില്ല; എല്ലാ ഇടപെടലുകളും ഒരു അഴിമതിയിൽ അവസാനിക്കുന്നു. ചില ഞെരുക്കമുള്ള വിഷയങ്ങളിൽ (സാധാരണയായി രാഷ്ട്രീയം) ആളുകൾ ധ്രുവ വീക്ഷണങ്ങൾ പുലർത്തുന്നതിനാലും അവരെ ജോലിക്ക് പുറത്ത് എങ്ങനെ വിടണമെന്ന് അറിയാത്തതിനാലും ചിലപ്പോൾ ഇത് സംഭവിക്കുന്നു. പരസ്പരം സഹിഷ്ണുത കാണിക്കുന്നതിനോ അവരുടെ പെരുമാറ്റം മാറ്റുന്നതിനോ അവരെ ബോധ്യപ്പെടുത്തുന്നത് തികച്ചും വ്യർത്ഥമായ ഒരു ജോലിയാണ്. തുറന്ന ധാരണകളുള്ള യുവ സഹപ്രവർത്തകർ മാത്രമാണ് ഞാൻ നേരിട്ട ഒരേയൊരു അപവാദം; ആനുകാലിക സംഭാഷണങ്ങളിലൂടെ അവരുടെ പെരുമാറ്റം ഇപ്പോഴും ക്രമേണ മാറ്റാനാകും. സാധാരണയായി, വ്യത്യസ്ത ടീമുകളായി വേർതിരിക്കുന്നതിലൂടെയോ അല്ലെങ്കിൽ ജോലിയിൽ ഓവർലാപ്പ് ചെയ്യാനുള്ള അവസരം നൽകുന്നതിലൂടെയോ പ്രശ്നം വിജയകരമായി പരിഹരിക്കപ്പെടും.

മേൽപ്പറഞ്ഞ എല്ലാ സാഹചര്യങ്ങളിലും, പങ്കെടുക്കുന്ന എല്ലാവരുമായും വ്യക്തിപരമായി സംസാരിക്കുന്നത് മൂല്യവത്താണ്, സാഹചര്യം ചർച്ച ചെയ്യുക, ഈ കേസിൽ അവർ എന്തെങ്കിലും പ്രശ്നം കാണുന്നുണ്ടോ എന്ന് ചോദിക്കുക, അവരുടെ അഭിപ്രായത്തിൽ, പരിഹാരങ്ങൾ എന്താണെന്ന് ചോദിക്കുക, ഇത് നിർമ്മിക്കുന്നതിൽ അവരുടെ പങ്കാളിത്തം ഉറപ്പാക്കുക തീരുമാനം.

ജോലി പ്രക്രിയ ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിന്റെ വീക്ഷണകോണിൽ (ഞാൻ സൂചിപ്പിച്ച ഇടത്തരം വീക്ഷണം), ഇവിടെ അധികം ചെയ്യാൻ കഴിയില്ല; ഒരു ടീം രൂപീകരിക്കുമ്പോൾ അനുയോജ്യത ഘടകം കണക്കിലെടുക്കുക എന്നതാണ് ഒപ്റ്റിമൈസേഷന്റെ ഒരേയൊരു പോയിന്റ്, ആളുകളെ ഉൾപ്പെടുത്തരുത്. ആർക്കൊക്കെ പൊരുത്തക്കേടുണ്ടാകുമെന്ന് മുൻകൂട്ടി ഒരുമിച്ച്.

ഒരു ടീം കൾച്ചർ വീക്ഷണകോണിൽ, പക്വതയാർന്ന സംസ്കാരമുള്ള ടീമുകളിൽ അത്തരം സാഹചര്യങ്ങൾ വളരെ കുറവാണ് ഉണ്ടാകുന്നത്, അവിടെ ആളുകൾ ടീമിനെയും സഹപ്രവർത്തകരെയും ബഹുമാനിക്കുകയും സ്വതന്ത്രമായി പ്രശ്നങ്ങൾ എങ്ങനെ പരിഹരിക്കാമെന്ന് അറിയുകയും ചെയ്യുന്നു. കൂടാതെ, ഉയർന്ന വിശ്വാസ്യതയുള്ള ടീമുകളിൽ അത്തരം വൈരുദ്ധ്യങ്ങൾ വളരെ എളുപ്പത്തിൽ പരിഹരിക്കപ്പെടും (പലപ്പോഴും സ്വയമേവ), ആളുകൾ വളരെക്കാലം ഒരുമിച്ച് പ്രവർത്തിക്കുകയും കൂടാതെ/അല്ലെങ്കിൽ ജോലിക്ക് പുറത്ത് പതിവായി ആശയവിനിമയം നടത്തുകയും ചെയ്യുന്നു.

തൊഴിൽ പ്രശ്നങ്ങളുമായി ബന്ധപ്പെട്ട പൊരുത്തക്കേടുകൾ:

അത്തരം പൊരുത്തക്കേടുകൾ സാധാരണയായി ഒരേസമയം രണ്ട് കാരണങ്ങളാൽ സംഭവിക്കുന്നു, വൈകാരികവും (പങ്കെടുക്കുന്നവരിൽ ഒരാൾ മുതിർന്നവരുടെ സ്ഥാനത്ത് അല്ല എന്നതും) ജോലി പ്രക്രിയയുടെ അപൂർണതയും. കോഡ് അവലോകനങ്ങൾക്കിടയിലോ ഡെവലപ്പർമാർ തമ്മിലുള്ള ആർക്കിടെക്ചർ ചർച്ചകളിലോ ഉണ്ടാകുന്ന പൊരുത്തക്കേടുകളായിരിക്കാം ഞാൻ നേരിട്ട ഏറ്റവും സാധാരണമായ പൊരുത്തക്കേടുകൾ.

രണ്ട് സാധാരണ കേസുകൾ ഞാൻ ഇവിടെ ഹൈലൈറ്റ് ചെയ്യും:

1) ആദ്യ സന്ദർഭത്തിൽ, ഡവലപ്പർക്ക് ഒരു സഹപ്രവർത്തകനിൽ നിന്ന് ഒരു കോഡ് അവലോകനം ലഭിക്കില്ല. പാച്ച് അവലോകനത്തിനായി അയച്ചു, ഒന്നും സംഭവിക്കുന്നില്ല. ഒറ്റനോട്ടത്തിൽ, ഇരുപക്ഷവും തമ്മിൽ വ്യക്തമായ വൈരുദ്ധ്യമൊന്നുമില്ല, പക്ഷേ നിങ്ങൾ അതിനെക്കുറിച്ച് ചിന്തിക്കുകയാണെങ്കിൽ, ഇത് തികച്ചും സംഘർഷമാണ്. ജോലി പ്രശ്നം പരിഹരിച്ചിട്ടില്ല, കക്ഷികളിൽ ഒരാൾ (ഒരു അവലോകനത്തിനായി കാത്തിരിക്കുന്നു) വ്യക്തമായ അസ്വസ്ഥത അനുഭവിക്കുന്നു. ഒരു കമ്മ്യൂണിറ്റിയിലോ വ്യത്യസ്‌ത ടീമുകളിലോ ഉള്ള വികസനമാണ് ഈ കേസിന്റെ ഒരു തീവ്രമായ ഉപവിഭാഗം, അതേസമയം ലോഡിംഗ് അല്ലെങ്കിൽ മറ്റ് സാഹചര്യങ്ങൾ കാരണം അവലോകനം ചെയ്യുന്നയാൾക്ക് ഈ പ്രത്യേക കോഡിൽ താൽപ്പര്യമില്ലായിരിക്കാം, റിവ്യൂ അഭ്യർത്ഥനയിൽ ശ്രദ്ധ ചെലുത്തിയേക്കില്ല, കൂടാതെ ബാഹ്യ മദ്ധ്യസ്ഥനും (ഇരുവശത്തും പൊതുവായ ഒരു മാനേജർ) ) നിലവിലില്ലായിരിക്കാം.

അത്തരമൊരു സാഹചര്യത്തിൽ സഹായിക്കുന്ന പരിഹാര സമീപനം ഒരു മുതിർന്ന വ്യക്തിയുടെ സംസ്കാരവുമായി ദീർഘകാല വീക്ഷണവുമായി കൃത്യമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. ആദ്യം, സ്മാർട്ട് പ്രവർത്തനം പ്രവർത്തിക്കുന്നു. അവലോകനത്തിൽ തൂങ്ങിക്കിടക്കുന്ന കോഡ് നിരൂപകന്റെ തന്നെ ശ്രദ്ധ ആകർഷിക്കുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കേണ്ടതില്ല. അവനെ ശ്രദ്ധിക്കാൻ നിരൂപകരെ സഹായിക്കേണ്ടതുണ്ട്. പിംഗാനി ദമ്പതികൾ, സിൻകേപ്പിനെക്കുറിച്ച് ഒരു ചോദ്യം ചോദിക്കുക, ചർച്ചകളിൽ പങ്കെടുക്കുക. വ്യക്തമായും, ഇംപോർച്യുണിറ്റി സഹായത്തേക്കാൾ ദോഷം ചെയ്യാനുള്ള സാധ്യത കൂടുതലാണ്, നിങ്ങൾ സാമാന്യബുദ്ധി ഉപയോഗിക്കേണ്ടതുണ്ട്. രണ്ടാമതായി, പ്രീ-തയ്യാറെടുപ്പ് നന്നായി പ്രവർത്തിക്കുന്നു. എന്താണ് സംഭവിക്കുന്നതെന്നും എന്തുകൊണ്ട്, എന്തുകൊണ്ടാണ് ഈ കോഡ് ആവശ്യമായി വരുന്നത്, ഡിസൈൻ എല്ലാവരുമായും മുൻകൂട്ടി ചർച്ച ചെയ്യുകയും അംഗീകരിക്കുകയും ചെയ്തിട്ടുണ്ടെങ്കിൽ, ആളുകൾ അത്തരം കോഡിലേക്ക് ശ്രദ്ധ ചെലുത്താനും ജോലിക്ക് സ്വീകരിക്കാനും കൂടുതൽ സാധ്യതയുണ്ട്. മൂന്നാമതായി, അധികാരം പ്രവർത്തിക്കുന്നു. നിങ്ങൾക്ക് അവലോകനം ചെയ്യണമെങ്കിൽ, ധാരാളം അവലോകനങ്ങൾ സ്വയം ചെയ്യുക. യഥാർത്ഥ പരിശോധനകൾ, യഥാർത്ഥ പരിശോധനകൾ, ഉപയോഗപ്രദമായ അഭിപ്രായങ്ങൾ എന്നിവ ഉപയോഗിച്ച് ഉയർന്ന നിലവാരമുള്ള അവലോകനങ്ങൾ നടത്തുക. ടീമിൽ നിങ്ങളുടെ വിളിപ്പേര് നന്നായി അറിയാമെങ്കിൽ, നിങ്ങളുടെ കോഡ് ശ്രദ്ധിക്കപ്പെടാനുള്ള സാധ്യത കൂടുതലാണ്.

ഒരു വർക്ക്ഫ്ലോ വീക്ഷണകോണിൽ, ഇവിടെ സാധ്യമായ മെച്ചപ്പെടുത്തലുകൾ ഡെവലപ്പറെ അവന്റെയും ടീമിന്റെയും ലക്ഷ്യങ്ങൾ (മറ്റുള്ളവരെ അവലോകനം ചെയ്യുക, കമ്മ്യൂണിറ്റിക്ക് കത്തുകൾ എഴുതുക, ഒരു ആർക്കിടെക്ചർ വിവരണം, ഡോക്യുമെന്റേഷൻ, ടെസ്റ്റുകൾ എന്നിവ സഹിതം കോഡിനൊപ്പമെത്തുക, ചർച്ചകളിൽ പങ്കെടുക്കുക. കമ്മ്യൂണിറ്റി മുതലായവ), പാച്ചുകൾ ക്യൂവിൽ ദീർഘനേരം തൂങ്ങിക്കിടക്കുന്നത് തടയുക തുടങ്ങിയവ.

2) കോഡ് അല്ലെങ്കിൽ ഡിസൈൻ അവലോകനങ്ങൾക്കിടയിലുള്ള പൊരുത്തക്കേടുകളുടെ രണ്ടാമത്തെ സാധാരണ കേസ്, സാങ്കേതിക പ്രശ്നങ്ങൾ, കോഡിംഗ് ശൈലി, ടൂളുകളുടെ തിരഞ്ഞെടുപ്പ് എന്നിവയെക്കുറിച്ചുള്ള വ്യത്യസ്ത വീക്ഷണങ്ങളാണ്. ഈ കേസിൽ വലിയ പ്രാധാന്യം, ഒരേ ടീമിൽ ഉൾപ്പെടുന്ന പങ്കാളികൾ തമ്മിലുള്ള വിശ്വാസത്തിന്റെ നിലവാരവും ഒരുമിച്ച് പ്രവർത്തിച്ചതിന്റെ അനുഭവവുമാണ്. പങ്കെടുക്കുന്നവരിൽ ഒരാൾ ബാലിശമായ ഒരു സ്ഥാനം സ്വീകരിക്കുകയും സംഭാഷണക്കാരൻ അവനോട് എന്താണ് പറയാൻ ആഗ്രഹിക്കുന്നതെന്ന് കേൾക്കാൻ ശ്രമിക്കാതിരിക്കുകയും ചെയ്യുമ്പോൾ ഒരു അന്ത്യം സംഭവിക്കുന്നു. പലപ്പോഴും, മറ്റ് കക്ഷി നിർദ്ദേശിച്ച സമീപനവും തുടക്കത്തിൽ നിർദ്ദേശിച്ച സമീപനവും വിജയകരമായി പ്രവർത്തിച്ചേക്കാം, ഏത് തിരഞ്ഞെടുക്കണമെന്നത് തത്വത്തിൽ പ്രശ്നമല്ല.

ഒരു ദിവസം, എന്റെ ടീമിലെ ഒരു പ്രോഗ്രാമർ (നമുക്ക് അവനെ പാഷ എന്ന് വിളിക്കാം) പാക്കേജ് വിന്യാസ സംവിധാനത്തിൽ മാറ്റങ്ങളുള്ള ഒരു പാച്ച് തയ്യാറാക്കി, അത് ഒരു അയൽ വകുപ്പിലെ സഹപ്രവർത്തകർ വികസിപ്പിക്കുകയും പിന്തുണയ്ക്കുകയും ചെയ്തു. പാക്കേജുകൾ വിന്യസിക്കുമ്പോൾ ലിനക്സ് സേവനങ്ങൾ എങ്ങനെ ക്രമീകരിക്കണം എന്നതിനെക്കുറിച്ച് അവരിൽ ഒരാൾക്ക് (ഇഗോറിന്) ശക്തമായ അഭിപ്രായമുണ്ടായിരുന്നു. ഈ അഭിപ്രായം പാച്ചിൽ നിർദ്ദേശിച്ച സമീപനത്തിൽ നിന്ന് വ്യത്യസ്തമായിരുന്നു, അവർക്ക് അംഗീകരിക്കാൻ കഴിഞ്ഞില്ല. പതിവുപോലെ, സമയപരിധി അവസാനിച്ചു, ഏതെങ്കിലും തരത്തിലുള്ള തീരുമാനത്തിലെത്തേണ്ടത് ആവശ്യമാണ്; അവരിൽ ഒരാൾക്ക് പ്രായപൂർത്തിയായ ഒരു സ്ഥാനം എടുക്കേണ്ടത് ആവശ്യമാണ്. രണ്ട് സമീപനങ്ങൾക്കും ജീവിക്കാനുള്ള അവകാശമുണ്ടെന്ന് പാഷ തിരിച്ചറിഞ്ഞു, പക്ഷേ തന്റെ ഓപ്ഷൻ കടന്നുപോകണമെന്ന് അദ്ദേഹം ആഗ്രഹിച്ചു, കാരണം ഒന്നോ രണ്ടാമത്തെ ഓപ്ഷനോ വ്യക്തമായ സാങ്കേതിക നേട്ടങ്ങളൊന്നും ഉണ്ടായിരുന്നില്ല.

ഞങ്ങളുടെ ചർച്ച ഇതുപോലെയായിരുന്നു (വളരെ ആസൂത്രിതമായി, തീർച്ചയായും, സംഭാഷണം അരമണിക്കൂറോളം നീണ്ടുനിന്നു):

- പാഷാ, കുറച്ച് ദിവസങ്ങൾക്കുള്ളിൽ ഞങ്ങൾക്ക് ഒരു ഫീച്ചർ ഫ്രീസ് ഉണ്ട്. ഞങ്ങൾ എല്ലാം ഒത്തുചേർന്ന് എത്രയും വേഗം പരിശോധന ആരംഭിക്കേണ്ടത് പ്രധാനമാണ്. ഇഗോറിലൂടെ നമുക്ക് എങ്ങനെ എത്തിച്ചേരാനാകും?
— അവൻ വ്യത്യസ്തമായ രീതിയിൽ സേവനങ്ങൾ സജ്ജീകരിക്കാൻ ആഗ്രഹിക്കുന്നു, അവൻ എനിക്കായി അവിടെ അഭിപ്രായങ്ങൾ രേഖപ്പെടുത്തി...
- പിന്നെ എന്താണ്, വലിയ മാറ്റങ്ങൾ, ഒരുപാട് ബഹളങ്ങൾ?
- ഇല്ല, കുറച്ച് മണിക്കൂർ ജോലിയുണ്ട്, പക്ഷേ അവസാനം ഒരു വ്യത്യാസവുമില്ല, അത് ഒന്നുകിൽ പ്രവർത്തിക്കും, എന്തുകൊണ്ട് ഇത് ആവശ്യമാണ്? ഞാൻ പ്രവർത്തിക്കുന്ന എന്തെങ്കിലും ഉണ്ടാക്കി, നമുക്ക് അത് സ്വീകരിക്കാം.
- കേൾക്കൂ, നിങ്ങൾ എത്ര നാളായി ഇതെല്ലാം ചർച്ച ചെയ്യുന്നു?
- അതെ, ഞങ്ങൾ ഇപ്പോൾ ഒന്നര ആഴ്ചയായി സമയം അടയാളപ്പെടുത്തുന്നു.
- ഉം... ഒന്നര ആഴ്‌ച എടുത്ത ഒരു പ്രശ്‌നം നമുക്ക് രണ്ട് മണിക്കൂർ കൊണ്ട് പരിഹരിക്കാനാകുമോ, അത് ചെയ്യാതിരിക്കുമോ?
- ശരി, അതെ, പക്ഷേ ഞാൻ അകപ്പെട്ടുവെന്ന് ഇഗോർ ചിന്തിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നില്ല ...
- ശ്രദ്ധിക്കൂ, നിങ്ങൾക്ക് എന്താണ് കൂടുതൽ പ്രധാനം, ഒരു റിലീസ് പുറപ്പെടുവിക്കുക, നിങ്ങളുടെ തീരുമാനത്തോടൊപ്പം ഉള്ളിൽ, അല്ലെങ്കിൽ ഇഗോറിനെ കൊല്ലുക? ഞങ്ങൾക്ക് അത് തടയാൻ കഴിയും, എന്നിരുന്നാലും, റിലീസിനൊപ്പം പറക്കാൻ നല്ല അവസരമുണ്ട്.
- ശരി ... തീർച്ചയായും, ഇഗോറിന്റെ മൂക്ക് തുടയ്ക്കുന്നത് രസകരമായിരിക്കും, പക്ഷേ ശരി, റിലീസ് കൂടുതൽ പ്രധാനമാണ്, ഞാൻ സമ്മതിക്കുന്നു.
- ഇഗോർ എന്താണ് ചിന്തിക്കുന്നതെന്ന് നിങ്ങൾക്ക് ശരിക്കും പ്രധാനമാണോ? സത്യസന്ധമായി പറഞ്ഞാൽ, അവൻ ഒരു കാര്യവും നൽകുന്നില്ല, അവൻ ഉത്തരവാദിയായ കാര്യത്തിന്റെ വിവിധ സ്ഥലങ്ങളിൽ ഒരു ഏകീകൃത സമീപനം ആഗ്രഹിക്കുന്നു.
- ശരി, ശരി, അദ്ദേഹം അഭിപ്രായങ്ങളിൽ ആവശ്യപ്പെടുന്നത് പോലെ ഞാൻ ചെയ്യട്ടെ, നമുക്ക് ടെസ്റ്റിംഗ് ആരംഭിക്കാം.
- നന്ദി, പാഷ! ഇഗോറെക്ക് നിങ്ങളേക്കാൾ പ്രായമുണ്ടെങ്കിലും നിങ്ങൾ രണ്ടുപേരിൽ കൂടുതൽ പക്വതയുള്ളവരായിരിക്കുമെന്ന് എനിക്ക് ഉറപ്പുണ്ടായിരുന്നു :)

പ്രശ്നം പരിഹരിച്ചു, റിലീസ് കൃത്യസമയത്ത് പുറത്തിറങ്ങി, പാഷയ്ക്ക് വലിയ അതൃപ്തി തോന്നിയില്ല, കാരണം അദ്ദേഹം തന്നെ ഒരു പരിഹാരം നിർദ്ദേശിക്കുകയും അത് നടപ്പിലാക്കുകയും ചെയ്തു. ഇഗോർ പൊതുവെ സന്തോഷിച്ചു, കാരണം ... അദ്ദേഹത്തിന്റെ അഭിപ്രായം കണക്കിലെടുക്കുകയും അദ്ദേഹം നിർദ്ദേശിച്ചതുപോലെ അവർ ചെയ്യുകയും ചെയ്തു.

ഒരു പ്രോജക്റ്റിലെ സാങ്കേതിക പരിഹാരങ്ങൾ/ലൈബ്രറികൾ/സമീപനങ്ങൾ എന്നിവയ്ക്കിടയിലുള്ള തിരഞ്ഞെടുപ്പാണ് അടിസ്ഥാനപരമായി സമാന വൈരുദ്ധ്യത്തിന്റെ മറ്റൊരു തരം, പ്രത്യേകിച്ച് വിതരണം ചെയ്ത ടീമിൽ. C/C++ ഉപയോഗിക്കുന്നതായി സ്ഥാപിച്ചിട്ടുള്ള ഒരു പ്രോജക്ടിൽ, പ്രോജക്റ്റിന്റെ സാങ്കേതിക മാനേജ്മെന്റ് STL (സ്റ്റാൻഡേർഡ് ടെംപ്ലേറ്റ് ലൈബ്രറി) ഉപയോഗിക്കുന്നതിന് എതിരാണെന്ന് തെളിഞ്ഞു. ഇത് വികസനം ലളിതമാക്കുന്ന ഒരു സ്റ്റാൻഡേർഡ് ലാംഗ്വേജ് ലൈബ്രറിയാണ്, ഞങ്ങളുടെ ടീം ഇത് വളരെ പരിചിതമാണ്. C++ നേക്കാൾ പ്രോജക്റ്റ് C യോട് വളരെ അടുത്താണെന്ന് മനസ്സിലായി, അത് ടീമിനെ വളരെയധികം പ്രചോദിപ്പിച്ചില്ല, കാരണം മാനേജ്മെന്റ് അവരുടെ കഴിവിന്റെ പരമാവധി ശ്രമിക്കുകയും മികച്ച കളിക്കാരെ റിക്രൂട്ട് ചെയ്യുകയും ചെയ്തു. അതേ സമയം, ടീമിന്റെ അമേരിക്കൻ ഭാഗം, എഞ്ചിനീയർമാരും മാനേജർമാരും, കമ്പനിയിൽ വളരെക്കാലം ജോലി ചെയ്തിരുന്നു, നിലവിലുള്ള അവസ്ഥയുമായി ശീലിച്ചു, എല്ലാത്തിലും സന്തുഷ്ടരായിരുന്നു. ഏതാനും ആഴ്‌ചകൾക്കുള്ളിൽ (ഞാനും ഉൾപ്പെടെ) ടീമിന്റെ റഷ്യൻ ഭാഗം അടുത്തിടെ ഒരുമിച്ച് കൊണ്ടുവന്നു. ടീമിന്റെ റഷ്യൻ ഭാഗം വികസനത്തോടുള്ള സാധാരണ സമീപനം ഉപേക്ഷിക്കാൻ ആഗ്രഹിച്ചില്ല.

രണ്ട് ഭൂഖണ്ഡങ്ങൾക്കിടയിൽ അവസാനിക്കാത്ത രേഖാമൂലമുള്ള ചർച്ചകൾ ആരംഭിച്ചു, മൂന്നോ നാലോ സ്ക്രീനുകളിൽ കത്തുകൾ അങ്ങോട്ടും ഇങ്ങോട്ടും പറന്നു, ഗ്രൂപ്പ് മെയിലിംഗുകളിലും വ്യക്തിഗതമായവയിലും, പ്രോഗ്രാമർമാർ മുതൽ പ്രോഗ്രാമർമാർ, മാനേജർമാർ വരെ. സാധാരണയായി സംഭവിക്കുന്നതുപോലെ, ഈ ദൈർഘ്യമുള്ള കത്തുകൾ രചയിതാക്കളും അവരുടെ തീവ്ര പിന്തുണക്കാരും ഒഴികെ മറ്റാരും വായിച്ചിട്ടില്ല. STL-ന്റെ സാങ്കേതിക നേട്ടങ്ങൾ, അത് എത്ര നന്നായി പരീക്ഷിച്ചു, എത്ര സുരക്ഷിതമാണ്, പൊതുവേ, അതിനൊപ്പം ജീവിതം എത്ര മനോഹരമാണ്, കൂടാതെ അത് എത്ര ഭയാനകമാണ്, എന്നിവയെക്കുറിച്ച് വ്യത്യസ്ത ദിശകളിലേക്ക് മൾട്ടി-സ്‌ക്രീൻ ചിന്തകൾ കടന്നുപോകുന്ന, ടെൻഷൻ കൊണ്ട് ചാറ്റുകൾ പൊട്ടിപ്പുറപ്പെട്ടു. .

പ്രശ്‌നത്തിന്റെ സാങ്കേതിക വശങ്ങളെക്കുറിച്ചാണ് ഞങ്ങൾ ചർച്ച ചെയ്യുന്നതെന്ന് ഞാൻ മനസ്സിലാക്കുന്നതുവരെ ഇതെല്ലാം വളരെക്കാലം നീണ്ടുനിന്നു, പക്ഷേ പ്രശ്നം യഥാർത്ഥത്തിൽ സാങ്കേതികമായിരുന്നില്ല. പ്രശ്നം STL ന്റെ ഗുണങ്ങളും ദോഷങ്ങളും അല്ലെങ്കിൽ അത് കൂടാതെ പ്രവർത്തിക്കാനുള്ള ബുദ്ധിമുട്ടും അല്ല. പ്രശ്നം സംഘടനാപരമായതാണ്. ഞങ്ങൾ ജോലി ചെയ്തിരുന്ന സ്ഥാപനം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് മനസ്സിലാക്കേണ്ടതുണ്ട്. ഞങ്ങളിൽ ആർക്കും ഇത്തരത്തിൽ ഒരു കമ്പനിയിൽ ജോലി ചെയ്ത പരിചയം ഇല്ലായിരുന്നു. കോഡ് വികസിപ്പിച്ച് ഉൽ‌പാദനത്തിലേക്ക് പുറത്തിറക്കിയ ശേഷം, മറ്റ് ടീമുകളിൽ നിന്ന്, മറ്റ് രാജ്യങ്ങളിൽ നിന്നുള്ള തികച്ചും വ്യത്യസ്തമായ ആളുകൾ പിന്തുണ കൈകാര്യം ചെയ്തു എന്നതാണ് കാര്യം. പതിനായിരക്കണക്കിന് എഞ്ചിനീയർമാരുടെ ഈ വലിയ എഞ്ചിനീയറിംഗ് ടീമിന് (മൊത്തം) തികച്ചും അടിസ്ഥാനപരമായ മിനിമം സാങ്കേതിക മാർഗങ്ങൾ മാത്രമേ താങ്ങാനാകൂ, സംസാരിക്കാൻ, മിനിമം മിനിമോറം. കമ്പനിയിൽ സ്ഥാപിതമായ എഞ്ചിനീയറിംഗ് നിലവാരത്തിന് അപ്പുറത്തേക്ക് പോകുന്ന ഒന്നും ഭാവിയിൽ പിന്തുണയ്ക്കാൻ കഴിയില്ല. ഒരു ടീമിന്റെ നിലവാരം നിർണ്ണയിക്കുന്നത് അതിലെ ഏറ്റവും ദുർബലരായ അംഗങ്ങളുടെ നിലയാണ്. ഞങ്ങൾ മനസ്സിലാക്കിയ ശേഷം യഥാർത്ഥ പ്രചോദനം ടീമിന്റെ അമേരിക്കൻ ഭാഗത്തിന്റെ പ്രവർത്തനങ്ങൾ, ഈ പ്രശ്നം അജണ്ടയിൽ നിന്ന് നീക്കം ചെയ്തു, ഞങ്ങൾ ഒരുമിച്ച് കമ്പനി സ്വീകരിച്ച മാനദണ്ഡങ്ങൾ ഉപയോഗിച്ച് ഉൽപ്പന്നം വിജയകരമായി വികസിപ്പിക്കുകയും പുറത്തിറക്കുകയും ചെയ്തു. ഈ കേസിലെ കത്തുകളും ചാറ്റുകളും നന്നായി പ്രവർത്തിച്ചില്ല; ഒരു പൊതു വിഭാഗത്തിലേക്ക് വരാൻ നിരവധി യാത്രകളും ധാരാളം വ്യക്തിഗത ആശയവിനിമയങ്ങളും എടുത്തു.

വർക്ക്ഫ്ലോയുടെ വീക്ഷണകോണിൽ നിന്ന്, ഈ പ്രത്യേക സാഹചര്യത്തിൽ, ഉപയോഗിക്കുന്ന ഉപകരണങ്ങളുടെ വിവരണം, അവയ്ക്കുള്ള ആവശ്യകതകൾ, പുതിയവ ചേർക്കുന്നതിനുള്ള നിയന്ത്രണങ്ങൾ, അത്തരം നിയന്ത്രണങ്ങൾക്കുള്ള ന്യായീകരണം എന്നിവ സഹായിക്കും. വികസിപ്പിച്ചെടുത്ത "സോഫ്റ്റ്‌വെയർ ഡെവലപ്‌മെന്റിനായുള്ള മാനേജറുടെ കൈപ്പുസ്തകത്തിന്റെ" പുനരുപയോഗ തന്ത്രവും വികസന പരിസ്ഥിതിയും ഖണ്ഡികകളിൽ വിവരിച്ചിരിക്കുന്നവയുമായി അത്തരം രേഖകൾ ഏകദേശം യോജിക്കുന്നു. നാസ. പ്രായം ഉണ്ടായിരുന്നിട്ടും, ഇത്തരത്തിലുള്ള സോഫ്റ്റ്വെയർ വികസനത്തിന്റെ എല്ലാ പ്രധാന പ്രവർത്തനങ്ങളും ആസൂത്രണ ഘട്ടങ്ങളും ഇത് തികച്ചും വിവരിക്കുന്നു. ഇതുപോലുള്ള രേഖകൾ ഉള്ളത് ഒരു ഉൽപ്പന്നത്തിൽ എന്ത് ഘടകങ്ങളും സമീപനങ്ങളും ഉപയോഗിക്കാമെന്നും എന്തുകൊണ്ടാണെന്നും ചർച്ച ചെയ്യുന്നത് വളരെ എളുപ്പമാക്കുന്നു.

ഒരു സാംസ്കാരിക വീക്ഷണകോണിൽ നിന്ന്, വ്യക്തമായും, കൂടുതൽ പക്വമായ നിലപാടിൽ, കക്ഷികൾ അവരുടെ സഹപ്രവർത്തകരുടെ പ്രവർത്തനങ്ങളുടെ യഥാർത്ഥ പ്രചോദനം കേൾക്കാനും മനസ്സിലാക്കാനും ശ്രമിക്കുന്നു, കൂടാതെ പ്രോജക്റ്റിന്റെയും ടീമിന്റെയും മുൻഗണനകളെ അടിസ്ഥാനമാക്കി പ്രവർത്തിക്കുന്നു, അല്ലാതെ വ്യക്തിപരമായ അഹംഭാവമല്ല. , സംഘർഷം എളുപ്പത്തിലും വേഗത്തിലും പരിഹരിക്കപ്പെടും.

ഒരു സാങ്കേതിക പരിഹാരം തിരഞ്ഞെടുക്കുന്നതിനെക്കുറിച്ചുള്ള മറ്റൊരു തർക്കത്തിൽ, ഒരു കക്ഷിയുടെ പ്രചോദനം മനസ്സിലാക്കാൻ എനിക്ക് ശ്രദ്ധേയമായ സമയമെടുത്തു (അത് വളരെ അസാധാരണമായ ഒരു കേസായിരുന്നു), എന്നാൽ പ്രചോദനം വ്യക്തമായതിന് ശേഷം, പരിഹാരം വ്യക്തമായിരുന്നു.

സാഹചര്യം ഇതാണ്: ഏകദേശം 20 ആളുകളുടെ ഒരു ടീമിൽ ഒരു പുതിയ ഡവലപ്പർ പ്രത്യക്ഷപ്പെടുന്നു, നമുക്ക് അവനെ സ്റ്റാസ് എന്ന് വിളിക്കാം. അക്കാലത്ത്, ഒരു ടീമെന്ന നിലയിൽ ആശയവിനിമയത്തിനുള്ള ഞങ്ങളുടെ അടിസ്ഥാന ഉപകരണം സ്കൈപ്പ് ആയിരുന്നു. പിന്നീട് തെളിഞ്ഞതുപോലെ, ഓപ്പൺ സ്റ്റാൻഡേർഡുകളുടെയും ഓപ്പൺ സോഴ്‌സ് സോഫ്‌റ്റ്‌വെയറുകളുടെയും വലിയ ആരാധകനായിരുന്നു സ്റ്റാസ്, കൂടാതെ പൊതുവായി ലഭ്യമായതും പൊതുവായി വിവരിച്ച പ്രോട്ടോക്കോളുകൾ ഉപയോഗിക്കുന്നതുമായ ഉപകരണങ്ങളും ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളും മാത്രമാണ് ഉപയോഗിച്ചത്. സ്കൈപ്പ് ഈ ഉപകരണങ്ങളിൽ ഒന്നല്ല. ഈ സമീപനത്തിന്റെ ഗുണങ്ങളും ദോഷങ്ങളും, വ്യത്യസ്ത ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളിൽ സ്കൈപ്പിന്റെ അനലോഗ് സമാരംഭിക്കാനുള്ള ശ്രമങ്ങൾ, മറ്റ് മാനദണ്ഡങ്ങളിലേക്ക് മാറാൻ ടീമിനെ ബോധ്യപ്പെടുത്താനുള്ള സ്റ്റാസിന്റെ ശ്രമങ്ങൾ, മെയിൽ വഴി അദ്ദേഹത്തിന് വ്യക്തിപരമായി എഴുതുക, വ്യക്തിപരമായി വിളിക്കുക എന്നിവയെക്കുറിച്ച് ഞങ്ങൾ ധാരാളം സമയം ചെലവഴിച്ചു. ഫോൺ, സ്കൈപ്പിനായി പ്രത്യേകമായി രണ്ടാമത്തെ കമ്പ്യൂട്ടർ വാങ്ങുക, മുതലായവ. അവസാനമായി, ഈ പ്രശ്നം, സാരാംശത്തിൽ, സാങ്കേതികമോ സംഘടനാപരമോ അല്ല, അത് പ്രത്യയശാസ്ത്രപരമാണ്, മതപരമാണ് (സ്റ്റാസിന്) എന്ന് ഒരാൾ പറഞ്ഞേക്കാം. ഞങ്ങൾ ഒടുവിൽ സ്റ്റാസും സ്കൈപ്പും കണക്‌റ്റ് ചെയ്‌താലും (ഇതിന് നിരവധി മാസങ്ങൾ എടുത്തിരുന്നു), തുടർന്നുള്ള ഏത് ഉപകരണത്തിലും പ്രശ്‌നം വീണ്ടും ഉടലെടുക്കും. സ്റ്റാസിന്റെ ലോകവീക്ഷണം മാറ്റാൻ എനിക്ക് യഥാർത്ഥ മാർഗങ്ങളൊന്നും ഉണ്ടായിരുന്നില്ല, ഈ പരിതസ്ഥിതിയിൽ തികച്ചും പ്രവർത്തിക്കുന്ന ഒരു ടീമിന്റെ ലോകവീക്ഷണം മാറ്റാൻ ശ്രമിക്കുന്നതിന് ഒരു കാരണവുമില്ല. വ്യക്തിയും കമ്പനിയും അവരുടെ ലോകവീക്ഷണത്തിൽ കേവലം ഓർത്തോഗണൽ ആയിരുന്നു. അത്തരം സാഹചര്യങ്ങളിൽ, ഒരു നല്ല പരിഹാരം സംഘടനാപരമായതാണ്. ഞങ്ങൾ സ്റ്റാസിനെ മറ്റൊരു ടീമിലേക്ക് മാറ്റി, അവിടെ അവൻ കൂടുതൽ ഓർഗാനിക് ആയിരുന്നു.

ഈ സംഘട്ടനത്തിന് കാരണം, എന്റെ അഭിപ്രായത്തിൽ, ഒരു പ്രത്യേക വ്യക്തിയുടെ വ്യക്തിഗത സംസ്കാരവും (അയാളെ വിട്ടുവീഴ്ച ചെയ്യാൻ അനുവദിക്കാത്ത ശക്തമായ അഭിപ്രായമുള്ളയാളും) കമ്പനിയുടെ സംസ്കാരവും തമ്മിലുള്ള പൊരുത്തക്കേടാണ്. ഈ സാഹചര്യത്തിൽ, ഇത് തീർച്ചയായും മാനേജരുടെ തെറ്റാണ്. ഇത്തരത്തിലുള്ള ഒരു പ്രോജക്റ്റിലേക്ക് അദ്ദേഹത്തെ എടുത്തത് തുടക്കത്തിൽ തെറ്റായിരുന്നു. സ്റ്റാസ് ഒടുവിൽ ഒരു ഓപ്പൺ സോഴ്‌സ് സോഫ്റ്റ്‌വെയർ ഡെവലപ്‌മെന്റ് പ്രോജക്റ്റിലേക്ക് മാറുകയും അവിടെ മികവ് പുലർത്തുകയും ചെയ്തു.

ഡെവലപ്പറുടെ ബാലിശമായ മനോഭാവവും ജോലി പ്രക്രിയയുടെ പോരായ്മകളും മൂലമുണ്ടാകുന്ന സംഘർഷത്തിന്റെ ഒരു നല്ല ഉദാഹരണം, ചെയ്തു എന്നതിന്റെ നിർവചനത്തിന്റെ അഭാവത്തിൽ, ഡെവലപ്പർക്കും ക്യുഎ ടീമിനും സന്നദ്ധത സംബന്ധിച്ച് വ്യത്യസ്ത പ്രതീക്ഷകളുള്ള ഒരു സാഹചര്യമാണ്. സവിശേഷത QA-ലേക്ക് മാറ്റി. കോഡ് എഴുതി വേലിക്ക് മുകളിലൂടെ ഫീച്ചർ QA ലേക്ക് എറിഞ്ഞാൽ മതിയെന്ന് ഡവലപ്പർ വിശ്വസിച്ചു - അവർ അത് അവിടെ അടുക്കും. സാമാന്യം പക്വതയുള്ള പരിചയസമ്പന്നനായ ഒരു പ്രോഗ്രാമർ, പക്ഷേ അത് ഗുണനിലവാരത്തിനുള്ള അദ്ദേഹത്തിന്റെ ആന്തരിക പരിധിയായിരുന്നു. QA ഇതിനോട് വിയോജിക്കുകയും താൻ സ്വയം പരിശോധിച്ചത് അവരെ കാണിക്കാനും വിവരിക്കാനും ആവശ്യപ്പെടുകയും അവർക്കായി ഒരു ടെസ്റ്റിംഗ് സ്ക്രിപ്റ്റ് ആവശ്യപ്പെടുകയും ചെയ്തു. ഈ ഡെവലപ്പറിൽ നിന്നുള്ള പ്രവർത്തനത്തിൽ അവർക്ക് മുമ്പ് പ്രശ്‌നങ്ങളുണ്ടായിരുന്നു, അവരുടെ സമയം വീണ്ടും പാഴാക്കാൻ അവർ ആഗ്രഹിച്ചില്ല. വഴിയിൽ, അവർ പറഞ്ഞത് ശരിയാണ് - ഫീച്ചർ ശരിക്കും പ്രവർത്തിച്ചില്ല, QA-ലേക്ക് അയയ്‌ക്കുന്നതിന് മുമ്പ് അദ്ദേഹം കോഡ് പരിശോധിച്ചില്ല.

സാഹചര്യം പരിഹരിക്കാൻ, എല്ലാം ശരിക്കും പ്രവർത്തിക്കുന്നുണ്ടെന്ന് എന്നോട് കാണിക്കാൻ ഞാൻ അവനോട് ആവശ്യപ്പെട്ടു (അത് പ്രവർത്തിച്ചില്ല, അവൻ അത് ശരിയാക്കണം), ഞങ്ങൾ ടീമുമായും QA ചെയ്തു എന്നതിന്റെ നിർവചനവുമായി സംസാരിച്ചു (അവർ അത് ചെയ്തില്ല എഴുത്ത്, കാരണം പ്രക്രിയയെ വളരെ ബ്യൂറോക്രാറ്റിക് ആക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ല ), ശരി, ഞങ്ങൾ ഈ സ്പെഷ്യലിസ്റ്റുമായി (പൊതുവായ ആശ്വാസത്തിനായി) വേർപിരിഞ്ഞു.

വർക്ക്ഫ്ലോയുടെ വീക്ഷണകോണിൽ, ഈ കേസിൽ സാധ്യമായ മെച്ചപ്പെടുത്തലുകൾ പൂർത്തിയാക്കിയതിന്റെ നിർവചനത്തിന്റെ സാന്നിധ്യം, ഓരോ യൂണിറ്റ് സവിശേഷതയുടെയും ഇന്റഗ്രേഷൻ ടെസ്റ്റുകളുടെയും പിന്തുണയ്‌ക്കുള്ള ആവശ്യകതകൾ, ഡവലപ്പർ നടത്തിയ പരിശോധനയുടെ വിവരണം എന്നിവയാണ്. പ്രോജക്‌റ്റുകളിലൊന്നിൽ, CI സമയത്ത് ടെസ്റ്റുകൾ വഴി ഞങ്ങൾ കോഡ് കവറേജിന്റെ ലെവൽ അളന്നു, ഒരു പാച്ച് ചേർത്തതിന് ശേഷം കവറേജ് ലെവൽ കുറഞ്ഞാൽ, ടെസ്റ്റുകൾ പരാജയപ്പെട്ടതായി അടയാളപ്പെടുത്തി, അതായത്. പുതിയ ടെസ്റ്റുകൾ ഉണ്ടെങ്കിൽ മാത്രമേ പുതിയ കോഡ് ചേർക്കാനാകൂ.

ജോലി പ്രക്രിയയുടെ ഓർഗനൈസേഷനുമായി അടുത്ത ബന്ധമുള്ള ഒരു സംഘട്ടനത്തിന്റെ മറ്റൊരു സാധാരണ ഉദാഹരണം. ഞങ്ങൾക്ക് ഒരു ഉൽപ്പന്നം, ഒരു ഉൽപ്പന്ന വികസന ടീം, ഒരു പിന്തുണാ ടീം, ഒരു ഉപഭോക്താവ് എന്നിവയുണ്ട്. ഉൽപ്പന്നത്തിലും കോൺടാക്‌റ്റ് പിന്തുണയിലും ഉപഭോക്താവിന് പ്രശ്‌നങ്ങളുണ്ട്. പിന്തുണ പ്രശ്നം വിശകലനം ചെയ്യുകയും പ്രശ്നം ഉൽപ്പന്നത്തിലാണെന്ന് മനസ്സിലാക്കുകയും പ്രശ്നം ഉൽപ്പന്ന ടീമിന് കൈമാറുകയും ചെയ്യുന്നു. ഉൽപ്പന്ന ടീം തിരക്കുള്ള സമയത്താണ്, ഒരു റിലീസ് അടുക്കുന്നു, അതിനാൽ ഒരു ഉപഭോക്താവിൽ നിന്നുള്ള പ്രശ്‌നമുള്ള ഒരു ടിക്കറ്റ്, അത് ഏൽപ്പിച്ചിരിക്കുന്ന ഡെവലപ്പറുടെ മറ്റ് ടിക്കറ്റുകൾക്കിടയിൽ നഷ്‌ടപ്പെട്ടു, ശ്രദ്ധയില്ലാതെ ആഴ്ചകളോളം തൂങ്ങിക്കിടക്കുന്നു. ഉപഭോക്താവിന്റെ പ്രശ്‌നത്തിൽ ഡെവലപ്പർ പ്രവർത്തിക്കുകയാണെന്ന് പിന്തുണ കരുതുന്നു. ഉപഭോക്താവ് കാത്തിരിക്കുകയും അവരുടെ പ്രശ്നം പരിഹരിക്കപ്പെടുമെന്ന് പ്രതീക്ഷിക്കുകയും ചെയ്യുന്നു. വാസ്തവത്തിൽ, ഇതുവരെ ഒന്നും സംഭവിക്കുന്നില്ല. ഏതാനും ആഴ്ചകൾക്കുശേഷം, ഉപഭോക്താവ് പുരോഗതിയിൽ താൽപ്പര്യമെടുക്കാൻ തീരുമാനിക്കുകയും കാര്യങ്ങൾ എങ്ങനെ പോകുന്നു എന്നതിനെ പിന്തുണയ്‌ക്കുകയും ചെയ്യുന്നു. പിന്തുണ വികസനം ആവശ്യപ്പെടുന്നു. ഡെവലപ്പർ വിറച്ചു, ടിക്കറ്റുകളുടെ ലിസ്റ്റിലൂടെ നോക്കുകയും അവിടെയുള്ള ഉപഭോക്താവിൽ നിന്ന് ഒരു ടിക്കറ്റ് കണ്ടെത്തുകയും ചെയ്യുന്നു. ഒരു ഉപഭോക്താവിൽ നിന്ന് ഒരു ടിക്കറ്റ് വായിക്കുമ്പോൾ, പ്രശ്നം പരിഹരിക്കാൻ മതിയായ വിവരങ്ങൾ ഇല്ലെന്ന് അയാൾ മനസ്സിലാക്കുന്നു, കൂടാതെ അയാൾക്ക് കൂടുതൽ ലോഗുകളും ഡമ്പുകളും ആവശ്യമുണ്ട്. പിന്തുണ ഉപഭോക്താവിൽ നിന്ന് കൂടുതൽ വിവരങ്ങൾ അഭ്യർത്ഥിക്കുന്നു. ഇക്കാലമത്രയും തന്റെ പ്രശ്‌നത്തിൽ ആരും പ്രവർത്തിച്ചിട്ടില്ലെന്ന് ഉപഭോക്താവ് മനസ്സിലാക്കുന്നു. ഒപ്പം ഇടിയും അടിക്കും...

ഈ സാഹചര്യത്തിൽ, സംഘട്ടനത്തിനുള്ള പരിഹാരം തന്നെ വളരെ വ്യക്തവും രേഖീയവുമാണ് (ഉൽപ്പന്നം ശരിയാക്കുക, ഡോക്യുമെന്റേഷനും ടെസ്റ്റുകളും അപ്ഡേറ്റ് ചെയ്യുക, ഉപഭോക്താവിനെ പ്രീതിപ്പെടുത്തുക, ഒരു ഹോട്ട്ഫിക്സ് റിലീസ് ചെയ്യുക മുതലായവ). ജോലി പ്രക്രിയ വിശകലനം ചെയ്യേണ്ടതും രണ്ട് ടീമുകൾ തമ്മിലുള്ള ആശയവിനിമയം സംഘടിപ്പിക്കുന്നതിന് ആരാണ് ഉത്തരവാദികളെന്നും മനസിലാക്കേണ്ടത് പ്രധാനമാണ്, എന്തുകൊണ്ടാണ് ഈ സാഹചര്യം ആദ്യം സാധ്യമായത്. ഈ പ്രക്രിയയിൽ എന്താണ് പരിഹരിക്കേണ്ടതെന്ന് വ്യക്തമാണ് - ഉപഭോക്താക്കളിൽ നിന്നുള്ള ഓർമ്മപ്പെടുത്തലുകൾ ഇല്ലാതെ, സജീവമായി ആരെങ്കിലും മൊത്തത്തിലുള്ള ചിത്രം നിരീക്ഷിക്കണം. ഉപഭോക്താവിൽ നിന്നുള്ള ടിക്കറ്റുകൾ ഡെവലപ്പർമാരിൽ നിന്നുള്ള മറ്റ് ടിക്കറ്റുകൾക്കിടയിൽ വേറിട്ടുനിൽക്കണം. ഡെവലപ്‌മെന്റ് ടീം നിലവിൽ അതിന്റെ ടിക്കറ്റുകളിൽ പ്രവർത്തിക്കുന്നുണ്ടോയെന്നും ഇല്ലെങ്കിൽ എപ്പോൾ പ്രവർത്തിക്കാൻ തുടങ്ങുമെന്നും എപ്പോൾ ഫലങ്ങൾ പ്രതീക്ഷിക്കാമെന്നും പിന്തുണ കാണണം. പിന്തുണയും വികസനവും ആനുകാലികമായി ആശയവിനിമയം നടത്തുകയും ടിക്കറ്റുകളുടെ നില ചർച്ച ചെയ്യുകയും വേണം, ഡീബഗ്ഗിംഗിന് ആവശ്യമായ വിവരങ്ങളുടെ ശേഖരണം കഴിയുന്നത്ര ഓട്ടോമേറ്റ് ചെയ്യണം.

യുദ്ധത്തിൽ ശത്രു രണ്ട് യൂണിറ്റുകൾക്കിടയിലുള്ള ജംഗ്ഷനിൽ ഇടിക്കാൻ ശ്രമിക്കുന്നതുപോലെ, ജോലിയിൽ ഏറ്റവും സൂക്ഷ്മവും ദുർബലവുമായ പോയിന്റ് സാധാരണയായി ടീമുകൾ തമ്മിലുള്ള ആശയവിനിമയമാണ്. പിന്തുണയും വികസന മാനേജർമാരും മതിയായ പ്രായമുള്ളവരാണെങ്കിൽ, അവർക്ക് സ്വയം പ്രോസസ്സ് പരിഹരിക്കാൻ കഴിയും, ഇല്ലെങ്കിൽ, സാഹചര്യം പരിഹരിക്കാൻ കഴിയുന്ന ഒരു മാനേജർ ഇടപെടുന്നത് വരെ പ്രക്രിയ വൈരുദ്ധ്യങ്ങളും പ്രശ്നങ്ങളും സൃഷ്ടിക്കുന്നത് തുടരും.

വിവിധ കമ്പനികളിൽ ഞാൻ ആവർത്തിച്ച് കണ്ടിട്ടുള്ള മറ്റൊരു ഉദാഹരണം, ഒരു ഉൽപ്പന്നം ഒരു ടീം എഴുതുന്ന സാഹചര്യമാണ്, അതിനുള്ള ഓട്ടോമാറ്റിക് ഇന്റഗ്രേഷൻ ടെസ്റ്റുകൾ രണ്ടാമത്തെ ടീം എഴുതുന്നു, ഒപ്പം എല്ലാം പ്രവർത്തിപ്പിക്കുന്ന അടിസ്ഥാന സൗകര്യങ്ങൾ മൂന്നാമത്തേത് ഒപ്പമുണ്ട്. ടീം. ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുമ്പോൾ എല്ലായ്‌പ്പോഴും പ്രശ്‌നങ്ങൾ ഉണ്ടാകുന്നു, അവയിലെ പ്രശ്‌നങ്ങളുടെ കാരണം ഉൽപ്പന്നവും ടെസ്റ്റുകളും അടിസ്ഥാന സൗകര്യങ്ങളും ആകാം. പ്രശ്‌നങ്ങളുടെ പ്രാഥമിക വിശകലനം, ഫയൽ ബഗുകൾ, ഉൽപ്പന്നത്തിന്റെ പാഴ്‌സ് ലോഗുകൾ, ടെസ്റ്റുകൾ, ഇൻഫ്രാസ്ട്രക്ചർ മുതലായവയുടെ പ്രാഥമിക വിശകലനം ആരാണ് നടത്തേണ്ടതെന്ന് സമ്മതിക്കുന്നത് സാധാരണയായി പ്രശ്‌നകരമാണ്. ഇവിടെ സംഘർഷങ്ങൾ വളരെ പതിവാണ്, അതേ സമയം, യൂണിഫോം. ഉയർന്ന വൈകാരിക തീവ്രതയുടെ കാര്യത്തിൽ, പങ്കെടുക്കുന്നവർ പലപ്പോഴും ബാലിശമായ ഒരു സ്ഥാനത്തേക്ക് വീഴുകയും പരമ്പരയിൽ ചർച്ചകൾ ആരംഭിക്കുകയും ചെയ്യുന്നു: "ഞാൻ എന്തിന് ഇത് കൈകാര്യം ചെയ്യണം," "അവർ പലപ്പോഴും തകരുന്നു," മുതലായവ.

ഒരു വർക്ക്ഫ്ലോ വീക്ഷണകോണിൽ, ഒരു പ്രശ്നം പരിഹരിക്കുന്നതിനുള്ള നിർദ്ദിഷ്ട ഘട്ടങ്ങൾ ടീമുകളുടെ ഘടന, ടെസ്റ്റുകളുടെ തരം, ഉൽപ്പന്നം മുതലായവയെ ആശ്രയിച്ചിരിക്കുന്നു. പ്രോജക്‌റ്റുകളിലൊന്നിൽ, ഞങ്ങൾ ആനുകാലിക ഡ്യൂട്ടി അവതരിപ്പിച്ചു, അതിൽ ടീമുകൾ ഓരോ ആഴ്ചയും ഓരോ ആഴ്‌ചയും ടെസ്റ്റുകൾ നിരീക്ഷിച്ചു. മറ്റൊന്നിൽ, പ്രാരംഭ വിശകലനം എല്ലായ്പ്പോഴും ടെസ്റ്റ് ഡെവലപ്പർമാർ നടത്തിയിരുന്നു, എന്നാൽ വിശകലനം വളരെ അടിസ്ഥാനപരവും ഉൽപ്പന്നം സ്ഥിരതയുള്ളതും ആയതിനാൽ അത് നന്നായി പ്രവർത്തിച്ചു. പ്രക്രിയ സുതാര്യമാണെന്നും എല്ലാ കക്ഷികൾക്കും പ്രതീക്ഷകൾ വ്യക്തമാണെന്നും സാഹചര്യം എല്ലാവർക്കും ന്യായമാണെന്നും ഉറപ്പാക്കുക എന്നതാണ് പ്രധാന കാര്യം.

ഒരു ഓർഗനൈസേഷനിൽ സംഘർഷം ഒരു പ്രശ്‌നമാണോ? നിങ്ങളുടെ ടീമിൽ പലപ്പോഴും (അല്ലെങ്കിൽ ഇടയ്‌ക്കിടെ) പൊരുത്തക്കേടുകൾ ഉണ്ടാകുന്നത് ഒരു മോശം അടയാളമാണോ? പൊതുവേ, ഇല്ല, കാരണം വളർച്ചയും വികാസവും ഉണ്ടെങ്കിൽ, ഒരുതരം ചലനാത്മകതയുണ്ട്, മുമ്പ് ഒരിക്കലും പരിഹരിക്കപ്പെടാത്ത പ്രശ്നങ്ങൾ ഉയർന്നുവരുന്നു, അവ പരിഹരിക്കുമ്പോൾ വൈരുദ്ധ്യങ്ങൾ ഉണ്ടാകാം. ചില മേഖലകൾക്ക് ശ്രദ്ധ ആവശ്യമാണെന്നതിന്റെ സൂചകമാണിത്, മെച്ചപ്പെടുത്താനുള്ള മേഖലകളുണ്ട്. പൊരുത്തക്കേടുകൾ പലപ്പോഴും ഉണ്ടാകുകയോ പരിഹരിക്കാൻ ബുദ്ധിമുട്ടുകയോ ദീർഘനേരം എടുക്കുകയോ ചെയ്താൽ അത് മോശമാണ്. ഇത് മിക്കവാറും കാര്യക്ഷമമായ പ്രവർത്തന പ്രക്രിയകളുടെയും ടീമിന്റെ അപര്യാപ്തമായ പക്വതയുടെയും അടയാളമാണ്.

അവലംബം: www.habr.com