Archive

Archive for the ‘Lean’ Category

استارت آپ از نوع لین

ژوئیه 24, 2012 بیان دیدگاه

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

با اینکه راه انداری استارت آپ جذاب می باشد ولی باید به خاطر داشته باشیم از هر 10 استارت آپ 8 استارت آپ شکست می خورد. (البته شکست به نظر من بد نیست ولی استارت آپ ها معمولا بعد از هر شکست ورچیده می شدند و از شکست دست گرفته نمی شد.)

معمولا این استارت آپ ها با یک ایده و فرضیه ای شروع می شود ، «من فکر می کنم این رو درست کنم خواهد فروخت ، من فکر می کنم مشتری این رو می خواد، من فکر می کنم …» .

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

پس در هر استارت آپ مسئله اصلی سرعت است. دوستان خارجی ما اسم جدیدی به نام Lean Startup درآوردند که می شود گفت نسخه تکمیلی برای Agile می باشد.

tumblr_l8tfn09Y7b1qz6pqio1_500.png (500×500)

در کل Lean Startup بر پایه این اصوول است :

  • Eliminate Waste : وقت خود را برای روی ساخت ویژگی هایی که کسی نمی خواهد به هدر ندهید.
  • Create Knowledge : لین استارت آپ در مورد یادگیری مداوم است.
  • Short Iterations : چرخه کوتاه و مداوم برای یادگیری و منطبق سازی.
  • Fail Fast : اگر چیزی قرار نیست کار بکند بهتر است زودتر کار نکند تا بتوانیم فرضیه های دیگر را آزمایش نماییم. 

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

ساختن چیز درست با درست ساختن چیزها فرق دارد

پس در لین استارت آپ فرض بر این است حتی Problem هم ناشناخته است و ما می خواهیم کشف کنیم که مشکل چیست؟ و این همان دلیلی است که یک استارت آپ تشکیل شده است. یک استارت آپ یک ورژن کوچک از سازمان نیست بلکه یک استارت آپ صرفا برای حل کردن یک مشکل ایجاد شده است و برای حل این مشکل با ایجاد Business Model های فرضیه های خود جهت شناخت و حل این مشکل تلاش می کند.

lnAgile.jpg (655×485)
در لین استارت یک پروسه ای داریم به نام Customer Development .  این پروسه معادل جمع آوری نیازمندی های روش های قدیمی نیست، هنری فورد (سازنده ماشین های فورد) گفت: «اگر از مشتری بپرسیم چه چیزی می خواهی ، مشتری خواهد گفت اسب های سریعتر» . Customer Development در مورد معتیر سازی یا Validate چشم انداز خود ما است.

پس  هدف ما در استارت آپ شناخت درست مشکل مشتری و ساخت و ارائه درست راه حل برای برطرف سازی مشکل و خوشحال کردن مشتری و پول در آوردن می باشد.

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

اما بزودی در تهران رویدادی به اسم Startupweekend برگزار خواهد شد که به نوعی یک رویداد Lean startup می باشد. این رویداد برای پرورش کارآفرین جهت ایجاد استارت آپ های لین می باشد.

swteh28aug-hq.jpg (680×220)

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

چابک و موفق باشید

دسته‌ها:Agile, Lean, Lean Startup

تولید محصولاتی که مشتریان عاشقش می شوند

آوریل 20, 2012 بیان دیدگاه

هفته بعد روز پنجشنبه تاریخ 7 اردیبهشت 91 در تبریز کارگاه آموزشی با عنوان کارگاه آموزشی تولید محصولاتی که مشتریان عاشقش می شوند خواهم داشت. این کارگاه رایگان و آزاد خواهد بود. در این کارگاه خواهم کوشید با تکیه بر مطالبی از تفکر Agile و Lean Startup  از طرز تهیه محصولات خوشمزه صحبت و بحث شود.

دوستان علاقمند می توانند از طریق این لینک برای حضور در کارگاه اعلام حضور نمایند.

PDLean.jpg (980×513)

یاشیاسیز

دسته‌ها:Agile, Lean, Lean Startup

کانبان ساده شده

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

