דוגמה למוקאפ של Web App שבניתי לקורסים דיגיטליים ו-E-commerce
3 משתמשים: גולש אורח, משתמש מחובר ואדמין
3 מסכים: מחשב, טאבלט ומובייל
פרסונה ראשית: נשים בישראל מעל גיל 60
עיצוב: צבעים נבחרו לאחר מחקר על הפרסונה ונגישות גבוהה
בית ספר לציור וחנות חומרי אמנות. פלטפורמה מלאה: קטלוג קורסים, מנויים, תשלומים, וידאו מוגן, חנות וממשק ניהול. 3 סוגי משתמשים: מזדמנים, מנויים ואדמין. אפיינתי, עיצבתי בהתאם לפרסונה ואני מפתח. הקוד נכתב עם קלוד קוד לפי המפרט שלי. הפרויקט עדין בפיתוח.
Next.js · Claude Code · Supabase · GitHub · Vercel
הקמת מערכת ניהול מרכזית (One-stop-shop) לאקדמיה לתיפוף יפני. ממשקי עבודה למשתמשים שונים: משרד, מדריכים ומכירות B2B. ניהול קורסים ורישום תלמידים, רכישות ותמחור דינמי, מנגנוני כרטיסיות, גיפטכארד וקופונים. הקמת מערך צ'אטבוט למסע לקוח ורישום תלמידים, הקמת צינור סנכרון דו-כיווני בין db ל-Wix CMS לעדכונים בזמן אמת וולידציות. הקמת אוטומציות וסקריפטים לניהול תורנויות קורסים עם Round Robin, בקרת היעדרויות והתראות, ו-CRM לצינור מכירה B2B.
Wix Velo · Make.com · Airtable · Cardcom · ManyChat
פרויקט אפיון להקמת מערכת לניהול פרויקטים ליצרן בתחום הרובוטיקה עם שבע מחלקות ו-5 דיסציפלינות הנדסיות. 14 ראיונות אפיון הפכו ל-17 טבלאות DB, 25 אוטומציות, אינטגרציה בין 3 מערכות ואפליקציית דיווחי שטח בהתאמה אישית..
Monday.com · Make.com · ERP
5 שנים של בעלות מוצר מול צוותי R&D, UX/UI ו-QA, על In-house CRM ו-B2B E-ecommerce, מדיסקברי עד פריסה ותחזוקה. יזמתי Epics, כתבתי User Stories ותעדפתי בקלוג. משתמשי המערכות בהרשאות שונות: הנהלה, משרד, מכירות ולקוחות (B2B). בתקופה זו הובלתי עשרות יוזמות בהיקפים שונים ובתחומים טכנולוגיים שונים.
Jira · In-house Platforms: CRM · B2B E-commerce · ERP · HLR
דוגמה למוקאפ של Web App שבניתי לקורסים דיגיטליים ו-E-commerce
3 משתמשים: גולש אורח, משתמש מחובר ואדמין
3 מסכים: מחשב, טאבלט ומובייל
פרסונה ראשית: נשים בישראל מעל גיל 60
עיצוב: צבעים נבחרו לאחר מחקר על הפרסונה ונגישות גבוהה
מי רואה מה, מי מאשר מה ומה קורה כשמישהו מגיע למקום שאסור לו.
סמדר - שלושה-עשר מסכי ניהול במוקאפ, ועשרה חיים בייצור: קורסים, שיעורים, מוצרים, קטגוריות, הזמנות, מנויות, פניות, דיוקנאות והגדרות מערכת. האכיפה יושבת בשלוש שכבות - מדיניות ברמת השורה במסד הנתונים, הפרדה מפורשת בין הרשאת קריאה להרשאת שירות, ושומר בשכבת האפליקציה. אף שכבה לא סומכת על זו שמעליה.
Taiko - למדריך יש הרשאת עריכה רק על מודול השיעורים והנוכחות, ורק לשיעורים שהוא משובץ אליהם. למשרד יש גישה מלאה
מקרה קצה לדוגמה: כשמכירה מהירה יוצרת מצב תחרות ושני אנשים רוכשים את המקום האחרון, המערכת לא מזכה אוטומטית - היא מסמנת את העסקה כדורשת בדיקה, ומשאירה את ההחלטה העסקית לאדם.
יצרן תעשייתי - מטריצה של תשעה תפקידים על שלושה-עשר משאבים, בארבעה מצבים: גישה מלאה, צפייה בלבד, גישה חלקית וחסימה.
019 מובייל - ניהלתי במערכת ה-CRM הפנימית את מנגנון ההרשאות עצמו: הגדרת פרמטרים לאילו פעולות דורשות אישור, איזה דרג מנהלים מקבל איזה קוד אישור ומתי, בניית קבוצות משתמשים, וולידציות וזרימת אישור לתשלום בהמחאות שחזרו - קבוצת מאשרים ייעודית עם קוד חד-פעמי ב-SMS למנהל.
בכל אחד מהפרויקטים, אותה מערכת משרתת קהלים עם צרכים שונים. אלה כמה מההחלטות שנדרשו.
סמדר - הניווט מקובץ לפי פרסונה: ציבורי · משפך חינמי · מנויה · חנות · ניהול · מערכת. מבקרת אנונימית לא יודעת שקיים אזור אישי ומנויה לא יודעת שקיים ממשק ניהול.
Taiko - שלוש פרסונות עם צרכים הפוכים. התלמיד רוצה חוויית רכישה חלקה. המדריך עומד באולפן רועש ומחזיק טלפון - הוא מקבל מסך אחד עם רשימת התלמידים של השיעור הנוכחי, מתג נוכחות, וכפתור הגרלת תורנויות. המשרד מקבל תצוגה רחבה עם הגדרות, מלאי, וחריגות.
בשער התשלומים של אותו פרויקט היו שש אוכלוסיות בצינור אחד: לקוח מחובר, קונה אנונימי, רוכש מתנה, המשתתף בפועל (שהוא לא בהכרח הרוכש), בעל כרטיסייה, וצוות התפעול. הפתרון לא היה 6 מסלולים נפרדים אלא טוקן אטום שעובר דרך התשלום בזמן שההקשר המלא נשאר בצד השרת ומעליו חוקים לפי פרסונה.
יצרן תעשייתי - תשע פרסונות. ההנהלה ביקשה נראות מלאה על כל הפרויקטים uצוותי ההנדסה לא רצו שהעבודה שלהם תיצפה בזמן שהיא בתהליך. שתי הדרישות לגיטימיות והן סותרות.
הפתרון שנבחר הוא לוח פורטפוליו מצרפי שההנהלה רואה במלואו, ולוח הנדסה שההנהלה חסומה ממנו. אותן משימות בדיוק - רמת אגרגציה שונה לכל תפקיד.
מוקאפים ברזולוציה גבוהה, ערכת עיצוב שהקוד יורש ממנה, ומצבי ממשק שנגזרים מנתונים חיים.
סמדר - מוקאפ בן שלושים מסכים, ובתוכו מסך ייעודי לערכת העיצוב: צבעים, סקאלת טיפוגרפיה, כפתורים, שדות טופס, כרטיסי בחירה, קפסולות תשובה וטבלאות. שכבת הטוקנים ננאמנה לקובץ הטוקנים של הקוד.
Taiko - הממשק נגזר ממלאי בזמן אמת. אם נותרו שלושה מקומות, תיבת הכמות נחסמת על שלושה. אם השיעור נמכר בזמן שהמשתמשת גולשת, הכפתור ננעל ומוצג שאזלו הכרטיסים. מגבלה עסקית שנאכפת בשכבת הקלט, לפני שהמשתמשת מגיעה לשגיאה.
019 מובייל - עבודה על מסכים קיימים ועל ממשק חדש: התאמת מסך פרופיל הלקוח ב-CRM - אילו שדות מוצגים, אילו נפתחים כדרופ דאון ואילו כטקסט חופשי ואיך הם מתבטאים בייצוא לדוחות. שינויים בממשק הניהול של החנות באופן הצגת המוצרים. שדרוג ממשק התשלומים. בדיסקברי בניתי והרצתי שאלוני UX/UI לאיסוף דרישות ממשתמשים פנימיים וחיצוניים.
5 ב-019 מובייל, על 2 מערכות בפיתוח פנימי - CRM ו-B2B E-commerce. יזמתי את רוב הפיצ׳רים שהושקו בתקופה זו, כתבתי User Stories ותיעדפתי אותן מול צוותי R&D, UX/UI ו-QA.
מאיפה הגיעה הדרישהכל פיצ׳ר התחיל מצורך עסקי ובבירור מול המשתמשים בפועל - עובדי החברה בדרגים שונים ולקוחות עסקיים. לאחר מכן נכתב Business Case - לפיו הוחלט האם קיימת כדאיות לפתח את הפיצ'ר.
איך נכתבה הדרישהכתבתי את הסיפורים ברמת הצורך, הערך והמימוש - מי המשתמש, מה הוא צריך, למה, ומה צריך להיות נכון כדי שנוכל לסגור את המשימה. ההחלטות הטכניות יחד נקבעו עם צוות הפיתוח. דוגמה לדרישה:
Epic: מנגנון הרשאות ואישורים ב-CRM
User Story: כמנהל בעל סמכות אישור, אני רוצה לקבל בקשת אישור לפעולה חריגה בערוץ שאני נמצא בו ממילא כדי שהאישור לא יתעכב בגלל שאני לא מול המחשב.
קריטריוני קבלה:
פעולה שהוגדרה כדורשת אישור אינה מתבצעת עד לאישור.
קוד האישור נשלח ב-SMS למאשר המשויך לקבוצת ההרשאה של אותה פעולה.
משתמש שאינו בקבוצה אינו יכול לאשר.
כל אישור נרשם עם מזהה המאשר וחותמת זמן.
האפיק הזה כלל גם את הגדרת הפרמטרים עצמם - אילו פעולות דורשות אישור, איזה דרג מקבל איזה קוד ומתי - ואת בניית קבוצות המשתמשים והוולידציה שלהן. אחת הזרימות שנגזרו ממנו היא אישור תשלום בהמחאות שחזרו, שקיבלה קבוצת מאשרים ייעודית משלה.
תעדוףה-Backlog נבנה ונוהל מול 3 צוותים במקביל - פיתוח, UX/UI ו-QA - תחת לחץ מתמיד של הנהלה ולקוחות ובתנאי תחרות עצימים. התעדוף נשען על ה-Business Case, על הערכת זמן הפיתוח ועל צורכי תחזוקה.
סגירת המעגלעקבתי אחרי המשימות ב-Jira ברמת המשימה הבודדת ולפני כל מעבר לייצור בדקתי בעצמי מול קריטריוני הקבלה שכתבתי - ורק אז סימנתי את המשימה כמאושרת. כשהפיתוח אמר שמשהו לא אפשרי טכנית, שאלתי למה, ולפעמים דחפתי שוב - בהלימה ל-Business Case ולשיקול דעתי.
בעלות על 2 מערכות בפיתוח פנימי - CRM וB2B E-commerce - מול צוותי R&D, UX/UI ו-QA.
יזמתי את רוב הפיצ׳רים שהושקו, כתבתי User Stories, תיעדפתי Backlog, עקבתי ב-Jira ברמת המשימה וביצעתי בדיקות קבלה בעצמי לפני כל שחרור. הייתי גם מנהל המוצר וגם שופר המשתמשים.
דוגמאות לפיצ׳רים שהובלתי דוגמאות נוספות לאפיקים שהובלתילפני שהוחלט אם לפתח פיצ׳ר מסוים, יזמתי ניסוי: כמאה לקוחות פעילים בעלי מאפיינים דומים, מחולקים חצי-חצי. קבוצה אחת קיבלה גרסת בטא, השנייה המשיכה בלעדיה. מדדנו שני דברים - כמה השתמשו בפיצ׳ר, ומה קרה למכירות בכל קבוצה. הניסוי רץ לפני הפיתוח המלא, כדי להחליט אם לפתח.