https://virgool.io/feed/@rezakamalifard علاقمند به مطالعه و تحقیق fa 2026-06-10 14:48:05 https://files.virgool.io/upload/users/4873/avatar/avatar.png?height=120&width=120 https://virgool.io/@rezakamalifard https://virgool.io/@rezakamalifard/%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87-%D9%81%DB%8C%D8%AF%D8%A8%DA%A9-%DA%AF%D8%B1%D9%81%D8%AA%D9%86-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-uh2vv8y7daai توضیح و رفع مسئولیت: من روانشناس یا فعال در حوزه منابع انسانی نیستم یاداشت هایی که می‌نویسم حاصل تجربه خودم از کار در پست های مختلف در سازمان های متفاوت و مطالعه منابع و تحقیقات علمی هستن که لیست اونها در انتها آمدهفیدبک بسیار مهم و حیاتی هست. دلیل اش هم مشخصه: عملکرد رو بهبود می‌ده، استعدادها رو توسعه می‌ده، انتظارات رو همسو می‌کنه، مشکلات رو حل می‌کنه، پروموشن و درآمد رو تسهیل و هدایت می‌کنه و خروجی رو افزایش می‌ده.به همین اندازه ای که تاثیرهای خوب فیدبک مشخص هست با کمی تحقیق و نگاه کردن به اطراف می‌شه واضح دید که فیدبک و فرآیند اش تو خیلی از سازمان ها کار نمی‌کنه. یک نگاه کوچیک به آمار داستان رو نشون می ده: فقط ۳۶ درصد از مدیرا ارزیابی های عملکرد سازمانی رو به طور کامل و به موقع انجام می‌دن. در یک نظرسنجی ۵۵ درصد از کارمندان گفتن که آخرین بررسی عملکرد آنها ناعادلانه یا نادرست بوده و از هر چهار یک نفر گفتند که بیش از هر چیز دیگری در زندگی کاری خود از چنین ارزیابی هایی عملکردی می ترسن و تبدیل به کابوس شون شده. و براساس یک نظرسنجی اخیر گالوپ فقط ۱۴ درصد کارکنان معتقد هستن که ارزیابی عملکرد به اونا انگیزه ای برای بهبود می‌ده. وقتی از مدیران ارشد منابع انسانی در مورد بزرگترین چالش مدیریت عملکردشان سوال شد، ۶۳ درصد به ناتوانی یا عدم تمایل مدیران برای داشتن بحث های فیدبک دشوار اشاره کردن. پس اوضاع خیلی خوب نیست.بیشتر شرکت ها بعد از درک و دیدن این وضع سعی می کنن با آموزش رهبران شون برای ارائه فیدبگ مؤثرتر و مکرر به این مسائل رسیدگی کنن. ایده بدی هم نیست وقتی مدیران مهارت های ارتباطاتی بهتری داشته باشن، همه سود می برن. اما این همه داستان نیست اگر گیرنده فیدبک نتونه اونچه گفته شده را درست جذب و درک بکنه، بهبود و ارتقا مهارت های فیدبک دهنده نتیجه زیادی نداره. این گیرنده است که کنترل می‌کنه فیدبک رو بپذیره یا اون رو رها کنه و نشنیده بگیره،گیرنده کسی هست که باید چیزی رو که می‌شنوه معنا کنه و درک کنه و تصمیم بگیره که آیا چیزی تغییر بکنه یا نه. با همه این توضیحات می‌خوام بگم که خوبه که فقط روی خوب فیدبک دادن تمرکز نکنیم و در عوض توانایی خودمون را برای فیدبک گرفتن بهبود بدیم.با نگاه کردن به تجربه های کاری استخدامی و مدیریتی که نمونه هاییش رو در بخش منابع هم آوردم می‌شه گفت تقریباً همه، از تازه کارا گرفته تا کهنه‌کارا C-suite، با گرفتن فیدبک مشکل دارن.قضیه می‌تونه سریع و ساده پیچیده بشه مثلا یه بررسی عملکرد همراه با انتقاد، یه پیشنهاد حتی به ظاهر با نیت خوب، یا یه نظر که ممکنه فیدبک باشه یا نباشه می تونه یه واکنش عاطفی و احساسی رو تو آدم ها جرقه بزنه، رابطه ها رو به تنش بکشونه ، و ارتباط بین آدم ها رو کند یا حتی متوقف بکنه. با این همه یه خبر خوب هم وجود داره: مهارت های مورد نیاز برای فیدبک گرفتن به خوبی قابل یادگیری هستن.این میون مهم ترین چیز توانایی شناسایی و مدیریت احساسات ناشی از گرفتن فیدبک و استخراج ارزش از انتقاد حتی زمانی که به شکل مناسبی ارائه نشده هست.چه چیزی گرفتن فیدبک رو سخت می‌کنه؟این دشواری که خیلی ها دچار اش هستن از ناسازگاری بین دو تا نیاز اصلی انسان شروع می‌شه - نیاز به یادگیری و رشد و نیاز به پذیرفته شدن همان طور که هستی. در نتیجه، حتی یک پیشنهاد به ظاهر با نیت خیر می‌تونه شما را عصبانی، مضطرب یا تهدید عمیق بکنه و گفتن یه چیزی مثل "این را شخصی نکن" یا داشتن یه لحن شوخی هم هیچ تاثیری زیادی در کاهش آسیب احساسی ای که وارد می‌شه نداره.بهتر شدن تو گرفتن فیدبک با درک کردن و مدیریت این احساسات شروع می شه. ممکنه که فکر کنین هزاران راه وجود داره که فیدبک گرفتن می تونه شما رو از نظر احساسی تریگر کنه، اما تحقیقات روان شناس که نمونه هاییش رو در منابع اشاره کردم نشون داده که در واقع سه دسته راه تریگر شدن وجود داره:تریگر های حقیقت: با محتوای فیدبک تعیین می شن. مثلا وقتی که ارزیابی ها یا توصیه ها به نظر بی اساس، نامفید یا به خیلی نادرست به نظر می رسن، احساس خشم، ظلم و عصبانیت می کنین.تریگر های رابطه: در ارتباط با شخصی هستن که فیدبک رو می‌ده. اعتقادی که دارین در مورد فیدبک دهنده (اون هیچ اعتباری تو این موضوع نداره!) و احساس شما در مورد تعاملات قبلی تون (بعد از همه کارهایی که براتون انجام دادم، با انتقاد جای تشکر جواب ام رو می‌دی) شکل دهنده میزان تریگر شدن هستن. برای همین ممکن هست که نظری یا فیدبک ای رو از یک شخص رد کنین در حالی که اگه همون از طرف شخص دیگه ای باشه، بر اساس اعتبار اون فرد اون رو می پذیرین.تریگرهای هویت: در مورد رابطه شما با خودتون هستن. فیدبک درست یا نادرست، عاقلانه یا بیهوده، می تونه ویرانگر باشه اگه باعث بشه احساس شما در مورد اینکه چه کسی هستین از بین بره. تو چنین لحظه هایی به فشار خیلی زیاد،رفتن به حالت دفاعی یا میزون نبودن دچار می‌شین.همه این واکنش ها طبیعی و معقول و بعضا اجتناب ناپذیر هستن. راه حل این نیست که وانمود کنین اونها رو ندارین. اینه که تشخیص شون بدین و آگاه باشین که چه اتفاقی داره می افته و یاد بگیرین که چگونه نقطه های مثبت فیدبک رو ببینید، حتی وقتی که یکی یا چندتا از تریگر های شما رو فعال بکنه.توی بخش بعدی به این می‌پردازیم که چی کار کنیم تا فیدبک گیرنده بهتری بشیم. لطفا اگر مطلب برای شما مفید با دوستانتون هم به اشتراک بگذارید.منابع:https://journals.aom.org/doi/abs/10.5465/amr.2016.0002https://www.sciencedirect.com/science/article/pii/S0749597816301807https://www.gallup.com/workplace/249332/harm-good-truth-performance-reviews.aspx رضا کمالی‌ رضا کمالی‌ Mon, 29 May 2023 14:49:21 +0330 https://virgool.io/@rezakamalifard/%D9%85%D8%AD%DB%8C%D8%B7-%DA%A9%D8%A7%D8%B1-%D8%AE%D9%88%D8%A8-%DA%A9%D8%AC%D8%A7%D8%B3%D8%AA-f3vj8rjp4mce مدتی بود که تو فکر تغییر شغل بودم و به چند تا شرکت استارتاپی که می‌شناختم سرزدم همه این شرکت ها به دنبال جذب برترین نیروهای فنی ممکن بودن و می‌گفتن که به شدت در حال از دست دادن نیروهای متخصص به دلایل مختلف مثلا مهاجرت هستن و برای جذب نیروهای فنی هر کاری در توانشون باشه می‌کنن مثلا امکانات مختلفی رو در اختیار کارکنان شون قرار می‌دادن که بسیار جالب بود مثل ESOP،(برنامه مالکیت سهام برای کارکنان) غذای رایگان، تهیه هر وسیله ای که برای کارکردن لازم هست، مراقبت های پزشکی، بیمه تکمیلی، دادن وام های کمک هزینه،پارکینگ، یک سرسره که انتهاش یخچال هست و…به عنوان کسی که این مدت به دنبال محل کار جدید می‌گشتم بعد از دیدن شرایط این نظر رو داشتم که دادن این امکانات به کارکنان یک سازمان باعث نمی‌شه که یه سازمان بد که درست کار نمی‌کنه (dysfunctional) و فرهنگ مناسبی نداره کارا بشه یا فرهنگ سازمان بهبودی پیدا بکنه. یه شرکت بد با وجود همه این امکانات هنوز هم یه شرکت بد هست. این موارد قطعا تو تصمیم گیری در مورد انتخاب بین دو تا شرکت خوب تاثیر گذارن ولی موارد مهم تری هم هستن. من سعی کردم مواردی که تو بررسی و انتخاب شرکت ها بهشون دقت بیشتری دارم رو مطرح کنم شاید تجربه من به ارزیابی محیط های کاری که شما می‌خواید به اون برید کمک بکنه.اولین و مهم ترین چیزی که بهش دقت می‌کنم مربوط به افرادی هست که در سازمان هستند. هم کسانی که در مصاحبه می‌بینم و هم کسانی که از اون شرکت می‌شناسم و باهاشون در ارتباط هستم. من همیشه دنبال کار درسازمانی بودم که افراد باهوش، خلاق و مهربونی داشته باشه. باهوش و خلاق برای اینکه وقتی همکار شدیم در تعامل با این افراد چیزهای بیشتری یاد بگیرم و کارهای جدیدی بکنم تا چالش های تازه تجربه کنم و مهربون باشن تا حاضر باشن که چیزهایی که می‌دونن و تجربه هاشون رو به اشتراک بذارن.مورد مهم دیگه این هست که من محیط مبتنی بر همکاری و گفتگو رو به محیط رقابتی و پرخاشگرانه ترجیح می‌دم. فضایی به نظر من بیشتر از همه موثرهست که در اون تصمیم ها با خرد جمعی گرفته می‌شه و گردش آزاد اطلاعات وجود داره. برای فهمیدن این مورد می‌تونید ازاعضا تیم ها سوالاتی بکنید تا ببینید که آیا نقشه راه و اهداف سازمان برای افراد در موقعیت های مختلف روشن هست و دیدی یکسانی و همسویی از مسیر دارند یا نه.فضای کسب و کار و استخدام این روزها خیلی رقابتی هست همزمان شرکت های زیادی هستند که تو این فضا کارایی بسیار پایینی دارن و برای حل این مشکلات شون به دنبال افراد قهرمان یا راه حل های جادویی می‌گردن.به نظر من قهرمان پروری مشکلاتی زیادی برای خود شرکت و افرادی که در شرکت کار می‌کنند ایجاد می‌کنه و محیط رو به سمت رقابتی و پرخاشگرانه شدن می‌بره. هر چقدر هم که فرد مورد نظر با تجربه باشه تجربه ای که از محیط دیگه ای داره ممکنه مسئله فعلی رو حل نکنه و جای گفتگو و تعامل با تیم و ضینفعان رو نگیره. صحبت کردن و فیدبک دادن به افراد در محیط قهرمان پرور کار سختی هست پذیریش انتقاد برای قهرمان کار بسیار سخت تری.تو این مدت با شرکت هایی حرف زدم که می‌گفتن فضایی مبتنی بر همکاری و خرد جمعی دارن و با این موارد مخالف هستن ولی آگهی های شغلی ای که داشتن نشون می‌داد که دنبال یک قهرمان، نینجا و یکی که همچی رو می‌دونه خیلی با تجربه است و… می‌گردن و معتقد هستن با اومدن اون فرد تمام مشکلات شون حل می‌شه.یک مورد که خیلی تاثیر گذاره برای تصمیم گیری بررسی میزان عدم کارایی و dysfunctional بودن تیم هاست. هرچقدر تیم ها عدم کارایی بالاتری داشته باشند ایجاد تغییر و بهبود فرآیند ها مشکل تر و زمان برتر میشه. یه راه بررسی کردن این موضوع به عنوان کسی که برای مصاحبه و شروع همکاری با سازمانی در ارتباط هست پرسیدن سوال از افراد مختلف در سازمان و بررسی همگام و همجهت بودن نظرات افراد در مورد یک موضوع مرتبط به تیم و کارکرد تیم هست. مثلا من از افراد یک تیم می‌پرسم که چطوری می‌فهمند کار جدیدی که باید بکنند چی هست و چطور جزئیاتش بهشون منتقل می‌شه.موردی که همیشه برام تاثیر گذار بوده به طور شخصی حفظ کرامت و ارزش افراد در هر رتبه ای از سازمان هست مثلا اگر دیدید که جایی مدیران مورد محبت و چاپلوسی دیگران قرار می‌گیرد ولی کارکنان رده پایین تر در سازمان یا مثلا نیروهای خدماتی در شرایط نامناسبی کار می‌کنند یا رفتار درستی باهاشون نمی‌شه یا عضوی از تیم دیده نمی‌شوند و به رسمیت شناخته نمی‌شن ( مثلا این امکانات که به شما گفته شده در اختیار کارکنان قرار می‌گیره در اختیارشون نیست) در کار کردن تو اون سازمان شک کنید. هر کسی در هر جایگاهی که هست باید شناخته بشه کرامت و سلامتی اش حفظ بشه و امکانات مربوط کار کردن اش در اختیار اش قرار بگیره.اعتقاد رهبران سازمان به مدل رهبری Transformational نکته خیلی مثبت ای می‌تونه باشه. این که همیشه رهبران در کنار تیم ها باشن تا نیازها رو تشخیص بدن و ارزش هایی بسازن که تغییرات رو در سازمان با همکاری و همراهی تیم های مختلف جلو ببره و همیشه تشویق بکنه تا تیم ها و افراد خودشون رو صاحب کاری که می‌کنند بدونن و با جسارت بیشتری کار بکنند. این مورد رو هم می‌شه با صحبت کردن با افراد تیم و رهبران در مورد تجربه های کاری شون و حل مشکلات و تعیین نقشه راه سازمان بفهمید.قطعا به جز این موارد مسائلی مثل محل کار و امکانات اش دور و نزدیکیش به محل اقامت تون، برند سازمان همچنین برند کارفرمایی سازمان و… هم تو انتخاب تاثیرگذار هست و شرایط یک trade-off ای هست بین ارزش های شما، درآمدتون و امکانات سازمان ای که قرار هست در اون کار کنید. لطفا اگر موارد دیگه ای رو هم در نظر دارید در کامنت ها بگید تا این پست کامل تر بشه. رضا کمالی‌ رضا کمالی‌ Sun, 10 Nov 2019 11:25:20 +0330 https://virgool.io/@rezakamalifard/%D8%AA%DB%8C%D9%85-%D9%84%DB%8C%D8%AF%D8%B1-%D9%81%D9%86%DB%8C-%D8%A8%D8%AE%D8%B4-%D8%A7%D9%88%D9%84-%D9%82%D9%87%D8%B1%D9%85%D8%A7%D9%86-%D9%86%D8%B4%D9%88-mxzi8e4xrbz1 من حدود چهار سالی می‌شود که تیم لیدر فنی‌ام و تو این مدت تو تیم های سه تا ۱۰ نفری کار کردم.برای من تیم لیدر شدن خیلی اتفاقی پیش اومد و قصه‌اش به زمانی بر می‌گرده که از طرف شرکتی که درش کار می‌کردم از من خواسته شد یک تیم توسعه برای محصول تشکیل بدم و مدیریتش کنم. اون روزها تجربه‌ای در این زمینه نداشتم و با این وجود این پیشنهاد به من شده بود، شاید بنظر موقعیت ترسناکی بیاد، اما درهمون شرایط بود که تصمیم گرفتم این پیشنهاد رو تبدیل به فرصتی برای رشد فردی خودم کنم وهمین تصمیم باعث شد که از اون موقعیت تجربه های زیادی به دست بیارم و تو این نوشته می‌خوام یکم از همین تجربه‌ها با شما به اشتراک بذارم.قهرمان نشو!تیم لیدرهای فنی، خصوصا کسایی که تازه این کار رو شروع می‌کنن؛ سعی می‌کنن قهرمان تیم و حل کننده همه مشکلات باشن.تجربه من نشون می‌ده که این اشتباهه و ضررهای زیادی به تیم و شما می‌رسونه.وقتی کسی باشید که همه‌چیز رو می‌دونه و برای هر سوالی یه جوابی داره؛ پیش خودتون اینطوری به نظر میاد که دارین خیلی کار می‌کنین و همه چیز داره با توجه به خرد و دانش شما جلو می‌ره؛ درحالی که از دور اینطوری به نظر می‌رسه که نشستین یه جا و به تیمتون می‌گین «این کارو بکن و این کار رو نه!» من فکر می‌کنم که اگر تیم‌لیدر باشین این شرایط رو تجربه کردین، چون هر کسی که در این موقعیت قرار می‌گیره دانش و تجربه اینو داره که سوال‌های زیادی رو جواب بده. یعنی از پیچیده ترین سوال‌ها تا هر چیزی که ممکنه با یه سرچ کوچیک بشه جواب‌اش رو پیدا کرد.این وضعیت الزاما چیز بدی نیست. وقتی که تیم لیدر می‌شین یه بخشی از کار شما مثل هر عضو دیگه‌ای از تیم؛ اینه که به بقیه کمک کنید و سوال‌هاشون رو جواب بدید. شما با توجه به تجربه بیشتری که دارید احتمالا بهتر از هرکس دیگه ای می‌تونین این کار رو انجام بدید.این وضعیت به شما حس قهرمان بودن می‌ده. راستش، کی از قهرمان بودن و در مرکز توجه قرار گرفتن بدش میاد؟شما می‌توانید قهرمان تیم باشید اما قبلش باید بررسی کنیم که این چه تاثیری رو تیم شما می‌تونه بذاره.اگر قصه‌ی قهرمانی شما ادامه‌دار باشه؛ احتمالا اعضای تیم شما عادت می‌کنن همه چیز رو از شما بپرسن و مسئولیت همه چیز بر دوش شما خواهد بود.شما با این کار به تیم تون یاد می‌دین که بدون شما کاری رو نکنن و با توجه به این که کار همه رو شما راه می‌ندازین تبدیل می‌شین به کراش هم تیمی هاتون و شاید مقبولیت زیادی هم به دست بیارید چون شما قهرمان‌اید و کلید حل همه مشکلات دست شماست و کس دیگه‌ای قرار نیست خیلی کار مهمی بکنه یا اگر بخواد بکنه باید منتظر نظر شما برای بخشی از کارش باشه. همه کم کم به این نتیجه می‌رسن که شما جواب همه‌ی سوال‌ها رو دارید و همه‌چیز رو می‌دونید و خب برای هرمشکلی یا هرمسئله و تصمیمی پیشت میان که قطعا وقت خیلی زیادی خواهد گرفت و شما رو از انجام مسؤلیت‌های اصلی‌تون مثلا تمرکز روی مسائل اعضا تیم و موفقیت شون یا رشد شخصی تون دور می‌کنه. علاوه بر این از همه مهم تر شما رو تبدیل می‌کنه به یک شخص کلیدی که همچی بهش وابسته هست و تقریبا هیچ کاری و تصمیم مهمی بدون حضور و نظرش نمی‌شه گرفت. کم کم آدم ها بیشتر و بیشتر به این مسئله عادت می‌کنن و مشکل کمبود وقت برای شما جدی‌تر می‌شه و دیگه وقت آزادی نخواهین داشت و نمی‌تونین بخوابین یا با خیال راحت یه سفر برین یا یه روز بدون دغدغه های کاری داشته باشید زیاد می‌شه که آخر وقت ها شما رو دید که تنها پشت میزتون نشستین و دارین سعی می‌کنین کارهایی که برنامه انجام شون برای اون روز بوده ولی بهش نرسیدین رو انجام بدید با خستگی زیاد و با دقت پایین و عجله بسیار. این حس خوب قهرمان بودن شاید به طور موقت برای شما حس خوبی باشه ولی شما جلوی پیشرفت کردن و رشد تیم تون و خود شما رو با این می‌گیره و کارکرد صحیح تیم رو شدیدا به شما و حضورتون وابسته می‌کنه.هر تیم دو تا محصول داره یکی خروجی تیم و رسیدن به اهداف کاری هست و یکی خود تیم اعضاش و این که رشد بکنند. که دومی یعنی رشد فردی آدم ها به این که خروجی تیم بهتر باشه بسیار کمک می‌کنه و اثرپایداری رو تیم خواهد داشت.اما خب، برای حل این مشکل چه کار می‌شه کرد؟ اصلا چطوری باید جواب داد ؟ وقتی سوالی یا مشکلی مطرح می‌شه که ما جوابش رو می‌دونیم یا شرایطی در کار پیش می‌یاد که ما مطمئن هستیم می‌تونیم به راحتی اون رو حل کنیم مثلا با مداخله در بحث ای بین دو نفر از اعضا تیم همه مون با این حس مواجه می‌شیم که سریع جواب اش رو بدیم که اگر همیشه همین کار رو بکنیم می‌تونه عادت های منفی که بالا در موردش صحبت کردیم رو در تیم و در خود ما ایجاد بکنه و تبدیل به سدی در برابر پیشرفت تیم بشه اما به جز این که بخوایم سریع جواب بدیم یا مشکل رو حل کنیم چه کارهای دیگه ای می‌شه کرد؟من سعی کردم که تو این مسائل اول بگم که مسئله رو کاملا درک می‌کنم و بلافاصله از خود طرف بپرسم که چه راه حلی یا ایده ای برای حل کردن مسئله داره؟ و اجازه بدم که اون حرف بزنه و ایده ای که داره رو در میون بذاره.باید سعی کنیم که کمک کنیم افراد مشکل شون رو به شکلی برطرف بکنن که راه حل رو یاد بگیرن و رشد بکنند.چیزی که اینجا ممکنه برای شما آزاردهنده باشه این هست که افراد بخوان مسئله رو به شکلی حل بکنن که با راه حلی که شما می‌دونید متفاوت هست و شما بدونین که این راه حل ایراداتی داره.اینجا معمولا دو حالت مطرح هست این که ایراداتی که وجود دارند منجر به اشتباهات حیاتی برای کسب و کار مثلا از دست دادن درآمد یا ایجاد هزینه خیلی زیاد می‌شن یا خیر و اگر هزینه زیادی ندارند اجازه بدید که افراد تصمیماتی که گرفتند رو اجرا کنند حتی اگر به نظر شما اشتباه هستند. خیلی از مدیر هایی که دیدم می‌گن وقتی کسی میاد پیششون و تصمیمی گرفته که روی اون تحقیق کرده و جوانب مختلف اش رو سنجیده مانع انجامش نمی‌شن مگر این که از نظرشون مشکل قطعی ای ایجاد بکنه که ضرر غیر قابل جبرانی داشته باشه، در صورتی که می‌دونن اون تصمیم اثرخیلی مخربی داره افراد رو راهنمایی می‌کنن که تصمیم شون ممکنه چه جوانبی رو داشته باشه که در نظر نگرفته باشن یا در موردش تحقیق ای نکرده باشن. وقتی می‌دونیم که یک تصمیم می‌تونه مشکلی ایجاد بکنه بهتر هست که اینطوری نظرمون رو بیان کنیم که این ایده به نظر من به این دلیل خوب نیست و ممکنه دقیقا چه ایراداتی داشته باشه بهتره که در مورد این نگرانی هم تحقیق بکنیم و اون رو در نظر بگیریم و در این شرایط ممکنه نگرانی شما رفع بشه با بررسی اون جوانب یا این که خود شخص به این نتیجه برسه که راه حل به دلایلی که شما مطرح کردید راه حل خیلی خوبی نیست. خیلی مهم هست که شما دقیق و روشن نگرانی ای که دارید یا ایرادی که وجود داره رو به شخص مورد نظر منتقل کنید. شما به عنوان مسئول باید حتما روش هایی رو داشته باشید که مطمئن بشید که اشتباهات خیلی حیاتی رخ نمی‌دن و ازشون جلوگیری کنید ولی در نهایت باید به افراد فضایی بدید که بتونن شکست بخورن تا تجربه کنند و یاد بگیرند. اگر به کارهایی که در تیم می‌کنیم نگاه کنید می‌بینید که ما خیلی وقت ها شکست می‌خوریم و نباید از این شکست ها بترسیم چون فرصت مهمی برای یادگیری و رشد هستند.وقتی یکی با یک سوال یا یک مسئله پیش ما میاد به عنوان تیم لیدر بدترین کار این هست که بگیم اوکی مرسی که اینو بهم گفتی من حلش می‌کنم یا من بهش فکر می‌کنم و راهی به ذهنم رسید بهت می‌گم تو نگرانش نباش. یکی از سوال های اساسی ای که می‌شه از آدم ها پرسید و من همیشه سعی می‌کنم تکرار کنم این هست که تو فکر می‌کنی چه کاری می‌تونیم برای حل این مشکل بکنیم؟ بعد هم می‌پرسم که تو می‌خوای من دقیقا چه کاری بکنم در این زمینه؟ خیلی وقت ها آدم ها فقط دنبال فیدبک ما هستن در مورد راه حلی که دارن تا برن روش کار بکنن نه این که از ما بخوان که خودمون در انجام کار یا حل مشکلی که با یک هم تیمی یا شخصی از تیم دیگه ای داریم مداخله ای بکنیم خوبه که حتما ازشون بپرسیم که دقیقا چه چیزی از ما می‌خوان ممکنه ما اشتباه فکر کنیم که دنبال این هستن که ما راه حلی برای حل مشکل بهشون بدیم و اونا هم فکر کنن که آزادی کافی رو ندارن و ما داریم Micromanagement می‌کنیم. حتی اگر افراد به راه حل هم فکر نکرده باشن این رفتار اعتماد به نفس کافی رو بهشون می‌ده که بهش فکر بکنند و دنبال راه حل بگردن و هر ایده دارن رو بیان کنن.راه حل دیگه که خیلی موثر هست پرسیدن این سوال از خودمون هست که چه کس دیگه ای می‌تونه تو تیم به حل این مسئله کمک بکنه می‌تونیم از اون بخوایم که کمک بکنه به شخصی که داره سوال می‌کنه تا ما تبدیل نشیم به تنها کسی که می‌تونه به سوال ها و مسائل جواب بده. میتونیم از شخص بخوایم که بره و با شخص دیگه پارتنر بشه تا مسئله رو با هم حل کنند و ما هم سعی کنیم که در جریان کارهایی که می‌کنن قرار بگیریم و اگر دانشی اینجا ایجاد می‌شه این دانش در دسترس دیگران هم قرار بگیره. علاوه بر خود جواب به مسئله روش پیدا کردن این جواب هم می‌تونه داکیومنت بشه و در دسترس بقیه قرار بگیره.یک تجربه هم خیلی ملموس دیدم تو تیم لیدرها این که اگر تمام وقت ما صرف جواب دادن به سوال ها دیگران و حل کردن مشکلاتی بشه که خودشون می‌تونن به راحتی حل بکنند یا یاد بگیرند که حل بکنند وقتی برای کار کردن و دیدن پیشرفت سیستم باقی نمی‌مونه برای ما باقی نمی‌مونه سیستم به سرعت تغییر می‌کنه و ما از دیدن و فهمیدن تغییراتش باز می‌مونیم و ناگهان می‌بینیم که دیگه خیلی چیز زیادی از این سیستم جدید ایجاد شده نمی‌دونیم. رضا کمالی‌ رضا کمالی‌ Wed, 16 Oct 2019 11:16:14 +0330 https://virgool.io/@rezakamalifard/%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87-concurrency-control-%D8%AF%D8%B1-rest-api-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-qzvxrutaeeoz قسمت اول - Lost Update Problemتجربه تا حد زیادی ثابت کرده که وقتی دارید یک API وب طراحی می‌کنین متدهایی که resource های موجود رو تغییر می‌دهن و دست کاری می‌کنن می‌تونن چالش های طراحی خیلی زیادی داشته باشن. دو تا از مهم ترین چالش های طراحی idempotency و concurrency control ( کنترل همروندی) هستن.تو این پست من سعی می‌کنم با توجه به تجربه ای که تو طراحی API برای چند تا سرویس به دست آوردم و مطالعه ای که داشتم (که شرح اش رو توی لینک های داخل پست می‌دم) مختصری در مورد یکی از مشکلات concurrency control توضیح بدم.تداخل concurrency که ما قصد داریم بررسی کنیم مربوط به زمانی هست که یک کاربر سعی داره resource ای رو تغییر بده که از زمانی که کاربر اطلاعات اون resource رو دریافت کرده تغییر کرده ( احتمالا توسط یک کاربر دیگه). مثلا فرض کنیم که علی و سارا به طور همزمان یک resource رو GET کنند که اطلاعات یک پست وبلاگ رو به ما برمی‌گردونه هم علی و هم سارا پست وبلاگ ما رو می‌بینن علی توی پست یک غلط املایی پیدا می‌کنه اون رو اصلاح می‌کنه و یک درخواست PUT برای اصلاح کردن دیتا به سرور ارسال می‌کنه. سارا هم در همون زمان‌ها در حال خوندن پست هست و تصمیم می‌گیره که بخش هایی از پست وبلاگ رو آپدیت کنه و شروع می‌کنه به اضافه کردن یک متن به پست و بعد درخواست PUT ای رو به سرور می‌فرسته و متن بلاگ رو به روزرسانی می‌کنه در این جا سارا از تغییراتی که علی روی پست داده خبری نداره و بعد از انجام درخواست سارا تغییراتی که علی داده گم می‌شه و دیگه در دسترس نیست. به این مشکل Lost Update Problem گفته می‌شه. در این جا حتی اگر سارا می‌خواست مثلا فیلد دیگری مثل عنوان پست را هم عوض کنه به دلیل یکسان بودن endpoint این resource دچار همین تداخل می‌شه.حداقل کردن عواقب در زمان رخ دادن تداخلکم کردن احتمال ایجاد عواقب ای که انتظارش رو نداریم در زمانی که تداخل‌های همروندی (concurrency conflicts) رخ می‌ده روش ساده اما بعضی وقتا موثر برای کنترل شرایط همروندی هست می‌تونیم با یک سری کارها احتمال پیش آمدن این عواقب رو کم کنیم.مثلا در عمل می‌تونیم فقط فیلد هایی رو به‌روزرسانی کنیم که کاربرنهایی قصد به‌روزرسانی کردن آن ها را داره. تو مثال بالا اگر سارا فقط عنوان پست رو عوض می‌کرد ما می‌تونستیم از ایجاد عواقب ای که منتظرش نبودیم ( گم شدن تغییرات علی) جلوگیری کنیم. این روش احتمال ایجاد این تداخل ها رو کم می‌کنه. این روش رو می‌شه با استفاده از endpoint های متفاوت برای فیلد های مختلف یا استفاده از PATCH به جای PUT و ارسال فقط فیلد هایی که نیاز به به‌روزرسانی دارن انجام داد.اگه با توجه به طراحی امکان این وجود داشته باشه که به طور کلی تغییردادن و به‌روزرسانی روی resource انجام نشه و بدون تغییر بمونه. تداخل‌های هم روندی می‌تونن به طور کلی از API حذف بشوند.کنترل همروندی خوش‌بینانه (Optimistic concurrency control)اگه بخوایم یک استراتژی برای کنترل همروندی داشته باشیم optimistic locking می‌تونه بهترین انتخاب ما باشه. optimistic locking به این صورت هست که یک کار رو انجام بدی و بعد ببینی اگر resource از زمانی که آخرین بار دریافت شده تغییری داشته تغییرات رو رد و باطل کنی در غیر این صورت تغییرات بدون مشکل هستن. optimistic locking (قفل‌گذاری خوش‌بینانه) در برابر pessimistic locking (قفل‌گذاری بدبینانه) که توی اون یک resource قبل از اون که به‌روزسانی بشه در برابر تغییر کردن قفل‌گذاری می‌شه و بعد از به‌روزرسانی آزاد می‌شود قرار داره. با توجه به این که pessimistic locking نیاز به نگه داشتن state در سمت سرور دارد خیلی مناسب RESTful API ها نیست که در اون‌ بهتر هست که سرور به صورت stateless نگه داشته شود.روش کلی قفل‌گذاری خوش‌بینانه به این صورته که توی payload دیتا یا header ها از سمت سرور یک مقدار ارسال بشه که نشان دهنده نسخه ای از resource باشه که کاربر تغییر می‌دهه. اگر نسخه resource تغییر پیدا کرده باشه تغییراتی که کاربر ارسال کرده باید باطل بشه. به عنوان مثال نسخه می‌تونه یک عدد باشه یا hash مربوط به resource تغییر نیافته و باید با تغییر کردن resource این مقدار هم تغییر بکند.می‌تونیم نسخه رو در زمان ارسال درخواست برای تغییردادن resource به عنوان بخشی از payload استفاده کنیم یا از If-Match در header درخواست استفاده کنیم که در مشخصات HTTP/1.1 معرفی شده به این صورت در زمان وجود تداخل status جواب برابر مقدار 412 (Precondition failed) خواهد بود.همون طور که دیدین به عنوان مکانیسم کنترل همروندی قفل‌گذاری خوش‌بینانه یک روش ساده و قدرتمند هست و پیاده سازی اون سرراست و ساده است.برای پیاده سازی این روش می‌تونیم از header Etag به عنوان شناسه نسخه تو گرفتن اطلاعات resource و header با کلید If-Match در ارسال درخواست استفاده کنیم تا به سرور این امکان رو بدیم که تصمیم بگیره (با استفاده از روشی که در بالا شرح داده شد)که resource باید به‌روزرسانی بشه یا نه.با این کار سرور می‌تونه به کاربرنهایی اطلاع بده که resource از زمانی که کاربر اطلاعات اون رو دریافت کرده تغییر کرده. سرور این کار را با ارسال Precondition Failed انجام می‌دهد که باعث می‌شه از ایجاد مشکل Lost Update Problem جلوگیری بشه و کلاینت می‌تونه با اطلاع دادن به کاربر نهایی (یا هر روش دیگری) با reload کردن مقادیر امکان دریافت تغییرات جدید رو به کاربر بده تا تغییرات لازم رو بده.کنترل همروندی انتخابیبا بررسی کردن تعدادی از معروف‌ترین API های عمومی مثل Github، Spotify و etcd می‌تونیم ببینیم که روش هایی که به کار می‌ره بسیار مختلف هستند از روش‌های سخت‌گیرانه تا به کار نگرفتن هیچ روشی برای کنترل همروندی ( آخرین درخواست برنده می‌شه و تغییرات اون جایگزین می‌شن) رو می‌شه دید. روشی که بیشتر مرسوم هست استفاده از کنترل همروندی انتخابی (Opt-in) هست به عنوان مثال در API های Spotify می‌تونیم یک فیلد اختیاری snapshot_id رو ارسال کنیم در درخواست های تغییر تا سرور بتونه براساس اون تصمیم بگیره که تغییرات رو قبول یا رد بکنه. اما در صورتی که این فیلد رو ارسال نکنیم درخواست آخر برنده می‌شه و تغییراتش اعمال می‌شه. این نوع کنترل همروندی که اجباری نیست این امکان رو به استفاده کننده های API می‌ده تا براساس نیازی که دارند از این امکان استفاده بکنند یا تصمیم بگیرند که درخواست آخر برنده باشد.پ.ن:منابع این نوشتار برای مطالعه بیشتر (+++) رضا کمالی‌ رضا کمالی‌ Wed, 29 Aug 2018 14:12:26 +0430 https://virgool.io/@rezakamalifard/%D8%AF%D8%B3%D8%AA%D9%88%D8%B1%D9%87%D8%A7%DB%8C-%DA%AF%DB%8C%D8%AA-%D9%86%D8%AC%D8%A7%D8%AA%D8%AF%D9%87%D9%86%D8%AF%D9%87-nixsdbrisp01 کار کردن با گیت سخت هست و وقتی پیچیده تر می‌شه که یه حالت خاصی پیش بیاد و مثلا یه اشتباهی بکنیم. تو این مدتی که با گیت توی پروژه های مختلف کار می‌کردم یه سری دستوراتی هستن که خیلی به درست کردن این اشتباها کمک می‌کنن و در واقع یکی از ویژگی های مهم یه سیستم کنترل نسخه مثل گیت همین هست.در ادامه پست یک سری از این دستور ها رو با هم بررسی می‌کنیم. اینا بهترین راه حل ها نیستن و اگر راه حل بهتری برای انجام این کارهای سراغ داشتید لطفا حتما توی کامنت ها بگید تا به پست اضافه کنم.وقتی که یه چیز رو اشتباه کامیت کردی و می‌خوای ببینی می‌تونی به گذشته برگردی و دوباره کامیت کنی (گیت ماشین زمان)git reflogبا دستور پایین می‌تونی یه لیست از تمام تغییراتی که این اواخر روی همه برنچ‌ها دادی ببینی که هر کدوم شون یه ایندکس دارن به این صورتHEAD@{index}کافیه توی لیستی که می‌بینی اون ایندکسی رو پیدا کنی که یکی قبل از جایی باشه که همچی رو خراب کردی و دستور پایین رو بزنی ( ایندکس رو با ایندکس مورد نظرت جایگزین کنی)git reset HEAD@{index}این دستور بیشتر وقتایی کاربرد داره که یه چیزی رو تو برنچ اشتباهی کامیت کردی یا فایلی رو اشتباهی پاک کردی یا مثلا یه مرج انجام دادی که کلی مشکل درست کرده و می‌خوای برش گردونی.وقتی که تمام تغییرات رو کامیت کردی ( با کلی فکر کردن روی پیام اش) و می‌فهمی که یه چیز خیلی کوچیک رو یاد رفته اضافه کنی (گیت اصلاح‌گر)وقتی که نیازه یه سری تغییرات نهایی انجام بدی ولی می‌خوای که داخل همون کامیت قبلی باشه. اینجا چیزی که خیلی به کار می‌یاد استفاده از قابلیت amend (اصلاح کردن) کامیت های گیت هست.استفاده ازش به این صورت که بعد از کامیت ای که کردی دوباره تغییراتی که مدنظرت هست رو بدی و فایل هایی که باید به آخرین کامیت اضافه بشن رو با استفاده از دستور add اضافه کنی و بعد دستور زیر رو بزنیgit commit --amendاین دستور اصلاح‌گر یه کاربرد دیگه هم داره با این دستور می‌تونی پیام کامیت آخری که کردی و مشکلی داره رو اصلاح کنی.اشتباهی یه چیزی رو روی مستر کامیت کردم که باید توی یه برنچ جدید کامیت می‌کردم ( گیت ذخیره‌گر)این خیلی پیش میاد برای من. معمولا این روزا خیلی‌ها از فیچر برنچ استفاده می‌کنن و روی مستر به طور مستقیم کامیت نمی‌کنن. ممکنه اشتباهی چیزی رو کامیت کرده باشی باید جای دیگه ای (برنچ دیگه ای) کامیت می‌کردی. خوب اول یه نفس عمیق بکش و بعدش اول آخرین کامیت ای که کردی رو بی اثر کن و به حالت قبل برگردونgit reset HEAD~ --softبعد از زدن دستور بالا می‌تونی تمام تغییرات ای که داری رو توی مخزن گیت ذخیره کنیgit stashحالا برو به برنچ درستی که باید روش کامیت می‌کردی و تغییرات رو از مخزن گیت بازیابی کنgit stash popخوب حالا می‌تونی تمام تغییرات رو کامیت کنی اونم روی برنچ درست!در این مورد مقاله اصلی ای که من ازش به عنوان منبع برای نوشتن این پست فارسی استفاده کردم جدیدا یه روش دیگه رو هم پیشنهاد کرده که از قابلیت cherry-pick گیت هست که با اون می‌تونی کامیت ها رو از یک برنچ به برنچ دیگه این منتقل کنی اینجا کامیت های مستر رو می‌تونی به برنچ صحیح منتقل کنی.اول به برنچ صحیح ای که باید کامیت های روی اون انجام بشه برین. برای آوردن کامیت از برنچ مستر دستور پایین رو بزنین ( می‌تونه از یه برنچ دیگه باشه که خوب کافیه فقط اون بخش اسم برنچ رو عوض کنی)git cherry-pick masterبه این صورت کامیت منتقل می‌شه به برنچ ای که داخلش هستی و بعد از این دستور می‌تونی به برنچ مستر بری و تغییرات رو اونجا بی اثر کنیgit reset HEAD~ --hardوقتی که گیت diff می‌زنم هیچ چیزی دیده نمی‌شه ( گیت مقایسه‌گر)گیت تغییرای فایل هایی که به محیط stage اضافه شدن ( اونایی git add ) براشون زدی رو به صورت پیش‌فرض نشون نمی‌ده ولی با دستور پایین می‌تونی این تغییرات رو ببینیgit diff --stagedاصلا خسته شدم هر کاری می‌کنم درست نمی‌شه!خوبی گیت اینه که اگر تغییرات قبلی رو یه جایی مثلا توی GitHub داشته باشی می‌تونی کل پروژه رو پاک کنی و دوباره ازش یه clone بگیری :)من یه سری دستور جایگزین ساده برای دستورات طولانی گیت دارم ( خوب کلی دیگه هم قطعا هست که کوتاه تر از این هم هستن) خیلی معمول هست که هر کسی یکی برای خودش درست می‌کنه مال من تو Gist هست. اگر ازش استفاده کردین بهم بگید و اگر دستور جدیدی رو ساده تر کردید به من هم بگید که اضافه کنم. رضا کمالی‌ رضا کمالی‌ Wed, 28 Feb 2018 02:58:14 +0330