https://virgool.io/feed/@omid_mojabi اسکرام مستر/ اجایل کوچ fa 2026-04-14 08:52:16 https://files.virgool.io/upload/users/195345/avatar/U1a2wp.jpg?height=120&width=120 https://virgool.io/@omid_mojabi https://virgool.io/@omid_mojabi/future-of-jobs-and-last-mile-delivery-sbhnq9ufvwgr ربات خودران برقی برای دلیوری غذا و بسته‌های کوچکدر حالی که ما روزانه مشغول سوزاندن میلیون‌ها لیتر بنزین در خودروها و موتورسیکلت‌های ناامن و ایجاد انواع آلودگی‌های صوتی و محیطی برای تحویل غذاهای ناسالم و یا بسته‌هایی از کالاهای بی‌کیفیت هستیم، در فاصله‌ای دور از ما - هم از منظر فاصله و هم به نظر زمان - فناوری edge در حال رونمایی از آینده last mile در چرخه دلیوری محصولات است؛ این بار با ربات خودرانی که غذا و بسته‌های کوچک را به مشتریان تحویل می‌دهد!این ماه پلتفرم دلیوری DoorDash، از ربات کوچک خود (با اسم Dot) برای تحویل غذا و بسته‌های سبک رونمایی کرده‌است. این ربات بامزه می‌تواند با سرعت ۳۲ کیلومتر در ساعت در خیابان‌ها، مسیرهای دوچرخه و پیاده‌روها حرکت کند. این پروژه در حال حاضر به صورت آزمایشی در شهر فینیکس آمریکا فعال شده و گذر زمان مشخص خواهد کرد که چقدر از آن استقبال خواهد شد. موفقیت این ربات می‌تواند منجر به پیووت بعدی در پروداکت دلیوری شود.ویدئوی این رونمایی را می‌توانید از اینجا تماشا کنید.مهم نیست چقدر در رابطه با فناوری‌های edge و شکاف دیجیتالی بین جوامع آگاهی داریم، این تصاویر واقعاً تأمل‌برانگیز هستند. به نظر می‌رسد بزودی، انسان‌ها هیچ شغلی برای انجام دادن نخواهند داشت - شاید به جز کار با داده‌ها در حوزه دانش. این تصویر دنیای آینده است - امن، آرام و عاری از حضور انسان. امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Fri, 17 Oct 2025 11:36:50 +0330 https://virgool.io/@omid_mojabi/httpsvirgoolioomidmojabimore-about-postmortem-tjhgdws4dhqg یادگیری از رخدادها تنها هدف پست مورتم نیستپست اخیر راجع به دستاورد Gen-AI تیم SRE شرکت زالاندو منجر به دریافت فیدبک‌هایی شد که یکی از آنها ابهام راجع به تعریف دقیق عبارت پست مورتم بود. برای مثال یکی از مخاطبان گفته با اینکه توی شرکتی که مشغول به کار هست به اندازه خوبی ازش دارند همه روزه اما متوجه نشده دقیقا چیه قضیه. به همین دلیل تصمیم گرفتم در این پست توضیح مختصری بنویسم که اصطلاحا هم‌صفحه بشیم راجع به کلیت موضوع.پست مورتم از خاستگاه علوم تجربی و پزشکی به سایر علوم از جمله IT و نرم‌افزار اومده و نکته اساس آن یادگیری به منظور اجتناب از تکرار اشتباهات گذشته در پروژه‌ها و کارهای آینده است. یادگیری یعنی ماتریالی از جنس دیتا و اطلاعات باید برای مرور اتفاقات رخ داده در جایی گردآوری بشود. چگونه؟ خیلی بستگی به کانتکست داره اما چه دستی انجام بشه و چه اتوماتیک حاصل کار یه حجم بالکی از دیتا هست که حتما باید مورد تفسیر و تجزیه و تحلیل قرار بگیره تا منجر به یادگیری بشه.نگاهی طنز به بعضی از ترندهای نزدیک به مبحث پست مورتم در IT/IS - تصاویر انتخابی از workchronicles.comخب تا اینجا مرزهای موضوع رو گرفتیم. حالا کمی بپریم داخل؛ این دیتا اگر در یک سنسور IoT باشه و یا در ذهن اعضای یک تیم باشه کمی شیوه گردآوری و تفسیر آنها متفاوت خواهد بود. لاگ‌های سرور یا پایپ‌لاین‌های سیستم امروزه معمولا به صورت خودکار و بر اساس یه زمان‌بندی و یا رخدادی خاص جمع‌آوری می‌شوند. اما گردآوری اطلاعات داخل مغز انسان مدیای ممکن است دیگری مانند گزارش نوشتاری یا جلسه نیاز داشته باشد. نتیجه این گردآوری‌ها دیتا یا همان پست مورتم هست که هم باید نگهداری شود و هم قابلیت استفاده مجدد داشته باشد و قسمت دشوار کار - یعنی تحلیل پست مورتم یا Postmortem Analysis - هم همین جاست که می‌تواند موضوع خوبی برای یک گفتگو در آینده باشد.👍😉ممکن است با اسامی دیگری مانند Root Cause Analysis یا RCA (از مکتب تویوتا)، Retrospective یا همون رتروی خودمون (این واس ماس😜) از اجایل، autopsy (پزشکی)، lesson learned (اصطلاح حوزه مدیریت دانش) و غیره هم اشاره بشه به موضوع که با وجود جزئیات زیادی راجع به هر کدام از آنها کلا زیاد ترسناک نیست قضیه! تنها نکته اینه که برای پست مورتم معمولا انتظار داریم در انتهای فرآیند به طریقی گزارشی داشته باشیم که شاید برای بقیه الزامی نباشه و یا فرمت‌های خاصی براش در نظر گرفته باشه هر پرکتیس که البته موضوع این نوشته راجع به اونها نیست. 😉🙏 فقط یادمون باشه بعضی فرآیندها خروجی ملموس ندارن اما در چیزی که عموما میگیم بهش پست مورتم انتظار داریم در انتهای فرآیند به طریقی گزارشی داشته باشیم.منابع بیشتر برای مطالعه راجع به پست‌مورتم:👇👇1. Dingsøyr, T. (2005). Postmortem reviews: purpose and approaches in software engineering. Information and Software Technology, 47(5), 293-303. https://doi.org/10.1016/j.infsof.2004.08.0082. Schmidt, J. (2024). An IT project postmortem: identifying root causes and eliminating rival explanations. Journal of Information Technology Case and Application Research, 26(4), 318-364. https://doi.org/10.1080/15228053.2024.24269653. Politowski, C., Fontoura, L. M., Petrillo, F., & Guéhéneuc, Y. G. (2018). Learning from the past: A process recommendation system for video game projects using postmortems experiences. Information and Software Technology, 100, 103-118. https://doi.org/10.1016/j.infsof.2018.04.0034. Stålhane, T., Dingsøyr, T., Hanssen, G. K., & Moe, N. B. (2003). Post mortem–an assessment of two approaches. In Empirical Methods and Studies in Software Engineering: Experiences from ESERNET (pp. 129-141). Berlin, Heidelberg: Springer Berlin Heidelberg. https://link.springer.com/content/pdf/10.1007/b11962.pdf#page=138 امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Thu, 16 Oct 2025 10:49:45 +0330 https://virgool.io/@omid_mojabi/httpsvirgoolioomidmojabiawoplescw0vb-awoplescw0vb بن بست یا معدن طلای دیتا - طراحی توسط DALL.Eهمانطور که امیدوارم همه بدانیم، اون چیزه متدها و مناسک نیستند. بلکه در کهکشان‌های همسایه یعنی مایندست و ویژن می‌چرخه!زالاندو اخیراً گزارشی منتشر کرده که نشان می‌دهد چگونه آنها توانسته‌اند پست‌مورتم‌هایشان (اگر هنوز در سیاره اسکرام هستید، آن را به عنوان جلسات و اکشن‌های رترو در نظر بگیرید!)، که به عنوان گزارش‌های دروس آموخته از شکست‌ها در نظر گرفته می‌شوند (و امید است در جایی مانند یک صفحه وب در کانفلوئنس شرکت نوشته شوند) و تیم‌ها پس از بحث و تصمیم‌گیری در مورد آنها هرگز کاری در راستای حل آن مسائل انجام نداده را به منبع قدرتمندی از بینش استراتژیک تبدیل کنند.معمولا دروس آموخته به صورت یک پست‌مورتم‌ (خیلی سخته این کلمه رو به فارسی ترجمه کرد!) نوشته و در جایی تلنبار میشده و تجزیه و تحلیل آنها به صورت دستی خیلی دشوار بود. در اینجا لحظه‌ای است که این روزها ناگهان ایده‌ای به ذهن گونه انسان‌ها می‌رسد:چه می‌شد اگر دیتای مربوط به هر کدام از این کات‌آف‌ها و خرابی‌ها بتواند کل سیستم ما را هوشمندتر کند؟این پرسشی بود که تیم SRE زالاندو در مورد حجم زیاد داده‌های مربوط به خرابی‌های زیرساخت‌هایشان از خودشان پرسیدند و برای پاسخ به آن، آنها یک پایپ‌لاین هوشمند چندمرحله‌ای (بازم کلمه فارسی کم اومد!) با استفاده از مدل‌های زبانی بزرگ (LLMs) ساختند. این سیستم به طور خودکار هزاران مورد از موارد پس از وقوع را خلاصه کرد، تکنولوژی‌ها و زیرساخت‌های مربوطه (مانند AWS S3، DynamoDB یا Postgres) را بررسی و شناسایی کرد، دلایل ریشه‌ای را تجزیه و تحلیل کرد و الگوهای خرابی بین سیستمی را آشکار نمود. کاری که زمانی هفته‌ها تلاش انسانی را می‌طلبید، اکنون می‌توانست در عرض چند ساعت به بینش‌های عملی تبدیل شود.نتایج قابل توجه بود: هوش مصنوعی نقاط دردناک دائمی - از پیکربندی‌های نادرست و مسائل مربوط به مقیاس‌بندی گرفته تا حتی مدیریت ضعیف تغییرات - را کشف و به شرکت کمک کرد تا با هدر دادن کمتر سرمایه‌های زمانی و پولی راهی برای جلوگیری از تکرار حوادث مشابه در آینده بیابد. اگرچه زالاندو تأکید می‌کند که هوش مصنوعی جایگزین قضاوت‌ها و تصمیم‌گیری‌های انسانی نشده و به عنوان یک انسان امیدوارم که آنها حقیقت را بگویند، اما وقتی به تصویر کلی نگاه می‌کنیم این مدل‌های هوشمند، [دستکم در تشخیص الگوی خرابی] به اندازه بسیار زیادی به مشاوران فنی و مهندسان کمک کرده‌اند. این مربوط به بررسی‌ها در مقیاس بزرگ و در عین حال ارزیابی دقت، عملکرد، قابلیت اطمینان، قابلیت نگهداری و نظایر آنهاست.من هرگز توسط زالاندو استخدام نشده‌ام و هیچکس هم برای تبلیغ کردن آنها به من پول نمی‌دهد. اما فقط نمونه‌ای از نسل بعدی پدیده چابکی را در گزارشی از یک وبلاگ فناوری دیدم و تصمیم گرفتم آن را با دوستان و همراهانم به اشتراک بگذارم. برای خرید لباس و کفش ورزشی، هنوز هم شخصا شرکت‌های کوچک و متوسط ​​محلی را ترجیح می‌دهم، زیرا آنها هنوز انسان‌گراتر هستند!اما همانطور که قبلاً میلیون‌ها بار بحث کردیم و گفتیم:چابکی (اون چیزه!) یعنی پیدا کردن کاری که باید انجام شود!https://engineering.zalando.com/posts/2025/09/dead-ends-or-data-goldmines-ai-powered-postmortem-analysis.html امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Sat, 11 Oct 2025 14:24:14 +0330 https://virgool.io/@omid_mojabi/%D8%A8%D8%A7-%DA%AF%D8%B1%DA%AF-%D9%87%D8%A7-%D9%86%D8%B1%D9%82%D8%B5%DB%8C%D8%AF-%D8%A8%D9%87-%D8%A2%D9%86%D9%87%D8%A7-%D8%BA%D8%B1%D8%B4-%DA%A9%D9%86%DB%8C%D8%AF-hu0t4qh5gcbu خلاصه مطلب: این نوشته تلاشی است در نقد روش و شیوه‌ای که برای تعیین حقوق و دستمزد به کار گرفته و این روزها خیلی هم پروموت می‌شود در گوشه و اطراف مارکت. من فکر می‌کنم وقت آن رسیده که به جای پذیرش "همینه که هست!" در جواب بگیم "اینجور باید باشه!". اما چجور؟ ادامه مطلب را بخوانید.چندی پیش یکی از منتی‌هام پرسشی راجع به حقوق و دستمزد مکفی برای استخدام اسکرام‌مسترها پرسید و من با اینکه بیش از یک و نیم سال بود از شرکت‌های ایرانی حقوق نگرفته بودم به عنوان یک شاغل تمام وقت گفتم باید تقریبا معادل با هزار دلار باشه در ماه. ایشون اما این مبلغ رو زیاد میدونست اشاره کرد به بنچ مارک‌هایی که سالانه انجام میشه در مارکت و یکی دو تا نام هم مطرح شد که به نظرم ضرورت نداره من اینجا تکرارشون کنم. اما من چجوری به این عدد رسیده بودم؟شیوه کار به نظر خیلی ساده است چون دنبال یه کار آکادمیک خیلی دقیقی نبودم؛ کیفیت زندگی‌ام در دهه گذشته معلوم بود (متوسط گاهی رو به بالا و گاهی رو به پایین)؛ میزان حقوق دریافتی هر ماه هم معلوم بود و در گزارش بیمه تامین اجتماعی‌تون میتونید ببینید مشابهش رو و قیمت دلار هم در همان زمان در دسترس بود هم در حافظه ما و هم روی اینترنت. نهایتا این شکلی شد نمودارش:نمودار میزان تغییرات حقوق دریافتی من طی یک دهه به دلاراما نمودار چی داره نشون میده؟ اول همه داره نشون میده که طی دهه گذشته هر زمان که از حاشیه امن خودم و محیط کار اومدم بیرون و چالش بزرگ‌تری رو برداشتم دریافتی‌ام متناسب با شهامتی که به خرج دادم یه پرشی داشته. دومی که بیشتر مربوطه به قصد نگارش این مطلب اینه که با همه بالا و پایین‌ها و فراز و نشیب‌های این دهه پر تنش و فرسوده کننده در زندگی همه ماها (بوس به کله همه دهی شصتی‌ها!)، متوسط حقوق دریافتی من حدود 850 دلار در ماه بوده است. تازه دیتای من تمیز نیست و خیلی پارامترها را در خودش نداره. برای مثال اوایل شروع کارمندی‌ام، من یک سالی هم سربازی رفتم (چون خیلی سرباز زیاد بود من انگار نخبه محسوب میشدم یه هشت ماهی هم کسر خدمت شامل حالم شد! آمین!) که حقوق اش اندازه کرایه اتوبوسم بود فقط و یا اینکه این اواخر از سپتامبر 2022 به مدت پانزده ماه به صورت ریموت و از خارج از کشور با آخرین شرکت ایرانی تمام‌وقت کار کردم و امکان داوطلب شدن برای چالش‌های زیادی در مارکت ایران رو نداشتم چون عملا اون رو ترک کرده بودم.اما طی این دهه من چجوری زندگی کردم؟ خونه ما در فردیس کرج بود؛ خانواده من فرهنگی بودن و با حقوق معلمی همانطور که خیلی‌ها شاید بدونند نمیشه زندگی بالاتر از متوسط داشت. من در همین دهه برای کار مهاجرت کردم به تهران چون پول اونجا پیدا میشد چراییش بماند؛ با این حال نزدیک به یک سال مسافر هر روزه اتوبان شلوغ تهران ـ کرج بودم. توی همین دهه من ازدواج کردم، بچه‌دار شدم و توی دست کم سه تا شرکت با اسم و رسم خوب ایرانی کار کردم که البته برای خودم جالبه که جز آخری که دیگه من به عنوان یک فرد سینیور توش بودم اون دو تای دیگه جز استثمار و خوردن حق و حقوق‌ام و زنده نگه داشتنم به صورت بخور و نمیر چندان گشایش زیادی در وضع مالی من نداشتن و من دو تا از بیشترین حقوق‌های نزدیک به هزار دلاری مسیر شغلی‌ام رو از شرکت‌های کوچیکی این وسطا گرفته بودم که جسورانه می‌خواستند در مارکت رشد کنند و من هم همراه‌شون رشد کردم.توی همین دهه خانواده من (خودم و همسرم و بعدش هم دخترم به ما اضافه شد) در مرکز شهر تهران زندگی می‌کرد و چندماه یک بار امکان مسافرت به خارج از تهران داشت. دو سه بار هم رفتیم ترکیه برای گذراندن تعطیلات. ما اهل معاشرت با دوستان هم بودیم و ماهی یک بار میهمانی مختصری برگزار می‌کردیم و گاهی هم دعوت دوستان رو قبول می‌کردیم و میهمان آنها می‌شدیم. ماهی یه بار دوبار هم میرفتیم رستوران یا فست‌فود و تهران‌گردی، نه خیلی بالاها ولی در حد قابل قبول. با این حقوق و دستمزد ما قطعا هیچ شانسی برای خریدن خونه که نداشتیم اما با جسارتی که همسرم در اوایل ازدواج‌مون و قبل از به دنیا اومدن دخترم، به خرج داد و کل درآمد ماهانه‌اش رو گذاشت وسط روی میز و البته با کمک‌های خانواده‌اش تونستیم پراید زپرتی من رو به یک پژوی 206 تبدیل کنیم که رخش وفادار ما بود تا زمانی که از کشور برای ادامه تحصیل من خارج شدیم. امیدوارم این جزئیات بتونه کمک کنه که مخاطب نکته رو بگیره وقتی می‌گم «یک زندگی معمولی» در تهران به حدود هزار دلار در ماه درآمد نیاز داره منظور چه جور زندگی‌ای هست! یه وقت فکر لندکروز، پورشه، فرمانیه، الهیه و خیابون فرشته رو نداشته باشین. اونا یه لیگ دیگه‌اند که باید آدم بازی دیگه‌ای باشید که از پیشینه شبیه من بتونین برسین بهشون. من که نبودم و راستش چندان هم ناراحت نیستم! یعنی باهاش کنار اومدم و وقتم رو صرف استفاده بهتر از امکانات و توانمندی‌های خودم کردم.حالا اگر میخواهید برای خودتون این قضیه حقوق مناسب رو یه جورایی جدی دنبال کنید و مثل من حوصله گذشته‌نگری ندارید یا تازه وارد بازار کار شدین و هنوز دیتایی برای تحلیل خودتون ندارید توصیه من اینه به جای خوندن گزارشات سالانه دستمزد فلان و بهمان شرکت و غیره سعی کنید یه متریکی برای اندازه زدن وضعیت زندگی‌تون پیدا کنید. یه خوبش شاخص ساقه طلایی هست که از اینجا در دسترسه برای همه:https://arashzd.notion.site/The-Saghe-Talaie-Index-dd681d82b7da48c28e47ba5d5d660b43تعداد ساقه طلایی‌هایی که میشه خریددر واقع یه متریک جالب هست برای دنبال کردن همزمان تغییرات نرخ تورم و البته قدرت خرید جامعه به صورت متوسط که اندازه زدن و دنبال کردنش خیلی هم نیاز به دانش آکادمیک و بنچ مارک‌های عجیب و غریب نداره.من دوست ندارم ارزش کار دیگران رو زیر سئوال ببرم و بگم فلان گزارش دستمزد سالانه که خیلی هم پرطمطراق منتشر شده طی چند سال هیچ ارزشی نداره. معتقدم در جای خودش خیلی هم ارزشمنده چون یه زحمتی براش کشیده شده که بفهمیم استاتوس مارکت چی هست. آن چیزی که اینجا مهمه اینه که چه استفاده‌ای میخواهیم از دیتایی که میده به ما این تیپ گزارشات داشته باشیم؟ استفاده از اونا برای تعیین حقوق دریافتی ابدا درست نیست! مثل سپردن گله گوسفندها به گرگ‌ها یا گوشت به گربه است. استفاده شرکت‌ها از این تحلیل این داده‌ها برای تعیین اشل حقوقی در واقع به صورت مودبانه تلاشی برای فریب ماهاست! وگرنه اگر در بین مدیران یا استکهولدرهای همون شرکت‌ها اگر کسی رو یافتید که زیر هزار دلار در ماه دستمزدش باشه بیایید هر چی دلتون خواست بگید به من!لازم به ذکر هم هست وقتی من بال بال میزدم مثل یه گنجشک حوالی هزار دلار در ماه دوستانی داشتم توانمندتر و با سابقه و اسکیل‌های بیشتر که عقاب شده بودند و توی لیگ دو یا سه هزار دلار در ماه پرواز می‌کردن. این تازه شامل اونایی هست که نون بازو و حاصل زحمتای خودشون رو خورده بودند. اون دسته از ما بهتران رو وارد بحث‌اش نمیشم اصلا.من اگر امروز در بازار کار آی تی در ایران یک فرد میدلول بودم (چه خوب که موهام سفید شده و دیگه نیستم!) و در میانه‌های دوره طلایی شغلی‌ام داشتم دوباره از حاشیه امن خودم می‌اومدم بیرون، ترجیح میدادم روی هزار دلار در ماه دریافتی (خالص بعد از کسورات یا ناخالص قبل از اون) چانه‌زنی کنم با شرکت‌ها؛ چون اول اینکه دلم لک زده برم پاسارگاد، تخت جمشید یا چغازنبیل رو ببینم در سفرهای بعدی، دوم فکر برنامه‌هایی هستم که به دخترم کمک کنه راه آینده‌شو پیدا کنه و سوم اینکه دلم میخواد بتونم برای پدر و مادرهامون که الان پا به سن گذاشتن کارهای بیشتری انجام بدم، چهار و پنج هم داره که زیاده و عرضی نیست و البته اینا چیزهای مهمتری هستن موقع ارزیابی حقوق درخواستی تا اون گزارشات یاد شده باد شده!زندگی در خارج از ایران این را هم به درستی به من نشون داده که ما کارکنان دانشی هر زمان که به خودمون میاییم در جنگلی که در آن به سر می‌بریم مثل یک شیر قوی و سلطان جنگل هستیم؛ پس بهتره با گرگ‌ها نرقصیم (اسم یه فیلمه و هرگونه تشابهی با موضوع دیگر تکذیبه!)؛ وقتش شده که به آنها غرش کنیم! امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Tue, 03 Jun 2025 15:41:17 +0330 https://virgool.io/@omid_mojabi/agile-in-the-age-of-ai-yehzya4qhh96 پیشتر درباره چشم انداز جهان ما در آغاز عصر هوش مصنوعی مطلبی را به فارسی برگردان کرده بودم. در این نوشتار دیدگاه تازه‌ای از Henrik Kniberg را برای مخاطبان انتخاب کرده‌ام. لازم به ذکر است همکار دیجیتال با حوصله‌ام (Chat GPT) مقاله را به فارسی کد زده و من بیشتر ریویو و دیباگ کرده‌ام!اسکرام بیش از ۳۰ سال و اصول اجایل بیش از ۲۰ سال دارند و ما در حال ورود به عصر هوش مصنوعی هستیم، دنیای جدید و عجیبی که هوش به عنوان یک خدمت در دسترس است. چگونه هوش مصنوعی بر اجایل و روش‌ها و چارچوب‌های مشهوری مانند اسکرام تأثیر می‌گذارد؟بیشتر اصول و روش‌های اجایل بر پایه فرضیاتی درباره رفتار انسان‌ها و بهره‌وری تیم‌ها هستند. برخی از این فرضیات هنوز هم صحیح هستند، اما برخی دیگر نیازمند به چالش کشیده شدن و ارزیابی مجدد دارند، که قطعا بر روی روش‌ها تأثیر خواهند گذاشت.این نوشتار ترکیبی از مشاهدات و پیش‌بینی است که شامل آنچه که من تاکنون دیده‌ام و برخی از حدس و گمان‌هایی درباره آنچه که فکر می‌کنم در آینده نزدیک اتفاق می‌افتد؛ می‌شود.به عنوان یک خواننده، نکته برداشتنی اصلی این است: برای تغییر آماده باشید! من دقیقاً نمی‌دانم چه چیزهایی و چگونه تغییر می‌کنند (این مقاله فقط برخی از حدس‌های من است)، اما اطمینان زیادی دارم که اجایل در دوران هوش مصنوعی با دوره قبل از آن تفاوت خواهد داشت. بنابراین یک گام به عقب بردارید، با دقت به نحوه کار کردن خود نگاه کنید و همه چیز را به پرسش بکشید.تیم‌های فراوظیفه‌ایتوسعه به صورت چابک معمولاً توسط تیم‌های کوچک، خودسازمانده و فراوظیفه‌ای (Cross Functional) انجام می‌شود. فراوظیفه‌ای بودن به این معنی است که اعضای تیم دارای مهارت‌های مختلفی هستند که یکدیگر را تکمیل می‌کنند. تصویر زیر فراوظیفه بودن را با استفاده از دایره‌ها برای نمایش مشترکات دانش و مهارت‌های هر عضو تیم نشان می‌دهد.تیم‌های فراوظیفه‌ای و گستره دانش اعضای آنهااما چرا در واقع به تیم‌های فراوظیفه‌ای نیاز داریم؟پیش فرض پایه‌ای در اینجا این است که تیم‌ها نیاز به ترکیبی از مهارت‌های تکمیلی دارند و در صورت نداشتن تمام توانمندی‌های مورد نیاز، نمی‌توانند هر آنچه که باید بسازند را به انجام برسانند. یک تیم فراوظیفه‌ای تمام مهارت‌هایی را که برای ساخت یک محصول قابل حمل و افزودن به آن به طور خودمختار نیاز هست با حداقل وابستگی به تیم‌های دیگر را داراست. تداخل مهارت‌های تکمیلی ضروری برای این کار است.اما با Generative AI، هر شخص به طور موثر دارای یک همکار هوش مصنوعی است که بسیار سریع هر زبان برنامه‌نویسی، چارچوب کاری مشهور، و یا هر الگوی طراحی را می‌شناسد و دارای دانشی بسیار قوی در مقایسه با همکار دیگرش هست. با استفاده از همان متافور تصویری قبلی، اضافه کردن یک عضو تیم هوش مصنوعی به معنای اضافه کردن یک دایره دانش است که به طور قابل توجهی بزرگتر از هر یک از دایره‌های انسانی است (اگرچه هنوز برخی از دانش انسانی را مدل هوش مصنوعی ندارد).گستره دانش همکار هوش مصنوعی در مقایسه با همکاران انسانیمدل‌های هوش مصنوعی هنوز کامل نیستند، آن‌ها به نیاز به نظارت انسانی نیاز دارند، اما یک یا دو نفر با مهارت‌های مهندسی قوی و دسترسی به یک مدل هوش مصنوعی قوی می‌توانند بهتر از یک تیم فراوظیفه‌ای چابک ـ هم از نظر سرعت و هم از منظر کیفیت ـ عمل کنند. من خودم این را به طور منظم تجربه می‌کنم. با یک همکار هوش مصنوعی می‌توانم در چند ساعت کارهایی را انجام دهم که بدون او انجامش روزها زمان می‌برد، و در طی چند روز کارهایی را انجام بدهم که در حالت عادی هفته‌ها زمان می‌برد تا به انجام برسد.بنابراین با اینکه تیم‌های فراوظیفه‌ای عالی هستند، اما به اندازه‌ گذشته دارای اهمیت نیستند، زیرا دیگر بدنه و گستره دانش واقعاً مانع اصلی برای موفقیت نیست. یک تیم ۱-۲ نفره به همراه یک همکار هوش مصنوعی دسترسی به بیشینه دانشی که تیم نیازمند آن است را داراست.اما چرا ۲ نفر؟ و نه فقط یک نفر؟ چون به نظر خوب است که بتوانید با یک انسان دیگر معاشرت کنید، و مواردی مانند تعطیلات و مرخصی‌ها را آسان‌تر مدیریت کنید!!بنابراین واقعاً چه اتفاقی می‌افتد وقتی که اندازه تیم به ۲ نفر کوچکتر می‌شود؟ آیا دیگر اعضای تیم را باید اخراج کرد؟ نه، من فکر می‌کنم که شرکت‌های هوشمند همه افراد را به وسیله هوش مصنوعی تقویت خواهند کرد، به جای اینکه چند نفر را تقویت کرده و سایرین را اخراج کنند. اخراج یک گروه از مردم به این دلیل خطر ایجاد فرهنگ ترس از نوآوری، آنها را به خطر می‌اندازد زیرا افراد تشویق نمی‌شوند که به این فناوری بیشتر بپردازند، زیرا بهبود کارایی منجر به اخراج بیشتر افراد می‌شود!بنابراین بگذارید بگوییم که اگر به عنوان مثال در ابتدا ۲ تیم کراس فانکشنال ۵ نفره داشتیم. اکنون ممکن است این ترکیب به ۵ تیم ۲ نفره به علاوه یک همکار هوش مصنوعی تقسیم شود.تغییر چیدمان تیم‌ها با اضافه کردن همکاران AIدر این حالت تیم‌های کوچک جدید باید بر چه کارهایی تمرکز کنند؟ این واقعا به شرایط بستگی دارد و یک مسأله لوکس به نظر می‌رسد: "ما اکنون ظرفیت توسعه را افزایش داده‌ایم، حالا چه کاری با آن انجام بدهیم؟!".بیایید بگوییم دو تیم بزرگ‌تر در حال کار روی یک محصول بودند و بر روی بخش‌های مختلف ویژگی تمرکز می‌کردند. اکنون ما 5 تیم کوچک‌تر داریم، که هرکدام موثرتر از یک تیم بزرگ قبلی عمل می‌کنند. می‌توانیم تمام 5 تیم جدید را بر روی همان محصول قبلی متمرکز نگه داریم. همانطور که پیش از این هم روی بخش‌های مختلف همان محصول کار می‌کردند. در نتیجه این کار بیشتری بر روی آن محصول می‌توان انجام داد. یا شاید بتوان 3 تیم را بر روی محصول فعلی نگه داشته و 2 تیم دیگر را به یک محصول جدید تخصیص بدهیم. به این ترتیب بهره‌وری کل شرکت را بیشتر می‌کنیم.تیم‌های کوچکتر = تیم‌های بیشتریکی از پیامدهای تیم‌های هوش مصنوعی این است که احتمالاً تیم‌های کوچکتر و تعداد بیشتر از آن‌ها خواهیم داشت. تیم‌های کوچکتر به این معناست که نیاز کمتری به جلسات و مناسک هماهنگی داخلی دارند. اگر کنار یکدیگر (فیزیکی یا دیجیتالی) بنشینند و هر زمانی نیاز دارند به طور غیررسمی صحبت کنند، آن‌ها تقریباً نیازی به هیچ جلسه رسمی داخلی (مثلا دیلی استنداپ یا دیلی اسکرام) در تیم ندارند چون می‌توانند هر زمانی به طور مستقیم با همدیگر صحبت کنند. با این حال، آن‌ها ممکن است به دلیل نیاز به معاشرت اجتماعی با همدیگر این کار را انجام دهند.اما از سوی دیگر، چون تیم‌های بیشتری نسبت به قبل داریم؛ نیاز به هماهنگی میان تیم‌ها افزایش می‌یابد. حداقل زمانی که این تیم‌ها بر روی یک محصول واحد کار می‌کنند و وابستگی‌هایی به همدیگر دارند. در واقع، اگر آن‌ها بر روی همان محصول کار می‌کنند، شاید هر تیم را بتوان به عنوان یک عضو تیمی در یک "تیم بزرگ‌تر" یا چیزی شبیه به آن دید و مناسکی مانند رترو و جلسات پلنینگ اسپرینت را در سطح تیمی از تیم‌ها انجام داد؟ایده تشکیل دادن تیمی شامل تیم‌های مسلح به AIبه هر حال، با اینکه اعتقاد دارم که اکثر شرکت‌ها در نهایت به یک نوع جلسه همگام‌سازی روزانه و یک نوع جلسه برنامه‌ریزی هر چند هفته یکبار می‌رسند؛ اما ساختار جلسات با روش‌های چابک فعلی متفاوت خواهد بود، به عنوان مثال احتمالاً جلسات ممکن است جلسات تیم‌های متقابل باشند به جای داخلی تیم، و جلسات برنامه‌ریزی احتمالاً بیشتر بر روی تصویر کلی تمرکز خواهند داشت تا موارد خاص لیستی از کارهای موجود در بک لاگ.شفاف‌سازی: من دقیقا نمی‌دانم به کدام نقطه مقصد خواهیم رسید. اما اطمینان زیادی دارم که چیزهایی تغییر خواهند کرد، زیرا فرضیات پایه‌ای بسیاری از روش‌های چابک فعلی با ظهور هوش مصنوعی واژگون خواهند شد.مهندسان نرم‌افزار (بیشتر) کد نمی‌نویسندیک روند واضح این است که مدل‌های هوش مصنوعی بی‌وقفه در حال بهتر شدن در کدنویسی هستند. درست است که هنوز کامل نیستند، اما همین الان هم به اندازه کافی خوب هستند که منطقی به نظر برسد که همکار هوش مصنوعی شما بیشترین بخش کد را بنویسد. این تغییری اساسی در نقش دولوپر هست. به عنوان یک مهندس نرم‌افزار، شما هنوز نیاز دارید تا مسئول باشید، درباره معماری فکر کنید، پرامپت‌ها را بنویسید، نتایج را بررسی کنید و مسئولیت کیفیت کد را بپذیرید. اما کدنویسی واقعی را می‌توانید در بیشتر اوقات به هوش مصنوعی که این کار را سریع‌تر و بهتر از شما انجام می‌دهد محول نمایید. این تا حدی امروزه درست است، و در عرض یک سال احتمالاً تا 90٪ اوقات صحیح خواهد بود. یک توسعه‌دهنده نرم‌افزار که اصرار دارد که همه کد را به صورت دستی در عصر هوش مصنوعی بنویسد، احتمالاً به عنوان یک مانع و منبعی برای تولید باگ‌ها تبدیل خواهد شد!اگر بخواهیم از ادبیات اسکرام استفاده کنیم، در واقع توسعه‌دهندگان نرم‌افزار به مالک محصول کوچک تبدیل می‌شوند و وظیفه اصلی آن‌ها این است که تصمیم بگیرند کدی که نیاز به نوشتن دارد چیست، نه نوشتن آن. این شبیه وضعیت فعلی است که کدهای سطح بالا را با استفاده از یک زبان برنامه‌نویسی مدرن می‌نویسید و کامپایلر آن را به زبان ماشین تبدیل می‌کند. اکنون داریم آن را یک سطح بالاتر بالا می‌بریم و مدل هوش مصنوعی کدهای سطح بالا را هم به جای ما می‌نویسد.حتی همکار هوش مصنوعی شما می‌تواند در پس‌زمینه کار کند. تصور کنید که این گفتگو بین باب، لیزا و همکار هوش مصنوعی آن‌ها، آقای فیکسیت، در طول قهوه صبحگاهی است:آقای فیکسیت: "صبح بخیر رفقا! چند گزارش باگ دیشب آمده بود. دو تای آن‌ها خیلی ساده بودند، بنابراین من آن‌ها را فیکس کردم و مرج ریکوئست فرستادم."لیزا: "چه عالی، من آن را سریعا بررسی می‌کنم. آیا چیز خطرناکی وجود دارد؟"آقای فیکسیت: "خب، من نیاز به تغییراتی در لاگین داشتم. تست‌های بیشتری اضافه کردم، بنابراین احتمالاً اوکی هست، اما آن قسمت ممکن است ریویوی بیشتری نیاز داشته باشد."لیزا: "اوکی، انجام می‌دهم".باب: "سلام آقای فیکسیت، آیا گفتگوی داخل اسلک درباره آسیب‌پذیری‌های امنیتی را دیدید؟"آقای فیکسیت: "آره، می‌خواهی من بررسی کنم؟ چند تا ایده دارم."باب: "لطفاً."آقای فیکسیت: "خوب، یک لحظه....... انجام شد! من سه مرج ریکوئست ارسال کردم، هرکدام یک رویکرد متفاوت برای حل آن‌ها دارد. برای جزئیات به توضیحات هر کدام مراجعه کنید. بررسی کنید و اگر می‌خواهید درباره‌ی هرکدام بحث کنیم، من را صدا بزنید."باب: "عالی!".این گفتگو امروز خیلی عجیب و غریب به نظر می‌رسد، اما به طور حتم در یک سال آینده فکر می‌کنم که رویه معمولی برای بسیاری از تیم‌ها خواهد بود.نتیجه: کدنویسی دیگر مانعی برای توسعه نرم‌افزار نیست. پس دیگر چه نیازی به مفاهیمی مانند اسپرینت‌ها (دوره‌های زمانبندی شده معمولاً ۲-۳ هفته‌ای) برای ایجاد تمرکز برای تیم در توسعه هست؟ اگر کاری که معمولاً یک هفته طول می‌کشد اکنون یک روز طول می‌کشد و کاری که معمولاً یک روز طول می‌کشد اکنون یک ساعت طول می‌کشد، آیا ما هنوز نیاز به اسپرینت‌ها داریم؟اسپرینت‌های یک روزه؟حدس من این است که اسپرینت‌ها به تدریج به شدت کوتاه‌تر خواهند شد و یا حتی به طور کامل ناپدید خواهند شد. شاید اسپرینت‌های یک روزه را همچنان بتوان داشت. با یک جلسه همگام‌سازی سریع با همکار انسانی و هوش مصنوعی در شروع روز، تصمیم بگیریم که امروز بر چه چیزی تمرکز کنیم، سپس کار را تمام و در پایان روز آن را ریلیز کرده، و قبل از خروج از محل کار یک ریویوی سریع هم انجام بدهیم. جلسات دیلی و پلنینگ اسپرینت در واقع به یک ایونت کوتاه تبدیل می‌شوند.با وجود چندین تیم که با هم کار می‌کنند، همچنان نیاز به یک جلسه همگام‌سازی در سطح بالاتر (شاید یک بار در هفته) وجود خواهد داشت، تا اطمینان حاصل شود که آن‌ها با هم هماهنگ هستند. این مورد بدون هوش مصنوعی هم صادق است، اما نیاز به آن هنگامی که به سمت تیم‌های کوچکتر به جای تیم‌های بزرگتر حرکت می‌کنیم، افزایش می‌یابد. همانطور که اشاره کردم، فکر می‌کنم هنوز نیاز انسانی به نوعی جلسه همگام‌سازی و برنامه‌ریزی چند هفته‌ای وجود دارد. اما هدف و ساختار آن جلسه هنگامی که به چرخه‌های کوتاه‌تر توسعه منتقل می‌شویم (و در آن دیگر نیازی به تجمیع کردن کارها برای چند هفته وجود ندارد) تغییر خواهد کرد.کارشناسان مشترک و یا چرخشی؟چه بر سر نیروهای مشترک بین تیم‌ها می‌آید؟ بگذارید بگویم که تیم‌های ما همچنان با پایگاه‌های داده و ثبات سر و کار دارند و نیازمند دانش متخصصان این موضوعات هستند. به طور سنتی، ما همیشه اطمینان حاصل می‌کردیم که هر تیم کراس فانکشنال حداقل یک نفر با مهارت‌های دیتابیس داشته باشد. در یک تیم 2 نفره که با هوش مصنوعی توانمند شده‌اند، انسان‌ها در برخی از مهارت‌ها کمبود خواهند داشت و وابستگی بیشتری به همکار هوش مصنوعی خود خواهند داشت. آیا این کافی خواهد بود؟ برای کارهای روتین، احتمالاً بله. اما گاهی برای تسک‌های پیشرفته‌تر، نیاز به یک متخصص انسانی وجود خواهد داشت، به عنوان مثال برای نوشتن کوئری در پایگاه داده و یا ارزیابی نتیجه آن و یا شاید برای ساخت ابزارهایی برای این کار. فرد متخصص انسانی همچنین می‌تواند کمک کند تا بتوان تعیین کرد که کدام مدل‌ها و ابزارهای هوش مصنوعی برای تسک جاری مناسب هستند و یا حتی مدل‌ها را با توجه به دانش تخصصی‌اش بهبود.حدس من این است که ما متخصص‌های گردشی و یا مشترک را خواهیم داشت. این رویکرد جدید نیست، برخی از تیم‌های چابک در حال حاضر هم همین کار را انجام می‌دهند. اما فکر می‌کنم که این موضوع رایج‌تر خواهد شد.نیروهای گردشی در تیمهای مسلح به AIبه عنوان مثال با 5 تیم بالا، بگذارید بگویم که همه آن‌ها از پایگاه‌های داده استفاده می‌کنند. شاید یک یا دو تیم واقعیتاً یک تخصص دیتابیس داشته باشند، زیرا آن‌ها تیم‌هایی هستند که بیشترین کار را با دیتابیس انجام می‌دهند. اما آن‌ افراد گاهی اوقات به تیم‌های دیگر هم کمک می‌کنند.نیروهای مشترک بین تیم‌های مسلح به AIیک جایگزین این است که نیروهای مشترکی را داشته باشیم که به هیچ تیم خاصی تعلق ندارند، و به صورت دوره‌ای به تیمی که در آن لحظه بیشترین نیاز به آن‌ها را دارد می‌روند. برای روشن شدن این موضوع، مدل‌های هوش مصنوعی باید بیشترین دانش تخصصی مورد نیاز را داشته باشند، اما متخصص انسانی به عنوان تکمیل کننده وقتی که به محدودیت‌های هوش مصنوعی برخورد می‌کنیم یا نیاز به یک جفت چشم اضافی انسانی برای ارزیابی نتیجه داریم، وجود دارد.نقش اسکرام مستر یا اجایل کوچاگر نقشی مانند اسکرام مستر یا مربی چابک یا مشابه آن را دارید، در این صورت به طور معمول وظایف وی شامل آموزش و راهنمایی تیم در مواردی مانند چگونگی به طور موثر تقسیم یک داستان کاربری، چگونگی اجرای موثر یک جلسه رترو و چگونگی کار کردن موثر به عنوان یک تیم می‌شود.یک تیم به علاوه همکار هوش مصنوعی اگر نیاز باشد همه این دانش‌ها و تخصص‌ها را از قبل دارد. بنابراین نقش شما بیشتر یک مربی و کمتر از جنس منتوری است. اگر تیم می‌خواهد بداند چگونه یک داستان را تقسیم کند، با آن‌ها بنشینید و یک پرسش را در Chat GPT (یا مدل دیگری) بنویسید. شما می‌دانید که آن ضرب‌المثل محبوب اینجا کاربرد دارد: "اگر میخواهی به آنها ماهی بده اما این فقط برای یک روز آنهاست. بهتر است به آنها ماهیگیری آموزش دهید، که برای یک عمر به کارشان می‌آید". اکنون که تیم‌ها خودشان ماهی را می‌گیرند، شما زمان بیشتری برای مربیگری و کمک به تیم‌های بیشتر دارید، و به آن‌ها کمک کنید تا بفهمند چگونه از آن ابزارهای ماهیگیری استفاده کنند.چرخه فیدبک کاربربازخورد کاربران همچنان یک بخش بحرانی از توسعه به صورت چابک است، حتی در دوران هوش مصنوعی هم این چالش پابرجاست. با این حال، جزئیات مربوطه تغییر می‌کند. ما قادر خواهیم بود که نسخه‌های بیشتری از محصول را ریلیز کنیم؛ بنابراین مشتریان و کاربران نهایی باید آماده باشند که به جای بروزرسانی‌های بزرگ بیشتر تغییرات کوچک را دریافت کنند. در نتیجه، آنها می‌توانند در توسعه محصول نقش فعال‌تری داشته باشند. برخی از آن‌ها این وضعیت را تحسین می‌کنند، برخی هم ممکن است مخالف آن باشند.اگر کاربران به اندازه لازم در دسترس نباشد، ما می‌توانیم با درخواست از یک مدل هوش مصنوعی برای بازیگری نقش یک نوع خاص کاربر، کاربران ماک شده ایجاد کنیم. ما می‌توانیم با استفاده از این روش user research ماک انجام دهیم، و احتمالاً بزودی قادر خواهیم بود که از کاربر ماک بخواهیم که سیستم ما را مستقیماً استفاده کنند و به ما بازخورد بدهند. فیدبک کاربر ماک ممکن است به اندازه بازخورد واقعی از کاربران واقعی مفید نباشد، اما از طرف دیگر ما می‌توانیم بازخورد را سریع‌تر و بیشتر و یافته شده از زاویه دید بیشتری دریافت کنیم، بنابراین ممکن است یک مکمل خوب باشد. این می‌تواند به تیم کمک کند مشکلات طراحی مهم‌تر را بیشتر کشف کند.نکات تکمیلیفقط به عنوان یک سرگرمی، من تمام مقاله فوق را به Claude Opus (آخرین مدل ژن‌هوش از آنتروپیک) دادم و از او خواستم که نکات اضافی را که باید اضافه شود، پیشنهاد دهد. در ادامه پاسخ بدون ویرایش او را مشاهده می‌کنید که فکر می‌کنم بسیار خوب بود:تأثیر بر backlog محصول و اولویت‌بندی: با تیم‌های مجهز به هوش مصنوعی که سریع‌تر تحویل می‌دهند، لیست backlog محصول ممکن است نیاز به به‌روزرسانی‌های بیشتری داشته باشد. نقش مالک محصول ممکن است برای تمرکز بیشتر بر روی اولویت‌بندی استراتژیک و مدیریت سهامداران تکامل یابد.تغییرات در ارزیابی و برنامه‌ریزی: تکنیک‌های ارزیابی پیشین، مانند استوری پوینت و یا روزهای ایده‌آل، ممکن است کم اهمیت بشوند زیرا هوش مصنوعی می‌تواند سرعت توسعه را به طور چشمگیری شتاب ببخشد. تیم‌ها ممکن است نیاز به انتخاب روش‌های جدید برنامه‌ریزی و پیش‌بینی داشته باشند.تطبیقات در چارچوب‌های چابک: چارچوب‌های محبوب چابک مانند اسکرام، کانبان یا SAFe ممکن است نیاز به تطبیق داشته باشند تا تغییراتی که هوش مصنوعی به همراه می‌آورد را پذیرفته و در خود بگنجاند. به عنوان مثال، مدت و فراوانی رویدادهایی مانند برنامه‌ریزی اسپرینت، دیلی اسکرام و ریویو و رتروی اسپرینت ممکن است نیاز به تنظیم مجدد داشته باشند.تأثیر بر دینامیک و همکاری تیم: در حالی که هوش مصنوعی می‌تواند به بهره‌وری کمک کند، ضروری است تأثیر آن بر دینامیسم و همکاری تیم را در نظر بگیریم. تیم‌ها ممکن است نیاز به یافتن راه‌های جدید برای تقویت ارتباط انسانی، خلاقیت و نوآوری در یک محیط مبتنی بر هوش مصنوعی داشته باشند.یادگیری مداوم و توسعه مهارت: هنگامی که هوش مصنوعی وظایف خاصی را برعهده می‌گیرد، اعضای تیم ممکن است نیاز به تمرکز بر توسعه مهارت‌های جدید، مانند مهندسی کوئری، انتخاب مدل هوش مصنوعی و ارزیابی نتایج داشته باشند. یادگیری مداوم و به‌روزسانی مهارت‌ها در دوران هوش مصنوعی اهمیت بیشتری پیدا می‌کند.ملاحظات اخلاقی و شفافیت: تیم‌ها باید در مورد ملاحظات اخلاقی مربوط به هوش مصنوعی، مانند بایاس‌ها، عدالت و شفافیت، بیشتر وارد عمل بشوند. شیوه‌های چابک ممکن است نیاز به تکامل داشته باشند تا توسعه و پیاده‌سازی مسئولانه هوش مصنوعی را تضمین کنند.بازنگری مجدد (Recalibrate)(خب، این من، انسان، دوباره نوشته‌ام)دوست من کنت بک این پست را توییت کرد:"تا به حال از امتحان کردن Chat GPT می‌ترسیدم. امروز (18 آوریل 2023) از آن تردید دست کشیدم. حالا می‌فهمم چرا می‌ترسیدم. ارزش 90٪ مهارت‌هایم به صفر رسیده است. امکانات برای 10٪ باقیمانده 1000 برابر شده است. باید بازنگری کنم."فکر می‌کنم کنت جوهر مسئله‌ی ما را درک کرده است، در تمام نقش‌ها و حرفه‌ها. ما باید بازنگری کنیم که وقت خودمان را چگونه صرف می‌کنیم. به چه معنی دولوپر، اسکرام مستر، مالک محصول، چپترلید و غیره هستیم؟همینطور با اجایل: ما باید روش‌های اجایل خودمان را بازنگری کنیم. این با خوداندیشی شروع می‌شود. وقت‌مان را برای چه چیزهایی صرف می‌کنیم؟ مناسک، نقش‌ها، و آرتیفکت‌هایمان چیست؟ چه چیزهایی باید مورد چالش، تغییر یا ارزیابی مجدد قرار بگیرد وقتی که وارد عصر هوش مصنوعی می‌شویم؟ نظرات خود را با ما به اشتراک بگذارید!مقاله اصلی: https://hups.com/blog/agile-in-the-age-of-ai امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Fri, 12 Apr 2024 17:12:09 +0330 https://virgool.io/@omid_mojabi/%D8%B3%D9%87-%D9%BE%D8%AF%DB%8C%D8%AF%D9%87-%D9%85%D8%AE%D8%B1%D8%A8-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%B1%D9%87%D8%A8%D8%B1%DB%8C-%DB%8C%DA%A9-%D8%AA%DB%8C%D9%85-regov0wlbalz شاید عبارت اصلی باید این باشد «سه پدیده گروهی که موفقیت شما به عنوان یک رهبر را خراب می‌کنند» که از اصل ترجمه عنوان مقاله اصلی آمده است یا این یکی که دلیل اصلی بازنشر این مطلب هست: «سه پدیده گروهی که موفقیت شما به عنوان یک رهبر را خراب می‌کنند یا چگونه با کمک ChatGPT با سرعت نور از خورشید طی ۸ دقیقه به زمین برسیم! یعنی مقاله‌ای با کمتر از ۱۵۰۰ کلمه به زبانی که اساسا آشنا نیستیم را به فارسی ترجمه کنیم!»سه پدیده مخرب در پیش پای رهبران سازمانی: رفتار گله‌ا؛: اثر هاله‌ای و پندار آرزومندانه و تکنیک‌هایی برای غلبه بر آنهاابتدا بیایید ترجمه مطلب اصلی به قلم سایمون فلوسمان که در scrum.org منتشر شده‌است را با ویرایش‌های جزئی من، بعد از برگردان به فارسی توسط ChatGPT جان، مروری داشته باشیم:چه ویژگی‌های به تشخیص رهبران موفق کمک می‌کند؟اخیراً از تیم کوک پرسیده شد چه چیزی سبب موفقیت سبک رهبری او شده است. او که به ندرت تن به مصاحبه می‌دهد چنین پاسخ داده‌است:«من لیدری هستم که به همکاری اعتقاد دارد. تنها ترکیب ایده‌های ما یک ایده عالی ایجاد می‌کند. یک ایده غنی شده و قوی که هیچ کدام از ما به تنهایی امکان دستیابی به آن را نداشت. اگر بتوانیم ایده‌ها را در مباحث بین گروه‌ها ایجاد کنیم، به چیزخایی بزرگتر از اندازه توانائی‌مان دست خواهیم یافت و شگفت‌آور است که ما با آن‌ها چه چیزهایی می‌توانیم خلق کنیم، جدا از اینکه که ایده مربوط به تولید یک محصول و یا بازاریابی آن باشد. بنابراین، سبک رهبری من این است که همه به این شیوه همکاری کنند.»بی‌شک تیم کوک یکی از موفق‌ترین رهبران عصر ما است. از زمانی که در سال ۲۰۱۱ رهبری اپل را برعهده گرفته است، ارزش اپل ۹۰ درصد افزایش یافته است (در سال ۲۰۲۳ برای نخستین بار اپل با اختلاف کمی سهم بزرگتری از بازار دستگاه‌های تلفن همراه را نسبت به رقیب دیرینه‌اش سامسونگ به دست آورد ـ مترجم). در حال حاضر اپل مقدار ۳ تریلیون دلار ارزش دارد و این برابر با اندازه اقتصاد کشور فرانسه است.برای تیم کوک رهبری به معنای ایجاد ۳ از مجموع ۱ و ۱، است! اگر شما همانند وی به دنبال امکان فراهم کردن همکاری برای تولید ایده‌های جدید هستید، باید به سه پدیده توجه کنید. این پدیده‌ها در ایده‌پردازی‌ها و بارش‌افکارهای گروهی رخ می‌دهند و جلوی تولید ایده‌های عالی را می‌گیرند.بیایید این پدیده‌ها را یکی پس از دیگری بررسی کنیم:پدیده ۱: رفتار گله‌ایآیا شما عصبانی می‌شوید هنگامی که اعضای تیم شما در گفتگو شرکت نمی‌کنند؟در سال ۱۹۸۵، روان‌شناسان گرولد استاسر از دانشگاه میامی و ویلیام تایتوس از دانشکده برایر کلیف یک آزمایش انجام دادند. دو گروه هرکدام شامل چهار نفر بودند و باید تصمیم بگیرند که کدامیک از سه نامزد برای سمت ریاست هیأت دانشجویی مناسب‌تر است. محققان پرونده‌ها را تهیه کردند که شامل ویژگی‌های مثبت و منفی هر نامزد بود. بر اساس این پرونده‌ها، نامزد A بهترین گزینه برای این سمت بود.در گروه اول، همه اعضا پیش از زمان، پرونده‌ها را مطالعه کردند، ترجیح شخصی خود را اعلام کردند و سپس به عنوان یک گروه برای نامزد A رای دادند.در گروه دوم، پرونده‌ها برای اعضا کامل نبودند. آنها برخی اطلاعات مشترک در مورد هر نامزد داشتند، اما اطلاعات باقیمانده از پرونده‌ها در پرونده‌های مختلف پخش شده بودند. به دلیل توزیع اطلاعات مثبت و منفی در پرونده‌ها، بیشتر اعضا پیش از رأی‌گیری به نامزد A اولویت ندادند. گرچه اعضای این گروه در زمان رأی‌گیری می‌دانستند که پرونده‌هایشان تمام اطلاعات را ندارند، اما به سرعت در گفتگوی گروهی یک توافق شکل گرفت.و سپس یک چیز غیرمنتظره اتفاق افتاد:با اینکه اعضای گروه می‌دیدند که یک توافق در حال شکل گیری است، به طور فزاینده‌ای کمتر احتمال داشت با وجود داشتن اطلاعات منفی درباره نامزد مورد توافق (یا مثبت درباره نامزدان غیرمورد توجه) افراد شهامت به خرج داده و آن اطلاعات را با جمع به اشتراک بگذارند. برخلاف گروه‌های کاملاً آگاه که در آن‌ها کاندیدای مناسب (نامزد A) انتخاب شد، این گروه‌ها تقریباً همیشه به یکی از نامزدهای دیگر رأی می‌دادند.به عبارت دیگر اگرچه گروه دسترسی به همه اطلاعات را داشت تا بررسی کند که نامزد A بهترین است، اعضای گروه این اطلاعات را ارائه ندادند و معمولا نامزدی را انتخاب می‌کردند که مطلوب نبود.اگر شما از این ناراحت هستید که اعضای تیم شما در گفتگو شرکت نمی‌کنند، باید از خودتان بپرسید که گفتگو چه قدر از یک توافق دور است. آیا از قبل یک همگرایی در آرا وجود دارد؟ اگر چنین است، احتمالاً اعضای تیم توان مخالفت با موضوع توافق شده با وجود دسترسی به اطلاعات دقیق‌تر را ندارند.مسائل در واقع این است:زمانی که می‌خواهد یکی از ۱ و ۱ مجموع ۳ بسازیم گروه باید دیدگاه‌های مختلف را بشنود. چرا که در مواجهه با دیدگاه‌های متفاوت یا مخالفت‌آمیز، پتانسیل تولد یک ایده نوآورانه وجود دارد. بهتر است این مشکل را با این روش حل کرد که به هر عضو تیم فرصت داد تا ایده‌اش را به صورت مستقل بیان کند.یک تکنیک که در اینجا موثر بوده است، تکنیک ۱-۲-۴-همه (از مجموعه تکنیک‌های Liberating Structure ـ مترجم) است ( برای اطلاعات بیشتر اینجا را ببینید).پدیده ۲: اثر هاله‌ای (یا هاله نور! ـ مترجم)چه اتفاقی می‌افتد اگر ماری کوری بخشی از تیم باشد؟آیا ایده‌های او باید توجه بیشتری جلب کنند؟ بله، ممکن است مواقعی پیش بیاید که نظر ماری باید وزن بیشتری داشته باشد تا نظر دیگران، به خصوص زمانی که گروه در مورد شیمی صحبت می‌کنند. اما در سایر موارد، بهتر است اگر افرادی که ایده ارائه می‌دهند، ناشناس بمانند.برای افراد سخت است در جلسات عمومی به افرادی که دارای دانش تخصصی بیشتر یا اختیار بیشتری هستند، اعتراض کنند، جدا از اینکه آیا این افراد ماری باشند یا مدیر دپارتمان آنها.این پدیده به نام اثر هاله‌ای (Halo effect) شناخته می‌شود و نخستین بار در یک آزمایش توسط روان‌شناس استنلی میلگرام در سال ۱۹۶۱ نشان داده شده است. در این آزمایش، شرکت‌کنندگان موظف به زدن شوک‌های الکتریکی با نیروی بیشتر به یک فرد دیگر که پشت یک پنجره شیشه‌ای نشسته بود، می‌شدند. این شوک‌ها از ۱۵ ولت شروع شد و به تدریج به ۳۰ ولت، ۴۵ ولت و ... تا حدود ۴۵۰ ولت تشدید می‌شد. حتی زمانی که فرد شکنجه‌شده از درد فریاد می‌زد و لرزش داشت (البته شکنجه‌ای با جریان برق در کار نبود نبود، بلکه فرد مربوطه یک بازیگر حرفه‌ای بود!) و شرکت‌کننده می‌خواست آزمایش را متوقف کند، استنلی میلگرام با آرامش می‌گفت: "ادامه دهید، آزمایش این را می‌خواهد." و بیشترین تعداد از شرکت‌کنندگان ادامه دادند. بیش از نیمی از شرکت‌کنندگان به بالاترین جریان الکتریکی رسیدند!چرا این اتفاق افتاد؟به دلیل اطاعت محض از مرجع معتبرآزمایش نشان می‌دهد چگونه افراد تمایل دارند از افرادی که در موضوعی خاص مرجع هستند، پیروی کنند یا به نظرات افراد به عنوان متخصصان بیشتر وزن دهند. آنها به این باور می‌رسند که باید به ایده فرد مرجع و متخصص وفادار بود، حتی اگر این باور با قضاوت شخصی یا اعتقادات اخلاقی آنها در تضاد باشد.آیا می‌خواهید از اثر هاله‌ای جلوگیری کنید؟در این صورت نه تنها باید به هر عضو تیم فرصت داده شود تا ایده‌اش را مستقل بیان کند، بلکه این باید به صورت ناشناس انجام شود. این کار باعث جلوگیری از این می‌شود که برخی از ایده‌ها به دلیل اینکه از متخصص فرضی در تیم نیستند، در ابتدای راه رد شوند. برون‌سپاری ۲۵/۱۰ (از مجموعه تکنیک‌های Liberating Structure ـ مترجم) یک تکنیک خوب برای اجرای گروه‌اندیشی است (برای اطلاعات بیشتر اینجا را ببینید ـ مترجم).علاوه بر دو مورد قبلی، پدیده دیگری هم وجود دارد که می‌تواند موفقیت رهبران را تخریب کند: پندار آرزومندانه یا آرزواندیشی!در سال ۱۹۹۴، در یک تحقیق از ۳۷ دانشجوی روان‌شناسی خواسته شد تا تخمین بزنند چقدر زمان برای تکمیل پایان‌نامه‌های خود نیاز دارند. آنها تخمین زدند که در میانگین ۲۷٫۴ روز زمان لازم است "اگر همه چیز به بهترین شکل ممکن پیش برود" و ۴۸٫۶ روز اگر "اگر همه چیز به بدترین شکل ممکن پیش برود".خودتان حدس بزنید چند روز واقعیاً به آنها نیاز بود؟در دنیای واقعی میانگین زمان انجام توسط آنها ۵۵٫۵ روز بود، و تنها ۳۰ درصد از دانشجویان کار خود را در زمان پیش‌بینی‌شده تکمیل کردند!راجر بیولر (روان‌شناس) این موضوع را گه پندار آرزومندانه نام دارد را به این صورت توضیح می‌دهد: «مردم باور دارند که وظایف به سرعت و آسانی انجام می‌شوند، چون آنها می‌خواهند که اینطور باشد!» ما در برنامه‌ریزی کارها فقط به سناریوی بهینه‌ترین حالت ممکن مراجعه می‌کنیم، به جای آنکه از تجارب مربوط به انجام وظایف مشابه استفاده کنیم. حالا که این اثر را می‌شناسید، حتماً مثال‌های بی‌شماری به ذهنتان می‌رسد که قبلاً آن را مشاهده کرده‌اید. یکی از مشهورترین‌‌ها احتمالاً ساخت فرودگاه برلین است. بعد از ۱۵ سال برنامه‌ریزی، ساخت فرودگاه در سال ۲۰۰۶ شروع و باید در سال ۲۰۱۱ تمام می‌شد. اما در واقع، تا سال ۲۰۲۰ به اتمام نرسید و به روی مردم باز نشد!چگونه می‌توانید اطمینان حاصل کنید که برنامه‌ریزی در تیم شما به یک فرودگاه برلین بعدی تبدیل نمی‌شود؟ما باید مرگ بیمار ـ در این موقعیت فرودگاه برلین ـ را بررسی کرده و علت مرگ را پیدا کنیم. در پزشکی این را به نام کالبدشکافی می‌شناسند. وقتی شرکت‌ها دنبال دلایل یک نتیجه ناامیدکننده پروژه هستند، آن را پست مورتم می‌نامیم. هدف از آن یادگیری از اشتباهات گذشته است. اما مشکل اینجاست:بیمار از پیش مرده است.بنابراین، روان‌شناس معروف گری کلین پیشنهاد می‌دهد که کالبدشکافی را پیش از اینکه بیمار از دست برود انجام دهیم. در این رویکرد فرض می‌کنیم بیمار مرده است و سپس به دنبال دلایل ممکن می‌گردیم. اجازه بدهید این تکنیک را پیش از مرگ بنامیم.استفاده از تکنیک‌های مشابهی برای جلوگیری از پدیده‌های منفی در گروه دارید؟اما حالا بیایید تجربه دیگری را با هم مرور کنیم. مقاله اصلی به زبان آلمانی بود؛ من با آلمانی آشنایی ندارم اما استفاده از Google Translate و ChatGPT را دارا بودم. ابتدا از AI پردازشگر زبان طبیعی محبوب‌مان خواستم که متن را به فارسی ترجمه کند؛ دو سه بار Hang over ریزی کرد ولی در طی ۸ دقیقه متن نسبتا ساده و روانی را به عنوان برگردان به فارسی در چت نوشت. بعد از ابزار translate موتورجستجوی محبوب‌مان خواستم که مجددا همان متن را ترجمه کند. جدا از اینکه اکانت من پرمیوم نبود و محدودیت ۵۰۰۰ حرف را باید به طریقی دور میزدم با یک واقعیت تازه مواجه شدم؛ گوگل جان با صرف زمان تقریبا مشابه (با در نظر گرفتن تاخیر ناشی از مجموعه عملیات چندین بار کپی کردن متن اصلی و مشاهده ترجمه فارسی) برای برخی لغات ترجمه بهتری پیشنهاد می‌کرد و برای برخی مشابه ابزار ChatGPT بود و در برخی دیگر ChatGPT بهتر بود. به عنوان مثال ترجمه جملات از ChatGPT بسیار روان‌‌تر از گوگل بود ولی ابزار translate معادل فارسی بهتری را برای برخی کلمات مهم متن بر می‌گزید.جدا از اینکه فارسی خیلی ساختار زبانی و ادبی دشواری برای محک زدن توانایی پردازش متن دو ابزار مورد آزمایش محسوب می‌شود و من هم آزمایش کنترل شده‌ای را برنامه‌ریزی نکرده بودم؛ اجازه بدهید بررسی آکادمیک موضوع را دست کن در این نوشته متوقف کرده و بیشتر روی نتیجه کار متمرکز باشیم. شما مقاله‌ای از یک مترجم آشنا به ادبیات فارسی و البته کانتکست موضوع ولی نا آشنا به زبان اصلی مقاله مطالعه کردید. چقدر برایتان مفید بود؟ چقدر خودتان انگیزه پیدا کرده‌اید برای تجربه کردن موردی مشابه؟به دنیای هوش مصنوعی خوش آمدید و البته که این تازه شروع ماجرا هست!موفق باشید! چابکی یافتن کاری است که باید انجام شود! امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Sun, 21 Jan 2024 10:27:14 +0330 https://virgool.io/@omid_mojabi/%D8%B3%D9%BE%D8%B1-%D8%A7%D9%86%D8%B3%D8%A7%D9%86%DB%8C-%D8%AF%D8%B1-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86-%D9%87%D8%A7-zjbsoheazfas فکر کنم لازم نیست تأکید کنیم که چقدر استفاده از افراد به عنوان سپر بلا روش بدی برای مدیریت آنها است، اما متأسفانه، این امر به یک اپیدمی در شرکت‌های در حال رشد تبدیل شده که هنوز به نقطه مارکت فیت خود نرسیده‌اند. اغلب مدیران، به خصوص از نوع مدیران میانی، از این رویکرد استفاده می‌کنند تا ناکارآمدی خود را در مدیریت امور پشت زیردستان‌شان پنهان کنند! چون همیشه باید کسی را به خاطر شکست ها سرزنش کرد! با این حال، دلیل اصلی چیست؟ ایده پشت این شیوه چیست؟ این پست می‌خواهد به یک حلقه حیاتی گمشده در زنجیره ذهنیت چابک داشتن در کار اشاره کند: گردن گرفتن یا همان اونرشیپ!فقدان مسئولیت‌پذیری و اونرشیپ داشتنخب، حالا ببینیم این رفتارها از کجا می آیند؟ چرا مردم از قبول مسئولیت‌های خود فرار می‌کنند؟ البته دلایل مختلفی برای این موضوع وجود دارد. عدم توازن بین ظرفیت و انتظارات از کارکنان، عدم شفاف‌سازی در مورد وظایف و خواسته‌ها؛ تضاد منافع بین طرف‌های مختلف درگیر در یک کار مشترک به دلیل شدت یا گسترش زیاد مسائلی که باید با مهارت ها و مسئولیت‌های مختلف حل شوند. می‌توانیم فهرست بی‌نهایتی از دلایلی را که از زمینه‌های مختلف می‌آیند آماده کنیم! اما به نظر من دو دلیل ریشه‌ای شامل انگیزش و شفافیت در اینجا مستتر هستند. بیایید این اصل مانیفست چابک را ببینیم:«پروژه ها را حول افراد با انگیزه بسازید. محیط و حمایتی را که نیاز دارند به آنها بدهید و به آنها اعتماد کنید تا کار را به انجام برسانند.» مانیفست چابک - اصل پنجمدر اینجا اشاره مستقیمی به افراد با انگیزه وجود دارد. واضح است که افراد باید برای قبول مسئولیت‌ها انگیزه داشته باشند، اما چگونه می توانیم آن را تعیین کنیم؟ آیا اجرای برنامه ارزیابی عملکرد برای ارزیابی کارایی افراد در وظایفشان ضروری است؟ آیا اساسا مفید هست؟ در بهترین حالت، شاید به ما نشان دهد که آیا آنها نسبت به وظایف خود عمل کرده‌اند و یا خیر و البته افراد می‌توانند در اندازه‌گیری‌ها تقلب هم بکنند!خودفریبی‌های ساختگی: (سمت چپ: من نماینده مطالبات هستم! سمت راست: من یک ابرقهرمان در تیم هستم)از این زاویه دید، من به این باور رسیده‌ام که انگیزه یک مفهوم خود تعیین‌کننده است و نمی‌توان آن را از بیرون شارژ و یا تقویت کرد. در نتیجه باید از دادن آب‌نبات به مردم خودداری کنیم! آنها نیازی به اتاق بازی لوکس یا اشتراک باشگاه ورزشی مجهز یا بلیط بازی بعدی در استادیوم ندارند. لطفا به خودمان دروغ نگوییم! اگر با ساختاری درگیر هستیم که سعی می‌کند مدیران را در قبال مسئولیت‌ها ایمن نگه دارد، باید آنها را به چالش بکشیم. ما اینجا هستیم تا برای کاربران نهایی واقعی ارزش ایجاد کنیم، نه برای لیستی از ادعاهای نمایندگی جعلی! از تست لیوان برای یافتن سیلوها و لایه‌های ناکارآمد و اخراج آنها استفاده کنید! می‌دانم که این یک ایده خیلی رادیکالی هست اما در عین حال تنها راه رستگاری است! لطفا سرنوشت توییتر را مرور کنید. دی اسکیل باید در لایه‌های ضخیم میانی اتفاق بیفتد نه اینکه آنها را غنی‌تر کند و برگ‌ها را آتش بزند!بیایید مشکل را از یک طرف دیگر هم ببینیم. در شرایطی که من کارمند تیم هستم، چه اتفاقی باید بیفتد تا انگیزه و تعهد خود را نسبت به وظایفم حفظ کنم؟ من معتقدم، ما به عنوان یک فرد باید ابتدا به این سؤالات پاسخ دهیم. زندگی خیلی کوتاه است. نباید با خود را فریب دادن آنرا هدر بدهیم!«من چند سال پیش به این شرکت پیوستم، اما احساس می‌کنم دیگر انگیزه‌ای برای ادامه همکاری با آن‌ها به همان شکلی که در روز اول داشته‌ام ندارم!»این دقیقا زمان رفتن است! ما باید بلافاصله بعد از این لحظه شنل‌های بتمن یا سوپرمن را که پوشیده بودیم را از تن به در بیاوریم!نهایتا، نقش اسکرام مسترها، مربیان تیم، مربیان سبک زندگی، و یا مربیان چابک در این میان چیست؟ من معتقدم مسئولیت ما بیشتر بر کانتکست دوم متمرکزتر است: تقویت شفافیت!نمی‌توانم تعداد مشاغلی را که به خاطر این رسالت از دست داده یا قبول نکرده‌ام را برشمارم! به عنوان یک مربی تیم یا یک اسکرام مستر، یکی از مسئولیت های مهم من در قبال تیم این است که آنها را بدون هیچ آرایشی در جلوی یک آینه صاف و درخشان قرار دهم (نه یک آینه سیاه که از داده‌های جعلی در مورد عملکرد و غیره می‌آید!). برایم اهمیتی ندارد که مدیران تا چه اندازه این نگرش را دوست دارند یا نه، زیرا احساس می‌کنم باید به عنوان یک مربی نسبت به سرنوشت مردم در تیم اونرشیپ و مسئولیت‌پذیری داشته باشم. اگر تیم موثری وجود نداشته باشد، نمی‌توانیم شانسی برای رسیدن به اهداف تجاری داشته باشیم. مردم باید وضعیت انگیزه خود را به صورت روزانه بررسی کنند، بنابراین شفافیت ضروری است!موفق باشید! چابکی یافتن کاری است که باید انجام شود!نسخه انگلیسی: https://medium.com/@omid.mojabi/human-shield-in-organizations-9f57ce2503cf امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Sun, 12 Nov 2023 20:25:59 +0330 https://virgool.io/payampardaz/%D8%B1%D8%A7%D9%87-%D8%AD%D9%84%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%87%D8%AF%D8%A7%DB%8C%D8%AA-%D8%AA%D8%B9%D8%A7%D8%B1%D8%B6%D8%A7%D8%AA-%D8%AF%D8%B1%D9%88%D9%86-%D8%AA%DB%8C%D9%85-c0fwbtjzaxfl آیا تعارضات (Conflict) درون تیم‌ها را می‌توان مدیریت (Management) و یا رفع (Resolution) کرد؟ حدودا یک دهه قبل پیش خانم لیزا ادکینز (Lyssa Adkins) استفاده از یک مدل و یا چارچوب کاری برای نحوه مواجهه با تعارضات (که به speed leas model شهرت دارد) را با بررسی دقیق‌تر آن در تیم‌های چابک را به مخاطبان‌شان ارائه دادند که هم مورد توجه قرار گرفت و هم دنبال کردن آن در سازمان‌ها و تیم‌ها نتایج بهتری نسبت به دیدگاه‌های کلاسیک مدیریت تعارضات به بار آورد. این نوشتار ترجمه آزادی است از جمع‌بندی این ارائه برای کمک به اسکرام مسترها و مربیان چابک ایرانی که همه روزه با تعارضات درون تیم‌های فنی مواجه هستند.به عنوان یک مربی چابک (یا اسکرام مستر)، باید به جای تلاش برای رفع و یا مدیریت تعارضات با روش‌های مکانیکی و صنعتی، باید آنها را به عنوان بخشی جدایی‌ناپذیر از طبیعت اجتماعی انسان‌ها بپذیریم و با آنها همراه شویم. با نگاهی عمیق‌تر به کانتکست‌های وقوع تعارضات می‌توان دست کم به دو دسته اصلی تعارضات عادی و یا ویرانگر و مخرب به صورت خیلی کلی اشاره کرد. نکته مهم این است که این رفتارها برای هر گروهی از افرادی که زمان قابل توجهی را با هم می‌گذرانند (برای مثال در خانه و یا محل کار) و تاریخچه مشترکی از مسائل را ایجاد می‌کنند، نشانه عادی بودن است و اگر وجود نداشت آن زمان باید نگران بود که انگار چیزی به درستی پیش نرفته‌است.سطوح پنج گانه تعارضات درون تیم بر اساس مدل Speed Leasدر این مدل پنج سطح از درگیری‌ها و تعارضات وجود دارد (شکل بالا). اما این مدل چگونه کار می‌کند؟ قطعا باید قبل از رفتن به سراغ اکشن‌ها بتوانیم حدس بزنیم که ما به عنوان یک تیم یا شرکت در چه سطحی از تعارضات قرار داریم؟ هنگامی که بتوانیم آن را تشخیص بدهیم، زمان دست به کار شدن است تا در سطحی که هستیم دامنه درگیری‌ها کاهش پیدا کند تا زمانی که دیگر آن تعارض ناپدید شود (و یا شفاف و هدایت شود ـ مترجم). این سطوح عبارتند از: 1- مساله‌ای برای حل کردن2- عدم توافق3- رقابت4- جبهه‌بندی5- جنگ جهانیاکشن‌های متناسب بسته به سطحی از تعارضات و درگیری‌ها که در تیم و یا سازمان وجود داردچه اقداماتی باید در مورد تعارضات انجام بدهیم؟سطح اول: مساله‌ای برای حل شدنناامیدی‌ها و ناراحتی‌های روزمره این سطح را تشکیل می‌دهند، و با بالا و پایین شدن روحیه افراد و یا حتی با آمدن و رفتن، تعارض را تجربه می‌کنیم. در این سطح، افراد نظرات متفاوتی دارند، سوءتفاهم ممکن است رخ داده باشد، اهداف یا ارزش‌های متضاد ممکن است وجود داشته باشد، و اعضای تیم احتمالاً نسبت به داشتن تعارض با یکدیگر هم احساس اضطراب می‌کنند!اگر در سطح اول هستیم: هیچ کاری نکن!در کنار بایستید و مشاهده کننده حرکات و اقدامات آنها باشید. ببینید آیا برای حل مساله‌ای که با آن مواجه شده‌اند به شکل سازنده‌ای پیش می‌روند یا خیر. حتی اگر فکر می‌کنید راه‌حلی برای کمک به آنها دارید (و یا حتی ندارید!)، اگر اعضای تیم به‌خوبی در مسیر یافتن راه‌حلی برای مساله خودشان هستند، آن‌ها را به حال خود رها کنید. این که تیم خودش بتواند اوضاع را بهتر (و یا حتی بدتر کند) بهتر از برنامه کامل شما برای حل موضوع است. حمایت از خودسازماندهی/خودمدیریتی تیم را به عنوان یکی از اهداف مربیگری همیشه به خاطر بسپارید. ناراحتی شما از نتیجه هزینه کمی است (در مقایسه با تجویزی که تیم خودش به آن نرسیده است و به او حاضر و آماده عرضه شده‌است ـ مترجم).سطح دوم: عدم توافقدر سطح دوم، محافظت از خود به اندازه حل مسال برای افراد مهم است. اعضای تیم از یکدیگر فاصله می‌گیرند تا مطمئن شوند که در نهایت خوب به نتیجه می‌رسند یا موقعیتی را برای توافقی که فکر می‌کنند به دست می‌آید ایجاد کنند. آنها ممکن است به صورت غیر رسمی با سایر اعضای تیم صحبت کنند تا استراتژی‌هایی را به بوته آزمایش بگذارند یا حتی به دنبال گرفتن مشاوره و پشتیبانی باشند. در این سطح، شوخی‌ها خوش اخلاق کم کم به سمت جدیت نه چندان خوشایند حرکت می‌کند. ممکن است حتی رفتارهای تندی در یک پوشش قندی به وقوع بپیوندند اما همچنان تلخی ته آن قابل احساس است. با این حال، اعضای تیم در رفتارشان آشکارا خصمانه نیستند، و فقط محتاط هستند. زبان استفاده شونده توسط آنها این وضعیت را منعکس می‌کند؛ کلمات آنها از یک موضوع خاص به سمت کلی‌گویی و تعمیم به کل تغییر می‌یابد. آنها در واقع با استحکام بخشیدن به دیوارهایی در پیرامون خود، تمام آنچه را که در مورد مسائل می‌دانند به اشتراک نمی‌گذارند. و حقایق به جای تفسیرها نقش دوم را بازی کرده و در مورد آنچه واقعاً اتفاق می‌افتد سردرگمی ایجاد می‌کنند.اگر در سطح دوم هستیم: بررسی و پاسخ را شروع کنیم!در این مرحله اقدامات ما شروع می‌شود. فهمیدن مسائلی چون در چه سطحی از تعارض هستیم؟ چه مسائلی دقیقا وجود دارد؟ چگونه به عنوان طرف A پاسخ دهم؟ من به عنوان طرف B چگونه پاسخ خواهم داد؟ چه گزینه‌هایی برای رفع موارد با ذهنیت باز وجود دارند؟ چه کاری باید انجام دهم (اگر انجام دادنی وجود باشد)؟ هنگام استفاده از حالت تجزیه و تحلیل و پاسخ، همواره به یاد داشته باشیی که هیچ فردی از ماجرا کلیت موضوع را نزد خود ندارد. دیدگاه هر فرد درگیر در موضوع معتبر و مورد نیاز است. اگر به عنوان مقال ده فرد عضو تیم هستند، ممکن است حتی ده دیدگاه مختلف راجع به موضوع وجود داشته باشد که هر کدام از آنها از نظر بیننده صادق است.سطح سوم: رقابتدر سطح سوم، هدف برنده شدن است. اعضای تیم شروع به همسو شدن با یک طرف یا طرف دیگر می‌کنند. احساسات به ابزاری تبدیل می‌شوند که برای "به دست آوردن" حامیان بیشتر برای موقعیت خود مورد استفاده قرار می‌گیرد. موضوعات و افراد به خط می‌شوند و اقدام به حمله به صورت باز صورت می‌گیرد. همانطور که اعضای تیم به ساختن جزئیات مطلوب خود توجه می‌کنند، زبان و عبارات مورد استفاده توسط آنها به تدریج خصمانه می‌شود. آنها برای مثال تعمیم بیش از حد انجام می‌دهند: "او همیشه فراموش می‌کند کد خود را بررسی کند" یا "شما هرگز به آنچه که من می‌گویم گوش نمی‌دهید." آنها در مورد طرف مقابل با فرضیات صحبت می‌کنند: "من می دانم که آنها چه فکر می‌کنند، اما آنها مساله واقعی را نادیده می‌گیرند."اگر در سطح سوم هستیم: بررسی و پاسخ را ادامه دهیم!در این مرحله اقدامات ما ادامه می‌یابد. با توجه به تنوع موضوعاتی که منجر به درگیری و تعارض می‌شوند؛ اقدامات ما در یکی از این دسته‌بندی‌ها قرار می‌گیرند:1- پذیرش دیدگاه افراد زمانی که خود رابطه مهمتر از موضوع است: البته این فقط می‌تواند یک استراتژی کوتاه مدت باشد و اگر در درازمدت به آن اصرار ورزیم، به گرفتاری‌های مضاعفی دامن خواهد زد. 2- مذاکره کنیم: وقتی چیزی که در مورد آن تعارض وجود دارد قابل تقسیم و تجزیه به اجزای کوچکتری باشد، برای مثال استفاده از یک منبع مشترک (نحوه تقسیم کارها بین افراد و نظایر آن ـ مترجم) مذاکره می‌تواند کارساز باشد. توجه به این نکته ضرورت دارد که وقتی موضوع حول محور ارزش‌های افراد (و در واقع برآمده از مایندست آنها است ـ مترجم) است، این روش موفق نخواهد بود چون ارزش‌ها قابل تجزیه به اتم‌های ریزتری نیستند و یک نفر با نقض ارزش‌های خود در واقع به مدل ارزشی دیگری تسلیم می‌شود (و دگیر آن فرد پیشین نخواهد بود ـ مترجم). 3- واقع‌گرا شویم: در وضعیتی هستیم که دو استراتژی قبلی کارایی ندارند. زمان عملگرایی فرارسیده؛ بدون فوت وقت شروع جمع آوری اطلاعات در مورد وضعیت برای اثبات حقایق موضوع نماییم.سطح چهارم: جبهه‌بندی (یا باندبازی ـ مترجم)در سطح چهارم ("ما" و "آنها" در آرایش تیم به شکل واضحی قابل مشاهده است ـ مترجم) اعضای تیم بر این باورند که افراد «طرف دیگر» مسائل تغییر نخواهند کرد. آنها ممکن است بر این باور باشند که تنها گزینه حذف سایرین از تیم یا حذف خودشان از آن تیم است. جناح‌ها ریشه‌دار می‌شوند و حتی می‌توانند در یک ساختار شبه سازمانی در تیم مستحکم شوند. هم‌ذات پنداری با یک جناح می‌تواند هویت تیم را تحت الشعاع قرار دهد و هویت تیم از بین برود. افراد و موقعیت‌ها یکسان دیده می‌شوند و راه را برای حمله اعضای تیم به وابستگی‌ها (نقاط ضعف و آسیب‌پذیری‌ها ـ مترجم) به جای تقابل با ایده‌ها و راه‌حل‌ها باز می‌کنند. این حملات به صورت زبانی با گفتارهایی مملو از ایدئولوژی‌ها و اصول موضوعه صورت می‌گیرد و باعث می‌شود به جای مسائل پیش‌آمده، موضوعات و حقایق خاص، این دیدگاه‌ها و اقدامات در کانون گفتگوها و واکنش‌های افراد واقع شوند. از مشخصه‌های این وضعیت داشتن نگرش کل‌گرایانه مدعی عدالت و روی آوردن به اقدامات تنبیهی و سرکوب طرف مقابل است.اگر در سطح چهارم هستیم: هدایت (Navigation) موضوع ضرورت دارد!در این مرحله باید از دیپلماسی "شاتل" استفاده کنیم! افکار و اقدامات را از یک گروه به گروه دیگر منتقل کنیم تا زمانی که آنها قادر به تنش‌زدایی (de-escalate) و استفاده از ابزارهای موجود در سطوح پایین‌تر درگیری هستند. ما در این مرحله به دنبال ایجاد دوباره یک ساختار امن در تیم و یا سازمان هستیم.سطح پنجم: جنگ جهانی!ناقوس "باید از بین بروند!" در این مرحله به صدا در می‌آید. در این سطح از تعارض دیگر تنها کافی نیست که یک نفر برنده شود. دیگران باید ببازند تا ما مطمئن شویم که این وضعیت وحشتناک دیگر تکرار نمی‌شود! ..اگر در سطح پنجم هستیم: فقط یک گزینه برای ما باقی مانده‌ است: جدا کردن اعضای درگیر شده با همدیگر به طوری که آنها به یکدیگر آسیب بیشتری نرسانند. مطلقا در این سطح از تعارضات هیچ نتیجه سازنده‌ای نمی‌توان داشت.مشاهده ویدئوی ارائه مشهور لیزا ادکینز:https://www.youtube.com/watch?v=Lm7amNJQBeMمقاله اصلی مورد استفاده در این ترجمه:https://jcalvopascua.medium.com/navigating-the-five-levels-of-conflict-9d7958ef09c8 امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Thu, 12 Oct 2023 14:21:19 +0330 https://virgool.io/@omid_mojabi/%DB%8C%DA%A9-%D8%AF%D8%A7%D8%B3%D8%AA%D8%A7%D9%86-%D9%85%D9%88%D9%81%D9%82-xhfvhf0hg5w9 این نوشتار ترجمه‌ای است از مقاله‌ای با عنوان "ساختن اپلیکیشن تردز" به قلم Gergely Orosz که سپتامبر امسال و مدتی بعد از لانچ تردز منتشر شده‌است.اپلیکیشن تردز (از شرکت متا مالک فیسبوک) در هفته‌ای که در دسترس عموم قرار گرفت بیش از یکصد میلیون بار نصب شد و تقریبا به همان تعداد کاربر پیدا کرد. چگونه تیم مهندسان این اپلیکیشن را ساختند و این استقبال دور از انتظار را مدیریت کردند؟ به شیوه‌ای منحصر به فرد!نمودار تعداد نصب‌های تردز در پنج روز اول بعد از لانچدر ژوئیه 2023، شرکت متا جدیدترین اپلیکیشن موبایل خود، با نام Threads را راه اندازی کرد که یک سرویس میکروبلاگینگ و رقیب جدیدی برای X (یا همان توییتر سابق) بود. در پنج روز اول پس از راه اندازی، این برنامه به 100 میلیون دانلود دست یافت که یک رکورد جدید برای شرکت با اختلاف بسیار زیاد است. رکورد قبلی متا برای نصب اپلیکیشن‌های جدید در پنج روز اول پس از انتشار عمومی، یک میلیون نصب بود. شکل بالا منحنی رشد تعداد کاربران تردز را نشان می‌دهد.این ارقام و اعداد رکورد قابل ملاحظه‌ای برای یک اپلیکیشن جدید هستند، حتی با در نظر گرفتن اینکه به بیش از 2 میلیارد کاربر فعال ماهانه اینستاگرام پروموشنی برای نصب ساده آن داده شده باشد. وقتی از این آمار مطلع شدم، اولین فکرم این بود که چگونه تیم مهندسی این انتشار را انجام دادند، ظاهراً بدون هیچ مساله بزرگی در هنگام انتشار. به‌ویژه وقتی در نظر می‌گیریم که تیم Threads از راه‌اندازی هم بالاتر رفت، خصوصا پس از آنکه توییتر کاربران رایگان را به تماشای 600 پست در روز محدود کرد؛ و این تصمیم یک فرصت عالی را برای یک رقیب بالقوه برای توییتر ایجاد کرد. کل ماجرا در عرض چند روز پس از محدود کردن نرخ مشاهده پست ها در توییتر به وقوع پیوست و به نظر می‌رسد که تردز از موقعیت پیش آمده به خوبی استفاده کرده است.اما از درون قضیه کار برای مهندسان سازنده اپلیکیشن چگونه پیش رفت؟ برای یافتن پاسخ این پرسش، با افرادی از تیم مهندسی Threads (که برای به اشتراک گذاشتن جزئیات پشت صحنه مشتاق و مجاز بودند) تماس گرفتم. جسی چن (Engineering Manager) و زاهان ملکانی (Server Engineer Lead) داستان چگونگی ساخت Threads را برای من تعریف کردند. جزئیاتی که آنها به اشتراک گذاشتند به خوبی با مجموعه چالش‌های مهندسان در دنیای واقعی مطابقت دارد.این لیستی از مطالبی هست که در این نوشتار راجع به آنها صحبت خواهم کرد:1. نحوه ساخت اپلیکیشن تردز2. گزینه‌های تکنولوژی و روش‌های مهندسی3. برنامه‌ریزی برای لانچ4. دروس آموخته و گام‌های بعدیدر این مقاله سئوالات من (Gergely Oorsz) با فونت مورب آمده و پاسخ های تیم مهندسی Threads با فونت معمولی هستند. به این ترتیب، در واقع جسی و زاهان هستند که درباره نحوه ساخت اپلیکیشن صحبت می‌کنند.نحوه ساخت تردزپرسش: تردز به عنوان یک پروژه نرم‌افزاری چقدر «معمولی» بود؟ در مقایسه با سایر اپلیکیشن‌های راه‌اندازی شده؟تردز با اکثر لانچ‌ها متفاوت بود. معمولاً وقتی یک اولویت جدید و هیجان‌انگیز از بالا به پایین در سازمان ما وجود دارد، ما به فرهنگ باز داخل تیم خود اتکا می‌کنیم تا افراد شرکت را حول ابتکار عمل جمع کنیم و تیم را برای پیوستن و راه‌اندازی خودانگیخته هیجان‌زده کنیم.اما در این مورد، تیم را عمدا کوچک و محرمانه نگه داشتیم. ما برای کار روی این موضوع از قوی‌ترین مهندسان، مدیران محصول و طراحان خود در اینستاگرام استفاده کردیم و با آدام موسری، مدیر ارشد اینستاگرام، مرورهای منظمی داشتیم. ما می دانستیم که time to market در این مورد اولویت اصلی است، و می خواستیم تیم را از سر و صدا و حواس‌پرتی محافظت کنیم.تیم انتشارپرسش: تیم اولیه چقدر بزرگ بود و چه بخشی از آن را مهندسان و افراد فنی تشکیل دادند؟تیم توسعه کم تعداد و مسطح (Flat) بود و از نظر تعداد سهم مهندسان و افراد فنی بیشتر بود؛ این یک انتخاب عمدی طراحی سازمانی بود زیرا ما ضرب الاجل سریعی برای انجام کار داشتیم و می‌خواستیم سرعت تصمیم‌گیری را به حداکثر ممکن و بوروکراسی و سلسله مراتب را به حداقل برسانیم.ما بر این باور بودیم که یک سازماندهی کم تعداد و Flat می‌تواند به ما کمک کند تا محصولات با کیفیت بالاتر را سریع‌تر بسازیم، و درستی این فرضیه هم در پایان به اثبات رسید. ما با یک تیم بسیار کوچک (در مجموع حدود دوازده نفر) شروع کردیم و اکثریت قریب به اتفاق اعضای تیم از اینستاگرام آمدند. هر فردی که به ساختمان Threads برای راه‌اندازی پیوست از یک انتقال داخلی به آنجا آمد و آنها پیش از پروژه کارکنان متا بودند.پیک کاری این تیم یک هفته قبل از انتشار تردز بود و در این زمان تیم از این افراد تشکیل می‌شد:1. سه نفر مدیر محصول2. سه نفر دیزاینر3. حدود 60 نفر مهندس و فنیمن (جسی) با لیدرهای فنی در سراسر سازمان اینستاگرام مشورت و بررسی کردم تا افراد کلیدی و سینیور مناسب را شناسایی کنم تا به این پروژه وارد شوند. بر همین اساس سطح تجربه تیم رفت به سمت کار کردن با افراد تمام سینیور، زیرا ما تیم نسبتاً کوچکی داشتیم و به افراد فنی‌ای نیاز داشتیم که می‌توانستند به طور مستقل کار کنند و قسمت‌های مربوط به خود را از برنامه با نظارت کمتری که معمولا نیاز است به پیش ببرند.تیم Threads در جشن راه اندازی ساعت شاد در ژوئیه 2023، در سانفرانسیسکو، کالیفرنیانحوه برنامه‌ریزی و کار با بقیه تیم‌های متاپرسش: برنامه‌ریزی کردن به جای مستقیما رفتن به دنبال نمونه‌سازی/کدنویسی چقدر رسمی یا غیررسمی بود؟در ابتدا پلنینگ‌های سطح بالایی وجود داشت، زیرا ما در مورد میزان استفاده مجدد از کدهای اینستاگرام بحث می‌کردیم. با این حال، در بیشتر موارد، ما مستقیماً به سراغ نمونه‌سازی و کدنویسی رفتیم.ما در این پروژه یکی از اصول اولیه متا را یادآوری کردیم، "کد همیشه بهتر از جر و بحث است". ما به شدت با این اصل هماهنگ بودیم. حتی قبل از اینکه برای شروع کار چراغ سبز رسمی را دریافت کنیم، مهندسان از قبل ایده آوردن یک فید متنی را برای فاز امکان‌سنجی نمونه‌سازی کرده بودند!پرسش: چقدر با سایر تیم‌های داخلی متا - مانند تیم‌های زیرساخت، پلتفرم یا محصول، کار و به آنها اعتماد کردید؟یکی از همکاری‌های منحصربه‌فرد ما یک برنامه «Bug Bounty» بود که در آن از محققان امنیتی دعوت کردیم تا قبل از لانچ اپلیکیشن را برای وجود اشکالات احتمالی بررسی کنند. هدف این برنامه کمک به محافظت از داده‌های افراد و کشف هر گونه اشکال امنیتی یا حریم خصوصی بود که ممکن است در اوایل کار داشته باشیم. به لطف این برنامه چندین باگ قابل توجه را قبل از لانچ پیدا کردیم.ما در واقع مخفیانه کار می‌کردیم. قبل از انتشار، تیم مهندسان اصلی از بقیه سازمان فنی اینستاگرام جدا شد. ما به شیوه‌ای محتاطانه کدهای خود را به کدبیس مشترک اضافه می‌کردیم و تنها زمانی که با مشکلاتی مواجه شدیم که به تخصص آنها نیاز داشت، با تیم‌های مربوطه برای رفع مسائل وارد تعامل شدیم. با این حال، ما نمی‌توانستیم این اپلیکیشن را در تمام مدت زمانی که برای آماده شدنش طول کشید، با کار به صورت منزوی نهایی کنیم. با اینکه ما قویا به ابزارها و چارچوب‌های داخلی خود متکی بودیم اما در چندین مورد مانند فریم‌ورک‌های واسط کاربری؛ سرویس‌ها، احراز هویت، امنیت، محرمانگی، زیرساخت سرورها و یکپارچه‌سازی از سایر تیم های متا کمک گرفتیم.ما تا جایی که می‌توانستیم از کدهای خود استفاده مجدد کردیم تا در سریع‌ترین زمان ممکن حرکت کنیم. سرعت توسعه و پایداری سریع ما در حین انتشار اولین نسخه، گواه این است که سازمان مهندسی ما چقدر عالی عمل کرده‌است. تیم‌های پلتفرم/زیرساخت ما وقتی به سرعت Scale می‌کنیم و محصولات جدید می‌سازیم و روی شانه‌های آنها می‌ایستیم، کار را آسان می‌کنند.تایم لاین پروژهما اولین خط کد را برای این اپلیکیشن به صورت مستقل در اواخر ژانویه 2023 نوشتیم و اولین نسخه قابل ریلیز را در ژوئن 2023 به اپ استور ارسال کردیم. مهندسی و ساخت این اپلیکیشن از آغاز تا اولین لانچ 5 ماه طول کشید.انتخاب‌های فناوری و رویکردهای مهندسیپرسش: کدام فناوری‌ها را برای بک اند و اپلیکیشن‌های موبایل انتخاب کردید؟بک اند در استک اینستاگرام (Django همراه با REST API های سفارشی شده) اجرا می‌شود. ما همچنین بک اند مونولتیک بزرگ متا را روی GraphQL (یک ماشین مجازی HHVM برای اجرای برنامه‌های نوشته شده در Hack و PHP) فراخوانی کردیم.اپلیکیشن‌ها عمدتاً Native هستند و از ترکیبی از Swift در iOS (و کمی Objective C) و Jetpack Compose در Android (با زبان های Kotlin و Java) استفاده می کنند. تعدادی صفحات نمایشی رندر شده برای برخی از تجربیات ساده وجود دارد، اما کد زدن Native جزو طبیعت سیستم است.استفاده مجدد از استک داخلیپرسش: برای استفاده مجدد از کدهای موجود در استک مانند کتابخانه‌های برنامه‌نویسی و فریم‌ورک‌ها در مقایسه با ساختن همه قسمت‌ها با کدهای خودتان، چه انتخاب‌هایی انجام دادید؟از آنجایی که Time to Market برای ما در اولویت بود، تا جایی که امکان داشت از استک فنی اینستاگرام استفاده کردیم. اینستاگرام خود بر اساس کتابخانه ها و فریم‌ورک‌های مختلفی ساخته شده که بسیاری از آنها داخلی و ساخت تیم‌های اینستاگرام هستند.ما از فرصت ایجاد شده برای آزمودن فناوری‌هایی در هنگام Scaleکردن استفاده کردیم که قبلاً فرصت آن را نداشتیم. در iOS، تمام بخش‌های جدید برنامه با سوئیفت ساخته شدند و در اندروید تا حد زیادی از Jetpack Compose استفاده کردیم. ما به توسعه زبان جدید (Swift) و گزینه‌های فریم‌ورک Jetpack Compose کمک می‌کنیم تا به همان سرعتی که انجام دادیم در ادامه کار هم حرکت کنیم.ما تصمیم گرفتیم قویا از استک فناوری‌های موجود در اینستاگرام استفاده کنیم، که بر اساس زیرساخت متا ساخته شده اند. این کار که کمک زیادی به سرعت برنامه‌نویسی ما کرد و یک مشکل اساسی نهفته در این پرسش را حل کرد: چگونه یک شبکه اجتماعی جدید مبتنی بر متن از ابتدا ایجاد کنیم؟ یا این پرسش بسیار متمرکز تر به موضوع: چگونه از بلوک های سازنده فید اینستاگرام برای پست‌هایی که بیشتر مبتنی بر متن هستند استفاده کنیم؟پرسش: تردز خیلی ضربتی انتشار خودش را انجام داد. چقدر پرفورمنس سمت مشتریان را در اولویت قرار دادید، و اگر این کار را انجام دادید، چگونه آن را اندازه‌گیری یا تست کردید؟عملیات لانچ به اندازه کافی سریع نبود! ما یک سری ابزارهای داخلی داریم که زمان مصرف شده در جاهای مختلف را رکورد می‌کنند و نمایش می‌دهند و مجبور شدیم در هنگام لانچ به شکل گسترده‌ای از آن‌ها استفاده کنیم. زمانی که محبوب‌ترین پست‌ها به‌طور جداگانه شروع به ایجاد انگیجمنت در کاربران کردند، ما اصلا انتظار نداشتیم که دستیابی به کل شبکه در روز لانچ شدنی باشد.ما فریم‌ورک‌های داخلی داریم که به ما امکان می‌دهند انواع متریک‌هایی عملکردی حیاتی را اندازه گیری کنیم. در اینجا چند نمونه آورده شده است:"زمان لازم برای شروع محتوای جدید" برای دیدن محتوا در فیدعملکرد اسکرول از طریق مشاهده پایین آمدن در فریمرویکرد تست برای تردزپرسش: چگونه مرحله تست را انجام دادید (یا انجام ندادید) و به طور خاص در مورد تست‌های اتوماتیک چه کردید؟ در اینجا دو مکتب فکری وجود دارد:محصول را بسازید و بازخورد سریع دریافت کنید و ملاحظاتی برای تست‌های خودکار در صورت وجود تناسب محصول با بازار (PMF) داشته باشید.محصول را از ابتدا با فرض یک PMF بسازید و تست‌هایی را برای نگهداری و نظایر آن در نظر بگیرید.ما دیدگاه اول را جلو رفتیم و در آن ملاحظاتی برای تست‌های اتوماتیک بعد از PMF برای تست قسمت‌های frontend/UI داشتیم. به دلیل اهمیت Time to Market، ما در مورد کنار گذاشتن چیزهایی که به ما در رسیدن به آن هدف کمک نمی‌کردند، با دیسیپلین و و به طور سیستماتیک عمل کردیم.برای اطمینان از عملکرد سیستم، تست‌های اتوماتیک قطعا مهم هستند. با این حال، نوشتن تست برای رابط کاربری که دائما در حال تغییر است، ارزشی ندارد. در این کانتکست، برخی از فلوها قبل از اینکه به چیزی که دوست داشتیم برسیم، بیش از 3 طراحی مجدد داشتند!تست‌های اتوماتیک به محصولی که PMF نکرده کمکی نمی‌کنند. به جای آن، ما به طور گسترده به DogFooding (روشی که در آن افراد فنی به طور مداوم از محصول خود استفاده می‌کنند تا ببینند چقدر خوب کار می‌کند و در کجا می‌توان بهینه‌سازی انجام داد) و QA متکی بودیم. Dogfooder ها نسخه‌های بیلد شده روی برنچ کاری master (که هر چند ساعت یک‌بار با آخرین تغییرات به‌روزرسانی می‌شوند) را دانلود و استفاده می‌کردند. حلقه بازخورد سریع به ما این امکان را می‌دهد که ظرف چند ساعت از ماک‌آپ‌های figma به یک بیلد اصلی روی تلفن شما برویم.با این حال، لاجیک کسب‌وکاری بک اند از روش TDD پیروی می‌کرد که از طریق بررسی توسط افراد pair تشویق شد. ما فریم‌ورک‌های تست داخلی عالی داریم که به شما امکان می‌دهد وضعیت مورد تست و منطق کسب‌وکار واقعی را به راحتی، بدون دست زدن به پایگاه‌های داده عملیاتی تنظیم کنید. این به تیم پشتیبان امکان داد سریع‌تر حرکت کند، زیرا می‌توانستیم با اطمینان تغییرات را ایجاد کنیم، بدون اینکه نیازی به تست سرتاسری (End-to-End) به ازای هر تغییر تازه باشد.برنامه ریزی برای انتشارپرسش: بزرگترین چالش‌های لودینگ که برای Threads پیش بینی می‌کردید کدام موارد بودند؟ویژگی خاصی که می‌دانستیم قرار است چالش‌هایی در Scale ایجاد کند، این بود که به کاربران این امکان را می‌داد تا به گراف خودشان از اینستاگرام متصل و وارد بشوند.یکی از بخش‌های دشوار راه‌اندازی یک شبکه اجتماعی جدید، «Cold Start» است که کاربران با آن مواجه هستند. هر یک از کاربران جدید شما نیاز دارند افرادی را که به آنها علاقه‌مند هستند را در پلتفرم پیدا کند و انتخاب کند که آنها را دنبال نمایند و یا دوست بشوند. در مورد ما، ما می‌خواستیم با ارائه یک حرکت یک ضربتی برای «فالو کردن همه افرادی که قبلاً در اینستاگرام دنبال می‌کنید» این کار را برای ایشان آسان‌تر کنیم.با این حال، یک مشکل Scaling عمده در اینجا وجود دارد! به حساب‌های پرطرفدارتری فکر کنید که به Threads ملحق می‌شوند و به این ترتیب میلیون‌ها مخاطب از قبل برای دنبال کردن آنها در صف ایستاده‌اند. ما نیاز داشتیم که چنین حساب‌های کاربری بزرگی را در زمان مناسبی پردازش کنیم. پس از راه اندازی، متوجه شدیم که مقیاسی که با آن سروکار داریم بسیار فراتر از انتظارات ما است. از زمان راه‌اندازی به بعد، ما باید این سیستم را با مجموعه‌ای از فرضیات کاملاً متفاوت طراحی کنیم.انجام Dogfooding (به عنوان بخشی از تست آلفا)پرسش: درThreads برای چه مدت Dogfooding انجام شد، و تقریباً توسط چند نفر؟ تیم چگونه به جمع آوری بازخورد و رسیدگی به آنها پرداخت؟این برنامه از ابتدا در آزمایش مداوم بود، اما ما عمداً گروه بازخورد را کوچک نگه داشتیم. هدف ما دریافت سیگنال‌های قوی بازخورد بدون ایجاد حواس‌پرتی برای تیم با گزارشات باگ‌ها بود. ما به آرامی Dogfooding را از تیم اصلی به تمام اینستاگرام گسترش دادیم. با جمعیت کوچک‌تر، مهندسان مستقیماً با همکاران خود انگیجمنت پیدا کردند و اشکال زدایی صورت پذیرفت، که منجر به یک حلقه بازخورد بسته در داخل سازمان شد.تست‌های Load (یا بدون Load Test)پرسش: چگونه برای لانچ محصول آماده شدید و لود اولیه را تحمل کردید؟ به عنوان مثال، آیا تست‌های لود را از قبل انجام داده‌اید یا تست‌های دیگری را امتحان کردید؟انجام تست‌های گسترده مطمئناً جزو برنامه ما بود. با این حال، به دلیل شرایط خارجی (احتمالا منظور ایشان محدودیت اعمال شده توسط توئیتر در تعداد فیدهای قابل خواندن توسط کاربران که فرصت خوبی برای لانچ سریع محصول به نظر می‌رسید - مترجم)، ما انتشار محصول خود را زودتر از زمان برنامه‌ریزی شده انجام دادیم.ما باید ظرفیت خود را افزایش می‌دادیم و از لانچ در حین ادامه توسعه پشتیبانی می‌کردیم. این به دلیل انتشار زودتر از برنامه‌ریزی ما بود و به دلیل این تغییر جدول زمانی، ما نتوانستیم تست‌های لود را از قبل انجام دهیم. این یکی از شدیدترین و سریع‌ترین لانچ‌هایی بود که در آن شرکت داشتیم!پرسش: چقدر مطمئن یا نامطمئن بودید که می‌توانید یک لود بزرگ بالقوه را هنگام انتشار تحمل کنید؟ من انجام یک لانچ به صورت جهانی (البته به استثنای کاربران اروپایی به دلیل مسائل حقوقی بین متا و اتحادیه اروپا - مترجم) بدون محدودیتی برای ثبت نام و یا لیست انتظار را شاهد بودم، همانطور که شما انجامش دادید.ما می‌دانستیم که تخصص اینستاگرام و متا را پشت سر داریم، بنابراین برای لانچ نسبتاً مطمئن بودیم. و البته ما در ابتدا فکر می‌کردیم که در مقیاسی کوچکتر از کل کاربران متا باشیم. حقیقتا ورود تعداد زیادی کاربر، به این سرعت، در متا بی‌سابقه بود. با این حال یک دهه سرمایه گذاری در زیرساخت‌های قابل اعتماد و کارآمد در متا واقعا کمک کرد. زمینه‌هایی مانند:پایگاه‌های داده (Datebases)سیستم‌های نمایه‌سازی مبتنی بر گراف (Graph indexing systems)سیستم‌های رتبه بندی (Ranking systems)سیستم‌های یکپارچگی (Integrity systems)سیستم‌های اطلاع رسانی (Notification systems)این سیستم‌ها همه به طور هماهنگ کار می‌کردند تا لود وارد شده را بدون هیچ گونه مشکل جدی‌ای جذب و مدیریت کنند.انتشار تردزپرسش: از بیرون، لانچ محصول به طرز شگفت‌آوری روان به نظر می‌رسید و شاید نهایتا چند ضربه کوتاه در هفته اول وجود داشت. از داخل سازمان چطور پیش رفت؟این یک وضعیت "همه دست به کار باشید" برای تیم بود، از هفته قبل از راه‌اندازی و برای هفته‌های پس از آن. ما تماس‌های ویدیویی منظمی را میزبانی می‌کردیم تا درباره مشکلات به صورت زنده صحبت کنیم، و اکثریت تیم شبانه‌روز برای حل مشکلات مختلف کار می‌کردند.نکته دلگرم کننده این بود که قطعاً این یک تلاش فقط از سوی تیم Threads نبود. بخش عمده‌ای از پشتیبانی راه‌اندازی از سوی تیم‌های همکار ما در اینستاگرام و در سراسر متا انجام شد. توسعه دهندگانی که روی اجزای زیرساختی کار می‌کردند با مهندسان و افراد فنی که سیستم‌ها را فعال نگه می‌داشتند، و مهندسان محصول برای رفع اشکال ویژگی‌های آنها کار می‌کردند، همکاری خوبی نشان دادند.لانچ تردز فرصتی برای مشاهده مزایای داشتن یک فرهنگ باز در سازمان است. یک پایگاه کد باز که واقعاً سودمند است، زیرا افراد جدید می توانند به سرعت به کار ملحق شده و ارزش ارائه کنند، حتی اگر موضوع کاملا جدید باشد.اندازه گیری چگونه پیش رفتن نحوه انتشار محصولپرسش: برای اطمینان از اینکه تردز همانطور که انتظار می‌رفت کار می‌کند، روی کدام KPI های مهندسی یا اندازه‌گیری‌ها تمرکز کردید؟ما از ابزارهای نظارتی مانند موارد زیر استفاده کردیم:سیستم ODS - یک ماشین ذخیره سازی سری زمانی با کارایی بالا - و Scuba - یک سیستم مدیریت داده که ما برای تجزیه و تحلیل بلادرنگ (Real-Time) استفاده می‌کنیم. این ابزارها به پیگیری لود و موارد مشابه در زمان واقعی کمک می‌کنند.یک اکوسیستم ETL تکامل یافته که متریک‌های کلیدی محصول را به صورت ساعتی به ما ارائه می‌دهد.ما به شدت از ابزارهای PREQ (عملکرد، قابلیت اطمینان، کارایی، کیفیت) استفاده کردیم. تیم ما بر تجربه فوق‌العاده متا در پشتیبانی از ابزارهای PREQ که در اپلیکیشن سمت کلاینت ساخته و در فریم‌ورک‌های سمت سرویس‌دهنده ما ادغام شده‌اند، تکیه کرده‌اند. متریک‌هایی که ما به آنها توجه داشتیم عبارتند از:عملکرد و لود سمت سرور (Performance and server-side load)"زمان لازم برای محتوای جدید" - متریک Cold Start ما در اپلیکیشنشاخص QPS / نرخ موفقیت در نقاط پایانی کلیدی ما (success rate on our key endpoints)طول صف در کارهای ناهمگام همراه با پردازش‌های سنگین (async jobs handling heavy lifting)ردپای کلی ما در مونولیت اصلی بک اند اینستاگرام (Instagram backend monolith)در صورتی که مقیاس را هم به درستی در نظر نگرفته باشیم، هشدارهای همگانی در سطح نقاط پایانی نیز هنگامی که چیزها برای نقاط پایانی خاصی می روند، به ما اطلاع می‌دهند.آمار و ارقام لانچرکورد قبلی سریعترین رشد اپلیکشن در متا، 1 میلیون کاربر در 5 روز بود. Threads اما اینگونه رشد کرد:1 میلیون کاربر در 1 ساعت اول30 میلیون کاربر در روز اول70 میلیون کاربر در روز دوم100 میلیون کاربر در روز پنجمدروس آموخته و گام‌های بعدیپرسش: چالش سختی که پیش آمد چه بود؟ایجاد یک فید جذاب برای Threads بزرگترین چالش بود. در یک سایت میکروبلاگینگ (مانند توئیتر)، مواردی در حال حاضر به وقوع می‌پیوندند اهمیت بیشتری دارند. باید آنچه که همه در مورد آن صحبت می‌کنند، ثبت و ضبط شود و انتخاب‌هایی را ارائه کند که کاربران در آن مکالمه‌ها غوطه‌ور شوند و انتشار مطلب را ادامه دهند.تعادلی بین بلادرنگ بودن و کمک به کاربر برای یافتن محتوای شخصی که به احتمال زیاد مورد علاقه وی است، وجود دارد. در عین حال، سایر اپلیکیشن‌های موجود در این فضا ثابت کرده‌اند که برای ارائه محتوای مرتبط و جالب نیازی به یک گراف گسترده‌ای از اتصالات ندارید.ما در تیم Threads صحبت کرده‌ایم که چگونه می‌خواهیم اتکای خود را به کاربرانی که به صورت دستی گراف دنبال‌کنندگان را تنظیم می‌کنند کاهش دهیم. با این حال، برای کاهش اتکا به آن، باید بدانید که این پست‌ها در مورد چی هستند، و بدانید که در دنیا چه می‌گذرد – که حداقل می‌توان گفت هر دو چالش برانگیز هستند!دروس آموخته برای تیم فنیپرسش: چه چیزی از نظر فنی و مهندسی در این پروژه و لانچ آن خوب پیش رفت؟این دو مورد برجسته هستند:سرعتی که با آن توانستیم یک محصول صیقل خورده آماده عرضه بسازیم.اندازه نسبتاً کوچک تیمی که به این موفقیت دست یافت، هم از نظر درون‌سازمانی و هم از نظر بیرون آن مطلوب بود.قبل از راه اندازی این برنامه، علاقه زیادی در بازار وجود داشت، که به مردم دلیل خوبی برای دانلود برنامه و امتحان کردن آن را داد. وظیفه ما به عنوان مهندس این بود که موانع فنی را از سر راه برداریم و به آنها اجازه دهیم این کار را انجام دهند. این یک دستاورد بزرگ است که ما توانستیم این کار را به شکلی روان و خوب انجام دهیم.پرسش: چه آموخته‌های ارزشمندی برای تیم فنی و مهندسان وجود دارد ؟تمرکز: تمایز اصلی بین محصولاتی است که برای یافتن محصول متناسب با بازار تنظیم شده اند و آنها که اینگونه نیستند. تمرکز ضروری است، اگرچه به خودی خود کافی نیست. تلاش در Threads این بود که بتوانیم با کوچک کردن اسکوپ تجربه محصول به شکلی تهاجمی، بر روی اصول اولیه تمرکز کنیم. در اوایل تصمیم گرفتیم اجرا را روی Milestone های درون سازمانی متمرکز کنیم. هر کدام از این Milestone ها یک اپلیکیشن کاملاً صیقل خورده و shippable بود که با عملکردهای کمتری ساخته شده بود. این Milestone های درونی، شفافیت را در مورد آنچه که ما برای ساختن آن نیاز داشتیم، فورس می‌کرد، زیرا اصلا زمانی برای بازگشت به عقب و بررسی چیزهای دیگر وجود نداشت.پرسش: به عنوان یک مهندس و فردی فنی، جالب ترین بخش این پروژه چه بود؟درک وسعت کدبیس‌های اینستاگرام. تصمیم فنی برای به اشتراک گذاشتن بسیاری از استک فناوری با اینستاگرام به این معنی بود که ساخت این اپلیکیشن به تمرینی برای ایجاد تغییر از طریق کدبیس‌های اینستاگرام تبدیل شد، و ما توانستیم آنها را به شکلی هدفمند برای پشتیبانی از کارهای خود مورد استفاده قرار دهیم.به ندرت می‌توان همزمان که به جزئیات پیاده‌سازی در زیرسیستم‌های مهم اینستاگرام میپردازیم بهانه‌ای هم برای درک اینستاگرام در چنین سطح بالایی به دست آورد! تقریباً شبیه یک پازل بود: ما باید در می‌یافتیم که در کدام سیستم‌های اینستاگرام هدفمندترین تغییرات را ایجاد کنیم که بیشترین دستاورد و در عین حال کمترین ریسک را داشته باشد. این چالش در نهایت جالب ترین بخش پروژه بود.گام‌های بعدیپرسش: راه اندازی Threads چه تاثیری بر نحوه ساخت اپلیکیشن‌ها در متا می‌تواند داشته باشد؟افراد زیادی بوده اند که در داخل به Threads به عنوان یک مطالعه موردی برای بررسی شیوه عرضه محصولات در آینده نگاه می‌کنند. سرعت بالای ارسال اولین نسخه Threads چیزی است که این راه‌اندازی را متمایز می‌کند – در حالی که کار روی این برنامه از اوایل همین سال آغاز شده است!این یک تغییر فرهنگی قابل توجه است که یک تیم فنی کوچک اما سینیور یک اپلیکیشن مستقل با این نوع استقبال عمومی را فقط در طی پنج ماه، حتی در متا بسازد و لانچ کند. از اینکه می‌بینم دیگران دارند الهام می‌گیرند و تیم‌های سریعتر و تهاجمی‌تری می‌سازند، هیجان زده هستم!پرسش: اولویت‌های بعدی تیم و برنامه‌های رشد آن چیست؟در خصوص اولویت‌ها، جدا از فیکس و بهبود تمام گپ‌ها و حفره‌های محصول اصلی که کاربران ما آنها را به صورت فیدبک فریاد می‌زنند، ما همچنین سرمایه‌گذاری هنگفتی در ارتقاء زیرساخت لازم برای قوی‌تر کردن Threads انجام می‌دهیم.تعداد لانچ‌های واقعی ما بسیار فراتر از پیش بینی‌ها بود. لیدرهای ما نسبت به مسیر برنامه خوشبین هستند و در نتیجه، ما روی رشد تیم فنی و مهندسی سرمایه گذاری می‌کنیم.تردز در ابتدا به عنوان یک دستگاه انکوباتور کوچک در سازمان اینستاگرام شروع به کار کرد. با موفقیت در لانچ، ما هیجان‌زده هستیم که شاهد رشد این روش ابتکاری به شکلی رسمی‌تر (در مجموعه شرکت‌های متا) باشیم.پرسش: تیم فنی و مهندسی با نگاه به آینده از چه چیزهایی هیجان زده است؟ما روی ارائه ویژگی‌های جدید تردز در سریع‌ترین زمان ممکن کار کرده‌ایم. یکی از این ویژگی‌ها، نسخه تحت وب لاگین شده است که بسیار درخواست شده بود و ماه گذشته آن را ارسال کردیم. نسخه دیگر، گسترش تست جستجوی محتوای کلمه کلیدی ما برای کاربران بیشتری در کانادا، ایالات متحده، هند و بریتانیا است - که امروز (7 سپتامبر 2023) آن را لانچ می‌کنیم.من برای تیم ما برای حفظ ویژگی‌های shipping که تجربه افراد را در Threadsبهبود می بخشد، هیجان زده هستم. من همچنین از تعهدمان برای پیوستن به Fediverse و پشتیبانی از پروتکل ActivityPub هیجان‌زده هستم. در مقیاس ما، این یک چالش فنی و نظارتی فوق العاده هیجان انگیز است. پیوستن به Fediverse و ایجاد قابلیت همکاری با سایر شبکه‌ها برای ایجاد یک اکوسیستم گفتگوی عمومی متنوع‌تر و پر رونق، چیزی است که ما همچنان متعهد به تلاش برای آن هستیم.نکات Takeawaysمن (Gergely) به عنوان نویسنده این مقاله از Jesse، Zahan و تیم مهندسی Threads برای به اشتراک گذاشتن جزئیات در مورد نحوه ساخت و راه اندازی برنامه بسیار سپاسگزارم. برای ما مخاطبان جالب بود بدانیم که این تیم چگونه این شاهکار را به دست آورد و چگونه رویکردهای آن‌ها با آنچه در مورد فرهنگ مهندسی متا می‌دانیم مطابقت دارد.آخرین سوالی که باید از تیم Threads بپرسم، برنامه آنها برای لانچ در اتحادیه اروپا است. این برنامه در سطح جهانی در دسترس است - به جز اتحادیه اروپا، به دلیل نگرانی‌های قوانین و مقررات آنجا. این چیزی است که تیم در مورد برنامه های خود به من گفت:ما در حال کار بر روی انتشار Threads در کشورهای بیشتری هستیم و به ارزیابی اینکه آیا در اتحادیه اروپا هم لانچ کنیم یا خیر، ادامه خواهیم داد، اما موضوع قوانین و مقررات اتحادیه اروپا در تصمیم ما برای عدم لانچ آن در حال حاضر نقش داشته است. اروپا همچنان یک بازار فوق العاده مهم برای متا است و ما امیدواریم در آینده محصولات جدیدی را در اینجا در دسترس قرار دهیم.جالب است بدانیم که آیا متا لانچ تردز در اتحادیه اروپا را به تعویق می اندازد؟ یا اینکه می‌توانیم انتظار داشته باشیم اپلیکیشن‌ها و سرویس‌های جدیدی که توسط شرکت‌های بزرگتر راه اندازی شده‌اند، به دلیل پیامدهای اضافی حفظ حریم خصوصی که قوانین سختگیرانه اروپایی نیاز دارد از استراتژی «آخر از همه در اتحادیه اروپا!» پیروی کنند.مشاهده نسخه انگلیسی مقاله: https://newsletter.pragmaticengineer.com/p/building-the-threads-app امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Thu, 05 Oct 2023 23:10:19 +0330 https://virgool.io/@omid_mojabi/%D8%A2%DB%8C%D8%A7-%D8%A7%D8%B3%DA%A9%D8%B1%D8%A7%D9%85-%D8%B4%D8%B1%D9%88%D8%B1%D8%A7%D9%86%D9%87-%D8%A7%D8%B3%D8%AA-u0um1g4ccf5q این هفته ما یک بحث چالش برانگیز در جلسات هفتگی اجایل به انگلیسی داشتیم و موضوع در مورد معضلات اسکرام به عنوان یک روش کار کردن بود. اخیراً بحث‌ها و بحث‌های مختلفی در خصوص استفاده از اسکرام در زمینه‌های مختلف پروژه‌ها و محصولات انجام شده است. در این جلسه، ما بر روی سناریوهای کلی در مورد استفاده از اسکرام و پیامدهای مبهم آن در روش‌های زمینه کاری متمرکز شدیم.متأسفانه، در بازار، توجه ضعیفی به واقعیت مساله صورت می‌پذیرد. چارچوب اسکرام یک ابزار برای رسیدن به موفقیت نیست. در واقع، اگر بخواهیم آن را برای ایجاد تغییرات مکانیکی برای رسیدن به موفقیت به کار ببریم، در نهایت ابزار بهتری برای شکست است! یکی از دوستان قدیمی من چندی پیش در میانه یک بحث چالش برانگیز گفت: ای کاش یک ماشین زمان داشتیم و می توانستیم به ده سال قبل برگردیم تا برخی چیزها را در مورد درک امروزی مان از چابکی اصلاح کنیم. من معتقدم وقتی می‌خواهیم برای رهبری یک تحول چابک در سطح شرکت اقدام کنیم، باید آن را در همه جهات شروع کنیم. این نهضت نمی‌تواند فقط از پایین به بالا یا از بالا به پایین باشد. اسکرام یک چارچوب کاری است که از مکتب تویوتا نشات گرفته است. آن‌ها می‌خواستند از ایده‌ای که در پشت آن وجود داشت برای ایجاد بخش‌های جدید از محصولات خود استفاده کنند. ایده اصلی در مورد تقویت نوآوری، خلاقیت و انعطاف‌پذیری در یک موقعیت ناشناخته است. استفاده از اسکرام برای مسائل و کانتکست‌هایی که قبلاً شناخته شده‌اند، بر خلاف تفکر ناب است و منجر به اتلاف وقت، بودجه و منابع ما خواهد شد. قطعا اسکرام شرورانه نیست. اما می‌توان از آن برای اهداف بدی مانند ارزیابی نادرست عملکرد یا میکرومنیجمنت استفاده کرد! اگر چه اسکرام چیزهای زیادی به ما داده است (مانند اسپرینت، بک لاگ، جلسات روزانه، DoD، و غیره) که دیگر نمی‌توانیم بدون آن‌ها پرکتیس کنیم، اما اگر فقط آنها را دنبال کنیم، ممکن است یک تله‌ای باشد که آنها را زامبی‌وار دنبال نماییم. مواردی را عملیاتی کنیم که ضروری نیستند یا ریسک‌های مهم را به دلیل سکوت چارچوب در رابطه با آنها فراموش نماییم! بیایید فرض کنیم که می‌دانیم چگونه از زامبی اسکرام یا اجرای مکانیکی آن اجتناب کنیم. آیا استفاده از آن در همه انواع پروژه‌ها، تیم‌ها، اتمسفرهای سازمانی و محصولات معنی دارد؟ قطعا نه! آیا مکانیسمی وجود دارد که بدانیم اسکرام برای به حداکثر رساندن ارزش مفید است یا خیر؟ سوال ساده‌ای نیست! خب پس نهایتا باید چه کار کنیم؟ آیا اسکرام خود را حذف کنیم و به روش‌های سنتی کار برگردیم؟ به نظر من امروزه نمی‌توانیم با روش‌های تماما اسکرام در بسیاری از محصولات و تیم‌هایمان کار کنیم. اما اسکرام به ما کمک کرده است تا در به کارگیری چیزهایی که معتقدیم درست است و آنها را تولید و عرضه می‌کنیم، آزادانه عمل نماییم. بتوانیم بازخورد جمع آوری کنیم و در مورد آنها تفکر کنیم و ترتیب اثر بدهیم. پس بیایید بگوییم که اسکرام در مقایسه با مدل های قدیمی کار کردن یک دستاورد قابل احترام است. اما ما باید چشمان خود را به مشکلات خود باز کنیم تا پاسخی بهتر از صرفا اعمال یک چارچوب کاری را پیدا کنیم. خود اسکرام این امکان را به ما داده‌است. بنابراین، بیایید انجامش بدهیم!چابکی یافتن کاری است که باید انجام شود!نسخه انگلیسی نوشتار: https://medium.com/@omid.mojabi/is-scrum-evil-37699d405486 امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Wed, 13 Sep 2023 23:58:52 +0330 https://virgool.io/@omid_mojabi/%DB%8C%DA%A9-%D9%85%D8%B3%D8%A7%D9%84%D9%87-%D8%A8%D8%B1%D8%A7%DB%8C-%DA%A9%D8%A7%D9%88%D8%B4-%D8%B0%D9%87%D9%86-ie0oiub3xnpp اگر فقط مجاز باشید دو چوب کبریت را جابجا کنید، بزرگترین عددی که می‌توان ساخت چیست؟این هفته، یکی از بهترین دوستان من چالش جدیدی را برای مدیریت محصول در بلاگ خودش به اشتراک گذاشت که از مخاطبان می‌خواست تمام تلاش خود را برای یافتن بزرگترین عددی که که فقط با حرکت دادن دو چوب کبریت ایجاد کرد، انجام دهند! او معتقد است که این یک چالش بزرگ برای افرادی خواهد بود که مسئول به حداکثر رساندن ارزش در یک محصول هستند! طبق معمول، چالش او را در کانال‌های رسانه‌های اجتماعی خودم منتشر کردم و با اعداد خارق‌العاده‌ای که از تلاش و خلاقیت مخاطبان می‌آمدند، مواجه شدم! در مقایسه با گذشته، این بار مخاطبان خیلی مشتاق بودند که شرکت کنند و اعداد بیشتری پیدا کنند! مسأله‌ای پیدا کرده بودم که باید با آن روبرو می‌شدم: چرا این دفعه متفاوت است؟ آیا خلق و خوی مردم به طور تصادفی تغییر کرده است؟ دلیل این حجم از مشارکت چیست؟قطعاً پاسخ صحیح از کانتکست می‌آید، اگر بخواهید بزرگترین عدد را با سه رقم داشته باشید، به راحتی آن را پیدا خواهید کرد. اگر چهار یا حتی پنج رقمی بخواهید، آنها را هم می‌توان ساخت! یک نفر توانست 9e9 یعنی 9 به همراه 9 تا صفر یا نه میلیارد را هم بسازد. اگر در مورد این مساله به صورت آنلاین جستجو کنید، اعداد بزرگتری را هم خواهید یافت (به عنوان مثال این ویدیو را تماشا کنید)، اما این مساله راجع به توانای‌های ریاضی و هوش ما نیست! این این به روشنی نشان می‌دهد، به عنوان یک محصول‌چی، ما مسئولیم از دانسته‌ها (در اینجا قانون و قاعده تنها تغییر دو چوب کبریت به عنوان حرکت مجاز) برای دست یافتن به نادانسته‌ها بهره‌برداری کنیم! هر آنچه که ما به دست بیاوریم مستقیما از عملکرد ما در زمین بازی و تصویری برنده‌ای که در ذهن ما نقش بسته‌است به وقوع می‌پیوندد. بیایید اعداد را فراموش کنیم و روی آنها تمرکز کنیم: تلاش و ذهن ما!موفق باشید! چابکی یافتن کاری است که باید انجام شود!نسخه انگلیسی نوشتار: https://medium.com/@omid.mojabi/a-problem-for-mining-the-mind-77c9238f5127 امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Sun, 10 Sep 2023 13:34:40 +0330 https://virgool.io/@omid_mojabi/%DA%A9%D8%AF-%D8%B1%DB%8C%D9%88%DB%8C%D9%88-%D8%AD%D9%84-%DA%A9%D8%B1%D8%AF%D9%86-%DB%8C%DA%A9-%D9%85%D8%B3%D8%A7%D9%84%D9%87-kouf7zsm86yw یک تیم فنی را با چندین برنامه‌نویس در نظر بگیرید که می‌توانند در بررسی کدها به یکدیگر کمک کنند. در نگاه اول، تقسیم کردن کد ریویوها بین آنها ایده خوبی به نظر می‌رسد تا ضرباهنگ تیم در تولید کدهای برنامه‌نویسی در برنچ‌های محلی روی سیستم افراد حفظ شود و کدهای تولید شده با کمترین میزان تاخیر در برنچ اصلی develop قرار گیرد. اما (همیشه یک «اما» وجود دارد!) سطوح مختلف دانش، تجربه و توجه افراد چی؟ ما با افرادی کار می‌کنیم که با هم متفاوت هستند، دانش آنها متفاوت است و حتی خلق و خوی آنها در یک روز عادی هفته متفاوت است! چگونه می توانیم تضمین کنیم که این رویکرد کدهای پایداری تولید می‌کند؟نظرتان در مورده ایده استفاده از یک Gateway چیست؟ راهنمای اسکرام تاکید می‌کند که فقط یک PO برای تیم اسکرام وجود دارد نه کمیته‌ای از آنها. یک جرقه‌ای از این ایده به ذهن ما می‌رسد: فقط یک نفر را مسئول ریویوی کدها کنیم! این جرقه خوشبختانه بلافاصله با این سئوال به پایان می‌رسد: چه کسی مسئول این Gateway فنی است؟ تیم‌ لیدرها؟ دولوپرهای سینیور؟ فرد مناسبی که بتوانیم در این مورد به او اعتماد کنیم کیست؟ و چرا باید برای یافتن این قهرمانان تلاش کنیم؟! آیا آنها خارج از فیلم‌ها یا سریال‌های تلویزیونی اصلا وجود دارند؟ هیچکس نمی‌خواهد این مسئولیت را در دنیای واقعی گردن بگیرد! به من اعتماد کنید! ما قطعاً به یک چیزی نیاز داریم که به آنها کمک کند تا آنرا به صورت سیستماتیک و یا حتی اکتشافی مدیریت کنند. من معتقدم این یک توافق در سطح تیم به نام "توافق تیم" یا Team Agreement است و در قلب آن، اصول کد ریویو باید تعبیه شود!بیایید این بار چیزمیزهای چابک را رها کنیم و روی اصول کد ریویو تمرکز داشته باشیم (قطعاً آنها از روش‌های چابک می‌آیند، اما این بار من روی قسمت فنی قضیه متمرکزم). برای نمونه بیایید نگاهی سریع به اصول SOLID در برنامه‌نویسی بیندازیم. اصول SOLID شامل پنج اصل طراحی کلاس‌ها به صورت شی‌گرا هستند. آنها مجموعه‌ای از قوانین و بهترین پرکتیس‌ها هستند که باید هنگام طراحی ساختار کلاس‌ها رعایت شوند. آنها از کجا می‌آیند؟ همانطور که در بالا هم اشاره کردم از سمت پیشگامان توسعه چابک مانند عمو باب!اصول SOLID در طراحی کلاس‌های برنامه‌نویسی شی‌گرابیایید این اصول را یکس یکی بررسی کنیم. آنها عبارتند از:1- فقط یک مسئولیت: یک کلاس باید یک کار را انجام دهد و بنابراین باید تنها یک دلیل برای تغییر داشته باشد. 2- باز ـ بسته بودن: کلاس ها باید برای تمدید باز و برای اصلاح بسته باشند. 3- جایگزینی Liskov: کلاس‌های فرعی باید بتوانند با کلاس‌های پایه خود جایگزین شوند.4- تفکیک اینترفیس‌ها: تعداد بیشتری از اینترفیس‌های خاص کلاینت بهتر از تنها یک اینترفیس عمومی هستند. مشتریان نباید مجبور شوند تا عملکردی را که به آن نیاز ندارند پیاده‌سازی کنند.5- وابستگی معکوس: کلاس‌های ما باید به جای کلاس‌ها و توابع مشخص به اینترفیس‌ها و یا کلاس‌های انتزاعی وابسته باشند.آیا می‌خواهید در مورد آنها بیشتر بدانید؟ پس، این مقاله را بخوانید: https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/ شما دیگر برنامه‌نویسی شی‌گرا را دنبال نمی‌کنید؟ اوکی؛ پس مواردی را پیدا کنید که در کد زدن به سبک شما کار می‌کنند (این خیلی آسان است، چون ما در عصر ChatGPT زندگی می‌کنیم!) و آنرا در Team Agreement خود با دولوپرها قرار دهید. شما فقط باید راهی پیدا کنید تا Cohesion بیشتر و Coupling کمتری در کدهای خود داشته باشید. اکنون، اوضاع بهتر به نظر می‌رسد. همه می‌توانند کد ریویو کنند و دیگر هیچ پاشنه آشیلی برای شکست (منظورم ابرقهرمانان است!) وجود ندارد! بیایید ستون ریویو را از برد کانبان تیم خود حذف کنیم! در مورد چک کردن لاجیک‌ها؟ من معتقدم که آنها چندان مهم نیستند! بیایید با یونیت تست‌ها به خدمت‌شان برسیم.موفق باشید! چابکی یافتن کاری است که باید انجام شود! نسخه انگلیسی نوشتار: https://medium.com/@omid.mojabi/code-review-a-problem-to-solve-9455ba202729 امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Sat, 02 Sep 2023 01:15:41 +0330 https://virgool.io/@omid_mojabi/leap-of-faith-vspdqj4yn4cf ممکن است شما هم راجع به The Leap Of Faith شنیده باشید. اولین چالش بعد از فهمیدن کانتکست، صحبت کردن راجع به آن برای مردمی به یک زبان دیگر (برای ما می‌شود فارسی‌زبانان) هست. این نوشتار از جاستین کاستلی در این خصوص در سال 2020 منتشر شده و مطالعه آن خارج از لطف نیست.پذیرش ریسک می‌تواند ترسناک باشداگر شکست بخوریم چه می‌شود؟ دیگران چه فکری خواهند کرد؟ پیامدهای مالی آن چه خواهند بود؟ اگر هرگز نتوانیم خودمان را از نا امید ناشی از آن رهایی بخشیم چه؟اما اگر موفق بشویم چه؟واقعا اگر موفق شویم چه؟ چیزی که در طرف دیگر پذیرش یک ریسک قرار دارد که می تواند زندگی ای باشد که هرگز در خواب هم نمی‌دیدیم، یا حتی بهتر از آن، زندگی‌ای باشد که به شدت خواهان آن هستیم اما از دنبال کردنش می‌ترسیم.ناشناختهبخشی از ترسی که افراد را از ریسک کردن باز می‌دارد ناشناختگی است. با هر تصمیمی متغیرهای ناشناخته‌ای به وجود خواهند آمد. اما از طریق برنامه‌ریزی می‌توان بسیاری از متغیرهای دخیل در تصمیم را شناسایی و به آنها رسیدگی کرده و میزان ریسک را کاهش داد.برای اینکه به ریسکی که باید درباره آن تصمیم بگیریم بهتر بتوانیم فکر کنیم. شاید بد نباشد که آن را به عنوان یک جهش سرنوشت‌ساز (The Leap Of Faith) در نظر بگیریم. تصور کنید قرار است از یک صخره به صخره دیگری بپرید. بدون برنامه‌ریزی، فاصله بین دو صخره به قدری زیاد است که احتمال عبور شما از سمت دیگر بسیار کم است. اما با برنامه‌ریزی، همزمان که متغیرهای تاثیرگذار در تصمیم به پریدن را شناسایی و برای آنها برنامه‌ریزی می‌کنید، انگار به به طور جادویی شروع به نزدیکتر کردن دو صخره به هم کرده و فاصله بین آنها را قابل کنترل می‌کنید و شانس پرش با موفقیت را بسیار افزایش می‌دهید.اینگونه است جهش سرنوشت‌ساز ما می‌تواند بسیار کوتاه تر و کمتر ترسناک تر شود و احتمال موفقیت افزایش یابد.یک نمونه از دنیای واقعیاخیراً، با یکی از مشتریان RLS Wealth در مورد فرصتی که برای اون به مثابه یک ریسک است، گفتگو کردم که پتانسیل تغییر اساسی زندگی او را هم از نظر مالی و هم از جنبه عاطفی داشت. در ظاهر، به نظر می‌رسید که ریسک بزرگی باشد. او می‌باید از درآمد شش رقمی خود چشم‌پوشی می‌کرد و نزدیک به 40 درصد از حقوق خود را از دست می‌دهد. هرچند با وجود کاهش درآمد، بودجه ماهانه او تنها تحت تأثیر چند صد دلار در هر ماه می‌بود چون او از شهری گران قیمت به Midwest (منطقه مرکزی در غرب آمریکا) نقل مکان می‌کرد که در آن اجاره و خرید املاک و مستغلات مقرون به صرفه‌تر هستند. در واقع بخش خوبی از کاهش درآمد با کاهش اجاره بها جبران می‌شد.متغیر اول (که احتمالا ترسناک‌ترین آنها بود) را مورد بررسی قرار دادی و آنقدرها هم که در ابتدا به نظر می‌رسید پیامدهایش شدید نبود. به همین دلیل به سرعت به سراغ متغیرهای دیگری رفتیم که تحت تأثیر این تصمیم قرار می‌گرفتند و رسیدگی به همه آنها آسان بود. شغل کنونی او شغلی نبود که از آن لذت می‌برد (فاقد رضایت و هیجانی است که فرصت شغلی جدید برای او فراهم می‌کرد)؛ شهر فعلی او شهری نیست که از زندگی در آن لذت ببرد و حتی دورکاری و ضعیت کاری هیبرید ناشی از COVID-19 به وضعیت کمک چندانی نکرده بود. شهر جدید او به خانواده‌اش نزدیکتر بود و دوستان نزدیکش در آنجا زندگی می‌کنند، و همانطور که قبلاً گفتم، مقرون به صرفه‌تر است. متغیرهای بیشتری وجود داشت که ما در مورد آنها بحث کردیم و همزمان که در مورد هر کدام بحث می‌شد، صخره‌ها از دو طرف به هم نزدیک‌تر می‌شدند.البته فقط به این دلیل که ما فاصله را برای "جهش ایمان" یا "جهش سرنوشت‌ساز" او کوتاه کرده‌ایم، هیچ تضمینی وجود ندارد که همه چیز طبق برنامه پیش برود. هنوز ممکن است فرصت جدید به نتیجه‌ای نرسد، اما ما قبلاً در مورد یک پلن B بحث کرده‌ایم. بدترین سناریو این است که او به شغل مشابهی که در حال ترک آن است بر می‌گردد، اما در شهری که حداقل از زندگی در آن لذت می‌برد و پادش آرامش بخش این جهش این است که او از شانس پشیمان شدن و فکر کردن به «چه می‌شد اگر...» برخوردار می‌شود. بهترین سناریو هم این است که او کاری را که دوست دارد انجام دهد، به ایجاد یک کسب و کار جدید کمک کند، در ازای ریسکی که کرده پاداش مالی ببیند و زندگی کامل و شادی داشته باشد. اگر از من بپرسید ارزش ریسک کردن دارد.کوتاه کردن جهش سرنوشت‌ساززندگی قرار است زنده بودن باشد. به عبارت بهتر معنای آن تجربه کردن و ریسک کردن است. قطعا برخی از ریسک‌ها ارزش قبول کردن ندارند، اما برخی می‌توانند به ایجاد زندگی مورد نظر ما (زندگی که لیاقت آن را داریم) کمک کنند. ریسک‌های تصمیمات مهم زندگی خود را ارزیابی کنید، برنامه‌ای برای پرداختن به متغیرها بسازید، در مورد نتایج احتمالی و نحوه برخورد با آنها صادق باشید و اعداد و ارقام را به هم بزنید. دو صخره را به هم نزدیکتر کنید، جهش را کمتر ترسناک کنید و بهترین شانس را برای موفقیت به خود بدهید. شما لیاقتش را دارید!منبع: https://www.rlswealth.com/blog/calculated-risks امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Mon, 24 Jul 2023 16:31:46 +0330 https://virgool.io/@omid_mojabi/artificial-intelligence-is-transforming-our-world-rwvetwdllgne شیوه ساخت هوش مصنوعی در حال حاضر توسط گروه کوچکی از متخصصان فناوری تصمیم گیری می‌شود. از آنجایی که این فناوری زندگی ما را متحول می‌کند، باید همه ما اشتیاق داشته باشیم که نسبت به موضوعات آن آگاه و درگیر بشویم. در این مقاله به پیامدهای چنین رویکردی در تحول دیجیتال پرداخته می‌شود.این مقاله برگردان مقاله اصلی با عنوان «هوش مصنوعی در حال تغییر دنیای ماست – این دیگر به ما بستگی دارد که مطمئن بشویم آیا به درستی پیش می‌رود یا خیر» به قلم مکس روزر ـ بنیانگذار و سردبیر دنیای ما در دیتا ـ می‌باشد.چرا باید به توسعه هوش مصنوعی اهمیت داد؟ به این فکر کنید که فناوری ها و دستاوردهای جایگزین شده با AI چگونه خواهند بود؟ اگر ما مردم نسبت به جنبه‌های آن آگاه نشده و درگیر نشویم، در واقع تصمیم گیری در مورد اینکه چگونه این فناوری دنیای ما را متحول خواهد کرد را به چندیت کارآفرین و مهندس و متخصص واگذار می‌کنیم. وضع موجود ما الان به همین صورت است. تنها تعداد کمی از افراد در چندین شرکت فناوری، که مستقیماً روی هوش مصنوعی (AI) کار می کنند، درک می کنند که این فناوری چقدر قدرتمند شده است. اگر بقیه افراد جامعه پای کار نیایند نشوند و به وضعیت فعلی خود به عنوان تماشاگر بسنده کنند، این جمع کوچکی از نخبگان هستند که تصمیم می‌گیرند چگونه این فناوری زندگی ما را تغییر دهد. برای تغییر وضعیت فعلی، می‌خواهم به سه سئوال در این مقاله پاسخ دهم:چرا جدی گرفتن چشم‌انداز دنیایی که توسط هوش مصنوعی متحول شده است دشوار است؟چگونه می‌توانیم چنین دنیایی را تصور کنیم؟با قدرتمندتر شدن این فناوری چه چیزی به خطر می‌افتد؟چرا جدی گرفتن چشم‌انداز دنیایی که توسط هوش مصنوعی متحول شده است دشوار است؟به شیوه‌ای باید آشکار باشد که چگونه فناوری می‌تواند جهان را به طور اساسی متحول کند. به نظر فقط کافی است که بتوانیم ببینیم که تا این لحظه دنیا چقدر تغییر کرده است. اگر بتوانید خانواده‌ای از اجداد انسان شکارچی بیست هزار سال پیش را در پرواز بعدی خود دعوت کنید، آنها بسیار شگفت زده خواهند شد. فناوری در حال حاضر دنیای ما را تغییر داده است، بنابراین باید انتظار داشته باشیم که دوباره هم بتواند اتفاق بیفتد. اما در حالی که قبلا هم شاهد تغییر جهان بودیم، شاهد این بودیم که این دگرگونی‌ها به صورت تدریجی و در طول نسل‌های مختلف به وقوع پیوسته است. آنچه اکنون متفاوت است این است که این تغییرات تکنولوژیکی بسیار سریع‌تر شده‌اند. در گذشته، فناوری‌هایی که اجداد ما در دوران کودکی خود استفاده می‌کردند، هنوز در دوران پیری در زندگی آنها نقش اساسی داشت. این مورد دیگر برای نسل های اخیر عملا وجود ندارد. به جای آن، خیلی بیشتر با فناوری‌هایی مواجه هستیم که در دوران جوانی بسیار بعید و دور از تصور بوده‌اند و در زندگی نسل بعدی بسیار عادی می‌شوند.این اولین دلیلی است که ممکن است به خاطر آن آینده را چندان جدی نگیریم: به راحتی می‌توان سرعتی را که فناوری می‌تواند جهان را تغییر دهد دست کم گرفت.دلیل دوم جدی نگرفتن هوش مصنوعی متحول کننده - به طور بالقوه حتی هوش مصنوعی به اندازه انسان‌ها - این است که بسیاری از آنها از ایده‌هایی آغاز شده‌اند که نخستین بار در سینما با آنها مواجه شده‌ایم. به همین دلیل برای بسیاری از ما تعجب آور نیست که اولین واکنش به سناریویی که در آن ماشین‌ها قابلیت‌های انسان‌مانندی دارند، مانند این است که از ما خواسته باشید آینده‌ای را جدی بگیریم که در آن خون‌آشام‌ها، گرگ‌نماها یا زامبی‌ها در کره زمین پرسه می‌زنند! اما این چیزهای فانتزی و اغلب علمی ـ تخیلی می توانند در زندگی ما یا فرزندان‌مان به وقوع بپیوندند.سومین دلیل برای جدی نگرفتن این چشم‌انداز احتمالا بعید، عدم درک این نکته است که هوش مصنوعی قدرتمند می‌تواند منجر به تغییرات بسیار بزرگ ش.د. این هم قابل درک است. ایجاد ایده‌ای در مورد آینده‌ای که بسیار متفاوت از زمان خودمان باشد برای ما انسان‌ها دشوار است. دو مفهوم وجود دارد که به نظر من در تصور آینده‌ای بسیار متفاوت با هوش مصنوعی مفید است. بیایید به هر دوی آنها نگاهی بیاندازیم.چگونه می‌توان ایده‌ای در مورد اینکه هوش مصنوعی در آینده به چه شکلی ظاهر می‌شود ایجاد کرد؟زمانی که به آینده هوش مصنوعی فکر می‌کنم، توجه به دو مفهوم مختلف به ویژه مفید است: هوش مصنوعی در سطح انسان و هوش مصنوعی متحول کننده. اولی قابلیت‌های هوش مصنوعی را برجسته می‌کند و آن‌ها را به معیاری آشنا متصل می‌کند، در حالی که هوش مصنوعی متحول کننده بر تأثیری که این فناوری بر جهان خواهد داشت تأکید می‌کند.در موقعیت امروزی‌مان، بسیاری از اینها ممکن است علمی ـ تخیلی به نظر برسند. بنابراین، شایان ذکر است که اکثر کارشناسان هوش مصنوعی که مورد بررسی قرار گرفته‌اند، معتقدند که شانس واقعی برای توسعه هوش مصنوعی در سطح انسان در دهه‌های آینده وجود دارد و برخی هم معتقدند که این هوش مصنوعی بسیار زودتر وجود خواهد داشت.مزایا و معایب مقایسه هوش ماشین و انسانیکی از راه‌های فکر کردن به هوش مصنوعی در سطح انسان، مقایسه آن با وضعیت فعلی فناوری هوش مصنوعی است. در حالی که سیستم‌های هوش مصنوعی امروزی اغلب دارای قابلیت‌هایی شبیه به بخش خاص و محدود ذهن انسان هستند، یک هوش مصنوعی در سطح انسانی، ماشینی است که قادر به انجام همان طیفی از وظایف فکری است که ما انسان‌ها قادر به انجام آن هستیم. همانطور که نوریگ و راسل در کتاب درسی خود در مورد هوش مصنوعی بیان کرده‌اند، این هوش ماشینی آن است که "می‌تواند انجام هر کاری را که انسان می‌تواند انجام دهد را بیاموزد."در مجموع، طیف توانایی‌هایی که هوش را مشخص می‌کند، به انسان توانایی حل مشکلات و دستیابی به اهداف مختلف را می‌دهد. بنابراین یک هوش مصنوعی در سطح انسانی، سیستمی است که می‌تواند تمام مشکلاتی را که ما انسان‌ها می‌توانیم حل کنیم را حل کند و وظایفی را که انسان امروزی انجام می‌دهد، انجام دهد. چنین ماشینی، یا مجموعه‌ای از ماشین‌ها، می‌تواند کار یک مترجم، یک حسابدار، یک تصویرگر، یک معلم، یک درمانگر، یک راننده کامیون یا کار یک تاجر در بازارهای مالی جهان را انجام دهد. همچنین مانند انسان‌ها قادر به انجام تحقیقات علمی و توسعه فناوری‌های جدید بر اساس آنها خواهد بود.مفهوم هوش مصنوعی در سطح انسان دارای مزایای واضحی است. استفاده از آشنایی با هوش خودمان به عنوان مرجع، راهنمایی‌های روشنی را در مورد چگونگی تصور قابلیت‌های این فناوری به ما ارائه می‌دهد. با این حال، معایب آشکاری نیز دارد. تثبیت تخیل سیستم‌های هوش مصنوعی آینده به واقعیت آشنای هوش انسانی این خطر را به همراه دارد که تفاوت‌های واقعی بین آنها را پنهان می‌سازد. برخی از این تفاوت ها آشکار است. به عنوان مثال، سیستم‌های هوش مصنوعی حافظه عظیمی از سیستم‌های رایانه‌ای خواهند داشت که ظرفیت ذخیره‌سازی اطلاعات در برابر آن کمرنگ می‌شود. تفاوت آشکار دیگر سرعتی است که ماشین می‌تواند اطلاعات را جذب و پردازش کند. اما ذخیره‌سازی اطلاعات و سرعت پردازش تنها تفاوت ها نیستند. حوزه‌هایی که ماشین‌ها از قبل از انسان‌ها بهتر عمل می‌کنند، به‌طور پیوسته در حال افزایش است: در شطرنج، پس از تطابق با سطح بهترین بازیکنان انسانی در اواخر دهه 1990، سیستم‌های هوش مصنوعی بیش از یک دهه پیش به سطوح فوق‌انسانی هم رسیدند. در بازی های دیگری مانند بازی‌های استراتژیک پیچیده، اخیراً این اتفاق افتاده است.این تفاوت ها به این معناست که هوش مصنوعی که حداقل به خوبی انسان‌ها در هر حوزه‌ای که به کار گرفته شود، در کل بسیار قدرتمندتر از ذهن انسان خواهد بود. بنابراین حتی اولین "هوش مصنوعی در سطح انسانی" از بسیاری جهات کاملاً فوق بشری خواهند بود. هوش انسانی از جهات دیگر نیز استعاره بدی برای هوش ماشینی است. طرز فکر ما اغلب با ماشین‌ها بسیار متفاوت است و در نتیجه خروجی ماشین‌های متفکر می‌تواند برای ما بسیار بیگانه و غیرقابل درک باشد.گیج‌کننده‌ترین و نگران‌کننده‌ترین آنها راه‌حل‌های عجیب و غیرمنتظره‌ای است که هوش ماشینی با دنبال کردن‌شان می‌تواند از کار بیفتد. تصویر تولید شده توسط هوش مصنوعی از اسب در زیر مثالی را ارائه می‌کند: از یک طرف، هوش مصنوعی می‌تواند کاری را انجام دهد که هیچ انسانی نمی‌تواند انجام دهد - تصویری از هر چیزی، به هر سبکی (در اینجا فوتورئالیستی)، در عرض چند ثانیه - اما از سوی دیگر. می‌تواند به گونه‌ای شکست بخورد که هیچ انسانی شکست نمی‌خورد. هیچ انسانی این اشتباه را مرتکب نمی‌شود که یک اسب را با پنج پا بکشد.تصویر اسب تولید شده با AIبنابراین تصور یک هوش مصنوعی قدرتمند در آینده به عنوان موجودی با توانایی برابر با یک انسان دیگر احتمالاً اشتباه خواهد بود. تفاوت‌ها ممکن است آنقدر زیاد باشد که نامیدن آنها به عنوان سیستم‌هایی در «سطح انسانی» اشتباه به نظر برسد.هوش مصنوعی متحول کننده با تأثیری که این فناوری بر جهان خواهد داشت تعریف می‌شوددر مقابل، مفهوم هوش مصنوعی متحول کننده مبتنی بر مقایسه با هوش انسانی نیست. این مزیت را دارد که مشکلاتی را که مقایسه با ذهن خود ما ایجاد می‌کند، کنار بگذارد. اما این عیب را دارد که تصور اینکه چنین سیستمی چگونه به نظر می‌رسد و چه سطحی از توانایی‌ها را دارد دشوارتر است. این امر مستلزم آن است که ما بتوانیم دنیایی را با بازیگران باهوشی تصور کنیم که به طور بالقوه بسیار متفاوت از خودمان هستند. هوش مصنوعی متحول کننده با هیچ قابلیت خاصی تعریف نمی‌شود، بلکه با تاثیری که در دنیای واقعی خواهد داشت، قابل درک کردن است. برای واجد شرایط بودن به عنوان یک مقوله تحول آفرین، محققان آن را به صورت هوش مصنوعی در نظر می گیرند که "به اندازه کافی قدرتمند است تا ما را به آینده‌ای جدید و از نظر کیفی متفاوت ببرد".در تاریخ بشریت، دو مورد از این تحولات بزرگ وجود داشته است: انقلاب کشاورزی و انقلاب صنعتی. تبدیل شدن به هوش مصنوعی یک واقعیت در این مقیاس خواهد بود. مانند ظهور کشاورزی در ده هزار سال پیش، یا گذار از تولید دستی به ماشینی در دوقرن پیش. رویدادی که جهان را برای میلیاردها نفر در سراسر جهان و کل مسیر آینده بشریت تغییر خواهد داد. فناوری‌هایی که اساساً نحوه تولید طیف وسیعی از کالاها یا خدمات را تغییر می‌دهند، فناوری‌های «همه منظوره» نامیده می‌شوند. دو رویداد دگرگون‌کننده قبلی ناشی از کشف دو فناوری همه‌منظوره به‌ویژه مهم بود: تغییر در تولید مواد غذایی با گذار بشر از شکار و جمع‌آوری به کشاورزی، و ظهور ماشین‌سازی در انقلاب صنعتی. بر اساس شواهد و استدلال های ارائه شده در این مجموعه در مورد توسعه هوش مصنوعی، من معتقدم که این امر قابل قبول است که هوش مصنوعی قدرتمند می‌تواند معرفی یک فناوری همه منظوره قابل توجه مشابه باشد.تایم لاین سه رخداد متحول کننده در تاریخ بشریتآینده هوش مصنوعی در سطح انسانی یا متحول کنندهاین دو مفهوم ارتباط نزدیکی با هم دارند، اما یکسان نیستند. ایجاد یک هوش مصنوعی در سطح انسانی مطمئناً تأثیر متحول کننده‌ای بر دنیای ما خواهد داشت. اگر کار بیشتر انسان‌ها بتواند توسط یک هوش مصنوعی انجام شود، زندگی میلیون‌ها نفر تغییر می‌کند. با این حال، برعکس این موضوع صادق نیست. ممکن است بدون توسعه هوش مصنوعی در سطح انسانی شاهد هوش مصنوعی متحول شده باشیم. از آنجایی که ذهن انسان از بسیاری جهات یک استعاره ضعیف برای هوش ماشین‌ها است، ممکن است قبل از توسعه هوش مصنوعی در سطح انسانی، هوش مصنوعی متحول کننده را توسعه دهیم. بسته به اینکه چگونه این اتفاق می‌افتد، این ممکن است به این معنی باشد که ما هرگز هیچ هوش ماشینی را نخواهیم دید که هوش انسانی برای آن قابل مقایسه باشد.پیش‌بینی اینکه چه زمانی و به چه صورتی سیستم‌های هوش مصنوعی ممکن است به هر یک از این سطوح برسند، البته دشوار است. در مقاله دیگری در مورد این پرسش، مروری بر آنچه محققان در این زمینه در حال حاضر معتقدند ارائه داده‌ام. بسیاری از کارشناسان هوش مصنوعی بر این باورند که شانس واقعی برای توسعه چنین سیستم‌هایی در دهه‌های آینده وجود دارد و برخی معتقدند که این سیستم‌ها خیلی زودتر وجود خواهند داشت.با قدرتمندتر شدن هوش مصنوعی چه چیزی به خطر می‌افتد؟تمام نوآوری‌های تکنولوژیکی منجر به طیفی از پیامدهای مثبت و منفی می‌شوند. برای هوش مصنوعی، طیف نتایج ممکن - از منفی‌ترین تا مثبت‌ترین - فوق العاده گسترده باشد. اینکه استفاده از فناوری هوش مصنوعی می‌تواند باعث آسیب شود واضح است، زیرا در حال حاضر اتفاق افتاده است. سیستم‌های هوش مصنوعی زمانی که افراد به طور مخرب از آن‌ها استفاده می‌کنند می‌توانند باعث آسیب شوند. به عنوان مثال، هنگامی که از آنها در کمپین‌های انتخاباتی با انگیزه سیاسی برای نشر اطلاعات نادرست استفاده می‌شود یا در جایی که برای فعال‌سازی نظارت و کنترل به صورت گسترده استفاده می‌شود.اما سیستم‌های هوش مصنوعی زمانی که متفاوت از آنچه در نظر گرفته شده عمل می‌کنند یا شکست می‌خورند و یا می‌توانند باعث آسیب ناخواسته شوند. به عنوان مثال، در هلند، مقامات از یک سیستم هوش مصنوعی استفاده کردند که به دروغ ادعا می کرد که حدود 26 هزار تن والدین ادعاهای تقلبی برای دریافت مزایای مالی مراقبت از کودکان داشته‌اند. اتهامات نادرستی که سختی بسیاری از خانواده‌های فقیرتر و نارضایتی آنها را به همراه داشت و متعاقب آن منجر به استعفای دولت هلند در سال 2021 شد.با قدرتمندتر شدن هوش مصنوعی، تأثیرات منفی احتمالی می‌تواند بسیار بزرگتر شود. بسیاری از این خطرات به درستی مورد توجه عموم قرار گرفته‌اند: هوش مصنوعی قوی‌تر می‌تواند به جابجایی انبوه نیروی کار یا تمرکز شدید قدرت و ثروت منجر شود. همچنین اگر آنها در خدمت حکومت‌های دیکتاتوری خودکامه باشند، می‌توانند به توتالیتاریسم از طریق مناسب بودن برای نظارت و کنترل توده‌ای قدرت بخشند.انچه که اصطلاحا مشکل همسویی (alignment problem) هوش مصنوعی نامیده می‌شود یک خطر شدید دیگر است. اینکه هیچ کس نتواند یک سیستم هوش مصنوعی قدرتمند را کنترل کند، در وضعیتی که هوش مصنوعی اقداماتی را انجام دهد که به ما انسان‌ها و یا به کل بشریت آسیب برساند. متأسفانه این خطر کمتر مورد توجه عموم قرار گرفته است، اما توسط بسیاری از محققان برجسته هوش مصنوعی به عنوان یک خطر بسیار بزرگ تلقی می‌شود.چگونه ممکن است یک هوش مصنوعی از کنترل انسان فرار کند و در نهایت به انسان آسیب برساند؟ریسکی که اینجا وجود دارد این نیست که یک هوش مصنوعی خودآگاه شود، نیت بدی ایجاد و عملی شدن آن را دنبال کند. خطر اصلی این است که ما سعی می کنیم به هوش مصنوعی دستور دهیم که هدف خاصی را دنبال کند - حتی یک هدف بسیار ارزشمند - اما در مسیر تحقق آن هدف به انسان‌ها آسیب برسد. این سناریو در مورد پیامدهای ناخواسته است. هوش مصنوعی آنچه را که ما به او گفته بودیم انجام می‌دهد، اما نه آنچه را که ما می‌خواستیم انجام شوند.آیا نمی‌توانیم به هوش مصنوعی بگوییم که این کارها را انجام ندهد؟ قطعا ساختن یک هوش مصنوعی امکان پذیر است که از هر مشکل خاصی که پیش بینی می کنیم جلوگیری کند، اما پیش‌بینی همه پیامدهای ناخواسته مضر احتمالی دشوار است. همانطور که استوارت راسل، محقق هوش مصنوعی می گوید، مشکل هم ترازی یا هم‌سویی به دلیل «عدم امکان تعریف اهداف واقعی انسان به طور صحیح و کامل» به وجود می‌آید.آیا نمی‌توانیم در چنین وضعیت با دنبال کردن نتایج کار به طریقی فقط هوش مصنوعی را خاموش کنیم؟ این نیز ممکن است امکان پذیر نباشد. این به این دلیل است که یک هوش مصنوعی قدرتمند دو چیز را می‌داند: با خطر خاموش کردن آن توسط انسان‌ها روبرو می‌شود و پس از خاموش شدن نمی‌تواند به اهداف خود دست یابد. در نتیجه، هوش مصنوعی یک هدف بسیار اساسی را دنبال خواهد کرد که اطمینان حاصل شود که خاموش نخواهد شد. به همین دلیل است که وقتی متوجه می‌شویم یک هوش مصنوعی بسیار هوشمند در تعقیب یک هدف خاص باعث آسیب ناخواسته می‌شود، ممکن است خاموش کردن آن یا تغییر عملکرد سیستم امکان‌پذیر نباشد.این خطر - که بشریت ممکن است نتواند پس از قدرتمند شدن هوش مصنوعی در کنترل خود باقی بماند و این ممکن است منجر به یک فاجعه شدید شود - درست از روزهای اولیه تحقیقات هوش مصنوعی بیش از 70 سال پیش شناخته شده است. توسعه بسیار سریع هوش مصنوعی در سال‌های اخیر، یافتن راه‌حلی برای این مشکل را بسیار ضروری‌تر کرده است.من سعی کردم برخی از خطرات هوش مصنوعی را خلاصه کنم، اما یک مقاله کوتاه فضای کافی برای پرداختن به همه سئوالات ممکن نیست. به خصوص در مورد بدترین خطرات سیستم‌های هوش مصنوعی، و آنچه که اکنون می‌توانیم برای کاهش آنها انجام دهیم، توصیه می‌کنم کتاب «مشکل همسویی» نوشته برایان کریستین و بنجامین هیلتون «جلوگیری از فاجعه مرتبط با هوش مصنوعی» را بخوانید.اگر بتوانیم از این خطرات اجتناب کنیم، هوش مصنوعی متحول کننده نیز می‌تواند به پیامدهای بسیار مثبتی منجر شود. پیشرفت در علم و فناوری برای بسیاری از تحولات مثبت در تاریخ بشریت بسیار مهم بوده است. اگر نبوغ مصنوعی بتواند نبوغ ما را تقویت کند، می‌تواند به ما کمک کند تا در بسیاری از مشکلات بزرگی که با آن روبرو هستیم پیشرفت کنیم: از انرژی پاک‌تر، تا جایگزینی کارهای ناخوشایند و حتی مراقبت‌های بهداشتی و درمانی بسیار بهتر.این تضاد بسیار بزرگ بین پیامدهای مثبت و منفی احتمالی، روشن می‌کند که خطرات با این فناوری به‌طور غیرعادی زیاد است. کاهش خطرات منفی و حل مشکل همسویی می تواند به معنای تفاوت بین آینده ای سالم، شکوفا و ثروتمند برای بشریت – (و یا نابودی آن) باشد.چگونه می‌توانیم مطمئن شویم که توسعه هوش مصنوعی به خوبی پیش می‌رود؟اطمینان از اینکه توسعه هوش مصنوعی به خوبی پیش می‌رود نه تنها یکی از حیاتی‌ترین پرسش‌های عصر ما، بلکه احتمالاً یکی از حیاتی‌ترین پرسش‌های تاریخ بشریت است و به منابع عمومی (بودجه عمومی، توجه عمومی و مشارکت عمومی) نیاز دارد. در حال حاضر، تقریباً تمام منابعی که به هوش مصنوعی اختصاص داده شده اند، با هدف سرعت بخشیدن به توسعه این فناوری هستند. از سوی دیگر، تلاش‌هایی که با هدف افزایش ایمنی سیستم‌های هوش مصنوعی انجام می‌شوند، منابع مورد نیاز خود را دریافت نمی‌کنند. در یک تحقیق انجام گرفته توسط Toby Ord در سال 2020 بین 10 تا 50 میلیون دلار برای کار برای رفع مشکل هم ترازی هزینه شده‌اس. سرمایه گذاری هوش مصنوعی در شرکت‌ها در همان سال بیش از 2000 برابر بیشتر بود و به 125 میلیارد دلار رسیده بود. این فقط در مورد مشکل هم سویی هوش مصنوعی صدق نمی‌کند. کار بر روی طیف وسیعی از پیامدهای اجتماعی منفی ناشی از هوش مصنوعی در مقایسه با سرمایه‌گذاری‌های کلان برای افزایش قدرت و استفاده از سیستم‌های هوش مصنوعی، منابع کمتری به خود اختصاص داده است.برای کل جامعه ناامید کننده و نگران کننده است که کار ایمنی هوش مصنوعی به شدت نادیده گرفته شده و بودجه عمومی اندکی به این زمینه تحقیقاتی حیاتی اختصاص می یابد. از سوی دیگر، برای هر فردی این غفلت به این معنی است که اگر اکنون خود را وقف این مشکل کنند، شانس خوبی برای ایجاد یک تفاوت مثبت دارند و در حالی که حوزه ایمنی هوش مصنوعی کوچک است، منابع خوبی را در مورد آنچه که می‌توانید انجام دهید اگر می‌خواهید روی این مشکل کار کنید، ارائه می‌کند.وقتی فرزندان ما به امروز ما نگاه خواهند کرد، تصور می‌کنم درک اینکه چقدر توجه و منابع کمی به توسعه هوش مصنوعی ایمن اختصاص داده‌ایم برایشان دشوار خواهد بود. امیدوارم در سال‌های آینده این تغییر کند و ما شروع به تخصیص منابع بیشتری برای اطمینان از توسعه هوش مصنوعی قدرتمند به‌گونه‌ای کنیم که به نفع ما و نسل‌های بعدی باشد. اگر نتوانیم این درک گسترده را توسعه دهیم، آنگاه این نخبگان کوچک باقی خواهند ماند که این فناوری را تأمین مالی و ایجاد می کنند که تعیین خواهد کرد چگونه یکی از - یا به طور قابل قبول - قدرتمندترین فناوری در تاریخ بشر، جهان ما را متحول خواهد کرد.این پست با همین عنوان پیشتر در اجایل ورس هم منتشر شده است: https://agileverse.io/articles/article/artificial-intelligence-is-transforming-our-world مقاله اصلی: https://ourworldindata.org/ai-impact امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Sat, 24 Jun 2023 14:42:56 +0330 https://virgool.io/@omid_mojabi/article-agility-is-in-back-to-nature-c6yjgolc4dmc گیاهان هم در مواقع حساس فریاد می‌زنند ـ عکس انتخابی از یورونیوزپیش‌درآمد: یک پژوهش دانشگاهی که به تازگی انجام شده نشان داده که گیاهان هم مانند سایر جاندارن در مواجهه با موقعیت‌های تنش‌زا صداهایی از خود تولید می‌کنند که حتی می‌توان آن‌ها را از فاصله چندمتری شنید (به شرط اینکه مسلح به گیرنده‌ای در باند فرکانسی محدوده جیغ زدن آنها باشیم!) و نوع این صدا با نوع اتفاقات آن روز آنها مطابقت دارد! این در حالی است که در دنیای ماشینی شده بشری، ما همه روزه در محیط‌های کسب و کار با میل عمیق افراد به گریز از مکالمه مستقیم داشتن با همکاران و عدم شفافیت مواجهیم! ذهن بشر چنان دچار پیچیدگی ناخواسته ناشی از انفجار اطلاعاتی عصر حاضر شده است که به صورت یک رویکرد سیستماتیک در خرج کردن زمان برای گفتگو و تعامل داشتن هم میخواهد صرفه‌جویی داشته باشد! این در حالی است که بیش از دو دهه هست که همه چارچوب‌های کاری چابک و همسایگان آنها بر اهمیت ارتباطات کاری تاکید می‌کنند.اخیرا و برای پرهیز از افتادن به دام این بلای خانمان سوز در تیم‌های نرم‌افزاری به همکارانم پیشنهاد کرده بودم هر زمان که hands off شده‌اند (به هر دلیلی) بدون فوت وقت سایر اعضای تیم را مطلع کنند. برای اینکه این اکشن جالب به نظر برسد و هم تیمی‌ها انجامش بدهند هم دست به دامن شوخ طبعی شدم و به شکلی من در آوردی گفتم که این پرکتیس اسمش "پترن جیغ" هست! و ما برای اجرای آن موظفیم هر زمان که کاری که در دست اقدام داریم از ریل خارج شد، بلند جیغ بزنیم (در حالت مجازی پوک، منشن، نوتیس یا هر چه اسمش را دوست دارید بنامید) تا سایرین مطلع بشوند. این پیشنهاد خوشبختانه با استقبال همکارانم مواجه شده و این پرکتیس را همچنان هم در تیم‌ها دنبال می‌کنیم؛ چون واقعا کمک می‌کند تا با مطلع شدن تیم راجع به بلاکرها فرصت واکنش به موضوع را در زمان مقرر داشته باشیم و از به وجود آمدن Waste ها پرهیز کنیم. ارتباطات کاری‌مان را هدف‌مند و در راستای اهداف هر ریتم کاری تنظیم کنیم و یک هوشمندی تیمی داشته باشیم.یک شب وقتی در حال مرور اخبار بودم، کاری که معمولا شب‌ها قبل از خواب انجام می‌دهم، با موضوع یافته علمی تازه مبنی بر اینکه گیاهان هم به وقت دشواری فریاد می‌زنند مواجه شدم؛ ناخودآگاه به این فکر افتادم که با وجود آنکه انقلاب‌های صنعتی و بعد از آن عصر دیجیتالی به ما امکانات زیادی برای بهینه کردن وضعیت زندگی داده اما در عوض چقدر موارد بنیادی مهمی را هم از دست داده‌ایم که برای داشتن آنها باید back to basic کنیم و جالب تر اینکه بسیاری از این basic ها در طبیعت ما و جهان طبیعی ما هستند و ما شدیدا مجازی شده و غرق در اوهام تکنولوژی مهارت به یاد آوردن و به کار بستن آنها را باید مثل یک پرکتیس از نو بسازیم و دنبال کنیم! پنداری که چابکی در ذات طبیعت ماست و ما مثل گمشدگانی هستیم که دقیقا معلوم نیست از کجای کار راه را اشتباه رفته‌ایم و الان باید در سودای بازگشت به مسیر درست باشیم!این مطلب پیشتر در اجایل‌ورس منتشر شده است:https://agileverse.io/articles/article/article-agility-is-in-back-to-natureهمچنین نحوه چگونگی تولید صدا توسط گیاهان را می‌توانید در این گزارش از یورونیوز ملاحظه بفرمایید:https://parsi.euronews.com/2023/04/01/scientists-say-plants-respond-with-scream-when-stressed-because-of-dehydration-or-cut امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Sun, 09 Apr 2023 15:43:05 +0330 https://virgool.io/@omid_mojabi/article-success-metric-scrum-master-xfbq8bwmngw5 یکی از کارهای دشوار تشخیص این است که آیا به عنوان یک اسکرام مستر موفق عمل کرده ایم یا خیر؟ در این نوشته برای این دغدغه تلاش کرده ام یک متریک قابل اندازه گیری بیابم و با همفکران چابک کار به اشتراک بگذارم.راهنمای اسکرام توضیحات خوبی در خصوص نحوه‌ای که اسکرام مستر می‌تواند به سه گروه دولوپرها، مالکان محصول و سازمان‌ها خدمت‌رسانی کند را بولت‌وار بر شمرده که معمولا سرنخ‌های خوبی به خود مربیان می‌دهد که در چه حوزه‌هایی باید تاثیرگذار باشند و کاری را مستقیما به دست بگیرند. اما ایرادی هم که اینجا مطرح است این است که هیچ کمیت قابل اندازه‌گیری از میزان موفقیت آنها در ماموریت‌شان به عنوان اسکرام مستر به آنها نمی‌دهد. همین مبهم بودن سقف انتظارات از مربیان به سازمان‌ها اجازه داده تا شرح شغل‌ها و به قول امروزی‌ها KPI های رنگارنگی به زعم خودشان برای ارزیابی عملکرد اسکرام مسترها بسازند که معمولا به تقلیل دادن این شغل به کسری از انتظارات واقعی از مربی منجر می‌شود و بعضا ممکن است به چالش مربی با تفکر مدیریتی حاکم بر سازمان بیانجامد.به عنوان یک اسکرام مستر که بیش از سه سال به صورت اختصاصی در سازمان‌های متنوعی با کسب و کارهای متفاوت مشغول به همکاری بوده‌ام همیشه به دنبال یافتن راهی برای آگاهی از میزان تاثیرگذاری خودم به عنوان مربی هستم. پیشتر گمان میکردم گرفتن فیدبک‌های فردی و یا جمعی به صورت 360 درجه که در بسیاری از سازمان‌ها مرسوم است راه خوبی برای سنجش موفقیت اسکرام مستر باشد اما واقعیت این است که اگر این فیدبک‌ها را حتی اگر به هنگام و نه در زمان ترک شغل جمع‌آوری کنیم نهایتا بازتابی از افکار دیگران در خصوص منش ما، رفتار ما و افورت‌های شخص خود ما هستند و نه شغل ما مربیان و لزوما همه آدم‌ها نمی‌توانند درک کامل و دقیقی از خدمات یک مربی داشته باشند که منجر به ارائه فیدبک ارزشمند بشود؛ اگر اینطور باشد با جمعی آرمانی مواجه هستیم که آنها را نیازی به هیچ مربیگری نیست.من گمان میکنم اگر تلقی‌های نادرست سازمان‌ها و مدیران را کنار بگذاریم هنوز نیاز هست زاویه دید خودمان به موضوع را هم تغییر بدهیم. به نظر می‌رسد به جای تکیه به سرویس‌هایی که به افراد مختلف قرار است بدهیم و تلاش برای ساختن متریک‌های مرتبط با آن خدمات، بهتر است چند قدم به عقب‌تر برویم و به این فکر کنیم که چرا در راهنمای اسکرام پنج‌گانه‌ای به عنوان ارزش‌های اسکرام مطرح شده و در طول سالیان متمادی که تجارب مختلف منجر به تغییر بخش‌های زیادی از این راهنمای مربیان شده این قسمت از آن همچنان دست نخورده باقی مانده است. معتقدم پاسخ ما در ارزش‌های اسکرام نهفته است.هر دستاوردی در راستای تحقق ارزش‌های پنجگانه تعهد، تمرکز، باز بودن، احترام گذاشتن و شجاعت که انجام داده باشیم می‌تواند متریک خوبی برای ارزیابی نتیجه کارهای ما مربیان بوده باشد. من یکی را بر می‌شمرم تا موضوع روشن‌تر شود؛ کار کردن در محیطی که من به عنوان یکی از کارکنان تعهد نشان می‌دهم و با تمرکز وظایف محوله را به همراه همکارانم با بهترین تلاشم دنبال می‌کنیم، در عین حال اختیار عمل داریم و همه چیز دیکته شده نیست و اگر جسارتی که به خرج داده‌ایم برای بهبود اوضاع به جای شماتت و بازخواست مورد احترام قرار می‌گیرد؛ این باعث می‌شود تمایلم برای ترک آن سازمان کاهش یابد. متریک ما همینجا بر اساس همین فرض ساخته شده‌است!اگر به عنوان یک مربی با تیمی همکاری می‌کنیم و نرخ خروج نیروهای کاری از آن تیم در اثر همکاری با ما نسبت به گذشته کاهش چشمگیری یافته است یعنی ما داریم به عنوان یک مربی، کمینه‌ای از انتظارات را برآورده می‌کنیم. نه اینکه خیلی دقیق باشد این متریک اما از آنجا که خوشبختانه ارزش‌های اسکرام هیچ کدام قابل مکانیزه شدن نیستند و تماما در حوزه نگرش و تفکر انسان‌ها جای گرفته‌اند، تحقق آنها اثرگذاری عامل انسانی که در آن مشارکت داشته را برجسته می‌نماید. نظر شما چیست؟منبع: https://www.agilevers.com/articles/article/article-success-metric-scrum-master امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Wed, 17 Aug 2022 17:56:06 +0430 https://virgool.io/@omid_mojabi/%DA%A9%D8%AF%D8%A7%D9%85-%D8%B3%D9%84%D8%A7%D8%AD-%D8%AF%D8%B1-%D8%AF%D8%B3%D8%AA-%D8%B4%D9%85%D8%A7%D8%B3%D8%AA-%D9%88-%D8%A8%D8%A7-%D8%A2%D9%86-%DA%86%D9%87-%D9%85%DB%8C-%DA%A9%D9%86%DB%8C%D8%AF-j0rgtbdm5nci تقابل محیط بان با شکارچی غیرمجاز در منطقه حفاظت شدهسی و یکم جولای سال ۲۰۰۷ مصادف با تاسیس اتحادیه جهانی رنجرها (محیط بانان) به عنوان روز جهانی محیط بان (world ranger day) نامگذاری شده‌است. روز جهانی محیط بان یادآور فداکاری‌ها و از خود گذشتگی‌های افرادی است که جان خود را در راه حفاظت از گنجینه‌های طبیعی جهان به خطر انداخته و در این راه کشته یا زخمی شده‌اند. ما در دنیای پیچیده محصولات هم با مسائل مشابهی دست به گریبان هستیم. چابکی به عنوان یک ذهنیت بخشی از طبیعت بشری است که بعد از انقلاب صنعتی و مکانیکی شدن جهان فناوری ها با عوارض و خسارات زیادی مواجه بوده است. مساله اساسی ما مربیان این است که اگر رسالتی مشابه یک محیط بان در حفظ طبیعت توسعه محصولات داشته باشیم با امکاناتی که داریم چه می کنیم؟ یکی از وظایف نانوشته ما به عنوان یک اسکرام مستر مطمئن شدن از سلامت تیم و محصول به صورت روزمره است و بلوغ عملکرد ما زمانی است که در خصوص مسائل پیش بینی نشده و گستاخی های ایادی کسب و کارها و دست اندازی هایشان به مفاهیمی چون کار تیمی، چابکی و پروداکتیویتی این مفاهیم ناب را به شیوه رنجرگونه پاسداری کنیم. نه متجاوزین را به رگبار ببندیم و نه به حال خودشان رهایشان کنیم. با متانت برشان گردانیم به جایی که آغاز کرده اند. از حصار ارزش های تیم و محصول مان حفاظت کنیم. پرکتیس ها و تجارب ما (اگر بشود آنها را به عنوان یک سلاح در نظر گرفت) با هدف کمک به حفظ طبیعت سالم محیط کار و بالندگی و رشد آن هستند.برای همه محیط بانان دنیای واقعی کشورم و دنیای پیچیده محصولاتش سلامتی و بهروزی آرزومندم امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Sun, 31 Jul 2022 20:03:03 +0430 https://virgool.io/@omid_mojabi/%D8%A7%D9%87%D9%85%DB%8C%D8%AA-%DA%AF%D9%81%D8%AA%DA%AF%D9%88-%D8%A8%DB%8C%D9%86-%D9%81%D9%86%DB%8C-%D9%88-%D9%85%D8%AD%D8%B5%D9%88%D9%84-vpwmj8ywqdi1 This week, We had a couple of meetings at the office. The purpose was to make an alignment between technical engineers and product guys on what we should do for the next 6 months. You may think, what? 6 months?! Can you consider yourselves agile and participate in this kind of delusional supervision about the complex world of products. Totally, you may be right on your point, but I had another target here and it was facilitating a tough conversation between engineers and product managers. Some moments of these long meetings were wonderful because most of my people participated actively and positively to help each other figure out challenges and unclear concerns. I hope we can contribute better in the future by using this mindset on daily basis. این هفته چندین جلسه در شرکت داشتیم. هدف این جلسات این بود که بین مهندسان فنی و مدیران محصول در مورد آنچه که باید برای شش ماه آینده انجام دهیم، هماهنگی ایجاد کنیم. ممکن است فکر کنید، چی؟ شش ماه؟! آیا می توانید خود را چابک بدانید و در اینچنین جلسات دارای دیدگاه متوهم در مورد دنیای پیچیده محصولات شرکت کنید. در مجموع، ممکن است این دیدگاه شما درست باشد، اما من در اینجا هدف دیگری داشتم و آن تسهیل یک گفتگوی دشوار بین مهندسان و مدیران محصول بود. برخی از لحظات این جلسات طولانی، واقعا فوق‌العاده بودند، چون اکثر بچه های تیم به طور فعال و مثبت برای کمک به یکدیگر و کشف چالش‌ها و نگرانی‌های نامشخص شرکت کردند. امیدوارم بتوانیم در آینده با استفاده از این ذهنیت به دست آمده در امور روزانه مشارکت بهتری در کارها داشته باشیم. #agility #technical-excellence #lean-thinking #agile #product_people امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Wed, 27 Jul 2022 09:46:00 +0430 https://virgool.io/@omid_mojabi/%D8%B3%D9%87-%D9%BE%D8%B1%D8%B3%D8%B4-%D8%A8%D8%B1%D8%A7%DB%8C-%D9%81%D9%87%D9%85%DB%8C%D8%AF%D9%86-%D8%A7%DB%8C%D9%86%DA%A9%D9%87-%D8%A2%DB%8C%D8%A7-%DB%8C%DA%A9-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86-%DA%86%D8%A7%D8%A8%DA%A9-%D9%87%D8%B3%D8%AA-mzdnvmeigume نویسنده: مایک کوهن برگردان به فارسی با اندکی تغییر به متن اصلی: امید مجابیتعداد زیادی از سازمان‌ها ادعا می‌کنند که چابک هستند. اینجا یک راه سریعی هست که بفهمیم آیا واقعا اینطور است؟ارزیابی چابک بودن یک سازمان دشوار است. یک سازمان می تواند از برخی جهات چابک باشد و در برخی دیگر نباشد. حتی اگر یک سازمان در برخی از جنبه‌های چابکی عالی به نظر برسد، ممکن است با برخی جنبه‌های دیگر آن مشکل داشته باشد. بنابراین هیچ پاسخ ساده و کاملی برای میزان چابک بودن یا نبودن یک سازمان وجود ندارد. چابکی در یک پیوستگی عمیق با وضعیت سازمان معنا پیدا می‌کند. برخی از سازمان‌ها بسیار چابک هستند، برخی دیگر نه چندان اما ممکن است در تلاش برای بهبود باشند. با این حال، داشتن یک روش سریع برای ارزیابی اینکه آیا یک سازمان حداقل نسبتاً چابک است و تلاش می‌کند تا بهتر شود مفید خواهد بود. به عنوان مثال، یک فرد جویای یک شغل ممکن است بخواهد قبل از متعهد شدن به پیوستن به آن سازمان بداند که آیا سازمانی چابک است یا خیر؟ برای کمک به چنین موقعیتی و یا موقعیت‌های مشابه، می‌خواهم مجموعه بسیار کوچکی از سئوالات را شناسایی کنم که نشان می‌دهد یک سازمان (یک شرکت یا تیم) واقعا چقدر چابک است. به همین دلیل تصمیم گرفتم خودم را به سه پرسش محدود کنم. اینکه چرا سه تا پرسش؟ و یا بیشتر و کمتر بتوان تعیین کرد دلخواه بود. اما من تعمداً تعدادی پرسش به اندازه کافی کم می‌خواستم که برای نمونه فردی که برای یک موقعیت مصاحبه می‌کند، بتواند در طول مصاحبه آنها بپرسد.ارزیابی عملکرد تیم چابکپرسش اول: تیم‌های شما هر چند وقت یک بار محصولات خود را به طور کامل integrate می‌کنند؟با طرح این سئوال، می‌خواهم بفهمم که آیا تیم‌ها کارکردهای متقابل دارند و به گونه‌ای ساختار یافته‌اند که به آنها اجازه می‌دهد تا به طور مکرر تمام کارها را انجام دهند. ابتدا به این فکر کردم که بپرسم محصولات واقعاً چقدر به مشتریان عرضه می‌شوند. اما پاسخ به آن در واقع کمتر آموزنده است، زیرا به شدت به این بستگی دارد که مشتریان چقدر حتی یک نسخه جدید را می‌خواهند. به عنوان مثال، من دوست دارم هر محصول SaaS که استفاده می‌کنم مداوما ویژگی‌های جدیدی اضافه کند (با فرض اینکه آنها ویژگی‌هایی هستند که من می خواهم و نه فقط فیچرهای باد کرده غیرضروری). آمازون که به اعتقاد من، گیرنده بیشتر هزینه‌های من در روزمره هست می‌تواند وب‌سایت خود را چندین بار در روز به روز کند و من همچنان خوشحال باشم. اما این موضوع برای مثال برای یک سازنده دستگاه تلفن همراه صادق نیست. برای مثال اگر یک آیفون جدید بخرم و اپل دو گوشی جدیدتر را در حین رانندگی‌ام به خانه از app store عرضه کند، برای من بسیار ناامیدکننده خواهد بود. بنابراین فرکانس عرضه واقعی یک محصول ممکن است چیز زیادی در مورد چابکی سازمان به من نگوید. من بیشتر به فرکانس مجتمع‌سازی آنها علاقه‌مند هستم. این به من می‌گوید که اگر مشتریان بخواهند، سازمان چقدر می‌تواند آنها را release کند.اندازه‌گیری میزان تعهد رهبری سازمان به چابکیپرسش دوم: اگر بحران یا مشکلی وجود داشته باشد که باعث شود رسیدن به یک ددلاین یا نقطه عطف برنامه‌ریزی شده دیگر امکان‌پذیر نباشد، چگونه پاسخ می‌دهید؟یکی از بهترین شاخص‌هایی که نشان می‌دهد سازمان چقدر به چابکی اعتقاد دارد، نحوه واکنش آنها در زمان وقوع بحران است. اگر به هر دلیلی تیمی نتواند به milestone توافق شده قبلی برسد، آیا پاسخ سازمان این است: «ما برای این چیز میزهای چابک وقت نداریم! آیا امکان دلیور کردن‌اش را با کمی تاخیر داریم؟» یا اینکه آیا کارمندان متوجه می‌شوند که در طی این بحران دقیق زمان آن رسیده است که چابکی را به طور کامل بپذیرند؟ پرسش درباره واکنش سازمان در خصوص شرایط بحرانی به فهم این واقعیت که آیا چابکی یک باور عمیق در آن سازمان است یا یا فقط چیزی است که رهبری آن می‌خواهد امتحان کند، کمک می‌نماید.کشف اختلالات پنهان چابکی سازمانپرسش سوم: در مورد بهترین اسکرام مستر یا مالک محصول خود به من بگوییددرخواست برای شنیدن اینکه چه کسی فکر می‌کند بهترین اسکرام مستر یا مالک محصول سازمان است، چیزهای زیادی را در مورد نحوه فکر افراد آن شرکت در مورد چابکی نشان می‌دهد. [البته اینجا منظور به دست آوردن لیستی از اسامی نیست.] وقتی در مورد بهترین اسکرام مستر بزرگ می‌پرسم، در واقع به دنبال خطوط قرمز هستم [که رد شدن از آنها نشانگر ناپختگی دیدگاه سازمان درباره چابکی است. اینکه از دیدگاه سازمان بهترین مالکان محصول و اسکرام مسترها چه ویژگی‌هایی دارند.] به عنوان مثال، آیا اسکرام مسترها در سازمان در تعداد زیادی از تیم‌ها پخش شده‌اند؟ آیا در مورد اینکه نقش اسکرام مستر باید تمام وقت باشد، جای بحث وجود دارد؟ و نظایر آن. در یکی از تجارب خودم در طرح این پرسش یکی از مدیران سازمان با خونسردی به من گفت که بهترین اسکرام مستر آنها با 20 تیم کار می‌کرد! یک خط قرمز دیگر شنیدن در مورد اسکرام مستری کردن به صورت بیش از حد دستوری یا تجویزی است. یا اینکه اگرچه سازمان مدعی استفاده از اسکرام است، اما تصمیم گرفته به مدیران پروژه اجازه دهد این عنوان را حفظ کنند به جای اینکه همه آنها را به اسکرام مستر تغییر نام دهند.همانند پاسخ‌های مربوط به یک اسکرام مستر مطلوب، زمانی که شخصی در حال توصیف یک مالک محصول عالی است، باید به آن‌ها گوش فرا داد. زمانی که در موقعیتی من خواستم دیدگاه سازمان درباره یک مالک محصول عالی را بدانم، در مورد شخصی به من گفتند که توانسته است نقش مالک محصول را «بدون اینکه بر کار واقعی او تأثیر بگذارد» به عهده بگیرد. مطمئناً این یک خط قرمز است. به طور مشابه، من امیدوار هستم که درباره مالک محصولی بشنوم که به جای جلسات Planning و Review، با تیم‌ها در طول اسپرینت‌شان درگیر است. اگر چنین نباشد، یکی دیگر از چندین خطوط قرمز احتمالی آشکار شده‌است.مطمئنا پرسیدن تنها سه سئوال کافی نیست، اما می‌تواند یک شروع خوب باشداحتمالاً غیرممکن است که تنها از طریق طرح سه پرسش بتوانیم بفهمیم یک سازمان چقدر چابک است. اما با گذشت زمان برای یک مصاحبه کامل‌تر، می توانید به دیدگاه دقیق‌تری راجع به چابکی یک سازمان رسید. اما من فکر می‌کنم که پاسخ‌های این سه پرسش حداقل پایه محکمی برای یک دیدگاه در خصوص چابکی سازمان‌ها فراهم می‌کنند و می‌توانید از آنها برای تصمیم‌گیری در مورد اینکه آیا شغلی در آن سازمان انتظارات شما را از چابکی برآورده می‌کند و یا خیر بهره‌برداری کنید. من از آنها قبل از اولین تعامل با مشتریانم استفاده کرده‌ام، بنابراین می‌دانم که هنگام ورود چه انتظاراتی باید داشته باشم.شما چه سئوالاتی می‌پرسید؟نظر شما در مورد سه پرسش مطرح شده توسط من چیست؟ سازمان شما چگونه به آنها پاسخ خواهد داد؟ اگر برای ارزیابی چابکی سازمان فقط قرار باشد سه سئوال از کسی بپرسید، چه می‌پرسید؟ لطفا نظرات خود را به اشتراک بگذارید.لینک مطلب اصلی:https://www.mountaingoatsoftware.com/blog/three-questions-to-determine-if-an-organization-is-agile امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Sun, 17 Jul 2022 16:00:03 +0430 https://virgool.io/@omid_mojabi/%D8%B3%D9%88%D8%AF%D8%A7%DB%8C-%D8%AE%D9%88%D8%AF%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA%DB%8C-%D8%A2%DB%8C%D8%A7-%D8%AF%D8%B1-%D8%AD%D8%A7%D9%84-%D8%A7%D8%AE%D8%AA%D8%B1%D8%A7%D8%B9-%D9%85%D8%AC%D8%AF%D8%AF-%DA%86%D8%B1%D8%AE-%D9%86%DB%8C%D8%B3%D8%AA%DB%8C%D9%85-ep2fpqko3rda پیش درآمد: این نوشتار ترجمه‌ای از مقاله‌ای با همین عنوان و به قلم Joost Minnaar (با اندکی تغییر و تلخیص نسبت به متن اصلی) است. از دوست عزیزم سهیل صمدزاده بابت به اشتراک‌گذاری ایده و مباحثاتی که در این خصوص داشته‌ایم تقدیر و تشکر می‌کنم.ما در مورد ظهور مفهوم خودمدیریتی (Self-Management) و تیم‌های خودگردان (یا خودمدیر) در سازمان های امروزی مطالب زیادی می‌خوانیم. با وجود اینکه تیم‌های خودگردان یا خودمدیر، اخیراً خیلی مورد توجه قرار گرفته‌اند، اما اطلاق این عنوان به یک تیم پدیده‌ای تازه و بدیعی نیست. به تازگی تحقیقات آکادمیک در مورد تیم‌های خودگردان به شکل عمیقی در جریان است اما در کمال تعجب، این ایده نه پدیده تازه که قابل رصد تا 70-80 سال قبل (از سال 1941) است. آنچه که ما یافته‌ایم نشان می‌دهد مفهوم تیم‌های خودمدیر واقعاً چیز جدیدی نیست.ریشه‌های آکادمیک موضوعتقریباً از زمان تولد مطالعات و تئوری‌های سازمان مدرن، محققان درباره یک رویکرد غیرمتمرکز و دموکراتیک‌تر در اداره یک سازمان بحث کرده‌اند. حتی در دهه 1940، نظریه‌پردازان گزینه‌های دیگری به جای رویه‌ها و قوانین محدودکننده بوروکراتیک پیشنهاد کرده‌اند. ریشه‌های دانشگاهی و شواهد تجربی تیم‌های خودمدیر را می‌توان در دهه 1950 جستجو کرد، زمانی که اریک تریست (دانشمند بریتانیایی) در مقاله معروف خود با «برخی از پیامدهای اجتماعی و روانشناختی روش Longwall در استخراج ذغال سنگ» به آن اشاره نمود. پس از آن، اقدامات دیگری بر پایه ایده تریست انجام شده که به عنوان نمونه می‌توان به تجربه تیم‌های نیمه‌مستقل در دهه 1970 در کشورهای حوزه اسکاندیناوی، تیم‌های خودمدیریتی در کارخانه صنایع غذایی آمریکایی Gaines Dog در دهه 1980 و سازمان‌های خودگردان مانند Morning Star ، Zappos ، Valve، FAVI، Haier، Handelsbanken و Buurtzorg در انتشارات جدیدتر اشاره کرد.در مطالعات و مقالات قدیمی‌تر، محققان طرفدار این ایده هستند که سازمان‌ها باید ساختار مدیریتی خود را با تبدیل شدن به تیمی دونده متشکل از کارکنان (Worker-run) از طریق حذف سرپرستان غیرضروری و سایر کارکنان اداری کاملاً تغییر دهند. این جمله به طور خاص در مقاله‌ای از پروفسور جیمز بارکر (منتشر شده در سال سال 1993) با عنوان «محکم کردن قفس آهنین، کنترل همزمان در تیم‌های خودگردان» آمده‌است. اگرچه بیش از دو دهه از انتشار این مقاله گذشته است، اما به طرز مشکوکی مانند توصیه‌های صاحب نظران امروزی حوزه مدیریت به نظر می‌رسد. آیا اینطور نیست؟در مقاله مشهور بارکر حتی پای از این هم فراتر گذاشته شده و تأکید شده‌است: «به جای اینکه توسط یک سرپرست به کارکنان گفته شود که چه کاری انجام دهند، کارمندان خودمدیر باید خودشان اطلاعات لازم را جمع آوری و ترکیب کرده، بر اساس آنها عمل نموده و مسئولیت جمعی اقدامات انجام شده را بر عهده بگیرند».احیای یک مفهوم قدیمیهمانطور که توسط بارکر نشان داده شده، ظهور تیم‌های خودمدیر در ادبیات حوزه مدیریت را می‌توان به عنوان تلاشی برای احیای مفاهیم تیم‌های خودمدیریتی باستانی بهتر توصیف کرد. مفاهیم توصیف شده توسط بارکر با مفاهیم و نوشته های مدرن و امروزی مدیریت خیلی همراستا به نظر می‌رسند.در رابطه با ساختار (Structure)کارکنان تیم خودمدیر معمولاً در تیم‌های 10 تا 15 نفری سازمان که وظایف و مسئولیت‌های سرپرستان پیشین خود را بر عهده دارند، سازمان یافته‌اند. اعضای تیم برای انجام هر وظیفه که کار نیاز داشته باشد آموزش متقابل دارند و همچنین اختیار و مسئولیت تصمیم‌گیری‌های اساسی لازم برای تکمیل عملکرد را دارا هستند.در رابطه با عملکرد (Function)معمولاً یک تیم خودمدیر مسئولیت تکمیل یک کار خاص کاملاً مشخص شده (تولیدی یا خدماتی) را بر عهده دارد. اعضای تیم همراه با انجام وظایف خود، برنامه‌ریزی لازم برای انجام کارها را انجام می‌دهند، ملزومات و پیش‌نیازها را سفارش می‌دهند و هماهنگی‌های لازم را با سایر گروه‌ها انجام می‌دهند.در رابطه با رهبری (Leadership)مدیریت ارشد سازمان اغلب چشم‌انداز شرکتی مبتنی بر ارزش را برای تیم‌ها فراهم می‌کند و اعضای تیم از آن برای استنباط پارامترها و فرضیات (هنجارها و قواعد) استفاده می‌کنند تا اقدامات روزمره آنها در جهت تحقق ارزش هدایت شود. اعضای تیم خودگردان با هدایت چشم‌انداز (Vision) سازمان، کار خود را هدایت کرده و با دیگر بخش‌های شرکت هماهنگ می‌شوند.در رابطه با نتایج (Outcomes)علاوه بر رهایی از برخی قید و بندهای بوروکراتیک و صرفه‌جویی در هزینه مدیران میانی، اداره شرکت‌ها و سازمان‌ها به صورت خودمدیریتی انگیزه، بهره‌وری و تعهد کارکنان را افزایش می‌دهد. کارمندان نیز به نوبه خود به سازمان و موفقیت آن متعهد می‌شوند.این ادعاها زمانی مدرن‌تر به نظر می‌رسند که نویسنده ادعا می‌کند: «تیم‌های خودگردان با اجازه دادن به کارکنان برای مدیریت خود در گروه‌های کوچک، پاسخگو، بسیار متعهد و بسیار سازنده، تولید بیشتر برای سازمان‌ها را به ارمغان آورده آنها را رقابتی‌تر می‌کنند.»اختراع مجدد سازمان چرخمتعاقب این تلاش‌ها، فشار برای ایجاد ساختارهای تخت سازمانی در ادبیات تجاری دهه‌های 1980 و 1990 به نوعی وسواس تبدیل شد. محققان دانشگاهی، به همراه مشاوران تأثیرگذار تجاری (نظیر پیتر دراکر و تام پیترز) از خوانندگان خود خواستند که بوروکراسی‌زدایی را در بنگاه‌های اقتصادی خود شروع کنند. حدود سه دهه پیش، این محققان سیلی از نظرات و مقالات آکادمیکی را منتشر کردند که در خصوص عواقب ساختارهای سازمانی بروکراتیک و سلسله مراتبی خبر می‌داد و همه آنها طرح‌های سازمانی انسان محور را که براساس ساختارها و روش‌های چابک ساخته شده بودند پیشنهاد می‌دادند که بحث اصلی آنها این بود که با قطع بوروکراسی و قوانین مترتب ناشی از آن، سازمان‌ها می‌توانند سلسله مراتب را مسطح کرده، هزینه‌ها را کاهش، بهره‌وری را افزایش و سرعت پاسخگویی به تغییرات دنیای کسب و کار را افزایش دهند.به نظر می‌رسید که این موضوع برای سال‌ها از علاقه‌مندی‌های آکادمیک محو شده بود، اما اخیراً دوباره توسط نسل جدیدی از مبلغان به عنوان پدیده‌ای بدیع و عجیب و غریب انتخاب شده‌است. نامگذاری تیم‌های خودمدیر به عنوان یک پدیده تازه و نو کاملاً بی‌معناست، زیرا نشان داده‌ایم که این مفهوم به صورت آکادمیک کاملاً پایه‌ریزی شده و مدت‌ها مطرح بوده‌است. اما آنچه تغییر کرده این است که این مفهوم در حال حاضر با دید بیشتری و به عنوان یک جریان اصلی در سازمان‌ها تمرین می‌شود. این چیزی است که ما با خوشحالی بیشتر و بیشتر شاهد آن در شرکت های Bucket List (اشاره به گروهی از پیشگامان، شورشیان و انقلابیون متشکل از سازمان‌ها، کارآفرینان، دانشگاهیان و رهبران تجاری که وضعیت موجود ناامید کننده را تغییر می‌دهند) که از آنها بازدید کرده‌ایم هستیم. با این وجود، باید به صورت شفاف گفته شود که بسیاری از سازمان‌های خودگردان امروزی نه تنها سازمان خود، بلکه به همان اندازه چرخ را نیز از نو اختراع می‌کنند!منبع: https://corporate-rebels.com/reinventing-the-wheel امید مجابی (یک اجایلیست) امید مجابی (یک اجایلیست) Tue, 16 Feb 2021 18:32:14 +0330