چرا ما خطی را برای ردیابی اشکال کنار گذاشتیم

Summarize this content to 400 words in Persian Lang
من عاشق بزرگ‌تر کردن سیستم‌ها هستم – هیچ چیز به اندازه این که بدانید چیزی که با هم هک کرده‌اید کار می‌کند و به تیم کمک می‌کند به جای ایجاد فرآیند زیاد، رضایت‌بخش نیست.

اما ساختن نرم افزارهای آشنا نیاز به تست های زیادی دارد.

این بخشی از دلیل این است که بهترین تیم‌های محصول مانند اپل و Linear برای انتشار چیزها وقت می‌گذارند – اولین پیش‌نویس یک محصول نرم‌افزاری به‌طور اجتناب‌ناپذیری با بسیاری از موارد لبه‌های نامطلوب مواجه می‌شود که باعث شکسته شدن چیزها می‌شود، و شما به تیمی از افراد نیاز دارید. سعی کنید تا آنجا که ممکن است بسیاری از موارد لبه را قبل از ارسال آن به صدها هزار نفر شبیه سازی کنید.

یکی از راه‌هایی که می‌توانید لبه‌های ناهموار را شبیه‌سازی کنید، استفاده از ابزاری مانند Synthetic Traffic است، اما راه دیگر این است که تا آنجا که می‌توانید با اپلیکیشنی که می‌سازید عجیب و غریب شوید.

صرف نظر از ابزاری که استفاده می کنید، فقط ردیابی اشکالات به خودی خود یک چالش است. با نیاز به جا دادن آن در میدان مین – بحث در مورد اینکه چگونه تیم شما باید وظایف را مدیریت کند (Coda؟ Linear? Jira? Notion??) و شما به یک بحث واقعاً غم انگیز و خشمگین نگاه می کنید. این تفاوت بین نوشیدن یک لیوان آب پرتقال تازه فشرده و نوشیدن یک لیوان ودکا-آب ردبول-ترشی-سریراچا است – این سه شنبه شب تهاجمی، ترش، تند، چسبناک و غیر ایده آل است.

ترکیب های بی نهایتی از نحوه ردیابی اشکالات توسط افراد وجود دارد، اما من می خواستم سیستم خود را که امروز از آن استفاده می کنیم به اشتراک بگذارم زیرا ممکن است تیم های کوچک را ترغیب کند تا بر روی کارهایی که امروز کارهای بیشتری انجام می دهند تمرکز کنند، نه اینکه سیستم مناسبی را برای مقیاس بندی قبل از اینکه واقعاً نیاز داشته باشید پیدا کنند. .

از دست دادن خطی

بنیانگذار من، @kiet_onlook، و من در ابتدا کار خود را در Linear با شرکت Onlook.dev آغاز کردیم، اما با جریان کاری خود متوجه شدیم: همانقدر که ما Linear را دوست داریم، سازماندهی همه اشکالات ما در واقع مانع از انجام کار شد. انجام شده.

ما باید ساده تر می رفتیم.

من و کیت به صورت ناهمزمان در Slack و Google Docs ارتباط برقرار می‌کنیم، بنابراین ما به منبعی از حقیقت برای اشکالات نیاز داشتیم که درک و سازماندهی آن بسیار آسان باشد. در حالت ایده آل، منبع حقیقت نباید چیز دیگری باشد که باید بررسی کنیم یا وارد آن شویم یا باید به خاطر بسپاریم که کجا پیدا کنیم.

ما در Slack با کانال #اشکالات خود شروع کردیم، جایی که با استفاده از چهار شکلک اشکال به یک سیستم رنگی رسیدیم که در یک نگاه اولویت‌بندی را به شما منتقل می‌کند.

پروانه = درخواست ویژگی / بهبود UX بزرگتر.

سوسک = بهبود کوچک / پیشنهاد UX کوچکتر / تنظیم آرایشی

کفشدوزک = شماره متوسط

پرواز = گند / شکسته / تصادف / چیزهای واقعا بد

چرا هر یک از این نقش ها را به آن ایموجی های خاص اختصاص دادیم؟ کمی شهودی است، و اگر دقت کنید، طیف رنگی از خوب به بد است.

🦋 پروانه / آبی – خوب! بهبود، پیشنهاد و غیره
🪲 سوسک سبز / سبز – بهبود کوچک / تنظیم آرایشی، نه خیلی مهم.
🐞 لیدی باگ / قرمز – بد / نیاز به توجه دارد.
🪰 پرواز / قهوه ای – واقعا بد / مدفوع / حیاتی است که باید مورد توجه قرار گیرد.

گرفتن اشکالات در زمینه

سیستم علامت گذاری اشکال در عمل چگونه به نظر می رسد؟

