هفت عادت دولوپرهای مؤثر

Stephen Covey مدرس، نویسنده و سخنران آمریکایی است که در مدت حیات خود، کتاب‌های زیادی را به رشتهٔ تحریر درآورد اما بیش از هر چیزی وی را به خاطر کتاب پرفروش The Seven Habits of Highly Effective People (هفت عادت مردمان مؤثر) می‌شناسند که در مورد مهارت‌های زندگی است به طوری که با پیاده‌سازی هفت عادت معرفی شده در این کتاب، خواننده فارغ از اینکه چه خصوصیاتی دارا است و یا به چه حرفه‌ای مشغول است، می‌تواند کیفیت زندگی شخصی/کاری خود را بهبود بخشد. حال با الهام گرفتن از عنوان و محتوای این کتاب، در این مقاله قصد داریم به بررسی هفت عادت دولوپرهای مؤثر بپردازیم!

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

1. Be Proactive
2. Begin with The End in The Mind
3. Put First Things First
4. Think Win/Win
5. Seek First to Understand, Then to Be Understood
6. Synergize
7. Sharpen The Saw

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

1. Be Proactive

Proactive نقطهٔ مقابل Reactive بودن است. به عبارت دیگر، این اصطلاح به معنی منفعل نبودن است بدین معنا که این شرایط بیرونی نیست که روی سرنوشت ما تأثیر می‌گذارد بلکه این ما هستیم که کنترل شرایط را در دست می‌گیریم.

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

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

تجربه نشان داده است که دولوپرهای منفعل معمولاً به سمت انجام کارهای یَدی سوق داده می‌شوند! حال ممکن است این سؤال پیش بیاید که در صنعت توسعهٔ نرم‌افزار که کاری کاملاً منطقی و الگوریتمیک است، برچسب یَدی را بر روی چه کارهایی می‌توان زد؟ در پاسخ به این سؤال باید گفت که همواره یکسری پروژه‌ها هستند که نیاز به خلاقیت چندانی ندارند، با سرهم کردن ماژول‌هایی از دیگر پروژه‌ها قابل پیاده‌سازی بوده و در یک کلام اصطلاحاً Challenging نیستند که به نوعی می‌توان این دست کارها را یَدی قلمداد کرد!

2. Begin with The End in The Mind

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

برخی دولوپرها هستند که به محض اینکه پروژه‌ای به ایشان محول می‌شود، دست به کد می‌شوند که این کار اساساً اشتباه است. به نوعی می‌توان گفت که بر اساس قانون هشتاد/بیست، ما باید پیش از کدنویسی پروژهٔ خود حدوداً ۸۰٪ فکر کنیم و زمان روی تحلیل و معماری نرم‌افزار اختصاص دهیم و در نهایت تقریباً ۲۰٪ از زمان را کد بزنیم (برای آشنایی بیشتر با این قانون، به مقالهٔ قانون ۸۰/۲۰ (اصل پارِتو) چیست؟ مراجعه نمایید).

واقعیت امر آن است که خیلی از ما دولوپرها فقط نیازهای جاری (در لحظهٔ) یک پروژه را در نظر می‌گیریم و این در صورتی است که چنانچه نرم‌افزار مد نظر بخواهد در آینده توسعه یابد، با مشکلات عدیده‌ای مواجه خواهد شد و این صرفاً بدین دلیل است که ابتدا به ساکن تحلیل درستی از نیازهای آتی (The End) نداشته‌ایم و اینجا است که پای مفهومی تحت عنوان تفکر طراحی به میان می‌آید که توصیه می‌کنیم برای آشنایی بیشتر با این مفهوم، به مقالهٔ تفکر طراحی (Design Thinking) چیست؟ مراجعه نمایید که در آن به تفصیل پیرامون این موضوع بحث شده است.

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

3. Put First Things First

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

به طور مثال، فرض کنیم که دولوپر تازه‌کاری هستیم و درصدد می‌باشیم تا هرچه سریع‌تر وارد بازار کار شویم اما دغدغه‌ای داریم بدین صورت که دوست داریم به معنای واقعی کلمه به یک دولوپر فول‌استک تبدیل شویم (برای آشنایی بیشتر با این اصطلاح، به مقالهٔ معنی و مفهوم Full Stack Developer چیست؟ مراجعه نمایید). قبل از اینکه ASP.NET را کامل یاد بگیریم، به سراغ Python می‌رویم و هم‌زمان شروع به یادگیری Angular.js می‌کنیم و در عین حال خیلی هم تمایل داریم تا کمی در مورد شبکه هم اطلاعاتی کسب کنیم!

