הפיתוח – בניית צוות
מאת ימי גליק | 5 תגובותבפוסט הקודם "הפיתוח אינו הבעיה – או שמא" הנחתי את אבן היסוד לנושא הפיתוח – הבנת הבעיה. הפיתוח אינו קורה מעצמו ואינו מגיע ליעדו ללא עבודה קשה. השעה כעת היא עשר בלילה ורק לפני 10 דקות חיברתי בשיחת ועידה מפתח ומעצב כדי שיסתנכרנו ביניהם על המשימות לדד-ליין של יום ראשון. אם מישהו תהה מדוע צריך צד ג' להעלות לשיחה שני אנשים בוגרים כדי שידברו ביניהם סימן כנראה שמעולם לא ניהל פרויקט, שכן הנטייה הטבעית של הדברים היא לאנטרופיה – חתירה בלתי נלאית לאי סדר. הנח לדברים להתנהל מעצמם והם לעולם לא יקרו – ולא חשוב איזה ספרות מנהלים ניו-אייג'ית טוענת אחרת.
בפוסט הנוכחי אנסה לעשות סדר בנושא הקמת צוות פיתוח. משימה לא פשוטה מאחר ויש לא מעט דרכים לבנות צוות שכזה ולא מעט אילוצים בהם צריך להתחשב, כשהאתגר הוא בהצגת תכנית ריאלית אותה ניתן ליישם גם ללא מליוני דולרים בקופה. כדי לעמוד באתגר יש להתייחס תחילה לפונקציות הדרושות לפיתוח מיזם דוט קום (ניהול, אפיון, עיצוב, פיתוח וכו') ולהתעלם לרגע מנושא איושן. כמובן שהכרחי בתחילת הדרך – ואפשרי גם בהמשכה – להטיל מספר פונקציות פיתוח על כל אדם, לפי כישוריו, אך טעות קלסית של מיזמים היא לגשת למלאכת הפיתוח מתוך אפשרויות האיוש המידיות ("יש לנו מנכ"ל, מפתח ואיש שיווק – אפשר להתחיל") תוך התעלמות מכלל הצרכים. אם מחליטים לוותר על אחת הפונקציות הדרושות יש לעשות זאת באופן מודע ומושכל. הפונקציות המוזכרות מופיעות לפי הסדר בו יש לעשות בהן שימוש, לפחות לפי העדפתי.
ניהול פיתוח
הפונקציה הראשונה בחשיבותה היא ניהול הפיתוח. המקום אליו מתנקז כל המידע הקיים בנושא הפיתוח וממנו מגיעות ההחלטות האופרטיביות לגבי התנהלותו. אל תתנו לעובדת היותו של המיזם סוג של "יחידת קצינים" להטעות אתכם – אנשי המקצוע יכולים לקבל החלטות נכונות לחלוטין, כל אחד בתחומו, ולהוביל את הפרויקט לקריסה. ללא ניהול פיתוח אין גורם הרואה לנגד עיניו את טובת כלל הפרויקט ומסוגל להובילו בדרך הישר. בנוסף, לא יתכן שהפרוייקט יורכב מאוסף של "קופסאות שחורות" שאף אחד לא יודע את תכנן ואת השיקולים שהביאו לבנייתן.
ניהול טכנולוגי
כל פרויקט טכנולוגי זקוק לפונקציה המהווה אוטוריטה הטכנולוגית בפני הצוות ובפני העולם החיצון. גורם המעורה מספיק בתחום בו עוסק המיזם כך שיוכל להגדיר ולעזור ליישם את התשתית הטכנולוגית והמקצועית הדרושות להקמתו. כמו כן, הכרחית פונקציה זו ליצירת אופק טכנולוגי ופיתוחי אליו ישאף המיזם בהמשך הדרך.
ניהול פרוייקט
בפרוייקט פיתוח יש ריבוא משימות של תיאומים, אזכורים, ניהול ספקים וטיפול בכל האספקטים שאינם מקצועיים גרידא. לעושים במלאכה אף פעם אין זמן "לרדוף אחרי אחרים" או "להתעסק במנהלות" אך מה לעשות שיש הרבה ריצות והרבה מנהלות. קל להמעיט בחשיבות העניין אך פרויקטים קמים ונופלים על תיאום פגישות נחוצות ותשלום בזמן לספקים.
אפיון מוצר
מה אנחנו הולכים בעצם לבנות? מה יעשה בפועל השירות וכיצד יתנהל מול המשתמשים? מענה מסודר ומקצועי על השאלות הללו יכול להשליך רבות על השירות אותו אתם רוצים לספק ומדהימה כמות המיזמים שמעולם לא תהו ברצינות מה בעצם יעשו המשתמשים עם הטכנולוגיה או השירות שפיתחו. תפקידה של הפונקציה המוצרית הוא להניח עין אחת על המשתמשים ועין אחת על השירות ולדאוג שהמיזם יחזיק את שניהם בשדה הראיה שלו בכל זמן נתון, מבלי לפזול קשות.
אפיון מוצר דורש לכל הפחות תכנון מסודר של המסכים במערכת ברמת ה- Wireframe. הירידה לפרטים אולי נראית מיותרת לעין הטכנולוגית אך ההגיון המוצרי משליך על הדרישות הטכנולוגיות והכספיות – שני דברים שעדיף לדעת לפני שמתחילים לעבוד.
אפיון טכנולוגי
לאחר שברור מה רוצים לעשות כדאי לשבת ולתכנן כיצד יש לעשות זאת. לא ברמת כלי העבודה אלה ברמת הנתונים, הפונקציות והתהליכים הדרושים לבניית השירות. האפיון הוא סוג של פרטיטורה באמצעותה ניתן להדריך את צוות הפיתוח מה לעשות וכיצד לעשות זאת. בשילוב עם האפיון המוצרי, יש לכם מדריך אותו ניתן להעביר לכל צוות מפתחים פנימי או חיצוני בידיעה שברור לכם ולהם מה אמור להתבצע.
ניהול בסיס נתונים
בניה וניהול נכונים של בסיס נתונים הם עניין של התמחות ואם אתם לא רוצים לכתוב מחדש חלקים גדולים מהמערכת, פעם אחר פעם, או להתקע עם מערכת לא יעילה, כדאי לעשות זאת נכון בפעם הראשונה. קיימת אסכולה של עבודה ראשונית מול בסיס נתונים ארעי, ללא תכנון רב, תוך ניסיון לאפשר גמישות יתרה בפיתוח בשלבים הראשונים והתייצבות עם גיבוש מבנה הנתונים הסופי – אך זוהי פריווילגיה של מקצוענים אמיתיים ולא פתרון דחק של מי שלא יודע איך עושים זאת כהלכה.
פיתוח "צד שרת"
כל החלק הפיתוחי המתייחס לממשקי התוכנה מול בסיס הנתונים ועם מערכות אחרות וכן לבניית רכיבים שאינם קשורים לממשק המשתמש מאוגד תחת השם הכללי מאד של "צד שרת". דרושים אופי ויכולות מקצועיות מיוחדים לעבודת פיתוח שתוצאותיה קובץ XML או רכיב בו ישתמשו מפתחים אחרים (להבדיל ממשהו שאדם מהישוב יוכל לראות ולהעריך).
עיצוב
ישנן שתי אפשרויות עיצוב קלאסיות: לפתח ללא עיצוב ולעצב כשהקונספט כבר נקבע, או לעצב מראש לפני שמתחילה עבודת קידוד ממשק המשתמש. האפשרות הראשונה מתאימה כשלא ברור לכם עדין לאן המוצר הולך ואתם רוצים ממשק ארעי שיאפשר לבחון את הטכנולוגיה או הקונספט. אם אתם יודעים לאן אתם הולכים, או לפחות חושבים כך, אל תיגשו למלאכת פיתוח הממשק לפני שיש לכם עיצוב ראשוני של המערכת. הרבה רעיונות מוצריים טובים מסתברים כגרועים כשמגיעים לעיצובם ועבודת העיצוב נוטה להחזיר את מאפיין המוצר חזרה לשולחן העבודה. זהו תהליך חשוב שכדאי שיקרה לפני שחלקים גדולים מהמערכת כבר נכתבו. בכל מקרה, פונקציית העיצוב היא אחת המוערכות פחות והחשובות יותר בתהליך ונוכחותה נדרשת לכל ארכו של הפיתוח. מעצב טוב יכול לחסוך מאות ואלפי שעות תכנות מיותרות.
HTML/CSS
עוד תחום הסובל מהערכת חסר הוא ה- HTML . הדרך מעיצוב לעמוד סופי מהגיהנום רצופה בכוונות טובות אך מי שרוצה בכך שהתוצאה תיראה כמו המקור – ברמת הפיקסל – ובכך שהדפים יעבדו בכל הדפדפנים המקובלים באותו האופן, ובכך ששינוי בסכמת הצבעים לא תוביל לכתיבה מחדש של כל האתר, כדאי שיתייחס לנושא ברצינות.
פיתוח ממשק משתמש
כשם שנדרש אופי מיוחד לפיתוח "צד שרת" כך נדרש אופי מיוחד לפיתוח של ממשק משתמש. הנאמנות לעיצוב, ההתעקשות על הניואנסים הקטנים של חווית המשתמש – דרושה כאן נשמה של משורר.
פיתוח "מתמחה"
יש לכם קומפוננטת פלאש מורכבת? צד מובייל? יישום וידאו? (כולם רכיבים בהם נתקלנו בויקידו) חישבו מראש כיצד אתם הולכים להתמודד עם העניין. גם אני חשבתי שמתכנת עם ותק של עשרים שנה ועם יכולת למידה של סוואנט יכול להתמודד עם כל דבר אבל ישנם תחומים שהם עניין של התמחות. עד שלא בנית עשרה כאלה אתה פשוט לא יודע עד הסוף איך עושים את זה נכון וכיצד להמנע משגיאות שיעלו לך ביוקר.
QA
"אני אעשה QA!" כן, בטח. תחום ה- QA הוא כבר מזמן הרבה יותר מסתם לבדוק את האתר באקספלורר ופיירפוקס. ישנו עולם שלם של קוד שאין לו ביטוי חיצוני אך הוא דורש בדיקה דקדקנית לא פחות – ואף יותר. Unit Testing, Functional Testing ושאר החבורה הם לא פריווילגיה של עשירים ואם אינכם רוצים שכל שינוי קטן בקוד יוביל לחודשים של בדיקות ושל תלונות משתמשים כדאי שתתייחסו לנושא ברצינות. ישנם לא מעט מיזמים שפשוט לא מעיזים לבצע שינויים בקוד מאחר ולא הניחו את תשתיות ה- QA הדרושות.
אז מה עושים עם כל זה?
אלו הן הפונקציות העיקריות בצוות הפיתוח של מיזם דוט קום. כמובן שיש עוד פונקציות כמו SEO ושימושיות שתפקידן חשוב בהחלט (ועוד יזכו להתייחסות בהמשך) אך מבחינת אבני בניין – ותקנו אותי אם אני טועה – זאת הרשימה הבסיסית.
"אז מה שאתה אומר זה שצריכים 10 אנשים ויותר כדי להתחיל מיזם דוט קום?" אז זהו, שלא. מה שכן צריך זה ייצוג נכון לכל אחת מהפונקציות המוזכרות. ישנם לא מעט מעצבים ומתכנתי ממשק משתמש היודעים לכתוב HTML מצוין כמו גם מנהלי פיתוח עם יכולות ארגון משובחות המאפשרות להם לנהל את הפרוייקט במקביל לניהול הפיתוח. החשוב הוא להגיע למצב בו כל אחת מפונקציות הפיתוח מצוותת לאדם בצוות בצורה הגיונית, מבלי להטיל על אנשים תפקידים שאינם יודעים לבצע, שיפריעו להם עם משימתם העיקרית בצוות או שלעולם לא יהיה להם זמן לבצעם. אפשר גם לדחות את ציוות ה- QA לשלב מאוחר יותר ואפשר גם להביא מעצב לאחר פיתוח הקונספט אבל צריך לדעת בדיוק את המשמעויות והמחירים הנלווים.
מגבלת המקום מונעת ממני להרחיב עוד ואתם מוזמנים לעשות זאת בתגובות. הפוסט הבא יעסוק בארגון נכון של תשתיות הפיתוח ועד אז – שבוע טוב לכולם!
ירון אורנשטיין: 
