ساختار تیم‌های مدرن نرم‌افزاری قسمت ششم: ارتباط با مشتریان

ساختار تیم‌های مدرن نرم‌افزاری

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

این آخرین نوشته در سری نوشته ساختار تیم‌های مدرن نرم‌افزاری است.


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

شنیدن و انتخاب کردن
تیم‌های مدرن نرم‌افزاری، حرف مشتریان را می‌شنوند. پیشتر درباره اینکه چطور به ساز همه نرقصیم در مطلب استفاده از فیدبک کاربران، صحبت کردیم. واقعیت این است که اگر محصول نرم‌افزاری شما به اندازه کافی با نیاز بازار متناسب نباشد، مثل هر کالای دیگر فروش نخواهد رفت. انحصار در ارائه خدمات نرم‌افزاری در طلایی‌ترین دورانش (تلاش‌های انحصارطلبانه مایکروسافت) هم نتوانسته است بازار را راضی کند. اکنون در دوره‌ای هستیم که چند جوان علاقمند و پرتلاش می‌توانند در مدت نسبتاً کوتاهی، سرویس نرم‌افزاری بین‌المللی ارائه کنند.
در این شرایط اگر درب دریافت پیشنهادات و انتقادات تیم شما به روی مشتریان بسته است، به زودی منتظر پایان تلخ کار خود باشید!
نمودار زیر ۲۰ دلیل اصلی شکست استارتاپ‌ها را بررسی می‌کند که در صدر آن «نادیده گرفتن مشتریان» است. گاهی اوقات، نیت «گوش کردن به مشتری» در تیم‌ها هست اما ابزار و بستر آن وجود ندارد. مطمئن شوید که راه شفافی برای ارتباط با مشتریان خود دارید و به آن‌ها گوش کنید.

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

درد مشتری، درد من است
پیش از ادامه، لازم است روشن کنم وقتی از ارتباط مشتری با یک تیم مدرن نرم‌افزاری صحبت می‌کنیم، منظور این نیست که برنامه‌نویسان تیم مدام در حال پاسخگویی به تلفن مشتریان باشند!
در واقع بدترین کاری که می‌توانید انجام دهید این است که ارتباط مستقیمی بین درخواست مشتری و برنامه‌نویسان برقرار کنید. حداقل یک نفر/تیم دیگر این وسط لازم است تا درخواست‌ها و ارتباطات را پایش کرده و همانطور که در بالا اشاره شد، حرف مشتری را بشنود و امکانات موثر برای مشتری را انتخاب کند.
اما با وجود ارتباط غیرمستقیم، باید «درد مشتری» به تیم منتقل شود. اگر مشتری برای دریافت قابلیتی در حالت اضطرار قرار گرفته (نباید با عجله عمومی مشتریان اشتباه گرفته شود) باید این اضطرار در اجرا به تیم هم منعکس شود. تیم نرم‌افزاری باید از تاثیر خروجی کارش بر کسب و کار مشتری آگاهی داشته باشد.

راه حل جدید برای مشکلات قدیمی
به این سناریو توجه کنید: پروژه‌ای را به اتمام رسانده‌اید، کار تحویل شده و پول هم توسط مشتری پرداخت شده. مدتی بعد یک روش جدید برای اجرای همان پروژه پیدا می‌کنید یا از نظر فنی، راه‌های جدیدی برای رفع مشکلات مشتری پیدا می‌شود. چه می‌کنید؟
همواره به فکر به روزرسانی نرم‌افزاری مشتریان باشید. فناوری‌های تولید نرم‌افزار هر روز بهتر می‌شوند. فناوری بهتر در تولید، باعث افزایش سرعت تولید و حتی افزایش کیفیت تولیدات نرم‌افزاری می‌شود. از این فرصت استفاده کنید و به مشتری پیشنهاد ارتقاء بدهید. 

