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

درباره وبلاگ

آرشیو

آخرین پستها

طبقه بندی

نویسندگان

ابر برچسبها


Admin Logo
themebox Logo


تئوری پنجره شکسته

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

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

شما چند تا پنجره شکسته در پروژه دارید؟




نویسنده :نیما نیازمند
تاریخ:جمعه 10 آبان 1392-01:46 ب.ظ
نوع مطلب : علم مدیریت 


منطق ، عقل سلیم و روش علمی (بخش دوم)

- حالا سوال اینه که چرا سریع پیش رفتن، با اصولی کار کردن در تضاده، این فرض از باوره یا حقیقت؟
- به نظر می یاد اصولی کار کردن زمان بیشتری می گیره. زمان بیشتر برای پیدا کردن راه حل خوب و در نتیجه کار بیشتر برای پیاده سازی آن.
- به عنوان برنامه نویس وقتی می خوام feature جدید اضافه کنم به دو مورد فکر می کنم: همه ما می دونیم با هر درخواست جدید که از طرف مشتری می شه، یه بخشی از سیستم تغییر می کنه پس سعی می کنم طوری کد بنوسیم که در آینده تغییر کمتری داشته باشم ، دوم اینکه بخشی از کارم مرتبط با کد های موجود می شه که ممکنه شخص دیگه ای نوشته باشه که به جزئیاتش آشنا نباشم یا کاره خودم باشه ولی یادم نیاد چیکار کردم! اکثرا مجبورم کد موجود رو تغییر بدم و این احتمال وجود داره که یک قسمتی رو از کار بندازم. یونیت تست ها تا حد زیادی می تونن کمک کنن ولی برداشتم اینه که نوشتن تست زمان گیره برای همین یونیت تست ها رو یه کار جانبی می دونم. ترجیح می دم یه کار موقتی انجام بدم که سریع تر باشه مثلا یکپارچگی با کل سیستم رو نادیده بگیرم یا هماهنگی با بقیه رو . هرچند دفعه بعد یک نفر دیگه شایدم خودم سر کد های موقتی گیر کنه در نتیجه کلاف این اسپاگتی بیشتر می شه. برای اینکه تغییر کمتری داشته باشیم باید بیشتر فکر کنیم که زمان بیشتری می گیره از طرفی برای این که سریع تر کار کنیم باید کمتر فکر کنیم که در آینده تغییرات بیشتری داریم یه تضاد دیگه!
- همیشه دنبال انتخاب راه حل ایده آلی که همه حالت ها رو جواب بده هستیم ، ولی اگه پیش بینی برای تغییرات آینده درست نباشه تمام زمانی که برای فکر کردن را حل ایده آل صرف شده هدر میره و کدی داریم که استفاده نمی شه و دوباره برای تغییرش زمان مورد نیازه!
- دقیقا ، تغییر جز توسعه نرم افزاره برای همین آجایل رو انتخاب کردیم اگه تغییر رو به عنوان واقعیت نرم افزا بپذیریم تلاش برای تغییرات کمتر بی فایده است!
- راهی هست که بشه کد رو به راحتی تغییر داد؟
- تغییر همیشه سخت تر و زمان گیر تره بهترین راه اینه که اصلا چیزی رو تغییر ندیم.
- ها!!!
- جدی می گم! جا انداختن یه سبک جدید مشکلات خودشو داره ، تا کاملا عادت بشه همش روش قدیمی پیاده می شه. بنابراین باید یه قاعده ساده باشه که هر کسی با یاد آوریش به سوی کد تغییر پذیر سوق داده بشه و اونم اینه که دیگه هیچ کس نباید کد نوشته شده رو تغییر بده باید کد جدید بنویسه.
- اینطوری که هر کسی ساز خودشو می زنه و  کلی کد تکراری پیدا می شه!؟
- اگه هنگام نوشتن کد به abstraction, re-usability, separation of concern توجه کنیم کد تکراری نخواهیم داشت!
- دیگه خیلی فنی شد ، جزئیات فنی برای تیم تولید. ولی از کجا مطمئینی حواب می ده ، فرصتی برای آزمون و خطا نداریم.
- اتفاقا منم از آزمون و خطا بدم می یاد در روش علمی یه مرحله داریم به اسم آزمایش علمی. همون طور که می دونی هیچ وقت نمی شه درستی یک فرضیه رو صد درصد اثبات کرد و ممکنه بعدها نادرستیش ثابت بشه و اینکه برای اثبات درستی می تونیم صد ها دلیل بیاریم ولی یک دلیل ، نادرستی رو ثابت می کنه. بنابراین کاری که باید انجام بدبم اینه که ثابت کنیم فرضیه نادرست نیست ولی چون راجبه علم محض صحبت نمی کنیم می شه از دلیل و منطق برای اثباتش استفاده کرد.
به طور خلاصه : بخشی از زمان برای پیدا کردن راه حل ایده آل که همه حالت ها رو جواب یده و بعدا نیاز به تغییر نداشته باشد صرف می شه و بعد از اون اگه راه حل جواب نده دوباره برای درست کردنش زمان صرف می کنیم در نتیجه برای ذخیره زمان راه حل موقتی ولی سریع تر پیدا می کنیم که سر فرصت بعدی درست کنیم. یعنی تغییراتی رو برای آینده باقی می زاریم که خودش کارو مضاعف می کنه. به عنوان راه حل فرض می کنیم اگر تغییر رو به عنوان واقعیت قبول کنیم و طوری کد بنویسیم که در آینده به راحتی و سرعت قابل تغییر باشه زمان زیادی صرفه جویی می شه و بهترین راه برای ایجاد کد تغییر پذیر ، تغییر ندادن کد موجوده. برای این کار باید روی interface ها متکی بشیم و به جای تغییر کد موجود پیاده سازی جدیدی رو برای اینترفیس ها داشته باشیم اگه فرضمون درست نباشه سرعت توسعه زیاد نمیشه از اونجایی که دیگه زمانی برای تغییرات و پیشبینی صرف نمی شه و پیش بینی کردیم که این زمان از زمان تولید کسر می شه ، پس بازم دلیلی وجود داره که زمان می گیره می شه.
- سوال اینه که چه دلیلی؟
-الان نمی تونم موردی پیدا کنم ، اگه موردی باشه فرضیه نادرسته. البته ممکنه پیاده سازی روش جدید وقت گیر باشه که می تونیم با یه جلسه آموزش 2 ساعته و پیاده سازی روی یه فرم تست کنیم یعنی تست در مقیاس کوچک.
- پس اون فرم هم جز لیست کار ها اضافه شد؟
- یه جلسه با تیم تولید می زارم بعد راجب اون فرم صحبت می کنیم.
- دقیقا روش علمی رو دنبال کردیم 1- شناسایی مشکل با پیدا کردن ریشه مشکل 2- شکل دادن یک فرضیه به عنوان راه حل با باور این که هیچ تضادی وجود نداره و به چالش کشیدن فرضیاتمون 3- اثبات فرضیه با سعی در اثبات نا درست بودن آن.
- منطق ، عقل سلیم ، روش علمی
- گفتی دقیقا چه منابع علمی رو خوندی
- فکر کنم به مدیریت فروش علمی علاقه مند شدی
- چرا که نه


