مدیریت پروژه با هوش مصنوعی؛ تجربهٔ G1Verify از 600 ساعت ساختن با چند ایجنت
خلاصه نوشته: در این مقاله، تجربهٔ G1Verify از مدیریت پروژه با چند ایجنت هوش مصنوعی را مرور می‌کنیم؛ از تعریف نقش انسان و ایجنت هماهنگ‌کننده تا فازبندی، ثبت وضعیت، مدیریت وابستگی‌ها و ارزیابی خروجی بر اساس شواهد. همچنین توضیح می‌دهیم چرا تست سبز همیشه به معنی نتیجهٔ درست نیست، چطور نوسان داده می‌تواند برداشت ما را تغییر دهد و چرا هر فاز باید خروجی، معیار پذیرش و شرط عبور مشخص داشته باشد. این روش هنوز کاملاً خودکار نیست، اما در تجربهٔ ما به هماهنگی بیشتر، دوباره‌کاری کمتر و مدیریت بهتر پروژه‌های چندایجنتی کمک کرده است.
جدول محتوا
در ۶۰ روز گذشته، بیش از ۶۰۰ ساعت با ابزارها و ایجنت‌های مختلف هوش مصنوعی روی توسعهٔ محصولاتمان کار کرده‌ایم. یکی از مهم‌ترین درس‌های این دوره، اهمیت حفظ پیوستگی پروژه بود: اینکه تصمیم اولیه، طراحی، کد و خروجی تحویل‌شده همچنان به یک مسئله پاسخ بدهند.
این تجربه در پروژه‌هایی مثل توسعهٔ G1Verify وچند پروژه دیگر شکل گرفت. پروژه های جانبی جی وان وریفای که یکی از آن پروژه ها، ترکیب ماتریس آیزنهاور و ماتریس تلاش–ارزش بود شروع شد و به محصولی برای مدیریت پروژه و امتیازدهی پویای تسک‌ها بر اساس وضعیت پروژه رسید. در G1Verify نیز توسعهٔ فروشگاه، اتوماسیون بازاریابی، تحلیل عملکرد و ابزارهای محتوا و سئو، نیاز به هماهنگی میان بخش‌های مختلف را پررنگ‌تر کرد.
با افزایش تعداد ابزارها، مسئله‌ای تکرارشونده داشتیم: فاصله میان خروجی مطلوب و آنچه تحویل می‌گرفتیم. هر بخش ممکن بود به‌تنهایی قابل قبول باشد، اما تصمیم‌ها، وابستگی‌ها و بعضی نیازمندی‌ها در رفت‌وبرگشت میان سشن‌ها جا می‌ماندند.
پاسخی که به‌تدریج برای این مسئله ساختیم، یک روش کاری مبتنی بر اسناد، نقشهٔ فازبندی و ایستگاه‌های ارزیابی بود. این مقاله روایت این تجربه است؛ نتایج آن را به‌عنوان مشاهدهٔ خودمان بیان می‌کنیم و ادعای سنجش کنترل‌شده یا تضمین برای همهٔ پروژه‌ها نداریم.
۱. هیئت مدیریت پروژه: انسان و ایجنت هماهنگ‌کننده
در روش ما، مدیریت پروژه حاصل همکاری انسان و ایجنت هماهنگ‌کننده است. برای توضیح این همکاری از تعبیر «هیئت مدیریت پروژه» استفاده می‌کنیم.
عارضه‌یابی، بررسی راه‌حل‌ها، تعریف پروژه، فازبندی، بررسی تحویل‌ها و ارزیابی بعدی، در همین همکاری انجام می‌شوند. تعریف مسئله و سنجش کیفیت نهایی با انسان است. ایجنت هماهنگ‌کننده در تحلیل، سازمان‌دهی اطلاعات، پیشنهاد مسیر و بررسی گزارش‌ها مشارکت می‌کند. ایجنت‌های تخصصی نیز کارهای طراحی و پیاده‌سازی را پیش می‌برند.
این مرزبندی اهمیت دارد، چون ممکن است یک ایجنت با اطمینان اعلام کند کار تمام شده، اما برداشت او از مسئله با هدف محصول یکسان نباشد. تصمیم نهایی باید به مسئلهٔ اصلی و شواهد خروجی برگردد.
چرخهٔ ما هنوز کاملاً خودکار نشده است. انسان همچنان در انتقال اطلاعات، هماهنگی و پذیرش خروجی نقش دارد، هرچند با ساختارمندشدن کار، رفت‌وبرگشت‌ها کمتر شده‌اند.
۲. اسناد مرتبط، با مرجعیت روشن
در سطح محصول، به سندی نیاز داریم که مسئله، کاربر، هدف، محدودیت‌ها و چرایی تصمیم‌ها را روشن کند. این سند به ایجنت کمک می‌کند هنگام مواجهه با ابهام، دلیل ساخت قابلیت را در نظر بگیرد.
در سطح اجرا، این تصویر باید به اسنادی تبدیل شود که هر مجری بتواند با آن کار کند. در نمونهٔ اسناد بررسی‌شدهٔ ما، سه سند مرتبط وجود دارد:
- نقشهٔ فازبندی: چه چیزی ساخته می‌شود، چه پیش‌نیازهایی دارد و در هر مرحله چه چیزی باید اثبات شود.
- دستورکار طراحی: چه صفحه‌ها و حالت‌هایی لازم است و طرح با چه معیاری پذیرفته می‌شود.
- دستورکار توسعه: چه چیزی پیاده‌سازی می‌شود، چه چیزی خارج از دامنه است و چه شواهدی باید تحویل داده شود.
شمارهٔ فازها میان اسناد هماهنگ است و گام‌های طراحی به فاز اجرایی مربوط ارجاع دارند. این ارتباط کمک می‌کند طرح تأییدشده و دستور پیاده‌سازی به یک نیازمندی اشاره کنند.
مرجعیت اسناد هم باید روشن بماند: سند محصول، هدف مورد توافق را ثبت می‌کند؛ نقشهٔ فازبندی، مسیر اجرا را؛ و کد و خروجی آزمون، شواهد وضعیت پیاده‌سازی را فراهم می‌کنند. اگر میان دستور و آنچه در کد دیده می‌شود تناقضی وجود داشته باشد، در دستورکار اجرایی ما از ایجنت خواسته شده آن را گزارش کند.
۳. فاز صفر: اول وضعیت موجود را بشناسیم
یکی از قواعد مشخص در اسناد ما این است: پیش از ساختن، بررسی کن چه چیزی از قبل وجود دارد.
در یک پروژهٔ در حال توسعه، ممکن است بخش دیگری از سیستم قبلاً همان مسئله یا بخشی از آن را حل کرده باشد. ساختن راه‌حل جدید بدون شناخت وضعیت موجود، می‌تواند منطق تکراری، ناسازگاری یا هزینهٔ نگهداری اضافی ایجاد کند.
به همین دلیل، فاز صفر در نمونهٔ ما صرفاً مرحلهٔ گزارش و اندازه‌گیری است. خروجی آن باید نشان دهد چه قابلیت‌هایی موجودند، چه وابستگی‌هایی داریم، تغییر پیشنهادی بر کدام بخش‌ها اثر می‌گذارد و چه چیزهایی از محیط فعلی قابل بررسی نیستند.
اگر اطلاعاتی در دسترس نیست، باید همان نادانسته ثبت شود. تبدیل ابهام به حدس قطعی، پایهٔ ضعیفی برای فازبندی می‌سازد.
در سند استاندارد عملکردِ پروژهٔ دیگری از همین مجموعه تجربه‌ها، فاز صفر یک وظیفهٔ مکمل دارد: ثبت خط پایه. پیش از تغییر، باید وضعیت نسخهٔ در حال سرویس‌دهی را ثبت کنیم تا بعداً مقایسه ممکن باشد. این سند شامل درخواست ثبت مرجع بصری، اندازهٔ منابع و سنجه‌های عملکرد است؛ خودِ سند، گزارش اجرای این اندازه‌گیری‌ها نیست.
درس قابل انتقال به پروژه‌های دیگر این است که هر مقایسه باید نسخه، محیط، روش و شرایط اندازه‌گیری مشخص داشته باشد. برای سنجه‌های نوسانی نیز تکرار آزمون و روش خلاصه‌سازی نتیجه باید معلوم باشد. نتیجهٔ یک اجرای سریع‌تر به‌تنهایی برای نتیجه‌گیری کافی نیست.
خط پایه را می‌توان با مشاهده و اندازه‌گیری نسخهٔ زنده ثبت کرد؛ آزمونی که عمداً خرابی ایجاد می‌کند باید روی نسخهٔ آزمایشی و قابل بازگشت انجام شود.
۴. نقشهٔ فازبندی باید شرط عبور داشته باشد
یک نقشهٔ اجرایی مفید، برای هر مرحله خروجی و معیار پذیرش تعیین می‌کند. در اسناد ما، شروع فاز بعد به تأیید ایستگاه قبلی وابسته است.
هر فاز باید روشن کند:
- چه خروجی‌ای می‌خواهیم؟
- چه پیش‌نیازهایی لازم است؟
- در این مرحله چه کاری انجام نمی‌شود؟
- خروجی چگونه بررسی می‌شود؟
- چه گزارشی باید به هیئت مدیریت برگردد؟
- در چه شرایطی باید متوقف شویم یا همان مرحله را اصلاح کنیم؟
برای نمونه، «نمایش یک پیام در محصول» می‌تواند عنوان یک تسک باشد. اما تعریف قابل ارزیابی باید رفتار بستن پیام، حالت خالی، زمان بارگذاری و نتیجهٔ توقف نمایش را نیز روشن کند. این یک مثال عمومی‌شده از ساختار دستورکارهای ماست و به‌تنهایی نشانهٔ اجرای موفق آن قابلیت نیست.
ارزش این ساختار در آن است که پیش از شروع، معنای «تمام‌شدن» را مشخص می‌کند. در نتیجه، صرف تولید کد یا ارائهٔ گزارش پایان کار، جای پذیرش خروجی را نمی‌گیرد.
سند پروژهٔ دیگر، بر توقف، گزارش و تأیید در هر ایستگاه تأکید می‌کند. در تفسیر این قاعده باید دو سطح را جدا نگه داریم: دستور به ایجنت برای توقف، و کنترل فنی‌ای که واقعاً امکان عبور را می‌بندد. برای مثال، آزمون خودکار فقط زمانی مانع ادغام می‌شود که نتیجهٔ آن واقعاً شرط لازم ادغام باشد. نوشتن چنین الزامی در یک سند، اثبات فعال‌بودن آن در ابزار نیست.
در قالب عمومی این روش، ایستگاه می‌تواند «پذیرفته»، «ردشده» یا «شواهد ناکافی» باشد. وضعیت سوم مجوز عبور نیست؛ لازم است معلوم شود چه شاهدی کم است و چه کسی باید آن را فراهم کند. این سه وضعیت، پیشنهاد صورت‌بندی برای روشن‌ترشدن فرایند هستند.
۵. طراحی و پیاده‌سازی، با تحویل مشخص
در مراحل دارای رابط کاربری، مسیر اسناد ما سه گام دارد: طراحی، تأیید انسانی طرح، سپس پیاده‌سازی همان فاز.
طرح باید حالت‌های موردنیاز را پوشش دهد؛ از جمله حالت خالی، بارگذاری، خطا و حالت‌های میانی مرتبط با قابلیت. فقط دیدن صفحه در حالت موفق، برای پذیرش طراحی کافی نیست.
در دستورکار توسعه هم آمده است که اگر طرح تأییدشده در دسترس نیست، ایجنت باید توقف کند و موضوع را اعلام کند. این قاعده از اجرای مبتنی بر حدس جلوگیری می‌کند.
طرح، مرجع رفتار و ظاهر مورد توافق است. پیاده‌سازی باید هم‌زمان با استانداردهای فنی پروژه سازگار باشد. کد نمایشی یک ابزار طراحی، صرفاً به دلیل شباهت بصری، آمادهٔ استفاده در محصول محسوب نمی‌شود.
در سند پروژهٔ دیگر، «دفتر ثبت استثناها» برای مواردی تعریف شده که پیاده‌سازی با قواعد طراحی موجود جور درنمی‌آید. مجری باید مورد را ثبت کند، دامنهٔ تکرار آن را نشان دهد و تا تعیین تکلیف، راه‌حل خارج از قاعده تولید نکند.
می‌توان این سازوکار را عمومی‌تر کرد: هر استثنا، دلیل، دامنهٔ اثر و تصمیم روشن داشته باشد؛ سپس تصمیم به دستورکار مرتبط برگردد. به این ترتیب، محدودیت‌های واقعی اجرا هم به اصلاح تصمیم‌ها کمک می‌کنند.
۶. تداوم پروژه میان سشن‌ها
بخشی از هماهنگی، وابسته به حفظ وضعیت پروژه خارج از متن گفتگو است. برای ادامهٔ کار باید بتوانیم بفهمیم چه تصمیمی گرفته شده، چرا گرفته شده، چه چیزی تغییر کرده و چه چیزی هنوز ناتمام است.
در نمونهٔ دستورکار اجرایی ما، ثبت کار جاری در سند تحویل و ارجاع به نسخهٔ کد و خروجی آزمون درخواست شده است. این‌ها شواهد قابل مراجعه برای ادامهٔ کار فراهم می‌کنند. خودِ درخواست ثبت گزارش، اثبات نمی‌کند که همیشه به‌درستی انجام شده؛ کیفیت گزارش نیز باید بررسی شود.
برای تبدیل این تجربه به یک الگوی قابل استفاده، پیشنهاد می‌کنیم بستهٔ انتقال وضعیت شامل هدف فعلی، تصمیم‌ها و دلایلشان، مرجع نسخهٔ کد، کارهای تمام‌شده و ناتمام، خطاهای شناخته‌شده، نتیجهٔ آزمون‌ها و گام بعدی باشد. این قالب پیشنهادی است، نه نقل عین یکی از اسناد پیوست.
سشن جدید باید وضعیت گزارش‌شده را با شواهد فعلی تطبیق دهد. خلاصه‌سازی می‌تواند اطلاعات مهم را حذف کند؛ انتقال وضعیت نیاز به بررسی دارد.
۷. هماهنگی میان ایجنت‌ها و مدیریت تغییر
در دستورکارهای ما، مالکیت کارها اهمیت دارد: ایجنت نباید فایل‌های متعلق به سشن دیگر را تغییر دهد. اگر کاری به حوزهٔ دیگری مربوط باشد، باید درخواست تحویل برای آن نوشته شود. همچنین برای بخش‌هایی که مجری مشترک دارند، ترتیب اجرای مشخص تعریف شده است.
این قواعد از فرض سادهٔ «هرچه موازی‌تر، بهتر» فاصله می‌گیرند. موازی‌سازی زمانی مفید است که مرز مسئولیت و وابستگی‌ها روشن باشند. سند مشترک به هماهنگی کمک می‌کند، اما به‌تنهایی مانع تعارض کد نمی‌شود؛ جداسازی محیط کار و بررسی ادغام نیز، متناسب با پروژه، لازم‌اند.
هنگام تغییر نیازمندی، هیئت مدیریت باید اثر آن را روی نقشهٔ فعلی بررسی کند: کدام خروجی قبلی تحت تأثیر قرار می‌گیرد؟ چه وابستگی‌هایی تغییر می‌کنند؟ کدام آزمون‌ها باید دوباره اجرا شوند؟ چه چیزی باید بازطراحی شود؟
برای عملی‌کردن این اصل، می‌توان تغییر را همراه با دلیل، فازهای متأثر و تصمیم نهایی ثبت کرد. این قالب، پیشنهاد تکمیلی این مقاله است؛ دادهٔ کافی برای روایت یک نمونهٔ مشخصِ اجراشده از مدیریت تغییر در این تجربه نداریم.
۸. پذیرش خروجی بر اساس شواهد
در تجربهٔ ما، گزارش ایجنت همراه با تست و ارزیابی انسانی مبنای بررسی خروجی بوده است.
در اسناد اجرایی، علاوه بر نتیجهٔ آزمون، درخواست شده که برای کنترل‌های تعریف‌شده نشان داده شود آزمون در صورت ایجاد خرابی مرتبط شکست می‌خورد. چنین بررسی‌ای باید در محیط آزمایشی و قابل بازگشت انجام شود. هدف، بررسی توانایی آزمون در کشف خطاست؛ سبزبودن تستی که خطای مربوط را تشخیص نمی‌دهد، اطمینان کافی ایجاد نمی‌کند.
همچنین در بعضی مراحل، مشاهدهٔ مستقیم رفتار محصول و مقایسهٔ قبل و بعد درخواست شده است. این بررسی‌ها جای هم را نمی‌گیرند: آزمون خودکار شرایط مشخصی را بررسی می‌کند و انسان باید تناسب خروجی با مسئله و تجربهٔ استفاده را بسنجد.
در طراحی نیز می‌توان معیارهایی مثل پوشش حالت‌ها، خوانایی و هماهنگی با سیستم طراحی داشت. قضاوت نهایی دربارهٔ کیفیت، به زمینهٔ محصول و هدف آن وابسته است. حضور انسان در این فرایند به ارزیابی هنری محدود نمی‌شود.
۹. حفظ کیفیت پس از تحویل
سند استاندارد پروژهٔ دیگر، پس از ایستگاه‌های مرحله‌ای، یک دروازهٔ دائمی پیشنهاد می‌کند: تغییرهای بعدی هم باید معیارهای پذیرفته‌شده را رعایت کنند. این بخش، مسئلهٔ حفظ دستاورد را وارد مدیریت پروژه می‌کند.
برای عمومی‌کردن آن، هر معیار مهم را به بررسی قابل تکرار تبدیل می‌کنیم و، هرجا امکان دارد، آن را به فرایند ادغام یا انتشار متصل می‌کنیم. اگر معیار تغییر می‌کند، دلیل تغییر و تأیید آن باید ثبت شود. پایین‌آمدن یک عدد در یک اجرا، به‌تنهایی دلیل کافی برای سخت‌ترکردن خودکار بودجهٔ آینده نیست؛ نوسان آزمون و نیازهای محصول هم باید دیده شوند.
همچنین باید روشن باشد چه چیزی نباید قربانی بهینه‌سازی شود. در این سند، دسترس‌پذیری و خوانابودن محتوای اصلی از قیود حفظ‌شونده‌اند. هدفی مانند کاهش حجم یا افزایش سرعت، باید در کنار حفظ قابلیت و تجربهٔ استفاده سنجیده شود.
برای بررسی عملکرد وب، دادهٔ آزمایشگاهی و دادهٔ کاربران واقعی نقش‌های مکمل دارند. اولی شرایط کنترل‌شده برای مقایسه و عیب‌یابی می‌دهد؛ دومی تنوع واقعی دستگاه، شبکه و رفتار کاربران را نشان می‌دهد. این دو را نباید معادل فرض کرد. توضیح Google دربارهٔ دادهٔ آزمایشگاهی و میدانی (پیوند بیرونی، در تب جدید باز می‌شود)
در آزمون تصویری نیز مرجع و محیط اجرای ثابت اهمیت دارند. اختلاف تصویر ممکن است از سیستم‌عامل، مرورگر یا نحوهٔ رندر ناشی شود؛ بنابراین حد پذیرش باید متناسب با آزمون تعریف شود. شباهت پیکسلی هم به‌تنهایی درستی رفتار محصول را اثبات نمی‌کند. راهنمای مقایسهٔ تصویری Playwright (پیوند بیرونی، در تب جدید باز می‌شود)
برای هر ایستگاه، این قالب عمومی گزارش قابل استفاده است:
| مورد | آنچه باید ثبت شود |
|---|---|
| موضوع بررسی | قابلیت یا شرط مورد آزمون |
| مرجع اجرا | نسخه، محیط و زمان بررسی |
| مبنای مقایسه | وضعیت پیش از تغییر، در صورت ارتباط |
| معیار پذیرش | حد عددی یا رفتار قابل مشاهده |
| اجرای بررسی | اجرا شد، اجرا نشد، یا ناقص ماند؛ همراه با تعداد حالت‌های بررسی‌شده |
| نتیجه | اندازه‌گیری یا مشاهدهٔ واقعی، با روش مشخص |
| اعتبار داده | کامل‌بودن خروجی، تعداد تکرارها و پراکندگی نتیجه در سنجه‌های نوسانی |
| اصلاح گزارش | ادعای قبلی، شاهد تازه و نتیجه‌ای که جایگزین شده است |
| شواهد | خروجی ابزار، تصویر یا گزارش قابل مراجعه |
| بررسی خود آزمون | آیا خطای مرتبط را در محیط آزمایشی تشخیص داد؟ |
| تصمیم | پذیرش، اصلاح یا تکمیل شواهد؛ همراه با مسئول تصمیم |
این قالب از قواعد گزارش‌دهی سند الهام گرفته و برای استفادهٔ عمومی تکمیل شده است. اعداد هدف و نمونه‌گزارش‌های داخل آن سند را به‌عنوان نتیجهٔ واقعی پروژه معرفی نمی‌کنیم.
۱۰. یک نمونهٔ واقعی: از موفقیت ظاهری تا اصلاح نتیجه‌گیری
در گزارش اجرای بخشی از یکی از پروژه‌ها، ایجنت اعلام کرد که برداشت قبلی‌اش از موفقیت انتشار را باید اصلاح کند. سه اجرا در فهرست گردش‌کارها موفق دیده می‌شدند، اما آزمون سایت زنده در همان اجراها خطا داشت: صفحه در عرض ۳۹۰ پیکسل، عرض محتوای قابل پیمایش ۴۴۳ پیکسل داشت؛ ۵۳ پیکسل سرریز افقی.
این روایت و اعداد از گزارش اجرای ایجنت نقل می‌شوند. در این مقاله، خروجی خام سامانهٔ CI و اندازه‌گیری مستقل را ارائه نمی‌کنیم؛ بنابراین دامنهٔ ادعا، آن چیزی است که در گزارش ثبت شده است.
مشکل فقط در چیدمان صفحه نبود. طبق گزارش، اجازهٔ نادیده‌گرفتن خطا روی کل یک جاب انتشار قرار گرفته بود. همان جاب، آزمون‌های سایت زنده را هم اجرا می‌کرد؛ در نتیجه، شکست آزمون به وضعیت نهایی اجرای گردش‌کار منتقل نمی‌شد.
در ادامهٔ بررسی، چند ضعف دیگر در مسیر ارزیابی گزارش شد:
- بعضی تغییرهای اسکریپت و تست، به‌دلیل فیلتر مسیرها، اصلاً اجرای تازه‌ای از گردش‌کار ایجاد نمی‌کردند.
- آزمونی برای سرریز صفحه وجود داشت، اما فقط دستی اجرا می‌شد و به مسیر بررسی پیش از انتشار متصل نبود.
- بررسی هم‌ترازی آزمون‌های محلی و CI فقط یک جهت را پوشش می‌داد؛ بعضی آزمون‌های محلی در CI اجرا نمی‌شدند.
- یک بار هم ابزار به‌دلیل مسیر نامعتبر مرورگر، پیش از سنجش متوقف شد. پیام خروجی به‌اشتباه از خطای محصول خبر می‌داد، درحالی‌که تعداد حالت‌های سنجیده‌شده صفر بود.
این موارد نشان می‌دهند بررسی کیفیت، خود به بررسی نیاز دارد: آیا آزمون اجرا شد؟ روی نسخه و محیط درست بود؟ دامنهٔ مورد انتظار را پوشش داد؟ و اگر شکست خورد، مسیر تحویل واقعاً متوقف شد؟
طبق همان گزارش، دامنهٔ تحمل خطا محدود شد، آزمون سرریز به اجرای محلی و CI متصل شد و بررسی هم‌ترازی آزمون‌ها در هر دو جهت تکمیل شد. برای بعضی از این کنترل‌ها نیز ایجاد عمدی خطای مرتبط و قرمزشدن آزمون گزارش شده است.
اصلاح چیدمان، عرض قابل پیمایش صفحه را در بررسی محلی از ۴۴۳ به ۳۹۰ پیکسل رساند. سپس نتیجهٔ بررسی ۲۴ صفحه در دو عرض، یعنی ۴۸ حالت محلی، بدون سرریز گزارش شد. در پایان متن، موفقیت آزمون سرریز روی نسخهٔ زنده نیز اعلام شده است؛ آن ۴۸ حالت را نباید به‌اشتباه ۴۸ سنجش روی سایت زنده معرفی کنیم.
| موضوع | وضعیت ثبت‌شده در گزارش |
|---|---|
| سرریز صفحهٔ اصلی در عرض ۳۹۰ پیکسل | ۵۳ پیکسل؛ پس از اصلاح، در بررسی محلی صفر |
| دامنهٔ بررسی محلی پس از اصلاح | ۲۴ صفحه × ۲ عرض؛ ۴۸ حالت بدون سرریز |
| بررسی نسخهٔ زنده در پایان گزارش | موفقیت آزمون سرریز اعلام شده است |
| حجم HTML صفحهٔ اصلی، طبق مقایسهٔ پایانی گزارش | از ۲۲۰٬۲۱۷ به ۱۲۱٬۸۶۶ بایت |
| نتیجهٔ LCP در ادامهٔ کار | اندازه‌گیری انجام شد، اما ادعاهای بهبود و افت زمانی در گزارش بعدی به‌علت نوسان نتایج پس گرفته شدند |
کاهش حجم HTML، نتیجه‌ای متفاوت از بهبود LCP است. عدد حجم در جدول مربوط به همان مقطع گزارش اول است؛ در ادامهٔ کار، محتوا و نحوهٔ بارگذاری نیز تغییر کرده‌اند. کاهش حجم حاصل مجموعه‌ای از تغییرهاست و نمی‌توان آن را به یک اصلاح یا به روش مدیریت پروژه به‌تنهایی نسبت داد.
گزارش‌های بعدی، بخش مهم‌تری به این نمونه اضافه کردند: ابتدا LCP صفحهٔ اصلی موبایل از ۲٬۳۹۶ به ۲٬۹۹۶ میلی‌ثانیه گزارش شد. بعد از تغییرهای بعدی، عدد ۲٬۳۰۴ ثبت شد و ایجنت از بهبود FCP هم خبر داد. اما تکرار اندازه‌گیری روی کدی تقریباً یکسان، نتیجه را تغییر داد: LCP صفحهٔ اصلی یک بار ۲٬۳۰۴ و بار دیگر ۲٬۷۲۴ میلی‌ثانیه ثبت شد؛ ۴۲۰ میلی‌ثانیه اختلاف.
ایجنت در گزارش آخر صریحاً ادعای بهبود ۵۵۶ میلی‌ثانیه‌ای FCP و تفسیر قطعی افت ۶۰۰ میلی‌ثانیه‌ای قبلی را پس گرفت. مسئله این نبود که عددی ثبت نشده؛ مسئله، کافی‌نبودن شواهد برای نسبت‌دادن آن اختلاف به تغییر کد بود.
در این گزارش، قاعده‌ای داخلی برای مقایسهٔ تغییر با نوسان آزمون ذکر شده است. آن قاعده و برآورد نوسان را نمی‌توان بدون دادهٔ خام و روش آماری به یک استاندارد عمومی تبدیل کرد. درس قابل انتقال این است که پیش از نتیجه‌گیری، تکرارپذیری، شرایط آزمون و پراکندگی نتایج بررسی شوند. مستندات Lighthouse هم دربارهٔ تغییر نتایج حتی بدون تغییر کد هشدار می‌دهند و کنترل محیط و تکرار اندازه‌گیری را توصیه می‌کنند. راهنمای رسمی نوسان نتایج Lighthouse (پیوند بیرونی، در تب جدید باز می‌شود)
تعداد درخواست‌های تا LCP، در دو اجرای بعدی ۹ گزارش شد؛ در خط پایه ۲۰ بود. این یک مشاهدهٔ مشخص در اجراهای گزارش‌شده است، نه اثبات بی‌نوسان‌بودن این سنجه یا مقدار معینی از بهبود سرعت. ایستگاه عملکرد هم در پایان این گزارش‌ها بسته نشده است.
هم‌زمان، خود ابزار اندازه‌گیری نقص دیگری داشت: زمان LCP ثبت می‌شد، اما عنصر مربوط به آن در خروجی نهایی منتقل نمی‌شد. مقدار خالی هم خطا محسوب نمی‌شد. طبق گزارش، مسیر انتقال داده اصلاح و آزمونی اضافه شد که حذف عمدی آن انتقال را تشخیص می‌داد. پس از آن، عنصر LCP در نتایج ثبت شد. برای مدیریت پروژه، این نمونهٔ روشنی از ضرورت بررسی کامل‌بودن شاهد است: ابزار باید همان اطلاعاتی را تحویل دهد که معیار پذیرش به آن وابسته است.
گزارش همچنین تفاوت پیش‌نمایش و محصول زنده را آشکار کرد؛ بعضی بخش‌های تولیدشده در محیط واقعی، در پیش‌نمایش وجود نداشتند. نتیجهٔ خوب روی یک پیش‌نمایش ناقص، همهٔ رفتارهای محصول را پوشش نمی‌دهد. دامنهٔ هر آزمون باید دقیقاً معلوم باشد.
یک درس دیگر در همین گزارش، بازگشت اصلاحات پس از اجرای مولد بود. تغییر روی خروجی تولیدشده با بازتولید فایل‌ها از بین می‌رفت؛ گزارش توضیح می‌دهد که اصلاح به مولد منتقل و اجرای تکراری آن بررسی شد. برای مدیریت پروژه، معنایش روشن است: محل اصلاح باید علت تولید خروجی را پوشش دهد، وگرنه «تمام‌شدن» یک تسک ممکن است با اجرای بعدی از بین برود.
از این نمونه، یک قاعدهٔ اجرایی استخراج می‌کنیم: «اجرا نشد»، «اجرا شد و رد شد» و «اجرا شد و پذیرفته شد» باید وضعیت‌های جدا باشند. اجرای ناقص یا نتیجهٔ ناپایدار نیز ممکن است تصمیم را در وضعیت «شواهد ناکافی» نگه دارد. گزارش موفقیت کلی جای بررسی الزامی را نمی‌گیرد.
قواعد منابع هم به تصمیم‌گیری نیاز داشتند. در ادامهٔ گزارش، اضافه‌شدن محتوای درخواستی یا یک اصلاح ساختاری باعث افزایش جزئی حجم شد و ایجنت از تغییر ثبت‌شدهٔ سقف و درخواست تصمیم خبر داد. این روایت را به معنی تأیید استثنا تلقی نمی‌کنیم. در الگوی پیشنهادی مقاله، عبور از سقف باید همراه با دلیل و اثر آن مطرح شود و تصمیم مسئول مشخص، به سند و آزمون برگردد؛ بهینه‌سازی یک عدد نباید بی‌صدا جای هدف محصول را بگیرد.
ارزش این تجربه برای ما در اصلاح‌پذیری تصمیم‌هاست: ادعای قبلی باید با آمدن شاهد تازه قابل بازبینی باشد، نتیجهٔ نامطمئن باز بماند و مرحلهٔ بعد بر اساس دانسته‌های معتبر انتخاب شود.
۱۱. چه چیزی بهتر شد و چه چیزی هنوز باز است؟
پس از ساختارمندشدن این روش، هماهنگی بیشتر، سرعت بالاتر، جاافتادن کمتر نیازمندی‌ها و اولویت‌بندی بهتر را مشاهده کردیم. مصرف منابع و دوباره‌کاری به‌طور محسوس کمتر شد و کیفیت خروجی‌ها بهتر شد.
برای این بهبودهای کلیِ فرایند، مقایسهٔ عددی کنترل‌شده ارائه نمی‌کنیم. اعداد مطالعهٔ موردی مربوط به یک خروجی فنی مشخص‌اند و میزان افزایش بهره‌وری همهٔ پروژه‌ها را اثبات نمی‌کنند. بنابراین درصد بهبود کلی، حذف کامل اتلاف یا رابطهٔ علّی قطعی به آن‌ها نسبت نمی‌دهیم.
خودکارسازی کامل چرخه هنوز انجام نشده است. هزینهٔ نگهداری اسناد و هماهنگی نیز باید در ادامه سنجیده شود. کمترشدن رفت‌وبرگشت‌ها به معنی حذف نیاز به نظارت و تصمیم‌گیری انسانی نیست.
برای دورهٔ بعد، شاخص‌هایی مثل دفعات بازشدن مجدد تسک، زمان شروع مؤثر یک سشن تازه، تعداد نیازمندی‌های جاافتاده و زمان صرف‌شده برای هماهنگی می‌توانند کمک کنند مشاهده‌های امروز را دقیق‌تر بسنجیم. این‌ها پیشنهاد برای اندازه‌گیری آینده‌اند.
یک نقطهٔ شروع عملی
برای امتحان‌کردن این روش، یک قابلیت مشخص را انتخاب کنید. هدف و محدودیت‌هایش را بنویسید، وضعیت موجود را بررسی کنید و آن را به چند مرحله با خروجی و معیار پذیرش روشن تقسیم کنید. دستورکار هر مجری را به همان مراحل متصل کنید، خط پایهٔ لازم را ثبت کنید و پس از هر مرحله، وضعیت و شواهد را بنویسید. کنترل‌های مهم را برای تغییرهای بعدی حفظ کنید و استثناها را با تصمیم روشن به اسناد برگردانید.
تجربهٔ ما نشان داد وقتی هدف، مسئولیت، وضعیت و معیار پذیرش روشن‌تر می‌شوند، کار با چند ابزار قابل مدیریت‌تر می‌شود. این همان ساختاری است که می‌خواهیم در همکاری انسان و ایجنت‌ها تقویت کنیم.