درود دوستان 👋 هنگام توی دنیای مهندسی نرم‌افزار یکی از مهمترین مهارت‌هایی که پا به پای مهارت‌های فنی (Hard Skills) می‌بایست بهش توجه کنیم، مهارت‌های نرم و به قول معروف Soft Skills هست.

در واقع یک مهندس نرم‌افزار خوب کسی هست که بتونه تعادلی بین این دو دسته از مهارت‌ها ایجاد کنه. معمولاً افرادی که جذب شغل‌های آی‌تی میشن افرادی هستن که به شکل فعالانه و خودجوش تمایلی به برقراری ارتباطات اجتماعی ندارن. اما پارادوکس این شغل اینه که برای موفق شدن توی اون، نیاز به تقویت انبوهی از مهارت‌های اجتماعی و ارتباطی داریم. مهارت‌هایی مثل برقراری ارتباط موثر، حل و فصل کشمکش‌های کاری، نحوهٔ مصاحبه دادن و هزاران مهارت‌های کوچیک و بزرگی که مجبوریم به اونها توجه داشته باشیم.

طبق تجربه شخصی، یکی از مهمترین این مهارت‌ها «نحوهٔ برقراری ارتباط با افراد غیر فنی و توضیح دادن مسائل فنی به اونهاست.» توی هر شرکتی با هر تعداد کارمند که مشغول به فعالیت باشیم، افرادی هستن می‌بایست با اونها ارتباط برقرار کنیم و درباره مسائل فنی به اونها توضیح بدیم. برای مثال مدیر محصول، تیم پشتیبانی و یا طراح. بدون شک اگه با افراد غیر فنی بخوایم مسائل رو از دیدگاه و ادبیات خودمون توضیح بدیم و مثلاً به نیروهای پشتیبانی که مشکلی رو گزارش دادن بگیم:

این دکمه کار نمی‌کنه به این دلیل که هندلر onClick هنوز به درستی درخواست‌های API رو مدیریت نمی‌کنه. تیم بکند ساختار API رو تغییر داده و من مجبور شدم از روش توابع Async و Debounce برای حل این قضیه استفاده کنم تا Race condition به وجود نیاد. همچنین منتظر حل‌شدن قضیه CORS توی Staging هم هستم.

قطعاً مشکل رو نه تنها حل نمی‌کنه، بلکه باعث کند شدن روند انجام وظایف و گمراهی اشخاص میشه و همچنین تأثیرگذاری و ارزشمند بودن ما رو هم کاهش میده. به جای جمله‌های بالا می‌تونیم بگیم:

این دکمه به این دلیل کار نمی‌کنه که ما هنوز داریم تلاش می‌کنیم که اون رو به بخش مربوطه توی بکند که تازه بروز شده متصل کنیم. توی بکند تغییراتی صورت گرفته که می‌بایست اون تغییرات رو توی UI هم اعمال کنیم. و برای همین منتظر آپدیت از تیم بکند هستم. به محض اینکه انجام بشه، اون رو اعمال می‌کنم و بهتون خبر میدم.

جملهٔ بالا مقداری ملموس‌تر و قابل فهم‌تر برای افراد غیر فنی هست. توی این پست می‌خوایم مهارت‌هایی رو بررسی کنیم که کمک می‌کنن بتونیم بهتر و موثر تر با افراد غیر فنی صحبت کنیم.

این پست از سری پست‌های «من مهندس نرم‌افزار هستم» هست که توی اونها نکات فنی و غیر فنی که ما رو به یک مهندس نرم‌افزار خوب تبدیل می‌کنه رو بررسی می‌کنیم.

 

قدم اول، شناخت مخاطب

مهمترین کاری که توی ارائه یک موضوع باید انجام بدیم اینه که اول ببینیم مخاطب ما کی هست، چقدر سواد فنی و چه پیشینه‌ای داره. مطمئناً توضیح دادن یک باگ به یک همکار فنی خیلی باید متفاوت باشه از توضیح دادن اون به مدیر اجرایی، کاربر و یا سهام‌دار شرکت.

