چگونه یک پروژه نرم‌افزاری را مدیریت کنیم؟

هدف از این مقاله نحوه سفارش اصولی یک نرم افزار خاص است که بصورت عمومی در بازار وجود ندارد. یا اگر موجود است انطباق کمی با نیاز شما دارد. پس ضرورت دارد این نیاز توسط تولیدکنندگان بنحو شایسته‌ای تامین گردد. همچنین اگر شرکت شما دارای بخش تولید نرم افزار(مدیریت آی تی IT) باشد یا نباشد باز این مقاله برای شما مفید خواهد بود.

در یک نگاه

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

چه نوع نرم افزار سفارشی مورد نظر این مقاله است؟

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

کیفیت سفارش چنین نرم‌افزارهایی بستگی به سطح آگاهی و تجربه شما از علم تولید نرم‌افزار دارد. هر چند اعلب افراد تصور می‌کنند همه چی را می دانند اما در واقع چنین نیست. در طول دوره ۲۵ ساله فعالیت من در این حوزه، افراد و مدیران زیادی دیده‌ام که واقعاً تصور می‌کنند بسیار مسلط هستند. آنها یقین دارند که می‌توانند کار را درست و بصرفه سفارش دهند. یا اینکه یک تیم برنامه‌نویسی ایجاد کنند و خود بر تولید نظارت کنند. البته اینو هم باید بگم که بیشتر افراد مورد نظر من، همین روش آخری را انتخاب می‌کنند یعنی تیم تولید راه می‌اندازند. واقعاً، شوخی نمی‌کنم!

من اینجا مشکلات هر دو روش را بیان خواهم کرد. تجربیات و اتفاقات عملی از هر دو گروه از مدیران را برای شما شرح خواهم داد. حتی اگر علاقمند بودید با کیس‌های مورد نظر من روبرو شوید و آنها را مشاهده کنید می توانید ایمیل بزنید تا دقیق شما را به موارد متعدد از هر دو نوع برخورد مدیریتی هدایت کنم.

ابتدا روش استفاده از تیم تولید نرم‌افزار را که گزینه زیادی برای بیشتر مدیران هست توضیح میدم.

یک باور اشتباه اما رایج

شرایط محیطی و تکنولوژی که طی سالهای اخیر با آن زندگی می‌کنیم اغلب ما انسانهایی را که در یک بیزنسی فعال هستیم به این باور رسانده  که آره، من خیلی در مورد کامپیوتر و نرم‌افزار میدونم. یعنی یک خودباوری ناقص در میزان تسلط ما به علوم نرم‌افزاری پدید آورده است. بخصوص برای مدیرانی که در بخش دولتی یا نیمه خصوصی فعال بوده‌اند. بعضی از کیس‌هایی که مشاهده کرده‌ام فرد در دوران دانشجویی یا سن خاصی چند تا  کد زده یا یک نرم‌افزارکی را بالا آورده یا اینکه موردی بوده طرف مسئول یک تیم تولید مبتدی بوده، چنان خودباوری داره که بقول امروزی‌ها خودشو  اند نرم افزار میدونه و این دوست ما میاد مسئول یک پروژه بزرگ میشه. یا مشاور یک شرکت بزرگ میشه و یک پروژه بزرگی را به هر طریقی باید مدیریت کنه. یا فرض کنید دوست فرضی ما پولدار شده و میخواد یک بیزنس مبتنی بر نرم‌افزار راه بندازه. شروع مشکلات از همین نقطه آغاز میشه. 

مشکلات روش تولید با استفاده از تیم برنامه نویسی داخلی

راه‌اندازی یک تیم تولید نرم‌افزار بنظر ایده خوبی است. شما می‌تونید چند جوان خوب از آشناها یا از طریق آگهی استخدام شناسایی کنید و آنها را بکار بگیرید. ابتدای فعالیت مشکلی نخواهید داشت چون هم شما بودجه‌ای را برای این کار کنار گذاشته‌اید و سر ماه حقوقها را پرداخت میکنید. و هم ابتدای توسعه هستید و تقریباً در حال طراحی و پیاده سازی اولیه هستید. خیلی از نیازمندیهای اولیه خوب هم پیاده می‌شند. نیازهایی مانند تعریف کاربر، لاگین شدن(ورود و خروج از سیستم)، دسترسی دادن، منوها، اطلاعات پایه و همینطور برخی فرمهای عادی.

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

یکی از مشکلات رایج در تیم‌های تولید داخلی

حالا در یکی از مفروضات و مشاهدات من که شرح دادم اختلاف بین کارفرما و تیم تولید از اینجا شروع میشه، عدم اعتماد، بدبینی. حالا خوش شانس خواهید بود در این مرحله یک ناقولای متخصص مآب گیرتون نیاد(بعنوان مشاور یا هرچی) که شروع به بازارگرمی بکنه  و کار تیم تولید را زیر سوال ببره. 

چرا به این مشکل خوردید؟ یکی از پاسخ‌های مهم : نیاز سنجی درست انجام نداده‌اید. اسناد تحلیل نیازمندی تهیه نشده و جلسات طراحی اصولی انجام نشده. پیش طراحی نشده. بله برای این کارها شما به متخصص نیاز داشتید ولی متخصص را فقط برنامه نویس میدونستید حالا گیر افتاده اید زمان زیادی را از دست داده‌اید کارهایی که تا حالا انجام شده دوباره باید بازتولید بشه، منابع زیادی را صرف کرده‌اید و هنوز نیازمندی ذهنی شما پیاده نشده است( موارد زیادی از این نوع مشاهده کرده‌ام). باور کنید موردی را دیده ام چنین اشتباهی را بارها تکرار کرده. واقعاً!

