در سال ۱۹۵۴، سریل نورتکوت پارکینسون این مفهوم را ارائه داد که «کار به اندازه زمانی که برای آن تخصیص داده شده، طول میکشد»، و اکنون به عنوان قانون پارکینسون شناخته میشود.
اگر ندانید که تنها برخی از مدیران آموزش مدیریتی میبینند، ممکن است فکر کنید آموزشگاهی وجود دارد که همهی آنها برای یک دورهی فشردهی قانون پارکینسون و مشتقات آن به آنجا رفتهاند. حتی مدیرانی که میدانند از مدیریت چیزی نمیدانند، به یک حقیقت بدیهی حاکم بر کارکنان و نگرش آنها نسبت به کار پایبند هستند: قانون پارکینسون. این به آنها اعتقادی قوی میدهد که تنها راه انجام کار، تعیین تاریخ تحویل خوشبینانه و غیرممکن است.
قانون پارکینسون و قانون نیوتن #
قانون پارکینسون تا بدیهی بودن فاصلهی زیادی دارد. به همان معنایی که قانون نیوتن یک قانون است، این یک قانون نیست. نیوتن دانشمند بود. او اثر گرانش را مطابق با سختترین روش علمی بررسی کرد. قانون وی تنها پس از آزمایش و تأیید دقیق ارائه شد. این قانون، چندین قرن مطالعهی بعدی را تاب آورده است.
پارکینسون دانشمند نبود. او هیچ دادهای جمعآوری نکرد. احتمالاً حتی از قوانین استنباط آماری هم سر در نمیآورد. پارکینسون یک طنزپرداز بود. دلیل پذیرفته شدن «قانون» او درستی نبود، بلکه چون خندهدار بود مورد قبول قرارگرفت.
مطمئناً اگر ریشهای از حقیقت در آن وجود نداشت، خندهدار نمیشد. پارکینسون نمونههایی از قانون خود را در بوروکراسی دولتی ساختگی نام میبرد که برخی معتقدند از ادارهی پست انگلیس الگو گرفته است. بوروکراسیها مستعد چنین مشکلاتی هستند، زیرا رضایت شغلی کارکنان آنها کم است. امّا احتمالاً شما در ساختار بوروکراتیک کار نمیکنید. حتی اگر کار کنید، تمام تلاش خود را میکنید تا مطمئن شوید کارکنانتان از تأثیرات آن در امان هستند. در غیر این صورت، آنها هرگز کاری را به پایان نخواهند رساند. در نتیجه، کارکنان شما امکان رضایت شغلی زیادی دارند. این منجر به حقیقت سادهای میشود که ارزش گفتن دارد:
قانون پارکینسون تقریباً به طور قطع در مورد کارکنان شما صدق نمیکند.
زندگی آنها کوتاهتر از آن است که اجازه دهد زیاد وقت تلف کنند. از آنجا که از کار خود لذت میبرند، تمایل ندارند کار را تا ابد ادامه دهند—این فقط رضایت خاطری که به دنبالش هستند را به تأخیر میاندازد. آنها به اندازه شما مشتاق به سرانجام رساندن کار هستند، با این شرط که مجبور نشوند از استاندارد کیفی خود بگذرند.
اگر کارمند تنبل ما را دیده بودید، این حرف را نمیزدید #
هر مدیر، حداقل چندبار در زندگی خود، با کارمندی مواجه میشود که به نظر میرسد از کار کردن اجتناب میکند، یا به نظر میرسد استاندارد کیفی ندارد، یا فقط نمیتواند کار را تکمیل کند. آیا این قانون پارکینسون را تأیید نمیکند؟
در یک محیط کار سالم، بازدهی نداشتن بعضی افراد به دلیل عدم شایستگی، عدم اعتماد به نفس و عدم همبستگی با دیگران در مورد پروژه و اهداف پروژه است. در هیچ یک از این موارد، فشار برنامهی زمانی کمک زیادی نمیکند. مثلاً وقتی به نظر میرسد کارمندی قادر به انجام کار نیست و اصلاً به کیفیت کار خود اهمیت نمیدهد، نشانهی قطعی آن است که فرد بیچاره از سختی کار تحت فشار است. او به فشار بیشتری احتیاج ندارد. آنچه نیاز دارد انتقال است، احتمالاً به یک شرکت دیگر.
حتی در موارد نادری كه فشار آوردن تنها گزینه است، مدیر باید آخرین کسی باشد که فشار میآورد. وقتی پیامی از طرف تیم میآید بسیار بهتر پذیرفته میشود. ما مواردی از تیمهای هماهنگ را دیدهایم که مدیر باید کنار بقیه میایستاد تا کسی که با بقیه همراه نبود را بازخواست کند.
در فصلهای بعدی، در مورد تیمها و ساختن فضایی معقول برای تشکیل آنها، چیزهای بیشتری برای گفتن داریم. اینجا موضوع روش کارآمد نیست، بلکه روش ناکارآمد است: نگرش پارکینسونی به کارکنان، ناکارآمد است. فقط آنها را تحقیر و بیانگیزه میکند.
اطلاعاتی از دانشگاه نیو ساوت ولز #
نگرش پارکینسونی به خواست ما از بین نمیرود. آنچه که به تغییر نظر مدیران کمک میکند، اطلاعات دقیق جمعآوری شدهای است که اثبات میکند قانون پارکینسون برای اکثر کارکنان صدق نمیکند. (برای چند لحظه فراموش کنید که پارکینسون هیچ دادهای برای اثبات قانون خود ارایه نداده، فقط چند صد صفحه آن را تکرار کرده است.)
دو محقق دانشگاه نیو ساوت ولز، مایکل لارنس و راس جفری، تحقیقات سالانهی خود را در دهه ۸۰ و ۹۰ انجام دادند. آنها پروژههای جاری صنعت را مطابق با یک استاندارد متداول جمعآوری داده، اندازهگیری کردند. هر سال بر جنبه متفاوتی از پروژهها تمرکز کردند. نظرسنجی ۱۹۸۵ اطلاعاتی را ارائه داد که قانون پارکینسون ناکارآمد است. این دقیقاَ تیرخلاص نیست که کاملاً قانون را بیاعتبار کند، ولی برای ایجاد تردید کافی است.
لارنس و جفری بررسی کردند متدهای مختلف برآورد کار چه تأثیری بر بهرهوری دارند. آنها در نظر داشتند این نظر عامیانه را اثبات (یا رد) کنند که توسعهدهندگان (در این مورد، برنامهنویسان) برای تحقق برآوردهای خود سختتر کار میکنند. برای هر کدام از ۱۰۳ پروژهی مورد مطالعه، یک معیار اندازهگیری برای بهرهوری محاسبه کردند. سپس بسته به نحوهی برآورد اولیه، نمونهها را در زیرگروههایی دستهبندی کردند. بخشی از نتیجه در جدول ۵-۱ ارایه شده است.
برآورد سختی توسط | متوسط بهرهوری | تعداد پروژهها |
---|---|---|
برنامهنویس به تنهایی | ۸٫۰ | ۱۹ |
مدیر به تنهایی | ۶٫۶ | ۳ |
برنامهنویس و مدیر | ۷٫۸ | ۱۶ |
جدول ۵-۱ بهرهوری در برابر رویکرد تخمین (بخشی از نتیجه)
تاکنون، نتایج نظر عامیانه را تایید میکنند: بهنظر میرسد برنامهنویسان پس از اینکه خودشان برآورد زمانی میدهند، کمی بیشتر بازدهی دارند، در مقایسه یا مواردی که مدیر، حتی بدون مشورت با آنها اینکار را انجام میدهد. وقتی هر دو با هم تخمین میزنند، نتیجه بینابین است.
در ۲۱ پروژه مورد مطالعه در آن سال، تخمینها توسط شخص سومی که عموما تحلیلگر سیستم بود، تهیه شده بود. توسعهدهندگان در این موارد، بهطور قابل توجهی در پروژههایی که تخمین زمانی توسط برنامه نویس و/یا به همراه یک مدیر انجام شده بود، بهتر عمل کردند.(جدول ۵-۲ را ببینید)
برآورد سختی توسط | متوسط بهرهوری | تعداد پروژهها |
---|---|---|
برنامهنویس به تنهایی | ۸٫۰ | ۱۹ |
مدیر به تنهایی | ۶٫۶ | ۳ |
برنامهنویس و مدیر | ۷٫۸ | ۱۶ |
تحلیلگر سیستم | ۹٫۵ | ۲۱ |
جدول ۵-۲ بهرهوری در برابر رویکرد تخمین (بخشی از نتیجه)
این اطلاعات اخیر، بههیج عنوان نظر عامیانه را تایید نمیکند. چرا برنامهنویسان برای رسیدن به برآورد تحلیلگر سخت کار میکنند، حتی بیش از تلاش برای تحقق برآورد خودشان؟ شاید وسوسه کننده باشد که این مسئله را به عنوان یک ناهنجاری در دادهها توضیح دهیم. ولی اگر شما هم مثل ما باور داشته باشید که تخمین نادرست، همیشه یک عامل بازدارنده است، بنابراین این دادهها اصلا احتیاجی به توضیح ندارد. تحلیلگر سیستم قاعدتاً برآوردکنندهی بهتری نسبت به برنامهنویس و یا سرپرست است. او به طور معمول کار را با جزییات زیاد میداند، امّا خوشبینی طبیعی شخصی که کار را واقعاً انجام میدهد و یا سوگیری سیاسی یا مالی رییس را ندارد. علاوه براین، تحلیلگران سیستمها، معمولاً تجربه تخمین بیشتری دارند.آنها قادرند سختی کار را دقیقتر پیشبینی کنند زیرا در گذشته کارهای مشابه بیشتری انجام دادهاند و درسشان را آموختهاند.
برآوردهای نادرست، برآوردهای فشرده و ناامیدکننده، شیرهی جان انجامدهندگان را میکشد. کِیپرز جونز، که مطالعات معروفی در زمینه شاخصهای پروژههای توسعه دارد، میگوید: «وقتی برنامهی پروژه کاملا غیرمنطقی و غیرواقعی است و با هیچ مقداری از اضافه کاری به پایان نمیرسد، تیم پروژه عصبانی و ناامید میشوند…و روحیه افراد از بین میرود.» 1 خیلی مهم نیست که «برنامهی کاملاً غیرمنطقی و غیرواقعی» از طرف رییس باشد یا از طرف خود سازندگان. وقتی افراد در شرایط بدون برد گیر میافتند، بازدهی کاری ندارند.
شگفتآورترین قسمت مطالعهی جفری-لارنس در سال ۱۹۸۵ در انتهای تحقیقات آشکار شد. زمانی که بهرهوری ۲۴ پروژهای را بررسی کردند که هیچ تخمین زمانی برای آنها مشخص نشده بود. این پروژهها به مراتب بهتر از سایر پروژهها بودند. (جدول ۵-۳ را ببینید)
برآورد سختی توسط | متوسط بهرهوری | تعداد پروژهها |
---|---|---|
برنامهنویس به تنهایی | ۸٫۰ | ۱۹ |
مدیر به تنهایی | ۶٫۶ | ۳ |
برنامهنویس و مدیر | ۷٫۸ | ۱۶ |
تحلیلگر سیستم | ۹٫۵ | ۲۱ |
(بدون برآورد) | ۱۲٫۰ | ۲۴ |
جدول ۵-۳ بهرهوری در برابر رویکرد تخمین (نتیجه نهایی)
پروژههایی که مدیر هیچگونه فشار زمانبندی روی آن اعمال نمیکند، («فقط وقتی کار تمام شد، من را خبر کنید») بالاترین بهرهوری را داشتند. البته، هیچیک از این موارد ثابت نمیکند که قانون پارکینسون برای توسعهدهندگان صادق نیست. امّا این باعث تعجب نیست؟
تصمیم اعمال فشار برای زمانبندی پروژه، باید به همان روشی گرفته شود که تصمیم میگیرید کودک خود را تنبیه کنید یا نه: اگر مجازات کم و بهموقع است، طوری که دلیل آن به سادگی معلوم میشود، آن وقت ممکن است کمک کند. اگر مرتب اینکار را انجام میدهید، نشانهی آن است که با خودتان مشکل پیدا کردهاید.
تنوع در یک موضوع توسط پارکینسون #
تغییرات جزیی در قانون پارکینسون، چیزی تولید میکند که به طرز وحشتناکی در بسیاری از سازمانها درست است:
مشغلهی سازمانی تمایل دارد تا پر کردن تمام روز کاری گسترش پیدا کند.
این اثر میتواند از زمان تاسیس شرکت شروع شود و هر سال بدتر شود. اگر کمپانی هند شرقی هلند (که در سال ۱۶۵۱ تاسیس شد و در آن زمان بزرگترین شرکت در جهان بود) همچنان وجود داشت، کارکنان آن چهل ساعت در هفته را صرف پر کردن فرمها میکردند. توجه داشته باشید که در این مورد، شرکت رفتار پارکینسون را ارایه میدهد تا کارمندانش. در بخش دوم به این موضوع باز خواهیم گشت.
Capers Jones, Programming Productivity (New York: McGraw-Hill, 1986), p. 213. ↩︎