هسته قدرتمند تمام شرکت‌های IT ،از یک تیم IT قوی شروع به رشد می‌کند (که پروژه‌های قابل تنظیم را به‌موقع گسترش می‌دهند)؛ اما چرا گاهی این تیم فوق‌العاده باعث می‌شود یک پروژه یکپارچه شکست بخورد؟ بجای بازدهی، نوآوری و موفقیت، CTOها و CIOها با چالش‌هایی که به اجرا، تخصیص بودجه و تیک‌تاک ساعت مربوط است، مواجه می‌شوند. براساس گزارش The Standish Group Chaos، نزدیک به تنها 30درصد از پروژه‌های IT به‌درستی اجرا می‌شوند و موفق هستند درحالی‌که 20درصد از پروژه‌ها کاملاً شکست می‌خورند.
قبل از آنکه به نکاتی که منجر به شکست می‌شوند اشاره کنیم، بیایید نگاهی به ملزومات یک پروژه موفق بیاندازیم:
یک پروژه موفق باید:
- به‌موقع تحویل داده شود.
- مقرون‌به‌صرفه باشد.
- همان‌طوری که طراحی شده است، کار کند.
- برای همه مفید باشد.
- انتظارات طراحان خود را برآورده کند.
- به اهداف درنظر گرفته شده برسد.
همه این موارد باید عملی شوند تا یک پروژه با موفقیت همراه شود. خب از آنجایی‌که سطح انتظارات بالا است، در واقعیت رسیدن به اهداف سخت می‌شود (تقریباً یک‌چهارم پروژه‌ها به دلیل ملزومات نامناسب شکست می‌خورند.)
دلایل پشت این اتفاق چیست؟
ملزومات نادرست
وقتی‌که یک نفر درحال نوشتن مشخصات یک پروژه است، تمام افراد تیم حاضر نیستند. اینکه افراد تیم ابتدا بتوانند طرح اولیه‌ای از آنچه باید روی آن کار کنند، ببینند، روی کل پروسه تأثیر می‌گذارد. احتمال اینکه تکمیل پروژه غیرممکن باشد، زیاد است و ممکن است نیاز باشد که مجدداً برنامه‌ریزی کنند و دوباره از ابتدا کار را آغاز کنند.
راه‌حل:
تمام متخصصان در مرحله طراحی حضور داشته باشند - شریکان، نمایندگانی از تیم IT، کاربران - آن‌ها به شما می‌گویند که چه چیزهایی باید تغییر یابد و راه‌حل‌هایی را ارائه می‌دهند. نمایندگان تجاری می‌توانند با کاربران نهایی برای شناسایی هدف نهایی هر پروژه هماهنگ شوند. این یک راه خوب برای طراحی یک پروژه موفق است.
کمبود حامیان مالی مناسب
حامیان مالی باید در مرحله توسعه پروژه درگیر شوند. آن‌ها نمی‌توانند فقط چشم‌اندازشان را دیکته کنند و منتظر بمانند که تمام کارها انجام و ارائه شود.
اگر مشکل، مسئله و یا سؤالی پیش بیاید، چطور؟ راهی برای پاسخ به آن وجود ندارد. اگر تیم توسعه‌دهندگان تصمیم بگیرد که یک پروژه بدون هیچ همفکری پیش برود و تصمیم اشتباهی بگیرد، آن تجارت با شکست روبرو خواهد شد.
تحقیق "PMI" نشان داد که بیش از 27درصد پروژه‌ها به دلیل عدم وجود حمایت مالی شکست می‌خورند.
راه‌حل:
همیشه مطمئن شوید که پروژه حامی مالی و یا فردی را برای مشورت دارد که به سؤالات پاسخ می‌دهد و برای مرور کارها در طول مرحله توسعه پروژه می‌توان به او مراجعه کرد.
تغییر اهداف پروژه
بیشتر تیم‌های IT در یک مدل توسعه "SCRUM" در دوره‌های کوتاه (از یک هفته تا یک ماه) کار می‌کنند. در شروع هر دوره، زمانی برای طراحی کار وجود دارد. این طرح نمی‌تواند به‌راحتی اصلاح شود، اما هر دوره جدید امکان پیاده‌سازی تغییرات را فراهم می‌کند.
گاهی اوقات دنبال کردن اهداف تغییریافته مشکل است اما استفاده از مدلی که بتواند از تغییرات احتمالی هم پشتیبانی کند، تأثیر آن‌ها را به حداقل می‌رساند.
به خاطر داشته باشید که: تغییرات به معنای شکست نیستند! شما می‌توانید با حداقل کردن چارچوب زمانی طرح‌ها، خطرات را کاهش دهید.
راه‌حل:
خوب است که کارها را برای دوره دوهفته‌ای طرح‌ریزی کنید: تعیین کنید که کدام‌یک از وظایف مهم‌تر هستند و در دوره 14 روزه روی انجام آن‌ها تمرکز کنید. به تیم اجازه دهید که روی کار کلیدی با بالاترین اولویت متمرکز بمانند که بتوانند کد ارزشمندی ارائه کنند.
برآوردهای بی‌دقت
در فاز اولیه یک پروژه، برآورد کردن مثل حدس زدن است. تیم IT شما اطلاعات کمی درمورد پروژه و ارزش آن، تخمین زمان ارائه و ملزومات آن برای دانستن هزینه‌های انجام کار و چارچوب زمانی دارد.
شروع برآوردها از زمانی‌که فرایند توسعه آغاز می‌شود و ملزومات کم‌کم مشخص می‌شوند، مناسب است.
ازآنجایی‌که تقریباً هیچ حامی مالی چیزی را بدون تضمین نمی‌پذیرد، تخمین‌های قابل‌تغییر باید در پروژه‌های IT وجود داشته باشند. آن‌ها به چیزی مثل یک طرح اولیه یا یک ایده نیاز دارند که هزینه و ریسک سرمایه‌گذاری را بدانند.
درواقع حدسیات و محاسبات غیردقیق به دلایل زیر به‌وجود می‌آیند:
- تخمین‌های نامناسب - تیم‌های توسعه‌دهنده تجربه‌ای در برآورد کردن و فرض کردن بیشتر اتفاقاتی می‌افتند، ندارند.
- برنامه‌ریزی زودهنگام - مدیران پروژه و CTOها می‌خواهند تخمین‌ها را خیلی سریع و فوری بدانند.
راه‌حل:
اگر تخمین زدن برایتان سخت است، سعی کنید به‌صورت محدوده‌‌ای تخمین بزنید. اگر توسعه‌دهندگان شما می‌گویند که یک پروژه در عرض دو ماه تکمیل می‌شود، این را به‌صورت یک "مخروط عدم قطعیت" درنظر بگیرید (با زیرکی) و یک محدوده اضافی برای مرحله کنونی پروژه درنظر بگیرید. به‌عنوان‌مثال اگر در مراحل اولیه هستید، مدت‌زمان لازم برای این مرحله را از دو هفته تا چهار ماه تخمین بزنید.
ریسک‌های ناگهانی و غیرمنتظره
مخروط عدم قطعیتی که در بالا به آن اشاره شد، درواقع برای چنین ریسک‌هایی درنظر گرفته‌شده است. در مراحل اولیه، توسعه‌دهندگان زمانی را برای تکمیل کد تخمین می‌زنند که صحیح است اما فقط به خاطر داشته باشید که همچنان خطر بالایی از شکست‌های غیرقابل پیش‌بینی وجود دارد. چهار برابر زمان مفروض را برای زمان ارائه برآورد کنید.
این زمان اضافی امکان رسیدگی به هر مسئله غیرقابل انتظاری را فراهم می‌کند. به این فکر کنید که به لطف مخروط عدم قطعیت و بدون هیچ شکستی، می‌توانید پروژه را زودتر، ارزان‌تر و... تمام کنید و به لحظه اعلام این موضوع به کارفرمای خود فکر کنید!
راه‌حل:
خطرات ناگهانی در 30درصد مواقع دلیل شکست پروژه هستند! اما یک راه‌حل برای آن وجود دارد! و آن شبیه راه‌حل برآوردهای خام است. برآوردها نیاز دارند که خطرات شناخته‌شده و ناشناخته را برای جلوگیری صحیح از گام‌های اشتباه غیرمنتظره بازتاب دهند.
کمبود منابع
PMها (project manager) و CTOها (chief technology officer) تمایل دارند که از مردم (منظور کارمندان است) به‌عنوان منابع استفاده کنند و زمانی که می‌گویند منابع کافی وجود ندارد، منظورشان در واقع این است که تعداد کافی از افراد برای کار روی پروژه وجود ندارد. این وضعیت در 20درصد پروژه‌های شکست‌خورده اتفاق افتاده است.
روش‌های مختلف، شروط متفاوتی دارند. در روش آبشاری -بودجه- در اینجا به معنی پول کافی برای اتمام پروژه است. در روش AGILE شما کاری را انجام میدهید که تیمتان بتواند با موفقیت آن را تکمیل کند.
در پروژه‌هایی که تعداد منابع کم است، معمولاً این اتفاق می‌افتد که بودجه، محدوده و چارچوب زمانی منعطف نیستند که این خوب نیست. حداقل یکی از این قیود باید نسبت به خطرات غیرمنتظره منعطف باشند.
درواقع نبود منابع هرگز دلیل شکست نیست! این درواقع دلیل شروع نکردن پروژه‌هاست. زمانی که شما پروژه‌تان را با یک روش مناسب طرح‌ریزی می‌کنید، از همان ابتدا باید بدانید که افراد کافی در تیمتان برای انجام مقدار زیادی کار در چارچوب زمانی مشخص‌شده دارید.
راه‌حل:
مشکل نبود منابع به‌راحتی حل می‌شود: یکی از این 3 قید را منعطف نگهدارید: زمان، بودجه، محدوده.
سخن پایانی
این مقاله را با ارائه یک لیست سه‌تایی از مواردی که منجر به موفقیت در پروژه می‌شوند، به پایان می‌رسانیم:
- تمام متخصصان را در جریان پروژه قرار دهید و فرصت صحبت با یکدیگر را در تمام طول پروژه برای آن‌ها ایجاد کنید که از تعیین ملزومات اشتباه و محصولات نامناسب جلوگیری شود.
- یکی از این موارد را منعطف نگهدارید: زمان، بودجه و یا محدوده و گهگاه برای کنترل اینکه آیا طرح‌ها در مسیر هستند یا نه (یا اینکه دوباره آن‌ها را به سمت مسیر ببرید) مجدداً برنامه‌ریزی کنید.
- با عبارت «مخروط عدم قطعیت» برای برآوردهای تمام افراد درگیر در پروژه به‌منظور کاهش خطرات شکست‌های غیرمنتظره و تاخیرات دوست باشید!
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید