من قبلا درباره مشکلات مربوط به تیم و تامین مالی در یک پروژه صحبت کرده ام. به عنوان خلاصه:
- پروژه ها، عموما اموری کوتاه مدت هستند که اغلب اوقات بدهی فنی (technical debt) و کارهای نیمه تمام زیادی پشت آنهاست.
- تیم های پروژه نیز عموما گروه هایی هستند که به صورت کوتاه مدت تشکیل شده و مدیران پروژه می توانند عمدا آنها را به سمت رژه مرگ (رژه مرگ یا death march به زمانی گفته می شود که برنامه ریزی واقع بینانه صورت نگرفته و کارکنان باید برای رسیدن به هدف پروژه، فشار بسیار زیادی را متحمل شوند) بکشانند. چرا که تیم به زودی منحل خواهد شد و تمامی اعضا به سوی رژه های مرگ دیگر می روند!
- تیم هیچ ارتباط طولانی مدتی با محصول یا ویژگی (خلق شده) ندارد و بنابراین تمایلی هم به ایجاد دانش دامنه (domain knowledge) و سرمایه گذاری عاطفی در محصول یا ویژگی ندارد.
بنابراین پاسخ چیست؟
تیم محصول، نه تیم پروژه!
ارائه نرم افزار به شیوه سنتی، توسط تیم پروژه و معمولا در ساختار ماتریسی انجام می شد. این یعنی افراد هم به مدیر اصلی (کسی که معمولا مدیریت افرادی با مهارت های مشابه را برعهده دارد؛ مثلا تسترهای محصول به مسئول تست گزارش می دهند) و هم به مدیر پروژه (کسی که مدیریت تعدادی از افراد با مهارت ها و توانمندی های متفاوت را داشته و درباره کل پروژه از افراد گزارش می گیرد) باید گزارش کار خود را بدهند. مدیر اصلی، کارهای مربوط به “مدیریت افراد” را انجام می دهد (مثلا توسعه مسیر شغلی، برنامه ریزی جانشین پروری، خروج از کار، عملکرد و غیره)، و مدیر پروژه کارهای مربوط به “مدیریت کار” را انجام می دهد (تحت نظر گرفتن اهداف، ریسک، مشکلات، مسائل مالی و غیره).
شاید این توضیحات منطقی به نظر برسند، اما مشکلات بزرگی هم دارند:
- مدیری که مسئول مسیر و توسعه شغلی فرد است، هیچ آشنایی با کار او ندارد.
- افراد هیچ ارتباط طولانی مدتی با محصول یا ویژگی ندارند.
- مدیران مستقیم می توانند از روی عمد، پروژه را با مشکل رو به رو کرده و یا در کار مدیر پروژه اختلال ایجاد کنند.
راه حل، استفاده از چیزی مانند مدل اسپاتیفای است که در آن قبایل و کارگروه ها تعریف می شوند.
قبیله ها و انجمن ها (Tribes and Guilds)
قبیله به محصول، ویژگی و تیم های توانمندی (capability teams) گفته می شود. تیم کوچک و چند منظوره ای که مسئولیت تحویل و مدیریت محصولی خاص یا بخشی از محصول را از طریق فرآیندهای سر به سر دارد. انجمن ها، گروهی از افراد هستند که همگی مهارت ها و علایق مشابهی دارند؛ برای مثال همگی روی پایگاه داده، توسعه سیستم عامل IOS یا مدیریت محصول کار می کنند. انجمن ها، دارای افرادی به نام رهبر کارگروه (chapter leads) هستند که این افراد مسئول ارتقاء عملکرد کلی افرادِ درون انجمن می باشند. این افراد البته، عضو قبیله خاصی نیستند و مسئولیتی برای ارتقاء ویژگی ندارند.
این یک شرایط برد-برد است: شما می توانید تیم هایی اختصاصی و متعهد تشکیل دهید که مسئولیت و مالکیت بلند مدت یک محصول یا ویژگی را داشته باشند؛ اما در عین حال گروه هایی از متخصصین با مهارت ها و علایق خاصی نیز دارید که با “متخصص ترین افراد در آن زمینه” هدایت می شوند.
تامین مالی برای محصول، نه پروژه!
تا اینجا به موضوعاتِ مربوط به ساختار سازمانی پرداختیم. اما تامین مالی چه می شود؟
به طور سنتی، فناوری اطلاعات به عنوان بخشی از بودجه بندی پروژه در نظر گرفته می شود؛ فرآیندی که در آن تامین مالی برای یک یا چند پروژه در طول یک سال مالی انجام می شود. به چند دلیل، این سیستم واقعا وحشتناک است:
- تامین مالی به بخش های بزرگ تقسیم شده و به پرونده های تجاری بزرگ و پیچیده ای گره خورده است که پر از فرضیه های نامتناسب و اطلاعات ناقص هستند.
- فرآیند تامین اعتبار، فرآیندی طولانی و پر زحمت است.
- از تیم انتظار می رود که تمام پول را خرج کرده و پروژه را تحویل دهند؛ حتی اگر مشخص شود برخی از قسمت های آن ایده مناسبی ندارد.
- تامین مالی به سود و منفعت های خاصی گره خورده است که رقم خوردن آنها هم به ایجاد یک سری ویژگی های خاص بستگی دارد و همه اینها هم از 12 ماه قبل طراحی شده اند!
- بنابراین، هیچ جایی برای تغییر مسیر یا نوآوری وجود ندارد.
اینجاست که تامین مالی چابک برای محصول، شما را نجات می دهد.
من سیستم ساده ای را پیشنهاد می دهم که در آنها تیم های کوچک و چند منظوره ای، مسئول انجام سلسله کارهایی باشند (workflow) که تامین اعتبار آنها هم به شکلی سیال و مداوم انجام شود.
برای تامین مالی، به چهار شیوه می توان تصمیم گیری کرد که عبارت اند از: تامین مالی مرحله بذرپاشی (seed)، تامین سرمایه برای محصول (Fund)، تامین مالی برای اتمام کار روی محصول (Retire) و متوقف کردن تامین مالی (Kill).
تامین مالی مرحله کشت ایده (Seed)
به تیم هزینه ای برای برگزاری سه اسپرینت، ساخت نمونه اولیه (پروتوتایپ) یا نسخه حداقلی محصول (MVP) و یادگیری داده می شود. این یادگیری ها منتج به اخذ تصمیمات بعدی برای تامین مالی می شود (احتمالا تامین سرمایه برای محصول و یا توقف تامین مالی).
تامین سرمایه برای محصول
به تیم سرمایه ای برای برگزاری دو اسپرینت برای یک ویژگیِ محصول، نگهداری و توسعه آن داده می شود. در طول زمان، نسبت انرژی که برای نگهداری ویژگی قبلی و توسعه ویژگی جدید اختصاص داده می شود، به تدریج تغییر می کند. فکر می کنم تخصیص سرمایه برای دو اسپرینت مناسب باشد چرا که برای تیم، سر کردن با یک اسپرینت به خاطر کمبود بودجه خیلی سخت خواهد بود. اغلب اوقات فقط برای خاتمه، اتمام و تحویل یک ویژگی، باید یک اسپرینت برگزار شود. کمی پایین تر درباره این مسئله توضیح داده ام.
اتمام کار روی محصول
اگر مالک محصول احساس کند نیازی نیست بیش از این ویژگی یا قابلیت دیگری به محصول اضافه شود، اما محصول هنوز ارزش نگهداری دارد، می تواند تصمیم به اتمام کار روی آن بگیرد. این دقیقا به معنی رفتن روی حالت نگهداری از محصول می باشد. به طور ایده آل، مالکیت محصول همچنان باید در دست تیمی باشد که آن را ساخته است. در زمان نگهداری، باید 10% یا 20% از زمان (یا بیشتر) را برای سرپا نگه داشتن، برطرف کردن مشکلات و غیره صرف کرد. بنابراین، همچنان نیاز به تامین مالی وجود دارد اما خیلی کمتر. همچنین، می توان محصول را به تیم پشتیبانیِ محصول تحویل داد که البته خیلی شرایط خوشآیندی نیست.
متوقف کردن تامین مالی
در این مرحله تصمیم نهایی برای توقف صرفِ هزینه برای یک محصول گرفته می شود. البته باید به خاطر داشته باشید که انجام همین مرحله هم نیازمند صرف هزینه هایی بوده و عموما حداقل یک اسپرینت را می طلبد (برای تغییر مدیریت، صحبت و تبادل اطلاعات، پاکسازی داده ها، منقضی کردن دامنه و غیره). بسیاری از سازمان ها این مرحله را فراموش کرده و همه چیز را نیمه کاره رها می کنند. کار را درست تمام کنید!
فرآیند تامین مالی چابک چطور عمل می کند
مالکین ارشد محصول باید با مالکین دیگر کار کرده و به طور مداوم محصولات خود را مورد بررسی قرار دهد. در این فرآیند، باید ارزش محصولات به طور مداوم تحت نظر قرار گرفته و پیش بینی شود و در هر اسپرینت، برای تامین مالی مرحله بذرپاشی، تامین سرمایه برای محصول، تمام کار روی محصول و یا متوقف نمودن تامین مالی تصمیم گیری شود. مسلما، اگر تیم تصمیم به توقف تامین مالی بگیرد، می تواند به سراغ اسپرینت بعدی برای بذرپاشی روی محصول یا ویژگی دیگر برود. بنابراین بهتر است بک لاگی از ایده های مختلف برای محصول وجود داشته باشد که تیم بتواند در مدت زمان کوتاهی به سراغ ایده های بعدی برود.
