দেরী প্রকল্পে আরও লোক যুক্ত করা কেন এটি পরে তৈরি করে?


25

এটি একটি মোটামুটি প্রচলিত প্রবন্ধ যা দেরিতে প্রকল্পে আরও প্রোগ্রামার যুক্ত করা বিষয়টিকে আরও খারাপ করে দেবে। কেন?


14
এর জন্য শব্দটি হ'ল ব্রুকস আইন ( en.wikedia.org/wiki/Brooks's_law )।
ম্যাকনিল

7
পরামর্শ: ব্রুকস '' দ্য মিথিক্যাল ম্যান-মাস 'পড়ুন। এই প্রবন্ধটি কোথা থেকে এসেছে তা এটি দেখায়, এটি একটি খুব পঠনযোগ্য বই এবং ক্ষেত্রের প্রত্যেকেরই এটি যেভাবেই পড়তে হবে।
ডেভিড থর্নলি

উইকিপিডিয়া পৃষ্ঠাটি খুব ভাল লেখা আছে।
হেনরি

কিভাবে উৎপাদনশীলতা দলের আকার সঙ্গে কমে যায় প্রমাণ স্বরূপ (7 দলের সদস্যদের ওপারে আপনার কমা আয় ঢোকা), দেখতে qsm.com/process_improvement_01.html
Joeri Sebrechts

উত্তর:


33

উপরি পরিচয়

প্রতিটি নতুন বিকাশকারীকে কোড বেস এবং বিকাশ প্রক্রিয়াতে প্রবর্তন করতে হবে যা কেবলমাত্র নতুন ব্যক্তির সময় নেয় না তবে [এ] প্রবীণ বিকাশকারী [এর] সহায়তাও প্রয়োজন (বিল্ড প্রক্রিয়াটির মাধ্যমে তাদের গাইডিং, পরীক্ষার প্রক্রিয়াটি ব্যাখ্যা করুন, তাদের সহায়তা করুন কোড ভিত্তিক pitfalls সঙ্গে, আরো অনেক কিছু কোড রিভিউ, ইত্যাদি) বিস্তারিত

অতএব, আপনি প্রকল্পে যত বেশি নতুন বিকাশকারী যুক্ত করবেন তাদের এমন পর্যায়ে আনতে আরও বেশি সময় ব্যয় করতে হবে যেখানে তারা প্রকৃতপক্ষে প্রকল্পে ভূমিকা রাখতে পারে।


সুতরাং আপনি যদি 'পরিচিতি' অপ্টিমাইজ করেন তবে তার প্রভাব কমবে?
হেনরি

9
@ হেনরি: সমস্যা হ'ল আপনি সাধারণত সেই দিকটি এমন কোনও ডিগ্রিতে অনুকূল করতে পারবেন না যেখানে এটি কোনও বাধা নয়। একজন নতুন প্রোগ্রামার প্রথমে আপনার প্রকল্প, আপনার কোড এবং আপনার প্রক্রিয়া সম্পর্কে ঠিক 0 জানে। এটি একই ওভারহেড যা নতুন দলের সদস্য যুক্ত করার সময় সর্বদা প্রয়োজন। তবে যখন কোনও প্রকল্প ইতিমধ্যে দেরিতে চলছে তখন টিমের কাছে প্রায়শই সঠিক পরিচয় করানোর সময় থাকে না এবং যদি এটি সময় করে তবে তা প্রকৃত বিকাশ থেকে অনুপস্থিত। সুতরাং এটি সাধারণত দলের জন্য একটি হেরে যাওয়ার পরিস্থিতি এবং নতুন ব্যক্তি প্রকল্পে অর্থবহ অবদান রাখতে না পারতে অনেক বেশি সময় নেয়।
বেলনর্ন

কোনও ভূমিকা দেওয়ার ব্যয় সম্পর্কে, এটি কি একবার ভিডিও-টেপ করা যায় না এবং তারপরে অনেকের কাছে সম্প্রচার করা যায়, যাতে এটি একবারে প্রচুর সংখ্যক নতুন প্রোগ্রামারকে প্রশিক্ষণ দিতে পারে? (উদাহরণস্বরূপ: বিকাশকারী সভা বা সম্মেলন))
২৮

7
@ রুং: এটি কোনও খারাপ ধারণা নয়, তবে এটি সাধারণত ব্যবহারিক হয় না। আপনি কেবল তথ্য উপস্থাপন করতে পারবেন না, আপনাকে নতুন ছেলেরা বুঝতে পেরেছে তা নিশ্চিত করতে হবে। এছাড়াও, যদি তারা সত্যই নতুন হয় (সাম্প্রতিক গ্রেডগুলি), তবে তাদের সকলের কাছে একবারে উপস্থাপন করার জন্য সাধারণত খুব বেশি তথ্য থাকে। আমরা খুঁজে পেয়েছি যে একটি উইকি ভাল কাজ করে, যেমন সমস্ত তথ্য এক জায়গায় থাকে এবং লোকেরা যদি বিট না বুঝতে পারে তবে প্রশ্ন পোস্ট করতে পারে।
TMN

একটি সম্ভাবনা হ'ল খুব উপযুক্ত নতুন ব্যক্তিকে নিয়োগ দেওয়া এবং তাদের অন্যকে বিরক্ত না করে নির্দিষ্ট কাজগুলি করার জন্য। তারা খারাপভাবে ফ্লাউন্ডার করবে এবং ধীরে ধীরে কাজ করবে এবং কিছু পরিচালক এবং / অথবা টিম এটি দেখার পক্ষে দাঁড়াতে পারে না। যাইহোক, নতুন বিকাশকারী সেইভাবে পরিচালনা করার সময় নেট প্লাস হতে পারে।
ডেভিড থর্নলি

32

অন্যান্য উত্তর ছাড়াও: বিবেচনা করার জন্য আরেকটি বিষয় হ'ল যোগাযোগ।

একটি টিমের যোগাযোগের চ্যানেলের পরিমাণের জন্য সবচেয়ে খারাপ পরিস্থিতি (যা অস্বাভাবিক নয়), এটি একটি সম্পূর্ণ গ্রাফ । আপনি কল্পনা করতে পারেন, মাত্র 1 বিকাশকারী যোগ করা যোগাযোগ চ্যানেলগুলি অনেক বাড়িয়ে তুলতে পারে। যোগাযোগের আরও প্রবাহিত পদ্ধতিতে, প্রভাব কম ... তবে এটি এখনও যোগ করে।


আমি প্রায় একই সময়ে লিখছিলাম! তবে আমি নতুন ছিলাম না এর একটি নাম ছিল (একটি সম্পূর্ণ গ্রাফ) এবং আপনার ব্যাখ্যাটি আরও ভাল, সুতরাং আমার ভোট আছে।
মিগুয়েল ভেলোসো

+1 টি। সম্মত হন, আরও দলের সদস্য যুক্ত করার সময় এটিই সবচেয়ে বড় সমস্যা।
মার্টিন উইকম্যান

একটি প্রকল্পে লোক যুক্ত করার সাথে আরও দীর্ঘমেয়াদী সমস্যার জন্য +1।
indyK1ng

23

বইটিতে উদ্ধৃত সমস্যাটি মূলত এই আইনটি প্রকাশ করেছে, দ্য মিথিক্যাল ম্যান-মাস , যোগাযোগ। তিনি এই বলে শুরু করে:

পুরুষ এবং মাসগুলি হ'ল বিনিময়যোগ্য পণ্য যখন কেবল কোনও কর্মীর মধ্যে যোগাযোগ নেই এমন অনেক শ্রমিকের মধ্যে ভাগ করা যায়। এটি গমের ফসল কাটা বা তুলা বাছাইয়ের ক্ষেত্রে সত্য; এটি সিস্টেম প্রোগ্রামিংয়ের ক্ষেত্রেও প্রায় সত্য নয়।

তিনি সমস্যার অংশ হিসাবে প্রশিক্ষণের কথা উল্লেখ করেছেন:

