از درخواستِ مشتری تا کدِ تحویل‌شده — در یک ابزار
مشتری مشکلی گزارش میکند. گزارش تسک میشود، برنامهنویس از داخلِ IDE درستش میکند، کامیت به همان تسک گره می‌خورد، کار از بازبینی و تست می‌گذرد — و وقتی به مرحلهی نهایی رسید، به مشتری خبر داده میشود که انجام شد. Vi همهی حلقه‌های این زنجیره را به هم وصل میکند؛ چیزی دستی کپی نمی‌شود و لازم نیست کسی یادش بماند به مشتری خبر بدهد.
درخواستِ مشتری معمولاً کجا گم میشود؟
درخواستِ مشتری معمولاً در دست‌به‌دست شدن بینِ ابزارها گم میشود: پشتیبانی آن را در یک helpdesk ثبت میکند، کسی آن را دستی در ابزارِ مدیریتِ کار کپی میکند، برنامهنویس در Git درستش میکند، و مشتری فقط وقتی خبردار میشود که کسی یادش بماند به ابزارِ اول برگردد. هر دست‌به‌دست شدن بخشی از زمینه را جا می‌گذارد — کدام مشتری خواسته، دقیقاً چه خواسته، کدام کامیت درستش کرده — و مشتری مدام می‌پرسد «خبری نشد؟» چون از نگاهِ او هیچ‌چیز تکان نخورده. راه‌حل helpdeskِ بهتر یا ابزارِ مدیریتِ کارِ بهتر نیست؛ یک رکوردِ واحد است که از درخواستِ مشتری تا خودِ کد جلو می‌رود.
زنجیره، حلقه به حلقه
هر قدم را آدمِ دیگری انجام میدهد و هر کدام همان رکورد را به نفرِ بعد می‌سپارد — بدونِ کپی، بدونِ سیستمِ دوم.
- 1مشتری
به آدرسِ Viِ سازمانِ شما ایمیل می‌زند یا فرمِ پورتالِ مشتری را پر میکند، و بی‌درنگ شمارهی پیگیری و لینکِ صفحهی وضعیت را میگیرد.
- 2سرپرستِ تیم
درخواست را در صندوقِ ورودی بررسی میکند و آن را با کلماتِ خودِ تیم به کارِ واقعی تبدیل میکند: یک تسک، یا — اگر چند مشکل را توصیف میکند — اپیکی با تسک‌هایی که لازم دارد، تا ۲۰ تسک. پیامِ اصلیِ مشتری در مکالمه‌ی درخواست میماند و در تسک کپی نمی‌شود.
- 3گردشکار
تسک واردِ گردش‌کارِ شما میشود، خودکار به کم‌بارترین فردِ نقشِ مناسب واگذار میشود و ساعتِ SLAاش شروع به کار میکند — درست مثلِ هر کارِ دیگری که تیمتان تحویل میدهد.
- 4برنامهنویس
تسک را در VS Code، Visual Studio، RAD Studio یا Lazarus انتخاب میکند و Start را می‌زند. وقتی کار آماده شد Done را می‌زند: Vi تغییرات را با پیامی مثلِ «[#123] عنوانِ تسک» کامیت میکند، اگر مخزن ریموتِ Git داشته باشد push میکند و مرحلهی او را پایان‌یافته علامت می‌زند. تسک جلو می‌رود — هنوز بسته نشده است.
- 5بازبین / QA
در مرحلههای بعدیِ گردشکار — به هر تعداد که فرایندتان لازم دارد — بازبینی، تست یا تأیید میکند. رد کردن تسک را با دلیل برمی‌گرداند؛ تأیید آن را جلو میبرد.
- 6گردشکار
وقتی تسک — یا در درخواستِ شکسته‌شده، همهی تسک‌های اپیکش — به مرحلهی نهاییِ گردشکار برسد، درخواست انجام‌شده حساب میشود. تمام‌شدنِ مرحلهی یک برنامهنویس به‌تنهایی هیچ‌وقت درخواستِ مشتری را نمی‌بندد.
- 7مشتری
ایمیلی میگیرد که درخواستش انجام شد و صفحهی وضعیت آن را انجام‌شده نشان میدهد. یک نظرسنجیِ تک‌کلیکیِ رضایت جداگانه می‌رسد. اگر بعد از آن دوباره بنویسد، پیام به صندوقِ ورودی می‌رود و تیم تصمیم میگیرد کار را بازگشایی کند یا کارِ تازه‌ای شروع کند.
دو نما از یک رکورد
مشتری و تیمتان به یک درخواست نگاه میکنند، ولی هر کدام فقط چیزی را میبیند که به کارش می‌آید.
مشتری چه میبیند
شمارهی پیگیری، یکی از چهار وضعیتِ ساده — دریافت شد، در حالِ انجام، انجام شد، بسته شد — درصدِ پیشرفت، و در درخواستِ شکسته‌شده تعدادِ بخش‌های انجام‌شده («۲ از ۳»). در پنلِ مشتری: پاسخهایی که تیمتان برای او فرستاده، به‌اضافه‌ی پیام‌ها و پیوست‌های خودش. نه نامِ کارشناس، نه مرحلههای داخلیِ گردشکار، نه بحثِ داخلی.
تیمتان چه میبیند
تسکِ کامل: مرحلهی گردشکار، مسئول، SLA، کامنت‌های داخلی، تأییدها، زمانِ صرف‌شده — و در بخشِ «تحویل‌شده»ی تسک هر کامیتی که برایش زده شده، با هش، شاخه و تعدادِ خطوط. کارتِ درخواستِ مشتری روی تسک (و برای درخواستِ چندتسکی روی اپیک) شمارهی پیگیری، دقیقاً همان چیزی که مشتری الان میبیند، نتیجه‌ی نظرسنجی و مکالمه با مشتری را نشان میدهد که تیم همان‌جا پاسخ میدهد.
درخواستِ مشتری چطور به کد وصل میشود؟
درخواستِ مشتری از راهِ تسکش به کد وصل میشود: Commit & Close شمارهی تسک را به‌صورتِ [#123] در پیامِ کامیت می‌نویسد و متادیتای کامیت را به همان تسک گزارش میدهد، پس درخواست، تسک و کامیت‌هایش یک خطِ قابلِ ردگیری می‌سازند. فقط متادیتا از سیستمِ برنامهنویس بیرون می‌رود — هش، پیام، شاخه و تعدادِ خطوط، و نامِ فایل‌ها اگر سازمانتان آن را روشن کند. سورسکد هرگز بیرون نمی‌رود.
اگر یک درخواست در واقع چند کارِ جدا باشد چه؟
اگر یک درخواست در واقع چند کار است، آن را به اپیک تبدیل کنید و تسک‌هایی را که لازم دارد فهرست کنید، یا بعداً یک تسکِ موجود را به حداکثر ۲۰ تسک جدا کنید. هر تسک مثلِ همیشه از راهِ گردشکار واگذار میشود و هیچ تسکِ ساختگی‌ای فقط برای نگه‌داشتنِ مکالمه ساخته نمی‌شود — مکالمه مالِ خودِ درخواست است. مشتری همچنان یک درخواست میبیند با پیشرفتِ «بخش‌های انجام‌شده از کل»؛ درخواست فقط وقتی حل‌شده حساب میشود که همهی بخش‌ها انجام شده باشند.
برای چه تیم‌هایی مناسب است — و برای چه تیم‌هایی نه
مناسب
تیم‌های نرم‌افزاری‌ای که محصولی می‌سازند و پشتیبانیِ مشتریانش را خودشان انجام می‌دهند — آژانس‌ها، استودیوهای محصول و تیم‌های داخلی که برنامه‌نویسی که باگ را درست میکند فقط چند قدم با مشتریِ گزارش‌دهنده فاصله دارد. اگر درخواست‌های پشتیبانیِ شما مرتب به تغییرِ کد ختم میشوند، این زنجیره بیشترِ کارِ دستیِ اطرافِ آن‌ها را حذف میکند.
نه چندان مناسب
یک واحدِ پشتیبانیِ بزرگ و مستقل که بیشترِ تیکت‌ها را بدونِ تیمِ فنی حل میکند، یا تلفن و چتِ زنده، مرکزِ راهنمای چندبرندی یا ماکرو روی هزاران تیکت در روز لازم دارد — یک helpdeskِ تخصصی بهتر به کارش می‌آید. Vi کدِ شما را deploy هم نمی‌کند: زنجیره با کامیت، push و مرحلهی نهاییِ گردشکارتان تمام میشود.
به کدام پلن نیاز دارید؟
Commit & Close و افزونه‌های IDE در همهی پلن‌ها، از جمله Free، در دسترس‌اند. سمتِ مشتریِ زنجیره — ایمیل‌به‌تسک با ایمیلِ دوطرفه‌ی تیکت، صندوقِ triage، پورتالِ مشتری، صفحه‌های وضعیت، پنلِ مشتری و ایمیل‌های خودکار — جزوِ پلنِ Business است. حسابِ مشتری هیچ‌وقت صندلی نمی‌گیرد و ایمیل روی آدرسِ Viِ سازمانتان کار میکند، بدونِ helpdesk یا سرویسِ ایمیلِ بیرونی.
پرسش‌های پرتکرار
آیا Doneِ برنامهنویس به مشتری خبر میدهد؟
نه — Doneِ برنامهنویس فقط مرحلهی خودِ او را در گردشکار تمام میکند و تسک را به مرحلهی بعد میبرد؛ به مشتری فقط وقتی خبر داده میشود که تسک به مرحلهی نهاییِ گردشکار برسد. به این ترتیب مشتری «انجام شد» را بعد از بازبینی و تست میشنود، نه با رسیدنِ اولین کامیت.
آیا مشتری کامیتها یا کد را میبیند؟
نه — مشتری فقط وضعیت و پیشرفتِ درخواست و پاسخهایی را میبیند که تیمتان برایش میفرستد. کامیتها داخلِ تسک و برای تیمتان دیده میشوند، و حتی آنجا هم Vi فقط متادیتای کامیت را نگه میدارد، هرگز سورسکد را.
Commit & Close در کدام IDEها هست؟
Commit & Close همین امروز برای VS Code، Visual Studio، RAD Studio 13 و Lazarus در دسترس است. در هر کدام برنامهنویس تسک را شروع میکند، وقتی سهمش آماده شد Done را می‌زند، و Vi با شمارهی تسک کامیت میکند، اگر ریموتِ Git تعریف شده باشد push میکند و تسک را به مرحلهی بعدیِ گردشکار میبرد.
آیا هر ایمیلی خودکار تسک میشود؟
نه — هر ایمیل، حتی از کسی که در سازمانتان حساب دارد، در صندوقِ ورودی منتظر میماند تا مدیر آن را به تسک یا اپیک تبدیل یا رد کند. مدیر تسک را با کلماتِ تیم می‌نویسد و ایمیلِ اصلی در مکالمه‌ی درخواست میماند.
مشتری چه چیزی میگیرد و آیا حساب لازم دارد؟
مشتری شمارهی پیگیری، صفحهی وضعیتی که بدونِ ورود باز میشود و ایمیل در زمانِ دریافت، انجام یا بستهشدنِ درخواست میگیرد — بدونِ نیاز به حساب یا صندلیِ پولی. اگر بخواهد همهی درخواستهایش را ببیند، پاسخ دهد یا فایل پیوست کند، با لینکِ یکبارمصرفی که به ایمیلش فرستاده میشود واردِ پنلِ مشتری میشود.
این صفحه با صفحهی helpdeskِ Vi چه فرقی دارد؟
صفحهی helpdesk خودِ ابزارهای پشتیبانی را توضیح میدهد — صندوقِ ورودی، triage، CSAT و پاسخهای آماده — و این صفحه یک درخواست را از ابتدا تا انتها دنبال میکند، از IDEِ برنامهنویس و مرحلههای بازبینیِ شما تا بازگشت به مشتری. هر دو یک محصول را توصیف میکنند: درخواستِ پشتیبانی در Vi یک تسک است.
آیا Vi اصلاحیه را روی production هم deploy میکند؟
نه — Vi با کامیت، push و مرحلهی نهاییِ گردشکارتان متوقف میشود و deploy با CI/CDِ فعلیِ شما میماند. اگر انتشار جزوِ فرایندتان است، مرحلهای مثلِ «منتشر شد» را مرحلهی نهاییِ گردشکار بگذارید تا فقط بعد از رسیدنِ اصلاحیه به محیطِ واقعی به مشتری خبر داده شود.
ادامه بدهید: میزِ پشتیبانی و ایمیل‌به‌تسک · Commit & Close چطور کار میکند · امنیتِ سورسکد · اجرای یک پایلوتِ متمرکز · پلن‌ها و قیمت
حلقه را با مشتری ببندید — از درخواست تا کد و برگشت به او
در دو دقیقه رایگان شروع کنید. کارتِ بانکی لازم نیست.
شروعِ رایگان