પુસ્તક “બૌદ્ધિકોનું સંચાલન કેવી રીતે કરવું. હું, અભ્યાસુઓ અને ગીક્સ"

પ્રોજેક્ટ મેનેજરોને સમર્પિત (અને જેઓ બોસ બનવાનું સ્વપ્ન જુએ છે).

ઘણા બધા કોડ લખવા મુશ્કેલ છે, પરંતુ લોકોને મેનેજ કરવું તે પણ મુશ્કેલ છે! તેથી બંને કેવી રીતે કરવું તે શીખવા માટે તમારે ફક્ત આ પુસ્તકની જરૂર છે.

શું રમુજી વાર્તાઓ અને ગંભીર પાઠને જોડવાનું શક્ય છે? માઈકલ લોપ (જેને સાંકડા વર્તુળોમાં રેન્ડ્સ તરીકે પણ ઓળખવામાં આવે છે) સફળ થયા. તમને અવિશ્વસનીય લાભદાયી (કાલ્પનિક હોવા છતાં) અનુભવો ધરાવતા કાલ્પનિક લોકો વિશે કાલ્પનિક વાર્તાઓ મળશે. આ રીતે રેન્ડ્સ મોટા IT કોર્પોરેશનોમાં કામ કરવાના વર્ષોમાં મેળવેલ તેના વૈવિધ્યસભર, ક્યારેક વિચિત્ર અનુભવો શેર કરે છે: Apple, Pinterest, Palantir, Netscape, Symantec, વગેરે.

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

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

અવતરણ. એન્જિનિયરિંગ માનસિકતા

પરના વિચારો: તમારે કોડ લખવાનું ચાલુ રાખવું જોઈએ?

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

લવચીક રહો!

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

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

કોડ લખવાનું બંધ કરો!

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

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

સારી સલાહ, બરાબર ને? સ્કેલ. મેનેજમેન્ટ. જવાબદારી. આવા સામાન્ય buzzwords. તે દયાની વાત છે કે સલાહ ખોટી છે.

ખોટું?

હા. સલાહ ખોટી છે! સંપૂર્ણપણે ખોટું નથી, પરંતુ એટલું ખોટું છે કે મારે કેટલાક ભૂતપૂર્વ સાથીદારોને કૉલ કરવો પડ્યો અને માફી માંગવી પડી: “તમારે કોડ લખવાનું કેવી રીતે બંધ કરવું તે વિશે મારું તે પ્રિય નિવેદન યાદ રાખો? તે ખોટું છે! હા... ફરીથી પ્રોગ્રામિંગ શરૂ કરો. પાયથોન અને રૂબીથી શરૂઆત કરો. હા, હું ગંભીર છું! તમારી કારકિર્દી તેના પર નિર્ભર છે!”

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

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

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

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

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

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

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

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

કોડ લખવાનું બંધ કરો, પણ...

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

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

તમને વાંધો છે. સમજવું. ચાલો સાંભળીએ.

“રેન્ડ્સ, હું ડિરેક્ટરની ખુરશી તરફ જવાનો છું! જો હું કોડ લખતો રહીશ, તો કોઈ માનશે નહીં કે હું વિકાસ કરી શકું છું.

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

મારી સલાહ એ છે કે તમારા આગલા ઉત્પાદન માટે ઘણી બધી સુવિધાઓ લાગુ કરવા માટે તમારી જાતને પ્રતિબદ્ધ ન કરો. તમારી ટીમ કેવી રીતે સૉફ્ટવેર બનાવી રહી છે તેની ટોચ પર રહેવા માટે તમારે સતત પગલાં લેવાની જરૂર છે. તમે ડિરેક્ટર તરીકે અને વાઇસ પ્રેસિડેન્ટ બંને તરીકે આ કરી શકો છો. કંઈક બીજું?

“ઓહ, રેન્ડ્સ! પરંતુ કોઈએ લવાદી બનવું પડશે! કોઈએ મોટું ચિત્ર જોવું પડશે. જો હું કોડ લખીશ, તો હું પરિપ્રેક્ષ્ય ગુમાવીશ."

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

એન્જિનિયરિંગ માનસિકતા જાળવવા માટેની મારી ટીપ્સ:

