https://virgool.io/feed/@ali.khabbaz14 fa 2026-04-15 02:08:50 https://files.virgool.io/upload/users/122888/avatar/OVevhc.jpg?height=120&width=120 https://virgool.io/@ali.khabbaz14 https://virgool.io/@ali.khabbaz14/%D8%B1%D9%88%D8%B4%D9%87%D8%A7%DB%8C%DB%8C-%DA%A9%D9%87-%D8%A8%D9%87-%D9%86%D8%B8%D8%B1-%D9%85%D9%81%DB%8C%D8%AF-%D9%87%D8%B3%D8%AA%D9%86%D8%AF-%D9%88-%D8%B1%D9%88%D8%B4%D9%87%D8%A7%DB%8C%DB%8C-%DA%A9%D9%87-%D9%88%D8%A7%D9%82%D8%B9%D8%A7-%DA%A9%D8%A7%D8%B1-%D9%85%DB%8C-%DA%A9%D9%86%D9%86%D8%AF-iazfugb8hxky فرآیند پراکنده‌سازی و گردآوری (Scatter-Gather Process)یک روش رایج برای مدیریت افراد در فرآیند توسعه نرم‌افزار وجود دارد که مستلزم تلاش زیادی است تا اطمینان حاصل شود که هر فرد وظایفی را دریافت می‌کند که متناسب با استعداد، دانش، مهارت و تجربه او باشد.برای هر ویژگی جدید یا تغییر در یک محصول نرم‌افزاری، یک فرد ارشد فنی طراحی‌ای را ایجاد می‌کند که احتمال موفقیت آن بالا باشد و با معماری کلی کسب‌وکار سازگار باشد. این فرد که می‌توان او را «طراح اصلی» نامید، سپس کار را به وظایف کوچک‌تر تقسیم می‌کند که هرکدام باید توسط افراد تیم انجام شوند.معمولاً یک متخصص ارشد با در نظر گرفتن مهارت‌های تیم خود، وظایف را بر اساس توانایی‌های افراد تقسیم می‌کند. برخی دیگر کار را بر اساس اجزای نرم‌افزار تقسیم می‌کنند و سپس مشخص می‌کنند که کدام عضو تیم باید روی کدام بخش کار کند، با توجه به اینکه چه کسی آن بخش را بهتر می‌شناسد.پس از اختصاص وظایف، اعضای تیم زمانی که فهرست وظایف فعلی خود را تکمیل کردند، شروع به انجام کارهای جدید می‌کنند. در طول این فرآیند، آن‌ها در صورت نیاز از فرد ارشد سؤال می‌پرسند و در بسیاری از سازمان‌ها (اما نه همه) قطعاتی را که توسعه داده‌اند به‌صورت مستقل آزمایش می‌کنند.تمام کارها به تسک‌های (تیکت‌ها) کوچک تقسیم شده و به افراد تیم اختصاص داده می‌شود. این کار در شاخه‌های جداگانه در یک سیستم کنترل نسخه (مانند Git) انجام می‌شود و از طریق یک سیستم مدیریت تیکت (مانند Jira) پیگیری می‌شود.هنگامی که همه بخش‌ها تکمیل شده و کد بررسی شد، این بخش‌ها در یک شاخه توسعه مشترک ادغام می‌شوند. پس از آزمایش یکپارچه، کد نهایی در شاخه اصلی (trunk) یا یک شاخه انتشار (release) ادغام می‌شود.به عبارت دیگر:کار ابتدا به بخش‌های کوچکتر تقسیم می‌شود.این بخش‌ها بین اعضای مختلف تیم توزیع می‌شوند.پس از تکمیل همه بخش‌ها، آن‌ها گردآوری می‌شوند.بخش‌های نرم‌افزاری ادغام و یکپارچه‌سازی می‌شوند.کد ترکیبی آزمایش می‌شود.زمانی که راه‌حل نهایی به درستی کار کرد، مستقر (deploy) می‌شود.کار به بخش‌های کوچکتر تقسیم می‌شود، پراکنده می‌شود، و سپس گردآوری می‌شود. این سبک کاری را توسعه پراکنده-گردآوری (Scatter-Gather Development) می‌نامیم.چه چیزی در مورد آن جذاب است؟این سیستم به دلایل مختلف برای افراد جذاب است:در حالت ایدئال، انجام کارها به‌صورت موازی باید منجر به تکمیل سریع‌تر پروژه شود. افراد (اغلب) می‌توانند به‌طور مستقل کار کنند، بدون نیاز به گفت‌وگوی زیاد یا هماهنگی مداوم.بیشتر کارها، در حالت ایدئال، به‌صورت موازی انجام می‌شود.وظایف به افراد متناسب با سطح تخصصشان اختصاص داده می‌شود، که باعث استفاده بهینه از منابع می‌شود.هر فرد مسئولیت و پاسخگویی کار خود را بر عهده دارد، که این امر ارزیابی مهارت‌ها و نقاط قوت (یا ضعف) هر شخص را برای مدیریت عملکرد آسان‌تر می‌کند.در حالت ایدئال، کارها با حداکثر موازی‌سازی و سرعت انجام می‌شوند، زیرا هر وظیفه به فردی سپرده شده که می‌تواند آن را در زمان مناسب تکمیل کند. اگر تغییرات به‌خوبی طراحی شده و وظایف به‌درستی تعریف شده باشند، ترکیب نهایی تغییرات نباید دشوار یا زمان‌بر باشد.مشکلات روش پراکنده-گردآوری (Scatter-Gather)این سیستم چند مشکل قابل توجه دارد که باید به آن‌ها اشاره کرد:به جای اینکه کار به‌صورت موازی انجام شود، کار در زمان پخش می‌شود.گسترش زمانی (Time Spread):کار معمولاً به‌صورت موازی انجام نمی‌شود زیرا هر فرد یک فهرست از وظایف مرتبط با داستان‌های مختلف دارد. طول و ترتیب فهرست وظایف ممکن است برای هر فرد متفاوت باشد. این موضوع ممکن است باعث شود که کار تکمیل آن زمان بیشتری ببرد زیرا کار در فهرست‌های مختلف کاری پخش می‌شود.شکل‌گیری سیلوها (Silos Form):هر فرد معمولاً کارهایی را دریافت می‌کند که در زمینه‌ای که به‌خوبی می‌شناسد، مرتبط است. افراد تمایل دارند که دانش بسیار خاص و عمیقی از یک بخش محدود از سیستم جمع‌آوری کنند. کار معمولاً به متخصصان صف می‌شود و این موضوع باعث تاخیر در تکمیل کار می‌شود.ساخت آجر (Brick Making) (بر اساس یک داستان قدیمی که در مقاله‌ای از Huffington Post ذکر شده است):توسعه‌دهندگان به ساخت قطعات کد مشغول هستند، نه به ادغام کامل و انتشارهای مکرر.تضعیف همکاری (Collaboration Discouraged):وظایف فردی و شخصی‌سازی‌شده برای برنامه‌نویسی تیمی (ensemble programming) چندان مناسب نیستند. همچنین، از آنجا که هر توسعه‌دهنده وظیفه خود را دارد، نمی‌تواند در کار دیگری مشارکت کند بدون اینکه کار خود را در معرض خطر ناتمام ماندن قرار دهد. به همین دلیل به تخصیص وظایف فردی، "عدم تیم‌سازی" (unteaming) گفته می‌شود.توسعه‌دهندگان آنقدر مشغول هستند که وقت کافی برای همکاری ندارند. بار روی طراح اولیه (Burden on Pre-designer):رهبر تیم نه‌تنها باید طراحی را از ابتدا انجام دهد (که اغلب به‌تنهایی صورت می‌گیرد)، بلکه باید بهترین روش برای تخصیص کارها به اعضای تیم را نیز درک کند. علاوه بر این، او موظف است به تمام سؤالات مربوط به پیاده‌سازی، یکپارچه‌سازی و تحلیل کسب‌وکار در طول پیشرفت داستان پاسخ دهد.تأخیر در تست (Late Testing):ویژگی‌ها تا زمانی که تمام بخش‌های آن تکمیل نشود، به‌صورت یک جریان کامل از ابتدا تا انتها در دسترس نیستند. بنابراین، تست سرتاسری (end-to-end testing) به‌ناچار به تأخیر می‌افتد.ادغام و تست دیرهنگام به معنای شگفتی‌های دیرهنگام است. فرصت‌های از دست رفته (Lost Opportunity):اعضای تیم هم‌زمان طراحی کلی را مشاهده نمی‌کنند، بنابراین توانایی آن‌ها در شناسایی نقص‌ها یا فرصت‌ها کاهش می‌یابد.شگفتی‌های دیرهنگام (Late Surprises):هرگونه نقص در طراحی اولیه یا برداشت‌های نادرست اعضای تیم از طراحی، دیرهنگام و در مرحله ادغام نمایان می‌شود. اگر مشکلات نیاز به اصلاح داشته باشند، این اصلاحات برنامه کاری فردی را که باید نقص را برطرف کند، مختل خواهد کرد.رد شدن دیرهنگام یک کار، جریان کاری توسعه‌دهنده را مختل کرده و باعث تأخیر در انجام سایر وظایف می‌شود. وضعیت نامشخص (Obscured Status):پیشرفت کار به‌صورت پراکنده و جداگانه انجام می‌شود. چه زمانی تمام بخش‌ها شروع خواهند شد؟ چه زمانی همه بخش‌ها تکمیل می‌شوند تا بتوانیم آن‌ها را یکپارچه کنیم؟ و در نهایت، در چه زمانی از تقویم می‌توان انتظار داشت که این ویژگی به مرحله تولید برسد؟پیش‌بینی زمان تکمیل پیچیده و نامطمئن است. پیش‌بینی سخت است و سخت‌تر می‌شودشرکت‌های فعال در حوزه نرم‌افزار سعی می‌کنند با انجام تخمین‌های دقیق‌تر، مشکلات مربوط به پیش‌بینی و کیفیت را مدیریت کنند، اما این کار بی‌فایده است. مشکل پیش‌بینی‌پذیری به دلیل تخمین‌های نادرست نیست، بلکه در ذات سیستم پراکنده‌سازی و گردآوری (Scatter-Gather) نهفته است.احتمالات علیه ما هستندایده تقسیم کار بین توسعه‌دهندگانی که برنامه‌های زمانی متفاوتی دارند، باعث افزایش احتمال ریسک می‌شود.در یک سیستم پراکنده‌سازی و گردآوری، کارهای کامل توزیع نمی‌شوند، بلکه قطعاتی از کارها به افراد مختلف اختصاص می‌یابد. اگر حتی یکی از این قطعات کامل نشود، کل ویژگی غیرقابل انتشار خواهد بود.حال تصور کنید که شما یک وظیفه دارید که انجام آن در توان شماست، اما باید به‌موقع تکمیل شود. دو حالت ممکن است رخ دهد: یا کار را به‌موقع تمام می‌کنید، یا نه.اگر این کار به دو بخش تقسیم و به دو نفر محول شود، هر بخش ممکن است به‌موقع انجام شود یا نشود. برای موفقیت، هر دو بخش باید تکمیل شوند. اما اکنون سه سناریوی شکست وجود دارد (تنها بخش A انجام شود، تنها بخش B انجام شود، یا هیچ‌کدام تکمیل نشوند) و فقط یک راه برای موفقیت وجود دارد.با افزایش تعداد بخش‌های تقسیم‌شده، احتمال شکست بیشتر می‌شود و پیش‌بینی زمان اتمام کار پیچیده‌تر و نامطمئن‌تر خواهد شدتقسیم کار به دو بخش و سه سناریوی شکستاگر کار را به سه بخش تقسیم کنید، ۸ حالت ممکن برای تکمیل آن وجود دارد، اما تنها یک حالت منجر به موفقیت می‌شود.تقسیم کار به سه بخش، 8 سناریو و تنها یک حالت موفق با تقسیم کار به ۴ بخش، فقط ۱ حالت از ۱۶ حالت ممکن موفقیت‌آمیز خواهد بود.با تقسیم کار به ۵ بخش، فقط ۱ حالت از ۳۲ حالت ممکن موفقیت‌آمیز خواهد بود.هماهنگی در ترتیب انجام کارها می‌تواند به کاهش برخی از ریسک‌ها کمک کند. اگر همه روی اولین کار تمرکز کنند، سپس وقتی آن تمام شد، به سراغ کار دوم بروند، انتظار داریم که برخی از کارها به طور کامل تکمیل شوند. اگر اولویت‌های مختلفی برای افراد وجود داشته باشد، احتمالاً تمام کارها فقط نیمه‌تمام خواهند ماند.اگر قرار است ترتیب انجام کارها را هماهنگ کنیم، بهتر است که همه با هم روی کارها کار کنند، به‌خصوص روی مهم‌ترین کارها اول.مشکل در مقیاس بزرگ‌تردر سیستم scatter-gather، ویژگی‌ها مانند یک دسته کارت جابجا می‌شوند و افراد در زمان‌های مختلف بخش‌های مختلف کارها را انجام می‌دهند.هیچ فردی در تیم نمی‌داند که چه چیزی برای تکمیل ویژگی در پایان هفته یا ماه نیاز است، مگر اینکه داشبوردهایی برای هر داستان وجود داشته باشد که آن‌ها بتوانند به آن‌ها مراجعه کنند. این نیازمند هماهنگی بیشتر و نمایشگرهای اختصاصی است (اکثر ابزارها قادر به تولید چنین داشبوردی هستند).اگر همه روی همان ویژگی کار می‌کردیم، متمرکز می‌شدیم و تنها یک ویژگی فعال برای صحبت درباره آن داشتیم. با وجود بسیاری از ویژگی‌ها در حال اجرا، ممکن است افراد درباره کارهایی که قبلاً انجام داده‌ایم یا کارهایی که قرار است انجام دهیم با ما صحبت کنند (که باعث اختلال در کار فعلی می‌شود).این مشکل زمانی بیشتر می‌شود که ویژگی در سطح بالا طراحی شود و سپس میان تیم‌ها تقسیم گردد و نه فقط افراد در همان تیم. اغلب تیم‌ها اولویت‌های مختلفی دارند که باعث می‌شود احتمالاً کار نیمه‌تمام، تست‌نشده و غیرقابل‌استفاده باقی بماند.باید بدانیم که این سیستم برای مشغول بودن بهینه‌سازی شده است: توسعه‌دهندگان بسیار مشغول هستند، سخت کار می‌کنند و به‌شدت مورد استفاده قرار می‌گیرند، در حالی که بیشتر ویژگی‌هایی که روی آن‌ها کار کرده‌اند در انتظار انجام سایر بخش‌ها متوقف شده‌اند.باز هم، فقدان هماهنگی که پیشرفت را مبهم کرده و تکمیل ویژگی‌ها را به تأخیر می‌اندازد، بخشی از سیستم scatter-gather است و نه نقصی در عملکرد توسعه‌دهندگان.چه کار می‌توانیم برای پیشبرد کارها انجام دهیم؟ما می‌توانیم توسعه‌دهندگان را تحت فشار قرار دهیم تا کار را تکمیل کنند، اما چون همه آن‌ها بسیار مشغول هستند، این ممکن است باعث شود که آن‌ها از روش‌های سریع‌تری استفاده کنند که احتمالاً به خطا یا بدهی فنی منجر می‌شود و نیاز به برگشت به مرحله تست دارد.ما می‌توانیم اولویت‌بندی کارها را تغییر دهیم، اما این به این معنی است که ویژگی‌های دیگر بیشتر منتظر خواهند ماند چون کارهایشان به تأخیر افتاده است (در بهترین حالت) یا قطع می‌شود (در بدترین حالت). سیستم scatter-gather بر تقسیم تمرکز سازمان توسعه متکی است، بنابراین اگر از scatter-gather استفاده کنیم باید بپذیریم که نمی‌توانیم تمرکز واضحی را حفظ کنیم.اگر تصمیم بگیریم که به روش scatter-gather کار کنیم، باید مشکلاتی را که این سیستم به همراه دارد بپذیریم.راه‌حل جایگزیندر عوض می‌توانیم تصمیم بگیریم که به روش scatter-gather کار نکنیم.به جای تقسیم بخش‌های مختلف کار میان افراد، می‌توانیم افراد را جمع کنیم تا واحدهای کامل کاری را انجام دهند.یک تیم چندرشته‌ای می‌تواند طراحی را با هم انجام دهد و مسائل و فرصت‌ها را در طول مسیر شناسایی کند. آن‌ها همچنین می‌توانند کار را در واحدهای قابل استقرار و با ارزش انجام دهند و ادغام و تست کامل را به عنوان بخشی از فرآیند کاری عادی در نظر بگیرند.زمانی که کار از مرزهای تیم عبور می‌کند، اعضای تیم از تیم‌های مختلف می‌توانند همان ویژگی را با هم کار کنند؛ ممکن است بخشی از عملکرد پشتیبان را بسازند در حالی که عملکرد جلویی در حال ساخت است؛ شاید بخش روی دستگاه را بسازند در حالی که بخش ابری در حال ساخته شدن است. شاید هم میکروسرویس‌ها را به صورت موازی بسازند.چون فقط یک ویژگی در هر زمان در حال اجرا است و همیشه قابل اجراست، ردیابی وضعیت بسیار ساده است و زمان لازم برای تحویل کمترین حالت ممکن است. حتی اگر تیم تصمیم به تقسیم کار بگیرد، در واقع کار به صورت موازی با ارتباط پرسرعت و ادغام مکرر انجام می‌شود.چون تیم تمام کار را با هم انجام می‌دهد، نیازی نیست که یک تکنسین اصلی تمام ویژگی‌ها را از پیش طراحی و تقسیم کند.اغلب اوقات تیم‌ها با استفاده از تکنیک‌هایی مثل برنامه‌نویسی گروهی (mob programming) یا تجمع (swarming) با هم کار خواهند کرد.آیا این کار راحت است؟نه.کار فردی از کار تیمی تفکیک‌ناپذیر می‌شود که این مسئله فرآیند مدیریت عملکرد فردی را دشوار می‌کند.اشتراک دانش و بهبود شخصی به سرعت و به طور طبیعی رخ می‌دهد. در یک ربع کاری با هم، آن‌ها ممکن است بیشتر از دو سال قبل یاد بگیرند، اما چگونه می‌توان مطمئن بود که چون شما نمی‌توانید مشارکت‌های آن‌ها را از دیگر همکارانشان جدا کنید؟زمانی که یک ویژگی را یک ب74/آن‌ها ممکن است دلتنگ تنهایی و انقطاع شوند. ممکن است از کار با همکاران خود خوششان نیاید. ممکن است با مشکلات منطقه‌های زمانی روبرو شوند. ممکن است احساس کنند که زمان کمتری برای انجام کار مؤثر دارند وقتی بیشتر وقت خود را برای بحث و تبادل نظر در مورد پیاده‌سازی صرف می‌کنند تا فقط دستورالعمل‌ها را دنبال کنند. ممکن است متوجه شوند که بیشتر وقت خود را صرف یادگیری می‌کنند و کمتر تایپ می‌کنند و این ممکن است باعث احساس گناه آن‌ها شود. ممکن است دلتنگ هیجان و فشار انجام کارهای زیاد به طور همزمان شوند. ممکن است از این بترسند که ضعف‌هایشان به تیم نمایان شود. ممکن است احساس کنند که تیم سرعت آن‌ها را کم می‌کند.این مشکلات معمولاً در صورتی که ایمنی روانی کافی میان اعضای تیم وجود داشته باشد و تیم از مدیرانی که ارزش یک فرآیند سبک‌تر و همکارانه‌تر را درک می‌کنند و از مشکلات scatter-gather خسته شده‌اند، پشتیبانی شود، قابل غلبه است.باید مجموعه‌ای از مشکلاتی را که تیم شما می‌تواند تحمل کند و مجموعه‌ای از فوایدی که می‌خواهد دریافت کند، انتخاب کنید.آیا این برای شما مفید خواهد بود؟ چه کسی می‌تواند بگوید؟ بدون امتحان کردن نمی‌توانید متوجه شوید که تیم شما در فرهنگ محلی شما با چه مشکلاتی روبرو خواهد شد. با این حال، بسیاری از سازمان‌ها سیستم ساده‌تری را که در آن تیم‌ها کار را به طور کامل انجام می‌دهند، پیدا کرده‌اند که بسیار رضایت‌بخش و با ارزش برای جامعه محصول بوده است.شاید ارزش امتحان کردن را داشته باشد.ترجمه مطلبی از Tim Ottinger با عنوان The Scatter-Gather Processترجمه شده با استفاده از هوش مصنوعی علی خباز علی خباز Sun, 30 Mar 2025 17:18:29 +0330 https://virgool.io/@ali.khabbaz14/%D8%AA%D9%84%D9%87-%D8%A7%D8%B3%D8%AA%D8%A7%D8%B1%D8%AA%D8%A7%D9%BE-pchzgllogeid [ترجمه ای به کمک هوش مصنوعی از مطلبی با همین عنوان از رابرت سی مارتین]تو به یک استارتاپ جدید پیوسته‌ایتو یک موجود فوق‌العاده با استعدادهای متعدد هستیمی‌توانی ۶۰، ۷۰، ۸۰ ساعت در هفته کار کنی تا کار را به سرانجام برسانیتو یک برنامه‌نویس و طراح درجه‌یک هستیتو در دام‌هایی که دیگران گرفتارشان شده‌اند، نخواهی افتادتو مطمئن می‌شوی که این بار اوضاع فرق داردتو آن‌قدر خوب هستی که قوانین برایت معنایی ندارند... تو به فنا رفته‌ایتله استارتاپاین داستان غم‌انگیزی است که بارها و بارها شاهدش بوده‌ایم. یک برنامه‌نویس جوان، با نیت‌های عالی شروع می‌کند، تمام اصول درست را یاد می‌گیرد، تمام مهارت‌های لازم را به دست می‌آورد، و سپس در دام تله استارتاپ می‌افتد.تله استارتاپ این باور است که شرایط تو با بقیه فرق دارد – اینکه تمام چیزهایی که درباره توسعه نرم‌افزار خوب یاد گرفته‌ای، به این کار خاص ارتباطی ندارند. تو فکر می‌کنی که این اصول بعداً به کار می‌آیند، وقتی که موفق شدی، اما نه حالا. نه در این لحظه که در یک مسابقه برای موفقیت هستی.تله استارتاپ این فکر است که فاز اولیه استارتاپ فرق دارد؛ و اینکه در این مرحله، موفقیت وابسته به زیر پا گذاشتن قوانین است. این طرز فکر کاملاً احمقانه است. فاز اولیه استارتاپ، صرفاً اولین مرحله از مراحل متعدد رشد شرکت است و همان‌طور که این فاز را پیش می‌بری، فرهنگ سازمان را برای آینده شکل می‌دهی. اگر پنج سال دیگر به همان شرکت برگردی (اگر زنده مانده باشد)، می‌بینی که همان رویکردی که در مرحله اولیه داشتند، هنوز هم پابرجاست – البته شاید به جز اضافه‌کاری‌های بی‌پایان! (خنده)یک نکته ساده: اصولی که به موفقیت نرم‌افزار منجر می‌شوند، همیشه معتبرند، فارغ از اینکه در چه مرحله‌ای از کار هستی. خنده‌دار است که فکر کنی رعایت این اصول در فاز استارتاپ اهمیتی ندارد. حقیقت این است که در مرحله استارتاپ، این اصول به همان اندازه حیاتی‌اند که در هر مرحله دیگری از رشد شرکت.یکی از این اصول، توسعه مبتنی بر تست (TDD) است. هرکسی که فکر می‌کند بدون نوشتن تست می‌تواند سریع‌تر حرکت کند، سخت در اشتباه است. بله، می‌دانم که تو یک جنگجوی شکست‌ناپذیر هستی. می‌دانم که همیشه کد را بدون نقص می‌نویسی. می‌دانم که ضرب‌الاجل نزدیک است و وقت نداری که تست بنویسی. اما متأسفم برای شکست‌های پیش رویت. متأسفم که داری کُند حرکت می‌کنی و هنوز متوجه نشده‌ای. و بیشتر از آن، متأسفم که وقتی بالاخره با زحمت و تقلای زیاد به یک موفقیت نسبی دست پیدا کردی، این رفتار بدت را به‌عنوان یک روش درست تبلیغ خواهی کرد و به دیگران پیشنهاد می‌دهی. خدا به همه ما رحم کند، چون تو نخواهی کرد!از خودت بپرس: حسابدار یک استارتاپ چگونه رفتار می‌کند؟ این فرد مسئول مدیریت پول سرمایه‌گذاران است. فکر می‌کنی او هم ضرب‌الاجل دارد؟ فکر می‌کنی تحت فشار است تا گزارش‌های مالی، پیش‌بینی‌ها و جریان نقدینگی را ارائه دهد؟ فکر می‌کنی مدیران شرکت، تأخیرهای او را تحمل می‌کنند؟به تو می‌گویم که فشار کاری حسابداری که مسئول پول سرمایه‌گذاران است، خیلی بیشتر از فشار روی یک برنامه‌نویس است.حالا به رفتار او دقت کن: آیا کارهایش را دوباره بررسی می‌کند؟ آیا حسابداری دوطرفه انجام می‌دهد؟ آیا تمام قوانین و اصول را رعایت می‌کند؟ یا چون در فاز استارتاپ هستند، قوانین را زیر پا می‌گذارد؟اگر این شرکت متعلق به خودت بود و سرمایه‌ات در خطر بود، چه احساسی نسبت به حسابداری داشتی که حساب‌های مالی را بررسی نمی‌کند، سمت بدهی‌ها را نادیده می‌گیرد، و آینده شرکتت را به حساب‌هایی وابسته می‌کند که صحت‌شان را کنترل نکرده؟تو بلافاصله اخراجش می‌کردی! آن‌قدر سریع که خودش هم نمی‌فهمید چطور از شرکت بیرون انداخته شده است!آیا کد تو از صورت‌حساب‌های مالی کم‌اهمیت‌تر است؟ آیا خطاهای کد، قابل‌تحمل‌تر از خطاهای مالی هستند؟ آیا یک باگ در کد نمی‌تواند اعتبار شرکت را خدشه‌دار کند، مشتریان را از بین ببرد، و سرمایه‌گذاران را فراری دهد؟ خودت جواب این سؤال‌ها را می‌دانی. و این را هم می‌دانی: اگر حسابداران می‌توانند در یک استارتاپ، اصول خود را رعایت کنند، تو هم می‌توانی!آیا کنار گذاشتن TDD باعث می‌شود سریع‌تر پیش بروی؟ بگذار جوابی بدهم در حد واکنش کاپیتان سولو وقتی که انفجار ماه قدرتی کلینگون رخ داد و یک افسر جوان پرسید که آیا باید ماجرا را به استارفلیت گزارش کنند؟"شوخی می‌کنی؟" واقعاً شوخی می‌کنی؟نه، تو سریع‌تر نمی‌روی. بلکه کندتر می‌شوی. و دلایلش را هم خوب می‌دانی:چون دیگر نمی‌توانی کد را بازآرایی (Refactor) کنی.کد به‌سرعت فرسوده و غیرقابل نگهداری می‌شود.تغییرات جدید سخت‌تر و سخت‌تر می‌شوند.باگ‌ها بیشتر و بیشتر می‌شوند.تو مجبور می‌شوی بین باگ‌های «بحرانی» و «قابل‌قبول» تمایز قائل شوی (انگار که هیچ باگی قابل‌قبول است!).ماژول‌هایی خواهی ساخت که آن‌قدر شکننده‌اند که جرئت نمی‌کنی آن‌ها را تغییر دهی، پس آن‌ها را دور می‌زنی.و به‌جای پیشرفت، یک توده گندیده از کد خواهی ساخت که هر هفته، انرژی بیشتری برای نگهداری آن نیاز است.در نهایت، پیشرفت متوقف می‌شود. حتی ممکن است برعکس شود، وقتی که هر نسخه جدید، پر از باگ‌های جدید، ناپایدارتر از قبل، و فاجعه‌بارتر از گذشته باشد.تو این داستان را می‌دانی. اگر به‌اندازه کافی تجربه داشته باشی، شاید قبلاً هم یک‌بار در این مسیر افتاده باشی. و با این حال، تله استارتاپ همچنان فریبنده است و تو را به سمت رفتارهای مخرب، کند و فاجعه‌آمیز می‌کشاند.اگر می‌خواهی سریع باشی، اگر می‌خواهی ضرب‌الاجل‌هایت را رعایت کنی، اگر می‌خواهی موفق شوی، پس توصیه‌ای بهتر از این ندارم:به اصولت پایبند باش! تست بنویس. کدت را مرتب و تمیز نگه دار. عجله نکن!تو مسئول خونِ زندگی‌بخش استارتاپت هستی. با آن سهل‌انگارانه رفتار نکن!یادت باشد: تنها راه سریع رفتن، این است که درست بروی.منبع علی خباز علی خباز Wed, 19 Mar 2025 20:30:00 +0330 https://virgool.io/@ali.khabbaz14/%D8%A8%D9%87-%D8%B8%D8%A7%D9%87%D8%B1-%DB%8C%DA%A9%D8%B3%D8%A7%D9%86-%D8%A7%D9%85%D8%A7-%D8%A8%D8%A7-%D8%AA%D9%81%D8%A7%D9%88%D8%AA-%D9%87%D8%A7%DB%8C-%D8%B2%DB%8C%D8%B1%D8%A8%D9%86%D8%A7%DB%8C%DB%8C-chfvo4o6z65g از آنجا که شخصاً طرفدار و شیفته‌ی ادوارد اسنودن هستم، ناخودآگاه نسبت به ماتریس استیسی هم گارد داشتم. می‌دانستم اسنودن مطلبی انتقادی درباره‌ی ماتریس استیسی نوشته است، اما تا چند روز پیش انگیزه‌ی خواندنش را نداشتم.چند روز پیش که دوباره تصاویر مربوط به ماتریس استیسی را در پست‌ها دیدم، تصمیم گرفتم زمانی را صرف خواندن مقاله‌ی اسنودن کنم و برداشت‌های خود را با شما به اشتراک بگذارم.عنوان مطلب اسنودن Separated by a common language است که با لحنی کنایه‌آمیز به تفاوت‌های بنیادی این دو چارچوب اشاره دارد. در نگاه اول، ماتریس استیسی و چارچوب کینوین اسامی تقریباً مشابهی برای فضاهای مسئله ارائه می‌دهند و ممکن است به نظر برسد که تفاوت چندانی ندارند. اما بیایید این تفاوت‌های زیربنایی را دقیق‌تر بررسی کنیم:۱. تفاوت در نگاه به پیچیدگی مسائلماتریس استیسی بر یک نگاه پدیدارشناختی (Phenomenological) استوار است. به این معنا که پیچیده یا ساده بودن یک مسئله، نه بر اساس ذات آن، بلکه بر اساس میزان اطمینان و توافق افراد تعیین می‌شود. یعنی اگر گروهی یک مسئله‌ی ساده را پیچیده بپندارند، احتمال دارد از روش‌های مختص حل مسائل پیچیده برای آن استفاده کنند.در مقابل، چارچوب کینوین بر یک نگاه هستی‌شناختی (Ontological) استوار است. یعنی تلاش می‌کند مسئله را بر اساس ویژگی‌های ذاتی آن طبقه‌بندی کند، نه بر اساس درک افراد.۲. نحوه‌ی تغییر وضعیت بین دسته‌بندی‌هادر ماتریس استیسی، جابه‌جایی بین دسته‌های مسئله به‌صورت تدریجی انجام می‌شود. از آنجا که تشخیص دسته‌بندی به درک افراد بستگی دارد، با تغییر آرام اطمینان و توافق، وضعیت مسئله نیز به‌آرامی تغییر می‌کند. این درک ممکن است به اشتباه حس قابل‌پیش‌بینی بودن تغییرات در سیستم‌ها را ایجاد کند و تصور کنترل‌پذیری همه‌چیز را به همراه داشته باشد.اما در چارچوب کینوین، تغییر وضعیت دفعی است. به‌عنوان مثال، گذار از یک فضای پیچیده به یک فضای آشوب (Chaos) می‌تواند مانند تغییر فاز آب از مایع به گاز باشد، یعنی ناگهانی و با صرف انرژی دفعی اتفاق می‌افتد. این تفاوت نشان می‌دهد که کینوین نقش عدم‌قطعیت و غیرخطی بودن سیستم‌ها را بهتر در نظر می‌گیرد.۳. نقش فضای آشوب در نوآوریدر ماتریس استیسی، فضای آشوب (Anarchy) به‌عنوان یک وضعیت نامطلوب(به نوع نامگذاری فضای آشوب توجه کنید) و غیرقابل‌کنترل در نظر گرفته شده که باید از آن اجتناب کرد. این دیدگاه با توجه به زمان توسعه‌ی ماتریس استیسی (دهه ۱۹۹۰) و ارزش‌های آن دوران، که بر ثبات و کنترل تأکید داشتند، منطقی به نظر می‌رسد.اما در چارچوب کینوین، فضای آشوب (Chaos) نه‌تنها یک وضعیت منفی نیست، بلکه محیطی برای خلق نوآوری و کشف راه‌حل‌های جدید محسوب می‌شود. سازمان‌ها گاهی به‌طور عمدی برخی محدودیت‌های خود را حذف می‌کنند تا وارد فضای آشوب شوند و از دل آن راه‌حل‌های نوآورانه استخراج کنند.۴. رد استفاده از مدل استیسی توسط رالف استیسی در فازهای بعدی کارشرالف استیسی در دهه‌ی ۱۹۹۰، به‌عنوان یک اقتصاددان و استراتژیست شرکتی، ماتریس استیسی را برای تحلیل سیستم‌های سازمانی با استفاده از نظریه‌ی پیچیدگی توسعه داد. این مدل، که بر محورهای اطمینان و توافق استوار بود، برای تصمیم‌گیری‌های مدیریتی طراحی شده بود.اما در اواخر دهه‌ی ۱۹۹۰ و اوایل ۲۰۰۰، استیسی به روان‌درمانی گروهی روی آورد و تحت تأثیر نظریه‌های جامعه‌شناسی و روان‌شناسی (مانند کارهای جورج هربرت مید و نوربرت الیاس) به سمت مفهوم "فرآیندهای پاسخگویی پیچیده" (Complex Responsive Processes) متمایل شد.در این مرحله، او ماتریس اولیه‌ی خود را رد کرد، زیرا احساس می‌کرد که این مدل بیش‌ازحد ساده‌سازی‌شده و نمی‌تواند پویایی‌های پیچیده و غیرقابل‌پیش‌بینی انسان‌ها را به‌خوبی منعکس کند. به عقیده‌ی او، این ماتریس می‌توانست به تقویت رویکردهای مدیریتی سنتی و کنترل‌محور کمک کند، که با دیدگاه‌های جدیدش در تضاد بودند.جمع‌بندیماتریس استیسی به دلیل ریشه داشتن در مدیریت سنتی و محدودیت‌های اولیه‌ی علوم پیچیدگی، درک تجربی، نادرست و ناقصی از سیستم‌های پیچیده ارائه می‌دهد. در مقابل، چارچوب ساینیفین، با تکیه بر علوم مدرن و دامنه‌های مشخص، نگاه دقیق‌تر و انطباق‌پذیرتری نسبت به واقعیت‌های پیچیده‌ی سیستم‌های انسانی و سازمانی دارد.(با کمک فراوان هوش مصنوعی در درک مطالب اسنودن و ویراستاری)منبع علی خباز علی خباز Sun, 02 Mar 2025 11:28:20 +0330 https://virgool.io/@ali.khabbaz14/adjacent-possible-jchbtlty1ubv The Adjacent Possible and How It Explains Human Innovation | Stuart Kauffman | TEDبرای من پیچیدگی امر مهمی است. هر چقدر بیشتر می‌فهمم بیشتر علاقه‌مند می‌شوم. داستان از آن جایی شروع کد من به عنوان توسعه‌دهنده احساس می‌کردم قدرت کارهایی بیش از توسعه کد را دارم ولی ساختارهای بسته چیده شده بر محیط پیچیده این را بر نمی‌تابید. در نهایت به چابکی رسیدم و یکی از مبناهای اون یعنی چارچوب کینوین و تئوری های دیگر در علم پیچیدگیمطالبی که در ادامه می‌خوانید به کمک چندین بات هوش مصنوعی و با هدف آشنایی با تئوری ممکن همجوار و دنیای پیرامون خود از یکی از سخنرانی های اخیر استوارت کافمن اخذ شده است.کافمن با نقل قول از هراکلیتوس، فیلسوف یونانی باستان، که گفته بود «جهان حباب‌وار بیرون می‌جهد» صحبت خود را آغاز می‌کند. کافمن استدلال می‌کند که زیست‌کره برای چهار میلیارد سال در حال «حبابیدن» بوده است، به این معنا که دائماً چیزهای جدیدی را از طریق فرآیند ممکن همجوار ایجاد کرده است. او تأکید می‌کند که فیزیک سنتی نمی‌تواند این فرآیند خلاقانه را توضیح دهد.(اینکه چرا فیزیک سنتی نمی‌تواند خلاقیت زیست کرده در خلق چیزهای جدید را توجیه کند داستان بسیار پیچیده‌تری است که کافمن در تالیفات خود به آن اشاره کرده است)کافمن برای توضیح مفهوم حبابیدن، به نمونه‌هایی از تکامل در زیست‌کره اشاره می‌کند. او توضیح می‌دهد که حتی باکتری‌های ساده با وجود داشتن سطح صاف، می‌توانند برای باکتری‌های دیگر محیطی برای حرکت و دسترسی به غذا ایجاد کنند. این خود یک مثال از پدید آمدن امکانات جدید است. این مثال ساده نشان می‌دهد که چگونه حتی موجودات ساده مانند باکتری‌ها می‌توانند به طور تصادفی محیطی را برای یکدیگر ایجاد کنند که منجر به پدید آمدن امکانات جدید می‌شود. این امکانات جدید می‌تواند منجر به تکامل و تنوع بیشتر در زیست‌کره شود.Cambrian and Ordovician Animalsانفجار کامبریَن: کافمن به انفجار کامبریَن اشاره می‌کند که حدود 540 میلیون سال پیش رخ داده است. در این دوره زمانی کوتاه، اکثر شاخه‌های اصلی جانوری که امروزه می‌شناسیم، پدید آمدند. این انفجار نمونه‌ای از خلاقیت و نوآوری عظیم در زیست‌کره است.کافمن برای درک خلاقیت زیست‌کره، مفهوم «عملکرد» اجزای یک اندام را مطرح می‌کند. او به عنوان مثال، قلب را ذکر می‌کند و توضیح می‌دهد که عملکرد اصلی قلب، پمپاژ خون است و نه ایجاد صدا. او از این مثال برای نتیجه‌گیری در مورد ماهیت «جور کردن» (jury-rigging) در زیست‌کره استفاده می‌کند. به این معنا که موجودات زنده با استفاده از ویژگی‌های موجود، کارکردهای جدیدی را ایجاد می‌کنند.کافمن از تجربه شخصی‌اش برای توضیح مفهوم ممکن همجوار استفاده می‌کندچند سال پیش، دخترم کیفش را در یک چاه کم‌عمق انداخت. من یک چوب لباسی سیمی برداشتم، آن را روی دسته یک تی کشیدم و کیفش را بیرون کشیدم. هر چیزی را می‌توان برای بیش از یک کار استفاده کرد. این مثال نشان می‌دهد که چگونه اشیاء موجود می‌توانند با اشیاء دیگر به روش‌های جدید ترکیب شوند تا کارکردهای جدیدی پیدا کنند. چوب لباسی برای آویختن لباس طراحی شده است، اما در این مورد با دسته تی ترکیب شده تا به ابزاری برای بیرون کشیدن کیف تبدیل شود.برای مثال، یک پیچ‌گوشتی را می‌توان برای پیچاندن پیچ استفاده کرد، اما برای خراشیدن بتونه از روی دیوار هم عالی است. روی یک بلوک فلزی می‌توان 8 سوراخ ایجاد کرد و از آن موتور ساخت. در واقع یک وزنه کاغذی فوق‌العاده است و تحقیقات علمی نشان می‌دهد که گوشه‌های آن تیز است و می‌تواند یک نارگیل را بشکند.شاید بتوان از موتور 8 سیلندر برای نگه داشتن کاغذ روی میز استفاده کرد، این هم کارکردی است و شاید موجب پیدایش کارکرد دیگری شوداما اگر از بلوک موتور به عنوان وزنه کاغذی استفاده می‌کنید، آیا می‌توانید نتیجه بگیرید که می‌توان از آن برای شکستن نارگیل هم استفاده کرد؟ نه، نمی‌توانید. اما این همچنین به معنای یک چیز اساسی است. یافتن کاربری‌های جدید برای اشیاء(جور کردن)، یک محاسبه نیست. این یک استنتاج نیست. جور کردن اصلاً یک محاسبه نیست. رایانه‌ها محاسبه می‌کنند. زیست‌کره دائماً با این روش که استنتاجی نیست، در حال نوآوری است. کافمن نتیجه‌گیری می‌کند که فرآیند نوآوری در زیست‌کره شبیه به جور کردن است، یعنی یافتن کاربری‌های جدید و غیرمنتظره برای اشیاء موجود. این فرآیند با آزمون و خطا پیش می‌رود، نه با محاسبات و استنتاجات منطقی.تئوری ممکن همجوار (TAP) به عنوان ابزاری برای درک فرآیند نوآوریکافمن از نمونه‌هایی مانند تکامل فلس‌های دایناسورها به پر و لنزهای چشم که از آنزیم‌ها به وجود آمده‌اند، استفاده می‌کند تا نشان دهد چگونه چیزهای موجود می‌توانند به طور غیرمنتظره‌ای به کارکردهای جدیدی تبدیل شوند. این موضوع نشان‌دهنده ماهیت غیرقابل پیش‌بینی نوآوری در زیست‌کره است. ما نمی‌توانیم بر اساس دانش یا ریاضیات موجود (نظریه مجموعه‌ها) پیش‌بینی کنیم که زیست‌کره در مرحله بعد چه چیزی را خلق خواهد کرد. زیست‌کره یک مکانیزم ساعت‌وار با نتایج قابل پیش‌بینی نیست.تکامل فلس‌های دایناسورها به پرکافمن استدلال می‌کند که این نوآوری غیرقابل پیش‌بینی در زیست‌کره، علم را فراتر از نظریه‌های تثبیت‌شده مانند فیزیک نیوتنی، مکانیک کوانتومی و حتی انقلاب کوپرنیکی می‌برد. با وجود محدودیت‌های پیش‌بینی، کافمن تئوری‌ای به نام TAP را ارائه می‌دهد که این تئوری بر روی آمار فرآیند نوآوری تمرکز دارد تا بر نتایج خاص.فرمول تئوری ممکن همجوارممکن همجوارمول تئوری مجاورت ممکنفرمول TAP هسته اصلی تئوری ممکن همجوار (TAP) است که توسط استوارت کافمن برای توصیف و تحلیل فرآیند نوآوری در زیست‌کره و سایر سیستم‌های پیچیده ارائه شده است. در این معادله:Mt+1: تعداد چیزهای موجود در سیستم در دوره زمانی بعدی Mt: تعداد چیزهای موجود در سیستم در دوره زمانی فعلی Mi: تعداد چیزهای نوع i در سیستم Ci: تعداد ترکیبات ممکن از i چیز ai: احتمال اینکه ترکیبی از i چیز ایجاد شودشاید شما هم مثل من در ابتدا متوجه این معادله نشده باشید، پس کمی بیشتر توضیح می‌دهمMt+1: این بخش از معادله نشان می‌دهد که تعداد چیزهای موجود در دوره زمانی بعدی، مجموع تعداد چیزهای موجود در دوره زمانی فعلی و تعداد چیزهای جدیدی است که در آن دوره ایجاد شده‌اند.Mt: این بخش از معادله نشان‌دهنده تعداد پایه چیزهای موجود در سیستم است که می‌توان از آنها برای ایجاد چیزهای جدید استفاده کرد.∑(Mi)(Ci) (ai): این بخش از معادله تعداد چیزهای جدیدی را که در دوره زمانی بعدی ایجاد می‌شوند، محاسبه می‌کند. برای هر نوع i چیز، تعداد ترکیبات ممکن (Ci) ضرب در احتمال ایجاد هر ترکیب (ai) می‌شود و سپس این مقادیر برای همه انواع چیزها جمع می‌شوند.در نظر داشته باشید:احتمال (ai): احتمال ایجاد یک ترکیب جدید از چیزهای موجود به عوامل مختلفی مانند سازگاری، کارایی و تازگی آن ترکیب بستگی دارد. و همچنین فرمول TAP به طور دقیق تعداد چیزهای جدیدی را که در دوره زمانی بعدی ایجاد می‌شوند، پیش‌بینی نمی‌کند، زیرا احتمال (ai) برای هر ترکیب می‌تواند به طور قابل توجهی متفاوت باشد. با این حال، این فرمول روند کلی افزایش تعداد چیزهای موجود در سیستم را در طول زمان نشان می‌دهد.نتایج فرآیند ممکن همجوار (TAP) و انفجار نوآوری در طول زمانفرآیند TAP با افزایش بسیار کند تعداد چیزهای موجود برای مدت طولانی مشخص می‌شود. سپس، ناگهان انفجاری عظیم مانند چوب هاکی رخ می‌دهد و تعداد چیزها در مدت زمان محدودی به بی‌نهایت می‌رسد.فرآیند TAP با افزایش بسیار کند تعداد چیزهای موجود برای مدت طولانی مشخص می‌شود. سپس، ناگهان انفجاری عظیم مانند چوب هاکی(شکل نموداری تعداد چیزهای جدید تولید شده) رخ می‌دهد و تعداد چیزها در مدت زمان محدودی به بی‌نهایت می‌رسد. این شبیه انفجار کامبریَن است که در آن تنوع حیات در زمین به طور ناگهانی افزایش یافت.کافمن این الگو را در تکامل انسان نیز نشان می‌دهد. او به عنوان مثال به ابزارهای سنگی اشاره می‌کند که با گذشت زمان پیچیده‌تر شده‌اند. ابزارهای انسان اولیه (Australopithecus) بسیار ساده بودند، در حالی که انسان‌های هوشمند (Homo erectus) چندین ابزار داشتند و انسان‌های نئاندرتال (Cro-Magnon) ابزارهای سنگی بسیار پیشرفته‌ای ساختند.اختراع لوح‌های گلی، نیاز به قلم را ایجاد کردکافمن اشاره می‌کند که اختراع یک ابزار، اغلب به اختراع ابزار دیگری برای استفاده از آن منجر می‌شود. به عنوان مثال، اختراع لوح‌های گلی، نیاز به قلم را ایجاد کرد. ابزارها، جایگاه‌هایی را برای ابزارهای جدید و مشاغل جدید ایجاد می‌کنند. کافمن با اشاره به انفجار ابزار از دوران باستان تا به امروز، روند شتاب نوآوری را نشان می‌دهد. ما اکنون میلیاردها ابزار در اختیار داریم، از سوزن‌های بافندگی گرفته تا ایستگاه فضایی.کافمن نتیجه می‌گیرد که همیشه چیزهای جدیدی در ممکن همجوار وجود دارد. به محض ساخت یک ابزار، ابزار پیچیده‌تر دیگری در ممکن همجوار قرار می‌گیرد. به عنوان مثال، پس از ساخت کمان، ساخت تیر و کمان در ممکن همجوار قرار می‌گیرد. این بخش نشان می‌دهد که فرآیند ممکن همجوار منجر به انفجارهای ناگهانی نوآوری می‌شود و با گذشت زمان، سرعت نوآوری افزایش می‌یابد.شواهدی از انفجار نوآوری در طول زمان و تئوری ممکن همجوار به عنوان توضیحی برای این پدیدهاندازه سکونت‌گاه‌های انسانی در 300،000 سال گذشتهفجار ناگهانی کافمن با بررسی اندازه سکونت‌گاه‌های انسانی در 300،000 سال گذشته، نشان می‌دهد که الگوی انفجار ناگهانی نوآوری که در انفجار کامبریَن مشاهده شد، در تاریخ بشر نیز وجود دارد. برای مدت طولانی هیچ تغییری در اندازه سکونت‌گاه‌ها وجود نداشت، اما در حدود 10000 سال پیش شاهد انفجار ناگهانی در اندازه و پیچیدگی آن‌ها هستیم.انفجار GDP در دو قرن گذشتهکافمن الگوی مشابهی را در مقیاس بزرگ‌تر برای تولید ناخالص داخلی (GDP) نشان می‌دهد. او استدلال می‌کند که برای هزاران سال، GDP تقریباً راکد بود، اما در دو قرن گذشته شاهد انفجاری در این شاخص بوده‌ایم.افزایش انفجاری اختراعات در طول عمر کافمن برابر با دوره‌های زمان طولانی‌تر در گذشتهکافمن با اشاره به تجربیات شخصی خود در طول عمر 83 ساله‌اش، بر شتاب نوآوری تأکید می‌کند. او به اختراعات متعددی اشاره می‌کند که در طول عمر او اتفاق افتاده است، مانند هلیکوپتر، تلویزیون، رایانه و پلاستیک. او این را با کمبود اختراعات مشابه در دوره‌های زمانی طولانی‌تر در گذشته مقایسه می‌کند. کافمن ادعا می‌کند که فرآیند TAP یک ویژگی جالب دارد. هر بار که چیزی جدید خلق می‌کنیم، زمان انتظار برای چیز جدید بعدی نصف می‌شود. این موضوع باعث شتاب قابل توجهی در نوآوری با گذشت زمان می‌شود.کافمن نتیجه می‌گیرد که تئوری ممکن همجوار می‌تواند انفجار نوآوری مشاهده‌شده در دوران کامبریَن و همچنین شتاب نوآوری که در حال حاضر تجربه می‌کنیم را توضیح دهد. انفجار رو به بالای خط نشان‌دهنده‌ی تعداد چیزها، همان انفجار دوران کامبریَن و دوره‌ای است که اکنون در آن قرار داریم. در نتیجه شواهد متعددی از انفجارهای ناگهانی نوآوری در طول تاریخ زمین و تاریخ بشر وجود دارد و تئوری ممکن همجوار با مفهوم کاهش زمان انتظار برای نوآوری‌های بعدی، این شتاب را توضیح می‌دهد.چالش‌های ناشی از فعالیت‌های انسانی و راه‌حلی بالقوه با استفاده از تئوری ممکن همجوارتصویری نگران‌کننده از تأثیر فعالیت‌های انسانی بر سیاره زمیناثرات مخرب فعالیت‌های انسانی: کافمن هشدار می‌دهد که فعالیت‌های انسانی مانند نابودی جنگل‌ها و انتشار گازهای گلخانه‌ای در حال آسیب رساندن جدی به سیاره است. او می‌گوید که امضای انسان‌زاد (Anthropocene) به‌سرعت در حال گسترش است(1).امید در خاک نهفته است: کافمن راه‌حلی بالقوه را در بهبود سلامت خاک می‌بیند. او به اهمیت کمپوست باکیفیت مانند کمپوست جانسون-سو (Johnson-Su) اشاره می‌کند که می‌تواند منجر به استفاده کمتر از زمین، کاهش تخریب جنگل‌ها، کاهش رویدادهای انقراض و بیماری‌های همه‌گیر شود. کافمن پیشنهاد می‌کند که با حذف کودهای شیمیایی و استفاده از راه‌حل‌های زیستی مبتنی بر قارچ‌ها و باکتری‌های مفید خاک، می‌توان به بهبود خاک کمک کرد. این راه‌حل‌ها شامل پوشش دادن دانه‌ها با این جوامع میکروبی، استفاده از بیوچار (Biochar) و ترکیب آن با کودهای شیمیایی برای توزیع در سراسر زمین است. کافمن جوامع قارچی و باکتریایی موجود در خاک را مثال‌هایی از ممکن همجوار می‌داند. این جوامع می‌توانند راه‌حل‌های جدید و غیرمنتظره‌ای برای مشکلات خاک ایجاد کنند.ما می‌توانیم با استفاده از راه‌حل‌های مبتنی بر طبیعت، مانند جوامع میکروبی خاک، مشکلات فعلی را حل کنیم.کافمن با خوش‌بینی نتیجه می‌گیرد که ما می‌توانیم با استفاده از راه‌حل‌های مبتنی بر طبیعت، مانند جوامع میکروبی خاک، مشکلات فعلی را حل کنیم. او تأکید می‌کند که ما بخشی از طبیعت هستیم و نه حاکمان آن.تصویر ارائه شده شامل نموداری است که تغییرات در چندین شاخص مرتبط با عصر آنتروپوسن (Anthropocene) را در طول زمان نشان می‌دهد. این شاخص‌ها شامل:جمعیت: این نمودار نشان‌دهنده افزایش سریع جمعیت انسان در طول چند هزار سال گذشته است.جنگل‌زدایی: این نمودار نشان‌دهنده کاهش تدریجی پوشش جنگلی زمین در طول چند قرن گذشته است.تمرکز دی‌اکسید کربن: این نمودار نشان‌دهنده افزایش مداوم غلظت دی‌اکسید کربن در جو زمین در طول چند دهه گذشته است.انقراض گونه‌ها: این نمودار نشان‌دهنده نرخ فزاینده انقراض گونه‌های جانوری و گیاهی در طول چند قرن گذشته است.مصرف آب: این نمودار نشان‌دهنده افزایش مداوم مصرف آب توسط انسان در طول چند دهه گذشته است.استخراج منابع: این نمودار نشان‌دهنده افزایش مداوم نرخ استخراج منابع طبیعی مانند فلزات، سوخت‌های فسیلی و چوب توسط انسان در طول چند قرن گذشته است.فعالیت‌های ماهیگیری: این نمودار نشان‌دهنده افزایش مداوم در نرخ صید ماهی توسط انسان در طول چند دهه گذشته است.کاهش لایه ازن: این نمودار نشان‌دهنده تخریب لایه ازن زمین توسط مواد شیمیایی ساخته شده توسط انسان در طول چند دهه گذشته است.سرمایه‌گذاری در فناوری: این نمودار نشان‌دهنده افزایش مداوم سرمایه‌گذاری در تحقیق و توسعه فناوری در طول چند دهه گذشته است.انقراض گونه‌ها: این نمودار نشان‌دهنده نرخ فزاینده انقراض گونه‌های جانوری و گیاهی در طول چند قرن گذشته است.این نمودارها به طور کلی تصویری نگران‌کننده از تأثیر فعالیت‌های انسانی بر سیاره زمین ارائه می‌دهند. افزایش سریع جمعیت، جنگل‌زدایی، انتشار گازهای گلخانه‌ای، انقراض گونه‌ها، مصرف آب، استخراج منابع، فعالیت‌های ماهیگیری، تخریب لایه ازن و سرمایه‌گذاری در فناوری همگی نشان‌دهنده فشار فزاینده انسان بر محیط‌زیست هستند. کافمن در ارائه خود از این نمودار برای تأکید بر این نکته استفاده می‌کند که عصر آنتروپوسن دوره‌ای از تغییرات بی‌سابقه و سریع در سیاره زمین است. این تغییرات در حال حاضر اثرات مخربی بر آب و هوا، اکوسیستم‌ها و تنوع زیستی دارند.او هشدار می‌دهد که اگر اقدامات فوری برای کاهش تأثیر فعالیت‌های انسانی بر محیط‌زیست انجام نشود، پیامدهای این تغییرات می‌تواند فاجعه‌بار باشد. علی خباز علی خباز Tue, 14 May 2024 19:13:25 +0330 https://virgool.io/@ali.khabbaz14/striving-for-wholeness-g2nvpido33w5 ما در سازمان‌ها خود واقعی‌مان، خود حقیقی‌مان نیستیم. چرا؟چون به خطر می‌افتیم! چون دیگر شما آن فرد مطمئن که جواب همه چیز را می‌داند نیست، سازمان‌ها، فرآیندهای ارزیابی، این را مطلوب نمی‌داند و نمره منفی، در نتیجه پول، امنیت شغلی و ... متاثر می‌شود، کاهش پیدا می‌کند. این موضوع آن‌چنان در همه جا ریشه دارد که حتی با قطع کردن ارتباط ارزیابی و حقوق هم اتفاق چندانی نخواهد افتاد. همه، زنده و غیر زنده(حتی رنگ دیوار) از من و شما عملکرد بالا و با کیفیت می‌خواهد، آدم پر سوال، آدم خطرپذیر و ...هزینه دارد.حال سوال این است که بروز خود واقعی انسانها چه سودی دارد و چگونه می‌تواند اتفاق بیفتد؟ در ادامه به بررسی این موضوع خواهیم پرداخت.برای کار که لباس می‌پوشیم(چه سازمان شما یونیفرم خاصی داشته باشد چه نه): مردم اغلب احساس می کنند که باید صبح هنگام لباس پوشیدن برای محل کار، بخشی از شخصیت خود را پنهان کنند. آنها یک ماسک حرفه ای می زنند که مطابق با انتظارات محل کار است. در بیشتر موارد، به معنای نشان دادن عزم مردانه، نشان دادن اراده و قدرت است. پنهان کردن تردیدها و آسیب پذیری. در کنار ما، سازمان هم همراهی می‌کند، آنها در بیشتر موارد، به معنای واقعی کلمه، مکان‌هایی بی‌روح هستند. این مکان‌ها برای ذات عمیق ما و آرزوهای پنهان روح ما نامساعد هستند.به قول پارکر پالمر: شما می توانید یک سازمان را با تعداد دروغ هایی که برای عضویت در آن باید بگویید اندازه‌گیری کنید. یکی از موضوعاتی که در این کتاب مدام به آن می‌پردازد خودمدیریتی است. حال ربط این به آن چیست؟خودمدیریتی، ما را به انسان‌های کامل‌تری در کارمان تبدیل می‌کند. در سازمان‌های سنتی، افراد برای کسب ارتقاء، راضی نگه داشتن رئیس و کنار زدن رقبا، رقابت(یا کار) می‌کنند. این رقابت‌ها باعث ایجاد تنش و سیاست‌بازی در سازمان می‌شود. در سازمان‌های خودمدیریتی، افراد برای خود کار می‌کنند. آنها نیازی به رقابت با یکدیگر ندارند و می‌توانند با خیال راحت، خود واقعی‌شان باشند.در سازمان‌های سنتی با وجود سلسله‌مراتب انسانها وارد رابطه‌هایی ناسالم می‌شوند، این نوع رابطه‌ها، خود بودن ما را بیش از پیش سخت می‌کند، سیستمی که به ناچار شما را در قالبی فرو میبرد و دیگر خود نیستید، همان خودی که پر از سوال است، پر از شک است و پر از نوآوری می‌تواند باشد. کارپمن این رابطه‌ها را اینگونه توصیف می‌کند:مدل مثلث درام کارپمن، یک مدل اجتماعی از تعامل انسانی است که توسط استیون کارپمن، روانشناس آمریکایی، در دهه ۱۹۶۰ ارائه شد. این مدل، سه نقش اصلی را در روابط انسانی شناسایی می‌کند:آزارگر (Persecutor): فردی که احساس قدرت و کنترل می‌کند و اغلب سعی می‌کند دیگران را کنترل یا سرکوب کند.نجات‌دهنده (Rescuer): فردی که احساس مسئولیت می‌کند و اغلب سعی می‌کند دیگران را از مشکلاتشان نجات دهد.قربانی (Victim): فردی که احساس ضعف و آسیب‌پذیری می‌کند و اغلب سعی می‌کند از دیگران کمک بگیرد.این سه نقش، در یک چرخه معیوب با یکدیگر تعامل دارند. آزارگر، قربانی را آزار می‌دهد، قربانی از نجات‌دهنده کمک می‌خواهد و نجات‌دهنده، آزارگر را متوقف می‌کند. این چرخه می‌تواند در روابط شخصی، کاری و حتی درونی افراد مشاهده شود.برایان رابرتسون از زمانی صحبت می‌کند که بعد از وضع شدن هولاکراسی(شما بخوانید کمی خودمختارشدن تیم‌ها) این مثلث چگونه شکست می‌خورد: در تیمهای خودسازمان‌ده تو انتخاب می‌کنی که قربانی باشی یا انتخاب کنی و تنش‌ها رو رفع کنی. از نقش قربانی به نقش خالق حرکت کنی. میل به تغییر نقش خیلی بیشتر است، زیرا نجات‌دهنده خودت و تیمت هستی. خودت میتوانی با یک پیشنهاد در تیم، بدون وابستگی به قدرت بیرونی، سیستم را به چالش بکشی و تغییر بدی. علی خباز علی خباز Tue, 16 Jan 2024 11:46:28 +0330 https://virgool.io/HumaCulture/%DB%8C%DA%A9-%D8%A2%D8%B1%D8%B2%D9%88%DB%8C-%D8%B4%DA%A9%D8%B3%D8%AA-%D8%AE%D9%88%D8%B1%D8%AF%D9%87-jprafvmqxrg6 اسپاتیفای از "مدل اسپاتیفای" استفاده نمی‌کند و شما نیز نباید از آن استفاده کنید.پیشنهاد مترجم: خباز - مدل تیم اسپاتیفای در اسپاتیفای شکست خورد و شرکت شما را نیز شکست خواهد داد.مطلبی که در ادامه مطالعه کنید، ترجمه از مقاله ایست که منبع آن در انتها اشاره شده است، با این حال بنده به فراخور نیاز نظراتی به آن افزودم، امیدوارم مفید باشد.از میان تمام جذابیت‌های فرهنگ استارت‌آپ، سرعت و زیرکی یک تیم کوچک بیشتر خواستنی هستند. حفظ این احساس با رشد یک شرکت یک چالش است. در سال 2012، اسپاتیفای روش کار خود را به اشتراک گذاشت و پیشنهاد کرد که آن را فهمیده است.وقتی در سال 2017 برای نقش مدیریت محصول در دفتر مرکزی آن در استکهلم مصاحبه کردم ، از دیدن عملکرد مدل اسپاتیفای هیجان‌زده شدم. با این حال، استخدام‌کننده قبل از اولین مصاحبه من را غافلگیر کرد. او به من هشدار داد که انتظار نداشته باشم اسپاتیفای یک آرمانشهر چابک باشد.من پس از سه برابر شدن اندازه آن به 3000 نفر در طول 18 ماه به شرکت پیوستم. من فهمیدم که مدل معروف اسکواد فقط یک آرزو بوده و هرگز به طور کامل اجرا نشد. من شاهد هرج و مرج سازمانی بودم در حالیکه رهبران شرکت به تدریج به ساختارهای مدیریت سنتی تر منتقل می‌شدند.وقتی از همکارانم پرسیدم که چرا محتوا حذف یا به‌روزرسانی نشد تا واقعیت را منعکس کند، هرگز پاسخ خوبی دریافت نکردم. بسیاری از مردم به طعنه فکر می کردند که این پست ها برای استخدام عالی هستند. من دیگر در اسپاتیفای کار نمی‌کنم، بنابراین تجربه‌ام را به اشتراک می‌گذارم تا واقعیت را بیان کرده باشم. مدل تیم اسپاتیفای در اسپاتیفای شکست خورد و شرکت شما را نیز شکست خواهد داد.اما شما مجبور نیستید حرف من را قبول کنید.یکی از نویسندگان مدل اسپاتیفای و چندین مربی چابک که در اسپاتیفای کار می کردند، سالهاست که به مردم گفته‌اند که آن را کپی نکنند. متاسفانه، حقیقت به این سرعت یا به اندازه ایده ای که مردم می خواهند به آن باور داشته باشند، منتشر نمی‌شود.«حتی در زمانی که ما آن را نوشتیم، آن را انجام نمی‌دادیم. بخشی از جاه طلبی بود، بخشی حدس. مردم واقعاً برای کپی کردن چیزی که واقعاً وجود نداشته تقلا کرده اند.» - Joakim Sundén، مربی چابک در اسپاتیفای2011–2017 وقتی مردم به کاری که ما انجام می‌دهیم نگاه می‌کنند و فکر می‌کنند این چارچوبی است که می‌توانند آن را کپی کرده و پیاده‌سازی کنند، من را نگران می‌کند. ... اکنون ما واقعاً تلاش می کنیم تا تأکید کنیم که مشکلاتی نیز داریم. همه چیز براق نیست و همه چیز خوب کار نمی کند و همه تیم های ما فوق العاده شگفت انگیز نیستند.خلاصهاسپاتیفای تیم هایی داشت که آنها را جوخه می نامید ، زیرا به نظر جالب تر بود (شوخی نمی‌کنم). گروهی از تیم ها در بخشی به نام قبیله سازماندهی شدند . در نظر گرفته شده بود که هر تیم یک مینی استارت‌آپ مستقل باشد، با یک مدیر محصول که به‌عنوان مینی مدیرعامل برای یک منطقه ویژه عمل می‌کند. این تیم ها دارای طراحان و مهندسان نرم افزار با طیف وسیعی از تخصص ها بودند. هدف این بود که یک تیم باید تمام مهارت های لازم را بدون نیاز به تکیه بر تیم دیگری برای موفقیت داشته باشد.مدیران محصول دارای ساختار مدیریت سنتی بودند. یک مدیر محصول در یک تیم به راهبر محصول بخش خود گزارش میداد ( "رهبر قبیله" ). برای طراحان هم همینطور. با این حال مهندسان نرم افزار خارج از ساختار تیم مدیریت می شدند.رهبران چپتر . به عنوان مثال، همه مهندسان نرم‌افزاری که روی APIهای Backend در تمام تیم‌های داخل دپارتمان کار می‌کنند، یک مدیر خواهند داشت و همه مهندسان موبایل اندروید در این بخش نیز مدیر متفاوتی خواهند داشت. هدف این بود که به مهندسان اجازه داده شود تا بین تیم‌های داخل دپارتمان حرکت کنند و نیازهای تجاری را بدون نیاز به تغییر مدیران برآورده کنند.اسپاتیفای یک ساختار تیمی ماتریسی طولانی مدت با انتخاب کلمات غیرمعمول را امتحان کرد، که خوب کار نکردچرا این روش جواب ندادمدیریت ماتریسی یک مشکل اشتباه را حل کردبر استقلال تیم تاکید داشتهمکاری یک صلاحیت مفروض بودتغییر اسطوره دشوار شدمدیریت ماتریسی یک مشکل اشتباه را حل کردتیم چابک "فول استک"(فراوظیفه‌ای) به خوبی کار کرد، اما مدیریت ماتریسی مهندسین نرم افزار بیش از آنکه مشکلی را حل کند، مشکلات جدیدی را بوجود آورد. تیم‌های اسپاتیفای نسبتاً عمر طولانی داشتند و مزیت عدم نیاز به تغییر مدیر هنگام انتقال به یک تیم دیگر کوچک بود.مدیران مهندسی در این مدل مسئولیت چندانی بیشتر از پیشرفت شغلی افرادی که مدیریت می کردند، نداشتند. حتی در آن زمان، توانایی مدیران برای کمک به توسعه مهارت های بین فردی مهندسان، محدود بود. یک مدیر مهندسی به دلیل دخالت نکردن در موضوعات جاری روزانه به طور مستقل تعارض درون تیم را نیز ارزیابی نمی‌کند.بدون یک مدیر مهندسی واحد که مسئولیت مهندسان یک تیم را بر عهده داشته باشد، مدیر محصول فاقد یک همتای همرده بود - مینی CTO برابر با نقش مینی CEO خود. هیچ فرد واحدی برای خروجی‌های تیم مهندسی پاسخگو نبود و یا فردی که در قبال اولویت‌بندی کارها بتوان با او در همان رده و مسئولیت مدیر محصول مذاکره کرد.هنگامی که در تیم مهندسی اختلاف نظر وجود داشت، مدیر محصول باید با همه مهندسان تیم مذاکره می کرد. اگر مهندسان نمی توانستند به اجماع برسند، مدیر محصول باید به یک پله سطح گفتگو را ارتقا میداد و با مدیران مهندسی که تخصص های مهندسی در تیم وجود دارد، مذاکره کند. یک تیم با مهندسین برنامه های کاربردی، وب و برنامه های تلفن همراه حداقل 3 مدیر مهندسی دارد که ممکن است نیاز به مشارکت داشته باشند. اگر آن مدیران مهندسی نمی توانستند به یک اجماع برسند، موضوع یک تیم باید به مدیر مهندسی دپارتمان ارتقا پیدا میکرد.”رهبران چپتر، رهبران خدمتگزار هستند که به شما کمک می‌کنند به‌عنوان یک فرد رشد کنید. آنها واقعاً با هیچ تیمی کار نمی کنند. آنها گزارش مستقیم از همه تیم ها دارند ولی واقعاً هیچ مسئولیتی در قبال تحویل ندارند. آنها این مسئولیت را نمی پذیرند. به راحتی می توان صاحب محصول را به عنوان مدیر تیم درنظر گرفت.“ Joakim Sundén، مربی چابک در اسپاتیفایاز اشتباهات Spotify درس بگیرید:یک تیم مهندسی - محصول - طراحی معمولاً شامل مهندسان بیشتری نسبت به طراحان یا مدیران محصول است. وجود یک مدیر مهندسی واحد برای مهندسان تیم، سطح بالایی از مسئولیت را در زمان های چالش در تیم ایجاد می کند.مدیران محصول باید یک همتای مشابه برای مهندسی داشته باشند. مدیران محصول باید در قبال اولویت بندی کار پاسخگو باشند. مدیران مهندسی باید در قبال اجرای مهندسان پاسخگو باشند، که شامل توانایی مذاکره بر سر سرعت و کیفیت با مدیر محصول است.البته پیشنهاد نویسنده این مقاله مبنی بر استفاده از دو مدیر در یک تیم کوچک فراوظیفه‌ای در پاسخ به حل مشکل یک مدیر کمی عجیب است. چون با یک مدیر جوابی نگرفتیم حال امیدوار باشیم با دو مدیر به نقطه مطلوب برسیم. دیری نخواهید پایید که به تعداد مدیران بیشتر بر حسب استفاده از متخصصان دیگر در تیم مورد نیاز خواهد بود، مثلا مدیر طراحان، مدیر تحلیلگران داده و ...آیا نباید با حذف عناوینی چون مینی CEO، جلوگیری از تولد چنین موقعیت هایی در تیم، روی آوردن به مدیریت جمعی و مسئولیت در قبال تیم مسیر متفاوتی را دنبال کنیم؟پیشنهاد مترجم - خبازاسپاتیفای روی استقلال تیم متمرکز شده استوقتی یک شرکت کوچک است، تیم‌ها باید طیف وسیعی از کارها را برای داشتن خروجی انجام دهند و باید ابتکارات را مرتباً تغییر دهند. همانطور که یک شرکت از استارتاپ به‌سمت بزرگتر شدن رشد می‌کند، عملکردهای تکراری در بین تیم‌ها به تیم‌های جدیدی منتقل می‌شوند که با کاهش کارهای تکراری، کارایی سازمان را افزایش می‌دهند. با تعداد بیشتر تیم ها، نیاز یک تیم به تغییر ابتکار به تناوب کاهش می یابد. هر دوی این تغییرات به تیم‌ها اجازه می‌دهد تا عمیق‌تر و طولانی‌مدت‌تر درباره مشکلاتی که می‌خواهند حل کنند فکر کنند. با این حال، تکرار سریعتر تضمین نمی شود. هر مسئولیتی که یک تیم برای افزایش تمرکز خود واگذار می کند به یک وابستگی جدید بین تیمی تبدیل می شود.اسپاتیفای فرآیند مشترکی برای همکاری بین تیمی تعریف نکرده است. اجازه دادن به هر تیمی برای داشتن یک روش کار منحصر به فرد به این معنی است که هر تیم در هنگام همکاری به روش منحصر به فردی برای تعامل نیاز دارد و در نتیجه بهره وری کلی سازمان آسیب خواهد دید.مدل اسپاتیفای زمانی مستند شد که اسپاتیفای یک شرکت بسیار کوچکتر بود. به گفته آندرس ایوارسون، قرار بود این یک سریال چند قسمتی باشد که خودمختاری اولین قسمت آن بود، اما بخش‌های مربوط به همسویی و مسئولیت‌پذیری هرگز تکمیل نشدند.از اشتباهات اسپاتیفای درس بگیرید:استقلال نیاز به همسویی دارد. اولویت های شرکت باید توسط رهبری مشخص شود. استقلال به این معنا نیست که تیم ها هر کاری می‌خواهند انجام دهند.فرآیندهای همکاری بین تیمی باید تعریف شود. خودمختاری به این معنا نیست که تیم ها را برای خود سازماندهی هر مشکلی رها کنیم.نحوه اندازه‌گیری موفقیت باید توسط رهبری تعریف شود تا افراد بتوانند به طور مؤثر در مورد اولویت‌بندی وابستگی بین تیمی مذاکره کنند.استقلال مستلزم پاسخگویی است. مدیریت محصول نسبت به ارزش پاسخگو است. تیم، مسئول ارائه فرآورده‌های (increment) «انجام شده» است. تیم های بالغ می توانند استقلال خود را با توانایی خود در بیان ارزش تجاری، ریسک، یادگیری و حرکت بهینه بعدی توجیه کنند.«اگر بخواهم یک کار را متفاوت انجام دهم، می‌گویم که نباید آنقدر روی خودمختاری تمرکز کنیم."هر بار که یک تیم جدید دارید، آنها باید چرخ را در مورد نحوه عملکردشان دوباره اختراع کنند. شاید، فقط شاید، باید «حداقل چابکی حیاتی» (MVA) داشته باشیم. شما با آن شروع کنید. شما آزاد هستید که انصراف دهید، اما مردم نباید همیشه مجبور باشند شرکت کنند. «در چه مرحله ای این فرآیند را وارد می کنید؟ احتمالاً زمانی که خیلی دیر شده است.»- Joakim Sundén، مربی چابک در اسپاتیفای«هنریک کنیبرگ در مورد این صحبت کرد که چگونه ما در ابتکارات بزرگ آنقدر خوب نیستیم و البته هنوز هم در ابتکارات بزرگ آنقدر خوب نیستیم. «اگر روش‌های کاری متناقض دارید، جابه‌جایی برای افراد دشوارتر می‌شود. اگر جابه‌جایی برای افراد دشوارتر است، به احتمال زیاد روش‌های کار ناسازگاری دارید. این فقط تا زمانی تقویت می شود که ناگهان، شما واقعاً دیگر برای همان شرکت کار نمی کنید. شما برای این نوع خرده فرهنگ های عجیب و غریب کار می کنید.» - جیسون ییپ، مربی چابک در اسپاتیفای 2015 – زمان نگارشگمان میکنم تلاش‌های فراوانی در جهت همسویی تیم‌های مستقل تا کنون انجام شده است. یکی از این آخرین تلاشها استفاده از سطوح پروازی(Flight Levels) است. کلاس لئوپولد در دو کتاب Practical Kanban و Rethinking Agile این موضوع، یعنی همراستایی در یک تیم، بین چند تیم و در سطح کل سازمان را مورد بررسی و راهکار سبکی را برای آن نیز ارائه کرده است که مطالعه آن خالی از لطف نیست بالاخص برای کانبان دوستانپیشنهاد مترجم - خبازهمکاری یک شایستگی فرضی(خیالی) بوددر حالی که اسپاتیفای به تیم ها کنترل روش کارشان را می داد، بسیاری از افراد درک اولیه ای از شیوه های Agile نداشتند. این منجر به این شد که تیم ها از طریق بهینه سازی فرآیند با امیدی کور برای یافتن ترکیبی که به آنها کمک می کند تحویل خود را بهبود بخشد، تکرار کنند. مردم فاقد یک زبان مشترک برای بحث موثر در مورد مشکلات فرآیند، آموزش حل آنها و تجربه ارزیابی عملکرد بودند. واقعا چابک نبود . فقط آبشار نبود«مربی‌های چابک» مشاوران داخلی بودند که اسپاتیفای تیم‌هایی را برای آموزش و پیشنهاد بهبود فرآیند ارائه می‌داد. با وجود حسن نیت، مربیان کافی برای کمک به هر تیمی وجود نداشت. تعامل یک مربی با یک تیم به ندرت به اندازه ای طولانی بود که تکمیل یک پروژه را در بر می‌گرفت تا به تیم کمک کند تا عملکرد را ارزیابی کند. علاوه بر این، آنها در مورد هیچ چیز پاسخگو نبودند."کنترل بدون شایستگی هرج و مرج است."- L. دیوید مارکت، کشتی را بچرخان!ادامه این جمله به درک آن کمک می‌کند:کنترل بدون شایستگی هرج و مرج است. اگر تنها کاری که باید انجام دهید همان چیزی است که به شما گفته می‌شود، پس نیازی به درک کاری که انجام می‌دهید نیست – اما زمانی که قدرت بیشتری برای تصمیم‌گیری به شما داده می‌شود، به دانش فنی نزدیکی نیاز دارید که بر اساس آن تصمیم‌گیری کنید.پیشنهاد مترجم - خبازاز اشتباهات اسپاتیفای درس بگیرید:همکاری، مهارتی نیازمند دانش و تمرین است. مدیران نباید تصور کنند که افراد درکی از شیوه های چابک دارند.وقتی یک شرکت به اندازه کافی بزرگ شد، تیم ها برای هدایت برنامه ریزی در تیم و ساختار همکاری بین تیم ها به پشتیبانی اختصاصی نیاز دارند. مدیریت برنامه می تواند پاسخگوی فرآیند برنامه ریزی باشد. مدیران برنامه‌های اختصاصی، تیم‌ها را به شیوه‌ای مشابه کاری که مدیران محصول و مدیران مهندسی اختصاص داده با شایستگی‌های مربوطه خود انجام می‌دهند، قادر می‌سازند.تغییر اسطوره دشوار استهنگامی که Agile Scrum معانی جدیدی را به مجموعه ای از کلمات مانند burn-down و sprint معرفی کرد، این کار را به دلیل معرفی مفاهیم جدیدی انجام داد که نیاز به نام داشتند. اسپاتیفای واژگان ماموریت‌ها ، قبیله‌ها ، جوخه‌ها ، اصناف و سرنخ‌های فصل را برای توصیف روش کار خود معرفی کرد. این توهم را ایجاد کرد که چیزی را ایجاد کرده است که برای یادگیری آن انتخاب کلمات غیر عادی نیاز است. با این حال، اگر مترادف‌های غیر ضروری را از ایده‌ها حذف کنیم،(یعنی زلم زیمبو اسمهای قلمبه سلمبه رو کنار بگذاریم و این مفهوم را لخت لخت بررسی کنیم، چیزی به نام) مدل اسپاتیفای به عنوان مجموعه‌ای از تیم‌های چندکاره با استقلال بیش از حد و ساختار مدیریتی ضعیف آشکار می‌شود.گرفتارش نشو. اگر اسپاتیفای به این ایده‌ها با نام اصلی‌شان اشاره می‌کرد، شاید می‌توانست آن‌ها را در زمانی که شکست خوردند، به جای مقابله با تغییر هویت فرهنگی خود صرفاً برای یافتن فرآیندهای داخلی که به خوبی کار می‌کنند، منصفانه‌تر ارزیابی کند.از اشتباهات اسپاتیفای درس بگیرید:اکثر کسب و کارها فقط می توانند حوزه های کمی از نوآوری را حفظ کنند. فرآیند داخلی به ندرت یک حوزه اصلی نوآوری است که یک شرکت را در بازار متمایز می کند. مطالعه گذشته به کسب و کارها اجازه می دهد تا زمینه های بهتری را برای نوآوری انتخاب کنند.برای درک بهینه سازی کنید. هر چیز جدیدی که با هدف سازنده بودن در سازمان توسط افراد یادگرفته می‌شود، باید ارزش آن را ارزیابی کرد.واحدهای تجاری ، بخش‌ها ، تیم‌ها و مدیران به‌طور مؤثرتری نسبت به مترادف‌های Spotify درباره نقش‌ها و مسئولیت‌ها در ساختار سازمان ارتباط برقرار می‌کنند و به روشی وابسته نیستند که خالق آن‌ها در خود آن روش شکست خورده باشد.در عوض این کار را انجام دهید (فقط شوخی کردم. هیچ راه حل سریعی وجود ندارد.)ممکن است مدل اسپاتیفای را به این دلیل کشف کرده باشید که سعی می‌کردید نحوه ساختار تیم‌های خود را بیابید. اینجا متوقف نشوید و به تحقیق کردن ادامه دهید. رهبران شرکت هایی که در آزمون های زمان طولانی تری مقاومت کرده اند، بسیار بیشتر از وبلاگ اسپاتیفای نوشته اند. تا زمانی که انسان ها وجود داشته اند، انسان ها سعی کرده اند دریابند که چگونه با هم کار کنند. عصر صنعتی و عصر اطلاعات برخی از محدودیت‌ها را تغییر داد، اما دانشگاهیان که نظریه‌های سازمانی را مطالعه می‌کنند، به حقایقی بی‌زمان در مورد آنچه که انسان‌ها برای موفقیت در یک جمع نیاز دارند، دست پیدا کرده‌اند.مشخص شد، اسپاتیفای در سال 2012 متوجه نشده بود که چگونه سرعت و چابکی یک تیم کوچک را در یک سازمان بزرگ حفظ کند. این شرکت فراتر از مدل همنام خود تکامل یافت و برای یافتن پاسخ های بهتر به بیرون از خود نگاه کرد. شما هم باید(همین مسیر را در پیش بگیرید و به حیات سازمان‌های بیرونی بیشتر توجه کنید).چند توصیه من در رابطه با موضوعات تحت پوشش روش کار اسپاتیفای:Team Topologies توسط متیو اسکلتون و مانوئل پیسEssential Scrum اثر کنت اس روبینShape Up by Basecamp ایده های خوبی برای سازمان های زیر 150 نفر به نظر می رسد .من از نزدیک شاهد بودم که چگونه Scaled Agile Framework به Fitbit کمک کرد تا هزاران نفر را برای راه اندازی سخت افزار پیچیده هماهنگ کند. مانند هر روش دیگری، هر سازمانی تجربه موفقی با آن نداشته است.منبع: لینک علی خباز علی خباز Mon, 07 Nov 2022 18:26:00 +0330 https://virgool.io/HumaCulture/origins-of-scrum-fj6ubeguzp9w ریشه‌های ژاپنی اسکرام غیرقابل چشم‌پوشی استمقدمهخلاصه‌ای از فصل دوم کتاب اسکرام: هنر انجام دو برابر کار در نصف زمانشما در ادامه خلاصه‌ای از مهمترین نکات به همراه تفسیر بنده روبرو خواهید شد، احتمالا ایرادات شما به تفسیرهای بنده بر این کتاب خواهد بود، پس در ایراد گرفتن دست و دلباز باشید، در این فصل جف ساترلند به تجربه‌هایی که موجب شکل گیری ایده‌های اولیه اسکرام می‌شود، اشاره می‌کند و بدیهی است بنده به همه آنها که در کتاب ذکر شده است، اشاره نخواهم کردربات شش‌پایکی از تجربه‌های جالب آقای ساترلند، حضور در تیمی بوده است که این تیم در حال ساخت رباتی بوده و نحوه عملکرد اون خیلی با چیزی که الان ما از اسکرام یا فرهنگ سازمانی چابک انتظار داریم نزدیک هست و آقای ساترلند اون رو اینطور توصیف می‌کندمن دیدم که این ربات زنده می‌شود. آنها روباتی ساختند که هر یک از شش پا، مغز خود را داشتند. یک پردازنده در ستون فقرات چند قانون ساده داشت: به جلو حرکت کنید، به عقب برگردید، به پاهای دیگر برخورد نکنید. تراشه شبکه عصبی در سر ربات این قوانین را می‌دانست و به عنوان داور برای همه قسمت‌ها عمل می کرد. به پاها می گفت که وقتی به مانعی برخورد می‌کند از طریق دوربینش چه چیزی می‌بیندآنچه جالب است این است که هر بار که ربات را روشن می‌کنید، برای اولین بار راه رفتن را یاد می‌گیرد. هیچ پایگاه داده‌ای از جایی که همه چیز در اتاق است وجود ندارد. در عوض، جهان پایگاه داده آن است. چه اتفاقی می‌افتد، اگر بتوانیم مجموعه‌ای از دستورالعمل‌های ساده برای تیم‌هایی از افراد ایجاد کنیم که درست مانند آن پاها با هم کار کنند؟ آنها خود سازماندهی و خود بهینه می‌شوند، درست مانند آن ربات.شاید مطالب زیادی شنیده باشیم که اسکرام تنها در حد تیم و یا تنها در مرحله پیاده‌سازی کاربرد دارد، ولی با توجه به این پس زمینه در ذهن خالقان اسکرام، میتوان این نگاه را که من به عنوان روح اسکرام از آن یاد می‌کنم، به تیم یا فاز خاصی از خلق محصول محدود نمی‌‌‌شودبه یاد می آورم در کتاب Reinventing Organizations از سامانی نام میبرد که در اونجا پس از تغییر و تحولات به ساختاری رسیده بودند که همه سازمان از حدود 800 تیم(طبیعتاً منظورم یک گروه با تعداد کم، اعتماد بالا و هدف مشترک است) تشکیل شده بود و تمامی متخصصان، افراد ارشد و مدیران در سطح سازمان برای رفع موانع تیمها در دسترس بودندکتاب خلق دوباره سازمان‌هاسازمان چند هزار نفره بدون حتی 1 مدیرسر و کله ژاپنی ها پیدا می‌شوددر همین بین آقای ساترلند توسط یکی از همکارانش با مقاله The New New Product Development Game آشنا میشود(به نویسندگی دو استاد کسب و کار ژاپنی)، در این مقاله با بررسی شیوه توسعه محصول در برترین شرکت های دنیا مثل Honda, Fuji-Xerox, 3M, Hewlett-Packard و خیلی های دیگه شیوه مرسومی آبشاری رو زیر سوال برده بود، در این شیوه مراحل توسعه بر یکدگیر همپوشانی داشته و انعطاف بیشتری داشتنددر این نوع شیوه توسعه تیم های فراوظیفه ای وجود داشتند. تیم ها استقلال داشتند. آنها این اختیار را داشتند که خودشان تصمیم بگیرند، هدفی متعالی داشتند و به دنبال چیزی بزرگتر از خودشان بودند.مدیریت دیگر چیزی را دیکته نمیکند و درعوض، مدیران اجرایی، رهبران خدمتگزار و تسهیل‌کننده‌هایی بودند که به جای اینکه به آن‌ها بگویند توسعه محصول چه کاری و چگونه انجام دهند، بر حذف موانع از سر راه تیم‌شان تمرکز داشتند.استادان ژاپنی کار تیم ها را با تیم راگبی مقایسه کردند و گفتند که بهترین تیم ها طوری رفتار می کنند که گویی در یک مسابقه حضور دارند.از دیگر ریشه های اسکرام در تفکرات ژاپن میتوان به مراحل استاد شدن در هر کاری از جمله شیوه ای که در اسکرام و یا بصورت کلی تر چابکی برای توسعه محصول در نظر داریم، اشاره کرد.شو ها ریدر برداشت بنده ما ایرانی ها خیلی با این شیوه و مراحلش ناآشنا نیستیم، این مراحل بصورت خلاصه اینگونه است:در حالت Shu، انجام شیوه دیکته شده، قدم به قدم بدون هیچ حرف و حدیثیدر حالت Ha، هنگامی که بر فرم ها تسلط پیدا کردید، می توانید نوآوری‌هایی انجام دهید.در حالت Ri می‌توانید فرم‌ها را دور بریزید، واقعاً به تمرین مسلط شده‌اید و اجازه دارید بدون مانعی خلاق باشید https://www.aparat.com/v/eTOjd https://www.aparat.com/v/h1D8w حرف آخرتوجه به ریشه های اسکرام نگاهی فراتر از تمرین های اسکرام و اسم های فرنگی آن میدهد که اسکرام چیزی جز این ریشه ها نیست، برای اینکه متوجه شویم آیا سازمانی در مسیر چابکی یا اسکرام قرار دارد یا خیر، نه به استیکی نوت‌ها توجه کنید و نه جلسات ایستاده، ببینید انسانها تا چه میزان در جهت اهداف متعالی خود استقلال دارند و مورد اعتماد هستند علی خباز علی خباز Wed, 28 Sep 2022 13:03:11 +0330