ارتباط داده محور به جای حدس و گمان
اگر مسئول سرویس نرم‌افزاری هستید که با مشتریان زیادی در ارتباط است، چطور کارآمد بودن سرویس خود را اندازه می‌گیرید؟ شاید بگویید با «شنیدن از مشتریان» 
واقعیت این است که بعضی حرف‌های مشتریان، از رفتار آن‌ها شنیده می‌شود. برای شنیدن این حرف‌های رفتاری، باید رفتار مشتریان را لاگ و آنالیز کنید.
در این حالت ارتباط شما با مشتریان به جای آن‌که بر اساس حدس و گمان باشد، بر پایه داده‌های حاصل از رفتار آن‌ها در نرم‌افزار است. کجا کلیک می‌کنند؟ چه صفحاتی را بیشتر می‌بینند؟ کجای نرم‌افزار کم باز می‌شود؟ و سوالاتی از این دست به شما کمک می‌کند تا ببینید UI‌ و UX نرم‌افزار و ارتباط شما با مشتری در چه وضعیتی است.

امیدوارم مجموعه مباحث مطرح شده در خصوص ساختار تیم‌های مدرن نرم‌افزاری مورد توجه شما قرار گرفته باشد. مثل همیشه پذیرای نظرات خوب شما هستیم.

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

ساختار تیم‌های مدرن نرم‌افزاری قسمت پنجم: جلسات نرم‌افزاری

ساختار تیم‌های مدرن نرم‌افزاری

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

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

جلسات نرم‌افزاری: خوب، بد، زشت

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

جلسات نرم‌افزاری برگزار می‌شوند تا مطمئن شویم همه اعضای تیم درک مشابهی از کلیت کار دارند و جزئیات وظایف خود را به درستی فهمیده‌اند. این خوبی جلسات است. بدی آن اتلاف وقتی است که به همراه می‌آورند و زشتی آن جایی است که اثربخش نیستند!

جلسات نرم‌افزاری در تیم‌های مدرن

مجدداً نقل قولی که از موسس گیت‌هاب (تام پرستون) داشتیم را با هم نگاه کنیم:

"در گیت هاب ما جلسه نداریم، روز یا ساعت کاری مشخصی نداریم، دنبال ثبت و رهگیری روزهای مرخصی یا بیماری افراد نیستیم، مدیر یا چارت سازمانی نداریم"

این نگاه به کار به نظر شما چقدر واقعی است؟ چقدر از آن در ایران امکان‌پذیر است؟ واقعیت این است که حذف ۱۰۰ درصد جلسات امکان‌پذیر نیست اما شما می‌توانید با دو راهکار استفاده بهتری از جلسات ببرید:

۱- شفاف‌سازی از طریقی غیر از برگزاری جلسه
۲- برگزاری جلسه با دقت به عوامل بهبود بازدهی جلسه

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

شفاف سازی از طریق تخته فیزیکی

یکی از کارهایی که صرفنظر از روش مدیریت پروژه خود و حتی بدون توجه به اصول اسکرام می‌توانید انجام دهید، استفاده از یک تخته فیزیکی و sticky note برای نوشتن وظایف جاری و تعیین وضعیت آن‌هاست. روی این تخته‌ها معمولاً سه ستون ToDo, Doing و Done وجود دارد که هر وظیفه بین ‌‌آن‌ها جابجا می‌شود.


اگر از این روش استفاده می‌کنید، یک گزینه دیگر هم دارید: استفاده از نرم‌افزارهای مشابه مثل TFS یا سرویس آنلاین آن که مزیت آن این است که می‌توانید علاوه بر عنوان و زمان اجرا توضیحات بیشتری هم درباره task بنویسید یا فایل مرتبطی را پیوست کنید و همچنین آرشیو یکپارچه‌ای از وظایف هر دوره و زمان اجرای آن‌ها داشته باشید.

شفاف سازی از طریق کد

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

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

ادامه دارد...

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

پنج دلیل اصلی (اشتباه) که شما تست کننده نرم‌افزار ندارید

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

دلیل اشتباه اول: باگ‌ها توسط برنامه‌نویسان تنبل ایجاد می‌شوند

دید اشتباه این هست که "اگر تست‌کننده نرم‌افزار استخدام کنیم" آن‌‌گاه "برنامه‌نویس‌ها، تنبل می‌شوند و کدهای باگ‌دار تولید می‌کنند. با استخدام نکردن تست‌کننده نرم‌افزار، برنامه‌نویسان مجبور می‌شوند که از همان اول کد خوب و بی‌باگ ایجاد کنند"

