دسته: Agile

اندازه‌گیری پیچیدگی نرم‌افزار

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

تعداد مسیرها که آیسا می‌توانست برای رسیدن به هدفش را طی کند میزان پیچیدگی شرایط‌ش در نظر گرفتیم. در سال ۱۹۷۶ شخصی به Thomas McCabe متریکی را برای اندازه‌گیری پیچیدگی در نرم‌افزار به نام Cyclomatic complexity معرفی کرد. او نیز تعداد مسیرهای مستقلی که کل یک ماژول یا متد را پوشش بدهد به عنوان پیچیدگی آن در نظر گرفت. برای محاسبه تعداد مسیرهای مستقل در متد روشهای مختلفی وجود دارد، رسمی‌ترین روش برای این کار رسم گراف کنترل جریان آن متد می‌باشد. در تصویر زیر گراف کنترل جریان متد حستجوی باینری رسم شده است.

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

Cyclomatic complexity = E – N + 2

تعداد یالهای گراف = E

تعداد گره‌های گراف = N

بر اساس تصویر بالا گراف کنترل جریان متد دارای ۱۲ گره و ۱۴ یال می‌با‌شد پس :

CC = 14 – ۱۲ + ۲ = ۴

پس متد جستجوی باینری دارای پیچیدگی ۴ می‌باشد، یعنی ۴ مسیر مستقل وجود دارد که کل متد را پوشش می‌دهد.

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

if | while | for | for each | case | default | continue | goto | && | || | catch | ?: | ??

اگر حوصله رسم گراف و شمردن نقاط تصمیم‌گیری را ندارید، استفاده از ابزارهای که متریک‌های کد را محاسبه کرده و نمایش می‌دهند بهترین گزینه هست. یکی از بهترین گزینه‌ها برای اینکار می‌تواند XDepend باشد برای دات نت NDepend، برای جاوا JDepend و برای پی‌اچ‌پی می‌توانید از PDepend استفاده کنید.  البته اگر از ویژوال استودیو استفاد می‌کنید نیازی به نصب ابزار دیگری نیست می‌توانید از منوی ANALYAZ بر حسب نیاز خود یکی از دو گزینه مشخص شده در تصویر را انتخاب کنید و نتیجه را مشاهده کنید.

مقدار قابل قبول برای Cyclomatic Complexity یک متد چقدر هست؟

یک مقدار ایده‌ ال برای محدود کردن Cyclomatic Complexity در یک متد وجود ندارد. تا ۱۰ را یک مقدار قابل قبول برای یک متد میدانند. و با افزایش آن میزان پیچیدگی افزایش و در نتیجه آن تست پذیری و قابلیت نگهداری کاهش می‌یابد. بازه‌های زیر را SEI برای مقدار  Cyclomatic Complexity منتشر کرده است.

Cyclomatic Complexityسطح پیچدگیریسک
۱-۱۰سادهکم
۱۱-۲۰نسبتا پیچیدهمتوسط
۲۱-۵۰پیچیدهزیاد
بزرگتر از ۵۰غیرقابل تستخیلی زیاد

آیا ارتباطی بین مقدار Cyclomatic Complexity و تعداد تست‌های واحد (unit test)  وجود دارد؟

مقدار Cyclomatic Complexity برابر حداقل تعداد تست‌های هست که می‌توان نوشت تا تمام مسیر‌های برنامه را پوشش بدهد. یعنی اگر برای هر مسیری که مشخص شده هست یک تست بنویسیم می‌توانیم از پوشش تمام مسیرهای برنامه توسط تست‌هایمان مطمئن شویم. در پست بعدی سعی می‌کنم در مورد میزان پوشش تست‌ها (test coverage) بنویسم و درباره انواع پوشش تست‌ها توضیح خواهم داد.

به‌عنوان نمونه تست‌های نوشته شده برای مسیر ۱ و ۲ در متد جستجوی باینری در پایین نمایش داده شده است. سطرهای که با رنگ سبز مشخص شده است مسیر اجرای آن تست را نشان می‌دهد و سطرهای که با رنگ قرمز مشخص شده است سطرهای هست که آن مسیر پوشش نمی‌دهد.

مسیر ۱:  ۰->1->2->3->11

مسیر ۲: ۰->1->2->4->5->6->11

قوانین طراحی ساده

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

 یک از ارزش‌های XP، سادگی و یکی از تکنیک‌های آن طراحی ساده (Simple Design) هست. Kent Beck مبدع XP برای داشتن یک طراحی ساده چهار قانون تعریف کردن که عبارت‌اند از:

  1. پاس شدن همه تست‌ها
  2. عدم وجود تکرار
  3. بیان مقصود برنامه نویس
  4. کاهش تعداد کلاس‌ها و متدها

