אני מציע לך להמשיך עוד כמה חודשים, ללמוד כמה שיותר טכנולוגיות ואז לעזוב. לדעתי קשה מאוד לשנות דברים לבד, במיוחד כשאין לך באמת כוח, את לא בתפקיד ניהולי וממה שאני מבין גם אין לך הרבה ניסיון מקצועי ולכן גם פה המעמד שלך פחות חזק. אני חושב שבגדול זה להילחם בטחנות רוח. במקום הבא תנסי לבדוק כמה שיותר בראיונות שהמקום באמת מתאים לך ושדברים מתנהלים באופן מסודר ואם אחרי חודש את רואה שלא אז תעזבי, עכשיו כשאת שנה זה קצת מלכוד, בגלל זה הייתי נשאר עוד כמה חודשים. באופן כללי אני לגמרי מסכים ומבין אותך, יש בהייטק הרבה אנשים שהם חכמים אבל לא הכי מסודרים וזה גורם לכאוס, דברים שנאמרים בעל פה, טעויות שחוזרות על עצמם, לא באמת עובדים לפי מתודולגיות קבועות, לא חושבים על שיפור תהליכים קיימים
יצא למישהו לעבוד בסטארט אפ שמתנהל בצורה לא מסודרת?
- פותח הנושא ShadowKit
- פורסם בתאריך
האמת שזה מעודד לשמוע שהמצב הזה מוכר ולא ממש חריג אצלי.
כי באיזשהו מקום אני די משליכה על עצמי בסוף את הכעס של איך אני לא מבינה משהו שבכלל לא הסבירו לי.
הבעיה היא שנורא קשה ללמוד גם שעובדים בצורה כזאת. אני חושבת שבמקומות שמתנהלים בצורה יותר אינפורמטיבית ומסודרת לומדים יותר. אבל אני אכן אשאר עוד קצת כדי "לצבור" ניסיון וידע מקצועי...
עבדתי בשני מקומות כאלה, ומניסיוני אפשר לשרוד שם (לא יותר). מורידים ראש, מתרכזים רק בפרויקט המוקצה ומכסת"חים באמצעות מיילים. אפשרי אבל למה? במצב השוק היום קל למצוא עבודה דומה בחברה יותר מסודרת.
במקומות כאלה עובדים יותר קשה ומפיקים (ומתקדמים) פחות, בתקופת המשבר הראשון (תחילת המילניום) מצאתי את עצמי עובד בחברה כזאת מחוסר ברירה ושנאתי כל רגע. ברגע שהצלחתי למצוא מקום עבודה תחליפי התחפפתי. לפני זמן לא ארוך במיוחד הייתי שוב בסיטואצייה דומה של מקום מבורדק (באשמתי, לא בדקתי אותם לעומק והתרשמתי אישית מהסמנכ"ל פיתוח) ופשוט עזבתי.
אני לא חושב שניתן לתקן מקום שנשאר בפאזת הסטארטאפ כאשר הוא גדל למספר תלת ספרתי של עובדים, לפחות לא בקלות. אם ההנהלה לא מבינה כי לא ניתן לתכנן פרויקט שלם לקבוצת פיתוח על ארוחת פיצה בלילה ו PDR מסדרון זה מתיישהו יובן להם ובדרך כלל בדרך הקשה. ישנם מצבים גרועים יותר של Job security שבהם בכוונה לא מעבירים ידע לשאר המהנדסים, זה קרה בעיקר אצל וותיקים שמשום מה חשבו שהשמש זורחת להם מהתחת.
בקיצור, למה את עדיין שם? ממה שניתן להבין מדובר על תקופה לא קצרה אז למה את שורדת את זה?
במקומות כאלה עובדים יותר קשה ומפיקים (ומתקדמים) פחות, בתקופת המשבר הראשון (תחילת המילניום) מצאתי את עצמי עובד בחברה כזאת מחוסר ברירה ושנאתי כל רגע. ברגע שהצלחתי למצוא מקום עבודה תחליפי התחפפתי. לפני זמן לא ארוך במיוחד הייתי שוב בסיטואצייה דומה של מקום מבורדק (באשמתי, לא בדקתי אותם לעומק והתרשמתי אישית מהסמנכ"ל פיתוח) ופשוט עזבתי.
אני לא חושב שניתן לתקן מקום שנשאר בפאזת הסטארטאפ כאשר הוא גדל למספר תלת ספרתי של עובדים, לפחות לא בקלות. אם ההנהלה לא מבינה כי לא ניתן לתכנן פרויקט שלם לקבוצת פיתוח על ארוחת פיצה בלילה ו PDR מסדרון זה מתיישהו יובן להם ובדרך כלל בדרך הקשה. ישנם מצבים גרועים יותר של Job security שבהם בכוונה לא מעבירים ידע לשאר המהנדסים, זה קרה בעיקר אצל וותיקים שמשום מה חשבו שהשמש זורחת להם מהתחת.
בקיצור, למה את עדיין שם? ממה שניתן להבין מדובר על תקופה לא קצרה אז למה את שורדת את זה?
תודה על התגובה. יש לדעתך דרכים לבדוק את זה לפני שאתה נכנס לחברה? מה למשל? לקרוא ביקורות על החברה?
מגמה מעניינת ששמתי לב אליה היא שככל שיש לאנשים יותר ותק בחברה כך הם פחות אינפורמטיבים, וזה מצחיק (ועצוב) כי זה קרה באופן קונסיסטנטי אצלנו. הבן אדם עם הכי הרבה ותק פחות אינפורמטיבי בעוד שהבן אדם עם הותק הנמוך ביותר, מאוד מאוד אינפורמטיבי.
כאילו ככל שאתה יותר זמן בחברה, כך החשק שלך להיות אינפורמטיבי יורד... האמת שגם מרגישים את זה שמגיעים לחברה, כל אחד בשלו ומתנהגים כאילו להסביר למישהו אחר משהו זה ממש עונש שנגזר עליהם.
randomUser432
New member
לצערי אני גם חוותי משהו דומה - חלק מissue נכתבו במילים בודדות והיה קשה להבין מה רוצים, גם feature היו מתוארים הרבה פעמים בחסר,
בגלל תחלופת כח אדם וחוסר תיעוד היו איזורי קוד שהיה קשה להבין מה "כוונת המשרור" ותחת אילו אילוצים הם נכתבו ולפעמים בגלל חוסר תיעוד של משימות ושיחות היו קצרי תקשורת.
אם הייתה לי מכונת זמן הייתי אומר לעצמי לא לחתום שם, מקווה שהדברים ישתפרו בשבילך.
בגלל תחלופת כח אדם וחוסר תיעוד היו איזורי קוד שהיה קשה להבין מה "כוונת המשרור" ותחת אילו אילוצים הם נכתבו ולפעמים בגלל חוסר תיעוד של משימות ושיחות היו קצרי תקשורת.
אם הייתה לי מכונת זמן הייתי אומר לעצמי לא לחתום שם, מקווה שהדברים ישתפרו בשבילך.
מעניין מה שאתה אומר. זה ממש מה שקורה אצלנו...
אני לא יודעת אם אני מצטערת שחתמתי שם, אבל אם עכשיו היתה לי הזדמנות וודאית לעבור למקום אחר שאני יודעת שמתנהל בצורה יותר מסודרת, כנראה הייתי הולכת על זה. אני לא ממש מעורבת עם מחלקות אחרות, אבל אני מקבלת מהם את הרושם שהם קצת יותר מסודרים ממחלקת פיתוח. (עדיין עובדים במנגנון של כאוס, אבל קצת יותר מסודרים)
randomUser432
New member
לפני שחתמתי שם הייתי בטוח שמכל הצעות העבודה שיש לי זו הכי טובה עם האנשים הכי נורמלים, בדיעבד זה לא היה נכון.
אלא אם יש לך מישהו שאת מכירה וסומכת עליו בתוך החברה אני לא חושב שאת יכולה לדעת מה המצב מבפנים - מה שגם חבר מבפנים זה לא ערובה שהיה בסדר.
את יכולה תמיד לחפש בשקט מהצד - אם יהיה מקום שתופס לך את העין תשקלי לעבור.
AnarchistPhilosopher
Well-known member
אם הייתה לך מכונת זמן לא היית צריך יותר לחתום בשום מקום...
הייתי במצב דומה בקטע של התיעוד, למרות שבמקרה שלי זה גם היה תיעוד ללקוחות (מה אם הלקוחות, לא מעניין אותם שאין תיעוד?), אני כן חושב שזה משהו שקשה לעשות "מהצד" ובמקרה שלי עד שזה לא הוגדר כמשימה שנכנסה ללוחות זמנים זה לא ממש בוצע, אז אם את רוצה לעשות את זה תבקשי שזה יוגדר כמשימה כדי שלא תיצור יותר מדי לחץ. טיעון שייכול לעזור הוא שלפעמים כאשר כותבים תיעוד מוצאים כל מיני דברים עקומים ובעיות בשימושיות (ככה זה היה במקרה שלנו) אז את ייכולה להגיד את זה למנהל בתקווה שזה יעבוד.
יש טסטים אוטומטיים? גם טסטים ייכולים להיות סוג של תיעוד.
אתם ייכולים להשתמש בgitea (שזה משהו כמו github רק קוד פתוח) ולאכסן את התיעוד באיזה פורמט מבוסס טקסט כמו latex או markdown, ככה אנשים יוכלו להגיש בקשות לשינויי הקוד/תיעוד ויהיה אפשר לעבור עליהם כדי לראות אם הם טובות או לא (יהיו אנשים שיהססו לכתוב תיעוד כי הם לא בטוחים אם זה טוב כמו מתכנתים זוטרים או אפילו לקוחות), אפילו אם אנשים רק יוסיפו לדברים בשביל שימוש אישי כדי שיהיה להם רפרנס לעתיד זה עדיין ייכול להתפתח לא רע.
אני חושב שכן כדאי לקחת בחשבון שקוד הם גם סוג של תיעוד, ואתה ייכול גם ללמוד דברים מלנסות להבין את הקוד שלא הייתה מבין אם היו מסבירים לך (מה שייכול לעזור לעסק בעתיד אם מפתח מסויים עוזב). גם אם כתיבת תיעוד ייכולה לעזור צריך להגיע למצב שהרווח מהכתיבה שלו (נניח בזמן שנחסך) שווה את ההשקעה ושהרווח גדול לא פחות אם הזמן היה מושקע בלפתח פיצר או לתקן באג מסויים.
בקשר לאנשים שמנפנפים אותך, מישהו צריך להיות מוגדר כמלווה או מנטור שלך ולקבל על זה קרדיט או הון פוליטי, אצלי היה מוגדר פעם בשבוע פגישה שאנחנו מדברים (היא הופיע בתור אחת שלוקחת שעה אבל לפעמים לקחה יותר), זה גם נותן לך מושג כמה עצמאית את ושאת לא מגיעה למצב שאת עלולה להיתפס כמי שצריך "להאכיל בכפית”.
יש טסטים אוטומטיים? גם טסטים ייכולים להיות סוג של תיעוד.
אתם ייכולים להשתמש בgitea (שזה משהו כמו github רק קוד פתוח) ולאכסן את התיעוד באיזה פורמט מבוסס טקסט כמו latex או markdown, ככה אנשים יוכלו להגיש בקשות לשינויי הקוד/תיעוד ויהיה אפשר לעבור עליהם כדי לראות אם הם טובות או לא (יהיו אנשים שיהססו לכתוב תיעוד כי הם לא בטוחים אם זה טוב כמו מתכנתים זוטרים או אפילו לקוחות), אפילו אם אנשים רק יוסיפו לדברים בשביל שימוש אישי כדי שיהיה להם רפרנס לעתיד זה עדיין ייכול להתפתח לא רע.
אני חושב שכן כדאי לקחת בחשבון שקוד הם גם סוג של תיעוד, ואתה ייכול גם ללמוד דברים מלנסות להבין את הקוד שלא הייתה מבין אם היו מסבירים לך (מה שייכול לעזור לעסק בעתיד אם מפתח מסויים עוזב). גם אם כתיבת תיעוד ייכולה לעזור צריך להגיע למצב שהרווח מהכתיבה שלו (נניח בזמן שנחסך) שווה את ההשקעה ושהרווח גדול לא פחות אם הזמן היה מושקע בלפתח פיצר או לתקן באג מסויים.
בקשר לאנשים שמנפנפים אותך, מישהו צריך להיות מוגדר כמלווה או מנטור שלך ולקבל על זה קרדיט או הון פוליטי, אצלי היה מוגדר פעם בשבוע פגישה שאנחנו מדברים (היא הופיע בתור אחת שלוקחת שעה אבל לפעמים לקחה יותר), זה גם נותן לך מושג כמה עצמאית את ושאת לא מגיעה למצב שאת עלולה להיתפס כמי שצריך "להאכיל בכפית”.
תודה על התגובה.
אנחנו לא עובדים ישירות מול הלקוחות, אז זה פחות רלוונטי התיעוד מולם.
תודה על הטיפים, לא הכרתי את gitea. האמת שאנחנו עובדים עם כמה פלטפורמות של תיעוד, אבל אף אחת מהן לא באמת ממריאה..
מה הכוונה מלווה/מנטור? מאיפה?
זה לא עובד ככה אצלנו, המתכנתים הבכירים לא ממש ששים לענות כששואלים אותם. ואין לנו דבר כזה "מלווה"
יש לנו יותר משהו כמו "עוף לי מהעיניים, אני עסוק"
הכוונה היתה לדבר עם מנהל כדי לנסות לייעל את תהליך הפיתוח (עשיתי את זה יותר מפעם אחת, זה לא בשמיים), תבואי עם הסברים טובים ותנסי לעשות את זה עם טקט ויש מצב שזה יעבוד.
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.