এমন ব্যবস্থাপনার সাথে লেনদেন করা যা ব্যবহারকারীর সাথে তত্ক্ষণাত দেখা যায় না এমন উন্নতির মান দেখতে পায় না


90

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

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

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

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

আমার পরিস্থিতি কীভাবে পরিচালনা করা উচিত?

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


2
আমরা কি দীর্ঘকালীন, সমালোচনামূলক অ্যাপগুলির বিষয়ে কথা বলছি? হয়তো বাজার করার সময় maintainability এবং কোড মানের চেয়ে বেশি গুরুত্বপূর্ণ?
আন্দ্রেস এফ।



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

উত্তর:


141

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

সম্ভবত আপনি জরুরি কাজ এবং গুরুত্বপূর্ণ কাজগুলি সম্পর্কে কথা বলতে পারেন। যখন গুরুত্বপূর্ণ কাজগুলি করা হয় না, তখন জরুরি কাজগুলি আরও বেশি সময় নেয় এবং আরও বেশি ব্যয় হয়।


2
আমি অনেক চাকরিতে এই সমস্যাটি বহুবার ডিল করেছি। এই বিষয়গুলি সম্পর্কে আপনি কীভাবে আপনার পরিচালকদের কাছে যেতে পারেন সে সম্পর্কে কিছু ধারণা পেতে আমি টেরি রায়ান দ্বারা "ড্রাইভিং প্রযুক্তিগত পরিবর্তন" পড়ার পরামর্শ দিই। pragprog.com/book/trevan/driving-technical-change
অ্যাড্রিয়ান জে মোরেনো

2
আসলে প্রশ্নটি থেকে আমি অনিশ্চিত যে আসলে debtণ কতটা আদায় হচ্ছে। যদিও স্বয়ংক্রিয় রেফারেন্স গণনা প্রয়োজনীয় আপগ্রেড বলে মনে হচ্ছে আমি "এলোমেলো অদ্ভুত ক্র্যাশগুলির সংখ্যা কমে যাওয়ার সম্ভাবনা আছে" কিনা তা জানতে আমি ডোমেনটির সাথে যথেষ্ট পরিচিত নই। <p> কেবলমাত্র এমভিসি 3-তে নতুন রেজার সিনট্যাক্স ক্লিনার হওয়ার অর্থ এই নয় যে আমার সংস্থাকে আজ বা আগামী মাসেও সেখানে চলে যাওয়া উচিত।
জোশুয়া ড্রেক

3
@ জেনন "প্রযুক্তিগত debtণ" শব্দটি খুব কমই নতুন ...
এন্ড্রেস এফ।

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

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

47

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

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

এই বিষয়টিতে আপনি নিজের সাথে নিতে পারেন এমন কয়েকটি তথ্য এখানে।

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

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


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

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

36

আপনি না।

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

আমি বলি আপনার পরবর্তী প্রযুক্তিগত অনুমানগুলিতে আপনার কাঙ্ক্ষিত পরিবর্তনগুলি বেক করুন। হেই, হোন, অ্যাপল প্রবর্তিত এই নতুন কাঠামোটিতে আমাদের "আপগ্রেড" করতে হবে like এআরসি ব্যবহার করে আপনার রোডম্যাপে আসতে দেবেন না। কোনও বিকল্প নেই; এআরসি-তে স্থানান্তর একমাত্র উপায়।


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

2
+1 টি। আপনি এই ধরণের স্টাফকে যেভাবে যোগাযোগ করেন তা অনুমানের মধ্য দিয়ে। আপনাকে যা করতে হবে তা হ'ল এই প্রত্যাশাটি সেট করা যে আপনি পুরো প্রকল্পের মধ্যে প্রাক্কলন সরবরাহ করবেন (যত তাড়াতাড়ি সম্ভব শুরু হবে) যাতে জড়িতরা সবাই বিনিয়োগের রিটার্ন বুঝতে পারে। এটিকে পরিষ্কার করুন যে তারা অনুমান করছে (এইভাবে, তারা আরও তথ্য ছাড়া পরিবর্তন করে না) এবং আপনি তাদের সাথে যোগাযোগ করছেন যাতে নেতৃত্ব আরও ভাল সিদ্ধান্ত নিতে পারে। তারপরে, আপনি অনুমানগুলি আপনার জন্য কথোপকথন শুরু করতে দেন। "কেন এই পর্বের প্রাক্কলন শেষের তুলনায় বেশি?" "ভাল ..."
nlawalker

