درس‌هایی که دولوپرها می‌توانند از حضور در بیمارستان بگیرند!

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

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

وقتی در اورژانس در بلندگو کد ۹۹ اعلام می‌شود، این بدان معنا است که یک نفر ایست قلبی کرده و تقریباً می‌شود گفت که کارش تمام است. به‌ محض اعلام این کد، می‌بینیم که از پرستار گرفته تا سرپرستار، خدمه، رزیدنت‌ها و پزشکان به‌ سمت تخت بیمار هجوم برده و تمام تلاش خود را به‌ کار می‌گیرند تا بلکه بتوانند ایشان را احیا کرده و به دنیا باز گردانند (به‌ تعبیری، مجدد تجربهٔ‌ زندگی در مملکتی فلاکت‌بار، سرشار از فقر، فساد،‌ فحشا، دروغ، دزدی، اختلاس و … را برای فردی که دعوت حق را لبیک گفته بود، رقم بزنند!)

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

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

مسئولیت‌پذیری
وقتی پای جان یا سلامتی فردی به‌ میان می‌آید، سایر افراد ناخودآگاه مسئولیت‌پذیرتر می‌شوند و این قضیه به‌ خوبی در تیم‌های پزشکی مشهود است؛ مثلاً وقتی که شیفت پرستاری عوض می‌شود و خانم پرستار شیفت بعدی می‌بیند به هر دلیلی، خواه خواب‌آلودی و خواه هر چیزی دیگری، کاری به درستی انجام نشده (مثلاً آنژیوکتی بایستی عوض می‌شده که نشده و مثال‌هایی از این دست)، وی وظیفهٔ خود می‌داند که مشکل را برطرف کند و این همان چیزی که اکثر دولوپرها در آن ضعف دارند!

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

تغییر شیفت و انتقال بیمار از پرستاری به پرستار دیگر
در بیمارستان، معمولاً ساعت ۷ الی ۸ صبح شیفت کاری عوض می‌شود و این در حالی است که این به‌ اصطلاح Shift Change برای یک دولوپر حاوی کلی درس کاربردی است. در واقع، سرپرستار شیفت قبلی به‌ همراه سرپرستار شیفت جدید به‌‌ علاوهٔ کل تیم پرستاری جدید سر تخت تک‌تک بیماران حاضر شده و نکات، مشاهدات، مشکلات و به‌ طور‌ کلی هر چیزی که مربوط به بیمار می‌شود به‌ صورت شفاهی برای اعضای شیفت جدید توضیح داده می‌شود و ایشان هم نُت‌برداری می‌کنند و این در حالی است که اگر این‌ کار به‌ درستی صورت گیرد، پس از Shift Change گویی فقط قیافهٔ‌ تیم پزشکی عوض شده و در ارتباط با دیتای مرتبط با بیماران، بدون کم‌وکاستی اطلاعات به تیم جدید منتقل شده است (البته این قضیه ۱۰۰٪ نیست و این احتمال وجود دارد که قصوری هم در این رابطه صورت گیرد.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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