برنامه‌نویسی یعنی نوشتن دستورهایی که نرمافزار را وادار به انجام کاری مشخص میکند. توسعه نرمافزار کل مسیر ساخت محصول است، از شناخت نیاز تا تست و پشتیبانی. کسب‌وکار شما وقتی به آن نیاز دارد که کاری تکراری یا پراکنده را بشود با قاعده انجام داد.
این راهنما برای مدیر یا صاحب کسب‌وکاری است که کدنویس نیست و نمی‌خواهد باشد. قرار نیست چیزی یاد بگیرید که برنامه‌نویس‌ها بلدند. قرار است در پایان بتوانید تشخیص دهید کدام مشکل شما را نرمافزار حل میکند و برای آن به ابزار آماده، ساخت اختصاصی یا کمک یک شرکت نیاز دارید، پیش از آنکه با کسی تماس بگیرید.
برنامه‌نویسی فقط کدنویسی است؟ فرق آن با توسعه نرمافزار برای مدیر چه معنایی دارد
وقتی نرمافزار به کار کسب‌وکارتان می‌آید، عملاً سه مسیر پیش رویتان است: ابزار آماده، توسعهٔ اختصاصی، یا همکاری با یک شرکت برنامه‌نویسی. بقیهٔ این مقاله برای این است که بین این سه، آگاهانه انتخاب کنید.
برنامه‌نویسی نوشتن دستورهایی است که کامپیوتر دقیقاً مطابق آن‌ها رفتار کند: وقتی مشتری دکمهٔ «ثبت سفارش» را زد، چه چیزی ذخیره شود، به چه کسی خبر برسد، موجودی چقدر کم شود. توسعه نرمافزار دامنهٔ بزرگ‌تری دارد. شناخت نیاز، طراحی، ساخت، تست، تحویل و نگهداری، همه در آن جا می‌گیرند. کدنویسی فقط یکی از حلقه‌های این زنجیر است.
تشبیهِ ساده‌اش ساختمان‌سازی است. برنامه‌نویس مثل استادکاری است که دیوار را می‌چیند. توسعه نرمافزار کل پروژهٔ ساخت است، با نقشه، مهندس ناظر و تحویل کلید. اگر فقط استادکار بگیرید و نقشه نداشته باشید، ساختمان بالا می‌رود ولی شاید همان چیزی نباشد که می‌خواستید.
پس چرا این برای شما مهم است؟ چون وقتی از یک شرکت «برنامه‌نویسی» می‌خواهید، باید دقیق بپرسید کدام بخش مسیر را به عهده می‌گیرد. فقط ساخت؟ یا از نوشتن نیازمندی‌ها تا پشتیبانی؟ این تفاوت در قرارداد، در مسئولیت و در نتیجهٔ نهایی خودش را نشان می‌دهد. برای نگاه کلی‌تر به این حوزه، می‌توانید صفحهٔ برنامه‌نویسی و توسعه نرمافزار در وبلاگ ما را هم ببینید.
چه مشکل‌هایی در کسب‌وکار شما واقعاً با نرمافزار حل میشود؟
از ابزار شروع نکنید، از مسئله شروع کنید. برای اینکه بحث ملموس بماند، یک سناریو را تا آخر مقاله دنبال می‌کنیم.
مثال فرضی: کسب‌وکاری کوچک، سفارش‌هایش را از دایرکت اینستاگرام و پیام‌های تلگرام می‌گیرد. موجودی کالا در یک فایل اکسل است که دو نفر ویرایشش می‌کنند. پیگیری مشتری‌ها هم یا در دفترچه است یا در همان چت‌ها، به شرط اینکه کسی یادش بماند برگردد و نگاه کند.
این کسب‌وکار فرضی ظاهراً کار میکند. اما نشانه‌های مشکل را در هر چهار بخش میشود دید.
فروش و سفارش‌های پراکنده
سفارش در سه جا می‌آید و هیچ جا فهرست کامل نیست. نشانهٔ عینی‌اش ساده است: یک سفارش در چت گم میشود و مشتری سه روز بعد می‌پرسد چه شد. وقتی ورودی سفارش یک مسیر ثابت نداشته باشد، هر کس برای خودش ثبت میکند و هیچ‌کس تصویر کامل را ندارد.
مدیریت مشتری و پیگیری‌ها
مشتری که دو ماه پیش خرید کرد و قرار بود دوباره یادآوری شود، در دفترچه مانده است. نشانه‌اش پیگیریِ فراموش‌شده است. اینجا چیزی که لازم دارید معمولاً یک CRM ساده است: جایی که تاریخچهٔ هر مشتری و کارِ بعدی‌اش یک‌جا ثبت شود.
انبار و موجودی
کالایی را می‌فروشید که دو روز پیش تمام شده. اکسل به‌روز نشده بود، چون کسی که کالا را بسته‌بندی کرد با کسی که فایل را باز میکند یکی نیست. فروشِ کالای تمام‌شده نشانهٔ کلاسیکِ نیاز به نرمافزار انبار است، یعنی جایی که هر فروش خودکار از موجودی کم کند.
کارهای تکراریِ دستی
یک اطلاعات را سه بار وارد می‌کنید: یک بار در چت، یک بار در اکسل، یک بار در نرمافزار حسابداری. این همان چیزی است که اتوماسیون برای حذفش وجود دارد. ورود دستیِ یک داده در چند جا هم زمان می‌برد و هم خطا می‌سازد.
قاعدهٔ تشخیص‌اش کوتاه است: اگر کاری با یک دستورالعمل مشخص انجام میشود و هر بار دستی تکرار میشود، کاندیدای نرمافزار است.
یک هشدار صریح هم لازم است. نرمافزار بی‌نظمیِ فرایند را حل نمی‌کند، فقط آن را سریع‌تر میکند. اگر هنوز نمی‌دانید سفارش از کجا وارد میشود، چه کسی تأییدش میکند و بعد چه میشود، اول باید همین را روی کاغذ روشن کنید. ما در این بخش هیچ وعدهٔ افزایش فروش یا صرفه‌جویی نمی‌دهیم، چون نتیجه به فرایند شما بستگی دارد، نه به خودِ نرمافزار.
وب‌سایت، فروشگاه، اپلیکیشن، نرمافزار سازمانی یا اتوماسیون: کدام به مسئلهٔ شما می‌خورد؟
این پنج اسم را اغلب به‌جای هم می‌شنوید، ولی هرکدام مسئلهٔ متفاوتی را حل می‌کنند. جدول زیر کمک میکند مسئلهٔ خودتان را به راهکارش وصل کنید.
نوع راهکار | مسئله‌ای که حل میکند | نشانهٔ مناسب‌بودن |
|---|---|---|
وب‌سایت | معرفی کسب‌وکار و ساختن اعتماد | مشتری پیش از تماس می‌خواهد شما را در گوگل ببیند و نمونه‌کار یا اطلاعات تماس پیدا کند |
فروشگاه اینترنتی | فروش و پرداخت از طریق درگاه | سفارش‌ها شکل مشخصی دارند: کالا، تعداد، آدرس، پرداخت |
اپلیکیشن موبایل | تعامل مکرر یا نیاز به امکانات گوشی | مشتری هفته‌ای چند بار برمی‌گردد یا به اعلان، دوربین یا موقعیت مکانی نیاز دارد |
نرمافزار سازمانی | فرایندهای داخلی مثل انبار، مشتری، مالی | کارمندان شما کاربر اصلی‌اند و داده در بیش از یک بخش باید جابه‌جا شود |
اتوماسیون | حذف کار تکراری بین ابزارهای موجود | ابزارها هستند ولی آدمی بین آن‌ها پیام می‌برد |
وب‌سایت و فروشگاه اینترنتی
وب‌سایت صرفاً نقش ویترین دارد. اگر فروش و پرداخت هم می‌خواهید، به فروشگاه اینترنتی می‌رسید که به درگاه پرداخت وصل است و سفارش را به‌صورت ساختاریافته ثبت میکند. برای مسیر ساخت چنین فروشگاهی می‌توانید شرکتهای طراحی فروشگاه اینترنتی را در دایرکتوری ببینید.
اپلیکیشن موبایل
اپلیکیشن همیشه از وب‌سایت بهتر نیست. اگر مشتری شما فقط گاهی سفارش می‌دهد، یک وب‌سایت خوب کافی است و نصبِ یک اپ برایش زحمت اضافه است. اپ وقتی معنا دارد که تعامل مکرر باشد یا به قابلیت‌های خودِ گوشی نیاز داشته باشید. اگر به این نتیجه رسیدید، فهرست شرکتهای طراحی و توسعه اپ موبایل نقطهٔ شروع خوبی برای بررسی است.
نرمافزار سازمانی و اتوماسیون
نرمافزار سازمانی (مثل ERP یا CRM) برای کارهای داخلی است و مشتری شما آن را نمی‌بیند. اتوماسیون چیز دیگری است: به نرمافزار جدید لازم ندارد، بلکه ابزارهای فعلی را به هم وصل میکند.
به سناریوی فرضی‌مان برگردیم. سفارش‌ها را یک فروشگاه جمع کند تا دیگر در چت پراکنده نباشند. موجودی را نرمافزار انبار نگه دارد تا هر فروش خودکار از آن کم شود. پیگیری مشتری را یک CRM ساده بر عهده بگیرد. لازم نیست هر سه را همزمان بسازید. اما این تصویر نشان می‌دهد هر مشکل به کدام راهکار می‌رسد.
پشت صفحه چه خبر است؟ فرانت‌اند، بک‌اند، پایگاه داده و API با یک مثال ساده
برای تصمیم‌گیری لازم نیست فنی بدانید، ولی چهار واژه را باید بشناسید، چون هر پیشنهاد فنی روی یکی از این‌ها سوار است. رستوران را در نظر بگیرید.
فرانت‌اند همان چیزی است که مشتری می‌بیند: منو، فرم سفارش، دکمه‌ها. سالن رستوران.
بک‌اند آشپزخانه است. سفارش آنجا پردازش میشود؛ قیمت حساب میشود، موجودی چک میشود، قوانین کسب‌وکار اجرا می‌شوند.
پایگاه داده انبار ثبت‌شدهٔ اطلاعات است: مشتری‌ها، سفارش‌ها، کالاها. جایی که هیچ چیز نباید گم شود.
API پیشخدمت است. پیام را بین بخش‌ها می‌برد و بین نرمافزار شما و دنیای بیرون هم، مثلاً درگاه پرداخت.
چرا باید بدانید؟ چون هر تغییر کار متفاوتی است. عوض‌کردن رنگ و چیدمان دکمه‌ها کار فرانت‌اند است. تغییر قاعدهٔ تخفیف یا نحوهٔ محاسبهٔ موجودی کار بک‌اند است. اتصال به سامانه‌ای دیگر کار API است. معمولاً هزینهٔ این سه با هم فرق دارد و وقتی شرکتی می‌گوید «این تغییر کوچک است»، می‌توانید بپرسید در کدام لایه.
این دانش وقتی به کارتان می‌آید که از شما بپرسند: «به نرمافزار حسابداری وصل شود؟ به سامانهٔ مودیان؟ به درگاه پرداخت؟» در واقع دارند از API می‌پرسند. جواب شما به این سؤال، کار و زمان پروژه را عوض میکند.
ساختِ یک نرمافزار از ایده تا پشتیبانی چه مراحلی دارد و کجا باید در آن حاضر باشید؟
ساخت نرمافزار با سپردن کار به یک تیم و منتظر ماندن تمام نمیشود. چهار مرحلهٔ کلی دارد و در دو تای آن، حضور شما تعیین‌کننده است.
شناخت نیاز و نوشتن نیازمندی‌ها
اینجا بیشترین سهم با شماست. شرکت می‌پرسد چه کاری، توسط چه کسی، با چه داده‌ای انجام میشود، و شما باید پاسخ بدهید. خروجی این مرحله یک سند نیازمندی‌ها (Requirements) است. در سناریوی فرضی ما، یکی از جمله‌ها می‌تواند این باشد: «وقتی سفارشی ثبت شد، موجودی همان لحظه کم شود و اگر از حدی پایین‌تر رفت، به مسئول انبار اعلان برسد.»
طراحی تجربهٔ کاربری و ساختار
طراحی UI/UX مشخص میکند کاربر چه صفحاتی می‌بیند و برای انجام هر کار چند قدم باید بردارد. طراحی خوب خطای کاربر را کم میکند. اگر کارمند انبار شما با نرمافزار دچار سردرگمی شود، به همان اکسل برمی‌گردد. در این مرحله بازخورد شما از روی نمونهٔ تصویری ارزان‌تر از تغییر بعد از ساخت است.
ساخت و تست
بهترین کاری که می‌توانید در ساخت بکنید این است که از کوچک‌ترین نسخه‌ای شروع کنید که مسئلهٔ اصلی را حل میکند. به آن می‌گویند MVP یا نسخهٔ حداقلی. در سناریوی ما شاید نسخهٔ اول فقط ثبت سفارش و کم‌شدن خودکار موجودی باشد. بقیه بعداً می‌آید. در تست هم نقش شما مهم است: تست پذیرش یعنی شما و کاربران واقعی بررسی می‌کنید که سیستم با کار روزمرهتان می‌خواند یا نه. تستی که فقط تیم سازنده انجام دهد، فقط نشان می‌دهد کد کار میکند، نه اینکه برای شما مفید است.
تحویل و پشتیبانی
پروژه با تحویل تمام نمیشود. نرمافزار باید روی هاستینگ و سرور اجرا شود، بهروزرسانی بگیرد و اگر خطایی پیش آمد، کسی پاسخگو باشد. پشتیبانی و نگهداری مرحلهٔ جداگانهای است و باید جداگانه قرارداد داشته باشد. پیش از امضا این سؤال‌ها را بپرسید:
مالکیت کد منبع با کیست؟ اگر با شرکت جدا شوید، کد در دست شماست؟
مستندات تحویل داده میشود؟ یعنی تیمِ بعدی بتواند کار را ادامه دهد.
نگهداری چه مدت و با چه شرایطی است؟ چه چیزی در آن می‌گنجد و چه چیزی کار جدید حساب میشود؟
زمان و هزینهٔ هر مرحله به اندازه و پیچیدگی پروژه بستگی دارد. هر عدد قطعی پیش از نوشتن نیازمندی‌ها حدس است، نه برآورد.
نرمافزار آماده کافی است یا باید اختصاصی بسازید؟ سه سؤالِ مرز
ما توصیه نمی‌کنیم همهٔ کسب‌وکارها نرمافزار اختصاصی بخواهند. بسیاری از آن‌ها با ابزار آماده سریع‌تر و کم‌دردسرتر شروع می‌کنند. برای اینکه ببینید شما کجا هستید، سه سؤال را به ترتیب جواب دهید.
ماتریس تصمیم
فرایند شما با دیگران در صنفتان فرق جدی دارد؟
ابزار آماده بدون دور‌زدن‌های دستی کار شما را می‌چرخاند؟
داده و منطق کارتان سرمایهٔ رقابتی شماست؟
فرایند فرق جدی دارد؟ | ابزار آماده بدون دور‌زدن کار میکند؟ | داده و منطق، سرمایهٔ رقابتی است؟ | نتیجه |
|---|---|---|---|
خیر | بله | خیر | ابزار آماده |
بله | بله | خیر | آماده با تنظیمات و افزونه |
خیر | بله | بله | آماده با تنظیمات، به شرطی که داده را بتوانید بیرون بکشید و مالکیتش با شما بماند |
بله | خیر | خیر | آماده با تنظیمات یا اختصاصی، بسته به حجم دور‌زدن‌های دستی |
هر پاسخ | خیر | بله | توسعهٔ اختصاصی |
سناریوی فرضی ما کجا می‌افتد؟ اگر فقط کالا می‌فروشد و پرداخت و ارسال معمولی دارد، احتمالاً در ردیف اول است و یک فروشگاه آماده کافی است. اگر سیستمِ قیمتگذاری یا چیدمان سفارش‌هایش منطق خاصی دارد که هیچ ابزاری بدون دور‌زدن دستی پیاده نمی‌کند، به ردیف آخر نزدیک میشود.
نشانه‌های عینی نیاز به اختصاصی را می‌توان دید:
دور‌زدن‌های دستیِ همیشگی، مثل کپی‌کردن داده از یک ابزار به ابزار دیگر هر روز.
محدودیت در اتصال به سامانه‌های ایرانی مثل درگاه‌های پرداخت داخلی یا نرمافزار حسابداری.
رشد مداوم هزینهٔ مجوزها یا افزونه‌ها، بدون اینکه مسئله واقعاً حل شده باشد.
وقتی وردپرس یا ابزار آماده جواب می‌دهد
اگر نیازتان استاندارد است و بودجه محدود، وردپرس با افزونه‌ها (از جمله ووکامرس برای فروشگاه) یا سرویس‌های SaaS معمولاً نقطهٔ شروع منطقی‌اند. برای بررسی شرکت‌هایی که روی آن کار می‌کنند، فهرست طراحی وب‌سایت وردپرس را ببینید. مقایسهٔ تفصیلی این گزینه‌ها با ساخت اختصاصی جای مقالهٔ جداگانه است و اینجا فقط مرزش را می‌گوییم.
هر دو توصیهٔ رایج یک جا شکست می‌خورند. «همیشه آماده بخر» وقتی شکست می‌خورد که داده یا فرایند شما منحصربه‌فرد است و ابزار آماده شما را به دور‌زدن‌های دستی مجبور میکند. «همیشه اختصاصی بساز» وقتی شکست می‌خورد که نیاز استاندارد است و بودجه محدود، چون پول و زمانی خرج می‌کنید که ابزار آماده از قبل داشت. راهنمای تصمیم‌گیری دقیق‌تر را در بخش راهنمای انتخاب دنبال کنید.
اشتباه‌هایی که پروژهٔ نرمافزاری را زمین می‌زند و نشانهٔ اولیهٔ هرکدام
در عمل دیده‌ایم که پروژه‌ها معمولاً با اشتباه‌های مشابهی دچار مشکل می‌شوند، و هرکدام نشانه‌ای دارد که زود دیده میشود. هیچ آماری پشت این فهرست نیست، فقط الگوهایی که بارها تکرار می‌شوند.
شروع بدون نیازمندی مکتوب. نشانه: هر هفته «یک چیز دیگر» به پروژه اضافه میشود. پیشگیری: پیش از هر کدی، نیازمندی‌ها را روی کاغذ بیاورید و امضا کنید، حتی اگر دو صفحه باشد.
خواستن همه‌چیز در نسخهٔ اول. نشانه: دامنهٔ کار بی‌پایان به نظر می‌رسد و هیچ‌کس نمی‌تواند بگوید «کی تمام میشود». پیشگیری: نسخهٔ اول را به یک مسئلهٔ اصلی محدود کنید و بقیه را فهرست بعدی بگذارید.
نبودنِ مالک داخلی. نشانه: شرکت سؤال می‌پرسد و کسی در سمت شما پاسخ نمی‌دهد، یا هر بار یک نفر دیگر نظر می‌دهد. پیشگیری: یک نفر را به‌عنوان تصمیم‌گیرندهٔ پروژه مشخص کنید که وقت واقعی برایش بگذارد.
فراموش‌کردن نگهداری. نشانه: قراردادی که بندی برای پشتیبانی بعد از تحویل ندارد. پیشگیری: پشتیبانی را جدا و مکتوب تعریف کنید.
اگر در همین چهار مورد حتی یکی را در پروژهٔ خودتان می‌بینید، زودتر اصلاحش کنید. ارزان‌ترین زمان برای رفع هرکدام ابتدای مسیر است.
چک‌لیست یک‌صفحه‌ای برای مشخص‌کردن نیاز اولیه پیش از هر گفتگو با شرکت
از اینجا به بعد دیگر توضیح نیست، کار است. این پرسش‌ها را روی یک برگه جواب بدهید. اگر نمی‌توانید به یکی جواب دهید، همان جا نشان می‌دهد پیش از مراجعه به شرکت چه چیزی باید روشن شود.
کدام کار در کسب‌وکار من هر روز یا هر هفته تکرار میشود؟
چه کسی کاربر اصلی است: مشتری، کارمند یا هر دو؟
چه داده‌ای باید ثبت شود و الان کجا نگهداری میشود؟
نرمافزار باید با چه سامانه‌هایی ارتباط داشته باشد؟ (حسابداری، درگاه پرداخت، سامانهٔ مودیان، پیامک)
چه کسی در سمت من پروژه را مالکیت میکند و تصمیم می‌گیرد؟
چه چیزی را در نسخهٔ اول لازم ندارم؟
موفقیت را چطور می‌سنجم؟
الان چه ابزارهایی دارم و کدام‌یک واقعاً کار میکند؟
پرسش هفتم را جدی بگیرید. معیار سنجش پیش از شروع باید با یک «وضعیت فعلی» ثبت شود، وگرنه بعداً نمی‌توانید بگویید چیزی بهتر شده یا نه. معیارهای معقول عددی نمی‌خواهند، فقط ثبتِ قبل و بعد را:
کاهش خطای ثبت (چند بار در هفته داده‌ای اشتباه وارد میشود؟)
کوتاه‌شدن زمان پاسخ به مشتری
دقت موجودی (چند بار کالایی فروخته میشود که نیست؟)
حالا سناریوی فرضی را با چک‌لیست جمع کنیم. کار تکراری: ثبت سفارش و بهروزرسانی موجودی. کاربر: مسئول انبار و فروشنده. داده: سفارش و موجودی کالا. اتصال: درگاه پرداخت و نرمافزار حسابداری. مالک پروژه: خود مدیر. لازم نیست در نسخهٔ اول: اپلیکیشن موبایل. معیار موفقیت: کمترین فروشِ کالای تمام‌شده و کوتاه‌ترین زمان پاسخ به مشتری، نسبت به وضعیت ثبت‌شدهٔ فعلی. با همین برگه می‌توانید با هر شرکتی گفتگو کنید و مطمئن باشید دربارهٔ چیزی حرف می‌زنید که روشن است.
قدم بعدی: چطور ارائه‌دهنده را انتخاب کنید و مقالهٔ بعدی را از کجا شروع کنید؟
اگر نتیجه گرفتید به کمک بیرونی نیاز دارید، معیار انتخاب را از پیش بدانید. ارائه‌دهنده‌ای را انتخاب کنید که:
نیازمندیهای شما را پیش از قیمتگذاری بنویسد، نه بعد از آن؛
نمونه‌کار هم‌حوزه و نظرهای راستی‌آزمایی‌شده داشته باشد؛
مالکیت کد و مستندات را در قرارداد روشن کند؛
پشتیبانی را جدا تعریف کند.
شرکتی که این چهار مورد را بدون اصرار شما پیشنهاد دهد، معمولاً با پروژه‌ها جدی برخورد میکند. شرکتی که فقط قیمت می‌دهد و از نیاز نمی‌پرسد، چیزی را زودتر به شما می‌فروشد تا بفهمد.
برای ادامهٔ مطالعه، به‌ترتیب این موضوع‌ها را بخوانید: معیار انتخاب شرکت برنامه‌نویسی، هزینهٔ طراحی اپلیکیشن، مقایسهٔ توسعهٔ اختصاصی با SaaS، و وردپرس در برابر طراحی اختصاصی. تا زمان انتشار آن مقاله‌ها، راهنمای انتخاب ما نقطهٔ شروع خوبی است.
وانوریکس مرجع مقایسه و انتخاب است و خودش نرمافزار نمی‌سازد. اگر آمادهٔ بررسی گزینه‌ها هستید، می‌توانید در دایرکتوری شرکتهای برنامه‌نویسی پروفایل‌ها، نظرهای راستی‌آزمایی‌شده و نشانهٔ «تأیید‌شده» را ببینید و با چک‌لیست همین مقاله سراغشان بروید.
پرسش‌های متداول
برای سپردن پروژه نرمافزاری به یک شرکت، خودم باید چه چیزی بدانم؟
چرا پیشنهاد قیمت شرکتهای مختلف برای یک نرمافزار اینقدر فرق دارد؟
اگر کسب‌وکارم مشمول سامانهٔ مودیان است، نرمافزار باید به آن وصل شود؟
برای ساخت نرمافزار، فریلنسر بگیرم یا شرکت؟
بعد از تحویل نرمافزار چه هزینههای ادامهداری باید در نظر بگیرم؟
به این مقاله امتیاز دهید
میانگین ۵ از ۵ (۱ رأی)
درباره نویسنده