نکات کلیدی
- معماری یک محصول نرمافزاری توسط تصمیمها و بهخصوص بدهبستانهایی (trade-off) تعریف میشود که تیم توسعه انجام میدهد. شفافکردن این تصمیمها و بدهبستانها برای یک معماری نرمافزاری موفق ضروری است.
- تیمهای توسعه باید برای اثبات (یا رد) تصمیمهایشان آزمایش کنند؛ آنها نمیتوانند صرفاً طراحی را مرور کنند تا بازخوردی را که برای اصلاح تصمیمها لازم دارند به دست آورند. برای بسیاری از تیمها، این یک تغییر بسیار بزرگ است که زمان میبرد تا در آن ماهر شوند.
- تیمها باید هنگام توسعه سیستم، این تصمیمها را بگیرند و آزمایشهای معماری را بهصورت پیوسته اجرا کنند. هر بار که قابلیت جدیدی اضافه میکنند یا چیزی را تغییر میدهند، باید اثرات معماری آن تغییرات را در نظر بگیرند. در نتیجه، در تلاش توسعه نرمافزار هیچ «فاز معماری» جداگانهای وجود ندارد.
- سازمان باید حاضر باشد بازخوردی را که از اجرای آزمایشها به دست میآورد بپذیرد. باید بر سوگیریهای تأییدی خود غلبه کند و آماده باشد «واقعیتهایی» را که «میداند» درست هستند کنار بگذارد، وقتی بازخورد نشان میدهد خلاف آن است.
- تیمها برای تغییر به کمک هم نیاز دارند. بهاشتراکگذاشتن تجربهها، چه خوب چه بد، به نزدیکترشدن افراد و یادگرفتن از یکدیگر کمک میکند.
- سختیِ تغییر فرهنگ سازمان را دستکم نگیرید. برای عبور از این مانع، با توسعه تکمحصولی شروع کنید و از همانجا حمایت و علاقه برای کارکردن به روش جدید ایجاد کنید.
مقدمه
در مجموعهای از مقالههای قبلی، ما مزایای مفهوم «معماری چابک» را توضیح دادهایم و بررسی کردهایم؛ مفهومی که آن را رویکرد حداقل معماری قابلاتکا یا Minimum Viable Architecture (MVA) مینامیم. رویکرد MVA بر مجموعهای ساده از ایدهها استوار است:
-
معماریها نه با مجموعهای از نمودارها یا اسناد، بلکه با مجموعهای از تصمیمهای حیاتی درباره اینکه سیستم چگونه نیازمندیهای ویژگیهای کیفی (QARها یا اهداف کیفی) را برآورده میکند و بدهبستانهایی که تیم مجبور است انجام دهد اگر نتواند اهداف کیفی را کاملاً برآورده کند، تعریف میشوند.
-
این تصمیمها بهطور مداوم توسط تیم بازبینی میشوند، همزمان با اینکه درک آنها از اهداف سیستم و نیازمندیهای ویژگیهای کیفی بیشتر میشود، بر پایه تجربهای که از طریق آزمایشکردن به دست میآورند.
-
ممکن نیست بدون اینکه بخشی از سیستم را بسازید و آزمایش کنید بدانید معماری سیستم «برای هدف» مناسب است یا نه.
-
معماری یک سیستم بهعنوان بخشی از مجموعهای از انتشارهای افزایشی محصول ساخته میشود که ارزش سیستم را آزمایش و اعتبارسنجی میکنند. ما این را در قالب مجموعهای از انتشارهای افزایشی حداقلی (محصولات حداقلی قابلاتکا یا Minimum Viable Products) بیان میکنیم که فرضیهها درباره ارزش سیستم را میآزمایند.
-
هر یک از این نکتهها تیمها و سازمانشان را مجبور میکند شیوه توسعه سیستمها را بهطور قابل توجهی تغییر دهند: از توانمندسازی تیمها برای تصمیمگیری، تا پذیرفتن اینکه سنجش مناسببودن معماری بدون ساختن چیزی ممکن نیست، تا پذیرش بازکاری (rework) ناشی از بازخوردی که نشان میدهد معماری نیاز به بهبود دارد.
این تغییرات بسیاری از فرضهای نانوشتهای را به چالش میکشد که سازمانها درباره مدیریت کارشان دارند، و تغییر ذهنیتهایی که پشت این فرضهاست زمان میبرد. همانطور که رویکرد MVA معماری سیستم را در یک گام ایجاد نمیکند، پذیرش رویکرد MVA هم به مجموعهای از گامهای افزایشی نیاز دارد.
با یک تیم توسعه شروع کنید
تمام تغییرها با یک تیم شروع میشود؛ تیمی که این ایده به ذهنش میرسد که میتواند متفاوت کار کند و نتیجه بهتری بگیرد. مهم است که فقط با یک تیم شروع کنید، چون باید قبل از اینکه بخواهید همه تیمهای سازمان را قانع کنید که باید متفاوت کار کنند، ثابت کنید این رویکرد حداقل برای یک تیم جواب میدهد.
در اینجا رویکرد MVP/MVA یک مشابه دارد: باید تغییرهای کوچک ایجاد کنید و درباره اثربخشی آنها بازخورد بگیرید تا بتوانید درباره شیوه کارکردن تصمیمهای درست بگیرید. این تغییرهای کوچک اغلب در گامهای زیر تجربه میشوند.
گام ۱: باورهای محدودکننده را به چالش بکشید
باورهایی که معمولاً و بهصورت ضمنی پذیرفته شدهاند میتوانند سختترین مانع باشند، چون هرگز بهطور صریح گفته نمیشوند و بنابراین هرگز به چالش کشیده نمیشوند. این باورها شامل موارد زیر است:
-
سیستم را نمیتوان بهصورت مجموعهای از افزایشها تحویل داد. اگر افراد باور داشته باشند که برای ارزشمندبودن انتشار اول باید «همه چیز» در همان انتشار باشد، هیچ فرصتی برای تحویل افزایشی وجود نخواهد داشت. نخستین گام برای غلبه بر این باور این است که همه توافق کنند تحویل زیرمجموعهای از سیستم به زیرمجموعهای از کاربران بالقوه محصول نهایی، ارزشمند است.
-
«نیازمندی» مشتری/کاربر باید قبل از شروع توسعه کاملاً فهمیده شود. مشکل فهم نیازهای مشتری/کاربر این است که خودِ مشتریها/کاربران هم این نیازها را دقیق نمیفهمند. بهجای اینکه از کاربران بپرسید در یک راهحل چه میخواهند، بهتر است بپرسید چه چیزی را میخواهند به دست بیاورند و بعد راهحلی طراحی کنید که به آنها کمک کند به نتیجه مطلوب برسند. تحویل افزایشی سیستم و اصلاح آن بر اساس بازخوردشان به آنها اجازه میدهد در تعریف راهحل مشارکت کنند، بدون اینکه مجبورشان کنید همه چیز را از ابتدا مشخص کنند.
-
کل سیستم باید توسعه داده شود تا بتوان چیزی از آن را تست کرد. این باور اغلب از میل مدیریت برای کاهش اتلاف میآید: «چرا چیزی را تست کنیم که میدانیم هنوز تمام نشده؟» تیمها لازم نیست TDD را کاملاً بپذیرند تا بتوانند همزمان با توسعه سیستم، پیوسته تست کنند؛ این فقط یک عمل خوب مهندسی نرمافزار است که با نوشتن کد ماژولار و جداسازی دغدغهها همراه است.
-
نیازهای مشتری و QARهای مرتبط با آنها ثابتاند و بهطور معناداری تغییر نمیکنند. مشتریها مجبور نیستند ثابتقدم باشند و میتوانند نظرشان را عوض کنند؛ گاهی چون کسی دقیقاً چیزی را ساخته که آنها خواسته بودند. وقتی مشتریها بتوانند بخشی از سیستم را ببینند، لمس کنند و استفاده کنند، ممکن است متوجه شوند راه بهتری برای حل مسئله وجود دارد. بهجای مقاومت در برابر این اثر، تیمها باید آن را بپذیرند و به نفع خودشان از آن استفاده کنند.
-
معماری سیستم را میتوان صرفاً بر اساس مجموعهای از نیازمندیها و بدون هیچ آزمایشی طراحی کرد. تصمیمگیری معماری ناگزیر شامل مجموعهای از بدهبستانهاست که برخی از آنها بدون ساختن و تستکردن کد قابل فهم نیستند؛ معماریکردن صرفاً یک فعالیت ذهنی نیست. در نتیجه، سازمانها بدون آزمایش نمیتوانند معماری مؤثری بسازند.
-
معماری از یک سیستم به سیستم دیگر قابل استفاده مجدد است تا وقتی دامنههایشان مشابه باشد. هر سیستم نرمافزاری متفاوت است، و تا زمانی که QARهای سیستمها حتی کمی با هم فرق داشته باشند، تصمیمها و بدهبستانهای متفاوتی لازم خواهد بود.
گام ۲: پذیرش رویکرد MVP/MVA را ایجاد کنید
نخستین گام در شکستن این باورهای محدودکننده، رسیدن به اجماع است که سیستم در قالب مجموعهای از افزایشها منتشر خواهد شد. جوهره رویکرد Minimum Viable Product (MVP) این است که هر افزایش محصول تلاش میکند حداقل یک نتیجه را برای حداقل یک زیرمجموعه از کاربران سیستم فراهم کند. سازمان موفقیتش را در دستیابی به این نتایج اندازهگیری میکند و از آن بازخورد برای تصمیمگیری درباره اینکه بعداً روی چه چیزی کار کند استفاده میکند.
استفاده از رویکرد MVP/MVA گفتوگوهایی را که تیم توسعه و ذینفعان دارند تغییر میدهد. بهجای تمرکز صرف بر «ارسال چیزی»، همه روی اهداف نتیجهمحور انتشار تمرکز میکنند و اینکه آیا افزایش محصول به آن اهداف رسیده یا نه، و همچنین اینکه آیا آن افزایش میتواند در طول عمر مورد انتظار محصول به ارائه آن نتایج ادامه دهد یا نه.
گام ۳: به تیم کمک کنید یاد بگیرد چگونه یک MVA توسعه دهد
یادگرفتن توسعه معماری بهصورت افزایشی نیازمند تمرین است و هیچ تیمی فوراً در آن استاد نمیشود. بیشتر تیمها تمایل دارند معماری بیشتری از حد لازم بسازند، و بعد متوجه شوند بخشی از کارشان اشتباه بوده یا دستکم ضروری نبوده است. احتمالاً در متعادلکردن بدهبستانها مشکل خواهند داشت. همچنین احتمالاً یاد میگیرند برخی انتخابهایی که کردهاند اشتباه بوده است. اینها خوب است. آنها باید تعادل درست را خودشان پیدا کنند و فقط با انجام چند انتخاب اشتباه و دیدن اثرش میتوانند این را یاد بگیرند.
باید در این دوره با آنها همراه باشید. میتوانید پیشنهاد بدهید، اما حتی پیشنهادها هم ممکن است مسیر یادگیریشان را کوتاهمدار کند. بهترین کاری که میتوانید بکنید این است که کمک کنید بازنگری (retrospect) کنند روی آنچه یاد گرفتهاند و کمک کنید آموختهها را وارد چرخه بعدیشان کنند.
تقریباً همه تیمهایی که با آنها کار کردهایم، دستکم در ابتدای مسیر، با چیزهای مشابهی دستوپنجه نرم میکنند. برای کمک به آنها، تلاش کنید به تیم کمک کنید:
-
آماده انجام بدهبستان باشند. کمک کنید تیم بفهمد طراحی معماریای که همه QARها را کاملاً برآورده کند ناممکن است؛ بیشتر QARها دستکم در ابتدا ناشناختهاند و حتی آنهایی که معلوماند ممکن است اشتباه باشند. توانایی انجام بدهبستانهای سنجیده، مهارت اصلی معماریکردن است.
-
بدهبستانها را شفاف کنند. آنها را مستند کنید و در فضای باز بیاورید تا قابل بحث و مناظره باشند. مهمتر از همه، نتایج واقعی تصمیم را اندازهگیری کنید و بررسی کنید آیا تصمیم به نتیجه موردنظر رسیده یا نه.
-
معماری را اجرایی کنید، نه فقط سند و نمودار. بازبینیها میتوانند برخی خطاها را پیدا کنند، اما هیچ چیز مثل اجرای کد بازخورد را ملموس نمیکند. بیشتر سیستمها پیچیدهاند، یعنی تعامل اجزا، که اغلب توسط تیمهای مختلف یا حتی سازمانهای مختلف ساخته میشوند، قطعی و قابل پیشبینی نیست. چیزهای عجیبی رخ میدهد که «نباید رخ بدهد» اما رخ میدهد. تنها راه اطمینان، ساختن یک محصول اجرایی است که بتوانید بهصورت تجربی ارزیابیاش کنید.
-
قبل از گرفتن بازخورد، بیش از حد معماری نسازند. اگر برای MVA یک شعار باشد، این است: هرگز بازخورد را به تعویق نیندازید. هرگز. در ساختن و ارزیابی کوچکترین افزایش ممکن برای پاسخ به پرسش «آیا تصمیم اخیر ما تصمیم خوبی بود؟» واقعاً ماهر شوید.
گام ۴: حلقههای بازخورد برای بهبود معماری برقرار کنید
دیدن اینکه بازخورد چگونه به تیم کمک میکند MVP را بهتر کند آسان است، اما همان سازوکار میتواند برای تکامل MVA هم استفاده شود؛ هر MVP/MVA فرصتی است برای جمعآوری بازخورد درباره توانایی سیستم در برآوردهکردن QARها. همانطور که هدف MVP این است که تیم از سرمایهگذاری روی قابلیتهایی که ارزشی ندارند پرهیز کند، هدف MVA این است که از سرمایهگذاری بیش از حد روی معماری زمانی که لازم یا مفید نیست جلوگیری کند و بدهبستانها را متعادل نگه دارد.
برخی QARها تا زمانی که تیم سیستم را نسازد و منتشر نکند معلوم نیستند و حتی قابل دانستن هم نیستند؛ تیم نمیتواند پیشبینی کند محصول چقدر محبوب میشود یا برای پاسخ به تقاضای غیرمنتظره با چه چالشهای فنی مواجه خواهد شد. از دید کسبوکار، محصولات بسیار موفق چیز خوبی هستند، اما برای تیم توسعه ریسکزا هستند. بازخورد کمک میکند این ریسک با اطلاعات بهتر مدیریت شود.
گام ۵: تصمیمها را آگاهانه و پیوسته بگیرید
وقتی یک تیم بتواند در چرخههای کوتاه تحویل دهد و بازخورد جمع کند، باید از این توانایی برای تصمیمگیری آگاهانه درباره هر افزایش MVP و MVA استفاده کند:
-
برای MVP، باید فرضیههایی شکل دهد درباره اینکه کدام قابلیتها را ارزشمندتر میداند و باید تصمیم بگیرد چگونه خواهد فهمید آیا این «حدسها» درست بودهاند یا نه.
-
برای MVA، باید تصمیم بگیرد چه چیزی بسازد تا اگر MVP موفق شد، تیم بتواند در طول زمان ارزش را حفظ کند.
این نکته آخر همانجایی است که تصمیمهای سخت میآید. تیم با چند نتیجه محتمل روبهروست:
-
ممکن است MVP آنقدر که تیم امیدوار است ارزشمند نباشد، یا اصلاً ارزشمند نباشد. در این حالت، تیم نمیخواهد کلی قابلیت پشتیبان بسازد که به کار نمیآیند. این میتواند باعث شود تیم صبر کند تا ببیند MVP مفید است یا نه، و بعد معماری پشتیبانش را بسازد. عقبانداختن توسعه MVA نسبت به MVP ممکن است منطقی باشد، مگر اینکه:
-
ممکن است MVP ارزشمند باشد، حتی بهشدت، و باعث شود پذیرش محصول ناگهان اوج بگیرد و سپس سقوط کند چون سیستم برای پشتیبانی از این پذیرش موفق معماری نشده است. اگر MVA سریع قابل انطباق نباشد، ممکن است MVP شکست بخورد.
متعادلکردن این دو گزینه یعنی MVA باید بهاندازه نیازهای فعلی MVP خوب باشد، در حالی که اگر این نیازها تغییر کرد بتواند خیلی سریع تطبیق پیدا کند. یک شیوه نگاه به MVA این است که هر MVA، به یک معنا، یک «اختیار» روی قابلیتهای آینده محصول است.
گفتوگو درباره بدهبستانها و منافع و محدودیتهایشان در واقع جوهره کار معماریای است که تیم انجام میدهد.
گام ۶: به بازخورد سازگار شوید
بازخورد چیزی است که به تیم توسعه کمک میکند معماری محصول را اثبات و بهبود دهد. تیمهایی که صرفاً افزایشهای محصول را تحویل میدهند بدون اینکه اندازهگیری کنند آیا به نتایج مطلوب رسیدهاند یا نه، یک فرصت مهم را از دست میدهند: فهمیدن اینکه آیا واقعاً ارزش تحویل میدهند و اگر از اهدافشان عقب هستند، چگونه بهتر شوند. این برای بخشهای عملکردی محصول یعنی MVP واضح است، اما برای معماری یعنی MVA هم به همان اندازه درست است.
جمعآوری بازخورد یعنی تیم توسعه باید تست بسازد و راههایی پیدا کند تا عملکرد افزایش محصول را نسبت به اهداف معماری اندازهگیری کند. باید برای این کار در برنامهریزی افزایش، زمان بگذارد. این سختتر از چیزی است که به نظر میرسد؛ ذینفعان معمولاً فشار میآورند چیزهای بیشتری به MVP اضافه شود، پس تیم باید مؤثرانه مقاومت کند تا روی MVA سرمایهگذاری کند، از جمله ساختن ابزارها و روشهای اعتبارسنجی تصمیمهای معماری.
از دید معماری، ارزیابی کارایی، مقیاسپذیری، امنیت و قابلیت اطمینان سیستم (و ویژگیهای دیگر) بازخورد ارزشمندی به تیم میدهد تا تصمیم بگیرد بعد چه کند: آیا همان مسیر را ادامه دهد یا مسیر را تغییر دهد؟ بدون داده تجربی، تصمیمها فقط بر اساس نظرها شکل میگیرند. داشتن داده میتواند کمک کند بدهبستانهای مؤثرتری انجام شود.
وقتی تیمهای بیشتری اضافه میکنید، برای موفقیت گستردهتر زیرساخت بسازید
وقتی به خودتان (و شکاکها) ثابت کردید رویکرد MVA برای شما جواب میدهد، میتوانید تعداد تیمهایی را که از این رویکرد استفاده میکنند افزایش دهید. در این مسیر، از آموختههای تیم اول برای کمک به تیمهای جدید استفاده کنید. همچنین تیمها را به هم وصل کنید تا از هم یاد بگیرند. در نهایت، شروع کنید به برخورد سیستماتیک با محدودیتها و موانع سازمانی این رویکرد.
گام ۷: یک جامعه (community) متمرکز بر معماریکردن چابک بسازید
وقتی یک تیم دارید که به روش جدید کار میکند، مدرک دارید که رویکرد جدید جواب میدهد. داشتن این مدرک برای توجیه تغییر گستردهتر مهم است، و تغییر یک تیم بدون تغییر کل سازمان نسبتاً آسان است، چون میشود «قواعد موجود را خم کرد» بدون اینکه مجبور باشید کاملاً جایگزینشان کنید.
هر تیم کموبیش مسیری را که بالا گفتیم طی میکند. اما میانبری برای یادگیری تجربی وجود ندارد؛ همانطور که نمیشود فقط با گوشدادن به حرف یک نفر یاد گرفت نرمافزار بسازید، تیمها هم باید مهارت تصمیمگیری را با تجربه رشد دهند. آنها میتوانند از تیمهای دیگر یاد بگیرند به چه چیزهایی توجه کنند، و اینجاست که یک جامعه مفید میشود. تمرکز این جامعه بین سازمانها متفاوت است، اما اغلب شامل موارد زیر است:
-
اشتراک تجربهها و یادگرفتن از یکدیگر. مهمترین چیز برای اشتراک «پاسخها» نیست، بلکه فرآیند فکریای است که به پاسخها رسید. یادگرفتن اینکه چه پرسشهایی باید پرسید و چه بدهبستانهایی باید سنجید، مهمتر از خود تصمیمهاست. هر تیم باید برای خودش تصمیم بگیرد، اما فهمیدن اینکه دیگران چگونه به مسئله نگاه میکنند اغلب بحثهای جالبی ایجاد میکند.
-
اشتراک مؤلفهها و فریمورکهای مشترک. تیمها نمیتوانند معماری کامل را به اشتراک بگذارند، اما تیمهایی با مسائل مشابه اغلب به مؤلفهها یا بلوکهای سازنده مشابه نیاز دارند. داشتن جایی برای اشتراک و توافق درباره اینکه چه کسی میتواند بهروزرسانی کند و چگونه، به همه کمک میکند.
-
مشارکت در زیرساخت مشترک توسعه و تست. مثل مؤلفهها، تیمهای مختلف نیازهای مشابه (اما نه دقیقاً یکسان) برای ابزارهای ساخت و تست خودکار دارند. برخی سازمانها این را به تیم زیرساخت میسپارند، اما جامعههای تخصصی (communities of practice) هم میتوانند در شناسایی ابزارها و رویکردهای جدید نقش داشته باشند.
-
کمک به رشد یک فرهنگ مهندسی تجربی که یادگیری مبتنی بر تجربه را ارزشمند میداند. حتی وقتی توافقی روی یک راهحل وجود ندارد، دانستن اینکه تیمهای دیگر چه چیزهایی تجربه کردهاند به تیمها کمک میکند گزینهها و بدیلهایشان را بهتر بفهمند.
-
کمک به تیمها برای پذیرش روشهای MVA. فراهمکردن مربی/منتور و آموزش، اگر لازم باشد، به تیمها کمک میکند قابلیتهای MVA خود را رشد دهند.
-
رشد حمایت مدیریت، بهخصوص برای پذیرش شفافیت. بسیاری از مدیرانی که با آنها کار کردهایم میگویند «از غافلگیری خوششان نمیآید». بازخورد گاهی بیرحم است. جامعهها میتوانند راههایی برای اشتراک تجربههای غلبه بر ناراحتی مدیریت در مواجهه با ناشناختهها فراهم کنند.
گام ۸: تیمها را توانمند کنید تا بدهبستانهای خودشان را انجام دهند و پیامدهای بلندمدت را بپذیرند
توانمندسازی تیمها برای تصمیمگیری درباره بدهبستانها بر اساس بازخورد آزمایشهایشان ضروری است، اما میتواند برای وضع موجود تهدیدآمیز باشد. تصور کنید وقتی:
-
یک تیم تصمیم میگیرد از یک فریمورک «استاندارد» داخلی استفاده نکند که یک واحد دیگر تازه با چند میلیون دلار لایسنس کرده، اما آن فریمورک نمیتواند QARهای تیم را برآورده کند.
-
یک تیم تصمیم میگیرد فریمورک امنیتیای که یک تیم محصول دیگر تبلیغش میکند نیازهایش را پوشش نمیدهد.
-
واحد زیرساخت درخواست دسترسی یک تیم به محیط تست مینفریم را تأیید نمیکند، در حالی که تیم احساس میکند برای راستیآزمایی اینکه معماریاش میتواند QARهای مقیاسپذیری و توان عملیاتی را برآورده کند به آن نیاز دارد. واحد زیرساخت میگوید جلسههای بازبینی کافی است و از تیم میخواهد QARها را کامل مستندسازی کند.
میشود ادامه داد، اما مفهوم روشن است. توانمندکردن تیمها گاهی یعنی آنها به نتیجهای متفاوت از «خبرهها» در جای دیگری از سازمان میرسند. این میتواند مشکلساز شود اگر «خبرهها» احساس کنند تخصصشان زیر سؤال رفته، بهجای اینکه بپذیرند تصمیمهایشان در همه موقعیتها جواب نمیدهد. رهبران سازمان باید این را مجاز کنند که تیمهای مختلف به تصمیمهای متفاوت برسند، تا وقتی شواهد و استدلالشان محکم است.
برخی افراد با قدرت (و گاهی با فشار) استدلال میکنند «استانداردها» مهماند و سازمان نمیتواند از تعداد زیادی فناوری متفاوت پشتیبانی کند، و ما تا حدی با این موافقیم. پیامدهای پشتیبانیپذیری بلندمدت تصمیمهای فنی نگرانی اصلی تصمیمهای معماری است، و تیم توسعه باید نشان دهد برآوردهکردن بهتر QARها ارزش بدهبستانِ افزایش پیچیدگیِ پذیرش یک فناوری اضافی را دارد. محدودشدن توسط «استانداردهایی» که تیم دیگری تعیین کرده، به تیمها کمک نمیکند بهتر تصمیم بگیرند؛ فقط گزینههایشان را محدود میکند.
گام ۹: با مواجهه با «فیلهای داخل اتاق» فرهنگ را تکامل دهید
شما با موفقیت هشت گام اول را طی کردید. متأسفانه هنوز باید با بزرگترین مانع روبهرو شوید: تکامل فرهنگ سازمان. در واقع، این «گام» یک گام نیست، بلکه یک فعالیت پسزمینهای است که باید همزمان با همه گامهایی که تا اینجا گفتیم اجرا شود.
فرهنگ سازمان مجموعهای از توافقهای عمدتاً ضمنی درباره این است که «چطور قرار است کارها انجام شوند». فرهنگ، بنا به ماهیتش، مانع تغییر است. فرهنگ وقتی مثبت است که میخواهید اختلالهای کوچک نظم سازمان را به هم نریزند، اما وقتی یک «بهبود» جدید وضع موجود را تهدید میکند، فرهنگ مثل یک سیستم ایمنی عمل میکند و روشهای جدید کار را مثل یک عفونت مهاجم نابود میکند. مشکل تغییر فرهنگ این است که فرهنگ خودبهخود و طبیعی، از طریق همکاری افراد شکل میگیرد و بنابراین تغییر مستقیم و صریح آن تقریباً ناممکن است.
چند «فیل داخل اتاق» وجود دارد که تیمهایی که رویکرد MVA را میپذیرند باید با آنها کنار بیایند تا موفق شوند، و اینها در فرهنگ بیشتر سازمانها جا گرفتهاند:
-
آدمها در برابر تغییر مقاومت میکنند، مخصوصاً اگر تغییر ایده خودشان نباشد. برای بیشتر افراد، تغییر یعنی از دست دادن کنترل و عدم قطعیت؛ از آن خوششان نمیآید. مشارکتدادن آنها در تغییر، اجازهدادن به اینکه تصمیم بگیرند چه چیزی تغییر کند و چه زمانی، میتواند کمک کند راحتتر شوند.
-
«بازی سرزنش» مخرب و ضدبهرهوری است. افراد میترسند اگر تغییر جواب ندهد سرزنش شوند. چون تصمیمهای معماری همیشه نامطمئناند، آنها را بهعنوان آزمایشهایی قاببندی کنید که باید امتحان شوند. اگر نتیجه مورد انتظار را ندادند، سازگار شوید و ادامه دهید. دانستن اینکه چیزی کار نمیکند به همان اندازه دانستن اینکه چیزی کار میکند ارزشمند است.
-
شفافیت میتواند افراد را معذب کند. هیچکس دوست ندارد ایدههایش نقد شود، اما وقتی با ناشناختهها سروکار دارید، همه ایدههایی خواهند داشت که جواب نمیدهند. جداکردن ایدهها از افراد پیشنهاددهنده و نگاهکردن به همه بازخوردها بهعنوان چیز خوب، راهی است برای راحتترکردن افراد با شفافیت.
-
توانمندسازی تیمها پویاییِ جایگاهها را تغییر میدهد. مدیران بالا به پایین که عادت دارند دستور بدهند و وقتی «مسیر درست» دنبال میشود اعتبار بگیرند، با اینکه تیمها خودشان تصمیم بگیرند مشکل دارند. «اگر تصمیم بد بگیرند چی؟ بد به اسم من تمام میشود.» نگاهکردن به تصمیمها بهعنوان آزمایشهایی که باید تست شوند و استفاده از بازخورد مکرر برای بهبود، بخش بزرگی از ریسک تصمیمگیری را کم میکند. همچنین تغییر جهت فرهنگ مدیریتی به سمت رشد تیمها بهجای «قهرمان تصمیمگیرنده بودن» هم کمک میکند.
-
تصورات درباره انطباق مقرراتی باعث میشود افراد فکر کنند نمیتوان سیستم را افزایشی تحویل داد. در برخی صنایع، نهادهای ناظر باید تغییرات محصول را تأیید کنند و ممکن است نخواهند یا نتوانند با افزایشهای کوچک کار کنند. اما همه تغییرات روی بخشهای تحت مقررات اثر نمیگذارند؛ بسیاری فقط روی کاربردپذیری یا تجربه کاربری اثر میگذارند بدون تغییر محصول پایه. شفافبودن درباره اینکه کدام تغییرات نیاز به تأیید ناظر دارند و سپس درگیرکردن زودترِ آنها کمک میکند.
نتیجهگیری
تغییر، طبق تجربه ما، با یک تیم شروع میشود و تیمبهتیم رشد میکند؛ ما هیچوقت ندیدهایم «تحولهای سازمانی بزرگ» به روش دیگری موفق شوند.
هر یک از این تیمها باید روی مسئلهای کار کنند که فقط بهصورت تجربی و از طریق آزمایش قابل حل است؛ اگر مسئله آنقدر خوب فهمیده شده باشد که «بهترینروشها» و راهحلهای کپی-پیست جواب بدهند، تیمها به چابکی/تجربهگرایی نیاز ندارند.
اولین کاری که این تیمها باید انجام دهند یادگرفتن تحویل افزایشی است. این معمولاً نیازمند کمک به ذینفعان است تا بفهمند تحویل افزایشی برای آنها چه معنایی دارد و تیم توسعه چگونه محصول را از طریق مجموعهای از انتشارها تکامل میدهد.
هنگام توسعه و تحویل افزایشی، تیمهای توسعه تمرکز معماری را از اسناد و نمودارها به سمت تصمیمها منتقل میکنند.
وقتی سازمان تجربه و موفقیت بیشتری به دست میآورد، میتوانید رویکرد را به تیمهای بیشتری گسترش دهید. در این مسیر، باید یک جامعه بسازید تا تجربهها و artefactها را به اشتراک بگذارد و به تیمها کمک کند بفهمند چگونه تصمیمها و بدهبستانهای معماری را انجام دهند.
وقتی تصمیمگیری را به تیمها منتقل میکنید، وضع موجود را هم بههم میزنید؛ میزان اختلال را دستکم نگیرید. مسائل سازمانی را بهصورت پیوسته مدیریت کنید و تعارضهایی را که تغییر روابط جایگاهی ایجاد میکند از قبل پیشبینی کنید.
