বৃদ্ধি প্রকল্পে বিকাশকারীর মানসিকতা

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

টুলস একটি মাধ্যম, শেষ নয়

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

যেকোন টুল, প্যাটার্ন বা প্রোগ্রামিং ল্যাঙ্গুয়েজ শুধুমাত্র একটি টুল , লক্ষ্য নয়। প্রায়শই প্রশ্ন: কেন আমার এখন এটি প্রয়োজন? এটা কি প্রদান করবে? কোন মেট্রিক্স এটি উন্নত হবে? উদাহরণস্বরূপ: কেন এখন একটি লিন্টার কনফিগার করবেন? কেন এখন CI/CD কাস্টমাইজ করবেন? আপনি যদি দিনে 10 বার একটি স্থাপনা করছেন, আপনার সম্ভবত এটি প্রয়োজন। আপনি যদি সপ্তাহে বা মাসে একবার একটি রিলিজ স্থাপন করেন, সম্ভবত আপনি তা করবেন না। যদি CI/CD কাস্টমাইজেশন অনেক সময় নেয়, কিন্তু উন্নয়নের গতি বাড়ে না বা প্রকল্প এবং গ্রাহকদের জন্য মূল্য আনে না, তাহলে এটি কি এখনই বাস্তবায়ন করা উচিত?

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

রিফ্যাক্টরিং তখনই প্রয়োজনীয় যখন এটি বিকাশের গতি এবং কর্মক্ষমতা বাড়াবে, বাগগুলি হ্রাস করবে বা ব্যাকলগ আনব্লক করবে।

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

ব্যবসার মান প্রথমে আসে

একটি ক্রমবর্ধমান প্রকল্পে একজন বিকাশকারীর জন্য, ব্যবসার মূল্য বোঝা অপরিহার্য। আপনি যখন একজন নিয়মিত বিকাশকারী হিসাবে অভ্যস্ত হন যিনি কেবলমাত্র প্রস্তুত-তৈরি বৈশিষ্ট্য অনুযায়ী কোড করেন, এটি প্রথমে চ্যালেঞ্জিং হতে পারে।

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

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

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

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

অনেক প্রশ্ন জিজ্ঞাসা করুন: "কেন এই বৈশিষ্ট্যটি এখনই বাস্তবায়ন করবেন? আমাদের কি এখনই এই সমস্যাটি সমাধান করা উচিত? এই সমস্যাটিও কি বিদ্যমান?" এটি প্রযুক্তির সাথে উপরে বর্ণিত হিসাবে ঠিক একই। সঠিক প্রশ্ন জিজ্ঞাসা করতে সক্ষম হওয়া আপনার পেশাদারিত্ব প্রকাশ করে। আপনাকে কেবলমাত্র আপনার সময় এবং ব্যবসার সংস্থানগুলি এমন জিনিসগুলিতে ব্যয় করতে হবে যা আপনার গ্রাহকদের জন্য সত্যই মূল্য নিয়ে আসে।

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

পরিকল্পনা ঝুঁকির উপর নির্ভর করে

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

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

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

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

ঝুঁকিগুলি বের করার পরে, আপনাকে কাজের পরিকল্পনা করতে হবে এবং কাজের জন্য একটি সময় অনুমান প্রদান করতে হবে। এই ফ্রেমওয়ার্ক আমি ব্যবহার করি:

• পরিস্থিতি লিখুন বা বোর্ডে তাদের কল্পনা করুন: যেমন, ব্যবহারকারী একটি বোতামে ক্লিক করেন এবং নথিটি ডাউনলোড হয়। আপনি বুঝতে পারেন যে পন্থা চয়ন করুন.

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

• পরিস্থিতিগুলিকে যৌক্তিক অংশে ভেঙে ফেলুন যা কোড করা দরকার।

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

  
  

  একটি বড় অনুমান দিতে ভয় পাবেন না: যখন একজন স্টেকহোল্ডার জিজ্ঞাসা করেন, "আপনি কি এটি দ্রুত করতে পারবেন না?" শুধু "না" উত্তর দিবেন না, তবে কেন ন্যায্যতা দিন। ঝুঁকি সম্পর্কে বলুন, পরিস্থিতি প্রদর্শন করুন এবং উদাহরণ দিন। স্টেকহোল্ডারকে বুঝতে হবে যে আপনি সমস্যাটি বিশ্লেষণ করেছেন এবং শুধু এলোমেলোভাবে মূল্যায়ন করেননি।

