بسیاری از مقاله‌ها، نقش هدایت فناوری و مدیران مهندسی را مورد خطاب قرار می‌دهند. یکی از زمینه‌هایی که خیلی به آن بر می‌خوریم، نحوه افزایش باروی گروه است. اما قبل از این که انرژی خود را بر روی تلاش برای افزایش باروری آن‌ها متمرکز کنید، ممکن است اول بخواهید ببیند که چه چیزی آن را از بین می‌برد، تا پایه‌ای داشته باشید که بر حسب آن کار کنید. متاسفانه، با این که «مردم‌افزار» تقریبا ۳۰ سال پیش منتشر شد، ما گروه‌های زیادی را می‌بینیم که از کمبود باروری زیاد به روش‌های قابل توجهی رنج می‌برند.
هیچ کس انتظار ندارد که یک برنامه‌نویس بدون دسترسی به یک کامپیوتر، کاری را انجام دهد؛ اما بسیاری شرکت‌ها هستند که انتظار دارند برنامه‌نویسان بدون دسترسی به ذهن خود، کار را به اتمام برسانند. این مسئله هم به همان اندازه غیر واقعی است.
پس بیایید به لیست ۱۲ چیز که جلوی توسعه دهندگان را می‌گیرند و باروری آن‌ها را کم می‌کنند، وارد شویم. من سعی خواهم کرد که این لیست را از موثرترین تا غیر موثرترین، اولویت بندی کنم.
اگر برایتان سوال شده است که این موارد اصلا کمک می‌کنند یا نه، فقط درآمد توسعه دهندگان را در نظر بگیرید. حتی ۱۰ درصد هم بسیار زیاد است!
۱) مزاحمت‌ها و ملاقات‌ها
به نظر من، مزاحمت‌ها مهم‌ترین موارد در از بین بردن باروری توسعه دهندگان هستند. توسعه دهندگان نمی‌توانند مستقیما به جایی که قبل از ایجاد مزاحمت بودند، باز گردند. آن‌ها باید به ذهنیت توسعه‌دهی وارد شوند، و سپس به آرامی از جایی که کار را رها کردند، آن را ادامه دهند. این کار، به راحتی می‌تواند بیش از ۳۰ دقیقه زمان ببرد. هرچه مزاحمت‌های بیشتری وجود داشته باشد، ناامیدی بیشتری وجود دارد، کیفیت کمتری در کار وجود دارد، باگ‌های بیشتری بروز می‌دهند و...
ملاقات‌ها چه؟ تنها تفاوت میان یک ملاقات و یک مزاحمت، این است که ملاقات یک مزاحمت برنامه‌ریزی شده است، که باعث می‌شود حتی بدتر شود. اگر توسعه دهندگان بدانند که در هنگام کار قرار است مزاحمتی برایشان ایجاد شود، نمی‌توانند در یک کار پیشرفت کنند. پس اگر در یک یا دو ساعت بعد ملاقاتی دارند، نخواهند توانست که بر روی هیچ چیزی پیشرفت کنند.
چگونه می‌توان از این جلوگیری کرد؟ این بخش به شدت سندنگاری شده است؛ شما هیچ بهانه‌ای ندارید. ملاقات‌های کوتاه مدتی را در ابتدای روز، یا برای مثال قبل از ناهار داشته باشید، تا از مزاحمت‌های غیر ضروری جلوگیری کنید.
۲) مدیریت جزئی
در میان انواع مختلف مدیران، مدیران جزئی ممکن است در زمینه باروری توسعه دهنده، بدترین‌ها باشند. البته، مدیران جزئی می‌خواهند ملاقات‌ها و مزاحمت‌های بدون برنامه‌ریزی داشته باشند. اما مسئله فقط این نیست. آن‌ها نوعی کمبود اعتماد دارند، و با این کار شما همینطور حس می‌کنید که مهارت و توانایی کمتری در انجام کار دارید. هر انگیزه‌ای که یک توسعه دهنده بین مزاحمت‌ها داشته، در همان زمان از بین می‌رود. اثر آن، فراتر از باروری می‌رود. مدیران جزئی می‌توانند اولین علت برای ترک کردن توسعه دهندگان، یا حداقل تغییر گروه باشند.
۳) مبهم بودن
راه‌های زیادی برای نشان دادن مبهمی وجود دارد. گزارش‌های باگ از طرف کاربران مانند «برنامه خراب است، برطرفش کن!» به توسعه دهنده اطلاعات کافی نمی‌دهد تا با توجه به آن کار کند. ضمنا، داشتن یک الگوی گزارش باگ در این موارد می‌تواند کمک کند.
یا یک مشخصات ناواضح درباره یک امکانات جدید یک برنامه، که در آن توسعه دهنده فقط شروع به پیاده‌سازی چیزی که درست به نظر می‌آید می‌کند، و سپس مجبور می‌شود پس از این که مدیر جزئیات مورد انتظار را بهتر توضیح داد، کار را از اول شروع کند.
اولویت‌بندی ناواضح هم در این دسته قرار دارد. زمانی که توسعه دهنده صرف می‌کند تا برایش سوال باشد که بر روی عملیات درست کار می‌کند یا نه، می‌تواند جلوگیری شود. و اگر هم زمانی مدیر به آن‌ها بگوید که چرا بر روی موضوعی خاص کار می‌کردند، باز هم مقدار زیادی ناامیدی نسیبشان خواهد شد.
۴) مدیریت به سبک مرغ دریایی
آیا تا به حال این اصطلاح را شنیده‌اید؟ این مسئله زمانی پیش می‌آید که مدیران کاملا خارج از کار هستند، اما گاهی اوقات پایین می‌آیند تا همه چیز را خراب کنند. «این اشتباه است، این بد به نظر می‌رسد و...» باید اعتراف کنم که تصور این موضوع را دوست داشتم، اما این مسئله بیشتر از آنچه که ما می‌خواهیم پیش می‌آید. این رفتار به شدت برای توسعه دهندگان ناامید کننده است. آن‌ها نخواهند توانست که برای چند ساعت بعدی، یا گاهی اوقات برای چند روز به میدان باز گردند.
۵) غرور اعتبار
آیا تا به حال مدیر یا توسعه دهنده دیگری داشته‌اید که تمام اعتبار مربوط به کاری که شما مشغولش بوده‌اید را به نام خودش ثبت کند؟ توسعه دهندگان، شایستگی را از همه چیز با ارزش‌تر می‌دانند. گرفتن اعتبار یک شخص دیگر، برابر با گرفتن شایستگی او برای خود و حذف کردن آن شایستگی از او است. این مورد در لیست من در جای بالایی قرار دارد، و به نظرم به قدری تنش ایجاد می‌کند که باروری توسعه دهنده را برای مدتی از بین می‌برد.
۶) محیط (صداها، حرکت، طراحی فضای کار و...)
این مورد ممکن است برای غیر برنامه‌نویسان عجیب باشد، اما محیطی که توسعه دهندگان در آن کار می‌کند، تاثیر مهمی بر روی فعالیت‌های آن‌ها دارد. برای مثال، داشتن برخی صداهای سفید (تهویه با صدای بلند، شنیدن صدای رد شدن خودروها و کامیون‌ها) به آن‌ها کمک نمی‌کند که بهتر تمرکز کنند. به همین علت است که بسیاری از ما یک هدست بر روی سر خود می‌گذاریم.
به طور مشابه، اگر محیط کار به گونه‌ای طراحی شده باشد که حرکت زیادی داشته باشد، به توسعه دهنده کمکی نمی‌کند. یا مثلا این که مانیتورها به گونه‌ای جهت‌دهی شده باشند که مدیران دید خوبی داشته باشند. این مسئله مقداری استرس اضافی، و حتی موقعیت‌های بیشتری برای مزاحمت ایجاد می‌کند.
۷) به هم ریختگی scope
به هم ریختگی scope در مدیریت پروژه، به تغییرات کنترل نشده در scope پروژه اشاره دارد. این مسئله می‌تواند وقتی پیش بیاید که scope یک پروژه به درستی تعریف، سندنگاری یا کنترل نشده است.
به هم ریختگی scope درخواست‌های نسبتا ساده را تبدیل به هیولا‌های پیچیده و وقت گیر می‌کند. و اکثر مواقع این اتفاق در طی توسعه دهی پیش می‌آید. برای مثال، برای یک امکان ساده:
نسخه ۱ (قبل از پیاده‌سازی): امکان مورد نظر این است که «یک نقشه از موقعیت را نشان دهیم».
نسخه ۲: این امکان تبدیل به «نمایش یک نقشه سه بعدی از موقعیت» می‌شود.
نسخه ۳: باز هم این امکان به «نمایش یک نقشه سه بعدی از موقعیت که کاربر بتواند در آن جا به جا شود» تغییر می‌کند.
۸) روند تعریف محصول
پس این مورد ممکن است در ابتدا عجیب به نظر برسد، اما در واقع درک آن بسیار ساده است. اگر یک گروه تولیدی، اولویت‌های گروه خود را بدون اعتبارسنجی بهره امکانات متناظر تعریف کند، (مثلا از طریق نظر مشتریان) و کاربران ببینند که اکثر امکانات در واقع استفاده نمی‌شوند، حس خواهند کرد که کاری که انجام می‌دهند بدون کاربرد است و انگیزه خود را از دست خواهند داد. همه ما می‌خواهیم که حس موثر بودن داشته باشیم، و این ممکن است برای توسعه دهندگان حتی مهم‌تر باشد.
۹) کمبود توجه به بدهی فنی
بدهی فنی، یک تصمیم حساب شده برای پیاده‌سازی راه حلی که بهترین نیست یا کدی که بهترین نیست، برای انتشار سریع‌تر برنامه است. گرفتن بدهی فنی، اجتناب‌ناپذیر است و می‌تواند سرعت را در توسعه نرم‌افزار افزایش دهد. گرچه، در طی مدت طولانی، به پیچیدگی سیستم کمک می‌کند که توسعه دهندگان را کندتر می‌کند. غیر برنامه‌نویسان اغلب از دست دادن باروری را دست کم می‌گیرند و وسوسه می‌شوند که همیشه به سمت جلو پیش بروند، و این مسئله تبدیل به یک مشکل می‌شود. اما اگر بازسازی هیچ وقت بخشی از اولویت‌ها نباشد، نه تنها باروری، بلکه کیفیت محصول را نیز تحت تاثیر قرار خواهد داد.
۱۰) چندگانگی ابزار و سخت‌افزار
توسعه دهندگان از ابزار زیادی برای برنامه‌نویسی و ادغام کد خود استفاده می‌کنند. هرچه خودکارسازی بیشتر باشد، بهتر است. نیازی به گفتن نیست که اگر از ابزار قدیمی استفاده کنید، بر روی باروریتان تاثیری خواهد داشت. به طور مشابه، داشتن یک صفحه بزرگ در مقابل داشتن فقط یک لپتاپ، می‌تواند موثر باشد. با توجه به هزینه سخت‌افزار و حقوق توسعه دهنده، داشتن فقط ۵ درصد باروری بیشتر، قطعا ارزش سرمایه‌گذاری را دارد. فقط سخت‌افزارها و ابزاری که گروهتان ترجیح می‌دهد را در اختیارشان قرار دهید. (سخت‌افزار به صورت فردی، و ابزار به صورت گروهی)
۱۱) سندنگاری «چگونه»
وقتی که در حال یادگیری کدنویسی هستید، گفته شده است که بیشتر کامنت‌گذاری کنید. این ایده یعنی این که بهتر است تعداد زیادی کامنت داشته باشید، تا این که اصلا کامنت نداشته باشید. متاسفانه، بسیاری از برنامه‌نویسان به اشتباه این جمله را به این صورت تفسیر می‌کنند که بر روی هر خط کد، یک کامنت قرار دهند، که به همین علت گاهی اوقات چنین کدهایی را می‌بینیم:
r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}
آیا اصلا می‌دانید که این کد چیست؟ من هم نمی‌دانم. مشکل این است که در حالیکه تعداد زیادی کامنت وجود دارد که کد را توضیح می‌دهند، هیچ کامنتی توضیح نمی‌دهد که دقیقا چه اتفاقی می‌افتد. اگر باگی در برنامه وجود داشت و شما به این کد برخوردید، نخواهید دانست که از کجا شروع کنید.
۱۲) مهلت‌های به شدت تنگ
این مورد آخر به گرایش مدیران مربوط است که از توسعه دهندگان یک زمان احتمالی بخواهند، و آن‌ها را تحت فشار قرار دهند تا در حد ممکن این زمان را کاهش دهند، و سپس به طور جادویی این زمان را به عنوان مهلت پایان کار تعیین کنند. حتی مدیران گاهی می‌گویند با توجه به این که توسعه دهندگان «تصمیم گرفتند» تا زمان احتمالی را تخمین بزنند، پس به آن زمان متعهد شدند و بهتر است که این زمان به مدیریت‌های سطح بالاتر منتقل شود.
جای تعجبی ندارد که توسعه دهندگان حس می‌کنند که این مهلت‌ها غیر منطقی و خودسرانه هستند. این مسئله تنش، و عدم قابلیت تمرکز را ایجاد می‌کند.
این موارد چگونه برای توسعه دهنده خاص هستند؟
اگر به تمام این ۱۲ مورد نگاه کنید، خواهید دید که در اکثر پروژه‌ها بسیار رایج هستند. فقط مسئله این است که تاثیر هر کدام برای توسعه دهندگان مهم است؛ زیرا آن‌ها نیاز دارند که عمیقا بر روی عملیات خود تمرکز کنند.
اگر برخی از نکات بالا را در شرکت خود تشخیص میدهید، شاید جالب باشد که آن‌ها را به توسعه دهندگان خود خطاب کنید. با آن‌ها صحبت کنید. ببینید که این موارد یک مشکل هستند یا نه، و چگونه می‌توانند حل شوند. هر چه که بگویند، مهم‌ترین چیز این است که به نظرات و بینش‌های آن‌ها اعتماد کنید. و در حالیکه فناوری امروزی بسیار متفاوت‌تر از ۳۰ سال پیش است، درس موجود همچنان مشابه است. وقتی که باروری گروه‌ها در نظر می‌گیرید، نمی‌توانید فاکتور انسان را نادیده بگیرید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید