از کار مجدد متنفر هستید؟ در اینجا راه حل صفر خطا است

دوباره کاری به ندرت از جایی شروع می شود که کسی اشتباهی را برطرف می کند. خیلی زودتر شروع می‌شود، وقتی درخواستی نامشخص است، فایلی قدیمی است یا تصمیمی در صندوق ورودی یک نفر باقی می‌ماند. من دیده ام که تیم ها ساعت ها را صرف تصحیح کارهایی می کنند که می توانست در ابتدا با یک بررسی کوتاه انجام شود. یک طراح از یک بریف محصول قدیمی استفاده می کند. یک تامین کننده نقشه ای را بدون آخرین اندازه گیری ها دریافت می کند. یک مدیر پیش نویس را بدون بررسی نیاز مشتری تأیید می کند. تیم به جلو حرکت می کند، سپس به عقب برمی گردد. هزینه بیشتر از نیروی کار اضافی است. دوباره کاری می تواند تحویل را به تاخیر بیندازد، بین تیم ها تنش ایجاد کند و مشتریان را در مورد فرآیند زیر سوال ببرد. یک فرآیند عملی پیشگیری از دوباره کاری قبل از شروع تولید، نوشتن، طراحی یا تحویل آغاز می شود. ### 1. درخواست را به یک خلاصه واضح تبدیل کنید یک درخواست کوتاه مانند "آن را حرفه ای تر کنید" فضای زیادی برای قضاوت شخصی باقی می گذارد. من خلاصه ای را ترجیح می دهم که پاسخ دهد: - چه چیزی باید ایجاد یا تغییر شود؟ - چه کسی از آن استفاده خواهد کرد؟ - چه مشکلی را باید حل کند؟ - چه فرمتی مورد نیاز است؟ - چه اطلاعاتی باید گنجانده شود؟ - چه کسی تایید می کند؟ - چه زمانی کار مورد نیاز است؟ - تیم باید از چه محدودیت هایی پیروی کند؟ خلاصه لازم نیست طولانی باشد. نیاز به حذف حدس و گمان دارد. به عنوان مثال، یک درخواست محتوا ممکن است شامل مخاطبان هدف، عبارت جستجوی اصلی، هدف صفحه، طول ترجیحی، لحن، حقایق محصول و مخاطب تایید باشد. درخواست طراحی ممکن است شامل ابعاد، نوع فایل، رنگ های برند، کانال استفاده و مواد مرجع باشد. هنگامی که این جزئیات در ابتدا ظاهر می شوند، تیم یک نقطه مرجع مشترک دارد. ### 2. قبل از شروع کار، معنی را تأیید کنید تأیید سریع می تواند از چرخه تصحیح طولانی جلوگیری کند. من از یک پیام ساده استفاده می‌کنم: "درک من از این درخواست است: [خلاصه مختصر]. [خروجی] را برای [مخاطبان] در [قالب] ارائه می‌دهم. نقطه تایید [شخص یا تیم] است. لطفاً تأیید کنید که این جزئیات درست است." این مرحله به خوبی کار می کند زیرا به درخواست کننده فرصتی برای اصلاح جهت قبل از صرف زمان برای اجرا می دهد. یک تیم نرم افزاری کوچک از این رویکرد برای داشبورد مشتری استفاده کردند. درخواست اصلی «اطلاعات فروش ماهانه» را درخواست کرد. تیم فرض کرد که این به معنای فروش کل ماهانه است. مشتری می خواست فروش بر اساس منطقه و دسته بندی محصول تقسیم شود. تفاوت در مرحله تأیید آشکار شد، نه پس از توسعه. ### 3. برای آخرین اطلاعات از یک منبع استفاده کنید. Rework اغلب زمانی ظاهر می شود که افراد از نسخه های مختلف یک فایل کار می کنند. یک تیم ممکن است این موارد را داشته باشد: - یک پیش نویس ذخیره شده در لپ تاپ - یک فایل اصلاح شده در ایمیل - یک نظر در داخل یک ابزار پروژه - یک سند با ظاهر نهایی در یک پوشه مشترک این تنظیم خطاها را آسان می کند. یک مکان اصلی را برای پرونده ها و تصمیمات تأیید شده انتخاب کنید. به هر فایل یک نام واضح با پروژه، نسخه و تاریخ بدهید. به جای گذاشتن فایل های قدیمی در کنار نسخه فعلی، آنها را به عنوان بایگانی شده علامت گذاری کنید. یک الگوی نام‌گذاری ساده می‌تواند به شما کمک کند: ProjectName_DocumentType_V02_2025-03-08 قالب دقیق کمتر از هر بار استفاده از آن اهمیت دارد. ### 4. یک نقطه بازبینی قبل از تولید کامل تعیین کنید لازم نیست که بازبینی فقط پس از تکمیل کل کار انجام شود. برای یک صفحه وب سایت، قبل از نوشتن تمام نسخه، طرح کلی را مرور کنید. برای برچسب محصول، پیش نویس طرح را قبل از چاپ بررسی کنید. برای یک ویژگی نرم افزاری، قبل از ساختن هر صفحه، جریان کاربر را بررسی کنید. این یک نقطه بازرسی کوچک ایجاد می کند در حالی که انجام تغییرات هنوز آسان است. بررسی باید بر روی جهت تمرکز کند، نه ترجیحات جزئی. بپرسید: - آیا این مشکل بیان شده را حل می کند؟ - آیا اطلاعات کامل است؟ - آیا ساختار با کاربری مورد نظر مطابقت دارد؟ - آیا خطراتی وجود دارد که نیاز به توجه دارد؟ - قبل از مرحله بعدی چه چیزی باید تغییر کند؟ بررسی زودهنگام تیم را از صیقل دادن کار اشتباه باز می دارد. ### 5. تغییرات مورد نیاز را از ترجیحات شخصی جدا کنید، هر نظر وزن یکسانی ندارد. تغییر مورد نیاز ممکن است شامل اندازه گیری نادرست، گم شدن اطلاعات مشتری، عبارت قانونی اشتباه یا قالبی باشد که قابل استفاده نباشد. ترجیح ممکن است شامل رنگ، انتخاب کلمه، سبک چیدمان یا سلیقه شخصی باشد. وقتی این نظرات با هم ترکیب می‌شوند، تیم‌ها می‌توانند زمان زیادی را صرف تغییر جزئیات کنند در حالی که مشکل اصلی را از دست می‌دهند. پیشنهاد می‌کنم بازخورد را به‌صورت زیر برچسب‌گذاری کنید: - الزامی - توصیه شده - اختیاری - لازم نیست. همچنین به بازبین کمک می‌کند توضیح دهد که چرا تغییر درخواست شده است. ### 6. مسئولیت تایید را به یک نفر بسپارید. چندین تصمیم گیرنده نهایی می توانند تاخیر ایجاد کنند. یک نفر را برای جمع‌آوری بازخورد و تأیید مسیر تأیید شده تعیین کنید. سایر اعضای تیم همچنان می توانند کار را بررسی کنند، اما نظرات آنها باید از طریق فرآیند توافق شده عبور کند. این دستورالعمل‌های متناقض را کاهش می‌دهد، مانند: - یک نفر نسخه کوتاه‌تر را درخواست می‌کند - شخص دیگری جزئیات بیشتری را می‌پرسد - شخص سوم مخاطبان هدف را تغییر می‌دهد یک مالک تایید منفرد بحث را حذف نمی‌کند. به بحث یک نقطه پایانی واضح می دهد. ### 7. یک رکورد تغییر کوتاه نگه دارید لازم نیست رکورد تغییر مانند یک گزارش بزرگ به نظر برسد. این می تواند شامل موارد زیر باشد: - چه چیزی تغییر کرده است - چه کسی آن را درخواست کرده است - چرا تغییر کرده است - کدام نسخه حاوی تغییر است - چه کسی آن را تایید کرده است. به جای تکیه بر حافظه، تیم می تواند تصمیم را بررسی کند. همچنین مشکلات مکرر را آشکار می کند. اگر همان مشخصات محصول مدام تغییر کند، ممکن است اطلاعات منبع نیاز به بررسی داشته باشد. اگر مشتریان اغلب همان جزئیات گمشده را درخواست می‌کنند، ممکن است فرم پذیرش نیاز به به‌روزرسانی داشته باشد. ### 8. بررسی انتقال اشتباهات بسیاری زمانی رخ می دهد که کار از یک فرد یا بخش به دیگری منتقل می شود. قبل از تحویل کار، تأیید کنید: - فایل فعلی پیوست یا پیوند شده است - دستورالعمل‌ها کامل است - سؤالات باز فهرست شده است - تأییدیه‌های مورد نیاز گنجانده شده است - نفر بعدی می‌داند چه چیزی را باید بررسی کند. یک یادداشت تحویل کوتاه می‌تواند از سردرگمی جلوگیری کند: «لطفاً از نسخه 3 برگه محصول استفاده کنید. ابعاد در صفحه دو به‌روزرسانی شد. فایل بسته‌بندی را از نسخه چاپی مدیر برنامه بررسی کنید. آن پیام به فرد بعدی زمینه مفیدی می‌دهد بدون اینکه او را مجبور به جستجو در مکالمات قدیمی کند. ### 9. منبع اصلاحات مکرر را مطالعه کنید هنگامی که دوباره کاری اتفاق می افتد، تعمیر خروجی ممکن است روند را برطرف نکند. بپرسید چه چیزی باعث اصلاح شد: - آیا درخواست اصلی مبهم بود؟ - آیا تیم از فایل قدیمی استفاده کرده است؟ - آیا داور خیلی دیر درگیر شد؟ - آیا دو نفر دستورات متناقضی دادند؟ - آیا یک الزام در چک لیست وجود نداشت؟ - آیا کار از سیستم های زیادی عبور کرد؟ یک رکورد کوچک از این علل می تواند الگوها را در طول زمان نشان دهد. به عنوان مثال، یک شرکت خدماتی ممکن است متوجه شود که اکثر اصلاحات صورتحساب از گم شدن شماره های سفارش خرید ناشی می شود. پاسخ ممکن است یک فرم دریافت واضح تر باشد، نه بررسی بیشتر در مرحله مالی. ### یک گردش کار ساده که می توانم قبل از شروع کار استفاده کنم: 1. درخواست را با عبارات واضح بنویسید. 2. هدف، مخاطب، قالب و مالک تایید را تأیید کنید. 3. آخرین فایل های منبع را در یک مکان مشترک قرار دهید. 4. الزامات و محدودیت ها را فهرست کنید. 5. در مورد یک نقطه بررسی اولیه به توافق برسید. در حین کار: 1. از اطلاعات تایید شده استفاده کنید. 2. تصمیمات جدید را ثبت کنید. 3. قبل از ایجاد تغییرات عمده نکات نامشخص را مطرح کنید. 4. قبل از تکمیل هر جزئیات، جهت را مرور کنید. قبل از تحویل: 1. خروجی را با بریف بررسی کنید. 2. تأیید کنید که نسخه صحیح در حال ارسال است. 3. نظرات باز را حل کنید. 4. تایید را ثبت کنید. Rework را نمی توان از هر پروژه حذف کرد. افراد نیازهای خود را تغییر می دهند، اطلاعات جدیدی ظاهر می شود و برخی از مسائل تنها در حین استفاده قابل مشاهده خواهند بود. هدف جلوگیری از دوباره کاری غیرقابل اجتناب است. پاک کردن درخواست‌ها، فایل‌های به اشتراک‌گذاشته‌شده، بررسی‌های اولیه و مراحل تأیید تعریف‌شده به تیم‌ها فرصت بهتری می‌دهد تا قبل از گران شدن تصحیح، کار را درست انجام دهند.

