به یاد داشته باشید که پم‌باک درباره مدیریت پروژه است و نه مدیر پروژه. بیشتر پروژه‌ها مدیر پروژه دارند، ولی هیچ پروژه‌ای بدون مدیریت پروژه انجام نمی‌شود. حتی وقتی به مدیریت پروژه توجهی نشود، بازهم شکلی ضمنی از آن در پروژه وجود خواهد داشت.
مدیریت پروژه دو شکل کلی دارد:
متمرکز: در این گزینه گروهی مسئول هماهنگی‌ها و سایر جنبه‌های مدیریت پروژه هستند. معمولا فردی نیز در مرکز این گروه قرار دارد که مدیر پروژه نامیده می‌شود.
نامتمرکز: در این گزینه فرد یا افرادی که فقط مسئول مدیریت پروژه باشند وجود ندارند، بلکه همه اعضای تیم که مسئولیت‌های فنی دارند در مدیریت پروژه نیز مشارکت می‌کنند.
هر دو حالت، چنانچه با دیگر اجزای متدولوژی و طبیعت پروژه هماهنگ باشند، پذیرفتنی هستند. سیستم‌های نامتمرکز را فقط در تیم‌های بسیار کوچک می‌توان به کار برد و نمی‌توان انتظار داشت پروژه‌ای با صدها نفر خودجوش و نامتمرکز مدیریت شود.
از سوی دیگر، بسیاری از افراد فنی علاقه‌ای به درگیر کردن خود در مسایل هماهنگی و مدیریتی ندارند و چنانچه وادار به چنین کاری شوند، درجه رضایتشان در پروژه کاهش خواهد یافت. چنین کسانی ترجیح می‌دهند در فضایی کار کنند که سیستمی متمرکز برای هماهنگی‌ها وجود داشته باشد و انواع خدمات مدیریتی را به آن‌ها بدهد تا بتوانند در فضایی امن بر کارهای تخصصی خود تمرکز کنند.
برنامه‌ریزی کافی نیست و باید آن را اجرا کرد. متدولوژی خود را بررسی کنید و ببینید که برای مشارکت دادن ذی‌نفعان چه فعالیت‌هایی دارد (برای نمونه، ارتباطات) و در نظر هم داشته باشید که برخی اقدام‌ها ضمنی و نامرئی هستند. آیا این جنبه‌های متوولوژی برای درجه حساسیت مدیریت ذی‌نفعان در پروژه‌تان کافیست؟ اگر نباشد باید آن را تقویت کنید.
در کنار برنامه‌ریزی‌هایی که برای مشارکت دادن ذی‌نفعان می‌کنید، اقدام‌های موردی فراوانی نیز وجود خواهد داشت. مهارت‌های انسانی، مانند مذاکره و رفع اختلاف، در چنین مواردی کمک شایانی می‌کنند و بنابراین بهتر است بر بهبود مهارت‌های انسانی خود سرمایه‌گذاری کنید.
رفتارهایی غیراخلاقی مانند رشوه دادن راهی رایج برای مشارکت دادن ذی‌نفعان در برخی کشورهاست. فراموش نکنید که همیشه باید اخلاقی عمل کنید، حتی اگر هیچ‌کس دیگری در اطرافتان اخلاقی عمل نمی‌کند. رفتارهایی مانند رشوه دادن پذیرفتنی نیستند.
برخی رفتارهای به ظاهر بی‌گناه هم می‌توانند ذات رشوه دادن داشته باشند یا اینگونه برداشت شوند و درنتیجه باید مراقب آن‌ها هم باشید. این مسئله بستگی به نوع ذی‌نفع نیز دارد. برای نمونه، اگر مدیر شرکتی باشید و مدیران شرکتی همکار را به ضیافتی دعوت کنید، شاید مشکلی نداشته باشد، ولی اگر چنین کاری را با نمایندگان سازمانی قانون‌گذار انجام دهید پذیرفتنی نخواهد بود.
بر پایه اصل‌های NUPP، باید برای هر کاری که انجام می‌دهیم هدفی داشته باشیم. هدف از مشارکت دادن ذی‌نفعان چیست؟
مشارکت دادن ذی‌نفعان چندین هدف دارد:
می‌خواهیم همه الزامات پروژه را در زمان مناسب کشف کنیم (نمونه پناهگاه کوهستانی).
می‌خواهیم اعتبار خود را حفظ کنیم و گرفتار نشویم (نمونه پیشین درباره خریداران خشمگین).
می‌خواهیم از پشتیبانی ذی‌نفعان بهره ببریم.
و …
برخی ذی‌نفعان از آغاز جبهه‌گیری مثبتی نسبت به پروژه دارند، ولی بازهم باید از آن‌ها مراقبت کرد که همچنان مثبت باقی بمانند. برخی دیگر جبهه‌گیری منفی دارند و شاید بتوانیم با اقدام‌های سنجیده تغییرشان دهیم.
زمانی مسئول پیاده‌سازی سیستم مدیریت پرتفولیو در سازمانی بزرگ بودم. در میانه کار باخبر شدم که یکی از مدیران ارشد با کارمان موافق نیست و با آن دشمنی می‌کند. درباره‌اش پرس و جو کردم و به من توضیح دادند که او همیشه فردی منفی‌نگر است و با بیشتر کارها مخالفت می‌کند. از سوی دیگر، برخلاف بسیاری از مدیران و کارکنان دیگر که پس‌زمینه فنی یا کسب و کار داشتند، پس‌زمینه‌ای سیاسی داشت و پس از سال‌ها کار در پارلمان اروپا جذب این سازمان شده بود که در تصمیم‌گیری‌های بین‌المللی و سیاسی کمک کند. به دلیل پس‌زمینه‌اش، از سایر افراد شرکت جدا افتاده بود.
با این‌که دیدگاه همگی این بود که نباید به دشمنی‌اش اهمیت داد، با او تماس گرفتم و درخواست …
منظور از ارزش، نسبت منافع به هزینه است. هزینه مقوله کمابیش سرراستی است، ولی مفهوم منفعت را باید بیشتر بررسی کرد.
پولی که برای کاری دریافت می‌کنید نمونه‌ای از منفعت است، ولی منفعت به این مورد ساده محدود نمی‌شود. برخی پروژه‌ها منفعت‌هایی مانند نجات دادن جان افراد، بهبود وضعیت زندگی، و کمک به محیط زیست دارند. همه این موارد، یا دست‌کم شکل کمی شده آن‌ها، منفعت به شمار می‌رود. اگر اعتبار شرکتتان با انجام پروژه بهبود پیدا کند، آن هم نوعی منفعت است، یا دست‌کم نتیجه‌ای که می‌تواند منجر به منفعت شود.
هر سازمان مجموعه‌ای از معیارهای ارزش (value drivers) دارد. این معیارها در سازمان‌های متفاوت یکسان نیستند. برای نمونه، بهبود وضعیت زندگی را در نظر بگیرید:
می‌تواند معیار ارزش اصلی برای موسسه‌ای غیرانتفاعی باشد.
می‌تواند معیاری فرعی برای یک شرکت خصوصی باشد که معیار اصلی‌اش درآمدزاییست.
مدیر پروژه نیاز به مهارت‌های انسانی گوناگونی دارد. برای نمونه، APMbok، که راهنمایی همانند پم‌باک است، چنین دسته‌بندی‌ای ارائه می‌کند:
مهارت‌های ارتباطی
مهارت‌های رفع اختلاف
مهارت‌های تفویض اختیار
مهارت‌های تاثیرگذاری
مهارت‌های رهبری
مهارت‌های مذاکره
مهارت‌های کار تیمی
دسته‌بندی مهارت‌های انسانی کار ساده‌ای نیست. برای نمونه، «تاثیرگذاری» در دسته‌بندی بالا از «رهبری» جداست، با این‌که برخی آن را زیرمجموعه‌ای از مهارت‌های رهبری می‌دانند. گذشته از این‌که چگونه مهارت‌های انسانی را دسته‌بندی کنید، مهارت داشتن در همه آن‌ها برای رهبران لازم است.
برای همه این موارد کتاب‌های فراوانی وجود دارد. اگرچه متاسفانه این دامنه عینی نیست و از این رو متخصص‌های دروغین فراوان دارد و باید در انتخاب منابع دقت کنید.
حد مناسبی از تفصیل برای برنامه‌هایی که در لایه مدیریت پروژه آماده می‌کنید وجود دارد و بهتر است باقیمانده جزئیات را به تیم‌اجرایی بسپارید تا خود به‌گونه‌ای ضمنی یا غیرضمنی برنامه‌ریزی کنند. با این کار هم حق انتخاب بیشتری به تیم‌ها می‌دهید که مانع از جبهه‌گیری‌های منفی می‌شود و هم برنامه‌های اصلی را ساده‌تر و کاراتر نگه می‌دارید.
برای نمونه، پرینس۲ برنامه‌ای کلان دارد که در آغاز پروژه ساخته می‌شود. سپس برای هر دوره برنامه‌ای کمابیش تفصیلی برای همان دوره تنظیم می‌شود. جزئیات کامل در برنامه سومی قرار دارد که ساخت و نگه‌داری‌اش بر دوش تیم‌های اجراییست و نه مدیر پروژه.
نکته پایانی این است که باوجود پافشاری فراوانی که بر اهمیت برنامه‌ریزی داشته‌ایم، نباید تصور کنید که همه‌چیز باید برنامه‌ریزی شود. عناصر کم‌اهمیت پروژه را می‌توان به طور موردی و بیرون برنامه‌ها هدایت کرد.
سیستم مدیریت ریسک را با میزان پیچیدگی متفاوتی می‌توان پیاده‌سازی کرد. برای نمونه، در سیستم مینیمالیستی P3.express یک سند به نام فهرست پیگیری وجود دارد که برای ذخیره‌سازی اطلاعات ریسک‌ها، مسایل، درخواست‌های تغییر، برنامه‌های بهبود، و درس آموخته‌ها به کار می‌رود. این رویکرد که با رویکرد بسیاری از متدولوژی‌ها متفاوت است به دو دلیل انتخاب شده است:
می‌توان از فرآیندی همسان برای پیگیری همه آن موارد استفاده کرد، بدون این‌که وارد جزئیاتی شد که وابسته به نوع اقلام قابل‌پیگیریست.
اقلام قابل‌پیگیری نوع ثابتی ندارند، بلکه معمولا از نوعی به نوع دیگر تبدیل می‌شوند. برای نمونه، یکی از اقلام می‌تواند درباره رویدادی در آینده پروژه باشد که رخ دادنش قطعی نیست. این قلم در زمان تدوینش ریسک به شمار می‌رود. با این‌همه، وقتی جلوتر برویم و واقعا روی دهد، همان قلم ناگهان از ریسک تبدیل به مسئله می‌شود. وقتی مسئله را پیگیری کنیم و دیر یا زود ببندیم، تبدیل به درس آموخته می‌شود.
چنین روشی برای بسیاری از پروژه‌ها مناسب‌تر از روش‌های پیچیده است، ولی، چه‌بسا در پروژه‌های بسیار بزرگ پاسخگو نباشد و لازم باشد درجه پیچیدگی سیستم را افزایش داده، برای هرکدام از انواع اقلام قابل‌پیگیری اسناد و فرآیندهای جداگانه‌ای بسازید.
پرینس۲ و بسیاری دیگر از متدولوژی‌ها سندی با نام فهرست ریسک (risk register) برای ذخیره‌سازی اطلاعات …
امیدوارم برنامه برایتان مفید بوده باشد! شاید لینک‌هایی که در این صفحه معرفی می‌کنم هم به کارتان بیایند.
مقاله‌ها و کتاب‌ها و سایت‌ها و شبکه‌های اجتماعی
من کمابیش در لینکدین فعال هستم. پروفایل لینکدینم اینجاست و اگر مایل باشید می‌توانید مرا به شبکه خود اضافه کنید. برای مطالعه مقاله‌های فارسی‌ام می‌توانید به سایت شخصی‌ام مراجعه کنید. البته سال‌های اخیر به اندازه گذشته مقاله ننوشته‌ام. با این حال گذشته از مقاله‌ها می‌توانید کتاب‌های الکترونیکی فارسی‌ام را هم در همان سایت پیدا کنید. آخرین کتاب فارسی‌ای که منتشر کرده‌ام راهنمای مفهومی PMBOK 7 بوده است.
علاوه بر آن‌ها، اگر مایل باشید می‌توانید مقاله‌های انگلیسی‌ام را هم مطالعه کنید. ارتباط یک به یکی بین مقاله‌های فارسی و انگلیسی‌ام وجود ندارد.
اسلایدها
برای موضوع این برنامه اسلایدهایی وجود دارد که پیش‌تر برای ارائه در کنفرانس دیگری تهیه کرده بودم. اسلایدها به زبان انگلیسی هستند و مطابقت صد در صد هم با برنامه ارائه شده در این کنفرانس ندارند. با این حال، اگر مایل باشید می‌توانید از آن استفاده کنید.
انجمن ۲۰۲۴
همانطور که گفتم فیلم خوش‌آمدگویی جامعه OMIMO که برایتان پخش شد از برنامه انجمن ۲۰۲۴ بود. اگر مایل باشید می‌توانید فیلم ضبط شده این برنامه را ببینید. نکته‌ای جالب: یکی از ارائه‌دهندگان این برنامه قاضی است! آیا می‌توانید حدس بزنید کدام …
اگر پروژه کوچک و ساده نباشد، بهتر است که هر عضوی از تیم پروژه دقیقا بداند که چه انتظاری از او می‌رود و چه انتظاری می‌تواند از دیگران داشته باشد. اینگونه، جلوی بسیاری از سوتفاهم‌ها و مشکل‌ها گرفته می‌شود و از این روست که تعیین نقش‌ها و مسئولیت‌ها یکی از اصل‌ها در پرینس۲ به شمار می‌رود.
ما روزانه با مسایل فراوانی سر و کار داریم و هیچ‌کس توان بایسته برای واکنش نشان دادن به همه آن‌ها ندارد. در عمل با بسیاری از مسایل اطراف خود انفعالی برخورد می‌کنیم، یعنی کاری در برابر آن‌ها نمی‌کنیم، مگر این‌که به درجه‌ای برسند که نیاز به پادرمیانی ما داشته باشند. این برخورد طبیعیست و تنها راهکار برای زندگی. با این‌همه، مانند همیشه، ذهنمان آن را به همه مسایل تسری می‌دهد و در پروژه‌ها نیز این‌چنین برخورد می‌کنیم، ولی وقتی مدیریت موضوعی بر دوش ما باشد باید با آن غیرانفعالی برخورد کنیم.
برخورد غیرانفعالی الزاما به معنی اقدام کردن نیست. برخورد غیرانفعالی این است که هرگاه با مسئله‌ای روبرو می‌شوید به‌جای این‌که از آن چشم‌پوشی کنید، به آن بیندیشید و تصمیم بگیرید که اقدامی نیاز دارد یا نه. مدیریت ریسک نمونه‌ای از برخورد غیرانفعالی در پروژه است.
این اصل به این معنیست که در همه کارهایی که در مدیریت پروژه انجام می‌دهید غیرانفعالی برخورد کنید.
هر کاری که در پروژه انجام می‌دهید باید هدفی توجیه‌پذیر داشته باشد. این‌که دیگران کاری را انجام می‌دهند دلیلی برای انجامش نیست. اگر منابعی مانند پم‌باک یا متدولوژی‌های مدیریت پروژه آن‌ها را پیشنهاد می‌کنند نیز دلیلی برای انجامشان نیست، بلکه باید با مطالعه دقیق آن منابع درک کنید که چرا آن اقدام پیشنهاد شده است و آن را هدفمند انجام دهید.
در زمان تصمیم‌گیری چنین روندی را طی کنید: دو جهان موازی تجسم کنید که فقط در یکی از آن‌ها اقدام مدنظر را انجام می‌دهید. باید بتوانید توضیح دهید که نتایج پروژه به چه شکل در این دو جهان موازی متفاوت خواهند بود. پس از آن، به این بیندیشید که نتیجه مثبتی که در یکی از این دو جهان به دست می‌آید توجیه‌کننده کار اضافه‌ای که قرار است انجام دهید هست یا خیر.
برای نمونه، پرینس۲ گزارشی با نام highlights report دارد. می‌توانید با کمی جستجو در اینترنت تمپلیت‌هایی برایش بیابید، آن‌ها را پر کرده، برای گیرندگان بفرستید. این کار نمونه‌ای از بارپرستی است که در آغاز کتاب بررسی کردیم. راه درست این است که با مطالعه پرینس۲ بیاموزید که این گزارش چه هدفی دارد و چگونه با دیگر عناصر یکپارچه می‌شود. سپس، بدون نیاز به تمپلیت، می‌توانید گزارش مناسبی آماده کنید که اهداف را محقق کند.
پس از شناسایی ریسک‌ها باید برنامه‌های واکنشی برایشان طراحی کنیم. اگر می‌دانیم که نبود دیوار بیرونی در طبقه‌هایی که به تازگی ساخته شده‌اند ریسک حادثه به وجود می‌آورد، چه کاری باید برایش بکنیم؟
یک واکنش این است که فعالیت تازه‌ای به پروژه اضافه کنیم و بی‌درنگ پس از ساخته شدن کف هر طبقه نرده‌هایی موقت در حاشیه آن نصب کنیم. این کار احتمال حادثه را کمتر می‌کند، ولی کافی نیست. شاید بتوانیم روند کارها را کمی تغییر دهیم که ساخت دیوارهای بیرونی در زودترین زمان ممکن انجام شوند. این کار باز هم احتمال رخداد ریسک را کمتر می‌کند. شاید حتی بتوانیم فعالیت‌های دیگر را کمی جابجا کنیم که تا وقتی که دیوارهای بیرونی ساخته نشده‌اند رفت و آمد در طبقه حداقل شود.
به موازات این مسایل، فکر خوبیست که اعضای تیم پروژه آموزش ایمنی هم ببینند. این واکنش افزون بر ریسک مدنظرمان بر بسیاری ریسک‌های دیگر هم اثر می‌گذارد و از این رو بسیار مفید است. اگر پروژه بزرگ و دورافتاده باشد، فکر خوبیست که امکاناتی برای کمک‌های اولیه و حتی پرستاری مقیم هم در نظر گرفته شود تا هنگامی‌که حادثه‌ای رخ می‌دهد اثرش کاهش یابد.
افزون بر اثر مالی و زمانی حادثه‌ها، مسئولیت اجتماعی ما نیز حکم می‌کند که با ریسک حادثه با جدیت برخورد کنیم. با این‌همه، وقتی همه واکنش‌های منطقی را انجام دهید باز هم احتمال حادثه وجود دارد. بنابراین برای حفاظت از …
آیا تا کنون چیزی همانند «نه، ما از پرینس۲ استفاده نمی‌کنیم چون برای شرکت ما زیاد از حد پرهزینه است» شنیده‌اید؟
پرینس۲ و همه متدولوژی‌های دیگر ساخته شده‌اند تا به شکل‌های گوناگون، از جمله کاهش هزینه، به شرکت‌ها کمک کنند. اگر سیستمی این‌چنینی پیاده‌سازی کنید و به نظرتان سربارش بیشتر از نتیجه باشد، به این معنیست که آن را به خوبی اختصاصی‌سازی نکرده‌اید.
اختصاصی‌سازی چیست؟
برای نمونه، پرینس۲ گزارشی به نام checkpoint report دارد که در دوره‌های زمانی از پیش تعیین شده از سوی مدیران تیم‌ها برای مدیر پروژه فرستاده می‌شود. پرینس۲ برای آن و دیگر موارد به‌جای عبارت «سند» از عبارت محصول مدیریتی استفاده می‌کند، زیرا الزامی نیست که آن‌ها را در قالب سند بسازید. اگر پروژه پیچیده و بزرگ باشد، شاید آن را مستند کنید، ولی در پروژه‌های کوچک‌تر حتی یک تماس تلفنی میان مدیر تیم و مدیر پروژه برای این منظور کفایت می‌کند. تنها الزام این است که تماس تلفنی در بازه‌های زمانی از پیش تعیین شده گرفته شود و در طی گفتگو موضوع‌های این گزارش بررسی شوند. هنگامی‌که نوع گزارش را تعیین می‌کنید، در عمل پرینس۲ را اختصاصی‌سازی کرده‌اید.
اگر استدلال بخش پیشین برایتان پذیرفتنی باشد، باز هم دو چالش کلان در عمل وجود خواهد داشت. نخستین چالش این است که بسیاری از کسانی که در پروژه‌ها کار می‌کنند مدیر پروژه‌ای که مهارت فنی نداشته باشد را نمی‌پذیرند. اگر چنین مدیر پروژه‌ای باشید، باید در نظر داشته باشید که ریشه دشواری این است که این افراد چه‌بسا هیچ‌گاه مدیر پروژه واقعی ندیده‌اند. همه مدیر پروژه‌هایی که داشته‌اند متخصص‌های ارشدی بوده‌اند که تصمیم‌گیری‌های کلان فنی بر دوششان بوده است و به‌جای کل تیم برنامه‌ریزی می‌کرده‌اند. قاعدتا برای انجام چنین کاری باید مهارت فنی داشت و از این روست که گمان می‌کنند فردی غیرفنی نمی‌تواند پروژه‌شان را مدیریت کند.
راهکار این است که از آغاز با شفافیت مسئله را برایشان روشن کنید. توضیح دهید که قرار نیست برایشان تصمیم‌گیری‌های فنی انجام دهید، بلکه نقشتان پشتیبانی از تیم پروژه و فراهم کردن فضای کاری مناسب است. بی‌گمان سخن گفتن در این باره کافی نیست و نیاز است که هر چه زودتر آن را در عمل به تیم نشان دهید تا بتوانید اعتمادشان را جلب کنید. اگر این کار را به‌درستی انجام دهید، پس از چند هفته تا چند ماه پذیرفته خواهید شد.
زمانی یکی از بهترین مدیر پروژه‌هایی که می‌شناختم برای مدیریت پروژه‌ای نرم‌افزاری انتخاب شد و اعضای تیم کاملا در برابرش جبهه‌گیری کرده بودند زیرا او همیشه در پروژه‌های سازمانی کار …
نسخه‌های نخستین پم‌باک برای پروژه‌های متعین تدوین شده بودند. پس از این‌که شیوه‌های تطبیقی پذیرش همگانی پیدا کردند، به‌تدریج مطالبی درباره‌شان به پم‌باک افزوده شد، ولی این موارد هیچ‌گاه با بدنه اصلی پم‌باک یکپارچه نشده بودند، بلکه به آن تحمیل شده بودند. از آن‌جایی که نسخه هفتم پم‌باک را از آغاز تدوین کردیم و به‌روزرسانی محتوای پیشین نیست، آن را از بنیان به‌گونه‌ای ساختیم که با هردو روش ساخت محصول سازگار باشد.
برخی گمان می‌کنند که «پم‌باک ۷ چابک شده است»، که کاملا اشتباه است. پم‌باک ۷ با هردو روش سازگار است و حتی بهتر است بگوییم رویکردش به مسایلیست که تاثیر چندانی از تطبیقی یا متعین بودن نمی‌گیرند.
تمدن بشری همیشه از هر دو روش متعین و تطبیقی استفاده کرده است و نشانه‌های آن را می‌توان در بسیاری پروژه‌های باستانی دید. نخستین نسل کامپیوترها محدودیت‌های فراوان و مخاطب ویژه و اندکی داشتند که باعث می‌شد ساخت نرم‌افزارهایشان نیاز به روشی متعین داشته باشد. با پیشرفت سخت‌افزار، کاهش محدودیت‌ها، و دگرگونی نوع و گستردگی مخاطب نرم‌افزارها، روش‌های متعین دیگر گزینه خوبی برای ساخت نرم‌افزار نبودند، ولی دست‌اندرکاران این نوع پروژه‌ها همچنان به عادت گذشته می‌کوشیدند روش‌های متعین را به‌کار گیرند.
تحمیل روش‌های متعین بر پروژه‌های نرم‌افزاری همچنان ادامه پیدا کرد، تا زمانی که برنامه‌نویسان و مدیران تیم‌ها بیشتر و بیشتر از وضعیت ناراضی شدند و گرایش به ساخت محصول به شیوه تطبیقی پیدا کردند. سرانجام، گروهی از این افراد دورهم گرد آمدند تا به رویکرد خود رسمیت بخشند و برای آن نام چابک را انتخاب کردند.
متاسفانه اختلاف‌ها و مشکل‌های فراوانی که در این روند به وجود آمده بود ذهنیتی منفی درباره روش‌های متعین برای این افراد و کسانی که ادامه‌دهنده راهشان شدند به وجود آورد. به عبارت دیگر، به‌جای اصلاحی تدریجی، انقلابی خونین به وجود آمد. کمی پس از انقلاب هم گروهی کوچک مهره‌های اصلی را کنار زده، قدرت مطلق را به دست گرفتند. دایما هم درباره دشمن بیرونی هشدار می‌دهند! برای اطلاعات بیشتر می‌توانید به کتاب «قلعه …