پا نوشت : برای پیاده سازی با این روش باید pattern ها و principal های زیر رو استفاده کنید.
SOLID
Separation of concern
Law of Demeter
Keep it simple stupid
you aren’t’ gonna need it
don’t repeat yourself





نویسنده :نیما نیازمند
تاریخ:یکشنبه 24 شهریور 1392-09:01 ق.ظ
نوع مطلب : علم مدیریت 


منطق ، عقل سلیم و روش علمی (بخش اول)

-  یکی از مشتری ها یه فرم ساده برای ورود یه سری اطلاعات می خواد
- الان اصلا نمی رسیم کار جدیدی شروع کنیم ، به سختی یتونیم کارای موجود رو سر وقت برسونیم!
- خیلی وقت نمی گیره ، یه فرم ساده ست. یه ساعته در می یاد ، بعدا جزء سیستم موجود می شه.
- یک ساعت !!! همیشه با یه فرم ساده شروع می شه ، همین فرم ساده نیاز به حذف و ویرایش و نمایش داره که به چشم نمی یاد. بعد گزارش و انواع شرایط  و گردش کار و ...
- خودت اجایل رو انتخاب کردی، گفتی می شه اولویت ها رو تغییر داد.
- الان که اولویت چیزی رو عوض نکردی داری به کارای (Task) موجود، یه کار جدید با اولویت بالا اضافه می کنی! می شه اولویت ها رو عوض کرد ولی نمی شه کاری رو نصفه رها کرد. می تونیم تسک جدید رو با یه تسک انجام نداده عوض کنیم یا باید صبر کنی برای iteration بعدی. هم می تونیم نیروی جدید بگیریم.
- نه هیچ کدوم نمیشه ، حالا فعلا یه چیزی در بیاد کارشون راه بیوفته تا بعد. رو سرم سوار شدن!
- فقط این نیست ، این کار کیفیت کد رو پایین می آره. دیدن یه فرم ساده با یه سیستم فرق می کنه بعد feature های دیگه می خوان ، اونم با عجله. همیشه با یه چیزه ساده شروع می شه و بعد تبدیل به اسپاگتی می شه. نگهداری سیستم کابوس می شه. با این ترافیک کاری که ایجاد کردی هیچ وقت نمی شه کد های قبلی رو باز بینی کنیم. حتی اگه کسی یه باگ ببینه مجبوره نا دیده بگیره چون وقت نداره درستش کنه!
- قبول، ولی به مشتری نمی شه نه گفت. محصول رقیبها آمادست ممکنه سویچ کنن. سنگ تراش یه چیزی بتراش. مشتری یه چیزی می خواد که کار کنه براش مهم نیست که داخلش اسپاگتیه یا اصول.
- قراره مشکل رو حل کنیم یا به هم پاس بدیم؟
- راه حلی داری !؟
- برای این که مشتری رو راضی نگه داریم باید با سرعت بیشتری کار کنیم در نتیجه کیفیت کد پایین می یاد و از طرفی برای این که نرم افزار قابل نگه داری داشته باشیم باید کد با کیفیت داشته باشیم که اونم سرعت تولید رو پایین می آره.
- دنیا پر از چیز های متضاده، باید یک توازن بین این دو رو انتخاب کنی تا ...
- کاریه که الان داریم انجام می دیم. فکر می کنم به خاطر همین ایجاد توارن در تضاد، کارا بد پیش می ره. احتیاج به سرعت نور داریم تا با این منابع کم کارو پیش ببریم حتی با اجایل هم نمی تونیم سریع تر پیش بریم. یه چیزی به فکرم رسید چند وقته دارم مقالات علمی می خونم، باید از زاویه علمی به مشکل نگاه کنیم.
- خوب ؟
- کل گرایی (Holism) یعنی یک سیستم رو باید بصورت کل ببینیم نه مجموعه ای از اجزا. شناخت اجزا باعث شناخت کل نمی شه ، کل از با هم بودن اجزا و تعامل بین آنها بوجود می آد. مثلا آب که از 2 مولکول هیدروژن و 1 مولکول اکسیژن درست شده ولی شناخت مولکول های تشکیل دهندش باعث شناخت آب نمیشه. متاسفانه چون سیستم ها اکثرا پیچیده هستن و درکشون سخته ما اونا رو به اجزاشون تقسیم می کنیم و هر جز رو جدا بررسی می کنیم بنابراین سیستم او طوری که هست فهمیده نمی شه و در نتیجه راه حل درست پیدا نمیشه.
- چطوری می شه بدون تقسیم یه سیستم پیچیده ، کل رو درک کرد؟
- اگه پیچیدگی رو زیادیه اجزا بدونیم مشکل می شه درکش کرد. برای مثال مفهوم حرکت ، پیچیده ست ولی نیوتن با سه قانون حرکت اونو به سادگی بیان کرد. برای فهم سیستم باید دنبال اجزایی باشیم که تغییر اونها باعث تغییر در کل سیستم می شه.
- یعنی باید ریشه ی مشکل(root cause)  رو پیدا کنیم؟
- مشکلات معمولا علائمی هستند که به خاطر درست کار نکردن یکی از علت های ریشه ای (common causes) بوجود می یان. اگه سیستم رو به این شکل ببینیم یعنی فقط اجزای کمی هستند که روی کل اثر می گذارن ، سیستم نه تنها پیچیده نیست بلکه بهبود سیستم راه حل ساده ای داره.
- داره جالب می شه!





