مقاله های زیادی هستند که به نقش راهنمایان تکنولوژی و مدیران فنی اشاره می کنند. یک موضوع خاصی که ما اغلب با آن روبرو می شویم این است که چطور می توانیم سودمندی توسعه دهنده و به طور کلی گروه را افزایش دهیم. اما قبل از اینکه انرژی خود را بر افزایش سودمندی توسعه دهنده و گروه متمرکز کنید، شاید بهتر باشد اول بدانید چه چیزی این سودمندی توسعه دهنده و گروه را نابود می کند. اگرچه کتاب Peopleware تقریبا 30 سال قبل منتشر شد، اما هنوز هم گروه های زیادی را می بینیم که از فقدان سودمندی بالا در بعضی از راه های خاص رنج می برند.

هیچ کس انتظار ندارد یک برنامه ریز بدون اینکه به کامپیوتر دسترسی داشته باشد کاری را به پایان برساند، اما شرکت های زیادی هستند که انتظار دارند برنامه ریزان بدون دسترسی به ذهن خود، وظیفه خود را به انجام برسانند. این امر غیر واقعی است.

بیاید سراغ 12 موردی برویم که همچون سدی برای سودمندی توسعه دهنده عمل می کنند. در این مقاله بر این تلاش دارد که این لیست را از مهم ترین تا کم اهمیت ترین مواردی که در سودمندی توسعه دهنده نقش دارد، دسته بندی کند. با حذف این عوامل سودمندی توسعه دهنده به حداکثر خود می رسد.

1. نقش وقفه ها و جلسات در سودمندی توسعه دهنده

از نظر من، وقفه ها اولین عامل نابود کننده سودمندی توسعه دهنده هستند. مسئله این است که توسعه دهندگان نمی توانند بعد از وقفه سریعا تمرکز کنند. آنها برای پیشرفت و ادامه فعالیت خود باید در همان ذهنیت قرار داشته باشند و سپس به آرامی به همان جایی برسند که در زمان وقفه از آن جدا شده بودند. تمرکز دوباره اغلب بیش از 30 دقیقه طول می کشد و سودمندی توسعه دهنده را زیر سوال می برد. هرچقدر وقفه ها بیشتر باشند، خستگی بیشتر است، کیفیت کار کمتر می شود، باگ ها بیشتر می شود و به همین روال ادامه پیدا می کند.

یک توسعه دهنده اظهار کرد: «وقتی من می خواهم کار خود را شروع کنم، هر چقدر حواس من بیشتر پرت شود- در هر بار مدت زمان بیشتری سعی می کنم تا تمرکز کنم. اگر صبح های من با وقفه پر شود، اگر آن روز بی حاصل بود، نباید تعجب کنید.»

جلسات چطور؟ تنها تفاوت بین یک جلسه و یک وقفه این است که جلسه یک وقفه برنامه ریزی شده است که برای سودمندی توسعه دهنده حتی بدتر از وقفه می باشد. توسعه دهندگان اگر بدانند وقتی در حال کار هستند یک وقفه خواهند داشت، نمی توانند در کار پیشرفت داشته باشند. بنابراین اگر آنها یک یا دو ساعت بعد جلسه داشته باشند، از آنجایی که کارهای فنی زمان بیشتری می طلبد، نمی توانند در هیچ چیز پیشرفت کنند. بنابراین این جلسات همچون مانعی برای سودمندی توسعه دهنده عمل می کنند.

پل گراهام نوشت: « یک جلسه می تواند با تقسیم کردن روز به بخش های کوچکتر، یک بعدازظهر کامل را از بین ببرد. هر بخش آنقدر کوچک است که نمی توان هیچ کاری سختی در آن انجام داد.»

اما چطور می توان از این وقفه ها و جلساتی که مانع سودمندی توسعه دهنده هستند اجتناب کرد؟ این بخش به خوبی مستند شده است؛ پس هیچ بهانه ای برای فرار از آنها ندارید. اما می توانید جلسات کوتاه را در شروع روز یا قبل از ناهار قرار دهید تا از وقفه های غیر ضروری اجتناب کنید و تاثیر کمتری بر سودمندی توسعه دهنده بگذاریم.

