روش های زیادی ( متدولوژی )‌بوجود آمده اند تا به شما یاد دهند که چطوری یک نرم افزار تولید کنید ولی همه آن ها آنقدر در جزییات به اندازه ی کافی مبهم هستند که از هیچکدام نمی توان استفاده کرد بخاطر همین ساده ترین متدولوژی بهترین متدولوژی است .

• کارفرما / مالک نرم افزار : من قابلیت X را لازم دارم
• مدیر فنی : منظور از قابلیت فنی یعنی …
• دولوپر ها : ما 4 هفته بیشتر زمان لازم داریم چراکه هم درخواست دیر داده شده هم این یک قابلیت جدید است
• کارفرما / مالک نرم افزار : این زمان خیلی دیره
• دولوپر ها : کار بیشتری اضافه شده پس انتخاب کن زمان بیشتر یا کیفیت کمتر .
• مدیر فنی : ما اسپرینت های یک هفته ای تعریف می کنیم و با جلسات بیشتر با تیم فنی مشکل را حل می کنیم

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

هستید و چیزی نمی سازید.

متدولوژی که در آن نیاز به تغییر در سازمان ندارید و خیلی ساده و کم هزینه قابل پیاده سازی باشد فقط نیاز به یک چیز است تیم تاثیرگذار

تیم تاثیرگذار

برای تولید محصول شما نیاز به سه اهرم دارید

• اهرم اول

کسی که وقتی یکی از اعضای تیم سوال دارد از او می پرسد . کسی که می تواند با یک کلام یک بحث چند ساعتی را تمام کند

• اهرم دوم

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

• اهرم سوم

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

اگر شما این سه رهبر را ندارید و در تیمی بیش از یک نفر کار می کنید هیچ وقت قادر نخواهید بود چیزی تولید کنید.

چرا تیم تاثیرگذار لازم است

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

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

سه مثلث نفرین شده

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

بدون آن ها هیچی ساخته نخواهد شد.