نرم‌افزار برنامه‌ریزی P3pper
مدتیه که مشغول تهیه نرم‌افزاری برای برنامه‌ریزی و کنترل پروژه هستیم به اسم P3pper (مشابه کلمه pepper {فلفل} تلفظ می‌شه) که زیرمجموعه‌ای از طرح P3.express هست.
هدف P3.express ساده‌سازی مدیریت پروژه‌س، و فکر می‌کنم تو این هدف موفق هم بوده. با این حال، هرچقدر هم که روند مدیریت پروژه ساخت‌یافته و ساده شده باشه، باز هم کارهایی هست که باید با کمک نرم‌افزار انجام بشه و نرم‌افزارهای موجود از نظر نوع امکانات و سادگی استفاده به اندازه کافی مناسب به نظر نمیان. به همین خاطر برای نزدیک شدن به هدف نهاییمون سراغ تهیه این نرم‌افزار رفتیم. خوشبختانه حمایت مالی اتحادیه اروپا هم وجود داره و از نظر توسعه نرم‌افزار دستمون رو باز می‌ذاره.
نرم‌افزار P3pper (که از اینجا به بعد بهش می‌گم «فلفل») از خیلی جهات با نرم‌افزارهای برنامه‌ریزی متعارف، مثل پراجکت و پریماورا، فرق داره. بعضی از مهم‌ترین تفاوت‌هایی که الان یادم میاد رو در ادامه توضیح می‌دم.
سادگی
سعی شده نرم‌افزار تا جای ممکن ساده باشه، طوری که استفاده ازش محدود به متخصص‌های برنامه‌ریزی نباشه و مدیر پروژه و سایر ذی‌نفعان هم بتونن باهاش کار کنن. البته در ادامه می‌بینین که با وجود این‌که بعضی قابلیت‌های متداول در این نرم‌افزار وجود ندارن، قابلیت‌های دیگه‌ای در نظر گرفته شده که خیلی پیشرفته‌تر و پیچیده‌تر از اون چیزهایی که در نرم‌افزارهای دیگه هست. با این حال، این پیچیدگی در پشت صحنه‌س و نه برای کاربر. هدف اینه که نرم‌افزار برای کاربر ساده باشه، نه برای توسعه دهنده.
رویکرد کل به جز
نرم‌افزاری مثل پراجکت ناخودآگاه کاربر رو تشویق می‌کنه که جز به کل فکر کنه، که برای خیلی پروژه‌ها مسئله ایجاد می‌کنه. پریماورا کمتر از پراجکت چنین حالتی داره، ولی باز هم رویکرد جز به کل توش خیلی قویه. فلفل از این نظر کاملا برعکسه و کاربر رو تشویق می‌کنه که کل به جز فکر کنه و امکاناتی در اختیارش می‌ذاره که این کار رو تا جای ممکن راحت کنه.
یکپارچگی
فلفل یه نرم‌افزار آنلاینه که توش کاربرهای مختلف می‌تونن با هم همکاری کنن. محدود به پروژه هم نیست و توش عناصر پرتفولیو و طرح هم وجود داره. به عنوان مثال، کارفرمایی ممکنه طرحی داشته باشه با چهار پروژه که هرکدوم پیمانکار خودش رو داره. هرکدوم از این پیمانکارها می‌تونن پروژه خودشون رو تو پرتفولیوی خودشون تعریف کنن و برای اون پروژه به کارفرما هم دسترسی بدن. از اون طرف، کارفرما می‌تونه یه طرح برای خودش تو فلفل بسازه و پروژه‌هایی که بهش دسترسی داده شده رو اونجا سازمان‌دهی کنه.
در کنار تمام این‌ها، همونطوری که کاربر می‌تونه بین عناصر داخل یه پروژه رابطه ایجاد کنه، می‌تونه بین اون عناصر و عناصر خارجی هم روابط ایجاد کنه. مثلا ممکنه رابطه‌ای بین یکی از تحویل‌شدنی‌های یکی از چهار پیمانکار و یکی از تحویل‌شدنی‌های پیمانکار دیگه‌ای وجود داشته باشه؛ این رابطه می‌تونه مستقیما تو برنامه پیمانکار دوم وارد بشه، حتی بدون این‌که به برنامه پیمانکار اول دسترسی داشته باشه.
تحویل‌شدنی‌های فی‌البداهه
سطوح بالای برنامه‌هایی که تو فلفل تهیه می‌شن متعین و زمان‌بندی شده هستن، یعنی مبتنی بر شبکه روابط، مدت‌زمان‌ها و امثال اون‌ها. با این حال، اگه کاربر بخواد می‌تونه سطوح پایین برنامه رو نامتعین تعریف کنه، که می‌شه چیزی مشابه روندی که خیلی‌ها دارن و توش کارهای پروژه رو تو تخته‌های کانبان مانند مدیریت می‌کنن، یعنی توالی خاصی بین عناصر وجود نداره و عنصر بعدی بر اساس اولویت‌های لحظه‌ای انتخاب می‌شه. البته قطعا این دو حالت کاملا با هم یکپارچه هستن و به شکل‌های مختلف به همدیگه کمک می‌کنن. این مورد تو پروژه‌های چابک کاملا لازمه و علاوه بر اون تو سطوح پایین پروژه‌های متعین هم می‌تونه خیلی مفید باشه.
از طرف دیگه، هر بخشی از پروژه، طرح یا پرتفولیو رو می‌شه هم به صورت درختی و همراه با نموداری مشابه نمودار گانت دید و هم می‌شه اون رو به شکل تخت، مشابه چیزی که تو تخته‌های کانبان هست دید و به اون شکل با عناصر کار کرد.
تحویل‌شدنی‌های با دامنه متغیر
هر تحویل‌شدنی یکی از دو حالت دامنه ثابت و دامنه متغیر رو می‌تونه داشته باشه. وقتی تحویل‌شدنی‌ای با دامنه ثابت معرفی بشه به این معنیه که عناصری که در اون لحظه زیرمجموعه‌ش هستن برای تحققش کافی هستن. اگه دامنه متغیر اعلام بشه به این معنیه که عناصر زیرمجموعه تحویل‌شدنی چیزهایی هستن که تا الان براش شناسایی کردیم و در آینده ممکنه اون‌ها رو کم و زیاد کنیم.
همونطوری که می‌تونین حدس بزنین این مشخصه بیشتر از هر چیز روی محاسبه پیشرفت اثر می‌ذاره. در نگاه اول ممکنه به نظر بیاد که کاربردش محدود به پروژه‌های چابکه، ولی در عمل تو سطوح پایین پروژه‌های متعین هم خیلی کاربرد داره.
عناصر انفعالی
هر تحویل‌شدنی یا مایل‌ستون می‌تونه فعال یا انفعالی باشه. عناصر فعال همون‌هایی هستن که پراجکت و پریماورا می‌شناسن. عناصر انفعالی، که تا حالا تو نرم‌افزار دیگه‌ای ندیدم، عناصری هستن که به طور خودکار تکمیل می‌شن.
این دو مورد مثال‌های خوبی از عناصری هستن که می‌تونن منفعل باشن:
- ده تحویل‌شدنی وجود داره که همگی پیش‌نیاز ده‌ها تحویل‌شدنی دیگه تو برنامه هستن. اگه بخواین برای همه این‌ها رابطه ایجاد کنین بی‌دلیل برنامه پیچیده می‌شه. یه راه حل خوب اینه که یه مایل‌ستون بسازیم، اون ده تحویل‌شدنی رو پیش‌نیاز مایل‌ستون کنیم، و مایل‌ستون پیش‌نیاز تحویل‌شدنی‌های دیگه بشه. اینطوری برنامه خیلی خواناتر و ساده‌تر می‌شه. تو این حالت، اون مایل‌ستون هویت مستقلی نداره و به محض این‌که پیش‌نیازهاش کامل بشن باید خودش هم کامل شده در نظر گرفته بشه، بدون این‌که لازم باشه کاربر دستی به اون مایل‌ستون پیشرفت بده.
- وقتی پیش‌نویس P3.express منتشر شد، یک ماه زمان داده شد که هر کسی مایله در موردش نظر بده. اینجا یه تحویل‌شدنی داریم برای نظرهای عمومی برای پیش‌نویس. این تحویل‌شدنی یه ماه مدت زمان داره و پیش‌نیازهای خاص خودش رو هم داره. با این حال، این تحویل‌شدنی انفعالیه و هروقت یک ماه زمانش بگذره باید به طور خودکار کامل بشه و پس‌نیازهاش شروع بشن، بدون این‌که نیازی باشه بهش دستی مقدار بدیم.
این قابلیت هم بعضی از کارهای کنترلی رو راحت می‌کنه و جلوی اشتباه رو می‌گیره و هم به بعضی محاسبات پیشرفته عملکرد پروژه کمک می‌کنه.
محاسبات پیشرفت
محاسبه پیشرفت بر اساس وزن نسبی آیتم‌ها انجام می‌شه و پیشرفت برنامه‌ریزی شده و واقعی الگوی مشابهی دارن (که متاسفانه همیشه تو پراجکت و خصوصا تو پریماورا امکان‌پذیر نیست). برای عناصر پایین‌ترین سطح برنامه که قراره مقدار پیشرفت دستی بگیرن، به جای این‌که مقدار پیشرفت دریافت بشه، وضعیتشون دریافت می‌شه (در انتظار پیش‌نیاز، قابل انجام، در حال انجام، تکمیل، تکمیل و تایید شده) و بر اون اساس به طور خودکار پیشرفت صفر، ۸۰ درصد یا ۱۰۰ درصد می‌گیرن. این محدودیت به این خاطر اضافه شده که جلوی یه سری از مشکل‌های رایج در برنامه‌ریزی و کنترل رو بگیره. پیشرفتهای پله‌ای برای عناصر کوچیک همیشه گزینه بهتری هستن.
مقدارهای برنامه‌ریزی شده به طور دینامیکی بر اساس آخرین وضعیت شبکه برنامه و بدون بیس‌لاین (به مفهوم سنتیش) محاسبه می‌شن، که هم نقاط قوت خاص خودش رو داره و هم نقاط ضعف. البته نقاط قوتش خیلی بیشترن.
در نهایت، تاریخ احتمالی پایان پروژه هم با روش پیشرفتهای که الهام گرفته از Earned Schedule Analysis هست محاسبه می‌شه و در اختیار کاربر قرار می‌گیره.
شبکه روابط
فلفل فقط یک نوع رابطه رو می‌پذیره: FS
این محدودیت به این خاطر ایجاد شده که تنها رابطه کاملا عینی FS هست و تمام روابط دیگه‌ای که در برنامه‌ها استفاده می‌شن معمولا به خاطر برداشت‌های اشتباه استفاده می‌شن و وجودشون برنامه رو ضعیف می‌کنه.
عامل دیگه‌ای که باعث تضعیف برنامه‌ها می‌شه، وجود تاخیر و همپوشانی در رابطه‌هاس، و به همین خاطر اون هم تو فلفل وجود نداره.
قطعا می‌دونین که تو روش تحلیل مسیر بحرانی دو مسیر رفت و برگشت تو محاسبات وجود داره و با ترکیب خروجی این دو، مقدار شناوری محاسبه می‌شه و بر اساس شناوری‌ها بحرانی بودن فعالیت‌ها تعیین می‌شه. تمام این محاسبات کاملا وابسته به کیفیت شبکه روابط هستن و واقعیت ناخوش‌آیند اینه که اکثر برنامه‌ها شبکه مناسبی ندارن و خروجی‌ای که به عنوان مسیر بحرانی می‌گیرن واقعی و کمک کننده نیست. تو این حالت اتکا کردن به این اطلاعات می‌تونه به پروژه صدمه بزنه. به این خاطر، فلفل کلا از روش مسیر بحرانی استفاده نمی‌کنه و نه مقدار شناوری محاسبه می‌کنه و نه فعالیت‌ها رو به عنوان بحرانی معرفی می‌کنه. در عوض اون‌ها، مکانیزم‌های دیگه‌ای برای جلب توجه به نکات مهم پروژه داره.
عنصر دیگه‌ای که به شدت باعث ضعف برنامه‌ها می‌شه، قید تاریخ هست. تو فلفل فقط می‌شه برای مایل‌ستون‌ها قید تاریخ وارد کرد. اگه مثلا مجوزی وجود داره که می‌دونیم در تاریخ خاصی صادر می‌شه، باید برای اون یه مایل‌ستون با قید تاریخ ساخت و اون رو پیش‌نیاز تحویل‌شدنی‌هایی کرد که وابسته به اون مجوز هستن، نه این‌که قید رو مستقیما به تحویل‌شدنی‌ها داد. این محدودیت خیلی می‌تونه به خوش‌ساخت شدن برنامه کمک کنه.
پیگیری‌ها
اگه P3.express رو مطالعه کرده باشین می‌دونین که در اون ریسک‌ها، مسایل، درخواست‌های تغییر، درس آموخته‌ها، و برنامه‌های بهبود فرآیند همگی از یک جنس در نظر گرفته می‌شن: «مواردی که نیاز به پیگیری دارن». برای پیگیری اون‌ها هم یک فرآیند وجود داره، نه فرآیندهای متفاوت. این رویکرد کمک می‌کنه که روند کار ساده بشه.
فلفل علاوه بر شبکه تحویل‌شدنی‌ها، تو پیگیری موارد هم به کاربر کمک می‌کنه. موارد قابل پیگیری تو نرم‌افزار وارد می‌شن، می‌تونن زیرمجموعه پرتفولیو، طرح یا پروژه باشن، و حتی این امکان وجود داره که اون‌ها رو مستقیم به تحویل‌شدنی‌ها هم وصل کرد.
فلفل در آینده نه چندان دور منتشر می‌شه و کاملا رایگان خواهد بود. پیش از اون لازمه که با گروهی از افراد علاقه‌مند اون رو به دقت تست کنیم که مطمئن بشیم درست کار می‌کنه. یه نکته مهم اینه که بر خلاف پراجکت و پریماورا که در حالت عادی با یه پروژه سر و کار دارن که نهایتا چند هزار آیتم داره، فلفل یه نرم‌افزار آنلاینه که پروژه‌های تمام کاربران توشه و به خاطر امکاناتی مثل کنترل‌های سطح طرح و پرتفولیو و روابط بین پروژه‌ای، پروژه‌ها کاملا از هم مستقل نیستن و در نتیجه به جای چند هزار آیتم، با چند میلیون آیتم سر و کار داریم. به همین خاطر محاسبات باید کاملا بهینه باشن و یکی از راه‌های بهینه‌سازی اینه که تو هر حالتی حداقل محاسبات روی حداقل تعداد آیتم انجام بشه. مشکلی که می‌تونه پیش بیاد اینه که جایی از نرم‌افزار نوع خاصی از محاسبه که باید اجرا می‌شده از قلم افتاده باشه. پیدا کردن امثال این مواردی هستن که نیاز به کمک داوطلبان دارن.
کارمون احتمالا دو هفته دیگه شروع می‌شه و حدود چهار تا شش هفته ادامه پیدا می‌کنه. تو اون مدت باید به اتفاق پروژه‌های مختلف رو تو فلفل پیاده‌سازی کنیم و باهاشون کار کنیم تا مشکل‌های احتمالی پیدا بشن. در اون مدت احتمالا هفته‌ای سه بار جلسه آنلاین هم باید داشته باشیم (شب‌ها) که همگی به اتفاق در مورد مسایل صحبت کنیم.
تعداد افرادی که به طور جدی با نرم‌افزارهای برنامه‌ریزی کار می‌کنن در ایران خیلی زیادتر از اکثر کشورهای دیگه‌س و به همین خاطر تصمیم گرفتیم که این تیم صرفا از متخصص‌های ایرانی باشه. برای این تیم نیاز به چهار نفر خبره در برنامه‌ریزی داریم و دو نفر که آشنایی خیلی زیادی با نرم‌افزارهای برنامه‌ریزی مثل پراجکت و پریماورا ندارن ولی تجربه کار در پروژه‌هایی که از تخته کانبان استفاده می‌کنن دارن.
نمی‌دونم کلا بین خواننده‌های سایت چه تعداد متخصص نرم‌افزار هست، ولی در کنار مواردی که گفتم به دنبال یک متخصص هم هستین که نرم‌افزار رو از نظر امنیت ممیزی کنه. نرم‌افزار هم خیلی با نرم‌افزارهای تحت وب متداول فرق داره، از این جهت که حتی یک خط جاوا اسکریپت هم توش وجود نداره و کلا تو هدرها جاوا اسکریپت غیر فعال شده!
این کار مثل تمام کارهای دیگه در طرح P3.express داوطلبانه انجام می‌شه و حق‌الزحمه‌ای بابتش پرداخت نمی‌شه. نام کسانی که در این حوزه کمک کرده باشن برای قدردانی به طور دایمی به لیست contributorهای P3.express اضافه می‌شه.
اگه علاقه‌مند هستین با من از طریق info@khorramirad.com تماس بگیرین و خودتون رو معرفی کنین. اگه تعداد داوطلب زیاد باشه متاسفانه نمی‌تونیم از همگی کمک بگیریم و مجبوریم از بین داوطلب‌ها شش نفر رو انتخاب کنیم.
به‌روزرسانی ۱۴۰۰/۰۱/۳۱: عده زیادی برای این کار اعلام آمادگی کردن، که واقعا باعث خوشوقتیه. امروز مصاحبه‌ها رو خاتمه می‌دیم و تیم نهایی می‌شه. به خاطر استقبال زیاد، در ادامه این مرحله که تست هدفدار و همراه با کارگاه‌های عمومیه، یه مرحله تست آزاد هم اضافه خواهیم کرد که سایر افرادی که علاقه‌مند هستن هم بتونن به شکلی که مایل هستن به بهبود نرم‌افزار کمک کنن. ممنون از همگی.