اگه قسمت اول این نوشته رو نخوندید، لطفا قبلش اون رو بخونید.
تو قسمت قبلی در مورد پیچیده بودن یه سازمان گفتیم و یه مقدار در مورد اینکه ساختار سازمانی مناسب برای هر سازمان به چیا بستگی داره صحبت کردیم. بعد یه کم به ویژگی‌ها و مدل کارکردن با آدم‌های تخصص‌گرا و آچارفرانسه‌ها پرداختیم و در انتها هم یه مقدار در مورد اینکه تیم و سازمان چرا باید لیدرهای غیررسمی داشته باشه و چرا باید عناوین شغلی آدم‌ها گسترده باشه گفتیم. این قسمت، ادامهٔ داستان رو می‌ریم جلو.
یه جاهایی تیم‌ها ممکنه مرز مشخصی نداشته باشن توی سازمان. هم ممکنه آدم‌هایی باشن که معلوم نیست دقیقا عضو کدوم تیم‌هان، هم کارهایی باشه که معلوم نیس کدوم تیم مسئولشه. هر کدوم از این دو حالت رو که دیدید بهتره دست به کار بشید و به عنوان مدیر تیم سعی‌تون رو بکنید که مرز‌ها مشخص‌تر بشه. تیم بودن و تلاش کردن برای هدف تیم، زمانی معنی داره که آدم‌ها خودشون رو عضوش بدونن و تعلق خاطر داشته باشن بهش. همچنین، مرز‌بندی باید جوری باشه که کارها هم معلوم باشه مسئولشون و سر هر کاری اعضای یه تیمی بدونن که این کار ماس و ما باید درستش کنیم.
یه چیزی هم که بعضی وقت‌ها پیش میاد و سخت هم هست حل کردنش، اینه که کسایی داشته باشین که عضو بیشتر از یه تیم باشن. اتفاقی که میوفته اینه که فرد معمولا خودش رو متعلق به هیچ کدوم نمی‌دونه و یه جایی اون وسط سرگردان می‌شه. البته منظور این نیست که هر نفر فقط با یه تیم کار داشته باشه. آدم‌ها توی تیم‌های مختلف می‌تونن (و خوبه که) علاوه بر هم‌تیمی‌های خود، به یاری کسای دیگه توی تیم‌های دیگه هم بشتابن و کمکشون بکنن. ولی نهایتا اگه خودشون رو عضو یکی از تیم‌ها بدونن بهتره.
من خودم بدترین عملکردم تو دوره‌هایی بوده که عضو چندتا تیم بودم همزمان. گرچه خودم فکر می‌کردم دارم خوب عمل می‌کنم و هیچ مشکلی نیست. توی کوتاه‌مدت هم ممکنه که واقعا بتونین درمجموع ارزش خوبی خلق بکنین برای سازمان ولی آدم خیلی سریع میوفته تو سراشیبی و افت عملکرد.
توی اسکرام می‌گن تعداد اعضای تیم باید ۷ به‌اضافه/منهای ۲ نفر باشه (چون از ۵ تا ۹ نفر علمی‌تر به نظر میاد اینجوری). جاهای دیگه و کسای دیگه هم حرفای دیگه‌ای می‌زنن. یه جا می‌گن ۸، یه جا می‌گن ۳ تا ۹، ولی اینا اصن مهم نیست و هیچ قانونی رو نباید گوش بدید تو این مقوله. دوتا چیز مهمه فقط: یکی اینکه تعداد تیم نباید از یه حدی کمتر باشه که تیم بودنه معنیش رو از دست بده و با کار کردن تنهایی فرقی نداشته باشه، و دومی هم اینکه از یه حدی هم نباید بیشتر باشه که کارهای تیم انقدر متنوع و گسترده بشه که دیگه آدم‌ها نتونن در راستای هدف مشترک کار کنن. کلا سایز مناسب برای تیم، به جنس کار تیم، محیطی که دارن توش کار می‌کنن و ارتباط‌شون با بقیه سازمان و به خود آدم‌هایی که توی تیم هستن خیلی ربط داره. یه جایی ممکنه تیم ۱۵ نفره خیلی خوب جواب بده و کارها خوب پیش برن و آدم‌ها هم خوشحال باشن، یه جا ولی تیم ۱۵ نفره خوبه تقسیم بشه به ۳ تا تیم ۵ نفره که کار بهتر پیش بره.
احتمالا مراحل شکل‌گیری و ساخته‌شدن تیم‌ها رو قبلا بهش برخوردین. بروس تاکمن می‌گه که تیم‌ها ۵ مرحله رو پیش رو می‌ذارن تو عمرشون:
Forming, Storming, Norming, Performing, Adjourning
توی مرحلهٔ Forming، تیم هنوز تازه داره شکل می‌گیره، آدم‌ها دنبال اینن که کی قراره چیکاره بشه و تیم قراره چیکار کنه و من باید چیکار کنم و چه انتظاری از من می‌ره و اینا. آدم‌ها هم خیلی نمی‌شناسن هم رو چون به احتمال زیاد کار نکردن باهم خیلی. تو مرحله بعدی ینی Storming، کم‌کم آدم‌ها شروع می‌کنن سوالات قسمت‌های قبلی رو جواب دادن. چون آدم‌های تیم تو این مرحله هنوز فضاهای ذهنی و تصورشون از تیم باهم خیلی فرق داره، ممکنه کلی باهم conflict بخورن (اگه نخورن عجیبه) و روی اهداف و کارها و کلی چیز دیگه بزنن تو سر و کله هم. نهایتا توی مرحله Norming، این دعواها می‌تونه تموم شده باشه و یه جورایی اعضا باهم متحد شده باشن و بدونن کلا قراره چیکار کنن. تو این مرحله‌س که دقیق‌تر می‌فهمن هر کسی قراره چیکار کنه و رهبر تیم کیه و وظایفش چیه. آروم آروم بهره‌وری تیم افزایش پیدا می‌کنه و کار شروع می‌کنه به جلو رفتن. اگه همه چی خوب پیش بره و آدم‌ها دوباره دعواهای جدید شروع نکنن (و برنگردن مرحله قبلی) تیم کم‌کم می‌ره تو مرحله بعدی که درخشان‌ترین مرحلهٔ تیمه، ینیز Performing. همون‌طور که از اسمش معلومه، این دوران، دورانیه که تیم دقیقا خودش رو پیدا کرده و ساخته و هرکی می‌دونه باید چیکار کنه و هدف‌ها و ساختار و مدل تصمیم‌گیری و ... مشخصه. مشکلات و بحث و جدل هم پیش میاد، ولی تیم بلده چجوری حلش کنه. تیم تو این دوره می‌تونه مثل تیراختور کار کنه و خروجی بده. ولی هر اومدنی رفتنی هم ممکنه داشته باشه. وقتی تیم به هدف‌هاش رسید، کارها رفته‌رفته به سرانجامشون رسیدن و ارزش‌هایی که قصد داشتیم خلق کنیم، خلق شدن، کم‌کم دیگه کار تیم تمومه و وارد مرحله Adjourning می‌شیم. تو این مرحله می‌تونیم کارها رو دیگه جمع و جور کنیم و اعضای تیم برن دنبال تیم‌ها و کارهای دیگه.
دشمن رشد کردن تیم‌ها، دخالت از بیرون و اعمال تغییرات زیاده. درسته که تطبیق‌پذیری از ویژگی‌های خوبیه که تیم‌ها و آدم‌هاشون باید داشته باشن، ولی اینکه تیم‌ها نیاز داشته باشن بیشتر از حدی که باید، خودشون رو تطبیق بدن، کار رو براشون سخت می‌کنه. اگه دمای آب با سرعت کمی کم بشه، بلورهای یخی که تشکیل می‌گیره شکل منظم‌تر داره، ولی اگه سریع دما رو کم کنید، بلورها نامنظم می‌شن. شکل‌گیری تیم‌ها هم هیچ ربطی به بلورهای یخ نداره و کاملا یه موضوع جداس.
توی سال ۹۸، ما توی بلد تغییرات خیلی زیادی توی تیم‌ها و ساختار سازمانی دادیم. بعضی تیم‌ها عمرشون به یه فصل هم نمی‌رسید و تا آدم‌ها بیان وارد مراحل توسعه تیم بشن، تیمه تموم شده بود و باید می‌رفتن سراغ انجام کارها توی تیم بعدی. هرچند روی کاغذ و در تئوری، تغییرات همیشه رو به جلو بوده، ولی در عمل باعث کلافه شدن آدم‌ها و کندتر انجام شدن بعضی کارها شد. البته این رو هم بگم که بچه‌ها خیلی خوب خودشون رو با شرایط وفق دادن و ترکوندن.
در ادامه، به مدل چیدن تیم‌ها در سازمان می‌پردازیم.
حالا مسئله اینه که چجوری سازمان رو به چندتا تیم بشکونیم. به صورت کلی دو تا راه برای این کار وجود داره. شکستن حول تخصص یا حول محصول و هدف بیزنسی. این دو در کتاب، functional و cross-functional گفته شده ولی من ترجمه درستی نتونستم پیدا کنم و یه ذره دست‌کاریش کردم.
تیم تخصص‌محور یا functional تیمیه که آدم‌ها توش تخصص مشابه دارن. مثلا تیم اندروید یه محصول، یا تیم مهندسین داده توی یه محصول. آوردهٔ تیم‌های تخصص‌محور، بازده بالا و یادگیری بهتره. وقتی ۴ تا توسعه‌دهندهٔ اندروید کنار هم می‌شینن و باهم تشکیل یه تیم می‌دن و پیوسته باهم ارتباط دارند، طبیعتا چیزهای بیشتری از هم یاد می‌گیرن و از کار هم بیشتر خبر دارن.
تیم محصول‌محور یا cross-functional تیمیه که آدم‌هاش حول برآورده کردن یه هدف بیزنسی، یا به سرانجام رسوندن یه زیرمحصول، یا کار روی رفع نیازهای یه نوع کاربر خاص دورهم جمع شده‌اند. در این حالت، تمرکز بیشتری روی رسوندن اون ارزش محصولی انجام می‌شه ولی خب ویژگی‌های تیم تخصص‌محور رو دیگه نداره.
اگه بتونیم ارتباطات روزمره بین تیم‌ها و آدم‌ها رو یه جوری تحلیل کنیم، به این نتیجه خواهیم رسید که اکثر هماهنگی‌ها و صحبت‌ها حول محصول و ارزش محصولی و بیزنس شکل می‌گیره؛ تا حول تخصص. لذا چند نفر با تخصص مختلف که روی یه پروژه کار می‌کنند، نیاز به تعامل و ارتباط بیشتری باهم دارند، تا چند نفر با تخصص‌های مشابه که روی چند تا پروژه کار می‌کنند. پس به صورت کلی اگه بخوایم بگیم، اگه یه سازمان به تیم‌های محصول‌محور شکسته شده باشه، بهتر عمل می‌کنه. مثال تیم‌های بازار رو توی قسمت اول این نوشته زدم، مشکلی که در حالت تیم‌های تخصص‌محور وجود داره اینه که برای انجام هر کاری نیازه که کلی هماهنگی و ارتباط صورت بگیره در صورتی که توی تیم‌های محصول‌محور، چون آدم‌ها دارن روی یه چیز مشترک کار می‌کنن این هماهنگی‌ها خیلی کمتر و خلاصه‌تر و درون تیم شکل می‌گیره.
ما زمانی که توی کافه‌بازار از سه تا تیم تخصص‌محور تشکیل شده بودیم، یادمه که وقتی داشتیم کارت هدیه بازار رو راه می‌نداختیم، نیازمند این بودیم که هم کلاینت بازار یه تغییراتی بکنه و امکان بازیابی و افزایش اعتبار با کارت هدیه بهش اضافه بشه، هم تیم پرداخت نیاز داشت یه کارهایی انجام بده حول این موضوع و هم تیم بک‌اند کافه‌بازار. یادمه که انجام این کار خیلی بیشتر از چیزی که فکر می‌کردیم طول کشید. دلیلش این بود که هر کدوم از این سه تا تیم گفته شده ایتریشن خودشون رو داشتند و کاره باید تعریف می‌شد و می‌رفت توی ایتریشن این سه تا تیم که لزوما باهم هماهنگ نبود. علاوه بر هماهنگ نبودن زمانی (که حالا شاید این رو می‌شد کاری کرد) اولویت تیم‌ها متفاوت بود. مثلا یکی از این سه تا تیم یه موضوع مهمی براش پیش اومده بود و نیاز بود که دو ایتریشن روش کار بکنه و این باعث می‌شد کل کار کارت هدیه بخوابه. بعد مشکل دیگه‌ای که پیش اومد این بود که وسط کار فهمیدیم یه چیزهایی رو باید تغییر بدیم و نیازمند این بود که این تغییره دوباره توی هر سه تا تیم اتفاق بیوفته و دوباره اجرای کار عقب افتاد. یه مشکل دیگه که به نظرم اصلی‌ترین مشکل تیم‌های تخصص‌محور می‌تونه باشه، این بود که هیچ کدوم از این تیم‌ها خودشون رو صاحب این کاره نمی‌دونستن. نه اینکه بگیم شل می‌گرفتن کار رو، مشکل این بود که این کار رو در راستای اهداف تیم‌ها نمی‌دونستن. در صورتی که اگه اون موقع ما یه تیم مثلا درآمد داشتیم، یکی از اهداف این تیم می‌تونست افزایش درآمد باشه و یه راهش هم این باشه که کارت هدیه رو توسعه بدن و کمکی بکنه به افزایش درآمد (کارت هدیه راهی بود برای اینکه کسایی که رمز اینترنتی ندارن و سختشونه، بتونن از خدمات بازار استفاده کنن). اینجوری اعضای این تیمه با پوست و استخون درک می‌کردن که چرا باید فیچر کارت هدیه رو بدیم (یا چرا نباید بدیم) و کار اندروید و بک‌اند و هماهنگی‌هاش هم داخل یه تیم انجام می‌شد و سریع‌تر می‌رفت جلو.
ولی اگه انقد مسائل بدیهی و راحت بود، تیم‌های تخصص‌محور توی نسل‌های اولیه بشر در اثر انتخاب طبیعی منقرض شده بودن و الان موضوع بحث ما نبودن. در تیم‌های محصول‌محور هم مشکلاتی پیش میاد. فرض کنید ۲ نفر توسعه‌دهندهٔ اندروید داریم و دو تا تیم محصول‌محور. حالا می‌شه این ۲ نفر هر کدوم برن توی یه تیم محصولی و کارهای اون تیم رو انجام بدن، می‌شه هم این ۲ نفر باهم تشکیل یه تیم سومی رو بدن و روی کارهای اندرویدی اون دوتا تیم محصول کار بکنن. در حالت اول (که تیم تخصص‌محور نداریم) ارتباط بین این دو توسعه‌دهنده اندروید کم خواهد شد و انتقال دانش و تجربه خیلی کمتر از حالت دوم خواهد بود. ممکنه در حالت دوم بتونیم راحت‌تر نسخهٔ جدید اندرویدمون رو برهانیم (ریلیز بدیم) چون این دو بزرگوار از هم بیشتر خبر دارند و می‌دونن کدوم کار تا فلان موقع می‌رسه و کدوم نمی‌رسه.
ساختار محصول‌محور نسبت به تخصص‌محور ایرادای دیگه هم داره. معمولا این اتفاق پیش میاد که توی ساختار محصول‌محور، یه سیستم‌های فنی‌ای بین چندتا تیم محصولی مشترکه و احتمال یتیم شدنش بیشتره. ینی اینکه کسی سیستم رو نرسه بهش، همه صرفا بخوان دنبال فیچر دادن روش باشن و بهبود‌های فنی روی اون سیستم برای کسی اولویت نباشه.
نهایتا اگه فرض کنیم سازمان از چندتا تیم محصول‌محور و چندتا تیم تخصص‌محور تشکیل شده، چندتا موضوع هست که خوبه حواسمون باشه:
کلا در هر سازمانی، بسته به شرایط آدم‌ها و محصول و ... ممکنه که هر کدوم از این دو ساختار (و یا ترکیبی از این دو) انتخاب بهتری باشه و بهتر جواب بده. منتهی به صورت کلی، تصمیم‌های بهتر بیزنسی و محصولی، کمتر شدن اتلاف وقت و انرژی به خاطر هماهنگی‌ها، سرعت توسعه و دلیوری بیشتر، برنامه‌ریزی ساده‌تر، و تمرکز بیشتر روی رسوندن ارزش توی تیم‌های محصول‌محور بیشتره. در مقابل، هر جای بهینه بودن یه کاری خیلی موضوع مهمی شد، ممکنه تشکیل یه تیم تخصص‌محور حول اون موضوع کار خوبی باشه.
در ادامه یه مقدار به حضور سلسله‌مراتب (hierarchy) در سازمان می‌پردازیم.
بحث وجود سلسله‌مراتب در سازمان یا عدم وجودش خیلی فلسفیه و اینجا کاری باهاش نداریم. فرض رو می‌ذاریم اینکه یه حدی از سلسله‌مراتب باید باشه و البته یه مقدار هم بهش خواهیم پرداخت که چرا. خوبی سلسله‌مراتب اینه که کارها توی لایه‌های مختلف با انگیزه‌ها و ملاحظات خودش بررسی می‌شن و هرکی می‌تونه کار خودش رو بهتر انجام بده. مثلا توسعه‌دهندهٔ یه تیم، بیشتر تمرکزش رو به کاری که در دست داره اختصاص می‌ده و سعی می‌کنه اون رو خوب انجام بده. مدیرمحصول همون تیم، علاوه بر کارهای در دست تیم، به آیندهٔ نزدیک هم نگاه می‌کنه و احتمالا مدیرعامل اون سازمان، خیلی بیشتر با آینده ممکنه درگیر باشه نسبت به مدیرعامل. ولی سلسله‌مراتب و حتی کلی‌ترش، ساختار، دلیل وجودیش کاهش دادن ارتباطات و هماهنگی‌ها به حد لزومه و طبیعتا پتانسیل این رو داره که تهدیدی باشه به مشکلات ارتباطی و جاری شدن اطلاعات در سازمان. همون‌قدر که وجود سلسله‌مراتب می‌تونه با لایه لایه کردن دغادیغ (جمع مکسر دغدغه) و اختیارات، به بهتر پیش رفتن کارها کمک کنه، می‌تونه کار رو خراب کنه و باعث بشه اطلاعات و جریانش هم لایه لایه بشه.
به باور نویسنده این کتاب، شبکه اطلاعات تو یه سازمان در کنار سلسله‌مراتب و موازی باهاش وجود داره. سلسله‌مراتب حالتی درخت‌وار داره و ۱ نفر مدیر n نفره و هر کدوم از اون n نفر هم ممکنه مدیر m نفر دیگه باشن. در حالی که شبکه اطلاعات، ساختار درختی نداره و همون‌طور که اسمش روشه، یه شبکه است.
شبکه اطلاعات غیررسمیه، به این معنی که نقش و وظیفه و اینایی نداره، ولی سلسله‌مراتب رسمیه. یه مثال، فرض کنید که تیم پرداخت بازار می‌خواد روی کارت هدیه کار بکنه. اصل این تصمیم و حساب کتابش و مدل توزیعش و عواقبش و اینا رو فرض کنیم مدیرعامل می‌گیره. بعد مدیر محصول جزئیات رو درمیاره و کار رو به قسمت‌های قابل اجرا تقسیم می‌کنه. بعد این کار توی ایتریشن تیم پرداخت مطرح می‌شه و قرار می‌شه که بچه‌های تیم انجامش بدن و نهایی که شد، اعلام بکنن که بازار همچین کاری کرده. چیزایی که گفته شد همه در مورد سلسله‌مراتب بود. حالا شبکه اطلاعات چیکار می‌کنه؟ بحث کارت هدیه رو یکی از توسعه‌دهنده‌های تیم می‌تونه به ذهنش رسیده باشه، بعد به مدیرعامل گفته باشه. بعد مدیرعامل رفته با مدیرمحصول و توسعه‌دهنده‌هاش یه جلسه گذاشته و صحبت کردن در موردش. در مورد قیمت‌هاش و اینکه چه مبلغ کارت‌هایی باید باشه یکی از توسعه‌دهنده‌های تیم یه ایده‌ای به ذهنش رسیده و با مدیر محصول مطرح کرده. مدیر محصول با مدیرعامل تو جلسه بعدیش رفته در موردش صحبت کرده و بعد قرار شده خود توسعه‌دهنده هم بهشون اضافه بشه و در موردش صحبت کنن. بعد سر اینکه ببینن کارت هدیه جاهای دیگه چقد استفاده‌ش سخته یا راحته، باهم رفتن و چندتا جا رو امتحان کردن و ...
اینایی که گفتیم، شبکه اطلاعاته. اطلاعات در تیم و سازمان باید جریان داشته باشه و سلسله‌مراتب جلوش رو نگیره. تو همین مثال می‌تونید راحت تصور کنید که هر کدوم از نفرات توی سلسله‌مراتب می‌تونن جلوی جریان اطلاعات توی این شبکه رو بگیرن و کار رو خراب کنن. نتیجه‌ش اینه که تیمی که با دل و جون روی این فیچر محصولی قرار بود کار کنه، اصن خبر نداره چی شد که می‌خوایم کارت هدیه بدیم، چه جزئیاتی دیگه‌ای داره، بعدا می‌خوایم گسترشش بدیم یا داریم تست می‌کنیم، مطمئنیم داریم این کارو می‌کنیم یا نه و کلی سوال دیگه که جوابش برای تیم نامعلومه. خیلی فرق می‌کنه تیمی که قراره صرفا قسمت فنی کار رو انجام بده، از جوانب محصولی کار خبر داشته باشه یا نداشته باشه. نتیجه محصولی و حتی نتیجه فنی تولیدشده رو هم زیر و رو می‌تونه بکنه بودن یا نبودن جریان اطلاعات.
مدیریت یه سازمان، باید از خداش باشه که اطلاعات به نرمی در شبکه جریان پیدا بکنه و لنگ سلسله‌مراتب نباشه و مستقل ازش کار کنه. جریان اطلاعات رو نه تنها نباید کنترل یا بلوکه کرد، بله باید بهش بها هم داد و تقویتش هم کرد.
خود سلسله‌مراتب هم نباید از حدی که نیازه پیچیده‌تر باشه. وجود لایه‌های بیشتر از حد لازم در یه سازمان می‌تونه باعث بشه یه تعداد مدیر اون وسط‌ها باشن و از بیکاری جلوی کار کردن بقیه رو بگیرن. هر لایه مدیریتی باید دقیقا مشخص باشه که چه کاری داره می‌کنه و چه مسئله‌ای رو حل می‌کنه که لایه زیریش و بالاییش نمی‌تونه حل کنه یا بهتره حل نکنه و درگیرش نباشه.
در قسمت پایانی این نوشته، به چندتا نکته و توصیه ریز ولی مهم هم می‌پردازیم و دیگه می‌بندیمش.
به اعتقاد نویسنده، اکثر مشکلات موجود در پروژه‌های نرم‌افزاری، به خاطر ارتباط‌های نادرسته. (bad communications). واسه اینکه ارتباط‌های خوبی داشته باشیم، سه تا چیز لازمه، افراد سازمان اطلاعات کافی از سازمان داشته باشن، روابط خوب بین آدم‌ها برقرار باشه و آدم‌ها بازخورد مناسب رو بگیرن. برای اینکه اطلاعات کافی باشه، باید هرچی که می‌شه رو عمومی کنیم و در دسترس افراد سازمان بذاریم. حتی چیزایی که ممکنه فک کنید به درد کسی نمی‌خوره رم عمومی کنید و فکر اونش رو نکنید. هرچی بیشتر بهتر. کد‌ها، مستندات، استراتژی، فایل‌ها، طراحی‌ها، روند پیشرفت تیم‌ها، هرچی که می‌تونید و سازمان‌تون بلوغش رو داره که بدونه.
یه کاری کنید چیزایی که عمومی می‌کنید، تو چشم هم باشن. مثلا اهداف سازمان، استراتژیش، نتایجی که تیم‌ها بهش می‌رسن و قله‌هایی که فتح می‌کنید. هرچی چیزها بیشتر تو چشم باشن، تاثیر بیشتری روی آدم‌ها می‌ذاره و آدم‌ها ناخودآگاه دنبال چیزای خوبی که می‌بینن می‌رن.
نکته آخر هم اینکه تغییر، لازمه خیلی از اتفاقات خوبه و خیلی جاها هم موقع ایجاد یه تغییر مطمئن نیستیم اتفاق خوبی بیوفته یا اتفاق بدی. یه جاهایی برای رسیدن به یه نتیجه خوب، باید تغییری بدیم که در کوتاه‌مدت نتایج بدی داره ولی ناگزیره. یه جاهایی هم ممکنه نتیجه موردنظر از یه تغییر رو نگیریم و لازم باشه تغییر رو برگردونیم. چیزی که همهٔ این تغییرات رو برای همهٔ آدم‌های سازمان آسون‌تر می‌کنه و باعث می‌شه بشه چابک‌تر رو به جلو حرکت کرد، وفق‌پذیری (adaptability) آدم‌های سازمانه. اگه آدم‌ها وفق‌پذیر نباشن، به جای درگیر شدن با خود تغییر و بهتر اجرا کردنش، باید با اعضای تیم‌تون سر درست و غلط بودن تغییر سر و کله بزنید و به جای ارزیابی کردن نتایج یه تغییر، باید وقتتون رو صرف راضی کردن آدم‌های ناراضی‌ای بکنید که راضی نیستند از محدوده امن خودشون خارج بشن و صرفا می‌خوان تغییری اتفاق نیوفته.
این مقاله و قسمت قبلیش، خلاصه و جمع‌وجورشدهٔ بخش‌هایی از فصل ۱۳ کتاب Management 3.0 نوشتهٔ Jurgen Appelo با اندکی تغییر و تفسیر است. این کتاب، کتابی بسیار زیبا و با ارزش است و خوندنش رو اکیدا به علاقه‌مندان توصیه می‌کنم.
