પ્રોગ્રામરોની ટીમનું સંચાલન કરવું: કેવી રીતે અને કેવી રીતે તેમને યોગ્ય રીતે પ્રોત્સાહિત કરવા? બીજો ભાગ

એપિગ્રાફ:
પતિ, ગમગીન બાળકોને જોઈને, તેની પત્નીને કહે છે: સારું, આપણે આને ધોઈશું કે નવા જન્મ આપીશું?

કટ નીચે અમારી ટીમ લીડર, તેમજ RAS પ્રોડક્ટ ડેવલપમેન્ટ ડિરેક્ટર ઇગોર માર્નાટના લેખનો બીજો ભાગ છે, પ્રોગ્રામરોને પ્રોત્સાહિત કરવાની વિશિષ્ટતાઓ વિશે. લેખનો પ્રથમ ભાગ અહીં મળી શકે છે - habr.com/ru/company/parallels/blog/452598

લેખના પહેલા ભાગમાં, મેં માસ્લોના પિરામિડના બે નીચલા સ્તરોને સ્પર્શ કર્યો: શારીરિક જરૂરિયાતો, સલામતી, આરામ અને સ્થિરતા માટેની જરૂરિયાતો અને આગલા, ત્રીજા સ્તર પર આગળ વધો, એટલે કે:

ત્રીજા - સંબંધ અને પ્રેમની જરૂર છે

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

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

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

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

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

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

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

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

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

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

IV. ઓળખાણની જરૂર છે

એક દયાળુ શબ્દ પણ બિલાડીને ખુશ કરે છે. દરેક વ્યક્તિ પોતે કરેલા કાર્યના મહત્વની માન્યતા અને તેના હકારાત્મક મૂલ્યાંકન દ્વારા પ્રેરિત થાય છે. પ્રોગ્રામરો સાથે વાત કરો, તેમને સમયાંતરે પ્રતિસાદ આપો, સારી રીતે કરેલા કામની ઉજવણી કરો. જો તમારી પાસે મોટી અને વિતરિત ટીમ હોય, તો સામયિક મીટિંગ્સ (જેને એકથી એક કહેવાય છે) આ માટે યોગ્ય છે; જો ટીમ ખૂબ નાની હોય અને સ્થાનિક રીતે સાથે કામ કરે, તો આ તક સામાન્ય રીતે કૅલેન્ડર પર વિશેષ મીટિંગ્સ વિના પ્રદાન કરવામાં આવે છે (જોકે સામયિક એક એક માટે તે હજી પણ જરૂરી છે, તમે તેને ઓછી વાર કરી શકો છો). manager-tools.com પરના મેનેજરો માટેના પોડકાસ્ટમાં આ વિષય સારી રીતે આવરી લેવામાં આવ્યો છે.

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

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

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

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

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

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

V. સમજશક્તિ અને સ્વ-વાસ્તવિકકરણની જરૂરિયાત.

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

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

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

જો આ ટીમમાં તેમની પાછળ 15-20 વર્ષનો અનુભવ ધરાવતા પ્રોગ્રામરો હોય, તો પ્રેરણા અલગ હશે. ઉંમર અને અનુભવ, અલબત્ત, 100% નિર્ણાયક પરિબળો નથી; તે બધું પ્રેરણાની રચના પર આધારિત છે. આ ચોક્કસ કિસ્સામાં, યુવા પ્રોગ્રામરોની જ્ઞાન અને વૃદ્ધિની ઇચ્છાએ ઉત્તમ પરિણામો આપ્યા છે.

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

માસ્લોના પિરામિડથી આગળ: પરિણામોની દૃશ્યતા, ગેમિફિકેશન અને સ્પર્ધા, કોઈ બુલશીટ નહીં

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

પ્રથમ પરિણામની દૃશ્યતા અને નિકટતા છે.

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

આ પ્રેરણા અમુક અંશે કોમ્પ્યુટર ગેમ્સ પૂર્ણ કરતી વખતે ખેલાડીઓ જે અનુભવે છે તેના જેવી જ છે: તેઓ દરેક સ્તરને પૂર્ણ કરે છે ત્યારે તેઓ સમયાંતરે મેડલ, પોઈન્ટ્સ, બોનસ મેળવે છે; આને "ડોપામાઈન પ્રેરણા" કહી શકાય.

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

બીજો મુદ્દો ગેમિફિકેશન અને સ્પર્ધા છે.

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

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

અને અંતે, ત્રીજો મુદ્દો - કોઈ બુલશીટ નહીં.

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

સોર્સ: www.habr.com