https://virgool.io/HumaCulture/feed فرهنگ هوما (تکمیل می شود) fa 2026-06-16 10:55:03 https://files.virgool.io/ https://virgool.io/HumaCulture 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