لطفا جاواسکریپت مرورگر خود را فعال سازید!

نحوه فعال سازی در کروم
  1. ابتدا باید اینکارو بگنید
  2. بعدش اونکارو
نحوه فعال سازی در فایرفاکس
  1. ابتدا باید اینکارو بگنید
  2. بعدش اونکارو
چطور یک سرپرست فنی خوب، موفق و تاثیرگذار باشیم؟

چطور یک سرپرست فنی خوب، موفق و تاثیرگذار باشیم؟

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

به‌طورکلی آنچه در این مقاله قصد داریم مورد بررسی قرار دهیم، ویژگی‌هایی است که به دولوپرهایی که در این سمت فعالیت می کنند کمک می‌کند تا خوب‌تر، موفق‌تر و تأثیرگذارتر ظاهر شوند.

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

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

مسائل فنی را به عهدهٔ دیگران بگذارید 
اگر شما سرپرست فنی هستید، باید حداکثر تلاشتان را بکنید تا مشکلی که به‌وجود آمده است را حل کنید؛ شما مجبورید راه‌حل‌های مختلف را برای حل یک مسئله امتحان کنید. البته نه هر راه‌حلی! راه‌حلی که پیدا می‌کنید باید ساده باشد. بنابراین وظیفهٔ شما درحال‌حاضر دیگر مربوط به رفع مشکلات مختلف است و موفقیت در کار جدیدتان هم به همین مسئله بستگی دارد.

ولی به این نکته هم باید توجه داشته باشید که در موقعیت جدید، سر شما به‌ اندازهٔ کافی شلوغ خواهد شد؛ یعنی تقریباً کدنویسی را دیگر باید کنار بگذارید. درگیر شدن با کدنویسی، رفع مسائل فنی دیگر از حیطهٔ وظایف شما خارج است.

شما باید کدنویسی را به دیگران بسپارید؛ به‌عبارت دیگر، از این پس که شما سرپرست فنی شده‌اید، نوبت بقیهٔ دولوپرها است که مهارت‌هایشان را بروز بدهند و مشکلات را حل کنند. اگر شما وظیفهٔ خودتان را به‌خوبی انجام ندهید، افراد زیردست شما هم نخواهند توانست وظایف خود را به‌درستی انجام دهند و همه‌چیز آشفته می‌شود و آن‌وقت هم احتمالاً افراد مستعد تیم به‌هم ریخته و شما را ترک خواهند کرد و احتمالاً شما هم در کارتان شکست می‌خورید!

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

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

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

کدنویسی را ترک نکنید! 
موقعیتی که شما دارید اسمش سرپرست فنی است و کلمهٔ «فنی» بدون دلیل در کنار «سرپرست» نیامده است! درواقع شما به‌عنوان یک سرپرست فنی باید همیشه کدنویسی را تمرین کنید تا با گذشت زمان این مهارت ارزشمند را از یاد نبرید (مثل زبان انگلیسی که می‌گویند «فرار» است، بدون اغراق می‌توان گفت که کدنویسی هم فرار است و درصورتی‌که تمرین نشود، به‌سادگی آن‌را از یاد خواهیم برد.)

وقتی شما هرازگاهی کدنویسی کنید هم دانش برنامه‌نویسی‌تان را به‌روز نگا داشته‌اید، با محدودیت‌ها، فرایندها و مشکلات کدنویسی جدید آشنا می‌شوید و هم این که ارتباط قوی‌تری با برنامه‌نویسان و تیم خود ایجاد خواهید کرد.

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

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

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

اگر نکته اول، یعنی سپردن وظایف و مسئولیت مسائل فنی به دیگران را رعایت کنید، احتمالاً کمی سرتان خلوت‌تر می‌شود و وقت بیشتری خواهید داشت؛ سرپرستان فنی موفق معمولاً تاریخ‌ها و زمان‌هایی را در برنامهٔ زمانی خود برای کدنویسی مشخص می‌کنند. با این کار، آن‌ها مطمئن می‌شوند که حتماً در طول هفته به کدنویسی و بازبینی کدها به همراه تیم توسعه می‌رسند.

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

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

همیشه در مورد معماری نرم افزار، اختلاف نظرهایی وجود خواهد داشت؛ نمودارها به دولوپرها کمک می‌کنند که موقعیت خودشان را متوجه شوند و بتوانند کار خود را باتوجه به معماری کل سیستم متناسب کنند.

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

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

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

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

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

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

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

سرپرست فنی باید راهی پیدا کند که بدون استفاده از اصطلاحات فنی و پیچیده، مسائل و مفاهیم مورد نظرش را منتقل کند؛ بهترین کار این است که اصطلاحات رایج در کسب‌وکار که در آن حوزه مورد استفاده قرار می‌گیرد را پیدا کنید و شما هم از همان‌ها استفاده کنید.

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

به‌علاوه می‌توانید در ارتباط با تیم توسعهٔ خودتان هم از برخی اصطلاحاتی عمومی‌تر استفاده کنید تا مجبور نباشید با ۲ زبان مختلف با افراد ارتباط برقرار کنید؛ هرچه تیم توسعه درک بهتری از نیازهای مشتری و بخش‌های دیگر داشته باشد، عملکرد بهتری هم در برطرف کردن نیاز مشتری از خود نشان خواهند داد.

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

حال نوبت به نظرات شما می‌رسد؛ آیا مدیر فنی تیمی که در آن مشغول به کار هستید از خصوصیات فوق برخوردار است؟ آیا به کارگیری خصوصیات فوق می‌تواند به بهتر شدن خروجی تیم‌های توسعهٔ نرم‌افزار کمکی کند؟ نظرات خود را با ما و سایر اعضای سکان آکادمی به اشتراک بگذارید.

منبع