1
আপনি ঘুমন্ত ব্যক্তিকে জাগিয়ে তুলতে পারেন, তবে ঘুমানোর ভান করছেন এমন ব্যক্তিকে জাগাতে পারবেন না
ভাইসু

2
আপনি যদি পরিচালককে কারিগরি debtণ ব্যাখ্যা করতে না পারেন তবে আপনার যোগাযোগ দক্ষতা উন্নত করতে হবে। "তারা বোকা, এটি বুঝতে পারে না" এই ভেবে আপনাকে আর পাওয়া যাবে না ... আমি ২ য় অনুচ্ছেদে সমর্থন করি যে আপনার দৃ you় হওয়া উচিত এবং সুবিধাগুলি স্পষ্টভাবে কোম্পানির কাছে জানাতে হবে।
সিয়ামি

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

28

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

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

আমি "চাচা" বব মার্টিন দ্বারা ক্লিন কোডার পড়ার পরামর্শ দেব । ভাল কোড লেখা আপনার কাজের অংশ। আপনি আপনার কাজ করার অনুমতি চান না, আপনি কেবল এটি করেন।


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

7

এই প্রকৃতির অন্যান্য প্রশ্নের মতো আপনাকেও এমন নম্বর সরবরাহ করতে হবে যা পরিচালনা বোঝে। এই উন্নতিগুলি প্রয়োগ করে কতটা সময় বাঁচবে, কত কম "এলোমেলো অদ্ভুত ক্র্যাশগুলি" ঘটবে ইত্যাদি দেখায় এমন নম্বর etc.

আপনি নিজের সময়ে এই উন্নতিগুলি বাস্তবায়নের চেষ্টা করতে পারেন (অর্থাত্ কাজের সময়ের বাইরে) এবং তারপরে পরিচালনার সুবিধাগুলি পরবর্তী সময়ে প্রদর্শন করতে পারেন। আমি কেবল তখনই এটি করতাম যখন এটি স্পষ্ট হয়ে যায় যে আপনি কী জানাতে চাইছেন এবং / অথবা তারা আপনাকে চেষ্টা করার জন্য সময় বরাদ্দ করতে চায় না তা ম্যানেজমেন্ট বুঝতে পারে না।

শুভকামনা!


6
আমি যুক্ত করব যে কেবলমাত্র শেষ ব্যবহারকারীটির জন্য ক্র্যাশগুলি দৃশ্যমান নয়, তারা ব্যবহারকারীদেরও তাড়িয়ে দেয় । এটা ভাল মার্কেটিং শিল্পে যে পরিচিত হয় পথ কঠিন একটি পূর্ববর্তী গ্রাহক win ফিরে তুলনায় এটি বিদ্যমান বেশী রাখতে পারবেন। আপনি কীভাবে বিদ্যমানগুলি রাখবেন? নিশ্চিত করুন যে তারা যে জিনিসগুলি ব্যবহার করে তারা কাজ করে!
সিডেসাক

একটি বিশ্বাসী উপস্থাপনার জন্য আপনার অনুসন্ধানে এখানে কিছু রেফারেন্স উপকরণ আছেন: en.wikipedia.org/wiki/Software_entropy , pragprog.com/the-pragmatic-programmer/extracts/software-entropy , codinghorror.com/blog/2009/02/ …
ম্যাসি অ্যাবে

7

একটি ব্যবসায়িক কেস উপস্থাপন করুন

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

  • অগ্রিম খরচ কি?
  • চলমান ব্যয় কি?
  • প্রস্তাবিত অর্থ / সময় সাশ্রয় কি এবং তারা কোথা থেকে আসে?
  • আরওআই দেখার আগে কতক্ষণ লাগবে?

কোনও ব্যবসায়ের ক্ষেত্রে যখন করা উচিত আপনার ডেটা দিয়ে সর্বদা আপনার যুক্তির ব্যাক আপ করা উচিত।

  • উন্নতি বর্তমানে সমস্যাগুলি মোকাবেলা করতে কত সময় ব্যয় করছে যা এটি সরিয়ে দেবে বা প্রশমিত করবে?
  • এটি যে সমস্যার সাথে সরিয়ে ফেলবে বা প্রশমিত করবে তার সাথে আপনি কতজন অভিযোগ পেয়েছেন?
  • এটির আর কী কী উপকার হবে?

