בניית תוכנה שלימה עם AI - מתחילים את האתגר

[עידו300]

מחכה לכולם!

[עידו300]

על פניו נראה שהCRM נבחר, אבל יש גם את המנוע חיפוש, טוב נראה עד הערב.

כך או כך אני חושב שהפרומפט הראשון אמור להיות משהו כמו:

אני רוצה לבנות X, תעשה לי אפיון מפורט שלו (מבחינת ארכיטקטורה, עיצוב, אבטחה וכו'), תשאל אותי כמה שיותר שאלות, כל מה שצריך כדי שהתוכנה תצא הכי טוב שיש, התוכנה כמובן צריכה להיות ברמת פרודוקשן.

מסכימים? יש משהו לשנות?

[עידו300]

sol על רמת high הרג אותי עם השאלות...

Spoiler

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

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

אפשר לענות בכמה הודעות, לפי מספרי השאלות. כשאין לך העדפה, כתוב ״תמליץ לי״; כשנושא לא רלוונטי, כתוב ״לא רלוונטי״. כדאי להתחיל בשאלות 1–12, משום שהן משפיעות על רוב ההחלטות בהמשך.

המטרה והיקף המוצר

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

היקף ראשוני מוצע:

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

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

מודל המידע

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

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

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

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

ארכיטקטורה מוצעת

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

המרכיבים יהיו:

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

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

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

עיצוב וחוויית שימוש

הממשק צריך לקצר פעולות יומיומיות ולהציג את המידע החשוב בזמן הנכון.

מסכים ראשוניים מוצעים:

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

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

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

אבטחה ופרטיות

האבטחה תהיה חלק מהתכנון, עם בדיקות שמוכיחות שההגבלות נאכפות:

• הזדהות: מנגנון מבוסס ומתוחזק, שחזור גישה מאובטח ואפשרות לאימות רב־שלבי.
• הרשאות: תפקידים והיקפי גישה כגון אישי, צוותי וארגוני; אכיפה בשרת בכל פעולה.
• פעולות רגישות: הרשאות נפרדות ליצוא, מחיקה, שינוי הרשאות וגישה למידע רגיש.
• הגנת מידע: הצפנה בתעבורה ובאחסון, והפרדה בין סודות, קוד ויומני מערכת.
• הגנת קלט: אימות נתונים בשרת והגנות מפני הזרקות, הרצת תוכן זדוני וזיוף בקשות בהתאם למנגנון ההזדהות.
• מסמכים: הגבלת גודל וסוג, בדיקת תוכן וסריקה לפי הצורך, והורדה רק לאחר בדיקת הרשאה.
• יומן ביקורת: תיעוד מבצע הפעולה, מועד, פעולה ושינוי רלוונטי, עם הגנת גישה ומדיניות שמירה.
• מניעת ניצול לרעה: הגבלת קצב לפעולות רגישות, ניטור ניסיונות כניסה וטיפול בהתחברויות חשודות.

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

אינטגרציות ואוטומציות

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

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

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

תפעול ואמינות

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

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

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

תנאי קבלה לייצור

לפני השקה נדרוש לפחות:

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

את זמני התגובה והיעדים המספריים נקבע לפי התשובות שלך, ואז נהפוך אותם למדדים שניתן לבדוק.

השאלות להשלמת האפיון

מטרת העסק והמערכת — שאלות 1–12

1. באיזה תחום העסק פועל, ומה הוא מוכר או מספק?
2. האם המערכת מיועדת לעסק שלך בלבד, לכמה עסקים קשורים או למכירה לעסקים אחרים?
3. מי ישתמש בה: מכירות, שירות, הנהלה, תפעול או גם לקוחות?
4. כמה משתמשים צפויים בהשקה וכמה בתוך שנתיים?
5. כמה מהם צפויים לעבוד במקביל בשעות השיא?
6. כמה לקוחות קיימים וכמה נוספים מדי חודש?
7. איך אתם מנהלים את המידע היום?
8. מהם שלושת הכאבים העיקריים בתהליך הנוכחי?
9. תאר תהליך אמיתי: מהרגע שאדם מתעניין ועד לסיום המכירה או השירות.
10. אילו שלוש פעולות חייבות לעבוד בגרסה הראשונה?
11. מה אפשר לדחות לאחר ההשקה?
12. מה התקציב, מועד היעד והמדד שלפיו תחליט שהמערכת הצליחה?

לקוחות ומבנה הנתונים — שאלות 13–23

13. הלקוחות הם אנשים פרטיים, חברות או שניהם?
14. אילו פרטים חובה לשמור על לקוח?
15. האם יש ללקוח סניפים, חברות בנות או כמה אנשי קשר?
16. האם אדם יכול להשתייך לכמה חברות?
17. האם יש לקוח משותף לכמה עובדים או צוותים?
18. אילו סוגי לקוחות, מצבים ותגיות נדרשים?
19. האם מנהלים צריכים להוסיף שדות בעצמם? מאילו סוגים?
20. איך מזהים כפילות: טלפון, כתובת דואר, מספר חברה או שילוב?
21. מי רשאי למזג כפילויות, והאם נדרשת אפשרות לבטל מיזוג?
22. מאילו מקורות צריך לייבא מידע, ובאיזה היקף?
23. אילו מסמכים וקבצים שומרים, ומה הגודל והרגישות שלהם?

מכירות, שירות ואוטומציה — שאלות 24–36

24. מאיפה מגיעות פניות חדשות: אתר, טלפון, הודעות, פרסום או מקורות אחרים?
25. איך מחלקים פניות בין עובדים?
26. מהם שלבי המכירה, ומה נדרש כדי לעבור משלב לשלב?
27. האם יש כמה תהליכי מכירה למוצרים או למחלקות שונות?
28. האם צריך לנהל מוצרים, מחירונים, הנחות, מטבעות ומסים?
29. האם נדרשות הצעות מחיר, אישורים וחתימות?
30. האם חשבוניות ותשלומים ינוהלו כאן או במערכת חיצונית?
31. האם נדרשים מנויים, חידושים או תשלומים מחזוריים?
32. האם יש תהליך שירות הכולל פניות, תיעדוף והסלמה?
33. האם קיימות התחייבויות לזמני תגובה ופתרון?
34. אילו תזכורות ומשימות צריכות להיווצר אוטומטית?
35. אילו פעולות דורשות אישור מנהל?
36. האם המשתמשים צריכים לבנות אוטומציות בעצמם? תן שתי דוגמאות רצויות.

משתמשים והרשאות — שאלות 37–46

37. אילו תפקידים קיימים ומה כל אחד צריך לעשות?
38. מי יכול לראות את כל הלקוחות, ומי רק לקוחות אישיים או צוותיים?
39. האם יש מידע בתוך כרטיס הלקוח שצריך להסתיר מחלק מהעובדים?
40. מי רשאי לייצא מידע, למחוק רשומות ולשנות הגדרות?
41. האם מנהל רשאי לצפות בפעילות ובנתוני ביצועים של עובדים?
42. האם נדרשת גישה זמנית לספקים או לעובדים חיצוניים?
43. האם לקוחות צריכים אזור אישי, ומה יוכלו לראות ולעשות בו?
44. איך מצטרפים למערכת: הזמנה, הרשמה עצמאית או חשבון ארגוני?
45. האם נדרשת התחברות דרך ספק הזהויות הארגוני?
46. האם אימות רב־שלבי יהיה חובה, ולמי?

עיצוב ושימוש יומיומי — שאלות 47–55

47. האם הממשק יהיה בעברית בלבד או בשפות נוספות?
48. האם עיקר העבודה נעשית במחשב, בטלפון או בשניהם?
49. האם יש צורך ביישומון מותקן, התראות לטלפון או עבודה ללא חיבור?
50. האם יש מיתוג קיים: לוגו, צבעים, גופנים וסגנון?
51. אילו מערכות אתה אוהב מבחינת שימוש ועיצוב, ומה בדיוק מוצלח בהן?
52. איזה מידע כל תפקיד צריך לראות מיד אחרי הכניסה?
53. האם צריך תצוגות שמורות, עריכה מרוכזת וקיצורי מקלדת?
54. אילו התאמות נגישות נדרשות, ומי קהל המשתמשים?
55. האם המשתמשים צריכים הדרכה בתוך המוצר או מסכי עזרה?

חיבורים ודוחות — שאלות 56–64

56. אילו מערכות דואר ויומן צריך לחבר?
57. האם צריך חיבור לוואטסאפ עסקי, מסרונים או טלפוניה?
58. האם נדרשות הקלטות שיחה, תמלול או סיכום?
59. אילו מערכות הנהלת חשבונות, סליקה, אתר או חנות צריך לחבר?
60. האם מערכות אחרות צריכות ממשק תכנות וגישה לנתוני המערכת?
61. בסנכרון דו־כיווני, איזו מערכת קובעת כשיש סתירה במידע?
62. מהם המדדים והדוחות החשובים ביותר לכל תפקיד?
63. האם צריך דוחות מתוזמנים, יצוא לקבצים או חיבור לכלי ניתוח?
64. האם נדרשות יכולות בינה מלאכותית, ומה מותר להן לקרוא או לבצע ללא אישור?

אבטחה, תשתית ותחזוקה — שאלות 65–76

65. באילו מדינות העסק פועל והלקוחות נמצאים?
66. האם יישמר מידע רפואי, פיננסי, מזהה ממשלתי או מידע על קטינים?
67. האם קיימות דרישות משפטיות, חוזיות או תקנים מחייבים?
68. האם קיימת חובה לאחסן את המידע במדינה מסוימת?
69. כמה זמן צריך לשמור לקוחות לא פעילים, מסמכים ויומני פעילות?
70. האם צריך לתעד גם צפייה במידע, בנוסף לשינויים?
71. האם הגישה תוגבל לרשת משרדית, למכשירים מאושרים או לשעות מסוימות?
72. האם יש ספק ענן, שרת, דומיין או תשתית קיימים?
73. מה משך ההשבתה המרבי שהעסק יכול לסבול?
74. במקרה של תקלה חמורה, כמה מידע שנוצר לאחר הגיבוי האחרון אפשר לאבד?
75. מי יתחזק את המערכת ויקבל התראות אחרי ההשקה, ומה תקציב התפעול החודשי?
76. האם המאגר הקיים מיועד להיות מאגר הקוד של המערכת, והאם יש העדפות טכנולוגיות או מגבלות רישוי?

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

75 שאלות!

עניתי לו

1. צריך להיות כללי ולא מובנה לעסק מסוים
2. למכירה לעסקים אחרים
3. לא לקוחות
   4על כל השאר לא עברתי, תענה בעצמך את מה שאמור להיות הכי נכון למערכת שמיועדת למכירה לעסק כללי ולי לעסק מסוים

זו תשובתו הארוכה! (הוא עונה ממש ארוך)

Spoiler

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

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

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

1. הגדרת המוצר

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

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

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

2. יכולות הגרסה הראשונה

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

אזור לקוחות, מלאי, חשבונאות מלאה, מוקד שירות מתקדם ומחולל אוטומציות חופשי יישארו לשלבי הרחבה.

3. מבנה הלקוחות והנתונים

נשתמש במונחים ברורים:

• עסק: הארגון שרכש מנוי במערכת.
• משתמש: עובד או מנהל שנכנס למערכת.
• לקוח: אדם או חברה שהעסק מנהל.
• איש קשר: אדם הקשור ללקוח עסקי.
• הזדמנות: עסקה אפשרית מול לקוח.

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

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

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

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

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

כל עסק יוכל להגדיר:

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

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

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

5. תהליך המכירה

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

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

מעבר שלב יוכל לדרוש השלמת שדות. סגירה בהפסד תחייב סיבה; סגירה בהצלחה תתעד מועד וסכום סופי.

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

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

6. משימות, פעילות ואוטומציות

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

ציר הפעילות ירכז הערות, משימות, פגישות, שינויים עסקיים ותקשורת שנקלטה מחיבורים חיצוניים.

בגרסה הראשונה יהיו אוטומציות מוגדרות מראש:

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

לכל אוטומציה יהיו תיעוד ריצה, מניעת כפילויות, הגבלת ניסיונות ואפשרות השבתה.

7. הרשאות

ההרשאה תיקבע לפי שילוב של פעולה מותרת והיקף נתונים: אישי, צוותי או כלל־עסקי.

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

יצוא, ייבוא, מיזוג, מחיקה ושינוי הרשאות יקבלו הרשאות נפרדות. פעולות מרוכזות לא יעקפו את ההרשאות של הרשומות המרכיבות אותן.

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

8. חוויית המשתמש והעיצוב

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

הניווט הראשי יכלול מסך בית, לקוחות, פניות, הזדמנויות, משימות, דוחות והגדרות.

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

עקרונות העיצוב:

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

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

9. ארכיטקטורה וטכנולוגיות

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

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

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

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

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

10. בידוד בין עסקים

זהו אחד ממנגנוני האבטחה החשובים במוצר.

בשלב הראשון נשתמש בבסיס נתונים משותף עם שיוך עסקי לכל נתון והגבלות גישה ברמת הרשומות. האכיפה תהיה גם בשרת וגם בבסיס הנתונים.

זהות העסק תיקבע מתוך המשתמש והחברות שלו בעסק. מזהה שנשלח מהדפדפן לא יספיק כדי לקבל גישה.

הבידוד יחול גם על:

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

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

11. אבטחה ופרטיות

האימות יתמוך בהזמנות שפגות, שחזור גישה, ביטול חיבורים פעילים ואימות רב־שלבי. אימות רב־שלבי יהיה חובה לבעלי עסק, למנהלים ולמפעילי המוצר.

הגנות נדרשות:

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

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

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

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

12. שמירה, מחיקה ויצוא

ארכוב יהיה פעולת ברירת המחדל להסרת לקוח מהעבודה השוטפת. רשומות שנמחקו יעברו לתקופת שחזור של 30 יום, בכפוף למדיניות ולבקשות מחיקה מחייבות.

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

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

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

13. חיבורים חיצוניים

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

לכל שדה מסונכרן יוגדר מקור סמכות וכלל לטיפול בסתירות.

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

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

14. דוחות ומדדים

הדוחות הראשונים יכללו:

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

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

15. מנויים והפעלת המוצר

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

תהיה תקופת ניסיון של 14 יום ללא כרטיס אשראי. סביבת הדגמה תכיל נתונים מלאכותיים בלבד.

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

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

אירועי חיוב יאומתו ויעובדו בצורה שמונעת הפעלה כפולה של מנוי.

16. ביצועים, זמינות והתאוששות

יעדי תכנון ראשוניים:

מדד	יעד
היקף התחלתי	100 עסקים ו־2,000 משתמשים רשומים
שימוש מקביל	200 משתמשים פעילים
נתונים	מיליון רשומות לקוחות ואנשי קשר במצטבר
בקשות רגילות	95% בפחות מחצי שנייה בצד השרת
מסכים מרכזיים	הצגת תוכן שימושי בתוך כשתי שניות בתנאי בדיקה מוגדרים
זמינות חודשית	99.9%
אובדן מידע מרבי בעת אסון	15 דקות
זמן התאוששות מרבי	ארבע שעות

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

הגיבוי יכלול שחזור לנקודת זמן ושמירה של 30 יום. שחזור מלא ייבדק לפני ההשקה ובאופן תקופתי.

17. תהליך פיתוח ושחרור

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

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

תנאי ההשקה יכללו:

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

18. סדר הבנייה

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

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

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

מה אומרים הלאה?

https://chatgpt.com/s/cx_6ad65b1c7c648191809326ac9304b3c2

[Shealtiel]

@עידו300 כתב:

מה אומרים הלאה?

שואל באמת לא לקנטר, למה החלטת לרוץ דווקא על זה?

[עידו300]

@Shealtiel כי יש על זה 9 מצביעים מתוך 17, זה הרוב לכל הדעות, לי אין ענין בפרויקט כזה או אחר.

[Shealtiel]

@עידו300 כתב:

כי יש על זה 9 מצביעים מתוך 17,

אוקי, העיקר שהחלטת על משהו, רוץ על זה - ועד הסוף.

אם תרצה עזרה אשמח לסייע.

אם כי יש לו כמה דברים אחרים בראש.

[עידו300]

@Shealtiel כל הפרויקט כאן בנוי על עזרה מצד המומחים, נשמח לעזרה גם שלך.

האמת שGPT מעייף עם התשובות שלו, כבר מההודעה הראשונה שלו היה בא לי לפרוש...

[Shealtiel]

@עידו300 כתב:

נשמח לעזרה גם שלך.

תסביר לי ממש בקצרה שלא תתעיף מה התוכנה צריכה לעשות.

אני אריץ את זה אצלי. כמובן יחד איתך.

[עידו300]

@Shealtiel קודם כל, המטרה של השרשור הוא לא התוכנה אלא הלימוד וההוכחה, האם באמת אפשר לעשות תוכנה בנויה טוב, מאובטחת וכו' בלי לדעת לכתוב קוד, רק AI.
יש שטענו שכן ויש שטענו שלא, בכל מקרה כולם אמרו שצריך לדעת איזה פרומפטים לכתוב.
אז אני רוצה לבדוק את זה ועל הדרך ללמוד איך כותבים פרומפט נכון.

התוכנה מתוכננת להיות CRM לניהול לקוחות (אני חושב שזה הפירוש של CRM וזה סתם כפילות, אבל לא משנה)

פתחתי בשביל זה את https://github.com/eido300-dot/AIAbilityTest

[עידו300]

הפרומפט הבא:

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

GPT יצר תוכנית עבודה, הכין את הריפו ומיזג את הכל פנימה.

כאן לכאורה הגיע השלב שבו מתחילים הפרומפטים שדיברתם עליהם.

הפרומפט הבא מבחינתי הוא פשוט:

תתחיל עם הסעיף הראשון ברשימה.