logo
מאות פודקאסטים, בלוגים ווידאו
מצאו את התוכן שהכי מתאים לכם
Early stage (244) Growth Stage (127) Pre-seed/seed (259) Scale/IPO (24) AI (33) Ideation (16) אימפקט (1) גיוס כספים (118) arrow דאטה (50) הנפקה (14) הצלחת לקוחות (CS) (23) arrow השראה (128) חרבות ברזל (12) יזמות (265) arrow יסודות (91) מוצר (123) arrow מכירות (39) משאבי אנוש (136) arrow משפטי (28) ניהול (34) עיצוב (27) arrow פיננסים (28) arrow פיתוח (44) שותפויות עסקיות (19) arrow שיווק (106) arrow תפעול (11)
247: מבוטסטראפ לאקזיט, הסיפור של Evers
27:03

פודקאסט

פודקאסט

עודד וליןותומר שי ...

247: מבוטסטראפ לאקזיט, הסיפור של Evers

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

Early stage
יזמות
Enter Card האזנה לפרק

בלוג

בלוג

6 דק'

ויטלי מרגולין

איך לבנות צוות חזק ועצמאי 

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

 

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

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

 

בחירת Proxy KPI's
אחרי שהגדרתי מטרה שעוזרת לי לתעדף בין הדברים ומכוונת את הצוות, צריך שיהיה ברור איך הדברים שהצוות עושה ביום יום יעזרו להם להשיג אותה ע״י הגדרת יעדים. הבעיה עם יעדים שהם ברמת החברה היא שהם נוטים להיות מאוד ׳בגבוה׳, כמו למשל הכנסות. אם אני בצוות ופיתחתי פיצ׳ר, אין לי דרך לדעת אם זה השפיע על ההכנסות בצורה ישירה, ולכן זה יעד שיהיה לא פשוט לעבוד איתו. כדי לחבר בין משימות ל impact צריך לייצר מטריקות פרוקסי שיש לצוות איך להשפיע עליהם ישירות, ואימפקט עקיף על ה-KPI המרכזי של החברה. מי שעושה את זה מאוד טוב אלו Hubspot, ואפשר לקרוא עוד על הדרך בה הם מגדירים יעדים בבלוג שלהם.

 

גיוס האנשים הנכונים

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

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

 

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

 

הפכו את עצמכם למיותרים

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

תיאום ציפיות וסטנדרטים

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

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

 

Recognition

הצלחתם ? תעצרו לחגוג !

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

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

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

 

בניית אמון

אם אתם שומעים משפטים כאלה ״ברור שהצוות השני לא סיים את המשימה שהבטיחו לנו לרבעון הזה, הם לא מסוגלים לעשות כלום״ - יש בעיית trust. כי אם היה אמון הייתם שומעים ״ברור שהם לא סיימו, אתה יודע כמה דברים סופר קריטיים נפלו עליהם תוך כדי הרבעון?״. קפיצה למסקנות אחד על השני זה סימן קלאסי לזה שיש בעיית אמון.
את הדוג׳ הזאת שמעתי שנה שעברה מאחד הצוותים אצלי וזה הקפיץ לי נורה. אבל אם בא לכם לקרוא על עוד נורות כאלה תקראו את The Five Dysfunctions of a Team.

אולי דוג׳ אחרונה לפני שנסיים - להחביא חולשות וטעויות.

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

 

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

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

 

Early stage
Pre-seed/seed
ניהול
Enter Card לקריאת הבלוג
איך לנהל את הראנווי ולהתכונן לסבב הבא
67.13

וידאו

וידאו

67 דק'

03/2024

איך לנהל את הראנווי ולהתכונן לסבב הבא
Early stage
גיוס כספים
Enter Card צפייה בוידאו
פרודקטיבי: איך יודעים שמוצר מספיק טוב כדי לצאת לשוק
27:32

פודקאסט

פודקאסט

עומר גרצמן

פרודקטיבי: איך יודעים שמוצר מספיק טוב כדי לצאת לשוק

אנחנו מדברים על השאלה מתי אנחנו יכולים לקבוע שאפשר לשחרר פיצ׳ר חדש ללקוחות

מוצר
Enter Card האזנה לפרק
246: איך להבין תוך יומיים אם קמפיין מרקטינג מביא לקוחות משלמים
22:41

פודקאסט

פודקאסט

אלונה קסל

246: איך להבין תוך יומיים אם קמפיין מרקטינג מביא לקוחות משלמים

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

שיווק
Enter Card האזנה לפרק

בלוג

בלוג

7 דק'

שחר פולק

איך לשמור על גמישות, מהירות ותפוקה של סטארטאפ גם כשגדלים

Velocity - קצב התקדמות לכיוון מסויים של הצוות בפיתוח של דרישות חדשות.

Throughput - כמות העבודה שהצוות מספק בפרק זמן נתון.

 

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

 

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

 

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

 

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

 

בהירות (Clarity)

 

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

 

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

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

 

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

 

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

 

יכולות (Capabilities)

 

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

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

 

המוביל הטכני ממלא שני תפקידים מרכזיים:

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

     

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

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

 

הסטה שמאלה (Shift Left)    

 

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

 

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

 

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

 

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

 

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

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

 

מניעת הסחות דעת ויצירת פוקוס בפרויקט (Context Switching)

 

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

 

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

 

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

 

תרבות אחריות אישית (Accountability)

 

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

 

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

 

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

 

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

 

עצמאות וגמישות לצוותים (Team Autonomy & Flexibility)

 

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

 

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

 

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

 

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

 

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

 

לסיכום

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

  1. יצירת בהירות מוחלטת לגבי מטרות הפרויקט, דרכי הפעולה והגדרת עדיפויות. ככל שיש פחות אי-בהירויות, כך הצוותים יכולים להתמקד בביצוע יעיל יותר.
  2. וידוא שלצוותים יש את כל הכלים, המשאבים והיכולות הנדרשים לביצוע הפרויקט ביעילות, כולל מוביל טכני מנוסה.
  3. אימוץ גישת "הסטה שמאלה" שמשלבת פעילויות כמו בדיקות, QA ואבטחה כבר בשלבים המוקדמים של הפיתוח כדי לזהות ולפתור בעיות מוקדם ככל האפשר.
  4. מזעור שינויי קונטקסט והפרעות לצוותים כדי לאפשר ריכוז וזרימת עבודה רציפה.
  5. טיפוח תרבות של אחריות אישית, מסירות ומחויבות לתוצאות בקרב חברי הצוותים.
  6. מתן עצמאות וגמישות לצוותים לקבל החלטות באופן עצמאי בתוך מסגרת העבודה שהוגדרה.

 

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

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

Early stage
Growth Stage
פיתוח
Enter Card לקריאת הבלוג
מרעיון להקמת סטארטאפ
39:20

וידאו

וידאו

39 דק'

03/2024

מרעיון להקמת סטארטאפ
Ideation
Enter Card צפייה בוידאו
איך לעשות ולידציה לבעיה ולא לרעיון
47:26

וידאו

וידאו

47 דק'

03/2024

איך לעשות ולידציה לבעיה ולא לרעיון
Ideation
Pre-seed/seed
יזמות
+1
Enter Card צפייה בוידאו

בלוג

בלוג

6 דק'

רעות בר קנא

כיצד לשמור על יעילות בעיצוב עבור המחלקות השונות

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

 

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

 

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

 

אז איך ניגשים לזה?  

 

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

 

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

 

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

 

 

 

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

עיצוב
Enter Card לקריאת הבלוג
iconתשאלו אותנו הכל