راه های مختلفی برای اجرای پروژه توسعه نرم افزار وجود دارد. اینها عمدتاً عبارتند از:
توسعه دهنده اختصاصی: توسعه دهنده ای خواهید داشت که فقط برای شما و سازمان شما کار می کند. معمولاً قیمت ماهانه بین ارائه دهنده خدمات و مشتری توافق می شود. توسعه دهنده تمام وقت (تقریبا 160 ساعت در ماه) برای مشتری کار خواهد کرد.
Man-and-Material/ Time-and-Material/ Agile/ Team توسعه: در اینجا یک پروژه مورد توافق قرار می گیرد، اما اجرا توسط یک تیم چند رشته ای متشکل از مدیران پروژه، استادان اسکرام، تحلیلگران کسب و کار، توسعه دهندگان کسب و کار، نرم افزار/وب انجام می شود. توسعه دهندگان، آزمایش کنندگان نرم افزار، و غیره. در اینجا اغلب از یک متدولوژی Agile استفاده می شود و پس از هر Spring (یک چرخه توسعه که حدود یک ماه طول می کشد) زمان های توسعه تنظیم می شود. این یک قیمت ثابت نیست، بلکه یک بودجه تقریبی است که بر اساس آن توسعه خواهد یافت. این می تواند یک رقم تقریبی باشد، اما می تواند چندین برابر آن رقم بودجه باشد. در سازمان های بزرگ معمولاً این رویکرد ترجیح داده می شود.
قیمت ثابت: این معمولاً در پروژه های کوچکتر استفاده می شود، جایی که قیمت و الزامات ثابت هستند. این مقاله در مورد این نوع پروژه است و مواردی که در اجرای چنین پروژه ای با قیمت ثابت باید در نظر گرفته شود.
معرفی
بسیاری از شرکت های کوچک و متوسط بودجه ای برای انجام پروژه های نرم افزاری دارند. به خصوص در شرکت های غیر IT، دانش در مورد پروژه های نرم افزاری محدود است. آنها ترجیح می دهند قیمت ثابتی داشته باشند که در آن مدیر پروژه در آن شرکت ها به راحتی با مدیر عامل یا مدیریت شرکت در جریان باشد.
خیلی سخت است که بگوییم: ” توسعه آن حدود 2 تا 8 ماه طول می کشد و هر ساعت 100 دلار آمریکا هزینه دارد. همچنین می تواند 14 ماه باشد.
اگر شرکت خدمات فناوری اطلاعات به مشتری بگوید، ” 4 ماه طول می کشد و بودجه 30000 دلار آمریکا طول می کشد “، تیم مشتری می تواند در مورد آن تصمیم بگیرد.
مشکل بزرگ با آن این است -> اینگونه نیست که یک پروژه نرم افزاری کار می کند. دلایل زیر است:
نیازها در طول پروژه تغییر می کنند: هیچ کس، حتی مشتری، نمی داند که همه چیز در نرم افزار/راه حل وب برای موفقیت آمیز بودن آن باید وجود داشته باشد. معمولاً تنها پس از چند هفته، اولین نسخه یا اولین رابط های کاربری وب قابل مشاهده می شود. معمولاً زمانی است که مشتری متوجه می شود ” اوه، این قابلیت وجود دارد که بسیار مهم است. بدون این قابلیت، پروژه موفقیت آمیز نخواهد بود . اما هزینه پروژه و اجرای پروژه قبلاً از طرف مشتری و شرکت خدمات فناوری اطلاعات “تثبیت” شده است. این می تواند یک توپ نمایش باشد.
هیچ کس دقیقاً نمی داند که توسعه یک عملکرد چقدر طول می کشد: حتی اگر یک توسعه دهنده نرم افزار می تواند رقم تقریبی در مورد مدت زمان توسعه یک عملکرد ارائه دهد. او دقیقاً آن را نمی داند. این حتی برای با تجربه ترین توسعه دهندگان نیز صادق است. بنابراین: هر چه پروژه بزرگتر باشد، ریسک بالاتر است، که برآورد اشتباه است. با این حال، با یک بافر بزرگتر در برآورد پروژه، شرکت توسعه نرم افزار به نوعی سعی در کاهش این خطر دارد.
این بدان معناست که ارائه‌دهنده خدمات فناوری اطلاعات در حال حاضر این خطر را دارد که نمی‌داند برآورد توسعه‌دهنده درست بوده است یا خیر، و علاوه بر آن، مشتری ممکن است تغییراتی را در پروژه درخواست کند.
همچنین این دلیلی است که بر اساس گزارش Chaos که بسیار مورد اشاره قرار گرفته است، درصد زیادی (حدود 40 تا 60 درصد) از تمام پروژه های فناوری اطلاعات شکست می خورند.
زیرا در یک پروژه با قیمت ثابت، هیچ کس نمی‌خواهد تسلیم شود. مشتری نمی‌خواهد یک دلار آمریکا بیشتر بپردازد «زیرا قیمت ثابتی توافق شده است» و ارائه‌دهنده خدمات فناوری اطلاعات تنها بر ساخت آنچه توافق شده است اصرار می‌ورزد. زیرا الزامات در ابتدای پروژه ثابت شده بود.
در اینجا چند نکته را به خاطر بسپارید تا پروژه های با قیمت ثابت کار کنند
1) الزامات ثابت هستند (و تنها پس از اتمام این الزامات، قابلیت های جدید اضافه می شود)
پس از توسعه قابلیت‌های مورد توافق اولیه، نیازی به توقف توسعه نرم‌افزار نیست. پس از اتمام پروژه اولیه، مرحله بعدی قابل بحث و اجرا است.
نکته 1: مشتری باید کارهای زیر را انجام دهد: در برابر اصرار برای قرار دادن الزامات جدید در پروژه در حال اجرا مقاومت کنید. حتی اگر این احساس قوی را داشته باشید که پروژه برای مشتریان شما ارزشمند نخواهد بود.
این به اندازه کافی سخت خواهد بود تا نیازهای اولیه را به نتیجه برسانیم. به آن اضافه نکنید.
2) در دسترس بودن مشتری در طول دوره توسعه
در یک پروژه با قیمت ثابت، شرکت خدمات فناوری اطلاعات (در پروژه های کوچکتر) یک تا سه توسعه دهنده، یک سرپرست تیم، یک مدیر پروژه و طراح را اختصاص می دهد.
پس از شروع پروژه، همه چیز سریع پیش می رود و نباید زمان را هدر داد.
به ویژه مهم: اگر تیم فناوری اطلاعات در مورد یک کار سؤالی دارد یا نیاز به بازخورد دارد، باید در اسرع وقت توسط مشتری در دسترس قرار گیرد. بدترین چیزی که ممکن است اتفاق بیفتد این است که تیم توسعه باید 2 روز منتظر بازخورد مشتری باشد و برای آن زمان بیکار بنشیند.
اگر تیم توسعه بیکار بنشیند، آن زمان معمولاً از بودجه زمان ثابت کسر می شود و تیم سعی می کند وظایف را در زمان باقی مانده به پایان برساند. که معمولا ایده خوبی نیست، اما شاید تنها راه رو به جلو باشد.
بنابراین، برای بهره مندی از تیم توسعه و زمان آنها، مشتری باید به راحتی برای سؤالات ارائه دهنده خدمات فناوری اطلاعات در دسترس باشد.
نکته 2: بهترین راه حل برای این خواهد بود: مشتری یک نقطه تماس اختصاصی را فراهم می کند که در طول ساعات توسعه و در کل دوره توسعه در دسترس است. به عنوان مثال، جان اسمیت از مشتری از 01. جولای تا 30. اوت در دسترس خواهد بود. در این زمان جان اسمیت از طریق اسکایپ یا اسلک چت در دسترس خواهد بود و می تواند به سوالات تیم توسعه پاسخ دهد.
3) محتوا را به موقع ارائه دهید
در برخی موارد، مشتری ملزم به ارائه متن، فیلم، عکس و انواع دیگر محتوا یا مطالب است.
این محتوای از پیش توافق شده باید به موقع ارائه شود.
در برخی موارد، شرکت توسعه فعلا امکان استفاده از متن
ساختگی یا محتوای ساختگی را دارد.
اما برای خروجی مناسب، در برخی موارد به محتوا نیاز است.
نکته 3: مطمئن شوید که محتوا (مانند متن ها یا تصاویر) را در زمانی که تیم توسعه درخواست می کند، آماده داشته باشید.
توجه: همچنین می‌تواند مربوط به تایید، انجام برخی کارها، یا با سند پروژه‌ای باشد که باید امضا شود.
4) اجتناب کنید: “اما این بخشی از الزامات بود” (نکته مهم)
در واقع، الزامات هرگز نمی توانند به طور کامل در شروع پروژه درک یا نوشته شوند.
تیم توسعه نرم‌افزار معمولاً با برخی از URLهای نمونه ارسال شده توسط مشتریان، یک یا دو جلسه آنلاین و برخی مطالب نوشتاری مانند ایمیل یا PDF کار می‌کند.
معمولاً درک کلی از عملکردهای اصلی وجود دارد، اما تصویر 100 درصد واضح نیست.
این می تواند توسط هر دو شرکت توسعه برای گفتن ” اما این بخشی از نیاز نبود، این هزینه اضافی است” یا مشتری برای گفتن ” اما این بخشی از نیاز اولیه بود، ما قطعاً این را بدون هزینه اضافی می خواهیم” .
نکته 4: باید انصاف عمومی در هر دو طرف وجود داشته باشد. ارزش پول باید وجود داشته باشد. اما از طرف دیگر این کار نباید آنقدر دست نیافتنی باشد تا شرکت توسعه هیچ سودی از پروژه ها نداشته باشد.
توجه: به طور کلی مشتری (در صورتی که متخصص فناوری اطلاعات نباشد) باید به روش توسعه پیشنهادی شرکت فناوری اطلاعات اعتماد کند.
نتیجه
راه بهتر برای انجام پروژه های نرم افزاری استفاده از توسعه دهنده اختصاصی یا توسعه دهنده اختصاصی/ رویکرد چابک است. اما این امر برای برخی از شرکت ها به دلیل محدودیت بودجه امکان پذیر نیست.
بنابراین بسیاری از شرکت های خدمات فناوری اطلاعات این گزینه را برای پروژه های با قیمت ثابت ارائه می دهند.
برای مشتری، توجه به این نکته مهم است که وقتی قیمت ثابت است، الزامات نیز ثابت است. اغلب اوقات، قیمت ثابت با «بوفه همه چیز می‌توانید بخورید» اشتباه می‌شود، جایی که یک بار پرداخت می‌کنید و می‌توانید هر چقدر که می‌خواهید بخورید (توسعه دهید). برعکس، بیشتر شبیه گزینه منوی “A-La-Carte” است که در آن استیک را به قیمت 5 دلار آمریکا سفارش می دهید، اگر با آن سیب زمینی سرخ کرده می خواهید، باید 2 دلار آمریکا اضافی بپردازید.
اما همچنین: توسعه نرم افزار و تهیه غذا متفاوت است. زیرا هنگام ایجاد یک استیک، ورودی کاملا واضح است. در توسعه نرم افزار، همیشه اینطور نیست.
نکات این مقاله به موفقیت پروژه های با قیمت ثابت کمک می کند.