ટીમમાં સંઘર્ષ વ્યવસ્થાપન - સંતુલિત કાર્ય અથવા મહત્વપૂર્ણ આવશ્યકતા?

એપિગ્રાફ:
એક સમયે, હેજહોગ અને નાનું રીંછ જંગલમાં મળ્યા હતા.
- હેલો, હેજહોગ!
- હેલો, નાનું રીંછ!
તેથી, શબ્દ દ્વારા શબ્દ, મજાક દ્વારા મજાક, હેજહોગ નાના રીંછ દ્વારા ચહેરા પર અથડાયો ...

નીચે અમારી ટીમ લીડર, તેમજ RAS પ્રોડક્ટ ડેવલપમેન્ટ ડાયરેક્ટર ઇગોર માર્નાટ દ્વારા કામના સંઘર્ષની વિશિષ્ટતાઓ અને તેના સંચાલન માટેની સંભવિત પદ્ધતિઓ વિશેની ચર્ચા છે.

કામ પર આપણે જે સંઘર્ષોનો સામનો કરીએ છીએ તેમાંથી મોટાભાગની તકરાર ઉપરના એપિગ્રાફમાં વર્ણવેલ સમાન દૃશ્ય અનુસાર વિકસિત થાય છે. ત્યાં ઘણા સહભાગીઓ છે જેઓ શરૂઆતમાં એકબીજા પ્રત્યે ખૂબ અનુકૂળ હોય છે; તેઓ કોઈ સમસ્યાને ઉકેલવાનો પ્રયાસ કરી રહ્યા છે, પરંતુ અંતે સમસ્યા વણઉકેલાયેલી રહે છે, અને કેટલાક કારણોસર ચર્ચામાં ભાગ લેનારાઓ વચ્ચેના સંબંધો બગડે છે.

જીવન વૈવિધ્યસભર છે, અને ઉપર વર્ણવેલ દૃશ્યમાં વિવિધતા જોવા મળે છે. કેટલીકવાર સહભાગીઓ વચ્ચેના સંબંધ શરૂઆતમાં ખૂબ સારા હોતા નથી, કેટલીકવાર એવી કોઈ સમસ્યા પણ હોતી નથી કે જેના માટે સીધા ઉકેલની જરૂર હોય (જેમ કે, એપિગ્રાફમાં), કેટલીકવાર ચર્ચા પછી સંબંધ પહેલા જેવો જ રહે છે, પરંતુ મુદ્દો આખરે ઉકેલાયો નથી.

કાર્ય સંઘર્ષની પરિસ્થિતિ તરીકે વ્યાખ્યાયિત કરી શકાય તેવી તમામ પરિસ્થિતિઓમાં શું સામાન્ય છે?



પ્રથમ, ત્યાં બે અથવા વધુ બાજુઓ છે. આ પક્ષો સંસ્થામાં વિવિધ સ્થાનો પર કબજો કરી શકે છે, સમાનતાના સંબંધમાં હોઈ શકે છે (ટીમમાં સાથીદારો), અથવા વંશવેલોના વિવિધ સ્તરે (બોસ - ગૌણ), વ્યક્તિગત (કર્મચારી) અથવા જૂથ (કોઈ વચ્ચે સંઘર્ષના કિસ્સામાં) હોઈ શકે છે. કર્મચારી અને એક ટીમ અથવા બે ટીમો), અને તેથી વધુ. સંઘર્ષની સંભાવના અને તેના ઉકેલની સરળતા સહભાગીઓ વચ્ચેના વિશ્વાસના સ્તરથી ખૂબ પ્રભાવિત થાય છે. પક્ષો એકબીજાને જેટલી સારી રીતે ઓળખે છે, વિશ્વાસનું સ્તર જેટલું ઊંચું હશે, તેટલી ઊંચી તકો કે તેઓ કરાર પર આવશે. ઉદાહરણ તરીકે, વિતરિત ટીમના સભ્યો કે જેમણે ક્યારેય સામસામે વાતચીત કરી નથી તેઓને ઓછામાં ઓછા થોડા સામસામે ક્રિયાપ્રતિક્રિયા કરી હોય તેવા લોકો કરતાં સામાન્ય કાર્ય મુદ્દા પર સંઘર્ષનો અનુભવ થવાની શક્યતા વધુ હોય છે. તેથી, વિતરિત ટીમોમાં કામ કરતી વખતે, તે સુનિશ્ચિત કરવું ખૂબ જ મહત્વપૂર્ણ છે કે ટીમના તમામ સભ્યો સમયાંતરે એકબીજા સાથે રૂબરૂમાં મળે.

બીજું, કાર્યસ્થળ પર સંઘર્ષની પરિસ્થિતિમાં, પક્ષો અમુક મુદ્દાને ઉકેલવાની સ્થિતિમાં હોય છે જે એક પક્ષ માટે, તે બંને માટે અથવા સમગ્ર સંસ્થા માટે મહત્વપૂર્ણ છે. તે જ સમયે, પરિસ્થિતિની વિશિષ્ટતાઓને લીધે, પક્ષો પાસે સામાન્ય રીતે પૂરતો સમય હોય છે અને તેને ઉકેલવા માટેની વિવિધ રીતો હોય છે (ઔપચારિક, અનૌપચારિક, મીટિંગ્સ, પત્રો, મેનેજમેન્ટ નિર્ણયો, ટીમના લક્ષ્યો અને યોજનાઓની હાજરી, પદાનુક્રમની હકીકત, વગેરે). આ સંસ્થામાં કાર્ય (અથવા બિન-કાર્ય) મુદ્દાને ઉકેલવાની પરિસ્થિતિથી અલગ છે, ઉદાહરણ તરીકે, એક મહત્વપૂર્ણ પ્રશ્નનું નિરાકરણ: ​​"અરે, બાળક, તમે કયા ક્ષેત્રના છો?!" શેરીમાં, અથવા એપિગ્રાફમાંથી સંઘર્ષ. કામના મુદ્દાને ઉકેલવાના કિસ્સામાં, કાર્ય પ્રક્રિયાની ગુણવત્તા અને ટીમમાં મુદ્દાઓને ઉકેલવાની સંસ્કૃતિ મહત્વપૂર્ણ છે.

ત્રીજે સ્થાને, સંઘર્ષનું નિર્ણાયક પરિબળ (અમારી ચર્ચાના દૃષ્ટિકોણથી) એ હકીકત છે કે પ્રક્રિયાના પક્ષકારો સ્વતંત્ર રીતે તમામ પક્ષોને અનુકૂળ હોય તેવા મુદ્દાના ઉકેલ પર આવી શકતા નથી. પરિસ્થિતિમાં તૃતીય પક્ષ, બાહ્ય લવાદીના હસ્તક્ષેપની જરૂર છે. આ મુદ્દો વિવાદાસ્પદ લાગે છે, પરંતુ, સારમાં, જો બાહ્ય લવાદીના હસ્તક્ષેપ વિના સંઘર્ષની પરિસ્થિતિ સફળતાપૂર્વક ઉકેલી લેવામાં આવી હતી, તો મુદ્દો સફળતાપૂર્વક ઉકેલાઈ ગયો હતો અને પક્ષોના સંબંધો બગડ્યા ન હતા, આ તે પરિસ્થિતિ છે જેના માટે આપણે પ્રયત્ન કરવો જોઈએ. . અમને સંભવતઃ આવા સંઘર્ષ વિશે ખબર પણ નહીં હોય, અથવા તે ઉકેલાઈ ગયા પછી અમે તક દ્વારા શોધીશું. ટીમ જેટલી વધુ સમસ્યાઓ જાતે ઉકેલી શકે છે, તે વધુ અસરકારક રહેશે.

સંઘર્ષની અન્ય લાક્ષણિકતા જે સ્પર્શ કરવા યોગ્ય છે તે નિર્ણય દરમિયાન ભાવનાત્મક તીવ્રતાની ડિગ્રી છે. સંઘર્ષ ઉચ્ચ ભાવનાત્મક સ્તર સાથે જરૂરી નથી. સારમાં, સંઘર્ષની પરિસ્થિતિ માટે સહભાગીઓએ બૂમો પાડવાની અને તેમના હાથ હલાવવાની જરૂર નથી. આ મુદ્દો ઉકેલાયો નથી, ચોક્કસ ભાવનાત્મક તણાવ હાજર છે (કદાચ તે સ્પષ્ટ રીતે બાહ્ય રીતે વ્યક્ત કરવામાં આવ્યો નથી), જેનો અર્થ છે કે આપણે સંઘર્ષની પરિસ્થિતિનો સામનો કરી રહ્યા છીએ.

શું સંઘર્ષની પરિસ્થિતિઓમાં દખલ કરવી જરૂરી છે, અથવા તેમના નિરાકરણને તેના માર્ગ પર જવા દેવું અને સમસ્યાનું સમાધાન થાય તેની રાહ જોવી વધુ સારું છે? જરૂર છે. સંઘર્ષને સંપૂર્ણપણે ઉકેલવા હંમેશા તમારી શક્તિ અથવા યોગ્યતામાં હોતું નથી, પરંતુ કોઈપણ પરિસ્થિતિમાં, કોઈપણ સ્તરના સંઘર્ષમાં, તમે પુખ્ત વયની સ્થિતિ લઈ શકો છો, ત્યાંથી તમારી આસપાસ ઘણા વધુ લોકોને લાવી શકો છો, તેના નકારાત્મક પરિણામોને ઘટાડી શકો છો. સંઘર્ષ કરો અને તેના નિરાકરણમાં ફાળો આપો.

સંઘર્ષની પરિસ્થિતિઓના થોડા ઉદાહરણો જોતા પહેલા, ચાલો કેટલાક મહત્વપૂર્ણ મુદ્દાઓ જોઈએ જે તમામ તકરારમાં સામાન્ય છે.

સંઘર્ષને ઉકેલતી વખતે, લડાઈથી ઉપર હોવું મહત્વપૂર્ણ છે, અને તેની અંદર નહીં (આને "મેટા-પોઝિશન" પણ કહેવામાં આવે છે), એટલે કે, રિઝોલ્યુશન પ્રક્રિયામાં પક્ષકારોમાંથી એકનો ભાગ ન બનવું. નહિંતર, બાહ્ય લવાદીને નિર્ણયમાં સહાયતા રાખવાથી માત્ર એક પક્ષની સ્થિતિ અન્ય પક્ષના નુકસાન માટે મજબૂત બનશે. નિર્ણય લેતી વખતે, તે મહત્વપૂર્ણ છે કે તે તમામ પક્ષો દ્વારા નૈતિક રીતે સ્વીકારવામાં આવે, કારણ કે તેઓ કહે છે, "ખરીદી." જેથી કરીને, પક્ષકારોને લીધેલા નિર્ણયથી આનંદ ન થયો હોય તો પણ, તેઓ ઓછામાં ઓછા નિષ્ઠાપૂર્વક તેનો અમલ કરવા સંમત થયા. જેમ તેઓ કહે છે, અસંમત અને પ્રતિબદ્ધ થવા માટે સક્ષમ થવા માટે. નહિંતર, સંઘર્ષ ફક્ત તેના દેખાવને બદલશે, ધૂમ્રપાન કરતી આગ પીટ બોગ હેઠળ રહેશે અને કોઈક સમયે અનિવાર્યપણે ફરીથી ભડકશે.

બીજો મુદ્દો, આંશિક રીતે પ્રથમ સાથે સંબંધિત છે, જો તમે પહેલેથી જ સંઘર્ષને ઉકેલવામાં ભાગ લેવાનું નક્કી કર્યું છે, તો તેને સંચાર અને સંદર્ભનો અભ્યાસ કરવાના દૃષ્ટિકોણથી શક્ય તેટલી ગંભીરતાથી લો. દરેક પક્ષકારો સાથે વ્યક્તિગત રીતે વાત કરો. દરેક સાથે અલગ, શરૂઆત માટે. મેલ માટે સમાધાન કરશો નહીં. વિતરિત ટીમના કિસ્સામાં, ઓછામાં ઓછી વિડિયો લિંક દ્વારા વાત કરો. સુનાવણી અને પ્રત્યક્ષદર્શી અહેવાલોથી સંતુષ્ટ થશો નહીં. વાર્તા સમજો, દરેક પક્ષ શું ઇચ્છે છે, તેઓ શા માટે ઇચ્છે છે, તેઓ શું અપેક્ષા રાખે છે, શું તેઓએ આ મુદ્દાને પહેલા ઉકેલવાનો પ્રયાસ કર્યો છે, જો તે ઉકેલવામાં નહીં આવે તો શું થશે, તેઓ કયા ઉકેલો જુએ છે, તેઓ કેવી રીતે સ્થિતિની કલ્પના કરે છે બીજી બાજુ, તેઓ શું વિચારે છે, સાચું કે ખોટું, વગેરે. દરેક જણ સાચા છે એમ માનીને ખુલ્લા મનથી તમારા માથામાં તમામ સંભવિત સંદર્ભ લોડ કરો. તમે સંઘર્ષની અંદર નથી, તમે તેની બહાર છો, મેટાપોઝિશનમાં છો. જો સંદર્ભ ફક્ત પોસ્ટ થ્રેડમાં જ ઉપલબ્ધ હોય, તો ઓછામાં ઓછું તેને સંપૂર્ણ રીતે વાંચો અને તેનાથી સંબંધિત થ્રેડો અને દસ્તાવેજો. તમે તેને વાંચ્યા પછી પણ તમારા અવાજથી બોલો. મેલમાં ન હોય તેવી કોઈ અગત્યની વાત સાંભળવાની તમને લગભગ ખાતરી છે.