به عنوان مثال، فرض کنید که Kiet یک نسخه جدید منتشر کرد، و من در حین آزمایش با یک باگ مواجه شدم. من یک بخش سرصفحه جدید را در Google Doc ردیابی اشکال خود برای تاریخ می‌گذارم (پراکسی آسان برای نسخه احتمالی که در حال آزمایش هستیم) و چک لیستی از آنچه با آن برخورد می‌کنم تهیه می‌کنم. با این حال، در ابتدای هر نقطه، شکلک اشکال مناسب را اضافه می کنم تا سازماندهی آن در یک نگاه آسان شود.

Kiet یا I اغلب درخواست‌های باگ را در گروه‌هایی دسته‌بندی می‌کنیم، زیرا پروانه‌ها (درخواست‌های ویژگی) را می‌توان برای مدتی به تعویق انداخت در حالی که Flys (مسائل بحرانی) باید خیلی زودتر برطرف شود.

و از آنجایی که این کار در Google Doc انجام می‌شود، می‌توانیم بسته به مدت زمانی که فکر می‌کنیم ممکن است طول بکشد و چقدر فوری باشد، در مورد اشکالات مورد نیاز بحث کرده و دوباره دسته‌بندی کنیم. Google Doc همچنین سابقه طولانی از ایده‌های ویژگی‌هایی را که در گذشته به آن‌ها رسیده‌ایم به ما می‌دهد، بنابراین همانطور که برنامه‌ریزی می‌کنیم چه چیزی را منتشر کنیم، می‌توانیم با CMD+F به شکار پروانه‌ها برویم و لیست جدیدی از ویژگی‌هایی را که می‌خواهیم شروع کنیم. اولویت بندی کنید.

ما یک کانال #اشکالات در Slack داریم که در ابتدا آن‌ها را ردیابی می‌کردیم، و بیشتر مکالمات ما از کانال #اشکالات به سند ردیابی اشکال برای موارد ناهمزمان منتقل شده است، اما کانال #اشکالات مکانی مفید برای ردیابی مکالمات بدون شلوغی است. نوار کناری doc همچنین، از آنجایی که Slack برای به اشتراک گذاری اسکرین شات ها و فایل ها عالی است، می تواند برای ارائه زمینه غنی تر از Google Docs بهتر باشد.

به عنوان یک تقویت اضافی برای ردیابی اشکال ما، من یک اتوماسیون Zapier راه اندازی کردم که اگر کسی با یک شکلک اشکال در پیامی واکنش نشان دهد، یک اشکال را به سند ما ارسال می کند.

Google Doc منبع حقیقت ما است، و قالب‌بندی چک لیستی برای ما آسان است که بتوانیم با آن کار کنیم، در حالی که ما از کانال #bugs Slack برای بحث‌های رفت و برگشت فعال در مورد اشکالات استفاده می‌کنیم.

از آنجایی که هر اشکال در Google Doc پیوندی به پیام Slack دارد، می‌توانیم همچنان به بحث ارجاع دهیم و در عین حال چک لیست اصلی را با ایده کلی باگ تمیز نگه داریم و هیچ نویز وجود نداشته باشد.

خیلی زود بیش از حد بهینه سازی نکنید

اگر به تازگی پروژه ای را شروع کرده اید، بزرگترین توصیه من این است که با ابزارهای خود ساده کار کنید. هر ثانیه ای که برای ساختن یک سیستم فانتزی صرف می کنید، زمان و انرژی است که صرف ساختن یک محصول یا صحبت با افرادی می شود که برای آنها می سازید.

پل گراهام در مورد ایده «خانه بازی» در مقاله‌اش قبل از راه‌اندازی نوشت و این یک یادآوری مداوم است که سیستم‌بندی چیزها یا پیچیده شدن بیش از حد با نحوه تنظیم فرآیندهای خود در روزهای اولیه مهم نیست.

ما طرفداران بزرگ این ابزارها هستیم که به تیم ها کمک می کند بدون زحمت با هم کار کنند، اما تا زمانی که افراد بیشتری را خارج از بنیانگذاران نیاوریم، باید همه چیز را ناب نگه داریم. اگر از خود این سوال را می‌پرسید که “این بلیط را کجا بگذارم؟” اغلب به دلیل اینکه ابزاری برای مدیریت پروژه راه‌اندازی می‌کنید که دارای ویژگی‌های بسیار زیادی است، ممکن است لازم باشد ساده‌تر عمل کنید.

بعداً زمان زیادی برای سیستم‌بندی فرآیند خود خواهید داشت، اما در حال حاضر، سعی کنید باگ‌ها را در قالبی ساده‌تر پیدا کنید.

کمک کنید خارج شوم!

اگر فکر می کنید این مقاله به شما کمک کرده است، بسیار خوشحال خواهم شد اگر بتوانید به ما یک ستاره بدهید! ❤️

https://github.com/onlook-dev/studio

همچنین، من کنجکاو هستم که چگونه اشکالات را در یک تیم بسیار کوچک ردیابی می کنید. خبرم کن!