میثم امیدالحق

اهمیت و چگونگی تدوین ساختار شکست کار (WBS)

break_the_melon

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

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

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

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

 

در ادامه توضیحاتی در خصوص شیوه ی تدوین ساختار شکست کار بر اساس استاندارد پم باک (PMBOK) و یا به عبارتی پیکره دانش مدیریت پروژه ارائه می کنم. پم باک مشهورترین استاندارد مدیریت پروژه می باشد که توسط موسسه مدیریت پروژه ی امریکا (PMI) ارائه و بروزرسانی می شود و به عنوان مرجع مدیریت پروژه مورد استفاده قرار می گیرد.

 

ساختار شکست کار در پم باک

 

در پم باک ۴۲ فرآیند برای مدیریت پروژه تعریف شده است که این ۴۲ فرآیند در ۹ حوزه‌ی دانش (یکپارچگی، گستره، زمان، هزینه، ارتباطات، کیفیت، منابع انسانی، ریسک و تدارکات) قرار می گیرد.

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

 

تعریف ساختار شکست کار

 

در پم باک ساختار شکست کار اینگونه تعریف می‌شود: “یک تقسیم بندی سلسله مراتبی و مبتنی بر تحویل شدنی ها، از فعالیت هایی که تیم پروژه برای رسیدن به اهداف پروژه انجام می دهد”

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

 

قواعد تدوین ساختار شکست کار

 

برای تدوین ساختار شکست کار، رعایت دو قاعده زیر الزامی می باشد:

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

با توجه به اینکه معمولا اعضای تیم پروژه تنها بر روی مسئولیت ها و وظایف خودشان تمرکز دارند، قاعده اول به اعضای تیم پروژه کمک می کند تا نسبت به کلیه عوامل موثر در اجرای پروژه، درک کاملی پیدا کنند.

 

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

WBS: Work Broken Structure
PMBOK: Project Management Body of Knowledge
PMI: Project Management Institute

میثم امیدالحق