গুরুত্বপূর্ণ দিক: আপনার মনের অবস্থাও একটি ঝুঁকি। আপনার অবকাশের পরিকল্পনা করুন, এবং অনুপ্রাণিত থাকার জন্য আপনার মানসিক স্বাস্থ্যের দিকে নজর রাখুন এবং জ্বলে উঠবেন না: এটি আপনার দায়িত্ব।

MVP একটি মহাকাশযান নয়

প্রশ্ন "কীভাবে একটি MVP তৈরি করবেন?" আমার পুরো ক্যারিয়ার আমাকে বিরক্ত করেছে। সহজ শোনাচ্ছে - ন্যূনতম কার্যকর পণ্য।

উইকিপিডিয়া সংজ্ঞা:

একটি ন্যূনতম কার্যকর পণ্য (MVP) হল এমন একটি পণ্যের একটি সংস্করণ যার শুধুমাত্র পর্যাপ্ত বৈশিষ্ট্যগুলি প্রাথমিক গ্রাহকদের দ্বারা ব্যবহারযোগ্য হতে পারে যারা ভবিষ্যতে পণ্যের বিকাশের জন্য প্রতিক্রিয়া প্রদান করতে পারে।

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

আমি আপনাকে আমার প্রথম MVP সম্পর্কে বলব। আমি অনেক টুলস এবং ফ্রেমওয়ার্ক পেয়েছি: UML, ডিজাইন প্যাটার্নস, রোডম্যাপ, স্টোরি পয়েন্টস, সিস্টেম রিকোয়ারমেন্ট স্পেসিফিকেশন, ADR, UI পরীক্ষা ইত্যাদি । আমি এই সমস্তগুলি ব্যবহার করার সিদ্ধান্ত নিয়েছি কারণ এই ফ্রেমওয়ার্কগুলি বড় সংস্থাগুলির মধ্যে ব্যবহৃত হয় এবং আমি সেগুলি সম্পর্কে সম্মেলন, বক্তৃতা এবং YouTube এ শুনেছি৷

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

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

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

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

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

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

সমস্ত পুনরাবৃত্তি লক্ষ্যে আঘাত করেছে, এবং 4র্থ চেষ্টায়, আমরা 100% আঘাত করেছি। স্ক্র্যাচ থেকে সবকিছু পুনর্লিখন করতে 10টি পুনরাবৃত্তি লাগবে, কিন্তু এমনকি কম সময়ে, আমরা একটি মাপযোগ্য পরিষেবা পেয়েছি যা সমস্যার সমাধান করেছে। একমাত্র প্রশ্ন হল পদ্ধতি।

ক্রমবর্ধমান প্রকল্পে একজন বিকাশকারীর কোডেক্স

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

• যেখানে সম্ভব রেডিমেড সমাধান ব্যবহার করুন।

• ব্যবসার মান প্রথমে আসে। ব্যবহারকারীরা পণ্যের জন্য আসে না, তারা তাদের সমস্যার সমাধানের জন্য আসে।

• শুরু থেকেই ঝুঁকি মূল্যায়ন করুন এবং সেগুলি স্টেকহোল্ডারদের কাছে স্পষ্টভাবে জানান।

• স্বল্পমেয়াদী পরিকল্পনা করুন। যদি টাস্কটি দুই বছর ধরে ব্যাকলগে থাকে, সম্ভবত, ব্যবহারকারীদের এটির প্রয়োজন নেই।

• প্রতিটি সম্ভাব্য উপায়ে প্রতিক্রিয়া এবং মেট্রিক্স সংগ্রহ করুন। মেট্রিক্স হল বৃদ্ধির পয়েন্ট খুঁজে পাওয়ার একটি নির্ভরযোগ্য উপায়।

• স্কেলেবল সমাধানগুলি অর্জন করা যেতে পারে এমনকি যখন "সঠিক" ইঞ্জিনিয়ারিং প্যাটার্নগুলি শুরুতে ব্যবহার করা হয় না।