واقعیت این است که باگ‌ها، به این خاطر ایجاد می‌شوند که برنامه‌نویس آن‌ها در کد خودش ندیده است و برای دیدن باگ‌ها در اغلب اوقات به یک جفت چشم دیگر هم نیاز هست. جوئل به خاطراتی از خودش اشاره می‌کند که زمانی که برنامه‌نویسی می‌کرده، از عادت‌‌های خودش برای تست نرم‌افزارها استفاده می‌کرده و مثلاً خیلی با Mouse کار می‌کرده است. بخش تست اما بیشتر با keyboard کار می‌کردند. نتیجه این شده که بخش‌های از برنامه وقتی با keyboard با آن‌ها کار می‌شده اصلاً کار نمی‌کرده است!

دلیل اشتباه دوم. برنامه من تحت وب است و هر باگی را در چند ثانیه می‌توانم حل کنم

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

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


عواقب استفاده از محصولی که به درستی تست نشده ممکن است جبران ناپذیر باشد: صحنه معروف کلاه‌ها در فیلم پرستیژ

دلیل اشتباه سوم: مشتریان، نرم‌افزار را برای من تست خواهند کرد

جوئل در توضیح اشتباه بودن این دلیل، متدولوژی مسخره netscape برای تست نرم‌افزارهایش (که به قول جوئل به شکل ماورا‌ الطبیعی به اعتبار شرکت صدمه وارد کرد) را توضیح می‌دهد:

  • وقتی برنامه‌نویسان، هنوز نیمی از کار را انجام دادند، نرم‌افزار را بدون تست در وب منتشر کن
  • وقتی برنامه‌نویسان می‌گویند که کار تمام شده، نرم‌افزار را بدون تست در وب منتشر کن
  • این کار را شش هفت بار تکرار کن
  • یکی از نسخه‌هایی که با این روش منتشر کردی را "نسخه نهایی" نام‌گذاری کن
  • هر دفعه که به یک باگ که باعث شرمساری می‌شود در سایت cnet اشاره شد،‌ نسخه‌های 0.1,0.2,0.3 را منتشر کن!
نتیجه این روش این شد که مشتریان بسیار زیادی در دنیا، همیشه و همیشه با نرم‌افزارهای باگ‌دار netscape کار کردند و این باعث شد حتی وقتی که نسخه نسبتاً بی‌باگی از نرم‌افزار release می‌شد، باز هم دید عمومی به آن به شکل یک نرم‌افزار باگ‌دار باشد.
 
مشکل بدتر در این مثال این بود که کل ایده اینکه باگ‌ها توسط مشتریان کشف و اعلام شوند، برای این بود که بعد از اعلام مشتری، شرکت بتواند باگ‌ها را رفع کند. اما متاسفانه نه netscape و نه هیچ شرکتی در دنیا، امکانات و نیروی انسانی و توان فنی برای بررسی اولویت‌ها و رفع باگ‌های اعلامی بیش از 2 میلیون مشتری را نداشت. در نتیجه باگ‌ها و ایرادات مهم در میان انبوه درخواست‌‌های رسیده دفن می‌شدند.
 
احتمالاً می‌توانید تصور کنید که چه صدمه‌ای به اعتبار شرکت زده شد و امروز هم netscape تبدیل شده به مثالی برای درس‌ها و عبرت‌های این چنینی.
 
دلیل اشتباه چهارم: کسانی که شایستگی لازم برای تست کردن نرم‌افزار را دارند نمی‌خواهند تست کننده نرم‌افزار باشند
 