যোগাযোগের অতিরিক্ত বোঝা দুটি অংশ নিয়ে গঠিত: প্রশিক্ষণ এবং আন্তঃযোগাযোগ। প্রতিটি কর্মীকে প্রযুক্তি, প্রচেষ্টার লক্ষ্য, সামগ্রিক কৌশল এবং কাজের পরিকল্পনায় প্রশিক্ষিত হতে হবে। এই প্রশিক্ষণটি বিভাজন করা যায় না, সুতরাং কাজের এই অংশটি শ্রমিকের সংখ্যার সাথে রৈখিকভাবে পরিবর্তিত হয়।

... তবে নোট করুন যে আন্তঃসংযোগ অনেক বড় কারণ:

যেহেতু সফ্টওয়্যার নির্মাণ অন্তর্নিহিতভাবে একটি সিস্টেম প্রচেষ্টা - জটিল আন্তঃসম্পর্কমূলক একটি অনুশীলন - যোগাযোগের প্রচেষ্টা দুর্দান্ত এবং এটি পৃথক পৃথক টাস্ক সময় হ্রাসকে দ্রুত বিভাজন দ্বারা প্রভাবিত করে। আরও পুরুষ যুক্ত করা সময়সূচী দীর্ঘায়িত করে, সংক্ষিপ্ত করে না।

এটি ফ্রেড ব্রুকস (লেখক) কী বলছেন তা জানার ব্যাকগ্রাউন্ড রয়েছে তাও লক্ষণীয় worth বইয়ের বেশিরভাগ অংশ আইবিএম এর ওএস / 360 প্রকল্প পরিচালনা করার অভিজ্ঞতার উপর ভিত্তি করে। দশকের দশক ধরে অনুসরণকারীরা "উন্নত" পরিচালনার সমস্ত পদ্ধতি প্রচার করে এবং কেউ কেউ দুর্দান্ত নাম (এক্সট্রিম, এগিল, স্ক্রাম ইত্যাদি) নিয়ে আসে যখন আপনি এতে নামেন, তখন থেকেই সংক্ষিপ্তসার 1 এর কিছুটা পরিবর্তিত হয়েছে বলে মনে হয়।

1 "সংশ্লেষ" এর সংজ্ঞার জন্য, একই লেখকের "নো সিলভার বুলেট: এসেন্সেন্ট অ্যান্ড এক্সসিডেন্ট ইন সফটওয়্যার ইঞ্জিনিয়ারিং" দেখুন, যা পৌরাণিক মানব-মাসের 20 তম বার্ষিকী সংস্করণে অন্তর্ভুক্ত রয়েছে ।


12

এটি নিছক প্রবাদ নয়; এটি যাচাইযোগ্য ব্রুকস ' দ্য মিথিক্যাল মান-মাস দেখুন


1
এটি একটি প্রবাদ এটি যাচাইযোগ্য হতে পারে বা নাও হতে পারে, তবে এটি প্রামাণ্য হওয়াটি থামায় না।
পিটার বুটন

3
আমার কাছে এই বই নেই (স্পষ্টতই)। এটি কি হার্ড সংখ্যা দ্বারা ব্যাক আপ করা হয় বা এটি অজানা?
হেনরি

2
@ হেনরি: আমি যখন এটি পড়েছি অনেকক্ষণ হয়ে গেছে তবে আইআইআরসি, উভয়ই পর্যাপ্ত পরিমাণে এই বিষয়টিকে অবশেষে বলার জন্য উপস্থিত রয়েছে।
স্টিভেন এভার্স 0

@ পিটার: আমার উত্তর সম্পাদনা করেছেন।
জন

@ পিটারবুটন এটি একটি প্রবাদ এছাড়াও, এটি নিছক একটি প্রবাদ নয়
সান্টিবাইলার্স

6

এখানে এই ইস্যুতে কিছু চিন্তা ...

  • প্রকল্পটি কী চলছে তার গতি বাড়ানোর জন্য নতুন সংস্থানগুলি আনতে বর্তমান সংস্থানগুলি ব্যবহার করা দরকার।
  • নতুন সংস্থান কোডের সাথে পরিচিত নাও হতে পারে, সুতরাং কোডটিতে সজ্জিত হওয়ার জন্য আরও বেশি সময় প্রয়োজন।

