הפוסט נכתב על ידי אדיר אמסלם, מפתח אינטרנט.
בתור מתכנתים, אנחנו נציגי הטכנולוגיה בצוות, אנחנו ממלאים תפקיד חשוב בהפיכת החזון למציאות ואני רוצה להאמין שכולנו רוצים ללמוד ולהשתפר כמה שיותר על מנת להיות מתכנתים טובים יותר. אנחנו לומדים שפות, טכנולוגיות וספריות חדשות, מתנסים עם מגוון כלים ומקפידים על כל שורת קוד שאנחנו כותבים. אבל האם אנחנו באמת צריכים לעשות את כל זה, מה זה בכלל אומר להיות מתכנת טוב יותר, מי מתכנת טוב יותר, טוב יותר למי, טוב יותר למה?
מיהו המתכנת האידיאלי?
בעבר חשבתי שהמטרה היחידה שלי ושל שאר המתכנתים בצוות היא לפתח את התוכנה הטובה ביותר – כזו שתהיה קלה לקריאה ולתחזוקה, שיהיה קל לשנות ולהרחיב אותה, שתהיה מהירה, יציבה, תוכל לגדול וכד', ובמשך שנים הקפדתי על כל העקרונות האלו במטרה לכתוב תוכנה איכותית. אנחנו מתכנתים, תפקידנו לכתוב קוד ואנחנו נכתוב את הקוד הטוב ביותר שאנחנו יכולים, בשביל זה משלמים לנו. אם היו רוצים קוד פחות איכותי משלנו היו שוכרים מישהו אחר, אך שכרו אותנו כי הם מבינים את החשיבות של קוד איכותי ושל תוכנה מצויינת.
עם זאת, בשלב כלשהו בקריירה שלי התחלתי קצת לערער באידיאולוגיה הזו, עדיין כתבתי קוד איכותי (אני מקווה לפחות) אבל לפעמים קצת פחות מבעבר, כשנתקלתי בצמתים במהלך הדרך לפעמים פשוט בחרתי כיוון והתקדמתי איתו גם בלי לכנס ישיבה עם שאר הצוות ולבחון את כל האפשרויות האחרות, לפעמים כתבתי קוד בצורה שטובה להיום ולמחר אבל לא לעוד שנתיים, לקחתי סיכונים וקיבלתי החלטות שאת חלקן יגידו שנצטרך לשנות בעתיד – הם צודקים, אך עשיתי את זה במודע.
לקח לי זמן להשלים עם הגישה הזו, היא הייתה קצת מנוגדת למה שהכרתי ולצורה שבה עבדו חלק מחבריי למקצוע, אך בשלב כלשהו נפל לי האסימון, זה היה כשהורדתי את הכובע של המתכנת וגיליתי את העולם הגדול.
בשנים האחרונות נושא הסטארטאפים זה כנראה הנושא הכי חם בקרב כל מי שקשור לעולם הזה, שמענו על חברות מצליחות, אקזיטים, מיזוגים, הנפקות והחיים הטובים של כל אלו שקמו בבוקר והחליטו להפוך את הרעיון שלהם למציאות. מתולוגיות כמו Agile הפכו רלוונטיות יותר מתמיד ואפילו קמו מתודולוגיות כמו Lean Startup שמטרתן העיקרית הייתה לעזור לנו להקים סטארטאפ מצליח במהירות וביעילות. כשהורדתי את הכובע של המתכנת והכרתי את העולמות של יזמים, אנשי מוצר, אנשי UX, אנשי שיווק ומכירות, פיתוח עסקי ושאר הכוחות שתמיד עבדו איתי ביחד אבל ישבו בחדרים אחרים, רק אז הבנתי וידעתי להגדיר בצורה ברורה מדוע לדעתי הגישה הזו של קוד מושלם לא תמיד נכונה, זה היה פשוט – המטרה היא לא תוכנה איכותית, המטרה היא מוצר איכותי.
רוב המוצרים מתחילים עם חזון מסויים, עם בעיה שאנחנו רוצים לפתור. אנחנו שוכרים את בעלי המקצוע הרלוונטים עבורנו ומתחילים לעבוד, כל אחד מאנשי המקצוע צריך לעשות את העבודה הטובה ביותר שהוא יכול לעשות. אנחנו בתור מתכנתים צריכים לכתוב את התוכנה הטובה ביותר שאנחנו יכולים, אך האם זה נכון והאם זה העיקר? לא תמיד.
כמתכנתים, אנחנו צריכים לזכור שהמטרה היא לא בהכרח תוכנה איכותית, אלא מוצר איכותי – תוכנה איכותית יכולה לעזור לנו להגיב לשינויים בקלות, לעמוד בעומסים, להיות מהירים, אבל חשוב לזכור תמיד שהיא אמצעי ולא מטרה, חשוב שנזכור ונתמקד בבעיה האמיתית שאנחנו צריכים לפתור ולא רק בבעיות טכנולוגיות. בסופו של דבר, למשתמשים וללקוחות שלנו לא אכפת כמה הקוד שלנו ברור והם לא רואים את כל ההערות שרשמנו בו, הם רוצים שהמוצר יפתור את הבעיה שלהם ויעלים את הכאב שלהם, זה הכל. יש אפילו שיגידו שהם יעלימו עין אם חווית המשתמש תהיה לפעמים פחות ממושלמת ושהם גם מסוגלים לסלוח על כפתור שלא ממוקם בדיוק כמו בעיצוב – העיקר שתפתרו להם את הבעיה ותעלימו להם את הכאב.
על מנת לעשות זאת – אתם צריכים להכיר את התחום שבו אתם פועלים, להבין את היעדים העסקיים של המוצר, לדעת מה הבעיה שאתם מנסים לפתור ומה הפתרון שאתם מציעים, זה לא פחות חשוב מהידע הטכנולוגי שלכם ומהכלים שתשתמשו בהם על מנת לפתח את התוכנה.
נקודה חשובה נוספת שחשוב להכיר היא שהרבה מוצרים משתנים במהלך הדרך, לפעמים כי מראש לא ידענו לאן אנחנו הולכים ולפעמים כי פשוט טעינו. תפקידנו כמתכנתים זה לשמור על האיזון הנכון בין תוכנה איכותית לבין תוכנה רלוונטית, לפעמים אנחנו רוצים זמן נוסף על מנת לשפר את הקוד שבדיוק כתבנו אבל לוחצים עלינו להעלות גרסה, לנו אין שום ספק שאם נשפר את הקוד הוא יהיה טוב יותר – אבל מה אם נשפר את הקוד ובסופו של דבר נזרוק את כל הפיצ'ר הזה לפח כי אף אחד לא רוצה אותו, לא חבל על הזמן? אלו שיקולים וסיכונים שאנחנו צריכים לדעת לנהל.
חוב טכני
מושג חשוב שכדאי לנו להכיר בהקשר הזה הוא חוב טכני – זה בעצם אומר שאנחנו עושים היום משהו בצורה לא אידיאלית, ואנחנו יודעים מראש שבעתיד כנראה נצטרך לעבוד יותר על מנת לסדר אותו, למעשה לשלם את החוב הזה בתוספת הריבית שנצבור עד אז. החוב זה העבודה שלא עשינו והריבית נוצרת כתוצאה מהמשך הפיתוח וההסתמכות על הצורה הקיימת שבה הקוד עובד, מתוך הנחה שבעתיד נצטרך לבצע שינויים במקומות נוספים שלא קיימים עכשיו וזה ידרוש מאיתנו זמן נוסף.
אך בעולם הסטארטאפים החוקים עשויים להשתנות, כשהדרישות לא תמיד ברורות והמוצר לא תמיד סגור, לעיתים כפי שהצגנו לפני כן אנחנו עשויים לזרוק עבודה שעשינו לפח, ואם לקחנו חובות בעבודה הזו, את חלקם אנחנו לא נצטרך לשלם – ככה שגם הוצאנו גרסה מוקדם, גם קיבלנו פידבק מהמשתמשים ולמדנו מה נכון ומה לא נכון וגם אנחנו לא צריכים לשלם את החוב שלקחנו, הוא נעלם.
חוכמת ההמונים
לפני כחודש וחצי החלטתי לפרסם שאלון קצר שבו שאלתי מיהו המתכנת האידיאלי, את הסקר הפצתי בעיקר בקרב מפתחי אינטרנט וחבריהם המעצבים, המאפיינים ואנשי המוצר. המטרה הייתה לבדוק מה הם חושבים, איך הם רואים את המתכנת האידיאלי, האם באמת כל כך הרבה מתכנתים ואנשי מקצוע בתחום הזה קשורים חזק מדי לכובע שלהם ולא מקדישים מספיק חשיבות למטרה האמיתית, למוצר שבסופו של דבר המאמצים המשותפים שלהם אמורים ליצור.
שאלון – המתכנת האידיאלי
קיבלתי בסביבות 60 תגובות, בהתחלה חשבתי שאפרט ואנתח אותן אך הפוסט התארך אז אולי בפעם הבאה. מה שכן היה נחמד לגלות זה איך אנשים שעוסקים בתחומים זהים רואים את המתכנת האידיאלי בצורה דומה, רוב המתכנתים ענו תשובות די דומות, המעצבים ענו תשובות די דומות וגם המאפיינים ענו תשובות די דומות, כל אחד בהתאם לנקודת המבט שלו ולנושאים שבהם הוא בא במגע עם מתכנתים, והמתכנתים בינם לבין עצמם. אתם מוזמנים לעיין בסיכום התגובות או בפירוט המלא.
לסיכום
לדעתי, המתכנת האידיאלי הוא אחד שבנוסף לכל כישוריו המקצועיים בתחום הוא יודע גם לראות את התמונה המלאה, הוא אחד שמבין שהתוכנה היא חלק מהפאזל ולא כולו, יודע לנהל סיכונים ולקבל החלטות, הוא אחד שמבין יעדים עסקיים, מבין את הבעיה שהמוצר שלו פותר, בקיא בפתרון שהוא מציע ויודע שעל כל שורת קוד שהוא משפר מעבר לנדרש הוא מוותר על פיצ'ר נוסף ופידבק מהמשתמשים. הוא מתכנת שמבין שהמטרה האמיתית היא מוצר טוב ולא קוד באיכות גבוהה.
מס' מקורות רלוונטים נוספים שנתקלתי בהם במהלך הדרך:
Domain Knowledge – מוניות (ליאור בר-און)
What good developers need to know besides developing good software (סרג' קרול)
אשמח לשמוע את דעתכם.
הפוסט פורסם לראשונה בבלוג אני, אדיר.
קרדיט תמונה: man in light via shutterstock.