• Facebook Black Square
  • google-plus-square
  • LinkedIn Black Square
  • YouTube Black Square

© 2014 by imoko Consulting and Shirley Leor. All rights reserved.

ארבע הצעות להתנעה לאחר תקופת אתנחתא // בחרו את המתאימה עבורכם....

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

האם אני צריך לשווק את עצמי? אבל אני שכיר...! // כיצד משפיע עולם הגיוסים החדש עלינו העובדים?

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

הבטחת איכות או אבטחת איכות?// - בואו ננפץ כמה מיתוסים מעולם בדיקות התוכנה...

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

חמשת הסיוטים הגדולים של מנהלי הפיתוח מול אלה של מנהלי הבדיקות// - מכירים ?

בתהליך פיתוח תוכנה קיימות 2 קבוצות עבודה מרכזיות אשר רוב העבודה נעשית על ידן: קבוצת הפיתוח קבוצת הבדיקות הליך פיתוח תוכנה תקין מצריך את קיומן של שתי קבוצות אלו. שתי הקבוצות תומכות אחת בשניה בתהליך הפיתוח. כל שינוי בתהליכי פיתוח התוכנה מצריך את התיישרותה של קבוצת הבדיקות בהתאם. ברוב המיקרים, חוק אצבע זה אינו עובד הפוך. בחרתי להביא כאן את חמשת הסיוטים הכי גדולים של מנהלי הפיתוח ומנהלי הבדיקות בתהליך פיתוח תוכנה... 1. ניהול גרסאות (CM) מנהלי הפיתוח: ניהול מספר גרסאות במקביל (גרסה ראשית מול branch מול patch) מנהלי הבדיקות: כל עליית גירסה ו/או עדכון בכל רמה ותכולה מצריכה סבב בדיקות משלה. ככל שיש יותר 2. אבולוציה מול רבולוציה מנהלי הפיתוח: כאשר מדובר במערכות מידע מסועפות ומורכבות, האופציה העדיפה ת