مراحل پنج‌گانه تاکرمن: چرا تیم شما در مرحله طوفان متلاشی می‌شود؟
تیم‌ها یکشبه ساخته نمی‌شوند.از طوفان عبور کن تا به هنجار و عملکرد برسی.این مقاله نقشه راه تحول تیم را نشان می‌دهد.
مراحل پنج‌گانه تاکرمن (Tuckman Stages) مدلی است که نشان می‌دهد هر تیم از لحظه‌ی شکل‌گیری تا رسیدن به عملکرد پایدار، پنج مرحله‌ی مشخص را طی می‌کند: تشکیل (Forming)، طوفان (Storming)، هنجارسازی (Norming)، اجرا (Performing) و انحلال (Adjourning). شناخت این مراحل به شما کمک می‌کند بدانید چرا یک تیم در هفته‌ی سوم به نظر متلاشی می‌آید و چرا بعضی تیم‌ها هرگز از مرحله‌ی طوفان عبور نمی‌کنند. بسیاری از مدیران فنی، فروپاشی موقت تیم را نشانه‌ی شکست می‌دانند، در حالی که این فروپاشی بخشی طبیعی از رشد است. این نوشته نشان می‌دهد در هر مرحله چه اتفاقی می‌افتد، چه نشانه‌هایی دارد و مدیر یا رهبر فنی چه اقداماتی باید انجام دهد.
هر تیمی که در آن نقش داشته‌ام، دیر یا زود یک نقطه‌ی سقوط داشته است. لحظه‌ای که به نظر می‌رسد همه‌چیز از هم می‌پاشد، ارتباطات قطع می‌شود و هر کس در گوشه‌ای مشغول دفاع از موضع خودش است. مدتی طول کشید تا بفهمم این نقطه‌ی سقوط، بخشی از یک الگوی شناخته‌شده است و نه نشانه‌ی شکست. این الگو همان چیزی است که بروس تاکرمن در سال ۱۹۶۵ توصیف کرد و بعدها با اضافه شدن مرحله‌ی پنجم، به یکی از پرکاربردترین مدل‌ها در روان‌شناسی سازمانی تبدیل شد.
مدل تاکرمن چیست و چرا هنوز معتبر است
بروس تاکرمن (Bruce Tuckman) در مقاله‌ای با عنوان «Developmental Sequence in Small Groups» مدلی را معرفی کرد که مسیر رشد یک تیم کوچک را در چهار مرحله توصیف می‌کرد. او بعدها با همکاری مری آن جنسن، مرحله‌ی پنجم را به مدل اضافه کرد. جذابیت این مدل در سادگی آن نیست، بلکه در توانایی‌اش برای پیش‌بینی الگوهایی است که در هر تیم تکرار می‌شوند.
نکته‌ی مهم این است که این مراحل خطی نیستند. تیم می‌تواند به مرحله‌ی قبلی برگردد. اضافه شدن یک عضو جدید، تغییر اهداف پروژه یا فشار زمانی می‌تواند تیم را از مرحله‌ی اجرا به مرحله‌ی طوفان برگرداند. در پروژه‌های نرم‌افزاری که تیم‌ها مرتب دستخوش تغییر می‌شوند، این بازگشت قاعده است، نه استثنا.
در سال‌های اخیر، پژوهش‌های مختلف در حوزه‌ی رفتار سازمانی این مدل را بازبینی کرده‌اند. بعضی مطالعات نشان داده‌اند که مرز میان مراحل در تیم‌های واقعی محوتر از آن چیزی است که مدل اولیه ترسیم می‌کرد. اما این بازبینی‌ها، اعتبار مدل را زیر سؤال نبرده‌اند؛ فقط آن را واقع‌بینانه‌تر کرده‌اند. اگر می‌خواهید درک عمیق‌تری از رفتار تیمی داشته باشید، پیشنهاد می‌کنم ابتدا مدیریت دانش تیمی و جلوگیری از فراموشی را مطالعه کنید؛ چون بخش زیادی از پویایی تیم به شیوه‌ی حفظ و انتقال دانش گره خورده است.
مراحل تاکرمن یک نقشه‌ی راه نیست؛ یک الگوی تشخیصی است که به شما می‌گوید کجای مسیر ایستاده‌اید.
مرحله‌ی تشکیل؛ آشنایی محتاطانه
در مرحله‌ی تشکیل (Forming)، اعضای تیم به‌تازگی گرد هم آمده‌اند. همه مودب هستند، کسی نمی‌خواهد موضع بگیرد و انتظارات هنوز مبهم است. جلسات با سکوت‌های طولانی همراه است و افراد منتظر می‌مانند تا ببینند چه کسی پیشقدم می‌شود. در ظاهر همه‌چیز آرام است، اما این آرامش از سر راحتی نیست؛ از سر احتیاط است.
در پروژه‌های نرم‌افزاری، این مرحله معمولاً با تعریف نقش‌ها همراه است. چه کسی معماری را طراحی می‌کند؟ چه کسی تست می‌نویسد؟ چه کسی با مشتری صحبت می‌کند؟ در بسیاری از تیم‌ها، این نقش‌ها به‌طور رسمی تعریف نمی‌شوند و به‌صورت ضمنی شکل می‌گیرند. همین ابهام، در مرحله‌ی بعد به تعارض منجر می‌شود.
اقدامات مؤثر در این مرحله ساده و مشخص هستند:
- تعریف روشن اهداف و معیارهای موفقیت
- شفاف‌سازی نقش‌ها و مسئولیت‌ها
- تعیین قواعد پایه برای ارتباطات و تصمیم‌گیری
- ساخت فرصت‌هایی برای شناخت غیررسمی اعضا
- اجتناب از بار سنگین فنی در هفته‌های اول
اشتباه رایج در این مرحله، پرتاب تیم به یک deadline سخت بدون فرصت برای شکل‌گیری روابط است. این کار باعث می‌شود مرحله‌ی تشکیل فشرده شود و تعارضات بعدی شدیدتر ظاهر شوند. تجربه‌ی کاری نشان داده تیم‌هایی که در دو تا سه هفته‌ی اول فرصت کافی برای تثبیت داشتند، در ادامه کارآمدتر عمل کردند.
مرحله‌ی طوفان؛ جایی که بیشتر تیم‌ها می‌شکنند
مرحله‌ی طوفان (Storming) سخت‌ترین بخش مسیر است. در این مرحله، انتظارات پنهان سر باز می‌کنند، دیدگاه‌ها برخورد می‌کنند و اولین تعارض‌های جدی رخ می‌دهد. هر کس می‌خواهد ثابت کند دیدگاهش درست است و در این میان، اعتماد میان اعضا کاهش می‌یابد. جلسات طولانی‌تر می‌شوند، اما به نتیجه نمی‌رسند.
در تیم‌های فنی، طوفان معمولاً حول چند محور مشخص رخ می‌دهد: انتخاب معماری، سبک کدنویسی، ابزارهای مشترک، فرآیند بازبینی کد و نحوه‌ی تعامل با ذی‌نفعان. اختلاف بر سر این موضوعات طبیعی است، چون هرکدام به پیشینه و تجربه‌ی متفاوت اعضا گره خورده است. کسی که چند سال با یک معماری خاص کار کرده، به‌سختی می‌پذیرد که رویکرد دیگری بهتر است.
در این مرحله، مدیر یا رهبر فنی نقشی کلیدی دارد. چند اقدام مؤثر:
- پذیرفتن تعارض به‌عنوان بخشی از رشد، نه نشانه‌ی شکست
- گوش دادن فعال به همه‌ی دیدگاه‌ها بدون قضاوت سریع
- تفکیک تعارض‌های مرتبط با کار از تعارض‌های شخصی
- تعیین معیارهای عینی برای تصمیم‌گیری، نه اعمال قدرت
- مستندسازی تصمیم‌ها و دلایلشان
اشتباه رایجی که بارها دیده‌ام، سرکوب تعارض با اقتدار است. مدیر تیم را مجبور می‌کند به یک تصمیم تن بدهد بدون آنکه اعضا فرصت گفت‌وگو داشته باشند. در ظاهر مشکل حل می‌شود، اما تعارض به زیر سطح می‌رود و در مرحله‌ی بعد به شکل بی‌انگیزگی یا ترک پروژه ظاهر می‌شود. تیم‌هایی که تعارض را با گفت‌وگوی صادقانه مدیریت می‌کنند، در مرحله‌ی هنجارسازی سریع‌تر و محکم‌تر پیش می‌روند.
برای درک بهتر اینکه چگونه تصمیم‌های تیمی روی کار فنی اثر می‌گذارند، نوشته‌ی KPI مناسب برای تیم توسعه چطور انتخاب کنیم؟ دید مفیدی می‌دهد. انتخاب KPI اشتباه می‌تواند تعارض مرحله‌ی طوفان را به یک بحران طولانی تبدیل کند.
تعارضی که سرکوب شود، ناپدید نمی‌شود؛ فقط به لایه‌ای می‌رود که تشخیصش سخت‌تر است.
مرحله‌ی هنجارسازی؛ شکل‌گیری قواعد نانوشته
وقتی تیم از طوفان عبور می‌کند، وارد مرحله‌ی هنجارسازی (Norming) می‌شود. در این مرحله، اعتماد بازمی‌گردد، قواعد نانوشته شکل می‌گیرد و اعضا یاد می‌گیرند چطور با تفاوت‌ها کنار بیایند. جلسات کوتاه‌تر می‌شوند، اما نتیجه‌ی بهتری می‌دهند. کد بازبینی می‌شود بدون آنکه به جدال شخصی تبدیل شود.
قواعد این مرحله معمولاً مکتوب نیستند، اما به‌شدت اثرگذارند. چه کسی در جلسه اول صحبت می‌کند؟ چه کسی در تعارض‌ها نقش میانجی می‌گیرد؟ چطور تصمیم‌های فنی گرفته می‌شود؟ این قواعد نامرئی، ساختار واقعی کار تیمی را می‌سازند.
خطر اصلی این مرحله، انجماد هنجارهاست. تیمی که قواعد خود را تغییرناپذیر می‌بیند، در مواجهه با تغییرات پروژه سریع واکنش نشان نمی‌دهد. قواعد باید زنده باشند و با شرایط جدید بازنگری شوند. اگر پروژه از یک محصول کوچک به یک پلتفرم بزرگ تبدیل می‌شود، هنجارهای مرحله‌ی قبل دیگر پاسخگو نیستند.
در این مرحله، مستندسازی هنجارها مفید است. نوشتن تصمیم‌ها و دلایلشان در یک مخزن مشترک یا پایگاه دانش، از فراموشی سازمانی جلوگیری می‌کند. همان‌طور که در مدیریت پروژه با GitHub Projects توضیح داده شده، ساختار رسمی می‌تواند به تثبیت هنجارهای غیررسمی کمک کند.
مرحله‌ی اجرا؛ عملکرد پایدار و خودگردان
در مرحله‌ی اجرا (Performing)، تیم به یک ماشین منظم تبدیل می‌شود. اعضا می‌دانند چه انتظاری از یکدیگر دارند، تعارض‌ها را سریع حل می‌کنند و تصمیم‌گیری سریع و دقیق است. مدیر در این مرحله بیشتر نقش تسهیل‌گر دارد و به‌ندرت نیاز است در کار روزمره دخالت کند.
نکته‌ی مهم این است که مرحله‌ی اجرا پایدار نیست. اضافه شدن یک عضو جدید، تغییر اولویت‌های کسب‌وکار یا حتی یک بحران خارجی می‌تواند تیم را به مرحله‌ی طوفان برگرداند. تیم‌های بالغ این بازگشت را می‌پذیرند و با آن کنار می‌آیند. تیم‌هایی که تصور می‌کنند مرحله‌ی اجرا یک وضعیت دائمی است، در مواجهه با اولین بحران واقعی از هم می‌پاشند.
در پروژه‌های نرم‌افزاری بلندمدت، حفظ مرحله‌ی اجرا نیازمند توجه مستمر است. آیین‌های تیمی مثل جلسات هفتگی، بازبینی‌های دوره‌ای و بازخورد ساخت‌یافته به حفظ انسجام کمک می‌کنند. اما آیین‌هایی که به عادت تبدیل می‌شوند و کارکرد خود را از دست می‌دهند، می‌توانند بیشتر ضرر بزنند تا نفع. بازنگری دوره‌ای این آیین‌ها بخشی از کار رهبری فنی است.
در تیم‌های دورکار، حفظ مرحله‌ی اجرا چالش بیشتری دارد. بدون تعامل رو در رو، نشانه‌های اولیه‌ی افت عملکرد دیرتر دیده می‌شوند. ابزارهایی که برای مدیریت پروژه استفاده می‌کنید، باید نشانگرهای زودهنگام را در دسترس قرار دهند. موضوعی که در مقایسه Notion و Trello برای مدیریت پروژه به آن پرداخته شده است.
مرحله‌ی انحلال؛ پایان یک چرخه
مرحله‌ی انحلال (Adjourning) در مدل اولیه‌ی تاکرمن وجود نداشت و بعدها اضافه شد. در این مرحله، پروژه به پایان می‌رسد یا تیم منحل می‌شود. احساسات این مرحله می‌تواند متفاوت باشد: از رضایت و افتخار تا ابهام و اضطراب.
در پروژه‌های نرم‌افزاری، انحلال معمولاً ناگهانی و بی‌برنامه است. تیم با موفقیت پروژه را تحویل می‌دهد و بلافاصله به پروژه‌ی بعدی منتقل می‌شود. اما این انتقال بی‌برنامه، فرصت مهمی را از دست می‌دهد: بازبینی آموخته‌ها. اگر تجربه‌های این تیم مستند نشود، همان اشتباهات در پروژه‌ی بعدی تکرار می‌شوند.
یک آیین مؤثر در این مرحله، جلسه‌ی بازبینی (Retrospective) جامع است. در این جلسه، اعضا به پرسش‌هایی مثل این پاسخ می‌دهند:
- چه چیزی خوب کار کرد و باید تکرار شود؟
- چه چیزی کار نکرد و باید تغییر کند؟
- کدام تصمیم‌های فنی درست بودند و کدام نبودند؟
- چه مهارت‌هایی در تیم رشد کرد؟
- اگر این پروژه را از نو شروع می‌کردیم، چه چیزی متفاوت انجام می‌دادیم؟
مستندسازی این بازبینی، سرمایه‌ی تیم‌های بعدی می‌شود. بدون آن، هر تیم جدید از صفر شروع می‌کند. اصول این نوع مستندسازی همان چیزی است که در مدیریت دانش تیمی و جلوگیری از فراموشی به آن پرداخته‌ام.
مراحل تاکرمن در تیم‌های دورکار
تیم‌های دورکار مسیر مشابهی را طی می‌کنند، اما زمان‌بندی و شدت مراحل متفاوت است. مرحله‌ی تشکیل در تیم‌های دورکار طولانی‌تر است، چون فرصت‌های غیررسمی برای آشنایی کمتر است. مرحله‌ی طوفان می‌تواند خفیف‌تر باشد، چون تعارض‌ها کمتر ابراز می‌شوند — اما همین خفیف بودن، خطرناک است؛ چون تعارض پنهان در ادامه به شکل انفعال یا خروج از تیم ظاهر می‌شود.
مرحله‌ی هنجارسازی در تیم‌های دورکار نیازمند کوشش آگاهانه است. بدون حضور فیزیکی، هنجارها به‌طور طبیعی شکل نمی‌گیرند؛ باید طراحی شوند. جلسات منظم، آیین‌های مشترک، کانال‌های ارتباطی مشخص و اسناد مشترک بخشی از این طراحی هستند.
مرحله‌ی اجرا در تیم‌های دورکار به بلوغ ابزارها وابسته است. اگر ابزارها خوب کار نکنند، نشانه‌های اولیه‌ی مشکل دیده نمی‌شوند و تیم از مرحله‌ی اجرا به عقب برمی‌گردد بدون آنکه کسی متوجه شود. در این بستر، بهترین شیوه‌های HRM برای تیم‌های دورکار راهنمای عملی خوبی برای پیشگیری است.
در تیم دورکار، سکوت نشانه‌ی رضایت نیست؛ معمولاً نشانه‌ی فاصله است.
نقش مدیر در هر مرحله چه تغییری می‌کند
| مرحله | نقش مدیر | اقدام کلیدی |
|---|---|---|
| تشکیل | راهنما و تعیین‌کننده | شفاف‌سازی اهداف و نقش‌ها |
| طوفان | میانجی و تسهیل‌گر | مدیریت تعارض و تصمیم‌گیری |
| هنجارسازی | ناظر و راهبر | تثبیت هنجارها و انعطاف‌پذیری |
| اجرا | تسهیل‌گر و حامی | کمترین دخالت، بیشترین پشتیبانی |
| انحلال | راهبر بازبینی | مستندسازی آموخته‌ها |
بسیاری از مدیران در مرحله‌ی اجرا همچنان با سبک مرحله‌ی تشکیل عمل می‌کنند. نتیجه، دخالت بی‌مورد و کاهش انگیزه در تیم است. تشخیص این خطا، نشانه‌ی بلوغ مدیریتی است.
در تیم‌های فنی، انتخاب سبک مدیریت به سطح بلوغ تیم بستگی دارد. تیمی که در مرحله‌ی اجراست، به فضای بیشتری برای خودگردانی نیاز دارد. تیمی که در مرحله‌ی طوفان است، به ساختار بیشتری نیاز دارد. انتخاب نادرست سبک مدیریت، می‌تواند یک تیم موفق را به مرحله‌ی قبل برگرداند. این موضوع در OKR در مقابل KPI: کدام برای تیم شما مناسب است؟ هم با رویکرد متفاوتی بررسی شده است.
چگونه بفهمیم تیم در کدام مرحله است
تشخیص مرحله‌ی تیم نیازمند مشاهده‌ی دقیق نشانه‌ها است. چند پرسش تشخیصی می‌تواند کمک کند:
- آیا اعضا در جلسات نظر می‌دهند یا فقط گوش می‌دهند؟
- وقتی اختلافی پیش می‌آید، چگونه حل می‌شود؟
- آیا اعضا به یکدیگر در کار کمک می‌کنند بدون آنکه درخواست شود؟
- آیا تصمیم‌ها سریع گرفته می‌شوند یا در جلسات طولانی گیر می‌کنند؟
- آیا اعضای تیم درباره‌ی مشکلات بیرون از کار صحبت می‌کنند؟
- آیا بازخورد انتقادی پذیرفته می‌شود یا منجر به دفاع می‌شود؟
پاسخ به این پرسش‌ها تصویر تقریبی از مرحله‌ی تیم می‌دهد. اما توجه داشته باشید که یک تیم می‌تواند در زیرگروه‌های مختلف، در مراحل متفاوتی باشد. تیم مهندسی ممکن است در مرحله‌ی اجرا باشد، در حالی که همکاری با تیم محصول در مرحله‌ی طوفان باشد.
اشتباهات رایج در عبور از مراحل
- انتظار اجرای سریع از تیم تازه: فشار برای نتیجه فوری در مرحله‌ی تشکیل، رشد تیم را متوقف می‌کند.
- سرکوب تعارض در مرحله‌ی طوفان: تعارض سرکوب‌شده در مرحله‌ی بعد به بحران تبدیل می‌شود.
- انجماد هنجارها در مرحله‌ی هنجارسازی: قواعدی که بازنگری نمی‌شوند، مانع رشد می‌شوند.
- دخالت زیاد در مرحله‌ی اجرا: مدیری که همچنان همه‌ی تصمیم‌ها را می‌گیرد، تیم را از رشد بازمی‌دارد.
- انحلال بدون بازبینی: پروژه‌ای که بدون مستندسازی به پایان می‌رسد، درس‌هایش را از دست می‌دهد.
- نادیده گرفتن بازگشت به مرحله‌ی قبل: تغییر ترکیب تیم همیشه به مرحله‌ی طوفان منجر می‌شود؛ این واقعیت را بپذیرید.
- اعمال سبک مدیریت یکسان در همه‌ی مراحل: سبکی که در مرحله‌ی تشکیل مؤثر است، در مرحله‌ی اجرا آسیب می‌زند.
بخش مهمی از این اشتباهات با آموزش و بازبینی دوره‌ای قابل پیشگیری است. در تیم‌های فنی که اعضا با مفاهیم مدیریتی آشنایی محدودی دارند، سرمایه‌گذاری روی این آموزش‌ها بازده بالایی دارد.
پرسش‌های پرتکرار درباره مراحل تاکرمن
آیا هر تیم الزاماً از همه‌ی مراحل عبور می‌کند؟ نه الزاماً. بعضی تیم‌ها بدون مواجهه‌ی جدی با تعارض، از تشکیل به هنجارسازی می‌روند. این وضعیت همیشه مطلوب نیست؛ چون تعارض حل‌نشده در مرحله‌ی طوفان، بعداً ظاهر می‌شود.
چقدر طول می‌کشد تا یک تیم به مرحله‌ی اجرا برسد؟ بسته به اندازه‌ی تیم، پیچیدگی پروژه و تجربه‌ی اعضا متفاوت است. تیم‌های کوچک با تجربه‌ی قبلی همکاری، ممکن است در چند هفته به مرحله‌ی اجرا برسند. تیم‌های بزرگ‌تر و تیم‌هایی که اعضای جدید جذب می‌کنند، ماه‌ها زمان نیاز دارند.
اگر عضو جدید به تیم اضافه شود چه اتفاقی می‌افتد؟ تیم معمولاً به مرحله‌ی طوفان برمی‌گردد، اما بازگشت کوتاه‌تر از بار اول است. اگر عضو جدید به‌خوبی پذیرفته شود، تیم سریع‌تر از قبل به مرحله‌ی اجرا برمی‌گردد.
آیا مرحله‌ی طوفان همیشه منفی است؟ نه. مرحله‌ی طوفان جایی است که دیدگاه‌های پنهان آشکار می‌شوند و تصمیم‌های واقعی گرفته می‌شود. تیمی که هرگز طوفان را تجربه نکند، ممکن است در سطحی از ادب باقی بماند که مانع رشد است.
چطور تیم را از مرحله‌ی طوفان عبور دهیم؟ با پذیرش تعارض، گوش دادن فعال، تفکیک تعارض کار از تعارض شخصی و تصمیم‌گیری بر پایه‌ی معیارهای عینی. سرکوب یا نادیده گرفتن تعارض، مسیر را طولانی‌تر می‌کند.
آیا مدل تاکرمن برای تیم‌های بزرگ هم کاربرد دارد؟ مدل اولیه برای گروه‌های کوچک طراحی شده بود. در تیم‌های بزرگ، هر زیرگروه مسیر خودش را طی می‌کند و مدیر باید هم‌زمان چند مرحله را مدیریت کند. مفاهیم کلی مدل همچنان معتبر هستند.
آیا تیم‌های دورکار مراحل متفاوتی دارند؟ مراحل مشابه‌اند، اما زمان‌بندی و شدت آن‌ها متفاوت است. در تیم دورکار، مرحله‌ی تشکیل طولانی‌تر و مرحله‌ی طوفان پنهان‌تر است.
آیا می‌توان مرحله‌ی طوفان را نادیده گرفت؟ خیر. اگر تیم در مرحله‌ی طوفان با تعارض مواجه نشود، تعارض در مرحله‌ی بعد به شکل دیگری ظاهر می‌شود: کاهش انگیزه، خروج از تیم یا کاهش کیفیت کار.
نگاه مهندسی سطح بالا به پویایی تیم
از منظر نظریه‌ی سیستم‌های پیچیده، تیم یک سیستم تطبیقی است که در پاسخ به تغییرات محیطی، بازآرایی می‌شود. مراحل تاکرمن بازآرایی‌های پیش‌بینی‌پذیر در این سیستم هستند. هر بازآرایی هزینه دارد و سازمان‌هایی که این هزینه را در نظر نمی‌گیرند، با کاهش بهره‌وری مواجه می‌شوند.
در سطح شبکه‌های اجتماعی درون‌تیمی، مرحله‌ی طوفان با افزایش ترافیک تعارضی همراه است. این ترافیک را می‌توان با روش‌های تحلیل شبکه‌ی اجتماعی (Social Network Analysis) سنجید. ابزارهایی مثل تحلیل گراف ارتباطی درون تیم، امکان تشخیص زودهنگام شکاف‌ها را فراهم می‌کنند. سازمان‌هایی که این روش‌ها را جدی می‌گیرند، سریع‌تر می‌توانند از مرحله‌ی طوفان عبور کنند.
در معماری سازمانی، انتخاب ساختار تیم بر مسیر رشد آن اثر می‌گذارد. تیم‌های cross-functional که شامل تخصص‌های متنوع هستند، در مرحله‌ی طوفان تعارض بیشتری تجربه می‌کنند، اما در مرحله‌ی اجرا انعطاف‌پذیری بالاتری دارند. تیم‌های تخصصی که اعضایشان زمینه‌ی مشابه دارند، مرحله‌ی طوفان کوتاه‌تری دارند، اما در مواجهه با مسائل میان‌رشته‌ای کندتر عمل می‌کنند.
از منظر تئوری بازی‌ها، تصمیم‌های تیمی در مرحله‌ی طوفان به یک بازی هماهنگی تبدیل می‌شوند که در آن، اعتماد به‌عنوان یک سرمایه‌ی مشترک عمل می‌کند. هر تعامل منفی، این سرمایه را کاهش می‌دهد و بازسازی‌اش زمان می‌برد. مدل‌هایی مثل Iterated Prisoner''s Dilemma نشان می‌دهند که استراتژی‌های همکارانه در بلندمدت برنده هستند، اما فقط در صورتی که بازیکنان افق زمانی بلندمدت داشته باشند. تیم‌هایی که پروژه‌های کوتاه‌مدت و پراکنده دارند، این افق را از دست می‌دهند و در دام تعارض‌های غیرسازنده می‌افتند.
در لایه‌ی ابزار، سیستم‌های مدیریت پروژه می‌توانند به‌عنوان بازتاب‌دهنده‌ی وضعیت تیم عمل کنند. داده‌هایی مثل زمان حل issue، نرخ بازگشت کار و توزیع بار کاری، نشانه‌های دقیقی از مرحله‌ی تیم ارائه می‌دهند. سازمان‌هایی که این داده‌ها را در داشبوردهای مدیریتی دارند، زودتر از سایرین می‌توانند مداخله کنند. موضوعی که در چرا Jira انتخاب اول مدیریت پروژه توسعه است؟ از زاویه‌ی ابزار بررسی شده است. 📊
یک نکته‌ی ظریف در سطح رفتاری: مرحله‌ی طوفان در تیم‌های چندفرهنگی شدیدتر است. تفاوت در انتظارات ارتباطی، نگرش به سلسله‌مراتب و شیوه‌ی ابراز مخالفت می‌تواند تعارض‌های پنهانی بسازد که در ظاهر دیده نمی‌شوند. در تیم‌های توزیع‌شده‌ی جغرافیایی، این لایه‌ی فرهنگی باید آگاهانه مدیریت شود. 🧩
در نهایت، از منظر یادگیری سازمانی، مراحل تاکرمن بازتاب چرخه‌ی یادگیری Kolb هستند. هر مرحله یک تجربه‌ی مشخص است که اگر بازبینی شود، به یادگیری تبدیل می‌شود. تیمی که بدون بازبینی از مرحله‌ای به مرحله‌ی بعد می‌رود، تجربه را از دست می‌دهد. تیمی که بازبینی را بخشی از فرآیند می‌کند، هر مرحله را به یک سرمایه تبدیل می‌کند. 🎯
بستن بحث
مراحل پنج‌گانه تاکرمن یک چارچوب تشخیصی است، نه یک قانون سخت. شناخت آن به شما کمک می‌کند بدانید کجای مسیر ایستاده‌اید و چه اقداماتی متناسب با آن مرحله لازم است. مدیران مؤثر کسانی هستند که سبک خود را با مرحله‌ی تیم تنظیم می‌کنند و تعارض‌ها را به‌عنوان بخشی از رشد می‌پذیرند.
اگر تیمی را رهبری می‌کنید و در حال حاضر در مرحله‌ی طوفان هستید، بدانید که این مرحله‌ای گذراست. با پذیرش، گفت‌وگوی صادقانه و تصمیم‌گیری مبتنی بر معیار، تیم شما به مرحله‌ی بعدی می‌رسد. اگر در مرحله‌ی اجرا هستید، مراقب باشید که این وضعیت را دائمی فرض نکنید؛ تغییرات بیرونی همیشه در کمین‌اند.
اگر تجربه‌ای از عبور یک تیم از مرحله‌ی طوفان دارید، برایم جالب است بدانید کدام اقدام بیشترین اثر را داشت. تجربه‌تان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل جایگزینی برای مدیریت تعارض در تیم‌های فنی پیدا کرده‌اید.