دفتر مدیریت پروژهمطالب ویژه

۱۳ نشانه شکست پروژه نرم‌افزاری شما (بخش دوم)

۵. مدل بدون هزینه

تخمین هزینه هر کاربر ساده‌تر از هر زمان دیگری است. کامپیوترهای ابری ظرف یک ساعت در دسترس هستند و سیستم‌های بدون سرور بر مبنای تراکنش قیمت‌گذاری می‌شوند. اگر کاربران N بار در ماه و به‌اندازه M بایت به سرورهای شما سر بزنند، می‌دانید هزینه محاسبات روی آن دیتا چقدر خواهد شد؟ برخی از تیم‌های پروژه هیچ ایده‌ای در مورد هزینه‌ها ندارند و بعد زمانی که کشف می‌کنند تراکنش با هزینه X فقط Y درآمد تولید می‌کند که متأسفانه X>Y. این نرم‌افزار ممکن است کامپایل شده و بدون خطا و باگ اجرا شود اما پروژه ادامه پیدا نمی‌کند چراکه ماشینی است که پول از دست می‌دهد. پیگیری هزینه‌ها و داشتن یک هدف مشخص ضروری است در غیر این صورت توسعه‌دهندگان چیزی را می‌سازند که خیلی عالی است اما نیاز به هزاران ماشین ابری پرقدرت دارد.

۶. توسعه‌دهندگان دائماً تسلیم یک نابغه می‌شوند

خیلی خوب است که افراد باهوش روی پروژه شما کار کنند. خطر زمانی شکل می‌گیرد که یک ذهن بر بقیه حکم‌فرما شود. به‌جز چند مورد عجیب‌وغریب، معمولاً علامت خوبی نیست زمانی که همه می‌گویند:” بیایید از فرد X بپرسیم” و شخص X همیشه یک نفر است. اگر هر اتفاقی برای شخص X بیفتد، پروژه سرگردان خواهد شد. گرچه اگر X پروژه را ترک نکند هم همه‌چیز بدتر خواهد شد چراکه همه می‌خواهند تصمیماتشان را با نظر X جلو ببرند و این گلوگاه آن‌ها را از حرکت روبه‌جلو بازمی‌دارد. ممکن است X از قدرت لذت ببرد و ممکن است X یک نابغه پذیرفته‌شده باشد اما اینکه تأیید همه کارها به عهده X باشد موجب آهستگی کار می‌شود.

۷. استانداردهای کد بر گفت‌وگو ارجحیت دارند

زیبایی‌شناسی مهم است اما برخی از توسعه‌دهندگان این موضوع را به حد اعلی می‌رسانند مثلاً با وسواس در مورد فضاهای خالی بین کدها. به‌اصطلاح استانداردهای کد نویسی فقط یکی از راه‌هایی است که اعضای سمی تیم با آن می‌توانند اعمال قدرت کنند. آن‌ها حین بررسی و مرور کدها زمانی که فضای اشتباه جای گذاری شده یا Tab پیدا می‌کنند به شکل خجالت‌آوری بیان می‌کنند “استانداردها برآورده نشده است.” عملکرد یک پروژه درنهایت باعث ایجاد یا شکست پروژه می‌شود و اگر تیم زمان خود را برای بررسی زیبایی‌شناسی کدهای داخلی که هرگز توسط افراد خارج از شرکت دیده نمی‌شود تلف کند، خوب هرگز به هدف نمی‌رسد.

۸. شاخص‌ها خوب به نظر می‌رسند

اندازه‌گیری پیشرفت تیم با استفاده از شاخص‌ها، شر ضروری است اما ایمان زیاد داشتن به آن خطرناک است. زیرا تفریح توسعه‌دهندگان هر شاخصی را که بگویید در برمی‌گیرد. یکی از دوستان تعریف می‌کرد که رئیسش شاخصی داشت که درصد به‌کارگیری توابع را با استفاده از کامنت ها اندازه می‌گرفت و از نرم‌افزار معروف هوش مصنوعی Chatterbot (نرم‌افزاری برای شبیه‌سازی مکالمات انسان) Eliza استفاده می‌کرد تا مطمئن شود تمامی توابعی که استفاده کرده است کامنت دارند و مهم نیست که این کامنت ها چقدر پوچ باشند. او همچنین یک سری کد هم سریعاً نوشت تا نام متغیرها گیراتر شود و آن‌ها در کامنت های بی‌معنی جا داد. آمارش فوق‌العاده بود. رئیسی که این‌همه کامنت خواسته بود، هرگز آن‌ها را نمی‌خواند و لذا این رئیس هرگز عاقلانه عمل‌نکرده است. او فقط کدی بزرگ و ۱۰۰ درصد کامنت شده روی داشبوردش می‌بیند و می‌رود به کار خودش می‌رسد. (مثلاً بازی گلف!)

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا