কোনও প্রকল্পে নিযুক্ত ব্যক্তিদের সংখ্যা এবং ত্রুটিগুলির সংখ্যার মধ্যে আসলেই কি সম্পর্ক রয়েছে?


12

এখানে এসএলআইএম এবং সফ্টওয়্যার অনুমান সম্পর্কিত কাজের জন্য একটি প্রশিক্ষণ ম্যানুয়াল থেকে একটি উদ্ধৃতি দেওয়া হয়েছে:

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

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

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

পুটনাম মডেল (যা এসএলআইএম দ্বারা ব্যবহৃত হয়) সম্পর্কিত যেগুলি ত্রুটি এবং প্রচেষ্টা বা ত্রুটি এবং কোনও প্রকল্পের লোকের সংখ্যার মধ্যে যে কোনও প্রকারের পরিচিত পরামর্শ দেয়, সেগুলি বাদ দিয়ে আমি কোনও দলিল খুঁজে পাইনি। এটি কি একটি পরিচিত সম্পর্ক, এবং "আরও বেশি লোক = আরও ত্রুটিগুলি" যুক্তি বৈধ?


10
"একটি দেরী সফ্টওয়্যার প্রকল্পের জনশক্তি যোগ করলে তা পরে তোলে" - ফ্রেড ব্রুকস
ওবেদের

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

@ থমাস ওভেনস - হ্যাঁ, উদ্ধৃতিটি প্রকৃতপক্ষে যোগাযোগের চ্যানেলগুলির বৃদ্ধি (এবং তাই অসুবিধা) সম্পর্কে ধারণা করা হচ্ছে যে এটি ত্রুটিগুলির দিকে পরিচালিত করবে।
ওজেড

আমি তখনও বলব যে যখন কোনও প্রকল্পে লোভকারীদের বোঝা নিক্ষেপ করা হয় তখন প্রায়শই এটি একটি ডেথ মার্চের ইঙ্গিত দেয়।
মরগান হের্লোকার

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

উত্তর:


14

আমার অন্তর্দৃষ্টি এইভাবে যায়:

প্রদত্ত আকারের একটি প্রকল্পে যত বেশি লোক নির্ধারিত হয়েছে, যোগাযোগের পরিমাণ ওভারহেড
=> তত বেশি ভুল বোঝাবুঝির সম্ভাবনা বেশি এবং সমস্ত ধরণের যোগাযোগের সমস্যা
=> ফলে প্রাপ্ত ত্রুটির সংখ্যা তত বেশি।

এবং

ভাল বিকাশকারীরা বিরল, মধ্যম / খারাপ লোকগুলির তুলনায় এটির সন্ধান করা এবং ভাড়া নেওয়া আরও শক্তিশালী
=> প্রদত্ত আকারের একটি প্রকল্পে যত বেশি লোক নির্ধারিত হয়, তত কম তাদের যোগ্যতার মাত্রা
=> ফলাফল ত্রুটির সংখ্যা তত বেশি।

তবে এগুলি কেবল আমার যুক্তি হতে পারে, আমার কাছে কোনও সমর্থনকারী প্রমাণ নেই।

পার্শ্ব নোট হিসাবে, আপনার অনুমানগুলি নীচে জোর দেওয়া হয়েছে আইএমএইচও (দুঃখজনকভাবে) আমাদের পেশার অবস্থা বিবেচনা করে:

এটি একটি ভাল প্রক্রিয়া এবং সক্ষম ইঞ্জিনিয়ারদের ধরে নিয়ে পাল্টা সংবেদনশীল বলে মনে হয় । [...] আমার অন্তর্নিহিত পরামর্শ দেয় যে উপযুক্ত মানের কৌশলগুলি ব্যবহার করে এমন কোনও প্রকল্পে প্রচেষ্টা এবং ত্রুটির মধ্যে খুব কম সম্পর্ক রয়েছে ।


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

তবে খুব কম লোকের সাথে আপনি তাদের শক্তির সাথে লেগে থাকার সম্ভাবনা কম রাখেন। এমন কিছু ভাল বিকাশকারীকে নিয়োগ দেওয়া কী সহজ যারা কেবলমাত্র একজন গুরুর পরিবর্তে কোনও অঞ্চলে মনোনিবেশ করতে পারে যারা সব কিছু করতে পারে যদি তারা আসলে আরও ভাল হতে পারে?
জেফো

@ জেফ ও, আপনার একটি বক্তব্য আছে। OTOH যদি প্রতিটি বিকাশকারী কেবল তার নিজের শক্তিশালী অঞ্চলে মনোনিবেশ করে তবে তাদের মধ্যে যোগাযোগ আরও জটিল হতে পারে।
প্যাটার তারেক

1
যোগাযোগটি আরও ঝামেলা বা কেবল প্রয়োজনীয় হয়ে ওঠে?
জেফো