ત્રીજો મહત્વનો મુદ્દો સંચાર માટે સામાન્ય અભિગમ છે. આ સામાન્ય વસ્તુઓ છે, વૈશ્વિક કંઈ નથી, પરંતુ તે ખૂબ જ મહત્વપૂર્ણ છે. અમે સમય બચાવવાનો પ્રયાસ કરતા નથી, અમે બધા સહભાગીઓ સાથે વાત કરીએ છીએ, અમે વ્યક્તિની ટીકા કરતા નથી, પરંતુ અમે તેના કાર્યોના પરિણામોને ધ્યાનમાં લઈએ છીએ ("તમે અસંસ્કારી છો" નહીં, પરંતુ "કદાચ છોકરાઓ નારાજ થઈ શકે છે. આ વસ્તુ”), અમે ચહેરો બચાવવાની તક આપીએ છીએ, અમે વ્યક્તિગત રીતે ચર્ચા કરીએ છીએ, લાઇનની સામે નહીં.

સંઘર્ષ સામાન્ય રીતે બેમાંથી એક કારણને કારણે થાય છે. પ્રથમ તે સંબંધિત છે કે શું સંઘર્ષ સમયે વ્યક્તિ પુખ્તની સ્થિતિમાં છે કે બાળકની સ્થિતિમાં (નીચે આના પર વધુ). આ તેની ભાવનાત્મક પરિપક્વતાને કારણે છે, તેની લાગણીઓને સંચાલિત કરવાની ક્ષમતા (જે, માર્ગ દ્વારા, હંમેશા તેની ઉંમર સાથે સંબંધિત નથી). બીજું સામાન્ય કારણ કાર્ય પ્રક્રિયાની અપૂર્ણતા છે, જે ગ્રે વિસ્તારોની પરિસ્થિતિઓ બનાવે છે જેમાં સહભાગીઓ વચ્ચે જવાબદારી ફેલાયેલી છે, પક્ષોની અપેક્ષાઓ એકબીજા પ્રત્યે પારદર્શક નથી અને પ્રક્રિયામાં ભૂમિકાઓ અસ્પષ્ટ છે.

તદનુસાર, તકરાર (તેમજ અન્ય કોઈપણ સમસ્યા) ઉકેલવા માટે, મેનેજરે ત્રણ પરિપ્રેક્ષ્યો ધ્યાનમાં રાખવા જોઈએ: ટૂંકા ગાળાના - અહીં અને અત્યારે સમસ્યા/સંઘર્ષને ઉકેલવા માટે, મધ્યમ ગાળાના - બીજા સંઘર્ષની સંભાવનાને ઘટાડવા માટે. સમાન કારણોસર, અને લાંબા ગાળાના - ટીમ વ્યક્તિમાં પુખ્ત સંસ્કૃતિ કેળવવા માટે.

આપણામાંના દરેકને એક આંતરિક બાળક છે, જે લગભગ ત્રણ કે ચાર વર્ષનું છે. તે મોટાભાગનો સમય કામ પર સૂઈ જાય છે, પરંતુ ક્યારેક જાગે છે અને નિયંત્રણ લે છે. બાળકની પોતાની પ્રાથમિકતાઓ હોય છે. તેના માટે આગ્રહ રાખવો મહત્વપૂર્ણ છે કે આ તેનું સેન્ડબોક્સ છે, તેની માતા તેને વધુ પ્રેમ કરે છે, તેનું મશીન શ્રેષ્ઠ છે (ડિઝાઇન શ્રેષ્ઠ છે, તે શ્રેષ્ઠ પ્રોગ્રામ કરે છે, ...). સંઘર્ષની પરિસ્થિતિમાં, બાળક રમકડાં દબાવી શકે છે, તેના પગને દબાવી શકે છે અને તેના સ્પેટુલાને ક્રેક કરી શકે છે, પરંતુ તે પુખ્ત વયના મુદ્દાઓ (સોલ્યુશન આર્કિટેક્ચર, સ્વચાલિત પરીક્ષણનો અભિગમ, પ્રકાશન તારીખો, વગેરે) હલ કરી શકતો નથી, તે લાભોની દ્રષ્ટિએ વિચારતો નથી. ટીમ માટે. સંઘર્ષમાં રહેલા બાળકને તેના પુખ્ત વ્યક્તિને બોલાવવાનું કહીને પ્રોત્સાહિત કરી શકાય છે, દિલાસો આપી શકાય છે અને પથારીમાં મોકલી શકાય છે. સંઘર્ષની પરિસ્થિતિમાં ચર્ચા શરૂ કરતા પહેલા, ખાતરી કરો કે તમે કોઈ પુખ્ત વ્યક્તિ સાથે વાત કરી રહ્યા છો, બાળક સાથે નહીં અને તમે પોતે પુખ્ત વયની સ્થિતિમાં છો. જો આ ક્ષણે તમારું પ્રામાણિક ધ્યેય ગંભીર સમસ્યાનું નિરાકરણ લાવવાનું છે, તો તમે પુખ્ત વયની સ્થિતિમાં છો. જો તમારો ધ્યેય તમારા પગને દબાવવાનો અને તમારા ખભાના બ્લેડને ક્રેક કરવાનો છે, તો આ એક બાલિશ સ્થિતિ છે. તમારા આંતરિક બાળકને પથારીમાં મોકલો અને પુખ્ત વયના વ્યક્તિને કૉલ કરો અથવા ચર્ચાને ફરીથી શેડ્યૂલ કરો. વ્યક્તિ ભાવનાત્મક નિર્ણય લે છે, અને પછી તેના માટે તર્કસંગત સમર્થન શોધે છે. બાળકોની પ્રાથમિકતાઓને આધારે બાળક દ્વારા લેવામાં આવેલ નિર્ણય શ્રેષ્ઠ રહેશે નહીં.

સંઘર્ષના સમયે વર્તન ઉપરાંત, બાળક અથવા પુખ્ત વયની સ્થિતિ પણ જવાબદારીના સ્તર દ્વારા વર્ગીકૃત થયેલ છે જે વ્યક્તિ પોતાની જાતને લેવા માટે તૈયાર છે. તેના આત્યંતિક અભિવ્યક્તિઓમાં, પ્રોગ્રામરની બાલિશ સ્થિતિ, જેને હું એક કરતા વધુ વખત મળ્યો છું, તે આના જેવો દેખાય છે: મેં કોડ લખ્યો, તેને સમીક્ષા માટે મોકલ્યો - મારું કાર્ય સમાપ્ત થયું. સમીક્ષકોએ તેની સમીક્ષા કરવી જોઈએ અને તેને મંજૂર કરવી જોઈએ, QAએ તેને તપાસવું જોઈએ, જો કોઈ સમસ્યા હોય, તો તેઓ મને જણાવશે. વિચિત્ર રીતે, એકદમ પરિપક્વ અને અનુભવી લોકો પણ ક્યારેક આ રીતે વર્તે છે. સ્કેલનો બીજો છેડો એ છે કે કોઈ વ્યક્તિ તેનો કોડ કામ કરે છે, પરીક્ષણો દ્વારા આવરી લેવામાં આવ્યો છે, તેના દ્વારા વ્યક્તિગત રીતે તપાસવામાં આવ્યો છે, સમીક્ષા સફળતાપૂર્વક પાસ થઈ છે (જો જરૂરી હોય તો, સમીક્ષકોને પિંગ કરવામાં, મુદ્દાઓની ચર્ચા કરવામાં કોઈ સમસ્યા નથી) તેની ખાતરી કરવા માટે વ્યક્તિ પોતાને જવાબદાર માને છે. અવાજ દ્વારા, વગેરે) અને દબાવવામાં આવ્યું છે, જો જરૂરી હોય તો QA સહાય પ્રદાન કરશે, પરીક્ષણ દૃશ્યો વર્ણવવામાં આવશે, વગેરે. સામાન્ય કિસ્સાઓમાં, પ્રોગ્રામર કાં તો સ્કેલના પુખ્ત વયના છેડાની નજીકથી શરૂ થાય છે, અથવા અનુભવ મેળવે તેમ ત્યાં જાય છે (જો ટીમમાં યોગ્ય સંસ્કૃતિ કેળવવામાં આવે તો). આત્યંતિક કેસોમાં, તે કામ કરવાનું ચાલુ રાખે છે, સામાન્ય રીતે બાલિશ સ્થિતિ લે છે, પછી તેને અને ટીમને સમયાંતરે સમસ્યાઓ અને તકરાર થાય છે.

ટીમમાં યોગ્ય, પરિપક્વ સંસ્કૃતિને પ્રોત્સાહન આપવું એ કોઈપણ મેનેજર માટે મહત્વપૂર્ણ કાર્ય છે. તે લાંબો સમય અને દૈનિક પ્રયત્નો લે છે, પરંતુ પરિણામ તે મૂલ્યના છે. ટીમ કલ્ચરને પ્રભાવિત કરવાની બે રીતો છે - ઉદાહરણ દ્વારા અગ્રણી (જે ચોક્કસપણે અનુસરવામાં આવશે; ટીમ હંમેશા નેતા તરફ જુએ છે) અને યોગ્ય વર્તનની ચર્ચા કરવી અને પુરસ્કાર આપવો. અહીં કંઈ પણ અસ્પષ્ટ અથવા ખૂબ જ ઔપચારિક નથી, ફક્ત સમસ્યાઓની ચર્ચા કરતી વખતે, નોંધ લો કે અહીં કંઈક કરી શકાયું હોત, ભારપૂર્વક જણાવો કે જ્યારે તે યોગ્ય રીતે નક્કી કરવામાં આવ્યું હતું ત્યારે તમે નોંધ્યું હતું, પ્રશંસા, પ્રકાશન સમીક્ષા દરમિયાન નોંધ, વગેરે.

ચાલો ઘણી સામાન્ય સંઘર્ષ પરિસ્થિતિઓને ધ્યાનમાં લઈએ, સરળથી જટિલ સુધી:

કામના મુદ્દાઓથી સંબંધિત ન હોય તેવા વિવાદો

ઘણી વાર કામ પર તકરાર થાય છે જે કામના મુદ્દાઓ સાથે સંબંધિત નથી. તેમની ઘટના અને રીઝોલ્યુશનની સરળતા સામાન્ય રીતે સહભાગીઓની ભાવનાત્મક બુદ્ધિના સ્તર, તેમની પરિપક્વતાના સ્તર સાથે સીધી રીતે સંબંધિત હોય છે અને તે કાર્ય પ્રક્રિયાની સંપૂર્ણતા અથવા અપૂર્ણતા સાથે સંબંધિત નથી.

