מה לדעתכם עתיד העבודה מהבית?

BravoMan

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

מה שאת מתארת, זה לחלוטין לא מה שאני דיברתי עליו.

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

בנוסף, עבודה עצמאית לא אומרת שמוותרים על code review.

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

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

אני לא יודע מה אתם מפתחים שמנצריך 10 אנשים לעבוד על צד קליינט במובייל, אבל יש לי חדשות בשבילך:
על כל אפליקציה כמו שלך, יש 100 אם לא 1000 ויותר אפליקציות שאתה מכנה "פשוטות וקטנות", שעדיין נחוצות, שימושיות, ודורשות ידע וניסיון כדי לממש כמו שצריך, אבל לא התרוצצות.

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

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


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

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

מה שאת מתארת, זה לחלוטין לא מה שאני דיברתי עליו.

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

בנוסף, עבודה עצמאית לא אומרת שמוותרים על code review.

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


זה לא חדש לי שאתה מכל האנשים לא מבין אותי כאן בפורום |יעני|

אני לא יודע מה אתם מפתחים שמנצריך 10 אנשים לעבוד על צד קליינט במובייל, אבל יש לי חדשות בשבילך:
על כל אפליקציה כמו שלך, יש 100 אם לא 1000 ויותר אפליקציות שאתה מכנה "פשוטות וקטנות", שעדיין נחוצות, שימושיות, ודורשות ידע וניסיון כדי לממש כמו שצריך, אבל לא התרוצצות.

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

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


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

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

BravoMan

Active member
אבל הנקודות האלו של הדרכה ראשונית ו code review הן נקודות שדורשות קשר סדיר בין עובדים.
לא ממש.

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

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

vinney

Well-known member
בגלל זה כתבתי שצריך אפיון ותיעוד מסודרים.
ואלה נוצרים מהאוויר יש מאין בדרך פלא בלי שום התערבות אנושית בשום שלב, וודאי.
בנוסף, עבודה עצמאית לא אומרת שמוותרים על code review.
אני במקומך הייתי טוען שcode review לא חייבים לעשות בפגישות ישירות וonline.
אבל code review אמור להיות תהליך מסודר שמבוצע בסוף המשימה.
אבל זה הטיעון שאתה מביא? מה פתאום???
זה לא חדש לי שאתה מכל האנשים לא מבין אותי כאן בפורום |יעני|
עובדה שזה לא רק אני :)
אני לא יודע מה אתם מפתחים שמנצריך 10 אנשים לעבוד על צד קליינט במובייל
האמת היא... שאתה יודע.

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

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

אגב, מאוד מוזר לי שחברה בגודל שאתה מתיימר לעבוד בה צריכה ש-10 אנשי צוות ידברו אחד עם השני לוודא שלא דורכים זה לזה על הרגליים במקום להשתמש בכלי ארגוני \ אוטומציה כלשהי כדי לוודא שזה לא קורה.
כי כנראה לא עבדת בחברה שעובדת בסדר גודל כזה. לא נורא, קורה.
כמה פעמים נתקלתם במצב שמישהו לא דיבר עם מישהו אחר כי לא חשב שהוא ידרוך לו על הקוד, ובסוף דרך, והיית בעיה לעשות merge?
כמה זמן פיתוח הדיבורים האלה שורפים?
אתה חושב בצורה נורא פשטנית. זה לא בעיות של merge, זה מילא. זה כל מיני התנגשויות בהתנהגות, כל מיני חישובים שצריך לעשות לגבי מי מקבל איזה חלק מהמסך, כל מיני שיחות שצריך לעשות כדי שגרסת android תראה כמו גרסת ios, וכמובן גם צריך לוודא שהשינויים שצריך לעשות בbackend נעשים (וזה בכלל בצוותים אחרים עוד יותר גדולים שיכולים להיות מאוד מרוחקים ארגונית), וכו׳ וכד׳.

שוב, קנה מידה שכנראה מעולם לא עבדת בו, אבל אלה דברים מסובכים וחשובים כשאתה מתעסק עם כמות המשתמשים באפליקציות האלה. כל פיפס שלא עובד כמו שצריך משפיע על מליוני אנשים.
יש ספר שנקרא The mythical man-month אחד הנושאים המרכזיים שהוא עוסק בהם זה שמעבר לכמות מסוימת, לזרוק עוד מפתחים על פרויקט דווקא מאריך את זמן הפיתוח במקום לקצר אותו, ופוגע באיכות המוצר.
מזל שאתה יודע לגגל. כנראה שמעולם לא הייתי שומע על הספר הזה בלעדייך! :-D
לא אני ולא הספר טוענים שכל, או רוב, פרויקטי תוכנה צריך לפתח אדם אחד, אבל לעבודה קבוצתית בהחלט יש מחיר, ואת המחיר הזה מאוד רצוי למזער.
המושג ״עלות מול תועלת״ מוכר לך? אני מקווה, אני נותן לך פה קצת יותר קרדיט ממה שהיית מוכן לתת לי.
 

