بعضی‌هامون نظم دادن به چیزها و ساختار چیدن در اون‌ها رو دوست داریم. از مرتب کردن وسایل روی میز، تا چیدن کتاب‌هامون توی کتاب‌خونه با ترتیب مشخص، تا چیدن مواد غذایی توی طبقه‌های یخچال بر اساس نوع مواد غذایی. (البته این آخری رو مطمئن نیستم آدمای زیادی درگیرش باشن.)
در مورد سازمان‌ها و شرکت‌ها هم، یه نوعی از نظم و ساختار باید وجود داشته باشه و فکر می‌کنم همه‌مون رو اینش توافق داریم. در این مقاله، در مورد ساختار سازمان و برخی جوانبش می‌پردازیم.
جلوتر خواهیم دید که هیچ ساختار سازمانی‌ای وجود نداره که برای همه جواب بده. چیزی که شرکت کافهبازار داره استفاده می‌کنه به احتمال زیاد توی بلد جواب نمی‌ده و چیزی که بلد داره ازش نتیجه می‌گیره احتمالا دیوار رو زمین بزنه. (حالا نه در این حد ولی نکته رو بگیرید دیگه)
در این مقاله، ساختارهای سازمانی متداول رو بررسی نخواهیم کرد و هدف این نیست که از بین‌شون کدوم رو برای سازمان خودمون انتخاب کنیم. جلوتر به این نتیجه هم می‌رسیم که همچین کاری خیلی ممکن نیست و اگه یه زمانی مشاوری کسی اومد و ادعا کرد می‌تونه این کار رو براتون انجام بده و بره، به احتمال زیاد سر شما و حتی خودش کلاه گذاشته.
مدلی که اینجا در موردش صحبت می‌کنیم و بازش می‌کنیم، به جای انتخاب ساختار، روی رشد دادن و ساختنش تاکید داره و معتقده که یه سازمان، یه سیستم پیچیده است و نمی‌شه یه ساختاری از بیرون برداریم و بگیم این باشه و ساختار باید از درون خود سازمان بجوشه و دربیاد. مدیر همچین سیستمی، می‌تونه بسته به بلوغ و شرایط دیگهٔ سازمانش، فرمون رو بگیره دستش و به شکل‌گرفتن ساختار سازمانش جهت بده.
برای موجودات زنده چه فرمی بهتر جواب می‌ده؟ ساختار بدن موجودات زنده چجوری باشه بهتره؟ دو تا موجود زنده رو در نظر بگیرید، عنکبوت و ستاره دریایی. می‌تونیم بگیم ساختار بدن عنکبوت بهتر از ستاره دریاییه یا برعکس؟ نمی‌شه گفت. ساختار بدن عنکبوت تو یه شرایط و محیطی بهتر جواب می‌ده، ستاره دریایی تو یه محیط‌های دیگه. ساختار سازمان هم مثل همینه (منظورم این نیست که بعضی ساختارها تو خشکی بهتر جواب می‌دن بعضیا تو دریا).
بسته به فرهنگی که یه سازمان داره، تعداد آدم‌های سازمان و تخصص‌هاشون، محصولی که داره می‌سازه و سرویسی که داره می‌ده و کلی فاکتور دیگه، ساختار مناسب برای سازمان تعیین می‌شه. این فاکتورها به مرور زمان عوض هم می‌شن، مثلا تعداد نفرات یه سازمان بیشتر می‌شه یا محصولی که داره می‌سازه تغییر می‌کنه، واسه همین ساختار بهینه برای یه سازمان نیاز به تغییر در طول زمان داره.
مثلا ممکنه بخشی از محصول که یه تیمی در یه سازمان درگیرشه، به بلوغ برسه، دیگه نیاز نباشه که فیچرهای بیشتری توش اضافه بشه و خوب باشه که بره تو حالت نگهداری. تو این شرایط، اگه نفرات این تیم تغییر نکنن (چه نوع‌شون چه تعدادشون) یه اتفاق بدی که می‌تونه بیوفته اینه که آدم‌هاش دیگه حال نکنن با جنس کاری که در ادامه هست، یا اینکه این تیمه بشینه تیکه‌ای از محصول رو که دستشه، هی خفن‌تر کنه در حالی که نیازی نیست به این کار و تیکه‌های دیگهٔ محصول رو زمین موندن. لذا تغییر نه تنها خوبه، یه جاهایی لازم هم هست.
ما تا سال ۹۳ توی کافهبازار، یه تیم کلاینت، یه تیم بک‌اند برای سرویس‌های عمومی کافهبازار و یه تیم بک‌اند برای سرویس پرداخت داشتیم. بعد دیدیم که کم کم هر استوری‌ای که می‌خوایم انجام بدیم، حداقل دوتا از این تیم‌ها رو تحت تاثیر قرار می‌ده و چون تیم‌ها برنامه‌ریزی و ایتریشن خودشون رو داشتن، هماهنگ کردن انجام این کارهای بین‌تیمی کار بسیار سختی می‌شه. لذا رفتیم گشتیم و خوندیم و ساختاری رو که اسپاتیفای داشت ازش استفاده می‌کرد، پیدا کردیم و ازش استفاده کردیم و خیلی بهتر شد. به جای سه تا تیمی که گفتم، اومدیم ۳ تا تیم دیگه ساختیم، تیم گشت و گذار، تیم اکتساب و تیم توسعه‌دهندگان. مدل ساختار جدید این بود که به جای تخصص (اندروید و بک‌اند و ...)، سفر کاربر توی محصول (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 با اندکی تغییر و تفسیر است. این کتاب، کتابی بسیار زیبا و با ارزش است و خوندنش رو اکیدا به علاقه‌مندان توصیه می‌کنم.
