خبرنامه
در سایت ثبت نام رایگان نمایید، و مشترك خبرنامه‌ی ما گردید. در این صورت اخبار، رویدادها و خبرهای ویژه‌ی سايت را از طریق e-mail دریافت خواهید نمود.



خبرنامه‌های بایگانی‌شده


سبد خرید

سبد خرید شما خالی است.

سابقه‌ی سفارشات گذشته

تماس با ما


مجموعه مقالات یادگیری و تفکر پراگماتیک از طریق مهندسی مجدد کارکردهای ذهن (بخش 2)
امتیاز : 1 كاربر به این نوشته امتیاز داده‌اند. امتیاز متوسط5.0
نوشته شده توسط : admin, در روز چهارشنبه 23/02/1394, در گروه " تفکر پراگماتیک "
بازدید : این نوشته تاكنون 14184 بار مشاهده شده است.
چكیده : نوشته‌ی اندی هانت - ترجمه‌ی:کبریا صبوری
با انتخاب و خواندن این مجموعه مقالات شما راهیِ سفری عجیب از میان علوم و تئوری‌های وابسته به کارکردهای ذهن و مغز و شناخت چگونگی تاثیر‌گذاری خود بر بهبود مهارت‌های تفکر و یادگیری، می‌شوید. اگر به عنوان یک برنامه‌نویس، مدیر و یا دانشمند دوست دارید با استفاده از روش طراحی مجدد عملکرد مغز خود به کارایی بیشتر در محیط کار خود برسید؛ و یا حتی اگر به این موضوع علاقه‌مندید، این مجموعه کمک بسیاری به شما خواهد کرد.

یادگیری و تفکر پراگماتیک از طریق مهندسی مجدد کارکردهای ذهن (بخش دوم)

فصل دوم- سفری برای مبتدی‌ها تا حرفه‌ای شدن

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

«آلبرت انیشتن»

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

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

آن دو، مدل کسب مهارت دریفوس[1] را پیشنهاد دادند که 5 مرحله‌ی کاملا مجزا را برای طی در مسیری منتهی به حرفه‌ای شدن بیان می‌کند که در ادامه به آن می پردازیم. در ابتدای دهه 1980، حرفه‌ی پرستاری در کشور آمریکا درس‌های بسیاری از مدل دریفوس برای اصلاح رویکرد و بهبود حرفه‌ی پرستاری، به‌کار بست. بسیاری از مشکلاتی که آن زمان پرستارها با آن مواجه بودند آیینه‌ای از مشکلاتی بود که هم اکنون مهندس‌ها و برنامه‌نویس‌ها با آن‌ها مواجه‌اند. حرفه‌ی پرستارها پیشرفت‌های خیره‌کننده‌ای کسب کرده است و در این بین، ما هنوز کارهایی برای انجام در این مسیر داریم.

نظریه‌های رویدادی در مقابل نظریه‌های ساخت (Event Theories vs. Construct Theories)