این یک واقعیت هست که پیدا کردن تست‌کننده خوب نرم‌افزار مثل برنامه‌نویس خوب مشکل است. جوئل اشاره می‌کند که در شرکت Juno که کار می‌کرده،‌ یکی از تست‌کننده‌های نرم‌افزار به تنهایی سه برابر مجموع همه باگ‌هایی که 4 تست کننده دیگر نرم‌افزار گزارش کرده بودند را کشف و گزارش کرده.
جوئل اشاره می‌کند که اغلب تست‌کننده‌های نرم‌افزار خوب بعد از مدتی حوصله‌شان از کار روتین تست نرم‌افزار به صورت روزانه سر می‌رود. این مشکلی هست که وجود دارد و باید آن را پذیرفت. پیشنهادهای جوئل برای این مساله این‌ها هستند:
  •  تست نرم‌افزار را به عنوان یک ارتقاء شغلی از بخش پشتیبانی مشتریان در نظر بگیرید
  • به تست‌کننده‌های خوب و باهوش اجازه بدهید که تا حدی برنامه‌نویسی کار کنند و unit test با استفاده از ابزارهای برنامه‌نویسی ایجاد کنند. این کار خیلی جذاب‌تر از تست دوباره و دوباره و دوباره و دوباره یک پنجره دیالوگ در نرم‌افزار هست.
  • بپذیرید که بعد از مدتی تست‌کننده‌های خوب شما را ترک خواهند کرد. همیشه در پی استخدام تست‌کننده باشید و روند استخدام آن‌ها را به خاطر اینکه موقتاً ظرفیت شما تکمیل شده را متوقف نکنید.
  • به صورت موقت استخدام کنید. اگر به عنوان مثال 10 نفر را به صورت موقت و چند روزه برای تست نرم‌افزاری استخدام کنید، خواهید دید که ده‌ها باگ پیدا می‌شود. بعضی از این افراد موقت، ممکن است توانمندی‌های لازم برای تبدیل شدن به یک تست‌کننده نرم‌افزار را داشته باشند که در این صورت می‌توانید آن‌ها را به صورت تمام وقت استخدام کنید.
دلیل اشتباه پنجم: من توان مالی برای استخدام تست‌کننده نرم‌افزار را ندارم!
 
این احمقانه‌ترین دلیل برای استخدام نکردن تست‌کننده نرم‌افزار است. مهم نیست که چقدر پیدا کردن تست‌کننده نرم‌افزار سخت باشد، به هر حال آن‌ها ارزان‌تر از برنامه‌نویس‌ها هستند. خیلی ارزان‌تر.
اگر شما از تست‌کننده نرم‌افزار استفاده نکنید، برنامه‌نویس شما باید کار تست را انجام دهد و علاوه بر هزینه‌ای که این کار به شما تحمیل می‌کند، باید صبر کنید و منتظر لحظه‌ای باشید که برنامه‌نویس ارشد شما از اینکه بارها به وی گفته شده که "چند هفته‌ بیشتر روی تست نرم‌افزار وقت بگذار قبل از اینکه منتشرش کنی" خسته می‌شود و می‌رود تا در شرکتی حرفه‌ای‌تر کار کند.
شما می‌توانید 3 تست‌کننده نرم‌افزار را برای یک سال استخدام کنید و هنوز ارزان‌تر از هزینه جایگزینی یک برنامه‌نویس ارشد هست.

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

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

ساختار تیم‌های مدرن نرم‌افزاری قسمت چهارم: مدیریت ارتباطات بین اعضای تیم

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

مدیریت ارتباطات برای هر کار تیمی لازم است

موضوعی که در این نوشته از سری نوشته‌های "ساختار تیم‌های مدرن نرم‌افزاری" می‌خواهم درباره‌اش صحبت کنم، یک موضوع عمومی و تا حدی در حوزه روانشناسی است. اما من سعی می‌کنم درباره مدیریت ارتباطات در یک تیم نرم‌افزاری بر اساس تجربه خودم صحبت کنم.

نمی‌دانم شما هم تجربه کار در تیم‌های نرم‌افزاری که صبحشون با یک سلام و علیک شروع و عصرشون با یک خداحافظی تمام می‌شه و حداکثر چند جمله رسمی در ساعات کاری بین اعضای تیم رد و بدل می‌شه رو داشتید یا خیر؟ مشکل این تیم‌ها چیه؟ ضعف ارتباطات که به صورت مستقیم باعث ضعف در خروجی تیم خواهد شد. 

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

این اثبات شده که انسان‌ها، وقتی شکست می‌خورند دیگران را در اون شکست مقصر می‌دانند و وقتی پیروز می‌شوند سهم خودشان را در پیروزی بیشتر می‌دانند (چند بار ترافیک را بهانه دیر رسیدن به جلسات کردید در حالی که دیر راه افتادن خودتان دلیل اصلی بوده؟)

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