پاس شدن همه تست‌ها

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

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

عدم وجود تکرار

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

این اصل اغلب بین توسعه دهنده‌های نرم‌افزار با نام DRY(Don’t Repeat Yourself.) یا Once And Only Once شناخته می‌شود. البته اصل DRY درباره تکرار کد نیست و درباره تکرار دانش هست، این اصل بیان می‌کند که  هر قسمت از دانش ما در سیستم باید جایگاه واحد، بدون ابهام و معتبری داشته باشد. (حسین بقایی عزیز چند ماه قبل لینک یک پست را در مورد DRY توئیت کرده بود که به صورت عالی این اصل را تشریح کرده بود خواندنش را از دست ندهید.)

بیان مقصود برنامه‌‌نویس

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

کاهش تعداد کلاس‌ها و متدها

این یکی از اصولی هست که شاید در نگاه اول با اصول بالا در تضاد باشد. وقتی برای نمونه شما برای حذف کدهای تکراری کدهای موجود را ریفکتور می‌کنید به احتمال زیاد تعداد کلاس‌ها و متدها شما افزایش می‌یابد. پس اصل چهارم به خودی‌خود نقض می‌شود؛ اما این اصل به تعداد کلاس‌ها اشاره نمی‌کند و در واقع اشاره آن به اصل YAGNI (You Aren’t gonna need it) می‌باشد.  اصل YAGNI بیان می‌کند که شما باید هر چیزی را وقتی پیاده سازی کنید که واقعاً به آن نیاز دارید و نه وقتی که می‌فهمید در آینده ممکن است به آن نیازمند شوید. این جمله یکی از جملاتی است که XP واقعاً روی آن تاکید دارد و اعلام می‌کند که شما حتی اگر اطمینان حاصل کنید که به این ویژگی در آینده نیاز خواهید داشت آنرا الان پیاده سازی نکنید. پس هدف اصل چهارم این است که نباید با پیاده‌سازی کلاس‌ها و متدهایی که احتمالاً در آینده فرضی به آن نیاز خواهیم داشت نعداد کلاس‌ها و متدها را افزایش بدهیم.

سپرده‌گذاری در بانک مساعدت

«بانک مساعدت دیگر چیست؟»

«خودت می‌دانی. هر آدم زنده‌ای این بانک را می‌شناسند.»

«ممکن است، اما هنوز منظورت را نمی‌فهم.»

«این موضوع در کتابی از یک نویسنده آمریکایی آمده. قدرتمندترین بانک دنیاست. همه‌جا شعبه دارد.»

«کشور من سابقه ادبی ندارد. نمی‌توانم به کسی کمک و لطفی بکنم.»

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

«و یک روز ….»

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

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

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

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

رویاهای ما برای جامعه حرفه‌ای ما

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

او گفت: “ولی چقدر بد است که مردم عادی اجازه ندارند آنجا بنشینند.”

من گفتم: “آهان، فهمیدم بابا. با توجه به اینکه من در بخش تخیلی دیسنی کار کرده‌ام، می‌دانم که برای جلو نشستن باید به دوز و کلک متوسل شد. می‌خواهی ببینی چطور؟”

او گفت: “البته.”

بنابراین به سوی متصدی خندان دیسنی رفتم و گفتم: “عذر می‌خوام، امکان دارد که ما سه نفری جلو بنشینیم؟”

متصدی گفت: “البته آقا.” او در را باز کرد و ما سه نفر کنار دست راننده نشستیم. این اولین مرتبه بود که پدرم از کار من کاملا هاج و واج مانده بود.

وقتی به سرعت به سوی قلمرو سحرآمیز می‌رفتیم، گفتم: “بهت گفتم که باید کلک زد. اما نگفتم که کلک سختی است.”

گاهی تنها کار لازم تقاضا کردن است، که باعث می‌شود تمام رویاهای آدم به حقیقت بپیوندند.

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

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

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

آرزوهای ابوالفضل فتاحی برای تبریز به عنوان یک دوست خوب برای همه تبریزیها

رویای و آرزوی امیر حبیب‌زاد برای شهرمان تبریز

رویای امین ضیاء پرانرژی برای جامعه حرفه‌ای تبریز

آرزوی زهره ضیاء برای کل جامعه تبریز

رویاهای کوچک ولی بزرگ سعید چوبانی  برای جامعه حرفه‌ای ما

آرزوهای بهنام خجسته برای شهرمان

محمد فلاحت و آرزوی ایستگاه خلاقیت برای تبریز

علی اسدی آرزوها و حرفهای خوبش برای جامعه ما

فرزام خجسته‌نیا و آرزویش در مورد کل جامعه ما

ندا ضیاء و آرزوهایش برای جامعه حرفه‌ای و کل شهرمان

شهرام اشراف‌نیا آرزیلاری

امید زمانی و آرزوی رفع یک مشکل شهرمان

وحید کشی‌پور و کمی حرف حساب

ابراهیم جباری و آرزوهایش برای شهر آرزوها

فرید دهقان و یک عالمه حرف‌ها و آرزوهای خوب برای شهرمان

مژگان و آرزوش برای تبریزمان و خودش

 نسرین و آرزوهایش برای ساختن یک دنیا بهتر

گاهی «نمی‌دانم» جواب سوال هست.

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

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

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

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

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

بیاید به همدیگر قول بدهیم قبل از اینکه به هر سوالی پاسخ بدهیم یک کمی فکر کنیم، شاید «نمی‌دانم» جواب اصلی سوال باشد.

قانون بوی اسکات

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

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

تئوری پنجره شکسته

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

به‌صورت اتفاقی در جای مطلبی را می‌خواندم که در آن اشاره به تئوری پنجره شکسته داشت. تئوری پنجره شکسته محصول فکری دو جرم شناس آمریکائی (Criminologist) بود به اسامی جمس ویلسون (James Wilson) و جورج کلینگ(George Kelling).  این دو استدلال می کردند که جرم نتیجه یک نابسامانی است. اگر پنجره ای شکسته باشد و مرمت نشود آنکس که تمایل به شکستن قانون و هنجارهای اجتماعی را دارد با مشاهده بی تفاوتی جامعه به این امر دست به شکستن شیشه دیگری می زند. دیری نمی پاید که شیشه های بیشتری شکسته می شود و این احساس آنارشی و هرج و مرج از خیابان به خیابان و از محله ای به محله دیگر می رود و با خود سیگنالی را به همراه دارد از این قرار که هر کاری را که بخواهید مجازید انجام دهید بدون آنکه کسی مزاحم شما شود.

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

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

لطفن توجیه نکن

