در کتاب پروژه فونیکس که توسط آقای جین کیم و کوین بهر و جورج اسپافورد نوشته شده دیدی منحصر به فرد از جنگل IT موجود در سازمان های بزرگ به خواننده نمایش داده می شود، نکته جالب توجه این است که محیط و مدل فعالیت‌ها اشاره شده درست است که درباره DevOps است ولی شباهت زیادی به اتمسفر موجود در محیط کاری UX است. ( خواندن این کتاب به تمامی متخصصان UX و توسعه دهندگان و مدیران محصول توصیه می گردد ). کتاب کاملاً مشخص می نماید که همدلی زیرساخت طراحی کاربر محور است.

توسعه نرم‌افزار و طراحی UX شانه به شانه یکدیگر هستند، جامعه UX نیاز است توجه ویژه ایی به حرکت DevOps داشته باشد زیرا تغییر مدل کاری تیم Ops درس‌های زیادی جهت ایجاد سیستم Continuous Design در خود دارد و کمک می نماید تا روش توسعه UX با مدل Continuous delivery یکپارچه گردد. در زیر تلاش شده تا با ارائه ۱۳ عبارت بدیهی Ops انتخاب شده آن‌ها را به  UX اعمال نماییم.

درس اول - Ux مناسب می تواند به درستی پیش بینی کننده عملکرد شرکت باشد

"to effectively manage IT is not only a critical competency but a significant predictor of company performance"

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

درس دوم - UX فقط یک عنوان یا دپارتمان نیست. بلکه یک توانمندی برای تمامی سازمان است.

"IT is not just a department. It is a competency that we need to gain as an entire company"

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

درس سوم -  شما باید سیستم کاری را که UX در آن فعالیت می کند و تعهدات سازمانی که تیم UX مسئول آن است درک کنید.

"you must gain a true understanding of the business system that IT operates in...there are organizational commitments that IT is responsible for helping uphold and protect that no one has verbalized precisely yet"

همه بخش ها باید از سیستم کاری که UX در آن کار می کند و تعهداتی که تیم UX عهده دار آن است ، مطلع شوند. این اساسی ترین جنبه Practice است که اکثریت قریب به اتفاق رهبران بخشها - حتی گاهی اوقات سازمان به عنوان یک کل از آن اطلاعی ندارند. هیچ کس بهتر از آلن کوپر رابطه UX با تجارت را بیان نمی کند: "آیا می خواهید پول در بیاورید ، یا می خواهید پس انداز کنید؟ یا می خواهید نوآوری کنید و پول بدست آورید؟ من اینجا نیستم تا پول شما را پس انداز کنم، من اینجا هستم تا پولت را بدست آورم. " وی در ادامه توضیح داد که یک بخش طراحی در سازمان یک مرکز هزینه است که طبق تعریف آن، بعداً باعث افزایش ارزش سازمان و سهام آن می گردد. همچنین وقتی سازمان در صدد کاهش هزینه از طریق کاهش تعداد پرسنل، کاهش کیفیت محصولات و حذف برخی فرآیندها است، بخش UX با برگشت سرمایه خوب خود و اشراف سازمان به این موضوع از این کاهش هزینه ها در امان بماند.

درس چهارم - اتخاض تصمیمات تجاری مناسب تر با نمایش تاثیر ریسک های UX بر عملکرد تجاری سازمان

"showing how IT risks jeopardize business performance measures, you can start making better business decisions"

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

تصمیمات ریشه در مصلحت اندیشی و نگرانی از زمان حضور در بازار می تواند خطرات UX را ایجاد کند که قابل اندازه گیری دقیق نیست. به طور خلاصه، شما نمی توانید ایده ای را که در بدو تولد رها شده تأیید کنید. برای شروع ارزیابی خطرات UX برای بیزینس، به یک دسته متفاوت از سوالات نیاز دارید. به عنوان مثال، به جای اینکه بپرسید سود سازمان از یک پیاده سازی خاص چیست ، ممکن است در عوض سوال کنید ، "کاربر با عدم اجرای راه حل بهتر چه چیزی را از دست می دهد؟" یا اینکه "با عدم اجرای این راه حل کامل تر، چه ارزش بیشتری برای کاربر وجود دارد؟"

درس پنجم - چهار نوع کار UX وجود دارد (پروژه ها ، عملیات معمول ، اصلاحات و کارهای برنامه ریزی نشده)

"there are four types of IT operations work: business projects, IT operations projects, changes, and unplanned work"

کار UX را می توان در این طبقه بندی ترسیم کرد. پروژه هایی وجود دارد که مستقیماً با محصولاتی مرتبط هستند که بیزینس را پیش می برند. همکاری های مداومی در زمینه طراحی وجود دارد که عملیاتی عادی برای هماهنگی با نیازهای کاربران و اصلاحات مداوم ذکر شده در پرونده های عقب مانده است. و کارهای غیر برنامه ریزی شده به صورت پیاده سازی هایی است که کمتر از مشخصات موجود است که به طور مداوم به بدهی UX می افزاید.

درس ششم: بدهی پرداخت نشده UX می تواند به مرور زمان به شکل کار بدون برنامه سیستم را فلج کند

"technical debt that is not being paid down. It comes from taking shortcuts, which may make sense in the short-term. But like financial debt, the compounding interest costs grow over time. If an organization doesn't pay down its technical debt, every calorie in the organization can be spent just paying interest, in the form of unplanned work"

بدهی UX می تواند تکامل طبیعی محصول را فلج کند. آنچه باید کل سازمان را نگران کند این نا آگاهی است که برخی جریانهای کاری در یک محصول نامناسب است ، یا اینکه اجرای UI نادرست است و فاصله گسترده ای بین هدف اصلی و نتیجه فعلی وجود دارد.

