چطور با دولوپرها کار کنیم؟

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

    • بیشتر از اینکه حرف بزنیم، بشنویم

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

    • در کارشون وقفه ایجاد نکنیم

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

    • برنامه را عوض نکنیم

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

    • سوال بپرسید، راه حل ارائه نکنید

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

    • یادآوری کنیم چه مشکلی را برای چه شخصی داریم حل می‌کنیم

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

عکس بالای این پست، پوستر دو پرسونایی است که تیم میل چیمپ به عنوان کاربر انتخاب کرده‌اند و به دیوار محلی که تیم در اون قرار دارد زده شده.

  1. سلام
    بیشتر بنویس و کار خوبتو ادامه بده…
    از فضا و حس سایتت خوشم اومد…

Leave a Reply

Your email address will not be published. Required fields are marked *