چطور کار تیمت رو به استراتژی شرکت گره بزنی
خلاصهٔ کاملتر
به گفتهٔ نویسنده، شروع سال مالیه؛ فصل استراتژی، همون وقتی که ایدههای بزرگ بیرون میان و همه هنوز امیدوارن. اون میگه در طول سالها به یه ساختار رسیده که کمکش میکنه پروژههایی تعریف کنه که هم به استراتژیِ بالادست وصل باشن و هم محیط خودِ تیمشو در نظر بگیرن.
نویسنده میگه استراتژی معمولاً از بالا میاد پایین: مدیران ارشد تصویر کلی رو میکشن، رؤسای بخش تیکهتیکهش میکنن به پروژه و اونها به تیمها میرسن. این فرایند همیشه شفاف نیست، ولی میشه با تزریق پروژههای خودت تا حدی مالکیتش رو به دست گرفت، چون چیزی که تو از جایگاهت میبینی ممکنه لایههای بالاتر نبینن و همون شکافها رو تو میتونی پر کنی. اولین قدم به گفتهٔ نویسنده اینه که واقعاً استراتژی رو بشناسی؛ یه گفتوگو با مدیرت دربارهٔ اینکه شرکت و مدیرِ مدیرت چند سال آینده کجا میخوان برن و چرا. اون میگه این کارو حداقل سالی یهبار انجام بده، چون وقتی پروژههاتو تو قالب استراتژی شرکت پیچ کنی، بیشترِ متقاعدکردن از قبل انجام شده و مدیرت هم راحت میتونه به بالا پیچش کنه.
برای تبدیل استراتژی به پروژه، نویسنده از یه نسخهٔ دستکاریشدهٔ opportunity solution tree از Teresa Torres استفاده میکنه. میگه یه استراتژی رو برمیداری، مثلاً «کاهش هزینه»، و شروع میکنی اکشنهای کلی رو بهش وصل کردن: اتوماسیون فرایندها، حذف نرمافزار کماستفاده، بررسی لایسنسها؛ این مرحله جای قضاوت نیست، جای ریختن ایدههاست. بهتره چند نفر باهوش از تیم رو هم بیاری، چون تو فقط چیزی که میدونی رو میدونی. بعد از مبهم به مشخص میری و فلافِ اضافه رو فیلتر میکنی و آخرش یه proof of concept تعریف میکنی: چی میشه سریع ساخت که ثابت کنه این ایده جون داره؟ اگه نتونی همچین چیزی پیدا کنی، احتمالاً ارزش دنبالکردن نداره.
نویسنده میگه میشه همینجا وایستاد و یه لیست پروژهٔ خوب داشت، ولی نکتهٔ اصلی جای دیگهست: پروژههایی که بیشتر از یه استراتژی رو خدمت میکنن. تو مرحلهٔ «ایدهٔ مبهم» مکث کن، همین تمرین رو برای بقیهٔ استراتژیها هم جدا اجرا کن و بعد یه قدم عقب برو و از بالا نگاه کن؛ اونجا همپوشانیها پیدا میشن، ایدههایی که چند هدف رو همزمان لمس میکنن و همونها برندهان، چون بودجه و دیدهشدن میگیرن. مثالی که میزنه اینه: اگه تیم فروش دستی سفارشها رو برای تیم تحویل ایمیل میکنه، جایگزینیش با یه اتصال API هم هزینهٔ نیروی کار رو کم میکنه و هم اگه پروژهٔ بعدیت به دیتای لحظهایِ سفارش نیاز داره، همون API میشه زیرساخت حیاتی؛ یه حرکت، دو تا برد.
نویسنده در جواب اینکه «من آزادیِ تعریف کار تیممو ندارم» میگه بیشتر تیمها ندارن، ولی این اولین قدم بهسمت اون آزادیه؛ کاری که میکنی اینه که به مدیرت کمک میکنی جلوی مدیرِ خودش خوب به نظر بیاد. ممکنه بار اول دستبهسرت کنن چون برنامهها قفل شدن، ولی دور بعدی شانس بیشتری داری که تو اتاق تصمیم باشی، چون ثابت کردی این چیزها رو میفهمی. اون تأکید میکنه پیشنهاد پروژه یعنی تعهد به انجامش نیست؛ ایدهآل اینه که کارِ تعیینشده رو با کارِ انتخابشده جایگزین کنی، نه اینکه پروژهٔ اضافه بار خودت کنی. همین جابهجایی از «کار تحمیلی» به «کار انتخابی» حرف اصلی نویسندهست.
نکات کلیدی:
- اول استراتژی شرکت رو با گفتوگوی سالانه با مدیرت واقعاً بشناس
- پیچکردن پروژه تو قالب استراتژی، شانس تأیید و دیدهشدنش رو بالا میبره
- با نسخهٔ سادهشدهٔ opportunity solution tree از استراتژی به اکشن و بعد پروژهٔ مشخص برس
- یه proof of concept سریع، ایدههای بیارزش رو فیلتر میکنه
- پروژههایی که چند استراتژی رو همزمان جلو میبرن، بودجه و اولویت میگیرن