এখন, পরীক্ষার জন্য নতুন সংস্থান যুক্ত করা কোনও খারাপ ধারণা হতে পারে না ... এটি পরীক্ষার প্রক্রিয়াটি গতিতে পারে (যদি আপনার পরীক্ষার কেসগুলি ভালভাবে লেখা থাকে), এবং হ্যাঁ পরীক্ষার সরঞ্জামগুলি ব্যবহার করাও সহায়তা করবে।


1
উন্নয়নের জন্য নয়, পরীক্ষায় সংস্থান যুক্ত করার জন্য +1।
বেলনর্ন

4

কারণ প্রোগ্রামিং বেসিক প্রোডাকশন লাইনের কাজ নয়। একটি সফ্টওয়্যার প্রকল্পে গতি পেতে সময় লাগে। নতুন লোককে প্রচুর প্রশ্ন জিজ্ঞাসা করতে হবে যা নেতিবাচক উত্পাদনশীলতার দিকে পরিচালিত করে (যেমন নতুন ব্যক্তি শেখা, বয়স্ক ব্যক্তি তাদের শেখায় -> কোনও আসল কাজ শেষ হচ্ছে না)।

এটিকে সহজ করতে, তুলনামূলকভাবে সহজ এক-ম্যান প্রকল্পটি কল্পনা করুন যা 1 সপ্তাহের জন্য নির্ধারিত রয়েছে: বৃহস্পতিবার, আপনি বুঝতে পারেন যে এটি সময়মতো সম্পন্ন হবে না, পরিবর্তে এটি একজন প্রোগ্রামারকে 6-7 দিনের মতো আরও গ্রহণ করবে 5.. যদি আপনি এই মুহুর্তে অন্য কোনও প্রোগ্রামার যুক্ত করেন তবে তাদের প্রোগ্রামার 1 এর সাথে কমপক্ষে কয়েক ঘন্টা বা এক দিন বা তার জন্য কাজ করতে হবে, গতিতে উঠতে প্রচুর প্রশ্ন জিজ্ঞাসা করবেন, ইত্যাদি সম্ভবত আপনি পাবেন না সপ্তাহের বাকি জন্য কোনও নেট পজিটিভ উত্পাদনশীলতা। নতুন প্রোগ্রামারটি সম্ভবত কিছু অতিরিক্ত বাগ প্রবর্তন করতে পারে (যেহেতু তারা বিদ্যমান কোডটি পাশাপাশি প্রোগ্রামার 1 জানবে না), যাতে বাস্তবায়ন এবং পরীক্ষার চক্রটি আরও দু'দিনের মধ্যে ফুটিয়ে তুলবে। প্রকল্পটি আসলটির পরিবর্তে সহজেই পুরো দুই কার্যদিবস স্থায়ী হবে!


ঠিক আছে, আপনার উদাহরণটি প্রকল্পটির অবাস্তব সংক্ষিপ্ত সময়সীমা ছেড়ে যাওয়ার দ্বারা কিছুটা স্বীকৃত। এটিকে এক মাসে পরিবর্তন করুন এবং আপনি দেখতে পাবেন এটি প্রয়োজনীয় সত্য নয়। ব্যক্তিগতভাবে আমি মনে করি উদ্ধৃতিটি আপত্তিজনক ছিল। রানটি অফ দ্য মিল, গড় / দরিদ্র প্রোগ্রামার বিবেচনা করার ক্ষেত্রে এটি সত্য। আপনার যদি ভাল প্রোগ্রামার থাকে এবং সময়সীমাটি 1 দিন বা 1 সপ্তাহের মতো অবাস্তব কিছু না হয় তবে উদ্ধৃতিটি ভুল: এটি করা যেতে পারে (প্রকল্পে সহায়তা করুন)।
n1ckp

