অ্যাসিঙ্ক-ফার্স্ট ইঞ্জিনিয়ারিং টিম পরিচালনার গাইড
অ্যাসিঙ্ক-ফার্স্ট ইঞ্জিনিয়ারিং টিম পরিচালনার ব্যবহারিক প্লেবুক – যোগাযোগের নিয়ম থেকে কার্যকর সিদ্ধান্ত গ্রহণের অভ্যাস পর্যন্ত।
By Ellis Keane · 2026-04-06
যখন টেলিগ্রাফ দৈনিক ব্রিফিং বন্ধ করে দিল
১৮৪৪ সালে স্যামুয়েল মোর্স ওয়াশিংটন ও বাল্টিমোরের মধ্যে প্রথম টেলিগ্রাফ বার্তা পাঠান, এবং এক দশকের মধ্যে যেসব ব্যবসায় দৈনিক কুরিয়ার ব্রিফিংয়ের উপর নির্ভর করত তারা ভিন্নভাবে কাজ করতে শুরু করে। কারণ তারা "টেলিগ্রাফ-ফার্স্ট" হতে চেয়েছিল তা নয় (কেউ এভাবে বলেনি), বরং সীমাবদ্ধতাটি পরিবর্তিত হয়ে গিয়েছিল। তথ্য ঘোড়ার চেয়ে দ্রুত যেতে পারত, তাই ঘোড়াকে কেন্দ্র করে গড়ে ওঠা অনুষ্ঠানগুলো নিরবে অপ্রয়োজনীয় হয়ে পড়ল।
অ্যাসিঙ্ক-ফার্স্ট ইঞ্জিনিয়ারিং টিম পরিচালনার সাথে এই সাদৃশ্য অস্বস্তিকরভাবে সরাসরি। আমাদের কাছে Slack, Linear, GitHub, Notion এবং আরও প্রায় সাতটি টুল আছে যা ওয়েবহুকের গতিতে তথ্য পাঠায়, তবুও বেশিরভাগ টিম এখনও তাদের দিনগুলো সিঙ্ক্রোনাস অনুষ্ঠানকে কেন্দ্র করে সংগঠিত করে – যে অনুষ্ঠানগুলো ডিজাইন করা হয়েছিল যখন প্রেক্ষাপট ভাগ করতে একই ঘরে থাকতে হত – প্রতিদিনের স্ট্যান্ডআপ যেখানে প্রত্যেকে তাদের Jira টিকেট ম্যানেজারকে পাঠ করে দেয়, যার দ্বিতীয় মনিটরে একই বোর্ড ইতিমধ্যে খোলা আছে, এবং "কুইক সিঙ্ক" যা ৪৫ মিনিট চলে কারণ তিনজন মানুষ পর্যায়ক্রমে স্ক্রিন শেয়ার করছেন আর বাকিরা ফোন চেক করছেন।
আমাদের মতো একটি ছোট ইঞ্জিনিয়ারিং টিমের জন্য – তিনটি টাইম জোনে চার জন মানুষ – এটা উপলব্ধি করা সহজ ছিল যে সীমাবদ্ধতা পরিবর্তিত হয়েছে। অনুষ্ঠানগুলো পুনর্নির্মাণ করতে বেশি সময় লেগেছিল।
একটি অ্যাসিঙ্ক-ফার্স্ট ইঞ্জিনিয়ারিং টিম আসলে কেমন দেখায়
অ্যাসিঙ্ক-ফার্স্ট ইঞ্জিনিয়ারিং মানে আপনার টিমের ডিফল্ট যোগাযোগ মোড হল অ্যাসিঙ্ক্রোনাস। সিদ্ধান্তগুলো লেখা হয়। স্ট্যাটাস না জিজ্ঞেস করেই দেখা যায়। প্রেক্ষাপট এমন জায়গায় নথিভুক্ত থাকে যেখানে মানুষ নিজের সময়সূচিতে খুঁজে পেতে পারে। মিটিং এখনও হয়, কিন্তু সেগুলো ব্যতিক্রম যা আপনি বেছে নেন, ডিফল্ট নয় যা থেকে আপনাকে বের হতে হবে।
এর মানে এই নয় যে কেউ কখনও রিয়েল টাইমে কথা বলে না – ডিজাইন রিভিউ, দ্বন্দ্ব সমাধান, ব্রেইনস্টর্মিং সেশন, এবং যে ধরনের জটিল আর্কিটেকচারাল আলোচনায় বডি ল্যাঙ্গুয়েজ পড়তে এবং হোয়াইটবোর্ডে আঁকতে হয় সেগুলো এখনও সিঙ্ক্রোনাস থাকে, এবং এটা ঠিকই আছে। পার্থক্য হল আপনি কোনো কিছু যোগাযোগ করতে চাইলে কোন মোডটি প্রথমে বেছে নেন, এবং ইঞ্জিনিয়ারিং টিমের বেশিরভাগ ক্ষেত্রে, উত্তর হওয়া উচিত লিখে রাখা, কারণ ব্রুকলিনে বিকেল ২টায় লেখা একটি সুলিখিত Linear মন্তব্য পরের দিন সকাল ৯টায় বার্লিনে এখনও পুরোপুরি পাঠযোগ্য।
অ্যাসিঙ্ক-ফার্স্ট মানে শুধু অ্যাসিঙ্ক নয়। এর মানে আপনার ডিফল্ট হল অ্যাসিঙ্ক্রোনাস, এবং যখন পরিস্থিতি সত্যিকার অর্থে দাবি করে তখন আপনি সচেতনভাবে সিঙ্ক্রোনাস যোগাযোগ বেছে নেন।
চারটি স্তম্ভ (যা চেষ্টা না করা পর্যন্ত স্পষ্ট মনে হয়)
গত এক বছর ধরে, আমরা মার্কিন পূর্ব উপকূল এবং ইউরোপ জুড়ে চার সদস্যের দল নিয়ে Sugarbug তৈরি করছি, এবং যে জিনিসগুলো আসলে আমাদের অ্যাসিঙ্ক-ফার্স্ট ইঞ্জিনিয়ারিং টিমকে কাজ করিয়েছে সেগুলো টুল বা নীতিমালা ছিল না – সেগুলো ছিল অভ্যাস। এখানে চারটি অভ্যাস যা টিকে গেছে।
১. সিদ্ধান্তগুলো যেখানে হয়েছে সেখানে লিখে রাখুন
প্রায় কেউই এটা ধারাবাহিকভাবে করে না। একটি Slack থ্রেডে সিদ্ধান্ত নেওয়া হয়। কেউ বলে "ঠিক আছে অপশন B নিয়ে এগোই।" এবং তারপর... এটা সেখানে থেকে যায়। একটি থ্রেডে যা তিন সপ্তাহ পরে কার্যত খুঁজে পাওয়া যাবে না।
সমাধান একটি সিদ্ধান্ত-লগ নয় (বরং সেটা মূল বিষয় নয়)। সমাধান হল একটি নিয়ম: যে ব্যক্তি চূড়ান্ত সিদ্ধান্ত নেয়, সে কাজ যেখানে হয় সেই টুলে কী সিদ্ধান্ত নেওয়া হয়েছে এবং কেন তার একটি এক-বাক্যের সারসংক্ষেপ লেখে। যদি আপনি API রেসপন্স ফরম্যাট পরিবর্তন করার সিদ্ধান্ত নিয়েছেন, সেই সারসংক্ষেপ Linear ইস্যু বা GitHub PR বিবরণে যায়, Slack থ্রেড বা মিটিং রেকর্ডিং ট্রান্সক্রিপ্টে নয় যা কেউ আবার দেখবে না।
আমরা এটা কঠিন উপায়ে শিখেছি: একটি PR তিন দিন রিভিউতে পড়ে ছিল কারণ রিভিউয়ার জানতেন না যে আমরা ইতিমধ্যে সেই পেজের জন্য সার্ভার-সাইড রেন্ডারিং ব্যবহার করার সিদ্ধান্ত নিয়েছি – সিদ্ধান্তটি আগের সপ্তাহের Slack থ্রেডে চাপা ছিল, এবং কেউ এটা ইস্যুতে লেখেনি। রিভিউয়ার ক্লায়েন্ট-সাইড হাইড্রেশন ট্রেড-অফ নিয়ে ছয়টি মন্তব্য রেখে গেলেন যা ইতিমধ্যে নিষ্পত্তি হয়েছিল, লেখক হতাশ হয়ে পড়লেন, এবং আমরা প্রায় এক সপ্তাহ হারিয়ে ফেললাম একটি কথোপকথনে যা দশ সেকেন্ড নিত যদি প্রেক্ষাপটটি প্রথম থেকেই কাজের সাথে সংযুক্ত থাকত।
তারপর থেকে, আমরা আলাদা সিদ্ধান্ত-ডকুমেন্ট বজায় রাখার চেষ্টা বন্ধ করে দিয়েছি (যা প্রায় দুই সপ্তাহ কাজ করেছিল, তারপর আর কেউ আপডেট করেনি) এবং সরাসরি ইস্যুতে সিদ্ধান্ত লিখতে শুরু করেছি। দশ সেকেন্ডের প্রচেষ্টা, এবং এটা টিকে থাকে কারণ এটা কাজের সাথে সংযুক্ত, কোনো মেটা-ডকুমেন্টে ভাসমান নয়।
২. স্ট্যাটাস দৃশ্যমান করুন, রিপোর্ট করা নয়
আমাদের টিমের জন্য, স্ট্যাটাস আপডেট মিটিং ছিল সবচেয়ে ব্যয়বহুল সিঙ্ক্রোনাস অনুষ্ঠান – প্রত্যেক ব্যক্তি গতকাল কী করেছেন এবং আজ কী করছেন তা বলছেন যখন বাকিরা অর্ধেক মনে শুনছেন এবং তাদের পালার জন্য অপেক্ষা করছেন। অ্যাসিঙ্ক-ফার্স্ট টিমে, স্ট্যাটাস এমন কিছু হওয়া উচিত যা আপনি দেখতে পান, কাউকে বলতে হয় না।
এর মানে আপনার প্রজেক্ট ম্যানেজমেন্ট টুলটি আসলে বাস্তবতা প্রতিফলিত করতে হবে। যদি একটি Linear ইস্যু "In Progress"-এ থাকে, তাহলে সেটা হওয়া উচিত কারণ কেউ সত্যিই এটা নিয়ে কাজ করছেন এখনই, শুধু এটা সোমবারে সেখানে সরিয়ে রাখা হয়েছিল এবং তারপর থেকে স্পর্শ করা হয়নি তা নয়। GitHub PR-এর বর্ণনামূলক শিরোনাম এবং লিঙ্কড ইস্যু থাকা উচিত। Figma ফাইলের স্পষ্ট নামকরণ থাকা উচিত যা বলে কোনটি চলমান এবং কোনটি অনুমোদিত।
স্ট্যাটাস দৃশ্যমান করে কী
- ইস্যুর সাথে লিঙ্কড PR – যে কেউ দেখতে পারেন কোন কোড কোন কাজের সাথে মেলে
- স্পষ্ট ব্রাঞ্চ নামকরণ –
feat/user-onboarding-flow fix-stuff-এর চেয়ে বেশি বলে
- আপডেট করা ইস্যু স্টেট – কাজ আসলে এগোলে টিকেট সরান, স্ট্যান্ডআপের সময় নয়
- লিখিত সাপ্তাহিক সারসংক্ষেপ – একজন ব্যক্তি ডাইজেস্ট লেখেন, সবাই অ্যাসিঙ্কে পড়েন
স্ট্যাটাস অদৃশ্য রাখে কী
- শুধু মৌখিক আপডেট – মিটিং শেষ হওয়ার সাথে সাথে তথ্য অদৃশ্য হয়
- স্ট্যাটাস মিটিং রেকর্ডের উৎস হিসেবে – স্ট্যান্ডআপে না বললে, হয়নি বলে গণ্য
- বাসি বোর্ড – সোমবার থেকে যে Kanban বোর্ড আর স্পর্শ করা হয়নি
- DM-এ আটকানো প্রেক্ষাপট – দুজন জানেন, বাকিরা অনুমান করছেন
৩. রেসপন্স উইন্ডো নির্ধারণ করুন, রেসপন্স টাইম নয়
অ্যাসিঙ্ক যোগাযোগের সূক্ষ্মতর উদ্বেগগুলির মধ্যে একটি হল খোলামেলা অপেক্ষা। আপনি একটি বার্তা পাঠান, এবং আপনি জানেন না উত্তর বিশ মিনিটে আসবে নাকি আগামীকাল বিকেলে। অনিশ্চয়তা আসল বিলম্বের চেয়ে খারাপ।
সমাধান হল দ্রুত উত্তর দাবি করা নয় (এটা শুধু সিঙ্ক্রোনাস সংস্কৃতি অতিরিক্ত ধাপে পুনরুজ্জীবিত করে)। সমাধান হল বিভিন্ন ধরনের যোগাযোগের জন্য রেসপন্স উইন্ডো সম্পর্কে স্পষ্ট প্রত্যাশা নির্ধারণ করা। আমাদের টিমের জন্য এটা মোটামুটি এরকম:
- পাবলিক চ্যানেলে Slack বার্তা: ৪ কার্যঘণ্টার মধ্যে
- PR রিভিউ: এক কার্যদিবসের মধ্যে
- Linear ইস্যু মন্তব্য: এক কার্যদিবসের মধ্যে
- জরুরি চিহ্নিত DM: কার্যঘণ্টায় ১ ঘণ্টার মধ্যে
- অন্য সব কিছু: ২ কার্যদিবসের মধ্যে
নির্দিষ্ট উইন্ডোর চেয়ে গুরুত্বপূর্ণ হল এগুলো বিদ্যমান এবং সবাই এতে সম্মত হয়েছে। একবার ক্যাডেন্স স্পষ্ট হয়ে গেলে, "তারা কি এটা দেখেছেন?" উদ্বেগটি কমে যায়, এবং মানুষ ৩০ মিনিট নীরবতার পরে ফলো-আপ পিং পাঠানো বন্ধ করে।
৪. সিঙ্ক্রোনাস সময় রক্ষা করুন যা সত্যিই প্রয়োজন
যা আমরা আশা করিনি: আমরা যে মিটিংগুলো রেখেছিলাম সেগুলো লক্ষণীয়ভাবে ভালো হয়ে গেল। যখন একটি মিটিং ডিফল্টের পরিবর্তে ব্যতিক্রম, মানুষ প্রস্তুত এবং মনোযোগী হয়ে আসে কারণ তারা জানে এটাই একমাত্র সুযোগ যা তারা একসাথে কিছু নিয়ে আলোচনা করতে পারবে।
আমরা তিন ধরনের সিঙ্ক্রোনাস মিটিং রেখেছি:
- সাপ্তাহিক টিম সিঙ্ক (সর্বাধিক ৩০ মিনিট) – স্ট্যাটাস আপডেট নয়, বরং ব্লকার, ক্রস-কাটিং সমস্যা, এবং "কেউ কি মনে করেন এই আর্কিটেকচারাল সিদ্ধান্ত আমাদের সমস্যায় ফেলবে?" কথোপকথন
- ডিজাইন রিভিউ – কিছু জিনিসের সত্যিই সিঙ্ক্রোনাস ভিজ্যুয়াল ফিডব্যাক দরকার
- পেয়ার প্রোগ্রামিং সেশন – দুজন মানুষ আটকে গেলে, একসাথে আলোচনা করা এখনও অ্যাসিঙ্ক আদান-প্রদানের চেয়ে দ্রুত
আগে যা মিটিং হত তার বাকি সব হয়ে গেল লিখিত প্রস্তাব, Loom ভিডিও, বা সংশ্লিষ্ট ইস্যুতে মন্তব্য থ্রেড। আমাদের ক্যালেন্ডার Tetris খেলার মতো দেখানো থেকে এমন কিছুতে পরিণত হল যা একজন মানুষ আসলে কাজ করতে পারে – যা, দেখা গেল, ক্যালেন্ডার থাকার মূল উদ্দেশ্য।
stat: "সপ্তাহে ৩টি মিটিং" headline: "১২ থেকে কমে" source: "অ্যাসিঙ্ক-ফার্স্টে যাওয়ার পর আমাদের টিমের আসল ক্যালেন্ডার"
যে অংশ কেউ সতর্ক করে না
অ্যাসিঙ্ক-ফার্স্টের কঠিন অংশ হল যোগাযোগের নিয়ম বা টুল সেটআপ নয়। এটা হল মানসিক সমন্বয়। যখন আমরা আমাদের দৈনিক স্ট্যান্ডআপ বাদ দিলাম, আমাদের একজন ইঞ্জিনিয়ার বললেন সকাল ১০টায় কারো সাথে চেক ইন না করেই গভীর কাজ শুরু করতে "অদ্ভুতভাবে দোষী বোধ" করছেন। অন্যজন বললেন সকালে Slack-এ নীরবতা মনে হচ্ছে কেউ কাজ করছে না, যদিও GitHub দেখাচ্ছিল প্রতি ঘণ্টায় কমিট আসছে।
এটি সমস্যার মানবিক-প্রকৃতির অংশ, এবং এর কোনো সিস্টেম-স্তরের সমাধান নেই। আমাদের যা সাহায্য করেছিল তা হল এটা নিয়ে স্পষ্ট কথা বলা। আমরা স্বীকার করেছিলাম যে অ্যাসিঙ্ক মাঝে মাঝে একাকী মনে হতে পারে, এবং আপনি যে সমস্যা সমাধান করছেন সে বিষয়ে একজন মানুষের সাথে কথা বলতে চাইলে শুধু সে কারণেই কল করা ঠিক আছে। নিয়মটি হল "কখনও কল করবেন না" নয়, এটা হল "যেসব জিনিসের কলের প্রয়োজন নেই সেগুলোর জন্য কলের প্রয়োজন নেই।"
টিমের কিছু মানুষ সত্যিই বেশি সিঙ্ক্রোনাস মিথস্ক্রিয়া পছন্দ করেন, এবং এটা মিটমাট করা অ্যাসিঙ্ক-ফার্স্ট দর্শনের ব্যর্থতা নয় – এটা স্বীকার করা যে যোগাযোগের পছন্দ ব্যক্তিগত, এবং যেকোনো একটি মোডে অনমনীয় আনুগত্য নিজেই এক ধরনের কর্মহীনতা।
কঠিন অংশ অ্যাসিঙ্ক ওয়ার্কফ্লো স্থাপন করা নয়। এটা হল বার্তার মাঝের নীরবতায় স্বস্তি পাওয়া, এবং বিশ্বাস রাখা যে আপনার সতীর্থরা কাজ করছেন যদিও আপনি তাদের দেখতে পাচ্ছেন না। attribution: Ellis Keane
এটা স্থায়ী করা: প্রথম ৩০ দিন
যদি আপনি একটি বিদ্যমান টিমকে অ্যাসিঙ্ক-ফার্স্ট ইঞ্জিনিয়ারিং টিম মডেলে রূপান্তরিত করছেন, তাহলে প্রথম মাসে এটা হয় শিকড় ধরে নয়তো "চলুন দ্রুত একটি কলে আলোচনা করি"-তে নিরবে ফিরে চলে যায়। এখানে আমাদের জন্য যা কাজ করেছিল একটি মোটামুটি টাইমলাইন হিসেবে:
সপ্তাহ ১: যোগাযোগের নিয়মগুলো লিখে রাখুন। সত্যিই – একটি এক-পাতার নথি যা বলে "এভাবে আমরা যোগাযোগ করি, এখানে প্রত্যাশিত রেসপন্স উইন্ডো, এখানে কী মিটিংয়ের যোগ্য।" এটা শেয়ার করুন, সিঙ্ক্রোনাসভাবে আলোচনা করুন (হ্যাঁ, বিদ্রূপাত্মক), এবং সম্মতি নিন।
সপ্তাহ ২: তিনটি পুনরাবৃত্তি মিটিং বাতিল বা রূপান্তর করুন। যেগুলো স্পষ্টতই ছদ্মবেশী স্ট্যাটাস আপডেট সেগুলো বেছে লিখিত ফরম্যাটে পরিবর্তন করুন। সব একসাথে বাতিল করবেন না – মানুষের ধীরে ধীরে মানিয়ে নেওয়ার দরকার, একটি গভীর খাদ নয়।
সপ্তাহ ৩: আপনার টুল হাইজিন অডিট করুন। Linear ইস্যুগুলো কি আসলে আপ-টু-ডেট? PR বিবরণগুলো কি উপযোগী? কাজ যেখানে হয় সেখানে কি সিদ্ধান্তগুলো লেখা হচ্ছে? না হলে, এই সপ্তাহই সেই নিয়মগুলো প্রতিষ্ঠা করার সপ্তাহ। কাউকে "অ্যাসিঙ্ক চ্যাম্পিয়ন" হিসেবে মনোনীত করুন যিনি মৃদুভাবে মনে করিয়ে দেন যখন কোনো সিদ্ধান্ত মৌখিকভাবে নেওয়া হয় কিন্তু লেখা হয় না।
সপ্তাহ ৪: রেট্রোস্পেকটিভ (স্বাভাবিকভাবেই, অ্যাসিঙ্কে)। একটি সহজ ফর্ম পাঠান: "কী কাজ করছে? কী করছে না? আপনি কী মিস করছেন?" উত্তরগুলো আপনাকে অবাক করবে – কেউ কেউ নীরবতা ভালোবাসবে, অন্যরা সংগ্রাম করবে। তত্ত্বের ভিত্তিতে নয়, বাস্তব ফিডব্যাকের ভিত্তিতে নিয়মগুলো সমন্বয় করুন।
- [x] যোগাযোগ নিয়মাবলী নথি লেখা
- [x] প্রতিটি চ্যানেলের জন্য রেসপন্স উইন্ডো নির্ধারণ
- [ ] ৩টি স্ট্যাটাস মিটিং বাতিল বা রূপান্তর
- [ ] টুল হাইজিন অডিট (ইস্যু, PR, সিদ্ধান্ত ডক)
- [ ] রূপান্তরের জন্য অ্যাসিঙ্ক চ্যাম্পিয়ন মনোনীত
- [ ] ৩০ দিন পরে অ্যাসিঙ্ক রেট্রোস্পেকটিভ পরিচালনা
- [ ] টিম ফিডব্যাকের ভিত্তিতে নিয়মাবলী সমন্বয়
কখন অ্যাসিঙ্ক-ফার্স্ট ভুল পছন্দ
অ্যাসিঙ্ক-ফার্স্ট বেশ কিছু সাধারণ পরিস্থিতিতে মানানসই নয়। যদি আপনার টিম একই অফিসে তিনজন মানুষ হয়, সিঙ্ক্রোনাস যোগাযোগ সম্ভবত ঠিকই আছে এবং অ্যাসিঙ্ক নিয়ম আনুষ্ঠানিক করার ওভারহেড এমন সমস্যা সমাধান করবে যা আপনার নেই। একইভাবে, যদি আপনার টিম সত্যিকারের সংকটে থাকে – প্রোডাকশন বন্ধ, একটি গুরুত্বপূর্ণ লঞ্চ আসন্ন, বা পণ্যের দিকনির্দেশনা পরিবর্তন হচ্ছে – এটা সিঙ্ক্রোনাস এলাকা, এবং অন্যথা ভান করা ব্যবহারিক না হয়ে মতবাদী হবে।
অ্যাসিঙ্ক-ফার্স্ট সবচেয়ে ভালো কাজ করে সেই টিমগুলোর জন্য যারা টাইম জোনে বিতরণ করা, প্রায় পাঁচজনের বেশি টিম (যেখানে সিঙ্ক্রোনাস সমন্বয়ের সমন্বয় বিস্ফোরণ ব্যাথা দিতে শুরু করে), এবং যে টিমগুলো মিটিংয়ে কী শিপ করেছে তা বলার চেয়ে কোড শিপ করতে বেশি পছন্দ করে। যদি এটা আপনার ক্ষেত্রে প্রযোজ্য হয়, অ্যাসিঙ্ক নিয়মে বিনিয়োগ প্রথম মাসের মধ্যে নিজেই পুষিয়ে যায়, মূলত পুনরুদ্ধার করা ইঞ্জিনিয়ারিং ঘণ্টায় যা মিটিং-শিল্প কমপ্লেক্সে অদৃশ্য হয়ে যেত।
টেলিগ্রাফ মুখোমুখি কথোপকথন বাতিল করেনি – এটা শুধু দৈনিক কুরিয়ার রাইড অপ্রয়োজনীয় করে তুলেছিল। অ্যাসিঙ্ক-ফার্স্ট একটি ইঞ্জিনিয়ারিং টিমের জন্য এটাই করে: এটা সেই অনুষ্ঠানগুলো অবসর নেয় যেগুলো শুধু বিদ্যমান ছিল কারণ টুলগুলো এখনও ধরতে পারেনি, এবং যে কথোপকথনগুলো সত্যিই গুরুত্বপূর্ণ সেগুলো রক্ষা করে।
প্রায়শই জিজ্ঞাসিত প্রশ্নসমূহ
Q: অ্যাসিঙ্ক-ফার্স্ট ইঞ্জিনিয়ারিং টিমে কোড রিভিউ কিভাবে পরিচালনা করবেন? A: একটি স্পষ্ট রিভিউ SLA নির্ধারণ করুন (আমাদেরটা এক কার্যদিবস) এবং PR বিবরণকে ভারী কাজ করতে দিন – শুধু কী পরিবর্তন হয়েছে তা নয় কেন পরিবর্তন হয়েছে তাও ব্যাখ্যা করুন, সংশ্লিষ্ট ইস্যু লিঙ্ক করুন, এবং রিভিউয়ার কী দিকে মনোযোগ দেবেন তা চিহ্নিত করুন। সবচেয়ে বড় অ্যাসিঙ্ক-রিভিউ ব্যর্থতার ধরন হল তিন দিন পড়ে থাকা একটি PR কারণ রিভিউয়ারের প্রেক্ষাপট দরকার যা শুধু কারো মাথায় আছে। লিখে রাখুন নয়তো পরে মূল্য দিন।
Q: Sugarbug কি অ্যাসিঙ্ক-ফার্স্ট ওয়ার্কফ্লোতে সাহায্য করে? A: এটা টুলগুলো জুড়ে প্রেক্ষাপট খণ্ডিত হওয়ার নির্দিষ্ট সমস্যায় সাহায্য করে – Slack-এ একটি সিদ্ধান্ত, Linear-এ একটি কাজ, Figma-তে একটি ডিজাইন মন্তব্য। Sugarbug সেই সিগন্যালগুলো সংযুক্ত করে যাতে মিটিংয়ে কাউকে বলতে না হয়ে স্ট্যাটাস দৃশ্যমান থাকে। এটাই একমাত্র সমাধান নয় (আপনি সব কিছু ম্যানুয়ালি ক্রস-লিঙ্ক করতেও পারেন), কিন্তু আমরা এটা তৈরি করেছিলাম কারণ ম্যানুয়াল সংস্করণে ক্লান্ত হয়ে পড়েছিলাম।
Q: অ্যাসিঙ্ক-ফার্স্টে যাওয়ার সময় টিমগুলো সবচেয়ে বড় ভুল কী করে? A: অভ্যাস পরিবর্তনের পরিবর্তে নীতি পরিবর্তন হিসেবে দেখা। আপনি একটি সুন্দর "যোগাযোগ নিয়মাবলী" নথি লিখতে পারেন, কিন্তু মানুষ যদি আসলে তাদের Linear ইস্যু আপডেট না করে বা PR-এ সিদ্ধান্ত না লেখে, তাহলে আপনি তথ্য প্রবাহ না বদলে শুধু মিটিং সরিয়েছেন। নিয়মগুলোকে পেশীর স্মৃতি হতে হবে, যা প্রায় এক মাস মৃদু, ধারাবাহিক উৎসাহ দেওয়া লাগে।
Q: অ্যাসিঙ্ক-ফার্স্ট টিমে জরুরি প্রোডাকশন সমস্যা কিভাবে পরিচালনা করবেন? A: আপনি সেগুলো অ্যাসিঙ্কে পরিচালনা করেন না – এটাই "অ্যাসিঙ্ক-ফার্স্ট, শুধু অ্যাসিঙ্ক নয়"-এর মূল কথা। একটি স্পষ্ট এস্কেলেশন পথ নির্ধারণ করুন: সত্যিকারের জরুরি পরিস্থিতির জন্য একটি নিবেদিত Slack চ্যানেল বা PagerDuty, এই বোঝাপড়া সহ যে বাকি সব কিছু স্বাভাবিক রেসপন্স উইন্ডো অনুসরণ করে। মূল পার্থক্য হল "জরুরি" (প্রোডাকশন বন্ধ) এবং "আমি এখনই উত্তর চাই" (যা সাধারণত অধৈর্য, জরুরি নয়) এর মধ্যে।
Q: Sugarbug কি স্ট্যান্ডআপ মিটিং সম্পূর্ণরূপে প্রতিস্থাপন করতে পারে? A: এটা তথ্য-সংগ্রহের অংশ প্রতিস্থাপন করতে পারে – "গতকাল সবাই কী করেছে?" অনুষ্ঠান – কারণ সেই প্রেক্ষাপট ইতিমধ্যে GitHub, Linear এবং Slack-এর মাধ্যমে প্রবাহিত হচ্ছে। যা এটা প্রতিস্থাপন করতে পারে না তা হল মানবিক সংযোগের অংশ, যে কারণে আমরা এখনও একটি ছোট সাপ্তাহিক সিঙ্ক রাখি যে কথোপকথনগুলো একই (ভার্চুয়াল) ঘরে থাকলে উপকৃত হয়।
আপনার ইনবক্সে সিগন্যাল ইন্টেলিজেন্স পান।