آیا اریک در ایران موفق می‌شود؟

این مقاله‌ی ترجمه شده در اپاتان بدجوری افکار منو به هم ریخته! حلقه‌های گمشده‌ی شرکت‌های نرم‌افزاریِ ایرانی کم بود، یکی دیگه هم اضافه شد!

در مقاله‌ی فوق، آقایی به‌نام Eric روش خودش برای اداره کردن یک شرکت نرم‌افزاری رو بیان می‌کنه؛ خصوصیات روش رو از همین لینک بخونید (باضافه‌ی کامنت‌ها)، و وقتی برگشتید به این سؤال من پاسخ بدید: بنظرتون این الگو کمی آشنا نیست؟ آیا این همون چیزی نیست که در اکثر شرکت‌های نرم‌افزاریِ ایرانی داره اتفاق میافته؟

بذارید از قبل پیش‌بینی کنم که جوابتون چیه: بله، کاملاً!

اگر صاحب مقاله روشش رو بدرستی توضیح داده باشه، و اگر هم واقعاً آنگونه که ادعا کرده روشی کارآمد باشه (البته با درنظر گرفتن شرایطی که همون اول تأکید کرده) و با توجه به این‌که اکثریت شرکت‌های ایرانی از چنین الگویی تبعیت می‌کنند، ما با چند سؤال روبرو هستیم: 1- آیا لزوماً چنین روشی باید نتیجه‌ی مثبتی داشته باشه؟ 2- در اینصورت، چرا چنین روشی در مورد شرکت‌های ایرانی مؤثر نیست؟

پیرو پست قبلی، قصد داشتم مطلبی بنویسم و «عدم وجود تعاریف دقیق شغلی» در شرکت‌های نرم‌افزاری رو به عنوان یکی از معضلات اصلی ذکر کنم. حالا جناب Eric منو راحت کرد و مفهوم دقیق «عدم وجود تعاریف دقیق شغلی» رو بین همه‌ی ما جا انداخت! این یعنی این‌که اکثر اوقات مرزبندی دقیقی برای “وظایف/مسؤولیت‌ها/اختیارات” شغلی وجود نداره.

 

بیایید چنین موقعیتی رو از چند زاویه‌ی مختلف بررسی کنیم:

الف – یک برنامه‌نویسِ نسبتاً بدبین(!): ایشون این قضیه رو معادل می‌دونه با روشی برای فرار از پرداخت حقوقی که متناسب با جایگاه واقعیِ خودش در شرکت هست. ببینید، شما فردی را بعنوان برنامه‌نویس استخدام می‌کنید و حوزه‌ی وظیفه‌ی وی رو بصورت واضح براش تصویر نمی‌کنید. با کمی اضافه کردن چاشنیِ «این‌جور مواقع خودت یه فکری به حالش بکن» در برخوردهایی که با وی دارید، می‌تونید از وی بعنوان مدیرِ یک تیم 4-5 نفره‌ از برنامه‌نویسان؛ بعنوان یک تست‌کننده؛ بعنوان مسؤول ارتباط با مشتری؛ و بطور کلی بعنوان کسی که گویا درصدی از سود پروژه را با شما شریک است و در نتیجه باید به اندازه‌ی شما برای پروژه دل بسوزاند، از او انتظار داشته باشید، اما هم‌چنان پرداخت‌های مالی‌تان به او در حد همان برنامه‌نویس (و یا کمی بیشتر) باقی بماند!!!

 

