با یک سرچ ساده در گوگل می‌توان به استراتژی‌هایی دست یافت که با به‌کارگیری اصولی آن‌ها می‌توان کارایی دولوپرها را ارتقاء داد اما در بسیاری از موارد مسأله این نیست که چه‌طور بهره‌وری را افزایش دهیم بلکه کاملاً برعکس، مسئلهٔ اصلی این است که عواملی که منجر به کاهش بهره‌وری می‌شوند را شناسایی کنیم که در همین راستا در ادامه به معرفی عواملی خواهیم پرداخت که کارایی دولوپرها را تحت تأثیر قرار داده و آن را نابود می‌کنند.
ایجاد وقفه در حین کدنویسی
یکی از بدترین چیزهایی که می‌تواند بهره‌وری دولوپر را کاهش دهد، وقفه‌هایی است که در میان کار رخ می‌دهند. به عنوان مثال، ممکن است دولوپری مشغول کار خود باشد که ناگهان یکی از همکاران شروع می‌کند به صحبت کردن در مورد اینکه امروز صبح رانندهٔ ماشین جلویی چه‌قدر ناگهانی ترمز گرفت و چه اتفاقی افتاد و اگر تدابیر هوشمندانهٔ او نبود چه اتفاقات بدتری ممکن بود رخ بدهد! یا حتی ممکن است یکی از همکاران سؤالی کاری و در ظاهر مرتبط از او بپرسد.
همین گفتگوهای کوتاه و در ظاهر بی‌اهمیت می‌توانند تمرکز ذهنی دولوپر را خدشه‌دار کنند و چنانچه دولوپر بخواهد مجدد بر روی کار خود متمرکز شود، باید زمان نسبتاً زیادی را صرف نماید. هرچه این وقفه‌های کوتاه در حین کدنویسی بیشتر اتفاق بیفتند، تمرکز دولوپر کمتر و کمتر خواهد شد که بالتبع به معنای خستگی بیشتر، کیفیت پایین‌تر و باگ بیشتر است.
جلسات یا بهتر بگوییم وقفه‌های برنامه‌ریزی‌شده حتی از وقفه‌های ناگهانی نیز مخرب‌تر هستند. یک دولوپر چه‌طور می‌تواند روی کارش تمرکز کند در حالی که مطمئن است به زودی وقفه‌ای در کارش رخ خواهد داد؟ جهت اجتناب از این دست وقفه‌های مخرب بهتر است جلسات را در ابتدای روز که دولوپرها هنوز کار خود را شروع نکردهاند و یا درست قبل از تایم ناهار یا نزدیک پایان وقت کاری برگزار نمود.
میکرومَنِیجمِنت
مدیری که سعی می‌کند وارد جزئیات کاری دولوپر شده و مو را از ماست بیرون بکشد به مذاق خیلی از دولوپرها خوش نمی‌آید که این نوع مدیریت اصطلاحاً Micromanagement گفته می‌شود. به نظر می‌رسد که میکرومَنِیجمنت باعث ایجاد وقفه‌های برنامه‌ریزی‌شده و برنامه‌ریز‌ی‌نشدهٔ بیشتری می‌شود اما بی‌رغبتی دولوپرها به این مدل مدیریتی بیشتر به خاطر حس عدم اعتمادی است که در پشت این رویکرد مدیریتی وجود دارد.
این نوع مدیران به توانایی و دانش نیروی انسانی خود اعتماد ندارند و سعی می‌کنند مستقیماً همه چیز را کنترل کنند و بدین ترتیب پیوسته در حال تضعیف مهارت‌های کارکنان خود هستند که مسلماً این رویکرد مدیریتی نادرست یکی از مهم‌ترین علت‌هایی است که دولوپرها شرکت خود را ترک می‌کنند (در همین راستا توصیه می‌کنیم که به مقالهٔ آیا می‌دانستید که ۵۰٪ کارمندان مدیرشان را ترک می‌کنند نه شرکت‌شان را؟ مراجعه نمایید.)
ابهام در کار
ابهام در موارد مختلفی می‌تواند رخ دهد. مثلاً در گزارش باگ، جملاتی مانند «درست کار نمی‌کند» و «اصلاح شود» توصیفاتی بسیار کلی از مشکل هستند و دولوپر هرگز از این جملات متوجه نخواهد شد که کجای کد چه مشکلی دارد. برای اجتناب از چنین ابهاماتی می‌توان از یک چارچوب مشخص برای گزارش باگ استفاده کرد که موارد مد نظر دولوپر در آن ذکر شده باشد.
همچنین ممکن است ابهام و سردرگمی در مورد یک فیچر خاص رخ دهد. به طور مثال، وقتی دولوپر نداند دقیقاً از او چه می‌خواهید، با پیش‌فرض‌های خود دست به کد می‌شود و در ادامه سعی می‌کند آن را به چیزی که حدس می‌زند بیشتر مورد نظر مدیرش است، نزدیک‌تر سازد. در مورد اولویت‌ها نیز همین مشکل می‌تواند پیش بیاید به طوری که ممکن است دولوپری ساعت‌ها وقت و تمرکز خود را بر روی بخشی از کار بگذارد، در حالی که از نظر مدیرش این کار اصلاً در اولویت نبوده و کارهای مهم‌تری برای انجام دادن وجود داشته‌اند. به طور کلی، برای دوری از مشکلاتی از این دست باید تلاش شود تا تمام جزئیات مورد نظر به دولوپر انتقال داده شده و نکته‌ای ناگفته باقی نماند.
مدیریت به شیوهٔ مرغ دریایی
اگر هم تا به حال چیزی در مورد این شیوهٔ مدیریت نشنیده باشید اما به احتمال خیلی زیاد از نزدیک با آن سروکار داشته‌اید. این شیوهٔ مدیریت مخصوص مدیرانی است که اصلاً در جریان کارها نبوده و درست مانند مرغ دریایی بر فراز آسمان برای خود مشغول پرواز هستند و شیوهٔ مدیریت آن‌ها هم بدین صورت است که گه‌گاه و به صورت کاملاً ناگهانی ارتفاع پرواز خود را کم نموده و فرود می‌آیند، چیزی همچون جملهٔ زیر می‌گویند و دوباره پرواز می‌کنند و می‌روند:
این چه کدیه نوشتی؟ اصلاً خوب نیست. اون یکی که افتضاحه و اینم که اصلاً کار نمی‌کنه!
این رفتار مدیران می‌تواند عمیقاً به ناامیدی و فرسودگی دولوپرها منجر شده و سبب شود که آن‌ها تا ساعت‌ها و حتی شاید تا چند روز بعد نتوانند روی کار خود تمرکز کنند که در همین راستا توصیه می‌کنیم به مقالهٔ چه می‌شود که شور و اشتیاق، انگیزه و حس تعلق اعضای تیم خود را از دست می‌دهیم! مراجعه نمایید.
خودخواهی مدیران مافوق
آیا تاکنون با مدیر و یا یکی از همکاران خود برخوردی داشته‌اید که قصد داشته باشد اعتبار و ارزش کار شما را به خود نسبت دهد؟ این کار مثل این است که توانایی‌های یک شخص را از او بگیریم و آن‌ها را به خود نسبت دهیم و نیاز به توضیح نیست که این‌گونه افراد معتقدند چون من باهوش، دقیق و یا خلاق هستم، دیگر افرادی که در کنارم کار می‌کنند این‌طور هوشمندانه، دقیق و خلاقانه کد می‌زند! این اخلاق نادرست تنش زیادی به دولوپر وارد نموده و به راحتی می‌تواند تمام بهره‌وری او را برای مدتی طولانی نابود کند (در همین راستا می‌توانید به مقالهٔ چگونه مدیرانی که خود را وقف کارمندان می‌کنند منجر به موفقیت بیشتر کسب‌وکار می‌شوند؟ مراجعه نمایید.)
شرایط نامطلوب محیط کار
شاید این مورد در نظر افرادی که دولوپر نیستند عجیب به نظر برسد اما شرایط محیط کار تأثیر مستقیمی بر کیفیت کار دولوپرها دارد. مثلاً وجود یک صدای تقریباً یکنواخت پس‌زمینه می‌تواند به افزایش تمرکز کمک کند و احتمالاً به همین دلیل است که افراد زیادی ترجیح می‌دهد در حین کار از هِدسِت استفاده کنند. عواملی مانند رفت و آمد زیاد در محیط کار و یا قرارگیری مانیتور به نحوی که در معرض دید سایرین قرار داشته باشد، هم استرس دولوپر و هم احتمال وقفه‌های کاری را افزایش می‌دهند و از همین روی تأثیر منفی بر تمرکز دارند.
تغییر تدریجی اهداف
تغییر تدریجی اهداف فرآیندی است که طی آن خواسته‌های نسبتاً ساده و کم‌اهمیت به هیولاهای وحشتناک زمان‌خواری تبدیل می‌شوند و معمولاً این وضعیت هنگامی پیش می‌آید که اهداف پروژه از ابتدا به خوبی تعریف و مستند نشده و یا تحت تأثیر عوامل ناپایدار دیگری قرار داشته باشند. مثلاً ممکن است اهداف یک فیچر ساده به صورت زیر تغییر کند:
- نسخهٔ اول (قبل از اجرا): این فیچر باید نقشهٔ یک مکان خاص را نمایش دهد.
- نسخهٔ دوم (تقریباً پس از تکمیل نسخهٔ اول): این فیچر باید بتواند نقشهٔ سه‌بُعدی یک مکان خاص را نشان دهد.
- نسخهٔ سوم (تقریباً پس از تکمیل نسخهٔ دوم): این فیچر باید نقشهٔ سه‌بُعدی یک مکان خاص را نمایش دهد و در قسمت‌های مختلف آن امکان زوم کردن برای کاربر فراهم باشد.
در اینجا هرچند ممکن است پیاده‌سازی نسخهٔ سوم این فیچر خیلی دشوارتر از نسخهٔ اول آن نباشد اما دولوپر عملاً سه نوبت برای نوشتن این فیچر وقت گذاشته است و این موضوع سبب اتلاف وقت وی شده و بدین ترتیب بهره‌وری او را تحت تأثیر قرار می‌دهد.
فرآیند تعریف محصول
تأثیر این مورد بر بهره‌وری دولوپرها در نگاه اول ممکن است کمی عجیب به نظر برسد اما با اندکی تأمل می‌توان نحوهٔ تأثیرگذاری آن را درک نمود. اگر اولویت‌های تیم توسعهٔ نرم‌افزار بدون اعتبارسنجی محصول صورت گیرد، این امکان وجود دارد که بسیاری از قابلیت‌های محصول نهایی بدون کاربرد باقی بمانند و این حس را در میان اعضای تیم ایجاد نمایند که محصول مفیدی تولید نکردهاند و همین حس نامفیدی می‌تواند به راحتی انگیزهٔ کار را از دولوپرها بگیرد و موجب دلسردی و ناامیدی آن‌ها شود.
بی‌توجهی به بدهی فنی
بدهی فنی یک تصمیم ارادی برای صرف‌‌نظر کردن از نوشتن بهینه‌ترین سورس‌کد یا ارائهٔ بهترین راه‌حل است. اتخاذ چنین تصمیمی گاهی گریزناپذیر است و در کوتاه‌مدت می‌تواند سبب سرعت گرفتن تکمیل و انتشار نرم‌افزار شود اما در عین حال انباشته شدن بدهی‌های فنی به مرور زمان می‌تواند پیشرفت کار را کند نموده و موجب آشفتگی دولوپرها شود.
معمولاً افرادی که دولوپر نیستند اهمیت تأثیر بلندمدت بدهی‌های فنی را دست‌کم می‌گیرند اما واقعیت آن است که بی‌توجهی به این موضوع نه تنها بهره‌وری دولوپر بلکه کیفیت کد را نیز تحت تأثیر قرار می‌دهد (برای آشنایی بیشتر با این مبحث، می‌توانید به مقالهٔ Technical Debt: بدهی فنی چیست و چگونه می‌توان از آن به نفع خود استفاده کرد؟ مراجعه نمایید.)
امکانات سخت‌افزاری و نرم‌افزاری
دولوپرها دائماً در حال ویرایش و اصلاح کدها و یا کامپایل آن‌ها هستند و از همین روی هر چه‌قدر این فرآیند‌ها به صورت خودکار درآیند، سرعت تولید محصول افزایش می‌یابد و واضح است که استفاده از ابزارهای بسیار قدیمی می‌تواند بهره‌وری دولوپر را تحت تأثیر قرار دهد. علاوه بر این، مسائلی همچون استفاده از مانیتور کوچک لپ‌تاپ به جای یک مانیتور بزرگ رومیزی نیز می‌تواند در بهره‌وری دولوپرها تأثیرگذار باشد (در این ارتباط، توصیه می‌کنیم به مقالهٔ آزادی انتخاب سخت‌افزار منجر به افزایش بهره‌وری کارکنان خواهد شد! مراجعه نمایید.)
نحوهٔ مستندسازی
از آنجا که در حین یادگیری کدنویسی معمولاً افراد به کامنتنویسی تشویق می‌شوند، ممکن است برخی از دولوپرها به نوشتن کامنت‌های خیلی زیاد عادت داشته باشند. به طور کلی، نیازی به کامنتنویسی برای خط به خط سورس‌کد وجود ندارد اما روی هم رفته نوشتن کامنت از ننوشتن آن به مراتب بهتر است. همچنین به خاطر داشته باشیم مسئلهٔ اصلی تعداد کامنت‌ها نیست بلکه مسئله نحوهٔ کامنتنویسی است به این معنا که در کامنت لازم است هدف کد و اینکه بلوک مورد نظر چه کاری انجام می‌دهد شرح داده شود تا اگر بعدها باگی در کد ایجاد شد، دولوپر بداند برای رفع آن باید از کجا شروع کند.
به طور خلاصه، کامنتنویسی بیش از حد در فرآیند توسعهٔ نرم‌افزار و وجودکامنت‌های غیرضروری و فراوان در هنگام ویرایش‌های بعدی کد از یکسو و کامنتنویسی نادرست از سوی دیگر می‌توانند بهره‌وری دولوپر را تحت تأثیر قرار دهند.
دِدلاین‌های غیرممکن
برخی از مدیران پروژه در آغاز کار زمان تقریبی اتمام کار را از دولوپر سؤال می‌کنند که تا اینجا هیچ مشکلی وجود ندارد اما مشکل زمانی ایجاد می‌شود که ایشان زمان تقریبی اعلامی را در ذهن خود تا حد ممکن کوتاه و کوتاه‌تر نموده و در نهایت آن را به عنوان زمان تکمیل پروژه در نظر می‌گیرند و سپس این زمان خیالی را به عنوان ددلاین دقیق اعلام‌شده توسط دولوپر به مدیران مافوق خود اعلام می‌کنند و از این روی اصلاً جای تعجب نیست که رعایت چنین دِدلاین مستبدانه‌ای برای دولوپرها فوق‌العاده دشوار و یا حتی غیرممکن باشد و نیاز به توضیح نیست که این موضوع می‌تواند فشار روانی زیادی به دولوپرها وارد نماید و تمرکز و بهره‌وری آن‌ها را از بین ببرد.
نتیجه‌گیری
در مقاله‌ای تحت عنوان ایجاد فرهنگ نرم‌افزاری مشابه با سیلیکون‌ولی و رقابت شرکت‌های فناوری برای بازآفرینی هویت دولوپرها به بررسی این موضوع پرداختیم که با رعایت چه اصولی می‌توان فرهنگ کاری کسب‌وکار خود را به شرکت‌های فعال در سیلیکون‌ولی نزدیک‌تر ساخت که به نوعی می‌توان گفت نقطهٔ مقابل مواردی است که در این مقاله مطرح شد.
آنچه مسلم است اینکه توسعهٔ نرم‌افزار هم علم است و هم هنر و نیاز به توضیح نیست که نیازمند خلاقیت است و چنانچه دولوپرها در فضایی قرار گیرند که نتوانند آن‌طور که باید و شاید خلاقیت خود را شکوفا سازند، در نهایت نخواهند توانست محصولی منحصر‌به‌فرد روانهٔ بازار کنند.
آیا تا به حال در پروژه‌های خود با موارد فوق مواجه شده‌اید و کدام مورد بیش از همه بهره‌وری شما را تحت تأثیر خود قرار می‌دهد؟ همچنین چه عوامل دیگری می‌شناسید که ممکن است بر بهره‌وری دولوپرها مؤثر باشند؟ نظرات، دیدگاه‌ها و تجربیات خود را با سایر کاربران سکان آکادمی به اشتراک بگذارید.