آیا تا به حال تجربه کار در یک محیط agile داشتهاید؟ چه طور میشه یک فضای کاری پویا را مدیریت کرد و این فضاهای کاری چه چالشهایی در پی دارد؟
دنبالهی موضوع اگه یک سال آیندهت رو قرار بود فقط و فقط روی یه پروژه کار کنی، اون چی بود؟
آیا تا به حال تجربه کار در یک محیط agile داشتهاید؟ چه طور میشه یک فضای کاری پویا را مدیریت کرد و این فضاهای کاری چه چالشهایی در پی دارد؟
دنبالهی موضوع اگه یک سال آیندهت رو قرار بود فقط و فقط روی یه پروژه کار کنی، اون چی بود؟
چند مورد تجربه با تیمهای استارتاپی داشتم، با در نظر گرفتن اینکه تیمهای استارتاپی باید چابک باشن، میتونم بگم که در تیمهای اجایل، تعاملات درون تیمی و تعامل با مشتریها حرف اول رو میزنه.
اصلا این در بیانیهی توسعه محصول چابک هم هست:
افراد و تعاملات بالاتر از فرآیندها و ابزارها
اگه اکثر افراد تیم چندان اهل حرف زدن نباشن، درونگرا و یا خجالتی باشن، از بروز نظرشون بترسن و یا به هر دلیلی سکوت رو به گفتگو ترجیح بدن، تیم در عمل به مشکل برمیخوره.
در ضمن تو این تیمها مدل ذهنی یادگیرنده و روحیه انعطافپذیر خیلی مورد نیازه، چون اصول کار چابک با تغییرات زیادی همراهه و اگه افراد نتونن پابهپای تغییر پیش برن و از مسیرشون یاد بگیرن، موفق نخواهند شد.
با توجه به این توصیفا، چالشهای اصلی مدیریت یک فضای کار چابک، از نظر من اینها هستن:
برای مدیریت تیمهای چابک روشها و چارچوبهایی وجود داره، از جمله روش اسکرام و okr.
طبق تجربه، روش اسکرام بدون حضور یک اسکرام-مستری با تسلط کلامی و روحیه همدلی بالا به جایی نمیرسه و فقط استرس به تیم و اعضا اضافه میکنه. شخصا روش okr رو بیشتر میپسندم، با اینکه به نظر میرسه برای تیمهای کوچیک روش اسکرام باید اثربخشتر باشه. در ضمن اینکه در اسکرام تعامل خیلی قویتر هست.
توی این چند وقته تجربه کار در دو محیط رو داشتم و در این دو محیط، در دو سطح متفاوت بودم، بنابراین فکر میکنم بتونم توصیههایی داشته باشم که از دو سمت قضیه به شما کمک کنه، بخصوص اگر که در مقام مدیریت هستید، با حرکتهایی سخت ولی در عینحال ساده میتونید چشمانداز کار رو بسیار بهتر کنید:
تعارضهای محیط رو باید مدیریت کنید. مدیریت مشخص برای تعارض میتونه به شکل حل اون از سریق یک سیستم معقول و مورد قبول همگانی باشه یا یک برنامه معین: مثلا ما در هر ماه، یک روز برای حل چالشهای تیمی وقت میزاریم بدون هیچ کار دیگهای.
روی «بازنگری دورهای» روی محصول و کار، وقت بزارید. این حرکت برخلاف جهت آب به نظر میاد ولی هر بار که «بازنگری» (در اصطلاح کدزنی refactor) رو به تاخیر بندازید، مشکلات رو به عمق میبرید و بعدها با هزینه بسیار زیاد باید برگردید و اونها رو تصحیح کنید. هر قدمی که با ذهنیت صرفهجویی در وقت، این اقدام رو به تاخیر میندازید، کار رو به خفه شدن نزدیک میکنید.
سیستمی درست برای ارزشیابی رشد و یادگیری داشته باشید. افراد نباید حس کنند که هرچه بهتر کار کنن، تنها به حساب وظیفه نوشته میشه و هیچ بازخورد واقعی از جمله رشد تیمی یا درآمدی در کار نیست. در بسیاری از موارد این ارزش الزامی نداره چیزی خارقالعاده باشه، بلکه حرکتی بسیار کوچک ولی با حسی واقعی میتونه باشه.
در هدفگذاری واقعگرایانه عمل کنید. نه بیخیال این حرکت بشید و نه به شوآفها توجه کنید. در حدی قابلقبول، مسیر و روش ارزیابی سریع رو برای خودتون و تیم فراهم کنید. باز هم در زمانهای مناسب این روش باید دچار بازنگری و تطابق با شرایط بشه. ممکنه موفقیتهای ظاهری حاصل هدفگذاری غلط باشه و باعث بشه که شما در تله بقا گیر بیوفتید و نتونید فرصت رشد رو پیدا کنید. بدونید که در چه سطحی بازی میکنید و سطح موفقیتها رو با این سطح بازی تطبیق بدید تا دچار سو تفاهم در تغییر سطح بازی نشید.
به طور کلی در تمام موارد، حرکت برخلاف جهت و به موقع، یعنی بازنگری در محصول، بازنگری در تیم و بازنگری در هدفگذاری، مهمترین نکاتیه که میتونید بهش توجه کنید. در بسیاری از جاها به بهانه رفع نیاز مشتری کنونی، یا تعجیل برای تولید محصول برای یک بازار ابتدایی، یا …، این کارها رو کنار میزارن و وقت تلف کردن میدونن. تجربه واقعی من میگه که اگر این اتفاق افتاد، شما و تیمتون در خوشبینانهترین حالت، ۲۰ سال بعد در همین وضعیت کنونی خواهید بود و هنوز برای بقا میجنگید!