به عنوان یک انجینرینگ لیدر در مواردی با سازماندهی مجدد تیم روبرو میشوید. در این مقاله روش سازماندهی مجددYelp توسط دیوید کیگر را بررسی میکنیم.
گاهی شکل سازمان با نیازهای کسب و کار تناسبی ندارد، در این صورت چگونه میتوان بدون ایجاد هرج و مرج، سازماندهی جدید به وجود آورد؟
در بخشهای مختلف رهبری، نیاز به تغییرات سازمانی به وجود میآید. این امر ممکن است به خاطر رشد (یا کوچک شدن) کسب و کار باشد، یا ایرادات ارتباطی که در سیستم منعکس شده (قانون کانوی)، یا ناهماهنگی در مسؤولیتها که به عنوان تکامل نقشها در تیم بروز میکند. تغییر ساختار سازمانی در اصل مخاطره آمیز است و اجرای صحیح آن نیازمند برنامهریزی و آمادهسازی است.
تکامل یا دینامیت؟
وقتی زمان تغییر فرا میرسد از خود میپرسیم؛ تکامل و تغییر به طور طبیعی رخ خواهد داد یا باید بساط دینامیت را به پا کرد؟ در حالت ایده آل ما در گروه اول قرار داریم، اما گاهی رویکردهای شدیدتری لازم است.
به عنوان نمونهای از تغییرات تکاملی، میتوان به تیمی بزرگ اشاره کرد که به دو تیم کوچکتر تقسیم میشود. یا دو تیم کوچک که با هم ترکیب میشوند. شاید یک تیم که در حال منحل شدن باشد، مسؤولیت و افرادش در بخشهای دیگر سازمان تقسیم شوند.
در هر شرایط و با هر مشخصاتی، معمولاً خطوط مالکیت مثل قبل باقی میمانند و افراد را به نقشهای خود متصل باقی نگه میدارند. در چنین مواردی میتوانید با اعتماد به نفس رو به جلو حرکت کنید. با وجود چالشها و نگرانیها افراد چنین تغییراتی را درک و یا حتی پیشبینی میکنند.
اما گاهی به تغییر بزرگتری نیاز است. سازماندهی مجدد به هر اندازه که اختلال بوجود آورد، باعث ترس افراد میشود. شاید پنج تیم کوچک را به سه تیم بزرگتر تبدیل کنید یا فناوری مورد نظر (مالکیت محصول) را تغییر دهید. در هر حال ممکن است بعضی افراد انتظار چنین تغییری را داشته باشند و برخی هم غافلگیر شوند، خصوصاً اگر تغییرات به سرعت صورت گیرد.
هماندیشی ساختارهای جدید
وقتی نوع تغییری که با آن سر و کار دارید را شناسایی کردید، میتوانید قدم بعدی را بردارید: شناسایی مرزهای ساختاری جدید.
راحتترین روش برای این کار جمع کردن سیستمهای موجود با یکدیگر بر اساس ارتباط محصول یا مهندسی است. این کار پروژهای نیست که به تنهایی انجام دهید، بلکه به عهده شما و تیم اولتان است. از لحاظ محصول به تمام ویژگیهایی که محصول شما در بر دارد فکر کنید، جریانهای کاربری، اپلیکیشنهای مختلف و غیره. این موارد را به گروههایی تقسیم کنید که از منظر محصول منطقی به نظر برسد.
شاید تمام آنها بخشهای مرتبط با یک کاربر باشند، یا شاید به ایجاد یک KPI جدید کمک کنند. صرف نظر از جزئیات، باید با تعداد کمی از بخشهای مرتبط/منسجم مالکیت گروهتان، کار را به انجام برسانید.
قدم بعدی تکرار این پروسه اما از دید یک مهندس است. در این مرحله موارد مهمی که باید به آنها فکر کرد؛ ذخیره اطلاعات سرویسها، APIها و دیگر ملاحظات فنی است. این موارد را دوباره به گروههایی تقسیم کنید که از دیدگاه مهندسی منطقی باشند. این مورد احتمالاً بر اساس زیرساختهای فنی، وظایف on-call، توانایی استقلال و مواردی از این دست باشد. در پایان این پروسه باید دوباره با تعداد کمی از بخشهای منسجم مالکیت گروه روبرو شوید.
در حالت ایدهآل، این گروههای مهندسی کاملاً با مرزهای محصول هم راستا میشوند - روشی که ویژگی یا اجزای مختلف محصول مدیریت میشوند. اما هم راستایی کامل به ندرت اتفاق میافتد. وقتی تلاش میکنید مرزبندیهای مهندسی را تعدیل کنید تا به مرزبندیهای محصول نزدیکتر شوید، اصلاح و سازگاری اتفاق میافتد.
مهم است که درگیر مسائل پیش پا افتاده نشوید و توافقاتی وجود داشته باشد. مثلاً ممکن است یک API به دو گروه تقسیم شود تا مالکیت محصول را آسانتر کند، یا گستره محصول دارای چند KPI اضافی باشد، تا امکان گردش on-call پایدارتری را فراهم کند. گاهی این تصمیمات باید اختیاری باشد. مهمترین مسأله این است که در مواقع نیاز مخالفت صورت گیرد. در چنین شرایطی سازماندهی مجدد برای موفقیت یا شکست تنظیم میشود و باعث ایجاد چهارچوبی برای کارکنان میشود.
فهرستی از نامها
چندین دهه پیش، بوکسور معروف، مایک تایسون، عقیده داشت: «همه تا وقتی مشت اول را نخوردهاند، برنامهای دارند» . اگر چارچوب نظری شما برای سازماندهی مجدد نشان دهد که باید تیم را از صفر بسازید، فرآیند استخدام احتمالاً اولین مشت خواهد بود. شاید خوششانس باشید و در اولین تلاشتان افراد ایدهآل را پیدا کنید، اما معمولاً سازماندهی مجدد اینگونه پیش نمیرود.
درعوض، با افرادی روبهرو خواهید شد که هر یک تخصص، نظرات، بینشها و تجربههای خاص خود را دارند. وظیفه شما این است که آنها را در جایگاهی قرار دهید که بتوانند به بهترین شکل مشارکت کنند و در عین حال، از نظر شخصی و حرفهای رضایت داشته باشند. موفقیت به این عنصر بستگی دارد – کاملترین ساختار روی کاغذ، اگر باعث شود تا شش ماه آینده همه کارشان را ترک کنند، حتی ارزش چاپ شدن ندارد.
شما باید نقشهای ایدهآل برای هر فرد را شناسایی کنید. باید بدانید چه کسی از این نقشها هیجانزده میشود، چه کسی شکاک است، و چه کسی مخالف. قطعاً همه چیز را بهطور کامل انجام نخواهید داد، به همین دلیل به برنامههای پشتیبان نیاز دارید، چون تغییرات زنجیرهای خواهند بود؛ اگر فردی از تیمی که به او اختصاص داده شده راضی نباشد، باعث تغییراتی میشود که نیازمند جابهجایی افراد دیگر تیم نیز خواهد بود. شناسایی تصمیمات استخدامی که اثر زنجیرهای دارند و گرفتن تأییدیه از کسانی که درگیر این تغییرات هستند، کمک میکند انتقال به شکلی روانتر انجام شود.
اما وقتی پای آشنا شدن با افراد به میان میآید، هرکدام تفاوتهایی دارند؛ بنابراین باید با هرکس متناسب با نیازها و انتظاراتش برخورد کنید. بعضی افراد با فهمیدن انتقالشان به تیمی دیگر خوشحال میشوند، در حالی که برخی دیگر احتمالاً در صورت نداشتن حق انتخاب، کار را ترک کنند. اینکه بدانید با چه کسی صحبت کنید، چگونه با او صحبت کنید، و چه زمانی این کار را انجام دهید، کاملاً کلیدی است تا مطمئن شوید که اکثریت ممکن افراد از این تغییر احساس رضایت داشته باشند.
برنامهریزی انتقال (جابجایی)
برای سازماندهی مجدد یک جدول زمانی شفاف ایجاد کنید. مهم نیست چقدر تلاش کردهاید تا افراد را به تیمهای مناسب اختصاص دهید، اگر خبر از طریق کانالهای غیررسمی به آنها برسد، برای همه سختتر خواهد شد. علاوه بر این، اعلام تغییر بدون ارائه یک برنامه زمانی مشخص، اضطراب را افزایش میدهد. برای جلوگیری از این وضعیت، یک برنامه اطلاعاتی تنظیم کنید. اینکه چه کسی، چه زمانی و چرا مطلع شود، شکلدهنده باقی فرآیند خواهد بود.
وقتی همه در جریان قرار گرفتند، میتوانید مراحل بعدی را پیش ببرید. با وجود تمام تلاشها، همیشه بخشهایی از مالکیت وظایف وجود دارد که شفافیت کمتری دارند. وقتی همه در جریان قرار گرفتند، کار سخت مشخص کردن جزئیات دقیق آغاز میشود. در این مرحله، ارائه یک جدول زمانی پیشبینیشده برای انتقال اهمیت دارد تا مشخص شود چقدر زمان و تلاش میتوان برای پرداختن به بخشهای نامشخص صرف کرد. همچنین، این زمان برای برنامهریزی ارتباطات گستردهتر با تیمهای همکار یا ذینفعان نیز مناسب است.
آخرین بخش برنامه، در نظر گرفتن مدت زمان سازماندهی مجدد است. امیدواریم برای یک تغییر کوچک و تدریجی، همه چیز در چند هفته حل شود. اما اگر بخواهید ساختار یک سازمان ۲۰۰ نفره را بازطراحی کنید، ممکن است یک سال یا بیشتر طول بکشد. دانستن این موضوع به شما کمک میکند انتظارات واقعبینانه داشته باشید و آنها را به گروههای داخلی/خارجی مناسب منتقل کنید. همچنین کمک میکند تا مراقب بقایای دراز مدت تغییرات باشید تا این موارد به طور دائم در بلاتکلیفی باقی نمانند.
نتیجه گیری
حالا که ساختار جدیدی در ذهن دارید، افراد مناسب را به تیمهای مناسب انتقال دادهاید و برنامهای قوی برای اطلاعرسانی و اجرای طرح دارید، وقت آن است که این برنامهها را عملی کنید. هنوز ممکن است هزاران مسأله پیش بیاید، اما انجام این کارهای اولیه احتمال وقوع مشکلات را بسیار کاهش میدهد. و اگر هم مشکلی پیش بیاید، شما برای آن آماده خواهید بود.
