View in Telegram
اکسپوگرافی | دیزاین و تجربه
پرایمر دیزاین سیستم گیت‌هابه. وقتی درباره‌ی داستان تکامل این دیزاین سیستم می‌شنویم متوجه می‌شیم که اتفاقاتی توی تیم طراحی این دیزاین سیستم افتاده که باعث شده وارد چالش‌های زیادی با تیم فنی بشن. Diana Mounter، که هدِ دیزاین توی شرکت گیت‌هابه توی این ویدیو به…
🔹 چطور پرایمر شکل گرفت؟
سال ۲۰۱۶ دایانا به عنوان پروداکت دیزاینر وارد گیت‌هاب شد و توی توسعه پرایمر نقش داشت. اون موقع، پرایمر بیشتر یه دیزاین سیستم مبتنی بر CSS بود. تیم دیزاین کوچیک بود و بیشتر اعضا توی کدنویسی مهارت داشتن. بنابراین تونستن دیزاین سیستمی بسازن که هم خوب کار می‌کرد و هم زیبا بود. ولی تیم فنی گیت‌هاب که بیشتر روی بک‌اند متمرکز بود، درگیر دیزاین سیستم نبود و اصلاً نیازی هم به این کار نمی‌دید. این باعث شد که تیم دیزاین، کار توسعه و برنامه‌نویسی پرایمر رو به دست بگیره و تیم فنی هم عملاً از این روند دور بود.
🔹 چالش‌ها چطور شکل گرفتن؟
تا سال ۲۰۲۰، پرایمر تبدیل به یه دیزاین سیستم پیچیده‌تر شد. مهندس‌هایی که توی تیم دیزاین بودن، کامپوننت‌ها رو با React بازنویسی کردن و علاوه بر اون، تیم دیزاین تونست دارک مود رو برای پرایمر معرفی کنه که از طرف کاربر‌ها هم خیلی استقبال شد.
اما همین تغییرات باعث شد تنش‌ها بیشتر دیده بشه؛ تیم دیزاین از React استفاده می‌کرد و تیم فنی همچنان با CSS کار می‌کرد. اینجا بود که یه چیزی به نام «Value Oasis» شکل گرفت؛ یعنی تیم طراحی برای خودش، با ارزش‌های خودش و با روش‌های خودش کار می‌کرد و خیلی با بقیه هماهنگ نبود.
این شکاف زمانی شدیدتر شد که تیم طراحی وظیفه داشت دارک مود رو برای کنفرانس Universe گیت‌هاب آماده کنه. وقتی مدیر محصول وارد پروژه شد، تازه دایانا فهمید که انتظارات و روش‌های کاری‌ای وجود داره که هیچ‌وقت باهاشون آشنا نبوده.
از طرف دیگه، تیم مهندسی هم توی یک‌دست کردن کدهای خودش با دیزاین سیستم جدید مشکل داشت. گیت‌هاب با یه سوال بزرگ روبرو شد: سرعت رو اولویت بدیم یا یک‌دست بودن رو؟
🔹 راه حل چی بود؟
در نهایت، مدیرهای گیت‌هاب تصمیم گرفتن ارتباطات بین مدیرهای طراحی و فنی رو بیشتر کنن تا درک متقابل بین‌شون بیشتر بشه.
علاوه بر این، وقتی دایانا Head طراحی کل محصول شد، افرادی رو برای دیزاین پرایمر استخدام کرد که دانش فنی خوب داشتن تا بتونن رابطه قوی‌تری با تیم فنی برقرار کنن.
در نهایت، توی سال ۲۰۲۲، وقتی اوضاع اقتصادی به هم ریخت و تعدیل نیروها شروع شد، دایانا تصمیم گرفت مهندس‌های تیم دیزاین سیستم رو به بخش فنی منتقل کنه. این تغییر ساختاری باعث شد دیگه تیم‌ها جدا از هم کار نکنن و اتفاقا نتایج بهتری رو برای گیت‌هاب داشت.
در واقع مشخص شد که دیزاین سیستم باید یه مسئولیت مشترک بین تیم‌های فنی، محصول و دیزاین باشه.
🔹 چه درسی بگیریم؟
مهم‌ترین درسی که از این تجربه می‌شه گرفت اینه که تیم‌ها نباید توی دنیای خودشون کار کنن. مهمه که تعامل خوبی بین تیم‌های محصول، فنی و دیزاین وجود داشته باشه.
از اون مهم‌تر، باید مدیر هر تیمی بدونه که تیم خودش و تیم‌های دیگه توی پیشبرد کارهاشون چه ارزش‌هایی رو دنبال می‌کنن؟ شناسایی و حل و فصل اختلاف‌هایی که بین این ارزش‌ها وجود داره می‌تونه به طور چشم‌گیری جلوی اصطکاک‌ها رو بگیره و فرآیند توسعه محصول رو بهبود بده.
در کل، تجربه گیت‌هاب نشون می‌ده که دیزاینر‌ها نه‌تنها باید با کاربر‌هاشون همدلی داشته باشن، بلکه باید با همه‌ی کسایی که توی فرآیند توسعه محصول نقش دارن، همدلی کنن. و البته برعکس :))
🔗 https://www.youtube.com/watch?v=2XuWY2z2TUo
#Config2024
✅@Expography
سال ۲۰۱۶ دایانا به عنوان پروداکت دیزاینر وارد گیت‌هاب شد و توی توسعه پرایمر نقش داشت. اون موقع، پرایمر بیشتر یه دیزاین سیستم مبتنی بر CSS بود. تیم دیزاین کوچیک بود و بیشتر اعضا توی کدنویسی مهارت داشتن. بنابراین تونستن دیزاین سیستمی بسازن که هم خوب کار می‌کرد و هم زیبا بود. ولی تیم فنی گیت‌هاب که بیشتر روی بک‌اند متمرکز بود، درگیر دیزاین سیستم نبود و اصلاً نیازی هم به این کار نمی‌دید. این باعث شد که تیم دیزاین، کار توسعه و برنامه‌نویسی پرایمر رو به دست بگیره و تیم فنی هم عملاً از این روند دور بود.
🔹 چالش‌ها چطور شکل گرفتن؟
تا سال ۲۰۲۰، پرایمر تبدیل به یه دیزاین سیستم پیچیده‌تر شد. مهندس‌هایی که توی تیم دیزاین بودن، کامپوننت‌ها رو با React بازنویسی کردن و علاوه بر اون، تیم دیزاین تونست دارک مود رو برای پرایمر معرفی کنه که از طرف کاربر‌ها هم خیلی استقبال شد.
اما همین تغییرات باعث شد تنش‌ها بیشتر دیده بشه؛ تیم دیزاین از React استفاده می‌کرد و تیم فنی همچنان با CSS کار می‌کرد. اینجا بود که یه چیزی به نام «Value Oasis» شکل گرفت؛ یعنی تیم طراحی برای خودش، با ارزش‌های خودش و با روش‌های خودش کار می‌کرد و خیلی با بقیه هماهنگ نبود.
این شکاف زمانی شدیدتر شد که تیم طراحی وظیفه داشت دارک مود رو برای کنفرانس Universe گیت‌هاب آماده کنه. وقتی مدیر محصول وارد پروژه شد، تازه دایانا فهمید که انتظارات و روش‌های کاری‌ای وجود داره که هیچ‌وقت باهاشون آشنا نبوده.
از طرف دیگه، تیم مهندسی هم توی یک‌دست کردن کدهای خودش با دیزاین سیستم جدید مشکل داشت. گیت‌هاب با یه سوال بزرگ روبرو شد: سرعت رو اولویت بدیم یا یک‌دست بودن رو؟
🔹 راه حل چی بود؟
در نهایت، مدیرهای گیت‌هاب تصمیم گرفتن ارتباطات بین مدیرهای طراحی و فنی رو بیشتر کنن تا درک متقابل بین‌شون بیشتر بشه.
علاوه بر این، وقتی دایانا Head طراحی کل محصول شد، افرادی رو برای دیزاین پرایمر استخدام کرد که دانش فنی خوب داشتن تا بتونن رابطه قوی‌تری با تیم فنی برقرار کنن.
در نهایت، توی سال ۲۰۲۲، وقتی اوضاع اقتصادی به هم ریخت و تعدیل نیروها شروع شد، دایانا تصمیم گرفت مهندس‌های تیم دیزاین سیستم رو به بخش فنی منتقل کنه. این تغییر ساختاری باعث شد دیگه تیم‌ها جدا از هم کار نکنن و اتفاقا نتایج بهتری رو برای گیت‌هاب داشت.
در واقع مشخص شد که دیزاین سیستم باید یه مسئولیت مشترک بین تیم‌های فنی، محصول و دیزاین باشه.
🔹 چه درسی بگیریم؟
مهم‌ترین درسی که از این تجربه می‌شه گرفت اینه که تیم‌ها نباید توی دنیای خودشون کار کنن. مهمه که تعامل خوبی بین تیم‌های محصول، فنی و دیزاین وجود داشته باشه.
از اون مهم‌تر، باید مدیر هر تیمی بدونه که تیم خودش و تیم‌های دیگه توی پیشبرد کارهاشون چه ارزش‌هایی رو دنبال می‌کنن؟ شناسایی و حل و فصل اختلاف‌هایی که بین این ارزش‌ها وجود داره می‌تونه به طور چشم‌گیری جلوی اصطکاک‌ها رو بگیره و فرآیند توسعه محصول رو بهبود بده.
در کل، تجربه گیت‌هاب نشون می‌ده که دیزاینر‌ها نه‌تنها باید با کاربر‌هاشون همدلی داشته باشن، بلکه باید با همه‌ی کسایی که توی فرآیند توسعه محصول نقش دارن، همدلی کنن. و البته برعکس :))
🔗 https://www.youtube.com/watch?v=2XuWY2z2TUo
#Config2024
✅@Expography
Telegram Center
Channel