برای مثال ما به عنوان یک توسعه‌دهندهٔ نرم‌افزار یک نکته برای بهبود برنامه به ذهنمون رسیده و می‌خوایم اون رو برای مدیر تعریف کنیم تا موافقتش رو جلب کنیم. ما باید خودمون رو به جای مدیر بذاریم و تا جایی که می‌تونیم اطلاعات رو از دیدگاه و پیشینهٔ اون شخص ارائه بدیم. برای مثال باید فکر کنیم که چه چیزی برای یک مدیر اهمیت داره و دنبال چه چیزی هست؟ احتمالاً کاهش هزینه‌ها و افزایش رضایت و تعداد مشتری‌ها.

برای مثال می‌تونیم بگیم:

می‌خوام باهاتون درباره یک قابلیت جدید صحبت کنم که اکثر شرکت‌ها در حال پیاده‌سازی اون هستن که باعث کاهش هزینه‌های توسعه و افزایش رضایت و جذب کاربرا میشه. به تازگی یک نرم‌افزار پشتیبانی کاربران معرفی شده که با استفاده از هوش مصنوعی می‌تونه خیلی سریع‌تر و با دقت بیشتری به سوالات مخاطب پاسخ بده. و همچنین هزینهٔ استفاده از اون خیلی پایین‌تر از روش‌هایی هست که ما در حال استفاده از اونها هستیم. طبق آمار این نرم‌افزار می‌تونه تا ۱۰ برابر توی رضایت مخاطب نقش مثبت داشته باشه و همچنین ۴۰٪ از هزینه‌های ما رو کاهش میده. اگه مایل باشید می‌تونیم خیلی سریع از قابلیت آزمایشی این نرم‌افزار برای جامعهٔ محدودی از کاربرانمون استفاده کنیم و ببینیم چقدر این نرم‌افزار می‌تونه کمک‌کننده باشه.

وقتی برای شناخت مخاطب وقت می‌ذاریم، می‌تونیم تأثیرگذاری بیشتری داشته باشیم. در غیر این صورت فقط هدر رفت وقت و انرژی ما و شخص مقابل هست.

 

قدم دوم،‌ همدلی کردن با مخاطب

وقتی با مخاطب غیر فنی (مثلاً شخصی از تیم پشتیبانی) با کلمات فنی و اصطلاحات تخصصی صحبت می‌کنیم، این نه تنها هوش اجتماعی پایین ما رو نشون میده، بلکه باعث مضطرب شدن شخص مقابل میشه (چون در صورت متوجه نشدن حرف‌های ما، حس عدم اعتماد به نفس بهش تلقین میشه) و اشتیاقش برای ارتباطات بعدی کاهش پیدا می‌کنه.

ما می‌بایست خودمون رو جای اون شخص بذاریم و ببینیم که چه چیزهایی می‌دونه و به دنبال چه چیزی هست. وقتی از ما پرسیده میشه «چرا این دکمه کار نمی‌کنه؟» قطعاً به دنبال دلیل فنی این اتفاق نیستن. بلکه احتمالاً جوابی می‌خوان بشه اون رو به کاربر یا مشتری ارائه داد.

برعکسِ این اتفاق هم صدق می‌کنه. اگه توی قسمت‌های پشتیبانی فعالیت می‌کنیم و می‌‌خوایم خطاها و گزارش‌هایی رو به تیم فنی اعلام کنیم، می‌بایست اطلاعات کافی مثل نحوه بروز دادن خطا (Steps to reproduce) رو ترجیحاً به شکل تصویری (اسکرین‌شات، ویدئو) و کاربری که دچار این خطا شده رو به شکل واضح بیان کنیم.

 

قدم سوم،‌ تعادل توی حجم اطلاعاتی که ارائه می‌دیم

