تیم های مهندسی و ارتباطات کتبی در محل کار


در حالی که مدیران مهندسی خوب می توانند کدنویسی کنند، مدیران بزرگ نیز می توانند ارتباط برقرار کنند.

ارتباط نوشتاری، به طور خاص، برای مدیریت و مقیاس‌بندی تیم‌های مهندسی ضروری است. جان پل بوریتیکا، که چندین تیم موفق از مهندسان را رهبری کرده است که اخیراً به عنوان معاون مهندسی در شرکت موسیقی Splice بوده است.

کارشناسانی مانند Buritica می‌دانند که با رشد تیم‌های مهندسی، گردش کار، فرآیندها، آهنگ‌های تصمیم‌گیری – حتی استراتژی‌های پروژه – نیز تغییر می‌کنند. سیستم هایی که برای یک تیم دو نفره کار می کنند لزوما برای یک تیم 40 نفره کار نمی کنند و فرآیندهایی که برای یک تیم هم محل کارآمد هستند ممکن است برای یک تیم توزیع شده کارایی نداشته باشند.

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

Buritica با ایجاد این اسناد – و تشویق اعضای تیمش به اضافه کردن ایده های خود – نه تنها توانست تیم خود را در Splice از پنج نفر به 50 نفر در 18 ماه برساند، بلکه زمان تحویل محصول خود را از شش ماه به شش هفته کاهش داد.

در اینجا استراتژی سه مرحله ای او برای استفاده از ارتباطات نوشتاری برای بهبود عملکرد تیم مهندسی آورده شده است:

1. از روز اول چارچوب های ارتباطی و تصمیم گیری ایجاد کنید

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

یکی از اسناد بنیادی چیزی است که بوریتیکا الف می نامد معماری ارتباطات: قوانینی در مورد نحوه برقراری ارتباط تیم – از طریق Slack، تیم های مایکروسافت، ایمیل، تماس های تلفنی و/یا زوم- و انتظارات در مورد زمان پاسخ.

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

Buritica می‌گوید برای رسیدن به این راه‌حل، اولین قدم این است که تیم را در مورد این موضوع بررسی کنید: «چگونه باید با یکدیگر صحبت کنیم؟ چگونه باید در دسترس بودن خود را اعلام کنیم؟ چه چیزی کار نمی کند؟ چه چیزی می تواند بهتر کار کند؟ چگونه با شرایط اضطراری برخورد کنیم؟»

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

پس از انتشار اولین پیش نویس، تیم به مدت چند هفته در چارچوب پیشنهادی عمل می کند تا نحوه عملکرد فرآیند جدید را ارزیابی کند. با گذشت زمان آنها سایر تغییرات ضروری را در سند ادغام می کنند تا زمانی که عملکرد استاندارد را تعریف کند.

به عنوان مثال دیگری، Buritica ایجاد یک سند استراتژی در اسپلایس توضیح دهد که چگونه تیم مهندسی قرار است اهداف تجاری خود را برآورده کند. هدف تسریع تحویل محصول با ارسال سریعتر نرم افزار بود که به این معنی بود که تیم باید اصطکاک را کاهش دهد. او می‌گوید که سند استراتژی گام‌های لازم را تشریح می‌کند، «و ما شروع به آزمایش، آزمایش، گزارش‌دهی و صحبت درباره ایده‌هایمان کردیم». “همه شروع به مشارکت در سند کردند و واقعاً انگیزه پیدا کردند.” در نهایت تیم به هدف خود رسید، یعنی زمان تحویل را از شش ماه به شش هفته کاهش داد.

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

او چگونه مردم را به اسناد اعتماد می کند؟ او می گوید: من از آنها استفاده می کنم. “من از طریق فرآیند خودم زندگی می کنم. اگر من از آنها استفاده نکنم، چگونه می توانم انتظار داشته باشم که شخص دیگری این کار را انجام دهد؟»

2. به تیم اجازه دهید تا مالکیت اسناد را در اختیار بگیرد

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

این بدان معناست که مدیران باید با تیم هایی که اطلاعات را زیر سوال می برند راحت باشند. اجازه دادن به تیم برای ایجاد تغییرات، آنها را توانمند می کند، اعتماد ایجاد می کند و حل مشکل را تقویت می کند. او می‌گوید: «به عنوان مثال، اگر فرآیند تصمیم‌گیری کارآیی نداشته باشد، باید به طور جمعی آن را رفع اشکال کنیم. به عنوان مدیر، نمی‌توانم فقط بگویم، لطفاً تصمیم‌گیری بهتر را شروع کنید.»

