عین همین مشکل را می‌توان در تیم‌های برنامه‌نویسی نیز مشاهده کرد. فرض کنید قرار است قاعده‌ای در سطح تیم‌های یک شرکت اجرا شود. مثلاً قرار است من بعد نام متغیرها، کلاس‌ها و… منطبق با یک روش خاص باشد. اگر بخواهیم از سیاست مچ‌گیری استفاده کنیم می‌توانیم اجباری بودن قاعده را اعلام کرده و آن فراموش کرده تا زمانی که یک جایی حسابی گیر افتادیم. مثلاً یک سری باگ‌های ناجور پیدا شده و حین دیباگ آنها متوجه شویم که برنامه‌نویس مربوطه قاعده‌ی مذکور را رعایت نکرده است. آن وقت تازه شروع می‌کنیم به گیر دادن به آن برنامه‌نویس بابت این که چرا قاعده را رعایت نکرده و با استفاده از اسم متغیرهای ناخوانا باعث شده دیباگ برنامه سخت و طولانی شود.
درست است که در سیاست مچ‌گیری همیشه می‌توان مقصر را پیدا کرد و بازخواستش کرد. اما واقعیت این است که این سیاست خوبی برای جا انداختن یک قاعده در یک تیم نیست. در کنار پیدا کردن مقصر و بازخواست وی می‌توان روش‌های دیگری را نیز استفاده کرده تا هم رعایت قانون به صورت یک فرهنگ داوطلبانه در بیاید، هم محیط کار صمیمی‌تری داشت و هم هیچ وقت در موقعیتی گیر نکنیم که تازه بفهمیم چقدر اشتباه وجود داشته و ما تا حالا نفهمیده‌ایم. به عنوان چند مثال از این روش‌ها می‌توان به موارد زیر اشاره کرد:
۱- جلسات آموزشی متعدد و توجیه مفید بودن قاعده برای تیم.
۲- پیگیری‌های روزانه برای رعایت قاعده.
۳- راهنمایی چهره به چهره برای کسب اطمینان از این که افراد مشکلی در اجرای قاعده ندارند.
۴- ثابت قدم بودن در اجرای قاعده. رهرو آن نیست که گه آهسته و گه تند رود. رهرو آن است که آهسته ولی پیوسته برود.
۵- اعمال سیاست‌های تشویقی و تنبیهی.
۶- تطبیق قاعده‌ی مورد نظر با دنیای واقعی و کسب اطمینان از این که اجرای قاعده‌ی مورد نظر باعث نمی‌شود کسی احساس احمق بودن کند.
دیدگاه‌ها
نوشته خیلی جالبی بود مخصوصا این که با مثال جالبی شروع کردید
در رابطه با مثال 5 می بایست به کسی که قواعد را رعایت می کند پاداش داد و به کسی که رعایت نمی کند از مثال شماره 4 استفاده کرد ولی اگر شماره 1 زیاد انجام شود فرد احساس سر خوردگی می کند که به نظر من این عمل بیشتر به صورت مخفی انجام شود بهتر است
@علی اقدم: یعنی جلسات آموزشی به صورت غیر مستقیم برگزار شود؟ چرا؟