مهدی شیشه گر
  • صفحه اصلی
  • دوره‌های آموزشی
  • اخبار و مقالات
  • درباره ما
  • تماس با ما
  • دوره‌های آموزشی
  • اخبار و مقالات
  • درباره ما
  • تماس با ما
@MehdiShishehgar@mehdi.shishehgar_coachinfo@mehdishishehgar.com
مهدی شیشه گر
طراحی شده با ❤️ توسط
    • صفحه اصلی
    • اخبار و مقالات
    • کدام کار را خودکار کنیم؟ شش سؤال پیش از انتخاب ابزار

    ۰۳ آبان ۱۴۰۵

    کدام کار را خودکار کنیم؟ شش سؤال پیش از انتخاب ابزار

    کدام کار را خودکار کنیم؟ شش سؤال پیش از انتخاب ابزار

    نویسنده: مهدی شیشه‌گر

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

    برای بررسی اولیه، یک کار کوچک را انتخاب کنید و مسیر آن را روی کاغذ بنویسید. حاصل این تمرین، شرحی است که می‌توان دربارهٔ اجرای آن با فرد فنی گفت‌وگو کرد. امکان فنی، دسترسی‌ها، هزینه و نحوهٔ آزمون، در مرحلهٔ بعد بررسی می‌شوند.

    ۱. دقیقاً کدام بخش از کار تکرار می‌شود؟

    عبارت‌هایی مانند «پیگیری مشتری» یا «مدیریت درخواست‌ها» چندین کار را در خود پنهان می‌کنند: پیدا کردن درخواست باز، تشخیص وضعیت، نوشتن پیام، انتخاب مخاطب و تصمیم دربارهٔ اقدام بعدی. بهتر است برای شروع، یکی از این بخش‌ها را جدا کنید.

    مثال فرضی: در دفتر هماهنگی یک مجموعهٔ خدمات نصب، مسئول دفتر هر صبح فهرست درخواست‌های باز را مرور می‌کند. پیشنهاد اولیه این است: «پیگیری‌ها را خودکار کنیم.» تعریف محدودتر می‌تواند این باشد: «درخواست‌هایی را که موعد مرورشان رسیده، در فهرست داخلی با برچسب نیازمند مرور مشخص کنیم.»

    این تعریف فقط دربارهٔ نظم دادن به فهرست اداری است. تماس با مشتری، تعیین زمان خدمت و تخصیص نیروی فنی، تصمیم‌های جداگانه‌اند. کوچک کردن دامنه باعث می‌شود بتوانیم دقیق بگوییم دربارهٔ چه کاری تصمیم می‌گیریم.

    ۲. چه رویدادی کار را شروع می‌کند؟

    «هر وقت لازم شد» برای توضیح شروع کافی نیست. کار با رسیدن یک ساعت مشخص آغاز می‌شود؟ با ثبت یک درخواست تازه؟ یا با تصمیم یک نفر و فشردن یک دکمه؟

    این تفاوت در ابزارهای واقعی هم وجود دارد؛ برای نمونه، مستند رسمی Microsoft Learn جریان‌های ابری را از نظر شروع با رویداد، شروع دستی و زمان‌بندی از هم جدا می‌کند. این مثال صرفاً نشان می‌دهد تعریف نقطهٔ شروع، بخشی از طراحی گردش کار است. مرور جریان‌های ابری در Microsoft Learn

    در مثال فرضی ما، شروع می‌تواند «زمان مرور روزانهٔ فهرست» باشد. سپس باید شرط انتخاب ردیف‌ها را بنویسیم: درخواست هنوز باز باشد، موعد مرورش رسیده باشد و مسئولش مشخص باشد. رسیدن ساعت به‌تنهایی نمی‌گوید کدام درخواست باید علامت بخورد.

    ۳. اطلاعات لازم از کجا می‌آید؟

    کنار هر ورودی، مرجع آن را بنویسید. برای مثال فرضی، شناسهٔ درخواست، وضعیت باز یا بسته بودن، موعد مرور و مسئول پیگیری لازم‌اند. اگر وضعیت در دو فایل متفاوت ثبت می‌شود، باید روشن شود کدام مرجع ملاک است و چه کسی آن را به‌روز می‌کند.

    یک سؤال عملی این است: «اگر این خانه خالی یا قدیمی باشد، چه کنیم؟» پاسخ نباید این باشد که برای کامل شدن جدول، مقدار دلخواه بگذاریم. می‌توانیم همان ردیف را به فهرست «نیازمند تکمیل اطلاعات» بفرستیم و مسئول پاسخ را مشخص کنیم.

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

    ۴. چه چیزی تغییر می‌کند و از کجا می‌فهمیم انجام شده؟

    اقدام را با فعل روشن بنویسید: «برچسب اضافه شود»، «پیش‌نویس ساخته شود» یا «یادآوری داخلی ثبت شود». عبارت «پیگیری انجام شود» معلوم نمی‌کند چه اتفاقی باید بیفتد.

    در مثال فرضی، خروجی فقط برچسب «نیازمند مرور» روی همان درخواست است. نشانهٔ انجام این مرحله، وجود برچسب روی ردیف درست است. پاسخ مشتری یا پایان خدمت، نتیجهٔ این اقدام محسوب نمی‌شود.

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

    ۵. چه زمانی باید توقف کند؟

    پیش از اجرای واقعی، مسیرهای خارج از حالت معمول را بنویسید. در مثال فرضی:

    • اگر درخواست بسته شده، برچسب مرور تازه ثبت نشود.
    • اگر مسئول معلوم نیست، ردیف برای تعیین مسئول کنار گذاشته شود.
    • اگر برچسب از قبل وجود دارد، برچسب تکراری ساخته نشود.
    • اگر وضعیت دو مرجع با هم فرق دارد، اختلاف برای بررسی انسانی ثبت شود.

    همهٔ استثناها را نمی‌توان از ابتدا پیش‌بینی کرد. مهم این است که برای وضعیت نامعلوم، قاعده‌ای داشته باشیم: ادامهٔ حدسی مجاز است یا باید متوقف شد؟ چه کسی دربارهٔ ادامه تصمیم می‌گیرد؟ این سؤال را در شرح کار بی‌پاسخ نگذارید.

    ۶. چه کسی مسئول بازبینی است؟

    خودکار شدن یک مرحله، مالکیت آن را حذف نمی‌کند. یک نقش مشخص باید بتواند دربارهٔ ورودی اشتباه، خروجی نامنتظره و تغییر قواعد پاسخ بدهد. در شرح کار، نام نقش را بنویسید؛ مثلاً «مسئول هماهنگی»، نه عبارت مبهم «تیم مربوطه».

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

    کاربرگ یک کار کوچک

    این جمله را برای یکی از کارهای تکراری کسب‌وکارتان کامل کنید:

    وقتی «رویداد شروع» رخ داد، با استفاده از «ورودی و مرجع آن»، فقط «اقدام مشخص» انجام شود. نشانهٔ انجام آن «خروجی قابل‌بررسی» است. اگر «استثنا یا دادهٔ نامعلوم» وجود داشت، کار متوقف شود و «نقش مسئول» تصمیم بگیرد.

    سپس کنار آن، دو خط اضافه کنید: این مرحله چه چیزی را ثابت نمی‌کند؟ اجرای واقعی آن هنوز به چه بررسی‌ای نیاز دارد؟

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

    برای شروع گفت‌وگوی کوچینگ دربارهٔ نظم کارها، همین برگهٔ یک‌صفحه‌ای را همراه داشته باشید: یک کار، یک نقطهٔ شروع و یک اقدام بعدیِ روشن.

    مطالعهٔ مرتبط: نتیجهٔ آزمون را ثبت کن؛ تصمیم‌گیری بدون داستان‌سازی.

    برای هماهنگی گفت‌وگو دربارهٔ همین موضوع، از صفحهٔ تماس مهدی شیشه‌گر استفاده کنید.

    دیدگاه کاربران