یک کتاب نسبتاً قدیمی از انتشارات wrox هست به نام Code Leader که مدتی پیش خواندنش را شروع کردم و هر از گاهی بخشی از آن را می‌خوانم. فصل اول این کتاب درباره مزیت رقابتی در نرم‌افزار صحبت می‌کند.

چکیده مباحث این فصل که به نظرم برای شرکت‌ها و تیم‌های نرم‌افزاری بسیار با اهمیت هستند به شرح زیر است:

  • حتی در یک پروژه با اندازه متوسط، تیم توسعه نمی‌تواند و نباید کل اجزای نرم‌افزار را به تنهایی پیاده سازی و تولید کند.
  • پیش از آنکه حتی یک خط کد بنویسید باید از خودتان بپرسید که آیا این نرم‌افزار ارزش تجاری برای مشتریانایجاد می‌کند؟
    یک مثال برای ارزش تجاری: اگر شرکت شما در زمینه تولید نرم‌افزارهای بانکی کار می‌کند مهمترین ارزش تجاری که برای مشتریان فراهم می‌کنید مربوط به حوزه کار بانکی است. بنابراین اگر در بخشی از نرم‌افزار به یک کنترل تقویم احتیاج دارید، با وجود اینکه کاربران سیستم به تقویم احتیاج دارند و شما هم خیلی وسوسه شدید که خودتان یک تقویم بنویسید، باز هم باید توجه کنید که کار اصلی شما تمرکز بر روی تولید یک نرم‌افزار بانکی است نه تولید یک کنترل تقویم. دیگرانی هستند که کنترل تقویم را خیلی بهتر از شما تولید کرده و پشتیبانی می‌کنند.
  • مساله مهم دیگر مساله سود و هزینه در تولید اجزای مختلف نرم‌افزار است.
    مثال (از خودم): نوشتن یک library زیرساختی برای log کردن اتفاقات نه تنها سودی ندارد بلکه مسائل مربوط به سازگاری و عملکرد بهینه و همیشگی و کنترل خطاها و ... باعث می‌شود هزینه زیادی به تیم وارد شود. در این مواقع می‌توانید از library های log آماده و تست شده و مشهور که مدام هم به روز می‌شوند و همه جوره قابل تنظیم هستند استفاده کنید.
  • برای ایجاد مزیت رقابتیباید به بخش‌های کلیدی پروژه که ارزش تجاری ایجاد می‌کنند توجه کنید. وقتی یک نرم‌افزار انبارداری می‌نویسید آنچه ارزش تجاری ایجاد می‌کند الگوریتم تشخیص زمان مناسب برای سفارش کالاهاست نه درایور بارکد اسکنر انبار! بعضی مواقع تصمیم‌گیری درباره اینکه چه بخش‌هایی را خودمان توسعه بدهیم و چه بخش‌هایی را به دیگران واگذار کنیم ساده است. مثلاً برای نگهداری داده‌های خود، هیچ وقت یک database engine درست نمی‌کنید.
    اگر مجدداً مثال نرم‌افزار بانکی و تقویم را در نظر بگیرید، اگر نرم‌افزار شما نیاز به تقویم دارد و شما از یک تقویم آماده استفاده می‌کنید اما مشتری در خاورمیانه دارید که نیاز به یک تقویم جایگزین مناسب با نوع تاریخش دارد، اینجا جایی است که با نوشتن یک تقویم جایگزین می‌توانید مزیت رقابتی ایجاد کنید. با وجود اینکه ایجاد کنترل تقویم هدف بیزنس شما نیست اما در این مورد خاص نوشتن یک تقویم جایگزین ارزش تجاری ایجاد می‌کند یعنی نرم‌افزار بانکی شما برای مشتریان خاورمیانه‌ای هم قابل استفاده می‌شود.
  • استفاده از پروژه‌های اپن سورس به عنوان بخشی از پروژه اصلی توصیه نمی‌شود. به یاد داشته باشید عبارت "بدون پرداخت هزینه" به معنی "بدون هزینه" نیست. یکی از مواردی که به عنوان مزیت استفاده از پروژه‌های اپن سورس یاد می‌شود این است که افراد بسیاری از سراسر جهان در حال کار و توسعه آن‌ها هستند. این موضوع فقط برای پروژه‌های بزرگ مصداق پیدا می‌کند. اگر در نهایت تصمیم می‌گیرید که از یک پروژه اپن سورس استفاده کنید، حتماً به میزان اکتیو بودن جامعه توسعه‌دهنده‌های آن توجه کنید.
  • نوشتن نرم‌افزار جالبه و کاری هست که ما انجامش می‌دهیم اما کاری نیست که به خاطرش حقوق می‌گیریم. ما حقوق می‌گیریم تا به کمک نوشتن نرم‌افزار برای مشتریانی که اسپانسر تولید این نرم‌افزارها شده‌اند ارزش تجاری ایجاد کنیم.