2. نقش مدیریت میکرو یا مدیریت ذره بینی در سودمندی توسعه دهنده

با توجه به سودمندی توسعه دهنده، در میان انواع مختلف مدیریت، مدیران میکرو یا ذره بینی شاید بدترین نوع باشند. مدیران میکرو تمایل دارند جلسات و وقفه های غیر برنامه ریزی شده بیشتری داشته باشند. اما فقط این نیست. آنها به کارمندان خود اطمینان ندارند و با این کار، همیشه حس می کنید مهارت ها و توانایی شما در انجام کارها دست کم گرفته می شود. این حس تاثیر منفی بر سودمندی توسعه دهنده خواهد گذاشت. هر انگیزه ای که یک توسعه دهنده در میان وقفه ها داشته است، با وجود این عدم اطمینان در آن لحظه از بین می رود. تاثیر این مورد فراتر از موثر بودن است. مدیران میکرو شاید اولین دلیل برای ترک توسعه دهندگان یا حداقل تعویض گروه ها باشند.

. 3.نقش ابهام در سودمندی توسعه دهنده

راه های زیادی برای توضیح ابهام وجود دارد. گزارش های باگ مانند «خراب است، آن را تعمیر کنید!» به توسعه دهندگان اطلاعات کافی نمی دهد تا بتوانند از شر آن باگ ها خلاص شوند. به هر حال، داشتن یک قالب گزارش باگ می تواند در آن شرایط کمک کننده باشد.

اگر درباره یک ویژگی توضیحات مجهول وجود داشته باشد، توسعه دهندگان شروع به اجرای چیزی می کنند که به نظر آنها درست است. همزمان این امکان وجود دارد که مدیر جزئیات بیشتری ارائه دهد و در این شرایط توسعه دهندگان مجبور هستند از اول شروع به کار کنند.

اولویت مجهول نیز به این دسته تعلق دارد. به راحتی می توان موقعیتی که یک توسعه دهنده حیران است که آیا بر روی وظیفه درست کار می کند یا نه را حذف کرد. اگر آنها حتی یکبار از طرف مدیر کامنتی دریافت کنند که چرا بر روی این کار خاص کار کردند (زمانی که اولویت ها تعریف نشده اند)... حس خیلی بدی به آنها می دهد. از اینرو سودمندی توسعه دهنده به حداقل می رسد.

4. نقش مدیریت به سبک مرغ دریایی در سودمندی توسعه دهنده

آیا تا به حال راجع به نقش مدیریت به سبک مرغ دریایی در سودمندی توسعه دهنده چیزی شنیده اید؟ این نوع مدیریت زمانی رخ می دهد که مدیران کاری به هیچ چیز ندارند، اما... هر از گاهی سرعت خود را پایین می آورند تا تمام چیزها را خراب کنند. برای مثال قبل از اینکه دوباره سراغ شما بیایند می گویند «این غلط است و بد به نظر می رسد» و غیره. باید اعتراف کنم که این تصویر را دوست دارم، اما متاسفانه این کار خیلی بیشتر از آنچه که دوست داریم رخ می دهد. این رفتار برای توسعه دهندگان بسیار خسته کننده است؛ در این شیوه آنها تا چند ساعت نمی توانند به حوزه کاری خود باز گردند و گاهی اوقات این زمان شاید تا روزها طول بکشد. این نوع مدیریت را می توان یکی از عوامل تاثیرگذار بر سودمندی توسعه دهنده دانست.

5. نقش طمع اعتبار در سودمندی توسعه دهنده

آیا تا به حال مدیر یا توسعه دهنده ای داشته اید که تمام اعتبار کاری که شما در چند هفته گذشته انجام داده اید را به نام خود ثبت کرده است؟ توسعه دهندگان بیش از همه روح رقابت دارند. اعتبار را برای دیگری ثبت کردن به معنای رقابت دیگری را برای خود گرفتن و حذف آن فرد می باشد. این گزینه در بالای لیست من قرار دارد، چرا که حس می کنم این موضوع آنقدر تنش ایجاد می کند که تمام سودمندی توسعه دهنده را برای مدت چشمگیری از بین می برد.

