در نظر گرفتن تمامی کاربران یک نرم‌افزار: کلید موفقیت یک پروژهٔ نرم‌افزاری

در نظر گرفتن تمامی کاربران یک نرم‌افزار: کلید موفقیت یک پروژهٔ نرم‌افزاری

دولوپر باید کسی بیش از یک دیوانهٔ کدنویسی باشد و در سایر حوزه‌ها همچون برنامه‌ریزی‌های پروژه، تحلیل رقبا، نیازسنجی و غیره نیز سهیم باشد و دخالت کند؛ اما سوال اینجا است که آیا نسل جدید دولوپرها، برای ایفای نقش در حداقل ۲ حوزهٔ برنامه‌نویسی و تحلیل (بازار) آماده هستند؟ گرچه شاید برخی دولوپرها را بتوان یافت که در این ۲ حوزهٔ حرف‌هایی برای گفتن دارند، اما اکثرا فاقد این آمادگی هستند و همین می‌شود که بسیاری از پروژه‌های نرم‌افزاری آن‌طور که بایدوشاید، به خوبی به‌پیش نمی‌روند! آنچه در این مقاله قصد داریم مورد بررسی قرار دهیم، این است که دولوپرها و برنامه‌نویسان چگونه می‌توانند به مهارت‌هایی به غیر از کدنویسی دست یابند که ضامن موفقیت‌های بیشتر ایشان در پروژه‌های نرم‌افزاری باشد. برای یافتن پاسخ به این سوال، در ادامه با سکان آکادمی همراه باشید.

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

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

این رویکرد یک همراهی و همکاری در سطح متوسط است که بودن آن به مراتب از نبودنش بهتر است! اما عملا برای تضمین موفقیت یک پروژهٔ ساده -چه رسد به پروژه‌های بزرگ و پیچیده- کافی نیست؛ اجازه دهید برای درک بهتر این موضوع، مثالی از دنیای واقعی بزنیم:

در نظر بگیرید دولوپری هستید که برای یک شرکت نرم‌افزاری که تخصصش در زمینهٔ طراحی پورتال‌های سازمانی است کد می‌زنید؛ صاحب پروژه‌ای هم که شما در تیم کدنویسی آن در نظر گرفته‌ شده‌اید، یک بیمارستان خصوصی است به طوری که این نرم‌افزار به مدیران بیمارستان کمک می‌کند تا برنامه‌ریزی و مدیریت شیفت‌های پرستاران و پزشکان بهبود یابد. حال کمی فکر کنید تا ببینید مهم‌ترین فرد و صاحب پروژه و افراد هدف در این سناریو چه کسانی هستند؟

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

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

برای انجام این کار، شما باید میان این 3 مورد تعادلی ایجاد کرده و سپس باید به قول‌هایی که داده‌اید عمل کنید. تا اینجای کار، ما تنها نیمی از راه را طی کرده‌ایم و اگر جلوتر نرویم، نمی‌دانیم آیا واقعا تلاش‌هایمان نتیجه خواهد داد یا خیر؟ در همین راستا، یکی از مهم‌ترین مواردی که می‌تواند در این پروژه به شما کمک کند تا مدیریت برنامه‌ریزی را ساده‌تر کرده و یک نتیجهٔ تجاری خوب نیز کسب کنید، این است که نیاز‌های پزشکان و پرستاران را در نظر بگیرید.

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

- در صورت هرگونه تغییر در برنامهٔ ویزیت پزشک، بیماران چگونه اطلاع‌رسانی می‌شوند؟ آیا آن‌ها می‌توانند در صورت تغییر پزشک، همچنان وقت دیگری برای ملاقات با پزشک مورد نظر داشته باشند؟

- آیا ابزار برنامه‌ریزی و زمان‌دهی به‌قدری خوب کار خواهد کرد که زمان‌های خالی را به‌طور مناسب پر کند؟ یا این‌که به دلیل حجم زیاد درخواست‌ها و کمبود نیرو، بیماران زمان‌های زیادی را معطل خواهند شد؟

- آیا این قابلیت، کیفیت خدمت‌رسانی به بیماران را بهبود می‌بخشد و یا این‌که تنها برای مدیریت بهتر مفید واقع خواهد شد؟ آیا ابزاری وجود دارد تا به هر ۲ مورد دست پیدا کند؟

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

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

حال نوبت به نظرات شما می‌رسد؛ آیا برای شروع یک پروژهٔ نرم‌افزاری بلافاصله شروع به کدنویسی می‌کنید یا چند هفته‌ای را به تحلیل پروژه از زوایای مختلف و صحبت با تمامی ذی‌نفعان و در نهایت شروع کدنویسی می‌پردازید؟ نظرات و دیدگاه‌های خود را با ما و سایر کاربران سکان آکادمی به اشتراک بگذارید.

منبع


سعید نصیری