https://virgool.io/feed/@alhich fa 2026-06-07 09:19:27 https://files.virgool.io/upload/users/17078/avatar/avatar.png?height=120&width=120 https://virgool.io/@alhich https://virgool.io/@alhich/teamwork-p2-ilrdvaeee3oq ادامه از بخش اول: کار تیمی در مهندسی نرم‌افزار - ویرگول (virgool.io)«تیم»حالا راه‌حل مصالحه بین «ارزیابی عمل‌کرد» و «معنادار کردن» کارکنان چیست؟ چگونه تیمی داشته باشیم که اعضای خوش‌حال و بهروزی داشته باشند و در عین حال «دستاوردهای تیمی»شان هم قابل توجه باشد؟من این مساله را در سه سطح می‌توانم در نظر بگیرم:۱- ویژگی‌های فردی اعضای تیم ۲- ویژگی‌های جمعی یک تیم به عنوان یک موجودیت مستقل ۳- پویایی رابطه بین اعضای تیمدر نظر من این‌ها پایه‌های یک هرم‌اند. زیرساخت هر تیم موثر چابکی را «شخصیت تک‌تک اعضا» تشکیل می‌دهند. اگر اعضای خوبی داشته باشیم می‌توانیم به مولفه‌های داشتن یک تیم موثر فکر کنیم. و در نهایت تلاش کنیم که یک رابطه پویا و تعالی‌بخش بین اعضای تیم تشکیل دهیم.بعد ازین نوبت به طراحی یک سری فرایندهای اثربخش داخلی می‌رسیم، چگونه از تفکر طراحی برای حل مساله استفاده کنیم، اصول چابکی را در فرایند توسعه نرم‌افزار دخیل کنیم و در نهایت موجب معرکه‌ شدن همه شویم.اما در ابتدا به قسمت اول و ویژگی‌های فردی «یک بازیکن تیمی ایده‌آل» بپردازیم:ویژگی‌های فردی اعضای تیم و «بازیکن تیمی ایده‌آل»:چارچوب این قسمت را از کتاب پاتریک لنچیونی با همین نام گرفتم.مولفه «فروتنی» یا Humble:مهم‌ترین مولفه یک بازیکن تیمی «فروتنی» است که کمی درباره‌ش صحبت کردیم. این مولفه ازین جهت مهم است که به سختی قابل آموزش است. بیش‌تر یک مولفه شخصیتی است. بنابراین در هنگام استخدام باید مواظب این مولفه باشید. البته که بایستی در فرهنگ سازمانی روی این مسئله کار کنید. بخش بزرگی از آن هم توسط «بنیانگذاران» شکل می‌گیرد. اما بعد از آن هم باید در داخل سازمان ازش نگهبانی شود و در هنگام استخدام و ترفیع و اخراج همیشه بهش توجه جدی شود. خصوصن در هنگام طراحی «نردبان شغلی» بایستی یک مولفه اساسی باشد. یعنی هر کسی نردبان را نگاه می‌کند بایستی متوجه ارزش «فروتنی» در این نردبان باشد. کلن نردبان بایستی بازتاب‌دهنده نظام ارزشی سازمان باشد.باری درباره «فروتنی» به قدر کافی صحبت کردیم. دو مولفه دیگر این چارچوب این‌ها هستند:مولفه «ولع» یا Hunger:به سادگی اینکه افراد میل به این داشته باشند که کارها را با کیفیت و کمیت بیش‌تری از آنچه در تعریف وظیفه آمده است انجام دهند. میل به انجام به‌تر و بیش‌تر کارها!این ویژگی خاصی است و به راحتی ممکن است با «اضافه کاری»‌ اشتباه شود. کارمندانی تشویق شوند که ساعت کاری زیادی دارند و مدام «اضافه کاری» می‌ایستند. البته من کلن سیستم «انگشت زنی» و «محاسبه دقیق ساعت کاری» و «اضافه کار» را چندان کارا نمی‌دانم. اما فارغ ازین فرایند، قرار نیست «ساعات کاری زیاد» هم ارزش اساسی باشد. یعنی اگر کسی فقط همان ساعات کاری معمول ۴۰ ساعت در هفته را حضور داشت، امکان رشد در نردبان شغلی را از دست بدهد.اما «ولع» یعنی اینکه آدم‌ها میل به اتمام خوب و با کیفیت کار داشته باشند. اگر در شرایط رساندن کار در ضرب‌الاجلی هستیم به خودشان «فشار» بیاورند و از دیگر زمینه‌های کاری بزنند. مثلن برای مدتی در سر کار تفریح نداشته باشند، مطالعه کاری و زمان گذاشتن برای رشد انفرادی را کنار بگذارند. جلسه‌های طولانی را کم‌تر کنند و با تمرکز تمام به «رساندن با کیفیت کار» فکر کنند. حالا بخشی از افراد هم احتمالن می‌توانند «زمان بیش‌تری» را هم بگذارند.اگر هم در شرایط «ضرب الاجل» نیستیم «ولع» به این معنا هم هست که همان کاری را که داریم را با همه‌ی حدود و صغورش با کیفیت انجام دهیم. «گوشت» و «استخوان» را با هم بخواهیم. هم «مستندسازی» خوبی داشته باشیم، هم «تست‌نویسی خودکار» خوبی داشته باشیم. هم «تست انسانی و دستی» را خودمان در حد خودمان انجام دهیم. هم از هم‌کاران داخلی و بیرون تیمی «پیگیری» داشته باشیم. هم «صورت‌جلسه‌ها» را بنویسیم.کارها معمولن چند دسته دارند. یکی اینکه کار مستقیمن در حوزه مسئولیت من است و آن را هم بلدم. که خب انجامش می‌دهم. اما بسیاری از کارها است که یا «کمی» با حوزه مستقیم مسئولیت من فاصله دارد، یا اینکه «کمی» با حوزه توان‌مندی من فاصله دارد. «ولع» یعنی من انگیزه داشته باشم که این «فاصله‌»ها را با اشتیاق طی کنم و کارها را به سرانجام برسانم.من روی کلمه «فاصله‌ی کم» تاکید می‌کنم. اینجور نباشد که من نابخردانه کار بزرگ‌تر از توان‌مندی و مسئولیتم به عهده بگیرم و تهش کار را خراب کنم و یا با کیفیت خیلی کمی به انجام برسانم. درک این «مناسب بودن» هم بخش مهمی از کار است و البته نقش «مدیر تیم» درین میانه برجسته است. من این‌جا یاد آن دعای معروف آرامش می‌افتم که از «شریعتی» نقل میشه :)«پروردگارا،آرامشی ده تا بپذیرم آن‌چه را که نمی‌توانم تغییر دهم،شهامتی ده تا تغییر دهم آن‌چه را که می‌توانم،و خردی ده تا یکی را از دیگری تشخیص دهم»یک «خطر» دیگر در فهم «ولع» فارغ از «پرکاری بیهوده» مساله «اتمام تعداد زیادی تسک در زمان کوتاه» است. بعضی وقت‌ها در سازمان‌ها فردی تشویق می‌شود که سرعت خیلی زیادی در اتمام تسک‌ها دارد. البته که چیز خوبی است. منتها به دو شرط: یکی فدا نکردن کیفیت و دوراندیشی است. دومی توان‌مندی استمرار سرعت در بلند مدت است. سازمان‌ها در عمده دوران زندگی‌شان درگیر «دوی ماراتون» هستند نه «دوی سرعتی صد متر».بعضی وقت‌ها برنامه‌نویس‌ها یادشان می‌رود که بسیاری از تصمیمات آن‌ها و کدهای متعاقب‌شان قرار است سال‌های سال در پروژه باقی بمانند و به همان شکل اولیه ازشان استفاده شود. خیلی از تصمیمات و کدها بازنویسی نمی‌شوند. و خب اگر کدی قرار است پنج سال در بخش عمیقی از برنامه استفاده شود خردمندانه است اگر پنج ساعت برای معماری‌ش فکر کنیم. اصلن عامدانه پیاده‌سازی را پنج روز عقب بیندازیم و برای جنبه‌های مختلفش با کمک همه‌ی تیم سناریو پردازی کنیم و با حداکثر دانش تیمی برویم و پیاده‌سازی‌ش کنیم.این مساله را بسیاری از مهندسان نرم‌افزار مهاجرت کرده باهاش مواجه می‌شوند. معمولن حجم کاری که در شرکت‌های آلمانی پیش روی هر مهندسی قرار دارد خیلی کم‌تر و ساده‌تر از وضعیت‌شان در ایران است. و با این حال خیلی وقت‌ها هم کیفیت پروژه بیش‌تر از تجربیات ایران است.باری، فکر می‌کنم برای یک مرور کوتاه درباره «ولع» به قدر کافی صحبت کردیم. حالا به مولفه آخر و سوم بپردازیم:مولفه «هوش‌مند»ی یا Smart:هوشمندی یک بازیکن تیمی ایده‌آل چیز ساده‌ای است. تا حدی با مفهوم «هوش هیجانی» قرابت دارد و اما کمی ساده‌تر و البته فراتر از آن است.بازیکن تیمی ایده‌آل دارای هوش هیجانی هست. حواسش به پویایی پیچیده‌ی رابطه‌ها در گروه است. بلد است که چگونه با دیگران به طور موثر تعامل کند. و در نهایت بصیرت خوبی درباره برداشت بقیه از حرف‌ها و کارهایش در تیم دارد.یک بازیکن هوشمند درک خوب و واقعی از رفتار انسانی دارد. می‌داند که تیم‌ها در وضعیت‌های احساسی گوناگونی قرار می‌گیرند و هر اقدامی مناسب هر وضعیتی نیست. مثلن وقتی سرویس نرم‌افزاری پایین است دنبال افزایش هیجان نیست، دنبال پست مرترم هم نیست! بلکه سعی می‌کند خونسردی خودش را حفظ کند و با هم‌کاری جمعی اول از همه در یک شرایط آرام سرویس را به وضعیت عملیاتی برگرداند.همین‌طور اگر قصد دارد انتقاد بزرگی را راجع به وضعیت تیم بیان کند منتظر یک وضعیت آرام و باثبات باقی می‌ماند. نه اینکه در میانه‌ی ورود یک نیروی جدید به تیم و در اولین جلسه روزانه‌ یک بحث بزرگ و سخت کاری را باز کند.در ضمن سبک کاری اصلی بازیکن هوشمند استفاده از تاثیر مثبت/ Infuence‌ بجای تلاش مدام برای استفاده از اختیارات / Authority است. و در نهایت همان‌گونه که در بخش فروتنی هم خاطرنشان کردیم تمرکز اصلی بازیکن تیمی ایده‌آل بر همکاری تیمی است و می‌داند که موفقیت جمعی مهم‌تر از تشویق فردی است.ویژگی‌های یک تیم به عنوان یک موجودیت مستقلخب بیایید امیدوار باشیم که جمعی را دور هم داریم که «بازیکن تیمی ایده‌آل» به شمار می‌روند. حالا اگر بخواهیم یک تیم را به عنوان یک شخصیت مستقل نگاه کنیم، چه ویژگی‌هایی تضمین کننده موثر بودن تیم خواهند بود؟ شرکت گوگل در یک پروژه بسیار بزرگ و بعد از سال‌ها تحقیق، به ۵ عامل رسید که این‌ها بودند:۱- امنیت خاطر روانی - psychological safety: اعضای تیم در هنگام انجام ریسک احساس امنیت می‌کنند و خودشان در مقابل بقیه اعضای تیم آسیب‌پذیر کرده‌اند. «امنیت خاطر» یکی از بنیادی‌ترین مولفه‌های یک تیم موثر است. تیمی که از توان همه‌ی اعضایش برای نتیجه گرفتن بهره می‌گیرد. تیمی که «برداشتن ریسک» را تشویق می‌کند. تیمی که «اشتباه کردن» را جزو جدایی ناپذیری از کار می‌داند. تیمی که افراد بعد از انجام «اشتباه» دنبال «مقصر فردی» نمی‌گردند. بلکه به دنبال پیدا کردن راه‌حل در فرایند‌ها و محصول‌شان هستند. تیمی که جوان‌ٰترین و کم‌سابقه‌ترین فرد تیم هم حق اظهار نظر درباره همه‌ی وظایف تیم را دارد. و البته بقیه هم حق دارند که اشتباهات بزرگ و کوچک‌ش را به او متذکر شوند. این «امنیت خاطر» ارتباط تنگاتنگی با مفهوم «اعتماد متقابل» اعضای تیم به هم دارد. کلن زیربنای هر کار تیمی فداکاری کردن و ریسک کردن بر سر «اعتماد‌» است. که خب درباره‌ش به قدر کافی صحبت کردیم.۲- قابلیت اتکا - Dependability: اعضای تیم «شخصیت قهرمانی» دارند و کارها در موعد مقرر به سرانجام می‌رسانند و استانداردهای بالایی برای کارشان معین می‌کنند. شاید به دست آوردن «امنیت خاطر روانی» در تیم سخت باشد. اما از آن سخت‌تر تیمی است که فقط و فقط به امنیت خاطر روانی فکر می‌کند. اینقدر امنیت خاطر زیاد است که کسی نگران نتیجه نیست. این‌جاست که این «شخصیت قهرمانی» عنصر مهمی است. آدم‌ها درین تیم‌ها میل به عمل- Bias To Action دارند، حواس‌شان هست که نتیجه خیلی مهم است و برای نتیجه خوب باید فداکاری کنند، احتمالن تعارضات زیادی را ایجاد و حل کنند، از هم مطالبه مسئولیت کنند و کارها را در موعد مقرر و با استاندارد بالا تحویل می‌دهند. بله، اعضای تیم حق اشتباه کردن دارند، اما «اشتباه تکراری» چندان قابل قبول شمرده نمی‌شود، و اگر یک نفر مدام در حال اشتباه کردن است احتمالن مشکل‌ش «عدم شایستگی» کافی است نه «نبودن امنیت خاطر روانی».پرانتز: یک نکته کوچک درباره نقش مدیر تیم هم درین مورد بگویم. و منظورم دقیقن جنبه Manager تیم است. نه Coach, Mentor, Leader. در نهایت مهم‌ترین وظیفه مدیر تیم این است که یک «تیم کارا و خوشحال» بسازد. یعنی هم تیم به نتایج مورد نظر برسد. و هم با حال خوب به این نتایج برسد. هر کدام ازین جنبه‌ها اگر مختل بشود دیگر نمی‌شود روی تیم حساب کرد. بله، من معتقدم که مهم‌ترین سبک رهبری و شاید تنها سبک درست Servant Leadership است. منتها این راه‌بری باید در خدمت «همه» باشد. یعنی هم اعضای تیم، هم ذی‌نفعان تیم (مثل سهامداران) و مهم‌تر از همه «مشتریان تیم». و «بُرد» باید برای همه باشد. درین مسیر مدیر تیم حتمن باید مربی خوبی باشد. یعنی جهت درست را شناسایی کند، به اعضا نشان بدهد و در مواقع شکست و اشتباه هم حمایت‌شان بکند. منتها اگر لازم است بازیکنان تیم را تعویض کند، یا حتا اخراج کند. به طور خلاصه در عین اینکه بکوشد که تا حد ممکن مستقیما از Authority ش استفاده نکند، اما اگر زمانش رسید اصلن از استفاده از ابزار قدرت خجالت نکشد و با اعتماد به نفس ازش استفاده کند. این ابزار خصوصن در ایجاد یک «شخصیت قهرمانی» چیز مهمی است. تیم خوب حتمن به Fast Fail اعتقاد دارد. منتها به Succes Faster اعتقاد بیش‌تری دارد و از باختن بدش می‌آید و بهش برمی‌خورد. و مدیر نقش کلیدی درین قضیه دارد.۳- شفافیت - Clarity: اهداف، برنامه‌ها و نقش‌ها از شفافیت کافی برخوردارند و ابهامی وجود ندارد. در نتیجه همان «تعارضات سازنده» و البته در سایه «مدیریت شایسته» هر وظیفه‌ای یک مسئول مشخص دارد و هر فردی هم مسئولیت مشخص و ترجیحن فقط همین یک مسئولیت را دارد. اعضا هم به این اهداف مورد اجماع تیم کاملن متعهدند. این اهداف کاری فردی و تیمی هم تا حد خوبی هم‌راستا با ماموریت کلی سازمان است. که مدیران ارشد سازمان به شکل مرتب و مداوم و حتا می‌شود گفت به شکل افراطی در حال ترویج و تبلیغ آن هستند. درباره «چشم‌انداز مشترک» من «افراط» در صحبت را به «تفریط» ترجیح می‌دهم. و معمولن سازمان‌ها به «تفریط» می‌افتند. چشم‌انداز مشترک چیزی است که هم برای «شفافیت» مهم است و هم در بخش «معنا» درباره‌ش صحبت کردیم.گوگل دو عامل «معنا» و «اثرگذاری» را هم در ادامه برمی‌شمرد که ما در بخش‌ ماموریت کمی درباره‌ش صحبت کردیم.پویایی رابطه بین اعضای یک تیمخب حالا می‌دانیم مهم‌ترین مولفه‌های یک تیم موثر چه چیزهایی هستند. سوال اصلی این است که نحوه رابطه بین اعضای تیم چگونه باید باشد که بتوانیم یک تیم موثر بسازیم؟ پاسخ این سوال را داخل کتاب «پنج دشمن کار تیمی» می‌جوییم:پنج دشمن کار تیمیتیم‌های خوب آن‌هایی هستند که از لحاظ ارزشی هرم زیر را رعایت می‌کنند:۱- این تیم‌ها توجه اصلی‌شان به «نتایج جمعی» است. درین تیم‌ها ماموریت تیم مسئله کلیدی است و به صورت مدام یادآوری می‌شود. نه این‌که فقط یک بیانیه کاغذی چسبانده به دیوار باشد. درین تیم‌ها «ارزش خلق شده برای مشتری، هم‌کاران، ذی‌نفعان و خود اعضای تیم» ماموریت اصلی برشمرده می‌شود و بالاتر از منفعت‌های شخصی اعضای تیم قرار می‌گیرد. این امر چگونه ممکن است؟ با رعایت اصل بعدی:۲- درین تیم‌ها همه اعضای تیم خود را «نگاهبان ماموریت کل تیم» می‌دانند. بر خلاف کارگروه‌ها که افراد فقط به رییس کارگروه پاسخ‌گو هستند، در این تیم‌ها همه از هم «مطالبه مسئولیت» می‌کنند و همه به همه پاسخ‌گو هستند. که من را یاد حدیث نبوی «کلکم راع و کلکم مسئول عن رعیته» می‌اندازد. درین تیم «استاندارد کارها» بالا است و «کار ضعیف» از هیچ کسی پذیرفته نمی‌شود. و همه از هم انتظار کارهای با کیفیت بالا دارند. این امر چگونه ممکن است؟ با رعایت اصل بعدی:۳- درین تیم‌ها «تعهد» بالایی به کارهای توافق شده وجود دارد. هر تسکی به صورت شفاف معین شده است. و مسئول انجام هر کاری هم روشن و مشخص است. ابهامی در زمینه خود وظایف و مسئول آن وظیفه وجود ندارد. «تعهد» درین تیم‌ها به معنای «موافقت همه افراد با همه وظایف» نیست. بلکه به معنای «تعهد به انجام وظایف بعد از اجماع تیم روی آن‌هاست، حتا اگر نظر شخصی من مخالف با نظر تیم باشد در نهایت من به اجماع تیم احترام می‌گذارم و بهش متعهد باقی می‌مانم». این امر چگونه ممکن است؟ با رعایت اصل بعدی:۴- درین تیم‌ها همه‌روزه «تعارضات سازنده» رخ می‌دهد. تیم از «گفتگوهای سخت» فرار نمی‌کند. بلکه حتا «کاوش‌گر تعارضات» دارند که بحث‌های سخت را به صحنه تیم می‌آورد. اعضای تیم مهارت‌های ارتباطی بالایی دارند و حرف همه درش شنیده می‌شد. افراد هم‌دیگر را قضاوت نمی‌کنند و این‌گونه نیست که فقط بعضی‌ها حق تصمیم‌گیری داشته باشند. بلکه از نیروی تازه‌کار هم انتظار می‌رود مشارکت فعال در تصمیم‌گیری تیم داشته باشد. و نتیجه این می‌شود که این تیم‌ها درگیر «هماهنگی تصنعی» نمی‌شوند. این امر چگونه ممکن است؟ با رعایت اصل بعدی:۵- درین تیم‌ها «اعتماد» جاری است. اعضا خودشان را نسبت به یک‌دیگر «آسیب‌پذیر» کرده‌اند. هم‌دیگر را به عنوان «انسان جایزالخطا» پذیرفته‌اند. در عین حال نسبت به «ماموریت تیم» حس دلبستگی دارند و تمام تلاش‌شان را می‌کنند که «قابل اطمینان، شریف و سخاوتمند» (‌با تعاریف برنه براون) باقی بمانند. این اعضا بدون شرمندگی از هم کمک می‌خواهند. و درین کمک‌خواهی هم‌دیگر را قضاوت نمی‌کنند. این اصل آخر و بنیادین بود. و جاری کردن‌ش در تیم از همه کارها سخت‌تر است. اما وقتی این اتفاق بیفتد انجام کارهای بالایی خیلی آسان‌تر خواهد بود.فهمیدن پنج دشمن کار تیمی در ابتدا امر ساده‌ای به شمار می‌رود. اما مهارت پیدا کردن در دیدن این مشکلات در لابلای کارهای روزمره تیم نیاز به مهارت و تمرین زیادی دارد. خود من در جاهای مختلف تلاشم برین بود که این کتاب را به شکل Bible ببینم و هر هفته مقداری از وقتم را برای مرور اتفاقات تیم در همین چارچوب فکری سپری کنم. ببینم کجای کار ما لغزیدیم و دچار dysfunction شدیم. و کجای کار را با مهارت خوبی توانستیم ازین pitfall ها گذر کنیم و یک کار موثر تیمی را به سرانجام برسانیم.جمع‌بندیخب مقداری درباره برداشت‌هایم از کار تیمی درست و استاندارد گفتم. در پست بعدی سعی می‌کنم تجربیات واقعی‌م در محل کار را با توجه به این چارچوب‌ها برایتان بازگو کنم. چگونه بعد از اتفاقات و تصمیمات بزرگ می‌نشستیم و عملکرد خود تیم را با توجه به این «ارزش‌ها» و «چارچوب»ها مرور می‌کردیم و از دل این مرور یادگیری داشتیم. و اینگونه تیم‌ها را درگیر یک «چرخه تعالی» می‌کردیم.همین‌طور درباره «فرایندها» صحبت خواهم کرد. حالا که جمعی از «بازیکنان تیمی ایده‌آل» داریم و تیم «شخصیت قهرمانی» دارد و «رابطه پویا و سالمی» هم بین اعضا برقرار است، چگونه با تعریف فرایندهای درست بر بستر این تیم محصولات خوبی بسازیم و برای همه‌ی مردم خلق ارزش کنیم. درباره «تفکر طراحی» صحبت می‌کنم که به درستی بتوانیم «ارزش» واقعی را شناسایی کنیم. درباره «چابکی» تیم‌های نرم‌افزاری صحبت می‌کنم که چطور بهینه‌تر بتوانیم «ارزش» را خلق کنیم و همینطور اینکه «هنر بازخورد»‌ حرف می‌زنم و اینکه چگونه باید در سازمان جاری‌ش کرد که «چرخه تعالی»‌ را به چرخش بیاورد. خدا قوت اگر تا این‌جای نوشته را همراه بودید و فعلن زیاده جسارت است.📷 Hossein Ansari Hossein Ansari Sun, 28 Apr 2024 14:00:19 +0330 https://virgool.io/@alhich/teamwork-nnqsvlgeidq1 نقل قول از کتاب باستانی حکمت مهندسی:«کدنویسی» بیشتر یک امر خلاقانه‌ی فردی است، اما «مهندسی نرم‌افزار» یک تلاش تیمی در راستای خلق ارزش برای انسان‌هاست.مقدمه:مشهور است که مهم‌ترین عامل سبک کاری هر فردی حاصل تجربه‌ی اولین کار حرفه‌ای اوست. من خوش‌اقبال بودم که اولین تجربه‌ی کاری‌م در یک محیط آموزشی پیشرو گذشت. در «پژوهش‌سرای دانش‌آموزی رباتیک مشهد» حدود ۵ سال در حوالی سال ۱۳۸۸ مسئولیت آموزش مفاهیم «برنامه‌نویسی» را در قالب «مسابقات روبوکاپ» به دانش‌آموزان دختر و پسر دبیرستانی داشتم. در آن سال‌ها یادگیری‌های بسیار زیادی درباره مفاهیم «کار تیمی» داشتم. ما تیم‌های موفق بسیاری ساختیم و ده‌ها رتبه در مسابقات مختلف کشوری به دست آوردیم. و مهم‌تر از همه نسلی ساختیم که بعدها به موفقیت‌های چشم‌گیری در ادامه زندگی تحصیلی و حرفه‌ای خودشان دست یافتند. بعدها فرصت بسیار خوب دیگری فراهم شد که با جمعی از دوستان «استارتاپ بله» را بنیان گذاشتیم و از یک تیم سه نفره به یک سازمان صد نفره رشد کردیم. باز مدتی در «کارگزاری مفید» به عنوان یک سازمان هزار نفره، نقش راه‌بر ارشد فنی را داشتم. برای من تجربیات این دوره‌ها شباهت‌های زیادی داشت، درین‌ جستار بعضی از یافته‌هایم درباره کار تیمی در فضای مهندسی نرم‌افزار را با نگاهی به این تجربیات بازگو می‌کنم. در ضمن درین پادکست هم کمی درباره همین مسایل گپ زدیم: اپیزود هجدهم | پیمان فخاریان با حسین انصاری | پیام‌رسان بله، کارگزاری مفید | در مسیر ساختن تیم کارا (youtube.com) آدم‌ها دوست‌داشتنی هستند.همان‌طور که گفتم من بابت این اولین تجربه کاری خوش‌اقبال بودم. چرا که دوست داشتن نوجوانان دختر و پسر ۱۵ ساله، با انبوهی از انرژی، شوق زندگی، بی‌آلایشی و البته کنجکاوی برای یادگیری رباتیک کار ساده‌ای بود.اما در نهایت من شیفته این حدیث نبوی هستم: «الخلق عیال الله، فَأحبُّ الْخلق إلی الله من نَفَع عیالَ الله» به این معنا که «مردم، خانواده پروردگار هستند، پس محبوب‌ترین مردم نزد پروردگار، کسی است که بیش‌ترین سودمندی را برای‌ خانواده حضرت حق داشته باشد». و درین حدیث از کلمه «خلق» استفاده شده است، نه «مسلمانان» یا «مومنان». نه «مردان» یا «زنان». بلکه کلمه «خلق» بار عام دارد و شامل همه‌ی انسان‌ها می‌شود. همان‌گونه که عارف ما «شیخ خرقانی» گفت: «هر کس درین سرای درآید نانش دهید و از ایمانش مپرسید، چه آن کس که به درگاه باری‌تعالی به جانی ارزد البته به خوان ابوالحسن به نانی ارزد».کار تیمی خوب وقتی صورت می‌گیرد که همیشه این پیش‌فرض ساده را در ذهن‌مان داشته باشیم: «آدمی به ذات ارزش‌مند و دوست‌داشتنی است». و «میزان مهارت‌، تجربه، اشتباهات، قیافه و …» از ارزش‌مندی ذاتی او کم نمی‌کند. ممکن است به عنوان یک مدیر حتا یک نفر را اخراج کنیم. اما این به معنای «بی‌ارزشی» او در مقام یک انسان نیست. فقط درین تیم خاص، درین زمان خاص، درین پروژه خاص نتوانسته‌ایم پیچ و مهره‌مان را با هم چفت کنیم و خوب کار کنیم. تازه آن هم معلوم نیست اشتباه کدام از طرفین بوده است، اما در نهایت ما در کنار هم انسان‌یم و منزلت یکسانی داریم.این‌جا وقت خوبی است که به اولین اصل از اصول سه‌گانه کتاب «بازیکن تیمی ایده‌آل» اثر «پاتریک لنچیونی» اشاره کنم. در ادامه به این نویسنده و اثر مشهور‌ترش «پنج دشمن کار تیمی» باز می‌گردم. اما درین کتاب اول سه مولفه برای یک بازیکن تیمی نقل می‌کند: «فروتنی، ولع و هوش‌مندی». «Humble, Hunger, Smart»فروتنی اولین و مهم‌ترین ویژگی یک بازیکن تیمی ایده‌آل است. شاید بقیه مولفه‌ها را بشود کمی در حین کار بهبود داد و پرورش داد، اما خیلی سخت است فروتنی را در طی دوران کاری تغییر داد. تعریف فروتنی از دید پاتریک این‌گونه است:عدم تکبر زیاد: افراد متواضع از اغراق در اولویت شخص خودشان پرهیز دارند. آن‌ها در سپاسگزاری از مشارکت دیگران سریع و در جلب توجه به اهمیت خودشان کند هستند.تمرکز بر تیم: آن‌ها تاکید دارند که موفقیت تیم مهم‌تر از دستاوردهای فردی است. به اشتراک گذاشتن افتخار و تعریف موفقیت به صورت جمعی، جزء اصول آن‌ها است .مورد یک به خصوص من را یاد این حدیث از «امام صادق» می‌اندازد: «از نشانه های انسان مؤمن این است که کار نیک خود را کم می بیند؛ هر چند کارش زیاد باشد و کار خیر دیگران را زیاد می بیند؛ هر چند کم باشد»حالا فرض کنیم ما جمعی داریم که فروتنی جزو ارزش‌های اصلی آن‌ها به شمار می‌رود. مدیر برای اعضای تیم‌ش منزلت ذاتی انسانی قائل است.یک تیم خوب یک ارزش اصلی دیگر هم دارد که آن هم تا حد خوبی محصول یک نوع نگاه به ذات بشر است: «آدم‌ها به دنبال رشد هستند. دنبال داشتن دل‌بستگی و ساخت معنا هستند. و بخش خوبی ازین معنا و دل‌بستگی می‌تواند در محیط حرفه‌ای و شغلی اتفاق بیفتد. و اگر فرصت آزادانه‌ای در اختیارشان قرار بگیرد ازش استقبال می‌کنند و در جستجوی بهروزی خودشان و تیم‌شان می‌روند.»این جملات مرا یاد بیانیه استقلال آمریکا انداخت: «ما این حقایق را بدیهی می‌دانیم که همه انسان‌ها برابر آفریده شده‌اند و برخی حقوق غیرقابل انکار توسط پروردگار به آن‌ها اعطا شده است، از جمله این موارد حق زندگی، آزادی و جستجوی خوشبختی است.»خب به نظر می‌رسد که خیلی‌ها با این گزاره‌های انتزاعی موافق هستند. اما چه می‌شود که در خیلی از تیم‌ها این اتفاق شکوهمند رخ نمی‌دهد و هم مدیران از بازدهی تیم ناراضی هستند و هم اعضای تیم دل‌بستگی به حرفه‌شان ندارند و احتمالا فقط برای «حقوق آخر ماه» کار می‌کنند؟وقتی به تجربه تدریسم نگاه می‌کنم یک نقطه پررنگ درش می‌بینم: «اعتماد». بتوانی به اعضای تیم‌ت اعتماد کنی و بهشان «آزادی عمل برای ابتکارات و خلاقیت‌های شخصی بدهی». بهشان اجازه بدهی هم‌دوش با تو «رسالت» تیم را بر عهده بگیرند و خودشان را بخشی از یک «ماموریت بزرگ‌تر» ببیند و از «تمام توان‌شان» برای پیش‌برد کارها استفاده کنند و درین مسیر برای خودشان «معنا» خلق کنند. بخش خوبی ازین «ساخت فضای مبتنی بر اعتماد» به دوش مدیر تیم است. اما خوب است کمی معنای اعتماد را باز کنیم:اعتمادیک تعریف ساده از اعتماد وجود دارد که از «برنه براون» یادش گرفته‌ام: «اعتماد، انتخاب کردن این مسیر است: خودت و چیزی که برای تو مهم است را در برابر اقدامات یک فرد دیگر آسیب‌پذیر بگذاری.»شکل ساده‌اش این می‌شود که من یک راز کوچک را با تو در میان می‌گذارم، تو می‌توانی از آن اطلاعات علیه من استفاده کنی، یعنی من به تو «اعتماد» کردم. یعنی من خودم را در مقابل تو «آسیب‌پذیر» کردم.یا این‌که اعتماد کردم و پولی به تو قرض دادم، تو می‌توانی آن را به من پس ندهی و من آسیب مالی خواهم دید.یا این‌که من بخشی از مسئولیت حرفه‌ای خودم را به تو واگذار کردم، اگر تو آن را به خوبی انجام ندهی، اعتبار کاری من زیر سوال می‌رود و من آسیب حرفه‌ای می‌بینم.و در نهایت «ما اعضای تیم به هم اعتماد کردیم و سوار یک قایق شدیم و همه بخشی از یک سرنوشت مشترکیم، اگر هر کسی کارش را خوب انجام ندهد قایق به مقصد نمی‌رسد و همه آسیب می‌بینیم»خانم برنه اعتماد را بیش‌تر هم می‌شکافد و هفت مولفه زیر را با اصطلاح BRAVING درش تشریح می‌کند:مرز گذاری، Boundaries: تعیین مرزها به این معناست که چه چیزی قابل قبول است است و چه چیزی خیر و چراقابلیت اطمینان،Reliability : شما آنچه را که می گویید انجام می دهید. در محل کار، این بدان معنی است که از شایستگی ها و محدودیت های خود آگاه باشید تا بیش از حد قول ندهید و بتوانید تعهدات خود را انجام دهید و اولویت های متضاد را متعادل کنید.مسئولیت پذیری، Accountability: شما اشتباهات خود را می‌پذیرید، عذرخواهی می‌کنید و برای اصلاح‌شان تلاش می‌کنید.محرم اسرار، Vault: شما اطلاعات یا تجربیاتی را که متعلق به شما نیست به اشتراک نمی‌گذارید. من باید بدانم که اعتماد من حفظ می شود و شما هیچ اطلاعات محرمانه در مورد افراد دیگر را با من به اشتراک نمی گذارید.شرافت، Integrity: انتخاب کردن شجاعت در مقابل راحتی؛ انتخاب آنچه که درست است به جای انتخاب‌های سرگرم کننده، سریع یا آسان؛ انجام دادن عملی ارزش‌ها در رفتار، نه فقط ابراز زبانی آنها.قضاوت نکردن، Non-Judgment: من می توانم آنچه را که نیاز دارم بخواهم و شما می توانید آنچه را که نیاز دارید بخواهید. ما می‌توانیم بدون قضاوت در مورد احساس خود صحبت کنیم.سخاوت‌مندی، Generosity : بسط سخاوتمندانه ترین تفسیر به نیت‌ها، گفتار و اعمال دیگران.ماموریتبا این تعاریف «اعتماد» یک هم‌بستگی عمیق با «دوست داشتن آدم‌ها»‌ دارد. پذیرش «انسان»‌ به عنوان یک «موجودی که حق اشتباه کردن و حق بخشیده شدن و پذیرفته شدن دارد.». ما محدودیت‌های خودمان و بقیه را به عنوان یک انسان درک می‌کنیم، خودمان را در مقابل هم آسیب‌پذیر می‌کنیم و با هم به پیش‌ می‌رویم، اما چرا؟«یووال نوح هراری» قشنگ تعریف می‌کند که «اگر یک شامپانزه و یک انسان را تنها در دو جزیره مختلف قرار دهیم، شانس زنده‌ماندن آن شامپانزه بسیار بیش‌تر از آن انسان است. اما اگر ده هزار شامپانزه و ده هزار انسان را در آن جزایر بگذاریم احتمال هم‌کاری سازنده انسان‌ها خیلی بیشتر است.توانایی «هم‌کاری سازنده درون جامعه‌ی بزرگ» انسان‌هاست که برتری اصلی آن‌ها را رقم می‌زند. و یووال معتقد است که دلیل اصلی آن «توانایی داستان‌گویی انسان‌هاست. آدم‌ها می‌توانند داستان‌های بزرگ بگویند و باور کنند. افراد می‌توانند با باور کردن داستان‌های بزرگ خودشان را بخشی از یک کل بزرگ‌تر ببیند و برای خودشان معنا و دل‌بستگی خلق کنند. یک داستان نمادین بسیار قدرت‌مند در زمانه‌ی ما جملات «رابرت اف کندی» درباره «سفر به کره‌ی ماه بود»: «ما انتخاب می‌کنیم که در این دهه به ماه برویم و کارهای دیگری انجام دهیم، نه به این دلیل که آن‌ها آسان هستند، بلکه به این دلیل که سخت هستند؛ چرا که این هدف به سازمان‌دهی و اندازه‌گیری بهترین توانایی‌ها و مهارت‌های ما کمک خواهد کرد.»«سفر به ماه» یک پروژه‌ی Grand Challenge Project بود، بدین معنا که «چالش سترگی» را با خود داشت که گذر از شان از پس یک نفر یا یک تیم برنمی‌آمد. بلکه تلاش جمعی هزاران نفر با تخصص‌ها و مهارت‌های مختلف را می‌طلبید. هم‌زمان یک پروژه‌ی Landmark Project هم بود، سنگ‌نشانی برای انجام یک کار نمادین، رفتن به ماه به خودی خود دستاورد خاص اقتصادی یا مهندسی نداشت، اما اگر این کار بزرگ به انجام می‌رسید، به این معنا بود که بسیاری از مسایل مختلف مهندسی و فنی مختلف را حل کرده‌ایم و بعدها سرریز این فناوری‌ها در صنایع مختلف به کار خواهد آمد.جالب است که پروژه «روبوکاپ» هم یک همچنین ماموریت ساده و بزرگی دارد: «در سال ۲۰۵۰ تیمی از ربات‌های فوتبالیست با تیم قهرمان انسان‌ها مسابقه خواهند داد و برنده خواهند شد». تیم‌های مختلفی در حیطه‌های الکترونیک، مکانیک، مواد، نرم‌افزار و هوش مصنوعی بایستی با هم هم‌کاری طولانی مدت کنند و مساله‌های بسیار مختلفی را حل کنند تا بتوانیم به این هدف برسیم.من براین باورم که «تکامل اعتماد تیمی» در بستری روی خواهد داد که «یک داستان بزرگ»، یک «بیانیه ماموریت ارزشمند» وجود داشته باشد که افراد بتوانند دوستش داشته باشند، آن‌قدر که خودشان را بخشی از آن داستان ببیند و بتوانند که برای محقق کردنش داوطلبانه دست به دامان هم‌کاری تیمی شوند و نفع شخصی‌شان را برای اهداف بزرگ‌تر تیم فداکارانه در اولویت دوم بگذارند.این بیانه ماموریت،‌ این «چشم انداز مشترک» بخش بسیار کلیدی در «معناداری» کار انسان‌هاست. بخش خوبی ازین مفاهیم را در کتاب کلاسیک «پنجمین فرمان» یاد گرفته‌ام.و همین‌طور یک دلیل در دوره «استارتاپ استنفورد» برای دلیل تاسیس استارتاپ شنیدم: «دنیا به من نیاز دارد تا این کار خاص را انجام بدهم». یعنی سه ویژگی مختلف: «دنیا به این کار نیاز دارد». کاری هست که برای انسان‌های زیادی «خلق ارزش» می‌کند. به «من» هم نیاز دارد. یعنی اولن من مهارت‌های لازم برای این کار را دارم و باعث شکوفایی من هم خواهد شد، دومن من جزو بهترین آدم‌ها برای حل کردن آن مساله خاص هستم و بقیه این مساله را با کیفیت لازم حل نکرده‌اند.حالا اگر من در سازمانی کار کنم که با این رویکرد تاسیس شده باشد حتمن می‌توانم داستانش را باور کنم و خودم را جزوی از یک جریان به سمت این ماموریت بدانم. با این توضیح که در خودم فرصتی برای «رشد و تعالی شخصی» در مسیر تحقق این ماموریت بدانم و همین‌طور توان‌مندی «تاثیرگذاری» درین مسیر را داشته باشم.اینجا مفهوم «Meaning» و «impact» بهم گره می‌خورد. چارچوب «ایکیگای» ژاپنی هم به همین مسئله می‌پردازد. بهترین جا برای بودن درین تقاطع چهار گانه است:«علاقه شخصی/معناداری»، «مهارت/رشد»، «نیاز جهان و سازمان/تاثیرگذاری» و «ایجاد درآمد/حقوق خوب».از دید من ما در زمانه‌ای زندگی می‌کنیم که خیلی فرصت خوبی برای داشتن این سازمان‌های بشردوستانه! داریم. جایی که آدم‌ها منزلت داشته باشند، احساس معنا و دلبستگی داشته باشند و در عین حال سازمان عمل‌گرا و نتیجه‌گرا باشد و دستاوردهای بزرگ و ارزشمندی داشته باشد. داشتن این سازمان‌ها شاید در اوایل انقلاب صنعتی کار دشواری بود. اما الان امکان پذیر است. کار خیلی دشواری هم نیست و اتفاقن با رعایت بعضی اصول کاملن قابل دست‌رسی است. و من رسالت خودم را کمک به ایجاد و نگه‌داری این سازمان‌ها می‌دانم. و پایه‌ای‌ترین اصلش را هم جاری کردن «اعتماد» در همه‌ی لایه‌های سازمان در همه‌ی عمرش می‌دانم. از تاسیس تا رشد و شکوفایی و استمرار همیشگی و به قول «سایمون سینک»، ماندن در «بازی بی‌نهایت».اما بیایید دوباره نگاه عمیق‌تری به مفهوم اعتماد بکنیم. اعتماد به دیگری چگونه تکامل پیدا می‌کند و گلوگاه اصلی‌ش چیست؟دوراهی اعتمادقبیله‌ای کوچک و اولیه را تصور کنید که مردانش بایستی برای تهیه آذوقه خانواده‌شان به شکار بروند. این مردان دو راه پیش روی خود دارند: شکار گوزن یا شکار خرگوش.بدین شکل که راه زیباتر این است که همه با هم هم‌کاری کنند، رد پای گوزنی را دنبال کنند، گوزن را محاصره کنند و شکارش کنند و به داخل قبیله بیاورند. گوزن چاق و چله است و شب هنگام ضیافتی با همه‌ی اعضای قبیله برگزار می‌شود، دور آتش می‌خوانند و می‌رقصند و غذای یک هفته قبیله را تامین می‌کنند.اما شکار گوزن سخت است، همه اعضا باید با هم هم‌کاری کنند، پیدا کردن گوزن و محاصره‌ش ممکن است ساعت‌ها طول بکشد، در ضمن اگر حتا یک نفر این وسط غفلت کند، گوزن از مسیر همو راه گریز را می‌یابد و از دست می‌رود و شب هنگام همه اعضا باید سرافکنده نزد خانواده برگردند و گرسنه بمانند. درین میان ممکن است خرگوش‌های کوچکی هم در آن حوالی پدیدار شود، حالا کار سخت‌تر است، هر مرد قبیله یک دوراهی در پیش دارد که آیا به جمع وفادار باقی بماند و احتمالن جایزه بزرگ گوزن را با هم دریافت کنند، یا این که به منفعت کوتاه مدت خودش فکر کند و در پی شکار خرگوش برود و فقط خانواده خودش را برای یک شب سیر کند؟سوال مهمی که هر مردی باید پاسخ دهد که آیا بقیه به جمع وفادار می‌مانند؟ اگر اعتماد بین اعضا کم باشد، هر فردی احتمال این را می‌دهد که یک نفر دیگر دنبال آن خرگوش می‌رود و آن وقت نه تنها گوزن را از دست داده‌اند، بلکه خودش آن خرگوش کوچک را هم از دست داده است!این مساله کلاسیک Trust Dilemma است که «ژاک روسو» آن را بیان کرده است و به شکل مدرن‌ترش در بازی زیبای Evolution Of Trust به تصویر کشیده شده است که به همه‌ی شما توصیه می‌کنم حتمن تجربه‌ش کنید. توصیه‌های انتهای بازی این‌ها هستند:۱- به بازی اعتماد به شکل بلندمدت نگاه کنید و سعی کنید زیاد تمرین‌ش کنید: افراد قبیله با هم وقت بگذرانید، از خانواده‌های هم باخبر باشید، در جاهای کوچک‌تر و کم‌ریسک‌تر تمرین کار تیمی کنید. ۲- سعی کنید منفعت حالت برد-برد را افزایش دهید: دنبال یک هدف-گوزن بزرگ بروید. سعی کنید روش‌هایی برای ذخیره گوشت بکنید تا در زمستان‌های سخت بیمه‌ای برای شکار باشد، به هم قرض دهید. ۳- تلاش بسیاری برای شفاف کردن «ماموریت» و «ارتباطات» بین اعضا کنید: داستان‌سرایی کنید، اسطوره بسازید و در همه مناسک‌ها تکرارش کنید!و در نهایت مهم‌ترین نکته‌ای که این بازی به ما می‌آموزد: «اینکه بازی و قوانین‌ش چه باشد، تعیین کننده نحوه بازی کردن بازی‌کنان است. به قول فیلسوفی «انسان حیوان ناتمام است» و ما تا حدی «محصول» محیط پیرامون‌مان هستیم. و این سازمان ماست که می‌تواند ما را طراحی کند. اگرچه باید به یاد داشته باشیم که در یک فضای انسانی هر کدام از ما «محیط» دیگری هستیم. پس در کوتاه مدت این بازی است که بازیکنان را تعریف می‌کند، اما در بلند مدت این ما بازیکنان هستیم که بازی را تعریف می‌کنیم.»قانون وارونهبازگردیم به این سوال که چه می‌شود که در خیلی از تیم‌ها این اتفاق شکوهمند اعتماد رخ نمی‌دهد؟ هم مدیران از بازدهی تیم ناراضی هستند و هم اعضای تیم دل‌بستگی به حرفه‌شان ندارند و احتمالا فقط برای «حقوق آخر ماه» کار می‌کنند؟بگذارید «قانون وارونه» را از کتاب «پادزهر» تعریف کنم. «الن واتس» فیلسوف این‌گونه می‌گوید که «در تمامی بافت‌های فردی و اجتماعی، از زندگی‌های شخصی ما گرفته تا سیاست‌های بزرگ اجتماعی، تلاش برای درست کردن تمام مشکل‌ها خود بخش بزرگی از مشکل است». «وقتی سعی می‌کنی روی سطح آب باقی بمانی غرق می‌شوی. اما وقتی سعی می‌کنی غرق شوی، شناور باقی می‌مانی».بیان دیگرش را درباره شادی، فیلسوف «جان استوارت میل» می‌گوید: «از خود بپرس شاد هستی؟ و با این پرسش شادی تو پایان می‌پذیرد». یا همان مثال معروف «داستایوسکی» که «تلاش کن خرس قطبی سفید را در ذهنت مجسم نکنی! و بعد می‌بینی تصویر لعنتی این حیوان رهایت نمی‌کند و لحظه لحظه وارد ذهنت می‌شود. »نتیجه‌گیری این کتاب این است که «اغلب اوقات تلاش برای رسیدن به شادی دقیقا همان چیزی است که سبب افسردگی ما می‌شود. و تلاش مستمر ما برای حذف چیزهای منفی (نبود امنیت، ناپایداری، شکست یا اندوه) است که باعث می‌شود احساس ناامنی، اضطراب، بی‌ثباتی و اندوه به ما دست دهد. ظاهرا برای این‌که واقعا شاد باشیم باید احساسات منفی را با میل و رغبت بپذیریم یا حداقل یاد بگیری از آن‌ها فرار نکنیم»(یک خاطره جالب از دوران اوایل اپلیکیشن بله یادم آمد که نقل کنم: یک میکروسرویس بکند داشتیم که دچار کندی شده بود، برای این‌که علت‌ش را بفهمیم کمی لایه‌های مانیتورینگ بهش اضافه کردیم و اما دلیلش پیدا نشد، باز بیشتر کاوش کردیم و اما عیبی درش نیافتیم، اما مشکل هم‌چنان بود و بزرگ‌تر هم شده بود تا حدی که بعضی وقت‌ها از کار می‌افتاد. تهش در یک تلاش ناامیدانه همه‌ی مانیتورینگ‌ها و لاگ‌ها و تریسنگ‌ها را غیرفعال کردیم و هورا! سرویس به حالت عمل‌کرد صحیح و بدون تاخیر خودش بازگشت! علت اصلی مشکلات، زیاد بودن همین «ریزنگری‌»ها برای کشف مشکل بود! )باری، عمیق‌ترین جمله‌ی درین رابطه را از «نیچه» می‌توان نقل کرد: «اگر دیری در مغاکی چشم بدوزی، آن مغاک نیز در تو چشم می‌دوزد». بله، من هم درک می‌کنم که سازمان‌ها عاشق بالا بردن بهره‌وری عمل‌کرد- Performance هستند، اما همین «عشق» بزرگ‌ترین دام است.سازمان‌ها دو روش استاندارد برای این کار دارند:۱- مشوق‌های مادی فردی (حقوق و مزایای اضافه‌کاری و …) ۲- نظارت دقیق بر انجام کارها، و سعی بر داشتن متریک برای همه چیزهای ممکنو همین دو روش «چماق و هویج» است که بزرگ‌ترین عامل از بین‌برنده ابتکار و خلاقیت فردی کارکنان سازمان است. و امکان مشارکت در «ایجاد معنا و دلبستگی به کار» را از بین می‌برد. چیزهایی مثل «تعداد خط کد نوشته شده، تعداد فیچر ایجاد شده، تعداد استوری پوینت تمام شده، تعداد آبجکتیوهای پاس شده در اوکی‌آر، …» همه می‌توانند تلاش‌هایی برای تضعیف مفهوم اعتماد و آزادی عمل فردی باشند.درین رویکرد شما می‌توانید همه را مجبور کنید که استوری پوینت‌های بیش‌تری را به سرانجام برسانند، روی کاغذ سرعت «اندازه‌گیری‌» شده بیش‌تر می‌شود. مزایا بر اساس این سرعت پرداخت می‌شود و شما «نبردها»ی زیادی را در مواجهه با کارمندان تنبل می‌برید، اما «جنگ» سازمان را می‌بازید. (یادی زنده کنیم از مرحوم «راب استارک» که همه نبردهای میدان را برد، اما جنگ تاج و تخت را باخت!) خلاقیت رنگ می‌بازد، فیچرهای بیهوده ایجاد می‌شود، ماموریت و معنا فراموش می‌شود و همه چیز در یک رقابت بیهوده «دان» کردن امتیازات و ارتقاهای حقوقی بر اساس آن خلاصه می‌شود.پیش‌گویی خود محقق شونده self-fulfilling prophecyدر ضمن بزرگ‌ترین مشکل این نگرش به کار این است که به شدت مستعد «پیش‌گویی خود محقق‌شونده»‌ است. حتمن بسیاری از شما خاطره‌ای از دوران تحصیل‌تان دارید که اگر از معلمی خوش‌تان می‌آمد پیش‌رفت‌تان در آن درس هم بهتر از بقیه دروس بود. صورت برعکس‌ش هم این است: در اولین روز کاری یک معلم، دانش‌آموزی دیرتر سر کلاس می‌آید. معلم با خودش می‌گوید که حتمن این دانش‌آموز بی‌نظم و از درس فراری‌ای است. باید بیش‌تر مواظبش باشم و کنترلش کنم. دانش‌آموز وقتی فشار کنترل معلم را می‌بیند دچار اضطراب می‌شود و علاقه‌ش به درس کم‌تر می‌شود. هم‌واره در یک حالت چمباتمه‌ی گریزان و ترسان از سرزنش معلم به سر می‌برد. تکالیفش را به درستی انجام نمی‌دهد و این خودش نظریه معلم را تایید می‌کند. معلم با خودش می‌گوید که بله، همان اول درست فهمیدم که این دانش‌آموز مشکل‌داری است. و این «دور باطل»، این چرخه‌ی اشتباه هم‌چنان ادامه پیدا می‌کند.این قضیه فراتر از کلاس درس در سازمان‌های ما هم به شدت متداول است. مدیران پیش‌گویی‌های اشتباه انجام می‌دهند و خود پیش‌گویی باعث محقق شدنش می‌شود. بیرون آمدن ازین دور باطل جز با تلاش زیاد مدیر میسر نیست و البته اکثر اوقات هم نجاتی اتفاق نمی‌افتد. کارمندان و البته سازمان قربانی این اشتباه هستند. و تشخیص‌ش هم بسیار دشوار است، چرا که داده‌ها و «متریک»ها نشان می‌دهند که کارمند مورد نظر کیفیت پایینی از خودش بروز می‌دهد!هم‌چنین من براین باورم که اکثریت افراد توانایی رشد بالایی دارند. خصوصن اگر محیط سازمان تشویق‌کننده این رشد باشد. البته که این ذهنیت باید از سمت خود افراد و در خانواده‌شان و در زمان تحصیل‌شان مورد تایید باشد. چیزی که «کارل دووک» از آن با عنوان «ذهنیت رشد» یاد می‌کند. آدم‌ها دو دسته‌اند: کسانی که ذهنیت «تبحر طلب» دارند، به «هوش» به چشم یک امر قابل ارتقا نگاه می‌کنند، از چالش‌ها استقبال می‌کنند و آن‌ها را به عنوان راهی برای تعالی می‌بینند. و به قول نیچه اعتقاد دارند که «آن چیزی که تو را نکشد قوی‌ترت می‌سازد».دسته دوم افرادی که ذهنیت «عملکرد گرا» دارند، به «هوش» به چشم یک امر «ثابت» می‌نگرند و از چالش‌ها گریزان هستند و شکست را برنمی‌تابند.نکته مهم این است که هر دوی این ذهنیت‌ها خیلی مستعد دچار شدن به «پیش‌گویی خود محقق‌شونده» هستند. «ذهنیت رشد» به «دور مطلوب» منجر می‌شود و «ذهنیت ثابت» به «دور باطل». اگر کسی با ذهنیت ثابت امتحان ریاضی‌ش را خراب کند احتمالن با خودش می‌گوید «معلوم است که من استعدادی در ریاضی ندارم»، علاقه‌ش کم‌تر می‌شود، تلاش کم‌تری می‌کند و وقتی در امتحان بعدی هم نمره مطلوبی نمی‌آورد نظریه‌ش تایید می‌شود!همه‌ی این گفته‌ها به این معنی نیست که من مخالف «ارزیابی عمل‌کرد» هستم. بلکه من مخالف «عدم اعتماد به کارکنان خط مقدم»، از بین بردن «آزادی عمل و ابتکار فردی» و کشتن «معنا و دل‌بستگی» به کار هستم.حالا راه‌حل مصالحه بین «ارزیابی عمل‌کرد» و «معنادار کردن» کارکنان چیست؟ چگونه تیمی داشته باشیم که اعضای خوش‌حال و بهروزی داشته باشند و در عین حال «دستاوردهای تیمی»شان هم قابل توجه باشد؟این‌ها را در بخش دوم نوشته می‌نویسم: کار تیمی در مهندسی نرم‌افزار - بخش دوم - ویرگول (virgool.io) Hossein Ansari Hossein Ansari Sat, 27 Apr 2024 17:24:37 +0330 https://virgool.io/baleacademy/stale-code-cku7dysmp6j6 بالغ-بالغ یا کودک-والد؟آیا روان‌شناسی به کار برنامه‌نویسی هم می‌آید؟ من که نان خانه‌ام را همین‌جور به دست می‌آوردم. باری چندی پیش نشستیم و یکی دو قصه تعریف کردیم و دو سه فحش به عدم درک کار تیمی دادیم و قول دادیم که شبی دیگر بیاییم و از الگوهای فنی برای کمک به رابطه‌های بالغ-بالغ بگوییم.حالا آمدیم که درباره «کدِ بیات» حرف بزنیم. کد ِبیات چیست؟ کدی که از زمان «بهترین تاریخ مصرف‌»ش گذشته باشد. یعنی بیش‌تر از ۲۴ ساعت از زمان نوشته شدنش توسط برنامه‌نویس گذشته باشد و هنوز در برنچ اصلی Master ادغام نشده باشد!کد بیات بخشی از چرخه است. یک گام بعدش «مستر بیات» است. Master بیات چیست؟ برنچ اصلی که ۲۴ ساعت از آخرین تغییرش گذشته باشد و هنوز آرتیفکت بیلدشده‌ش در جایی پابلیش نشده باشد!و در آخر «نسخه‌ بیات» را داریم. نسخه‌ای که ۲۴ ساعت از ساخت آرتیفیکت و احتمالا دیپلوی شدنش گذشته است ولی به مشتریان و کاربران «دلیور» نشده باشد.همه‌ این‌ها در همان چرخه توسعه محصول Lean هستند. ‌می‌خواهیم بدانیم به قول خارجی‌ها From Idea to Cash چقدر طول می‌کشد؟ چقدر تند تند می‌توانیم چرخه Build-Measure-Learn را طی کنیم؟خب از قصه دور نشویم. «کد بیات» چیست و چرا؟ در پست پیش درباره قصه‌ی «مدل برنچینگ گیت‌هاب طور» صحبت کرده بودیم. این که چقدر «نسخه دادن»‌ را خون‌بار می‌کند.گفتیم که بعضاً ناگزیریم که همین مدل را پیش برویم. اما اگر یک «تیم» کوچک و چابک هستیم راه‌های به‌تری برای رستگاری وجود دارد.یک پترن خوب و توصیه‌شده این است: «Trunk Based Development». یا به طور خلاصه T‌BD.حرف حساب تی‌بی‌دی چیست؟ «فساد کد بیات بدترین فساد ممکن است. هزینه‌ش برای تیم خیلی بیش‌تر از هر چیز دیگر است. هر کدام از اعضای تیم که کدی برای خودش نوشت باید در سریع‌ترین زمان ممکن آن‌ها را در برنچ اصلی ادغام کند. یعنی ترجیحن زیر دو ساعت این کار را بکند. و تلاشش را بکند که هیچ Long Lived Branchی با عمر بیش‌تر از یک روز نداشته باشد.در تیم‌های کوچک دو سه نفره حتی می‌شود هیچ برنچی نداشت و همه چیز را به سادگی در همان برنچ اصلی نوشت. در تیم‌های بزرگ‌تر حالا اشکالی ندارد Short Lived Branch با عمر چند ساعت داشته باشیم»عوض کردن چرخ‌های ماشین در حال حرکتاین کار طبعاً هزینه‌هایی دارد. اما مدعا این است که در نهایت هزینه‌ش برای تیم کم‌تر است. و سود خوبی نصیب تیم می‌کند. مهم‌ترین مزایا چیستند؟ما همیشه یک ماشین در حال حرکت داریم! یعنی هر لحظه که بخواهیم می‌توانیم از برنچ اصلی یک نسخه بدهیم. لازم نیست ماشین توسعه‌ی کد را متوقف کنیم و درگیر کانفلیکت‌های سینتکسی گیت و ناسازگاری‌های بعدش در هنگام مرج‌های بزرگ شویم.اگر دعوایی بین کدهای اعضای تیم وجود دارد خیلی سریع آشکار می‌شود. این شاید مهم‌ترین مزیت این کار باشد! Fail Fast, Fail Often. لازم نیست دو هفته کد بنویسیم و بعد بفهمیم یکی همان حین معماری آن کلاسی که ازش استفاده می‌کردیم را عوض کرده است!امنیت روانی کاذب و اشتباه اعضای تیم را ازشان می‌گیرد. نمی‌توانند به غار تنهایی‌شان بروند و بگویند وظیفه‌ی ما نوشتن همین تسک خاص است. و مسئولیت درست کردن نسخه و انتشارش با بقیه و مدیر تیم و مدیر محصول و این‌هاست. این رفتار کودک-والد را کنار می‌گذارند و مسئولیت مشترک محصول را به عهده می‌گیرند و بالغ-بالغ رفتار می‌کنند.خب مخاطب این نوشته‌ها لزومن فقط برنامه‌نویسان نیستند. اتفاقاً من برای مدیران تیم و مدیران محصول می‌نویسم.این‌‌ها را اگر به برنامه‌نویسان خودتان بگویید یحتمل فحش‌های قابل پیش‌بینی می‌دهند. که این ادغام زود کدهای نیمه‌تمام هزار تا باگ درست می‌کند و کیفیت کد را کاهش می‌دهد و اصلاً مانع رلیز می‌شود.منتها یک سری راه‌کار فنی ساده برای پیمایش درست و کم‌هزینه‌ این مسیر وجود دارد که در پست‌های بعد درباره‌ش صحبت می‌کنیم. می‌گوییم که چطور کدهای نیمه‌کاره را در برنچ اصلی ادغام کنیم. از روی برنچ اصلی نسخه بدهیم ولی کاربران را اذیت نکنیم! Hossein Ansari Hossein Ansari Sat, 12 Dec 2020 08:20:18 +0330 https://virgool.io/baleacademy/corona-and-dinosaurs-xflacj0fbvpw بزرگ بود و از اهالی دیروز بود!وقتی هفت سالم بود، دلم می‌خواست فیگور عروسکی دایناسورها را داشته باشم؛ اما خب اسباب‌بازی گرانی بود و برایم نمی‌خریدند. الان ۳۴ساله هستم و باز هم دلم می‌خواهدشان؛ اما خب اسباب‌بازی خیلی گرانی است و برایم نمی‌خرم. :) بعضی چیزها عوض نمی‌شوند!اما بعضی چیزها هم خیلی عوض می‌شوند، مثلن همین دایناسورهای عزیز. حدود هفتاد میلیون سال قوی‌ترین و غالب‌ترین گونه‌ی جانوری زمین بودند. نقطه‌ی قوت اصلی‌شان «بزرگی»شان بود. مثلن آمفی‌کوئلیاس فراگیلیموس از اهالی آرژانتین را داشتیم با قد افراشته‌ی پانزده‌متری!منتها و منتها همین نقطه‌ی قوت بلای جانشان شد. دری به تخته خورد و شهاب‌سنگی به زمین افتاد و دود فراوانی همه‌ی آسمان را در بر گرفت و نور خورشید از زمین و گیاهان دریغ شد و بخشی از زنجیره‌ی غذایی دچار کاهش درخور ملاحظه‌ای شد. بعضی پرندگان و پستانداران کوچک انطباق پیدا کردند و نجات یافتند؛ اما گونه‌های «بزرگ» بالای زنجیره‌ی غذایی از گرسنگی تلف شدند!سمیناهارتازگی‌ها با اکراه در جلسه‌ی یک سازمان دولتی حضور یافتم، در اتاق سمیناهار مجهز ساختمانی دوازده‌طبقه با ارتفاع ۳۶ متر. جلسه طبق معمول بسیار کم‌فایده بود. یک دلیلش این بود که اعضا در خود جلسه با موضوع مواجه شده بودند و گیج می‌زدند. کلن زیاد بودن منابع در سازمان نهادینه شده بود. ظاهرن هم وقت آدم‌ها زیاد بود و هم تجهیزات.متاسفانه سازمان (دایناسور) ما هنوز نمی‌دانست که شهاب‌سنگ کرونا به زمین خورده و دودش هم آسمان را فرا گرفته است. فرض می‌کرد که انگار همه‌چیز شبیه قبل است و فقط باید دم در تب مراجعان را بسنجد.اما اگر بخواهیم که خلاف دایناسورها زنده بمانیم، باید هرچه زودتر «انطباق» پیدا کنیم! شاید می‌شد کم‌کاری‌های قبلی را با جثه‌ی بزرگ و منابع زیاد، اندکی لاپوشانی کرد اما الان انعطاف‌پذیری و استفاده‌ی مؤثر از منابع فقط یک انتخاب بهتر نیست، بلکه یک ضرورت است.حداقل تلاش ما باید این باشد که برای جلسه‌های ترجیحن مجازی هماهنگی گروهی و آمادگی قبلی داشته باشیم.تیمباری اثرات شهاب‌سنگ کرونا فقط محدود به همین بهینه‌سازی‌های ساده نیست! بلکه باید بدانیم که نظم جدیدی در جهان در حال شکل‌گیری است و شکاف بین سازمان‌ها به‌شدت افزایش پیدا خواهد کرد.و چه کسانی برندگان دوران جدید هستند؟ «تیم‌»ها!«تیم‌»ها برنده می‌شوند و «منزوی»ها می‌بازند.سازمان‌های تشکیل‌شده از تیم‌ها باقی می‌مانند؛ چراکه انعطاف‌پذیری و همکاری مؤثر در شرایط دشوار را تمرین کرده‌اند. این تیم‌ها پر از خارپشت‌‌های بالغ‌ـ‌بالغ‌اند. به‌خاطر هدف مشترک سختی تحمل تیغ‌های هم را می‌پذیرند، متعهدانه نزدیک هم می‌مانند، باعث دلگرمی یکدیگر می‌شوند و هم‌افزایی ایجاد می‌کنند.و سازمان‌های پر از افراد منفرد به‌سادگی محو خواهند شد. به‌آرامی دایناسورها، سازمان‌ها، شرکت‌ها و کشورهای کُند و فربه از بقیه عقب خواهند ماند و خواهند باخت و منقرض خواهند شد! Hossein Ansari Hossein Ansari Wed, 03 Jun 2020 19:59:04 +0430 https://virgool.io/baleacademy/%D8%B9%D8%B2%DB%8C%D8%B2%D9%85-%DA%A9%D8%AC%D8%A7%DB%8C%DB%8C-rmlc7mfkuavt جستاری درباره رفتارهای «والد-والد» در کار تیمی توسعه‌ی نرم‌افزار فرایند توسعۀ نرم‌افزار وجوه مختلفی دارد: «پیچیدگی ذاتی»، «نیازمندی‌های متنوع و متغیر» و شاید مهم‌تر از همه جنبۀ‌ «فناورانۀ» مهمی دارد!اما من می‌گویم آن ادعای «شاید مهم‌تر از همه» بیخود است! قطعاً وجهۀ «انسانی» توسعۀ نرم‌افزار مهم‌ترین بخش فرایند است. چیزی که موفقیت و شکست هر نرم‌افزاری را تعیین می‌کند!الگویی تکرارشونده در زندگی روزمرۀ همۀ ما آدم‌های جایزالخطا «نظریۀ بازی‌»هاست. در اصطلاح علم «روان‌شناسی» عرض می‌کنم: «والد، بالغ و کودک درون». همه‌مان خیلی دوست داریم نقش «والد» کنترل‌کننده را به‌عهده بگیریم! نه که لزوماً دستور بدهیم؛ اما این دو قصۀ آشنا و کاملاً مشابه به‌نظرم مصداق این بازی است:قصۀ الفتیم‌های کامپوننتی: روزهای اول «بله» این‌طور بود. حدود هفت نفر برنامه‌نویس داشتیم که به سه تیم تقسیم شده بودند: «سرور»، «اندروید» و «آی‌او‌اس».یک تیم دو نفرۀ «سیس‌ادمین» هم داشتیم. روزهای خوش‌حالی بود. هر فردی با متخصصان رشتۀ خودش همکار بود و از آن‌ها چیز یاد می‌گرفت و کارها را پیش‌ می‌برد.یک نوع حس «امنیت روانی» و «کنترل مطلوب شرایط» در همه وجود داشت!قصۀ بمدل گیت‌فلوی گیت‌هاب‌طور: باز هم در روزهای اول «بله» این‌جور بود که برای هر کاری، برنچی برای خودمان بسازیم و مدت نسبتاً طولانی (از دو تا ده روز) با آن سروکله بزنیم و بعد از رضایت نسبی با برنچ اصلی (مستر) ادغامش کنیم! در طی آن دوره متغیرهای بیرونی ما را اذیت نمی‌کرد و مشغول کارمان بودیم و پیش می‌بردیمش.یک نوع حس «امنیت روانی» و «کنترل مطلوب شرایط» در همه وجود داشت!مختصر بگویم: جفتشان بیخود هستند! جفتشان دشمن Continuous Delivery هستند. جفتشان مانع همکاری «بالغ‌بالغ» و «بهره‌ور» و البته «دشوار» کار تیمی هستند، تیمی که هدفی مشخص دارد. افراد با نقش‌های مشخص و متفاوت با همکاری هم دنبال به‌نتیجه‌رساندن «هدف مشترک تیم» هستند؛ نه اینکه فقط به‌دنبال خواسته‌ها و آرامش شخصی خودشان باشند.مشکلات قصۀ الفمساله Sub Optimization شدید! ایجاد سیلوهای سفت و سخت. نیازمند مدیر پروژه‌ با کفش‌های آهنین و معمولاً خسته و غرغرو! سربارهای Dependency Management و...مثلاً «بله» می‌خواست ویژگی «لایک» پیام را اضافه کند. تیم «سرور» کار را با انرژی زیاد شروع می‌کرد. وقتی نوبت هم‌کاری تیم «اندروید» بود، معمولاً تیم اندروید سرش به کار دیگری گرم بود. تیم «سرور» می‌رفت دنبال کار دیگری. تیم اندروید کار قبلی‌اش تمام می‌شد و می‌آمد سراغ «لایک». باگی وجود داشت که تیم سرور باید حلش می‌کرد. اما الان تیم «سرور» سرش جای دیگری گرم بود. قس‌علی‌هذا! تحویل ویژگی «لایک» حدود سه ماه طول می‌کشید! درحالی‌که شاید فقط کار یک هفتۀ همه بود.مشکلات قصۀ ب «درد و خون‌ریزی» زیاد هنگام «انتشار نسخه». بعضی وقت‌ها این درد همان زمان merge هم پیش می‌آید. خصوصاً در شرایطی که بیشتر از سه نفر روی بخش‌های مشترک کد بنویسند؛ اما خب مشکل اصلی زمان انتشار است.مثلاً آخر ماه می‌خواهیم رلیز کنیم. دو نفر برنامه‌نویس اندروید ما تا هفتۀ آخر روی برنچ لوکال خودشان به‌شدت کار می‌کنند. باگ‌ها را برطرف می‌کنند و نهایتاً کد را مرج می‌کنند. گاهی ادغام هم کمی دشواری دارد؛ اما فرضاً با تلاش تحسین‌برانگیزی حاصل حدود یک ماه کار در برنچ اصلی ادغام می‌شود. تبریک! یک موفقیت شخصی دیگر! اما مشکلات تازه شروع می‌شود. آدم‌ها در طول ماه بدون اطلاع هم تغییراتی داده‌اند که «ناهمخوان» است. هر دو تا فیچری که قبلاً روی کامپیوتر خودشان خیلی خوب کار می‌کرد، دیگر به‌درستی کار نمی‌کند! دوباره وارد فرایند دردناک «دیباگ» می‌شویم، سخت و دشوار! بعد از دو روز می‌فهمیم که آن یکی برنامه‌نویس «شمای دیتابیس» را دست‌کاری کرده بوده است و ما خبر نداشته‌ایم و ازین قبیل مشکلات!هر انتشار تبدیل به کاری رنج‌آور و دشوار می‌شود! گاهی هم برای حلش فرایندهای احمقانۀ دیگری به‌وجود می‌آید: از این به بعد فلان ماژول فقط کار آقای فلان است و فلان بخش کد را فقط خانم فلان می‌تواند عوض کند و... (البته توجه داشته باشیم که این مدل برای مشارکت افراد خارج تیم در پروژه‌های متن‌باز ناگزیر است.)خب، حالا چه کنیم؟ از بازی روانی «والد‌والد» چطور بیرون بیاییم؟ و «بالغ‌بالغ» رفتار کنیم؟ از چه الگوی فنی‌ای برای حل مشکلاتمان بهره بگیریم؟ در قسمت‌های بعدی به این موضوع می‌پردازم. Hossein Ansari Hossein Ansari Sat, 07 Mar 2020 11:07:24 +0330