مدیریت چابک چیست؟ — Agile Management به زبان ساده و کاربردی

مدیریت چابک یا Agile Management رویکردی مدرن در رسیدگی به پروژه‌ها است که روی عرضه مداوم نسخه‌های مختلفی از محصول که بازخورد مخاطبان را به دست می‌آورند متمرکز است. این رویه تفاوت‌های فراوان با مدیریت پروژه «آبشاری» دارد که رویکردی خطی در قبال توسعه محصول در پیش می‌گیرد. مدیریت چابک به گونه‌ای صورت می‌گیرد که تمام اعضای حاضر در یک تیم را به برقراری ارتباط آزادانه، همکاری، الهام‌گیری و اعتماد متقابل تشویق می‌کند.

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

مدیریت چابک چیست؟

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

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

مدیریت آبشاری در مقابل مدیریت چابک

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

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

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

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

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

مدل آبشاری می‌تواند به برخی از چالش‌های مشخص توسعه محصول دامن بزند:

• موانع و مدیریت اتکا: استایل‌های مدیریت پروژه سنتی معمولا به «مسیرهای حیاتی» منتهی می‌شوند. در این حالت تا زمانی که مشکلی که به مانعی برای پروژه تبدیل شده برطرف نگردد، کار پیش نمی‌رود.
• دشواری در دریافت بازخورد کاربر و اعتبارسنجی محصول: برای اینکه به زخم نمک پاشیده شده باشد، مشتری نهایی تا پیش از عرضه محصول به صورت کامل قادر به تعامل با آن نیست. بنابراین شاهد بروز این مشکل جدی هستیم که برخی نواقص در طراحی و کدنویسی محصول تا پیش از عرضه شناسایی نخواهند شد.

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

مدیریت چابک و ساختار سیکلی آن می‌تواند چندین فرصت برای تیم به وجود آورد:

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

مدیریت چابک به تیم‌ها اجازه می‌دهد واکنشی ارتجاعی‌تر به تغییراتی داشته باشند که به شکلی اجتناب‌ناپذیر حین پیش بردن یک پروژه رخ می‌دهند.

و مزیت حتی بزرگ‌تر، مهارتی است که میان تمام اعضای تیم نرم‌افزار به اشتراک گذاشته می‌شود. هم‌پوشانی مهارتی اعضای تیم باعث شکل‌گیری انعطاف‌پذیری شده و هرکسی می‌تواند روی پایه کد تیم کار کند. به این ترتیب اگر مسیر پروژه تغییر کند، منابع و زمان هدر نمی‌روند.

قواعد مدیریت چابک

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

فاکتورهایی که هنگام گذار به مدیریت چابک باید در نظر داشت

گذار به سیستم مدیریت چابک می‌تواند کاری چالش‌برانگیز باشد، خصوصا وقتی که رویکردهای مدیریت پروژه سنتی در یک تیم یا سازمان ریشه دوانده‌اند. حرکت به سمت رویکردهای چابک ممکن است نیازمند تغییر برخی پروسه‌ها باشد -خصوصا هنگام به‌کارگیری رویکرد DevOps- و تیم‌های توسعه و عملیات باید به همکاری بسیار نزدیک با یکدیگر بپردازند تا روند توسعه و رسیدگی به نرم‌افزار به بهینه‌ترین شکل پیش برود.

هنگام به‌کارگیری قواعد مدیریت چابک، تیم توسعه و سهام‌داران باید با آغوش باز به سراغ دو مفهوم بسیار مهم بروند:

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

بیایید به بررسی مکانیزم‌هایی بپردازیم که مدیریت چابک از آن‌ها برای نظم‌بخشی، اجرا و ساختاربخشی به کار بهره می‌گیرد.

نقشه‌های راه

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

الزامات

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

وظایف انباشت شده (Backlog)

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

معیارهای چابک

تیم‌های چابک تمام موفقیت خود را مدیون معیارها هستند. محدودیت‌های Work in Progress (یا به اختصار WIP) تیم و کسب‌وکار را بر رسیدگی بر کارهایی که از بیشترین اولویت برخوردار هستند متمرکز می‌کند. گراف‌هایی مانند چارت‌های Burndown و چارت‌های کنترل به تیم در پیش‌بینی ریتم کار و دیاگرام‌های جریان فزاینده به شناسایی گلوگاه‌ها کمک می‌کنند. این معیارها باعث می‌شوند تمام اعضای تیم روی اهداف بزرگ متمرکز باشند و نسبت به توانایی‌های خود در رسیدگی به کارهای آتی اعتماد به نفس داشته باشند.

