چارچوب Cynefin

یک چارچوب شناختی (Sensemaking Framework) است که توسط دیو اسنودن (Dave Snowden) و مری بون (Mary Boone) در سال ۲۰۰۷ معرفی شد، ابزاری است برای کمک به رهبران و تصمیم‌گیران تا بتوانند با درک ماهیت موقعیت‌ها، رویکرد و شیوه‌ی واکنش بهتری انتخاب کنند. این چارچوب فقط مختص مدیریت کلان یا تصمیم‌گیری راهبردی نیست؛ می‌توان آن را در حوزه‌های مختلف از جمله توسعه نرم‌افزار نیز به‌خوبی به کار گرفت. ایده‌ی اصلی این است که هنگام تصمیم‌گیری در مورد نحوه‌ی طراحی، پیاده‌سازی، تست، دیباگ یا حتی مدیریت تیم و فرایندهای توسعه، ابتدا تشخیص دهید که با چه نوع مسئله‌ای روبه‌رو هستید و بعد متناسب با همان فضا عمل کنید. این چارچوب پنج حوزه (Domain) اصلی دارد که هر کدام نوع خاصی از پیچیدگی و عدم‌قطعیت را نشان می‌دهند:

۱. حوزه‌ی ساده (Obvious/Simple)

• مشخصه: رابطه‌ی علی و معلولی روشن است و روش‌های راه‌حل از پیش مشخص و اثبات‌شده‌اند.
• رویکرد پیشنهادی: «حس کردن - دسته‌بندی کردن - پاسخ دادن» (Sense – Categorize – Respond)
• مثال کاربردی: فرض کنید شما مسئول موجودی انبار یک سوپرمارکت کوچک هستید. روش‌های استانداردی برای سفارش مجدد کالا وجود دارد (مثلاً وقتی کالایی به زیر یک حد خاص رسید سفارش جدید دهید). مسئله روشن است، راه‌حل‌ها مشخص هستند، و خطای زیادی هم ممکن است رخ ندهد. کافی است دستورالعمل‌های مشخص را دنبال کنید.

چالش بالقوه در این حوزه این است که مدیر یا مسئول ممکن است دچار اعتماد به نفس کاذب شود و شرایط را بیش از حد ساده ببیند. در این صورت، ممکن است زمانی‌که اوضاع پیچیده یا پیچیده‌تر می‌شود، غافلگیر شود.

۲. حوزه‌ی پیچیده (Complicated)

• مشخصه: رابطه‌ی علت و معلولی وجود دارد، اما برای تشخیص و استفاده از راه‌حل باید از کارشناسان و تخصص‌های مختلف کمک گرفت. پاسخ‌های صحیح متنوع هستند، اما می‌توان با تحلیل و دانش تخصصی به جواب رسید.
• رویکرد پیشنهادی: «حس کردن - تحلیل کردن - پاسخ دادن» (Sense – Analyze – Respond)
• مثال کاربردی: فرض کنید می‌خواهید یک کمپین بازاریابی در فضای آنلاین اجرا کنید. شما برای بخش‌های مختلف (سئو، تبلیغات کلیکی، شبکه‌های اجتماعی و ...) احتمالاً از متخصصان کمک می‌گیرید. همه چیز مبهم نیست، اما تحلیل و دانش عمیق در بخش‌های مختلف لازم است تا نتیجه‌ی مطلوب حاصل شود.

مسئله‌ی کلیدی: روش پاسخ در حوزه‌ی پیچیده این است که ابتدا حس کنید و اطلاعات جمع کنید، سپس با تحلیل تخصصی به راهکار دست یابید. مدیران در این حوزه باید به کارشناسان اعتماد کنند.

۳. حوزه‌ی پیچیده (Complex)

• مشخصه: روابط علت و معلولی به‌صورت شفاف قابل شناسایی نیستند و از قبل نمی‌دانید کدام راه‌حل حتماً موفقیت‌آمیز خواهد بود. بهترین رویکرد، آزمایش و تست روش‌های مختلف، مشاهده‌ی نتایج و سپس انطباق با شرایط است.
• رویکرد پیشنهادی: «پروب کردن - حس کردن - پاسخ دادن» (Probe – Sense – Respond)
• مثال کاربردی: شما یک استارتاپ دارید که راه‌حل نوآورانه‌ای ارائه می‌دهد و بازار هدف هم جدید است. دقیقاً نمی‌دانید کدام استراتژی فروش، جذب سرمایه یا توسعه‌ی محصول بهترین نتیجه را خواهد داشت. در این شرایط، ابتدا چند آزمایش کوچک (پایلوت) انجام می‌دهید تا رفتار مشتریان را بسنجید، سپس با مشاهده‌ی نتایج، مسیرتان را اصلاح می‌کنید.
  

نکته‌ی مهم: در حوزه‌ی پیچیده «پروب کردن» (ساختن آزمایش‌های کنترل‌شده) و جمع‌آوری بازخورد، کلید موفقیت است.

۴. حوزه‌ی آشوبناک (Chaotic)

• مشخصه: هیچ رابطه‌ی علی و معلولی مشخص نیست و یا اگر باشد آن‌قدر شرایط بی‌ثبات و بحرانی است که فرصتِ تحلیل دقیق وجود ندارد. اولین کار، ایجاد ثبات اولیه و جلوگیری از گسترش بحران است.
• رویکرد پیشنهادی: «اقدام کردن - حس کردن - پاسخ دادن» (Act – Sense – Respond)
• مثال کاربردی: در دقایق اولیه بعد از یک فاجعه طبیعی، مهم‌ترین کار نجات جان افراد و تأمین نیازهای فوری است. برنامه‌ریزی‌های بلندمدت یا تحلیل‌های پیچیده بعداً انجام می‌شود. اول باید عمل کنید تا بحران را از حادترین حالت بیرون بیاورید.
  

فلسفه‌ی اقدام: «اول عمل کن تا جلوی فاجعه را بگیری، بعد ببین اوضاع چطور است، سپس تصمیم‌های بعدی را بگیر.»

۵. حوزه‌ی نابه‌سامانی (Disorder)

• مشخصه: در این حوزه مشخص نیست که وضعیت ما جزو کدام یک از چهار حوزه‌ی قبلی است. ممکن است بخشی از سیستم ساده باشد، قسمتی پیچیده باشد و بخشی هم کاملاً آشفته باشد. در این حالت بهترین رویکرد، «تقسیم وضعیت به بخش‌های قابل فهم» است تا بتوان آن‌ها را در حوزه‌ی مناسب خود قرار داد.
• مثال کاربردی: گاهی آن‌قدر ابعاد پروژه وسیع است که نمی‌توان به‌سرعت تشخیص داد کدام بخش روتین و ساده است، کدام بخش نیازمند تخصص بیشتر است، کدام بخش پیچیده (Complex) و کدام بخش در آشوب به‌سر می‌برد. در این حالت باید پروژه را خرد کرد و اجزای آن را در حوزه‌های مناسب قرار داد و بر اساس آن‌ها تصمیم‌گیری کرد.

نکات تکمیلی و توصیه‌های عملی

