با افزایش تعداد پروژه‌ها، فایل‌ها، تصمیم‌ها و مراحل تحویل، مدیریت کار دیگر فقط به یادداشت‌کردن چند Task محدود نمی‌شود.
هر پروژه مسیر خودش را دارد.
یک وب‌سایت WordPress با یک اپلیکیشن موبایل یا سیستم اختصاصی، مراحل یکسانی برای طراحی، توسعه، امنیت، SEO، تست و تحویل ندارد.
اگر این تفاوت‌ها فقط در ذهن تیم باقی بمانند، بخشی از کنترل کیفیت به حافظه افراد وابسته می‌شود.
NaarCode Project Manager از همین مسئله شکل گرفت.
هدف ساخت یک ابزار داخلی بود که بتواند پروژه را از لحظه ایجاد تا مراحل کنترل کیفیت و تحویل در یک ساختار مشخص نگه دارد.
این محصول همچنان در حال توسعه و تکمیل است و قابلیت‌های آن براساس نیازهای واقعی پروژه‌های NaarCode گسترش پیدا می‌کنند.
هدف؛ تبدیل استانداردهای کاری به یک سیستم قابل اجرا
داشتن یک Checklist در یک فایل متنی مفید است.
اما وقتی قرار باشد همان استاندارد روی پروژه‌های مختلف اجرا شود، به‌روزرسانی شود، وضعیت هر آیتم مشخص باشد و در نهایت بتوان کیفیت پروژه را اندازه‌گیری کرد، یک فایل ساده دیگر کافی نیست.
هدف Project Manager این بود که استانداردهای داخلی NaarCode به بخشی از خود جریان پروژه تبدیل شوند.
از Documentation به Workflow
به‌جای اینکه تیم در پایان پروژه به یک سند جداگانه مراجعه کند، Checklist باید از ابتدا همراه پروژه باشد.
نوع پروژه مشخص می‌شود.
ساختار مناسب ایجاد می‌شود.
وظایف و کنترل‌های مربوط به همان پروژه در اختیار کاربر قرار می‌گیرند.
و وضعیت آن‌ها مستقیماً روی پیشرفت و کیفیت پروژه تأثیر می‌گذارد.
Projects؛ هر پروژه یک فضای کاری مستقل
هسته اصلی سیستم، Project است.
هر پروژه اطلاعات، وضعیت، مراحل و فعالیت‌های خودش را دارد.
هدف این نبود که همه پروژه‌ها داخل یک لیست بزرگ از Taskها قرار بگیرند.
هر پروژه باید بتواند به‌عنوان یک Workspace مستقل دیده شود.
ساختار به‌جای پراکندگی
در یک فضای پروژه، اطلاعات اصلی، Checklist، وضعیت پیشرفت، فعالیت‌ها، یادداشت‌ها و فایل‌ها باید در کنار هم قرار بگیرند.
این ساختار کمک می‌کند وقتی بعد از چند روز یا چند هفته به پروژه برمی‌گردیم، برای فهمیدن وضعیت فعلی مجبور نباشیم بین چند ابزار و فایل مختلف جست‌وجو کنیم.
Project Wizard؛ شروع پروژه با ساختار درست
یکی از بخش‌های مهم سیستم، Wizard ایجاد پروژه است.
همه پروژه‌ها یکسان نیستند و نباید با یک Template ثابت آغاز شوند.
Wizard کمک می‌کند در ابتدای کار مشخص شود با چه نوع پروژه‌ای روبه‌رو هستیم و چه بخش‌هایی برای آن اهمیت دارند.
سؤال‌های درست در شروع پروژه
به‌جای ساخت یک پروژه خالی، سیستم می‌تواند براساس اطلاعات اولیه، ساختار مناسب را آماده کند.
برای مثال یک پروژه ممکن است شامل:
Frontend
Backend
Database
Authentication
SEO
Deployment
Mobile
یا Integrations باشد.
پروژه دیگری ممکن است فقط بخشی از این موارد را نیاز داشته باشد.
هدف این است که سیستم از همان ابتدا زمینه پروژه را بفهمد و فقط کنترل‌های مرتبط را فعال کند.
Dynamic Checklist؛ چک‌لیستی که با پروژه تطبیق پیدا می‌کند
یکی از مهم‌ترین بخش‌های Project Manager، Dynamic Checklist است.
Checklist نباید فقط یک لیست ثابت از چند ده یا چند صد مورد باشد.
اگر پروژه Mobile Application ندارد، بررسی Safe Area یا Keyboard Behaviour برای آن معنایی ندارد.
اگر پروژه Authentication ندارد، کنترل Session و Login نیز نباید به‌صورت بی‌دلیل نمایش داده شود.
فقط چیزهایی که واقعاً مربوط‌اند
ساختار Checklist براساس نوع و ویژگی‌های پروژه تنظیم می‌شود.
این کار دو مزیت دارد:
اول اینکه کاربر با یک لیست شلوغ و غیرمرتبط روبه‌رو نمی‌شود.
دوم اینکه کنترل کیفیت واقعی‌تر می‌شود، چون آیتم‌ها متناسب با همان پروژه انتخاب شده‌اند.
در نتیجه Checklist به‌جای اینکه یک سند عمومی باشد، به بخشی از منطق پروژه تبدیل می‌شود.
کنترل کیفیت؛ Done با Ready فرق دارد
یکی از مسائل مهم در مدیریت پروژه این است که «تمام‌شدن توسعه» الزاماً به معنی «آماده‌بودن برای تحویل» نیست.
ممکن است Feature پیاده‌سازی شده باشد، اما هنوز:
Responsive تست نشده باشد.
Error State بررسی نشده باشد.
SEO ناقص باشد.
Backup تست نشده باشد.
یا دسترسی کاربران به‌درستی کنترل نشده باشد.
Quality Score
برای ایجاد دید واضح‌تر نسبت به وضعیت واقعی پروژه، مفهوم Quality Score وارد سیستم شد.
پیشرفت می‌تواند نشان دهد چه مقدار از کار انجام شده است.
اما Quality Score قرار است سؤال دیگری را جواب دهد:
این پروژه تا چه حد استانداردهای مورد انتظار را پاس کرده است؟
این تفاوت بین Completion و Quality یکی از پایه‌های اصلی طراحی سیستم است.
Progress؛ درصدی که باید معنی داشته باشد
یک Progress Bar فقط زمانی مفید است که عدد پشت آن قابل اعتماد باشد.
اگر پیشرفت پروژه به‌صورت دستی و براساس حدس وارد شود، خیلی سریع ارزش خودش را از دست می‌دهد.
در Project Manager تلاش می‌شود Progress تا حد ممکن از وضعیت واقعی مراحل و Checklistها به دست بیاید.
دیدن وضعیت پروژه در یک نگاه
هدف این است که با بازکردن پروژه بتوان سریع فهمید:
چه مقدار از مسیر طی شده؟
کدام بخش‌ها هنوز باز هستند؟
کدام حوزه‌ها بیشترین ریسک را دارند؟
و پروژه چقدر به وضعیت قابل تحویل نزدیک شده است؟
این دید برای پروژه‌های طولانی اهمیت بیشتری پیدا می‌کند.
Templates؛ استانداردسازی بدون یکسان‌سازی همه پروژه‌ها
وقتی پروژه‌های مشابه بارها اجرا می‌شوند، بخشی از دانش قبلی نباید هر بار از صفر ساخته شود.
Templateها برای همین مسئله وارد طراحی شدند.
یک Template می‌تواند ساختار پایه پروژه و Checklistهای مرتبط را فراهم کند.
استفاده دوباره از تجربه پروژه‌های قبلی
هدف Template این نیست که همه پروژه‌ها دقیقاً یک مسیر را طی کنند.
هدف این است که چیزهایی که قبلاً یاد گرفته شده‌اند دوباره استفاده شوند.
مثلاً یک پروژه WordPress می‌تواند از مجموعه‌ای از کنترل‌های مرتبط با:
Performance
SEO
Security
Forms
Responsive Design
Deployment
و Backup شروع شود.
در حالی که یک اپلیکیشن موبایل مجموعه متفاوتی از کنترل‌ها خواهد داشت.
Activity؛ پروژه باید تاریخچه داشته باشد
در یک پروژه واقعی فقط وضعیت فعلی مهم نیست.
گاهی باید بدانیم چه چیزی تغییر کرده، چه کسی تغییری انجام داده و چه تصمیمی قبلاً گرفته شده است.
به همین دلیل Activity بخشی از معماری سیستم است.
حفظ Context پروژه
Activity Log کمک می‌کند تغییرات مهم در طول پروژه قابل دنبال‌کردن باشند.
در کنار آن، Notes و Files نیز بخشی از Workspace پروژه هستند تا Context موردنیاز در همان محل باقی بماند.
این موضوع مخصوصاً زمانی مهم است که پروژه بعد از مدتی دوباره باز شود یا فرد دیگری بخواهد وضعیت آن را بررسی کند.
کاربران و دسترسی؛ هر کسی نباید همه‌چیز را کنترل کند
از ابتدا سیستم فقط برای نمایش یک Dashboard طراحی نشده است.
ساختار Login و Users بخشی از نقشه V1 است تا سیستم بتواند در آینده توسط چند نقش مختلف استفاده شود.
دسترسی براساس مسئولیت
در یک سیستم مدیریت پروژه داخلی، همه کاربران الزاماً نباید به Settings یا مدیریت کاربران دسترسی داشته باشند.
ساختار نقش‌ها و Permissionها قرار است این تفاوت را کنترل کند.
این بخش نیز مانند سایر قسمت‌های محصول به‌صورت مرحله‌ای در حال تکمیل است.
رابط فارسی و RTL؛ سیستم داخلی هم باید تجربه کاربری خوبی داشته باشد
Project Manager برای استفاده واقعی ساخته می‌شود.
اگر یک ابزار قرار است هر روز باز شود، تجربه استفاده از آن اهمیت زیادی دارد.
رابط فارسی و RTL از ابتدا جزو ساختار اصلی پروژه بوده است، نه یک ترجمه اضافه‌شده در انتهای توسعه.
اطلاعات زیاد بدون شلوغی
یکی از چالش‌های اصلی در این نوع سیستم‌ها نمایش حجم زیادی از اطلاعات بدون تبدیل صفحه به یک Dashboard شلوغ است.
پیشرفت، Checklist، وضعیت، فعالیت‌ها و کنترل‌های مختلف باید در یک سلسله‌مراتب بصری مشخص قرار بگیرند.
هدف این است که کاربر بتواند سریع مهم‌ترین اطلاعات را پیدا کند، بدون اینکه تمام جزئیات همزمان روی صفحه فریاد بزنند.
معماری فنی؛ پایه‌ای برای یک ابزار داخلی قابل توسعه
NaarCode Project Manager با معماری وب مدرن در حال توسعه است.
Frontend با Next.js و React ساخته شده و TypeScript برای کنترل بهتر ساختار کد استفاده می‌شود.
PostgreSQL نیز برای لایه داده در نظر گرفته شده است.
سیستم باید با نیازهای جدید رشد کند
این پروژه ذاتاً محصولی است که با تجربه‌های جدید تغییر خواهد کرد.
ممکن است یک پروژه واقعی نیاز جدیدی برای Checklist، Template یا Workflow ایجاد کند.
بنابراین معماری باید بتواند این تغییرات را بدون تبدیل‌شدن به مجموعه‌ای از استثناهای پراکنده مدیریت کند.
هدف ساخت یک سیستم قابل گسترش است، نه یک Dashboard ثابت.
پروژه‌ای که از پروژه‌های واقعی یاد می‌گیرد
Project Manager هنوز در حال توسعه است.
این موضوع فقط به این معنی نیست که Featureهای بیشتری باقی مانده‌اند.
بخشی از طراحی محصول عمداً با استفاده واقعی از پروژه‌های NaarCode تکمیل می‌شود.
سیستم داخلی باید از واقعیت کار شکل بگیرد
بعضی نیازها فقط زمانی مشخص می‌شوند که یک پروژه واقعی وارد سیستم شود.
ممکن است یک Checklist بیش از حد طولانی باشد.
یک مرحله اهمیت بیشتری پیدا کند.
یا یک نوع پروژه به Template متفاوتی نیاز داشته باشد.
به همین دلیل Project Manager به‌جای اینکه یک‌باره به‌عنوان محصول «نهایی» طراحی شود، در یک چرخه مداوم استفاده، اصلاح و توسعه قرار دارد.
نتیجه؛ ساخت یک سیستم برای بهتر انجام‌دادن پروژه‌ها
هدف NaarCode Project Manager جایگزین‌کردن همه ابزارهای مدیریت پروژه موجود نیست.
این سیستم برای یک نیاز مشخص ساخته می‌شود:
مدیریت پروژه‌های NaarCode براساس شیوه کاری و استانداردهای خود NaarCode.
Project، Wizard، Dynamic Checklist، Progress، Quality Score، Templates و Activity همه بخشی از همین هدف‌اند.
قرار نیست فقط بدانیم چه کارهایی باقی مانده است.
قرار است بدانیم پروژه در چه وضعیتی قرار دارد، چه چیزهایی هنوز بررسی نشده‌اند و آیا واقعاً آماده تحویل است یا نه.
چیزی که از این پروژه یاد گرفتیم
ابزار مدیریت پروژه زمانی ارزش بیشتری پیدا می‌کند که فقط کار را ثبت نکند، بلکه روش انجام کار را هم بهتر کند.
سیستم باید دانش تیم را حفظ کند
هر پروژه مجموعه‌ای از تجربه‌ها و تصمیم‌ها تولید می‌کند.
اگر این دانش فقط در ذهن افراد باقی بماند، در پروژه بعدی بخشی از آن دوباره از صفر کشف می‌شود.
یکی از اهداف بلندمدت Project Manager این است که این تجربه‌ها به Template، Checklist و Workflow تبدیل شوند.
در این حالت، سیستم فقط پروژه‌ها را مدیریت نمی‌کند.
به مرور، بخشی از دانش عملی NaarCode را هم حفظ می‌کند.
Project Snapshot
Project NaarCode Project Manager
Type NaarCode Lab / Internal Product
Status In Development / Work in Progress
Scope Project Management · Dynamic Checklists · Quality Control · Progress Tracking · Templates · Activity · Notes · Files · User & Access Management
Platform Web Application
Technology Next.js · React · TypeScript · PostgreSQL
Current Direction Completing the V1 project workflow, refining dynamic quality checklists, improving progress and quality scoring, and expanding reusable project templates
