رهبری موفق در مهندسی با خروجی‌های تیم‌ها سنجیده نمی‌شود، بلکه با ارزشی ارزیابی میشود که از طریق فراهم کردن شرایط مناسب به دست می‌آید. یکی از مفاهیمی که مکرراً در بحث‌های مربوط به بهره‌وری مطرح میشود، قانون پارکینسون (Parkinson’s Law) است. این اصل به ظاهر ساده، پیامدهای عمیقی برای رهبری تیم‌های مهندسی دارد؛ اما نه لزوماً به شکلی که بسیاری تصور می‌کنند.
شاید آنچه در این نوشته به آن اشاره میشود، شما را شگفت‌زده کند: چالش واقعی این است که از مهندسان بخواهیم که کار را متوقف کنند، نه اینکه آن‌ها را به کار بیشتر وادار کنیم. همان‌طور که در ادامه خواهیم دید، در مهندسی، کار نه به دلیل ناکارآمدی بوروکراتیک یا تنبلی، بلکه به خاطر کمال‌گرایی کنترل‌نشده طولانی میشود؛ تعهدی به کیفیت که به شکلی متناقض می‌تواند مانع از ارائه‌ی ارزش شود.
پیشینه: منظور واقعی پارکینسون چه بود؟
قانون پارکینسون که در سال ۱۹۵۵ توسط مورخ، سیریل نورثکوت پارکینسون (Cyril Northcote Parkinson)، مطرح شد و در کتاب تأثیرگذار “Peopleware” نیز به آن اشاره شده است، بیان می‌کند: “کار به اندازه‌ی زمان موجود برای تکمیل آن، طولانی میشود.”
این مسئله مانند تهیه‌ی یک ساندویچ است. اگر ۲ دقیقه برای آن فرصت داشته باشید، نان، گوشت و پنیر را روی هم می‌گذارید و کار تمام میشود. اما اگر ۳۰ دقیقه وقت در دسترس باشد، ناگهان شروع به بریدن گوجه‌فرنگی‌ها به شکل دایره‌های کامل، برشته کردن نان و چیدن منظم همه چیز می‌شوید. در هر دو حالت، همان گرسنگی و همان ساندویچ ساده وجود دارد، اما زمان بسیار بیشتری برای آن صرف میشود.
پارکینسون این مشاهده را نه در آشپزخانه، بلکه در حوزه موضوعات اداری انجام داد، به ویژه در مورد نحوه‌ی رشد بوروکراسی در خدمات دولتی بریتانیا، که بدون توجه به حجم کاری واقعی رخ می‌داد. او درباره‌ی متخصصانی که به حل مشکلات پیچیده می‌پردازند صحبت نمی‌کرد؛ او در حال توصیف ناکارآمدی بوروکراتیک بود. پارکینسون مشاهدات خود را بر اساس وظایف اداری با پایان مشخص بنا نهاده بود. این موضوع با حل مسئله‌های پیچیده و خلاقانه که ویژگی اصلی مهندسی نرم‌افزار مدرن است، تفاوت دارد. با این وجود، نکته‌ای از این قانون هنوز در دنیای مهندسی امروز صدق می‌کند.
آنچه تحقیقات در مورد تخمین‌های زمانبندی در مهندسی فاش می‌کند
تحقیقات مربوط به تخمین‌های زمانبندی در پروژه‌های مهندسی، روایت جالبی را بازگو می‌کنند. نسخه‌ی سال ۲۰۱۳ کتاب “Peopleware” به یک مطالعه‌ی بسیار جالب در سال ۱۹۸۵ از لارنس و جفری (Lawrence & Jeffery)در دانشگاه نیو ساوت ولز اشاره دارد که بررسی کرده است رویکردهای تخمین زمانبندی متفاوت چگونه بر بهره‌وری تیم تأثیر می‌گذارند.
یافته‌های آن‌ها خیره‌کننده بود:
| روش تخمین زمانبندی | شاخص بهره‌وری |
| سرپرست به تنهایی (تحمیل‌شده توسط مدیر) | ۶.۶ |
| سرپرست و برنامه‌نویس با هم | ۷.۸ |
| برنامه‌نویس (در اختیار تیم) | ۸.۰ |
| کارشناس مستقل (تحلیلگر سیستم) | ۹.۵ |
| بدون تخمین رسمی (بدون فشار زمان تحویل کار) | ۱۲.۰ |
این مطالعه نشان داد تیم‌هایی که هیچ موعد تحویلی نداشتند، بهره‌وری‌شان به مراتب بالاتر (حدود ۴۰ تا ۵۰ درصد بهتر) از بهترین گروه‌هایی بود که موعد تحویل داشتند. این بهبود، نه تنها اندک نبود، بلکه به طرز چشمگیری محسوس بود.
کاپرز جونز(Capers Jones) در این کتاب می‌گوید: «وقتی زمانبندی یک پروژه کاملاً غیرمنطقی است و حتی با اضافه‌کاری هم نمی‌توان به آن رسید، تیم پروژه عصبانی و ناامید میشود و روحیه‌ی اعضا به پایین‌ترین حد خود سقوط می‌کند.»
با توجه به این داده‌ها، به نظر می‌رسد قانون پارکینسون کاربرد چندانی در مهندسی نرم‌افزار ندارد. در واقع، هرگاه این قانون به عنوان توجیهی برای تعیین ضرب‌الاجل‌های فشرده تحویل کار استفاده شود، نتیجه‌ی معکوس می‌دهد.
با این حال، دنیای واقعی پیچیدگی‌های خود را دارد. تیم‌های مهندسی در سیستم‌های گسترده‌تری شامل ذی‌نفعان، نقشه‌های راه محصول، وابستگی‌های میان تیم‌ها و بودجه‌های مشخص فعالیت می‌کنند. به همین دلیل، در مقاطعی، باید مایلستونهای مشخصی تعیین شوند.
با وجود اینکه برخی استدلال می‌کنند که باید تخمین‌ها را به کلی کنار گذاشت، این دیدگاه اغلب واقعیت‌های کسب‌وکار را نادیده می‌گیرد. نرم‌افزار برای خدمت به کاربران و همسویی با استراتژی کلی سازمان ساخته میشود، نه اینکه صرفاً وظایفی را تکمیل کند.
واقعیت این است که تخمین‌های زمانی واقع‌بینانه نه تنها محدودکننده نیستند، بلکه ابزارهایی ارزشمند برای برقراری تعادل میان آزادی عمل مهندسان و نیازهای سازمانی هستند. نکته کلیدی اینجاست که این تخمین‌ها باید از نظرات دقیق و تأمل‌شده‌ی تیم به دست بیایند، نه از ضرب‌الاجل‌های خودسرانه.
زمانی که قانون پارکینسون در مورد مهندسان صدق می‌کند
در حالی که تحقیقات، کاربرد سنتی قانون پارکینسون در کارهای خلاقانه و تخصصی را به چالش می‌کشند، مشاهده شده است که طولانی شدن و گسترش کار همچنان در تیم‌های مهندسی رخ می‌دهد؛ اما از طریق سازوکاری متفاوت با آنچه که در پارکینسون توصیف شده است.
مهندسان، به جای تنبلی یا بی‌انگیزگی، تمایلی طبیعی به کمال‌گرایی (پرفکشنیزم) دارند. بدون وجود محدودیت‌های واضح، بسیاری از مهندسان موارد زیر را انجام می‌دهند:
- اصرار بر بهبود راه‌حل‌ها، حتی پس از رسیدن به نتیجه‌ای قابل قبول
- اضافه کردن ویژگی‌هایی به محصول که “خوب است که داشته باشیم” ، ولی در الزامات اولیه نبوده‌اند
- ریفکتور کردن کدهایی که عملکردشان مناسب است، اما می‌توانند “زیباتر” باشند
- به تعویق انداختن تحویل تا زمانی که احساس کنند راه‌حل “کامل” است
این دقیقاً نقطه‌ی مقابل تنبلی است. این یک تعهد به کیفیت است که به طرز متناقضی می‌تواند علیه تحویل ارزش به صورت کارآمد عمل کند.
تله‌ی کمال‌گرایی: جایی که برتری طلبی به مانع تبدیل می‌گردد
چیزی که در عمل به عنوان قانون پارکینسون برای مهندسان شناخته میشود، غالباً همان “تله‌ی کمال‌گرایی” است. مهندسان زمان خود را با کارهای بی‌اهمیت پر نمی‌کنند؛ آن‌ها به دنبال راه‌حل ۱۰۰٪ هستند، در حالی که یک راه‌حل ۸۰٪ می‌توانست ارزش تجاری مورد نیاز را ارائه دهد.
یک مثال شناخته‌شده از تله‌ی کمال‌گرایی، جیمیل (Gmail) گوگل است که به مدت بیش از پنج سال در حالت «بتا» باقی ماند. در حالی که بهبود مداوم، ویژگی‌ها را ارتقا می‌داد، این کمال‌گرایی کنترل‌نشده، پذیرش گسترده‌ی تجاری، به ویژه در محیط‌های سازمانی که “بتا” نشانه‌ی بی‌ثباتی بود، را به تأخیر انداخت. مهندسان گوگل به دلیل تنبلی تأخیر ایجاد نمی‌کردند؛ آن‌ها به طور مداوم محصول را فراتر از آنچه کاربران واقعاً نیاز داشتند بهبود می‌بخشیدند و این نشان می‌دهد که قانون پارکینسون در مهندسی چگونه از طریق کیفیت‌گرایی، نه از طریق سهل‌انگاری، خود را نشان می‌دهد.
تله‌ی کمال‌گرایی از چندین عامل روان‌شناختی ناشی میشود:
- هویت حرفه‌ای: مهندسان اغلب ارزش خود را با کیفیت کدشان گره می‌زنند.
- ترس از قضاوت: نگرانی در مورد انتقاد همکاران در حین بررسی کد.
- نیات مثبت: باور صادقانه به اینکه کمال‌گرایی به سلامت بلندمدت محصول کمک می‌کند.
این انگیزه‌ها از یک جایگاه خوب نشأت می‌گیرند: تعهد به کیفیت، توجه به جزئیات و غرور حرفه‌ای. اما وقتی کنترل نشوند، می‌توانند مانع از تحویل به‌موقع ارزش شده و پیش‌بینی‌پذیری را در فرآیند مهندسی از بین ببرند.
بازده کاهشی کمال‌گرایی
همان‌طور که استیو مک‌کانل (Steve McConnell) در کتاب “کیفیت نرم‌افزار در سرعت بالا” استدلال می‌کند، تلاش برای رسیدن به نرخ‌های بالای حذف نقیصه ها (بالای ۹۵٪) می‌تواند در واقع تحویل را کند نموده و مزایای ناچیزی را در خارج از سیستم‌های حیاتی ارائه دهد. این نشان می‌دهد که دنبال کردن “ایده آل” در کیفیت نرم‌افزار می‌تواند به سرعت نتیجه‌ی معکوس دهد.
به عنوان یک کیس واقعی، در یک سازمان یک اصل برای توسعه محصول وجود داشت که این توازن را به خوبی در بر می‌گرفت: “همه‌ی موارد را پوشش ندهید.” . این یک رویکرد فرهنگی عمدی بود. این اصل، تیم‌ها را به حرکت سریع، تحویل سریع ارزش و رسیدگی به موارد خاص به صورت تدریجی تشویق می‌کرد. این رویکرد در آن مرحله از رشد که سرعت یادگیری و تحویل از اهمیت بیشتری نسبت به بهبودهای بی‌نهایت برخوردار بود، به خوبی کار کرد. این مسئله توضیح می‌دهد که چرا قانون پارکینسون در مهندسی خود را نشان می‌دهد: کار، نه به دلیل تنبلی، بلکه به خاطر تلاش برای کمال‌گرایی بی‌مورد، طولانی میشود.
نقش رهبران مهندسی: تعیین محدودیت‌های صحیح
“پس اگر قانون پارکینسون به آن شکلی که به طور سنتی درک میشود به طور کامل صدق نمی‌کند، رهبران مهندسی چگونه باید به مدیریت زمان بپردازند؟”
در حالی که ممکن است وسوسه شوید زمانبندی و ضرب‌الاجل‌های خودسرانه اعمال کنید، رهبری مؤثر مهندسی نیازمند موارد زیر است:
- درک ظرفیت واقعی تیم؛ نه بر اساس انتظارات آرزومندانه یا فشار.
- تعیین محدودیت‌هایی که تیم را به چالش بکشد بدون آنکه روحیه را تضعیف کند؛ ضرب‌الاجل‌های زمانبندی باید بلندپروازانه، اما دست‌یافتنی به نظر برسند.
- تعریف واضح “شرط اتمام کار” (Definition of Done)؛ کدام ویژگی‌ها و سطح کیفی، یک محصول قابل تحویل را تشکیل می‌دهند؟
- ترویج تحویل تدریجی؛ تقسیم کار به قطعات کوچک‌تر و قابل تحویل.
- ایجاد امنیت روانی؛ مهندسان باید در تحویل راه‌حل‌های “به اندازه کافی خوب” و بهبود آن‌ها در آینده احساس راحتی کنند.
به جای فشار بر مهندسان برای کار سریع‌تر، هدف این است که آن‌ها را در تشخیص لحظه‌ی ایده‌آل برای توقف بهبود و تحویل محصول راهنمایی کنید. این رویکرد، تمایلات کمال‌گرایانه را به سمت تحویل ارزش تجاری ملموس هدایت می‌کند.
مسیر میانه: بین زمانبندی تحویل خودسرانه و نبود موعد تحویل
یافتن تعادل مناسب بسیار حیاتی است. همان‌طور که در تیم‌ها مشاهده شده است:
- موعد تحویل بیش از حد سخت‌گیرانه منجر به نادیده گرفتن برخی موارد، افزایش بدهی فنی و در نهایت فرسودگی شغلی میشود.
- موعد تحویل بیش از حد سهل‌گیرانه یا نبود ضرب‌الاجل اجازه می‌دهد تا تله‌ی کمال‌گرایی رخ دهد و تحویل ارزش را به تأخیر می‌اندازد و هزینه‌های پروژه را افزایش می‌دهد.
این تمایلات کمال‌گرایانه معمولاً زمانی بروز می‌کنند که مهندسان با ابهام مواجه شوند؛ مثلاً وقتی اولویت‌ها تغییر می‌کنند، انتظارات نامشخص است یا ساختار سازمانی در حال دگرگونی است
نقطه‌ی مطلوب چیزی است که “محدودیت‌های آگاهانه” نامیده میشود؛ زمان‌بندی‌هایی که بر اساس درک واقعی از کار و تیم تعیین شده‌اند، با فشاری کافی برای حفظ تمرکز، اما نه آنقدر زیاد که کیفیت آسیب ببیند.
قانون پارکینسون به عنوان یک ابزار، نه یک اسلحه
با این تعریف جدید، قانون پارکینسون به ابزاری مفید برای رهبران مهندسی تبدیل میشود. این قانون به ما یادآوری می‌کند که:
- محدودیت‌ها می‌توانند مفید باشند، به شرطی که واقع‌بینانه و آگاهانه باشند.
- کامل بودن، دشمن اتمام کار است، به ویژه در محیط‌های فناوری با حرکت سریع.
- مهندسان به راهنمایی‌های شفافی نیاز دارند که به آن‌ها بگوید چه زمانی باید بهبود را متوقف کرده و کار را تحویل دهند
این قانون در مورد وادار کردن افراد به کار سخت‌تر یا سریع‌تر نیست؛ بلکه در مورد تشخیص تمایل طبیعی ما به گسترش کار و تعیین مرزهای مناسب است. و نکته‌ی حیاتی، این است که بدانیم چه زمانی این فشار را اعمال کنیم و چه زمانی نه.
شناسایی تله‌ی کمال‌گرایی
به این نشانه‌های هشداردهنده کمال گرایی توجه کنید:
- ریفکتورینگ بی‌وقفه کد، بدون اینکه نقطه‌ی پایانی مشخص شده باشد.
- ویژگی‌هایی از محصول که برای روزها در وضعیت “۹۰ درصد تکمیل” باقی می‌مانند.
- اکراه مهندسان از به اشتراک گذاشتن کار خود، تا زمانی که آن را “بی‌نقص” بدانند.
- افزایش دامنه‌ی پروژه، بدون تنظیم متناسب با زمانبندی.
اعمال محدودیت‌های آگاهانه
در حالی که محدودیت‌های صحیح، استراتژی کلی را برای یک رویکرد حمایتی و واقع‌بینانه به مدیریت زمان در سطح رهبری فراهم می‌کنند، محدودیت‌های آگاهانه شیوه‌های عملی برای اجرای این استراتژی هستند.
- همکاری در تخمین زمان‌ها: تیم باید در تعیین زمان‌بندی‌ها مشارکت داده شود تا از واقع‌بینانه بودن و پذیرش آن‌ها اطمینان حاصل شود.
- تعریف معیارهای پذیرش شفاف: “تمام شدن کار” باید به صراحت و با استفاده از یک تعریف روشن از “به اندازه کافی خوب” مشخص و دست‌یافتنی شود.
- ارزش‌گذاری بر تحویل به‌موقع به جای ایده آل گرایی: با قدردانی از تحویل به‌موقع، بر ارزش رساندن کارها به کاربران تأکید شود.
- طراحی چرخه‌های بهبود: بهبودها باید پس از انتشار اولیه برنامه‌ریزی شوند، نه اینکه برای رسیدن به نقطه ایده آل ، تحویل به تأخیر بیفتد. (به عنوان مثال: “این ویژگی را همین حالا منتشر می‌کنیم، داده‌ها را جمع‌آوری کرده و در اسپرینت بعدی با اطلاعات بیشتر آن را بهبود خواهیم داد.”)
- پیاده‌سازی زمانبندی دقیق (Timeboxing): برای ریفکتورینگ یا تکمیل کار، بازه‌های زمانی مشخصی باید اختصاص داده شود که پس از آن تیم به سراغ کار بعدی بررود.
البته تعادل مناسب در این طیف بر اساس زمینه موضوع تغییر می‌کند؛ نرم‌افزار پزشکی به حق، کمال‌گرایی بالاتری نسبت به یک وب‌سایت بازاریابی می‌طلبد، استارتاپ‌ها از راه‌حل‌های ۷۰٪ سریع بهره می‌برند در حالی که سازمان‌های بزرگ به کیفیت بیشتری نیاز دارند، و محصولات اولیه به تکرار سریع نیاز دارند، در حالی که محصولات بالغ نیازمند بهبود عمیق‌تر هستند. رهبران مؤثر، به جای اعمال یک آستانه‌ی یکسان برای همه، محدودیت‌ها را بر اساس این عوامل تنظیم می‌کنند.
یک رویکرد عملی موفقیت‌آمیز: وقتی یک عضو تیم پیشنهاد اضافه کردن محدوده یا ریفکتورینگ های اضافی را مطرح می‌کند، از او بخواهید تأثیر آن بر کاربر را کمٌی کند: “چه تعداد کاربر متوجه این بهبود خواهند شد؟” و “کدام معیارهای کسب‌وکار با این تغییر، متحول می‌شوند؟”
این رویکرد، تلاش مهندسی را بر اساس نتایج کاربر و ارزش تجاری هدایت می‌کند، نه صرفاً کنجکاوی فنی یا کیفیت‌گرایی.
نتیجه‌گیری: فراتر از قانون
قانون پارکینسون هرچند برای مهندسی نوشته نشده بود، اما الگوی اصلی آن، یعنی طولانی شدن کار به اندازه‌ی زمان موجود، همچنان در این حوزه به چشم می‌خورد. با این تفاوت که این اتفاق نه به دلیل ناکارآمدی بوروکراتیک، بلکه از طریق تعهد بیش از حد به کیفیت‌گرایی رخ می‌دهد.
امروزه، کار در مهندسی مدرن به ندرت به دلیل بیکاری با مشکل مواجه میشود. مهندسی نرم‌افزار بیش از هر زمان دیگری در دسترس است و جامعه‌ای پویا و سرشار از متخصصان باانگیزه دارد که مشتاق حل مشکلات هستند.
چالش واقعی این است که بدانیم چه زمانی باید از بهبود دست کشید و کار را تحویل داد. اینجاست که نقش رهبری اهمیت پیدا می‌کند؛ نه با اعمال فشار، بلکه با ایجاد راهنمایی و شفافیت.
شفافیت در اولویت‌ها، در دامنه‌ی کار و در تعریف “تمام شدن کار”.
زمانی که رهبران مهندسی محدودیت‌های آگاهانه تعیین می‌کنند، برای تحویل معنادار ارزش قائل می‌شوند و ارزش نهایی را در کانون توجه نگه می‌دارند، قانون پارکینسون از یک پتک به یک ابزار مفید تبدیل خواهد شد.
این همان کار اصلی است؛ و اینجاست که رهبری موفق خود را نمایان می‌کند.
منبع :https://dzone.com/articles/rethinking-parkinsons-law-modern-engineering-teams