1. جابه‌جایی حوزه‌ها: ممکن است وضعیت از یک حوزه به حوزه‌ی دیگر تغییر کند. برای مثال، اگر بحران مدیریت نشود، حوزه‌ی پیچیده (Complex) می‌تواند به آشوب (Chaotic) تبدیل شود. یا ممکن است بعد از یک دوره‌ی طولانی نوآوری در حوزه‌ی پیچیده، در نهایت به یک دستورالعمل تثبیت‌شده برسیم که آن را به حوزه‌ی ساده منتقل کند.
2. هم‌پوشانی حوزه‌ها: گاهی در یک پروژه‌ی بزرگ، بخش‌هایی از آن ساده و روتین هستند (مثلاً کارهای تکراری اداری)، ولی بخش‌هایی دیگر Complex یا حتی Chaotic هستند (مثلاً درگیرشدن با یک بحران تأمین کالا). مدیران باید بخش‌ها را تفکیک کنند و برای هر بخش روش تصمیم‌گیری مناسبی اتخاذ کنند.
3. اهمیت فرهنگ سازمانی: در حوزه‌ی پیچیده، نیاز به فرهنگ «یادگیری مداوم» و «آزمایش سریع و ارزان» (Fail Fast) پررنگ است. سازمان‌هایی که اشتباه را تاب نمی‌آورند، در این حوزه مشکل خواهند داشت، زیرا از ترس شکست دست به هیچ آزمایشی نمی‌زنند.
4. آگاه‌بودن از تعصب‌ها (Biases): انسان تمایل دارد مسائل را ساده ببیند یا گاهی هم بدون دلیل آن را پیچیده‌تر کند. آگاهی از سوگیری‌های شناختی (مثلاً توهم دانایی، ترس از ناشناخته‌ها و ...) می‌تواند کمک کند تا واقع‌بینانه‌تر قضاوت کنیم.

به‌عنوان یک رهبر فنی (Technical Lead) در تیم نرم‌افزاری، این چارچوب می‌تواند در تصمیم‌گیری‌ها، مدیریت تسک‌ها، رهبری تیم و حتی در تعیین استراتژی توسعه بسیار راهگشا باشد. در ادامه چند پیشنهاد و راهکار عملی ارائه می‌شود که نشان می‌دهد چگونه می‌توانید از این چارچوب در نقش رهبری فنی استفاده کنید:

۱. پایش مداوم و شناسایی نوع مسئله

بهترین کاربرد ساینِفین این است که قبل از هر تصمیم یا اقدام، به‌صورت آگاهانه از خودتان بپرسید:

• آیا مسئله/تسک، ساده و دارای بهترین‌روش اثبات‌شده (Best Practice) است؟
• آیا نیاز داریم با متخصصان مشورت کنیم و داده‌ها را عمیق تحلیل کنیم (پیچیده/Complicated)؟
• آیا نمی‌توان از قبل پاسخ را پیش‌بینی کرد و باید آزمایش و تکرار (Complex) انجام دهیم؟
• آیا شرایط بحرانی یا فوریتی است و باید بلافاصله عمل کنیم (Chaotic)؟

به این ترتیب، شما به‌صورت سیستماتیک یاد می‌گیرید برای هر تسک و چالشی روش متناسبی به کار بگیرید، به‌جای اینکه یک الگوی ثابت برای همه‌ی مسائل تجویز کنید.

۲. مدیریت و اولویت‌بندی تسک‌ها بر اساس حوزه

در نقش رهبر فنی معمولاً به شما رجوع می‌کنند که کدام تسک فوری است، کدام تسک پیچیده است و به تحلیل نیاز دارد، و کدام تسک را می‌توان با یک دستورالعمل ساده انجام داد. با بهره‌گیری از ساینِفین می‌توانید:

• تسک‌های ساده (Obvious) یا روتین را به نیروهای کم‌تجربه یا تازه‌وارد بسپارید تا به‌سرعت کار را یاد بگیرند. این تسک‌ها نباید وقت نیروهای ارشد را زیاد بگیرد.
• تسک‌های پیچیده (Complicated) را شناسایی کنید و برایشان زمان تحلیل و بررسی کارشناسی کافی بگذارید. اگر لازم است، متخصصان خارجی یا ابزارهای پیشرفته را وارد کنید.
• تسک‌های با عدم قطعیت بالا (Complex) را با رویکرد «Proof of Concept» یا «MVP» جلو ببرید. از اسپرینت‌های کوتاه و بازخورد مداوم استفاده کنید تا ریسک را کنترل کنید.
• تسک‌های بحرانی (Chaotic) را فوری در اولویت اول قرار دهید. برنامه‌ها را متوقف کنید و ابتدا بحران را مهار کنید؛ مثلاً باگ تولیدی(Production) یا حمله امنیتی.

