شما به یک پلتفرم نیاز ندارید، شما به یک چیز نیاز دارید که کار کند

اگر در زمینه فناوری کار می کنید و از آن دسته افرادی هستید که کلمه «استراتژیک» را دوست دارید، احتمالاً از آن دسته افرادی هستید که کلمه «پلتفرم» را دوست دارید. و از نظر تئوری، حق با شماست: پیش بینی کردن."پلتفرم" استراتژی هوشمند است. پلتفرم‌ها در هر اکوسیستم فناوری جدی ضروری هستند: آنها می‌توانند در زمان زیادی صرفه‌جویی کنند و تجربه‌های یکپارچه را فراهم کنند - اما همیشه اینطور نیست. مشکل اصلی ساختن پلتفرم خود واقعاً یکی از زمان‌بندی است. یک پلتفرم خوب طراحی شده که در زمان مناسب معرفی می‌شود موهبت الهی است، اما پلتفرم پیشگیرانه اغلب باعث حواس‌پرتی است که انرژی و پول زیادی را می‌کشد. پس بیایید درباره «پلتفرم‌ها» صحبت کنیم: آنها چیستند، چرا مفید هستند و چرا تیم‌های دولتی مانند پشه‌هایی به سمت حشرات جذب می‌شوند؟

و در عوض چه کنیم؟

پلتفرم ها، یک تعریف

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

یک پلت فرم خوب یک مشکل را برای بسیاری از محصولات مختلف به خوبی حل می کند. یک مثال از این حساب Google شما است که شما را وارد Gmail، Google Calendar و Youtube می‌کند (و سایر برنامه‌هایی که از «ورود به سیستم با Google» استفاده می‌کنند). کارهای زیادی وجود دارد که برای انجام آنها باید "ورود به سیستم" وارد شوید، و احمقانه است که همه تیم ها در همه جا سیستم مدیریت حساب خود را بسازند. بهتر است آن را در یک مکان به گونه ای حل کنید که همه بتوانند از آن استفاده کنند (در غیر این صورت ممکن است تقریباً 60 سیستم ورود جداگانه داشته باشید). اگر به درستی انجام شود، هر تیم را از ساخت مجدد موارد مشابه نجات می‌دهید و تجربیات یکپارچه ایجاد می‌کنید: به عنوان مثال، پس از ورود به Gmail، می‌توانید رویدادهای GCal خود را ببینید.

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

پلتفرم ها در دولت

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

