د پروژې مدیرانو ته وقف شوی (او هغه څوک چې د مالک کیدو خوب کوي).
د ډیری کوډونو لیکل سخت دي، مګر د خلکو اداره کول خورا سخت دي! نو تاسو یوازې دې کتاب ته اړتیا لرئ ترڅو زده کړئ چې دواړه څنګه ترسره کړئ.
ایا دا ممکنه ده چې مسخره کیسې او جدي درسونه یوځای کړئ؟ مایکل لوپ (په تنګ حلقو کې د رینډز په نوم هم پیژندل شوی) بریالی شو. تاسو به د افسانوي خلکو په اړه افسانوي کیسې ومومئ چې د نه منلو وړ ګټور (که څه هم افسانوي) تجربې لري. دا څنګه رینډز خپل مختلف ، ځینې وختونه عجیب تجربې شریکوي چې په لوی IT کارپوریشنونو کې د کار کولو په کلونو کې ترلاسه شوي: ایپل ، پینټیریسټ ، پالانټیر ، نیټسکیپ ، سیمانټیک او داسې نور.
ایا تاسو د پروژې مدیر یاست؟ یا غواړئ پوه شئ چې ستاسو بد مالک ټوله ورځ څه کوي؟ رینډز به تاسو ته درس درکړي چې څنګه د انفلاسیون شوي ترکیې په زهرجن نړۍ کې ژوندي پاتې شئ او د غیر فعاله شوخ خلکو عمومي جنون کې وده وکړئ. په دې عجیبه ټولنه کې د مغز مغزونو کې حتی اجنبی مخلوقات شتون لري - مدیران چې د صوفیانه تنظیمي رسم له لارې، د ډیرو خلکو په پالنونو، فکرونو او بانکي حسابونو باندې واک ترلاسه کړی.
دا کتاب د هر ډول مدیریت یا مشرتابه لاسوندونو برعکس دی. مایکل لوپ هیڅ شی نه پټوي، هغه یوازې دا ورته وایي (شاید ټولې کیسې باید عامه نه شي: P). مګر یوازې پدې توګه به تاسو پوه شئ چې څنګه د داسې مالک سره ژوندي پاتې کیدلی شئ ، څنګه د ګیکس او عصبي اداره کول ، او څنګه "دا ناوړه پروژه" خوشحاله پای ته راوړو!
اقتباس. د انجینرۍ ذهنیت
په اړه فکرونه: ایا تاسو باید د کوډ لیکلو ته دوام ورکړئ؟
د مدیرانو لپاره د قواعدو په اړه د رینډز کتاب د عصري مدیریت "ضروري کارونو" خورا لنډ لیست لري. د دې لیست نیمګړتیا له دې حقیقت څخه رامینځته کیږي چې د "لازم" مفهوم یو ډول مطلق دی ، او کله چې دا خلکو ته راځي ، خورا لږ مطلق مفکورې شتون لري. د یو کارمند لپاره د مدیریت بریالي میتود به د بل لپاره ریښتینی ناورین وي. دا فکر د مدیر په "باید ترسره کولو" لیست کې لومړی توکی دی:
انعطاف منونکی اوسئ!
فکر کول چې تاسو دمخه هرڅه پوهیږئ یو خورا بد نظر دی. په داسې حالت کې چې یوازینی ثابت حقیقت دا دی چې نړۍ په دوامداره توګه بدلیږي، انعطاف یوازینی سم دریځ کیږي.
په متضاد ډول ، په لیست کې دوهم توکي د حیرانتیا وړ انعطاف وړ دی. په هرصورت، دا ټکی زما شخصي غوره دی ځکه چې زه باور لرم چې دا د مدیریتي ودې لپاره بنسټ رامینځته کولو کې مرسته کوي. دا پراګراف لوستل کیږي:
د کوډ لیکل بند کړئ!
په تیوري کې، که تاسو غواړئ مدیر شئ، تاسو باید په هغه چا باور زده کړئ چې ستاسو لپاره کار کوي او په بشپړ ډول دوی ته کوډونه وسپاري. دا مشوره معمولا د هضم لپاره ستونزمنه ده، په ځانګړې توګه د نویو مدیرانو لپاره. ښایي یو له هغو دلیلونو څخه چې دوی مدیران شوي د دوی په پرمختګ کې د تولید وړتیا له امله وي، او کله چې شیان غلط شي، د دوی لومړی غبرګون د هغه مهارتونو بیرته راګرځیدل دي چې دوی په بشپړ باور لري، کوم چې د کوډ لیکلو وړتیا ده.
کله چې زه ګورم چې یو نوی شوی مدیر د کوډ لیکلو کې "ډب" کوي، زه ورته وایم: "موږ پوهیږو چې تاسو کوډ لیکلی شئ. پوښتنه دا ده: تاسو رهبري کولی شئ؟ تاسو نور یوازې د ځان لپاره مسؤل نه یاست، تاسو د ټول ټیم مسؤلیت یاست؛ او زه غواړم ډاډ ترلاسه کړم چې تاسو کولی شئ خپل ټیم ترلاسه کړئ چې ستونزې پخپله حل کړي، پرته لدې چې تاسو پخپله کوډ ولیکئ. ستاسو دنده دا ده چې معلومه کړئ چې څنګه خپل ځان اندازه کړئ. زه نه غواړم تاسو یوازې یو یاست، زه غواړم چې ستاسو په څیر ډیر وي."
ښه مشوره، سمه ده؟ پیمانه. مدیریت. مسؤلیت. دا ډول عام ټکي. دا د افسوس خبره ده چې مشوره غلطه ده.
ناسم؟
هو. مشوره غلطه ده! په بشپړه توګه غلط نه، مګر دومره غلط چې ما باید ځینې پخوانیو همکارانو ته زنګ وواهه او بخښنه وغواړم: "زما هغه غوره وینا په یاد ولرئ چې تاسو باید د کوډ لیکلو مخه ونیسئ؟ دا غلطه ده! هو... بیا پروګرام کول پیل کړئ. د Python او روبي سره پیل کړئ. هو، زه جدي یم! ستاسو مسلک په دې پورې اړه لري!"
کله چې ما په بورلینډ کې د سافټویر جوړونکي په توګه خپل مسلک پیل کړ، ما د پاراډکس وینډوز ټیم کې کار کاوه، کوم چې یو لوی ټیم و. یوازې د 13 غوښتنلیک جوړونکي شتون درلود. که تاسو د نورو ټیمونو څخه خلک اضافه کړئ چې د دې پروژې لپاره په دوامداره توګه په کلیدي ټیکنالوژیو کار کوي، لکه د اصلي ډیټابیس انجن او اصلي غوښتنلیک خدمتونه، تاسو 50 انجنیران په مستقیم ډول د دې محصول په پراختیا کې ښکیل یاست.
هیڅ بل ټیم چې ما هیڅکله کار نه دی کړی حتی دې اندازې ته نږدې نه راځي. په حقیقت کې، د هر تیر کال سره، په ټیم کې د خلکو شمیر چې زه یې کار کوم په تدریجي ډول کمیږي. څه تیریږي؟ ایا موږ پراختیا کونکي په ټولیز ډول هوښیار او هوښیار کیږو؟ نه، موږ یوازې بار شریک کوو.
پراختیا کونکي په تیرو 20 کلونو کې څه کوي؟ د دې وخت په جریان کې موږ د کوډ شیټ بار لیکلی. د کوډ سمندر! موږ دومره کوډ لیکلی چې موږ پریکړه وکړه چې دا به ښه نظر وي چې هرڅه ساده کړئ او خلاصې سرچینې ته لاړ شئ.
خوشبختانه، د انټرنیټ څخه مننه، دا پروسه اوس د امکان تر حده ساده شوې. که تاسو د سافټویر جوړونکي یاست، تاسو کولی شئ همدا اوس یې وګورئ! خپل نوم په ګوګل یا ګیتوب کې وپلټئ او تاسو به هغه کوډ وګورئ چې تاسو یې په اړه هیر شوي یاست، مګر هر څوک یې موندلی شي. ډارونکی، سمه ده؟ ایا تاسو نه پوهیږئ چې کوډ د تل لپاره ژوند کوي؟ هو، هغه د تل لپاره ژوند کوي.
کوډ د تل لپاره ژوند کوي. او ښه کوډ نه یوازې د تل لپاره ژوند کوي، دا وده کوي ځکه چې هغه څوک چې ارزښت لري په دوامداره توګه ډاډ ترلاسه کوي چې دا تازه پاتې کیږي. دا د لوړ کیفیت لرونکي، ښه ساتل شوي کوډ د منځنۍ انجینرۍ ټیم اندازې کمولو کې مرسته کوي ځکه چې دا موږ ته اجازه راکوي چې د نوي کوډ لیکلو پرځای په موجوده کوډ تمرکز وکړو، او د لږو خلکو سره او په لنډ وخت چوکاټ کې کار ترسره کړو.
د استدلال دا کرښه خپګان کوي، مګر نظر دا دی چې موږ ټول یوازې د ادغام اتوماتیک یوه ډله یو چې د ډیک ټیپ په کارولو سره د موجوده شیانو مختلف بټونه سره وصل کړو ترڅو د ورته شیانو یو څه مختلف نسخه رامینځته کړي. دا د لوړ پوړو چارواکو ترمینځ د فکر کولو کلاسیک کرښه ده چې د آؤټ سورس کولو سره مینه لري. "هرڅوک چې د ګوګل کارولو څرنګوالی پوهیږي او یو څه ډیکټ ټیپ لري دا کولی شي! بیا ولې موږ خپلو ماشینونو ته ډیرې پیسې ورکوو؟"
موږ دې مدیرانو ته واقعیا لویې پیسې ورکوو ، مګر دوی دا ډول بې ځایه فکر کوي. یوځل بیا، زما مهم ټکی دا دی چې زموږ په سیارټ کې ډیری تکړه او خورا سخت کار کونکي پراختیا کونکي شتون لري؛ دوی واقعیا تکړه او هوښیار دي ، که څه هم دوی په معتبرو پوهنتونونو کې ناست یوه دقیقه هم نه ده لګولې. هو هو، اوس د دوی څخه ډیر څه شتون لري!
زه وړاندیز نه کوم چې تاسو یوازې د خپل ځای په اړه اندیښنه پیل کړئ ځکه چې ځینې تکړه ملګري د دې په لټه کې دي. زه وړاندیز کوم چې تاسو د دې په اړه اندیښنه پیل کړئ ځکه چې د سافټویر پراختیا تکامل شاید ستاسو په پرتله ګړندی روان وي. تاسو د لسو کلونو لپاره کار کوئ، پنځه یې د مدیر په توګه، او تاسو فکر کوئ: "زه دمخه پوهیږم چې سافټویر څنګه رامینځته کیږي." هو، تاسو پوهیږئ. د خدای په امان…
د کوډ لیکل بند کړئ، مګر ...
که تاسو زما اصلي مشوره تعقیب کړئ او د کوډ لیکلو مخه ونیسئ، تاسو به هم په داوطلبانه توګه د جوړولو په پروسه کې برخه اخیستل ودروئ. دا د دې دلیل لپاره دی چې زه په فعاله توګه د آوټ سورسنګ نه کار اخلم. اتومات نه جوړوي، دوی تولیدوي. ښه ډیزاین شوي پروسې ډیرې پیسې خوندي کوي، مګر دوی زموږ نړۍ ته نوي څه نه راوړي.
که تاسو یو کوچنی ټیم لرئ چې د لږو پیسو لپاره ډیر څه کوي، نو د لیکلو کوډ بندولو نظر زما لپاره د خراب مسلک پریکړه ښکاري. حتی د شیطان شرکتونو کې د دوی نه ختمیدونکي مقرراتو ، پروسو او پالیسیو سره ، تاسو حق نلرئ هیر کړئ چې څنګه پخپله سافټویر رامینځته کړئ. او د سافټویر پراختیا په دوامداره توګه بدلیږي. دا همدا اوس بدلیږي. ستاسو د پښو لاندې! په همدې ثانیه کې!
تاسو اعتراض لرئ. پوه شو. راځئ چې واورئ.
"رینډز، زه د رییس څوکۍ ته په لاره یم! که زه د کوډ لیکلو ته دوام ورکړم، هیڅوک به باور ونه کړي چې زه وده کولی شم.
زه غواړم له تاسو څخه دا پوښتنه وکړم: له هغه وخته چې تاسو په خپل "زه د اجراییوي رییس په توګه ناست یم!" څوکۍ کې ناست یاست، ایا تاسو لیدلي چې د سافټویر پراختیا منظره بدلیږي، حتی ستاسو په شرکت کې؟ که ستاسو ځواب هو وي، نو زه به له تاسو څخه یوه بله پوښتنه وکړم: دا څنګه بدلیږي او تاسو د دې بدلونونو په اړه څه کوئ؟ که تاسو زما لومړۍ پوښتنې ته "نه" ځواب ورکړ ، نو تاسو اړتیا لرئ یو بل څوکۍ ته لاړشئ ، ځکه چې (زه شرط لرم!) د سافټویر پراختیا ساحه پدې ثانیه کې بدلیږي. تاسو به څنګه وده کوئ که تاسو ورو ورو مګر یقینا هیر کړئ چې څنګه سافټویر رامینځته کړئ؟
زما مشوره دا نه ده چې د خپل راتلونکي محصول لپاره د ټن ځانګړتیاو پلي کولو ته ځان ژمن نه کړئ. تاسو اړتیا لرئ په دوامداره توګه ګامونه واخلئ ترڅو په سر کې پاتې شئ چې ستاسو ټیم څنګه سافټویر رامینځته کوي. تاسو کولی شئ دا دواړه د رییس او مرستیال په توګه ترسره کړئ. بل څه؟
"او، رینډز! مګر یو څوک باید ثالث وي! یو څوک باید لوی عکس وګوري. که زه کوډ ولیکم، زه به لید له لاسه ورکړم."
تاسو لاهم باید ریفري اوسئ ، تاسو لاهم باید پریکړې نشر کړئ ، او تاسو لاهم باید هره دوشنبه سهار له خپل یو انجینر سره د ودانۍ شاوخوا څلور ځله وګرځئ ترڅو د هغه اونیزې "موږ ټول برباد یو" د 30 لپاره واورئ. دقیقې! مګر له دې ټولو هاخوا ، تاسو باید د انجینرۍ ذهنیت وساتئ ، او تاسو اړتیا نلرئ د دې کولو لپاره د بشپړ وخت برنامه اوسئ.
د انجینرۍ ذهنیت ساتلو لپاره زما لارښوونې:
- د پرمختیا چاپیریال وکاروئ. دا پدې مانا ده چې تاسو باید د خپل ټیم وسیلو سره آشنا اوسئ، پشمول د کوډ جوړونې سیسټم، نسخه کنټرول، او د پروګرام کولو ژبه. د پایلې په توګه، تاسو به په هغه ژبه کې ماهر شئ چې ستاسو ټیم یې کاروي کله چې د محصول پراختیا په اړه خبرې کوي. دا به تاسو ته اجازه درکړي چې د خپلې خوښې متن ایډیټر کارولو ته دوام ورکړئ، کوم چې په سمه توګه کار کوي.
- تاسو باید د دې وړتیا ولرئ چې یو مفصل معماري ډیاګرام رسم کړئ چې ستاسو محصول په هر وخت کې په هر سطح کې تشریح کوي. اوس زما مطلب دا ندی چې ساده نسخه د دریو حجرو او دوه تیرونو سره. تاسو باید د محصول تفصيلي ډیاګرام پوه شئ. تر ټولو ستونزمن. نه یوازې کوم ښکلی ډیاګرام ، مګر یو ډیاګرام چې تشریح کول یې سخت دي. دا باید د محصول د بشپړ پوهاوي لپاره مناسبه نقشه وي. دا په دوامداره توګه بدلیږي، او تاسو باید تل پوه شئ چې ولې ځینې بدلونونه رامنځته شوي.
- د یو دندو پلي کول په غاړه واخلئ. زه په حقیقت کې د دې لیکلو په وخت کې په زړه پورې یم ځکه چې دا ټکي ډیری پټ خطرونه لري، مګر زه واقعیا ډاډه نه یم چې تاسو کولی شئ د لږترلږه یوه ځانګړتیا پلي کولو ژمنې پرته # 1 او # 2 نقطه ترلاسه کړئ. پخپله د یوې ځانګړتیاو په پلي کولو سره، نه یوازې تاسو به د پراختیا په بهیر کې په فعاله توګه دخیل شئ، دا به تاسو ته اجازه درکړي چې د وخت په تیریدو سره د "د هر څه مسؤل مدیر" رول څخه "د یو پلي کولو مسؤل مدیر" رول ته لاړ شئ. د دندو." دا عاجز او بې کفایته چلند به تاسو ته د کوچنیو پریکړو اهمیت په ګوته کړي.
- زه لا تر اوسه په ټوله کې لړزوم. داسې ښکاري چې یو څوک لا دمخه په ما چیغې کوي: "هغه مدیر چې د فعالیت پلي کول یې پخپله اخیستي؟!" (او زه ورسره موافق یم!) هو، تاسو لاهم مدیر یاست، پدې معنی چې دا باید یو څه کوچنی فعالیت وي، سمه ده؟ هو، تاسو لاهم ډیر څه لرئ. که تاسو نشئ کولی د فنکشن پلي کولو کې برخه واخلئ ، نو زه ستاسو لپاره یو څه اضافي مشورې لرم: ځینې کیګونه حل کړئ. پدې حالت کې ، تاسو به د رامینځته کیدو خوښي احساس نه کړئ ، مګر تاسو به پدې پوه شئ چې محصول څنګه رامینځته کیږي ، پدې معنی چې تاسو به هیڅکله له کار څخه پاتې نه شئ.
- د واحد ازموینې ولیکئ. زه لاهم دا د تولید په دوره کې ناوخته کوم کله چې خلک لیونۍ پیل کوي. د خپل محصول لپاره د روغتیا چک لیست په توګه فکر وکړئ. دا ډیری وختونه وکړئ.
بیا اعتراض؟
"رینډز، که زه کوډ لیکم، زه به زما ټیم ګډوډ کړم. دوی به نه پوهیږي چې زه څوک یم - مدیر یا پراختیا کونکی.
ښه.
هو، ما وویل، "ښه!" زه خوښ یم چې تاسو فکر کوئ تاسو کولی شئ یوازې د پراختیا کونکي حوض کې د لامبو وهلو سره خپل ټیم ګډوډ کړئ. دا ساده ده: د سافټویر پراختیا کې د مختلف رولونو تر مینځ سرحدونه اوس مهال خورا تیاره دي. UI هلکان هغه څه کوي چې په پراخه کچه د جاواسکریپټ او CSS برنامه ویل کیدی شي. پراختیا کونکي د کارونکي تجربې ډیزاین په اړه ډیر څه زده کوي. خلک یو له بل سره اړیکه نیسي او د کیګونو په اړه زده کوي، د نورو خلکو د کوډ غلا کولو په اړه، او همدارنګه د دې حقیقت په اړه چې د مدیر لپاره هیڅ ښه دلیل شتون نلري چې پدې پراخه، نړیوال، کراس ګرده معلوماتو کې برخه وانخلي.
سربیره پردې ، ایا تاسو غواړئ د یوې ټیم برخه اوسئ چې په اسانۍ سره د بدلیدونکي اجزاو څخه جوړه وي؟ دا به نه یوازې ستاسو ټیم ډیر ګړندی کړي ، دا به د ټیم هر غړي ته فرصت ورکړي چې محصول او شرکت له مختلف لیدونو څخه وګوري. تاسو څنګه کولی شئ د فرانک درناوی وکړئ ، د ودانیو مسؤل آرام سړی ، د هغه د جوړ شوي سکریپټونو ساده ښکلا لیدو وروسته نور څه؟
زه نه غواړم چې ستاسو ټیم ګډوډ او ګډوډ شي. برعکس، زه غواړم ستاسو ټیم په اغیزمنه توګه اړیکه ونیسي. زه باور لرم که تاسو د محصول په جوړولو او په ځانګړتیاو کار کولو کې ښکیل یاست، نو تاسو به ستاسو ټیم ته نږدې شئ. او خورا مهم ، تاسو به په خپل سازمان کې د سافټویر پراختیا پروسې کې دوامداره بدلونونو ته نږدې شئ.
وده مه کوئ
په بورلینډ کې زما یو همکار یو ځل په لفظي ډول په ما برید وکړ چې هغې ته یې "کوډر" ویل.
"رینډز، کوډر یو بې عقل ماشین دی! بیزو! کوډر هیڅ مهم کار نه کوي پرته له دې چې د بې کاره کوډونو ستړي لینونه ولیکي. زه کوډر نه یم، زه د سافټویر جوړونکی یم!"
هغه سمه وه ، هغې به نوي اجرایوي رییسانو ته زما لومړنۍ مشورې نفرت درلود: "د کوډ لیکل بند کړئ!" نه ځکه چې زه وړاندیز کوم چې دوی کوډر دي، مګر نور ځکه چې زه په فعاله توګه وړاندیز کوم چې دوی د دوی د دندې ترټولو مهمې برخې له پامه غورځوي: د سافټویر پراختیا.
نو ما خپله مشوره تازه کړه. که غواړې چې ښه رهبر شې، کولای شې د کوډ لیکلو مخه ونیسې، خو...
انعطاف منونکی اوسئ. په یاد ولرئ چې دا د انجینر کیدو معنی څه ده او د سافټویر رامینځته کول مه پریږدئ.
د لیکوال په اړه
مایکل لوپ یو تجربه لرونکی سافټویر جوړونکی دی چې لاهم د سیلیکون ویلی نه دی پریښی. په تیرو 20 کلونو کې ، مایکل د مختلف نوښت کونکو شرکتونو لپاره کار کړی ، پشمول د Apple، Netscape، Symantec، Borland، Palantir، Pinterest، او همدارنګه یې په پیل کې برخه اخیستې چې ورو ورو له پامه غورځول کیږي.
د کار څخه بهر، مایکل د ټیکنالوژۍ او مدیریت په اړه یو مشهور بلاګ د رینډز په نوم چلوي، چیرې چې هغه د لوستونکو سره د مدیریت په برخه کې نظریات بحث کوي، په نبض کې د خپلې ګوتې ساتلو دوامداره اړتیا په اړه اندیښنه څرګندوي، او دا تشریح کوي، سره له دې. د محصول رامینځته کولو لپاره سخاوتمند انعامونه ، ستاسو بریا یوازې ستاسو د ټیم څخه مننه امکان لري. بلاګ دلته موندل کیدی شي .
مایکل د خپلې کورنۍ سره په ریډ ووډ، کالیفورنیا کې ژوند کوي. هغه تل د غره بایسکل ته وخت پیدا کوي، هاکي لوبې کوي او سور شراب څښي، ځکه چې صحتمند پاتې کیدل د مصروفیت څخه ډیر مهم دي.
» د کتاب په اړه نور جزئیات دلته موندلی شئ
»
»
د Khabrozhiteley لپاره 20% تخفیف د کوپن په کارولو سره - د خلکو اداره کول
د کتاب د کاغذي نسخې لپاره د پیسو په ورکولو سره، د کتاب بریښنایی نسخه به د بریښنالیک له لارې لیږل کیږي.
PS: د کتاب قیمت 7٪ به د نوي کمپیوټر کتابونو ژباړې ته ځي ، د کتابونو لیست چاپ خونه ته وسپارل شو .
سرچینه: www.habr.com