این یک داستان است. شرح حال یک شرکت فرضی و فرایند تبدیل آن از سنتی به چابک. این داستان هم واقعی است و هم نه. واقعی است از این جهت که بسیاری از موارد ذکر شده مشکلات و معضلاتی است که شرکت‌ها در عمل با آنها درگیر بوده یا هستند. هر خواننده ممکن است بخشی از این داستان را آشنا ببیند و حس کند که در شرکت‌های کوچک و بزرگی که در آنها کار کرده این تجربه‌ها را از سر گذرانده است. اما واقعی نیست از این جهت که واقعا به این شکل اتفاق نیافتاده یا دست کم من ندیده یا نشنیده‌ام. با این توضیح برویم سراغ اصل ماجرا.
پیش درآمد
الان که دارم نوشتن این داستان را شروع می‌کنم، چند دقیقه است که جلسه بازنگری اسپرینت تمام شده و از روز بعد اسپرینت جدیدی را شروع خواهیم کرد. این داستان شرکت ما است. می‌نویسم که در خاطره جمعی شرکت بماند و بخصوص همکاران تازه بدانند که از کجا به کجا رسیدیم.
1- روزی روزگاری، واترفال
برای شروع داستان باید چند سال برگردم عقب و کمی از پیشینه و اوضاع شرکت در آن سالها بگویم. شرکت ما در واقع یک سازمان بزرگ با تعداد زیاد پرسنل و سابقه چندین ساله است که کار اصلی‌اش تولید نرم‌افزار است و تعدادی هم مشتری قدیمی و جدید دارد.
این شرکت واحدهای مختلفی دارد. مثل تولید، کنترل کیفیت، امنیت، بازاریابی و فروش، اداری، منابع انسانی. در هر کدام از این واحدها هم بسته به پروژه‌ها و کارهای موجود، تعدادی تیم تشکیل شده. هر تیم یک سرپرست دارد که به مدیر واحد مربوطه گزارش می‌دهد، مدیران واحدها هم گزارشات کلی پیشرفت پروژه‌ها و وضعیت کارها را به مدیرعامل می‌دهند.
واحدها و تیم‌ها هر کدام شرح وظایف مخصوص به خود دارند و بصورت مستقل از بقیه کار می‌کنند. معمولا ارجاع کار بین واحدها و تیم‌ها از طریق سیستم‌های نرم افزاری و اتوماسیون اداری انجام می‌شود و درخواست تلفنی یا شفاهی مجاز نیست. تیم‌ها کاری را انجام نمی‌دهند مگر اینکه بصورت مکتوب و پس از طی سلسله مراتب لازم آن را دریافت کرده باشند. در ضمن تیم های فنی اجازه تماس مستقیم با مشتری را ندارند و هر گونه درخواست از طرف مشتری باید از طریق واحد مشتریان شرکت به دست بقیه برسد. این دستور مدیریت است که کارها کاملا شسته رفته و روال‌ها کاملا مشخص باشد. همه درخواست‌ها و فایل‌ها و مستندات بصورت سیستمی بین تیم‌ها تبادل می‌شوند. همچنین عودت محصول یا مستند به واحد تولید کننده به هر دلیل، از جمله به دلیل نقص یا نیاز به اصلاح، نیز بصورت مکتوب صورت می‌گیرد.
در واحد فنی، بسته به نوع کار و تخصص، تیم های مستقلی وجود دارد. مثل تیم های تحلیل، طراحی و تولید. وقتی تحلیل نیازمندی‌ها انجام می‌شود نتیجه بصورت یک مستند جامع و از طریق سیستم‌های موجود تحویل تیم معماری و طراحی می‌شود. مستند طراحی پس از تهیه، به همین ترتیب تحویل تیم تولید می‌شود. سپس کدها توسط تیم تولید نوشته و نرم افزار تولید شده برای بررسی و تایید، تحویل واحدهای کنترل کیفیت و امنیت می‌شود و همینطور الی آخر.
شرکت یک واحد کنترل پروژه هم دارد که همیشه اول هر سال از هر تیم لیست پروژه‌ها و کارهای در دست انجامش را به همراه زمان بندی و گانت چارت دقیق و با جزییات کامل دریافت می‌کند و بر اساس آن در هر فصل پیشرفت پروژه‌ها را پیگیری و به مدیرعامل گزارش می‌کند.
2- خوب، بد، زشت
حیات شرکت بستگی به سه چیز دارد: مدیران، کارمندان و مشتریان. ببینیم هر کدام از این سه، چه اوضاع و احوالی دارند.
مدیران
کار اصلی مدیران در هر لایه، نظارت بر انجام کارها و پیگیری آنها است و اطمینان از اینکه آیا زیردستان کار خود را درست انجام می‌دهند و با تمام توان کار می‌کنند یا خیر.
قبل از شروع هر کار و با نظارت و تایید مدیر، مدت زمانی برای انجام آن تعیین می‌شود. مهم است که هر کاری در زمان تعیین شده‌اش انجام شود و بیشتر طول نکشد.
برای مدیریت مهم است که نیروهای تحت امر حتی یک ثانیه هم پِرت زمانی نداشته باشند و در تمام مدت حضور، پشت میز نشسته و مشغول باشند. اضافه کاری هم از عوامل مهم و امور پسندیده است که نشان می‌دهد یک نفر برای کار شرکت اولویت قائل است و حاضر است از وقت خود برای شرکت مایه بگذارد.
مدیران هرماه نیروهای زیردست را بر اساس پارامترهایی که برخی‌اش گفته شد ارزیابی می‌کنند و به آنها بسته به امتیاز ارزیابی‌شان پاداش می‌دهند. کسانی که امتیاز خوبی نگرفته یا خرابکاری کرده و یک باگ و مشکل جدی ایجاد کرده باشند را هم بسته به درجه اهمیت و میزان خرابی که بار آمده، توبیخ و جریمه می‌کنند.
مدیرها شنیدن خبر بد را دوست ندارند و با کسانی که خبر بد می‌دهند برخورد می‌کنند. برای همین بقیه، بخصوص مدیرهای زیردست گاهی وقت‌ها مجبور می‌شوند بعضی مشکلات را پنهان کنند و اول اخبار را به قول معروف پاستوریزه کرده و بعد به گوش مدیر بالادست می‌رسانند. وگرنه ممکن است مورد غضب واقع شوند. برای حفظ میز و جایگاه، معمولا تعریف و تمجید و چشم گفتن به مدیر بالادست یکی از راهکارهای اصلی است.
کارمندان
اما بشنویم از کارمندان که البته در شرکت معمولا از آنها به اسم سرمایه انسانی نام برده می‌شود. البته سرمایه ای که به راحتی جایگزین می‌شود. بارها دیده شده یک نیروی باتجربه و با دانش فنی خوب به دلایل مختلف به راحتی و بدون اینکه بدانند دردش چیست، کنار گذاشته شده.
کارمندان طبیعتا پارامترهای ارزیابی و خواسته‌های مدیران را کم و بیش می‌دانند. به همین خاطر معمولا زیاد از پشت میزها بلند نمی‌شوند و اغلب اضافه کاری هم می‌کنند. برای اینکه توبیخ نشوند معمولا کارهای پر ریسک انجام نمی‌دهند و تا آنجا که بشود سعی می‌کنند مسئولیت چیزی را نپذیرند و کارها را بسپرند به دیگران. بعضی‌ها که نمی‌توانند با این شیوه کار کنار بیایند، یا شرکت را ترک می‌کنند یا اینکه خودشان را عادت می‌دهند و یاد می‌گیرند که زیاد با مدیرها کَل کَل نکنند و به قول معروف همرنگ جماعت می‌شوند.
گاهی هم بین پرسنل اختلافات و دعواهایی پیش می‌آید که دلایل مختلفی دارد، مثل اینکه چرا مدیر به یک نفر امتیاز بیشتر داده و به یکی کمتر. یا اینکه مدیر به یک نفر کارهای بهتر و جذاب‌تری ارجاع می‌دهد و به آن یکی نه. البته که دلایل شخصی و اختلافات سلیقه‌ای معمول نیز به جای خود.
مشتریان
حالا بشنویم از آن طرف میز. از احوالات کارفرما یا همان مشتری. مشتری‌های شرکت یک ویژگی دارند، اینکه همیشه طلبکار و ناراضی‌اند. از تاخیرها، از مشکلات سیستم و قطعی‌ها. از عملکرد فیچرها و روال‌های پیاده شده. از رنگ آیکن‌ها، از همه چیز. اگرچه مو به مو طبق سند نیازمندی‌های اولیه پیاده سازی شده‌اند. اما مشتری باز هم ناراضی است. چه می‌شود کرد؟ مشتری است دیگر، مشتری همیشه همین است. اگر دستت را عسل کنی و بگذاری دهانش باز هم گاز می‌گیرد و غر می‌زند و بیشتر می‌خواهد. این جملاتی است که معمولا همه در شرکت درباره مشتری می گویند. از مدیر گرفته تا کارشناسان فنی.
اگرچه مشتری معمولا راضی نیست، اما کاری هم نمی‌کند. چون چاره دیگری سراغ ندارد و فکر می‌کند که در همه شرکت‌های نرم افزاری همین بساط است. تازه شرکت این شرکت برای خود اسم و رسمی دارد و به هرحال چند پیراهن بیشتر از شرکت‌های دیگر پاره کرده و در این صنعت استخوان ترکانده. خلاصه اینکه مشتری کج دار و مریز با مشکلات سر می‌کند و از آن طرف، با پول ندادن جبران می‌کند و به ازای هر تاخیر یا مشکل نیز بصورت ساعتی یا روزانه، شرکت را جریمه می‌کند. خلاصه خون به دل مدیران شرکت می‌کند.
عنوان این بخش را خوب، بد، زشت گذاشتم. اما از بین مدیران، کارمندان و مشتریان، کدام خوب و کدام بد و کدام زشت هستند؟ به نظرم جواب بستگی به جایگاه شما دارد. در هر گروهی که باشید شما خوب هستید و دو تای دیگر بد و زشت!
3- کاسه چه کنم
برای رفع مشکلات موجود طبیعی است که شرکت به دنبال راهکار باشد. به این منظور معمولا یک یا چند جلسه مدیریتی برگزار می‌شود، بعضا کمیته‌ای نیز جهت بررسی موضوع و ارائه راهکارهای احتمالی تشکیل می‌شود.
راستی قبل از اینکه به توضیح راهکارهای معمول در شرکت بپردازم، لازم است یک فرض اساسی که همیشه وجود دارد را ذکر کنم. همیشه و در همه حال در ذهن کسانی که دنبال راهکار هستند این فرض وجود دارد که “ما خوبیم و مشکل از بقیه است”. در واقع راهکارهای ارائه شده در راستای این است که چه می شود کرد که بقیه که منشا و عامل مشکلات هستند، نتوانند مشکل درست کنند و اگر هم کردند، چگونه مسئول و مقصر پیدا و چه راه‌های تنبیهی اتخاذ شود؟
راهکار اصلی معمولا سفت و سخت گرفتن و مستند سازی همه چیز است. بخصوص در قبال مشتری. نیازمندی‌ها باید مکتوب باشند و به تایید و امضای مشتری برسند و ضمیمه قرارداد شوند تا بعدا جا برای حرف و حدیث و گله گذاری باقی نماند.
راهکار دیگر که به نوعی در راستای همان راهکار اول است این است که فرایندهای جدید تعریف شود و ابزارهای تازه ای مورد استفاده قرار گیرد. احتمالا در این مرحله با یک شرکت بیرونی بعنوان مشاور قراردادی بسته می‌شود و از همان شرکت یا شرکت دیگر، ابزاری جهت مدیریت و پیگیری چرخه کار خریداری می‌گردد. این قراردادها حداقل دوساله است و به احتمال زیاد تمدید می‌شود.
مجموعه این راهکارها و فرایند ها و ابزار، منجر به رواج هرچه بیشتر فرهنگ سازمانی پاس‌های تک ضرب می‌شود. یعنی تیم‌ها و واحدها نهایت تلاش خود را می‌کنند که هرچه کمتر توپ را پیش خود نگه دارند و هرچه سریع تر شوت کنند یا پاس بدهند به بغلی و البته فراموش نکنند که این شوت و پاسکاری را حتما در سیستم هم ثبت کنند.
این وسط گاهی راهکارهای دیگری نیز به ندرت دیده می شود. از جمله یک بار از کنج یکی از اتاق‌های تنگ و تاریک شرکت و از درون یکی از تیم‌های فنی، یکی از کارمندان که چیزهایی در مورد اجایل و اسکرام شنیده و خوانده، پیشنهاد می‌دهد که آن را هم امتحانی بکنند. سرپرست تیم مخالفت نمی‌کند و اجازه می‌دهد. بدین ترتیب تلاشی در این رابطه شکل می گیرد. خود آن کارمند می شود اسکرام مستر و برای اعضای تیم هم یک جلسه آموزشی برگزار می‌کند و درباره دیلی اسکرام و جلسات برنامه ریزی و بازنگری توضیحاتی می‌دهد. یک تخته وایت برد هم دست و پا می کند و خلاصه اسکرام شروع می‌شود. از مالک محصول البته خبری نیست. طبیعتا امکان دسترسی به مشتری هم وجود ندارد. بنابراین همان تسک‌های جاری داخل گانت چارت می‌شود بک لاگ.
در صورتی که نیاز به همکاری با سایر تیم‌ها هم باشد که اغلب اینطور است، طبق روال عادی شرکت نامه نگاری انجام و سلسله مراتب تایید رعایت می‌شود و همین معمولا باعث تاخیر می‌شود و گاهی یک کار از یک اسپرینت به اسپرینت‌های بعدی و بعدی و بعدی کشیده می‌شود.
درباره این نیمچه اسکرام البته به جز سرپرست همان تیم کسی در شرکت چیزی نمی‌داند و مدیران بالادست روح شان نیز از آنچه در آن اتاق تنگ و تاریک می‌گذرد خبردار نیست.
اما با وجود همه تلاش‌ها، تمهیدات، پول‌های خرج شده و ابزار خریده شده، حکایت همچنان باقی است: مشتری ناراضی، کارمند ناراضی ، مدیر ناراضی.
4- سونامی
کمی جلوتر بیاییم و به اتفاقی بپردازیم که نقشی اساسی در تغییر و تحولات آتی شرکت داشت.
واحد بازاریابی و فروش شرکت که مدتی بود با تمام توان مشغول مذاکره برای تصاحب یک پروژه و عقد یک قرارداد نان و آب دار بود، سرانجام پس از چانه زنی فراوان و طی تشریفات مختلف و مناقصه موفق شد بر رقبا پیروز شود و پروژه را از آن خود کند.
به مناسبت این موفقیت، مدیرعامل یک جلسه عمومی ترتیب داد و سخنرانی کرد و تبریک گفت و به خود و شرکت معظم‌اش بالید و وعده پاداش داد.
کمی که گذشت و تب تبریک و تهنیت‌ها فروکش کرد، پروژه رسما آغاز شد. یک نفر به عنوان مدیر پروژه تعیین شد. سپس تیم تحلیل دست به کار شد و جلسات دریافت نیازمندی‌ها با مشتری را آغاز کرد. وقت کم بود و نیازمندی‌ها زیاد و متنوع. بعد از سه ماه نیازمندی‌ها جمع آوری و مستند شد و تحویل داده شد. نوبت به تیم طراحی رسید که بر اساس مستند تحلیل به معماری نرم افزار و طراحی اجزاء نرم‌افزار بپردازد که آن هم چند ماه طول کشید. سرانجام مستندات طراحی به دست تیم تولید رسید. در این زمان گانت چارت 60 درصد پیشرفت در پروژه نشان می داد و البته اندکی هم تاخیر که نگران کننده نبود. همه چیز خوب به نظر می رسید.
مسئولیت اصلی پیاده سازی پروژه به تیم آ سپرده شد. اما با توجه به اینکه در بسیاری موارد سرویس‌هایی که تیم ب و پ و ت متولی‌اش بودند هم استفاده می‌شد و نیاز به تغییرات داشت، وابستگی‌هایی پدید آمد. حین پیاده سازی وقتی که تیم آ از تیم دیگر درخواستی داشت، طبق روال درخواست خود را طی نامه‌ای اعلام می‌کرد. تیم گیرنده هم با توجه به اینکه اغلب درگیر کارهای دیگری بود و اولویت‌های متفاوتی داشت، درخواست تیم آ را هم در لیست کارهای خود می‌گنجاند و طبق اولویت‌های خود و با توجه به زمان آزاد نیروهایش، انجام می‌داد. البته که پیگیری‌های تیم آ برای انجام کار اجتناب ناپذیر بود. خلاصه پیاده سازی هم بدین ترتیب پیش می‌رفت.
ناگفته نماند که در این حین مستند طراحی هم به دلیل نیاز به اصلاح چند باری رفت و برگشت.
با توجه به اینکه ددلاین پروژه نزدیک بود کم کم تماس‌ها و پیگیری‌های مشتری شروع شد و پیرو آن مدیر پروژه و مدیرعامل هم جویای چند و چون کار شدند.
ددلاین رد شد اما هنوز خبری از نرم افزار نبود. مشتری وعده‌ی “به زودی” دریافت می کرد و از این سو نیز اضافه کاری‌ها و “زودباش دیر شد” ها شروع شد.
سرانجام، پیاده سازی تمام شد و نرم افزار تحویل واحد کنترل کیفیت و امنیت شد.
واحد کنترل کیفیت تست فیچرها را شروع کرد و امنیت نیز بررسی‌های امنیتی نرم افزار را. طبق روال، همه باگ‌ها، اشکالات کارکردی و ملاحظات امنیتی بصورت یکجا و طی گزارشی جامع ارائه می‌شد. به این دلیل تیم آ تا رسیدن گزارشات مشغول کارهای دیگر شد.
در این حین برای آرام کردن مشتری که هرچه زودتر نرم افزارش را می‌خواست، یک جلسه دمو در محیط توسعه تنظیم شد. نمایندگان مشتری در روز و ساعت مقرر در واحد توسعه شرکت حاضر شدند. هرچه جلسه پیش می‌رفت و فیچرهای بیشتری دمو می‌شد، اخم نمایندگان مشتری نیز بیشتر در هم می‌رفت. کم کم زمزمه‌ها و غُرغُرها شروع شد. نمایندگان مشتری نرم افزار را مطابق خواسته خود نمی‌دیدند. برخی فیچرها و روال ها اساسا نقص داشت و برخی دیگر کار کردنش برای کاربر سخت و غیر عملی بود. خلاصه اینکه جلسه با نارضایتی مشتری و لیست بلند بالایی از اصلاحات و تغییرات تمام شد.
از سوی دیگر ، گزارشات تست و امنیت نیز از راه رسید و تیم آ دوباره مشغول توسعه شد که هر روز تا پاسی از شب ادامه داشت.
ناگفته پیدا است که دیگر فرصتی برای هماهنگی با واحد تحلیل و طراحی و بروزرسانی مستندات مربوطه نبود و فقط و فقط کد نوشته می‌شد.
در نهایت با فشار مشتری تاریخی برای عملیاتی شدن نرم افزار تعیین شد و “زودباش” و “بدو بدو” ها باز هم بیشتر و کارها تقریبا دو شیفته شد. البته با همان تعداد نفرات.
هرطور بود نرم افزار با تاخیر چندماهه راه اندازی و به مشتری اطلاع رسانی شد.
نمایندگان مشتری دست به کار شدند و کار عملی با سیستم را شروع کردند. دوباره تعداد زیادی باگ و درخواست پیدا شد. مشکل دیگر کندی و قطعی‌های سیستم بود که با اضافه شدن کاربران جدید افزایش می‌یافت، تا جایی که پس از مدتی دیگر امکان استفاده از نرم افزار وجود نداشت. بنابراین مشتری رسما اعلام کردند که تا زمان رفع مشکلات و قطعی‌های مکرر از نرم افزار استفاده نخواهد کرد و اینگونه، سرویس ها پایین آمد و کار با آن متوقف شد.
خستگی‌ها به تن شرکت و بیش از همه تیم آ مانده بود.
مشتری نامه‌ای شدید الحن ارسال کرد و با استناد به شرایط نقض تعهدات پیمانکار در قرارداد، مبلغ هنگفتی را بعنوان جریمه اعلام و تهدید به فسخ و ارجاع به مراجع قانونی نمود.
مدیرعامل مثل یک ببر زخمی، خشمگین بود و نمی‌شد طرفش رفت. اول پرداختی‌ها را معلق کرد و بعد هم همه افراد در گیر پروژه را از ریز و درشت و کوچک و بزرگ به خط کرد و زیر آتش گرفت.
آنچه می‌خواست این بود که بداند تاخیرها از چه بابت بوده؟ آیا چیزی بوده که در تحلیل و طراحی دیده نشده؟ و اینکه مقصر یا مقصرین که بوده اند؟
آخر سر نیز کاسه و کوزه ها بر سر توسعه دهنده ها شکست که همه باگ ها و کندی و قطعی‌ها، ناشی از کدهای ضعیف و بی دقتی آنها بوده است.
5- راه‌های نرفته
فسخ قرارداد از طرف مشتری عواقب و هزینه‌های سنگینی برای شرکت داشت. گذشته از ضرر هنگفت مالی، اعتبار شرکت را نیز خدشه دار می‌کرد. لذا شرکت با پذیرش شرایط مشتری و پرداخت جریمه و با مذاکره و چک و چانه، مشتری را راضی کرد و نهایتا 2 ماه از او فرصت گرفت.
فقط 2 ماه برای اینکه همه مشکلات سامانه رفع و مطابق نیاز مشتری بروزرسانی و عملیاتی گردد.
فوری در دفتر مدیرعامل جلسه ای تشکیل شد و همه مدیران احضار شدند و در خصوص اینکه چگونه این ماموریت دو ماهه را به سرانجام برسانند، به رایزنی پرداختند. هر کس نظری داشت. اما اغلب پیشنهادها حول ایجاد فرایندهای جدید و تقسیم وظایف و ایجاد گردش کارهای دقیق که مو لای درزش نرود می‌گشت. به تبع هر فرایندی، برای اجرا نیاز به ابزار هم داشت و لذا پیشنهاد استفاده از ابزارهای مختلف هم مطرح می‌شد. یکی می‌گفت که قبل از هرکار باید یک کمیته حقیقت یاب تشکیل و اتفاقات پیش آمده آنالیز شود و سپس فرایندها و ابزار بر اساس آن تعریف گردد. اغلب حاضرین در خصوص موارد مطرح شده به تایید سر تکان می‌دادند و موافق بودند. فقط یک مشکل وجود داشت و آن تنگی زمان بود که همه راهکارها به بن بست آن برخورد می‌کرد. دو ماه برای هیچ راهکاری کافی به نظر نمی‌رسید.
بین مدعوین کسی بود که تقریبا اتفاقی در جلسه حاضر شده بود. مدیرش به دلیل علاقه‌ای که به او داشت در لحظه آخر با او تماس گرفته بود و از آن اتاق تنگ و تاریک گوشه شرکت برای حضور در جلسه فراخوانده بود. او سرپرست همان تیمی بود که چند وقت بود تلاش می‌کردند اسکرام را در تیم خود پیاده کنند. گرچه همانطور که گفته شد، اسکرام شان به دلایل مختلف تحول و تفاوتی ایجاد نکرده بود، با این حال همین بهانه و انگیزه‌ای شده بود که او مطالعات خود را در خصوص چابکی و اسکرام بیشتر کند و حالا او تقریبا دانش خوبی در این خصوص داشت و با اصول پایه نگرش چابک آشنا بود.
با این که او خیلی اهل حرف زدن نبود، اما وقتی بلاتکلیفی جمع را دید، فرصت را غنیمت شمرد و پیشنهادی مطرح کرد. اصل حرفش دو چیز بود. اول اینکه در فرصت دو ماهه نمی‌شود همه مشکلات محصول را حل کرد، اما می‌شود روی نیازمندی‌های اصلی و ضروری مشتری تمرکز کرد و حتی الامکان آنها را بهبود داد. دوم اینکه از همه تیم‌های درگیر از جمله تیم ب و پ و ت، همچنین تیم تست و امنیت، نمایندگانی با دانش و اختیار کافی و تمام وقت به تیم آ اضافه شوند. تا برای رفع وابستگی‌ها نیاز به نامه نگاری و هماهنگی نباشد. همچنین تست و بررسی‌های لازم همراه با توسعه انجام شود تا کارها با کمترین میزان اتلاف وقت انجام شود.
این پیشنهاد به مذاق اکثریت خوش نیامد. در مخالفت، این انتقادات مطرح شد که اولا همه نیازمندی‌ها به یک اندازه برای مشتری مهم است و نمی‌توان بعضی را به بقیه اولویت داد. در ضمن دور زدن روال‌های تعریف شده منجر به بی نظمی می‌شود و مشکلاتی که بعدها ایجاد می‌کند ضررش بیشتر است و بعد از این دیگر نمی‌شود هیچ کاری را پیگیری کرد و کسی را مسئول دانست.
با وجود بحث‌ها و نظرات بعضا موافق و اغلب مخالف، مدیرعامل تصمیم گرفت که اعتماد کند. در واقع چاره دیگری نداشت. به همین دلیل سرپرست مقیم در اتاق تنگ و تاریک را مسئول این کار کرد و به مدیران مربوطه نیز دستور داد که ظرف یک ساعت پس از جلسه نمایندگان تیم‌های ب و پ و ت و همینطور مسئول تست و مسئول امنیت را معرفی کنند.
عصر همان روز تیم یک جلسه توجیهی سریع برگزار شد و کار شروع شد.
تمرکز روی دو موضوع قرار گرفت. اول تعیین اینکه کدام بخش‌ها بودنش در محصول برای مشتری ضروری است و بدون آن نمی‌شود. به این منظور پس از هماهنگی با مشتری، چند تن از اعضای تیم، راهی محل مشتری شدند و دوباره پای صحبت آنها نشستند. هدف این نبود از مشتری لیست سرویس‌های ضروری را بگیرند، بلکه این بود که مهمترین مشکلی که مشتری انتظار داشت با این نرم افزار حل شود، همچنین دلیل نارضایتی شان از نرم افزار فعلی را درک کنند. در نهایت بعد از یک روز کامل جلسات گوناگون با افراد مختلف، گروه به شرکت برگشت. البته بعد از اینکه شماره‌های تماس مستقیم بین طرفین رد و بدل شد.
مساله دوم، دلایل قطعی و مشکلات فنی بود. برای این منظور نیز کلیه لاگ‌های موجود سیستم دریافت و بررسی شد. با خود مشتری نیز در این خصوص تماس گرفته شد و سناریوهای کاربری که منجر به خطا می‌شد پرسیده شد. بررسی شد که کدام فیچرها بیشترین مشکل را داشته‌اند و اینکه آیا می‌شود آنها را موقتا غیرفعال کرد یا نه. حتی فیچرهای ضروری هم دوباره بازنگری شد و اگر جزئی یا مرحله ای از آنها امکان حذف داشت، آن نیز لحاظ می‌شد.
همه تلاش این بود که در مدت دو ماه، چیزی به مشتری تحویل شود که عملا بتواند بخشی از نیاز مشتری را پاسخ دهد و کمترین اشکال را نیز داشته باشد.
بر اساس مجموعه این بررسی و پرس و جوها، لیستی تهیه شد از کارها، شامل بهبود های فنی و فیچرهای ضروری. سپس کارها اولویت بندی شد و تیم دست به کار شد. 2 ماه که البته حدودا یک هفته‌اش سپری شده بود، تقسیم شد به 7 هفته. هر صبح با یک دیلی کوتاه شروع می‌شد. در ابتدا و انتهای هر هفته نیز جلسات برنامه ریزی و بازنگری در مختصرترین شکل ممکن برگزار می‌شد. در حین کار تماس روزانه با مشتری برقرار بود. همچنین هر جا مانعی پیدا می‌شد یا همکاری فرد یا تیمی بیرونی نیاز بود، یک تماس با مدیرعامل کافی بود تا مانع مرتفع گردد.
برای بخش‌هایی از سیستم که به نظر می‌رسید بیشترین خطا و باگ از آنجا ناشی شده بود یونیت تست نوشته شد. ناگفته نمایند که از آنجا که اعضای تیم با یونیت تست آشنا نبودند، از تیم دیگر فردی که آشنایی عملی داشت ملحق شد و در این زمینه همکاری کرد. البته که با توجه به ضیق وقت تنها بخشی که ضرورت داشت پوشش داده شد.
در مدت دو ماه چند بار از نمایندگان مشتری دعوت شد و حضوری در مورد تغییرات، صحبت و همفکری شد.
هفته آخر به نصب و استقرار و عملیاتی کردن سیستم اختصاص داده شد. البته که فرصتی برای ایجاد روال‌های اتوماتیک نبود و بخش عمده کار بصورت دستی انجام شد.
در موعد مقرر، سیستمی با حداقل امکانات آماده و نصب شده بود.
وقتی مشتری، بخصوص مدیران مشتری، بعد از دو ماه با نرم افزار مواجه شدند، از اینکه برخی فیچرها قبلا بوده و الان غیرفعال شده بود، برانگیختند و بنا کردند به گله و شکایت. اما وقتی درگیر کار با نرم افزار شدند و تغییرات صورت گرفته را دیدند، کم کم راضی شدند. البته این رضایت بر زبان ایشان نیامد. اما از همین هیچ نگفتن هنگام کار با نرم افزار و همینطور از حرف‌ها و بیان برنامه‌های شان درباره ادامه پروژه می‌شد فهمید که راضی و به آینده محصول امیدوار اند.
در ادامه، تیمی که تشکیل شده بود به همان شکل و با همان نفرات به کار خود ادامه داد و دست به کار بقیه فیچرها و نیازها شد. اعضای قرضی تیم ب و پ و ت، همچنین نفرات تست و امنیت در همان تیم ماندگار شدند و دیگر همه رسما عضو یک تیم بودند. سرپرست از اتاق تنگ و تاریک خود اسباب کشی کرد و شد مالک محصول. همچنان ارتباط با مشتری برقرار بود، و پشتیبانی مدیرعامل هم سر جای خود. می‌شود گفت که دیگر چرخ پروژه از گِل درآمده بود.
6- این داستان، پایان ندارد
از اینجا به بعد داستان را با دور تند دنبال می‌کنیم. بعد از این تجربه انگیزه و علاقه برای تیم‌های بیشتری ایجاد شد که با روش جدید، کار کنند. بخصوص که مدیرعامل هم دیگر حامی بزرگ آن بود. از این رو برای تیم‌های مختلف، دوره‌های آموزشی چابک برگزار شد. ناگفته نماند که خیلی‌ها علاقه ای به این تغییرات نداشتند و بصورت نامحسوس مقاومت و سنگ اندازی‌هایی می‌کردند. از جمله برخی مدیران که نگران جایگاه شغلی خود بودند. همچنین کارمندانی که روش قدیمی برای‌شان راحت‌تر و بی دردسرتر بود. اما به هرحال چابکی در شرکت راه خود را پیدا کرده بود و داشت رشد می‌کرد. مثل یک آیین جدید. آیینی که در آن ارائه راهکار ارزشمند، اهمیت داشت. نه صرفا انجام وظیفه تعریف شده و پاسکاری. آیینی که در آن تلاش فعالانه همه، بخصوص کارمندان کف هرم سازمان و افراد ساکن در اتاق‌های تنگ و تاریک ضروری بود و بجای دستور و جریمه، اعتماد برقرار بود!
گرچه این نوشته رو به اتمام است، اما این پایان داستان نیست. این داستان پایانی ندارد، چون رشد و بهبود پایان ندارد.
سخن آخر
اول اینکه ممنون که این نوشته نسبتا طولانی را تا اینجا خواندید. بعد هم اینکه این داستان را نمی‌توان به چشم راه حل و نسخه ای که بی کم و کاست باید پیچید دید. هر شرکت و سازمان به اقتضای خود باید راهکارهای ویژه خود را بیابد. این داستان و سایر داستان‌های موفقیت صرفا نمونه‌هایی هستند که شاید بشود از آنها الهام گرفت. اما خط به خط و بدون توجه به شریط خاص هر شرکت پیاده کردن آنها، قطعا خطا است.
نکته آخر اینکه این نوشته راهنما و آموزش چابکی و اسکرام و تمرین های مرتبط با آن نیست و حتی تا جای ممکن عامدانه از اسم بردن و اشاره به آنها پرهیز شده. در این داستان صرفا قصد این بوده که حس و حال کلی و تفاوت‌های نگرش چابک با ساختار سنتی و آبشاری بیان شود . آنطور که برای کسی که هیچ آشنایی با چابکی و اسکرام ندارد قابل درک باشد. امیدوارم اندکی موفق به این کار شده باشم. لطفا نظرات خود را با من در میان بگذارید.
دی ماه 1398