• در مورد سرویس بیاموزید
  • آیا واجد شرایط هستم؟
  • (اختیاری :) مستندات را ارائه دهید
  • (اختیاری :) پرداخت کنید

  هر یک از این مراحل می تواند "پلتفرم" باشد (برای سکه کردن یک عبارت): شاید "ارسال اطلاعات" یک بستر باشد ، شاید "پرداخت یک بستر" باشد ، شاید "ارسال ایمیل های تأیید" یک بستر باشد ، شاید - اوه بله -"ورود به سیستم" می تواند یک سکوی باشد.

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

  سیستم عامل های سازمانی: شروع به عقب

  ادارات بزرگ دوست دارند (شما از قبل می دانید) رویکرد "سازمانی" برای حل مسئله را به خود اختصاص دهند ، و منجر به وضعیت جدیدی شود که گروه های داخلی کاملاً عاشق پیشنهادات سیستم عامل در جایی هستند که حداقل به آنها نیاز دارند و به احتمال زیاد اشتباه می کنند.

  در یک پست قبلی ، من توضیح دادم که چگونه سازمان های "سازمانی" هدف نهایی خود را "سازگاری" می کنند. برای کشیدن نقل قول:

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

  در این مفهوم ، سیستم عامل های فناوری یک غرق كلی هستند:

  • آنها کار به انجام کار را منطقی می کنند (یک تیم به جای تلاش کپی کردن ، مشکل مشابهی را برای همه دیگران حل می کند)
  • با حل یک مشکل در یک مکان مرکزی ، این بدان معنی است که همه یک تجربه مداوم دارند

  اگر کار من این بود که برنامه های بسیار پیچیده ای را ارائه دهم که به نظر می رسد بسیار جذاب است ، شما بهتر است باور کنید که من یک پلتفرم یا دو را در نمودار معماری سیستم خود قرار می دهم.

  اما حتی اگر این روی کاغذ خوب به نظر می رسد - خواننده وفادار، خود را آماده کنید - این در واقع در عمل بسیار عقب مانده است. مشکل اساسی شیفتگی «تجاری» به سکوها این است که نمی توانید یک گاری را بدون قرار دادن آن در مقابل اسب تصور کنید.

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

  1. پلتفرم برای هیچ

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

  در بسیاری از برنامه ریزی های سازمانی، ایده اصلی این است:

  1. طرح اولیه: بیایید یک برنامه، یک وب سایت و یک ربات چت بسازیم که لیستی از مزایا را نمایش دهد.
  2. بنابراین، ما باید بتوانیم داده های یکسان را در 3 مکان مختلف به طور همزمان بازیابی کنیم.
  3. بنابراین، ساخت یک پلت فرم بازیابی داده منطقی است (بیایید آن را "رابط شبکه عمومی برنامه کاربردی Y2K" بنامیم). این عالی است زیرا ما مجبور نیستیم عملکردهای مشابه را در مکان‌های مختلف بازسازی کنیم و محصولات پایین‌دستی ما را ساده‌تر می‌کند.
  4. بنابراین، ابتدا باید رابط شبکه عمومی برنامه Y2K (YAGNI) را بسازیم و بعداً برنامه، وب سایت و ربات چت خود را بسازیم، زیرا همه آنها به YAGNI متکی هستند.
  5. بنابراین، بیایید مجموعه‌ای از جلسات را رزرو کنیم که در آن YAGNI را با دعوت از 80 نفر برای بررسی یک پاورپوینت که در آن 100 کلمه در هر اسلاید وجود دارد، تعیین کنیم.
     • همچنین بیایید مطمئن شویم که از این به بعد همیشه آن را "YAGNI" بنامیم و هرگز آن را برای افراد جدید توضیح ندهیم.

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

  در اینجا چند شاخص خوب برای جلوگیری از ساخت یک پلت فرم وجود دارد:

  • وقتی 1 محصول دارید که می توانید از آن استفاده کنید
  • وقتی 0 محصول دارید که می توانید از آن استفاده کنید

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

  2. پلتفرم متاسفم که باید منتظر بمانید

  سیستم عامل های خوب زندگی را برای تیم هایی که باعث می شود زندگی را برای کاربران آسان تر کند ، آسانتر می کند. سیستم عامل های بد تیم ها را از پیشرفت های مورد نیاز منع می کنند - اینگونه "عالی" دشمن "خوب" می شود.

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

  در عوض ، بیایید در ساخت برنامه ، وب سایت و chatbot مکث کنیم و در عوض یک تیم "استراتژیک" را جمع کنیم تا برنامه ریزی و ساخت رابط کاربری شبکه عمومی برنامه Y2K خود را ایجاد کنیم: پس از داشتن آن ، این پلت فرم داده ما خواهد بود.

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

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

  • هیچ کس نمی تواند خط لوله آزمایش خود را تا زمانی که "استراتژی تست خودکار" آماده نشود ، بسازند.
  • هیچ کس نمی تواند یک سرویس ابری را منتشر کند تا اینکه "تیم پلتفرم ابری" "سکوی ابری" خود را ساخته و ارزیابی کرده است.
  • هیچ کس نمی تواند API عمومی خود را بسازد تا اینکه "API Gateway" در حال اجرا باشد.

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

  3. سیستم عامل های محور نمودار

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

  بدون راه آسانی برای تیم‌ها برای آزمایش فناوری‌های جدید، نرم‌افزارهای جدید و طرح‌های جدید، توانایی بلندمدت خود را برای مدرن‌سازی تدریجی خفه می‌کنید.

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

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

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

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

  تله خرس برنامه ریزی پلت فرم پیشگیرانه

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

  هر زمان که تغییر در یک سکو ایجاد کنید ، جلوه های ضرب و شتم بسیار بزرگتر از آنچه برای یک سرویس فردی وجود دارد ، بزرگتر است. این بدان معنی است که شما احتمالاً قبل از متعهد شدن به ساخت یک سکوی بزرگ و هونکین که صدها میلیون دلار تحول دیجیتالی شما را تحت تأثیر قرار می دهد ، دانش دامنه زیادی می خواهید. و یکی از راه های دستیابی به آن دانش دامنه این است که - آن را با من بگویید - توسعه محصول چابک.

  برنامه ریزی سازمانی می خواهد در پایان شروع کند (به معنای واقعی کلمه ، شما با برنامه ریزی "وضعیت نهایی" خود شروع می کنید): با مفهوم سازی آنچه یک استراتژی کاملاً تحقق یافته و کاملاً اجرا شده به نظر می رسد ، و سپس ریختن پول و انرژی در توصیف آن چشم انداز در دردناک است. جزئیاتبرنامه ریزی چابک از امروز آغاز می شود: اکنون چه چیزی داریم ، اولویت های ما در 6 ماه آینده چیست و برای چند سال آینده چه باید در نقشه راه خود قرار دهیم؟هنگام رسیدن به آنها از کدام پل ها می توانیم عبور کنیم؟

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

  برنامه ریزی چابک

  Agile یک رویکرد اساسی تکراری است که فضا را برای اطلاعات جدید می گذارد. این بدان معنا نیست که هیچ برنامه ریزی در این زمینه وجود ندارد ، اما این به معنای برنامه هایی است که کمتر جزئیات دارند و برای تنظیم باز هستند.

  بیایید از مثال برنامه ریزی برای تعطیلات استفاده کنیم.

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

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

  Agile در مورد برنامه ریزی برنامه هایی است که بر اولویت های فوری متمرکز شده و تصمیمات آینده را جهت می گیرند ، در حالی که برنامه ریزی شرکت در مورد ایجاد هواداران بیش از حد واقع بینانه در مورد دنیایی است که ما نمی دانیم که 84 ٪ از این پروژه ها به تأخیر افتاده اند یا به طور کامل شکست می خورند.

  شروع با ساده

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

  در Systemantics ، جان گال مشاهده زیر را در مورد سیستم های پیچیده انجام می دهد:

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

  بنابراین بیایید تفکر خود را تغییر دهیم: به جای 10 سال دور "حالت پایان" که در آن ما یک اکوسیستم فنی کامل و منطقی خواهیم داشت ، به نظر می رسد از نظر یک سیستم کار ساده چه فکر کنیم؟چگونه می توانیم با تمرکز روی یک چیز که کار می کند به جایی برسیم که باید باشیم؟

  یک چیز که کار می کند

  من قبلاً توضیح دادم که چگونه برنامه ریزی برای سیستم عامل های پیشگیرانه اغلب منجر به تحویل غیرقابل کنترل می شود که "ساده" از پنجره به همان سرعتی که پیش بینی های بودجه شما می رود ، از پنجره بیرون می رود. اما مسئله این است که بیشتر خدمات دولتی که من روی آن کار کرده ام در مورد ورود به سیستم و پر کردن یک شکل است و ساختن این نوع برنامه ها در سال 2022 نوعی مشکل حل شده است.

  90 ٪ از زمان ، شما می توانید چارچوب وب محبوب محبوب MVC خود را انتخاب کنید - جاوا دارای بوت بهار است ، پایتون دارای جنگو ، جاوا اسکریپت است ، اکسپرس ، C# دارای . NET و غیره - و آن را با یک پایگاه داده Postgres اجرا می کند. برنامه های MVC آسان برای یادگیری و پشتیبانی هستند و بانکهای اطلاعاتی رابطه ای تعریف خطرناک نیستند. اگر می توانید محصول خود را به عنوان چند کانتینر (برنامه + پایگاه داده) در حال اجرا باشد ، می توانید آن را بر روی هر فروشنده ابری منتشر کرده و قوانین خودکار سازی را تنظیم کنید تا مطمئن شوید که می تواند سنبله ها را در ترافیک کنترل کند. هر نان و کره هر فروشنده ابری دقیقاً این نوع محصول - یک برنامه MVC (با API اختیاری) و یک بانک اطلاعاتی مدیریت شده را میزبان و مقیاس بندی می کند - در صورتی که واقعاً آن را فشار دهید ، هزینه ماهانه بین 15 دلار تا چند صد است.

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

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

  آیا می تواند خیلی ساده باشد؟

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

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

  1. چرا من چیزی را می سازم که قبلاً می دانم بعداً باید تغییر کند؟آیا این تلاش هدر رفته نیست؟
  2. فقط همه چیز را تا حد امکان بسازید؟همیشه؟چه موقع تعمیم می دهم؟
  3. شاید از جایی که شما هستید ، اما به هیچ وجه نمی توانم با ساختن یک پایگاه داده ابری جداگانه در بخش خود فاصله بگیرم.

  1. برنامه ریزی برای تغییر با "معماری فداکاری"

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

  یک رویکرد متناوب در اینجا این است که با یک "معماری قربانی" شروع شود: یک معماری آگاهانه ساده لوحانه که در کوتاه مدت کار می کند و شما را به سمت حالت نهایی مورد نظر خود سوق می دهد. این شبیه به ایجاد یک نمونه اولیه است: شما یک نسخه اولیه از چیزی را ایجاد می کنید که می توانید پس از تأیید رویکرد ، بازنشستگی یا بازنشستگی یا بازسازی کنید.

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

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

  2. قانون سه

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

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

  3. خدمات "عمودی" هوشمندانه

  آیا من واقعاً پیشنهاد می کنم داده های شهروند را در یک پایگاه داده جدید در ابر قرار دهید؟آیا این ارزیابی شده است؟چگونه حتی می توانیم آن را تأمین کنیم؟در مورد SA و A سند چطور؟این یک کار گسترده خواهد بود !!

  مطمئناً ، شما همیشه می خواهید موانع خود را-یا ذاتی در فضای مشکل یا دپارتمان تحمیل کنید-اما یک اصل مهم چابک انتخاب برش های عمودی و نه افقی است ، که برای هوشمندانه کردن محصول (های) شما کاهش می یابد.

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

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

  بنابراین ، بله ، شاید ذخیره داده های شهروندان در این مرحله زودرس و غیرقابل کار باشد (آیا از آن محافظت می شود؟) - که منطقی است ، همه ما باید در محدودیت ها کار کنیم. اما بدون درخواست از مردم برای ایجاد حساب ، چه ارزشی می توانید ارائه دهید؟شاید این کافی باشد که در مورد برنامه هایی که برای آنها اعمال می شود ، بیاموزید تا بتوانند اسناد مورد نیاز خود را جمع کنند. به یاد داشته باشید ، هدف شما حمل و نقل است ، بنابراین بیشتر از آنچه می توانید جویدید نیش بزنید. همیشه راهی برای دامنه محصولات وجود دارد که یک مشکل کامل را برای کاربر نهایی حل می کند ، در حالی که مشکلات را برای خودتان به حداقل می رساند.

  ابتدا خدمات ، سیستم عامل ها بعداً

  سیستم عامل های فناوری بلوک های ساختاری هر اکوسیستم دیجیتال کاملاً یکپارچه هستند و همه ما باید برای آنها آرزو کنیم. با این حال ، در زمینه برنامه ریزی فناوری اطلاعات دولت ، یک "سکوی" معمولاً به معنای تحویل عظیم ، گران قیمت و انتزاعی است که از لحاظ تئوری بسیاری از مشکلات را در هنگام آماده شدن حل می کند اما در این میان شما هنوز هم تمام آن مشکلات را دارید زیرا به تأخیر می افتد.

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

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