بدترین تجربه زمان برنامه نویسی و استقرار برنامه
استقرار نرمافزار در شهرک صنعتی؛ سانتیمتر به سانتیمتر! (تجربه ای از استقرار در سال 1395 دریکی از شرکت های تولیدی صنعتی)
استقرار نرمافزار در یک مجموعه صنعتی، از دور شاید خیلی ساده به نظر برسد؛ چند جلسه تحلیل، کمی برنامهنویسی، نصب نرمافزار، آموزش کاربران و تمام!
اما واقعیت پروژههای صنعتی معمولاً چیز دیگری است.
گاهی برای اینکه فقط یک فرآیند ساده از کاغذ به نرمافزار منتقل شود، باید هفتهها و ماهها با عادتهای قدیمی، مقاومت کاربران، اطلاعات ناقص، ناهماهنگی مدیران و حتی مشکلات داخل تیم پروژه دستوپنجه نرم کرد.
یکی از پروژههایی که برای من دقیقاً چنین تجربهای بود، استقرار یک سیستم نرمافزاری در یکی از شهرکهای صنعتی بود؛ پروژهای که واقعاً باید آن را سانتیمتر به سانتیمتر جلو میبردیم.
همهچیز روی کاغذ خوب بود!
در شروع پروژه، تقریباً همهچیز منطقی و ساده به نظر میرسید.
قرار بود اطلاعات بخشهای مختلف کارخانه بهتدریج در یک سیستم متمرکز جمع شود و بخشی از فرآیندهای عملیاتی، مخصوصاً نگهداری و تعمیرات تجهیزات، از حالت سنتی خارج شود.
هدف مشخص بود:
ثبت تجهیزات، برنامهریزی سرویسهای دورهای، ثبت خرابیها، صدور دستور کار تعمیرات، کنترل قطعات مصرفی، بررسی زمان توقف ماشینآلات و در نهایت ارائه گزارشهای مدیریتی.
از نظر نرمافزاری کار شدنی بود.
مشکل اصلی از جایی شروع شد که پای «استقرار واقعی» وسط آمد.
مشکل پروژه فقط کد و نرمافزار نبود
خیلی زود متوجه شدیم که بزرگترین مانع ما باگ نرمافزاری یا دیتابیس نیست.
مسئله اصلی، آدمها و فرآیندها بودند.
بعضی مدیران همکاری لازم را نداشتند. اطلاعاتی که برای راهاندازی سیستم نیاز داشتیم یا دیر تحویل داده میشد، یا ناقص بود، یا اساساً کسی نمیدانست نسخه درست آن کجاست.
بخشی از اطلاعات داخل فایلهای Excel بود.
بخشی روی کاغذ.
بخشی در دفترهای قدیمی.
و بخش مهمتری هم فقط در ذهن افراد باتجربه مجموعه وجود داشت.
از طرف دیگر، بعضی کاربران احساس میکردند نرمافزار قرار است برایشان کار اضافه ایجاد کند.
مثلاً تعمیرکاری که سالها بعد از تعمیر یک دستگاه فقط شفاهی گزارش میداد، حالا باید علت خرابی، قطعه مصرفشده، زمان شروع و پایان تعمیر و اقدام انجامشده را ثبت میکرد.
طبیعی بود که مقاومت شکل بگیرد.
وقتی مشکل از داخل تیم هم شروع میشود
داستان فقط به مجموعه مشتری ختم نمیشد.
داخل تیم توسعه هم مشکلاتی وجود داشت.
در مقاطعی، تمرکز لازم روی پروژه وجود نداشت و حتی سرپرست تیم برنامهنویسی بخشی از زمان پروژه را صرف کارهای شخصی خودش میکرد.
نتیجه مشخص بود:
کارهایی که باید در زمان مشخص انجام میشد، عقب میافتاد.
درخواستهای کاربران جمع میشد.
اصلاحات با تأخیر انجام میشد.
و اعتماد مجموعه به تیم نرمافزار کمکم آسیب میدید.
در چنین پروژههایی، هر تأخیر کوچک میتواند یک زنجیره بزرگ از مشکلات ایجاد کند.
کاربر میگوید نرمافزار مشکل دارد.
برنامهنویس میگوید اطلاعات ناقص است.
مدیر میگوید کاربران همکاری نمیکنند.
کاربر میگوید مدیر تصمیم مشخصی نمیگیرد.
و پروژه کمکم وارد یک دور باطل میشود.
نرمافزار صنعتی را نمیشود فقط پشت میز ساخت
یکی از مهمترین درسهای آن پروژه برای من این بود که نرمافزار صنعتی را نمیتوان فقط از داخل اتاق برنامهنویسی طراحی کرد.
باید وارد محیط واقعی کار شد.
باید کنار دستگاه ایستاد.
باید دید وقتی یک ماشین متوقف میشود دقیقاً چه اتفاقی میافتد.
چه کسی خرابی را اعلام میکند؟
چه کسی تعمیرکار را خبر میکند؟
آیا برای تعمیر دستور کار صادر میشود؟
قطعه یدکی از انبار چگونه تحویل داده میشود؟
زمان توقف دستگاه را چه کسی ثبت میکند؟
علت واقعی خرابی کجا نوشته میشود؟
و مهمتر از همه:
آیا این اطلاعات بعداً قابل استفاده هستند یا دوباره در یک دفتر یا فایل گم میشوند؟
وقتی این سؤالها را از نزدیک بررسی کردیم، متوجه شدیم بعضی از چیزهایی که در نرمافزار کاملاً منطقی به نظر میرسند، در محیط واقعی کارخانه عملاً قابل اجرا نیستند.
پس مجبور شدیم نرمافزار را با واقعیت کار تطبیق دهیم، نه اینکه انتظار داشته باشیم کارخانه خودش را یکشبه با نرمافزار تطبیق دهد.
سیستم نگهداری و تعمیرات؛ قلب مهم پروژه
یکی از مهمترین بخشهای پروژه، سیستم نگهداری و تعمیرات یا همان CMMS بود.
فرآیند کلی تقریباً به این شکل طراحی شد:
ثبت تجهیزات و ماشینآلات
↓
تعریف برنامههای سرویس و نگهداری پیشگیرانه
↓
ثبت خرابی یا ایجاد درخواست تعمیر
↓
صدور دستور کار
↓
تخصیص نیروی تعمیرات و قطعات موردنیاز
↓
انجام عملیات تعمیر
↓
ثبت علت خرابی و فعالیتهای انجامشده
↓
ثبت زمان توقف دستگاه
↓
بستن دستور کار و ثبت در سوابق تجهیز
↓
تحلیل اطلاعات و ارائه گزارش مدیریتی
روی کاغذ، این فقط چند مرحله پشت سر هم است.
اما در عمل، پشت هر مرحله چند نفر، چند واحد سازمانی و تعداد زیادی تصمیم و هماهنگی قرار دارد.
یک نفر که واقعاً پروژه برایش مهم بود
در میان تمام مشکلات پروژه، یک اتفاق مهم مسیر کار را تغییر داد.
در مجموعه، فردی بود که واقعاً دلش میخواست سیستم به نتیجه برسد.
نه به این دلیل که کسی مجبورش کرده بود.
نه برای اینکه فقط گزارشی به مدیر ارائه کند.
واقعاً به پروژه اهمیت میداد.
هرجا اطلاعات ناقص بود، پیگیری میکرد.
با کاربران صحبت میکرد.
مشکلات را دقیق منتقل میکرد.
جلسات را هماهنگ میکرد.
موارد عقبافتاده را دوباره دنبال میکرد.
و اجازه نمیداد پروژه کاملاً متوقف شود.
وجود همان یک نفر باعث شد بخش زیادی از فاصله بین تیم نرمافزار و مجموعه صنعتی کم شود.
گاهی در پروژههای بزرگ، یک نفر دلسوز و مسئولیتپذیر بیشتر از دهها جلسه و صورتجلسه میتواند پروژه را نجات دهد.
پروژه را تکهتکه کردیم
در نهایت فهمیدیم اجرای یکباره کل سیستم تقریباً غیرممکن است.
بنابراین پروژه را مرحلهبندی کردیم.
ابتدا اطلاعات پایه تجهیزات تکمیل شد.
بعد ثبت خرابیها راه افتاد.
سپس دستور کارهای تعمیراتی وارد سیستم شدند.
بعد نوبت برنامههای PM و سرویسهای پیشگیرانه رسید.
در مرحله بعد، ارتباط با قطعات مصرفی و انبار فنی بهتر شد.
و در آخر، گزارشها و داشبوردهای مدیریتی شکل گرفتند.
هر قسمت که جا میافتاد، وارد مرحله بعد میشدیم.
به همین دلیل بهترین توصیفی که برای آن پروژه دارم همین است:
استقرار سانتیمتر به سانتیمتر.
وقتی دادهها شروع به حرف زدن کردند
بعد از مدتی، اطلاعاتی که قبلاً پراکنده و بیاستفاده بودند، کمکم تبدیل به داده قابل تحلیل شدند.
مدیریت میتوانست پاسخ سؤالهایی را ببیند که قبلاً جواب دقیقشان مشخص نبود.
مثلاً:
کدام دستگاه بیشتر خراب میشود؟
کدام خرابی بیشتر تکرار شده است؟
کدام خط تولید بیشترین زمان توقف را دارد؟
متوسط زمان تعمیر هر دستگاه چقدر است؟
کدام قطعات بیشترین مصرف را در تعمیرات داشتهاند؟
چند درصد سرویسهای دورهای در زمان مناسب انجام شدهاند؟
هزینه نگهداری یک تجهیز در طول سال چقدر بوده است؟
اینجا بود که نرمافزار از یک ابزار ساده ثبت اطلاعات، تبدیل شد به یک ابزار واقعی برای تصمیمگیری.
چیزی که از آن پروژه یاد گرفتم
آن تجربه برای من یک نتیجه خیلی مهم داشت:
موفقیت نرمافزار فقط به کیفیت برنامهنویسی وابسته نیست.
ممکن است بهترین معماری، بهترین دیتابیس، بهترین فرمها و بهترین گزارشها را طراحی کنید؛ اما اگر مدیران همراه نباشند، کاربران سیستم را نپذیرند، فرآیندها مشخص نباشند و تیم پروژه تمرکز نداشته باشد، استقرار شکست میخورد.
در مقابل، اگر چند نفر واقعاً مسئولیتپذیر باشند و پروژه را رها نکنند، حتی یک پروژه گرفتار و فرسایشی هم میتواند دوباره روی مسیر درست قرار بگیرد.
استقرار نرمافزار در صنعت یعنی ترکیب تکنولوژی، فرآیند و انسان.
و شاید «انسان» مهمترین بخش این معادله باشد.
ما آن پروژه را سریع جلو نبردیم.
مسیرش ساده هم نبود.
گاهی یک قدم جلو میرفتیم و دو قدم عقب برمیگشتیم.
اما در نهایت، همان حرکتهای کوچک و مداوم نتیجه داد.
بعضی پروژهها (شاید بهتر است بگویم بیشتر پروژه های نرم افزار) کیلومتری جلو نمیروند؛ سانتیمتر به سانتیمتر ساخته میشوند.