انجام درست پروژه در بار اول بیشتر از زمان صرفه جویی می کند. همچنین هزینه های اضافی، جزئیات از دست رفته، فشار تیم و ناامیدی مشتری را کاهش می دهد. من دیده ام که پروژه های زیادی کند شده اند زیرا تیم قبل از مشخص شدن هدف شروع به کار کرده است. یک سوء تفاهم کوچک در ابتدا به یک تغییر بزرگ تبدیل شد. طرح باید به روز می شد، محتوا باید بازنویسی می شد و تاریخ تحویل تغییر می کرد. یک فرآیند بهتر قبل از شروع کار شروع می شود. ## با هدف واقعی شروع کنید من یک سوال ساده می پرسم: "این کار باید به مشتری کمک کند تا به چه چیزی دست یابد؟" پاسخ باید واضح و قابل اندازه گیری باشد. ممکن است یک مشتری بگوید، "من به وب سایت بهتری نیاز دارم"، اما این عبارت می تواند چندین چیز داشته باشد: - درخواست های تماس بیشتر - رزرو آنلاین آسان تر - اطلاعات بهتر محصول - بارگذاری صفحه سریع تر - تصویر واضح تر از برند هر هدف منجر به یک برنامه متفاوت می شود. بدون این مرحله، یک تیم ممکن است زمانی را صرف بهبود بخش هایی از پروژه کند که مشکل اصلی را حل نمی کند. به عنوان مثال، یک شرکت تعمیر محلی ممکن است فکر کند که به یک وب سایت جدید نیاز دارد. پس از یک بحث کوتاه، مشکل واقعی ممکن است این باشد که بازدیدکنندگان نمی توانند شماره تلفن یا منطقه خدمات را پیدا کنند. یک ساختار صفحه ساده و بخش تماس واضح ممکن است بیش از یک طراحی مجدد کامل کمک کند. ## الزامات را به صورت کتبی بنویسید دستورالعمل های شفاهی به راحتی فراموش می شوند یا اشتباه می شوند. من ترجیح می دهم جزئیات کلیدی را در یک خلاصه پروژه کوتاه ثبت کنم. خلاصه می تواند شامل موارد زیر باشد: - هدف پروژه - مخاطبان هدف - خدمات یا محصولات اصلی - صفحات یا ویژگی های مورد نیاز - لحن و سبک ترجیحی - فرمت تحویل - روند بررسی - محدودیت های شناخته شده، مانند بودجه یا مواد موجود، سند نیازی به طولانی بودن ندارد. باید روشن شود. یک مشتری یک بار محتوای وب سایت "دوستانه و حرفه ای" را درخواست کرد. این کلمات برای مشتری و نویسنده معانی متفاوتی داشتند. مشتری جملات کوتاه و مستقیم می خواست. نویسنده از سبک تجاری رسمی استفاده کرده است. یک پاراگراف نمونه کوتاه در ابتدا لحن مورد انتظار را نشان می داد و از بازنویسی کامل اجتناب می کرد. ## قبل از انتخاب پیام، مخاطب را بررسی کنید کار خوب با یک گروه واقعی از مردم صحبت می کند، نه با همه. من به سوالات مخاطبان نگاه می کنم: - سوالات متداول - نگرانی های خرید - سطح دانش - زبان ترجیحی - دلایل تاخیر در تصمیم گیری - مرحله بعدی مورد انتظار یک محصول فنی ممکن است به توضیحات ساده برای کاربران جدید نیاز داشته باشد. خدماتی برای متخصصان آموزش دیده ممکن است به جزئیات بیشتری نیاز داشته باشد. پیام یکسان نمی تواند به هر دو گروه به خوبی ارائه شود. تحقیق واضح در مورد مخاطب نیز به جلوگیری از ادعاهای پوچ کمک می کند. به جای اینکه بگویم «خدمات ما بهترین انتخاب است»، می‌توانم توضیح دهم که چگونه کار می‌کند، چه کسانی ممکن است از آن سود ببرند، و مشتری باید چه انتظاری داشته باشد. ## یک طرح ساده بسازید یک طرح به کار مسیر روشنی می دهد. من معمولا آن را به مراحل کوچک تقسیم می کنم: 1. جمع آوری اطلاعات 2. تایید هدف اصلی 3. ایجاد ساختار 4. تهیه پیش نویس یا نمونه 5. بررسی جزئیات 6. ایجاد تغییرات توافق شده 7. بررسی نسخه نهایی 8. ارائه کار تمام شده این رویکرد یافتن مشکلات را آسان تر می کند. اگر ساختار اشتباه است، می توانم قبل از نوشتن هر صفحه آن را برطرف کنم. اگر مخاطب نامشخص است، می توانم قبل از ایجاد تبلیغات یا توضیحات محصول به آن بپردازم. یک بررسی کوتاه در هر مرحله اغلب ساده تر از یک بررسی بزرگ در پایان است. ## جزئیاتی را که بر نتیجه تأثیر می گذارد تأیید کنید برخی از جزئیات کوچک به نظر می رسند اما می توانند کل پروژه را تغییر دهند. بررسی می‌کنم: - نام‌ها و جزئیات تماس صحیح - اندازه‌های محصول، قیمت‌ها یا مناطق خدماتی - رنگ‌های برند و فایل‌های لوگو - حقوق تصویر - انواع فایل‌های مورد نیاز - نمایش تلفن همراه - عبارات جستجویی که با مخاطبان مطابقت دارند - پیوندها و تنظیمات فرم یک شرکت ممکن است یک شماره تلفن قدیمی را در پیش‌نویس خود ارائه دهد. اگر کسی آن را بررسی نکند، صفحه تمام شده می تواند مشتریان را به نقطه تماس اشتباهی بفرستد. بررسی سریع جزئیات از کار و تجربه مشتری محافظت می کند. ## از یک نمونه قبل از تولید کامل استفاده کنید یک نمونه به هر دو طرف کمک می کند جهت را ببینند. برای محتوا، ممکن است یک صفحه یا یک بخش کوتاه آماده کنم. برای طراحی، ممکن است یک صفحه نمایش را نشان دهم. برای یک کمپین بازاریابی، ممکن است یک گروه کوچک از پیام های نمونه ایجاد کنم. نمونه می تواند به سوالات عملی پاسخ دهد: - آیا لحن مناسب است؟ - آیا دنبال کردن چیدمان آسان است؟ - آیا سطح جزئیات درست است؟ - آیا پیام با مخاطب مطابقت دارد؟ - آیا فراخوان ها برای اقدام واضح هستند؟ این مرحله به مشتری این فرصت را می دهد که در حالی که تغییرات هنوز قابل مدیریت هستند، پاسخ دهد. ## یک فرآیند بررسی واضح ایجاد کنید. ممکن است یک نفر تیتر کوتاه را ترجیح دهد در حالی که دیگری جزئیات بیشتری را بخواهد. سپس پروژه در جهات مختلف حرکت می کند. من توصیه می کنم یک مخاطب اصلی را انتخاب کنید. آن شخص می تواند بازخورد جمع آوری کند و یک لیست توافق شده از تغییرات را ارسال کند. بازخورد مفید به بخش خاصی از کار اشاره می کند: - "منطقه خدمات گم شده است." - "لطفا از عنوان کوتاه تر استفاده کنید." - این جمله زمان تحویل را توضیح نمی دهد. - "تصویر محصول را به وضوح نشان نمی دهد." نظراتی مانند "من آن را دوست ندارم" به تیم اطلاعات کافی برای ایجاد یک تغییر مفید نمی دهد. ## فضا را برای چک نهایی بگذارید چک نهایی با بازنویسی کامل یکسان نیست. این یک بررسی دقیق از کار تمام شده است. من محتوا را از دیدگاه مشتری بررسی می کنم: - آیا می توانم به سرعت پیشنهاد را درک کنم؟ - آیا می توانم مرحله بعدی را پیدا کنم؟ - آیا حقایق درست است؟ - آیا صفحه روی گوشی کار می کند؟ - آیا لینک ها فعال هستند؟ - آیا عبارت با نام تجاری مطابقت دارد؟ - آیا اشکال املایی یا قالب بندی وجود دارد؟ من هم کار را با صدای بلند خواندم. برخی از جملات روی صفحه نمایش خوب به نظر می رسند اما هنگام گفتن نامشخص به نظر می رسند. این عادت ساده می تواند کلمات تکراری، عبارات طولانی و اطلاعات از دست رفته را آشکار کند. ## از هر اصلاحی بیاموزید یک اصلاح زمانی مفید است که پروژه بعدی را بهبود بخشد. اگر مشتری اغلب متن کوتاه‌تری را درخواست می‌کند، می‌توانم تنظیمات برگزیده طول را در خلاصه بنویسم. اگر جزئیات محصول اغلب وجود ندارد، می توانم یک فرم اطلاعات استاندارد تهیه کنم. اگر تأییدها بیش از حد طول بکشد، می توانم قبل از شروع کار در مورد تاریخ های بازبینی توافق کنم. این امر مشکلات مکرر را به عادات کاری بهتر تبدیل می کند. درست کردن آن در بار اول به معنای عدم ایجاد تغییر نیست. کار خوب هنوز نیاز به بررسی دارد. هدف جلوگیری از اشتباهات قابل اجتناب، دستورالعمل های نامشخص و غافلگیری دیرهنگام است. وقتی هدف را تعریف می کنم، الزامات را ثبت می کنم، نمونه ای را آزمایش می کنم و جزئیات را قبل از تحویل بررسی می کنم، مدیریت پروژه آسان تر می شود. مشتری می داند که باید چه انتظاری داشته باشد و تیم می تواند به جای ترمیم خطاهای قابل پیشگیری، روی خلق کارهای مفید تمرکز کند.