نکات مهم در برقراری و حفظ ارتباط موثر در تیم‌های نرم‌افزاری

اولین و مهم‌ترین نکته‌ای که در ارتباط با هم تیمی‌هایتان در یک تیم نرم‌افزاری باید در نظر داشته باشید این است که هیچ وقت و تحت هیچ شرایطی به تصویری که هم تیمی شما از خودش دارد حمله نکنید! احترام به تصویر درونی افراد اولین اصل برقراری ارتباط موثر هست.

اگر developer شما فکر می‌کنه بتمن هست، اگر بت موبیل در اختیارش نمی‌گذارید، مهم نیست
اما اگر بهش بگید بتمن نیست، احتمالاً دیگه نمی‌تونید روی کمکش به تیم حتی به عنوان بت کید حساب کنید! 

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

نکته بعدی در برقراری و حفظ ارتباط موثر، خوب دیدن و خوب گوش دادن هست. اگر دید شما نسبت به یک برنامه‌نویس مثل نگاه به یک کارگر خط تولید یک کارخانه باشه که مثل یک ربات باید خروجی تحویل بده، این نوشته برای شما نیست. اما اگر به برنامه‌نویس، نه به شکل یک ربات که به شکل یک انسان نگاه می‌کنید پس با توجه به اینکه خروجی کارش متاثر از فکرش هست (و نه نیروی بازو) بنابراین باید بتونید شرایط و محیط دوستانه‌ای رو فراهم کنید که افراد تیم بتوانند با هم حرف بزنند.

این نگاه انسانی به نیروی کار، حتی در حوزه‌های دیگه هم وارد شده: اخیراً لینکی رو در بخش لینک‌های روزانه قرار دادم تحت عنوان "گوگل و سرمایه‌های انسانی" که نویسنده اشاره کرده بود که حتی نام بخش منابع انسانی یا سرمایه‌های انسانی (که در ایران بیشتر کارگزینی گفته می‌شه!) به بخش People Operations تغییر کرده، یا مثال دیگه در مورد تغییر ارزیابی‌ و رتبه‌بندی سنتی در مایکروسافت و جایگزینی آن با جلسات حضوری تحت عنوان connect‌ است.

نتیجه وجود این محیط دوستانه اینه که اعضای تیم با عشق تمام، کارشون رو شروع می‌کنند و به خاتمه می‌رسانند. نتیجه‌اش مثل ویدئوی github که در نوشته ساعات کار دلخواه بهش اشاره کردم هست که کارمند github اشاره می‌کنه به وضعیت زایمان خانمش و اینکه نتونسته بیاد سر کار و دیگران چقدر حمایتش کردند و از رئیسی که بگه فلان کار مونده و ... خبری نبوده و در نتیجه شرکت و همکارانش رو مثل خانواده‌اش می‌دونه.

اما این حرف زدن (در مورد کار) به تنهایی کافی نیست. باید مهارت گوش دادن موثر (و نه صرفاً شنیدن) و مشاهده موثر رفتارها را در خودتون (به عنوان مدیر تیم یا عضوی از تیم) تقویت کنید. بعد از تقویت این مهارت‌ها، افراد راحت‌تر به رشد و رفع نقایص خودشون و تیم کمک می‌کنند.

برای جلوگیری از طولانی شدن نوشته،‌ ادامه موارد مربوط به مدیریت ارتباطات در تیم‌های نرم‌افزاری رو در نوشته دیگه‌ای با هم بررسی می‌کنیم.

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

تست جوئل قسمت هفتم: لیست مشخصات نرم‌افزار

قبل از شروع مطالعه این نوشته، لازم است بدانید این مطلب بخشی از سری "تست جوئل، 12 گام برای کد برتر" است. دیگر نوشته‌های این سری را از این آدرس می‌توانید مطالعه کنید.

تست هفتم جوئل: آیا دارای لیست مشخصات هستید؟

هر محصول صنعتی دارای مشخصات (specifications) است، نرم‌افزار هم از این قاعده مستثنی نیست. هر کد نرم‌افزاری باید بر مبنای یک سند مشخصات یا به اختصار spec تولید شود.

جوئل در این مورد می‌گوید: "نوشتن لیست مشخصات (specifications) درست مثل استفاده از نخ دندان است:‌ همه قبول دارند كه كار خوبی است ولی هیچ كس حوصله‌اش را ندارد."


در فصل اول سریال فرار از زندان،اگر مایکل اسکوفیلد تونست از زندان فرار کنه، فقط به خاطر هوشش نبود،
لیست مشخصات بخش‌های مختلف زندان رو هم داشت!

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

گفته جوئل درست است که اگر نرم‌افزاری را بر اساس سند مشخصات (در واقع نقشه design انجام شده) درست نکنید، احتمالاً گرفتار یک طراحی بد و زمان خارج از کنترل خواهید شد. 

توجه کنید که سند مشخصات نرم‌افزار واقعاً باید یک سند مکتوب باشد و صحبت درباره مشخصات نرم‌افزار و آنچه که شما درباره نرم‌افزاری که دارید می‌سازید در ذهن دارید spec محسوب نمی‌شود!

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

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

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

جوئل اسپالسکی هم مثالی درباره عواقب عدم توجه به این مساله می‌زند: "به نظر می‌رسد كه مشكل Netscape نیز همین بوده - چهار نسخه اول آن قدر شلم شوربا شد كه مدیریت به طرز احمقانه‌ای تصمیم گرفت همه كد آن را دور بياندازد و از صفر شروع كند. سر Mozilla هم دوباره همین اشتباه را مرتكب شدند،كه محصول آن هیولایی خارج از كنترل است كه چند سال طول كشیده تا فقط به مرحله آلفا برسد."

حالا که درباره اهمیت لیست مشخصات صحبت کردیم، در نوشته‌های دیگری به این موضوع خواهیم پرداخت که لیست مشخصات چیست و چطوری باید یک سند spec درست کنیم؟

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی

تست جوئل قسمت ششم: برنامه‌ریزی و تخمین زمان اجرا بر اساس شواهد

قبل از شروع مطالعه این نوشته، لازم است بدانید این مطلب بخشی از سری "تست جوئل، 12 گام برای کد برتر" است. دیگر نوشته‌های این سری را از این آدرس می‌توانید مطالعه کنید.

تست ششم جوئل: آیا برنامه زمانبندی‌تان به روز است؟

تست ششم جوئل که درباره برنامه زمان‌بنید است، مقدماتی داشت. در دو نوشته درباره بایدها و نبایدها در برنامه‌ریزی تولید نرم‌افزار گفتم. به طور خلاصه تست ششم جوئل اشاره می‌کند که یک تیم نرم‌افزاری باید برنامه زمانبندی برای تولید داشته باشد.

یکی از مهمترین دلایلی که جوئل برای داشتن یک برنامه زمانبندی به‌ روز اشاره می‌کند بحث جلوگیری از بیماری featuritis است. بیماری که طراحان و برنامه‌نویسان دچار آن می‌شوند و می‌خواهند به یک سیستم پیچیده امکانات بیشتری را بدون برنامه‌ریزی لازم اضافه کنند. درباره این بیماری در نوشته دیگری مفصل صحبت خواهم کرد، فعلا در پرانتز از تجربه شخصی‌ام در این مورد می‌گویم که محصولی ایجاد کرده بودیم که بر اساس تنظیماتش alert‌های شرطی را به صورت آنی ارسال می‌کرد، برای اینکه از قابلیت‌های این محصول در یک محصول دیگر برای ارسال alert‌ها استفاده کنیم، قابلیت ارسال بر اساس یک زمان‌بندی مشخص (روزانه، هفتگی، ماهیانه) به محصول اضافه شد. نتیجه؟ محصول فوق‌العاده پیچیده شد، دیباگ آن عملاً به یک کابوس تبدیل شد و توسعه آن غیرممکن! برای رهایی از مشکلاتی که اضافه کردن این قابلیت خاص بدون بررسی لازم و پیش‌بینی عواقب آن ایجاد کرده بود، در نسخه بعدی محصول، عملاً قابلیت ارسال بر اساس زمان‌بندی حذف شد!

