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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



بهزاد مرادی