@ n1ck এটি একটি সাধারণীকরণ - "অনেকগুলি রান্নার মতো" - মূল বিষয়টি হ'ল প্রকল্পটিতে কেবল জনশক্তি নিক্ষেপ করাই অগত্যা এটির দ্রুত সমাধানের কারণ হবে না। 1 জন 2 কে? সম্ভবত হবে। 2 থেকে 4? অনেকগুলি ভেরিয়েবল - এটি প্রকল্পের আকার এবং কাঠামোর উপর নির্ভর করে। 4 -> 8? অবশ্যই প্রান্তিক হয়ে উঠছে (ব্যয় নেওয়ার ক্ষেত্রে খুব কমপক্ষে)।
মার্ফ

@ মুর্ফ: আপনি বেশিরভাগ ক্ষেত্রে আমার মতো একই জিনিসগুলি ভাবছেন বলে মনে হয় তবে আপনি আপনার সমীকরণের একটি অত্যন্ত গুরুত্বপূর্ণ পরিবর্তনশীল: যুক্ত জনশক্তির দক্ষতা স্তর ভুলে গিয়েছিলেন। এটি আমার সর্বশেষ মন্তব্যে ছিল তাই আমি এটি অদ্ভুত মনে করি যে আপনি এটি মিস করেছেন। অন্ধভাবে জনশক্তি যুক্ত করা অবশ্যই সমাধান নয়। খুব বিশেষায়িত জনশক্তি যুক্ত করা (আপনার অনেকের প্রয়োজন নেই) অবশ্যই সহায়তা করতে পারে এবং এটি পৌরাণিক মানব-মাসের উদ্ধৃতিতে অনুপস্থিত ছিল। আমার বক্তব্য ছিল। নাহলে আমি উক্তিটির অর্থ কী তা সম্পর্কে জানি।
n1ckp

ঠিক আছে, উদাহরণটি আরও ভাল হতে পারে তবে সাধারণীকরণটি এখনও বৈধ?
মার্ফ

1
আমি যথেষ্ট সময় পেরিয়ে এসেছি এটা জেনেছি যে এটি অত্যন্ত বিশেষায়িত ক্ষেত্রে কার্যকরভাবে কাজ করা জিনিসগুলির মধ্যে একটি, তবে 99% সময় এটি ব্যবহার করে না। তাত্ত্বিক সময়ে এটিকে যত ভাল লাগছে তা বিবেচ্য নয়। এটি বলেছিল, হ্যাঁ, এটি কোনও কালো এবং সাদা পরম নয়। এটি আরও বলার মতো, কীভাবে মুক্ত সম্পর্ক কাজ করে না। তত্ত্বটি দুর্দান্ত, এবং লোভনীয়;) .... তবে পশুর প্রকৃতি এমন যে বেশিরভাগ ক্ষেত্রে এটি ব্যর্থ হয়ে যায়। "ব্যতিক্রমগুলি নিয়মের প্রমাণ দেয়" জিনিসটিকে বাছাই করুন।
ববি টেবিল

4

ফ্রেড ব্রুকস এই প্রশ্নের উত্তর দিয়ে একটি সম্পূর্ণ বই "দ্য মিথোলিক্যাল ম্যান-মাস" লিখেছিলেন।

এখানে দ্রুত-এন-নোংরা সংস্করণ:

1) আরও বেশি প্রোগ্রামারকে বরাদ্দ দেওয়ার জন্য আপনি কোনও প্রকল্পকে আলাদা আলাদা টুকরো টুকরো করতে পারবেন এমন একটি সীমা রয়েছে।

2) একটি প্রকল্পকে আরও বেশি লোকের কাছে বিভক্ত করার ফলে অ্যাপ্লিকেশনটির সমস্ত অংশ সমন্বয় করার জন্য প্রয়োজনীয় যোগাযোগের পরিমাণ বৃদ্ধি পায়। আরও যোগাযোগ = আরও কাজ।

3) আপনি প্রকল্পে যুক্ত প্রতিটি ব্যক্তির জন্য আপনি একাধিক যোগাযোগ চ্যানেল যুক্ত করেন যা অবশ্যই দলে নেভিগেট করতে হবে। এই সংখ্যাটি জ্যামিতিকভাবে বৃদ্ধি পায় এবং যোগাযোগের পরিমাণ বাড়বে যা অবশ্যই ঘটবে। আরও যোগাযোগ = আরও কাজ।

