מיצוי נכון של חברות יעוץ

Disclaimer:

בשנתיים האחרונות אני עובד כיועץ בכיר בחברת אלונה.

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

הזמן של המתכנתים עולה כסף:

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

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

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

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

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

שאלו לניסיון בתחום:

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

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

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

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

סיפור מניסיון עבר שלי כראש צוות ב- Radware  - רצינו לקנפג rmi over ssl  ב-   Jboss (היה מדובר בגירסה חדשה). פנינו לשלוש חברות יעוץ שונות שלושתן ענו תשובה שהן מכירות את הנושא ועשו את זה בעבר, הוקצה לכל אחת מהחברות זמן קצר (כמה שעות ) לעשות את הדבר , שכן מדובר בשינוי של מספר קצבי XML. שינוי מהיר עבור מישהו שמכיר את זה , אבל שלושתם כשלו.

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

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

איך בוחרים חברת יעוץ:

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

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

אחד מהיועצים הבכירים בתחום ה -  Erp אמר לי כי אנשים נוטים לדרג איכות של יועצים לפי עד כמה מה שאמר היועץ מתאים למה שהם חשבו, בדיחה שכנראה יש בה הרבה מהמציאות.

אז איך בכל זאת בוחרים חברת יעוץ:

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

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

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

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

איפה כדאי להכניס יועץ:

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

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

תהליכים טכנולוגיים חד פעמיים - כגון כתיבה של plug-in for eclipse ....

מקדו את תהליך היעוץ:

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

POC  - לעיתים פונים לחברות יעוץ בבקשה להכין sample POC עבור טכנולוגיה מסויימת. במידה ואותו POC לא מדגים את הצרכים הספיציפיים שלנו ורק מדגים טכנולוגיה כללית אז שילמתם כסף לשווא. אין שום צורך שיוכיחו לכם ש - jaxb or jboss or spring באמת עובדים. בכלל poc לרוב מבזבז כסף וצריך לשקול היטב נחיצות שלו ומיקוד שלו.

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

POC משתלם הוא POC שמציג לכם כלי מסויים וחוסך לכם את הזמן ללמוד את הקמת הכלי במידה והכלי הוא מורכב. כדוגמת סביבות monitor ....

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

Code Review - מבט על הקוד יכול ללמד הרבה על תהליכים ארגוניים. איכות הצוותים. בדיקות... ערבו מדי פעם יועץ שיסתכל על הקוד וינסה לתת לכם תובנות לא רק לגבי קוד אלא גם לגבי תהליכים ושיפור יכולות מתכנתים.

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

דברים שאתם לא יודעים לעשות  - במידה ובנק השעות שלכם מוגבל אזי יש לשים לב כי היועץ יבצע רק דברים שבהם יש לו יתרון מובהק עליכם. למשל אנחנו רוצים לטעון מידע ל- DB עם כל מיני לוגיקה. אין צורך שהיועץ ימפה עבורכם entities או יערוך xsd....תנו לו לעשות רק דברים שלכם יקחו לפחות פי 4. במידה וזמן היעוץ לא מוגבל אזי יש לשקול במונחים של עלות תועלת ולזכור שזמן מתכנת הוא יותר יקר מזמן היועץ.