🧩 بزرگترین سوءتفاهم درباره تبدیل شدن به یک مدیر محصول 🧩
هفته قبل در طی دوره آموزشی مدیر محصول چابک، مفهومی مطرح شد بعنوان اینکه مدیر محصول باید mini-CEO محصول باشد، مثل اینکه در رأس یک ساختار سازمانی قرار بگیری، تیمها رو هدایت کنی و تصمیم نهایی با تو باشد. اما این تصویر یک ذره رمانتیک تر از واقعیت هست.
🚫 انتظار: قرار گرفتن در بالای ساختار سازمانی و تصمیمگیری نهایی.
✅ واقعیت: در واقع، در رأس هیچ چیزی نیستی! به جای اون، در مرکز یک شبکه از منافع متضاد قرار داری. فروش، بازاریابی، مهندسی، پشتیبانی مشتری، تجربه کاربری... هر کدوم اولویتهای خودشون رو دارن، و به عنوان مدیر محصول، تو باید همه رو به یک تعادل نسبی و توافق جمعی برسونی، بدون اینکه حق تصمیمگیری نهایی توی هیچ حوزهای داشته باشی.
وظیفه تو چی هست؟ تأثیرگذاری بدون اختیار مستقیم، هماهنگ کردن تیمهای مختلف و پیش بردن کارها به سمت هدفی مشترک حتی وقتی که ذینفعان اهداف متفاوتی دارند. شاید مسئولیتها مشترک باشد، ولی تصمیمگیری یک کار تیمی هست. این نقش به همدلی، مهارتهای ارتباطی و کمی دیپلماسی (با چاشنی صبر زیاد) نیاز دارد.
حقیقت این هست که مدیر محصول بودن، به جای در کنترل داشتن همه امور، بیشتر بدنبال ایجاد وضوح، مدیریت هرج و مرج و کمک به همکاری دیگران برای ساختن چیزی معنادار هست.
هفته قبل در طی دوره آموزشی مدیر محصول چابک، مفهومی مطرح شد بعنوان اینکه مدیر محصول باید mini-CEO محصول باشد، مثل اینکه در رأس یک ساختار سازمانی قرار بگیری، تیمها رو هدایت کنی و تصمیم نهایی با تو باشد. اما این تصویر یک ذره رمانتیک تر از واقعیت هست.
🚫 انتظار: قرار گرفتن در بالای ساختار سازمانی و تصمیمگیری نهایی.
✅ واقعیت: در واقع، در رأس هیچ چیزی نیستی! به جای اون، در مرکز یک شبکه از منافع متضاد قرار داری. فروش، بازاریابی، مهندسی، پشتیبانی مشتری، تجربه کاربری... هر کدوم اولویتهای خودشون رو دارن، و به عنوان مدیر محصول، تو باید همه رو به یک تعادل نسبی و توافق جمعی برسونی، بدون اینکه حق تصمیمگیری نهایی توی هیچ حوزهای داشته باشی.
وظیفه تو چی هست؟ تأثیرگذاری بدون اختیار مستقیم، هماهنگ کردن تیمهای مختلف و پیش بردن کارها به سمت هدفی مشترک حتی وقتی که ذینفعان اهداف متفاوتی دارند. شاید مسئولیتها مشترک باشد، ولی تصمیمگیری یک کار تیمی هست. این نقش به همدلی، مهارتهای ارتباطی و کمی دیپلماسی (با چاشنی صبر زیاد) نیاز دارد.
حقیقت این هست که مدیر محصول بودن، به جای در کنترل داشتن همه امور، بیشتر بدنبال ایجاد وضوح، مدیریت هرج و مرج و کمک به همکاری دیگران برای ساختن چیزی معنادار هست.
جلسات بی فایده، یا عدم مشارکت اعضای تیم در موضوعات جلسه
این دو مورد از شایع ترین مواردی هست که این روزها در تیم های چابک گزارش می شود، یا اعضای تیم از جلسات بی فایده شکایت دارند که وقتشان در آن تلف می شود، یا اسکرام مسترها/مربیهای چابک از این که اعضای تیم در جلسات مشارکت نمیکنند، گلهمند هستند.
اینجا دقیقا جایی است که نقش یک تسهلیگر خوب تعریف می شود:
تسهیل گر خوب، کسی است که بتواند یک جلسه یا ورکشاپ را به گونه ای طراحی و اجرا کند، که 1- افرادی که در آن حضور دارند، بیشترین مشارکت را داشته باشند 2- جلسه آغاز و پایان خوبی داشته باشد 3- انتهای جلسه حس کنیم که این جلسه فایده داشته و اکنون میدانیم که گام بعدی چیست.
اسکرام مسترها/مربیهای چابک باید بر روی مهارت تسهیلگری خود سرمایه گذاری خوبی انجام بدهند، زیراکه می توانند با این ابزار در داخل تیم و شیوه کاری تحول بزرگی ایجاد کنند.
ورکشاپ تسهیلگری چابک آبان امسال در شش جلسه از 17 آبان تا 2 آذر به صورت آنلاین برگزار خواهد شد. برای اطلاعات بیشتر میتوانید از این لینک استفاده کنید.
این دو مورد از شایع ترین مواردی هست که این روزها در تیم های چابک گزارش می شود، یا اعضای تیم از جلسات بی فایده شکایت دارند که وقتشان در آن تلف می شود، یا اسکرام مسترها/مربیهای چابک از این که اعضای تیم در جلسات مشارکت نمیکنند، گلهمند هستند.
اینجا دقیقا جایی است که نقش یک تسهلیگر خوب تعریف می شود:
تسهیل گر خوب، کسی است که بتواند یک جلسه یا ورکشاپ را به گونه ای طراحی و اجرا کند، که 1- افرادی که در آن حضور دارند، بیشترین مشارکت را داشته باشند 2- جلسه آغاز و پایان خوبی داشته باشد 3- انتهای جلسه حس کنیم که این جلسه فایده داشته و اکنون میدانیم که گام بعدی چیست.
اسکرام مسترها/مربیهای چابک باید بر روی مهارت تسهیلگری خود سرمایه گذاری خوبی انجام بدهند، زیراکه می توانند با این ابزار در داخل تیم و شیوه کاری تحول بزرگی ایجاد کنند.
ورکشاپ تسهیلگری چابک آبان امسال در شش جلسه از 17 آبان تا 2 آذر به صورت آنلاین برگزار خواهد شد. برای اطلاعات بیشتر میتوانید از این لینک استفاده کنید.
چرا استعاره تحول کرمابریشم به پروانه برای تغییرات سازمانی اشتباه است
شاید این چیزی که میگویم یک نظر نامحبوب باشد ولی بیایید یک استعاره قدیمی و پرکاربرد را به چالش بکشیم: این که تغییر در سازمان مثل تبدیل شدن کرمابریشم به پروانه است. این استعاره در اکثر کتاب های تحول دیجیتال استفاده شده است.
این استعاره در نگاه اول زیبا به نظر میرسد. یک کرمابریشم 🐛 که تلاش میکند، در نهایت به یک پروانهی زیبا و بینقص 🦋 تبدیل میشود. انگار دو حالت مشخص داریم: وضعیت فعلی که ناقص است و آیندهای آرمانی و ایدهآل که همه چیز در آن کامل است.
اما مشکل اینجاست: تغییر در دنیای واقعی این شکلی نیست.
مشکل من با استعاره پروانه چیست؟
این استعاره این تصور را ایجاد میکند که یک نقطه پایان کامل وجود دارد، یک حالت آرمانی که در آن تمام چالشها از بین میروند و اوضاع کاملاً "درست" میشود.
اما حقیقت این است که زندگی - و سازمانها - هیچوقت اینطور عمل نمیکنند.
چسبیدن به این استعاره باعث میشود انتظارات اشتباهی ایجاد کنیم و در نهایت خسته شویم. چرا؟ چون:
- حالت ایدهآل یک سراب است 🏝️ – هیچ وضعیت کاملی وجود ندارد. هر مرحله جدید چالشهای و مشکلات خاص خودش را دارد.
- باعث نارضایتی میشود 😕 – وقتی آیندهای بینقص را بزرگنمایی میکنیم، ارزش حال حاضر را پایین میآوریم و وقتی به آن کمال نمیرسیم، افراد ناامید میشوند.
- خستگی ناشی از تغییر را افزایش میدهد 💤 – تلاش برای رسیدن به یک آرمان غیرممکن انرژی و انگیزه تیمها را تحلیل میبرد.
تکامل استعاره بهتری از تحول است 🌱
در علم پیچیدگی، رسیدن به تعادل، هدف نیست؛ بلکه یک زنگ خطر ⚠️ است. سیستمهایی که به تعادل میرسند، از تکامل بازمیمانند و در طبیعت، این یعنی مرگ 💀. سیستمهای زنده با سازگاری مداوم زنده میمانند.
به جای این که تغییر را مثل یک جهش ناگهانی از کرمابریشم به پروانه ببینیم، تغییر واقعی بیشتر شبیه تکامل است: تدریجی، پر از چالش و پویایی. تکامل وعده یک خط پایان را نمیدهد. بلکه عدم قطعیت و تعامل میان فرصتها و مشکلات را میپذیرد.
چرا تکامل استعاره بهتری است؟ 🔄
تکامل این واقعیتها را درباره تغییر بهتر نشان میدهد:
- تداوم دارد 🔁 – تغییر متوقف نمیشود. هر قدم دریچههای جدید را باز میکند، اما موانع جدیدی هم به همراه دارد.
- واقعگرایانه است ⚙️ – تمرکز بر پیشرفت است، نه کمال.
- انطباقپذیر است 🌍 – تکامل به محیط واکنش نشان میدهد و بر پایه بازخورد و ظهور شکل میگیرد.
اگر اصرار دارید از کلمه "تحول" استفاده کنید، آن را همراه با "مداوم" بیاورید تا نشان دهد تغییر واقعی هیچوقت پایانپذیر نیست. اما راستش، تکامل بهتر این موضوع را بیان میکند.
چرا این موضوع برای عوامل تغییر مهم است؟ 💡
به عنوان عاملین تغییر، باید از فروختن آرمانشهرها 🏰 دست برداریم. به جای این که آیندهای دستنیافتنی را وعده دهیم، بیایید تغییر را به عنوان یک سفر 🚶♂️🚶♀️ معرفی کنیم—سفری که ارزشش نه به خاطر پایان آن، بلکه به خاطر این است که ما را به سازگاری، رشد و کشف وادار میکند.
سازمانها، مثل سیستمهای زنده، زمانی رشد میکنند که تکامل را بپذیرند، نه وقتی که در تعقیب یک توهم کمال باشند.
اسد صفری
شاید این چیزی که میگویم یک نظر نامحبوب باشد ولی بیایید یک استعاره قدیمی و پرکاربرد را به چالش بکشیم: این که تغییر در سازمان مثل تبدیل شدن کرمابریشم به پروانه است. این استعاره در اکثر کتاب های تحول دیجیتال استفاده شده است.
این استعاره در نگاه اول زیبا به نظر میرسد. یک کرمابریشم 🐛 که تلاش میکند، در نهایت به یک پروانهی زیبا و بینقص 🦋 تبدیل میشود. انگار دو حالت مشخص داریم: وضعیت فعلی که ناقص است و آیندهای آرمانی و ایدهآل که همه چیز در آن کامل است.
اما مشکل اینجاست: تغییر در دنیای واقعی این شکلی نیست.
مشکل من با استعاره پروانه چیست؟
این استعاره این تصور را ایجاد میکند که یک نقطه پایان کامل وجود دارد، یک حالت آرمانی که در آن تمام چالشها از بین میروند و اوضاع کاملاً "درست" میشود.
اما حقیقت این است که زندگی - و سازمانها - هیچوقت اینطور عمل نمیکنند.
چسبیدن به این استعاره باعث میشود انتظارات اشتباهی ایجاد کنیم و در نهایت خسته شویم. چرا؟ چون:
- حالت ایدهآل یک سراب است 🏝️ – هیچ وضعیت کاملی وجود ندارد. هر مرحله جدید چالشهای و مشکلات خاص خودش را دارد.
- باعث نارضایتی میشود 😕 – وقتی آیندهای بینقص را بزرگنمایی میکنیم، ارزش حال حاضر را پایین میآوریم و وقتی به آن کمال نمیرسیم، افراد ناامید میشوند.
- خستگی ناشی از تغییر را افزایش میدهد 💤 – تلاش برای رسیدن به یک آرمان غیرممکن انرژی و انگیزه تیمها را تحلیل میبرد.
تکامل استعاره بهتری از تحول است 🌱
در علم پیچیدگی، رسیدن به تعادل، هدف نیست؛ بلکه یک زنگ خطر ⚠️ است. سیستمهایی که به تعادل میرسند، از تکامل بازمیمانند و در طبیعت، این یعنی مرگ 💀. سیستمهای زنده با سازگاری مداوم زنده میمانند.
به جای این که تغییر را مثل یک جهش ناگهانی از کرمابریشم به پروانه ببینیم، تغییر واقعی بیشتر شبیه تکامل است: تدریجی، پر از چالش و پویایی. تکامل وعده یک خط پایان را نمیدهد. بلکه عدم قطعیت و تعامل میان فرصتها و مشکلات را میپذیرد.
چرا تکامل استعاره بهتری است؟ 🔄
تکامل این واقعیتها را درباره تغییر بهتر نشان میدهد:
- تداوم دارد 🔁 – تغییر متوقف نمیشود. هر قدم دریچههای جدید را باز میکند، اما موانع جدیدی هم به همراه دارد.
- واقعگرایانه است ⚙️ – تمرکز بر پیشرفت است، نه کمال.
- انطباقپذیر است 🌍 – تکامل به محیط واکنش نشان میدهد و بر پایه بازخورد و ظهور شکل میگیرد.
اگر اصرار دارید از کلمه "تحول" استفاده کنید، آن را همراه با "مداوم" بیاورید تا نشان دهد تغییر واقعی هیچوقت پایانپذیر نیست. اما راستش، تکامل بهتر این موضوع را بیان میکند.
چرا این موضوع برای عوامل تغییر مهم است؟ 💡
به عنوان عاملین تغییر، باید از فروختن آرمانشهرها 🏰 دست برداریم. به جای این که آیندهای دستنیافتنی را وعده دهیم، بیایید تغییر را به عنوان یک سفر 🚶♂️🚶♀️ معرفی کنیم—سفری که ارزشش نه به خاطر پایان آن، بلکه به خاطر این است که ما را به سازگاری، رشد و کشف وادار میکند.
سازمانها، مثل سیستمهای زنده، زمانی رشد میکنند که تکامل را بپذیرند، نه وقتی که در تعقیب یک توهم کمال باشند.
اسد صفری
چگونه یک جلسه پریمورتِم برگزار کنیم؟
بسیاری از تیمهای مهندسی زمانی که خطا یا مشکلی رخ میدهد، جلسهی پستمورتِم (Post-Mortem) برگزار میکنند. این جلسات برای آن است که تیم دور هم جمع شود و دربارهی دلیل بروز مشکل و راههای جلوگیری از وقوع مجدد آن بحث کند (نه برای پیدا کردن مقصر یا سرزنش کردن).
اما اگر بتوانیم این شکستها را قبل از وقوع پیشبینی و از آنها جلوگیری کنیم چه؟ اینجاست که پریمورتِم (Pre-Mortem) وارد میشود.
پریمورتِم ابزاری قدرتمند است که بهترین تیمهای محصول در شرکتهایی مانند گوگل، متا، استرایپ و سایر شرکتهای بزرگ به طور منظم از آن استفاده میکنند تا شانس موفقیت لانچ محصول را افزایش دهند و از شکستهایی که جبرانشان دشوار است جلوگیری کنند.
چطور یک پری-مورتِم برگزار کنیم؟
برای موفقیت یک پری-مورتِم، حضور افراد از بخشهای مختلف سازمان ضروری است تا دیدگاههای متنوعی مطرح شود. علاوه بر تیمهای مهندسی، محصول، و طراحی، همکارانی از حوزههای داده، بازاریابی، حقوقی، مالی و پشتیبانی مشتری نیز دعوت کنید. اگر تعداد شرکتکنندگان زیاد باشد، میتوانید جلسات جداگانه برگزار کنید.
شروع جلسه
تسهیلگر(معمولاً مدیر محصول یا لید مهندسی) جلسه را با یک پرسش ساده شروع میکند:
"چند روز از لانچ محصول گذشته و پروژه شکست خورده است. دلایل این شکست چه بودهاند؟"
حاضرین سپس دلایل فرضی و احتمالی شکست پروژه را مینویسند. هدف این است که خلاق باشند و هیچ ایدهای "بد" یا "مسخره" تلقی نشود.
برای افزایش حس امنیت روانی، سه دستهبندی از دلایل مطرح میشود:
- ببر (Tiger): مشکلی واقعی که میتواند پروژه را به خطر بیاندازد.
- ببر کاغذی (Paper Tiger): مشکلی که دیگران ممکن است نگران آن باشند، اما شما نیستید. دلیل این نگرام نبودن معمولاً این است که شما تقریبا مطمئن هستید این موضوع جای نگرانی ندارد یا حداقل برنامه مشخصی برای آن دارید.
- فیل (Elephant): موضوعی که نمیدانید مشکل است یا نه، اما نگران هستید که گروه به اندازهی کافی دربارهی آن صحبت نمیکند.
اشتراکگذاری و دستهبندی دلایل
پس از نوشتن دلایل، تسهیلگر از افراد میخواهد تا دلایل خود را به اشتراک بگذارند. میتوانید از روشهایی مثل چسباندن یادداشتهای استیکی روی وایتبرد استفاده کنید و آنها را در گروههای مرتبط دستهبندی کنید. هدف این است که همهی دلایل مطرح شوند بدون اینکه بحث یا جدلی زودهنگام رخ دهد.
توسعهی راهحلها و برنامههای پشتیبان
پس از مطرح شدن دلایل اصلی، گروه دربارهی ببرها و اقدامات بعدی بحث میکند.
البته حتما لازم خواهد شد که بحث از ببرهای کاغذی نیز شروع شود تا سوءتفاهمات برطرف شود و تا همه درک کنند چرا این مورد جای نگرانی ندارد. سپس به ببرهای واقعی پرداخته میپردازیم تا مشکلات حیاتی شناسایی و برنامهی عملی برای حل آنها تدوین شود.
پرداختن به فیلها
در پایان جلسه، به فیلها میپردازیم. این مسائل معمولاً ناشی از کمبود ارتباطات هستند، اما مطرح کردن آنها باعث ایجاد امنیت روانی و ارتباط عمیقتر در تیم میشود.
جمعبندی جلسه
جلسه را با خلاصهای از نگرانیهای اصلی (ببرها، ببرهای کاغذی، و فیلها) و برنامههای عملی به پایان برسانید. اقدامات بعدی، افراد مسئول، و زمانبندی مشخص را تعیین کنید و از همکاری تیم تشکر کنید.
متن اصلی
بسیاری از تیمهای مهندسی زمانی که خطا یا مشکلی رخ میدهد، جلسهی پستمورتِم (Post-Mortem) برگزار میکنند. این جلسات برای آن است که تیم دور هم جمع شود و دربارهی دلیل بروز مشکل و راههای جلوگیری از وقوع مجدد آن بحث کند (نه برای پیدا کردن مقصر یا سرزنش کردن).
اما اگر بتوانیم این شکستها را قبل از وقوع پیشبینی و از آنها جلوگیری کنیم چه؟ اینجاست که پریمورتِم (Pre-Mortem) وارد میشود.
پریمورتِم ابزاری قدرتمند است که بهترین تیمهای محصول در شرکتهایی مانند گوگل، متا، استرایپ و سایر شرکتهای بزرگ به طور منظم از آن استفاده میکنند تا شانس موفقیت لانچ محصول را افزایش دهند و از شکستهایی که جبرانشان دشوار است جلوگیری کنند.
چطور یک پری-مورتِم برگزار کنیم؟
برای موفقیت یک پری-مورتِم، حضور افراد از بخشهای مختلف سازمان ضروری است تا دیدگاههای متنوعی مطرح شود. علاوه بر تیمهای مهندسی، محصول، و طراحی، همکارانی از حوزههای داده، بازاریابی، حقوقی، مالی و پشتیبانی مشتری نیز دعوت کنید. اگر تعداد شرکتکنندگان زیاد باشد، میتوانید جلسات جداگانه برگزار کنید.
شروع جلسه
تسهیلگر(معمولاً مدیر محصول یا لید مهندسی) جلسه را با یک پرسش ساده شروع میکند:
"چند روز از لانچ محصول گذشته و پروژه شکست خورده است. دلایل این شکست چه بودهاند؟"
حاضرین سپس دلایل فرضی و احتمالی شکست پروژه را مینویسند. هدف این است که خلاق باشند و هیچ ایدهای "بد" یا "مسخره" تلقی نشود.
برای افزایش حس امنیت روانی، سه دستهبندی از دلایل مطرح میشود:
- ببر (Tiger): مشکلی واقعی که میتواند پروژه را به خطر بیاندازد.
- ببر کاغذی (Paper Tiger): مشکلی که دیگران ممکن است نگران آن باشند، اما شما نیستید. دلیل این نگرام نبودن معمولاً این است که شما تقریبا مطمئن هستید این موضوع جای نگرانی ندارد یا حداقل برنامه مشخصی برای آن دارید.
- فیل (Elephant): موضوعی که نمیدانید مشکل است یا نه، اما نگران هستید که گروه به اندازهی کافی دربارهی آن صحبت نمیکند.
اشتراکگذاری و دستهبندی دلایل
پس از نوشتن دلایل، تسهیلگر از افراد میخواهد تا دلایل خود را به اشتراک بگذارند. میتوانید از روشهایی مثل چسباندن یادداشتهای استیکی روی وایتبرد استفاده کنید و آنها را در گروههای مرتبط دستهبندی کنید. هدف این است که همهی دلایل مطرح شوند بدون اینکه بحث یا جدلی زودهنگام رخ دهد.
توسعهی راهحلها و برنامههای پشتیبان
پس از مطرح شدن دلایل اصلی، گروه دربارهی ببرها و اقدامات بعدی بحث میکند.
البته حتما لازم خواهد شد که بحث از ببرهای کاغذی نیز شروع شود تا سوءتفاهمات برطرف شود و تا همه درک کنند چرا این مورد جای نگرانی ندارد. سپس به ببرهای واقعی پرداخته میپردازیم تا مشکلات حیاتی شناسایی و برنامهی عملی برای حل آنها تدوین شود.
پرداختن به فیلها
در پایان جلسه، به فیلها میپردازیم. این مسائل معمولاً ناشی از کمبود ارتباطات هستند، اما مطرح کردن آنها باعث ایجاد امنیت روانی و ارتباط عمیقتر در تیم میشود.
جمعبندی جلسه
جلسه را با خلاصهای از نگرانیهای اصلی (ببرها، ببرهای کاغذی، و فیلها) و برنامههای عملی به پایان برسانید. اقدامات بعدی، افراد مسئول، و زمانبندی مشخص را تعیین کنید و از همکاری تیم تشکر کنید.
متن اصلی
نقشه راه چابکی : مدل اجایل فلوئنسی
بسیاری از شرکتها معمولا در دام پیاده سازی اجباری یا به زور چارچوبهای چابک میفتند، بدون اینکه نقشه راه مشخصی از چابکی داشته باشند. حقیقت این است که چابک یک مقصد نهایی نیست، بلکه یک سفر با ایستگاههای متنوع است که هر کدام مزایای خاص خود را دارند. مدل اجایل فلوئنسی هم دقیقاً همین نقشه راه گام به گام را ارائه میدهد؛ یک نقشه راه منعطف که به شما امکان میدهد "ایستگاه" چابکی مناسب تیم خود را انتخاب کنید.
تصورش کنید سوار "اتوبوس مدل اجایل فلوئنسی" شدهاید. هر ایستگاه که به آن میرسیم،به سطحی از توانایی چابک خواهیم رسیم، از مهارتهای پایه تا نوآوریهای پیشرو. نیازی نیست به "آخرین ایستگاه" برسید تا موفق باشید؛ کلید کار این است که ایستگاهی را انتخاب کنید که با نیازها و اهداف کسبوکارتان سازگار باشد. البته، سفر هم رایگان نیست، برای اتوبوس باید بلیط تهیه کنید و هر چقدر مسیر دورتر، بلیط گرانتر.
ایستگاه 1: متمرکز شدن – تسلط بر اصول پایه
این آغاز سفر چابکی است. تیمها در این مرحله، پایههای کار را محکم میکنند: هدفگذاری شفاف، اولویتبندی کارها و همکاری مؤثر. چارچوب هایی مثل اسکرام و کانبان، در این مرحله کاربرد خواهند داشت.
چرا مهم است: این مرحله شفافیت ایجاد میکند، درک مشترک میسازد و همه را در مسیر یک هدف مشترک قرار میدهد. در واقع پایهای است که تمام موفقیتهای بعدی چابک بر آن سوار میشوند و به تیمها کمک میکند ارزش قابل پیشبینی ارائه دهند.
ایستگاه 2: تحویل دادن – ارسال ارزش بهطور مستمر
اتوبوس حالا سرعت میگیرد و به ایستگاه "تحویل یا دلیور" میرسد. در اینجا، تمرکز تیمها بر تحویل پایدار و با کیفیت است. تصور کنید قابلیت هایی که همیشه سر وقت و بدون دردسر به دست مشتری میرسند—بدون موعدهای از دست رفته یا عجلههای دقیقه نودی.
چرا مهم است: دست یافتن به این مرحله منجر به کاهش اتلافات و باگ ها شده و البته زمان رسیدن به بازار را کوتاه میکند. تیمها تبدیل به گروههایی بسیار کارآمد میشوند. در این مرحله چارچوب فنی تر مانند اکس پی، DevOps , ... بیشتر مطرح خواهند بود.
ایستگاه 3: بهینهسازی – پیش بردن نوآوری و رهبری بازار
حالا در جادههای سریع در حرکتیم. تیمها در این مرحله فقط تحویل نمیدهند؛ بلکه نوآوری هم میکنند. آنها روندهای بازار را پیشبینی، ایدههای جدید را آزمایش و مرزهای ممکن را جابهجا میکنند. تصور کنید تیمی مثل گروه مکانیکهای فرمول یک که مدام عملکرد را بهتر میکنند تا به نتایج عالی برسند.
چرا مهم است: این مرحله فرهنگ بهبود مداوم و نوآوری را ایجاد میکند، به تیمها اجازه میدهد ارزش متمایز عرضه کنند و از رقبا جلو بزنند.
ایستگاه 4: توانمندسازی – ساخت یک اکوسیستم چابک
ایستگاه چهارجایی است که اصول چابک از مرز یک تیم فراتر میرود و در کل سازمان جاری میشود. اینجا صحبت از ایجاد شبکهای از تیمهای هماهنگ و انعطافپذیر است که مثل یک ارکستر خوشصدا با هم همکاری میکنند و هر بخش نقش خود را عالی ایفا میکند.
چرا مهم است: این مرحله چابکی و انعطافپذیری سازمانی را تقویت میکند و به کل کسبوکار اجازه میدهد با سرعت به تغییرات پاسخ داده و ارزش پایدار ایجاد کند.
مدل اجایل فلوئنسی درباره یک مسیر خطی نیست، بلکه درباره انتخاب آگاهانه است. کدام ایستگاه همین حالا برای شما مناسب است؟ به این پرسشها فکر کنید:
چالشهای اصلی کسبوکار شما چیست؟ (مثلاً تحویل ناپایدار، کمبود نوآوری، تأخیر در رسیدن به بازار)
چقدر میخواهید سرمایهگذاری کنید؟
فرهنگ سازمانی شما چگونه است؟
مدل اجایل فلوئنسی به شما امکان میدهد سفر چابکیتان را بر اساس نیازهای خاص خودتان تنظیم کنید. بحث رسیدن به یک "بهشت افسانهای چابک" نیست؛ بلکه انتخاب مسیر درست برای دستیابی به اهداف کسبوکارتان است.
ورکشاپ بعدی "تحول چابک با مدل اجایل فلوئنسی" در حال ثبت نام است، برای اطلاعات بیشتر میتوانید این لینک را مشاهده کنید.
بسیاری از شرکتها معمولا در دام پیاده سازی اجباری یا به زور چارچوبهای چابک میفتند، بدون اینکه نقشه راه مشخصی از چابکی داشته باشند. حقیقت این است که چابک یک مقصد نهایی نیست، بلکه یک سفر با ایستگاههای متنوع است که هر کدام مزایای خاص خود را دارند. مدل اجایل فلوئنسی هم دقیقاً همین نقشه راه گام به گام را ارائه میدهد؛ یک نقشه راه منعطف که به شما امکان میدهد "ایستگاه" چابکی مناسب تیم خود را انتخاب کنید.
تصورش کنید سوار "اتوبوس مدل اجایل فلوئنسی" شدهاید. هر ایستگاه که به آن میرسیم،به سطحی از توانایی چابک خواهیم رسیم، از مهارتهای پایه تا نوآوریهای پیشرو. نیازی نیست به "آخرین ایستگاه" برسید تا موفق باشید؛ کلید کار این است که ایستگاهی را انتخاب کنید که با نیازها و اهداف کسبوکارتان سازگار باشد. البته، سفر هم رایگان نیست، برای اتوبوس باید بلیط تهیه کنید و هر چقدر مسیر دورتر، بلیط گرانتر.
ایستگاه 1: متمرکز شدن – تسلط بر اصول پایه
این آغاز سفر چابکی است. تیمها در این مرحله، پایههای کار را محکم میکنند: هدفگذاری شفاف، اولویتبندی کارها و همکاری مؤثر. چارچوب هایی مثل اسکرام و کانبان، در این مرحله کاربرد خواهند داشت.
چرا مهم است: این مرحله شفافیت ایجاد میکند، درک مشترک میسازد و همه را در مسیر یک هدف مشترک قرار میدهد. در واقع پایهای است که تمام موفقیتهای بعدی چابک بر آن سوار میشوند و به تیمها کمک میکند ارزش قابل پیشبینی ارائه دهند.
ایستگاه 2: تحویل دادن – ارسال ارزش بهطور مستمر
اتوبوس حالا سرعت میگیرد و به ایستگاه "تحویل یا دلیور" میرسد. در اینجا، تمرکز تیمها بر تحویل پایدار و با کیفیت است. تصور کنید قابلیت هایی که همیشه سر وقت و بدون دردسر به دست مشتری میرسند—بدون موعدهای از دست رفته یا عجلههای دقیقه نودی.
چرا مهم است: دست یافتن به این مرحله منجر به کاهش اتلافات و باگ ها شده و البته زمان رسیدن به بازار را کوتاه میکند. تیمها تبدیل به گروههایی بسیار کارآمد میشوند. در این مرحله چارچوب فنی تر مانند اکس پی، DevOps , ... بیشتر مطرح خواهند بود.
ایستگاه 3: بهینهسازی – پیش بردن نوآوری و رهبری بازار
حالا در جادههای سریع در حرکتیم. تیمها در این مرحله فقط تحویل نمیدهند؛ بلکه نوآوری هم میکنند. آنها روندهای بازار را پیشبینی، ایدههای جدید را آزمایش و مرزهای ممکن را جابهجا میکنند. تصور کنید تیمی مثل گروه مکانیکهای فرمول یک که مدام عملکرد را بهتر میکنند تا به نتایج عالی برسند.
چرا مهم است: این مرحله فرهنگ بهبود مداوم و نوآوری را ایجاد میکند، به تیمها اجازه میدهد ارزش متمایز عرضه کنند و از رقبا جلو بزنند.
ایستگاه 4: توانمندسازی – ساخت یک اکوسیستم چابک
ایستگاه چهارجایی است که اصول چابک از مرز یک تیم فراتر میرود و در کل سازمان جاری میشود. اینجا صحبت از ایجاد شبکهای از تیمهای هماهنگ و انعطافپذیر است که مثل یک ارکستر خوشصدا با هم همکاری میکنند و هر بخش نقش خود را عالی ایفا میکند.
چرا مهم است: این مرحله چابکی و انعطافپذیری سازمانی را تقویت میکند و به کل کسبوکار اجازه میدهد با سرعت به تغییرات پاسخ داده و ارزش پایدار ایجاد کند.
مدل اجایل فلوئنسی درباره یک مسیر خطی نیست، بلکه درباره انتخاب آگاهانه است. کدام ایستگاه همین حالا برای شما مناسب است؟ به این پرسشها فکر کنید:
چالشهای اصلی کسبوکار شما چیست؟ (مثلاً تحویل ناپایدار، کمبود نوآوری، تأخیر در رسیدن به بازار)
چقدر میخواهید سرمایهگذاری کنید؟
فرهنگ سازمانی شما چگونه است؟
مدل اجایل فلوئنسی به شما امکان میدهد سفر چابکیتان را بر اساس نیازهای خاص خودتان تنظیم کنید. بحث رسیدن به یک "بهشت افسانهای چابک" نیست؛ بلکه انتخاب مسیر درست برای دستیابی به اهداف کسبوکارتان است.
ورکشاپ بعدی "تحول چابک با مدل اجایل فلوئنسی" در حال ثبت نام است، برای اطلاعات بیشتر میتوانید این لینک را مشاهده کنید.
lnkd.in
LinkedIn
This link will take you to a page that’s not on LinkedIn
مدل ذهنی Probabilistic Thinking
به عنوان یک رهبر فنی، یکی از متداولترین (و شاید ناخوشایندترین) سوالاتی که با آن مواجه میشوید: «این کار کی تمام میشود؟» مشتریان، ذینفعان و حتی اعضای تیم خودتان به دنبال قطعیت در حوزه ای ذاتا نامطمئن هستند. در حالی که ارائه تاریخهای دقیق تحویل غیرممکن است، در اینجا میتوانیم از مدل ذهنی Probabilistic Thinking برای ارائه تخمینهای واقعبینانهتر و ارزشمندتر استفاده کنیم.
توسعه نرمافزار یک امر پیچیده است. چالشهای غیرمنتظره، تغییر نیازمندیها و خلاقیت ذاتی درگیر در آن، پیشبینی تکمیل با قطعیت مطلق را غیرممکن میسازد. برخورد با تخمینها به عنوان ضربالاجلهای ثابت، انتظارات غیرواقعی ایجاد میکند و میتواند منجر به موارد زیر شود:
- سندرم فرسودگی شغلی: توسعهدهندگان تحت فشار قرار میگیرند تا ضربالاجلها را رعایت کنند که منجر به استرس و کاهش بهرهوری در بلند مدت میشود.
-کاهش کیفیت: برای رعایت ضربالاجلها، ممکن است از برخی مراحل صرفنظر شود که منجر به نرمافزار دارای باگ و افزایش بدهی فنی شود.
- از دست دادن اعتماد: عدم رعایت مکرر ضربالاجلها، اعتماد بین تیم توسعه و ذینفعان را از بین میبرد.
به جای تاریخهای ثابت، بیایید عدم قطعیت را بپذیریم. در اینجا نحوه کمک Probabilistic Thinking آورده شده است:
شناسایی عدم قطعیتهای کلیدی:
پیچیدگی: پیچیدگی کار چقدر است؟ آیا ناشناختهها یا وابستگیهایی وجود دارد؟
تغییر دامنه: احتمال تغییر نیازمندیها چقدر است؟
تجربه توسعهدهندگان: تجربه تیم در زمینه فناوری و حوزه مسئله چیست؟
عوامل خارجی: آیا عوامل خارجی احتمالی وجود دارد که میتواند بر پروژه تأثیر بگذارد (مانند مشکلات زنجیره تامین، تاخیرهای غیرمنتظره)؟
تخصیص احتمالات:
بر اساس ارزیابی شما از این عدم قطعیتها، احتمالات را به سناریوهای مختلف اختصاص دهید.
به عنوان مثال، «۷۰٪ احتمال تکمیل شدن در عرض دو هفته، ۲۰٪ احتمال تکمیل در عرض سه هفته و ۱۰٪ احتمال مواجهه با تاخیرهای غیرمنتظره وجود دارد.»
ارتباط شفاف:
- به جای وعده دادن یک تاریخ مشخص، طیف وسیعی از نتایج احتمالی مرتبط با آنها را ارائه دهید.
- عواملی را که به عدم قطعیت کمک میکنند توضیح دهید.
- در مورد احتمال تاخیرها و اقداماتی که برای کاهش آنها انجام خواهید داد، صریح باشید.
ارزیابی مجدد مداوم:
- با پیشرفت پروژه، بازخورد جمعآوری کنید، پیشرفت را کنترل کرده و تخمینهای خود را متناسباً تنظیم کنید.
- این بهروزرسانیها را به طور منظم با ذینفعان در میان بگذارید تا شفافیت و اعتماد را حفظ کنید.
مثال:
درخواست ویژگی ظاهراً سادهای میرسد: «دکمهای به پروفایل کاربر اضافه کنید.»
پیچیدگی: در حالی که این کار ظاهراً ساده است، ممکن است وابستگیهایی به سایر بخشهای سیستم یا موارد حاشیهای غیرمنتظره وجود داشته باشد.
تغییر دامنه: مشتری ممکن است پس از مشاهده اجرای اولیه، درخواست اضافی کند.
ارتباط: به جای گفتن «تا جمعه انجام خواهد شد»، تیم لید ممکن است بگوید: «بر اساس ارزیابی اولیه، ۸۰٪ احتمال تکمیل این کار تا جمعه وجود دارد، اما ۲۰٪ احتمال وجود دارد که با چالشهای غیرمنتظرهای مواجه شویم که میتواند جدول زمانی را تمدید کند.»
ایجاد اعتماد از طریق شفافیت
با پذیرش Probabilistic Thinking و ارتباط صادقانه و شفاف، رهبران فنی یا مدیران پروژه میتوانند اعتماد را با ذینفعان ایجاد کنند. این رویکرد نه تنها منجر به انتظارات واقعبینانهتر میشود، بلکه فرهنگ همکاری و بهبود مستمر را نیز تقویت میکند.
به عنوان یک رهبر فنی، یکی از متداولترین (و شاید ناخوشایندترین) سوالاتی که با آن مواجه میشوید: «این کار کی تمام میشود؟» مشتریان، ذینفعان و حتی اعضای تیم خودتان به دنبال قطعیت در حوزه ای ذاتا نامطمئن هستند. در حالی که ارائه تاریخهای دقیق تحویل غیرممکن است، در اینجا میتوانیم از مدل ذهنی Probabilistic Thinking برای ارائه تخمینهای واقعبینانهتر و ارزشمندتر استفاده کنیم.
توسعه نرمافزار یک امر پیچیده است. چالشهای غیرمنتظره، تغییر نیازمندیها و خلاقیت ذاتی درگیر در آن، پیشبینی تکمیل با قطعیت مطلق را غیرممکن میسازد. برخورد با تخمینها به عنوان ضربالاجلهای ثابت، انتظارات غیرواقعی ایجاد میکند و میتواند منجر به موارد زیر شود:
- سندرم فرسودگی شغلی: توسعهدهندگان تحت فشار قرار میگیرند تا ضربالاجلها را رعایت کنند که منجر به استرس و کاهش بهرهوری در بلند مدت میشود.
-کاهش کیفیت: برای رعایت ضربالاجلها، ممکن است از برخی مراحل صرفنظر شود که منجر به نرمافزار دارای باگ و افزایش بدهی فنی شود.
- از دست دادن اعتماد: عدم رعایت مکرر ضربالاجلها، اعتماد بین تیم توسعه و ذینفعان را از بین میبرد.
به جای تاریخهای ثابت، بیایید عدم قطعیت را بپذیریم. در اینجا نحوه کمک Probabilistic Thinking آورده شده است:
شناسایی عدم قطعیتهای کلیدی:
پیچیدگی: پیچیدگی کار چقدر است؟ آیا ناشناختهها یا وابستگیهایی وجود دارد؟
تغییر دامنه: احتمال تغییر نیازمندیها چقدر است؟
تجربه توسعهدهندگان: تجربه تیم در زمینه فناوری و حوزه مسئله چیست؟
عوامل خارجی: آیا عوامل خارجی احتمالی وجود دارد که میتواند بر پروژه تأثیر بگذارد (مانند مشکلات زنجیره تامین، تاخیرهای غیرمنتظره)؟
تخصیص احتمالات:
بر اساس ارزیابی شما از این عدم قطعیتها، احتمالات را به سناریوهای مختلف اختصاص دهید.
به عنوان مثال، «۷۰٪ احتمال تکمیل شدن در عرض دو هفته، ۲۰٪ احتمال تکمیل در عرض سه هفته و ۱۰٪ احتمال مواجهه با تاخیرهای غیرمنتظره وجود دارد.»
ارتباط شفاف:
- به جای وعده دادن یک تاریخ مشخص، طیف وسیعی از نتایج احتمالی مرتبط با آنها را ارائه دهید.
- عواملی را که به عدم قطعیت کمک میکنند توضیح دهید.
- در مورد احتمال تاخیرها و اقداماتی که برای کاهش آنها انجام خواهید داد، صریح باشید.
ارزیابی مجدد مداوم:
- با پیشرفت پروژه، بازخورد جمعآوری کنید، پیشرفت را کنترل کرده و تخمینهای خود را متناسباً تنظیم کنید.
- این بهروزرسانیها را به طور منظم با ذینفعان در میان بگذارید تا شفافیت و اعتماد را حفظ کنید.
مثال:
درخواست ویژگی ظاهراً سادهای میرسد: «دکمهای به پروفایل کاربر اضافه کنید.»
پیچیدگی: در حالی که این کار ظاهراً ساده است، ممکن است وابستگیهایی به سایر بخشهای سیستم یا موارد حاشیهای غیرمنتظره وجود داشته باشد.
تغییر دامنه: مشتری ممکن است پس از مشاهده اجرای اولیه، درخواست اضافی کند.
ارتباط: به جای گفتن «تا جمعه انجام خواهد شد»، تیم لید ممکن است بگوید: «بر اساس ارزیابی اولیه، ۸۰٪ احتمال تکمیل این کار تا جمعه وجود دارد، اما ۲۰٪ احتمال وجود دارد که با چالشهای غیرمنتظرهای مواجه شویم که میتواند جدول زمانی را تمدید کند.»
ایجاد اعتماد از طریق شفافیت
با پذیرش Probabilistic Thinking و ارتباط صادقانه و شفاف، رهبران فنی یا مدیران پروژه میتوانند اعتماد را با ذینفعان ایجاد کنند. این رویکرد نه تنها منجر به انتظارات واقعبینانهتر میشود، بلکه فرهنگ همکاری و بهبود مستمر را نیز تقویت میکند.
چند روز پیش، یکی از دوستان گلهای را با من در میان گذاشت که عمیقاً با تجربههای خودم در تیمهای مختلف همخوانی داشت: «جلسات بازنگری (retro) تیم ما بیفایده شده. جالب اینکه همه قبول دارند مشکلاتی وجود دارد، اما همیشه انگشت اتهام را به بیرون نشانه میروند. همیشه پای ‘وابستگیها’، ‘قوانین شرکت’، یا ‘گروه یا دپارتمان دیگر’ وسط است و انتهای همه بحثها به این نتیحه میرسیم که فقط مشکلات را به اطلاع مدیران برسانیم، اما هیچ تغییری از طرف خودمان اعمال نمیشود.»
او حس میکند که تیم او در یک رکود و بیحرکتی گیر کرده است. وقتی تیمها بهطور مداوم مشکلات را به عوامل بیرونی نسبت بدهند، اختیار عمل را از دست میدهند و به جای کنشگران فعال تغییر تبدیل به تماشاگران منفعل میشوند . تصور کنید کشتیای را که در جریان تند آب گرفتار شده و بهجای تنظیم بادبانها، مدام از جریان آب شکایت میکند.
البته این لزوماً از روی بدجنسی نبوده و یک تمایل طبیعی انسانی است. مغز ما طوری طراحی شده که دنبال توضیحات ساده بگردد و از ناهماهنگی شناختی دوری کند.
ادامه نوشته
https://blog.scrum.ir/2025/01/useless-retro-meetings/
او حس میکند که تیم او در یک رکود و بیحرکتی گیر کرده است. وقتی تیمها بهطور مداوم مشکلات را به عوامل بیرونی نسبت بدهند، اختیار عمل را از دست میدهند و به جای کنشگران فعال تغییر تبدیل به تماشاگران منفعل میشوند . تصور کنید کشتیای را که در جریان تند آب گرفتار شده و بهجای تنظیم بادبانها، مدام از جریان آب شکایت میکند.
البته این لزوماً از روی بدجنسی نبوده و یک تمایل طبیعی انسانی است. مغز ما طوری طراحی شده که دنبال توضیحات ساده بگردد و از ناهماهنگی شناختی دوری کند.
ادامه نوشته
https://blog.scrum.ir/2025/01/useless-retro-meetings/
آینده شغلی مدیریت محصول چه خواهد شد؟
در این ویدئو کلیر وو، مدیر ارشد محصول در لانچدارکلی و بنیانگذار چتپیاِرد،به این سوال جواب میدهد که آینده شغلی مدیریت محصول چه خواهد شد . در این سخنرانی، او به موارد زیر میپردازد:
- چرا مدیریت محصول به شکلی که میشناسیم، در حال مرگ است؟
- چگونه هوش مصنوعی توسعه محصول را سریعتر از حد انتظار متحول میکند؟
- ظهور "سهگانههای قدرتمند" مبتنی بر هوش مصنوعی که میتوانند وظایف محصول، طراحی و مهندسی را بر عهده بگیرند؟
- رهبران محصول برای ماندگاری در عصر هوش مصنوعی به چه اقداماتی نیاز دارند؟
- چگونه تیمهای محصول مبتنی بر هوش مصنوعی را بسازیم و مدیریت کنیم؟
https://www.youtube.com/watch?v=93fCvFkY1Lg
در این ویدئو کلیر وو، مدیر ارشد محصول در لانچدارکلی و بنیانگذار چتپیاِرد،به این سوال جواب میدهد که آینده شغلی مدیریت محصول چه خواهد شد . در این سخنرانی، او به موارد زیر میپردازد:
- چرا مدیریت محصول به شکلی که میشناسیم، در حال مرگ است؟
- چگونه هوش مصنوعی توسعه محصول را سریعتر از حد انتظار متحول میکند؟
- ظهور "سهگانههای قدرتمند" مبتنی بر هوش مصنوعی که میتوانند وظایف محصول، طراحی و مهندسی را بر عهده بگیرند؟
- رهبران محصول برای ماندگاری در عصر هوش مصنوعی به چه اقداماتی نیاز دارند؟
- چگونه تیمهای محصول مبتنی بر هوش مصنوعی را بسازیم و مدیریت کنیم؟
https://www.youtube.com/watch?v=93fCvFkY1Lg
اجایل دوناتز 18 (دورهمی آنلاین چابک کاران ایران)
جمعه، 17 اسفند (7 مارچ 2025) ساعت ۲۰:۰۰ به وقت تهران
موضوع: بررسی چارچوب جدید Shape Up - مقایسه با روش اسکرام
شرکت بیس کمپ چند سال پیش روش کاری جدیدی به نام Shape Up را به صورت عمومی منتشر کرد. این روش شباهتهایی با چارچوب اسکرام دارد، اما تفاوتهای قابل توجهی نیز میان آنها دیده میشود. پس از معرفی این روش، بسیاری از شرکتها آن را آزمایش کردند و مقالات و نوشتههای متعددی در مورد مزایا و معایب آن منتشر شد.
در این دورهمی، ابتدا به بررسی چارچوب Shape Up میپردازیم و سپس به سوالاتی مانند موارد زیر پاسخ خواهیم داد:
آیا این روش میتواند جایگزین اسکرام شود؟
آیا میتوان این دو روش را با هم ترکیب کرد؟
در این دورهمی خواهیم کوشید که نظرات و تجربیات خودمان را با هم به اشتراک بگذاریم و البته مشتاق شنیدن نظرات و تجربیات همه دوستان هستیم.
🍩☕
لینک جلسه در گوگل میت:
https://meet.google.com/iaz-yefy-zgs
جمعه، 17 اسفند (7 مارچ 2025) ساعت ۲۰:۰۰ به وقت تهران
موضوع: بررسی چارچوب جدید Shape Up - مقایسه با روش اسکرام
شرکت بیس کمپ چند سال پیش روش کاری جدیدی به نام Shape Up را به صورت عمومی منتشر کرد. این روش شباهتهایی با چارچوب اسکرام دارد، اما تفاوتهای قابل توجهی نیز میان آنها دیده میشود. پس از معرفی این روش، بسیاری از شرکتها آن را آزمایش کردند و مقالات و نوشتههای متعددی در مورد مزایا و معایب آن منتشر شد.
در این دورهمی، ابتدا به بررسی چارچوب Shape Up میپردازیم و سپس به سوالاتی مانند موارد زیر پاسخ خواهیم داد:
آیا این روش میتواند جایگزین اسکرام شود؟
آیا میتوان این دو روش را با هم ترکیب کرد؟
در این دورهمی خواهیم کوشید که نظرات و تجربیات خودمان را با هم به اشتراک بگذاریم و البته مشتاق شنیدن نظرات و تجربیات همه دوستان هستیم.
🍩☕
لینک جلسه در گوگل میت:
https://meet.google.com/iaz-yefy-zgs
Google
Real-time meetings by Google. Using your browser, share your video, desktop, and presentations with teammates and customers.
Iran Agile pinned «اجایل دوناتز 18 (دورهمی آنلاین چابک کاران ایران) جمعه، 17 اسفند (7 مارچ 2025) ساعت ۲۰:۰۰ به وقت تهران موضوع: بررسی چارچوب جدید Shape Up - مقایسه با روش اسکرام شرکت بیس کمپ چند سال پیش روش کاری جدیدی به نام Shape Up را به صورت عمومی منتشر کرد. این…»
Iran Agile
اجایل دوناتز 18 (دورهمی آنلاین چابک کاران ایران) جمعه، 17 اسفند (7 مارچ 2025) ساعت ۲۰:۰۰ به وقت تهران موضوع: بررسی چارچوب جدید Shape Up - مقایسه با روش اسکرام شرکت بیس کمپ چند سال پیش روش کاری جدیدی به نام Shape Up را به صورت عمومی منتشر کرد. این…
🎥 فیلم ضبط شده - اجایل دوناتز 18 : بررسی چارچوب Shape Up: آیا جایگزین اسکرام میشود؟ |
در این قسمت، به سراغ یکی از موضوعات دنیای چابک رفتیم: چارچوب Shape Up که توسط شرکت بیس کمپ معرفی شده است.
در این ویدیو، به بررسی چارچوب Shape Up میپردازیم و شباهتها و تفاوتهای آن را با روش محبوب اسکرام مقایسه میکنیم. سوالاتی که در این دورهمی به آنها پاسخ میدهیم عبارتند از:
- چارچوب Shape Up چیست و چگونه کار میکند؟
- نقاط قوت و ضعف Shape Up نسبت به اسکرام کدامند؟
- آیا Shape Up میتواند جایگزین اسکرام شود؟
- آیا امکان ترکیب این دو روش وجود دارد؟
https://www.youtube.com/watch?v=AF6Wz-q7wVg&t=8s
در این قسمت، به سراغ یکی از موضوعات دنیای چابک رفتیم: چارچوب Shape Up که توسط شرکت بیس کمپ معرفی شده است.
در این ویدیو، به بررسی چارچوب Shape Up میپردازیم و شباهتها و تفاوتهای آن را با روش محبوب اسکرام مقایسه میکنیم. سوالاتی که در این دورهمی به آنها پاسخ میدهیم عبارتند از:
- چارچوب Shape Up چیست و چگونه کار میکند؟
- نقاط قوت و ضعف Shape Up نسبت به اسکرام کدامند؟
- آیا Shape Up میتواند جایگزین اسکرام شود؟
- آیا امکان ترکیب این دو روش وجود دارد؟
https://www.youtube.com/watch?v=AF6Wz-q7wVg&t=8s
YouTube
بررسی چارچوب Shape Up: آیا جایگزین اسکرام میشود؟ | اجایل دوناتز 18
در این قسمت، به سراغ یکی از موضوعات دنیای چابک رفتیم: چارچوب Shape Up که توسط شرکت بیس کمپ معرفی شده است.
در این ویدیو، به بررسی چارچوب Shape Up میپردازیم و شباهتها و تفاوتهای آن را با روش محبوب اسکرام مقایسه میکنیم. سوالاتی که در این دورهمی به آنها…
در این ویدیو، به بررسی چارچوب Shape Up میپردازیم و شباهتها و تفاوتهای آن را با روش محبوب اسکرام مقایسه میکنیم. سوالاتی که در این دورهمی به آنها…
Iran Agile
Please open Telegram to view this post
VIEW IN TELEGRAM
💡کارگاه اسکرام کاربردی هفته آینده برگزار خواهد شد.
به اطلاع دوستانی که پیگیر ورکشاپ اسکرام کاربردی بودند، میرساند که این دوره این هفته در روزهای ۱۸، ۱۹، ۲۵، ۲۶ اردیبهشت ماه ۱۴۰۴
با مربی گری اسد صفری برگزار خواهد شد.
هدف اصلی این دوره علاوه بر عمیق شدن در مفاهیم اسکرام و چابک، انتقال تجربیات از دنیای واقعی و چالشهای محیط کار است که معمولا در کتابها و اینترنت کمتر پیدا میشود.
📎 برای اطلاعات بیشتر میتوانید از این لینک استفاده کنید.
به اطلاع دوستانی که پیگیر ورکشاپ اسکرام کاربردی بودند، میرساند که این دوره این هفته در روزهای ۱۸، ۱۹، ۲۵، ۲۶ اردیبهشت ماه ۱۴۰۴
با مربی گری اسد صفری برگزار خواهد شد.
هدف اصلی این دوره علاوه بر عمیق شدن در مفاهیم اسکرام و چابک، انتقال تجربیات از دنیای واقعی و چالشهای محیط کار است که معمولا در کتابها و اینترنت کمتر پیدا میشود.
📎 برای اطلاعات بیشتر میتوانید از این لینک استفاده کنید.
دو راهکار ساده برای برنامهریزی و تخمین بهتر در اسپرینتها
“چطور میشه آیتمهای بکلاگ اسپرینت رو بهتر تخمین زد؟”
“جداً کلافه شدیم! اول اسپرینت کلی کار میریزیم تو برنامه، اما هنوز به وسط نرسیده یا آخر اسپرینت، مجبور میشیم کلی از اونها رو از اسپرینت حذف کنیم.”
من با تیمهای زیادی کار کردم و تقریباً همه آنها دنبال یک جور چوب جادویی هستن که باعث بشود برنامههای اسپرینت را دقیقِ دقیق برنامه ریزی بکنند.
در این نوشته میخواهیم دو ایده کاربردی و امتحان پس داده را با شما در میان بگذاریم
ادامه
https://blog.scrum.ir/2025/05/two-ways-for-better-planning-and-estimating/
“چطور میشه آیتمهای بکلاگ اسپرینت رو بهتر تخمین زد؟”
“جداً کلافه شدیم! اول اسپرینت کلی کار میریزیم تو برنامه، اما هنوز به وسط نرسیده یا آخر اسپرینت، مجبور میشیم کلی از اونها رو از اسپرینت حذف کنیم.”
من با تیمهای زیادی کار کردم و تقریباً همه آنها دنبال یک جور چوب جادویی هستن که باعث بشود برنامههای اسپرینت را دقیقِ دقیق برنامه ریزی بکنند.
در این نوشته میخواهیم دو ایده کاربردی و امتحان پس داده را با شما در میان بگذاریم
ادامه
https://blog.scrum.ir/2025/05/two-ways-for-better-planning-and-estimating/
چرا تیم من رو جزوی از خودشون نمی بینه!؟
حدود ۹-۱۰ سال پیش، این اتفاق برای من افتاد. تازه به یک تیم جدید ملحق شده بودم، پر از ایده و با اشتیاق واقعی برای اینکه کمک کنم کارهای بزرگی انجام بدهیم و یک تغییر مثبت ایجاد کنیم.
اما خیلی زود متوجه شدم چیزی سر جاش نیست. با اینکه تمام تلاشم را میکردم که با تیم ارتباط برقرار کنم، ولی انگار یک جور دیوار نامرئی بین ما بود. حس میکردم من رو یکی از خودشون نمیدونستن.
یک روز بالاخره تونستم با یکی از اعضای تیم صحبت خودمونی و صادقانه داشته باشم تا بفهمم داستان چی هست و چیزی که شنیدم واقعاً شوکهام کرد. 🤯 کاشف به عمل اومد که فکر میکردن من اونجا هستم تا ریز به ریز کارهاشون رو کنترل کنم، انگار از طرف مدیریت اومدم برای بازرسی و نظارت و بیشتر آدم مدیر هستم، نه کسی که کنارشون هست و باهاشون هممسیره. به عنوان اسکرام مستر، هدفم دقیقاً برعکس این بود! میخواستم کمک کنم کارهای فوقالعادهمون رو روان و راحت انجام بدیم، تیم خوب و همکار بسازیم. اما در عمل، به نظر میرسید من رو مانع اصلی میدیدن. واقعاً دردناک بود.
خب، کلی فکر کردم. چی کار کرده بودم یا چی گفته بودم که این حس رو ایجاد کرده بود؟ و بعد یهو یه چیزی به ذهنم رسید، چیزی ظاهراً کوچک: لحن و کلماتی که به کار میبردم.
متوجه شدم اغلب در جلسات، مخصوصاً وقتی کارها طبق برنامه پیش نمیرفت، به جای «ما»، میگفتم «من» و «اونها». مثلاً اگه به هدف اسپرینت نمیرسیدیم، تو ذهن خودم (و گاهی هم به زبون!) میگفتم «اونها نتونستن انجام بدن»، نه اینکه «ما نتونستیم انجام بدیم.»
تو ذهن خودم، خود رو جلوی تیم میگذاشتم و خوب بعد یک مدت واقعا این اتفاق افتاده بود.
همین تغییر کوچیک تو دیدگاه، یعنی تمرکز روی «ما» و «همهمون»، واقعاً ورق رو برگردوند. فقط بحث کلمات نبود، بلکه طرز فکر پشت اونها هم مهم بود. این باعث شد چالشهاشون رو چالشهای خودمون ببینم، موفقیتهاشون رو موفقیتهای خودمون.
اما ماجرا به همین جا ختم نشد. این درک باعث شد به راههای کوچک اما قدرتمند دیگری برای ارتباط واقعی و ساختن اون حس «تیمی بودن» هم فکر کنم:
واقعاً گوش دادن: نه فقط شنیدن، بلکه واقعاً گوش دادن برای درک دیدگاهها و نگرانیهاشون، حتی وقتی با نظر من فرق داشت.
حضور فعال و موثر: نه فقط حضور فیزیکی تو جلسات، بلکه واقعاً درگیر بودن، سوال پرسیدن و نشون دادن اینکه کار و حالشون برام مهم هست.
جشن گرفتن موفقیتهای مشترک: مطمئن شدن از اینکه موفقیتها را، هرچقدر هم کوچک، جشن میگیریم.
پیدا کردن نقاط مشترک: گاهی به سادگیِ یه قهوه خوردن و چند دقیقه گپ زدن در مورد چیزای غیرکاری بود؛ پیدا کردن اون نقاط مشترک کوچیکی که ما رو به هم نزدیکتر میکنه.
درخواست بازخورد از خودم: اینکه خودم هم ازشون بازخورد بخواهم. پرسیدن اینکه «چطور میتونم بهتر از تیم حمایت کنم؟» نشون میداد که منم با اونها هستم.
بازسازی اعتماد و اینکه کاری کنم احساس کنن واقعاً بخشی از تیم هستم، نه فقط کسی که سعی در کنترل شون داره، زمان و تلاش آگاهانه میخواست.
این درسی هست که هنوز هم بعد از این همه سال با من هست. گاهی بزرگترین موانع، همونهایی هستن که خودمون نادانسته ایجاد میکنیم.
حدود ۹-۱۰ سال پیش، این اتفاق برای من افتاد. تازه به یک تیم جدید ملحق شده بودم، پر از ایده و با اشتیاق واقعی برای اینکه کمک کنم کارهای بزرگی انجام بدهیم و یک تغییر مثبت ایجاد کنیم.
اما خیلی زود متوجه شدم چیزی سر جاش نیست. با اینکه تمام تلاشم را میکردم که با تیم ارتباط برقرار کنم، ولی انگار یک جور دیوار نامرئی بین ما بود. حس میکردم من رو یکی از خودشون نمیدونستن.
یک روز بالاخره تونستم با یکی از اعضای تیم صحبت خودمونی و صادقانه داشته باشم تا بفهمم داستان چی هست و چیزی که شنیدم واقعاً شوکهام کرد. 🤯 کاشف به عمل اومد که فکر میکردن من اونجا هستم تا ریز به ریز کارهاشون رو کنترل کنم، انگار از طرف مدیریت اومدم برای بازرسی و نظارت و بیشتر آدم مدیر هستم، نه کسی که کنارشون هست و باهاشون هممسیره. به عنوان اسکرام مستر، هدفم دقیقاً برعکس این بود! میخواستم کمک کنم کارهای فوقالعادهمون رو روان و راحت انجام بدیم، تیم خوب و همکار بسازیم. اما در عمل، به نظر میرسید من رو مانع اصلی میدیدن. واقعاً دردناک بود.
خب، کلی فکر کردم. چی کار کرده بودم یا چی گفته بودم که این حس رو ایجاد کرده بود؟ و بعد یهو یه چیزی به ذهنم رسید، چیزی ظاهراً کوچک: لحن و کلماتی که به کار میبردم.
متوجه شدم اغلب در جلسات، مخصوصاً وقتی کارها طبق برنامه پیش نمیرفت، به جای «ما»، میگفتم «من» و «اونها». مثلاً اگه به هدف اسپرینت نمیرسیدیم، تو ذهن خودم (و گاهی هم به زبون!) میگفتم «اونها نتونستن انجام بدن»، نه اینکه «ما نتونستیم انجام بدیم.»
تو ذهن خودم، خود رو جلوی تیم میگذاشتم و خوب بعد یک مدت واقعا این اتفاق افتاده بود.
همین تغییر کوچیک تو دیدگاه، یعنی تمرکز روی «ما» و «همهمون»، واقعاً ورق رو برگردوند. فقط بحث کلمات نبود، بلکه طرز فکر پشت اونها هم مهم بود. این باعث شد چالشهاشون رو چالشهای خودمون ببینم، موفقیتهاشون رو موفقیتهای خودمون.
اما ماجرا به همین جا ختم نشد. این درک باعث شد به راههای کوچک اما قدرتمند دیگری برای ارتباط واقعی و ساختن اون حس «تیمی بودن» هم فکر کنم:
واقعاً گوش دادن: نه فقط شنیدن، بلکه واقعاً گوش دادن برای درک دیدگاهها و نگرانیهاشون، حتی وقتی با نظر من فرق داشت.
حضور فعال و موثر: نه فقط حضور فیزیکی تو جلسات، بلکه واقعاً درگیر بودن، سوال پرسیدن و نشون دادن اینکه کار و حالشون برام مهم هست.
جشن گرفتن موفقیتهای مشترک: مطمئن شدن از اینکه موفقیتها را، هرچقدر هم کوچک، جشن میگیریم.
پیدا کردن نقاط مشترک: گاهی به سادگیِ یه قهوه خوردن و چند دقیقه گپ زدن در مورد چیزای غیرکاری بود؛ پیدا کردن اون نقاط مشترک کوچیکی که ما رو به هم نزدیکتر میکنه.
درخواست بازخورد از خودم: اینکه خودم هم ازشون بازخورد بخواهم. پرسیدن اینکه «چطور میتونم بهتر از تیم حمایت کنم؟» نشون میداد که منم با اونها هستم.
بازسازی اعتماد و اینکه کاری کنم احساس کنن واقعاً بخشی از تیم هستم، نه فقط کسی که سعی در کنترل شون داره، زمان و تلاش آگاهانه میخواست.
این درسی هست که هنوز هم بعد از این همه سال با من هست. گاهی بزرگترین موانع، همونهایی هستن که خودمون نادانسته ایجاد میکنیم.
مسئله فقط شغل ما نیست، داستان زندگی است
این روزها اضطرابی عمیق در همه جا موج میزند. همه جا صحبت از هوش مصنوعی و آینده است و در پس این گفتگوها، ترسی بزرگ پنهان شده: ترس از نابودی شغلها.
اولین واکنشی که معمولاً میشنویم: «نگران نباشید، قبلاً هم از این چیزها داشتهایم.» آنها به ما داستان بافندههایی را یادآوری میکنند که دستگاههای نساجی جایشان را گرفت، یا کشاورزانی که زمینهایشان را رها کردند و به کارخانهها رفتند. استدلالشان همیشه یکی است: تکنولوژی شغلهای قدیمی را از بین میبرد، اما شغلهای جدیدی خلق میکند.
حرفشان اشتباه نیست، اما اصل مطلب را نمیبینند.
این بار، داستان کاملاً فرق میکند. برای اینکه بفهمیم چرااین تغییر اینقدر دردناک است، باید عمیقتر نگاه کنیم؛ نه فقط به کاری که مردم انجام میدهند، بلکه به کسی که هستند.
جامعه برای نسلها به ما قول داده بود که مسیر رسیدن به یک زندگی باثبات و محترم، از جادۀ «دانش» میگذرد. به دانشگاه برو. سالها، حتی یک دهه، درس بخوان. در یک مهارت پیچیده استاد شو. پزشک شو، وکیل شو، معمار شو، دانشمند شو.
در ازای این سفر طولانی و طاقتفرسا، جامعه فقط به تو حقوق نمیداد؛ به تو یک هویت میبخشید.
«حرفه» چیزی فراتر از یک شغل است؛ یک «قبیله» است. زبان مخصوص خود را دارد، مرام و مسلک خود را، و نگاه ویژۀ خود را به جهان. «حرفه» داستانی است که برای خودت تعریف میکنی و جامعه دربارۀ تو تعریف میکند.
وقتی کسی میگوید «من یک پزشک هستم»، او فقط شغلش را توصیف نمیکند. او در حال فراخواندن یک روایت کامل است: روایتی از فداکاری، هوش، و... او عضویت خود را در قبیلهای اعلام میکند که فرهنگ ما برایش احترام زیادی قائل است. و البته هویت او با تاروپود این نقش گره خورده است.
این اولین بار در تاریخ است که یک فناوری نه فقط «کار» ما، که «داستانهای» ما را تهدید میکند.
هوش مصنوعی فقط مهارتهای ما را به چالش نمیکشد؛ جایگاه اجتماعی ما را به چالش میکشد. فقط درآمد ما را تهدید نمیکند؛ «معنای» زندگی ما را تهدید میکند. حالا، یک ماشین میتواند آن مسیر را در یک چشم به هم زدن طی کند. و این، یک پرسش هولناک خلق میکند: «اگر یک ماشین میتواند کاری را انجام دهد که من تمام زندگیام را وقف آن کردهام، پس ارزش من چیست؟ من کیستم؟»
به همین دلیل است که توصیۀ سادهانگارانۀ «برو یک مهارت جدید یاد بگیر» اینقدر توخالی به نظر میرسد. مثل این است که به کسی که خانهاش را از دست داده بگوییم نگران نباش، میتوانی مبل جدید بخری. این توصیه، عمق مساله را درک نمیکند. این یک بحران مهارت نیست؛ یک بحران هویت است.
👇👇👇👇👇
این روزها اضطرابی عمیق در همه جا موج میزند. همه جا صحبت از هوش مصنوعی و آینده است و در پس این گفتگوها، ترسی بزرگ پنهان شده: ترس از نابودی شغلها.
اولین واکنشی که معمولاً میشنویم: «نگران نباشید، قبلاً هم از این چیزها داشتهایم.» آنها به ما داستان بافندههایی را یادآوری میکنند که دستگاههای نساجی جایشان را گرفت، یا کشاورزانی که زمینهایشان را رها کردند و به کارخانهها رفتند. استدلالشان همیشه یکی است: تکنولوژی شغلهای قدیمی را از بین میبرد، اما شغلهای جدیدی خلق میکند.
حرفشان اشتباه نیست، اما اصل مطلب را نمیبینند.
این بار، داستان کاملاً فرق میکند. برای اینکه بفهمیم چرااین تغییر اینقدر دردناک است، باید عمیقتر نگاه کنیم؛ نه فقط به کاری که مردم انجام میدهند، بلکه به کسی که هستند.
جامعه برای نسلها به ما قول داده بود که مسیر رسیدن به یک زندگی باثبات و محترم، از جادۀ «دانش» میگذرد. به دانشگاه برو. سالها، حتی یک دهه، درس بخوان. در یک مهارت پیچیده استاد شو. پزشک شو، وکیل شو، معمار شو، دانشمند شو.
در ازای این سفر طولانی و طاقتفرسا، جامعه فقط به تو حقوق نمیداد؛ به تو یک هویت میبخشید.
«حرفه» چیزی فراتر از یک شغل است؛ یک «قبیله» است. زبان مخصوص خود را دارد، مرام و مسلک خود را، و نگاه ویژۀ خود را به جهان. «حرفه» داستانی است که برای خودت تعریف میکنی و جامعه دربارۀ تو تعریف میکند.
وقتی کسی میگوید «من یک پزشک هستم»، او فقط شغلش را توصیف نمیکند. او در حال فراخواندن یک روایت کامل است: روایتی از فداکاری، هوش، و... او عضویت خود را در قبیلهای اعلام میکند که فرهنگ ما برایش احترام زیادی قائل است. و البته هویت او با تاروپود این نقش گره خورده است.
این اولین بار در تاریخ است که یک فناوری نه فقط «کار» ما، که «داستانهای» ما را تهدید میکند.
هوش مصنوعی فقط مهارتهای ما را به چالش نمیکشد؛ جایگاه اجتماعی ما را به چالش میکشد. فقط درآمد ما را تهدید نمیکند؛ «معنای» زندگی ما را تهدید میکند. حالا، یک ماشین میتواند آن مسیر را در یک چشم به هم زدن طی کند. و این، یک پرسش هولناک خلق میکند: «اگر یک ماشین میتواند کاری را انجام دهد که من تمام زندگیام را وقف آن کردهام، پس ارزش من چیست؟ من کیستم؟»
به همین دلیل است که توصیۀ سادهانگارانۀ «برو یک مهارت جدید یاد بگیر» اینقدر توخالی به نظر میرسد. مثل این است که به کسی که خانهاش را از دست داده بگوییم نگران نباش، میتوانی مبل جدید بخری. این توصیه، عمق مساله را درک نمیکند. این یک بحران مهارت نیست؛ یک بحران هویت است.
👇👇👇👇👇
بخش دوم
پس واقعاً چه کاری از دست ما برمیآید؟ چطور باید پیش برویم؟
راه حل، رقابت با ماشینها نیست. راه حل این است که بنیاد خود را روی زمینی بسازیم که تکنولوژی به آن دسترسی ندارد.
۱. هویت خود را از عنوان شغلیتان جدا کنید.
عنوان شغلی یک برچسب است. ارزش واقعی شما در تواناییهای انسانی نهفته در آن است. یک کاغذ بردارید و روی آن ننویسید که چه کاری انجام میدهید، بنویسید در چه چیزی خوب هستید.
- به جای «من طراح گرافیک هستم»، بنویسید: «من در انتقال احساسات از طریق تصویر یک متخصصم. من به ایدههای پیچیده شفافیت میبخشم.»
- به جای «من مدیر پروژه هستم»، بنویسید: «من کسی هستم که از دل آشفتگی، نظم میآفریند. من در یک تیم اعتماد میسازم تا به بهترین نتیجه برسند.»
عناوین شغلی شکنندهاند. اما این تواناییهای انسانی، دائمی هستند. اینها سرمایۀ شما برای ورود به هر آیندۀ جدیدی است.
۲. بر مهارتهای منحصراً انسانی مسلط شوید.
هوش مصنوعی میتواند اطلاعات را پردازش کند، یک متن بنویسد و یک مسئله را تحلیل کند. اما نمیتواند روبروی یک مشتری بنشیند و رابطهای بر پایۀ اعتماد بسازد. نمیتواند یک همکار جوانتر را با همدلی راهنمایی کند. نمیتواند در یک موقعیت پیچیده، یک تصمیم اخلاقی شجاعانه بگیرد. این بخش نهایی کار – جایی که خرد، ارتباط انسانی و شخصیت حرف اول را میزند – قلمرو انسان باقی خواهد ماند. روی این مهارتها سرمایهگذاری کنید.
این یک گذار دشوار است و باید در مورد آن صادق باشیم. این مسیر از ما میخواهد که معنای خود را در جایی فراتر از کارت ویزیت یا شرح وظایفمان پیدا کنیم. وظیفۀ پیش روی ما، ساختن هویتی آنچنان استوار و انسانی است که هیچ تغییر فناورانهای دیگر هرگز نتواند آن را تهدید کند.
پس واقعاً چه کاری از دست ما برمیآید؟ چطور باید پیش برویم؟
راه حل، رقابت با ماشینها نیست. راه حل این است که بنیاد خود را روی زمینی بسازیم که تکنولوژی به آن دسترسی ندارد.
۱. هویت خود را از عنوان شغلیتان جدا کنید.
عنوان شغلی یک برچسب است. ارزش واقعی شما در تواناییهای انسانی نهفته در آن است. یک کاغذ بردارید و روی آن ننویسید که چه کاری انجام میدهید، بنویسید در چه چیزی خوب هستید.
- به جای «من طراح گرافیک هستم»، بنویسید: «من در انتقال احساسات از طریق تصویر یک متخصصم. من به ایدههای پیچیده شفافیت میبخشم.»
- به جای «من مدیر پروژه هستم»، بنویسید: «من کسی هستم که از دل آشفتگی، نظم میآفریند. من در یک تیم اعتماد میسازم تا به بهترین نتیجه برسند.»
عناوین شغلی شکنندهاند. اما این تواناییهای انسانی، دائمی هستند. اینها سرمایۀ شما برای ورود به هر آیندۀ جدیدی است.
۲. بر مهارتهای منحصراً انسانی مسلط شوید.
هوش مصنوعی میتواند اطلاعات را پردازش کند، یک متن بنویسد و یک مسئله را تحلیل کند. اما نمیتواند روبروی یک مشتری بنشیند و رابطهای بر پایۀ اعتماد بسازد. نمیتواند یک همکار جوانتر را با همدلی راهنمایی کند. نمیتواند در یک موقعیت پیچیده، یک تصمیم اخلاقی شجاعانه بگیرد. این بخش نهایی کار – جایی که خرد، ارتباط انسانی و شخصیت حرف اول را میزند – قلمرو انسان باقی خواهد ماند. روی این مهارتها سرمایهگذاری کنید.
این یک گذار دشوار است و باید در مورد آن صادق باشیم. این مسیر از ما میخواهد که معنای خود را در جایی فراتر از کارت ویزیت یا شرح وظایفمان پیدا کنیم. وظیفۀ پیش روی ما، ساختن هویتی آنچنان استوار و انسانی است که هیچ تغییر فناورانهای دیگر هرگز نتواند آن را تهدید کند.