درس هفتم - مهم است که بدانید کار بدون برنامه در ux از کجا ناشی می شود.

"unplanned work is recovery work, which almost always takes you away from your goals. That's why it's so important to know where your unplanned work is coming from"

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

دو نوع صرفه جو در زمان وجود دارد. یکی عمدی است. مورد دوم عینی است. در اولین، ما منطق طراحی محاسبه و گاهی اوقات با فداکاری به ظرافت یک ویژگی است. در مرحله دوم، ما از دقت در اجرا چشم پوشی می کنیم، زیرا آنها را مانعی برای همگام شدن با تعهدات اسپرینت ها می دانند. در هر صورت، وقتی کیفیت UX به عنوان مشکل اصلی دیده می شود، باعث نارضایتی کاربر و کاهش فروش می شود. زمان لازم برای تعریف راه حل های UX با کاستی های شناخته شده، بحث در مورد آنها و سپس بررسی دقیق آنها، هزینه و زمان بیشتری را برای همه تیم ها به همراه دارد. یک رویکرد برای کاهش این مسئله مطابق با نظرات دبلیو ادواردز دمینگ است: "برای دستیابی به کیفیت، وابستگی خود را به بازرسی انبوه متوقف کنید. در مرحله اول فرآیند را بهبود بخشید و کیفیت را در محصول ایجاد کنید." چگونه این امر محقق می شود؟ هرکسی که دستی در پیاده سازی محصول دارد، باید در مورد استاندارد کیفیت UX که باید رعایت شود، آموزش ببیند.

هنگامی که کیفیت و موفقیت UX در معیارهای عملکرد کسب و کار کمی شود، آگاهی سازمان به یک ذهنیت جدید تبدیل می شود که کیفیت بالاتری تولید می کند. بهترین تلافی در Phoenix Project به مضمونی از جمله "کمال دشمن خوب است" می رسد، که یکی از قهرمانان داستان به او پاسخ می دهد، "نه ، عدم صلاحیت دشمن خوب است." هدف باید افزایش توانایی UX در سازمان باشد.

درس هشتم - چیزی که مهم است نتایج هستند

"outcomes are what matter—not the process, not controls, or, for that matter, what work you complete"

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

درس نهم - هرچه چرخه UX طولانی تر باشد، مدت طولانی سرمایه شرکت قفل شده و بازدهی ندارد

"The longer the product development cycle, the longer the company capital is locked up and not giving us a return"

هسته تحویل مداوم است که UX ، dev و IT باید در آن روان شود. مهمترین جنبه چالش برانگیز این است که محدوده UX به اندازه کافی فضایی را در اختیار تفکر طراحی، برای نشان دادن راه حل های بهتر نسبت به چرخه های توسعه قرار دهد. این می تواند به تدوین یک راه حل چند طبقه یا پذیرش پیاده سازی های دور ریختنی تبدیل شود. در اینجا دوباره، Kim آموزش می دهد که از طریق حل مسئله فناوری اطلاعات ، می توان این رشته را از طریق درک بیشتر جریان کار ایجاد کرد.

درس دهم − با نگه داشتن تیم توسعه دهنده در جریان منطق طراحی ، یک جریان سریع UX ایجاد کنید

"understand how to create a fast flow of work as it moves from Development into IT Operations"

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

درس یازدهم - تعادل مناسب برای تمرکز بر روی آنچه واقعاً مهم است را پیدا کنید و WIP را به حداقل برسانید (کار در حال انجام )

"You've improved flow by freezing and throttling the project releases, but your batch sizes are still way too large...You also have way too much WIP (work in progress) still trapped inside the plant, and the worst kind, too. Your deployments are causing unplanned recovery work downstream"

به طور خلاصه، Kim چالش پیچیده ای را که شامل تمام دپارتمان های متمرکز بر محصول است را مطرح می نماید. جهت متمایز نمودن محصول ما از محصولات رقبا چقدر باید تغییر ایجاد نمود؟ نوآوری کجا بیشترین اهمیت را دارد؟ وعده ها برای داستان بازاریابی چقدر باید باشد که علاقه تحلیلگران را برانگیزد و به نوبه خود توجه بازار را به خود جلب کند؟ چگونه مدیریت محصول یک نقشه راه رو به رشد همراه با یک چشم انداز روشن را ترسیم می کند، در حالی که همچنان در مسیر خود انعطاف پذیر است؟ چگونه UX یک هویت قوی را تعریف می کند که منسجم، با کیفیت و مصالحه ناپذیر در کیفیت باشد اما با این وجود از الزامات تجاری برخوردار است؟ برای سازمانی که بلند پرواز بوده و قصد رهبری بازار را دارد، سوال مهمی مطرح می گردد. پروژه ققنوس (Phoenix Project ) از طریق متدهای اجرای کارها به ما یک نگاه اجمالی ارائه می دهد.

درس دوازدهم − آزمایش کنید ،طرفدار Deploy های سریع باشید و برای کوچک و سریع کردن امور نظم داشته باشید

"we're now experimenting with doing daily deployments. Because the batch size is so much smaller, we can make small changes very quickly"

اینجا، درست در اینجا، جوهره تحویل مداوم است: تمایل به آزمایش، تعصب نسبت به نظم برای کوچک و سریع کردن کارها.

درس سیزدهم - UX فقط یک عملکرد پشتیبانی نیست بلکه همه افراد سازمان باید در آن تجربه داشته باشند.

"IT is not merely a department. Instead, it's pervasive, like electricity. It's a skill, like being able to read or do math—we expect everyone we hire to have some mastery of it"

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