کانبان همانند اسکرام یکی از متدهای توسعه چابک می باشد که در این متد توجه بیشتر بر روی ارائه های درجا (just-in-time) و بصری سازی فرآیند توسعه می باشد. کانبان ذاتا از متد تفکری Lean گرفته شده است و بیشتر صنعت گران (بدلیل آشنایی مانند تولید ناب و تویوتا وی) با کانبان آشنا هستند.

کانبان یک متد مدیریتی بصری (Visualize) است که می گوید چه چیزی تولید کنید ، چه زمانی تولید کنید ، چه قدر تولید کنید (بر اساس ذات ناب ، اساس آن بر تولید ناب و ارزش گرا و پرهیز از تولید تلف شده می باشد)

کانبان در اختصار

کانبان فقط شامل یک تابلو (Board) می باشد که کارهای در جریان روی آن تابلو قرار می گیرد. این تابلو توسط ستون هایی که هر ستون نشان دهنده وضعیت کاری (مثلا در حال توسعه یا در حال تست و یا …) به چندین قسمت تقسیم شده است. کارهای موجود در ستون های مختلف این تابلو سیر می نمایند تا به آخرین ستون برسند .

1.jpg (407×203)نکاتی در رابطه با کانبان

  • برای هر ستون محدودیتی در نظر گرفته می شود که فقط این تعداد کار در هر زمان می تواند در داخل این ستون قرار داشته باشد.  این محدودیت را اصلاحا محدودیت WIP یا Work-in-progress بیان می شود.
  • کانبان یک سیستم کششی می باشد . یعنی اگر تیم تست کاری برای انجام دادن در ستون خود نداشت ، مقدار کاری را (نسبت به محدودیت) از ستون قبلی خود به ستون خود می کشد (پس تیم توسعه حق ندارد کار انجامم شده خود را به ستون تیم توسعه هل بدهد ، برای اینکه آیتم های تکمیل شده هم در این ستون تجمیع نشود از ستون هایی با عنوان صف یا بافر استفاده می شود)
  • تابلوهای مختلفی می توان برای کانبان ایجاد کرد که بهترین تابلو فقط از طریق تجربه به دست خواهد آمد.
  • در کانبان کارها به صورت اسپرینتی نیست که آخر هر اسپرینت ارائه ای انجام شود ، در کانبان هر وقت که لازم شد و یا طبق برنامه ریزی خاصی می توان ارائه داشت و جلساتی مانند بازبینی و بازنگری را انجام داد.
  • نقش ها در کانبان تجویز شده نیستند ولی می توان از نقش های اسکرام (مالک محصول / اسکرام مستر / تیم ) استفاده کرد.
  • کانبان در فاز نگه داری سیستم بسیار خوب عمل می کند.
  • یک تابلوی کانبان بین همه تیم ها و اشخاص مشترک می باشد و نیازی به تابلوهای جداگانه نیست.

برای درک رفت و آمد مابین ستون ها مشاهده این فایل با عنوان یک روز در سرزمین کانبان توصیه می شود.

یاشیاسیز

دسته‌ها:Agile, Kanban, Lean برچسب‌ها: , , ,

Lean در خدمت Agile

اکتبر 4, 2010 2 دیدگاه

https://sirasad.files.wordpress.com/2010/10/ninjasuit.jpg?w=300چشم بادامی ها یا مردمان خاور دور همیشه در همه بحث ها  در آسیا و کل دنیا زبان زد عام و خاص بوده اند به طوری که هم اکنون برتری آسیا نسبت به آفریقا فقط 3 کشور ژاپن ,  چین و کره می باشند. به عبارتی قاره کهن به داشتن این 3 کشور به خود می بالد حتی در محافل بین المللی  نماد آسیا چشم بادامی هایند  . حالا گذشته از سامورایی های ژاپنی ,  کونگ فو کاران چینی ,  فوتبالیست های کره ای ,  معبد شائولین ,  بروس لی و جکی چان و … ,   این مردمان همیشه مبدع سیستم های فکری و متدلوژی های زندگی بوده اند . سیستم های فکری آنها فقط در حوزه ورزش و یا زندگی نبوده است یعنی آنها فقط تای چی کار نمی کنند ,  بلکه تای چی را در صنعت به کار می گیرند . این مردمان بی ادعا در دنیا سیستم های تولیدی متعددی را بنا نهاده اند که Lean یکی از شاهکارهای تولیدی آنها می باشد .

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

