این یک داستان به اندازه خود فناوری است …
دسته ای از افراد برای ساخت سیستم استخدام شدند. بنابراین ما انجام دادیم.
سپس از ما خواسته شد تا یکی دیگر را بسازیم. بنابراین ما هم این کار را کردیم.
سپس مورد سوم درخواست شد. و ما هم آن را ساختیم …
در جایی در این مسیر ، فهمیدیم که شروع به توسعه یک ردپای زیرساخت بسیار بزرگ می کنیم. این امر باعث افزایش تقاضا برای تیم ما از افراد می شود که سعی در توسعه سیستم ها دارند … کسی که باید روی مدیریت زیرساخت ها تمرکز کند. بنابراین ما یک دسته از افراد را برای انجام این کار استخدام کردیم.
نوشتن درخواست ایجاد تیم پلتفرم احتمالاً چیزی در مورد “ارائه پلتفرم به عنوان خدمتی که توسعه دهندگان فقط می توانند از آن استفاده کنند ، ذکر کرده است ، که می تواند کار توسعه آنها را تسریع کند” … راهی برای انتزاع همه وصله سیستم عامل و تنظیمات امنیتی و سایر مواردی که یک توسعه دهنده برنامه به عنوان یک حواس پرتی فکر می کند.
لغزش از ریل ها
در ابتدا همه چیز خوب پیش می رفت … اما با گذشت زمان ، تیم پلتفرم در برخورد با امنیت ، انطباق ، شبکه ، ذخیره سازی ، مدیریت ساختمان ، فروشندگان یا هر تعداد تیم دیگر که باید با آنها ارتباط برقرار کنند ، دچار مشکل شدند. به تدریج ، تمرکز آنها از تیم های توسعه دهنده ای که برای خدمت به آنها ایجاد شده اند منتقل شد.
مدتهاست که تیم پلتفرم حتی فراموش می کند که آن حلقه های بازخورد را با Dev به دست آورد و حفظ کند. “آه ، ما می دانیم که آنها به چه چیزی نیاز دارند.”
اما این مشکل است … پلتفرم نمی کند بدانید که توسعه دهندگان به چه چیزی احتیاج دارند. این نیازها با هر کار جدید در حال تغییر است! و تمرکز “توسعه دهنده محور” با تمرکز “سکوی محور” جایگزین می شود.
اما … ما هم هستیم ، نه؟
آره تو هستی اما شما دارید اهداف مختلفبشر و وقتی اهداف شما واگرایی می کنند … چگونه می دانید؟ چگونه مسیری را انتخاب می کنید که به بهترین وجه از تجارت پشتیبانی می کند؟ وقتی تجارت می پرسد که آیا شما برای مقیاس ساخته اید ، سؤال خواهد بود … “مقیاس ما برای چه کسی ساخته ایم؟”
و برای آنچه ارزش آن را دارد ، گاهی اوقات افراد سکو در واقع دارند فراموش شده که آنها نیز توسعه دهنده هستند. آنها عمیق در ذهنیت غرق می شوند که “من نرم افزاری نمی نویسم. این همان است آنها مردمی انجام می دهند. “(شخصاً ، این دلیلی است که من تمایل دارم از این اصطلاح استفاده کنم سازندگان به جای توسعه دهندهبشر این تعداد کمتری به آن دارد.)
تیم های پلتفرم واقعی از سکوی محور نیستند
چگونه یک تیم پلتفرم می تواند بگوید که آنها طرح را از دست داده اند؟
-
تصمیمات ابزاری بدون ورودی از تیم های Dev گرفته می شود. چند بار از افرادی که فکر می کنید باید از آنچه می سازید استفاده می کنید؟
-
سیستم عامل ها از نظر فنی عالی هستند اما پذیرش کند است. “توسعه دهندگان فقط از آنچه ما ساخته ایم استفاده نمی کنند!” به یک شکایت رایج تبدیل می شود.
-
معیارها با محوریت زیرساخت ها (به موقع ، انطباق) هستند ، و نتیجه ای متمرکز نیستند (زمان به اولین بار مستقر ، زمان منجر به تغییر و غیره). آیا تیم خود را به روش هایی که نشان می دهد اندازه گیری می کنید نمایندگان شما موفق می شوند؟
بینش کلیدی: یک بستر فنی عالی که هیچ کس از آن استفاده نمی کند ، خرابی است تفکر محصول، نه مهندسیبشر
مثل تیم محصول فکر کنید
آیا تا به حال فکر کرده اید ، “ما این چیز عالی را ساختیم ، چرا آنها از آن استفاده نمی کنند؟”
اگر چنین است … مشکلی نیست. این یک چیز معمول است که چنین احساسی داشته باشید! بیشتر ما (خودم شامل) از طریق کار به سیستم عامل رسیدیم مهندسی سازمان ما در حمایت از سیستم بسیار عالی بودیم و به تدریج مهارت ها و مسئولیت های خود را افزایش دادیم تا اینکه توجه تیم/مدیر پلتفرم را به خود جلب کنیم. ما نبودیم آموزش دیده برای فکر کردن در مورد مدیریت محصول.
اما از دیدگاه محصول در مورد آن فکر کنید:
اگر من محصولی را تهیه کنم که قصد فروش آن را در بازار آزاد داشته باشم ، آیا این معقول است که فقط آن را بسازیم و سپس امیدوارم که این چیزی باشد که مشتریان به آن احتیاج دارند؟
تیم های محصول یک تن از تحقیقات بازار انجام می دهند – آنها دائماً با مشتریان و چشم اندازهای مربوط به آنچه مردم نیاز دارند صحبت می کنند.
بنابراین بیایید از دیدگاه محصول در مورد پلتفرم خود فکر کنیم. پلتفرم شما دارای:
- کاربران (تیم های DEV شما می خواهید آن را اتخاذ کنید)
- استفاده از موارد (سرعت برای تحویل ، استقلال در سیستم عامل)
- اهداف پذیرش
سکوی شما یک است محصولبشر بنابراین ما باید برخی از این مهارت های محصول را اتخاذ کنیم تا پلتفرم خود موفق شود! در اینجا نحوه کسب این برنده ها آورده شده است:
-
فکر کردنبشر اگر Devs شما نتوانند به راحتی از آن استفاده کنند ، بی ارزش مبتنی بر YAML است. آیا شما به آنچه برای بهترین چیزها فکر می کنید فکر می کنید شما یا چه چیزی برای بهترین است خود را؟
-
کاربر در حال سوار شدنبشر مانند “تاریخ اول” به آن فکر کنید … اگر این برداشت اول افتضاح است ، آیا می خواهید یک تاریخ دوم دریافت کنید؟
-
مستندات روشنبشر تصور کنید که اولین روز شما در سیستم عامل است. از کجا می دانید چه کاری انجام دهید؟ آیا اسناد لازم برای کمک به شما را دارید یا باید تمام روز را با پرسیدن سؤال کنید؟
-
همدلی ، نه فقط اجرایبشر بله ، گاهی اوقات شما باید کارها را انجام دهید زیرا باید از امنیت و امنیت سکو محافظت کنید. بعضی اوقات این تصمیمات می تواند کارها را برای توسعه دهندگان دشوارتر کند. آیا شما برای به حداقل رساندن شعاع انفجار آن تصمیمات ، آنچه را می توانید انجام می دهید ، یا فقط قوانین مربوط به انطباق خود را در جای خود قرار می دهید؟
مجدداً بر روی توسعه دهنده
بازی بارز در اینجا این است که بفهمیم چگونه حلقه بازخورد توسعه دهنده را دوباره وصل کنید. اما اگر از تمرین خارج نشوید ، ممکن است دوباره این پمپ سخت باشد. در اینجا چند ایده وجود دارد:
-
وقت خود را صرف تماشای کار توسعه دهندگان کنید. به دنبال آنچه آنها گیر می کنند ، یا اولین بار درست کار نمی کند.
-
مصاحبه های داخلی کاربر و مطالعات قابلیت استفاده را انجام دهید. بسیاری از تیم های Dev یک شخص UX دارند … شاید بتوانید چند ترفند از آنها شریک شوید و یاد بگیرید؟
-
میزبان “ساعات اداری سکو” یا اعضای تیم در تیم های محصول به صورت دوره ای است.
-
یک توسعه دهنده چرخان را به جلسات برنامه ریزی خود دعوت کنید.
-
قبل از اجرای استانداردها ، اعتماد ایجاد کنید. سریعترین راه برای بیگانه کردن توسعه دهندگان این است که دیر با یک دروازه به جای اوایل با راهنمایی ظاهر شوید.
بسته بندی
من پست امروز را با چند سوال می بندم:
-
آخرین باری که تیم Dev را با استفاده از ابزارهای پلتفرم خود مشاهده کردید چه زمانی بود؟
-
آیا یک توسعه دهنده جدید می تواند در روز اول خود با استفاده از سکوی شما چیزی مفید باشد؟
-
آیا موفقیت پلتفرم را از نظر توسعه دهنده (مانند سهولت استفاده ، فرزندخواندگی یا کاهش زحمت) اندازه گیری می کنید؟
-
آیا تیم های Dev درخواست شما را ارسال می کنند – یا راه حل های شما را برای شما ارسال می کنند؟
اگر پاسخ ها شما را ناراحت کننده می کند … شما شکست نمی خورید. شما فقط برای مرحله بعدی آماده هستید.
