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

چابک شوید!

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

بازاریابی چابک را می‌توان اینگونه تعریف کرد: گروهی از تیمها که حول یک پرسش محوری شکل گرفته‌اند: ” چطور می‌توانیم به بهترین نحو ارزش به مشتریان‌ ارائه کنیم؟”

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

اسکرام چیست؟

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

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

قواعد اسکرام

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

خود‌‌سازماندهی

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

چارچوب‌بندی زمان

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

پیشرفت مداوم

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

تعاریف و اصطلاحات مهم

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

 Backlog

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

Sprint

یک دوره زمانی‌ست که از قبل تعیین، و برای انجام کارهای انتخاب شده از backlog انتخاب می‌شود. این زمان معمولا یک تا دوهفته است.

جلسات روزانه ایستاده

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

مرور گذشته

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

صاحب پروژه

آن عضو از تیم است که تصمیم می‌گیرد چه کارهایی باید در backlog  و sprint قرار بگیرد.

Scrum Master

کسی که روند scrum را درون یک تیم به اجرا می‌گذارد و پیش می‌برد.

گردش کار

حالا نگاهی جامع و کلی به روند گردش کار خواهیم داشت، و بعد با جزییات توضیح می‌دهیم که شما چگونه می‌توانید این روند را برای تیم خود اجرا کنید.

۱- مدت زمان یک sprint را مشخص کنید. این زمان نباید کمتر از یک هفته، یا بیشتر از چهار هفته باشد. شما می‌توانید این مدت زمانی را در آینده، و بعد از اینکه فهمیدید سرعت کاری تیم شما چقدر است، تغییر دهید.

۲- بک‌لاگ ایجاد کنید. همه کمپین‌های بازاریابی، کارها، و حتی ایده‌هایی که شاید در آینده اجرا شوند را در backlog قرار دهید.

۳- برای sprint برنامه‌ریزی کنید. تمام پروژه‌ها و کارهایی که باید تا پایان زمان اولین sprint  انجام شوند را در یک برنامه مشخص بگنجانید.

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

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

وقت کار است

خب دیگر تئوری بس است! بیایید ببینیم که چطور می‌توانید این روش را در تیمتان به کار بگیرید، تا بهره‌وری را افزایش داده و بیشتر نتیجه بگیرید. شما همه این کارها را می‌توانید با استفاده از کاغذهای یادداشت چسبان روی یک تخته وایت‌برد انجام بدهید، اما ما می‌خواهیم به شما نشان دهیم که چطور از تسکولو برای انجام همه این کارها استفاده کنید. شما با تسکولو می‌توانید به راحتی backlog, sprint, جلسات روزانه و بررسی‌های sprint را مدیریت کنید.

در مرحله اول باید یک پروژه در تسکولو بسازید.

Backlog

همه ما نیاز به جایی داریم که ایده‌ها، و کارهایی که باید در آینده انجام دهیم را در آن نگه داریم. Backlog دقیقا همین است.

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

برای جلوگیری از این اتفاق، نکاتی هست که باید رعایت کنید:

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

Screen_Shot_2016-05-31_at_8.17.22_PM

‌Sprint

حالا زمان برنامه‌ریزی برای sprintها رسیده است. یک جلسه برای تصمیم‌گیری درباره مدت زمان ‌sprint ها برگزار کنید. حتما همه اعضای تیم باید در این جلسه شرکت کنند. اولین و مهمترین کار تعیین طول زمانی هر sprint  است.

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

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

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

task

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

با همین روش به انجام کار ادامه دهید و کارها را از backlog به sprint منتقل کنید، تا جایی که احساس کنید برای آن دوره از کل توان تیمتان استفاده کرده‌اید. فراموش نکنید که هرکدام از کارها را به یکی از اعضای تیمتان واگذار کنید، و مطمئن شوید که همه اعضای تیم مسئولیت‌هایشان را در طول یک sprint می‌دانند.

بعد از انجام این کار، دوباره کارهایی که به افراد مختلف واگذار کرده‌اید را مرور کنید، و مطمئن شوید که هرکدام از اعضای تیم در حد متعادلی کار برای انجام دادن دارد.

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

2 Screen_Shot_2016-05-31_at_7.56.59_PM

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

جلسات روزانه

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

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

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

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

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

3 Screen_Shot_2016-06-05_at_10.47.43_AM

بررسی

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

راستی براورد زمانی اولیه در ابتدای برنامه‌ریزی برای sprint را که یادتان نرفته؟‌ حالا زمان آن رسیده که براورد خود را با زمان واقعی مقایسه کنید.

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

اصلاح و بهبود

هرچقدر هم که تیم خوبی داشته باشید، باز هم جا برای بهتر شدن هست.

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

  • چه مواردی در طول sprint خوب پیش رفت؟ شاید یکی از اعضای تیم شما ابزاری پیدا کرده که به او امکان داده سریعتر بخش تحلیل کلمات کلیدی (Keyword Analysis) را انجام دهد. با به اشتراک گذاشتن این تجربه مثبت، می‌توان این ابزار را به فهرست ابزارهای مورد استفاده در تیم افزود و از این طریق کارایی کل تیم را بهبود بخشید.
  • چه مواردی در طول sprint خوب پیش نرفت؟ این فرصتی برای مقصر جلوه دادن بقیه نیست. بلکه فرصتی‌ست که بتوانید راه‌های بهتر و کارامدتری برای انجام دادن کارها پیدا کنید و نتایج بیشتری بگیرید.
  • چه تغییراتی ایجاد کنیم تا روند را بهبود ببخشیم؟ این که بدانید چه چیزهایی خوب پیش رفته و چه مشکلاتی وجود داشته کافی نیست. باید از این نکات درس بگیرید و تغییرات ایجاد کنید تا اتفاقات خوب همیشه بیفتند و اتفاقات بد نیز متوقف شوند. مهم است که به بحث و تبادل نظر ادامه دهید تا وقتی که راه‌ حل‌های مشخصی برای هر مورد پیدا کنید.

برای افزایش کارایی، مهمترین چیز ایجاد تغییرات تدریجی و مستمر است. اگر طول sprint شما یک هفته است، هر هفته و پس از پایان هر sprint بهتر است فقط یک تغییر در روند کاری خود به وجود بیاورید. با این روش در پایان سال شما بیش از ۵۰ مورد را در کار خود بهبود داده‌اید. این بهبود‌ها زمان بیشتری را در اختیار شما قرار می‌دهند، و به تیم شما کمک می‌کنند تا بهترین خود را به نمایش بگذارند.

آخرین کلام

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

وقتی این اتفاق بیفتد، تیم شما نتایج بیشتری تولید خواهد کرد، و شادتر، با استرس کمتر و با بهره‌وری بالاتری کار خواهد کرد.

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

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

فرهاد هدایتی‌فرد

فرهاد هدایتی‌فرد

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

در همین زمینه بیشتر بخوانید

