این نمودار مقادیر تجمعی بتن‌ریزی، آرماتوربندی و قالب‌بندی رو تو دوره‌های مختلف نشون می‌ده و متاسفانه امثال این نمودار رو زیاد می‌بینم. در مورد نسبت عددها سخت‌گیری نکنین، چون رندم مقدار گرفتن.
مشکل این نمودار اینه که سه ماهیت مختلف، با سه واحد متفاوت، در یک نمودار و با یک محور عمودی ترسیم شده. به عنوان مثال عدد 1000 در محور عمودی نمودار هم به معنی هزار کیلوگرم آرماتور، هم هزار متر مربع قالب‌بندی و هم هزار متر مکعب بتن‌ریزی به کار رفته.
این شیوه ارائه اطلاعات خیلی بده، چون وقتی چنین نموداری ارائه می‌شه، مخاطب ناخودآگاه مقایسه‌ای بین مقادیر سه خط انجام می‌ده، در حالی که این مقایسه در این شرایط کاملا بی‌معنیه. پایین‌تر بودن خط قالب‌بندی به معنی کار کمتر در حوزه قالب‌بندی نیست، چون قالب‌بندی نرم‌ها و واحدهای دیگه‌ای داره.
اگه قرار باشه سه ماهیت متفاوت رو در یک نمودار قرار بدیم، حتما باید واحدهاشون رو یکسان کنیم. چطوری می‌شه واحدهای این سه ماهیت رو یکسان کرد؟
ساده‌ترین راه اینه که تمام مقادیر رو بر برآورد کلیشون تقسیم کنیم و نشون بدیم که چه درصدی از کل بتن‌ریزی، کل آرماتوربندی و کل قالب‌بندی انجام شده. به این ترتیب همه مقادیر با واحد درصد هستن و نشون دادنشون تو یک نمودار منطقی‌تره.
حالا از همه این‌ها که بگذریم، چه دلیلی داره که همزمان هر سه مقدار رو نشون …
فرض کنین می‌خوایم مقدار دوره‌ای بتن‌ریزی رو تو دوره‌های مختلف نشون بدیم. تو این مثال دوره‌ها رو با A، B، C و امثال اون‌ها نشون دادم. چنین نموداری رو گاهی اینطوری ترسیم می‌کنن:
ولی چرا؟
انواع و اقسام نمودارها وجود داره و تقریبا می‌شه از هرکدوم برای نمایش هر اطلاعاتی استفاده کرد، ولی این به این معنی نیست که خودمون رو مجاز به این کار بدونیم؛ نوع نمودار با دو فاکتور مشخص می‌شه:
نوع اطلاعاتی که قراره ارائه بشه
تصویری که انتظار داریم با دیدن اون اطلاعات در ذهن مخاطب نقش ببنده
نمودارهای خطی نوعی پیوستگی رو به ذهن القا می‌کنن و در نتیجه برای ارائه اطلاعاتی مناسب هستن که جنبه تجمعی داشته باشن. مثلا اگه بخوایم مقدار تجمعی بتن‌ریزی رو نشون بدیم، احتمالا بهترین نمودار همون نمودار خطیه. ولی در مورد مقادیر دوره‌ای اینطور نیست؛ مقادیر دوره‌ای پیوستگی مقادیر تجمعی رو ندارن؛ مقادیر مستقلی هستن که کارکرد دوره‌های مختلف رو نشون می‌دن. با توجه به این مسایل، بهتره که برای این اطلاعات از نمودار میله‌ای استفاده بشه:
این نمودار توزیع بتن‌ریزی دوره‌ها رو به خوبی نشون می‌ده و تصویر نادرستِ وجود “روند” و پیوستگی رو هم در ذهن مخاطب به وجود نمیاره.
گفتم که علاوه بر اطلاعات، ذهنیتی که قصد داریم به وجود بیاد هم اهمیت داره. مثلا فرض کنین می‌خوایم نشون بدیم که از بتن‌ریزی‌های این دوره‌ها، چه سهمی به هر دوره …
فرض کنین تعدادی دوره داریم و برای هرکدوم مقدار پیشرفت دوره‌ای برنامه‌ریزی شده و واقعی. اگه نمودار اون‌ها رو تو اکسل رسم کنین، احتمالا نموداری شبیه شکل زیر دستتون رو می‌گیره:
خیلی‌ها نمودار رو همین شکلی ارائه می‌کنن؛ ولی خیلی حیفه. اگه از من می‌شنوید، هیچوقت نمودارها رو با تنظیم‌های پیش‌فرض اکسل ارائه نکنین.
اولین مرحله اینه که نمودار رو کمی شهودی‌تر کنیم. رنگ‌ها و روشنایی‌ها هرکدوم معنایی دارن که باید از اون‌ها کمک بگیریم. چه دلیلی داره که مقدارهای واقعی قرمز و برنامه‌ریزی شده آبی باشن؟
من دوست دارم اطلاعاتی که ارائه می‌کنم سیاه و سفید باشن، رنگ‌ها رو میذارم برای روز مبادا. مقدارهای برنامه‌ریزی به انتظار ما و به نوعی به رویاهامون ربط دارن، پس خیلی شهودی‌تره که اون‌ها رو کمرنگ‌تر نشون بدیم و مقدارهای واقعی که “واقعیت” هستن رو پر رنگ.
من ترجیح می‌دم به جای این‌که مقدارهای برنامه‌ریزی شده رو کمرنگ کنم، با خاکستری تیره، ولی با شفافیت بالا نشونشون بدم. تو این حالت میله‌ها عملا کمرنگ می‌شن، ولی فرقش اینه که خط‌های راهنما از پشت اون‌ها دیده می‌شن.
راهنمای نمودار هم اگه سمت راست باشه، بی‌دلیل جای زیادی رو اشغال می‌کنه؛ همیشه می‌شه داخل نمودار جایی خالی براش پیدا کرد.
اون توصیه همیشگی هم تو این نمودار رعایت شده: کمرنگ کردن خط‌های راهنما.
خیلی پیش میاد که فاجعه‌ای مثل شکل زیر رو به جای یه جدول ارائه کنن:
چرا این جدول مناسب نیست؟
کادرها هم مثل رنگ‌ها و روشنایی‌ها اهمیت زیادی دارن و باید از اون‌ها به تناسب استفاده کرد. کادرها توجه بیننده رو به خودشون جلب می‌کنن و هرچه زخیم‌تر باشن، توجه بیشتری جلب می‌کنن. برای کارهای معمولی باید از ظریف‌ترین کادرهای ممکن استفاده کرد و کادرهای ضخیم رو محدود به استفاده‌های خاص کرد. گذشته از این موضوع، تعدادِ زیادِ خط‌های ضخیمی که تو این جدول وجود دارن به عددها غلبه می‌کنن و بیننده نمی‌تونه حواسش رو جمعِ دیدن عددها کنه.
جدول زیر تا حدی بهتره:
این جدول بهتره، به این خاطر که از خط‌های ضخیمِ کمتری استفاده کرده. خط‌های بیرونی ضخیم‌ترن (هرچند که هنوز هم زیاد از حد ضخیمن) و توجه بیننده رو به داخل جدول جلب می‌کنن، ولی داخل جدول خط‌ها نازک‌تر هستن و باعث می‌شه که اعداد بهتر دیده بشن.
ولی چه دلیلی داره که از این همه خط توی جدول استفاده کنیم؟
اگه ردیف‌ها خط نداشته باشن معمولا بیننده نمی‌تونه ترتیب و ساختار جدول رو به خوبی ببینه، ولی ستون‌ها معمولا اینطوری نیستن. به این خاطره که معمولا می‌تونیم برای مجزا کردن ستون‌ها از خط استفاده نکنیم و به این ترتیب جدول با کادرهای بسته تشکیل نمی‌شه و ذهن رو کمتر به خودش جلب می‌کنه. تو این شرایط می‌تونیم از عنصرِ قویِ کادر برای متمایز کردن اطلاعات حساس استفاده …
تو کارهامون نمودارهایی شبیه نمودار زیر رو زیاد می‌بینیم:
به نظرتون نمودار بدی نیست؟ بهتر نیست نمودار به صورت زیر ارائه بشه؟
نمودار اول دو مشکل داره:
فاصله بین خط‌های راهنمای افقی خیلی کمه. این خط‌ها قراره راهنمایی باشن برای این‌که بشه ارتفاع میله‌ها رو با هم مقایسه کرد، ولی اگه تعدادشون زیاد باشه نه تنها راهنمایی نمی‌کنن، که خوانایی نمودار رو هم کم می‌کنن. همیشه باید فاصله مناسبی رو برای خطوط در نظر بگیرین و تو اکسل وارد کنین.
رنگ‌ها اهمیت زیادی دارن، خیلی زیاد. هر رنگ و هر مقدار روشنایی از هر رنگ، به اندازه‌ای جلب توجه می‌کنه. هرچی عنصر پر رنگ‌تر باشه، بیشتر جلب توجه می‌کنه. این مسئله باید متناسب با عناصر نمایشی باشه. هر عنصری که اهمیت بیشتری داره باید با رنگی نمایش داده بشه که بیشتر جلب توجه می‌کنه. خط‌های راهنما اهمیتی کمتر از میله‌ها دارن، پس باید کمرنگ‌تر باشن. تو نمودار اول خط‌ها مشکی هستن، به همین خاطر توجه رو به خودشون جلب می‌کنن و بیننده نمی‌تونه به راحتی با نمودار ارتباط برقرار کنه. خط‌های راهنمای نمودار دوم از نظر میزان جلب توجه در حدی مناسب خودشون قرار گرفتن.
می‌خوام بعد از این مطالبی در مورد شیوه‌های ارائه اطلاعات بنویسم، و این مجموعه مطالب رو با این پست شروع می‌کنم.
به نمودار زیر نگاه کنین:
به نظرتون نمودار چه اشکالی داره؟
هر نمودار تصویری از اطلاعات ارائه می‌کنه و این نمودار هم نسبتی بین این سه مقدار رو تو ذهن تصویر می‌کنه. آیا این نسبت درسته؟ مثلا به نظر میاد که B بیشتر از دو برابر A باشه، ولی آیا همینطوره؟
نه، اینطور نیست. حداقل مقدار محور عمودی صفر نیست، 110 حداقل مقداره. به این خاطره که نسبت‌ها تو نمودار به هم خوردن. نمودار صحیح تو شکل زیر نشون داده شده:
محور عمودی این نمودار از صفر شروع شده و به همین خاطر نسبت اطلاعات رو به درستی نشون می‌ده. نمودار اول غلط نیست، ولی به شدت گمراه کنندس؛ اطلاعات ارائه شده نباید گمراه کننده باشن.
این رو دارم می‌نویسم، چون خیلی‌ها در موردش اشتباه می‌کنن.
فرض کنین پروژه‌ای صد روزه باشه، پیشرفت برنامه‌ریزی شده صد درصد باشه و 80٪ پیشرفت واقعی کرده باشیم. مقدار تاخیر چقدره؟ خیلی‌ها به این سوال جواب می‌دن که 20 روز. چنین جوابی اصلا درست نیست؛ در واقع هیچ رابطه مستقیم و ساده‌ای بین انحراف پیشرفت و تاخیر وجود نداره.
ممکنه پیشرفت واقعی بیشتر از برنامه‌ریزی باشه، ولی تاخیر داشته باشیم. این اتفاق زمانی می‌افته که فعالیت‌های بحرانی انجام نشده باشن، ولی مقدار زیادی از فعالیت‌های غیر بحرانی انجام شده باشن. معنیش هم اینه که وضعیت پروژه خوب نیست، چون انجام نشدن فعالیت‌های بحرانی باعث می‌شه که جبهه‌های کاری بسته بشه و به تدریج پیشرفت واقعی هم از پیشرفت برنامه‌ریزی شده عقب بیفته.
ممکنه پیشرفت واقعی کمتر از پیشرفت برنامه‌ریزی شده باشه، ولی تاخیری به وجود نیومده باشه. این ترکیب زمانی اتفاق می‌افته که تمام فعالیت‌های بحرانی انجام شده باشن، ولی مقداری از فعالیت‌های غیر بحرانی طبق برنامه پیش نرفته باشن. البته وقتی فعالیتی، هرچند غیر بحرانی، مقدار زیادی به تاخیر بیفته، احتمال بحرانی شدنش زیاده؛ به همین خاطر این حالت زیاد اتفاق نمی‌افته، مگر این‌که منطق اجرایی طور عجیبی باشه یا برنامه خیلی بد نوشته شده باشه.
شکل زیر این حالت رو نشون می‌ده:
فرض کنین در زمانی که خط عمودی قرمز رنگ نشون می‌ده …
یه مقدار در مورد محاسبه پیشرفت برنامه‌ریزی شده مشکل وجود داره و می‌خوام تو این نوشته یه توضیح کوچیک در موردش بدم. در دو حالت با مقادیر برنامه‌ریزی شده پیشرفت سر و کار داریم:
مقدار تجمعی پیشرفت برنامه‌ریزی شده: وقتی می‌خوایم بگیم پروژه مثلا 45 درصد پیشرفت کرده، در حالی که برنامه‌ریزی شده بوده که 50 درصد پیشرفت کنه. این حالت رو باید همونجوری که همه بلدن حساب کرد و می‌شه بعد از پایان برنامه‌ریزی مقادیر تجمعی پیشرفت برنامه‌ریزی شده رو تا پایان پروژه محاسبه کرد.
مقدار دوره‌ای پیشرفت برنامه‌ریزی شده: مثلا وقتی می‌خوایم بگیم این ماه 4 درصد پیشرفت کردیم، در حالی که برنامه‌ریزی شده بوده که 5 درصد پیشرفت کنیم.
خیلی‌ها دومی رو هم با روش اولی محاسبه می‌کنن، ولی من اصلا با این کار موافق نیستم. مثلا فرض کنین سرعت کار حدودا نصف بوده و به جای این‌که حدود 90 درصد پیشرفت داشته باشیم، 45 درصد پیشرفت کردیم. تو این حالت اگه پیشرفت برنامه‌ریزی شده دوره‌ای رو از مقدارهایی ساده‌ای که برای مورد اول محاسبه کردیم به دست بیاریم، پیشرفت برنامه‌ریزی شده برای دوره‌ای در آینده پروژه که اتفاقا نزدیک به پایان پروژه هست و مقدارها هم افت کردن به دست میاد که هیچ معنایی نداره و بی دلیل وضع پروژه رو خوب نشون می‌ده.
یه مثال دیگه براتون می‌زنم. فرض کنین پروژه بلوک‌های مختلفی داره و می‌خواین اطلاعات پیشرفت اون‌ها رو به …
دیروز انتشارات دیباگران به مناسبت انتشار هزار و صدمین کتابش، جشنواره‌ای برای تجلیل از مولفان و مترجمان برگزار کرد. تو این جشنواره، از هر موضوعی، یک یا چند مولف/مترجم به عنوان افراد برگزیده انتخاب شدن و بهشون لوح و سکه هدیه شد. به من هم لطف داشتن و تو گروه “کامپیوتر و IT” انتخابم کردن.
از این تریبون از تمام همکاران دیباگران، که فکر نمی‌کنم این مطلب رو بخونن، تشکر می‌کنم. کلا مجموعه خوبیه و همکاری باهاشون لذت‌بخشه.
کتاب راهنمای جامع برنامه‌نویسی VBA در پراجکت چاپ شد. بعد از صفحه‌بندی شد 422 صفحه.
لینک بالا صفحه این کتاب رو تو سایت ناشر باز می‌کنه. فهرست مطالب و بقیه مشخصات اونجا هست.
کسایی که بخوان کتاب رو تهیه کنن علاوه بر کتاب‌فروشی‌ها، می‌تونن از سایت دیباگران هم خرید کنن. ظاهرا سیستم کامل و بی‌دردسری برای فروش دارن؛ حالا اگه آزمایش کردین نتیجش رو به من هم بگین.
کتاب اتوکد 2009 تموم شد و فرستادمش برای ناشر. کتاب حدود 1100 صفحه شد.
همونطوری که گفتم، این کتاب به‌روز شده اتوکد 2007 خودم هست. اون کتاب دو جلدی بود و هر دو جلدش با کمی فاصله چاپ دوم هم شدن. این بار دو جلد رو تو یه جلد ترکیب کردم. کار به‌روز کردن کتاب خیلی بیشتر از اونی که انتظار داشتم ازم کار برد، چون اینترفیس نرم‌افزار عوض شده بود و عملا می‌بایست تمام شکل‌ها رو جایگزین کنم (کتاب 2044 شکل داره که یا شکل‌های شماره‌دار، یا شکل‌های داخل متن هستن). از طرف دیگه، دلم نمیومد که فقط قابلیت‌های جدید رو به نرم‌افزار اضافه کنم؛ بعضی جاها که به نظرم میومد قبلا به اندازه کافی توضیح ندادم رو اضافه کردم. چند جا هم احساس کردم زیاد از حد توضیح دادم (از اون مدلایی که می‌گن به خواننده بی احترامی شده)، توضیحاتشون رو کم کردم. در نهایت ساختار کتاب رو هم کامل عوض کردم. فصل‌ها جابجا شدن، بعضی فصل‌ها خورد شدن و بعضی‌های دیگه با هم ترکیب شدن. الان به نظرم ساختار کتاب خیلی منطقی‌تر و کاربردی‌تره. مشکل اصلی این بود که برای نسخه 2007 اول جلد یک رو تهیه کردم و دادم به انتشارات و بعد رفتم سر جلد دو، تا کار زودتر به بازار بره. وقتی جلد دو رو تموم کردم، اولی چاپ شده بود. به این خاطر امکانش رو نداشتم که چیزی رو بین این دو جلد با هم هماهنگ کنم.
به هر حال… کتاب بعدی پریماورا 6 هست. فعلا قرارداد رو نبستم و کار رو هم …
امروز می‌بایست یه برنامه رو خیلی سریع بنویسم. وقتی داشتم روابط رو وارد می‌کردم، که می‌دونین چقدر تکراریه و حتا با ترفندهای مختلفی که سرعت انجام این کار رو زیاد می‌کنن باز هم به اندازه کافی زیاد نمی‌شه، به این فکر افتادم که یه برنامه برای پراجکت بنویسم که با یه ترتیبی قاعده دریافت کنه و روابط رو بر اساس اون قواعد بسازه. هر وقت هم قواعد تغییر کنن، روابط رو بازسازی کنه.
مثلا فرض کنین تو پروژه‌ای خاص تعدادی از قواعد این‌ها باشن:
کانال کشی هر ناحیه، بعد از لوله کشی فاضلابش انجام می‌شه.
لوله کشی آب بعد از کانال کشی انجام می‌شه.
لوله کشی گاز، بعد از لوله کشی آب انجام می‌شه.
و روابط دیگه‌ای از این نوع. حالا کافیه چنتا فیلد داشته باشیم که یکیشون ناحیه‌ها رو مشخص کنه و یکی دیگه نوع فعالیت رو. می‌شه یه فیلد سوم هم در نظر گرفت که استثناها رو مشخص کنه. مثلا روابطی که گفتم ممکنه تو ناحیه موتورخونه برقرار نباشه، در این حالت می‌شه استثنا بودن رو تو فیلد سوم مشخص کرد تا قاعده به اون‌ها اعمال نشه.
منظورم اینه که منابع روی زمان بندی تاثیر بذارن. من یه طرفدار شدید این شیوه برنامه‌ریزیم. تو این روش فقط روابط اجتناب ناپذیر توی برنامه تعریف می‌شن (مثلا گچ و خاک بعد از سفت کاری باید انجام بشه، چون سفت کاری اگه نشده باشه چیزی نیست که روش گچ و خاک بشه)، و روابطی که نشون دهنده سلسله مراتب کاری باشن، وارد نمی‌شن (مثلا گچ و خاک این طبقه بعد از طبقه بالا یا پایینش). در عوض منابعی قابل تسطیح برای فعالیت‌های مشابه تعریف می‌شه و در صورت لزوم اولویت‌های اون‌ها هم مشخص می‌شه و بعد از این‌که منابع رو تسطیح کنیم، سلسله مراتبی که لازم داشتم به وجود میاد.
امتیاز بزرگ این روش اینه که برنامه خیلی انعطاف پذیر می‌شه. مثلا خیلی راحت می‌شه تعداد اکیپ‌ها رو کم و زیاد کرد و برنامه را تسطیح کرد تا تاثیرش رو دید؛ در حالی که تغییر تعداد اکیپ تو حالتی که از روابط برای پیاده کردن اون‌ها استفاده شده باشه یه فاجعه تمام عیاره.
با وجود تمام امتیازهای این روش که واقعا الان وقتش رو ندارم که بیشتر از این بنویسم چون همین الان باید برگردم سر برنامه‌ای که دارم تهیه می‌کنم که فردا تموم شده باشه، یه نقطه ضعف خیلی بزرگ هم وجود داره:
تو این حالت برنامه‌ریزی، هیچ راهی برای پیدا کردن عناصری که به زمان‌بندی حاکم شدن وجود نداره. مثلا وقتی از روابط استفاده شده باشه، یه مسیر بحرانی هست که آدم با اون می‌تونه زمان رو کم و زیاد …
یکی از ویژگی‌های مهم کاری من تو این هشت سالی که مشغول هستم، اینه که تو شرکت‌های متعددی کار کردم. معمولا همزمان تو سه شرکت کار می‌کنم و تا الان با هفت شرکت مختلف کار کردم، که یکیشون هم عملا دو اکیپ کاملا متفاوت از یه شرکت بوده که می‌شه مشابه هشت شرکت. بین این‌ها، همکاری یک ساله تا پنج ساله رو تجربه کردم.
تو این مدت یه چیزی که کاملا متوجه شدم، اینه که طرز برخورد سازمان با افراد، طوریه که بعضی از شرکت‌ها در پرسنلشون حس دلسوزی ایجاد می‌کنن و بعضی دیگه نه. خود من در مقابل شرکت‌های مختلفی که باهاشون همکاری می‌کنم حس‌های مختلفی دارم. در مورد بعضیشون اگه مشکلی پیش بیاد، واقعا ناراحت می‌شم، طوری که انگار مشکل برای خود من پیش اومده (در حالی که اون مشکل تاثیر مستقیمی برای من نداره)، در حالی که بعضی‌های دیگه اگه دچار مشکل بشن، ناراحت نمی‌شم و حتا ممکنه با خودم بگم “به درک”.
خیلی به این فکر کردم که چه چیزی می‌تونه اینطور جبهه‌گیری رو به وجود بیاره. جدیدا به این نتیجه رسیدم که سازمان شرکت حرف اول رو نمی‌زنه، بلکه مدیریت اونه. یکی از شرکت‌هایی که واقعا براش دل می‌سوزونم، اصلا سازماندهی خوبی نداره و به این خاطر مشکلات خیلی زیادی پیدا می‌کنم؛ ولی، چون مدیرش آدم بسیار محترم، دلسوز، خوشفکر و قدرشناسیه، چنین حسی رو در من به وجود آورده. در عین حال، شرکت دیگه‌ای هست که سازماندهی خیلی بهتری داره، ولی …
این کتاب هم چاپ شد. از نظر من مکمل جلدهای اول و دوم راهنمای جامع اتوکد هست که چند وقت پیش چاپ شده بود و الان جلد اولش چاپ دوم هم شده.
کتاب کلا یه ورک شاپ (کارگاه؟) هست. اولش کمی تمرین‌های کاربردی گذشتم که بعضی تکنیک‌های مهم رو توضیح می‌ده و بعد از اون ورک شاپ اصلی شروع می‌شه. هدف این ورک شاپ، تهیه کل نقشه‌های معماری، تاسیسات مکانیکی و تاسیسات برقی یه تیپ واحد کوچیکه، که از اولین قدم شروع می‌شه و تمام مسایلی که می‌تونه پیش بیاد رو توضیح می‌ده. نوشتن این کتاب باعث شد که برای اولین بار تو عمرم یه سری نقشه ساختمانی رو به طور کامل بکشم!
حساسیت اصلی من در مورد این کتاب، تصاویرش بود، که هم من و هم بقیه زحمت خیلی زیادی براش کشیدیم. هنوز کتاب رو ندیدم… امیدوارم تصاویر اون طوری باشه که دلم می‌خواست.