چند ساعت بالای کوه دارد بحث را مدیریت می‎‌کند که به نتیجه دلخواه خودش برسد و آن اتفاقی که در زندگیش افتاده را توجیه کند. می‌خواهد به نقطه‌ای برسیم که هم خودش و هم ما قبول کنیم که آن اتفاق قسمتش بود و او نمی‌توانسته نقشی در نتیجه آن اتفاق داشته باشد. می‌خواهد چشم‌هایش را بر حقیقت ببندد و فقط با جمله “قسمت‌م این بود” به آرامشی هر چند کوتاه‌مدت، دست بیابد.
امیر شاید به اندازه آن دوست پارگراف بالا قفسه‌های پر کتاب جامعه‌شناسی، روانشناسی، فلسفه و … نداشته باشد. اما امیر در صفحه فیس‎‌بوک خود نوشته «میدونستید اگه ایرانیها میخواستن کولر رو اختراع کنن هیچ وقت اختراع نمیشد! چون هی‌هی مثل خیلی از ماها میگفتن خدا حتمن یه چیزی میدونه که تابستونو گرم کرده اگه خودش بخواد سردش میکنه. خدا میدونه چی واسه ما خوبه :|میدونید از چی متنفرم؟ از اینکه بگن این حکمت خدا بوده که اینطوری شده یا این قسمت نبوده که اینطوری شده. » از نظر من امیر این جامعه، مردمش و تفکرش را می‌شناسد و نمی‌خواهد بخاطر آرامش چشمانش را بر حقیقت ببندد.
من از توجیه کردن، کتمان حقیقت و هر چیزی که کم‌کارهای خودمان را پنهان کند نفرت دارم. اما حقیقت‌گریزی و پنهانکاری در ذات اغلب آدم‌های این جامعه هست. این حرف من نیست، فقط کافی هست که چشم‌هایم را ببندم و صفحات چند کتاب را به یاد بیاورم. جامعه‌شناسی خودمانی نوشته حسن نراقی مثل همیشه گزینه اول هست که در ذهنم خودنمایی می‌کند.
«در مجموع ما ایرانی‌ها علاقه چندانی به روبرو شدن با حقایقی که به هر دلیلی مطابق میل و سلیقه‌مان نباشد نداریم.
از بیماری صعب‌العلاجی که خدای ناکرده گریبان خود و یا عزیزی از اطرافیانمان را گرفته تا معظلات و مشکلات اجتماع ترجیح می‌دهیم در بهترین حالت با سکوت به آسانی از کنار آن بگذریم و به این منظور در حادترین شرایط حاکم با «انشاءا…» . به امید خدا و در اوج بی‌علاجی «هر چی خداوند مقدر کرده باشند»، صورت مسئله را پاک می کنیم. غافل از این‌که به استناد ده‌ها توصیه مسلم انجام این گونه امور را خداوند به عهده خود ما قرار داده و قرار هم نیست اگر کوشش در رفع معضل نکنیم خود بخود حل شود.»
اما این درد، یک درد کهنه هست و مانند یک میراث خانوادگی از نسلی به نسل دیگر منتقل می‌شود. قبل از حسن نراقی، فریدون آدمیت در کتاب اندیشه‌های میرزا آقاخان کرمانی همین جملات را تکرار می کند. «از اینرو در دماغ ایرانیان عقیده غریبی رخنه یافته که همه چیز را به بخت و طالع نسبت می‌دهند، و زحمت و کوشش را در تحصیل ثروت و آبرو شرط نمی‌دانند. این اعتقاد درهای علم و معرفت را چنان به‌روی اهالی این مملکت بست که پیدایش اشیاء را بی‌سبب دانسته‌اند و «عقب پژوهش علل اشیاء که ریشه درخت علم است برنیامده‌اند». رفته‌رفته این مرض شوم کار مردم این مرز و بوم را به جایی کشانیده که هر تقصیر در تدبیر را حواله به تقدیر می‌کنند و هر خرابی را محول به مشیت پروردگار می‌نمایید.»
اما این مشکل فقط مربوط به جامعه ما نیست و تقریبا تمام کشورهای خاورمیانه را در برمی‌گیرد. استفین پی. رابینر در کتاب مبانی رفتار سازمانی بیان می کند «در کشورهای خاورمیانه، مردم از این دیدگاه به زندگی نگاه می‌کنند که از قبل تعیین شده است. هنگامی که رویدادی رخ می‌دهد آنها آن را خواست خدا می‌دانند. در جامعه‌ای که خود را تابع محیط می‌داند، تعیین هدف اهمیت چندان زیادی ندارد. اگر قرار باشد انسان بر این باور باشد که نمی‌تواند در امر رسیدن به هدف کار چندان زیادی انجام دهد، دیگر تعیین هدف چه فایده‌ای دارد.»
سالها هست که این کتابها هست، سالها هست که هزاران نفر این کتابها را می‌خوانند، سالها هست کسانیکه این کتابها را نه خواندن و نه نوشتن این درد را می‌بینند. اما دیدن، نوشتن و خواندن داروی این درد نیست چون اگر دارویش بود تا بحال باید ریشه این بیماری از بین رفته بود. داروی این درد فقط پذیرفتن حقیقت هست با تمام دردهای نهانش، داروی این درد اینست که ما میراث‌دار خوبی نباشیم و کوری را بخاطر آرامش تحمل نکنیم.

فریم ورک تعاملات – قسمت دوم

چرا DISC مهم هست؟

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

درک و پذ‌یرش د‌یگران

افرادیکه با مدل DISC آشنایی دارند، می توانند با درک و پذیرش رفتار دیگران به صورت موثرتری در تیم‌ها فعالیت کنند.

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

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

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

تعامل با افراد با زبان خودشان

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

تصور کنید که شما قرار است به یکی از مدیران ارشد شرکت خود یک گزارش درباره هزینه های یک پروژه که قرار است انجام شود بدهید. اگر شما قرار باشد گزارش را به یک مدیر با D بالا ارائه کنید به چه صورت گزارش خود را تنظیم و ارائه خواهید کرد؟ در صورتیکه مدیر با  Cبالا باشد چگونه اینکار را انجام خواهید داد؟

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

اگر شما باید گزارش را به یک مدیر با C بالا ارائه بدهید، باید کاملاً به صورت برعکس عمل کنید. یعنی اول باید اطلاعات و جزئیات مربوط به هر هزینه را بیاورید و سپس مبلغ آن هزینه را.

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

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

زبان DISC

دلیل آخر برای اهیمت DISC این است که افراد می توانند از “زبان DISC” به عنوان یک اهرم استفاده کنند.

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

