একটি আইটি প্রকল্পে একটি দলে কর্মপ্রবাহের সংগঠন

হ্যালো বন্ধুরা. প্রায়শই, বিশেষ করে আউটসোর্সিংয়ে, আমি একই চিত্র দেখি। বিভিন্ন প্রকল্পে দলে একটি স্পষ্ট কর্মপ্রবাহের অভাব।

সবচেয়ে গুরুত্বপূর্ণ বিষয় হল প্রোগ্রামাররা বুঝতে পারে না কিভাবে গ্রাহকের সাথে এবং একে অপরের সাথে যোগাযোগ করতে হয়। একটি মানসম্পন্ন পণ্য বিকাশের একটি ক্রমাগত প্রক্রিয়া কীভাবে তৈরি করা যায়। কিভাবে আপনার কর্মদিবস এবং স্প্রিন্টের পরিকল্পনা করবেন।

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

এক সময়ে, আমি এমন একটি প্রকল্পে শেষ করেছি, যেখানে এই সমস্ত আনন্দ ছিল।

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

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

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

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

যেহেতু এটি আমার প্রকল্পে কাজ করে, সম্ভবত এটি কাউকে সাহায্য করবে। সুতরাং, প্রক্রিয়াটি নিজেই যা আমাদের প্রকল্পটি সংরক্ষণ করতে সহায়তা করেছে:

"আমার প্রিয় প্রকল্প" প্রকল্পে দলের কাজের প্রক্রিয়া

ক) অভ্যন্তরীণ দল প্রক্রিয়া (ডেভেলপারদের মধ্যে)

• জিরা পদ্ধতিতে সব সমস্যা তৈরি হয়
• প্রতিটি কাজ যতটা সম্ভব বর্ণনা করা উচিত এবং কঠোরভাবে একটি কর্ম সম্পাদন করা উচিত
• যে কোনো বৈশিষ্ট্য, যদি তা যথেষ্ট জটিল হয়, তা অনেক ছোট ছোট কাজে বিভক্ত হয়
• দলটি একক কাজ হিসাবে বৈশিষ্ট্যগুলিতে কাজ করে। প্রথমত, আমরা সবাই একসাথে একটি বৈশিষ্ট্যে কাজ করি, এটিকে পরীক্ষার জন্য পাঠাই, তারপর পরবর্তীটি গ্রহণ করি।
• ব্যাকএন্ড বা ফ্রন্টএন্ডের জন্য প্রতিটি কাজ চিহ্নিত করা হয়
• কাজ এবং বাগ ধরনের আছে. আপনি তাদের সঠিকভাবে নির্দেশ করতে হবে.
• একটি কাজ শেষ করার পরে, এটি কোড পর্যালোচনা স্থিতিতে স্থানান্তরিত হয় (এই ক্ষেত্রে, একজন সহকর্মীর জন্য একটি টান অনুরোধ তৈরি করা হয়)
• যে ব্যক্তি কাজটি সম্পন্ন করেছে সে অবিলম্বে এই কাজের জন্য তার সময় ট্র্যাক করে।
• কোডটি পরীক্ষা করার পরে, PR অনুমোদন করবে এবং এর পরে, যিনি এই কাজটি করেছেন তিনি স্বাধীনভাবে এটিকে মাস্টার শাখায় একীভূত করেন, তারপরে তিনি এর স্থিতি পরিবর্তন করে ডেভ সার্ভারে স্থাপনার জন্য প্রস্তুত হন।
• ডেভ সার্ভারে স্থাপনের জন্য প্রস্তুত সমস্ত কাজ টিম লিড (তার দায়িত্বের ক্ষেত্র) দ্বারা নিযুক্ত করা হয়, কখনও কখনও কোনও দলের সদস্য দ্বারা, যদি কিছু জরুরী হয়। স্থাপনের পরে, ডেভেলপমেন্টের জন্য প্রস্তুত থেকে ডেভের সমস্ত কাজ স্ট্যাটাসে স্থানান্তরিত হয় - ডেভ-এ পরীক্ষার জন্য প্রস্তুত
• সমস্ত কাজ গ্রাহক দ্বারা পরীক্ষা করা হয়
• গ্রাহক যখন dev-এ কাজটি পরীক্ষা করে দেখেন, তখন তিনি এটিকে উৎপাদনে স্থাপনের জন্য প্রস্তুত অবস্থায় স্থানান্তর করেন
• উত্পাদনে স্থাপনার জন্য, আমাদের একটি পৃথক শাখা রয়েছে, যেখানে আমরা স্থাপনের আগে কেবলমাত্র মাস্টারকে একত্রিত করি
• যদি পরীক্ষার সময় গ্রাহক বাগ খুঁজে পান, তবে তিনি সংশোধনের জন্য কাজটি ফেরত দেন, এটির স্থিতি সংশোধনের জন্য ফেরত হিসাবে সেট করে। এইভাবে আমরা নতুন কাজগুলি থেকে আলাদা করি যারা পরীক্ষায় উত্তীর্ণ হয়নি।
• ফলস্বরূপ, সমস্ত কাজ তৈরি থেকে সমাপ্তির দিকে যায়: করণীয় → বিকাশে → কোড পর্যালোচনা → dev-তে প্রস্তুত → QA on dev → (dev-এ ফেরত যান) → প্রস্তুত → পণ্যে QA → সম্পন্ন
• প্রতিটি ডেভেলপার তার কোড স্বাধীনভাবে পরীক্ষা করে, যার মধ্যে একজন সাইট ব্যবহারকারী হিসেবেও রয়েছে। কোডটি কাজ করে কিনা তা নিশ্চিতভাবে জানা না থাকলে একটি শাখাকে প্রধান শাখায় একত্রিত করার অনুমতি দেওয়া হয় না।
• প্রতিটি কাজের অগ্রাধিকার থাকে। অগ্রাধিকার হয় গ্রাহক বা দলের নেতৃত্ব দ্বারা সেট করা হয়.
• বিকাশকারীরা প্রথমে অগ্রাধিকারমূলক কাজগুলি সম্পূর্ণ করে।
• যদি সিস্টেমে বিভিন্ন বাগ পাওয়া যায় বা একটি টাস্ক একাধিক বিশেষজ্ঞের কাজ নিয়ে গঠিত হয় তবে বিকাশকারীরা একে অপরকে কাজগুলি বরাদ্দ করতে পারে।
• গ্রাহক যে সমস্ত কাজ তৈরি করেন তা টিম লিডের কাছে যায়, যিনি সেগুলিকে মূল্যায়ন করেন এবং হয় গ্রাহককে সেগুলি সংশোধন করতে বলেন বা দলের সদস্যদের একজনকে অর্পণ করেন৷
• dev বা prod-এ স্থাপনার জন্য প্রস্তুত সমস্ত কাজ টিম লিডের কাছেও যায়, যিনি স্বাধীনভাবে নির্ধারণ করেন কখন এবং কীভাবে স্থাপনা চালাতে হবে। প্রতিটি স্থাপনার পরে, টিম লিড (বা দলের সদস্য) গ্রাহককে এই বিষয়ে অবহিত করতে হবে। এবং কাজের জন্য স্থিতি পরিবর্তন করে dev/cont-এর জন্য পরীক্ষার জন্য প্রস্তুত করুন।
• প্রতিদিন একই সময়ে (আমাদের জন্য এটি 12.00 এ) আমরা সমস্ত দলের সদস্যদের মধ্যে একটি মিটিং করি
• দলনেতা সহ মিটিংয়ে উপস্থিত সবাই রিপোর্ট করে যে তারা গতকাল কি করেছে এবং আজ তারা কি করবে। কি কাজ করে না এবং কেন. এইভাবে পুরো দলটি জানে যে কে কী করছে এবং প্রকল্পটি কোন পর্যায়ে রয়েছে। এটি আমাদের অনুমান এবং সময়সীমা প্রয়োজন হলে পূর্বাভাস দেওয়ার এবং সামঞ্জস্য করার সুযোগ দেয়।
• সভায়, টিম লিড প্রকল্পের সমস্ত পরিবর্তন এবং গ্রাহকের দ্বারা পাওয়া যায়নি এমন বর্তমান বাগগুলির স্তর সম্পর্কেও কথা বলে। সমস্ত বাগ বাছাই করা হয় এবং তাদের সমাধান করার জন্য প্রতিটি দলের সদস্যকে বরাদ্দ করা হয়।
• সভায়, দলের নেতা ডেভেলপারদের বর্তমান কাজের চাপ, তাদের পেশাদার প্রশিক্ষণের স্তর এবং ডেভেলপার বর্তমানে যা করছেন তার সাথে একটি নির্দিষ্ট কাজের নৈকট্য বিবেচনা করে প্রতিটি ব্যক্তিকে কাজগুলি অর্পণ করেন।
• সভায়, দলের নেতা স্থাপত্য এবং ব্যবসায়িক যুক্তির জন্য একটি সাধারণ কৌশল তৈরি করে। এর পরে পুরো দল এটি নিয়ে আলোচনা করে এবং সমন্বয় বা এই কৌশল গ্রহণ করার সিদ্ধান্ত নেয়।
• প্রতিটি বিকাশকারী কোড লেখেন এবং একটি একক আর্কিটেকচার এবং ব্যবসায়িক যুক্তির কাঠামোর মধ্যে স্বাধীনভাবে অ্যালগরিদম তৈরি করেন। প্রত্যেকেই তাদের বাস্তবায়নের দৃষ্টিভঙ্গি প্রকাশ করতে পারে, কিন্তু কেউ কাউকে এইভাবে করতে বাধ্য করছে না এবং অন্যথায় নয়। প্রতিটি সিদ্ধান্তই ন্যায়সঙ্গত। যদি একটি ভাল সমাধান থাকে, কিন্তু এখন এটির জন্য কোন সময় নেই, তাহলে কোডের একটি নির্দিষ্ট অংশের ভবিষ্যতের রিফ্যাক্টরিংয়ের জন্য চর্বিতে একটি কাজ তৈরি করা হয়।
• যখন একজন বিকাশকারী একটি কাজ গ্রহণ করেন, তখন তিনি এটিকে উন্নয়ন স্থিতিতে স্থানান্তর করেন। গ্রাহকের সাথে টাস্কের স্পষ্টীকরণ সংক্রান্ত সমস্ত যোগাযোগ বিকাশকারীর কাঁধে পড়ে। টিম লিড বা সহকর্মীদের কাছে প্রযুক্তিগত প্রশ্ন করা যেতে পারে।
• যদি বিকাশকারী টাস্কটির সারমর্ম বুঝতে না পারে এবং গ্রাহক এটি পরিষ্কারভাবে ব্যাখ্যা করতে অক্ষম হন, তবে তিনি পরবর্তী টাস্কে এগিয়ে যান। এবং দলের নেতৃত্ব বর্তমানটি নেয় এবং গ্রাহকের সাথে এটি নিয়ে আলোচনা করে।
• প্রতিদিন, ডেভেলপারকে ক্লায়েন্টের চ্যাটে লিখতে হবে যে সে গতকাল কোন টাস্কে কাজ করেছে এবং আজ সে কোন টাস্কে কাজ করবে।
• কাজের প্রক্রিয়া স্ক্রাম অনুযায়ী সঞ্চালিত হয়। সবকিছু স্প্রিন্টে বিভক্ত। প্রতিটি স্প্রিন্ট দুই সপ্তাহ স্থায়ী হয়।
• দলের নেতৃত্ব দ্বারা স্প্রিন্ট তৈরি, ভরা এবং বন্ধ করা হয়।
• যদি প্রকল্পের কঠোর সময়সীমা থাকে, তাহলে আমরা আনুমানিকভাবে সমস্ত কাজ অনুমান করার চেষ্টা করি। এবং আমরা একটি স্প্রিন্ট মধ্যে তাদের একসঙ্গে করা. গ্রাহক যদি স্প্রিন্টে আরও কাজ যোগ করার চেষ্টা করেন, তাহলে আমরা অগ্রাধিকার সেট করি এবং পরবর্তী স্প্রিন্টে কিছু অন্যান্য কাজ স্থানান্তর করি।

খ) গ্রাহকের সাথে কাজ করার প্রক্রিয়া

• প্রতিটি বিকাশকারী গ্রাহকের সাথে যোগাযোগ করতে পারে এবং করা উচিত
• গ্রাহককে খেলার নিজস্ব নিয়ম আরোপ করার অনুমতি দেওয়া যাবে না। ভদ্র এবং বন্ধুত্বপূর্ণ পদ্ধতিতে গ্রাহকের কাছে এটি স্পষ্ট করা প্রয়োজন যে আমরা আমাদের ক্ষেত্রের বিশেষজ্ঞ, এবং শুধুমাত্র আমাদের অবশ্যই কাজের প্রক্রিয়া তৈরি করতে হবে এবং গ্রাহককে সেগুলিতে জড়িত করতে হবে।
• এটি প্রয়োজনীয়, আদর্শভাবে, কোনো কার্যকারিতা বাস্তবায়ন শুরু করার আগে, বৈশিষ্ট্যটির (ওয়ার্কফ্লো) জন্য সমগ্র যৌক্তিক প্রক্রিয়ার একটি ফ্লোচার্ট তৈরি করা। এবং নিশ্চিতকরণের জন্য গ্রাহকের কাছে পাঠান। এটি শুধুমাত্র জটিল এবং সুস্পষ্ট কার্যকারিতার ক্ষেত্রে প্রযোজ্য নয়, উদাহরণস্বরূপ, একটি পেমেন্ট সিস্টেম, বিজ্ঞপ্তি সিস্টেম ইত্যাদি। এটি আমাদের গ্রাহকের ঠিক কী প্রয়োজন তা আরও সঠিকভাবে বুঝতে, বৈশিষ্ট্যের জন্য ডকুমেন্টেশন সংরক্ষণ করতে এবং গ্রাহক ভবিষ্যতে বলতে পারে যে আমরা যা বলেছি তা আমরা করিনি তার বিরুদ্ধে নিজেদেরকে নিশ্চিত করার অনুমতি দেবে।
• সমস্ত ডায়াগ্রাম/ফ্লোচার্ট/যুক্তি ইত্যাদি আমরা এটিকে কনফ্লুয়েন্স/ফ্যাটে সংরক্ষণ করি, যেখানে আমরা গ্রাহককে মন্তব্যে ভবিষ্যতের বাস্তবায়নের সঠিকতা নিশ্চিত করতে বলি।
• আমরা প্রযুক্তিগত বিবরণ দিয়ে গ্রাহকের বোঝা না করার চেষ্টা করি। গ্রাহক কীভাবে এটি চান তা যদি আমাদের বোঝার প্রয়োজন হয়, তাহলে আমরা একটি ফ্লোচার্ট আকারে আদিম অ্যালগরিদম আঁকি যা গ্রাহক নিজেই সবকিছু বুঝতে এবং সংশোধন/পরিবর্তন করতে পারে।
• যদি গ্রাহক প্রকল্পে একটি বাগ খুঁজে পান, তাহলে আমরা আপনাকে ফ্যাট-এ এটিকে বিশদভাবে বর্ণনা করতে বলি। কোন পরিস্থিতিতে এটি ঘটেছে, কখন, পরীক্ষার সময় গ্রাহকের দ্বারা কী ক্রিয়াকলাপ করা হয়েছিল। স্ক্রিনশট সংযুক্ত করুন.
• আমরা প্রতিদিন চেষ্টা করি, সর্বোচ্চ প্রতি অন্য দিন, ডেভ সার্ভারে স্থাপন করার জন্য। গ্রাহক তারপর কার্যকারিতা পরীক্ষা করতে শুরু করে এবং প্রকল্পটি নিষ্ক্রিয় থাকে না। একই সময়ে, এটি গ্রাহকের জন্য একটি চিহ্নিতকারী যে প্রকল্পটি সম্পূর্ণ বিকাশে রয়েছে এবং কেউ তাকে রূপকথার গল্প বলছে না।
• এটি প্রায়শই ঘটে যে গ্রাহক তার কী প্রয়োজন তা পুরোপুরি বুঝতে পারে না। কারণ তিনি নিজের জন্য একটি নতুন ব্যবসা তৈরি করছেন, এমন প্রক্রিয়া সহ যা এখনও প্রতিষ্ঠিত হয়নি। অতএব, একটি খুব সাধারণ পরিস্থিতি হল যখন আমরা কোডের সম্পূর্ণ টুকরো ট্র্যাশে ফেলে দিই এবং অ্যাপ্লিকেশন লজিকটিকে পুনরায় ডিজাইন করি। এটি এই থেকে অনুসরণ করে যে আপনি পরীক্ষা দিয়ে একেবারে সবকিছু কভার করা উচিত নয়। পরীক্ষার মাধ্যমে শুধুমাত্র সমালোচনামূলক কার্যকারিতা, এবং তারপর শুধুমাত্র সংরক্ষণের সাথে কভার করা বোধগম্য।
• এমন পরিস্থিতি রয়েছে যখন দল বুঝতে পারে যে আমরা সময়সীমা পূরণ করছি না। তারপরে আমরা কাজগুলির একটি দ্রুত অডিট করি এবং অবিলম্বে গ্রাহককে এটি সম্পর্কে অবহিত করি। পরিস্থিতি থেকে বেরিয়ে আসার উপায় হিসাবে, আমরা সময়মতো গুরুত্বপূর্ণ এবং সমালোচনামূলক কার্যকারিতা চালু করার পরামর্শ দিই এবং বাকিগুলি প্রকাশের পরে ছেড়ে দেওয়ার জন্য।
• গ্রাহক যদি তার মাথা থেকে বিভিন্ন কাজ নিয়ে আসা শুরু করে, কল্পনা করতে শুরু করে এবং তার আঙ্গুল দিয়ে ব্যাখ্যা করতে শুরু করে, তাহলে আমরা তাকে আমাদের একটি পৃষ্ঠা বিন্যাস প্রদান করতে বলি এবং যুক্তি দিয়ে প্রবাহিত করতে বলি যা সম্পূর্ণ বিন্যাসের আচরণকে সম্পূর্ণরূপে বর্ণনা করবে এবং এর উপাদান।
• কোনো কাজ নেওয়ার আগে, আমাদের অবশ্যই নিশ্চিত করতে হবে যে এই বৈশিষ্ট্যটি আমাদের চুক্তি/চুক্তির শর্তাবলীতে অন্তর্ভুক্ত ছিল। যদি এটি একটি নতুন বৈশিষ্ট্য হয় যা আমাদের প্রাথমিক চুক্তির বাইরে যায়, তবে আমাদের অবশ্যই এই বৈশিষ্ট্যটির মূল্য দিতে হবে (আনুমানিক সমাপ্তির সময় + 30%) x 2) এবং গ্রাহককে নির্দেশ করতে হবে যে এটি সম্পূর্ণ করতে আমাদের এত সময় লাগবে, এছাড়াও সময়সীমা দুই দ্বারা গুণিত অনুমান সময় দ্বারা স্থানান্তরিত হয়। আসুন কাজটি দ্রুত করি - দুর্দান্ত, সবাই এতে উপকৃত হবে। যদি না হয়, তাহলে আমরা আপনাকে কভার করেছি।

গ) আমরা একটি দলে যা গ্রহণ করি না:

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

এবং অনেকগুলি প্রশ্ন/থিসিস যা আমি মাঝে মাঝে আমার গ্রাহককে সমস্ত ভুল বোঝাবুঝি দূর করতে বলি:

1. আপনার মানের মানদণ্ড কি?
2. একটি প্রকল্পে সমস্যা আছে কিনা তা আপনি কীভাবে নির্ধারণ করবেন?
3. সিস্টেম পরিবর্তন/উন্নতির বিষয়ে আমাদের সমস্ত সুপারিশ এবং পরামর্শ লঙ্ঘন করে, সমস্ত ঝুঁকি শুধুমাত্র আপনার দ্বারা বহন করা হয়
4. প্রকল্পে যে কোনো বড় পরিবর্তন (উদাহরণস্বরূপ, সমস্ত ধরণের অতিরিক্ত প্রবাহ) বাগগুলির সম্ভাব্য উপস্থিতির দিকে পরিচালিত করবে (যা আমরা অবশ্যই ঠিক করব)
5. প্রকল্পে কী ধরনের সমস্যা হয়েছে তা কয়েক মিনিটের মধ্যে বোঝা অসম্ভব, তা অবিলম্বে ঠিক করা অনেক কম
6. আমরা একটি নির্দিষ্ট পণ্য প্রবাহে কাজ করি (ঝিরা-তে কাজ - উন্নয়ন - পরীক্ষা - স্থাপন)। এর অর্থ হল আমরা চ্যাটে সমস্ত অনুরোধ এবং অভিযোগের প্রবাহের প্রতিক্রিয়া জানাতে পারি না।
7. প্রোগ্রামাররা প্রোগ্রামার, পেশাদার পরীক্ষক নয় এবং প্রকল্প পরীক্ষার সঠিক গুণমান নিশ্চিত করতে পারে না
8. চূড়ান্ত পরীক্ষা এবং উত্পাদন কাজ গ্রহণের জন্য দায়িত্ব সম্পূর্ণরূপে আপনার উপর
9. যদি আমরা ইতিমধ্যে একটি কাজ হাতে নিয়ে থাকি, তবে আমরা বর্তমানটি সম্পূর্ণ না করা পর্যন্ত আমরা অবিলম্বে অন্যদের সাথে স্যুইচ করতে পারি না (অন্যথায় এটি আরও বেশি বাগ এবং বিকাশের সময় বৃদ্ধি করে)
10. দলে কম লোক রয়েছে (ছুটি বা অসুস্থতার কারণে), তবে আরও কাজ রয়েছে এবং আপনি যা চান তার প্রতিক্রিয়া জানাতে শারীরিকভাবে আমাদের কাছে সময় নেই
11. আমরা আপনাকে ডেভ-এ পরীক্ষিত কাজ ছাড়াই প্রোডাকশনে মোতায়েন করতে বলি - এটি শুধুমাত্র আপনার ঝুঁকি, ডেভেলপারদের নয়
12. আপনি যখন অস্পষ্ট কাজগুলি সেট করেন, সঠিক প্রবাহ ছাড়াই, ডিজাইন লেআউট ছাড়াই, এর জন্য আমাদের থেকে অনেক বেশি প্রচেষ্টা এবং বাস্তবায়নের সময় প্রয়োজন, কারণ আপনার পরিবর্তে আমাদের অতিরিক্ত পরিমাণ কাজ করতে হবে
13. বাগগুলির কোনও কাজ, তাদের ঘটনার বিস্তারিত বিবরণ এবং স্ক্রিনশট ছাড়া, কী ভুল হয়েছে এবং কীভাবে আমরা এই বাগটি ঠিক করতে পারি তা বোঝার সুযোগ দেয় না
14. কর্মক্ষমতা এবং নিরাপত্তা উন্নত করার জন্য প্রকল্পটির ধ্রুবক পরিমার্জন এবং উন্নতি প্রয়োজন। অতএব, দলটি তার সময়ের কিছু অংশ এই উন্নতিতে ব্যয় করে
15. আমাদের ঘন্টার মধ্যে ওভারটাইম থাকার কারণে (জরুরি সংশোধন), আমাদের অবশ্যই অন্যান্য দিনে তাদের জন্য ক্ষতিপূরণ দিতে হবে

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

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

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

আপনার প্রকল্পে প্রত্যেকের জন্য শুভকামনা. জ্বলে উঠবেন না এবং আপনার প্রক্রিয়াগুলি উন্নত করার চেষ্টা করবেন না।

আমার মধ্যে উৎস ব্লগ পোস্ট.

উত্স: www.habr.com