چگونه طراحان و توسعه‌دهندگان به‌خوبی در کنار هم کار کنند؟

منتشر شده در thenextweb به تاریخ ۶ ژانویه ۲۰۲۲
لینک منبع Product designers and developers don’t always play nice — here’s how to work together

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

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

سه هفته بعد، شما با نمونه اولیه تکمیل‌شده به دیو بازمیگردید.

و او عصبانی است.

به گفته او، شما کاملا دستورالعمل‌های تیم او را نادیده گرفتید. شما پیکسل‌های دقیق مشخص‌شده را اجرا نکردید، سایه‌های رنگ را کاملا درست به دست نیاوردید، و -اه- آن همه جلوه‌های خاص کجا هستند؟

حالا شما از دست دیو و تیمش هم عصبانی هستید. در طول این سه هفته، آن‌ها اصلاً با شما تماس نگرفتند.

و حالا، بعد از هفته‌ها کار در شیفت شب برای فرستادن نمونه اولیه به موقع، تمام چیزی که دیو می‌خواهد ببیند مدیر شماست، بنابراین او کسی را دارد که بهتر است سر او داد بزند.

چگونه تنش به‌وجود می‌آید؟

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

برخی از طراحان محصولات می‌خواهند تا دیروز تمام محصولات دقیق و پیچیده خود را آماده کنند.

این به خاطر این نیست که آن‌ها آدم‌های بدی هستند.

طراحانی مانند آن تمایل دارند دانش فنی در مورد تمام چارچوب‌ها و کارهایی که در بک‌اند انجام می‌شود ندارند. تبدیل یک نمونه اولیه به یک محصول در حال کار، به چیزی بیش از یک جادوی کوچک نیاز دارد.

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

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

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

با این حال، طراحان بی‌تجربه نیز می‌توانند یک آفت باشند.

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

چنین دانشی همچنین به طراحان کمک می‌کند تا ایده‌های خود را با جزئیات بیشتر منتقل کنند.

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

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

اساسا، به این مساله بستگی دارد: طراحان و توسعه دهندگان به زبان‌های مختلف صحبت می‌کنند.

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

چگونه توسعه دهندگان و طراحان را از گم شدن در ترجمه باز داریم

شاید باید یک مترجم بگیرید؟ نگران نباشید، لازم نیست.

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

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

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

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

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

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

ابزارهای نرم‌افزاری برای پر کردن شکاف

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

انیما

انیما یک پلت‌فرم طراحی به کد است که در آن طراحان (و توسعه دهندگان! می‌توانند نمونه‌های اولیه را توسعه دهد و کد مناسب توسعه دهنده را در پایان فرآیند صادر کند. برای توسعه دهندگان، این کد در فریمورک‌های محبوب مختلف مانند React، vue.js و html موجود است. علاوه بر این، طراحان می‌توانند نمونه‌های اولیه خود را راحت‌تر از ابزارهای طراحی سنتی‌تر زنده کنند، زیرا آن‌ها می‌توانند اثرات تعاملی مانند اثرات شناور، انیمیشن‌های ورودی، GIFها، و غیره را اضافه کنند.

فریمر ایکس

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

برنامه‌های Handoff، Visly، Modulz، و بیشتر

ابزارهای طراحی بیشتری وجود دارند که نمونه‌های اولیه را به کد تبدیل می‌کنند. با این حال، یک مشکل با اکثر آن‌ها وجود دارد: آن‌ها به بخش پویا نمونه‌های اولیه مانند Anima و Framer نمی‌پردازند. این امر بسیار به تخیل توسعه دهنده مسئول واگذار می‌شود. به عبارت دیگر، پتانسیل زیادی برای درگیری بر روی میز باقی می‌گذارد.

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

هدف نهایی: ابزارهای خوب، افراد خوب، فرهنگ خوب

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

می‌دانم که این خیلی بدیهی به‌نظر می‌رسد.

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

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

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

مقالات لینک‌شده در این متن می‌توانند به صورت رایگان با استفاده از مقاله‌خوان ترجمیار به فارسی مطالعه شوند.