یک سال در دیوار از نگاه یک فرانت اند دولوپر

مقدمه

من، سامان محمدی، بیش‌تر از یک سال است که به عنوان web front-end developer در تیم core دیوار مشغول به کارم. تصمیم گرفتم از تجربیاتم در این یک سال، در محیط کاری دیوار بنویسم. در این مطلب درباره‌ی دوره‌ی آموزشی بعد از ورود به شرکت، روال کاری، فضای chapter، مسیر رشد فردی و چالش‌های فنی front-end توضیحات مختصری می‌دهم. امیدوارم خواندن این نوشته به شما دید بهتری از کار کردن در دیوار بدهد.

قبل ورود به دیوار، بیشتر به صورت full-stack در start-upها یا به شکل پاره‌وقت در شرکت‌های غیرکامپیوتری کار می‌کردم. دوست داشتم کار کردن در یک محیط بزرگ‌تر و در کنار افراد حرفه‌ای‌تر را تجربه کنم؛ هرچند با رویه‌ی کارمند بودن در یک سازمان مشکل داشتم. محیط ایده‌آل کاری را جایی تصور می‌کردم که درگیر روزمرگی کارها و سیستم سلسله مراتبی و نگاه بالا به پایین مدیران به کارمندان نباشد. تصمیم گرفتم به دنبال شغلی بگردم که علاوه بر داشتن ویژگی‌های خوب اکوسیستم‌های استارت‌آپی، مثل همکاری تیمی، چابکی، داشتن دغدغه‌ی محصولی و ... محیطی حرفه‌ای‌تر با چالش‌های بزرگ‌تر داشته باشد. تا در نهایت به دور از ساختار سلسله مراتبی بتوانم تمرکز بیشتری بر تاثیرگذاری در سطح محصولی داشته باشم، چالش‌های کاری فرصت یادگیری بیشتر را برایم فراهم کند و در کنار تیم رشد کنم.

ورود به دیوار

فرآیند ورود به شرکت برای بچه‌های front-end به این صورت است که قبل از ورود به تیم‌ها باید یک دوره‌ی آموزشی بگذرانند. هدف این دوره غالباً آموزش حداقل‌های فنی مورد نیاز به افراد جدید پیش از ورود به تیم است.

در دوره آموزشی سرفصل های مختلف مرتبط با front-end مثل Javascript، CSS، DOM و… به صورت مرحله به مرحله مرور می‌شود. انتهای هر مرحله، هر فرد باید تمرین های مربوط به آن مرحله را انجام دهد و اشکالات احتمالی به کمک مربی بررسی و برطرف می‌شود. در انتهای دوره یک پروژه کوچک تعریف شده که تقریباً تمام سرفصل‌های دوره‌ی آموزشی را پوشش می‌دهد و در عین حال جمع و جور است. در یک کلام، در هر سطحی از تسلط به مباحث front-end باشید احتمالاً مباحث قابل توجه و آموزنده‌ای را برای مطالعه پیدا می‌کنید. مدت زمان این دوره بسته به سطح هر فرد و نیازمندی‌های شرکت می‌تواند متفاوت باشد. در طول دوره، علاوه بر نکات فنی با فرآیند‌های تیمی و شرکتی مثل فرآیند بررسی کد، کانال‌های slack (مثلا کانال مخصوص بازخورد، کانال اطلاع‌رسانی عمومی، کانال هماهنگی برای فوتبال و ...) و … نیز آشنا می‌شوید.

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

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

روال کار کردن در تیم

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

در اکثر تیم‌ها فرآیند به این صورت است که جلسه‌های روزانه (daily) در یک ساعت مشخص برگزار می‌شود و هر نفر از اعضای تیم در حد چند دقیقه از کارهایی صحبت می‌کند که انجام داده‌ است. علاوه بر این، جلسه‌های دوره ای (iteration) داریم که هر دو هفته کارهایی که باید انجام می‌شده را بررسی کرده و کارهایی را برنامه‌ریزی می‌کنیم که برای دو هفته‌ی بعد باید انجام گیرد. من بعد از تیم جویندگان به تیم core آمدم و در حال حاضر در این تیم مشغول هستم. در دیوار، ساختار تیم‌ها کاملاً منعطف بوده و بر اساس شرایط تغییر می‌کند. مثلاً در تعطیلات نوروز امسال که قصد داشتیم «دیوار فروشگاه‌ها» را پیاده‌سازی کنیم ساختار تیم‌ها تغییر کرد و یک تیم جدید برای توسعه بخش فروشگاه تشکیل شد. جابه‌جایی افراد در تیم‌های مختلف باعث می‌شود با همکاران بیش‌تری در دیوار آشنا شویم، با شرایط کاری جدید مواجه شویم و از برخورد با چالش‌های جدید تجربه کسب کنیم.

