“הצוותים שהרוויחו הכי הרבה מ-AI היו אלה שתכננו את זה בכוונה.”
ככה סיכמתי את הלקחים מהטמעת AI בצוות הפיתוח שלי.
השורה התחתונה: מי שאימץ AI הכי מהר – לא בהכרח הרוויח.
SDLC הוא מחזור פיתוח התוכנה- מהרעיון ועד שהפיצ’ר מגיע ללקוח. כשבונים אותו מחדש לעבודה עם AI, בעולם קוראים לזה AI SDLC.
כשמכניסים כלי AI למפתחים בארגון, כמות העבודה שיוצאת מהצוות עולה מהר. כדי שהיא תישאר איכותית, בלי רעש בסביבת הייצור ובלי עבודה חוזרת, צריך להכניס סדר לתהליך.
הסדר הזה בנוי מחמש החלטות של מנהל, ומקבלים אותן כשהצוות כבר מתחיל לעבוד עם AI.
מה AI אמור לשפר במחזור פיתוח התוכנה בארגון?
ההחלטה הראשונה היא מה אתם רוצים לשפר, ו”להכניס AI” זו עוד לא תשובה.
בכל מחזור פיתוח תוכנה בארגון יש שלב שבו הקוד מחכה בדרך ללקוחות.
כשיודעים איפה העבודה מחכה, יודעים גם מה למדוד. למשל, כמה זמן לוקח לפיצ’ר להגיע ללקוח, וכמה תקלות מגיעות איתו.
מי שמדלג על ההחלטה הזאת מודד בסוף את מה שהכי קל לספור, כמה קוד נכתב, אבל יותר קוד עוד לא אומר שהלקוח קיבל משהו מוקדם יותר.
מי צריך להיות אחראי על AI בצוות הפיתוח?
אדם אחד בהנהלה, בדרך כלל CTO או סמנכ”ל פיתוח.
התפקיד שלו הוא להחליט איזו דרך עבודה עוברת לכל הצוות, ואיזו נשארת ניסוי של מפתח אחד.
כשאין אחראי, כל מפתח מוצא לעצמו דרך משלו לעבוד עם AI. חלק מהדרכים האלה טובות, אבל אף אחת מהן לא עוברת לשאר הצוות.
איזה מידע אסור להכניס לכלי AI?
בדרך כלל זה מידע על הלקוחות שלכם, פרטים על איך המערכת בנויה, ופיצ’רים שעוד לא השקתם.
את הרשימה קובעים מיד, כי אחרי שכולם כבר עובדים עם הכלים, קשה מאוד לדעת מה כבר הוכנס אליהם.
לכן כותבים אותה, וכל מי שמקבל גישה לכלים מכיר אותה מהיום הראשון.
רוצים להבטיח שהצוות שלכם ישתמש ב-AI בצורה שבאמת תוביל לקיצור זמני פיתוח?
השאירו פרטים כאן לתיאום שיחת מיקוד
מילוי הפרטים לטובת יצירת קשר מהווה הסכמה למדיניות הפרטיות של האתר
באילו שלבים הצוות מחליט, ובאילו ה-AI עובד ״לבד״?
כשהכנסנו AI לצוות שלנו, התוכנית הייתה פשוטה. ה-AI כותב, והמפתחים עוברים על התוצאה בסוף.
בפועל, המפתחים מצאו את עצמם כותבים יחד עם ה-AI, ומעבר קצר על התוצאה בסוף כבר לא הספיק.
אז העברנו את ההחלטות של הצוות לשלב שלפני כתיבת הקוד: קודם מסכימים מה בונים, ורק אחר כך ה-AI כותב.
שם הכי קל להשפיע על התוצאה, כי עוד אין קוד שצריך לתקן.
מי שמדלג על זה משאיר את כל ההחלטות לבדיקה בסוף, ושם העבודה נתקעת.
למה צריך לחזק את בדיקות האיכות כשמכניסים AI?
Google סיכמה את דוח DORA שלה מ-2025 במשפט אחד: AI מגביר את מה שכבר יש בצוות. צוות חזק נהיה טוב יותר, וצוות שמתקשה רואה את הבעיות שלו גדלות.
לכן מחזקים את הבדיקות האוטומטיות על הקוד כבר מההתחלה, במקביל לעבודה עם ה-AI.
בלי זה, הצוות כותב עם AI הרבה יותר קוד, ואותם מפתחים בכירים צריכים לבדוק את כולו.
אותו צוואר בקבוק למרות ה-AI = אותו קצב פיתוח אחרי שהוצאתם כבר כסף על רישיונות.
לתת ל-AI לכתוב יותר קוד בלי לחזק את הבדיקות, זו אחת משלוש טעויות בהטמעת AI SDLC שפירטנו בכתבה נפרדת.
מאיפה מתחילים את ההטמעה בצוות הפיתוח?
מתחילים בקטן. בוחרים צוות אחד, מריצים איתו פיילוט, ולומדים תוך כדי מה עובד ומה צריך התאמות. את חמש ההחלטות מקבלים במקביל, כך שהסדר נבנה יחד עם העבודה. בכתבה איך מתחילים בצוות אחד פירטתי איך בוחרים את הצוות הראשון ומה לומדים ממנו.
כשאנחנו באים להטמיע AI בצוות פיתוח, אנחנו בוחרים יחד עם ההנהלה את הצוות שמתחיל ראשון, ומקבלים איתה את ההחלטות האלה: איפה העבודה נתקעת בדרך ללקוחות שלכם, מי מוביל, ומה לא נכנס ל-AI.
משם עובדים צמוד עם הצוות, עד שזה רץ אצלכם גם בלעדינו.
ה-AI יגרום לצוות שלכם להוציא יותר. הסדר בתהליך קובע אם זה יגיע ללקוחות תקין, או יחזור לתיקון.
רוצים לבחון את שדרוג הפיתוח בצוות שלכם? השאירו פרטים לקביעת שיחת מיקוד ללא עלות.
פרטים נוספים אפשר למצוא בהטמעת AI בצוותי פיתוח.
רוצים לראות איפה הדליברי שלכם נתקע ואיך אתם יכולים באמת לקצר זמני פיתוח עם AI?
מלאו את הפרטים שלכם כאן, ונחזור אליכם לתיאום שיחת מיקוד.
מילוי הפרטים לטובת יצירת קשר מהווה הסכמה למדיניות הפרטיות של האתר
שאלות שמנהלים שואלים כשמכניסים כלי AI לפיתוח
מה מנהל צריך להחליט לפני שמכניסים AI לצוות הפיתוח?
איך מונעים דליפת מידע רגיש לכלי AI בארגון?
האם הטמעת AI בפיתוח היא החלטה של ההנהלה או של המפתחים?
מה כדאי למדוד כשמכניסים AI לצוות פיתוח?
למה לא מספיק לתת לכל מפתח רישיון לכלי AI?