پیش از این گفتیم که باید قدرت نَه گفتن را هم بیاموزیم اما نکته اینجا است که بیش از اینکه روی نَه گفتن به سایرین کار کنیم، باید این توانایی را کسب کنیم تا به وسوسه‌های ذهنی خودمان نَه بگوییم. شکی به دل راه ندهید که با لیست کردن نام ده الی دوازده زبان برنامه‌نویسی، فریمورک و تکنولوژی مختلف، هرگز نمی‌توانیم از یک مدیر HR دلبری کنیم! به عبارت دیگر، اکثر شرکت‌های حرفه‌ای اصلاً تمایلی به استخدام فردی که مهارت‌هایی به وسعت یک اقیانوس اما عمق یک سانتی‌متر دارد نداشته اما در عین حال شرکت‌های کمتر حرفه‌ای به دنبال این دست افراد می‌گردند (برای آشنایی بیشتر با نحوهٔ نوشتن رزومه، به مقالهٔ چگونه یک روزمهٔ خوب به عنوان برنامه‌نویس یا توسعه‌دهنده بنویسیم؟ مراجعه نمایید).

در یک کلام، عادت Put First Things First را این‌گونه می‌توان تفسیر کرد که با در نظر گرفتن کلیهٔ متغیرهایی که متضمن موفقیت شغلی‌مان هستند، باید تک‌تک ثانیه‌های کاری خود را اولویت‌بندی کرده و آن‌ها را صرف چیزهایی کنیم که ما را به هدفمان (ولو یک سانتی‌متر) نزدیک‌تر می‌کنند.

4. Think Win/Win

به طور کلی، ما در تعاملات اجتماعی خود دو رویکرد مختلف را می‌توانیم اتخاذ کنیم: 
- برد-باخت  
- برد-برد

در رویکرد اول (برد-باخت)، افراد هر کاری را به عنوان نوعی رقابت تلقی می‌کنند و نیاز به توضیح نیست که احتمال موفقیت برای کسانی که چنین رویکردی را در پیش می‌گیرند همواره ۵۰٪ است اما این در حالی است که اگر استراتژی Win-Win را در نظر داشته باشیم، احتمال موفقیت ما دوچندان خواهد شد (این عادت با عادت ششم یا همان Synergize ارتباط مستقیمی دارد که در ادامه بیشتر پیرامون این موضوع بحث خواهیم کرد).

Agile چیزی است که مفهوم برد-برد در دلش گنجانده شده است (برای کسب‌ اطلاعات بیشتر، به آموزش معرفی مانیفست اجایل مراجعه نمایید). اگر بخواهیم نگاهی اجمالی به فلسفهٔ اجایل داشته باشیم، به این نتیجه می‌رسیم که در تعامل با تک‌تک اعضای تیم و مهم‌تر از آن مشتریان، خوشحالی ایشان بیش از هرچیز حائز اهمیت است که این رضایتمندی صرفاً با ارائهٔ محصولی ۹۹٪ نزدیک به نیازهای ایشان امکان‌پذیر است. 

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

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

5. Seek First to Understand, Then to Be Understood

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

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

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

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

6. Synergize

به گفتهٔ ارسطو، کل بزرگتر از جمع اجزایش است (.The Whole Is Greater Than The Sum of Its Parts)؛ به عبارت دیگر، تأثیرگذاری عملکرد یک تیم به مراتب بیش از جمع جبری میزان تأثیرگذاری اقدامات تک‌تک اعضا است. اگر همان‌طور که در آیتم چهارم توضیح داده شد، از تفکری برد-برد برخوردار باشیم، به راحتی قادر به Synergize (هم‌افزایی) خواهیم بود.

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

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

7. Sharpen The Saw

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

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

فرض کنیم دولوپری هستیم که تاکنون با نسخهٔ 5.6 زبان PHP کد می‌زده‌ایم اما علیرغم اینکه نسخهٔ ۷ این زبان به ثبات کافی رسیده است، به خود زحمت مهاجرت به این نسخه را نمی‌دهیم غافل از اینکه سرعت وب اپلیکیشن‌های نوشته شده با این نسخه به مراتب بیش از گذشته است؛ و یا فرض کنیم دولوپر فرانت‌اندی هستیم که تاکنون از لایبرری jQuery استفاده می‌کرده‌ایم و به قول معروف کارمان راه می‌افتاده است اما کماکان علاقه‌ای به رفتن به سمت رقبای جدیدتری همچون React یا Angular.js نداریم!

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

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

کلام آخر
آنچه در این مقاله مورد بحث و بررسی قرار دادیم، اقتباسی بود از کتاب پرفروش هفت عادت مردمان مؤثر که در سال ۱۹۸۹ توسط استفان کُوی تألیف شده و تاکنون به بیش از ۴۰ زبان زندهٔ دنیا -من‌جمله فارسی- ترجمه شده است. باتوجه به اینکه عمده مخاطبین ما را برنامه‌نویسان، دولوپرها، طراحان سایت، وب مسترها و دیگر فعالان حوزهٔ آی‌تی تشکیل می‌دهند، سعی شد تا این هفت عادت کاربردی را با حال و هوای حرفه‌ٔ توسعهٔ نرم‌افزار ریفکتور کنیم.

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