اشتباهات کوچک می توانند کل پروژه را کند کنند. یک شماره از دست رفته در یک گزارش، یک پیوند شکسته در یک ایمیل، یا یک جمله نامشخص در صفحه محصول ممکن است منجر به تجدید نظرهای اضافی و از دست دادن اعتماد شود. دریافته ام که بیشتر اشتباهات ناشی از کمبود مهارت نیست. آنها اغلب زمانی ظاهر می شوند که افراد بدون یک فرآیند بررسی ساده کار می کنند. یک گردش کار واضح به من کمک می کند تا قبل از اینکه کار به مشتری، مدیر یا مشتری برسد، مشکلات را تشخیص دهم. همچنین استرس ناشی از بررسی مجدد همان فایل را کاهش می دهد. من با تعریف اینکه کار باید به چه چیزی برسد شروع می کنم. قبل از نوشتن، ویرایش یا بررسی یک فایل، از خودم می پرسم: - چه کسی آن را خواهد خواند؟ - خواننده چه اقدامی باید انجام دهد؟ - کدام حقایق، اعداد یا پیوندها باید دقیق باقی بمانند؟ - فایل نهایی به چه فرمتی نیاز دارد؟ - چه چیزی می تواند باعث سردرگمی شود؟ این سوالات به من یک چک لیست اساسی می دهد. بدون این مرحله، ممکن است زمانی را صرف تصحیح جزئیات کوچک کنم و در عین حال مشکل بزرگتری را از دست بدهم، مانند پیام نامشخص یا اطلاعات از دست رفته. من خلقت را از بررسی جدا می کنم. وقتی همزمان می نویسم و ​​ویرایش می کنم، اغلب یک جمله را چندین بار تغییر می دهم بدون اینکه آن را اصلاح کنم. توجه من بین ایده‌ها، گرامر، طرح‌بندی و واقعیت‌ها حرکت می‌کند. این باعث می شود که خطاهای کوچک راحت تر از دست بروند. من به جای آن از دو پاس استفاده می کنم: 1. من پیش نویس کامل را می نویسم و ​​روی پیام تمرکز می کنم. 2. من پیش نویس را با چک لیست جداگانه بررسی می کنم. در اولین پاس، برای هر مسئله املایی متوقف نمی شوم. در طول بررسی، من از نزدیک به عبارت، اعداد، پیوندها، قالب بندی و لحن نگاه می کنم. این روش برای بسیاری از انواع کارها، از جمله پست‌های وبلاگ، ایمیل‌های فروش، گزارش‌ها، توضیحات محصول و پاسخ‌های مشتری، به خوبی کار می‌کند. من حقایق را در یک مکان بررسی می کنم. کپی کردن اطلاعات از چندین تب می تواند اشتباهاتی ایجاد کند. ممکن است قیمت تغییر کند، نام محصول ممکن است املای متفاوتی داشته باشد، یا ممکن است یک فایل قدیمی حاوی جزئیات قدیمی باشد. من اطلاعات منبع را در یک سند یا سیستم تایید شده نگه می دارم. سپس پیش نویس را با آن منبع مقایسه می کنم. برای صفحه محصول، ممکن است بررسی کنم: - نام محصول - شماره مدل - ویژگی های اصلی - قیمت - جزئیات تحویل - اطلاعات گارانتی - جزئیات تماس - پیوندها یک مثال ساده یک فروشگاه آنلاین است که توضیحات محصول را به روز می کند. نویسنده ممکن است نام صحیح محصول را کپی کند اما از زمان تحویل قدیمی از صفحه قبلی استفاده کند. متن می تواند صیقلی به نظر برسد در حالی که هنوز اطلاعات اشتباهی را به مشتریان می دهد. بررسی منبع به جلوگیری از این نوع مشکل کمک می کند. من اعداد را با دقت بیشتری بررسی می کنم. اعداد به بررسی خاص خود نیاز دارند زیرا یک کاراکتر کوچک می تواند معنی را تغییر دهد. من به موارد زیر نگاه می کنم: - تاریخ ها - قیمت ها - درصدها - اندازه گیری ها - شماره های سفارش - شماره تلفن ها - آدرس های ایمیل - مراجع صفحه من به جای اسکن کردن کل پاراگراف، هر عدد را به آرامی می خوانم. اگر گزارشی شامل محاسبات باشد، ارقام اصلی و نتیجه نهایی را بررسی می‌کنم. یک صفحه گسترده می تواند کمک کند، اما من همچنان فرمول ها و برچسب ها را بررسی می کنم. ابزارها از فرآیند پشتیبانی می کنند. آنها جایگزین قضاوت نمی شوند. متن را با صدای بلند خواندم. خواندن با صدای بلند به من کمک می‌کند جملاتی را پیدا کنم که درست به نظر می‌رسند اما ناخوشایند به نظر می‌رسند. همچنین نشان می دهد که خواننده ممکن است در کجا مکث کند، یک نکته را اشتباه متوجه شود یا مسیر پیام را از دست بدهد. برای مثال، این جمله ممکن است از نظر گرامری صحیح باشد: «مشتریان می‌توانند پس از بررسی دستورالعمل‌های صفحه حساب، از تیم پشتیبانی درخواست تعویض کنند.» یک نسخه واضح‌تر ممکن است این باشد: «مشتریان می‌توانند دستورالعمل‌های صفحه حساب را بررسی کنند و برای درخواست جایگزینی با پشتیبانی تماس بگیرند». نسخه دوم مسیر مستقیم تری را به خواننده می دهد. من فایل را همانطور که خواننده می بیند بررسی می کنم. ممکن است یک سند در ویرایشگر خوب به نظر برسد اما پس از صادرات، آپلود یا انتشار متفاوت به نظر برسد. نسخه نهایی را باز می‌کنم و بررسی می‌کنم: - سرفصل‌ها - فاصله‌ها - تصاویر - طرح‌بندی موبایل - دکمه‌ها - پیوندها - جداول - شکستگی‌های صفحه - نام فایل‌ها روی هر پیوند مهم کلیک می‌کنم. در صورت امکان فرم ها را تست می کنم. اگر محتوا در دستگاه های تلفن همراه مشاهده شود، صفحه را در تلفن باز می کنم. این مرحله اغلب مشکلاتی را آشکار می کند که در پیش نویس نامرئی هستند. من از ابزارهایی با محدودیت های مشخص استفاده می کنم. املا می تواند بسیاری از خطاهای تایپی را پیدا کند. ابزارهای گرامر می توانند تغییراتی را پیشنهاد دهند. جستجوگرهای پیوند می توانند URL های شکسته را شناسایی کنند. تاریخچه نسخه می تواند نشان دهد چه کسی و چه زمانی یک فایل را تغییر داده است. من هر پیشنهاد را به عنوان یک تصمیم فوری و نه یک تصمیم نهایی در نظر می‌گیرم. یک ابزار ممکن است یک نام تجاری را تغییر دهد، یک اصطلاح فنی را حذف کند یا معنای یک جمله را تغییر دهد. من تغییرات پیشنهادی را قبل از پذیرش آنها بررسی می کنم. من همچنین یک گزارش خطای کوتاه نگه می دارم. هر بار که یک مشکل تکراری پیدا می کنم، آن را به لیست اضافه می کنم. چک لیست من ممکن است شامل موارد زیر باشد: - نام ها و اعداد را بررسی کنید - تاریخ ها را تأیید کنید - پیوندهای تست را - عناوین را مرور کنید - پاراگراف ابتدایی را با صدای بلند بخوانید - فایل را در موبایل بررسی کنید - نسخه نهایی را با منبع مقایسه کنید این لیست به مرور زمان مفیدتر می شود زیرا اشتباهات واقعی کار من را نشان می دهد. یک فرآیند بررسی قابل اعتماد نیازی به پیچیده نیست. من هدف را تعریف می کنم، پیش نویس را ایجاد می کنم، حقایق را با یک منبع قابل اعتماد مقایسه می کنم، اعداد را بررسی می کنم، قالب نهایی را آزمایش می کنم و نتیجه را از دید کاربر می خوانم. هدف این نیست که هر کاری کند جلوه کند. هدف این است که مشکلات قابل اجتناب را قبل از ایجاد کار بیشتر شناسایی کنید. چند بررسی متمرکز می‌تواند از کیفیت گزارش، صفحه وب، ایمیل یا پیام مشتری محافظت کند و در عین حال مدیریت کل فرآیند را آسان‌تر کند.