8 نظر

  1. سهیل صمدزاده

    اسکرام چارچوب توسعه نرم‌افزاره. چابک هم صرفا نظریه‌ای برای توسعه نرم‌افزار هست! نمیتونید ازش در پروژه‌های دیگه استفاده کنید! به بیانیه چابک مراجعه کنید! 🙂

    • آزاده نوربخش

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

      http://www.agilemarketing.net/what-is-agile-marketing/

      https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&sqi=2&ved=0ahUKEwi34d-4zqzOAhXEtRQKHSs9AT0QFgguMAM&url=http%3A%2F%2Fwww.agilemarketing.net%2Fwhat-is-a-scrum%2F&usg=AFQjCNHeNqoQHrKpL28o7hEuzUWZReokAA&sig2=HUg3lfIsRl5ghWW6lQCs6A&bvm=bv.129391328,d.bGg

      https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&cad=rja&uact=8&sqi=2&ved=0ahUKEwi34d-4zqzOAhXEtRQKHSs9AT0QFgg0MAQ&url=http%3A%2F%2Flabs.openviewpartners.com%2Fscrum-for-non-technical-teams%2F&usg=AFQjCNEQPGG0T4NbGV6We76pegiEntDdsg&sig2=BV9NVO_bL557iTBD4s4FUA&bvm=bv.129391328,d.bGg

      • سهیل صمدزاده

        تعجب میکنم که میگید:

        در هیچ جا تعریفی پیدا نکردیم که نوشته باشه اسکرام و چابک فقط مخصوص توسعه نرم افزار هستند.

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

        برای روشن شدن موضوع به لینک زیر مراجعه کنید (به کلمه‌ی Software دقت کنید در بیانیه و همینطور در اصول 12 تایی):
        http://agilemanifesto.org/
        و اگر فرصت داشتید این لینک رو هم مطالعه کنید:
        http://www.islet.ir/?p=1107
        در مورد لینک هایی که معرفی کردید هم هر کدوم جای بحث داره!

        خلاصه اینکه: شاید بتونید از آموزه ها و تئوری های مطرح شده در چابک (که عموما هم اختراع خود چابک کاران نیست و از تئوری های دیگه گرفته شده) استفاده کنید ولی نمیتونید اسمش رو چابک بذارید. این درست نیست که هر جنبش جوان و عموما بدون پشتوانه‌ی علمی (Agile Marketing, Agile Learning, Agile Supporting, etc) یا مطلب خارجی یا سایت رو چون اجایل به اولش اضافه شده به عنوان اصل بپذیریم چه برسه به اینکه اسکرام که یک چارچوب برای پیاده سازی چابک هست رو در بازاریابی یا حتی پشتیبانی استفاده کنیم!

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

        سپاس

        • آزاده نوربخش

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

          • رضا هاشمی

            به نظر من آقای سهیل نکته دقیق و درستی را اشاره میکنند و بیانیه چابک اصولا برای نرم افزار است. ارزش دوم بیانیه چابک راجع به نرم افزار صحبت میکنه:
            Working software over comprehensive documentation
            همچنین در ۱۲ بند اصول چابک بند های ۱ و ۳ و۷ صراحتا راجع به استفاده در نرم افزار هستند:
            ۱. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
            ۳. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
            ۷.Working software is the primary measure of progress.

            به نظرم اینکه استفاده از شیوه چابک در پروژه های غیر نرم افزاری تطابق با بیانیه چابک نداره کاملا درسته اما اینکه آیا نباید از چابک برای پروژه های غیر نرم افزاری استفاده کرد بحث کاملا متفاوتی است .
            واقعیت اینه که با مدل سازی مشابه از امتیازات چابک برای پروژه های غیر نرم افزاری هم استفاده میشه و موفق بوده و مثلا استفاده از اسکرام برای پروژه های غیر نرم افزاری هم مرسوم است.

  2. حسابدار

    با سلام
    با تشکر از اطلاعات خوبتون می خواستم ببینم فقط از اسکرام برای پروژه های بازرایابی استفاده می کنن؟
    اگر در پروژه های دیگه استفاده میشه لطفا بفرمائید.

    با تشکر

    • آزاده نوربخش

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

  3. فرزاد مشکاتی

    کلا ما دو نوع روش مدیریت پروژه داریم: یک سری از پروژه ها هستند “گستره و محدوده کار” و همچنین “نتیجه آخر کار” از قبل مشخص هست، مثلا قراره شما یک ساختمان یا پل یا یک “محصول” نرم افزاری در تولید انبوه بسازید. این نوع پروژه ها با همان روش های مدیریت پروژه مرسوم و با استانداردهایی همچون pmbok انجام داده می شوند.
    ولی یک سری از پروژه ها هستند که دقیقا مشخصات و خروجی و نتیجه آخر ، نه برای مالک و نه برای پیمانکار مشخص نیست. بلکه در حین کار و با بررسی بیشتر، سایر مشخصات نتیجه نهایی از حالت ابهام بیرون میاد و مشخص میشه و با گرفتن بازخورد مسیر حرکت را اصلاح می کنیم.
    این پروژه ها را با روش های مرسوم و کلاسیک مدیریت پروژه نمی توان به درستی مدیریت کرد. بلکه روش چابک جوابگوی این نوع پروژه هاست. و البته اکثر پروژه های”تولید و توسعه” نرم افزاری را که نتیجه نهایی بصورت تدریجی و قدم به قدم تکمیل میشه را می توان از روش چابک مدیریت کرد. و البته نکته دیگه اینکه بعضی از پروژه های نرم افزاری را باید به همان روش کلاسیک مدیریت کرد. مثلا فرض کنید شما یک شرکت طراحی سایت وردپرس دارید که هر ماه شما تعداد زیادی پروژه مشابه هم دارید. در اینجا مشخصات محصول نهایی دقیقا مشخصه و اینجا دیگه نمیشه از چابک استفاده کرد.
    حالا یکی از چارچوبهای استفاده از روش چابک یا همان agile چارچوب اسکرام است و چون اولین بار برای تولید و توسعه نرم افزار استفاده شده بعضی از دوستان تعصبانه فکر می کنند اسکرام منحصرا برای توسعه نرم افزار است و لاغیر.
    درصورتی که موضوع این مقاله تسکولو درباره مدیریت پروژه هایی مثل سئو هست که از اتفاق می توان به خوبی با متد agile انجام داد.
    مطالعه بیشتر https://moz.com/ugc/best-of-agile-for-seo-management

‎نظر شما چیه؟

‎آدرس ایمیل شما نمایش داده نمی شود‫.‬ ‎پر کردن فیلدهای ‫*‬ دار ضروریه

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>