4) আপনি প্রতিটি দলের সদস্য যুক্ত করার সময় একটি "জে-কার্ভ" থাকে। এটি হ'ল, বিদ্যমান উত্পাদনশীল সংস্থানগুলিতে নতুন লোকদের গতি বাড়ানোর জন্য সময় ব্যয় করতে হবে যা তারা অন্যথায় প্রকল্পের কাজ করতে ব্যয় করতে পারত। শেষ পর্যন্ত আপনি ক্ষমতা বৃদ্ধি করতে পারেন, তবে এটি অস্থায়ীভাবে প্রকল্পটি ধীর করে দেয়। প্রকল্পের পরবর্তীতে আরও বেশি কিছু শিখতে হবে, ফলে এর প্রভাব আরও স্পষ্টভাবে প্রকাশিত হবে।


4

আরেকটি কারণ যা আমি উল্লেখ করি নি তা হ'ল কিছু কাজ একটি নির্দিষ্ট ক্রমে করা দরকার। টাস্ক 3 সম্পন্ন হওয়া অবধি আপনি টাস্ক 4 করতে পারবেন না কারণ এটি 3 এর উপর নির্ভরশীল কারণ এটি 4 কারও সাথে টাস্ক 4 দেওয়ার জন্য কোনও ভাল কাজ করে না একই সময়ে কেউ টাস্ক করছেন ৩. প্রায়শই একটি প্রকল্পের শেষে , যে কাজগুলির জন্য অন্যান্য জিনিসগুলি প্রথমে সম্পূর্ণ করা দরকার সেগুলি হ'ল বাকী কাজগুলি।

এগুলি প্রায়শই বেশ কয়েকটি জটিল কাজগুলি করা প্রয়োজন যা ইতিমধ্যে সম্পন্ন হয়েছে যা ভঙ্গ করে এড়াতে পুরো ডিজাইনের সেরা বোঝার প্রয়োজন হয়। এগুলির জন্য সাধারণত সবচেয়ে বিস্তৃত ব্যবসায় ডোমেন জ্ঞান প্রয়োজন। আমি কয়েক মাস ধরে এই প্রকল্পে কাজ করার পরে এক সপ্তাহ বা তারও কম সময়ে টাস্কটি করতে সক্ষম হব। নতুন কেউ গতিতে উঠতে এক সপ্তাহেরও বেশি সময় ব্যয় করবে (এবং প্রশ্নের উত্তর দেওয়ার জন্য আমাকে সেই সময়টির একটি ভাল চিত্রের জন্য আমাকে আমার কাজ থেকে সরিয়ে নিয়েছিল) এবং সম্ভবত অত্যন্ত দক্ষ এমনকি যদি কাজটি করতে বেশি সময় নেয় তবেও হতে পারে। কারণ তিনি বা তিনি সক্ষম নন তবে প্রকল্পের আসল কাঠামো বা ডাটাবেস ব্যাকএন্ডের সাথে অজানা কারণে।


+1 টি। এটি আমার শেষ কাজের একটি বড় সমস্যা ছিল। ব্যবস্থাপনাগুলি মেগা "মেন মাসে" যোগ করে কোনও বড় প্রকল্পের জন্য কিছু চিন্তা না করেই ক্রেজ হয়েছিল। এক পর্যায়ে, আমাদের দলটি ধীর হয়ে যাওয়ার জন্য ড্রিল হয়েছিল - কারণ আমাদের বড় বড় প্রকল্পটির সাথে সংহত করার জন্য আমাদের স্টাফগুলি দরকার। তবে তারপরে, বড় প্রকল্পের নতুন ভাড়াগুলি দ্রুত গতিতে উঠতে পারেনি, সুতরাং আমরা অনেক এগিয়ে চলেছি ( তাদের ব্যাকেন্ডগুলি শেষ করার জন্য প্রয়োজনীয় জিনিসগুলিতে )। এক পর্যায়ে আমরা অর্ধ-বেকড ব্যাকএন্ড এবং পরীক্ষার ক্ষতির জন্য সম্মুখ প্রান্তগুলি বিকাশ করছিলাম। ভাল প্রবাহ নয়।
ববি টেবিলগুলি