بسیاری از تیم ها زمان زیادی را صرف رفع مشکلات مشابه می کنند. به روز رسانی از دست رفته منجر به پیگیری مشتری می شود. لینک فایل خراب پروژه را کند می کند. یک کار بدون مالک مشخص در صندوق ورودی کسی می نشیند. کار تمام می شود، اما همین موضوع چند روز بعد بازمی گردد. من قبلاً با این مشکلات به عنوان وقفه های کوچک برخورد می کردم. با گذشت زمان، من این الگو را دیدم: اصلاحات مکرر اغلب به یک فرآیند ضعیف اشاره می کند، نه یک فرد بی دقت. هوشمندانه کار کردن با ساده‌تر کردن کار بعدی و انجام نادرست سخت‌تر شروع می‌شود. با مشکلات مکرر شروع کنید من به مسائلی که بیش از یک بار در هفته ظاهر می شوند نگاه می کنم. بپرسید: - کدام کار نیاز به تصحیح دستی دارد؟ - مردم کجا منتظر اطلاعات هستند؟ - کدام مرحله به یک نفر بستگی دارد؟ - چه سوالی مدام در پیام های تیم ظاهر می شود؟ - کدام فایل، فرم یا سیستم باعث سردرگمی می شود؟ یک رکورد کوچک می تواند چیزهای زیادی را آشکار کند. مشکل، علت آن، زمان صرف شده برای رفع آن و شخصی که تعمیر را انجام می دهد را یادداشت کنید. برای مثال، یک فروشگاه اینترنتی کوچک متوجه شد که به‌روزرسانی‌های سفارش اغلب دیر ارسال می‌شوند. تیم دوره‌های پرمشغله را مقصر می‌دانست، اما علت واقعی صفحه‌گسترده‌ای بود که به چندین بررسی دستی نیاز داشت. تیم برگه را تغییر داد، یک فیلد وضعیت واضح اضافه کرد و یک نقطه بازبینی را قبل از ارسال روزانه تعیین کرد. به روز رسانی های دیرهنگام کمتر رایج شد و کارکنان زمان کمتری را صرف بررسی یک سفارش دو بار کردند. مالکیت را قابل مشاهده کنید یک کار بدون مالک می تواند بین افراد بدون حرکت رو به جلو حرکت کند. من ترجیح می دهم به هر وظیفه تکراری یک مالک واضح بدهم. آن شخص نیازی به تکمیل هر قسمت از کار ندارد. نقش این است که بررسی کنیم که کار دارای یک شروع واضح، یک مرحله بعدی مشخص و یک نتیجه تمام شده است. یک رکورد ساده کار می تواند شامل موارد زیر باشد: - نام وظیفه - شخص مسئول - تاریخ سررسید - اطلاعات مورد نیاز - اقدام بعدی - بررسی تکمیل این ساختار برای بررسی های بازاریابی، بررسی تجهیزات، پاسخ های مشتریان و گزارش های داخلی کار می کند. همچنین پیام‌هایی مانند «چه کسی این کار را انجام می‌دهد؟» را کاهش می‌دهد. یا "آیا کسی فایل را بررسی کرده است؟" از ابزارهای کمتر با قوانین واضح تر استفاده کنید افزودن یک برنامه دیگر همیشه مشکل گردش کار را حل نمی کند. می تواند مکان دیگری برای جستجو ایجاد کند. من سعی می کنم به هر نوع اطلاعات یک خانه بدهم: - وظایف در سیستم وظیفه باقی می مانند. - تصمیمات تیم در پرونده پروژه باقی می ماند. - جزئیات مشتری در سیستم مشتری باقی می ماند. - فایل های به اشتراک گذاشته شده در یک پوشه تایید شده باقی می مانند. این تیم همچنین به یک قانون ساده برای نام‌گذاری فایل‌ها و به‌روزرسانی وضعیت نیاز دارد. پیروی از یک سیستم مفید اغلب ساده تر از یک سیستم غنی از ویژگی است که از مردم می خواهد انتخاب های زیادی داشته باشند. یک تیم طراحی پنج نفره ممکن است نیازی به ابزارهای جداگانه برای چت، وظایف، تاییدیه ها، یادداشت ها و نظرات فایل نداشته باشد. یک تابلوی پروژه مشترک، یک ساختار پوشه، و یک بررسی هفتگی ممکن است بیشتر کار را پوشش دهد. پاسخ‌های رایج را به راهنمایی مشترک تبدیل کنید اگر به یک سؤال سه بار پاسخ دهم، آن را نشانه‌ای از نیاز تیم به راهنمای کتبی می‌دانم. نیازی به طولانی بودن راهنما نیست. یک صفحه مفید می تواند توضیح دهد: 1. چه زمانی از فرآیند استفاده شود 2. چه کسی آن را شروع می کند 3. چه اطلاعاتی مورد نیاز است 4. چه اتفاقی پس از ارسال می افتد 5. کجا درخواست کمک کنیم از زبان ساده استفاده کنید و یک مثال واقعی اضافه کنید. یک عضو جدید تیم باید فرآیند را بدون نشستن در یک جلسه طولانی درک کند. علت را مرور کنید، نه تنها خطا را مرور کنید وقتی مشکلی پیش می‌آید، می‌پرسم چه چیزی باعث شده که خطا ایجاد شود. تأیید مفقود ممکن است از یک فرم نامشخص باشد. آدرس تحویل اشتباه ممکن است از کپی کردن داده ها بین سیستم ها باشد. گزارش تاخیری ممکن است از مهلتی باشد که هیچ کس مالک آن نیست. هدف مقصر دانستن نیست. هدف حذف یک نقطه سردرگمی است. یک بررسی کوتاه می تواند سه سوال را پوشش دهد: - چه اتفاقی افتاد؟ - کجای فرآیند اجازه داد؟ - چه تغییر کوچکی می تواند تکرار را کاهش دهد؟ تغییر ممکن است یک فیلد الزامی، یک چک لیست، یک برچسب واضح تر، یا یک یادآوری در مرحله درست باشد. آزمایش و نگهداری تغییرات کوچک آسان تر است. محافظت از زمان برای بهبود تیم ها اغلب مشغول رفع مشکلات فوری هستند. بدون زمان بهبود برنامه ریزی شده، همان مشکلات در اولویت قرار می گیرند. من یک دوره کوتاه هفتگی را برای بررسی مسائل تکراری اختصاص دادم. این جلسه می تواند 20 دقیقه طول بکشد. ما یک مشکل را انتخاب می کنیم، علت احتمالی آن را پیدا می کنیم و روی یک اقدام توافق می کنیم. اقدام باید دارای مالک و تاریخ بازبینی باشد. اگر تغییر کمک کند، آن را حفظ می کنیم. اگر کار را بدون کاهش خطا اضافه کرد، آن را تنظیم یا حذف می کنیم. این باعث می شود که بهبود فرآیند با کار روزانه مرتبط باشد. این نیازی به یک پروژه بزرگ یا یک جلسه طولانی ندارد. کار مهم را اندازه گیری کنید یک معیار مفید باید به تیم کمک کند تا تصمیم بهتری بگیرد. می‌توانید موارد زیر را ردیابی کنید: - زمان صرف شده برای تصحیح کار - تعداد سؤالات پشتیبانی مکرر - وظایفی که برای جزئیات از دست رفته بازگردانده شده‌اند - تأییدیه‌های تاخیری - درخواست‌های مشتری بازگشایی شده - مراحل دستی در یک فرآیند منظم این ارقام نیازی به تبدیل شدن به یک گزارش پیچیده ندارند. یک مقایسه ساده ماهانه می تواند نشان دهد که آیا تغییر کمک می کند یا خیر. اگر یک چک لیست جدید دو دقیقه به یک کار اضافه کند اما از اصلاحات مکرر جلوگیری کند، ممکن است مفید باشد. اگر بدون بهبود نتیجه زمان اضافه کند، تیم دلیلی برای تغییر آن دارد. دریافته‌ام که کار هوشمندانه‌تر به ندرت از انجام کارهای بیشتر ناشی می‌شود. این از حذف تصمیمات قابل اجتناب، قابل مشاهده کردن مالکیت و رفع علت مشکلات مکرر ناشی می شود. وقتی یک تیم زمان کمتری را صرف تعمیر کار دیروز می کند، توجه بیشتری به مشتریان، برنامه ریزی و ایده های جدید مفید دارد. کار آرام‌تر می‌شود زیرا مردم می‌دانند به کجا نگاه کنند، چه کاری انجام دهند و چه کسی مسئول قدم بعدی است.

