ویرگول
ورودثبت نام
Ali Fazeli
Ali Fazeliمهندس نرم افزار
Ali Fazeli
Ali Fazeli
خواندن ۶ دقیقه·۱ ماه پیش

چرا و چطوری اهداف تیم مهندسی رو به خروجی‌های سازمان وصل کنیم؟

چرا و چطوری اهداف تیم مهندسی رو به خروجی‌های سازمان وصل کنیم
چرا و چطوری اهداف تیم مهندسی رو به خروجی‌های سازمان وصل کنیم

مشکلی که همه می‌شناسیم

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

ولی اگر ازشون بپرسی که چرا دارن این کار رو انجام میدن، جواب دقیقی ندارن.

جواب‌هایی می‌شنوم مثل: "چون تیم x ازمون درخواست کرده"، "چون مدیر بخش y اینو گفته" یا "چون پروداکت منیجر توی تسک‌هامون قرارش داده".

چرا این موضوع مهمه؟

ندونستن اهداف سازمان و چرایی کارها تاثیرات مستقیمی روی عملکرد تیم داره:

برای مدیرها: نمی‌تونن تصمیم‌های دقیقی برای رسیدن به اهداف بگیرن. نمی‌دونن کجا باید سرعت بیشتری داشته باشن، کجا می‌تونن کیفیت رو بالاتر ببرن، و چه Compromise هایی قابل قبول هستن.

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

برای سازمان: نمیشه تیم رو برای رسیدن به اهداف همسو نگه داشت و حتی تعریف شفافی از موفقیت هم وجود نداره.

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


یک مثال عملی: پروژه بلک فرایدی

بیاید یه پروژه رو توی تیم مهندسی و محصول یه پلتفرم فروش آنلاین تصور کنیم و ببینیم دونستن اهداف یا ندونستن‌شون چه تاثیری روی مدل کار و تصمیم‌گیری میذاره.

شرح پروژه: یه پروژه شامل یک سری فیچر برای تخفیف و نمایش تخفیف‌های ویژه Black Friday تعریف شده و از تیم خواسته شده که اون‌ها رو اجرا کنه. این پروژه قراره به سازمان کمک کنه که به اهداف فروشش توی فصل آخر سال برسه و بتونه تعداد سفارش‌ها و سایز سفارش‌ها رو بالاتر ببره.

سه سوال کلیدی

مدیر یا رهبر تیم مهندسی با دونستن این اطلاعات میتونه این سوال‌ها رو بپرسه و اون‌ها رو با تیم به اشتراک بذاره:

۱. اگر کار انجام نشه چی میشه؟

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

۲. این کار چه ارزشی برای کاربران داره؟

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

۳. اگر این کار زودتر یا بهتر انجام بشه چه تاثیری داره؟

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

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


از تئوری تا عمل: تصمیم‌گیری آگاهانه

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

مثال‌های واقعی از تصمیم‌گیری:

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

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

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

درباره ساختار اجرایی: حتی ممکنه مدل مدیریت پروژه رو تغییر بده و مثلا از یک مدیر پروژه اختصاصی برای این کار استفاده کنه.

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


فریمورک عملی: چطور شروع کنیم؟

بیاید با درست کردن یه مدل ساده یه کمی کار رو راحت تر کنیم:

برای رهبرهای مهندسی:

۱. توی Planning ها این سوالات رو مطرح کنید:

  • این پروژه کدوم هدف سازمانی رو پوشش میده؟

  • اگر موفق نشیم چه اتفاقی می‌افته؟

  • موفقیت رو چطور می‌سنجیم؟

۲. اطلاعات رو شفاف به اشتراک بذارید:

  • توی کیک‌آف میتینگ‌ها context کامل رو توضیح بدید

  • اهداف سازمانی رو به زبان ساده و قابل فهم منتقل کنید

  • مثال‌های واقعی و ملموس بزنید