ب – مدیر یک شرکت نرم‌افزاری:‌ ایشون تعدادی برنامه‌نویس (*) در استخدام شرکتش داره. احساس می‌کنه بعضی از اون‌ها با استعداد هستن و نباید براشون حد و مرزِ خاصی قایل شد و در ریزترین جنبه‌های کاریِ‌ اون‌ها وارد شد. در نتیجه با هماهنگیِ مدیرِ پروژه (گویا مدیر پروژه سرش خیلی شلوغه و به همه‌ی کارهاش نمی‌رسه)، بتدریج آزادیِ عمل بیشتری به اون‌ها میده. بخشی از سیستم رو مستقیماً دست اون‌ها میسپره و با این دید که خودشون از پسِ کار بر میان، فقط سرنخ رو در اختیارشون قرار می‌ده: مثلاً این‌که یه تعریف کلی از سیستم نهایی در اختیارشون قرار می‌ده و چون می‌دونه که اون‌ها افراد باهوشی هستن، بقیه‌ی کار رو کلاً واگذار می‌کنه بهشون. این‌که جزییات نیازمندی‌های سیستم چیه، طراحی‌اش چطوری باشه، چطوری پیاده‌سازی بشه، از چه جهاتی تست بشه و غیره، همش رو می‌سپره دست اون‌ها.

…

پ و ت و بقیه‌ی حالت‌ها بماند برای بعد. من فقط قصد داشتم یک سناریوی محتمل رو براتون تصویر کنم. سناریویی که بارها اتفاق افتاده و باز هم خواهد افتاد. اصلاً بیایید برای راحتی، فرض کنیم که برنامه‌نویسِ سناریوی ما، بدبین نیست و بعد از گذشت زمان، حس بدی نسبت به این قضیه پیدا نمی‌کنه. این‌طوری تحلیل صورت مسأله‌ی ما ساده‌تر می‌شه. خب، بنظرتون در همچین سیستمی چه اشتباهاتی ممکنه رخ بده؟ اگه تصادفاً یکی از این افراد، بخشی از حوزه‌ی سیستم (domain) رو درست متوجه نشده باشه، چه اتفاقی میافته؟‌ آیا در شرکت کسی بوده که domain expert باشه و متناوباً طراحی‌ها و پیاده‌سازی‌ها رو با تعریف اصلی از صورت مسأله انطباق بده؟ آیا این سیستم همون چیزیه که کاربر می‌خواد؟‌ چه جور تست‌هایی این برنامه رو تصدیق (verify) می‌کنن؟‌ مسوؤلیت تولید سناریوهای تست با کیه؟ با همون برنامه‌نویسه؟ یا یکی دیگه از برنامه‌نویس‌های همون تیم؟ یا این‌که سناریوهای تست رو فردی که با کاربران مواجهه‌ی مستقیم داره و دیدگاه اون‌ها رو می‌شناسه تهیه کرده؟ …

 

قانون کلی صادر کردن برای نرم‌افزار خیلی سخته. نه می‌شه از جزء به کل رسید (مثلاً با دیدن سناریوی فوق، نتیجه‌ گرفت که چنین روشی لزوماً به شکست یا موفقیت نتیجه می‌شه)، و یا این‌که مثل بعضی از این فلاسفه، بعد از کلی تفکراتِ انتزاعی، یه قانون کلی صادر کرد که برای همه‌ی حالت‌ها صادق باشه! تنها کاری که می‌شه انجام داد، پیگیری مداوم و دقت در هر سناریویی است که باهاش مواجهیم. داشتن حس ششم قوی هم اکیداً توصیه می‌شه! دیده شده که شرایط بعضی از موفقیت‌ها یا شکست‌ها رو  نمی‌شه چندان با منطق توجیه کرد. هیچ دلیلی هم وجود نداره که اگه یکبار دیگه همون الگو رو استفاده کردیم، با همون پاسخ مواجه بشیم. این وسط حتی اگه همه‌ی شرایط هم یکسان باشه، یه چیز یکسان نیست: روحیه‌ی افراد تیم.

 

—————————

* – من کلمه‌ی “برنامه‌نویس” را آن‌گونه که نویسنده‌ی مقاله بکار برده، استفاده نکردم. منظور من از برنامه‌نویس، همون مفهومیه که تابحال هممون با شنیدنش در ذهنمون تصویر می‌کردیم. در مورد این واژه‌ها قصه‌ی جداگانه‌ای دارم که بعداً تعریف می‌کنم!

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