ارتباطات در چپتر فرانت

علاوه بر جلسات تیمی، جلسات chapter نیز داریم که هر دو هفته همه بچه‌های front-end دیوار در آن شرکت می‌کنند. در حال حاضر تعداد کل بچه‌های front-end دیوار ۱۰ نفر بوده ولی این تیم در حال بزرگ شدن است. جلسه‌های chapter معمولاً درباره‌ی مسائل مختلفی است. مثلاً از فلان کتاب‌خانه استفاده کنیم یا نه، فلان مورد را در coding style تغییر دهیم یا نه، فلان چالش را با چه روشی حل کنیم و… از مباحثی که تازگی‌ها بررسی کرده‌ایم می‌توان به تکنولوژی‌ها و روش‌های مختلف SSR، micro front-end، Dynamic Serving و React Concurrent Mode اشاره کرد. بحث‌هایی که در این جلسه‌ها شکل می‌گیرد به بچه‌ها کمک می‌کند از تجربه‌های یکدیگر استفاده کنند و چالش‌ها را با هم‌فکری حل کنند. برای این که در حین پیاده‌سازی یا پس از آن در جریان چرایی و چگونگی انتخاب روش‌ها قرار بگیریم و علاوه بر این مانع تکرار اشتباهات شویم، تلاش می‌کنیم این فرآیند را مستند کنیم و تقریباً برای هر راه حلی که ارائه شده یک design doc داریم.

فرآیند طراحی و پیاده‌سازی

در دیوار از یک design system به نام «سنت» استفاده می‌کنیم. این که مثلاً دکمه‌ها چه اندازه‌ای باشد، چه رنگ‌هایی استفاده شود، فاصله و جای‌گذاری‌ المان‌ها در صفحه چگونه باشد و… از مواردی هستند که توسط تیم UX به صورت یک استاندارد درآمده است و بعد از طراحی روی zeplin قرار می گیرند. سنت مختص به وب دیوار نمی‌شود، مثلاً بچه های اندروید بر پایه‌ی این design system اپ دیوار را توسعه می‌دهند، اگه دوست دارید با جنبه‌های اندرویدی و چالش‌های آن بیشتر آشنا شوید، پیشنهاد می‌کنم این ویدیو را حتماً ببینید. کاربرد اصلی داشتن یک design system این است که از به وجود آمدن ناسازگاری در بخش‌های مختلف یک محصول و یا حتی میان محصول‌های مختلف شرکت جلوگیری می‌کند.

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

ما در وب دیوار برای توسعه بر پایه design system سنت نیاز به یک ابزار یا کتاب‌خانه‌ی میانه داشتیم، چیزی مثل bootstrap یا material-ui با این تفاوت که باید مطابق با استاندارد‌های سنت (design system تعریف‌شده‌مان) می‌بود. از آن‌جایی‌که چنین چیزی وجود نداشت تصمیم گرفتیم خودمان آن را توسعه دهیم و نام آن را «خشت» گذاشتیم. خشت همان‌طور که از اسم آن پیداست قرار است اجزای سازنده دیوار (نسخه وب) باشد. از آن‌جایی که تصمیم جدی بر مبنای حرکت کردن به سمت design system جدید در مدت زمانی کوتاه داشتیم، زمان زیادی از وقت من و سایر بچه‌های front-end صرف توسعه خشت شد و در حال حاضر تا حد خوبی توسعه یافته‌ است. اگر کمی دقت کنید این تغییرات را می توانید به مرور در بخش‌های مختلف وب دیوار مشاهده کنید که قدم‌های اولیه برای رفتن به سمت طراحی جدید هستند.

یکی از قدم‌های دیگر برای رفتن به سمت طراحی جدید، توسعه بر پایه widget است. در تعریف widget به صورت خلاصه می‌توان گفت که هر کدام از اجزا(یا componentها)ی صفحه قابلیت widget شدن را دارد. رفتار و شکل ظاهری این component از سمت back-end می‌آید. پیاده‌سازی این سیستم نیازمند این بوده که یک استاندارد یا توافقی بین تیم‌های back-end، front-end و design وجود داشته باشد. برای مثال وقتی صحبت از ویجت PostCard می‌شود، مشخص باشد که این widget چه اطلاعاتی نیاز دارد، چه رفتار‌هایی می‌تواند داشته باشد و در نهایت به چه شکلی قرار است render شود. با پیاده‌سازی این روش، امکان این را داریم که بدون deploy کردن کد سمت front-end و تنها با توجه به اطلاعاتی که از سمت back-end می‌آید ترکیب متفاوتی از componentها با رفتار‌های متفاوتی را render کنیم.

یک مثال ساده از کاربرد این روش می‌تواند این باشد: فرض کنید شرایط خاصی پیش آمده و نیاز داریم در کوتاه ترین زمان ممکن این امکان را داشته باشیم که در صفحه‌ی آگهی، یک بنر در یک جای غیرمعمول نمایش دهیم، قبلاً این‌طور بود که برای انجام این کار باید بنر را تیم design طراحی می‌کرد، API مربوط به فعال/غیرفعال شدن بنر را تیم back-end پیاده‌سازی می‌کرد و در نهایت ما (front-end) با توجه به بنر طراحی شده و API، کد مربوط به صفحه‌ی آگهی رو تغییر می‌دادیم و deploy می‌کردیم. این فرآیند برای محصول بزرگی در سطح دیوار حداقل چند روز طول خواهد کشید. ولی با وجود ساختار widget، تمام componentها از قبل طراحی (سنت) و پیاده‌سازی (خشت) شده‌اند و تنها کاری که باید انجام شود این بوده که data از سمت back-end برای صفحه‌ی آگهی تغییر کند و widget بنر را در کنار سایر widgetها بفرستد. لازم به توضیح نیست که این روش در عین چابک بودن، انتخاب‌های خیلی بیشتری را در اختیار ما قرار می‌دهد. از آن‌جایی که بیشتر کارهای مربوط به صفحه جستجو (لیست آگهی‌ها) مربوط به تیم جویندگان بود، اصلاح ساختار این صفحه بر پایه‌ی widget از جمله کارهای من در این تیم بود.

از جمله امکاناتی که فرآیند توسعه را ساده‌تر کرده و میزان bugها را کاهش داده، وجود نقش مهندس کنترل کیفیت (QA engineer) است. تمام تغییرات قبل از merge شدن در مرحله QA از نظر مطابقت با design و کارکرد بررسی می‌شوند، این کار باعث می‌شود ما در front-end زمان بیشتری را به توسعه اختصاص دهیم و فرآیند تست و بررسی کیفیت توسط افراد متخصص، با دقت بیشتر و به صورت حرفه‌ای‌تری انجام گیرد. تیم QA علاوه بر تست و بررسی فردی، در طراحی و تعریف سناریو های مختلف برای تست های E2E هم نقش مهم را ایفا می‌کند.

مسیر پیشرفت شغلی

از روز اولی که هر فردی وارد شرکت می‌شود، یک مسیر رشد برای او ترسیم شده که باید در این مسیر قدم بردارد. این مسیر در قالب سطح‌های مختلف تعریف شده و هر چقدر سطح فرد افزایش پیدا کند انتظارات نیز به همان نسبت از او بیشتر خواهد شد. به طور کلی در سطح صفر از هر فرد انتظار می‌رود که بتواند یک کار خوش‌تعریف را در مدت زمان معقولی انجام دهد. ولی در سطح‌های بالاتر انتظار می‌رود علاوه بر انجام دادن کارها، در تصمیمات راهبردی و جهت‌دهی فنی آدم‌ها و پروژه‌ها نیز مشارکت کند. ارزیابی این موارد بر عهده ماست که در شرکت به آن «خودارزیابی» مي‌گوییم. فرآیند خودارزیابی هر ۶ ماه یک‌بار انجام می‌شود. در این فرآیند هر نفر یک گزارش ارزیابی با توجه به عمل‌کردی‌ می‌نویسد که در این مدت داشته است. در نهایت توسط team leader و سایر بچه‌هایی که در این مدت همکاری بیشتری با آن‌ها داشتیم، مورد بررسی قرار می‌گیرد. نتیجه ارزیابی معیار خوبی برای سنجش میزان تطابق عملکردمان با مسیر رشد تعریف شده است.

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

یکی از مواردی که برای من (که پیش‌تر freelance کار می‌کردم) روش آموزنده و مفیدی از تجربه‌ی کار کردن در دیوار بوده، فرآیند بررسی کد است. در اینجا هر کدی که می‌زنیم قبل از merge شدن باید توسط یک نفر دیگر از بچه‌های front-end بررسی شود. این کار کمک می‌کند bugهای احتمالی کاهش یافته و کیفیت کد افزایش پیدا کند. هر چند به نظر من مهم‌ترین مزیت این کار، یادگیری به واسطه‌ی بررسی کد دیگران است که قطعاً در رشد فنی افراد می‌تواند تاثیرگذار باشد.

یک front-end developer بودن در دیوار تنها به این معنی نیست که شما تنها مسئول انجام دادن کارهای front-end هستید! اینجا همه بچه‌های تیم صرف نظر از این که چه نقشی دارند، در قبال رسیدن به اهداف تیمی و در نهایت رشد محصول احساس مسئولیت می‌کنند. اگر قرار باشد تغییری اعمال شود یا ویژگی جدید اضافه شود، این تصمیم به عهده‌ی همه اعضای تیم است و همگی در جریان چرایی و چگونگی این تصمیم قرار می‌گیرند.

در پایان...

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

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