https://virgool.io/feed/@esmaeil-ghafarnia معاون ارشد مهندسی | مدیر ارشد فناوری سابق (CTO) | مشاور مدیرعامل در حوزه فناوری | توسعه پلتفرم‌های مشتری‌محور و پیشبرد تحول دیجیتال fa 2026-06-07 09:20:06 https://files.virgool.io/upload/users/176/avatar/j07tqS.jpeg?height=120&width=120 https://virgool.io/@esmaeil-ghafarnia https://virgool.io/@esmaeil-ghafarnia/%D8%AA%D9%84%D9%87-%D8%AA%D8%B1%D8%AF%DB%8C%D8%AF-%DA%86%D8%B1%D8%A7-%D8%A8%D8%B1%D8%AE%DB%8C-%D9%85%D8%AF%DB%8C%D8%B1%D8%A7%D9%86-%D9%87%D8%B1%DA%AF%D8%B2-%D8%AA%D8%B5%D9%85%DB%8C%D9%85-%D9%86%D9%85%DB%8C-%DA%AF%DB%8C%D8%B1%D9%86%D8%AF-i4hs8zy8v7wa تله تردید: چرا برخی مدیران هرگز تصمیم نمی‌گیرند؟ تصمیم‌گیری، قلب تپنده‌ی مدیریت است. اما برخی مدیران در این مسیر گرفتار "تله تردید" می‌شوند، جایی که هر انتخابی با شک و دودلی همراه است و در نهایت، تصمیمی گرفته نمی‌شود یا به تعویق می‌افتد. این تعلل نه‌تنها به سازمان آسیب می‌زند، بلکه فرصت‌ها را از بین می‌برد، انگیزه‌ی کارکنان را کاهش می‌دهد و هزینه‌های پنهان زیادی به دنبال دارد.اما چرا برخی مدیران در تصمیم‌گیری مردد هستند؟ آیا ترس از شکست آن‌ها را فلج کرده یا در دام کمال‌گرایی گیر افتاده‌اند؟ آیا سازمان‌های بیش از حد بوروکراتیک باعث کندی تصمیم‌گیری شده‌اند یا مدیران اعتماد به نفس کافی ندارند؟در این مقاله، ریشه‌های تعلل در تصمیم‌گیری، پیامدهای خطرناک آن و راهکارهایی برای خروج از این تله را بررسی خواهیم کرد. اگر شما هم با مدیرانی روبه‌رو هستید که تصمیم‌گیری را به فردا موکول می‌کنند، یا خودتان گاهی در این دام گرفتار می‌شوید، این مطلب را از دست ندهید. در این مقاله، دلایل تعلل در تصمیم‌گیری، اثرات منفی آن و راهکارهایی برای بهبود این مهارت مهم را بررسی خواهیم کرد.۱. چرا برخی مدیران در تصمیم‌گیری تعلل می‌کنند؟مدیران به دلایل مختلفی ممکن است در تصمیم‌گیری تاخیر، تعلل و یا از آن اجتناب کنند. برخی از مهم‌ترین این دلایل عبارتند از:ترس از شکست و پیامدهای اشتباهبسیاری از مدیران نگران این هستند که تصمیم آن‌ها اشتباه باشد و منجر به شکست شود. این ترس باعث می‌شود که تصمیم‌گیری را تا حد امکان به تعویق بیندازند، با این امید که شرایط تغییر کند یا شخص دیگری مسئولیت تصمیم را بر عهده بگیرد. اما در واقع، عدم تصمیم‌گیری خود یک تصمیم است که معمولاً پیامدهای منفی زیادی به دنبال دارد.کمال‌گرایی بیش از حدبرخی مدیران دوست دارند که همه چیز بی‌نقص باشد. آن‌ها به‌دنبال بهترین و ایده‌آل‌ترین تصمیم ممکن هستند، اما در عمل، چنین چیزی وجود ندارد. کمال‌گرایی بیش از حد باعث می‌شود که زمان زیادی صرف بررسی جزئیات شود و در نهایت تصمیم‌گیری به تأخیر بیفتد.کمبود اطلاعات و تحلیل بیش از حد داده‌هاداشتن اطلاعات کافی برای تصمیم‌گیری مهم است، اما برخی مدیران آن‌قدر در جمع‌آوری داده‌ها و بررسی سناریوهای مختلف غرق می‌شوند که هرگز به یک تصمیم نهایی نمی‌رسند. این پدیده که به "فلج تحلیلی" (Analysis Paralysis) معروف است، می‌تواند مانع از اقدام به‌موقع شود.نداشتن اعتماد به نفس در تصمیم‌گیریبرخی مدیران اعتماد به نفس کافی برای تصمیم‌گیری ندارند. آن‌ها نگران هستند که مورد قضاوت دیگران قرار بگیرند یا در صورت شکست، اعتبار خود را از دست بدهند. این عدم اعتماد به نفس باعث می‌شود که از تصمیم‌گیری اجتناب کنند یا تصمیم‌گیری را به دیگران واگذار کنند.بوروکراسی و فرهنگ سازمانی کنددر برخی سازمان‌ها، فرآیند تصمیم‌گیری بسیار پیچیده و طولانی است. مدیران مجبورند قبل از هر تصمیم، تاییدیه های مختلفی از سطوح بالاتر دریافت کنند. این موضوع باعث می‌شود که تصمیمات مهم به تعویق بیفتند و سازمان از رقابت عقب بماند.۲. عواقب تأخیر یا عدم تصمیم‌گیری در مدیریتمدیرانی که تصمیم‌گیری را به تعویق می‌اندازند یا از آن اجتناب می‌کنند، پیامدهای مختلفی را برای خود، کارکنان و سازمان به همراه دارند. برخی از مهم‌ترین این پیامدها عبارتند از:از دست دادن فرصت‌های مهمدر دنیای کسب‌وکار، فرصت‌ها دائماً در حال ظهور و ناپدید شدن هستند. اگر مدیران نتوانند به‌موقع تصمیم بگیرند، ممکن است فرصت‌های ارزشمندی را از دست بدهند. به‌عنوان نمونه، تأخیر در تصمیم‌گیری درباره ورود به یک بازار جدید می‌تواند باعث شود که رقبا زودتر وارد آن شوند و سهم بازار را تصاحب کنند.کاهش بهره‌وری سازمانهنگامی که تصمیمات مهم گرفته نمی‌شوند، کارکنان نمی‌دانند که چه باید بکنند. این عدم قطعیت باعث کاهش بهره‌وری و افزایش سردرگمی در محیط کار می‌شود. تیم‌ها ممکن است در انتظار تصمیم مدیر بمانند و این موضوع باعث ایجاد وقفه در فرآیندهای کاری شود.نارضایتی و کاهش انگیزه کارکنانکارکنان انتظار دارند که مدیران بتوانند راه را برای آن‌ها روشن کنند. اگر مدیری در تصمیم‌گیری تعلل کند، کارکنان احساس خواهند کرد که رهبر آن‌ها ناتوان است. این مسئله باعث کاهش انگیزه، افزایش استرس و حتی ترک کارکنان با استعداد از سازمان می‌شود.افزایش هزینه‌های سازمانیتصمیم‌گیری دیرهنگام می‌تواند منجر به افزایش هزینه‌های سازمان شود. به‌عنوان نمونه، اگر یک مدیر در تصمیم‌گیری درباره استخدام نیروی جدید تعلل کند، ممکن است تیم موجود تحت فشار قرار گرفته و بهره‌وری کاهش یابد. یا اگر یک تصمیم مالی به تأخیر بیفتد، ممکن است فرصت‌های سرمایه‌گذاری سودآور از دست برود.کاهش اعتبار و نفوذ مدیرمدیرانی که از تصمیم‌گیری اجتناب می‌کنند، به‌تدریج اعتبار خود را از دست می‌دهند. کارکنان، مدیران دیگر و حتی سهام‌داران سازمان ممکن است آن‌ها را به‌عنوان رهبرانی ضعیف و فاقد شجاعت تلقی کنند. این امر باعث کاهش نفوذ آن‌ها در سازمان و سخت‌تر شدن اجرای تصمیمات آینده می‌شود.۳. چگونه می‌توان از تعلل در تصمیم‌گیری جلوگیری کرد؟اگرچه تأخیر در تصمیم‌گیری یک مشکل رایج است، اما راهکارهایی برای بهبود این مهارت وجود دارد. در ادامه، برخی از این راهکارها را بررسی می‌کنیم:پذیرش این حقیقت که هیچ تصمیمی بی‌نقص نیستمدیران باید بپذیرند که هیچ تصمیمی ۱۰۰٪ کامل نیست و همیشه درجاتی از ریسک وجود دارد. مهم این است که تصمیمی آگاهانه و منطقی بگیرند و در صورت نیاز، آن را اصلاح کنند.تعیین محدودیت زمانی برای تصمیم‌گیریبرای هر تصمیم، یک بازه زمانی مشخص تعیین کنید. به‌عنوان نمونه، اگر قرار است درباره استخدام یک نیروی جدید تصمیم بگیرید، یک بازه زمانی منطقی (مثلاً یک هفته) مشخص کنید تا از تعلل جلوگیری شود.استفاده از مدل‌های تصمیم‌گیریبرخی مدل‌های تصمیم‌گیری می‌توانند به مدیران کمک کنند تا سریع‌تر و بهتر تصمیم بگیرند، از جمله:ماتریس تصمیم‌گیری برای مقایسه گزینه‌های مختلفروش ۸۰/۲۰ (اصل پارتو) که بر مهم‌ترین عوامل تمرکز داردمدل OODA Loop (مشاهده، جهت‌گیری، تصمیم‌گیری و اقدام) که برای تصمیم‌گیری سریع در شرایط پیچیده مفید است.تفویض اختیار و مشارکت دادن تیم‌هامدیرانی که سعی می‌کنند همه تصمیمات را خودشان بگیرند، معمولاً دچار استرس و تأخیر در تصمیم‌گیری می‌شوند. تفویض اختیار به تیم‌ها و استفاده از نظرات کارشناسان می‌تواند این روند را تسریع کند.تقویت اعتماد به نفس و پذیرش مسئولیتمدیران باید به تصمیمات خود اعتماد داشته باشند و مسئولیت آن‌ها را بپذیرند. اگر اشتباهی رخ داد، مهم این است که از آن درس بگیرند و در آینده تصمیمات بهتری بگیرند.۴. نتیجه‌گیریمدیرانی که در تصمیم‌گیری تعلل می‌کنند یا از آن اجتناب می‌کنند، به سازمان، کارکنان و حتی خودشان آسیب می‌رسانند. این مشکل می‌تواند منجر به از دست رفتن فرصت‌ها، کاهش بهره‌وری، افزایش هزینه‌ها و کاهش اعتبار آن‌ها شود. اما با پذیرش مسئولیت، بهبود مهارت‌های تصمیم‌گیری و استفاده از روش‌های مدیریتی صحیح، می‌توان این چالش را برطرف کرد و به مدیری قاطع و موفق تبدیل شد. اسماعیل غفارنیا اسماعیل غفارنیا Wed, 12 Mar 2025 09:38:31 +0330 https://virgool.io/@esmaeil-ghafarnia/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%D8%A7%DB%8C-%D8%A7%D8%B2-%D9%85%D9%82%D8%A7%D9%84%D9%87-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%DA%AF%DB%8C-%D8%A7%D8%B2-herbert-a-simon-nzz5jsmjlwde خلاصه ای از مقاله معماری پیچیدگی از Herbert A. Simonمقدمهمقاله "معماری پیچیدگی" نوشته Herbert A. Simon، یکی از مقالات بنیادین در حوزه نظریه سیستم‌ها و پیچیدگی است. سایمون در این مقاله به بررسی ساختار سیستم‌های پیچیده و ویژگی‌های مشترک آن‌ها در حوزه‌های مختلف علمی از جمله علوم اجتماعی، زیستی و فیزیکی می‌پردازد. او استدلال می‌کند که پیچیدگی اغلب به شکل سلسله‌مراتبی ظاهر می‌شود و سیستم‌های سلسله‌مراتبی دارای ویژگی‌های مشترکی هستند که مستقل از محتوای خاص آن‌ها است. این مقاله به چهار بخش اصلی تقسیم می‌شود: سیستم‌های سلسله‌مراتبیتکامل سیستم‌های پیچیدهسیستم‌های تقریباً تجزیه‌پذیر توصیف سیستم‌های پیچیدهمفهوم سیستم‌های پیچیدههربرت سایمون سیستم‌های پیچیده را این‌گونه تعریف می‌کند: سیستم‌هایی که از تعداد زیادی اجزا تشکیل شده‌اند و این اجزا به شیوه‌ای پیچیده و غیرساده با یکدیگر در تعامل هستند. در چنین سیستم‌هایی، "کل" چیزی بیش از مجموع ساده اجزای آن است. البته این به معنای متافیزیکی نیست، بلکه به این معناست که پیش‌بینی رفتار کل سیستم تنها بر اساس رفتار تک‌تک اجزای آن کار آسانی نیست. سایمون تأکید می‌کند که حتی اگر کسی از نظر تئوری به رویکرد کاهش‌گرایی (یعنی تحلیل سیستم‌ها با تجزیه آن‌ها به اجزای کوچکتر) اعتقاد داشته باشد، در عمل ممکن است مجبور شود به رویکرد کل‌نگری (یعنی در نظر گرفتن سیستم به عنوان یک کل واحد) روی آورد. به عبارت دیگر، وقتی با پیچیدگی مواجه می‌شویم، ممکن است از نظر تئوری بخواهیم سیستم را به اجزای کوچکتر تقسیم کنیم و آن‌ها را جداگانه تحلیل کنیم، اما در عمل متوجه می‌شویم که سیستم به عنوان یک کل، ویژگی‌هایی دارد که فقط با نگاه به کل سیستم و نه اجزای آن، قابل درک است.سیستم‌های سلسله‌مراتبیسایمون استدلال می‌کند که بسیاری از سیستم‌های پیچیده در طبیعت به شکل سلسله‌مراتبی سازمان‌یافته‌اند. در این سیستم‌ها، هر سیستم از زیرسیستم‌هایی تشکیل شده است که خود آن‌ها نیز به نوبه‌خود از زیرسیستم‌های کوچکتری ساخته شده‌اند. این ساختار سلسله‌مراتبی در حوزه‌های مختلفی از جمله سیستم‌های اجتماعی، زیستی و فیزیکی مشاهده می‌شود.سیستم‌های اجتماعیدر سیستم‌های اجتماعی، خانواده‌ها به عنوان واحدهای ابتدایی در نظر گرفته می‌شوند که در روستاها، شهرها و کشورها سازمان‌دهی می‌شوند. به عنوان نمونه، یک شرکت تجاری یا یک دانشگاه دارای ساختاری سلسله‌مراتبی است که در آن هر بخش به زیربخش‌های کوچکتری تقسیم می‌شود. سایمون اشاره می‌کند که حتی در سازمان‌های رسمی، روابط واقعی بین افراد ممکن است فراتر از روابط سلسله‌مراتبی رسمی باشد، اما ساختار کلی همچنان سلسله‌مراتبی است.سیستم‌های زیستیدر سیستم‌های زیستی، سلول‌ها به عنوان واحدهای ابتدایی در نظر گرفته می‌شوند که به بافت‌ها، بافت‌ها به اندام‌ها و اندام‌ها به سیستم‌های بزرگتر سازمان‌دهی می‌شوند. به عنوان نمونه، یک سلول از زیرسیستم‌هایی مانند هسته، غشای سلولی، میتوکندری و غیره تشکیل شده است. سایمون تأکید می‌کند که این ساختار سلسله‌مراتبی به دانشمندان اجازه می‌دهد که سیستم‌های پیچیده را به شیوه‌ای ساده‌تر تحلیل کنند.سیستم‌های فیزیکیدر سیستم‌های فیزیکی نیز ساختار سلسله‌مراتبی به وضوح قابل مشاهده است. در سطح میکروسکوپی، ذرات بنیادی به اتم‌ها، اتم‌ها به مولکول‌ها و مولکول‌ها به ماکرومولکول‌ها سازمان‌دهی می‌شوند. در سطح ماکروسکوپی، سیستم‌های سیاره‌ای، کهکشان‌ها و خوشه‌های کهکشانی نیز دارای ساختار سلسله‌مراتبی هستند. سایمون اشاره می‌کند که حتی در سیستم‌هایی مانند الماس یا گازهای مولکولی، ساختار سلسله‌مراتبی وجود دارد، اگرچه این ساختار ممکن است بسیار "مسطح" باشد.تکامل سیستم‌های پیچیدهسایمون با استفاده از یک تمثیل به نام "ساعت‌سازان" (Hora و Tempus) نشان می‌دهد که سیستم‌های سلسله‌مراتبی بسیار سریع‌تر از سیستم‌های غیرسلسله‌مراتبی با اندازه مشابه تکامل می‌یابند. در این تمثیل، Tempus ساعت‌هایی می‌سازد که اگر در حین ساخت متوقف شوند، تمام اجزا از هم می‌پاشند، در حالی که Hora ساعت‌هایی می‌سازد که از زیرمجموعه‌های کوچکتری تشکیل شده‌اند و در صورت توقف، تنها بخش کوچکی از کار از بین می‌رود. این تمثیل نشان می‌دهد که وجود زیرمجموعه‌های پایدار در سیستم‌های سلسله‌مراتبی، زمان لازم برای تکامل سیستم‌های پیچیده را به شدت کاهش می‌دهد.سایمون استدلال می‌کند که این تمثیل می‌تواند به درک تکامل زیستی نیز کمک کند. او اشاره می‌کند که زمان لازم برای تکامل یک سیستم پیچیده از اجزای ساده به شدت، به تعداد و توزیع فرم‌های پایدار میانی بستگی دارد. اگر سلسله‌مراتبی از فرم‌های پایدار میانی وجود داشته باشد، زمان لازم برای تکامل سیستم‌های پیچیده به طور قابل توجهی کاهش می‌یابد. به عنوان نمونه، زمان لازم برای تکامل موجودات چندسلولی از تک‌سلولی‌ها ممکن است در همان مرتبه بزرگی باشد که زمان لازم برای تکامل تک‌سلولی‌ها از ماکرومولکول‌ها.سیستم‌های تقریباً تجزیه‌پذیرسایمون مفهوم "سیستم‌های تقریباً تجزیه‌پذیر" (Nearly Decomposable Systems) را معرفی می‌کند. در این سیستم‌ها، تعاملات درون زیرسیستم‌ها بسیار قوی‌تر از تعاملات بین زیرسیستم‌ها است. این ویژگی باعث می‌شود که رفتار کوتاه‌مدت هر زیرسیستم تقریباً مستقل از دیگر زیرسیستم‌ها باشد، در حالی که در بلندمدت، رفتار هر زیرسیستم به صورت کلی تحت تأثیر رفتار دیگر زیرسیستم‌ها قرار می‌گیرد. این ویژگی به ما امکان می‌دهد که سیستم‌های پیچیده را به صورت سلسله‌مراتبی تحلیل کنیم و رفتار آن‌ها را درک کنیم.نمونه ای از سیستم‌های تقریباً تجزیه‌پذیرسایمون یک نمونه ساده از یک سیستم تقریباً تجزیه‌پذیر ارائه می‌دهد: یک ساختمان که به چندین اتاق تقسیم شده است و هر اتاق به چندین بخش کوچکتر (مانند کابین‌ها) تقسیم شده است. اگر در ابتدا دما در هر کابین متفاوت باشد، پس از چند ساعت، دما در هر اتاق به تعادل می‌رسد، اما تفاوت دما بین اتاق‌ها همچنان باقی می‌ماند. پس از چند روز، دما در کل ساختمان به تعادل می‌رسد. این مثال نشان می‌دهد که در سیستم‌های تقریباً تجزیه‌پذیر، تعاملات درون زیرسیستم‌ها (اتاق‌ها) بسیار قوی‌تر از تعاملات بین زیرسیستم‌ها (اتاق‌ها) است.توصیف سیستم‌های پیچیدهسایمون به این موضوع می‌پردازد که چگونه می‌توان سیستم‌های پیچیده را به شیوه‌ای ساده توصیف کرد. او دو نوع توصیف را معرفی می‌کند: توصیف حالت (State Description) و توصیف فرآیند (Process Description). توصیف حالت به توصیف وضعیت سیستم در یک لحظه خاص می‌پردازد، در حالی که توصیف فرآیند به توصیف تغییرات سیستم در طول زمان می‌پردازد. سایمون استدلال می‌کند که بسیاری از سیستم‌های پیچیده را می‌توان با استفاده از توصیف فرآیند به شیوه‌ای ساده‌تر و کارآمدتر توصیف کرد.سیستم‌های خودتکثیر شوندهسایمون به بررسی سیستم‌های خودتکثیر شونده (Self-Reproducing Systems) می‌پردازد و استدلال می‌کند که تکثیر سیستم‌های پیچیده نیازمند توصیفی ساده و کارآمد از سیستم است. او به عنوان نمونه، DNA را به عنوان یک سیستم خودتکثیر شونده معرفی می‌کند که اطلاعات لازم برای تکثیر خود را در قالب یک توصیف فرآیند (برنامه ژنتیکی) ذخیره می‌کند. این برنامه ژنتیکی نه تنها اطلاعات لازم برای تکثیر DNA را فراهم می‌کند، بلکه فرآیندهای متابولیک سلول را نیز کنترل می‌کند.نتیجه‌گیریسایمون در پایان مقاله تأکید می‌کند که ساختار سلسله‌مراتبی و ویژگی تقریباً تجزیه‌پذیری سیستم‌های پیچیده، درک و تحلیل این سیستم‌ها را بسیار ساده‌تر می‌کند. او استدلال می‌کند که این ویژگی‌ها نه تنها در سیستم‌های طبیعی، بلکه در سیستم‌های مهندسی و اجتماعی نیز مشاهده می‌شوند. سایمون پیشنهاد می‌کند که مطالعه سیستم‌های پیچیده و توسعه نظریه‌هایی برای درک آن‌ها، یکی از چالش‌های اصلی علم و مهندسی در آینده خواهد بود. اسماعیل غفارنیا اسماعیل غفارنیا Tue, 04 Feb 2025 23:21:13 +0330 https://virgool.io/@esmaeil-ghafarnia/%D9%86%DA%A9%D8%A7%D8%AA%DB%8C-%D8%AF%D8%B1-%D8%A8%D8%A7%D8%A8-%DA%AF%D8%B0%D8%B1-%D8%A7%D8%B2-%D9%85%D9%87%D9%86%D8%AF%D8%B3-%D8%A7%D8%B1%D8%B4%D8%AF-%D8%A8%D9%87-%D9%85%D8%AF%DB%8C%D8%B1-%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-yau2quhfq3in نکاتی در باب گذر از مهندس ارشد به مدیر مهندسیتبدیل شدن به یک مدیر مهندسی (Engineering Manager)، گامی کلیدی و تأثیرگذار در بسیاری از مشاغل فنی محسوب می‌شود. این تغییر به معنای عبور از کارهای عملی و فنی به سمت رهبری و هدایت تیم است. این گذار نیازمند مهارت‌های ویژه و تغییر در نگرش و دیدگاه ها است. در این نوشته، مسیر تبدیل شدن از مهندس ارشد به مدیر مهندسی را بررسی می‌کنیم و نکات کلیدی، مراحل مهم و اقدامات عملی را ارائه می دهم تا به شما کمک کنم این تغییر را با موفقیت پشت سر بگذارید. تصمیم‌گیری برای تبدیل شدن به یک مدیر مهندسی، انتخاب بزرگی است که نیازمند تفکر دقیق و آمادگی کامل است. به نظر من، این مسیر برای همه مناسب نیست و لزوماً نباید به عنوان گام بعدی و طبیعی پس از مهندس ارشد در نظر گرفته شود. برخی افراد ترجیح می‌دهند در جایگاه فنی باقی بمانند و به عنوان متخصص فنی به رشد خود ادامه دهند، که این هم راهی معتبر و ارزشمند برای پیشرفت در حرفه مهندسی است.تشخیص زمان مناسبانتقال به نقش مدیر مهندسی نیازمند مواردی بیش از تخصص فنی است. بسیار مهم است که علاقه خود به رهبری و توسعه تیم‌ها، توانایی شما در برقراری ارتباط و حل تعارضات، و اهداف کلی شغلی‌تان را ارزیابی کنید. نشانه‌هایی که ممکن است برای این انتقال آماده باشید شامل تمایل به راهنمایی مهندسان تازه‌کار، اشتیاق به هدایت پروژه‌ها به صورت کلی و تمایل به مشارکت در رشد تیم است.ارزیابی مجموعه مهارت‌هامجموعه مهارت‌های فعلی خود را ارزیابی کنید و حوزه‌هایی که نیاز به توسعه دارند را شناسایی کنید. اگرچه مهارت‌های فنی ضروری هستند، اما نقش‌های مدیریتی نیازمند ارتباطات قوی، هوش هیجانی و تفکر استراتژیک هستند. روی بهبود مهارت‌هایی مانند ارتباطات مؤثر، حل تعارضات، مدیریت زمان و توانایی ارائه بازخورد سازنده تمرکز کنید.تعامل و یافتن یک Mentorبا مدیران مهندسی یا رهبران فعلی در سازمان خود تعامل داشته باشید. بینش و تجربیات آن‌ها می‌تواند راهنمایی ارزشمندی برای آماده‌سازی شما برای این انتقال باشد. سؤالاتی درباره مسئولیت‌های روزمره آن‌ها، چالش‌هایی که با آن‌ها مواجه شده‌اند و توصیه‌هایی برای موفقیت در تغییر نقش بپرسید.کسب مهارت‌های جدیدشرکت در کارگاه‌ها، دوره‌ها یا برنامه‌های آموزشی را برای توسعه مهارت‌های مدیریتی لازم در نظر بگیرید. دوره‌های رهبری، مدیریت پروژه و پویایی تیم می‌توانند به شما کمک کنند.نمایش توانایی‌های رهبریحتی قبل از گذار از مهندس ارشد به مدیر مهندسی، به دنبال فرصت‌هایی برای نمایش توانایی‌های رهبری خود باشید. در پروژه‌های بین‌رشته‌ای داوطلب شوید، به مهندسان تازه‌کار راهنمایی ارائه دهید و پیشنهاد دهید که تیم‌های کوچک را رهبری کنید. این تجربیات نه تنها مهارت‌های شما را نشان می‌دهد، بلکه به شما کمک می‌کند تا به عنوان یک مدیر آینده اعتماد به نفس لازم را کسب کنید.پرسش مداوم از خودهمیشه از خود بپرسید: آیا این مسیر برای من مناسب است؟ آیا واقعاً می‌خواهم یک راهنما باشم؟ آیا علاقه‌مند هستم که از کدنویسی فاصله بگیرم و بیشتر روی افراد تمرکز کنم؟بیان اهداف خودعلاقه خود به نقش مدیریتی را به سرپرست فعلی یا بخش منابع انسانی سازمان خود اعلام کنید. این کار باعث باز شدن مسیر گفت‌وگو می شود و امکان راهنمایی، آموزش یا همسو کردن اهداف شغلی شما با نیازهای سازمان را فراهم می‌کند.در تجربه شخصی من در سال های گذشته، در اولین باری که به نقش مدیریتی علاقه‌مند شدم، با عدم اطمینان در مورد چگونگی بیان این موضوع به سرپرستم همراه بود. ذهنم پر از افکار مختلف بود قبل از اینکه در نهایت جرأت داشته باشم تا مستقیم با او صحبت کنم. هدف من این نبود که جایگاه او را بگیرم، بلکه آرزویم پیشرفت و پرورش مسیر شغلی خودم بود.آماده‌سازی برای مصاحبه‌هااگر تصمیم دارید فرصت‌های خارج از سازمان فعلی خود را بررسی کنید، برای مصاحبه‌هایی که روی پتانسیل رهبری شما تمرکز دارند آماده شوید. مواردی را که در آن‌ها رهبری کرده‌اید، تعارضات را مدیریت کرده‌اید یا به رشد تیم کمک کرده‌اید را بازگو کنید.تغییر در طرز تفکرانتقال از مشارکت‌کننده فردی به مدیر نیازمند تغییر در طرز تفکر است. شما باید وظایف را تفویض کنید، رشد تیم خود را هدایت کنید و روی اهداف کلی تیم به جای دستاوردهای فردی تمرکز کنید.پذیرش یادگیری مستمرسفر شما پس از تبدیل شدن به مدیر مهندسی پایان نمی‌یابد. به طور مداوم بازخورد بگیرید، از تجربیات خود یاد بگیرید و سبک مدیریت خود را بر اساس نیازهای تیم و سازمان تطبیق دهید.ارائه و دریافت بازخوردبه عنوان یک مدیر، تسلط بر هنر ارائه و دریافت بازخورد بسیار مهم است. بازخورد سازنده ابزاری ارزشمند برای هدایت رشد تیم و همسو کردن تلاش‌های آن‌ها با اهداف سازمانی است. به همان اندازه، مهارت دریافت بازخورد با ذهنی باز و شناخت آن به عنوان فرصتی برای رشد شخصی و حرفه‌ای نیز اهمیت دارد.توصیه‌هابرای درک بیشتر از رهبری و مدیریت، این کتاب ها می توانند نقش به سزایی داشته باشند:مسیر مدیر: راهنمایی برای رهبران فناوری در مسیر رشد و تغییر، نویسنده Camille Fournierصراحت تمام عیار: چگونه رئیس خوبی باشید بدون از دست دادن انسانیت خود، نویسنده Kim Scottانگیزه: حقیقت شگفت‌انگیز درباره آنچه ما را برمی‌انگیزد، نویسنده Daniel H. Pinkفرآیند یادگیری را بپذیرید، به دنبال راهنمایی باشید و به توانایی های خود برای رهبری مؤثر اعتماد کنید.نتیجه‌گیریگذار و تبدیل شدن از مهندس ارشد به مدیر مهندسی سفر چالش‌برانگیز اما پرباری است. این مسیر نیازمند خودآگاهی، توسعه مهارت‌ها و تعهد به رشد مستمر است. با دنبال کردن این نکات، شما می توانید این گذار را با موفقیت پشت سر گذارید و در نقش جدید خود به عنوان مدیر مهندسی رشد کنید.به یاد داشته باشید، این نوشته به عنوان یک نقشه راه عمل می‌کند، اما سفر هر فرد منحصر به فرد است. اسماعیل غفارنیا اسماعیل غفارنیا Wed, 22 Jan 2025 10:46:57 +0330 https://virgool.io/@esmaeil-ghafarnia/%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%81%D8%B4%D8%A7%D8%B1-%D8%B0%DB%8C-%D9%86%D9%81%D8%B9%D8%A7%D9%86-%D8%B1%D8%A7%D9%87%D9%86%D9%85%D8%A7%DB%8C%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%DB%8C%DA%A9-%D8%B1%D9%87%D8%A8%D8%B1-%D9%81%D9%86%DB%8C-htfpfhom4c8b مدیریت فشار ذی‌نفعان: راهنمایی برای یک رهبر فنی ما به این Feature برای فصل بعد نیاز داریم.می‌توانی این سه Feature را اضافه کنی؟مشتری انتظار داشت این کار هفته گذشته تحویل داده شود.پیام‌ها یکی پس از دیگری انباشته می‌شوند. تیم شما در حال حاضر در حداکثر ظرفیت خود کار می‌کند. سه ذی‌نفع مختلف منتظر به‌روزرسانی‌ها هستند و شما هنوز در تلاشید تا بفهمید چگونه همه‌چیز را مدیریت کنید.آیا این شرایط آشنا به نظر می‌رسد؟این یک چالش رایج برای رهبران فنی تازه‌کار است: مواجهه با فشارهای ناشی از ذی‌نفعان مختلف، مدیران پروژه، اسکرام مسترها، مالکان محصول و دیگران.این انتظارات مداوم می‌تواند طاقت‌فرسا باشد، به‌ویژه در اولین نقش رهبری شما.روزهای اولیه‌ام به عنوان یک رهبر فنی را به یاد می‌آورم، جایی که فشار انتظارات از جهات مختلف را احساس می‌کردم. به نظر می‌رسید فشار از همه جا می‌آمد و فکر می‌کردم باید فوراً به انتظارات همه پاسخ دهم. اما نکته مهمی را یاد گرفتم: فشار ذی‌نفعان اغلب نه از سوی خود آن‌ها، بلکه از نیاز درک‌شده ما برای پاسخ‌گویی فوری به انتظارات همه ناشی می‌شود.نکته کلیدی: همه ذی‌نفعان در نهایت چیزی را می‌خواهند که برای پروژه بهترین است و برای دستیابی به آن، رفاه تیم باید در اولویت باشد.حقایقی ساده درباره موفقیت پروژهدر طول چندین پروژه سازمانی، این موضوع را به طور مداوم مشاهده کرده‌ام:افراد و ذینفعان وقتی کارها زودتر از موعد تحویل داده می‌شوند، بسیار خوشحال می‌شوند.وقتی کارها طبق برنامه پیش می‌روند، خوشحال هستند.در صورت وجود ارتباطات شفاف، حتی با تاخیرها هم راضی می‌شوند.اما هیچ‌کس از تاخیرهای غیرمنتظره و بدون توضیح خوشحال نمی‌شود.این الگو در سازمان‌ها و نقش‌های مختلف صدق می‌کند. تفاوت در این نیست که آیا با چالش‌ها مواجه می‌شوید یا نه، بلکه در این است که چقدر زود و صادقانه درباره آن‌ها ارتباط برقرار می‌کنید.حقایقی ساده درباره موفقیت پروژه صداقت زودهنگام درهای جدیدی باز می‌کندوقتی از همان ابتدا شفاف باشید، اتفاقات جالبی رخ می‌دهد.آنچه به عنوان یک بحث درباره محدودیت‌ها شروع می‌شود، اغلب به یک جلسه حل مسئله مشارکتی (Problem solving) تبدیل می‌شود. این موضوع را به‌ویژه در جلسات Backlog Planning مشاهده کرده‌ام، جایی که تیم‌های محصول، UX و فنی دور هم جمع می‌شوند.صداقت زودهنگام فشار را به مشارکت تبدیل می‌کند.صداقت کامل درباره محدودیت‌های فنی، ظرفیت تیم، منحنی‌های یادگیری و چالش‌های یکپارچه‌سازی اغلب منجر به راه‌حل‌های خلاقانه‌ای می‌شود که به تنهایی به آن‌ها نمی‌رسیدید. کلید کار این است که به یاد داشته باشید همه افراد حاضر در جلسه خواهان موفقیت پروژه هستند.رویکردهای استراتژیکهنگام مواجهه با چالش‌های زمانی یا منابعی، این سه حوزه کلیدی می‌توانند به یافتن راه‌حل کمک کنند. توجه داشته باشید که هیچ روال و ترتیب ثابتی وجود ندارد، اولویت و توالی کاملاً به زمینه خاص و استراتژی تعریف‌شده توسط همه حوزه‌های درگیر برای هر پروژه بستگی دارد.استراتژی محصول و UXفرصت‌های ساده‌سازی تجربه کاربریکاهش پیچیدگی رابط کاربریبرنامه‌ریزی تحویل مرحله‌ایبازتعیین اولویت‌هانوآوری فنیرویکردهای فنی ساده‌تربازسازی استراتژیکبهینه‌سازی معماری برای استفاده مجدد از کدبهبود فرآیند توسعهتقویت توانمندی‌هاگسترش تیم (کارمندان تمام‌وقت یا پیمانکاران)چرخش استراتژیک تیم از پروژه‌های دیگرفرصت‌های ادغام کارآموزاننکته کلیدی پیروی از یک ترتیب ثابت نیست، بلکه یافتن ترکیب درست استراتژی‌ها برای زمینه خاص شماست.در حالی که شروع با استراتژی محصول اغلب نتایج خوبی به همراه دارد (زیرا می‌تواند پیچیدگی را قبل از سرمایه‌گذاری در راه‌حل‌های فنی یا گسترش تیم کاهش دهد)، رویکرد درست بسته به پروژه متفاوت است.مهم‌ترین عامل این است که اطمینان حاصل کنید همه حوزه‌ها (محصول، UX و فنی) در تعریف استراتژی مشارکت دارند.رویکردهای استراتژیکاولویت حیاتی: رفاه تیمنکته مهمی که باید به خاطر بسپارید این است: در حالی که همه ذی‌نفعان خواهان موفقیت پروژه هستند، این موفقیت نمی‌تواند به قیمت فرسودگی تیم به دست آید.تیم‌های فرسوده اشتباه می‌کنند.استرس منجر به ترک کار می‌شود.کیفیت تحت فشار آسیب می‌بیند.پایداری بلندمدت مهم‌تر از پیروزی‌های کوتاه‌مدت است.یک نمونه عملیبه جای احساس فشار برای پاسخ مثبت فوری به درخواست‌های ذی‌نفعان، این رویکرد را امتحان کنید:درخواست را تأیید کنید: «من اهمیت این زمان‌بندی را درک می‌کنم. اجازه دهید آن را به درستی تحلیل کنم تا بتوانم ارزیابی واقع‌بینانه‌ای ارائه دهم.»زمانی برای ارزیابی در نظر بگیرید.ظرفیت تیم را بررسی کنید.پیچیدگی های فنی را در نظر بگیرید.فرصت‌های بهینه‌سازی را شناسایی کنید.با گزینه‌ها بازگردید: «بر اساس تحلیل ما، این سه رویکرد ممکن وجود دارد، هر کدام با معاوضه‌های متفاوت…»در مورد نیازها صادق باشید: «برای رعایت این زمان‌بندی، به منابع بیشتری نیاز داریم. با این حال، راه‌هایی برای ساده‌سازی راه‌حل شناسایی کرده‌ایم که ممکن است به ما کمک کند هدف را به گونه‌ای متفاوت محقق کنیم.»نتیجه گیریبه یاد داشته باشید، به عنوان یک رهبر فنی، نقش شما این نیست که یک قهرمان باشید که می‌تواند همه‌چیز را انجام دهد.بلکه می بایست یک رهبر متفکر باشید که:از رفاه تیم محافظت می‌کند.صادقانه ارتباط برقرار می‌کند.به‌صورت استراتژیک فکر می‌کند.راه‌حل‌های خلاقانه پیدا می‌کند.وقتی با این ذهنیت به فشار ذی‌نفعان نزدیک می‌شوید، اغلب متوجه می‌شوید که خود فشار شروع به محو شدن می‌کند و جای خود را به حل مسئله مشارکتی می‌دهد. اسماعیل غفارنیا اسماعیل غفارنیا Tue, 21 Jan 2025 13:32:24 +0330 https://virgool.io/@esmaeil-ghafarnia/%DA%86%D8%B1%D8%A7-%DB%8C%DA%A9-engineering-manager-%D9%86%D8%A8%D8%A7%DB%8C%D8%AF-code-review-%D8%A7%D9%86%D8%AC%D8%A7%D9%85-%D8%AF%D9%87%D8%AF-srutbqgk55k3 چرا یک Engineering Manager نباید Code Review انجام دهد؟وقتی در مورد سازمان‌دهی تیم ها صحبت می‌کنم، اغلب از من می‌پرسند: «چرا فردی که Technical Lead تیم است، مدیر تیم نمی‌شود؟» و یا اینکه «با توجه به اینکه شما می‌خواهید مدیران در تیم‌ها حضور داشته باشند، آیا مدیر هنوز می‌تواند بررسی کد (Code Review) انجام دهد؟»این سوالات همیشه مطرح می‌شود. اما بیایید کمی عمیق‌تر به این سوال و پاسخ های آن فکر کنیم.چرا Technical Lead نباید مدیر تیم باشد؟چرا Engineering Manager نباید بررسی کد انجام دهد؟مانند همه‌چیز در فناوری، پاسخ به موقعیت بستگی دارد. در اینجا سعی می‌کنم به این سوال همیشگی پاسخ دهم که «چرا Technical Lead نباید تیم را مدیریت کند و چرا یک Engineering Manager با تیمی به اندازه کافی بزرگ نباید Code را بررسی کند؟»برای پاسخ به این سوال، سه جنبه را در نظر می‌گیریم: تعریف نقش، پیچیدگی ارتباطات تیمی و اندازه تیم. بیایید استدلال‌هایم را با کمک نمودارها بازگو کنم.تفاوت بین نقش Engineering Manager و Technical Leadابتدا به تعریف نقش می‌پردازیم. Engineering Manager و Technical Lead دو نقش با مهارت‌های متفاوت هستند. ممکن است فردی در یک نقش عالی باشد اما در نقش دیگر نه (و برعکس). به عنوان نمونه، بهترین برنامه‌نویس تیم همیشه بهترین فرد برای سازمان‌دهی همه‌چیز نیست.با این حال، تیم به هر دو نقش نیاز دارد تا بهینه عمل کند. بنابراین بیایید این نقش‌ها را مقایسه و تفاوت‌هایشان را بررسی کنیم.تفاوت بین نقش Engineering Manager و Technical Leadوقتی یک مهندس می‌خواهد مدیر شود، من با یک سری سوال شروع می‌کنم: «آیا مطمئنی؟»، زیرا این‌ها نقش‌های بسیار متفاوتی هستند.این جدول نشان‌دهنده یک مشارکت بین Technical Lead و Engineering Manager است. تقسیم کار بین کار سازمانی و ارتباطی از یک سو و تفکر عمیق فنی از سوی دیگر. این نقش‌ها از نظر سطح و دامنه در تیم برابر هستند، اما فعالیت‌های متفاوتی انجام می‌دهند تا موفقیت تیم را تضمین کنند.برای اینکه این مشارکت بین Engineering Manager و Technical Lead به درستی اتفاق بیفتد، باید بین آن‌ها اعتماد ایجاد شود.مدیر مهندسی باید رهبری فنی تیم را به Technical Lead واگذار کند و از جزئیات فنی دور بماند. مدیران نباید از اتوبوس بیفتند و دهه‌ها تجربه فنی را فراموش کنند. اما مدیریت اساساً یک شغل سیاست‌گذاری است، و مدیران باید مرزها را رعایت کنند. هر چیز دیگری، همانند Micromanaging (مدیریت جزئی‌نگر) باعث از بین رفتن اعتماد می شود.یک Technical Lead باید کارهای مربوط به رشد شغلی، رشد تیم، ارتباطات و هماهنگی را به Engineering Manager واگذار کند و روی معماری، انتخاب‌های فنی، جهت‌گیری فنی و کمک به اجرا متمرکز شود.با این حال، این تمایز بین Engineering Manager و Technical Lead تا زمانی که تیم حداقل ۴ نفر نداشته باشد، لازم نیست. در یک تیم با تعداد ۴ نفر و بیشتر، نقش‌ها تقسیم می‌شوند و Engineering Manager باید روی تیم متمرکز شود و یک مشارکت مبتنی بر اعتماد با Technical Lead ایجاد کند.بیایید ببینیم چرا تیم با تعداد ۴ نفر و بیشتر یک نقطه عطف است.پیچیدگی ارتباطات O(n²)یک مدیر، تیمی را می‌سازد که بر اساس اصول ارتباطی قوی کار می‌کند. با اضافه شدن اعضای جدید به تیم، مسیرهای ارتباطی در تیم چند برابر می‌شوند. ما به طور شهودی فکر می‌کنیم که پیچیدگی ارتباطات تیمی به صورت O(n) رشد می‌کند،پیچیدگی ارتباطات در یک تیم به صورت (2/((1-n)*n) رشد می‌کند، یا به عبارت دیگر، O(n²) (زمان درجه دوم).در ابتدا، شما تنها نفر در تیم هستید، بنابراین تمام روز با خودتان صحبت می‌کنید و تعداد مسیر ارتباطی صفر می باشد.شما یک نفر (A) به تیم اضافه می‌کنید. حالا شما با A صحبت می‌کنید و A با شما صحبت می‌کند، ۱ مسیر ارتباطی.شما یک نفر دیگر (B) به تیم اضافه می‌کنید. حالا شما ۳ مسیر ارتباطی دارید، شما با A، شما با B، و A با B.شما یک نفر دیگر (C) به تیم اضافه می‌کنید. حالا شما ۶ مسیر ارتباطی دارید.و به همین ترتیب.مسیرهای ارتباطی در یک تیم (همه باید با همه صحبت کنند!)وقتی تیمی با ۵ نفر (۶ نفر در کل، شما + ۵ مهندس) ایجاد کنید و یک مدیر محصول و یک Data Scientist اضافه کنید، مدیر تیم باید ۲۶ مسیر ارتباطی (2/(7 * 8)) را مدیریت کند تا تیم بتواند کارها را پیش ببرد. اگر چند تیم همکار و ارتباط با بازاریابی، فروش و خدمات مشتریان را اضافه کنید، مدیریت تیم ناگهان به یک شغل تمام‌وقت تبدیل می‌شود.همه این ارتباطات نشان‌دهنده سرمایه‌گذاری در زمان هستند. مدیر مانند عنکبوتی در یک تار پیچیده از ارتباطات است، از جمله:ایجاد وضوح کامل در اولویت‌بندی‌ها،هدایت اجرای تیم،هماهنگی وضعیت و انتشار با ذینفعان،مدیریت روان فرآیندهای تیم،ارتباط اهداف، انتظارات و عملکرد تیم و افراد برای رشد شغلی،باز کردن گره‌های ارتباطی تیم،و غیره.حتی مدیریت جلسات تیم با رشد تیم پیچیده می‌شود. جنبه منفی رشد تیم، «نارسایی‌های مقیاس پذیر» نامیده می‌شود. هر چه مقیاس سیستم بیشتر شود، هزینه پیچیدگی افزایش می‌یابد. این پیچیدگی به این دلیل است که جلسات استندآپ با افزایش تعداد افراد به تدریج متوقف می‌شوند و تیم نمی‌تواند بی‌نهایت بزرگ شود.اضافه کردن افراد زیاد به تیم باعث فروپاشی آن می‌شود. وقتی ارتباطات به عدد دانبار (Dunbar’s number) برسند، مدیر دیگر نمی‌تواند پیچیدگی ارتباطات را به تنهایی مدیریت کند. این آستانه حدود ۱۷ نفر (۱۳۶ ارتباط) است، پس از آن مدیر باید شروع به اولویت‌بندی روابط کند، تیم را به دو بخش تقسیم کند یا بیشتر وظایف را واگذار کند.بیایید این را به صورت نمودار ترسیم کنیم و ببینیم چه اتفاقی می‌افتد.منحنی اندازه تیمما همه اینجا مهندس هستیم. اگر بتوانیم کاری انجام دهیم، ترسیم نمودار است.ما پیچیدگی ارتباطات و اندازه تیم را ترسیم می‌کنیم تا ببینیم Engineering Manager چه زمانی باید خود را از فناوری دور کند و روی سربار ارتباطات لازم برای یک تیم سالم متمرکز شود. (ما مدیر را در شمارش‌ها لحاظ می‌کنیم، بنابراین این اعداد شامل Engineering Manager + مهندسان است.)نمودار اندازه تیم در مقابل ارتباطاتدر تیم‌های ۱ تا ۳ نفره، ارتباطات توسط گروه قابل مدیریت است، تیم هنوز کوچک و سبک است. و در این اندازه، رهبر تیم می‌تواند نقش یک Technical Lead - Manager (TLM) را انجام دهد. رهبر یک تیم فنی کوچک که هنوز می‌تواند کد بنویسد و وظایف فنی انجام دهد، در حالی که بسیاری از جنبه‌های نقش مدیر را نیز حفظ می‌کند: رشد مهندسان، انجام بررسی‌های عملکرد، مدیریت سربار همکاری با تیم‌های مجاور و غیره. زمانی که ۶ مسیر برای هماهنگی وجود دارد. ۶ مسیر ممکن است زیاد به نظر نرسد، اما وقتی به رشد، عملکرد، اولویت‌بندی و هماهنگی برای ۴ نفر فکر می‌کنید، این کار به اندازه‌ای زمان می‌برد که خروجی فنی شروع به کاهش می‌کند و چیزی باید قربانی شود (یا خروجی یا دقت ارتباطات). اگر یک نفر هر دو نقش را انجام دهد. مهندسان رشد نمی‌کنند، کدها ارسال نمی‌شوند، تیم در مورد مهم‌ترین موضوعات سردرگم می‌شود.۴ عدد جادویی است که در آن TLM باید بین Technical Lead یا Engineering Manager یکی را انتخاب کند، اما نه هر دو.وقتی تعداد اعضای تیم به عدد ۵ رسید، TLM بودن کاملاً منتفی است. اگر هیچ‌کس نقش ارتباطات تیم را بر عهده نگیرد چه اتفاقی می‌افتد؟ بیشتر اوقات، تیم دچار هرج‌ومرج می‌شود و از پیشروی در اولویت‌هایش بازمی‌ماند. تیم و ذینفعانش بیش از حد سردرگم می‌شوند. فردی باید فرآیندی ایجاد کند تا مهندسان بتوانند بهترین کار خود را انجام دهند: ساخت محصولات عالی. این نقش یک شغل تمام‌وقت است.پیچیدگی ارتباطات همچنین دلیل این است که تیم‌های بزرگ به طور طبیعی به زیرتیم‌های ۱ تا ۳ نفره تقسیم می‌شوند تا روی یک پروژه متمرکز شوند. در اندازه تیم ۱ تا ۳ نفر، سربار ارتباطات قابل مدیریت است و کار فنی انجام می‌شود. اما با اضافه کردن نفر چهارم، وارد دنیای منحنی اندازه تیم می‌شویم.در مورد TLM بودنبه نظر می‌رسد که نقش TLM نقش ایده‌آلی است که به یک رهبر اجازه می‌دهد هم مدیریت افراد و هم کار فنی انجام دهد. علاوه بر این، برای شرکت‌های کوچک، تبدیل یک Technical Lead به TLM یک راهکار سریع برای ساخت تیم است.اما TLM یک موقعیت بلندمدت نیست، زیرا در نهایت، نقش‌های Technical Lead و Engineering Manager متفاوت هستند. انجام دو نقش به طور همزمان (بدون کیفیت مناسب) بدون اینکه بتواند دامنه (فنی یا تیمی) کسی که به یکی از این نقش‌ها اختصاص داده شده را پیش ببرد. در نهایت، TLM باید یکی از این دو مسیر را انتخاب کند یا درجا بزند، زیرا نمی‌تواند دامنه کار خود را گسترش دهد.چرا یک Engineering Manager نباید Code Review انجام دهد؟در نهایت، با ترکیب این موارد، دو واقعیت را ثابت می‌کنیم:۱. نقش Technical Lead و Engineering Manager دو نقش هستند که با همکاری هم تیم را به موفقیت می‌رسانند. بنابراین، باید نقش‌ها و مسئولیت‌های روشنی داشته باشند و در یک مشارکت متقابل همکاری کنند.۲. تیم‌ها به یک نقطه عطف تعداد بیشتر از ۴ نفر می‌رسند که در آن کسی باید زمان خود را به ارتباطات اختصاص دهد تا تیم کار کند. در غیر این صورت، تیم به یک سیاه‌چاله از هرج‌ومرج فرو می‌رود.در تیم بزرگتر از ۴ نفر، یک Engineering Manager باید روی نقش اصلی خود متمرکز شود: مدیریت ارتباطات درون و بیرون تیم، تمرکز بر رشد اعضادرک اولویت‌های تیمدر تیم بزرگتر از ۴ نفر، یک Technical Lead باید برروی موارد ذیل متمرکز شود:معماریانتخاب‌های فنیکار فنیتقسیم کار نتیجه گیرینقش اصلی یک Engineering Manager، مدیریت ارتباطات درون و بیرون تیم است: از جمله رشد شغلی، عملکرد، برنامه‌ریزی و تنظیم فرآیندهای تیم. این کار ارتباطی، سرمایه‌گذاری قابل توجهی در زمان است.پس از رسیدن به اندازه کافی از تیم، مدیر باید بین مهارت فنی و سرمایه‌گذاری در هماهنگی و ارتباطات یکی را انتخاب کند، زیرا پیچیدگی ارتباطات بالا است.در اندازه کافی از تیم، سربار ارتباطات ممکن است آنقدر بالا باشد که مدیر مجبور به انتخاب شود یا تنها توسط این کار غرق شود.یک Engineering Manager که Code را بررسی می‌کند، نه تنها نقش اصلی خود را نادیده می‌گیرد، بلکه به Micromanaging Technical Lead می‌پردازد. این فعالیت باعث از بین رفتن اعتماد می شود.این به این معنا نیست که Engineering Manager نمی‌تواند در بحث‌های فنی (به ویژه بررسی‌های معماری) مشارکت کند، اما Technical Lead است که فناوری را هدایت می‌کند.و بنابراین، دلیل اینکه چرا یک Engineering Manager با تیمی به اندازه کافی بزرگ نباید کد را بررسی کند، این است که اعتماد، تفویض اختیار و ارتباطات هسته اصلی نقش Engineering Manager هستند، و این همان چیزی است که اهمیت دارد. اسماعیل غفارنیا اسماعیل غفارنیا Mon, 20 Jan 2025 09:50:04 +0330 https://virgool.io/@esmaeil-ghafarnia/%D9%81%D8%B1%D9%87%D9%86%DA%AF-%D8%A8%D8%A7%D8%B2%D8%AE%D9%88%D8%B1%D8%AF-%D8%B3%D8%A7%D8%B2%D9%86%D8%AF%D9%87-culture-of-constructive-feedback-ppoz50dwlznh فرهنگ بازخورد سازنده (Culture of Constructive Feedback) در دنیای پرشتاب کسب‌وکارهای امروزی، توانایی ارائه و دریافت بازخورد سازنده یکی از مهارت‌های اساسی برای موفقیت و رشد شخصی و سازمانی است. بازخورد، به عنوان یکی از مهم‌ترین ابزارهای مدیریت و توسعه عملکرد کارکنان، نقش کلیدی در بهبود فرآیندها و افزایش انگیزه و بهره‌وری دارد. اما بازخورد باید به گونه‌ای ارائه شود که سازنده، مفید و تاثیرگذار باشد. فرهنگ بازخورد سازنده به مجموعه‌ای از ارزش‌ها، رفتارها و نگرش‌ها اشاره دارد که در آن افراد به طور مستمر و با احترام به یکدیگر بازخورد داده و دریافت می‌کنند تا در بهبود عملکرد و توسعه خود نقش فعال داشته باشند.تعریف فرهنگ بازخورد سازندهفرهنگ بازخورد سازنده به معنای ایجاد محیطی است که در آن افراد بدون ترس از سرزنش یا قضاوت، بتوانند نظرات خود را به اشتراک بگذارند و از تجربیات خود بیاموزند. در این فرهنگ، بازخورد به عنوان فرصتی برای یادگیری و بهبود در نظر گرفته می‌شود، نه به عنوان انتقاد یا ارزیابی منفی. بازخورد سازنده نه تنها بر اشتباهات و نقص‌ها تمرکز می‌کند، بلکه به تشویق نقاط قوت و پیشرفت‌های فرد نیز می‌پردازد.اهمیت فرهنگ بازخورد سازنده در سازمان‌هاایجاد یک فرهنگ بازخورد سازنده در سازمان‌ها فواید بسیاری به همراه دارد که برخی از مهم‌ترین آن‌ها عبارتند از:افزایش انگیزه و بهره‌وری: وقتی کارکنان بازخورد سازنده دریافت می‌کنند، می‌دانند که تلاش‌ها و کارهای آن‌ها مورد توجه قرار می‌گیرد و این موضوع باعث افزایش انگیزه و بهره‌وری آن‌ها می‌شود.بهبود عملکرد فردی و تیمی: بازخورد سازنده به کارکنان کمک می‌کند تا نقاط ضعف و قوت خود را بشناسند و در جهت بهبود عملکرد خود تلاش کنند. همچنین باعث می‌شود تیم‌ها با هماهنگی بیشتر و عملکرد بهتری به اهداف خود برسند.ارتقاء فرهنگ یادگیری: بازخورد مستمر و سازنده، فرآیند یادگیری را تسریع کرده و به کارکنان کمک می‌کند تا از تجربیات خود و دیگران درس بگیرند و اشتباهات گذشته را تکرار نکنند.ارتقاء روابط سازمانی: بازخورد سازنده باعث می‌شود تا افراد در محیط کار به یکدیگر احترام بگذارند و در ارتباطات خود شفاف‌تر و مسئولانه‌تر عمل کنند. این موضوع باعث بهبود روابط درون‌سازمانی و افزایش اعتماد بین اعضای تیم می‌شود.عناصر کلیدی در فرهنگ بازخورد سازندهبرای ایجاد و تقویت یک فرهنگ بازخورد سازنده در سازمان‌ها، باید به چند عنصر کلیدی توجه شود:گفت‌وگوهای دوطرفه: بازخورد باید به صورت یک گفت‌وگوی دوطرفه باشد. افراد باید بتوانند نه تنها بازخورد بدهند، بلکه بازخورد دریافت کنند و به تبادل نظر بپردازند. این فرآیند باعث می‌شود تا کارکنان احساس کنند که در تصمیم‌گیری‌ها و بهبودها نقش دارند.وضوح و شفافیت: بازخورد باید به صورت شفاف و واضح ارائه شود. ابهام در بازخورد باعث سردرگمی و کاهش تاثیر آن خواهد شد. بهترین روش این است که بازخورد به صورت مشخص به رفتارها و عملکردهای قابل مشاهده ارجاع داده شود.احترام متقابل: برای ایجاد بازخورد سازنده، باید یک فضای احترام‌آمیز و دوستانه برقرار شود. افراد باید احساس کنند که بازخورد برای بهبود آن‌ها ارائه می‌شود و نه برای سرزنش یا تحقیر.تشویق و حمایت: بازخورد سازنده نباید تنها به نقد محدود شود. باید همواره به نقاط قوت نیز اشاره شود و فرد برای پیشرفت‌های آینده تشویق شود. این موضوع باعث می‌شود که فرد احساس کند که تلاش‌های او مورد توجه قرار گرفته و برای او اهمیت قائل شده‌اند.مراحل پیاده‌سازی فرهنگ بازخورد سازندهبرای پیاده‌سازی موفق فرهنگ بازخورد سازنده در سازمان، می‌توان مراحل زیر را دنبال کرد:آموزش و آگاهی‌بخشی: اولین گام در این مسیر، آموزش کارکنان درباره اهمیت بازخورد سازنده و نحوه ارائه آن است. باید به کارکنان آموزش داده شود که چگونه بازخورد بدهند و چگونه بازخورد را دریافت کنند. آموزش مهارت‌های ارتباطی و گوش دادن فعال نیز از اهمیت بالایی برخوردار است.تشویق به بازخورد مستمر: برای ایجاد یک فرهنگ بازخورد سازنده، بازخورد نباید تنها به جلسات رسمی محدود شود. باید فضایی فراهم شود که بازخورد به صورت مستمر و در هر لحظه از تعاملات کاری ارائه شود. این موضوع به افراد کمک می‌کند تا به طور مداوم از پیشرفت‌ها و چالش‌های خود مطلع شوند.ایجاد محیطی امن برای ارائه بازخورد: افراد باید احساس کنند که می‌توانند بدون ترس از عواقب منفی، بازخورد خود را ارائه دهند. سازمان‌ها باید محیطی امن و باز برای بازخورد فراهم کنند و اطمینان حاصل کنند که بازخوردها به شیوه‌ای مثبت و سازنده مدیریت می‌شود.پیگیری و ارزیابی بازخوردها: بازخورد سازنده زمانی موثر است که به دقت پیگیری شود. افراد باید بدانند که بازخوردهای آن‌ها مورد توجه قرار گرفته و بر اساس آن‌ها تغییرات لازم صورت گرفته است. همچنین ارزیابی مستمر از نتایج بازخوردها می‌تواند به بهبود فرآیندهای بازخورددهی کمک کند.چالش‌ها و موانع در ایجاد فرهنگ بازخورد سازندهبا وجود فواید بی‌شمار فرهنگ بازخورد سازنده، ایجاد و پیاده‌سازی آن با چالش‌هایی نیز همراه است. برخی از این چالش‌ها عبارتند از:مقاومت در برابر تغییر: برخی افراد ممکن است به دلیل ترس از انتقاد یا عدم تمایل به تغییر، در برابر دریافت بازخورد مقاومت نشان دهند. این موضوع می‌تواند به دلیل عدم آگاهی از اهمیت بازخورد سازنده یا تجربه‌های منفی گذشته باشد.نبود مهارت‌های ارتباطی مناسب: بازخورد سازنده نیازمند مهارت‌های ارتباطی قوی است. اگر افراد نتوانند به درستی احساسات و نظرات خود را بیان کنند، ممکن است بازخورد آن‌ها به جای سازنده بودن، مخرب و منفی تلقی شود.عدم پیگیری بازخوردها: اگر بازخوردهای داده شده پیگیری نشود و تغییری در عملکرد فرد یا تیم مشاهده نشود، افراد ممکن است احساس کنند که بازخوردهای آن‌ها بی‌ارزش است و انگیزه‌ای برای ادامه ارائه بازخورد نداشته باشند.فرهنگ رقابتی و ترس از شکست: در سازمان‌هایی که فرهنگ رقابتی بیش از حد غالب است یا ترس از شکست و انتقاد وجود دارد، ایجاد فرهنگ بازخورد سازنده دشوارتر خواهد بود. در چنین محیط‌هایی، افراد به دلیل نگرانی از ارزیابی منفی یا کاهش اعتبار، از ارائه بازخورد خودداری می‌کنند.راهکارهایی برای غلبه بر چالش‌هابرای غلبه بر چالش‌های ذکر شده و ایجاد یک فرهنگ بازخورد سازنده، سازمان‌ها می‌توانند از راهکارهای زیر استفاده کنند:تقویت مهارت‌های ارتباطی کارکنان: سازمان‌ها باید برنامه‌های آموزشی و توسعه‌ای برای تقویت مهارت‌های ارتباطی کارکنان خود ارائه دهند. این شامل آموزش نحوه ارائه و دریافت بازخورد به شیوه‌ای موثر و سازنده است.تشویق به بازخورد مثبت و سازنده: بازخورد نباید تنها به نقد محدود شود. سازمان‌ها باید به کارکنان خود یاد بدهند که چگونه بازخوردهای مثبت و تشویقی ارائه دهند و فرهنگ قدردانی را در سازمان تقویت کنند.مدیریت فرهنگ سازمانی: مدیران و رهبران سازمان‌ها باید به عنوان نمونه‌های رفتاری عمل کنند و خود به طور مستمر بازخورد سازنده ارائه دهند و دریافت کنند. این موضوع باعث می‌شود که سایر اعضای سازمان نیز به اهمیت بازخورد سازنده پی ببرند و در جهت ایجاد آن تلاش کنند.پیگیری و ارزیابی مستمر: سازمان‌ها باید مکانیزم‌هایی برای پیگیری بازخوردها و ارزیابی نتایج آن‌ها داشته باشند. این موضوع باعث می‌شود که بازخوردها به شیوه‌ای موثر پیگیری شده و نتایج ملموسی از آن‌ها به دست آید.نتیجه‌گیریفرهنگ بازخورد سازنده یکی از پایه‌های اساسی برای موفقیت سازمان‌ها در دنیای امروز است. با ایجاد این فرهنگ، سازمان‌ها می‌توانند محیطی یادگیرنده و پویا ایجاد کنند که در آن افراد به طور مستمر از تجربیات خود و دیگران درس بگیرند و در جهت بهبود و رشد تلاش کنند. بازخورد سازنده نه تنها به بهبود عملکرد فردی و تیمی کمک می‌کند، بلکه به ارتقاء روابط سازمانی و افزایش انگیزه و بهره‌وری نیز منجر می‌شود. اسماعیل غفارنیا اسماعیل غفارنیا Sun, 20 Oct 2024 11:56:02 +0330 https://virgool.io/@esmaeil-ghafarnia/%D9%85%D8%AA%D8%B1%DB%8C%DA%A9-%D9%87%D8%A7%DB%8C-%D8%AA%D8%AD%D9%88%DB%8C%D9%84-%D9%85%D8%AD%D8%B5%D9%88%D9%84-product-delivery-metrics-y5ybg3avsdam متریک های تحویل محصول (Product Delivery Metrics)امروزه، در محیطی که تحولات سریع تکنولوژی و نیازهای بازار به‌شدت در حال تغییر هستند، توانایی سازمان‌ها برای تحویل سریع، باکیفیت، و مداوم محصولات به یک مزیت رقابتی تبدیل شده است. موفقیت در تحویل محصول به‌موقع نه‌تنها به رضایت مشتریان می‌انجامد، بلکه به افزایش سودآوری و رشد کسب‌وکار نیز کمک می‌کند. به همین دلیل، سازمان‌ها به‌طور فزاینده‌ای از متریک‌های تحویل محصول برای ارزیابی و بهینه‌سازی فرآیندهای داخلی استفاده می‌کنند. در توسعه نرم‌افزار و دیگر صنایع تولیدی، پیاده‌سازی اصول "تحویل مستمر" (Continuous Delivery) به یکی از استانداردهای اصلی بدل شده است. این اصول، تیم‌ها را قادر می‌سازند تا با حداقل وقفه و به‌طور مداوم، تغییرات جدید را به مشتریان ارائه کنند. در این میان، متریک‌های تحویل محصول، ابزارهایی هستند که کارایی این فرآیندها را به دقت می‌سنجند و کمک می‌کنند تا بهبودهای لازم صورت گیرد.انواع متریک‌های تحویل محصولزمان سرب (Lead Time)یکی از متریک‌های حیاتی برای سازمان‌ها به‌شمار می‌رود که سرعت پاسخگویی آن‌ها به نیازهای بازار را اندازه‌گیری می‌کند. این متریک به سازمان‌ها کمک می‌کند تا مدت‌زمان بین شروع یک سفارش یا درخواست از سوی مشتری تا زمان تحویل نهایی محصول را بسنجند. به عنوان مثال، در صنایع تولیدی، کاهش Lead Time می‌تواند تأثیر مستقیم بر رقابت‌پذیری شرکت‌ها داشته باشد، زیرا مشتریان انتظار دارند محصولات با سرعت بیشتری به دستشان برسد. در دنیای نرم‌افزار، کاهش Lead Time باعث می‌شود تا تیم‌ها بتوانند با سرعت بیشتری ویژگی‌های جدید را پیاده‌سازی کرده و به مشتری تحویل دهند، که این امر می‌تواند به رضایت بیشتر مشتریان و افزایش نرخ بهره‌وری منجر شود.زمان چرخه (Cycle Time)مدت‌ زمانی است که برای تکمیل یک واحد کاری یا وظیفه خاص از زمانی که آن کار آغاز می‌شود تا پایان آن سپری می‌شود. این متریک در تیم‌های توسعه نرم‌افزار و سایر صنایع به عنوان معیاری برای سنجش سرعت انجام کارهای روزمره استفاده می‌شود. کاهش Cycle Time معمولاً به این معناست که تیم‌ها توانسته‌اند بهره‌وری خود را افزایش دهند و وظایف خود را در مدت‌زمان کوتاه‌تری به پایان برسانند. اما این کاهش نباید به قیمت کاهش کیفیت یا افزایش نرخ خطاها انجام شود. سازمان‌ها باید تعادلی میان زمان چرخه و کیفیت خروجی حفظ کنند.بازدهی (Throughput)یکی از شاخص‌های کلیدی برای ارزیابی توانایی سازمان در تحویل محصولات یا خدمات به مشتریان است. این متریک به تعداد خروجی‌ها یا وظایف تکمیل‌شده توسط تیم‌ها در یک دوره زمانی خاص اشاره دارد. افزایش Throughput معمولاً نشان‌دهنده افزایش کارایی تیم‌هاست، اما این شاخص باید به دقت با دیگر متریک‌ها مانند Lead Time و Cycle Time مقایسه شود تا مطمئن شد که افزایش بازدهی به قیمت کاهش کیفیت یا افزایش نرخ خطاها تمام نشده است.تناوب انتشار (Deployment Frequency)نرخ دفعات انتشار، تعداد دفعاتی را اندازه‌گیری می‌کند که تیم‌ها می‌توانند نسخه‌های جدید محصول یا به‌روزرسانی‌های نرم‌افزاری را به مشتریان ارائه دهند. در سیستم‌های توسعه نرم‌افزار با استفاده از اصول DevOps، تناوب انتشار اهمیت زیادی دارد، چراکه سازمان‌هایی که می‌توانند به‌طور مداوم و با نرخ بالاتری تغییرات را تحویل دهند، معمولاً از مزیت‌های رقابتی بیشتری برخوردارند. بااین‌حال، سازمان‌ها باید توجه داشته باشند که افزایش نرخ انتشار نباید منجر به کاهش کیفیت و افزایش خرابی‌ها در زمان انتشار شود.نرخ شکست تغییرات (Change Failure Rate)به درصد تغییرات یا به‌روزرسانی‌هایی اشاره دارد که پس از انتشار، به دلیل بروز مشکلات فنی، نیاز به بازگشت یا اصلاح دارند. این متریک مستقیماً به کیفیت فرآیندهای توسعه و تست مرتبط است. اگر نرخ شکست تغییرات بالا باشد، این نشان‌دهنده نقص در فرآیندهای تست، برنامه‌ریزی یا پیاده‌سازی تغییرات است. کاهش این نرخ نیازمند اعمال فرآیندهای قوی‌تر برای بررسی تغییرات قبل از انتشار و افزایش سطح همکاری میان تیم‌های توسعه و عملیاتی است.میانگین زمان ریکاوری (Mean Time to Recovery)میانگین زمانی است که طول می‌کشد تا یک سیستم یا محصول پس از بروز یک خرابی یا مشکل به وضعیت عملیاتی عادی خود بازگردد. این متریک معمولاً در سازمان‌هایی که به ارائه خدمات پیوسته مشغول‌اند (مانند شرکت‌های فناوری و ارائه‌دهندگان خدمات ابری) بسیار اهمیت دارد. هدف اصلی سازمان‌ها باید کاهش MTTR و بهبود سرعت بازیابی در مواقع بروز اشکالات باشد.چالش‌ها و فرصت‌ها در استفاده از متریک‌های تحویل محصولچالش هاپیچیدگی در تجزیه‌وتحلیل داده‌ها: یکی از بزرگ‌ترین چالش‌ها در استفاده از متریک‌های تحویل محصول، پیچیدگی داده‌ها و نیاز به تحلیل دقیق آن‌هاست. در سازمان‌های بزرگ، حجم زیادی از داده‌های مرتبط با تحویل محصول وجود دارد که تحلیل آن‌ها نیازمند ابزارهای مناسب و تخصص کافی است.تمرکز بر یک متریک خاص: گاهی اوقات، سازمان‌ها به‌طور اشتباه تنها بر یک متریک خاص تمرکز می‌کنند. به عنوان مثال، اگر سازمانی تنها بر کاهش Lead Time متمرکز شود، ممکن است با افزایش خطاها یا کاهش کیفیت مواجه شود. بنابراین، سازمان‌ها باید از ترکیبی از متریک‌ها برای ارزیابی جامع فرآیندها استفاده کنند.مقاومت تیم‌ها در برابر تغییر: معرفی و استفاده از متریک‌های جدید ممکن است با مقاومت از سوی تیم‌ها مواجه شود. تیم‌های توسعه و عملیاتی ممکن است این متریک‌ها را به‌عنوان فشار اضافی تلقی کنند و در مقابل تغییرات مقاومت نشان دهند. برای رفع این مشکل، ضروری است که سازمان‌ها تیم‌ها را با مزایای استفاده از متریک‌ها آشنا کنند و به آن‌ها کمک کنند تا درک کنند که این متریک‌ها به بهبود فرآیندها کمک می‌کنند.فرصت هابهبود همکاری بین تیم‌ها: استفاده از متریک‌های تحویل محصول می‌تواند به بهبود همکاری میان تیم‌های توسعه، عملیاتی و کیفی کمک کند. با تجزیه‌ و تحلیل داده‌های مشترک، تیم‌ها می‌توانند به فهم مشترکی از مسائل برسند و برای بهبود فرآیندها با یکدیگر همکاری کنند.پیش‌بینی و جلوگیری از مشکلات: متریک‌ها به سازمان‌ها این امکان را می‌دهند که مشکلات را قبل از وقوع شناسایی و از آن‌ها جلوگیری کنند. به‌عنوان مثال، اگر نرخ شکست تغییرات به‌طور مداوم در حال افزایش است، تیم‌ها می‌توانند قبل از بروز مشکل بزرگ، به بررسی فرآیندهای خود پرداخته و بهبودهای لازم را اعمال کنند.نتیجه گیریدر دنیای پیچیده و رقابتی امروز، استفاده از متریک‌های تحویل محصول به سازمان‌ها کمک می‌کند تا فرآیندهای خود را بهینه‌سازی کرده و توانایی خود را در ارائه محصولات بهتر و سریع‌تر به مشتریان افزایش دهند. متریک‌های کلیدی مانند Lead Time، Cycle Time، و Deployment Frequency نشان‌دهنده توانایی سازمان در مدیریت زمان و منابع هستند، در حالی که متریک‌هایی مانند Change Failure Rate و MTTR به سازمان‌ها کمک می‌کنند تا کیفیت و پایداری محصولات خود را حفظ کنند. بااین‌حال، سازمان‌ها باید با دقت از این متریک‌ها استفاده کنند و آن‌ها را در زمینه‌ای وسیع‌تر از بهره‌وری و کیفیت کلان بررسی کنند. اسماعیل غفارنیا اسماعیل غفارنیا Sat, 19 Oct 2024 09:15:17 +0330 https://virgool.io/@esmaeil-ghafarnia/%D8%AA%D9%81%D8%A7%D9%88%D8%AA-%D9%87%D8%A7%DB%8C-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D9%88-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D9%88-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D9%85%D8%AD%D9%88%D8%B1-vpgwhzmkn18j تفاوت های پروژه و محصول و توسعه محصول محورپروژه‌ها و محصولات دو مفهوم کلیدی در حوزه مدیریت و توسعه نرم‌افزار و همچنین بسیاری از صنایع دیگر هستند. هرچند ممکن است در نگاه اول این دو مفهوم مشابه به نظر برسند، اما تفاوت‌های عمده‌ای بین آن‌ها وجود دارد که باید درک شود. این تفاوت‌ها بر نحوه مدیریت، توسعه، پیاده‌سازی و نگهداری تاثیرات قابل توجهی دارند. در این مقاله به بررسی تفاوت‌های بین پروژه و محصول پرداخته و در ادامه یک مدل توسعه نرم‌افزار بر اساس محصول را تشریح خواهیم کرد.تعریف پروژهپروژه یک تلاش موقتی است که برای ایجاد یک محصول یا خدمت مشخص در یک بازه زمانی مشخص با منابع محدود انجام می‌شود. مدیریت پروژه شامل برنامه‌ریزی، تخصیص منابع، زمان‌بندی، کنترل و تحویل پروژه است. ویژگی‌های کلیدی یک پروژه عبارتند از:موقت بودن: پروژه‌ها همیشه یک شروع و پایان مشخص دارند. پس از اتمام هدف پروژه، فعالیت‌های مربوطه نیز به پایان می‌رسند.هدف مشخص: هر پروژه یک یا چند هدف خاص دارد که به‌طور شفاف تعریف شده‌اند.محدودیت‌ها: پروژه‌ها معمولاً با محدودیت‌هایی مانند زمان، بودجه و منابع روبرو هستند.تحویل‌پذیری: نتیجه پروژه معمولاً یک محصول یا خدمات مشخص است که به مشتری یا ذی‌نفعان تحویل داده می‌شود.تعریف محصولمحصول، به یک کالای نرم‌افزاری یا خدماتی اشاره دارد که برای برآورده کردن نیازهای مشتریان طراحی شده و به‌طور مداوم بهبود یافته و به‌روز می‌شود. محصول ممکن است یک اپلیکیشن، وب‌سایت، ابزار نرم‌افزاری یا حتی یک پلتفرم خدمات باشد. مدیریت محصول شامل برنامه‌ریزی، طراحی، توسعه، عرضه به بازار، و همچنین پشتیبانی و نگهداری مداوم محصول است. ویژگی‌های کلیدی یک محصول عبارتند از:طولانی‌مدت بودن: محصولات به طور مداوم مورد استفاده قرار می‌گیرند و به‌روزرسانی‌ها، پشتیبانی و توسعه‌های جدید برای بهبود آن‌ها انجام می‌شود.چرخه عمر طولانی: یک محصول دارای چرخه عمر طولانی است که شامل مراحل تولید، بهره‌برداری، نگهداری و پایان می‌شود.ارتباط با مشتری: محصولات به صورت مداوم به مشتریان ارائه می‌شوند و نظرات مشتریان بر روند بهبود و توسعه آن‌ها تاثیر می‌گذارد.توسعه مداوم: برخلاف پروژه که پایان دارد، محصولات نیاز به توسعه مداوم و بهبود دارند.تفاوت‌های کلیدی بین پروژه و محصولمدت زمان: پروژه‌ها موقتی هستند و پس از دستیابی به اهداف خود پایان می‌یابند. محصولات دائمی‌تر هستند و نیاز به بهبود، پشتیبانی و نگهداری طولانی‌مدت دارند.هدف: پروژه‌ها بر روی تحویل یک خروجی مشخص تمرکز دارند. محصولات برای برآورده کردن نیازهای بازار و مشتریان به صورت مداوم به‌روز می‌شوند.محدودیت‌ها: پروژه‌ها با محدودیت‌های زمانی و بودجه‌ای مشخص مواجه هستند. محصولات نیاز به بودجه و منابع برای پشتیبانی طولانی‌مدت دارند.تحویل و نگهداری: در پروژه‌ها، تحویل یکبار انجام می‌شود و پس از آن پروژه پایان می‌یابد. در محصولات، تحویل به صورت مداوم و با ارائه نسخه‌های جدید و به‌روزرسانی‌ها صورت می‌گیرد.توسعه و بهبود: پروژه‌ها به صورت خطی به هدف خود می‌رسند و سپس خاتمه می‌یابند. محصولات باید به‌طور مداوم با توجه به نیازهای جدید به‌روزرسانی و بهبود یابند.توسعه محصول محور در برابر توسعه پروژه محورتوسعه محصول محور به معنای تمرکز بر روی خلق و بهبود یک محصول در طول زمان است. در این روش، تیم‌ها به طور مداوم به بازخورد مشتریان توجه می‌کنند و ویژگی‌های جدیدی را برای بهبود تجربه کاربر و برآورده کردن نیازهای بازار ارائه می‌دهند. در حالی که توسعه پروژه محور تمرکز بر روی تکمیل یک کار مشخص در مدت زمان محدود دارد.مدل‌های توسعه نرم‌افزار مبتنی بر محصولیکی از رایج‌ترین مدل‌های توسعه نرم‌افزار مبتنی بر محصول، مدل توسعه چابک (Agile) است. این مدل بر اساس تولید محصول در چرخه‌های کوتاه‌مدت به نام اسپرینت (Sprint) طراحی شده است و در هر مرحله بازخورد مشتری را دریافت می‌کند.اصول توسعه چابکتحویل مکرر: محصول به صورت نسخه‌های کوچک و قابل استفاده در فواصل کوتاه تحویل داده می‌شود.همکاری مداوم با مشتری: تیم‌های توسعه به‌طور مداوم با مشتریان در ارتباط هستند تا اطمینان حاصل کنند که محصول نهایی نیازهای آن‌ها را برآورده می‌کند.انعطاف‌پذیری: تغییرات در طول فرآیند توسعه به راحتی پذیرفته می‌شوند و تیم‌ها می‌توانند بر اساس نیازهای جدید مشتری، محصول را تغییر دهند.توسعه تدریجی: به جای تکمیل همه ویژگی‌ها در یک مرحله، محصول به تدریج و با اضافه کردن ویژگی‌های جدید توسعه می‌یابد.مزایای توسعه محصول محورافزایش انعطاف‌پذیری: تیم‌ها می‌توانند به تغییرات بازار و نیازهای مشتری به سرعت واکنش نشان دهند.توسعه مداوم: محصولات به طور مداوم بهبود می‌یابند و با فناوری‌ها و نیازهای جدید هماهنگ می‌شوند.ارتباط مداوم با مشتری: بهبود مستمر محصول بر اساس بازخورد مشتری به کسب و کار کمک می‌کند تا مشتریان را راضی نگه دارد.افزایش کیفیت محصول: با تحویل مکرر نسخه‌های محصول، کیفیت به مرور زمان افزایش می‌یابد.ارتباط بین Feature و پروژهویژگی‌های جدید (Feature) که در یک محصول توسعه داده می‌شوند، اغلب به‌صورت پروژه‌های کوچک یا میکروپروژه‌ها مدیریت می‌شوند. برای نمونه، اگر در یک محصول نرم‌افزاری یک قابلیت جدید اضافه شود، مانند اضافه کردن سیستم پرداخت آنلاین به یک وب‌سایت فروشگاهی، این توسعه ویژگی ممکن است به عنوان یک پروژه کوچک در نظر گرفته شود. ویژگی‌های جدید به خودی خود پروژه نیستند، اما فرآیند توسعه آن‌ها می‌تواند مانند پروژه‌ای با محدوده، زمان‌بندی و منابع تعریف شده مدیریت شود.شباهت‌های توسعه Feature و پروژهمدت زمان محدود: توسعه هر ویژگی معمولاً یک بازه زمانی مشخص دارد.منابع و تیم: توسعه هر ویژگی جدید نیاز به تیم توسعه، طراحی، تست و غیره دارد.تحویل خروجی: در پایان فرآیند، ویژگی به‌عنوان یک خروجی ملموس به محصول اضافه می‌شود.محدوده کاری: هر ویژگی یا تغییر ممکن است محدوده خاصی داشته باشد که برای تکمیل آن لازم است.تفاوت بین توسعه Feature و پروژهارتباط با محصول کلی: در حالی که پروژه‌ها ممکن است به صورت مستقل از یک محصول توسعه داده شوند، ویژگی‌ها همواره به یک محصول موجود اضافه می‌شوند و به بهبود آن کمک می‌کنند.ادغام با محصول: پروژه پس از تکمیل می‌تواند تمام شود، اما ویژگی‌ها به‌عنوان بخشی از محصول نیاز به نگهداری و بهبود مداوم دارند.چرخه عمر: پروژه‌ها چرخه زندگی کوتاه‌تری دارند، اما ویژگی‌ها پس از توسعه ممکن است به‌طور مداوم بهبود یابند یا نسخه‌های جدید از آن‌ها ارائه شوند.مدل توسعه نرم‌افزار محصول محور و نقش Featureدر توسعه محصول محور، تمرکز اصلی روی بهبود مستمر محصول است. مدل‌های توسعه محصول محور معمولاً از چارچوب‌های چابک (Agile) استفاده می‌کنند که در آن‌ها توسعه ویژگی‌ها به بخش‌های کوچک و زمان‌بندی شده تقسیم می‌شود. اسپرینت‌ها در متدولوژی چابک به تیم‌ها این امکان را می‌دهد که در هر دوره کوتاه مدت (معمولاً ۲ تا ۴ هفته)، یک یا چند ویژگی جدید را توسعه دهند.نمونه ای از مدیریت ویژگی به‌عنوان پروژهدر یک تیم چابک، افزودن یک ویژگی جدید به محصول معمولاً به عنوان یک آیتم در بک‌لاگ محصول (Product Backlog) ثبت می‌شود. این آیتم به‌طور دقیق توصیف می‌شود و با تخصیص منابع، زمان‌بندی و برنامه‌ریزی در طول یک یا چند اسپرینت توسعه می‌یابد. به این ترتیب، هر ویژگی به نوعی پروژه کوچک محسوب می‌شود که خروجی آن به محصول اضافه می‌شود.به عنوان مثال، فرض کنید که یک تیم توسعه نرم‌افزار برای یک اپلیکیشن مالی قصد دارد قابلیت پرداخت از طریق ارز دیجیتال را اضافه کند. این قابلیت جدید (Feature) مراحل زیر را شامل می‌شود:تعریف و برنامه‌ریزی: نیازمندی‌ها، مستندات و اهداف قابلیت پرداخت با ارز دیجیتال تعریف می‌شود. این فرآیند مانند آغاز یک پروژه است.طراحی و توسعه: تیم توسعه این ویژگی را برنامه‌ریزی کرده و توسعه آن آغاز می‌شود.آزمایش و بازخورد: ویژگی آزمایش شده و بازخوردهای لازم جمع‌آوری می‌شود.تحویل و استقرار: ویژگی پس از اتمام توسعه و آزمایش به محصول نهایی اضافه شده و به مشتریان ارائه می‌شود.این چرخه به طور کلی بسیار شبیه به یک پروژه کوچک است.مدیریت محصول (Product Management) و پروژه (Project Management)در مدیریت محصول، تیم‌های توسعه به‌صورت مستمر بر روی بهبود و توسعه ویژگی‌های جدید کار می‌کنند و ویژگی‌های مختلف محصول با تمرکز بر نیازهای مشتری بهبود می‌یابد. در مقابل، مدیریت پروژه بیشتر بر روی تکمیل یک کار خاص در یک بازه زمانی مشخص تمرکز دارد.در مدیریت محصول، مهم‌ترین چیز چرخه عمر محصول است. این چرخه شامل مراحل زیر است:تعریف و طراحی: شامل برنامه‌ریزی کلی و طراحی محصول اولیه یا ویژگی‌ها.توسعه و استقرار: تیم‌های توسعه شروع به کار می‌کنند و ویژگی‌های جدید را به محصول اضافه می‌کنند.بازخورد و بهبود: پس از ارائه نسخه‌های جدید، بازخورد مشتریان جمع‌آوری شده و ویژگی‌ها بهبود می‌یابند.نگهداری و پشتیبانی: محصول پس از توسعه مداوم نیاز به پشتیبانی و به‌روزرسانی دارد.از سوی دیگر، مدیریت پروژه بیشتر شامل برنامه‌ریزی دقیق، زمان‌بندی و تحویل به موقع پروژه است.یک نمونه از توسعه محصول محور: GitLabگیت لب (Gitlab) یک نمونه بارز از محصول محور بودن در توسعه نرم‌افزار است. این پلتفرم ابزارهای متعددی برای مدیریت کد، CI/CD، امنیت و مانیتورینگ ارائه می‌دهد. در GitLab، هر ماه یک نسخه جدید از محصول ارائه می‌شود که ویژگی‌ها و بهبودهای جدیدی را شامل می‌شود. فرآیند توسعه GitLab به این صورت است که تیم‌های توسعه در اسپرینت‌های کوتاه کار می‌کنند و بازخوردهای مشتریان را در اولویت قرار می‌دهند. این رویکرد به GitLab کمک کرده است که به سرعت به یک ابزار قدرتمند و محبوب در جامعه توسعه‌دهندگان تبدیل شود.نتیجه‌گیریتفاوت‌های اساسی بین پروژه و محصول نشان می‌دهد که هر کدام به رویکردهای متفاوتی در مدیریت و توسعه نیاز دارند. پروژه‌ها موقتی و با اهداف خاص هستند، در حالی که محصولات نیاز به توسعه مداوم و توجه به نیازهای مشتری دارند. توسعه محصول محور، به‌ویژه با استفاده از مدل‌های چابک، روشی اثربخش برای بهبود و توسعه مداوم نرم‌افزارهاست. این رویکرد تضمین می‌کند که محصول همواره مطابق با نیازهای بازار و مشتریان به‌روزرسانی و بهبود یابد.ویژگی‌های جدید در توسعه محصول می‌توانند به‌عنوان پروژه‌های کوچک در نظر گرفته شوند. هرچند که آن‌ها بخشی از یک محصول بزرگ‌تر هستند، اما فرآیند توسعه هر ویژگی جدید، شامل برنامه‌ریزی، تخصیص منابع، اجرا و تحویل است که تمامی این مراحل مشابه با یک پروژه است. بنابراین، توسعه یک ویژگی جدید می‌تواند یک پروژه در مقیاس کوچک باشد که در نهایت به محصول اضافه می‌شود. اسماعیل غفارنیا اسماعیل غفارنیا Wed, 16 Oct 2024 14:47:59 +0330 https://virgool.io/@esmaeil-ghafarnia/%D9%BE%D9%86%D8%AC-%D8%B3%D8%B7%D8%AD-%D8%A7%D8%B2-%D8%AA%D8%B9%D8%A7%D8%B1%D8%B6-%DB%8C%DA%A9-%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%AC%D8%A7%D9%85%D8%B9-nkiqbwwwjrx1 Navigating the Five Levels of Conflict: A Comprehensive Explorationتعارض بخش طبیعی و اجتناب‌ناپذیر تعاملات انسانی است. چه در روابط شخصی، محیط‌های کاری یا سازمان‌های بزرگ، توانایی درک و مدیریت تعارض برای حفظ هماهنگی و دستیابی به نتایج مطلوب ضروری است. پنج سطح تعارض، که اغلب در محیط‌های سازمانی و بین فردی مورد بحث قرار می‌گیرند، چارچوبی را ارائه می‌دهند تا درک کنیم چگونه تعارض‌ها تشدید می‌شوند، علل ریشه‌ای آنها چیست و چگونه می‌توان آنها را حل کرد. این مقاله به بررسی این پنج سطح از تعارض، راهکارهای مدیریت هر سطح و تأثیر آنها بر روابط و محیط‌های کاری می‌پردازد.تعارض چیست؟تعارض به وضعیتی گفته می‌شود که در آن اهداف، نیازها، یا منافع دو یا چند طرف با یکدیگر ناسازگار است. این ناسازگاری می‌تواند به شکل‌های مختلفی بروز کند، از اختلافات جزئی گرفته تا نزاع‌های بزرگ و جدی. در بیشتر موارد، تعارض‌ها به دلیل تفاوت در نظرات، ارزش‌ها، یا منافع شکل می‌گیرند و اگر به درستی مدیریت نشوند، ممکن است به تشدید و حتی خرابی روابط منجر شوند.پنج سطح از تعارضپنج سطح تعارض که در این مقاله بررسی می‌شوند شامل موارد زیر می باشند:سطح اول: مشکلات روزمره و اختلافات جزئیسطح دوم: تعارضات شخصیسطح سوم: تعارضات گروهی یا سازمانیسطح چهارم: تعارض‌های نظام‌مندسطح پنجم: تعارض‌های تعاملی و ساختاریاین سطوح به ترتیب از شدت کم تا شدید طبقه‌بندی می‌شوند و هر کدام نیازمند رویکردهای خاصی برای حل و فصل هستند.سطح اول: مشکلات روزمره و اختلافات جزئیاین سطح از تعارض به مواردی اشاره دارد که در زندگی روزمره به‌طور طبیعی اتفاق می‌افتد. این اختلافات معمولاً به دلیل تفاوت در سلیقه‌ها، نظرات یا توقعات افراد به وجود می‌آید. به عنوان مثال، در یک محیط کاری، ممکن است دو همکار در مورد یک پروژه نظر متفاوتی داشته باشند یا در خانه، اعضای خانواده درباره نحوه انجام یک کار خانگی اختلاف نظر پیدا کنند.ویژگی‌هاکمترین سطح از شدت تعارض.معمولاً به راحتی قابل حل است.تأثیرات منفی پایدار ندارد.روش‌های مدیریتبرای مدیریت تعارضات در این سطح، رویکردهای ساده‌ای مانند گفتگو و گوش دادن فعال مؤثر است. بهتر است افراد بدون احساسات منفی با یکدیگر صحبت کنند و تلاش کنند تا به تفاهم برسند.سطح دوم: تعارضات شخصیاین سطح زمانی رخ می‌دهد که اختلافات جزئی به تعارضات شخصی تبدیل شوند. این نوع تعارض معمولاً ناشی از احساسات منفی، عدم درک متقابل یا سوء تفاهم است. به عنوان مثال، در یک تیم کاری، ممکن است یکی از اعضا احساس کند که دیگری به نظرات او توجه نمی‌کند و این موضوع به دلخوری منجر شود.ویژگی‌هاشدت بیشتری نسبت به سطح اول دارد.ممکن است روابط بین فردی را تحت تأثیر قرار دهد.نیازمند مدیریت دقیق‌تر است.روش‌های مدیریتدر این سطح، ارتباط مؤثر و شفاف اهمیت بیشتری پیدا می‌کند. افراد باید بتوانند به صراحت احساسات خود را بیان کنند و به طرف مقابل فرصت بدهند تا نظرات و دیدگاه‌های خود را بیان کند. همچنین، استفاده از مهارت‌های حل تعارض مانند همدلی و تفکر انتقادی می‌تواند به حل این نوع تعارض کمک کند.سطح سوم: تعارضات گروهی یا سازمانیدر این سطح، تعارض بین گروه‌ها یا واحدهای مختلف یک سازمان رخ می‌دهد. این نوع تعارض معمولاً به دلیل تفاوت در اهداف، منابع محدود، یا رقابت بر سر قدرت شکل می‌گیرد. به عنوان مثال، دو تیم در یک سازمان ممکن است بر سر تقسیم بودجه یا منابع انسانی با یکدیگر رقابت کنند.ویژگی‌هاپیچیدگی بیشتری نسبت به سطوح قبل دارد.ممکن است به کاهش بهره‌وری و کاهش روحیه تیمی منجر شود.نیازمند رویکردهای سازمانی و مدیریتی است.روش‌های مدیریتبرای مدیریت تعارضات سازمانی، استفاده از ابزارهای مدیریتی مانند میانجی‌گری، مذاکره و تکنیک‌های حل مسأله مؤثر است. مدیران باید به گونه‌ای عمل کنند که هر دو طرف تعارض را درک کرده و به راه‌حل‌های عادلانه دست یابند. همچنین، ایجاد شفافیت در اهداف و منابع می‌تواند به کاهش تعارضات سازمانی کمک کند.سطح چهارم: تعارض‌های نظام‌منداین سطح زمانی رخ می‌دهد که تعارض به ساختارها و فرآیندهای سازمانی گره می‌خورد. در این سطح، تعارضات به دلیل عدم کارایی سیستم‌ها یا ناکارآمدی سیاست‌ها و رویه‌ها به وجود می‌آید. برای مثال، در یک سازمان بزرگ ممکن است سیاست‌های منابع انسانی به شکلی باشد که برخی از کارکنان احساس نابرابری کنند و این موضوع به تعارضات جدی‌تری منجر شود.ویژگی‌هاتعارض‌های عمیق‌تر و پایدارتر.نیازمند تغییرات ساختاری برای حل مشکل.ممکن است تأثیرات طولانی‌مدت بر سازمان داشته باشد.روش‌های مدیریتبرای مدیریت تعارض‌های نظام‌مند، نیاز به بررسی دقیق فرآیندها و ساختارهای سازمان است. مدیران باید تغییرات لازم را در سیاست‌ها و رویه‌ها ایجاد کنند تا عدالت و شفافیت در سازمان بهبود یابد. همچنین، استفاده از مشاوره‌های حرفه‌ای و کارشناسان منابع انسانی می‌تواند به حل این نوع تعارض کمک کند.سطح پنجم: تعارض‌های تعاملی و ساختاریاین سطح بالاترین و پیچیده‌ترین سطح تعارض است. تعارض‌های تعاملی زمانی رخ می‌دهند که افراد یا گروه‌ها به شکلی عمیق‌تر و سیستماتیک با یکدیگر درگیر شوند و نتوانند به تفاهم برسند. این نوع تعارض‌ها معمولاً به ساختارهای اجتماعی یا فرهنگی گره می‌خورند و ممکن است به تغییرات عمیق و گسترده در سازمان یا جامعه نیاز داشته باشد.ویژگی‌هابالاترین سطح از شدت تعارض.نیازمند راه‌حل‌های جامع و بلندمدت.ممکن است تأثیرات اجتماعی و فرهنگی داشته باشد.روش‌های مدیریتمدیریت تعارض‌های تعاملی و ساختاری نیاز به تغییرات بنیادی دارد. در این سطح، باید از روش‌های استراتژیک و بلندمدت برای ایجاد تغییرات استفاده کرد. همچنین، توجه به مسائل فرهنگی، اجتماعی و سیاسی که ممکن است به تعارضات دامن بزند ضروری است. در برخی موارد، ممکن است نیاز به میانجی‌گری یا حتی تغییرات ساختاری در سطح کلان باشد.نتیجه‌گیریتعارض بخشی طبیعی از زندگی و تعاملات انسانی است، اما مدیریت نادرست آن می‌تواند به تشدید مشکلات و خرابی روابط منجر شود. آشنایی با پنج سطح از تعارض به ما کمک می‌کند تا درک بهتری از ریشه‌های تعارض پیدا کنیم و راه‌حل‌های مناسب‌تری برای مدیریت هر سطح ارائه دهیم. در محیط‌های سازمانی و بین فردی، استفاده از مهارت‌های ارتباطی، حل مسأله و میانجی‌گری می‌تواند به کاهش تعارض و افزایش بهره‌وری و هماهنگی کمک کند.تعارض اگر به درستی مدیریت شود، می‌تواند منجر به رشد، یادگیری و بهبود در روابط و ساختارهای سازمانی شود. اسماعیل غفارنیا اسماعیل غفارنیا Mon, 14 Oct 2024 16:43:39 +0330 https://virgool.io/@esmaeil-ghafarnia/linkedin-temporary-restricted-cigjywkfjdm2 Linkedin Temporary Restrictedدر هفته گذشته پس از تغییر رمز عبور در Linkedin که یک عادت همیشگی است و تقریبا هر 3 ماه انجام میدهم، همه چیز به صورت عادی بود تا اینکه شب هنگام زمانی که میخواستم اپ Linkedin را اجرا کنم با خطای Temporary restricted مواجه شدم، پیام عجیبی بود و تابحال با این اخطار روبرو نشده بودم، اهمیتی ندادم و سعی کردم Login کنم که وارد صفحه ای شدم و به من اجازه نداد و مضمون پیام این بود که فعالیت های مشکوکی در اکانت کاربری رخ داده است و ما مجبور به احراز هویت شما می باشیم. پیام عجیب و برای من استرس آور بود، اکانت 16 ساله ام Restricted شده بود و من هیچ ایده ای برای بازیابی آن نداشتم. اولین کاری که کردم سعی کردم به اعصابم مسلط باشم و شروع کردم به Search کردن در Google که مشاهده کنم آیا افراد دیگری هم به این مشکل برخورد کرده بودند یا خیر؟ در وب فارسی افرادی دچار این مشکل شده بودند و راه حل هایی نیز ارائه گردیده بود، من از فرم ذیل برای ارسال درخواست به Linkedin استفاده کردم.https://www.linkedin.com/help/linkedin/ask/ppqدر این بخش Regain Access to My Account را انتخاب و در بخش Your Question، سوال و درخواست خودم را بدین گونه مطرح کردم:Dear LinkedIn Support, I hope this message finds you well. I have recently encountered an issue where my LinkedIn account was closed, and I believe this might have happened due to my usage of various VPNs, as I reside in Iran. Unfortunately, due to restrictions, I have been a long-time user of LinkedIn and rely heavily on my account for professional networking. I urgently need access to my account to continue my work and professional connections. I kindly request that you review my case and consider reactivating my account as soon as possible. Thank you for your understanding and prompt attention to this matter.Best regardsدر حدود بازه زمانی 2 ساعت از ارسال این درخواست، به ایمیلم پیامی از Linkedin Support ارسال شد که هم بابت این موضوع عذرخواهی کرده بودند ولی ذکر کردند که هویت و Privacy کاربران برای ما خیلی مهم است و به لینک ذیل رجوع، کشور خود را انتخاب و تصویر Passport را Upload نمایید. من خوشحال شدم که با این روش میتوانم اکانتم را بازیابی کنم، ولی با توجه به اینکه کشور Iran در لیست Country ها بود، امکان بارگذاری تصویر Passport را نداد و پیامی مبنی بر عدم پشتیبانی از ایران به من نشان داد. مجدد به همان ایمیلی که از سمت Linkedin Support ارسال شده بود، پیامی ارسال کردم که من امکان Upload ندارم و در پاسخ به این درخواست یک فرم با دو فرمت Word و PDF ارسال کردند و از من خواستند که یک مرکز معتبر رسمی همچون شهرداری و یا دفاتر اسناد رسمی آن را تکمیل و مجدد برای ما ارسال کنید. دوباره به Google رجوع کردم که مشاهده کنم آیا وکلای بین المللی و یا مهاجرت می توانند چنین فرمی را تکمیل و من را احراز هویت کنند. در وب فارسی به نام آقای دکتر حسن امیرشاهی مواجه شدم که گویا برای افراد دیگری نیز چنین فرمی را تکمیل نموده بودند، تماس گرفتم و روز بعد به ایشان مراجعه کردم و فرم به همراه تصویر Passport تکمیل و به من ارائه گردید. در پاسخ به همان ایمیل هایی که Linkedin Support ارسال کرده بودم، فرم تکمیل شده را ارسال و پس از حدود 3 ساعت، پیامی مبنی بر Reset Password اکانت Linkedin برای من ارسال شد و مجدد توانستم اکانتم را بازیابی کنم. در اینجا چند نکته مهم را در مواجهه با چنین رخدادی عنوان می کنم: خونسردی خود را حفظ کنید و دچار استرس نشوید.از ایجاد اکانت جدید حتما خودداری کنید، به دلیل اینکه به احتمال بسیار زیاد اکانت جدید شما نیز به همین مشکل دچار خواهد شد. تمامی مراحلی که در بالا ذکر شد می بایست ظرف مدت 14 روز حتما انجام شود، در غیر اینصورت اکانت شما قابل بازیابی نخواهد بود. اسماعیل غفارنیا اسماعیل غفارنیا Thu, 26 Sep 2024 09:27:45 +0330 https://virgool.io/DesignersCommunity/%D8%B1%D8%B3%DB%8C%D8%AF%D9%86-%D8%A8%D9%87-%D8%AA%D8%B9%D8%A7%D9%85%D9%84-%D9%85%DB%8C%D8%A7%D9%86-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D8%A8%D8%A7-ux-%D8%A8%D9%87-%D8%B1%D9%88%D8%B4%DB%8C-%D8%AF%DB%8C%DA%AF%D8%B1-p2fhp7hhb33v اگر باید یکی را انتخاب کنید، ترجیح می دهید مدیر محصول باشید یا طراح UX؟این کار شما نیست.تقریباً ۱۰ سال پیش، قبل از شروع کار در IQ Capital، درباره اینکه مدیر محصول چه چیزی می تواند باشد، هیچ ایده ای‌ نداشتم. یکی از دوستانم به من گفت که در حال جذب نیروی جدید هستند و سوال من این بود که برای افرادی مثل من موقعیت هایی وجود دارد؟ بعد از صحبت با چند نفر، به من گفته شد، می توانم تحلیلگر تجاری (اصطلاح آنها برای مدیر محصول) خوبی باشم. ترکیبی از تجارت، تجزیه و تحلیل به نظر جالب توجه بود، بنابراین پیشنهاد را به سرعت قبول کردم.جمع آوری نیازهای کسب و کار، مشخص کردن امکانات و موضوعات اصلی، ارسال مشخصات به مهندسان، درست کردن نمونه رابط های کاربری، آزمایش پذیرش کاربر، گردآوری بازخورد مشتریان، پژوهشکاربر و مدیریت دامنه، از مسئولیت های من بودند. در آن زمان روند کاری این شرکت از متدهای Agile یا Lean بسیار دور بود، اما من روش بهتری نمی شناختم و شغلم را دوست داشتم.چهار سال بعد در OpenSky، برای اولین بار اصطلاح "طراح تجربه کاربری" را شنیدم. رئیسم اعلام کرد، قصد استخدام یک مدیر UX را دارد. ظاهرا نقش من به عنوان مدیر محصول با یک طراح UX یکسان و شبیه نبود. اکنون مدیر UX مسئولیت طراحی و نمونه سازی تمام رابط ها را بر عهده داشت و همه چیز را به بهترین شکل انجام می داد.اما من عاشق طراحی و ایجاد جریانهایی بودم که مشکلات را حل می کنند.سرانجام توسعه دهندگان نیز در این فرآیند شرکت کردند. ما با یکدیگر طراحی می کردیم و مطالب و ایده هایمان را در هم تلفیق و جفت و جور می نمودیم. اما زمانیکه مدیر جدید UX شروع به کار کرد، بیشتر اینها از بین رفت. او دست به کار شده بود و من هنوز ایده های محصول را آزمایش می کردم، اما دیگر نتوانستم در جلب نظر کاربران، مشارکتی داشته باشم.به سرعت فهمیدم این نقشی نیست که می خواستم. بنابراین استعفا دادم تا در شرکت دیگری به عنوان مدیر UX Designer مشغول به کار شوم. حالا مشکلم برعکس بود و مجاز به مشارکت در تصمیم گیری های شرکت در زمینه امکانات و موضوعات اساسی نبودم. مدیران محصولات این موارد را انجام می دادند و من فقط طراحی می کردم.موضوعاتی تأیید می شدند که به بازخوردی که از مشتریان می شنیدم مربوط نمی شدند. زمانیکه این سوال برایم پیش آمد "چرا آنها را می سازیم"، به سرعت مورد حمله قرار گرفتم.گیج شده بودم. اگر من مدیریت محصول و UX را انجام داده ام و در هر دو عملکرد خوبی داشتم، در نهایت جایگاه درست من کجا است؟در مدیریت محصول، کمی UX نیز وجود دارد.وقتی این نقش ها را مقایسه می کنم، مسئولیت های کاملا شفافی را می بینم. به عنوان نمونه، اولویت بندی درخواست های اصلی به طور معمول توسط یک مدیر محصول هدایت می شود.سپس، مسئولیت هایی وجود دارد که مبهم هستند. چه کسی شخصیت ها و نقش ها را به وجود می آورد؟ من شخصیت هایی را در یک شرکت بعنوان مدیر محصول، در شرکتی دیگر مدیر UX و در جای دیگری تحت عنوان بازاریاب مشاهده کرده ام. چه کسی مسئول تحقیق کاربر است؟چنانچه شما توضیحات مختلف شغلی را بخوانید، همپوشانی زیادی در مسئولیت های اصلی مشاهده خواهید کرد:وقتی مشغول نوشتن برنامه آموزشی مدیریت محصول برای مجمع عمومی بودم، مشکلاتی داشتیم. هفته ها به موضوعاتی مثل شخصیت ها، تحقیق، عملیات نمونه سازی و غیره اختصاص داده شده بود که بعضی از آنها صرفاً UX را مد نظر قرار می داد. اما این موارد برای مدیریت محصول نیز ضروری هستند.این مربوط به نقش ها نیست، بلکه مربوط به مهارت ها است.من تعریف نقشها را به نسبت نحوه عملکرد یک شرکت کمتر متوجه شدم. تیمهایی که در آن ها میزان مشارکت زیاد است،دارای مدیران محصول و طراحان UX هستند و این افراد بر اساس نیاز پروژه، وظایف یکدیگر را تعیین و پشتیبانی می کنند و در نهایت هر کسی کاری را انجام خواهد داد که بتواند به بهترین شکل از عهده آن بر بیاید. آن ها در این موارد با یکدیگر توافق دارند. گاهی اوقات طراح UXمی تواند تحقیق کند و در موارد دیگر مدیر محصول، اما من امیدوارم این دو بیش از این ها با یکدیگر همکاری کنند.شرکت ها باید بدانند مدیران محصولات و طراحان UX، هر دو از اهمیت بالایی برخوردار هستند، اما موضوع مهم تر این است که این دو می توانند با یکدیگر تصمیم بگیرند. مدیریت محصولات بدون طراح رابط کاربری، منجر به طراحی محصولاتی می شود که باعث هیجان کاربران نخواهد شد. طراحی تجربه کاربر بدون مدیریت محصول، محصولاتی تولید می کند که به تجارت تبدیل نمی شوند. چنانچه این دو نقش، مسئولیت های مشترکی نداشته باشند، شما در تیم و محصول خود گسستگی خواهید داشت.اگر به جای تعریف نقش، تغییر گفتگو را با مهارت پوشش بدهیم، همه چیز واضح تر می شود. آیا ما تمام مهارتهای لازم در این تیم را برای اعتبار سنجی و اجرای ایده محصول داریم؟ اگر ما یک مدیر محصول داریم که نمی تواند عملیات نمونه سازی را انجام دهد، بیایید یک طراح UX استخدام کنیم. اگر واقعاً بخواهیم این کار را تکرار کنیم و سریعتر به بازار برویم، باید روی محدود کردن اندازه تیم مان تمرکز کنیم. دارا بودن بیش از حد بسیاری از قطعات متحرک روند ما را کند خواهد کرد. دامنه کار را محدود کنید و به جای اضافه کردن نقش ها یا افراد به یک تیم، تعداد تیم ها را افزایش دهیم.دانش من از طراحی UX، من را به مدیر محصول بهتر و دانشم از مدیریت محصولات، من را به یک طراح UX بهتر تبدیل می کند. این امر باعث می گردد در تولید محصولاتی که کاربران را راضی می کند و مشکلات شان را برطرف می کند، عملکرد بهتری داشته باشم.منبع مطلب اسماعیل غفارنیا اسماعیل غفارنیا Mon, 28 Oct 2019 20:43:12 +0330 https://virgool.io/Software/python-flask-framework-part-03-hc730njvff7z یک برنامه ساده در فریم ورک Flask به شکل ذیل می باشد:from flask import Flask app = Flask(__name__) @app.route('/') def hello_world(): return 'Hello, World!' و حالا مواردی که باید از این کد بدانیم:1. در ابتدا Flask کلاس را در برنامه Import کردیم.2. در مرحله بعد یک Instance از این کلاس را ایجاد کردیم. اولین بخش از این قطعه کد نام application's module یا پکیج مورد استفاده می باشد. اگر ما بخواهیم همانند کد فوق، از یک Single ماژول استفاده کنیم می بایست از ساختار __name__ استفاده کنیم، این نام گذاری به جهت اینکه کد شما به صورت این که به عنوان یک برنامه اجرا شود یا یک ماژول مورد اهمیت می باشد. 3. سپس از ()route جهت مسیریابی برنامه استفاده می کنیم، در آینده از این بخش استفاده های بیشتری خواهیم نمود. 4. در این بخش یک متد با نام hello_world ایجاد می کنیم و در آن پیامی که می خواهیم به کاربر نمایش دهیم را وارد می کنیم. هم اکنون این قطعه کد را با نام hello.py ذخیره می کنیم. توجه داشته باشید از نام flask.py به علت conflict با کدهای فریم ورک استفاده نکنید. اجرای برنامه در محیط لینوکس$ export FLASK_APP=hello.py $ flask run * Running on http://127.0.0.1:5000/اجرای برنامه در محیط ویندوزC:\path\to\app>set FLASK_APP=hello.py اجرای برنامه در محیط پاورشلPS C:\path\to\app> $env:FLASK_APP = "hello.py" سپس برنامه توسط یک Web Server داخلی که جهت تست برنامه های ایجاد شده با Flask مناسب و کارآمد بوده اجرا و پیام مورد نظر را در مرورگر به کاربر نمایش می دهد.  اسماعیل غفارنیا اسماعیل غفارنیا Thu, 26 Jul 2018 20:57:05 +0430 https://virgool.io/Software/python-flask-framework-part-02-swyh6lkvnk6i فریم ورک Flask از آخرین نسخه از پایتون 3، 2.7 و PyPy پشتیبانی می کند، درهنگام نصب این فریم ورک پیش نیازهای ذیل به صورت اتوماتیک نصب می گردند:- Werkzeug- Jinja- MarkupSafe- ItsDangerous- Clickموارد ذیل نیز به صورت Optional می توانند نصب گردند:- Blinker- SimpleJSON- Python-dotenv- Watchdogدر مقالات بعدی، در خصوص این موارد توضیحاتی ارائه خواهد شد.معرفی Virtual Environmentاز یک Virtual Environment برای مدیریت وابستگی های یک پروژه در محیط تولید و عملیات استفاده می شود. شاید این سوال پیش بیاید که چرا می بایست از یک Virtual Environment استفاده نمود؟هرچقدر تعداد پروژه های پایتون بیشتری داشته باشیم، به احتمال بسیار زیاد می بایست از نسخه های مختلف Library های پایتون استفاده نمود و نکته ی مهم اینجاست که نسخه های مختلفی از یک Library می تواند باعث عدم اجرای صحیح پروژه های دیگر شود در همین راستا Virtual Environment ها محیط های مستقلی از Library های پایتون هستند که فایل های نصب شده برای هر پروژه را با پروژه ی دیگری متفاوت خواهند نمود.ایجاد Virtual Environment لینوکس، نسخه 3 پایتونmkdir myprojectcd myprojectpython3 -m venv venvویندوز، نسخه 3 پایتونpy -3 -m venv venvفعال سازی Virtual Environmentپیش از شروع کار برروی پروژه، می بایست Virtual Environment ایجاد شده را با استفاده از دستور ذیل فعال نمود:لینوکس. venv/bin/activateویندوزvenv\Scripts\activateنصب Flaskپس از فعال سازی Virtual Environment، می بایست Flask را با استفاده از دستور ذیل نصب نمایید:pip install Flaskهم اکنون پروژه با فریم ورک Flask آماده استفاده می باشد. اسماعیل غفارنیا اسماعیل غفارنیا Mon, 23 Jul 2018 09:23:50 +0430 https://virgool.io/Software/python-flask-framework-part-01-hfjdahdqvyl9 در این مجموعه مقالات می خواهیم یکی از فریم ورک های زبان برنامه نویسی پایتون را با نام Flask که با عنوان Micro-Framework معروف است معرفی نماییم. این فریم ورک دارای هسته ای کوچک و ساده ولی با قابلیت انعطاف پذیری و گسترش با Plugin هایی از جمله Babel, CouchDB, MongoDB و ... می باشد. لازم به ذکر است Micro به معنای این که تمامی برنامه های وب شما می بایست در یک فایل واحد پایتون قرار بگیرند نیست (اگرچه قاعدتا می تواند بدین سان هم باشد). همانطور که در بالاتر ذکر شد در این Framework، هسته ی اصلی به صورت کوچک و ساده طراحی شده ولی می توان به راحتی آن را گسترش داد. اگر بخواهیم خیلی راحت بیان کنیم Flask برای شما تصمیم نمی گیرد که چگونه از پایگاه داده استفاده کنید و یا از چه نوع Template Engine و با چه رویکری می بایست استفاده کرد، همه چیز برای تغییر آسان است، همه چیز را همانگونه که بخواهید می توانید تغییر دهید. به طور پیش فرض، Flask شامل مواردی همچون Database abstraction layer یا form validation نمی باشد بلکه به شما اجازه می دهد از Plugin هایی همچون ارتباط با پایگاه داده، اعتبارسنجی فرم، آپلود فایل، تکنولوژی های مختلف احراز هویت و ... استفاده کنید. در ذیل به ویژگی های اصلی این فریم ورک اشاره می کنیم:- راحتی استفاده- یکپارچگی و استفاده به صورت Built in از Development Server و Debugger- پشتیبانی از Unit Testing- پشتیبانی از RESTful request- استفاده از Jinja2 Templating- پشتیبانی از Secure Cookies- پشتیبانی از Unicode- مستندسازی زیاددر ذیل نمونه ای از یک برنامه ساده به Flask را مشاهده می کنیم.from flask import Flask app = Flask(__name__)   @app.route("/") def hello(): return "Hello World!"   if __name__ == "__main__": app.run() با اجرای دستور ذیل و باز کردن مرورگر می توان نتیجه را مشاهده نمود. $ python hello.py * Running on http://localhost:5000/ در سری مقالات بعدی، به جزییات برنامه نویسی با این فریم ورک و هم چنین نحوه نصب و استفاده از آن خواهیم پرداخت. اسماعیل غفارنیا اسماعیل غفارنیا Sun, 22 Jul 2018 22:05:30 +0430 https://virgool.io/@esmaeil-ghafarnia/%D8%AA%D9%81%D8%A7%D9%88%D8%AA-%D9%85%DB%8C%D8%A7%D9%86-%DA%A9%D9%88%DA%86-%D9%88-%D9%85%D9%86%D8%AA%D9%88%D8%B1-ie2wps2os تفاوت میان کوچ و منتور اصطلاحات کوچینگ (coaching) و منتورینگ (mentoring) با شروع استارت‌آپ‌ها بیشتر مطرح شده اند و امروز در زمینه کسب‌و‌کار نیز استفاده می‌شوند و معمولا به‌جای یکدیگر به‌کار می‌روند. به همین دلیل در بسیاری از سازمان‌ها، از یک منتور انتظار دارند مسوولیت‌های کوچینگ را هم به‌عهده بگیرد. اما به‌رغم باور عموم این دو مقوله یعنی منتور و کوچ تفاوت‌های زیادی با یکدیگر دارند. برای اینکه تفاوت میان این دو را بدانیم و از دستاوردهایی که هرکدام برای کسب‌و‌کارمان به ارمغان می‌آورند مطلع باشیم، باید ابتدا با مسوولیت‌های مخصوص هر یک آشنا شویم.منتور کیست؟ به زبان ساده یک منتور کسی است که دانش، تخصص و مشاوره خود را به کسانی که تجربه کمتری دارند ارائه می‌دهد. منتور با بهره‌گیری از تجربه و مهارت‌های خود، کارمندانش را در مسیر درست هدایت می‌کند. یک منتور به کارمندان تازه‌کار برای یافتن فرصت‌های رشد حرفه‌ای، به‌دست آوردن اعتماد‌ به‌نفس و بهبود مهارت‌های فردی کمک می‌کند. این کمک و حمایت بر اساس تجربه‌ها و آموخته‌های شخصی منتور است که باعث جلب اطمینان بیشتر از جانب کارمندان خواهد شد.وظایف یک منتور چیست؟همان‌طور که گفته شد، یک منتور کسب‌و‌کار با توجه به رشد حرفه‌ای و توسعه مهارت‌های بین فردی و متقابل کارمندان تازه کارش، از آنها حمایت و پشتیبانی می‌کند و به‌ویژه او کمک می‌کند تا این کارمندان گزینه‌ها و انتخاب‌های حرفه‌ای خود را کشف کنند، اهداف توسعه را تعیین کنند، ارتباطات جدید ایجاد کنند و منابع را به خوبی شناسایی کنند. در این روش، یک منتور به عنوان الگو و مشاوری حرفه‌ای برای کارمندان عمل می‌کند. نقش یک منتور بر اساس نیازهای متغیر کارمندان تازه‌کار در طول زمان، تکامل پیدا می‌کند. در اغلب موارد، روابط منتورینگ غیررسمی است، درحالی‌که چنین روابطی هرازچندگاهی می‌تواند رسمی‌تر باشد. در روابط منتورینگ رسمی، منتورها روش‌های از پیش تعیین شده و ساختاریافته‌ای را برای تعیین و تنظیم انتظارات واقع‌بینانه، به‌دست آوردن و افزایش منافع متقابل و ارتقای کیفیت کارمندان دنبال می‌کنند.منتورهای خوب همیشه تمایل دارند تا مهارت‌ها و دانش خود را با کارمندان جوان به اشتراک بگذارند و از آنجایی که آنها هم مانند کارمندان تازه‌کار با همین چالش‌ها مواجه شده‌اند، می‌توانند با همدلی بیشتر با نیازهای آنان برخورد کنند. منتورها برای الهام بخشی و ایجاد اطمینان و اعتماد در عملکرد خود، نگرش مثبت و تمایل به مقابله با مشکلات را دارند. این ویژگی به آنها کمک می‌کند که با کارمندان جوان در مورد اهداف و دغدغه‌های حرفه‌ای راحت‌تر بحث کنند.از دیدگاه کسب‌وکار، منتورها به کارمندان در بالا بردن اعتماد به‌نفس، توسعه مهارت‌ها و افزایش اعتبار آنها کمک می‌کنند و کارمندانی که دارای اعتماد به‌نفس و رضایتمندی هستند، سازمان را به جلو هدایت می‌کنند و به همین دلیل کسب‌و‌کارها در حال حاضر تمرکز خود را بر شناسایی برنامه‌های منتورینگ صحیح، راهبردی و حمایتی قرار داده‌اند.کوچ کیست؟ کوچ بر مهارت‌های خاص و اهداف توسعه یافته تمرکز دارد؛ او این کار را با تجزیه این مهارت‌ها و اهداف به وظایف و کارهای مشخص در یک دوره زمانی مشخص انجام می‌دهد که درنتیجه با انجام این کار و برای روشن ساختن چشم‌انداز پیشرفت کسب‌و‌کار، به رشد آن کمک می‌کند. شناسایی و اولویت‌بندی اهداف برای بسیاری از کسب‌و‌کارها یک چالش بزرگ محسوب می‌شود. کوچ‌ با کمک به کسب‌و‌کار‌ها برای اولویت‌بندی اهدافشان بر اساس اهمیت آنها با این چالش‌ها مقابله می‌کند. آنها به دنبال یک روش نظام‌مند و رسمی‌تر برای حل و فصل مسائل و مدیریت جنبه‌های خاص کسب‌و‌کار هستند.وظیفه یک کوچ چیست؟یک کوچ خوب بر تعیین اهداف، اولویت‌بندی آنها و انتخاب راه درست برای رسیدن به آنها تمرکز می‌کند. به این ترتیب او کمک می‌کند تا کسب‌و‌کارها بیشتر پاسخگو، هدف‌محور و رقابتی باشند. او همچنین جنبه‌های مختلفی از یک کسب‌و‌کار موفق و در حال اجرا؛ ازجمله اهداف فروش، استراتژی‌های بازاریابی، مهارت‌های ارتباطی، ایجاد و ساخت تیم، رهبری و… را پوشش می‌دهد. کوچ‌ها کسب‌و‌کارها را به‌گونه‌ای فراگیر ارزیابی می‌کنند و با این کار به تنظیم طرح، تعیین اهداف و شناسایی مراحل مورد نیاز برای رسیدن به نتایج موردنظر می‌پردازند. یک کوچ کسب‌‌وکار وضع موجود را به چالش می‌کشد و کسب‌و‌کارها را وادار می‌کند تا نگاه دقیق‌تری به رویکردها، روش‌ها و تصمیمات خود داشته باشند. به این ترتیب چشم‌انداز تازه‌ای برای استراتژی‌ها و اهداف کسب‌و‌کار ترسیم می‌کنند و در ازای مطرح کردن سوالات ساده‌ای در زمینه چگونگی اجرا و روند کارها، سازمان را به اتخاذ استراتژی‌های مناسب رشدشان هدایت می‌کند.یک کوچ با هدایت کسب‌و‌کارها در مسیر صحیح، در جهت حصول موفقیت آن کمک می‌کند. اغلب کسب‌و‌کارها دچار فقدان چشم‌انداز اهداف موردانتظار هستند و در طی کردن مراحلی که آنها را به موفقیت می‌رساند دچار خطا می‌شوند، اما یک کوچ شفافیت لازم برای دستیابی به این چشم‌انداز را فراهم می‌کند. آنها ایده‌های موجود را مورد تردید و پرسش قرار می‌دهند و کسب‌و‌کار را به مسیر اصلی برمی‌گردانند.تفاوت‌های بین این دو مقولهمنتورینگ یک فرایند طولانی مدت و براساس اعتماد و احترام متقابل است اما کوچینگ یک فرایند کوتاه‌مدت است.منتورینگ بر ایجاد یک ارتباط غیررسمی بین منتور و کارمند تازه‌کار متمرکز است، در حالی که کوچینگ یک رویکرد ساختار‌یافته‌تر و رسمی را دنبال می‌کند.یک منتور کسب‌و‌کار دارای تجربه‌های مهمی است که به درآمدزایی کارمند تازه‌کار منتهی می‌شود، اما یک کوچ، کسب‌و‌کار تجربه‌ها و عملکردهای سازمان را مورد تحلیل و پرسش قرار می‌دهد. اولویت منتور، کمک به توسعه مهارت‌های کارمند در فعالیت‌های فعلی و عملکردهای آتی آن است، اما اولویت کوچ بهبود عملکرد و کارایی فعلی و تاثیرگذاری در عملکردهای زمان حال است.منتورها و کوچ‌ها از راه‌های متفاوت می‌توانند در بهبود و سودمندی کسب‌‌وکارها نقش داشته باشند و برای حصول این امر، کسب و کارها نیاز به شفافیت اولویت‌ها و نوع حمایت‌های موردنیازشان دارند. کسب‌و‌کارهای کوچک به‌واسطه حمایت‌های صحیح و بجا سازنده‌تر، سودآور و رقابتی‌تر خواهند بود. باید توجه داشت که بهتر است بدون اینکه گرفتار تفاوت تعاریف بشویم روی این موضوع اصلی متمرکز باشیم، برای رشد در هرکاری همواره نیاز به کمک گرفتن از افراد باتجربه هست.منبع: روزنامه دنیای اقتصاد اسماعیل غفارنیا اسماعیل غفارنیا Tue, 20 Jun 2017 05:06:32 +0430 https://virgool.io/@esmaeil-ghafarnia/%DA%A9%D9%88%DA%86%DB%8C%D9%86%DA%AF-%D9%88-%D8%AA%D8%B9%D8%B1%DB%8C%D9%81%DB%8C-%D8%A7%D8%B2-%D8%A2%D9%86-hi480ten7 کوچینگ و تعریفی از آنکوچینگ هنر بهسازی عملکرد دیگران است. مدیرانی که این روش را برای هدایت اعضای گروه خود به کار می گیرند در واقع آن ها را تشویق می کنند که با انجام کارهاش چالش برانگیز بر تجربیات خود بیفزایند.کوچینگ عبارتست از:مکالمه ای که به یادگیری کمک می کند.فرآیندی که فرصت هایی را برای بهبود و تغییر فراهم می کند.راهکاری که کمک می کند بهترین راه حل را پیدا کنید.مجموعه ای از ابزارها و روش ها که فرآیند یادگیری را پشتیبانی می کند.هنر تسهیل کارآیی، یادگیری و توسعه یک فرد دیگر را کوچینگ می گویند. اما یادمان باشد در این تعریف کلید واژه ی اصلی، کلمه تسهیل است. فرض اصلی این است که راهنمایی شونده، توانایی درک مطالب را از طریق خودش دارد و کوچ پتانسیل نهفته را استخراج می کند. اسماعیل غفارنیا اسماعیل غفارنیا Tue, 20 Jun 2017 05:03:56 +0430 https://virgool.io/enline/%DA%A9%D9%88%DA%86%DB%8C%D9%86%DA%AF-%D8%B1%D8%B4%D8%AA%D9%87-%D8%AC%D8%AF%DB%8C%D8%AF-%D8%B9%D9%84%D9%85%DB%8C-%D8%A7%D8%B3%D8%AA%D8%9F-isjeo1f4d کوچینگکوچینگ رشته ی جدید علمی نیست که به یکباره و به طور ناگهانی بوجود آمده باشد، کوچینگ احتمالا باید به اندازه برگزاری اولین مسابقه تیراندازی در عصر حجر قدمت داشته باشد. با این حال در دهه اخیر بوده است که واقعا می توان مفهوم کوچینگ را در زمینه تجارت و کسب و کار و خارج از محیط ورزشی دید.کوچینگ همیشه بخش طبیعی از زندگی هر فردی و در هرجایی بوده است، زمانی که میلیون ها پدر و مادر در هرجایی از دنیا فرزندان خود را بی قید و شرط دوست دارند و نیازهای آنان را به طور کامل برآورده می کنند و حمایت همه جانبه ای از آن ها دارند تا رشد کنند و یا وقتی صدها هزار نفر از رهبران بزرگ و موفق می دانند که چگونه کارمندان خود را رشد دهند، آن هم نه با اعمال زور و قدرت، بلکه با باور کردن آن ها، به چالش کشاندنشان، حمایت از آن ها و دادن بازخوردهای مثبت و منقی در واقع از کوچینگ استفاده می کنند.اما این حوزه به مفهوم امروزی آن در اوایل دهه ۱۹۸۰ آعاز گردید. پیش از ابداع واژه کوچینگ، افراد فعال در این عرصه برای اشاره به خودشان از عناوینی نظیر مربی، مشاور، راهنما و گاهی هم از واژه دستیار استفاده می کردند. در حال حاضر این حرفه به خوبی شناخته شده و از جایگاه معتبر شغلی خاصی برخوردار است و گفته می شود پس از مشاغل حوزه ی IT، در سال های آنی به صنعت شماره ی دو در حال رشد تبدیل خواهد شد.براساس گزارش فدراسیون بین المللی کوچینگ (ICF) در حال حاضر تقریبا ۱۶ هزار کوچ پاره وقت و تمام وقت در سراسر دنیا وجود دارد که متوسط درآمد سالانه آن ها از ۳۵ تا ۱۰۰ هزار دلار و حتی بیشتر در نوسان است البته کوچ های حرفه ای تر درآمد قابل ملاحظه تری دارند. حوزه مذکور عرصه ی جدیدی بوده و در سراسر جهان به سرعت در حال رشد است و با ملاحظه این واقعیت که هر فردی می تواند از کوچ و آموزش های وی بهره مند شود در چند سال آینده شمار کوچ های مورد نیاز به چندین برابر خواهد رسید. اسماعیل غفارنیا اسماعیل غفارنیا Tue, 20 Jun 2017 04:59:37 +0430