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