بعد از یه فرآیند نسبتا سخت شش ماهه که شامل مصاحبه و ارزیابی عملی می‌شد، بالاخره تونستم مجوز رسمی تدریس و برگزاری آزمون PRINCE2 رو از APMG بگیرم.
برای تدریس PMP نیاز به هیچ مجوزی نیست؛ حتی مدرس لازم نیست که PMP باشه. حتی محتوایی هم که تدریس می‌شه لازم نیست تایید شده باشه؛ هرچند که روندهایی برای دریافت تاییدش وجود داره. با این حال اوضاع برای PRINCE2 متفاوته. مدرس پرینس۲ باید گواهی تدریس داشته باشه. این گواهی به کسایی داده می‌شه که نمره‌های بالایی تو آزمون PRINCE2 Practitioner داشته باشن (نمره قبولی ۵۵ درصده، ولی این افراد باید حداقل ۶۷ درصد گرفته باشن)، تو مصاحبه حضوری با ارزیاب نشون بدن که دانششون از پرینس۲ کامل، یکپارچه و پیوسته‌س و بتونن برای همه موارد مثال‌های عملی بزنن، و در نهایت یه دوره آموزشی رو هم تحت مراقبت ارزیاب‌ها تدریس کنن و سبک تدریسشون از نظر پویایی، تعامل، تاثیرگذاری و کیفیت تایید بشه. البته علاوه بر اون باید یه موسسه آموزشی تایید شده پرینس۲ هم این افراد رو تایید و به APMG معرفی کنه.
این مجوز علاوه بر تدریس PRINCE2 برای برگزاری آزمون هم هست. یعنی این افراد باید تسلط کاملی به روند و قوانین آزمون‌ها داشته باشن و بتونن داوطلب‌ها رو راهنمایی کنن. این افراد مورد اعتماد موسسه هستن و می‌تونن هر جای دنیا آزمون‌های کاغذی پرینس۲ رو برگزار کنن.
بعضی وقت‌ها تو استانداردها و روش‌های مدیریت پروژه به توصیه‌های متناقض بر می‌خوریم. مثلا تو خیلی از چهارچوب‌های چابک با تشویق اعضای تیم پروژه مخالفیم، در حالی که داشتن نظام تشخیص و تشویق تو PMBOK لازمه. خوب، حالا کدوم درست می‌گه؟
یا مثلا داشتن تعریف‌های دقیق و شفاف از نقش‌ها و مسئولیت‌ها تو PRINCE2 واجبه (از اصول زیربناییه)، در حالی که مثلا تو تیم تولید اسکرام تعریف هیچ نقش و سمتی مجاز نیست، همه مثل هم هستن. کدوم درست می‌گه؟
موارد متناقض اینچنینی زیاد می‌بینیم و شاید این سوال براتون پیش بیاد که کدوم درست می‌گه. جواب هم ساده‌س: سوال درست نیست!
بله، چنین سوالی درست نیست. هیچکدوم از اون‌ها درست یا غلط نیستن. ماجرای مهم اینه که سیستمی پیوسته، سازگار و موثر داشته باشیم. پم‌باک طوریه که برای حفظ سازگاری و پیوستگیش نیاز به نظام تشخیص و تشویق داریم و خیلی از چهارچوب‌های چابک طوری هستن که چنین چیزی سازگاریشون رو به هم می‌زنه. موارد دیگه هم همینطور هستن.
حالا دلیل اصلی نوشتن این مطلب این نبود که بگم چنین سوالی درست نیست، دلیل اصلیش این بود که بگم تا چه حد مهمه که نظامی که آدم استفاده می‌کنه التقاطی نباشه. کسایی که مثلا سعی می‌کنن از چهارچوبی مثل اسکرام استفاده کنن، ولی یکی دو قسمت اون رو حذف می‌کنن چون اعتقاد دارن که برای محیطشون مناسب نیست یا کسایی که مثلا سعی می‌کنن از پم‌باک و پرینس۲ …
خیلی از شماها که کارتون برنامه‌ریزی و کنترل پروژه‌س به فکر تاسیس شرکت می‌افتین و بعضی وقت‌ها ایمیل‌هایی برای مشورت در این مورد دریافت می‌کنم. تو این مطلب می‌خوام نظرم رو در این مورد برای همه بگم.
من خودم وقتی ۱۸ سال پیش کارم رو تو این حوزه شروع کردم خیلی زود تصمیم گرفتم که یه روزی شرکت خودم رو راه بندازم. شرکتی تخصصی برای برنامه‌ریزی و کنترل پروژه. این هدف من بود و سال به سال که جلوتر می‌رفتم مصمم‌تر می‌شدم و بیشتر از قبل براش برنامه‌ریزی می‌کردم. با این حال شتاب‌زده عمل نکردم و به تدریج چیزهایی یاد گرفتم که باعث شد بفهمم این انتخاب برای من مناسب نیست؛ برای کسای دیگه‌ایه. با این‌که هیچوقت تو زندگیم کارمند نبودم و نمی‌خواستم هم که باشم، ولی تاسیس شرکت از برنامه کاری من حذف شد. البته الان به نوعی ممکنه صاحب شرکت به حساب بیام، چون در ازای دریافت سهام به مجموعه‌ای پیوستم و کارم رو اونجا متمرکز کردم، ولی این شرایط کاملا متفاوته.
بدونیم داریم چیکار می‌کنیم
اولین نکته اینه که دقیقا بدونیم داریم چیکار می‌کنیم. دیدگاه سنتی اینه که وقتی یه نفر پیشرفت می‌کنه باید از کارشناس تبدیل بشه به مدیر و بعد هم یه شرکت برای خودش راه بندازه. ولی این درست نیست. تبدیل شدن از یه کارشناس به یه مدیر یه تغییر تو حرفه‌س، پیشرفت نیست. تاسیس شرکت هم همینطور.
اگه بزرگ‌ترین علاقه‌مندی حرفه‌ای‌تون کار تخصصی تو حوزه …
یه سوال همیشگی اینه که ترتیب فرآیندهای PMBOK چیه و اگه مثلا بخوایم اجراش کنیم باید چطوری پیش بریم. قبلا تو خیلی از نوشته‌ها مستقیم یا غیر مستقیم درباره‌ش توضیح دادم، ولی الان می‌خوام به طور خاص در مورد این ماجرا صحبت کنم.
فرآیندهای PMBOK ترتیب ندارن!
اولین نکته اینه که باید بدونین فرآیندهای پم‌باک ترتیب ندارن. بله، پم‌باک قصد نداشته براشون ترتیب مشخص کنه.
حالا احتمالا فکر کنین که اگه قراره ترتیب برای فرآیندها ارائه نشده باشه، پس اون همه فلش‌هایی که تو پم‌باک از یه فرآیند به فرآیند دیگه می‌ره چیه. اون روابط تو پم‌باک نشون‌دهنده ترتیب اجرا نیستن، نشون‌دهنده اینن که فرآیندها چطوری با هم یکپارچه می‌شن، که این از مهم‌ترین مفاهیم پم‌باکه.
این یکپارچگی نشون می‌ده که چه نوع وابستگی‌هایی بین فرآیندها هست و اگه بخوایم یه فرآیند خاص رو خوب و کامل و موثر اجرا کنیم، باید از چه چیزهایی تاثیر بگیره و بر چه چیزهایی تاثیر بذاره. اگر تاثیرپذیری کامل نباشه، نتیجه‌ش قابل اطمینان نیست و اگه تاثیرگذاریش کامل نباشه، نتیجه‌ش درست استفاده نشده. تو هر دو حالت دچار مشکل می‌شیم.
چرا فرآیندهای PMBOK ترتیب ندارن؟
حالا چرا فرآیندهای پم‌باک ترتیب ندارن؟
می‌شه مثلا به PRINCE2 نگاه کنین. فعالیت‌های پرینس۲ کمابیش معادل فرآیندهای پم‌باک هستن و بین اون‌ها هم فلش‌هایی وجود داره، روابطی وجود داره. ولی این روابط تو …
اون ماجرای مثلث پروژه و محدودیت‌های سه‌گانه رو که حتما می‌شناسین: گستره، زمان، هزینه… کیفیت رو هم خیلی وقت‌ها بهش اضافه می‌کنن و در عین حال بازم سعی می‌کنن مثلث نگهش دارن.
به هر حال، یکی از تفاوت‌های عمده‌ای که تو رویکرد چابک Atern به پروژه هست رو می‌شه روی همین مثلث توضیح داد:
تو پروژه‌های کلاسیک گستره رو ثابت نگه می‌داریم. مثلا قراره یه بیمارستان بسازیم، گستره‌ش ثابته… یه بیمارستان کامله، با تعداد طبقه و زیربنای مشخص و مصالح تعیین شده و امثال اون‌ها. با هزینه و زمان طوری بازی می‌کنیم که به اون گستره برسیم. سعی می‌کنیم هزینه و زمان رو محدود نگه داریم، ولی اگه ببینیم مثلا وقت کم داریم، معمولا گستره رو کوچیک نمی‌کنیم (مثلا یه طبقه بیمارستان رو حذف کنیم، یا تاسیسات مکانیکیش رو بذاریم کنار)، یا بیشتر هزینه می‌کنیم، یا زمان بیشتر مصرف می‌کنیم. کیفیت رو سعی می‌کنیم ثابت نگه داریم، ولی خیلی وقت‌ها مجبور می‌شیم برای رسیدن به گستره کیفیت رو هم قربانی کنیم.
تو رویکرد چابک اترن (DSDM Aten) برعکس عمل می‌کنیم، یعنی هزینه و زمان و کیفیت رو از ابتدا مشخص و ثابت می‌کنیم و گستره رو کم و زیاد می‌کنیم.
به نظرتون عجیب میاد، نه؟ مثلا یه پیمانکار با کارفرماش قراردادی می‌بنده که توش مدت زمان و هزینه و کیفیت کار به دقت مشخص شده، ولی گستره کار اجازه داره که تغییر کنه!
شاید از این سوال تعجب کنین؛ شاید فکر کنین که وقتی از برنامه عقب می‌افتیم باید به فکر چاره باشیم و وقتی که جلو می‌افتیم فقط خوشحال می‌شیم و لازم نیست کاری کنیم. در حالی که اینطور نیست.
هرکدوم از پارامترهای پروژه مقدار مشخصی دارن و هدف اینه که پروژه رو طبق اون مقادیر تکمیل کنیم. پارامترهای معمول این‌ها هستن:
زمان
هزینه
کیفیت
گستره
منافع
برای هرکدوم یک یا چند حد کنترلی هم مشخص می‌کنیم و این‌ها تعیین می‌کنن که وقتی انحرافی به وجود میاد چه کسی باید برای اصلاحش تصمیم بگیره (همون مفهوم مدیریت مبتنی بر سطوح پرینس۲). مثلا مدت زمان پروژه ۱۸ ماهه با این حدود رواداری: ۲ ماه بیشتر یا ۴ ماه کمتر. اگه از اون حدود رد بشیم باید تمام برنامه‌ها رو بازبینی کنیم و به فکر چاره باشیم و سطوح مدیریتی بالاتر هم باید در مورد راه حل نهایی تصمیم بگیرن.
حالا شاید با خودتون فکر کنین که چرا وقتی از برنامه جلو می‌افتیم، مثلا تو مثال قبلی پیش‌بینی می‌کنیم که پروژه به جای ۱۸ ماه تو ۱۲ ماه تموم می‌شه باید مثل وقتی که از برنام عقب افتادیم تصمیم‌گیری‌های جدید بکنیم، برنامه جدید تهیه کنیم و امثال اون‌ها. نظرتون در مورد این سوال چیه؟
ماجرا اینه که اگه وضعیت مطلوب این باشه که پروژه ۱۸ ماهه تموم بشه و ما داریم جوری پیش می‌ریم که پیش‌بینی می‌شه ۱۲ ماهه تموم بشه، احتمالا داریم زیاد از حد منابع صرف می‌کنیم. شاید بتونیم با …
قطعا تو حوزه مدیریت پروژه زیاد به عبارت چابک یا Agile می‌رسین و ممکنه تصور کاملی ازش نداشته باشین، حوصله‌ش رو هم نداشته باشین که منابع کامل رو بخونین و یاد بگیرینش. تو این مطلب می‌خوام سعی کنم چابک بودن رو به سریع‌ترین و ساده‌ترین حالت ممکن توضیح بدم.
چه وقتی باید چابک بود؟
وقتی از روش‌های چابک استفاده می‌کنیم که عدم قطعیت‌ها و تغییرهای پروژه خیلی زیاد باشن. مثال همیشگی من اینه: فرض کنین قراره یه بیمارستان بسازین. ممکنه خیلی تغییرات به پروژه اعمال بشه، حتی ممکنه تعداد طبقه‌هاش کم و زیاد بشه، ولی احتمالا در آخر باز هم یه بیمارستان خواهد بود و مثلا یه شهر بازی از آب در نمیاد. غیر از اینه؟ ولی تو بعضی پروژه‌ها اینطور نیست. مثلا تو پروژه‌های نرم‌افزاری ممکنه کار رو برای تولید یه «بیمارستان» شروع کنین و وقتی تموم می‌شه ببینین یه «شهر بازی» ساخته شده. روش‌های چابک برای این نوع پروژه‌ها در نظر گرفته شدن.
در حال حاضر از روش‌های چابک عمدتا برای پروژه‌های نرم‌افزاری و تا حدی برای پروژه‌های تحقیقاتی و تغییر سازمانی استفاده می‌شه. مثلا اگه می‌خواین یه ERP یا یه سیستم مدیریت اسناد تو سازمانتون پیاده‌سازی کنین می‌تونین چابک پیش ببرینش.
چابک بودن چطوریه؟
چابک بودن یعنی این‌که تغییرات رو بپذیریم و فضایی به وجود بیاریم که هر تغییری که ممکنه بخواد رخ بده سریع‌تر اتفاق بیفته. هرچقدر تغییر بیشتر …
چند وقت پیش در مورد سری جدید راهنماهای PMI که اسمشون راهنماهای عملی (Practice Guide) هست نوشته بودم و در مورد اولین راهنما که در مورد مدیریت تغییراته. الان راهنمای دوم هم منتشر شده، درباره مدیریت پیچیدگی‌های پروژه، طرح و پرتفولیو.
کتاب حدودا ۱۰۰ صفحه‌س و موضوع رو از این جنبه‌ها توضیح می‌ده:
جنبه‌های زیرساختی مرتبط با پیچیدگی‌ها، یعنی سازمان
ریشه‌های پیچیدگی، که اون‌ها رو به سه دسته می‌کنه: رفتار انسانی، رفتار سیستمی و ابهام
اقدامات واکنشی، که عمدتا تو یکی از چهار حوزه گستره، ارتباطات، ذی‌نفعان و ریسک قرار می‌گیرن.
نظامی برای ارزیابی پیچیدگی‌ها
نکته جالب اینه که این کتاب رایگانه و همگی می‌تونن دانلودش کنن. برای دانلود کتاب از این لینک استفاده کنین. بعد از دانلود می‌تونین پسوندش رو از اون چیزی که هست به PDF تبدیل و مثل هر کتاب PDF دیگه‌ای ازش استفاده کنین.
، یعنی همون موسسه‌ای که PMBOK رو تهیه و منتشر می‌کنه، مجموعه‌ای از استانداردها داره، از جمله استاندارد مدیریت پرتفولیو.
مدیریت پرتفولیو نظامیه که پروژه‌ها، طرح‌ها و عملیات سازمان رو ارزیابی می‌کنه، بهترین‌هاش رو انتخاب می‌کنه و در مدت اجرا منابع محدود رو به شکل مناسب به اون‌ها اختصاص می‌ده. یه سیستم مدیریت پرتفولیوی خوب باعث می‌شه پروژه‌های نامناسب رو شروع نکنیم. پروژه‌هایی رو انتخاب کنیم که بیشتری فایده رو برای سازمانمون داشته باشن (معمولا سود) و بالانس هم باشن، یعنی مثلا ترکیب‌های زود بازده و دیربازده با هم ترکیب شده باشن.
استاندارد مدیریت پرتفولیوی PMI موضوعی مشابه استاندارد MoP داره، ولی ساختار و رویکردش متفاوته. استاندارد پرتفولیوی PMI مثل بقیه استانداردهای این خانواده از جنس دانشه، در حالی که MoP مثل استاندارد مدیریت پروژه هم‌خانواده‌ش، یعنی PRINCE2، بیشتر از جنس متودولوژیه.
استاندارد مدیریت پرتفولیوی PMI مثل پم‌باک مجموعه‌ای از فرآیندهاس و مثل پم‌باک اون‌ها رو به دو شکل دسته‌بندی می‌کنه:
گروه‌های فرآیندی: بر اساس نوع، شامل گروه‌های تعریف، تنظیم و تصویب و کنترل
حوزه‌های دانش: بر اساس موضوع، شامل استراتژی، حاکمیت، عملکرد، ارتباطات و ریسک
تو این استاندارد ۱۶ فرآیند داریم و هرکدوم از اون‌ها عضو یه گروه فرآیندی و یه حوزه دانشه.
PMI راهنماهای مختلفی داره که تو این گروه‌ها قرار می‌گیرن:
استانداردهای اصلی (پم‌باک، استاندارد مدیریت طرح، استاندارد مدیریت پرتفولیو، …)
استانداردهای عملی (زمان‌بندی، ساختار شکست کار، …)
توسعه‌های پم‌باک (پروژه‌های ساخت و ساز، دولتی، نرم‌افزاری)
و به تازگی گروه چهارمی اضافه شده، راهنماهای عملی (practice guides). این گروه قراره راهنماهایی رو تو خودش جا بده که در سطح «استانداردهای عملی» نیستن، ولی از همون جنسن و ممکنه زمانی به استاندارد تبدیل بشن. در حال حاضر فقط یک محصول تو این گروه وجود داره که جدید هم هست: راهنمای عملی مدیریت تغییرات در سازمان
اگه عضو PMI باشین می‌تونین همین الان به رایگان دانلودش کنین.
بخش اول این کتاب کلیاتی رو در مورد تغییرات و چهارچوب کلی مدیریت تغییرات ارائه می‌کنه و بعد از اون چهار بخش مهم وجود داره:
مدیریت تغییرات در مدیریت پروژه سازمانی
مدیریت تغییرات در مدیریت پروژه
مدیریت تغییرات در مدیریت طرح
مدیریت تغییرات در مدیریت پرتفولیو
و به این ترتیب شیوه پیاده‌سازی اون چهارچوب رو تو هرکدوم از اون سطوح توضیح می‌ده. البته شکی نیست که برای درک کامل این راهنما باید پم‌باک، استاندارد مدیریت پرتفولیو و بقیه استانداردهای مرتبط رو هم شناخت.
تو هر پروژه‌ای به طور دوره‌ای ارزیابی انجام می‌دیم و بر اون اساس گزارش‌هایی می‌دیم. اطلاعاتی که تو گزارش‌ها داده می‌شه رو می‌شه به دو دسته تقسیم کرد:
مربوط به گذشته (مثل درصد پیشرفت، بخش‌های تکمیل شده، هزینه صرف شده و مقدار تاخیری که تا حالا روی مسیر بحرانی پیش اومده)
مربوط به آینده (مثل تاریخ پایان تخمینی پروژه و هزینه تخمینی پروژه)
اطلاعات گروه اول ارزش دارن، ولی فقط ارزش محاسباتی دارن، برای این‌که برسیم به اطلاعات گروه دوم. چیزی که واقعا به درد مدیران می‌خوره و به طور کلی چیزی که می‌تونه مبنای تصمیم‌گیری‌ها قرار بگیره اطلاعات گروه دومه. چیزایی که تو گروه اول قرار می‌گیرن حتی زیاد از جنس «اطلاعات» نیستن، بیشتر «داده» خام به حساب میان که باید پردازش بشن.
متاسفانه انواع اطلاعاتی که تو گزارش‌ها ارائه می‌شه از گروه اوله. پیشرفت کل پروژه و پیشرفت اجزای اون، به تفکیک واقعی و برنامه‌ریزی شده و تجمعی و دوره‌ای و امثال اون‌ها، با چیزهایی که دوباره مشابه اون‌ها هستن، یعنی بخش‌های تکمیل شده و مایل‌ستون‌های محقق شده و عقب افتاده، و چیزی که واقعا کاربرد مدیریتی نداره، یعنی تاخیر روی مسیر بحرانی.
وقتی یه مدیر چنین اطلاعاتی رو دریافت می‌کنه ممکنه اعتراض نکنه که کافی نیستن، چون بهشون عادت کرده. اون آدم ناخودآگاه سعی می‌کنه با این اطلاعات وضعیت آینده رو پیش‌بینی کنه و بر اون اساس تصمیم‌گیری …
یه سوال رایج اینه که وزن‌های فیزیکی رو تو پروژه‌های EPC چطوری باید تنظیم کنیم. سعی می‌کنم تو این مطلب جواب کاملی به این موضوع بدم.
ساختار شکست کار پروژه‌های EPC
قبل از این‌که در مورد وزن‌بندی صحبت کنیم می‌خوام کمی در مورد ساختار شکست کار این نوع پروژه‌ها بگم. معمولا اولین سطح ساختار شکست این نوع پروژه‌ها E (مهندسی)، P (تدارکات) و C (اجرا) هست؛ ولی این شکست زیاد مناسب نیست.
یادتون که دو معیار تدوین ساختار شکست چیه؟
ساختار شکست کار باید مبتنی بر تحویل‌شدنی‌ها باشه، باید محصول محور باشه، نه این‌که توش صرفا فعالیت‌ها رو دسته‌بندی کنیم. در واقع ساختار شکست برای دسته‌بندی فعالیت‌ها نیست، یه ساختاره که گستره پروژه رو نشون می‌ده و اگه بخوایم اصولی کار کنیم، بعد از این‌که ساختار شکست کار تهیه بشه فکر می‌کنیم و هرکدوم از بسته‌های کاری (عناصر پایین‌ترین سطح ساختار شکست کار) رو به فعالیت‌هایی که برای تولید اون محصول لازمه خرد می‌کنیم.
باید قاعده ۱۰۰ درصد رو هم رعایت کرده باشه که به موضوع فعلیمون ارتباط زیادی نداره. اگه علاقه‌مند بودین می‌تونین به ایبوک راهنمای تدوین ساختار شکست کار مراجعه کنین.
بنابر این به نظر من ساختار شکست کار مناسب‌تر برای یه پروژه EPC که مثلا از نوع کارخونه فرآوری باشه یه همچین چیزیه:
همکارم به تازگی یه فیلم آموزشی یک ساعته در مورد پرینس۲ ساخته که می‌تونه برای آشنایی مقدماتی با متودولوژی مفید باشه. می‌تونین فیلم رو که به زبان انگلیسی هست تو یوتیوب ببینین.
تو اکثر کلاس‌هایی که درس می‌دم از من در مورد معنی مدیریت پرتفولیو می‌پرسن؛ کسایی که تعریفش رو می‌دونن، ولی راضی نیستن، چون درک درستی ازش ندارن. از طرف دیگه اشتباه‌های زیادی در مورد مدیریت پرتفولیو رایجه، که تو این مطلب می‌خوام در موردشون توضیح بدم.
اشتباه ۱: مدیریت پرتفولیو نیاز به مدیریت طرح و پروژه داره
خیلی‌ها فکر می‌کنن که اول باید سیستم مدیریت پروژه رو سر و سامون داد، بعد رفت سراغ سیستم مدیریت طرح (اگه لازم باشه) و بعد از همه اون‌ها سیستم مدیریت پرتفولیو. واقعیت اینه که اینطور نیست. ممکنه سیستم‌های مدیریت پروژه و طرح سازمان به بلوغ نرسیده باشن و حتی اصلا هم مناسب نباشن، ولی بتونین سیستم مدیریت پرتفولیوی مناسبی مستقر کنین و ازش نتیجه هم بگیرین.
اشتباه ۲: هر شرکتی نیاز به مدیریت پرتفولیو نداره
اصلا؛ هر شرکتی حداقل یه پرتفولیوی کلی داره که کل پروژه‌ها و اقدامات شرکت رو تحت پوشش می‌گیره. حتی هر آدمی هم یه پرتفولیو داره و باید مدیریتش کنه.
بعضی شرکت‌ها که تعداد و تنوع پروژه‌ها و کارهاشون خیلی زیاد باشه اون‌ها رو تو چنتا پرتفولیو تقسیم می‌کنن تا مدیریتش راحت‌تر بشه. تو این حالت هم بهتره که اون پرتفولیوها همه زیرمجموعه «یک» پرتفولیوی کلی بشن.
مدیریت پرتفولیو چیه؟
خیلی‌ها تو درک معنی پرتفولیو و خصوصا تفاوتش با طرح مشکل دارن. این دوتا تو خیلی از منبع‌ها اینطوری تعریف می‌شن:
این مطلب برای معرفی دوتا از نرم‌افزارهای محبوب منه، که هردوشون هم به سبک کانبان هستن.
نمی‌دونم از چه سبک و روشی برای مدیریت کارهای شخصی‌تون استفاده می‌کنین، ولی کانبان شخصی (Personal Kanban) یکی از روش‌های خوبه. به جز اون چیزهای دیگه‌ای مثل GTD هم هست. من خیلی از اون‌ها رو امتحان کردم و حتی روش‌های ترکیبی و ابداعی خودم رو هم ساختم، ولی به هر حال الان مدت زیادیه که از نسخه بسیار ساده شده‌ای از Personal Kanban استفاده می‌کنم.
در هر حال از هر روشی که استفاده کنین یه قاعده خیلی مهم توش وجود داره:
کارهایی که باید انجام بدین رو ثبت کنین
این باعث می‌شه که هم چیزی یادتون نره و هم ذهنتون آزادتر باشه. بعد می‌تونین با هر روشی ترتیب کارها رو مشخص کنین و پیش برین. بیشتر روش‌ها در مورد تعیین ترتیب کارهاس و بعضی‌هاشون زیاد از حد پیچیده می‌شن، در حالی که واقعا به اون اندازه پیچیده نیست. تعیین ترتیب کارها برای من فقط فوریت و بازگشت مالی و امثال اون‌ها نیست، این هم هست که تو هر زمان دلم می‌خواد چه جور کاری انجام بدم.
کاری که من می‌کنم اینه که یه تخته کانبان «ناقص» دارم و کل کارهام رو توش وارد می‌کنم، هر کار روی یه کارت. بعد چند وقت یه بار ترتیب کارتها رو اصلاح می‌کنم. از اول روز هم که می‌خوام کارهام رو شروع کنم یه نگاهی به بالای تخته می‌ندازم و از بین کارت‌هایی که اون بالا هستن (یعنی کارهایی که باید …
