https://virgool.io/feed/@keyhan.asghari هم‌بنیان‌گذار دیوار و معاون محصول در بلد fa 2026-06-21 11:49:20 https://files.virgool.io/upload/users/33937/avatar/peMW2A.png?height=120&width=120 https://virgool.io/@keyhan.asghari https://virgool.io/@keyhan.asghari/%D8%B3%D8%A7%D8%AE%D8%AA%D8%A7%D8%B1-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86-%D8%A2%D8%AF%D9%85%D9%87%D8%A7-%D8%B1%D8%B4%D8%AF-%D8%AE%D9%84%D9%82-%D8%A7%D8%B1%D8%B2%D8%B4-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-fek6njnawnp4 اگه قسمت اول این نوشته رو نخوندید، لطفا قبلش اون رو بخونید.تو قسمت قبلی در مورد پیچیده بودن یه سازمان گفتیم و یه مقدار در مورد اینکه ساختار سازمانی مناسب برای هر سازمان به چیا بستگی داره صحبت کردیم. بعد یه کم به ویژگی‌ها و مدل کارکردن با آدم‌های تخصص‌گرا و آچارفرانسه‌ها پرداختیم و در انتها هم یه مقدار در مورد اینکه تیم و سازمان چرا باید لیدرهای غیررسمی داشته باشه و چرا باید عناوین شغلی آدم‌ها گسترده باشه گفتیم. این قسمت، ادامهٔ داستان رو می‌ریم جلو.یه عکس الکی دیگه در مورد کار و زمان و برنامه‌ریزی و اینا. من خودم جایی از این عکسا ببینم ادامه مطلب رو نمی‌خونم.مرز تیم‌هایه جاهایی تیم‌ها ممکنه مرز مشخصی نداشته باشن توی سازمان. هم ممکنه آدم‌هایی باشن که معلوم نیست دقیقا عضو کدوم تیم‌هان، هم کارهایی باشه که معلوم نیس کدوم تیم مسئولشه. هر کدوم از این دو حالت رو که دیدید بهتره دست به کار بشید و به عنوان مدیر تیم سعی‌تون رو بکنید که مرز‌ها مشخص‌تر بشه. تیم بودن و تلاش کردن برای هدف تیم،‌ زمانی معنی داره که آدم‌ها خودشون رو عضوش بدونن و تعلق خاطر داشته باشن بهش. همچنین، مرز‌بندی باید جوری باشه که کارها هم معلوم باشه مسئولشون و سر هر کاری اعضای یه تیمی بدونن که این کار ماس و ما باید درستش کنیم.یه چیزی هم که بعضی وقت‌ها پیش میاد و سخت هم هست حل کردنش، اینه که کسایی داشته باشین که عضو بیشتر از یه تیم باشن. اتفاقی که میوفته اینه که فرد معمولا خودش رو متعلق به هیچ کدوم نمی‌دونه و یه جایی اون وسط سرگردان می‌شه. البته منظور این نیست که هر نفر فقط با یه تیم کار داشته باشه. آدم‌ها توی تیم‌های مختلف می‌تونن (و خوبه که) علاوه بر هم‌تیمی‌های خود، به یاری کسای دیگه توی تیم‌های دیگه هم بشتابن و کمکشون بکنن. ولی نهایتا اگه خودشون رو عضو یکی از تیم‌ها بدونن بهتره.من خودم بدترین عملکردم تو دوره‌هایی بوده که عضو چندتا تیم بودم همزمان. گرچه خودم فکر می‌کردم دارم خوب عمل می‌کنم و هیچ مشکلی نیست. توی کوتاه‌مدت هم ممکنه که واقعا بتونین درمجموع ارزش خوبی خلق بکنین برای سازمان ولی آدم خیلی سریع میوفته تو سراشیبی و افت عملکرد.خودم فکر می‌کردم دارم خوب عمل می‌کنم و هیچ مشکلی نیست.سایز تیم‌هاتوی اسکرام می‌گن تعداد اعضای تیم باید ۷ به‌اضافه/منهای ۲ نفر باشه (چون از ۵ تا ۹ نفر علمی‌تر به نظر میاد اینجوری). جاهای دیگه و کسای دیگه هم حرفای دیگه‌ای می‌زنن. یه جا می‌گن ۸، یه جا می‌گن ۳ تا ۹، ولی اینا اصن مهم نیست و هیچ قانونی رو نباید گوش بدید تو این مقوله. دوتا چیز مهمه فقط: یکی اینکه تعداد تیم نباید از یه حدی کمتر باشه که تیم بودنه معنیش رو از دست بده و با کار کردن تنهایی فرقی نداشته باشه، و دومی هم اینکه از یه حدی هم نباید بیشتر باشه که کارهای تیم انقدر متنوع و گسترده بشه که دیگه آدم‌ها نتونن در راستای هدف مشترک کار کنن. کلا سایز مناسب برای تیم، به جنس کار تیم، محیطی که دارن توش کار می‌کنن و ارتباط‌شون با بقیه سازمان و به خود آدم‌هایی که توی تیم هستن خیلی ربط داره. یه جایی ممکنه تیم ۱۵ نفره خیلی خوب جواب بده و کارها خوب پیش برن و آدم‌ها هم خوشحال باشن، یه جا ولی تیم ۱۵ نفره خوبه تقسیم بشه به ۳ تا تیم ۵ نفره که کار بهتر پیش بره.عمر تیم‌هااحتمالا مراحل شکل‌گیری و ساخته‌شدن تیم‌ها رو قبلا بهش برخوردین. بروس تاکمن می‌گه که تیم‌ها ۵ مرحله رو پیش رو می‌ذارن تو عمرشون:Forming, Storming, Norming, Performing, Adjourningتوی مرحلهٔ Forming، تیم هنوز تازه داره شکل می‌گیره، آدم‌ها دنبال اینن که کی قراره چیکاره بشه و تیم قراره چیکار کنه و من باید چیکار کنم و چه انتظاری از من می‌ره و اینا. آدم‌ها هم خیلی نمی‌شناسن هم رو چون به احتمال زیاد کار نکردن باهم خیلی. تو مرحله بعدی ینی Storming، کم‌کم آدم‌ها شروع می‌کنن سوالات قسمت‌های قبلی رو جواب دادن. چون آدم‌های تیم تو این مرحله هنوز فضاهای ذهنی و تصورشون از تیم باهم خیلی فرق داره، ممکنه کلی باهم conflict بخورن (اگه نخورن عجیبه) و روی اهداف و کارها و کلی چیز دیگه بزنن تو سر و کله هم. نهایتا توی مرحله Norming، این دعواها می‌تونه تموم شده باشه و یه جورایی اعضا باهم متحد شده باشن و بدونن کلا قراره چیکار کنن. تو این مرحله‌س که دقیق‌تر می‌فهمن هر کسی قراره چیکار کنه و رهبر تیم کیه و وظایفش چیه. آروم آروم بهره‌وری تیم افزایش پیدا می‌کنه و کار شروع می‌کنه به جلو رفتن. اگه همه چی خوب پیش بره و آدم‌ها دوباره دعواهای جدید شروع نکنن (و برنگردن مرحله قبلی) تیم کم‌کم می‌ره تو مرحله بعدی که درخشان‌ترین مرحلهٔ تیمه، ینیز Performing. همون‌طور که از اسمش معلومه، این دوران، دورانیه که تیم دقیقا خودش رو پیدا کرده و ساخته و هرکی می‌دونه باید چیکار کنه و هدف‌ها و ساختار و مدل تصمیم‌گیری و ... مشخصه. مشکلات و بحث و جدل هم پیش میاد، ولی تیم بلده چجوری حلش کنه. تیم تو این دوره می‌تونه مثل تیراختور کار کنه و خروجی بده. ولی هر اومدنی رفتنی هم ممکنه داشته باشه. وقتی تیم به هدف‌هاش رسید، کارها رفته‌رفته به سرانجامشون رسیدن و ارزش‌هایی که قصد داشتیم خلق کنیم، خلق شدن، کم‌کم دیگه کار تیم تمومه و وارد مرحله Adjourning می‌شیم. تو این مرحله می‌تونیم کارها رو دیگه جمع و جور کنیم و اعضای تیم برن دنبال تیم‌ها و کارهای دیگه.دشمن رشد کردن تیم‌ها، دخالت از بیرون و اعمال تغییرات زیاده. درسته که تطبیق‌پذیری از ویژگی‌های خوبیه که تیم‌ها و آدم‌هاشون باید داشته باشن، ولی اینکه تیم‌ها نیاز داشته باشن بیشتر از حدی که باید، خودشون رو تطبیق بدن، کار رو براشون سخت می‌کنه. اگه دمای آب با سرعت کمی کم بشه، بلورهای یخی که تشکیل می‌گیره شکل منظم‌تر داره، ولی اگه سریع دما رو کم کنید، بلورها نامنظم می‌شن. شکل‌گیری تیم‌ها هم هیچ ربطی به بلورهای یخ نداره و کاملا یه موضوع جداس.توی سال ۹۸، ما توی بلد تغییرات خیلی زیادی توی تیم‌ها و ساختار سازمانی دادیم. بعضی تیم‌ها عمرشون به یه فصل هم نمی‌رسید و تا آدم‌ها بیان وارد مراحل توسعه تیم بشن، تیمه تموم شده بود و باید می‌رفتن سراغ انجام کارها توی تیم بعدی. هرچند روی کاغذ و در تئوری، تغییرات همیشه رو به جلو بوده، ولی در عمل باعث کلافه شدن آدم‌ها و کندتر انجام شدن بعضی کارها شد. البته این رو هم بگم که بچه‌ها خیلی خوب خودشون رو با شرایط وفق دادن و ترکوندن.در ادامه، به مدل چیدن تیم‌ها در سازمان می‌پردازیم.تیم‌های تخصص‌محور و تیم‌های محصول‌محورحالا مسئله اینه که چجوری سازمان رو به چندتا تیم بشکونیم. به صورت کلی دو تا راه برای این کار وجود داره. شکستن حول تخصص یا حول محصول و هدف بیزنسی. این دو در کتاب، functional و cross-functional گفته شده ولی من ترجمه درستی نتونستم پیدا کنم و یه ذره دست‌کاریش کردم. تیم تخصص‌محور یا functional تیمیه که آدم‌ها توش تخصص مشابه دارن. مثلا تیم اندروید یه محصول، یا تیم مهندسین داده توی یه محصول. آوردهٔ تیم‌های تخصص‌محور، بازده بالا و یادگیری بهتره. وقتی ۴ تا توسعه‌دهندهٔ اندروید کنار هم می‌شینن و باهم تشکیل یه تیم می‌دن و پیوسته باهم ارتباط دارند، طبیعتا چیزهای بیشتری از هم یاد می‌گیرن و از کار هم بیشتر خبر دارن. تیم محصول‌محور یا cross-functional تیمیه که آدم‌هاش حول برآورده کردن یه هدف بیزنسی، یا به سرانجام رسوندن یه زیرمحصول، یا کار روی رفع نیازهای یه نوع کاربر خاص دورهم جمع شده‌اند. در این حالت، تمرکز بیشتری روی رسوندن اون ارزش محصولی انجام می‌شه ولی خب ویژگی‌های تیم تخصص‌محور رو دیگه نداره.اگه بتونیم ارتباطات روزمره بین تیم‌ها و آدم‌ها رو یه جوری تحلیل کنیم، به این نتیجه خواهیم رسید که اکثر هماهنگی‌ها و صحبت‌ها حول محصول و ارزش محصولی و بیزنس شکل می‌گیره؛ تا حول تخصص. لذا چند نفر با تخصص مختلف که روی یه پروژه کار می‌کنند، نیاز به تعامل و ارتباط بیشتری باهم دارند، تا چند نفر با تخصص‌های مشابه که روی چند تا پروژه کار می‌کنند. پس به صورت کلی اگه بخوایم بگیم، اگه یه سازمان به تیم‌های محصول‌محور شکسته شده باشه، بهتر عمل می‌کنه. مثال تیم‌های بازار رو توی قسمت اول این نوشته زدم، مشکلی که در حالت تیم‌های تخصص‌محور وجود داره اینه که برای انجام هر کاری نیازه که کلی هماهنگی و ارتباط صورت بگیره در صورتی که توی تیم‌های محصول‌محور، چون آدم‌ها دارن روی یه چیز مشترک کار می‌کنن این هماهنگی‌ها خیلی کمتر و خلاصه‌تر و درون تیم شکل می‌گیره. ما زمانی که توی کافه‌بازار از سه تا تیم تخصص‌محور تشکیل شده بودیم، یادمه که وقتی داشتیم کارت هدیه بازار رو راه می‌نداختیم، نیازمند این بودیم که هم کلاینت بازار یه تغییراتی بکنه و امکان بازیابی و افزایش اعتبار با کارت هدیه بهش اضافه بشه، هم تیم پرداخت نیاز داشت یه کارهایی انجام بده حول این موضوع و هم تیم بک‌اند کافه‌بازار. یادمه که انجام این کار خیلی بیشتر از چیزی که فکر می‌کردیم طول کشید. دلیلش این بود که هر کدوم از این سه تا تیم گفته شده ایتریشن خودشون رو داشتند و کاره باید تعریف می‌شد و می‌رفت توی ایتریشن این سه تا تیم که لزوما باهم هماهنگ نبود. علاوه بر هماهنگ نبودن زمانی (که حالا شاید این رو می‌شد کاری کرد) اولویت تیم‌ها متفاوت بود. مثلا یکی از این سه تا تیم یه موضوع مهمی براش پیش اومده بود و نیاز بود که دو ایتریشن روش کار بکنه و این باعث می‌شد کل کار کارت هدیه بخوابه. بعد مشکل دیگه‌ای که پیش اومد این بود که وسط کار فهمیدیم یه چیزهایی رو باید تغییر بدیم و نیازمند این بود که این تغییره دوباره توی هر سه تا تیم اتفاق بیوفته و دوباره اجرای کار عقب افتاد. یه مشکل دیگه که به نظرم اصلی‌ترین مشکل تیم‌های تخصص‌محور می‌تونه باشه، این بود که هیچ کدوم از این تیم‌ها خودشون رو صاحب این کاره نمی‌دونستن. نه اینکه بگیم شل می‌گرفتن کار رو، مشکل این بود که این کار رو در راستای اهداف تیم‌ها نمی‌دونستن. در صورتی که اگه اون موقع ما یه تیم مثلا درآمد داشتیم، یکی از اهداف این تیم می‌تونست افزایش درآمد باشه و یه راهش هم این باشه که کارت هدیه رو توسعه بدن و کمکی بکنه به افزایش درآمد (کارت هدیه راهی بود برای اینکه کسایی که رمز اینترنتی ندارن و سختشونه، بتونن از خدمات بازار استفاده کنن). اینجوری اعضای این تیمه با پوست و استخون درک می‌کردن که چرا باید فیچر کارت هدیه رو بدیم (یا چرا نباید بدیم) و کار اندروید و بک‌اند و هماهنگی‌هاش هم داخل یه تیم انجام می‌شد و سریع‌تر می‌رفت جلو.ولی اگه انقد مسائل بدیهی و راحت بود، تیم‌های تخصص‌محور توی نسل‌های اولیه بشر در اثر انتخاب طبیعی منقرض شده بودن و الان موضوع بحث ما نبودن. در تیم‌های محصول‌محور هم مشکلاتی پیش میاد. فرض کنید ۲ نفر توسعه‌دهندهٔ اندروید داریم و دو تا تیم محصول‌محور. حالا می‌شه این ۲ نفر هر کدوم برن توی یه تیم محصولی و کارهای اون تیم رو انجام بدن، می‌شه هم این ۲ نفر باهم تشکیل یه تیم سومی رو بدن و روی کارهای اندرویدی اون دوتا تیم محصول کار بکنن. در حالت اول (که تیم تخصص‌محور نداریم) ارتباط بین این دو توسعه‌دهنده اندروید کم خواهد شد و انتقال دانش و تجربه خیلی کمتر از حالت دوم خواهد بود. ممکنه در حالت دوم بتونیم راحت‌تر نسخهٔ جدید اندرویدمون رو برهانیم (ریلیز بدیم) چون این دو بزرگوار از هم بیشتر خبر دارند و می‌دونن کدوم کار تا فلان موقع می‌رسه و کدوم نمی‌رسه. ساختار محصول‌محور نسبت به تخصص‌محور ایرادای دیگه هم داره. معمولا این اتفاق پیش میاد که توی ساختار محصول‌محور، یه سیستم‌های فنی‌ای بین چندتا تیم محصولی مشترکه و احتمال یتیم شدنش بیشتره. ینی اینکه کسی سیستم رو نرسه بهش، همه صرفا بخوان دنبال فیچر دادن روش باشن و بهبود‌های فنی روی اون سیستم برای کسی اولویت نباشه. در تیم‌های تخصص‌محور، نیاز به ارتباط و هماهنگی بیشتری بین تیم‌ها وجود داره نسبت به تیم‌های تخصص‌محورنهایتا اگه فرض کنیم سازمان از چندتا تیم محصول‌محور و چندتا تیم تخصص‌محور تشکیل شده، چندتا موضوع هست که خوبه حواسمون باشه:زمانی که یه functionality رو از تیم محصول‌محور خارج می‌کنیم و محول می‌کنیم به یه تیم تخصص‌محور (مثلا توسعهٔ اندروید یا طراحی UI فیچر‌های یه تیم محصول محور خارج ازش انجام می‌شه)، این تیم محصول‌محور باید یه اینترفیس یا یه نماینده توی اون تیم تخصص‌محور داشته باشه. ینی مثلا همهٔ تیم‌های محصول‌محور یه نماینده (نه لزوما اختصاصی) توی تیم تخصص‌محور داشته باشن.کسایی که عضو تیم‌های تخصص‌محور هستند، حواسشون باشه که هدف اصلی‌شون خلق ارزشه و به تیم‌های دیگه به چشم مشتری نگاه بکنن و در راستای برآورده کردن هدف اون‌ها تلاش بکنن. ارزیابی تیم‌های تخصص‌محور از نظر اینکه چقد دارن خوب کار می‌کنن و ارزش خلق می‌کنن رو تیم‌های محصول‌محور باید بدند. درواقع تیم محصول‌محور مشتری تیم تخصص‌محور باید باشه و خب طبیعتا باید نظر نهایی رو بتونه تیم محصول‌محور بده. اینجوری، اگه تیم تخصص‌محوری به بیراهه بره و از خلق ارزش برای بیزنس فاصله بگیره، زودتر خواهیم فهمید. یه تیم تخصص‌محور می‌تونه مجازی باشه. یعنی به جای اینکه اعضای تیم تشکیل یه تیم سفت و سخت رو بدن و به صورت فیزیکی هم کنار هم بشینن، تشکیل یه شبه‌تیم رو بدن و هر از گاهی دور هم جمع بشن و علاوه بر تبادل دانش، روی استاندارد‌های چیزهای مشترکی که بین‌شون دارن و فرآیند‌های مشترکشون و ... تصمیم بگیرن؛ ولی عضو یه تیم محصولی باشن در اصل. در کتاب به این ساختار‌ها می‌گه communities of practice. توی ساختار اسپاتیفای هم بهش می‌گن chapter.کلا در هر سازمانی، بسته به شرایط آدم‌ها و محصول و ... ممکنه که هر کدوم از این دو ساختار (و یا ترکیبی از این دو) انتخاب بهتری باشه و بهتر جواب بده. منتهی به صورت کلی، تصمیم‌های بهتر بیزنسی و محصولی، کمتر شدن اتلاف وقت و انرژی به خاطر هماهنگی‌ها، سرعت توسعه و دلیوری بیشتر، برنامه‌ریزی ساده‌تر، و تمرکز بیشتر روی رسوندن ارزش توی تیم‌های محصول‌محور بیشتره. در مقابل، هر جای بهینه بودن یه کاری خیلی موضوع مهمی شد، ممکنه تشکیل یه تیم تخصص‌محور حول اون موضوع کار خوبی باشه.در ادامه یه مقدار به حضور سلسله‌مراتب (hierarchy) در سازمان می‌پردازیم.سلسله‌مراتب رسمی و شبکه اطلاعات غیر رسمیبحث وجود سلسله‌مراتب در سازمان یا عدم وجودش خیلی فلسفیه و اینجا کاری باهاش نداریم. فرض رو می‌ذاریم اینکه یه حدی از سلسله‌مراتب باید باشه و البته یه مقدار هم بهش خواهیم پرداخت که چرا. خوبی سلسله‌مراتب اینه که کارها توی لایه‌های مختلف با انگیزه‌ها و ملاحظات خودش بررسی می‌شن و هرکی می‌تونه کار خودش رو بهتر انجام بده. مثلا توسعه‌دهندهٔ یه تیم، بیشتر تمرکزش رو به کاری که در دست داره اختصاص می‌ده و سعی می‌کنه اون رو خوب انجام بده. مدیرمحصول همون تیم، علاوه بر کارهای در دست تیم، به آیندهٔ نزدیک هم نگاه می‌کنه و احتمالا مدیرعامل اون سازمان، خیلی بیشتر با آینده ممکنه درگیر باشه نسبت به مدیرعامل. ولی سلسله‌مراتب و حتی کلی‌ترش، ساختار، دلیل وجودیش کاهش دادن ارتباطات و هماهنگی‌ها به حد لزومه و طبیعتا پتانسیل این رو داره که تهدیدی باشه به مشکلات ارتباطی و جاری شدن اطلاعات در سازمان. همون‌قدر که وجود سلسله‌مراتب می‌تونه با لایه لایه کردن دغادیغ (جمع مکسر دغدغه) و اختیارات، به بهتر پیش رفتن کارها کمک کنه، می‌تونه کار رو خراب کنه و باعث بشه اطلاعات و جریانش هم لایه لایه بشه. به باور نویسنده این کتاب، شبکه اطلاعات تو یه سازمان در کنار سلسله‌مراتب و موازی باهاش وجود داره. سلسله‌مراتب حالتی درخت‌وار داره و ۱ نفر مدیر n نفره و هر کدوم از اون n نفر هم ممکنه مدیر m نفر دیگه باشن. در حالی که شبکه اطلاعات، ساختار درختی نداره و همون‌طور که اسمش روشه، یه شبکه است.سلسله‌مراتب: خطوط نازک | شبکه اطلاعات: خطوط ضخیمشبکه اطلاعات غیررسمیه، به این معنی که نقش و وظیفه و اینایی نداره، ولی سلسله‌مراتب رسمیه. یه مثال، فرض کنید که تیم پرداخت بازار می‌خواد روی کارت هدیه کار بکنه. اصل این تصمیم و حساب کتابش و مدل توزیعش و عواقبش و اینا رو فرض کنیم مدیرعامل می‌گیره. بعد مدیر محصول جزئیات رو درمیاره و کار رو به قسمت‌های قابل اجرا تقسیم می‌کنه. بعد این کار توی ایتریشن تیم پرداخت مطرح می‌شه و قرار می‌شه که بچه‌های تیم انجامش بدن و نهایی که شد، اعلام بکنن که بازار همچین کاری کرده. چیزایی که گفته شد همه در مورد سلسله‌مراتب بود. حالا شبکه اطلاعات چیکار می‌کنه؟ بحث کارت هدیه رو یکی از توسعه‌دهنده‌های تیم می‌تونه به ذهنش رسیده باشه، بعد به مدیرعامل گفته باشه. بعد مدیرعامل رفته با مدیرمحصول و توسعه‌دهنده‌هاش یه جلسه گذاشته و صحبت کردن در موردش. در مورد قیمت‌هاش و اینکه چه مبلغ کارت‌هایی باید باشه یکی از توسعه‌دهنده‌های تیم یه ایده‌ای به ذهنش رسیده و با مدیر محصول مطرح کرده. مدیر محصول با مدیرعامل تو جلسه بعدیش رفته در موردش صحبت کرده و بعد قرار شده خود توسعه‌دهنده هم بهشون اضافه بشه و در موردش صحبت کنن. بعد سر اینکه ببینن کارت هدیه جاهای دیگه چقد استفاده‌ش سخته یا راحته، باهم رفتن و چندتا جا رو امتحان کردن و ... اینایی که گفتیم، شبکه اطلاعاته. اطلاعات در تیم و سازمان باید جریان داشته باشه و سلسله‌مراتب جلوش رو نگیره. تو همین مثال می‌تونید راحت تصور کنید که هر کدوم از نفرات توی سلسله‌مراتب می‌تونن جلوی جریان اطلاعات توی این شبکه رو بگیرن و کار رو خراب کنن. نتیجه‌ش اینه که تیمی که با دل و جون روی این فیچر محصولی قرار بود کار کنه، اصن خبر نداره چی شد که می‌خوایم کارت هدیه بدیم، چه جزئیاتی دیگه‌ای داره، بعدا می‌خوایم گسترشش بدیم یا داریم تست می‌کنیم، مطمئنیم داریم این کارو می‌کنیم یا نه و کلی سوال دیگه که جوابش برای تیم نامعلومه. خیلی فرق می‌کنه تیمی که قراره صرفا قسمت فنی کار رو انجام بده، از جوانب محصولی کار خبر داشته باشه یا نداشته باشه. نتیجه محصولی و حتی نتیجه فنی تولیدشده رو هم زیر و رو می‌تونه بکنه بودن یا نبودن جریان اطلاعات.مدیریت یه سازمان، باید از خداش باشه که اطلاعات به نرمی در شبکه جریان پیدا بکنه و لنگ سلسله‌مراتب نباشه و مستقل ازش کار کنه. جریان اطلاعات رو نه تنها نباید کنترل یا بلوکه کرد، بله باید بهش بها هم داد و تقویتش هم کرد.خود سلسله‌مراتب هم نباید از حدی که نیازه پیچیده‌تر باشه. وجود لایه‌های بیشتر از حد لازم در یه سازمان می‌تونه باعث بشه یه تعداد مدیر اون وسط‌ها باشن و از بیکاری جلوی کار کردن بقیه رو بگیرن. هر لایه مدیریتی باید دقیقا مشخص باشه که چه کاری داره می‌کنه و چه مسئله‌ای رو حل می‌کنه که لایه زیریش و بالاییش نمی‌تونه حل کنه یا بهتره حل نکنه و درگیرش نباشه. سخن آخردر قسمت پایانی این نوشته، به چندتا نکته و توصیه ریز ولی مهم هم می‌پردازیم و دیگه می‌بندیمش. به اعتقاد نویسنده، اکثر مشکلات موجود در پروژه‌های نرم‌افزاری، به خاطر ارتباط‌های نادرسته. (bad communications). واسه اینکه ارتباط‌های خوبی داشته باشیم، سه تا چیز لازمه، افراد سازمان اطلاعات کافی از سازمان داشته باشن، روابط خوب بین آدم‌ها برقرار باشه و آدم‌ها بازخورد مناسب رو بگیرن. برای اینکه اطلاعات کافی باشه، باید هرچی که می‌شه رو عمومی کنیم و در دسترس افراد سازمان بذاریم. حتی چیزایی که ممکنه فک کنید به درد کسی نمی‌خوره رم عمومی کنید و فکر اونش رو نکنید. هرچی بیشتر بهتر. کد‌ها، مستندات، استراتژی، فایل‌ها، طراحی‌ها، روند پیشرفت تیم‌ها، هرچی که می‌تونید و سازمان‌تون بلوغش رو داره که بدونه. یه کاری کنید چیزایی که عمومی می‌کنید، تو چشم هم باشن. مثلا اهداف سازمان، استراتژیش، نتایجی که تیم‌ها بهش می‌رسن و قله‌هایی که فتح می‌کنید. هرچی چیزها بیشتر تو چشم باشن، تاثیر بیشتری روی آدم‌ها می‌ذاره و آدم‌ها ناخودآگاه دنبال چیزای خوبی که می‌بینن می‌رن.نکته آخر هم اینکه تغییر، لازمه خیلی از اتفاقات خوبه و خیلی جاها هم موقع ایجاد یه تغییر مطمئن نیستیم اتفاق خوبی بیوفته یا اتفاق بدی. یه جاهایی برای رسیدن به یه نتیجه خوب، باید تغییری بدیم که در کوتاه‌مدت نتایج بدی داره ولی ناگزیره. یه جاهایی هم ممکنه نتیجه موردنظر از یه تغییر رو نگیریم و لازم باشه تغییر رو برگردونیم. چیزی که همهٔ این تغییرات رو برای همهٔ آدم‌های سازمان آسون‌تر می‌کنه و باعث می‌شه بشه چابک‌تر رو به جلو حرکت کرد، وفق‌پذیری (adaptability) آدم‌های سازمانه. اگه آدم‌ها وفق‌پذیر نباشن، به جای درگیر شدن با خود تغییر و بهتر اجرا کردنش، باید با اعضای تیم‌تون سر درست و غلط بودن تغییر سر و کله بزنید و به جای ارزیابی کردن نتایج یه تغییر، باید وقتتون رو صرف راضی کردن آدم‌های ناراضی‌ای بکنید که راضی نیستند از محدوده امن خودشون خارج بشن و صرفا می‌خوان تغییری اتفاق نیوفته. این مقاله و قسمت قبلیش، خلاصه و جمع‌وجورشدهٔ بخش‌هایی از فصل ۱۳ کتاب Management 3.0 نوشتهٔ Jurgen Appelo با اندکی تغییر و تفسیر است. این کتاب، کتابی بسیار زیبا و با ارزش است و خوندنش رو اکیدا به علاقه‌مندان توصیه می‌کنم. کیهان اصغری کیهان اصغری Fri, 10 Apr 2020 17:54:01 +0430 https://virgool.io/@keyhan.asghari/%D8%B3%D8%A7%D8%AE%D8%AA%D8%A7%D8%B1-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86-%D8%A2%D8%AF%D9%85%D9%87%D8%A7-%D8%B1%D8%B4%D8%AF-%D8%AE%D9%84%D9%82-%D8%A7%D8%B1%D8%B2%D8%B4-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-nsi2oowa6n5p بعضی‌هامون نظم دادن به چیزها و ساختار چیدن در اون‌ها رو دوست داریم. از مرتب کردن وسایل روی میز، تا چیدن کتاب‌هامون توی کتاب‌خونه با ترتیب مشخص، تا چیدن مواد غذایی توی طبقه‌های یخچال بر اساس نوع مواد غذایی. (البته این آخری رو مطمئن نیستم آدمای زیادی درگیرش باشن.)در مورد سازمان‌ها و شرکت‌ها هم، یه نوعی از نظم و ساختار باید وجود داشته باشه و فکر می‌کنم همه‌مون رو اینش توافق داریم. در این مقاله، در مورد ساختار سازمان و برخی جوانبش می‌پردازیم.یه عکس الکی از کار کردن و ایناچه ساختاری برای سازمان من مناسبه؟جلوتر خواهیم دید که هیچ ساختار سازمانی‌ای وجود نداره که برای همه جواب بده. چیزی که شرکت کافه‌بازار داره استفاده می‌کنه به احتمال زیاد توی بلد جواب نمی‌ده و چیزی که بلد داره ازش نتیجه می‌گیره احتمالا دیوار رو زمین بزنه. (حالا نه در این حد ولی نکته رو بگیرید دیگه) در این مقاله، ساختارهای سازمانی متداول رو بررسی نخواهیم کرد و هدف این نیست که از بین‌شون کدوم رو برای سازمان خودمون انتخاب کنیم. جلوتر به این نتیجه هم می‌رسیم که همچین کاری خیلی ممکن نیست و اگه یه زمانی مشاوری کسی اومد و ادعا کرد می‌تونه این کار رو براتون انجام بده و بره، به احتمال زیاد سر شما و حتی خودش کلاه گذاشته.مدلی که اینجا در موردش صحبت می‌کنیم و بازش می‌کنیم، به جای انتخاب ساختار، روی رشد دادن و ساختنش تاکید داره و معتقده که یه سازمان، یه سیستم پیچیده‌ است و نمی‌شه یه ساختاری از بیرون برداریم و بگیم این باشه و ساختار باید از درون خود سازمان بجوشه و دربیاد. مدیر همچین سیستمی، می‌تونه بسته به بلوغ و شرایط دیگهٔ سازمانش، فرمون رو بگیره دستش و به شکل‌گرفتن ساختار سازمانش جهت بده.یه شوخی بی‌مزه با ساختار سازمانی شرکت‌های بزرگ آی‌تی جهانمحیط، محصول، آدم‌ها و تعدادشونبرای موجودات زنده چه فرمی بهتر جواب می‌ده؟ ساختار بدن موجودات زنده چجوری باشه بهتره؟ دو تا موجود زنده رو در نظر بگیرید، عنکبوت و ستاره دریایی. می‌تونیم بگیم ساختار بدن عنکبوت بهتر از ستاره دریاییه یا برعکس؟ نمی‌شه گفت. ساختار بدن عنکبوت تو یه شرایط و محیطی بهتر جواب می‌ده، ستاره دریایی تو یه محیط‌های دیگه. ساختار سازمان هم مثل همینه (منظورم این نیست که بعضی ساختارها تو خشکی بهتر جواب می‌دن بعضیا تو دریا). بسته به فرهنگی که یه سازمان داره، تعداد آدم‌های سازمان و تخصص‌هاشون، محصولی که داره می‌سازه و سرویسی که داره می‌ده و کلی فاکتور دیگه، ساختار مناسب برای سازمان تعیین می‌شه. این فاکتورها به مرور زمان عوض هم می‌شن، مثلا تعداد نفرات یه سازمان بیشتر می‌شه یا محصولی که داره می‌سازه تغییر می‌کنه، واسه همین ساختار بهینه برای یه سازمان نیاز به تغییر در طول زمان داره. مثلا ممکنه بخشی از محصول که یه تیمی در یه سازمان درگیرشه، به بلوغ برسه، دیگه نیاز نباشه که فیچرهای بیشتری توش اضافه بشه و خوب باشه که بره تو حالت نگهداری. تو این شرایط، اگه نفرات این تیم تغییر نکنن (چه نوع‌شون چه تعدادشون) یه اتفاق بدی که می‌تونه بیوفته اینه که آدم‌هاش دیگه حال نکنن با جنس کاری که در ادامه هست،‌ یا اینکه این تیمه بشینه تیکه‌ای از محصول رو که دستشه، هی خفن‌تر کنه در حالی که نیازی نیست به این کار و تیکه‌های دیگهٔ محصول رو زمین موندن. لذا تغییر نه تنها خوبه، یه جاهایی لازم هم هست. ما تا سال ۹۳ توی کافه‌بازار، یه تیم کلاینت، یه تیم بک‌اند برای سرویس‌های عمومی کافه‌‌بازار و یه تیم بک‌اند برای سرویس پرداخت داشتیم. بعد دیدیم که کم کم هر استوری‌ای که می‌خوایم انجام بدیم، حداقل دوتا از این تیم‌ها رو تحت تاثیر قرار می‌ده و چون تیم‌ها برنامه‌ریزی و ایتریشن خودشون رو داشتن، هماهنگ کردن انجام این کارهای بین‌تیمی کار بسیار سختی می‌شه. لذا رفتیم گشتیم و خوندیم و ساختاری رو که اسپاتیفای داشت ازش استفاده می‌کرد، پیدا کردیم و ازش استفاده کردیم و خیلی بهتر شد. به جای سه تا تیمی که گفتم، اومدیم ۳ تا تیم دیگه ساختیم، تیم گشت و گذار، تیم اکتساب و تیم توسعه‌دهندگان. مدل ساختار جدید این بود که به جای تخصص (اندروید و بک‌اند و ...)، سفر کاربر توی محصول (user journey) رو ملاک قرار دادیم و گفتیم فرض کنیم دو دسته کاربر داریم، کاربر عادی و توسعه‌دهنده. یه تیم، کل کارهای مربوط به توسعه‌دهندگان رو دست گرفت و دو تا تیم دیگه، هر کدوم بخشی از سفر کاربر توی بازار رو. اینجوری که از لحظه‌ای که کاربر بازار رو باز می‌کنه و دنبال اپ‌ها می‌گرده یا لیست‌ها رو می‌بینه و تصمیم می‌گیره یه اپی رو نصب کنه، دست یه تیم باشه (گشت و گذار)، و از لحظه‌ای که می‌خواد یه اپی رو نصب کنه و دانلودش می‌کنه یا می‌خرتش و بعد نصب می‌کنه و بعدا شاید در موردش نظر ‌بده و اینا هم دست یه تیم دیگه (اکتساب برنامه‌ها). بعدها که تعداد آدم‌ها بیشتر شد، تغییرات بیشتری هم داده شد و احتمالا الان دیگه تیم‌هایی که گفتم وجود ندارن. هیچ کدوم از ساختارهایی رو که تجربه کردیم، نمی‌شه گفت خوب بودن یا بد. هر کدومش در زمان خودش جواب می‌داد و تو زمان دیگه‌ای نه.در ادامهٔ مقاله، در مورد یه تعداد گایدلاینی که توی شکل‌گیری یا تغییرات ساختارها می‌تونن کمک‌مون بکنن صحبت خواهیم کرد. با صحبت در مورد تخصص‌گراها و آچار فرانسه‌ها شروع می‌کنیم.تخصص‌گراها و آچار فرانسه‌هافرض کنید شما صاحب یه مجله آشپزی هستید. بعضی از کارمند‌هاتون آشپزن و دستور کار پخت غذاهای جدید درست می‌کنن، بعضی‌هاشون عکاسن و موقع تهیه غذا از خود غذا و مواد لازم و ... عکس می‌گیرن. بعضی‌هاشون هم ویراستارن و این دستور پخت‌ها رو به متن درست حسابی تبدیل می‌کنن و عکس‌ها رو می‌چسبونن تنگش و یه دستور پخت درست می‌کنن و می‌ذارن تو نسخه بعدی مجله. حالا فرض کنید پروسهٔ تهیه یه نسخهٔ مجله‌تون خیلی کار سختیه و هماهنگی و همکاری زیادی رو می‌طلبه و حس می‌کنید کار داره خوب و روون پیش نمی‌ره. یکی برمی‌گرده بهتون یه راه حل پیشنهاد می‌ده. می‌گه بیا به جای آشپز و عکاس و ویراستار، تایتل همه رو بذار «عضو تیم» و هر کدوم از اعضای این تیم بتونن صفر تا صد یه دستور آشپزی رو دربیارن؛ از پختش تا عکاسی و ویرایش دستور غذا. اینجوری دیگه هیچ هماهنگی‌ای لازم نیست و تو صرفا تهش یه تعداد دستور غذا از این اعضای تیم دریافت می‌کنی و می‌ذاری کنار هم و مجله‌ت رو منتشر می‌کنی. قبول می‌کنید پیشنهاد ایشون رو؟ معلومه که نه. اون غذایی که عکاس درست می‌کنه، اون متنی که آشپز می‌نویسه و اون عکسی که ویراستار می‌گیره ممکنه به درد هیچ یک از فامیل‌های کسی که پیشنهاد داده نخوره. نکته‌ای که اینجا می‌خوایم بگیم، تخصص‌گراییه. تو جوامع و در طول سالیان این ثابت شده که اگه من به جای پختن نون و کشاورزی و شکار بشینم کدم رو بزنم و هر کسی توی کاری تخصص پیدا بکنه و اون رو بهتر انجام بده، به نفع همه‌س. تحقیقات نشون داده که بهره‌وری یه تیم متشکل از چند نفر تخصص‌گرا (specialist)، از یه تیم متشکل از چند نفر آچار فرانسه (generalist) بیشتره. علی‌رغم اینکه آچار فرانسه‌ها هم خیلی مهمن، ولی تخصص‌گرایی اهمیت بیشتری داره. لذا سعی‌تون رو بکنید که برای هر کاری آدم متخصصش رو پیدا کنید و بذارید، به جای اینکه کسایی رو داشته باشید که هیچ کاری رو خیلی خوب بلد نیستن ولی اکثر از کارها سر درمیارن و سررشته‌ای توش دارن.نفر چپیه فک می‌کنه چیزی که تو ذهنشه لامپه، ولی لامپ نیس، یه تعداد چرخ‌دنده‌س. نفر راستیه هم کلی چرخ‌دنده تو کله‌ش هست.با این همه، تخصص‌گرایی خالی هم مشکلات خودش رو داره. یه جاهایی ممکنه یه تخصصی گلوگاه کارتون بشه و باعث بشه کل کار بخوابه. مثلا تو این مثال تیم مجله آشپزی، فرض کنید یه عکاسی دارید که خیلی هم کارش رو دقیق و خوب بلده، ولی سررشته‌ای تو باقی کار نداره و تا حالا خودش غذا درست نکرده. یا فرض کنید تو یه تیم نرم‌افزاری، برنامه‌نویس اندرویدی دارید که هیچ سررشته‌ای از طراحی رابط کاربری و مدیریت محصول نداره. احتمالا یه جاهایی باهاشون به مشکل خواهید خورد. اگه همین تخصص‌گراها، خبری از باقی قضیه داشتند و یه نیمچه دستی توش داشتند، کارتون خیلی روون‌تر پیش می‌رفت. چیزی که بهش می‌رسیم اینه که سعی کنید دنبال تخصص‌گراهایی بگردید که آچار فرانسه هم هستند. کسایی که یه کاری رو خیلی خوب بلدن، ولی دستی هم در کارهای دیگه دارن. این آچار فرانسه بودنشون شبیه چسبی عمل می‌کنه که تخصص خودشون رو به تخصص‌های دیگه می‌چسبونه، باعث می‌شه هماهنگی‌ها راحت‌تر بشه، اگه یه روز یه تخصص‌گرای دیگه‌ای از تیم مرخصی بود، کار نخوابه و پیش بره. خصوصا توی شرکت‌های نوپا و با تعداد نفرات کم، این دسته از آدم‌ها خیلی به کار میان. یادمه که اوایل کافه‌بازار و زمانی که ۵ نفر بودیم، در کنار تخصص‌هایی که داشتیم، تقریبا همه‌مون دستی تو همهٔ کارها داشتیم. اندروید، بک‌اند، UX، مدیریت محصول و بعضی نقش‌ها و تخصص‌ها که اون موقع اسمشون رو نمی‌دونستیم (و الان هم نمی‌دونیم). مثلا تیم و محصول لنگ منی که برنامه‌نویس اندروید بودم و پاره‌وقت هم بودم و ممکن بود امتحان معادلات دیفرانسیل داشته باشم، نبود و کار پیش می‌رفت (البته اینکه درس نمی‌خوندم و معدلم ۱۱.۲ بود هم تاثیر داشت). یا مثلا من اگه برای فیچری نیاز به تابعی سمت سرور داشتم که باید فراخوانی می‌کردم، منتظر نمی‌موندم سمت سرورش زده بشه و تموم بشه تا من کارم رو شروع کنم، خودم دست به کار می‌شدم. یا مثلا ۵، ۶ سال اول کافه‌بازار و دیوار ما اصن نقشی به اسم UX Designer نداشتیم. شاید یکی برگرده بگه که همینه که UX تون خوب نبوده (خیلی هم خوب بوده!) ولی اینش مهم نیس، مهم اینه که کار با کیفیت که دوست داشتیم داشت پیش می‌رفت.عنوان‌های شغلی گستردهتوی تیم‌های کوچیک، به عنوان‌های شغلی عجیب غریب برخوردید؟ مثلا نقش Content Manager تو اپی که یک نفر داره توش کار محتوا می‌کنه. یا مثلا نقش Interaction Designer تو تیم فنی یه اپی که نسخهٔ اولش دو ماه پیش لانچ شده و تیمش کلا ۱۰ نفره.حرفی که تو این قسمت می‌زنیم اینه که سعی کنید توی تیم‌تون به جای اینکه نیروهایی داشته باشید که یه کار خاص می‌کنن و عنوان شغلی‌شون ۵ کلمه‌س، کسایی داشته باشید که ۵ تا کار می‌تونن بکنن و عنوان شغلی‌شون یه کلمه است. به جای Interface Programmer، Software Architect و Backend Developer، یه نقش Developer بذارید، ولی اجازه بدید بتونن Developerهاتون همه مدل کار بکنن. آورده‌ای که این کار داره، انعطاف‌پذیری توی نقش‌ها و توی آدم‌هاست. من و مدیرم و همه همکارهام، وظیفه‌مون اینه که محصول خوبی ارائه بدیم، پس باید هر کاری برای بهتر شدن این محصول لازمه انجام بدیم. در نهایت نتیجه‌ش هم عاید همه‌مون باید بشه. لذا تو یه تیم خوب، چیزی که هیچ وقت نمی‌شنوید، چیزهایی شبیه به اینه که من فلان کار رو نمی‌کنم و فلان کار تو عنوان شغلی من نیست. البته این لازمه‌ش اینه که قبل‌تر از همه، مدیر و لیدر تیم این مایندست رو داشته باشه که هر کاری از دستش برمیاد برای تیم و محصول می‌کنه. اوایل لانچ دیوار که هنوز تیمی برای انتشار آگهی‌ها نبود، منی که برنامه‌نویس بودم و حسام آرمندهی که مدیرعامل بود، تو یه بازه‌هایی آگهی‌های جدید دیوار رو خودمون دونه دونه بررسی کردیم و براش زمان گذاشتیم تا سریع‌تر منتشر بشن. فضای تیم جوری بود که من خوشحال هم بودم که یه فرصتی دارم که می‌تونم در کنار کدی که می‌زنم، به جلو رفتن کارهای دیگه محصول هم کمک بکنم. من هیچ وقت به ذهنم خطور نکرد که من برنامه‌نویس اندرویدم، چرا باید آگهی تایید کنم؟ چون می‌دونستم که مدیرم هم همچین فکری نمی‌کنه.لیدرشیپ غیررسمییه چیزی داریم به اسم Line Management که من اینجا با اجازه‌تون مدیریت مستقیم تعریفش کردم. مثلا من عضو فلان تیمم و دارم ریپورت می‌کنم به مدیرم که فلانیه. اون شخص، مدیر تیم منه و کسی که من رو قراره ارزیابی کنه و بخواد ارتقا بده و این حرفا. اینجا به اون شخص می‌گیم مدیر مستقیم من و هم‌تیمی‌هام. چیزی که متداوله اینه که این مدیر مستقیم تیم، قوانین تیم رو خودش وضع می‌کنه، آدم‌ها رو رشد می‌ده و تصمیم نهایی همه کارها رو خودش می‌گیره. یه مدیر تازه‌کار معمولا نگران این چیزا هست اون اوایل. چیزایی از این جنس که چرا فلانی از بیرون تیم اومد و یه کاری با یکی از اعضای تیم من داشت؟ چرا فلان عضو تیم قبل از اینکه نظر من رو بپرسه فلان تصمیم رو گرفت؟ چرا طراحی فلان قسمت از محصول رو تیم انجام داده و پیاده‌سازی هم کرده بدون اینکه من تایید بکنم؟ چیزی که تو این بخش در موردش می‌خوایم صحبت کنیم اینه که این بزرگوار این کارو نکنه و بذاره تیم خودش کار خودش رو پیش ببره.شما به عنوان لیدر تیم، می‌تونید در کنار مدیریت مستقیمی که دارید انجام می‌دید، لیدرشیپ غیررسمی هم جا بندازید. اگه عنوان‌های شغلی آدم‌های تیم‌تون گسترده باشه، کم کم خواهید دید که بارقه‌هایی از لیدرشیپ توی بچه‌های تیم‌تون ظاهر می‌شه. مثلا می‌بینید یه عضو تیم‌تون دو تا عضو دیگهٔ تیم رو با خودش همراه کرده که فلان کار رو بشینن انجام بدن و تمومش بکنن؛‌ بدون اینکه شما مستقیم ازش خواسته باشین. یا ممکنه ببینید عضوی از تیم، خودجوش رفته کارهای باقی‌مونده برای انجام فلان پروژه رو درآورده و به بچه‌های دیگه هم اساین کرده و دارن شبانه‌روز تلاش می‌کنن که کار به موقع برسه. این‌ها، نشونه‌هایی از لیدرشیپ غیررسمیه.این مدل لیدرشیپ رو با ساپورت کردن این آدم‌ها می‌تونید گسترشش بدید و فضا رو براشون باز کنید تا شکوفا بشن و بتونن کارشون رو بکنن. خوبه لیدر تیم، خودش کسی رو اساین نکنه و بذاره تیم خودش تصمیم بگیره و به نتیجه برسه که فلان عضو تیم، پروژه رو مدیریت کنه و پیش ببره،‌ یا فلان‌کس روی دیزاین‌هایی که انجام می‌دیم نظر نهایی رو بده. با این روش، به جای اینکه لایه‌های مدیریتی و ساختار پیچیده درست کنید، نقش‌های غیررسمی‌ای شکل می‌گیرن که به جلورفتن کارها کمک می‌کنن و فردا هم اگه ساختار تیم و محصول‌تون عوض شد، نیاز نیس بشینید دوباره نقش‌های جدید تعیین کنید. خود تیم دوباره با شرایط جدید هماهنگ می‌شه و نقش‌های غیررسمی جدیدی به وجود میاره. قسمت اول این مقاله در همین‌جا به پایان می‌رسه. قسمت دومش رو می‌تونید اینجا بخونید.این مقاله و قسمت بعدیش، خلاصه و جمع‌وجورشدهٔ بخش‌هایی از فصل ۱۳ کتاب Management 3.0 نوشتهٔ Jurgen Appelo با اندکی تغییر و تفسیر است. این کتاب، کتابی بسیار زیبا و با ارزش است و خوندنش رو اکیدا به علاقه‌مندان توصیه می‌کنم. کیهان اصغری کیهان اصغری Sun, 29 Mar 2020 21:34:58 +0430 https://virgool.io/@keyhan.asghari/%D8%A7%D9%81%D8%B2%D8%A7%DB%8C%D8%B4-%D8%AD%D9%82%D9%88%D9%82-%D8%AA%D9%86%D9%87%D8%A7-%D8%B1%D8%A7%D9%87-%D8%A7%D9%81%D8%B2%D8%A7%DB%8C%D8%B4-%D8%A7%D9%86%DA%AF%DB%8C%D8%B2%D9%87-vusc4r70fion همه‌مون دوست داریم انگیزه بیشتری در کار و زندگی داشته باشیم. همچین انتظاری رو از آدم‌هایی که باهاشون کار می‌کنیم هم داریم. داگلاس مک‌گرگور، استاد دانشگاه ام‌آی‌تی، مدلی از انگیزه رو مطرح می‌کنه، به اسم نظریهٔ X و نظریهٔ Y. افزایش حقوق لزوما باعث افزایش انگیزه نمی‌شهنظریهٔ Xتوی نظریهٔ X میاد می‌گه که آدم‌ها عموما دوست ندارند کار کنند. این نظریه می‌گه که پول، فشار،‌ زور و چیزهایی از این قبیل هستند که باعث می‌شوند آدم‌ها کار بکنند. بخواین آدم‌ها بیشتر کار کنند، باید همین چیزها رو بیشتر اعمال کنید! برای مثال، اگر می‌خواهید کارمندی بهتر کار بکند، پول بیشتری به او بدهید و ددلاین‌های سفت و سخت‌تری برای او بگذارید. به خاطر باورمون به برهان علیت، خیلی معموله که فکر کنیم این تئوری کاملا درسته و جواب می‌ده. یا شاید بگیم نه تنها کاملا درسته، بلکه تنها راه هم هست. ولی خیلی‌ها بر این باورند که پول بیشتر دادن در ازای کار بیشتر و بهتر، می‌تونه خیلی هم مخرب باشه.نظریهٔ Yتوی نظریه Y میاد فرض می‌کنه که آدم‌ها ذاتا وظایفی که بهشون سپرده می‌شه و کارهایی رو که باید انجام بدهند، واقعا دوست دارند و می‌گه که کار کردن، اندازهٔ بازی کردن دوست‌داشتنی و لذت‌بخش می‌تونه باشه. این بخش از نظریه آقای مک‌گرگور، در مورد انگیزه درونیه.کاهش انگیزهباوری هست که شما نمی‌تونید به کسی انگیزه بدید! صرفا می‌تونید موانعی رو که باعث انگیزه گرفتن کسی می‌شه رو از راهش بردارید. متاسفانه یا خوشبختانه، این حرف درست نیست. به این فکر کنیم، آیا شما می‌تونید کسی رو خوشحال کنید؟ یا صرفا می‌تونید چیزهایی که مانع خوشحال شدنش هستند رو حذف کنید؟ آیا می‌تونید کسی رو بخندونید؟ یا فقط می‌تونید چیزهایی که باعث گریهٔ او می‌شه رو از سر راهش بردارید؟نظریه دو عاملینظریه دو عاملی (two-factor theory) یا Motivator-Hygiene (می‌شه ترجمه‌ش کرد انگیزنده-بهداشتی!) نظریهٔ روان‌شناس آمریکایی به اسم فردریک هرتزبرگ است که ادعا می‌کنه رضایت یا عدم رضایت، مستقل از یک‌دیگر هستند. چیزهایی که باعث افزایش انگیزه آدم‌ها می‌شوند، متفاوت هستند از چیزهایی که باعث کاهش انگیزه‌شان می‌شوند. محیط‌های سمی، حقوق‌های پایین، بروکراسی و چیزهایی این شکلی، آدم‌ها رو بی‌انگیزه می‌کنه. ولی اگه همین مسائل رو خوب مدیریت کنیم و مشکلی نداشته باشند هم، باعث افزایش انگیزه در آدم‌ها نمی‌شوند. تا حالا شنیدید کسی بگه صندلی من انقدر خوبه که باعث می‌شه سعی کنم کارم رو به بهترین نحو ممکن انجام بدم؟ چیزهایی مانند قدرت تصمیم‌گیری، به‌اندازه بودن مسئولیت، داشتن فرصت تاثیرگذاری، حس تعلق به جمع و چیزهایی از این دست، می‌تونند باعث بالا رفتن انگیزهٔ آدم‌ها بشوند. درواقع هرتزبرگ بین دو گروه از عوامل، تفکیک قائل می‌شه:عوامل انگیزنده: چالش کاری، دست یافتن به موفقیت، رشد شخصی، مسئولیت، مورد توجه واقع شدن و ... که باعث افزایش انگیزهٔ آدم‌ها می‌شه.عوامل بهداشتی: امنیت شغلی، حقوق، موقعیت کاری، شرایط محیط کار و ... که نبودشون باعث کاهش انگیزهٔ آدم‌ها می‌شه. عوامل بهداشتی، نمی‌تونند باعث بالا رفتن انگیزه کسی بشوند. مانند نقش بهداشت در زندگی آدم. بهداشت می‌بایستی حد معقولی داشته باشه و بیشتر بودن از اون حد دیگه خیلی فرقی برای آدم نمی‌کنه. نظریهٔ خودمختاری (Self-determination)دیدیم که انگیزه درونی مهم‌تر از انگیزه بیرونیه و حالا می‌خوایم ببینیم انگیزه درونی از چی ساخته می‌شه. این نظریه، وصف کلی‌تری از انگیزه درونی می‌ده و سه نیاز درونی انسان رو مطرح می‌کنه:صلاحیت (competence): نیاز فرد به اینکه ببینه از عهده کارها برمیاد و می‌تونه با محیط تعامل و مقابله کنه.استقلال (autonomy): نیاز فرد به اینکه بتونه تعیین کنندهٔ رفتار خودش باشه و بتونه به صورت مستقل کارهایی رو انجام بده.تعلق (relatedness): نیاز به توجه کردن و تعلق داشتن به دیگران و در ارتباط بودن با اجتماع.این نظریه، بیان می‌کنه که ما چطور می‌تونیم باعث افزایش انگیزه درونی آدم‌های دیگه بشیم. بر اساس این نظریه و نظریه‌های مشابه، می‌شه نتیجه گرفت ۱۰ کاری که در یک کسب و کار می‌شه با آدم‌های یک تیم کرد که انگیزه‌شون بالا بره، این‌هاس:کاری کنیم که آدم‌ها حس بکنند که شایسته و لایق کارشون هستند. بهشون کارهایی بدیم که براشون چالش داره (ولی قدرت انجامش رو هم دارند).یه کاری کنیم آدم‌ها حس پذیرفته شدن از سمت ما و تیم داشته باشند. در مورد موفقیت‌هاشون تعریف کنیم (الکی نه، فقط وقتی واقعا اینطور فکر می‌کنیم).حواسمون باشه به کنجکاوی آدم‌ها بها داده می‌شه. بعضی وقت‌ها مجبوریم کارهایی بکنیم که حوصله‌سر‌برن، ولی سعی کنیم همیشه یه چیز جدید و جذابی هم در کنارش باشه که آدم‌ها بتونن برن دنبال کشف کردنش.بیش از حد در امور داخلی تیم‌ها دخالت نکنیم، اجازه بدیم به تیم‌ها که قوانین خودشون رو وضع کنند؛ قوانینی که اعضای تیم قراره ازش پیروی کنند.کمی ایده‌آل‌گرایی وارد کسب‌و‌کار کنیم. قرار نیست فقط پول دربیاریم. حداقل یه کوچولو هم کمک کنیم دنیا جای بهتری بشه.کمک کنیم و اجازه بدیم آدم‌ها مستقل و متفاوت از بقیه باشن و کارها و مسئولیت‌ها و مدل خودشون رو داشته باشن. در مورد شیوه و مدل خاصشون تشویقشون کنیم و نخوایم همرنگ جماعت بشن.حواسمون باشه یه حداقلی از قانون و نظم برقرار باشه توی سازمان. آدم‌ها وقتی بتونن به یه تعداد قوانین حداقلی تکیه کنند، بهتر کار می‌کنند.حواسمون باشه آدم‌ها به چیزهایی که داره دور و برشون اتفاق میوفته، کنترل داشته باشند. گوش بدیم به حرفای آدم‌ها و کمک کنیم اتفاقایی که دوست دارند، بیوفته.بستر مناسبی درست کنیم برای رشد ارتباط‌های اجتماعی و به وجود آمدن دوستی بین آدم‌ها. حواسمون باشه که آدم‌ها عنوان و جایگاهی در سازمان داشته باشند و حس نکنند یه جایی اون پایینای یه سلسله‌مراتب بزرگ مشغول به کار هستند.خوبه اگه مدیر تیمی هستیم، به این ۱۰ مورد اهمیت بدیم و هر از گاهی مرورشون کنیم. این کارها، معمولا توی دستهٔ کارهای مهم ولی غیراورژانسی قرار می‌گیرند، لذا خیلی محتمله که از یاد ببریمشون. پس حواسمون بهشون باشه و یادمون باشه که در درازمدت، خیلی بیشتر از افزایش حقوق می‌تونن روی بالا بودن بازدهی تیم‌ها تاثیرگذار باشند.این مقاله، ترجمهٔ بخش‌هایی از فصل ۵ کتاب Management 3.0 نوشتهٔ Jurgen Appelo با اندکی تغییر و خلاصه‌سازی است. این کتاب، کتاب بسیار زیبا و با ارزشی است و خوندنش رو به علاقه‌مندان توصیه می‌کنم. کیهان اصغری کیهان اصغری Fri, 05 Jul 2019 05:02:07 +0430