લાક્ષણિક ઉદાહરણો: કોઈ વ્યક્તિ વૉશિંગ મશીન અથવા શાવરનો વારંવાર પૂરતો ઉપયોગ કરતું નથી, જે અન્યને ગમતું નથી, કોઈ વ્યક્તિ ભરાઈ જાય છે, જ્યારે અન્ય લોકો બારી ખોલે તો પવન આવે છે, કોઈને ખૂબ ઘોંઘાટ હોય છે, અને અન્યને કામ કરવા માટે મૌનની જરૂર હોય છે, અને તેથી પર આ પ્રકારની તકરારના ઉકેલમાં વિલંબ ન કરવો અને તેમને તેમનો માર્ગ અપનાવવા ન દેવો તે વધુ સારું છે. તેઓ જાતે જ ઉકેલશે નહીં અને દરરોજ તમને કામથી વિચલિત કરશે અને ટીમમાં વાતાવરણને ઝેર કરશે. સદનસીબે, તેમને હલ કરવી એ સામાન્ય રીતે કોઈ મોટી સમસ્યા નથી - સ્વચ્છતાની અવગણના કરનારા સાથીદાર સાથે માત્ર શાંતિથી વાત કરો (એક પછી એક, અલબત્ત), મૌન/ઠંડક પસંદ કરતા લોકો માટે આરામદાયક બેઠક પ્રદાન કરો, અવાજ-શોષી શકે તેવા હેડફોન ખરીદો અથવા પાર્ટીશનો ઇન્સ્ટોલ કરો. , વગેરે

અન્ય એક ઉદાહરણ કે જે મેં મારા કામ દરમિયાન ઘણી વખત અનુભવ્યું તે છે ટીમના સભ્યોની માનસિક અસંગતતા. કેટલાક કારણોસર, લોકો ફક્ત એક સાથે કામ કરી શકતા નથી; દરેક ક્રિયાપ્રતિક્રિયા કૌભાંડમાં સમાપ્ત થાય છે. કેટલીકવાર આ એ હકીકતને કારણે થાય છે કે લોકો કેટલાક દબાવતા મુદ્દા (સામાન્ય રીતે રાજકીય) પર ધ્રુવીય મંતવ્યો ધરાવે છે અને તેમને કામની બહાર કેવી રીતે છોડવું તે જાણતા નથી. એકબીજાને સહન કરવા અથવા તેમની વર્તણૂક બદલવા માટે તેમને સમજાવવું એ એક નિરર્થક કાર્ય છે. એક માત્ર અપવાદ હું અનુભવી શક્યો છું તે છે ખુલ્લી ધારણાવાળા યુવાન સાથીદારો; તેમની વર્તણૂક હજુ પણ સમયાંતરે વાતચીત દ્વારા ધીમે ધીમે બદલી શકાય છે. સામાન્ય રીતે સમસ્યાને વિવિધ ટીમોમાં અલગ કરીને અથવા ઓછામાં ઓછા કામ પર ખૂબ જ ભાગ્યે જ ઓવરલેપ થવાની તક પૂરી પાડીને સફળતાપૂર્વક ઉકેલવામાં આવે છે.

ઉપરોક્ત તમામ પરિસ્થિતિઓમાં, બધા સહભાગીઓ સાથે વ્યક્તિગત રીતે વાત કરવી, પરિસ્થિતિની ચર્ચા કરવી, પૂછવું કે શું તેઓ આ કેસમાં કોઈ સમસ્યા જોતા નથી, તેમના મતે, ઉકેલો શું છે તે પૂછવું અને આ કરવામાં તેમની ભાગીદારીની ખાતરી કરવી યોગ્ય છે. નિર્ણય

કાર્ય પ્રક્રિયાને ઑપ્ટિમાઇઝ કરવાના દૃષ્ટિકોણથી (મેં ઉલ્લેખ કર્યો છે તે મધ્યમ-ગાળાના પરિપ્રેક્ષ્ય), અહીં ઘણું કરી શકાતું નથી; ઑપ્ટિમાઇઝેશનનો એકમાત્ર મુદ્દો એ છે કે ટીમ બનાવતી વખતે સુસંગતતા પરિબળને ધ્યાનમાં લેવું અને લોકોને ન મૂકવા. એકસાથે અગાઉથી કોણ સંઘર્ષ કરશે.

ટીમ કલ્ચરના પરિપ્રેક્ષ્યમાં, પરિપક્વ સંસ્કૃતિ ધરાવતી ટીમોમાં આવી પરિસ્થિતિઓ ઘણી ઓછી વાર ઊભી થાય છે, જ્યાં લોકો ટીમ અને સહકર્મીઓનો આદર કરે છે અને સ્વતંત્ર રીતે સમસ્યાઓનું નિરાકરણ કેવી રીતે કરવું તે જાણે છે. વધુમાં, આવી તકરાર એવી ટીમોમાં વધુ સરળતાથી (ઘણી વખત આપમેળે) ઉકેલાય છે જ્યાં ઉચ્ચ સ્તરનો વિશ્વાસ હોય, લોકોએ લાંબા સમય સુધી સાથે કામ કર્યું હોય અને/અથવા કામની બહાર વારંવાર વાતચીત કરી હોય.

કામના મુદ્દાઓથી સંબંધિત વિરોધાભાસ:

આવા સંઘર્ષો સામાન્ય રીતે એક જ સમયે બંને કારણોસર થાય છે, બંને ભાવનાત્મક (એ હકીકત છે કે સહભાગીઓમાંથી એક પુખ્તની સ્થિતિમાં નથી) અને કાર્ય પ્રક્રિયાની અપૂર્ણતા. કદાચ સૌથી સામાન્ય પ્રકારની તકરાર કે જેનો મને સામનો કરવો પડ્યો છે તે કોડ સમીક્ષાઓ અથવા વિકાસકર્તાઓ વચ્ચે આર્કિટેક્ચર ચર્ચાઓ દરમિયાન તકરાર છે.

હું અહીં બે લાક્ષણિક કિસ્સાઓ પ્રકાશિત કરીશ:

1) પ્રથમ કિસ્સામાં, વિકાસકર્તા સહકાર્યકર પાસેથી કોડ સમીક્ષા મેળવી શકતા નથી. પેચ સમીક્ષા માટે મોકલવામાં આવે છે, અને કંઈ થતું નથી. પ્રથમ નજરમાં, બંને પક્ષો વચ્ચે કોઈ સ્પષ્ટ સંઘર્ષ નથી, પરંતુ જો તમે તેના વિશે વિચારો છો, તો આ તદ્દન સંઘર્ષ છે. કામનો મુદ્દો ઉકેલાયો નથી, પક્ષકારોમાંથી એક (સમીક્ષાની રાહ જોઈ રહ્યું છે) સ્પષ્ટ અગવડતા અનુભવે છે. આ કેસનો એક આત્યંતિક પેટા પ્રકાર એ સમુદાયમાં અથવા જુદી જુદી ટીમોમાં વિકાસ છે, જ્યારે સમીક્ષકને આ ચોક્કસ કોડમાં રસ ન હોઈ શકે, લોડિંગ અથવા અન્ય સંજોગોને લીધે, સમીક્ષા વિનંતી પર બિલકુલ ધ્યાન ન આપી શકે, અને બાહ્ય મધ્યસ્થી (બંને બાજુઓ માટે સામાન્ય મેનેજર) ) બિલકુલ અસ્તિત્વમાં નથી.

ઉકેલનો અભિગમ જે આવી પરિસ્થિતિમાં મદદ કરે છે તે લાંબા ગાળાના પરિપ્રેક્ષ્ય, પુખ્ત વયના લોકોની સંસ્કૃતિ સાથે ચોક્કસ રીતે સંબંધિત છે. પ્રથમ, સ્માર્ટ પ્રવૃત્તિ કામ કરે છે. તમારે એવી અપેક્ષા ન રાખવી જોઈએ કે સમીક્ષા પર લટકતો કોડ સમીક્ષકનું જ ધ્યાન આકર્ષિત કરશે. અમને સમીક્ષકોને તેની નોંધ લેવામાં મદદ કરવાની જરૂર છે. પિંગાની કેટલાક લોકો, સિંકેપ પર પ્રશ્ન પૂછો, ચર્ચાઓમાં ભાગ લો. દેખીતી રીતે, મદદ કરતાં આયાતને નુકસાન થવાની શક્યતા વધુ છે, તમારે સામાન્ય સમજનો ઉપયોગ કરવાની જરૂર છે. બીજું, પૂર્વ તૈયારી સારી રીતે કામ કરે છે. જો ટીમ સમજે છે કે શું થઈ રહ્યું છે અને શા માટે, આ કોડની જરૂર કેમ છે, ડિઝાઇન પર દરેક સાથે અગાઉથી ચર્ચા કરવામાં આવી છે અને તેના પર સંમત થયા છે, તો લોકો આવા કોડ પર ધ્યાન આપે છે અને તેને કાર્ય માટે સ્વીકારે છે. ત્રીજું, સત્તા કામ કરે છે. જો તમે સમીક્ષા કરવા માંગતા હો, તો ઘણી બધી સમીક્ષાઓ જાતે કરો. વાસ્તવિક તપાસો, વાસ્તવિક પરીક્ષણો અને ઉપયોગી ટિપ્પણીઓ સાથે ઉચ્ચ ગુણવત્તાની સમીક્ષાઓ કરો. જો તમારું હુલામણું નામ ટીમમાં જાણીતું છે, તો તમારા કોડની નોંધ લેવામાં આવે તેવી શક્યતા વધુ છે.

