راستش تا حالا کسی از مخاطبهای سایت چنین سوالی از من نپرسیده، ولی یه بار که تو دوره آموزش حین خدمت آموزش و پرورش درس میدادم این سوال رو زیاد ازم پرسیدن و الان هم یه گزارش پیشرفت جلومه که نمودارهاش سهبعدیان. به این خاطره که میخوام به این سوال جواب بدم.
سوال: چه زمانی از نمودارهای سهبعدی استفاده کنیم؟
پاسخ: هیچوقت!
نمودارهای سهبعدی هیچ نکته مثبتی ندارن و خواناییشون هم همیشه کمتر از نمودارهای دو بعدیه. در نتیجه هیچ دلیلی نداریم که ازشون استفاده کنیم.
بعضیها احساس میکنن نمودارهای سهبعدی قشنگترن و به همین خاطر ازشون استفاده میکنن. به نظر من قشنگتر هم نیستن. از اون گذشته، اگه زیبایی براتون اهمیت داره، همیشه میتونین به روشهای حرفهایتری گزارشهاتون رو زیبا کنین، طوری که همراه با زیباتر شدن، خواناتر هم بشن. اگه دوست دارین تو این زمینه پیشرفت کنین، باید کتابهایی که درباره Information Visualization نوشته شده رو بخونین و در این بین کتابهای استیفن فیو از واجبات هستن. این اسم براتون آشنا نیست؟ این آدم همونیه که نمودارهای گلولهای رو ابداع کرده.
اگه میخواین بپرسین که “اگه نمودارهای سهبعدی به درد نمیخورن، اصلا چرا اکسل همچین چیزی داره؟”، جواب من اینه که “برای اینکه قابلیتی از نرمافزارهای رقیب کم نداشته باشه” و اگه بپرسین …
اگه میخواین به زمان و کارهایی که میکنین مسلط باشین، حتما باید یه “ژورنال” داشته باشین: یه فایل ورد یا اکسل یا حتی فایلی که با نرمافزارهای مخصوص این کار ساخته میشه. باید تمام کارهایی که در طول روز میکنین و مدت زمانی که برای هرکدوم صرف میکنین رو تو فایل وارد کنین.
خیلی مشخصه که یه فایده این کار اینه که بعدا میتونین به فایل مراجعه کنین و جواب بعضی سوالهاتون رو پیدا کنین (فلان گزارش رو چه تاریخی برای بهمان جا فرستادم؟)؛ ولی این اهمیت زیادی نداره.
فایده اصلی اینه که میفهمین زمانتون رو چطوری صرف میکنین. واقعیت اینه که همه مدت زیادی از زمانمون رو صرف کارهای کم ارزش میکنیم و اگه اون زمان رو کم کنیم و بذاریمش برای کارهای مهمتر، خیلی موفقتر خواهیم بود. برای این کار باید مدت زمانی که برای هر نوع کاری صرف میکنین رو مشخص کنین و میزان محصولی که به دست آوردین رو هم حساب کنین. بعد از اینکه اطلاعات چند ماه رو تحلیل کنین (که قطعا یه کارشناس برنامهریزی و کنترل پروژه باید خیلی تو این کار وارد باشه)، مطمئنا تحت تاثیر جوابها قرار میگیرین. قدم بعدی اینه که برای تغییر سیستمتون برنامهریزی کنین و همچنان ارزیابی رو ادامه بدین. میدونم که اکثرا تا حالا چنین کاری نکردین؛ این همون ماجرای کوزهگریه که از کوزه شکسته آب میخوره. یه کم هم به فکر خودتون باشین.
تو خیلی از پروژهها علاوه بر اجرا، طراحی هم داریم. اشتباه رایج اینه که پیشرفت طراحی رو هم مثل اجرا تعیین میکنیم. مثلا میگیم که نقشههای سیستم اعلان حریق فلان ساختمون ماه پیش 32٪ بوده و این ماه شده 58٪.
این روش به دو دلیل درست نیست:
تعیین پیشرفت واقعی طراحی عینی نیست. چطوری میخوایم بگیم که 58 درصد کار انجام شده؟ مثلا تعداد ساعتهای کاری که روش انجام شده رو به برآورد اولیه تقسیم کنیم؟ بعیده برآورد اولیه کاملا درست باشه. چیکار میکنیم؟ عملا شهودی میشه. ولی پیشرفت کارهای اجرایی اینطوری نیست. مثلا پیشرفت ساخت یه دیوار رو وقتی میخوایم تعیین کنیم خیلی راحت مقدار ساخته شدهش رو به کل مقدارش تقسیم میکنیم و این کل مقدار کاملا مشخصه.
نتایج طراحی معمولا پیش از تکمیل کاملا در دسترس مشاور مادر و کارفرما قرار نمیگیره و اونها پیش از تکمیل نمیتونن دقیقا بدونن که چقدر کار انجام شده. این هم باز با دیوارکشی فرق میکنه، چون وقتی پیمانکار داره یه دیوار رو میسازه هرکسی میتونه بره، اون رو ببینه و بفهمه که چقدر کار انجام شده.
نتیجه هم اینه که پیمانکار یا مشاور طراح، مشاور مادر و کارفرما دایما در مورد درصدهای پیشرفت اختلاف نظر خواهند داشت.
به خاطر تمام این مسایله که معمولا تو همه جای دنیا پیشرفت طراحی رو مثل کارهای اجرایی ارزیابی نمیکنن. امیدوارم متوجه شده باشین که منظورم مشخص کردن پیشرفت …
یکی از چیزایی که معمولا تو گزارشها وجود داره، سرفصلیه با اسم “موانع و مشکلات پروژه”. این سرفصل خیلی مهمه و حتما هم باید تو گزارشها باشه، حتی من همیشه تاکید میکنم که اگه مشکلی وجود نداره هم سرفصل رو بذارن و بعد زیرش بنویسن که این دوره مشکلی نبوده.
چیزایی که برای این سرفصل نوشته میشه معمولا مشکلایی داره و میخوام درباره این مشکلا و راه بهتر کردنشون بگم. اولین نکته اینه که باید عنوان این سرفصل رو عوض کنیم. “موانع و مشکلات” جالب نیست، منفیه. به جاش بذاریم “مشکلات و راه حلها”. این باعث میشه همه یادشون باشه که اگه به مشکلی اشاره میشه، به این خاطره که راه حلش پیدا بشه.
خیلی وقتا تو این سرفصل آیتمهای اینطوری میبینیم:
عقب افتادن کارها به خاطر تاخیر مشاور در ارائه نقشهها.
این آیتم به هیچ دردی نمیخوره؛ نق زدنه و گزارش جای نق زدن نیست. آیتم درست اینه:
عقب افتادن فلان کار، به خاطر اینکه طبق زمانبندی مصوب انتظار داشتیم مشاور بهمان نقشه رو تو فلان تاریخ به ما تحویل بده، در حالی که در بهمان تاریخ تحویل داده.
این میشه یه ادعای درست و حسابی که جای بررسی داره. وقتی ادعا اینطور دقیق باشه خیلی بهتر هم آدم رو به سمت پیدا کردن راه حل هدایت میکنه. خوب، برای اینکه این آیتم کامل بشه باید یک یا چند راه حل هم بدیم. مثلا برای این آیتم فرضی:
وقتی یه کارشناس پیشرفت میکنه چی میشه؟ میشه مدیر. این تصور خیلی اشتباهه.
این تصور از چند جهت اشتباهه:
مدیریت با کار کارشناسی خیلی تفاوت داره؛ مثل این میمونه که من بگم کارشناس طراح تاسیسات برقی هستم و دلم میخواد پیشرفت کنم بشم کارشناس اجرایی سازه؛ ربطی نداره.این پیشرفت نیست، تغییره. خیلیها هستن که وقتی کار کارشناسی رو ترک میکنن و مدیر میشن حوصلهشون سر میره، چون کاری که دوست دارن کار کارشناسیه، نه مدیریتی.
درسته که مدیریت از لحاظ سازمانی بالاتر از کارشناسیه و معمولا آدمها بعد از مدتی کارشناس بودن تبدیل به مدیر میشن، ولی این هم باعث نمیشه که آدم فکر کنه پیشرفتش در گروی اینه که بشه مدیر. آدم میتونه کارشناس قویتری بشه، freelance و مشاورهای کار کنه، کارهای هیجانانگیزتر بگیره، با شرکتهای قویتر کار کنه، تو انتخاب کار و شرایط انجامش دستش بازتر باشه، درآمد خیلی بالاتر داشته باشه و …
مدیریت یه تخصصه. آدم وقتی میتونه مدیر باشه که دانش و مهارت کافی داشته باشه؛ البته به نظر خیلیها باید یه سری خصوصیتهای ذاتی و غیر اکتسابی هم داشته باشه. پیشرفت در کار کارشناسی برای مدیر شدن کافی نیست و فرد حتما باید مهارتهای مدیریتی خودش رو هم ارتقا بده. حتی کارشناس خبره بودن شرط لازم برای مدیر بودن هم نیست، اگه مدیر اطلاعاتی کلی درباره جنبههای فنی کار داشته باشه کافیه. این اشتباه رو زیاد …
جدیدا دو شرکت مختلف به من برنامههایی داده بودن که پیشرفتهای فیزیکیشون با فیلدهای اختصاصی محاسبه میشد و هردو شرکت روش خیلی بدی رو انتخاب کرده بودن. من قبلا ندیده بودم که محاسبات برنامه رو به این ترتیب انجام بدن و الان که تو این فاصله زمانی کوتاه دو بار چنین چیزی رو دیدم واقعا نگران شدم و باعث شد که این مطلب رو بنویسم.
برنامههایی که میگم یه فیلد اختصاصی دارن برای ضرایب وزنی. یه فیلد اختصاصی دارن برای اینکه پیشرفت واقعی فعالیتها رو دریافت کنه و یه فیلد اختصاصی دیگه برای اینکه پیشرفت فیزیکی تمام آیتمها رو ارائه کنه.
مشکل این روش اینه که اطلاعات پیشرفت فقط تو فیلدهای اختصاصی باقی میمونن و به هیچ وجه تو برنامه عملیاتی نمیشن. این حالت هیچ فرقی با این نمیکنه که یه لیست از فعالیتها تو اکسل داشته باشین و پیشرفتها رو همونجا وارد کنین و نتیجه بگیرین. به نظر شما این درسته؟
تو این حالت نه میشه تاخیر CPM رو محاسبه کرد، نه میشه پیشرفتهای برنامهریزی شده دورهای ترکیبی رو به دست آورد، نه میشه لیست فعالیتهای دوره بعد رو به راحتی به دست آورد، نه میشه محاسبات ارزش کسب شده و زمان کسب شده رو به دست آورد، نه میشه تاریخ پایان تخمینی پروژه رو حساب کرد، نه میشه شاخصهای عملکرد زمانی رو به دست آورد و … فقط میشه پیشرفت واقعی تجمعی، پیشرفت واقعی دورهای، پیشرفت برنامهریزی شده تجمعی و …
خیلیها درباره شیوه محاسبه تاخیر تو شرایط مختلف از من میپرسن. جواب هم همیشه بستگی داره به شیوه پایش، نوع فعالیتها و …
ولی یه نکته رو فراموش نکنین؛ بهترین راه برای ارزیابی عملکرد زمانی پروژه، استفاده از روش زمان کسب شدهس (توسعهایه برای تحلیل ارزش کسب شده) و محصولش به مراتب بهتر از چیزیه که فقط با روش مسیر بحرانی به دست میارین. سخت هم نیست، نگران نباشین!
در کنار این مسئله، باز هم از همه یه درخواست تکراری دارم: لطفا از عبارت “تاخیر” فقط برای اشاره به زمان استفاده کنین، بهتره به اختلاف پیشرفت واقعی و برنامهریزی شده بگیم “انحراف”، نه “تاخیر”. این توصیه صرفا به این خاطره که سوتفاهم به وجود نیاد و منظور به خوبی منتقل بشه.
عدهای از همکارانمون برای من برنامهای (پراجکتی) فرستاده بودن که دیدم توش تاریخها با فرمول محاسبه میشه. چون این روش ممکنه برای بعضیها به درد بخوره، فرمولهاش رو میذارم اینجا. از اون همکاران پرسیدم که فرمولها رو چه کسی تهیه کرده تا اینجا ازش نام ببرم، که متاسفانه اسمش رو نمیدونستن. در هر حال با تشکر از این فردی که نمیشناسیم.
فرمول تاریخ شروع:
(Int((Int([Start]-DateValue("21/3/1997 00:00:00"))-Int(Int([Start]-DateValue("21/3/1997 00:00:00"))/1461))/365)+76) & "/" & (IIf(((((Int([Start]-DateValue("21/3/1997 00:00:00")))-Int((Int([Start]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))<=186,Int(((((Int([Start]-DateValue("21/3/1997 00:00:00")))-Int((Int([Start]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))/31)+1,Int((((((Int([Start]-DateValue("21/3/1997 00:00:00")))-Int((Int([Start]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))-186)/30)+7)) & "/" & (IIf(((((Int([Start]-DateValue("21/3/1997 00:00:00")))-Int((Int([Start]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))<=186,Int(((((Int([Start]-DateValue("21/3/1997 …
تا حالا اصطلاح Halo Effect رو شنیدین؟ میشه ترجمهش کرد به اثر هاله نور.
قبلش یه سوال میپرسم. به نظر شما مدیر پروژه چه تخصصیهایی باید داشته باشه؟
جواب خیلی سادهس، تخصص در مدیری پروژه؛ همین.
کسی میتونه مدیر پروژه باشه که در مدیریت پروژه تخصص داشته باشه. سادهتر از این؟
تخصص فنی تو حوزه پروژه چطور؟ خوب، اگه باشه بهتره، ولی نبود هم نبود. مثلا اگه پروژه ساختمانیه، اجباری نیست که مدیر پروژه متخصص ساخت و ساز باشه، ولی حتما باید مدیریت پروژه بدونه.
این میشه گرایش PMI و همه سیستمهای حرفهای دیگهای که من تا حالا دیدم.
حالا مشکل چیه؛ مشکل در اینه که اکثرا فکر میکنن اگه کسی تو حوزه کاری پروژه تخصص داشته باشه میتونه مدیر پروژه باشه. مدیر پروژه از نظر خیلیها متخصصترین کارشناس حوزه کاری پروژهس. به این میگن Halo Effect.
این Halo Effect مدیریت پروژه رو به شدت دست کم میگیره. انگار پروژه به جز مسایل فنی مسئله دیگهای نداره؛ انگار نه انگار که باید مجموعه بزرگ و موثری از کارهای مدیریتی هم توی اون انجام بشه و این کار نیاز به متخصص مدیریت و به طور خاص، متخصص مدیریت پروژه داره.
کسی به عنوان کارشناس خیلی موفقه، میکننش مدیر پروژه. این آدم اگه استعداد داشته باشه به تدریج قسمتی از مهارتهای مدیریت پروژه رو یاد میگیره و بعد از اینکه چنتا پروژه رو چندان موفق پیش نبره، به تدریج موفقتر میشه. …
تا حالا شده فایل پراجکتی به دستتون برسه که توش قالببندی تمام عناصر نمای گانت (یا نمایی دیگه) رو عوض کرده باشن و قالببندیشون هم به نظرتون جالب نباشه؟
منظورم فونتهاییه که هرکدوم یه اندازهای هستن، رنگهای عجیب و غریب، بولد بودنهای بیدلیل و …
اگه سعی کرده باشین قالببندی رو به حالت معمولی برگردونین قطعا میدونین که کار وقتگیر و سختیه. راه ساده؟
بله، راه ساده هم داره؛ امروز اتفاقی وقتی میخواستم قالببندی یه برنامهای رو درست کنم به نظرم رسید.
منطق قالببندی در پراجکت
قبلش باید این رو توضیح بدم. پراجکت تمپلیتی داره به اسم global.mpt و تمام قالببندیها توی اون ذخیره میشن. اون نمای گانتی که تو فایلهای جدید میبینین از اون تمپلیت میاد.
وقتی یه فایل جدید میسازین، هر نمایی که لازم داشته باشه از global.mpt خونده میشه و تو خود فایل ذخیره میشه. تا این مرحله قالببندیها تفاوتی ندارن. حالا اگه کاربر قالببندی رو عوض کنه، نسخهای که تو خود فایل هست تغییر میکنه و global.mpt دست نخورده میمونه. به این خاطر فایل رو تو هر کامپیوتری که باز کنین همون نمایی که اختصاصیسازی شده رو میبینین و در عین حال اگه فایل جدیدی بسازین باز هم از همون قالببندی پیشفرض استفاده میشه.
شیوه بازیابی قالببندی پیشفرض
حالا اگه از قالببندی اختصاصیسازی شدهای که تو فایل هست خوشمون نیاد باید چیکار کنیم؟ خیلی …
احتمالا میدونین که عملکرد قید As Late As Possible تو پریماورا و پراجکت فرق میکنه. وقتی فعالیتی رو تو پریماورا ALAP کنین، شناوری آزادش صفر میکنه، ولی اگه این کار رو تو پراجکت کنین، شناوری کلش صفر میشه.
قید ALAP پراجکت باعث میشه که شناوری کل تمام فعالیتهایی که مستقیم یا غیر مستقیم وابستگیای به فعالیت ALAP شده دارن هم صفر بشه.
هرکدوم از این دو نوع قید کاربردهای خودش رو داره، و خیلی خوب میشد اگه هر دو نرمافزار هر دو نوع قید رو ارائه میکردن، که متاسفانه نمیکنن.
حالا اومدیم و تو پراجکت نیاز به ALAP پریماورایی پیدا کردین. تکلیف چیه؟
میشه با یه مقدار عملیات آکروباتیک موضوع رو حل کرد.
این هم برنامه مثال:
فعالیتی که میخوایم شناوری آزادش صفر باشه، فعالیت a هست. چرا؟
فرض کنین مثلا a یه فعالیت تدارکاتیه. c رنگ دیواره، b خود دیوارکشیه، d هم بقیه کارها. a هم رنگیه که باید برای اونجا بخریم. حالا کی باید بخریمش؟
میشه a رو SF با c کرد تا زمانبندیش درست بشه. ولی تو این حالت اگه a به تاخیر بیفته، c رو به تاخیر نمیندازه، در نتیجه اهمیتش تو برنامه مشخص نمیشه. به این خاطره که ترجیح میدیم a رو پیشنیاز c کنیم (در واقعیت هم همینطوره). حالا اگه معمولی این کار رو کنیم، a تو شروع پروژه شروع میشه، چون خودش پیشنیاز نداره. زمان مناسبش چه موقع باشه؟ بهترین گزینه زمانیه که شناوری آزادش رو صفر …
قسمت مدیریت زمان کتاب راهنمای آزمون PMP ریتا مثالهای زیادی داره، که کاربردی هم هستن. ولی متاسفانه به نظر من اشکالات زیادی هم داره (الان نصف فصل رو ترجمه کردم).
یکی دو جا فرضهایی که برای حل مسئله کرده کافی نیست و سادهانگارانهس. مثلا چون فعالیتها با مدت زمانهای expected بحرانی بودن، فرض کرده که با حدهای بالا و پایین هم بحرانی هستن و مسئله رو حل کرده (و این فرض رو در صورت مسئله نیاورده)، در حالی که وقتی به جای مقادیر expected از مقادیر دیگهای استفاده کنیم میتونه مسیر بحرانی دیگهای به وجود بیاد. خوب، این ماجرا رو با اضافه کردن توضیح حل کردم.
کمی که جلوتر میایم، میخواد مدت زمانهای کل پروژه رو به همین ترتیب حساب کنه و قطعا باید جز به کل حساب کرد. ولی روشی که استفاده کرده به نظر من غلطه (صفحه 193).
باز جلوتر میایم و میخواد چیزی رو با مثال قبل توضیح بده. نتایج حل مثال قبل این بود که مدت زمان expected فعالیتهای A و B به ترتیب 28 و 62 روزه. انحراف معیارشون هم به ترتیب 5.5 و 8 روزه. این دوتا فعالیت بالاترین انحراف معیارها رو دارن. حالا سوال اینه که ریسک کدوم فعالیت بیشتره. نظر شما چیه؟
ریتا میگه فعالیت B بیشتره، چون انحراف معیارش بالاتره. ولی به نظر من درست نمیاد و لازمه که نسبت انحراف معیار رو به مدت expected بسنجیم، که در این صورت ریسک A بالاتر خواهد بود. مسئله سادهایه، فرض …
خیلی وقتا وضعیت پروژه رو اونطوری تعبیر میکنیم که دلمون میخواد، یا اونطوری که به نظر میاد، نه اونطوری که هست. این نمودار رو ببینین:
فرض کنین این نمودار رو جلسهای ارائه شده. حالا قطعا کسایی پیدا میشن (عمدتا تو تشکیلات پیمانکار) که بگن “به به، این دو ماه اخیر پیشرفت پیمانکار خیلی بیشتر شده، نشون میده که وضعشون داره بهتر میشه”.
نظرتون چیه؟
یه بار باید برگردیم عقب. پیشرفت واقعی از کجا اومده؟
یه عددیه که کاملا وابستس به ضرایب وزنی. حالا اگه الان نوبت اجرا به فعالیتهایی رسیده باشه که ضریب وزنیاشون خیلی بالا باشه و زمان اجراشون کوتاه، پیشرفت فیزیکی یه دفعهای رشد میکنه.
حالا الان باید چیکار کنیم؟
خوب قطعا میشه رفت لیست فعالیتها و ضرایبشون و پیشرفتاشون رو نگاه کرد و دید که پیشرفت از کجا اومده. ولی قبل اون خیلی کارهای دیگه هم میشه با همین یه دونه نمودار کرد. به خصوص که ممکنه تو جلسه به اطلاعات تفصیلی دسترسی نداشته باشیم. اولیش اینه که نمودار پیشرفت برنامهریزی شده رو نگاه کنیم. برای اون چه اتفاقی افتاده؟ با یه شیبی جلو رفته، بعد یه دفعهای شیبش زیاد شده. این اتفاق به احتمال زیاد به این معنیه که فعالیتهایی با وزن زیاد و تو زمان کم تو اون موقع بودن. ممکنه الان تو واقعیت هم به همون حد رسیده باشیم؟
این مطلب رو چند وقت پیش برای فصلنامه مدیریت پروژه نوشته بودم، که چون شماره جدید فصلنامه چاپ نشده و ظاهرا هم خبری از چاپش نیست، اینجا منتشرش میکنم.
منظور از پریماورا، نرمافزار Project Management شرکت پریماورا است. مباحث عمدتا معطوف به نسخه خاصی از نرمافزارها نیست، ولی مبنا نسخه 2007 پراجکت و نسخه 6 پریماورا است.
تاریخچه و زمینه
میتوان ادعا کرد که بازار نرمافزارهای برنامهریزی و کنترل پروژه ایران در انحصار پراجکت و پریماورا است. مشابهِ این وضعیت در جهان نیز برقرار است، هرچند که سهم آنها در جهان کمتر از سهمشان در ایران است. در نقاط دیگرِ جهان که نرمافزارها به شیوهای قانونی خریداری میشوند، قیمت به نسبت بالای این دو نرمافزار عاملی برای مطرح شدن نرمافزارهای ارزانتر است. از سوی دیگر، نرمافزارهای پیشرفته و گرانقیمتِ دیگری نیز با سهمی کمتر در بازارهای خارجِ ایران وجود دارند که برای ایرانیان شناخته شده نیستند.
اولین نسخه پراجکت در 1984، در یکی از شرکتهایی که به مایکروسافت خدمات نرمافزاری میداد تهیه شد. یک سال بعد، مایکروسافت امتیاز نرمافزار را خرید و پس از آن به توسعه و انتشار آن ادامه داد. نسخههای سازگار با Mac OS این نرمافزار نیز تولید میشوند.
شرکت پریماورا در سال 1983 پایهگذاری شد و کمی پس از آن نرمافزارهای خود را منتشر کرد. چندی پیش شرکت اوراکل پریماورا را خرید و …
واقعا آدمها با فهم و درک درصد مشکل دارن. این از دو نظر برای شغل ما اهمیت داره:
جلوی اشتباهها و سو تعبیرها رو بگیریم
اگه زمانی لازم شد، به هر دلیلی (امیدوارم لازم نشه) واقعیتی رو جلوه ندیم، میتونیم بدون اینکه رسما دروغ گفته باشیم از این کمبود استفاده (=سو استفاده) کنیم.
اولی که کار همیشگی منه؛ اشتباههای مردم رو تو این حوزه پیدا کنم و بهشون توضیح بدم. دومی رو هم اعتراف میکنم که هر از چندی مجبورم استفاده کنم.
حالا اصلا منظورم چیه…
فرض کنین دارین تو خیابون میرین، یه دفعهای همچین چیزی رو میبینین:
افزایش سقف صادرات به تولید تا 20٪
حالا بگذریم که مشخص نیست که مثلا منظورش اینه که قبلا 50٪ تولیدشون رو صادر میکردن و الان شده 70٪ یا قبلا 17٪ تولید میکردن و الان رسیده به 20٪. اگه دومی باشه هم معلوم نیست که 1٪ بوده که شده 20٪ یا 19٪ بوده و شده 20٪. به هر حال منظورش اینه که این نسبت زیاد شده.
حالا این خوبه یا بد؟
فرض کنین قبلا 10 واحد صادر میکردن و 90 واحد داخل مصرف میشده. حالا الان دارن 8 واحد صادر میکنن و 32 واحد برای مصرف داخل تولید میکنن. تو این سناریو نسبت صادرات از 10٪ رسیده به 20٪. این خوبه؟ قطعا نیست.
یه مقاله بود درباره اینکه 99٪ مبتلایان به ایدز از راه جنسی مبتلا میشن، و کلی گفته بود درباره این که این چقدر بده که تو این حوزه به اندازه کافی آموزش نمیدن (که فکر …
چطوری میشه درصد پیشرفت رو با دو رقم اعشار نشون داد؟
این سوال و سوالهای شبیه اون زیاد مطرح میشه. جواب همه اونها مشابهه و چیزیه که میخوام توضیح بدم. البته من توضیحات رو درباره Complete % میدم، ولی مطمئنم که خودتون میتونین اون رو به بقیه هم ربط بدین؛ به خصوص به Work Complete %.
اعشاری که لازم دارین وجود داره، ولی Complete % نشونش نمیده. این فیلد رو طوری طراحی کردن که مقادیر رو گرد شده نشون بده تا خوانایی بیشتر باشه. فکر درستی هم هست، ولی خوب من هم قبول دارم که بعضیها نیازهایی دارن که باعث میشه نیاز به اعشار هم داشته باشن.
این برنامه مثالمون:
الان اگه به t1 پیشرفت 15٪ بدیم، s1 باید چه مقداری داشته باشه؟
میدونین که Complete % پیشرفت فعالیتها رو با وزن Duration ترکیب میکنه و به وزن خلاصه فعالیتها میرسه. تو این مثال t1 نصف وزن رو داره و در نتیجه پیشرفت 15٪ اون باعث 7.5٪ پیشرفت خلاصه فعالیت مادرش میشه:
ولی Complete % اون رو گرد کرده و شده 8٪. حالا میخوایم همین مقدار رو با دو رقم اعشار به دست بیاریم. راه اینه که یه فیلد اختصاصی بسازیم که مقدار پیشرفت زمانی رو با همون روشی که پراجکت حساب میکنه حساب کنه و اون رو با قالببندی ما نشون بده.
پیشرفت زمانی حاصل تقسیم Actual Duration بر Duration هست. پس فیلدی، مثلا از نوع Number برای این کار میسازیم: