شاید اغراق نباشد اگر بگوییم یک توسعه‌دهندهٔ واقعی نرم‌افزار کسی است که به غیر برخورداری از مهارت کدنویسی، در سایر حوزه‌ها همچون مدیریت پروژه، تحلیل رقبا، نیازسنجی و غیره هم سهیم باشد و اظهار نظر کند؛ اما سؤال اصلی اینجا است که آیا اکثر دولوپرها برای ایفای نقش در حداقل دو حوزهٔ کدنویسی و تحلیل پروژه آماده‌اند؟ گرچه شاید برخی دولوپرها را بتوان یافت که در این دو حوزهٔ حرف‌هایی برای گفتن داشته باشند، اما اکثراً فاقد این آمادگی هستند و همین می‌شود که بسیاری از پروژه‌های نرم‌افزاری آن‌طور که باید و شاید به خوبی پیش نمی‌روند! در همین راستا، آنچه در این مقاله قصد داریم مورد بررسی قرار دهیم این است که دولوپرها و برنامه‌نویسان چگونه می‌توانند به مهارت‌هایی به غیر از کدنویسی دست یابند که ضامن موفقیت‌های بیشتر ایشان در پروژه‌های نرم‌افزاری گردد.
Product Owner واقعی کیست؟
اگر بخواهیم رُک صحبت کنیم، بایستی بگوییم که بسیاری از برنامه‌نویسان این قابلیت را دارا هستند تا در زمینهٔ نیازسنجی پروژه نیز فعال باشند چرا که آن‌ها می‌دانند برای حل یک مسأله باید به خوبی آن را درک کرده و متوجه زیر و بم آن شد. در واقع، برای این کار باید مدتی در زمینه‌های مرتبط تحقیق کرده و در کنار آن‌ها، می‌بایست درک بالایی از نیازها و انگیزه‌های سفارش‌دهندهٔ نرم‌افزار و اهداف پروژه داشت. اما مشکلی که با آن برخورد می‌کنیم -که معمولاً نقطهٔ کوری است که کمتر دیده می‌شود- این است که ما به عنوان دولوپر معمولاً کسی را که فیش حقوقی پایان ماه را تأیید می‌کند و یا گزارش عملکرد ما را چک می‌کند به عنوان صاحب اصلی پروژه یا به اصطلاح Product Owner می‌پنداریم.
به عبارت دیگر، فعالیت‌های خود را بر اساس انتظارات آن‌ها -که معمولاً مدیرعامل شرکت یا مدیران میانی است- شکل می‌دهیم و سعی می‌کنیم تا میان آنچه یک کار خوب و آنچه آن‌ها را خوشحال می‌کند تعادلی برقرار کنیم و وقتی هم این کار را خوب انجام دادیم، در ازای آن پاداش دریافت می‌کنیم!
این رویکرد یک همراهی و همکاری در سطح متوسط است که بودن آن به مراتب از نبودنش بهتر است! اما عملاً برای تضمین موفقیت یک پروژهٔ ساده (چه رسد به پروژه‌های بزرگ و پیچیده) کافی نیست! اجازه دهید برای درک بهتر این موضوع، در ادامه مثالی از دنیای واقعی بیاوریم.
فرض کنیم قرار است یک نرم‌افزار بیمارستانی بنویسیم!
در نظر بگیرید دولوپری هستید که برای یک شرکت نرم‌افزاری که تخصصش در زمینهٔ طراحی پورتال‌های سازمانی است کد می‌زنید. صاحب پروژه‌ای هم که شما در تیم کدنویسی آن در نظر گرفته شده‌اید، یک بیمارستان خصوصی است به طوری که این نرم‌افزار به مدیران بیمارستان کمک می‌کند تا برنامه‌ریزی و مدیریت شیفت‌های پرستاران و پزشکان بهبود یابد. حال کمی فکر کنید تا ببینید مهم‌ترین فرد، صاحب اصلی پروژه و گروه هدف در این سناریو چه کسانی هستند؟
مدیر آیتی بیمارستان فوق‌الذکر از شما می‌خواهد قابلیتی ایجاد کنید که برنامهٔ شیفت‌های بیمارستان را در مقابل لیست وقت ویزیت‌های آن‌ها چک کند و با این کار می‌خواهد سطح عملکرد کارکنان در شیفت‌های مختلف حفظ شود. شما به خوبی دربارهٔ این کار توجیه شده‌اید و می‌توانید هر سؤال یا پیشنهادی را قبل از شروع به کار بپرسید اما واقعیت امر آن است که وقتی می‌توان برچسب موفق روی این پروژهٔ نرم‌افزاری زد که هر سه شرط زیر برآورده شود:
- مدیر آیتی از قابلیتی که شما ایجاد کرده‌اید رضایت داشته باشد.
- این قابلیت با بودجه‌ای توسعه یافته که سهام‌داران بیمارستان آن را قبول دارند.
- و بودجهٔ اختصاص یافته ارزش زمانی که بر روی این پروژه صرف می‌شود را داشته است.
برای انجام این کار، شما باید میان این سه آیتم تعادلی ایجاد کرده، سپس به قول‌هایی که داده‌اید عمل کنید. تا اینجای کار، ما تنها نیمی از راه را طی کرده‌ایم و اگر جلوتر نرویم، نمی‌دانیم آیا واقعاً تلاش‌هایمان نتیجه خواهند داد یا خیر؟ در همین راستا، یکی از مهم‌ترین مواردی که می‌تواند در این پروژه به شما کمک کند تا مدیریت پروژه را ساده‌تر کرده و یک نتیجهٔ تجاری خوب نیز کسب کنید، این است که نیازهای پزشکان و دیگر کادر فنی همچون پرستاران را هم در نظر بگیرید.
اما سؤالی که اینجا پیش می‌آید این است که آیا کاربران اصلی این پروژه پزشکان و پرستاران هستند؟ البته که خیر! گرچه ایشان از اهمیت بالایی برخوردارند، اما یک گروه بسیار مهم دیگری نیز وجود دارد تا به آن‌ها خدمات عالی ارائه دهید و اعضای این گروه کسانی نیستند جز بیماران. اگرچه بیماران در لایه‌های پایانی این چرخه قرار دارند، اما آن‌ها افرادی هستند که تعیین می‌کنند کاری که شما انجام داده‌اید، مفید بوده و یا اینکه اساساً تأثیری در پروسهٔ کاری سه‌گانهٔ بیمارستان-پزشک-بیمار نداشته است! با فرض قبول کردن این مسئله، حال با یکسری سؤال دیگر روبه‌رو خواهیم شد که عبارتند از:
- در صورت هرگونه تغییر در برنامهٔ ویزیت پزشک، بیماران چگونه اطلاع می‌یابند؟ آیا آن‌ها می‌توانند در صورت تغییر پزشک، همچنان وقت دیگری برای ملاقات با پزشک مورد نظر داشته باشند؟
- آیا ابزار برنامه‌ریزی و زمان‌دهی به‌قدری خوب کار خواهد کرد که زمان‌های خالی را به طور مناسب پُر کند؟ یا اینکه به دلیل حجم زیاد درخواست‌ها و کمبود نیرو، بیماران زمان‌های زیادی را معطل خواهند شد؟
- آیا این قابلیت کیفیت خدمت‌رسانی به بیماران را بهبود می‌بخشد و یا اینکه تنها برای مدیریت بهتر کادر فنی مفید واقع خواهد شد؟
رمز موفقیت یافتن رَگ‌خواب مشتری در پروسهٔ توسعهٔ نرم‌افزار است!
با شناخت تمامی این موارد و نیازها، شما مجبور می‌شوید به نقطه‌ای که از آن شروع کردید بازگشته و در مسیر انجام پروژه، ذی‌نفعان را نسبت به کارهایی که انجام می‌شود راضی کرده و در کنار آن، انتظارات ایشان را نیز برآورده سازید. برای انجام این کار، باید با هر یک از ایشان (پزشکان، مدیران، پرسنل اجرایی و بیماران) با روش و رویکرد مختلفی ارتباط ایجاد کنید، چرا که هر یک از آن‌ها به قول معروف رَگ‌خواب و نیاز متفاوتی دارند (پیش از این در مقاله‌ای تحت عنوان چند درسی که دولوپرها از حضور در بیمارستان می‌توانند بگیرند! به تجربیاتی اشاره کردیم که دولوپرها می‌توانند از فضای بیمارستانی بگیرند.)
چنین کاری به نظر سخت می‌آید؟ بله، واقعاً کار سختی است اما این همان درک و همکاری متقابل می‌باشد و همین مورد است که پروژه‌های نرم‌افزاری موفق را از دیگر پروژه‌ها متمایز می‌کند چرا که با در نظر گرفتن نیازهای تک‌تک ذی‌نفعان پروژه، می‌شود #تجربهٔ کاربری خوبی برای تمامی یوزرها به وجود آورد. به عبارت دیگر، شما به عنوان یک دولوپر حرفه‌ای می‌بایست در حین فرایند کدنویسی پروژهٔ اتوماسیون این بیمارستان، گاهی خود را جای مدیر آیتی گذاشته، گاهی جای پزشک و گاهی هم جای بیمار تا بتوانید با دید بازتری به نیازهای تک‌تک ایشان واقف گردید.
حال نوبت به نظرات شما می‌رسد. آیا برای شروع یک پروژهٔ نرم‌افزاری بلافاصله دست به کد می‌شوید یا چند هفته‌ای را به تحلیل پروژه از زوایای مختلف و صحبت با تمامی ذی‌نفعان و در نهایت شروع کدنویسی می‌پردازید؟ نظرات، دیدگاه‌ها و تجربیات خود را با سایر کاربران سکان آکادمی به اشتراک بگذارید.