1. વિકાસ વાતાવરણનો ઉપયોગ કરો. આનો અર્થ એ છે કે તમારે કોડ બિલ્ડ સિસ્ટમ, સંસ્કરણ નિયંત્રણ અને પ્રોગ્રામિંગ ભાષા સહિત તમારી ટીમના સાધનોથી પરિચિત હોવા જોઈએ. પરિણામે, પ્રોડક્ટ ડેવલપમેન્ટ વિશે વાત કરતી વખતે તમારી ટીમ જે ભાષા વાપરે છે તેમાં તમે અસ્ખલિત બની જશો. આ તમને તમારા મનપસંદ ટેક્સ્ટ એડિટરનો ઉપયોગ કરવાનું ચાલુ રાખવાની પણ મંજૂરી આપશે, જે સંપૂર્ણ રીતે કાર્ય કરી રહ્યું છે.
2. તમે કોઈપણ સમયે કોઈપણ સપાટી પર તમારા ઉત્પાદનનું વર્ણન કરતું વિગતવાર આર્કિટેક્ચરલ ડાયાગ્રામ દોરવામાં સમર્થ હોવા જોઈએ. હવે મારો મતલબ ત્રણ કોષો અને બે તીરો સાથેનું સરળ સંસ્કરણ નથી. તમારે ઉત્પાદનની વિગતવાર આકૃતિ જાણવી આવશ્યક છે. સૌથી મુશ્કેલ એક. માત્ર કોઈ સુંદર આકૃતિ જ નહીં, પરંતુ એક આકૃતિ જે સમજાવવી મુશ્કેલ છે. તે ઉત્પાદનની સંપૂર્ણ સમજ માટે યોગ્ય નકશો હોવો જોઈએ. તે સતત બદલાતું રહે છે, અને તમારે હંમેશા જાણવું જોઈએ કે ચોક્કસ ફેરફારો શા માટે થયા.
3. કાર્યોમાંથી એકના અમલીકરણને હાથમાં લો. જ્યારે હું આ લખું છું ત્યારે હું શાબ્દિક રીતે વિચલિત થઈ રહ્યો છું કારણ કે આ બિંદુમાં ઘણાં છુપાયેલા જોખમો છે, પરંતુ મને ખરેખર ખાતરી નથી કે તમે ઓછામાં ઓછી એક વિશેષતા લાગુ કર્યા વિના બિંદુ #1 અને બિંદુ #2 પૂર્ણ કરી શકશો. એક વિશેષતાનો જાતે અમલ કરીને, તમે માત્ર વિકાસની પ્રક્રિયામાં સક્રિયપણે સામેલ થશો જ નહીં, તે તમને સમયાંતરે "દરેક વસ્તુના ચાર્જ મેનેજર" ની ભૂમિકામાંથી "એક અમલીકરણના પ્રભારી માણસ" ની ભૂમિકા પર સ્વિચ કરવાની પણ મંજૂરી આપશે. કાર્યોની." આ નમ્ર અને નમ્ર વલણ તમને નાના નિર્ણયોના મહત્વની યાદ અપાવશે.
4. હું હજી પણ આખી ધ્રુજારી કરું છું. એવું લાગે છે કે કોઈ પહેલેથી જ મારા પર ચીસો પાડી રહ્યું છે: “મેનેજર કે જેમણે ફંક્શનના અમલીકરણની જવાબદારી લીધી?! (અને હું તેની સાથે સંમત છું!) હા, તમે હજી પણ મેનેજર છો, જેનો અર્થ છે કે તે કોઈ નાનું કાર્ય હોવું જોઈએ, ઠીક છે? હા, તમારે હજુ ઘણું કરવાનું બાકી છે. જો તમે ફંક્શનના અમલીકરણ પર ધ્યાન આપી શકતા નથી, તો મારી પાસે તમારા માટે કેટલીક વધારાની સલાહ છે: કેટલીક ભૂલોને ઠીક કરો. આ કિસ્સામાં, તમે સર્જનનો આનંદ અનુભવશો નહીં, પરંતુ તમને ઉત્પાદન કેવી રીતે બનાવવામાં આવે છે તેની સમજ હશે, જેનો અર્થ છે કે તમે ક્યારેય કામથી દૂર નહીં રહેશો.
5. એકમ પરીક્ષણો લખો. જ્યારે લોકો પાગલ થવા લાગે છે ત્યારે હું હજી પણ પ્રોડક્શન સાયકલમાં આ મોડું કરું છું. તેને તમારા ઉત્પાદન માટે આરોગ્ય ચેકલિસ્ટ તરીકે વિચારો. આ વારંવાર કરો.

