https://virgool.io/feed/@hosseinhelali دارم نوشتن کم کم تمرین می کنم و از ایده ها و چیزایی می نویسم که توی این سالها یاد گرفتم. fa 2026-04-15 04:45:13 https://files.virgool.io/upload/users/88306/avatar/7jUkzQ.jpg?height=120&width=120 https://virgool.io/@hosseinhelali https://virgool.io/@hosseinhelali/%DA%86%D8%B1%D8%A7-%D8%AD%D8%A7%D9%84-%D8%AA%DB%8C%D9%85-%D9%87%D8%A7%DB%8C-%D9%81%D9%86%DB%8C-%D8%A7%D8%B3%D8%AA%D8%A7%D8%B1%D8%AA%D8%A7%D9%BE-%D9%87%D8%A7-%D8%AA%D9%88%DB%8C-%D8%A7%DB%8C%D8%B1%D8%A7%D9%86-%D8%AE%D9%88%D8%A8-%D9%86%DB%8C%D8%B3%D8%AA-arp7hcz1cgsr ویدیوبرای دیدن ویدیو روی این متن کلیک کنیدچرا این مقاله را نوشتم؟در سال‌های اخیر، به عنوان مدیرفنی، تجربه‌ی کار با چندین استارتاپ و شرکت بزرگ فناوری در ایران را داشته‌ام. در خلال این همکاری‌ها، بارها با الگوهای تکرارشونده‌ای از مشکلات مواجه شدم؛ مشکلاتی که تیم‌های فنی، مدیران محصول و رهبران فناوری در سازمان‌های در حال رشد با آن‌ها دست و پنجه نرم می‌کنند. این مشکلات صرفاً فنی نیستند؛ بلکه ریشه در ساختار، فرهنگ، راهبری و حتی مدل تصمیم‌گیری درون سازمان‌ها دارند.در بسیاری از این شرکت‌ها، پس از یک دوره رشد سریع، سازمان وارد مرحله‌ای می‌شود که من از آن با عنوان «دره مرگ» یاد می‌کنم. جایی که افزایش پیچیدگی، فشارهای کسب‌وکار، ضعف در کیفیت نرم‌افزار و انباشت بدهی‌های فنی و امنیتی، تیم‌ها را در شرایطی قرار می‌دهد که دیگر نمی‌توانند پاسخگوی انتظارات باشند. در چنین وضعیتی، انسیدنت‌ها به رویدادهای روزمره تبدیل می‌شوند و اعتماد میان ذی‌نفعان و تیم‌های فنی به‌شدت تضعیف می‌شود.ایده‌ی نگارش یک کتاب برای مستندسازی این تجربیات و ارائه‌ی راهکارهای عملی مدت‌ها در ذهنم بود. اما با توجه به فوریت و اهمیت موضوع، تصمیم گرفتم محتوای این کتاب را در قالب یک سلسله ویدیو و مقالات تحلیلی منتشر کنم تا افراد و سازمان‌هایی که اکنون درگیر این چالش‌ها هستند، سریع‌تر بتوانند از آن بهره‌مند شوند.در نخستین ویدیوی این مجموعه، که در بالا لینک آن را در اختیارتون گذاشتم, تصویری کلی از وضعیت فعلی سازمان‌های بزرگ فناوری در ایران ترسیم کردم و توضیح دادم که چرا بسیاری از آن‌ها در وضعیت بحرانی قرار گرفته‌اند. اما برای شکافتن لایه‌های عمیق‌تر این بحران و بررسی ریشه‌ها و راه‌حل‌ها، به نوشتن این سلسله مقاله و ویدیو نیاز بود.در این سلسله مقاله ها تلاش می‌کنم به پرسش‌های زیر پاسخ دهم:چرا سازمان‌ها پس از رشد دچار بحران می‌شوند؟نشانه‌ها و الگوهای رفتاری در وضعیت «دره مرگ» چیست؟چگونه می‌توان با تفکر سیستمی و نگاهی تکاملی از این وضعیت عبور کرد؟سازمان پیچیده‌ی تکاملی چه ویژگی‌هایی دارد؟معماری سازمان، نرم‌افزار، تیم‌ها و فرهنگ در این نوع سازمان‌ها چگونه باید باشد؟این مقاله برای کسانی نوشته شده که می‌خواهند فراتر از سطح، به لایه‌های زیرین مشکلات سازمانی نفوذ کنند و با ابزارهای تفکر سیستمی، راهی برای پایداری و پیشرفت بیابند.با من همراه باشید.توسعه سریع و ناپایداری سرویس هادر مسیر رشد و توسعه استارتاپ‌ها و کسب‌وکارهای دیجیتال، نقطه‌ای بحرانی وجود دارد که می‌توان آن را "دره مرگ" نامید. این مرحله زمانی رخ می‌دهد که پس از یک دوره رشد سریع، پیچیدگی‌های فنی و مدیریتی افزایش یافته و کارایی تیم‌های فنی کاهش می‌یابد. اعتماد میان مدیران ارشد و تیم‌های فنی تضعیف می‌شود و کسب‌وکارها برای حفظ بقا به اقدامات فوری و بعضاً مخاطره‌آمیز روی می‌آورند. که در ادامه به بررسی این مرحله بحرانی، اقدامات مخاطره‌آمیز و راه‌حل‌های ممکن برای عبور از آن می‌پردازد.ناپایداری سرویس ها در صدر ریسک‌های کسب‌وکارنگاهی به کسب‌وکارهای بزرگ مبتنی بر فناوری، به‌ویژه استارتاپ‌های برجسته در ایران، نشان می‌دهد که نارضایتی‌های مشترکی میان صاحبان کسب‌وکار نسبت به عملکرد تیم‌های فناوری وجود دارد. این مشکلات اغلب منجر به اقدامات اصلاحی توسط مدیران می‌شود که گاهی به تغییرات اساسی در ساختارهای سازمانی یا نیروی انسانی می‌انجامد، اما نه‌تنها مشکلات را حل نمی‌کند، بلکه ممکن است پیچیدگی‌ها را بیشتر کند.موضوعی که در این میان برجسته می‌شود این است که ناپایداری سرویس به یکی از بزرگ‌ترین تهدیدها برای توسعه کسب‌وکارها تبدیل شده است. این مشکل زمانی پیچیده‌تر می‌شود که بدانیم بازار بزرگ و انحصاری ایران فرصت‌های بالقوه زیادی برای توسعه ارائه می‌دهد؛ اما یکی از موانع اصلی بر سر راه این توسعه، ناپایداری سرویس‌هاست. این وضعیت شبیه به یک شرکت تولیدکننده نوشیدنی است که پس از تبلیغات سنگین، مشتریان زیادی را جذب کرده، اما زمانی که آن‌ها به فروشگاه‌ها مراجعه می‌کنند، کالا در قفسه‌ها موجود نیست.این موضوع را می‌توان به‌طور خلاصه در یک جمله بیان کرد:"ناپایداری سرویس در صدر ریسک‌های کسب‌وکار برای توسعه آن قرار گرفته است."در چنین فضایی، اعتماد به تیم‌های فناوری و مدیران آن‌ها به‌شدت کاهش می‌یابد و اختلاف‌ها میان آن‌ها و سایر ذینفعان سازمان نمایان می‌شود. وقتی کسب‌وکار وارد "دره مرگ" می‌شود، نشانه‌های بحرانی و خطرناک در سطح سازمان پدیدار می‌شود که می‌توان به موارد زیر اشاره کرد:فرد محوری به‌جای تیم‌محوری: سیستم به‌جای آنکه مبتنی بر تیم‌های کارآمد باشد، به افراد کلیدی وابسته شده و آن‌ها به ریسک بزرگی برای مجموعه تبدیل می‌شوند.عدم درک درست از مشتری: تیم‌های نرم‌افزاری به‌دلیل فاصله زیاد با مشتریان، از اولویت‌ها و دغدغه‌های واقعی آن‌ها آگاهی ندارند. این باعث می‌شود راه‌حل‌های ارائه‌شده عملاً به نیازهای بازار پاسخ ندهند.پروژه‌های نیمه‌تمام و زمان‌بندی نامشخص: حجم زیادی از پروژه‌ها و تولیدات در مرحله نیمه‌تمام باقی می‌مانند و هیچ‌گونه زمان‌بندی دقیق و پیش‌بینی شفافی برای تکمیل آن‌ها وجود ندارد.عدم توانایی در برنامه‌ریزی و مدیریت زمان: افراد و تیم‌ها قادر به برنامه‌ریزی مناسب و زمان‌بندی دقیق برای انجام کارها نیستند و این باعث افزایش تاخیرها و پیچیدگی‌ها می‌شود.زمان طولانی برای ارائه محصول: زمان لازم برای تولید و ارائه محصولات به‌طور چشمگیری افزایش یافته و روند توسعه به کندی پیش می‌رود.تغییرات گسترده و نامشخص: تغییرات گسترده‌ای در سازمان در حال اجراست، اما تأثیر این تغییرات بر بهبود سرویس مشخص نیست. در برخی موارد، سازمان حتی مسیر خود را در این تغییرات گم کرده است.عدم هماهنگی بین تیم‌ها: تیم‌های مختلف در سازمان هماهنگی خود را از دست داده‌اند و سیستم به‌صورت غیر همگرا عمل می‌کند. تغییرات در یک بخش به‌درستی با سایر بخش‌ها همگام نیست.عدم تفکیک مسئولیت‌ها: مالکیت و مسئولیت‌ها به‌درستی تفکیک نشده و مشخص نیست چه کسی مسئول کدام قسمت از پروژه است. این سردرگمی باعث بی‌اعتمادی بیشتر می‌شود.تعامل ناکافی و نادرست بین تیم‌ها: تعامل موثر بین تیم‌های زیر ساخت و تولید کاهش یافته و این مسئله کیفیت سرویس‌ها را تحت تاثیر قرار داده است. حتی گاهی تعاملات نادرست به نتایج اشتباه و خطرناکی منجر می‌شوند.سازمان یادگیرنده نیست: سازمان تحلیل جامعی از رویدادها ندارد و با مشکلات به‌صورت سطحی و موضعی برخورد می‌کند. یادگیری از اشتباهات و تحلیل دقیق داده‌ها جایی در فرایندها ندارد.محافظه‌کاری به‌دلیل ترس از اشتباه: تیم‌ها به‌دلیل ترس از اشتباهات محافظه‌کار شده‌اند و همین امر باعث تکرار مکرر مشکلات می‌شود، بدون اینکه راه‌حل‌های کارآمدی پیدا شود.بی‌انگیزگی و انفعال تیم‌های فنی: علی‌رغم هزینه‌های بالای تیم‌های فنی، میزان انگیزه و تحرک در این تیم‌ها پایین است و آن‌ها با بی‌انگیزگی و انفعال روبرو هستند.افزایش زمان Onboarding: جذب و راه‌اندازی افراد جدید به‌طور چشمگیری زمان‌بر شده است، که این مسئله سرعت بهبود تیم‌ها و فرآیندها را کندتر می‌کند.افزایش استخدام‌ها بدون حل مشکل: افزایش تعداد نیروها و افزایش هزینه‌ها نه‌تنها مشکل را حل نکرده، بلکه منتقدان بیشتری را به مجموعه اضافه کرده است.وجود بهانه‌های متعدد برای به تعویق انداختن کارها: بهانه‌های زیادی برای سهل‌انگاری، تاخیر و به تعویق انداختن کارها وجود دارد که این موضوع بهره‌وری تیم‌ها را به شدت کاهش داده است.این موارد نه تنها نشان‌دهنده کاهش کارایی سازمان است، بلکه ورود به "دره مرگ" (که در ادامه به آن می پردازیم)را تأیید می‌کند؛ جایی که اگر این چالش‌ها به درستی مدیریت نشوند، می‌توانند به کلافی سردرگم منجر شوند.چرا این کسب و کارها دچار این آشفتگی و درهم ریختگی می شوند؟شروع یک استارتاپ معمولاً با یک ایده ساده و محدود آغاز می‌شود. در مراحل اولیه، استارتاپ‌ها با تیمی کوچک و منابع محدود می‌توانند به سرعت به نیازهای مشتریان پاسخ دهند. اما با رشد سریع کسب‌وکار و افزایش تعداد مشتریان، پیچیدگی‌ها به تدریج افزایش می‌یابند:افزایش تعداد مشتریان: با جذب مشتریان بیشتر، نیاز به خدمات و محصولات متنوع‌تر ایجاد می‌شود که منجر به پیچیدگی در مدیریت درخواست‌ها و پاسخگویی به آن‌ها می‌شود.تنوع خدمات: برای حفظ رقابت، استارتاپ‌ها معمولاً خدمات و ویژگی‌های جدیدی اضافه می‌کنند. این امر باعث افزایش پیچیدگی سیستم‌ها و فرآیندهای عملیاتی می‌شود.تنوع روش‌های دسترسی به خدمات: مشتریان ممکن است از طریق اپلیکیشن موبایل، وب‌سایت و سایر پلتفرم‌ها به خدمات دسترسی پیدا کنند که این تنوع نیاز به هماهنگی و یکپارچگی بیشتری دارد.نیاز به پاسخگویی سریع‌تر: به منظور بهبود تجربه کاربری، زمان پاسخ‌دهی به درخواست‌های مشتریان باید کوتاه‌تر و کارآمدتر شود.فناوری و زیرساخت: رشد سریع نیازمند زیرساخت‌های قوی‌تر، از جمله سخت‌افزار و نرم‌افزار است. انتخاب فناوری‌های مناسب و ادغام آن‌ها در سیستم‌ها می‌تواند بسیار پیچیده باشد.افزایش سرورها و سخت‌افزارها: با افزایش بار سیستم، نیاز به سرورهای بیشتر و ارتقای تجهیزات سخت‌افزاری ضروری می‌شود.افزایش داده‌های ذخیره‌شده: با رشد کسب‌وکار، حجم داده‌های مشتریان، تراکنش‌ها و اطلاعات بیشتر می‌شود و نیاز به زیرساخت‌های مناسب برای ذخیره‌سازی و مدیریت داده‌ها ضروری است.نیاز به افزایش سرعت پردازش اطلاعات: برای مدیریت حجم بالای داده‌ها و درخواست‌ها، سیستم‌ها باید بهینه‌سازی شوند و توان پردازشی بیشتری پیدا کنند.افزایش پهنای باند شبکه: با افزایش تعداد کاربران و درخواست‌ها، پهنای باند شبکه باید گسترش یابد تا خدمات بدون وقفه ارائه شود.استخدام برنامه‌نویسان و مهندسان بیشتر: گسترش تیم توسعه برای طراحی و نگهداری سیستم‌های پیچیده به افراد متخصص بیشتری نیاز دارد.مدیریت تیم‌ها: با رشد کسب‌وکار، تیم‌ها نیز بزرگ‌تر می‌شوند و نیاز به هماهنگی و مدیریت موثر بین اعضا افزایش می‌یابد. این موضوع ممکن است منجر به چالش‌های ارتباطی و فرآیندی شود.افزایش این پیچیده گی منجر به کاهش کیفیت سرویس ها می شود:افزایش خطاها (More Fail): با پیچیده‌تر شدن سیستم‌ها، احتمال وقوع خطاها بیشتر می‌شود.افزایش تاخیر در پاسخگویی (Request Latency): به دلیل بار بالای سیستم‌ها، زمان پاسخگویی ممکن است افزایش یابد که منجر به نارضایتی کاربران می‌شود.افزایش خطاهای برنامه‌نویسی (More Bugs): پیچیدگی‌های بیشتر، احتمال بروز باگ‌ها را افزایش می‌دهد.کندی در اجرای ایده‌ها: با افزایش ایده‌ها برای توسعه محصولات، سرعت اجرای آن‌ها کاهش پیدا می‌کند.دیر رسیدن ایده‌ها به مشتریان: به دلیل پیچیدگی‌های عملیاتی، ممکن است زمان عرضه محصولات جدید به تاخیر بیفتد.این وضعیت می‌تواند به عنوان یک ریسک جدی برای توسعه کسب‌وکارهای دیجیتال محسوب شود. به دلایل زیر:کاهش کیفیت تجربه مشتری: افزایش تعداد مشتریان و پیچیدگی سیستم‌ها، مدیریت درخواست‌ها و پاسخگویی به آن‌ها را دشوارتر می‌کند. هرگونه تاخیر یا نقص در ارائه خدمات، می‌تواند به نارضایتی مشتریان منجر شده و آن‌ها را به سمت رقبا سوق دهد.افزایش هزینه‌ها و پیچیدگی فنی: افزایش تعداد سرورها و نرم‌افزارها، نیاز به مقیاس‌پذیری بالا و مدیریت پیچیدگی‌های فنی، هزینه‌های زیرساختی را افزایش می‌دهد. مدیریت این پیچیدگی‌ها به مهارت‌های تخصصی بیشتری نیاز دارد که ممکن است برای کسب‌وکارها گران باشد.کندی در نوآوری: رشد تیم‌ها و تعداد پروژه‌ها منجر به کاهش سرعت اجرای ایده‌ها می‌شود. این مسئله می‌تواند کسب‌وکار را در رقابت با دیگران به عقب بیندازد.افزایش خطاها و باگ‌ها: پیچیدگی‌های بیشتر منجر به افزایش احتمال بروز باگ‌ها و خطاها می‌شود. اگر این مشکلات به سرعت برطرف نشوند، تجربه کاربری کاهش می‌یابد.کاهش امنیت: تنوع در دسترسی به خدمات از طریق پلتفرم‌های مختلف، خطرات امنیتی را افزایش می‌دهد. اگر کسب‌وکار نتواند به‌خوبی امنیت داده‌ها را مدیریت کند، احتمال بروز آسیب‌های جدی وجود دارد.کاهش انعطاف‌پذیری: با بزرگ‌تر شدن ساختارها، انعطاف‌پذیری در پاسخ به نیازهای جدید مشتریان کاهش می‌یابد. این مسئله می‌تواند فرصت‌های بازار را از دست بدهد.کسب و کار در چنین فضایی دست به چه اقداماتی می زنند و چرا؟زمانی که کسب و کارها با چنین پیچیده گی در زمینه سرویس ها مواجه می شوند که نقطه قوت آنها تبدیل به اولین ریسک کسب و کار می شود به شدت اعتماد به تیم های فنی خود را از دست می دهند برای اینکه متوجه شویم چگونه این اعتماد از دست می رود بهتره به روند بلوغ تکنولوژی و روند آن در این سازمانها نگاهی بیندازیم.دره مرگ یک مرحله در مسیر رشد و توسعه استارتاپ‌هاروند بلوغ تکنولوژی هانمودار هایپ (Hype Cycle) یک ابزار گرافیکی است که فرآیند بلوغ و پذیرش یک تکنولوژی یا نوآوری را در طول زمان نمایش می‌دهد. این نمودار دارای پنج مرحله کلیدی است که به درک رفتار و عملکرد استارتاپ‌ها در مواجهه با رشد و پیچیدگی کمک می‌کند:Hype Cycleانگیزش نوآوری (Innovation Trigger): استارتاپ‌ها با یک ایده نوآورانه و ساده شروع می‌کنند. در این مرحله، تیم‌های کوچک و متمرکز با اشتیاق و انگیزه بالا به سرعت ایده‌ها را اجرایی می‌کنند. به دلیل کوچک بودن تیم و داشتن تعاملات نزدیک، اعتماد میان اعضای تیم در سطح بالایی قرار دارد. این اعتماد به توانمندی‌های تیم، فضای لازم برای آزمایش و تجربه کردن را فراهم می‌کند.اوج انتظارات تورم‌یافته (Peak of Inflated Expectations): با موفقیت اولیه و رشد سریع، انتظارات از کسب‌وکار افزایش می‌یابد. استارتاپ در این مرحله به دنبال گسترش کسب‌وکار است، زیرا اعتماد به تیم به اوج خود رسیده است. رهبران کسب‌وکار ممکن است به این نتیجه برسند که زمان توسعه محصولات جدید، افزایش تعداد مشتریان و گسترش تیم‌ها فرا رسیده است. در این حالت، اعضای تیم‌های فنی و اجرایی تحت فشار هستند تا از عهده این گسترش سریع در بیایند.شیب سقوط به‌ سمت ناامیدی (Trough of Disillusionment): با افزایش پیچیدگی‌ها (افزایش مشتریان، خدمات جدید، زیرساخت‌های گسترده‌تر و نیاز به مدیریت داده‌ها و منابع بیشتر)، مشکلات فنی و فرآیندی شروع به نمایان شدن می‌کنند. تیم‌های فنی که قبلاً توانسته بودند در محیط‌های ساده و چابک کار کنند، اکنون با چالش‌های پیچیده‌تر مواجه می‌شوند. این چالش‌ها ممکن است شامل تاخیر در تحویل پروژه‌ها، باگ‌های نرم‌افزاری، عدم مقیاس‌پذیری سیستم‌ها و کاهش کارایی باشند. به دلیل این مشکلات، اعتماد به تیم‌های فنی کاهش می‌یابد. مدیران و ذینفعان ممکن است احساس کنند که تیم‌ها نمی‌توانند به درستی با رشد کسب‌وکار همراه شوند و به‌جای حل مشکلات، آن‌ها را پیچیده‌تر می‌کنند.شیب روشنگری (Slope of Enlightenment): با گذشت زمان و تجربه، کسب‌وکارها یاد می‌گیرند که چگونه پیچیدگی‌ها را مدیریت کنند. تیم‌ها ممکن است روش‌ها و فرآیندهای جدیدی برای مقابله با مشکلات پیدا کنند، از ابزارهای مناسب‌تری استفاده کنند و به بازسازی ساختارها بپردازند. این مرحله زمان بهینه‌سازی و بهبود عملکرد است. اگر کسب‌وکار موفق به گذر از این مرحله شود، اعتماد به تیم‌ها می‌تواند تا حدودی بازسازی شود، اما به این شرط که فرآیندهای مدیریت و هماهنگی بهبود یافته و کارایی تیم‌ها افزایش یابد.پایداری بهره‌وری (Plateau of Productivity): در این مرحله، استارتاپ به بلوغ می‌رسد و قادر است با استفاده از تجربیات قبلی و فرآیندهای بهبود‌یافته، به شکلی پایدار و با کارایی بالا عمل کند. تیم‌ها اعتماد از دست رفته را تا حد زیادی بازمی‌یابند و ساختارهای جدیدی برای مدیریت پیچیدگی‌ها و هماهنگی بهتر برقرار می‌شود. اما این مسیر اغلب زمان‌بر است و بدون مدیریت صحیح، کسب‌وکارها ممکن است هرگز به این مرحله نرسند.چالش دره مرگدره مرگ (Valley of Death) یک مرحله در مسیر رشد و توسعه استارتاپ‌ها و کسب‌وکارهای دیجیتال است که به دوره‌ای اشاره دارد که در آن کسب‌وکار پس از یک دوره رشد سریع، با پیچیدگی‌های فنی، مدیریتی و سازمانی مواجه می‌شود. در این مرحله، تیم‌های فنی و مدیریتی ممکن است توانایی یا سرعت کافی برای انطباق با شرایط جدید را نداشته باشند، که در نتیجه آن، عملکرد کسب‌وکار دچار بحران می‌شود. این دره زمانی است که اغلب استارتاپ‌ها با چالش‌های اساسی مواجه می‌شوند. این وضعیت از لحاظ روانی به هر یک از ذینفعان نمود متفاوتی دارد که منجر به عکس العمل های متفاوتی می شود.نمود دره مرگ به ذینفعاناز نگاه مدیران ارشد و صاحبان کسب‌وکار :عدم اطمینان به تیم‌های فنی: در این مرحله، مدیران و صاحبان کسب‌وکار ممکن است اعتماد خود به تیم‌های فنی را از دست دهند، چرا که احساس می‌کنند توسعه کسب‌وکار از کنترل خارج شده و تیم‌های فنی قادر به ارائه نتایج مطلوب نیستند.استراتژی‌های ناپایدار: تصمیمات استراتژیک ممکن است به شدت تحت تاثیر بحران‌ها قرار گیرند، به‌طوری‌که مدیران ممکن است بدون تحلیل دقیق، به تغییرات ساختاری و مدیریتی روی بیاورند که این تغییرات ش مشکلات را حل نمی‌کند، بلکه باعث افزایش پیچیدگی و آشفتگی می‌شود.از نگاه تیم‌های فنی و مهندسی:فشار کاری و انتظارات غیر واقعی: دره مرگ برای تیم‌های فنی به معنای افزایش فشار و عدم توانایی در پاسخ به درخواست‌ها و انتظارات مدیران و مشتریان است. این امر باعث ایجاد استرس و ناامیدی در تیم‌ها می‌شود.از دست رفتن انگیزه: با افزایش ناکامی‌ها و انتظارات را برآورده، افراد فنی احساس می‌کنند که تلاش‌هایشان بی‌فایده است و در نتیجه ممکن است انگیزه و انرژی خود را از دست بدهند.از نگاه مشتریان:کاهش کیفیت خدمات: از نگاه مشتریان، این دوره با کاهش کیفیت محصولات و خدمات همراه است. زمان انتظار برای حل مشکلات افزایش می‌یابد، ناپایداری سرویس‌ها بیشتر می‌شود، و تجربه مشتری به شدت آسیب می‌بیند.از دست دادن اعتماد: وقتی مشتریان متوجه می‌شوند که کسب‌وکار توانایی پاسخگویی به نیازهای آن‌ها را ندارد، اعتماد آن‌ها به برند کاهش می‌یابد و این می‌تواند منجر به ترک مشتریان و آسیب جدی به اعتبار برند شود.از نگاه سرمایه‌گذاران:کاهش بازگشت سرمایه: سرمایه‌گذاران ممکن است با مشاهده کندی رشد و افزایش مشکلات عملیاتی، احساس نگرانی کنند و انتظار بازگشت سرمایه خود را در معرض خطر ببینند.فشار برای تغییرات سریع: سرمایه‌گذاران معمولاً در چنین شرایطی به دنبال راه‌حل‌های سریع هستند و ممکن است فشار زیادی برای انجام تغییرات مدیریتی و استراتژیک بر مدیران وارد کنند.اقدام ها ی خطرناک در وضعیت دره مرگدر مواجهه با این مرحله، بسیاری از کسب‌وکارها دست به اقداماتی می‌زنند که نه تنها مشکلات را حل نمی‌کند، بلکه گاهی اوضاع را بدتر می‌کند.برخی از این اقدامات و تحلیل عواقب آن‌ها عبارتند از:۱- افزایش تعداد استخدام‌ها افزایش تعداد استخدام‌ها در زمان بحران به‌عنوان یکی از نخستین واکنش‌های سازمان‌ها می‌تواند به جای حل مشکل، آن را پیچیده‌تر کند. بسیاری از کسب‌وکارها با این باور که افزایش تعداد نیروهای انسانی منجر به تسریع توسعه و حل مشکلات می‌شود، به استخدام‌های گسترده روی می‌آورند. اما این رویکرد، اگر با دقت و دیسیپلین همراه نباشد، نتایج معکوسی به‌همراه خواهد داشت.فقدان دیسیپلین در مدیریت و رشد سریع تیم‌ها: استخدام نیروهای جدید بدون داشتن یک ساختار مدیریتی مستحکم، ابزارهای مناسب و فرایندهای سازمان‌یافته، منجر به افزایش عدم هماهنگی بین تیم‌ها می‌شود. افراد جدید معمولاً به زمان برای آشنایی با فرهنگ سازمان، فرآیندهای موجود و تیم‌های همکار نیاز دارند. اگر این فرآیندها شفاف و مشخص نباشند، هرگونه تلاش برای هم‌راستا کردن آن‌ها با اهداف سازمان به تأخیر می‌افتد.دیسیپلین به معنای داشتن یک نظم و روال مشخص است که تمام تیم‌ها و افراد بر اساس آن عمل کنند. نبود این نظم باعث می‌شود:اهداف نامشخص بمانند: تیم‌های جدید نمی‌دانند اولویت‌های اصلی چیست و کدام بخش‌ها باید زودتر توسعه یابند.ناهماهنگی در فرآیندها: فرآیندهای ناکافی یا پیچیده ممکن است باعث شود که تیم‌ها برای هر تغییر یا به‌روزرسانی به‌طور مستقل و غیرموثر عمل کنند.کاهش کارایی: بدون دیسیپلین، هماهنگی بین تیم‌های مختلف کاهش می‌یابد، زمان تحویل محصولات افزایش یافته و تصمیم‌گیری‌ها طولانی‌تر می‌شود.افزایش پیچیدگی و کاهش بهره‌وری: هر نیروی جدید به معنی نیاز به مدیریت بیشتر است. در نبود دیسیپلین و ساختارهای واضح، تیم‌های مدیریتی با چالش‌های بیشتری در مدیریت نیروی انسانی و پروژه‌ها مواجه می‌شوند. این موضوع به تدریج به افزایش بوروکراسی، جلسات بیشتر، و پیچیدگی‌های ارتباطی منجر می‌شود. در نتیجه، به‌جای افزایش سرعت و کارایی، بهره‌وری سازمان کاهش پیدا می‌کند.تشدید اختلافات و انتقادات: در غیاب یک استراتژی منسجم، استخدام‌های بی‌رویه می‌تواند باعث افزایش انتقادات درون‌سازمانی شود. نیروهای جدید ممکن است با تیم‌های موجود دچار تضاد شوند و عدم شفافیت در اهداف و فرآیندها به نارضایتی و سرخوردگی تیم‌های قدیمی و جدید منجر گردد. به جای همکاری برای حل مشکلات، اختلاف‌ها و چالش‌های داخلی افزایش می‌یابد.۲- تغییرات ساختاری و مدیریتیگاهی کسب‌وکارها به‌جای حل مشکلات بنیادین و زیرساختی، تصمیم به تغییر ساختار سازمانی یا حتی تعویض مدیران می‌گیرند. این اقدام ممکن است در ابتدا حس تغییر و بهبود ایجاد کند، اما بدون تحلیل دقیق مسائل و به‌کارگیری استراتژی‌های مناسب، این تغییرات معمولاً به نتیجه مطلوبی نمی‌رسد و ممکن است حتی بی‌ثباتی بیشتری به همراه داشته باشد.ایجاد تیم های موازیدر این رویکرد، سازمان به‌جای اصلاح تیم‌های موجود یا بهبود فرآیندها، اقدام به ایجاد تیم‌های جدیدی می‌کند که وظایف یا پروژه‌های مشابهی را دنبال می‌کنند. این تیم‌ها معمولاً با هدف شتاب‌دهی به توسعه یا حل مشکلات فنی تشکیل می‌شوند و به‌طور موازی با تیم‌های اصلی سازمان فعالیت می‌کننچرا ایجاد تیم‌های موازی خطرناک است؟افزایش پیچیدگی و تضادها ایجاد تیم‌های موازی باعث افزایش پیچیدگی در سازمان می‌شود، چرا که اکنون چندین تیم به‌طور همزمان روی مسائل مشابه کار می‌کنند. این موضوع می‌تواند به تضاد در تصمیم‌گیری‌ها، ایجاد اختلاف در روش‌های کاری، و حتی رقابت ناسالم بین تیم‌ها منجر شود.کاهش هماهنگی و همگرایی با وجود تیم‌های موازی، هماهنگی بین تیم‌های مختلف کاهش می‌یابد و تلاش‌ها در مسیرهای مختلفی پراکنده می‌شوند. این عدم همگرایی باعث می‌شود که کسب‌وکار نتواند به‌طور موثر و منسجم به اهداف خود برسد. در نهایت، پروژه‌ها ممکن است از مسیر اصلی خارج شوند یا اهداف متناقضی را دنبال کنند.اتلاف منابع ایجاد تیم‌های موازی منابع زیادی از جمله نیروی انسانی، زمان و هزینه را مصرف می‌کند. با این حال، اگر مدیریت مناسبی در این فرآیند وجود نداشته باشد، این منابع به‌جای حل مشکلات، تنها باعث اتلاف بیشتر و افزایش هزینه‌ها می‌شوند.کاهش مالکیت و مسئولیت‌پذیری هنگامی که چندین تیم موازی روی یک پروژه یا بخش مشابه کار می‌کنند، مسئولیت‌پذیری واضحی بین تیم‌ها وجود ندارد. این وضعیت منجر به سردرگمی در تعیین مالکیت نتایج و تصمیمات می‌شود. هیچ تیمی احساس مالکیت کامل نمی‌کند و مسئولیت مشکلات بین تیم‌ها تقسیم می‌شود، که خود منجر به کاهش کیفیت و افزایش نارضایتی می‌شود.بروز مشکلات ارتباطی تیم‌های موازی اغلب دچار مشکلات ارتباطی می‌شوند، زیرا هر تیم رویکرد و چارچوب کاری خود را دنبال می‌کند. این مسئله باعث می‌شود که تبادل اطلاعات و هماهنگی بین تیم‌ها دشوارتر شود و در نتیجه ناهماهنگی‌های جدی در توسعه محصول یا خدمات به وجود آید.تضاد در تصمیم‌گیری و راهبردها تیم‌های موازی ممکن است تصمیمات متفاوتی بگیرند یا رویکردهای متفاوتی در حل مشکلات اتخاذ کنند. این تضاد در تصمیم‌گیری می‌تواند به سردرگمی بیشتر در سازمان منجر شده و نتایج نهایی پروژه‌ها را تحت تاثیر منفی قرار دهد.۳.تغییر تکنولوژی و بازنویسی مجددتغییر تکنولوژی و بازنویسی محصولات یکی از تصمیماتی است که کسب‌وکارها به‌ویژه در زمان بحران یا رکود به آن متوسل می‌شوند. اگرچه این اقدام به ظاهر می‌تواند نوآوری و بهبودهایی را به همراه داشته باشد، اما در عمل معمولاً با ریسک‌های زیادی همراه است. بازنویسی محصولات از پایه، به‌ویژه در زمانی که تیم‌های فعلی نتوانسته‌اند مشکلات موجود را به‌درستی حل کنند، می‌تواند باعث تاخیر در عرضه محصول، افزایش هزینه‌ها و از دست رفتن مشتریان شود.تله بازنویسی به‌عنوان راه‌حل ساده و کاملدر شرایط پیچیده، بازنویسی سیستم اولین و ساده‌ترین جوابی است که به ذهن مدیران و تیم‌ها می‌رسد. این تله ذهنی ناشی از تلاش مغز برای ساده‌سازی مسائل و کاهش مصرف انرژی است؛ پدیده‌ای که ریشه در تکامل انسان دارد. اما در مواجهه با مشکلات پیچیده، این راه‌حل‌های سریع و سطحی به‌ندرت بهترین گزینه هستند و همیشه باید به اولین راه‌حل شک کرد.پیامدهای بازنویسی بدون تحلیل عمیقمدیران باید در نظر داشته باشند که بازنویسی کامل سیستم، علیرغم امیدبخش بودن، دارای مشکلات اساسی است. اگر این کار بدون تغییر در مدل‌های ذهنی و فرهنگی سازمان انجام شود و هیچ مکانیزم پیشگیرانه‌ای برای کنترل کیفیت در سیستم ایجاد نشود، ریسک شکست افزایش می‌یابد. در این حالت، بازنویسی به‌جای حل مشکلات موجود، تنها منجر به طولانی‌تر شدن فرآیندها و افزایش هزینه‌ها خواهد شد.بازنویسی با تیم و افراد جدیددر بسیاری از مواقع، بازنویسی توسط تیم‌های جدید انجام می‌شود. اما این تصمیم می‌تواند به گسست دانش و تجربه قبلی منجر شود. محصولاتی که به‌صورت تدریجی و تکاملی توسعه یافته‌اند، دارای دانشی هستند که اغلب به‌طور رسمی مستند نشده است و در اختیار تیم‌های قدیمی قرار دارد. افراد و تیم‌های جدید که این دانش را در اختیار ندارند، مجبور به بازسازی تجربیات گذشته می‌شوند که این امر به پیچیدگی و هزینه زمانی اضافه می‌کند.تغییر استک و تکنولوژییکی از خطرناک‌ترین تصمیمات در شرایط بحران، تغییر شتاب‌زده استک و تکنولوژی است. این تغییرات باعث می‌شود تیم‌های قدیمی که دارای دانش و تجربه عملی سیستم هستند، از فرآیند حذف شوند. در چنین شرایطی، این افراد اغلب آینده‌ای در سازمان برای خود نمی‌بینند و به امید شکست تیم‌های جدید، از همکاری و انتقال دانش خودداری می‌کنند. از سوی دیگر، تیم‌های جدید که پرانگیزه ولی بی‌تجربه در مواجهه با سیستم قبلی هستند، مجبور به کشف مجدد مسائل می‌شوند. این وضعیت، زمان توسعه را به شدت افزایش می‌دهد و باعث می‌شود که بازنویسی سیستم نه تنها مشکلات را حل نکند، بلکه آن‌ها را تشدید کند.بازنویسی سیستم به عنوان راه‌حلی برای خروج از بحران می‌تواند بسیار پرهزینه و زمان‌بر باشد. این اقدام باید با تحلیل دقیق مشکلات فعلی، تغییرات اساسی در مدل‌های مدیریتی و فرهنگی و بهره‌برداری از دانش موجود انجام شود. بدون این پیش‌شرط‌ها، بازنویسی صرفاً یک اقدام سطحی و پرخطر خواهد بود که به‌جای نوآوری و بهبود، ممکن است سازمان را به سمت شکست سوق دهد.راه حل چیست؟برای روشن کردن این تاریکی؛ برای شکستن مرزهای تفکر جزئی‌نگر و حرکت به سوی فهمی که سازمان را نه مجموعه‌ای از اجزا، بلکه به‌عنوان سیستمی پویا و تکاملی می‌بیند. در ادامه برای تحلیل درستی از موقعیت این شرکت ها ، از نظریات علوم پیچیدگی، تفکر سیستمی و اصول تکاملی الهام خواهیم گرفت تا راهی تازه برای فهم، طراحی و هدایت سازمان‌های چابک و خلاق بیابیم و عبور سازمانهایی که در دره مرگ گیرکرده اند ارائه دهیم.با من در مقاله های بعدی همراه باشید... حسین هلالی حسین هلالی Fri, 16 May 2025 15:24:16 +0330 https://virgool.io/@hosseinhelali/%D8%A2%D9%85%D8%A7%D8%B1-%D8%A8%D8%A7%D8%B2%D8%AF%DB%8C%D8%AF-%D9%85%D8%B7%D8%A7%D9%84%D8%A8-%D9%85%D9%86-%D8%AF%D8%B1-%D8%B3%D8%A7%D9%84-%DB%B9%DB%B8-unfpdrf2leia اگر دستاوردی را نتوانم اندازه بگیرم، چیزی در دست ندارم.اشتباه نشود، این به معنای تمایل به بهترین بودن و یا میل به اثبات چیزی نیست، اما تنها چیزی که می‌تواند برای بهتر شدن به من کمک کند یک نقشه راه است، از مسیری که طی کرده‌ام، تا بدانم چه اثری از خود به جا گذاشته‌ام. یک تصویر کلی که بتواند خیلی ساده نشانم دهد تلاش من چه اثری بر جامعه‌ام گذاشته است.ویدیوی آمار مخاطبین من را ببینید: https://cdn.virgool.io/annual-report/1398/zzbwishkzlsc-crG7O.mp4 دستاوردهای من در سال ۹۸در سال ۹۸، من در مجموع ۵ پست در ویرگول منتشر کردم و پست‌های من ۹۲ مرتبه لایک شدند و افراد ۳۶ بار نظرات خود را روی پست‌های من به اشتراک گذاشتند. امسال ۳۳ نفر در ویرگول من را دنبال کردند تا پست‌های بعدیم را بخوانند. اما چیزی که این دستاورد را ارزشمندتر می‌کند اثری است که این پست‌ها از خود به جا گذاشتند.اثر پروانه‌ای منطبق آمار ۲,۱۴۸ بار پست‌های من خوانده شدند و زمانی حدود ۵۴۶,۰۳۰ ثانیه صرف مطالعه آنها شده است، که با توجه به جمعیت ۷۲٬۹۴۰٬۰۰۰ نفری که در ایران به اینترنت دسترسی دارند، من توانستم حدود ۰/۰۰۷۴۸۶ ثانیه، سرانه مطالعه دیجیتال کشور را بالا ببرم. عددی که با تمام کوچک بودنش، اثر بزرگ و ارزشمندی است.اما این عددها فقط توضیحی است از آنچه که برای مخاطبانم به ارمغان آورده‌ام، اثر ارزشمند‌تری که با نوشتن در ویرگول از خود به جا گذاشته‌ام، تلاش پنهانی بوده که برای حفظ محیط زیست کرده‌ام. من با انتشار پست‌های خودم در فضای ویرگول توانستم در مصرف کاغذ صرفه جویی کنم؛ یعنی اگر قرار بود پست‌هایم را چاپ و به دست تک تک خوانندگان برسانم باید ۱۱,۱۹۶ کاغذ مصرف می‌شد. حسین هلالی حسین هلالی Sun, 29 Mar 2020 21:52:56 +0430 https://virgool.io/@hosseinhelali/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%AF%D8%B1-%D8%A7%DB%8C%D9%86-%D8%AF%D9%86%DB%8C%D8%A7%DB%8C-%D8%B4%D9%84%D9%88%D8%BA-%D9%81%D9%86%D8%A7%D9%88%D8%B1%DB%8C-%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1-%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8-%DA%A9%D9%86%DB%8C%D9%85-pgkfjpf2mlxz https://unsplash.com/هر وقت به لیست Bookmark های مرورگر خودم یا به PDF هایی که توی لپ تاپ شخصی ام ذخیره کرده ام نگاه میکنم. دچار استرس شده و حس ناامیدی به سراغم میاد که چگونه باید مدیریت زمانی کنم. آخرش هم هنوز تموم نشده می شنوم فلان تکنولوژی اومده …اگر به مجموعه تغییراتی که توی این ۱۰ سال توی حوزه بازيگران تولید نرم افزار, به وجود آمده نگاهی کنیم متوجه می شویم چقدر این تغییرات مارو هرروزه تحت فشار قرار داده که دائما بر روی دانسته های خودمان تجدید نظر کنیم و اقدام به یادگیری فناوری های جدید کنیم.این چالش تنها به اینجا ختم نشده و در هر جایگاهی از یک تیم تولید نرم افزار باشیم همواره با چالش مستمری درگیریم .و اون مساله انتخابه , انتخاب بین این همه تکنولوژی , زبان , ابزار , فریم ورک یا پلتفرم که همواره در حال تغییره راه حل چیست؟ چطوری باید انتخاب کرد؟در ابتدا باید به این سوال پاسخی بدهیم این فضای تغییر تکنولوژی کی آروم میگیره ؟ و ما باید تاکی بخونیم؟ تا کی باید انتخاب کنیم؟تغییرات پی در پی محیط - مساله اینه که ما در یک اکوسیستم از ابزارها و تکنولوژی ها داریم زندگی می کنیم که هر از گاهی با ایجاد نوآوری های جدید در قالب زبان , ابزار , فریم ورک یا پلتفرم و حتی شیوه های تولید تعادل خودشو از دست میده. این اکوسیستم مانند اکوسیستم های طبیعی است.به طور مثال زیاد شنیده اید که چگونه با ورود یک جانور جدید و غیربومی تعادل یک اکوسیستم طبیعی بهم می خورده و سال ها طول میکشه سیستم به تعادلی جدید ولی در یک شکل جدید برسه.مثال های زیادی از این دست میشه توی سال های اخیر عنوان کرد. به طور مثال Linux چگونه عرصه رو از دست سیستم عامل های غیررایگان خارج کرد. و این خود منجر به تحول رویکرد توسعه سیستم ها که به دنبال صرفه جویی در منابع بودند شد.یا رویکرد متن باز چگونه سبب شده شرکت مایکروسافت دست از نسخه های پولی مثل Net. برداره و برای حفظ حیات خودش رو به مدل های متن باز بیاره و Net Core. بوجود بیارهاین برهم خوردن تعادل دائما ما رو تحت فشار قرار داده و از یک طرف موجب تغییر در رویکرد ها و ساختارهای پروژه ها و محصولاتمان می شود و از طرف دیگر ماراو با انتخاب های جدید روبرو می کند.پس تغییر جز لاینفک این اکوسیستم می باشد.افزایش سرعت -سرعت رشد و تحول این اکوسیستم با رویکرد متن باز و ایجاد Repository های جهانی مثل GitHub افزایش سرسام آوری رو بدست آورده. تازه ما در یک دنیای شبکه ای باز با حلقه های مثبت قرار گرفته ایم که اولا ارتباطات زیاد شده و هر Open Source خودش سکویی برای دیگر Open Source ها شده و سرعت تولید بالا می برد.افزایش سرعت هم علاوه بر تغییر کننده گی خصوصیت دیگر این اکوسیستم می باشد.نحوه تولید -چیزی که موجب نوآوری و خلق پدید ه های جدید در این اکوسیستم میشه خلق Problem است. , مساله در به بن بست رسیدن پارادایم های موجوده.به طور مثال گوگل آنقدر داده از کاربران خودش جمع آوری کرد که برای تحلیل اون دچار مشکل جابه جایی اطلاعات جهت پردازش روی سرور های خودش شد. بعد با یک تغییر پارادایمی به جای انتقال اطلاعات بر روی شبکه اقدام به جابجایی پردازش کرد و این منجر به تولید الگوی Map-Reduce به عنوان یک رویکرد جدید و خلق اکوسیستم Apache Hadoop شد.یا داستان خلق KAFKA در LinkedIn نمونه دیگری است.زبانهای برنامه برنامه نویسی نمونه دیگری از این مدل ها هستند. بهترین مثال شاید زبان جاوا که برای حل مشکل مدیریت حافظه زبان C تولید شد.در گذشته نه چندان دور این شرکت های بزرگ فناوری مثل SUN , Oracle, IBM, Microsoft … نقش اصلی نوآوری و ایجاد ابزارها و زبانها و .. بر عهده داشتند. و آنها را در قالب محصول به مشتریان می فروختند و سعی می کردن مشکلات مشتریان خودشان را در صورت عام بودن در قالب ابزار و فناوری به سازمانها عرضه کنند.به طور مثال: IBM WebSphere, Oracleولی با ظهور شرکت های TECH Company یعنی همان استارتاپ های که در یک کسب و کار خاص با رویکرد فناوری وارد شده و آن حوزه را متحول می کنند. به دلیل درهم تنیده بودن فناوری با کسب و کار سرعت خلق Problem رو افزایش داده و گردونه تحول و نوآوری رو دردست گرفته اند.این شرکت ها, این فناوری ها را در قالب متن باز تحت Apache License منتشر می کنند تا روند بلوغ خود را طی کند.یا استارتاپ هایی حول این فناوری شکل گرفته و اقدام به توسعه و نگهداری این محصول ها در قالب نسخه تجاری با قابلیت های خاص و نسخه متن باز می کنند.از این جمله میشه به شرکت هایی همچون google, Amazon, Facebook, Netflix, spottily … اشاره کرد.بطور مثال: Apache Hadoop, Apache Kafka, Amazon Dynamo-db, Spring Cloud, ...زبان Go-Lang توسط گوگلتوسعه زبان PHP توسط فیسبوکبه همین دلیل است که دیگر ابزارهای بالغ و کامل با User Interface های داشبورد های کامل که قراره به تمامی مسائل مشتریان جواب دهد و توسط شرکت های بزرگ فناوری تولید می شد. جای خودشو به ابزارهایی داده که دیگر خبری از اون داشبوردها و امکانات جانبی نداشته و سعی دارد به جای اینکه برا تمامی مشتریان پاسخی داشته باشد. تخصصی تر شده عمل کند.بدنبال ابزارهای تمام و کمال و با داشبوردهای گرافیکی کامل نباشید.روند ها - یکی دیگر از خصوصیات این اکوسیستم روندها است. تغییرات حاصل از روندها فراتر از یک ابزار و یا یک زبان خاص می باشد. بلکه این تغییرات تمامی ابعاد اکوسیستم رو تحت تاثیر قرار می دهد.به طور مثال : می توانید درباره روند تغییر الگوهای معماری نرم افزار به مقاله ای که قبلا تحت عنوان "نسل بعدی الگوهای معماری نرم افزار چیست؟" منتشر کرده ام مراجعه کنید.گاهی این روندها تحت تاثیر ابر روند های جهانی است مثل افزایش سرعت است.یک نمونه از تغییرات تحت تاثیر ابرروند افزایش سرعتGartner Survey Finds 85 Percent of Organizations Favor a Product-Centric Application Delivery Modelچرخه حیات و بلوغنمودار هایپ گارتنر - شرکت پژوهشی و مشاوره آمریکایی گارتنر، که در زمینه ارائه خدمات برون‌سپاری، تحقیق و پژوهش و مشاوره فناوری اطلاعات فعالیت می‌نماید.یک نمودار گرافیکی از چرخه حیات هر فناوری معرفی کرده که این چرخه حیات شامل مراحل زیر می باشد.Gartner Hype Cycleپیدایش نوآوری ( Innovation Trigger)در این مرحله ابتدا فناوری در حد یک مفهوم و یا طرح اولیه و یا یک Proof of concept از این مفهوم ایجاد شده به بازار ارائه می گردد که محصول قابل استفاده ای نیست. و استفاده تجاری از آن صورت نگرفته است.قله‌ ی انتظارات (Peak of Inflated Expectations)در این مرحله تبلیغات داستان های موفقیتی از استفاده از این تکنولوژی منتشر می کند و این فناوری بر سر زبانها می افتد.که اغلب با شکست هایی مختلفی همراه است.در این مرحله شرکت ها و یا تشنه گان فناوری اقدام به بکارگیری این فناوری کرده ولی اکثر شرکت ها این فناوری و بکار نمی گیرند.دره‌ی سرخوردگی ( Trough of Disillusionment)در این دوره چون فناوری نمی تواند به وعده های خود کمال و تمام دستیابی پیدا کند. مشکلات و نواقص فناوری ظهور کرده فناوری شکست خورده و اعتبار خودشو از دست می دهد.سرمایه گذاران و استفاده کنندگان به شرطی استفاده از این فناوری را ادامه می دهند که تولید کنندگان اقدام به تصحیح مشکلات و نواقص فناوری بکنند.شیب روشنفکری ( Slope of Enlightenment)در این مرحله نمونه های بیشتر از بکارگیری موفق این فناوری و ابعاد جدیدی از آن پدیدار می گردد. و شرکت ها مهارت بیشتری در بکارگیری این فناوری بدست می آورند.در این مرحله نسل های ۲ و ۳ این فناوری متولد می شود. شرکت های بیشتری اقدام به بکارگیری این فناوری می کنند. ولی همچنان شرکت های محافظه کار,محتاط باقی می مانند.فلات بهره‌وری ( Plateau of Productivity)فناوری در این مرحله وارد دوره ثبات خود شده و پذیرش عمومی آغاز می گردد.در این دوره ارزیابی و معیارهای قابل اعتمادی از آن فناوری عرضه می گردد.و نقاط قوت و ضعف آن به خوبی شناخته می شود و شرکت ها در این مرحله اقدام به استفاده گسترده از این فناوری می کنند.گارتنر هرساله Hype Cycle زیادی از فناوری های مختلف منتشر می کند.رادار فناوری - شرکت ThoughtWorks که درضمینه طراحی , تولید و خدمات مشاوره ای نرم افزار مشغول به کار بوده و با جنبش تحول توسعه نرم افزار چابک در ارتباط است. در ژانویه سال 2010 ، گروهی از متخصصان خود را برای بحث در مورد موضوعات مورد علاقه خود و آنچه در دنیای فناوری اتفاق می افتد دور هم جمع کرد. سپس نكات مطرح شده را در سندی تحت عنوان "رادار فناوری" منتشر نمود.رادار به هرچیزی که نقشی را در توسعه نرم افزار بازی می کند 'blips' می نامد.رادار کلیه 'blips' ها را تحت یک نمودار گرافیکی که از حلقه هایی که به چهارقسمت تقسیم بندی شده نشان می دهد.این چهار قسمت شامل تکنیک ها, ابزارها ,فریم ورک ها و پلتفرم ها می باشد.Technology Radarو حلقه ها کم و بیش نشان دهنده این است که آیا متخصصان Thought Works فکر می کنند این فناوری ها ایده خوبی بوده و به اندازه کافی برای استفاده در جریان اصلی پروژه ها بالغ هستند یا نهTechnology Radarحلقه Adopt -این حلقه نشان دهنده 'blips' هایی است که مورد استفاده قرار گرفته و بالغ شده و به صورت جدی توصیه میشه.البته باید توجه داشت که هر ابزاری در یک زمینه خاص مورد استفاده بوده و نباید در هر پروژه ای استفاده شود.و رعایت تناسب با مسئله اصل مهمی است.حلقه Trial - کلیه 'blips' هایی که برای استفاده آماده بوده ولی هنوز مانند حلقه Adapt به اثبات نرسیده در این حلقه قرار می گیرد. و توصیه می شود در استفاده از آنها احتیاط کرده و به صورت آزمایشی استفاده گردد. تا تصمیم بگیرید آیا آنها باید جزی از ابزارهای شما باشند یا نهحلقه Access - این حلقه شامل مواردی است که باید از نزدیک روند بلوغ شان پیگیری بشه و تنها زمانی باید مورد آزمایش قرار گیرند که مطمئن باشید برای شما قابل استفاده اند.معمولا این حلقه شامل 'blips' هایی هست که در خور توجه بوده و دارای ارزشند.حلقه Hold - این حلقه شامل مواردی است که حتی اگر در صنعت پذیرفته شده اند توصیه نمی شوند.شاید به اندازه کافی بالغ نیستند و تجربه خوبی از استفاده آنها وجود ندارد.یا دارای نقص های ذاتی و غیرقابل حلند و یا به اشتباه مورد استفاده قرار گرفته اند. بنابراین هشدار داده می شود که با آنها ممکن است دچار مشکل شوید.به نکته زیر که در رابطه با رادار از زبان خودش بیان شده حتما توجه کنید:"ما قصد نداریم به عنوان یک روند علمی خالی از نظرات شخصی و جامع باشیم. بلکه رادار سندی است از blips ها و تغییرات آن, که برای متخصصان ما در حال حاضر جالب بوده و مواردی که فکر می کنیم شما باید در پروژه های خود به آن توجه کرده و از آن استفاده کنید. این بیانگر عقاید مجموعه تکنسین های ارشد ما است و مبتنی بر کار و تجربیات روزانه ما که در اتاق های دربسته پس از بحث و گفتگوی بسیار بدست آمده است. اگرچه فکر می کنیم این جالب است ، نباید آن را به عنوان یک تحلیل عمیق در بازار مورد بررسی قرار داد."در استفاده از هر فناوری باید دقت کرد که در کدام مرحله از چرخه حیات بوده و آن مرحله چه ریسک هایی دارد.محبوبیت و استفاده کنندگان به نام- یکی دیگر از معیارها انتخاب شاید میزان استفاده و محبوبیت یک فناوری است. هرچه Community یک فناوری بیشتر باشد دسترسی شما به مستندات و جواب های مشکلات احتمالی که به آن برمی خورید بیشتر است.به طور مثال گیت هاب سعی کرده یک معیار از میزان محبوبیت و استفاده از یک متن باز را در قالب میزان ستاره های که استفاده کنندگان به آن می دهند نشان دهد. البته در این زمینه بازیگران زیادی سعی دارند ملاک هایی با دسته بندی های مختلف عنوان کنند.همچنین شرکت های Tech Company با استفاده خود از این فناوری ها به آنها اعتبار بخشیده و این فناوری ها را بالغ می کنند.فناوری ها با Community بزرگتر و استفاده کنندگان به نام, ریسک عدم دانش و دسترسی به مستندات شما در استفاده از آن و پشتیبانی از آن را کاهش می دهد.در انتها به عنوان جمع بندی باید همواره در انتخاب های خودمان نکات زیر را درنظر داشته باشیم:بپذیرید ما در یک اکوسیستم زندگی می کنیم تغییر و تکامل جز لاینفک این اکوسیستم بوده و سرعت تغییرات رو به افزایشهبدنبال ابزارهای کامل و بالغ و همه منظوره مانند گذشته نباشید. ابزارها تخصصی تر شده اند.سعی کنید روندها را شناسایی و تحلیل کنید. همسو با آنها انتخاب کنید.در رابطه با ابزار ها و یا زبانهای برنامه نویسی دقت کنید چه مشکلی را قراره حل کنه یا چه پارادایمی رو بهم زده. و از چه خواستگاهی می آیند.به مرحله حیات فناوری در چرخه حیات آن (Gartner Hype Cycle) و ریسک های آن و میزان خطر پذیری پروژه و سازمان خود در آن زمینه توجه کنید. آنگاه دست به انتخاب زده و ریسک های آن را بپذیرید.از رادار تکنولوژی و جایگاه blips ها در حلقه ها بهره بگیرید.به اندازه Community شکل گرفته حول آن و دسترسی به مستندات توجه کنید.اگر به نتیجه نرسیدید سعی کنید با شبیه سازی محیط عملیاتی فاکتورهای لازم رو اندازه گیری کرده و Fail Fast نمایید.استراتژی خودتونو تغییر بدید.به صورت ترکیبی عمل کنید. و از نگاه های جدید مثل میکروسرویس ها که به شما اجازه می دهند در هر سرویس متناسب با آن زبان و تکنولوژی مناسب را استفاده کنید بهره ببرید.به دنبال یک منبع که جواب قطعی به شما بدهد نباشید و وجود ندارد و انتخاب تخصص شماست. حسین هلالی حسین هلالی Mon, 17 Feb 2020 15:09:56 +0330 https://virgool.io/@hosseinhelali/%D9%85%D8%A7-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3-%D9%87%D8%A7-%D9%87%D9%85-%D9%84%D8%A8%D8%A7%D8%B3-%DA%A9%D8%A7%D8%B1-%D8%AF%D8%A7%D8%B1%DB%8C%D9%85-wt2i3ziqmwfr اصولا هر شغلی رو میشه از روی لباس کارش شناخت. هر چه شغل رسمی تر باشد و نیاز به دیسیپلین های سخت باشه دارای لباس فرم مشخص تری است.به طور مثال شغلهای نظامی رو در نظر بگیرید که در آن سلسله مراتبه از اهمیت خاصی برخوردار بوده و نیازه در محیط های عملیاتی افراد به عنوان یک چرخ دنده از ماشین نظامی عمل کنند و فقط اجرا کننده دستورات باشند.در مقابل طیف هنرمندان در نظر بگیرید. مجموعی از لباس های راحت و نامنظم و گاهی اوقات خارج از عرف می بینیم.در همین ساختار های نظامی هم وقتی سراغ سیستم های چریکی و جنگ نامنظم میریم میبینیم لباس های سفت و سخت نظامی جای خودشو به لباس های راحت تری می دهند.یادم نمیره یک روز گرم تابستون که تازه یک سرویس جدید روی رو سایت راه اندازی کرده بودیم. به باگ خورده بود همه سخت مشغول کار بودیم.اون روز من یک شلوار جین با یک پیراهن راسته پوشیده بود و به سبک جدید آستیناشو بالا زده بودم.رییس شرکت از در وارد شد همه شروع کردن به دست دادن و سلام کردن به من که رسید چپ چپ نگاهی کرد و با طعنه گفت:"می بینم مهندس آستین رو زده بالا که کارو شروع کنه"توی دلم گفتم"ما کجاییم (سخت درگیر باگ) این کجا"اره نمیدونه چرا بعضیا نمیخوان بپذیرن ما برنامه نویس ها هم لباس کار داریم.لباس کار ما طراحی شده برای خلاقیت نه برای سلسله مراتب. کار ما خلاقیته درسته ازش صدای تق تق کیبورد میاد ولی واقعا اون پشت داریم خلق می کنیم.ما بیشتر شبیه هنرمندانیم تا نظامی ها.لباس کارما شاید : "کوله پشتی - شلوار جین - تی شرت - کفش اسپرت"من گاهی اوقات دست های زحمت کشیده مکانیک های ماشین رو میبینم. که چقدر روغنی کثیفه, یاد ذهن خودمون می افتم. اون روزایی که ذهنمون مثل یک ساعت داره کار میکنه حتی از شرکت هم میایم بیرون دست از سرمون برنمیداره. یاد اون روزایی که صبح با جواب مسله از خواب میپریم و خسته تر از زمانی که می خواستیم بخوابیم.محیط های یکنواخت و سخت, با قوانین سخت و ساعت کاری های سفت و سخت, خلاقیت ما رو کور میکنه. ما عاشق متفاوت عمل کردنیم. جلسات متفاوت توی محیط های متفاوت.به روش های متفاوت.یادم نمیره روز اول کاری رو بایکی از دوستان توی یکی از شرکت های خوبی که کارکردم. مدیر شرکت گفت برید چهارشنبه ساعت هفت صبح با ساک وسایلتون بیاین شرکت می خواهیم بریم شمال. اولین روز کاریو توی شمال توی یک ویلا با تیم شروع کردیم. چقدر الهام بخش بود. توی او پنج روز باهم طرح کلان پروژه را بستیم. چقدر این رفتار متفاوت انرژی بخش بود." یکنواختی دشمن خلاقیت در محیط های کاری است."ما عاشق محیط هایی هستم که از درو دیوارش خلاقیت بباره. این نمادها و دستاوردهای خلاقانه دیگران به ما سرایت می کنه."مدیرعامل باید مدیر ارشد نوآوری باشد."اریک اشمیت و جاناتان روزنبرگ - کتاب گوگل چگونه کار می کند"خلاقیت قابل سرایته, باید به چشم دیده بشه. محیط های کاری در و دیوارش باید الهام بخش خلاقیت باشند."ما باید آزاد باشیم. باید ابراز عقیده کنیم, باید از ابراز عقیده احساس امنیت بکنیم. این حس امنیت مارو خلاق تر می کند. ما باید آزادانه و خلاقانه کار کنیم. باید شکست بخوریم و یاد بگیریم.شکت خوبه اگر منجر به یادگیری بشه. اون موقع باید شکست و جشن گرفت."عالی شکست بخورید. و سریع شکست بخورید."اریک اشمیت و جاناتان روزنبرگ - کتاب گوگل چگونه کار می کند"احساس امنیت اولین شرط محیط های خلاقه, هرچه احساس آزادی در برابر خطر کردن و ابراز عقیده بیشتر باشه سازمان خلاق تره"ما عاشق اینم که بهترین اثر (کد)تولید کنیم با بهترین الگوها, ابزارها و تکنیک ها.ما عاشق چالشیم محیط هایی که مسئله داشته باشند و ما بخواهیم حلش کنیم.ما محیط هایی که توی اون یادگیری نباشه دوست نداریم. یادگیری هم توی چالش بدست میاد."اهداف دست نیافتنی تعیین کنید. بلند پرواز باشید."اریک اشمیت و جاناتان روزنبرگ - کتاب گوگل چگونه کار می کند"محیط های سخت و دارای چالش و خطر خلاقند.سخت و چالش به معنای کار زیادنیست."ما خروار خروار PDF داریم که به ته سال می رسیم می بینیم خیلی شو نخوندیم فقط جمع آوری شون کردیم. این تمومی نداره. زبان هم که شده قوز بالا قوز.ما وقتی به کوه دشت میریم و یک منظره زیبا می بینیم اولین چیزی که به ذهنمون میرسه"چه حالی میده آدم بشین اینجا با لب تاپش کد بزنه"کلا خاصیم. اگر بخواهید ما را بشناسید باید از جنس ما باشید. جالبه به یکی از قوانین گوگل اشاره کنم که یکی از دوستان که اونجا کار می کرد می گفت کلیه مدیران بجز لایه مدیران ارشد باید حتما در دوران کاری برنامه نویسی کرده باشند.(البته مرجعی براش پیدا نکردم.نقل قول ایشونه) و تجربه من نشون میده قانون درستیه.بله کار ما خلاقیته و بگفته اریک اشمیت و جاناتان روزنبرگ ما خلاق هوشمندیم.به همین دلیل است که شرکت های موفق دنیا, بخش۲۰درصد از زمان کاری را به کارمندان خود در محیطی متفاوت فرصت می دهند تا ایده های خودشونو پیاده سازی کرده و در صورت قابل بودن از آنها می خرن"مهندسان ۲۰ درصد از زمان خودشان را صرف انجام کارهایی می کنند که انتخاب خودشان است.برنامه زمان ۲۰ درصدی منجر به تولید محصولات ارزشمندی در گوگل شده است.قانون ۲۰ درصد مسئله زمان نیست بلکه مساله آزادی است."اریک اشمیت و جاناتان روزنبرگ - کتاب گوگل چگونه کار می کند حسین هلالی حسین هلالی Sat, 08 Feb 2020 13:40:50 +0330 https://virgool.io/@hosseinhelali/%DA%86%D9%87-%D8%A7%D9%81%D8%B1%D8%A7%D8%AF%DB%8C-%D8%B1%D9%88-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AA%DB%8C%D9%85-%D9%87%D8%A7%DB%8C-%D8%AE%D9%88%D8%AF%D9%85%D8%AE%D8%AA%D8%A7%D8%B1-%D8%A7%D8%B3%D8%AA%D8%AE%D8%AF%D8%A7%D9%85-%DA%A9%D9%86%DB%8C%D9%85-dlhirfzyui7f https://unsplash.com/سالها پیش به عنوان یک عضو تیم, ازمن خواستن رزومه یکی از دوستان رو که تقاضای کار کرده بود, بررسی کنم.خوب یادمه.وقتی که شروع کردم به مصاحبه, از هرچی که بلد بودم ازش پرسیدم. حتی مشکلاتی که توی پروژه بهش خورده بودیم. جلسه هرچه پیش میرفت هی تنش بالا می گرفت. تا جایی که رسیده بودیم به اینجا که اون می گفت من فلان چیزو قبول ندارم و من می گفتم نه اشتباهه.خلاصه بگم تفتیش عقایدی بود برای خودشهنوزم که خودم گاهی برای استخدام میرم یا از اعضای تیم میخوام یه چنین مصاحبه ای انجام بدن این الگو رو زیاد مشاهده می کنم.مشکل روشنه همه ما آدم های فنی هستیم. که اصلا برای استخدام افراد آموزش ندیده ایم پس بنابراین با داشته های خودمون سعی میکنم افراد محک بزنیم و گاهی اوقات زورآزمایی و کنترل....مشکل بعدی اینه هرچند گروه های منابع انسانی قوی هم اطراف شما باشند محک زدن توانمندی های فنی افراد با شماست. حتی من به این جمله اریک اشمیت و جاناتان روزنبرگ در کتاب How Google Work کاملا معتقدم."استخدام مهمترین کاری است که انجام می دهید."شما به عنوان مدیر فنی تنها مسئول اصلی استخدام هستید. بخصوص اولین استخدام های که انجام می دید.اولین استخدام های شما شکل دهنده DNA تیم بوده و آینده و فرهنگ تیم را شکل می دهد.من تیم های زیادی رو توی این سالها دیدم که یک فرهنگ اشتباهی رو دنبال میکنن و قابل تغییر نیستند. تنها بخاطر همین DNA اولیه و هی اوضاع آنها بدتر میشه و حتی با حذف افراد دوباره این الگوها در افراد دیگری بروز می کنه.اینجا بد نیست به اثر گله ای که در همین کتاب عنوان شده ذکر کنیم."یک تیم کاری خوب که از افراد بسیار خوب تشکیل شده نه تنها کار و به شیوه خوب انجام می دهند بلکه افراد بسیار خوب را هم جذب می کنند."بله هدف از استخدام یافتن افراد مناسب است ولی این افراد چه کسانی هستند و باید دارای چه خصوصیاتی باشند.جواب خلاق ها هوشمند همان ویژه گی که اریک اشمیت و جاناتان روزنبرگ در گوگل به دنبال آن هستند.ولی هوشمندی چیست؟ و چه تعریفی ازش داریم؟این سوالی بود که مدتها ذهن منو مشغول به خود کرده بود و گاهی اوقات اونو با آی کیو اشتباه می گرفتم.اینجا بود که با آشنایی با کتاب موسسه گالوپ "رهیدن از قانون های کهنه" نقش بسیار مهمی در روشن شدن این مطلب برای من داشت."مديران بزرگ هوشمندي را امري كمياب و دور از دسترس نمـي داننـد بلكـه تعريـف آنـان از هوشـمندي چنين اسـت: الگويي تكرار شدني از انديشه، احساس يا رفتار كه ميتوان آن را بهرهمندانه به كار بـست. از ديد اين مديران هر نقشي،براي اينكه كه به شايستگي ايفا گردد نيازمند هوشمندي است.""مديران برجسته بيش از آنكه به تجربه و دانش افراد بها دهند براي هوشمندي آنان و توان تصميم گيري شان در مواقع حساس ارزش قائلند. زيـرا هوشمندي آموختني نيست افـراد مختلـف بـه ميـزان متفاوتي از آن بهره مندند. اين هوشمندي مهمتر است، چرا كه انگيزه دهنده اسـت، انسان را بـه اندیشیدن وا می دارد و موجب برقراري ارتباط هاي سازنده ميشود. نمونه هايي كه بسيار ديده شده، نشان ميدهند كه افراد با داشتن تجربه و دانش يكسان، عملكرد متفاوتي در مواقع بحراني از خود نشان داده اند و اين بدان دلیل اسـت کـه صافي مغز آنان در پاسخ به محركهاي يكسان، متفاوت عمل ميكند. اين صافي به ملیت، جنس و نژاد بستگي ندارد و در درون هر فرد نهادينه شده است"حالا سوال بعدی پیش می آید چگونه باید این افراد رو پیدا کنیم؟تکنیک های زیادی توی این کتاب ذکر شده ولی یکی از بهترین آنها را عنوان می کنم.برای یافتن خلاق ها هوشمند بهتره در مصاحبه ها دنبال پیروزی ها و کارهای موفق افراد باشید تا به دنبال ناکامی ها و شکست های آنها چون هوشمندی افراد در آنجاست که توانستن گل بزنن و آنجاست که پرانرژی هستند و ازش لذت می برند.زمانی که تیم ها خودمختار می شوند خصوصیات دیگری هم علاوه بر هوشمندی خودشان را بیشتر از پیش نشان می دهند.وقتی سیستم به سوی خودمختاری پیش میره این جاست که ضعف ها و عدم مهارت های شخصی بروز می کنه. در چین سیستمی افراد باید بتونن در یک ساختار مسطح که تعهدات نقطه به نقطه بوده, و از هم سطحی اطلاعاتی بهره می برند و دیگر سلسله مراتب جایی ندارد به صورت خود سامان ده در راستای اهداف تیمی و سازمانی همسو حرکت کنن.اینجاست که نیازمند به برنامه نویسان , معماران و متخصصانی هستید که در عین اینکه که خلاق و ساختار شکن و توانمند در حل مساله و با حس مالکیت بالا بوده, مطابق گفته پاتریک لنچونی یک بازیکن تیمی ایدئال باشند. که بتوان در محیط پر چالش و نیازمند کار گروهی فراون بدون کنترل گرایی موثر عمل نمایند.پاتریک لنچونی در کتاب خود "بازیکن تیمی ایدئال" عنوان می کند هرکس که دارای سه فضیلت بنیادین فروتنی , پرولع و هوشمند باشد می توان از اوبه عنوان یک بازیکن ایده آل تیمی عنوان کرد.یافتن چنین افرادی و یا کمک به تقویت این ویژگی ها در افراد تیم ها نیازمند پشتیبانی تیم منابع انسانی قوی و آشنا به ظرافت های استخدام و روحیات و نگهداشت توسعه دهندگان نرم افزار در درون اکوسیستم IT سازمان می باشد.پس برای یافتن این چنین افراد مناسب , وقت زیادی از شما صرف استخدام و مصاحبه با افراد می شود، که نقش کلیدی در موفقیت دارد.سوال بعدی اینه که پس تخصص چی میشه؟بله منظور از ویژگی های عنوان شده به معنای حذف یا بی اهمیت نشان دادن تخصص و تجربه نیست بلکه تخصص مورد نیازه, ولی کافی نیست.توی مقاله قبلی که در رابطه با معماری و چابک نوشته بودم به روشن مشخص کردم نه تنها افراد باید در تخصص های اصلی خودشان عمیق باشند بلکه باید مهارت ها و تخصص های جانبی دیگر را تا حدودی داشته باشند چون مساله معماری و دغدغه های کیفیت توزیع شده است. مثلا افراد باید آگاهی عمومی لازم از کیفیت , معماری , الگوها ..در کنار دانش و تخصص خود داشته باشند. در این ساختار دیگر افراد صرفا تخصصی (Web Developer, Backed Developer, ...), کارا نبوده و باید اصطلاحا T Shape باشند.جالب اینجاست در شرکت هایی که به سمت محصول گرا بودن رفتن و تیم ها تبدیل به استارتاپ های کوچکی در دل این سازمانها شده اند, این تعریف هم در حال تغییر است.به طور مثال : Full Cycle Developers در نت فلیکسNetflix Full Cycle Programmerدر این شرکت ها افراد مسئول ساخت , راه اندازی و نگهداری محصول می باشند. لذا علاوه بر T Shape بودن باید مهارت های چرخه تولید محصول را هم در کنار تخصص های قبلی خود داشته باشند.آمازون : "you build, you run it"نت فلیکس : "Operate What You Build"اسپاتیفای: "Think it, build it, ship it, tweak it"یکی دیگر از نکات مهم در رابطه با استخدام افراد نحوه تفکر آنها در استفاده از تکنولوژی برای ایجاد ارزش برای مشتری است.با توجه به اینکه توی سالهای اخیر به واسطه تفکر متن باز ابزارها و تکنولوژی های رایگان , متنوع و زیادی توسعه یافته, این خودش تبدیل شده به آفت.مشکل رایج افراط در استفاده از ابزار ها و تکنولوژی ها, بدون نگاه به ایجاد ارزش برای مشتری, که صرفا با هدف اندوختن تجربه کاری و هیجان با این ابزارها صورت می گیرد.در اینجا به گفته WERNER VOGELS اشاره می کنم که تكنولوژي نباید صرفا جهت افزودن به Stack فناوری بکار گرفته شود بلکه تکنولوژی باید برای رساندن و توسعه خدمات به مشتریان بکار گرفته شود."It is important that engineers who come to work at Amazon understand that we do not build technology for technology’s sake, but to support the customer."--WERNER VOGELSشاید در اینجا بهتره به رویکرد آمازون به گفته WERNER VOGELS تحت عنوان “working from the customer backwards” اشاره کرد.این بدین معناست در فرایند فکری خود با نیاز مشتری شروع کرده و به عقب برمی گردیم و بدنبال فناوری ساده ای میگردیم که بتوان با آن نیاز مشتری را برآورده نمود.این نحوه فکر در مقابل نگاه از زاویه فناوری به نیاز مشتری بوده که معمولا منجر به Over-design می شه."Technology is useless if not used for the greater good of serving the customer"--WERNER VOGELSجنبه بعدی که باید در ساختار تیم های خودمختار توجه کرد Diversity یا همون تنوعهتوی این سالهای کاری, دو تا از تجربه های من خیلی خاص بودن.وقتی که دوباره به این دوتا تیم نگاه می کنم می بینم چقدر این تیم ها شکننده و غیر خلاق بودند.چقدر سریع تحت تاثیر عوامل بیرونی و درونی قرار میگرفتن و دچار بهم ریختگی و آشفتگی می شدند. و چقدر دچار حاشیه می شدن.خلاصه بگم تیم از هر طرف که جمع میکردی از طرف دیگه میزد بیرونبرام خیلی جالب بود. تنها وجه مشترک این دوتا تیم تک جنسیتی بودن بود(یکی تیم کلا خانم ویک تیم کلا آقا)خلاصه حسم میگفت باید یک رابطه بین تک جنسیتی بودن و بعضی از این نشونه ها باشه.بعدا که با مساله Diversity یا همون تنوع آشنا شدم فهمیدم مشکل از کجا آب میخوره تیم هایی که از تنوع خوبی برخوردارند.چه از لحاظ سن , جنسیت, قومیت , ملیت .. در برابر تغییرات محیطی مقاوم ترن.تنوع انعطاف پذیری رو بالا میبره و سبب نوآوری می شه و سبب میشه بتوانیم در محیط های سخت بیشتر دوام بیاریم.خلاص سعی کنید در استخدام تیم های خودمختار تنوع در استخدام را به خوبی رعایت کنید چون این تیم ها باید چالشی تر و خلاق تر و تعاملی تر از گذشته باشند.اینا چیزهایی بود که من توی سالهای کاری خودم یاد گرفتم و مطمئنا کامل نیست. و موضوع منابع انسانی حوزه عمیقی است و من تخصصم چیز دیگریه و به اندازه نیاز سعی دارم ازش بفهمم و قسمت بالایی T خودمو بسازم.در انتها منابع و کتاب هایی که به من کمک کرده رو میذارم؛ دوست دارم شما هم از تجربیاتتون و کتابهایی که ذهنتونو تغییر داده بگید. حسین هلالی حسین هلالی Fri, 31 Jan 2020 18:55:46 +0330 https://virgool.io/@hosseinhelali/%DA%86%DA%AF%D9%88%D9%86%D9%87-%DA%86%D8%A7%D8%A8%DA%A9-%D8%A8%D8%A7%D8%B4%DB%8C%D9%85-%D9%88%D9%84%DB%8C-%D8%A7%D8%B5%D9%88%D9%84-%DB%8C%DA%A9-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%AE%D9%88%D8%A8-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C-%D8%B1%D8%A7-%D9%87%D9%85-%D8%AD%D9%81%D8%B8-%DA%A9%D9%86%DB%8C%D9%85-yn7tsr5ysira https://unsplash.com/روز های اولی که با اصول چابک(Agile), از طریق XP آشنا شده بودم یادم نمیره. دچاری تعارض بدی بودم از یک طرف میدیدم متدولوژی های RUP که و در اون نقش معمار و اصول معماری با فرایند ها و دیسیپلین های سخت از پیش تعریف شده نهادینه شده بود و شفاف بود. درحال از بین رفتنه, جای خودشو داره به یک اصولی می ده که بنظر می رسد پایبندی مشخصی به معماری و کیفیت نداره بلکه فقط میخواد زودتر یک نرم افزار بسازه و بدست مشتری برسونه حتی لعنتی پایبند به مستندسازی هم نیست.بنابراین هی با خودم می گفتم این هم یه چند روزی هست و تب فضای نرم افزاره ولی چند سال بعد که مشکلاتش بیرون زد ازبین میره.زمان گذشت دیدم سروکله اسکرام پیدا شد اونم میگه هر دو هفته یا سه هفته باید یه فیچر به کاربر داد.و سازمانها یکی بعد از دیگری در حال های پیاده سازی اونن با خودم گفت دیگه انکار بسه مثل اینکه این تغییر بیشتر از حذف مستندات ، دو هفته ای کار کردن و کاغذی های رنگی قشنگه.یادم نمیره رفته بودم برای مصاحبه توی یک شرکت وقتی کانبان برد اونجا رو دیدم توی دلم گفتماوه اوه .. اینجا هم از این قرتی بازیا داره.حالا باید اقرار کنم بعد از کار توی چندین شرکت و کار با دوستانی خوبی که مفاهیم چابکی رو خوب درک کرده بودند به روشنی میگمبزرگترین تحول در تولید نرم افزار توی این سالهای اخیر همین تفکر چابک است.شاید شما هم مثل من دچار این تعارض شده باشید من توی این متن سعی دارم راجب تحول فکری خودم بگم و راهی که رفتم.رویکرد چابک با در مرکز قرار دادن مشتری و تغییر رویکرد, به ایجاد ارزش برای مشتری انگار جایی برای تفکر معماری و اصول اولیه تولید نرم افزار ارزان(high internal quality) و با کیفیت قائل نیست.Martin Fowler“High internal quality leads to faster delivery of new features, because there is less cruft to get in the way”--Martin Fowlerتازه اوضاع بدتر میشه وقتی که می فهمید برای مشتری اصول نرم افزار و ابزار و استاندارها همگی از جنس کیفیت داخلی بوده نه قابل درکه و نه قابل دیدن پس ارزشمند محسوب نمیشه.از اون بدتر میشه وقتی که رویکرد سازمان محصول گرا شده و از شما خودمختاری می خواهند.تعارض بدیه از یک طرف همه شما رو به عنوان معمار یا مدیرفنی، وقتی سیستم باگ داره یا دچار Crash میشه خلاصه بگم بدهی های فنی بیرون میزنه مسئول میدونن از طرف دیگر جایی برای ایجاد یک زیرساخت خوب قائل نیستند.معماران نرم افزار سالهاست که یاد گرفته اند چگونه اصول یک معماری خوب از همون روز اول و با صرف وقت و ایجاد فریم ورک ها و پیاده سازی استاندارد های سختگیرانه و انتخاب ابزارها مناسب و … نهادینه کنن.حالا فرض کنید چنین تفکر میخواد کنار تفکر چابک قرار بگیره رسما تعارضهاین تعارض شاید دردناک باشه و سرچشمه تحولات معماری بعد از ایجاد موج چابک در سالهای اخیر است.برای حل این تعارض بهتر است پناه ببریم به همون به پنج اصل کلیدی از ۱۲ اصل چابک با رویکرد معماری"توجه مداوم به برتری فنی و طراحی خوب باعث افزایش چابکی می شود"پس در گام نخست چابک با کیفیت و طراحی خوب مشکلی ندارد بلکه اونو باعث افزایش چابکی می داند."بهترین معماری ها , نیازمندی ها و طراحی ها از تیم های خود سازمانده پدید آور می شود"گام بعدی تیم های "خود سامانده" اساس ایجاد یک معماری خوبه نه ساختارهای سخت از پیش تعریف شده و تمرکز گرا"پروژه ها را بر دوش افراد با انگیزه بنا کنید. فضای لازم را به آنها بدهید و از نیازهای آن ها پشتیبانی کنید و به آنها اعتماد کنید تا کارها را انجام دهند"خودمختاری نه تنها منجر به خودساماندهی میشه بلکه انگیزه راهم بالا می برد."استقبال از تغییر نیازمندی ها، حتی در اواخر فرآیند توسعه. فرآیند های چابک، تغییر را در جهت مزیتِ رقابتی مشتری مهار میکنند"استقبال از تغییر به جای مقابله با آن"بالاترین اولویت ما جلب رضایت مشتری با تحویل زود و مداوم نرم افزاری ارزشمند"معماری نرم افزار همگرا با چابک باید دارای چندین خصوصیاتی باشد:از تمرکز گرایی پرهیز کند تا خود ساماندهی به وجود بیاید.خودمختاری را پشتیبانی کند تا هم انگیزها را بالا ببرد و هم کمک کند به خود ساماندهیهزینه تغییرات را به شدت پایین بیاورد.امکان تحویل خرد خرد داشته باشد تا تداوم ایجاد کند.Werner Vogels Amazon CTO 2006“The first and foremost lesson is a meta-lesson: If applied, strict service orientation is an excellent technique to achieve isolation; you come to a level of ownership and control that was not seen before.”-- Werner Vogels Amazon CTO 2006این ها اساس شکل گیری موج بعدی چابک یعنی معماری میکروسرویس است.سرویس گراست.نرم افزار رابه واحد های سازنده کوچک شکسته و آن ها را در قالب سرویس های مستقل از هم توسعه می دهد.به صورت ذاتی توزیع شده است.با پرهیز از هرگونه تمرکز گرایی توزیع شدگی را نهادینه دارد.از خود مختاری حمایت می کند.مایکروسرویس با کوچک کردن سرویس ها و سست کردن ارتباط میان آنها و حتی غیرمتمرکز کردن مدیریت داده ها (Database های جدا از هم) خودمختاری را تقویت می کند.تغییر در آن آسان تراست.هر سرویس Base Code خود را دارد و با ایجاد لایه انتزاعی خود از نشت کردن تغییرات به سایر سرویس ها جلوگیری می کند.تحویل سیال با به حداقل رساندن هماهنگی جهت انتشاراجازه می دهد سرویس ها جدا از هم و به طوری موازی توسعه و بهبود داده شوند.استقلال سرویس ها از هم سبب می شود دیگر نیاز به هماهنگی جهت انتشار به حداقل خود برسد. اینجاست که شما دیگر یک جریان سیال و خرد خرد و پر تکرار از تحویل به مشتری دارید.برگرفته از گارتنرمساله همچنان باقی است؟ تکلیف معماری و کیفیت توی این فرهنگ جدید چیه؟شما به عنوان معمار نرم افزار یا مدیر فنی از هر سبکی که استفاده می کنید:چه به عنوان معمار و مدیر فنی تمام تصمیمات مهم را می گیرد.تا مطمئن شود کلیه سیستم از یک یکپارچگی لازم و مفهومی برخوردار است و معتقدید که اعضای تیم از مهارت های لازم برای انجام این تصمیم برخوردار نیستند.و یا سعی دارید همواره از آنچه که در پروژه می گذرد با خبر باشید و به دنبال موضوعات مهم بوده تا قبل از اینکه تبدیل به چالش بزرگی شود با تعامل زیاد با تیم ها با آن مقابله کنید.باید پارادایم ذهنی خود را تغییر داده و بدونید در فضای چابکدیگر اصول معماری و کیفیت مساله فقط یه معمار یا مدیر فنی نیست(متمرکز و مرکز گرا نیست) بلکه مثل خود مایکروسرویس توزیع شده است یعنی تیم های توسعه دهند سرویس ها هم باید این دغدغه را داشته و مشارکت کنند.وظیفه شما ایجاد ساختارها و فرایندها و تمهیداتی است که خودمختاری را به حداکثر برساند.حال چگونه ساختارها و فرایندها و تمهیداتی ایجاد کنیم که خودمختاری را به حداکثر برساند؟اگر توجه کنید معماری میکروسرویس دارای دو وجه بیرونی و درونی است.برگرفته از گارتنروظیفه شما ,ایجاد همسویی (Alignment)است و شما می توانید با تمرکز بر روی وجه بیرونی و با مشارکت تیم ها همسویی لازم را ایجاد نمایید.نحوه ارتباط و ارکستریشن سرویس هااستراتژی برای Versioning سرویس هاطراحی زیر ساخت برای Scale Outمجازی سازی کردن دسترسی به سرویس ها از دنیای خارجامنیتمانیتورینگ و مدیریت یکپارچه log هاتعیین واحد استقرارزمانی که مشخصات این وجه بیرونی مشخص شد آنگاه خودمختاری قابل اعطا به تیم های تولید سرویس می باشد.البته یادتان نرود همین اصول معماری بیرونی هم باید قابل تغییر توسط تیم ها باشد شما و تیم ها باید مکانیسمی برای تحول در صورت نیاز داشته باشید. نقش شما صرفا از ایجاد رویکردهایی برای Alignment است.حال با وجهه درونی چکار باید کرد؟ آیا خودمختاری در این حوزه منجر به از دست رفتن کیفیت نمیشه؟اینجا نقش شما چیه؟بهتره در اینجا از دو فرهنگ سازمانهای چابک کمک بگیرید. "Fast Failed" و "Data Driven"ابتدا اجازه بدید بجای اعمال استانداردهای از پیش نوشته شده و اعلان آن به تیم ها, خود تیم ها به صورت خودمختار دست به انتخاب ابزارها و استانداردها و … زده و شما با ایجاد و تعریف معیارهای کیفی مثل throughput , Load و … و پیاده سازی آن از طریق گیت های تست و فراهم کردن بستری CI/CD آنها را زودتر به چالش بکشید وبا جمع آوری اطلاعات از طریق سیستم های مانیتورینگ و Log تیم ها را ترغیب به برگزاری جلسات Postmortem کرده و برای اعضای تیم فضای یادگیری ایجاد نمایید.تا اقدام به بهبود نمایند.زمانی که استانداردها , ابزارها و حتی Library ها درست بدست آمد و یادگیری انجام شد اجازه بدهید این استاندارد ها خود به خود بین تیم های انتشار یابد و از یکدیگر بیاموزند.به طور مثالروش گرده افشانی در شرکت اسپاتی فاینتفلیکس اجازه می دهد کدهای مشترک و تست شده در قالب کدهای متن باز در اختیار سایر تیم ها قرار گرفته و آنها را تشویق می کند از این کدها استفاده کنند. ولی در صورت لزوم مسیر را باز می کند تا تیم ها بتوانند مسائل را به روش متفاوتی حل کنند.باید گفت درسته فضای تولید نرم افزار با رویکرد چابک دچار تغییر شده ولی دیگر نمی توان با پارادایم های قبلی با آن همراه شد.وظیفه شما به حداکثر رسانی تغییرپذیری است و این با افزایش خود مختاری و جدا کردن دغدغه ها در قالب سرویس های کوچک قابل بدست آمدن است.در این مقاله سعی شد، در رابطه با تحول چابک بر روی معماری نرم افزار و ایجاد مایکروسرویس صحبت شود در آینده سعی می کنم در رابطه با موج های بعدی این تحول بیشتر بنویسم.به نظر شما خودمختاری (Autonomy)که اساس این نوع معماریه چطوری منجر به ایجاد نتایج شگفت انگیز میشه؟؟ حسین هلالی حسین هلالی Mon, 27 Jan 2020 23:02:45 +0330 https://virgool.io/@hosseinhelali/%D9%86%D8%B3%D9%84-%D8%A8%D8%B9%D8%AF%DB%8C-%D8%A7%D9%84%DA%AF%D9%88%D9%87%D8%A7%DB%8C-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%DA%86%DB%8C%D8%B3%D8%AA-jgjxycnyv6nz What is Next?چند روز پیش دوست عزیزم "امیر صدیقی" این عکس رو توئیت کرده بود. برام خیلی جالب اومد الگوهای مختلف معماری نرم افزارو به غذا ها تشبیه کرده و در پایان یک سوال جالب طرح می کنه که بعدی چیه؟واقعا بعدی چیه؟؟؟اگر به نسل های مختلف معماری های نرم افزار از دیدگاه چهار عامل کاربر، نرم افزار، داده و فرآیند در طول زمان نگاه کنیم ، در همه آن ها روند مشخصی را مشاهده می کنیم.User - Centricدر نسل های اولیه نرم افزار، فرآیندها و اطلاعات در دنیایی خارج از نرم افزار توسط کاربران گردش و تولید شده سپس نتایج آن توسط کاربران در سیستم ها ثبت و نگهداری می گردید. از این نسل می توان به سیستم های مدیریت اطلاعات - MIS اشاره کرد که در آنها، این کاربر است که نقش Orchestration را برعهده داشته و وظیفه ارتباط میان سایر عامل ها را به عهده دارد.Application - Centricسپس با رشد نرم افزارها و افزایش توانمندی ها، نرم افزارها در مرکز قرار گرفته و نقش محوری و Orchestration سایر اجزای سازمان را بر عهده گرفتند. در این نسل از معماری ها می توان به Workflow ها اشاره کرد.Process - Centricاما با ظهور معماری سرویس گرا و شکست نرم افزارها به مولفه های سرویس این فرایند ها هستند که در مرکز قرار می گیرند و نقش Orchestration را برعهده دارد. در این نگاه اصالت به فرآیند ها داده شده که همچون نخ تسبیح دانه ها را به هم متصل می کند. داده ها , نرم افزارها(Service) و کاربران در اطراف آن شکل می گیرد.Data - Centricبا رشد و سریعتر شدن تولید داده ها و ایجاد روند های داده های کلان و یادگیری ماشین داده ها از اهمیت فوق العاده ای در سال های اخیر برخوردار شده به طوری که گارتنر پیش بینی میکند در سالهای آینده شغل های تولید نرم افزار کاهش یافته و شغلهای داده محور و یادگیری افزایش خواهد یافت..این اهمیت پیدا کردن داده ها سبب شده در معماری های نوین اصالت با داده ها قرار گرفته و این سایر اجزا است که در اطراف آن Orchestrate می شوند.داده ها یا همان رویدادها (EVENT) حقیقت های اتفاق افتاده و غیر قابل انکاری است. که دنیای واقعی را در نرم افزار مدل سازی می نماید.Jay Kreps - CEO - Confluent"a business is a series of events and the reactions to those events"--Jay Kreps | Kafka Summit 2018 Keynoteرویدادهای تولید شده توسط سنسورها , نرم افزارها , کاربران و … تبدیل به جریانی بی انتها, از اطلاعات (Streaming) می گردد.سپس در طول سرویس ها جریان می یابد.سرویس های نرم افزاری در راستای این جریان اطلاعات اقدام به Validation , Enrichment, Filtering, Processing … و حتی تولید رویداد های جدید می کنند.Event Streamingبانک های اطلاعاتی که فقط، وظیفه ذخیره سازی State ها در قالب ها استاتیک رابر عهده داشتند جای خود را به انباره هایی از رویدادها(Event Sourcing) می دهند. State ها در این مدل قابل بازیابی از رویدادها می باشد. و هر جز از سیستم که از دست برود قابل بازیابی و بازسازی از روی رویدادها می باشد.رویداد ها به تنهایی قابل ارزش بوده و با جمع شدن رویداد ها در کنار هم، الگو ها کم کم پدیدار می گردد. و این الگوها مبنای یادگیری و تحلیل(Machine Learning) و بصیرت (Insight)قرار می گیرد.رویداد ها در هر زمان از زندگی خود(از تولد تا جایگیری در انبارها) دارای ارزش هستند اند. هرچه از زمان تولد می گذرد ارزش فردی خود را از دست داده( Fast Data - Fine Grain) و با در کنار هم قرار گرفتن ارزش جمعی ایجاد می کنند.(Big Data - Cross Grain)برگرفته از کتاب Fast Data and the New Enterprise Data Architectureحالا میشه گفت نسل جدید الگوهای معماری نرم افزار Event-Driven Architecture است. که اتفاق افتاده و روند بلوغ خود را می گذراند.SOUP-ORIENTED Architectureاین انقلاب داده محور رویداد گرا، معماری مایکروسرویس را هم متحول کرده و نسل جدیدی از مایکروسرویس را به وجود می آورد. این نوع نگاه به عکس نگاه قدیمی request-driven، رویداد گرا شده و پلتفرم قابل انعطافی را بوجود میاورد که در آن ارتباطات میان سرویس ها دچار وارونگی(Inversion) شده و سست تر (loosely coupled)از گذشته می گردد."For tech to be a real driver of innovation and growth, IT need to reorganize itself around --flexible platforms." -McKenzieسرویس های می توانند آزادانه بدون تاثیر روی سرویس های توسعه یافته گذشته به جریان ارزش رویدادها اضافه گردند.(Open–closed principle)در این نوع ارتباط مقیاس پذیری دوطرفه گشته هم Up Stream و Down Stream به صورت مستقل قابلیت مقیاس پذیری پیدا می کنند.با جهت گیری به رویداد محوری و مایکروسرویس , قابلیت ارتجاعی (Resilience) را به شدت افزایش می دهد .رویدادهای زنده Business Activity Monitoring را به صورت بالقوه به همراه آورده و دستاوردی جدید که همان بصیرت (Insight) می باشد را به کسب و کارها هدیه می دهد.حال سوال بعدی چیه؟در طی این سالها این چهار عامل کاربر، نرم افزار ، داده و فرآیند دچار جایگشت شده و انواع معماری ها را بوجود آورده شاید تغییر آینده دیگر از نوع جایگشت نبوده بلکه افزوده شدن یک عامل جدید باشه ولی این عامل جدید چیه؟??? حسین هلالی حسین هلالی Thu, 23 Jan 2020 17:49:27 +0330