כמה מילים עלי

שלום לכולן\ם, שמי ליאור ישראל בן הזוג של מירב ואבא מאושר של רותם ואורי.

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

מה חדש? הסטורי שלי

איזה כייייף, סיימתי לעלות את הפוסטים (שעומדים במבחן הזמן כמו שהם פחות או יותר).

מה יהיה בעתיד? את זה אני אתן לכן.ם לגלות בזמן הקרוב :-9
בכל נקרה מוזמנות ומוזמנים לעקוב אחרי בTwitter שם כל פוסט חדש יקבל Twittet

פוסטים אחרונים

בואו נשמור על קשר

מבטיח שלא להטריד

9 סיבות למה ארכיטקט.ת טוב.ה היא/הוא איש.ת מוצר טוב.ה

זמן קריאה: 6 דקות

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

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

 

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

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

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

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

 

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

 

לאורך השנים ובצורה מאוד מפוקסת בזמן האחרון אני מוצא יש הרבה קווי דמיון וראייות שיש מספר נושאים שאם הארכיטקט.ית עושה אותם טוב ב אז לחלוטין זה סוג של ניהול מוצר.
הרבה פעמים מוצאים שארכיטקטים טובים הופכים להיות מנהלי פיתוח (טובים?) אבל יש לא מספר מקרים במיוחד בחברות מוצר שבהם הארכיטקט.ית עוסקת גם בתחום ניהול המוצר עד ל founder & head of product.

 

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

1- הכרות טובה עם הצרכים העסקיים

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

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

  • 17 מהנדסים שיצרו את המושג Agile בשנת 2001 

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

  • דורית דור המדהימה מצ'ק פוינט וכן גם גיל שוויד

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

 

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

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

 

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

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

 

3- כישורים טובים בלתקשר חזון לאנשים שלא נמצאים באותו מקום מבחינת הראייה העסקית/טכנולוגית

נשות ואנשי מותר טובים חייבות לדעת לספר את הסיפור ולהעביר את המסר, לעיתים המסר לנמענים השונים (הנהלה , משתמשים/לקוחות , צוותי הפיתוח) צריך להיות ארוז בצורה שונה. תמיד המסר צריך להביא את כל הגורמים השותפים להסתכל על אותו צורך/אתגר ולהבין מה צריך לעשות ויותר חשוב מה יהיה בערך העסקי ואיך נדע שהוא באמת ערך ולא ״נפנופי ידיים״.
גם כאן מתקיימת הלימה חזקה, כל ארכיטקטית וארכיטקט שאני עובר איתה או איתו את המסע של להיות איש.ת מקצוע יותר טוב.ה, אני מלמד את עקרון המפתח לקבלת משוב מהיר ואיכותי – אם צוות הפיתוח לא הצליח לממש את הארכיטקטורה שתוכננה האחריות ברוב המקרים היא על בונה הארכיטקטורה. זו הסיבה שאני כל כך אוהב לעבוד בתפיסת Agile בצורה כזו אני מקבל משוב מאוד מהיר האם הארכיטקטורה שתכננתי (יחד עם כולם) באמת עובדת ואני לא צריך לחכות חודשים ואפילו שנים על מנת לדעת זאת.
הארכיטקט.ת צריך גם לדעת לספר את הסיפור למנהלים ומקבלי ההחלטות ואפילו לצד הטכני והעסקי של הלקוח.
אני זוכר בתחילת דרכי בתור ארכיטקט צעיר איך היה קשה לי להעביר מסרים טכנולוגים , אני מקווה שעם השנים השתפרתי :-9

 

4- הניסיון ההנדסי והתהליכי למציאת המדדים הנכונים (KPIs) על מנת להבנה האם הצורך העסקי והטכנולוגי באמת באים לידי ביטוי מבחינת תוצאות בשטח.

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

 

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

לארכיטקט צעיר וגם לאיש מוצר צעיר יש הרבה אפשרות לכל דבר, ארכיטקטת מנוסה ואיש מוצר מנוסה יודע לגדר את האפשרויות ל 2-3 ולא יותר ובעצם על בסיס האינטואיציה להבין איזו אפשרות היא המועדפת תוך הבנה של כל מרחב הבעיה. אני במקצוע כבר מעל ל 20 שנה וארכיטקט במשרה מלאה כבר 15 שנה ואני עדין נמצא במסע שלי, אני אומנם לא ״ירוק״ אבל יש לי עוד דבר או 2 ללמוד. בצניעות במאת בצניעות, מניסיון אני לחלוטין יודע היום לספק את בתור ארכיטקט את הפתרון המתאים (ואלי עוד אחד אלטרנטיבי) בתור איש מוצר אני עדין ברמה של 2-3 לכן בנתיב של איש מוצר יש לי עוד מסע לעבור.

 

6- היכולת להגדיר בעצם מה הדרישות המינימליות על מנת שזה יהיה MVP ויותר חשוב מזה היכולת להגדיר בצורה טובה מה זה product market fit- PMF 

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

 

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

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

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

 

  1. הלהט לצאת מאזור הנוחות וללמוד תחומים חדשים מעולמות אחרים ולהכיל אותם על העולם של המוצר 

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

  1. היכולת להקשיב , להקשיב להקשיב ולהכיל והכי חשוב – לזכור תמיד שאת.ה לא הארכיטקט.ית הכי חכמ.ה בחדר

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

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

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

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



אני ממש מחכה לשמוע מה את חושבת או מה אתה חושב




שתפו את הכתבה

4 תגובות

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

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

  3. דעה לא פופולרית:
    זה הכל טייטלים לתרבות הלינקדין ולוחות המשרות. בסוף הן:
    1. מנהל מוצר
    2. מנהל פרויקט
    3. פיתוח עסקי
    4. מהנדס מערכת
    5. ארכיטקט
    זה ממש בגדול? אותו דבר.
    מהניסיון שלי פשוט בכל ארגון אותה עבודה נעשית על ידי טייטל אחר מהנ"ל.
    לדוגמא בתעשיות כמו אלביט ורפאל שם טייטל הנדסת המערכת יותר פופולרי.
    ארגונים שהם מאוד פיתוח תוכנה/חומרה "קלאסית" אז ארכיטקט.
    עולמות הווב שם פונים לקהל יוזרים ויש מטריקות שיווקיות דוקא אוהבים יותר את ההגדרה למנהל מוצר.
    ההבדל הוא לא הטייטל אלא התוכן ולאן כל חברה לוקחת את זה ובעיקר על המנעד של עד כמה זה טכני.
    הבלבול הכי גדול הוא ארגונים שם זה מאוד טכני ומשתמשים בטייטל מנהל מוצר: כי האנשים שם זה בכירים ש"צ'ופרו" בקידום פנים ארגוני לעמדה מתוך פיתוח התוכנה, וזה "החלום" של כל מפתח כי גם הגיוון בתפקיד עולה וגם התגמול. ואז כמובן מבלבלים זאת עם מקומות שם אותו טייטל של מנהל מוצר זה משהו יותר של מנהל עסקים שמתאים גם ללא בעלי רקע בתכנות (והתגמול בהתאם!) ומשווקים זאת כזהה למקרה הקודם.

כתיבת תגובה

האימייל לא יוצג באתר.

דילוג לתוכן