قانون کانوی؛ آیا شرکت شما ساختار درستی دارد؟

ملوین کانوی (Melvin Conway) فوق‌لیسانس فیزیک از موسسه فناوری کالیفرنیا یا کلتک (Caltec) و دکترای ریاضیات از دانشگاه کیس وسترن رزرو (Case Western Reserve University) داشت. او جزو کسانی بود که در دهه ۷۰ میلادی روی توسعه کامپایلر زبان پاسکال کار می‌کرد.

او در سال ۱۹۶۷ مقاله‌ای به مجله هاروارد بیزینس ریویو (Harvard Business Review) فرستاد که البته این مجله مقاله‌ او را به دلیل نبود شواهد کافی درباره نظرات بیان‌شده در آن، رد کرد.

این مقاله قاعده‌ای را در مورد تاثیر ساختارهای سازمانی روی ساختارهای محصولات و به‌طور خاص محصولات نرم‌افزاری شرکت‌های فناوری، بیان می‌کرد.

قانون کانوی چیست؟

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

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

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

آیا لزوما دلیل کیفیت و کارایی محصولات گوگل فقط به خاطر نیروی متخصص و سرمایه‌گذاری گوگل است؟

کانوی در کار خود مشاهده کرد که ساختار نرم‌افزارهایی که توسط تیم‌های برنامه‌نویسی تولید می‌شود، بازتابی از ساختار سازمانی این تیم‌ها هستند.

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

طبق قانون کانوی (Conways's Law) هنگامی‌که تیم بازاریابی سازمان یک صفحه وب، تیم دیگر فروش یک صفحه وب دیگر و تیم روابط عمومی وب‌سایت دیگری برای خود دارد، این ساختار وب‌سایت ناشی از دیکته شدن ساختار سازمان در محصول است و نه بر پایه راحتی و نیازهای مشتریان.

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

قانون کانوی هم قانون طبیعت نیست

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

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

در سال ۲۰۰۸ آلن مک‌کورمک (Alan MacCormack) و همکاران او با مقایسه نرم‌افزارهای تولیدی در شرکت‌ها و نرم‌افزارهای کدباز توانستند شواهدی بر درستی قانون کانوی پیدا کنند.

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

به همین دلیل علی‌رغم وجود شواهد، شاید نتوان گفت که قانون کانوی واقعا یک قانون است؛ اما به نظر می‌آید که در موارد زیادی صدق می‌کند.

قانون کانوی به چه دردی می‌خورد؟

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

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

چگونه ساختار مناسبی برای سازمان طراحی کنیم؟

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

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

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

شاید بتوان با دقت کردن روی ساختار محصولات تولیدی شرکت‌های فناوری، به معماری درون شرکت‌ها نیز پی برد.

واضح است که این فرآیند کند، زمان‌بر و غیربهینه است و به‌هیچ‌وجه توان رقابت و تغییر در دنیای تند امروز را ندارد.

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

برای ساختن این تعداد تیم‌ هم لازم است قواعد سازگاری برای خروجی محصول نهایی هرکدام از تیم‌ها تنظیم شوند تا در نهایت بتوان یک محصول سازگار و پایدار ارائه داد.

آیا ساختار شرکت شما مناسب است؟

در نهایت قانون کانوی نه‌تنها معیاری برای بررسی تناسب ساختار با محصول مورد انتظار ارائه نمی‌دهد، بلکه حتی ابزاری برای تشخیص وجود مشکل هم ندارد.

ولی به ما یادآوری می‌کند دائما این سؤال را از خود بپرسیم که آیا ساختار موجود در شرکت ما می‌تواند بهترین محصول را برای مشتریان ما ارائه دهد یا نه؟