@ জেফ ও, আইএমও একে অপরের ক্ষেত্র সম্পর্কে যত কম বুঝতে পারে, তত বেশি যোগাযোগের প্রয়োজন হয় এবং ভুল বোঝাবুঝি এবং মিথ্যা অনুমানের সম্ভাবনা তত বেশি higher
প্যাটার টারিক

5

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


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

দেরীতে লোকদের যুক্ত করা কেবলমাত্র একটি কারণ যা আমি উল্লেখ করেছি। ম্যানেজমেন্ট এখনও আরও অনেক বেশি মানুষের দায়িত্ব অর্পণ করা একটা প্রবণতা আছে সামনে প্রকল্প তারা আরো ঝুঁকিপূর্ণ বা জটিল হচ্ছে কহা।
কার্ল বিলেফেল্ড

এসএলআইএমের বিন্দু (এবং অন্যান্য অনুমানের সরঞ্জামগুলি, যখন সঠিকভাবে ব্যবহৃত হয়) হ'ল প্রয়োজনীয় সংখ্যার লোক, একটি প্রকল্পের ব্যয়, প্রয়োজনীয় সময়, এবং এরকম অনুমান সহ সহায়তা করা। যাইহোক, এটির জন্য সরঞ্জামটি সঠিকভাবে বোঝা এবং ব্যবহার করা দরকার।
টমাস ওয়েন্স

3

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

সুতরাং যা ঘটছে তা হ'ল বৃহত্তর প্রকল্পগুলির আরও ত্রুটি রয়েছে, যা মোটেও অবাক হওয়ার মতো নয়।


2

এটি একটি ভাল প্রক্রিয়া এবং সক্ষম ইঞ্জিনিয়ারদের ধরে নিয়ে পাল্টা সংবেদনশীল বলে মনে হয়।

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

  • যোগাযোগ ওভারহেড
  • ওভারহেড কোড রিডিং (এর অর্থ এই যে সর্বোত্তম দেবগণ তাদের নিজের থেকে অন্য লোকের কোড পড়তে এবং গ্রাস করতে বেশি সময় নেয়)
  • টেস্টিং অবশ্যই আরও বিশদ হতে হবে (আমরা সবাই 100% পরীক্ষা কভারেজের জন্য শুট করি, তবে বাস্তব জগতে এটি খুব কমই ঘটে। পার্শ্ব প্রতিক্রিয়া হবে না। সমস্ত পরীক্ষা এমনকি কোনও যুক্তিসঙ্গত পদ্ধতিতে স্বয়ংক্রিয় করা যায় না, যা আরও বেশি সময় নেয়))

আমার অভিজ্ঞতায় বিকাশকারীদের দ্বারা লোড হওয়া প্রকল্পগুলির নেতিবাচক প্রভাবগুলি হ্রাস পায় যখন প্রকল্পটি খুব মডুলার হয় এবং আপনার প্রতি স্তরের প্রতি 1 বা 2 জন লোক থাকে। আপনি কোন সংস্করণ নিয়ন্ত্রণ সিস্টেমটি ব্যবহার করছেন তা আমি মাথা ঘামাই না, 4 টি বিকাশকারী একই সাথে একই ফাইলটিতে সমস্ত স্ব-মার্জ করা চেকিনগুলি সম্ভবত খারাপ ধারণা হতে পারে।


যদি একই ফাইলে 4 টি দেবকে কাজ করা প্রতিরোধের একমাত্র উপায় হয় টিমের আকার 3 এর মধ্যে সীমাবদ্ধ করা, আপনি বড় সমস্যা পেয়েছেন।
জেফো

2

পারস্পরিক সম্পর্ক এবং কারণের মধ্যে পার্থক্য রয়েছে; উদ্ধৃতিটি বলে মনে হচ্ছে যে মোট ত্রুটিগুলির সংখ্যা প্রজেক্টের জন্য বেশি যেখানে প্রকৌশলীগুলির বৃহত সংখ্যক বরাদ্দ রয়েছে for এটি আমার কাছে নিখুঁতভাবে উপলব্ধি করে, আমি নিশ্চিত যে আমি তৈরি করা অ্যাপ্লিকেশনগুলির চেয়ে এমএস উইন্ডোজের আরও ত্রুটি রয়েছে, তবে এর অর্থ এই নয় যে আমার অ্যাপ্লিকেশনগুলি উচ্চতর মানের।

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


উইন্ডোজের সাথে আপনার উদাহরণের জন্য, আমি নিশ্চিত যে উইন্ডোজের ত্রুটিযুক্ত হওয়ার জন্য আরও বেশি সুযোগ রয়েছে কারণ এটি বড়। যদি কোনও বিকাশকারী এমন একটি সিস্টেম লিখেছিলেন যা 10 এসএলওসি এবং একটি সিস্টেম যা 10000 এসএলওসি ছিল, 10000 এসএলওসি সহ সিস্টেমটিতে ত্রুটি হওয়ার সম্ভাবনা বেশি থাকে (যার মধ্যে টাইপগুলি সংকলন, নিখোঁজ সেমিকোলন, লজিক ত্রুটিগুলি রোধ করে এবং তাই) । সাধারণত, বড় প্রকল্পগুলিতে আরও প্রকৌশলী থাকত, তবে সম্পর্কটি মানুষের সংখ্যা এবং ত্রুটির মধ্যে নয়, তবে আকার এবং ত্রুটিগুলির মধ্যে।
থমাস Owens

@ থমাস ওভেনস - ইয়েপ্প, এটাই আমার বক্তব্য ছিল।
ড্যানিয়েল বি

প্রকল্পের আকার এবং জটিলতার তুলনায় ত্রুটিগুলি কেন তুলনা করা হবে না?
জেফো

@ জেফো - আপেক্ষিক উপায়ে এটি পরিমাপ করা সম্পূর্ণ তুচ্ছ নয় (আপনি কীভাবে এটি করেন?)। সম্ভবত মূল বিবৃতিটি প্রসঙ্গের বাইরে নিয়ে যাওয়া হয়েছে, তবে লেখকরা খুব কমই জটিল, গণনার ফলাফলকে কেবল "ত্রুটি" হিসাবে উল্লেখ করেছেন। এই জাতীয় ক্ষেত্রে, আমি "মানের" (যা বোঝায় যে কিছু গণনা করা হয়েছিল), বা "নির্ধারিত ইঞ্জিনিয়ার প্রতি ত্রুটিগুলি" এর মতো দীর্ঘতর বাক্যাংশের মতো আরেকটি শব্দ আশা করব would সম্ভবত আমি এখানে লেখকদের প্রতি কিছুটা কৌতূহল বোধ করছি :)
ড্যানিয়েল বি

@ জেফ তারা হবে। তবে আপনি ত্রুটিগুলি আকার এবং জটিলতার সাথে তুলনা করবেন, মানুষের সংখ্যার সাথে নয়। আকার এবং জটিলতা বৃদ্ধির সাথে সাথে ত্রুটিগুলি বৃদ্ধি পায় এবং মানুষের সংখ্যা বৃদ্ধি পায়। সুতরাং হ্যাঁ, যদিও মানুষের সংখ্যা বৃদ্ধি পায় তবে লোকেরা যে বৃদ্ধি ত্রুটির সংখ্যা বাড়ায় না।
থমাস Owens

1

আসুন এক মুহুর্তের জন্য লোকের সংখ্যা সম্পর্কে দৃ .়তা রাখি।

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

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

আমি দেখতে পাচ্ছি না যে আরও বেশি লোকের চেয়ে বেশি লোকের সংখ্যা কীভাবে ফিট করে।

পার্শ্ব নোট হিসাবে, কার্যকারিতা সঙ্গে পারস্পরিক সম্পর্ক বিভ্রান্ত করবেন না। আকার এবং ইনজেকশনের ত্রুটির সংখ্যার মধ্যে পারস্পরিক সম্পর্ক রয়েছে তবে আকারটি কারণ নয়। লোকেরা এবং প্রক্রিয়া সম্পর্কিত সমস্যাগুলি আপনি যেমন উল্লেখ করেছেন তেমন কারণটি সাধারণত আসে। এটি বলেছে যে আকারের ফাংশন হিসাবে ত্রুটিগুলি যদি সমস্যা হয় তা বোঝার জন্য এবং পরিবর্তনের কার্যকারিতা নির্ধারণের জন্য দুর্দান্ত মেট্রিক।


0

আমি ধরে নিচ্ছি এটি মূল প্রোগ্রামিং দলের সদস্যদের মধ্যেই সীমাবদ্ধ এবং এমন কোনও পরিস্থিতি নয় যেখানে বিশেষজ্ঞ রয়েছে যেমন: ইউআই, ইউএক্স, ডিবিএ, ইত্যাদি not

আমি মনে করি এটি ভালভাবে পরিচালনা করা দরকার তবে এটি সহজ নয়। গুণমান বিকাশকারীদের সমন্বয়ে গঠিত ছোট দলগুলি তাদের পরিচালনা করতে পারে। কোডের বৃহত বিভাগগুলি এড়িয়ে যাওয়ার সম্ভাবনা কম প্রতিভা সহ কাউকে তৈরি করেছে।

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

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

বাস্তবতাটি হ'ল, এমন অনেক লোক নেই যারা সফল প্রকল্পে কোনও বড় দলকে পরিচালনা করতে পারেন। এমনকি তারা সবাই মেধাবী হলেও, বড় দলগুলির পক্ষে স্ব-পরিচালনা করা কঠিন difficult ইহোসরা কি পথে যায়?

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