با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست
ETA را فقط با شواهد بده
شواهد داده قابل مشاهده مانند پیام خطا، Log، نتیجه تست، وضعیت Port یا تنظیمات فعلی هستند؛ هر فرضیه باید با شواهد تأیید یا رد شود حدس و تجربه شخصی مفیدند اما جای شواهد را نمی‌گیرند در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان به‌روزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن نکته‌ای که هنگام پشتیبانی نباید از آن عبور کنی این است که ارتباط حرفه‌ای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤال‌های مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک می‌کند و در صورت استفاده معنای ساده آن را هم روشن کن
اگر زمان حل معلوم نیست زمان Update بعدی را بگو
اگر زمان حل معلوم نیست زمان Update بعدی را بگو اگر زمان حل مشخص نیست زمان اطلاع‌رسانی بعدی را تعهد کن؛ مثلاً «تا ۳۰ دقیقه دیگر وضعیت جدید می‌فرستیم» تا کاربر بدون خبر نماند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان به‌روزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، ارتباط حرفه‌ای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤال‌های مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک می‌کند و در صورت استفاده معنای ساده آن را هم روشن کن
تأخیر را زود اطلاع بده
اگر زمان وعده‌داده‌شده تغییر کرد قبل از تمام شدن آن بازه اطلاع بده، دلیل کوتاه و زمان Update بعدی را مشخص کن؛ سکوت تا بعد از Deadline اعتماد را کم می‌کند در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان به‌روزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که ارتباط حرفه‌ای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤال‌های مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک می‌کند و در صورت استفاده معنای ساده آن را هم روشن کن
وابستگی به Vendor را روشن کن
وابستگی یعنی یک سرویس یا برنامه برای کار کردن به جزء دیگری نیاز دارد؛ توقف جزء پایه می‌تواند چند سرویس ظاهراً نامرتبط را هم‌زمان خراب کند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، ارتباط حرفه‌ای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤال‌های مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک می‌کند و در صورت استفاده معنای ساده آن را هم روشن کن برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان به‌روزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی
قول خارج اختیار نده
اگر حل وابسته به ISP، Vendor یا تیم دیگری است زمان قطعی قول نده؛ زمان پیگیری بعدی را مشخص کن و وضعیت را به‌روز نگه دار برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، ارتباط حرفه‌ای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤال‌های مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک می‌کند و در صورت استفاده معنای ساده آن را هم روشن کن برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان به‌روزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی
فرض کن در ارتباط با کاربر یا مشتری مشکلی گزارش شده و احتمال می‌دهی به مدیریت انتظار و زمان‌بندی مربوط باشد. قبل از تغییر، وضعیت فعلی را با Ticket، یادداشت تماس، ایمیل و سابقه ارتباط بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباه‌ها را تکرار نکن
- حدس و تجربه شخصی مفیدند اما جای شواهد را نمی‌گیرند
- تغییر دادن تنظیمات مرتبط با مدیریت انتظار و زمان‌بندی قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجه‌گیری درباره مدیریت انتظار و زمان‌بندی فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با مدیریت انتظار و زمان‌بندی، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
- با Ticket، یادداشت تماس، ایمیل و سابقه ارتباط وضعیت مرتبط با مدیریت انتظار و زمان‌بندی را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
- یک خطای فرضی مرتبط با مدیریت انتظار و زمان‌بندی بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند
نکته‌هایی که باید با خودت ببری
- ETA را فقط با شواهد بده
- اگر زمان حل معلوم نیست زمان Update بعدی را بگو
- تأخیر را زود اطلاع بده
- وابستگی به Vendor را روشن کن
- قول خارج اختیار نده
- چیزی را که هنوز مطمئن نیستی به‌عنوان نتیجه قطعی به کاربر اعلام نکن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید ETA را فقط با شواهد بدهی و از کجا می‌فهمی نتیجه درست است؟
شواهد داده قابل مشاهده مانند پیام خطا، Log، نتیجه تست، وضعیت Port یا تنظیمات فعلی هستند؛ هر فرضیه باید با شواهد تأیید یا رد شود
این نکته را با یک مثال توضیح بده: اگر زمان حل معلوم نیست زمان Update بعدی را بگو. بعد بگو در عمل چطور آن را بررسی می‌کنی.
اگر زمان حل مشخص نیست زمان اطلاع‌رسانی بعدی را تعهد کن؛ مثلاً «تا ۳۰ دقیقه دیگر وضعیت جدید می‌فرستیم» تا کاربر بدون خبر نماند
چرا باید تأخیر را زود اطلاع بدهی و از کجا می‌فهمی نتیجه درست است؟
اگر زمان وعده‌داده‌شده تغییر کرد قبل از تمام شدن آن بازه اطلاع بده، دلیل کوتاه و زمان Update بعدی را مشخص کن. سکوت تا بعد از Deadline اعتماد را کم می‌کند
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود
