אנו נוטים להתייחס לטכנולוגיה חדשה כמו הגביע הקדוש, מגדלור של אור, והתשובה לכל מה שהוא איטי, לא יעיל וישן. וזה יכול להיות - אם זה מיושם עם מטען רב של תכנון וראיית הנולד.
אבל ובכן, כולנו יודעים איך זה הולך.
במהלך שנותיי בממשלה, שבהן לפעמים זה הרגיש כאילו אנחנו משחקים משחק של הדבקה טכנולוגית שאי אפשר לנצח, למדתי מה יכול לקרות כשראיית הנולד הזו מובנת מאליה. זה נראה קצת פחות כמו הגביע הקדוש והרבה יותר כמו חריגה בעלויות, עיכובים ופתרונות מפותלים לבעיות פשוטות אחרת.
כפי שלמדתי, אחד המפתחות העיקריים לפרויקט טכנולוגי מצליח הוא הקשר ההרמוני בין הצוות העסקי וצוות הטכנולוגיה. מניסיוני, הצוות העסקי נהג לעיתים קרובות לשינוי (אנו זקוקים למערכת מורכבת יותר למעקב אחר הוצאות מענק פדרליות, למשל), אך לא יכולנו להשיג מושג של התקדמות בלי שהמפתחים ומנהלי פרויקטים בתחום ה- IT יוכלו לעשות זאת קורה. לעתים קרובות הפרויקטים הסתיימו בהרבה מלהיות הרמוניים, תוצאה של דיבור שפות שונות ושמירה על ציפיות שונות בהרבה (שינוי שנראה לי קל, למשל, התברר לעיתים קרובות כמפתח עבור המפתחים).
אבל עסקים וטכנולוגיה יכולים - וחייבים - להיות חברים. החדשות הטובות? השגת הרמוניה באמת לא כל כך מסובכת. כמו כל שיתוף פעולה, זה קשור לתדירות ואיכות התקשורת, מערכת יעדים מוסכמת הדדית ותוכנית לטיפול בשינוי כמעט בלתי נמנע של אותם יעדים. להלן מספר הנחיות בסיסיות לניהול חלוקת הטכנולוגיה העסקית.
1. המטרה למסמר את הדרישות בפעם הראשונה
חשוב על הדרישות העסקיות כתכנית. לא הייתם מציירים סט שרטוטים רישומים לבית, מסירים אותם לקבלן ומאחלים לו בהצלחה. לא הייתם חוזרים שלושה שבועות לבנייה ומבקשים ממנו להוסיף קומה שלישית וחדר אמבטיה רביעי, ואולי חלון מפרץ בסלון. וודאי שלא הייתם מציירים את ההדפסות שלכם ללא תשומת לב של אדריכל ומהנדס.
פרויקט טכנולוגי אינו כה שונה. זה צריך להיות מעוצב בדיוק, וברגע שהפיתוח מתחיל, לא תמיד קל להכיל שינויים מבלי להשפיע על כל הבסיס. זו הסיבה שחשוב מאוד להיות מקיף ככל האפשר מההתחלה ולקבל את הקלט והמומחיות הדרושים לך כשאתה חושב מה הפתרון ידרוש. ראיינו את משתמשי הקצה כדי להבין את האתגרים שעומדים בפניהם ובאופן מדויק כיצד הם יצטרכו להשתמש בטכנולוגיה החדשה. אל תניח הנחות ואל תשאיר חלקים מהתכנון להמשך.
2. אך הכירו בכך שתחסרו מעטים
עם זאת, מצאתי את זה כמעט בלתי אפשרי לדמיין כל תכונה יחידה לה אנו זקוקים בשלבי התכנון המופשטים. באופן בלתי נמנע, ברגע שהמערכת הייתה בפיתוח, נבין ששכחנו לבקש פונקציית חיפוש מתקדמת או כפתור "שמור והמשך". כאשר ניגשנו למפתחים לבקש מהם בחביבות להתאים לבקשות החדשות הללו, לעתים קרובות נפגשנו עם תסכול. אולי השינוי החדש ידרוש מהם לבטל את העבודה שכבר ביצעו ולארגן מחדש חלקים מהפתרון. אולי חזינו שזה ייקח שעתיים כשלמעשה זה ייקח יום.
יתכן שלא תוכלו למנוע את הגילויים המאוחרים-במשחק, כך שהדבר הכי טוב שתוכלו לעשות הוא לבנות מאגר שיוכל להכיל אותם. הוסף שבוע נוסף לציר הזמן הראשוני שלך ותוספת של 5-10% לתקציב שלך. ארגונים רבים, המכירים בתדירות ההשתנות של הציפיות, נקטו גישה זריזה לפיתוח, ומפעילים טכנולוגיה בשלבים כדי לאפשר הערכה מחודשת תקופתית. לא משנה מה הגישה שלך, אל תטעה לחשוב שחשבת על הכל מההתחלה. זה כמעט ולא קורה.
3. הכירו את זחילת היקף כשאתה רואה את זה
ככל שהפרויקט מתקדם וצרכים חדשים מתגלים, חשוב להבדיל בין אלה שאתה באמת צריך לבין אלה שאתה רק רוצה. בקשת המפתחים שלך להכיל כל פעמון ושריקה שהמוח יכול לחלום, בדרך כלל מוביל לפרויקטים בלתי נגמרים ולתוצאות סיום מורכבות מדי. יש לתעדף כל בקשה חדשה, לפני שהיא מתבצעת.
כשאתה שוקל תכונה, שאל את עצמך כמה שאלות בסיסיות: האם המערכת תעבוד בלעדיה? כמה זמן ייקח ליישם וכמה תועלת תועבר בסופו של דבר למשתמש הקצה? אם נחכה עד לשחרור עתידי כדי לטפל בזה, האם משהו יאבד? זה תרגיל של סדרי עדיפויות, וכל דבר ניתן להקצות לו מעמד של גבוה, בינוני או נמוך. אם הוא נמוך, הכניסו אותו לחניון פיגורטיבי - שמעתי על חברות עם מסמכי "בקשה לפיתוח חלומות" שכל אחד יכול להוסיף להם רעיונות והמהנדסים יכולים לדפדף בשעות הפנאי שלהם. תמיד ניתן לבקר בו מחדש כחלק מקבץ שיפורים שיבוצע ברגע שהפרויקט יוצא מהשטח ופועל בהצלחה.
4. פיתוח שפה נפוצה
כל מערכת חדשה כוללת קבוצה של יעדים עסקיים בבסיסה. זה יאפשר לך ללכוד יותר נתונים, לייעל תהליך קיים או להציע שירותים חדשים ללקוחות שלך. זה קריטי שהצוות העסקי וצוות הטכנולוגיה ישבו לפני שתתחיל עבודה כלשהי ותעביר את המטרות הללו. אסור שהיעדים העסקיים ילכו לאיבוד בתוך ים של דיבורים טכניים, והם חייבים להישאר בחשבון היטב בכל שלב בעבודה.
פיתוח שפה משותפת פירושו לא רק קביעת יעדים קולקטיביים, אלא מעקב אחר ההתקדמות באופן שעובד עבור כולם. עסקים וטכנולוגיה עשויים להשתמש בכלים שונים כדי למדוד את עבודתם, אך צריך להיות לפחות השקפה אחת על ההתקדמות המשותפת. זה יכול להיות פשוט כמו תוכנית פרוייקט או גיליון אלקטרוני עם שדות מוסכמים, כמו תאריכים ויעדים ואחוזים מלאים, כך שלכולם יש גישה למצב של כל משימה שתושלם. המטרה היא להימנע ממצב בו הצוות העסקי חושב שהם באמצע הדרך וצוות הטכנולוגיה אומר שהם רק רבע - לכל אחד צריך להיות אותה הבנה של מה נעשה ומה שנותר לעשות.
אתה יכול לדבר בתוכניות עסקיות וב- PowerPoints, והם עשויים לדבר בקוד, אבל אלא אם אתה מתקשר בבירור מההתחלה, לעולם לא תצליח לצאת ממנה בבל. פרויקט טכנולוגי מצליח עוסק במפגש מוחי - לא רק בהתחלה, אלא בכל שלב בדרך. הכיר את ההנחות שלך ונסה לא להכניס יותר מדי. ככל שהפער בין עסק וטכנולוגיה קטן יותר, כך יהיה קל יותר לחצות את הגשרים שלכם יחד.