خطاها می توانند در هر کاری جابجا شوند. یک عدد از دست رفته، یک نسخه فایل اشتباه، یا یک جمله نامشخص می تواند هزینه های اضافی ایجاد کند و پروژه را کند کند. من هر بار همه چیز را از ابتدا بررسی می کردم، اما اشتباهات کوچک هنوز ظاهر می شد. مشکل کمبود مراقبت نبود. روند بررسی من ترتیب مشخصی نداشت. من اکنون از یک روال ساده بررسی خطا استفاده می کنم. این نوید کار کامل را نمی دهد، اما راهی ثابت برای یافتن و رفع مشکلات بیشتر قبل از رسیدن به مشتری، مدیر یا خواننده به من می دهد. مرحله 1: معنی "درست" را تعریف کنید قبل از اینکه سندی را بررسی کنم، نکاتی را که باید درست باشند فهرست می کنم. برای صفحه محصول، می‌توانم بررسی کنم: - نام محصول - قیمت - گزینه‌های اندازه و رنگ - جزئیات تحویل - اطلاعات تماس - املا و دستور زبان - پیوندها و دکمه‌ها - تصاویر و زیرنویس‌های تصویر این لیست باعث می‌شود که فقط متن قابل مشاهده را بررسی نکنم در حالی که لینک خراب یا جزئیات نادرست را از دست ندهم. یک چک لیست کوتاه بهتر از مجموعه ای طولانی از دستورالعمل های مبهم کار می کند. هر نقطه باید به راحتی به عنوان کامل علامت گذاری شود یا نیاز به بررسی دارد. مرحله 2: قبل از سبک، حقایق را بررسی کنید ** من با حقایق شروع می کنم. یک جمله می تواند نرم به نظر برسد و همچنان حاوی اطلاعات اشتباه باشد. من سند را با منبع اصلی مقایسه می‌کنم، مانند برگه محصول، ایمیل مشتری، لیست قیمت تایید شده یا خلاصه پروژه. نام ها، تاریخ ها، ارقام، اندازه گیری ها و جزئیات تماس را یکی یکی چک می کنم. اعداد نیاز به توجه ویژه دارند. یک نقطه اعشار نابجا می تواند معنای قیمت یا اندازه گیری را تغییر دهد. ارقام را به آرامی می خوانم و به جای اعتماد به حافظه ام، آنها را با منبع مقایسه می کنم. یک عادت مفید، بررسی یک نوع واقعیت در یک زمان است. همه تاریخ ها را با هم مرور می کنم، سپس همه قیمت ها، سپس همه نام ها. این احتمال رد شدن از جزئیات را کاهش می دهد. **مرحله 3: مطالب را به روشی جدید بخوانید پس از بررسی حقایق، محتوا را به عنوان یک خواننده بررسی می کنم. من فقط نمی پرسم: "آیا این جمله صحیح است؟" می پرسم: - آیا خواننده می تواند موضوع اصلی را بفهمد؟ - آیا هر جمله از جمله بعدی پشتیبانی می کند؟ - آیا جزئیات مهمی از دست رفته است؟ - آیا خواننده ممکن است پیشنهاد یا دستورالعمل را اشتباه متوجه شود؟ - آیا صفحه به سؤالی که خواننده را به آنجا رسانده پاسخ می دهد؟ جملات کوتاه زمانی کمک می کند که موضوع کاربردی باشد. جملات طولانی‌تر جای خود را دارند، اما نباید ایده‌های زیادی را به یکباره حمل کنند. به عنوان مثال: "مشتریان می توانند در صورتی که کالا آسیب دیده به دستشان برسد و عکس بسته و محصول را ارائه دهند، ظرف 14 روز درخواست تعویض کنند." این جمله ممکن است دقیق باشد، اما دارای چندین شرط است. یک نسخه واضح تر می تواند این باشد: "مشتریان می توانند ظرف 14 روز درخواست تعویض کنند. اگر کالای آسیب دیده وارد شود، باید عکسی از بسته و محصول ارائه دهند." نسخه دوم مسیر تمیزتری را به خواننده می دهد. مرحله 4: از یک پاس جداگانه برای زبان استفاده کنید من پس از بررسی حقایق و معنی املا، دستور زبان، نقطه گذاری و لحن را بررسی می کنم. مخلوط کردن هر نوع چک در یک پاس می تواند فرآیند را خسته کننده و ناهموار کند. من به دنبال: - کلمات تکراری - مقالات مفقود - زمان فعل نادرست - ضمایر نامشخص - حروف بزرگ ناهموار - فاصله های اضافی - خطاهای نقطه گذاری - جملاتی که خیلی قوی یا مبهم به نظر می رسند همچنین بررسی می کنم که آیا لحن با مخاطب مطابقت دارد یا خیر. صفحه راهنما باید واضح و آرام به نظر برسد. یک صفحه فروش می تواند دوستانه باشد، اما نباید قول هایی بدهد که کسب و کار نتواند از آن پشتیبانی کند. ابزارهایی مانند غلط‌گیر املا و نرم‌افزار دستور زبان می‌توانند به من در تشخیص مشکلات کمک کنند. من با پیشنهادات آنها به عنوان یک اعلان رفتار می کنم، نه پاسخ های خودکار. یک ابزار ممکن است عبارتی را که در زمینه درست است علامت گذاری کند یا یک خطای واقعی را که فقط یک شخص می تواند آن را بفهمد از دست بدهد. مرحله 5: هر نقطه عمل را بررسی کنید ممکن است یک صفحه کامل به نظر برسد در حالی که عملکرد اصلی آن کار نمی کند. من روی هر لینک و دکمه مهم کلیک می کنم. من فرم ها را با اطلاعات نمونه ساده تست می کنم. بررسی می‌کنم که آیا پیام تأیید ظاهر می‌شود و آیا جزئیات ارسال‌شده به جای درست می‌رسند یا خیر. برای فرم رزرو، من این موارد را بررسی می‌کنم: - فیلدهای الزامی - گزینه‌های تاریخ و زمان - پیام‌های خطا - جزئیات تأیید - اعلان‌های ایمیل - نمایشگر تلفن همراه دکمه‌ای که می‌گوید «ارسال» باید نتیجه‌اش را روشن کند. اگر کاربر نداند پس از کلیک روی آن چه اتفاقی می افتد، صفحه به توضیح بهتری نیاز دارد. من یک بار یک صفحه خدمات را بررسی کردم که دارای متن صحیح و تصاویر جذاب بود. فرم تماس باز شد، اما فیلد تلفن فرمت شماره معمولی را رد کرد. بازدیدکنندگان نتوانستند فرم را تکمیل کنند. صفحه نیاز به طراحی جدید نداشت. از نظر کاربر به یک تست ساده نیاز داشت. مرحله 6: طرح بندی را در بیش از یک صفحه مرور کنید متن می تواند در یک نمایشگر بزرگ درست به نظر برسد و خواندن آن در تلفن سخت شود. بررسی می‌کنم: - سرفصل‌ها - فاصله پاراگراف‌ها - اندازه متن - طول خط - محل قرارگیری تصویر - قابلیت مشاهده دکمه‌ها - جداول و فهرست‌ها - بارگیری صفحه موبایل فاصله‌گذاری تمیز به افراد کمک می‌کند اطلاعات را پیدا کنند. یک پاراگراف شلوغ می تواند یک شرط مهم را پنهان کند، حتی اگر هر کلمه درست باشد. وقتی خوانندگان نیاز به اسکن جزئیات دارند، بخش‌های کوتاه، زیرعنوان‌های مفید و فهرست‌ها را ترجیح می‌دهم. این همچنین به موتورهای جستجو کمک می کند تا ساختار صفحه را بدون اجبار کلمات کلیدی در هر پاراگراف درک کنند. مرحله 7: از شخصی بخواهید که یک بررسی متمرکز انجام دهد شخص دوم نیازی به بررسی کل پروژه ندارد. من به آنها یک وظیفه روشن می دهم. به عنوان مثال: "لطفاً همه قیمت ها را در لیست تایید شده بررسی کنید." یا: "لطفاً این را به عنوان یک مشتری جدید بخوانید و به من بگویید دستورالعمل ها در کجا مشخص نیست." یک بررسی متمرکز اغلب مسائلی را پیدا می کند که نویسنده دیگر نمی بیند. آشنایی باعث می شود که مغز کلمات از دست رفته را پر کند و اشتباهات مکرر را نادیده بگیرد. وقتی هیچ همکار در دسترس نباشد، قالب را تغییر می‌دهم. من متن را با صدای بلند می خوانم، آن را چاپ می کنم، یا آن را در دستگاه دیگری مشاهده می کنم. این تغییرات کوچک می تواند خطاهای پنهان شده در صفحه اصلی را آشکار کند. مرحله 8: خطاهای تکراری را ثبت کنید اشتباهاتی را که بیش از یک بار ظاهر می شوند یادداشت می کنم. فهرست من ممکن است شامل موارد زیر باشد: - نام‌های محصول به اشکال مختلف نوشته شده است - تاریخ‌هایی که از فرمت‌های ترکیبی استفاده می‌کنند - فضاهای خالی بعد از نقطه‌گذاری - قیمت‌های قدیمی کپی شده در صفحات جدید - پیوندهایی که به فایل‌های قدیمی اشاره می‌کنند این رکورد به من کمک می‌کند به جای رفع دوباره و دوباره همان مشکل، روند را بهبود بخشم. اگر یک خطا مدام ظاهر می شود، یک مورد چک لیست اضافه می کنم، فایل منبع را به روز می کنم یا یک الگو ایجاد می کنم. الگوها برای کارهای مکرر مفید هستند. آنها تعداد جزئیاتی را که باید از روی حافظه بازسازی کنم کاهش می دهند. من همچنان هر سند جدید را بررسی می‌کنم زیرا یک الگو می‌تواند یک خطای قدیمی را در بسیاری از صفحات حمل کند. یک فرآیند بررسی عملی دارای یک نظم واضح است: 1. جزئیات مورد نیاز را تعریف کنید. 2. حقایق و اعداد را تأیید کنید. 3. معنی و وضوح خواننده را مرور کنید. 4. زبان و لحن را بررسی کنید. 5. پیوندها، فرم ها و دکمه ها را آزمایش کنید. 6. طرح بندی را در صفحه های مختلف مرور کنید. 7. برای بررسی دوم متمرکز بخواهید. 8. مشکلات تکراری را ثبت کنید. من با "صفر خطا" به عنوان یک وعده رفتار نمی کنم. من با آن به عنوان یک هدف کاری برخورد می کنم که بررسی های دقیق را قبل از انتشار یا تحویل تشویق می کند. قوی ترین نتایج معمولاً از یک روال ساده، یک چک لیست کوتاه و فاصله کافی از پیش نویس اصلی به دست می آید تا آن را همانطور که یک خواننده می بیند، ببیند. کار دقیق این نیست که یک صفحه را چندین بار بدون برنامه بخوانید. این در مورد بررسی جزئیات درست در مرحله درست است. برای هر گونه سوال در مورد محتوای این مقاله، لطفا با جو: 594530434@qq.com/WhatsApp +8613812786885 تماس بگیرید.

دبلیو ادواردز دمینگ (1986) خارج از بحران جوزف ام جوران (1992) ژوران در مورد کیفیت توسط طراحی مایکل همر و جیمز چمپی (1993) مهندسی مجدد شرکت دونالد ال کرکپاتریک و جیمز دی کرک پاتریک (2006) ارزیابی برنامه‌های آموزشی (1995) بهبود فرآیندها خط را سریع می کند