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