স্টার্টআপের জন্য ডিসিশন লগ
স্টার্টআপে প্রতি সপ্তাহে শত শত সিদ্ধান্ত নেওয়া হয়। বেশিরভাগই Slack থ্রেড আর ভুলে যাওয়া মিটিংয়ে হারিয়ে যায়। এখানে দেখো কীভাবে এমন একটি ডিসিশন লগ বানাবে যা সত্যিই টিকে থাকে।
By Ellis Keane · 2026-03-16
১৯৮৬ সালে স্পেস শাটল Challenger উৎক্ষেপণের ৭৩ সেকেন্ড পর ভেঙে পড়ে। পরবর্তী তদন্তে দেখা যায়, আগের রাতে Morton Thiokol-এর ইঞ্জিনিয়াররা O-ring seal নিয়ে উদ্বেগ তুলেছিল, তাদের যুক্তি ছিল ঠান্ডা আবহাওয়ায় লঞ্চ নিরাপদ নয়। ম্যানেজমেন্ট তাদের কথা উড়িয়ে দেয়। সিদ্ধান্তটা নেওয়া হয়েছিল একটা টেলিকনফারেন্সে, আর চার্ট ও সাক্ষ্য থাকলেও override-এর পেছনের গুরুত্বপূর্ণ যুক্তিগুলো অংশগ্রহণকারীদের মধ্যে ছড়িয়ে ছিল এবং নির্ভরযোগ্যভাবে উপরের স্তরে পৌঁছায়নি।
আমি তোমার স্টার্টআপের প্রোডাক্ট সিদ্ধান্তকে শাটল দুর্ঘটনার সাথে তুলনা করছি না (আচ্ছা, বেশিরভাগটাকে না)। কিন্তু ভেতরের failure mode একই, যেটা আমি প্রতি সপ্তাহে স্টার্টআপে দেখি, শুধু stakes কম: একটা সিদ্ধান্ত নেওয়া হয়, তার পেছনের যুক্তি কারও মাথায় থাকে বা এমন একটা Slack থ্রেডে থাকে যা একটু পরেই স্ক্রিন থেকে সরে যাবে, আর তিন মাস পর কেউই বের করতে পারে না কেন আমরা approach A না নিয়ে approach B নিয়েছিলাম। সিদ্ধান্তটা ভুল ছিল বলে না – অনেক সময় সেটা দারুণ ছিল – বরং যে কনটেক্সট সেটাকে সঠিক করেছিল, সেটা উবে গেছে।
"একটা সিদ্ধান্ত নেওয়া হয়, তার পেছনের যুক্তি কারও মাথায় থাকে বা এমন একটা Slack থ্রেডে থাকে যা একটু পরেই স্ক্রিন থেকে সরে যাবে, আর তিন মাস পর কেউই বের করতে পারে না কেন আমরা approach A না নিয়ে approach B নিয়েছিলাম।" – Ellis Keane
স্টার্টআপের জন্য ডিসিশন লগ কোনো আমলাতান্ত্রিক কাজ না। এটা হলো "আমরা সেটা ট্রাই করেছিলাম, কাজ হয়নি" (উপকারী) আর "মনে হয় এটা নিয়ে একবার কথা হয়েছিল?" (অকার্যকর) – এই দুইয়ের পার্থক্য।
হারিয়ে যাওয়া সিদ্ধান্তের অ্যানাটমি
একটা নির্দিষ্ট সিদ্ধান্তকে তার পুরো lifecycle ধরে ট্রেস করি, কারণ এই সমস্যার abstract ভার্সনের চেয়ে concrete ভার্সন বেশি বিশ্বাসযোগ্য।
ফেব্রুয়ারির এক মঙ্গলবার। তোমার head of engineering আর PM একটা Slack থ্রেডে তর্ক করছে – custom notification system বানাবে, নাকি third-party service ব্যবহার করবে। থ্রেড ৪৭টা মেসেজে গড়ায় (জানি, কিন্তু এভাবেই হয়), আর ৩৮ নম্বর মেসেজে তারা third-party option-এ সিদ্ধান্ত নেয়, কারণ custom build করতে তিনটা sprint লাগবে আর launch deadline দুই sprint পরে।
PM একটা Linear issue তৈরি করে: "Notifications-এর জন্য [Service X] ইন্টিগ্রেশন।" একজন engineer সেটা তুলে নিয়ে কাজ শুরু করে। Slack থ্রেডটা টেকনিক্যালি আছে, কিন্তু কেউ সেটা bookmark করে না বা Linear issue থেকে লিংক করে না।
মে মাসে ফাস্ট-ফরওয়ার্ড করো। Third-party service-এর reliability সমস্যা দেখা দেয়। কেউ জিজ্ঞেস করে: "আমরা এটা নিজেরা বানালাম না কেন?" PM কথোপকথনটা মনে করতে পারে, কিন্তু ডিটেইলস না। Head of engineering parental leave-এ। Slack থ্রেডটা ফেব্রুয়ারির #engineering চ্যানেলে কোথাও আছে, কিন্তু নির্দিষ্ট তারিখ কারও মনে নেই, আর Slack search-এ "notification" দিলে ২০০টা result আসে (কারণ, স্বাভাবিকভাবেই, সব টিমই notifications নিয়ে সবসময় কথা বলে)।
টিম ৪৫ মিনিটের একটা মিটিংয়ে আসল যুক্তি reconstruct করে। শেষে একই সিদ্ধান্তেই আসে – timeline constraint তখনও প্রযোজ্য ছিল – কিন্তু ৪৫ মিনিট চলে গেছে, আর সন্দেহটা থেকে যায়। এটাকে একটা স্টার্টআপ প্রতি মাসে যত ডজন সিদ্ধান্ত নেয় তার সাথে গুণ করো, আর দেখবে আগেই ভেবেচিন্তে নেওয়া সিদ্ধান্ত নিয়ে বারবার তর্ক করতে উল্লেখযোগ্য সময় চলে যাচ্ছে।
স্টার্টআপে এটা বিশেষভাবে খারাপ কেন
বড় কোম্পানিগুলো (তাদের অসংখ্য ত্রুটি সত্ত্বেও) সাধারণত process-এর মধ্যে institutional memory ধরে রাখে: architecture decision record, RFC, formal review cycle-এ যাওয়া design doc। সিদ্ধান্তগুলো হয়তো Confluence-এ পুঁতে থাকে, কিন্তু অন্তত কোথাও লেখা আছে যেখান থেকে খুঁজে পাওয়া যায়।
স্টার্টআপে ওই infrastructure থাকে না, আর সেটা বানানোটাই মনে হয় সেই ধরনের overhead যেটা ছোট আর দ্রুত দলে এড়িয়ে চলাই উচিত। "আমরা মনে রাখব" – ৪ জনের টিমে এই যুক্তি কাজ করে, আর করেও – যতক্ষণ না ৫ নম্বর মানুষ জয়েন করে, যার কাছে কিছু কেন এমন, সেই কনটেক্সটই নেই।
আরেকটা জিনিস যেটা স্টার্টআপে সিদ্ধান্ত ট্র্যাকিংকে বিশেষভাবে কঠিন করে সেটা হলো tool fragmentation। সিদ্ধান্ত সর্বত্র হয়: Slack thread, Zoom call, Notion comment, Linear discussion, GitHub PR review, আর (ক্রমবর্ধমানভাবে) DM-এ যেটা কখনো shared channel-এ আসে না। প্রতিটা টুল সিদ্ধান্তের একটা অংশ ধরে, কিন্তু কোনোটাই পুরোটা ধরে না, আর তাদের মধ্যকার লিংক মানুষের স্মৃতির ওপর নির্ভর করে, যেটা (ভালোবেসেই বলি) আমাদের সবার হাতে থাকা সবচেয়ে কম নির্ভরযোগ্য database।
ডিসিশন লগে আসলে কী দরকার
এটা নিয়ে over-engineer করার প্রলোভন থাকে। আমি টিমকে Notion-এ প্রতি entry-তে ১৫টা property দিয়ে বিশাল database বানাতে দেখেছি – decision type, impact level, review status, stakeholder, related OKR – তারপর কখনো ব্যবহার করেনি, কারণ প্রতিটা সিদ্ধান্তে এত ফিল্ড পূরণের overhead perceived value-এর চেয়ে বেশি।
স্টার্টআপের জন্য ডিসিশন লগ এত হালকা হতে হবে যাতে মানুষ সত্যিই ব্যবহার করে। যা দরকার:
সিদ্ধান্তটা কী। এক বাক্য। "Custom বানানোর বদলে আমরা notifications-এর জন্য Service X ব্যবহার করছি।" অনুচ্ছেদ না – এক বাক্য।
কে নিয়েছে, আর কখন। নাম আর তারিখ। এটা শুনতে obvious লাগে কিন্তু ছয় মাস পরে যখন কেউ সিদ্ধান্ত নিয়ে প্রশ্ন তোলে, তখন এই অংশটাই সবচেয়ে গুরুত্বপূর্ণ। এটা দোষ ধরার জন্য না (আচ্ছা, বেশিরভাগ সময় না) – এটা জানার জন্য যে আসল যুক্তি জানতে কাকে জিজ্ঞেস করতে হবে।
কী কী বিকল্প বিবেচনা করা হয়েছিল। দুই বা তিনটা bullet point। "Custom build বিবেচনা করা হয়েছিল (৩ sprint estimate, deadline খুব টাইট)" আর "Service Y বিবেচনা করা হয়েছিল (১০K user-এর পর pricing scale করেনি)।" এই অংশটাই re-litigation ঠেকায় – বিকল্প আর তাদের trade-off ডকুমেন্ট করা থাকলে টিমকে আবার নতুন করে আবিষ্কার করতে হয় না।
আলোচনা কোথায় হয়েছে। Slack thread, Linear issue, Notion comment – যেখানে আসল debate হয়েছে তার একটা লিংক। এটা সবচেয়ে underrated field। এটা ছাড়া log entry শুধু প্রমাণহীন দাবি। এটা থাকলে যে কেউ পুরো context পেতে মূল কথোপকথনে গিয়ে পড়তে পারে।
কী হলে সিদ্ধান্ত বদলাবে। এটা optional, কিন্তু context দ্রুত বদলায় এমন স্টার্টআপে অসম্ভব কাজের। "Launch deadline ৪ সপ্তাহের বেশি সরলে আমরা এটা revisit করব" বা "ধরা হয়েছে মাসে ১০K notifications-এর নিচে থাকব।" এটা একটা static record-কে living record-এ পরিণত করে।
স্টার্টআপের জন্য সেরা ডিসিশন লগ হলো যেটা তোমার টিম সত্যিই পূরণ করে। পাঁচটা field, প্রতিটা এক বাক্য। একটা সিদ্ধান্ত লগ করতে ৯০ সেকেন্ডের বেশি লাগলে সিস্টেমটা এক মাসের মধ্যে মারা যাবে।
এটা কোথায় রাখবে
আমি টিমকে তিনটা approach নিতে দেখেছি, আর তিনটারই trade-off আছে।
Notion database। এটা সবচেয়ে common আর মোটামুটি ভালো কাজ করে। ওপরের পাঁচটা field দিয়ে database বানাও, দ্রুত পূরণের জন্য template যোগ করো, আর প্রতিটা entry-কে relevant project page-এর সাথে লিংক করো। Downside: Notion-এ specs থাকে, সিদ্ধান্ত হয় না, তাই সিদ্ধান্ত অন্য কোথাও হওয়ার পর কাউকে Notion-এ গিয়ে লিখতে হয়। ওই "পরের" ধাপটাতেই dropout হয়।
Slack-এ inline। কিছু টিম dedicated #decisions channel ব্যবহার করে আর প্রতিটা সিদ্ধান্তের জন্য formatted message পোস্ট করে। Friction কম (সিদ্ধান্ত হয়তো Slack-এই হয়েছে), কিন্তু project বা date range ধরে সিদ্ধান্ত খুঁজতে Slack-এর search দুর্বল, আর structured field না থাকায় consistency সময়ের সাথে কমে যায়।
Linear-এ inline। সিদ্ধান্ত যদি নির্দিষ্ট workstream-এর সাথে সম্পর্কিত হয়, relevant Linear issue-তে comment হিসেবে রাখলে সিদ্ধান্ত কাজের কাছাকাছি থাকে। Downside হলো একাধিক issue বা project জুড়ে সিদ্ধান্তের কোনো natural home থাকে না।
সত্যি বলতে, এগুলোর কোনোটাই দারুণ না। মূল সমস্যা হলো সিদ্ধান্ত হয় একাধিক টুলে, কিন্তু লগ থাকে একটা টুলে, তাই gap পেরোতে সবসময় একটা manual step লাগে। আমার দেখা প্রতিটা ডিসিশন লগে এই manual step-ই single point of failure।
Sugarbug-এ আমরা কী বানাচ্ছি
Sugarbug-এ আমাদের approach হলো কাউকে manually log করতে বলার বদলে, টুলজুড়ে সিদ্ধান্ত হওয়ার সময়ই সেটাকে detect করা। This is the bridge between a startup decision log and cross-tool awareness for engineering leaders: decisions need to be findable wherever they happened, which is exactly what the cross-tool decision trail from Slack through Linear to GitHub provides.
যখন একটা Slack থ্রেড একটা সিদ্ধান্তে পৌঁছায় ("OK, চলো Service X নিয়ে যাই"), যখন Linear issue discussion resolve হয়, যখন GitHub PR review approval দিয়ে শেষ হয় – এগুলো সবই সিগন্যাল যে একটা সিদ্ধান্ত নেওয়া হয়েছে। Sugarbug এই সিগন্যালগুলো ingest করে, classify করে, আর নলেজ গ্রাফে relevant task ও মানুষের সাথে লিংক করে। "Decision log" আলাদা কোনো database না যেটা কাউকে maintain করতে হয় – এটা তোমার existing tool-এ আগে থেকেই এমবেড করা সিদ্ধান্তগুলোর উপর একটা view।
আমরা এখনো classification accuracy নিয়ে কাজ করছি ("সিদ্ধান্ত" আর "স্রেফ কথোপকথন" আলাদা করা শুনতে যত সহজ, বাস্তবে তত না), কিন্তু directional bet হলো source-এই সিদ্ধান্ত capture করা – যেখানে সেটা বাস্তবে হয় – মানুষকে আলাদা সিস্টেমে duplicate করতে বলার চেয়ে বেশি নির্ভরযোগ্য।
এটা তোমার কাজে লাগলে sugarbug.ai-তে আরও ডিটেইল পাবে। তবে উপরের manual system বেশিরভাগ স্টার্টআপে ভালো কাজ করবে, যতক্ষণ না টিম এত বড় হয় যে manual logging-এর dropout rate আসল সমস্যা হয়ে দাঁড়ায় – আমাদের অভিজ্ঞতায় সাধারণত ৮–১২ জনের আশেপাশে।
Slack scroll-এ সিদ্ধান্ত হারিয়ে ফেলা বন্ধ করো। Sugarbug যেখানে সিদ্ধান্ত সত্যিই হয়, সেই টুল থেকে স্বয়ংক্রিয়ভাবে ধরে রাখে।
Q: একটা স্টার্টআপ ডিসিশন লগে কী কী থাকা উচিত? A: কমপক্ষে: সিদ্ধান্তটা কী (এক বাক্য), কে নিয়েছে, কখন, কী কী বিকল্প বিবেচনা করা হয়েছিল, আর আলোচনা কোথায় হয়েছে। শেষের field-টাই সবচেয়ে গুরুত্বপূর্ণ – মূল কথোপকথনের লিংক না থাকলে লগটা প্রমাণহীন দাবি হয়ে যায়, আর ছয় মাস পরে কেউ প্রশ্ন তুললে আবার স্মৃতি থেকে reconstruct করতে হয়।
Q: Sugarbug কি বিদ্যমান টুল থেকে স্বয়ংক্রিয়ভাবে ডিসিশন লগ বানায়? A: আমরা ওই দিকেই এগোচ্ছি। Sugarbug Slack, Linear, GitHub, Notion আর অন্যান্য টুল থেকে সিগন্যাল ingest করে, সেগুলোকে নলেজ গ্রাফে classify করে। যখন এটা কোনো সিদ্ধান্ত শনাক্ত করে – approved PR, resolved Linear discussion, বা পরিষ্কার next step দিয়ে শেষ হওয়া Slack thread – তখন সেটাকে relevant task আর মানুষের সাথে স্বয়ংক্রিয়ভাবে লিংক করে। আমরা এখনো classification refine করছি ("সিদ্ধান্ত" আর "কথোপকথন" আলাদা করা সত্যিই কঠিন), তবে সিগন্যাল ingestion আর linking কাজ করছে।
Q: স্টার্টআপে কত ঘন ঘন ডিসিশন লগ আপডেট করা উচিত? A: আদর্শভাবে, সিদ্ধান্ত নেওয়ার সাথে সাথেই লগ করা উচিত, সাপ্তাহিক ব্যাচে নয়। শুক্রবারে এসে মঙ্গলবারের সিদ্ধান্তের যুক্তিই ঝাপসা হয়ে যায়, আর "বিবেচিত বিকল্প" field-টা সঠিকভাবে পূরণ হওয়ার সম্ভাবনা দ্রুত কমে। Manual logging করলে সিদ্ধান্তের ঠিক পরেই ৯০ সেকেন্ডের অভ্যাস বানাও। Sugarbug-এর মতো টুল ব্যবহার করলে লক্ষ্য হলো যেখানে সিদ্ধান্ত বাস্তবে হয়, সেই টুল থেকে real-time capture।
Q: Sugarbug কি Slack, Linear, আর GitHub জুড়ে সিদ্ধান্ত ট্র্যাক করতে পারে? A: Sugarbug তিনটার সাথেই (এবং Notion ও Figma-র সাথেও) কানেক্ট করে এবং কথোপকথন, টাস্ক, আর কোড পরিবর্তনের সম্পর্কের একটা নলেজ গ্রাফ ধরে রাখে। Slack thread-এ সিদ্ধান্ত ওঠে, Linear issue-তে যায়, তারপর GitHub PR তৈরি হলে Sugarbug পুরো chain লিংক করে দেয় – যাতে origin থেকে implementation পর্যন্ত ট্রেস করতে পারো, কাউকে manually link বানাতে না হয়।
Q: ডিসিশন লগ আর architecture decision record (ADR)-এর মধ্যে পার্থক্য কী? A: ADR সাধারণত বড় technical choice-এর জন্য formal document – "MongoDB-র বদলে PostgreSQL ব্যবহার করছি" – যেখানে context, decision, আর consequences-এর structured section থাকে। স্টার্টআপের ডিসিশন লগ বেশি broad আর lightweight: এটা দৈনন্দিন operational সিদ্ধান্ত ধরে (কোন vendor, কোন deadline, কোন feature কাটবে) যেগুলো ADR-এর জন্য খুব ছোট মনে হয়। দুটোই মূল্যবান; ডিসিশন লগ ওই ৯৫% সিদ্ধান্ত কভার করে যেগুলোর formal ADR দরকার পড়ে না, কিন্তু traceable থাকা দরকার।