আপনার প্রোগ্রামাররা লটারি জিতলে আপনার সংস্থাগুলি ডুবে যাবে না তা কীভাবে নিশ্চিত করা যায় [বন্ধ]


28

আমার অধীনে কয়েকজন প্রোগ্রামার রয়েছে, তারা সকলেই খুব দুর্দান্ত এবং খুব স্মার্ট স্পষ্টতই করছে। আপনাকে অনেক ধন্যবাদ.

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

আমি তাদের programাকতে নতুন প্রোগ্রামার আনার কথা ভাবছি, যদি তারা বাসে ধাক্কা খায়, বা পদত্যাগ করে বা যাই হোক না কেন। তবে আমি ভীত

  1. পুরানো প্রোগ্রামাররা জ্ঞান স্থানান্তরের ধারণাটিকে সক্রিয়ভাবে প্রতিহত করতে পারে, এই আশঙ্কায় যে কোনও ব্যাকআপ তাদের মান হ্রাস করতে পারে।
  2. বিভিন্ন বিকাশকারীদের মধ্যে প্রযুক্তি হস্তান্তর সহজ করার জন্য আমার কাছে সিস্টেম নেই, তাই আমি যদি তাদের এটি করতে বলি তবে আমার কোনও আশ্বাস নেই যে তারা এটি সঠিকভাবে করবে।

আমার প্রশ্ন হ'ল,

  1. এটি পুরানো প্রোগ্রামারদের কাছে কীভাবে রাখবেন তারা তাতে একমত হবে
  2. এই জাতীয় "ব্যাকআপ" সুবিধার্থে আপনি কী সিস্টেমগুলি ব্যবহার করেন? আমি বুঝতে পারি যে আপনি কোড পর্যালোচনা করতে পারেন, তবে এটি পরিচালনা করার কোনও সহজ উপায় আছে? আমি মনে করি আমরা সম্পূর্ণ ব্লোন্ড, চেক ইন কোড পর্যালোচনার জন্য প্রস্তুত নই।

4
আপনি সর্বদা উল্লেখ করতে পারেন যে প্রদত্ত অঞ্চলে অতিরিক্ত বাজে কাজ করার কারণে আপনি অন্য অঞ্চল অনুসন্ধান করার পরিবর্তে সেই অঞ্চলটি কেপিয়ে রাখতে পারবেন। এটি প্রোগ্রামিং জ্ঞানের পক্ষেও যায় তাই এটি তাদের কাজগুলিকে নিরাপদ রাখে যাতে অন্যেরা যা জানেন তারা তা জানেন।

1
একটি কাজ, আমাদের অফিস লটারি পুল ছিল। ম্যানেজার যোগদানের জন্য জোর দিয়েছিলেন, এই কারণেই যে তিনি আমাদের আটকে রাখতে চাইলে সেখানে আটকাতে চান না।
ডেভিড থর্নলি

3
জেফ? এটা কি তুমি! অভিশাপ আপনি ভাল আমাদের হত্যা করার চেষ্টা করা হবে না!

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

1
@ কারা দুর্ভাগ্যক্রমে প্রশ্নটি এক নয় - আপনি বাসের ধাক্কায় এমন কাউকে গেমের ভালবাসার জন্য থাকতে রাজি করতে পারবেন না! :)
নিকোল

উত্তর:


19

এটি পুরানো প্রোগ্রামারদের কাছে কীভাবে রাখবেন তারা তাতে একমত হবে

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

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

এই জাতীয় "ব্যাকআপ" সুবিধার্থে আপনি কী সিস্টেমগুলি ব্যবহার করেন? আমি বুঝতে পারি যে আপনি কোড পর্যালোচনা করতে পারেন, তবে এটি পরিচালনা করার কোনও সহজ উপায় আছে? আমি মনে করি আমরা সম্পূর্ণ ব্লোন্ড, চেক ইন কোড পর্যালোচনার জন্য প্রস্তুত নই।

আমাদের দলে কোড / ডিজাইন পর্যালোচনা বাদে আমরা ব্যবহার করি

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

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


Team/project wiki, আপনি এই বিস্তারিত বলতে পারেন? এবং এছাড়াও, face-to-face knowledge transfer sessionsআপনি কি এই ধরণের অধিবেশন নিয়মিত একটি নির্দিষ্ট সময় ধরে রাখেন?
গ্রাভিটন

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

Knowledge transfers we do on when needed, সম্ভবত এমন সময় কোনও কর্মী পদত্যাগ করবেন? এর জন্য প্রয়োজনীয় সময়টি কি খুব বেশি সংক্ষিপ্ত হবে না?
গ্রাভিটন

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

12

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

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

হতে পারে তারা কিছু বিষয়ে জোড়ায় কাজ করতে পারে, যদি তারা অনুসন্ধানী প্রকৃতির হয় তবে কোনও সমস্যা হওয়া উচিত নয়।


4

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

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

তারপরে আপনি নতুন লোক নিয়োগের বিষয়টি বিবেচনা করতে পারেন। বা না, আপনার সংস্থার কাজের চাপের উপর নির্ভর করে।


@ এ্যাম্মিউকিউ, এই স্কেলগুলি কিনা খুব বেশি নিশ্চিত নয়; আপনি নতুন লোক নিয়োগের পরে কি হবে, আপনি আবার ইউএমএল আঁকতে যাচ্ছেন? এবং যদি ডিজাইনের আর্কিটেকচার পরিবর্তন হয়? সেগুলি পর্যালোচনা করার জন্য আপনার কি কোনও ব্যবস্থা আছে?
গ্রাভিটন

2
@ গ্রাভিটন: নতুন লোকেরা বিদ্যমান স্টাফদের দ্বারা লিখিত ডকুমেন্টেশন সবেমাত্র পড়েন। ইউএমএল চিত্রগুলি আবার আঁকার দরকার নেই। যদি আর্কিটেকচার পরিবর্তন হয়, আপনাকে ডকুমেন্টেশন গ্রহণ করতে হবে। হ্যাঁ, যে স্তন্যপান, আমি জানি। তবে আপনাকে এটিতে সহায়তা করার জন্য ইউএমএল সরঞ্জাম রয়েছে, তারা উত্স কোডটি পড়ে এবং শ্রেণীর চিত্র এবং স্টাফ তৈরি করে gene
ব্যবহারকারী 281377

বিটিডাব্লু, আপনি কীভাবে মনে করেন যে নতুন কর্মীরা সফ্টওয়্যারটির ইন্টার্নালগুলি শিখবে যখন সোর্স কোড ছাড়া শেখার জন্য এবং বিদ্যমান প্রোগ্রামারদের জিজ্ঞাসা করার জন্য কিছুই নেই?
ব্যবহারকারী 281377

@ আম্মকিউ, আমি জানি না; যদি আমি জানতাম তবে আমাকে প্রশ্ন করতে হবে না।
গ্রাভিটন

1
@ ওস্টারওয়াল, ভাগ্যক্রমে আমরা এখন একটি স্ট্যান্ডার্ড বিল্ড ম্যানেজমেন্ট সিস্টেম (মাভেন) ব্যবহার করতে পারি, তাই বিল্ড প্রক্রিয়াটির বিশদ ডকুমেন্ট করার জন্য কেবলমাত্র একটি ন্যূনতম প্রয়োজন is (এবং যদি কোনও টিম সদস্য বিল্ড কনফিগারেশন আপডেট না করে নতুন মডিউল যোগ করেন তবে আমাদের সকলেই 5 মিনিটের মধ্যে কনটিনিউস ইন্টিগ্রেশন সার্ভার থেকে একটি মেইল ​​পেয়ে যাবেন যে বিল্ডটি ভেঙে গেছে, এবং কার দ্বারা।) তবে হ্যাঁ, ফিরে যখন আমি কাস্টমটি লিখেছিলাম বিল্ডস এবং রিলিজগুলি স্বয়ংক্রিয় করার জন্য স্ক্রিপ্টগুলি, আমি সেগুলি ভাল করে নথিভুক্ত করেছি।
পিটার তারেক

4

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

আমি বিশ্বাস করি এর জন্য সঠিক এইচআর ভাষা হ'ল উত্তরাধিকার পরিকল্পনা । এটি মোকাবেলার জন্য আপনার কোম্পানির ইতিমধ্যে নীতি এবং ফ্রেমওয়ার্ক থাকতে পারে।


4

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

বড় প্রকল্পগুলির জন্য যা সিনিয়র বিকাশকারীরা কখনও কখনও কোনও প্রকল্পের দৈর্ঘ্যের জন্য সিস্টেমের অন্য অংশে জুনিয়র বিকাশকারী হিসাবে কাজ করার জন্য বলা হয়েছিল যাতে তারা অন্যান্য সিস্টেমগুলি শিখতে শুরু করতে পারে।

দলটির প্রসার ও বর্ধনের সময় বিদ্যমান বিকাশকারীদের জ্ঞান এবং জ্যেষ্ঠতার প্রতি শ্রদ্ধা করার মূল চাবিকাঠিটি ছিল। এটি একটি ধীর প্রক্রিয়া ছিল তবে সময়ের সাথে সাথে ঠিকঠাক কাজ করেছে।


4

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

আপনি যা করতে চান তা বোঝাতে হবে যে জিনিসগুলি আসলে কীভাবে আপনার এখনকার দলটিকে আঘাত করছে। আপনি যে পয়েন্টগুলি পেতে চান তা এখানে এবং অগ্রাধিকার হিসাবে এই ক্রমে:

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

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

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

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

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


2

ইন্টার্নগুলি একটি ভাল ধারণা হতে পারে, তারা বর্তমান বিকাশকারীদের সরাসরি অধস্তন হতে হবে, তাই তারা হুমকী অনুভব করবে না।

সংস্থাটি বাড়ার সাথে সাথে আপনার পুরানো বিকাশকারী এবং তাদের ইন্টার্নশিপের পরে যারা তৈরি করেছেন তাদের উভয়ের প্রয়োজন হবে।

আমি মনে করি এটি কাজ করতে পারে।


1

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

প্রত্যেককে তাদের সমস্ত প্রক্রিয়া এবং প্রক্রিয়াগুলি ডকুমেন্ট করতে বলা হয়

" কর্পোরেট ডুমের সতর্কতা লক্ষণ " এর স্তর 3 ।

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


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

1
@oosterwol - উত্পাদনশীল উন্নয়ন দলকে একত্রিত করতে ও পরিচালনা করতে সক্ষম হওয়াই মূল্যবানতার তুলনায় অনেক ভাল ভবিষ্যদ্বাণী। আপনার কাছে দুর্দান্ত ডকুমেন্টেশন রয়েছে তা বলা যেমন আপনার দুর্দান্ত উত্স নিয়ন্ত্রণ রয়েছে like অবশ্যই এগুলি প্রয়োজনীয়, তবে এটি আপনাকে প্রতিযোগিতা থেকে আলাদা করবে না।
জেফো

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

1

@AmmoQ তার উত্তরে শুরু হয়েছে এমন সম্পূর্ণ ডকুমেন্টেশনের ধারণার ভিত্তিতে ...

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

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

এর অর্থ হ'ল আপনাকেও যা করতে হবে তা নথিভুক্ত করতে হবে এবং আপনার প্রত্যক্ষ প্রত্যক্ষ প্রতিবেদনের প্রশিক্ষণ সরবরাহ করতে হবে। এইভাবে, আপনি যদি আজ মারা যান তবে একটি পূর্ণ-সময়ের প্রতিস্থাপন না পাওয়া পর্যন্ত তাদের মধ্যে একটি আপনার জন্য পূরণ করতে পারে।


আপনি কি ইন্টারনেটে এমন একটি দস্তাবেজের একটি লিঙ্ক সরবরাহ করতে পারেন যা যথেষ্ট পরিমাণে একটি পুরো প্রয়োগ তৈরির জন্য যথেষ্ট পরিমাণে লিখিত একটি স্পেসিফিকেশন দেখায়? আমি মনে করি এটি আরবান মিথের আওতায় পড়ে।
JeffO

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

1

আমি নতুন প্রোগ্রামার আনতে শুরু করার আগে আমি তাদের প্রত্যেককে তাদের নিজস্ব নথিভুক্ত উত্তরাধিকার তৈরিতে সহায়তা করার জন্য বলব।

হয় উইকি, বা তাদের কাজের প্রতিটি দিক সম্পর্কে নথির একটি 3-রিং বাইবেল।

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

তারপরে এর একটি উইকি সংস্করণ তৈরি করুন, যাতে আপনার প্রোগ্রামার আপডেট / সম্পাদনা / অংশগ্রহণ / মন্তব্য করতে পারে।

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

এছাড়াও সত্যই সত্য যে প্রোগ্রামার কেবল একটি মূল অঞ্চলে আটকে থাকা বুদ্ধিমানের কাজ নয়, ট্রেনটি পার হওয়া, ক্রস কোরের কাজটি সত্যিই প্রদান করা উচিত।

তারপরে আপনি নিজের বিদ্যমান কর্মীদের ব্যবহার করতে পারবেন, যখন 1 ব্যক্তি ছুটি নেয় বা এর মতো কিছু করে।


1

আপনার প্রোগ্রামারদের মধ্যে যখনই কোনও অসুস্থ নেই, প্রশ্ন এবং সমস্যা নিয়ে বারবার ফোন করুন।

আপনার প্রোগ্রামারদের মধ্যে যখনই ছুটিতে থাকে তখনই তাকে প্রশ্ন ও সমস্যা নিয়ে বারবার ফোন করুন।

তারা শীঘ্রই বুঝতে পারবেন যে তাদের পক্ষে পাশাপাশি সংস্থার পক্ষে মূল অঞ্চলের জন্য একক লোককে দায়বদ্ধ না করাই ভাল।


0

কেউ বাসে ধাক্কা খেতে চায় না, তবে তারা সংক্ষিপ্ত নোটিশে অন্য কারও প্রকল্প গ্রহণ করতে এবং তাদের প্রকল্পটিও বজায় রাখতে চায় না। তারপরে সবাই ব্যবসার বাইরে যাওয়ার ঝুঁকি চালায়।

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

আপনার কোডের একটি অংশে একাকী বিশেষজ্ঞ থাকা দক্ষতার মায়া।

কেউ কি কখনও ছুটিতে যেতে চান?


0

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

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