ارزش – هزینه – تلفات : اینها عوامل کلیدی در تولید می باشند که کنترل کردن و یا نکردن آنها منجر به پیروزی یا شکست صنعت خواهد شد . تفکر Lean اگر همراه سیستم «برنده/برنده» نباشد به درد نخواهد خورد به عبارتی باید در Lean سیستم «برنده/برنده» نهادینه شده باشد . در تولید دو رکن اصلی وجود دارد : تولید کننده و مصرف کننده . در سیستم غیر «برنده / برنده» تولید کننده یا مصرف کننده به فکر منافع خود هستند («برنده/بازنده» یا «بازنده/برنده» یا «بازنده/بازنده») . اگر سیستم فکری بر اساس «برنده/برنده» باشد این سیستم قادر به گرایش به سیستم تولید ناب یا Lean خواهد بود .

درسیستم «برنده/برنده» منافع همه ذینفعان باید برآورده شود : یعنی هم مصرف کننده و هم تولید کننده . منافع مصرف کننده در واقع ارزش های مستمری که در سیستم تولید ناب دریافت می کند می باشد و منافع تولید کننده هزینه کم و اتلاف منابع حداقلی می باشد . یعنی Lean خود یک سیستم «برنده/برنده» است بدلیل اینکه در اینجا هم منافع مشتری در نظر گرفته می شود و هم تولید کننده .

از اصلی ترین اصول Lean می توان به موارد زیر اشاره کرد :

  • از بین بردن اتلافات (Waste)
  • ایجاد کیفیت در ارزش آفرینی
  • خلق و کسب دانش

از بین بردن اتلافات

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

  • انجام کارها به صورت ناقص و ناتکمیل
  • امکانات و ویژگی های اضافی
  • دست به دست کردن های بی مورد و زیاد
  • Task Switching
  • تاخییر ها
  • Defects and bugs

ایجاد کیفیت در ارزش آفرینی

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

خلق و کسب دانش

برای ارزش آفرینی نیاز به سازمان ها و انسان های یادگیرنده داریم . سازمان و یا شخص یاد گیرنده کسی است که کاری را جز برای یاد گرفتن نکند . اگر ما در ارائه و یا تولید در فکر یادگرفتن بیشتر ارزش های مشتری باشیم ,  می توانیم محصولی با ارزش های مشتری تولید کنیم ,  می توانیم از تولید امکانات و ویژگی های اضافی جلوگیری نماییم ,  می توانیم در پروسه تولید بهبود به وجود آوریم و می تواینم هزینه ها را کاهش دهیم .بنابر این یکی از اصول Lean  کسب دانش در طی تولید می باشد .

ربط Agile و Lean چیست ؟

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

https://sirasad.files.wordpress.com/2010/04/agile-pills.png?w=228&h=152همانطور که بیان شد بحث Lean مربوط به بحت تولید و یا Production می باشد در حالیکه ما در صنعت نرم افزار عملا توسعه یا Development  می کنیم و نه تولید (قبلا در همین باب مقاله ای نوشته شده است ) . با این حساب شاید به نظر برسد که Lean در بحث توسعه کاربردی ندارد !؟ نه اصلا اینگونه نیست . برای اینکه بتوان به تفکر Lean در محیط توسعه نرم افزار رسید می توان از تفکر Agile استفاده کرد .

Agile – Agile – Agile . دوستی می گفت ما هرچه به شما گفتیم چکار کنیم شما گفتی : Agile . این بار هم می گویم Agile .

در واقع یکی از پایه های محکم Agile همان Lean  می باشد . یعنی دوستانی که لطف کردند و بیانیه Agile را ساختند کاملا بر بحث Lean واقف بودند و کاملا بعضی از اصول Agile  مبتنی بر اصول Lean می باشد .

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

این موارد را می توان در دسته اصل خلق و کسب دانش Lean دسته بندی کرد .

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

این موارد را نیز می توان در دسته های از بین بردن اتلافات (Waste) و ایجاد کیفیت در ارزش آفرینی دسته بندی کرد .

شاید یعضی از موارد که ذکر شد بی ربط به موضوع به نظر بیاید ولی اینطور نیست . خود تفکر Agile از روی یک سری تفکرات مانند Lean , Toyota way و از همه مهمتر تجربیات توسعه گران نرم افزار توسعه داده شده است . وجود تفکر Lean در داخل هسته ی Agile  کاملا مشهود است و کسانی که از Agile در محیط واقعی خود بهره جسته اند می توانند بر این موضوع صحه بگذارند که بعد از استفاده از این تفکر اتلافات آنها کم شده است – هزینه ها پایین تر آمده است – محصولاتشان با کیفیت تر شده است و … .

شاید سوال پیش بیاید که آیا ما در کنار Agile باید از Lean هم استفاده کنیم ؟ مسلما جواب بلی است ولی نه اینکه Lean با یک پروسه جدید . در واقع شما اگر تفکر Agile را به درستی (درست به معنی کامل نیست) در سازمان خود نهادینه کرده باشید ,  خواسته یا ناخواسته متد Lean  را هم اجرا کرده اید .

پس اگر Lean داخل Agile هست ,  پس چرا شما برای این مورد مقاله می نویسید و وقت ما را تلف می کنید ؟ دغدغه نوشتن مقاله و تشریح مسئله Lean از آنجایی حادث می شود که بنده مشاهده می کنم که سازمان هایی و یا اشخاصی از عناوین Agile ما/من استفاده می کنند («ما اینگونه Agile کار می کنیم / ما در Agile فلان اصل را انجام نمی دهم / من فلان اصل را دوست ندارم /  ما نمی توانیم با مشتری همکاری بکنیم/ همه نیروهای کار ما احمق هستند و فلان اصل اینجا قابل اجرا نیست / … «) . اینکه سازمان ها و یا اشخاص به بلوغی رسیده اند که از Agile خود استفاده می کنند بسیار خوب است و من هم همه این دوستان را تحسین می کنم ولی دغدغه من این است که با حذف مواردی از اصول Agile  یا حتی حذف روش های متدی مانند اسکرام نکند که Lean را کنار بگذاریم ؟ نکند محصول بی کیفیت تولید کنیم ؟ نکند اوضاع بدتر شود ؟ و … .

https://sirasad.files.wordpress.com/2010/10/iiff_2.jpg?w=500

شاید بپرسید که ما نرم افزار بی کیفیت تولید می کنیم , چرا برای شما دغدغه ایجاد می شود ؟ کسی که Agile را یاد گرفته است و آن را در سازمان خود اجرا می کند ,  اگر مواردی را حذف کند بدون اینکه بداند چه ارزش هایی را حذف کرده است ,  نباید منتظر دستیابی به آن ارزش ها در آینده باشند . دوستان مواردی را از Agile حذف می کنند و بعد به نتیجه ای که مثلا در فلان وبلاگ و یا فلان کتاب خوانده بودند (کیفیت بالا – هزینه کم – مشتری رضایت مند – نیروی کار با انگیزه – سود بیشتر ) نمی رسند که باید هم همینطور باشد . البته باز هم عرض می کنم من با بومی سازی و یا همسان سازی Agile با سازمان به هیچ وجه مخالف نیستم و همیشه هم تشویق می کنم که دوستان انجام بدهند ولی وقتی اصلی را قبول ندارید باید اصل دیگری را که به همان نتیجه می رساند مصوب بکنید و جایگزین نمایید .

زمانیکه دوستان با روش های شبه Agile خود کار می کنند و نتایج قابل قبول را نمی گیرند شروع به تبلیغ منفی و رواج شعار «این در ایران به درد نمی خورد » یا «من می دونم نمی شه » می کنند و ناکامی های خود را ناشی از نواقصات و معایب روش Agile می دانند و نه روش شبه Agile خود : زمانیکه از این روش استفاده می کنند همیشه از لفظ Agile من/ما استفاده می کنند ولی وقتی ناکام می شوند از Agile آن وبلاگ/سایت/کتاب یاد می کنند در حالیکه Agile مشکلی ندارد بلکه Agile من/ما مشکل دارد .

سازمان های بزرگ زیادی در خود آمریکا با همین روش Agile چندین میلیون دلار ضرر کرده اند یعنی اول MY Agile و بعدا Their Agile کرده اند و به همان روش قبلی سوئیچ کرده اند . پس در استفاده کردن و یا نکردن از روش Agile کمی دقت نمایید .

Lean فکر کنید و Agile باشید .

یاشیاسیز

دسته‌ها:Agile, Lean برچسب‌ها: , , , ,