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

برنامه نویسی

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Tips for Being an Effective Tech Lead

0


برچسب ها: برنامه نویسی      مشاهده کلیه ترفندهای: عباس رهامی      در تاریخ: 1395/08/10



از طریق این فرم، می توانید بدون ثبت نام نظر دهید و یا اگر قبلا ثبت نام کرده اید، با ورود ناحیه ی کاربری می توانید علاوه بر ثبت نظر، به مدیریت نظرات خود نیز بپردازید.
(فیلد اجباری)
(فیلد اجباری)
(فیلد اجباری)
(فیلد اجباری)

سایر ترفندهای مرتبط