مهارت‌های نرمِ کار تیمی، استفاده از ابزار‌های تخصصی ارتباطی و فهم و به‌کار‌گیری قواعد حاکم در تیم‌های توسعه‌ی موفق، لازمۀ رشد در فضای رقابتی برنامه‌نویسی است. ایگور باگاینکو در مورد تفاوت عملکرد شخص فاقد و دارای این توانایی‌ها می‌نویسد.
معرفی نویسنده
آقای Yegor Bugayenko، برنامه‌نویس، مدیر ارشد فنی، بنیان‌گذار، سرمایه‌گذار و یک فعال امور بشر‌دوستانه است. ایگور نویسندۀ چندین کتاب در زمینۀ طراحی شی‌گرا و مهندسی نرم‌افزار است و سخنرانی‌های او در کنفرانس‌های جاوا مورد استقبال قرار می‌گیرد. نوشته‌های او را می‌توانید در وبلاگ شخصی‌اش دنبال کنید.
توسعۀ نرم‌افزار و کد‌نویسی دو چیز متفاوت‌اند. معمولا اولی شامل دومی هم می‌شود، اما نه همیشه، کد‌نویس سطر‌هایی از کد تولید می‌کند در حالی که توسعه‌دهندۀ نرم‌افزار محصول تولید می‌کند. متاسفانه عمدۀ کسانی که به شرکت ما می‌پیوندند تنها یک کد‌نویس‌اند. آن‌ها اگرچه ادعا دارند توسعه‌دهنده‌اند اما در واقع فاقد مهارت‌های اجتماعی-تکنیکی هستند که تولیدکنندگان محصول را از تولیدکنندگان خطوط کد متمایز می‌کند.
اجازه دهید ابتدا علائم این ضعف را به شما نشان دهم.
نام شخص را ماریو می‌گذاریم. بر اساس رزومه‌اش یک برنامه‌نویس ماهر جاواست. بیشتر از ده سال در صنعت بوده و چندین پروژۀ کلان انجام داده است. به ظاهر فرد مجربی است، در نتیجه به او اجازه می‌دهیم به گیت‌هاب پروژه دسترسی داشته باشد و چند تیکت تعیین کند.
در عرض چند ساعت یک پیام حدودا یک صفحه‌ای در فیس‌بوک دریافت می‌کنم. در پیام می‌گوید بسیار خوشحال است که روی پروژه کار می‌کند، اما چیزی را متوجه نمی‌شود و به کمک نیاز دارد. در ادامه لیستی از سوالات را می‌پرسد و در نهایت می‌گوید آمادۀ تماس تلفنی است تا جواب‌ها را دریافت کند.
در جواب می‌نویسم:
«عزیزم، من شما را مثل برادرم دوست دارم، اما وقت جواب دادن به سوال‌های شما را ندارم. نه به این دلیل که برای کار شما ارزش قائل نیستم… در واقع، بلی، دقیقا به همین دلیل. من تنبلم و دلم نمی‌خواهد به سوالات شما در یک پیام‌رسان جواب دهم. چرا که اگر فردا شما از پروژه خارج شوید یا یک هفتۀ دیگر یک نفر به تیم اضافه شود و دقیقا سوال شما را داشته باشد، در این صورت جواب من کاملا به هدر رفته است. باید دوباره برای او هم توضیح دهم؟ من برای این کار خیلی پیر یا تنبلم.»
مطمئنا او با خودش فکر خواهد کرد که من یک مرد مزخرف و متکبر ام، ولی چه کار می‌توانم بکنم؟ او این مقالۀ مرا می‌خواند و با خودش می‌گوید: «خب! راهش را پیدا کردم»
در عرض نیم ساعت ماریو چند تیکت به یک repository دیگر(!) می‌فرستد. تیکت با عنوانِ «مشکل» و متنِ «کمک کنید پروژه را بفهمم» ارسال شده است.
به عنوان معمار پروژه چه کار می‌توانم بکنم؟ تیکت او را با یک پیغام سریع می‌بندم: «لطفا، تیکت‌های کلی باز نکنید.» جوابم تنها یک ذره با «برو گم شو!» متفاوت است. اما واقعا چه می‌توانم بگویم؟ ماریو از روش کار با تیکت‌ها هیچ چیز نمی‌داند. او احتمالا تا الان در یک دفتر کوچک و دنج کار می‌کرده و همۀ اعضای تیم دور هم و دوست بوده‌اند. در نتیجه حتی به چت هم نیاز نداشتند و پشت یک میز می‌نشستند و اگر سوالی داشتند از هم می‌پرسیدند. من کاری را از او می‌خواهم که هیچ وقت انجام نداده، طبیعی هم هست که بلد نباشد، احتمالا به خاطر این مسئله احساس شرمندگی هم می‌کند.
بعد چه اتفاقی می‌افتد؟ احتمالا با یک سری سوال مشابه دیگر سراغ مسنجر می‌رود، عکس العمل او به شخصیتش وابسته خواهد بود. می‌تواند عصبانی شود، احساس کند گیج شده است یا … . ولی اصل قضیه این است که او یک توسعه‌دهنده نیست بلکه تنها یک کد‌نویس است. او سیستم حاکم بر پروژه‌های مدرن را درک نمی‌کند، روش تعامل‌های جدید در آن‌ها را نمی‌فهمد، بلد نیست از ابزار‌های ارتباطی اختصاصی این کار استفاده کند و فاقد مهارت‌های اجتماعی-تکنیکی این حوزه است:
- چگونه به دنبال اطلاعات بگردد و آن‌ها را پیدا کند
- چگونه سوال بپرسد و جواب‌ها را جمع آوری کند
- اطلاعات مفید به repository اضافه کند
- در مکاتبات بحث کند و تغییرات را مرور و بررسی کند
- تیکت‌ها را ببندد و بتواند از بسته شدن آن‌ها جلوگیری کند
- نظم و نظام حاکم بر repository را رعایت کند
متاسفانه تقریبا هر کسی به تیم ما اضافه می‌شود، این ضعف‌ها در او دیده می‌شود.
یک پروژۀ نرم‌افزاری مدرن بیشتر از آن که کد‌نویسی باشد یک فعالیت اجتماعی است. دانستن روش درست تعامل با تیم و سر و کار داشتن با اطلاعات، بسیار مهم‌تر از دانستن الگو‌های طراحی است. تنها راهِ یاد گرفتن این مهارت‌ها تمرین است. چندین بار گفته ام، اجازه دهید دوباره تکرار کنم: اگر یک فعال جامعۀ متن‌باز یا شخصی با حسن شهرت خوب در StackOverflow نیستید، به احتمال زیاد این مهارت‌ها را ندارید.
پی نوشت: چند روز پس از انتشار مقاله فوق، بیست و یکمین شماره از سری پادکست‌های Shift-M به همین موضوع اختصاص داده شد. برای بررسی بیشتر می‌توانید به لینک پادکست در سایت SoundCloud مراجعه کنید.
