היי אריאל

גם בתגובתך שזורות המילים מוצר מספר פעמים.

ואני אכן מבדיל בין מוצר שאתה מייצר ורוצה למכור

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

דרך אגב מה הניסיון שלך בפתוח מוצרים לצרכים פנים ארגוניים ?

שיקולי הפתוח והעלות של המוצר שאתה מייצר ורוצה למכור הם שיקולים של בכמה תצליח למכור את המוצר. חלק מרכזי בכך  הוא השיקול  השווקי. וכבר ראינו חברות שמשקיעות כסף / משאבים רבים ויוצרים מוצר מצויין אלא שאין מי שיקנה או שהוא לא מוכוון שוק, או שהשוק לאט בשל וכו. לכן צריך להשקיע מחשבה רבה בעלות המוצר. לא חשוב איך קוראים לשיטה אם העלות והחזר היא נר לרגלי ההשקעה הרי כל שיטה טובה. ממרום זיקנתי וניסיוני, סיסמאות כאלה ואחרות הן ביטויים לתהליכים שאנשים עם נסיון ואם common sense כבר אימצו מזמן. למשל TQM, ו- object Oriented , ו- SOA . כולם שמות לתהליכים שאמורים בסוף התהליך ליעל את העבודה, ולהוזילה.

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

בברכה, ישראל

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

 

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

 

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

 Responding to change over following a plan

מתי אפשר לדעתי להמשיך לעבוד בשיטת מפל המים הישנה?

1) כאשר הפרויקט קטן, מוגדר היטב, וסטטי מבחינת שינויי דרישות

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

3) על פרויקט של מספר קטן של שבועות לא הייתי מיישם agile בצורה מלאה. פרויקט של מספר חודשים הוא המינימום

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

שיטות agile לא באה מממקום של בוא נתחיל לעבוד בלי תכנון ונראה מה יוצא... ממש לא. יש מקום לתכנון מוקדם ראשוני והערכות זמנים (מה שקורה הרבה פעמים באיטרציה הראשונה) רק שהשיטה בצדק טוענת שבאיטרציה ה-N הידע על הבעיות והשינויים קטן משמעותית בדר"כ מבאיטרציה ה-N+1 ולכן השיטה מציעה דרך אפקטיבית לניהול סיכונים ושינויים

אשמח לדון עוד offline אם אתה מעוניין ולהבין את הבעיות הספצפיות בעולם שלך.

יש צורך להבחין בין סוגי פתוח תוכנה .

יש תוכנה שהיא מוצר, ואולי שם הדברים שנאמרו נכונים.

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

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

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

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

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

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

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

נשמע מוכר? קוראים לזה Agile וזו מתודולוגיה שקיימת כבר שנים.

שורה תחתונה - יש להתאים את המתודולוגיה למצאיות גם אם זה מנוגד לצתורך הבסיסי שלנו לוודאות.

ידידי אריאל כץ

 

הדבר הבא ,זהו בדיוק רב , הדבר הבא !

 

וגם זהו רמז עבה במיוחד .

 

עכ"פ אשמח אני ובוודאי יתר החברים כאן לשמוע את דעתך מהו הכיוון של הדבר הבא

 

מבחינתך !

 

בעולם התוכנה ההפתעות הן שאין הפתעות , ומאחר ותמיד ישנן , גם הכיוון שלך

 

מפתיע ועל כך הסקרנות .

 

אהבתי

 

בהצלחה

פוסט מרתק

אהבתי מאד את השפה והאופן שבו הדברים כתובים. 

מתקשר לי להרבה דברים שעדיין לא מתנסחים  לי בצורה מדוייקת

אולי עוד שנתיים...: 

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

כם כבר בעניין מעמד המקצוע

מה שאולי קצת שונה כאן זה שהמהנדסים

הם גם אלה שמנחים את הלבנים

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

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

אכן יש שיפורים ניכרים בזמן פיתוח התוכנה וביצירת תוכנה ממרכיבים ( Composite Application, SOA .........בזזזז  פכחחחחח), אך תמיד התמונה יותר מורכבת ומסובכת ופחות אנשים יודעים לפתח בצורה נכונה( NET. , JAVA, AJAX , WPF, WCF , SOA ,  בזזזזזזז , פחחחכככ ) ומבינים את המשמעות ולא רק לעשות גזור, הדבק.

המהפכה תמיד שנתיים לפנינו . נפגש עוד שנתיים

 

 

אולי יש לו רעיון?

לפחות שירמוז על כיוון.

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

 

גם הדוגמאות שלו לא רלוונטיות.

מהנדסי חמרה מרוויחים שכר גבוה לפחות כמו מהנדסי תוכנה.

גם מהנדסי בנין (פרט למתחילים שמקבלים חלקי עבודות פשוטות)

משתכרים שכר גבוה.

 

אבל נחכה ונראה.

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

מהפכה בהנדסת תוכנה

לא לא שמעתי שהמציאו משהוא חדש

לא שמעתי אפילו שגילו אותה מחדש

זה שהענף לאורך השנים עובר תהליך של התבגרות

כן בהחלט

לא יותר מיזה ובטח ובטח לא מהפכה

 

 

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

 

 

גם קצת קשה לגזור את כול עולם התוכנה יש חברות שבאמת דומה

לבניה של בניין ( כלומר עוד מאותו הדבר )

אבל יש בהחלט חברות תוכנה שיש להם מחלקות R and D אמיתיות

זה לא ממש דומה להנדסה אחרת

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

ישראל פטשניק

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

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

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

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

לדעתי המקצוע הוא מאוד ייחודי. רק במקצוע זה אדם הוא כל-יכול.

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

 

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