সংখ্যাগুলি সারি করুন এবং এটিকে একটি রুক্ষ, তবে সাধারণ সমীকরণ করুন। এটি করতে এক্স ব্যয় করবে এবং এটি ওয়াই সংস্থাকে উপকৃত করবে।

দ্রষ্টব্য: একাডেমিকভাবে ভাল ধারণা বাস্তবায়নের জন্য যদি এটি নিষিদ্ধভাবে ব্যয়বহুল হয় তবে অবাক হবেন না।


6

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

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

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

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


5

আপনি উল্লেখ করেছেন যে আপনি যথেষ্ট ভাগ্যবান যে আপনার পরিচালক এবং সিইও উভয়ই প্রোগ্রামার are সুতরাং তারা সম্ভবত না তা বুঝতে প্রযুক্তিগত ঋণ পরিশোধের পর।

পরিস্থিতিগুলিকে তথ্য ভিত্তিক সমাধানের চেষ্টা করার মাধ্যমে পরিস্থিতি সামলানো উচিত, যার অর্থ এমন একটি সম্ভাবনা রয়েছে যে আপনি যে প্রযুক্তিগত উন্নতি করতে চান তা শেষ করবেন না (তথ্যগুলি সেইভাবে বিরক্ত করতে পারে)।

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

কোডের সাথে জড়িত না থাকা লোকেদের জন্য যেমন "লুকানো" জিনিসগুলির উন্নতি করার সুবিধা দেখতে যেমন কঠিন হতে পারে তেমনি ব্যবসায়ের ক্ষেত্রগুলিতে সুবিধাগুলি কিছুটা হলেও অর্জন হলে দৃশ্যমান কোড পরিবর্তনের সুবিধা দেখতে প্রোগ্রামারদের পক্ষে কঠিন হতে পারে " বিকাশকারীদের কাছ থেকে "লুকানো"।

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

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


2

সম্ভবত এটি কোনও উত্তর নয়, তবে আমি যে ভুলগুলি করেছি তার উপর ভিত্তি করে একটি প্রতিক্রিয়া। এছাড়াও আমি এখানে পড়া কিছু দর্শনের সাথে মতভেদ।

  • প্রোগ্রামার সবচেয়ে ভাল জানেন যে বিশ্বাসের উপর পড়ে না।
  • সৎ হও. আপনি পাশাপাশি চলার সাথে সাথে পুনরায় ফ্যাক্টর করুন তবে মিথ্যা কথা বলবেন না এবং আপনার নিজের উদ্দেশ্যে প্যাডের অনুমান করুন।
  • আপনি কোডটির মালিক নন। নেতৃত্বের দ্বারা অনুমোদিত নয় এমন কাজ করবেন না।
  • আপনি কিছু সম্পর্কে সঠিক হতে পারে; আপনি ভুল হতে পারে ... তবে আপনার যা করা উচিত তা আপনার করা উচিত।

তবে অবশ্যই জিনিসগুলির উন্নতি করার জন্য দেওয়া দুর্দান্ত পরামর্শ অনুসরণ করুন।


হ্যাঁ, আপনি যদি একটি কোড-বানর হতে চান তবে এগিয়ে যান এবং আপনি যা বলে "মনে করেন" তা করুন। প্রোগ্রামিং সম্পর্কে যা কিছু রয়েছে তা অবলম্বন করার জন্য ধন্যবাদ।
জোড়ান পাভলভিক

2

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

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

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

পিএইচবি জানে যে 6 মাসের মধ্যে, হুক বা কুটিল দ্বারা, তিনি সেই অ্যাপ্লিকেশনটিতে ত্রিশ বা চল্লিশটি নতুন বৈশিষ্ট্য পেতে পারেন যে বিক্রয়কর্মীরা (যারা অবশ্যই যাদুকর হতে হবে তারা আসলে যা বিক্রি করছে তা দিয়ে) নতুন ক্রয় এবং আপগ্রেডকে প্রলুব্ধ করতে ব্যবহৃত হতে পারে ।

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

যে উপসংহারে আমি পৌঁছেছি তা হ'ল পাগল থেকে বেরিয়ে আসার একমাত্র উপায় হল একটি নতুন স্টার্ট আপে কাজ করা, কয়েকজন লোক যারা আপনার সফ্টওয়্যারটি কীভাবে করা উচিত সে সম্পর্কে আপনার দৃষ্টিভঙ্গি ভাগ করে এবং তারপরে কৌতুকপূর্ণভাবে সেই দর্শনে আটকে থাকে (I এখনও সেখানে যাওয়ার বিষয়ে কাজ করছি!)