بسیار مهم است که به خاطر اقتدار، اقتدار را آسان کنید و به ایده های تیم باز باشید. او می‌گوید: «از افرادی که در جلسات مرا به چالش می‌کشند، سؤالات دشوار می‌پرسند و دیگران را تشویق می‌کنند تا همین کار را انجام دهند، قدردانی می‌کنم. به عنوان مثال، در یک سند نوشتم که ما باید درخواست های کشش را در 36 ساعت ادغام کنیم. یکی از مهندسان من پرسید: “چرا 36 ساعت؟” و او پرونده ای برای تغییر آن ایجاد کرد.»

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

اگر تیم کوچکی باشد، Buritica به همه حقوق ویرایش می دهد. اگر گروه بزرگ‌تری باشد، او امتیازات ویرایش را فقط برای چند نفر از اعضای تیم حفظ می‌کند، اگرچه هر کسی می‌تواند پیشنهاد بدهد. در صورت بروز تعارض یا نظرات متناقض، مدیر تصمیم می گیرد. او می گوید: «این سند برای دموکراتیک یا اجماع نیست. “نباید همه موافق باشند.”

«اگر کسی به ما پیشنهاد دهد که ما فقط دو ساعت در روز کار کنیم، مدیر مهندسی باید به وضوح بگوید نه. این مسخره است،» او می گوید. ایجاد و نگهداری این اسناد یک فرآیند مشارکتی است که به مردم کمک می کند، اما دموکراسی نیست. در نهایت مدیر مهندسی مسئول بهره وری تیم، رفاه و عملکرد صحیح آن است. آنها حرف آخر را می زنند.»

3. پیچیدگی چارچوب های موجود را افزایش دهید تا تیم ها را مقیاس دهید

هنگامی که تیم ها توزیع می شوند، چارچوب های تصمیم گیری از اهمیت بیشتری برخوردار هستند.

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

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

بنابراین، او سند خود را مفصل تر بیان کرد. «سپس آن مدیر فرآیند را طی کرد و مصاحبه را امتحان کرد، و او سرانجام آنچه را که نوشته بودم اصلاح کرد، و اشاره کرد که چه چیزی کار می کند و چه چیزی نیست. با گذشت زمان، دیگر سند من نبود و تبدیل به سند تیم شد. و به تکامل خود ادامه می دهد.»

امروز، به عنوان یک تیم 50 نفره، این سند رشد کرده است تا شامل فرآیندهای مربوط به غربالگری، گفتگوهای فنی و ملاقات با اعضای تیم موجود باشد. او می‌گوید: «روبریک، بررسی‌های کور، و لهستانی‌های بیشتر وجود دارد. «این در سطح بعدی است. افرادی که خارج از فرآیند هستند، می توانند آن را بهتر درک کنند.”

آینده کار نوشته شده است

به همه این دلایل، بوریتیکا مهارت های ارتباطی نوشتاری را زمانی که تیمی را رهبری می کند در اولویت قرار می دهد.

«آیا می توانید به خوبی در یک رسانه نوشتاری ارتباط برقرار کنید؟ من توانایی کسی را برای درست بودن دستور زبان ارزیابی نمی کنم. انگلیسی حتی زبان اول من نیست. من می‌خواهم بدانم که آیا یک نامزد می‌تواند نظر خود را منتقل کند و تأثیر بگذارد.» هر عضو تیم باید توانایی های نوشتن خود را تقویت کند تا بتواند به طور موثر در چارچوب های ارتباطی مشارکت کند.

او می‌گوید: «بیش از دور بودن آینده کار، فکر می‌کنم آینده کار نوشته می‌شود، چه در یک مکان فیزیکی باشید یا نباشید». من هر تیم مهندسی را تشویق می کنم که بیشتر بنویسد. این می تواند به تیم شما کمک کند که به طور جمعی فکر کنند، به عنوان یک گروه تصمیم بگیرند، یاد بگیرند و رشد کنند.”



منبع

Matthew Newman

Matthew Newman Matthew has over 15 years of experience in database management and software development, with a strong focus on full-stack web applications. He specializes in Django and Vue.js with expertise deploying to both server and serverless environments on AWS. He also works with relational databases and large datasets
[ Back To Top ]