توی قدم‌های قبلی بیشتر تمرکزمون روی کیفیت موضوع بود. یعنی اینکه برای شناخت مخاطب وقت بذاریم و مسائل رو از دیدگاه اونها نگاه کنیم. اما هنگام ارائه دادن موضوعی به همکارانمون (چه فنی و چه غیر فنی) علاوه بر کیفیت اطلاعات می‌بایست به کمّیت اطلاعاتی که ارائه می‌دیم هم توجه کنیم.

فرض کنیم می‌خوایم یک تیکت پشتیبانی ثبت کنیم. اگه محتویات تیکت ما خیلی طولانی و حوصله‌سر بر باشه، و یا بیش از حد خلاصه و فاقد اطلاعات ضروری باشه، احتمالاً اون تیکت نادیده گرفته میشه و در نتیجه تأثیر منفی روی اعتبار ما میذاره.

این نکته طلایی توی همه جنبه‌های کاری ما مثل ساختن رزومه، کاور لتر و هنگام مصاحبه‌ها کاربرد داره. یکی از علت‌های مهم که باعث رجکت شدن رزومه‌ها و مصاحبه‌ها میشه اینه که زیاد حد صحبت می‌کنیم یا اطلاعات غیر ضروری ارائه می‌دیم (یا بلعکس). پس «تعادل» نکتهٔ کلیدی توی هر جنبه‌ای از کار و زندگی ماست.

 

قدم چهارم، ارائه دادن اطلاعات با فرمت‌های مختلف

طبق تجربهٔ شخصی، توی محل کار و هنگامی که می‌خوام موضوعی (مثلاً گزارش یک خطا) رو برای شخصی (چه فنی و چه غیر فنی) توضیح بدم، تا جایی که ممکنه سعی می‌کنم اون رو با اسکرین‌شات یا ساختن ویدئو از نحوهٔ بروز خطا ارائه بدم. این کار یک نوع احترام به وقت شخص مقابل هست، و کمک می‌کنه شخص زودتر و راحت‌تر متوجه موضوع بشه و همچنین وقتی می‌بینه که ما برای ارائه اطلاعات وقت صرف کردیم، احتمالاً زودتر جواب خواهیم گرفت.

 

قدم پنجم، ارائه با سرعت مناسب

این نکته هم یک جورایی زیر مجموعه قدم دوم، یعنی همدلی کردن با مخاطب هست. خیلی اوقات مخاطب ما نیاز به زمان داره تا صحبت‌هایی که کردیم رو درک و پردازش کنه. قبل از ارائه، این فقط ما هستیم که از موضوع با خبر هستیم و از اون شناخت داریم. وقتی خیلی سریع صحبت می‌کنیم و موضوعات رو ارائه می‌دیم و زمانی رو به مخاطب نمی‌دیم تا اطلاعات رو پردازش کنه، باعث میشه که مخاطب از درک نادرستی از موضوع بدست بیاره و یا اظهار بی‌میلی کنه.

 

 

خب دوستان به آخر این پست رسیدیم. همونطور که قبلاً اشاره کردم، ایجاد تعادل بین مهارت‌های فنی و مهارت‌های نرم یکی از مهمترین پایه‌های موفقیت توی هر زمینهٔ شغلی هست. توی دنیای امروزی، یک توسعه‌دهندهٔ خوب کسی هست که علاوه‌بر داشتن مهارت‌های حل مسائل فنی، بتونه مسائل بین فردی و ارتباطی رو به بهترین شکل حل کنه. امیدوارم از این پست استفاده کرده باشید. روزتون خوش 👋😉

https://medium.com/@tpagram/a-guide-to-improving-your-technical-communication-162a2563c795

https://medium.com/learning-data/5-tips-for-explaining-tech-concepts-to-non-technical-people-8b47ab0e79dc

https://www.lucidchart.com/blog/how-to-explain-technical-ideas-to-a-non-technical-audience