פחות או יותר 06:00 יום של סתו תל אביב אמצע נובמבר
בפעם הראשונה שגיליתי שאתר הבלוגים הישראלי של מיקרוסופט ישראל הפסיק להיות פעיל (באמת לא מבין למה….) הבנתי שהדור הבא של הבלוג שלי יהיה שלי, כלומר עצמאי ללא תלות באף גורם.
במסע של החיים זה לקח לי זמן בעיקר זמן רגשי לבחור את הדרך הנכונה וכאשר מצאתי את הדרך הנכונה היא הייתה הכי נכונה בשבילי
לפעמים כשיוצאים למסע יש הרבה בחירות שצריך לעשות והרבה פעמים מסע מתחיל עם הרבה מאוד מסעות מקבילים. בשנה-שנתיים האחרונות עברתי גם אני לא מעט מסעות מקבילים הן בחיים המקצועיים וגם בחיים האישיים אני מבורך רוב המסעות שעברתי הם מסעות חיובים.
בפוסט זה אני רוצה להתמקד במסע של החזרת הבלוג לפעילות ופרוייקט שיפוץ ומעבר בית. יש קווי דמיון מעניינים בין 2 הפרויקטים האלו ובהם אתמקד. המטרה היא לשתף למי שמתחילה או מתחיל מסעות דומים. אני עשיתי זאת גם בהקמה מחדש של הבלוג וכמובן שגם בפרויקט השיפוץ.
הבלוג – הוא אישי ובעברית, הכותרת שלו מכילה את כל ההוויה המקצועית ואני מאמין שלי.
Li-Mate-Or – נראה לי שהכל ברור
The simple architect journey through life or maybe an impossible is possible
זה המסע שלי בחיים המקצועים ואני לחלוטין מאמין שהבלתי אפשרי הוא אפשרי (אם לא הייתה אמונה צסק״א לא הייתה אוכלת אותה).
ידעתי שמעבר לפוסטים מקצועיים אני ארצה שיכיל יותר,,, וידאו , תמונות מחיים וממש בקרוב גם פודקאסט
פרויקט השיפוץ – בית החלומות שלי הוא בית קרקע קומה אחת עם חצר גדולה ומגרש כדורסל מקורה, טוב זה לא יקרה בזמן הקרוב. בת זוגי ואני עברנו לדירה הראשונה שלנו ישר מבית ההורים לפני כ 20 שנה (דירה צנועה של זוג צעיר). לפני קצת יותר משנה מצאנו את הנכס שיהווה בשבילנו את החלום המשותף, אז נכון שזה לא בית עם קומה אחת ואין לנו חצר גדולה ולצערי אין לנו מגרש כדורסל מקורה אבל לחלוטין יש שם את המקום שהלב שלנו נמצא בו.
פרויקט השיפוץ התבסס על חברות ומקצוענות. כבר התחלה התייעצנו עם אין סוף חברים.ות טובות שעברו מסעות דומים. זה המשיך במצב שרוב בעלי המקצוע והספקים הם חברים של חברים ולא פחות חשוב כולם מקצוענים בכל רמ״ח איבריהם.
בניית הבלוג – הסתמכתי על הניסיון שלי ועל מספר כותבות וכותבים ישראלים שכותבים בשפת הקודש. התלבטתי רבות באיזו פלטפורמה לבחור ולבסוף הבחירה הייתה WP ובעקבות פודקאסט ששמעתי בחרתי בעסק החברתי Techjump שהקימה אביטל, קורל היא זו שהובילה את פרויקט בניית האתר.
לא סתם אני מתמקד בפרויקטים האלו בפוסט זה, המכנה המשותף שלהם דומה למרות שהם פרויקטים מסוג שונים. לכל הפונה למסע דומה אפשר לקחת (בחינם) מהניסיון שעברתי ואפילו לשוחח איתי בנושא.
ריכזתי את ה 5 הנקודות המרכזיות שלי , אין חשיבות לסדר. למען האמת הנקודות האלו עובדות לי גם בחיים המקצועים בתור ארכיטקט פשוט
בעל המקצוע המתאים לעבודה המתאימה זה מרכיב חשוב בהצלחת כל מסע, זה ממש כמו לבחור את הכלים הנכונים למשימה הנכונה. ברור שאפשר לדפוק מסמר עם מברג או לחזק בורג עם פטיש. אבל זה יהיה הרבה יותר מוצלח אם נבריג את הבורג עם מברג מתאים. בחיי המקצועיים אני ממליץ לקחת את בעלות המקצוע הנכונות לפעמים מספיק רק נסיון אבל הרבה פעמים חשוב גם המקצועיות והגישה לעבודה.
זה לא פשוט לבחור בעלי מקצוע ראויים (אני זכית בכאלו בשנה האחרונה), אבל למדתי שאותם עקרונות שהנחו אותי בתור ארכיטקט/מנהל בגיוס ובחירת הא.נשים הנכונים עובד גם בפרויקט הבית או הבלוג.
נראה לי שעל זה כתבתי פוסט ובטוח שאכתוב עוד אחד בעתיד
הגדרת backlog מבוסס מטרות זה נושא רגיש. המטרות מורכבות ממספר רבדים ששזורים אחד בשני. בבלוג זה היה רבדים שלי, למשל מה המטרה בתור ארכיטקט פשוט , מטרה בתור פריילנסר , בתור אדם פרטי שחושף את עצמו בפומבי וכמובן מה אני רוצה לתרום לקהל היעד שלי.
בפרויקט הבית כמובן שזה היה הרבה יותר מורכב, כל בן משפחה הוא עולם ומלואו , השותפה שלי לחיים ואני זה עוד רובד וכמובן אנחנו בתור משפחה.
כמובן שאפשר להגדיר מטרות ״רופפות״ אבל זה יכול לעלות בהרבה דם יזע ודמעות. אפשר להגדיר מטרות מפורטות מאוד אבל זה יכול לקבע אותנו למחשבה מסויימת ואפילו להקשות על גמישות בהמשך. וכן גם כאן כמו בחיים המקצועים איך מגדרים את בנק המטרות זו מיומנות. גילוי נאות היו הרבה נקודות בדרך שכמעט וויתרתי לעצמי, לשמחתי רק כמעט.
חשוב לזכור שמרכיב המשאבים חייב לבוא לידי ביטוי כחלק מהמטרות , לפחות בשבילי.
גבולות גזרה של מה כן ובמיוחד מה לא
בכל פרויקט ההבנה מה נמצא מחוץ לטווח או במילים אחרות מה לא נכנס או מה לא יהיה זה נושא באתגר בפני עצמו. לאחר מגדרים את המה לא כבר יותר קל להגדיר את המה כן. גבולות הגזרה חייבות להיות גלויים לכל המעורבים, כמובן ברמת השקיפות המתאימה לכל מעורבות. בצורה כזו מאוד קל לקחת את ה backlog ולצאת לדרך כאשר ברור לאיזו יבשה מגיעים. ברור שלכל יבשה אפשר להגיע במספר דרכים אבל כאשר המטרות ברורות וגבולות הגזרה מסומנים זה הרבה יותר פשוט לנווט.
בכל פרויקט יש אתגרים וככל שהפרויקט מורכב יותר ו/או מערב יותר גורמים ן/או כולל מרכיבים לא ידועים האתגרים הרבה יותר משמעותיים ולפעמים בעוצמות יותר גדולות. וכאן בא לידי ביטוי מה שאני תמיד מדבר עליו בהרצאות שלי, השינוי הוא הדבר הקבוע היחידי. כמובן שאם בעלות המקצוע הנכונות , מטרות מוגדרות ומתועדפות ושמירה על גבולות גזרה אפשר להתמודד עם מרבית האתגרים. אף פעם חיוך לא הזיק ואפשר להגיד שברוב האתגרים הוא אפילו ה x-factor
אני לא מאלו שאומרים שמטרה מקדשת את האמצעים, אכן המטרות מאוד חשובות אבל בגלל החיים שלנו זה מבע ארוך ומדהים הדרך חשובה לא פחות. דריך לדעת לעשות אותה בצורה הנכונה, לחלק כוחות לעשות זאת בשיתוף והבנה ולהקיף בא.נשים שיתמכו ויעזרו להתקדם קדימה.
אני תמיד אומר שבגלל שהדרך לא פחות חשובה חשובה לתת לה ביטוי הן במטרות והן בגבולות הגזרה
לכל הקוראות והקוראים, תרגישו חופשי לפנות אלי, אני מבטיח להשתדל לענות/לסייע
בפוסט זה אני לא מתכוון לגלות לכם התשובה לחיים, היקום וכל השאר, בשביל זה תשאלו את גוגל.
מה שאני כן רוצה זה לנסות לתרום מניסיוני , שכמובן נבנה גם מניסיונם של אחרים לצורת ניהול זמן.
זה עובד בשביל אחרים ובצורה מסוימת זה עובד גם בשבילי.
ברור שתמיד אני מנסה לשפר :-9
פוסט זה כתוב בלשון זכר אבל ברור שזה עובד גם בצד הנשי.
זמן יצירתי – הקצאה לחשיבה, העלאת רעיונות ופתרונות
זמן הכנה – מוקדש לתכנן משימות , התארגנות ותיאום
זמן יצרני – ביצוע העבודה בפועל מימוש המשימה כולל טיפול במשברים
זמן תפעול – נושאי מעטפת "תקורה" מעקב ובקרה, תכתובות ודיווחים
חשוב שהשבוע יכיל את כל סוגי הזמן, כמובן שהתמהיל הנכון הוא לחלוטין סובייקטיבי.
עבוד בהתאם לתכנון שלך
קבע פעילויות קבועות , כגון מילוי נוכחות , קריאת הדרכות וכדומה
עבוד לפי סדר חשיבות ולא על פי סדר דחיפות, כמובן שבמרבית המקרים
נצל ביעילות זמני ביניים (Backlog)
קבע מטרות ויעדים לכל פגישה שאתה מוביל
אל תענה לטלפונים בזמן פגישה או דיון
בפגישות שאתה מוביל סיים 5 דקות לפני הזמן.
פגישות שדורשות פעילות המשך סכם את המשימות כולל זמן לביצוע
אשתדל להגיע 5 דקות לפני תחילת הפגישה או בדיון
במידה ואתה מאחר, ידע את אחראי הפגישה. זכור הזמן של כולם חשוב לפחות כמו שלך!
יצר מקום ויזואלי עם כלל המשימות שלך. חשוב שיהיה נגיש לך ולמנהלים שלך בשעת הצורך.
ניהול יומן הוא אחד מהגורמים שהופך מישהו מחובבן למקצוען.
מפה את המשימות המוטלות עליך
קבע יעדים וסדרי עדיפויות
תכנן את המשימות ביומן ועדכן אותם באופן שוטף. גם בדיעבד. לדומה אם עסקתי במשך שעתיים בכתיבת דוגמת קוד או הכנת מצגת אסמן זאת ביומן כמשימה.
התחל את היומן במשימות החשובות
רכז משימות דומות וטפל בהן בבת אחת
הקצה זמן קבוע לתכנון של היום או השבוע הבא
הכנס ליומן זמן להפסקת צהרים
הכנס אירועים פרטים ליומן (כמובן שברגישות) וסמן אותם מחוץ למשרד
הכנס תזכורות כגון ימי הולדת, מועדי השלמת משימות ונושאים לבדיקה
צבע את סוגי המשימות בצבעים שונים על מנת שתוכל להבחין האם חלוקת הזמן נכונה. אני באופן אישי מגדיר צבעים לפי פרויקטים ותחומי עיסוק. במבט אחד מאוד קל לי להבין "על מה בזבזתי את הזמן"
פגישות כפולות זה אכזבות כפולות, נהל הרישום הכפול בצורה נבונה. בכל מקרה באותו יום וודא שאין לך רישום כפול.
אחד מהגורמים הקריטיים לתקלות בארגון זה בלאגן הדואר. לכן חשוב מאוד לראות איך מייצרים סדר במקום שהכי קל ליפול.
זכור מרוב עצים (דואר שלא נקרא) לא רואים את היער (המשימות לביצוע)
כלל אצבע – אל תשאיר דואר שלא נקרא יותר מ 24 שעות (למעט אם אתה בחופש). הקצב זמן קצר לתיוגו והבנה מה צריך לעשות עם הדואר.
העבר או תייג את הדואר לקטגוריות מתאימות.
הקפד על נמעני TO מתאימה וכמובן כל השאר ב CC.
דואר ששלחת וחשוב לך שלא קיבלת עליו משוב תוך מספר ימים נסה לברר מה הסיבה.
מי שאומר "שלי זה לא יקרה" כנראה זה קורה לו כל הזמן. אנחנו חיים בעולם דינמי (וטוב שכך) משימות בלתי מתוכננות תמיד קורות.
עצור! אל תמהר ללא חשיבה מקדימה.
תכנן כיצד להתמודד עם הבלת"מ ומה נדרש כדי ליישמו
בחן המשמעות של פגיעה בתכנון משימות אחרות
הערך את חשיבות הבלת"מ למול המשימות האחרות ובמידת הצורך הרם דגל
אז זהו שיש הרבה קשר :-9
הרבה פעמים אני רואה, ובכל הרמות. ניהול זמן , משימות ודואר לא טוב מיצר בזבוז.
כאשר לא נשאר זמן מוותרים על הדברים "שקל" לוותר כמו דרישות לא פונקציונאלית , הנדסת תוכנה ותהלכי פיתוח בריאים. הדבר יוצר חובות טכנולוגים שבהרבה מקרים "הורגים" פרויקט ומחסלים את חדוות היצירה!
הרבה פעמים הצוות או הבודד נמצאים במצב של כאוס בגלל ניהול זמן ומשימות לא טוב. ניהול זמן ומשימות טוב מוציא אותנו ממצב של כאוס למצב של למידה וזה חשוב.
דעתי האישית שגם בעולם ה Agile וגם בעולם המפל כללים אלו יכולים לעזור ובטוח לא להזיק :-9
ברור שכללים אלו יכולים להיות טובים לא רק לעולם הפיתוח אלה גם לעולמות אחרים, בדיוק כמו Agile ומפל.
כרגיל אשמח לשמוע דעתכם וכמובן לקבל ממכם טיפים למדריך לטרמפיסט ;-9
פורסם לראשונה בבלוג הישן ב -אוקטובר 2010
לפני מספר שנים קיבלתי שיעור מעניין ממנהל שאני מאוד מעריך. אפילו שהשיעור לא היה בצורה ישירה.
בסופו של השיעור הגעתי למסקנה שאין הבדל בין סקר קוד לבין הבעת דעה על מצגת.
ולמה אני עושה את האנלוגיה זהו? או כמו שאומרים פעם מפתח תמיד מפתח :-9
עם הזמן למדתי שכאשר אני מסתכל על קוד שמפותח ע"י מפתח אחר אני חייב להתייחס כאילו מישהו מתייחס לקוד שאני כתבתי…..
אני לא מצפה לשמוע כמה הקוד גרוע, אלה לשמוע על רעיונות טובים שיש בקוד.
כלומר אני לא מצפה לשמוע מה לא בסדר במה שכתבתי אלה איך ניתן לשפר את מה שכתבתי.
וכמובן אני מצפה שיאמינו לי שרציתי לכתוב את הקוד הכי איכותי!!!!!!
גילוי נאות אני לא תותח בהכנת מצגות, בכתיבת קוד אני כותב ברמה גבוהה (אני מקווה) ולכן תמיד מנסה "לברוח" לשם.
בואו ננסה לראות איך יכול להיות ששווה להביע עמדה
אף אחד לא מצפה לשמוע כמה שהמצגת לא טובה אלה מה כן טוב המצגת.
הצד שמציג מעדיף לשמוע איך ניתן לשפר את המצגת ואיך לקדם אותה כמה צעדים קדימה וכמובן שלא מצפה להערות שליליות על השקפים אחד אחד……
ובדרך כלל מי שהכין את המצגת השקיעה בה זמן ושימת לב.
עשיתי בחיי כמה וכמה סקרי קוד ועיצוב ,מקווה שהצד השותף עבר חוויה חיובית.
אני תמיד משתדל להביע עמדה על מצגות כמו שאני מביע על קוד ופתרונות עיצוב.
"קח אותו לאט את הזמן……" לפעמים המשפט יכול לעזור
אשמח לשמוע את דעתכם
ראשית אני חייב לפתוח בגילוי נאות. אני 5 שנים ארכיטקט במשרה מלאה וכמות הקוד שכתבתי שעבר ליצור פחות מ 200 שורות. יחד עם זאת כמות הקוד שפגשתי עבר בקלות את המיליון, גם לא מעט באגים ואתגרים של ביצועים וזליגות זיכרון פגשתי.
אני חושב שיצא לי לראות עשרות פרויקטים קטנים וגדולים ורובם עברו ליצור וברובם הלקוח היה מרוצה. אפשר לדבר כמובן על זמנים, כמות המשאבים שהושקעה וכמות ה…. של הצוותים אבל זה לא רלוונטי הלקוח היה מרוצה והפרויקט הוגדר כהצלחה.
בקשר למהדורה שנייה שלישית ויותר זו כבר שאלה אחרת, התשובה לשאלה זו לא פשוטה ובטוח לא נעימה. אבל זה נושא לפוסט אחר.
בפוסט זה אני רוצה להתרכז בשאלת הקוד הנקי, כן אתם יודעים זה שמריח טוב, זה שלא שומעים בחדר WTF או על שאלה של כמה זמן נדרש להוסיף משהו או לשנות מקבלים את התשובה עזוב זה עובד לא נוגעים.
אני רוצה לשאול את השאלה טיפה אחרת, הם אתם גאים בקוד שכתבתם?
באופן אישי בכל פרויקט שפגשתי המפתחים היו גאים לפחות ביכולת, מחלקה, UI או צורת תקשורת. אותי באופן אישי זה היה מרגש. לראות מפתחים שגאים בעבודה שלהם זה כייייף.
אחת מהסיבות שאני אוהב להסתכל ולבחון פרויקטי קוד פתוח או SDK זו הסיבה שהיוצרים שלהם היו גאים, הרי הם פרסמו את זה בשמם…..
בשנים שלי בעולם התוכנה ראיתי לא מעט קוד שממש אמרתי ואו זה קוד מגניב גם אני רוצה לכתוב כזה/ככה. אז בואו נראה מה גורם לי לקנא
אני יכול לקרוא את הקוד כאילו קראתי סיפור.
אני מרגיש בטוח שכאשר תהיה בעיה בייצור יהיה מאוד קל למצוא ולתקן אותה.
אני מרגיש שהקוד לא ירסק את המערכת.
אני מרגיש שהקוד לא יפגע בביצועים או יגרום לזליגות.
אני מרגיש שהקוד לא תלוי בכל העולם וקצת יותר.
אני מרגיש שאפשר להחליף חלקים מהקוד במימוש אחר ועדין לא יהיו בעיות.
אני מרגיש שלא באמת חשוב באיזה שפה הכתב הקוד אבל אני יכול לתחזק אותו.
אני מרגיש שהקוד נכתב מתוך מטרה אמיתי ולא מתוך מטרה להרשים.
אני מרגיש שניתן לעשות שימוש חוזר בקוד.
אני מרגיש שהשקיעו מחשבה לפני שסיימו לכתוב את הקוד.
אבל הכי חשוב אני מרגיש שעשו את מה שעשו לא בגלל שהיו חייבים אלא בגלל שהם מקצוענים.
בכל מקרה תמיד נחמד לדעת שכאשר כתבו את הקוד זה לווה בחדוות עשייה.
במקרה ואתם נתקלים במפתחים שגאים בקוד שלהם דבר ראשון תהיו נחמדים! אל תזלזלו וקחו את הדברים הטובים תתרכזו בהם ותנסו לעזור איפה שצריך לשפר.
חשוב לזכור שכתיבת קוד זה תהליך שדורש אימון ולא תזיק הנחיה, אבל גם צריך לזכור שהאויב של הטוב זה הטוב ביותר.
באופן כללי יש לא מעט ספרים , סרטים , הקלטות ופוסטים איך לכתוב קוד ולהיות גאים בו. אני בטוח שכל אחד רוצה להיות גאה במה שהוא עשה.
לפעמים החוכמה זה לעשות דברים במקצוענות שבסיסה בתהליכים הנדסיים אבל שזה יראה כאומנות :-9 אל תשכחו אנחנו לא אומנים אנחנו מפתחים/מהנדסים.
אשמח אם תצרפו קוד שאתם גאים בו, תודה
כחלק מתפקידי בתור ארכיטקט אני נשאל לא פעם את שאלת מיליון הדולר???
"כיצד חולקים ידע מקצועי בתוך ארגון?"
התשובה היא קצרה, בקלות אבל עם הרבה אומץ לב!
ברוב הארגונים צוותי הפיתוח לא שווים ביכולתם, למען האמת זו משימה לא קלה לגדל צוות וזו משימה מאוד קשה לדאוג שכל הצוותים יהיו ברמה שווה וגבוהה.
למה אני אומר שזה קל….. כי אנחנו מתעסקים ביכולות נלמדות.
למה אני אומר שצריך אומץ…………. כי איזה מנהל ישקיע במשהו שהוא לא תוצר ממשי לטובת הלקוח ולא בטוח שבאמת התהליך יצליח.
יש לי מספר רעיונות שיכולים להפוך את התשובה לבאמת קלה.
חילופי סטודנטים זה עובד יפה בלא מעט מקומות בעולם. תקופת החילוף צריכה להיות מוגדרת מראש. אבל יותר חשוב המשימות גם כן ידועות והכי חשוב "הסטודנטים" צריכים להיות ברמה דומה. באופ אישי בפעם הראשונה אני ממליץ על לא יותר מחודש במשימות רוחביות עם מפתחים חזקים.
מנהל מתחלף
במקרה זה יודעים לאיפה נכנסים אבל לא יודעים כיצד יוצאים, על משקל אורח לרגע רואה כל פגע. בשיטה זו יש להגביל את התקופה לפרק זמן קצר יחסית. מי שמכיר את התכנית "אמא בהחלפה" זה עובד בשיטה דומה. מאוד חשוב לבחור בפעם הראשונה מנהלים עם מעוף.
סקרים משותפים
השיטה שבה הידע משותף בצורה הטובה ביותר במידה ומדובר בצוותים בוגרים ושנמצאים במצב של self leading . אני אישית אוהב את האזורים של ארכיטקטורה אבל במרבית המקרים הכי קל להיכנס דרך הצגות משותפות של קוד "שווה".
שבוע הזנק
יש לא מעט שעושים זאת בסוף שבוע של הזנק, אבל במסגרת עבודה שווה לקחת שבוע אחד. בשבוע זה שני צוותים או נציגים ממספר צוותים נפגשים ביחד. 9:00 יום ראשון עד 21:00 יום חמישי. מתחילים את השבוע עם רעיון ומסיימים אותו עם מוצר עובד. מאוד חשוב שיהיה מבוגר אחראי במגרש אבל הכי חשוב לספק את התנאים המתאימים לחדוות יצירה.
ימים בסגנון של Coderetreat
ימים כאלו שבהם ייקחו חלק משתתפים מצוותים שונים בהחלט מייצרים את הבסיס לשיתוף ידע! שווה לקרוא יותר בקישור הבא
אשמח לשמוע תגובות ובמיוחד לסייע למי שרוצה
את הפוסט הבא אני רוצה להקדיש לאחת מהחברות הכי טובות שלי
בעצם חוץ מבת זוגתי ב 27 שנים האחרונות היא החברה הכי טובה שלי.
היא לא רק חברה טובה שלי גם אדם שאני מכיר כבר 17 שנה ואני מניח שכבר ניחשתן שזו הבת המדהימה שלי רותם.
את הפוסט הזה שהנושא שלו זה בעצם GRIT אני רוצה לכתוב הרבה מאוד זמן.
בעצם מהפעם הראשונה שנפגשתי עם המושג הזה.
בשבילי אין יותר מתאימה ברמה האישית והבלתי משוחדת להסביר מה זה גריט יותר מאשר רותם.
כדי להסביר לכם מה גריט אני יכול לתת לכם דוגמאות מהמסע שרותם עוברת בחיים. לא מעט מהדברים רותם למדה לבד בלי שאף אחד סייע לה.
שתי שפות שלא לומדים בבית הספר ,ספרדית וקוריאנית. כן היא למדה ל ב ד.
כאשר רותם מציבה לעצמה מטרה היא מתרגלת ומבינה מה היא עשתה בסדר ולא בסדר.
את האהבה שלה לקונדטוריה ואפיה היא לקחה בצורה הכי מקצועית מגיל צעיר. היא הלכה לסדנאות של א.נשים מבוגרים ועם הרבה תרגול כישלונות והצלחות היום היא מקצוענית אמיתית.
גם באהבה שלה לריקוד היא לא התייאשה ותרגלה ותרגלה וגם אם לא נתנו לה לרקוד בשורה הראשונה היא אף פעם לא הפסיקה להתאמן ולהשתפר.
כמו אבא שלה היא אדם ממוצע, יש דברים שהיא טובה בהם יותר ויש שפחות. אבל היכולת של לעשות את המקסימום לא לפחד להיכשל ואז ללמוד הצלחות וכשלונות זה משהו שהיא תיקח איתה לחיים…. זה GRIT
את המושג GRIT פגשתי בהרצאת TED ולאחר מכן כמובן רצתי לעקוב אחרי אנג׳לה דאקוורת והספר מלווה אותי לא מעט זמן.
גריט על פי פרופסור דאקוורת זה השילוב בין להט התמדה ונחישות שמוביל להצלחה. המחקרים שלה שבאים לידי ביטוי בספר מראים שלא רק כישרון ומזל הם אלו המובילים להצלחה אלה גם תכונה נוספת שמתבטאת ב GRIT. זה בדיוק כמו הטעם הנוסף (החמישי) אוממי תמיד הבנו שיש אותו והבנו שהוא הופך אוכל למשהו אחר אבל רק לפני פחות מ 20 שנה הבנו שזה הטעם החמישי. בדיוק לדעתי כמו הגריט.
לצערי מערכת החינוך (בארץ וברוב העולם) מחנכת לעולם תעשייתי שבו מה שחשוב וכנראה רק מה שחשוב זו ההצלחה. הדרך פחות, ההבנה שאפשר לטעות ואפילו להיכשל והלימוד מזה לא פחות חשוב וכמובן שלא כולן.ם שווים עם אותה צורה של אפשרות ללמוד או לעבוד.
ולכן אנחנו הפילטרים שלנו הם לא תמיד מדוייקים ולפעמים (אפילו הרבה) מובילים אותנו למקומות פחות טובים.
שלא תבינו לא נכון – אני חושב לציונים יש ערך ולהצלחה ברור שיש ערך אבל זה לא מהות הכל. או כמו שמישהו פעם אמר לי, אין תחליף לעבודה קשה…. וחשוב מאוד להנות מהדרך….
בתור ארכיטקט פשוט ויזם שלא מפסיק לחלום אני מוצא שהגריט שלי זה שריר שאני כל הזמן צריך לתחזק ולחזק. ברור שאם אני מסתכל אחורה אני מבין שתמיד היה לי גריט, אני בוגר אוניברסיטה פתוחה :-9 וכמובן שהיו לא מעט אירועים (זה לפוסט אחר) שהגריט סייע לי להמודד איתם.
אני בטוח שאם נביט על 4 הנכסים שמגדלים גריט נראה שזה עוזר לנו להיות אנשי מקצוע יותר טובים ויזמות ויזמים אמיתיים.
כאשר אני משוחח עם נשות מקצוע או יזמיות ניתן לראות את הברק בעיינים, לשמוע את האנרגיה בקול ולהשתכנע שהדבר שהם משוחחים עליו הוא מעניין ואפילו מרתק.
אני יכול שעות לדבר על למה כל קח חשוב לכתוב קוד נקי או לחילופין למה מיזם מסויים הוא הדבר הבא שייצר השפעה חיובית על העולם או רק על אדם אחד.
ובאמת השאלה כאן היא של ביצה ותרנגולת אבל אני בטוח את היכולת למצוא עניין אמיתי בכל דבר שעושים היא חשובה, בצורה כזו גם המשימות היותר ״משעממות״ או היום יומיות יכולת להילקח בצורה איכותית.
במקום שאין עניין האדם יבוא לעבודה ולא יבוא לעבוד….
במסגרת המגע שלי עם א.נשים שונים אני תמיד מחפש את האלמנט הבסיסי שלי – האם העניין של האנשים קיים, אם לא השינוי/שיפור יהיה מאוד קשה.
כולנו בני אנוש ותמיד אנחנו רוצים לעשות דברים שיגרמו לנו אושר… ולעשות דברים מעניינים עם להט לרוב הא.נשים גורם לאושר
בתור אחד שכדורסל סל נמצא לו בדם 2 שחקני ענק ממחשים לי באופן אישי מה זה גריט…
מיקל ג׳ורדן ״"החטאתי מעל 9000 זריקות בקריירה שלי.הפסדתי כמעט 300 משחקים. ב-26 הזדמנויות סמכו עלי לקחת את הזריקה המכרעת במשחק…ופספסתי. נכשלתי שוב ושוב ושוב בחיי, וזו בדיוק הסיבה להצלחתי."
גם ארכיטקט הניצחון מ י ק י ברקוביץ׳ אמר לא פעם שהוא היה מגיע ראשון לאימונים וממשיך לזרוק גם שכבר כיבו את האורות.
כן, כן גם הכשרונים ביותר אם לא יתאמנו על בסיס קבוע לא ישתפרו. להיות מאסטרו צריך לפחות 10000 שעות אימון.
לצערי הרב במציאות של ימינו מפתח צעיר כבר אחרי שנתיים מוסיף לתיאור שלו את המילה ״בכיר״ כולם רוצים היום הכל מהר הכל שטחי. רק למי שיש גריט אמיתי עם יכולת התמדה יגיע באמת רחוק.
היכולת להבין כל פעולה איזו השפעה היא תייצר זה בעצם המצפן של של אשת המקצוע ו/או היזמית. אני תמיד אוהב להתחיל משאלת ה WHY ולאחר מכן ישר לענות כיצד הפעולה תקרה ליעד או תייצר השפעה.
טולקין בספרו ההוביט מתאר שהחבורה בכל שלב קשה בדרך הבינה מה התכלית ומהטרה שבגללה היא צועדת. וכן זה חשוב בתהליך של השיפור המתמיד של ה GRIT.
כאשר אני מלווה מיזמים אני מבקש מהם תמיד לשמור על הWHY נגיש ותמיד בזמנים מאתגרים לחזור ולראות האם אנחנו בתור קבוצה או בודדים מצלחים להגשים את השאלה או המטרה שאיתה יצאנו לדרך.
טוב כאן חייבים להגיד שאם לא הייתה אמונה (תקווה) צסקא לא הייתה אוכלת אותה.
יומיים אחרי שרותם נולדה היה המשחק שנקרא עד היום נס זלגריס. אם לגור לא הייתה אמונה שהוא יכול למסור ולדריק לא הייתה את האמונה שהוא יכול לתפוס ולקלוע העונה הייתה נגמרת לגמרי אחרי.
אני תמיד אומר שגם אם הדרך לא נראת מתקרבת לסופה בלפחות 50 אחוז מהמקרים אנחנו כבר עברנו את חציה.
בתור יזם או יזמת וכמובן בתור טכנולוג או טכנולוגית פרוצי דרך. תמיד תמיד חשוב למצוא את הנקודה שמייצרת תקווה. בסופו של דבר התקווה היא ספק אנרגיה מדהים לשיפור העבודה על הגריט.
ממש סיכום קצר- לכל אחת ואחד ממכן.ם יש GRIT יש כאלו שמהתחלה הוא שריר קיים אבל לכולנו יש את היכולת לשפר אותו ולעבוד עליו.
חשוב לזכור – התנהגות מובילה להרגל והרגל מוביל לאופי (טוב גם על זה אני מתכנן לכתוב פוסט)
כרגיל אשמח לשמוע כל משוב וכמובן לשוחח עם כל אחת ואחד ממכן.
פוסט זה אני רוצה להקדיש לדבר היחסי ביותר בעולם — זמן
אל תגידו אין לי זמן!!! קראו את הפוסט עד הסוף
ביום יום שלי אני מלווה הרבה פרויקטי פיתוח, קטנים וגדולים ותיקים וחדשים.
אבל תמיד ולא משנה מה המצב אני שומע לא מעט את הסיבה ללא לעשות משהו כ "אין לי זמן" חייבים לעמוד בלו"ז!
למען האמת לא חסרים לי סיפורים איך אנשים שאני מכיר וגם עבדכם הנאמן יצרו זמן במקומות שלא היו פנויים בזמן. אני רוצה להתמקד ב 2 מיצגים, יש עוד בערך 50 נוספים
יצא לי לפני מספר שנים להיות מפתח בפרויקט שעבר לא מעט ידיים, בין 5 ל 8.
כמובן שפרויקט היה כתוב לפי כל השכבות כולל שכבת WEB עשירה.
למען האמת כתבו אותו לא מעט מפתחים מוכשרים עד מוכשרים מאוד.
אבל הנקודה הכואבת הפרויקט מומש ב VB.NET. אני הוא איש של C++ או C# ו VB זה ממש לא אני :-9. כאשר שאלתי למה לא כותבים ב C# אמרו לי שהתחלנו לכתוב את הפרויקט הגענו מ VB6 ולכן VB.NET זה היה הכי טבעי לנו. אז כמובן בהתחלה אמרתי OK ננסה.
לאחר כ 3 שעות מ(ה/ע)נות החלטתי שדי זה לא יכול להיות, כל קטע קוד שהייתי צריך לכתוב כתבתי בתוכנית בצד ב C# ולאחר מכן בעזרת reflector ראיתי איך צריך לכתוב ב VB.
צעד זה עזר לי בערך לעוד 4 שעות, כלומר משכתי יום שלם.
לאחר מספר ימים כאלו החלטת שדי אני חייב לעשות משהו בנדון, אני חייב לציין שכל הפרויקטים באותו זמן נכתבו ב C# וכולם ידעו C#.
שוב פעם באמצעות reflector המרתי את כל השכבות למעט שכבת ה UI ל C# זה לקח לי ………………………………. יומיים.
מאותו רגע היעילות שלי עלתה פלאים ואת המשימה שתוכננה ל שבועיים סיימתי ב שבוע (כולל ההמרה)
אחד מהדברים שאני יודע לעשות ואוהב לעשות (ומקווה שעושה את זה טוב) זה לשפר ביצועים במקומות הקשים ביותר.
מקרה שקרה כך קרה, בפרויקט ענק שמבוסס WPF צוותי הפיתוח התלוננו על ביצועים גרועים במסכי תוצאות. כמו כל מערכת מידע מסכי תוצאות מגיעים אחרי מסכי שליפה. כל עצה שנתתי להם כיצד לנסות לשפר לקח למפתחים יום שלם להחזיר לי תשובה האם העצה עזרה או לא.
אתם בטח שואלים למה יום שלם? זה פשוט: קימופול אפליקציה –> הרצת האפליקציה –> העלאת צד שרת –> הבאת נתוני קונפיגורציה מהשרת –> הכנת נתוני שליפה –> ביצוע שליפה –> הצגת תוצאות במסך תוצאות, כמובן שבדרך השרת היה למטה, ה DB "נדפק" בגלל מישהו או כל סיבה מעכבת נוספת. לעצה שלי למה אתם לא בונים אפליקציה קטנה בצד קיבלתי את התשובה "אין לנו זמן זה כבר עובד בתוך האפליקציה שלנו".
לאחר זמן לא קצר וכמובן לאחר הרבה צעקות עד כדי רצון לוותר על WPF אמרתי לאחד המפתחים, תן לי יום אני רוצה לנסות לבדוק בעצמי.
בשעה הראשונה בניתי אפליקציה עם הXMAL של דף התוצאות. באותה שעה כבר לקחתי את הנתונים שהוכנו לתוך ה DataContext ובאמצעות DataContractSerializer הפכתי את ה DM ל XML.
מאותה נקודה לא הייתי צריך לא דף שליפה וכמובן שום צד שרת. כל בדיקה וניסיון שלי לקחו בדיוק 30 שניות ולא יום שלם. תוך פחות מיום שיפרתי את הביצועים ב 2.5 שניות ל 0.8 שניות וזאת רק ע"י ניסוי וטעייה.
כיצד מודדים זמן פיתוח, בואו ננסה לפשט
X- זמן הניתוח והעיצוב
Y – זמן הקידוד
I – זמן האינטגרציה
T – זמן הבדיקות
יש עוד לא מעט משתנים אבל למען הפשטות נשאיר זאת כך.
TOTAL=X+Y+I+T
כמובן שבעולם שלנו תמיד הזמנים לוחצים וצריך לספק תוצר ללקוח בזמן המהיר ביותר TTM.
ברור שהלקוח תמיד צודק, הוא רוצה בזמן מהיר תוצר איכותי ושנותן לו את כל היכולות שהוא ביקש. בואו נראה מה קורה בעולם האמיתי.
למשתנה X אף פעם אין זמן ושלא תבינו לא נכון צריך לתת ל X את הזמן הראוי לא אבל לא יותר מידי, לדוגמא ארכיטקטורה/עיצוב על למערכת הכי מורכבת לא צריך להיות יותר מחמישה ימים.
משתנה Y – כאשר תמחרו לנו את זמן Y ברור שתמחרו אותו ללא כל הדברים מסביב וכולם לחוצים שהמפתחים יסיימו כמה שיותר מהר. אז מה עושים…… כותבים קוד כדי שייתן מענה עסקי (אתם זוכרים יש לקוח בקצה) ואת כל השאר משאירים לסוף ומה זה כל השאר? טיפול בשגיאות, תיעוד , ביצועים, רישום ל LOG ועדכון העיצוב.
משתנה I – אחד מהנושאים הכואבים בכל פרויקט חומרה , תוכנה , ספורט וכדו' ככל שיש יותר שחקנים יותר קשה לבצע אינטגרציה.
משתנה T – שלא תתבלבלו בדיקות לא נועדו להוכיח שמה שפיתחנו תקין………… בדיקות נועדו לבדוק האם מה שפיתחנו "דפוק"
וכמובן שאתם כבר יכולים לראות מה קורה X<=>I<=>T<=>Y משפיעים רבות אחד על השני.
במערכת בריאה אנו נראה התכנסות, במערכת פחות בריאה נראה התבדרות
כמובן בגלל ההתבדרות שהיא בחוג פתוח (כדור שלג) נשמע יותר ויותר את המשפט "אין לי זמן"
האמונה שלי שתמיד אפשר לייצר זמן במיוחד במקומות שבהם קל להגיד "אין לי זמן".
אחד התפקידים שלי בתור ארכיטקט זה לייצר לכל השותפים בתהליך זמן.
אני רוצה לדבר על כמה חשובים
דעתי בנושא ידועה, אבל אני רוצה להמחיש אותה בסיפור קצר.
חברה ישראלית הייתה צריכה להקים פס ייצור לשם כך שכרה חברה אמריקאית שנתנה הצעת מחיר אטרקטיבית במועד סיום תואם לצורך חודש מתחילת הפרויקט.
הגיעו 3 מהנדסים אמריקאים שבמשך 3 שבועות ישבו וחשבו ורשמו רישומים, אבל שום פס ייצור לא התחיל לקום. כמובן שהישראלים היו לחוצים מה קורה עם פס הייצור? יש לנו לוחות זמנים. וכך שבוע לפני מועד הסיום פירקו המהנדסים את הציוד הרכיבו אותו חיברו לחשמל וביום ה "ש" אמרו שניתן להרים את החשמל. ברור שהכל עבד :-9
כן אני יודע אתם חושבים ישר על Agile אבל זה לא רק זה. אפשר לעשות זאת בעוד מספר דרכים לא פחות טובות. הבסיס הוא פשוט אם תהליכי הבקרה יבוצעו בצורה מסודרת וידועה מראש (ללא תקורת זמן מיותרת) ונעשה זאת על פרק זמן קצר הטעות שתצטבר תמיד אבל תמיד תהיה קטנה. הרבה יותר קל לתקן טעויות קטנות בשוטף מאשר טעות אחת גדולה בסוף.
קוד לא איכותי משפיע ישירות על Y,I,T גם בטווח הקצר וגם בטווח הארוך. בתוך ניסיון אני יכול להגיד בצורה ברורה השקעה מינימאלית באיכות קוד מייצרת באופן ברור חיסכון ב Y,I,T. ברור שניתן להגיע לזה במספר דרכים פשוטות כגון סקרי קוד, static code analysis , peer programming וכמובן "חיילות פרט"
ללא ספק כלים אוטומטיים הם חסכני זמן לא קטנים.
אבל מה, הבעיה היא שאין לנו זמן להכניס לפרויקט תהליכים אוטומטיים בנושאים השונים כגון… build's , בדיקות יחידה/עומסים/UI/זיכרון, תהליכי הפצה , תהליכי בקרה וכו'
אז עושים זאת לאט ובזהירות
בנקודה זו אני רוצה לתת דוגמא אשר תמחיש את העניין.
לוגים באפליקציה הם בעיני ההבדל בין חובבנות ולמקצוענות.
לצערי הרב ברוב המקרים המתכנתים רצים לכתוב קוד שנותן פונקציונאליות וכל השאר לא מעניין אותם את הלוגים בקוד הם ישאירו לסוף הפרויקט. ואני תמיד שואל למה לדחות???? הרי אני כבר נמצא בקוד אז למה לא להיות מפתח נחמד ולכתוב עוד כמה שורות קוד שיספקו לוגים/טיפול בשגיאות/הערות.
אני מבטיח לכם שלהוסיף את כל הדברים החשובים האלו בסוף הפרויקט זה דבר בלתי ישים בעליל, מה שקורה זה כשיש בעיות אז נזכרים בדברים האלו….. ואז זה לפעמים מאוחר מידי ומעט מידי.
אם נשקיע בשוטף יהיה לנו יותר זמן בהמשך, במקום לכבות שריפות נוכל לפתח דברים חדשים!
"אין לי זמן" לתכנן את הבדיקות הבודקים שלנו בעלי ניסיון.
הכוונה–> הבודקים שלנו הם בעצם הלקוחות
"אין לי זמן" לבצע עיצוב גרפי והנדסת אנוש.
הכוונה–> מה הלקוח עובד רק על סוג אחד של מסך ורזולוציה קבועה
"אין לי זמן" לבצע סקר קוד בכל מקרה הלוגיקה פשוטה.
הכוונה–> נו באמת סקר קוד זה אומר שהגרסה שלי תתעכב ותהיה יותר עבודה
"אין לי זמן" לבצע בדיקות זיכרון.
הכוונה–> מה זיכרון , הרי יש לאפליקציה 1G לפחות . הכי הרבה פעם בשעה שהלקוח יתחיל אותה מחדש
"אין לי זמן" לבדוק ביצועים.
הכוונה–> הלקוח לא שילם על ביצועים הוא שילם על יכולות, לביצועים תהייה עוד גרסה
"אין לי זמן" לבצע עיצוב על יש לי רק חודש לקידוד.
הכוונה–> זו באמת עשיתי זאת כבר עשרות פעמים למה צריך עיצוב הכול יושב לי בראש.
"אין לי זמן" לבדוק את המערכת בעומס.
הכוונה–> נו באמת בעולם של היום שיש ענן אז נגדיל את עוצמת המחשוב, בכל מקרה זה הלקוח משלם.
"אין לי זמן" זמן לתעד את הפיתוח.
הכוונה–> למה לתעד בכל מקרה אני לא אהיה פה במהדורה הבאה
"אין לי זמן" לחשוב על הנדסת תוכנה גם כך הפיתוח הוא זמני עד למוצר הבא.
הכוונה–> מה שזמני קבוע…… המוצר הבא יהיה בדור הבא.
בשנים האחרונות ראיינתי מספר מועמדים למספר תפקידים. מי שרוצה לשמוע איך עושים זאת במקצועיות יכול לשמוע את הפודקאסט בסדרה החדשה של אורי לביא וליאור כהן.
בפוסט זה ברצוני להרחיב ולהוסיף מספר דעות שלי.
הפוסט נכתב בלשון זכר אבל הוא מיועד גם למין החזק.
ראשית תמיד עלינו לזכור שאנחנו אנשי מקצוע, המקצוע שלנו זה… תוכנה , חומרה , ניהול וכו'.
המקצוע שלנו זה לא לגייס, בשביל זה יש אנשים מקצועיים שזה תפקידים.
בעיני אנשים אלו הם אחד מהגורמים החשובים בחברה! אל תשכחו המועמד שומע אותם בטלפון מדבר איתם ושואל אותם את השאלות הראשונות על החברה והתפקיד.
רוב תהליך הגיוס קורה דרכם והרושם שהמועמד מקבל על החברה ועל החלטה האם להצטרף לחברה נגזר לא מעט ממשק עם האנשים החשובים האלו.
באופן אישי, לי מאוד מאוד כיייייייף לעבוד איתם.
התפקיד שלנו זה להשלים לאנשי הגיוס את מה שחסר מבחינה מקצועית והטמעת המועמד לתפקיד. ברור שבסוף הבחירה היא שלנו האם המועמד מתאים לנו או לא.
ראשית שהוא בן אדם והדגש הוא בן אדם טוב.
שיש לו יכולת לעבודת צוות וגם לעבוד לבד
כמובן לא מעט שהדברים שהזכיר אורי בפודקאסט.
בחינה האם הוא מתאים לקבוצה שהוא מתוכנן להגיע אליו. ברור שקבוצה יכולה להשתנות אבל התאמה לקבוצה תעזור לתקופה הראשונה בעבודה שזה לא פחות חשוב בכל תהליך הגיוס.
עוד משהו שחשוב לבדוק זה מה מפת הדרכים של המועמד.
מה התפקיד שהוא מיועד לו.
מה האפשרויות שלו בחברה
לאיזה קבוצה הוא הולך להגיע
טיפה על טכנולוגיה ומתודולוגיה
והכי חשוב שהוא מגיע למקום של בני אדם (טובים) והוא לא פיון
מאוד חשוב לי לראות האם מועמדים שראיינתי והמלצתי עליהם באמת התאימו והם היו מרוצים והחברה מרוצה, אני בודק זאת לאחר 3 חודשים וגם בפרקי זמן ארוכים יותר.
אני שמח לראות שאין לי פספוסים, עד כה……..
אשמח לשמוע דעתכם.ן,
פורסם לראשונה בבלוג הישן ב – יולי 2010
לעיתים השוני שבמילה הוא כל כך מהותי.
אני רוצה לצרף דוגמא קטנה שעוברת לי בראש לא מעט זמן.
כאן בישראל נהוג לכנות את מה שאנחנו עושים למחייתנו במספר שמות שונים.
מתכנת, מפתח, מהנדס תוכנה | מתכנתת, מפתחת, מהנדסת תוכנה
לקחתי את המילים הקודמות והעברתי אותם ב google translate מה יצא???
programmer, developer, software engineer
האם למישהו.י יצא מתי שהוא לקרוא לעצמה.ו programmer? או לקרוא למישהו אחר programmer?????
אני מניח שלא, זה תמיד נע בין developer לבין software engineer.
אפשר לדבר הרבה מה מסתתר מאחורי המילה ואני בוחר לא לעשות זאת כי אני חושב שכל אחד מבין את המשמעות!
תוכלו למצוא דיון מעניין בקישור הבא
אז אולי נוכל אנחנו להתחיל שינוי (אני התחלתי כבר לפני מספר שנים 
) בואו נתייחס בכבוד למקצוע ונשתמש במושגים מפתח תוכנה או מהנדס תוכנה. לתכנת כל אחד יכול…..
כרגיל תגובות יתקבלו בברכה
הפוסט המקורי פורסם בדצמבר 2012 עברו מאז כבר שמונה שנים אבל אמא שלי שכבר אז היתה חסרה לנו הרבה יותר מידי זמן לא פחות חסרה לנו גם היום. כל ילד צריך לפחות אדם אחת.ד שיאמין בו, אימי היית זו שהאמינה בי ולימדה אותי שהבלתי אפשרי הוא אפשרי
הוביט "התרגום השחור" ו Peer Programming
ההוביט – הפגישה הראשונה
האהבה הראשונה שלי היא הספרים. בעצם הספרים מלווים אותי בערך מגן חובה. המתנה שביקשתי מהורי לחג פסח (כן "מצאתי" את האפיקומן) זה מנוי לספריה העירונית.
בכיתה ג כבר קראתי בקצב של 2 ספרים ביום, כל ספר בעברית שהיה מסומן לקבוצת הגיל שלי קראתי. בכיתה ד זה כבר היה קצב של 3 ספרים ליום, הגעתי למצב שבו כבר בדרך מהספרייה הייתי קורא ספר (וכמובן מתנגש בכמה עמודי חשמל בדרך).
אימי ז"ל גם כן אהבה לקרוא ספרים ותמיד היה לה ספר קריאה בהישג יד,
כמובן שלאחר שסיימתי לקרוא את ספרי הספרייה הייתי פוזל לספרים שלה.
בחלק מהפעמים גם הספרים שקראה התאימו לגילי , כיתה ד אתם זוכרים.
לאמי בארון תמיד היה ספר שקראו לו הוביט דווקא אליו לא נמשכתי.
ספר בכריכה שחורה שתמיד נראה לי כמו ספר בישול, אל תשאלו למה הוא נראה לי כך אבל הוא נראה לי כך :-9.
בערך באמצע השנה קצב הקריאה שלי השאיר אותי שעות שלמות ללא חומר קריאה. וכמו שאתם מנחשים בסוף לקחתי את הספר השחור שנראה כמו ספר בישול ליד. ואז בעצם לא הפסקתי לקרוא אותו, למען האמת בשנותי על פני האדמה קראתי אותו עשרות פעמים בתרגום השחור כמה פעמים בתרגום המקצועי ואפילו בשפת המקור.
מה זה הוביט
הוביט נכתב ע"י הפרופסור והסופר המחונן ג'ון רעואל רונלד טולקין הספר יצא לאור בשנת 1937. בעיני רבים נחשב כאחד מאבות הזאנר של סיפורי ה D&D.
אין דרך טובה יותר לתאר בעצם מה זה הוביט אלה ע"י תיאור ישיר מהספר.
מה זה בעצם הוביט? אני משער לעצמי שיש צורך בתיאור הוביט בימים אלה, מאז הפכו נדירים ונעשו ביישנים מפני "האנשים הגדולים" …. יצורים זעירים כמחצית קומתנו, וקטנים אף מהגמדים העבדקנים. להוביט אין זקן. לא אופף אותם קסם מיוחד, פרט לכושר הטבעי להיעלם בשקט ובמהירות כאשר יצורים גדולים ומטופשים כמוני וכמוך משוטטים ומקימים רעש כמו פילים, שההוביט יכול לשמוע ממרחק פרסה. הם נוטים להשמין, בעיקר לגדל כרס ומתלבשים בצבעים בהירים (לרוב ירוק וצהוב) אינם נועלים נעלים, היות ורגליהם מגדלות סוליות עור טבעיות וכיסוי חמים של שיער עבות, כמו שעל ראשם המתולתל. הם בעלי אצבעות ארכות ומיומנות, פנים המבעים טוב לב וצחוקם עסיסי, במיוחד אחרי ארוחת צהרים.
בקיצור ההוביט הם יצורים שובי לב, אבל לא ממש הסוג של הגיבורים. הספר מספר על בילבו הוביט שנחשב רגוע אבל בשילוב עם הקוסם האגדי גאנדאלף וחבורה של 13 גמדים עובר הרפתקה שמשנה אותו מקצה לקצה. ההרפתקה מטרתה להציל אוצר מידי דרקון אולם בדרך אנחנו מגלים את העולם המופלא שטולקין טווה בדרכו הציורית הקולחת והמיוחדת. למען האמת ניתן לדבר רבות על הספר הזה (כמובן שאשמח עם מי שרוצה) אבל בטוח שכולכם מכירים את הספר/סרט טרילוגיה שר הטבעות.
הספר תורגם לראשונה ע"י משה הנעמי בשנת 1976 אולם אני רוצה לדבר דווקא על התרגום המיוחד ובעיני המדהים של טייסים שנפלו בשבי המצרי וראה אור בשנת 1977.
ניתן לראות את ההוביט כספר ילדים (240 עמודים) אולם הוא שווה עשרות מיליונים של קוראים.
תהליך התרגום של הטייסים
התרגום התחיל בחורף 1971. 10 אנשים בשבי המצרי מייצרים מסגרת של חיים בשבי (לא זה לא האח הגדול ולא שודר 24/7). החברה יצרו מסגרת לימודים שבו כל אחד לימד את כלל החברים את מה שהוא יודע. אפשר לומר שהם קראו הרבה, אחד המתרגמים קרא מעל 300 ספרים. וכן הם קיבלו את טרילוגיית שר הטבעות שיצרה להם עולם אלטרנטיבי לשבי ולאחר מכן קיבלו גם את ההוביט. הם נהנו המיוחד מההוביט שבגלל שכוון יותר לילדים כלל הרבה הומור. כאמור הם היו 10 שידעו אנגלית וכל השאר לא בדיוק שלטו בשפה, לכן הם החליטו לתרגם את הספר.
הם עבדו בזוגות פחות או יותר כי במלאכת התרגום עסקו 7 אנשים כאשר אחד קורא את הטקסט באנגלית ודיבר אותו בעברית והשני כתב בעברית. לאחר העברית "הלא קשורה" בנה הזוג עברית לוגית. אם לזה לא קוראים Peer programming אז אני לא יודע למה כן. ה 7 לא היו מתרגמים מקצועיים ואפילו לא הכירו את עקרונות התרגום. אולם הם יצור להם כללים לוגים. למשל, בגלל שחלק מהתרגום של הגזעים לא הסתדר במבנה יחיד ורבים לדוגמא אלפים לא יוצא טוב ביחיד אלף (זכרו זה לפני סדרת הטלוויזיה) לכן הם יצרו כלל שבו לצורת הרבים הם מוסיפים את ה' הידיעה לכן ההוביט ברבים והוביט ביחיד (כשם הספר). הם בהחלט עברו חוויה של פעם בחיים. התרגום של הספר לקח להם 4 חודשים של עבודה קבוצתית. אתם בטח שואלים למה הם לא תרגמו גם את הטרילוגיה הרי נשארו להם עוד 3 שנים בשבי? התשובה מתחלקת ל 2 ראשית בלשון הומוריסטית הם רצו לשמור את שר הטבעות לפעם הבאה ו שנית לאחר 4 חודשי תרגום נותרו 2 מחנות חבורת המתרגמים ואלו שלא ולכן הם העדיפו לשמור על אחדות החבורה.
ניתן לקרוא את הטור המלא של מלאכת התרגום מפי רמי הרפז http://numenore.com/28/
לסיכום קצר, הספר השחור אצלי למעוניינים. בעיני אחד מהספרים הטובים ביותר שקראתי (וקראתי הרבה) כל פעם שאני קורא אותו מקבל מימד חדש על הספר ועל החיים בכלל. הנאה צרופה.
באופן כללי אני מוצא את עצמי נתקל בהרבה דוגמאות מהחיים שלא קשורות לעולם הפיתוח המדמות מצבים שקיימים ביום יום שלנו ממש מתחת לאף
את הפוסט הזה רציתי לכתוב ישר ששגיא המדהים פגש אותי בשעת לילה מאוחרת בערב הראשון של חודש דצמבר ,ביקור מאדם עם חלומות מרתקים אנרגיה אין סופית והיכולת לחבר אנשים עם האהבה לכדורסל ה NBA לסיכום עונה מאגדות.
בעצם אורן לוי ושגיא רפאל הרכיבו נבחרת של כותבים הרימו מסע גיוס בהדסטארט הוציאו בזמן מהיר את הספר שמסכם את העונה היוצאת דופן שעברה על ה NBA, עונה שאף אחת ואחד לא תשכח.
אני זכיתי לביקור עם הקדשה אישית והקהילה זכתה לספר איכותי (במהדורה לאספנים בפחות מאלף עותקים).
אורן , שגיא, הכתובים ובעצם כל החברות והחברים שתרמו למסע אין סוף תודה רבה.
אותי זה מרגש וממלא תקווה שלפעמים חלומות מתגשמים.
היצירה שלכם פשוט מרתקת, ממש כייף לראות איך הכל הפך להיות למשהו בעל משמעות
אה, משהו קטן אנחנו ב frenziQ זכינו לקבל פרק עם הקדשה. הפרק קשור לקבוצה עם המשחק הקבוצתי המרשים ביותר בעונה מאגדות (משאיר לכן ולכם למצוא את הפרק) ;-9 בעיני הוא אחד משני הפרקים המעולים בספר וזה כאשר מרבית הפרקים מדהימים.
הספר מתאים לא רק לאוהדות אוהדי הכדור הכתום, הוא מתאים לכל אחת ואחד שמתעניין בניהול ברמות הגבוהות ביותר. כמעט מכל פרק ניתן לראות שכדורסל NBA הוא הרבה יותר מכדורסל ותפיסות הניהול שמובאות בסדר יכולות להיות מאומצות על ידי כל מנהלת ומנהל יכול.ה לקחת משהו.
וכן גם 2 הפרקים האחרונים בספר הם יצירה מרתקת , אהבתי מאוד את דרך העברת מסרים לדני ויותר אהבתי את הראיון טיפני מיטשל כולל המשמעות של מאמנת שהיא בעצם מנטורית לחיים (דון סטיילי)
כל מי שרוצה לקבל בהשאלה לקריאה את הספר המדהים, אשמח לחלוק. אבל ספר כזה כל אחת ואחד חייבת שיהיה בתור פריט אספנות ותור מקור לידע וחוויה
וכמו שהבטחתי לשגיא, בעונה הבאה מבטיח שאם יהיה עוד מסע לספר אני אחבר עם הגורמים המתאימים ללוגיסטיקה האין סופית בשליחת התשוקות והספרים
שלא תפסיקו את האהבה לכדור הכתום
אני ממש לא איש של בוקר.
אבל אתגרי התקופה זימנו לי את הזכות לבוקר עם החצי המדהים שלי.
אה, ועל הדרך גם לתפוס תמונות יוצאות דופן :-9
אני יודע שלא מעט קוראות וקוראים ירימו גבה על מה שהם יקראו בשורות הבאות של פוסט זה :-9
כזכור בלוג זה מייצג רק את דעתי האישית…… אתם יכולים להסכים או לא….. אבל תמיד אשמח לתגובות.
על מנת שפרויקט פיתוח יצליח , ברמת סמך גבוה , על התנאים הבאים להתקיים בסדר הבא:
טוב למען האמת סעיף 5 זה מאוד נחמד שיהייה אבל הוא לא הכרחי. אני טוען שאם נעשה את השלבים הקודמים או שלא נהיה צרכים אותו או שאם אנחנו צרכים אותו אז המצב שלנו לא כזה פשוט.
אשמח לשמוע כרגיל את דעתכם
האם ארכיטקט.ת טוב.ה היא אשת מוצר טובה? וואו זאת שאלה ממש מעניינת, לפחות אותי
כן כן אני בטוח שגם ארכיטקטיות וארכיטקטים וגם אנשי ונשות המוצר עכשיו אומרים מה, מה פתאום? הפוסט הזה לא הגיוני וזה ממש לא עושה שכל.
גם אני בהתחלה חשבתי שבאמת זה לא עושה שכל כאשר אני אומר ״מהתחלה״ זה היה לפני הרבה שנים בתחילת המילניום כאשר הדעות שלי היו הרבה פחות מגובשות על עולם הייטק הישראלי והגלובלי.
באופן אירוני זה בדיוק מה שאני עשיתי בתור מפתח צעיר –> הייתי גם איש חומרה וגם יש תוכנה וגם איש המוצר. הסיבה הפשוטה היא שבעצם גדלתי בתחום שבו הפכתי להיות מטכנאי למפתח ולכן זה היה הכי טבעי להיות זה שיכול להגדיר ברמה עסקית תפעולית וטכנולוגית את קו המוצרים החדש.
זו היתה ממש סגירת מעגל , אם בצבא הייתי זה שבתור חייל צעיר השתמשתי במוצר ואחרי זה גם בתור חייל יותר ותיק ואיש קבע גם קלטתי מעבדה שלמה שקשורה לאותו מוצר (במקביל התחלתי ללמוד באוניברסיטה הפתוחה ניהול ומדעי המחשב) אז השלב הבא היה לעבור לתעשייה אווירית (תמ״מ) ושם הייתי מהנדס חומרה|תוכנה|מוצר .בעצם התיקון הראשון של הקוד שעשיתי היה על מוצר שכתוב בפסקל ורץ על DOS והמטרה הייתה לעשות אופטימיזציה בקוד על מנת לפנות מקום לפונקציה נוספת.
זכיתי כבר בגיל צעיר יחסית (אמצע שנות העשרים שלי) להתחיל פיתוח של מוצר משלב היזמות דרך כל שלבי הפיתוח המסירה וההטמעה, בגלל הנסיבות שונות ומשונות בסוף זכיתי להיות מהנדס המערכת (איש המוצר) מהנדס החומרה ומהנדס התוכנה.
כן * כן המוצר החדש החליף גם את המוצר הישן בצבא (ובעוד לקוחות ברחבי העולם) כמובן שהמיזם הזה יקבל פוסט נפרד
אני מניח שהבנתם שאני חושב שארכיטקטית טובה יכול להיות איש מוצר טוב אני לא מתכוון לארכיטקט צעיר או ארכיטקט שמלווה צמוד צוותי פיתוח ואני לא מתכוון על product צעיר או מאפיין אני מתכוון על ארכיטקט מנוסה שהצליח.ה לעשות עבודה באמת מערכת/ארגון מקצה לקצה.
אני מאמין שארכיטקט או ארכיטקטית טובה שלא מתעניינית רק בפונקציה או בסיס הנתונים או API או החידוש הטכנולוגי האחרון אלה זו שבאמת עושה ארכיטקטורה כמו שצריך יכולים אם יש רצון להיות מנהלת מוצר טובה, למען האמת יש לא מעט דוגמאות מהתעשייה בדיוק לכזה דבר.
לאורך השנים ובצורה מאוד מפוקסת בזמן האחרון אני מוצא יש הרבה קווי דמיון וראייות שיש מספר נושאים שאם הארכיטקט.ית עושה אותם טוב ב אז לחלוטין זה סוג של ניהול מוצר.
הרבה פעמים מוצאים שארכיטקטים טובים הופכים להיות מנהלי פיתוח (טובים?) אבל יש לא מספר מקרים במיוחד בחברות מוצר שבהם הארכיטקט.ית עוסקת גם בתחום ניהול המוצר עד ל founder & head of product.
טוב לאחר הפתיחה בוא נעבור על הנקודות המעניינות
אין ספק לעסוק בהובלת מוצר ברמת מקצוענות גבוה זה הרבה יותר מלהיות עם ניסיון רב באפיון. הובלת מוצר איכותית משלבת נושאים נוספים הקשורים להבנת הצרכים העסקים ברמה שמעל הממוצע היכולת להבין את אסטרטגיית החברה ומשם לגזור את מפת הדרכים של המוצר ומה זה צריך להיות במוצר ומה לא על בסיס הצרכים העסקים. זו יכולת שלא ניתן להתפשר אליה.
ואכן גם להיות ארכיטקט.ת מזקק את הדרישות האלו (בנוסף לכל היכולות הטכנולוגיות וההנדסיות).
אני רוצה לגלות לכל מאות אלפי הקוראות והקוראים של הבלוג שלי (כן כן גם אני אחד מעשרות האלפים שמאזינים למפתחים חסרי תרבות) לאורך כל ההיסטוריה של עולם התוכנה אנשי ונשות המוצר הטובים ביותר היו מהנדסי תוכנה מהמובילים בתעשיה טיפה דוגמאות
17 מהנדסים שיצרו את המושג Agile בשנת 2001
אותו גאון יחיד ומיוחד שהמציא את המותג של התפוח וגאון לא פחות בטוח גם מיוחד שבלעדיו חלונות לא היה מותג שנמצא אצל כולנו
דורית דור המדהימה מצ'ק פוינט וכן גם גיל שוויד
וכמובן לא מעט יזמות ויזמים שהיו ארכיטקטיות מאוד טובים והפכו להיות אנשי מוצר לא פחות טובים
ארכיטקט נוסף שממנו למדתי לא מעט הוא Juval lowy שאומר שהבסיס לארכיטקטורה טובה זו הבנה של גבולות הגזרה עסקיים והבנה מה יכול להשתנות ומה כנראה אף פעם לא ישתנה.
ארכיטקטים ארכיטקטיות בתחילת דרכן נוטים ישר ״לברוח״ לפרטים הטכנולוגים וזאת ללא הבנה באמת מה הם אמורת לבנות.
נשות ואנשי מוצר (ויצא לי לפגוש לא מעט מהן) ידעו לעשות את העבודה שלהם ממש כמו שצריך. אבל הטובות והטובים ידעו מעבר, הרבה מעבר כלומר חשוב מאוד להבין האם יש שיקולים עסקים ואפילו מגבלות, איפה נמצאת הטכנולוגיה ואיפה היא לא יכולה להיות ולא פחות חשוב אילו שיקולים משפיעים על עלויות . כמובן שגם היבטי משאבי כוח האדם בפרויקט בחברה ואפילו בתעשייה מהווים נדבך משמעותי בהבנת המגבלות
מרבית הפרויקטים שיצא לי לראות (וראיתי מאות פרויקטים ומוצרים) לא הצליחו או נכשלו בגלל גורם אחד אבל תמיד ההובלה של הארכיטקטורה הייתה חייבת לקחת בחשבון את כל הנושאים שגם הובלת המוצר צריכה לקחת כאשר זה לא נלקח הארכיטקטורה במקום להיות גורם מאפשר הפכה להיות גורם מזיק. וכן הארכיטקט או הארכיטקטית תמיד חייב להסתכל לא רק על הטכנולוגיה אלה גם על כוח האדם , המגבלות של העולם העסקי וכמובן גבולות גזרת המוצר
נשות ואנשי מותר טובים חייבות לדעת לספר את הסיפור ולהעביר את המסר, לעיתים המסר לנמענים השונים (הנהלה , משתמשים/לקוחות , צוותי הפיתוח) צריך להיות ארוז בצורה שונה. תמיד המסר צריך להביא את כל הגורמים השותפים להסתכל על אותו צורך/אתגר ולהבין מה צריך לעשות ויותר חשוב מה יהיה בערך העסקי ואיך נדע שהוא באמת ערך ולא ״נפנופי ידיים״.
גם כאן מתקיימת הלימה חזקה, כל ארכיטקטית וארכיטקט שאני עובר איתה או איתו את המסע של להיות איש.ת מקצוע יותר טוב.ה, אני מלמד את עקרון המפתח לקבלת משוב מהיר ואיכותי – אם צוות הפיתוח לא הצליח לממש את הארכיטקטורה שתוכננה האחריות ברוב המקרים היא על בונה הארכיטקטורה. זו הסיבה שאני כל כך אוהב לעבוד בתפיסת Agile בצורה כזו אני מקבל משוב מאוד מהיר האם הארכיטקטורה שתכננתי (יחד עם כולם) באמת עובדת ואני לא צריך לחכות חודשים ואפילו שנים על מנת לדעת זאת.
הארכיטקט.ת צריך גם לדעת לספר את הסיפור למנהלים ומקבלי ההחלטות ואפילו לצד הטכני והעסקי של הלקוח.
אני זוכר בתחילת דרכי בתור ארכיטקט צעיר איך היה קשה לי להעביר מסרים טכנולוגים , אני מקווה שעם השנים השתפרתי :-9
ארכיטקט.ת טוב חייב להיות מהנדס ולכך אלמנט המדידה צריך להיות מושרש בכל דבר שהוא עושה. וכן גם איש או אשת מוצר טובים חייבים לדעת לא רק להגדיר את הצורך העסקי ואיך נממש אותו אלה לא פחות חשוב איך נוודא (מדידה) שהוא באמת מספק את הערך שתיכננו.
מעל ל 60% מהיכולות לא באמת משתמשים בהם וברוב המקרים ממש לא מודדים אותם.
לארכיטקט צעיר וגם לאיש מוצר צעיר יש הרבה אפשרות לכל דבר, ארכיטקטת מנוסה ואיש מוצר מנוסה יודע לגדר את האפשרויות ל 2-3 ולא יותר ובעצם על בסיס האינטואיציה להבין איזו אפשרות היא המועדפת תוך הבנה של כל מרחב הבעיה. אני במקצוע כבר מעל ל 20 שנה וארכיטקט במשרה מלאה כבר 15 שנה ואני עדין נמצא במסע שלי, אני אומנם לא ״ירוק״ אבל יש לי עוד דבר או 2 ללמוד. בצניעות במאת בצניעות, מניסיון אני לחלוטין יודע היום לספק את בתור ארכיטקט את הפתרון המתאים (ואלי עוד אחד אלטרנטיבי) בתור איש מוצר אני עדין ברמה של 2-3 לכן בנתיב של איש מוצר יש לי עוד מסע לעבור.
תשאלו 9 אנשי ונשות מוצר כיצד הן מגדרים PMF תקבלו 10 תשובות הובלה אמיתית של מוצר היא בעצם היכולת להגדיר מהו ה PMF של המוצר , הדעה האישית והצנועה שלי PMF יכול להתעדכן ןצען האמת צריך להתעדכן לאורך כל חיי המוצר כלומר אם הגיעו לאחד ישר נגדיר את הבא בתור.
ולמרבה ההפתעה זה עובד בדיוק ככה בארכיטקטורה, תשאלו 9 ארכיטקטים כיצד הם מגדירים ארכיטקטורה נכונה תקבלו 10 תשובות. בניה של ארכיטקטורה שמובילה Antifragility זה הדבר הנכון וכמובן לפי אורך חיי המוצר הארכיטקטורה צריכה להשתנות ולהתאים את עצה לצרכים העסקים , טכנולוגים ולסביבה הנושמת
מגיל מאוד צעיר הרגילו אותנו שלטעות זה דבר לא טוב. הרגילו אותנו שציונים זה הדבר הכי חשוב, אם תשאלו מנהל או מנהלת כמה פעם הם טעו או נכשלו בחיים הסיכוי שתקבלו תשובה גדולה מ ״0״ היא לא גבוהה.
אני תמיד מנסה להעביר את המסר שבתור אנשי ונשות מקצוע שעושים ברוב המקרים דברים חדשים ואפילו חדשניים זה בסדר גמור לטעות ואפילו להיכשל. החוכמה היא ללמוד ולא לחזור על אותה טעות פעמים ויותר חשוב זו היכולת להודות בכישלון ואני לא מתכוון בצורה של להרים ידים ולפרוש אלה להבין שזה בסדר גמור להיכשל אבל מה שחשוב זה ללמוד מהדרך ואם יש צורך לשנות הרגלים על מנת להצליח בפעם הבאה.
כמו שמיקל אומר ״החטאתי מעל 9000 זריקות בקריירה שלי.הפסדתי כמעט 300 משחקים. ב-26 הזדמנויות סמכו עלי לקחת את הזריקה המכרעת במשחק…ופספסתי. נכשלתי שוב ושוב ושוב בחיי, וזו בדיוק הסיבה להצלחתי״
אסור בתחילת האיסור גם לא לנשות ואנשי המוצר וגם לא לארכיטקטיות והארכיטקטים להישאר רק עם הידע שיש להם. על מנת להיות אלו שמבאים את הכי הרבה ערך חייבים כל הזמן להתחדש, ללמוד ולפעמים גם לצאת מאזור הנוחות.
אפשר לקרוא על לא מעט א.נשים מוכשרות שכאשר היו תקועים בבעיה או באין מוצא הלכו ועשו משהו אחר , למודו מקצוע משלים ובטוח יצאו מאור הנוחות זה מה שגרם להם לייצר את השינוי
לפעמים נראה שארכיטקטים הם האנשים הכי לא חברותיים וקשובים שיוצא לפחות , ואכן יש מצב שהרווחנו את זה בצדק. ואני יכול להעיד מניסיון אישי שככל שאני מקשיב יותר ומכיל את הצד השני זה עוזר לי להיות איש מקצוע יותר טוב. גם איש מוצר חייב שתהיה לו את היכולת הזו, להקשיב ללקוחות למנהלים לאנשים הטכנים ובעצם להכיל את כולם ולייצר את MVP וומפת הדרכים הנכונה.
אני תמיד אוהב לשוחח עם אלו שעושים את העבודה באמת ולשמוע מהם מה הם חושבים. מבטיח לכם אפשר ללמוד המון רק מהלקשיב
ברגע שאשת או אישת המוצר יחשבו שהם הכי חשובים בחדר/בתהליך זה סימן שהמוצר/פרויקט חברה נמצאים במצב לא טוב….
תמיד השתדלתי לגייס א.נשים שיותר טובים ממני ותמיד אני מוצא (100% מהמקרים) שאני לא האיש הכי חכם בחדר/תהליך. וכן זה מה שעושה איש מותצר וארכיטקט לטובים באמת היכולת להיות חלק מקבוצה היכולת להבין שיש חלקים יותר חכמים ויותר מוכשרים והכוח הוא בלאחד את כולם לרקמה אנושית אחת שתייצר את המוצר הטוב ביותר, זו שתממש את הארכיטקטורה המועילה ביותר.
אני ממש מחכה לשמוע מה את חושבת או מה אתה חושב
פוסט זה הולך להיות פוסט מאוד off topic אבל מצד שני אני חושב שרבים ימצאו בו קווים דומים למה שהם מכירים. אני רוצה לתת טיפה את התבלינים שלי לתבשיל שנקרא קריירה.
אני נמצא בעולם המקצועי כבר יותר מ 13 שנה עברתי מספר תחומים וגם מספר מקומות עבודה אבל העוגן שלי היה תמיד החברה שלי לחיים שהיום היא אשתי. ולמה אני בכלל כותב על זה ? מהסיבה הפשוטה אבל כל כך חשובה, לפעמים צריך להגיד תודה.
שוק העבודה בישראל ובמיוחד בתחום ההייטק הוא תחום טובעני ותובעני שדורש שעות אין ספור. אני מחלק את הזוגות בו ל 2 סוגים עיקרים, הסוג הראשון שבו שני בני הזוג הם הייטקיסטים והשני שבו רק בן זוג אחד נמצא בתחום.
מירב ועבדכם הנאמן נמנים על הסוג השני. אפשר להגיד שכל מה שקשור לחומרה או תוכנה ממש לא מושך את מירב אישתי, הייתי אומר אפילו גורם לה איזה תחושת גירוד עזה.
אני לא שוביניסט או פמיניסט אבל באופן כללי אני מעריץ אתכן הנשים שעובדות ומגדלות איתנו את הילדים. אבל את אישתי אני הכי הרבה מעריץ. היכולת לקום כל בוקר עוד לפני שהשמש זורחת להתארגן ולארגן להגיע לעבודה כאשר הילדים בבית בדיוק מתעוררים ולהיות שם כאשר הם מסיימים את המסגרות ב 16:00. ואז כמובן מגיע החלק הטוב שבו יש למלא את החלק הנותר עד הערב בשיעורים, חוגים , פעילות ושאר נושאים שאני אפילו לא מצליח לחשוב.
היכולת של מירב לדאוג להכל ולזכור את הכל גם ביום הכי לחוץ שלה היא מדהימה, אני חושב שזו תכונה אימהית שאנחנו "אנשי הקריירה" לא תמיד מבינים איך אתם "נשות הקריירה" מכילות אותה.
אני בטוח שאנחנו לא המשפחה היחידה שמנהלת כל אחר צהרים את המשא ומתן מתי אבא חוזר הביתה, וכן הצד השני צודק צריך לבוא ולעזור עם הילדים, אבל גם במציאות הישראלית שלנו צריך גם להיות לא מעט שעות בעבודה.
אני תמיד טוען שצריך לחזור לפחות פעם בשבוע מוקדם על מנת לבלות עם הילדים, לצערי ברוב השבועות אני לא באמת מצליח לקיים זאת, למען האמת הרבה מסביבי לא מצליחים וכן אני יודע שזה לא תרוץ.
במרתון של החיים צריך למצוא את בן הזוג המתאים, לא תמיד זה קל ולא תמיד מוצאים. אני מאוד מאושר שאני מצאתי. אני חייב להגיד שהרבה מחברי מצאו ומוצאים גם כן. אני לא סתם משווה בין הקריירה למרתון אם נחשוב על זה יש הרבה דברים שדומים, בקילומטר הראשון קשה לראות את האחרון ובאחרון בטוח שלא זוכרים את המאה מטרים הראשונים.
אבל אל תשכחו עם נועלים נעלים לא מתאימות ובלי גרביים הסיכוי לגמור חצי מרתון אפסי.
גם במרתון של החיים חשוב לראות את הדברים הקטנים ולהגיד להם תודה.
את הדברים הגדולים צריך לקחת מטר אחרי מטר.
לשמור על קצב ולאמץ טכניקה לאיך לרוץ ביחד.
והכי חשוב לא לקבל כמובן מאליו את הדברים הקטנים והגדולים, המכלול גדול מסך כל חלקיו.
בכל איש מקצוע יש גם בנאדם ותמיד חשוב לזכור זאת. כל אחד מאיתנו שרוצה להיות מקצוען בסופו של דבר או אפילו בבסיסו הוא אדם/אישה אשר מכיל מעבר ליכולות המקצועיות גם תחביבים.
אני רוצה לסכם בנימה הכי אישית בכל הפוסטים שכתבתי.
מירב תודה רבה על הדרך ושיתוף הפעולה וכמובן מזל טוב ליום ההולדת. לא סתם נולדת ב 10/10 את באמת בנאדם מדהים.
ונסיים בוידאו שמנסה לסכם את הכל :-9
פורסם לראשונה בבלוג הישן ב – נובמבר 2009
בעולם התוכנה יש מילה שמקבלת הרבה משמעויות וצבעים. זו מילה מפוצצת שקשורה ולא קשורה. המילה הזו בשבילי תמיד תתקשר ל סלוגן…… מ.י.ק.י ברקוביץ— ארכיטקט הניצחון.
אני מתכוון ל "ארכיטקטורה" או למושג ארכיטקט.ת תוכנה.
יצא לי להכיר הרבה א.נשים שקראו לעצמם או נקראו ארכיטקטים וגם כאלו שלא קראו לעצמן כך אבל היו בכל רמ"ח איברים, בקיצור יש הרבה אבל יש מעט. גם עבדכם הנאמן הוא ארכיטקט (פשוט) , מקווה שמוביל לניצחון………
כמובן שאם נקרא ב WIKI http://en.wikipedia.org/wiki/Software_architect נגלה שהמושג הזה מאוד מאוד צעיר בעולם התוכנה.
בפוסט זה אני מתכוון לנסות להגדיר טיפה:
נא לקרוא לפני השימוש – כל הנאמר בפוסט זה זו דעתי האישית בלבד
ראשית תפקידו הארכיטקט לבנות מערכת תוכנה העומדת בכל כללי הנדסת תוכנה, אמינות בהירות יעילות וגמישות לשינויים. בסופו של דבר עבודה נכונה של הארכיטקט תוביל לחיסכון, פיתוח מהיר ואושר ועושר לכלל השחקנים בפרויקט כולל הלקוח.
ישנם סוגים רבים, ארכיטקטים מרמת Application Architect (ברוב המקרים ר"צ המפתח) דרך Solution Architect ועד ל Enterprise Architect.
בעולם התוכנה במרבית המקרים ניתן לראות שמקור הארכיטקט.ת הוא ממפתח.ת.
אולם לא כל תוכניתן טוב הוא גם ארכיטקט טוב, ואני אדבר על זה בהמשך (ונא לזכור את החוק הפיטרי).
הארכיטקט בניגוד למפתח נכנס כבר בשלבים הראשונים של הפרויקט החל מתמחור דרך יזום וניתוח וכמובן שעד לעיצוב המערכת. הארכיטקט.ת גם נמצא הרבה אחרי המפתח.ת בשלבי ההטמעה, המסירה ללקוח ואנליזה מתקדמת של שימושית המערכת בייצור.
אף פעם לא תוכלו למצוא שני ארכיטקטים דומים או זהים, השונות היא לא מעטה ויחד אם זאת כולם.ן ארכיטקטיות וארכיטקטים.
קיים קו ישר ועבה בין טכנולוגיה וארכיטקטורה. אני מתקשה להאמין שללא ארכיטקטים יתקיים שימוש נכון בטכנולוגיית תוכנה. ובטוח ללא טכנולוגיה מתקדמת מתרעננת ומגוונת לא היה צורך בארכיטקטים.
שלא תבינו לא נכון, לא תמיד יש קשר ישיר בין להיות טכנולוג.ת מצוין לארכיטקט.ת המייצרת ערך. אבל ארכיטקט רציני חייב להיות מודע לטכנולוגיות שבדור הקודם, בדור הנוכחי וכמובן שבדור הבא.
יצא לי לראות ארכיטקטים שנותנים פתרונות של הדור הקודם למערכת שיש לה צפי חיים ארוך וגם יצא לי לראות ארכיטקטים שנותנים פתרונות של דור שקיים רק בתור בלון ניסוי למערכת בייצור. כמובן לעיתיים המתואר עשה את העבודה בצורה חלקית… אבל כמו שאומרים יותר מזל משכל.
קשה לי להתמודד עם ארכיטקטים שנדרשים לתת פתרונות O.O אבל חיים בעידן ה mainframe. אבל הרבה יותר קשה לי לראות ארכיטקטים המוכרים אשליות של פתרונות שבמצגות נראים מדהים אבל אין שום ביסוס אמיתי בקוד.
תמיד נשאלת השאלה כמה זמן צריך מפתח.ת להשקיע בפיתוח היוכולת המקצועית שלו.ה, כמובן שיש לי דעה ברורה בנושא (לא תקבלו אותה בפוסט זה). וכמובן שניתן לשאול כמה זמן ארכיקט צריך להשקיע בטכנולוגיה. ושאלה יותר קשה, כמה צריך הארכיטקט "ללכלך את הידיים בקוד"? האם לתת פתרונות ברמת DAL צריך להתלכלך ב- ORM האם כדי לתת פתרונות Smart Client צריך להתלכלך ב front end או טכנולוגיות ענן?
כמובן שיש לי תשובה ברורה, הרי זה נושא הפוסט .
ארכיטקט צריך להשקיע הרבה בטכנולוגיה ולא רק באזורים שהוא נדרש לתת להם פתרון בפרויקטים שהוא נמצא בהם ביום יום.
אני משקיע בערך שעתיים ביום מעבר לזמן העבודה בטכנולוגיות.
וכן ארכיטקט חייב ללכלך את הידיים. היא או הוא לא חייבים להיות מומחה הטכנולוגיות מקצה לקצה. אבל חייב להכיר על בוריו מה זה אומר פיתוח תוכנה מה זה clean code וכמובן את השיטות התקשורת בין רכיבים או אפילו סוגים שונים של Data Stores וללא ספק אפילו מה זה GitFlow. כן הארכיטקט.ית נדרש להכיר עולם מושגים רכב ולא רק ברמת המצגות. חייבת להיות לארכיטקט הבנה מה הולך להתרחש לאור כל המלצה. כמה קשה יעבדו האחרים, כמה הפתרון באמת יעבוד, כמה הפתרון לא יפיל ביצועים ועוד הרבה אספקטים שהוא חייב להיות מודע לכולם.
נושא שיש לי דעה ברורה ברורה ומוצקה. כל איש מקצוע צריך להיות בן אדם. אולם ארכיטקט.ית חייב.ית להיות בן או בת אדם.
ראיתי בימי חיי מספיק ״מה שנקרא ארכיטקטים״ וברור שהם היו מאוד מוכשרים מאוד חריפים ושיודעים לדבר יפה. אבל לא הייתי נותן להם פרס נובל בחביבות ויחס אדיב ואנושי לאנשים שהם עובדים /עבדו איתם.
אני יוכל לדבר על המה זה להיות בן אדם וגם מקצועי הרבה אולם חברי ואני אספנו את עשרת הדברות לאריכטקט.ית שמשמשים אותנו :
לפני שאני עונה על השאלה כיצד הופכים להיות ארכיטקט.ית חשוב לציין שהכוונה בשאלה זו לא על תואר שני במדעי המחשב.
המקבילה בעולמות תוכן דומים לעולם התוכנה ומוצא את זה די בקלות. זה הנדסת מערכת – מעולם החומרה. במקור אני מגיע מעולם החומרה. בתפקיד הראשון שביצעתי בעצם הייתי 80 אחוז מהנדס חומרה ו 20 אחוז מהנדס תוכנה. באותו תפקיד רק בחלקו האחרון עשיתי בדיוק ההפך 20 אחוז מהנדס חומרה ו 80 אחוז מהנדס תוכנה. אבל תמיד היה מישהו שהוא היה מהנדס המערכת, מאוד דומה לארכיטקט. וגם באנלוגיה זו היו סוגים ורמות שונות של מהנדס מערכת.
בעולם החומרה בשנים האחרונות התפקיד הזה הפך גם למקצוע נלמד באונברסיטאות עם רשימת המתנה לא קצרה ותוכנית לימודים מעוד מעניינת.
אני מאמין שגם בעולם התוכנה צריך להיות תואר שני בנושא שלא יתמקד רק במדעי המחשב אלה ישלב את מדעי המחשב מנהל עסקים וקורסים יעודים לארכיטקטים. אני בטוח ארשם לכזה מסלול.
לדעתי צעד כזה אם יקרה יכול להקפיץ את עולם התוכנה מספר צעדים קדימה, ואין מתאימה מזה היא ישראל.
כמובן שאיך לחשוב מחוץ לקופסא אבל בצורה מערכתית יהיה קשה עד בלתי אפשרי ללמד.
לא פחות חשוב זה כמובן תזמון, לפעמים להיות במקום הנכון ובזמן הנכון שווה את כל הכישרון בעולם.
נקודה לא פחות חשובה זה הכישרון, למי שקרא את הפיסקה הקודמת הבין שאני בעד תואר שני בארכיטקטורת אולם יחד עם זאת למי שיש כישרון, כישרון ועוד טיפה כישרון לא צריך אפילו תואר ראשון במדעי המחשב.
אולם בבסיס של כל הנושא יש נקודה חשובה ולדעתי גם הכרחית והיא להיות מפתח.ת.
כמובן שלא כל מפתח מקצוען יכול להיות ארכיטקט.ת טוב ולפעמים אפילו זה לא מסתדר הרי להיות מפתח זה מקסימום לעבוד בצוות. אין יותר מידי מה להסביר לאחרים או לנסות לשכנע מנהלים ואפילו לקבל החלטות רוחביות.
ולכן חברים יקרים תזהרו מהחוק הפיטרי שבו כל אדם מקודם כל עוד הוא טוב ומפסיק להיות מקודם מתי שהוא מפסיק להיות טוב. זאת אומרת שבלי בעיה נוכל למצוא ארכיטקטים לא בשיא כושרם…. ותחשבו על זה
חוץ מכל הנקודות שאמרתי ישנם עוד מספר יכולת ששווה לפתח. יכולת הדרכה, לימוד עצמי, טכנולוגיות שונות ואפילו משונות. ועוד נקודה יכולת שלי באופן אישי חסרה ואני מנסה לעבוד עליה כל הזמן, יכולת כתיבה וקריאה באנגלית.
אסיים בנימה אישית.
בתחילת דרכי בתור ארכיטקט במשרה מלא מאוד חששתי מהמעבר ממפתח במשרה מלאה.
היום לאחר מסע מרתק כאשר אני מביט לאחור ורואה את הדרך המעניינת שעברתי דרך שבה עשרת הדברות של הארכיטקט מהווים לי בסיס. אני מנסה כל הזמן להישאר מעודכן. אבל הכי חשוב משתדל להיות להיות בן אדם (צנוע וגאה) .
אני תמיד מתחיל יום או שיחה בידיעה שאני יכול ללמוד מהצד השני כמו שאני יכול ללמד. וכמובן שאני לא האדם הכי חכם בחדר.
והדעה האישית שלי, אם שואלים מה אתם.ן רוצים.ות להיות ראשי צוותים או ארכיטקטים תענו ללא היסוס, ארכיטקטים.ות. כמובן שתמיד תוכלו אחר כך להיות מנהלים.ות (זוכרים.ות את החוק הפיטרי ).
שלום לכולן.ם, שמי ליאור ישראל בן הזוג של מירב ואבא מאושר של רותם ואורי.
בנוסף אני גם ארכיטקט תוכנה פשוט עם הרבה עיסוקים בעולם היזמות , תוכנה ובעצם בתחומים נוספים אשר יכולים לעזור לא.נשים.
© כל הזכויות שמורות לליאור ישראל
נבנה על ידי Techjump , העסק החברתי לבניית אתרים