פרומט שבודק את האפליקציה בקפידה ומציע שדרוגים

משימת ניתוח מערכת והצעת Roadmap לפיתוח

אני מבקש לבצע סקירה מקיפה של המערכת הקיימת על בסיס הקוד בלבד, תוך קריאה וניתוח של כמה שיותר קבצים, מסכים, רכיבים, שירותים, תהליכים עסקיים ומבני נתונים.

הנחיות חשובות

אין לבצע שינויים בקוד.

אין ליצור קבצים חדשים.

אין למחוק, לעדכן או לשפר שום רכיב במערכת.

המטרה היחידה היא לקרוא, להבין, לנתח ולתעד.

יש להתבסס על המימוש הקיים בפועל ולא על הנחות.

יש לנסות להבין את המערכת מנקודת המבט של המשתמשים השונים, התהליכים העסקיים והארכיטקטורה הקיימת.



---

שלב 1 – מיפוי והבנת המערכת

יש לנתח ולהציג:

מטרת המערכת

מה הבעיה שהמערכת פותרת.

מי קהל היעד שלה.

אילו תהליכים עסקיים נתמכים בה.


סוגי משתמשים

יש לזהות ולהציג:

סוגי משתמשים במערכת.

הרשאות ותפקידים.

מסלולי עבודה (User Flows).

אינטראקציות בין סוגי המשתמשים השונים.


מיפוי מסכים

עבור כל מסך שנמצא:

שם המסך.

מטרת המסך.

סוג המשתמש המשתמש בו.

פעולות מרכזיות.

נתונים המוצגים בו.

קשר למסכים אחרים.



---

שלב 2 – ניתוח ארכיטקטורה

יש להציג:

Frontend

טכנולוגיות בשימוש.

מבנה רכיבים.

State Management.

Patterns מרכזיים.

תלות בין מסכים ורכיבים.


Backend

שירותים קיימים.

APIs.

Business Logic.

הרשאות ואבטחה.


Database

מבנה הנתונים.

ישויות מרכזיות.

קשרים בין טבלאות.

נקודות מורכבות במודל הנתונים.


אינטגרציות

שירותים חיצוניים.

APIs חיצוניים.

אוטומציות קיימות.



---

שלב 3 – זיהוי הזדמנויות לשיפור

לאחר הבנת המערכת בלבד, יש להציע פיתוחים חדשים בהתבסס על:

צרכי המשתמשים הקיימים.

תהליכים קיימים במערכת.

מידע שכבר נאסף במערכת.

ארכיטקטורה ותשתיות שכבר קיימות.


חשוב שכל הצעה תהיה מבוססת על יכולות קיימות במערכת ולא על רעיונות תאורטיים בלבד.


---

שלב 4 – תוכנית פיתוח מפורטת

עבור כל הצעה יש להציג:

תיאור הפיתוח

מה הפיתוח עושה.

למי הוא מיועד.

איזה צורך הוא פותר.


ערך עסקי

השפעה על משתמשים.

השפעה על אימוץ המערכת.

השפעה על יעילות תפעולית.

השפעה על הכנסות או הצלחת המוצר.


רכיבים מושפעים

מסכים קיימים.

שירותים קיימים.

טבלאות נתונים.

APIs.

הרשאות.


מורכבות פיתוח

יש לסווג:

נמוכה

בינונית

גבוהה


ולנמק.

הערכת מאמץ

יש לציין:

שעות פיתוח משוערות.

ימי עבודה משוערים.

משימות עיקריות.


סיכוני רגרסיה

עבור כל פיתוח יש לציין:

אילו אזורים במערכת עלולים להיפגע.

אילו תהליכים קיימים עלולים להשתנות.

אילו בדיקות נדרשות.

רמת הסיכון:

נמוכה

בינונית

גבוהה



השפעה על הארכיטקטורה

האם נדרש שינוי במבנה המערכת.

האם נדרש שינוי במסד הנתונים.

האם נדרש שינוי בהרשאות.

האם נדרש שינוי בתהליכים עסקיים.


המלצת מימוש

יש לציין:

Quick Win

שלב ביניים

פיתוח אסטרטגי



---

שלב 5 – Roadmap מסודר

בסיום יש להציג טבלה מסכמת הכוללת:

פיתוח	ערך עסקי	מורכבות	סיכון רגרסיה	מאמץ	עדיפות



ולסדר את ההמלצות לפי סדר עדיפות מומלץ לביצוע.


---

דגש סופי

לפני הצעת פתרונות או פיתוחים חדשים, יש להשקיע את מרבית המאמץ בהבנת המערכת הקיימת, הארכיטקטורה, המשתמשים והתהליכים העסקיים.
אין לבצע שינויים בקוד.
אין להציע שיפורים לפני שבוצע ניתוח מקיף ומעמיק של המערכת בפועל.
יש להתבסס על הקוד הקיים, מבנה המערכת וההתנהגות האמיתית של המוצר.