چگونه یک پروژهٔ نرم‌افزاری را ارزیابی کنیم؟

قبل از نوشتن خط کد، قبل از تمدید قرارداد تیم، و قبل از قول تاریخ انتشار به بازار، یک سؤال مشترک هست: این پروژه از نظر محصول، فنی و عملیاتی سالم است یا روی شن ساخته می‌شود؟ ارزیابی خوب پیش‌گویی آینده نیست؛ روشن کردن فرض‌ها، ریسک‌ها و معیارهای خروج است.

این مقاله چارچوب پایانی بلوک تصمیم سری است و رشته‌های ۱۱۵ تا ۱۲۰ را به هم وصل می‌کند: پشته، تازگی فناوری، زبان، دیتابیس، سایز سرور، و معماری. همچنین به مفاهیم قبلی سری — محیط‌ها، امنیت رازها، Git، مستند، CI/CD، مانیتورینگ — قلاب می‌زند تا ارزیابی فقط اسلاید معماری نباشد.

مخاطب اصلی صاحب محصول و مدیر فنی است؛ توسعه‌دهنده هم می‌تواند همین چک‌لیست را برای «آیا وارد این پروژه شوم؟» استفاده کند.

پاسخ کوتاه

پروژه را در نه لنز ارزیابی کنید: هدف و موفقیت، دامنه و اولویت، تیم و نقش‌ها، پشته و تناسب کار، داده و صحت، معماری و پیچیدگی، امنیت و رازها، تحویل و کیفیت، عملیات و بازیابی. برای هر لنز یک وضعیت سبز/زرد/قرمز با شاهد بنویسید. قرمز یعنی توقف یا کاهش دامنه؛ زرد یعنی برنامهٔ رفع قبل از مقیاس؛ سبز یعنی می‌توانید تعهد زمانی بدهید.

پروژهٔ «جذاب» با چند قرمز بدون صاحب، معمولاً گران‌تر از پروژهٔ خسته‌کننده با فرض‌های نوشته‌شده تمام می‌شود.

ارزیابی یعنی تبدیل امید به فرض قابل‌آزمون — و تعیین اینکه اگر فرض شکست، چه می‌کنید.

چارچوب نه لنزی

۱) هدف و تعریف موفقیت

اگر موفقیت فقط «سایت بالا باشد» باشد، هر تأخیری توجیه می‌شود و هیچ‌چیز تمام نمی‌شود. یک تا سه معیار قابل‌مشاهده بنویسید: مثلاً تکمیل سفارش آزمایشی end-to-end، زمان پاسخ صفحهٔ کلیدی زیر آستانه، یا تعداد کاربر فعال هفتگی. تاریخ را به معیار وصل کنید نه برعکس.

صاحب محصول باید بتواند در دو دقیقه بگوید نسخهٔ اول چه ارزشی به چه کسی می‌دهد. اگر نتوانست، ارزیابی فنی زود است.

۲) دامنه و برش نسخه

دامنهٔ باز دشمن تخمین است. برای نسخهٔ اول: Must / Should / Won't. Won't را بلند بگویید تا فشار لحظهٔ آخر دوباره به Scope Creep تبدیل نشود. وابستگی‌های بیرونی (درگاه پرداخت، پیامک، تأمین‌کننده) را با وضعیت قرارداد و محیط تست فهرست کنید.

۳) تیم و نقش‌ها

مقالات نقش‌های سری (۰۵۱–۰۵۸) را به‌عنوان چک‌لیست پوشش بخوانید: چه کسی اولویت می‌دهد، چه کسی معماری را نگه می‌دارد، چه کسی عملیات را؟ یک نفر بودن همهٔ نقش‌ها ممکن است؛ انکار کمبود نقش خطرناک است.

• Bus Factor برای مسیر پرداخت و استقرار چیست؟
• آیا Code Review واقعی دارید یا فقط Merge؟
• آیا دانش در README و Runbook است یا فقط در چت؟

۴) پشته و تناسب کار

از ۱۱۵–۱۱۷ استفاده کنید: زبان و فریم‌ورک با Use Case و مهارت تیم، نه با جدول محبوبیت. از ۱۱۶ برای فیلتر تازگی: Core محافظه‌کار، حاشیه آزمایش‌پذیر. شاهد خوب: Spike مسیر حیاتی و ADR یک‌صفحه‌ای.

۵) داده و صحت

مدل موجودیت، منبع حقیقت، نیاز تراکنش، و مسیر بکاپ/Restore را بدون نام برند بکشید؛ بعد با ۱۱۸ موتور را قفل کنید. اگر گزارش مدیریت با دادهٔ عملیاتی اختلاف دارد و کسی نمی‌داند کدام درست است، لنز داده قرمز است.

۶) معماری و پیچیدگی

با ۱۲۰ و استدلال Monolith First: آیا پیچیدگی توزیع‌شده را واقعاً نیاز دارید؟ مونولیت ماژولار برای بیشتر نسخه‌های اول کافی است. قرمز: میکروسرویس از روز صفر بدون مشاهده‌پذیری و بدون مرز دامنه.

۷) امنیت و رازها