1

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


1

আপনি উভয়ই সঠিক এবং উভয়ই ভুল, এই কারণেই এই সমস্যাগুলি দীর্ঘ সময় ধরে থাকে এবং কঠোর অনুভূতি তৈরি করে।

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

আপনার দৃষ্টিও সঠিক: গ্রাহকদের পক্ষে তবে এটি দীর্ঘ মেয়াদে ভাল। আপনার ক্রিয়াকলাপগুলি স্বল্পমেয়াদী পরিকল্পনার তুলনায় ভবিষ্যতে আরও বেশি আয় করতে পারে।

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

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

আপনি এই সমস্যাটি কীভাবে সমাধান করবেন? আপনি বেশ কয়েকটি ইস্যুতে একে অপরকে যথেষ্ট ভালভাবে যোগাযোগ এবং বুঝতে পারেন। এটি সম্ভবত গ্রাহকের ব্যস্ততা এবং সন্তুষ্টির উপর ফোকাস হবে।

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

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

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

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


0

আপনার যদি একটি কোড পর্যালোচনা থাকে তবে একটি প্রযুক্তিগত টিকিট তৈরি করুন যাতে এআরসি ব্যবহার করে কোডটি উন্নত করা উচিত এবং ম্যানেজারকে বরাদ্দ করুন।

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


0

পরিচালনাগুলি যেভাবে কিনতে রাজি সেগুলি আপনাকে এই পরিবর্তনগুলি বিক্রি করতে হবে:

এমন কোনও ব্যবহারকারী-মুখোমুখি বৈশিষ্ট্যটি সন্ধান করুন যাতে মজবুত ব্যবস্থাপনার কেবল এটি থাকা দরকার তবে কোডটিতে কিছু নিম্ন-স্তরের উন্নতি না করে করা অসম্ভব।


0

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

  1. ক্লায়েন্টের অনুরোধটি সরবরাহ করতে কতক্ষণ সময় লাগে?
  2. আপনি যখন বলবেন আপনি কি সরবরাহ করবেন?

আপনি বরং বলবেন যে এটি 3 সপ্তাহে লাগবে এবং 5 এ বিতরণ করবে বলে আপনি 3 এ বিতরণ করবেন তবে 4 নিবেন।

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


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

0

আমি আপনাকে 2 বিলিয়ন ডলার সুযোগ সম্পর্কে বলি যা প্রায়োগিক জড়তার কারণে আমাদের হাতের মধ্যে পড়ে যায়।

আমাদের কারও কারও কাছে গ্রাহকের ভয়েস শোনার একটি বিন্দু রয়েছে, যার অর্থ তিনি কী চান তা বোঝা। তিনি সর্বদা যা চান তা এটি নয়, তবে আপনি যদি আপনার গ্রাহকের সাথে কথোপকথনের মতো অবস্থানে থাকেন তবে অবশেষে তিনি কী চান তা নিয়ে আপনি একটি পারস্পরিক বোঝাপড়া করতে পারেন। (তারপরে তিনি স্পষ্টভাবে এর জন্য জিজ্ঞাসা শুরু করতে পারেন))

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

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

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

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

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

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

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


0

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

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


0

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

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

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

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

শুভকামনা!


-1

স্বয়ংক্রিয় রেফারেন্স গণনার জন্য আপনার অনুরোধটি কেন প্রত্যাখ্যান করা হচ্ছে তা এখানে:

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

সমস্যাটি পরিচালনা করতে আপনি কয়েকটি পদক্ষেপ ব্যবহার করতে পারেন:

  1. বৈশিষ্ট্যটি ড্রপ করুন
  2. আসল সমস্যাটি কী তা সন্ধান করুন
  3. দরকারী কিছু করা শুরু করুন
  4. আপনি আপনার সময় কীভাবে ব্যবহার করবেন তা যত্ন সহকারে পরিকল্পনা করুন
  5. কীভাবে আপনার উন্নতিগুলি অর্থ আনে তা সন্ধান করুন
  6. কেবলমাত্র এমন বৈশিষ্ট্যগুলি বেছে নিন যা বেশিরভাগ অর্থ উপার্জন করে
  7. উপলব্ধি করুন যে সফ্টওয়্যার বিকাশের প্রোগ্রামিং দিকটি পুরো সিস্টেমের কেবলমাত্র একটি ছোট অংশ - এর উন্নতিগুলি কখনই মূল্যবান হতে পারে না
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.