مدل تریفوس از" نظریه‌ها‌ی ساخت" محسوب می‌شود. در این زمینه 2 نوع نظریه وجود دارد: نظریه‌های رویدادی و نظریه‌های ساخت. (نگاه کنید به : Tools of Critical Thinking: Metathoughts for Psychology [Lev97]، هر دوی این نظریه‌ها برای توضیح مشاهدات به‌کار می‌روند. نظریه‌های رویدادی قابل اندازه‌گیری و قابل اثبات هستند و شما می‌توانید راجع به صحت آن‌ها قضاوت کنید. نظریه‌های ساختی مفاهیم انتزاعی ناملموسی هستند که اثبات آن‌ها مفهمومی ندارد و با کارایی‌شان سنجیده می‌شوند و شما نمی‌توانید قضاوتی در زمینه‌ی صحت یا نادرستی آن‌ها داشته باشید. آن‌ها مخلوطی از سیب‌ها و وجود گرایی (Existentialism) هستند؛ سیب یک وجود عینی و قابل مشاهده است اما وجود گرایی ، یک مفهوم انتزاعی است. برای مثال اثبات همه‌چیز در مورد مغز شما، با یک جریان برق ساده و وسایل تصویربرداری پزشکی قابل اثبات است اما ذهن قابل اثبات نیست چون یک مفهوم انتزاعی است و واقعا چنین چیزی وجود عینی ندارد و تنها یک مفهوم و تصوری کلی است که وجود آن بسیار مفید و قابل استفاده است. همان‌طور که بیان شد، مدل دریفوس از جنس نظریه‌های ساختی است و چنان‌که خواهیم دید، مدل بسیار سودمندی است.

در این قسمت به مشاهداتی می‌پردازیم که به‌نظر می‌آید در هر دو گروه پرستاران و برنامه‌نویس‌ها و یا شاید سایر حرفه‌ها صدق کند:

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

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

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

نظریه‌های رویدادی در مقابل نظریه‌های ساخت (Event Theories vs. Construct Theories)


مدل تریفوس از" نظریه‌ها‌ی ساخت" محسوب می‌شود. در این زمینه 2 نوع نظریه وجود دارد: نظریه‌های رویدادی و نظریه‌های ساخت. (نگاه کنید به : Tools of Critical Thinking: Metathoughts for Psychology [Lev97]، هر دوی این نظریه‌ها برای توضیح مشاهدات به‌کار می‌روند. نظریه‌های رویدادی قابل اندازه‌گیری و قابل اثبات هستند و شما می‌توانید راجع به صحت آن‌ها قضاوت کنید. نظریه‌های ساختی مفاهیم انتزاعی ناملموسی هستند که اثبات آن‌ها مفهمومی ندارد و با کارایی‌شان سنجیده می‌شوند و شما نمی‌توانید قضاوتی در زمینه‌ی صحت یا نادرستی آن‌ها داشته باشید. آن‌ها مخلوطی از سیب‌ها و وجود گرایی (Existentialism) هستند؛ سیب یک وجود عینی و قابل مشاهده است اما وجود گرایی ، یک مفهوم انتزاعی است. برای مثال اثبات همه‌چیز در مورد مغز شما، با یک جریان برق ساده و وسایل تصویربرداری پزشکی قابل اثبات است اما ذهن قابل اثبات نیست چون یک مفهوم انتزاعی است و واقعا چنین چیزی وجود عینی ندارد و تنها یک مفهوم و تصوری کلی است که وجود آن بسیار مفید و قابل استفاده است. همان‌طور که بیان شد، مدل دریفوس از جنس نظریه‌های ساختی است و چنان‌که خواهیم دید، مدل بسیار سودمندی است.

در این قسمت به مشاهداتی می‌پردازیم که به‌نظر می‌آید در هر دو گروه پرستاران و برنامه‌نویس‌ها و یا شاید سایر حرفه‌ها صدق کند:

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

همه‌ی کارکنان حرفه‌ای تمایلی به‌مدیر شدن در انتهای نردبان ترقی شغلی ندارند.

واریانس بسیار زیادی در توانایی‌های کارکنان وجود دارد.

واریانس بسیار زیادی در توانایی‌های مدیران وجود دارد.

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

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

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

unix

تصویر 2-1: یک جادوگر یونیکس (Unix)

2.1. مبتدی‌ها در برابر حرفه‌ای‌ها

شما به یک توسعه‌دهنده‌ی حرفه‌ای نرم‌افزار چه می‌گویید؟ یک جادوگر! ما با اعداد جادویی، چیزهایی شبیه طلسم و جادو، فرایندهایی نامرئی و زامبی‌گونه و افسون‌هایی رازآلود مانند “sudo gem install –include- dependencies rails” و “tar –xzf plugh.tgz”[2] سر و کار داریم.

ما هم‌چنین می‌توانیم مشخصات شناسایی خود را به مشخصات شخص دیگری و یا به root user[3] تبدیل کنیم، کسی که نماد قدرت در دنیای یونیکس است. جادوگر‌ها این کار را به آسانی انجام می‌دهند: یک چشم سوسمار آبی، کمی غبار روی بال خفاش، کمی سحر و جادو و پوف! کار تمام است.

جدای از این تشبیه‌های افسانه‌ای، شاید این تصویر برای افراد حرفه‌ای در هر زمینه‌ای خیلی هم دور از نظر نباشد (به‌خصوص برای ما برنامه‌نویس‌ها که به اندازه‌ی کافی کارمان محرمانه و رازآمیز می‌نماید). برای مثال سرآشپزی را غرق در غباری از طعم‌ها و ادویه‌ها و بوهای متفاوت تصور کنید که همچنان‌که غذا را آماده می‌کند، دستیارش ظرف‌های کثیفی که او روی هم می‌چیند را می‌شوید و ممکن است تنها دغدغه‌ی سرآشپز این باشد که نحوه‌ی پخت غذا را چگونه شمرده به شما بگوید: "خب! کمی از این، یک قاشق غذاخوری از آن- نه بیشتر- و اجازه دهید تا پخته شود!" سرآشپز مطمئنا خنگ نیست و معنی "اجازه دهید تا پخته شود" را می‌داند. او تفاوت ضمنی بین "کافی" و "بسیار زیاد" را بسته به رطوبت گوشت، جایی که گوشت را خریده و تازگی سبزیجات می‌داند.

کار را به‌نظر ساده کنید.


زمانی من در مسئولیت انجام مصاحبه با نوازندگان ارگ جهت انتخاب یکی از آن‌ها برای استخدام بودم. برای تست مصاحبه‌شوندگان، من قطعه‌ی Taccata ساخته‌ی Charles-Minor Widor (از سمفونی شماره 5 در F Minor, Op. 42 No.1) را انتخاب کرده بودم که قطعه‌ای بسیار تند و آشفته است و برای گوش‌های آماتوری مانند من، بسیار سخت می‌نماید.

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

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

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

توضیح و سخنوری در مورد مهارت‌ها بسیار سخت است.

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

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

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

2.2. مراحل پنج‌گانه مدل دریفوس

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

مدل دریفوس به ازای هر مهارت به‌طور مستقل، قابل اجرا است.

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

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

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

مرحله‌ی اول: مبتدی‌ها (Novices)

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

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

مبتدی‌ها نیاز به دستورالعمل دارند.

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

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

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

  • مبلغ درآمد خود در سال گذشته را وارد کنید.
  • آن را به دولت بفرستید.

بسیار ساده و شفاف!

تصویر 2.2: طرز پخت کیک شکلاتی. اما شما برای پخت ان چه‌قدر وقت می‌گذارید؟

یک شرکت بزرگ سخت‌افزار کامپیوتر ممکن است از سناریویی همانند مثال زیر استفاده کند:

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

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

مشکلی که با دستورالعمل‌ها وجود دارد (به‌خصوص آن‌هایی که بدون در نظرگرفتن زمینه تدوین شده‌اند) این است که شما هرگز نمی‌توانید همه چیز را به‌طور کامل مشخص کنید. برای نمونه، زمان پخت در دستور پخت مافین ذرت، 20 دقیقه در نظر گرفته شده است. در چه وضعیتی باید آن را بیشتر و یا کمتر بپزم؟ چطور باید بدانم چه زمانی فرایند پخت مافین کامل شده است؟ شما می‌توانید قواعد بیشتری را برای توضیح آن‌ها و باز هم دستورالعمل‌های بیشتری را برای توضیح قواعد قبلی آماده کنید اما یک محدودیت عملی در سطح مشخص کردن قواعد بیشتر برای توضیح بیشتر وجود دارد، بدون این‌که دچار شیوه‌ی آقای بیل کلینتون شوید: "بستگی به این دارد که معنی کلمه‌ی است، چه چیزی است." این پدیده به اسم پَسرَوی نامحدود[5] شناخته می‌شود. در برخی قسمت‌ها، شما مجبورید از تعریف و توضیح بیشتر جهت شفاف‌سازی دست بردارید.

مرحله‌ی دوم: نوآموزهای پیشرفته (Advanced Beginners)

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

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

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

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

مرحله‌ی سوم: کاردان (Competent)

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

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

در این مرحله افراد معمولا به کاردانی و داشتن ابتکار عمل شناخته می‌شوند. آن‌ها متمایل به داشتن نقش‌های رهبری در گروه هستند (چه این نقش به‌طور رسمی در گروه وجود داشته باشد یا نه).[6] وجود این افراد در گروه شما، بسیار حائز اهمیت است؛ آن‌ها قادر به رهبری و آموزش مبتدی‌‌ها‌ هستند، بدون آن‌که حرفه‌ای‌ها را خیلی اذیت کنند.

حتی در حیطه‌ی تخصصی ما (توسعه‌ی نرم‌افزار) هم کاردان‌ها نمی‌توانند از شیوه‌های Agile به نحو مطلوبی استفاده کنند و هنوز توانایی کافی برای عکس‌العمل دقیق و تصحیح کردن اعمال خود به تنهایی را نداشته و به عبارت دقیق‌تر خودبسنده نیستند. به‌همین دلیل ما به عبور از این مرحله به‌سوی مرحله‌ی بعد احتیاج داریم: کارشناس

مرحله‌ی چهارم: کارشناس (Proficient)

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

کارشناس‌ها خودبسنده هستند.

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

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

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

به‌طور مثال، پند مشهوری در Extreme Programming وجود دارد با مضمون "هر آن‌چه ممکن است باعث خطا شود را امتحان کنید".

نکته‌های پراگماتیکی


هنگامی که من و ِدیو توماس کتاب The Pragmatic Programmer را می‌نوشتیم، سعی داشتیم که تعدادی از توصیه‌هایی را که فکر می‌کردیم بسیار به حرفه‌ی ما مربوط می‌شد را انتقال دهیم.

این نکته‌ها (این پندها) بازتابی از برآیند سال‌ها تجربه‌ی ما بود: از تمرین گسترش ذهن با یادگیری یک زبان برنامه‌نویسی جدید در هر سال تا اصولی که پس از سال‌ها تجربه به‌دست آمده‌اند مانند”Don’t Repeat Yourself (DRY)” و یا “No Broken Windows”. این پندها کلید عبور به حرفه‌ای شدن هستند.

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

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

به همین ترتیب الگوهای نرم‌افزار (مطرح شده در کتاب Design Patterns: Elements of Reusable Object-Oriented Software [GHJV95] که هم‌چنین به عنوان Gang of Four book نیز شناخته می‌شود.) به‌طور موثری توسط افراد کارشناس به‌کار گرفته می‌شوند (اما نه لزوما در سطوح پایین‌تر مهارت؛ به مطلبی که در باکس زیر آورده شده است توجه کنید).

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

لگوهای نادرست و روش‌های غیرقابل اطمینان


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

توسعه Agile مبتنی بر بازخورد است؛ در حقیقت تعریف من از توسعه Agile بر اساس کتاب Practices of an Agile Developer; Working in the Real World [SH06] است: "توسعه Agile از بازخوردها برای ساختن قضاوتی پایدار در محیطی با تشریک مساعی بالا استفاده می کند." اما تنها در مراحل پیشرفته‌ی مهارت، خود بسنده بودن بر مبنای عملکرد گذشته امکان پذیر است.

نوآموزهای پیشرفته و کاردان‌ها غالبا الگوهای طراحی نرم‌افزار را با دستورالعمل‌ها اشتباه می‌گیرند که در برخی موارد منجر به اشتباهات فاجعه‌باری نیز می‌شود. به‌طور مثال با توسعه‌دهنده‌ای برخورد کردم که به‌تازگی با کتاب Gang of Four(GoF) آشنا شده بود و اشتیاق فراوانی در استفاده از همه‌ی الگوهای طراحی در یک زمان بر روی یک بخش کوچک از کد تولید گزارش داشت. او قبل از این‌که کسی متوجه شود، موفق به جمع‌ کردن 17 الگو از مجموع 23 الگوی GoF در این کد ناموفق شد.

مرحله‌ی پنجم: حرفه‌ای (Expert)

و بالاخره در مرحله‌ی پنجم به انتهای این مسیر می‌رسیم: حرفه‌ای.

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

بر طبق آمار تعداد حرفه‌ای‌ها زیاد نیست، شاید رقمی نزدیک به 1 تا 5 درصد از جمعیت .[8] این افراد بر اساس شهود کار می‌کنند نه دلیل. این موضوع بسیار جالب است و باعث طرح سوالات بسیاری می‌شود، اما به‌هر حال شهود چیست؟ (در سراسر کار این موضوع را بسط خواهیم داد).

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

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

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

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

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

بدون مهارت و ناآگاه


وقتی شما در حوزه‌ای، مهارت اندکی دارید، بیشتر دچار توهم حرفه‌ای بودن می‌شوید. در مقاله‌ی “Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments [KD99]” ، دو روانشناس به‌نام‌های Kruger و Dunning ، موردی را با این مضمون مطرح می‌کنند که دزدی در روشنایی روز به یک بانک دستبرد زده و زمانی که دستگیر می‌شود، ناباورانه اظهار می‌کند که گمان می‌برده اگر صورت خود را به آب لیمو آغشته کند، از دید دوربین‌های امنیتی پنهان می‌ماند!

"مرد آب لیمویی" هرگز به نظریه‌ی خود شک نکرده بود. این فقدان خود ارزیابی صحیح، یک جور بی-کفایتی (Second-order Incompetence) محسوب می‌شود که ناشی از بی‌مهارتی و ناآگاهی است.

وضعیت مذکور، یک مشکل بزرگ در توسعه‌ی نرم‌افزار محسوب می‌شود، زیرا بسیاری از مدیران و توسعه‌دهندگان نرم‌افزار حتی از وجود شیوه‌ها و تکنیک‌های بهتر نیز ناآگاهند. من برنامه‌نویس‌های جوان زیادی دیده‌ام (با 1 تا 5 سال سابقه) که تا‌به‌حال در هیچ پروژه‌ی موفقی حضور نداشته‌اند. آن‌ها تسلیم این فکر اشتباه شده‌اند که یک پروژه‌ی معمولی باید به‌سختی پیش برود و در نهایت نیز شکست بخورد. چارلز داروین این نکته را به‌خوبی بیان کرده است: "ناآگاهی بسیار بیشتر از دانش، باعث به‌وجود آمدن اعتماد به-نفس می‌شود". این گفته به‌نظر بسیار درست می‌آید؛ زمانی که شما تبدیل به یک حرفه‌ای می‌شوید تازه متوجه می‌شوید که در گذشته به‌طرز دردناکی از دانش کمی برخوردار بوده‌اید.

در حقیقت نابود کردن یک حرفه‌ای و تخریب عملکرد او بسیار آسان است؛ تمام کاری که باید انجام دهید این است: از آن‌ها بخواهید که از دستورالعمل‌ها پیروی کنند!

دستورالعمل‌ها، حرفه‌ای‌ها را نابود می‌کنند.

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

اما زمانی که از خلبان‌ها خواسته شد که از دستورالعمل‌های خودشان استفاده کنند، عملکرد آن‌ها به‌طور قابل توجهی کاهش پیدا کرد .[9]

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

شهود برای تمامی افراد حرفه‌ای در هر زمینه‌ای یک ابزار بسیار قدرتمند محسوب می‌شود، اما سازمان‌ها آن را بی‌اهمیت می‌دانند چون به اشتباه احساس می‌کنند که "شهود، علمی یا قابل تکرار نیست". بنابراین ما تمایل داریم به خواسته‌ی حرفه‌ای‌ها –کسانی که حقوق زیادی نیز به آن‌ها می-پردازیم- توجهی نکنیم.

note

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

فشارها در این صنعت بر علیه ما در هر دو جهت، هم‌دست شده‌اند. درک غلطی که از اصلاحات سیاسی وجود دارد ما را وادار می‌کند که بدون در نظر گرفتن توانایی‌های توسعه‌دهندگان، با تمامی آن‌ها برخوردی یکسان داشته باشیم و نسبت به هر دو گروه مبتدی‌ها و حرفه‌ای‌ها ظالمانه رفتار کنیم (و این حقیقت که در همه‌جا بهره‌وری توسعه‌دهندگان نرم‌افزار از نسبت 20 به 1 تا 40 به 1 متغیر است را نادیده بگیریم) . [10]

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

Work to Rule


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

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

بر طبق گفته‌ی Benner (در کتابFrom Novice to Expert: Excellence and Power in Clinical Nursing Practice [Ben01]): "تکنیک‌ها هیچ‌گاه به‌صورت کامل فرموله نمی‌شوند زیرا همواره به‌صورت جدیدی در آن واحد و در روابط خاص و متفاوت، ظاهر می‌شوند."

تفاوت مبتدی‌‌ها و حرفه‌ای‌ها‌ تنها محدود به شهود و دستورالعمل نمی‌شود. خصوصیات زیادی هستند که در این مسیر تغییر خواهند کرد، اما مهم‌ترین تغییرات در این راه عبارتند از:[11]

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

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

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

شما ممکن است تصور کنید که عمده‌ی جمعیت، در میانه‌ی مدل دریفوس هستند و این مدل از توزیع استاندارد پیروی می‌کند. اما این‌طور نیست. متاسفانه تحقیقات نشان می‌دهد که اکثر مردم در بیشتر مهارت‌ها در سراسر عمرشان، هرگز وارد مراحل بالاتر از مرحله‌ی دوم (نوآموزان پیشرفته) نمی-شوند، "وظایفی که نیاز دارند را اجرا کرده و همگام با به‌وجود آمدن خواسته‌های جدید، چیزهای جدیدی نیز می‌آموزند اما هرگز به یادگیری مفهومی و گسترده‌تر از فضای یک وظیفه، نائل نمی‌شوند.[12]” توزیع مناسب‌تری در تصویر 2.4، آمده است.

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

هم‌چنین توانایی انجام آگاهانه‌ی وظایف [13] و یا به‌عبارتی خودآگاه بودن در مراحل بالای مهارت اتفاق می‌افتد. متاسفانه افراد در مراحل پایین مهارت تمایل بسیار زیادی به اغراق در توانایی‌هایشان دارند (رقمی نزدیک به 150 درصد). بر طبق مطالعه‌ی “Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments [KD99]”، تنها را ه خود ارزیابی صحیح‌تر، بهبود سطح مهارت شخصی است که منجر به افزایش توانایی انجام وظایف به‌صورت آگاهانه می‌شود.

این موضوع که شما حجم ندانسته‌های خود را ندانید، ممکن است نوعی بی‌کفایتی (Second-order Incompetence) به‌شمار آید. مبتدی‌ها علی‌رغم غیرعادی بودن روند کار، اعتماد به‌نفس خوبی دارند اما حرفه‌ای‌ها در زمان مشکوک شدن روند کار، احتیاط بیشتری می‌کنند؛ حرفه‌ای‌ها شک بیشتری نسبت به کار خود نشان می‌دهند.

از آن‌چه نمی‌دانید، آگاه شوید.

حرفه‌ای! = معلم


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

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

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

ده سال تا حرفه‌ای شدن؟


خب! آیا شما می‌خواهید یک حرفه‌ای شوید؟ شما صرف‌نظر از حوزه‌ی مورد مطالعه‌ی خود، احتیاج به ده سال تلاش دارید. محققان* به مطالعه‌ی بازی شطرنج، نقاشی، اجرای پیانو، شنا، تنیس و سایر مهارت‌ها و رشته‌ها پرداخته‌اند. در آخر در هر نمونه‌ای، از موزارت تا بیتل‌ها، شما می‌توانید شواهدی از حداقل 10 سال کار و تلاش سخت را قبل از قرار گرفتن در کلاس جهانی ببینید. به‌طور مثال گروه بیتل‌ها با اجرای تاریخی خود در Ed Sullivan Show در سال 1964، طوفانی به‌پا کردند. اولین آلبوم موفق آن‌ها با نام “Sgt. Pepper’s Lonely Hearts Club Band”، به مدت کمی پس از این موفقیت در سال 1967 به بازار آمد. اما قبل از آن در سال 1964، آن‌ها در تور کنسرت خود، خارق‌العاده نبودند و از سال 1957 تا آن زمان نیز تنها در کلاب‌ها می‌نواختند؛ 10 سال پیش از اجرای تاریخی خود.

با کار سخت، به‌ندرت به بیشتر از 10 سال احتیاج پیدا خواهید کرد. شما احتیاج به تمرین دارید. تمرین هدفمند- آن‌گونه که دانشمند برجسته‌ی علوم شناختی، Dr. K. Anderson Ericsson بیان می-کند- احتیاج به 4 شرط دارد:

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

این شیوه‌ی تدریجی تمرین و ممارست، شما را به حرفه‌ای شدن می‌رساند. همان‌طور که در کتاب “The Pragmatic Programmer: From Journeyman to Master [HT00]” ، آمده است، حتی Chaucer (از شاعران و نویسندگان برجسته‌ی ادبیات انگلیسی 1400-1340) نیز شکایت می‌کند که: "زندگی بسیار کوتاه است و هر صنعت یا هنری برای یادگیری بسیار بلند".

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

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

2.4. استفاده‌ی موثر از مدل دریفوس

در انتهای دهه‌ی 1970، حرفه‌ی پرستاری در امریکا در موقعیت دشواری قرار گرفت. مشکلات این حرفه را می‌توان بر اساس موارد متعدد مطالعه شده و روایت‌های گوناگون بیان شده در موارد زیر خلاصه کرد:[15]

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

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

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

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

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

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

پذیرش مسئولیت

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

در یک آزمایش [16]، یک محقق با اتاق عمومی بیماران بستری تماس گرفت و خود را به‌عنوان پزشک معرفی و از پرستاران می‌خواست که داروی مشخصی را به بیماری تعیین شده بدهند. دستور پزشک حاوی اشتباهات فاحش زیر بود:

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

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

"من تنها از دستورات پیروی کردم" راه حل نیست.

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

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

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

با نگاه کردن و تقلید، بیاموزید.

نوازنده‌ی ترومپت Clark Terry راز یادگیری موزیک را در عبور از سه فاز زیر می‌داند:

  • تقلید کردن
  • شبیه ساختن
  • نوآوری داشتن

هیچ تخصصی بدون تجربه وجود ندارد


موسیقی جاز هنری است که شدیدا به تجربه از دنیای واقعی وابسته است. ممکن است تمامی تکنیک‌های اجرای آن‌را بدانید اما لازم است که آن را اجرا کرده باشید تا بتوانید "حسش" کنید. نوازنده‌ی ترومپت مشهور Louis “Satchmo” Armstrong در مورد جاز می‌گوید که "اگر از آن بپرسید، هرگز آن را نخواهید فهمید".

هیچ تخصصی بدون تجربه وجود ندارد و هیچ جایگزینی نیز برای تجربه نیست اما می‌توانیم کاری کنیم که تجربه‌ی شما بهره‌وری بالا و موثرتری داشته باشد.

در ابتدا از تمرین‌های موجود تقلید می‌کنید و به آرامی دانش ضمنی را تحلیل و شبیه سازی کرده و تجربه می‌کنید. در نهایت در موقعیت فراتر از شبیه‌سازی رفته و ابداع می‌کنید. این پدیده، انعکاس سیکل آموزش در هنرهای جنگی است که به نام “Shu Ha Ri” شناخته می‌شود

.

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

ینابراین ما باید تمامی روش‌ها و راه‌هایی که به نگهداری تمامی تجربه‌های موجود در پروژه کمک می‌کنند را پیدا کنیم؛ هیچ‌کدام از این روند‌های تغییر و پیشرفت کمکی نخواهند کرد مگر این‌که افراد در حوزه تخصصی خود باقی بمانند.

بدست آوردن مهارت در تمرین

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

برنده‌ها، بازنده‌ها را با خود بالا نمی‌کشند.

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

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

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

مقاله‌ای که توسط Geoffrey Colvin نوشته شده است، این ایده را با توجه به این موضوع بسط داده است: همه در گروه، ستاره نیستند؛ بعضی‌ها تازه‌کارند (مبتدی‌ها و نوآموزان پیشرفته) و به تعداد کمتر نیز کاردان هستند. تازه‌کارها از نردبان بالا می‌روند اما برنده‌ها، بازنده‌ها را با خود حمل نمی‌کنند و بازنده‌ها از تیم جدا می‌شوند. در نهایت او خاطر نشان می‌کند که تنها 2/0 درصد از بهترین‌ها در کلاس جهانی قرار می‌گیرند نه 2 درصد.

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

  • میزان قدرت یک گروه به ضعیف ترین عضو آن وابسته است. بهترین اجرا‌کننده‌ها را برای بخش اصلی قرار دهید و برای سایر بخش‌ها از "گروه‌های معمولی" استفاده کنید.
  • یک گروه را با یک ترکیب تقریبا ثابت در هفته‌های متوالی در نظر بگیرید. شما می خواهید که گروه تشکیل شده به اصطلاح "بسته شده و محکم شود". جابجا کردن پیاپی نوازنده‌ها می تواند اثرات مخربی بر روی تولیدات موسیقی گروه داشته باشد.
  • زمان‌بندی همه چیز است؛ Drummer گروه نوازندگان و یا همراهی کننده‌ی گروه کر(accompanist) باید بسیار قابل اطمینان باشند. بهتر است از یک accompaniment از قبل ضبط شده استفاده کنید تا این‌که از یک Drummer یا تنظیم کننده‌ی عجیب و غیر قابل اعتماد استفاده کنید.
  • گروه خود را برای نوازندگان با استعداد جایی امن کنید و تمامی وقایع را زیر نظر داشته باشید.

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

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

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

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

برای حرفه‌ای باقی ماندن، به تمرین خود ادامه دهید.

2.5. از دام "ابزار" برحذر باشید

در مورد نقش ابزار، مدل‌های رسمی، مدلسازی و مواردی از این قبیل در حوزه‌ی توسعه نرم‌افزار، بسیار نوشته شده است. بسیاری بر این باورند که UML (Unified Modeling Language) و MDA (Model-driven architecture) آینده را در این حوزه شکل می‌دهند، دقیقا شبیه زمانی که بسیاری اعتقاد داشتند که RUP (Rational Unified Process) و CMM (Capability Maturity Model) نجات بخش این صنعت بوده است. اما مانند سایر سناریوهایی از این دست، مردم متوجه شدند که این امر به سهولتی که می‌پنداشتند، امکان‌پذیر نیست و اگرچه این ابزارها و مدل‌ها در جای خود بسیار مفیدند اما معجزه‌ای برای تمامی مشکلات نیستند و حتی استفاده‌ی نابجا از آن‌ها موجب صدمه‌زدن بیشتر به پروژه نیز می‌شود.

مدل یک "ابزار" است و نه یک آینه

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

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

دکتر Deborah Gordon در تالیف یک فصل از کتاب Benner با او همکاری نمود. این فصل به بررسی برخی از خطرات تکیه‌ی زیاد بر مدل‌های رسمی حرفه‌ی پرستاری پرداخته است. در این بخش من به تفسیری جدید از برداشت‌های او، با خصوصیات و جزییاتی از حرفه‌ی توسعه نرم‌افزار می‌پردازم، اما حتی متن اصلی هم بدون تغییراتی که من داده‌ام، بسیار برای شما آشنا خواهد بود.

عدم تشخیص مدل از واقعیت

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

بی‌ارزش کردن ویژگی‌ها و کیفیات غیر قابل فرموله شدن

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

قانونی کردن رفتارِ مخالف با استقلال و خلاقیت شخصی

 

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

بیگانه و منزوی کردن افراد باتجربه به نفع مبتدی‌ها

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

توضیح بیش‌از حد جزییات

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

ساده کردن بیش از حد وضعیت‌های پیچیده

طرفداران اولیه‌ی RUP (Rational Unified Process) و برخی از متاخرین آن‌ها بر این عقیده‌اند که "تمام کاری که باید انجام دهید این است که فقط از مراحل فرایند پیروی کنید". بسیاری از حامیان XP (Extreme Programming) نیز بر همین امر اصرار دارند. اما هر دو در اشتباهند. هر پروژه‌ای و هر موقعیتی پیچیده‌تر از این است که با این روش‌ها مدیریت شود. هر وقت کسی با این جمله حرفش را شروع کرده که "تمام کاری که باید انجام دهید این است که......" یا "فقط این کار را انجام دهید......." سخت در اشتباه بوده است!

استفاده‌ی‌بیش از حد از یک شیوه‌ی واحد

یک استاندارد واحد را نمی‌توان در موقعیت‌های مختلف، به‌طور یکسانی به‌کار برد و ممکن است شیوه‌ای که در پروژه‌ی قبلی شما بسیار موفق بوده باشد برای موقعیت جاری، یک فاجعه محسوب شود. "باب" و "آلیس" [17]در کار کردن باEclipse بسیار بهره‌وری دارند، در حالی‌که "کارول" و "تد" در کار کردن با آن، فاجعه به‌بار می‌آورند و IntelliJ [18]یا TextMate [19] و یا Vi [20]را ترجیح می‌دهند.

بی‌توجهی به جزییات وابسته به "زمینه"

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

سردرگمی بین پیروی از قواعد و قضاوت شخصی

چه زمانی برای شکستن قواعد و دستورالعمل‌ها مناسب است؟ همیشه؟ هیچ‌وقت؟ یا چیزی بین این دو؟ چطور بفهمیم؟

پیچیده‌ سازی

گفتارها و صحبت‌ها به‌حدی شکل شعار می‌گیرند که در نهایت مبتذل شده و معنی خود را از دست می‌دهند (برای مثال: "ما یک سازمان مشتری محور هستیم!"). روش‌های Agile نیز به سرعت تاثیر خود را به دلیل همین مشکل از دست می‌دهند.

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

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

هرگز تسلیم ابهت نابه‌جای یک ابزار و یا مدل نشوید. هیچ جایگزینی برای تفکر وجود ندارد.

2.6. و باز هم: "زمینه" را در نظر داشته باشید

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

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

-

کتاب دریای کورتز نوشته‌ی John Steinbeck

کتاب "دریای کورتز" Steinbeck در مورد تاثیر متقابل زمینه و حقیقت، تفکر عمیقی دارد. شما می‌توانید یک ماهی مکزیکی [21] را در آزمایشگاه توصیف کنید. کاری که باید انجام دهید این است: ظرف بدبوی حاوی جسد بیزارکننده و رنگ‌پریده از محلول فرمالین ماهی را بازکرده و آن را از ظرف خارج کنید. مهره‌های او را بشمارید و حقیقت را بنویسید: D.XVII-15-IX. این یک واقعیت علمی، اما فارغ از زمینه است و شبیه یک ماهی زنده نیست، "رنگش تغییر می‌کند و دمش را به هوا می‌کوبد". ماهی زنده در زمینه‌ی زیستگاه طبیعی‌اش واقعیتی بسیار متفاوت دارد از آن‌چه که درون ظرف آزمایشگاه نگهداری می‌شود؛ موضوع مربوط به زمینه.

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

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

از عینیت بخشیدن به چیزی، بدون درنظر گرفتن زمینه پرهیز کنید.

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

در مثال دیگر این موضوع را بررسی می‌کنیم: "من می‌خواهم این در قفل‌شده را باز کنم" اصلا کافی نیست! زمینه‌ی آن چیست؟ چه نیازی به باز شدن در است؟ آیا باید از یک ابزار مانند تبر یا اره برقی استفاده کنیم یا ابزاری که بدون جای گذاشتن اثری، قفل را باز می‌کند؟ یا شاید تنها نیاز است نگاهی به اطراف بیاندازیم تا شاید بتوانیم از در باز دیگری استفاده کنیم؟

در تفکر سیستمی مانند برنامه‌ریزی شی‌ء‌گرا، اغلب روابطی بین اجزا وجود دارد که جالب هم هست و همین روابط است که تفاوت‌ها را می‌سازد.

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

2.7. هر روز با دریفوس

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

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

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

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

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

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

مهارت یادگیری را یاد بگیرید.

در ادامه...

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

  • بهبود بخشیدن به شهود
  • درک اهمیت فزاینده‌ی زمینه و مشاهده‌ی الگوهای موقعیتی [22]
  • مهار و در اختیار آوردن بهتر تجربه‌‌های شخصی

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

مطالب مرتبط:


[1] Mind Over Machine: The Power of Human Intuition and Expertise in the Era of the Computer

[2] LINUX Commands

[3]شخص مدیر سیستم، کسی که بیشترین دسترسی‌ها و مجوز‌ها را دارد

[4] From Novice to Expert: Excellence and Power in clinical Nursing Practice

[5] Infinite Regression

[6] Teaching and Learning Generic Skills for the Workplace [SMLR90]

[7] نگاه کنید به: Personal Knowledge [Pol58]

[8] نگاه کنید به Standards for Online Communication [HS97]

[9] The Scope, Limits, and Training Implications of Three Models of Aircraft Pilot Emergency Response Behaviour [DD79]

[10]درسال 1968 طی مطالعه¬ای با عنوانExploratory Experimental Studies Comparing Online and Offline [Sac68] مشخص شد که بهره¬وری در بین برنامه¬نویس¬ها نسبتی 10 به 1 دارد. به¬نظر می¬آید که این فاصله تاکنون بسیار بیشتر شده باشد.

[11] نگاه کنید به: From Novice to Expert: Excellence and Power in Clinical Nursing Practice [Ben01])

[12] نگاه کنید به Standards for Online Communication [HS97]

[13] م: این عبارت (Metacognitive Ability) به معنی آگاهی نسبت به آگاهی و همان آگاهی از شناخت است: آنكس كه بداند و بداند كه بداند... اسب شَرف از گُنبد گردون بِجهاند.

[14] در این¬جا الگو به معنی الگوهای طراحی نرم¬افزار نیست بلکه مفهوم مصطلح الگوهای شناختی را دارد.

[15]نگاه کنید به: From Novice to Expert: Excellence and Power in Clinical Nursing Practice [Ben01]

[16]نگاه کنید به: Influence: Science and Practice [Cia01]

[17]م: یک محیط توسعه¬ی نرم¬افزار چند زبانه است

[18]م: یک java IDEA تجاری است.

[19]م: ویرایشگر متن GUI چند منظوره برای Mac OS X است.

[20]م: ویرایشگر متن است که در اصل برای سیستم عامل Unix طراحی شده است.

[21]Mexican Sierra Fish

[21]Situational Patterns


شما چه امتیازی به این نوشته می‌دهید؟

بازخورد بازدیدكنندگان

برای این نوشته كامنت بگذارید.
نام :
e-mail:
كامنت :


صفحه اصلی
نوشته‌ها
فلش‌كارت‌ها
فروشگاه
انجمن‌گفتگو
تماس با ما
© 1390 - 1384 شركت فن‌آوران اطلاعات و ارتباطات روزآمد، تمامی حقوق محفوظ است.