فصل ۱ — فلسفهٔ عمل‌گرایانه

برنامه‌نویسان عمل‌گرا (Pragmatic Programmer) را چه چیزی متمایز می‌کند؟ ما فکر می‌کنیم نگرشی است، سبکی است، فلسفی برای نزدیک شدن به مسائل و راه‌حل‌هایشان. آن‌ها فراتر از مشکل فوری فکر می‌کنند، همیشه تلاش می‌کنند آن را در context بزرگ‌تر قرار دهند، همیشه سعی می‌کنند از تصویر بزرگ‌تر آگاه باشند. بالاخره، بدون این context بزرگ‌تر چگونه می‌توانید عمل‌گرا باشید؟ چگونه می‌توانید مصالحه‌های هوشمندانه و تصمیم‌های آگاهانه بگیرید؟

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

بیشتر مردم پذیرش تغییر را دشوار می‌یابند؛ گاهی به دلایل خوب، گاهی به‌خاطر اینرسی ساده. در «سوپ سنگی و قورباغه‌های جوشیده» به استراتژی برای برانگیختن تغییر نگاه می‌کنیم و (به‌خاطر تعادل) داستان هشداردهندهٔ دوزیستانی را روایت می‌کنیم که خطرات تغییر تدریجی را نادیده گرفت.

یکی از مزایای درک contextی که در آن کار می‌کنید این است که آسان‌تر می‌شود بدانید نرم‌افزارتان باید چقدر خوب باشد. گاهی نزدیک به کمال تنها گزینه است، اما اغلب مصالحه در میان است. این را در «نرم‌افزار به‌اندازهٔ کافی خوب» بررسی می‌کنیم.

البته برای انجام همهٔ این‌ها به پایهٔ گسترده‌ای از دانش و تجربه نیاز دارید. یادگیری فرایندی پیوسته و مداوم است. در «سبد دانش شما» دربارهٔ استراتژی‌هایی برای حفظ شتاب صحبت می‌کنیم.

و سرانجام، هیچ‌کس از ما در خلأ کار نمی‌کند. همهٔ ما زمان زیادی را صرف تعامل با دیگران می‌کنیم. «ارتباط برقرار کنید!» راه‌هایی را فهرست می‌کند که می‌توانیم این کار را بهتر انجام دهیم.

برنامه‌نویسی عمل‌گرایانه از فلسفهٔ تفکر عمل‌گرایانه سرچشمه می‌گیرد. این فصل پایهٔ آن فلسفه را می‌گذارد.

۱. گربه کد منبعم را خورد

بزرگ‌ترین همهٔ ضعف‌ها، ترس از ضعیف به نظر آمدن است.

— J. B. Bossuet، Politics from Holy Writ، ۱۷۰۹

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

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

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

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

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

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

اگر ریسکی بود که vendor برایتان نتیجه ندهد، باید برنامهٔ contingency داشته باشید. اگر دیسک خراب شود — و تمام کد منبع شما را با خود ببرد — و backup نداشته باشید، تقصیر شماست. گفتن به رئیستان که «گربه کد منبعم را خورد» جواب نمی‌دهد.

TIP 3

گزینه ارائه دهید، بهانه‌سازی نکنید

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

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

