פורסם לראשונה בבלוג הישן ב – יוני 2010
את הפוסט הזה אני רוצה להקדיש לכל אלו שאכפת להם.ן, אני חושב שזה רלוונטי למגוון רחב של תחומים.
כבר בעבר דיברתי (כלומר כתבתי) על מה זה לדעתי ארכיטקט.
ארכיטקט, כן יש חיה כזאת, יכול להיות בכל מיני roles במסגרת פרויקטים שונים.
אני רוצה לנסות לתאר באיזה תפקידים ניתן למצוא את הארכיטקט.
- כמובן שבבסיס ניתן לראות אותו בתוך הפרויקט כמוביל טכנולוגי או כראש הצוות
- הצורה השניה והמאוד מקובלת, ארכיטקט בתור יועץ שמתלווה לפרויקט בשלבים שונים ונותן שירותי ארכיטקטורה.
- הצורה האחרונה שבעייני היא ייחודית זה הארכיטקט בתור ארכיטקט ארגוני.
בקריירה שלי זכיתי להיות בכל הצורות האפשריות ובכולן נהנתי (שששש אל תגלו) ולשמחתי הייתי מעורב בבניה והובלה של מספר קבוצות ארכיטקטים בצורות שונות
תמיד הובילך אותי עיקרון פשוט מאוד==> ההצלחה היא של הפרויקט הכישלון הוא של כולם. ולא פחות חשוב שימשו במילה אנחנו ולא הם/אתם .
נקודה נוספת המאפיינת את עבודה של ארכיטקט הוא הכלל הפשוט – מי שמחליטה היא מנהלת הפרויקטת, בתור ארכיטקטים נייעץ, נעזור, נבחן, נדבר/נצעק ננסה לשכנע אבל תמיד כאשר תתקבל ההחלטה, האמירה היא שאנחנו ביחד באותה סירה.
אבל לכל קוראי וקוראות השורות שהחיוך עולה על פרצופם.ן אני יכול להגיד כן כן החיים הם לא כל כך פשוטים.
לכל פרויקט יש סט שלם של אילוצים ולא תמיד ההחלטות שמתקבלות הם הטכנולוגיות ביותר הוא אלו שעונות על קריטריונים של הנדסת תוכנה.
כבר הרבה מאוד זמן אני מנסה למצוא את הנוסחה המנצחת איך מצליחים לרוץ גם ריצה של 100 מטר וגם ריצת מרתון.
לדעתי וזו דעתי האישית בלבד יש דרך לעשות זאת ואני בטוח שהיא לא היחידה.
הנוסחה שלי == אמון , יישור קו ומציאת מכנה משותף , הפריה הדדית ושיפור מתמיד
אמון
השלב שהכי קשה להשיג ולאחר שכבר הושג שהכי קל לאבד.
בדרך כלל לארכיטקטים מתלווה הילה של שחצנות, יהירות או כל סטיגמה אחרת שתבחרו. ושלא תבינו לא נכון האמירות לא תמיד תלושות מהמציאות. לדעתי החטא הקדמון של הארכיטקט הוא חטא היהירות!!!!
אני מאוד מאמין שהאמון מתחיל בלהיות בן אדם וגם מקצוען כלומר אם הארכיטקט.ת אומר.ת אמירה אזי חייב להיות לה ביסוס ברמת סמך מאוד גבוהה. לא לשכוח אמון קשה להשיג וקל מאוד לאבד.
דוגמא פשוטה אם יש אמירה שלכתוב ToString לכל אובייקט מידע זה אמור להיות פשוט ומועיל הפעולה המתבקשת זה להראות מימוש נכון ואיפה זה באמת מועיל.
דוגמא שקל לאבד את השותפים, האמירה "בגרסה הבא זה יעבוד יותר טוב" וזה לא לדעת מה יש בגרסה הבאה…. או קודם לבדוק שזה באמת אמור לעבוד.
יישור קו ומציאת מכנה משותף
זהו השלב הכי קשה שדורש הכי הרבה יצירתיות. הרי זה ידוע לכל שארכיטקטים אוהבים לדבר בשפת ה….
DSL, NoSQL , DI ,ML ,JWT , Angular ,RestAPI , Clude, SaaS , SOA , DAL ,BL ,UX ,UI, IOT , DI , AOP , DFO
נו אתם כבר מביניים הרבה קיצורים טכנולוגיות שיטות. בשורה התחתונה אנחנו מבלבלים את השותפים שלנו.
לכן שלב זה צריך לכלול ראשית מציאת הפערים , חלק חשוב בשלב זה, לאחר מכן בניית תוכנית הכשרות מהירה יעילה וממוקדת
ביחד עם השותפים יש ליצור שפה אחידה כמובן שתחילה בדברים החשובים ביותר אבל לבסוף אפילו כיצד מבצעים סקר קוד.
מתוך ניסיון של מספר לא קטן של פרויקטים ושותפים הרוב רוצים לייצר מכנה משותף וכמובן ליישר קו.
מה שחשוב שזה נעשה בשיתוף פעולה תוך הבנת כלל הצרכים ולא רק איך כותבים קוד נכון.
הפריה הדדית ושיפור מתמיד
הפריה הדדית??? כן כן כל אחד כולל הארכיטקט לומד השותפים האחרים ומלמד באותה מידה. אני תמיד שמח לראות שכמו שלימדתי אחרים , אחרים לימדו אותי לא פחות.
וכמובן אסור להיכנס לזחיחות תמיד צריך לשאוף לשיפור תמידי, זה נכון שהאויב של הטוב הוא הטוב ביותר,
אבל האויב של חוסר שיפור תמידי הוא קיבעון ומעבר לעבודה בצורת תבניות ללא שום יכולת חשיבה מחוץ לקופסא.
כמובן שכל השלבים הם מחזורים וכל השלבים נדרשים לתחזוקה שוטפת.
אם זה לזכור שאמון קל לאבד
דרך שמירה על מכנה משותף ולא רק ברמת קוד
וכמובן שיפור והפריה
משפט קצר לסיכום – ארכיטקט ללא סמכות זה הארכיטקט הטוב ביותר
על תיפלו למשפט הנדסת תוכנה היא חיינו אבל לא בשבילנו……………..
