تا حالا فکر کنم چند بار به آداب ایمیل نوشتن اشاره کردم. این بار میخوام یه قاعده مهم رو طرح کنم و توصیه کنم که تا جای ممکن رعایتش کنین:
هر «یک» ایمیل کاری باید فقط و فقط «یک» موضوع رو مطرح کنه و این موضوع تو عنوان ایمیل هم بیاد. در نتیجه اگه مثلا میخواین درباره سه موضوع مختلف با کسی صحبت کنین، به جای اینکه اونها رو دنبال هم تو یه ایمیل بنویسین، براشون سه ایمیل مختلف تنظیم کنین.
این کار به نظر شما چه فایدهای داره؟
روی همه موضوعها به اندازه کافی تاکید میشه. خیلی وقتها که چند موضوع تو یه ایمیل هستن توجه خواننده میره به مهمترین موضوع و اونهای دیگه روند خوبی رو طی نمیکنن.
بعدا اگه اون آدم بخواد بگرده و ایمیلی قدیمی رو پیدا کنه کار براش خیلی راحتتر میشه.
وقتی قراره یه پرزنتیشن پاورپوینت تهیه کنین چیکار میکنین؟
احتمالا میشینین پای کامپیوتر، پاورپوینت رو اجرا میکنین و شروع میکنین به تهیه اسلایدها. این کار زیاد جالب نیست.
همیشه قبل از اینکه شروع کنین به تهیه پرزنتیشن باید وقت زیادی رو صرف برنامهریزیش کنین، همونطوری که یه پروژه رو برنامهریزی میکنیم. برنامهریزی یه پرزنتیشن میتونه جواب به همچین سوالهایی باشه:
مخاطب کیه؟
هدف این پرزنتیشن چیه؟
پیام اصلی چیه؟
ساختار مطالب و محتوایی که میخوام ارائه کنم چیه؟
۱. مخاطب
هر مخاطب ویژگیهای خودش رو داره. مثلا فرض کنین قراره یه تکنیک جدید زمانبندی رو پرزنت کنین. اگه مخاطب شما مدیران ارشد شرکتها باشن، باید در مورد مفاهیم کلی اون تکنیک صحبت کنین و اگه مخاطبتون متخصصهای برنامهریزی هستن باید بیشتر بریم سراغ محاسبات.
همیشه باید مخاطبمون رو بشناسیم و درک کنیم که چه جنبهای از موضوع براش مهمتر، جالبتر و قابل درکه.
۲. هدف
اصلا چرا میخوایم چنین پرزنتیشنی ارائه کنیم؟ برای من عجیبه، ولی خیلیها اصلا به این فکر نمیکنن. هدفمون اینه که حمایت مخاطب رو جلب کنیم؟ هدف اینه که اطلاعاتشون رو بیشتر کنیم؟ هدف اینه که…
هدف به محتوا شکل میده و اگه هدف رو خوب درک و تعریف نکرده باشین محتوای چندان مناسبی هم به وجود نمیاد.
۳. پیام
آیا میتونین کل محتوای پرزنتیشن رو تو یکی دو جمله خلاصه کنین؟ اون میشه …
ویرایش جدید کتاب راهنمای فرمولنویسی در اکسل که چهار سال پیش چاپ شده بود رو تهیه کردم و در آینده نه چندان دور چاپ میشه. نسخه الکترونیکیش هم مطابق معمول از همین الان قابل تهیهس.
کتاب خیلی سادهس و عمدتا برای کسایی تهیه شده که آشنایی چندانی با فرمولنویسی اکسل ندارن و میخوان خیلی سریع و راحت اون رو یاد بگیرن. با این حال به تدریج که تو کتاب جلو میریم مهارتهایی آموزش داده میشه و خصوصا ترفندهایی مرور میشه که میتونه برای خیلی از کاربران اکسل مفید باشه.
قسمت عمده مطالب کتاب هم از طریق مثالهای کاربردی هدفدار آموزش داده میشن.
بهروزرسانی: الان که بعد از هفت سال داشتم سری به مطلبهای قدیمی سایت میزدم که لینکهای از کار افتاده و مطالب منقضی شده رو پاکسازی کنم چشمم به این مطلب خورد. برای کسایی که الان اون رو میخونین ممکنه جالب باشه که بدونین فعالیت موثر در لینکدین همه جنبههای زندگی من رو طی این سالها عوض کرد؛ از شریک کاری تا محل زندگی و مشارکت در پروژههای بینالمللی. بگذریم، مطلب اصلی در ادامه میاد:
نمیدونم LinkedIn رو چقدر میشناسین؛ مهمترین شبکه اجتماعی متمرکز بر مسایل حرفهای. همون نقشی که فیسبوک تو دوستیها و سرگرمیها داره، LinkedIn تو دنیای کسب و کار داره. پس اگه عضوش نیستین یا فعالیتی نمیکنین پیشنهاد میکنم همین الان این کار رو شروع کنین. خود من تا حالا تمام کارهایی که از کشورهای به جز ایران گرفتم رو مدیون LinkedIn هستم.
به هر حال، الان دارم این مطلب رو مینویسم چون دیدم که خیلی از کسایی که تو شبکه من هستن بعضی مسایل حرفهای رو تو این شبکه حرفهای رعایت نمیکنن. پس چیزایی که به نظرم میرسه رو باهاتون در میون میذارم:
عکس
دو جور عکس برای LinkedIn مناسبه: یکی عکس آتلیهای و دومی عکسی که تو محیط کاریتون گرفته باشین. پس مثلا اگه یه عکس پای برج ایفل، در آغوش پارتنر یا در کنار دوستانتون گرفتین، نگهش دارین برای فیسبوک و یه عکس حرفهای برای LinkedIn بگیرین.
روند پذیرفته شده برای بررسی توجیهپذیری پروژه چنین چیزیه:
اولین کار اینه که توجیهپذیری پروژه رو خیلی کلی و ساده بررسی کنیم؛ مثلا تو یه هفته. این اطلاعات رو همراه با خیلی چیزهای دیگه تو پیشنویس منشور پروژه میذاریم.
منشور پروژه بررسی میشه و اگه تایید بشه پروژه رسما شروع میشه.
بعد از شروع پروژه خیلی دقیق و کامل توجیهپذیری پروژه رو مطالعه میکنیم و تمام برنامهریزیهای پروژه (زمانبندی، برنامهریزی هزینه، ریسکها، تدارکات و …) رو هم انجام میدیم. دلیلش اینه که هیچوقت نمیشه یه توجیهپذیری دقیق تهیه کرد، مگر اینکه پروژه برنامهریزی شده باشه.
توجیهپذیری پروژه همراه با برنامهها بررسی میشن و تصمیم میگیریم که کار اجرایی پروژه رو شروع کنیم یا نه.
این ترکیب رو میشه با چرخه حیاتهای مختلف پیادهسازی کرد. مثلا میشه کار اجرایی و مطالعات تو دو پروژه متفاوت باشن، میتونن دو فاز از یه پروژه باشن، یا حتی دو مرحله از یه پروژه خیلی ساده؛ ولی به هر حال بهتره روندی که گفته شد تو چرخه حیات وجود داشته باشه.
دلیل اینکه مطالعه توجیهپذیری رو دو قسمت میکنیم اینه که مطالعه دقیق توجیهپذیری کار پر هزینهایه. به جای اینکه هر ایدهای به نظرمون میرسه دو سه ماه براش وقت بذاریم ببینیم بهتره انجامش بدیم یا نه، برای هر کدوم مثلا یه هفته وقت میذاریم، اگه نتیجه اون یه هفته مثبت بود اونوقت مطالعه …
یه پروژه کوچیک رو فرض کنین؛ مثلا قراره تو شرکت یه نرمافزار مدیریت اسناد راهاندازی کنین. ماجرا اینه که مدیر عامل و مدیرای ارشد شرکت جلسهای دارن و دارن به این فکر میکنن که این کار رو انجام بدن یا نه. در نهایت دستهجمعی به این نتیجه میرسن که این کار به نفع شرکته و بهتره انجام بشه. مدیر عامل از مدیرهای ارشد شرکت میپرسه که چه کسی حاضره مسئولیت این کار رو به عهده بگیره و یکی از اونها این مسئولیت رو قبول میکنه. اون مدیر ارشد و مدیر عامل بلند میشن، با هم دست میدن و مدیر عامل ضمن اینکه ازش تشکر میکنه براش آرزوی موفقیت هم میکنه.
الان اینجا چه اتفاقهایی افتاد؟
اول اینکه پروژه به عهده یه مدیر ارشد گذاشته شد. این به این معنی نیست که اون آدم مدیر پروژه میشه؛ نه، اون میشه مالک پروژه. دلیلش هم اینه که هر پروژهای نیاز نفوذ و قدرت یه مدیر ارشد داره. تو پمباک به این آدم میگن Sponsor (حامی پروژه) و تو پرینس۲ بهش میگن Executive.
اون جایی که تو جلسه بحث نرمافزار پیش کشیده شد و بررسی پروژه رو شروع کردن هم میشه project mandate (جرقه پروژه).
مرحله بعدی اینه که اون مدیر ارشد باید مدیر پروژه انتخاب کنه. مثلا میره با مسئول واحد IT، مسئول واحد کنترل پروژه، مسئول دبیرخونه یا کس دیگهای صحبت میکنه و توافق میکنن. از حالا به بعد اون آدم میشه مدیر پروژه.
قبل از هر چیز باید تجربه به دست بیارین، تجربه دقیق، هدایت شده، واقعی و موثر. حالا چطوری میشه کسی که مدیر پروژه نیست تجربه مدیریت پروژه به دست بیاره؟ خیلی سادهس، با به عهده گرفتن کارهایی که به مدیریت پروژه نزدیکن، همکاری موثر با مدیر پروژه، به عهده گرفتن مسئولیت، دقیق شدن تو کارها و تصمیمها و حرفای مدیر پروژهها و پیگیری و تحلیل کردن اونها.
بعضی شغلهایی که میتونین داشته باشین تا مدیریت پروژه رو به خوبی درک کنین اینها هستن:
برنامهریزی و کنترل پروژه – برنامهریزی و کنترل پروژه جزئی از مدیریت پروژهس و کسی که این مسئولیت رو داره باید خیلی به مدیر پروژه نزدیک باشه. البته متاسفانه چون خیلی وقتها سیستمهای برنامهریزی و کنترل پروژه تو ایران صوری هستن و کار موثری انجام نمیدن، ارتباط کافی هم با مدیر پروژه ندارن. پس اگه میخواین از طریق این کار تجربه مدیریت پروژه به دست بیارین حتما مطمئن بشین که امکانش رو دارین که ارتباط کافی برقرار کنین. بعضی وقتها این …
وقتی برنامه جبرانی تهیه میکنیم چه اتفاقی برای ارزیابی عملکرد میافته؟
قبل از جواب دادن به این سوال باید به سوال خیلی مهمترین جواب داد: اصلا چرا برنامه جبرانی تهیه میکنیم؟
ماجرا اینه که تو هر پروژه باید به نوعی حدود رواداری در نظر گرفت. مثلا پروژه (یا مرحلهای از پروژه) قراره تو شش ماه با حداکثر سه هفته رواداری تموم بشه، با هزار تومن هزینه و رواداری صد تومن. این میشه سادهترین حالت تعریف بودجه و رواداری پروژه (بودجه هم به پولی گفته میشه که برای اون کار کنار گذاشته شده و هم زمانی که براش در نظر گرفته شده). حالا وقتی کار داره پیش میره دایما تاریخ پایان پروژه (یا مرحله) و هزینه تخمینی زمان پایان اون رو محاسبه میکنیم و اگه اون حدود رواداری رو رد کنه، وقت تهیه برنامه جبرانی میشه که اصلاحا به اون رویداد میگیم exception. تو این حالت قرار نیست یه برنامهریز تک و تنها بره بشینه تو اتاق، در رو ببنده و با زمانها و روابط بازی کنه تا برنامه فشرده بشه؛ اتفاقی که میافته اینه که فهمیدیم با سیاستهای اجرایی برنامهریزی شده نمیتونیم به هدفهای تعریف شده برسیم و در نتیجه باید دوباره تیم پروژه جمع بشن (مثل روز اولی که همه با هم برنامه رو تهیه کردن) راه حلی پیدا کنن؛ یه روش جدید کار کردن که بتونه ما را به هدفهامون برسونه، تجدید نظری تو هدفها یا هر چیز دیگه. نیروهای برنامهریز به نمایندگی …
ماکس پلانک بعد از اینکه جایزه نوبل رو تو سال ۱۹۱۸ میگیره یه تور دور آلمان میذاره و تو شهرهای مختلف درباره کوانتوم مکانیک صحبت میکنه. چون هر دفعه دقیقا یه محتوا رو ارائه میکرده، دیگه رانندهش کاملا اونها رو حفظ شده بود. یه بار رانندهش بهش میگه که «شما از تکرار این حرفها خسته نمیشین؟ من الان دیگه به حدی حفظ شدمشون که میتونم به جای شما ارائه کنم. اصلا بیاین تو مقصد بعدی که مونیخه من سخنرانی کنم و شما لباس من رو بپوشین و بشینین تو جلسه؛ برای هردومون تنوع میشه». پلانک هم قبول میکنه!
شوفر خیلی خوب تو جلسه درباره کوانتوم مکانیک صحبت میکنه و شوندهها هم خیلی لذت میبرن. ولی آخرش یه فیزیکدان بلند میشه و سوال میپرسه. شوفر هم در نهایت خونسردی میگه «من تعجب میکنم که تو شهری پیشرفته مثل مونیخ سوالهایی به این اندازه ساده میپرسن که حتی شوفر من هم میتونه جواب بده! شوفر عزیز، شما به ایشون جواب بدین».
بر اساس همین داستان اسم اثر خاصی رو گذاشتن «اثر شوفر»؛ جایی که متخصص واقعی و مجری غیر متخصص جابجا میشن. به نظر اکثر آدمها مجریهای (منظور مفهوم کلی مجریه، نه مجری تلویزیون) غیر متخصصی که مثل اون شوفر فقط چیزهایی رو حفظ هستن متخصصتر میان تا اونهایی که واقعا متخصص هستن، چون یه متخصص واقعی به خودش اجازه نمیده در مورد هر چیزی با قطعیت اظهار نظر کنه، در حالی که مجری در مورد همه …
بعضی از اصطلاحات مدیریت پروژه تو بازههای خاصی مد میشن. مثلا تو سالهای گذشته PMBOK بیشتر از هر چیزی به گوشمون میخورد. الان حقیقتا هیچ چیزی از نظر مد بودن به پای PMO نمیرسه. نکته جالب هم اینه که این ماجرا به ایران محدود نمیشه و عملا یه مد جهانیه. به همین خاطر میخوام تو این مطلب توضیحهای خلاصه ولی جامع در مورد این مفهوم بدم.
ترکیب عبارت
PMO میتونه مخفف یکی از این عبارتها باشه:
Project Management Office
Program Management Office
Portfolio Management Office
و این سهتا انقدر شباهت دارن که عملا تو یه سرفصل بررسی بشن و به همین خاطره که مهمترین استانداردی که در مورد PMOها هست اسمش P3O گذشته شده که مخفف این عبارته:
Portfolio, Programme, and Project Offices
و این استانداردیه که ما عملا برای پیادهسازی PMOها استفاده میکنیم.
مفهوم عبارت
PMO تعریف خاص و روشنی نداره. به یه دفتری میگن که معمولا به چند پروژه سرویس میده و این سرویسها برای همسانسازی و استاندارد کردن فعالیتهای مدیریت پروژهس. با این حال یه کم جلوتر با هم میبینیم که تنوع فعالیتها خیلی بیشتر از این هم میتونه باشه.
در هر حال باید در نظر داشته باشین که معنیدار ترین حالت یه PMO وقتیه که به چندین پروژه سرویس بده (نه یه پروژه) و هدفش هم تعالی مدیریت پروژه باشه. شاید میدونین که تکرارپذیر کردن فرآیندهای مدیریت پروژه …
تولید تو کارخانه از مثالهای رایج برای «عملیاته»، چیزی که پروژه نیست و قرار نیست از ابزارهای مدیریت پروژه براش استفاده بشه. ولی اوضاع برای بعضی تولیدهای مبتنی بر سفارش یه کم پیچیده میشه.
به نظر من اگه سفارشی که کارخونه میگیره صرفا به معنی نوعی پیشخرید برای تولید محصول روتین کارخونه باشه، باید عملیات در نظر گرفته بشه. اگه این سفارش منجر به نوعی طراحی و تولید اختصاصی میشه که البته در عین حال درجهای از روتین بودن رو هم حفظ میکنه، ماجرا جایی بین پروژه و عملیات قرار میگیره. تو این حالت تصمیمگیری در مورد ماهیت کار زیاد ساده نیست و حتما باید عوامل مختلفی رو در نظر گرفت. حتی شاید لازم باشه برعکس عمل کنیم، یعنی ببینیم که روشها و ابزارهای مدیریت پروژه برای اون کار موثرتره یا عملیات و بر اون اساس روی کار برچسب پروژه یا عملیات بزنیم. من خودم تو اکثر موارد توصیه میکنم که کار عملیات دونسته بشه.
اگه این نوع کارها رو پروژه دونستین هم حتما در نظر داشته باشین که سیستم مدیریت پروژهای که براش اختصاصیسازی (tailor) میکنین حتما باید خیلی ساده باشه.
در نهایت آخرین نکتهای هم که وجود داره اینه که توجه داشته باشیم تمایز بین عملیات و پروژه معمولا تو سیستمهای کلاسیک اهمیت داره و خیلی از متودها مثل بعضی از متودهای چابک هم برای پروژه و هم برای عملیات قابل استفاده هستن. در نتیجه اگه گرایش به اون …
کتاب «راهنمای جامع برنامهریزی و کنترل پروژه با Primavera P6» که چهار سال پیش برای نسخه ۶ نرمافزار تهیه و منتشر شده بود رو برای نسخه 8.3 بهروزرسانی کردم و نسخه الکترونیکیش رو میتونین از این آدرس تهیه کنین.
این کتاب مشابه نسخه قبلیش حالت مرجع داره و نه خودآموز. محتوای کلی هم مثل قبله و فقط تغییرات نرمافزار توش منعکس شده. در نتیجه اگه نسخه قبلی رو داشته باشین نیازی نیست که دوباره تهیهش کنین؛ البته مگر اینکه الکترونیکی بودنش رو ترجیح بدین.
نسخه چاپی کتاب هم تا چهار پنج ماه دیگه منتشر میشه.
همونطوری که میدونین یکی از موسسههای غیرانتفاعی مدیریت پروژه IPMA هست. این موسسه بیشتر گرایش اروپایی داره، ولی تو کل دنیا فعاله؛ البته دستاندرکارای مدیریت پروژه زیاد نمیشناسنش.
به هر حال این موسسه تو ایران هم رسما فعالیت میکنه و آزمونهای موسسه رو هم برگزار میکنه.
چهار گواهی تعریف شده، IPMA-D و IPMA-C و IPMA-B و IPMA-A، که به ترتیب حرفهایتر میشن. سادهترین آزمونها که سطح C و D هستن قراره پنجشنبه ۲۸ شهریور ۱۳۹۲ تو ایران برگزار بشن. آزمون به زبان فارسی برگزار میشه.
اگه علاقهمند بودین میتونین به سایت انجمن مدیریت پروژه ایران مراجعه کنین و اطلاعات تکمیلی رو پیدا کنین و اگه مایل بودین ثبت نام هم بکنین.
استاندارد انجمن که ICB هست رو هم میتونین به رایگان از سایت دریافت کنین. البته سوالهای آزمون محدود به ICB نمیشه و باید خیلی چیزهای دیگه هم مطالعه کنین. علاوه بر اون نمونه سوال هم هست که میتونه خیلی به دردتون بخوره.
کلا دو روش برای بحرانی به حساب آوردن فعالیتها و در نتیجه تعیین «مسیر بحرانی»، یعنی مجموعه فعالیتهای بحرانی – که از قدیم علاقه داشتیم تو یه مسیر باشن – وجود داره:
بر اساس حداکثر شناوری کل فعالیتها
بر اساس قرار گرفتن روی طولانیترین مسیر
روش اول برای اکثر افراد آشناتره و معمولا جاهایی که تئوری CPM رو توضیح میدن از همین روش استفاده میکنن. تو این روش زودترین و دیرترین تاریخهای شروع و پایان هر فعالیت تو دو مرحله رفت و برگشت محاسبه میشه و تفاضل زودترین و دیرترین تاریخها دو مقدار شناوری شروع و شناوری پایان رو به وجود میاره. نرمافزارهای مختلف یا یکی از این دوتا رو شناوری کل میشناسن، یا حداقل اونها رو، یا حتی انتخاب اون رو به شما بدن؛ البته این دو مقدار تو حالتهای معمولی با هم برابر هستن. حالا حدی برای اونها در نظر گرفته میشه و هر فعالیتی که شناوری کلش از اون مقدار بیشتر نباشه بحرانی به حساب میاد.
شناوری کل فعالیتها تو برنامهای که آزاد باشه از صفر کمتر نمیشه و این فرض تو حالتهای قدیمی که تو تئوریها توضیح داده میشه هم وجود داره. برای همین رسم بر این بوده که شناوری صفر بحرانی به حساب بیاد. حالا تو پروژههایی که مدت زمانشون زیاد باشه و مدت زمان فعالیتهاشون هم خیلی کم نباشه، شناوریهایی مثل یک روز چندان با صفر فرق نمیکنه. به همین خاطر این گزینه هم وجود داره که حداکثر …
خیلیها در مورد امتیاز قبولی تو آزمون PMP سوال دارن. ماجرا اینه که امتیاز قبولی یه زمانی ۶۲٪ بود، خیلی ساده و سرراست. ولی الان مدت زیادیه که دیگه امتیاز مشخص و سادهای برای قبولی تو آزمون وجود نداره و کسایی که دارن برای آزمون آماده میشن نمیدونن که دقیقا باید چه انتظاری داشته باشن.
PMI سیستم فعلی رو رسما توضیح نداده و قصد هم نداره بده، ولی ظاهرا ماجرا اینطوریه: بانکی از سوالها وجود داره که تعدادی از اونها برای آزمون هر کسی انتخاب میشه. حالا الان تو اون بانک برای هر سوال یه پارامتری هم وجود داره که سختیش رو مشخص میکنه. امتیاز قبولی هر کس بسته به ترکیب سختی سوالهایی که به طور رندم براش انتخاب شده تعیین میشه. به همین خاطر امتیاز قبولی همه یه جور نیست و اگه احیانا سوالهاتون سخت باشن خیالتون راحته که با امتیاز کمتری قبول میشین و به عبارت دیگه ماجرا منصفانهتر میشه. امتیازهای قبولی ظاهرا بین ۶۰ تا ۶۵ (و از نظر بعضی ۶۰ تا ۶۸) قرار داره.
البته وقتی که آزمون تموم میشه امتیازتون اعلام نمیشه و فقط میفهمین که قبول شدین یا نه و اینکه تو هرکدوم از گروههای فرآیندی چه وضعیتی داشتین. یه شایعهای که وجود داره اینه که باید تو هرکدوم از گروهها هم حداقلی از امتیاز رو بگیرین تا قبول بشین. با اینکه نمیشه کاملا به این شایعه اطمینان داشت، ولی به هر حال خوبه که وضعیت خودتون رو تو تک تک …
هدف خیلی از پروژههای بزرگی که میبینیم کمابیش واضح هستن، ولی بعضی وقتها هدف پروژه به اندازه کافی واضح نیست و تا وقتی که اون رو به خوبی مشخص نکنیم نمیتونیم پروژه رو درست برنامهریزی و اجرا کنیم. مثلا فرض کنین شما متخصص پیادهسازی سیستمهای مدیریت اسناد هستین و یه شرکتی شما رو برای این کار استخدام کرده. الان هدف چیه؟ اگه بگیم هدف پیادهسازی سیستم مدیریت اسناده زیاد دقیق صحبت نکردیم، چون اون خودش منجر میشه به این سوال که هدف از پیادهسازی سیستم مدیریت اسناد چیه. جوابی هم که به این سوال میدیم خیلی روی تعریف محصول پروژه و به تبع خود پروژه اثر داره، پس باید تو این کار جدی باشیم.
پروژه تو PRINCE2 تعریف و مشخصاتی داره که یکی از جنبههای اون میتونه خیلی تو شفاف کردن محصول پروژه بهمون کمک کنه:
پروژه چیزیه که تغییری تو دنیا به وجود میاره
این نکته خیلی جالبیه. اگه مجموعه کاری تعریف بشه که حتی به لحاظ تئوریک هم پتانسیل ایجاد تغییری تو دنیا رو نداشته باشه، نمیشه اسمش رو گذاشت پروژه.
حالا میتونیم از همین رویکرد PRINCE2 برای شفافتر کردن محصول پروژه استفاده کنیم. اولین سوالی که باید بپرسیم اینه که «انتظار دارین محصول این پروژه چه تغییری ایجاد کنه؟»، یا تو مثالی که زده بودم «انتظار دارین که سیستم مدیریت اسناد چه چیزی رو براتون تغییر بده؟». جوابهایی که برای چنین سوالهایی میگیرین مسایلی …