به‌جای بهانه، گزینه ارائه دهید. نگویید نمی‌شود انجام داد؛ توضیح دهید چه کاری می‌توان برای نجات وضعیت انجام داد. آیا باید کد دور انداخته شود؟ آن‌ها را از ارزش refactoring (بخش Refactoring، صفحه ۱۸۴) آگاه کنید. آیا باید وقت بگذارید و prototype بسازید تا بهترین راه پیشروی را مشخص کنید (بخش Prototypes and Post-it Notes، صفحه ۵۳)؟ آیا باید تست بهتر (بخش Code That's Easy to Test، صفحه ۱۸۹، و Ruthless Testing، صفحه ۲۳۷) یا automation (بخش Ubiquitous Automation، صفحه ۲۳۰) معرفی کنید تا دوباره اتفاق نیفتد؟ شاید به منابع بیشتری نیاز دارید. نترسید بخواهید، یا بپذیرید که به کمک نیاز دارید.

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

بخش‌های مرتبط

• Prototypes and Post-it Notes، صفحه ۵۳
• Refactoring، صفحه ۱۸۴
• Code That's Easy to Test، صفحه ۱۸۹
• Ubiquitous Automation، صفحه ۲۳۰
• Ruthless Testing، صفحه ۲۳۷

چالش‌ها

• وقتی کسی — مثلاً صندوقدار بانک، مکانیک خودرو یا کارمند — با بهانه‌ای بی‌ارزش نزد شما می‌آید چه واکنشی نشان می‌دهید؟ در نتیجه دربارهٔ آن‌ها و شرکتشان چه فکری می‌کنید؟

۲. آنتروپی نرم‌افزار

در حالی که توسعهٔ نرم‌افزار تقریباً از همهٔ قوانین فیزیکی مصون است، entropy به‌شدت به ما ضربه می‌زند. Entropy اصطلاحی از فیزیک است که به میزان «بی‌نظمی» در یک سیستم اشاره دارد. متأسفانه، قوانین ترمودینامیک تضمین می‌کنند که entropy در جهان به سمت حداکثر میل می‌کند. وقتی بی‌نظمی در نرم‌افزار افزایش می‌یابد، برنامه‌نویسان آن را «پوسیدگی نرم‌افزار» (software rot) می‌نامند.

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

چه چیزی تفاوت ایجاد می‌کند؟

در شهرهای مرکزی، بعضی ساختمان‌ها زیبا و تمیزند و بعضی لاشه‌های در حال پوسیدن. چرا؟ پژوهشگران حوزهٔ جرم و فساد شهری مکانیزم محرک جالبی کشف کردند که خیلی سریع یک ساختمان تمیز، سالم و مسکون را به ویرانه‌ای شکسته و متروک تبدیل می‌کند [WK82].

یک پنجرهٔ شکسته.

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

«نظریهٔ پنجرهٔ شکسته» (Broken Window Theory) بخش‌های پلیس نیویورک و شهرهای بزرگ دیگر را الهام بخشید تا روی جزئیات کوچک سخت‌گیر باشند تا چیزهای بزرگ را دور نگه دارند. جواب می‌دهد: کنترل پنجره‌های شکسته، گرافیتی و تخلفات کوچک دیگر، سطح جرم جدی را کاهش داده است.

TIP 4

با پنجره‌های شکسته زندگی نکنید

«پنجره‌های شکسته» (طراحی بد، تصمیم اشتباه یا کد ضعیف) را بدون تعمیر رها نکنید. هر کدام را به‌محض کشف، درست کنید. اگر وقت کافی برای تعمیر درست ندارید، آن را بپوشانید. شاید بتوانید کد مشکل‌دار را comment out کنید، پیام «Not Implemented» نمایش دهید، یا به‌جای آن دادهٔ dummy بگذارید. اقدامی انجام دهید تا آسیب بیشتر جلوگیری شود و نشان دهید وضعیت را تحت کنترل دارید.

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

شاید فکر کنید کسی وقت ندارد همهٔ شیشه‌های شکستهٔ یک پروژه را جمع کند. اگر به فکر کردن به این شکل ادامه دهید، بهتر است برای گرفتن یک کانتینر زباله برنامه‌ریزی کنید، یا به محلهٔ دیگری نقل مکان کنید. نگذارید entropy برنده شود.

خاموش کردن آتش

در مقابل، داستان آشنای بسیار ثروتمند اندی را داریم. خانه‌اش بی‌نقص، زیبا و پر از عتیقه‌های گران‌بها و objets d'art بود. یک روز، یک تابلو که کمی نزدیک‌تر از شومینهٔ نشیمن آویزان بود آتش گرفت. آتش‌نشان‌ها برای نجات روز — و خانه‌اش — شتاب کردند. اما قبل از اینکه شلنگ‌های بزرگ و کثیفشان را به داخل خانه بکشند، توقف کردند — در حالی که آتش می‌سوخت — و بین در ورودی و منبع آتش یک تشک پهن کردند.

نمی‌خواستند فرش را کثیف کنند.

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

به همین ترتیب، اگر در تیمی و پروژه‌ای هستید که کدش بی‌نقص زیباست — تمیز نوشته شده، خوب طراحی شده و elegant — احتمالاً مراقبت ویژه‌ای می‌کنید که آن را خراب نکنید، درست مثل آتش‌نشان‌ها. حتی اگر آتش می‌سوزد (deadline، تاریخ release، دمو نمایشگاه و غیره)، نمی‌خواهید اولین کسی باشید که کثیف‌کاری می‌کند.

بخش‌های مرتبط

• Stone Soup and Boiled Frogs، صفحه ۷
• Refactoring، صفحه ۱۸۴
• Pragmatic Teams، صفحه ۲۲۴

چالش‌ها

• با بررسی محلهٔ محاسباتی‌تان به تقویت تیم کمک کنید. دو یا سه «پنجرهٔ شکسته» انتخاب کنید و با همکاران دربارهٔ مشکلات و راه‌حل‌های ممکن بحث کنید.

• آیا می‌توانید بفهمید پنجره اولین بار کی شکسته شد؟ واکنش شما چیست؟ اگر نتیجهٔ تصمیم شخص دیگری یا دستور مدیریت بود، چه کاری می‌توانید انجام دهید؟

۳. سوپ سنگی و قورباغه‌های جوشیده

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

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

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

چند دقیقه بعد، روستاییان دوباره پرسیدند «فقط همین؟»

«خب»، سربازها گفتند، «چند سیب‌زمینی به آن body می‌دهد.» روستایی دیگری دوید.

در ساعت بعد، سربازها مواد بیشتری که سوپ را بهتر می‌کرد فهرست کردند: گوشت، تره‌فرنگی، نمک و سبزی. هر بار روستایی دیگری دوید تا از ذخیرهٔ شخصی‌اش بردارد.

سرانجام دیگ بزرگی از سوپ داغ درست کردند. سربازها سنگ‌ها را بیرون آوردند و با کل روستا نشستند تا اولین وعدهٔ کامل غذایی که ماه‌ها نخورده بودند را بخورند.

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

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

شاید در وضعیتی باشید که دقیقاً می‌دانید چه باید انجام شود و چگونه. کل سیستم جلوی چشمانتان ظاهر می‌شود — می‌دانید درست است. اما اگر اجازه بخواهید کل آن را انجام دهید، با تأخیر و نگاه‌های خالی روبه‌رو می‌شوید. مردم کمیته تشکیل می‌دهند، بودجه باید تأیید شود و همه چیز پیچیده می‌شود. هر کس از منابع خود محافظت می‌کند. گاهی این را «خستگی شروع» (start-up fatigue) می‌نامند.

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

TIP 5

کاتالیزور تغییر باشید

طرف روستاییان

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

همهٔ علائم را دیده‌ایم. پروژه‌ها آرام و ناگزیر کاملاً از کنترل خارج می‌شوند. بیشتر فاجعه‌های نرم‌افزاری آن‌قدر کوچک شروع می‌شوند که متوجه نشوید و بیشتر تأخیرهای پروژه روزبه‌روز رخ می‌دهند. سیستم‌ها feature به feature از specification دور می‌شوند، در حالی که patch بعد از patch به تکه‌ای کد اضافه می‌شود تا چیزی از اصل باقی نماند. اغلب انباشت چیزهای کوچک است که روحیه و تیم‌ها را می‌شکند.

TIP 6

تصویر بزرگ را به یاد داشته باشید

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

¹ در حین انجام این کار، شاید با جمله‌ای که به دریادار Grace Hopper نسبت داده می‌شود دلگرم شوید: «بخشیدن گرفتن اجازه آسان‌تر است.»

توجه کنید مشکل قورباغه با مسئلهٔ پنجره‌های شکسته که در بخش ۲ بحث شد متفاوت است. در نظریهٔ پنجرهٔ شکسته، مردم ارادهٔ مبارزه با entropy را از دست می‌دهند چون احساس می‌کنند کس دیگری اهمیت نمی‌دهد. قورباغه فقط تغییر را متوجه نمی‌شود.

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

بخش‌های مرتبط

• Software Entropy، صفحه ۴
• Programming by Coincidence، صفحه ۱۷۲
• Refactoring، صفحه ۱۸۴
• The Requirements Pit، صفحه ۲۰۲
• Pragmatic Teams، صفحه ۲۲۴

چالش‌ها

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

۴. نرم‌افزار به‌اندازهٔ کافی خوب

تلاش برای بهتر شدن، اغلب آنچه خوب است را خراب می‌کند.

— King Lear ۱.۴

جوک قدیمی (نسبتاً قدیمی) دربارهٔ شرکتی آمریکایی است که سفارش ۱۰۰٬۰۰۰ مدار مجتمع (integrated circuit) به سازندهٔ ژاپنی می‌دهد. بخشی از specification نرخ نقص بود: یک تراشه در ۱۰٬۰۰۰. چند هفته بعد سفارش رسید: یک جعبهٔ بزرگ حاوی هزاران IC و یک جعبهٔ کوچک با فقط ده تا. روی جعبهٔ کوچک برچسبی بود با این متن: «این‌ها معیوب‌ها هستند.»

کاش واقعاً چنین کنترلی بر کیفیت داشتیم. اما دنیای واقعی اجازه نمی‌دهد چیز زیادی واقعاً کامل تولید کنیم، به‌ویژه نرم‌افزار بدون باگ. زمان، فناوری و خلق‌وخو همه علیه ما توطئه می‌کنند.

با این حال، این لزوماً ناامیدکننده نیست. همان‌طور که Ed Yourdon در مقاله‌ای در IEEE Software [You95] توصیف کرد، می‌توانید خودتان را به نوشتن نرم‌افزاری که به‌اندازهٔ کافی خوب است — به‌اندازهٔ کافی برای کاربران، برای نگهدارندگان آینده، برای آرامش خاطر خودتان — وادار کنید. خواهید دید که productiveتر هستید و کاربران خوشحال‌ترند. و شاید بفهمید برنامه‌هایتان به‌خاطر دورهٔ کوتاه‌تر بلوغ واقعاً بهتر شده‌اند.

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

کاربران را در مصالحه دخیل کنید

معمولاً نرم‌افزار را برای دیگران می‌نویسید. اغلب یادتان می‌ماند requirements را از آن‌ها بگیرید.² اما چند وقت یک‌بار از آن‌ها می‌پرسید نرم‌افزارشان چقدر باید خوب باشد؟ گاهی انتخابی نخواهید داشت. اگر روی pacemaker، شاتل فضایی یا کتابخانهٔ سطح پایینی که گسترده منتشر می‌شود کار می‌کنید، requirements سخت‌گیرانه‌تر و گزینه‌هایتان محدودتر است. اما اگر روی محصول کاملاً جدید کار می‌کنید، محدودیت‌های متفاوتی دارید. بازاریابان وعده‌هایی داده‌اند، کاربران نهایی شاید بر اساس برنامهٔ تحویل برنامه‌ریزی کرده‌اند و شرکت شما قطعاً محدودیت cash-flow دارد. نادیده گرفتن requirements این کاربران فقط برای افزودن feature جدید به برنامه یا یک بار دیگر polish کردن کد، غیرحرفه‌ای است. ما از وحشت دفاع نمی‌کنیم: وعدهٔ بازه‌های زمانی غیرممکن و بریدن گوشه‌های مهندسی پایه برای رسیدن به deadline به همان اندازه غیرحرفه‌ای است.

² قرار بود شوخی باشد!

دامنه و کیفیت سیستمی که تولید می‌کنید باید بخشی از requirements آن سیستم مشخص شود.

TIP 7

کیفیت را یک مسئلهٔ نیازمندی کنید

اغلب در موقعیت‌هایی هستید که مصالحه در میان است. شگفت‌آور است که بسیاری از کاربران ترجیح می‌دهند امروز نرم‌افزاری با لبه‌های ناهموار داشته باشند تا یک سال برای نسخهٔ multimedia صبر کنند. بسیاری از بخش‌های IT با بودجهٔ تنگ موافقند. نرم‌افزار عالی امروز اغلب بر نرم‌افزار کامل فردا ترجیح دارد. اگر زود چیزی برای بازی دادن به کاربران بدهید، بازخوردشان اغلب به راه‌حل بهتر نهایی منجر می‌شود (بخش Tracer Bullets، صفحه ۴۸).

بدانید کی متوقف شوید

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

اما هنرمندان می‌گویند همهٔ زحمت اگر ندانید کی متوقف شوید خراب می‌شود. اگر لایه روی لایه، جزئیات روی جزئیات اضافه کنید، نقاشی در رنگ گم می‌شود.

یک برنامهٔ کاملاً خوب را با overembellishment و over-refinement خراب نکنید. جلو بروید و بگذارید کدتان مدتی به‌خودی‌خود بایستد. شاید کامل نباشد. نگران نباشید: هرگز کامل نمی‌توانست باشد. (در فصل ۶، صفحه ۱۷۱، دربارهٔ فلسفه‌های توسعهٔ کد در دنیای ناقص بحث می‌کنیم.)

بخش‌های مرتبط

• Tracer Bullets، صفحه ۴۸
• The Requirements Pit، صفحه ۲۰۲
• Pragmatic Teams، صفحه ۲۲۴
• Great Expectations، صفحه ۲۵۵

چالش‌ها

• به سازندگان ابزارهای نرم‌افزاری و سیستم‌عامل‌هایی که استفاده می‌کنید نگاه کنید. آیا شواهدی پیدا می‌کنید که این شرکت‌ها راحت نرم‌افزاری که می‌دانند کامل نیست ship می‌کنند؟ به‌عنوان کاربر، ترجیح می‌دهید (۱) صبر کنید تا همهٔ باگ‌ها برطرف شود، (۲) نرم‌افزار پیچیده داشته باشید و بعضی باگ‌ها را بپذیرید، یا (۳) نرم‌افزار ساده‌تر با نقص کمتر را انتخاب کنید؟

• اثر modularization بر تحویل نرم‌افزار را در نظر بگیرید. آیا رساندن یک بلوک monolithic به کیفیت مورد نیاز بیشتر طول می‌کشد یا سیستمی که به ماژول طراحی شده؟ آیا نمونه‌های تجاری پیدا می‌کنید؟

۵. سبد دانش شما

سرمایه‌گذاری در دانش همیشه بهترین سود را می‌دهد.

— Benjamin Franklin

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

در این مورد، اما، بن واقعاً به هدف زد. دانش و تجربهٔ شما مهم‌ترین دارایی حرفه‌ای‌تان هستند.

متأسفانه، آن‌ها دارایی‌های در حال انقضا (expiring assets) هستند.³ دانش شما با توسعهٔ تکنیک‌ها، زبان‌ها و محیط‌های جدید منقضی می‌شود. نیروهای بازار ممکن است تجربهٔ شما را obsolete یا نامربوط کند. با سرعتی که سال‌های وب می‌گذرند، این می‌تواند خیلی سریع اتفاق بیفتد.

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

³ دارایی در حال انقضا چیزی است که ارزشش با زمان کاهش می‌یابد. مثال‌ها شامل انبار پر از موز و بلیت یک مسابقهٔ ورزشی است.

سبد دانش شما

ما دوست داریم همهٔ حقایقی که برنامه‌نویسان دربارهٔ محاسبات می‌دانند، حوزه‌های کاربردی که در آن‌ها کار می‌کنند و تمام تجربه‌شان را سبد دانش (Knowledge Portfolio) آن‌ها بدانیم. مدیریت سبد دانش بسیار شبیه مدیریت سبد مالی است:

1. سرمایه‌گذاران جدی به‌طور منظم سرمایه‌گذاری می‌کنند — به‌عنوان عادت.
2. تنوع‌بخشی کلید موفقیت بلندمدت است.
3. سرمایه‌گذاران هوشمند سبد خود را بین سرمایه‌گذاری‌های محافظه‌کارانه و پرریسک با پاداش بالا متعادل می‌کنند.
4. سرمایه‌گذاران سعی می‌کنند ارزان بخرند و گران بفروشند برای حداکثر بازده.
5. سبدهای سرمایه‌گذاری باید به‌طور دوره‌ای بررسی و rebalancing شوند.

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

ساختن سبد خود

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

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

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

ارزان بخرید، گران بفروشید. یادگیری فناوری نوظهور قبل از محبوب شدن می‌تواند به‌سختی پیدا کردن سهام کم‌ارزش باشد، اما پاداش می‌تواند به همان اندازه باشد. یادگیری Java وقتی تازه آمد شاید پرریسک بود، اما برای early adopterهایی که الان در صدر آن حوزه‌اند سودآور بود.

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

از همهٔ این دستورالعمل‌ها، مهم‌ترینشان ساده‌ترین برای انجام است:

TIP 8

به‌طور منظم در سبد دانش خود سرمایه‌گذاری کنید

اهداف

حالا که دستورالعمل‌هایی دربارهٔ چه و کی به سبد دانش اضافه کنید دارید، بهترین راه برای کسب سرمایهٔ فکری برای تأمین سبد چیست؟ چند پیشنهاد:

• هر سال حداقل یک زبان جدید یاد بگیرید. زبان‌های مختلف همان مسائل را به روش‌های مختلف حل می‌کنند. با یادگیری چند رویکرد مختلف، می‌توانید تفکر را گسترش دهید و از گیر کردن در یک rut جلوگیری کنید. علاوه بر این، یادگیری زبان‌های زیاد الان آسان‌تر است، به‌لطف انبوه نرم‌افزار آزاد در اینترنت (صفحه ۲۶۷).

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

• کتاب‌های غیرفنی هم بخوانید. مهم است به یاد داشته باشید که کامپیوترها توسط مردم استفاده می‌شوند — مردمی که می‌خواهید نیازهایشان را برآورده کنید. جنبهٔ انسانی معادله را فراموش نکنید.

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

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

• با محیط‌های مختلف آزمایش کنید. اگر فقط در Windows کار کرده‌اید، در خانه با Unix بازی کنید (Linux آزاد برای این عالی است). اگر فقط از makefile و editor استفاده کرده‌اید، IDE امتحان کنید و برعکس.

• به‌روز بمانید. در مجلات تخصصی و سایر نشریات مشترک شوید (صفحه ۲۶۲ برای پیشنهادها). چند موردی انتخاب کنید که فناوری متفاوت از پروژهٔ فعلی‌تان را پوشش دهند.

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

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

مهم نیست آیا هرگز این فناوری‌ها را در پروژه استفاده می‌کنید، یا حتی در رزومه می‌گذارید. فرایند یادگیری تفکر شما را گسترش می‌دهد و شما را به امکانات و روش‌های جدید باز می‌کند. cross-pollination ایده‌ها مهم است؛ سعی کنید درس‌هایی که یاد گرفته‌اید را در پروژهٔ فعلی به کار ببرید. حتی اگر پروژه از آن فناوری استفاده نکند، شاید بتوانید ایده‌ای قرض بگیرید. با object orientation آشنا شوید، مثلاً، و برنامه‌های C ساده را متفاوت می‌نویسید.

فرصت‌های یادگیری

پس voraciously می‌خوانید، از آخرین تحولات حوزه‌تان باخبرید (کار آسانی نیست)، و کسی از شما سؤالی می‌پرسد. هیچ ایده‌ای ندارید پاسخ چیست و آزادانه اعتراف می‌کنید.

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

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

همهٔ این خواندن و تحقیق وقت می‌گیرد و وقت از قبل کم است. پس باید از قبل برنامه‌ریزی کنید. همیشه چیزی برای خواندن در لحظات مرده داشته باشید. وقت انتظار برای پزشک و دندانپزشک فرصت عالی برای جبران عقب‌ماندگی خواندنتان است — اما حتماً مجلهٔ خودتان را بیاورید، وگرنه ممکن است در حال ورق زدن مقالهٔ سگ‌خوردهٔ ۱۹۷۳ دربارهٔ پاپوآ گینهٔ نو باشید.

تفکر انتقادی

آخرین نکتهٔ مهم این است که آنچه می‌خوانید و می‌شنوید را با تفکر انتقادی بررسی کنید. باید مطمئن شوید دانش در سبد شما دقیق است و تحت تأثیر هیاهوی vendor یا رسانه قرار نگرفته. از zealotهایی که اصرار می‌کنند dogma آن‌ها تنها پاسخ است هشیار باشید — ممکن است به شما و پروژه‌تان مربوط باشد یا نباشد.

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

TIP 9

آنچه می‌خوانید و می‌شنوید را با نقد تحلیل کنید

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

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

مراقبت و پرورش Gurus

با پذیرش جهانی اینترنت، guruها ناگهان به اندازهٔ کلید Enter شما نزدیک‌اند. پس چگونه یکی پیدا کنید و چگونه کاری کنید با شما حرف بزند؟

چند ترفند ساده پیدا کرده‌ایم:

• دقیقاً بدانید چه می‌خواهید بپرسید و تا جایی که می‌توانید مشخص باشید.
• سؤال را با دقت و ادب قالب‌بندی کنید. به یاد داشته باشید که لطف می‌خواهید؛ طوری نباشید که انگار پاسخ را طلب می‌کنید.
• وقتی سؤال را قالب‌بندی کردید، توقف کنید و دوباره به دنبال پاسخ بگردید. چند keyword انتخاب کنید و در وب جستجو کنید. به دنبال FAQهای مناسب (فهرست سؤالات متداول با پاسخ) باشید.
• تصمیم بگیرید می‌خواهید عمومی یا خصوصی بپرسید. گروه‌های خبری Usenet مکان‌های عالی برای متخصصان تقریباً هر موضوعی هستند، اما بعضی از ماهیت عمومی این گروه‌ها می‌ترسند. در عوض، همیشه می‌توانید مستقیماً به guru ایمیل بزنید. در هر صورت، subject line معنادار استفاده کنید. («Need Help!!!» جواب نمی‌دهد.)
• بنشینید و صبور باشید. مردم مشغول‌اند و ممکن است چند روز طول بکشد تا پاسخ مشخصی بگیرید.

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

چالش‌ها

• این هفته یادگیری یک زبان جدید را شروع کنید. همیشه در C++ برنامه‌نویسی کرده‌اید؟ Smalltalk [URL 13] یا Squeak [URL 14] را امتحان کنید. Java می‌نویسید؟ Eiffel [URL 10] یا TOM [URL 15] را امتحان کنید. برای منابع دیگر کامپایلر و محیط آزاد صفحه ۲۶۷ را ببینید.

• شروع به خواندن یک کتاب جدید کنید (اما اول این را تمام کنید!). اگر implementation و coding بسیار جزئی انجام می‌دهید، کتابی دربارهٔ design و architecture بخوانید. اگر design سطح بالا انجام می‌دهید، کتابی دربارهٔ تکنیک‌های coding بخوانید.

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

۶. ارتباط برقرار کنید!

معتقدم بهتر است دیده شوی تا نادیده گرفته شوی.

— Mae West، Belle of the Nineties، ۱۹۳۴

شاید بتوانیم از خانم West درس بگیریم. فقط آنچه دارید مهم نیست، بسته‌بندی آن هم مهم است. داشتن بهترین ایده‌ها، بهترین کد یا عمل‌گراترین تفکر در نهایت بی‌ثمر است مگر بتوانید با دیگران ارتباط برقرار کنید. ایدهٔ خوب بدون ارتباط مؤثر یتیم است.

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

فهرستی از ایده‌هایی که مفید می‌یابیم جمع کرده‌ایم.

بدانید چه می‌خواهید بگویید

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

برنامه‌ریزی کنید چه می‌خواهید بگویید. outline بنویسید. بعد از خود بپرسید «آیا این هر چیزی که می‌خواهم بگویم را منتقل می‌کند؟» تا زمانی که بکند اصلاح کنید.

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

مخاطب خود را بشناسید

فقط وقتی ارتباط برقرار می‌کنید که اطلاعات منتقل می‌کنید. برای این کار باید نیازها، علایق و توانایی‌های مخاطب را بفهمید. همه در جلساتی نشسته‌ایم که یک geek توسعه با monologue طولانی دربارهٔ شایستگی‌های فناوری arcane چشمان معاون بازاریابی را خیره می‌کند. این ارتباط نیست: فقط حرف زدن است و آزاردهنده است.⁵

تصویر ذهنی قوی از مخاطب بسازید. آکروستیک WISDOM، نشان‌داده‌شده در شکل ۱.۱، ممکن است کمک کند:

WISDOM — درک مخاطب

• W — می‌خواهید چه چیزی یاد بگیرند؟ (What do you want them to learn?)
• I — علاقهٔ آن‌ها به آنچه می‌گویید چیست؟ (What is their interest in what you've got to say?)
• S — آن‌ها چقدر پیچیده / حرفه‌ای هستند؟ (How sophisticated are they?)
• D — چقدر جزئیات می‌خواهند؟ (How much detail do they want?)
• O — می‌خواهید مالکیت اطلاعات در دست چه کسی باشد؟ (Whom do you want to own the information?)
• M — چگونه می‌توانید آن‌ها را به گوش دادن به شما تشویق کنید؟ (How can you motivate them to listen to you?)

فرض کنید می‌خواهید سیستم مبتنی بر وب پیشنهاد دهید تا end userها بتوانند گزارش باگ ارسال کنند. می‌توانید این سیستم را به روش‌های مختلف بسته به مخاطب ارائه دهید. end userها قدردانی می‌کنند که می‌توانند ۲۴ ساعته گزارش باگ بفرستند بدون انتظار تلفنی. بخش بازاریابی می‌تواند از این واقعیت برای افزایش فروش استفاده کند. مدیران بخش پشتیبانی دو دلیل برای خوشحالی دارند: به کارکنان کمتری نیاز است و گزارش مشکل خودکار می‌شود. سرانجام، developerها شاید از کسب تجربه با فناوری‌های Web-based client-server و موتور پایگاه دادهٔ جدید لذت ببرند. با ارائهٔ pitch مناسب به هر گروه، همه را برای پروژه‌تان هیجان‌زده می‌کنید.

⁵ کلمهٔ annoy از enui فرانسوی باستان می‌آید که به معنای «خسته کردن» هم هست.

لحظهٔ مناسب را انتخاب کنید

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

به‌عنوان بخشی از فهمیدن آنچه مخاطب باید بشنود، باید اولویت‌هایش را مشخص کنید. مدیر را بگیرید که رئیسش به‌خاطر گم شدن کد منبع سخت‌گیری کرده — شنوندهٔ پذیراتری برای ایده‌هایتان دربارهٔ repositoryهای کد منبع خواهید داشت. آنچه می‌گویید را در زمان و همچنین در محتوا مرتبط کنید. گاهی فقط سؤال سادهٔ «آیا وقت خوبی است برای صحبت دربارهٔ ...؟» کافی است.

سبک را انتخاب کنید

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

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

خوب به نظر برسد

ایده‌های شما مهم‌اند. شایستهٔ وسیلهٔ خوش‌ظاهری هستند که آن‌ها را به مخاطب منتقل کند.

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

امروز بهانه‌ای برای تولید اسناد چاپی بی‌کیفیت نیست. word processorهای مدرن (همراه سیستم‌های layout مثل LATEX و troff) خروجی خیره‌کننده تولید می‌کنند. فقط چند دستور پایه باید یاد بگیرید. اگر word processor از style sheet پشتیبانی می‌کند، استفاده کنید. (شرکت شما شاید style sheet تعریف‌شده داشته باشد.) یاد بگیرید header و footer صفحه تنظیم کنید. به اسناد نمونهٔ همراه بسته نگاه کنید تا ایده برای سبک و layout بگیرید. املا را بررسی کنید، اول خودکار و بعد دستی. بعد از همه، اشتباهات املایی هست که spell checker نمی‌تواند بگیرد.

مخاطب را دخیل کنید

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

شنونده باشید

یک تکنیک هست که اگر می‌خواهید مردم به شما گوش دهند باید استفاده کنید: به آن‌ها گوش دهید. حتی اگر وضعیتی است که همهٔ اطلاعات را دارید، حتی اگر جلسهٔ رسمی است و ۲۰ نفر با کت و شلوار جلویتان ایستاده‌اند — اگر به آن‌ها گوش ندهید، آن‌ها به شما گوش نمی‌دهند.

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

به مردم پاسخ دهید

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

TIP 10

هم آنچه می‌گویید مهم است و هم نحوهٔ گفتنش

مگر در خلأ کار کنید، باید بتوانید ارتباط برقرار کنید. هر چه آن ارتباط مؤثرتر باشد، تأثیرگذارتر می‌شوید.

ارتباط ایمیلی

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

• قبل از زدن SEND بازخوانی کنید.
• املا را بررسی کنید.
• format را ساده نگه دارید. بعضی ایمیل را با فونت proportional می‌خوانند، پس تصاویر ASCII art که با زحمت ساختید برایشان مثل خط‌خطی مرغ به نظر می‌رسد.
• از ایمیل rich-text یا HTML فقط وقتی استفاده کنید که می‌دانید همهٔ گیرندگان می‌توانند بخوانند. plain text جهانی است.
• quoting را تا حد امکان کم نگه دارید. کسی دوست ندارد ایمیل ۱۰۰ خطی خودش را با «موافقم» برگردانده ببیند.
• اگر ایمیل دیگران را quote می‌کنید، حتماً منبع را ذکر کنید و inline quote کنید (نه به‌عنوان attachment).
• flame نکنید مگر بخواهید بعداً به شما برگردد و آزار دهد.
• فهرست گیرندگان را قبل از ارسال بررسی کنید. مقالهٔ اخیر Wall Street Journal کارمندی را توصیف کرد که شروع به توزیع انتقادات از رئیسش از طریق ایمیل بخشی کرد، بدون اینکه بداند رئیس در لیست توزیع بود.
• ایمیل را archive و سازماندهی کنید — هم چیزهای مهم که دریافت می‌کنید و هم ایمیلی که می‌فرستید.

همان‌طور که کارمندان مختلف Microsoft و Netscape در تحقیقات وزارت دادستی ۱۹۹۹ کشف کردند، ایمیل برای همیشه است. سعی کنید به ایمیل همان توجه و دقتی را بدهید که به هر memo یا گزارش نوشته‌شده می‌دهید.

خلاصه

• بدانید چه می‌خواهید بگویید.
• مخاطب خود را بشناسید.
• لحظهٔ مناسب را انتخاب کنید.
• سبک را انتخاب کنید.
• خوب به نظر برسد.
• مخاطب را دخیل کنید.
• شنونده باشید.
• به مردم پاسخ دهید.

بخش‌های مرتبط

• Prototypes and Post-it Notes، صفحه ۵۳
• Pragmatic Teams، صفحه ۲۲۴

چالش‌ها

• چند کتاب خوب بخش‌هایی دربارهٔ ارتباط در تیم‌های توسعه دارند [Bro95, McC95, DL99]. تصمیم بگیرید در ۱۸ ماه آینده هر سه را بخوانید. علاوه بر این، کتاب Dinosaur Brains [Ber96] دربارهٔ بار عاطفی که همه به محیط کار می‌آوریم بحث می‌کند.

• دفعهٔ بعد که باید presentation بدهید یا memoای برای دفاع از موضعی بنویسید، قبل از شروع آکروستیک WISDOM (صفحه ۲۰) را مرور کنید. ببینید آیا کمک می‌کند بفهمید چگونه آنچه می‌گویید را موقعیت‌دهی کنید. در صورت مناسب بودن، بعداً با مخاطب صحبت کنید و ببینید ارزیابی نیازهایشان چقدر دقیق بود.