این کار باعث می‌شود منابع (زمان، نیرو، هزینه) را دقیق‌تر تقسیم کنید و تیم‌تان را کاراتر جلو ببرید.

۳. انتخاب روش توسعه و متدولوژی مناسب

ساینِفین به شما کمک می‌کند تشخیص دهید چه رویکردی در توسعه باید به کار گرفته شود:

• در مسائل ساده: استفاده از مستندات آماده، چک‌لیست‌ها و Best Practiceهای رایج. مثلاً وقتی می‌خواهید یک API ساده با یک الگوی شناخته‌شده درست کنید.
• در مسائل پیچیده (Complicated): معمولاً مهندسی پیش از اجرا (Upfront Engineering)، بررسی چندین سناریو و تهیه مستندات طراحی (Design Documents) مفید است.
• در مسائل پیچیده (Complex): توسعه‌ی چابک (Agile)، اسپرینت‌های کوتاه، ساخت پروتوتایپ و گرفتن بازخورد.
• در حوزه‌ی آشوبناک (Chaotic): فرایند رسمی را کنار بگذارید و سریع اقدام اضطراری کنید (Hotfix، Rollback و ...).

به‌عنوان رهبر فنی، می‌توانید برای هر بخش یا فاز پروژه، متدولوژی منطبق با حوزه‌ی مربوطه را پیشنهاد کنید و از یک روش واحد برای همه‌ی قسمت‌ها استفاده نکنید.

۴. آموزش و توانمندسازی تیم

بسیاری از مشکلات در توسعه نرم‌افزار زمانی ایجاد می‌شوند که اعضای تیم نمی‌دانند باید از چه رویکرد یا ابزاری استفاده کنند. شما می‌توانید:

1. تیم‌تان را با چارچوب ساینِفین آشنا کنید: در جلسات داخلی، با مثال‌های واقعی از پروژه‌ی خودتان، توضیح دهید که کدام تسک‌ها را می‌توان در حوزه‌ی ساده در نظر گرفت و کدام در حوزه‌ی پیچیده.
2. برای هر حوزه دستورالعمل کلی داشته باشید: مثلاً یک راهنمای مختصر بنویسید که اگر تسک ساده است، راهنمایی اصلی چیست (چک‌لیست‌ها؟ مستندات خاص؟). اگر پیچیده/Complicated است، بهتر است سراغ چه ابزارها یا افراد متخصصی برویم و چه مدت زمان برای تحلیل لازم داریم.
3. چشم‌انداز مشترک بسازید: وقتی همه‌ی اعضا یک زبان مشترک برای توصیف پیچیدگی یا بحران داشته باشند، سریع‌تر و شفاف‌تر می‌توانند در مورد راه‌حل توافق کنند.

۵. مدیریت تغییر و نوآوری

اغلب رهبران فنی وظیفه دارند تیم را به سمت فناوری‌های جدید، ابزارهای به‌روز یا معماری‌های مدرن سوق دهند. اما میزان ریسک و عدم قطعیتی که هر تکنولوژی جدید به همراه دارد، در ساینِفین می‌تواند به شما نشان دهد در کدام حوزه قرار می‌گیرید:

• اگر فناوری یا ابزار جدید، تا حد زیادی تست‌شده و سندیت دارد (مثلاً استفاده از یک کتابخانه‌ی محبوب در جامعه‌ی متن‌باز)، این موضوع می‌تواند نزدیک به حوزه‌ی پیچیده (Complicated) باشد و با بررسی کارشناسی سراغش بروید.
• اگر هنوز ناشناخته است و مطمئن نیستید چه نتایجی خواهد داشت (مثلاً ابزارهای بسیار نوپا، یا ترکیب معماری‌های عجیب‌وغریب)، به حوزه‌ی پیچیده (Complex) نزدیک است و باید با رویکرد آزمایشی (Proof of Concept) عمل کنید.