چطور یک برنامه ‌ریزی موفق داشته باشیم؟

جوئل در نوشته دیگری به موضوع برنامه‌ریزی می‌پردازد. روش معرفی شده در این نوشته که Painless Software Schedules نام دارد دیگر قدیمی شده و جوئل Evidence Based Scheduling را پیشنهاد می‌کند.

قبل از صحبت درباره برنامه‌ریزی جوئل به دلایل اینکه برنامه‌نویسان از برنامه‌ریزی تولید نرم‌افزار فرار می‌کند می‌پردازد. مهمترین دلیلی که ذکر می‌شود این است که: "هیچ کس باور نمی‌کند که برنامه‌ریزی انجام شده واقع‌بینانه باشد!

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

 

Evidence Based Scheduling چطور کار می‌کند؟ 

برای اینکه یک برنامه‌ریزی موفق با استفاده از روش EBS داشته باشید باید کارهای زیر را انجام دهید:

1- شکستن زمان انجام وظایف: برنامه ریزی شما نباید بر اساس روز یا هفته باشد، باید بر اساس ساعت انجام شود، شما باید مجموعه کارهایی که در جریان اجرای یک پروژه باید تکمیل شوند را به وظایفی که حداکثر در 16 ساعت قابل انجام باشند بشکنید.
مزیت اصلی این کار این است که شما مجبور می‌شوید جزئیات کار را به دقت مشخص کنید. مثلاً اگر قرار باشد یک کار تحت عنوان اضافه کردن پروفایل کاربر داشته باشید و مثلاً برایش 4 روز زمان بگذارید بدون اینکه بدانید عملاً چه کاری می‌خواهد انجام شود، به خاطر همین عدم قطعیت و مشخص نبودن فعالیت‌های اجرایی، در نهایت بیشتر از آن زمان را صرف خواهید کرد و برنامه شما به deadline هایش نخواهد رسید. 

2- زمان صرف شده را ثبت و بررسی کنید: همه افراد در تخمین زمان اجرای کارها مثل هم نیستند، بعضی دقیق‌تر تخمین می‌زنند و بعضی هم با اختلاف زیاد. نکته مهم این است که زمان تخمین زده شده و زمان واقعی اجرای کارها را ثبت و بر اساس آن نموداری به شکل زیر برای هر برنامه‌نویس آماده کنید.

 

در نمودار بالا، زمان تخمین زده شده و زمان واقعی اجرای کارها نشان داده می‌شود. اینجا یک مفهوم دیگر هم به بازی وارد می‌شود: سرعت اجرای وظایف یا velocity که بر اساس تقسیم زمان تخمین زده شده بر زمان واقعی اجرا به دست می‌آید.

حالت ایده‌آل velocity عدد یک است، یعنی زمان تخمین زده شده و زمان واقعی با هم برابر باشند. در این حالت برنامه نویسی که خوب می‌تواند تخمین بزند، در نمودارش اعداد 1 را برای velocity خواهد داشت. بر حسب میزان تجربه و دقت در تخمین، ممکن است velocity بیشتر یا کمتر از 1 باشد، در نهایت velocity به شما نمایی از میزان دقت در برنامه‌ریزی برای هر شخص در تیم می‌دهد.

3- شبیه‌سازی آینده: با استفاده از velocity که در مرحله قبل به دست آوردید می‌توانید زمان تقریبی اتمام کارها را با دقت بالایی تخمین بزنید. در واقع به جای جمع زدن اعداد تخمینی زمان اجرا، از روش زیر برای تخمین زمان استفاده کنید. هر زمانی که برنامه‌نویس برای اجرا به شما اعلام می‌کند در یک velocity تصادفی که از تاریخچه کارهای آن برنامه‌نویس بدست آمده ضرب کنید و به این ترتیب زمان کلی اجرا را بدست آورید، یک نمونه را به شکل زیر می‌توانید مشاهده کنید.

 

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

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

درباره روش EBS در مطلب جداگانه‌ای بیشتر صحبت خواهم کرد.

به اشتراک گذاری این نوشته در شبکه‌های اجتماعی