2

আমার কাছে সর্বদা অভিবাদনটি হ'ল আপনি এক মাসে নয় জন মহিলাকে বাচ্চা বানাতে পারবেন না।


আপনি যদি মনে করেন কোনও সফ্টওয়্যার প্রকল্প বাচ্চার মতো হয় তবে আপনি বাস্তব বিশ্বে বাস করেন না। উদ্ধৃতিতে কিছু সত্যতা রয়েছে তবে জিনিসগুলি প্রসঙ্গের বাইরে নিয়ে যাওয়ার নিখুঁত উদাহরণ: -1
n1ckp

1
এটা অবশ্যই না। তবে তারা আপনার কাছে টাইম লাইন বিক্রি করেছে তারাও সফ্টওয়্যার বিকাশ বুঝতে পারে না। অ্যানালগগুলি হ'ল একটি সত্তার সাথে একটি অজানা ধারণা সম্পর্কিত সেই উদ্দেশ্যে।
পুনরায় চালু করুন

2
ব্রুকস আরেকটি সাদৃশ্যগুলি একটি রেস্তোরাঁয় খাবার খাওয়ানো। একটি ভাল রান্নাঘর রান্নাঘর সমান্তরালভাবে প্রচুর খাবার তৈরি করতে পারে, তবে এটি কোনও আটকানো বা জ্বালানো ছাড়াই একটি খাবার কতটা দ্রুত তৈরি করতে পারে তার সীমাবদ্ধতা রয়েছে।
ডেভিড থর্নলি

@ আররুন: আপনার সাদৃশ্যটি নিয়ে সমস্যাটি হ'ল গর্ভবতী মহিলাদের জন্য কোনও কর্মীর উপমা নেই। আপনার ক্ষেত্রে মহিলারা আরও সহজে সংস্থার সাথে তুলনা করতে পারেন , শ্রমিক নয়। সে কারণেই এটি আমার মতে এত ব্যর্থ। সবচেয়ে কাছের আমি ভাবতে পারি খাবারটি তবে এটি কোডের লাইনের মতো হবে, তাই না, শ্রমিক নয়।
n1ckp

1
@ এন 1 কে: আমার ধারণাটি হল যে আপনি একমত নন কারণ আপনি এটি বোঝেন না, সত্যি বলতে। ব্রুকস অযোগ্য ব্যক্তিদের যোগ্য লোকদের প্রতিস্থাপনের বিষয়ে কথা বলছিল না, কারণ তিনি এমন পরিস্থিতিতে ছিলেন যেখানে এখনও নিয়োজিত প্রত্যেকেই উপযুক্ত হিসাবে বিবেচিত হত।
ডেভিড থর্নলি

2

আমি ডিমারকো এবং লিস্টার দ্বারা "পিপলওয়্যার" পরামর্শ দিই।

এবং ডি মার্কো রচিত "দ্য ডেটলাইন" এটি উপস্থাপন করে এবং আরও অনেকগুলি সফ্টওয়্যার প্রকল্প পরিচালনা রোগ এবং হালকা হৃদয়যুক্ত এবং খুব পঠনযোগ্য ফ্যাশনে ফ্যালাকগুলি।

এটি প্রকল্প / দল কাজ করে এমন লোকের গতিশীলতা সম্পর্কেও তদন্ত করে, এবং কেবলমাত্র কীভাবে যোগাযোগ এবং ভূমিকা যেমন কোনও দলের উপলব্ধ কার্যকালীন সময়কে হ্রাস করে সে সম্পর্কে কিছু বিশদে যায়।

এই বইগুলি বেশ সস্তা, আমি আপনাকে সেগুলি দেওয়ার প্রস্তাব দিই (অ্যামাজন বা বুক ডিপোজিটরি সেগুলি আছে) এবং পড়ুন। এখানে সংক্ষিপ্ত উত্তর জিজ্ঞাসিত প্রশ্নের সত্যই বিচার করতে পারে না।


2

