سلام دوستو. گهڻو ڪري، خاص طور تي ٻاهر نڪرڻ ۾، مون کي ساڳيو تصوير ڏسڻ ۾ اچي ٿو. مختلف منصوبن تي ٽيمن ۾ واضح ورڪ فلو جي کوٽ.
سڀ کان اهم شيء اها آهي ته پروگرامر اهو نه ٿا سمجهن ته ڪسٽمر سان ۽ هڪ ٻئي سان ڪيئن گفتگو ڪجي. هڪ معيار جي پيداوار جي ترقي جي مسلسل عمل کي ڪيئن ٺاهيو. توهان جي ڪم ڪندڙ ڏينهن ۽ اسپرنٽ جي منصوبابندي ڪيئن ڪجي.
۽ اهو سڀ ڪجهه آخرڪار ٽٽل ڊيڊ لائنن، اوور ٽائم، مسلسل شوڊائونز جو نتيجو آهي ته ڪير ذميوار آهي، ۽ گراهڪ جي عدم اطمينان - ڪٿي ۽ ڪيئن سڀ ڪجهه هلي رهيو آهي. گهڻو ڪري، اهو سڀ ڪجهه پروگرامن جي تبديلي جي ڪري ٿي، ۽ اڃا به پوري ٽيمون. هڪ گراهڪ جي نقصان، شهرت جي خرابي ۽ پوء تي.
هڪ دفعي، مان صرف هڪ اهڙي منصوبي تي نڪتو، جتي اهي سڀئي نعمتون هيون.
ڪو به پروجيڪٽ جي ذميواري وٺڻ نه چاهيندو هو (هڪ وڏي خدمت مارڪيٽ)، واپار خوفناڪ هو، گراهڪ صرف ڦاڙيو ۽ اڇلائي ڇڏيو. سي اي او ڪنهن نه ڪنهن طرح مون وٽ پهتو ۽ چيو ته توهان وٽ ضروري تجربو آهي، تنهنڪري توهان جي هٿن ۾ ڪارڊ آهن. پنهنجو پاڻ لاء پروجيڪٽ وٺو. جيڪڏهن توهان خراب ڪيو، اسان پروجيڪٽ کي بند ڪنداسين ۽ سڀني کي ٻاهر ڪڍنداسين. اهو ڦرندو، اهو ٿڌو ٿيندو، پوء ان جي اڳواڻي ڪريو ۽ ان کي ترقي ڪريو جيئن توهان مناسب ڏسندا. نتيجي طور، مان منصوبي تي ٽيم ليڊر بڻجي ويو ۽ هر شيء منهنجي ڪلهن تي ڪري پيو.
پهرين شيء جيڪا مون ڪئي هئي اهو هڪ ڪم فلو ٺهيل هو شروع کان جيڪو منهنجي نظر سان ملندو هو ۽ ٽيم لاءِ نوڪري جو تفصيل لکيو. ان تي عمل ڪرڻ آسان نه هو. پر ڪٿي ڪٿي هڪ مهيني اندر سڀ ڪجهه ٺيڪ ٿي ويو، ڊولپرز ۽ ڪلائنٽ ان کي استعمال ڪيو، ۽ هر شيء خاموشي ۽ آرام سان ٿي وئي. ٽيم کي ڏيکارڻ لاءِ ته هي صرف شيشي ۾ طوفان نه آهي، پر صورتحال مان نڪرڻ جو هڪ حقيقي رستو آهي، مون ٽيم مان ناپسنديده معمول کي هٽائي، تمام گهڻي ذميواريون ورتيون.
هڪ اڌ سال اڳ ۾ ئي گذري چڪو آهي، ۽ پروجيڪٽ بغير اوورٽائم جي ترقي ڪري رهيو آهي، بغير "چوڻي نسل" ۽ هر قسم جي دٻاء جي. پراڻي ٽيم ۾ ڪو اهڙو ڪم ڪرڻ نه چاهيندو هو ۽ ڇڏي ويو، ان جي برعڪس، ڪو ماڻهو واقعي ان ۾ داخل ٿيو ته شفاف ضابطا ظاهر ٿيا. پر نتيجي طور، ٽيم ۾ هرڪو تمام گهڻو حوصلا افزائي آهي ۽ ڄاڻي ٿو وڏي منصوبي کي مڪمل طور تي، ٻنهي جي سامهون ۽ پوئتي آخر سان. جنهن ۾ ڪوڊ جو بنياد ۽ سڀ ڪاروباري منطق شامل آهن. اهو ان نقطي تي پهچي چڪو آهي ته اسان صرف ”روئر“ نه آهيون، پر اسان پاڻ ڪيترن ئي ڪاروباري عملن ۽ نئين خاصيتن سان گڏ آيا آهيون جيڪي ڪاروبار پسند ڪن ٿا.
اسان جي حصي تي هن طريقي جي مهرباني، گراهڪ فيصلو ڪيو ته اسان جي ڪمپني مان هڪ ٻي مارڪيٽ جو حڪم ڏنو وڃي، جيڪا سٺي خبر آهي.
جيئن ته هي منهنجي پروجيڪٽ تي ڪم ڪري ٿو، شايد اهو پڻ ڪنهن جي مدد ڪندو. تنهن ڪري، عمل پاڻ، جنهن اسان کي منصوبي کي بچائڻ ۾ مدد ڪئي:
منصوبي تي ٽيم جي ڪم جو عمل "منهنجو پسنديده منصوبو"
a) ٽيم جي عمل جي اندر (ڊولپرز جي وچ ۾)
- سڀ ڪم جيرا سسٽم ۾ ٺاهيا ويا آهن
- هر ڪم کي ممڪن طور بيان ڪيو وڃي، ۽ سختي سان هڪ عمل انجام ڏيو.
- ڪا به خصوصيت، جيڪڏهن اهو ڪافي پيچيده آهي، ڪيترن ئي ننڍن ڪمن ۾ ورهايل آهي
- ٽيم ھڪڙي ڪم جي طور تي خاصيتن تي ڪم ڪري ٿي. پهرين، اسان هڪ خاصيت گڏ ڪريون ٿا، ان کي جاچ لاءِ ڏيو، پوءِ ٻيو وٺو.
- هر ڪم کي پس منظر يا فرنٽ اينڊ لاء ليبل ڪيو ويو آهي
- ڪم ۽ بگ جا قسم آهن. توھان کي انھن کي صحيح نموني بيان ڪرڻ گھرجي.
- ڪم مڪمل ٿيڻ کان پوء، ان کي منتقل ڪيو ويو آهي ڪوڊ جائزو جي حيثيت (هڪ پل جي درخواست ان جي ساٿي لاء ٺاهي وئي آهي)
- جيڪو ڪم مڪمل ڪري ٿو، فوري طور تي هن ڪم لاء پنهنجي وقت کي ٽريڪ ڪري ٿو
- ڪوڊ چيڪ ڪرڻ کان پوء، پي آر منظور ڪيو ويندو آهي ۽ ان کان پوء، جيڪو هن ڪم کي انجام ڏئي ٿو، اهو آزاديء سان ان کي ماسٽر برانچ ۾ ضم ڪري ٿو، جنهن کان پوء اهو ان جي حيثيت کي تبديل ڪري ٿو ته ڊيو سرور تي ترتيب ڏيڻ لاء تيار آهي.
- ديو سرور تي مقرر ٿيڻ لاءِ تيار ڪيل سڀئي ڪم ٽيم ليڊر (سندس ذميواري جو علائقو)، ڪڏهن ڪڏهن ٽيم جو ميمبر، جيڪڏهن ڪا شيءِ تڪڙي هجي. تعیناتي کان پوء، سڀني ڪمن کي ترتيب ڏيڻ لاء تيار کان dev ڏانهن منتقل ڪيو ويو آهي اسٽيٽس تي - dev تي جاچ لاء تيار
- سڀ ڪم ڪسٽمر طرفان آزمايا ويا آهن
- جڏهن گراهڪ ڊيو تي ڪم کي آزمائي چڪو آهي، هو ان کي منتقل ڪري ٿو اسٽيج تي تيار ڪرڻ لاء تيار ڪيل پيداوار لاء.
- پيداوار ۾ ڊيپلائيمينٽ لاءِ، اسان وٽ هڪ الڳ برانچ آهي جتي اسان ڊيپلائيمينٽ کان پهريان ماسٽر کي ضم ڪندا آهيون.
- جيڪڏهن جانچ جي دوران گراهڪ کي ڪيڙا ملن ٿا، ته پوءِ هو نظرثاني لاءِ ڪم کي واپس ڪري ٿو، ان جي اسٽيٽس کي ترتيب ڏئي نظرثاني لاءِ واپس ڪيو ويو. اهو آهي ته اسان انهن کان نوان ڪم الڳ ڪريون ٿا جيڪي آزمائشي نه ڪيا ويا آهن.
- نتيجي طور، سڀ ڪم ٺاھڻ کان وٺي مڪمل ٿيڻ تائين وڃن ٿا: ڪرڻ لاءِ → ڊولپمينٽ ۾ → ڪوڊ ريويو → تيار ڪرڻ لاءِ dev → QA تي dev → (ڊيو ڏانھن واپس وڃو) → تيار ڪرڻ لاءِ تيار → پروڊ تي QA → ٿي ويو
- هر ڊولپر پنهنجي ڪوڊ کي آزاد طور تي آزمائي ٿو، بشمول سائيٽ جي صارف جي طور تي. ان کي اجازت نه آهي ته شاخ کي مکيه شاخ سان ملائي، جيستائين اهو معلوم نه ٿئي ته ڪوڊ ڪم ڪري ٿو.
- هر ڪم جي ترجيحات آهي. ترجيحات يا ته ڪسٽمر يا ٽيم ليڊر طرفان مقرر ڪيل آهن.
- ڊولپرز پهرين ترجيحي ڪم ڪن ٿا.
- ڊولپرز هڪ ٻئي کي ڪم تفويض ڪري سگهن ٿا جيڪڏهن سسٽم ۾ مختلف ڪيڙا مليا آهن يا هڪ ڪم ڪيترن ئي ماهرن جي ڪم تي مشتمل آهي.
- سڀئي ڪم جيڪي گراهڪ ٺاهي ٿو ٽيم ليڊر ڏانهن موڪليا ويا آهن، جيڪو انهن جو جائزو وٺندو آهي ۽ يا ته گراهڪ کان پڇي ٿو انهن کي حتمي شڪل ڏيڻ يا انهن کي ٽيم جي ميمبرن مان هڪ کي تفويض ڪري ٿو.
- سڀئي ڪم جيڪي ڊيوٽي ڪرڻ لاءِ تيار آهن dev يا پروڊ پڻ ٽيم ليڊر کي ملي ٿو، جيڪو آزاديءَ سان طئي ڪري ٿو ته ڪڏهن ۽ ڪيئن ٺهڪائڻو آهي. هر مقرري کان پوء، ٽيم جي اڳواڻ (يا ٽيم ميمبر) کي لازمي طور تي صارف کي ان بابت مطلع ڪرڻ گهرجي. ۽ dev / prod تي جاچ لاءِ تيار ٿيڻ لاءِ ڪمن لاءِ حالتون پڻ تبديل ڪريو.
- هر روز ساڳئي وقت (اسان وٽ 12.00 تي آهي) اسان سڀني ٽيم جي ميمبرن جي وچ ۾ هڪ ريلي منعقد ڪندا آهيون
- ريلي ۾ موجود هرڪو رپورٽ ڪري ٿو، بشمول ٽيم ليڊر، هن ڪالهه ڇا ڪيو، اڄ ڇا ڪرڻ جو منصوبو آهي. ڇا ڪم نٿو ڪري ۽ ڇو. اهڙيءَ طرح، پوري ٽيم کي خبر آهي ته ڪير ڇا ڪري رهيو آهي ۽ ڪهڙي مرحلي ۾ پروجيڪٽ آهي. هي اسان کي پيش گوئي ۽ ترتيب ڏيڻ جو موقعو ڏئي ٿو، جيڪڏهن ضروري هجي ته، اسان جي تخميني ۽ آخري وقت.
- گڏجاڻي ۾، ٽيم ليڊر پڻ اعلان ڪري ٿو ته منصوبي ۾ سڀني تبديلين ۽ موجوده مسئلن جي سطح جيڪي صارف پاران نه مليا هئا. سڀئي بگ ترتيب ڏنل آهن ۽ انهن کي حل ڪرڻ لاءِ هر ٽيم ميمبر کي تفويض ڪيو ويو آهي.
- ريلي ۾، ٽيم ليڊر هر هڪ لاء ڪم تفويض ڪري ٿو، ڊولپرز جي موجوده ڪم لوڊ، انهن جي پيشه ورانه تربيت جي سطح، ۽ انهي سان گڏ هڪ خاص ڪم جي قربت کي به نظر ۾ رکندي جيڪو ڊولپر هن وقت ڪري رهيو آهي.
- گڏجاڻي ۾، ٽيم جي اڳواڻ فن تعمير ۽ ڪاروباري منطق لاء هڪ عام حڪمت عملي ٺاهي ٿي. ان کان پوء، سڄي ٽيم ان تي بحث ڪندي ۽ فيصلو ڪري ٿي ته ڇا ترتيب ڏيڻ يا هن حڪمت عملي کي اپنائڻ.
- هر ڊولپر ڪوڊ لکي ٿو ۽ الگورتھم ٺاهي ٿو آزاديءَ سان هڪ فن تعمير ۽ ڪاروباري منطق جي اندر. هرڪو پنهنجي عمل جي نظريي جو اظهار ڪري سگهي ٿو، پر ڪو به ڪنهن کي مجبور نه ڪري رهيو آهي ته ان کي ائين ڪرڻ لاءِ ۽ نه ٻي صورت ۾. هر فيصلو جائز آهي. جيڪڏهن ڪو بهتر حل آهي، پر هاڻي ان لاء ڪو به وقت نه آهي، پوء هڪ ڪم ٿلهي ۾ پيدا ڪيو ويو آهي، مستقبل ۾ ڪوڊ جي هڪ خاص حصي جي ريفڪٽرنگ لاء.
- جڏهن هڪ ڊولپر هڪ ڪم تي وٺندو آهي، هو ان کي ترقي جي حيثيت ڏانهن منتقل ڪري ٿو. ڪسٽمر سان ڪم جي وضاحت بابت سڀ مواصلات ڊولپر جي ڪلهن تي پوي ٿو. ٽيم جي اڳواڻ يا ساٿين کان ٽيڪنيڪل سوال پڇي سگهجن ٿا.
- جيڪڏهن ڊولپر ڪم جي جوهر کي سمجهي نه ٿو، ۽ گراهڪ ان کي سمجهه سان وضاحت نه ڪري سگهيو، پوء هو ايندڙ ڪم ڏانهن اڳتي وڌندو. ۽ ٽيم ليڊر موجوده ھڪڙي کي وٺي ٿو ۽ ان کي گراهڪ سان بحث ڪري ٿو.
- هر روز، ڊولپر کي ڪلائنٽ جي چيٽ ۾ لکڻ گهرجي ته هن ڪالهه ڪهڙن ڪمن تي ڪم ڪيو ۽ اڄ ڪهڙن ڪمن تي ڪم ڪندو.
- ڪم فلو اسڪرم تي ٻڌل آهي. هر شي اسپرنٽ ۾ ورهايل آهي. هر اسپرنٽ ٻن هفتن تائين رهي ٿو.
- اسپرنٽ ٺاهيا ويا آهن، ڀريل ۽ بند ٿيل ٽيم جي اڳواڻ طرفان.
- جيڪڏهن پروجيڪٽ سخت ڊيڊ لائنون آهن، ته پوء اسان سڀني ڪمن جو اندازو لڳائڻ جي ڪوشش ڪندا آهيون. ۽ اسان انهن مان هڪ سپرنٽ گڏ ڪندا آهيون. جيڪڏهن گراهڪ اسپرنٽ ۾ وڌيڪ ڪم شامل ڪرڻ جي ڪوشش ڪري ٿو، ته پوءِ اسان ترجيحات مقرر ڪريون ٿا، ۽ ڪجهه ٻين ڪمن کي ايندڙ اسپرنٽ ۾ منتقل ڪريون ٿا.
ب) ڪسٽمر سان ڪم ڪرڻ جو عمل
- هر ڊولپر ڪري سگهي ٿو ۽ صارف سان رابطو ڪرڻ گهرجي
- توهان گراهڪ کي اجازت نه ٿا ڏئي سگهو ته اهي راند جا پنهنجا ضابطا لاڳو ڪن. اهو ضروري آهي ته شائستگي ۽ دوستانه انداز ۾ صارف کي اهو واضح ڪرڻ گهرجي ته اسان پنهنجي شعبي ۾ ماهر آهيون، ۽ صرف اسان کي ڪم جي عمل کي ٺاهڻ گهرجي ۽ انهن ۾ ڪسٽمر کي شامل ڪرڻ گهرجي.
- اهو ضروري آهي، مثالي طور تي، ڪنهن به ڪارڪردگي تي عمل ڪرڻ کان اڳ، هڪ خصوصيت (ڪم فلو) لاء پوري منطقي عمل جو فلو چارٽ ٺاهي. ۽ تصديق لاءِ گراهڪ ڏانهن موڪليو. اهو صرف پيچيده ۽ واضح ڪارڪردگي تي لاڳو ٿئي ٿو، مثال طور، هڪ ادائيگي وارو نظام، هڪ نوٽيفڪيشن سسٽم، وغيره. اهو توهان کي وڌيڪ صحيح طور تي سمجهڻ جي اجازت ڏيندو ته ڪسٽمر کي ڪهڙي ضرورت آهي، خصوصيت لاء دستاويز محفوظ ڪريو، ۽ انهي حقيقت جي خلاف پاڻ کي يقيني بڻائي ته گراهڪ مستقبل ۾ اهو چئي سگهي ٿو ته اسان اهو نه ڪيو جيڪو هن پڇيو.
- سڀ ڊراگرام/ فلو چارٽس/ منطق وغيره. اسان ڪنفلوئنس/فٽ ۾ محفوظ ڪريون ٿا، جتي اسان ڪسٽمر کان پڇون ٿا تبصرن ۾ مستقبل جي عمل جي درستي جي تصديق ڪرڻ لاءِ.
- اسان ڪوشش ڪريون ٿا ته گراهڪ تي ٽيڪنيڪل تفصيل سان بوجھ نه وجهون. جيڪڏهن اسان کي سمجهڻ جي ضرورت آهي ته گراهڪ ڪيئن چاهي ٿو، ته پوءِ اسان هڪ فلو چارٽ جي صورت ۾ ابتدائي الگورتھم ٺاهيندا آهيون جنهن کي گراهڪ سمجهي سگهي ٿو ۽ پاڻ هر شيءِ کي درست/تبديل ڪري سگهي ٿو.
- جيڪڏهن گراهڪ پروجيڪٽ ۾ ڪو بگ ڳولي ٿو، ته پوءِ اسان توهان کان پڇون ٿا ته ان کي فٽ ۾ وڏي تفصيل سان بيان ڪريو. ڪهڙن حالتن ۾ اهو واقع ٿيو، جڏهن، جانچ جي دوران ڪسٽمر طرفان عملن جو ڪهڙو سلسلو ڪيو ويو. مھرباني ڪري اسڪرين شاٽ شامل ڪريو.
- اسان هر روز ڪوشش ڪريون ٿا، وڌ ۾ وڌ هر ٻئي ڏينهن، ڊيو سرور تي ترتيب ڏيڻ لاءِ. ڪسٽمر وري ڪارڪردگي جي جانچ شروع ڪري ٿو ۽ پروجيڪٽ بيڪار نه آهي. ساڳئي وقت، اهو گراهڪ لاء هڪ مارڪر آهي ته پروجيڪٽ مڪمل ترقي ۾ آهي ۽ ڪو به کيس پراڻيون ڪهاڻيون نه ٻڌائيندو آهي.
- اهو اڪثر ڪري ٿو ته گراهڪ مڪمل طور تي سمجهي نه ٿو ته هن کي ڇا جي ضرورت آهي. جيئن ته هو پنهنجي لاءِ هڪ نئون ڪاروبار ٺاهي ٿو، پروسيس سان جيڪي اڃا تائين ڊيبگ نه ڪيا ويا آهن. تنهن ڪري، هڪ تمام عام ڪيس آهي جڏهن اسان ڪوڊ جا سمورا ٽڪرا ڪچري ۾ اڇليندا آهيون ۽ ايپليڪيشن منطق کي ٻيهر شڪل ڏيون ٿا. انهي مان اهو معلوم ٿئي ٿو ته اهو ضروري ناهي ته ٽيسٽ سان هر شيء کي ڍڪڻ لاء. اهو سمجھ ۾ اچي ٿو ته صرف نازڪ ڪارڪردگي کي ٽيسٽ سان، ۽ پوءِ تحفظات سان.
- حالتون آهن جڏهن ٽيم محسوس ڪري ٿي ته اسان ڊيڊ لائنن ۾ مناسب نه آهيون. ان کان پوء اسان ڪمن جي تڪڙو آڊٽ ڪندا آهيون، ۽ فوري طور تي گراهڪ کي ان بابت ڄاڻ ڏيو. صورتحال مان نڪرڻ جي طريقي جي طور تي، اسان وقت تي اهم ۽ نازڪ ڪارڪردگي شروع ڪرڻ جي صلاح ڏيو ٿا، ۽ باقي ڇڏڻ کان پوء ڇڏڻ لاء.
- جيڪڏهن گراهڪ پنهنجي سر کان مختلف ڪمن سان گڏ اچڻ شروع ڪري ٿو، تصور ڪرڻ شروع ڪري ٿو ۽ هن جي آڱرين تي وضاحت ڪرڻ شروع ڪري ٿو، ته پوء اسان کانئس پڇون ٿا ته اسان کي هڪ صفحي جي ترتيب فراهم ڪري ۽ منطق سان وهندي، جيڪا پوري ترتيب جي رويي کي مڪمل طور تي بيان ڪرڻ گهرجي. عناصر.
- ان کان اڳ جو اسان ڪنهن به ڪم تي هٿ رکون، اسان کي پڪ ڪرڻ گهرجي ته اها خاصيت اسان جي معاهدي / معاهدي جي شرطن ۾ شامل هئي. جيڪڏهن هي هڪ نئين خصوصيت آهي جيڪا اسان جي شروعاتي معاهدي کان ٻاهر آهي، پوء اسان کي ضرور هن خصوصيت جو اندازو لڳائڻ گهرجي (تقريبن ليڊ ٽائيم + 30٪) x 2) ۽ ڪسٽمر ڏانهن اشارو ڪيو ته اهو اسان کي ان کي مڪمل ڪرڻ لاء گهڻو وقت وٺندو، گڏوگڏ ڊيڊ لائن کي ٻن سان ضرب ڪيو ويو تخميني وقت لاءِ منتقل ڪيو ويو آهي. اچو ته ڪم کي تيز ڪريون - عظيم، هرڪو صرف هن مان فائدو وٺندو. جيڪڏهن نه، پوء اسان کي بيمه ڪيو ويو آهي.
ج) ڇا اسان ٽيم ۾ قبول نٿا ڪريون:
- بي اتفاقي ، بي اتفاقي ، ڀلجڻ
- ”ناشتو کارائڻ“. جيڪڏهن توهان ڪم مڪمل نه ٿا ڪري سگهو، توهان کي خبر ناهي ته ڪيئن، پوء توهان کي فوري طور تي ٽيم ليڊر کي ان بابت مطلع ڪرڻ جي ضرورت آهي، ۽ آخري وقت تائين انتظار نه ڪريو.
- برووا ۽ فخر هڪ شخص کان جيڪو اڃا تائين ثابت نه ڪيو آهي پنهنجي صلاحيتن ۽ پيشه ورانه عمل سان. جيڪڏهن ثابت ٿيو ته پوءِ اهو ممڪن آهي، شرافت جي حدن ۾ 🙂
- ان جي سڀني ظاهر ۾ فريب. جيڪڏهن ڪم مڪمل نه ٿيو ته پوءِ توهان کي ان جي اسٽيٽس کي مڪمل ڪرڻ ۾ تبديل نه ڪرڻ گهرجي ۽ ڪلائنٽ جي چيٽ ۾ لکو ته اهو تيار آهي. ڪمپيوٽر خراب ٿي ويو، سسٽم خراب ٿي ويو، ڪتي ليپ ٽاپ تي چيليو - اهو سڀ ڪجهه ناقابل قبول آهي. جيڪڏهن هڪ حقيقي طاقت جو شڪار ٿئي ٿو، پوء ٽيم جي اڳواڻ کي فوري طور تي اطلاع ڏنو وڃي.
- جڏهن هڪ ماهر هر وقت آف لائن آهي ۽ ڪم جي ڪلاڪن دوران هن تائين پهچڻ ڏکيو آهي.
- ٽيم ۾ زهر جي اجازت ناهي! جيڪڏهن ڪنهن کي ڪنهن ڳالهه تي اختلاف آهي ته پوءِ سڀ گڏ ٿي جلسي لاءِ گڏ ٿين ٿا ۽ بحث مباحثو ڪري فيصلو ڪن ٿا.
۽ ڪيترائي سوال / ٿيسز جيڪي آئون ڪڏهن ڪڏهن پنهنجي گراهڪ کان پڇان ٿو ته سڀئي غلط فهميون دور ڪن:
- توهان جي معيار جا معيار ڇا آهن؟
- توهان ڪيئن اندازو لڳايو ته هڪ پروجيڪٽ مسئلا آهي يا نه؟
- سسٽم کي تبديل ڪرڻ / بهتر ڪرڻ بابت اسان جي سڀني سفارشن ۽ صلاحن جي ڀڃڪڙي ڪندي، سڀ خطرا صرف توهان جي طرفان پيدا ڪيا ويا آهن
- پروجيڪٽ جي ڪا به وڏي تبديلي (مثال طور، هر قسم جي اضافي وهڪري) سببن جي ممڪن ظهور کي ڏسندي (جنهن کي اسين، يقينا، درست ڪنداسين)
- اهو سمجهڻ ناممڪن آهي ته ڪجهه منٽن ۾ پروجيڪٽ تي ڪهڙي قسم جو مسئلو پيش آيو، ۽ اڃا به وڌيڪ، ان کي درست ڪرڻ لاء.
- اسان هڪ مخصوص پراڊڪٽ جي وهڪري تي ڪم ڪريون ٿا (زهيرا ۾ ڪم - ترقي - جاچ - ڊيپلائي). هن جو مطلب آهي ته اسان چيٽ ۾ درخواستن ۽ شڪايتن جي پوري وهڪري جو جواب نٿا ڏئي سگهون.
- پروگرامر صرف پروگرامر آهن، نه پروفيشنل ٽيسٽ ڪندڙ، ۽ پروجيڪٽ جي جاچ جي مناسب معيار کي يقيني بڻائي نٿا سگهن
- حتمي جانچ ۽ وڪري تي ڪمن جي قبوليت جي ذميواري مڪمل طور تي توهان سان آهي
- جيڪڏهن اسان اڳ ۾ ئي هڪ ڪم ورتو آهي، ته پوءِ اسان فوري طور تي ٻين ڏانهن تبديل نه ٿا ڪري سگهون جيستائين اسان موجوده هڪ کي مڪمل نه ڪريون (ٻي صورت ۾ اهو اڃا به وڌيڪ بگ ۽ ترقي جي وقت ۾ اضافو ٿي ويندو)
- ٽيم ۾ گهٽ ماڻهو آهن (ڇوڪرين يا بيمارين جي ڪري)، ۽ وڌيڪ ڪم آهي ۽ اسان وٽ جسماني طور تي وقت نه هوندو ته توهان هر شي جو جواب ڏينداسين.
- dev تي آزمائشي ڪمن کانسواءِ پروڊڪشن تي لڳائڻ لاءِ توهان کان پڇڻ صرف توهان جو خطرو آهي ، نه ڊولپر جو
- جڏهن توهان مبهم ڪمن کي ترتيب ڏيو ٿا، بغير درست وهڪري جي، بغير ڊزائن جي ترتيب جي، ان لاءِ اسان کان وڌيڪ ڪوشش ۽ عمل ۾ وقت جي ضرورت آهي، ڇو ته اسان کي توهان جي بدران اضافي ڪم ڪرڻو پوندو.
- بگ تي ڪو به ڪم، انهن جي موجودگي ۽ اسڪرين شاٽس جي تفصيلي وضاحت کان سواءِ، اسان کي اهو سمجهڻ جو موقعو نه ٿو ڏئي ته ڇا غلط ٿيو آهي ۽ اسان هن بگ کي ڪيئن خارج ڪري سگهون ٿا.
- پروجيڪٽ جي ڪارڪردگي ۽ حفاظت کي بهتر ڪرڻ لاء مسلسل سڌارڻ ۽ سڌارن جي ضرورت آهي. تنهن ڪري، ٽيم پنهنجو ڪجهه وقت خرچ ڪري ٿو انهن سڌارن تي.
- ان حقيقت جي ڪري ته اسان وٽ اوور ٽائم ڪلاڪ (تڪڙي اصلاح) آهن، اسان کي ٻين ڏينهن تي انهن جي تلافي ڪرڻ گهرجي
ضابطي جي طور تي، گراهڪ فوري طور تي سمجهي ٿو ته سافٽ ويئر جي ترقي ۾ هر شيء بلڪل سادو ناهي، ۽ اڪيلو خواهش واضح طور تي ڪافي ناهي.
عام طور تي، اهو سڀ ڪجهه آهي. پردي جي پويان، مان ڪيترن ئي ڳالهين ۽ سڀني عملن جي شروعاتي ڊيبنگ کي ڇڏي ڏيان ٿو، پر نتيجي طور، سڀ ڪجهه ڪم ڪيو. مان چئي سگهان ٿو ته اهو عمل اسان لاء هڪ قسم جي "سلور بلٽ" بڻجي چڪو آهي. نوان ماڻهو جيڪي پراجيڪٽ ۾ آيا هئا، اهي پهريان ئي پهرين ڏينهن کان ڪم ڪرڻ لاءِ پاڻ کي استعمال ڪري سگھن ٿا، ڇاڪاڻ ته سڀئي عمل بيان ڪيا ويا آهن، ۽ ڊاگرامس جي صورت ۾ دستاويز ۽ فن تعمير کي فوري طور تي اهو خيال ڏنو ويو ته اسان سڀ ڇا ڪري رهيا آهيون. هتي.
پي ايس مان واضح ڪرڻ چاهيان ٿو ته اسان جي پاسي ڪو به پروجيڪٽ مينيجر ناهي. اهو ڪلائنٽ جي پاسي تي آهي. بلڪل ٽيڪنيڪل ناهي. يورپي پروجيڪٽ. سڀ ڪميونيڪيشن صرف انگريزيءَ ۾ آهي.
توهان جي منصوبن تي سڀني لاء سٺي قسمت. نه ساڙيو ۽ پنهنجي عمل کي بهتر ڪرڻ جي ڪوشش ڪريو.
منهنجو ذريعو .
جو ذريعو: www.habr.com