مدیریت چابک و اعتماد

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

استفاده از جریان‌های کاری برای سرگرمی و سوددهی

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

• کاربران آیفون هنگام استفاده از یک اپلیکیشن موبایل برای تماشای استریم زنده پرتاب موشک نیازمند تماشای ویدیو به صورت افقی هستند
• کاربران دسکتاپ نیاز به یک دکمه «فول‌اسکرین» در گوشه پایین سمت راست ویدیو پلیر خود دارند
• کاربران اندرویدی باید به استور اپل متصل شوند

داستان‌های بالا همگی به یکدیگر مرتبط بوده و می‌توانند وظایفی مجزا در نظر گرفته شوند که به سمت تکمیل شدن بدنه‌ای بزرگ‌تر از کار (یک اپیک) حرکت می‌کنند. در این مثال، اپیک می‌تواند «بهبود سرویس استریم برای پرتاب موشک در سه‌ماهه نخست سال» باشد.

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

اپیک چابک در برابر ابتکار چابک

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

ساخت یک اپیک چابک

هنگام ساخت یک اپیک جدید، باید به ابزارهای برنامه‌ریزی و سازمانی که تیم از پیش به آن‌ها دسترسی دارد توجه نشان داد. ساخت اپیک بر مبنای اهداف و ماموریت‌های تیم در هر سه‌ماهه شروعی درست خواهد بود. هنگام ساخت اپیک، فاکتورهای زیر را به کار ببندید:

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

کالبدشکافی یک اپیک در مدیریت چابک

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

نقش کاربر یا پرسونا - یک داستان منحصر به فرد برای پرسونای هر کار خود بسازید - به عنوان مثال می‌توان به «لاگین سریع‌تر برای کاربران تازه‌وارد» یا «لاگین سریع‌تر برای مشتریان که بازگشته‌اند» اشاره کرد.

گام‌های منظم - پروسه را خرد کرده و یک داستان برای هر گام بسازید.

فرهنگ - اجازه دهید نرم‌های تیمی دیکته‌کننده این باشند که داستان باید سریعا انجام شود یا پروژه‌ای یک هفته‌ای باشد.

زمان - یک مانع روانی دیگر را نیز از پیش روی تیم برداشته و داستان‌هایی طراحی کنید که می‌توانند در بازه زمانی واقع‌گرایانه به پایان برسند.

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

داستان‌های کاربر: معنا، مثال‌ها و قالب‌ها

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

ممکن است به داشتن این ذهنیت وسوسه شوید که داستان‌های کاربر در واقع پیش‌نیازهای سیستم نرم‌افزاری هستند، اما این‌طور نیست.

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

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

کار کردن با داستان‌های کاربر

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

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

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

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

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

قالب و مثال‌های داستان کاربر

داستان‌های کاربر معمولا با جملات ساده نوشته شده و ساختاری مشابه آنچه در پایین آمده دارند:

«به عنوان یک [پرسونا]، من [می‌خواهم که...]، تا...»

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

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

تا: تمایلات آنی ‌آن‌ها برای انجام یک کار چطور با تصویر کلی پروژه سازگاری می‌یابد؟ آنچه آن‌ها به دنبالش هستند چه مزایایی به همراه می‌آورد؟ مشکل بزرگی که باید برطرف شود چیست؟

برای مثال داستان‌های کاربر می‌توانند چنین شکل و شمایلی داشته باشند:

-به عنوان رضا من می‌خواهم قادر به دعوت کردن دوستانم باشم تا با یکدیگر از این سرویس لذت ببریم.

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

-به عنوان یک مدیر، می‌خواهم بتوانم پیشرفت همکارانم را درک کنم تا بهتر قادر به گزارش کردن موفقیت‌ها و شکست‌ها باشم.

استفاده از این ساختار ضروری نیست، اما می‌تواند به شما در معنابخشی به کار کمک کند. وقتی پرسونای مورد نظرمان به ارزشی که به آن نیاز دارد دست پیدا کند، داستان به پایان می‌رسد. در این مسیر تیم‌ها می‌توانند ساختار خودشان را ساخته و به آن بچسبند.