વર્કફ્લોના દૃષ્ટિકોણથી, વિકાસકર્તાને તેના અને ટીમના લક્ષ્યો હાંસલ કરવામાં મદદ કરવાના હેતુથી અહીં શક્ય સુધારાઓ યોગ્ય પ્રાથમિકતા છે (અન્યની સમીક્ષા કરો, સમુદાયને પત્રો લખો, આર્કિટેક્ચર વર્ણન, દસ્તાવેજીકરણ, પરીક્ષણો સાથેની ચર્ચામાં ભાગ લો સમુદાય, વગેરે), પેચોને ખૂબ લાંબી કતારમાં લટકતા અટકાવે છે, વગેરે.

2) કોડ અથવા ડિઝાઇન સમીક્ષાઓ દરમિયાન તકરારનો બીજો સામાન્ય કેસ તકનીકી મુદ્દાઓ, કોડિંગ શૈલી અને સાધનોની પસંદગી પરના જુદા જુદા મંતવ્યો છે. આ કિસ્સામાં ખૂબ મહત્વ એ છે કે સહભાગીઓ વચ્ચેના વિશ્વાસનું સ્તર, સમાન ટીમ સાથે જોડાયેલા અને સાથે મળીને કામ કરવાનો અનુભવ. જ્યારે સહભાગીઓમાંથી કોઈ એક બાલિશ સ્થિતિ લે છે અને વાર્તાલાપ કરનાર તેને શું કહેવા માંગે છે તે સાંભળવાનો પ્રયાસ કરતો નથી ત્યારે મૃત્યુ પામે છે. ઘણીવાર, અન્ય પક્ષ દ્વારા પ્રસ્તાવિત અભિગમ અને શરૂઆતમાં પ્રસ્તાવિત અભિગમ બંને સફળતાપૂર્વક કામ કરી શકે છે અને સૈદ્ધાંતિક રીતે કયું પસંદ કરવું તે કોઈ વાંધો નથી.

એક દિવસ, મારી ટીમના એક પ્રોગ્રામરે (ચાલો તેને પાશા કહીએ) પેકેજ ડિપ્લોયમેન્ટ સિસ્ટમમાં ફેરફારો સાથે એક પેચ તૈયાર કર્યો, જેને પડોશી વિભાગના સહકાર્યકરો દ્વારા વિકસાવવામાં અને સપોર્ટ કરવામાં આવ્યો હતો. તેમાંથી એક (ઇગોર) નો પોતાનો મજબૂત અભિપ્રાય હતો કે જ્યારે પેકેજો જમાવવામાં આવે ત્યારે Linux સેવાઓ કેવી રીતે ગોઠવવી જોઈએ. આ અભિપ્રાય પેચમાં પ્રસ્તાવિત અભિગમથી અલગ હતો, અને તેઓ સંમત થઈ શક્યા ન હતા. હંમેશની જેમ, સમયમર્યાદા સમાપ્ત થઈ રહી હતી, અને અમુક પ્રકારના નિર્ણય પર આવવું જરૂરી હતું; તેમાંથી એક માટે પુખ્ત પોઝિશન લેવી જરૂરી હતી. પાશાએ ઓળખ્યું કે બંને અભિગમોને જીવનનો અધિકાર છે, પરંતુ તે ઇચ્છતો હતો કે તેનો વિકલ્પ પસાર થાય, કારણ કે એક કે બીજા વિકલ્પમાં કોઈ સ્પષ્ટ ટેકનિકલ ફાયદા નથી.

અમારી ચર્ચા કંઈક આના જેવી દેખાતી હતી (ખૂબ જ યોજનાકીય રીતે, અલબત્ત, વાતચીત અડધા કલાક સુધી ચાલી હતી):

- પાશા, અમારી પાસે થોડા દિવસોમાં ફીચર ફ્રીઝ છે. તે મહત્વપૂર્ણ છે કે આપણે બધું એકસાથે મેળવીએ અને શક્ય તેટલી વહેલી તકે પરીક્ષણ શરૂ કરીએ. અમે ઇગોર દ્વારા કેવી રીતે મેળવી શકીએ?
- તે સેવાઓને અલગ રીતે સેટ કરવા માંગે છે, તેણે ત્યાં મારા માટે ટિપ્પણીઓ અટકી...
- અને ત્યાં શું છે, મોટા ફેરફારો, ઘણી બધી હલફલ?
- ના, એકાદ-બે કલાક કામ છે, પણ અંતે કોઈ ફરક નથી પડતો, બંને રીતે ચાલશે, આની જરૂર કેમ છે? મેં કંઈક કામ કર્યું છે, ચાલો તેને સ્વીકારીએ.
- સાંભળો, તમે કેટલા સમયથી આ બધી ચર્ચા કરો છો?
- હા, અમે હવે દોઢ અઠવાડિયાથી સમય ચિહ્નિત કરી રહ્યા છીએ.
- અમ... શું આપણે એકાદ બે કલાકમાં સમસ્યા હલ કરી શકીએ કે જેને દોઢ અઠવાડિયું લાગી ગયું હોય, અને તે ન કરી શકાય?
- સારું, હા, પણ હું નથી ઈચ્છતો કે ઈગોર એવું વિચારે કે હું અંદર આવી ગયો છું...
- સાંભળો, તમારા માટે વધુ મહત્વનું શું છે, તમારા અંદરના નિર્ણય સાથે, રિલીઝ જારી કરવા અથવા ઇગોરને મારવા? અમે તેને અવરોધિત કરી શકીએ છીએ, જો કે, પ્રકાશન સાથે ઉડવાની સારી તક છે.
- સારું... અલબત્ત, ઇગોરનું નાક સાફ કરવું તે સરસ રહેશે, પરંતુ ઠીક છે, પ્રકાશન વધુ મહત્વપૂર્ણ છે, હું સંમત છું.
- ઇગોર શું વિચારે છે તે તમારા માટે ખરેખર એટલું મહત્વનું છે? સાચું કહું તો, તે જરાય વાંધો આપતો નથી, તે ફક્ત તે વસ્તુના વિવિધ સ્થળોએ એકીકૃત અભિગમ ઇચ્છે છે જેના માટે તે જવાબદાર છે.
- સારું, ઠીક છે, તે ટિપ્પણીઓમાં પૂછે છે તેમ મને કરવા દો અને ચાલો પરીક્ષણ શરૂ કરીએ.
- આભાર, પાશા! મને ખાતરી હતી કે તમે બેમાંથી તમે વધુ પરિપક્વ હશો, જોકે ઇગોરેક તમારા કરતા મોટા છે :)

મુદ્દો ઉકેલાઈ ગયો, પ્રકાશન સમયસર પ્રકાશિત થયું, પાશાને વધુ અસંતોષ ન લાગ્યો, કારણ કે તેણે પોતે જ ઉકેલ સૂચવ્યો અને તેનો અમલ કર્યો. ઇગોર સામાન્ય રીતે ખુશ હતો, કારણ કે ... તેમના અભિપ્રાયને ધ્યાનમાં લેવામાં આવ્યો અને તેઓએ જેમ સૂચન કર્યું તેમ કર્યું.