ફરી વાંધો?

“રેન્ડ્સ, જો હું કોડ લખીશ, તો હું મારી ટીમને મૂંઝવણમાં મૂકીશ. તેઓ જાણતા નથી કે હું કોણ છું - મેનેજર કે ડેવલપર."

ગુડ

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

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

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

વિકાસ કરવાનું બંધ કરશો નહીં

બોરલેન્ડ ખાતે મારા એક સાથીદારે એકવાર તેણીને "કોડર" કહેવા બદલ મારા પર મૌખિક હુમલો કર્યો.

“રૅન્ડ્સ, કોડર એક અવિચારી મશીન છે! વાનર! નકામી કોડની કંટાળાજનક રેખાઓ લખવા સિવાય કોડર કંઈ મહત્વનું કામ કરતું નથી. હું કોડર નથી, હું સોફ્ટવેર ડેવલપર છું!"

તેણી સાચી હતી, તેણીએ નવા સીઈઓને મારી પ્રારંભિક સલાહને નફરત કરી હશે: "કોડ લખવાનું બંધ કરો!" એટલા માટે નહીં કે હું સૂચવે છે કે તેઓ કોડર છે, પરંતુ વધુ કારણ કે હું સક્રિયપણે સૂચવી રહ્યો છું કે તેઓ તેમના કામના સૌથી મહત્વપૂર્ણ ભાગોમાંના એકને અવગણવાનું શરૂ કરે છે: સોફ્ટવેર ડેવલપમેન્ટ.

તેથી મેં મારી સલાહ અપડેટ કરી છે. જો તમે સારા નેતા બનવા માંગતા હો, તો તમે કોડ લખવાનું બંધ કરી શકો છો, પરંતુ...

લવચીક બનો. એન્જીનિયર બનવાનો અર્થ શું છે તે યાદ રાખો અને સોફ્ટવેર વિકસાવવાનું બંધ કરશો નહીં.

લેખક વિશે

માઈકલ લોપ એક અનુભવી સોફ્ટવેર ડેવલપર છે જેણે હજુ પણ સિલિકોન વેલી છોડી નથી. પાછલા 20 વર્ષોમાં, માઇકલે Apple, Netscape, Symantec, Borland, Palantir, Pinterest સહિતની વિવિધ નવીન કંપનીઓ માટે કામ કર્યું છે અને ધીમે ધીમે વિસ્મૃતિમાં ફેરવાતા સ્ટાર્ટઅપમાં પણ ભાગ લીધો છે.

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

માઈકલ તેના પરિવાર સાથે રેડવુડ, કેલિફોર્નિયામાં રહે છે. તે હંમેશા માઉન્ટેન બાઇક, હોકી રમવા અને રેડ વાઇન પીવા માટે સમય કાઢે છે, કારણ કે વ્યસ્ત રહેવા કરતાં સ્વસ્થ રહેવું વધુ મહત્વનું છે.

» પુસ્તક વિશે વધુ માહિતી માટે, કૃપા કરીને મુલાકાત લો પ્રકાશકની વેબસાઇટ
» સમાવિષ્ટોનું કોષ્ટક
» અવતરણ

Khabrozhiteli માટે કૂપન પર 20% ડિસ્કાઉન્ટ - લોકોનું સંચાલન

પુસ્તકના પેપર વર્ઝન માટે ચૂકવણી કર્યા પછી, પુસ્તકનું ઈલેક્ટ્રોનિક વર્ઝન ઈ-મેલ દ્વારા મોકલવામાં આવશે.

પીએસ: પુસ્તકની કિંમતના 7% નવા કમ્પ્યુટર પુસ્તકોના અનુવાદમાં જશે, પુસ્તકોની સૂચિ પ્રિન્ટિંગ હાઉસને સોંપવામાં આવશે અહીં.

સોર્સ: www.habr.com