از شهریور سال ۸۱ فعالیت حرفه ای خود را در زمینه ی طراحی وب شروع کرد و در ادامه به عنوان مدیر عامل دو شرکت نرم افزاری حدود ۱۰۰ وب سایت بزرگ و کوچک را راه اندازی کرده است که تعدادی از آنها پروژه های ملی بوده اند و البته اندک سابقه ای هم در زمینه تدریس دارد. او در سارینا مدیر پروژه است.

  1. سه شنبه، ۱۴ مرداد ۱۳۹۳ اهورا صادقی
    خیلی خوب بود. ممنون از توضیحات.
    یه مشکلی که من دارم (شاید بقیه هم داشته باشن) اینه که بستن پروژه و محدود کردن پروژه در اول کار برای مشتری قابل انجامه، ولی وقتی که به اواخر پروژه نزدیک می شیم، مشتری خواستار یک سری تغییراته و با توجه به کوچک بودن اسکیل شرکت ما و نیاز به جلب رضایت نزدیک به 100% مشتری، باید این تغییرات رو اعمال کنیم. (اواسط کار یا بعد از تحویل). از تغییرات هم منظور من باگ ها و مشکلات نیست. برای پیاده سازی این متدی هم که توضیح دادین نیاز هست که از اول همه چی دیده شه و به قول خود شما (قاعدع 100%) نباید بعد از اتمام طراحی ساختار تغییری در اون داده بشه.
    چه راهکاری هست که بتونیم بدون از دست دادن اعتماد و رضایت مشتری این تغییرات رو انجام ندیم؟
    نکته دوم اینه که حداقل در تجربه من، 80% مشتری ها هم نمی دونن دقیقا چی می خوان و حتی با تشکیل جلسات مختلف با مشتری و بحث و گفت و گو به 100% خواسته ی مشتری نخواهیم رسید و مشتری پس از پیاده سازی قسمتی از پروژه توسط ما تازه به خواسته های جدید (و البته ضروری) خود در هنگام کار با سیستم پی می برد که این باعث تغییر و یا بزرگ تر شدن پروژه و درنهایت تغییر در ساختار wbs می شود.
    برای این مشکل دوم چه راهکاری پیشنهاد می دهید؟
    یک مثال جالب، بنده در آخرین نرم افزاری که باید پیاده سازی می کردم، یک نرم افزار کنترل پروژه و یا همان Issue Tracking بود و با اینکه مشتری درخواست چنین نرم افزاری را داده است و کاملا با فرایند شکست پروژه آگاه است و مسلط به مسائل مدیریتی است ، پروژه 3 ماهه تبدیل به پروژه 6 ماهه شده است و نیز هزینه آن برای مشتری نیز تقریبا دو برابر شده است. منظور بنده این است که مشتری بنده بسیار با سواد و آگاه به مسائل هست، ولی خود او هم نتوانست از اول به صورت کامل نیازمندی های خود را ارائه بدهد (به بنده حتی گانت، داکیومنت تجزیه و تحلیل سیستم - که به شرکت دیگری سپرده شده بود - تحویل دادند و قبل از شروع پروژه نیز چندین جلسه برگزار شده بود، ولی پس از پیاده سازی کامل کار و برآورده کردن نیاز های مشتری ، وی متوجه شد که این فقط 60% از نیاز های او می باشد و در طول زمان این پروژه بزرگتر شد که تقریبا از همان اسکرام کمک گرفته شد ولی کار به این صورت برای مشتری بسیار سخت و پیچیده بود و نیز برای ما هم با توجه به تغییرات زیاد پیچیدگی کار زیاد شد.. در ضمن فقط با این مشتری که بسیار با سواد بود و به ما اعتماد کامل داشت توانستم این کار را انجام دهیم که فکر می کنم با سایرین قادر به انجام چنین کاری نباشیم.
    • میثم امیدالحق
      پنج شنبه، ۱۶ مرداد ۱۳۹۳ میثم امیدالحق
      با سلام
      بخشی از پروژه که بصورت کلاسیک انجام می شود همان بخشی است که ما و مشتری نسبت به آن تفاهم نظر داریم، البته همین بخش کوجک و شفاف هم با انحراف از پیش بینی اولیه انجام میشود، ولی ما از همون ابتدا به مشتری اعلام میکنیم که این محصول نهایی نخواهد بود و در ادامه تغییرات را با استفاده از اسکرام انجام خواهیم داد.
      درواقع این بخش صرفا برای جلب اعتماد و آشنایی با توان کیفی طرفین انجام می شود.
      پیدا کردن راهی برای انتقال زوایای پنهان و مشکلات اجرای پروژه، موضوع بسیار مهمی است که از نظر من صرفا با تجربه کاری و اجرای پروژه های مختلف میسر خواهد شد.
      اگر به یاد داشته باشید، در جلسات مربوط به پروژه ی سازمان بهداشت جهانی یک پزشک به عنوان نماینده وزرات بهداشت مسئولیت طرح مسئله و درخواست سازمان غذا و دارو را به عهده داشتند. من بصورت اتفاقی ایشان را در یک سینما ملاقات کردم و از ایشون درخصوص تسلطشون روی مباحث نرم افزاری سوال کردم، و ایشون اعلام کرد که فقط و فقط تحربه 4 ساله ی حضور در کنار یک تیم نرم افزاری و لمس نزدیک پروسه های تولید نرم افزار باعث افزایش درک ایشون نسبت به مسائل تولید نرم افزار شده است.
  2. سه شنبه، ۱۴ مرداد ۱۳۹۳ پویا یزدانی
    مطلب مفیدی بود. ممنون بابت معرفی WBS.
    کتاب آقای خرمی راد هم در مورد نحوه تدوین شکست کار فکر کنم راهنمای خوبی باشه.
    • میثم امیدالحق
      پنج شنبه، ۱۶ مرداد ۱۳۹۳ میثم امیدالحق
      با سلام، بنده از مطالب و کتاب های آقای خرمی راد هم استفاده میکنم. به وبلاگ شما هم مراجعه کرده و از مطالبی که منتشر کردین استفاده کردم. ضمنا مقاله ها و کتاب های آقای علی فروزش هم در همین حوزه قابل توجه هستند.
  3. سه شنبه، ۱۴ مرداد ۱۳۹۳ هیلدا نکومند
    سلام به نظر من استفاده از چهارچوب Prince2 و استفاده از PBS به جای WBS در پروژه های نرم افزاری بهتر جواب می دهد چرا که استاندارد PMBOK به طور کلی و در ابتدا برای اجرای پروژه های عمرانی اجرایی نگارش یافته و بیشتر مورد استفاده قرار گرفته است. البته از لحاظ ماهیت عملا هر دو یک کارکرد و هدف را دنبال می کنند.
    ممنون از مطلب شما
    • میثم امیدالحق
      پنج شنبه، ۱۶ مرداد ۱۳۹۳ میثم امیدالحق
      با سلام، با نظرتون کاملا موافقم، نکته ای که وجود دارد این است که استفاده از ساختار شکست محصول در پروژه های حوزه ی فناوری اطلاعات، خصوصا سرویس های تحت وب، با مشکلات عدیده ای همراه خواهد بود، چراکه اغلب سفارش دهندگان و مشتریان درک کاملی نسبت به درخواست خود ندارند و اساسا پیش بینی کلیه ابعاد و الزامات محصول نهایی بسیار مشکل و در بیشتر مواقع غیر ممکن است، به همین دلیل ما از چهارچوب اجایل (و متد اسکرام) در مدیریت پروژه های نرم افزاری استفاده می کنیم که با شفافیت نسبی نسبت به محصول نهایی تعریف می شوند. همچنین بخشی از پروژه که به روش کلاسیک انجام می شود با محصول نهایی تفاوت خواهد داشت و با تائید فرمایش شما، ما هم پس از پایان بخش اول پروژه بر روی محصول متمرکز خواهیم شد. با تشکر از حسن نظر و دقت شما.
  4. پنج شنبه، ۲۳ مرداد ۱۳۹۳ کاوه صالح پور
    سلام میثم عزیز از مطلب ارائه شده شما بسیار لذت بردم ، فقط جهت اطلاع و توسعه بحث شما در استاندارد منتشر شده pmbok 2013 تعداد از 42 به 47 فرآیند و در حوزه های دانش نیز از 9 حوزه به 10 حوزه افزایش یافته است . که این تغییرات در حوزه Stakeholder Management میباشد و نشان دهنده اهمیت خاص و نگاه ویژه ذی نفعان در پروژه ها میباشد.