અનિવાર્યપણે સમાન સંઘર્ષનો બીજો પ્રકાર પ્રોજેક્ટમાં તકનીકી ઉકેલો/ગ્રંથાલયો/અભિગમ વચ્ચેની પસંદગી છે, ખાસ કરીને વિતરિત ટીમમાં. એક પ્રોજેક્ટમાં, જેને C/C++ નો ઉપયોગ કરીને સ્થાન આપવામાં આવ્યું હતું, તે બહાર આવ્યું છે કે પ્રોજેક્ટનું તકનીકી સંચાલન સ્પષ્ટપણે STL (સ્ટાન્ડર્ડ ટેમ્પલેટ લાઇબ્રેરી) ના ઉપયોગની વિરુદ્ધ હતું. આ એક પ્રમાણભૂત ભાષા પુસ્તકાલય છે જે વિકાસને સરળ બનાવે છે, અને અમારી ટીમ તેની ખૂબ આદત છે. તે બહાર આવ્યું છે કે આ પ્રોજેક્ટ C++ કરતા C ની ખૂબ નજીક છે, જેણે ટીમને ખૂબ પ્રેરણા આપી નથી, કારણ કે મેનેજમેન્ટે તેમનો શ્રેષ્ઠ પ્રયાસ કર્યો અને ખરેખર શાનદાર વત્તા ખેલાડીઓની ભરતી કરી. તે જ સમયે, ટીમનો અમેરિકન ભાગ, બંને એન્જિનિયરો અને મેનેજરો, લાંબા સમયથી કંપનીમાં કામ કરતા હતા, હાલની સ્થિતિથી ટેવાયેલા હતા અને દરેક વસ્તુથી ખુશ હતા. ટીમના રશિયન ભાગને થોડા અઠવાડિયામાં (મારા સહિત) ખૂબ જ તાજેતરમાં એકસાથે લાવવામાં આવ્યો હતો. ટીમનો રશિયન ભાગ સ્પષ્ટપણે વિકાસ માટેના સામાન્ય અભિગમને છોડી દેવા માંગતો ન હતો.

બે ખંડો વચ્ચે અનંત લેખિત ચર્ચાઓ શરૂ થઈ, ત્રણ કે ચાર સ્ક્રીનો પરના પત્રો આગળ-પાછળ, જૂથ મેઇલિંગમાં અને વ્યક્તિગતમાં, પ્રોગ્રામરોથી લઈને પ્રોગ્રામરો અને મેનેજરો સુધી. જેમ કે સામાન્ય રીતે કેસ છે, આ લંબાઈના પત્રો લેખકો અને તેમના પ્રખર સમર્થકો સિવાય કોઈએ વાંચ્યું ન હતું. STL ના ટેકનિકલ ફાયદાઓ, તે કેટલું સારી રીતે ચકાસાયેલ છે, તે કેટલું સલામત છે, અને સામાન્ય રીતે, તેની સાથે જીવન કેટલું અદ્ભુત છે, અને તેના વિના તે કેટલું ભયંકર છે, તે અંગે વિવિધ દિશામાં મલ્ટિ-સ્ક્રીન વિચારો પસાર કરીને, તણાવ સાથે ચેટ્સ. .

આ બધું ખૂબ લાંબો સમય ચાલ્યું, જ્યાં સુધી મને આખરે સમજાયું કે અમે મુદ્દાના તકનીકી પાસાઓ પર ચર્ચા કરી રહ્યા છીએ, પરંતુ સમસ્યા વાસ્તવમાં તકનીકી નથી. સમસ્યા STL ના ફાયદા કે ગેરફાયદા અથવા તેના વિના કામ કરવામાં મુશ્કેલી નથી. સમસ્યા તેના બદલે સંસ્થાકીય છે. અમારે એ સમજવાની જરૂર છે કે અમે જે કંપની માટે કામ કર્યું તે કેવી રીતે કામ કરે છે. અમારામાંથી કોઈને અગાઉ આવી કંપનીમાં કામ કરવાનો અનુભવ નહોતો. બાબત એ હતી કે કોડ વિકસિત થયા પછી અને ઉત્પાદનમાં રિલીઝ થયા પછી, અન્ય ટીમો, અન્ય દેશોના સંપૂર્ણપણે અલગ લોકો દ્વારા સમર્થનનું સંચાલન કરવામાં આવ્યું હતું. હજારો ઇજનેરોની આ વિશાળ ઇજનેરી ટીમ (કુલમાં) સંપૂર્ણપણે મૂળભૂત લઘુત્તમ તકનીકી માધ્યમો જ પરવડી શકે છે, તેથી બોલવા માટે, લઘુત્તમ લઘુત્તમ. કંપનીમાં ભૌતિક રીતે સ્થાપિત એન્જિનિયરિંગ સ્ટાન્ડર્ડથી આગળ વધેલી કોઈપણ વસ્તુને ભવિષ્યમાં સમર્થન આપી શકાશે નહીં. ટીમનું સ્તર તેના સૌથી નબળા સભ્યોના સ્તર દ્વારા નક્કી કરવામાં આવે છે. અમે સમજ્યા પછી વાસ્તવિક પ્રેરણા ટીમના અમેરિકન ભાગની ક્રિયાઓ, આ મુદ્દાને કાર્યસૂચિમાંથી દૂર કરવામાં આવ્યો હતો, અને સાથે મળીને અમે કંપની દ્વારા અપનાવવામાં આવેલા ધોરણોનો ઉપયોગ કરીને ઉત્પાદનને સફળતાપૂર્વક વિકસાવ્યું અને બહાર પાડ્યું. આ કિસ્સામાં પત્રો અને ચેટ્સ સારી રીતે કામ કરી શક્યા ન હતા; સામાન્ય સંપ્રદાયમાં આવવા માટે તેને ઘણી ટ્રિપ્સ અને ઘણી બધી વ્યક્તિગત વાતચીત કરવી પડી હતી.

વર્કફ્લોના દૃષ્ટિકોણથી, આ ચોક્કસ કિસ્સામાં, તે ઉપયોગમાં લેવાતા સાધનોનું વર્ણન, તેમના માટેની આવશ્યકતાઓ, નવા ઉમેરવા પરના પ્રતિબંધો અને આવા પ્રતિબંધોને વાજબી ઠેરવવામાં મદદ કરશે. આવા દસ્તાવેજો અંદાજે ફકરામાં વર્ણવેલ "સોફ્ટવેર ડેવલપમેન્ટ માટે મેનેજરની હેન્ડબુક" ના પુનઃઉપયોગ વ્યૂહરચના અને વિકાસ પર્યાવરણને અનુરૂપ છે, નાસા. તેની ઉંમર હોવા છતાં, તે આ પ્રકારના સોફ્ટવેર ડેવલપમેન્ટની તમામ મુખ્ય પ્રવૃત્તિઓ અને આયોજન તબક્કાઓનું સંપૂર્ણ રીતે વર્ણન કરે છે. આના જેવા દસ્તાવેજો રાખવાથી ઉત્પાદનમાં કયા ઘટકો અને અભિગમોનો ઉપયોગ કરી શકાય છે અને શા માટે તે ચર્ચા કરવાનું ખૂબ જ સરળ બનાવે છે.

સાંસ્કૃતિક દૃષ્ટિકોણથી, દેખીતી રીતે, વધુ પરિપક્વ સ્થિતિ સાથે, જેમાં પક્ષકારો તેમના સાથીદારોની ક્રિયાઓની વાસ્તવિક પ્રેરણા સાંભળવાનો અને સમજવાનો પ્રયાસ કરે છે અને પ્રોજેક્ટ અને ટીમની પ્રાથમિકતાઓના આધારે કાર્ય કરે છે, અને વ્યક્તિગત અહંકારને આધારે નહીં. , સંઘર્ષ સરળ અને ઝડપી ઉકેલવામાં આવશે.

તકનીકી ઉકેલની પસંદગી અંગેના અન્ય સંઘર્ષમાં, મને એક પક્ષની પ્રેરણા સમજવામાં નોંધપાત્ર સમય લાગ્યો (તે ખૂબ જ અસામાન્ય કેસ હતો), પરંતુ પ્રેરણા સ્પષ્ટ થયા પછી, ઉકેલ સ્પષ્ટ હતો.

પરિસ્થિતિ આ છે: લગભગ 20 લોકોની ટીમમાં એક નવો વિકાસકર્તા દેખાય છે, ચાલો તેને સ્ટેસ કહીએ. તે સમયે, એક ટીમ તરીકે સંદેશાવ્યવહાર માટેનું અમારું પ્રમાણભૂત સાધન Skype હતું. જેમ કે તે પછીથી બહાર આવ્યું, સ્ટેસ ઓપન સ્ટાન્ડર્ડ્સ અને ઓપન સોર્સ સોફ્ટવેરનો મોટો ચાહક હતો, અને તે માત્ર એવા સાધનો અને ઓપરેટિંગ સિસ્ટમનો ઉપયોગ કરતો હતો કે જેના સ્ત્રોતો સાર્વજનિક રીતે ઉપલબ્ધ હતા અને જે જાહેરમાં વર્ણવેલ પ્રોટોકોલનો ઉપયોગ કરતા હતા. સ્કાયપે આમાંથી એક સાધન નથી. અમે આ અભિગમના ફાયદા અને ગેરફાયદા વિશે ચર્ચા કરવામાં ઘણો સમય વિતાવ્યો, વિવિધ ઑપરેટિંગ સિસ્ટમ્સ પર સ્કાયપેના એનાલોગ શરૂ કરવાના પ્રયાસો, ટીમને અન્ય ધોરણો પર સ્વિચ કરવા માટે સ્ટેસના પ્રયાસો, તેમને વ્યક્તિગત રૂપે મેઇલ દ્વારા લખો, તેમને વ્યક્તિગત રીતે કૉલ કરો. ફોન, ખાસ કરીને Skype વગેરે માટે તેને બીજું કમ્પ્યુટર ખરીદો. છેવટે, મને સમજાયું કે આ સમસ્યા, સારમાં, તકનીકી અથવા સંસ્થાકીય નથી, તે તેના બદલે વૈચારિક છે, એક પણ કહી શકે છે, ધાર્મિક (સ્ટેસ માટે). જો આપણે આખરે Stas અને Skype ને કનેક્ટ કર્યું હોય (જેમાં ઘણા મહિનાઓ લાગ્યા), તો પછીના કોઈપણ સાધન પર સમસ્યા ફરીથી ઊભી થશે. સ્ટેસના વિશ્વ દૃષ્ટિકોણને બદલવા માટે મારી પાસે કોઈ વાસ્તવિક માધ્યમ નહોતું, અને આ વાતાવરણમાં સંપૂર્ણ રીતે કામ કરતી ટીમના વિશ્વ દૃષ્ટિકોણને બદલવાનો પ્રયાસ કરવાનું કોઈ કારણ નહોતું. વ્યક્તિ અને કંપની તેમના વિશ્વ દૃષ્ટિકોણમાં ફક્ત ઓર્થોગોનલ હતા. આવી પરિસ્થિતિઓમાં, એક સારો ઉકેલ સંગઠનાત્મક છે. અમે સ્ટેસને બીજી ટીમમાં સ્થાનાંતરિત કર્યો, જ્યાં તે વધુ કાર્બનિક હતો.

આ સંઘર્ષનું કારણ, મારા મતે, કોઈ ચોક્કસ વ્યક્તિની વ્યક્તિગત સંસ્કૃતિ (જેનો મજબૂત અભિપ્રાય છે જે તેને સમાધાન કરવાની મંજૂરી આપતું નથી) અને કંપનીની સંસ્કૃતિ વચ્ચેની વિસંગતતા છે. આ કિસ્સામાં, તે, અલબત્ત, મેનેજરની ભૂલ છે. શરૂઆતમાં તેને આ પ્રકારના પ્રોજેક્ટમાં લેવાનું ખોટું હતું. Stas આખરે એક ઓપન સોર્સ સોફ્ટવેર ડેવલપમેન્ટ પ્રોજેક્ટમાં ખસેડવામાં આવ્યો અને ત્યાં શ્રેષ્ઠ દેખાવ કર્યો.

વિકાસકર્તાના બાલિશ વલણ અને કાર્ય પ્રક્રિયાની ખામીઓ બંનેને કારણે થતા સંઘર્ષનું એક સારું ઉદાહરણ એ એવી પરિસ્થિતિ છે કે જેમાં, પૂર્ણની વ્યાખ્યાની ગેરહાજરીમાં, વિકાસકર્તા અને QA ટીમની તૈયારી અંગે જુદી જુદી અપેક્ષાઓ હોય છે. સુવિધા QA માં સ્થાનાંતરિત. વિકાસકર્તાનું માનવું હતું કે કોડ લખવા અને સુવિધાને વાડ ઉપર QA પર ફેંકી દેવા માટે તે પૂરતું છે - તેઓ તેને ત્યાં સૉર્ટ કરશે. એકદમ પરિપક્વ અને અનુભવી પ્રોગ્રામર, માર્ગ દ્વારા, પરંતુ તે ગુણવત્તા માટે તેની આંતરિક થ્રેશોલ્ડ હતી. QA આની સાથે અસંમત હતો અને તેણે પોતે શું તપાસ્યું હતું તે બતાવવા અને તેનું વર્ણન કરવાની માંગ કરી અને તેમના માટે પરીક્ષણ સ્ક્રિપ્ટની માંગણી કરી. તેઓને ભૂતકાળમાં આ ડેવલપરની કાર્યક્ષમતામાં સમસ્યા હતી અને તેઓ ફરીથી તેમનો સમય બગાડવા માંગતા ન હતા. માર્ગ દ્વારા, તેઓ સાચા હતા - સુવિધા ખરેખર કામ કરતી ન હતી, તેણે QA ને મોકલતા પહેલા કોડ તપાસ્યો ન હતો.

પરિસ્થિતિને ઉકેલવા માટે, મેં તેને મને બતાવવા કહ્યું કે બધું ખરેખર કામ કરે છે (તે કામ કરતું નથી, અને તેણે તેને ઠીક કરવું પડશે), અમે ટીમ સાથે વાત કરી અને પૂર્ણની QA વ્યાખ્યા સાથે વાત કરી (તેઓએ તે કર્યું નથી. લેખન, કારણ કે અમે પ્રક્રિયાને વધુ અમલદારશાહી બનાવવા માંગતા ન હતા ), સારું, અમે ટૂંક સમયમાં આ નિષ્ણાત (સામાન્ય રાહત માટે) સાથે અલગ થઈ ગયા.

વર્કફ્લોના દૃષ્ટિકોણથી, આ કિસ્સામાં શક્ય સુધારાઓ એ પૂર્ણની વ્યાખ્યાની હાજરી, દરેક એકમ વિશેષતા અને એકીકરણ પરીક્ષણોના સમર્થન માટેની આવશ્યકતાઓ અને વિકાસકર્તા દ્વારા હાથ ધરવામાં આવેલા પરીક્ષણનું વર્ણન છે. એક પ્રોજેક્ટમાં, અમે CI દરમિયાન પરીક્ષણો દ્વારા કોડ કવરેજનું સ્તર માપ્યું અને જો પેચ ઉમેર્યા પછી કવરેજનું સ્તર ઘટી ગયું, તો પરીક્ષણોને નિષ્ફળ તરીકે ચિહ્નિત કરવામાં આવ્યા હતા, એટલે કે. કોઈપણ નવો કોડ ફક્ત ત્યારે જ ઉમેરી શકાય છે જો તેના માટે નવા પરીક્ષણો હોય.

કાર્ય પ્રક્રિયાના સંગઠન સાથે નજીકથી સંબંધિત સંઘર્ષનું બીજું લાક્ષણિક ઉદાહરણ. અમારી પાસે ઉત્પાદન, ઉત્પાદન વિકાસ ટીમ, સહાયક ટીમ અને ગ્રાહક છે. ગ્રાહકને ઉત્પાદન અને સંપર્કોના સમર્થનમાં સમસ્યા છે. સપોર્ટ સમસ્યાનું વિશ્લેષણ કરે છે અને સમજે છે કે સમસ્યા ઉત્પાદનમાં છે અને સમસ્યાને ઉત્પાદન ટીમમાં સ્થાનાંતરિત કરે છે. પ્રોડક્ટ ટીમ વ્યસ્ત સમયમાં છે, રિલીઝ નજીક આવી રહી છે, તેથી ગ્રાહકની સમસ્યાવાળી ટિકિટ, જે વિકાસકર્તાને સોંપવામાં આવી છે તેની અન્ય ટિકિટો વચ્ચે ખોવાઈ ગઈ છે, તે ધ્યાન આપ્યા વિના કેટલાક અઠવાડિયા સુધી અટકી જાય છે. આધાર વિચારે છે કે વિકાસકર્તા ગ્રાહકની સમસ્યા પર કામ કરી રહ્યો છે. ગ્રાહક રાહ જુએ છે અને આશા રાખે છે કે તેમની સમસ્યા પર કામ કરવામાં આવી રહ્યું છે. વાસ્તવિકતામાં, હજી સુધી કંઈ થઈ રહ્યું નથી. થોડા અઠવાડિયા પછી, ગ્રાહક આખરે પ્રગતિમાં રસ લેવાનું નક્કી કરે છે અને સપોર્ટને પૂછે છે કે વસ્તુઓ કેવી રીતે ચાલી રહી છે. આધાર વિકાસ માટે પૂછે છે. વિકાસકર્તા ધ્રૂજી જાય છે, ટિકિટોની યાદી જુએ છે અને ત્યાંના ગ્રાહક પાસેથી ટિકિટ શોધે છે. ગ્રાહક પાસેથી ટિકિટ વાંચીને, તે સમજે છે કે સમસ્યા હલ કરવા માટે પૂરતી માહિતી નથી, અને તેને વધુ લોગ અને ડમ્પની જરૂર છે. આધાર ગ્રાહક પાસેથી વધારાની માહિતીની વિનંતી કરે છે. અને પછી ગ્રાહકને ખ્યાલ આવે છે કે આટલા સમય સુધી તેની સમસ્યા પર કોઈ કામ કરતું નથી. અને ગાજવીજ પડશે...

આ પરિસ્થિતિમાં, સંઘર્ષનો ઉકેલ પોતે એકદમ સ્પષ્ટ અને રેખીય છે (ઉત્પાદનને ઠીક કરો, દસ્તાવેજીકરણ અને પરીક્ષણો અપડેટ કરો, ગ્રાહકને ખુશ કરો, હોટફિક્સ છોડો, વગેરે). કાર્ય પ્રક્રિયાનું વિશ્લેષણ કરવું અને બે ટીમો વચ્ચેની ક્રિયાપ્રતિક્રિયાનું આયોજન કરવા માટે કોણ જવાબદાર છે તે સમજવું અને આ પરિસ્થિતિ શા માટે પ્રથમ સ્થાને શક્ય બની તે મહત્વનું છે. તે સ્પષ્ટ છે કે પ્રક્રિયામાં શું ઠીક કરવાની જરૂર છે - કોઈએ ગ્રાહકોના રીમાઇન્ડર વિના, સક્રિયપણે એકંદર ચિત્રનું નિરીક્ષણ કરવું જોઈએ. ગ્રાહકની ટિકિટો વિકાસકર્તાઓની અન્ય ટિકિટો વચ્ચે અલગ હોવી જોઈએ. સપોર્ટ એ જોવું જોઈએ કે શું ડેવલપમેન્ટ ટીમ હાલમાં તેની ટિકિટ પર કામ કરી રહી છે, અને જો નહીં, તો તે ક્યારે કામ કરવાનું શરૂ કરી શકે છે અને ક્યારે પરિણામોની અપેક્ષા રાખી શકાય છે. સપોર્ટ અને ડેવલપમેન્ટે સમયાંતરે ટિકિટની સ્થિતિ વિશે વાતચીત અને ચર્ચા કરવી જોઈએ, ડિબગીંગ માટે જરૂરી માહિતીનો સંગ્રહ શક્ય તેટલો સ્વચાલિત હોવો જોઈએ, વગેરે.

જેમ યુદ્ધમાં દુશ્મન બે એકમો વચ્ચેના જંકશનને મારવાનો પ્રયાસ કરે છે, તેવી જ રીતે કામમાં સૌથી નાજુક અને સંવેદનશીલ બિંદુ સામાન્ય રીતે ટીમો વચ્ચેની ક્રિયાપ્રતિક્રિયા છે. જો સપોર્ટ અને ડેવલપમેન્ટ મેનેજર પૂરતા પ્રમાણમાં જૂના હોય, તો તેઓ પ્રક્રિયાને જાતે જ ઠીક કરી શકશે, જો નહીં, તો જ્યાં સુધી મેનેજર પરિસ્થિતિને ઠીક કરી શકે તે દરમિયાનગીરી ન કરે ત્યાં સુધી પ્રક્રિયા તકરાર અને સમસ્યાઓ પેદા કરતી રહેશે.

અન્ય એક વિશિષ્ટ ઉદાહરણ જે મેં વિવિધ કંપનીઓમાં વારંવાર જોયું છે તે એવી પરિસ્થિતિ છે કે જેમાં ઉત્પાદન એક ટીમ દ્વારા લખવામાં આવે છે, તેના માટે સ્વચાલિત સંકલન પરીક્ષણો બીજી ટીમ દ્વારા લખવામાં આવે છે, અને ઇન્ફ્રાસ્ટ્રક્ચર કે જેના પર તે બધું સંચાલિત થાય છે તે ત્રીજી સાથે હોય છે. ટીમ પરીક્ષણો ચલાવતી વખતે સમસ્યાઓ હંમેશા ઊભી થાય છે, અને તેમાં સમસ્યાઓનું કારણ ઉત્પાદન અને પરીક્ષણો અને ઈન્ફ્રાસ્ટ્રક્ચર બંને હોઈ શકે છે. સમસ્યાઓ, ફાઇલ બગ્સ, ઉત્પાદનના લોગ પાર્સ, પરીક્ષણો અને ઈન્ફ્રાસ્ટ્રક્ચર વગેરેનું પ્રારંભિક વિશ્લેષણ કોણે કરવું જોઈએ તેના પર સંમત થવું સામાન્ય રીતે સમસ્યારૂપ છે. અહીં સંઘર્ષો ખૂબ જ વારંવાર થાય છે, અને, તે જ સમયે, એકસમાન. ઉચ્ચ ભાવનાત્મક તીવ્રતાના કિસ્સામાં, સહભાગીઓ ઘણીવાર બાલિશ સ્થિતિમાં આવે છે અને શ્રેણીમાં ચર્ચાઓ શરૂ થાય છે: "મારે આ સાથે શા માટે ટિંકર કરવું જોઈએ," "તેઓ વધુ વખત તૂટી જાય છે," વગેરે.

વર્કફ્લોના પરિપ્રેક્ષ્યમાં, સમસ્યાને ઉકેલવા માટેના ચોક્કસ પગલાં ટીમોની રચના, પરીક્ષણોના પ્રકાર અને ઉત્પાદન વગેરે પર આધાર રાખે છે. એક પ્રોજેક્ટમાં, અમે સામયિક ડ્યુટી રજૂ કરી, જેમાં ટીમોએ એક પછી એક પરીક્ષણો, અઠવાડિયા દર અઠવાડિયે મોનિટર કર્યા. અન્યમાં, પ્રારંભિક વિશ્લેષણ હંમેશા પરીક્ષણ વિકાસકર્તાઓ દ્વારા કરવામાં આવતું હતું, પરંતુ વિશ્લેષણ ખૂબ જ મૂળભૂત હતું અને ઉત્પાદન તદ્દન સ્થિર હતું, તેથી તે સારી રીતે કામ કર્યું હતું. મુખ્ય બાબત એ સુનિશ્ચિત કરવાની છે કે પ્રક્રિયા પારદર્શક છે, તમામ પક્ષો માટે અપેક્ષાઓ સ્પષ્ટ છે અને પરિસ્થિતિ દરેકને ન્યાયી લાગે છે.

શું સંસ્થામાં સંઘર્ષ પણ એક સમસ્યા છે? શું તે ખરાબ સંકેત છે કે તમારી ટીમમાં વારંવાર (અથવા માત્ર સમયાંતરે) તકરાર થાય છે? સામાન્ય રીતે, ના, કારણ કે જો ત્યાં વૃદ્ધિ, વિકાસ હોય, કોઈ પ્રકારની ગતિશીલતા હોય, તો પછી એવા મુદ્દાઓ ઉદ્ભવે છે જે પહેલાં ક્યારેય ઉકેલાયા નથી, અને જ્યારે તેમને હલ કરવામાં આવે છે, ત્યારે તકરાર ઊભી થઈ શકે છે. આ એક સૂચક છે કે કેટલાક ક્ષેત્રો પર ધ્યાન આપવાની જરૂર છે, કે સુધારણા માટેના ક્ષેત્રો છે. તે ખરાબ છે જો તકરાર ઘણી વાર થાય, ઉકેલવામાં મુશ્કેલ હોય અથવા લાંબો સમય લાગે. આ મોટે ભાગે અપૂરતી સુવ્યવસ્થિત કાર્ય પ્રક્રિયાઓ અને ટીમની અપૂરતી પરિપક્વતાની નિશાની છે.

સોર્સ: www.habr.com