একাধিক টুলে টাস্ক ট্র্যাক করবে কীভাবে, মাথা না খুইয়ে
যে টিমই একাধিক টুলে টাস্ক ট্র্যাক করতে যায়, শেষমেশ একটা স্প্রেডশিট বানায়। কেন সেটা ভেঙে পড়ে, আর সিস্টেম-লেভেলের সমাধান দেখতে কেমন – সেটাই এখানে।
By Ellis Keane · 2026-03-13
সেরা সিস্টেমটা টিকে ছিল এগারো দিন
একাধিক টুলে টাস্ক ট্র্যাক করার জন্য আমি যত সিস্টেম ব্যবহার করেছি, তার মধ্যে সেরা ছিল একটা স্প্রেডশিট। পরিষ্কার, লজিক্যাল, সুন্দর কালার-কোডেড, আর বাস্তবতার সামনে টিকেছিল প্রায় এগারো দিন – যতদূর বুঝি, ম্যানুয়াল ট্র্যাকিং সিস্টেমের এটাই প্রায় সার্বজনীন half-life, সিস্টেম মেইনটেইন করা মানুষগুলো যতই স্মার্ট হোক না কেন, বা তারা যত শখ করে conditional formatting rules বসাক না কেন।
আমাদের কলাম ছিল Linear ticket, GitHub PR (যখন থাকত), কনটেক্সট থাকা Notion doc-এর লিঙ্ক, আর একটা status field যেটা নাকি আসলে কী হচ্ছে সেটা দেখাবে। সবকিছুই খুব যুক্তিসঙ্গত ছিল, আর দুই সপ্তাহের মধ্যে পুরোটা ছেড়ে দেওয়া হলো, কারণ ছয়জনের টিমে কেউই নিজের আসল কাজ থেকে কনটেক্সট সুইচিং করে গিয়ে সেই স্প্রেডশিট আপডেট করতে চায় না, যেটা আছে শুধু এই জন্য যে টুলগুলো নিজেদের মধ্যে ট্র্যাক রাখতে পারে না। পুরো ব্যায়ামটা – কাজ ট্র্যাক করার কাজ – প্রতিজনের দিনে প্রায় আধা ঘণ্টা খেয়ে ফেলছিল, আর কোয়ার্টার জুড়ে হিসাব করলে সেটা সত্যিই মন খারাপ করার মতো। কার্যত আমরা একটা ফুল-টাইম কর্মীর সমান সময় দিচ্ছিলাম শুধু এমন একটা ডকুমেন্ট চালাতে, যেটা কেউ চেক করার আগেই ভুল হয়ে যেত।
তবে আসল ব্যাপারটা হলো: তথ্য সবসময়ই ছিল – প্রতিটা issue-এর status ছিল, প্রতিটা PR-এর review state ছিল, আর approach বদলানো Slack thread-এ দরকারি সব কনটেক্সট ছিল। সমস্যা কখনোই তথ্যের ঘাটতি ছিল না – সমস্যা ছিল, প্রতিটা টুল শুধু নিজের ছোট অংশটাই জানত, আর এগুলোকে যুক্ত করে রাখছিল শুধু কারও স্মৃতি যে কোন অংশটা কোথায় দেখেছিল। যখন সেই স্মৃতি ভেঙে যায় (আর একসময় ভাঙেই, সাধারণত সবচেয়ে জরুরি দিনে), টাস্ক এমনভাবে ফসকে যেত যে পরে সেটা reconstruct করাও কঠিন হয়ে পড়ত।
কেন আরেকটা টুল দিয়ে একাধিক টুলে টাস্ক ট্র্যাক করা যায় না
আমাদের ইন্ডাস্ট্রিতে একটা স্থায়ী বিশ্বাস আছে যে cross-tool task tracking-এর সমাধান হলো আরও ভালো একটা টুল – স্মার্ট প্রজেক্ট ম্যানেজমেন্ট প্ল্যাটফর্ম, আরও শক্তিশালী ড্যাশবোর্ড, এমন কিছু যা অবশেষে তোমার টিমের সবকিছুর ওপর সেই বিখ্যাত "single pane of glass" দেবে। গত এক দশক ধরে প্রজেক্ট ম্যানেজমেন্ট ইন্ডাস্ট্রি ঠিক এই ধরনের প্রোডাক্টই বানিয়ে যাচ্ছে। এখন এমন প্রোডাক্ট ডজনের পর ডজন, আর ডজনের পর ডজন থাকা নিজেই বলে দেয়, একটাও একা সমস্যাটা আসলে কতটা সমাধান করতে পেরেছে। প্রথমটাই যদি কাজ করত, সাঁইত্রিশ নম্বরটার দরকার হতো না।
"প্রথমটাই যদি কাজ করত, সাঁইত্রিশ নম্বরটার দরকার হতো না।" – Ellis Keane
আমি নিজেও কিছুদিন এই মিথে বিশ্বাস করেছিলাম। আমরা এ ধরনের কয়েকটা টুল ট্রাই করেছি (সবগুলোর নাম বলছি না, তবে তুমি এই রাস্তা দিয়ে গেলে সম্ভবত একই কিছু টুল ব্যবহার করেছ), আর সবার একটা মৌলিক সীমাবদ্ধতা ছিল: এগুলোও শেষ পর্যন্ত single tool-ই। GitHub data, Slack thread আর Notion page একসাথে দেখানো ড্যাশবোর্ড স্প্রেডশিটের চেয়ে ভালো, ঠিক আছে, কিন্তু সেটাও নিজের মতো করে "task" এর একটা মডেল চাপিয়ে দেয় আর অন্যদের মডেলকে তার schema-তে গুঁজে দিতে চায়। ফলে তথ্য flatten হয়ে যায়, সম্পর্ক হারিয়ে যায়, আর শেষমেশ তুমি পাও খুব দামী একটা read-only view, যে data তোমার আগেই ছিল, এমন layout-এ দেখানো যা source tool-গুলোর কোনোটার সংগঠনই ঠিকমতো ফলো করে না।
আর এখানেই recursive অংশটা, যেটা আমার কাছে প্রায় হাস্যকরভাবে পারফেক্ট লাগে: "single pane of glass" যদি পেতে তোমাকে ইন্টিগ্রেশন সেটআপ করতে হয়, mapping configure করতে হয়, আরেকটা dashboard মেইনটেইন করতে হয়, আরেকটা app নিয়মিত চেক করতে হয়, তাহলে তুমি tool sprawl কমাচ্ছ না – বাড়াচ্ছ। তোমার n টুলের সাথে এখন n+1 হলো, আর n+1 নম্বর টুলের কাজই হচ্ছে বাকি n টুলকে নজর রাখা। ফলে তার accuracy কমে ঠিক তত, যত বেশি টুল সে দেখে আর যত ঘনঘন টুলগুলো API বদলায়। টুল বেশি, তাই টুল ম্যানেজ করতে টুল নিই, সেটা পুরো কাজ না করলে gap ভরতে আরেকটা টুল নিই। একসময় পেছনে তাকিয়ে দেখো, SaaS subscription-এর এক Rube Goldberg machine বানিয়ে ফেলেছ, আর আসল কাজ – যেটাকে সাপোর্ট করার কথা ছিল এসব টুলের – সেটা টুলের জন্য নয়, টুল সত্ত্বেও এগোচ্ছে।
মিথটা হলো এটা visibility problem – সব এক জায়গায় দেখলে ঠিক হয়ে যাবে। বাস্তব মেকানিজম হলো এটা relationship problem। কোনো single tool একাধিক টুলে টাস্ক ট্র্যাক করতে পারে না, কারণ প্রতিটা টুলের task-এর নিজস্ব মডেল আছে, আর মডেলগুলো মৌলিকভাবে অসামঞ্জস্যপূর্ণ। ড্যাশবোর্ডে পাশাপাশি দেখালেই মডেল compatible হয় না। শুধু incompatibility-টা দেখতে একটু সুন্দর লাগে। The visibility gap between modern work tools is deeper than dashboards can reach, which is why decision traceability across a fragmented engineering toolchain and how managers see team progress without asking for status reports are both ultimately the same problem in different clothing.
Cross-tool tracking ভাঙে এই কারণে না যে তুমি data দেখতে পারো না, বরং এই কারণে যে কোনো টুলই বোঝে না data কীভাবে যুক্ত। ড্যাশবোর্ড তোমাকে পাঁচ জায়গার facts দেখায়, কিন্তু বোঝে না এগুলো একই কাজের অংশ।
আসলে প্রতিটা টুল কী দেখে
এটা একটু কংক্রিটভাবে বলি, কারণ abstraction ব্যাপারটার খারাপ দিকটা আড়াল করে দেয়।
একটা কাজ ধরো – নতুন API endpoint implement করা। Linear-এ এটা issue, সঙ্গে status, assignee, priority, cycle। GitHub-এ এটা PR (বা দুইটা – backend-এর জন্য একটা, client-এর জন্য একটা), সঙ্গে review state, CI checks, merge status। Slack-এ এটা thread, যেখানে approach নিয়ে প্রশ্ন উঠেছে আর চল্লিশ মেসেজ ধরে তিনজন আলোচনা করে একেবারে ভিন্ন design-এ গিয়েছে। Notion-এ RFC page আছে, দুজন কনট্রিবিউট করেছে আর একজন Slack আলোচনা সব পাল্টে দিলেও doc আপডেট করতে ভুলে গেছে। আর কোথাও Figma-তে original design-এর comment থেকেই আসলে পুরো পরিবর্তন শুরু হয়েছিল।
পাঁচটা টুল, একটা টাস্ক, আর এই টুলগুলোর একটাও জানে না বাকি চারটাও একই জিনিস নিয়ে কথা বলছে। Figma comment জানে না RFC আছে। Slack thread জানে না ticket আছে। GitHub জানে না approach বদলেছে। প্রতিটা টুল নিজের ডোমেইন অসাধারণভাবে ট্র্যাক করে – সমস্যা হলো, একাধিক টুল জুড়ে চলা টাস্কের full lifecycle কোনো এক টুলই দেখে না, আর আমাদের সাইজের টিমে এক দিনের বেশি সময় নেয় এমন প্রায় সব টাস্কই এমন।
এই সব দ্বীপের মধ্যে সেতু হলো মানুষের স্মৃতি, আর মানুষের স্মৃতি (যে কেউ কলের মধ্যে থেকে Slack thread মিস করেছে সে জানে) পুরো প্রজেক্ট ভিজিবিলিটি দাঁড় করানোর জন্য ভীষণ সীমিত রিসোর্স।
তিনভাবে টাস্ক উধাও হয়
ডজন ডজন টাস্কে cross-tool tracking ভাঙতে দেখে (আর সত্যি বলতে, এই ব্যর্থতার অনেকগুলোতে আমরাও ভূমিকা রেখেছি), আমরা কিছু pattern দেখতে শুরু করি। আসলে তিন ধরনের failure mode আছে, আর এগুলোর নাম দেওয়া কাজে দেয়, কারণ fix-ও আলাদা লাগে।
Ghost task। কাজ এক টুলে আছে, অন্যগুলোতে আসে না। কেউ issue খুলল, সম্পর্কিত PR হলো কিন্তু কেউ link করল না, approach আলোচনা হলো এমন channel-এ যেখানে issue creator নেই, আর তিন সপ্তাহ পর টাস্ক সবার কাছে blocked দেখায়, শুধু যিনি চুপচাপ ship করে চলে গেছেন তিনি বাদে। কাজ হয়েছে – কেউ জানে না।
Stale status। এক টুলে টাস্কের status বাস্তবতা থেকে drift করে যায়, কারণ আসল progress অন্য জায়গায় ট্র্যাক হচ্ছে। ticket-এ এখনও "In Progress", কিন্তু PR গতকাল merge হয়েছে। doc-এ "Draft", কিন্তু টিম thread-এ অন্য approach approve করেছে যেটা কেউ bookmark করেনি। "source of truth" দেখে মানুষ ভুল ছবি পায়, আর stale data দেখে সিদ্ধান্ত হয় – যা অনেক দিক থেকে data না থাকার চেয়েও খারাপ, কারণ data না থাকলে অন্তত তুমি জানো তুমি অনুমান করছ।
Orphaned context। এটা সবচেয়ে subtle, আর (কমপক্ষে আমার অভিজ্ঞতায়) আসল ক্ষতি সবচেয়ে বেশি করে। কোনো আলোচনা টাস্কের দিক বদলে দেয় – হয়তো অপ্রত্যাশিত constraint, হয়তো কারও ভালো approach – কিন্তু সেটা original spec-এ ফেরত যায় না। দুই সপ্তাহ পর কেউ original requirement ধরে টাস্ক তুলে নিয়ে ভুল জিনিস বানায়, আর টিমের একটা sprint উড়ে যায়। কনটেক্সট পুরো সময় ছিল – শুধু এমন টুলে ছিল যা টাস্ক চিনত না।
তিনটাই একই root cause থেকে আসে: কী হচ্ছে তার shared model টুলগুলোর নেই। এগুলো দ্বীপ, মাঝখানে human-attention bridge, আর human attention-ই সেই রিসোর্স যা সবসময় কম।
এখনই কী করতে পারো (কিছু না কিনেই)
সিস্টেম-লেভেলের fix-এ যাওয়ার আগে (আর হ্যাঁ, এটা পুরোপুরি sales pitch নয় – অন্তত পুরোটা নয়), শুধু discipline আর lightweight process change দিয়ে cross-tool tracking failure কমানোর কিছু উপায় আছে। কিছু বানানোর আগে আমরা এগুলো সব ট্রাই করেছি, আর ভালো tooling থাকলেও এর কিছু এখনও জরুরি।
প্রতিটা টাস্কের canonical home নির্ধারণ করো। status-এর source of truth হিসেবে একটা টুল বেছে নাও (আমাদের জন্য Linear), আর টিম rule করো যে status বদলায় এমন সিদ্ধান্ত ২৪ ঘণ্টার মধ্যে ওখানে reflect করতে হবে, আলোচনা যেখানেই হোক। এটা পুরো সমস্যা solve করে না, কিন্তু stale status failure mode বেশ কমায়।
সাপ্তাহিক orphaned-context sweep চালাও। সপ্তাহে একবার, একজন (রোটেট করো) গত সপ্তাহের Slack thread দেখে মিলিয়ে নাও কোনো সিদ্ধান্ত বা দিক-পরিবর্তন সংশ্লিষ্ট ticket বা doc-এ ধরা হয়েছে কি না। উদ্দেশ্যপূর্ণ ১৫ মিনিট bridging করলে ধারণার চেয়ে বেশি context drop ধরা পড়ে।
Cross-link ধারাবাহিকভাবে করো। PR খোলার সময় issue link দাও। টাস্ক নিয়ে Slack thread শুরু করলে প্রথম মেসেজে ticket URL দাও। doc আপডেট করলে thread-এ mention করো। এটা বিরক্তিকর, ম্যানুয়াল, কেউ করতে চায় না (তাই সময়ের সাথে degrade করে), কিন্তু যতক্ষণ চলে, ভালোই চলে।
Stale-status SLA সেট করো। ticket পাঁচ business day আপডেট না হলে আর সম্পর্কিত PR বা thread-এ activity থাকলে flag করো। এটা weekly Linear filter দেখে নিলেও করা যায়।
এগুলোর কোনোটাই permanent solution না – সবই মানুষ মনে রাখবে এই অনুমানের ওপর দাঁড়ানো, আর আমরা ইতিমধ্যেই দেখেছি এই রিসোর্স নির্ভরযোগ্য না – তবু structural fix লাগবে কি না বুঝে ওঠার আগ পর্যন্ত এগুলো ক্ষতি যথেষ্ট কমায়।
বাস্তব সমাধান দেখতে কেমন (আর যেটা আমরা এখনও খুঁজছি)
এখানে সাবধানে বলতে চাই, কারণ এতক্ষণ আমি অতিরিক্ত প্রতিশ্রুতি দেওয়া টুল নিয়ে খোঁচা মেরেছি, আর এখন নিজে একই ভুল করতে চাই না। তাই আমরা যেটাকে বাস্তব fix মনে করি সেটা বলছি, সঙ্গে সৎ caveat – এর কিছু অংশ আমরা এখনও গুছিয়ে নিচ্ছি।
মূল ইনসাইট – হ্যাঁ, বলার পর obvious শোনায়, কিন্তু আমাদের এখানে পৌঁছাতে সময় লেগেছে – হলো তোমার আরেকটা ড্যাশবোর্ড দরকার নেই। তোমার দরকার নলেজ গ্রাফ। টুল থেকে data এনে read-only aggregation না, বরং এমন কিছু যা টুল জুড়ে আইটেমগুলোর সম্পর্ক সক্রিয়ভাবে বোঝে। যখন PR description-এ issue number রেফার হয়, কেউ thread-এ দুটোই mention করে, design comment original spec-এ লিঙ্ক করে, তখন নলেজ গ্রাফ এগুলো অটোমেটিক কানেক্ট করতে পারে – explicit reference match করে, কনটেন্টের semantic similarity ধরে, আর related activity-র temporal proximity ব্যবহার করে – কাউকে ম্যানুয়ালি লিঙ্ক করতে হয় না।
---
Sugarbug তোমার বিচ্ছিন্ন টুলগুলোকে একটি জীবন্ত নলেজ গ্রাফে যুক্ত করে। টাস্ক, মানুষ, কথোপকথন – Slack, GitHub, Notion, Figma আর আরও টুল জুড়ে অটোমেটিকভাবে লিঙ্কড। যত বেশি সময় এটা চলে, তত বেশি স্মার্ট হয়। কীভাবে কাজ করে দেখো
---
Sugarbug দিয়ে আমরা এটাই বানাচ্ছি। এটা তোমার বিদ্যমান টুলের সাথে কানেক্ট করে (নতুন কিছু adopt করতে হয় না – টিম যা জানে তাই ব্যবহার করো) আর সবকিছু কীভাবে সম্পর্কিত তার একটা গ্রাফ বানায়। এই graph approach তিনটাই failure mode ধরতে পারে: ghost task ধরা পড়ে কারণ কেউ ticket link না করলেও system PR activity দেখে। stale status flag হয় কারণ issue update না হলেও system জানে code merge হয়েছে। orphaned context surface হয় কারণ task owner না দেখলেও system thread-এর সিদ্ধান্তকে প্রভাবিত টাস্কের সাথে লিঙ্ক করে।
সৎভাবে বলি, সব অংশে এখনও সমানভাবে পারফেক্ট না – আর loop-এ কিছু human judgment ছাড়া orphaned context পুরো solve করা যায় কি না, আমি নিজেও নিশ্চিত নই, কারণ conversational intent বোঝা এখনও কঠিন। ghost task detection solid, stale status flagging দ্রুত ভালো হচ্ছে, আর context surfacing-ই এখন আমাদের frontier। তবে architecture-এর শক্তি হলো, নতুন প্রতিটা connection পুরনোগুলোকে আরও স্মার্ট করে, আর এই compounding effect-টাই এই প্রজেক্টে আমার কাছে সবচেয়ে ইন্টারেস্টিং।
আমাদের জন্য কী বদলেছে
Cross-tool tracking আংশিকভাবে ঠিক হলেও সবচেয়ে অবাক করা জিনিস হলো সময় সাশ্রয়ের বাস্তব অনুভূতি। এটা quarterly review-এর abstract productivity metric না – ব্যাপারটা হলো, প্রতিদিন সকালে approach কেন বদলালো সেটা খুঁজতে Slack ঘেঁটে বিশ মিনিট নষ্ট করা বন্ধ হয়েছে, আর "এই X-এর কী হলো?" জিজ্ঞেস করে কারও তিন জায়গা চেক করা পর্যন্ত অপেক্ষা করতে হয় না।
আমাদের টিম (rough estimate, controlled study না) দিনে মোট দুই থেকে তিন ঘণ্টা খরচ করছিল যেটাকে আমি work-about-work বলি: tracking doc আপডেট, টুল জুড়ে context খোঁজা, যেগুলো অটো কানেক্ট হওয়ার কথা সেগুলো হাতে কানেক্ট করা। ট্র্যাকিং কাজ করলে – যখন তুমি ভরসা করতে পারো সিস্টেম জানে কী কোথায় – কিছু জিনিস বদলে যায়।
Status meeting ছোট হয় বা একেবারে বাদ যায়। আমরা daily standup থেকে সপ্তাহে দুইবার check-in-এ গেছি, যদিও বলতে হবে async অভ্যাস ভালো হওয়াও এতে ভূমিকা রেখেছে, তাই সব কৃতিত্ব tooling-কে দিচ্ছি না। দরকারের সময় context সামনে আসে – তুমি টাস্ক তুললেই relevant thread, doc, comment আগে থেকেই linked থাকে, তাই involved হওয়ার আগে পনেরো মিনিট reconstruct করতে হয় না। আর ফসকে যাওয়া কাজ কমে – শূন্য হয় না (আমার মনে হয় কোনো সিস্টেমই পুরোটা রোধ করতে পারে না), কিন্তু নাটকীয়ভাবে কমে, যা বছরের পর বছর টুলের ফাঁকে টাস্ক নীরবে মরে যেতে দেখে আসার পর ছোটখাটো অলৌকিক লাগতেই পারে।
এর কিছু pitch-এর মতো শোনাতে পারে, আর পরিষ্কারভাবে বলছি, সব edge case জুড়ে আমরা এখনও পুরো ডেলিভারি দিচ্ছি না, সেদিকেই এগোচ্ছি। কিন্তু দিকটা সঠিক মনে হচ্ছে, আর শুরুতে যে ফল পাচ্ছি তা এতটাই উৎসাহজনক যে আমরা এটা শেষ পর্যন্ত নিয়ে যেতে প্রতিশ্রুতিবদ্ধ।
টুলের ফাঁকে টাস্ক হারানো বন্ধ করো। Sugarbug Linear, GitHub, Slack, আর Notion-কে এক জীবন্ত নলেজ গ্রাফে যুক্ত করে।
Q: Sugarbug কি GitHub, Slack, Notion, আর অন্য টুলে টাস্ক স্বয়ংক্রিয়ভাবে ট্র্যাক করতে পারে? A: হ্যাঁ। Sugarbug GitHub, Slack, Notion, Linear, Figma, ইমেইল, আর ক্যালেন্ডারের সাথে কানেক্ট করে, তারপর এমন একটা নলেজ গ্রাফ বানায় যা সবগুলোর সম্পর্কিত আইটেম লিঙ্ক করে। যখন PR কোনো issue রেফার করে আর কেউ thread-এ approach নিয়ে আলোচনা করে, Sugarbug বুঝে এগুলো একই টাস্কের অংশ – ম্যানুয়াল লিঙ্কিং লাগে না।
Q: প্রজেক্ট ম্যানেজমেন্ট ড্যাশবোর্ড থেকে Sugarbug আলাদা কীভাবে? A: ড্যাশবোর্ড তোমার টুলের data এক ভিউতে জড়ো করে, কিন্তু ওগুলো read-only snapshot, সম্পর্ক বোঝে না। Sugarbug একটা জীবন্ত নলেজ গ্রাফ বানায় যা টুল জুড়ে টাস্ক, মানুষ, আর কথোপকথনকে যুক্ত করে – আর যত বেশি সময় চলে, তত বেশি স্মার্ট হয়। এটা শুধু দেখায় না কী কোথায় আছে; যেগুলো ফসকে যাওয়া কাজ হতে যাচ্ছে, সেগুলোও ধরে ফেলে।
Q: একাধিক টুলে টাস্ক ট্র্যাক করলে কি সত্যিই এত সমস্যা হয়? A: আমাদের অভিজ্ঞতায়, হ্যাঁ – আর টিমগুলো সাধারণত মাপা শুরু করার আগে সমস্যার আকার বোঝে না। সমস্যা আলাদা টুল খারাপ এটা না। সমস্যা হলো কনটেক্সট টুল জুড়ে ভেঙে যায়, আর কোনো একক টুলের কাছে পুরো ছবি থাকে না। টাস্ক আটকে যায় কারণ যাকে কাজ করতে হবে, সে জানেই না প্রাসঙ্গিক আলোচনা পুরোপুরি অন্য কোথাও হয়ে গেছে।
Q: আমি কি আমার বিদ্যমান টুলের পাশাপাশি Sugarbug ব্যবহার করতে পারি? A: এটাই পুরো কথা। Sugarbug তোমার বিদ্যমান ওয়ার্কফ্লো টুলস রিপ্লেস করে না – কানেক্ট করে। তোমার টিম যে টুলগুলো আগেই জানে, তুমি সেগুলোই ব্যবহার করো, আর Sugarbug সবকিছুকে লিঙ্ক করা ইন্টেলিজেন্স লেয়ার বানায়। কোনো migration না, দৈনন্দিন কাজের জন্য নতুন UI শেখার ঝামেলাও না।
তোমার টিম যদি টুলের ফাঁকে উধাও হওয়া টাস্কে ঘণ্টার পর ঘণ্টা হারায়, Sugarbug দেখে নেওয়া যেতে পারে।