حداقل: Secret در مخزن نیست، محیط‌ها جدایند، دسترسی کمترینی، HTTPS، و آگاهی از ریسک‌های رایج وب (نگاه به OWASP Top 10 به‌عنوان نقشهٔ تهدید نه چک‌لیست جادویی). اگر AI Coding استفاده می‌کنید، مرز دادن Secret و دسترسی سرور را از مقالات ۰۹۹ و ۱۰۰ جدی بگیرید.

۸) تحویل و کیفیت

آیا مسیر Local → Staging → Production تعریف شده؟ آیا CI روی مسیر اصلی اجباری است؟ آیا Review بیش از تأیید صوری است؟ نبود تست خودکار مطلق قرمز نیست؛ نبود هرگونه شبکهٔ ایمنی برای مسیر پول قرمز است.

۹) عملیات و بازیابی

مانیتورینگ بدون اقدام نمایش است؛ لاگ بدون همبستگی نویز است. حداقل: سلامت سرویس، هشدار برای خطای مسیر حیاتی، بکاپ با Restore تمرین‌شده، و یک Runbook برای دو حادثهٔ محتمل. سایز سرور را با ۱۱۹ از روی Workload ببینید نه از روی پکیج فروش.

دروازهٔ Go / No-Go

1. هر لنز را سبز/زرد/قرمز با یک شاهد بنویسید.
2. هر قرمز یا باید قبل از تعهد تاریخ بسته شود یا دامنه کوچک شود.
3. زردها صاحب و تاریخ رفع می‌گیرند.
4. اگر بیش از دو قرمز در امنیت/داده/عملیات ماند، تاریخ بازاریابی را عقب بکشید نه کیفیت را.

خروجی جلسهٔ ارزیابی باید یک صفحه باشد: وضعیت لنزها، تصمیم، و تاریخ بازبینی — نه سی صفحه ویکی که کسی نمی‌خواند.

ارزیابی پروژهٔ در حال حرکت (نه فقط شروع)

برای سیستم زنده، همان نه لنز را با سؤال «چه چیزی از آخرین بار بدتر شده؟» مرور کنید. رشد ترافیک بدون مانیتور، افزودن سرویس بدون قرارداد، و ماندن روی نسخهٔ بدون پشتیبانی، زردهایی‌اند که قرمز می‌شوند.

بازسازی بزرگ را فقط وقتی شروع کنید که درد اندازه‌گیری شده و برش مهاجرت دارید؛ بازنویسی کامل از صفر بدون معیار، ارزیابی نیست — فرار است.

اتصال به کل مسیر یادگیری سری

اگر از ابتدای سری آمده‌اید: مفاهیم پایه (داده، API، سرور، امنیت)، نقش‌ها و اسکرام، ابزار مدیریت، Git و کیفیت کد، UX، AI، کانتینر و تحویل، و حالا تصمیم پشته و ارزیابی. این مقاله جای entکه همه را دوباره تعریف کند؛ جای جمع‌بندی تصمیم است.

برای کسی که فقط همین پرونده را می‌خواند: از ۱۱۵ شروع کنید، ۱۱۷ و ۱۱۸ را برای انتخاب‌های برگشت‌ناپذیر بخوانید، ۱۲۰ را قبل از توزیع، و به اینجا برای دروازهٔ نهایی برگردید.

چک‌لیست یک‌صفحه‌ای قابل چاپ

• معیار موفقیت نسخهٔ اول نوشته شده است.
• Won't Have نسخهٔ اول توافق شده است.
• مالک محصول و مالک فنی مشخص‌اند.
• Use Case حیاتی و Stack در ADR ثبت شده است.
• منبع حقیقت داده و بکاپ روشن است.
• معماری با اندازهٔ تیم می‌خواند.
• Secret و دسترسی حداقل رعایت شده است.
• Staging شبیه و مسیر CI وجود دارد.
• مانیتور و Runbook مسیر حیاتی آماده است.

جمع‌بندی

ارزیابی پروژه یعنی نه لنز با شاهد، دروازهٔ رنگی، و شجاعت کم کردن دامنه وقتی قرمز می‌ماند. پشته، زبان، دیتابیس، سرور و معماری ابزارند؛ چارچوب تصمیم آن‌ها را به هدف محصول و توان تیم قفل می‌کند. با فرض نوشته‌شده جلو بروید و تاریخ بازبینی بگذارید.

اگر فقط یک کار بعد از خواندن این سری انجام می‌دهید، همین هفته یک صفحهٔ ارزیابی با نه لنز برای پروژهٔ جاری‌تان پر کنید و یک قرمز را ببندید.

منابع و مراجع

• Martin Fowler — Monolith First: https://martinfowler.com/bliki/MonolithFirst.html
• OWASP Top Ten: https://owasp.org/www-project-top-ten/
• GitHub Docs — About READMEs: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes
• Node.js Learn — Introduction: https://nodejs.org/en/learn/getting-started/introduction-to-nodejs
• Python.org — Applications: https://www.python.org/about/apps/
• PHP Manual — Introduction: https://www.php.net/manual/en/introduction.php
• Effective Go: https://go.dev/doc/effective_go

این نقطهٔ پایان منطقی بلوک تصمیم سری است؛ از اینجا به بعد، ارزش در اجرای چارچوب روی پروژهٔ واقعی است نه در جمع‌آوری ابزار بیشتر.