6.نقش محیط – صدها، حرکت، طراحی محیط کار و غیره در سودمندی توسعه دهنده

این موضوع شاید برای افرادی که برنامه ریز نیستند، عجیب باشد، اما محیطی که توسعه دهندگان در آن کار می کنند تاثیر مهمی بر فعالیت و سودمندی آنها دارد. برای مثال، داشتن مقداری صدای سفید – صدای ماشین و کامیون هایی که عبور می کنند- به آنها کمک می کند بهتر تمرکز کنند. به همین خاطر بیشتر این افراد هدفون بر گوش می گذارند!

به طور مشابه، اگر محیط کاری طوری طراحی شده است که باید حرکت زیادی داشته باشید، مانع تمرکز افراد می شود! یا اینکه صفحه دسکتاپ کامپیوتر را طوری قرار دهیم که خیلی در معرض دید مدیران باشد، این کار باعث استرس بیشتر و حتی فرصت های بیشتری برای وقفه می شود. وجود هر گونه استرس در محیط باعث می شود سودمندی توسعه دهنده کاهش پیدا کند.

7. نقش مرحله مرحله جلو رفتن قلمرو در سودمندی توسعه دهنده

مرحله مرحله جلو رفتن قلمرو (که مرحله مرحله جلو رفتن تمرکز، مرحله مرحله جلو رفتن نیازمندی، مرحله مرحله جلو رفتن ویژگی و گاهی اوقات سندرم کیچن سینک نیز نامیده می شود) در مدیریت پروژه، به تغییرات غیرقابل کنترل در وسعت پروژه اشاره می کند. این موضوع زمانی می تواند رخ دهد که وسعت یک پروژه به خوبی تعریف، ثبت یا کنترل نشده است.

مرحله مرحله جلو رفتن قلمرو، به نسبت درخواست های ساده را به هیولاهای زمان بر و بسیار پیچیده تبدیل می کند! این موضوع بیشتر اوقات در زمان پیشرفت اتفاق می افتد! برای مثال، برای یک ویژگی ساده:

نسخه 1 (قبل از اجرا سازی): ویژگی «یک نقشه از موقعیت را نشان بده» است.

نسخه 2 (وقتی نسخه 1 تقریبا تمام شده است): ویژگی به «یک نقشه 3 بعدی از موقعیت نشان بده» تغییر یافته است.

نسخه 3 (وقتی نسخه 2 تقریبا تمام شده است): ویژگی دوباره به «یک نقشه سه بعدی از موقعیت نشان بده که کاربر می تواند در آن حرکت کند» تغییر می کند.

8. نقش فرایند تعریف محصول در سودمندی توسعه دهنده

شاید این مورد در نگاه اول عجیب به نظر برسد، اما در حقیقت درک آن بسیار آسان است. اگر یک گروه محصول بدون اینکه علایق مشابه را تصدیق کنند (از طریق بازخورد مشتری یا هر وسیله دیگری)، فقط اولویت های گروه خود را تعریف کنند و توسعه دهندگان ببیند که بیشتر ویژگی ها در نهایت استفاده نشده اند، این حس  به توسعه دهنده دست خواهد داد که کاری که انجام می دهند بی فایده است و انگیزه آنها از دست خواهد رفت. این موضوع سودمندی توسعه دهنده را زیر سوال می برد. ما همه می خواهیم حس کنیم تاثیرگذار هستیم و این موضوع برای توسعه دهندگان بسیار مهم تر است!

9. نقش عدم توجه به بدهی فنی در سودمندی توسعه دهنده

بدهی فنی یک تصمیم عمدی برای عدم اجرای بهترین راه حل یا ننوشتن بهترین کد، در انتشار سریعتر نرم افزار است.  برعهده گرفتن تعدادی بدهی فنی غیرقابل اجتناب است و می تواند در کوتاه مدت سرعت را در توسعه نرم افزار افزایش دهد. هرچند، بدهی فنی در طولانی مدت، منجر به پیچیدگی سیستم می شود و سرعت توسعه دهندگان را کاهش می دهد. افراد غیربرنامه ریز اغلب فقدان سودمندی توسعه دهنده را دست کم می گیرند و وسوسه می شوند که به سمت جلو حرکت کنند و این امر در نهایت به یک مسئله تبدیل می شود. اما اگر عامل یابی دوباره هیچ وقت بخشی از اولویت ها نباشد، نه تنها بر سودمندی توسعه دهنده تاثیر خواهد گذاشت، بلکه بر کیفیت محصول نیز تاثیرگذار خواهد بود.

10. نقش تعدد ابزار و سخت افزار در سودمندی توسعه دهنده

توسعه دهندگان هر روزه از ابزارهای زیادی برای برنامه ریزی، اعمال و ادغام کد خود استفاده می کنند. این امر بدون اینکه بگوییم اگر شما از ابزارهای «باستانی» استفاده کنید، بر سودمندی شما تاثیر می گذارد، جریان دارد. به طور مشابه، داشتن یک نمایشگر بزرگ در مقایسه با یک لبتاب می تواند تاثیر داشته باشند. با توجه به هزینه سخت افزار و حقوق توسعه دهنده، دست یافتن به 5 درصد سودمندی قطعا ارزش هر نوع سرمایه گذاری در آن زمان را دارد! فقط ابزارها و سخت افزاری که تیم توسعه دهنده شما ترجیح می دهد به آنها بدهید تا سودمندی توسعه دهنده به حداکثر رسد.

11. نقش «چگونگی» سند سازی در سودمندی توسعه دهنده

وقتی یاد می گیرید چطور کدسازی کنید، به ما گفته می شود که هر از گاهی نظر بدهیم. این ایده به این معنی است که بهتر است کامنت های زیادی داشته باشیم تا کم.

12. نقش ضرب العجل های فشرده و غیرممکن در سودمندی توسعه دهنده

این مورد آخر به تمایل مدیران بستگی دارد. برخی از مدیران اغلب از توسعه دهندگان می خواهند که تخمین بزنند، سپس آنها را مجبور می کنند تا جای ممکن آن تخمین ها را کم کنند و در نهایت به طور معجزه آسایی آن را به عنوان ضرب العجل در نظر می گیرند! مدیران حتی این را در نظر می گیرند که از آنجایی که خود توسعه دهندگان درباره تخمین «تصمیم گرفته اند»، به ضرب العجل ها متعهد هستند و بنابراین ضرب العجل ها باید آنقدر معتبر در نظر گرفته شوند که با مدیریت اصلی به اشتراک گذاشته شوند.

تعجبی نیست که توسعه دهندگان احساس می کنند که آن ضرب العجل ها غیرمنطقی هستند؛ این موضوع باعث تنش و عدم تمرکز در سودمندی توسعه دهنده می شود.

چطور تمام این موارد برای توسعه دهندگان خاص هستند؟

اگر به تمام این 12 مورد نگاه کنید، متوجه می شوید که آنها در حقیقت در بیشتر شغل های پروژه محور مشترک هستند. باید به یاد داشته باشیم که تاثیر هر کدام از این موارد برای توسعه دهندگان بسیار مهم تر است، چرا که آنها برای پیشرفت در کارهای خود نیاز به تمرکز بیشتری دارند.

اگر بعضی از نکته هایی که در بالا ذکر شد را در شرکت خود شناسایی کردید، شاید جالب باشد که همراه با توسعه دهندگان خود درباره آنها صحبت کنید تا سودمندی توسعه دهنده را افزایش دهید. با آنها صحبت کنید؛ ببینید آیا این موارد برای آنها مسئله ساز است و چطور می توانید آنها را حل کنید. بیاد داشته باشید که به بازخورد و دیدگاه آنها اعتماد کنید. درست است که تکنولوژی امروز با تکنولوژی 30 سال قبل تفاوت دارد، اما دَرسی که می توان از آن گرفت، همان است. وقتی سودمندی توسعه دهنده و گروه را در نظر می گیرید نمی توانید عامل انسانی را نادیده بگیرید. فرایندها، محیط و عادت های کاری خود را با گروه در میان بگذارید و اجازه دهید آنها شما را در اینکه چطور می توانید بیشترین سودمندی و تاثیر را داشته باشید، راهنمایی کنند.