تیم هستهٔ دیوار که بود و چه کرد؟!

من مهدی خوشنودی هستم و در حال حاضر وظیفهٔ راهبری (تیم لید) تیم Core یا هسته رو به عهده دارم.

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

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

از کجا آمده‌ایم؟

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

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

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

تکامل تیم هسته تا به امروز

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

• پایداری (Reliability)
• بازدهی (Performance)
• امنیت (Security)
• بهره‌وری توسعه‌دهندگان (Developers Productivity)
• بهینگی زیرساخت (Infrastructure Efficiency)
• زیرساخت داده (Data Infrastructure)

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

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

در نهایت به صورت خلاصه با این توصیفات، من تیم هسته رو به شکل تعریف می‌کنم: «تیم هسته با دنبال کردن اهداف ذکر شده در زمینهٔ سرویس‌هایی که در خدمت کاربران نهایی هستند به پایدار ماندن و رشد دیوار کمک می‌کند.»

شکافت هسته‌ای

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

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

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

این سرویس‌ها، سرویس‌های حیاتی دیوار محسوب می‌شن و لازمه که پایداری‌شون مهم‌ترین اولویت دیوار باشه و در هر شرایطی بالا بودن این سرویس‌ها از هر چیز دیگه‌ای مهم‌تره.

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

تصمیمات‌مون رو بر چه اساسی می‌گیریم؟

در دیوار همهٔ تیم‌ها بر اساس OKR کار می‌کنند و موظفند تا هر سه ماه هدف‌گذاری فصلی خودشون رو ارائه کنند. من اینجا خیلی روی اینکه OKR چیه

و چطور می‌تونه کمک کنه، تمرکز نمی‌کنم و اگر مایل به مطالعهٔ بیشتر روی این موضوع بودید پیشنهاد می‌کنم این مطالب رو مطالعه کنید.

حالا کاری که ما می‌کنیم اینه که در هفته‌های قبل از شروع OKR جدید، جلساتی برای بازنگری OKR گذشته و هم‌فکری و ایده‌پردازی برای OKR بعد تنظیم می‌کنیم تا در درجهٔ اول نسبت به وضعیت فعلی‌مون آگاه‌تر بشیم و ببینیم هر مورد کجای کاره و آیا لازمه در OKR بعدی دیده بشه یا نه.

در قدم بعدی با هم‌فکری همدیگه همهٔ ایده‌هایی که در کل (نه لزوما برای OKR بعد) به ذهنمون می‌رسه رو می‌نویسم و در ادامه با بحث و گفتگو سعی می‌کنیم موارد مبهم رو شفاف کنیم و یک ایدهٔ اولیه از اولویت کارها شکل بدیم. تا در جلسات آینده که برای جمع‌بندی و نهایی کردن OKR پیشنهادی تیم برگزار می‌شه، آماده‌تر باشیم.

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

برنامه‌ریزی برای OKR و اجرا

بعد از نهایی شدن OKR با کمک تیم یک نقشهٔ راه می‌چینیم که بدونیم برای رسیدن به اهداف OKRمون چه کارهایی باید انجام بدیم. سند این نقشهٔ راه چیزی شبیه به شکل زیره. در سمت چپ کارهای کلی که باید برای رسیدن به هر هدف در OKR باید انجام بشه هر ستون هم نشون‌دهندهٔ یک اسپرینت دو هفته‌ایه که در ادامه بیشتر راجع بهش توضیح می‌دم.

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

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

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

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

از ابزار scrum for trello هم برای ثبت تخمین و زمان صرف شده برای هر کارت استفاده می‌کنیم.

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

• Scope
• Search
• Payment
• Post View
• …
• Type
• Feature
• Bug
• Reliability
• …
• Status
• Out of Iteration
• Not Done
• Blocked

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

بدون شک یکی از مهم‌ترین تکنیک‌هایی که ما به صورت مداوم اجرا می‌کنیم جلسات هماهنگی روزانه‌است. همون‌جوری که از اسمش پیداست، ما هر روز ساعت ۲ بعد از ظهر کارت‌ها رو در ترللو بروز می‌کنیم و دور هم جمع می‌شیم و وضعیت کارهامون رو با تیم به اشتراک می‌ذاریم.

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

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

مستقل از کارها

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

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

ما به صورت ماهانه یک فرم سلامت‌سنجی هم پر می‌کنیم و در یک جلسه دور هم نتیجهٔ سلامت‌سنجی رو بررسی می‌کنیم، مواردی که نیاز به تغییر و بهبود داشته باشند رو شناسایی می‌کنیم و براشون راه‌کار پیدا می‌کنیم. خروجی فرم سلامت‌سنجی چیزی شبیه تصویر زیر میشه.

در مورد اینکه کرونا و دورکاری چه اثری در ارتباطات تیمی داشته دیگه فکر کنم لازم به توضیح نیست. کاری که ما برای جبران بخشی از اون ارتباطات و دوستی‌ها کردیم تعیین زمان «خستگی درکنی بعد از اسپرینت» بود که بعد از جلسات ایتریشن و تموم شدن اسپرینت دور هم جمع می‌شیم و بازی می‌کنیم (برای مثال Among Us).

هر دو سه ماه یک بار هم سعی می‌کنیم برنامه‌ای بچینیم تا با بودجه‌ی تیم‌سازی که شرکت در اختیارمون می‌ذاره، به صورت حضوری همدیگه رو ببینیم و گپ بزنیم و یه غذایی بخوریم!

مخلص کلام

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

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

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