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