۳. فضای پرسیدن سوال رو ایجاد کنید:

  • تیم رو تشویق کنید که "چرا" رو بپرسن

  • وقتی مهندسین سوال می‌پرسن، پاداش‌شون بدید نه سرزنش

برای مهندسین نرم‌افزار:

۱. قبل از شروع هر Task، بپرسید:

  • این کار چطوری به کاربر کمک می‌کنه؟

  • اگر این کار نشه چه اتفاقی می‌افته؟

  • این کار تو بیگ پیکچر سازمان کجا قرار داره؟

۲. توی Daily ها و Review ها:

  • نگاهتون رو فقط به "کار تموم شد یا نه" محدود نکنید

  • درباره تاثیر کارتون صحبت کنید

  • به هم‌تیمی‌ها کمک کنید تا هدف کلی محقق بشه

۳. اگر جوابی ندارید:

  • سوال بپرسید! این حق شماست

  • از مدیرتون، از پروداکت منیجر، از هر کسی که می‌تونه کمک کنه


موفقیت یعنی چی؟ ارتباط با نتایج سازمان

اگر توی انجام کارها موضوع "چرایی" رو به درستی اجرا کردید، توی بررسی نتایج هم باید با نگاه به نتایج کلی سازمان نگاه کنید.

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

مثال از همون پروژه بلک فرایدی:

قبل: "یه باگ توی صفحه checkout پیدا کردم و فیکسش کردم چون تو تسکم بود."

بعد: "یه باگ توی صفحه checkout پیدا کردم که می‌تونست مستقیم روی conversion rate بلک فرایدی تاثیر بذاره. فیکسش کردم و تست کردم چون می‌دونم این پروژه چقدر برای اهداف Q4 شرکت حیاتیه."

تفاوت رو می‌بینید؟ در هر دو حالت باگ فیکس شده، ولی توی حالت دوم:

  • مهندس می‌فهمه چرا این کار مهمه

  • انگیزه برای انجام دقیق‌تر کار بیشتره

  • احتمال اینکه edge case ها رو هم چک کنه بالاتره

  • خودش رو بخشی از موفقیت سازمان می‌بینه


جمع‌بندی

وصل کردن اهداف تیم مهندسی به خروجی‌های سازمان یک انتخاب نیست، یک ضرورت است.

وقتی همه می‌دونن چرا دارن کاری رو انجام میدن:

  • تصمیم‌گیری بهتر میشه

  • کیفیت کار بالاتر میره

  • انگیزه و تعهد افزایش پیدا می‌کنه

  • تیم همسو می‌مونه

از فردا شروع کنید. یک پروژه رو انتخاب کنید و سه سوال کلیدی رو باهاش مرور کنید:

  1. اگر این کار انجام نشه، چه اتفاقی می‌افته؟

  2. این کار چه ارزشی برای کاربر داره؟

  3. اگر زودتر یا بهتر انجام بشه، چه تفاوتی می‌سازه؟

جواب‌ها رو با تیم به اشتراک بذارید و ببینید چطور روی تصمیمات و کیفیت کارتون تاثیر می‌ذاره.


چک‌لیست: سه سوال قبل از شروع هر پروژه

برای استفاده آسان، این سه سوال رو همیشه بپرسید:

□ اگر این کار انجام نشه، چه اتفاقی می‌افته؟

  • چه ریسکی برای سازمان ایجاد میشه؟

  • چه ارزشی از دست میره؟

□ این کار چه ارزشی برای کاربر داره؟

  • کاربر چطوری از این استفاده می‌کنه؟

  • چه مشکلی رو براش حل می‌کنه؟

□ اگر زودتر یا بهتر انجام بشه، چه تفاوتی می‌سازه؟

  • آیا زمان مهمه؟

  • آیا کیفیت بالاتر می‌تونه تاثیر بیشتری داشته باشه؟


اهدافسازمان
۱۵
۱
Ali Fazeli
Ali Fazeli
مهندس نرم افزار
شاید از این پست‌ها خوشتان بیاید