آموزشدفتر مدیریت پروژهکنترل و مدیریت پروژه

چگونه شرح‌کار پروژه بنویسیم (بخش دوم)

در قسمت قبلی این مقاله دیدیم که شرح‌کار چیست، چه‌موقع باید شرح‌کار بنویسیم و در شرح‌کار باید چه‌چیز لحاظ شود.

در بخش دوم این مقاله لیست دسته‌بندی‌های اطلاعات شرح‌کار و اقدامات لازم بعدی برای شرح‌کار را مطالعه می‌کنیم.

دسته‌بندی اطلاعات موجود در شرح‌کار:

* محدودۀ کار: توصیف پرجزئیات کار، نرم‌افزار و سخت‌افزارِ مورداستفاده و ماهیت دقیق کار؛

* محل کار: به‌غیر از محل استاندارد کار، محل انجام کار کجا خواهد بود؛ این بخش از شرح‌کار برای کاری که باید خارج از شرکت انجام بشود قابل‌کاربرد است؛

* مدت عملکرد: تاریخ آغاز و پایان پروژه، حداکثر ساعات قابل‌پرداخت به‌ازای هر دوره، و غیره؛

* زمان‌بندی اقلام تحویلی: زمان‌های تعیین‌شده برای اقلام تحویلی پروژه، شامل تاریخ‌های تکمیل توسعه، آزمون QA، و آزمون پذیرش کاربر و غیره؛

* استانداردهای قابل‌کاربرد: استانداردهای صنعتی و دیگر استانداردهای اعمال‌شده به اقلام تحویلی پروژه؛ شامل هر استانداردی مثل ISO CMM ،CMMI و غیره؛

* معیار پذیرش: این معیارها شامل هر استاندارد کیفی‌ای است که باید برآورده شود، مثلاً صفر اولویت، یک نقص. همچنین این معیارها باید شامل دیگر شرایط لازم‌الاجرا باشند، مانند تعداد موارد آزمون، تعداد موارد آزمون اجراشده، و غیره؛

* نیازمندی‌های تخصصی: این‌ نیازمندی‌های شامل هر کیفیت بخصوصی است که نیروهای کار باید داشته باشند، مانند مدیریت پروژۀ گواهی‌دار PMP.

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

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

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

قدم‌های بعدی

مرحلۀ بعدی تأیید کردن SOW توسط حامیان مالی پروژه و مشتری پروژه است. SOW اکنون مرز رسمی محدودۀ پروژۀ شماست. هر جزئیات مربوط‌به شرح‌کار باید در محصول نهایی اعمال شود.

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

تاریخ‌های ابتدایی و انتهاییِ درنظرگفته‌شده در شرح‌کار باید در ساختار شکست کار نیز درنظر گرفته شده باشد. اگر از MS Project یا ابزار مشابه آن برای پشتیبانی از ساختار شکست کار استفاده می‌کنید، تاریخ شروع، اولین ثبت در ابزار خواهد بود. از تاریخ انتهایی، به‌عنوان محدوده استفاده خواهید کرد. وقتی که تمام اطلاعات ساختار شکست کار، نحوۀ شکست کار و زمان‌بندی وظایف را درنظر گرفتید، باید تاریخ نهایی موردنظر را با تاریخ نهایی شرح‌کار مقایسه کنید. به همین شیوه، از تاریخ‌های زمان‌بندی اقلام تحویلی در شرح‌کار استفاده کنید.

باید از SOW به‌عنوان یک ابزار ارتباطی برای توصیف کار پروژه به ذی‌نفعان استفاده کنید. می‌توانید این کار را با ارسال SOW بر یک سایت عمومی، همراه با دیگران اسناد پروژه، برای استفادۀ عموم قرار بدهید. فراموش نکنید که وقتی تغییری در کار پروژه تأیید می‌شود، SOW را به‌روزرسانی کنید.

توجه کنید که اطلاعات درستی را درخصوص کار پروژه درنظر بگیرید؛ متحمل دشواریِ بررسی آن شوید تا بتوانید مطمئن شوید که اطلاعات، تا جای ممکن، دقیق است. با استفادۀ مناسب از این اطلاعات در دیگر برنامه‌ریزی‌هایتان می‌توانید وقت کمتری را صرف برنامه‌ریزی بیشتر در آینده کنید. فقط فراموش نکنید که شرح‌کار یک مستند «زنده» است و هر تغییری در هر مؤلفه‌ای از شرح‌کار باید در آن اعمال شود.

آنچه در این مقاله ذکر شد براساس تجربۀ شخصی و بهترین شیوه‌های PMI است.

قسمت اول این مقاله

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

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

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

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