مدیر عامل شرکت نرم‌افزار هِمِند
روش‌های بی‌اخلاقی در پروژه‌های نرم‌افزار
در طول سال‌هایی که برای افراد مختلفی کار کردیم و برنامه‌نویسان و تیم‌های دیگری را در کنار خودمان دیدیم، کارهای درست و اشتباه بسیاری مرتکب شدیم. اما امروز که اینجا ایستاده‌ایم می‌دانیم که چه کاری را باید و چه را نباید انجام دهیم. اخلاق ممکن است برای همه شرط اول نباشد اما دانستن نکات آن خالی از لطف نیست. این مطلب برای آن دسته که می‌خواهند با برنامه‌نویسان کاری کنند هم شامل نکات ریز و درشتی است که شاید گاهی آوردن آن در قرارداد طرفین لازم باشد.
بی تعهدی در پروژه
اگر بگویم مهم‌ترین موضوع در اجرای پروژه برای یک کارفرما، تعهد است، پُر بیراه نگفته‌ام. من جامعه شناس نیستم اما فکر می‌کنم در فرایند تربیتی جامعه‌ی ما وفای به عهد، خیلی کار نشده. با تجربه چند‌سال کار کردن با برنامه‌نویس‌های مختلف، باید عرض کنم که متاسفانه در این صنف هم مانند بسیاری از صنف‌ها این مسئله خیلی نمود پیدا می‌کند. به عنوان یک فعال این حوزه علاقه‌ای به بیان این مطلب ندارم. موارد زیر شاید بخشی از دلایل این بی تعهدی‌ها باشد:
- محاسبه نکردن خطاهای احتمالی در برآورد اولیه:
در نظر نگرفتن تلورانس در پروژهها باعث می‌شود که تعهد نداشتن به زمانبندی‌های ارائه شده برای برنامه‌نویسان عادی شود.
- تغییرات ناگهانی پروژه:
چابکی پروژه‌های نرم‌افزاری و توسعه برپایه بازخوردها مرحله‌ای مشتریان باعث شده تا پروژهها در خلال اجرا دائما دستخوش تغییر شوند (در اصطلاح مدیران پروژهها :خزش محدوده). این تغییرات دائمی نظم در عملکرد تیم‌های نرم‌افزاری را به هم می‌ریزد و دلیلی دیگر برای عادی شدن بی‌تعهدی به ددلاین‌های تحویلی باشد.
- عدم حضور مدیریت پروژه :
عمده برنامه‌نویسان و تیم‌های برنامه‌نویسی از اهمیت یک مدیر پروژه که تخصص مدیریت داشته باشد آگاه نیستند. بی‌نظمی نتیجه‌ای جز بی‌تعهدی و تخریب برند شما به دنبال نخواهد داشت.
- ضعف تیم‌ها در کارهای ستادی:
برنامه‌نویسان بجهت تیپ کاریشان، در کارهای اداری و مالی و حقوقی ضعیف هستند و اصطلاحا حوصله‌ی این کارها را ندارند. با توجه به اینکه ستون هر کسب و کاری مسائل ستادی آن است، برنامه‌نویسان را در دهه دوم کاریشان معمولا به عنوان کارمند می‌بینید بر خلاف شروع به کارشان که رویای خلق کردن دارند.
بی‌اخلاقی در محصول
بزرگنمایی در امکانات یک محصول نرم‌افزاری، از دسته کارهای فوق‌العاده‌ایست که بسیاری انجام می‌دهند. مدتی در یک شرکت فعال در زمینه هوشمندسازی همکاری داشتم. به طرز جالبی در فرایند فروش، از قابلیت‌های برنامه‌ریزی تجهیزات نامبرده می‌شد در حالیکه در اجرا پیاده‌سازی و تحویل مشتری نمی‌شد، با این توجیه که هر چه امکانات بیشتر شود هزینه پشتیبانی ما افزایش پیدا می‌کند (زیبا نیست؟).
زخمی کردن کار
همیشه برایم سوال بوده که چطور یک بازیگر همزمان می‌تواند در چند سریال و فیلم همزمان حضور داشته باشد. با توجه به حجم عوامل یک فیلم و برداشت‌های پس و پیش، مشاهده نحوه عملکرد یک مدیر برنامه‌ریزی در این پروژه‌های خاص برایم جالب بوده. این مدیر برنامه‌ریزی را در تیم‌های نرم‌افزاری به ندرت می‌توانید بیابید. یک تیم برنامه‌نویسی هنر کند طراح و تحلیل‌گر را در کنار خود حفظ کند. دیگر جایی برای این کارها نمی‌ماند.
روش انتخابی چه می‌تواند باشد؟ زخمی کردن؛ یعنی شما به هر شیوه‌ای که شده اعتماد کارفرما را جلب و قرارداد را می‌بندید و پیش‌پرداخت را می‌گیرید و آنچنان بلایی سر فرد یا شرکت مقابل می‌آورید که دیگر اسم یک برنامه‌نویس یا تیم تولید نرم‌افزار را شنید، فرار کند و حتی به خودش اجازه ایده‌پردازی برای خلق یک نرم‌افزار را ندهد.
خالی‌بندی در توانایی
روز اول ملاقات با کارفرما: «آقا شما هرچیزی در دنیای نرم‌افزار قابلیت اجرا داره رو به ما بسپار. نگران نباش» دوستان من می‌دانند که خود ما هم دوره‌ای از این حرف‌ها زده‌ایم (گرچه در نهایت انجام داده‌ایم) اما الان اعتقاد دارم که این در واقعیت امکان‌پذیر نیست. در نهایت، پروژه ناقص، نیمه کامل و قطعا سرشار از ناراحتی به پایان خواهد رسید.
عدم آگاه کردن کارفرما از همه هزینه‌ها ( علی‌الخصوص در پروژه‌های استارتاپی)
ما هیچ تعهدی نداریم که به مشتری بگوییم که چه هزینه‌هایی غیر از پولی که به ما می‌دهد را باید در نظر بگیرد. کارفرما شروع می‌کند به کار و هزینه‌ی ما را قدم به قدم می‌دهد. بعد ما پیشنهادات و ملزومات هزینه‌ای را یکی یکی جلوی او می‌گذاریم. سرور، امنیت سرور، مدیریت سرور، تبلیغات، تولید محتوا و بسیاری موارد دیگر که کارفرما اصلا آن‌ها را نمی‌دانسته. اصولا به ما چه ربطی دارد؟ کسی که خربزه می‌خورد پای لرزش هم باید بنشیند. در این سال‌ها به این نتیجه رسیده‌ام که حتی اگر کارفرما نیاز مالی نداشته باشد، این هزینه‌ها انگیزه او را خواهد کشت. اگر تصمیم داشتید که یک کار موفق استارتاپی ارائه دهید تا می‌توانید از آینده‌‌ای که می‌شناسید، برای مشتری بگویید.
رعایت نکردن تست‌های امنیتی
دقیقا چیزی بی‌اهمیت‌تر از امنیت در نرم‌افزار ندیده‌ام. به نظر شما چه دلیلی دارد که امنیت مورد اهمیت قرار بگیرد؟ چه کسی اصلا این سایت را می‌بیند که من برای اهمیت از مشتری پول بگیرم یا هزینه کارشناس تست و امنیت برای خودم بتراشم؟
احمقانه‌ترین حرف‌هایی که اگر روزی از کسی مثل من شنیدید، فرار کنید. شاید در ابتدای کار خیلی با اهمیت نباشد ولی حتما باید در برآوردها و برنامه‌ریزی‌های شما باشد.
آخجون کاری
این واژه در سال‌های اخیر در ادبیات خدمات به شدت آشنا و جا افتاده است. اینکه هر پروژه‌ای را بگیریم و به فکر اینکه برای باقی تعهدات ما چه اتفاقی می‌افتد نباشیم. شاید در ظاهر بی‌اخلاقی خاصی مرتکب نشده باشیم. اما در نهایت دَمار از روزگار طرف‌های مقابلمان خواهیم آورد.
استفاده از اطلاعات مشتریان
از جذاب‌ترین و غیراخلاقی‌ترین و غیر‌قانونی‌ترین کارهایی که می‌توانید در برنامه‌نویسی انجام دهید، این است که از اطلاعات درون پروژه یا سامانه برای خودتان بهره‌برداری نمایید (حتی به درست). پایه‌ای‌ترین و بی اهمیت‌ترین اطلاعات مشتری یا کارفرما نیز بدون همانگی او نباید مورد استفاده قرار گیرد.
فروش ایده/ محصول به غیر
نمی‌گوییم ایده همه چیز است. اما در صورت توافق با کارفرما مبنی بر عدم افشای آن، به هیچ عنوان حق استفاده از ایده یا ایده‌های او را نداریم. در صورت رعایت نکردن، قطعا یکی از مدال‌های بی اخلاقی را بر سینه چسبانده‌ایم.
حالت دوم هم استفاده از محصولی که یک نفر ایده و هزینه‌اش را پرداخته به نفرات بعدی‌ست. درست است که نفر اول احتمالا لایسنس نرم‌افزار را پرداخت نکرده ولی اخلاق حکم می‌کند که در همان ابتدا مشتری در جریان کار ما قرار گیرد.
عدم ارائه مستندات پروژه
چه معنی دارد که پروژه‌ای که درست کار می‌کند، مستندات داشته باشد؟
این لحنی‌ست که در صورت کار کردن با برنامه‌نویس‌های متعدد، قطعا به گوشتان خواهد خورد. کارفرما معمولا نمی‌داند که با پروژه‌ای که مستندات ندارد، عملا امکان کار با تیم دیگری را ندارد و در صورت اقدام به این کار، به احتمال خیلی زیادی، باید پروژه را با تیم جدید از نو آغاز استارت بزند. اخلاقی‌‌ست که هزینه مستندسازی دریافت گردد و مستندات ضروری پروژه به همراه پروژه تحویل گردد. آیا شما یک مداد نوکی که نوکش را فقط همان مغازه دارد می‌خرید؟
بازی با لغات
استفاده از لغات غلمبه یکی از روش‌هاییست که هر گاه در مذاکره گیری می‌افتد، میانگین استفاده از آن به شدت بالا می‌رود. اگر به جای توسعه‌ی درست محصول و خدمات‌دهی درست به کارفرما یا مشتری با لغات بازی می‌کنید و از فن بیانتان بهره می‌برید، به شما تبریک می‌گوییم. به امید حق، حتما موفق خواهید شد.
تحویل بدموقع
شما را به خدا به لوله‌کشی که می‌گویند کارش خوب است اما مشخص نیست کی می‌آید و کی تحویل می‌دهد، کاری می‌سپارید؟ اگر آری که هیچ. اگر جوابتان منفی‌ست پس انصاف داشته باشید و زمان را با احتساب تخمین خطاها درست و سر وقت بدهید.
دروغگویی در پرزنت محصول
بگذارید مصداقی بگویم. دروغ انواعی دارد: بزرگنمایی، غلو، اغراق، نگفتن حقیقت یا پنهان کاری نواقص، نداشتن شفافیت لازم و تمامی انواع آن از نظر نویسنده هم‌خانه و هم‌خانواده‌ی دروغند. روزی جمله‌ای زیبا شنیدم.
شما می‌توانید راستگو باشید یا صادق باشید؛ اما اگر حقیقت را بگویید، انسان‌ها را شیفته‌ی خود کرده‌اید. اگر آن‌ها با شما همراه شوند، هر چه بفروشید، خریدارند.
اگر در این زمینه تجربه‌ای دارید، با ما در میان بگذارید. از لایک و نظرات شما پیشاپیش سپاسگذاریم.
مطلبی دیگر از این انتشارات
برنامه‌نویسی و شب‌‌کاری
مطلبی دیگر از این انتشارات
به بهانه‌ی انتخابات هیات مدیره سازمان نصر
مطلبی دیگر از این انتشارات
شاخ گاوی به نام کسب و کار آنلاین