در یکی از جلسات طوفان مغزی که به‌صورت دوره‌ای در این شرکت برگزار می شود. مدیرعامل به صورت پیوسته در حال سخنرانی است و فرصت صحبت را به فرد دیگری نمی‌دهد. مدیرعامل فرد بسیاری باهوشی است و ائده‌های خوب زیادی برای ارائه کردن دارد. اما هیچ کدام از اعضاء فرصت صحبت پیدا نمی کنند. اگر شما در آن جلسه بودید چگونه فرصت صحبت را برای خودتان یا دیگران مهیاء می کردید؟ در آن جلسه یکی از حاضران در فرصت مناسب فقط این جمله را بیان می کنه: “آقای مدیرعامل، مثل اینکه D شما امروز در سطح خیلی بالای هست.” با شنیدن این جمله مدیرعامل شروع به خندیدن می کند و فرصت صحبت را به دیگران نیز می‌دهد. بدون “زبان DISC”  به‌آسانی ممکن نبودکه از مدیرعامل خواست که سخنان خود را قطع کند (خفه شود) تا دیگران نیز به اظهار عقیده بپردازند. زمانیکه از “زبان DISC ” استفاده می‌کنید، مردم اغلب لبخند می‌زنند و نکته جمله را می‌گیرند.

استراتژهای برای تعامل

جدول زیر به طور خلاصه استراتژیهای را برای تعامل افراد با دیگران با توجه به مدل رفتاری آنها ارائه می‌دهد.

رفتار

استراتژیهای برای تعامل

D

سر اصل مطلب بروید، با آنها از نتایج صحبت کنید، جایگزینهای را ارائه بدهید، اطلاعات را به صورت خلاصه وار به آنها ارائه بدهید.

I

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

S

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

C

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

 پایان

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

فریم ورک تعاملات – قسمت اول

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

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

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

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

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

فریم ورک تعاملات

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

بیانیه چابک بیان می کند: “افراد و تعاملات مهمتر از فر آیندها و ابزارها هستند.” و در یکی از اصول بیانیه چابک بیان شده است: “کارآمدترین و موثرترین روش انتقال اطلاعات به تیم توسعه و تبادل آن در میان اعضای تیم، گفتگوی چهره به چهره است.” بنابراین اگر اجایل  یک توافق بزرگ برای افزایش کارایی تعاملات و روشی که تیم باهم کار می کنند هست، پس چرا افرادیکه یک پروژه چابک را شروع می کنند از یک فریم ورک تعاملات که تعاملات و کار تیمی را بهبود می بخشد استفاده نمی کنند؟ در این نوشته سعی خواهیم کرد که با یکی از ارزشمندترین فریم ورک های تعاملات به نام DISC آشنا شویم. (در بسیاری از منابع مدیریتی فریم ورک تعاملات را با عنوان مدل رفتاری، پروفایل شخصیتی و … معرفی می کنند. ولی در اکثر منابع و دوره های مربوط به اجایل از اصطلاح فریم ورک تعاملات استفاده شده است).

تاریخچه DISC

فریم ورکی که من اکثر موارد برای تیم های مختلف توصیه می کنم  DISC نام دارد. احتمال دارد شما نیز با DISC  آشنایی داشته باشید. اما DISC  بسیار قدیمی تر از متدهای چابک و تفکر ناب هست و ریشه های آن به 400 سال قبل از میلاد مسیح برمی گردد، زمانیکه بقراط رفتارهای انسان را مورد بررسی قرار داد و آنها را به چهار گروه تقسیم کرد.

در 1928 ويليام مولتون مارستن کتابی با عنوان “The Emotions of Normal People” منتشر کرد، که در آن تئوری DISC را تشریح کرد. در طول این سالها، شرکتهای متعددی تاییدیه های آماری و بهبود مستمر را بر روی DISC ارائه کرده‌اند.

تعریف DISC

شما می توانید DISC را به عنوان اثر انگشت رفتاری هر فرد در نظر بگیرید. رفتار هر فرد ترکیبی از چهار عنصر است، اما ترکیب این چهار عنصر در هیچ دو فردی دقیقا مشابه یکدیگر نیست. ترکیب این چهار عنصر است که مشخص می کند هر فرد چگونه رفتار می کند. درک DISC بسیار ساده است، اگر یک فرد بخواهد که بر همه افراد و محیط خود تسلط داشته باشد، این فرد یک D است. هر یک از حروف در عنوان DISC  بیانگر یکی از این چهار عنصر است. هر کدام از این حروف به چه معنای هستند؟

The D—Dominator

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

Dهای مشهور: جورج بوش، مارگارت تاچر، پوتین، مایکل جردن و رابرت دنیرو.

The I—Influencer

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

Iهای مشهور: بیل کلینتون، آندره آغاسی، استیو مارتین

The S—Supporter

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

Sهای مشهور: مادر تزار، مارتین لوتر کینگ، جان اف کندی

The C—Critical Thinker

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

Cهای مشهور: بیل گیتس، آلبرت انشتین، آلن گرین اسپن