https://virgool.io/feed/@atomerz توسعه‌دهنده‌ نرم‌افزار fa 2026-06-16 13:09:47 https://files.virgool.io/upload/users/206198/avatar/zhEndM.png?height=120&width=120 https://virgool.io/@atomerz https://virgool.io/@atomerz/%D8%B7%D9%86%D8%A7%D8%A8-%D9%87%D8%A7%DB%8C-%D9%86%D8%A7%D9%BE%DB%8C%D8%AF%D8%A7%DB%8C-%D8%AE%DB%8C%D9%85%D9%87-%D9%82%D8%B3%D9%85%D8%AA-%DA%86%D9%87%D8%A7%D8%B1%D9%85-%D9%BE%D8%A7%DB%8C%D8%A7%D9%86-rfygxgp7hio8 سفری ذهنی در کشف انگیزه‌ها و شکل‌دهی به تصمیم‌های جمعیفصل چهارم: توانا بود هر که دانا بود؟بقا، وفا، و آن‌گاه اعتلاچند روزی از جلسه با خسرو و مهسا می‌گذشت. شهاب بعد از آن روز با محسن و سامان صحبت نکرده بود. هر کدام به روال عادی کارِ خود در خامه برگشته بودند. به نظر می‌رسید تمام تلاش‌ها به بن‌بست رسیده و جایی برای پیگیری و رفع چالش‌های مطرح شده وجود ندارد. پاسخ خسرو جای شکی برای این موضوع باقی نگذاشته بود. سرعت و صراحت او طوری بود که گویی از قبل تصمیم‌اش را گرفته بود. با این حال ذهن شهاب هنوز به چیزهایی که در جلسه مطرح شده بود مشغول بود.به نظر شهاب خیمه با وضعیت فعلی نمی‌توانست دوام بیاورد. ادامه‌ی کار با روال‌های فعلی به تدریج باعث تحلیل منابع و در نهایت ورشکستگی می‌شد. از طرفی ایرادهایی که مهسا وارد کرده بود هم به نظر درست و منطقی می‌آمد. حرف‌های خسرو هم حداقل در ظاهر بی‌راه نبود. اما چطور می‌شد همه‌ی این موارد را یک‌جا پاسخ داد؟شهاب با خود فکر کرد مهم‌ترین مأموریت یک سازمان چیست؟ هر سازمان متشکل از گروهی افراد است که هدف یا اهداف مشترکی را دنبال می‌کنند. افراد، اهداف، یا ساختار سازمان می‌توانند طی زمان تغییر کند اما آن‌چه تغییر نمی‌کند این است که همه‌ی این‌ها زمانی معنا پیدا می‌کند که سازمانی وجود داشته باشد. از این جهت سازمان شبیه یک موجود زنده است. اجزای آن می‌تواند تغییر کند، رشد کند، تحلیل برود و اهدافش ممکن است عوض شود. اما یک موجود مرده نه هدفی دارد و نه چیزی برای تغییر و بهبود. بنابراین مهم‌ترین مأموریت هر موجود زنده و به تبع آن یک سازمان، بقاست.خیمه می‌توانست با هر مشکلی دست و پنجه نرم کند یا آن را نادیده بگیرد. می‌توانست تغییر نکند و روال‌های فعلی را ادامه دهد. اما باید بقای خود را تضمین می‌کرد. آیا با ادامه‌ی مسیر فعلی خیمه زنده می‌ماند؟ شهاب مطمئن نبود. او صحبت‌های مهسا را به خاطر آورد. در ظاهر همه‌ی صحبت‌ها از جنس احساس خطر و نگرانی‌های منابع انسانی بود و نگاه کلی‌نگر سازمانی در آن دیده نمی‌شد. از جذب گرفته تا تغییر دکور و اجرای مراسم. حتی به نظر می‌آمد ایرادی که به تمامیت‌گرایی در سود و زیاد گرفته بود هم از دید محلی‌نگر نشأت گرفته باشد. اگر واقعاً این‌طور بود در واقع پیشنهاد جریان به نوعی بقای منابع انسانی را زیر سؤال برده بود. با این نگاه تعجبی نداشت که مهسا با جریان مخالف بود. اما شهاب یاد گرفته بود از نگاه‌های ساده‌انگارانه و دیگربدپندار پرهیز کند.او با خود فکر کرد ایراد مهسا به سخت شدن جذب نیرو قابل درک است. اگر به این مسأله فکر نمی‌شد و برای آن چاره‌ای پیدا نمی‌شد در بلند مدت خیمه از بین می‌رفت. در مسأله‌ی محاسبه‌ی سود و زیان هم ردّی از حقیقت دیده می‌شد. گاهی لازم است سازمان در مسیری قدم بردارد که با سود و زیان قابل سنجش نیست و یا نگاشت آن هزینه‌ی زیادی دارد. سامان وجود منابع انسانی و سایر خدمات سازمانی را خوب توضیح داده بود اما موارد دیگر به این راحتی توجیه نمی‌شدند. برای مثال شرکت در خیریه، یا در نظر گرفتن پیامدهای زیست‌محیطی که باعث بالا رفتن هزینه‌ی انجام کار می‌شوند و ... شهاب با خود فکر کرد هر چند همه‌ی این دغدغه‌های اهمیت دارند اما وزن آن‌ها یکسان نیست. در وهله‌ی اول هر آن‌چه بقای سازمان را تحت تأثیر قرار می‌دهد اولویت پیدا می‌کند و سایر موارد می‌توانند به تعویق بیفتند.شهاب متوجه شد جریان می‌خواهد با ایجاد انگیزه و هدف‌مند کردن روال‌های سازمان بقای خیمه را در بلند تضمین کند. اما در این مسیر چالش‌هایی ایجاد کرده که اگر پاسخ درست به آن داده نشوند سازمان در میان‌مدت دچار چالش‌های جدی‌تری می‌شد. خیمه در یک مسیر با بی‌نظمی‌های طبیعی در نقطه‌ای قرار گرفته بود که رشدش محدود شده بود و از منابع‌اش استفاده‌ی بهینه نمی‌کرد اما زنده مانده بود. با ادامه‌ی این مسیر بعید بود در بلندمدت بتواند زنده بماند اما با پیروی از جریان در شکل پیشنهادی فعلی‌اش احتمالاً زودتر تلف می‌شد.با این بینش شهاب اکنون نتیجه‌ی جلسه را درک می‌کرد. با این حال چیزی او را آزار می‌داد. تصمیم خسرو شاید نهایتاً تصمیم درستی بود اما برخورد او طوری بود که جایی برای تغییر شرایط و بهبود باقی نمی‌گذاشت. گویی مرگ تدریجی خیمه، محتوم و پذیرفته شده بود. خسرو نه تنها از تلاش خودجوش یک گروه در کشف یک مسأله‌ی سازمانی و ارائه‌ی راه‌حل برای آن، به وجد نیامده بود بلکه با نگاه سلسله‌مراتبی، بالا به پایین، و تحکمی که داشت انگیزه را از آن‌ها گرفته و ادامه‌ی راه را بر آن‌ها بسته بود. با این اوصاف تعجبی نداشت که پیش از شهاب کسی در این مسیر پیش قدم نشده بود. شاید چنین تجربه‌هایی افراد مشابه را یکی یکی در کنج عزلت خود قرار داده بود.به نظر می‌آمد خسرو در تشخیص جنبه‌ی تهدیدکننده‌ی بقای سازمان خوب عمل کرده اما به بخش دیگری ضربه زده باشد. او با نگاه سلسله مراتبی، بالا به پایین و ایجاد حوزه‌های استحفاظی در عمل وفاداری افراد به سازمان را تضعیف کرده بود. او با پیش‌رفتن در این مسیر راه بروز خلاقیت و دریافت پیشنهادهای کمک‌کننده را بسته بود. علاوه بر این فشار و مسئولیت حل مسأله را بر خود بیش از حد نیاز کرده بود. در نهایت این شیوه‌ی مدیریت باعث شده بود سازمان نتواند از مرحله‌ی بقا عبور کرده و خود را اعتلا دهد.با وجود همه‌ی این‌ها شهاب هنوز خود را عضو سازمان می‌دانست و دغدغه‌ی بهبود آن را داشت. هر چند چالش‌های جریان قابل حل به نظر می‌رسیدند با توجه به نگاه خسرو ادامه‌ی آن مسیر ناممکن به نظر می‌رسید. علاوه بر این به کارگیری یک شیوه‌ی امتحان نشده (حداقل در خیمه) به یک‌باره در سطح سازمانی غیر ضروری به نظر می‌رسید. شاید بهتر بود برای شروع، کار در مقیاسی کوچک‌تر انجام شود. شاید در جمعی که آمادگی و انگیزه‌ی بیشتری برای قرار گرفتن در مسیر جریان را داشتند. شاید خامه...بعد از مدت‌ها سردرگمی و تلاش مستمر، و علی رغم نتیجه‌ای که حاصل شده بود، شهاب احساس رضایت می‌کرد. او با بدون آن‌که بداند به خاطر برخورد با موانع و چالش‌ها در مسیر یک ماجراجویی قرار گرفته بود. طی مسیر گمراه شده اما نامیده نشده بود. با کمک گرفتن از همراهانی که داشت توانسته بود نقشه‌ی راهی برای ادامه‌ی مسیر طراحی کند. در نهایت به مانعی سخت برخورد کرده بود که برای رد شدن از آن به چیزی جز منطق و استدلال نیاز داشت. با این حال این مسأله او را ناامید نکرده بود. احساس می‌کرد تجربه و دانشی که کسب کرده او را در مسیری قرار داده که او را از این مانع هم عبور خواهد داد. احساس غریبی داشت و این حد از تلاش کردن با روحیه‌ی شیرازی‌اش سازگار نبود. از خیمه استعفا داد و به شیراز گریخت تا در سعدیه فال حافظ بفروشد.قصه‌ی ما به سر رسید، کلاغه هم دنبال شهاب به سمت شیراز رفت اما چون از مسیر هوایی رفت دچار خطای انسانی شد و به مقصد نرسید. سید مرتضی هاشمی سید مرتضی هاشمی Thu, 07 Nov 2024 14:48:43 +0330 https://virgool.io/@atomerz/%D8%B7%D9%86%D8%A7%D8%A8-%D9%87%D8%A7%DB%8C-%D9%86%D8%A7%D9%BE%DB%8C%D8%AF%D8%A7%DB%8C-%D8%AE%DB%8C%D9%85%D9%87-%D9%82%D8%B3%D9%85%D8%AA-%D8%B3%D9%88%D9%85-qgxvtxqbx5oy سفری ذهنی در کشف انگیزه‌ها و شکل‌دهی به تصمیم‌های جمعیفصل سوم: تدبیردستی بر آتششهاب خسته و بی‌رمق به خانه رسید و روی مبل ولو شد. احساس می‌کرد مثل آن چهار پا در چیزی بدبو گیر کرده است. اطلاعات زیادی با مشاهده، فکر کردن، و صحبت کردن با سامان، محسن و مریم کسب کرده بود. اما این اطلاعات بیش از آن‌که به او کمک کند دست و پای او را بسته بود. احساس سردرگمی می‌کرد. برای مشاهدات و قضاوت‌های خود ارزش قائل بود و آن‌ها را منطقی و مفید می‌دانست. با این حال صحبت‌های سامان هم بی‌نقص و با خود سازگار به نظر می‌رسید. از طرفی محسن هم به نکات مهمی اشاره کرده بود. با وجود این‌که پذیرفتنش سخت بود از مریم هم چیزهایی آموخته بود. اما وقتی همه‌ی این‌ها در کنار هم قرار می‌گرفت وضعیت همین می‌شد که بود.همه می‌خواستند خیمه را برپا کنند. هر یک طنابی در دست داشت و آن را به سوی خود می‌کشید. اما هیچ یک به سایرین نگاه نمی‌کرد و در نظر نمی‌گرفت که در این مقطع طناب باید از کدام جهت کشیده شود. در نتیجه خیمه هر بار از جهت متفاوتی واژگون می‌شد. چرا هیچ کس این را متوجه نشده بود و برای آن اقدامی نمی‌کرد؟ذهنش توانایی بیشتر از این فکر کردن را نداشت. تلویزیون را روشن کرد. اخبار ۲۰:۳۰ شروع شد. سرخط خبرها در حال پخش بود. گروهی از کشورها قاره‌ی سبز با گروهی دیگر در حال جنگ بودند و هر دو سو به خاک سیاه نشسته بودند! متحدان ایران در وسطستان با همکاری نیروهای امنیتی در موفقیتی بزرگ مشتی محکم بر دهان دشمن زده بودند و بخشی از سرزمین‌های از دست رفته را باز پس گرفته بودند. شهاب با خود فکر کرد که این سرزمین‌ها کِی از دست رفته بود که حالا پس گرفته شد؟ او اخبار منطقه را با دقت از تمام رسانه‌های معتبر داخلی دنبال می‌کرد اما این خبر از نگاه تیزبین او پنهان مانده بود. وقت بیشتر برای بررسی این موضوع نداشت. سرخط خبرها با سرعت ادامه داشت. شب گذشته موشک‌های ایران به سمت اِشغالستان پرتاب شده بود و ۱۰۰ درصد آن‌ها به اهداف برخورد کرده بود. ایران در یک کشمکش تاریخی با دیوِستان قرار داشت. هیچ‌وقت درگیری‌ها به جنگ مستقیم منجر نشده بود اما میانستان میدان جنگ نیابتی آن‌ها بود. اشغالستان یکی از کشورهایی بود که محل این جنگ‌های نیابتی قرار گرفته بود. با تمام شدن سرخط خبرها رئیس جمهور ایران در پاسخگویی به اراجیف رئیس (به اصطلاح) جمهور دیوستان سخنرانی می‌کرد.با ظاهر شدن تصویر ریاست محترم جمهور، شهاب ناخودآگاه از روی مبلی که در آن فرو رفته بود به نشانه‌ی احترام برخاست. ناگهان متوجه شد در خانه است و نیازی به تظاهر نیست. در نقطه‌ای دیگر روی مبل فرود آمد. رئیس، سخنان خود را با یک زبان خارجی آغاز کرد و چیزهایی شبیه به ورد به زبان آورد. شهاب این بخش از صحبت‌ها را خیلی متوجه نشد. بخش فارسی صحبت‌های رئیس با اشاره به رذالت، خباثت، و وحشی‌گری‌های مسئولین دیوستان شروع شد. ریاست فهیم جمهور دقت داشت که بین مسئولین دیوستان و دیوهای معمولی آن سرزمین تفاوت قائل شود. او بارها بر این موضوع تأکید کرده بود و در این سخنرانی هم به این موضوع اشاره کرد. در ادامه‌ی صحبت‌ها، ریاست فرزانه که ضعف‌ها و مشکلات داخلی از چشمان تیزبین‌اش پنهان نمانده بود مدیران داخلی را مورد عتاب قرار داد. او تأکید داشت که بارها گفته است که مشکلات باید حل شوند اما متأسافانه مدیران توجه نمی‌کردند...صحبت‌ها به جایی رسیده بود که در زندگی شهاب تأثیر مستقیم داشت. بنابراین جنبه‌ی تفریحش را از دست داد. اگر به شنیدن صحبت‌ها ادامه می‌داد احساس خشم پیدا می‌کرد. در جستجوی کنترل تلویزیون بود. بدون این‌که ذره‌ای از جایش تکان بخورد تمام اتاق را با چشمانش به طور کامل رصد کرد. در همین حال که بود احساس کرد مثل همیشه روی مبل راحت نیست. کنترل را یافته بود. تلویزیون را خاموش کرد اما رد یک سؤال در ذهنش باقی‌مانده بود.چطور یک مقام مسئول بلندپایه می‌توانست تا این حد از واقعیت فاصله گرفته باشد؟ قضاوت عامیانه که مدیران کشور را احمق یا شرور می‌دانست را نمی‌پسندید. این نگاه در واقع از همان جنس نگاه رئیس‌جمهور به دیوستان بود. در بهترین حالت حتی اگر این برداشت از واقعیت الهام گرفته بود، آن را کاریکاتوری و اغراق‌شده ترسیم کرده بود. علاوه بر این یک تصویر خیر و شر مطلق جایی برای قضاوت موشکافانه و بهبود باقی نمی‌گذارد. تکلیف همه کس و همه چیز روشن است. گمان شهاب این بود که واقعیت از این پیچیده‌تر است.دکتر کابوس عنکبوتیان، که مردم به برای راحتی او را کبوتی صدا می‌زدند، فردی ساده‌زی به نظر می‌آمد. لباسی ساده می‌پوشید و در خانه‌ای معمولی زندگی می‌کرد. در مقام رئیس‌جمهور بود اما گویی واقعاً از جنس مردم بود و برای رفاه آن‌ها تلاش می‌کرد. پس چه چیز باعث می‌شد تا در تصمیم‌گیری از مردم عادی فاصله بگیرد؟ چه چیز باعث می‌شد او خود صبح شنبه شستش نفتی شود؟ و چه چیز باعث می‌شد هر گروهی از مخالفین را مشتی خس و خاشاک ببیند؟ در نگاه اول شاید می‌شد گفت که اطلاعات درستی به او نمی‌رسد. شاید او توسط گروهی احاطه شده بود که اطلاعات کافی را به او نمی‌رساندند. شاید حتی مانع رسیدن این اطلاعات به او می‌شدند. فرضیات از این دست تمامی نداشتند اما شهاب احساس می‌کرد در مسیر اشتباهی پیش می‌رود. شاید اگر مثل سامان به جای پرداختن به این فرضیات پیچیده نگاهش به مسأله را عوض می‌کرد زودتر به جواب می‌رسید.او با خود فکر کرد که یک رئیس‌جمهور یا هر مقام مسئول دیگر چطور متوجه اشتباه خود می‌شود؟ از آن مهم‌تر کِی حاضر است در عمل به اشتباه خود اعتراف کرده و تصمیمش را تغییر دهد؟ شهاب مثال‌هایی را به خاطر آورد که این اتفاق رخ داده بود. در یک مورد وزیر امور خارجه، دکتر شریف، صحبت از بهبود روابط با دیوستان به میان آورده بود. در نتیجه‌ی هشیاری مردم و فشار فعالین مدنی بعد از ظهر همان‌روز بیانیه‌ای در تکذیب موضوع صادر کرد. صبح روز بعد مجبور به عذرخواهی شد و چیزی از شرافتش باقی نماند. یعنی تشخیص یک اشتباه و تغییر مسیر در صورت لزوم با سرعت باد ممکن بود. پس چرا در سایر موارد این اتفاق رخ نمی‌داد؟ شهاب این‌بار نمونه‌ای از این موارد را در ذهن آورد. پس از آن‌که قیمت اجناس به طور ناگهانی بالا رفت زندگی رئیس‌جمهور چه تغییری کرد؟ سر کوچه‌ی کبوتی هنوز سیب‌زمینی به همان قیمت قبل بود. شهاب از این گزاره‌ی مضحک لذتی لحظه‌ای برد اما بر آن تکیه نکرد. رئیس‌جمهور واقعاً ساده‌زی به نظر می‌آمد. اگر این تصویر ساختگی بود قضاوت سخت نبود اما اگر جعلی نبود چطور؟ گویی واقعاً شوخی با قیمت سیب‌زمینی آن‌قدرها هم که به نظر می‌آمد مضحک نبود. کبوتی در حقیقت مثل مردم زندگی نمی‌کرد و درکی از انتظارات آن‌ها نداشت. بنابراین نتیجه‌ی تصمیم‌هایی که می‌گرفت هر چند جامعه را تحت تأثیر قرار می‌دهد برای خود او قابل حس نبود.در یک مثال دیگر شهاب به یاد آن صبح شنبه‌ی کذایی و اتفاقاتی که پیش آمد افتاد. پس از آن مسیر حرفه‌ای رئیس جمهور چه تغییری کرد؟ برای دور دوم هم انتخاب شد. اگر می‌توانست در دور سوم هم شرکت می‌کرد اما چون قانون این اجازه را نمی‌داد به مدیریت سازمان بازیافت بلندپایگان مشغول شد. در واقع وقتی نتیجه‌ی یک تصمیم برای یک مسئول هزینه زیادی داشت او مجبور می شد به اشتباهش اعتراف کند. اما وقتی هزینه به اندازه‌ی کافی زیاد نبود می‌توانست بر اشتباهش پافشاری کند.اشتباه کردن تجربه‌ی دردناکی است. اشتباه کردن در جمع، علاوه بر دردناک بودن عواقب اجتماعی بیشتری هم در پی دارد. پذیرفتن اشتباه برای یک سیاست‌مدار، آن هم زمانی که اشتباهش از سوی مخالفان به او گوش‌زد می‌شود از جمله دردناک‌ترین و پر عواقب‌ترین تجربه‌هاست. با این بینش تعجبی ندارد که کبوتی اشتباهات خود را نمی‌پذیرد، از آن درس نمی‌گیرد و وضعیت کشور را به سمت بهبود سوق نمی‌دهد.شهاب با خود اندیشید که از این حیث اداره‌ی کشور شباهت زیادی به گروهی از آدم‌ها دارد که دور یک آتش حلقه زده‌اند. عده‌ای نزدیک‌تر به شعله و عده‌ای دورتر هستند. هر کسی دستش را به سمت آتش دراز کرده تا از آن بهره برده و از سرمای هوا در امان باشد. اگر کسی که در مورد شعله تصمیم می‌گیرد در حلقه‌ی اول باشد، احتمالاً شعله‌ی آتش را طوری تنظیم می‌کند که افراد دورتر سردشان خواهد شد. اگر کسی که تصمیم می‌گیرد در حلقه‌های دورتر باشد احتمالاً از حلقه‌های نزدیک‌تر به عنوان گوشت کبابی برای سایرین استفاده خواهد کرد. این‌که تصمیم‌گیرنده در کدام حلقه باشد و یا تصمیم‌گیری فردی یا جمعی باشد مسأله‌ی مهمی است اما مهم‌تر از آن این است که تصمیم‌گیرنده یا تصمیم‌گیرندگان اصلاً دستی بر آتش دارند یا نه؟ اگر تصمیم‌گیرنده با پوشیدن کاپشن خودش را گرم نگه‌داشته باشد، هر چقدر هم که متخصص، پاک‌دل، درست‌کار و ... باشد، تنظیم شعله‌ی آتش توسط او به نتیجه‌ی مطلوب برای جمع نخواهد رسید.جریانصبح یک روز دیگر شهاب در مسیر شرکت بود. با توجه به تجربه‌ی ناخوشایندی که دفعه‌ی پیش از رانندگی داشت این بار با تاکسی به محل کارش می‌رفت. در مسیر برای ادامه‌ی روز کاری برنامه‌ریزی می‌کرد. بعد از مدت‌ها سردرگمی احساس می‌کرد کلید حل مشکل را پیدا کرده است. تصمیم داشت قدم‌های آخر برای به نتیجه رساندن کار را بردارد. تا این‌جا اگر کمک و نظرات دیگران نبود به این نقطه نرسیده بود. ادامه‌ی مسیر هم بدون هم‌فکری با بقیه براش قابل تصور نبود. تصمیم داشت با محسن و سامان در مورد چیزهایی که فهمیده بود مشورت کند. کمک گرفتن از مریم را هم در نظر گرفته بود. از یک سو به نظر می‌آمد خود مریم میلی به کمک کردن در این مسیر نداشته باشد. از سوی دیگر شهاب اعتماد خود را به او از دست داده بود. اگر مریم با همان رویکردی که توضیح داده بود به این جمع اضافه می‌شد احتمالاً چیز بیشتری برای اضافه کردن نداشت. به شرکت که رسید با سامان و محسن صحبت کرد. قرار شد در پایان روز کاری به یک سفره‌خانه رفته و در این‌باره صحبت کنند.آخر وقت که شد هر سه با هم به سمت سفره‌خانه‌ای که همان نزدیکی بود روانه شدند. سفره‌خانه محیطی سنتی داشت اما خود را در زیرزمین یک ساختمان با نمایی امروزی پنهان کرده بود. با پایین رفتن از پله‌ها یک فضای دل‌انگیز مشاهده می‌شد. سالنی بزرگ دارای چند حوض. دور هر حوض تعدادی تخت قرار داده شده بود و موسیقی قهوه‌خانه‌ای ملایمی در حال پخش بود. یکی از تخت‌ها را انتخاب کرده و دور آن نشستند.شهاب سر صحبت را باز کرد و موضوع ناهمسویی افراد را مطرح کرد. در ادامه توضیح داد تا زمانی که نتیجه‌ی تصمیم‌ها تأثیر مستقیم بر افراد نداشته باشد پاسخگویی و مسئولیت‌پذیری شکل نخواهد گرفت.محسن با شنیدن این صحبت‌ها اضافه کرد که شفاف نبودن اهداف در سطح سازمان هم در این موضوع بی‌تأثیر نیست. او توضیح داد که نه تنها افراد در هماهنگی با هم عمل نمی‌کنند بلکه این موضوع در ارتباطِ آن‌ها با سازمان هم بروز پیدا می‌کند. در این شرایط هدایت سلسله تصمیم‌ها به سمتی مشخص امکان‌پذیر نیست.همزمان که صحبت‌ها رد و بدل می‌شد سامان شنونده‌ بود اما چیزی نمی‌گفت. سرویس چای از دور نزدیک شد و روی تخت قرار گرفت. یک فنجان را در استکان قرار داد و جلوی خود قرار داد. وقتی شهاب در حال صحبت کردن بود صدای دیگری هم در گوش سامان می‌پیچید. حوضی که در نزدیکی تخت قرار داشت در واقع شکلی شبیه به چند جام داشت که روی یکدیگر قرار گرفته باشند. هر چه یک جام بالاتر بود بود، اندازه‌اش هم کوچک‌تر بود. در قله‌ی آن فواره‌ای قرار داشت که آب مثل یک چشمه از آن بیرون می‌آمد. هر طبقه از حوض، آب را از لایه‌های بالاتر می‌گرفت و از شیارهای مشخصی به لایه‌ی پایین‌تر تحویل می‌داد. فرود آمدن آب از این شیارها حالتی شبیه به آبشار ایجاد کرده بود. صدای شرشر همین آبشارک‌ها توجه سامان را به خود جلب کرده بود. در هر طبقه‌ی حوض تعدادی ماهی در رفت و آمد بودند. اکنون محسن صحبت می‌کرد و گوش سامان با او بود. در همین حال با لبانش چای را جرعه جرعه می‌نوشید و چشمش را به یکی از این ماهی‌ها دوخته بود. او داشت به مرزهای اجرای همزمان چندکار نزدیک می‌شد. ماهی، بی‌هدف در حوض حرکت می‌کرد و از یک سو به سوی دیگر می‌رفت. در نتیجه‌ی تعدادی از همین حرکت‌های بی‌هدف در نزدیکی یکی از آبشارک‌ها قرار گرفت. بی‌آن‌که بداند به ابتدا آرام آرام و سپس به سرعت به سمت آن کشیده شد. چیزی نمانده بود که در عمق آبشار فرو برود اما تقلایی کرد و خود را از مهلکه رهاند. صحبت‌های محسن در حال تمام شدن بود که ایده‌ای به ذهن سامان رسید.از محسن و شهاب خواست یک رودخانه را در نظر بگیرند. رودخانه مسیری است که آب از یک سوی آن به سوی دیگر روانه می‌شود. هر چند حرکت در مسیر عکس رودخانه غیر ممکن نیست اما هزینه‌ی زیادی دارد. اگر شما مسافری باشید که به سمت پایین رودخانه راهی است به راحتی از جریان رود استفاده می‌کنید و سریع‌تر و کم‌هزینه‌تر به مقصد می‌رسید. اگر بخواهید از یک سوی رود به سوی دیگر برود باز هم می‌توانید این کار را انجام دهید. اما اگر مقصد شما به سمت بالارود باشد حرکت در مسیر رودخانه انرژی زیادی از شما خواهد گرفت و بهتر است راه دیگری را انتخاب کنید. در واقع همراه شدن با جریان رود در عمل برای کسانی امکان‌پذیر است از قبل در مسیری هم‌سو با آن قرار دارند و یا می‌توانند با آن هم‌سو شوند.شهاب منظور سامان را فهمیده بود اما نمی‌توانست از آن برای حل مسأله‌ی خیمه استفاده کند. برای همین پرسید: چطور این رو در خیمه به کار ببندیم؟سامان توضیح داد در شرایط فعلیِ خیمه، یک فرد برای تلاش بیشتر و پیش‌برد اهداف تیم دو انگیزه دارد. اول حقوقی که دریافت می‌کند و دوم مسیر ارتقای سازمانی. سازوکار فعلی هیچ یک از این دو به شکلی نیست که فرد را تشویق به تولید نتیجه‌ی نهایی برای سازمان کند.حقوق چیزی است که تقریباً بی‌قید و شرط در پایان ماه به حساب شما واریز می‌شود. مسیر ارتقای سازمانی هم توجهی به این موضوع ندارد. مسیر فنی، رشد فردی را دنبال می‌کند و مسیر مدیریتی به دنبال کنار هم نگه داشتن آدم‌هاست. برای این‌که بتوانیم جریان را به وجود آوریم باید مسیر ارتقای جدیدی طراحی کنیم. مسیری که اهداف فردی، تیمی و سازمانی را همراستا کرده و ارتباط مزایای مالی با آن را شفاف‌تر کند. با تمام شدن صحبت‌های سامان قرار شد روز آینده پیش‌نویسی برای مسیر ارتقای سازمانی آماده کنند.صبح روز بعد هر سه به موقع در اتاق جلسه حاضر شدند و به طراحی مسیر جدید پرداختند. حاصل کار، سندی بود که مسیر ارتقای سازمانی را تعیین می‌کرد. در این سند اهداف سازمانی بالادستی مثل کسب درآمد و رضایت مشتری به صراحت ذکر شده بودند. مأموریت هر یک از بخش‌های سازمان در نهایت برآورده کردن این اهداف بود. به همین ترتیب، تیم‌های زیر یک بخش و افراد عضو یک تیم باید به نحوی به پیش‌برد این اهداف کمک می‌کردند. ارتقاء و پیش‌رفت هر عنصر سازمانی در گرو ارتقأ و پیش‌رفت عناصر بالادست‌تر تعریف شده بود. به این ترتیب اگر فرد، تیم یا یک بخش، کاری را به بهترین شکل انجام می‌داد اما نهایتاً منجر به تغییری در وضعیت اهداف سازمانی نمی‌شد، رشد نمی‌کرد.هر عنصر سازمانی، در حوزه‌ی مسئولیتی که به او سپرده شده بود آزادی عمل برای تصمیم‌گیری داشت. مادامی که تصمیم‌ها منجر به بهبود وضعیت اهداف سازمانی می‌شد نیازی به مداخله نبود. برای شفاف‌سازی، مثالی از به کارگیری این رویکرد در خامه آورده شده بود. تمام تصمیم‌گیری‌های مربوط به پروژه از داخل تیم و بدون دخالت خارجی قابل انجام بود. این آزادی عمل مشروط به این بود که ارتباطِ هر تصمیم با پیش‌برد اهداف پروژه و اهداف سازمانی برای ذی‌نفعان مشخص شده باشد. علاوه بر این، عنصر تصمیم‌گیرنده (در این مورد خامه) مسئولیت پیامدهای تصمیم‌گیری را نیز عهده‌دار می‌شد. یعنی اگر اهداف برآورده نمی‌شدند، تیم و به تبع آن اعضای تیم امتیازی برای ارتقاء در سازمان دریافت نمی‌کردند.به‌کارگیری این رویکرد می‌توانست چالش‌هایی ایجاد کند. برای مثال چنان‌چه شهاب کار خود را به درستی انجام می‌داد اما مریم نمی‌توانست به اندازه‌ی کافی هدف فروش را برآورده کند هر دو تنبیه می‌شدند. این در حالی بود که شهاب نه علاقه‌ای به مسائل فروش و بازاریابی داشت و نه تخصصی. در پاسخ به این چالش، در سند توضیح داده شده بود که هر عنصر باید حداقلی از آشنایی و تسلط را کسب کند تا بتواند در مورد تعیین مسیر برای رسیدن به یک هدف سازمانی بین گزینه‌های موجود قضاوت کند. در مثالی که ذکر شد، شهاب می‌توانست اطلاعات بیشتری در مورد کاری که انجام می‌داد کسب کرده تا بتواند رسیدن به هدف سازمانی را برای خود توجیه کند. او همچنین می‌توانست بدون کنکاش عمیق به مریم اعتماد کرده و در این مسیر پیش برود. در هر صورت نمی‌توانست از پیامدهای انتخابش بگریزد.به کارگیری این رویکرد مشکل به تعویق افتادن تصمیم، جلسات طولانی و بحث‌های بی‌پایان را نیز خود به خود حل می‌کرد. در مدل پیشنهادی مسیر رشد شهاب از برآورده شدن اهداف سازمانی می‌گذشت. بنابراین او همواره مجبور بود بین ادامه‌ی گفتگو برای یافتن راه‌حل بهتر و پیش‌برد کار با آن‌چه عملی به نظر می‌رسد مصالحه برقرار کند.در بخش‌های دیگر سند، به تفصیل در مورد مسیرهای رشد از منظر فردی، تیمی، تخصصی و ... توضیح داده شده بود. در هر موضوع تلاش شده بود با ذکر مثال، ابهامات و ظرافت‌ها شفاف شوند. در مجموع تصویر کلی این بود که سازمان به خرده‌سازمان‌هایی خودمختار تفکیک شده که در قبال به نتیجه رسیدن کارها در حوزه‌ی مسئولیت خود پاسخگو بودند. هر چقدر یک خرده‌سازمان سابقه‌ی بهتری در برآورده کردن اهداف سازمانی نشان می‌داد رشد، آزادی عمل، و جبران خدمات بیشتری پیدا می‌کرد.آن‌سوی پرده‌های خیمهشهاب، محسن، و سامان از نتیجه‌ی کاری که انجام داده بودند راضی بودند. قدم بعدی مطرح کردن موضوع در گروهی از مدیران ارشد خیمه بود. محسن هماهنگی‌های لازم را انجام داد. سندی که نوشته بودند پیش از جلسه با حاضرین به اشتراک گذاشته شد تا بیشترین استفاده را از زمان جلسه ببرند.روز جلسه فرا رسید. علاوه بر این سه نفر، مهسا نماینده‌ی منابع انسانی و خسرو مدیر عامل هم در جلسه شرکت داشتند. جلسه با ارائه‌ی شهاب شروع شد. طی چند دقیقه او علت ایجاد شدن دغدغه و مشکلات موجود را توضیح داد. سپس بدون این‌که وارد جزئیات شود رویکرد کلی سند به حل مسأله را مطرح کرد. او توضیح داد هدف اصلی در درجه‌ی اول، شفاف کردن اهداف و ایجاد هم‌سویی عناصر سازمانی با آن‌هاست. در درجه‌ی دوم، تلاش می‌شود سازوکاری برای مسئولیت‌پذیری و حل تعارض به شکل توزیع‌شده طراحی شود. یعنی هر عنصر سازمانی برای رسیدن به اهداف تعیین شده انگیزه پیدا کند و در شرایط تعارض بتواند مصالحه را به درستی برقرار کند.در ادامه خسرو شروع به صحبت کرد. او به وجود مشکل اذعان داشت و آن را درک می‌کرد اما اضافه کرد ایراداتی در سند وجود دارد که پیاده‌سازی آن را در عمل ناممکن می‌کند. سپس از مهسا خواست در این مورد توضیح دهد.مهسا گفت هدف‌گرایی و ضرورت رسیدن به نتیجه را درک می‌کند و آن را برای سازمان لازم می‌داند. با این حال روشِ پیشنهادی سخت‌گیرانه است و می‌خواهد به شیوه‌ای خاص آن را اجرا کند. این مسأله می‌تواند جذب و نگه‌داری نیرو را با چالش مواجه کند. علاوه بر این، سنجش و اندازه‌گیری همه‌ی فعالیت‌های سازمان با نگاه سود و زیان نه امکان‌پذیر است و نه انسانی. برای مثال، فعالیت‌های منابع انسانی به طور کل هزینه بود و سودی از آن حاصل نمی‌شد. از جذب نیرو و مصاحبه گرفته تا هر گونه تغییر در فضای شرکت یا مراسم سالانه.صحبت‌های مهسا که تمام شد محسن تلاش کرد به ایرادهای مطرح شده پاسخ دهد. او با جزئیات بیشتری وضعیت فعلی را توضیح داد. تأکید او بر این بود که با وجود ایرادهایی که ممکن است در سند پیشنهادی وجود داشته باشد ادامه‌ی وضعیت فعلی در بلند مدت خیمه را با شکست مواجه خواهد کرد.سامان پشت صندلی خودش جابجا شد. این توضیحات درست بود اما هیچ کدام از ایرادهایی که مهسا مطرح کرده بود پاسخ داده نشده بود. صرفاً دوباره ذکر مصیبت شده بود. با اشاره به محسن از او اجازه خواست رشته‌ی کلام را در دست بگیرد. سامان در پاسخ به ایرادی که مهسا در مورد منابع انسانی مطرح کرده بود شروع به توضیح کرد. او گفت در نگاه جدید بخش‌های مختلف سازمان در عمل شرکت‌هایی خودمختار هستند که از یکدیگر خدمات می‌گیرند. هیچ شرکتی بدون جذب نیرو زنده و سرپا نخواهد ماند. با این نگاه کسی به ضرورت وجود و فعالیت منابع انسانی شک ندارد. همچنین توضیح داد شرکت‌هایی را می‌شناسد که کار را از این پیش‌تر هم برده‌اند. به این معنی که میان این زیر شرکت‌ها نوعی از پول داخلی اختراع کرده‌اند و در خدمت دادن و خدمت گرفتن از یکدیگر از این پول داخلی استفاده می‌کنند. این باعث می‌شود ارزش خدمات هر گروه و حتی ارزش هر خدمت به طور خاص هم قابل اندازه‌گیری و ارزیابی باشد. او اضافه کرد به چنین مواردی در این سند نپرداختیم تا آن را ساده و قابل اقدام نگه‌داریم.بعد از صحبت‌های سامان، خسرو شروع به صحبت کرد: از توضیحاتی که دادی متشکرم. اما اجازه بدید یه چیزی رو شفاف توضیح بدم. حل مشکلاتی که توضیح دادید در نهایت کار مدیران ارشد سازمانه. ما هم به مسأله آگاهیم و داریم روش کار می‌کنیم. این مدل شکوندن سازمان به زیرسازمان‌های خودمختار، آشوب ایجاد می‌کنه. حرکت به این سمت خطرناکه و من تصمیم ندارم این کار رو انجام بدم. این تصمیم نهاییه ولی به این معنی نیست که صحبت کردن در موردش مجاز نیست. اگر جایی ابهامی هست می‌تونید مطرح کنید.شهاب، سامان، و محسن نگاهی به یکدیگر انداختند و بدون این‌که کلمه‌ای رد و بدل شود توافق کردند جلسه به پایان برسد. شهاب انتظار چنین نتیجه‌ای از جلسه نداشت. احساس ناخوشایندی داشت. خسرو را به خاطر موضع شفافی که داشت تحسین می‌کرد. او شک نداشت خسرو کاملاً به پیامدهای تصمیم‌اش آگاه است و حداقل در مورد یک مدیرعامل گریزی از پیامدهای تصمیم وجود ندارد. با این حال به خاطر برخورد با یک دیوار بتنیِ سخت که تا آخرین لحظه از دید او پنهان مانده بود، گیج و شگفت‌زده بود. سید مرتضی هاشمی سید مرتضی هاشمی Sat, 02 Nov 2024 14:02:37 +0330 https://virgool.io/@atomerz/%D8%B7%D9%86%D8%A7%D8%A8-%D9%87%D8%A7%DB%8C-%D9%86%D8%A7%D9%BE%DB%8C%D8%AF%D8%A7%DB%8C-%D8%AE%DB%8C%D9%85%D9%87-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-bwni9xnn9d5b سفری ذهنی در کشف انگیزه‌ها و شکل‌دهی به تصمیم‌های جمعیفصل دوم: سرگشتگیمرگ با عزت به از زندگی با ذلتشهاب: سامان می‌شه باهات صحبت کنم؟سامان: چرا نمی‌شه؟یک جلسه‌ی بی‌نتیجه‌ی دیگر به پایان رسیده بود. شهاب در عین خستگی و کلافگی، تصمیم گرفته بود ریشه‌ی این مسأله را پیدا کند. به همین علت می‌خواست با سامان صحبت کند. هر دو به سوی رخنه روانه شدند. رخنه نام اتاق جلسه‌ای دو نفره کمی آن‌طرف‌تر بود (منابع انسانی‌های بی‌مزه!).سامان: خب؟شهاب: من مدتیه احساس می‌کنم در جلسات کارها پیش نمی‌ره و تصمیمی گرفته نمی‌شه. انگار هر کس دنبال اینه که بگه نظر خودش درسته. زمان زیادی رو به صحبت کردن می‌گذرونیم و در نهایت نتیجه‌ی مشخصی نداریم.شهاب سکوت می‌کند و منتظر پاسخ سامان است.سامان: خب؟شهاب: همین دیگه.سامان: سؤالت چیه؟شهاب: خب تو مدام تو جلسات نظر مخالف داری...سامان: ...شهاب: گاهی کلمات نامناسبی استفاده می‌کنی... یه وقت‌هایی اشتباه می‌کنی و نظرت عوض می‌شه... خب اگر مخالفت نکنی نیازی نیست نظرت رو هم عوض کنی و زودتر به نتیجه می‌رسیم.سامان: این بار هم سوال نپرسیدی و هم چند تا چیز رو با هم گفتی. بذار کمکت کنم. من دنبال مخالفت یا موافقت با چیزی نیستم. من با اطلاعاتی که دارم تصمیم می‌گیرم. گاهی اوقات تو جلسه اطلاعات جدیدی مطرح می‌شه که باعث می‌شه نظرم تغییر کنه. این اتفاقاً نشونه‌ی اینه که دنبال این نیستم که نظر خودم درست باشه. بعدش هم، همیشه که نظرم اشتباه نیست.شهاب کمی مکث کرد و گفت: اما گاهی اوقات طوری نظرت رو می‌گی که دیگه کسی براش مهم نیست در مورد چی حرف زدی.سامان: من متوجهم که گاهی اوقات افسار از دستم در می‌ره و چیزی می‌گم که نباید بگم. دارم روش کار می‌کنم اما بذار باز بهت کمک کنم. سوال تو هیچ کدوم از این‌ها نیست. سوال تو همون چیزهایی هست که اول گفتی. چرا کارها پیش نمی‌ره؟ چرا تصمیم گرفته نمی‌شه؟ چرا هر کس دنبال اینه که نشون بده نظر خودش درسته؟ چرا در نهایت نتیجه نداریم؟ درسته؟شهاب: خب آره.سامان: خب من که تو همه‌ی جلسات نیستم. اون‌جاها کار چطور پیش می‌ره؟شهاب: بعضی وقت‌ها همینه و بعضی وقت‌ها این‌طور نیست.سامان: اون وقت‌هایی که وضع همینه که هیچ. در اون مواقعی که این طور نیست و به نتیجه می‌رسیم در نهایت چه اتفاقی می‌افته؟ وقتی من هستم هم در نهایت به یه نتیجه می‌رسیم دیگه، فقط دیرتر. بعدش چی می‌شه؟ خودت می‌گی حس می‌کنم کارها پیش نمی‌ره. پس این یعنی با سرعت به نتیجه رسیدن مشکلی رو حل نمی‌کنه. این یعنی حذف یا تغییر رفتار من مشکل رو حل نمی‌کنه. موافقی؟شهاب: فکر کنم آره.سامان: پس مشکل چیه؟شهاب: نمی‌دونم...سامان: در جلسات چطوری تصمیم می‌گیریم؟شهاب: با همدیگه صحبت می‌کنیم و در نهایت رأی می‌گیریم؟سامان: درسته. اون مواقعی که به نتیجه می‌رسیم یعنی رأی اکثریت به یک تصمیم رسیده. درسته؟شهاب: آره.سامان: چطوری این اتفاق رخ می‌ده؟ تو خودت تو جلسات کی به یک تصمیم رأی می‌دی؟شهاب: خب معلومه. وقتی که فکر کنم تصمیم درسته.سامان: مطمئنی؟ اون چیزی که بهش رأی می‌دی نظر خودته یا نظر کس دیگه‌ای؟شهاب: چه فرقی می‌کنه؟سامان: فرق می‌کنه. بیا در مورد مواقعی که خودت نظری داریم صحبت کنیم. وقتی که نظرت رأی میاره که هیچ. وقتی نظرت عوض می‌شه چه اتفاقی افتاده؟شهاب: خب فهمیدم نظرم اشتباهه.سامان: خیلی خوبه. آفرین. تا اینجا عین هم هستیم. اما چیزی رو یادت نرفته؟شهاب: ...سامان: مگه قرار نشد اگه نظرمون عوض می‌شه بحث نکنیم؟ خودت به این حرف عمل می‌کنی یا نه؟ من فرض می‌کنم عمل می‌کنی. حالا یا آگاهانه یا ناخودآگاه.شهاب کمی مؤذب شد و در فکر فرو رفت. به نوعی احساس می‌کرد به اون توهین شده. او یا ریاکار بود یا سست عنصر. در هر صورت درست‌کاری او زیر سؤال رفته بود.سامان: خیلی ناراحت نشو. فقط تو نیستی که این‌طور هستی. بقیه هم همین‌طور هستن. برای زودتر به نتیجه رسیدن از نظری که دارن کوتاه میان حتی اگر بدونن اشتباهه. اما این تنها حالتی نیست که اجماع حاصل می‌شه. دنیای واقعی از این هم پیچیده‌تره. اگر تو نتونی در یک موضوع قضاوت مستقل داشته باشی (یعنی بدون این‌که به بقیه نگاه کنی خودت بتونی با توجه داده‌هایی که داری به یک تصمیم برسی) به کدوم گزینه رأی می‌دی؟ اگر به خودت اعتماد به نفس داشته باشی، رأی نمی‌دی. اگر نداشته باشی چی؟شهاب: رأی می‌دم؟سامان: به چی رأی می‌دی؟ چطوری انتخاب می‌کنی؟شهاب: ...سامان: واقعیتش اینه که مهم نیست به چی رأی می‌دی در بهترین حالت به نظر اونی که فکر می‌کنی بیشتر می‌فهمه رأی می‌دی و موضع اون رو قوی‌تر می‌کنی در حالی که صلاحیت نظر دادن رو نداری...شهاب به فکر فرو رفت. کمی گیج شده بود. چطور بحث به اینجا رسیده بود؟ اصلاً در مورد چه صحبت می‌کردند؟سامان: ... می‌خوام بگم واقعیت به این سادگی که فکر کنی نیست. اما برگردیم به سوال خودمون. چرا تصمیم نمی‌گیریم؟ چرا جلسات طولانی می‌شه؟ چرا حتی وقتی تصمیم می‌گیریم به نظر میاد کار پیش نمی‌ره؟ جواب همه‌ی این‌ها در یک کلمه خلاصه می‌شه «میانگین»!شهاب یاد جلسه‌ای افتاد که سامان در آن زمزمه‌ای کرده بود. حرف او را کامل نشنیده بود اما میانگین را به خوبی به خاطر داشت. کلمه‌ی دیگه‌ای هم در کنار آن شنیده بود اما یادش نمی‌آمد. در همین فکر بود که گفت: چه ربطی به ترس داره؟سامان: آفرین! سؤال خوبیه. ولی من نگفتم ترس، گفتم میانگین. چه اتفاقی افتاده که ما چه تصمیم بگیریم و چه تصمیم نگیریم احساس پیش‌رفت نداریم؟ این اتفاق وقتی رخ می‌ده که تصمیم‌ها جهت مشخص نداشته باشن و یکی پس از دیگری همدیگه رو پشتیبانی نکنن. در یک جلسه تصمیمی می‌گیریم که در جلسه‌ی دیگری بی‌اثر یا تضعیف می‌شه. یک روز تصمیم به سرمایه‌گذاری در کیفیت می‌کنیم و یک روز دیگه تصمیم به کاهش بودجه‌ی کیفیت می‌کنیم. خب این اتفاق چطور رخ می‌ده؟ به اون مثال‌هایی که از پیچیدگی واقعیت زدم فکر کن. شیوه‌ی تصمیم‌گیری ما رو هم به یادت بیار. به چه نتیجه‌ای می‌رسی؟شهاب: نمی‌دونم... رأی گیری نکنیم؟سامان: عجله نکن. به این نتیجه می‌رسیم که تصمیم‌گیری‌های جمعی ما در جهت مشخصی نیست. چرا در جهت مشخصی نیست؟ چون این گروه در مجموع داره به جای تصمیم‌گیری آگاهانه شیر یا خط بازی می‌کنه. حالا در این نقطه دو راه داری. اول این‌که بری بفهمی چرا رأی گیری تبدیل به شیر یا خط شده و درستش کنی. دوم این‌که وقتی یه جاهای احساس کردی این گروه تبدیل به کمیته‌ی شیر یا خط شده تبدیل به دیکتاتوری‌اش کنی. دیکتاتوری نه به این معنی که یک نفر دیگه شیر یا خط بنداره به این معنی که یک نفر هست که حواسش هست تصمیمات در یک جهت خاص پیش می‌رن و به نتیجه می‌رسن حتی اگر بهینه نباشن. خب حالا چه کسی می‌تونه نقش این دیکتاتور رو داشته باشه؟شهاب: مُدسِن؟سامان: آفرین. خودت نفهمیدی ولی مغزت فهمید. مدیر یا همون محسن!شهاب: اگر اشتباه کرد چی؟سامان: مرگ با عزت به از زندگی با ذلت!شهاب: یعنی چی؟سامان: یعنی اگه قراره اشتباه کنم، هر چه زودتر بفهمم بهتره. نه این‌که دور سرم بچرخم مبادا که بفهمم اشتباه کردم. حداقل وقتی اشتباه کردم با خیال راحت مسیر متفاوتی رو می‌رم.شهاب: این‌ها رو به محسن گفتی؟سامان: بارها!شهاب: خب. چرا محسن این کار رو نمی‌کنه؟سامان: این رو دیگه باید از «مُدسِن» بپرسی.شهاب لبخندی زد و گفت: تو چرا مدسن نمی‌شی؟سامان: این هم سوال خوبیه. ولی دیگه خستگی در من رخنه کرده. خودت بهش فکر کن. دلیل شخصی من اینجا مهم نیست. برای این‌که دست‌خالی نرفته باشی به مشکلی که به من تذکر دادی فکر کن. به نقش پدر و مادر در خانواده هم فکر کن. به تفاوت مربی و بازیکن هم فکر کن. شاید به جاهای خوبی رسیدی.ربط روغن موتور به شانه کردن موشهاب بعد از صحبت کردن با سامان به جای آن‌که احساس کند بیشتر می‌داند حس حماقت بیشتری می‌کرد. شاید به خاطر خستگی دو جلسه‌ی پیاپی بود. شاید هم به این خاطر بود که بیشتر از آن‌که چیزی فهمیده باشد، فهمیده بود چقدر نمی‌داند. سامان به نوعی مشاهدات او را بی‌ارزش کرده بود. او نه تنها مشاهدات سامان را ناقص توصیف کرده بود و پیچیدگی بیشتر واقعیت را نشان داده بود بلکه گفته بود این ره که می‌روی به ترکستان است و اصل چیز دیگری است. او به این بسنده نکرده بود و مشق هم برای شهاب تعیین کرده بود. او باید می‌فهمید چرا سامان خودش کار را در دست نمی‌گرفت. همچنین باید می‌فهمید چرا محسن ایده‌های سامان را عملی نمی‌کند. حرف‌های او به نظر بی‌نقص می‌آمد.امروز نه وقت کافی برای صحبت کردن با محسن را داشت و نه توان لازم را. تصمیم گرفت تا جلسه‌ی تک به تک بعدی صبر کند و این موضوع را مطرح کند. جلسات تک به تک در خیمه جلساتی بود بین یک مدیر و فردی که مستقیم با او کار می‌کند. این جلسات به صورت منظم و دوره‌ای برگزار می‌شد. روز جلسه فرا رسید و شهاب موضوع را با محسن در میان گذاشت.محسن: موضوع پیچیده‌تر از این‌هاست...شهاب در ذهن خود آهی کشید. کم‌کم داشت نسبت به این کلمه حساس می‌شد.محسن: رسیدن به نتیجه مهمه اما فقط به نتیجه رسیدن نیست که مهمه. من می‌خوام اعضای تیمم خوش‌حال باشن. می‌خوام مسئولیت‌پذیر باشن. می‌خوام در نبود من خودشون بتونن کارها را به نتیجه برسونن. می‌خوام مسأله‌ای نادیده گرفته نشه. برقرار کردن توازن بین همه‌ی این‌ها کار ساده‌ای نیست. اگر تصمیم‌گیری‌ها رو من انجام بدم در بلند مدت تیم از هم می‌پاشه.شهاب مطمئن نبود دقیقاً حرف محسن را درک کرده باشد اما اهمیت برخی از این موارد را درک می‌کرد. چیزی که متوجه نمی‌شد این بود که چرا جهت دادن به تصمیم‌ها باعث از هم پاشیدن تیم می‌شود. همین سوال را از محسن پرسید.محسن: اجازه بده یه تیم خوب رو برات توصیف کنم. توی یه تیم خوب این مدیر نیست که تصمیم‌ها رو می‌گیره. هر کدوم از اعضای تیم می‌تونن تصمیم‌گیری و تصمیم‌سازی کنن و آزادی عمل لازم رو دارن. توی چنین تیمی آدم‌ها خوش‌حالن. خودشون رو مسئول می‌دونن. احساس می‌کنن هدف دارن و رشد می‌کنن. مدیر توی تیم می‌چرخه، حواسش به آدم‌ها و ارتباط‌هاشونه و وقتی جایی مانعی وجود داره، اون رو برطرف کنه. از این جهت عملکرد یه مدیر مثل روغن موتوره. باعث می‌شه قطعات روون و بدون اصطکاک کار کنن و ماشین سالم بمونه.حالا تصور کن که من شروع کنم به تصمیم‌گیری. سلسله اتفاقات بعد از اون رو تصور کن. کم‌کم به این تبدیل به رفتار طبیعی می‌شه. آدم‌ها با خودشون می‌گن آخرش که محسن تصمیم می‌گیره. حس مسئولیت از بین می‌ره. یواش یواش احساس می‌کنن آزادی کافی ندارن و انگیزه‌ی تلاش برای رشد رو از دست می‌دن. دیگه خوش‌حال نیستن و یواش یواش باید دنبال این باشی که چرا کارها به نتیجه نمی‌رسه. منظورم رو می‌فهمی؟شهاب احساس می‌کرد حرف‌های خوبی شنیده اما به مقصد درستی هدایت نشده است. عملکرد مستقل، مسئولیت‌پذیری، و رشد همه چیزهای خوبی به نظر می‌رسیدند. علاوه بر این، نگاه محسن به مدیر به عنوان یک تسهیل‌گر برای او تازگی داشت. پیش از این، تصور شهاب از مدیر، فردی برتر از اعضای تیم بود و به همین علت هدایت تیم به او سپرده شده بود. با در نظر گرفتن نگاه محسن تازه متوجه می‌شد چرا خیمه دو مسیر رشد متفاوت برای افراد طراحی کرده است.با این حال هنوز احساس می‌کرد محسن جایی در مسیر اشتباه رفته و قضاوت نادرستی کرده است. رو به او کرد و گفت: کارها الان هم به نتیجه نمی‌سه. تفاوتش اینه که در مقیاس بزرگ‌تری داریم به نتیجه نمی‌رسیم. این بدتر نیست؟محسن: درسته ولی ما یه گروه ربات سر و کار نداریم. با موجود زنده سر و کار داریم. موجود زنده تغییر وضعیت می‌ده، نظرش عوض می‌شه، خسته می‌شه و هزار و یک اتفاق براش رخ می‌ده که ممکنه اون رو از مسیر خارج کنه. از این جهت مدیریت مثل شونه کردن موهاست. صبح موهات رو شونه می‌کنی و از خونه میای بیرون. باد می‌زنه خرابش می‌کنه، دوباره شونه‌اش می‌کنی. میای محل کار بعد از چند ساعت حالتش رو از دست می‌ده، باز شونه‌اش می‌کنی. شب می‌خوابی صبح بلند می‌شی، باز شونه‌اش می‌کنی. جا انداختن یه رویه بین گروهی از آدم‌ها هم همین شکلیه. تکرار و تکرار و تکرار.تک به تک به پایان رسید اما موقعیت تبدیل به گل نشد. باز هم شهاب به بن‌بست رسیده بود. چیزهای زیادی یاد گرفته بود اما احساس پیش‌رفت نمی‌کرد. در عین حال به نظرش می‌آمد جایی در قضاوت‌های محسن کمبودی هست و یک جای کار می‌لنگد اما نمی‌دانست کجا.تاوانیک روز عادی دیگر در خیمه در حال سپری شدن بود. شهاب خود را در یک منجلاب گرفتار می‌دید. با این حال حس غریبی به او می‌گفت به اندازه‌ی کافی در گیج و سردرگم نشده و هنوز چیزهایی هست که باید بداند. او باید دسته‌ای از مدارک پروژه را که برای رسیدگی‌های مالی لازم داشتند، چاپ می‌کرد. در راهروی شرکت به سمت اتاق تکثیر حرکت می‌کرد که مریم را دید. مریم از سوی دیگر راهرو به سمت مخالف می‌رود. شهاب با خود فکر کرد چاپ کردن این مدارک می‌تواند کمی دیرتر انجام شود. به مریم سمت مریم حرکت کرد و گفت: وقت داری صحبت کنیم؟مریم گفت: درباره‌ی چی؟شهاب: موضوع مهمیه. خیلی وقتت رو نمی‌گیرم.مریم به ساعت خود نگاه کرد و هر دو به سوی رخنه حرکت کردند. وارد اتاق که شدند هر کدام روی یک صندلی روبروی هم نشستند. مریم مثل همیشه آراسته و خوش‌پوش بود. ماهرانه صورتش را آرایش کرده بود. طبق معمول بوی عطرش فضای اتاق را به آرامی پر می‌کرد. تعجبی نداشت که فروشنده‌ی موفقی بود. او تمام اصول ظاهری را برای تحت تأثیر قرار دادن مخاطب خود رعایت کرده بود. اگر موضوع جلسه مهم‌تر نبود می‌شد او را به عنوان یک اثر هنری نگریست و تحلیلی عمیق در انتخاب لباس، کشیده شدن یا نشدن هر خط و سایه، و زبان بدن او ارائه داد. مطمئن نبود صحبت کردن با مریم فایده‌ای داشته باشد اما چیزی برای از دست دادن نداشت. دست کم دقایقی را با یک بانوی باوقار در فضایی خوش‌بو سپری کرده بود.شهاب: مدتیه که کارها با سرعت مناسب پیش نمی‌ره. جلساتی که برگذار می‌کنیم و اقداماتی که می‌کنیم به سمت بهبود نمی‌ره. می‌خواستم ببینم به نظر تو باید چه کار کنیم؟مریم: کی از تو خواسته در این موضوع تحقیق کنی؟شهاب: هیچ کس. خودم کنجکاو بودم.مریم با حس بی‌میلی دوباره نگاهی به ساعت انداخت و پرسید: دیگه با کی صحبت کردی؟شهاب: به سامان و محسن.حالت چهره‌ی مریم تغییر کرد. گویی انگیزه‌ی کافی برای ادامه‌ی صحبت پیدا کرده بود: موضوع ساده است. همه‌ی کارهای ما در نهایت باید منجر به فروش بیشتر بشه. فروش بیشتر یعنی پول بیشتر، یعنی سود بیشتر، یعنی همه برنده‌ایم.شهاب: فکر نمی‌کنم کسی منکر این موضوع باشه. پس چرا کارها پیش نمی‌ره؟مریم: چون اگه عملیات رو به حال خودش رها کنی می‌خواد خودش رو با مشکلات فرضی سرگرم کنه. چون مدیر تیم به جای افزایش سود برای شرکت دنبال تفریحه.شهاب: پیشنهاد تو چیه؟ چطور باید کارها رو پیش ببریم؟مریم: فروش باید در رأس همه‌ی امور قرار بگیره. هر کاری که انجام می‌شه باید اثرش روی سود مشخص باشه. فروش تعیین که چه کاری انجام بشه، چه کاری انجام نشه و اولویت هر چیز چقدره.شهاب: خب تو اگر تصمیم‌گیر باشی چطوری این رو عملی می‌کنی؟مریم: اگر قدرتش رو داشته باشم، تنهایی تصمیم می‌گیرم. اگر نداشته باشم با با دلیل و مدرک سعی می‌کنم بقیه رو قانع کنم.شهاب: حتی با دروغ و جعل مدرک؟برخلاف انتظار شهاب، بدون این‌که به مریم بربخورد با حفظ آرامش پرسید: منظورت چیه؟شهاب: اون روز تو جلسه‌ای که داشتیم تو گفتی مطالعات سارا رو خوندی و ...مریم: بذار یه چیزی رو برات توضیح بدم. شنیدی که می‌گن حق همیشه با مشتریه؟شهاب سر خود را به نشانه‌ی تأیید تکان داد.مریم نگاهی به اطراف انداخت و با صدایی آهسته گفت: این دروغه و فقط یه جمله‌ی تبلیغاتیه.سپس ادامه داد: مشتری خودش هم نمی‌دونه چی می‌خواد. ما موظفیم طوری محصول رو بهش ارائه کنیم که خرید کنه. بعداً ازمون تشکر می‌کنه.شهاب: حتی اگه بهش دروغ بگیم؟! اگه خرید کرد و ناراضی بود چی؟مریم یک بار دیگر به ساعت خود نگاه کرد. از صندلی بلند شد و همین‌طور که از اتاق خارج می‌شد رو به شهاب گفت: اون دیگه مشکل تولید و عملیاته. به من پول می‌دن که فروش رو افزایش بدم. برای رسیدن به یک چیز باید بهاش رو پرداخت کنی. گاهی اوقات بهاش دروغه.مریم اتاق جلسه را ترک کرد. شهاب همین‌طور که روی صندلی نشسته بود به فکر فرو رفت. دردناک، غیراخلاقی و غیرانسانی به نظر می‌رسید اما درست بود. در نهایت اگر سودی نبود، خیمه‌ای هم نبود. با این حال نمی‌توانست رسیدن به هدف را با هر قیمتی بپذیرد. علاوه بر این بر خلاف ابتدای جلسه که مریم جذاب و حرفه‌ای به نظر می‌رسید اکنون جلوه‌ی خود را از دست داده بود. شهاب حسی آمیخته از ترس و بی‌میلی برای مشورت دوباره با او داشت. چه اتفاقی در جلسه افتاده بود که نظر شهاب را تغییر داده بود؟ هیچ‌کدام از این‌ها ادامه‌ی مسیر را برای شهاب روشن‌تر از پیش نمی‌کرد. در قعر چاهی که برای خود کنده بود، عمیق‌تر از پیش فرو رفته بود. سید مرتضی هاشمی سید مرتضی هاشمی Wed, 23 Oct 2024 17:10:15 +0330 https://virgool.io/@atomerz/%D8%AA%D8%B5%D9%85%DB%8C%D9%85-%D9%87%D8%A7%DB%8C-%D9%86%D8%A7%D9%BE%DB%8C%D8%AF%D8%A7-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-cpwcq2na0zld سفری ذهنی در کشف انگیزه‌ها و شکل‌دهی به تصمیم‌های جمعیفصل اول: تلنگردور بی‌پایانصدای ناشناس اول: ... پیشنهاد من افزایش بودجه‌ی تبلیغاته ...صدای ناشناس دوم: ... باید بررسی بیشتری کنیم و هنوز اطلاعات کافی نداریم ...صدای ناشناس سوم: بی‌خودی پیچیده کردید مسأله رو. یه کم فکر کنید همه چیز واضحه! محصول ایراد فنی داره و باید روی کیفیت تمرکز کنیم.صدای ناشناس اول: با این حال از پارسال تا الان هیچ تبلیغی انجام نشده و این هم در موضوع مؤثره.صدای ناشناس سوم: اهمیتی نداره. تبلیغ برای چیزی که کار نمی‌کنه کار رو بدتر می‌کنه.صدای ناشناس دوم: من داده‌ی کافی برای تصمیم‌گیری ندارم.صدای ناشناس سوم: چه داده‌ی بیشتری نیازه؟! سرمون رو مثل کبک کردیم زیر برف. همین دیروز حادثه داشتیم و خسارت دادیم!صدای ناشناس اول: این نشون از عملکرد بد تیم عملیاته. باید بودجه‌ی عملیات رو کم کنیم و به تبلیغات تزریق کنیم.صدای ناشناس چهارم: به نظر میاد اتفاق نظر نداریم. وقت جلسه هم تموم شده. بعداً در این موضوع تصمیم می‌گیریم.شهاب، پشت میز خود نشسته و به ظاهر مشغول به کار است. اما عمیقاً در فکر فرو رفته. در ذهن خود به جلسه‌ای که گذشت فکر می‌کند. برای او واضح است که نظر سامان درست است و راه‌حلی که ارائه می‌دهد پاسخ مناسب به مسأله است.چرا نظر سامان پذیرفته نشد و به اجماع نرسیدند؟ چرا فقط شهاب به این نتیجه رسیده بود؟ آیا بقیه به اندازه‌ی شهاب تسلط به مسأله نداشتند؟ درک و استعدادشان کم‌تر بود؟ چه چیزی مانع شد که بقیه هم به همین نتیجه برسند؟استاد بداخلاقشهاب پشت میز خود نشسته و غرق در کار است. او با مسأله‌ای پیچیده روبروست که برای حل آن نیاز به تمرکز و دقت زیادی دارد. محیط کار او اتاقی است که یک تیم نسبتاً بزرگ در آن مشغول به کار است. در اتاق ۱۲ میز در سه گروه ۴ تایی به شکلی خاص در کنار هم قرار گرفته‌اند. درب ورودی معمولاً باز است تا با رفت و آمد افراد نیاز به باز و بسته کردن آن نباشد و سر و صدا ایجاد نکند. صدای کوبیده شدن کفش‌هایی پاشنه بلند روی کف سنگی اتاق شنیده می‌شود که از دور نزدیک می‌شود. زنی آراسته، پوشیده در کت و دامنی مشکی‌رنگ به میز شهاب نزدیک می‌شود.- سلام شهاب- سلام مریم، صبح به خیرمریم بدون این‌که متوقف شود سری به نشانه‌ی پاسخ تکان می‌دهد و به سمت میز خود می‌رود. بوی مطبوع عطری که بر تن دارد مثل ردپای یک غزال در مسیری که از آن می‌گذرد به جا مانده و در اتاق پخش می‌شود. او یک دانشجوی دکتری است که تصمیم دارد بعد از فارغ‌التحصل شدن به عنوان استاد دانشگاه تدریس کند. در عین حال می‌داند که حقوق دانشگاه برای گذران مخارج زندگی کافی نیست. به همین علت علاوه بر پیگیری مسیر علمی به دنبال کسب تجربه و کار در صنعت هم هست. همین مسیر او را به خیمه آورده و کنار شهاب قرار داده است. «خیمه‌گستران فناور» نام شرکتی است که هر دو در آن کار می‌کنند اما کسی آن را به این نام صدا نمی‌کند. برای راحتی همه به آن خیمه می‌گویند. مریم پشت میز خود نشیند و به مرور بقیه اعضای تیم هم وارد می‌شوند.نزدیک به ظهر شهاب که هنوز عمیقاً مشغول به کار است به ایده‌ای برای حل مسأله می‌رسد. برای عملی کردن ایده و پیش‌بردن کار تغییرات مورد نظرش را در مستندات اعمال می‌کند. روال کار در خیمه این است که کارهای تک نفره انجام نمی‌شوند. معمولاً یک نفر کار را پیش می‌برد و دیگری آن را بازبینی می‌کند تا از اشتباه و سهل‌انگاری جلوگیری شود. بر همین اساس شهاب مستندات را از طریق ایمیل برای به سامان می‌فرستد تا مورد بازبینی قرار بگیرد. سامان از قدیمی‌های خیمه است و فردی با تجربه و در عین حال جدی است. شهاب برای نظر او احترام زیادی او قائل است و به چشم یک استاد به او نگاه می‌کند. فرایند بازبینی فرصت خوبی است که شهاب از تجربه و تسلط سامان استفاده کند و از او یاد بگیرد.زمان نهار فر می‌رسد و اعضای تیم یک به یک اتاق را به مقصد سالن نهار ترک می‌کنند. شهاب بعد از صرف نهار به اتاق بر می‌گردد و به کار خود ادامه می‌دهد. پس از چند دقیقه سامان او را صدا می‌زند. میز شهاب در گروه ۴ تایی میانی، رو به در ورودی و قرار دارد. سامان در همان گروه، پشت سر شهاب می‌نشیند. شهاب روی صندلی خود می‌چرخد و به سمت میز سامان حرکت می‌کند تا با او صحبت کند.- چرا این قسمت از سند رو تغییر دادی؟+ به این خاطر که...- مرض داشتی؟!شهاب شوکه می‌شود اما این حرف را نشنیده می‌گیرد و توضیح می‌دهد چرا به نظر او نیاز به تغییر وجود داشت. در نهایت با چند دقیقه صحبت کردن این مورد برطرف می‌شود و بازبینی به پایان می‌رسد. در این مورد خاص تصمیم درست بود اما موارد دیگری بود که نیاز به تغییر داشت و تصمیم اشتباهی گرفته شده بود. در نهایت نتیجه‌ی کار با بازبینی، کامل‌تر و بهتر از قبل بود و بازبینی سامان کار را به سمت بهبود پیش برده بود.شهاب پشت میز خود برگشت و شروع به اعمال اصلاحات و ادامه‌ی کار کرد. ناگهان در ذهنش چراغی روشن شد. جلسه‌ی روز پیش را به خاطر آورد. صحبت‌های جلسه را در ذهن خود مرور کرد. در آن جلسه هم سامان برخورد سرسختانه‌ای با نظرات سایرین داشت و قاطعانه و محکم مخالفت می‌کرد. علاوه بر این مثل صحبتی که گذشت گاهاً کلمات نامناسبی استفاده کرده بود. اما در نهایت اگر از این موارد عبور کرده و به محتوای صحبت‌ها پرداخته می‌شد، حرفی که می‌زد درست بود و راه‌حلی که ارائه می‌کرد کم‌ترین هزینه را داشت. راه‌حل بقیه یا به نتیجه نمی‌رسید یا هزینه‌ی بیشتری داشت.تیم‌سازیصبح سه شنبه شهاب خانه را به مقصد پارک آب و آتش ترک کرد. قرار بود همه‌ی اعضای تیم یک روز را خارج از شرکت تحت عنوان تیم‌سازی سپری کنند. هدف این بود که در فضای غیر رسمی و غیر کاری با هم تعامل کنند، یکدیگر را بهتر بشناسند تا در نهایت بتوانند بهتر در کنار یکدیگر کار کنند. تیم‌سازی‌ها معمولاً توسط محسن تدارک دیده می‌شد. محسن مدیر تیم بود. برای او مهم بود که اعضای تیم حس و حال خوبی داشته و با هم ارتباط نزدیک و سالمی داشته باشند.قرار برای ساعت ۹ به صرف صبحانه بود. پس از آن یک فعالیت گروهی تدارک دیده شد بود که همه در آن شرکت می‌کردند. طبق معمول هیچ جمعی بزرگ‌تر از یک نفر سر وقت در یک مکان جمع نمی‌شود و بچه‌های خامه (نام تیمی که شهاب در آن کار می‌کرد) هم از این قاعده مستثنی نبودند. البته خب ترافیک تهران هم بی‌تأثیر نبود ولی غیر قابل پیش‌بینی بود! بالاخره اعضای تیم با تأخیر کم‌تر و کمی بیشتر در رستوران حاضر شدند و صبحانه‌ای مشتی به رگ زدند و پر انرژی آماده‌ی مرحله‌ی بعد بودند.برای فعالیت گروهی یک بازی رومیزی به نام مونوپولی پیش‌بینی شده بود. به طور خیلی خلاصه هر بازیکن در این بازی با تاس انداختن روی صفحه‌ی بازی حرکت می‌کند، می‌تواند مِلک بخرد و اگر وارد ملک دیگری شود باید به او اجاره دهد. استراتژی‌های متفاوتی برای بازی وجود دارد. در ظاهر موفقیت بازی تک‌نفری است اما مکانیزم‌هایی مثل معامله با سایر بازیکن‌ها وجود دارد که آن را پیچیده‌تر و جذاب‌تر می‌کند.هر یک از اعضای تیم یک مهره انتخاب کردند و به قرعه ترتیب انداختن تاس را تعیین کردند. بازی شروع شد و به مرور ملک‌ها بین بازیکن‌ها تقسیم شد تا جایی که دیگر چیزی برای خریدن وجود نداشت. در این مرحله بازیکن‌ها مجبور به معامله با یکدیگر بودند تا بتوانند منابع بیشتری برای خود کسب کنند. این‌جا بود که سامان تصمیم گرفت با مریم وارد معامله شود. پیشنهاد سامان پیشنهاد عادلانه‌ای بود و در نهایت باعث می‌شد که هر دوی آن‌ها از سایر بازیکنان پیشی بگیرند. با این‌حال مریم حاضر به معامل نبود و در نهایت با این جمله صحبت را خاتمه داد:- اصلاً من هیچ معامله‌ای با تو ندارم!گفتگو در این‌جا قطع شد و بازی ادامه پیدا کرد. این‌باز شهاب می‌دانست که موضوع چیست. او در ذهن خود مریم را به خاطر مهارت کمی که در به کارگیری منطق و استدلال داشت، سرزنش می‌کرد. چند تاسی پرتاب شد و این‌بار سامان به شهاب پیشنهادی برای معامله داد. این معامله هم معامله‌ی جذاب و به نفع طرفین بود. اما شهاب تصمیم داشت برنده شود و برای این‌کار باید مطمئن می‌شد که نفع او در این معامله بیشتر است. در حال سبک سنگین کردن معامله در ذهن خود بود که این تعلل کاسه‌ی صبر سامان را سرریز کرد:- عن‌بازی در نیار دیگه!شهاب این بار هم شوکه شده بود. اما این‌بار حس متفاوتی داشت و نمی‌توانست از شنیدن این حرف صرف نظر کند. تا همین چند لحظه پیش مریم را سرزنش می‌کرد. چه چیزی تغییر کرده بود که او هم استعداد و مهارت استدلال خود را از دست داده بود؟ بازی در جریان بود و وقت برای فکر کردن به این سوال نداشت. تصمیم گرفت با سامان معامله نکند و بازی ادامه پیدا کرد. در نهایت محسن برنده‌ی بازی شد اما این برای شهاب اهمیتی نداشت. ذهن او درگیر مسأله‌ی مهم‌تری شده بود.امروز صبح که شهاب از خانه بیرون آمده بود انتظار داشت در یک فضای دوستانه ساعات خوشی را در کنار خامه‌ای‌ها بگذراند. تأخیر بعضی از بچه‌ها در رسیدن به صبجانه هر چند ناخوشایند بود اما اصل فعالیت را زیر سوال نبرده بود. در مقابل برخورد سامان با شهاب در این شرایط نقض غرض بود. شهاب در آن لحظه به دنبال درست‌ترین و منطقی‌ترین تصمیم نبود. صرفاً داشت در کنار اعضای تیمش ساعات خوشی را سپری می‌کرد. این‌که در این بازی برنده می‌شود یا نه در درجه‌ی کم‌تری از اهمیت قرار داشت.امروز اگر شهاب در بازی برنده نمی‌شد هیچ اتفاق بدی رخ نمی‌داد. اگر برنده می‌شد هم اتفاق خاصی نیفتاده بود. این شرایط با یک روز عادی کاری متفاوت بود. در آن شرایط یک تصمیم‌گیری بد و یا اشتباه در اجرا می‌توانست خیمه را تا مرز ورشکستگی پیش ببرد. برای همین تصمیم‌گیری درست در اولویت قرار داشت.پایان یک دوریک روز کاری دیگر در خیمه در حال سپری شدن است. شهاب پشت میز خود و طبق معمول عمیقاً در حال کار است. پشتی صندلی خود را خوابانده و خود را داخل میز فرو برده. برای تمرکز بیشتر هدستی بر گوش دارد و به موسیقی ملایم گوش می‌دهد. در همین حال و حواست که ناگهان صدای اعلان در گوش او پخش می‌شود. زمان یک جلسه فرا رسیده و باید میزش را به مقصد دخمه ترک کند. دخمه نام یک اتاق بزرگی است که برای جلسات اختصاص داده شده است. منابع انسانی علاقه‌ی خاصی به نام‌گذاری تک تک اتاق‌های جلسات دارد!همه‌ی افرادی که باید در جلسه حاضر می‌شدند خود را به دخمه رسانده‌اند: مریم متخصص فروش، سامان، شهاب، و سارا متخصصین عملیات، و محسن مدیر تیم. موضوع، ادامه‌ی جلسه‌ی پیش بود که بی‌نتیجه رها شده بود. محسن در ابتدای جلسه مروری بر آن‌چه گذشت می‌کند. در ادامه از سارا می‌خواهد نتیجه‌ی بررسی‌هایی که انجام داده را ارائه کند. سارا فردی منظم، آرام و خجالتی که تا از او سوالی پرسیده نشود صحبت نمی‌کند. او با صدای کم شروع به صحبت می‌کند طوری که شهاب متوجه صحبت‌های او نمی‌شود اما چیزی نمی‌گوید. در همین حال سامان حرف سارا را قطع می‌کند: «صدات نمیاد. بلندتر صحبت کن». شهاب با خود می‌گوید هرچند حرف سارا (در واقع تصویر سارا، چون، صدایی شنیده نمی‌شد) قطع شد اما بهتر از این بود که وقت جلسه به بطالت بگذرد. در نهایت سارا باید حرفش را تکرار می‌کرد.سارا: من داده‌های مربوط به حوادث رو بررسی کردم و در یک گزارش ثبت کردم. از طرفی یک پرسش‌نامه در شبکه‌های اجتماعی منتشر کردیم و از نتایج تحلیلش رو هم در گزارش دیگه‌ای آوردیم.سامان: خب نتیجه؟ الان چه کنیم؟سارا: نمی‌دونم. مطمئن نیستم.مریم: قبلاً هم گفتم مشکل فروش و تبلیغاته. من گزارش‌ها رو خوندنم. ما همین الان هم تو ضرر هستیم و چاره‌ای جز افزایش فروش نداریم.محسن: سارا جان فایل‌های گزارش‌ها رو باز می‌کنی که بتونیم یه نگاهی به نتایج بندازیم؟سارا لپ‌تاپ خود را به پروژکتور وصل کرد و جداول مربوط به نتایج را به اشتراک گذاشت. همان‌طور که از سارا انتظار می‌رفت یک بررسی کامل با تحلیل موشکافانه انجام شده بود. در کمال تعجب در قسمت نتایج جداولی بود که به وضوح نشان می‌داد اولاً محصول پایدار است و مشکل کیفی وجود ندارد و دوماً آگاهی مشتریان از محصول کاهش یافته با نیاز به سرمایه‌گذاری بیشتر وجود دارد.محسن: خب به نظر میاد که حق با مریمه و سامان اشتباه می‌کرد.مریم: بله. من که گفتم مشکل تبلیغاته!سامان: اما به دروغ!مریم که واضح بود احساس کرده به او توهین شده کمی مکث کرد. سپس به حالت اعتراض گفت: یعنی تبلیغات نیست؟!سامان: تبلیغات هست. اما نه به این دلیل که ضررده هستیم. داده‌ها این رو نشون نمی‌ده. داده‌ها می‌گه آگاهی پایینه. بنابراین موافقم که باید روی تبلیغات کار کنیم.مریم: تو که جلسه‌ی پیش گفتی کیفیت پایینه. پس چرا نظرت عوض شد؟سامان: درسته. اما الان اطلاعات بیشتری داریم. اگه نظرم عوض نشه احمقم!محسن: فکر کنم بحث دیگه کافیه. کیا موافقن که بودجه‌ی تبلیغات افزایش پیدا کنه؟سامان: یعنی رأی بگیریم؟!محسن: بله.سامان: وقتی همه چیز روشنه چرا باید رأی بگیریم؟ الان اگه اکثریت بگه نه تو نتایج تحقیق رو نادیده می‌گیری؟!محسن کمی مکث کرد. بعد انگار که جرقه‌ای در ذهنش خورده باشد گفت: «آهان! نه منظورم اینه که اگر کسی مخالفه توضیح بده.»سامان چیزی زیر لب زمزمه کرد اما کسی متوجه نشد چه گفت و کسی هم نپرسید. شهاب دو کلمه‌ی «ترسو» و «میانگین» را تشخیص داد. با این‌که کسی چیزی نگفت جلسه با نتیجه‌ی مشخص به پایان رسید.جلسه تمام شده بود اما شهاب با خود فکر می‌کرد که چقدر اتفاق عجیب در این جلسه افتاد. چرا سارا در پاسخ به این سؤال که چه کنیم گفت نمی‌دانم؟ در حالی که همه چیز در نتایج بررسی‌ها مشخص شده بود و او می‌دانست. چرا سامان به جای این‌که بگوید مریم اشتباه کرده گفت او دروغ گفته؟ چرا محسن تصمیم به رأی‌گیری گرفت اما در نهایت نه رأی‌گیری کرد و نتیجه را واضح اعلام کرد. منظور سامان از ترسو که بود و میانگین چه چیزی؟تعطیلاتصبح یک روز اسفند ماه بود. سرمای زمستان آخرین تلاش‌های خود برای نگه داشتن شهاب در تخت خواب می‌کرد. صدای زنگ ملایم گوشی که برای ساعت ۸ صبح تنظیم شده بود شهاب را از خواب بیدار کرد. پس از دوش صبح‌گاهی و صرف صبحانه، شال کلفتی به گردن انداخت و به سوی ایستگاه مترو روانه شد. یک لیوان قهوه‌ی داغ در ایستگاه خرید و آرام آرام شروع به نوشیدن آن کرد. وقتی قطار از راه رسید قهوه تمام شده بود و سلول‌های مغز شهاب در حال بیدار شدن بود.تعطیلات سال نو نزدیک بود. معمولاً ابتدای هر سال شرکت‌ها به دنبال دولت افزایش حقوق‌های دولتی در پرداختی‌های خود بازنگری می‌کنند. خیمه هم از این دسته مستثنی نبود. علاوه بر این خیمه روال دیگری برای رشد و ارتقا گرفتن افراد در سازمان طراحی کرده بود. در بازه‌های زمانی مشخصی در سال این امکان وجود داشت که افراد درخواست‌های خود برای ارتقأ را به کمیته‌ی مربوطه ارسال کنند تا بررسی شود. یکی از این بازه‌ها بعد از تعطیلات سال نو بود که در حال نزدیک شدن بود.در خیمه دو مسیر جداگانه برای رشد افراد در نظر گرفته شود بود. یک مسیر کمک به توسعه‌ی محصول از طریق مدیریت و سرپرستی افراد دیگر بود. مسیر دوم افزایش بهره‌وری، اتکاپذیری یا مواردی از این قبیل بود که خبرگی و رشد فنی را نشان می‌داد. در نتیجه ذهن شهاب با این سؤال روبرو شده بود که می‌خواهد کدام مسیر را پیش بگیرد. همین‌طور که دستش را از دستگیره‌ی قطار آویزان کرد بود تا ترمزهای ناگهانی راننده او را زمین نزند با این سوال هم دست و پنجه نرم می‌کرد. وقتی به ایستگاه مقصد رسید و از زیر فشار جمعیت بیرون آمد ناگهان به ذهنش رسید درباره‌ی این موضوع با سامان صحبت کند. به هر حال او چهار تا پیراهن بیشتر از شهاب پاره کرده بود. علاوه بر این او هم در مسیر شهاب قدم برداشته بود و حتماً در یک مقطع با همین سؤال مواجه شده بود. به شرکت که رسید در فرصتی مناسب با سامان صحبت کرد و از او مشورت خواست.اسفند ماه تمام شد و تعطیلات سال نو از راه رسید. هر سال این موقع شهاب به زادگاه خود برمی‌گشت و تا با خانواده دیدار کند. به شیراز رسید و در خانه‌ی پدری عید را در کنار خانواده گذراند. با وجود این‌که باید از تعطیلات لذت می‌برد همچنان ذهنش مشغول تصمیمی بود که باید می‌گرفت. سر سفره‌ نهار در همین فکرها بود که پدرش گفت:‌‌ «پسر کجایی؟ عاشق شدی؟» شهاب لبخندی زد و گفت:‌ «نه. یه موضوع کاریه.» بعد با خود گفت پدر هم چند پیراهنی از من بیشتر پاره کرده خوب است با او هم مشورت کنم.بعد از نهار موضوع را با او در میان گذاشت. پدر شهاب فرد تحصیل کرده‌ای نبود. او آدمی سخت‌کوش و اجتماعی بود که با طیف مختلفی از آدم‌ها و محیط‌ها کار کرده بود. وقتی شهاب موضوع را مطرح کرد پدر بی‌درنگ او را به ادامه‌ی مسیر در سمت‌های مدیریتی تشویق کرد. او توضیح داد که رشد کردن در سازمان‌ها همیشه به همین شکل سلسله مراتبی است و برای رشد کردن باید در همین مسیر قدم برداری. وقتی شهاب در مورد مسیرهای متفاوت رشد در خیمه توضیح داد، پدر تعجب کرد و به حرف خودش ادامه داد. در نهایت شهاب گفت اما سامان طور دیگری فکر می‌کند. پدر در جواب گفت: «من خیر رو تو بیشتر می‌خوام یا سامان؟!» شهاب که این را شنید چیز بیشتری برای گفتن نداشت. حق با پدر بود. هیچ کس بیشتر از او خیر شهاب را نمی‌خواست.تعطیلات عید تمام شد و شهاب به کار برگشت. بازه‌ی ارزیابی نزدیک شده بود اما او هنوز نتوانسته بود تناقض‌های ذهنی‌اش را حل کند. از طرفی پدرش خیر او را می‌خواست و سامان هیچ انگیزه‌ای در پیشرفت یا عدم پیشرفت او نداشت. از سوی دیگر حرف‌های سامان با واقعیت‌های پیش رو مطابقت بیشتری داشت.ارتقاءدر نهایت شهاب تصمیم گرفت در این مقطع مسیر مدیریت و سرپرستی را دنبال نکند. در سالی که گذشت، اتفاقات مهم‌تری برای او رخ داده بود. شهاب به مرور متوجه شده بود که هر یک از خامه‌ای‌ها در تصمیم‌گیری و تصمیم‌سازی انگیزه‌هایی دارد که آن را برای سایرین شفاف نمی‌کند. او متوجه شده بود که شیوه‌ی گفتگوی یک شخص می‌تواند باعث شود محتوای صحبت‌های او نادیده گرفته شود، حتی اگر این موضوع در نهایت به ضرر خیمه باشد. او متوجه شده بود که فقط صداهای بلند شنیده می‌شود اما همه‌ی چیزهای مهم توسط صداهای بلند مطرح نمی‌شود. برای دانستن دانستنی‌ها باید راهی برای شنیدن همه‌ی صداها پیدا کرد. او فهمیده بود که حسن نیت برای رسیدن به نتیجه کافی نیست. همچنین فهمیده بود رسیدن به نتیجه همیشه لازم نیست. اما چیزهای دیگری هم بود که باید می‌فهمید.شهاب کوله‌باری از تجربه در تعامل با خامه‌ای‌ها داشت که متناقض می‌نمود. به نظر می‌آمد گاهی تصمیم‌هایی گرفته می‌شود که با تصمیم‌های قبلی در تعارض هستند. گاهی اوقات تصمیمی گرفته می‌شد که پیامدهای آن گفته شده بود اما وقتی آن‌چه گفته شده بود رخ می‌داد جلسه‌ای برای عیب‌یابی مسأله تشکیل می‌شد. اغلب جلسات طولانی و تصمیم‌گیری‌ها به تعویق می‌افتاد. چرا خامه در این وضعیت گیر افتاده بود و کند پیش می‌رفت؟ هرچند شهاب مسیر رشد خود را بر اساس افزایش خبرگی و رشد فنی تعریف کرده بود اما چالش دیگری هم در ذهن داشت. او ارتقاء خود را در کشف علت این ناکارآمدی و برطرف کردن آن می‌دید.گرگ و میشناگهان چشم‌هایش را باز کرد. دیگر احساس خواب‌آلودگی نداشت. نمی‌دانست ساعت چند است. از پنجره که بیرون را نگاه می‌کرد هوا روشن نشده بود اما تاریک هم نبود. به بدنش کش و قوسی داد و از تخت بیرون آمد. پای پنجره رفت تا از منظره لذت ببرد. هوای دلپذیر صبح‌گاهی آرام آرام ذهنش را بیش از پیش بیدار می‌کرد. هوا نه تاریک بود و نه روشن، تاریک روشن بود، چیزی بود میان این دو، گرگ و میش بود.از پشت پنجره به سمت آشپزخانه رفت. شیر آب را باز کرد. کتری را پر کرد و روی گاز گذاشت. شعله‌ی زیر آن را روشن کرد و به آن خیره شد. همه جا سکوت بود و صدای شعله‌ی گاز به وضوح شنیده می‌شد. با گذشت زمان آب سرد داخل کتری گرم‌تر می‌شد. آرام آرام صداهای دیگری شنیده می‌شد. آب ولرم شده بود. هر چه می‌گذشت صداها شدت می‌گرفت. شهاب می‌دانست که آب گرم شده است اما هنوز به نقطه‌ی مطلوب نرسیده است. در یک لحظه ناگهان شدت صداها بیشتر شد. صدای قل قل آب واضح بود. آب جوش آمده بود. یک فنجان قهوه آماده کرد و پشت پنجره برگشت. هوا دیگر روشن شده بود. همین‌طور که اولین جرعه‌ی قهوه را می‌نوشید چراغی در ذهنش روشن شد: گرگ و میش! ولرم!دوش صبح‌گاهی را که گرفت، لباس‌هایش را پوشید و به سمت ایستگاه مترو حرکت کرد. ایستگاه شلوغ‌تر از معمول بود. از آن مواقعی که کافی است جلوی در قطار بایستی و خود به خود توسط جمعیت پیاده و سوار می‌شوی. همان‌طور که پیش‌بینی می‌کرد وقتی قطار از راه رسید، جمعیت او را سوار کرد. واگن به حدی پر بود که آدم‌ها تن به تن یکدیگر ایستاده بودند. حتی جایی روی میله‌ها باقی نمانده بود که دستش را به آن بگیرد. البته نکته‌ی مثبتش این بود که نیازی به دستگیره هم نبود، چون جایی برای لغزیدن وجود نداشت.همین‌طور که قطار به سمت مقصد در حرکت بود شهاب در فکر عمیقی فرو می‌رفت. صبح که از خواب بیدار شده بود و هوای بیرون را می‌دید می‌دانست هوا نه روشن است و نه تاریک اما چرا در توصیف آن تعلل کرده بود؟ علتش این نبود نمی‌دانست هوا روشن است یا تاریک، او دقیقاً می‌دانست در مقابل خود چه می‌بیند. با خود اندیشید که او عادت کرده روشنایی هوا را با یکی از این دو حالت توصیف کند. در این زمانه کسی دیگر از گرگ و میش استفاده نمی‌کند. آخرین باری که او این کلمه را شنیده بود احتمالاً در آزمون ادبیات دوره‌ی راهنمایی بود. بعد با خود اندیشید که اگر این کلمه را نمی‌دانست احتمالاً ناخودآگاه یکی از حالات تاریک یا روشن را برای توصیف آن انتخاب می‌کرد. فضای بین تاریکی و روشنایی یک حالت دوگانه نیست. گستره‌ای است که بی‌نهایت نقطه میان آن قرار دارد. اما در ذهن او کلماتی برای توصیف این نقاط وجود نداشت. در مورد میزان گرمای آب هم به همین شکل بود. اما این بار او کلمات بیشتری برای توصیف حالت‌های میانی داشت. این باعث شده بود در تشخیص و توصیف هر حالت تعلل نکند. قطار به مقصد رسیده بود و فشار کافی برای پیگیری رشته‌ی افکارش به او وارد نمی‌شد. باید تا پایان ساعت کاری صبر می‌کرد.روز کاری که تمام شد به سمت ایستگاه مترو شتابید و خود را لابلای جمعیت در واگن قطار چپاند. طبق انتظار فشار وارد شده به او باعث شد بتواند رشته‌ی افکارش را از سر بگیرد. شهاب متوجه شده بود که افراد مختلف در ارزیابی صحبت‌های دیگران چیزهای متفاوتی را اندازه می‌گیرند. برخی درستی یک چیز را می‌سنجند. برخی لحن مخاطب را می‌سنجند. گاهی خیرخواهی گوینده را مد نظر قرار می‌دهند و سایر مواقع سود و ضرر شخصی را اندازه می‌گیرند. فارق از این‌که سنجیدن کدام‌یک از این‌ها مفیدتر است معمولاً نتیجه‌ی قضاوت ما تعیین یک وضعیت بین دوگانه‌هاست. برای مثال، یک عبارت یا به سود من است یا به ضرر من، لحن یک نفر یا مناسب است یا نامناسب و ... در برخی از این موارد وقتی آگاهانه به موضوع فکر کنیم می‌دانیم این قضاوت ساده شده است اما خیلی اوقات از وجود پیچیدگی و گستره‌ها آگاه نیستیم. جالب این‌جاست که مستقل از آگاهی داشتن یا نداشتن وقتی گرم گفتگو هستیم معمولاً از همین قضاوت‌های دوگانه‌ی بدوی استفاده می‌کنیم. در نهایت وقتی می‌خواهیم از یک گفتگو نتیجه بگیریم، چون قضاوت‌های ساده شده‌ای در مورد گفته‌ها داریم ممکن است به نتیجه‌ی اشتباه برسیم.شهاب مشاهداتی که از سامان داشت را به خاطر آورد. او در گفتگو صریح بود اما گاهی از کلماتی استفاده می‌کرد که توهین‌آمیز بود. برای مثال، آن‌چه او در تیم‌سازی گفته بود به وضوح در دسته‌ی توهین‌آمیز بودن قرار می‌گرفت اما وقتی حرف سارا را قطع کرده بود قضاوت به این سادگی نبود. شهاب با خود اندیشید که اگر بنا بر قضاوت‌های ساده‌ی دوگانه باشد، این کار هم در دسته‌ی توهین آمیز قرار خواهد گرفت. وقتی به اندازه‌ی کافی مشاهدات توهین آمیز داشته باشیم نتیجه‌ی یک جلسه با حالتی که این مشاهدات را درست جایابی کنیم متفاوت خواهد بود. شنیدن حرف‌های کسی که صریح است ولی بی‌ملاحظه از تحمل یک آدم بی‌ادب که دائماً توهین می‌کند راحت‌تر است.باز قطار به مقصد رسیده بود و با رها شدن شهاب از زیر فشار جمعیت، او انگیزه و توان خود برای ادامه‌ی فکر عمیق را از دست داده بود. اما این بار او به حکمت تازه‌ای رسیده بود. پیش از این او برخی ابعاد حقیقت‌سنجی را کشف کرده بود. اکنون وجود و اهمیت یک گستره در هر بعد را درک می‌کرد. بیش از این نیازی به تحت فشار گذاشتن خود در مترو احساس نمی‌کرد و احساس می‌کرد. در روزهای شلوغ دیگر می‌توانست از تاکسی استفاده کند.نمای ۱۰هزار پاییصبح یک روز دیگر شهاب در مسیر شرکت بود. این بار او با خودروی شخصی به محل کارش می‌رفت. بر خلاف مردم عادی که شب‌ها موقع خواب تعداد گوسفندها را می‌شمارند، این تفریح زمان روز او بود. همین‌طور که در حال شمار بود «پنج، شش، هفت! هـــــــــفت!» به چراغ قرمز نزدیک می‌شد. چراغ از سبز به زرد تغییر کرد و «هشت...» او که می‌دانست چراغ زرد هم برای کسانی که از آن عبور نکرده‌اند حکم چراغ قرمز را دارد. پشت خط عابر متوقف شد. پس از سبز شدن چراغ راهنما مسیر خود را ادامه داد و وارد بزرگ‌راه ذلت شد. بر خلاف انتظار ترافیک سنگین نبود و می‌توانست با ساعت مسیر را طی کند. در قسمتی از مسیر به یک پل نزدیک می‌شد. همچنان مسیر خلوت بود و او با سرعت به پیش می‌رفت. به بالاترین نقطه‌ی پل که نزدیک می‌شد ناگهان سقف یک ماشین نمایان شد و خیلی زود مشخص شد که در آن سوی پل ترافیک سنگین است.سرعت او زیاد بود و فاصله‌ی او با اولین ماشین روبرو به در حال کم شدن. پایش را روی ترمز فشرد اما نه به حدی که ماشین سر بخورد. سرعت بیش از آن بود که به ماشین پیش رو برخورد نکند. در خط سمت راست ماشین‌ها مقدار بیشتری پیش‌رفته بودند. فرمان را به سمت راست پیچاند. سرعت ماشین هنوز زیاد بود و اگر با سرعت تغییر مسیر می‌داد ماشین واژگون می‌شد اما او ناخودآگاه می‌دانست چه مقدار از تغییر مسیر در این سرعت امکان‌پذیر است. ماشین در آخرین لحظات در خط سمت راست قرار گرفت. سرعت در حال کم شدن بود اما هنوز هم امکان برخورد به خودروی جلویی وجود داشت. فشردن بیشتر پدال ترمز باعث سر خوردن ماشین می‌شد اما دیگر چاره‌ای نبود. در نهایت با برخوردی نرم با خودروی جلویی ماشین متوقف شد. تمام این اتفاقات در یک بازه‌ی چند ثانیه‌ای رخ داد.به شرکت که رسید در میز خود فرو رفت. از قضا امروز باید روی نقشه‌ی مسیرهای رانندگی در شهر کار می‌کرد. با خود فکر کرد که نقشه چیز جالبی است. گویی که از سطح زمین فاصله گرفته باشی و از آسمان به آن نگاه کنی. با این تفاوت که نقشه در عین این‌که نشان‌دهنده‌ی واقعیت هست، نشان‌دهنده‌ی واقعیت نیست. نقشه‌ی مسیرهای رانندگی روی مسیرهای قابل عبور توسط خودروها تمرکز دارد و چیزی جز آن را نشان نمی‌دهد. درخت‌ها، خانه‌ها، خودروهای داخل خیابان و ... همه و همه حذف شده‌اند. به عبارتی نقشه آن‌قدر از واقعیت حذف کرده و آن را ساده‌سازی کرده تا برای یک هدف مشخص خوب عمل کند: مسیریابی. یک راننده با در دست داشتن نقشه می‌تواند در زمان کوتاه مسیری برای رسیدن از یک نقطه به نقطه‌ی دیگر پیدا کند. به عبارت دیگر نقشه با حذف بخشی از واقعیت سرعت تصمیم‌گیری را افزایش می‌دهد.با خود فکر کرد امروز صبح که از یک تصادف شدید گریخته بود، اتفاق مشابهی افتاده بود. او توانسته بود مجموعه‌ای از تصمیم‌ها را در زمانی کوتاه بگیرد. آیا در آن‌جا هم بخشی از واقعیت نادیده گرفته شده بود؟ آیا وقتی در لحظه‌ی اول تصمیم گرفت پدال را با تمام قدر نفشرد تصمیم درستی گرفته بود؟ آیا واقعاً با فشردن پدال ماشین سر می‌خورد؟ آیا این سر خوردن باعث می‌شد ماشین در زمان مناسب متوقف نشود؟ آیا وقتی تصمیم به تغییر مسیر به راست داد مطمئن بود که خودروی دیگری پشت سر او نیست؟ آیا وقتی در نهایت تصمیم گرفت به قیمت سر خوردن ماشین با تمام قدرت پدال را فشار دهد کار درستی کرده بود؟ او جواب قطعی برای هیچ یک از این سوال‌ها نداشت. در زمان حادثه فرصت کافی برای پاسخ دادن به این سوال‌ها هم نداشت و مجبور به انتخاب بود.در نهایت این ساده‌سازی‌ها و نادیده گرفتن‌های بخشی از واقعیت به او کمک کرده بود از خطر بگریزد. آیا می‌توانست همیشه به همین شکل تصمیم بگیرد؟ اگر با تغییر مسیر به خودروی دیگری برخورد کرده بود باز هم به همین نتیجه می‌رسید؟ سید مرتضی هاشمی سید مرتضی هاشمی Mon, 21 Oct 2024 23:00:38 +0330 https://virgool.io/se-radio/se-radio-tech-lead-t8eioiy13dxd مطلبی که می‌خوانید ترجمه‌ی قسمت ۲۶۵ از رادیو مهندسی نرم‌افزار است. رادیو مهندسی نرم‌افزار هر یکی دو هفته یک بار مصاحبه‌ای درباره‌ی یکی از موضوعات حوزه‌ی مهندسی نرم‌افزار با افراد خبره و با تجربه در موضوع مورد بحث ترتیب می‌دهد.در این قسمت یوهان سوِن با پاتریک کوآ درباره‌ی نقش رهبر فنی (Technical Lead) و چگونگی تبدیل شدنِ یک فرد به رهبر فنی صحبت می‌کند. تعریف رهبر فنی، مسئولیت‌های این نقش و چالش‌های تبدیل شدن به یک رهبر فنی از جمله موضوعاتی هستند که در این گفتگو مطرح می‌شود.به یک برنامه‌ی دیگر از رادیوی مهندسی نرم‌افزار خوش آمدید. امروز با پاتریک کوا هستم. به رادیوی مهندسی نرم‌افزار خوش آمد پاتریک! خوشحالیم که با ما هستی.ممنونم که مرا دعوت کردید، خوشحالم که با شما صحبت می‌کنم.پاتریک کوا یک مشاور ارشد و یک رهبر فنی در Thoughtworks است. معمولاً در لندن زندگی می‌کند، هرچند در حال حاضر در برلین کار می‌کند. او در زمینه‌ی توسعه‌ی نرم‌افزار بیش از یک دهه تجربه دارد و تمرکزش بر افراد، کسب و کار و فناوری است. ممکن است او را به واسطه‌ی کتاب «دفترچه راهنمای گذشته‌نگر» (The Retrospective Handbook) و یا کتاب جدیدترش «گفتگو با رهبران فنی» (Talking with Tech Leads) بشناسید. پاتریک همچنین در زمینه‌ی آموزش رهبری فنی، هم به صورت داخلی در Thoughtworks و هم در خارج از آن فعالیت داشته است. من در یکی از این آموزش‌های او بوده‌ام. موضوع این برنامه چگونگی تبدیل شدن به یک رهبر فنی است که کاملاً منطبق [با تجربیات او] است.پاتریک آیا چیز دیگری هست که بخواهی در مورد خودت بگویی؟نه، خیلی خوب خلاصه‌اش کردی.برای این‌که جای ابهامی باقی نماند، هم من و هم پاتریک در Thoughtworks کار می‌کنیم. برای همین من در یکی از آموزش‌های او شرکت کردم. اولین سؤالی که هنگام صحبت کردن در مورد رهبری فنی به ذهن می‌رسد این است که نقش رهبر فنی چیست؟ وقتی من یک رهبر فنی می‌شوم چه مسئولیت‌هایی دارم؟این سوال خیلی خوبی است. اول از همه باید بگویم که فقط یک تعریف خوب در این مورد وجود ندارد، چون هر سازمانی این نقش را به شکلی متفاوت تلقی می‌کند. من با تعداد زیادی از مشتریان در سازمان‌های متفاوت کار کرده‌ام؛ فکر می‌کنم بتوانم آن‌چه که به نظرم ویژگی‌های مشترک مسئولیت‌های یک رهبر فنی است را بگویم.در برخی سازمان‌ها به رهبر فنی، توسعه‌دهنده‌ی پیشرو اطلاق می‌شود؛ در سایر سازمان‌ها به آن معمار می‌گویند. به نظر من، ترکیب این دو تفکر این است که رهبر فنی، نقشِ یک معمار نیست که خارج از تیم است. در واقع یک توسعه‌دهنده است. کسی که دارای مهارت‌های توسعه است و مسئولیت رهبری تیم را بر عهده دارد. این نقش با نقش توسعه دهنده‌ی ارشد کاملاً متفاوت است، که هدایت یک حوزه در بخشی از سیستم را بر عهده دارد. رهبر فنی سعی می‌کند بر اثرگذاری کلی تیم تمرکز کند. من انتظار دارم که یک رهبر فنی تا حدی کد بنویسد و همچنین در سطوح فنی کار کند.آنچه که به نظر من رهبر فنی نیست، چیزی است که افراد اغلب به آن مدیر فنی می‌گویند. کسی که بیشتر مسئولِ پیشرفت افراد و گزارش‌هاست اما لزوماً درگیر معماری نیست. حتی اگر پیش‌زمینه‌ی فنی داشته باشد لزوماً بر سیستم متمرکز نیست. انتظار دارم که مدیران فنی با رهبر فنی در تعامل باشند.در بسیاری شرکت‌های دیگر استاد اسکرام (Scrum Master) نقش خیلی محبوبی است و به نظر من، این نقش خیلی متفاوت [از رهبر فنی] است، هر چند یک رهبر فنی می‌تواند استاد اسکرام هم باشد. استاد اسکرام بودن، لزوماً به صورت خودکار از شما یک رهبر فنی نمی‌سازد.این جنبه، شاخص است که رهبر فنی همچنان یک توسعه‌دهنده است که بر اثرگذاری تیم تمرکز دارد.درست است.آیا در مقام مقایسه موافقید که مدیر فنی منحصراً بر تیم تمرکز دارد، معمار منحصراً بر فناوری تمرکز دارد، و توسعه‌دهنده‌ی ارشد کسی است که مالک بخش خاصی از سیستم است؟بله، درست است. تأکید می‌کنم که این‌ها مربوط به نقش‌ها هستند، و این به آن معنی نیست که یک سازمان برای هر یک از نقش‌ها فرد مجزایی خواهد داشت. گاهی یک فرد چند تا از این نقش‌ها را بازی می‌کند. ممکن است رهبر فنی نقش مدیر فنی را هم داشته باشد که مراقب افرادِ خط تولید است و ممکن است در عین حال ارشدترین عضو تیم هم باشد. اما در شرایط دیگر مثلاً از نظر اندازه‌ی تیم یا نحوه‌ی ساختاردهی یک سازمان، ممکن است نقش‌های جداگانه‌ای هم باشند.من نوعی از تقسیم [وظایف] را [در نقش رهبر فنی] می‌بینم؛ یک جنبه‌ی فنی که مربوط به معماری و مسیر سیستم است، و جنبه‌ی مدیریت افراد و پروژه که ممکن است بیشتر مربوط به مدیر فنی باشد. این یک الگوی متداول است که می‌بینم. اما تأکید می‌کنم که این یک نقش است و به این معنی است که مجموعه‌ای از مسئولیت‌ها را شامل می‌شود.پیش از آن‌که در این موضوع عمیق‌تر شویم آیا ممکن است توضیح دهید که دقیقاً چرا به رهبر فنی نیاز داریم؟بله، این سؤال خیلی خوبی است. وقتی در کنفرانس‌ها در مورد این‌که رهبر فنی چیست صحبت می‌کنم، یکی از سؤالاتی که عموماً پرسیده می‌شود این است که «چرا به آن نیاز داریم؟» قطعاً می‌توانم شرایطی را تصور کنم که در یک تیم کوچک کار می‌کنید و همه به خوبی با هم کنار می‌آیند و هر کس می‌داند که باید چه کاری انجام دهد؛ در چنین شرایطی شاید به یک رهبر فنی احتیاجی نباشد، چون همه کارشان را می‌دانند و به خوبی هماهنگ شده‌اند. این یک وضعیت ایده‌آل است و بسیاری تیم‌ها هستند که در وضعیت آشفته‌تری هستند و ترکیبی از مهارت‌های متفاوت دارند. عموماً ممکن است درباره‌ی نحوه‌ی پیاده‌سازی یا مسیر سیستم و معماری ابهاماتی وجود داشته باشد. خیلی خوب است که توسعه‌دهندگانی که توانایی گرفتن چنین تصمیماتی دارند، این تصمیمات را در کارهای خودشان بگیرند. اما زمانی که افراد در مقابل یکدیگر قرار می‌گیرند با یک آشفتگی مواجه می‌شوید. به نظر من یکی از وظایف یک رهبر فنی این است که کاری کند توسعه‌دهندگان به شکلی اثربخش در یک جهت فعالیت کنند.حتی یک تیم پایدار که به خوبی با هم کنار می‌آیند ممکن است روزی در در انتخاب مسیر، یک چارچوب کاری، یک ابزار، و یا یک ویژگی اختلاف نظر پیدا کنند و با تفرقه مواجه شوید. نقش رهبر فنی این است که به نحوی از تیم مراقبت کند که تیم در مسیر مشخصی قدم بردارد و بیشترین اثرگذاری را داشته باشد.به خاطر دارم که یک توئیت را در ارائه‌تان به اشتراک گذاشته بودید: «در آخرین پروژه‌ام ده نفر بودند که همه‌شان عقایدی سرسختانه داشتند که در کد نشان داده شده بود.» آیا به همین مسئله اشاره دارید؟بله، دقیقاً. این توئیت را در آن‌جا قرار دادم چون این مسئله را از دیدگاه دیگری خلاصه می‌کند. [فرض کنید] مخزن کدی (Codebase) را باز کرده‌اید که آن را نمی‌شناسید (یک مخزن کد غریبه) و بخش‌های مختلف سیستم را باز می‌کنید. در این‌صورت، یک نشانه از رهبری فنی کارآمد و کار تیمی این است که در حالت کلی این حس وجود داشته باشد که همه چیز با یک طرز تفکر در توسعه نوشته شده است. اگر ده نوع شخصیت متفاوت داشته باشید که به ده شکل مختلف کد بنویسند اولاً نگه‌داری آن به یک کابوس تبدیل می‌شود، و [دوماً] به انزوای بیشتری ختم می‌شود. به طور کلی این برای من یک نگرانی در مورد کارایی تیمی است.بله، بسیار خوب. شما در جاهای مختلفی رهبر فنی بوده‌اید و خیلی با تجربه شده‌اید. البته زمانی بوده که شما برای اولین بار رهبر فنی شدید. می‌شود حس‌تان و این‌که چطور این اتفاق افتاد را شرح دهید؟بله، قطعاً. فکر می‌کنم اولین تجربه‌ام خیلی تکان‌دهنده بود. به تازگی از تعطیلات برگشته بودم و داشتم در یک تیم کار می‌کردم. روزی که داشتم بر می‌گشتم در فرودگاه با من تماس گرفتند و گفتند که به عنوان رهبر فنی‌ِ تیم دیگری شروع به کار خواهم کرد. به خاطر این‌که یک توسعه‌دهنده بودم و الان باید کار دیگری انجام دهم شوکه‌ شده بودم. نمی‌دانستم معنی آن چیست. فکر می‌کنم برای بسیاری از افراد که خود را در این نقش می‌یابند، همین نگرانی‌ها وجود دارد. در نقش رهبری فنی، مجموعه‌ای از مسئولیت‌های توصیف نشده و کارهایی که باید به عنوان یک رهبر فنی انجام شود، وجود دارد. شاید به عنوان توسعه‌دهنده به خود اطمینان داشته باشند، اما ندانند که این‌ها چه تفاوتی با کار توسعه دارد. بسیاری از تجربیات من در این زمینه بود که بفهمم این نقش چیست. چون در واقع در آن زمان نمی‌دانستم برای یافتن این اطلاعات باید به کجا مراجعه کنم. خوشبختانه با افراد دیگری که به آن‌ها احترام می‌گذاشتم و به آن‌ها دسترسی داشتم، صحبت کردم و از آن‌ها در مورد رویکردشان سؤال کردم. اما می‌توانم بگویم که احساس می‌کردم حمایت نشده‌ام چون احساس امنیت نداشتم.آن ها در مورد نقش رهبری فنی چه گفتند؟برخی از آن‌ها در مورد مسائلی که به نظرشان مهم بود و رویکرد خودشان به این نقش، صحبت کردند. به خاطر دارم که یکی از آن‌ها در مورد تصویر بزرگ‌تر و معماری صحبت می‌کرد. وقتی یک توسعه دهنده هستید، احتمالاً بیشتر به تمیزی کدی که می‌نویسید و قابل تست بودن آن و طراحی خوب مؤلفه‌تان، فکر می‌کنید. اما گاهی فراموش می‌کنید که جای آن در تصویر بزرگ‌تر چیست. فکر می‌کنم این حس را در فضای چابک (Agile) دارم. عمدتاً در مورد معماری حرف نمی‌زنیم. من از داشتن نقش معمار و این‌که فقط چنین شخصی بر معماری تمرکز کند دفاع نمی‌کنم. در واقع اعتقاد دارم همه باید به معماری فکر کنند. در واقع بخشی از کار یک معمار این است که در برخی مقاطع به تیم کمک کند که در مسیر درستی قرار داشته باشند.نکته‌ی دیگری که یک نفر به من گفت این بود که هر چند رهبر فنی هستی بخشی از کارَت ارتباط با سایر اعضاست. زمانی که یک توسعه‌دهنده هستید و مناقشه‌ای میان دو توسعه‌دهنده در تیم می‌بینید، یک راهبرد عمومی این است که به کار خودتان ادامه دهید و آن را به عنوان مشکلِ خودتان به حساب نیاورید. اما به عنوان یک رهبر فنی تلاش برای برطرف کردن مناقشه یا جدال‌های طراحی میان دو توسعه‌دهنده، کار مهمی است. چون می‌خواهید همه در مسیر کلی توافق داشته باشند. لزوماً این‌که کدام راه‌حل درست است اهمیت ندارد، بلکه می‌خواهید همه سهمی در [تعیین] تصویر کلی داشته باشند.آیا در اولین تجربه‌ی رهبری فنی، مناقشه داشتید؟بله. پیش‌زمینه‌ی من به عنوان یک توسعه‌دهنده بیشتر فنی و مربوط به مهارت‌های معماری بود. فکر می‌کنم کارکردن با انسان‌ها باعث شد متوجه شوم افراد چقدر متفاوت هستند. این‌که افراد در کار با افرادی که پیش‌زمینه متفاوت و یا مهارت‌ها و توانایی‌های متفاوتی دارند، چقدر عجیب عمل می‌کنند.ممکن است با یک مثال این را توضیح دهید؟بله. ما معمولاً به روش برنامه‌نویسی دونفره (Pair Programming) کار می‌کردیم که در آن دو نفر پشت یک کامپیوتر می‌نشینند و روی یک داستان (Story) یا ویژگی (Feature) کار می‌کنند. یک زوج خاص را به خاطر دارم که یکی از آن‌ها فردی تحریک‌پذیر بود که می‌خواست کار را [به سرعت] انجام دهد. روش توسعه‌ی نفر دوم بیشتر این بود که باید کمی به این مسئله فکر کنم و می‌خواهم بروم و آن را مدل کنم، شکل بکشم. منظورم چند هفته یا چند روز نیست، بلکه نیاز به کمی زمان [داشت]. یادم می‌آید که مقداری آزردگی در تیم به خاطر این مسئله به وجود آمده بود. یکی از آن‌ها می‌گفت که می‌خواهم کار را انجام دهم و دیگری می‌گفت به نظرم آماده نیستیم و نمی‌دانم می‌خواهیم چه کنیم. به نظر من، این صرفاً دو سبک متفاوت است. آن‌ها نمی‌دانستند که هر کدام سبک متفاوتی دارند و نتوانسته بودند راهی برای کار کردن با یکدیگر پیدا کنند.پیش از آن تعطیلات مهم، پیش از آن تماس، با چنین شرایطی چطور عکس‌العمل نشان می‌دادید؟ به عنوان یک رهبر فنی چطور؟فکر می‌کنم قبل از تعطیلات احتمالاً می‌گفتم این مسئله به من مربوط نیست. مسئولیت رهبر فنی یا مدیر پروژه است که به آن رسیدگی کند.بنابراین حداکثر کاری که می‌کردید صحبت کردن با رهبر فنی یا مدیر پروژه بود؟احتمالاً آن را هم پشت گوش می‌انداختم. کمی عجیب است که در مناقشاتی که در آن قرار ندارید دخالت کنید. وقتی بعد از تعطیلات در این نقش قرار گرفتم احساس کردم این‌که تمام توسعه‌دهندگان بتوانند با هم صحبت کنند و توانایی‌های یکدیگر را درک کنند و با هم کنار بیایند، واقعاً مهم است. در چنین شرایطی، در نهایت هر دو طرف را به اتاقی بردم تا در مورد بازخوردهای صریح در مورد آن‌چه که می‌دیدم صحبت کنیم. این‌طور نبود که تلاش کنم آن‌ها را خجالت‌زده کنم، بیشتر این‌طور بود که متوجه شوم موضع هر طرف و ریشه‌ی آن چیست. به نظرم صحبت کردن در مورد این‌که برای هر کدام چه چیزی اهمیت دارد و دوست دارند چطور کار کنند، مفید بود. فکر می‌کنم این‌که به افراد اجازه دهیم نظرات‌شان را در محیطی امن‌تر بیان کنند مسئله‌ی مهمی بود.در نهایت آن‌ها روی یک سبک‌ کاری به توافق رسیدند؟بله. در نهایت چیزی که به آن رسیدند این بود که وقتی کار جدیدی را شروع می‌کنند، برای مدتی جدا از هم کار کنند. فردی که دوست داشت ادامه بدهد احتمالاً شروع به ساختن نمونه‌ی اولیه می‌شد و یا در مورد ابزارها و تکنولوژی‌های مرتبط با کارشان مطالعه می‌کرد. شخص دیگر هم به طراحی و مدل‌سازی می‌پرداخت. پس از یکی دو ساعت گرد هم می‌آمدند تا در مورد نحوه‌ی پیاده‌سازی با هم صحبت کنند.داستان خوبی است. با این داستان خیلی سطحی در مورد وظایف رهبر فنی صحبت کردیم. بنابراین باید چشم‌انداز پروژه و معماری کلی آن را در ذهن داشته باشید. یک برنامه‌ی خوب در مورد طرح‌های معماری نرم‌افزار داریم که توسط سایمون براون ارائه شده است که ممکن است ارزش شنیدن را داشته باشد. او نویسنده‌ی کتاب «معماری نرم‌افزار برای توسعه‌دهندگان» ( Software Architecture for Developers) است (اشاره به قسمت ۲۲۸ است-مترجم).این در مورد کار کردن با افراد بود که در مثالی که درباره مناقشه داشتید به آن اشاره کردید. چه کارهای دیگری را به عنوان مسئولیت‌های یک رهبر فنی می‌بینید؟در یکی از نوشته‌های بلاگم مدلی دارم که شبیه به نمودار وِن است. اگر دنبالش بگردید شاید آن را پیدا کنید. موضوعش درباره‌ی نقش رهبر فنی است. آن‌جا در مورد هم‌پوشانی سه حوزه صحبت می‌کنم. یکی از آن‌ها مهارت‌های توسعه است. برای من خیلی اهمیت دارد که یک رهبر فنی بتواند کد بنویسد و بتواند با سیستمی که ساخته می‌شود کار کند. معنی‌اش این نیست که فقط کد بنویسد اما باید بتواند این کار را انجام دهد و بتواند در هر مقطعی با توسعه‌دهندگان کار کند.حوزه‌ای مربوط به رهبری عمومی هم وجود دارد. منظور از آن مثلاً رسیدگی به مناقشات است. اما به نظرم چیزهای زیادی درباره‌ی رهبری وجود دارد که یک رهبری فنی کارآمد از آن بهره می‌گیرد. بخشی از آن این است که افرادِ در حوزه‌ی کسب و کار را متقاعد کند که باید به صورت تیمی به مسائل فنی بپردازند. چون باید این زمان را صرف کرده باشید تا بتوانید در برخورد با مسائل فنی عمیق و یا مسائل زیرساختی به صورت کارآمدتری عمل کنید. مثل یک خیابان دوطرفه است. باید توسعه‌دهندگان را هم متقاعد کنید که فقط روی مسائل فنی کار نکنند تا اطمینان داشته باشند میان چیزی که روی آن کار می‌کنند و کمک به کسب و کار، ارتباطی وجود داشته باشد. چون به این ترتیب می‌خواهید میان افراد فنی و کسب و کار اعتمادسازی کنید. بنابراین رهبر فنی به نوعی نقش یک پل را ایفا می‌کند. کمی در مورد مدیریت مخاطرات (Risk) صحبت کردم. به نظرم این یک مسئله‌ی خیلی بزرگ است که یک رهبری فنی باید به آن بیاندیشد. در بیشتر سازمان‌ها این نقش معمولاً مرتبط با افراد دیگری خارج از تیم است. این افراد ممکن است افراد تیم عملیات (Operations) یا پشتیبانی باشند که باید نرم‌افزار ساخته شده را اجرا کنند. همچنین ممکن است افراد حوزه‌ی بازاریابی و مالی باشند که در با پیامدها و ویژگی‌های نرم‌افزار [سروکار دارند]. در واقع هدف این است که یک نفر به طور کلی نگرانی‌های مخاطرات را در نظر دارد؛ برخی تیم‌ها ممکن است مدیر پروژه داشته باشند یا نه. رهبر فنی باید در مورد مخاطرات فنی هم بیاندیشد. مثلاً آیا وقتی نرم‌افزار در محیط محصول قرار می‌گیرد به اندازه‌ی کافی زیرساخت برای لاگ وجود دارد تا اگر چیزی خراب شد بتوان از آن پشتیبانی کرد؟ آیا تصمیمات فنی درستی گرفته‌ایم تا به نقشه‌ی راه یک فروشنده‌ی خاص وابسته نشویم و اگر آن فروشنده از بین برود نرم‌افزار ما هم دچار مشکل شود. آیا به اندازه‌ی کافی وقت صرف تمیز نگه داشتن کد و بازسازی (Refactor) آن می‌کنیم؟ چون در نهایت این منجر به کاهش اثرگذاری تیم می‌شود. فکر می‌کنم این‌ها مسئولیت‌های رهبری عمومی هستند.حوزه‌ی سوم مربوط به معماری است. یعنی تلاش برای این‌که افراد بیشتر به ساختن یک سیستم فکر کنند تا به نوشتن نرم‌افزار. یعنی فقط به ویژگی‌هایی که می‌نویسند فکر نکنند بلکه به زیست‌بومی (Ecosystem) که نرم‌افزار در آن زندگی خواهد کرد هم فکر کنند.یعنی فکر کردن به این‌که آیا باید با یک محفظه‌ی داکِر در فضای ابری (Cloud) مستقر شود یا چنین چیزهایی؟دقیقاً. فکر می‌کنم در هر تیم، متفاوت باشد. برخی‌ها خودشان سیستم‌شان را اجرا می‌کنند و آن را در محیط محصول مستقر می‌کنند. برخی دیگر، نرم‌افزار در حال اجرایشان را نمی‌بینند چون به بخش‌های دیگری در سازمان سپرده شده است. اما این موضوع اهمیت دارد که رهبر فنی به افراد کمک کند پیامدِ بازخوردهایشان را درک کنند؛ همچنین تلاش می‌کند توسعه‌دهندگان هم بازخوردهای مربوط به نرم‌افزاری که می‌نویسند را دریافت کنند. بخشی از آن هم این است که توسعه‌دهندگان درک کنند چه اتفاقی برای نرم‌افزارشان در محیط محصول رخ می‌دهد.عنوان نوشته‌ی بلاگی که به آن اشاره کردید «رهبر فنی-حوزه‌های مسئولیت» است. می‌خواهم کمی در مورد برخی چیزهایی که مطرح شد عمیق‌تر صحبت کنیم. چیزهایی مثل رهبری و همین‌طور امور مربوط به توسعه از جمله شئ‌گرایی، ‌کدنویسی، معماری تکاملی، و … . به نظرم تا حدی شبیه به مدیریت فرهنگ تیم است. آیا شما این را هم مسئولیت خود می‌بینید؟بله، قطعاً. فکر می‌کنم فرهنگ تیم یک بخش مهم است. در یکی از سخنرانی‌هایی که داشتم که عنوانش «راهنمای رهبری یک تیم برای یک خوره‌ی نرم‌افزار» (The geek's guide to leading a team) است در این مورد صحبت کردم که یک رهبر فنی باید بر چه چیزهایی از جنبه‌ی فرهنگ تیمی تمرکز کند. من آن را با رهبر تیم مقایسه می‌کنم، که روی نحوه‌ی تعامل اعضای تیم با یکدیگر کار می‌کند. در نقش رهبر فنی یک مسأله فرهنگی این است که افراد چه رویکردی نسبت به کدی که می‌نویسند دارند؟ مثلاً این‌که به دنبال ترویج چه نوعی از فرهنگ توسعه هستید؟ چون توانایی تأثیرگذاری بر آن را دارید.یک مثال از آن این است که اگر یکپارچه‌سازی مستمر (Continuous Integration) دارید، [ممکن است] یک بیلد (Build) خراب شود. من در تیم‌هایی کار کرده‌ام که در آن این خرابی ادامه پیدا می‌کرد چون نگاه این بود که مشکل کسِ دیگری است. این نشان از نوعی از [مشکل] فرهنگ تیمی بود که رهبر فنی روی آن تمرکز نکرده بود. این در مقابل تیمی است که به محض این‌که یک بیلد خراب شود، یک نفر به سوی آن می‌شتابد و پرچمی افراشته می‌شود که مشخص می‌کند چه کسی در حال درست کردن آن است.برای ایجاد و حمایت از این فرهنگ تیمی معمولاً چه می‌کنید؟بخش زیادی از این مسائل این است که تیم را در مقاطعی، دور هم جمع کنیم تا با هم یک‌سو شویم. به نظر من یک‌سویی خود به خود و در نتیجه‌ی کار کردن کنار یکدیگر رخ نمی‌دهد. احتمال دارد این اتفاق رخ دهد اما در بیشتر مواقع افراد پشت کامپیوترهایشان می‌مانند و در مورد مسائل بزرگ صحبت نمی‌کنند. یکی از فعالیت‌هایی که به عنوان یک رهبر فنی به آن فکر می‌کنم جمع کردن تیم توسعه در یک اتاق است. با این هدف که در مورد نگرانی‌هایی که برای همه وجود دارد صحبت کنیم و به توافق برسیم. مثلاً ممکن است افراد لاگ‌ها را در قالب‌های متفاوتی ثبت کنند. در این صورت بحث در مورد رویکردمان به لاگ است و این‌که چطور اطمینان حاصل کنیم که سطح درستی از اطلاعات را لاگ کرده‌ایم.یک راه دیگر برای یک‌سو شدن این است که یک توسعه‌دهنده، بخشی از سیستم را توضیح دهد (شاید در مورد تعامل با واسط‌های برنامه‌نویسی (API) خارجی یا سایر وابستگی‌های خارجی باشد) و سپس ببینیم آیا یک رویکرد عمومیِ سازگار در آن وجود دارد یا خیر. حتی در یک تیم هشت نفره ممکن است با سه راهبرد برای تعامل با سیستم‌های خارجی مواجه شوید و افراد می‌توانند از این یاد بگیرند.آن‌چه متوجه شدم این است که آن‌چه شما می‌گویید کمی شبیه به اجتماعات فنی (Tech Huddle) است که در آن تیم گرد هم آمده و در مورد فناوری‌ها صحبت می‌کنند. آیا منظور همین است؟بله، قطعاً. اجتماع فنی یک نام آن و یک راه برای رسیدن به آن است. برخی تیم‌ها یک بازبینی کد (Code Review) کاملاً گروهی انجام می‌دهند. شرکتی به نام Unruly در انگلیس هست که به خاطر فراتر بردن XP، (مخفف Extreme Programming) شناخته شده است. آن‌ها برنامه‌نویسی گروهی (Mob Programming) را اتخاذ کرده‌اند که در آن تمام تیم در یک زمان در حال برنامه‌نویسی است.اجازه بدهید از فرهنگ تیم به موضوع رشد توسعه‌دهنده و رشد افراد، برویم. فکر می‌کنم این به کار رهبر فنی مربوط باشد. رویکرد شما به آن چطور است؟بگذارید اول توضیح دهم چرا این مسئله مهم است. یک ضدالگو که در میان رهبران فنی تازه‌کار خیلی متداول است این است که بسیاری از شرکت‌ها بهترین توسعه‌دهندشان را در این نقش قرار می‌دهند. به نظر من لازم نیست که برای قرار گرفتن در این نقش بهترین توسعه‌دهنده باشید؛ کافی است توسعه‌دهنده‌ی خوبی باشید که همه به او احترام می‌گذارند. یکی از عواقب این‌که بهترین توسعه‌دهنده ارتقاء پیدا کند این است که می‌خواهد به نوشتن کد به بهترین شکل ادامه دهد. این منجر به ایجاد یک چرخه‌ی سیستمی بد می‌شود که او می‌خواهد تمام مسائل جالب و راه‌حل‌های سخت را به عهده بگیرد و مسائل ساده را به توسعه‌دهندگان بسپرد. اگر به سوی دیگر نگاه کنیم که شما یک توسعه‌دهنده در تیم هستید کار کردن روی مسائلی که جالب نیستند خیلی هیجان‌انگیز و الها‌م‌بخش نیست. در همین حال این رهبر فنی، درگیر جلسات و مسائل دیگری است که مسئول آن است و برایش سخت است که مانند قبل روی مسائل متمرکز شود و کارها را به همان خوبی انجام دهد. برای همین فکر می‌کنم تقویت سایر توسعه‌دهندگان مهم است. این‌که چطور توسعه‌دهندگان جدیدی را از طریق فراهم کردن فرصت‌های جدیدی که قبلاً نداشتند و حمایت کردن آن‌ها، تربیت کنید. این‌که افراد را به کار روی زمینه‌ها و فناوری‌هایی که قبلاً با آن مواجه نشده‌اند، تشویق کنید و خودتان یا شخص دیگری ایده‌پردازی کنید و رویکردهای حل مسئله را طراحی کنید.می‌شود مثالی از انجام این کار با یک شخص بزنید؟در یکی از تیم‌هایی که کار می‌کردم ما مفهوم رهبر ویژگی (Feature Lead) را مطرح کردیم. ایده، این بود که من به عنوان یک رهبر فنی بدانم در هر زمینه چه رویکردی داریم. هر توسعه‌دهنده صاحب یک ویژگی و نحوه‌ی پیاده‌سازی در آن زمینه شد. رویکرد احراز هویت یک مثال از آن است. افراد را دو به دو تقسیم کردم تا توسط یکدیگر حمایت شوند. سپس آن‌ها نیازمندی‌های مربوط به احراز هویت را کاوش می‌کردند؛ در مورد ابزارها و کتابخانه‌هایی که می‌توانیم از آن استفاده کنیم، رویکرد ما به مسئله، راه‌حل‌های بالقوه‌ و طراحی آن صحبت می‌کردند. این تا جایی پیش می‌رفت و سپس من آن را بازبینی می‌کردم تا مطمئن شوم مشکل وجود ندارد و در راستای سایر چیزها قرار دارد. پس از این‌که به راه‌حل مناسب رسیدیم، آن را با آن‌چه که به آن اجتماع فنی گفتید همراه می‌کردیم و تمام تیم را در جریان آن قرار می‌دادیم تا بدانند رویکرد کلی ما چیست.مسئله‌ی جالب این بود که برخی از مسئولان ویژگی به مراتب در اینکه راه حل را به تنهایی ارائه کنند، موفق‌تر بودند. اما در موارد دیگر افراد نیاز به زمان بیشتری داشتند و می‌گفتند حتی نمی‌دانیم از کجا شروع کنیم و ما با هم روی رویکردها و گزینه‌های متفاوتی که قابل بررسی بود، کار می‌کردیم. این کمک می‌کرد افراد رشد کنند و از راه‌هایی متفاوت به هدف برسند.راهبرد رهبر ویژگی اساساً به این معنی است که به افراد صراحتاً مسئولیت‌هایی در تیم سپرده شود و از کسانی که به تنهایی از پسِ آن بر نمی‌آیند حمایت شود.بله، دقیقاً.چطور از من حمایت می‌کنید؟ اگر من رهبر ویژگی احراز هویت باشم و ندانم چطور شروع کنم به من چه می‌گویید؟کمی در مورد آن‌چه از یک رهبر ویژگی انتظار دارم صحبت می‌کنم. این‌که اطمینان حاصل کنیم تمام نیازمندی‌های کسب و کار برآورده شده است و تمامی مخاطراتِ موارد کاربرد مربوط به احراز هویت که نیاز داریم ارزیابی می‌شود. بخشی از آن احتمالاً این است که باید با چنین افرادی صحبت کنی تا بفهمی چطور می‌خواهند با سیستم تعامل می‌کنند. سپس او به این کار می‌پردازد و سپس در مورد رویکرد فنی به این مسئله صحبت می‌کند. یک عادت خوب رهبر فنی این است که جواب کامل را بلافاصله ندهد و اجازه دهد افراد خود به آن دست یابند. من سؤالات زیادی می‌پرسم تا بفهمم افراد چه علاقه‌مندی‌هایی دارند و چه دانشی دارند. در مثالی که زدید اگر اصلاً ندانند از کجا باید شروع کرد، کمی واضح‌تر می‌گویم: «آیا OAuth و کتابخانه‌های مربوط به این زمینه را دیده‌ای؟ آیا به احراز هویت دوگانه (Two Factor Authentication) نیاز داریم؟» سپس افراد آن را بررسی کرده و راه‌حل مناسب را با توجه به پشته‌ی فناوری‌ای که داریم پیدا می‌کنند. حتی ممکن است بگویم «برو و یک Spike اجرا کن.» که یک تحقیق فنی با زمان محدود است که در آن فرد، یک نمونه‌ی اولیه‌ی کوچک ارائه می‌کند و از آن یاد می‌گیریم.وقتی من در این شرایط هستم معمولاً می‌گویم: «این‌ها عباراتی است که در گوگل جستجو می‌کنم.» شما هم این کار را می‌کنید؟بله، قطعاً این هم یک گزینه است.بسیار خوب. به رهبر ویژگی اشاره کردیم که به این معنی است که بخشی از وظایف یک رهبر فنی را به شخص دیگری می‌سپارید تا رشد کند. آیا نکته‌ای در انتخاب فرد مناسب برای این کار وجود دارد؟من مدل به طرف خود کشیدن (Pull) را ترجیح می‌دهم. من به عنوان یک رهبر فنی می‌خواهم تمام افراد از کاری که می‌کنند حمایت کنند، چون افرادی می‌خواهم که به موضوع اهمیت دهند. در بسیاری از موارد سعی می‌کنم افراد را صراحتاً انتخاب نکنم و افرادی را بیابم که بخواهند در آن زمینه کار کنند. بخشی از کار که یک مهارت ارتباطی است، این است که افراد را با جذابیت‌های زمینه‌های مختلف به هیجان بیاوریم. گاهی اوقات در مورد اشکالات در سیستم‌های مختلف صحبت می‌کنید، یا این‌که کار باید ادامه پیدا کند اما برخی از مشکلات هم باید برطرف شوند و فرصت‌های دیگری هم هستند. من ترجیح می‌دهم بگویم:‌ «باید به مدیریت فعالیت نگاهی کنیم و باید راهی برای یکپارچه‌سازی راه‌حل فنی با نحوه‌ی اجرای فعالیت‌های مربوط به محصول، پیدا کنیم. یک نفر می‌خواهیم که راه‌حل فنی و رویکرد کلی به این مسئله را پیدا کند... این‌ها هم فرصت‌های جذاب و افرادی هستند که با آن‌ها کار خواهید کرد که معمولاً پیش نمی‌آید.» سپس به دنبال داوطلب می‌گردم. گاهی اوقات ممکن است داوطلب وجود نداشته باشد و مجبور هستید که انتخاب کنید. بخشی از این کار بر عهده‌ی شما به عنوان یک رهبر است که برای توسعه‌دهندگان، اعتماد سازی کنید.آیا تا به حال در شرایطی بوده‌اید که یک نفر، زیادی داوطلب شود؟بله، قطعاً. معمولاً این را صراحتاً می‌گویم. بخشی از کار من به عنوان یک رهبر فنی، که تلاش می‌کند از موفقیت افراد حمایت کند، این هم هست که مراقب باشم افراد چه مقدار کار بر می‌دارند و آن را مدیریت کنم. در یکی از تیم‌هایی که در آن کار می‌کردم یک قانون راهنما داشتیم «صرفاً به این دلیل که کار زیاد است، نباید کسی روی بیش از دو ویژگی کار کند.»در آموزش‌ها هم به خاطر دارم که شما در فهمیدن این‌که افراد در چه زمینه‌هایی می‌خواهند کار کنند، خیلی سنجیده عمل می‌کنید. می‌شود کمی در این مورد توضیح دهید؟این مربوط به شناخت افراد است. ابزاری که می‌توانید از آن استفاده کنید گفتگوهای دو نفره است. از افراد بپرسید به چه چیزی علاقه‌مند هستند؟ چه کار می‌خواهند انجام دهند؟ وقتی این را از افراد بپرسید، بسیاری از افراد معمولاً جوابی ندارند چون در واقع به آن فکر نمی‌کنند. برخی هم اهداف واضحی دارند. بنابراین بخشی از آن این است که بفهمید افراد به چه علاقه‌مند هستند، اهداف واقعی آن‌ها چیست و به کدام سو می‌روند. من به عنوان یک رهبر فنی به دنبال این هستم که در محیطی که در آن هستیم کارهای در دسترسِ قابل انجام را با فرصت‌هایی که افراد دوست دارند و شاید هنوز نمی‌دانند، همسو کنم. برای مثال، توسعه‌دهندگانی داشته‌ام که می‌خواستند وارد فضای ذهنی توسعه-عملیات (DevOps) و کار با زیرساخت شوند و روی خودکارسازی، با مثلاً Puppet یا Chef و چنین چیزهایی کار کنند. در حالی که سایر توسعه‌دهندگان اصلاً نمی‌خواستند با آن سر و کار داشته باشند. بیشتر می‌خواستند بر جلوی‌کار (Frontend) و واسط کاربری متمرکز باشند. یا گروه دیگری که نمی‌خواهند حتی به واسط کاربری نگاه کنند :-) و می‌خواهند در توسعه‌ی سرویس‌های سرسخت پشتِ‌کار (Backend) و واسط‌های برنامه‌نویسی، رشد کنند. اگر از افراد نپرسید این‌ها را نخواهید فهمید. این‌جاست که صَرف وقت برای هر توسعه‌دهنده مفید است. شاید حتی به صورت گروهی هم بتوانید آن را انجام دهید.باز هم موضوع را کمی عوض کنیم. در ابتدا اشاره کردید که به عنوان یک رهبر فنی باید خودتان هم کد بنویسید. چرا؟فکر می‌کنم یک مسئله‌ی کلیدی است. برای من به این معنی است که بتوانید کد سیستم را بنویسید. مقاله‌ای در ComputerWorld یا InfoWorld هم هست که به آن ارجاع می‌کنم. نویسنده در آن در مورد این صحبت می‌کند که توسعه‌دهندگان به این خاطر به سایر توسعه‌دهندگان احترام می‌گذارند که کدِ آن‌ها را می‌بینند. یک مثال از اوایل فعالیت حرفه‌ایم دارم. در شرکتی کار می‌کردم که چند مدیر فنی داشت. یکی از مدیران فنی می‌خواست در ارتباط با اتمام یک ابزار جلسه داشته باشیم که در آن زمان سیستم کنترل نسخه‌ها (CVS) را به سیستم داخلی کنترل کدهای منبع‌شان (Source Control) متصل می‌کرد. این ابزار وابستگی‌هایی به Perl و ... داشت و ساعات آخر روز جمعه بود. مدیر آمد و گفت «خیلی مهم است که این کار قبل از پایان روز به اتمام برسد.» صحبت از ساعت ۳ بعد از ظهر روز جمعه است :-) و من تقریباً مطمئن هستم که نمی‌توانیم آن را تمام کنیم. گفتم بیایید بنشینیم و با هم روی آن کار کنیم و کیبورد را به مدیر فنی دادم. چهره‌اش طوری بود که می‌گفت چه کنم؟ برای من واضح بود که او نمی‌تواند کد Perl بنویسد و نمی‌دانستم با کنار من نشستن می‌خواست به چه چیزی دست یابد. من در ابتدای فعالیت حرفه‌ایم متوجه شدم که «بسیار خوب، این فرد را در زمره‌ی افراد غیر فنی قرار می‌دهم» و در این نقطه، دیدگاه‌تان تغییر خواهد کرد.اگر توسعه‌دهندگان در نوشتنِ کدِ سیستم برای شما احترامی قائل نباشند، زمانی که می‌خواهید در تصمیم‌گیری گروهی درباره‌ی مسیری متفاوت، به آن‌ها کمک کنید، احتمالاً تصمیم‌های اشتباهی خواهید گرفت. همچنین توسعه‌دهندگان احتمالاً از آن حمایت نخواهند کرد. برای من واقعاً اهمیت دارد که رهبر فنی بداند در کد چه خبر است. احتمالاً بیش‌تر به خواندن کد عادت خواهید کرد تا نوشتن آن. با این‌حال فکر می‌کنم این‌که رهبر فنی بتواند در سیستم مشارکت داشته باشد، اهمیت دارد. این‌که بداند برای فلان زمینه به کجا برود و چطور ویژگی‌های جدید را اضافه کند و تست‌ها کجا هستند و ... چون این مسئله در حفظ درک متقابل خیلی اهمیت دارد. در آگاهی از معماری فنی کلی و مخاطرات هم همین‌طور.بنابراین برای این‌که احترام توسعه‌دهندگان را به همراه داشته باشم و بتوانم رهبر فنی موفقی باشم، باید کد بزنم. جنبه‌ی دومی که به آن اشاره کردید این است که رهبر فنی باید بداند در کد چه خبر است.بله، قطعاً. زیاد می‌بینم که رهبران فنی، به ویژه آن‌هایی که بی‌مقدمه در این نقش قرار گرفته‌اند، به تیم اعتماد می‌کنند. وقتی شش ماه بعد به سراغ کد می‌روند می‌گویند: «چرا کلاس‌های ما سیصد خط هستند؟ تست‌ها کجا هستند؟» و به دنبال تمامی انتظاراتشان از کد خوب می‌گردند که در واقع محقق نشده‌اند،‌ چون تیم این تصمیم‌ها را گرفته است. این برای من به منزله‌ی مدیریت مخاطرات فنی (Technical Risk Management) است. یعنی خیلی خوب است که به توسعه‌دهندگان اعتماد کنید و بخواهید به آن‌ها این حد از آزادی و درک را بدهید. اما در عین حال به یک حلقه‌ی بازخورد نیاز دارید تا آن‌چه که فکر می‌کنید در حال رخ دادن است محقق شود. این برای من یک مسئله‌ی کلیدی است. به عنوان یک رهبر فنی باید بدانید وضعیت فعلی سیستم چیست تا بتوانید موازنه برقرار کنید. موازنه‌ای میان سرعت اضافه کردن ویژگی‌ها و یا بازطراحی و رویکردهای معماری در یک بخش سیستم.وقتی به عنوان یک رهبر فنی کد می‌نویسید، آیا دو نفری (Pair) کد می‌زنید و یا به تنهایی و یا به شکل دیگری است؟سؤال خوبی است. به شدت توصیه می‌کنم که از تبدیل شدن به یک تکاورِ تنها که روی ویژگی‌های بحرانی و حساس به زمان کار می‌کند، خودداری کنید. چون تبدیل به مسدودکننده کار می‌شوید. فکر می‌کنم یکی از دشواری‌هایی که بعداً در مورد آن صحبت خواهیم کرد مربوط به مدیریت زمان است. یعنی نمی‌توانید مداوم روی یک چیز کار کنید و باید از کار کردن روی چیزهایی که در مسیر بحرانی قرار دارند پرهیز کنید. به نظرم دو نفری کار کردن راه خیلی خوبی است. وقتی برای [پیاده‌سازی] یک ویژگی یا یک داستان (Story) گرد هم می‌آییم، در مورد رویکرد کلی و کاری که باید انجام دهیم صحبت می‌کنیم. صراحتاً در مورد کارهایی که می‌خواهیم انجام دهیم حرف می‌زنیم تا اگر من مجبور به ترک کار شدم یا باید به جلسه می‌رفتم آن شخص بتواند کار را ادامه دهد و امیدوار باشم تا وقتی برمی‌گردم کار از مسیر خارج نشده یا حداقل می‌شود درباره‌ی آن صحبت کرد. این کار، یکی دو مزیت دارد. شخصی که با او کار می‌کنید اطلاعاتی از یک دیدگاه دیگر دریافت می‌کند. شما هم نقطه‌ی تماسی با آن ویژگی پیدا می‌کنید و می‌فهمید در کد چه خبر است.بنابراین وقتی دونفری کار می‌کنید مسیر پیاده‌سازی را طراحی می‌کنید تا در صورتی که لازم شد به جلسه بروید شخص دیگر بتواند به تنهایی کار را ادامه دهد؟بله. می‌خواهم یک ضدالگوی دیگر را مطرح کنم چون فکر می‌کنم خیلی حساس است. این مسئله در همان پروژه‌ای اتفاق افتاد که در آن توسعه‌دهنده بودم و بعد از آن رهبر فنی شدم. رهبر فنی ما در آن زمان در برخورد با چیزهایی که دوست نداشت، سبک خاصی داشت. وقتی ما توسعه‌دهندگان شب به خانه می‌رفتیم او به شکلی جادویی در نیمه‌ی شب همه چیز را بازسازی (refactor) می‌کرد و آن را در مخزن کد قرار می‌داد. وقتی ما صبح سر کار بر می‌گشتیم، می‌گفتیم چرا همه چیز بازنویسی شده است؟ گفتگویی در مورد این‌که چرا این کار انجام شده بود و یا این‌که آیا بهتر است یا نه وجود نداشت. نگه‌داری آن برای ما سخت و گیج‌کننده بود. این باعث به وجود آمدن حس تضعیف شده بود. می‌خواهم این موضوع را به عنوان یک ضد الگوی مهم رهبری فنی مطرح کنم. این‌که کد افراد را از نو بنویسید چون با آن مخالفید.این ما را به موضوع دیگری هدایت می‌کند. وقتی توسعه‌دهنده هستید، همکاران‌تان در کنارتان هستند. اما در شرایطی که توسعه‌دهنده و رهبر فنی وجود دارند، آن‌طور که توضیح دادید این یک نقش منفرد است. یک رهبر فنی تا چه حد عضوی از تیم است و تا چه حد از تیم توسعه متفاوت است؟به نظر من رهبر فنی عضوی از تیم است. برخی از مسئولیت‌ها و دیدگاه‌ها این حس را به وجود می‌آورد که میان دو دنیا در تقلا هستید. بخشی از آن کار کردن با تیم و کد زدن است. اما در عین حال به سمت چیزهای دیگری کشیده می‌شوید. شاید کسب و کار نیز ویژگی جدیدی دارد و شما تحت فشار تحویل چیزهای جدید هستید. شاید یک توسعه‌دهنده با موضوع حساسی که نگرانش کرده نزد شما می‌آید که به خاطر شخصی بودن موضوع، نمی‌شود آن را با سایرین مطرح کرد. این جایی است که خود را هم داخل تیم و هم خارج از آن احساس می‌کنید. به عنوان یک توسعه‌دهنده که در این نقش قرار گرفته، این می‌تواند خیلی دشوار باشد. نقش‌های دیگری هم در تیم توسعه هستند که منحصر به فردتر هستند. مثلاً شاید یک آزمون‌گر (Tester) یا یک مدیر پروژه داشته باشید. اما یک توسعه‌دهنده معمولاً در کنار توسعه‌دهندگان دیگر قرار دارد. وقتی در نقش رهبری فنی قرار می‌گیرید هم حس می‌کنید جزئی از تیم هستند و هم حس می‌کنید خارج از آن هستید. این تنهایی می‌تواند خیلی آزاردهنده باشد.فارغ از این تنهایی، تبدیل شدن به یک رهبر فنی به چه معناست؟برخی از این‌ها را از راه سخت‌اش یاد گرفتم :-) این‌که می‌توانید خودتان با مشکلات روبرو شوید. دلیلی داشته که شما در این نقش قرار گرفته‌اید، بنابراین شایستگی انجام آن را دارید. اما مهم است که شبکه‌ی حمایتی خود را بسازید. یعنی در برخی موضوع‌ها بهتر است با افراد دیگری که به محیط فعلی شما ارتباطی ندارند، صحبت کنید. این چیزی است که در کلاس‌هایی که ارائه می‌دهم زیاد درباره‌اش صحبت می‌کنم؛ ساختن شبکه‌ی حمایتی. در برخی سازمان‌ها ممکن است خوش‌شانس باشید و با رهبران فنی تیم‌های دیگر کار کنید. یا ممکن است رهبران فنی زیادی در یک طبقه داشته باشید. در این‌صورت این مزیت را دارید که چیزی مثل آن‌چه ما به آن «نهار رهبران فنی» می‌گفتیم را هماهنگ کنید. جلساتی که در آن رهبران فنی را جمع کرده و در مورد مسائلی صحبت کنید که صحبت کردن در مورد آن‌ها با تیم‌تان سخت است. ممکن است مربوط به مدیریت وقت و تقویم و کنار آمدن با برگشتن به کد زدن باشد. شاید مربوط به بهترین راهِ حل و فصلِ مناقشات در تیم باشد. یا مثلاً اینکه سایر تیم‌ها چه ابزارها و فناوری‌های استفاده می‌کنند که ما حتی از آن خبر نداریم چون در تیم ما کسی از آن خبر ندارد. چیزهایی که بازخورد گرفتن در مورد آن در تیم سخت است. به این نوع از پشتیبانی احتیاج دارید.یک بار در جلسه‌ای بودم، [پرسیدم] کدام یک از شما مدیر، کدام توسعه‌دهنده و کدام‌یک معمار است؟ او گفت مدیر کسی است که سرش مدام در ایمیل است. توسعه‌دهنده مدام در IDE و معمار در PowerPoint است :-) و من گفتم رهبر فنی همیشه سرش در تقویم‌اش است :-)در این نهارها در این مورد هم صحبت می‌کنید؟ می‌توانید صحبت‌هایی که در این جلسات اتفاق می‌‌افتاد را به اشتراک بگذارید؟بله. Thoughtworks یک شرکت مشاوره‌ای است و با مشتریان متفاوتی کار می‌کند. اما من این شانس را داشتم که نزدیک به تیم‌هایی باشم که با مشتریانی کار می‌کردند که در همسایگی ما هستند. وقت نهار گرد هم می‌آمدیم چون این راحت‌ترین راه بود که در جایی خنثی کنار هم باشیم. سپس روی یکی از موضوعات روز تمرکز می‌کردیم. لیستی از موضوعاتی که می‌خواستیم درباره‌ی آن صحبت کنیم داشتیم. یکی از این موضوعات مدیریت زمان بود: «چطور خود را از جلسات رها کنید؟» موضوع دیگر هم بود که درباره‌ی نحوه‌ی تعامل با مشکلات توسعه‌دهندگان بود. مثلاً شاید توسعه‌دهنده‌ای باشد که با سایر اعضای تیم وفق نمی‌شود. دیگران چه راهبردهایی در کمک به برطرف کردن این مسئله استفاده می‌کنند؟ این به یک‌سو کردن راهبردها در این نوع مسائل کمک می‌کند. گاهی اوقات صحبت از مسائل فنی بود. مثلاً بازبینی معماری‌مان و این‌که آیا مناسب است یا این‌که شما رویکردی دیگری به آن می‌داشتید؟ تلاش می‌کردیم روی چیزهایی که خیلی مربوط به توسعه‌دهنده هستند، تمرکز نکنیم. چون در این مسائل می‌توانید با تیم‌تان صحبت کنید: «الگوی طراحی درست برای این ویژگی چیست؟ و ...» بیشتر روی مسائلی تمرکز می‌کردیم که فکر می‌کردیم مناسبِ همکارانِ در آن سطح بود.به نظر می‌رسد ایجاد شبکه‌ی حمایتی راهبرد خوبی باشد. بیایید به فرایندِ تبدیل شدن به رهبر فنی نگاه کنیم. وقتی که از تعطیلات بر می‌گشتید در فرودگاه با شما تماس گرفتند و با این یک تماس شما از یک توسعه‌دهنده به یک رهبر فنی تبدیل شدید. آیا در این مسیر قدم برمی‌داشتید یا اتفاقی بود؟فکر می‌کنم «بر سرم آمد» بهترین راه توصیف آن باشد. من راهی جز صحبت کردن با دیگران برای یافتن حمایت و پشتیبانی نداشتم. خوش‌حالم که افرادی بودند که با آن‌ها صحبت کنم اما اگر می‌دانستم مسئولیت‌هایم چه هستند و چطور باید آن را انجام دهم، خیلی بهتر بود.بعد از این تجربه به دنبال کتاب‌هایی در این موضوع گشتم. قدیمی‌ترین کتابی که پیدا کردم «رهبر فنی شدن» (Becoming Technical Leader) نوشته‌ی جرالد واینبرگ بود. کتاب خیلی خوبی بود و ابزارهای خوبی در اختیار قرار می‌دهد اما فکر می‌کنم به درد هر کسی در هر محیط فنی بخورد و خاص رهبران فنی نیست. در کمک کردن به افراد برای این‌که معنی رهبر فنی موفق را درک کنند، یک جای خالی را حس می‌کردم. این یکی از دلایلی بود که نوشتن کتابم را شروع کردم که مجموعه‌ای از مصاحبه‌هاست با عنوان «گفتگو با رهبران فنی» (Talking with Tech Leads).بعداً کمی در مورد کتاب صحبت می‌کنیم. کنجکاوم بدانم که وقتی به طرز ناگهانی در نقش دیگری شروع به کار می‌کنید،‌ متوجه چه چیزهایی می‌شوید؟ وقتی به رهبر فنی تبدیل می‌شوید چه چیزهایی تفاوت می‌کنند؟ این‌طور نیست که یک روزه آدم دیگری بشوید؟نه :-) فکر می‌کنم بخشی از دشواری این است که اولاً وقتی کسی این نقش را به شما می‌دهد، عدم قطعیت وجود دارد. اغلب میزان زیادی اضطراب دارید: «آیا کارم را به درستی انجام می‌دهم؟» خیلی دشوار است که فهرستی از مسئولیت‌ها یا زمینه‌هایی که باید بر آن تمرکز کنید، تهیه کرد. من از چیزهایی که نمی‌دانستم، آگاهی نداشتم و می‌دانستم که احتمالاً چیزهایی هستند که باید به دنبال آن باشم اما درباره‌شان نمی‌دانم. سعی می‌کردم با افراد درباره‌ی کارهایی که انجام نمی‌دهم ولی باید انجام دهم، صحبت کنم. در عین حال تلاش کردم به خودم بفهمانم: من از سطح مهارت‌های توسعه‌ی خودم راضی‌ام اما قطعاً مهارت‌های رهبری هم هست که در عنوان این نقش هست. این‌ها به چه معنی است؟ کجا می‌توانم آن‌ها را بهبود بخشم؟ درک نحوه ی ارتباط کارآمد، خصوصاً با ذی‌نفعان غیرفنی و فنی. چطور به مناقشات رسیدگی کنم؟ چطور بدون نوشتن کد، روی افراد تأثیر بگذرام؟ این مسائل مربوط به معماری رهبر فنی چه هستند؟ و تلاش کنم در این زمینه‌ها مهارت پیدا کنم.آیا توسعه‌دهندگان تیم شما کاری انجام دادند که در این فرایند جابجایی به شما کمک کند؟ آیا به طور عمومی، توسعه‌دهندگان می‌توانند کاری در در حمایت از یک رهبر فنی تازه‌کار انجام دهند؟بله. اگر به چند تا از تیم‌های قبلی‌ام فکر کنم، دریافت بازخورد از چند منبع به من کمک کرد. یکی از ابزارهای مورد علاقه‌ی من برای این‌کار، چرخه‌ی بازخورد ۳۶۰ درجه است، که در جلسات دو نفره یا سایر جلسات از آن استفاده می‌کردم. گاهی اوقات می‌توانیم کنار هم بنشینیم. دیده‌ام که سایر رهبران فنی فکر می‌کنند که کارشان عالی است، اما توسعه‌دهندگان نظر متفاوتی دارند. فکر می‌کنم یک رهبر فنی باید خود را مجبور به دریافت بازخورد از منظر توسعه‌دهندگان کند. اگر اعتمادسازی نکرده باشید، کار سختی است اما فکر می‌کنم واقعاً امر مهمی است و اگر این رفتار را با تیم‌تان داشته باشید اعتماد،‌ عمیق‌تر می‌شود.اگر بتوانید این سؤالات را مطرح کنید «من به عنوان یک رهبر فنی چه می‌کنم و تو چه انتظاراتی داری؟ آیا من آن‌ها را برآورده می‌کنم؟ فکر می‌کنی در کدام زمینه ضعیف‌تر هستم یا می‌توانم بهبود پیدا کنم؟ در کدام زمینه کارم را خوب انجام می‌دهم؟» در اینصورت دیدگاه بهتری نسبت به آن خواهید داشت و می‌توانید آن را در سطح تیم بررسی کنید.بنابراین بازخورد گرفتن ابزار مهمی است. اگر مایل هستید بگویید خود شما چه بازخوردهایی دریافت کردید؟بازخوردی که من از تیمم دریافت کردم -که یک مسئله‌ی شخصی است- این بود که وقتی زیاد بین مسائل جابجا می‌شوم چون وظیفه‌گرا هستم، خیلی آمرانه برخورد می‌کنم. بازخوردی که گرفتم این بود که خصوصاً وقتی مضطرب هستم، به افراد برای صحبت کردن در مورد مسائل و مشکلات فرصت کافی نمی‌دهم و فقط روی این‌که «چطور آن را برطرف کنیم» تمرکز می‌کنم. این برای من یک نقطه‌ی عطف بود. چون اولاً وقتی مضطرب هستید نمی‌دانید چقدر روی رفتار شما تأثیر گذار است و هر کدام از ما به شکل متفاوتی با آن برخورد می‌کنیم. به علاوه، این به من کمک کرد بفهمم که تیم چه مشکلی دارد و روی سازوکاری برای کنار آمدن با اضطراب و جابجا شدن بین مسائل توافق کنیم. یعنی زمان‌هایی برای تمرکز بیشتر داشته باشم و در سایر اوقات افراد بتوانند به من مراجعه کنند.همچنین این مسئله به من کمک کرد بفهمم وقتی مضطرب هستم چطور با افراد رفتار می‌کنم. تلاش کردم به جای این‌که به سرعت به سمت یک راه‌حل خاص بروم به افراد زمان بیشتری بدهم تا با شرایط آشنا شوند.بسیار خوب. بگذارید وارد جمع‌بندی شویم. یک سؤال آزاردهنده در مورد کسانی که برای اولین بار رهبری فنی را تجربه می‌کنند، باقی‌مانده است. آن سؤال این است که از کجا بدانم رهبری فنی‌ام خوب است؟این سؤال خیلی خوبی است :) واقعاً تا به حال به آن فکر نکرده‌ام. هر کس سبک رهبری فنی خودش را دارد. آن‌چه به نظر من خوب است این است که باید رویکردتان به مسائل را درک کنید و بشناسید. یک نشانه از کارامدی رهبر فنی این است که هر روز به او نیاز ندارید. اگر رهبری فنی مدام درگیر جلسات و جواب دادن به همه‌ی مسائل است، احتمالاً رهبر فنی کارآمدی نیست. به یکی از اولین سؤالات شما برگردیم «اصلاً چرا به رهبر فنی احتیاج داریم؟» اگر رهبر فنی کارآمدی باشید، به نقش توسعه‌دهنده برمی‌گردید و هنوز می‌توانید روی تصویر کلی تمرکز داشته باشید و مراقب ناهمسویی‌ها باشید. اگر کارتان را به خوبی انجام دهید، تیم باید [با تصویر کلی] همسو باشد و نباید مناقشات زیادی وجود داشته باشد، یا اگر هم هست خودشان باید بتوانند آن را برطرف کنند و این توافق عمومی باید وجود داشته باشد.بسیار خوب. شما کتابی با عنوان «گفتگو با رهبران فنی» (Talking with Tech Leads) نوشته‌اید. در این کتاب با تعداد زیادی از رهبران فنی مصاحبه کرده‌اید و سؤالاتی یکسان را از آن‌ها پرسیده‌اید. در این کتاب چند دیدگاه در مورد نحوه‌ی رهبری فنی وجود دارد. آن‌چه من درباره‌ی این کتاب دوست دارم این است که نشان می‌دهد هر رهبر فنی سبک خاص خودش را دارد. حین انجام دادن این مصاحبه‌ها چه یاد گرفتید؟اول آن چیزی که شما هم به آن اشاره کردید. این‌که رویکردهای متفاوتی برای انجام این کار هست که همه‌ی آن‌ها درست‌اند. وقتی وارد این نقش می‌شوید از خود می‌پرسید:‌‌ «آیا کار درستی انجام می‌دهم؟» شما سبک خود را دارید و صرفاً به این دلیل که یک رهبر فنی در تیم دیگری رویکرد متفاوتی دارد به این معنی نیست که کار شما اشتباه است.ابزارها و رویکردهای متفاوتی وجود داشت که افراد از آن استفاده می‌کردند. یکی از بزرگ‌ترین درس‌هایی که گرفتم این بود که وقتی در نقش رهبر فنی هستم زمان کافی برای خودم صرف نمی‌کنم. این یک مشاهده‌ی جالب از جان پیتر در کتاب بود. او تمرکز زیادی بر تعمق (Meditation) و حضور در لحظه داشت تا اطمینان حاصل کند زمان کافی برای کاری که انجام می‌دهد را دارد و زمانش را اولویت‌بندی کند. این یکی از بزرگ‌ترین درس‌هایی بود که از این کتاب گرفتم. این‌که برای خودتان زمان کافی صرف کنید.با چند رهبر فنی صحبت کردید؟فکر می‌کنم در نهایت با ۳۷ نفر صحبت کردم. چند نفر دیگر هم بودند اما خواستم [مطلب] عمق بیشتری داشته باشد. همچنین تلاش کردم رهبران فنی خانم را پیدا کنم. این جالب بود، چون ما به عنوان یک صنعت در جذب توسعه‌دهندگان خانم مشکل داریم و وارد کردن رهبران فنی خانم در کتاب برای من یک هدف شخصی بود. کمک خواستن از شبکه‌ی افرادی که می‌شناختم برای اینکه در این مورد با چه کسی صحبت کنم، برایم جالب بود.رهبران فنی در مورد چه چیزی حرف می‌زدند؟ موضوعات اصلی چه بودند؟کتاب به دو بخش تقسیم می‌شود. یک بخش روی تازه‌کارها تمرکز دارد و بخش دیگری که افراد باتجربه‌تری در آن هستند و گاهاً به آن‌ها متخصص گفته می‌شود. جالب بود که برای تازه‌کارها اشتراک زیادی در زمینه‌ی شوکه شدن وجود داشت. اینکه: «من یک توسعه‌دهنده بوده‌ام و الان در نقش رهبر فنی هستم. این به چه معنی است؟» این برای من جالب بود که همه، مشکلات مشابهی داشتند چون امیدوارم این به افراد کمک کند که بدانند اگر برای نخستین بار به این نقش وارد می‌شوند، این مسئله عادی است.در بخش دوم کتاب، موضوعات دیگری مطرح شدند. یکی مسئله، مدیریت خودتان بود که یک موضوع کامل بود. این موضوع بر اولویت‌بندی زمان و اطمینان حاصل کردن از این‌که آیا زمان‌تان را به کارآمدترین شکل صرف می‌کنید، تمرکز می‌کرد: این‌که ایرادی ندارد زمانی را صرف این کنید که زمان‌تان را صرف چه کاری کنید. فکر می‌کنم این مسئله‌ی مهمی است.بخش دیگری در مورد افراد وجود دارد. فکر می‌کنم پیشرفت در این بخش برای توسعه‌دهندگان دشوارتر باشد. فکر می‌کنم توسعه‌دهندگان به صورت طبیعی به سوی افکار فنی و معماری کشیده می‌شوند که مربوط به بخش فنیِ رهبری فنی است. اما درک سروکار داشتن با شرایطِ دشوارِ مربوط به افراد مسئله‌ای است که به عنوان یک توسعه‌دهنده خیلی به آن نمی‌پردازید. تجربه‌ای ندارید که از آن شروع کنید و زمانی که به این نقش وارد می‌شوید به آن نیاز دارید.بخش آخر مربوط به ارتباط برقرار کردن میان بخش فنی و کسب و کار است. خیلی در مورد آن صحبت نکردیم چون از لحاظ معماری و فنی خیلی مسئله‌ی داخلی‌ای است. نقش رهبر فنی در بسیاری از سازمان‌ها مربوط به ارتباط برقرار کردن با کسب و کار است: تلاش برای این‌که آن‌چه تیم فنی تحویل می‌دهد، ارزش کسب و کار ایجاد کند، به کسب و کار کمک کند معنی اصطلاحات فنی و معماری را بفهمد و پیامدهای هر تصمیم را بداند. این‌که کسب و کار بداند هر تصمیم، فرصت‌های کسب و کار را چطور تحت تأثیر قرار می‌دهد.این آخرین سؤال من بود. الان فرصت دارید که به هر سؤالی که باید می‌پرسیدم جواب دهید. آیا می‌خواهید چیزی بگویید؟ شاید آخرین دُرهای حکمت؟امیدوارم حیطه‌ی وظایف رهبر فنی در نتیجه‌ی برخی کارهایی که انجام داده‌ام، کمی روشن‌تر شده باشد. امیدوارم به افراد کمک کرده باشد که بفهمند مجموعه‌ای از مهارت‌ها و زمینه‌های متفاوت است. پس از آن می‌توان راهی برای تمرین در هر یک از این مهارت‌ها پیدا کرد تا آن را بهبود داد. قطعاً خواهم گفت که شبکه‌ی پشتیبانی خود را بسازید. این یک مسئله‌ی کلیدی است. رهبر فنی بودن نباید یک مسئله‌ی خجالت‌آور باشد. برخی افراد فکر می‌کنند این به معنی گذر کردن از کار فنی است، در حالی‌که به معنی تأثیرگذاری مثبت است. گاهی اوقات به عنوان یک توسعه‌دهنده از محیطی که در آن هستید خسته می‌شوید اما به عنوان یک رهبر فنی شما این محیط را شکل می‌دهید. این یک فرصت جذاب است.خیلی متشکرم. افراد چطور درباره‌ی این موضوع بیشتر اطلاعات کسب کنند؟ واضح است که می‌توانند کتاب را بخرند و بخوانند.من زیاد در مورد این موضوعات مربوط به رهبری فنی، بلاگ می‌نویسم. آدرس آن www.patkua.com است. در توئیتر هم خیلی فعال هستم و خیلی دوست دارم سؤالات، معماها و افکار شما در مورد رهبر فنی را بشنوم. من فکر می‌کنم از صحبت کردن با افراد و مشکلاتی که دارند خیلی یاد می‌گیرم و دوست دارم تجربه‌هایم را به اشتراک بگذارم. آدرس توئیتر من patkua@ است. سایت کتاب هم هست که می‌توانید آن را در leanpub پیدا کنید.پاتریک، بابت این مصاحبه خیلی از شما متشکرم. فکر می‌کنم خیلی جالب بود.متشکرم که من را دعوت کردید. سؤالات خوبی داشتید و من از بحث لذت بردم. سید مرتضی هاشمی سید مرتضی هاشمی Sat, 09 Jul 2022 19:33:13 +0430 https://virgool.io/se-radio/se-radio-mechanical-sympathy-a53nmrnekotw مطلبی که می‌خوانید ترجمه‌ی قسمت ۲۰۱ از رادیو مهندسی نرم‌افزار است. رادیو مهندسی نرم‌افزار هر یکی دو هفته یک بار مصاحبه‌ای درباره‌ی یکی از موضوعات حوزه‌ی مهندسی نرم‌افزار با افراد خبره و با تجربه در موضوع مورد بحث ترتیب می‌دهد.در این قسمت رابرت بلومن با مارتین تامسون که یکی از متخصصان پیش‌رو در تنظیم و بهبود کارایی سیستم‌های کامپیوتری است مصاحبه می‌کند. در این قسمت بحث می‌شود که چطور داشتن پیش‌زمینه و درک از عملکرد سخت‌افزاری و مکانیک کامپیوتر می‌تواند شما را در طراحی و توسعه‌ی مؤثرتر سیستم‌های نرم‌افزاری یاری دهد. مارتین یک سخنران در کنفرانس‌های فناوری، بنیان‌گذار شرکت LMAX، یکی از بنیانگذاران پروژه متن بازِ Disruptor، و صاحب بلاگی به نام درک مکانیکی (Mechanical Sympathy) است. او در حال حاضر صاحب Real Logic Ltd. است که یک شرکت مشاوره در زمینه‌ی سیستم‌های کامپیوتری در لندن است.مارتین لطفاً کمی در مورد سوابق خود به شنوندگان ما بگویید. چطور به مبحث کارایی علاقه‌مند شدید؟[این موضوع] خیلی جالب است. من کارهای زیادی در طول دهه‌های اخیر انجام دادم. اما همیشه به سمتی کشیده می‌شدم که کارایی کامپیوتر افزایش پیدا می‌کرد. در آنجا فرصت‌هایی ایجاد می‌شد که قبلاً وجود نداشت. فکر می‌کنم اولین کاری که در این زمینه انجام دادم به سال ٩٢ بر می‌گردد که اطلاعات فرابورس را می‌گرفتم. در آن زمان مجبور بودیم همه چیز را روی Main Frame های IBM پردازش کنیم. این اطلاعات روی دو هارد دیسک که روی یک کامپیوتر نصب شده بودند، جا می‌شد. آن موقع اندازه‌ی هارد دیسک‌ها حدود 250 مگابایت بود. اما امروز ما نهان‌گاه‌ها (Cache) را برای نگه‌داری این [حجم] اطلاعات داریم و این فرصت‌هایی را در کسب و کار ایجاد می‌کند که قبلاً امکان‌پذیر نبود.فعالیت‌های حرفه‌ای من شامل چیزهای متفاوتی بوده است: مدل‌سازی وسایل نقلیه، کار با فهرست‌های بزرگ، کار با سیستم‌های تجاری. سیستم‌هایی که واقعاً با هم متفاوتند، اما تنظیم کارایی و دستیابی به توان عملیاتی (Throughput) بالا بخشی از اکثر این کارها بوده است.اسم بلاگ شما درک مکانیکی است، منظورتان از آن چیست؟درک مکانیکی اصطلاح جالبی است. من از طرفداران مسابقات موتورسواری هستم؛ این اصطلاح از آن‌جا نشأت گرفت. Jackie Stewart نام موتورسواری در دهه‌های 60 و 70 است که موتورسوار فوق‌العاده موفقی بود و در زمین‌های مرطوب خیلی خوب عمل می‌کرد. او در مورد داشتن حس درک مکانیکی با موتوری که سوارش بود صحبت می‌کرد. زمانی که آن وسیله را درک می‌کرد، نسبت به بقیه‌ی موتور سوارها بهتر عمل می‌کرد و این در زمین‌های مرطوب به خوبی نشان داده می‌شد. در یک جمله درک مکانیکی یعنی به کارگیری قابلیت‌ها تا مرز توانایی آن و نه فراتر از آن، تا بهترین نتیجه حاصل شود. برای او درک مکانیکی به معنی هماهنگی در کار کردن با موتورش بود و برای من هم چیزی شبیه به این در سخت‌افزار و نرم‌افزار است. هر زمان که نرم‌افزار نحوه‌ی کارکرد سخت‌افزار و بستر سخت‌افزاری را درک کند، با آن هماهنگ می‌شود و بهترین نتیجه حاصل می‌شود.امروزه تعداد زیادی از نرم‌افزارها را می‌بینیم که بر خلاف سخت‌افزار عمل می‌کنند و درک خیلی محدودی از آن دارند. در نتیجه نه تنها کارایی پایینی دارند، بلکه ممکن است دچار مشکلات دیگری هم بشوند: چون ابزارها به درستی استفاده نشده‌اند، در شرایط مرزی مشکلات بروز می‌کنند. این به آن معنی نیست که شما باید تمام جزئیات را مانند یک فرد خبره بفهمید، تنها دانستن موارد مهم کافی است. مثلاً در مسابقات موتورسواری لازم نیست بدانم که موتور چطور ساخته شده است، فقط لازم است بدانم چطور کار می‌کند. بنابراین لازم است مفاهیم اساسی نحوه‌ی کارکرد جعبه دنده و سیستم تعلیق را بفهمم. با دانستن این موارد در سطح پایه‌ای می‌توان بهترین نتیجه را گرفت. در نرم‌افزار هم همین‌طور است.می‌شود یک نمای کلی از مواردی که به نظرتان توسعه‌دهندگان نرم‌افزار به آن آگاهی ندارند، به ما بگویید؟بله، مثال‌های خوب زیادی در این زمینه وجود دارد. بسیاری از آن‌ها در حقیقت نام‌گذاری‌هایی هستند که استفاده می‌کنیم و ما را در جهت اشتباه هدایت می‌کنند. نام‌هایی که برای چیزهای خیلی مهم در برنامه‌ها به کار می‌بریم. مثلاً در مورد حافظه با دسترسی تصادفی (Random Access Memory) صحبت می‌کنیم، در حالی که دسترسی به حافظه به هیچ وجه تصادفی نیست. تفاوت قابل توجهی میان دسترسی خطی با دسترسی تصادفی به حافظه وجود دارد. به علت نحوه‌ی عملکرد سخت‌افزار برخی اطلاعات با تأخیر کمتری به حافظه‌ انتقال پیدا می‌کنند.اگر دسترسی به خانه‌های پشت سر هم در حافظه باشد، سخت‌افزار می‌تواند تقریباً تأخیرها را به کلی پنهان کند و دسترسی در زمانی کوتاه در حد چند نانو ثانیه صورت خواهد گرفت. در صورتی که اگر به صورت تصادفی به آن دسترسی پیدا کنم این زمان به چیزی حدود ٧٠ تا ١٠٠ نانو ثانیه افزایش پیدا می‌کند (همان کامپیوتر و همان قابلیت‌های سخت‌افزاری که با الگوی متفاوتی به حافظه دسترسی پیدا کرده است). بنابراین اجازه دهید که بگویم حافظه خیلی شبیه به یک دستگاه خطی مثل نوار عمل می‌کند تا یک دستگاه با دسترسی تصادفی. هارد دیسک‌ها هم ویژگی‌های مشابهی دارند، حتی SSD ها هم برخی از این ویژگی‌ها را دارند، اما بیشتر افراد از این مسائل آگاهی ندارند و بدون اینکه بدانند حافظه چگونه کار می‌کند به آن دسترسی پیدا می‌کنند و در نتیجه دچار مشکلات کارایی می‌شوند.حین خواندن قسمت‌هایی از بلاگ شما یک مسئله به صورت پررنگ دیده می‌شود و آن این است که بخش عمده‌ای از کارایی برنامه تحت تأثیر رابطه‌ی میان هسته‌های CPU و لایه‌های نهان‌گاه (Cache) آن است. کمی در مورد اهمیت این موضوع توضیح دهید.این چیزی است که زمانی که یک نرم‌افزار مدرن را پروفایل می‌کنید زیاد به آن بر می‌خورید. ما حافظه‌ی خیلی کوچکی در نهان‌گاه داریم که در سلسله مراتبی از نهان‌گاه‌ها سازمان‌دهی شده است. در هر سطح میزان حافظه افزایش پیدا کرده و در مقابل تأخیر دسترسی هم افزایش پیدا می‌کند. CPU هیچ وقت روی حافظه کار نمی‌کند، بلکه محتویات آن را در ثبات‌های داخلی ذخیره کرده، عملیات را روی ثبات‌ها انجام داده و نتیجه را به دست می‌آورد. حتی این نتیجه را به صورت مستقیم در حافظه قرار نمی‌دهد، بلکه آن را در زیرسیستم نهان‌گاه ذخیره می‌کند.در تمامی سیستم‌های کامپیوتری مدرن زیر سیستم نهان‌گاه منبع اطلاعات است و هنگامی که به نقطه‌ی تخلیه (Point of Exhaustion) برسیم، محتویات نهان‌گاه در حافظه ذخیره می‌شود. نهان‌گاه‌ها از الگوریتمِ «اخیراً کمتر استفاده شده» (Least Recently Used) برای تبادل داده‌ها استفاده می‌کنند و این خوب است. داده‌هایی که اخیراً مورد استفاده قرار گرفته‌اند، احتمالاً در نهان‌گاه باقی می‌مانند. علاوه بر این نهان‌گاه حافظه را تکه تکه دریافت می‌کند و نه بایت به بایت. این تکه‌ها ممکن است با توجه به اینکه در چه سطحی از نهان‌گاه هستیم، به اندازه خط نهان‌گاه (Cache Line) یا صفحات (Page) باشند. بنابراین حافظه‌های نزدیک به هم، با هم وارد نهان‌گاه می‌شوند. مسئله‌ی دیگر پیش‌واکشی‌های سخت‌افزاری (Hardware Pre-fetcher) هستند که با بررسی الگوهای دسترسی در کد و بر اساس آن، قسمتی از حافظه را پیش از دسترسی به آن، واکشی می‌کنند.دسترسی به نهان‌گاه سطح ١ که پردازنده‌ها مستقیماً با آن کار می‌کنند تنها ٣ تا ٤ چرخه طول می‌کشد. بعد از آن سطح ٢ است که نهان‌گاه بزرگ‌تری است و در پردازنده‌های امروزی حدود ٢٥٦ کیلوبایت حافظه دارد که به مراتب بیشتر از ٣٢ کیلوبایت در سطح قبلی است. بعد از آن سطح ٣ است که چیزی بین ٢ تا ٣ مگابایت حافظه دارد. همین‌طور که حافظه افزایش پیدا می‌کند تأخیر هم افزایش پیدا می‌کند.همه‌ی این‌ها زمانی اهمیت پیدا می‌کند که می‌خواهیم الگوریتمی را انتخاب کنیم. در دانشگاه‌ها به ما در مورد پیچیدگی الگوریتم‌ها آموزش داده شده است، اما در محاسبه‌ی این مرتبه‌ی پیچیدگی، سخت‌افزار در نظر گرفته نشده است. یک مثال خوب در این مورد، لیست پیوندی است. اگر یک لیست پیوندی را پیمایش کنیم، مرتبه‌ی آن می‌بایست با پیمایش یک آرایه یکسان باشد. اگر به مرتبه‌ی الگوریتم آن نگاه کنم متوجه نمی‌شوم دسترسی به آن چند برابر بیشتر از آرایه است، اما می‌بینم که دسترسی تصادفی به آرایه به مراتب سریع‌تر از لیست پیوندی است.مسئله‌ی مهم‌تر این است که زمانی که یک لیست پیوندی را پیمایش می‌کنیم، گره‌ی بعدی ممکن است در هر جایی از حافظه قرار گرفته باشد. در نتیجه یک دسترسی تصادفی به حافظه خواهیم داشت و پیش‌واکشی‌های سخت‌افزاری نمی‌توانند کمکی کنند. دریافت حافظه‌های نزدیک به هم، هم کمکی نمی‌کند. نگه‌داشتن آخرین اطلاعات استفاده شده هم کمکی نمی‌کند. بنابراین دسترسی به یک لیست پیوندی بزرگ در مقایسه با یک آرایه‌ی بزرگ می‌تواند به مراتب زمان‌گیرتر باشد. چنین الگوهایی در نگاشت‌ها (Map) و درخت‌ها (Tree) و سایر ساختارها نیز دیده می‌شوند.فکر می‌کنم منظور شما این است که معماری سخت‌افزار، برخی فرض‌ها را در مورد نحوه‌ی دسترسی برنامه به حافظه در نظر می‌گیرد که در صورتی درست از آب در می‌آید که برنامه نویس‌ها هم آن‌ها را در نظر بگیرند.بله، درست است. فرضیات زیادی وجود دارد، یکی از آن‌ها را گفتم. مطلب دیگر این است که تعداد ترانزیستور‌ها و هوشمندی پردازنده‌ها همواره در حال افزایش است، ولی این رشد اساساً محدود است. اگر به طور کاملاً تصادفی به حافظه دسترسی پیدا کنید، بدترین کارایی حاصل می‌شود چون سخت‌افزار نمی‌تواند به شما کمکی کند. در حقیقت مسئله فراتر از این است؛ فقط داده‌ها نیستند که بر کارایی تأثیرگذارند، بلکه جریان دستورالعمل‌ها نیز در آن مؤثر است. پردازنده‌ها اطلاعاتی آماری در مورد انشعاب‌های برنامه را نگه‌داری کرده و بر اساس آن پیش‌بینی‌هایی از مسیر انشعاب‌های بعدی انجام می‌دهند. پردازنده‌های مدرن مسیر انشعاب‌ها را پیش‌بینی می‌کنند، چون ممکن است داده‌های (لازم برای انجام محاسبات) آن هنوز آماده نباشند. بنابراین در حالی که منتظر دریافت اطلاعات هستند، فرضی را در مورد انشعاب (درست یا غلط بودن آن) در نظر گرفته و اجرای دستورالعمل‌های بعدی را ادامه می‌دهند. در صورتی که بعداً معلوم شود که فرض اشتباه بوده، می‌بایست نتایج این محاسبات دور ریخته شود. در صورتی که فرض درست باشد، کار از پیش در حال اجرا بوده و کد سریع‌تر شده است. بنابراین با توجه به این‌که این اطلاعات آماری نگه‌داری می‌شود، برنامه باید رفتاری قابل پیش‌بینی داشته باشد و از الگوهای مشابهی پیروی کند. در صورتی که رفتار تصادفی باشد، مزیت ذکر شده از دست می‌رود. مسئله‌ی جالب این است که در صورتی که در مورد الگوریتم‌ها و کاربرد آن فکر شود، بسیاری از انشعاب‌ها در برنامه می‌توانند با محاسبات ریاضی جایگزین شوند یا این‌که می‌شود مدل تمیزتر و ساده‌تری از مسئله ارائه کرد.اطلاعات زیادی در مورد نحوه‌ی عملکرد پردازنده‌های مدرن و سیستم‌های زمان اجرا وجود دارد و اگر واقعاً می‌خواهید به کارایی بالا دست پیدا کنید، به توابع کوچک، ساده، خطی، و با قابلیت ترکیب بالا نیاز دارید. بهبود کارایی توابع بزرگ با انشعاب‌ها و حلقه‌های زیاد، در سطح پردازنده و سیستم‌های زمان اجرا (Runtime System) کار فوق‌العاده دشواری است. در مقابل، کد تمیز و قابل پیش‌بینی بسیار سریع اجرا می‌شود، علاوه بر این خواندن و درک آن برای انسان‌ها هم ساده‌تر است؛ این‌ها با یکدیگر مغایر نیستند. من زیاد می‌شنوم که افراد می‌گویند: اگر من کدم را برای کارایی بالاتر بهبود دهم، خوانایی آن از دست می‌رود. به نظر من این درست نیست. در واقع کاملاً برعکس است. مجموعه‌ای از توابع موزون و زیبا، با وظایف تفکیک شده، دارای همبستگی بالا، ساده و قابل ترکیب با هم، در بیش از ٩٠% موارد کاربرد، عملکرد فوق‌العاده چشم‌گیری دارند. شرایط خاصی نیز وجود دارد که نیاز به کارهای خاص دارد، اما آن‌ها استثناء هستند.چند دقیقه پیش در مورد آرایه‌ها و لیست‌ها صحبت می‌کردید. من به یکی از مطالب بلاگ شما برخوردم که گفتید بسیاری از کتابخانه‌های استاندارد مربوط به ساختمان داده‌های پایه که در زبان‌های برنامه‌نویسی متداول وجود دارند، خیلی مناسب سخت‌افزار (Machine Friendly) نیستند. آیا این درست است؟بله، کاملاً درست است. برای مثال، در محبوب‌ترین زبان برنامه‌نویسی دنیا، جاوا، اگر بخواهم چینشی به صورت ساختار آرایه‌ای داشته باشم -یک علت خوب برای این کار پیاده‌سازی بهتری از HashMap است- می‌بایست آرایه‌ای از ارجاع‌ها (Reference) داشته باشم. هر کدام از این ارجاع‌ها به گره‌هایی اشاره می‌کنند که ابتدای یک زنجیره را نشان می‌دهند. هرکدام از این زنجیره‌ها، مربوط به یک Bucket در داخل HashMap هستند. اگر می‌توانستم از مکان شروع هر کدام از Bucketها، یک ساختار آرایه‌ پیوسته داشته باشم، کارایی خیلی بهتر بود.این‌ها چیزهایی هستند که در JDK استاندارد وجود ندارند. در واقع JDK کاملاً برای تولید مداوم خطاهای نهان‌گاه (Cache Miss) طراحی شده است. در مقابل ساختار Dictionary در #C با یک چینش (Layout) بسیار مناسب در حافظه پیاده‌سازی شده است. من کارایی را برای مجموعه داده‌هایی بیش از 2 گیگابایت در .NET و جاوا اندازه گرفته‌ام و .NET حداقل 10 برابر سریع‌تر است.مثال‌های زیادی دیگری هم وجود دارد. ما به تغییرات زیاد دیگری هم در جاوا نیاز داریم. بیشتر اوقات ما از انواع اولیه (Primitive) به عنوان کلید استفاده می‌کنیم، مثلاً long یا integer. اگر از آدرس‌دهی باز (Open Addressing) و کاوش خطی (Linear Probing) در HashMap ها استفاده کنیم، کارایی به مراتب بیشتری خواهیم داشت، چون با hash کردن، مستقیماً به یک مکان رفته و به صورت خطی در حافظه حرکت می‌کنیم. این فقط یک مورد است، می‌توانم در مورد درخت‌ها هم بگویم.افراد عمدتاً درخت‌های دودویی طراحی می‌کنند. در صورتی که باید درخت‌های nتایی طراحی کنیم که به بلاک‌هایی اشاره می‌کنند که تعدادی گره دارند و هر گره چند فرزند دارد. می‌بایست روش‌هایی مشابه آن‌چه در دیسک‌ها برای توسعه‌ی پایگاه‌های داده به کار می‌روند را در ذخیره‌سازی ساختارهای خود در حافظه نیز به کار ببریم. بسیاری از ساختارهایی که در زبان‌های متداول از آن‌ها استفاده می‌کنیم با این طرز فکر طراحی نشده‌اند.مسئله از این هم فراتر می‌رود. کسانی که کتابخانه‌ی مجموعه‌ها (Collection) را در جاوا توسعه می‌دهند، در جاهایی که ثوابت و ضرایبی وجود دارد توضیحاتی در کد قرار داده‌اند که می‌توانید آن را بخوانید. این توضیحات می‌گویند که این مقادیر می‌بایست به طور مرتب بر اساس اندازه‌گیری‌ها بازبینی شوند. کدها خیلی سال‌ پیش نوشته شده‌اند و طبق اطلاعاتی که من دارم، این مقادیر هرگز به روز رسانی نشده‌اند.یک سؤال دیگر در رابطه با کتابخانه‌ها دارم. در یکی از کنفرانس‌های سانفرانسیسکو در مورد تنظیم کارایی صحبت می‌کردید و بر هزینه‌ی بالای کپی کردن اطلاعات تأکید داشتید و اینکه کارایی برنامه‌ها عمدتاً تحت تأثیر یک کتابخانه‌ی خارجی (Third Party) قرار می‌گیرد. مثلاً یک پیاده‌سازی از JDBC یا Message Queuing که در آن نسخه‌های غیرضروری از اطلاعات نگه‌داری می‌شود. زمانی که سیستمی را توسعه می‌دهید و گلوگاه شما در یک کتابخانه‌ی خارجی است چه کار می‌کنید؟این یک چالش جالب است. در بهترین حالت می‌توانید از کتابخانه‌ی دیگری استفاده کنید، اما همیشه نمی‌شود این کار را کرد. فکر می‌کنم اکثر کتابخانه‌ها بعداً به کتابخانه تبدیل شده‌اند (از ابتدا تصمیم به توسعه‌ی کتابخانه نبوده است). JDBC مثال خیلی خوبی است که در طول زمان بهبود پیدا کرده اما هنوز مشکلاتی دارد. مثلاً هنوز کتابخانه‌های JDBC که Non-blocking و ناهمگام (Asynchronous) باشند، وجود ندارند در حالی که باید چنین کتابخانه‌هایی وجود داشته باشد. این مسئله در طراحی‌های فعلی لحاظ نشده است. اگر به گذشته نگاه کنیم می‌بینیم که کد همیشه توسط چند تیم نوشته شده است و بافرها بین لایه‌های مختلف و متعدد جابجا می‌شوند و به همین علت کارایی پایینی دارند. گاهی اوقات این الگوها از C گرفته شده است که تبادل اطلاعات توسط اشاره‌گرها انجام می‌شود، اما در جاوا عمدتاً این‌طور نیست. چون قسمت‌های زیادی از کد برای کار با بخشی از یک آرایه طراحی نشده است، از کپی کردن استفاده شده است. خیلی زیاد به این موارد بر می‌خورید. در جاوا حتی اگر به کد برنامه‌ها دسترسی نداشته باشید می‌توانید بایت کد را به کد تبدیل کرده و کارایی آن را بررسی کنید و این مشکلات را ببینید. در برخی موارد من مجبور شدم کتابخانه‌ها را Decompile کرده، مشکلات را در برخی نقاط حل کنم و مشکل را به اطلاع تولید کننده برسانم. یا در برخی موارد دیگر پیاده‌سازی مشتری را به طور کامل تغییر دهم.دوست دارم کمی در مورد پردازش چندهسته‌ای صحبت کنیم. یک مقاله یا نقل قول هست که می‌گوید: "دیگر از ناهار مجانی خبری نیست" (The free lunch is over). منظور گوینده از این جمله چیست؟فکر می‌کنم شما به مقاله‌ی معروف هرب ساتر اشاره می‌کنید. من حوالی سال ٢٠٠٧-٢٠٠٨ آن را خواندم. منظور هِرب این بود که ما در فرایند کوچک‌تر کردن اندازه‌ی پردازنده‌ها به نقطه‌ای رسیده‌ایم که دما آن‌قدر زیاد شده که دیگر نمی‌توان سرعت ساعت (Clock Speed) را افزایش داد. گویی در طول سال‌های اخیر از یک وعده‌ی ناهار مجانی استفاده می‌کردیم که در آن هر ١٨ ماه، سرعت پردازنده‌هایمان در نتیجه‌ی افزایش سرعت ساعت و بهبود فرآیند تولید، دو برابر می‌شد.ادامه‌ی این روند و افزایش سرعت پردازنده‌ها به بیش از ٤ گیگاهرتز، با توجه به میزان گرمای تولید شده، خیلی مشکل است. بنابراین پردازنده‌ها سریع‌تر نمی‌شوند، در حقیقت سریع‌تر می‌شوند اما رشد آن به شدت کاهش پیدا کرده است. چون سرعت ساعت تقریباً تغییر نکرده و در عوض پردازنده‌ها هوشمندتر می‌شوند، سیستم‌های نهان‌گاه هوشمندتر می‌شوند.پردازنده‌ها به خودی خود محدودیت‌های سیستم ما نیستند. اگر اکثر سیستم‌ها را بررسی و اندازه‌گیری کنید متوجه می‌شوید که پردازنده‌ها در اکثر مواقع بیکار هستند و اطلاعات با سرعت کافی به آن‌ها نمی‌رسد. مسئله‌ی اصلی اینجاست: «چطور داده‌ها و دستورالعمل‌ها را به پردازنده با سرعت کافی برسانیم؟» در اینجاست که نقش زیر سیستم‌های حافظه، شناخت ساختار سلسله مراتبی آن‌ها، غیر یکنواخت شدن (Non uniform) و نحوه‌ی کار کردن آن اهمیت پیدا می‌کند.ممکن است به اصطلاح NUMA (یا Non-Uniform Memory Architecture) برخورد کرده باشید. من به بسیاری از افراد بر می‌خورم که یک سرور دارای چند گره خریداری می‌کنند و متوجه نیستند که حافظه به هر کدام از آن گره‌ها متصل شده است. فرض کنید یک سرور با دو گره دارید. یک سوکت وجود دارد که حافظه به آن متصل شده است. سوکت دیگری نیز در کامپیوتری که حافظه به آن متصل شده است وجود دارد. این دو سوکت توسط یک مدار اتصال با سرعت بالا به یکدیگر متصل شده‌اند. زمان پیمایش از یک طرف به طرف دیگر این مدار اتصال ٢٠ نانو ثانیه است، بنابراین رفت و برگشت حدود ٤٠ نانو ثانیه است. اگر من از سوکت یک پردازنده به حافظه‌ی پردازنده‌ی دیگر دسترسی پیدا کنم، ٤٠ نانوثانیه زمان صرف خواهم کرد و مهم نیست اطلاعات در نهان‌گاه است یا در حافظه یا جای دیگر. خیلی مواقع با در نظر گرفتن چنین مواردی می‌توان به افزایش چشم‌گیر در سرعت دست یافت. اگر برنامه‌ی من که ممکن است یک برنامه‌ی C یا جاوا یا هر چیز دیگر باشد، منابع کافی از قبیل حافظه و تعداد کافی هسته‌های پردازنده را برای اجرا در اختیار داشته باشد، می‌تواند تا سه برابر سریع‌تر عمل کند اما این در صورتی است که برنامه این منابع را روی یک گره در اختیار داشته باشد، نه اینکه روی چند سیستم پخش شده باشد (که رفتار پیش‌فرض سیستم عامل است).در گذشته اگر می‌خواستید یک سیستم بزرگ، با حافظه یا تعداد هسته‌های زیاد بخرید به شرکت‌های بزرگ مثل IBM، Sun یا HP مراجعه می‌کردید و آن‌ها در مورد نرم‌افزارها، سخت‌افزارها و کاربردهای مورد نیاز شما از شما سوال می‌کردند تا شما محصول درست را خریداری کنید. اما امروز شما خودتان این کارها را انجام می‌دهید. با مراجعه به سایت شرکت فروشنده و چند کلیک، محصول به شما تحویل می‌شود. مشکل اینجاست که افراد فکر می‌کنند هر چه بیشتر، بهتر: سوکت‌های بیشتر، حافظه‌ی بیشتر، چیزهای بیشتر روی کامپیوتر. در صورتی که زمانی که تعداد سوکت‌های یک کامپیوتر بیشتر می‌شود به این معنی است که هزینه‌ی رفت و آمد میان گره‌ها افزایش پیدا می‌کند و تأخیر زیادی به دسترسی‌های حافظه تحمیل می‌شود. در نتیجه با اینکه شما هزینه‌ی بیشتری کردید سرعت برنامه کاهش پیدا می‌کند. علت این مسئله کمبود درک مکانیکی از سخت‌افزاری است که استفاده می‌کنیم.آیا درست است که بگوییم سرعت برنامه با استفاده از n هسته‌ی پردازنده، n برابر نمی‌شود؟به نظرم خیلی درست است. اگر اکثر سیستم‌ها را بررسی کنید متوجه می‌شوید که بیشتر اوقات هسته‌های پردازنده بیکار هستند. در واقع یک یا دو هسته ١٠٠% مشغول هستند و مابقی بیکارند. علت این است که طراحی برنامه دارای نقاط ازدحام (Contention Point) است. نقطه‌ی ازدحام به این معنی است که گلوگاهی وجود دارد و همه چیز می‌بایست از آن عبور کند. این مشکل ممکن است فراتر از نرم‌افزار باشد، ممکن است مربوط به سیستم زمان اجرا باشد.مثلاً اگر در حال استفاده از سیستم زمان اجرای جاوا مقدار زیادی حافظه بگیرید و لازم شود Garbage Collector احضار شود، باید وضعیت تمامی نخ‌ها (Thread) ذخیره شده و متوقف شود تا Garbage Collector بتواند کارش را انجام دهد. ذخیره کردن وضعیت نخ‌ها به معنی عدم پیشرفت برنامه و بیکار ماندن هسته‌هاست. زمانی که می‌خواهید برای متوقف کردن تمامی نخ‌ها، وضعیت آن‌ها را ذخیره کنید، ممکن است یک نخ به سرعت ذخیره شده و ذخیره‌سازی نخ دیگر به دلایلی مثل نگه‌داری آرایه‌ها یا کپی کردن مقادیر حافظه، زمان زیادی بگیرد. در این وضعیت، تا کارها بصورت ١٠٠% به پایان نرسد، برنامه‌ی شما پیشرفتی نخواهد نداشت یعنی تا متوقف شدن همه نخ‌ها و ادامه کارهای JVM از قبیل Garbage Collection، بارگذاری کلاس‌ها، بهینه‌سازی‌ها و خیلی کارهای دیگر. این فقط در مورد جاوا نیست، هر محیط مدیریت شده‌ در زمان اجرای (Managed Runtime) دیگری مثل PHP یا Python هم چنین است. علت این است که از پیش در مورد این مشکلات فکر نشده است. در نتیجه محدودیت‌ها و گلوگاه‌هایی در سیستم زمان اجرا داریم و برنامه‌ها در آن نقاط خطی اجرا می‌شوند و کارمان پیشرفتی نخواهد داشت.بحث JVM را مطرح کردید، دوست دارم که در مورد آن صحبت کنیم. اما می‌خواهم اول در مورد دو مفهوم اصلی در توان عملیاتی سیستم‌ها صحبت کنید: قانون Amdahl و قانون Little.بله، فکر می‌کنم همه افرادی که در ارتباط با سیستم‌های بزرگ با نیازمندی‌های پیشرفته کارایی کار می‌کنند، می‌بایست همواره درک روشنی از این دو قانون داشته باشند.قانون Amdahl محدودیت مقیاس‌پذیری هر الگوریتمی را با اضافه کردن تعداد هسته‌های بیشتر به زیبایی توضیح می‌دهد. برای مثال اگر الگوریتم من ٩٥% موازی باشد، اما ٥% آن می‌بایست به صورت پشت‌سرهم اجرا شود، نمی‌توان بیش از ٢٠ هسته در اختیار آن قرار داد. هر چه تعداد بیشتری هسته در اختیار آن قرار دهید، اثر آن ٥% از کد بیشتر می‌شود، تا جایی که برنامه دیگر سریع‌تر نخواهد شد. تا زمانی که از پردازنده‌های ٢ یا ٤ هسته‌ای استفاده می‌کنید، این موارد در بیشتر مواقع از شما پنهان است، اما زمانی که تعداد هسته‌ها به ١٦، ٣٢ یا ٦٤ هسته افزایش پیدا کند، خیلی سریع این مسئله نمود پیدا می‌کند. اگر در الگوریتم‌هایتان، چنین نقاطی (کدی که قابل موازی سازی نباشد) وجود داشته باشد، از قانون Amdahl گریزی نیست و مقیاس‌پذیری الگوریتم شما اساساً محدود است، حتی اگر درصد ناچیزی از کد باشد. ممکن است افراد برخی جاها این مسئله را فراموش کنند یا متوجه آن نشوند، مثلاً اگر در نرم‌افزارتان یک نهان‌گاه (Cache) داشته باشید که دسترسی به آن، [نیاز به] قفل (Lock) داشته باشد همه‌ی دسترسی‌ها به این نها‌ن‌گاه نوبتی خواهد بود. ممکن است فکر کنید که اضافه کردن این نهان‌گاه کارایی را بهبود داده است اما در حقیقت آن را بدتر کرده است.این توصیف قانون Amdahl و تأثیر مؤلفه‌های غیرموازی در ظرفیت بالقوه‌ی افزایش کارایی یک برنامه است. قانون Amdahl در کنار قانون Little قرار می‌گیرد. قانون Little نظریه صف‌ها را شرح می‌دهد که در نقاط غیرموازی کد رخ می‌دهد. زمانی که چنین نقاطی در کد داشته باشید، تنها یک نفر در آن واحد قادر به استفاده از آن خواهد بود و در نتیجه یک صف تشکیل می‌شود. زمانی که صف در سیستم شما تشکیل شود، تأثیر آن را در تأخیر عملیات می‌بینید: تشکیل صف برابر است با افزایش تأخیر. چون صف‌های شما محدود نیستند، این تأخیر می‌تواند به صورت نامحدود افزایش پیدا کند و حتی بدتر از آن باعث مصرف زیاد حافظه شود.صف‌ها در همه جا حضور دارند، چه افراد متوجه باشند، چه نباشند. هر جا که Semaphore، قفل یا چیزی شبیه به این‌ها وجود دارد، صف هم وجود دارد. این صف‌ها نامحدودند، و ممکن است تا جایی رشد کنند که در سیستم نهان‌گاه جا نشوند و به اجبار در حافظه ذخیره شوند. در نتیجه الگوریتم نهان‌گاه که سعی داشت اقلامی که اخیراً استفاده شده بودند را در نهان‌گاه نگه‌دارد، از این به بعد دچار خطاهای مکرر نهان‌گاه می‌شود و سیستم به سرعت از بین می‌رود. بنابراین اگر صف‌های نامحدود در سیستم شما وجود دارد، دیر یا زود شاهد یک حادثه خواهید بود.یکی از چیزهایی که شما درباره‌ی آن می‌نویسید، مسئله‌ی تحت تأثیر قرار گرفتن کارایی برنامه‌های چند نخی (Multithread) به علت هزینه‌ی هماهنگ‌سازی و تعویض میان نخ‌ها به جای انجام دادن کار مفید است. چرا این‌طور می‌شود؟فکر می‌کنم این به‌خاطر تغییراتی باشد که در سخت‌افزار و توسعه‌ی آن رخ داده است. ما برای مدتی طولانی با سیستم‌های تک‌پردازنده‌ کار می‌کردیم و اکنون پردازنده‌های چند هسته‌ای را داریم. برای مثال اگر من یک سیستم تک‌پردازنده داشتم و یک کد جاوا را روی آن اجرا می‌کردم ماشین مجازی جاوا تمامی قفل‌ها را حذف می‌کرد. چرا که در سیستم‌های تک‌پردازنده‌ای نیازی به آن نداشت (می‌شد با تغییر زمانبندی‌ها از استفاده از قفل صرف نظر کرد). اما در دنیای چند‌هسته‌ای امروز مجبوریم که قفل‌ها را به کار ببریم.یکی از مشکلات در چنین کارهایی خبر دادن اتمام یک کار به سایر نخ‌هاست. یک مثال ساده، قرار دادن و برداشتن اطلاعات در یک صف است. اگر بخواهم از یک صف، اطلاعاتی را بردارم و صف خالی باشد، و اگر عملیات خواندن به صورت مسدود کننده (Blocking) باشد، باید صبر کنم. یعنی درخواستی به سیستم عامل بفرستم تا مرا به حالت تعلیق در آورد. زمانی که می‌خواهم اطلاعاتی را در صف قرار دهم نیز می‌بایست به سیستم عامل خبر دهم که چیزی در صف قرار گرفته است تا نخِ دیگر بتواند کارش را ادامه دهد. تمامی این کارها (فراخوانی‌های سیستم عاملی برای خبر دادن به سایر نخ‌ها) هزینه‌ی بسیار بالایی دارد.در یک سیستم عامل امروزی زمان این عملیات می‌تواند چیزی بین ٣ الی ١٦ میلی ثانیه باشد و اغلب این زمان بسیار بیشتر از کاری است که سعی در انجام آن داریم. بنابراین طراحی برنامه‌ها به شکل چند نخی و به این شکل استفاده از قفل‌ها و متغیرهای شرطی می‌تواند به شدت کارایی برنامه را تحت تأثیر قرار دهد و بهتر است که برنامه را به صورت تک نخی بنویسیم.یکی از چیزهایی که من افراد را به آن تشویق می‌کنم این است که ببینند آیا می‌توان منطق کسب و کار را با یک نخ به انجام رساند؟ و اغلب اوقات این امکان‌پذیر است. تنها مشکل این است که نمی‌توانید از فراخوانی‌های مسدود کننده استفاده کنید. خیلی از افراد نرم‌افزار را به گونه‌ای طراحی می‌کنند که به صورت همگام (Synchronous) و با تکیه به فراخوانی‌های مسدود کننده کار می‌کنند. در نتیجه نمی‌توان آن را روی یک نخ اجرا کرد و مقیاس‌پذیر نیست. در اینجا لازم است الگوی برنامه را تغییر داده و از فراخوانی‌های ناهمگام استفاده شود. پس از آن می‌توان برنامه را بدون نیاز به درنظر گرفتن مسائل همزمانی بر روی یک نخ اجرا کرد.شما یکی از کسانی هستید که در پروژه‌ی متن‌باز Disruptor که برخی از مفاهیمی که در مورد آن صحبت کردید را در بر می‌گیرد، همکاری می‌کنید. کمی در مورد طرز فکر پشت این پروژه و این که چگونه مشکلاتی که در مورد آن صحبت کردیم را حل می‌کند به ما می‌گویید؟بخشی از کارهایی که من در گذشته انجام داده‌ام شامل توسعه نرم‌افزارهای با کارایی بالا و قابلیت مقیاس‌پذیری و سیستم‌های مبادلات مالی است. یکی از چالش‌ها در چنین محیط‌هایی توان عملیاتی بالا است: ده‌ها یا صدها هزار عملیات که می‌بایست در یک ثانیه انجام شوند و در کنار آن نیاز به تأخیر خیلی پایین و قابل پیش‌بینی داریم. برای انجام این کار به طراحی‌های زیادی نگاه کردیم. Disruptor در نتیجه‌ی فشار برخی از عوامل که طراحی را به سمت آن می‌کشاندند، به شکل کنونی درآمد. این‌طور نبود که در یک گوشه بنشینیم و Disruptor را تصور کنیم بلکه با توجه به نیازمندی‌ها و محدودیت‌های ذاتی مسئله که به ما تحمیل می‌شد به آن رسیدیم.در طراحی هر سیستم مبادله‌ای یکی از کارهایی که سعی در انجام آن دارید داشتن میزان بالای قابلیت جبران خطا (Resilient) است. برای جبران خطا، می‌بایست داده‌ها را روی دیسک ذخیره کنید و آن را روی سایر گره‌ها تکرار (Replicate) کنید. باید داده‌های دریافتی از شبکه را رمزگشایی و آماده‌سازی کنید. در عین حال منطق کسب و کار برنامه می‌بایست ادامه یابد. کارهای زیادی وجود دارد که می‌تواند در صورت همگام‌سازی، کاملاً مستقل از هم انجام شود. البته منظورم همگام‌سازی با قفل نیست بلکه منظور همگام‌سازی از طریق زمانبندی اجرای هر کار در طول زمان است.بعنوان مثال، فرض کنید من اطلاعات را در دیسک می‌نویسم و آن را در یک یا چند گره‌ی دیگر تکرار می‌کنم، و همزمان آن داده‌ها را برای انجام عملیات مربوط به کسب و کار نیز آماده می‌کنم. مانند سایر مسائل پردازشی، می‌خواهم که این کار را در حداقل زمان، با حداقل سربار انجام دهم. طراحی Disruptor بر اساس درک مکانیکی بوده است: چطور می‌توانم تمامی این نخ‌ها را به صورت موازی اجرا کنم؟ چطور می‌شود با یک هزینه‌ی کم، کارها را هماهنگ کرد و وقوع رخدادها را به نخ‌ها اطلاع داد؟ تمامی این‌ها به وسیله‌ی مفاهیمی به نام الگوریتم‌های بدون قفل انجام می‌شود.علاوه بر این طراحی به گونه‌ای است که بار Garbage Collection را از دوش ماشین جاوا بر می‌دارد. در محیط‌هایی که اعوجاج پایین (Low Jitter) مد نظر است (Jitter به معنای اختلاف و واریانس مشاهده شده در تأخیرها است - مترجم) ، نمی‌خواهیم زباله‌های حافظه‌ای تولید کنیم. زباله‌های بیشتر موجب فراخوانی Garbage Collector می‌شوند. بسیاری از ماشین‌ها مجازی فعلی مشکلاتی با Concurrent Collection ها دارند و می‌بایست تمامی نخ‌های را برای انجام عملیات خود متوقف کنند. بنابراین نمی‌توانند در زمان کوتاه پاسخگو باشند. طراحی Disruptor به گونه‌ای است که حافظه‌ی مورد نیاز را از پیش تخصیص داده و چند بار از آن استفاده می‌کند. در نتیجه در صورت وجود تعداد کافی هسته برای اجرای کارهایی که می‌بایست در حال اجرا باشند، می‌توانید به توان عملیاتی بالا و تأخیر پایین دست یابید.من گاهی اوقات می‌بینم که افراد هنگام استفاده از Disruptor بیش از تعداد هسته‌هایی که در اختیار دارند، نخ اجرا می‌کنند و این استفاده‌ی درستی از Disruptor نیست. بنابراین اگر شما سیستمی ١٦ هسته‌ای دارید، اما می‌خواهید 100 نخ را اجرا کنید، Disruptor برای این کار طراحی نشده است. اما اگر ١٦ هسته دارید و به ١٠ نخ احتیاج دارید، Disruptor بسیار خوب عمل می‌کند و توان عملیاتی بالایی خواهید داشت.مارتین، چرا بافر حلقوی؟بافر حلقوی از این نظر جالب است که با درک مکانیکی هماهنگی دارد. در یک بافر حلقوی به طور مکرر به خانه‌های یک نقطه از حافظه دسترسی پیدا می‌کنید. پیش‌تر اشاره کردم که سخت‌افزار فرض‌هایی را در مورد آخرین داده‌های استفاده شده و دسترسی قابل پیش‌بینی در نظر می‌گیرد. هنگامی که از یک بافر حلقوی استفاده می‌کنم، دسترسی‌های من به حافظه قابل پیش‌بینی است و پیش‌واکشی‌های سخت‌افزاری در اینجا به کار می‌آیند. بنابراین اطلاعات قبل از آن‌که من به آن نیاز داشته باشم در پردازنده (نهان‌گاه) قرار می‌گیرد. این روشی است که در اکثر سخت‌افزارها استفاده می‌شود. بخشی از جذابیت‌های مطالعه‌ی سخت‌افزار این است که چیزهای زیادی در مورد ساختار داده‌هایی که هم در سخت‌افزار و هم در نرم‌افزار بسیار خوب کار می‌کنند، یاد می‌گیرید. اگر به نحوه‌ی کارکرد اکثر کارت‌های شبکه، درایورها و توصیفات طراحی نگاه کنید، می‌بینید که همه از بافرهای حلقوی استفاده می‌کنند، در حالی که نرم‌افزارهای امروزی عموماً از آن استفاده نمی‌کنند.موضوع دیگری که چند لحظه پیش به آن اشاره کردید و در نوشته‌های شما هم دیده می‌شود، مفهوم الگوریتم‌های بدون قفل است. به ما بگویید بدون قفل یعنی چه و چرا به آن احتیاج داریم؟بله، همان‌طور که قبلاً هم گفتم، هر وقت که وارد ناحیه‌ی بحرانی میان دو نخ می‌شویم، می‌خواهیم داده‌هایی را برداریم، یا اینکه نخ دیگری را از یک تغییر آگاه کنیم، اغلب این کارها با استفاده از قفل‌ها یا متغیرهای شرطی انجام می‌شود. متغیرهای شرطی ممکن است به صورت Notify در جاوا، یا سینگال در Java EE، یا Mutex در Posix ظاهر شود. همه‌ی این‌ها در نهایت به چیزی تبدیل می‌شوند که یک ناحیه‌ی بحرانی یا امکان سیگنال دادن را فراهم می‌کند. هر زمان که این اتفاق می‌افتد، اگر قفل شما دچار ازدحام شده باشد، لازم است با سیگنال دادن، سایرین را آگاه کنید و مجبورید هسته‌ی سیستم‌عامل را درگیر کنید. بنابراین فراخوانی‌های سیستم‌عاملی انجام می‌دهید که کاری با سربار به شدت بالاست. مثل این است که از دولت کمک بخواهید و آن‌ها نیز از وکلا برای کمک شما استفاده کنند. این رویه کار خواهد کرد، امنیت دارد، و کارآمد است اما هزینه‌ی آن به شدت بالاست. اجرای چنین دستور‌العمل‌هایی میلیون‌ها چرخه به طول می‌انجامند.عارضه‌ی جانبی دیگری که از آن اجتناب می‌شود این است که زمانی که از الگوریتم‌های بدون قفل استفاده می‌کنید به این معنی است که شما شخص سومی (Third Party) را وارد کار نمی‌کنید. در این الگوریتم‌ها بر سر یک سری گام‌ها برای هماهنگ‌سازی به توافق می‌رسید و تغییرات را با نمایان شدن حافظه به یک ترتیب خاص به اطلاع سایرین می‌رسد. برای این کار لازم است کنترل ترتیب اعمال تغییرات در نقاط مختلف الگوریتم را به دست بگیرید.فرض کنید که من و شما می‌خواهیم برای انجام یک کار تعامل کنیم. من و شما هر کدام می‌توانیم بخشی از کار را انجام دهیم و توافق کنیم در چه نقاطی اطلاعاتمان را به اشتراک می‌گذاریم و تعامل می‌کنیم. پروتکلی برای این کار تعریف می‌کنیم و نقاط مربوطه را در پروتکل مشخص کنیم. الگوریتم‌های بدون قفل به ما اجازه چنین کارهایی را می‌دهند. بنابراین با به کارگیری چنین روش‌هایی در فضای کاربری (User Space) یک برنامه، نخ‌ها می‌توانند بدون دخیل کردن هسته‌ی سیستم‌عامل با هم تعامل کنند.این روش‌ها عموماً چگونگی نمایان کردن حافظه به یک ترتیب خاص را نشان می‌دهند زیرا اکثر کامپایلرها و پردازنده‌ها برای دستیابی به کارایی بیشتر سعی می‌کنند خیلی کارها را خارج از ترتیب انجام دهند البته تا جایی که به «تصور» اجرای هر نخ به ترتیب تعیین شده‌ی آن خدشه‌ای وارد نشود. لازم نیست حتماً این ترتیب رعایت شود.مثال خوبی از این مورد این است که حلقه‌ای داریم که درون آن تغییرات و محاسباتی روی داده‌ها انجام می‌دهیم و در عین حال لازم است که شمارنده‌ی حلقه نیز افزایش پیدا کند. آیا مهم است که در ابتدا، میانه، یا انتهای حلقه شمارنده را افزایش دهیم؟ تنها چیزی که اهمیت دارد این است که این کار قبل از بررسی شرط حلقه انجام شود و کامپایلرها و پردازنده‌ها برای افزایش کارایی این کارها را انجام می‌دهند.چنین چیزهایی زمانی که با نخ‌ها کار می‌کنیم اهمیت پیدا می‌کنند. چون اگر نمایان شدن، خارج از ترتیب رخ دهد در هماهنگی با سایر نخ‌ها دچار مشکل می‌شویم. برای این کار باید راهنمایی‌ها و دستورالعمل‌هایی را در کد قرار دهیم تا نشان دهیم برخی کارها باید به ترتیب خاصی انجام شوند (چیزهایی که در معرض دید سایر نخ‌ها هستند). بنابراین بخشی از کار تعیین این ترتیب تغییرات در حافظه است و به نظر من مهم‌ترین نکته است.نکته‌ی مهم بعدی این است که برخی از کارها که ممکن است دارای چند مرحله باشند باید به صورت Atomic اجرا شوند. فرض کنید چند نخ داریم که هر کدام پایان کارشان را با افزایش یک شمارنده نشان می‌دهند. اگر مراقبت نشود ممکن است برخی از شمارش‌ها گم شوند (مثلاً دو نخ شمارنده را با مقدار ١٠ دیده و همزمان آن را به ١١ افزایش می‌دهند). کاری که باید برای حل این مشکل انجام دهید استفاده از روش‌های مقداردهی و معاوضه همروند (Concurrent Set and Concurrent Swap) است. در این روش‌ها مقدار متغیر به صورت شرطی تغییر می‌کند، یعنی زمانی می‌توانم یک متغیر را به‌روز رسانی کنم که در وضعیتی باشد که من از آن آگاهم. مثلاً متغیری را می‌خوانم که مقدارش ١٠ است، آن را افزایش می‌دهم، اما زمانی می‌توانم مقدار آن را در حافظه بنویسم که مقدارش هنوز ١٠ باشد اگر این‌طور نباشد عملیات شکست خواهد خورد و باید دوباره امتحان کنم.الگوریتم‌های بدون قفل این دو کار اصلی را انجام می‌دهند: اطمینان از این‌که کارها به ترتیب درست انجام شوند، و این‌که برخی کارها به صورت Atomic انجام می‌شوند، تا بتوان هماهنگ بود. با این دو روش می‌توان اکثر الگوریتم‌هایی را که نیاز به هماهنگی دارند، پیاده‌سازی کرد. اگر کار دارای چند مرحله است یک ماشین حالت می‌سازیم و گام‌ها را یک به یک انجام می‌دهیم.تا به حال چند بار موضوع Garbage Collection در جاوا را مطرح کرده‌اید. آیا فکر می‌کنید تکامل زبان‌ها از malloc و free به Garbage Collection باعث بهبود شده یا ترکیبی از مزایا و معایب است؟سوال جالبی است. اگر موارد کاربرد خیلی خاصی دارید، می‌توانید تخصیص و آزادسازی حافظه را خودتان خیلی کاراتر از سایر روش‌های مدیریت حافظه‌ی عام‌منظوره (مثل Garbage Collection) انجام دهید. یک مثال از این،‌ استفاده از بافر حلقوی برای تبادل اطلاعات میان تولیدکننده و مصرف‌کننده (Producer/Consumer) است. خیلی از مسائل این‌طور نیستند، در واقع چندین تولیدکننده و چندین مصرف‌کننده وجود دارد، یا اینکه چند نخ درگیر هستند. در محیط چند نخی مدیریت حافظه دشوار است. ممکن است است بگویید از شمارش مراجع (Reference Counting) استفاده می‌کنیم اما برای شمارش مراجع می‌بایست از روش‌هایی استفاده کنیم که پیش‌تر در مورد آن‌ها صحبت کردیم (قفل‌گذاری و نواحی بحرانی) که هزینه‌ی زیادی دارند. بنابراین مدیریت حافظه با این روش احتمالاً یکی از کندترین روش‌هاست. Garbage Collector ها با جمع‌آوری همروند زباله‌ها و ردگیری حافظه‌های بدون استفاده، بسیاری از مشکلات ما را حل می‌کنند و جلوی بسیاری از خطاها را می‌گیرند.من مقدار زیادی برنامه‌نویسی در زبان‌های سطح پایین و سطح بالا با امکان Garbage Collection انجام داده‌ام و وقتی که شما Garbage Collection دارید قطعاً نگرانی برای دسته‌ای از خطاها را ندارید. می‌توانید به راحتی به حافظه دسترسی پیدا کنید و لازم نیست در مورد دسترسی‌های غیر مجاز و بررسی شرایط مرزی نگران باشید، اما این‌ها هزینه دارد. مسئله‌ی جالب این است که از نظر تئوری Garbage Collection می‌تواند کارآمدترین روش عام‌منظوره تخصیص و آزادسازی حافظه باشد. مشکل اینجاست که اکثر Garbage Collector ها با نگاه ساده انگارانه‌ای نوشته شده‌اند. آن‌ها انتظار دارند که در برخی مراحل کارشان، همه چیز متوقف شود. این باعث می‌شود که بخشی از برنامه به صورت غیر موازی اجرا شده و قانون Amdahl بر آن حاکم شود و در نتیجه مقیاس‌پذیری محدود شود. البته Garbage Collector هایی هم وجود دارند که واقعاً به صورت همروند عمل می‌کنند و کارایی فوق‌العاده‌ای دارند. یک مثال خوب C4 محصول شرکت Azul است. اما این تنها محصول تجاری است که من می‌شناسم و می‌تواند توان عملیاتی بالایی ارائه دهد و به سادگی بدون متوقف کردن برنامه قابل استفاده باشد.با توجه به قانون Amdahl، آیا محدودیتی روی تعداد هسته‌های قابل استفاده توسط ماشین مجازی جاوا وجود دارد؟ البته با این فرض که در سایر قسمت‌های برنامه گلوگاهی وجود نداشته باشد.این وابسته به این است که چه مقدار تخصیص حافظه دارید و چه کارهایی در حال انجام است. بردن نخ‌ها به وضعیت امن (Safe Point)، یکی از بزرگ‌ترین مشکلات ماشین‌های مجازی امروزی است. این مسئله در برخی موارد مشکل‌ساز می‌شود. برای هرکاری که بخواهد باعث متوقف شدن کامل برنامه (Stop The World) شود لازم است ابتدا وضعیت تمامی نخ‌ها را به حالت امن ببریم. در این نقطه است که حالا می‌توانیم برنامه را متوقف کنیم و می‌توانیم چرخه Garbage Collection را اجرا کنیم، می‌توانیم کلاس‌ها را تخلیه کنیم (Class Unloading)، می‌توانیم بهینه‌سازی‌ها را انجام دهیم و خیلی کارهای دیگر. اما قبل از همه این کارها لازم است که همه نخ‌ها را به وضعیت امن برسانیم. اینها مسائلی هستند که می‌بایست بصورت ترتیبی اجرا شوند.برای اینکه این مسأله روشن‌تر شود می‌توانیم به این موضوع اشاره کنیم که خیلی از افراد زمان Garbage Collection را در برنامه‌های خود اندازه‌گیری می‌کنند اما یکی از چیزهای دیگری که می‌بایست اندازه‌گیری شود، زمان توقف برنامه است، در بسیاری از موارد متوجه خواهید شد که زمان توقف برنامه به مراتب بیشتر از زمان Garbage Collection است. من اغلب در اندازه‌گیری‌ سیستم‌ها می‌بینم که متوقف کردن برنامه زمان بیشتری نسبت به انجام کار واقعی Garbage Collection دارد.فکر می‌کنید تا چه حد می‌شود با تنظیم گزینه‌ها و پارامترهای Garbage Collector ها کارایی برنامه‌های سرور را افزایش داد؟در اینجا عموماً به دو دسته از مسائل بر می‌خورم. یکی این است که شخصی با اعمال تغییرات بیشتر به سیستم ضرر رسانده است تا سود. در حقیقت بهتر بود که سیستم را با تنظیمات پیش‌فرض رها می‌کردند. مورد دیگر این است که افراد پیکربندی را به درستی انجام نداده‌اند، و برنامه‌شان را به درستی پروفایل نکرده‌اند تا میزان مورد نیاز حافظه و سایر پارامترها را بدست آورند چرا که فقط اندازه‌گیری این موارد بر اساس داده‌های واقعی، می‌تواند باعث بهبود اجرای برنامه‌هایتان شود.بزرگ‌ترین چالشی که افراد در این مسئله دارند این است که آن‌ها تست‌هایی که نمایان‌گر میزان کارایی برنامه‌هایشان باشد ندارند. آن‌ها معمولاً سعی می‌کنند به مشکلاتی که در سیستم‌های واقعی رخ می‌دهند واکنش نشان دهند و چون نظارت مناسبی روی سیستم‌ها ندارند، راهی برای ایجاد کردن مجدد مشکلات ندارند. در نتیجه نمی‌توانند تنظیمات را به درستی انجام دهند و کورکورانه و بر اساس حدس و گمان عمل می‌کنند.برای استفاده‌ی هوشمندانه‌تر از Garbage Collector افراد بر چه چیزهایی نظارت داشته باشند؟فکر می‌کنم فعال کردن ثبت وقایع (Log) مهم‌ترین چیز باشد. من یک مقاله با عنوان Garbage Collection Distilled نوشته‌ام. هدف از نوشتن این مقاله این بود که انواع مختلف Garbage Collector هایی که با ماشین مجازی جاوا ارائه می‌شوند و پارامترهای اصلی تنظیمات آن‌ها معرفی شوند. یکی از تنظیماتی که باید انجام شود فعال کردن ثبت اطلاعات وقایع است. وقتی که این اطلاعات را داشته باشید، می‌توانید از ابزارهای دیگری استفاده کنید. سربار فعال کردن آن در سیستم‌های محصول (Production System) ناچیز است و حتی متوجه آن نخواهید شد. پس از آن می‌توانید اطلاعات را برداشته و با استفاده از ابزارها، ببینید در برنامه‌های شما چه اتفاقاتی رخ داده است.پیش از این در مورد ناتوانی زبان جاوا در تعریف کردن آرایه‌ای از رکوردها (به جای آرایه‌ای از ارجاع‌ها) صحبت کردید. همچنین در مورد برخی ساختارهای خارج از Heap برای حل این مسئله صحبت کردید. ممکن است بیشتر در این مورد توضیح دهید؟اگر بتوانیم چینش قابل پیش‌بینی در حافظه داشته باشیم، خواهیم توانست کارایی پیش‌بینی شده‌ای در زیرسیستم حافظه داشته باشیم. بنابراین زبان‌های برنامه‌نویسی باید این امکانات را در اختیار ما قرار دهند. فکر نمی‌کنم این امکانی باشد که توسعه‌دهندگان هر روزه به آن نیاز داشته باشند اما فکر می‌کنم که برای طراحان زبان‌ها خیلی مهم باشد. آن‌ها باید بتوانند انواع مجموعه‌ها از قبیل نگاشت‌ها (Map)، درخت‌ها و ... را به نحوی طراحی کنند که کارایی مناسبی در کار با حافظه داشته باشد. متأسفانه زبان جاوا و بایت کد این شفافیت را به ما نمی‌دهند تا چینش حافظه را با توجه به نیاز انجام دهیم.در واقع من، در 3 موقعیت به داشتن کنترل روی چینش حافظه نیاز دارم. یکی تعریف آرایه‌ای از ساختارها یا اشیاست تا بتوانیم به طور مستقیم و با پیمایش در حافظه به عناصر دسترسی پیدا کنیم.مورد دوم این‌که گاهی نیاز دارم یک شی‌ء را در دل شیء دیگری قرار دهم. مثلاً یک صف یک سر و یک ته دارد. من می‌خواهم زمانی که به سر یا ته این صف دسترسی پیدا می‌کنم اطلاعات همانجا باشد. بنابراین باید بتوانم اشیاء کوچک را درون اشیاء بزرگتر قرار دهم. یک مثال خوب از آنها، انواع atomic int و atomic long هستند. اشیاء کوچکی که پوششی (Wrapper) روی انواع داده‌ای اولیه هستند.سومین چیزی که به آن نیاز دارم، داشتن توانایی گسترش یک چیز در زمان اجراست. این مفهوم خیلی شبیه به داشتن یک ساختار در زبان C است که آرایه‌ای با طول متغیر در انتهای خود دارد. این مورد برای چیزهایی مثل رشته‌ها (String) خیلی مفید است. اشیاء رشته مقادیری مثل hash code، طول رشته، اندیسی در آرایه و در نهایت آرایه‌ای از بایت‌ها (حروف آن رشته) را نگهداری می‌کنند. چرا باید یک شیء داشته باشیم که نماینده‌ی رشته باشد و از آنجا به نقطه‌ی دیگری ارجاع کنم که آرایه را نشان دهد؟ این آرایه باید به صورت پیوسته در انتهای شیء مورد نظر قرار گیرد تا محلی بودن (Locality) حافظه حفظ شود. ماشین جاوا از برخی ترفندها برای کار با چیزهایی مثل رشته‌ها استفاده می‌کند اما من باید بتوانم چنین کاری را برای همه‌ی ساختارها انجام دهم تا مطمئن شوم چینشی کارا دارم. باید بتوانم با علم به وجود چنین امکاناتی،‌ کتابخانه‌های خود را طراحی کنم. این تغییرات لازم نیست در سطح زبان باشد. این کار می‌تواند از طریق الگوها و نشانه‌هایی که از پیش با ماشین جاوا توافق شده است انجام شود (مثل Annotation ها). زمانی که ماشین جاوا این علامت‌ها را ببیند، کارهای لازم را انجام می‌دهد. با وجود این امکانات می‌توانیم در برخی از مجموعه‌ها و برخی الگوهای دسترسی به کارایی به مراتب بهتری دست یابیم.اگر می‌توانستید، آموزش علم کامپیوتر را برای کسانی که فارغ‌التحصیل نشده‌اند تغییر دهید، چگونه عمل می‌کردید؟به چیزهایی مثل روش‌های علمی خیلی بیشتر توجه می‌کردم. کار کردن بر اساس استدلال، اندازه‌گیری و علم، باید اساس باشد؛ همان‌طور که گرفتن مدرک در سایر رشته‌ها این‌گونه است مواردی از قبیل یادگرفتن نحوه‌ی استدلال، چگونگی دنبال کردن مطالبی که همواره تغییر می‌کنند، آگاهی از این مسئله که انسان خیلی راحت در دام پیروی از محبوبیت و مد (popularity and fashion) می‌افتد.چیزی که در رشته‌ی ما می‌توانیم از آن مطمئن باشیم تغییر است. بنابراین اگر در دانشگاه جزئیات را یاد بگیرید، خیلی زود تاریخ مصرفشان خواهد گذشت. باید چیزهایی را یاد بگیرید که در دراز مدت پایدار باشد.به نظرم مهم است که زمانی که افراد در مورد Agile صحبت می‌کنند در مورد چرخه‌ی بازخورد صحبت شود. آن‌چه که در دل Agile قرار دارد این است که طوری طراحی کنیم که چرخه‌ی بازخورد کوتاه شود. زمانی که چرخه‌ی بازخورد کوتاه باشد، تصمیمات بهتری گرفته می‌شود. در حقیقت انجام دادن غلط کارها اشکالی ندارد. چون چرخه‌ی شما کوتاه است، میزان هدر رفت هم کم است و همواره پیشرفت دارید. اما وقتی در مورد استانداردها و مراسم‌های Agile صحبت می‌کنیم از موارد اصلی باز می‌مانیم. فکر می‌کنم این چیزی است که ما در علم کامپیوتر باید یاد بگیریم: «یک چیز چطور کار می‌کند؟»در دنیای امروز افراد از دانشگاه فارغ‌التحصیل می‌شوند در حالی که هرگز با زبانی که به طور مستقیم با حافظه دسترسی دارد کار نکرده‌اند. خیلی خوب است که بتوانیم از این چیزها فاصله بگیریم اما اگر مفاهیم اساسی چگونگی کارکرد آن را ندانید، تصمیمات اشتباهی خواهید گرفت.مارتین، اگر شنوندگان بخواهند بیشتر در مورد نظرات و کارهای شما بدانند چطور این کار را انجام دهند؟وبلاگ من یکی از جاهایی است که می‌توانند از آن شروع کنند. همچنین می‌توانید در گروه درک مکانیکی در گوگل عضو شوید که گفتگوهایی خوبی در آنجا اتفاق می‌افتد. افراد زیادی داریم که موضوعات را با جزئیات بیشتری بررسی می‌کنند و در مورد نحوه‌ی کارکرد چیزها به طور اساسی صحبت می‌کنند.آیا ارائه‌ای از کنفرانس‌ها روی اینترنت وجود دارد که بخواهید شنوندگان آن‌ها را ببینند؟کارهای متفاوتی هست که من انجام دادم و امیدوارم در آینده هم انجام دهم. اگر نام من و ارائه‌هایم در infoq یا Yahoo را در گوگل جستجو کنید نقطه‌ی شروع خوبی است. برای معرفی و توضیح دادن یک موضوع به افراد معمولاً یک wiki در بلاگم قرار می‌دهم تا از آنجا شروع کرده و بیشتر مطالعه کنند. دوست دارم موضوعات جدید را به افراد معرفی کنم. قرار نیست آنجا همه چیزهایی که به آن نیاز دارند را پیدا کنند اما نقطه‌ی شروع خوبی است.مارتین، از شما خیلی متشکریم که با ما صحبت کردید.متشکرم که من را دعوت کردید. سید مرتضی هاشمی سید مرتضی هاشمی Fri, 10 Dec 2021 16:12:47 +0330 https://virgool.io/se-radio/se-radio-estimation-ich0an3ojpfp مطلبی که می‌خوانید ترجمه ی قسمت قسمت ۲۷۳ از رادیو مهندسی نرم‌افزار است. رادیو مهندسی نرم‌افزار هر یکی دو هفته یک بار مصاحبه‌ای درباره‌ی یکی از موضوعات حوزه‌ی مهندسی نرم‌افزار با افراد خبره و با تجربه در موضوع مورد بحث ترتیب می‌دهد.در این قسمت که در نوامبر ۲۰۱۶ منتشر شده است، سوِن یوهان با استیو مک‌کانل درباره‌ی برآورد نرم‌افزار (Software Estimation) صحبت می‌کند. مباحثی که مطرح می‌شود:چرا و چه وقت کسب‌وکارها به برآورد نیاز دارند یا چه وقت ندارند؟تبدیل برآورد‌ها به طرح‌ریزی و سنجش پیشرفت بر اساس این طرح‌ریزی به چه نحوی است؟چرا برآورد‌های نرم‌افزار همواره مملو از عدم قطعیت است؟این عدم قطعیت‌ها چه هستند و چه‌طور با آن‌ها روبرو شویم؟من سوِن یوهان هستم و امروز استیو مک‌کانل مهمان من است. استیو مدیر ارشد اجرایی و مهندس ارشد نرم‌افزار در شرکت نرم‌افزاری Construx است؛ او مؤلف Code Complete ، Rapid Development و بسیاری کتاب‌های دیگر است. او در سال ۲۰۰۶ کتابی در مورد برآورد نرم‌افزار منتشر کرد. همچنین به عنوان سردبیر مجله مهندسی نرم‌افزار IEEE فعالیت کرده است. من امروز با استیو درباره‌ی برآورد هزینه‌ی نرم‌افزار صحبت می‌کنم. استیو به برنامه خوش آمدی!متشکرم که مرا دعوت کردید.آیا چیز مهمی را در معرفی شما فراموش کردم؟نه فکر می‌کنم تقریباً به طور کامل توضیح دادید.خوب. برآورد چیست؟فکر می‌کنم وقتی سوال می‌کنیم که برآورد چیست باید میان نحوه‌ی استفاده‌ی عمومی افراد -که در بسیاری از موارد ناسالم و غیرسازنده است- و آنچه‌که یک برآورد واقعاً هست، تمایز قائل شویم؛ هم از لحاظ تعریف کتابی و هم از لحاظ نحوه‌ی درست صحبت کردن در مورد برآورد. فکر کنم اگر به تعریف برآورد در واژه‌نامه نگاه کنید، برآورد یک پیش‌بینی آماری از مدت زمان انجام یک کار، یا هزینه‌ی آن، و یا این‌‌که چه تعداد ویژگی را می‌توان در یک زمان مشخص تحویل داد است. بنابراین مفهوم مورد نظر در اینجا پیش‌بینی است. تعریف واژه‌نامه‌ای معمولاً مفهومی از تقریبی، تجربی و مقدماتی بودن یا چیزی شبیه به آن را نیز مطرح می‌کند. بنابراین در واقع ما درباره‌ی یک تصویر مقدماتی یا پیش‌گویی تجربی یا همچنین چیزی صحبت می‌کنیم. فکر می‌کنم این درست باشد. این بهترین و سازنده‌ترین روش فکر کردن به آن در نرم‌افزار است.در عمل آن‌چه فهمیدیم این است که افراد در هر دو سوی تصمیمات فنی و کسب‌وکار، قطعاً گرایش دارند که از کلمه‌ی برآورد به معنی پیش‌گویی آماری استفاده کنند؛ اما از آن به معنی تعهد هم استفاده می‌کنند. یعنی افراد کسب‌وکار می‌پرسند به برآورد شما این کار چقدر طول می‌کشد؟ افراد فنی هم می‌گویند فکر می‌کنیم تا فلان تاریخ طول بکشد. در این لحظه تاریخ مورد نظر تبدیل به تعهدی به کسب‌وکار می‌شود؛ این کمی فراتر از برآورد می‌رود. فکر می‌کنم استفاده از این کلمه علاوه بر اشاره برآورد و تعهد، برای اشاره به اهداف هم استفاده می‌شود. مثلاً طرف کسب‌وکار ممکن است بگوید ما واقعاً دوست داریم که این کار تا فلان تاریخ تمام شود و در حین گفتگو ما به نحوی کلمات برآورد و تعهد را تلفیق می‌کنیم. این منجر به انواع مشکلات می‌شود که می‌توانیم در صورت نیاز در مورد آن‌ها صحبت کنیم؛ اما فکر می‌کنم برای کوتاه کردن سخن اگر بتوانیم در گفتگوهایمان و یا حداقل در ذهن‌مان میان برآورد‌ها، تعهدات و اهداف تمایز قائل شویم -حداقل در جنبه‌ی فنی معادله- خودمان را برای داشتن گفتگوهای بسیار سازنده‌تری درباره‌ی برآورد آماده کرده‌ایم. ما ارزش بسیاری در صِرفِ روشن کردن این مفهوم دیده‌ایم. چون روشن کردن مفهوم، منجر به روشن شدن فعالیت هم می‌شود. بنابراین می‌دانیم کِی برآورد می‌کنیم، کِی درباره‌ی یک هدف صحبت می‌کنیم، و کِی تعهد می‌دهیم. روشن کردن این کلمات در حقیقت به ما کمک می‌کند تا از دادن تعهد درحالی که فکر می‌کنیم صرفاً برآورد می‌کنیم، دوری کنیم.تعهد، هدف و برآورد. رئیس من از من یک برآورد خواست اما در واقع می‌خواست به هدفی برسد و از ما تعهدی برای رسیدن به هدف بگیرد. آیا این بازگویی از زبان من درست است؟ :-)فکر می‌کنم درست باشد. فکر می‌کنم روش سازنده‌ای برای فکر کردن به آن است. یعنی [تشریح] کامل آن این است که کسب‌وکار چیزی در ذهن دارد که فکر می‌کند به درد کسب‌وکار می‌خورد. این هدف است. معمولاً کسب‌وکار می‌پرسد چه برآوردی از این کار دارید؟ فکر می‌کنید چه تعداد ویژگی می‌توانید تا فلان تاریخ تحویل دهید؟ بنابراین آن‌چه که کسب‌وکار طبیعتاً فکر می‌کند این است که آن‌چه که امیدوار بودیم به آن دست پیدا کنیم، صد درصدِ آن‌چیزی است که در ذهنمان بود. عموماً این‌طور است که افراد خوش‌بین هستند. افراد فنی می‌روند و کار واقعیِ برآورد کردن را انجام می‌دهند که من در واقع به آن برآورد می‌گویم. و عموماً برمی‌گردند و همان‌طور که از نام خوش‌بینی پیداست متوجه می‌شوند در واقع هدف کسب‌وکار [در زمان] مورد نظر قابل دست‌یابی نیست؛ [هدف] خیلی خوش‌بینانه بود. توانایی حقیقی سازمان برای تحویل آن کافی نیست. اتفاقی که در اینجا رخ می‌دهد این است که ما از برآورد استفاده می‌کنیم تا بفهمیم توانایی‌مان در رسیدن به یک هدف و این‌که به آن متعهد شویم معقول است یا خیر. برآورد در واقع به ما کمک می‌کند تعیین کنیم که این تعهدی است که «احتمالاً» به آن دست می‌یابیم یا این تعهدی است که «احتمالاً» نمی‌توانیم زیر بار آن برویم. اما مفهومی از بی‌ثباتی و احتمال در هر برآورد واقع‌بینانه وجود دارد. بنابراین در هر برآورد واقع‌بینانه درجه‌ای از انعطاف‌پذیری وجود دارد. وقتی می‌گوییم برآورد، حاکی از احتمال برآورده شدن تعهد است، برآورد آن را تضمین نمی‌کند. در عوض می‌گوید که فرصت خیلی خوبی برای برآوردن تعهد داریم یا این‌که امکان تلاش کردن برای آن را داریم یا این‌که هیچ شانسی برای عمل به تعهد نداریم و در نتیجه احتمالاً از همان ابتدا نباید زیر بار آن برویم.وقتی کتاب‌تان را خواندم توضیح خیلی خوبی در این مورد داده بودید؛ با [تمثیل] یک چمدان زمانی که به تعطیلات می‌روید. با تثبیت میزان چیزهایی که می‌تواند در چمدان قرار بگیرد. شاید بخواهید در مورد این مثال به مخاطبان بگویید. فکر می‌کنم [موضوع را] خیلی واضح کند.بله حتماً. این بخش از کتاب در واقع از ستونی که کمی قبل‌تر در IEEE منتشر کرده بودم گرفته شده است. فرض کنید می‌خواهیم به تعطیلات برویم و می‌خواهیم تصمیم بگیریم که چمدان با چه اندازه‌ای برای لباس‌هایمان لازم داریم. واقعاً نمی‌خواهیم اندازه‌ی دقیقِ چمدانی را بدانیم که دقیقاً به اندازه‌ی لباس‌های ماست. ما می‌خواهیم چمدانی داشته باشیم که به اندازه‌ی همه‌ی لباس‌ها جا داشته باشد، اما نه آن‌قدر بزرگ که کلی جای خالی در آن باشد و در فرودگاه ما را دچار دردسر کند. مسئله‌ای که در آن فصل از کتاب مطرح می‌کنم این است که زمانی که می‌خواهید به سفر بروید، کاری که می‌کنید این است که چمدان‌تان را برمی‌دارید. ممکن است تعدادی لباس دیگر هم داشته باشید که باید در آن جا شوند و شاید لازم باشد چمدان را به زور ببندید. اما اگر اندازه‌ی آن به اندازه‌ی کافی بزرگ باشد می‌توانید به زور هم که شده آن را ببندید. [بنابراین] احتمالاً خوب است و چمدان به اندازه‌ی کافی بزرگ است. فکر می‌کنم این قیاس مناسبی با کاری است که ما می‌خواهیم در برآورد نرم‌افزار انجام دهیم. ما تلاش نمی‌کنیم با برآورد‌هایمان بگوییم که به طور دقیق به آن‌ها دست خواهیم یافت. چیزهای زیادی در پروژه‌های نرم‌افزاری تغییر می‌کند. این تصور که ما دقیقاً به هر آن‌چه برآورد می‌کنیم دست خواهیم یافت وابسته به این است که ما دقیقاً همان‌چیزی را که در ابتدا شروع کردیم، تحویل بدهیم؛ این به ندرت رخ می‌دهد. چیزهای زیادی در طول مسیر تغییر می‌کند. اما [کافی است] آن‌چه که در ابتدا برآورد می‌کنیم به اندازه‌ی کافی نزدیک به واقعیت باشد، به نحوی که بتوانیم به چیزی مشابه به آن دست یابیم حتی اگر نیاز به کار بیشتری داشته باشد،‌ شاید یکی دو آخر هفته یا آخر وقت (که معادل به زور چپاندن لباس‌ها در چمدان هستند). اگر این محقق شود ما کم و بیش آن‌چه که گفته بودیم تحویل می‌دهیم را، کم و بیش در بازه‌ی زمانی که گفته بودیم، تحویل داد‌ه‌ایم. من فکر می‌کنم اکثریت کسب‌وکارها درک می‌کنند که زندگی غیر قطعی است. با وجود این‌که همه چیز را در نظر گرفتیم و شاید دقیقاً مطابق آن‌چه که انتظار داشتیم پیش نرفتیم، اما به اندازه‌ی کافی به آن نزدیک شدیم، به طوری که این اجرای پروژه را خوب و به طور کلی یک پروژه‌ی موفق در نظر می‌گیریم. این به نوعی ماهیت داستان چمدان بود. هدف آن این بود که نشان دهد خیلی خوب بود اگر هیچ چیز هرگز تغییر نمی‌کرد و می‌توانستیم به دقت پیش‌بینی کنیم که دقیقاً چه رخ خواهد داد؛ هرچند در واقعیت این‌گونه نیست اما آن‌چه واقعاً می‌خواهیم این است که به اندازه‌ی کافی به برآورد‌هایمان نزدیک شویم؛ به طوری که بتوان فاصله را با حد معقولی از کار اضافی، یا حذف کردن ویژگی‌ها در مقیاس‌های کوچک، یا تغییرات کوچکی که روی موفق بودن پروژه تأثیر ندارند، پر کنیم.اما خطای برآورد از کجا سرچشمه می‌گیرد؟:-) من تقریباً ۲۰ سال است که یک کلاس برآورد کردن را تدریس می‌کنم. حداقل در ۱۰ سال گذشته به دانشجویان تمرینی می‌دهم و به آن‌ها می‌گویم که سه دقیقه وقت دارید که طوفان فکری کنید و هر تعداد که می‌توانید از منابع تغییرات در پروژه را بیابید که باعث می‌شوند برآورد‌هایی که پروژه بر آن بنا شده بود باطل شود. از همان تغییراتی که به صورت روزمره رخ می‌دهند. من به دنبال تغییرات تصادفی و غیرمنتظره نیستم که شاید بتوان پیش‌بینی کرد بلکه به دنبال چیزهایی هستم که در برآورد‌ها در نظر گرفته نشدند و حتی اگر آن‌ها را در نظر می‌گرفتید نمی‌توانستید برآورد را بهبود دهید. چیزهایی که همواره در پروژه‌ها رخ می‌دهند. به آن‌ها سه دقیقه وقت می‌دهم تا هر تعداد که می‌توانند بگویند. در یک گروه بیست نفری معمولاً لیستی از ۳۰ یا ۴۰ مورد تهیه می‌شود. لیست را بررسی می‌کنیم و می‌گویم که از شما خواستم که اتفاقات نادر را نگویید. آیا این‌ها اتفاقات غیرمتداول هستند یا عموماً رخ می‌دهند؟ آن‌ها همیشه می‌گویند این‌ها متداول هستند و همیشه اتفاق می‌افتند. چیزهایی که از آن صحبت می‌کنیم از این قبیل‌اند: یک عضو کلیدی از دسترس خارج می‌شود، کار را ترک می‌کند، یا به پروژه‌ی دیگری ملحق می‌شود؛ اولویت‌های مدیریتی عوض می‌شود، یعنی اولویت‌ها در ابتدای پروژه در حین پروژه تغییر می‌کنند؛ بودجه تغییر می‌کند، پروژه را با ده نفر شروع می‌کنید، بودجه عوض می‌شود و باید با هفت نفر کار را انجام دهید؛ بازار تغییر می‌کند، رقیب ویژگی‌ای منتشر می‌کند که باید به آن در نسخه‌ی بعدی محصول عکس‌العمل نشان دهید. این لیست ادامه دارد... .این قبیل چیزها هستند که در تمام پروژه‌ها اتفاق می‌افتد. در حقیقت فکر می‌کنم اگر پروژه‌ای پیدا کنید که از ابتدا تا انتها حقیقتاً پایدار مانده باشد، به شدت متعجب می‌شوید. در اکثر مواقع وقتی می‌گویم پایدار منظورم این است که فرض‌هایی که برآورد را تحت تأثیر قرار می‌دهند از ابتدا پایدار بمانند. این‌ها فرض‌هایی در مورد مجموعه ویژگی‌ها، افراد تیم، پشتیبانی سازمانی و ... هستند.ین کار را سخت می‌کند. منظورم این است که برخی از همکاران سابقم را می‌شناسم که برآورد می‌خواستند و در انتها فقط اعداد را مقایسه می‌کردند. [آن‌ها می‌گفتند:] این‌ها ۱۰۰۰ نفر/روز برآورد کرده بودند در حالی که ۱۲۰۰ نفر/ساعت وقت گرفت؛ [پس] این افراد، بد هستند. من فرصتی برای دفاع ندارم. چه‌طور باید از خودم دفاع کنم. راهی وجود دارد؟ آیا باید همه چیز را بنویسم، یا این صرفاً احساس شخصی من است که افراد اسلحه‌ای روی سر من گذاشته‌اند [و می‌گویند] تو کاملاً اشتباه برآورد کردی!بله، فکر می‌کنم بسته به جزئیات، این سناریو می‌تواند به دلایل مختلفی اتفاق بیفتد. دلیل ناسالمی که ممکن است این اتفاق رخ دهد این است که افرادی که پروژه را برآورد می‌کنند برآوردگران خوبی نیستند و در واقع چیزی تغییر نکرده است و باید همان ۱۲۰۰ نفر/ساعت را در ابتدا برآورد می‌کردند. اما این کار را نکردند و ۱۰۰۰ نفر/ساعت برآورد کردند. بنابراین از برنامه عقب افتادند. این اساس برحقی در انتقاد به تیم است. فکر می‌کنم این گاهی اتفاق می‌افتد. حقیقت موضوع این است که وضعیت سرمشق‌های (Practice) [نحوه‌ی] برآورد هنوز خیلی خوب نیست. هنوز در اغلب موارد تیم‌ها و سازمان‌هایی را می‌بینیم که از چیزهایی که به آن سرمشق‌های «عقیده‌ی خبره» (Expert's Judgment) گفته می‌شود، استفاده می‌کنند. این به آن معنی است که این سرمشق‌ها به طرزی که استفاده می‌شوند به شدت در معرض خطا هستند. بنابراین خیلی اوقات این انتقاد برحق است.در مواقع دیگر فکر می‌کنم یکی از دلایلی که پروژه‌ای که ۱۰۰۰ نفر/ساعت برآورد شده بود، ۱۲۰۰ نفر/ساعت طول بکشد تغییرات ردگیری نشده در مفهوم پروژه هستند. فکر می‌کنم این خیلی متداول است. من موارد خیلی خیلی زیادی را دیده‌ام که تیم‌های پروژه با یک مفهوم از پروژه و مجموعه‌ای از نیازمندی‌ها شروع به کار روی پروژه می‌کنند. [سپس] تغییرات نیازمندی‌ها یا نیازمندی‌های جدید وارد می‌شوند. و همه‌ی افراد از جمله‌ی افراد کسب‌وکار دور میزی می‌نشینند و تغییرات را نگاه می‌کنند و می‌گویند این تغییرات خوب هستند؛ باید آن را انجام دهیم؛ هزینه‌ی آن ارزشش را دارد. اما اتفاقی که می‌افتد این است که هرچند همه با تغییرات موافق‌اند آثار تجمعی تغییرات را در پروژه ردگیری نمی‌کنند. از قدرت من خارج است که به شما بگویم چه تعداد تیم‌های پروژه را دیده‌ام که دور میز می‌نشینند و توافق می‌کنند که یک تغییر خوب است و به صورت داخلی موافقند که [این تغییر] روی پروژه و هزینه‌های آن تأثیرگذار است اما با این وجود این هیچ تأثیر موجی (Ripple Effect) [برای بروزرسانی] پروژه‌ی اصلی، بودجه‌ی اصلی یا زمان‌بندی اصلی ندارد. بنابراین فکر می‌کنم خیلی متداول است که پروژه‌ای که ۱۰۰۰ نفر/ساعت برآورد شده باشد اما ۱۲۰۰ نفر/ساعت طول بکشد. بسیار محتمل است که این ۲۰۰ نفر/ساعت را اضافه کرده باشیم؛ به صورت توافقی هم اضافه کرده باشیم. و اگر از کسب‌وکار بپرسید که فلان چیز یا بهمان چیز ارزشش را داشت؟ این تفاوت میان ۱۰۰۰ و ۱۲۰۰ ارزشش را داشت؟ خیلی محتمل است که بگویند بله. بنابراین آن‌چه که واقعاً از آن صحبت می‌کنیم اصلاً یک مسئله‌ی فنی نیست، یک مسئله‌ی ارتباطی [و انتقال مطلب] است. از این لحاظ که اطمینان حاصل کرد سازمان بفهمد که خود سازمان است که تصمیمی می‌گیرد و قلمروی (Scope) پروژه را افزایش می‌دهد. این تجاوز نیست؛ افزایش قلمرو آن است؛ این‌ها یکسان نیستند.ظاهراً سال‌ها پیش وقتی بیل گیتس همچنان مدیرعامل مایکروسافت بود، درخواستی برای گزارش وضعیت پروژه‌ها در قالب خاصی می‌کند. نمی‌دانم این یک داستان است یا واقعیت دارد، اما به هر حال آن را دوست دارم. ظاهراً خواست گزارش وضعیت در یک صفحه باشد که در بالای آن زمان‌بندی اولیه‌ی پروژه باشد و در خط دوم زمان‌بندی فعلی پروژه و سپس لیستی از تفاوت‌ها و دلایلی باشد که چرا زمان‌بندی فعلی مانند زمان‌بندی اولیه نیست. فکر می‌کنم این روش خیلی زیرکانه‌ای باشد. چون او با درخواست گزارش‌ها در این قالب می‌خواهد نشان دهد میل دارد زمان‌بندی اولیه را به یاد داشته باشد اما نمی‌خواهد تمامی تغییراتی که بین زمان‌بندی اولیه و زمان‌بندی فعلی وجود دارد را بخاطر آورد؛ با این‌که احتمالاً دلایل خوبی برای تغییرات وجود دارد. اما در گزارش وضعیت، من خلاصه‌ای سریع می‌خواهم از این‌که چرا تصویر من از زمان‌بندی اولیه تغییر کرده و باید به جای زمان‌بندی اولیه، روی زمان‌بندی فعلی تمرکز کنم.باشه، من این را امتحان خواهم کرد :-) خوب به نظر می‌رسد. میزان زیادی عدم قطعیت در برآورد وجود دارد. درست است؟ حتی اگر همه‌ی این کارها را انجام دهم، ممکن است خیلی اشتباه کنم. چون وقتی یک پروژه را برآورد می‌کنم خصوصاً در ابتدای آن، زمانی که مشتری می‌گوید می‌خواهم یک فیسبوک برای سگ‌ها داشته باشم :-)) و ما آن را برآورد می‌کنیم. در شروع کار، من اطلاعات خیلی کمی در مورد آن دارم. هر چه بیش‌تر پیش می‌روم درک بیش‌تری از مشکلات پروژه پیدا می‌کنم و برآوردی بهتری می‌کنم. فکر می‌کنم یک اصطلاح برای آن وجود داشته باشد: مخروط عدم قطعیت (Cone of Uncertainty).درست است.می‌توانید این را توضیح دهید؟بله، حتماً. چند دقیقه پیش در مورد وضعیت نامطلوبِ سرمشق‌های برآورد صحبت کردیم. یکی از جنبه‌هایی که وضعیت سرمشق‌ها نامطلوب است این است که هنوز هم افراد در زمان اشتباهی در پروژه‌ها برآورد می‌کنند و بار زیادی به برآوردها تحمیل می‌کنند. [برآوردهایی] که قبل از آن‌که بدانند چه می‌کنند تهیه شده است. فکر می‌کنم تمام جنبه‌های برآورد، چند وجهی هستند. تقریباً هر چیزی که از آن صحبت می‌کنیم، یک دیدگاه کسب‌وکاری و دیدگاه نظرِ فنی دارد. دیدگاه کسب‌وکاری سالم و ناسالم و همین‌طور دیدگاه فنی سالم و ناسالم. به نظر من هیچ چیز ناسالمی در این نیست که کسب‌وکار در روز صفر پروژه، قبل از این‌که هیچ کاری انجام شده باشد، بخواهد بداند پروژه دقیقاً چقدر طول می‌کشد و چقدر هزینه دارد؟ این درخواست برای کسب‌وکار منطقی است. چیزی که منطقی نیست این است که افراد فنی بروند و وانمود کنند که چیزی که خواسته شده را به آنان داده‌اند. چون در روز صفر پروژه همان‌طور که گفتید مجهولات زیادی وجود دارد. ممکن است بی‌ثباتی‌هایی داشته باشیم. انواع مختلفی از بی‌ثباتی خواهیم داشت. بی‌ثباتی در تعداد کارمندان، به طور خاص چه کسانی عضو کارمندان خواهند بود؟ پروژه کی شروع خواهد شد؟ کارمندان کی در دسترس قرار می‌گیرند؟ دقیقاً چه ویژگی‌هایی در مجموعه قرار خواهند گرفت؟ توصیف جزئیات پیچیدگی‌های این ویژگی‌ها و … . ما بی‌ثباتی‌های بی‌شماری در روزهای نخست پروژه داریم. یکی از روش‌هایی که من در این مقطع می‌پسندم این است که سازمان لیستی از پروژه‌های قبلی که انجام داده است داشته باشد، که شامل هزینه و نیرو و زمان‌بندی است. بنابراین حتی در روز صفر پروژه کسب‌وکار می‌تواند بگوید ما فکر می‌کنیم پروژه‌ی جدید از لحاظ حجم چیزی شبیه به فلان پروژه است که بر اساس اطلاعات گذشته‌ی ما ۱۵۰۰ نفر/ساعت و ۴ ماه طول کشید. بنابراین پس از این افراد فنی می‌توانند بازگردند و بگویند بله به نظر ما هم این شبیه فلان پروژه است و یک برآورد کلی -چیزی مانند آن‌که با انگشت در هوا نگه داشتن مسیر باد را تشخیص دهیم- فکر می‌کنیم در همان محدوده باشد. این بدین معنی است که با پیشرفت بیشتر کار ممکن است دو برابر بیشتر یا کم‌تر باشد. این فکر منطقی است. یا ممکن است افراد فنی بازگردند و بگویند نه، من فکر می‌کنم شما فلان پروژه را در نظر دارید در حالی که واقعاً منظورتان فلان چیز و بهمان چیز دیگر هم هست و وقتی همه‌ی این‌ها را تجمیع کنیم چیزی شبیه به بیسار می‌شود که به میزان چشم‌گیری بیشتر است. می‌توانید این گفتگوها را در روزهای خیلی ابتداییِ پروژه داشته باشید. این‌ها به شما اعداد و ارقام نمی‌دهند و اما حداقل انتظارات شما را در محدوده‌ی مناسبی قرار می‌دهند.مفهوم مخروط عدم قطعیت به ما می‌گوید زمانی پروژه‌های نرم‌افزاری با سطوح بالای تغییر که از تمامی منابع سرچشمه می‌گیرند، شناخته می‌شوند که پروژه واقعاً در مسیر قرار بگیرد. از مجموعه‌ی ویژگی‌ها، عدم قطعیت‌های معماری، و عدم عطعیت‌های کارمندان گرفته تا چیزهایی مثل این‌که مفهوم پروژه تا چه حد در حین پروژه تغییر خواهد کرد و انواع عدم قطعیت‌های دیگر وجود دارد. اگر ما کارمان را در بخش مدیریت فنی خوب انجام دهیم، تلاش خواهیم کرد به منشأهای عدم قطعیت هجوم برده تا میزان تغییر را کاهش دهیم. اگر کارمان را خیلی خوب انجام دهیم، این کار را به ترتیب انجام خواهیم داد و ابتدا به منشأهای دارای بی‌ثباتی زیاد هجوم می‌بریم. یعنی در هر برهه از پروژه به منشأ دارای بیشترین میزان بی‌ثباتی هجوم می‌بریم طوری که تمامی منشأهای دیگر نسبت به مواردی که تا به حال به آن‌ها هجوم برده‌ایم بی‌ثباتی کم‌تری داشته باشند. این فعالیت‌ها است که مخروط عدم قطعیت را شکل می‌دهد و بی‌ثباتی را به شدت و به سرعت کاهش می‌دهد. بسیاری از تیم‌ها این‌طور عمل نمی‌کنند. تیم‌هایی را می‌بینیم که سخت‌ترین کار را برای آخر کار می‌گذارند که از منظر برآورد کنترل پروژه مطلقاً بدترین کار ممکن است :-) بنابراین مخروط عدم قطعیت راهی برای توصیف آن چیزی است که می‌تواند در یک پروژه‌ی سالم اتفاق بیفتد و به هیچ وجه توصیفی از آن‌چه که در تمام پروژه‌ها اتفاق می‌افتد نیست.این‌طور به نظر من می‌رسد که عدم قطعیت و مدیریت مخاطرات (Risk Management) خیلی به هم نزدیک هستند یا تقریباً یکسان هستند.فکر می‌کنم اگر نگاهتان را به مدیریت مخاطرات گسترده‌تر کنید، این‌طور باشد. وقتی ما در شرکت خودمان از مدیریت مخاطرات صحبت می‌کنیم معمولاً میان مدیریت مخاطرات ذاتی و اتفاقی تفاوت قائل می‌شویم. آن‌چه در پروژه‌های نرم‌افزاری می‌بینیم این است که همیشه روی مخاطرات اتفاقی تمرکز می‌کنیم. مثل این‌که فلانی و بهمانی پروژه را ترک کنند، یا این‌که فلان یا بهمان روش فنی جواب ندهد. اما فکر می‌کنم در اکثر پروژه‌ها مخاطرات اتفاقی در واقع در مقایسه با مخاطرات ذاتی ناچیز هستند. می‌توانیم این‌ها را مخاطرات عمومی هم بنامیم. مخاطرات عمومی یا ذاتی، مخاطراتی شبیه به این هستند که ما کارمان را در فهم نیازمندی‌ها خوب انجام نمی‌دهیم و [در نتیجه] مجبور خواهیم شد دوباره‌کاری کنیم. زمان زیادی را صرف ساختن چیز اشتباهی می‌کنیم و آن را به مشتری نشان می‌دهیم و آن‌ها می‌گویند ما این را نمی‌خواستیم و آن چیز دیگر را می‌خواستیم. کیفیت پایین هم یکی دیگر از مخاطرات فجیع ذاتی است. تیم‌های پروژه‌ی زیادی را می‌بینیم که کاری را بسیار عجولانه انجام می‌دهند و بخش زیادی از کار کیفیت را به تعویق می‌اندازند. بدهی فنی (Technical Debt) بدی را در حین پیشرفت کار انباشت می‌کنند. کارشان را روی پروژه انجام می‌دهند و فکر می‌کنند که در حال پیش‌رفت هستند اما در واقع به صورت غیر رسمی، در حال انباشت کردن مقدار زیادی کارِ رفع خطا هستند. این در واقع باعث ناپایدار شدن برآوردهای کنترل پروژه می‌شود. فکر می‌کنم خوب است که روی مخاطرات منحصر به فرد اتفاقی تمرکز کنیم؛ اما وقتی که به مخاطرات ذاتی -مخاطراتی که تقریباً در تمامی پروژه‌ها واقعاً رخ می‌دهند- بنگریم، [خواهیم دید] که میان کارهایی که برای باریک کردن مخروط عدم قطعیت انجام می‌دهیم و کارهایی که برای مدیریت مخاطرات ذاتی در پروژه‌ها انجام می‌دهیم، همپوشانی زیادی وجود دارد.چیزهایی مثل اسکرام، یا [متدولوژی‌های] چابک یا روش‌هایی که میزان تکرارکنندگی زیادی دارند هم هستند که در واقع مخاطرات را کاهش می‌دهند؛ حداقل بسیاری از مخاطراتی که شما توضیح دادید را کاهش می‌دهند. چون اگر بخواهم هر دو هفته یک‌بار چیزی که کار می‌کند را تحویل دهم یعنی چیزی که باید توسط یک سرویس تست و دیگر ذی‌نفعان مورد پذیرش قرار بگیرد، این باعث کاهش مخاطره‌ی انجام نشدن کار می‌شود.من عمدتاً به این شکل می‌بینمش -البته روی آن تأکید زیادی هم دارم- که آیا این واقعاً یک پیاده‌سازی کاملاً وفادار به اسکرام است؟ و آیا ما داریم دقیقاً در مورد اسکرام صحبت می‌کنیم؟ فکر می‌کنم بیش از حد بارِ کلمه‌ی چابک، شده و در حال حاضر فریبنده و آبکی شده است. به حدی که اگر تیمی بگوید که چابک کار می‌کند به من هیچ اطمینانی در رابطه با این‌که روش کار آن‌ها بهتر از آبشاری باشد، نمی‌دهد. فرض کنیم تیمی بگوید که از اسکرام استفاده می‌کند و حقیقتاً اسکرام انجام دهند و فقط حرف آن را نزده باشند و یک پیاده‌سازی تا حد زیادی وفادار به اسکرام داشته باشند. در این صورت، فکر می‌کنم بخشی از آن‌چه در اسکرام خیلی خوب جواب می‌دهد این باشد که روشی که در اسکرام جا انداخته می‌شود در واقع این استعداد نهانی را دارد که به برخی از مخاطرات ذاتی در پروژه‌ها هجوم ببرد. بنابراین این خیلی وابسته به این است که تیم یک پیاده‌سازی با وفاداری بالا به اسکرام داشته باشد.شما به دوره‌های دو هفته‌ای اشاره کردید. بله اگر تیم حقیقتاً دوره‌ها را کوتاه نگه دارد و چیزی را پایان هر دوره تحویل دهد، به چند طریق کمک می‌کند. یک راه این است که اگر از نظام (Discipline) پیش‌برد نرم‌افزار به سمت یک سطح قابل انتشار از کیفیت پیروی کنیم، به بررسی مخاطرات عمومیِ مربوط به کیفیت پایین کمک کرده‌ایم. اما بسیاری از تیم‌ها را می‌بینیم که از اسکرام استفاده می‌کنند و این‌کار را انجام نمی‌دهند. این یکی از حالت‌های اصلی شکست در اسکرام است. این که تیم‌ها نظام نگه‌داشتن نرم‌افزار در یک سطح قابل انتشار از کیفیت را ندارند. و وقتی چنین کاری را انجام می‌دهند مقدار زیادی از مزایای اسکرام را از دست می‌دهند. صِرف این‌که ما هر دو هفته یکبار [مؤلفه‌ها را] ادغام می‌کنیم حس بهتری از پیش‌رفت نسبت به آن‌چه در حالت آبشاری انجام می‌دهیم به ما می‌دهد. فرض کنید نیازمندی‌هایمان را به صورت دسته‌های بزرگ انجام داده‌ایم و بیشتر آن را در ابتدای کار انجام داده‌ایم. بنابراین طرح‌ریزیِ اسپرینت را انجام می‌دهیم و آن را به یک دوره‌ی دو هفته‌ای نگاشت می‌کنیم. تصور می‌کنیم این دوره‌ی دوهفته‌ای حدود ده درصد از نیازمندی‌های کلی پروژه را برآورده می‌کند. خوب اگر به انتهای دوره‌ی دو هفته‌ای برسیم و فقط نیمی از کار را انجام داده باشیم -به عبارت دیگر تنها پنچ درصد از پروژه را انجام داده باشیم- این یک داده‌ی اولیه‌ی خیلی قوی به ما می‌دهد که پروژه‌ی ما احتمالاً دو برابر بیشتر از آن‌چه فکر می‌کردیم طول خواهد کشید. این یک تضمین صد درصدی نیست اما باعث می‌شود سؤال ایجاد شود و باعث می‌شود این سؤال زودتر ایجاد شود. وقتی به دوهفته‌ی دوم وارد می‌شویم می‌توانیم بگوییم خود را می‌رسانیم و یا این که بگوییم همچنان با نیمی از آن سرعتی که فکر می‌کردیم پیش خواهیم رفت. دو هفته‌ی دیگر یک نقطه‌ی بررسی (Check Point) جدید خواهیم داشت. این عالی است. در پروژه‌های آبشاری سنتی که برای بیست هفته طرح‌ریزی شده بود، به راحتی ممکن بود پانزده هفته در پروژه پیش رویم پیش از آن‌که به فکر بیفتیم که مشکلی داریم. در بسیاری موارد ممکن بود نوزده و نیم هفته پیش برویم، پیش از آن‌که به این مشکل اقرار کنیم. اما اجرای خوب از یک پیاده‌سازی اسکرام ممکن است بعد از دو تا چهار هفته پس از طرح‌ریزی متوجه این مشکل شویم. بنابراین به لحاظ مدیریت مخاطرات عمومی، افکار واهی و برآوردهای کم، خیلی تأثیر گذار است.مسئله‌ی دیگر این است که ما به موضوع مدیریت مخاطرات رسیدیم. مدیریت مخاطرات شامل کنترل مخاطرات، مدیریت مخاطرات، اولویت‌بندی مخاطرات و ... می‌شود. اما نقطه‌ی شروع همه‌ی این‌ها شناسایی مخاطرات است. فکر می‌کنم یکی از چیزهایی که در اسکرام خصوصاً با دوره‌های کوتاه، تعبیه شده است این است که اگر در یک دوره آن‌چه که تصور می‌کردیم را تحویل ندهیم، باعث می‌شود از خود بپرسیم چرا این‌طور شد؟ این طبیعتاً به سرعت و مکرر موجب شناسایی مخاطرات می‌شود. بنابراین [با این که] اسکرام هرگز مستقیماً از شناسایی مخاطرات صحبت نمی‌کند، این مفهوم شناسایی مخاطرات اساساً از آن نتیجه می‌شود. با یک پیاده‌سازیِ با وفاداری بالا به اسکرام، شناسایی مخاطرات مداوم و زودهنگام را به دست می‌آوریم. اگر بتوانیم مخاطرات را زودهنگام شناسایی کنیم معمولاً گزینه‌های قدرت‌مندتری برای رسیدگی به آن مخاطرات داریم. در نتیجه همه چیز بهتر کار خواهد کرد. بنابراین بله، فکر می‌کنم اگر اسکرام بر اساس کتاب و با وفاداری بالا اتخاذ شود این استعداد نهفته برای کاهش مخاطرات مهمِ ذاتیِ سنتی و منشأهای بی‌ثباتی در نرم‌افزار را دارد.چیز دیگری که می‌خواهم توضیح دهم این است که یک زیرجریان (Undercurrent) در اسکرام وجود دارد که به نظر من با برآورد مغایر است. در اسکرام یک جوّ فرهنگی وجود دارد که فکر می‌کنم جزئی از سرمشق‌های اسکرام نباشد. اما اگر ادبیات اسکرام از جمله کتاب اصلی آن که توسط کِن شوِیبر و ... نوشته شده است را بخوانید، تأکیدی قوی بر توانایی اسکرام در انعطاف‌پذیری و پاسخ دادن به تغییرات و نیازمندی‌ها وجود دارد. به طوری که هر چند واقعاً ذکر نمی‌شود خیلی راحت ممکن است به این ایده برسید که تنها راهی که باید همواره یک پروژه‌ی اسکرام را اجرا کنیم این است که نیازمندی‌ها را در ابتدا تثبیت نکنیم و حتی تلاشی برای این کار نکنیم؛ صرفاً باید نیازمندی‌ها را در حین انجام کار شناسایی کنیم و در حین انجام کار آن را دگرگون کنیم و فقط از همین طریق آن را انجام دهیم. اگر این روش را اتخاذ کنیم -که ممکن است در برخی موارد جواب دهد- از هرگونه اندیشه‌ی برآوردهای طولانی مدت‌تر دست برداشته‌ایم. بنابراین زمانی که از اسکرام به این شکل سرمشق گرفته شود -به طور خاص اگر نیازمندی‌ها فقط دوره به دوره انجام شوند- ما از توانایی خود برای برآورد کردن، به شکل ضعیفی استفاده کرده‌ایم. من نمی‌گویم که این خوب است یا بد است، من می‌گویم وقتی که از [این] ترکیب اسکرام و برآورد کردن صحبت می‌کنم، این ترکیبی است که جواب نخواهد داد.چطور برآوردهای اسکرام و آن‌چه که واقعاً تحویل داد‌ه‌ایم را ارزیابی می‌کنید؟ مثلاً یک پروژه‌ی اسکرام را شروع می‌کنیم و برآوردهایمان را انجام می‌دهیم و تصمیم می‌گیریم که پنج ویژگی را می‌خواهیم. معمولاً [این کار را] تک به تک انجام نمی‌دهیم،‌ احتمالاً دو ویژگی را به صورت موازی انجام می‌دهیم. برآوردمان را [با] درجه‌ی داستان (Story Point) انجام می‌دهیم، و یک سرعت (Velocity) داریم. بعد از مدتی خیلی دشوار است که آن‌چه که قبلاً انجام داده‌ایم را با نیازمندی‌های اولیه تطبیق دهیم. چون هرگز میزان زمانی را که برای یک نیازمندی صرف کرده‌ایم را یادداشت نکرده‌ایم.فکر می‌کنم چند سؤال در اینجا وجود دارد. روشی که من با آن اسکرام و برآورد آشتی می‌دهم این است که -صادقانه بگویم، من فکر نمی‌کنم کار زیاد یا تغییر بزرگی در اسکرام نیاز باشد که تا این آشتی برقرار شود- از یک رویکرد دسته‌ای به نیازمندی‌ها در ابتدای پروژه استفاده شود. این به آن معنی نیست که بعداً نمی‌توانیم نظرمان را عوض کنیم. تمام فکر اصلی بیانیه چابک‌سازی (Agile Manifesto) در XP پذیرفتن تغییرات بود. این نبود که تعهد ندهید بلکه این بود که خودتان را به نحوی آماده کنید که وقتی تغییرات اتفاق افتاد بتوانید به آن پاسخ دهید و آن را بپذیرید. اسکرام به شما قابلیت خوبی در پذیرفتن تغییرات می‌دهد اما این به آن معنی نیست که شما نمی‌خواهید ثبات داشته باشید. بنابراین با قرار دادن حد کافی از تعاریف در نیازمندی‌ها این آشتی برقرار می‌شود. منظورم [تعریف کردن] هر اندازه از مجموعه کل نیازمندی‌هایتان است که می‌توانید در ابتدای پروژه‌ی اسکرام داشته باشید. این شامل این است که آن‌ها به قدری خوب تعریف شده باشند که بتوانید از برآوردهای درجه‌ی داستان برای آن استفاده کنید. سپس برآوردهای درجه‌ی داستان را انجام می‌دهید. محاسبه می‌کنید که در مجموع چند درجه داستان در پروژه دارید و آن را در زمان‌بندی نگاشت می‌دهید: تعداد داستان‌ها در هر دوره. سپس کار توسعه‌ی جزئیات پروژه را شروع می‌کنید و سرعت‌تان را اندازه می‌گیرید. این به شما توانایی چشمگیری می‌دهد تا بر این که آیا واقعاً درحال پیش‌رفت بر اساس طرح‌ریزی هستید و این که آیا واقعاً به برآوردهایتان دست می‌یابید، نظارت کنید. همیشه تصوری از آن‌چه که فکر می‌کنید سرعت اولیه‌تان خواهد بود دارید و بعد از دو یا سه دوره، داده‌های واقعی پروژه را خواهید داشت که می‌توانید از آن برای اصلاح کردن برآوردهایتان استفاده کنید. این داده‌ها یا به شما می‌گویند برآوردهای اولیه شما خوب بودند و یا این که نیاز به اصلاح دارند. در هر صورت هنوز هم در ابتدای پروژه هستید و این توانایی را دارید که بگویید ما فکر می‌کردیم سرعت‌مان ۲۵ درجه داستان در هر دوره خواهد بود اما الان که دست به کار شدیم با سرعت ۱۵ درجه داستان در هر دوره پیش می‌رویم. بنابراین اگر با همین سرعت پیش برویم ۶۷٪ از برآورد تجاوز خواهیم کرد. هیچ کس دوست ندارد که این را بشنود. کسی خبر بد را دوست ندارد. اما اگر به جای دیرتر گفتن، زودتر به آن‌ها بگویید رضایت بیشتری دارند. اسکرام قابلیت خوبی برای این به شما می‌دهد. اگر نیازمندی‌هایتان را از پیش تعریف کنید و تا سطحی از جزئیات این کار را انجام دهید که بتوان به آن درجه‌ی داستان نسبت داد. اتفاقی که می‌افتد این است که شاید شما چند دوره پیش بروید و تغییرات زیادی رخ ندهد و شما اولویت‌ها را به صورت نزولی تحویل می‌دهید. همه چیز خوب پیش می‌رود تا این‌که تغییرات رخ می‌دهند. این خیلی خوب است چون اسکرام سازوکار فوق‌العاده‌ای برای پذیرفتن این تغییرات به شما می‌دهد. می‌توانیم تغییرات پیشنهادی را در قالب درجه داستان برآورد کنیم و اولویت آن را در مقایسه با داستان‌های موجود در انباره‌ی انتشار (Release Backlog) تعیین کنیم. می‌توانیم آن‌ها را اضافه کنیم و بدانیم زمان‌بندی‌مان چه‌قدر زیاد می‌شود، چون چیزی به آن اضافه می‌کنیم و سرعت‌مان را می‌دانیم. یا این‌که می‌توانیم ویژگی‌های جدید را با کارهای کم اولویت‌تر در انباره جابجا کنیم و مجموع درجات داستان را ثابت نگه‌داریم.یکی از چیزهایی که برای من آزاردهنده است این است که در ساختار اسکرام ضرورتاً به شکلی است که گویی یک بهشتِ برآورد است: به ما قابلیت خوبی در ارائه‌ی برآوردهای عددی کیفی زودهنگام می‌دهد، به ما قابلیت بررسی و اصلاح زودهنگام برآوردها را در حین کار می‌دهد؛ به ما ساختار و نظامی برای صحبت کردن در مورد تغییرات را در حین انجام کار می‌دهد؛ به نحوی که برآوردهای قبلی را به طور کامل باطل نمی‌کند. بنابراین ابزار بسیار خوبی برای برآورد در اختیار شماست. اما [همه این‌ها در صورتی است که] تیم حاضر باشد این‌طور به اسکرام نگاه کند و به همین خاطر است که زمانی که درباره‌ی جو فرهنگی در تیم‌های اسکرام صحبت می‌کنم آزرده می‌شوم. گاهی تیم‌ها فکر می‌کنند برآورد کردن با اسکرام در تضاد است. من فکر می‌کنم خلاف این درست باشد. فکر می‌کنم اکثر کسب‌وکارها مایل‌اند تصوری از پایان کار و آن‌چه که برای آن پول صرف کرده‌اند داشته باشند. برآورد با این طرز فکرِ ارائه یک تصویر از آن‌چه کسب‌وکار برای آن خرج می‌کند، جفت و جور می‌شود.چیز دیگری که می‌گویم این است که من به شدت به این نتیجه رسیده‌ام که یکی از پاشنه‌های آشیل در توسعه‌ی چابک و تکرارشونده (Iterative) با نگاه از منظر کسب‌وکار این است که کسب‌وکارها ترجیح می‌دهند اشتباه کنند تا این‌که در ابهام باشند. منظورم این است که اگر بگوییم می‌خواهیم این مجموعه ویژگی‌ها را بسازیم که این‌قدر طول می‌کشد و این قدر هزینه دارد و به میانه‌ی پروژه برسیم و بگوییم می‌دانی چیست؟ الان تصویر بهتری داریم و می‌خواهیم برنامه‌مان را اصلاح کنیم؛ فلان ویژگی‌ها را اضافه می‌کنیم و بهمان ویژگی‌ها را حذف می‌کنیم و الان برنامه این است. کسب‌وکار در واقع با تغییر عقیده کنار می‌آید؛ با اشتباه بودن کنار می‌آید؛ اما برای شروع به چیزی واقعی نیاز دارد. بنابراین الگویی که توصیف کردم از منظر کسب‌وکار یک الگوی دوام‌پذیر و قابل پذیرش است. آن‌چه که معمولاً از منظر کسب و کار قابل قبول نیست این توصیف متعارف چابک است که می‌گوید پولی که دارید را به ما بدهید و مجموعه ویژگی‌های مورد نظرتان را هم بدهید که لازم نیست کامل باشد. ما هر دو هفته یک‌بار از شما می‌پرسیم ارزشمندترین چیز بعدی که می‌خواهید برایتان انجام دهیم چیست؟ این به شما امکان می‌دهد که حداکثر میزان ارزش را از پولی که خرج کردید دریافت کنید چون ما همیشه روی مهم‌ترین چیز باقی‌مانده کار می‌کنیم. منطقی در این [نگاه] وجود دارد. چیز بدی در این تحلیل وجود ندارد، آن‌چه که بد است این است که در اکثر موارد [این نگاه] با نحوه‌ی بودجه‌بندی و خرج‌کردن کسب‌وکار مطابقت ندارد. کسب‌وکار بودجه را صرف نمی‌کند مگر این‌که حداقل تصویری کلی از آن‌چه که برای پولش خواهد گرفت داشته باشد. بنابراین این اندیشه که به من اعتماد کن، [چون] من همیشه ارزشمندترین چیز بعدی را تحویل می‌دهم برای کسب‌وکار به این معنی نیست که شما [اجازه دارید] آن کار را انجام دهید. این ما را به موضوع برآورد بر می‌گرداند. برآورد به این هدف کسب و کار کمک می‌کند که می‌خواهد از آنچه در ازای پولش خواهد گرفت تصویری حداقلی داشته باشد.به خاطر دارم که سال‌ها پیش که اولین پروژه‌ی XP من بود، تعدادی فوق ستاره‌های آن زمان هم به عنوان مشاور حضور داشتند. کاری که کردیم این بود که نگاهی کلی به آن‌چه که در طول سال می‌خواهیم انجام دهیم انداختیم. سال را به دوره‌های سه ماهه تقسیم کردیم. به طور تقریبی میزان کاری را که در هر فصل قابل انجام بود، برآورد کردیم. این [برآورد] همیشه روی دیوار بود. همان‌طور که شما گفتید خیلی اوقات نظرمان را تغییر می‌دهیم؛ با این حال اگر کسی وارد اتاق شود می‌تواند ببیند در یک سال آینده چه خبر است و خودمان هم همیشه می‌توانستیم در میان راه ببینیم که کجا هستیم. در واقع فهم خوبی از جایی که هستیم نسبت به طرح‌ریزی بلند مدت یا سالانه یا محصول به طور کل داشتیم.نمی‌خواهم این‌طور جلوه دهم که رویکرد تکرارشونده‌ی خالص هرگز مفید نیست. فکر می‌کنم عرصه‌هایی هست که در آن مفید است مثلاً در یک زمینه‌ی اکتشافی تحقیقاتی. فکر می‌کنم یک راه برای توضیح آن -که عوام پسند نیست- این باشد: نیازمندی‌ها [به روش] آبشاری، توسعه [به روش] اسکرام. این به نوعی آن‌چه که می‌گویم را خلاصه می‌کند. فکر می‌کنم در خیلی موارد خوب کار می‌کند. اما نمی‌خواهم این را القا کنم که محیط‌های دیگری وجود ندارد که در آنجا انجام نیازمندی‌ها به روش تکرارشونده‌ی خالص مفید نباشد. اگر من در فضایی در حال ظهور قرار داشته باشم، مثلاً اگر من پنج سال پیش روی برنامه‌های تلفن همراه کار می‌کردم که نمی‌دانستم و نمی‌توانستم برای یک سال طرح‌ریزی کنم چون خیلی در حال تغییر بود آن زمان، برنامه‌ام را می‌نوشتم و هر دو هفته مهم‌ترین چیز بعدی را انجام می‌دادم. اگر بازار تا این حد ناشناخته و متغیر است احتمالاً این رویکرد خیلی خوبی است. اگر در یک زمینه‌ی تحقیقاتی هستم و میزان زیادی از مجهول‌های مرکب (Unknown Unknown) دارم؛ [یعنی] حتی نمی‌دانم مجهول‌هایم چه هستند؛ آن‌وقت این‌که سعی کنم بفهمم بزرگ‌ترین مجهولات پیش‌رو چه هستند و دوهفته‌ی بعدی را روی آن‌ها کار کنم و سپس برگردم و بزرگ‌ترین مجهول بعدی را پیدا کنم، فکر می‌کنم پاسخ مناسبی باشد. نکته این است که ما در حال صحبت کردن از برآورد هستیم و با وجود این‌که این [برآورد کردن] رویکرد درستی برای مدیریت و کنترل یک پروژه با میزان زیادی عدم قطعیت است، اما این روش‌ها [ی کاملاً اکتشافی] از برآورد حمایت نمی‌کنند. بنابراین برآورد در تک‌تک پروژه‌ها ضروری نیست. فکر می‌کنم همیشه مفید است که از کسب و کار پرسید آیا به برآورد اهمیت می‌دهد؟ اما عموماً حتی لازم نیست این سؤال را بپرسیم. کسب‌وکارها از همان اول شدیداً برآورد را از شما می‌خواهند. بنابراین خیلی واضح است که کسب و کار به برآورد اهمیت می‌دهد.حتی در یک محیط استارتاپ Lean، البته این کم و بیش همان چیزی است که چند دقیقه پیش توضیح دادید. درست است؟ اگر نرخ بالایی از تجربه کردن را داریم یا این‌که ویژگی‌های جدیدی برای کاربران داریم که نمی‌دانیم می‌خواهند یا نه، برای این قبیل کارها واقعاً به برآورد نیاز نداریم.بله فکر می‌کنم در محیط استارتاپ اگر صد درصد اطمینان دارید که ایده‌ی خوبی دارید به این شکل باشد. مثلاً اگر به عقب برگردیم و من Lotus 1-2-3 باشم و VisiCalc از پیش در بازار وجود داشته باشد و من می‌دانم که مأموریت من این است که می‌خواهم نرم‌افزار صفحه گسترده‌ی نسل بعد را تولید کنم. اگر بخواهم محصولی جالب و پیش‌گام و تغییردهنده‌ی دنیا را به صحنه بیاورم، مجهولات زیادی از لحاظ نیازمندی در اینجا وجود ندارد. باید نسل بعدی صفحه گسترده را منتشر کنم. بله ممکن است جزئیاتی در ویژگی‌ها باشد، اما تا حد زیادی آبشاری است و می‌توانید با آن مثل یک پروژه‌ی آبشاری رفتار کنید. بنابراین لزوماً تمام استارتاپ‌ها چنین رویکردی ندارند. استارتاپ‌های دیگر وجود دارند که افراد فکر می‌کنند زمینه‌ای در حال ظهور است و فرصت‌های بالقوه‌ی زیادی در آن هست. دقیقاً مطمئن نیستیم که این فرصت‌ها چیست. ممکن است شما یا سرمایه‌گذاران مایل باشید که پول یا سهمی از سود را صرف کاوش برای یافتن ایده‌های مفید کنید. ما موارد زیادی در اطراف خودمان نزدیک سیاتل می‌بینیم، استارتاپ‌هایی که افراد حاضرند چیزی را برای یک یا دو سال بیازمایند و می‌گویند می‌خواهیم ببینیم تا کجا می‌توانیم پیش برویم و سرمایه‌گذاران بر اساس ایده، علاقه و زمینه‌ی مملو از فرصت‌های بالقوه، گاهاً حاضر به صرف مقدار زیادی پول هستند.وقتی به کسب و کارهای جاافتاده می‌رویم فکر می‌کنم کمی متفاوت باشد. در یک کسب‌وکار جاافتاده، کسب و کار می‌خواهد بداند اگر صدهزار دلار یا یک میلیون دلار خرج می‌کند در قبال آن چیزی به دست می‌آورد و بنابراین این‌جاست که دوباره به فکر برآورد برمی‌گردیم. آن‌ها به برآورد نیاز دارند قبل از این‌که حتی حاضر باشند در مورد فرصت کسب و کاری که به پول نیاز دارد صحبت کنند. همیشه استثناهایی در همه چیز وجود دارد. اما متداول‌ترین حالت در اینجا این است که کسب و کارها به هر چیزی که نیاز به هزینه‌ی زیادی دارد نگاه می‌کنند و می‌خواهند به نوعی آن را مورد بررسی تجاری قرار دهند. این ممکن است رسمی یا غیررسمی باشد اما می‌خواهند این بررسی را انجام دهند. این [بررسی] شامل هزینه و سود است. هر دوی این‌ها خیلی تقریبی هستند. همه‌ی ما این را می‌دانیم؛ اما این به آن معنی نیست که این کار را به طور کل رها خواهیم کرد. کاری که واقعاً باید انجام دهیم این است که بفهمیم چطور این اعداد را بهتر کنیم. بنابراین از نظر افراد فنی کاری که باید انجام دهیم این است که تقریب بهتری از این اعداد ارائه دهیم. این کار ماست که بدانیم توانایی واقعی تحویل سازمان چیست تا بتوانیم به کسب و کار بگوییم که هزینه چقدر است. در دنیای بی‌نقص، کسب‌وکار هم، به همین میزان در برآورد فرصت‌های بالقوه‌ی کسب و کار خوب است و می‌تواند سود را محاسبه کند. اما خوب این مسئله‌ی آن‌هاست :-) مسئله‌ی ما این است که کارمان را به بهترین شکلی که می‌توانیم برای محاسبه‌ی هزینه‌ها انجام دهیم.چطور این کار را انجام دهیم؟ چه روش‌های خوب و بدی در برآورد کردن وجود دارد؟ اگر کسی از من بخواهد که فیس‌بوکی برای سگ‌ها بسازم. چطور به برآورد برسم؟فکر می‌کنم قبلاً به چند مورد کلیدی اشاره کرده‌ایم. یکی این است که قبل از آنکه بتوانیم برآوردی کنیم که ارزش زیادی داشته باشد، باید به اندازه‌ی کافی در مخروط [عدم قطعیت] پیش‌رفته باشیم تا بدانیم از چه صحبت می‌کنیم. بنابراین این‌که تشخیص دهیم که در کجای مخروط عدم قطعیت قرار داریم کلیدی است و اگر هنوز در سمت پهن مخروط باقی مانده باشیم نمی‌توانیم قطعیت زیادی داشته باشیم. بنابراین بدون آمادگی فکری، برآورد نکنید. اعداد حسی و تصادفی را که کسی از خود در می‌کند، به عنوان برآوردهای معنی‌دار تلقی نکنید. این‌ها واقعاً نکات کلیدی هستند. یک نکته‌ی کلیدی دیگر که فکر می‌کنم در مورد آن صحبت کردیم، این است که اطمینان حاصل کنیم تمایز واضحی میان برآوردها، اهداف و تعهد وجود دارد. ما می‌خواهیم مطمئن شویم که خودمان را با این افکار گیج نمی‌کنیم که واقعاً یک برآورد کرده‌ایم یا این‌که با فکر گروهی یک هدف یا تعهد را پذیرفته‌ایم بدون این‌که واقعاً آن را بسنجیم و برآورد کنیم. در مورد داده‌های تاریخی هم صحبت کردیم. از چند طریق در مورد نگه‌داری هزینه‌ها، زمان‌بندی‌ها و میزان نیروی مورد نیاز در پروژه‌های گذشته صحبت کردیم؛ این یک نوع از اطلاعات تاریخی است. گفتیم که با یک برآورد اولیه‌ی پروژه‌ی اسکرام را شروع کنیم، اما به محض این‌که بتوانیم سرعت واقعیِ مشاهده شده را محاسبه کنیم، فرصت داریم [برآورد را] اصلاح کنیم؛ این نوع دیگری از داده‌های تاریخی است که من به آن داده‌های پروژه می‌گویم. این با داده‌های سازمان متفاوت است. داده‌های پروژه در واقع قدرت‌مندترین نوع داده‌های تاریخی برای اهداف برآورد هستند. اگر این قبیل کارها را انجام دهیم از اکثر خطاهای بارز در برآورد جلوگیری کرده‌ایم و حداقل تا نیمه‌ی راه پیش رفته‌ایم.مشکل برآورد نرم‌افزار در عمل این نیست که افراد تلاش خالصانه می‌کنند ولی از روش اشتباهی استفاده می‌کنند. مشکل بیشتر این است که افراد تلاش خالصانه نمی‌کنند یا این‌که اصلاً نمی‌دانند تلاش خالصانه چه هست. بنابراین اولین قدم در انجام یک کار این است که بگویم می‌خواهم کاری عاقلانه انجام دهم و به آن تحت عنوان یک فعالیتِ برآورد، توجه می‌کنم و با هم به آن خواهیم پرداخت تا یک برآورد واقعی انجام دهیم. این بزرگ‌ترین قدمی است که سازمان برمی‌دارد. وقتی که به قدم دوم می‌رسیم، استفاده از نوعی از داده‌های تاریخی واقعاً راه‌گشاست. البته قطعاً سرمشق‌های بهتر یا بدتری وجود دارد که به نظر من نگرانی ثانویه است. برای پروژه‌های کوچک که تیم‌های دست‌نخورده داریم، تجزیه‌ی یک برآورد که در آن هر یک از اعضای تیم یک بخش را برآورد می‌کنند، می‌تواند تا حد قابل قبولی برای یک پروژه‌ی کوچک و کوتاه جواب دهد.متأسفانه یکی از الگوهای متداولی که در سازمان‌هایی -که خالصانه برای بهبود برآوردهایشان تلاش می‌کنند ولی فهم درستی از آن ندارند- می‌بینیم این است که قبل از موعد به سطح جزئیات زیادی وارد می‌شوند. این مایه‌ی ناراحتی است. چون کار به شدت زیادی انجام می‌دهند و انگیزه‌شان خوب است اما زیادی کار می‌کنند. روش مورد استفاده‌شان روش درستی نیست. بنابراین گاهی سخت است که شرکت‌ها را متقاعد کنید که می‌توانند با کار کم‌تر و وارد شدن به جزئیات کم‌تر به برآوردهای بهترِ زودهنگام‌تری دست‌یابند. افراد نرم‌افزاری گرایش به ورود به جزئیات دارند اما در حقیقت وقتی وارد پروژه‌های با اندازه‌های مختلف می‌شویم، برآورد بر اساس داده‌های تاریخی و براساس صفاتی در سیستم که قابل شمارش‌اند و ... [کاملاً مفید است]. این‌ها، سرمشق‌هایی هستند که به ما در ارائه‌ی برآوردهای معنی‌دار و دقیق‌تر در ابتدای پروژه کمک می‌کنند. مگر این‌که در مورد یک پروژه‌ی دو یا سه نفری صحبت کنیم که چند ماه بیشتر طول نمی‌کشد. برای پروژه‌های بزرگ‌تر لازم است به جای استفاده از عقیده [خبره] یا لیست وظایف، به سراغ چیزی که من در کتابم به آن شمارش و محاسبه می‌گویم برویم.الان من غافل‌گیر شدم. چون من فکر می‌کردم بهترین راه این است که آن را تقسیم کنیم. شاید نه با جزئیات کامل اما حداقل این‌که نیازمندی‌ها را جمع‌آوری کنیم و آن‌ها را تقسیم کنیم و هر تکه را برآورد کنیم. در روش شمارش، چه چیزی را می‌شمارید؟ اخیراً مجموعه‌ای از نیازمندی‌های خیلی سطحی از یک مشتری گرفتم. او می‌خواست بداند که هزینه‌اش چقدر است. من با خودم گفتم بیا بشماریم. فیلدها را بشماریم، دکمه‌ها را بشماریم اما بعد از آن کمی احساس شک کردم که درست است یا نه. رئیسم هم پرسید: دیدم که داری می‌شماری اما...:-) در این مورد فهمیدنش سخت است. مواردی هستند که چیزهایی که گفتید نشانه‌های خوبی از کلیت قلمروی پروژه هستند؛ نمی‌توانم در مورد خاص شما بگویم که این‌طور است یا نه. به طور کلی چون بسیاری از تیم‌ها از اسکرام استفاده می‌کنند، فکر می‌کنم درجه‌ی داستان در دسترس‌ترین چیز برای شمارش باشد. تفاوت چشم‌گیری میان بررسی یک لیست ویژگی‌های جزئی و برآورد نیرو یا زمان لازم برای هر یک از آن‌ها به جای برآورد کردن درجه‌ی داستان آن‌ها وجود دارد. وقتی درجه‌ی داستان را برای ویژگی‌ها برآورد می‌کنیم، احتمالاً تصوری کلی از این‌که هر درجه داستان به چند روز یا ساعت یا هفته تبدیل می‌شود، داریم. با این حال اندازه‌ی آن را با درجه‌ی داستان بیان می‌کنیم. بعداً چون همه چیز را با درجه‌ی داستان برآورد کرده‌ایم و درجه‌ی داستان یک مقیاس نسبی است، مقادیر مختلف درجه داستان‌ها وابسته به یکدیگر هستند. زمانی که پروژه آغاز شود ما این توانایی را داریم که درجه داستان‌ها را با توجه به داده‌های واقعی پروژه اصلاح کنیم. اگر از اسکرام استفاده کنیم می‌توانیم خیلی زود در ابتدای پروژه این کار را انجام دهیم. مثلاً دو یا چهار هفته بعد از شروع پروژه باید اصلاحاتی معقول داشته باشیم. از سوی دیگر اگر دقیقاً همان کار را و دقیقاً با همان سطح از جزئیات اما بر اساس تلاش [لازم برای انجام کار] برآورد کنیم، ممکن است منجر به خوش‌خیالی شود یعنی بگویم من فکر می‌کردم این سه روز طول بکشد اما وقتی شروع به کار کردم، متوجه شدم که نمی‌‌شود. ممکن است چون می‌خواهم در سه روز تمام شود لازم شود میان‌بر بزنم در نتیجه بدهی فنی وارد پروژه کنم. فکر می‌کنم حتی اگر از یک دید سطحی، عمل برآورد کردن در هر دو، خیلی یکسان به نظر برسد اما در تحرکات (Dynamics) کاملاً متفاوت باشند.اما اگر درجه داستان‌ها را بشمارید هنوز هم به فهم خوبی از نیازمندی‌ها نیاز دارید. درست است؟به فهم کافی از نیازمندی‌ها نیاز دارید تا بدانید برای یک داستان مقیاس درجه‌ی آن در کجا قرار می‌گیرد. اگر درجه‌ی داستان را بر اساس کتاب انجام دهید مقیاس آن بی‌نهایت قابل تقسیم نیست. این‌طور نیست که بگوییم ۱، ۲، ۳، ۳.۱، ۳.۲ و … . اعداد متداول درجه داستان، اعداد فیبوناچی هستند ۱، ۲، ۳، ۵، ۸، … بنابراین لازم نیست بدانید که یک چیز دقیقاً ۵ است، کافی است بدانید که به اندازه‌ی ۳ کوچک نیست و به اندازه‌ی ۸ بزرگ نیست. باید به اندازه‌ای بدانیم که این گفتگو میسر باشد. لازم نیست در ذهن مان بدانیم که ۵.۵ است یا ۵.۷ هدف این سرمشق این نیست.باشه، اما در نهایت من باید درجه داستان‌ها را به هفته یا روز تبدیل کنم. درست است؟در واقع خیر. منظورم این است که در نهایت باید درجه داستان‌ها را به طرح اسپرینت تبدیل کنید و این‌که ما فکر می‌کنیم چه مقدار کار در یک اسپرینت می‌توانیم انجام دهیم...اگر مدیر من بخواهد بداند...بله. البته اگر تیمی دست نخورده داشته باشید که قبلاً تعدادی پروژه انجام داده باشد؛ که گاهاً اتفاق می‌افتد. خوشحالم که بگویم یکی از آثار جانبی برنامه‌ریزی نشده و غیر شایعِ حرکت به سمت اسکرام و [متدولوژی‌های] چابک این باشد که تیم‌ها را نسبت به قبل بیشتر در کنار هم نگه می‌دارد. این عقیده که یک تیم کارای دست‌نخورده را تجزیه کنیم در بیست سال نخست [فعالیت] من در صنعت خیلی دردآور بود. فکر می‌کنم در ده سال اخیر کم‌تر آن را دیده‌ام و فکر می‌کنم خوب باشد. اگر تیم دست‌نخورده‌ای داشته باشید، آن‌ها احتمالاً درکی سنجیده از [درجه داستان] سه، پنج یا ... دارند. بنابراین می‌توانید سرعت آن‌ها را از پروژه‌های قبلی که روی آن کار کردند بفهمید. ممکن است دقیقاً مطابق نباشد اما معمولاً خطا حدود دو برابر است و خیلی نزدیک خواهد بود. اگر تیم دست‌نخورده‌ای نداشته باشید و افراد را جمع کرده‌اید،‌ احتمالاً افراد تصورات متفاوتی از [درجه داستان] سه یا پنج دارند. بنابراین تیم باید به عنوان یک تیم، مقداری کار کند تا همگام شود. می‌توانید که این برآورد را خیلی زود در ابتدای پروژه به مدیرتان ارائه کنید و بگویید که مجموعه ویژگی‌ها ما ۲۴۰ درجه داستان است و بهترین حدس ما این است که می‌توانیم ۲۰ درجه داستان در هر دوره انجام دهیم که این پروژه را در ۱۲ دوره به پایان می‌رساند. قطعاً می‌توانید این را ارائه کنید اما می‌توانید همزمان با آن بگویید که ما سرعت تیم جدید را از روز اول اندازه خواهیم گرفت و وقتی که به دوره‌ی دوم یا سوم برسیم، یعنی ۴ تا ۶ هفته بعد از شروع پروژه، تصویری سنجیده‌تر از این‌که آیا ۲۰ درجه داستان در هر دوره قابل دست‌یابی است یا نه خواهیم داشت. حداکثر ۶ هفته دیگر برمی‌گردیم و به شما می‌گوییم که زمان‌بندی ۲۰ هفته‌ای هنوز هم واقع‌بینانه است یا باید آن‌ها را بر اساس مشاهدات تغییر دهیم.من که شگفت‌زده شده‌ام. چون خیلی وقت پیش یاد گرفتم که هنگام برآورد کردن عدم قطعیت‌ام را در برآورد با یک بازه بیان کنم. اگر کسی از من بپرسد که چقدر وقت می‌گیرد، می‌گویم بین ده تا سی روز یا ده تا سیزده روز. هر چه بازه بزرگ‌تر باشد،‌ عدم قطعیت‌ام را بیشتر بیان کرده‌ام. اگر با درجه داستان‌ها برآورد می‌کنیم این از بین می‌رود.در واقع از بین نمی‌رود چون عدم قطعیت از درجه داستان‌ها نشأت نمی‌شود، از سرعت نشأت می‌شود. بنابراین فکر می‌کنم به موضوع تمایز میان برآورد و تعهد برگشتیم. اگر مدیر من واقعاً یک برآورد از من می‌خواهد می‌توانم بگویم ما درجه داستان‌ها را شمرده‌ایم که ۲۴۰ است. اگر به سابقه‌ی افراد در این تیم و سرعت آن‌ها در پروژه‌های دیگر نگاه کنیم، به نظرمان می‌رسد سرعت‌مان چیزی بین ۱۵ تا ۲۵ درجه داستان در هر دوره باشد. هنوز به اندازه‌ی کافی اطلاعات نداریم تا مطمئن باشیم که سرعت‌مان ۱۵، ۲۰، یا ۲۵ است یا چیزی بین این‌هاست. بنابراین اگر امروز از ما برآورد بخواهید به شما بازه‌ای بر اساس ۲۴۰ درجه داستان با سرعتی بین ۱۵ تا ۲۵ درجه داستان در هر دوره می‌دهیم. اگر امروز از ما تعهد می‌خواهید،‌ تعهدمان را بر اساس حداقل بهره‌روی می‌دهیم که همان ۱۵ درجه داستان در هر دوره است. اما اگر به ما شش هفته فرصت بدهید می‌توانیم تعهد دقیق‌تر و بازه‌ی کوچک‌تری بدهیم و در حقیقت بازه نمی‌دهیم، تعهد می‌دهیم. ممکن است در ذهنمان بازه‌ای داشته باشیم اما آن زمان شرایط‌مان شبیه همان چمدان است؛ می‌دانیم که چه اندازه‌ای از چمدان نیاز داریم. ممکن است تغییراتی وجود داشته باشد که میزان زور مورد نیاز برای بسته شدن آن را تحت تأثیر قرار دهد، یعنی این‌که آیا پروژه به راحتی تمام خواهد شد یا باید مقداری اضافه‌کاری کنیم. اما تصور خیلی خوبی از تحویل کاری که سازمان از ما می‌خواهد، خواهیم داشت. ما با سازمان‌هایی کار می‌کنیم که عکس‌العمل‌های متفاوتی نسبت به این دارند. برخی‌ها می‌گویند ما الان تعهد را می‌خواهیم و اگر تنها چیزی که الان می‌توانید متعهد شوید سرعتی برابر با ۱۵ درجه داستان در هر دوره و تبعات آن است، ما امروز در فرایند طرح‌ریزی‌مان به آن احتیاج داریم و اشکالی ندارد. برخی دیگر می‌گویند متوجه هستیم که مقداری عدم قطعیت وجود دارد و ما ترجیح می‌دهیم تصویر واضح‌تری داشته باشیم. اگر ارزش بیشتری وجود داشته باشد نمی‌خواهیم عجولانه بهره‌وری شما را از آن‌چه که هست کم‌تر در نظر بگیریم. هرچند فعلاً عددی مثل ۲۰ درجه داستان در هر دوره را به عنوان سرعت در طرح‌ریزی قرار می‌دهیم و بر اساس آن زمان‌بندی می‌کنیم. اما برنامه داریم که طرح‌ریزی را در چهار تا شش هفته‌ی آینده بر اساس سرعت مشاهده شده به‌روزرسانی کنیم و می‌دانیم که این عدد قطعی تعهد شماست که می‌توانید به آن دست پیدا کنید. چون بر اساس داده‌های تاریخی و به طور خاص داده‌های پروژه است.بسیار خوب. نزدیک به پایان هستیم. سؤال آخر. ما در مورد اسکرام زیاد صحبت کردیم. اگر در اسکرام برآورد کنیم، معمولاً پوکرِ طرح‌ریزی (Planning Poker) را داریم،‌ یعنی تعداد زیادی از افراد برآورد می‌کنند. آیا این خوب است؟ و اگر بله، چرا؟بله قطعاً پوکرِ طرح‌ریزی رویکرد مثبتی است که می‌تواند خوب عمل کند. پوکرِ طرح‌ریزی مثالی از خانواده‌ای از روش‌های برآورد کردن است که با عنوان روش‌های تصمیم‌گیری گروهی ساخت‌یافته (Structured Group Decision Making Techniques) شناخته می‌شوند که در واقع همانی است که به نظر می‌رسد. افراد را در گروهی کنار هم قرار می‌دهد و ساختاری حول نحوه‌ی تصمیم‌گیری آنان شکل می‌دهد. پوکرِ طرح‌ریزی مقرراتی دارد که این ساختار را فراهم می‌کند. این مقررات شامل چیزهایی مثل این است که از مقیاس اعداد فیبوناچی استفاده می‌کنیم، هر کدام از ما جداگانه برآوردهایمان را می‌کنیم و همزمان نتیجه را نشان می‌دهیم. ممکن است مقرراتی در مورد این‌که اگر افراد بازه‌ای از برآورد داشتند یا هر کسی برآورد متفاوتی داشت، وجود داشته باشد یا وجود نداشته باشد. این یک راه انجام آن است. من فکر می‌کنم می‌تواند خوب جواب دهد. تیم‌هایی را دیده‌ایم که بخش پوکر را به معنای کلمه تعبیر می‌کنند و به اتاق کنفرانس می‌روند و عینک‌های سبز می‌گذارند و :-) فایده‌ای برای من ندارد اما اگر یک فعالیت خسته‌کننده را کمی جذاب‌تر می‌کند فکر می‌کنم ایرادی نداشته باشد.یکی از چیزهایی که در مورد پوکرِ طرح‌ریزی دوست دارم این است که تصمیم‌گیری گروهی ساخت‌یافته یک راه برای توصیف آن است. راه دیگر توصیف آن می‌تواند یک جلسه باشد. جلسات برای سوزاندن بی‌ثمر وقت بدنام شده‌اند. اکثر افراد، خصوصاً افراد فنی واقعاً از جلسات بیزار هستند. یکی از چیزهایی که من در مورد پوکر طرح‌ریزی دوست دارم این است که اگر آن را به نحوی که باید، انجام دهید، دستورالعملی برای اجرای یک جلسه‌ی خوب است. سرعت پوکرِ طرح‌ریزی باید خیلی زیاد باشد. باید روی برآورد کردن فقط در مقیاس تعیین شده تمرکز کنید و اقلام درون انباره را بررسی کنید و این باعث ادامه‌ی گفتگو می‌شود. این به آن معنی نیست که در همه‌ی موارد، هیچ‌گاه گفتگو از خط خارج نمی‌شود، اما اگر آن را بر اساس مقررات انجام دهید، ساختاری واقعاً ساخت‌یافته برای اجرای یک جلسه‌ی خوب است. دلیلی برای این‌که کسی بی‌حوصله شود وجود ندارد چون به طور منظم و پی‌درپی در حال برآورد کردن ویژگی بعدی هستند.حالا که این‌ها را گفتم و با این‌که پوکرِ طرح‌ریزی را دوست دارم و هیچ‌وقت تلاش نمی‌کنم تیمی را که از آن استفاده می‌کند و آن را دوست دارد و برای آن‌ها خوب جواب می‌دهد، را از انجام آن باز دارم اما این تنها راه ممکن برآورد کردن نیست. در کلاس‌های شرکت من یک روش جایگزین که ما تدریس می‌کنیم «دم را به برآورد بچسبان» نام دارد (این اصلاح از بازی کودکانه‌ی دم را به الاغ بچسبان برگرفته شده است-مترجم). در این روش ما مقیاسی را روی دیوار داریم که اعداد فیبوناچی روی آن نوشته شده‌اند. داستان‌های مختلف در کاغذ یادداشت‌ها نوشته شده‌اند. سپس در یک فرایند گروهی تصمیم می‌گیریم که یک کاغذ یادداشت در کجای دیوار قرار می‌گیرد، در عدد ۵، در عدد ۸، در عدد ۱۳ یا … . این مثال دیگری از روش تصمیم‌گیری گروهی ساخت‌یافته است. جزئیات آن متفاوت‌ است اما موفقیت خوبی با استفاده از این روش داشته‌ایم. من نمی‌گویم که این روش از پوکر طرح‌ریزی بهتر است یا بدتر. بعضی از گروه‌هایی که با آن‌ها کار می‌کنیم آن روش را دوست دارند. مثلاً برخی گروه‌ها این‌که به جای ایستادن، می‌نشینید و چنین چیزهایی را بیشتر دوست دارند. فکر می‌کنم در حالت کلی روش‌های تصمیم‌گیری گروهی ساخت‌یافته یکی از روش‌های خوب برای برآورد و قطعاً نسبت دادن درجه داستان‌ها به طور خاص، هستند.بسیار خوب. آیا چیز مهمی هست که من یادم رفت از شما بپرسم؟خوب، برآورد موضوع گسترده‌ای است. در‌واقع، یک موضوع اصلی‌ در مهندسی نرم‌افزار است که من را در سال‌های ابتدایی حرفه‌ام به موضوعات ساخت‌یافته‌تر و رسمی‌تر در مهندسی نرم‌افزار علاقه‌مند کرد. بنابراین من تمایل دارم بخش زیادی از توسعه‌ی نرم‌افزار را از دریچه‌ی برآورد بنگرم. یکی از دلایلی که به نظرم برآورد جالب است این است که اگر تیم پروژه در برآورد، ضعیف عمل می‌کند، می‌تواند دلایل متعددی وجود داشته باشد. اما اگر در برآوردها خوب عمل می‌کنند معمولاً به این معنی است که خوب برآورد کرده‌اند اما همچنین به این معنی است که خیلی چیزهای دیگر را هم خوب انجام می‌دهند. بنابراین فکر می‌کنم دریچه‌ی برآورد، دریچه‌ی جالبی برای از نظر گذراندن مهندسی نرم‌افزار به طور کلی باشد. اگر برآورد را به خوبی درک کنید، راه زیادی را در درکِ درست توسعه‌ی نرم‌افزار به طور کلی پیموده‌اید. بنابراین این چیزی است که حدود سی سال من را به این موضوع علاقه‌مند نگه داشته است. دوست دارم این گفتگو به سایر افراد در گرایش به برآورد و سرمشق‌های مهندسی نرم‌افزار کمک کرده باشد.فکر می‌کنم این‌طور باشد. به جز کتاب‌تان منبع دیگری هم دارید که شنوندگان ما باید در مورد برآورد نرم‌افزار بدانند؟کتاب من در بردارنده‌ی اکثر مفاهیم مهم در مورد برآورد است. در سال ۲۰۰۶ منتشر شده است و در آن زمان برخی از سرمشق‌های اسکرام به هیچ‌وجه به توسعه‌یافتگی امروز نبودند و برآورد در اسکرام به نسبت آن‌چه که در کتاب توضیح داده‌ام پیش‌رفت کرده است. شرکت من یک کلاس آموزشی آنلاین در مورد برآورد دارد که من آن را تدریس می‌کنم، ممکن است افراد به آن علاقه‌مند باشند. یکی از چیزهای مورد علاقه‌ی من یک مطلب است که چند سال پیش در مورد یک پروژه‌ی تابستانی برای ساختن یک قلعه برای بچه‌هایم، نوشتم. فکر می‌کنم چند نکته‌ی جالب در مورد برآورد در آن پروژه وجود داشت. فکر می‌کنم یکی از جالب‌ترین مطالبی باشد که نوشته‌ام :-)خوب است. استیو از شما متشکرم که در برنامه حضور داشتید. سید مرتضی هاشمی سید مرتضی هاشمی Fri, 12 Nov 2021 01:11:51 +0330 https://virgool.io/se-radio/se-radio-technical-debt-s1zmfbyyrobz مطلبی که می‌خوانید ترجمه‌ی قسمت ۲۲۴ از رادیو مهندسی نرم‌افزار است. رادیو مهندسی نرم‌افزار هر یکی دو هفته یک بار مصاحبه‌ای درباره‌ی یکی از موضوعات حوزه‌ی مهندسی نرم‌افزار با افراد خبره و با تجربه در موضوع مورد بحث ترتیب می‌دهد.در این اپیزود که در آوریل ۲۰۱۵ منتشر شده است، سوِن یوهان و ابرهارد ولف در مورد بدهی فنی (Technical Debt) صحبت می‌کنند. آن‌ها در نوشتن مقاله‌ای در مورد بدهی فنی با هم همکاری کرده‌اند. این قسمت به شکل مصاحبه نیست بلکه سوِن و ابرهارد با هم بحث را پیش می‌برند.سوِن، چند کلمه در مورد خودت به ما بگو.اسم من سوِن یوهان است و به عنوان توسعه‌دهنده‌ی نرم‌افزار در Trifork در آمستردام کار می‌کنم. همچنین دست‌اندرکار کنفرانس‌های GOTO هستم و خوشحالم که میزبان ریزسرویس‌ها در جلسه‌ی آمستردام هستم.بله، خیلی جالب به نظر می‌رسد. من ابرهارد ولف هستم. من مستقل کار می‌کنم (Freelance). همچنین رئیس هیأت مشاوره‌ی فناوری در Adesso AG هستم. من در کنفرانس‌ها (اکثراً در آلمان) سخنران هستم و اخیراً کتابی در مورد تحویل مستمر نوشتم. همچنین دست‌اندرکار کنفرانس‌های GOTO و چند کنفرانس دیگر هستم.اجازه بدهید به موضوع بپردازیم. بدهی فنی به وضوح با کیفیت نرم‌افزار ارتباط دارد. بنابراین قبل از این‌که وارد عمق بحث بدهی فنی بشویم باید در مورد کیفیت صحبت کنیم. انواع مختلفی از کیفیت وجود دارد. یک نوع از آن کیفیت خارجی است. این کیفیتی است که می‌تواند توسط کاربر یا مشتری مشاهده شود. ممکن است کارایی، امنیت، مقیاس‌پذیری، پایداری و ... باشد. [این نوع کیفیت] می‌تواند توسط کاربر اندازه‌گیری و مورد آزمایش قرار بگیرد؛ چون ویژگی‌ای از محصول است. چیزی است که باید توسط مالک محصول یا افرادِ حوزه‌ی کسب و کار مدیریت شود. چون آن‌ها هستند که به کیفیت و چگونگی دریافت آن توسط مشتری علاقه‌مند هستند. مثل خریدن یک خودرو است که ویژگی‌هایی دارد؛ [کیفیت] صرفاً یکی از ویژگی‌های محصول است.قسمت پیچیده‌تر در توسعه‌ی نرم‌افزار کیفیت داخلی است. کیفیت داخلی فقط توسط توسعه‌دهندگان یا افراد فنی قابل مشاهده است. [کیفیت داخلی] هر چیزی است که گسترش و نگه‌داری کد را سخت‌تر یا آسان‌تر می‌کند. ممکن است تست‌هایی باشد که وجود دارند یا ندارد، چون اگر تست داشته باشیم، تغییر کد آسان‌تر است. ممکن است سبک معماری یا مشکلات آن باشد. همچنین مربوط به مشکلات کد است، این‌که کد بیش از حد پیچیده یا بیش از حد ساده است. شبهه‌ای که در مورد آن وجود دارد این است که توسط هیچ‌کس به جز افراد فنی قابل مشاهده نیست. این به آن معنی است که مدیریت کیفیت داخلی در واقع دشوار است. چون اگر فردی فنی نباشید، درک این کیفیت و تأثیر آن روی فرایند توسعه سخت است. این چیزی است که در مورد بدهی فنی هم مهم است.سوِن می‌خواهی در این مورد صحبت کنی؟بله. اساساً می‌توان گفت بدهی فنی تشبیهی برای توصیف کد نامطلوب است. [اصطلاح] بدهی اشاره‌ای به بدهی مالی دارد و از آن استفاده می‌کنیم تا [مفهوم] این کیفیت داخلی و ریسک کد را به افراد غیرفنی منتقل کنیم. توسعه‌دهندگان همواره در مورد کدهای باکیفیت و خوب صحبت می‌کنند اما افراد غیرفنی عموماً فایده‌ی آن را درک نمی‌کنند. به نظر آن‌ها «نرم‌افزار خوب کار می‌کند، چرا باید در کیفیت سرمایه‌گذاری کنم؟!». تشبیه بدهی فنی به ما کمک می‌کند که توضیح دهیم اگر بخواهیم بر اساس کد نامطلوب چیزی بسازیم، این باعث می‌شود توسعه‌های بعدی گران تمام شوند؛ زمان بیشتری صرف پیاده‌سازی یک ویژگی به کدی که خیلی خوب نیست، می‌شود. همچنین دیر یا زود این کیفیت داخلی تبدیل به کیفیت خارجی می‌شود؛ این هم مسئله‌ی است که باید بفهمانیم. مثلاً اگر کد بدی داشته باشیم، باگ‌های بیشتر و بیشتری خواهیم داشت و کند می‌شویم و این مشکل به تدریج به ذی‌نفعان و پروژه هم منتقل می‌شود. بنابراین بدهی فنی در حقیقت مشکل توسعه‌دهنده نیست، یک مشکل در سطح شرکت است. اگر بدهی فنی زیادی داشته باشید، در شرایط بحرانی تمام تیم مهندسی متوقف می‌شود. فکر می‌کنم خیلی از شرکت‌ها این را تجربه کرده باشند؛ فرضاً سامانه‌های [نوشته‌شده] با COBOL که امکان تغییر چیزی را در آن نداشتند.بنابراین می‌شود ادعا کرد که بدهی فنی یکی از موارد کلیدی در موفقیت تجاری نرم‌افزارهای توسعه‌داده‌شده است. این اصطلاح توسط وارد کانیگهام در سال ۱۹۹۲ ابداع شد. او چنین چیزی گفت: «انتشار اولین کد مثل بدهکار شدن است. کمی بدهی، سرعت توسعه را بهبود می‌بخشد؛ به شرطی که در اولین فرصت با بازنویسی کد، تسویه شود... خطر زمانی رخ می‌دهد که تسویه نشود. هر دقیقه که صرف کد نامطلوب شود به عنوان بهره تلقی می‌شود. تمامی یک سازمان مهندسی می‌تواند تحت بار بدهی این کد نامستحکم، به حالت توقف کشانده شود، [خواه این اشکال] از نوع شئ‌گرایی باشد یا نباشد.» (متن کانینگهام را می‌توانید از این لینک ببینید -مترجم)‌ این به وضوح می‌گوید که تشبیه بدهی فنی ارتباط نزدیکی با بدهی مالی دارد و مربوط به انتشار سریع یک چیز و در نتیجه بدهکار شدن است. بعداً باید این بدهی را با بهبود کیفیت، تسویه کنید و اگر این کار را نکنید مجبور به پرداخت نرخ بهره هستید چون بهره‌وری شما کاهش پیدا می‌کند و توسعه‌تان کند می‌شود. و همان‌طور که سوِن الان گفت این تشبیه مناسبی برای صحبت با مدیریت است چون آن‌ها با اصطلاحات مالی آشنا هستند. با استفاده از این اصطلاحات راحت‌تر است که به آن‌ها بگوییم این مثل رفتن به بانک است. برای مدتی سود دارد اما در نهایت باید آن را بازپس دهید؛ اصل و بهره‌ی آن را. این‌طور بود که این اصلاح ابداع شد. اما تعریف دیگری هم وجود دارد. درست است سوِن؟دقیقاً، دقیقاً. انجمن محققین ترجیح می‌دهند از تعریف مک‌کانل استفاده کنند. او می‌گوید: بدهی فنی‌ای که رویکردی در طراحی یا ساخت باشد در کوتاه‌مدت عملی است. اما یک زمینه‌ی فنی ایجاد می‌کند که در آینده انجام کار در آن به نسبت الان زمان بیشتری خواهد گرفت، این شامل افزایش هزینه در گذر زمان هم هست. فکر می‌کنم این تعریفی است که اکثر ما از بدهی فنی می‌دانیم. کاری را سریع و کثیف انجام می‌دهیم و چیزی در کوتاه‌مدت به دست می‌آوریم اما می‌دانیم که در درازمدت گریبان‌گیرمان خواهد شد.این بیش از حد معمول است. فکر می‌کنم بعد از توضیح تشبیه، مهم‌ترین بخش این است که چطور با بدهی فنی برخورد کنیم؟ همان‌طور که گفتم، [بدهی فنی] یکی از کلیدهای کسب و کار موفق در توسعه‌ی نرم‌افزار است. بنابراین سؤال این است که چطور با آن برخورد می‌کنید؟ احتمالاً اولین سؤال این است که آیا اصلاً چیز بدی است؟اگر درباره‌اش فکر کنید، بدهکار شدن اغلب چیز بدی نیست. اگر برای مثال یک خانه بخرید، می‌توانید مقداری از پول‌تان را پس‌انداز کنید چون دیگر اجاره پرداخت نمی‌کنید و این نوع از سرمایه‌گذاری ممکن است چیز خوبی باشد. به همین‌خاطر است که در صنعت، وام وجود دارد. به شما پول می‌دهند تا در ماشین‌آلات بهتر یا هر چیز دیگر سرمایه‌گذاری کنید و بهره‌وری را بهبود دهید و تولید را بیشتر کنید و آن را پس دهید. بنابراین بدهی لزوماً چیز بدی نیست. در برخی موارد -اگر دوباره به تشبیه بنگریم- ممکن است بد باشد. اگر صرفاً برای خرید کالاهای تجملی، یا هدیه سال نو یا ... بدهکار شوید، این پول سرمایه‌گذاری نشده است، صرفاً خرج شده و رفته است. بنابراین در ارتباط با تشبیه در توسعه‌ی نرم‌افزار همیشه معنی ندارد که بدهی را پرداخت کنیم. چرا این‌طور است؟ علت این است که در مقایسه با بدهی عادی نرخ بهره‌ای که شما پرداخت می‌کنید تنها زمانی تغییر می‌کند که شما کد را تغییر می‌دهید. بنابراین همان‌طور که گفتیم کیفیت داخلی مربوط به این است که کد چقدر قابل تغییر است. اگر کد را تغییر ندهید کیفیت داخلی و بدهی فنی اصلاً اهمیت ندارد. بنابراین تسویه‌ی بدهی فنی در بخش‌هایی از کد که تغییر نمی‌کنند اصلاً معنی ندارد.مسئله‌ی دیگری هم وجود دارد که یکی از بخش‌های نامهربان بازیِ توسعه‌ی نرم‌افزار است و آن، این است که شخصی که بدهی را پرداخت می‌کند لزوماً کسی که آن را تحمیل کرده نیست. بنابراین اگر در یک پروژه، یک تیم نرم‌افزاری را تولید می‌کند و تیم متفاوتی قرار است بعداً نگه‌داری را انجام دهد، تیمی که پیاده‌سازی را انجام می‌دهد نرخ بهره و بدهی فنی را پرداخت نمی‌کند؛ تیم نگه‌داری این کار را خواهد کرد. در این مورد ممکن است به نفع تیم پیاده‌سازی باشد که بدهی فنی را انباشت کند، چون سریع‌تر پیش می‌روند و هرگز به جنبه‌ی منفی آن بر نخورند، چون این کار تیم نگه‌داری است. این یکی از مشکلاتی است که ممکن است در رابطه با بدهی فنی داشته باشید؛ کسی که بدهی فنی را به وجود می‌آورد ممکن است بعداً مسئول آن نباشد.همچنین مدتی پیش گفتگویی با وارد کانینگهام درباره‌ی بدهی فنی داشتیم و او گفت: خب، در واقع بدهی فنی یک راهبرد است. چرا یک راهبرد است؟ چون می‌توانیم با بدهکار شدن به سرعت به هدف کسب و کار برسیم. چون ممکن است به بازار فرستادن چیزی خیلی مهم‌تر از مثلاً داشتن کد بی‌نقص و دیر رسیدن باشد. اما می‌توانیم چیزی را در بازار بفرستیم و اگر اولین بار باشد ببینیم که اصلاً به درد می‌خورد یا نه. فکر می‌کنم جالب است که مثلاً اریک ریس نویسنده‌ی کتاب The Lean Startup در کتابش توضیح می‌دهد که وقتی در استارتاپ کار می‌کرد همیشه خوشحال بود که کد بی‌نقصی نوشته است اما در نهایت هیچ‌کس از آن استفاده نمی‌کرد. بنابراین عملکردی که با کد بی‌نقصش ساخته بود کاملاً بدون استفاده بود. پس بهتر است چیزی را سریع بنویسید و به کاربر برسانید و ببینید که آیا برای کسی مفید است؟ اگر برای کسی مفید است آن وقت است که بدهی فنی را پرداخت می‌کنیم. اگر کد بی‌نقصی برای عملکردی که نمی‌دانیم مفید است یا نه بنویسیم هدر دادن زمان است. هنریک نیبرگ از Spotify حدود یک سال پیش در بلاگش چیزی نوشت: اگر عملکرد کد بی‌نقص «واقعاً» مفید نباشد، ما آن را زباله در نظر می‌گیریم. کاری که آن‌ها می‌کنند این است که یک عملکرد را خیلی سریع راه‌اندازی می‌کنند در حالی که ظاهر خوبی ندارد و آن را به مشتری می‌رسانند. اگر کاربر آن را دوست داشت و خواست از آن استفاده کند آن را Refactor می‌کنند و بهبود می‌دهند. این راهبردها را مدام و مدام می‌بینیم. فکر می‌کنم یک نمونه‌ی مشهور آمازون و تویتر باشد. فکر می‌کنم در تویتر این حس وجود دارد که انگار همیشه دارند سامانه‌شان را بازنویسی می‌کنند :-) چون فکر می‌کنم در ابتدا یک برنامه Ruby on Rails بود و الان یک سامانه‌ی اشتراک پیام است. آمازون هم در ابتدا سامانه‌ی کاملاً متفاوتی به نسبت آن‌چه که الان هست، بود. بله، فکر می‌کنم یک راهبرد باشد.و ضمناً این چیزی است که وقتی من با معماران نرم‌افزار صحبت می‌کنم، تذکر می‌دهم. به آن‌ها تمرین‌هایی می‌دهم، اغلب آن‌ها راه‌حل‌هایی ارائه می‌دهند که مقیاس‌پذیری را در نظر می‌گیرد و فکر می‌کنند که مقیاس‌پذیری نگرانی اصلی‌شان است در حالی که در واقع باید روی زمان رسیدن به بازار تمرکز بیشتری داشته باشند. در غیر این‌صورت به نقطه‌ای که به مقیاس‌پذیری نیاز داشته باشند، نخواهند رسید. چون احتمالاً قبل از آن شرکت ورشکست می‌شود فرصت کسب و کار از دست خواهد رفت. بنابراین همان‌طور که می‌بینید همیشه بد نیست. با این حال باید به نحوی با بدهی فنی روبرو شوید. یکی از ایده‌های بزرگی که من به آن برخوردم ایده‌ی اریک ایوانز بود که به خاطر کتاب Domain Driven Design مشهور است. بخشی از کتاب هست که تقریباً همه آن را می‌دانند؛ درباره زبان و مخازن کد و … . بخش دیگری هم در کتاب هست که به نظر نمی‌رسد خیلی‌ها آن را خوانده باشند. درباره‌ی طراحی راهبردی و طراحی زمخت‌تر است. اساساً او می‌گوید اولاً نمی‌توانید یک سطح از کیفیت در تمام بخش‌های سامانه داشته باشید. اگر به آن فکر کنید در واقع کاملاً واضح است. چون توسعه‌دهندگان خوب و بد در تیم‌تان دارید. حتی اگر تیم خیلی خوبی داشته باشید باز هم توسعه‌دهندگان بهتر و بدتری خواهید داشت. بنابراین چون افراد متفاوتی در تیم دارید نمی‌توانید کیفیت یکسانی در تمام سامانه داشته باشید. چه کار می‌شود کرد؟ می‌توانید این‌که کدام بخش‌ها کیفیت بهتری داشته باشند را به شانس بسپارید یا این‌که درباره‌ی آن تصمیم آگاهانه‌ای بگیرید. یک راه برای روبرو شدن با بدهی فنی این است که بپرسید چه بخش‌هایی از سامانه واقعاً در تغییرپذیری اهمیت دارند؟ این اطلاعات را می‌شود در داده‌های تاریخی پیدا کرد، مثلاً این‌که تغییرات اخیر در کدام قسمت‌ها بوده است. یا می‌توانید از منظر کسب و کار به آن بنگرید،‌ در کدام بخش‌ها اگر تغییرات سریع‌تری داشته باشیم به ما مزیت رقابتی می‌دهد؟ مثلاً نحوه‌ی ترابری مهم است و در این مورد بخشی از سامانه که کار ترابری را انجام می‌دهد باید دارای کیفیت داخلی بالایی باشد. اریک ایوانز در کتابش تعداد کمی الگو دارد که در این رابطه صحبت می‌کنند. او می‌گوید می‌توانید یک زمینه‌ی کران‌دار (Bounded Context) داشته باشید که در آن یک مدل حوزه‌ی خاص معتبر است. می‌توانید میان زمینه‌های کران‌دار یک لایه ضد فساد داشته باشید. اگر همان سامانه‌ی ترابری را در نظر بگیریم و فرض کنیم یک مدل حوزه‌ی خوب در آن دارید که خیلی پیشرفته است و کد آن کیفیت بالایی دارد و بخش دیگری هم در سامانه هست که مثلاً با مشتریان سر و کار دارد و نرم‌افزاری عادی است که کیفیت پایینی دارد و مدل حوزه‌ی خیلی زشتی دارد. برای این‌که مطمئن شوید که این مدل حوزه‌ی زشت به سامانه‌ی ارزشمند ترابری شما نشت نمی‌کند، بهتر است یک لایه‌ی ضد فساد داشته باشید که این دو مدل را از هم جدا می‌کند و تفسیر بین آن‌ها را انجام می‌دهد. او در این مورد سلول‌ها را مثال می‌زند؛ مثل موجودات که از سلول‌ها ساخته شده‌اند، سامانه‌ی شما هم از تعدادی زمینه‌ی کران‌دار متفاوت تشکیل شده است. هر سلول غشائی دارد که مثل لایه‌ی ضد فساد است. [این غشاء] اطمینان حاصل می‌کند مشکلات خارجی به سلول (زمینه‌ی کران‌دار) نشت نمی‌کنند و آن‌ها به وضوح از هم جدا هستند. می‌توانید سلول‌ها (زمینه‌های کران‌دار) را با کیفیت بالایی داشته باشید و اگر مشکل کیفیت داشته باشید، در کد پخش نخواهد شد. این راه مناسبی برای توسعه‌ی راهبردی کیفیت در بدهی فنی است. تصمیم می‌گیرید کدام بخش‌ها مهم هستند، از آن‌ها مراقبت می‌کنید و بهترین توسعه‌دهندگان‌تان روی آن کار می‌کنند. کیفیت آن را از نزدیک پایش می‌کنید و ... بخش‌های دیگری هم هستند که ممکن است برای آن‌ها حتی از نرم‌افزارهای متداول، نرم‌افزارهایی که خریده‌اید یا از سامانه‌های میراثی خود (Legacy Systems) یا هر چیز دیگر استفاده کنید. فکر می‌کنم این راه جالبی برای توسعه‌ی راهبردی کیفیت یک سامانه‌ی نسبتاً پیچیده باشد.البته یک سؤال این است که اصلاً چرا بدهی فنی داریم؟ آیا نمی‌شود از همان ابتدا یک نرم‌افزار بی‌نقص داشته باشیم؟ فکر می‌کنم تقریباً هر توسعه‌دهنده‌ای بخواهد کار عالی ارائه دهد. فکر نکنم نگرش کسی این باشد که کار کم کیفیت ارائه دهد. منظورم این است که همه‌ی ما می‌خواهیم کارهای خوب انجام دهیم. [پس] چرا کار کم کیفیت ارائه می‌دهیم در حالی که می‌خواهیم کار با کیفیت ارائه دهیم؟ چند دلیل برای آن وجود دارد. واضح‌ترین دلیل برای اکثر ما توسعه‌دهندگان فشار زمانی است. ما می‌خواهیم که کار خیلی خوبی انجام دهیم، اما زمان نداریم. باید انتشار دهیم و ضرب‌العجل داریم. بنابراین برای این که سریع‌تر باشیم کیفیت را قربانی می‌کنیم. تست کردن را از قلم می‌اندازیم، یا فقط تست‌های خودکار را. به طراحی خوب به طرز عمیقی فکر نمی‌کنیم. در اکثر مواقع این منجر به کیفیت نامطلوب می‌شود. نکته‌ی دیگر این است که ما داریم آگاهی از نحوه‌ی انجام کار را از دست می‌دهیم. اگر از یک فناوری جدید برای نخستین بار استفاده می‌کنیم و از آن درک کمی داریم، به ناچار از آن به طرز اشتباهی استفاده خواهیم کرد حتی اگر نیت‌مان خیر باشد. همچنین اگر حوزه‌ی کسب و کار را خیلی خوب نشناسیم منجر به طراحی‌های عجیب می‌شود. چیزی هم مثل پوسیدگی نرم‌افزار وجود دارد. اگر یک نرم‌افزار عالی داشته باشیم مثلاً EJB 2.0 که شاید ۱۵ سال پیش خوب بود. اما الان کمی تاریخ مصرف گذشته است.فکر می‌کنم یک مطالعه‌ی برآوردی جالب در دانشگاه Turku بود که از افراد در فنلاند پرسیدند بدهی فنی شما از کجا سرچشمه می‌گیرد؟ خیلی جالب بود. چون نگفتند فشار زمانی. همچنین نگفتند که فناوری را نمی‌شناختیم. آن‌ها گفتند نیازمندی‌ها را درک نکردیم‌یا اساساً فهم درستی از حوزه‌ی کسب و کار نداشتیم بنابراین بدهی فنی از نیازمندی‌های درک نشده نشأت می‌گیرند. البته آن‌ها این‌ را هم گفتند که معماری بدی داشتیم، یا معماری [به خوبی] انتقال داده نشده بود. این‌ها دلایل اصلی بدهی فنی برای آن‌ها بود.در واقع این خیلی جالب است. چون در مقطعی من هم تصور می‌کردم که معماری است که منبع اصلی بدهی فنی است. اما یک زمان از خود پرسیدم چه چیزی است که تغییر نرم‌افزار را دشوار می‌کند؟ پاسخی که به آن دادم تست‌ها بودند. اگر من حق انتخاب بین سامانه‌ای که معماری بدی دارد ولی تست‌های زیادی دارد و سامانه‌ای که یک معماری عالی دارد ولی هیچ تستی ندارد، سامانه‌ای که من برای تغییر انتخاب می‌کنم آنی است که معماری بدی دارد ولی تست دارد. این هم یکی از جاهایی است که من خیلی مطمئن نیستم بدهی فنی را چطور تعریف کنم و فقط حول آن صحبت می‌کنم. کیفیت کد و معماری در اینجا اجزای سنتی هستند.بله. نمی‌دانم. اخیراً از فیلیپه کوچتن مبدع RUP شنیدم که درباره‌ی آن صحبت می‌کرد. او برای بسیاری کارهای معماری شناخته شده است. او گفت حتی اگر تعداد زیادی موارد تست (Test Case) داشته اما معماری بدی داشته باشید، نمی‌توانید فرض کنید که می‌توانید کیفیت بهتر را با پیرایش کردن (Refactor) در سامانه وارد کنید. چون اگر معماری اشتباه باشد، مثلاً سبک اشتباهی را انتخاب کرده باشید، پیرایش کردن به شما کمکی نمی‌کند. واقعاً باید سامانه را از نو بنا کنید. در واقع من نمی‌دانم، سؤال خوبی است: کدام بدتر است؟ معماری بد با موارد تست یا معماری بهتر بدون موارد تست؟این یکی از چیزهایی است که می‌توانید در مورد آن به تفصیل بحث کنید. در ارتباط با منشأ بدهی فنی، مدل دیگری هم هست که مارتین فاولر آن را معرفی کرده است. واضح است که او برای چیزهای زیادی در صنعت ما شناخته شده است. او بدهی فنی را در چهار ربع‌دایره تقسیم کرد. این ربع‌دایره‌ها بر اساس این‌که بدهی فنی، به طرزی غیرمسئولانه یا معقول تحمیل شده است، از هم جدا می‌شوند. اساساً سؤال این است که به اندازه‌ی کافی زمان برای فکر کردن به بدهی فنی وجود داشت؟ آیا صرفاً [تصمیمی] غیرمسئولانه بود و افراد تحت فشار زیادی بودند یا این‌که معقولانه بود؟ حتی در مواردی که زمان زیادی داشته باشید هم -همان‌طور که کمی بعد خواهیم دید- می‌توانید بدهی فنی داشته باشید. و [سؤال دیگر این‌که] آیا عمدی بود یا غیرعمدی؟ این‌که آیا تصمیمی آگاهانه بود که افراد گفتند ما بدهی فنی را می‌پذیریم و کار را انجام می‌دهیم یا این‌که به نحوی [خود به خود] اتفاق افتاد؟ ما زمان برای طراحی نداریم بنابراین به هر نحوی شده آن را انجام می‌دهیم. سرانجام سامانه‌ای به جای می‌ماند که بد طراحی شده است. اما شما می‌دانستید با این شرایط مواجه خواهید شد؛ بنابراین، این تصمیمی آگاهانه بود. اما اگر این تصمیم گرفته شد چون زمان کافی وجود نداشت، غیرمسئولانه‌ی عامدانه است. در مقابل، [تصمیم] معقول عامدانه یعنی این‌که الان باید انتشار دهیم و با پیامدهای آن مواجه شویم. بنابراین هر چند زمان کافی وجود داشت، باز هم این کار را کردیم و تصمیمی عامدانه بود، می‌دانستیم به لحاظ فنی بدهکار خواهیم شد و این کار را انجام دادیم. بدهی غیرمسئولانه‌ی غیرعمدی [چیزی مثل این است:] لایه بندی یعنی چه؟! واضح است که [این نوع بدهی فنی] چیزی است که در آن شما وقت کافی برای فکر کردن به تصمیم و عواقب آن صرف نمی‌کنید. تصمیم‌تان آگاهانه نبود چون حتی نمی‌دانستید که این یک مشکل است، شما اصلاً لایه بندی را نمی‌شناختید و در نتیجه یک سامانه‌ی بدون لایه‌بندی و شلوغ دارید. چون در واقع خیلی به آن فکر نکردید. بدهی عاقلانه‌ی غیرعامدانه این است که سامانه‌ای دارید و در بازنگری متوجه می‌شوید باید آن را به شکل دیگری می‌ساختید. معماری‌ای که استفاده کردید در زمانی خود مناسب بود اما بعداً در حین پیاده‌سازی به طراحی کاملاً متفاوتی درباره‌ی سامانه رسیدید که بهتر بود. در بازنگری روشن می‌شود که بدهی فنی زیادی دارید و مسئله این است که این فکر قبلاً به ذهن شما نرسیده بود. بنابراین زمان کافی داشتید و تصمیم عاقلانه بود اما در عین حال غیرعمدی هم بود چون نحوه‌ی عملکرد و واقعیت‌های معماری در آن زمان واضح نبود.چیزی که فکر می‌کنم در این مورد خیلی جالب است این است که در ابتدای بحث در مورد تعریف بدهی فنی صحبت می‌کردیم؛ در این مورد که بدهی فنی را متحمل می‌شویم تا سریع‌تر انتشار دهیم. بنابراین این تصمیمی آگاهانه است. بنابراین تعریف اصلی بدهی فنی می‌گوید که تصمیمی آگاهانه است. بدهکار می‌شویم و در عوض برای مدتی سریع‌تر انتشار می‌دهیم و بعداً بدهی را تسویه می‌کنیم. چیزی که فکر می‌کنم در مورد مدل ربع‌دایره‌های مارتین فاولر جالب است -اگر کمی در آن دقیق‌تر شوید- این است که او می‌گوید این همیشه درست نیست. برخی مواقع برای شما واضح است که باید کار را به نحو دیگری انجام می‌دادید، چون در بازنگری وقتی به مسئله و نحوه‌ی حل مسئله‌تان، و نتیجه‌ی کار بنگرید، همه چیز واضح است. همچنین من برداشتی متفاوتی از بدهی فنی پیدا می‌کنم چون او می‌گوید غیرمسئولانه است. او نمی‌گوید که زمان کافی نداریم، مسئله صرفاً این است که شما برای پیشبرد کار به حدی تحت فشارید که بدهی فنی انباشت می‌شود. این تصمیمی آگاهانه نیست، این صرفاً اتفاقی است که می‌افتد، چون زمان زیادی تحت فشار هستید. فکر می‌کنم بخش جالب قابل برداشت در اینجا این است که منشأهای متفاوتی برای بدهی فنی وجود دارد و مدل ساده‌ای که می‌گفت ما کیفیت را فدای سرعت می‌کنیم در واقع چیزی نیست که همیشه اتفاق می‌افتد. فکر می‌کنم مسئله‌ای که سوِن مطرح کرد نکته‌ی مهمی است. اگر کار را با سامانه‌ای شروع کنید و از فناوری‌ای نظیر EJB 2.0 استفاده کنید در حالی که نسخه‌ی جدیدتری از EJB وجود دارد یا کتابخانه‌ی دیگری وجود دارد که مورد علاقه‌ی شما است، قطعاً به لحاظ فنی خود را بدهکار کرده‌اید. چون راه‌های راحت‌تری برای انجام کارها وجود دارد و راهی که شما انتخاب کرده‌اید بدهی فنی محسوب می‌شود. [در گذشته] هیچ راهی برای جلوگیری از این بدهی فنی وجود نداشت چون فناوری، جدید و در حال پیشرفت است. بنابراین به نظر این نشانه‌ای است که این تشبیه شکست می‌خورد. البته سؤال بعدی این است داشتن یک سامانه‌ی بدون بدهی واقع‌بینانه است؟ فکر کنم شما بخواهید در این مورد صحبت کنید. درست است سوِن؟دقیقاً. آیا امکان دارد که سامانه‌ای بدون بدهی فنی داشته باشیم؟ منظورم این است که خیلی اوقات به چیزهایی از قبیل «بدهی فنی بس است»، «چطور بدهکار نباشیم، در ۱۰ مرحله»، «چه کنیم تا بدهکار نباشیم؟» و ... بر می‌خورم. فکر می‌کنم دستیابی به سامانه‌ای بدون بدهی غیر ممکن است. فکر می‌کنم باید بپذیریم که بدهی فنی همواره وجود خواهد داشت. حتی اگر سامانه‌ای بدون بدهی وجود داشت، چطور به آن دست می‌یابید؟ احتمالاً باید زمان و پول زیادی صرف کنید که لزوماً به موفقیت پروژه منجر نخواهد شد.در ارائه‌ای که در آمازون و تویتر داشتیم، آن‌ها به شدت موفق بودند در حالی که مقدار زیادی بدهی فنی وجود داشت. بنابراین فکر می‌کنم یکی از چیزهای جالب این است که بدهی فنی به هیچ وجه به موفقیت تجاری محصول گره نخورده است؛ می‌توان پروژه‌ای یا کسب و کاری از لحاظ تجاری موفق داشت که بر اساس نرم‌افزاری پر از مشکل استوار شده است؛ می‌شود بعداً آن را بازنویسی کرد. Extreme Programming این ایده را مطرح کرد که کیفیت را حداکثر قرار دهید و به هیچ وجه آن را فدا نکنید. این ممکن است ایده‌ی خوبی نباشد چون مقادیر زیادی منابع، پول و نیرو صرف بالا نگه‌داشتن کیفیت می‌کنید در حالی که ضرورتی ندارد و ممکن است اصلاً موفقیت تجاری را تحت تأثیر قرار ندهد. چون ممکن است چیزی باشد که کاربر اصلاً آن را نمی‌بیند. بنابراین بدهی فنی ممکن است بهترین تشبیه نباشد. سؤال همچنان این است که چرا به آن اهمیت می‌دهیم؟ چون در دراز مدت ممکن است بهره‌وری را تحت تأثیر قرار دهد و بدهی فنی صرفاً چیزی است که برای بهبود انتقال مطلب از آن استفاده می‌کنیم. ممکن است بهترین تشبیه نباشد، چون می‌توانید بگویید سیستم بدون بدهی غیر ممکن است و یا می‌توانید بگویید در بسیاری موارد حتی تصمیم آگاهانه‌ای در مورد بدهکار شدن وجود ندارد مثلاً در برخی موارد به علت فناوری جدید است که بدهی فنی رخ می‌دهد و نمی‌شود کاری در قبال آن کرد. بنابراین این تشبیه تاحدی معیوب است که شاید نیاز باشد به دنبال تشبیه دیگری باشیم. این موضوعی است که فلیکس مولر و من سعی داریم در حین پروژه‌ی کارشناسی ارشد روی آن کار کنیم (در این مقاله راجع به آن صحبت شده است -مترجم). ایده‌ی اصلی این است که اگر نمی‌توانیم از [تشبیه] بدهی فنی استفاده کنیم چون همیشه وجود دارد و چون گاهی تصمیم‌گیری آگاهانه در مورد آن وجود ندارد، پس چرا از تشبیه متفاوتی استفاده نمی‌کنیم؟ تشبیهی که ما پیشنهاد کردیم «بهبود در کیفیت» است. به جای این‌که در مورد بدهی صحبت کنیم...بهبود در کیفیت است یا سرمایه‌گذاری در کیفیت؟نکته‌ی خوبی بود، اساساً بهبود است اما از تشبیهی در دنیای تجاری استفاده می‌کنیم. بنابراین تشبیه مورد استفاده‌ی ما «سرمایه‌گذاری در کیفیت» است. منظور این است که اگر بدهی فنی همواره وجود دارد اگر همواره چیزی مربوط به کیفیت داخلی برای بهبود وجود دارد، چرا به آن در قالب سرمایه‌گذاری فکر نمی‌کنیم؟ ما در کیفیت سرمایه‌گذاری می‌کنیم. کسی را داریم که برای چند روز روی چیزی کار می‌کند، مثلاً تست‌های سامانه را بهبود می‌دهد که پنج روز طول می‌کشد و در قبال آن نتیجه‌ای حاصل می‌شود. مثلاً یک یا دو روز در هر اسپرینت (اشاره به دوره‌های توسعه در متدولوژی Scrum -مترجم) صرفه‌جویی می‌کنیم. این مثل هر سرمایه‌گذاری دیگری است. هدف این است که هزینه کاهش یابد. کاهش هزینه در واقع بهبود بهره‌وری منهای نیرویی است که در بهبود کیفیت سرمایه‌گذاری کردید.آخرین مسئله در این مورد مدل کیفیتی است که به نظر من مشابه آن است. مدلی به نام SQALE وجود دارد که در آن چیزی به نام هزینه‌های مداوا (Remediation Costs) دارند که به معنی نیروی لازم برای برطرف کردن مشکلات کیفیت است و همچنین هزینه‌های مداوا نکردن (Non-remediation Costs) را دارند که نیرویی است اگر مشکلات را برطرف نکنید نیاز دارید. بنابراین اگر پوشش کد بدی داشته باشید، هزینه‌ی مداوا برابر با بهبود پوشش تست‌ها خواهد بود و هزینه‌ی مداوا نکردن، بهره‌وری کم‌تر است چون باید زمانی بیشتری صرف برطرف کردن خطاها و ... کنید. فکر می‌کنم این مسئله‌ی جالبی باشد. فکر می‌کنم در اصل این مربوط به طرز فکر باشد. طرز فکر باید این باشد که اگر در چیزی سرمایه‌گذاری می‌کنم، مثلاً پوشش تست را بهبود می‌دهم، اگر خط‌ لوله‌ی تحویل مستمر را بهبود می‌دهم، یا اگر در کیفیت کد سرمایه‌گذاری می‌کنم، نباید آن را زر اندود کنم. باید کارهایی را انجام دهم که بهره‌وری را بالا نگاه می‌دارند و هزینه‌ی صرف‌شده را پس می‌دهند. اگر به کیفیت به این شکل بنگرید فکر می‌کنید راه مناسبی برای رسیدگی به بدهی فنی و کیفیت داخلی و همچنین انتقال مطلب به تصمیم‌گیرندگان و مدیران باشد.یکی از انتقادهایی که به این مدل هست این است که توسعه‌دهندگان باید همواره کیفیت را بالا نگاه دارند اما فکر می‌کنم هنوز مشکلات بزرگ‌تری هست که باید برطرف شوند و توسعه‌دهنده به تنهایی نمی‌تواند این کار را انجام دهد. آن‌ها باید با [بخش] تولید محصول هماهنگ باشند و چیزهایی از این قبیل. برای مثال اگر بخواهید خط‌لوله‌ی تحویل مستمر (Continuous Delivery Pipeline) داشته باشید چون می‌خواهید سریع به انتشار برسید، این نیروی خیلی زیادی می‌طلبد. این چیزی نیست که توسعه‌دهنده به تنهایی بتواند زیر بار آن برود و برای متقاعد کردن مدیریت برای سرمایه‌گذاری در آن، تشبیهی مثل سرمایه‌گذاری در کیفیت نیاز است که می‌گوید اگر این خط‌ لوله را داشته باشید کیفیت بهتری خواهیم داشت و خطاهای کمتر و بهره‌وری بیشتری خواهیم داشت. به این شکل، در گفتگویی که با مدیریت دارید به راه‌حل بهتری خواهد رسید. سؤال دیگر این است که چطور می‌توان بدهی فنی را تشخیص داد؟ شما در اینجا نظراتی دارید. درست است؟بله. در حقیقت برخی نظرات افراد دیگر را دزدیده‌ام :) برخی نشانه‌های واضح وجود دارند. مثلاً اگر کد پر از TODO و FixMe هاست این نشان می‌دهد که افراد برای تحویل عملکرد عجله داشتند اما در همین حال بسیاری موارد فرصت بهبود را می‌دیدند. یا اگر می‌خواهید کدی را تغییر دهید و توسعه‌دهنده می‌گوید: «من نمی‌توانم این کد را تغییر دهم چون این کد فلانی است!» شما به دردسر بزرگی افتاده‌اید. چون این بدین معنی است که شما خواستید که سریع پیش بروید و تنها یک توسعه‌دهنده همه چیز را در ذهنش دارد و آن را به اشتراک نگذاشته است و یک جزیره دانش شکل گرفته است. اگر آن توسعه‌دهنده با اتوبوسی تصادف کند دیگر هیچ کس نمی‌تواند چیزی را در کد تغییر دهد. اگر بخشی از کد فقط توسط افراد خاصی قابل تغییر باشد نشان‌دهنده‌ی این است که یک بدهی بزرگ فنی وجود دارد. همچنین اگر در راهروها می‌شنوید که بله ما هم عملکرد مشابه را داریم اینجا و آنجا داریم، پس بیایید کد را کپی کنیم و برخی قسمت‌های آن را تغییر دهیم. ممکن است بتوانید این کار را یکی دو بار انجام دهید اما اگر زیادی این کار را انجام دهید مخزن کدتان کاملاً غیر قابل نگه‌داری خواهد شد و تبدیل به یک کد اسپاگتی می‌شود. نشانه‌ی دیگر این است که توسعه‌دهنده‌ای می‌گوید: «دوست ندارم به این کد دست بزنم چون مطمئن نیستم اگر این کار را بکنم کلی چیز خراب نشود». این بدین معنی است که طراحی خیلی بدی دارید و نمی‌توانید تغییرات محلی برای نیازمندی‌های محلی انجام دهید چون همه چیز به نوعی به هم گره خورده است. شما در خطر هستید و در پیاده‌سازی نیازمندی‌های جدید خیلی کند عمل می‌کنید و رفع یک خطا، خطاهای دیگری را ایجاد می‌کند. تنها راه جلوگیری از آن تست گسترده است. نشانه‌ی دیگر در تیم‌های اسکرام است. آن‌ها [مفهومی به نام] سرعت (Velocity) دارند. اگر سرعت تیم مدام کاهش پیدا کند در حالی که تیم پایدار است باید از خود بپرسید چرا سرعت در حال کاهش است؟ در اکثر مواقع این به خاطر بدهی فنی است. و نکته‌ی دیگری هم که قبلاً گفتیم این است که نرم‌افزار پیر می‌شود: کتابخانه‌های قدیمی، JDK های قدیمی یا هر چیز قدیمی دیگر. اگر یک سیستم با طراحی بی‌نقص داشته باشید، ده سال دیگر به همان بی‌نقصی نخواهد بود. باید کتابخانه‌های آن را به‌روزرسانی کنید و ارتقاء دهید تا نیازمندی‌های جدید را برآورده کند و بتوان موفق بود. همچنین به نظر من بد است که بشنوید: «می‌توانیم این خطای مهم را رفع کنیم و فقط یک خط است یکی دو هفته طول می‌کشد تا منتشر شود». آن‌چه که واقعاً می‌خواهید این است که وقتی خطایی را برطرف می‌کند ده دقیقه یا یک ساعت بعد بتوانید نسخه‌ی جدید را انتشار دهید. اما اگر چرخه‌ای دو سه هفته‌ای دارید که بخش کوچکی از کد را تغییر دهید و آن را انتشار دهید، مشکل دارید. [مسئله دیگری که] خیلی مهم نیست اما جالب است این است که تست‌های کندی دارید که واضح است زمان می‌گیرد. اگر سیاستی دارید که می‌گوید حتماً باید تمامی تست‌ها را اجرا کنید قبل از این که کد خود را ثبت کنید -که به نظر من هر پروژه‌ای باید این سیاست را داشته باشد- خیلی فرق می‌کند که مجبور باشید یک دقیق صبر کنید، یا ده دقیقه، یا بیست دقیقه. تعدادی نشانه‌ی دیگر هم هست که شاید شما بخواهید در موردش صحبت کنید. مثل SonarQube یا Structure101اگر بخواهید به کیفیت کد نگاه کنید، SonarQube ابزار خوبی برای تحلیل کد است که کارهای متفاوتی انجام می‌دهد. تحلیل ایستای کد انجام می‌دهد، پوشش کد تست‌ها را بررسی می‌کند و خیلی کارهای دیگر. نکته‌ی جالب درباره‌ی آن این است که ابزارهای زیادی را ادغام می‌کند و به شما گزارش خوبی از میزان خوبی کدتان می‌دهد. اطلاعات تاریخی در اختیارتان می‌گذارد تا بفهمید که در حال بهبود هستید یا خیر. ابزارهای دیگر هم مثل Structure101 وجود دارند که من دوست‌شان دارم. همین‌طور Sonargraph که به شما اجازه می‌دهد معماری کدتان را تحلیل کنید. فقط کدتان را به آن می‌دهید -گاهاً کد کامپایل شده- و سپس می‌توانید معماری را ببینید، این‌که چقدر خوب است، چقدر وابستگی دارد، چقدر پیچیدگی دارد و می‌توانید بر اساس آن واکنش نشان دهید. این‌ها ابزارهایی هستند که می‌توانید از آن استفاده کنید. باز هم من فکر می‌کنم که مهم‌ترین چیز این است که کدی داشته باشیم که به سهولت قابل تست باشد. و اگر می‌خواهید بدهی فنی را تشخیص دهید، چیزی که باید به آن فکر کنید این است که چه چیزی بیشترین تأثیر را بر قابلیت نگه‌داری دارد؟ چه چیزی بیشترین تأثیر را بر تغییرپذیری دارد؟ چطور می‌توانم این‌ها را بهبود دهم؟ و این [مسائل] لزوماً وابسته به کد نیست. ممکن است مربوط به تست‌ها باشد، به خاطر پوشش پایین تست‌ها، تغییر آن سخت است چون نمی‌توانید از تغییرات‌تان مطمئن باشید. ممکن است چیزی را خراب کرده باشید و تا زمان انتشار متوجه آن نشوید. یا همان‌طور که گفتیم اگر استقرار یا تست‌های کندی داشته باشید، تغییرات کم‌تری می‌توانید در کد اعمال کنید چون قرار دادن آن تغییرات در محصول زمان زیادی می‌گیرد.ما در مورد شناسایی بدهی فنی صحبت کردیم. حالا سؤال این است که در قبال آن چه کار می‌توانیم انجام دهیم؟ فکر می‌کنم موضوع جالبی باشد. یکی از راه‌هایی که می‌توانید با بدهی فنی روبرو شوید این است که یک فعالیت حائل (‌Buffer Task) در هر دوره‌ی انتشار ایجاد کنید. مثلاً می‌گویید ده درصد از زمان را به تیم اختصاص دهیم تا روی مسائل فنی کار کند. چیزهایی که آن‌ها فکر می‌کنند باعث بهبود می‌شود. حتی می‌توانید مقدار بیشتری از بودجه‌تان را صرف بدهی فنی کنید. می‌توانید انتشار فنی (Technical Release) داشته باشید که صرفاً در آن کد را بهبود داده‌اید. این به این معنی است که نیروی صرف شده برای بدهی فنی به صورت متوازن پخش نشده است-مانند آن‌چه که در فعالیت حائل داشتیم که ده درصد هر اسپرینت را می‌گرفت، در اینجا یک اسپرینت کامل از هر دو یا سه اسپرینت است. ممکن است یک انباره‌ی فنی (Technical Backlog) (اشاره به انباره‌ی نیازمندی‌ها در Scrum -مترجم) از چیزهایی که باید بهبود داده شوند، داشته باشید. راه دیگر این است که اگر برای ویژگی‌های کسب و کار، یک وظیفه (Task) یا داستان کاربری (User Story) داریم در همان حال می‌توانیم بخشی از نیرو را در رسیدگی به بدهی فنی سرمایه‌گذاری کنیم. اساساً هدف این است که وقتی داستان جدیدی داریم و مثلاً می‌خواهیم فرایند ثبت‌نام را تغییر دهیم، در حین انجام تغییرات، کیفیت را بهبود دهیم به نحوی که پیاده‌سازی فرایند ثبت نام آسان‌تر شود. به این طریق بودجه‌ی بهبود کیفیت را در بخش‌هایی صرف می‌کنیم که تغییرات در آن‌ها انجام می‌شود. این چیزی است که بر هر مورد کاربرد تأثیر می‌گذارد و مدیریت می‌تواند در مورد آن تصمیم بگیرد. او می‌تواند بگوید من این داستان را نمی‌خواهم چون خیلی گران است، چون کیفیت خیلی پایین است و از این طریق به مدیر اجازه می‌دهید این‌گونه تصمیمات را بگیرد.دست آخر، کیفیت و بهبود آن باید یک تصمیم کسب و کار باشد. چون مربوط به اولویت‌بندی کیفیت و ویژگی‌هاست. همان‌طور که گفتیم این مسئله خیلی مهمی است. اگر کیفیت را بهبود دهید، در دراز مدت مفید خواهد بود، هرچند اگر واقعاً می‌خواهید یک ویژگی [زودتر] به اتمام برسد چون در غیر این‌صورت فرصت کسب و کار از دست می‌رود یا عواقب دیگری در کسب و کار دارد، دیگر کیفیت اهمیت پیدا نمی‌کند. بنابراین این سؤال که آیا باید در کیفیت سرمایه‌گذاری کنید یا نه باید یک تصمیم کسب و کاری باشد. مشکل این است که اگر ده درصد از زمان تیم را برای رسیدگی به کیفیت اختصاص دهید یا این‌که انتشار برخی نسخه‌ها را برای رسیدگی به کیفیت در نظر بگیرید دیگر یک تصمیم کسب و کار نیست در حالی که باید این‌طور باشد. فکر می‌کنم بخشی از مشکل رسیدگی به بدهی فنی، قادر ساختن کسب و کار به تصمیم‌گیری در مورد بخش‌هایی است که باید کیفیت بالاتری داشته باشند و سپس در آن سرمایه‌گذاری کنند. واضح است که این اشتباه است که تیم تصمیم‌گیری کند. ممکن است نتوانند این کار را انجام دهند یا ممکن است نتوانند بهترین تصمیم‌ها را بگیرند چون تصویر کلی را ندارند. فکر می‌کنم این علتی است که همراه کردن کسب و کار یکی از سخت‌ترین بخش‌هاست. ارتباط با مدیریت هم در قلب مسئله تشبیه بدهی فنی است، در واقع به همین دلیل، این تشبیه به کار برده شد. تا حدی هم مربوط به اعتماد است. اگر توسعه‌دهندگان بدانند چطور به کیفیت رسیدگی کنند و چطور آن را بالا نگاه دارند، می‌توان به آن‌ها اجازه داد که این تصمیم‌گیری‌ها را انجام دهند. در غیر این‌صورت باید نوعی تصمیم‌گیری کنید و بخواهید که برای سرمایه‌گذاری در کیفیت بودجه صرف شود و این می‌تواند خیلی سخت باشد. بنابراین فکر می‌کنم مربوط به اعتماد باشد. اما همچنین مربوط به سرمایه‌گذاری در جایی است که می‌توانید از آن نتیجه بگیرید و این چیزی است که کسب و کار باید از آن اطلاع داشته باشد و به آن فکر کند.بله. فکر می‌کنم اعتماد نکته‌ی مهمی است چون اغلب مواردی هست که توسعه‌دهندگان شکایت زیادی از کیفیت بد و چارچوب‌های بد دارند و می‌گویند باید این را بهبود دهیم، باید این چارچوب را عوض کنیم و ... حرفشان توسط مدیر شنیده می‌شود ولی مدیر می‌گوید این خیلی مهم نیست. اما اگر یک توسعه‌دهنده‌ی خیلی خوب داشته باشید که کسب و کار را بشناسد و این را ثابت کرده باشد و وقتی او می‌گوید: «باید مشکل آن‌ها را حل کنیم چون با این کد به جایی نمی‌رسیم، باید آن را پاک‌سازی کنیم» اگر افراد حوزه‌ی کسب و کار به این فرد یا گروه اعتماد داشته باشند آن وقت است که می‌توانیم ادامه دهیم. اگر مدیران به این افراد اعتماد داشته باشند می‌گویند: «اگر فلانی و بهمانی می‌گویند، پس مهم است و باید این کار را بکنیم. آن‌ها کسب و کار را به طور کلی می‌شناسند؛ شاید باید به آن‌ها گوش دهیم و به آن‌ها اجازه دهیم تصمیم بگیرند.»تا حدودی چیزی که می‌گویی درست است اما از سوی دیگر افراد حوزه‌ی کسب و کار تنها کسانی هستند که می‌توانند بگویند آیا سرمایه‌گذاری در کیفیت در حال حاضر امکان دارد یا خیر. چون ممکن است نیاز داشته باشند تعدادی ویژگی را منتشر کنند و همچنین همان‌طور که گفتیم بدهی فنی وابستگی زیادی به این دارد که کدام بخش‌های سیستم در آینده تغییر خواهند کرد و این چیزی است که توسعه‌دهندگان تا حدی می‌توانند از آن اطلاع داشته باشند. آن‌ها می‌دانند در چند نسخه‌ی بعدی چه خواهد شد اما بینش راهبردی بلند مدت چیزی است که کسب و کار باید به آن برسد. به همین علت است که من اعتقاد دارم مسئله فقط انتقال مسئولیت به توسعه‌دهندگان نیست و باید توسط توسعه‌دهندگان و حوزه‌ی کسب و کار باشد. چون هر کدام بخشی از اطلاعات را دارند پس باید در کنار هم قرار دهند تا به نتیجه برسند و بفهمند که باید کجا، کی و چطور در کیفیت سرمایه‌گذاری کنند.منظور من این بود که توسعه‌دهندگانی هستند که در حوزه‌ی مسئله خبره هستند و به نوعی راهبرد کسب و کار را می‌شناسند و این‌که سامانه به کجا رهنمون است. اگر افراد حوزه‌ی کسب و کار به این توسعه‌دهندگان اعتماد داشته باشند که می‌گویند باید در کیفیت سرمایه‌گذاری کنیم معمولاً حرفشان شنیده می‌شود. اما اگر کسب و کار را نفهمید خیلی دشوار است که این اعتمادسازی را انجام دهید.بله درست است. اگر چنین توسعه‌دهندگانی در تیم داشته باشید خیلی خوش‌شانس هستید. اما این مسئله همچنین انتظارات را از توسعه‌دهندگان تا حدی افزایش می‌دهد که من مطمئن نیستم خیلی‌ها بتوانند این کار را انجام دهند. چون شما فقط به دنبال افراد فنی خوب نیستید، بلکه کسانی که در مورد کسب و کار هم اطلاع دارند و یک فرد فنی خوب بودن به خودیِ خود به اندازه‌ی کافی دشوار است. اگر قرار باشد در مورد کسب و کار هم بدانید واقعاً سخت خواهد شد. برای همین است که من فکر می‌کنم در برخی موارد باید افراد حوزه‌ی کسب و کار و تیم فنی با هم در این مورد کار کنند که به همین علت خیلی سخت است.فکر می‌کنم یک نکته‌ی مهم دیگر باقی مانده باشد. این سؤالی است که فرانک بوشمان چندی پیش مطرح کرد. فرانک بوشمان بیشتر به خاطر کتاب معماری نرم‌افزار مبتنی بر الگو شناخته شده است. او می‌پرسد: بدهی فنی را باید تسویه کرد یا نه؟ به نظر من این مقاله خیلی جالب بود ولی متأسفانه به صورت رایگان در دسترس نیست و باید آن را از IEEE خریداری کنید. اما او می‌گوید: ما همواری بدهی فنی داریم؛ غیرقابل پیش‌گیری است. چطور با آن مواجه شویم؟ یعنی آیا آن را تسویه می‌کنیم یا نه؟ او سه پاسخ به این سؤال می‌دهد. حالت اول پرداخت بدهی است (Debt-free Payment). ما یک قطعه کد یا مؤلفه‌ی بد در سامانه داریم و تصمیم می‌گیریم کاملاً آن را Refactor کنیم یا ممکن است آن را جایگزین کنیم،‌ آن را دور بریزیم و از نو بسازیم یا به یک طراحی پایدار و خوب پیرایش کنیم. فقط زمانی باید این کار را بکنید که کد واقعاً بد است و شما می‌دانید که باید بر اساس آن در آینده به دفعات عملکردهای جدیدی بسازید. حالت دومی که پیشنهاد می‌کند تبدیل بدهی است. شما مؤلفه‌ای یا بخش از سامانه را دارید که بدهی فنی زیادی دارد اما جایگزینی آن راه‌حل عملی نیست. مثلاً یک برنامه‌ی میراثی سی ساله دارید که نمی‌توانید آن را دور بریزید، چون خیلی گران است، یا ریسک زیادی دارد اما می‌توانید بدهی را تبدیل کنید. یعنی سامانه را به چیزی بهتر اما نه بی‌نقص تبدیل کنید. این راه‌حل بهتر و نه بی‌نقص، نرخ بهره‌ی پایین‌تری دارد. بنابراین هنوز هم بی‌عیب نیست، هنوز هم باید برای توسعه‌ی آن هزینه کرد، اما خیلی خیلی بهتر از سامانه‌ی قبلی است و ما استطاعت ساختن راه‌حل بی‌نقص را نداریم چون زیادی گران است و زیادی ریسک دارد. و آخرین حالت که آن را زیاد می‌شنوم و فکر می‌کنم نکته‌ی درستی باشد این است که با آن کنار بیاییم و بهره‌ی آن را بپردازیم. می‌دانیم که کد خوبی نیست، اما آن را تحمل می‌کنیم. چون هر چند خیلی خوب نیست ولی نباید زمانی زیادی را هدر دهیم و هزینه‌ی پیرایش کد نامطلوب به کد بهتر از تحمل کردن آن بیشتر است. فکر می‌کنم این چیزی است که باید همیشه در ذهن داشته باشیم. آیا باید آن را بهبود دهیم؟ یا این‌که هزینه‌ی آن از تحمل کردن آن بیشتر است؟ فکر می‌کنم این مشارکت خیلی خوبی بود. فکر می‌کنم این همه چیز باشد. درست است؟بله، سوِن. خیلی ممنونم که وقت گذاشتی و با من در مورد بدهی فنی صحبت کردی. سید مرتضی هاشمی سید مرتضی هاشمی Thu, 28 Oct 2021 20:32:33 +0330 https://virgool.io/@atomerz/study-v59y3rxiizbn مطالعه، فقط خواندن کتاب نیست. محتوا که ارزش‌مند باشد خواندن یک مطلب روی اینترنت، گوش دادن به یک پادکست، تماشای یک مستند تلویزیونی، دیدن یک فیلم، یا شرکت در یک گفت‌وگو هم می‌تواند در دایره‌ی مطالعه قرار گیرد. اما محتوای ارزش‌مند چیست؟ چطور آن را پیدا کنیم؟ و چطور به مطالعه عادت کنیم؟خوراک ذهنوقتی گرسنه می‌شویم بدن ما نیاز به غذا دارد. خوردن یک تکه شکلات یا یک بستنی هم می‌تواند حس گرسنگی را برطرف کند. اما اگر به این کار ادامه دهیم مواد غذایی مورد نیاز بدن تأمین نمی‌شود؛ بیمار می‌شویم و آسیب می‌بینیم. گرسنگی هشدار بدن ماست برای اعلام نیاز به موادی که برای ادامه‌ی حیات به آن احتیاج داریم.بدن به مواد گوناگونی برای ادامه‌ی فعالیت خود احتیاج دارد اما به صورت تفکیک شده کمبود هر ماده را اعلام نمی‌کند. همه‌ی کمبودها به صورت حس گرسنگی بروز پیدا می‌کنند. علاوه بر این، حس گرسنگی نتیجه‌ی اندازه‌گیری موجودی تمام مواد مغذی مورد نیاز بدن نیست. وقتی گرسنه می‌شویم که میزان قند خون کاهش پیدا کند یا معده خالی باشد یا مواردی از این دست. این‌ها پوشش کاملی از نیازهای غذایی بدن نیست. در نتیجه وقتی بعد از خوردن، میزان قند خون افزایش پیدا کند یا معده پر شود حس گرسنگی هم از بین خواهد رفت. این لزوماً به معنی برآورده شدن نیازهای غذایی بدن نیست.اگر نیاز واقعی برآورده نشود به شکل بیماری بروز پیدا می‌کند. بیماری نه تنها هشدار دردآورتری نسبت به حس گرسنگی است بلکه درمان آن هم از برطرف کردن حس گرسنگی سخت‌تر و پر هزینه‌تر است. گاهی حتی درمان‌پذیر نیست و باید با پیامدهای آن زندگی را ادامه داد (یا ادامه نداد!). بنابراین باید مراقب خوراک‌مان باشیم و به محتویات آن دقت کنیم.مطالعه برای ذهن، حکم خوراک برای بدن را دارد. گرسنگی ذهن به شکل احساس حوصله سر رفتن، کسالت، و نیاز به سرگرمی بروز پیدا می‌کند. خوراک آن هم می‌تواند هر چیزی باشد که سلول‌های عصبی آن را مشغول نگه‌دارد؛ خواندن کتاب، تماشای تلویزیون، بازی کردن و ... اگر خوراک مناسبی به ذهن ندهیم نه تنها رشد نمی‌کند بلکه ممکن است آسیب ببیند. نوع خطرناک‌تری از پاسخ به این نیاز این است که به جای مشغول نگه‌داشتن سلول‌ها آن‌ها را خاموش کنیم یا حتی بکشیم؛ این کاری است که مخدرها و روان‌گردان‌ها انجام می‌دهند. بنابراین باید خوراک مناسب ذهن را شناخت، ورودی ذهن را کنترل کرد و در طول زمان از آن مراقبت کرد. اما خوراک کامل چیست؟خوراک ناکامل یا خرده خوراک هر چیزی است که هشدارهای گرسنگی ذهن را به شکلی کاذب خاموش کند. تماشای طولانی مدت تلویزیون، خواندن صفحه‌ی حوادث روزنامه، خواندن خبر، دنبال کردن افراد معروف (به هر شکلی از روزنامه و مجله و فضای مجازی گرفته تا دنبال کردن فیزیکی :)) )، عضو شدن در کانال‌های جوک، افراط در بازی‌های کامپیوتری و ... مثال‌هایی از خرده خوراک هستند. البته هیچ‌کدام از این موارد به خودی خود بد نیستند. دنبال کردن خبر، تماشای تلویزیون، خنده و تفریح همه مواردی هستند که به آن نیاز داریم. نکته این است که این موارد پاسخ کاملی به نیاز گرسنگی ذهن نیستند. این‌ها با مشغول نگه داشتن ذهن، هشدارها را خاموش کرده ولی نیاز واقعی را برطرف نمی‌کنند.خوراک کامل، محتوایی است که ما را رشد می‌دهد، کمک می‌کند بهتر درک کنیم، بهتر رفتار کنیم، و بهتر زندگی کنیم. گفته می‌شود فیلم خوب مثل یک قطار است. قطاری که در یک نقطه سوار آن می‌شوی و وقتی از آن پیاده می‌شوی جای دیگری هستی. محتوای خوب هم چنین خاصیتی دارد، تغییرمان می‌دهد. بعد از مطالعه‌ی آن دیگر آدم سابق نیستیم. دانشی کسب کرده‌ایم که ما را بهتر می‌کند. احساس خوشبختی بیشتری می‌کنیم. بیشتر درک می‌کنیم. بیشتر هم‌دردی می‌کنیم. برای خودمان و دیگران مفیدتر خواهیم بود و بهتر زندگی خواهیم کرد.یکی از ویژگی‌های مهم مطالعه این است که دست‌آوردهای آن در گذر زمان مشخص می‌شوند و عموماً بلافاصله قابل تشخیص نیستند. اثر مطالعه بر ذهن مثل رشد دادن یک درخت است. مثل اثر سایشی جریان یک رود بر سنگ است. کند هست ولی قدرت‌مند است. نتیجه‌اش ماندگار است و ارزشمند.وقتی کتابی چند صد صفحه‌ای می‌خوانیم یعنی مدت زیادی با آن همراه هستیم. گاهی ممکن است بتوانیم مطلبی که یک کتاب منتقل می‌کند را در چند صفحه خلاصه کنیم. اما این چند صفحه آن اثرگذاری را نخواهد داشت. شانه زدن موهای‌تان را در نظر بگیرید. برای این‌که به حالت دلخواه‌تان در بیاید چند بار آن را شانه می‌کنید؟ با هر بار کشیدن شانه موهای شما کمی به حالت دلخواه نزدیک‌تر می‌شود. اثر مطالعه هم همین‌طور است؛ آهسته ولی ماندگار. منظور در این‌جا این نیست که مطلب هر چه طولانی‌تر باشد اثرگذار تر است؛ این‌طور نیست. منظور این است که انتقال مطالب ارزشمند و مهم به شکلی اثرگذار، عموماْ به صورت خلاصه و سریع امکان‌پذیر نیست.بنابراین از مطالعه‌ی یک کتاب بزرگ، یک بلاگ طولانی، یا گوش دادن به یک پادکست یک ساعته دوری نکنید. برعکس جملات قصار، پارگراف‌های قشنگ، کلیپ‌های کوتاه و ... را کم‌تر بخوانید، گوش دهید و ببینید. در پس یک جمله‌ی قصار داستانی است که نخوانده‌ایم و شرایطی هست که نمی‌دانیم. عادت کردن به این خرده خوراک‌ها، حتی اگر اثرگذار باشند، باعث می‌شود طوطی‌وار کاری را انجام دهیم در حالی که آن را عمیق درک نکرده‌ایم. در واقع بیشتر اوقات اثر این جملات یک احساس رضایت لحظه‌ای و فراموشی/بی‌عملی است.اثر منفی دیگر عادت کردن به این خرده خوراک‌ها این است ما را برای مدت کوتاهی سیر می‌کنند. پس از خواندن یک جمله‌ی قصار چه می‌کنیم؟ احتمالاً جمله‌ی دیگری می‌خوانیم، سراغ اخبار می‌رویم، یک کلیپ طنز می‌بینیم. به هر حال سراغ چیز دیگری می‌رویم. یعنی نیاز ما به درستی و در حد کافی برطرف نشد. علاوه بر این وقتی مدام در موضوع‌های متفاوت پرسه می‌زنیم ذهن ما پر از اطلاعات پراکنده‌ی پردازش نشده می‌شود. ذهن ما توانایی پردازش همه‌ی این موارد را در کوتاه مدت ندارد. بنابراین بخش زیادی از آن دور ریخته می‌شود که منجر به همان فراموشی یا بی‌عملی می‌شود. یعنی اثرگذاری اگر صفر نباشد ناچیز است. این اثرگذاری کم گاهی باعث سرخوردگی، کاهش اعتماد به نفس و سستی اراده هم می‌شود. اطلاعات مفید، قشنگ و کاربردی زیادی را در زمان کوتاهی به دست آورده‌ایم اما نتوانسته‌ایم از آن‌ها در عمل استفاده کنیم و بهتر زندگی کنیم.یادگیری و تغییر نیاز به اراده،‌ تمرکز و زمان دارد. زندگی خود را مرور کنید. روی نقاطی که در آن رشد کرده‌اید تمرکز کنید. با چه سرعتی رشد کرده‌اید؟ چقدر زمان صرف کردید؟ از زمانی که با ایده آشنا شدید تا زمانی که اثربخشی آن در زندگی شما آشکار شد چقدر طول کشید؟ روی چند موضوع تمرکز داشته‌اید؟ تحت تأثیر چند نفر بوده‌اید؟ استمرار و پشت‌کار تا چه حد در رشد و اثرگذاری تعیین کننده بود؟تا این‌جا اهمیت مطالعه را مرور کردیم و فرق خوراک کامل و خرده خوراک را دانستیم. قدم بعدی این است که بدانیم چطور اثربخشی مطالعه را بهبود دهیم و آن به یک عادت تبدیل کنیم.اثربخش کردن مطالعهکمی در مورد عوامل بازدارنده و بهبود دهنده‌ی اثرگذاری مطالعه گفتیم. بخشی از این مسأله به نوع محتوا بر می‌گشت. بخش دیگری از آن مربوط به استمرار، پشت‌کار و عادت‌سازی است. گاهی محتوا طوری است که ادامه‌ی راه را نشان نمی‌دهد. گاهی ادامه‌ی راه را نشان می‌دهد اما فقط خوشی‌ها را می‌گوید و از چاله چوله‌های مسیر حرفی نمی‌زند. گاهی اغراق می‌کند و گاهی حتی دروغ می‌گوید. هر مطلبی، از هر نوعی، در هر رسانه‌ای که باشد و نوشته‌ی هر کسی باشد تا حدی این ایرادها را دارد. هیچ چیز و هیچ کس کامل نیست. بنابراین وقتی بعد از خواندن مطلبی بخواهید آن را در زندگی خود به کار بگیرید با موانعی روبرو خواهید شد. برای گذشتن از این موانع و بهبود اثرگذاری مطالعه چه کنیم؟ واضح است که تغییر مسیر و ایجاد بهبود در زندگی کار سخت و پیچیده‌ای است. عوامل زیادی مثل شانس، اراده، اعتماد به نفس و ... در کسب موفقیت و بهبود مؤثرند. بعضی‌ها در کنترل ما و بعضی‌ها خارج از کنترل ما. یکی از مواردی که روی آن کنترل داریم مطالعه است. بنابراین تلاش می‌کنیم به این سوال پاسخ دهیم که چطور مطالعه را به یک عادت تبدیل کنیم؟از کجا شروع کنیم؟اولین مانع در تبدیل مطالعه به یک عادت این است که اصلاً مطالعه نمی‌کنیم. حتی نمی‌دانیم از کجا شروع کنیم. کدام کتاب را بخوانیم؟ چه چیزی گوش دهیم؟ کدام فیلم را ببینیم؟ پاسخ این سوال‌ها برای هر فرد متفاوت و شخصی است اما مسیری که برای پیدا کردن پاسخ طی می‌کنیم مشابه است.کنجکاویکنجکاوی‌هایتان را دنبال کنید. همه‌ی ما با حس کنجکاوی نسبت خودمان، دیگران و دنیای اطراف به دنیا می‌آییم. به مرور زمان ممکن است این حس در ما سرکوب شده و یا کم‌رنگ شده باشد. با مطالعه این حس در ما تقویت می‌شود؛ کنجکاوی‌های جدیدی پیدا می‌کنیم و احساس رضایت پیدا می‌کنیم.ذهن ما مثل مجموعه‌ای از اتاق‌های به هم متصل است. بعضی اتاق‌ها با در به هم وصل هستند و به هم راه دارند. برخی درها باز و برخی بسته‌اند. بعضی اتاق‌ها پنجره دارند و از طریق آن می‌توان منظره‌ی بیرون را دید. اثر مطالعه بر ذهن مثل اثر نور است. وقتی مطلبی می‌خوانیم چراغی در یک اتاق روشن می‌شود. از تاریکی بیرون می‌آییم و تازه متوجه می‌شویم در آن اتاق چه هست و چه نیست. نور این چراغ فقط این اتاق را روشن نمی‌کند. مقداری از آن به اتاق‌های هم‌جوار هم می‌رسد و آن‌جا را هم کمی روشن‌تر می‌کند. گاهی یک کتاب دری که قبلاً بسته بود را باز می‌کند و اتاق جدیدی پیدا می‌کنیم. گاهی وارد اتاقی می‌شویم که پنجره‌ای به دنیای بیرون برای ما باز می‌کند. دنبال کردن هر کنجکاوی به کنجکاوی‌های بیشتری منجر می‌شود.با وجود این‌که حس کنجکاوی ذاتی است ممکن است به مرور زمان آن را از دست داده باشیم یا نسبت به آن آگاهی نداشته باشیم. برای بازیافتن کنجکاوی‌هایمان باید خود را در معرض اطلاعات قرار دهیم. این‌جا جایی است که مواردی که در بخش قبل آن‌ها را نهی کردیم می‌تواند به ما کمک کند. ممکن است جمله‌ی قصاری بخوانید، عنوان خبری را ببینید، یا در حین پرسه زدن در فیس‌بوک یا اینستاگرام چیزی توجه شما را به خود جلب کند. این‌ها مواردی است که احتمالاً در روال فعلی زندگی ما قرار دارد و با آن‌ها می‌توانیم کنجکاوی‌هایمان را پیدا کنیم. هر چند با گذشت زمان می‌توانیم به روش‌های بهتری کنجکاوی‌ها را پیدا کنیم. برای مثال می‌شود افراد یا نهادهای تأثیرگزار (نه صرفاً معروف)، کسانی که حرف یا ایده‌ای برای گفتن دارند را شناخت و دنبال کرد.هدف در این‌جا در معرض اطلاعات مفید قرار گرفتن است. می‌خواهیم کنجکاوی‌هایی که فکر می‌کردیم نداریم را پیدا کنیم. اما باید مراقب باشیم دچار بمباران اطلاعاتی نشویم. میزان ورود اطلاعات را طوری تنظیم کنیم که دچار سردرگمی و سرخوردگی نشویم. به یاد داشته باشیم که ذهن ما توانایی پردازش محدودی دارد. همچنین وقتی یک چیز را یاد می‌گیریم و رشد می‌کنیم که زمان و تمرکز کافی برای آن صرف کنیم. بنابراین باید در بازه‌های زمانی مناسب کنجکاوی‌های خودمان را محدود کنیم.دردممکن است در شرایط بدی قرار داشته باشیم. درگیر مشکلات و دردهایی باشیم که به ما فرصت کافی برای دنبال کردن کنجکاوی‌هایمان ندهد یا انرژی را از ما بگیرد. مشکلات جسمی، روحی، مالی، اجتماعی یا ... در این شرایط نیاز ما به مطالعه اگر بیشتر از قبل نباشد، کم‌ترهم نیست. در این شرایط چیزی که انگیزه یا امکان مطالعه را از ما می‌گیرد شدت مشکلات و درد است. بیشتر اوقات می‌شود اولویت‌ها، زمان‌بندی و شرایط را طوری تغییر داد که این انگیزه یا فرصت را پیدا کنیم. در برخی موارد مثل وقتی در فقر و گرسنگی به سر می‌بریم این امکان را نداریم اما بیشتر موقعیت‌ها و مشکلاتی که ما با آن روبرو هستیم تا این حد بحرانی نیستند.بنابراین خیلی وقت‌ها با یادآوری چند نکته می‌توانیم فرصت و انگیزه‌ی مطالعه را برای خود ایجاد کنیم. اول این‌که مطالعه می‌تواند با هدف پیدا کردن راه‌حلی برای همین مشکلات و دردها باشد. دوم این‌که گاهی اوقات همین که در مورد یک مشکل بیشتر بدانیم خود تسکین است. بنابراین با پرسش‌گری در مورد دردهایی که آزارمان می‌دهند هم تسکین پیدا می‌کنیم و هم ممکن است با گذر زمان راه‌حلی پیدا کنیم.علاقهشاید راحت‌ترین نوع شروع به مطالعه پرداختن به علایق باشد. اگر علاقه‌مندی‌های خودتان را بشناسید، همین شوق و علاقه شما را به دنبال کردن و مطالعه در مورد آن سوق می‌دهد و نیازی به کمک بیشتری ندارید. اگر هم آن را پیدا نکرده باشید یکی از دو مورد قبلی به شما برای پیدا کردن علایق‌تان کمک خواهد کرد. بنابراین در این قسمت به جای پرداختن به مزایای پرداختن به علایق به خطرات محدود شدن به علایق می‌پردازیم.دنبال کردن علایق از جمله لذت بخش‌ترین فعالیت‌هایی است که می‌توانیم انجام دهیم. اما صرف تمام انرژی و وقت برای علایق آسیب‌هایی دارد که توضیح می‌دهیم.اولین ایراد این است که برای بیشتر آدم‌ها دامنه‌ی علایق به نسبت کنجکاوی‌ها و مشکلاتی که دارند بسیار محدودتر است. بنابراین محدود کردن مطالعه به موضوعات مورد علاقه، رشد ما را محدود می‌کند. برای بهتر شدن به مجموعه‌ی متنوعی از مهارت‌ها احتیاج داریم. لزوماً همه‌ی این مهارت‌ها با علایق ما پوشش داده نمی‌شوند. کسی که فقط علایق خود را دنبال می‌کند مثل ورزش‌کاری است که فقط روی یک عضو، مثلاً بازو، تمرکز می‌کند. بازوی ورزشکار رشد خواهد کرد و قوی خواهد شد اما تناسب اندام از دست خواهد رفت. به جز آثاری که این رشد نامتناسب بر زیبایی خواهد داشت ممکن است در برخی موارد حتی آثار بدی روی سلامت جسمی داشته باشد؛ برخی ورزش کردن‌ها از ورزش نکردن بدتر است.علاوه بر این، میزان علاقه‌ی ما به مسائل مختلف یکسان نیست. ممکن است در یک موضوع به حدی علاقه داشته باشیم که موقع پرداختن به آن گذر زمان را هم متوجه نشویم. اما علاقه داشتن یا نداشتن به یک موضوع یک وضعیت دوگانه نیست. گاهی اوقات موضوعی را دوست داریم و گاهی هم از آن خسته می‌شویم. گاهی اوقات به موضوعی علاقه‌مندیم اما فقط وقتی با فرد دیگری دیگری آن را دنبال کنیم. گاهی هم به موضوعی علاقه داریم اما فقط تا زمانی که برای‌مان منفعت داشته باشد. در نتیجه اگر تنها مبنای مطالعه پرداختن به علایق‌مان باشد خیلی زود به خوردن خرده خوراک‌ها برمی‌گردیم.مشکل دیگری که پرداختن انحصاری به علایق ایجاد می‌کند این است که رشد ما حتی در همان حوزه را محدود و کند می‌کند. خیلی از پیش‌رفت‌های بشری نتیجه‌ی ترکیب دانش زمینه‌های مختلف هستند. برای مثال صنعت نرم‌افزار از روال‌ها و آموزه‌های مدیریت خط تولید در کارخانجات چیزهایی زیادی یاد گرفته است. اگر این اتفاق رخ نمی‌داد صنعت نرم‌افزار به ناچار باید چرخ را دوباره اختراع می‌کرد. در موارد دیگر ترکیب دو یا چند حوزه، حوزه‌ی جدیدی ایجاد کرده است. برای مثال، ترکیب رشته‌های برق، کامپیوتر و الکترونیک امکان به وجود آمدن رشته‌ی رباتیک را فراهم آورد. ممکن است مثال‌هایی که زده شد نتیجه‌ی این باشد که یک یا چند نفر به موضوعات اشاره شده علاقه‌مند بوده باشند و در نتیجه‌ی دنبال کردن آن علاقه این پیش‌رفت‌ها ایجاد شده باشد. اما نکته این نیست. نکته این است که اگر ما بخواهیم کنترل را به دست بگیریم و حساب‌شده این اتفاقات را رقم بزنیم، دنبال کردن علایق ما را محدود خواهد کرد. مثل غذایی که با اضافه کردن کمی چاشنی خوشمزه‌تر می‌شود، کمی خارج شدن از حوزه‌ی علایق، دنبال کردن همان علایق را لذت‌بخش‌تر و کارآمدتر می‌کند.عادت به مطالعهمطالعه فقط خواندن نیستشاید اولین چیزی که به ما کمک کند مطالعه را به عادت تبدیل کنیم شناخت خود مطالعه باشد. پیش‌تر در مورد مطالعه به عنوان خوراک ذهن توضیح دادیم و کمی هم در مورد خوراک کامل و مصداق‌های آن گفتیم. این‌جا کمی بیشتر در مورد چیزهایی که می‌تواند به عنوان مطالعه در نظر گرفته شود صحبت می‌کنیم.عادت داریم مطالعه را به معنی خواندن محتوای نوشتاری در نظر بگیریم. خواندن کتاب، روزنامه، مقاله و ... اما اگر مطالعه را هر فعالیتی که جریان مفیدی از اطلاعات را به ذهن روانه کند می‌تواند در نظر بگیریم، بسیاری فعالیت‌های دیگر هم به اندازه‌ی خواندن کتاب و مقاله اثرگذار خواهند بود.در گذشته‌های دور تنها راه انتشار یک مطلب نوشتن یا چاپ کردن آن روی کاغذ بود. به مرور زمان و با پیش‌رفت فناوری، امکان انتشار مطالب به صورت صوت و بعدتر تصویر امکان‌پذیر شد. همچنین تنوع مطالب نوشتاری از کتاب، به روزنامه، مجله، مقاله، اعلامیه و ... افزایش پیدا کرد. در رسانه‌های صوتی و تصویری هم همین تنوع به شکل رادیو، تلویزیون، کاست، ویدیو و ... بروز پیدا کرد. بنابراین محتوای قابل مطالعه که قبلاً فقط به صورت کتاب در دسترس بود به روش‌های متنوع‌تری در دسترس قرار گرفت. معنی کلمه‌ی مطالعه شاید همراه با آن تحول پیدا نکرد و عادت کردیم همان خواندن کتاب و مقاله و نوشتار را مطالعه در نظر بگیریم، در حالی که واقعیت این نیست.اثر دیگر این پیش‌رفت‌ها این بود که هزینه‌ی انتشار مطلب کاهش پیدا کرد و در دسترس افراد بیشتری قرار گرفت. در نتیجه حجم محتوا به شدت افزایش پیدا کرد. همچنین کیفیت مطالبی که منتشر می‌شد هم تحت تأثیر قرار گرفت. شاید قبلاً کسی اقدام به چاپ کردن و انتشار فعالیت‌های عادی روزانه‌ی خود نمی‌کرد اما امروز به خصوص با ظهور شبکه‌های اجتماعی به شدت در معرض این نوع محتوا هستیم.بنابراین چالش امروز ما پیدا کردن مطلب برای مطالعه نیست، بلکه پیدا کردن محتوای مفید است. در این مورد در بخش قبل توضیح دادیم. این‌جا تلاش کردیم به خود یادآوری کنیم که مطالعه فقط خواندن نیست. هر فعالیتی که جریانی از اطلاعات را به سمت ذهن ما هدایت کند مطالعه است. اگر با این تعریف به فعالیت‌های روزانه‌ی خود نگاه کنیم ممکن است خیلی از ما بیشتر از آن‌چه فکر می‌کنیم اهل مطالعه باشیم.هم‌نشینیگاهی اوقات هدف مطالعه نه حل مشکل است و نه یادگیری، صرفاً یک هم‌نشینی است با دیگری. گاهی با خواندن یک کتاب، دیدن یک فیلم، یا گوش دادن به یک سخنرانی چیز جدیدی یاد نمی‌گیریم بلکه صرفاً با نویسنده، گوینده یا کارگردان همراه می‌شویم و لذت می‌بریم.گاهی که در اطرافمان به لحاظ فکری و روحی احساس تنهایی می‌کنیم با مطالعه متوجه می‌شویم کسی در نقطه‌ای دیگر از دنیا یا حتی در عصری دیگر با ما همفکر و هم نظر است، ما را درک می‌کند، داستان ما را روایت می‌کند. این همان حسی است که گاهی با قرار گرفتن در دایره دوستان پیدا می‌کنیم.گاهی نیز که در زندگی خود غرق شده‌ایم با یک قصه، زندگی دیگری را تجربه می‌کنیم، با گروه دیگری همراه می‌شویم. در زمان و مکان دیگری قرار می‌گیریم و چیزهایی را تجربه کنیم که نمی‌توانستیم و نمی‌دانستیم.این تجربیات ممکن است همراه با درک یا احساس همدردی جدیدی باشد یا نباشد. آن‌چه این‌جا اهمیت دارد این است که با فرد یا گروهی خارج از گستره‌ی فضا و زمان همراه و هم‌نشین می‌شویم. با مطالعه‌ی ادبیات، شعر، داستان یا دیدن یک فیلم اجتماعی، تخیلی یا ... چنین حسی پیدا می‌کنیم. این نه تنها یک حس لذت‌بخش است بلکه نوعی از ارتباط معنی‌دار هم هست. ارتباط با آدم‌هایی فراتر از محدویت‌های زمان و مکان.رهرو آن است که آهسته و پیوسته رودعادت کردن به مطالعه به صورت منظم و دائم خوب است، خیلی هم خوب است. اما برای اغلب ما شرایط محیطی، جسمی و روحی به شکلی تغییر می‌کند که اجرای بی‌نقص یک برنامه‌ی از پیش تعیین شده را عملاً غیر ممکن می‌کند. اگر قرار باشد به خاطر این‌که نمی‌توانیم کاری با بی‌نقص انجام دهیم کلاً آن را کنار بگذاریم، رشد خود را محدود کرده‌ایم. یک عامل مهم در رشد و پیش‌رفت و بهبود، داشتن پشت‌کار و سماجت است. همه‌ی عوامل تأثیرگذار در زندگی، در کنترل ما نیستند؛ در واقع بیشتر آن‌ها در کنترل ما نیستند. اما این توانایی را داریم که اگر حوادث و اتفاقات زندگی ما را از مسیر خارج کرد ناامید نشویم و تلاش کنیم به مسیر برگردیم.به جز تقویت پشت‌کار و سماجت، کارهای دیگری هم می‌شود برای راحت‌تر کردن ایجاد یک عادت انجام داد. برای مثال، می‌توانیم خود را درحلقه‌ی افرادی قرار دهیم که اهل مطالعه هستند، در گروه‌های کتاب‌خوانی شرکت کنیم و ...فعالیت‌هایی از این دست ما را به مطالعه تشویق می‌کند. روش دیگری که راه ما را در تبدیل مطالعه به عادت تسهیل می‌کند حذف عوامل بازدارنده یا حذف خرده خوراک‌هاست. مثل گرسنگی، ذهن ما دائماً هشدارهای نیاز به دریافت اطلاعات را صادر می‌کند اما اگر با خرده خوراک‌ها آن را سیر نگه داریم، دیرتر متوجه اشتباهمان می‌شویم. میزان دریافت خرده خوراک‌ها را تنظیم کنید. آن‌ها را به حدی نرسانید که نیاز گرسنگی شما را پنهان کنند. عمل کردن به این پیشنهاد ممکن است آزاردهنده و سخت باشد. اما مثل خوردن یک داروی تلخ است برای درمان یک بیماری.گاهی یادآوری این‌که مطالعه لزوماً پاسخ سوال امروز ما نیست در حفظ عادت آن کمک کننده است. خیلی اوقات مطلبی را می‌خوانیم یا می‌شنویم یا می‌بینیم که در آن لحظه کاربردی برای ما ندارد. اما دانشی که کسب می‌کنیم در ذهن ما می‌ماند و در آینده به کار می‌آید. بنابراین هر چند ممکن است چیزی که امروز می‌خوانیم دغدغه یا مسأله‌ی امروز ما نباشد اما این به معنی بی‌اثر بودن آن نیست.آخرین نکته این‌که اجازه ندهید کمال‌گرایی، شما را به بی‌عملی برساند. گاهی اوقات در شرایطی هستیم که مطالعه کردن نه تنها مشکلی از ما حل نمی‌کند بلکه ادامه‌ی آن، حسی ناخوشایند در ما ایجاد می‌کند. اصرار به ادامه‌ی مطالعه در چنین شرایطی ممکن است به حدی آزاردهنده شود که آن را به طول کل کنار بگذاریم. در چنین شرایطی از کمال‌گرایی و اجرای بی‌نقص برنامه‌هایتان پرهیز کنید. گاهی اوقات همین که نسبت تنوع منابع مطالعاتی آگاه باشیم کمک‌کننده است. همیشه لازم نیست کتاب بخوانیم، گاهی دیدن یک فیلم هم مطالعه است، شنیدن یک قطعه موسیقی هم مطالعه است. گاهی هم ذهن‌مان توانایی پردازش یک مطلب را ندارد و نیاز به استراحت دارد. اگر این فرصت را به ذهن ندهیم آن را فرسوده می‌کنیم و از کار می‌اندازیم. اجازه ندهید این میل به کمال شما را از کار بیندازد.بنابراین با تقویت عوامل تشویق‌کننده، محدود کردن عوامل بازدارنده، و ناامید نشدن از شکست‌ها می‌توانیم مسیر تبدیل مطالعه به یک عادت را برای خودمان هموارتر کنیم. سید مرتضی هاشمی سید مرتضی هاشمی Sun, 19 Sep 2021 22:45:37 +0430 https://virgool.io/SahabPardaz/accelerate-ublssivylh5v مقدمه«کد بدون تست نداریم.»«هیچ کدی بدون بازبینی (review) داخل نمی‌رود.»«همه‌ی مراحل استقرار (deployment) خودکارسازی شده است.»«ما مجهز به CI/CD هستیم.»«کارهای بزرگ را به کارهای کوچک‌تر شکسته و کارهای موازی را محدود می‌کنیم.»«همواره از مشتری بازخورد دریافت می‌کنیم.»«در سازمان ما، افراد به داشتن ارتباط مستقیم با تیم‌ها و بخش‌های دیگر سازمان و حتی مدیران تشویق می‌شوند.»احتمالاً تعداد زیادی از این گزاره‌ها به گوش شما هم خورده باشد. شاید حتی خود شما هم چندتایی را استفاده کرده و به آن باور داشته باشید. شاید مطالب زیادی در مورد هر یک خوانده باشید که یک یا چند مورد را تایید یا رد کرده باشند. شاید در سازمان شما هم طرفداران و مخالفانی برای هر یک از گزاره‌ها وجود داشته باشد. اما در دنیای واقعی کدام‌یک درست و کدام‌یک اشتباه است؟این خلأ، چیزی است که کتاب Accelerate تلاش می‌کند آن را پر کند. نویسندگان با مطالعه به روش علمی در یک جامعه‌ی آماری گسترده، عوامل موثر بر کارایی را معرفی و اندازه‌گیری می‌کنند. در مقدمه‌ی کتاب می‌خوانیم:این پژوهش، نیازی را که در حال حاضر در بازار، خدمات‌دهی نمی‌شود، برطرف می‌کند. هدف ما این است که با استفاده از روش‌های دقیق علمی —که پیش از این عمدتاً در محیط‌های پژوهشی استفاده‌ می‌شدند— و دسترس‌پذیر کردن آن برای صنعت، کیفیت توسعه و تحویل نرم‌افزار را بهبود بخشیم. با شناسایی و درک توانایی‌هایی که در عمل به شکلی معنادار کارایی را بهبود می‌دهند —چیزی بیش از فقط داستان‌گویی و فراتر از تجربه‌های یک یا چند تیم— می‌توانیم به بهبود صنعت کمک کنیم.خوراک کتاب، سلسله پژوهش‌هایی است که از سال ۲۰۱۴ با عنوان State of DevOps Report منتشر می‌شود. نویسندگان کتاب در واقع پژوهش‌گرانی هستند که آن را پیش می‌برند: Nicole Forsgren, Jez Humble و Gene Kim. در دنیای مهندسی نرم‌افزار شاید هامبل از سایرین شناخته شده‌تر باشد. او نویسنده‌ی کتاب تحویل مستمر (Continuous Delivery) است.از جمله نکات شگفت‌آور این است که به مواردی بر می‌خورید که بر خلاف انتظار، از جنبه‌ی آماری اندازه‌گیری می‌شوند؛ مثل اندازه‌گیری فرهنگ سازمانی و تأثیر آن روی توسعه و تحویل نرم‌افزار. علاوه بر این، بر پایه‌ی روش علمی، پس از اندازه‌گیری، پیش‌بینی صورت گرفته و درستی پیش‌بینی مورد بررسی قرار می‌گیرد.با این مقدمه، سراغ خود کتاب می‌رویم. کتاب در سه بخش تألیف شده است. من مطالب کتاب را به طور کامل پوشش نداده و به ذکر نکات برجسته بسنده می‌کنم.چطور کارایی را اندازه‌گیری کنیم؟متدولوژی‌ها و چهارچوب‌های کاری متعددی وجود دارند که تلاش می‌کنند روش توسعه‌ی محصولات و خدمات را بهبود دهند. هر یک با ارائه‌ی یک تعریف از «خوب» و اندازه‌گیری کمیت مربوط به آن، مسیر بهبود را به ما نشان می‌دهند. کاستی‌هایی که روش‌های پیشین داشته‌اند، معمولاً مربوط به تعریف اشتباه از «خوب» است. برای مثال، تعداد خط کد، سرعت (velocity) یا بهره‌گیری (utilization) را به عنوان شاخص‌های کارایی در نظر بگیرید؛ آیا تعداد خط بیشتر نشان‌دهنده‌ی کارایی بیشتر یک تیم یا توسعه‌دهنده است؟ تعداد خط کم‌تر چطور؟ عمدتاً ما ترجیح می‌دهیم به جای یک برنامه‌ی هزار خطی با یک برنامه‌ی ده‌خطی دست و پنجه نرم کنیم. حتی دوست داریم با هیچ کدی مواجه نباشیم و کدهای اضافی را پاک می‌کنیم. از سوی دیگر، گاهی یک قطعه کد ده خطی را که واضح است و به راحتی خوانده می‌شود، نسبت به نسخه‌ی فشرده‌شده‌ی سه خطی و جادویی آن که نیاز به رمزگشایی دارد، ترجیح می‌دهیم. بنابراین اندازه‌گیری تعداد خط کد معیار ایده‌آلی نیست.اندازه‌گیری سرعت چطور؟ در فرهنگ اصطلاحات چابک (Agile)، مسائل به تعدادی داستان (story) شکسته شده و به داستان‌ها عددی به عنوان امتیاز (point) نسبت داده می‌شود که برآوردی از میزان نیرویی است که صرف آن کار می‌شود. تعداد امتیازهایی که در هر دوره (iteration) توسط تیم به مشتری تحویل داده می‌شود، قابل اندازه‌گیری است و به آن سرعت تیم گفته می‌شود. هدف طراحی سرعت، ارائه‌ی ابزاری برای برنامه‌ریزی ظرفیت است. یعنی پیش‌بینی زمان کامل‌ شدن کارهایی که برنامه‌ریزی و برآورد شده‌اند. سرعت، یک کمیت نسبی و وابسته به تیم است. به همین دلیل نمی‌توان از آن به عنوان شاخصی برای اندازه‌گیری کارایی یا مقایسه میان تیم‌های متفاوت استفاده کرد. علاوه بر این، استفاده از این کمیت برای مقایسه بین تیم‌ها سبب ایجاد یک بازی‌ شده که در این بازی، بی‌شک طرف پیروز، اغراق در برآورد و تمرکز بر کارهای درون‌تیمی به جای همکاری میان‌تیمی خواهد بود.سنجش بهره‌گیری (utilization) به عنوان معیاری برای بهره‌وری (productivity) چطور؟ ایراد این روش این است که بالا بردن بهره‌گیری تا حدی خوب است. به حداکثر رساندن بهره‌وری به این معنی است که هیچ ظرفیت خالی‌ای نداریم. بنابراین، نمی‌توانیم کارهای برنامه‌ریزی نشده، تغییرات یا کارهایی را که منجر به بهبود فرایند می‌شود، بپذیریم. در نتیجه، زمان انجام کار افزایش پیدا خواهد کرد.ایراد اساسی روش‌های توضیح داده شده، تمرکز بر خروجی‌ها (output) به جای پیامدها (outcome) است. خروجی چیزی است که به مشتری تحویل می‌دهیم و پیامد، ارزشی است که مشتری دریافت می‌کند (مطالعه‌ی بیشتر). همچنین شاخص جایگزین باید به شکلی انتخاب شود که منجر به رقابت ناسالم میان تیم‌ها نشود. کتاب، چهار کمیت برای اندازه‌گیری کارایی معرفی می‌کند:۱. زمان تحویل (delivery lead time)۲. فرکانس استقرار (deployment frequency)۳. زمان بازیابی سرویس (time to restore service)۴. نرخ شکست تغییرات (change failure rate)بر این اساس سوالاتی طراحی شده تا میزان تأثیر این شاخص‌ها را روی کارایی تحویل نرم‌افزار، مشخص کند. جداول زیر نتیجه‌ی این پژوهش در سال‌های ۲۰۱۶ و ۲۰۱۷ را نشان می‌دهند.اولین نکته‌ای که در این آمار جلب توجه می‌کند این است که هیچ مصالحه‌ای (tradeoff) میان بهبود کارایی و دستیابی به سطوح بالاتر کیفیت و پایداری وجود ندارد. در حقیقت، تیم‌هایی کارآمدتر در همه‌ی جنبه‌ها از سایرین پیشی گرفته‌اند. احتمالاً چنین عباراتی برای شما آشنا هستند:«نوشتن تست خوب است؛ اما باعث می‌شود کار دیرتر به نتیجه برسد.»«خودکارسازی خوب است؛ اما وقت نداریم.»«مدام خطاهای محیط عملیاتی با تغییرات انسانی برطرف می‌شوند.»...این‌ها همه مثال‌هایی هستند که نشان‌دهنده‌ی طرز تفکری است که بهبود کیفیت و پایداری را در تناقض با بهبود کارایی می‌بیند. نکته‌ی شگفت‌انگیزتر این است که ادامه‌ی مطالعات در سال‌های بعد نشان می‌دهد تیم‌هایی که در گروه کارآمد هستند، نه‌تنها بهتر عمل می‌کنند، بلکه با گذشت زمان فاصله‌ی بیشتری از سایرین می‌گیرند. فرهنگ؟ اندازه‌گیری؟ مگر داریم؟ مگر می‌شود؟!خواندن این بخش از کتاب بسیار برای من جالب و مطالب موجود در آن، بسیار شگفت‌آور بود. تصور اندازه‌گیری چیزی مثل فرهنگ، غیرممکن بود؛ اما با خواندن مطالب کتاب متوجه شدم که با مدل‌سازی درست و طرح سوالات سنجیده چنین کاری نه‌تنها غیرممکن نیست، بلکه می‌تواند به شکلی کاربردی انجام شود.مدل فرهنگ سازمانی وسترومپژوهش‌گران از مدل فرهنگ سازمانی وستروم (Westrum) برای مدل‌سازی فرهنگ استفاده می‌کنند. بر اساس این مدل، سازمان‌ها در سه دسته قرار می‌گیرند:۱. بیمار‌گونه (pathological) / مبتنی بر قدرت: میزان وجود ترس و تهدید در بدنه‌ی سازمان، چنین سازمانی را مشخص می‌کند. افراد معمولا اطلاعات را به دلایل سیاسی نشر نداده یا آن را تغییر می‌دهند تا بهتر به نظر برسند.۲. بوروکراتیک / مبتنی بر مقررات: از بخش‌های (department) خود حمایت می‌کنند. افرادِ داخل یک بخش، از «خاک» خود دفاع می‌کنند، به مقررات خودشان اصرار دارند، و معمولاً بر اساس مقررات عمل می‌کنند (البته، مقررات خودشان).۳. مولد / مبتنی بر کارایی: سازمان‌هایی که بر مأموریت تمرکز می‌کنند. همه چیز به کارایی خوب بستگی دارد؛ به کاری که قرار است انجام دهیم.مدل وستروم به چه درد می‌خورد؟مدل وستروم، چگونگی جریان اطلاعات درون سازمان را پیش‌بینی می‌کند. این نظریه ادعا می‌کند سازمان‌هایی که در آن اطلاعات بهتر جریان دارد، بهتر عمل می‌کنند. فرهنگ خوب، پیش‌نیازهایی دارد که با پرداختن به آن‌ها، ویژگی‌های فرهنگ خوب هم مشخص می‌شود.برای داشتن فرهنگ خوب، به اعتماد و همکاری میان افراد در بخش‌های مختلف سازمان نیاز داریم. بنابراین فرهنگ خوب، نشان‌دهنده‌ی میزان همکاری و اعتماد درون سازمان است.فرهنگ سازمانی بهتر نشان‌دهنده‌ی کیفیت بهتر تصمیم‌گیری است. در چنین فرهنگی، اشتراک اطلاعات برای بهبود تصمیم‌گیری کاری خوب است. علاوه بر این، حتی اگر مشخص شود تصمیمی اشتباه است، راحت‌تر می‌توان تصمیم را برگرداند؛ چراکه به جای برخورد سلسله مراتبی و نگه‌داشتن موضوع در جمعی بسته، شفاف به آن پرداخته می‌شود.در انتها نیز می‌توان گفت تیم‌های دارای چنین فرهنگی، به علت کشف و برطرف شدن سریع مشکلات، در کار بهتر عمل می‌کنند.چطور فرهنگ را اندازه بگیریم؟برای اندازه‌گیری فرهنگ سازمانی بر اساس مدل وستروم، از پرسش‌نامه‌ی زیر استفاده ‌شده است:نکات جالبی در طراحی این پرسش‌نامه پنهان است. نکته‌ی اول این‌که گزاره‌ها به شکلی جمله‌بندی شده‌اند که افراد بتوانند نسبت به آن موضع‌گیری کنند. نکته‌ی دوم این‌که جهت به‌دست‌آمدن اطلاعات بیشتر، پاسخ‌ها طیفی از مقادیر را در بر می‌گیرد. در نهایت، سوالات به شکل هوشمندانه‌ای واقعاً جنبه‌های فرهنگی یک سازمان را هدف قرار می‌دهند. در نتیجه با پاسخ دادن به این سوالات می‌توان نوع فرهنگ سازمانی را تعیین کرد.نتیجه‌ی پژوهش نشان می‌دهد نوع فرهنگ سازمانی نه‌تنها به طور کلی با کارایی تحویل نرم‌افزار و کارایی سازمان در ارتباط است، بلکه حتی تعیین‌کننده‌ی آن نیز هست. این یافته‌ها برای نخستین بار در این کتاب مطرح نمی‌شوند. برای مثال، این مسئله در انجمن‌های DevOps کاملاً پذیرفته شده است. در واقع جنبش DevOps به یک تغییر نگاه فرهنگی تأکید دارد. استفاده از مجموعه‌ای ابزارها، به تنهایی مشکلی که DevOps تلاش می‌کند آن را حل کند، برطرف نخواهد کرد. به همین خاطر فرهنگ در انجمن‌های DevOps از اهمیت ویژه‌ای برخوردار است. آن‌چه کتاب را ارزشمند می‌کند، بررسی و تحلیل آماری جامعه‌ی نرم‌افزار است. این باعث می‌شود شیوه‌ی گفتگو از تبادل نظر و سلیقه‌گرایی به سمت اندازه‌گیری و مطرح کردن حقایق رشد کند.تا این‌جا متوجه شدیم چطور کارایی را اندازه‌گیری کنیم. دیدیم که فرهنگ سازمانی تعیین‌کننده‌ی میزان کارایی است. چگونگی اندازه‌گیری آن را هم بررسی کردیم. حالا نوبت به این سوال می‌رسد که فرهنگ سازمانی تحت تأثیر چیست و چطور آن را بهبود دهیم؟ کتاب عوامل فنی و مدیریتی را در فرهنگ سازمانی مؤثر می‌داند. عوامل فنی مؤثر در قالب مجموعه‌ای از تمرین‌ها با عنوان تحویل مستر (Continuous Delivery) و عوامل مدیریتی تحت عنوان تمرین‌های مدیریتی Lean معرفی می‌شوند.سوالی که ممکن است پیش بیاید این است که چرا عوامل تأثیرگذار، تا این حد مشخص و محدود معرفی می‌شوند؟ آیا همه‌ی عوامل فنی در قالب تمرین‌های تحویل مستمر (Continuous Delivery) قابل خلاصه‌سازی هستند؟ عوامل مدیریتی چطور؟ آیا جز این دو عامل، عامل دیگری وجود ندارد؟ این‌طور اظهارنظرها در واقع ریشه در روش علمی دارد. در حقیقت، روش علمی به این شکل است که گزاره‌ای به عنوان فرضیه در نظر گرفته شده و درستی آن مورد بررسی قرار می‌گیرد. برای مثال، فرض می‌کنیم تمرین‌های تحویل مستمر روی فرهنگ سازمانی تأثیر مثبت می‌گذارند. سپس درستی این فرضیه را بررسی کرده و میزان تأثیرگذاری را اندازه می‌گیریم.تمرین‌های فنیتحویل مستمر (Continuous Delivery) یعنی چه؟ تحویل مستمر (Continuous Delivery) مجموعه‌ای از توانایی‌هاست که به ما امکان می‌دهد انواع تغییرات —ویژگی‌های جدید (feature)، تغییرات پیکربندی، رفع خطاها، و آزمایش‌هایمان— را به شکلی ایمن، سریع و پایدار در محیط عملیاتی به دست کاربر برسانیم. پنج اصل کلیدی در تحویل مستمر (Continuous Delivery) وجود دارد:کیفیت را درون محصول قرار دهید. این عبارت در تقابل با این طرز نگاه است که کیفیت می‌تواند بعداً به محصول اضافه شود.قدم‌های کوتاه بردارید. محیط به سرعت در حال تغییر است. عمدتاً نمی‌دانیم چیز درستی را می‌سازیم یا نه. شکاندن کار بزرگ به کارهای کوچک‌تر باعث می‌شود بتوانیم خروجی را زودتر تحویل دهیم. در نتیجه زودتر می‌توانیم پیامدهای آن برای کسب و کار را اندازه‌گیری کنیم و بازخورد بگیریم. هر چند شکاندن کار به کارهای کوچک‌تر ممکن است سربار داشته باشد این سربار با پیش‌گیری از تحویل چیزی که ارزش آن صفر یا منفی است جبران می‌شود.کارهای تکراری را خودکار کنید. ماشین‌ها برای انجام کارهای تکراری مناسب‌اند و انسان‌ها برای حل مسائل. با خودکارسازی کارهای تکراری به انسان‌ها فرصت می‌دهیم وقتشان را صرف کارهایی ارزشمندتر مثل بهبود طراحی سیستم‌ها و فرایندها کنند.به دنبال بهبود مستمر باشید. مهم‌ترین ویژگی تیم‌های کارآمد قانع نبودن آن‌هاست. همیشه به دنبال بهبود هستند و آن را بخشی از کارهای روزانه‌ی خود می‌دانند.همه مسئول‌اند. در سازمان‌های بوروکراتیک هر بخش روی اهداف خود تمرکز دارد. توسعه به دنبال خروجی بیشتر، تست به دنبال کیفیت، و عملیات به دنبال پایداری است. اما در واقع همه‌ی این‌ها پیامدهایی در سطح کل سیستم هستند که تنها با همکاری بین تیمی به دست می‌آیند.آثار تحویل مستمرطی پژوهش‌ها کیفیت تحویل مستمر در تیم با اندازه‌گیری توانایی‌های زیر انجام شد.هر کدام از این توانایی‌ها در قالب سوالات چند گزینه‌ای اندازه‌گیری شدند. برای مثال، در مورد کنترل نسخه (version control) از شرکت‌کنندگان پرسیده شد تا چه حد با گزاره‌های زیر موافق یا مخالف‌اند.کد برنامه‌ی ما در سیستم کنترل نسخه ذخیره شده است.پیکربندی سیستم ما در سیستم کنترل نسخه ذخیره شده است.پیکربندی برنامه‌ی ما در سیستم کنترل نسخه ذخیره شده است.اسکریپت‌های خودکارسازی build و پیکربندی ما در سیستم کنترل نسخه ذخیره شده است.تحویل مستمر به این معنی تعریف و اندازه‌گیری شد:تیم می‌تواند استقرار در محیط عملیاتی (یا محیط کاربر) را در هر لحظه از چرخه‌ی حیات تحویل نرم‌افزار انجام دهد.بازخورد سریع در مورد کیفیت و قابل استقرار بودن سیستم برای همه‌ی تیم در دسترس است و افراد واکنش به این بازخورد را در اولویت قرار می‌دهند.همان‌طور که در شکل بالا نشان داده شده است، بررسی‌ها نشان داد که عوامل آورده شده در سمت چپ شکل تعیین‌کننده‌ی کیفیت تحویل مستمر هستند. در ادامه اثر تحویل مستمر بر تحویل نرم‌افزار و بهبود فرهنگ بررسی شده و مشخص شد تحویل مستمر دارای این پیامدهاست:افراد نسبت به سازمان خود احساس تعلقی قوی دارندسطوح بالاتری از کارایی در تحویل نرم‌افزار به دست می‌آیدنرخ شکست تغییرات پایین‌تر استفرهنگ سازمانی مولد و مبتنی بر کارایی استنکته‌ی جالبی که در اینجا نهفته است اثر تحویل مستمر بر احساس تعلق افراد به سازمان است. فرض کنید از شما پرسیده می‌شود چطور تعلق افراد به سازمان را بیشتر کنیم؟ احتمالاً در حوزه‌های غیر فنی به دنبال پاسخ این سوال هستیم؛ اما در این پژوهش نشان داده می‌شود که با به‌کارگیری روال‌های درست فنی هم می‌توان احساس تعلق افراد به سازمان را بهبود داد. با نگاهی به عوامل تأثیرگذار بر تحویل مستمر این مسأله روشن‌تر می‌شود. در سازمانی احساس تعلق بیشتر خواهد بود که افراد قدرت انتخاب و اثرگذاری بیشتری در کارشان داشته، وقتشان را صرف انجام کارهای خلاقانه به جای کارهای تکراری کرده، و همه‌ی افراد خود را در کشف و برطرف کردن مشکلات مسئول بدانند.اثر تحویل مستمر بر کیفیتبرای اندازه‌گیری کیفیت، این موارد اندازه‌گیری شد: زمانی که صرف انجام کارهای جدید، دوباره‌کاری و کارهای برنامه‌ریزی نشده، و سایر کارها شده است. نتیجه‌ی بررسی‌ها نشان داد میزان زمان صرف شده در هر مورد بین تیم‌های کارآمد و سایرین متفاوت است.تفاوت میزان وقت صرف شده در هر مورد شاید موضوع چندان عجیبی نباشد. آن‌چه جالب است صرف بیش از نیمی از وقت برای کارهای پیش‌بینی نشده و دیگر کارها حتی در تیم‌های کارآمد است. تصور بسیاری از ما این است که در جلسات برنامه‌ریزی دوره‌ای می‌توانیم و باید برآوردهای (estimate) دقیقی ارائه دهیم. این در حالی است که می‌بینیم حتی در تیم‌های موفق، نزدیک به 20 درصد از کارها غیرقابل پیش‌بینی بوده و نیمی از کارها مواردی هستند که احتمالاً ما در زمان برنامه‌ریزی در نظر نگرفته یا نمی‌توانیم در نظر بگیریم. این به آن معنی نیست که برنامه‌ریزی و برآورد را باید دور ریخت و یا نباید برای بهبود آن تلاش کرد. در عوض باید نظر داشت که ذات توسعه‌ی نرم‌افزار قرار گرفتن در یک فضای ناشناخته و دست و پنجه نرم‌کردن با مسأله است. معمولاً کاری را انجام می‌دهیم که قبلاً انجام نداده‌ایم. بنابراین انتظار ارائه‌ی برآوردهای دقیق و رسیدن ضرب‌العجل‌های (deadline) سخت‌گیرانه، غیر واقع‌بینانه است.نکته‌ی جالب دیگر این است که تفاوت میان گروه کارآمد و سایرین از میزان مورد انتظار کم‌تر بود. پاسخ به این سوال به نقل از کتاب:ما از سازمان‌ها و متخصصانی که با چیزهایی مثل مدیریت پیکربندی، زیرساخت با کد (infrastructure-as-code)، و استقرار مستمر (continuous deployment) آشنایی نداشتند، اطلاعاتی جمع‌آوری نکردیم. با جمع‌آوری نکردن داده‌های این گروه، عده‌ای که به احتمال زیاد حتی از ناکارآمدترین گروه ما بدتر عمل می‌کنند را از دست می‌دهیم.کنترل کیفیت و هیأت مشاور تغییراتیکی از یافته‌های جالب مربوط به اثرگذاری موجودیت‌های کنترل کیفیتی خارج از تیم است. این موجودیت‌ها را ممکن است با عناوینی مثل تیم کنترل یا تضمین کیفیت (QA/QC) و یا هیأت مشاور تغییرات (CAB: Change Advisory Board) بشناسید. مطالعات نشان می‌دهد:تست‌های خودکاری که توسط کنترل کیفیت نوشته شده و نگه‌داری می‌شوند یا به تیم‌های خارج از سازمان برون‌سپاری شده‌اند با کارایی فناوری اطلاعات ارتباطی ندارد.در حقیقت کیفیت زمانی بهبود پیدا می‌کند که آن را به خود تیم بسپاریم. چرا چنین چیزی مشاهده می‌شود؟ دو عامل مهم وجود دارد. اول این‌که وقتی توسعه‌دهندگان تست‌ها را بنویسند، کد قابل تست می‌شود. چون خود توسعه دهنده باید تست‌ها را بنویسد مجبور است طوری کد را بنویسد که قابل تست باشد. دوم آن‌که وقتی مسئولیت تست‌های خودکار بر عهده‌ی توسعه‌دهنده قرار گیرد، برای آن‌ها اهمیت بیشتری قائل می‌شود و انرژی بیشتری برای نگه‌داری و درست کردن خطاها می‌کند.پس آیا دیگر احتیاجی به نقش آزمون‌گر (tester) نداریم؟ جواب کوتاه این سوال خیر است. از پرداختن بیشتر به این موضوع در این‌جا صرف نظر می‌کنم. برای اطلاعات بیشتر می‌توانید به متن کتاب مراجعه کرده و یا کتاب How Google Tests Software را بخوانید.موضوع هیأت مشاور تغییرات (CAB) نیز به طور خاص مورد بررسی قرار گرفته است. در پرسش‌نامه گزینه‌های زیر در اختیار شرکت‌کنندگان قرار گرفت:تمامی تغییرات باید توسط یک موجودیت خارجی (مثل یک مدیر یا هیأت مشاور) مورد تأیید قرار بگیرد.فقط تغییرات پرخطر مثل تغییرات پایگاه داده نیاز به تأیید دارند.برای مدیریت تغییرات از بازبینی همتایان (peer review) استفاده می‌کنیم.هیچ فرایندی برای تأیید تغییرات نداریم.یافته‌ها شگفت‌انگیزند. در مورد تأثیر هیأت مشاور بر کارایی:... نیاز به تأیید، فقط برای تغییرات پرخطر با کارایی تحویل نرم‌افزار ارتباطی نداشت. تیم‌هایی که فرایند تأیید نداشتند یا از بازبینی همتایان (peer review) استفاده می‌کردند به کارایی تحویل نرم‌افزار بیشتری دست می‌یافتند. در نهایت، تیم‌هایی که نیاز به تأیید توسط موجودیت خارجی داشتند کارایی کمتری داشتند.در مورد تأثیر هیأت مشاور بر پایداری:... تأییدهای خارجی با زمان تحویل (lead time)، فرکانس استقرار، و زمان بازیابی ارتباط منفی داشته و با نرخ شکست تغییرات ارتباطی نداشتند.به زبان ساده، این موجودیت‌های خارجی نه‌تنها تأثیری بر کیفیت و پایداری ندارند بلکه باعث کند شدن کار هم می‌شوند؛ تا آن‌جا که وجود آن‌ها از نبود هیچ فرایندی هم بدتر است. این‌که چرا این اتفاق رخ می‌دهد مشخص است. سیستم‌های نرم‌افزاری پیچیده‌اند. گاهاً حتی افرادی که داخل تیم توسعه قرار دارند به همه‌ی جنبه‌های سیستم مسلط نیستند. این انتظار که فردی خارج از تیم می‌تواند ظرافت‌هایی که از دید تیم توسعه مخفی مانده را کشف کند واقع بینانه نیست. اتفاقی که در عمل می‌افتد این است که ما فرایند را دنبال می‌کنیم تا بهانه‌ای دست دیگران ندهیم. این در حالی است که می‌دانیم این فرایند در بهترین حالت بی‌اثر است و صرفاً جنبه‌ی نمایشی دارد تا آن‌که بخواهد چیزی را بررسی کند.توسعه‌ی مبتنی بر trunkتوسعه‌ی مبتنی بر trunk یکی از روش‌های مدیریت branchها در سیستم کنترل نسخه (version control) است. روش‌های مختلفی برای مدیریت branchها در سیستم کنترل نسخه وجود دارد. برای مثال ممکن است عبارات git workflow، github workfow، یا gitflow را شنیده باشید. هر کدام از این روال‌های کاری، روشی برای مدیریت branchها در سیستم کنترل نسخه ارائه می‌دهند. برخلاف این روال‌ها، توسعه‌ی مبتنی بر trunk تلاش می‌کند به جای مدیریت branchهای متفاوت، استفاده از branchها را به حداقل کاهش دهد. در توسعه‌ی مبتنی بر trunk یک branch اصلی وجود دارد که همه‌ی تغییرات به صورت روزانه در آن ادغام (merge) می‌شوند. branchها عموماً عمر کوتاهی دارند و پس از ادغام در شاخه‌ی اصلی حذف می‌شوند.بررسی‌ها نشان می‌دهد توسعه‌ی مبتنی بر trunk با کارایی بیشترِ تحویل در ارتباط است. تیم‌هایی که عملکرد خوبی داشتند حداکثر سه branch فعال داشتند و طول عمر branchهایشان خیلی کوتاه (کم‌تر از یک روز) بود. همچنین چیزی تحت عنوان دوره‌ی پایدارسازی و متوقف کردن فرایند توسعه نداشتند. این نتایج مستقل از اندازه‌ی تیم، اندازه‌ی سازمان، و صنعتی است که سازمان در آن فعالیت می‌کند.در این‌جا باز هم شاهد نکات ارزشمندی هستیم: طول عمرهای به شدت کوتاه، تعداد branchهای فعال خیلی کم، و فراگیر بودن مطالعات. با این‌حال ممکن است افرادی که Github یا سیستم‌های مشابه کار کرده‌اند نسبت به این مشاهدات بدبین باشند. نکته‌ی کلیدی در این‌جا این است که توسعه‌ی مبتنی بر trunk بر طول عمر کوتاه branchها تأکید دارد. مادامی که این شرط برقرار باشد، هر روال کاری که مورد استفاده قرار گیرد از مزیت‌های این روش بهره‌مند خواهد شد.چرا تعداد زیاد branch بد است؟ تعداد زیاد branch به معنی تعداد زیاد کارهای باز است. وقتی با تعدادی زیادی branch روبرو هستیم، این احساس را داریم که در حال انجام مقدار زیادی کار هستیم، در حالی که هیچ یک از آن‌ها واقعاً عملیاتی نشده‌اند. با کم کردن تعداد branchهای فعال تلاش می‌کنیم زمان رساندن یک تغییر به محیط عملیاتی را کاهش دهیم. از سوی دیگر، هر branch در سیستم کنترل نسخه از سایر branchها جداست. یعنی که تغییراتی که در یک branch اعمال می‌شود، برای سایر branchها قابل مشاهده نیست. تنها زمانی که یک branch در شاخه‌ی اصلی ادغام شود، این تغییرات آشکار می‌شوند. هر چه تعداد branchها بیشتر باشد، میزان این تغییرات نهفته بیشتر خواهد بود. در نتیجه احتمال و پیچیدگی تعارض‌ها (conflict) نیز افزایش پیدا می‌کند.چرا عمر زیاد branch بد است؟ هر چه طول عمر یک branch بیشتر باشد، به معنی فاصله گرفتن بیشتر آن از شاخه‌ی اصلی است. ممکن است تصور کنیم اگر در فواصل زمانی کوتاه، تغییرات را از مخزن اصلی بگیریم این مسئله حل می‌شود؛ اما مسئله این‌جاست که همواره در حال پرداخت هزینه‌ی این فاصله گرفتن از شاخه‌ی اصلی هستیم. از سوی دیگر هر چه طول عمر branch بیشتر باشد، احتمالاً تغییرات بیشتری در آن انجام شده است. بنابراین زمانی که تغییرات را در شاخه‌ی اصلی ادغام کنیم به سایر اعضای تیم هزینه‌ی ادغام سنگینی وارد خواهد شد.«اما اگر همیشه تغییرات را در مخزن اصلی ادغام کنیم، نرم‌افزار ناپایدار می‌شود...» نتیجه‌ی مطالعات این را نشان نمی‌دهد. در حقیقت خلاف این را نشان می‌دهد؛ اما این به معنی نیست که اگر همه‌ی تغییرات را در شاخه‌ی اصلی ادغام کنیم، به صورت خودکار محصول پایدار می‌شود. توسعه‌ی مبتنی بر trunk در کنار استفاده از سایر تمرین‌های تحویل مستمر به ما کمک خواهد کرد به این هدف دست پیدا کنیم.برای مطالعه‌ی بیشتر در زمینه‌ی روش‌های مدیریت branch می‌توانید به این مقاله از مارتین فاولر مراجعه کنید.ویژگی‌های معماریتا این‌جا از آثار به‌کارگیری تمرین‌های تحویل مستمر (continuous delivery) بر فرهنگ، کارایی و ... صحبت کردیم. با این‌حال ممکن است با خود بگوییم:«همه‌ی این‌ها درست است، اما در سازمان ما یا پروژه‌ی ما یا در نوع پروژه‌هایی که ما انجام می‌دهیم جواب نمی‌دهد. DevOps و تحویل مستمر برای سیستم‌های مبتنی بر وب طراحی شده‌اند در حالی که ما روی یک نرم‌افزار یک‌تکه (monolithic) که روی mainframe اجرا می‌شود کار می‌کنیم.»این بخش از پژوهش تلاش می‌کند تأثیر تصمیمات و محدودیت‌های معماری را بر تحویل نرم‌افزار در محیط‌های متفاوت بررسی کرده و ویژگی‌های معماری مؤثر را شناسایی کند. یافته‌ها نشان می‌دهد... دستیابی به کارایی بالا در همه‌ی انواع سیستم‌ها امکان‌پذیر است، به شرطی که سیستم و تیم توسعه‌دهنده و نگه‌دارنده‌ی آن، دارای وابستگی‌های سست (loose coupling) باشند.انواع سیستم‌هایی که طی پژوهش مورد بررسی قرار گرفتند به شرح زیرند.زمین سبز (greenfield): سیستم‌های جدیدی که هنوز منتشر نشده‌اندسیستم‌های سرگرمی (مورد استفاده‌ی مستقیم کاربران)سیستم‌های ثبت و ضبط (برای ذخیره‌سازی اطلاعات حیاتی کسب و کار که در آن صحت و سازگاری اطلاعات اهمیت دارد)نرم‌افزار سفارشی که توسط شرکت دیگری توسعه داده می‌شودنرم‌افزار سفارشی داخلینرم‌افزار تجاری از پیش‌آماده و بسته‌بندی شده (commercial off-the-shelf)نرم‌افزار تعبیه‌شده (embedded) که روی دستگاه سخت‌افزاری تولید شده اجرا می‌شودنرم‌افزارِ دارای مولفه‌ای که توسط کاربر نصب می‌شود (شامل برنامه‌های موبایل)نرم‌افزار غیر mainframe که روی سرورهای شرکت دیگری اجرا می‌شودنرم‌افزار mainframeیافته‌ها نشان می‌دهد... گروه‌های ناکارآمدتر بیشتر می‌گفتند نرم‌افزاری که می‌سازند یا سرویس‌هایی که با آن تعامل دارند نرم‌افزاری سفارشی است که توسط شرکت دیگری توسعه داده می‌شود... همچنین تعداد بیشتری از آن‌ها روی سیستم‌های mainframe کار می‌کردند. به طرز جالبی یکپارچه (integrate) کردن تغییرات در سیستم‌های mainframe ارتباطی با کارایی نداشت.در سایر موارد ارتباط چشم‌گیری بین نوع سیستم و کارایی تحویل وجود نداشت.این یافته‌ها شگفت‌آور است و نشان می‌دهد حتی در سیستم‌های بسته‌بندی شده و میراثی، می‌توان از مزیت‌های معماری با وابستگی سست بهره‌مند شد. همچنین در مقابل، استفاده از آخرین نسخه‌ی معماری microservice یا استفاده از container برای استقرار تضمینی برای بهبود کارایی نیست. آن‌چه بر کارایی اثرگذار است ویژگی‌هایی است که در ادامه به آن خواهیم پرداخت.تمرکز بر قابل استقرار و قابل تست بودنبرای بررسی قابل استقرار و قابل تست بودن گزینه‌های زیر در پرسش‌نامه قرار گرفت. تیم‌هایی که با عبارات زیر موافق بودند به احتمال بیشتری در دسته‌ی کارآمد قرار می‌گرفتند.بیشتر تست‌های ما بدون نیاز به محیط یکپارچه قابل اجراست.می‌توانیم برنامه‌مان را مستقل از برنامه‌ها یا سرویس‌هایی که به آن‌ها وابستگی دارد، استقرار داده یا انتشار دهیم و از این امکان استفاده می‌کنیم.این دو ویژگی را قابل تست و قابل استقرار بودن می‌نامیم. این ویژگی‌ها حاصل تصمیم‌هایی در سطح معماری هستند. برای دست‌یابی به این ویژگی‌ها طراحی باید به شکلی باشد که وابستگی‌ها سست باشند. یعنی تغییر و اعتبارسنجی (validation) بخش‌های مختلف سیستم، باید بتواند به صورت مستقل از هم انجام شود. بررسی‌ها نشان می‌دهد موارد زیر، مهم‌ترین عوامل در تحویل مستمر هستند؛ حتی مهم‌تر از خودکارسازی تست و استقرار.تیم می‌تواند تغییرات طراحی در مقیاس بزرگ را بدون نیاز به اجازه‌ی فردی خارج از تیم انجام دهد.تیم می‌تواند تغییرات در مقیاس بزرگ را در طراحی سیستم خود انجام دهد؛ بدون این‌که نیاز به تغییر در سیستم دیگری باشد یا کار زیادی برای سایر تیم‌ها ایجاد کند.تیم می‌تواند کار خود را بدون نیاز به ارتباط و هماهنگی با افراد خارج از تیم انجام دهد.تیم می‌تواند بدون در نظر گرفتن سایر سرویس‌های وابسته، سرویس یا محصول خود را در لحظه (on demand)، استقرار یا انتشار دهد.تیم می‌تواند بیشتر تست‌های خود را در لحظه و بدون نیاز به محیط یک‌پارچه انجام دهد.تیم می‌تواند استقرار را در ساعات اداری با زمان قطعی (downtime) ناچیز انجام دهد.این موارد ویژگی‌های سیستمی است که وابستگی‌های سست دارد. اما چطور به این نقطه برسیم؟ برای دست‌یافتن به این قابلیت، به تیم خودکفا (cross functional) نیاز داریم؛ تیمی که تمامی مهارت‌های مورد نیاز طراحی، توسعه، تست، استقرار، و عملیات در آن وجود دارد. هدف این است که تیم بتواند کار خود را از مرحله‌ی طراحی تا استقرار، بدون نیاز به تعاملات بین تیمی زیاد انجام دهد.پس DevOps چه شد؟ DevOps ما را تشویق به ارتباطات بهتر بین تیمی می‌کند. تیم خودکفا نمی‌خواهد ارتباطات بین تیمی را حذف کند. وابستگی‌های سست باعث می‌شود بتوانیم در تعاملات بین تیمی به جای پرداختن به جزئیات، بر اهداف مشترک تمرکز کنیم.سخن پایانیآن‌چه خواندید بخشی از نکات برجسته و ارزشمند کتاب Accelerate بود. موارد زیادی بود که در این مطلب فرصت پرداختن به آن را پیدا نکردم. به طور خاص به تمرین‌های مدیریتی و مسائل پیرامون آن مثل رضایت کارمندان، رهبری و ... نپرداختم. به بخش روش تحقیق نیز پرداخته نشد و خواننده‌ی علاقه‌مند می‌تواند توضیحات بیشتر را با مراجعه به کتاب پیدا کند.به نظر می‌رسد مطالب ارائه شده در کتاب، پشتوانه‌ی قوی علمی و پژوهشی داشته باشد. یافته‌ها شگفت‌انگیز هستند. اظهار نظرها بعضاً جسورانه هستند؛ اما تلاش شده با مطالعه‌ی گسترده جای بحث و گمان به حداقل برسد. با این حال ممکن است به بخش‌هایی از آن مشکوک بوده یا کاملاً با آن مخالف باشید. ممکن است با خود بگویید حتی اگر چیزی در اکثریت یک جامعه‌ی آماری برقرار باشد، به معنی جهان‌شمولی آن نیست و شاید در سازمان ما جواب ندهد.ممکن است حق با شما باشد. آورده‌ی اصلی این کتاب، تنها یافته‌های آن نیست. آن‌چه خواندن این کتاب را ارزشمند می‌کند نوع نگاه و روش علمی پرداخت به موضوع است؛ اظهار نظر بر اساس اندازه‌گیری و جمع‌آوری اطلاعات، به جای ادعا و اعمال سلیقه. آزمایش‌ها قابل تکرار هستند. می‌توانید پرسش‌نامه‌ها را در سازمان خود پخش کرده و نتایج را ببینید. نتیجه هر چه که باشد، با اتکا به جمع‌آوری داده و اندازه‌گیری، در مسیر بهتری قرار خواهید گرفت. سید مرتضی هاشمی سید مرتضی هاشمی Fri, 18 Dec 2020 16:30:20 +0330 https://virgool.io/SahabPardaz/release-it-bbc5k6annhdc خیلی از ما توسعه‌دهندگان نرم‌افزار، درد یک فرایند استقرار طولانی و دلهره‌آور را چشیده‌ایم. ممکن است پس از به پایان رسیدن این فرایند سخت، با تجربه‌ی ناخوشایند بیدار شدن از خواب با تماس‌های تلفنی مواجه شده باشیم. حتی شاید به دلیل پایین آمدن سرویس، از دست رفتن اطلاعات و یا نشت آن تا مرز از دست رفتن شغلمان پیش رفته باشیم. مایکل نایگارد در کتاب Release It تلاش می‌کند راه‌کارهایی به ما ارائه کند تا کمتر با چنین مشکلاتی برخورد کنیم. او یک مهندس نرم‌افزار است که سال‌ها در زمینه‌‌ی توسعه و استقرار سیستم­‌های نرم‌افزاری تجربه دارد. او در این کتاب چکیده‌ای از تجربیات خود را به صورت ترکیبی از داستان و درس تدوین کرده است.برای بسیاری از ما توسعه‌دهندگان، تعریف پایان کار، اضافه شدن کد به مخزن است؛ چه اضافه شدن یک ویژگی باشد و چه رفع یک خطا. توسعه‌دهندگانِ باتجربه‌تر به این بسنده نمی‌کنند. آن‌ها تا زمانی که تست نکنند، کار خود را تمام شده نمی‌دانند. عده‌ای هوشمندانه قبل از اضافه کردن کد به مخزن با اضافه کردن تست‌های خودکار، زحمت کار خود را کاهش می‌دهند. اما در نهایت، توسعه‌دهندگان اغلب پس از پاس شدن تست‌ها، کار خود را تمام شده می‌دانند. نایگارد این مسأله را به زیبایی مطرح می‌کند:شما سخت روی پروژه کار کرده‌اید. به نظر می‌­رسد همه‌­ی ویژگی‌­ها (feature) کامل شده‌­اند و حتی اکثر آن‌­ها تست هم دارند. می‌توانید نفسی راحت بکشید. کار شما تمام است.درست است؟آیا «تکمیل ویژگی­‌ها» به معنی «آمادگی برای محیط عملیاتی» است؟ آیا سیستم شما واقعاً برای استقرار آماده است؟ آیا می‌­تواند بدون شما توسط تیم عملیات اجرا شده و با هجمه­‌ی کاربران واقعی روبرو شود؟ آیا در این فکر غرق شده‌اید که دیروقت با تماس ­های اضطراری و هشدار مواجه خواهید شد؟ به نظر می‌­رسد توسعه‌ی نرم‌­افزار چیزی بیش از اضافه کردن ویژگی­‌ها باشد.در حقیقت، کار توسعه‌دهنده با پاس شدن تست‌ها تمام نمی‌شود، بلکه تازه باید برای محیط عملیاتی آماده شد. Release It شامل موضوعاتی است که توسعه‌دهنده باید برای زنده ماندن در محیط عملیاتی مد نظر داشته باشد.کتاب از چهاربخش تشکیل شده و شیوه­‌ی نگارش آن بسیار جالب است. هر بخش با یک داستان شروع می‌­شود؛ داستانی از حوادث در محیط عملیاتی؛ حوادثی که منجر به وارد شدن صدمه به دارایی‌های مالی یا معنوی ذی‌نفعان می‌شود. داستان‌ها واقعی بوده و بدون واسطه، توسط نویسنده تجربه شده‌اند؛ اما نام‌ها و جزییات تغییر داده شده تا محرمانگی حفظ شود.بخش اول «ایجاد پایداری» نام دارد. نایگارد با «اکسپشنی که یک خط هوایی را زمین زد» شروع می‌کند؛ داستان به‌­روزرسانی بخشی از یک سیستم، طی یک فرایند از قبل طراحی شده و بر اساس برنامه. در نهایت این به‌­روزرسانی منجر به بروز اختلال در سایر سیستم­‌ها از جمله سیستم صدور بلیط می‌­شود. تا زمانی که مسئله برطرف شود، هزینه­ زیادی هم از لحاظ مالی و هم از لحاظ آبروی کسب و کار، به خط هوایی وارد شده است.یکی از کارهایی که مایکل نایگارد در این کتاب انجام داده است، جمع­ آوری و نام­‌گذاری چیزهایی است که احتمالاً ما هم هنگام توسعه یا استقرار با آن برخورد کرده‌ایم. شاید هم به طور پراکنده در مورد آن مطالعه کرده باشیم؛ کاری مثل آن‌چه که کتاب الگوهای طراحی انجام داد. نایگارد ضد الگوهای پایداری را به ما معرفی می‌­کند. ضد الگوها عادت‌هایی هستند که نه تنها به پایداری سیستم کمکی نکرده، بلکه باعث تضعیف آن نیز می‌شوند.در بخش اول 12 ضد الگوی پایداری معرفی می‌شود. بعضی از این الگوها با هم ارتباط یا هم‌پوشانی داشته و یا یکدیگر را تقویت می‌کنند. بعد از مطرح کردن ضد الگوهای پایداری، نوبت به معرفی الگوهای پایداری می‌رسد. در این‌جا هم 12 الگو معرفی می‌شود که کم و بیش در تناظر با ضد الگوهای یاد شده هستند. یکی از الگوهای جالب Let It Crash است:گاهی اوقات بهترین کاری که می شود برای پایدارسازی در سطح سیستم انجام داد، رها کردن پایداری در سطح مؤلفه است. در دنیای Erlang به این روش، فلسفه «let it crash» گفته می شود. ... می دانیم که نمی توان به جلوگیری از همه خطاهای ممکن امیدوار بود. ابعاد، گسترش یافته و فضای حالت به صورت نمایی رشد می‌کند. راهی برای تست همه چیز و پیش بینی همه‌ی راه‌های شکست سیستم وجود ندارد. باید فرض کنیم که خطا رخ خواهد داد.سوال کلیدی این است، «با خطا چه کنیم؟». اغلب تلاش می کنیم شرایط را بازیابی کنیم. یعنی سیستم را با استفاده از exception handler ها و ... به یک حالت شناخته‌شده‌ی خوب برگردانیم. آیا این کافی است؟پاک‌ترین حالتی که برنامه‌ی شما می تواند داشته باشد، حالتی که درست بعد از شروع به کار دارد. رویکرد «let it crash» می‌گوید جبران خطا سخت و غیرقابل اتکاست، بنابراین هدف ما باید رسیدن هرچه سریع‌تر به آن وضعیت پاک باشد.در واقع نایگارد در این‌جا از ما دعوت می‌کند برای داشتن سیستم‌های پایدار، در شرایط خطا مولفه‌ها را هر چه سریع‌تر پایین بیاوریم!موضوع بخش بعدی کتاب «طراحی برای محیط عملیاتی» است. بارها شنیده‌ایم و دیده‌ایم که چیزی در محیط توسعه کار می‌کند اما در محیط عملیاتی با خطا مواجه می‌شود؛ جدال قدیمی میان تیم توسعه و استقرار. چیزی که نایگارد در این‌جا توجه ما را به آن جلب می‌کند تفاوت‌های محیط توسعه و محیط عملیاتی است. این تفاوت‌ها موجب بروز نگرانی‌هایی در محیط عملیاتی می‌شود. علاوه بر این، نکته‌ی دیگری که او به زیبایی به آن اشاره می‌کند در نظر داشتن افراد تیم عملیات است:طراحی برای محیط عملیاتی یعنی فکر کردن به مشکلات عملیاتی به عنوان نگرانی‌های دست اول. این مشکلات شامل شبکه محیط عملیاتی است که ممکن است بسیار متفاوت از محیط توسعه باشد. همچنین شامل لاگ زدن و نظارت (monitoring)، کنترل runtime، و امنیت می شود. طراحی برای محیط عملیاتی همچنین به معنی طراحی برای افرادی است که کار عملیات را انجام می‌دهند، چه تیم جداگانه‌ای باشند و چه در توسعه ادغام شده باشند.سپس نایگارد لایه‌های نگرانی را مطرح می‌کند. در هر لایه الفبا معرفی شده و قدم‌های بعدی برای مطالعه‌ی توضیح داده می‌شود.پس از «طراحی برای محیط عملیاتی» نوبت به «تحویل سیستم» می‌رسد. داستان این بخش «در انتظار گودو» نام دارد. در این داستان نایگارد دوتجربه‌ی متفاوت از استقرار در محیط عملیاتی را تعریف می‌کند. یکی با تلاش بیش از 40 نفر متخصص در یک بازه‌ی 24 ساعته و دومی با فشرده شدن یک دکمه توسط یک سرمایه‌گذار که در حال بازدید از شرکت بود!نایگارد از خودکارسازی استقرار، خط لوله‌ی build و استقرار مستمر (Continuous Deployment) صحبت می‌کند. او مفاهیم اصلی را به طور خلاصه مطرح کرده و برخی از ابزارهای موجود را نیز معرفی می‌کند. من به جزییات این موارد نمی‌پردازم و صرفاً به چند نکته‌ی جالب بسنده می‌کنم.یکی از نکات جالب pets vs. cattle است. در گذشته تعداد ماشین‌هایی که با آن سروکار داشتیم محدود بود. هر ماشین نقش مشخص و شناخته شده‌ای داشت. حتی گاهی تک‌تک ماشین‌ها را با اسمشان صدا می‌کردیم؛ مثل حیوانات خانگی. اما با گذر زمان تعداد ماشین‌ها بیشتر شد. نحوه‌ی کار با آن‌ها هم تغییر کرد. امروز ما با گله‌ای از ماشین‌ها مواجه‌ایم. این مسئله چطور روی کار ما تأثیر خواهد گذاشت؟ دیگر نام ماشین‌ها را نمی‌دانیم. دیگر نمی‌دانیم چه چیزی روی چه ماشینی اجرا می‌شود. دیگر از بین رفتن یک ماشین خاص برایمان اهمیت ندارد.نکته‌ی دیگری که در این فضای جدید اهمیت پیدا می‌کند رسیدگی به نسخه‌هاست. در شرایط پیچیده‌تر امروز باید بتوانیم نسخه‌های متفاوت سرویس‌ها را با یکدیگر هماهنگ نگه‌داریم. مصرف کننده‌ی یک سرویس، تیم یا محصول دیگری است. چطور نسخه‌های جدید را بدون نگرانی انتشار دهیم؟ اینجا صحبت از backward compatibility، نوشتن تست‌ها توسط مشتری و سخت‌گیری و بدبینی در تعامل با سایر سرویس‌ها است.در بخش آخر نایگارد، از «حل مشکلات سیستمی» صحبت می‌کند. در فصل اول این بخش، او از ضرورت تطبیق‌پذیری (Adaptability) صحبت می‌کند. در شرایط کنونی، مقاومت در برابر تغییر دیگر یک گزینه نیست. اکنون صحبت از کوتاه کردن چرخه‌ی بازخورد و رفع موانع است؛ این‌که چطور خود را برای استقبال از در آغوش گرفتن تغییرات آماده کنیم.در فصل بعدی نایگارد وارد موضوع مهندسی آشوب (Chaos Engineering) می‌شود. مهندسی آشوب یک موضوع نوظهور در عرصه‌ی نرم‌افزار است و طی چند سال گذشته تحولات زیادی داشته است. مهندسی آشوب تلاش می‌کند نرم‌افزار را در مقابل فجایعی که ممکن است در محیط عملیاتی رخ دهند، مقاوم کند. نایگارد این‌طور آن را معرفی می‌کند:گفتگویی را تصور کنید که این‌طور شروع می‌شود:شما می‌گویید: «سلام رئیس، من می‌خوام تو محیط عملیاتی یه تعدادی از ماشینا رو بترکونم. یه کم از اینور و یه کم از اون‌ور. نباید مشکلی پیش بیاد.»فکر می‌کنید ادامه‌ی گفتگو چطور پیش‌ خواهد رفت؟ ممکن است با مراجعه‌ی یک نفر از منابع انسانی و دستور تمیز کردن میز کارتان تمام شود. شاید هم یک قرار ملاقات با نزیک‌ترین مطب روانشناسی! پایین آوردن ماشین‌ها ممکن است یک ایده‌ی افراطی باشد، اما جنون نیست. این یک تکنیک از یک مکتب نوظهور است به نام «مهندسی آشوب».این مقدمه شاید مضحک به نظر برسد؛ اما ایده‌ی اصلی مهندسی آشوب همین است: خراب‌کاری نیمه‌کنترل شده در محیط عملیاتی! در ادامه توضیح بیشتری در مورد تاریخچه‌ی این مکتب و نگاه آن به نحوه‌ی مقاوم‌سازی سیستم‌ها داده می‌شود.آن‌چه که خواندید گوشه‌ای از مطالبی است که در کتاب Release It آمده است. خواندن کتاب و مرور دوباره‌ی آن برای نوشتن این مطلب، برای من لذت‌بخش و آموزنده بود. امیدوارم توانسته باشم این حس را در خوانندگان هم ایجاد کرده باشم. سید مرتضی هاشمی سید مرتضی هاشمی Sun, 05 Jul 2020 22:11:35 +0430