با این شیوه، می‌توانید از پریدن ناگهانی کل تیم به سمت فناوری‌های ناشناخته جلوگیری کرده و ابتدا با چند آزمایش و پروتوتایپ جلو بروید.

۶. رسیدگی به بحران‌ها (Incident Management)

یکی از وظایف مهم رهبر فنی، مدیریت بحران‌های فنی است. ساینِفین می‌گوید در حوزه‌ی آشوبناک (Chaotic):

• اولویت اول: اقدام فوری برای جلوگیری از گسترش بحران (مثلاً از دسترس خارج‌کردن سرویس، ری‌بوت سرور، Rollback انتشار جدید و ...).
• سپس حس کردن (Sense) و تشخیص ابعاد مسئله
• در نهایت پاسخ دادن (Respond) به شکل ساختارمند (مثلاً پس از بازگرداندن شرایط عادی، وارد دلایل ریشه‌ای (Root Cause Analysis) شوید).

این رویکرد باعث می‌شود هم سرعت عمل داشته باشید و هم پس از آرامش اولیه، با تحلیل درست، از بروز مجدد مشکل جلوگیری کنید.

۷. جلوگیری از سردرگمی (حوزه‌ی Disorder) در تیم

حوزه‌ی «نابه‌سامانی (Disorder)» زمانی اتفاق می‌افتد که تیم شما نمی‌داند نوع چالش چیست یا حتی تعریف درستی از مسئله ندارد. به‌عنوان رهبر فنی می‌توانید:

1. تفکیک مسئله به بخش‌های کوچکتر: اگر یک مشکل یا پروژه خیلی مبهم است، سعی کنید اجزایش را جدا کنید و برای هر بخش، یک دامنه یا حوزه‌ (Domain) را تشخیص دهید.
2. شفاف‌سازی نیازمندی‌ها: با ذی‌نفعان (مدیر محصول، کاربران، مشتریان) جلساتی بگذارید تا نیازمندی‌ها را واضح‌تر کنید.
3. همکاری با اسکرام مستر یا مدیر پروژه: اگر در تیم‌تان شخصی برای مدیریت فرایند وجود دارد، با او هماهنگ شوید که در جلسه‌های Grooming یا Planning به تیم کمک کند تا کارها را خوب دسته‌بندی کنند.

۸. نظارت و بازنگری مداوم

ساینِفین یک چارچوب پویا است؛ ممکن است مسئله‌ای که ابتدا ساده به‌نظر می‌رسد، ناگهان پیچیده یا حتی آشوبناک شود (یا برعکس). بنابراین، به‌صورت دوره‌ای (مثلاً در جلسات اسپرینت ریویو یا جلسات هفتگی) این سوال‌ها را مطرح کنید:

• آیا تغییری در وضعیت پروژه یا تیم ایجاد شده که نوع تسک/مسئله را عوض کند؟
• آیا حوزه‌ی تسک‌ها از Complex به Complicated منتقل شده و حالا دستورالعمل بهتری برایش داریم؟
• آیا تسک یا مشکل خاصی پیش آمده که باید فوری وارد عمل شویم (Chaotic)؟

این بازنگری‌ها به شما امکان می‌دهد رویکرد و منابع‌تان را به‌روز کرده و از غافل‌گیری جلوگیری کنید.

جمع‌بندی

استفاده از این چارچوب باعث می‌شود که رهبران و مدیران، به جای تلاش برای تحمیل یک روش ثابت به همه موقعیت‌ها، ابتدا نوع موقعیت را بشناسند و سپس متناسب با آن بهترین سبک رهبری و تصمیم‌گیری را انتخاب کنند.