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

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

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

המשתמש רואה "נשמר", אבל ברשימה הכללית למשימה מופיע מועד ישן — אובדן העריכות מתגלה כעבור יום, בישיבת תכנון.

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

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

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

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

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

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

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

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

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

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

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

מצבי סנכרון אופליין: מלא, חלקי, מבוסס אירועים

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

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

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

שלבי הטמעה: מאודיט תרחישים ועד מסירת נהלים

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

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

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

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

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

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

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

מה מוסרים לידיים: סכמות, כללי סנכרון, נהלים

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

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

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

מקרה בוחן: עבודות שטח וסנכרון משימות של בריגדות

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

מה נשבר לפני ההטמעה

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

מה השתנה במכניקה

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

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

במה סנכרון אופליין שונה ממקאשינג רגיל?

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

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

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

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

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

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

בירור שאלות טכניות לפני תחילת העבודה

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

עד כמה הנתונים במכשיר עצמו מוגנים?

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

המכשיר אבד — הנתונים ידלפו החוצה?

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

האם אפליקציה קיימת תצטרך להיכתב מחדש?

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

נדון במשימה ונחזור עם תוכנית סנכרון

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

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

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