BravoMan

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

אני במקומך הייתי טוען שcode review לא חייבים לעשות בפגישות ישירות וonline.
חשבתי שזה מובן מעליו ולכן לא כתבתי...

אבל זה הטיעון שאתה מביא?
זה חלק מהסיבה שלא חייבים ישיבה פנים מול פנים, מה הבעיה שלך עם הטיעון הזה בדיוק?

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

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

מה זה משנה אם המעסיק הישיר של המפתח הוא חברה שמתמחה בפיתוח מובייל אך מפתחת עבור אחרות במקום לייצר מוצרים משלה, או אם מדובר בחברה מספיק גדולה להחזיק מחלקה in house למוצרי מובייל שלה?
המקום שאני עובדה בו עכשיו עושה גם וגם (גם מחזיק מחלקה In house וגם עושה outsourcing), כי גם אצלנו יש הרבה אפליקציות.

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

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

כל מיני שיחות שצריך לעשות כדי שגרסת android תראה כמו גרסת ios,
שמעתם על כלים כמו zeplin?

אצלנו מפתחים רק native (בלי כל מיני faltter וכו') לכן התאמת מראה בין הפלטפורמות עולה לא פעם, אבל מניסיוני, דיבור על זה רק מביא לבאגים כשהמוצר מגיע ל-QA, ואז מתחילים להתווכח מי אמר מה.
לאומת זאת, כשמכריחים מפתחים להיצמד לעיצוב מכוון (online), הכל הולך יותר חלק. וכאמור, לזה יש כלים היום.

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

אבל אלי בחברות ענקיות כמו שלך לאף אחד לא אכפת מהזוטות האלה, וכל עוד סיכמתם בע"פ שאנדרויד נסה להתנהג כמו iOS או להפך, ה-QA לא יפתח על זה באגים...

וכמובן גם צריך לוודא שהשינויים שצריך לעשות בbackend נעשים (וזה בכלל בצוותים אחרים עוד יותר גדולים שיכולים להיות מאוד מרוחקים ארגונית),
אין issue tracker שמאפשר לוודא מה בוצע ומה עלה ל-QA או לפרוד?

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

אני נותן לך פה קצת יותר קרדיט ממה שהיית מוכן לתת לי.
אני לא בנק ולא חברת אשראי! :-P:

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

אני מנהל כל יום שיחת מחלקה באופן מכוון שכוללת הן את המחלקה הפנימית שלי והן את ה-outsourcing שעובדים צמוד איתנו.
מעלים שאלות, בודקים אפה בדיוק עומדת כל משימה וכו'.

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

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

vinney

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

המקום שאני עובדה בו עכשיו עושה גם וגם (גם מחזיק מחלקה In house וגם עושה outsourcing), כי גם אצלנו יש הרבה אפליקציות.
וכל אפליקציה מפותחת על ידי בן אדם בודד?
אם אתה מייצר מסך באפליקציה שצריך לחלק בין כמה מפתחים, זה מקור לבעיות, וכנראה גם יצור "overload" של מידע עבור המשתמש.
אבל מה אני מבין...
ניכר שלא הרבה.
שמעתם על כלים כמו zeplin?
יש הרבה כלים מהסוג הזה, אז? מה הנקודה שלך חוץ מנסיון להרשים אותי בbuzzwords?
אצלנו מפתחים רק native (בלי כל מיני faltter וכו') לכן התאמת מראה בין הפלטפורמות עולה לא פעם, אבל מניסיוני, דיבור על זה רק מביא לבאגים כשהמוצר מגיע ל-QA, ואז מתחילים להתווכח מי אמר מה.
שוב, אתה חושב בקטן ועובד בקטן. אם אתה מחכה לQA כדי לגלות באגים אתה לא עובד בצורה טובה. ואם כשבאגים מתגלים אתה מתחיל להתווכח אז זה רק מוכיח כמה שיחות חשובות, ובשבלים מוקדמים.

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

choo

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

אתה לא מבין את ההבדל בין עבודה שכירה לעבודה קבלנית.


וכל אפליקציה מפותחת על ידי בן אדם בודד?

ניכר שלא הרבה.

יש הרבה כלים מהסוג הזה, אז? מה הנקודה שלך חוץ מנסיון להרשים אותי בbuzzwords?

שוב, אתה חושב בקטן ועובד בקטן. אם אתה מחכה לQA כדי לגלות באגים אתה לא עובד בצורה טובה. ואם כשבאגים מתגלים אתה מתחיל להתווכח אז זה רק מוכיח כמה שיחות חשובות, ובשבלים מוקדמים.


דיון מתנהל בכתב? זה נורא מאריך את התהליך. סיכום דיון צריך להיות בכתב, לא הדיון עצמו.

וודאי שיש, אלא מה?

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

זה בדיוק מה שטענת.

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

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

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

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

BravoMan

Active member
ואתה חושב שזה קנה מידה מקצועי.
תוכל להגדיר בבקשה כמה אנשים צריך לזרוק על code base נתון כדי שהוא יראה "מקצועי" עבורך?

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

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

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

אבל לכתוב אפליקציה לטפון?
אני יכול לחשוב על כמה שצריכות צוות, בעיקר משחקים רציניים יותר, אבל אפליקציית שירות שהיא בסה"כ קליינט נייטיב קצת יותר חכם ל-web api?

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

מפתיע אותי שאתה שואל בכלל...
כמעת כאילו אתה עובד באיזה מקום לא מקצועי שלא יודע על דברים כאלה...

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

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

וודאי שיש, אלא מה?
אז למה אתם צריכים שיחות פנים מול פנים כדי לדעת מה בוצע ומה לא???

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

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

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

vinney

Well-known member
תוכל להגדיר בבקשה כמה אנשים צריך לזרוק על code base נתון כדי שהוא יראה "מקצועי" עבורך?
תלוי באנשים. אנשים כמוך - כנראה שצריך הרבה ועדיין לא יהיה מספיק. אתה חושב שלינוס מתנהג בסדר, הרי, אמות מידה שלך לחלוטין לא רלוונטיות.
תתפלא, מבין מצוין.
אולי לך היית בעיה בהבנת הנקרא - השאלה היית מה זה משנה בקונטקסט של הדיון הנוכחי?
עבודה קבלנית זאת עבודת ״שגר ושכח״. אתה מזמין פרוייקט, הוא מגיע כשהוא מוכן, אתה לא צריך לדבר עם הקבלן בין לבין.

עבודה שכירה זאת עבודה בה אתה ביום-יום מנהל את העובד, מגדיר לו משימות, מוודא תוצרים, מוודא שהוא מבצע את כל התהליכים כנדרש, ומשתמש בכלים שהוא צריך להשתמש.

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

כן, מפתח אחד פר פלטפורמה.
נו בסדר, חברה קטנה, קורה.

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

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


אבל לכתוב אפליקציה לטפון?
אני יכול לחשוב על כמה שצריכות צוות, בעיקר משחקים רציניים יותר, אבל אפליקציית שירות שהיא בסה"כ קליינט נייטיב קצת יותר חכם ל-web api?
אז אתה לא יכול לחשוב.... אז?
אז הם חוסכים דיונים.
אתמול היה לי דיון ארוך עם העובדת שלי כי היא לא השתמשה בכלים האלה נכון ונוצר outage ושריפה שהייתי צריך לכבות.

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

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

BravoMan

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

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

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

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

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

לכן אני בספק רב שחברה כלשהי תשקיע באפליקציה של "שגר ושכח", שלא כוללת חוזה תחזוקה כזה או אחר.

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

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


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

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

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

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


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

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

באמת? אני אצטט: ״דיבור על זה רק מביא לבאגים כשהמוצר מגיע ל-QA, ואז מתחילים להתווכח מי אמר מה.״
חשבתי שאתה מפתח מנוסה מספיק כדי להכיר את הסיטואציה:
יש חוסר בהירות או מקום לפרשנות במסמכי אפיון ו\או עיצוב, מקיימים דיון בעל פה עם המפתחים כיצד יש לסגור את החור, הדיון אינו נכנס למסמכים כי "כולם הבינו כל מה שצריך", הגרסה עוברת שפיות ו-code review, מגיע ל-QA, לבודקים יש ראיונות משלהם איך צריך להשלים את החור, והם פותחים באג.

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

מה אתה חשוב שאתה מנהל?
צוות מקצועי שצריך להוציא מוצר לפי דרישות, שהולך לעבור בדיקות של צוות QA ואישור של לקוח.
מה בדיוק אתה מנהל? בסטה בשוק?

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

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

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

vinney

Well-known member
אה, אז אתה מעריך יכולות פיתוח בהתאם לאג'נדה פוליטית חברתית של האדם, ולא הידע הטכנולוגי שלו...
הבנתי. זה יכול להסביר כמה דברים...
לא יכולת פיתוח אלא יכולת עבודה בצוות, ולא לפי אג׳נדה פוליטית אלא לפי יכולת לנהל תקשורת תקינה עם אנשים אחרים.
מעניין מאוד גם שלא כתבת שזה תלוי בגודל של ה-code base, אלא רק באלו אנשים המפתח חושב שהם "בסדר" או "לא בסדר".
אני מבין שלפי הלוגיקה שלך, מפתח אחד בחולצת BLM יוכל לעשות עבודה של לפחות 20 מפתחים עם כובעי MAGA, נכון?
אני הייתי מעדיף אם מפתחים היו מתעסקים בפיתוח ולא בחבישת כובעים, אבל אחד היתרונות של לעבוד מרחוק הוא שאני לא צריך לראות מי חובש איזה כובע. נכון כיף?
נשמע שמעולם לא עבדת עם חברת קבלן.
ייתכן שיש פרויקטים קבלניים שאכן מתנהלים ככה, אבל ממש לא כולם.
פרוייקטים קבלניים מתנהלים ככה. מה שאתה מכיר כ״פרוייקט קבלני״ זה שיטת המצליח הישראלית בה מנסים להרגיש עם ולהיות בלי העובד השכיר. בארה״ב שיטת העבודה הזאת כבר מזמן הוצאה מחוץ לחוק (האמת שגם בארץ, אף אחד פשוט לא אוכף את זה).

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

_____


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

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

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

----

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


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

כשהם עובדים מרחוק כל זה נעלם. זה מקשה על העבודה שלי. כי אז אני תופס את הטעויות האלה אחרי שהן קורות, אני צריך להשקיע המון זמן בלדבר איתם באופן פעיל ולשאול אותם על מה הם עושים ואיך הם עושים את זה, לדגום ולדוג אחרי מידע מהם שהייתי מקבל מהאוויר רק מהרעש בחדר בו יושב הצוות.
אתה שואל ברצינות??? חשבתי שאמרת שאתה מכיר את הכלים האלה? |פנים|
זה היה נסיון פאסיב-אגרסיב להראות לך שאתה מקובע בעולמך ולא מבין איך עולמות אחרים עובדים. מוקאפ עושים לUI. לך תעשה מוקאפ לפרוייקט אופטימיזציה של מאגר נתונים מבוזר....
בהתחשב שמכל האנשים שאני דן איתם בכתב, הן בפורומים, והן בחיי המקצועיים והאישיים אתה היחיד שאומר לי את זה, הסטטיסטיקה לא לצידך...
או, ואני מרגיש שאני חוזר על עצמי, עולמך צר.
חשבתי שאתה מפתח מנוסה מספיק כדי להכיר את הסיטואציה:
יש חוסר בהירות או מקום לפרשנות במסמכי אפיון ו\או עיצוב, מקיימים דיון בעל פה עם המפתחים כיצד יש לסגור את החור, הדיון אינו נכנס למסמכים כי "כולם הבינו כל מה שצריך", הגרסה עוברת שפיות ו-code review, מגיע ל-QA, לבודקים יש ראיונות משלהם איך צריך להשלים את החור, והם פותחים באג.
שוב, אתה מראה לי שיש לך הרגלי עבודה מגונים. ״כולם הבינו כל מה שצריך״ מתורגם לסיכום דיון שמצורף לאותו האפיון, או לתיקונים באפיון עצמו. אתה לא באמת עושה transcript לכל ישיבה, נכון?
צוות מקצועי שצריך להוציא מוצר לפי דרישות, שהולך לעבור בדיקות של צוות QA ואישור של לקוח.
לא נשמע שזה מה שאתה מנהל. ודווקא בסטה בשוק צריכה ניהול מאוד טוב כדי להצליח, הצוות שלך כנראה מסתפק ביכולות המועטות שלך ואיכשהו לא כשל לגמרי עדיין.
השורה השלישית מוכיחה שהשורה השניה סותרת את הראשונה.
הצלחת לבלבל אותי לגמרי כי אין לי מושג מה ניסית להגיד.
אכן, אתה כל הזמן מחפש להביא לי טענות שיש בדיוק מחסומים כאלה, וגם כשאני מראה לך שיש דרכים להתגבר עליהם, או שאתה פוסל אותם, או שאתה מחפש עוד מחסומים, בכל הכוח.
לא, אני מראה לך שלמרות שאתה טוען שיש כלים ״להתגבר״ על המחסומים האלה מבחינה טכנולוגית, מעשית לכלים האלה יש מחיר שלא כל מעסיק מוכן לשלם.
 
למעלה