نویسنده :نیما نیازمند
تاریخ:جمعه 15 شهریور 1392-02:00 ب.ظ
نوع مطلب : علم مدیریت 


استفاده از قوانین و نظریه های علمی در مدیریت پروژه (بخش اول)

سومین قانون حرکت نیوتن

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

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

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





نویسنده :نیما نیازمند
تاریخ:جمعه 24 شهریور 1391-06:18 ب.ظ
نوع مطلب : علم مدیریت 


آشنایی با علم و کاربرد آن در مدیریت پروژه (بخش دوم)

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

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

برای سالها دانشمندان از روش علمی برای پیدا کردن پاسخ برای سوالات استفاده کرده اند. روش علمی یک روش سیستماتیک و تکرار شونده (Iterative) است که شامل شناسایی مشکل به شکل شفاف ، جمع آوری اطلاعات مرتبط با مشاهده کردن، شکل دادن یک فرضیه به عنوان راه حل و آزمایش علمی برای اثبات فرضیه است.




نویسنده :نیما نیازمند
تاریخ:شنبه 24 تیر 1391-07:55 ب.ظ
نوع مطلب : علم مدیریت 


آشنایی با علم و کاربرد آن در مدیریت پروژه (بخش اول)

مدیریت پروژه همانند کشف غار در دل کوه است که با هر دالانی که طی می کنیم یک دو راهی جدید نمایان می شود. با هر مسیری که طی می کنیم مسیر های باقی مانده بی پایان به نظر می رسند. برای حرکت در این مسیر به دانش بسیاری نیاز است ، با هر قدمی که بسوی مسیر های مدیریت پروژه پیش می بریم کمبود دانش بیشتر احساس می شود. شاید کمی روان شناسی برای ایجاد انگیزه در بچه های تیم و سرو کله زدن با آنها ، دانش فنی برای فهمیدن مشکلات و موانع فنی ، دانستن روش آموزش برای رشد تیم ، روشهای زمان بندی و فرآیندهای تولید ، روشهای بهبود سیستم، منطق برای سرو کله زدن با مدیران و ذینفعان و متقاعد کردن آنها و ...
برای بدست آوردن دانش مورد نیاز ،صدها کتاب منتظر خوانده شدن هستند. چگونه می توان با چند قانون و قائده مشکلات را حل کرد .آیا می توان با یک ابزار یا یک فرایند فکری از پس گذشتن از این مسیر تو در تو در آمد. بشر در طول قرن ها از علم برای درک و شناخت دنیای پیرامون خود استفاده کرده است. با روش علمی می توان به عنوان روشی برای حل مسائل و مشکلات پروژه استفاده کرد.
تعریف علم
قبل از این که بتوانیم از روش علمی برای مدیریت پروژه استفاده کنیم باید درک درستی از علم داشته باشیم. گلدرت توسعه علمی را در سه مرحله تعریف می کند: طبقه بندی (Classification)، ارتباط (Correlation) و علت و معلول (Cause and effect) .
مرحله طبقه بندی ابتدای توسعه علمی است. در این زمان، مفاهیم نام گذاری می شوند و در طبقه مناسب قرار می گیرند. در علم پزشکی طبقه بندی بیماری ها با توجه به علائم آنها و نوع آلوده سازی آنها بود. اصطلاحاتی مثل واگیر دار یا نام بیماری ها در این مرحله شکل گرفت. مرحله ارتباط ، زمانی است که ارتباط بین چیز ها پیدا می شود و الگو ها کشف می شوند. با کشف سرم علم پزشکی به مرحله دوم رفت. در این مرحله فهمیدن که با وارد کردن سرم از خون گاو به بدن انسان ، انسان نسبت به بیماری مقاوم می شود. در آن زمان نمی دانستند چرا فقط ارتباط بین سرم و مقاومت نسبت به بیماری پیدا شده بود. علت و معلول آخرین مرحله توسعه علمی است ،مرحله چرا ها و علت ها، فقط در این مرحله می توانیم از نام علم استفاده کنیم. مرحله سوم در پزشکی زمانی بود که میکروب کشف شده یعنی علت بیماری.




نویسنده :نیما نیازمند
تاریخ:سه شنبه 30 خرداد 1391-05:20 ب.ظ
نوع مطلب : علم مدیریت 


علم یا هنر مدیریت پروژه !

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




نویسنده :نیما نیازمند
تاریخ:جمعه 15 اردیبهشت 1391-08:19 ق.ظ
نوع مطلب : علم مدیریت