একটি software company গড়ার অভিজ্ঞতা software-কে দেখার দৃষ্টিভঙ্গি বদলে দেয়।

Developer হিসেবে আমি দেখতে পারি feature কাজ করছে কি না। SoftWebGrove-এর founder হিসেবে আমাকে আরও দেখতে হয়—এটি সঠিক সমস্যা সমাধান করছে কি না, client এটি চালাতে পারবেন কি না, team support করতে পারবে কি না এবং feature ঘিরে দেওয়া promise সৎ কি না।

এই বড় দায়িত্ব আমার কাজের ধরন তৈরি করেছে।

এগুলো সবার জন্য absolute rule নয়। Client work, product scope এবং দীর্ঘমেয়াদি ownership নিয়ে সিদ্ধান্তে আমি যে lesson ব্যবহার করি, সেগুলোই এখানে লিখছি।

Trust-ও deliverable-এর অংশ

Technically correct release-ও trust নষ্ট করতে পারে।

এটা ঘটে যখন:

• delay-এর কথা client অনেক দেরিতে জানেন;
• limitation launch-এর পর প্রথম প্রকাশ পায়;
• estimate-এর গুরুত্বপূর্ণ assumption লুকানো থাকে;
• handover-এ একজনই সব knowledge-এর source হয়ে থাকেন;
• error investigate না করে vague ভাষায় বলা হয়;
• recovery path ছাড়া change release হয়।

Project-এর বাস্তব অবস্থা visible রাখলে trust তৈরি হয়। Deadline পর্যন্ত অবাস্তব promise ধরে রাখার চেয়ে কঠিন constraint শুরুতেই বোঝানো আমার কাছে ভালো।

এই কারণেই আমার async client communication system-এ decision, progress, risk এবং question আলাদা থাকে।

Request মানেই requirement নয়

Client সাধারণত তাঁর জানা ভাষায় desired feature ব্যাখ্যা করেন। প্রথম request underlying need না হয়ে একটি সম্ভাব্য solution হতে পারে।

“Export button দিন” বলতে বোঝাতে পারে:

• finance team-এর monthly reconciliation file দরকার;
• manager-এর printable summary দরকার;
• অন্য system-এর structured data দরকার;
• customer-এর transaction proof দরকার।

এগুলো এক সমস্যা নয়।

Estimate-এর আগে আমি জানতে চাই result কে ব্যবহার করবেন, কোন decision-এ এটি কাজে লাগবে, কোন data লাগবে, কোন data বাদ যাবে এবং action-এর পরে কী হবে।

Client-কে অকারণে challenge করা লক্ষ্য নয়। লক্ষ্য হলো আত্মবিশ্বাসের সঙ্গে ভুল জিনিস build না করা।

Ownership-এর নাম থাকতে হবে

সবাই যখন ধরে নেন অন্য কেউ দায়িত্বে আছেন, তখন project fragile হয়।

গুরুত্বপূর্ণ area-তে আমি স্পষ্ট উত্তর চাই:

• workflow কে approve করবেন?
• production account কার ownership-এ?
• secret কে rotate করতে পারবেন?
• failure alert কে পাবেন?
• incident-এ rollback লাগবে কি না কে সিদ্ধান্ত নেবেন?
• handover-এর পর content কে maintain করবেন?
• billable scope change কে authorize করবেন?

এর জন্য বড় team দরকার নেই। Small project-এও role পরিষ্কার হতে পারে, একজন একাধিক role নিলেও।

Small system-এরও real boundary আছে

Startup ছোট হতে পারে, তার data কাল্পনিক নয়।

Authentication, authorization, tenant isolation, backup, auditability এবং input validation customer জিজ্ঞেস করার পর প্রথম ভাবার বিষয় নয়। Implementation product অনুযায়ী ছোট হতে পারে, কিন্তু boundary deliberate হতে হবে।

Secure multi-tenant SaaS foundation এবং growth সহ্য করতে পারে এমন API contract পরিকল্পনায় আমি এই নীতি ব্যবহার করি।

“আমরা এখনো early stage-এ” ছোট solution justify করতে পারে। Unknown solution নয়।

Scope হলো decision system

ভালো scope শুধু page list নয়।

এটি যুক্ত করে:

1. business outcome;
2. যে user-এর এটি প্রয়োজন;
3. value তৈরি করা core path;
4. path-এর data ও permission;
5. acceptance evidence;
6. exclusion;
7. release ও recovery plan।

এগুলো না থাকলে team assumption দিয়ে gap পূরণ করে। প্রতিটি assumption rework-এর ঝুঁকি বাড়ায়।

Practical process-এর জন্য পড়ুন requirement থেকে shippable scope।

“Done”-এর মধ্যে operation আছে

Code complete হওয়া delivery-এর একটি event।

Relevant মানুষগুলো নিচের প্রশ্নের উত্তর না জানা পর্যন্ত feature operationally complete নয়:

• কীভাবে configure হবে?
• success কীভাবে observe হবে?
• failure-এ user কী দেখবেন?
• support team-এর কী জানা দরকার?
• access কীভাবে revoke হবে?
• data কীভাবে recover হবে?
• launch-এর পর কীভাবে safe change হবে?

তাই documentation, validation, observability এবং handover side task নয়। এগুলো original implementation session শেষ হওয়ার পরও product চালু থাকার সক্ষমতার অংশ।

“না” বলা product-কে রক্ষা করতে পারে

কিছু idea technically possible হলেও বর্তমান release-এর জন্য strategic নয়।

আমি feature delay করার পরামর্শ দিতে পারি যদি:

• clear user বা outcome না থাকে;
• team নিতে পারবে না এমন security obligation তৈরি হয়;
• existing path duplicate করে;
• demand evidence ছাড়া ongoing provider cost যোগ করে;
• stability problem-এর সময় release surface বাড়ায়;
• product reliably collect করে না এমন data প্রয়োজন হয়।

Responsible “এখন নয়”-এর সঙ্গে reasoning এবং safer next step থাকা উচিত। কখন আমি feature-কে না বলি-তে approach-টি ব্যাখ্যা করেছি।

Reputation ordinary decision-এ তৈরি হয়

Personal এবং company reputation শুধু polished launch থেকে আসে না।

এটি জমে ছোট ছোট কাজে:

• clear estimate;
• disclosed risk;
• protected credential;
• tested recovery path;
• respectful disagreement;
• useful handover;
• honest incident update;
• guarantee করা যায় না এমন ranking, revenue বা deadline promise না করার সিদ্ধান্ত।

এই decision homepage-এর চেয়ে কম visible, কিন্তু client আবার কাজ করতে চাইবেন কি না তা এগুলোই ঠিক করে।

যে standard ধরে রাখতে চাই

SoftWebGrove-এ আমি চাই কাজ impressive হওয়ার আগে understandable হোক।

এর মানে business problem বোঝা, boundary visible রাখা, uncertainty communicate করা এবং client-কে এমন system দেওয়া যা তিনি সত্যিই operate করতে পারেন।

Technology বদলাবে। এই standard বদলানো উচিত নয়।

আপনি product plan করছেন এবং build-এর আগে কাজ পরিষ্কার করতে সাহায্য করবে এমন technical partner চান, তাহলে business-এর কী অর্জন করা দরকার তা জানান।