https://virgool.ir/feed/@karvan.jafiمدیر محصول، مشاور، توسعه دهندهfa2026-11-11 11:21:15https://files.virgool.ir/upload/users/746645/avatar/qAsBC9.jpeghttps://virgool.ir/@karvan.jafihttps://virgool.ir/@karvan.jafi/استار-برای-تازه-کارها-zpr0cyi2r8xoزبان این نوشتار، محاوره ای بوده و بر اساس تجربیات شخصی خودمه. هیچ داده و شواهدی برای اثبات این نوشتار وجود ندارد. اخیرا در چند نوبت متوجه شدم که دوستان زیادی برای تنظیم کردن رزومه خود بر اساس مدل استار دچار مشکل شدن. دغدغه هایی مانند نداشتن جایگاه شغلی که بتوانند تصمیمات کلان بگیرند یا تازه وارد بودن در صنعت و غیره. احساس میکنم بیشتر سوال ها و دغدغه ها ناشی از درک نادرست یا ناکامل این مدل هست برای همین سعی کردم یه چند نکته رو اینجا با هم مرور کنیم و چند مثال بزنم شاید بتونم کمکی کنم به نوبه خودم.تعریف ساده مدل استار (STAR) Situationاین تو قصه گویی همون تیکه - یکی بود یکی نبود - هستش. شما فقط باید بگید چی بود و چی نبود. مثلا من در فلان شرکت تازه استخدام شده بودم که ... یا از من خواسته شد که عضوی از تیم فلان باشم و ....، یا من وقتی که رو فلان برنامه کار میکردم، من به عنوان برنامه نویس در این شرکت ......Taskوظیفه شما چی بود. قرار نیست خیلی وظیفه خطیری باشه، حقیقت بهترین دوست شماست. من قرار بود به مدیرم کمک کنم، من قرار بود تسک های آسون رو انجام بدم، من قرار بود یه کار گِلی رو انجام بدم که کسی حاضر نبود انجامش بده و من جدید بودم زورشون فقط به من رسید، من قرار بود آموزش ببینم، قرار بود از رو دست بغل دستیم یاد بگیرم.Actionبه نظر من این خیلی مهمه، چون باید بگید چه جوری اون کاری که بالا گفتید رو انجام دادید، فرق شما با بقیه اینجا معلوم میشه. مثلا من با اشتیاق خیلی زیاد شروع کردم به انجام اون کار گِل و یه چیز جذاب توش پیدا کردم، من خیلی با علاقه هر روز با هم تیمیم کد میزدیم، من تسک های خیلی آسون رو سعی کردم با کیفیت خیلی بالا انجام بدم. من خیلی سریع تمرین های آموزشی رو انجام دادم.Resultنتیجه کار شما قرار نیست مسیر بشریت رو تغییر بده. همین که با علاقه، بدون مشکل با هم تیمی هاتون تسک هاتون رو انجام بدید میتونه یک پایان قشنگ باشه و چه بهتر که بتونید اینو کمّی هم بکنید. مثلا همکاری من در انجام دادن تسک های آسون بدون درگیر کردن بقیه تیم منجر شد که ما 100% ددلاین ها رو با موفقیت برسونیم. علاقه نشون دادن من در انجام دادن کارهای گِل باعث شد بقیه تیم هم بیان و کمک کن و کارایی تیم 10% بهتر شد. فالو کردن تصمیمات مدیرم باعث کاهش تنهش در تیم شد و ما پروژه رو 20 روز زودتر تحویل دادیم. من سریع تمرین هامو انجام دادم زور وارد تیم اصلی شدم و لود کار رو اعضای تیم رو 10% کم کردم. چند تا نکته ریز:استار خوبه ولی راه های رسیدن به یک جایگاه به تعداد آدم هاست. اگه میبینی نمیشه، یه فرمت دیگه رو انتخاب کن. یه جور دیگه حق مطلب رو ادا کن. ولی استاندارد ها و توصیه ها رو جدی بگیر.قرار نیست تمام برنامه نویس های دنیا، پرفورمنس برنامه رو ارتقا بدن. قرار نیست همه کار معماری و سینیوری انجام بدن. قرار نیست تصمیمات ما منجر به ارتقا بهره وری سازمان بشه. واقعیت رو بیان کنید. درسته که کسی نمیاد از شما آمار بگیره ولی کمّی کردن باید منطقی باشه. شما نمیتونید با 6 ماه سابقه کار یه باگی که کل تیم رو رو ماه گرفتار کرده رو دو روزه پیدا کنید. یا دروغ میگید، یا اون تیم خیلی داغون بوده، که جفتش بده.سوالی بود تو توییتر در خدمتم.کاروان جافیکاروان جافیFri, 22 Apr 2022 21:24:01 +0430https://virgool.ir/Appel-Sib/کانال-سوئز-و-باگ-سرور-لایو-ufivfqmia8i4در دنیای توسعه نرم افزار شاید چیزی ترسناک تر از باگ در سرور لایو نباشه. ترسناک هست چون ما نمیبینمشون ولی اونا وجود دارن و اون ها زمانی خودشون رو نشون میدن که اصلا انتظارشو نداریم. بعضی وقت ها حتی نمیتونیم این باگ ها رو توی محیط تست یا توسعه شبیه سازی کنیم، و در این شرایط که باگی در محیط لایو به خودشو نوشن داده، هر ثانیه مهمه و متاسفانه افرادی که بتونن کمک کنن کم و این باگ ها همیشه کسب و کار ما و مشتری های ما رو تهدید میکنن. این دقیقا اتفاقی بود که برای کشتی اور گیون در کانال سوئز افتاد - باگ سرور لایو.در این مدت هر وقت تصویر ماشین مکنده کوچیک کنار کشتی غول پیکر چند صد متری رو تو شبکه های اجتماعی دیدم یاد خودم و تیمم افتادم که جمعه بعد از ظهر داریم با سرور لایو یکی از مشتریامون سر و کله میزنیم که مشکلش رو حل کنیم. البته مسلما این دفعه خطا از سمت ما نبود و کسی هم از فضا تا حالا خطای ما رو ندیده.خلاصه من سعی کردم به این اتفاق از دید یک برنامه نویس نگاه کنم. نه برای اینکه چجوری جلوی این اتفاق ها رو بگیریم بلکه بیشتر درباره اینکه هنگام وقوع این اتفاق ها چیکار بکنیم.1- هیچ اهمیتی نداره اگه نرم افزار، سرویس یا وب سایت شما در طی 150 سال گذشته بدون مشکل کار کرده، اینو بدونید که همیشه یک باگ وجود داره. پس همیشه چیزی برای بهتر کردن هست.پس سعی کنید کد ها، راه حل ها و متد های خودتون رو ریفکتور کنید. کلید موفقیت زیاد ریفکتور کردن است. در غیر اینصورت ریفکتور کردن منجر به تولید باگ های بیشتر میشه جای بهبود برنامه. ریفکتور کردن باید در پوست و خون و فرهنگ تیم شما باشه.2- این رو باور کنید که قدم های کوچک شما در حل مشکل به وجود آمده با ارزش هستند. سعی کنید افکار منفی رو از خودتون دور کنید و توجهی نکنید که الان تیم ها دیگه چه فکری میکنند. تمرکز خودتون رو روی تخصصتون بذارید. اگه مشکل شما اندازه اون کشتی غول پیکر و شما اندازه اون مکنده زرد رنگ کوچیک هستید، باید روی مشکل تمرکز کنید و ادامه بدید. بعدا میشه به این فکر کرد که به مدیرتون چی بگید یا بقیه چجوری میخوان شما رو قضاوت کنند.3- مشکل رو سریع حل کن ولی یادت نره که بعدا بهترش کنی. بعضی وقت ها کد هایی که در شرایط خاص می نویسیم رو فراموش میکنیم چون کار میکنن و ترجیح میدیم ریسک نکنیم. ولی مطمئن باشید هر کدی که در این شرایط نوشته میشه باید بازخوانی و بازنویسی بشه، ترجیحا توسط یک برنامه نویسه دیگه. 4- یا تا یک ساعت دیگه این مشکل رو حل کن یا هیچ وقت - همچین چیزی معنی نداره. ما اینو خیلی وقت ها میشنویم - یا الان درست بشه یا به درد نمیخوره. یا تا اخر هفته آماده باشه یا دیگه کاربردی نداره - این غیر مفید ترین مشوقیه که می تونه تو این شرایط وجود داشته باشه. یک باگ در سرور لایو شما وجود داره. شما تمام تلاشتون رو میکنید که مشکل رو رفع کنید. اگر نتونستید تا یک ساعته دیگه مشکل رو رفع کنید، متوقف نمیشید. بلکه ادامه میدید. چون نمیتونید دست نگه دارید. مشکل باید رفع بشه. اگر غیر از این بود اون کشتی هنوز اونجا گیر کرده بود. پس همه تمرکزتون رو بذارید روی رفع مشکل.5- هیچ وقت باگ رو دست کم نگیرید.معمولا برنامه نویس ها، فیچر ها رو بر اساس پیچیدگیشون اولویت بندی میکنن ولی کاربر ها بر اساس نیازشون که اینها لزوما منطبق بر هم نیستند. پس اهمیتی نداره باگ چیه و کجاست، ساده است یا پیچیده. همه تلاش خودتون رو بکنید، به کاربر های خودتون متعهد باشید حتی اگه فقط چند کاربر دارید. ممکنه در کمتر از 150 سال، یک روز بعد از ظهر 369 کشتی منتظر این باشن که شما باگ سیستم تون رو رفع کنید فقط چون شما اونو جدی نگرفتید. این رو بدونید لحظه ای که شما فکر میکنید کسی از این فیچر برنامه استفاده نمیکنه، همون لحظه یه باگ سرور لایو به وجود میارید.نسخه اصلی متن https://karvan-jafi.medium.com/suez-canal-softwares-production-server-bugs-1525ac8b336bکاروان جافیکاروان جافیFri, 09 Apr 2021 13:05:59 +0430https://virgool.ir/@karvan.jafi/ماتریس-تخصیص-وظایف-raci-ph76ckhbzot6به زبان خیلی ساده، هدف ماتریس RACI، مشخص کردن نقش های افراد تیم فارغ از عناوین شغلی آن هاست. شما این ماتریس را در سطح تسک، اسپرینت و محصول میتونید مشخص کنید.Responsibleچه فرد یا افرادی باید کار رو انجام بدهند. این افراد متخصص انجام کار هستند. Accountableچه کسی باید پاسخگو باشد و کار رو ارائه دهد. این فرد تنها مرجع برای تائید پایان کار هست.Consultantدر صورت ابهام از چه کسی میتوان کمک گرفت. معمولا این افراد بیشتر از بقیه درباره کسب و کار محصول اطلاع دارند.Informerچه کسی رو باید در جریان وضعیت کار قرار داد. معمولا مدیران سطح بالاتر.ماتریس تخصیص وظایف RACIدر صورت استفاده از این فریم ورک مطمئن شوید که تمام اعضای تیم از وجود آن و نقش هایشان در این ماتریس مطلع هستند.نقش های افراد در ماتریس، می تواند مستقل از جایگاه سازمانی افراد باشد.اعضای تیم در طی زمان و بر اساس نوع کار می توانند نقش های مختلف داشته باشند. مهمترین نکته:این ماتریس تنها برای تیم های سالم میتواند کارا باشد. کاروان جافیکاروان جافیThu, 25 Mar 2021 15:05:28 +0430