בפוסט אפשור מול ריסון: קרב האור באופל של ארכיטקטורת התוכנה? התפתח דיון:
- מי נכון שיקבל את ההחלטות הטכנולוגיות בארגון?
- איך זהות מקבל ההחלטות משפיעה על היחס בין ריסון לאפשור?
- ב Code Review - מה מעמדו של ה Reviewer? האם הוא יכול לחייב את כותב הפיצ׳ר לשנות דברים או שהוא רק ממליץ? האם נכון לאפשר לו לחסום הכנסה של קוד ל master?
טראומות
"לצערי נתקלתי בהמון מקרים שכל החלטה קטנה הופכת לדיון ובעיניי זה הרסני." - תגובה לפוסט.
"נושא כאוב נוסף שניתן להתייחס אליו זה code review - מה מעמדו של ה reviewer?..." - עוד תגובה לפוסט
הדיון "מי מקבל החלטות טכנולוגיות בארגון?" הוא דיון שמגיע כנראה מתוך כאב, אפילו טראומות. לכל אחד מאיתנו (מלבד הצעירים ביותר) יש סדרה של אירועים כואבים בהם הרגשנו שהחלטה כזו או אחרת פגעה בנו / בארגון, הייתה טעות גדולה או אולי חסרת הגיון ומטופשת לגמרי - אבל לא יכולנו להשפיע עליה.
אשתף בשתי "טראומות" שלי:
שעבדתי ב SAP עבדנו על מוצר וובי (Web) כלשהו, יום אחד הגיע ארכיטקט בכיר מאוד בארגון ודרש שנשכתב את כל המוצר משפת ג'אווה ל PL/QSL - על גבי בסיס הנתונים החדש ש SAP בנתה, HANA. הוא טען שהביצועים ישתפרו בצורה דרמטית, וזה יועיל למוצר - וגם כדרך אגב SAP תוכל להתנסות יותר בפיתוח משמעותי על גבי HANA, כמו שנאמר: Eat your own dog food.
הדבר הזה קרה אחרי שכבר עשינו מעבר מ MySQL ל HANA כבסיס-נתונים - ולמרות ההבטחות ספגנו פגיעות בביצועים (HANA היה מאופטם לשאילתות אנליטיות גדולות, ואת השאילתות הקטנות והממוקדות שלנו הוא ביצע בצורה פחות טובה מ MySQL).
ההתנגדות למהלך בקרב מובילי המוצר הייתה מקיר-לקיר, אבל הארכיטקט הבכיר מאוד (ומי שהוא ייצג) הכריעו - והדבר נעשה. אחרי שישה חודשים של שכתוב קוד ג'אווה ל PL/SQL (שפה גמישה הרבה פחות) שרשרת הכישלונות הייתה כל-כך ברורה וכואבת - שההחלטה התהפכה. לקח לנו עוד כחודשיים להפוך את ההחלטה (לסרוק שינויים ב PL/SQL - ולהכניס אותם חזרה לג'אווה), אבדנו 8 חודשי עבודה (של כ 50 מפתחים), והתשנו מאוד את הצוות ואת האמונה שלו בדרך. המוצר נכשל - אבל גם כנראה היה נכשל בלי קשר להחלטה הזו (לא היה לו מספיק ערך עסקי).
המקרה השני התרחש דווקא בחברת סאטראט-אפ בה רצינו, לראשונה, לבנות אפליקציית Desktop למשתמשים חצי-טכניים. ה VP R&D של הארגון דחף באגרסיביות כלי בשם Eclipse-RCP, פלטפורמת ה UI בה משתמשת Eclipse (ומיועדת לכתיבת IDEs או כלים דומים) - על סמך היכרות על הפלטפורמה מפרויקט שניהל בארגון קודם.
בחנו את הטכנולוגיות מול אלטרנטיבות יותר מקובלות (בזמנו): ממשק וובי, Java Swing, ו FORMS.NET.
Eclipse RCP דורגה מקום אחרון בסקירה, תחת הרשמים שהיא מורכבת, ומספקת כלים מוגבלים ל UI למשתמש הפשוט - אבל מנהל הפיתוח לא ויתר: הוא הזמין שני מובילים טכניים מהחברה הקודמת שלו, לשתף אותנו בניסיון שלהם ב Eclipse RCP. למרבה ההפתעה: הוא אפילו לא תיאם איתם עמדות - הם הביעו חוויה שלילית מהשימוש ב Eclipse RCP וסיפקו לנו עוד דוגמאות וטיעונים מדוע הפלטפורמה לא תהיה בחירה מוצלחת עבורנו. הם המליצו בחום להימנע.
מה אתם חושבים שהיה הצעד הבא? בחרנו ב Eclipse RCP, כמובן. אחרי חודשיים של עבודה ופידבק שלילי מהשטח - החלפנו את הפלטפורמה לטובת ממשק וובי.
המקרה השני יותר מוזר / חזק בעיני: בעוד במקרה הראשון נראה שההחלטה שירתה צורך עסקי אמיתי של החברה (HANA היא מוצר דגל של SAP, שהכניס לחברה מאות מיליונים) - גם במחיר "הקרבה" של קבוצת פיתוח / מוצר זניח אחר, במקרה השני לא היה אינטרס אחר או "גדול יותר" לחברה. ההחלטה להשתמש ב Eclipse RCP הייתה פשוט לא טובה, ולא שירתה שום צורך אמיתי נראה לעין. היא התנהלה בצורה רעה - שגרמה למעורבים (ביניהם אני) לאבד אמון בהנהלה. נכון שהנזק (האבסולוטי) היה קטן יותר: כמה אנשים שאיבדו מידה של אמון במנהל, ואולי עבודה של 2-3 מפתחים לאורך כחודשיים - התבררה כבזבוז.
מה אפשר ללמוד מהמקרים הללו?
(אני מתייחס רק לשני המקרים שתיארתי - שאני מכיר אותם היטב)
- לעתים ה"אנשים הפשוטים בשטח" מבינים טוב יותר, ויכולים לקבל החלטות טובות יותר ממנהלים בכירים.
- בכל זאת, קולם של האנשים הבכירים רם יותר - והשפעתם גדולה יותר.
- במאמר מוסגר אוסיף שזו אחת המוטיבציות של אנשים להתקדם בארגון: להתקדם בעיקר בכדי להיות מסוגלים להשפיע יותר.
- כשהטיעונים להחלטה לא נראים הגיוניים / מציאותיים - מתרחש תהליך של איבוד אמון, תהליך המלווה בתסכול וכאב, בקרב אלו שלא יכולים להשפיע עליו.
- בחדרי הישיבות ובדיונים ניתן לומר הכל - אבל מציאות-ברורה היא חזקה יותר.
- למשל: למרות כוחו הרב של מנהל הפיתוח לקבוע שימוש ב Eclipse RCP בניגוד לכל הדעות האחרות, עבודה קצרה (יחסית) בשטח - הפכה לחלוטין את ההחלטה.
- כלומר: המנהל יכול היה להכריע שננסה את השימוש ב Eclipse RCP, אבל לא באמת היה לו מספיק כח להכריח את השימוש בו לאורך זמן / ניסיון לא טוב.
- אנשים שונים מבינים את המציאות באופנים שונים, לעתים במידה שכמעט ואינה ניתנת לגישור.
- לפעמים, התכתשויות על החלטות טכנולוגיות - נעשות באמונה שלמה, של שני הצדדים, שזה הדבר נכון לארגון. זה המקרה הטוב יותר.
- יש מקרים, לא נדירים, בהם השיקול שמנחה אנשים הוא לא באמת טובת הארגון, אלא טובתם שלהם: חשק, עניין, תחושת ביטחון ("זו הטכנולוגיה שאני מכיר", "נוח לי יותר לעבוד עם הקבוצה הזו", או "זה יקנה לי שקט מול מישהו קולני בארגון"). הרבה פעמים אלו צרכים אישיים ולא "רשעות טהורה" - אבל הגישה הזו לרוב תוביל לתוצאה (וגם אווירה) - טובה פחות. זה המקרה הפחות טוב.
- אני אתוודה, שאני לא פעם "דחפתי" החלטות טכנולוגיות על בסיס היכרות אישית שלי. רציתי שנעבוד עם כלים שאני בקיא בהם, ויהיה לי יותר מה לתרום, ויותר יכולת השפעה. רק במעט הפעמים - זה היה השיקול הנכון לארגון (כלומר: זה שאני אכיר / ארגיש בנוח עם הטכנולוגיה), ואני מנסה מאוד להימנע ולחזור על הטעות הזו.
- החלטות טכנולוגיות, על אף המאמץ להפוך אותן "למדע מדויק" - לעולם לא יהיו לגמרי כאלו. תמיד יש בהן אלמנטים של טעם אישי וניסיונות עבר סובייקטיביים, הן יוכרעו במידה על סמך יחסי-הכוחות בארגון, ובלתי-נמנע שחלק מהאנשים לא יהיו מרוצים.
- אני לא מאמין בניסיון לרצות את כולם - ואני מאמין שהן צריכות להתקבל ולהעשות, גם כשיש חוסר שביעות-רצון. כמובן שככל שחוסר שביעות הרצון גדול יותר, ומאנשים רלוונטיים יותר - נכונות ההחלטה נחלשת.
- חשוב, לתת משקל משמעותי למי שעומד "לחיות" עם ההחלטה, ולשלם בפועל על טעויות בהחלטה. למשל: אם בניתוח הטכני אופציה א' מקבלת ציון 90 ואופציה ב' ציון 70, אבל הצוות שאמור לממש את הקוד ולחיות איתו מאמין יותר באופציה ב' - סיכוי טוב שנכון יותר לאמץ את אופציה ב', משני טיעונים מאוד ענייניים:
- א. סיכוי טוב שמישהו בשטח מבין משהו שאתם לא, אפילו אם הוא לא יודע להסביר את זה בצורה טובה. (אם היה מתקשר מעולה, אולי היו מקדמים אותו והוא כבר לא היה בשטח?).
- ב. מוטיבציה היא הדלק של תעשיית התוכנה. מי שכואב את הבחירה באופציה א', יוכל בלי משים, לממש אותה בדירוג 60, בעוד את אופציה ב' שהוא מאוד מאמין בה, להביא למימוש לדירוג 80.
זו נשמעת כמו סחטנות או כוחנות, אבל זו המציאות האנושית ככל שאני מצליח להבין אותה: כך הדברים מתגלגלים בשטח ולא חכם "לטבוע בצדקנות". אנשים טובים יעשו עבודה פחות טובה שהם לא מרגישים חלק ממנה, ועבודה יותר טובה כאשר הם כן מרגישים חלק ממנה. לכן זה צריך להיות פאקטור גדול בשיקול. - המציאות חזקה יותר מכל טיעון - ולכן לעתים עדיף להתכתש בשטח מאשר באולם הדיונים. כאשר זה אפשרי, יש טעם בפשוט לנסות בשטח, ולשמור אופציות לשינוי כיוון.
- לא פעם נופתע, שבעצם אופציה שפחות האמנו בה עובדת "טוב מספיק".
- לא פעם, המציאות בשטח תשנה את דעת המתנגדים - ברוח טובה, ונוכל לפנות לדרך טובה יותר, כקבוצה מגובשת.
- הכרעה בשטח היא בשום אופן לא הסתמכות על הגורל או "הרמת ידיים". כדי להצליח בה טוב חשוב:
- לחתור בשטח למגע מוקדם וחד-משמעי, ככל האפשר, עם נקודות המחלקות.
- תיאום ציפיות לשינוי כיוון, במידה ומדדי הצלחה מסוימים לא יוכרעו.
- אפשור האופציות הטכנולוגיות (ארכיטקטורה), והפרויקטליות (לוחות זמנים) לשינוי הכיוון. אם יצאנו לניסיון בלי יכולת אמיתית לבצע שינוי כיוון אמיתי מאוחר יותר - יצאנו פשוט טיפשים. סליחה.
- ניתן אולי להסיק מכאן שעדיף "להפוך את הפירמידה" ולתת למפתחים את מירב שיקול הדעת וההחלטות בנושאים טכנולוגיים - וכך גם להשיג את מירב המוטיבציה וההיכרות עם השטח. זו שאיפה יפה, אבל אני חושב שהיא לא מתרחשת מהסיבות הבאות:
- לעתים מפתחים בשטח מבינים טוב יותר - אבל גם לפעמים לא.
- מפתחים נוטים לגלות אהבה רבה לטכנולוגיות חדשות ומדוברות - באופן שמטה יותר מדי החלטות לכיוונים פחות טובים.
- גם מפתחים לא חפים מאלמנט של קידום האינטרס האישי: "שימוש ב <באזז> ישפר את מעמדי מול חברי / קו"ח / בטחון עצמי".
- למפתחים לרוב יש הבנה פחות טובה של הביזנס, אלמנט קריטי בנכונות של ההחלטה.
- מפתחים לא פעם מפגינים חשיבה קצרת טווח / נאיבית - לגבי החלטות.
- בקיצור: הבכירים לרוב קונים את מעמדם (וקולם העדיף) בזכות האמון בהם, שהם מסוגלים לקחת החלטות טובות יותר. כמובן שיש כשלים במינויים, ולא פעם הבכיר הוא אדם שמקבל החלטות טכנולוגיות רעות באופן סדרתי.
- ניסיון וידע הם דבר להתבסס עליו בקבלת החלטות טכנולוגיות - אבל כיצד?
- אני רואה משקל משמעותי למישהו שכבר היה בסיטואציה דומה. זהו ניסיון קונקרטי.
- "שנות-ניסיון" הוא לטעמי מדד מטעה: זה חבל, אבל יש אנשים עם 10 ו 20 שנות ניסיון שהידע שלהם פחות יסודי ו/או הם מקבלים החלטות טכנולוגיות פחות טוב מאנשים אחרים עם 5 או אפילו פחות שנות ניסיון. הם עברו הרבה מערכות וחברות - אבל ספגו מזה רק מעט. מאוד הייתי רוצה לאפיין מהי קבלת החלטות טובה וכיצד רוכשים את המיומנות הזו. ניסיתי בכמה הזדמנויות - אבל זה נושא גדול.
- ברור שהמעמדות (מונח מציק באוזן) בארגון משנים גם הם. לארכיטקט או ראש צוות יהיה משקל גדול יותר - על אף שייתכן שהם לא "יספקו את הסחורה".
- ראשי צוותים, למשל, הם ה Backbone של הארגון. זה תפקיד קשה, שוחק, ולעתים - כפוי טובה. הארגון "חייב" משהו לאנשים הללו בתמורה, ולעתים זה מתבטא בסלחנות להחלטות פחות טובות שלהם. דינאמיקת ה"קח ותן" הזו נוגעת בכל מי שנותן ערך נוסף לארגון והארגון "חייב" לו. זו דינמיקה חיונית, כנראה - שיש לה צדדים פחות יפים, אך היא חשובה.
אפשור מול ריסון בהיבט של קבלת החלטות
חקר-מקרה: נקסט אינשורנס
"אני מוצא את עצמי די מזדהה עם התגובה הזאת. ממש הייתי שמח לקרוא מאמר/כתבה על איך צריך לקבל החלטות בצוותי פיתוח. אילו דברים הם ברמת ההחלטה של המפתח הבודד, אילו דברים צריכים לעלות לדיון מול הצוות, אילו דברים ניתן לסגור באישור בין המפתח לראש הצוות וכו׳..." - תגובה לפוסט.
- כמובן שהחברה היא לא מקשה אחד, ומה שאספר מדויק יותר באזורים מסוימים של החברה - ומדויק פחות באזורים אחרים.
- אני מספק נקודת מבט לא אובייקטיבית, כי כארכיטקט-ראשי של החברה, יש לי צד ועניין בדברים.
- אני "שולף" כאן. כל הפוסט הזה נכתב ברצף של כמה שעות, ופרטים שלא חזרתי ועיינתי בהם - יהיו פחות מדויקים ומבושלים, מנושאים שניתחתי בקפידה.
- כל מה שנכתב פה הוא על דעתי האישית בלבד, לא התייעצתי ובדקתי בכדי לנסות ולתאר את "דעת החברה".
- קבלת החלטות היא העצמה ופיתוח של העובד - ויש רצון לתת למפתחים לקבל החלטות בעצמם, ככל שזה יעבוד טוב.
- האחריות מוטלת בסופו של דבר על ראשי הצוותים, ראשי הקבוצות, ואף הארכיטקטים - ואחריות באה עם יכולת השפעה.
- חשוב לנו ניהול Stack מינימלי של טכנולוגיות - בכדי לפשט את המערכת ולשמר את היכולת של מפתח מצוות X להבין ולשנות קוד של צוות Y. אנחנו נקשה/נאתגר בכל פעם שיהיה רצון להרחיב ולשנות את ה Stack הטכונולוגי, ונגדיר סדרת מבחנים - שיש לעבור בכדי להוסיף טכנולוגיה ל Stacks (יש לנו כמה Stacks שכאלו: Backend, Frontend, ו Data).
- כנ"ל לגבי מבנים וסגנונות עבודה. יש לנו קווים מנחים / Patterns למבנה של מיקרו-שירות (שכבות, אינטרקציה, דרך לכתוב בדיקות, איך מתבצעת תקשורת בין שירותים, דפוסים לעבודה עם בסיס הנתונים) - ואני והצוות שלי נאתגר את מי שירצה לחרוג או לשנות אותם. צריך להראות ערך / צורך ברור ומעל ספק סביר - בכדי לעשות שינוי. העיקרון המנחה הוא שמערכת אחידה יותר - תהיה מובנה וצפויה יותר לשאר הארגון.
- יש לנו תהליך של "ניסוי" בו כל אחד, בתיאום ראש הצוות, יכול לנסות טכנולוגיה חדשה / סגנון חדש באזור מוגדר. לאחר כמה חודשים של ניסיון אמור להיות שלב Go/no Go. אם קבוצת ה Reveiw השתכנה שזה שיפור ברור - מאמצים כחלק מהסטנדרט (או לעתים: סטנדרט רק למקרים ספיציפיים ומגודרים היטב.). אם צוות ה Reviewer לא השתכנע שזה מספיק טוב - הניסוי יימחק והקוד יומר לסנטדרט.
- תהליך יפה, שלא כ"כ מתנהל בפועל. יש שני מקרים ברורים בהם נכנסו כך טכנולוגיות חדשות לרוחב החברה - וגם מספר דחיות, אבל עדיין ממתינים כ 10 ניסיויים באוויר, בלי שאנחנו עושים להם תהליך רביו. כשל אישי שלי.
- לא מזמן הקמנו קבוצת עבודה להגדרת Guidelines לעבודה: אני מוביל את הקבוצה בעזרת נציג מכל מחלקת פיתוח. אנו מציעים ביחד טיוטה לסטנדרטים (שהוסכם שכארגון אנו רוצים בהם): כיצד להגדיר API, כיצד לעשות Code Review, כיצד להשתמש ב Exceptions. הטיוטה עוברת Community Review - סשנים בהם כל מפתח יכול להצטרף ולהציע שינויים, אבל הוא צריך לבוא עם "שיעורי בית" מוכנים: טיעונים ודוגמאות משכנעים. על השינויים מסכימים ברמת ה Community. לפעמים זה קל, לפעמים בהצבעה - ואחרת אני מכריע (מקרים נדירים שזה נדרש. נדרש כדי לא למרוח החלטות). מאותו שלב אנחנו מפרסמים את ה Guideline ועובדים לפיו.
- עד כמה ה Guideline תואם למציאות בפועל? לפעמים יותר, ולפעמים פחות. כשיש ויכוח בין שני צדדים - הוא כן מסמך מכריע בהחלטה. כלומר: צוות שיחליט לעבוד אחרת יכול לעשות זאת "מתחת לראדאר" עד אשר יהיה ויכוח פומבי בנושא. גם אז - ננסה להבין אם הבעיה היא חוסר-הגמישות של הצוות, או בעיה ב Guideline שנקבע.
- חייב להיות לפחות Reviewer אחד שמאשר את הקוד. אם מדובר בקוד של צוות אחר - חייב להיות אישור של מישהו מהצוות.
- Reviewer שלא מרגיש שיש לו משהו משמעותי לתרום ב Review יסיר את עצמו, ויוסיף Reviewer אחר במידת הצורך.
- ברוב המקרים, ה Reviewer רק מספק הצעות לכותב הקוד. הצעות יכולות להתקבל או להדחות. אנו מעודדים אנשים להיות רגישים אחד לשני, וגם לפרגן על קוד טוב - בכדי לבנות את האמון.
- Code Review בהגדרה הוא לא כלי להכתיב סגנון מועדף לאנשים אחרים. ה Reviwer נותן עצות, ורצוי שיצליח לתת אותן ממקום חברי ותומך (ולא ממקום נוזף ומתנגד).
- במידה וה Reviwer מזהה בעיה משמעותית: באג, תכנון (Design) בעייתי, או חריגה משמעותית מה Guidelines הוא מסמן את ה PR כ "Changes Required". מהשלב הזה ה PR לא יוכל להתמזג (merge) ללא הסכמה של אותו Reviewer. כלומר: אנו נותנים ל Reviewer דגל אדום להרים, שיש מאחורי סמכות - אבל הציפיה היא להשתמש בו בזהירות ובאחריות.
- מי שישתמש בזכות הזו במידה רבה מדי - יזכה להכוונה מחדש מהמנהל שלו.
- יש לנו גם שורה של עצות מה לבדוק בקוד Review, ועל מה להעיר. זה בעיקר Checklist לבודק.
דיון מרתק. המון תודה על ההתייחסות לנושאים החשובים האלה
השבמחקתודה!
מחקמענין ובא לי בדיוק בזמן...
השבמחקעובד בקבוצת פיתוח בה למנהל יש הבנה טכנולוגית מסוימת אבל הוא רחוק מאד מקוד
כבר נתקלתי בשתי החלטות מנותקות שנעשו, (בניגוד לדעת ר"צ ומפתחים)
אחת נפלה אחרי 2-3 חודשי פיתוח
ואחת עדיין איכשהו מקרטעת...
חבל ממש כי אם היה יותר שיתוף של הצוות בשלב המחקר - זה היה נמנע
אבל "הצנחת ההחלטות" הזו זה מתסכלת את הצוות וגם מזיקה לחברה...
מרתק. גמישות וכנות מעוררות השראה
השבמחקאני מאמין שלכל אחד יש זכות להחליט החלטות כאלו, וההשפעה על הביזנס היא קריטית. המיקרים בהם "בוחרים כלי לא נכון כדי לפתור בעיה" הן בעיות צורמות, אבל מניסיום, ב90% מהמקרים זוהי חוכמה שבדיעבד.
השבמחקברור שיש לשים את הטריידאוף במקום בולט, לחקור את האלטרנטיבות, ולדעת להסביר את ההחלטה. ככה - אפילו במקרה ואין הסכמה - אפשר לראות את הסיכון ולהתנהל מולו.
לגבי הסיכום - וזה דיון - אני לא בטוח שאני, כמנהל פיתוח בחברת פרויקטים, מצליח לייצר הבנה של ORG > GROUP > I, אני לא יכול להימנע מדינאמיקה אירגונית, אני רגיש מאוד להחלטות לקוח בנושא זה. אני מסתמך על כוח אדם לא מנוסה, ולצערי אני לוקה בצבעוניות שאתה מדבר עליה (וכן - אגו זו בעיה). לצערי כשאני מנסה להיכנע לקונצנזוס - קל לעשות טעויות מהסוגים שדיברת עליהם - החלטות מוטות באז, החלטות מוטות אופנה, ובלי הצדקה כלכלית או ROI סביר).
כלי לתיעוד ההליך של קבלת ההחלה הוא ה ADR - https://adr.github.io/
אם נוכל לצייר את מה הבעיה, מה הפתרון, מה סטטוס ההחלטה (האם הוחלט, או הוצע?), מה משמעות ההחלטה (ברמה של מגבלות) ומה האלטרנטיבות. דיון כזה *לדעתי* הרבה יותר פורה ומפרה. כך גם הטריידאוף ברור לכולם.
לדעתי חלק חשוב הוא לא רק ההחלטה, אלא גם היכולת לבדוק אותה לאחר זמן.
מחקאם נצא מנקודת הנחה שלטעות זה אנושי, צריך לוודא שאנחנו לא מנציחים טעויות וממשיכים לסבול רק בגלל אגו / פוליטיקה או סתם הזנחה...
POINT ON!
מחקהבכירים לרוב קונים את מעמדם (וקולם העדיף) בזכות האמון בהם, שהם מסוגלים לקחת החלטות טובות יותר. כמובן שיש כשלים במינויים, ולא פעם הבכיר הוא אדם שמקבל החלטות טכנולוגיות רעות באופן סדרתי.
השבמחקמה באמת נכון לעשות כשיש "אדם שמקבל החלטות טכנולוגיות רעות באופן סדרתי" (והוא בכיר ממני)?
חוץ מלעבור מקום עבודה...
נכתב בדיוק בזמן בשבילי, תודה רבה!
השבמחקאצלי בחברה אנחנו לקראת שינוי ארכיטקטורה באופן מאומץ במשך שבוע שלם שיכלול את כל צוות הפיתוח (backend&frontend) והדברים שנכתבו כאן ללא ספק ישפיעו על האופן בו אתן לכל אחד ואחת להביע את עמדתו/ה ולהשפיע במקום להנחית עליהם עובדות מלמעלה.
השבמחקThis blog is an extremely informative blog on flutter development. It contains all the information you need to get a good understanding of developing applications in a flutter. It is highly recommended to read this blog to anyone who is looking to develop applications on android and iOS platforms. Flutter is a robust mobile app SDK to help developers and designers build modern mobile apps for iOS and Android. Flutter works with existing code. It has been used by developers and organisations around the world. Eiliana helps expert developers of Flutter apps get connected with clients in need of their services.