تبلیغات
مدیر پروژه - مطالب فرایند بهبود در حال توسعه

درباره وبلاگ

آرشیو

آخرین پستها

طبقه بندی

نویسندگان

ابر برچسبها


Admin Logo
themebox Logo


چگونه پروژه از چشم انداز به واقعیت رسید؟

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

فرایند بهبود در حال توسعه

  1.  تعیین هدف
  2. تعیین معیارهای سنجش هدف
  3. پیدا نمودن بزرگترین مانع (محدودیت Constraint)برای رسیدن به هدف
  4. ارائه راه حل برای مشکل (با روش علمی: فرض می کنیم راه حل پیشنهادی راه درست است)
  5. آزمایش علمی برای اطمینان از درست و کاربردی بودن راه حل
  6. پیاده سازی راه حل
  7. داستان ادامه دارد به مرحله 2 برو 





نویسنده :نیما نیازمند
تاریخ:جمعه 1 دی 1391-05:09 ب.ظ


زمان هایی که به هدر رفتند

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

این جمله آشناست نه؟ تا حالا چند بار این دیالوگ را شنیده اید یا آن را بکار برده اید. متاسفانه تنها روش برای سرعت بخشیدن به تولید، افزایش تعداد ساعات کار و تحت فشار گذاشتن تیم تولید است. نا امید کننده است. اگر مدیریت زمان بندی و برنامه ریزی به همراه فرایند بهبود در حال توسعه وجود نداشته باشد زمان زیادی به هدر می رود.

معرفی سه قانون

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

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

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

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





نویسنده :نیما نیازمند
تاریخ:شنبه 21 مرداد 1391-07:18 ب.ظ


آشنایی با مثلث آهنین


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

مثلث آهنین
 
تمام پروژه ها زیر سلطه سه محدودیت زمان ، هزینه و وسعت (Scope) هستند که به عنوان مثلث آهنین یا محدودیت سه گانه شناخته می شوند. فکر نکنم تا حالا پیش آمده باشد روی پروژه ای کار کنید که محدودیت زمانی نداشته باشد. هر پروژه ای فرجه تعیین شده دارد. هزینه یعنی تمام منابع در نظر گرفته شده که شامل تمام تجهیزات و آدمها ست. وسعت ، حجم و کیفیت کاری است که باید انجام شود. بخش بد ماجرا این است که فقط دو ضلع مثلث را می توان انتخاب کرد ، ضلع سوم را باید برای جبران محدودیت ایجاد شده در انتخاب قبلی حساب کرد. مثلا برای تحویل یک سیستم خدمات پس از فروش با وسعت توافق شده در مدت 3 ماه یعنی انتخاب زمان و وسعت ، ناچار به افزایش تعداد نیرو (منابع) برای جبران محدودیت وسعت زیاد در زمان کم هستیم. اگر تعداد نیرو ها و زمان ثابت باشد باید برای جبران کمبود وقت از وسعت پروژه کم کنیم. (اکثرا پروژه هایی که با متد agile پیش می روند از این حالت استفاده می کنند) با این که نمی توان سه ضلع را انتخاب کرد ، اما با یک فرایند و مدیریت علمی می توان تا حدی بر این مثلث غلبه کرد و آن را شکست.




نویسنده :نیما نیازمند
تاریخ:یکشنبه 21 خرداد 1391-05:39 ب.ظ


همه چیز زیر نور هدف رنگ می گیرد (بخش دوم)

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

معیار های سنجش در نرم افزار
انبار (Inventory) : هر چیزی که وارد سیستم می شود و در انتظار می ماند تا کاری روی آن انجام شود شامل تمام ایده ها ، نیاز های سیستم و feature ها است.

واحد سنجش انبار: سرانجام فرایند تولید، تحویل قابلیت های ارزشمند برای مشتری (client-valued functionality) است. نرم افزار باید نیاز های مشتری را برآورده کند. دنیای agile از user story, backlog item, feature برای مستند کردن feature های سیستم استفاده می کند که همگی بیانگر که یک قابلیت کوچک از دید مشتری هستند که می توان آن ها را در کمتر از چند روز انجام داد. و از واحد های Fibonacci point, T-Shit size, 5 point scale برای سنجش وزن feature یا سنجش تلاش لازم برای انجام یک feature استفاده می شود. معیار های agile برای سنجش انبار کاملا مناسب هستند. اما use case معیار مناسبی برای سنجش نیست. بزرگترین مشکل use case به عنوان واحد سنجش نبودن یک فرمت استاندارد مورد توافق همه است. البته در یک سازمان معمولا فرمت یکسانی برای نوشتن آن وجود دارد. مشکل بعدی این است که پیاده سازی یکuse case  ممکن است هفته ها یا ماه ها به طول انجامد به همین علت واحد ملموسی برای بیان تعداد واحد های انجام شده در یک یا چند روز نیست.

Lead time: مدت زمانی که یک واحد از انبار بیرون آمده و برای مشتری قابل استفاده می شود.

نرخ تولید (Production rate): تعداد واحد هایی که در یک دوره از زمان انجام می شوند. برای مثال یک تیم می تواند 50 point در هفته پیاده سازی کند.

زمانی در جهت هدف حرکت می کنیم که تعداد واحد های موجود در انبار پایین، lead time پایین و نرخ تولید بالا باشد.





نویسنده :نیما نیازمند
تاریخ:یکشنبه 7 خرداد 1391-07:55 ب.ظ


همه چیز زیر نور هدف رنگ می گیرد (بخش اول)

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





نویسنده :نیما نیازمند
تاریخ:یکشنبه 24 اردیبهشت 1391-07:51 ب.ظ