فهرست مشکلات در تیم‌های برنامه‌نویسی داخلی

در هم چی مواردی مشکلات زیادی ممکن است رخ بدهد که برخی از مهمترین آنها را براتون لیست میکنم:

  • شناسایی و بکارگیری اشتباه متخصصین تولید نرم افزار ( زمان بیشتر و اندکی هزینه هدر رفته است)
  • انتخاب نا مناسب روش تولید و توسعه نرم‌افزار( دوباره کاری/ از دست دادن زمان و هزینه)
  • مشکلات در تکمیل کادر تخصصی( اگر پروژه هایتک بود مانند میکروسرویس، داکر و RestfulApi)
  • ترک کار توسط برخی از کادر متخصص ذر حین تولید و توقف/تاخیر فعالیتها( ناشی از تاخیر حقوق، کافی نبودن حقوق، مسائل انسانی و برخوردهای بین کارفرما و کارشناس و …)

مشکلات رایج در واگذاری نرم افزار به شرکت‌های توسعه دهنده(سفارش تولید)

هدف ما از این بخش، توضیح مشکلات رایج و واضح در مدیریت پروژه‌ّای بزرگ نرم افزاری است و قصدی نداریم تا اصول مدیریت یک چنین‌ پروژه‌هایی را در اینجا ارائه کنیم در صورتیکه به دنبال چنین مباحثی هستید می ةوانید براحتی گوگل کنید. اما سعی می‌کنم چند لینک مناسب از چنین مقالاتی را در اینجا قرار بدم اگر پیاش نکردم حتماً خودم تولیدش خواهم کرد.(قول میدم) 
TODO: Make Lists of How to manage a big software project

مهمترین گام در سفارش یک پروژه، تهیه نیازمندی دقیق آن پروژه است که به ان RFP هم گفته میشه. RFP (Request for proposal) در این سند شرح دقیق از نیازمندی تهیه می‌شود. به این خاطر که پیمانکار بتونه برای این نیازمندی، راهکار پیاده سازی بده. این راهکار همراه با زمان و هزینه است. خود فرایند تهیه RFP هم خیلی کار تخصصی و مهندسی است و معمولا آنجه در تشکلیلات دولتی مشاهده کرده‌ام اگر برون سپاری (مشاوره) استفاده نکرده باشند معمولاً فاقد اعتبار است. یعنی تهش چیزی که بیرون میاد کاربردی نخواهد بود و چون زمان زیادی هم میکذره و مدیرا عوض میشن و اینا، آخرش کسی گیر هم نمیوفته. ( یگی از دلایل پر هزینه بودن کارهای دولتی همینه)

در چند تا از بخشهای مهم دولتی که حتی از نظر تکنولوژی هم بالا بوده چندین پروژه ناموفق یا دقیق‌تر ابر پروژه نرم افزاری بوده ( و احتمالاً شما خوانند گرامی هم دیده و شنیده‌اید) که پروژه سالها طول کشیده و آخرش عملیاتی نشده. چنین مشکلاتی در شرکت‌های بزرگ خصوصی و نیمه خصوصی هم زیاد اتفاق افتاده است. دلیل عمده این شکست‌ها بر نقص در تعریف پروژه و ایجاد زیرساخت اصولی مدیریت آن است.

پس بهتر است پروژه خود را به صورت اصولی شروع کنید. یا تیم صلاحیت‌دار تعریف پروژه دارید که RFP تهیه کنه یا از شرکت‌های مشاوره IT کمک بگیرید( لازم به یادآوری است برخی از شرکت‌های مشاوره کشکی و فاقد صلاحیت هستن، حواستان باشد اینجا هم اشتباه نکنید)

برخی از موضوعات مهم فنی و تکنولوژی در پیاده سازی پروژه‌های نرم‌افزاری بزرگ، که باید به آنها دقت کنید.

  • انتخاب تکنولوژی تولید( در انتخاب تکنولوژی، موارد زیادی موثر هستند مثلاً سیستمهای وابسته موجود که این پروژه باید با آنها لینک باشه، میزان بار سیستم، توزیع شدگی یا پراکندگی جغرافیایی بهره‌برداری، توان و بودجه پروژه، خروجی‌های متنوع مانند Mobile App، Web, Windows ، نحوه میزبانی یا Hosting پروژه و …)
  • روش تولید( مبتنی بر سرویس ابری، روش سنتی، میکروسرویس)
  • استفاده از سیستم‌های متن باز موجود در بازار مانند Odo
  • استفاده از ERP های مطرح مانند SAP
  • توجه به میزان دانش و صلاحیت کاربران و فرایندهای مدیریتی و اداری(بخصوص در شرکت‌های بزرگ دولتی و خصوصی) که اهداف پروژه ایده‌ال گرایانه است اما بهره‌برداران و فرایندهای اجرایی و مدیریتی فاقد شرایط لازم و صلاحیت فنی برای بهره‌برداری هستند. این مورد در پروژههای ERP زیاد اتفاق افتاده و نتیجه عدم عملیاتی سازی درست پروژه بوده است. یعنی نرم‌افزار عالی بوده ولی توانایی استفاده و شرایط استفاده در شرکت یا سازمان مهیا نبوده است. شرایط استفاده فقط صلاحیت فنی کاربر نیست فرایندها و مقررات و روش مدیریتی هم از عوامل مهم جاری سازی پروژه‌های بزرگ نرم‌افزاری است.