🥇আমাদের পণ্যের বিকাশের জন্য আমরা কীভাবে ধারণা বেছে নেব: বিক্রেতা অবশ্যই শুনতে সক্ষম হবেন...

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

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

ধারনা

সূত্র

5টি উত্স রয়েছে:

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

অনুরোধের শ্রেণীবিভাগ

আমরা উৎস থেকে কাঁচা তথ্য পাই - চিঠি, টিকিট, মৌখিক অনুরোধ। সব
আপিল শ্রেণীবদ্ধ করা হয়:

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

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

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

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

পরিবর্তনের অনুরোধ প্রসেস করা হচ্ছে

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

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

পণ্য কার্যকারিতা ব্যবস্থাপনা

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

প্রকৃতপক্ষে, প্রযুক্তিগত কাউন্সিল অ্যাপ্লিকেশনগুলিতে প্রকাশিত চাহিদাগুলি পর্যালোচনা করে শিল্প এবং বাজারের চাহিদার প্রতি সাড়া দেয়। সামান্য প্রাসঙ্গিক সবকিছু ব্যাকলগে থেকে যায় এবং উন্নয়নে পৌঁছায় না।

পরিবর্তনের অনুরোধ এবং অর্থের শ্রেণীবিভাগ

উন্নয়ন ব্যয়বহুল। অতএব, আমরা অবিলম্বে আপনাকে বলব যে আমাদের কাছে কী বিকল্প থাকতে পারে যদি পরিবর্তনের অনুরোধটি একজন ক্লায়েন্টের কাছ থেকে আসে এবং একজন কর্মচারীর কাছ থেকে আসে না।

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

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

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

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

DevOps

বিকাশ বছরে দুটি বড় রিলিজ প্রস্তুত করে। প্রতিটি প্রকাশে, কারিগরি পরিষদ থেকে প্রাপ্ত 5টি কার্য বাস্তবায়নের জন্য সময় সংরক্ষিত রয়েছে। এইভাবে, রুটিনের মাঝখানে, আমরা কখনই পণ্য বিকাশের কথা ভুলে যাই না।

প্রতিটি রিলিজ পরীক্ষা এবং ডকুমেন্টেশনের একটি উপযুক্ত সেটের মধ্য দিয়ে যায়। এর পরে, এই রিলিজটি সংশ্লিষ্ট গ্রাহকের পরীক্ষার পরিবেশে ইনস্টল করা হয়, যারা ঘুরেফিরে, সাবধানতার সাথে সবকিছু পরীক্ষা করে এবং শুধুমাত্র তার পরেই রিলিজটি উত্পাদনে স্থানান্তরিত হয়।

রিলিজ সিস্টেম ছাড়াও, দ্রুত বাগ ফিক্সের জন্য একটি বিন্যাস রয়েছে যাতে ক্লায়েন্টরা ছয় মাস ধরে ত্রুটির সাথে বাঁচতে না পারে। এই মধ্যবর্তী বিন্যাসটি আপনাকে প্রথম-অগ্রাধিকারের ঘটনাগুলিতে দ্রুত প্রতিক্রিয়া জানাতে এবং বর্ণিত SLAগুলি পূরণ করতে অনুমতি দেবে।

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

উত্স: www.habr.com

আমরা কীভাবে আমাদের পণ্যগুলির বিকাশের জন্য ধারণাগুলি চয়ন করি: বিক্রেতা অবশ্যই শুনতে সক্ষম হবেন...

একটি মন্তব্য জুড়ুন উত্তর বাতিল