آغاز به کار با داستان‌های کاربر

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

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

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

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

چارت کنترل

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

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

دیاگرام جریان فزاینده

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

معیارهایی حتی بیشتر

معیارهای خوب را نمی‌توان محدود به مواردی دانست که بالاتر راجع به آن‌ها صحبت کردیم. برای مثال کیفیت یک معیار مهم در تیم‌های متکی بر مدیریت چابک به حساب می‌آید و چند معیار سنتی هم داریم که می‌توانند در توسعه چابک به کار بسته شوند:

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

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

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

• مطالب پیشنهادی برای مطالعه:
  • ترلو چیست و چگونه از Trello استفاده کنیم؟ — راهنمای رایگان و کامل
  • انواع مکاتب مدیریت — معرفی جامع و به زبان ساده

چارت گانت چیست؟

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

تاریخچه کوتاه چارت گانت

اوایل قرن بیستم میلادی بود که هنری گانت با ابداع چارت گانت، انقلابی در مدیریت پروژه به وجود آورد. در همان نیز چارت‌های گانت روی یک تکه کاغذ پیاده‌سازی می‌شدند. با ظهور کامپیوترها در دهه ۱۹۸۰ میلادی، چارت‌های گانت هم شکلی پیچیده‌تر و مفصل‌تر به خود گرفتند. امروز چارت‌های گانت یکی از برجسته‌ترین ابزارهایی هستند که برای مدیریت پروژه مورد استفاده قرار می‌گیرند.

از چارت گانت برای چه کاری استفاده می‌شود؟

مدیران پروژه به سه دلیل اصلی از چارت‌های گانت استفاده می‌کنند:

ساخت و مدیریت یک پروژه فراگیر

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

تعیین لجستیک‌ها و وابستگی‌های میان وظایف

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

پایش پیشرفت پروژه

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

مزایای استفاده از چارت گانت

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

چارت گانت در مدیریت آبشاری و مدیریت چابک

چارت‌های گانت می‌توانند ابزاری قدرتمند هم برای متدولوژی آبشاری و هم مدیریت چابک باشند.

مدیریت آبشاری

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

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

مدیریت چابک

از طرف دیگر، مدل مدیریت چابک برای انعطاف‌پذیری و تطبیق‌پذیر احترام قائل می‌شود. به جای ساخت یک خط زمانی کامل با انبوهی تاریخ شروع و پایان، تیم‌های چابک پروژه خود را به سیکل‌های کوچک‌تر (که تحت عنوان «تاخت» هم شناخته می‌شوند) تقسیم می‌کنند. در ابتدای یک سیکل تاخت، تیم به برنامه‌ریزی برای اهداف پروژه طی دو هفته آتی می‌پردازد. وقتی آن سیکل به پایان رسید، موفقیت‌ها و خروجی‌های آن به برنامه‌ریزی برای سیکل بعدی کمک می‌کنند.

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

استفاده از چارت‌های گانت

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

مدیریت برنامه در مقابل مدیریت پروژه

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

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

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

این مجموعه آموزشی در ۱۰ درس ارائه می‌شود. در درس اول تا سوم با مفاهیم کلی مدیریت چابک، تاریخچه پیدایش Agile و ارزش‌ها و اصول بنیادین آن آشنا خواهید شد. درس چهارم و پنجم بر توصیف مزایای اجایل و رویکرد اسکرام اختصاص می‌یابند. درس پنجم شما را به شکلی بنیادین با مفهوم Extreme Programming آشنا می‌کند. درس هفتم به صورت جامع مفاهیم کانبان، اسکرام بان، اسکرام و XP را در بر می‌گیرد و در درس هشتم نیز با داستان‌های کاربر و روش‌های استفاده از آن‌ها آشنا می‌شود. درس نهم با تمرکز بر تخمین در رویکرد Agile پیش می‌رود و در درس دهم هم تمرین‌هایی عملی دریافت خواهید کرد تا دانشی که در حوزه مدیریت چابک به دست آورده‌اید مورد آزمایش قرار بگیرد.

مدیریت برنامه چیست؟

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

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

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

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

پروژه‌ها چنین ویژگی‌هایی دارند:

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

برنامه‌ها چنین ویژگی‌هایی دارند:

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

مدیر برنامه چه می‌کند؟

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