onia$
دستیار مدیر تالار مدیریت
صنعت نرم‌افزار و حقوق
به جاي اقامه دعوي، كارآمدي را افزايش دهيد
نویسنده: جان کازگراو
مترجم: متین پدرام 1
خوب یا بد، نظام قضایی دنیا کامپیوترها و فعالان آن را کشف کرده است. زمانی که روزنامه می‌خوانیم یا اخبار را دنبال می‌کنیم، متوجه می‌شویم دعاوی مربوط به نقض حقوق نرم‌افزار بسیار گسترش یافته است. در واقع، حقوقدانان ممکن است نخستین کسانی باشند که انگیزه‌هایی برای تعهدات قراردادی واقع‌گرایانه و تعهد سازمانی به کیفیت فراهم می‌کنند. این امر برای صنعت خودروسازی ایالات متحده آمریکا اتفاق افتاد که به سود خودروسازان و مصرف‌کنندگان منجر شد.
تهدید
«تام دومارکو» و «تیم لیستر» تخمین زده‌اند، «هزینه‌های اقامه دعوی بسیار سریع‌تر از جنبه‌های دیگر توسعه نرم‌افزار افزایش می‌یابد. همچنین هزینه‌های اقامه دعوی... جزئی از برنامه‌نویسی نرم‌افزارها شده است.» معمولا این امر دربرگیرنده اختلافات پروژه‌های کامپیوتری و قراردادهای آن است؛ اما اغلب نیازمند نظرات کارشناسی درباره موضوعات تخصصی است. مسائل مهمی وجود دارد که ساختار اقتصادی، سلامتی شهروندان و ایمنی آنها را تهدید می‌کند و با نرم‌افزارهای کامپیوتری مرتبطند. این تهدیدها مدت زمان طولانی است که وجود دارند؛ اما اخیرا نظام حقوقی امکان اقامه دعوی در حوزه نرم‌افزار را به خوبی مشخص کرده است.
چرا نرم‌افزارها متفاوتند؟
بسیاری از نظام‌های مهندسی با طرح‌های جامع و ویژگی‌های مختص به خود آغاز می‌شوند؛ اما تعداد اندکی از شرکت‌های عمده نرم‌افزار موفق به انجام آنها می‌شوند!
این واقعیت ساده وضعیتی را به وجود می‌آورد که به اقامه دعوی منتهی می‌شود. درواقع، معمولا ناممکن است که به صورت کامل بسیاری از نظام‌های عملی نرم‌افزار تعریف شوند. «واتس هامفری» این معما را چنین بیان می‌کند: «چالش نرم‌افزار، ایجاد تعادل میان ماهیت ناشناخته لوازم آن و نیاز تجاری به رابطه قراردادی بنگاه‌ها است.»
بنابراین پاسخ واضحی برای ابهامات حقوقی وجود ندارد. هر دو طرف باید یاد بگیرند که با این ابهامات زندگی کنند و آنها را با همکاری یکدیگر حل‌وفصل کنند. زمانی که این فهم درهم می‌شکند باید این امر را به خاطر داشت که نتایج اقامه دعوی و حکم نهایی برای طرفین دعوی پرهزینه خواهد بود. دومارکو و لیستر، چنین عنوانی برای مقاله خود برگزیدند: «هر دو طرف همیشه شکست می‌خورند: اقامه دعوی درباره قراردادهای تولید انبوه نرم‌افزار». مهم‌ترین وظیفه کارشناسان نرم‌افزار این است که طرفین اختلاف را از این حالت بیمارگونه دور کنند.
توصیف مسائل غیرقابل توصیف
همان‌طور که «ویت» می‌گوید: «همه طرفین دعوی دروغ می‌گویند؛ اما هیچ‌یک از آنها نمی‌دانند که دروغ می‌گویند.» این امر در دعاوی مربوط به نرم‌افزار به طور مضاعفی درست است. مردم به این مساله خو گرفته‌اند که بیشترین نتایج غیرقابل دفاع نشأت‌گرفته از واقعیت‌های کامپیوتر این است که آنها باور می‌کنند هرچیزی می‌تواند گاهی اوقات درست باشد. بنابراین آنها ممکن است به خوبی مدعی آن شوند؛ زیرا پیچیدگی معمولا بسیار زیاد است و به دشواری می‌توان هر اظهار اشتباهی را در یک آیین رسیدگی اثبات کرد.
چه باید کرد؟
هیچ تضمینی وجود ندارد؛ اما اگر فرآیند توسعه نرم‌افزار، همه گام‌های معقولانه را دربرگیرد، بهترین دفاع ممکن در دسترس خواهد بود. اگرچه یک فرآیند مستند کارآمد، کیفیت را تضمین نمی‌کند؛ اما تضمین کیفیت بالا و نتایج سازگار همیشه نتیجه یک فهم و فرآیند مستند کارآمد است. دست‌کم با این عمل، اتهام بی‌مبالاتی بعید است که مورد حکم دادگاه قرار بگیرد.
پرهیز از اقامه دعوی و حفظ آن به عنوان یک اهرم
چندین سال قبل، «باد لوسون» روشی برای تعریف فرآیندهای مهندسی پیشنهاد کرد تا با کمک آن، به توسعه نرم‌افزار و سیستم‌های امنیتی پرداخته شود. این روش فرض می‌کند که دعوایی حقوقی علیه آنها اقامه شده است و باید همه گام‌های معقولانه در فعالیت‌های مهندسی وجود داشته باشد. به این ترتیب می‌توان در برابر چنین دعوایی دفاع کرد. دومارکو و لیستر استراتژی مشابهی را پیشنهاد می‌کنند. آنها بر این باورند که مسائلی که شما برای موفقیت در یک دعوی نیاز دارید این است که... شما باید از اقامه دعوی پرهیز کنید.»
به عبارت دیگر، مهندسی کارآمد در بهترین حالت خود بهترین دفاع حقوقی خواهد بود. برای نمونه فرهنگ گروه توسعه‌دهنده نرم‌افزار به ندرت با رویه‌هایی سازگار است که یک حقوقدان می‌تواند به آنها به عنوان تمامی گام‌های معقولانه در دادگاه استناد کند. پروژه‌های واقعی با نیازهایی تعریف می‌شوند که اغلب مستقل از ابزارهای در دسترس هستند.
هامفری در مقاله خود با عنوان «چرا شرکت‌های نرم‌افزار بی‌نظم هستند؟» پروژه را چنین تعریف می‌کند: «جدول... نشان می‌دهد چه چیزی نیاز است و هیچ‌چیزی نباید مانع از عملی‌شدن طرح دست‌یافتنی شود.» حتی اگر گروه توسعه نرم‌افزار به این جدول عمل کنند، ممکن است کیفیت محصول قابل پذیرش نباشد که پایه‌ای متفاوت برای اقامه دعوی ایجاد می‌کند. راه‌حل این است که بر انتظارات دست‌یافتنی تاکید کنیم تا گروه توانا شود نظامی را بر اساس اصل گام‌های معقولانه اداره کند.
براساس یک رویکرد، توسعه‌دهندگان نرم‌افزار ممکن است بدترین اصول را برای توسعه پروژه‌های خود طراحی کنند. اقامه دعوی بسیاری از کارخانه‌ها را تحریک می‌کند تا بدترین اصول را طراحی و راه‌های مدیریت آنها را تبیین کنند. برای نمونه کارخانه‌های خودرو می‌توانند از خودشان دفاع کنند؛ به این صورت که به تحقیق و آزمایش‌های دشوار به منظور تایید طرح‌های خود پیش از تولید نهایی آنها استناد کنند. اگرچه این آزمایش‌ها و تحقیقات هنوز کامل نیستند؛ اما پیشرفت‌های عمده‌ای در ایمنی محصولات انجام شده است. مهندسی نرم‌افزار نیز احتمالا با چنین فشاری روبه‌رو خواهد شد و باید از این اصول استفاده کند.
مدیریت انتظارات
هامفری همچنین اظهار کرد یک رخوت فرهنگی با انتظارات غیرواقعی سروکار دارد: «شرکت‌های تولیدکننده نرم‌افزار مانند دونده‌ای هستند که می‌خواهد مسافت یک مایل را در دو دقیقه طی کند. آنها برای موفقیت باید چه اقداماتی انجام دهند؟ بسیاری از برنامه‌نویسان در جست‌وجوی کفش‌های ورزشی هستند.» می‌توان پاسخ‌های دیگری به این پرسش داد؛ اما این امر بدیهی است که عقلانیت نمی‌تواند به درستی در توسعه نرم‌افزار حاکم شود.
برای نمونه مشتری انتظار دارد محصول مورد نظر خود را در کمتر از شش ماه دریافت کند. مشتری می‌داند که انجام این تعهد سابقه نداشته، امری دشوار و دارای ریسک است؛ اما زمانی که انتظارات خریدار جامه عمل نپوشید، او، قرارداد را فسخ و از تامین‌کننده شکایت می‌کند.
نقش کارشناس این بود که انتظارات طرفین را توصیف کند و تغییرات احتمالی انتظارات مشتری از تأمین‌کننده را طی دوران حیات پروژه پیش‌بینی کند. این نوع از انتظارات آن‌طور که باید نادر نیستند. بسیاری استدلال می‌کنند که نبود واقع‌گرایی (realism) به هنجاری در توسعه نرم‌افزار تبدیل شده
است.
بدون اغراق می‌توان گفت زمانی که انتظارات غیرواقعی فراموش می‌شوند، اقامه دعوی دنبال می‌شود. توسعه‌دهندگان نرم‌افزار از این مساله پرهیز می‌کنند؛ زیرا فرآیند آموزش مشتری همیشه دشوار و ممکن است ناکارآمد باشد. تنها راه این فرآیند دشوار، مواجهه با درک مشتریان و مستندکردن فهم مشترک است. همچنین، مهندسی کارآمد به منظور تعریف یک پروژه با اهداف دست‌یافتنی ضروری است.
جمع‌بندی
اقامه دعوی به بخش مهمی از زندگی حرفه‌ای برنامه‌نویسان تبدیل شده است. در نتیجه، ما به تغییر مسیر احتیاج داریم. همچنین اقامه دعوی سناریویی پرریسک است که بیشتر به بازی باخت-باخت شباهت دارد. بسیاری از تغییرات این صنعت مفید است. برای نمونه، صداقت میان مشتریان و شرکت، واقع‌گرایی و استفاده از روش‌های کارآمد به همگان در بلندمدت سود خواهند رساند.
در نهایت، همه شرکت‌های تولیدکننده نرم‌افزار باید این تعهد را بپذیرند که همیشه بدترین حالت این حرفه را در نظر داشته باشند و حقوقدانان نیز این مساله را روشن کنند که چرا صنعت نرم‌افزار، چنین فرآیندی دارد.
به جاي اقامه دعوي، كارآمدي را افزايش دهيد
نویسنده: جان کازگراو
مترجم: متین پدرام 1
خوب یا بد، نظام قضایی دنیا کامپیوترها و فعالان آن را کشف کرده است. زمانی که روزنامه می‌خوانیم یا اخبار را دنبال می‌کنیم، متوجه می‌شویم دعاوی مربوط به نقض حقوق نرم‌افزار بسیار گسترش یافته است. در واقع، حقوقدانان ممکن است نخستین کسانی باشند که انگیزه‌هایی برای تعهدات قراردادی واقع‌گرایانه و تعهد سازمانی به کیفیت فراهم می‌کنند. این امر برای صنعت خودروسازی ایالات متحده آمریکا اتفاق افتاد که به سود خودروسازان و مصرف‌کنندگان منجر شد.
تهدید
«تام دومارکو» و «تیم لیستر» تخمین زده‌اند، «هزینه‌های اقامه دعوی بسیار سریع‌تر از جنبه‌های دیگر توسعه نرم‌افزار افزایش می‌یابد. همچنین هزینه‌های اقامه دعوی... جزئی از برنامه‌نویسی نرم‌افزارها شده است.» معمولا این امر دربرگیرنده اختلافات پروژه‌های کامپیوتری و قراردادهای آن است؛ اما اغلب نیازمند نظرات کارشناسی درباره موضوعات تخصصی است. مسائل مهمی وجود دارد که ساختار اقتصادی، سلامتی شهروندان و ایمنی آنها را تهدید می‌کند و با نرم‌افزارهای کامپیوتری مرتبطند. این تهدیدها مدت زمان طولانی است که وجود دارند؛ اما اخیرا نظام حقوقی امکان اقامه دعوی در حوزه نرم‌افزار را به خوبی مشخص کرده است.
چرا نرم‌افزارها متفاوتند؟
بسیاری از نظام‌های مهندسی با طرح‌های جامع و ویژگی‌های مختص به خود آغاز می‌شوند؛ اما تعداد اندکی از شرکت‌های عمده نرم‌افزار موفق به انجام آنها می‌شوند!
این واقعیت ساده وضعیتی را به وجود می‌آورد که به اقامه دعوی منتهی می‌شود. درواقع، معمولا ناممکن است که به صورت کامل بسیاری از نظام‌های عملی نرم‌افزار تعریف شوند. «واتس هامفری» این معما را چنین بیان می‌کند: «چالش نرم‌افزار، ایجاد تعادل میان ماهیت ناشناخته لوازم آن و نیاز تجاری به رابطه قراردادی بنگاه‌ها است.»
بنابراین پاسخ واضحی برای ابهامات حقوقی وجود ندارد. هر دو طرف باید یاد بگیرند که با این ابهامات زندگی کنند و آنها را با همکاری یکدیگر حل‌وفصل کنند. زمانی که این فهم درهم می‌شکند باید این امر را به خاطر داشت که نتایج اقامه دعوی و حکم نهایی برای طرفین دعوی پرهزینه خواهد بود. دومارکو و لیستر، چنین عنوانی برای مقاله خود برگزیدند: «هر دو طرف همیشه شکست می‌خورند: اقامه دعوی درباره قراردادهای تولید انبوه نرم‌افزار». مهم‌ترین وظیفه کارشناسان نرم‌افزار این است که طرفین اختلاف را از این حالت بیمارگونه دور کنند.
توصیف مسائل غیرقابل توصیف
همان‌طور که «ویت» می‌گوید: «همه طرفین دعوی دروغ می‌گویند؛ اما هیچ‌یک از آنها نمی‌دانند که دروغ می‌گویند.» این امر در دعاوی مربوط به نرم‌افزار به طور مضاعفی درست است. مردم به این مساله خو گرفته‌اند که بیشترین نتایج غیرقابل دفاع نشأت‌گرفته از واقعیت‌های کامپیوتر این است که آنها باور می‌کنند هرچیزی می‌تواند گاهی اوقات درست باشد. بنابراین آنها ممکن است به خوبی مدعی آن شوند؛ زیرا پیچیدگی معمولا بسیار زیاد است و به دشواری می‌توان هر اظهار اشتباهی را در یک آیین رسیدگی اثبات کرد.
چه باید کرد؟
هیچ تضمینی وجود ندارد؛ اما اگر فرآیند توسعه نرم‌افزار، همه گام‌های معقولانه را دربرگیرد، بهترین دفاع ممکن در دسترس خواهد بود. اگرچه یک فرآیند مستند کارآمد، کیفیت را تضمین نمی‌کند؛ اما تضمین کیفیت بالا و نتایج سازگار همیشه نتیجه یک فهم و فرآیند مستند کارآمد است. دست‌کم با این عمل، اتهام بی‌مبالاتی بعید است که مورد حکم دادگاه قرار بگیرد.
پرهیز از اقامه دعوی و حفظ آن به عنوان یک اهرم
چندین سال قبل، «باد لوسون» روشی برای تعریف فرآیندهای مهندسی پیشنهاد کرد تا با کمک آن، به توسعه نرم‌افزار و سیستم‌های امنیتی پرداخته شود. این روش فرض می‌کند که دعوایی حقوقی علیه آنها اقامه شده است و باید همه گام‌های معقولانه در فعالیت‌های مهندسی وجود داشته باشد. به این ترتیب می‌توان در برابر چنین دعوایی دفاع کرد. دومارکو و لیستر استراتژی مشابهی را پیشنهاد می‌کنند. آنها بر این باورند که مسائلی که شما برای موفقیت در یک دعوی نیاز دارید این است که... شما باید از اقامه دعوی پرهیز کنید.»
به عبارت دیگر، مهندسی کارآمد در بهترین حالت خود بهترین دفاع حقوقی خواهد بود. برای نمونه فرهنگ گروه توسعه‌دهنده نرم‌افزار به ندرت با رویه‌هایی سازگار است که یک حقوقدان می‌تواند به آنها به عنوان تمامی گام‌های معقولانه در دادگاه استناد کند. پروژه‌های واقعی با نیازهایی تعریف می‌شوند که اغلب مستقل از ابزارهای در دسترس هستند.
هامفری در مقاله خود با عنوان «چرا شرکت‌های نرم‌افزار بی‌نظم هستند؟» پروژه را چنین تعریف می‌کند: «جدول... نشان می‌دهد چه چیزی نیاز است و هیچ‌چیزی نباید مانع از عملی‌شدن طرح دست‌یافتنی شود.» حتی اگر گروه توسعه نرم‌افزار به این جدول عمل کنند، ممکن است کیفیت محصول قابل پذیرش نباشد که پایه‌ای متفاوت برای اقامه دعوی ایجاد می‌کند. راه‌حل این است که بر انتظارات دست‌یافتنی تاکید کنیم تا گروه توانا شود نظامی را بر اساس اصل گام‌های معقولانه اداره کند.
براساس یک رویکرد، توسعه‌دهندگان نرم‌افزار ممکن است بدترین اصول را برای توسعه پروژه‌های خود طراحی کنند. اقامه دعوی بسیاری از کارخانه‌ها را تحریک می‌کند تا بدترین اصول را طراحی و راه‌های مدیریت آنها را تبیین کنند. برای نمونه کارخانه‌های خودرو می‌توانند از خودشان دفاع کنند؛ به این صورت که به تحقیق و آزمایش‌های دشوار به منظور تایید طرح‌های خود پیش از تولید نهایی آنها استناد کنند. اگرچه این آزمایش‌ها و تحقیقات هنوز کامل نیستند؛ اما پیشرفت‌های عمده‌ای در ایمنی محصولات انجام شده است. مهندسی نرم‌افزار نیز احتمالا با چنین فشاری روبه‌رو خواهد شد و باید از این اصول استفاده کند.
مدیریت انتظارات
هامفری همچنین اظهار کرد یک رخوت فرهنگی با انتظارات غیرواقعی سروکار دارد: «شرکت‌های تولیدکننده نرم‌افزار مانند دونده‌ای هستند که می‌خواهد مسافت یک مایل را در دو دقیقه طی کند. آنها برای موفقیت باید چه اقداماتی انجام دهند؟ بسیاری از برنامه‌نویسان در جست‌وجوی کفش‌های ورزشی هستند.» می‌توان پاسخ‌های دیگری به این پرسش داد؛ اما این امر بدیهی است که عقلانیت نمی‌تواند به درستی در توسعه نرم‌افزار حاکم شود.
برای نمونه مشتری انتظار دارد محصول مورد نظر خود را در کمتر از شش ماه دریافت کند. مشتری می‌داند که انجام این تعهد سابقه نداشته، امری دشوار و دارای ریسک است؛ اما زمانی که انتظارات خریدار جامه عمل نپوشید، او، قرارداد را فسخ و از تامین‌کننده شکایت می‌کند.
نقش کارشناس این بود که انتظارات طرفین را توصیف کند و تغییرات احتمالی انتظارات مشتری از تأمین‌کننده را طی دوران حیات پروژه پیش‌بینی کند. این نوع از انتظارات آن‌طور که باید نادر نیستند. بسیاری استدلال می‌کنند که نبود واقع‌گرایی (realism) به هنجاری در توسعه نرم‌افزار تبدیل شده
است.
بدون اغراق می‌توان گفت زمانی که انتظارات غیرواقعی فراموش می‌شوند، اقامه دعوی دنبال می‌شود. توسعه‌دهندگان نرم‌افزار از این مساله پرهیز می‌کنند؛ زیرا فرآیند آموزش مشتری همیشه دشوار و ممکن است ناکارآمد باشد. تنها راه این فرآیند دشوار، مواجهه با درک مشتریان و مستندکردن فهم مشترک است. همچنین، مهندسی کارآمد به منظور تعریف یک پروژه با اهداف دست‌یافتنی ضروری است.
جمع‌بندی
اقامه دعوی به بخش مهمی از زندگی حرفه‌ای برنامه‌نویسان تبدیل شده است. در نتیجه، ما به تغییر مسیر احتیاج داریم. همچنین اقامه دعوی سناریویی پرریسک است که بیشتر به بازی باخت-باخت شباهت دارد. بسیاری از تغییرات این صنعت مفید است. برای نمونه، صداقت میان مشتریان و شرکت، واقع‌گرایی و استفاده از روش‌های کارآمد به همگان در بلندمدت سود خواهند رساند.
در نهایت، همه شرکت‌های تولیدکننده نرم‌افزار باید این تعهد را بپذیرند که همیشه بدترین حالت این حرفه را در نظر داشته باشند و حقوقدانان نیز این مساله را روشن کنند که چرا صنعت نرم‌افزار، چنین فرآیندی دارد.
