پیشگفتار
در همین لحظه، در جایی از جهان، یک توسعهدهندهی نرمافزار در حالِ باز کردنِ یک تیکت از لیستِ وظایفِ پروژه است، و از اینکه میخواهد روی موضوعِ جدیدی کار کند هیجانزده است. اما وقتی شروع به خواندنِ توضیحاتِ وظیفه میکند، ناگهان لپتاپش پر از اعلانهای سیستمِ ردیابیِ خطاهای عملیاتی میشود و تمرکزش به هم میریزد. سرانجام، پس از بازگشت به وظیفهی اصلی، توسعهدهنده به بررسیِ نیازمندیهای ذکرشده در تیکت میپردازد. متأسفانه، وظیفه فاقدِ زمینه و وضوحِ کافی است و مجبور میشود درخواستِ کمک کند، درخواستی که چندین روز طول میکشد تا پاسخ داده شود. در همین حین، توسعهدهنده وظیفهی قبلیاش را بررسی میکند که برای چندین روز در صفِ انتظار برای تأیید مانده است. تستها و buildها مرتباً دچار مشکل میشوند و هر بار تلاشِ reviewerها برای تأیید تغییرات را متوقف میکنند. وقتی توسعهدهنده از وظیفهای به وظیفهی دیگر میرود و امید دارد بالاخره غرق در کارِ عمیق شود، متوجه میشود که تجربهی امروز آنطور که باید نیست تا بهترین عملکرد را از او بگیرد.
برای بسیاری از توسعهدهندگانِ حرفهایِ نرمافزار، این داستان بیش از حد شبیه به روزمرگیهای آنهاست. اصطکاک فراوان است، چرخهی توسعه پر از موانعِ بوروکراتیک است، و تحویلِ موفقِ کد به عملیاتی به رویدادی تبدیل شده است که بهندرت اتفاق میافتد. حتی بدتر از این، مشکلات همچنان روی هم انباشته میشوند. توسعهدهندگان ناامیدانه شاهد این هستند که مدیرانِ ارشد دخالتی نمیکنند، و این موضوع منجر به توقفِ سرعتِ توسعه و ترکِ بهترین مهندسانِ تیم میشود.
چگونه است که سازمانها به این وضعیت میافتند؟
امروزه، تجربهی توسعهدهنده (DevEx) توجهِ بیشتری را در بسیاری از سازمانهای نرمافزاری به خود جلب کرده است، چرا که رهبران به دنبالِ بهینهسازیِ تحویلِ نرمافزار در پسزمینهی محدودیتهای مالی و فناوریهای تحولآفرینی مانند هوش مصنوعی هستند. به صورتِ شهودی، در میانِ رهبرانِ فنی این پذیرش وجود دارد که تجربهی خوبِ توسعهدهنده به تحویلِ مؤثرتر نرمافزار و خوشحالیِ توسعهدهندهها منجر میشود. با این حال، در بسیاری از سازمانها، پیشنهادات و سرمایهگذاریها برای بهبودِ تجربهی توسعهدهنده در جلبِ حمایت شکست میخورند، زیرا ذینفعانِ تجاری ارزشِ این بهبودها را زیر سؤال میبرند. بسیاری از آنها میپرسند “تجربهی توسعهدهنده چیست؟” و “چرا مهم است؟”
چرا تجربهی توسعهدهنده (DevEx) مهم است؟
تجربهی توسعهدهنده شامل احساس، تفکر، و ارزشگذاریِ توسعهدهندگان نسبت به کارشان میشود. اما چرا این موضوع اهمیت دارد؟
اول از همه، توسعهدهندگان هر روز نرمافزار میسازند و از سیستمهای مهندسی استفاده میکنند، بنابراین بهترین جایگاه را برای ارائهی دیدگاههای انتقادی دربارهی کاراییِ سیستمها و فرآیندها دارند. به عنوان مثال، آیا نوشتنِ کد و تحویلِ آن به مشتریان، ساده است؟ یا فرآیندی پیچیده و پُر از مراحلِ دستی است که مستعدِ اشتباه و قطعی است؟ البته میتوان گفت در هر دو حالت، توسعهدهندگان در حالِ نوشتن کد و تحویل نرمافزار هستند، اما محیط و شرایط، تفاوتِ بسیاری دارد و میتواند نشانگرِ کیفیت، قابلیتِ اطمینان، نگهداریپذیری، و حتی امنیت سیستمها باشد.
تجربهی توسعهدهنده به دلیلِ تأثیراتی که بر توسعه میگذارد نیز مهم است.
این نکته شاید بدیهی به نظر برسد، چرا که بسیاری از سازمانها در سراسرِ جهان – از استارتاپها و شرکتهای غیرانتفاعی گرفته تا شرکتهای بزرگ – توسعهدهندگان را برای نوشتنِ نرمافزار برای مشتریان، بهبودِ ابزارهای داخلی، یا خودکارسازیِ فرآیندهای پیچیده استخدام میکنند. اما تفاوتِ بزرگی بین صرفاً نوشتن کد و نوشتن کد در محیطی که برای این کار بهینه شده، وجود دارد.
محیطهای بهینه برای نوشتنِ کد، کارآمد، مؤثر، و مناسب برای رفاهِ توسعهدهنده هستند و بر ترکیب مناسبی از ابزارها، شیوهها، فرآیندها، و ساختارهای اجتماعی تکیه میکنند. این محیطها به توسعهدهندگان کمک میکنند:
- به جریانِ کاری (Flow) وارد شوند و وقفهها را به حداقل برسانند تا بتوانند تمرکز کرده و مسائلِ پیچیده را حل کنند.
- ارتباطات و همکاریها را تقویت کنند تا آنها و تیمهایشان در مواقعِ ضروری خلاقیت داشته باشند.
- بازخوردهای باکیفیت دریافت کنند تا پیشرفت کنند.
با این نگاه، مشخص میشود که توسعهی نرمافزار فقط به نوشتنِ کد محدود نیست؛ بلکه یک فرآیندِ اجتماعی-فنی است که هم به کارِ توسعهدهندگان کمک میکند و هم به عملکردِ تیمها، مأموریتهای سازمانی، و فرهنگِ آنها میافزاید.
اگرچه تحقیقاتِ تجربیِ خاصی درباره تأثیراتِ DevEx وجود ندارد، اما نیاز به مطالعهی نتایجِ کارِ توسعهدهندگان و طراحیِ کاری که از آن پشتیبانی میکند کاملاً احساس میشود.
هدفِ این تحقیق پاسخ به این سؤال است: تجربهی توسعهدهنده چگونه بر توسعهدهندگانِ فردی، تیمهای آنها، و سازمانها تأثیر میگذارد؟
پاسخ کوتاه: بهبودِ تجربهی توسعهدهنده نتایجِ مثبتی به همراه دارد – و نه فقط برای توسعهدهندگان. این به بهبودِ عملکردِ تیمها و سازمانها نیز کمک میکند. به عنوانِ مثال، تجربهی بهترِ توسعهدهنده میتواند بهرهوری، یادگیری، نوآوری، و سودآوری را بهبود بخشد – و مواردِ دیگر. برای جزئیاتِ بیشتر ادامهی متن را بخوانید، یا اگر عجله دارید، مستقیماً به بخش «تحلیل و بحث» مراجعه کنید.
تجربهی توسعهدهنده بهعنوانِ طراحیِ کار
تحقیقات ما بر اساس نظریهی طراحیِ کار (WDT: Work Design Theory) انجام شده است و دو دلیلِ اصلی برای این انتخاب داریم:
در نظر گرفتنِ نتایجِ چندبُعدیِ کار
نظریهی طراحی کار نتایجِ حاصل از کار را در ابعادِ مختلف بررسی میکند. تحقیقات در این حوزه نشان دادهاند که کارکردها و تأثیراتِ مهمی برای افراد (مانند کاهشِ فرسودگیِ شغلی)، تیمها (مانند بهبودِ تحویلِ نرمافزار)، سازمانها (مانند بهبودِ معیارهای مشتری و سازمانی)، و حتی جامعه وجود دارد. تحقیقاتِ پیشین ما نیز نشان دادهاند که با بهبودِ محیطِ کار و طراحیِ کارِ توسعهدهندگان، نتایج عملکردی در سطحِ فردی، تیمی و سازمانی بهتر میشود.پیچیدگیِ مفهومیِ مناسب برای درکِ کارِ توسعهدهندگان
نظریهی طراحیِ کار، کار را بهعنوان هم یک شغلِ محولشده (یعنی مجموعهای از وظایف که بهصورتِ رسمی به یک فرد واگذار شدهاند) و هم بهعنوانِ “فعالیتهای ظهوریافته، اجتماعی و گاهی خودانگیخته” در نظر میگیرد. کارِ توسعهدهندگانِ نرمافزار شاملِ وظایفِ محولشده (مانند مواردی که در طیِ یک اسپرینت تعیین میشوند) و فعالیتهای ظهوریافته است (مانند کارِ واکنشی برای رفع اشکالات، کارِ خلاقانهی خودجوش، و فعالیتهای اجتماعی برای همکاری و بهبودِ فرآیندها).
اهدافِ این تحقیق با استفاده از نظریهی طراحی کار عبارتند از:
- گسترشِ تحقیقاتِ قبلی برای بررسیِ نتایج گستردهتر در سطوحِ فردی، تیمی، و سازمانی.
- بررسیِ طراحیِ کارِ توسعهدهندگان، با تمرکز بر تجربهی توسعهدهنده (DevEx)، که تأثیرِ مثبتی بر این نتایج دارد.
این رویکرد به ما اجازه میدهد تا علاوه بر شناختِ بهترِ کارِ توسعهدهندگان، راهکارهایی را برای بهبودِ محیط و طراحیِ کار پیشنهاد کنیم که منجر به نتایجِ بهتری برای افراد، تیمها، و سازمانها شود.
نتایج (outcomes)
وقتی به نتایجِ کارِ توسعه یا تجربهی توسعهدهنده فکر میکنیم، بسیاری از محققان و افراد بهرهوری را مدنظر قرار میدهند. با این حال، بر اساسِ سالها تجربه، ما مشاهده کردهایم که بهبود در کار توسعهدهندگان بسیار فراتر از بهرهوریِ شخصیِ افراد است و نتایجِ تیمی و سازمانی را نیز شامل میشود.
این تحقیق نتایج را در سه سطح توسعهدهنده، تیم و سازمان بررسی میکند که این رویکرد توسط نظریهی طراحیِ کار (WDT) نیز پشتیبانی میشود.
نتایجِ توسعهدهنده
نتایجِ توسعهدهنده آنهایی هستند که به نفع یک توسعهدهندهی فردی هستند. بهطورِ خاص، تحقیقاتِ قبلی در زمینهی نظریهی طراحیِ کار (WDT) نشان دادهاند که بهبود طراحیِ کار تأثیرِ مثبتی بر عملکردِ شغلی، خلاقیت، و یادگیری دارد—سه نتیجهای که در این مطالعه مورد بررسی قرار گرفتهاند.
نتایجِ تیمی
نتایجِ تیمی آن دسته از نتایجی هستند که ممکن است به یک توسعهدهندهی فردی کمک کنند، اما احتمالِ بیشتری دارد که در سطحِ تیم نمود پیدا کنند و به همین دلیل در این سطح بررسی و مطالعه میشوند. WDT همچنین نشان داده است که نتایجی مانندِ کیفیت، به تیمها سود میرسانند. در زمینهی تجربهی توسعهدهنده (DevEx)، ما به این موضوع میپردازیم که چگونه طراحیِ کار میتواند بر کیفیتِ سیستمی که تیم در آن کار میکند تأثیر بگذارد و این موضوع را بهصورتِ کیفیتِ کد و بدهیِ فنی بررسی میکنیم.
نتایجِ سازمانی
نتایجِ سازمانی به کارفرمای یک نیرو سود میرسانند. درحالیکه نتایج توسعهدهنده و تیمی به احتمالِ زیاد به نفعِ سازمان نیز هستند، بررسیِ تأثیرات بهبودهای کاری که بهطورِ خاص به سازمان مرتبط هستند، همچنان اهمیت دارد. این بررسی میتواند رابطهی DevEx با مأموریتِ سازمان را نشان دهد، ارزش DevEx را برای سازمان توضیح دهد، و شواهدی ارائه دهد که به توجیه و حمایت از سرمایهگذاری در ابتکارات DevEx کمک کند. درواقع، تحقیقاتِ قبلی در زمینهی WDT نشان دادهاند که بهبودِ طراحیِ کار بر سازمانها تأثیر میگذارد. بسیاری از این نتایج برای رهبران تجاری از اهمیتِ بالایی برخوردارند، از جمله حفظِ نیروها و نوآوری. تحقیقاتِ قبلی همچنین نشان دادهاند که بهبودِ کارِ توسعهدهندگان بهطورِ مثبت بر سودآوری و تواناییِ سازمان برای دستیابی به اهداف تأثیر میگذارد. این معیارهای نتایج سازمانی—حفظِ نیروها، نوآوری، سودآوری، و تواناییِ دستیابی به اهداف—در این مطالعه اندازهگیری شدهاند.
تجربهی توسعهدهنده
بر اساسِ تحقیقاتِ قبلیِ ما، در اینجا مدلی برای درک و اندازهگیری تجربهی توسعهدهنده (DevEx) ارائه میشود که شاملِ سه بُعد است که تأثیرِ آنها بر تجربهی توسعهدهنده شناسایی شده است: حالتِ جریان (Flow State)، حلقههای بازخورد (Feedback Loops)، و بارِ شناختی (Cognitive Load). این بخش هر یک از این ابعاد را تعریف کرده و توضیح میدهد که چگونه توسط نظریهی طراحی کار (WDT) پشتیبانی میشوند. فرضیات بهصورت Hn نمایش داده شدهاند، به این معنا که H1، H2، یا H3 نشاندهندهی فرضیهای است که در این تحقیق مورد آزمون قرار گرفته است.
حالتِ جریان
حالتِ جریان، که اغلب بهعنوان “در لحظه بودن” یا “در منطقه بودن” توصیف میشود، یک وضعیتِ ذهنی است که در آن فرد به طورِ کامل در کارِ خود غرق شده و احساسِ تمرکزِ پرانرژی، مشارکتِ کامل و لذت را تجربه میکند. دستیابی به حالتِ جریان و حمایت از آن از طریق تنظیماتِ محیطی (مثلاً اتاقهای ساکت)، ابزارها (مثلاً حالتِ تمرکز در ابزارها)، و روشهای فردی یا تیمی (مثلاً تعیین بازههای زمانی برای کارِ عمیق) امکانپذیر است. به همین ترتیب، تحقیقاتِ قبلی در زمینهی WDT نشان دادهاند که کارِ نوآورانه و جنبههای محیطِ کاری که تمرکز را تسهیل میکنند (مانند انعطاف در زمانبندی و محیطهای کاری عاری از صدا) بر نتایجِ مرتبط با کار تأثیر میگذارند.
ما حالتِ جریان را از طریقِ این معیارها اندازهگیری میکنیم:
- رضایت از مقدار زمانی که به کارِ عمیق اختصاص داده میشود.
- فرکانسِ وقفهها (interruptions).
- میزانِ جذابیتِ وظایف برای توسعهدهنده.
بر اساسِ تحقیقاتِ قبلی در زمینهی توسعهدهندگان و WDT، ما فرض میکنیم که حالتِ جریان نتایجِ مثبتی در زمینهی توسعهدهندگان دارد و این نتایج در سه سطح ظاهر میشوند: توسعهدهنده، تیم، و سازمان. بهطور رسمی بیان میشود:
H1 – حالتِ جریان تأثیر مثبتی بر نتایجِ (الف) توسعهدهنده، (ب) تیم، و (ج) سازمان دارد.
برای وضوحِ بیشتر، این فرضیه به شرح زیر گسترش مییابد:
- فرضیه 1a: حالتِ جریان تأثیرِ مثبتی بر نتایجِ توسعهدهنده دارد.
- فرضیه 1b: حالتِ جریان تأثیرِ مثبتی بر نتایجِ تیمی دارد.
- فرضیه 1c: حالتِ جریان تأثیرِ مثبتی بر نتایجِ سازمانی دارد.
فرضیاتِ بعدی از همان نمادگذاری و ساختارِ مشابه پیروی میکنند.
حلقههای بازخورد
حلقهی بازخورد زمانی رخ میدهد که بخشی از سیستم بهعنوانِ ورودی برای بخشِ دیگری از همان سیستم استفاده شود. در زمینهی کار و توسعهی نرمافزار، سرعت و کیفیتِ اطلاعات در حلقهی بازخورد نیز اهمیتِ زیادی دارند. تحقیقاتِ قبلی در زمینهی WDT نشان دادهاند که بازخوردِ دقیق و بهموقع از نتایجی مانند عملکردِ فردی و کشف خطاها حمایت میکند.
در این مطالعه، ما حلقههای بازخورد را از طریقِ معیارهای زیر اندازهگیری میکنیم:
- زمانِ لازم برای تأییدِ تغییراتِ کد.
- فرکانسِ دریافتِ پاسخِ سریع به یک سؤال.
بنابراین فرض میکنیم که حلقههای بازخورد از نتایج در سه سطح پشتیبانی میکنند: توسعهدهنده، تیم، و سازمان:
H2 – حلقههای بازخورد تأثیرِ مثبتی بر نتایجِ (الف) توسعهدهنده، (ب) تیم، و (ج) سازمان دارند.
بارِ شناختی
بارِ شناختی میزان اطلاعاتی است که حافظهی کاری میتواند در یک زمان پردازش کند و به حلِ مسئله و یادگیری کمک میکند. در زمینه DevEx، بارِ شناختی میزان پردازشِ ذهنیِ موردنیاز برای انجامِ یک وظیفه توسطِ یک توسعهدهنده است. نظریه بارِ شناختی چارچوبی را با سه نوع بارِ شناختی توصیف میکند: بارِ شناختی ذاتی که میزانِ تلاش یا سختیِ ذاتی موردنیاز برای انجام یک وظیفه است؛ بارِ شناختیِ اضافی که نحوه ارائه اطلاعات است و میتواند بهگونهای تغییر کند که شهودیتر یا کمتر شهودی باشد؛ و بارِ شناختیِ مؤثر که به الگوهای ذهنی مرتبط است.
تحقیقاتِ قبلی در زمینه WDT ویژگیهای محیطی و کاری را بررسی کردهاند که با بارِ شناختی همخوانی دارند و به نتایجِ کاری کمک میکنند. بهعنوانِ مثال، یک مطالعه نشان داد که وظایفِ آسانفهم (ذاتی) و جریانهای اطلاعاتیِ خوب طراحیشده (مؤثر) به نتایج کمک میکنند. یک تحقیقِ دیگر، که یک مطالعهی بزرگ متاآنالیز بود، نشان داد که پیچیدگی وظیفه (ذاتی) و عواملی که از پردازشِ اطلاعات پشتیبانی میکنند (مؤثر) به نتایج کمک میکنند.
در تحقیقِ ما، بارِ شناختی از طریقِ معیارهای زیر اندازهگیری میشود:
- میزانِ آسانیِ اعمالِ تغییرات.
- میزانِ سهولتِ درکِ کد.
- میزانِ شهودی بودنِ کار با فرآیندها و ابزارهای توسعهدهنده.
بهطورِ رسمی، ما فرض میکنیم که بارِ شناختی پایین از نتایج بهتر برای توسعهدهندگان، تیمهای توسعه و سازمانهایشان پشتیبانی میکند:
H3 – بارِ شناختی پایین تأثیرِ مثبتی بر (الف) نتایجِ توسعهدهنده، (ب) نتایجِ تیم و (ج) نتایجِ سازمان دارد.
مدلِ تحقیقِ پیشنهادی در شکل 1 ارائه شده است. پرسشنامه استفادهشده برای اندازهگیری این مدل در بخشِ بعدی توضیح داده شده است.