কারণ কেউ এর জন্য সুচিন্তিত, পরিকল্পনাযুক্ত, পরীক্ষিত প্রক্রিয়া করার জন্য সময় নেয় না: নিয়োগকারী, প্রশিক্ষণ, বিকাশকারী এবং তদারকিকারী প্রোগ্রামারগুলিকে কোনও নির্দিষ্ট প্রকল্পের গতি বাড়ানোর জন্য তাদের একাই ছেড়ে দেয়।

আপনি যদি বিকাশকারীদের একটি দল পরিচালনা করে থাকেন তবে আপনার যদি খোলার ব্যবস্থা থাকে তবে আপনি ভাড়া নিতে চান এমন লোকদের এখনই আপনার বেশ কয়েকটি পরিচিতি থাকা উচিত। বিকাশকারী গ্রুপগুলিতে যোগদান করুন।

আপনি কত দ্রুত ব্র্যান্ডের নতুন বিকাশ মেশিন সেটআপ পেতে পারেন এবং যেতে প্রস্তুত?

আপনি কি কখনও অন্য কোনও প্রকল্পের বিকাশকারীকে দেখিয়ে আপনার প্রকল্পের নথিপত্র এবং চশমাগুলি পরীক্ষা করেছেন? তারা কি এটি দেখেছিল এবং প্রয়োজনে তারা প্রকল্পটিতে কাজ শুরু করতে পারে তা নির্ধারণ করেছে?

কোনও প্রকল্পের সময়সূচি কতটা আপ টু ডেট?

একটি বর্ষার দিনের জন্য সংরক্ষণ করুন কারণ যখন কোনও প্রকল্প তার পিছনে পড়ে তখন হরিকেনের মতো হয়।


1

যোগাযোগের সমস্যাটি বাদ দিয়ে (যা আমি মনে করি যে অন্যান্য সমস্ত উত্তর সম্পর্কে কথা বলছে), কোনও ব্যক্তি কোনও প্রকল্পে যুক্ত হওয়া বা বাগ তৈরি করা খুব সম্ভব, কারণ তারা কোডটি এখনও খুব ভাল জানেন না।

যখনই আমি কোনও প্রকল্পে যুক্ত হই, আমি সর্বদা চেষ্টা করি জিনিসগুলি না ভাঙ্গতে। এর অর্থ আমি প্রথমে জিনিসগুলি ঠিক করতে অনেক ধীর আছি।


0

আমি অন্য উত্তরগুলি দ্বারা এতদূর সম্পূর্ণ উপেক্ষা করা কিছু উল্লেখ করতে চাই।

দেরিতে প্রজেক্টে লোক যুক্ত হওয়ার সময়, সাধারণত পুরো সংস্থা জুড়ে অনেক কিছু ভুল হয়ে গেছে। ম্যানেজমেন্ট এবং ক্লায়েন্ট খুশি নয়। এটির সাথে চালিয়ে যাওয়ার জন্য জনগণকে চাপ দেওয়া হয়েছে। বিষয়গুলি বেশ উত্তেজনাপূর্ণ।

এখন ভাবুন আপনি সেই দলে রয়েছেন। অবশ্যই এগুলির কোনওটিই আপনার দোষ নয়। পরিকল্পনা (যার মধ্যে আপনার কিছুই ছিল না) খুব আশাবাদী হয়েছে। সমস্ত ভুল সিদ্ধান্ত আপনার সাথে পরামর্শ না করেই নেওয়া হয়েছিল। আপনি এটির সেরাটি চেষ্টা করার চেষ্টা করছেন এবং হঠাৎ করেই একগুচ্ছ নতুন লোকের চাকা চলা হচ্ছে this এটি কোন বার্তা দেয়?

উপরের লোকেরা অবশ্যই আপনার প্রতি বিশ্বাস হারিয়ে ফেলেছে। তারা বড় ছেলেরা ডেকেছিল যে আপনি কী গোলমাল করলেন for

আপনি কি এখনও এটিকে সফল করতে অনুপ্রাণিত হবেন? বা ... আপনি কি আরও বেশি হতাশ হবেন এবং আপনি বরং পুরো জিনিসটি ক্র্যাশ করে দেখবেন?

আপনার সময় নিন :-)।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.