ضد الگو ها در توسعه محصول چابک - قسمت دوم


سیلوها:

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

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

راهکار های مختلفی برای این مشکل وجود دارد که از جمله آنها که مورد تجربه من نیز بوده میتوانم به برگزاری Tech meet ها (مخفف Tech Meeting) و مورد بعدی کاهش طبقات در ساختار سازمانی، استفاده از فضای باز Open Office، کاهش فرآیند های بوروکراسی و ... اشاره کنم.

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


قفل شدن:

زمانی میگوییم تیم توسعه دچار قفل Lock in شده است که برای توسعه یک محصول، اتکای بسیار شدیدی به یک تکنولوژی خاص و یا یک vendor داشته باشد. اینجاست که باید برای استفاده از یک تکنولوژی خاص بعنوان "یکی از راهکار های موجود" و بعنوان "تنها راهکار موجود" تمایز قائل شویم.

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

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



مهندسی بیش از حد:

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



طلا کاری Gold-plating:

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

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

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


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

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

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


پایان قسمت دوم.

http://vrgl.ir/KIMp8
http://vrgl.ir/7bI5b
http://vrgl.ir/05BAu
http://vrgl.ir/0Dyzz