مدیریت ریسک پروژه IT چیست؟ با رایجترین ریسکهای توسعه نرمافزار آشنا شوید
۹ شهریور ۱۳۹۹
![مدیریت ریسک پروژه IT](https://cms.liara.ir/wp-content/uploads/2020/08/it-project-risk-management.jpg)
همه ما در طول زندگی، با خطرات و ریسکهای متعددی روبهرو میشویم. آیا تاکنون به این فکر کردهاید با پذیرش ریسک، چه اتفاقی ممکن است در آینده برای شما رخ بدهد؟ برای مثال، فرض کنید که قصد دارید از خیابان عبور کنید و چراغ راهنما، قرمز است. چه اتفاقی ممکن است برای شما رخ بدهد؟ ممکن است در هنگام عبور از خیابان، تصادف کنید. این اتفاق، حاصل ریسکی است که برای عبور از خیابان با چراغ قرمز، آن را پذیرفتهاید. اما در این مطلب قصد داریم که به ارزیابی ریسک پروژه IT بپردازیم و پس از آن، مدیریت ریسک پروژه IT را بررسی کنیم.
برای درک بیشتر موضوع، بندبازی را تصور کنید که قصد دارد از روی یک طناب، که دو ساختمان را بهیکدیگر متصل کرده، عبور کند. Philippe Petit بندبازی بود که توانست این کار پرخطر را با موفقیت به انجام برساند، احتمالا این پرسش را بارها و بارها، با خود تکرار کرده است. او قطعا از ریسک انجام این کار پرخطر، بهخوبی آگاه بوده است.
اما چگونه میتوانید مسیر اجرای یک پروژه را پیشبینی کنید؟ برای هر پروژهای که در دست انجام دارید، میتوانید یک لیست کامل از ریسکهای احتمالی، تهیه کنید. در این میان، باید بدانید که هیچ پروژه بدون ریسکی وجود ندارد و ریسک، جزئی از ماهیت هر پروژه است که باید بهصورت آیندهنگرانه، برای آن برنامهریزی کنید.
ریسک چیست؟
در ابتدا، با ارائه تعریفی از واژه ریسک، شروع میکنیم. واژه ریسک، به موارد زیر اشاره میکند:
- رویدادی که هنوز رخ نداده است،
- احتمال وقوع یک رویداد،
- رخدادی که میتوان از وقوع آن جلوگیری کرد،
- اتفاقی که وقوع آن میتواند جنبه مثبت یا منفی داشته باشد،
- رویدادی که میتوان پیامدها و خطرات ناشی از آن را به حداقل یا حداکثر میران ممکن رساند یا آنها را پذیرفت.
مدیریت ریسک پروژه IT و علت ریسک
زمانیکه از مدیریت ریسک پروژه IT صحبت میکنیم، لازم و ضروری است که علل احتمالی چنین ریسکهایی را نیز تعیین کنیم. زمانیکه ما بتوانیم ریسکهای احتمالی پروژه IT را دستهبندی کنیم، یافتن و مدیریت این ریسکها، بسیار سادهتر خواهد بود. با این وجود، ما برای دستهبندی ریسکهای احتمالی، نیاز داریم که ماهیت پروژه IT دریافتی، را بررسی کنیم. در زمینه مدیریت ریسک پروژه IT، میتوانیم سه مورد از عمدهترین خطرات مرتبط با آن، شامل ریسک بیرونی، ریسک درونی و ریسک شخصی، را بررسی کنیم. این خطرات بهصورت زیر تعریف میشوند:
- ریسک بیرونی (external risk)، حاصل تاثیر مشتری بر روی پروژه است.
- ریسک درونی (internal risk) به خودی خود، بهعنوان نتیجهای از فرایند توسعه نرمافزار، حاصل میشود.
- ریسک شخصی (personal risk)، نتیجهای از تلاشها، کیفیت کار و میزان تعهد اعضای تیم توسعهدهنده پروژه بهشمار میآید.
در ادامه، برخی از مهمترین و رایجترین ریسکهای مدیریت پروژه IT را که براساس تجربیات متخصصین تضمین کیفیت (QA: Quality Assurance) و مدیران پروژه حاصل شده است، مشاهده میکنید. در مورد هر ریسک، سعی میکنیم که پیامدها، استراتژیها و راهکارهای ممکن برای مقابله با آنها را بهصورت جداگانه بررسی کنیم.
رایجترین ریسکها در مدیریت پروژههای توسعه نرمافزار
تغییر نیازمندیها و اولویتهای پروژه
یک پروژه در طول عمر خود، دستخوش تغییرات بسیاری میشود. برای مثال، مفاهیم، نیازمندیها، تعداد وظایف تعریفشده در هر sprint (اسپرینت: بازههای زمانی کوچک تعریفشده در طول اجرای پروژه) و اولویتهای پروژه، همگی میتوانند تغییرات مختلفی را تجربه کنند. گاهی اوقات، یک مشتری ممکن است در فرایند اجرای پروژه و درست زمانیکه بخشی از پروژه براساس برنامهریزی قبلی در حال انجام است، تغییر نظر بدهد. البته این موضوع، هزینههای اجرایی پروژه را نیز افزایش میدهد.
پیامدها
- عدم تناسب زمانبندی و تعداد کارهایی که باید در هر اسپرینت، انجام شوند که باعث میشود برنامهریزی اسپرینتها بهینه نباشد. بهعبارت دیگر، تغییرات در پروژه ممکن است منجر به افزایش فشار کاری داخل اسپرینتهایی با زمانبندی کمتر شود یا نسبت به زمان هر اسپرینت، وظایف کمی برای آن تعریف شود.
- نیمهکاره رها شدن وظایف تعریفشده در پروژه
- نیاز به بازنویسی کامل یا بخشی از برنامه
- اعمال تغییر در زمانبندی پروژه
- کامل نشدن اسپرینتها یا تمدید زمان آنها
- نیاز ناگهانی به افزودن افراد جدید به تیم توسعه نرمافزار
راهحل
زمانیکه قصد دارید پروژه را دستخوش تغییرات کنید، ضروری است که تاثیر این تغییرات را بر روی بخشهای مختلف آن پروژه، بهطور دقیق بررسی کنید. برای مثال، باید تاثیر این تغییرات را بر وضعیت فعلی پروژه، میزان تلاش و هزینه موردنیاز برای اعمال این تغییرات و همچنین ریسک تاخیر در تحویل پروژه را ارزیابی کنید. این ارزیابیها و تحلیلها، بهشما کمک میکنند تا وظایف را بهطور کارآمد و موثر تقسیمبندی کنید، اولویتهای پروژه را بهروزرسانی کرده و همچنین بتوانید اطلاعات دقیقی از امکان یا عدم امکان تحویل بهموقع بخشهای مختلف پروژه، به مشتری ارائه کنید.
هر سوالی را که در این زمینه، بدون پاسخ رها کنید، بهمعنای آن است که ریسک و عواقب آن را بدون هیچگونه قید و شرطی، پذیرفتهاید. این یک روش متداول در فرایند توسعه نرمافزار، بهشمار میرود. بههمین دلیل، بسیار مهم است که تمامی ذینفعان پروژه، عواقب تغییرات موردنظر در آن پروژه را درک کرده و در صورت نیاز، بهصورت مشترک بهمنظور ارائه راهحلی برای مقابله با این پیامدها، سازش کنند.
عدم تعهد افراد تیم توسعه نرمافزار
تعهد اعضای تیم، یکی از عوامل ضروری برای موفقیت هر پروژهای محسوب میشود. به همین دلیل لازم است که تمامی اعضای تیم توسعه، به هدف مشترک تیم متعهد باشند، نقش خودشان را در تیم درک کرده و از سایر همکاران خود، پشتیبانی کنند.
در واقع منظور از تیم، شامل تمامی ذینفعان پروژه، ازجمله مشتریان، مدیران پروژه، توسعهدهندگان، متخصصین تست و ارزیابی نرمافزار، طراحان و تحلیلگرانی است که در پیشبرد پروژه، ایفای نقش میکنند.
پیامدها
- تاخیر در تحویل بخشهای مختلف پروژه در مهلتهای مقرر (ددلاینها)
- ایجاد اثرات منفی در انگیزه و روحیه سایر اعضای تیم
راهحل
توجه خود را به همکاران و سایر اعضای تیم معطوف کرده و سعی کنید بفهمید که چهچیزی، میتواند میزان تعهد آنها را تقویت کند. آنها باید احساس خوبی از شرایط خود داشته باشند و در عین حال، بتوانند بر روی کارشان نیز تمرکز کنند. بنابراین سعی کنید که به رشد فردی همکارانتان، کمک کنید. برای این کار، میتوانید با آنها صحبت کرده و از تواناییها و مهارتهای آنها، تعریف و تمجید کنید. همچنین سعی کنید تا حد ممکن، جزئیات پروژه را در اختیار تمامی اعضای تیم قرار دهید؛ تا جاییکه بتوانند به مسئولیتشان، بهعنوان بخش مهمی از یک پروژه بزرگتر و مهمتر، نگاه کنند و در راستای موفقیت آن، بیشترین تلاش خود را بهکار بگیرند.
ارتباطات ضعیف اعضای تیم توسعه نرمافزار با یکدیگر
برقراری ارتباطات صحیح میان همکاران و اعضای تیم، یک عامل ضروری و حیاتی برای تاثیرگذاری بیشتر کار در فرایند توسعه نرمافزار، بهشمار میرود. هرگونه ضعف در زمینه ارتباطات، میتواند منجر به بروز اختلال در فرایند اجرای پروژه شود. اما پیامدهای ارتباطات ضعیف اعضای تیم توسعه نرمافزار، کدامند؟
پیامدها
- ایجاد شکاف در دانش تیمی پیرامون پروژه موردنظر
- تکرار شدن و دوباره کاری وظایف
- کاهش بهرهوری
راهحل
برگزاری جلسات منظم با همکاران و اعضای تیم توسعه نرمافزار، با هدف تکمیل وظایف، کارها و همچنین بهاشتراکگذاری دانش تیمی از پروژه، بهعنوان یک بخش ضروری و مهم از فرایند اجرای پروژه، بهشمار میآید. در طی این جلسات، تمامی افراد باید احساس امنیت و آرامش داشته باشند و همچنین، به تمامی اعضا شانس صحبت کردن و به اشتراک گذاشتن اطلاعات و نکات مدنظرشان، نیز داده شود. سعی کنید هیچیک از سوالات مطرح شده را بدون ارائه پاسخ مناسب، رها نکنید. اگر پاسخ پرسشی را نمیدانید، باید به سایر اعضا اطلاع بدهید که در پی یافتن پاسخ موردنظر هستید و بهزودی آن را با تیم بهاشتراک میگذارید.
بسیار ضروری است که همه افراد تیم، نقش و مسئولیت خودشان را در پیشبرد پروژه، درک کنند. برگزاری دورهمی و جلسات غیرکاری با همکاران، نیز میتواند به بهبود فضای تیمی کمک کند.
عملکرد ضعیف و غیرکارآمد در تهیه مستندات پروژه
منظور از مستندات پروژه چیست؟ مستندات پروژه شامل حداقل محصول قابلارائه (MVP: Minimum viable product)، تعریف وظایف در نرمافزار JIRA و همچنین تعریف فضای پروژه در نرمافزار Confluence است که همگی برای موفقیت پروژه، ضروری هستند.
پیامدها
- هرجومرج و بیبرنامگی
- طرح سوالات تکراری و بیفایده توسط اعضای تیم پیرامون اطلاعات پایه پروژه
- عدم برخورداری اعضای تیم از معیارهای مناسب برای استفاده از آنها، در طول اجرای پروژه و پس از آن
- اطلاعات ناکافی و ناقص اعضای جدید تیم که در میانه فرایند اجرای پروژه، به تیم میپیوندند.
راهحل
حتی تهیه حداقل مستندات یک پروژه نیز مسیر طولانی را طی میکند تا از بدترین پیامدها در مسیر اجرا و پیادهسازی پروژه، جلوگیری کند.
یکی از بهترین متدولوژیها در مهندسی و توسعه نرمافزار، روش Agile است و اینچنین بیان میکند که کارکرد نرمافزار بسیار مهمتر از تهیه مستندات با جزئیات زیاد است. اما این موضوع به معنای آن نیست که تهیه مستندات پروژه حائز اهمیت نیستند.
امابهترین راهکار برای مقابله با این مسئله چیست؟
سعی کنید در همان ابتدای کار، زمانی را به نوشتن صحیح مستندات پروژه اختصاص بدهید. در این صورت، با هیچ مشکل و بهانهای در زمان اجرا و پیادهسازی پروژه، مواجه نخواهید بود. برای این کار میتوانید از ابزارهایی مانند JIRA، Confluence یا QA Touch استفاده کنید که انجام کارها را بری شما بسیار سادهتر میکنند. علاوهبراین، ابزارهای تخصصیتری نیز وجود دارند که در تهیه مستندات پروژه برای APIها و سایر خدمات پروژه، به شما کمک میکنند. باید تعیین کنید که چه اطلاعاتی، باید همیشه در دسترس باشند. بهترین ابزار برای ذخیرهسازی پیوسته اطلاعات در طول اجرای پروژه، Confluence است. در این ابزار قادر خواهید بود که تمامی اطلاعات اصلی پروژه، اعضای تیم توسعه نرمافزار و نقشها و وظایف آنها، رمزهای عبور و سایر اطلاعات دسترسی به محیط و موجودیتهای پروژه، تعاریف کاربران یا فهرست ویژگیها و قابلیتهای نرمافزار، را در آن ذخیره کنید.
همواره از یک روش خاص برای نامگذاری و تعریف وظایف و کارها، استفاده کنید. به خاطر داشته باشید که مستندات پروژه، نباید خیلی گسترده و پر از جزئیات غیرمفید و غیرضروری باشد. هدف از تهیه مستندات پروژه، این است که در آن کلیت پروژه را بهصورت واضح و روشن تعریف کرده و یک مسیر و راهکار ساده برای اجرای آن، ارائه کنید. بنابراین، سعی کنی که تنها اطلاعات موردنیاز را در آن ثبت کرده و از نوشتن هرگونه اطلاعات غیرضروری در آن، اجتناب کنید تا مستندات پروژه گمراهکننده نباشد.
غیبت ناگهانی اعضای تیم توسعه بدون هماهنگی قبلی
هر بار غیبت ناگهانی اعضای تیم توسعه نرمافزار، بدون برنامهریزی و هماهنگی قبلی، میتواند برای پروژههای درحال اجرا، نگرانکننده باشد. احتمال وقوع این اتفاق، بهویژه در فصلهای پاییز و زمستان که احتمال ابتلا به بیماری بیشتر است، افزایش پیدا میکند.
پیامدها
- بینظمی
- تاخیر در تحویل وظایف و کارها
- زمانیکه افراد غیبت میکنند، نمیتوانند در جلسات مرتبط با پروژه شرکت کنند. به این ترتیب نمیتوانند در جریان اطلاعات پیرامون پروژه قرار بگیرند و در نهایت، بهدلیل کمبود دانش و اطلاعات کافی از آن پروژه، از روند توسعه دور میمانند. بهویژه اگر این غیبتها بدون هماهنگی قبلی صورت گرفته باشند، برنامهریزی برای جبران آنها بهمراتب سختتر خواهد بود. در این شرایط، اهمیت تهیه کامل و جامع مستندات پروژه، مجددا یادآوری میشود.
- کاهش انگیزه و روحیه تیمی
راهحل
نکته اصلی این است که تمامی اعضای تیم، باید دانش و نکات ضروری مرتبط با پروژه را با یکدیگر به اشتراک بگذارند. بسته به وضعیت پروژه و اینکه غیبت اعضای تیم چقدر طول بکشد، مدیر پروژه باید بتواند در رابطه با جایگزینهای احتمالی موردنیاز نیز تصمیمگیری کند. در این شرایط، با ارائه مستندات کامل و اطلاعات کافی از روند آن پروژه، شروع کار برای اعضای جدید و همچنین برای کارکنانی که برای مدتی در تیم حضور نداشتهاند، نیز سادهتر خواهد بود.
عدم ارتباط کافی با مشتری
آیا مشتری شما پاسخگو نیست؟ آیا چندین بار تلاش کردهاید که با او در تماس باشید، اما موفق نشدهاید؟ ممکن است که بهصورت اتفاقی، مشتری شما به مرخصی رفته و فراموش کرده باشد که به شما و سایر اعضای تیم، اطلاع بدهد.
پیامدها
- عدم امکان تحویل بهموقع پروژه، بهدلیل عدم پاسخگویی و عدم همکاری مشتری با تیم
- کاهش انرژی و انگیزه سایر اعضای تیم
راهحل
سعی کنید اهمیت برقراری ارتباط عمیق و نزدیک میان مشتری و تیم توسعه نرمافزار را از همان جلسه اول، به مشتری خود نشان دهید. هدف از این کار، این است که اهمیت مشارکت و حضور در روند توسعه نرمافزار را به مشتری دهید. بهطوری که مشتری بداند که باید پیوسته در دسترس باشد و در شرایطی که در دسترس نخواهد بود، از قبل هماهنگیهای لازم را با تیم توسعه انجام بدهد.
در واقع شما باید مشخص کنید که کدام تصمیمگیریها، باید با حضور و همکاری مشتریان انجام شوند و کدامیک، باید توسط توسعهدهندگان یا مدیران پروژه، بهتنهایی اتخاذ شوند. زمانیکه شما درخواستی را از طریق ایمیل برای مشتری ارسال میکنید، بهترین کار این است که در پیام خود بهطور واضح و دقیق توضیح بدهید که چرا تاخیر در پاسخگویی، میتواند برای پروژه مشکل آفرین باشد. برای مثال، ممکن است تاخیر در پاسخگویی مشتری منجر به بروز مشکل در تحقق ددلاینها شود. از این رو، برای جلوگیری از بروز هرگونه مشکل با مشتری، تمامی مسائل و جزئیات را با ذکر دلیل کافی، برای آنها توضیح بدهید. اما اگر هیچ راهی برای ارتباط با مشتری وجود نداشته باشد، مدیر پروژه باید در جهت بهبود ارتباطات تیم با مشتری، وارد عمل شود.
عدم تحویل بهموقع پروژه در مراحل مختلف
شاید نتوان پروژهای را یافت که در هیچکدام از مراحل آن، تاخیری دیده نشود. مواردی مانند تغییر نیازمندیها در طول اجرای پروژه، تخمین اشتباه در تعیین و زمانبندی وظایف و کارها، تستها و آزمایشهایی که با شکست مواجه شدهاند، غیبت اعضای تیم توسعه بدون هماهنگی قبلی و برنامهریزی، ارتباط ضعیف و نامناسب با مشتری و بسیاری دیگر از موارد، عواملی هستند که مانع برنامهریزی درست برای آن پروژه میشوند. بههمین دلیل، باید از همان ابتدای کار این ریسکها را درنظر داشته باشید و برای آنها چارهاندیشی کنید.
پیامدها
- تاخیر در اجرا و پیادهسازی پروژه
- عدم اتمام وظایف که منجر به بروز مشکل در تکمیل سایر کارها میشود
- عدم رضایت مشتری
- فضای کاری نامناسب
راهحل
زمانیکه میخواهید برای پروژه و تخمین سرعت اجرای آن، برنامهریزی کنید، باید همهی ریسکهایی را که ممکن است در اجرای فرایندها و زمانبندی شما اختلال ایجاد کنند، در نظر بگیرید. سعی کنید ریسکهای ممکن را شناسایی و تحلیل کنید و آن را به اطلاع مشتری نیز برسانید. همیشه وظایف و مسئولیتهای مختلف پروژه را با توجه به تواناییها، نقاط قوت و ضعیف اعضای تیم توسعه نرمافزار، به آنها واگذار کنید. همچنین سعی کنید که در طول اسکرام روزانه (Daily Scrum)، همهی مشکلات و موانع موجود را مطرح کرده و اطلاعات مربوط به روند پیشرفت پروژه را نیز بهطور دقیق بیان کنید. این بهترین کاری است که میتوانید برای تضمین کیفیت پروژه توسعه نرمافزار، انجام بدهید.
اگر نمیتوانید براساس زمانبندی قبلی پیش بروید و پروژه را در مهلت مشخص ارائه دهید، باید حتما آن را هر چه زودتر، به اطلاع مشتری برسانید. یک روش مناسب برای مقابله با چنین اتفاقی، این است که یک کار بزرگتر را به دو کار کوچکتر تقسیم کنید. زیرا حتی اگر چند بخش کوچکتر از پروژه را ارائه بدهید، بهتر از آن است که کلا چیزی برای ارائه به مشتری، در اختیار نداشته باشید. این کار، تعهد و مسئولیتپذیری تیم توسعهدهنده پروژه را به مشتری نشان میدهد.
شناسایی ریسک در توسعه نرمافزار
توانایی شناسایی ریسکها و خطرات احتمالی، تاثیر بسزایی در بهبود کیفیت فرایند توسعه نرمافزار دارد. زمانیکه از ریسکهای احتمالی اجتناب کرده و در عین حال، احتمال وقوع آنها را در تخمین زمانبندی پروژه لحاظ میکنید، ممکن است بتوانید کارها و وظایف پروژه را حتی زودتر از ددلاینها، تحویل بدهید که این موضوع، کار را برای تیم بسیار راحت میکند. تمامی اعضای تیم باید در تلاش گروهی برای تشخیص ریسکهای پروژه، ایفای نقش کنند، از پیامدهای ریسکهای احتمالی بهخوبی آگاه باشند و بدانند که چگونه در برابر این خطرات، واکنش نشان بدهند.
اما چهزمانی باید به شناسایی ریسک بپردازید؟ در واقع از همان ابتدای شروع پروژه، باید این کار را آغاز کنید. میتوانید کار خود را با ایجاد یک فهرست از ریسکهای احتمالی، که باید در کل مدت اجرای پروژه موردتوجه قرار داشته باشند، شروع کنید. همزمان که در مسیر توسعه پروژه پیش میروید، این لیست نیز باید بهروزرسانی شود.
بهترین روشهای شناسایی ریسک کدامند؟
ابزارها و تکنیکهای بسیاری وجود دارند که به شما، در بهبود فرایند شناسایی ریسک، کمک میکنند. برخی از این روشها، عبارتند از:
- تحلیل مستندات پروژه
- تحلیل جزئی موجودیتهای پروژه
- کنترل فهرستها براساس تجربیات بهدست آمده از اجرای پروژههای قبلی
- طوفان فکری، البته گفتگوی ساده میان تمامی اعضای تیم میتواند برای مدت طولانی طول بکشد.
زمانیکه شما به تحلیل و ارزیابی ریسکهای احتمالی پروژه میپردازید، موظف هستید که به بسیاری از ارتباطات میان این ریسکها، نیز توجه کنید. بههمین دلیل، بسیار اهمیت دارد که هرچه زودتر ریسکهای احتمالی در فرایند توسعه نرمافزار را شناسایی کرده تا از تاثیرات منفی بسیاری از آنها، جلوگیری کنید.
جمعبندی: مدیریت ریسک پروژه IT
همانطور که پیش از این نیز اشاره کردیم، هیچ پروژه نرمافزاری وجود ندارد که بدون ریسک باشد. بنابراین بسیار حائز اهمیت است که درک کنید وجود ریسک در دنیای فناوری اطلاعات، بسیار طبیعی و ذاتی است. از اینرو، لزومی ندارد که از ریسکهای موجود در فرایند پروژه، بترسید. تنها کافیست که به نکات زیر توجه داشته باشید تا علیرغم وجود ریسکها و مشکلات متعدد، در نهایت پروژه IT را با موفقیت به پایان برسانید.
- بهصورت منظم، جلساتی را با اعضای تیم و مشتریان برگزار کنید.
- بهسرعت به مشکلات رسیدگی کنید.
- به تحقیق و جستجوی اطلاعات و دادههای پیرامون پروژه بپردازید، آنها را به اشتراک گذاشته و مستند کنید و در پایان، سعی کنید آنها را درک کنید.
- تلاش کنید تا انگیزه تمام اعضای تیم توسعه نرمافزار را در سازمان، افزایش بدهید.
همچنین، بهخاطر داشته باشید که موفقیت، یک فرایند همهگیر بوده و میتواند تاثیرات مثبت گستردهای در سازمان شما داشته باشد. در واقع، اثرات مثبت این موفقیت میتواند به تمامی اعضای تیم مجری پروژه و سایر تیمها در یک سازمان، تزریق شود. سعی کنید دانش و اطلاعاتی را که در طول فرایند تشخیص ریسکهای پروژه IT به دست آوردهاید، دستهبندی و نگهداری کرده و از آن برای مقابله با چالشهای جدید در آینده، استفاده کنید. اگر بتوانید برای یکبار این کار را بهدرستی انجام بدهید، بهراحتی میتوانید آن را به یک فرایند قابل پیشبینی و تکرار شدنی تبدیل کرده و بارها و بارها در مدیریت ریسکهای پروژههای IT مختلف، آنها را بهکار بگیرید.
توسعهدهندگان دربارهی ما چه میگویند
تجربه کار باliara_cloud@امروز خیلی خوب بود. یکی از سرویس هام رو منتقل کردم روش و راضیم. انقد سریع و جذاب کارم راه افتادم اصن باورم نمیشد! برعکس سرویس های PaaS دیگه با اون همه پیچیدگیشون. دمتون گرم
...
MohammadReza![](data:image/svg+xml;charset=utf-8,%3Csvg height='400' width='400' xmlns='http://www.w3.org/2000/svg' version='1.1'%3E%3C/svg%3E)
![liara testimonial]()
keikaavousi
بعد از بسته شدن @fandoghpaas و ناراحتی همهمون از اینکه یه سرویس خوب و صادق نمیتونه از پس هزینهها بر بیاد، سرویسم رو منتقل کردم به پاس لیارا (https://liara.ir @liara_cloud) . تجربه راحت و خوب. تفاوتهایی داشت که کمی کار میخواست ولی تا الان کاملا راضی.
jadi![](data:image/svg+xml;charset=utf-8,%3Csvg height='400' width='400' xmlns='http://www.w3.org/2000/svg' version='1.1'%3E%3C/svg%3E)
![liara testimonial]()
jadi
یه خسته نباشید باید به تصمیمliara_cloud@بگم،
بعد از چندین روز سرکله زدن با سرویس های مشابه بالاخره تصمیم گرفتم لیارا رو امتحان کنم و باور نمیشه ۱۰ دقیقه بیشتر وقت نبرد،
دمتون گرم.
Arch![](data:image/svg+xml;charset=utf-8,%3Csvg height='400' width='400' xmlns='http://www.w3.org/2000/svg' version='1.1'%3E%3C/svg%3E)
![liara testimonial]()
EbadiDev
واسه سرویس PaaS با اختلاف لیارا بهترین رابط کاربری داره و یکی از مزیتهای سرویس دیتابیسشون اینه که خودشون به صورت دورهای بکآپ میگیرن.
...
Ali Najafi![](data:image/svg+xml;charset=utf-8,%3Csvg height='400' width='400' xmlns='http://www.w3.org/2000/svg' version='1.1'%3E%3C/svg%3E)
![liara testimonial]()
me_ali_najafi
یکی از کارهای خوبی که جدیداً میکنم اینه که یه دیتابیس روی لیارا میسازم و به پروژه وصل میکنم اینطوری هم خونه و هم محل کار دیتابیس بروز رو دارم و راحت میتونم ادامه بدم کار روliara_cloud@
Navid![](data:image/svg+xml;charset=utf-8,%3Csvg height='80' width='80' xmlns='http://www.w3.org/2000/svg' version='1.1'%3E%3C/svg%3E)
![liara testimonial]()
1navid
عاشقliara_cloud@شدم درسته در حد AWS نیست ولی خب تجربه خوبی واسه پروژه های داخل ایران ارائه میده، میتونم رو CD هم اجراش کنم
Amir H Shekari![](data:image/svg+xml;charset=utf-8,%3Csvg height='400' width='400' xmlns='http://www.w3.org/2000/svg' version='1.1'%3E%3C/svg%3E)
![liara testimonial]()
vanenshi