תגית: לקוחות

להבין את צרכי הלקוח
אחד הדברים החשובים לפרילנסר בתחום הפיתוח הוא להבין את צרכי הלקוח. הרבה פעמים דברים שלא היו מתקבלים בחברות טכנולוגיות מקובלים אצל הלקוחות. לקוח אחד ביקש להתממשק מול מערכת הERP שלו כך שכל עדכון בERP בטבלה מסויימת יעדכן אוטומטית את האפליקציה שלו. האופן שבו הוא עשה את זה היה שהERP הנפיק אחת לשעה קובץ טקסט עם רשימת השינויים ושמר אותה בתיקיה משותפת. באפליקציה החיצונית היה Timer שפעם בשעה קרא את הקובץ וייבא את הנתונים. היועצים הציעו להחליף את המערכת בטענה שזו שיטה גרועה. הם המליצו על SOA, Web Services שימוש במוצרי תווכה שונים ושרתי אינטגרציה. אבל לשאלה הפשוטה של הלקוח לאף אחד לא היה מענה: מה רע במצב הקיים?

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

הכנסת טכנולוגיות מגוונות מדי לארגון
עוד בעיה נפוצה היא שיועצים עצמאים נוטים למצוא את הכלי המתאים ביותר לפתרון הספציפי מבלי להתחשב באסטרטגית הIT של הארגון. בחברה מסויימת היה ERP של SAP, כמה אפליקציות דוט נט, בסיס נתונים של אורקל ופורטל ארגוני של SAP Portal. כשהם ביקשו לפתח אפליקציה תפעולית מסויימת, הקבלן בחר בOracle JDeveloper על שרתי Oracle IAS לפיתוח התוכנה. התוכנה היתה תוכנה קטנה ששרתה צורך מסויים והבעיה נוצרה כשבארגון "צמח" לפתע סט שרתי חדשים, סביבת פיתוח, ופלטפורמה שצריך לתחזק. זה דרש הקצאה של כוח אדם, יועצים, חומרה ורשיונות תוכנה רק בשביל אותה אפליקציה. אז אומנם הפיתוח הראשוני היה מהיר אבל התחזוקה רבת השנים שלא לדבר על שינויים ותיקונים גררו את הלקוח להוצאות כבדות ומיותרות. הפתרון הנכון היה לבחור באחת הפלטפורמות שנמצאות כבר בארגון ולפתח על בסיסה.

עומס טכנולוגיות – Over Kill
בעיה נוספת שמאפיינת בעיקר את הפרילנסרים חובבי הטכנולוגיות והגאדג'טים הוא שימוש מופרז בכלים מתוחכמים שבסופו של יום לא מספקים ערך מוסף ללקוח או אפילו פוגעים בו. הרבה פעמים מתכנתים רוצים להשתמש בטכנולוגיות המשוכללות והנוצצות ביותר כשמספיק משהו הרבה יותר בסיסי. למשל, שימוש נפוץ בשרתי JBoss ובJ2EE מנפחים פרוייקט ג'אווה כשהרבה פעמים כל מה שצריך הוא Servlet Container כמו Tomcat בשילוב עם Hibernate. אין טעם להשתמש בשרת אפליקציות כבד אם לא מתכוונים לנצל את הפונקציונליות שלו.

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

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

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