خصوصیات افرادی که مناسب کار تیمی نیستند

نویسنده : سید ایوب کوکبی ۱۸ خرداد ۱۳۹۸
خصوصیات افرادی که مناسب کار تیمی نیستند

در دنیای برنامه‌نویسی، پیشرفت انفرادی تا حدی ممکن است. زمانی پیشرفت واقعی حاصل می‌شود که از لاک تنهایی بیرون بیایید و در قالب یک تیم فعالیت کنید. اغلب محصولات نرم‌افزاری ثمرۀ کار تیمی و تلاش شبانه‌روزی صدها نفر/ساعت کار است. استعدادهای فردی در دلِ تیم‌های بزرگ شکوفا می‌شوند. یک توسعه‌دهنده هرقدر هم باهوش باشد نمی‌تواند به تنهایی سیستم‌عاملی را طراحی کند. ساخت بسیاری از محصولات نرم‌افزاری نیازمند زمان، تخصص و انرژی فراوانی است که از عهدۀ یک شخص خارج است.

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

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

تکبر و خودپسندی

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

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

بخوانید  افکار و نگرش‌هایِ یک برنامه‌نویسِ خوب

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

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

کدنویسی شلخته

شلختگی کدها علائمی دارد مثل:

  • نامگذاری عجیب متغیرها، متدها و کلاس‌ها؛
  • عدم پاکسازی کامنت‌های قدیمی و کدهای بدون استفاده؛
  • نداشتن دقت کافی در انتخاب انواع داده‌ای؛
  • ریفکتور نکردن و عدم زیباسازی کد؛
  • رها کردن اخطارهای IDE به حال خود؛
  • کپی و پیست کدها از اینترنت بدون درک درست؛
  • داکیومنت نکردن کد؛
  • هندل نکردن خطاها؛
  • استفادۀ بی‌جهت از کتابخانه‌ها و ایجاد وابستگی‌های غیرضروری؛
  • پیروی کردن از best practiceها بدون درک درست آن‌ها (هیچ best practiceای وجود ندارد که در همۀ تیم‌ها کاربرد داشته باشد).

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

ارزش قائل نشدن برای زمان بقیه

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

بخوانید  چند توصیۀ برنامه‌نویسی به تازه‌واردان

مواردی که برای زمان دیگران ارزش قائل نیستیم:

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

منفی‌بافی

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

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

البته سوء برداشت نشود. انتقاد در برخی از موارد سازنده و به‌جاست. مثلاً یک توسعه‌دهندۀ اسکالا ممکن است به یک توسعه‌دهنده جاوا از برتری Promiseها بگوید ولی از آن طرف باید CompletableFuture‌های جاوا را هم تست کند تا مزۀ Monad در زبان جاوا را هم بچشد. منظور این است که انتقاد و بحث زمانی خوبی است که یک‌طرفه و کورکورانه نباشد. متأسفانه چنین بحث‌های دوستانه‌ای این روزها کمتر وجود دارد.

حرص و زیاده‌خواهی

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

بخوانید  اشتباهاتی که به عنوان یک برنامه‌نویسِ مبتدی مرتکب شدم

اهمیت ندادن به تیم

مهندسی نرم‌افزار همکاری تیمی افراد مختلفی اعم از توسعه‌دهنده، طراح، مدیر محصول و … است. به همین خاطر احترام به کار همۀ آن‌ها ضروری است. به عنوان مثال:

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

تمرکز نداشتن

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

مسئولیت‌پذیر نبودن

همانطور که بالاتر گفتیم تمرکزِ بر کار از هر چیزی مهم‌تر است. اعضای تیم منتظر هستند که شما هم به عنوان عضوی از تیم ایفای نقش کنید. اینکه فقط بگویید چه کارها می‌کنید کافی نیست. باید در عمل مسئولیت‌پذیری خود را نشان دهید. مسئولیت‌پذیری لازمۀ کار تیمی است. افرادی بی‌مسئولیت معمولا با بهانه‌هایی مثل پیچیدگی مسئله یا کمبود زمان می‌خواهند از زیر بار مسئولیت شانه خالی کنند. عذرخواهی و بهانه‌جویی هیچ کمکی به پیشبرد اهداف پروژه نمی‌کند.

سید ایوب کوکبی

نویسنده و مترجم...

مطالب مرتبط

0 دیدگاه

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *