تحلیل و بررسی نیازها

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

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

مستندات

این مرحله برای ارائه راهی برای مستندسازی راه حل و الزامات پروژه است و باید شامل همه چیزهایی باشد که در طول توسعه مورد نیاز است و بررسی های کمی را ارائه می دهد: اقتصادی، حقوقی، عملیاتی، فنی و برنامه زمانی، کم و بیش.

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

طرح

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

کد نویسی

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

من اغلب می بینم که در جایی که نسخه MVP ویژگی یا تحویل را پیدا می کنید و آن را پیاده سازی می کنید، پلان B اعمال می شود و بعداً به آن بازمی گردید، جایی که بعد از تحقیقات مفصل زیاد، ویژگی را بیشتر بهبود می بخشید. نمایش باید ادامه یابد و پس از حرکت قطار، برداشتن واگن دشوار است.

کدگذاری ممکن است با پیروی از یک مدل توسعه چابک انجام شود که در آن ویژگی‌ها در اسپرینت ارائه می‌شوند، در برنامه‌ریزی‌های اسپرینت برنامه‌ریزی می‌شوند و به‌روزرسانی‌های روزانه مهندس در استندآپ‌های روزانه دریافت می‌شوند. تیم توسعه مجموعه‌ای از ویژگی‌ها و باگ‌ها را نگه می‌دارد تا بین آن‌ها توزیع کند و آنها را در هر اسپرینت برطرف کند که معمولاً 2 هفته طول می‌کشد.

تست کدها

وقتی کد انجام شد، مرحله آزمایش است. من در مورد تست‌های واحد صحبت نمی‌کنم، زیرا این آزمایش‌ها باید در مرحله کدگذاری اتفاق بیفتند، چه از تکنیک توسعه مبتنی بر تست استفاده کنید یا نه. مرحله آزمایش برای QA و E2E (گاهی اوقات) است. این تست ها بعد از کدگذاری 100% موارد انجام نمی شود. آنها با تکمیل قسمت های مختلف اتفاق می افتند.

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

انتشار

اگر همه چیز کدگذاری شده، تست شده و درست به نظر می رسد، مستقر می شود، اما به این معنی نیست که کار توسعه دهندگان و آزمایش کنندگان کامل شده است. سپس QA چیزهایی را در تولید آزمایش می‌کند زیرا محیط‌های تولید و توسعه متفاوت هستند و دوباره، هر چیزی که شکسته شده است نیز ارسال می‌شود تا توسط توسعه‌دهندگان تعمیر شود.

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

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

پشتیبانی مشتری حتی ممکن است توسعه دهندگان نیز باشند. برخی از شرکت‌ها از مفهوم داشتن توسعه‌دهندگان "در حال تماس" برای هر گونه مسائل مربوط به کاربر استفاده می‌کنند. معمولاً شرکت‌های کوچک این کار را انجام می‌دهند و این مهندسان حتی در ساعات غیر اداری هم در خدمت هستند.

نگهداری

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

پشتیبانی

نکته ای که باید به آن توجه کرد این است که مرحله کدگذاری اغلب کوچک است. برنامه ریزی و زمان پشتیبانی زیادی برای تحویل محصول اختصاص داده شده است. من در شرکت‌هایی کار می‌کردم که ۲ سال و نیم طول کشید تا یک محصول را تحویل دهیم و همچنین شرکت‌هایی که بسته به نوع محصول ۳، ۶ یا ۹ ماه طول می‌کشید. صرف نظر از زمان لازم برای ارائه نرم افزار، همه آنها یک چرخه توسعه نرم افزار را دنبال می کنند یا سعی می کنند آن را دنبال کنند.

 نتیجه

اندازه پروژه نباید مهم باشد، چه پروژه جانبی باشد یا یک پروژه آزاد. همیشه باید سعی کنید از یک برنامه پیروی کنید و آن را خوب کنید. مراحل تمرکز شما را محدود می کند و به شما امکان می دهد محصولی را به صورت ناخواسته تحویل دهید که شما را در مسیر حرکت و رضایت شما حفظ می کند.

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